Multiplex communications – Diagnostic testing – Determination of communication parameters
Reexamination Certificate
2000-01-11
2003-12-16
Cangialosi, Salvatore (Department: 2661)
Multiplex communications
Diagnostic testing
Determination of communication parameters
C370S377000
Reexamination Certificate
active
06665273
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is related to networking systems and in particular, to maximizing bandwidth resources in a Multiprotocol Label Switching (MPLS) system.
2. Background
Internet is the widely accepted medium for the interchange of information. Government, business entities and other organizations routinely use the Internet to provide and receive information, and the number of users is increasing. To support such increased usage, networks and supporting devices have become larger and more complex. However, even with the proliferation of such devices and network complexity, an Internet service provider (ISP) must still provide reliable service that can withstand link or node failures while maintaining high transmission capacity. Additionally, the devices used in the network links and the intermediate devices such as switches and routers are expensive items and thus should be used to their maximal capacity. Traffic engineering is one solution that enables ISPs to maximize device capacities while providing network resiliency.
Traffic engineering (TE) is a term that refers to the ability to control traffic flow in a network (notwithstanding a path chosen by a routing protocol) with a goal of reducing congestion thereby getting the most use out of the available devices. For example, a network topology typically has multiple paths between two points. However, a routing protocol will usually select a single path between the two points regardless of the load on the links that form the path. This may cause certain paths to be congested while the other paths are under-utilized. Traffic engineering facilitates load balancing or load sharing among the paths thereby enabling the network to carry more traffic between two points.
Multiprotocol Label Switching (MPLS) is a technology that, among others, allows traffic engineering to be performed. The principle behind MPLS, as its name implies, is using labels to switch packets along a path. This is in contrast to a routing lookup table in which the longest lookup on an Internet Protocol (IP) header is performed. A label distributing mechanism based on a Label Distribution Protocol (LDP) or existing protocols such as Resource Reservation Protocol (RSVP), which has been enhanced, allows for the assignment and distribution of the labels. RSVP is a protocol for reserving network resources to provide Quality of Service guarantees to application flows. Various control modules are responsible for facilitating and maintaining traffic engineering as well as for maintaining other relevant control information.
Referring to
FIG. 1
, an exemplary MPLS based router
100
, among others, may include:
a routing module
110
that constructs a routing table
112
using conventional routing protocols, preferably a linked-state Interior Gateway Protocol (IGP) such as Intermediate System to Intermediate System (IS-IS), Open Shortest Path First (OSPF) and so forth;
a traffic engineering (TE) module
120
that enables explicitly specified label switched paths (LSPs) to be configured throughout a network using a TE topology database and a TE path calculation module, as will be described, which preferably in conjunction with RSVP and a label allocation module (not shown), assigns labels
122
to routes and supplements the above routing table with those labels to be further described with respect to
FIG. 2
;
a TE path calculation module
130
that calculates the “best” path for the LSPs based on resources required by the path and the available resources in the network;
a TE topology database
140
that receives and stores information on link states of the network and available resources via the IGP assuming that it is a linked state IGP,
a TE link management module
150
that keeps track of and maintains all LSPs that have been set up; and
supporting protocols such as RSVP
160
and an IGP
170
with extensions for global flooding of resource information.
Explicitly routed LSPs are referred to as TE tunnels.
FIG. 2
illustrates the operation of an MPLS system supporting unicast TE tunnel routing. Using an IGP and RSVP, each router on a path of a TE tunnel builds a routing table supplemented with labels. For this configuration, each router has its resource information flooded to the appropriate IGP link state database and accepts RSVP signaling requests. Generally, when a TE tunnel is being established, assuming it to be a dynamic path, the TE module sets the resource requirement of the path based on operator input or default. The TE path calculation module calculates a constrained short path from the “head-end” router to the “tail-end” router based on resources required to setup the path, which in this instance is path
200
. RSVP then signals the routers along the path
200
that a setup is being performed. During setup, the routers on the path need to agree on the labels to be used for the packets traveling along the path. This label allocation procedure may also be performed by RSVP in that its signaling and the resource reservation features may be used to construct the TE tunnels. RSVP also requests labels from the label allocation module; these labels required for constructing the TE tunnel.
The TE module using RSVP causes router R
1
at the head-end of the tunnel to send a setup request to the router Rn at the tail-end of the tunnel. The setup request travels along the calculated path
200
until it reaches the tail-end router Rn. Upon receipt of the setup request, the router Rn returns a setup reply to router R
1
over the path
200
traveled by the setup request. When router Rn-
1
receives the setup reply, it requests a label from the label allocation module, which allocates a label LRn-
1
for the segment of the path. Router Rn-
1
then establishes a mapping in its routing table between the label LRn-
1
and the path to router Rn. Router Rn-
1
then attaches the label LRn-
1
to the setup reply and sends it “upstream” to the previous “hop” router Rn-
2
on the path. In response to receiving the setup reply, Router Rn-
2
requests and receives a label LRn-
2
, which it uses to allocate for that segment of the path and establishes a mapping in its routing table between the label LRn-
2
and the path to router Rn-
1
. Router Rn-
2
then replaces the label LRn-
1
on the setup reply with its label LRn-
2
and sends it to the next router Rn-
3
on the path. Likewise, Router Rn-
3
, upon receiving the setup reply, requests and allocates a label LRn-
3
for the segment of the path and establishes a mapping between the label LRn-
3
and the path to router Rn-
2
. Router Rn-
3
then replaces the label on the setup reply with its own label and sends the setup reply further upstream. This process is repeated for each router along the path
200
until the head-end router R
1
receives the setup reply. In this instance, the setup reply will have a label LR
2
attached thereto by the router R
2
on the path. Router R
1
then adds an entry to its routing table using the label LR
2
which functions as an initial label for entering the TE tunnel created for the path.
Once the TE tunnel has been established, the TE module notifys the IGP as to the IP address of the TE tunnel. Once notified, the IGP can route packets through the TE tunnel using the IP address. In instances where the IGP is load balancing between a TE tunnel and a regular path, IGP may use a “flow” method or a “round-robin” method to load balance between the two paths. The flow method is really a load sharing method and may be performed in a following manner: a portion of a source address and a destination address of a packet may be combined and hashed to generate one of a pseudo-random range of numbers. The value of the number determines which path the packet is to follow. Assuming the packet is routed to the TE tunnel, the packet transmission mechanism through the tunnel is based on label switching.
For example, when router R
1
receives a packet, it performs a conventional longest match lookup on the IP header. If the lookup indicates a label, router
Goguen Robert
Swallow George
Cangialosi Salvatore
Cesari and McKenna LLP
Cisco Technology Inc.
LandOfFree
Dynamically adjusting multiprotocol label switching (MPLS)... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamically adjusting multiprotocol label switching (MPLS)..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamically adjusting multiprotocol label switching (MPLS)... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3171330