Dynamic routing on networks

FIELD OF THE INVENTION

0001This invention relates generally to telecommunications networks. More particularly, the invention concerns systems and methods for dynamically routing packets on a network.

BACKGROUND OF THE INVENTION

0002Dynamic Routing is used on the Internet backbone (core and edge) routers. With the coming of Virtual Private Networks and overlay secure networks using VPN, semantics of dynamic routing shall be affected. Current methods for dynamic routing will lead to various issues and difficulties as virtual private networks become more common. Issues related to running dynamic routing on virtual private networks need to be addressed. The document <patcit id="pcit0001" dnum="US5602839A"><text>US 5602839</text></patcit> discloses an adaptive and dynamic routing scheme in which the nodes in a network are divided into gateway nodes and local nodes and where each gateway node controls routing directions to a plurality of predetermined local nodes, and two-level multipath routing tables are used in each node to ensure efficient routing.

0003IPsec is the Internet Engineering Task Force (IETF) standards protocol for providing security over the Internet at the network (IP) level. It provides authentication and encryption with the help of manual or automatic key exchange via IKE protocol. IPsec can be implemented via transport or tunnel mode. For the application of virtual private networks and secure overlay networks, tunnel mode of IPsec is typically used. Many implementations implement IPsec tunnels as logical virtual interfaces overlaying the physical interfaces. These logical virtual interfaces can be used as with other interfaces to run dynamic protocols on top of them. In such a setup, the tunnel endpoints will be considered as neighbors and the tunnel will be considered as a point-to-point link.

0004Running a dynamic protocol, such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), or Border Gateway Protocol (BGP) on a tunnel interface would mean that routing information like adjacency, distance vector, and link state of the nodes behind one tunnel end point are shipped to the remote tunnel endpoint. As such, the routes at one end (local and private) are learned by the remote tunnel endpoint.

0005For example, <figref idref="f0001">Fig. 1</figref> shows a tunnel link between endpoints A and B via the Internet. After enabling a dynamic protocol on the tunnel link interfaces on A and B, the routes to hosts in protected network A shall be visible to B as well as to hosts in protected network B. Similarly, the routes in protected network B shall be visible to A as well as to hosts in protected network A. The routing information conveyed in the dynamic routing protocol shall go out encrypted from A to B and B to A.

0006After the new routes are learned, for traffic from A or hosts in protected network A destined to B, or for hosts in protected network B, the tunnel interface can be chosen. As such, packets will go through IPsec processing, thereby coming out of the tunnel encrypted for destinations in B. Difficulties may arise, however, such as difficulties related to conflicts in routing between the virtual nature of the link between A and B and the physical links on which it is overlaid. Other difficulties may also arise, such as related to routing decisions between virtual paths and physical paths, between more than one virtual path, or between IPsec processing and routing procedures.

SUMMARY OF THE INVENTION

0007The invention is defined by the claims.

0008The present invention overcomes many routing difficulties that may arise in relation to dynamic routing and virtual paths. As such, the embodiments of the present invention provide methods for updating a routing table and routing packets on a network having virtual links overlaying physical links. One embodiment of the invention includes updating a routing table using interface information shared by a neighboring router. Other embodiments include making routing decisions based on interface information from a neighboring router. Further embodiments include making routing decisions based on priorities established according to interface information. Yet other embodiments include making routing decisions based on local interface information.

0009In one embodiment of the invention, a method of updating a routing table on a first gateway includes the steps of receiving data disclosing interface information on a neighboring second gateway, and updating a routing table based on the interface information. The interface information for the neighboring second gateway includes identification of communication interfaces on the second gateway, a neighbor for each one of the interfaces, an interface type for each one of the interfaces, and a physical type interface on which each virtual type interface is overlaid.

0010In another embodiment of the invention, a gateway is provided that routes packets based on data provided in an interface message from neighboring gateways. The steps involved in routing a packet at the gateway includes receiving the data packet, choosing a first route based on a routing protocol, determining an interface on the second gateway corresponding to a second next hop in the route, identifying a third gateway based on the interface, and if the third gateway matches the first gateway, choosing another route.

0011In other embodiments of the invention, computer-executable instructions for implementing the disclosed methods are stored on computer-readable media. Other features and advantages of the invention will become apparent with reference to the following detailed description and figures.

BRIEF DESCRIPTION OF THE DRAWINGS

0012The invention will be described in detail in the following description of preferred embodiments with reference to the following figures wherein:

0013<figref idref="f0001">FIG. 1</figref> shows an architecture that supports virtual connections between gateways in accordance with prior art;

0014<figref idref="f0002">FIG. 2</figref> shows an architecture that supports apparatus and methods in accordance with embodiments of the invention;

0015<figref idref="f0003">FIG. 3</figref> shows a RIP Response Message and an Interface Message/Interface Table in accordance with one embodiment of the present invention according to the architecture of <figref idref="f0002">FIG. 2</figref>;

0016<figref idref="f0004">FIG. 4</figref> shows a Link State Advertisement Message, an Interface Table, and entries from a Global Routing Table in accordance with another embodiment of the present invention according to the architecture of <figref idref="f0002">FIG. 2</figref>;

0017<figref idref="f0005">FIG. 5</figref> shows a router according to a further embodiment of the present invention;

0018<figref idref="f0006">FIG. 6</figref> shows a Radix Prefix Tree based on a Global Routing Table according to another embodiment of the present invention based on the architecture of <figref idref="f0002">FIG. 2</figref>;

0019<figref idref="f0007">FIG. 7</figref> shows another architecture that supports apparatus and methods in accordance with embodiments of the invention;

0020<figref idref="f0008">FIG. 8</figref> shows a Radix Prefix Tree based on a Global Routing Table according to another embodiment of the present invention based on the architecture of <figref idref="f0007">FIG. 7</figref>;

0021<figref idref="f0009">FIG. 9</figref> shows a Radix Prefix Tree based on a Global Routing Table according to a further embodiment of the present invention based on the architecture of <figref idref="f0007">FIG. 7</figref>;

0022<figref idref="f0010">FIG. 10</figref> shows steps of a method in accordance with embodiments of the invention.

DETAILED DESCRIPTION OF THE INVENTION

0023The invention may be embodied in various forms. Referring now to <figref idref="f0002">Fig. 2</figref>, a network architecture 10 is shown that supports systems and methods in accordance with embodiments of the invention. The architecture generally includes gateways A, B, C, D, E, and F labeled 12, 14, 16, 18, 20, and 22 respectively. A gateway as used herein refers to any device capable of forwarding data packets, such as a personal computer or a router. That is, the term gateway refers to any node in a network that can forward data packets, and can also refer to an entire network through which data packets are forwarded. Architecture 10 is a simple example that does not differentiate between hosts and routers, packet switches and terminals, subnets and links, etc. Each gateway is identified by its address, which is simply represented here as A, B, C, D, E and F. Assume for simplicity sake that the links are symmetric.

0024As shown, gateway A is connected to neighbors C, E, and F via links 24 (L1), 26 and 28 respectively. Likewise, gateway D is connected to neighbors C and B via links 30 (L2) and 32 (L3) respectively. The links may be point-to-point links or broadcast links. A tunnel 34 acts as a virtual link between gateways A and B, which have a security association therebetween. As such, gateways A and B treat each other as neighbors, even though in reality tunnel 34 is overlaid on physical links L1, L2 and L3. From the perspective of gateway A, gateway E is in the network net2, gateway B is the network net5, gateway C is in the network net0, gateway D is in the network net4, and gateway F is in the network net1.

0025An example gateway according to one embodiment of the invention is shown in <figref idref="f0005">Fig. 5</figref>, which includes a router 100. The router 100 generally includes a processor 102 connected to a memory 104 and a plurality of real interfaces 106, 108, and 110. The real interfaces 106, 108, 110 according to one embodiment include ethernet interfaces identified as eth0, eth1 and eth2, which correspond to real (physical) interfaces 110, 106 and 108 respectively. As an example, suppose that router 100 represents gateway A. Accordingly, as represented in <figref idref="f0002">Fig. 2</figref>, interface eth0 is connected to network net0 with gateway C as a next hop within that network. In addition, eth1 is connected to network net1 with gateway F as a next hop within that network, and eth2 is connected to network net2 with gateway E as a next hop within that network. Further, based on a security association with another gateway, virtual interface 120 (e.g. tun0 for gateway C) may be established and stored in memory 104 for forwarding packets via an associated tunnel, such as tunnel 34. Tun0 therefore is a virtual interface on gateway A that is connected to network net3 with gateway B as a neighbor (a virtual next hop) within that network. Tun0, however, is overlaid on eth0, which is connected to net0 with gateway C as a neighbor.

0026Stored in the memory 104 of router 100 are forwarding software 112 and a global routing table 116. As discussed later, a routing daemon 114 may also be stored in the memory 104, as well as an interface table 118 for a neighboring router. Routing daemon 114 and forwarding software 112 are programs written in a language such as the language known as C. In one embodiment router 100 operates on a UNIX^® operating system, such as systems known as Berkeley System Distribution Unix (BSD) or Free BSD.

0027Referring back to <figref idref="f0002">Fig. 2</figref>, suppose that from the perspectives of A and C, based on a metric such as a throughput metric or a delay metric, that tunnel 34 has a cost equal to 5. Suppose also that L1 has a cost of 1, L2 has a cost of 1, and L3 has a cost of 10. This creates an inconsistency of costs for tunnel 34 versus the aggregate cost of physical links L1, L2 and L3 on which tunnel 34 is overlaid. This inconsistency may be due to various reasons, such as the use of multiple metrics, inconsistent updates from gateways, flaws in computing metrics, or for other reasons.

0028Suppose now that a data packet (not shown) arrives at gateway A and that the data packet has a destination, for example a gateway (not shown) beyond gateway B. As such, gateway A may route the packet to gateway B through at least two routes. Assume that one route through tunnel 34 is a viable option and that another route through links L1, L2 and L3 (i.e. unencrypted) is another option. Assume based on the lower cost of tunnel 34, gateway A selects the route with tunnel 34 and therefore performs IPSec processing and forwards the packet on tunnel 34 to gateway B. Because tunnel 34 overlays L1, the packet is forwarded to C with a destination address for B. Based on an aggregate cost of 6 to forward the packet via L1 and tunnel 34 versus an aggregate cost of 11 to forward the packet via L2 and L3, gateway C forwards the packet to A. Gateway A repeats its evaluation and forwards the packet back to gateway C. Accordingly, the packet is continuously looped until its time to live expires, thereby never reaching gateway B. The continuous loop between A and C may be avoided by exchanging interface information between neighboring gateways A and C and updating their routing tables accordingly.

0029Referring now to <figref idref="f0002">Figs. 2</figref>, <figref idref="f0003">3</figref>, <figref idref="f0005">5</figref> and <figref idref="f0010">10</figref>, a method for updating a routing table according to interface information for a neighbor gateway in accordance with one embodiment of the invention is shown. Inclusion of interface information of neighboring gateways in routing decisions avoids the loop problem discussed above. It further avoids other potential problems and provides advantages, such as greater flexibility and improved accuracy in routing decisions. Such routing decisions generally include the use of dynamic routing protocols.

0030As an example, suppose that a dynamic routing protocol in operation on gateway A and C includes a distance vector protocol such as Routing Information Protocol (RIP) version I (see IETF RFC 1058) or RIP version 2 (see IETF RFC 1388). In accordance with such protocols, gateways typically send routing messages to their neighbors that include routing information known by the sending gateway. Suppose that gateways A and C use RIP and that gateway A sends 80 to gateway C a routing message 34, which in this example is a RIP response message.

0031As shown in <figref idref="f0003">Fig. 3</figref>, the RIP response message 34 according to one embodiment of the invention includes an identification 36 of each network connected to A (e.g. net0, net1, net2 and net3), the number of hops 38 to each network identified, and a nexthop_link indicator 40 for each network. The nexthop_link indicator 40 in one embodiment includes information that discloses an interface_id 42 for one of the interfaces 106, 108, 110, 120 on A for the network represented by identification 36. In other words, nexthop_link discloses the interface on A that a packet will take in being forwarded on A to the network with which the nexthop_link is associated.

0032According to such an embodiment, gateway A also sends 82 an interface message 44 to gateway C. The interface message 44 may be sent along with the RIP response message 34 or it may be sent independently. The interface message 44 according to one embodiment includes an interface list 46 that discloses an interface_id 42 for each interface on gateway A. For each interface_id 42, interface message 44 discloses an interface type 48 for the corresponding interface on A, a neighbor 50 (a gateway for a point to point network or a network for a broadcast network) to which the corresponding interface is connected, and if the interface type 48 is virtual, the physical type interface 52 on which the virtual type interface is overlaid.

0033Upon reception of the interface message 44, gateway C either creates 84 an interface table 54 for gateway A and stores it in memory 104, or updates an existing interface table 54 in memory 104, according to instructions stored in memory 104. The interface table 54 according to one embodiment includes interface list 46 from interface message 44. Upon reception of RIP Response message 34, gateway C updates 86 entries 35 of a global routing table (not shown) to include the nexthop_link indicator 42 for each associated route that includes gateway A as the nexthop in the route. The nexthop_link indicator 42 identifies the interface_id for the nexthop from gateway A in the associated route. The nexthop_link indicator 42 further includes a pointer 56 pointing to an entry in interface table 54 corresponding to the interface_id for the next hop. An example of global routing table entries that include nexthop_link indicators is shown in <figref idref="f0006">Fig. 6</figref> and is discussed along with another embodiment of the invention.

0034Referring now to <figref idref="f0002">Figs. 2</figref>, <figref idref="f0004">4</figref>, <figref idref="f0005">5</figref> and <figref idref="f0010">10</figref>, another embodiment of a method for updating a routing table according to the present invention is shown. This embodiment coincides with the use of a link state protocol, such as Open Shortest Path First (OSPF), on gateways A and C. As such, this embodiment is generally the same as the previous RIP embodiment, except that only a link state advertisement message 60 is sent 80 from A to C, rather than an interface message 44. A conventional OSPF link state advertisement message includes an indication of link type 62 for each link connected to the gateway, as well as a link_id 64 for a neighbor gateway connected to that link. It also typically includes link data 66 identifying real interfaces on the gateway for each real link. It may include an interface_id 68 for each interface on the gateway, but generally does not provide overlay information 70. In such an embodiment according to the present invention, the link state advertisement message 60 is expanded to include overlay information 70 for at least virtual link types.

0035As an example, link state advertisement message 60 includes link type information 62 for each interface on gateway A. The link_id 64 discloses each of A's neighbors based on the link. For example, the virtual link from A to B is represented accurately as a virtual type link with the link_id equaling "B," the neighbor through that link. It further includes link_data 66, which identifies a physical interface for each link, or for each virtual link, identifies a gateway (e.g. gateway A) as a host of the virtual link. It may further include interface_id 68, which identifies an interface for each physical or virtual link. Accordingly, the interface_id for the virtual link on gateway A identifies tun0 as the interface for the virtual link to B. Overlay information 70 identifies physical interface "eth0" as being the real interface for the virtual link 34 to gateway B.

0036Upon reception 80 of the link state advertisement message 60, in accordance with a further embodiment the present invention, an interface table 54 is created (or updated) 84 based on the information in the advertisement message 60. Further, entries 35 in the global routing table (not shown) for gateway C may also be updated 86 to include a nexthop_link indicator 42. The nexthop_link indicator 42 may be created by information inferred from the advertisement message 60. For example, routing daemon 114 may evaluate advertisement message 60 and determine that the nexthop_link for the virtual link on gateway A is "tun0." Routing daemon 114 may further create a pointer to an entry in the interface table 54 that corresponds to the nexthop_link for the virtual link. Based on the updated global routing table (not shown) and the interface table 54, methods for routing packets disclosed in accordance with the RIP embodiment are also applicable in this embodiment.

0037In a further embodiment of the present invention shown in <figref idref="f0002">Figs. 2</figref>, <figref idref="f0005">5</figref> and <figref idref="f0010">10</figref>, a method of routing a data packet includes the steps of receiving 88 a data packet (not shown) and choosing 90 a potential route based on a routing protocol. Suppose that the routing is a part of forwarding software 122 stored on gateway C. Suppose further that gateway C receives a packet (not shown) destined for gateway B and that the routing protocol selects the route of L1 to A and A to B (network 3) via tunnel 34 as the potential route. After selecting such a route, forwarding software 122 (or alternatively routing daemon 114) reviews the entry 35 for the selected route in the global routing table (not shown), which includes a nexthop_link indicator 42. Upon finding the nexthop_link indicator 42, forwarding software 122 is able to determine 92 the interface that will be taken on gateway A to forward the packet to gateway B. As indicated by nexthop_link indicator 42, and as shown in the example architecture 10 and RIP response message 34, gateway A will forward the packet along such a route using interface tun0.

0038Because nexthop_link indicator 42 further includes a pointer 56 to an entry in interface table 54, forwarding software 112 is able to determine 92 that the interface having interface_id "tun0" is a virtual link to neighbor B that is overlaid on the outgoing physical interface represented by interface_id "eth0." Based on the entry in interface table 54 for interface_id "eth0," forwarding software 112 is able to determine that the packet will be forwarded on "eth0" to neighbor "C." Once forwarding software 112 recognizes itself (gateway C) as the neighbor for the nexthop_link on A, it will choose 94 another route that excludes gateway A. As such, the forwarding software 122 will return another route to B as a potential route, such as a route through D. A route is chosen 99 based on priority, and the forwarding software forwards 96 the data packet along the selected route.

0039Referring now to <figref idref="f0002">Figs. 2</figref>, <figref idref="f0005">5</figref>, <figref idref="f0006">6</figref> and <figref idref="f0010">10</figref>, another embodiment of the present invention is shown, which includes a further method for forwarding a data packet (not shown) based on interface information. This method may take advantage of previous methods discussed for updating a routing table. However, in accordance with this method, a routing daemon 114 stored in memory 104 of a router 100 updates 97 route entries 35 of global routing table (not shown) to include priorities 70 based on interface information. For example, assume gateway C has established an interface table 54 for gateway A and has updated routing entries 35 associated with routes to gateway B to include nexthop_link indicators 42. Based on instructions included in daemon 114, daemon 114 evaluates the nexthop_link 42 for each route to B (e.g. via D or via A), and assigns a priority based on a potential conflict with the route via A. Daemon 114 determines the potential conflict by following the pointer 56 of nexthop_link indicator 42 and by determining that packets via tun0 on gateway A will be routed to itself, gateway C.

0040As part of the method for routing the packet (not shown), forwarding software 112 consults global routing table entries 35 for routes to B. This may occur by following logic such as represented by, for example, a Radix Prefix Tree 72. Upon evaluating the priorities of entries 35, forwarding software 112 selects 99 the route via D based on its assigned priority being higher than the priority for the route via A. As such, even though the route via A has a lower cost as determined by metrics, the route via D is selected and the data packet is forwarded 96 along that route.

0041Referring now to <figref idref="f0007">Fig. 7</figref>, a network architecture 210 is shown that supports systems and methods in accordance with further embodiments of the invention. The architecture 210 generally includes gateways A, B, C, D, E, and F labeled 212, 214, 216, 218, 220, and 222 respectively. Architecture 210 is similar to architecture 10 of <figref idref="f0002">Fig. 2</figref>, except that gateway F is shown connected to gateway B. Further, the cost for routing a packet (not shown) between A and B via gateway F as determined by metrics is 2, versus a cost of 5 via tunnel 234. Accordingly, for a packet received at gateway A for forwarding to gateway B, a routing decision based on metrics would favor the route via gateway F. Such a decision, however, may be contrary to the intent of sending the packet (not shown) to gateway A. For example, it may be desirable for the packet to be routed to gateway B in an encrypted state via tunnel 234, rather than in an unencrypted state via gateway F. A routing decision based on metrics, therefore, would frustrate this intent.

0042A method of routing a data packet according to one embodiment of the invention is illustrated with reference to <figref idref="f0007">Figs. 7</figref>, <figref idref="f0008">8</figref> and <figref idref="f0010">10</figref>. Suppose that a data packet (not shown) is received at gateway A that has a destination of gateway B. According to instructions stored in the memory 104 of gateway A, such as part of a routing daemon 114, entries 235 corresponding to routes to gateway B in a routing table (not shown) are evaluated and updated 98 to include priorities 270. The priorities are determined by routing daemon 114 based on the interface type for a local interface corresponding to each route. As such, routing daemon 114 considers the local interface associated with each route and determines the interface type for each interface. Daemon 114 thereby determines that the route to gateway B via gateway F is connected to local interface eth1, which is a physical type interface. Daemon 114 also determines that the route via tunnel 234 is connected to local interface tun0 and is a virtual type interface. Because tun0 is a virtual interface and eth1 is a physical interface, daemon 114 assigns a higher priority 270 to the route via tunnel 234.

0043Based on the priorities, forwarding software 112 selects the route via tunnel 234 even though the route via gateway F has a lower cost. Accordingly, the packets received at gateway A will be encrypted in transmission to gateway B via tunnel 234, despite other choices suggested by metrics.

0044In another embodiment of the invention, forwarding software 112 performs the steps performed by routing daemon 114 except for assigning priorities. As such, forwarding software 112 determines that the route via tunnel 234 is connected to local interface tun0 and is a virtual type interface. Because tun0 is a virtual interface and eth1 is a physical interface, forwarding software 112 selects the route via tunnel 234 according to its programming despite the costs determined by metrics.

0045Referring now to <figref idref="f0007">Figs 7</figref> and <figref idref="f0009">9</figref>, a method of routing a data packet according to a further embodiment of the invention is shown. Suppose that an encrypted data packet (not shown) is received at gateway D from gateway C that has a destination address of gateway B, as part of routing on tunnel 234. Based on metrics, it is possible that gateway D will forward the data packet to gateway C on a route to gateway B that includes gateways C, A, and F. This may cause a loop as the packet is routed back and forth between gateways C and D or gateways A, C and D.

0046According to a further embodiment of the present invention, a method for routing a packet is shown in <figref idref="f0009">Fig. 9</figref>. As such, instructions stored in the memory 104 of gateway D, such as daemon 114, evaluates potential routes for forwarding the packet to gateway B by looking at entries 235 of a global routing table. Upon recognizing that the direct route to gateway B includes one hop (e.g. nexthop = B), daemon 114 assigns a higher priority to this route than to other routes that includes multiple hops. Accordingly, forwarding software 112 selects the direct route to gateway B over other routes suggested by metrics.

0047While the present invention has been described in connection with the illustrated embodiments, it will be appreciated and understood that modifications may be made without departing from the scope of the invention. In particular, the invention applies to almost any type of network and a variety of different routing protocols, such as path vector protocols.