Patent Application
20080159288
The invention is directed towards traffic engineering in packet-based networks, specifically IP packet-based networks.
Quality of service (QoS) requirements of packet-based networks have become a great concern as network demands have increased in the past few years. One particular QoS requirement of concern is traffic engineering, or source-destination route selection. A further requirement with traffic engineering is quick recovery via alternate route selection when a link selected in the original source-destination route fails or otherwise becomes unavailable.
In IP networks based on link state routing, e.g., OSPF, nodes on the network maintain a network topology table, or a listing of node-to-node links throughout the network along with the corresponding characteristics. By utilizing this table, a source node can construct a source-destination route and begin transmission of a data flow.
A current standard for traffic engineering in IP networks is Multiprotocol Label Switching (MPLS). In MPLS, Label Switched Paths (LSPs) can be created along any desired route in the network based on the QoS requirements of the flows to be carried over the path. Essentially, an LSP is a virtual connection, or a path chosen through the network using the information provided by a routing protocol. While the topological information required for construction of LSPs can be disseminated using a standard routing protocol, the packets themselves are switched based on the fixed-length LSP labels. This provides for efficient packet forwarding based on referencing routing tables indexed by the LSP labels. Basically, by using a packet's LSP label to identify the corresponding next hop, i.e. the next node on the route, each routing node in the route can quickly determine the next link over which the packet is to be forwarded.
While efficient for forwarding packets, this approach has limitations when it comes to fast recovery from route failures. MPLS provides means for fast protection in an IP network by pre-establishing alternate LSPs on node paths. Traffic is switched to this alternate LSP upon failure of the primary path. A major drawback to this approach is that the alternate LSPs have to be pre-established for fast protection as signaling to set up new LSPs after failure requires a long time in comparison to the time required to switch the traffic to a pre-established LSP. This arrangement has the additional drawback that these alternate paths chosen to replace a faulty LSP may not be the most efficient based upon current network conditions.
Another method that exists for routing packets along designated routes is source routing. By using features in IPv4 (Internet Protocol version 4), such as an options field in the header, a source can label the entire route that it chooses for a packet to follow. In source routing, every packet must have the entire route in the header. This leads to additional costs, as each routing node on the path must check each header for the path and determine the next hop. Also, as each packet contains the entire source-destination route, the size of each packet increases.
Recently, IPv6 (Internet Protocol version 6) was approved as a means to alleviate the IP address exhaustion problem. Specifically, the number of IP addresses allocated for by IPv4 is being exhausted. Along with providing more address space, IPv6 also provides additional capabilities to improve QoS. One of these capabilities is the use of extension headers, or headers used dynamically by a node to include additional information in the packet.
The present invention provides a method for traffic engineering and fast protection of individual data flows using capabilities supported by IPv6. In this method, a specific network route based upon QoS requirements of a data flow, i.e., required bandwidth and delay constraints, and a flow label for the data flow can be selected by a source node. Once a route meeting the QoS requirements of the data flow and the corresponding flow label are selected, a source node can insert the route and the flow label in an initial packet header and force the flow along the corresponding network path. The insertion of the route into the initial packet header utilizes the capabilities of IPv6 hop-by-hop extension headers. The flow label is carried in the “flow label” field of the IPv6 fixed header. The source and intermediate nodes cache the route and the flow label selected for a data flow. For subsequent packets, the flow label is used by intermediate nodes to determine the next hop along the route.
In the event of a link or node failure on the route of a data flow, an intermediate node can divert the data flow along a new route by inserting the new route in the next packet belonging to the data flow so that, as the packet is forwarded toward the destination, intermediate nodes on this new path can cache the route and the flow label associated with the data flow. This new route is computed to be disjoint from the failed segment of the primary path. Note that this alternate route can be pre-computed or computed in real-time and, immediately on receipt of the failure indication, an intermediate node can switch the flow to this alternate route.
a is a data packet according to IPv6 standards.
b is an Options Field in a Hop-by-Hop extension header.
a is a flow chart illustrating the behavior of a source client according to principles of the present invention.
b is a flow chart illustrating the behavior of an intermediate node according to principles of the present invention.
c is a flow chart illustrating the behavior of a destination client according to principles of the present invention.
The present invention provides a method and computer program product for utilizing quality of service (QoS) capabilities in IPv6 (Internet Protocol version 6) to improve traffic engineering and fast protection/error control.
Problems may occur along the route, however. For example, connection 120 between router 110a and router 110b could become inactive for various reasons, e.g., physical hardware breakdowns. The optimized route being used to forward the data flow is now incomplete and cannot continue to be used. An alternate path is needed to continue transferring the data flow.
Using existing techniques to recover from a situation such as this requires initiating a new path at the source route. This can be time consuming if the number of nodes on the path is very large. Each node must queue packets belonging to the data flow until the source node can determine a new path and forward the packets along this new path. Additionally, several existing techniques, such as MPLS discussed above, utilize new routes that were determined at the same time the optimized route was chosen. This can lead to the selected new route being ill-suited to carry the data flow to the destination client on account of changes in the operating conditions.
In the present invention, the node immediately preceding the problem, in this example router 110a, will determine a new route to utilize for the forwarding of the packets. In this example, router 110a determines that router 110c can be used to bypass broken connection 120. Router 110a indicates the new route to the nodes involved in routing the data flow by using the same features of IPv6 extension headers that were used by source client 105 to establish the original route. By forming the new route at an intermediate routing node, time is saved as the optimization can occur in real time without the need for every node on the route to queue the data flow until the failure indication propagates to the source client and a result containing a new route propagates to the router preceding the error.
a illustrates a data packet as standardized by IPv6. The present invention makes use of the extension headers introduced in IPv6. The IPv6 specification allows for six types of extension headers: Hop-by-Hop, Routing, Fragment, Destination Options, Authentication, and Encapsulating-Security-Payload. Except for the Hop-by-Hop and Routing extension headers, all the other extension headers are processed only at the node specified by the destination address in the IPv6 header. Routing extension headers are used for source routing, i.e., to list the intermediate nodes to be visited. Hop-by-Hop extension headers are also processed by each intermediate router. Note, however, that the standard only specifies the format/framework but does not suggest any particular uses of or content for these extension headers. These extension headers can be stitched together using the Next Header field 201 as shown in
b illustrates an Options Field 203 of a Hop-by-Hop extension header. Several types of information can be reported in a Hop-by-Hop extension header by exploiting this (i.e., options) feature. The present invention utilizes this feature to indicate the route to be followed by packets associated with the data flow to which the present packet belongs. Note that a single extension header can contain multiple Options Fields, each of which comprises three sub-fields—Option Type, Option Length and Data.
a-c illustrate the steps taken by each major component in the network (i.e., source client, intermediate nodes and destination client) according to a particular embodiment of the present invention. In this embodiment, the steps required for forwarding a data flow through the network illustrated in
a illustrates the steps taken by the source client. The process begins at step 300. Here, source client 105 initiates a data flow to be forwarded to destination client 115. After initiating a data flow and determining the destination client, source node 105 determines an optimized route to use in forwarding the data flow to the destination. By using a network topology table, source client 105 can quickly determine an optimized route for forwarding the data flow. In this example, the optimized route used is source client 105 to router 110a to router 110b to destination client 115. Source client 105 also selects a flow label for the data flow that is unique within the relevant part of the network.
Once source client 105 has determined an optimized route and selected a flow label, the process continues to step 302. At step 302, source client 105 formats a first packet of the data flow to include an extension header which includes the optimized route.
Once the packet header including the extension header for the initial packet is completely filled, the process proceeds to step 304. Here, the source client 105 transmits the initial data packet of the data flow along the optimized route. Once the initial data packet is transferred, the source client 105 waits for a response. One of two responses are possible, a positive response which indicates the data packet reached the destination client 115 or a negative response which indicates the data packet failed to reach the destination client 115. If a negative response is received, the process returns to step 302 where the source client 105 reformats the extension header to include a new optimized route. Then the process proceeds as before.
b illustrates the steps performed by an intermediate node (e.g., routers 110a and 110b in
After determining the next node to forward the packet to, the process proceeds to stop 330 where the intermediate node determines if the packet sent is the last packet of a data flow. If the packet is not the last packet of the data flow, the process continues to step 332. Here, as before at step 322, the intermediate node determines if the route is intact. If the route is intact, the process returns to step 324 where the packet is forwarded to the next node on the optimized route. However, if the route is not intact, the process proceeds to step 334 where the intermediate node computes a new route. This new route is computed using the local network topology table stored at the intermediate node. By computing this new route at the intermediate node as opposed to the source node, efficiency is increased as the re-routing happens immediately. If the source node had to be notified to compute a new route, the packet would need to be resent along the new route which would create a much larger delay than in the present invention.
Returning to step 330, if the packet is a flow termination packet associated with the data flow, the process proceeds to step 336. Here, as is done at steps 322 and 332, the intermediate node determines if the route is intact. If the route is not intact, the intermediate node deletes the cached entries associated with the flow and then discards the flow termination packet at step 338. Conversely, if the route is intact, the intermediate node identifies the next hop for the termination packet, deletes the cached entries associated with the flow, and then forwards the termination packet to the next hop node at step 340. ***** Change
c illustrates the steps performed by a destination client (e.g., destination client 115) according to an embodiment of the present invention. At step 350, a destination client receives the first packet of a data flow containing an extension header listing a flow label and an optimized route. The destination client caches the relevant pieces of information about the flow (e.g. the address of the source client, the flow label, etc.) The process then proceeds to step 352 where the destination client sends a positive response to the source client. This response is used as an indication that the initial data packet reached the destination node and that the optimized route is suitable for forwarding the remainder of the data flow.
As described above,
Once the bandwidth and traffic class have been filled, the source client begins to fill the fields relating to the chosen route. The first field is Number of Intermediate Nodes 418. In this example, source client 105 will insert a “2” into this field as there are two intermediate nodes (i.e., router 110a and router 110b) between source client 105 and destination client 115. Following field 418, source client 105 inserts the network address of router 110a into field 420. Similarly, source client 105 inserts the network address of router 110b into field 422. It is important to note that in this embodiment, the source address and destination address are not inserted into the initial extension header. Only the addresses of the intermediate nodes are inserted into the initial extension header.
Once the intermediate node addresses are inserted into the extension header, the source client can update Option Length field 410 to indicate the total length of the fields contained within the scope of the current Option. The Header Extension field 406 is also filled at this time with the total length of the just-filled extension header. The source client can also add another extension header at this time, such as an extension header containing information for performance monitoring along the source-destination route. Each of these extension headers will begin with “Next Header” and “Header Extension Length” fields, followed by the corresponding contents.
In contrast to the above discussion, a negative response can be sent to the source node from any intermediate node along the route. Similar in structure to the positive response, a negative response includes a negative indication in Response Code field 516. Additionally, Number of Node Addresses field 518 will change depending on where the negative response initiated. The addresses of the packet will change as well. The source address in IPv6 Fixed Header 502 will be the address of the node sending the negative response. The address contained in field 520 of the extension header will be the address of the destination client. As mentioned earlier, this address field is always filled with the address of the destination of the original flow setup or change packet in response to which the present packet is being sent. The addresses that follow in the extension will change accordingly to indicate the nodes between the node sending the negative response and the source node.
Once router 110a receives the packet, it knows that the new route has been positively acknowledged by all nodes on the new route. Note that when router 110a initiates the reroute, it sends the packet carrying the flow reroute request along the proposed route. When nodes on this route receive the reroute request, they verify that they have the resources to support the flow. If they do, they allocate the desired resources to the flow, cache information related to the route (including the flow label), and forward the packet to the next node on the proposed reroute. Otherwise, they discard the packet carrying the flow reroute request, and send a negative response to the node which initiated the flow reroute request (router 110a in the present example.) Since only the node where the proposed reroute merges with the original route can send a positive response to a flow reroute request (which happens only if all intermediate nodes have forwarded the reroute request along the proposed route), receiving a positive response from router 110b indicates to router 110a that all nodes and links on the proposed reroute can support the rerouted flow.
Similar to the discussion of
As the termination packet is forwarded through the route, each intermediate node processes the information similarly. First, the intermediate node checks Option Type field 808 and determines the packet indicates a flow termination. Next, the intermediate node checks Flow Label field 814 to determine which flow is being terminated. The node uses this information to find the stored route in its cache, identifies the node (if any) that occurs next on the route, and then deletes the route and the accompanying flow label. The node next forwards the packet to the next node on the route (identified in the previous step). If the node that appears next on the route is the destination of the flow, the node forwards the packet to the destination address contained in IPv6 Fixed Header 802. Once destination client 115 receives the packet, it, too, first checks Option type field 808 to determine the packet is a flow termination packet. It checks Flow Label 814, and similar to the intermediate nodes, deletes the stored route. Finally, destination client 115 checks the non-header information contained in the packet for any additional data relating to the data flow.
The use of the flow termination feature described above is optional. At each node on the route associated with the data flow, the cache entries associated with the flow and the corresponding resource allocations are controlled via a timer. If a node does not receive any packet associated with the data flow for a certain amount of time, the corresponding cache entries and resource allocations are erased. The flow termination feature helps speed up this process by eliminating the need for a node to wait for a corresponding time-out interval before erasing the entries and resource allocations.
By utilizing the extension headers provided in IPv6 as discussed above, several advantages over the prior art are realized. Primarily, a route change can be made immediately at a node where a link has failed. The node can quickly determine a new route and alter the data flow to follow this new route while simultaneously reporting the new route to the unaffected nodes in the route. By doing this, the unaffected nodes are updated with a new route listing without interrupting delivery of the data flow. Another advantage over the prior art is that routes can be changed at any time by a source node. If the requirements for a data flow change for some reason, a source node merely needs to send a flow setup or change packet indicating a new bandwidth or traffic class requirement as well as a new route if needed. In this case, if the route has changed, the cache entries associated with the flow at nodes that do not appear on the new route are timed out as described earlier. Alternatively, the source node may send a termination packet first which will be forwarded along the old route, followed by a flow setup or change packet that will follow the new route. If this latter method is used, cache entries and resource allocations at nodes on the old route are explicitly erased before the new route is established. In either case, a source client can quickly change routes seamlessly (without losing any data) by dynamically creating a new route that conforms to the requirements of the data flow. Yet another advantage is that a source client can force a data flow to follow a selected route without inserting the route into every packet of the data flow. This lowers the size of each packet in the data flow and increases efficiency.
The embodiment shown in
