Payment networks and methods for facilitating data transfers within payment networks

Exemplary payment networks and methods are provided for facilitating data transfers. One exemplary method includes determining a performance of a first path through a first WAN between a hub and a customer, determining a performance of a second path through a second different WAN between the hub and the customer, causing a data traffic associated with a first class of application to be routed along the first path when the performance of the first path is within a first performance threshold, and causing the data traffic, when routed along the first path, to be switched to the second path when the performance of the first path fails to satisfy and/or violates the performance threshold.

FIELD

The present disclosure generally relates to payment networks and methods for facilitating the transfer of data within the payment networks.

BACKGROUND

A variety of data transfers occur within a payment network to permit the authorization, clearing, and settlement of payment account transactions among issuers and/or acquirers to the transactions. In addition to transaction authorization, clearance, and settlement, the payment network is embodied to provide a variety of services between the payment network and customers of the payment network, including, the issuers, the acquirers, and third parties who provide services to the payment network, etc. In general, the payment network operates to ensure responses, often prompt responses, to transactions, while permitting secure movement of data through the payment network.

DETAILED DESCRIPTION

Payment networks provide data transfer between data centers and customers (e.g., third party networks, remote data centers, or other customers/partners, etc.) through third party carriers, such as telecommunications providers. The networks and methods herein provide a dynamic network with multiple paths (or routes), supported by multiple wide area networks (WANs) disposed between a data center and each customer, so that traffic to/from the customer may be shifted between different paths based on performance. In particular, traffic specific to sensitive applications/services, may be transferred along a preferred path to a customer and switched between the preferred path and a different path to the customer to enhance and/or ensure performance. In this manner, the network is able to maintain data transfer along one of the multiple paths, generally independent of the particular WAN, and switch the data transfer to a different path when the original path is degraded below one or more thresholds. Additionally, the paths are defined by dynamically generated tunnels, which permit not only direct access between the data center and the customer, but also between customers. The network further provides enhanced security by relying on certificate-based encryption (e.g., IPSec, etc.), which is managed centrally for efficient access, issuance and revocation.

FIG. 1illustrates an exemplary network100, in which the one or more aspects of the present disclosure may be implemented. Although parts of the network100are presented in one arrangement, other embodiments may include the same or different parts arranged otherwise, depending, for example, on the types and/or priorities of applications within the network100, the interactions of the applications with the network100, etc.

In the exemplary embodiment, the network100is a payment network connected to various customers, which interact with the payment network to provide and/or receive information related to transactions among customers/merchants (e.g., authorization, clearing, settlement, etc.) and/or services offered by a service provider to customers of the network100, or to data transactions between data centers in different geographic regions. The network100includes a primary hub102and a backup hub104, each connected to data centers106a-b. The data centers106a-bhost a variety of different types of information related to the payment network100and transactions within the payment network (or, as stated above, other related services), etc. Generally, the data centers106a-b, when separated, are located in different geographic regions, such that they may serve primary/backup roles, in this embodiment, as environmental conditions may limit the performance, availability, and/or access to only one of the data centers106a-b. The data centers106a-bare coupled to one another in the network100by a dedicated network (e.g., WAN, etc.), indicated by107. The dedicated network107, or communication media, permits the data centers106a-bto be redundant, as necessary.

Each of the hubs102and104includes multiple routers108a-dand110a-d, respectively. The routers108a-cand110a-care coupled to at least one of wide area networks (WANs)112a-c, as illustrated inFIG. 1, for each of customers118and120. In this exemplary embodiment, the WANs112include multiprotocol label switching (MPLS) networks, provided by one or more third parties, such as, for example, telecommunication providers, etc. The WANs112, which may include a variety of different implementations/parties, provide a network that generally spans a geographic region, such as, for example, a state, county, country, continent, or the globe, etc. In addition to the WANs112, the network100further includes, or is coupled to, the Internet114.

With continued reference toFIG. 1, the WANs112are coupled to edge routers116a-dThe edge routers116are located proximate to and are coupled to the customers118and120, respectively. The customers118and120, in the illustrated embodiment, include banks or bank associated institutions, which function as issuers of payment accounts, and/or acquirers of transactions from merchants, or another entity which provides services within the payment network100(e.g., rewards entities, authentication entities, etc.), etc. In one or more embodiments, one or more merchants may be a customer to a network, potentially depending on, for example, its size, volume of transactions, and/or other interactions with the payment network, etc. Further, in at least one embodiment, the customer118or customer120may include a separate data center, which is related to data centers106(i.e., a redundant or backup data center), located in a different geographic region. For example, the data centers106, as part of a global network for Bank Company, may host data for a first region (e.g., the United States, etc.), while a separate data center of Bank Company may host data for a separate region (e.g., Europe, or India, etc.). In such an example, the separate data center may be represented as the customer118, in this exemplary embodiment, described herein.

As shown inFIG. 1, each of the routers108of the hub102is coupled to one of the WANs112, or the Internet114. As shown, router108ais coupled to WAN112a; the router108bis coupled to WAN112b; the router108cis coupled to WAN112c; and the router108dis coupled to the Internet114. Likewise, as shown, router110ais coupled to WAN112a; the router110bis coupled to WAN112b; the router110cis coupled to WAN112c; and the router110dis coupled to the Internet114. Proximate to customers118and120, the WAN112ais coupled to edge router116a; the WAN112bis coupled to edge router116b; the WAN112cis coupled to edge router116c; and the Internet114is coupled to edge router116d. In this manner, the data transfer path from the data center106ato the customer118may include the WAN112aand/or WAN112b, i.e., different paths, and separately, the data transfer paths from the data center106ato the customer120may include the WAN112cand/or Internet114.

Because the same structure is repeated, in this exemplary embodiment, between each of customers118and120and the hub102and the backup hub104, if issues arise with either the hub102, or the backup hub104, data transfers provided by a problematic hub may alternately be provided through the other hub.

Further, while only two customers118and120are shown inFIG. 1, a different number of customers may be included in the network100. Generally, consistent with customer118, for example, the network will associate at least two routers (e.g., edge routers116a-b) to each customer, with each router coupled to a different WAN and/or the Internet, thereby providing two potential communication paths to the additional customer. In one or more embodiments, however, certain customers may be coupled to the network100, via multiple routers (e.g., two or more), while other customers may be coupled to the hub via only one router. The availability of one or more alternate paths to/from the customer may impact the implementation of one or more aspects described herein.

Furthermore, while only two WANs or one WAN and one Internet are illustrated as coupled to each customer118and120in the network100inFIG. 1, it should be appreciated, however, that depending on desired performance, for example, the customers118and120(and/or other customers supported by the network100) may be coupled to additional WANs and/or Internets (e.g., three, five, eight, etc.), whereby routing, as described herein, could be done between the customers118and120and the data centers106aand106b, via additional paths therebetween. In one particular example, up to eight different WANs and/or Internets may be coupled between a like number of hub routers in the hub102and a like number of edge routers at the customer118. Further still, the hub102and/or hub104may be coupled to more or less WANs and/or Internets, in other payment network embodiments, again depending on, for example, desired performance, etc., with more WANs and/or Internets coupled to certain customers and less WANs and/or Internets coupled to other customers.

Traffic in the network100(i.e., data transfers) may be related to payment transactions (e.g., authorizations, clearing, settlement, etc.), file transfer applications/services, mobile application support, operations, interactive (e.g., HTTP, etc.), management, video applications/services, voice applications/services, etc. Despite these specific examples, it should be appreciated that any different kind of data transfers may be effected within network100, whether related or unrelated to payment transactions, applications and/or services, etc. More generally, in various embodiments, the network100may be unrelated to a payment network, or payment transactions.

With further reference toFIG. 1, each of the hubs102and104includes a routing engine122, which in this embodiment, is a router. The routing engine122coordinates traffic along different paths from the respective hubs102,104to customers118and120. In the network100, paths A and B are provided between the customer118and the hub102. Likewise, paths C and D are provide between the customer120and the hub102. In this exemplary embodiment, an additional path126exists between the WAN112band the router116c, i.e., the different customers118and120are coupled to the same WAN, as will be described below. The routing engine122is configured to respond to one or more parameters and/or rules to route the traffic from hub102to customer118, for example, along either path A through WAN112aor path B through WAN112b.

As shown inFIG. 1, the edge routers116aand116ceach include a routing engine132. Specifically, rather than a separate router like routing engines122in hubs102and104, in this exemplary embodiment, the routing engines132are embedded in the edge routers116aand116c, as shown. The routing engines122or132, whether as standalone routers, or otherwise implemented in other devices, or embedded in other devices, such as a router, performs substantially consistent with the description herein. For ease of reference, however, the description is presented with reference to routing engine122, but the statements and descriptions are equally applicable to the routing engines132.

In one example, the routing engine122relies on a preferred path, load balancing, and/or one or more thresholds, in part, to make a selection between different paths A and B for the transfer of data between hub102and customer118, and further, to switch the data transfer between different paths A and B. The threshold, as described in more detail below, may relate to, for example, percentage loss (e.g., byte loss percentage, packet loss percentage, etc.), latency of the path, jitter, percentage of bandwidth, etc. The threshold may be generic to the data being transferred to/from the customer118, or may be specific to the type or class application associated with the data being transferred to/from the customer118. For example, particular applications (e.g., voice applications, etc.) may have a higher value of thresholds on path performance (e.g., 3% packet loss percentage, etc.), to ensure, provide and/or preserve quality of service. Conversely, a batch file transfer related to clearing/settlement may be classified with a less stringent, or lower value, threshold (e.g., 10% packet loss percentage, etc.) as minor delay(s) in the transfer generally have minor or no impact on the overall settlement process. In general, the routing engine122is application/service aware, in that it includes one or more data structures (e.g., tables, lists, etc.) in which different traffic types are identified (by characteristic(s) and/or content of packets in the data traffic), so that the routers108, for example, are able to inspect packets as received to identify the type of application/service associated with the data traffic. As such, traffic may be routed for the specific applications/services, thereby providing greater sensitivity to specific application/service performance considerations. Without limitation, in determining particular applications/services to which particular data traffic relates, the routing engine122may monitor traffic flow for particular issues, cause probes to be transmitted between routers associated with the hub102, etc. Uniquely, therefore, the path is not merely changed in a failed path scenario, but it may further be changed or switched based on altered or degraded path performance scenarios (e.g., based on failure to satisfy and/or violation of one or more thresholds, etc.).

In the embodiment ofFIG. 1, routing parameters and/or rules are stored in memory (e.g., memory204, etc.) in the routing engine122, at hub102. A copy of such routing parameters and/or rules is included at hub104as well, in routing engine122, for use when hub104is employed as a back-up hub, or otherwise. Further, each router108relies on the routing engine122for such parameters and/or configuration rules. The routing engine122relies on loopback addresses for one or more operations, including receiving configurations, creating at least one routing table for network prefixes (e.g., for network100, etc.), and sending probes along multiple different access paths, etc. In short, it is the routing engine122that controls traffic between different paths from the hub102(or hub104) to customers118and120(and other customers).

In addition to threshold based routing, as indicated above, the routing engine122, at each of hubs102and104, may also be configured to employ one or more of a preferred path for specific applications (or classes of applications), load balancing, and application diversity between the paths. For example, the routing engine122, at hub102, is configured to originally select path A through WAN112aover path B through WAN112b, based on the preferred path A (e.g., an application-specific path, etc.), etc. Once selected, in various embodiments, the routing engine122is configured to continue to compare the performance of available paths (e.g., path A and path B, etc.), and potentially switch paths, if the prior selected path performance degrades below one or more thresholds (potentially regardless of preferred paths, load balancing, etc.). The routing engine122thus is able to select and/or improve/preserve the performance of the data transfer from the data center106a, through the hub102, to the customer118via path A or path B, as needed.

Generally, the paths A, B, C, and D, in this exemplary embodiment, are tunnels, and specifically, GRE (generic routing encapsulation) tunnels. The tunnels are generated (automatically, in this embodiment) on-demand dynamically, by the edge routers116(or, more generally, in the direction of the originator of the data transfer (e.g., routers108,110or116, etc.)), to support transfer of data between the hub102(i.e., routers108) and edge routers116, as needed. Further, the tunnels may be provided for customer-to-customer transfers, whereby access to the data centers106is not required. In several embodiments, the tunnels are automatically generated, starting at the edge routers116, and are deleted, by the routing engines122(and/or routers116) when not in use, either immediately or after an expiration period.

The description herein is generally limited to paths A-D, between the data centers106and customers118and120. It should be appreciated, however, that customer-to-customer data transfers are also provided in the network100, as indicated below.

In the exemplary embodiment ofFIG. 1, the tunnels (e.g., paths A-D, etc.) are encrypted with Internet Protocol Security (IPSec), which is provided to encrypt data as it exits the routers108and110to the WANs112toward the customers118and120, and/or as it exits the edge routers116to the WANs112(or Internet114) toward the data centers106. The hubs102and104and edge routers116then decrypt incoming data from the WANs112or Internet114. In addition in this embodiment, the network100further includes firewalls130, which are separate from and/or integrated with the routers108d,110d, and116d. The firewalls130, and not the respective routers108d,110d, and116d, in this example, encrypt and decrypt the data, via IPSec, flowing to and from the Internet114. As such, regardless of WAN or Internet, the network100provides end-to-end encryption of data transfers (i.e., routers108,110, and116at either end of the WANs112or Internet114). It should be appreciated that the illustration of firewalls130, associated with particular routers108d,110d, and116d, does not suggest that firewalls may not be disposed elsewhere in the network100ofFIG. 1, to perform one or more functions related to encryption.

In this exemplary embodiment, encryption may reduce the types of traffic that the routers108,110, and116identify, and thus, may provide simplified routing of traffic. The encryption further permits efficiency in the creation and maintenance of access filters, at network routers (shown and not shown), which may be added, as desired, to govern the routers' interactions with the WANs112and may provide additional edge security to network100.

Encryption of data transfer in the tunnels (e.g., paths A-D, etc.), as described in more detail below, is based on certificates. In this exemplary embodiment, each of the data centers106includes a certificate server128, as shown. When any of the routers108,110, and116, are initialized, the routers contact the appropriate certificate server128, to receive a certificate, by sending information (e.g., router name, identifier/ID, location, etc.) to the certificate server128. In turn, the certificate server128, if approved, creates a public certificate for the routers108,110, and116, signs it, and returns it to the routers108,110, and116. In this manner, the hub routers108and110and the edge routers116are IPSec peers within the network100. The certificate then provides the IPSec keys for the encryption/decryption of the data transferred, at the hubs102and104and the routers108,110and116.

As an example, to open a tunnel to another router, such as router108a(prior to routing any traffic), the router116asends its certificate. The router108areviews and verifies the certificate, before responding with its own certificate to the router116a. When the router116areviews and verifies the certificate, a trust is created between the two routers116aand108a, by which a tunnel is generated and data may then be transferred therebetween (i.e., IPSec encrypted data). Because the customers118and120are both connected to the WANs112(the edge router116cis connected by path126), in this example, the routers116band116care able to communicate using a similar process. When router116bwants to open a path to router116c, it sends a message to hub102, which is redirected, by the router108b, to the router116c(along a tunnel between router108cand116c). The router116c, in turn, reviews and verifies a certificate included in the message from the router116b, and then provides its certificate back to router116b, which permits (upon verification of the certificate), the routers116band116cto generate a tunnel (i.e., IPsec tunnel in this embodiment) directly therebetween (without passing data through the hubs102and104).

Further in the network100, the data centers106are protected with intrusion detection sensors (IDS)124. In the exemplary embodiment, the sensors124at the data centers106are part of or coupled to the hubs102and104. The sensors are configured to inspect every packet (i.e., 100%), or a high percentage of packets (e.g., 95%, 99%, 99.9%, etc.), received by the hubs102and104(and/or the data centers106) for signatures of intrusion, viruses, malware, hacks, etc., or other signatures of attack on the network100, and specifically, the hubs102and104and/or the data centers106a-b. It should be appreciated that the sensors124may be employed elsewhere in different network embodiments, or even omitted, in other embodiments.

For illustration, the network100is described herein with reference to an exemplary computing device200, as shown inFIG. 2. Generally, the data centers106, the routers108,110and116, and the customers118and120, as illustrated inFIG. 1, are embodied in one or more computing devices, such as the computing device200, etc. The network100, and its parts, however, should not be considered to be limited to the computing device200, as different computing devices, and/or arrangements of computing devices may be used in other embodiments.

As shown inFIG. 2, the exemplary computing device200generally includes a processor202, and a memory204coupled to the processor202. The processor202may include, without limitation, a central processing unit (CPU), a microprocessor, a microcontroller, a programmable gate array, an application-specific integrated circuit (ASIC), a logic device, or the like. The processor202may be a single core processor, a multi-core processor, and/or multiple processors distributed within the computing device200. The memory204is a computer readable media, which includes, without limitation, random access memory (RAM), a solid state disk, a hard disk, compact disc read only memory (CD-ROM), erasable programmable read only memory (EPROM), tape, flash drive, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. Memory204may be configured to store, without limitation, routing protocols, classifications of applications/services, rules, thresholds, and/or other types of data suitable for use as described herein.

The computing device200further includes a network interface206coupled to the processor202, which permits communication with the various other components included in the network100. The network interface206generally includes one or more wired network adapters, suitable for use as described herein, but may also include one or more wireless network adapters, or other devices capable of communicating to one or more of the same or different networks.

The computing device200, as used herein, performs one or more functions, which may be described in computer executable instructions stored on memory204(e.g., a computer readable storage media, etc.), and executable by one or more processors202. The computer readable storage media is a non-transitory computer readable media. By way of example, and without limitation, such computer readable storage media can include RAM, read-only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of executable instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.

FIG. 3illustrates an exemplary embodiment of a method300for use in facilitating transfers of data within a payment network. The exemplary method300is described with reference to the network100, and the computing device200. The method300, however, should not be understood to be limited to the network100and/or computing device200, as other networks and computing devices may be employed to perform the method300. Conversely, network100and computing device200should not be understood to be limited to the method300.

The routing engines122generally operate to provide access for the customers118and120to the data at the data centers106, to receive data from the customers118and120to the data centers106, and further to provide services offered by the payment network100, based on access to the data centers106, to the customers118and120, and to other customers, for example, within the network100. The routing engines122, in this embodiment, initially rely on preferred routing or load balancing, when data traffic is initiated, and further rely on path preference and thresholds to further select, maintain and/or switch among potential paths between the customers118and120and the data centers106, for example. In the exemplary method300, the routing engine122of hub102is providing access between customer118and data center106a, through either path A or path B. It should be appreciated, as described above, that other paths may be employed to provided access (e.g., to enable data transfers, etc.), between the illustrated and/or other data centers and customers.

While the method300is described with reference to routing engine122, specifically the routing engine122that is part of hub102, the description is applicable to the routing engine122of hub104, and also the routing engines132in the edge routers116.

As shown inFIG. 3, in the method300, the routing engine122of hub102receives, at302, a request to transfer data to the customer118. Despite the exemplary flow of data in this description, it should be appreciated that data may flow in either direction between the customers118and120, the hubs102and104, and the data centers106.

At,304, the routing engine122determines if the data should be routed according to load balancing, or according to a preferred path. The option for load balancing or preferred path is generally selected by the operator and/or designer of the network100to provide consistent and/or efficient service, and specifically, quality of service, to the customers118and120and the data centers106. Routing may be selected, in general, for all data traffic, or it may be specific and particular to different classes, applications/services, and/or information. In the exemplary embodiment, the applications/services are often organized into different classes, based on a number of factors, such as, for example, the importance of the data traffic in the class, etc. For example, a higher threshold of performance may be required for video or voice applications, than batch file transfers. It may be determined to be advantageous to select a particular preferred path for classes, or, alternatively, to ensure particular classes are handled consistent with load balancing, depending on the particular embodiment.

For purposes of illustration, path A is considered to be a primary path, and path B is considered to be a secondary or backup path. As shown inFIG. 3, when preferred path routing is indicated, at304, the routing engine122determines, at306, whether the preferred path, i.e., primary path A, in this example, is within a threshold. In particular, at308, different routers within the network100(e.g., routers108,110and116, etc.) transmit probes along the paths (or tunnels generated as described above) associated with the hub102and hub104, to determine the performance of the paths, relative to one or more thresholds. The probes may be transmitted periodically, for example, every 10 seconds, 15 seconds, 30 seconds, 1 minute, or a different interval depending on the traffic along the path, the type of the WANs112, etc. In one example, the routers108,110and/or116transmit three probes every 1-10 seconds. The routing engine122then determines, after 30 seconds, for example, how many of the probes were received back to the routers108,110, and/or116. For example, if one of the three probes is missed, the loss indicated for the path would be 33%. The performance, based on the probes, is compared to the threshold for the applications/services, and the primary path, at306, is determined to be within or not within the threshold.

Upon response to the probes, the routers108,110and116report back to the routing engine122(or routing engine132) certain information such as, for example, timing of the probes, number of probes, response to probes, etc., which is specific to one or more performance characteristic(s) of interest. The performance characteristic(s) may include, without limitation, byte loss, packet loss, bandwidth used percentages, jitter, latency, etc. The routing engine122, in turn, employs one or multiple thresholds, to determine if the path performance, specific to the characteristic(s) of interest (potentially specific to an application class), has degraded and/or is suitable for use. It should be appreciated that the thresholds, at306(or at312,320,326, and328, described below), may be different for different applications/services within the network100. Further, in multiple embodiments, as indicated above, the network100divides different applications/services into different classes. Different classes may be assigned different thresholds, depending on, for example, the importance of the data traffic in the class. The different traffic (or applications or services) may be defined in different classes, whereby the routing engine122would act more or less quickly to alter the routing path of the traffic, when degradation of the path is detected. Like the performance parameters, for example, the thresholds may also be based on byte loss, packet loss, bandwidth used percentages, jitter, latency, etc.

In this exemplary embodiment, when the path performance is within the thresholds (e.g., the packet loss is below about 5%, etc.), the routing engine122routes the data to the primary path A, at310

Conversely, if the primary path A is not within the threshold, at306, the routing engine122determines, at312, whether the secondary path, (i.e., path B, in this example) is within one or more thresholds. The threshold may be the same, similar, or different than the threshold employed, at306. In this particular example, the threshold is packet loss below about 5%, and is the same as the threshold employed at306. Again, however, different thresholds and/or a different number of thresholds, based on the same or different performance characteristic(s), may be used in other routing engine embodiments.

If path B is not within the threshold, at312, the routing engine122falls back to conventional routing rules and/or techniques, at314, including for example, bandwidth delay, route summarizations, etc., associated with one or more routing protocols to thereby select between the available paths. Alternatively, if path B is within the threshold, the routing engine122routes the data to the secondary path B, at316.

Because, at this part of the method300, the routing engine122is still governed by the preferred path selection at304, the routing engine122attempts to maintain the data traffic on the primary path, i.e., path A. The routing engine122is therefore configured to keep or return the data to the primary path. Thus, after the routing engine122switches the data to path B, at316, the routing engine122determines, at320, if path A is within one or multiple thresholds, and continues to determine, at320, if the primary path is within the threshold, at a regular or irregular interval, regardless of whether the secondary path is within one or more thresholds. The determination is again based on the probes transmitted at308.

When the primary path, or path A, comes within the threshold at320, the routing engine122switches the traffic back to primary path A, at318. And then returns to operation320, to continue to determine if the primary path A is within one or more thresholds. If the primary path A is within the threshold, at320, and the current path is the primary path A, the routing engine122takes no action, and returns to (or maintains at) operation320to, again, determine if the primary path A is within one or more thresholds, in a loop at a regular or irregular interval (e.g., every 3 minutes, 5 minutes, 18 minutes, or other predefined interval, etc.).

Referring still toFIG. 3, alternately, at304, the routing engine122of hub102may route data based on load balancing. In particular, the routing engine122may balance the traffic based on, for example, the destination and the differentiated services code point (DSCP) within the traffic, which alone or in combination with other parameters, is used in one or more algorithms to shift load among the multiple paths, i.e., paths A and B. For example, if the data to be transferred is the same as an existing or recent data transfer (e.g., it includes the same destination and DSCP, etc.), the routing engine122will route the data along the same path. However, if the transfer is different (e.g., either the destination or DSCP is different, etc.), the routing engine122routes the data transfer based on, for example, load, performance, and other parameters indicative of the quality of the path, etc. Based on a comparison among the available paths, the routing engine122selects a path for the traffic. Different algorithms may be employed for determining load balancing and for directing traffic. Algorithms, for example, may permit new and existing traffic to be distributed between available paths, based on better characteristics in one path over another, with a ceiling for each path, e.g., 95% of bandwidth, etc., after which balancing would not be used to further load the path.

It should be appreciated that, in various embodiments, a variety of criteria may be employed in load balancing, so that one path is not loaded to the point of substantially degrading performance of the network100. In one or more embodiments, load balancing may be applied or not applied based on the class of the application/service traffic (e.g., as defined by DSCP settings, etc.) to be routed.

With continued reference toFIG. 3, relying on load balancing, the routing engine122selects a path (e.g., path A or path B) to route traffic, at322, and then routes the data traffic along the selected path as described above, at324. Consistent with the description above, the routers108,110, and116transmit probes along the selected path, and then report one or more performance characteristics of the selected path (e.g. path A, etc.) to the routing engine122(or routing engine132). The routing engine122, in turn, determines, at326, based on the performance, whether the selected path is within one or more thresholds. The threshold used, generally relates to the performance characteristic(s) of the selected path, including, for example, byte loss, packet loss, bandwidth used percentages, jitter, latency, etc. When the selected path is not within the threshold, at326, the routing engine122determines if the alternate path (i.e., unselected path B) is within the threshold, at328. If the alternate path is within the threshold, the routing engine122routes the data traffic along the different path, i.e., the newly selected path, at330. Alternatively, if the alternate path is not within the threshold, at328, the routing engine122routes the data traffic according to conventional routing rules and/or techniques, at332. Operations326-332are repeated, as necessary, so that data traffic is maintained on an available path (i.e., the selected path), which is within the threshold for the particular application, class, or in general.

Consistent with the above, regardless of whether the routing engine122, or routing engine132, employs preferred path or load balancing at304, the network100is able to provide two paths for data transfers, while also providing sensitivity to the particular applications/services at issue. For example, the routing engine122may act to decouple and switch traffic associated with some applications/services to a different path, while leaving other traffic associated with other applications on a previously selected path. The network100is customizable so that routing among the routers108,110, and116, via the WANs112a-cand the Internet114may be selected based on the particular performance of the paths, and also the performance needs of particular applications and/or services.

Referring again toFIG. 1, and as previously described, to provide the data paths A, B. C and D, the network100provides tunnels, generally, through the WANs112and Internet114. Tunneling may, in various embodiments, provide scalability, quality of service, increased security, and simplicity for configuration and management. The network100, and in particular the edge routers116and hub routers108and110, each provide a single defined tunnel, which are dynamically generated to provide particular access, and closed when unneeded or unused. In the network100, path A is defined by a tunnel. The tunnel may be generated to provide access to the hub102from the customer118, to provide access between customers118and120, or to provide access to the backup hub104from the customer118. In particular, when access is provided via hub102, via a tunnel, the customer118(in this example), and in particular, the edge router116, generates the tunnel to the hub102. After the tunnel is generated, an enhanced interior gateway routing protocol (EIGRP) neighbor is created between the hub102and the customer118, and data is transferred over the generated tunnel.

Conversely, for customer-to-customer access (between customer118to customer120, for example), which is generally only created when needed or on demand, a different process is provided. Initially, the hub102(and in particular, router108b) receives a connection from the router116b, for example, to a destination site associated with router116c(associated with customer120). The hub102then forwards the request to the router116c, and the hub102informs the router116c(e.g., instructs the router116c, etc.) about direct access to the router116b, via the WANs112(or Internet114). Further the hub102creates a next hop resolution protocol (NHRP) entry for the customer's prefix (i.e., prefix for router116b) in its routing tables. The router116cthen forwards the response directly to the customer118, via its interface to WANs112. Router116bthen creates a NHRP entry for the prefix for router116c. The customers118and120are then able to communicate, directly between routers116, over a tunnel therebetween. This connection may, for example, remain open for a predefined interval, such as, for example, 2 minutes, 5 minutes, 10, minutes, etc., after a last packet of data is exchanged between customer118and customer120(and in particular, routers116).

The backup hub104provides redundant access, if issues arise with hub102. Specifically, upon failure of hub102, the hub104establishes the same tunnel with customers118and120, and between the customers as existed at the primary hub102, based on static maps contained in each of the routers108,110and116. For example, when a connection is created between router116aand router108a, a connection is also created to router110a(as indicated in a static map). The traffic to the data center106ais handled between the routers116aand108a, as long as hub102is operational. Upon failure, the router116ainvokes the connection to router110a, indicated in the static map, to further handle the traffic.

In another aspect of the disclosure, IPSec provides the framework used to issue and maintain certificates to the routers108,110and116included in the network100. While the description herein is presented with reference to IPSec, it should be appreciated that other similar protocols may be used, in other embodiments, for secured communication between devices. IPSec provides data encryption at the IP packet layer, which may provide scalable, secure, and standards-based security solutions for tunnel encryption (as described above). The encryption is provided between the hubs102and104, between the hubs102and104and the customers118and120, and between the customers118and120(and/or other customers). In particular, IPSec employs a simple certificate enrollment protocol (SCEP) for handling certificates (e.g., issuing, renewing, revoking, etc.) within the network100, and by the certificate server128. For the hubs102and104, enrollment is accomplished via the data centers106, at the corresponding certificate server128. For routers (e.g., routers116, etc.) remote from the hubs102and104, the enrollment is accomplished via temporary border gateway protocol (BGP) routes installed over one or more of the WANs112. The initial request for certificates, i.e., enrollment, is unencrypted traffic within the network100.

In particular, a router (e.g., one of routers116, etc.) obtains a copy of the certificate and then generates a certificate signing request (CSR), based on, for example, a local key pair and the name of the router. The CSR is sent, by the router (e.g., one of routers116, etc.), to the certificate server128. The router then polls the certificate server128to check whether the certificate had been signed. Once the certificate is signed, it is returned to the router, where the signed certificate is written to memory, such as, non-volatile memory (e.g., non-volatile random access memory (NVRAM), etc.). The certificate is used, by the router116, to service SCEP requests to the services network and/or to permit interactions with the other parts of the network100, such as, for example, to generate and/or access dynamic tunnels.

After the certificate is issued, each router re-enrolls (e.g., via the IPSec tunnel, etc.), as necessary, in order to maintain a certificate and, as a result, access within the network100. In this exemplary embodiment, the certificates are valid for a predetermined period, such as, for example, 1 year, 2 years, 4 years, or other suitable intervals, etc. The router seeks to re-enroll sufficiently in advance of the expiration of the certificate so that the certificate server128issues/signs the new certificate before the expiration of the prior certificate. For example, when a certificate is valid for 2 years, re-enrollment may be initiated by the router between 16 and 20 months, or other interval less than 2 years. To the extent a router is removed from the network100and/or a customer opts not to participate in the network100(e.g., for one or more business reasons, etc.), the certificate for the router is revoked. In this manner, decommissioning a router, or other device, from the network100is more efficient than, for example, distributing new or different keys, for which a change would require touching each of the routers. In the exemplary embodiment, a certificate revocation list is maintained at the certificate server128, and disseminated, as necessary, for maintenance of the network100. Specifically, when a router is decommissioned, or taken down, it is removed from the list of routers (e.g., a static router map, etc.) within the certificate server128. As routers108,110, and116update themselves, at regular or irregular intervals (e.g., every 15 minutes, 20 minutes, 7 days, etc.), the router, which has been decommissioned, is no longer included in the updated router maps. As such, the decommissioned router is unable to communicate within the network100.

In various embodiments, payment networks and methods herein thus may employ one or more forwarding tables and/or one or more filters in a global routing domain to handle data traffic within the payment networks. Consequently, multiple domains may be avoided, thereby providing efficiency and/or simplicity to the payment networks and/or maintenance thereof.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by: (a) determining, by a routing engine, a performance of a first path between a hub associated with a payment network data center and a customer, the first path defined by a first tunnel through a first wide area network (WAN) between the hub and a first edge router associated with the customer, the hub including the router, (b) determining, by the routing engine, a performance of a second path between the hub and the customer, the second path defined by a second tunnel through a second WAN between the hub and a second edge router associated with the customer, (c) causing, by the routing engine, a data traffic to be initially routed along the first path, (d) selecting a first performance threshold for the data traffic based on a class of application associated with the data traffic, (e) switching, by the routing engine, the traffic to the second path, when the first path fails to satisfy and/or violates the first performance threshold and the second path does not fail to satisfy and/or violate the second performance threshold, (f) transmitting probes along the first path and the second path at one or more intervals; (g) switching the first data traffic from the secondary path to the first preferred path when the data traffic is routed along the second path, but the performance of the first path is within the performance threshold; (h) routing the data traffic along a first path when the performance of the first path is within a performance threshold and the data traffic is associated with a first class of application, but routing the data traffic along a second path when a performance of the first and second path is within a performance threshold and the data traffic is associated with a second class of application; and (i) routing data traffic along a path, when the path is within the performance threshold, wherein the performance threshold includes a first value when the data traffic is associated with a first application and a second different value when the data traffic is associated with a different application.