1. Field of the Invention
The present invention relates to data networks and more specifically to reporting out-of-resources (OOR) conditions in a data network.
2. Background Information
A data network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations. Many types of networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect large numbers of geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. Nodes typically communicate over a data network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
In a typical arrangement, end nodes in a data network are coupled via one or more intermediate nodes, such as routers. Routers are often configured to “route” data, such as packets, between various nodes in the network. Routing is typically performed at layer-3 (L3), which is the network layer of the Open Systems Interconnect Reference Model (OSI-RM).
Routers often maintain forwarding databases (FDBs), which are typically configured to hold routing information which may include L3 addresses and interface information that the router uses to determine where data (e.g., data packets) are forwarded in order to reach their destination. For example, a router may have a FDB organized as a routing table containing one or more entries wherein each entry contains a L3 destination address of a destination node and interface information about an interface on the router through which the destination node may be reached. A data packet containing a destination address that matches a destination address of an entry in the routing table is forwarded by the router to the interface specified by the matching entry for transfer to the destination node.
A router may execute one or more routing protocols that enable the router to route packets and exchange routing information with other routers in the network. The routers often use this information to configure (e.g., compute) their FDBs. The routing protocols may include distance-vector protocols, such as the well-known Routing Information Protocol (RIP), or link-state protocols, such as the well-known Intermediate-System-to-Intermediate-System (IS-IS) and Open Shortest Path First (OSPF) protocols. Routing information is typically exchanged between the routers in the form of advertisement messages. For example, nodes executing the OSPF protocol exchange routing information (e.g., link state) using an advertisement message called a Link State Advertisement (LSA). As used herein, an advertisement message refers generically to a message that a routing protocol uses to convey routing information to other intermediate nodes (e.g., a router, a switch) in the network. An intermediate node that acquires an advertisement message may use information contained therein to update its FDB.
Routers may transfer data packets through the network between a source and destination in a “connection-oriented” manner using a connection-oriented protocol. A connection-oriented protocol transfers data packets through the network over a predefined path, often called a connection or circuit, that is established between the source and destination. Here, the connection or circuit is established between the source and destination before any data are transferred. After the connection has been established, data are transferred between the source and destination over a path defined by the connection.
Some connection-oriented protocols utilize unidirectional connections, i.e., connections that transfer data in one direction from a source to a destination. For example, a unidirectional connection between a router A and a router B transfers data in one direction from router A to router B. In order to transfer data in the other direction, i.e., from router B to router A, another unidirectional connection from router B to router A would have to be established.
The connections may be “signaled” end-to-end using a signaling protocol, such as the Resource Reservation Protocol (RSVP). The end of the connection that initiates the signaling for the connection is often called the “head-end” of the connection and the end of the connection that terminates the signaling is often called the “tail-end” of the connection. A router hosting the head-end of the connection is often called the head-end node and a router hosting the tail-end of the connection is often called the tail-end node. Thus, for example, in a connection from a source to a destination where router A hosts the “head-end” of the connection and router B hosts the tail-end of the connection, router A is the head-end node and router B is the tail-end node.
When the connection is no longer needed, the connection is typically “torn down” and resources, such as nodes, interfaces, protocols and so on, utilized by the connection are made available for other connections. A resource, as used herein, refers to entities associated with an intermediate node. These entities may include the intermediate node itself, an interface (e.g., a port) on the intermediate node and a protocol running on the intermediate node.
Multiprotocol Label Switching (MPLS)
An example of a well-known connection-oriented protocol is the Multiprotocol Label Switching (MPLS) protocol. MPLS employs an innovative label-based forwarding technique that simplifies Internet Protocol (IP) traffic routing in complex networks. MPLS provides a framework that embodies various features enabled by a connection-oriented link layer including, e.g., Quality of Service (QoS), Traffic Engineering and Constraint-based Routing (CR).
According to the MPLS protocol, a label is added to a packet by a head-end node of a pre-determined labeled-switched path (LSP). The head-end node is typically a label-switching router (LSR) often called an ingress LSR. The LSP is a pre-determined path that is taken by the packet through the network from the “head-end” of the LSP to the “tail-end” of the LSP and the label typically contains information (e.g., tags) associated with the LSP. As the packet traverses the LSP, LSRs handling the packet use the tag information contained in the label to “switch” the packet along the LSP. When the packet reaches a node at the “tail-end” of the LSP (e.g., a egress LSR), the label is removed and the modified packet may be further processed (e.g., routed), accordingly.
MPLS-Traffic Engineering (MPLS-TE)
Traffic engineering (TE) relates to the process of selecting paths utilized by data traffic in a manner that facilitates efficient and reliable network operations while optimizing network resource utilization and data traffic performance. TE works within various bandwidth and administrative requirements to choose a path that is optimal for carrying data traffic. A goal of TE is to compute a path from one node to another where the path does not violate various constraints, such as bandwidth and various administrative requirements, and is optimal with respect to some scalar metric. Once a path is chosen, TE is responsible for establishing and maintaining state along the path.
Although the MPLS protocol provides underlying technologies in forwarding packets in MPLS networks, it alone does not provide all of the components necessary for TE support. MPLS-TE is an extension of the MPLS protocol that employs TE to establish and maintain MPLS-TE labeled-switched paths (MPLS-TE LSPs). MPLS-TE LSPs are set up by MPLS-TE in a manner that ensures resources are available for data flows that use the MPLS-TE LSP. MPLS-TE LSPs often originate at a head-end LSR and terminate at a tail-end LSR. Protocols, such as RSVP-TE, are typically used to reserve the resources for the MPLS-TE LSP.
MPLS Differentiated Services TE (DS-TE)
MPLS Differentiated Services TE (DS-TE) is an extension of MPLS-TE that enables traffic to be classified on a class of service (CoS) basis. With DS-TE data flows are classified into classes and resources are allocated to the data flows on a per-class basis. Packets belonging to a particular DS-TE class are said to constitute a Behavior Aggregate (BA).
At an ingress node (e.g., ingress LSR) of a DS-TE LSP, a packet is marked with a MPLS shim header and classified into DS-TE classes and steered onto appropriate DS-TE LSP. The shim header comprises a 20-bit label value and a 3-bit experimental value. LSRs that acquire the packet use the 3-bit experimental value and/or the 20-bit label value to determine the treatment the packet receives.
Out-of-Resources (OOR) Condition
During the establishment of an MPLS-TE LSP, nodes along the path may either accept the MPLS-TE LSP or reject it. One condition that may cause a node to reject an MPLS-TE LSP is an “out-of-resources” (OOR) condition. An OOR condition may occur when, for example, allowing the new MPLS-TE LSP would cause the node to: (1) exceed the maximum number of MPLS-TE LSPs allowed for the node, (2) run out of MPLS-TE LSP label space and/or (3) exhaust various hardware resources on the node.
When an MPLS-TE LSP is rejected, the node rejecting the MPLS-TE LSP typically communicates the rejection to the head-end node that initiated the MPLS-TE LSP via a rejection message. The head-end node may respond to the rejection by “pruning” the rejecting node from its routing topology and computing an alternate path for the MPLS-TE LSP that does not use the rejecting node.
Certain routing protocols, such as OSPF, often advertise bandwidth that is available for certain links. Here, a head-end LSR may use this information to compute a path that a new MPLS-TE LSP (established from the head-end LSR) could take. However, while a link in the computed path may initially have sufficient resources with respect to, e.g., bandwidth at the time the path was computed, it may thereafter have insufficient resources (e.g., a lack of hardware resources) at the time the path is actually established. Thus, while advertised bandwidth information may be useful to a head-end LSR for calculating a prospective path the information may turn out to be misleading when the MPLS-TE LSR is actually established.
An existing technique for handling an OOR condition associated with an entity, such as a data link, line card or a node, involves advertising the entity as having a “maximum cost” in an advertisement message. By advertising a maximum cost associated with the entity, other nodes in the network are discouraged from using the entity in their path calculations for new MPLS-TE LSPs. However, advertising an entity as having a maximum cost is not a precise way to report an OOR condition for the entity. Rather, nodes on the network may still use the entity in their path calculations for new MPLS-TE LSPs if no other lower cost alternatives are available.
Another problem with advertising an entity as having a maximum cost involves disrupting existing MPLS-TE LSPs. Since the maximum cost indicates that the entity has a high cost associated with it, on learning of the high cost associated with the entity a node may respond by recalculating paths for existing MPLS-TE LSPs that use the entity in an effort to avoid the entity. This, in turn, may cause disruption to existing data flows that use these LSPs.
Yet another problem associated with advertising an entity as having a maximum cost is that it may not provide sufficient information to a head-end node of a MPLS-TE LSP to enable the node to distinguish between DS-TE classes that can no longer use the entity and DS-TE classes that may still use the entity. This may be the case where resources on the node are provisioned on a per-DS-TE class basis.
USPTO Backgrounds
USPTO Backgrounds