Patent Publication Number: US-2018041419-A1

Title: Virtual Router For Paths Between Autonomous-System Pairs

Description:
FIELD OF THE INVENTION 
     This invention relates to computer networking and, more particularly, to the interconnection of routing domains. 
     BACKGROUND OF THE INVENTION 
     An Autonomous System (AS), also referred to herein as a routing domain, is a collection of one or more interconnected computing networks and/or subnetworks that present a common routing policy to the internet, share one or more Internet Protocol (IP) routing prefixes, and/or are under the control of a common administrator. Although, in some cases, hosts in a first AS may communicate with hosts in a second AS over a direct link, one or more different intermediate networks, often facilitate the passing of such traffic. For example, an AS may gain access to the internet through interconnection via a previously-connected routing domain. 
     Often, a pair of routing domains pass large traffic volumes between one another, making it desirable to ensure a sufficiently robust path exists. Furthermore, in such scenarios, it can be desirable to provide opportunities for multiple different paths between the pair of routing domains. Interconnections can increase capacity, control of traffic, and redundancy, among other advantages. Also, since the Intermediate Networking Infrastructure (INI) between a pair of routing domains is organic and in a continual process of change, paths through the INI are subject to changes over time. Some changes may present problems, while others may present opportunities, making it desirable not only to establish multiple paths, but also to be able to switch between paths flexibly. 
     However, there are many obstacles to switching between, and/or otherwise utilizing such paths flexibly. Although an AS-network-level Gateway Protocol (AGP), like Boarder Gateway Protocol (BGP), may be used to advertise network routes and/or prefixes to route traffic between routing domains, actual configuration of connections between routing domains may involve agreement on monetary and/or other non-technical issues, establishing physical layer connections, and/or manual interaction with a configuration tool on the relevant routers. Establishing a connection between two routing domains is further complicated by the many different methods for establishing a path between two routing domains. These different approaches are associated with different types of advantages, limitations, and metrics for measuring traffic. Such obstacles also complicate the creation of a control mechanism for directing traffic at the inter-routing-domain level. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order that the advantages of the disclosures will be readily understood, a more particular description will be rendered by reference to specific embodiments illustrated in the appended drawings, understanding that these drawings depict only typical examples and are not, therefore, to be considered limiting in scope. These drawings include: 
         FIG. 1  is a schematic block diagram of several different approaches to providing a path over Intermediate Networking Infrastructure (INI) between two routing domains, including: a transit network; a chain of networks; an Internet Exchange Point (IXP); a direct link; and a novel Distributed Internet Exchange Platform (DIXP), in accordance with examples; 
         FIG. 2  is a schematic block diagram of a virtual router used to switch paths between two routing domains over a DIXP, extending peering capabilities from a localized IXP to multiple access points on a geographically large scope, in accordance with examples; 
         FIG. 3  is a schematic block diagram of a virtual router used to switch a path, between two routing domains, over a chain of networks to a new path over a DIXP, in accordance with examples; 
         FIG. 4  is a schematic block diagram of a set of agents distributed across the INI to collect information for a virtual router about potential paths, in accordance with examples; 
         FIG. 5  is a schematic block diagram of a database, determination module, and implementation module associated with a virtual router to: (1) maintain topology information and/or measurements for a wide variety of paths between routing domains; (2) make determinations about paths for traffic flows; and (3) configure nodes in the INI to implement a determination, in accordance with examples; 
         FIG. 6  is a schematic block diagram of another exemplary database and additional functionalities supported thereby, in accordance with examples; 
         FIG. 7  is a schematic block diagram an implementation module operable to engage in one of various forms of machine-to-machine communication, possibly using agents distributed across the INI, to implement routing determinations for a virtual router, in accordance with examples; and 
         FIG. 8  is a flow chart for implementing a virtual router at an inter-routing-domain level, involving collecting on different paths over INI, analyzing the potential impact of a new path, and remotely configuring intermediate notes to implement the new path, in accordance with examples. 
     
    
    
     DETAILED DESCRIPTION 
     It will be understood that components of the invention, as generally described and illustrated herein, can be arranged in a wide variety of different configurations. The following detailed description, which merely represents certain examples, is not intended to limit the scope of the claims. These examples may be understood by reference numbers to the figures. Reference numbers concluding with an additional letter, or letter-number pair, indicate differing instances of a class with the same or similar, but varying, attributes. References by number only refer more generally to the class and/or a representative instance. 
     Referring to  FIG. 1 , Intermediate Networking Infrastructure (INI), also referred to herein as networking structure,  10   a  is depicted between a first Autonomous System (AS), or routing domain,  12   a  and a second AS/routing domain  12   b . Gateway routers  14   a ,  14   b  respectively pertaining to the first AS  12   a  and the second AS  12   b  may provide access to the INI  10   a . Such gateway routers  14   a ,  14   b  may implement an AS-network-level Gateway Protocol (AGP), like, without limitation, Boarder Gateway Protocol (BGP) to advertise routing and/or prefix information for traffic from and/or to other routing domains  12 . 
     The first AS  12   a  comprises multiple networks  16   a ,  16   b  interconnected by routers  18   a ,  18   b  for a common enterprise. Conversely, the second AS  12   b  covers a single network  16   c . Both, however, are consistent with the definition of an AS. 
     The first AS  12   a , may require analysis of large data volumes it generates, but may lack the necessary infrastructure. Although lacking a direct link to the first AS  12   a , the second AS  12   b , which may be a datacenter  16   c , may offer data-analysis services. However, traffic flows between the routing domains  12   a ,  12   b  entailed by the services may create common issues that merit the creation of a path, or connection, attuned for certain metrics including, without limitation: bandwidth; security; and/or any number of considerations. Also, several different approaches to paths/connections between routing domains  12   a ,  12   b , with different relevant metrics, may be possible. 
     Some of the differences between approaches may arise from differences between transit and peering relationships. With respect to transit relationships, for example, each of the routing domains  12   a , AS  12   b  may be a tier 3 domain or a tier 2 domain. A Tier 3 domain may be, without limitation, an enterprise-level network, one or more specialized networks, and/or a small, regional ISP. To gain internet access, a tier 3 domain often needs to pay a fee, known as settlement, to another domain, known as a transit network/domain  20 , which may be a tier 1, 2, or 3 domain that already has access to the internet. 
     With respect to peering relationships, a tier 2 network/domain often pays settlement to another transit network/domain  20  to reach certain internet domains. However, a tier 2 network/domain is also often able to agree with other routing domain/networks  12  to mutually carry traffic for one another without cost, or significant cost, in a peering relationship. Often, in peering relationships, participating routing domains  12  may have access to one another, but not to routing domains with a second degree of separation from the participating routing domains  12 . Additionally, each participating routing domain  12  retains its own revenue. According to a common standard, tier 1 domains can access most any other network/domain on the internet without paying settlement. 
     In addition to settlement costs, or lack thereof, transit and/or peering relationships may impose different requirements, in the form of routing policies, which may have implications for deciding between traffic paths. In the context of considerations surrounding transit and peering relationships, a discussion may commence as to various, non-limiting approaches, depicted in  FIG. 1 , to establishing paths/connections between routing domains  12   a ,  12   b.    
     For example, according to a first approach, the first AS  12   a  may, as a third tier domain, pay settlement to a second-tier transit network/domain  20   a . However, consistent with the second-tier status, the transit network/domain  20   a  may not have direct access to the second AS  12   b . However, the transit network/domain  20   a  may have access, such as through a transit or peering relationship, to another intermediate network/domain  22   a , which may pertain to a chain of any number of intermediate network/domains  22   a - 22   n . The final intermediate network/domain  22   n  in the chain  22   a - 22   n  may provide access to the second AS  12   b , thereby making possible a first path  24   a , indicated by the circled number  1  in the figure, between the routing domains  12   a ,  12   b.    
     In such examples, the path, or route,  24   a  of the traffic is subject to the control of not only the first transit network/domain  20   a , but also the chain of intermediate network(s)/domain(s)  22   a - 22   n , outside the control of a common entity. Consequently, for such paths  24 , costs, services, and/or performance metrics are subject greater variability, creating barriers to guarantees for Quality of Service (QoS) for sensitive traffic. 
     These limitations may be addressed with a second approach in which the first AS  12   a  enters a transit relationship with a second exemplary transit network/domain  20   b  with direct access to the second AS  12   b . The second exemplary transit network/domain  20   b  may be, for example, a first tier domain able to access most networks without paying settlement. 
     In such scenarios, the transit network/domain  20   b  may handle traffic internally along a second path  24   b , indicated by the circled number  2 . The transit network/domain  20   b  may control traffic directed between its gateway routers  14   c ,  14   d  with internal switches, routers, and or the like that may be connected to one another and/or a network controller. Consequently, the transit network/domain  20   b  may offer certain guaranties with respect to QoS and/or the like. However, the first AS  12   a  and/or second AS  12   b  may pay a premium in settlement and/or be subject to burdensome routing policies, which may or may not be justified, depending on the nature of the traffic and/or alternative options. 
     A third approach for a third path  24   c , indicated by the circled number  3 , may make use of an Internet eXchange Point (IXP)  24   a . An IXP  24   a  may provide a switch, or system of switches,  28   a  to which routing domains  12   a ,  12   b  participating in the IXP  20  may connect. Furthermore, the IXP  26   a  may operate a layer-2 configuration and/or may utilize an Internet Protocol (IP) subnet for the connection of participating ASs  12 . Two participating routing domains  12   a ,  12   b  may utilize their connections, therefore, to engage in a peering session, as opposed to paying settlement. Examples of such an IXP  26  may include a data center or collocation center, where the costs may be shared by participants. However, IXPs  26  are limited in the peering they can facilitate by their physical location. 
     As an example of a fourth approach, which may overcome geographic limitations and/or tailor a path  24   d  to the needs of routing domains  12   a ,  12   b , a private communication link  30   a  may be installed, creating a fourth path  24   d  indicated by the circled number  4 , the two routing domains  12   a ,  12   b . The private communication link  30   a  may be, without limitation, copper and/or fiber-optic cabling, microwave channels, and/or satellite links. Even more so than with the transit approaches, this fourth approach can be expensive, especially where long distances and/or large bandwidths are involved, and only provides a path  24   d  between two routing domains  12   a ,  12   b.    
     As can be appreciated, these different approaches do not share common metrics, and each has its tradeoffs. A fifth approach, which may provide a fifth path  24   e  indicated by the circled number  5 , may provide further options, which may combine many advantages, with few disadvantages, of previous approaches. This new approach is described in further detail with the following figure and is referred to herein as an Internet Exchange Grid (IEG), a grid of IXPs, or a Distributed Internet Exchange Platform (DIXP),  32   a.    
     Referring to  FIG. 2 , an IEG/DIXP  32   b  is depicted, highlighting its advantages in implementing peering relationships irrespective of the geographic location of the participating routing domains  12   c - 12   h . As depicted, peering relationships may be entered into even where routing domains  12   c - 12   h  are remotely located on different continents  34   a ,  34   b.    
     An IEG/DIXP  32   b , within the INI  10   b , may interconnect a set of multiple IXPs  26   b ,  26   c  at different geographic locations. As used herein, a ‘set’ may include any number of elements including one element and no elements. The IEG/DIXP  32   b  may include a number of routers, switches, cloud infrastructure, and/or the like providing nodes in a mesh, or other topology, operable to carry traffic between routing domains  12   c - 12   h , such as an AS  12   c  in San Francisco and an AS  12   f  in Paris. The first routing domain  12   c  and the second routing domain  12   f  may respectively connect, or be communicatively coupled, to a first IXP  26   b  at a first geographic region, or physical location, and a second IXP  26   c  at a second geographic region, or physical location, geographically remote from the first region/location. The first and second IXPs  26   b ,  26   c  may, in turn, be connected by the IEG/DIXP  32   b , which may provide physical packet-switching infrastructure  26  between the first IXP  26   b  and the second IXP  26   c.    
     As depicted, different traffic paths  24   f ,  24   g  are possible between the two IXPs  26   b ,  26   c  to which the two remotely located routing domains  12   c ,  12   f  are connected. Although two paths  24   f ,  24   g  are depicted, any number of different paths  24  are possible. The variety of routes  24  is further highlighted by the inset depiction of an enlarged portion of the IEG/DIXP  32   b , for which multiple instances of switching fabric  28   b - 28   e  are depicted with a wide range of bidirectional links  36   a - 36   f  between instances  28   b - 28   e  highlighting the possibilities for paths  24 . 
     In addition to the physical connections for traffic in the data plane, connections between routing domains  12   c - 12   h  rely on routing information, authentication to insure reliability of the routing information, and or the like, as may be provided in the control plane. To meet such needs, a set of Gate Keepers GK, which may include a Global Gate Keeper (GGK)  40 , may be included for execution on a set of processors in the IEG/DIXP  32   b . The GGK  40  may be operable to authenticate the first AS  12   c  to make connections across the IEG/DIXP  32   b  with a set of authenticated ASs  12   d - 12   h . Hence, a GGK  40  may authenticate the first AS  12   c  and the second AS  12   f  to pass traffic over the physical packet-switching infrastructure  32   b  along a new path  24   g  according to a peering relationship. Also, to facilitate such paths  24   g ,  24   f , the GGK  40  may run an inter-autonomous-system-routing protocol, such as, by way of example and not limitation, a Border Gateway Protocol (BGP) to import and/or export/advertise network prefixes and/or routing information to and/or for routing domains  12   c - 12   h.    
     One or more routers  14  pertaining to multiple routing domains  12   c - 12   h  connecting to the IEG/DIXP  32   b , regardless of their geographic location, may connect, or establish a session with, a GGK  40 . By way of example, and not limitation, an AS  12   c  may connect with a GGK  40  by establishing a BGP session with the GGK  40 . Once authenticated, the geographically-dispersed routing domains  12   c - 12   h  may also advertise net prefixes and/or routing information by one or more GGKs  40 . Other geographically-dispersed routing domains  12   c - 12   h  may receive and/or trust network prefixes and/or routing information advertised by geographically-dispersed routing domains  12   c - 12   h  connected to and/or authenticated by a corresponding GGK  40 . In some examples, the set of Gate Keepers (GK) than may include one or more Local Gate Keepers that may provide similar functionality for localized subsets of the IEG/DIXP  32   b.    
     Hence, a GGK  40  may allow for multilateral peering sessions between multiple routing domains  12   c - 12   h , requiring minimal configuration at corresponding routers. The routing domains  12   c - 12   h  connected to and/or authenticated by a corresponding GGK  40  may, therefore, form a Virtual Local Area Network (VLAN) providing packet-switching infrastructure to communicate traffic between the set of IXPs  26   b ,  26   c  for a set of ASs  12   c - 12   h  authenticated by the GGK  40 , enabling a peering relationship between the set of authenticated ASs  12   c - 12   h . Further explanation of IEG/DIXP technology may be found in U.S. Pat. No. 9,246,766, entitled “Method and Apparatus for a Distributed Internet Architecture,” which is incorporated herein by reference. 
     Advantageously, the IEG/DIXP  32   b  may lower peering barriers and/or provide alternative paths  24  for remote routing domains  12   c - 12   h . The control plane, not only of the IEG/DIXP  32   a / 32   b , but of additional Intermediate Network Infrastructure (INI)  10   b , may also be used to collect data on different potential paths  24  between routing domains  12   c - 12   h . With such information, responsive decisions may be made to better utilize the INI  10   b . To facilitate such determinations, appropriate data sets, informed by the nature of the various approaches to connecting routing domains  12 , particularly in light of the peering relationships enabled by DIXP technologies  32 , may be provided. 
     As can be appreciated from the discussion of the first two figures, different types of paths  24  may be utilized between routing domains  12 . Which of these paths  24  best meets the needs of a pair of routing domains  12  may vary over time. To respond to information about changes, a virtual router  42   a  may be implemented at the networking layer, or layer 3. For example, information may indicate a new path  24   g , or improved performance along a second path  24   g  relative to a first path  24   f  for a flow of packets  44   a  from the first AS  12   c  to the second AS  12   f . In response, the virtual router  42   a  may stop the flow  44   a  along the first path  24   f  and may route the flow  44   a  along the second path  24   g . However, for a variety of considerations, such as the different nature of potential paths  24 , implementation of such a virtual router  42   a  presents difficulties. 
     The following discussion provides a brief, non-limiting overview of implementation examples for virtual routers  42 . Either within the virtual router  42  or otherwise communicatively coupled to the virtual router  42 , a database may be maintained on a storage medium. The database may include path information/data for Intermediate Networking Infrastructure (INI)  10  between a first AS  12  and a second AS  12 . Additionally, the virtual router  42 , which may be executable from memory by one or more processors, may be communicatively coupled to the INI  10 . 
     The virtual router  42  may include a receive module and an implementation module. The receive module may be operable to receive instances of path information. The received information may be collected by a set of agents operable to collect path data at a set of networking nodes in networking structure  10  between multiple routing domains  12 , including the first AS  12  and the second AS  12 . A path module may be included in some examples, which may be operable to correlate the current path information in the database to topology information about the INI  10 . 
     The implementation module may be operable, responsive to current path information, to reconfigure one or more network nodes in the INI  10  to change traffic from a first path  24  between the first AS  12  and the second AS  12  over the INI  10  to a second path  24  between the first and second ASs  12 . Even though the virtual router  42  may be physically implemented remotely, for example and without limitation on cloud infrastructure, from the one or more network nodes, it may still remotely reconfigure one or more network nodes. In some examples, the virtual router  42  may include a determination module operable to process path information in the database, applying one or more algorithms to make a determination, indicated to the implementation module, to change the path. 
     The INI  10  may include an IEG/DIXP  32 . In such examples, the current path information in the database may include node information with which to direct the traffic along the first path  24 , which traverses the INI  10  outside of the IEG/DIXP  32 , and the second path  24 , which traverses the INI  10  within the IEG/DIXP  32 . Also, the implementation module may be operable to redirect, with the node information, the traffic from the first path  24  to the second path  24 , in response to the current path information. 
     Similarly, the current path information in the database may include node information for the INI  10  with which to direct traffic between the first AS and the second AS along the first path  24 , having a first set of traffic-handling implications, and the second path  24 , having a second set of traffic-handling implications. In such examples, the determination module, trigger module, and/or an analysis module may be operable to determine to change the traffic between the first AS  12  and the second AS  12  along the first path  24  to the second path  24 . The implementation module may be operable to utilize the node information to change the traffic between the first AS  12  to the second AS  12  along the first path  24  to the second path  24 , in response to the current path information. Furthermore, additional aspects and additional details for a virtual router  42  are set forth in greater detail below, with the help of the following drawings. 
     Referring to  FIG. 3 , a virtual router  42   b  is depicted. The virtual router  42   b  is depicted blocking a flow of packets  44   b  over a transit network/domain  20   c  and a chain of intermediate routing domains  22   a - 2 - 22   n - 2  between a first AS  12   i  and a second AS  12   j . However, the virtual router  40   b  may be operable to provide such routing services for any number of pairs of routing domains  12 , including large numbers of routing domains  12 , that may register, or subscribe, for such services. The virtual router  42   b  may include a database  46   a  and/or an implementation module  48   a.    
     Much of the structure and functionalities disclosed herein, may be provided by modules. Modules may be embodied in hardware, software, or an interfaced combination of both, with, without limitation, firmware, resident software, micro-code, and/or the like. Aspects of the disclosure may take the form of a computer program product embodied in any tangible, computer-readable medium for use by an instruction execution system, apparatus, or device, such as a micro-processor, Central Processing Unit (CPU), and/or the like. Without limitation, a computer-readable medium may include a portable computer diskette, a hard disk, a Random Access Memory (RAM) device, a Read-Only Memory (ROM) device, an Erasable Programmable Read-Only Memory (EPROM or Flash memory) device, a portable Compact Disc Read-Only Memory (CDROM), an optical storage device, and/or a magnetic storage device. Computer program code may be written in any combination of programming languages, including object-oriented languages, such as C++, and/or conventional procedural languages, such as the “C.” 
     The virtual router  42   b  may also redirect the flow  44   b  to a second path  24   i  along an IEG/DIXP  32   c  within the INI  10   c , enabling a peering relationship between the first and second ASs  12   i ,  12   j . In the figure, the virtual router  42   b  may act in response to path information from the database  46   a  to redirect the flow of packets  44   b . One example of path information may include second path data correlated to the alternative path  24   i  including an indication that the second AS  12   j  has connected to a second IXP  26   e  of the IEG/DIXP  32   c  and has been authenticated by the set of GKs  40  for access to the switching infrastructure  28 , enabling the peering relationship over the alternative path  24   i.    
     As appreciated, metrics for the two paths  24   h ,  24   i  may differ. A first set of metrics for the first path  24   h  may include metrics for monetary cost for the traffic traversing a transit network  20   c  along the first path  24   h , within the INT  10   c , between the routing domains  12   i ,  12   j  and/or a set of conditions for the transit network  20   c . Owing to a chain of intermediate routing domains  22   a - 2 - 22   n - 2  outside the control of the transit network/domain  20   c , a unique set of performance metrics for the first path  24   h  may be utilized. For example, values for performance metrics may be collected indirectly, such as by way of measuring lag time, drop rates, and/or the like for data communicated between the routing domains  12   h ,  12   i . However, the divided control of the networks  20   c ,  22   a - 2 - 22   n - 2  mitigates against any QoS metrics. 
     Conversely, with respect to the second path  24   i , the IEG/DIXP  32   c  may be under common administration, allowing for QoS guarantees. The IEG/DIXP  32   c  is connected to a first and second IXP  26   d , IXP  26   e , which in turn are connected respectively to the first and second AS  12   i ,  12   j . Unlike the hardware of the transit network/domain  20   c  and intermediate routing domains  22   a - 2 - 22   n - 2 , hardware of the IEG/DIXP  32   c  may be commonly administered and give access to the virtual router  42   b . A set of metrics for the second path  24   i  may, therefore, include indicators for hardware health. 
     Despite differences between the first and second sets of metrics relevant to the two paths  24   h ,  24   i , the virtual router  42   b  may employ algorithms to analyze values from the current path information pertaining to both the first and second sets of metrics for the first and second paths  24   h ,  24   i  respectively. Furthermore, despite these qualitative differences, the virtual router  42   b  may determine to change the traffic between the first and second ASs  12   i ,  12   j  from the first path  24   h  to the second path  24   i.    
     The virtual router  42   b  may access current path  24   h  information that includes node information to direct the traffic along the first path  24   i , traversing the INI  10   c  outside the IEG/DIXP  32   c . Such node information may include, without limitation, an IP address for a gateway router  14   e  of the first AS  12   i  and/or for the gateway router  14   g  of the transit network/domain  20   c . To direct traffic from the first path  24   h , the virtual node  42   b  may insure that a routing table of the gateway node  14   e  of the first AS  12   i  indicates that traffic with a destination IP address within the second AS  12   j  is routed to the gateway router  14   g  of the transit network/domain  20   c.    
     Also, the virtual router  42   b  may have access to path information for the second path  24   i  that may also include node information for the second path  24   i . Such node information may include, without limitation, an IP address for a gateway router  14   e  of the first AS  12   i  and/or an for the IXP  26   d  connected to the IEG/DIXP  32   c . In response to an indication in the current path information to redirect the flow of packets  44   b  to the second path  24   i , the implementation module  48   a , with this node information, may change a routing table of the gateway node  14   e  of the first AS  12   i  to indicate that traffic with a destination IP address within the second AS  12   j  be routed to an IP address of the IXP  26   d . Hence, the implementation module  48   a  may change a connection for traffic between the first and second AS  12   i ,  12   j  following the current path  24   h  to the alternative path  24   i . However, the actions taken by the virtual router  42   b  to change to the alternative path  24   i  are taken in response to recent updates to the current path information. Therefore, a question arises as to the origin of such updates. 
     Referring to  FIG. 4 , a set of agents  50   a - 50   n  is depicted, implemented at a set of network nodes throughout the INI  10   d , and communicatively coupled to the virtual router  42   c . Individual agents  50   a - 50   n  in the set may be operable to collect instances of path information from the set of network nodes in the INI  10   d  and send collected path information to the virtual router  42   c.    
     Although agents  50   a - 50   n  are distributed throughout the INI  10   d , agents  50  may not be located within routing domains  20   d ,  22   a - 3 - 22   n - 3  outside the administrative scope of the virtual router  42   c  and/or routing domains  12   k ,  12 L subscribing to services of the virtual router  42   c . The transit network/domain  20   d  and the chain of intermediate routing domains  22   a - 3 - 22   n - 3  may be separately administered, preventing placement of agents  50  therein. Conversely, the same entity administering the virtual router  42   c  may have access to a stand-alone IXP  26   f  at which agents  50   a  may be located. 
     Because the entity administering the virtual router  42   c  may also administer an IEG/DIXP  32   d , agents  50   c  may be located at instances of switching infrastructure  28   f  therein. Agents  50   d - 50   g  may be located with one or more IXPs  26   g - 26   j  connected to the IEG/DIXP  32   d . Additionally, when an administrator  52  of a routing domain  12   k  subscribes to services of the virtual router  42   c , it may also provide routing information for and access to a gateway router  14   h , allowing for placement of an agent  50   b  with the gateway router  14   h.    
     The administrator  52  may sign-up, register, and/or otherwise subscribe a routing domain  12   k  using a console and/or other computing device  54  to access a webpage, or website,  56  associated with the virtual router  42   c . The webpage/website  56  may be maintained by a registration module  58 , incorporated with the virtual router  42   c  and/or otherwise associated therewith. The registration module  58 , which may be accessible over the internet and hosted on one or more servers, may solicit input which the virtual router  42   c  may utilize to route traffic to and/or from the routing domain  12   k  being registered. 
     Non-limiting examples of such information may include: an Autonomous System Number (ASN)  60 ; routing addresses, prefixes, protocols, and/or other routing information  62 ; and/or conditions  64  for peering, transit, and/or other relationships with other domains  12 . The registration module  58  may then record, store, and/or maintain this information in the database  46   b  of the virtual router  42   c  and/or another database accessible by the virtual router  42   c . Additionally, teachings about the collection of information during registration are disclosed by  FIG. 3  and accompanying discussion of U.S. patent application Ser. No. 14/713,783, entitled “AUTOMATED NETWORK PEERING IN A SOCIAL-NETWORK MODEL,” and incorporated herein by reference. 
     Owing to the different nature of the various approaches to creating paths  24  between routing domains  12   k ,  12 L, agents  50   a - 50   n  may collect measurements and/or information for many qualitatively distinct metrics, including information about changes in the topology of the INI  10   d . Therefore, agents  50  may be designed for general utility to collect measurements across a wide range of metrics. Additionally, or in the alternative, agents  50  may be tailored to collect information for metrics relevant to a given type of path  24 . 
     Consequently, in collecting measurements, the agents  50   a - 50   n  may collect measurements for a first set of metrics tailored to a first method for creating a connection between the first AS  12   k  and the second AS  12 L over an existing path  24 . Similarly, the agents  50   a - 50   n  may collect measurements for a second set of metrics tailored to a second method for a new path  24 . As discussed above, the first set of metrics may differ from the second in as much as the first method for the first path  24  may differ from the second method. With reference to the first figure, but without limitation, the first and/or second methods may use: a transit network  20 ; a first transit network  20  and an additional network  22 ; a localized IXP  26 ; a direct connection  30 ; and a grid of IXPs  32 . 
     Agents  50   a - 50   n  may then provide measurements to the virtual router  42   c  over a control plane  66  via a control plane module  54 . As can be appreciated, the control plan  66  may include multiple control planes for different networks that may be integrated and/or generalized in a unified control plane  66  to relay measurements/information to the virtual router  42   c . A receive module  68  of the virtual router  42   c  may be operable to communicate with the control plane  66  and combine new instances of path information/data, from agents  50   a - 50   n , with path information/data in a database  46   b , updating the database  46   b  to provide current path information/data. Just as traditional routers  14   h ,  14 L use a dynamic routing protocol to exchange information about destination addresses, routing tables  72 , and/or topology  74 , the agents  50   a - 50   n  may provide path information/data with measurements and/or topology information to a virtual router  42   c  about the INI  10   d  and potential paths  24 . Further explanation of information collection from the INI  10   d  is found in U.S. patent application Ser. No. 14/985,120, entitled “DATA MONITORING/AGGREGATION FOR EVALUATING CONNECTIONS BETWEEN NETWORKS,” which is incorporated herein by reference. 
     Referring to  FIG. 5 , an exemplary database  46   c  upon which a virtual router  42  may rely for path information/data, is depicted, illustrating the wide range of metrics/information that a determination module  76   a  may take into account. The database  46   c  may reside on a physical storage medium, including, without limitation, one or more RAM device(s), solid state memory devices, and/or hard drives. Such information may include topology information  78   a  about INI  10  and/or measurements for many different metrics. Topology information  78   a  may include, without limitation, information about nodes in the INI  10  and/or links between nodes, and/or available bandwidth. 
     Additionally, topology information  78   a  may include information about a path  24  over INI  10  for which the virtual router  42  may not have topology information and/or access to networking nodes therein. Examples of such routing domains may include a transit network/domain  20  and/or a chain of intermediate network/domains  22   a - 22   n . Information about paths  24  over such infrastructure may include a list of routing domains  12  accessible thereby and/or qualitative information about path types. 
     Furthermore, path information about new connections between nodes and/or routing domains  12  within and/or connected to the INI  10  may update topology information  78   a . Consequently, when a second AS  12  establishes a connection with an IEG/DIXP  32  connected to the first AS  12 , an agent  50  at the IEG/DIXP  32  may collect this information. The receive module  68  may then enter it into the database  46   c  to update topology information  78   a.    
     Measurements in the database  46   c  may pertain to a variety of metrics that may differ, as discussed, based on the type of path  24  for which they are gathered. For example, measurements  80  for a set of metrics for the fifth type of paths  24  through an IEG/DIXP  32 , characterized by peering relationships of unlimited geographic scope, may include, without limitation, a number of hops, bandwidth, lag time, QoS guarantees, jitter, packet loss, and/or the like. Additional, non-limiting examples may include measurements for metrics about hardware health, such as hardware status, available routing memory, power-supply status, fan status, CPU temperature, hardware temperature, ambient temperature, and/or the like. Additionally, measurements  80  for the metrics may be maintained for nodes and/or other elements of the IEG/DIXP  32  not yet incorporated in a path  24 , for exploring potential alternative paths  24 . 
     Measurements  82  for a set of metrics for a fourth type of paths  24  through a private communication link  30  may include metrics about bandwidth, reliability, and/or maintenance costs. Additionally, metrics for a potential path over a private communication link  30  may include costs to establish the link  30 . 
     Measurements  84  for a set of metrics for a third type of paths  24  over a standalone IXP  26  may include metrics for bandwidth, lag time, QoS, packet loss, jitter, and/or the like. Such metrics may also include metrics relevant to hardware health for the IXP  26 , such as those discussed above and/or metrics for “global health,” such as, ambient temperature at the IXP  26 , as indicated by the thermometer icon. 
     Measurements  86  for a second type of paths  24  over a transit domain/network  20  may include metrics about settlement costs  88 , as indicated by the dollar icon. Another non-limiting examples include QoS guaranties, transit-agreement provisions, and/or the like  64   b . Since the transit domain/network  20  may not be under common administration with the virtual router  42 , an AS  12  with a path/connection  24  over the transit domain/network  20  may provide such information upon registering with the virtual router  42  for inter-AS routing, possibly via a web, or mobile, application  56  associated with the virtual router  42 . This may also be the case for other measurements of other sets of metrics for other path types. 
     Measurements  90  for a set of metrics for a first type of paths  24  over a chain of intermediate network/domains  22   a - 22   n  may include metrics collected indirectly, such as by way of routing domains  12  connected over the chain  22   a - 22   n  measuring data communicated between each other, as indicated by the icon with the circling arrows. In such examples, agents  50  at gateway routers  14  for the routing domains  12  may collect measurements by, without limitation, ping and/or traceroute methods. Consequently, the database  46   c  may be operable to maintain data for different metrics specific to different path types having a potential to facilitate traffic passing between domains  12 . 
     The determination  76   a  module may be operable to access topology information  78   a , path information, measurements  80 - 90 , and or the like from the database  46   c  to determine paths  24  for one or more pairs of routing domains  12 . For example, the determination module  76   a  may process the information for the current path  24 , which may include information about a set of links in the INI  10  and/or a set of measurements  80 - 90  for metrics relevant to the current paths  24  across the INI  10  between the routing domains  12 . Additionally, the determination module  76   a  may indicate, based on a result of processing the current path information, to the implementation module  48   b  to reconfigure one or more network nodes in the INI  10  to change the traffic from a first path  24  to a second path  24 . 
     The determination  76   a  module may indicate routing changes automatically based on rules programmed, and/or pre-programmed, into the virtual router  42 . Alternatively, or additionally, a network administrator may manually indicate routing changes. The determination module  76   a  may indicate routing changes based on, without limitation, information in the database  46   c  about cost  88 , performance, guaranteed latency minimums and/or other information to dynamically select paths  24  to meet needs of each routing domain  12 . In some examples, the determination module  76   a  may split traffic for a pair of routing domains  12  between multiple paths  24 . For example and without limitation, the determination module  76   a  may indicate routing changes, providing lowered cost and improved traffic speed to a routing domain  12 , which uses a transit domain  20  for internet access, to send some traffic through direct peering over an IEG/DIXP  32 , while allowing the remaining traffic to traverse the transit domain  20 . 
     In some examples, a correlation module  92  and/or a path module  94  may be included, which may be operable to correlate path data, received from the agents  50 , to a set of paths  24  traversing the networking structure  10 . Similarly, in certain examples, a trigger module  96  may be included, which may be operable to compare first path data correlated to a current path  24  to second path data correlated to an alternative path  24 , the current path  24  and the alternative path  24  traversing the networking structure  10  between a first AS  12  and a second AS  12  among multiple ASs  12  for which the virtual router  42  provides inter-AS-routing services. The trigger module  96  may determine that a comparison result merits, or triggers, a change to the alternative path  24 . 
     An analysis module  98  may provide alternative approaches to analyze the potential impact of a path change and identify an improvement for the new path  24 , which may traverse the INI  10  via a second method, or path type. Additionally, a prediction module  100   a  and/or one or more other modules  102  may also be included to assist in the determination process. Once the determination is made, an implementation module  48   b  may change a connection  24  for traffic between the first AS  12  and the second AS  12  following the current path  24  to the alternative path  24 . 
     Referring to  FIG. 6 , another exemplary determination module  76   b  is depicted, to explain additional functionality that a determination module  76   b  may provide. For example, a path module  94  (depicted previously) of the determination module  76   b  may plot out different potential paths  104   a - 104   n , indicated by the doted lines, between a pair of routing domains  12   m ,  12   n . A prediction module  100   b  may then utilize historical measurements  106  to predict values for relevant metrics for one or more of the alternative paths  24  at one or more points, or ranges, of time  108  in the future, before the alternative path(s)  24  are established. 
     Additionally, the prediction module  100   b  may analyze historical measurements  106  to identify and/or predict attributes for a likely Denial of Service (DOS) attack  110 . The prediction module  100   b  may also be operable to identify a flow of packets  44  as being part of a DoS attack  110 . An implementation module  48   c  of the virtual router  42  may then engage to drop, reroute, and/or otherwise prevent packets so identified from being routed by the virtual router  42  to mitigate impact of the DoS attack  110 . Additionally, the implementation module  48   c  may effect changes in the IEG/DIXP  32   f  to establish paths  24   j ,  24   l  therein. 
     As a non-limiting example of the one or more other modules  102  previously depicted, an option module  112  may be included. The option module  112  may be operable to provide notification that a given AS  12   o  has established a first connection or an additional connection to the INI  10   e . For example, a third AS  12   o  may maintain a connection to the INI  10   e , which may allow a first AS  12   m  to establish a relationship with the third AS  12   o , over a transit network/domain  20   e  in the INI  10   e . The third AS  12   o  may then, at a later time, establish a connection, or link,  24  with a stand-alone IXP  26   k  and/or an IXP  26   n  pertaining to an IGP/DIXP  32   e . The option module  112  may then notify the first AS  12   m  of one or more of these new connections  24 . 
     Not only may the option module  112  notify routing domains  12   m ,  12   n  of the connection of additional routing domains  12   o  to the INI  10   e , but the option module  112  may facilitate the recruitment of routing domains  12  and/or the creation of additional links, or connections, to the INT  10   e . For example, the option module  112  may provide a web, or mobile, application/portal/platform  114  associated with the virtual router  42 , hosted by one or more servers and/or accessible over the internet and/or by a mobile device. The web, or mobile, application  114  may be incorporated with, and/or independent from, the website/webpage  56  discussed above for registering an AS  12 . 
     The web, or mobile, application  114  may provide profiles of routing domains  12   o  to assist another AS  12   m ,  12   n  to make determinations about entering into traffic passing relationships, such as peering relationships, with an AS  12   o  based on the profile information. In some embodiments, the web, or mobile, application  114  may support a social-networking environment  116  to facilitate such connections, together with additional automation and/or other architecture disclosed by  FIGS. 4 through 6  and accompanying discussion of U.S. patent application Ser. No. 14/713,783, entitled “AUTOMATED NETWORK PEERING IN A SOCIAL-NETWORK MODEL,” and incorporated herein by reference. Provided with notifications about of novel routes that become available for particular destinations, the virtual router  42  may respond. For example, the virtual router  42  may switch to using a new route  24 L that becomes available if it is determined that it is more desirable than the current route  24   k.    
     The implementation module  48   c  may carry out this determination. As a non-limiting example, the implementation module  48   c  may be operable to configure gateway routers  14 L,  14   m  participating in a path/connection  24 L over the INT  10   e , to include a common label  118  in packets, and/or packet headers  120 , pertaining to traffic  44  between the first AS  12   m  and another AS  12   o . The common label  118  may be readable by a set of network nodes along a second, or new path  24 L in the INI  10   e  to steer the packets along the path  24 L. In some examples, the implementation module  48   c  may communicate instructions to network nodes for handling packets with various labels  118 . Additional examples and/or details potential operations of an implementation module  48  are discussed with respect to the following figure. 
     Referring to  FIG. 7 , an implementation module  48   d  is depicted within a virtual router  42   d . The implementation module  48   d  may be operable to communicate  122  with one or more of the agents  50   aa - 50   an  distributed at different locations, such as at networking nodes, across the INI  10   f . Together, the implementation module  48   d  and the agents  50   aa - 50   an  may constitute a control system. In some examples, one or more agents  50   aa - 50   an  may constitute may constitute existing infrastructure at corresponding network nodes. The implementation module  48   d  may reconfigure at least one network node to implement a change determined by the virtual router  42   d.    
     The control system may enable machine-to-machine interaction between the virtual router  42   d  and at least one networking node of the networking structure  10   f.  In some examples, agents  50   aa - 50   an  may coincide with the agents  50   a - 50   n  discussed with respect to  FIG. 4 , may be a subset thereof, or visa versa. The control system may be operable to reconfigure one or more networking nodes in accordance with a protocol consistent with Simple Object Access Protocol (SOAP)  124 . 
     Alternatively, or additionally, the control system may be operable to reconfigure networking nodes in accordance with a protocol consistent with REpresentational State Transfer (REST)  126 . In some examples, such protocols  124 ,  126  may change  128  a destination address in one or more routing tables  72   c  for routers  14   p  and/or switches in the INI  10   f . In certain examples, the implementation module  48   d  may rely on a Software Defined Networking (SDN) technology, such as, without limitation, OpenFlow  130 . 
     Referring to  FIG. 8 , a method  200  is illustrated with a flow chart for implementing a virtual router  42  at an inter-routing-domain level. The flowchart illustrates the architecture, functionality, and/or operation of possible implementations of systems, methods, and computer program products according to examples. A block, or combination of blocks, in the flowchart may represent a module, special-purpose, hardware-based system, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in alternative implementations, the functions noted in the blocks may occur out of the order noted. In certain examples, two blocks shown in succession may, in fact, be executed substantially concurrently. Additionally, certain steps or functions may be omitted. 
     The method  200  may begin  202  by collecting  204  data for different paths  24  between a pair of ASs  12  over networking structure  10  between the pair of ASs  12 . A determination  206  may be made as to whether there has been a change in the configuration of the networking structure  10  and/or one or more values for metrics relevant to the paths  24 . If the answer is no, the method  200  may return to collecting  204  data. If the answer is yes, the method  200  may analyze  208  a potential impact for changing from an existing path  24  for a connection between the pair of ASs  12  to a new path  24 . 
     A second determination  210  may then ask whether the configuration change(s) and/or a value change(s) present an opportunity to optimize and/or improve a connection between the pair of ASs  12  by changing the path  24 . If the answer is no, the method  200  may also return to collecting  204  data. If, however, the answer is yes and the potential impact indicates an improvement, the method  200  may configure  212  one or more network nodes in the networking structure  10  to implement the connection along the new path  24 . 
     A third determination  214  may then be made as to whether a path  24  continues between the pair of ASs  12 . If the answer is yes, the method  200  may start again by returning to collecting  204  data. If the answer is no, the method may end  216  for the pair of ASs  12 . 
     The present disclosures may be embodied in other forms without departing from their spirit or essential characteristics. The described examples are to be considered as illustrative, not restrictive. The scope of the invention is, therefore, indicated by the appended claims, not the foregoing description. All changes within the meaning and range of equivalency of the claims are embraced within their scope.