WO2003010923A2 - Apparatus and method for establishing tunnel routes to protect paths established in a data network - Google Patents
Apparatus and method for establishing tunnel routes to protect paths established in a data network Download PDFInfo
- Publication number
- WO2003010923A2 WO2003010923A2 PCT/CA2002/001164 CA0201164W WO03010923A2 WO 2003010923 A2 WO2003010923 A2 WO 2003010923A2 CA 0201164 W CA0201164 W CA 0201164W WO 03010923 A2 WO03010923 A2 WO 03010923A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- path
- node
- tunnel
- subset
- tunnel route
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 35
- 230000015654 memory Effects 0.000 claims abstract description 23
- 238000012545 processing Methods 0.000 claims description 9
- 230000003190 augmentative effect Effects 0.000 claims description 4
- 238000011144 upstream manufacturing Methods 0.000 claims description 3
- 238000012217 deletion Methods 0.000 claims 1
- 230000037430 deletion Effects 0.000 claims 1
- 230000006870 function Effects 0.000 claims 1
- 229920006395 saturated elastomer Polymers 0.000 description 18
- 230000008569 process Effects 0.000 description 9
- 239000011159 matrix material Substances 0.000 description 8
- 238000013507 mapping Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 229920006008 lipopolysaccharide Polymers 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
- H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
Definitions
- the present invention is related to data transmission networks and, in particular to a method and apparatus for providing protection against link and node failures in such networks.
- LSP label-switched paths
- LDP Label Distribution Protocol
- RVP Resource Reservation Protocol
- OSPF Open Shortest Path First
- a solution to this problem is to establish backup routes through which the data packets will be forwarded in case of a node or link failure.
- An LSP for which such a backup route has been defined is thus commonly referred to as a "protected" LSP.
- One way of protecting LSPs is to pre-establish backup routes by reserving bandwidth along fixed trajectories in the network. Each such "backup channel" is assigned to protect one or more LSPs.
- a backup channel assigned to protect multiple LSPs is designed to occupy enough bandwidth to maintain the maximum possible quality of service that could be associated with each of N LSPs it is assigned to protect.
- a backup channel may be established so as to occupy only enough bandwidth to maintain the maximum possible quality of service associated with M of the N LSPs it is assigned to protect, where M ⁇ N.
- the present invention may be summarized as a computer readable storage medium containing a program element for execution by a computing device in a network having a plurality of linked nodes, wherein paths for conveying data traffic are defined in the network, each path traversing an ordered set of nodes from among the plurality of nodes.
- the program element includes a first program component adapted to assign, for a particular node that is intermediate at least one particular path, a particular tunnel route to the protection of a particular subset of the at least one particular path against failures occurring downstream from the particular node along the particular subset of the at least one particular path.
- the program element further includes a second program component adapted to store in a memory a set of first data elements, each first data element identifying: a respective subset of the at least one particular path for which the particular node is intermediate; and a respective tunnel route assigned to the protection of the respective subset of the at least one particular path against failures occurring downstream from the particular node along the respective subset of at the least one particular path.
- the program element further includes a third program element adapted to consult the set of first data elements to determine which, if any, of the tunnel routes identified in the first data elements is also capable of protecting the particular subset of the at least one particular path against failures occurring downstream from the particular node along the particular subset of the at least one particular path; and if at least one tunnel route is so determined, select one of the at least one tunnel route so determined as the tunnel route assigned to protect the particular subset of the at least one particular path against failures occurring downsfream from the particular node along the particular subset of the at least one particular path.
- the third program element consults the set of first data elements to determine which, if any, of the tunnel routes identified in the first data elements satisfies a first condition of including two nodes that are traversed by each path in the particular subset of the at least one particular path. In a specific embodiment, the third program element also consults the set of first data elements to determine which, if any, of the tunnel routes identified in the first data elements satisfies a second condition of including a next node that is distinct from a next node of each path in the particular subset of the at least one particular path.
- the present invention allows protection to be provided for portions of a path, such as an LSP without requiring that such protection be established on an end-to-end basis. Also, by consulting a list of existing tunnel routes prior to the establishment of new tunnel routes, the time required to protect data traffic is reduced. Moreover, since the tunnel routes locally protect the paths of interest, the establishment of such tunnel routes does not consume much bandwidth in the network.
- the present invention provides a node for exchanging packets in a network in which are defined paths for conveying data packets along ordered sets of nodes.
- the node includes at least one input interface for accepting data packets along at least one of the paths; at least one output interface for releasing data packets along the at least one of the paths; and a processing module adapted to assign a particular tunnel route to the protection of a particular subset of the at least one of the paths against failures occurring downstream from the node along the particular subset of the at least one of the paths.
- the node includes a router.
- the present invention may be summarized as a method for providing path protection in a network having a plurality of linked nodes, wherein paths for conveying data traffic are defined in the network, each path traversing an ordered set of nodes from among the plurality of nodes.
- the method includes assigning, for a particular node that is intermediate at least one particular path, a particular tunnel route to the protection of a particular subset of the at least one particular path against failures occurring downstream from the particular node along the particular subset of the at least one particular path.
- Fig. 1 illustrates a network in which the protection method of the present invention can be applied
- Fig. 2 illustrates a node in the network of Fig. 1 ;
- Fig. 3 illustrates a node confroller included in the node of Figure 2;
- Fig. 4 shows a procedure for assigning tunnel routes to the protection of LSPs in accordance with an embodiment of the present invention.
- Fig. 5 illustrates the network of Fig. 1 in which two LSPs and a tunnel route have been established.
- FIG. 1 shows a network 100 in which the present invention can be implemented.
- the network 100 includes a plurality of nodes HO j , j varying from 1 to 12.
- the nodes are connected through a plurality of links 120 ⁇ m , k and m varying from 1 to 12, k ⁇ m. It will be appreciated that k and m do not necessarily take all possible values between 1 and 12, as each node 110 j is not necessarily linked to all the other nodes 110 j of the network 100.
- the network 100 includes the nodes 120 1 2 , 120 23 , 120 2)6 , 120 28 , 120 2,9 , 120 3,4 , 120 3 ⁇ 6 , 120 4>5 , 120 4>7 , 120 4,8 , 120 4>9 , 120 5;7 , 120 5)9 , 120 6>7 , 120 6>12 , 120 10>12 , 120 1011 and 120 11 12 .
- the reader skilled in the art will of course appreciate that the present invention could be implemented in a network having a number of nodes 110 j greater or smaller than 12.
- the network 100 has a limited number of links 120 km .
- Link 120 KM allows data traffic to be exchanged between nodes 110 ⁇ and 110 M .
- the reader skilled in the art will however appreciate that the present invention can also be implemented in a network 100 having a plurality of links 120 ⁇ m differing from those illusfrated.
- Each node HOj can include a switch, a router or other type of network equipment that can exchange data traffic with other network nodes through the links 120 km
- a plurality of routes for conveying data traffic are defined. Each route fraverses a respective ordered set of nodes selected from the plurality of nodes HO j .
- a route PI can be a label-switched path (LSP) that fraverses the ordered set of nbdes ⁇ 110 l5 110 2 , 110 3 , 110 4 , 110 5 ⁇ .
- LSP label-switched path
- data traffic is conveyed from the node HO j to the node 110 5 through the nodes 110 2 , 110 3 and 110 4 , using the links 120 12 , 120 23 , 120 34 and 120 45 .
- the routes are label switched paths (LSPs), although this is not to be construed as a limitation of the types of routes to which the present invention applies.
- routes are said to convey data packets, although it should be understood that it is actually the nodes 110 j and the links 120 ⁇ m along a particular route that handle the data packets.
- a route is said to convey a particular data packet if the particular data packet is conveyed successively through the nodes 110 j defining that route.
- node 110 2 An example structure of node 110 2 is shown on Figure 2.
- the other nodes 110 l3 110 3 , etc. have a structure similar to node 110 2 .
- the node 110 2 includes X input interfaces 210 x , x varying from 1 to X, and Y output interfaces 220 y , y varying from 1 to Y.
- the input interfaces 210 x are shown separately from the output interfaces 220 y on Figure 2, the reader skilled in the art will appreciate that this has been done for clarity and that the input interfaces 210 x and the output interfaces 220 y could be implemented in the form of bidirectional (input/output) interfaces.
- Node 110 2 further includes a switch matrix 230 and a node controller 240 linked to the switch matrix 230 through a control link 250.
- the input interfaces 210 x accept data traffic incoming from the network 100 while the output interfaces 220 y release data traffic outgoing to the network 100.
- the switch matrix 230 under the control of the node controller 240, allows data traffic to be switched through node 110 2 from the input, interfaces 210 X to the output interfaces 220 y .
- the data traffic is exchanged between the nodes in the form of data packets. Since node 110 2 may have sufficient capacity to process data packets from different LSPs, more than one LSP could require the switching services of node 110 2 .
- each input interface 210 x and each output interface 220 y could convey data packets along different LSPs. Accordingly, the switch matrix 230 and the node confroller 240 are adapted to process the data traffic passing through node 110 2 on a packet-by-packet basis.
- Each packet transmitted along a particular LSP includes a header designating a label that identifies the particular LSP.
- the label may be a single number or a character string, for example.
- the switch matrix 230 and the node confroller 240 are adapted to switch each data packet according to the label that it designates.
- the node controller 240 may also have the capability to process data packets which do not necessarily include a label according to standard protocols.
- the sequence of nodes through which a data packet has to be conveyed is predetermined by the LSP in that packet's label.
- the switch matrix 230 conveys data traffic from the input interfaces 210 x to the output interfaces 220 y , so that each data packet is forwarded to a respective destination node in the network, until the packet reaches its ultimate destination. For example, a packet carrying the label PI and incoming at node 110 2 has to be forwarded to the node 110 3 over the link 120 23 on its way to the ultimate destination of node 110 5 .
- the output interface of node 110 2 to which the data packet is forwarded by the switch matrix 230 of node 110 2 is an input interface connected to the link 120 23 .
- the switch matrix 230 switches the data packets received by node 110 2 under the control of the node confroller 240.
- the node confroller 240 is adapted to provide "protection" for at least some of the LSPs that pass through the node 110 2 .
- “provide protection” is meant the provision of an alternate route for data in the event of link or node failures on a portion of the network further downsfream along that LSP.
- the node confroller 240 is a computing device that includes a CPU 310, a memory 320 and a bus 330.
- the CPU 310 is adapted to execute software in the form of a program element.
- the program element is adapted to perform a method for providing protection for at least some of the LSPs that pass through a node of interest, an example of such method being described in greater detail below.
- the memory 320 holds the program element in addition to any data that needs to be kept readily available to node 110 2 .
- the memory 320 can include a memory chip, a magnetic storage medium such as a hard disk, an optical storage medium or any other suitable memory.
- memory 320 is shown as a single functional block, the reader skilled in the art will appreciate that memory 320 can include two or more physical components selected from the previous list of memory types.
- the bus 330 connects the CPU 310, the memory 320 and the control link 250 so that data can be exchanged between these components.
- the present invention is particularly concerned with providing protection of an LSP transiting through a node of interest in the event of a link or node failure of a portion of the network that is located further downsfream along that LSP.
- the invention applies to an LSP that merely transits through the node of interest without originating therefrom.
- node 110 2 is adapted to protect a downsfream portion of the LSP PI in the event of a failure of link 120 23 and subsequent nodes or links. This is achieved by selecting an alternate route for data from the perspective of node 110 2 .
- This alternate route is definable by a series of links and nodes assigned to LSP PI and will hereinafter be referred to as a. "tunnel route”.
- the method of the present invention also includes storing data elements in a memory, where each data element is representative of, on the one hand, an LSP that is protected in the event of link or node failures further downsfream along that LSP and, on the other hand, a tunnel route originating at the node of interest and assigned to protect that LSP.
- each data element in the memory is representative of, on the one hand, an LSP protected in the event of downstream link or node failures (i.e., starting at link 120 2>3 ) and, on the other hand,
- ⁇ an individual tunnel route originating at node 110 2 that is assigned to protect that LSP.
- the data elements are rows in a table.
- a tunnel route By being assigned to protect a given LSP transiting a node of interest in the event of downsfream link or node failures, a tunnel route essentially provides an alternate path for traffic having the given LSP's label. It should be appreciated that if multiple LSPs transit the node of interest and share a common downsfream physical portion of the network, then either the same tunnel route or different tunnel routes can be assigned to protect the multiple LSPs in the event of link or node failures along that common downstream physical portion of the network. With continued reference to Fig. 1, a specific example of implementation of the method for provisioning protection in the network 100 in accordance with an embodiment of the present invention is now considered.
- the protection problem is viewed from the perspective of node 110 2 and LSP PI.
- the method may be performed by a program element executed by the CPU 320 that is included in the node 110 2 .
- a CPU remote from the node 110 2 can execute the program element and the results transmitted to node 110 2 .
- LSP PI has already been created between nodes 110, and 110 5 through nodes 110 2 , 110 3 and 110 4 . Basically, this involves an exchange of messages between these nodes such that each node becomes operative for switching data packets having a label identifying LSP PI to the next node downsfream. Protocols for creating a LSP are well known in the art and will not be discussed in further detail.
- a tunnel route can be assigned to protect LSP PI in the event of a failure of the aforementioned node or links.
- the purpose of the tunnel route so assigned is to convey the data traffic ordinarily conveyed along the LSP PI in case of a failure of node 110 3 or of links 120 2 , 3 or 120 34 .
- many possible tunnel routes could be selected to protect the LSP PI in the event of a failure further downstream along LSP PI. The choice of tunnel route will therefore be based on criteria associated with the protection policy being implemented.
- each LSP is generally associated with a service criterion in the form of a minimal bandwidth requirement.
- the minimal bandwidth requirement associated with an LSP e.g., LSP PI
- LSP PI is a minimal bandwidth that is required to convey the data traffic via the links and nodes situated along LSP PI .
- the required bandwidth is reserved for conveying exclusively data packets including a label identifying the LSP PI.
- a tunnel route that protects LSP PI in the event of a downsfream link or node failure should be capable of supporting the reservation of bandwidth resources in order to accommodate the minimal bandwidth requirement associated with LSP PI.
- the bandwidth is to be reserved in all the nodes 110 j defining the tunnel route and all the links 120 ⁇ m between the nodes 110 j defining the tunnel route for the exclusive use of data traffic conveyed through the tunnel route.
- bandwidth required by the tunnel route is readily available in case of a failure of a downsfream portion of the network 100 traversed by LSP PI, the bandwidth required for the tunnel route cannot be used for other purposes, even when the tunnel route is not in the process of conveying data traffic. Therefore, bandwidth in the network 100 will be reserved both for normal data traffic (to cover the case where there has been no failure in the network 100) and for protection data traffic (to cover the case where there has been a failure in the network 100).
- the minimal bandwidth requirement can also be a minimal bandwidth requirement for the data traffic conveyed by more than one LSP traversing a node 110j or a link 120 KM .
- LSP PI remains as previously defined.
- a second LSP P2 is defined to fraverse nodes 110 6 , 110 2 , 110 3 , 110 4 and 110 9 via links 120 2>6 , 120 2>3 , 120 3>4 and 120 4;9 .
- both LSP PI and LSP P2 fraverse a common portion of the network 100 consisting of nodes 110 2 , 110 3 and 110 4 , as well as links 120 23 and 120 34 .
- the service criterion associated with each LSP and the resources included in each tunnel route are implementation features that are not critical to the invention.
- the program element in the CPU running the method receives a protection setup request which identifies an LSP.
- the LSP of interest is LSP PI and the node of interest is node 110 2 .
- the protection setup request can be sent when LSP PI is created.
- a protection setup request arrives at node 110 2 from the node upstream from the node 110 2 (relative to the LSP in question), which is the node 110, for LSP PI.
- the protection setup request can also be generated internally to node 110 2 .
- the explicit receipt of a protection setup request message is not essential to the present invention.
- the node 110 2 (or any other intermediate node along an LSP of interest) attempts to provide protection for every new LSP that is established through that node.
- node 110 2 attempts to provide protection for an LSP in response to a parameter transmitted in an LSP creation message.
- the parameter can be a single bit which indicates whether protection is required or not for a new LSP to be established.
- Other suitable parameters will be readily apparent to the reader skilled in the art. In this sense, by "received", it is meant that the protection setup request is received at the CPU running the method of Fig. 4.
- the node 110 2 is in operation and already has assigned certain tunnel routes to the protection of various LSPs in the event of downsfream link or node failures along the respective. LSPs. It is recalled that such tunnel routes and the LSPs they are assigned to protect can be stored in a table in memory as previously described. However, the reader skilled in the art will appreciate that the illusfrated method could be applied even if this table is empty, as would be the case if the node 110 2 had just been reset or powered on.
- the program element searches the list of existing tunnel routes to find a sublist of existing tunnel routes that "qualify" to protect LSP PI.
- a tunnel route "qualifies” to protect LSP PI if (1) its end points are two nodes 110 R and 110 s that belong to LSP PI and (2) it does not contain the next downsfream node along the LSP PI . In other words, a qualifying tunnel route must branch off from and eventually merge with the LSP PI and the next downsfream node along the LSP PI must not belong to the tunnel route.
- An example of an existing tunnel route which would "qualify" to protect the downsfream portion of the network for LSP PI from the perspective of node 110 2 would be an existing tunnel route that included nodes 110 2 , 110 8 and 110 4 .
- a tunnel route would also qualify to protect the LSP PI in the event of a downstream failure of node 110 3 if it were made up of a direct link between nodes 110 2 and 110 4 .
- the program element restricts the protection of LSP PI to those existing tunnel routes for which all the constituent nodes, except for the first and last nodes of the tunnel route, are not traversed by the LSP PI . In this way, the protection provided by such a tunnel route is maximized because a downsfream link or node failure along LSP PI will not prevent the tunnel route from conveying data traffic.
- the program element restricts to the protection of LSP PI to those existing tunnel routes for which the last (terminating) node is as close as possible to the first node in the nodes defining LSP PI, while still respecting the above conditions. As a result, the shortest possible portions of LSPs are protected.
- an existing tunnel route will not qualify to protect an LSP if it is made up of a number of nodes that exceeds a predetermined number. Therefore, in such an example of implementation, the node 110 2 does not consider a tunnel route as qualified to protect an LSP if such tunnel route is made up of a number of nodes which exceeds the predetermined number.
- step 430 the program element determines whether step 420 was successful. Specifically, the program element determines whether at least one existing tunnel route qualifies to protect the LSP PI against an immediate downsfream link or node failure. If so, the program element jumps to step 432; otherwise, the program element performs step 470, which is discussed later on in greater detail.
- the program element isolates from the sublist of qualifying tunnel routes those tunnel routes that can accommodate the minimal bandwidth requirement of LSP
- step 433 the program element determines at step 433 if at least one tunnel route was found at step 432. In the case in which step 433 reveals that step 432 was a success, step 434 is performed by the program element, otherwise step 450 (to be described later) is performed.
- a particular tunnel route from the tunnel routes identified at step 432 is selected to protect the LSP PI and the minimal bandwidth required by the LSP PI is reserved.
- the program element stores in the memory 320 a data element representative of the assignment of the tunnel route Tl to the protection of the LSP P 1 and the method ends.
- the particular tunnel route selected is the first tunnel route found by the program element to satisfy the conditions of step 433.
- a shortest tunnel route is selected to protect the LSP PI and, if applicable, to protect additional LSPs that were protected by the tunnel route prior to its selection for the protection of the LSP PI.
- the shortest tunnel route can be the tunnel route that is made up of the smallest number of nodes.
- the shortest tunnel route can be a tunnel route wherein a propagation time for data is minimized. Therefore, while the term shortest is used in the specification, the reader skilled in the art will appreciate that the selected route can be any route that satisfies a suitable optimization criterion.
- the particular optimization criterion is not critical to the present invention.
- step 433 had revealed that no tunnel route was selected at step 432, then this means that the tunnel routes in the sublist of qualifying tunnel routes found at step 410 are existing tunnel routes which (1) qualify to protect the LSP PI against immediate downsfream link or node failures; (2) by virtue of being existing, are assigned to the protection of at least one additional LSP; and (3) involve network resources capable of accommodating the minimal bandwidth requirements associated with those additional LSPs.
- the network resources involved in these tunnel routes are insufficient to accommodate the minimal bandwidth requirement of LSP PI.
- such tunnel routes are said to be "saturated" tunnel routes with respect to LSP PI and it is entirely possible that such tunnel routes would not be saturated with respect to a different LSP having less stringent minimal bandwidth requirements.
- the program element performs step 450, whereby the sublist of qualifying tunnel routes is searched in an attempt to replace one of the tunnel routes that is saturated with respect to LSP PI.
- the replaced tunnel route should (1) qualify to protect LSP PI; (2) involve resources capable of accommodating the service criterion of LSP PI in addition to the service criteria associated with the LSPs currently protected by the saturated tunnel route being replaced; and (3) not consist of any additional node that is traversed by any of the LSPs currently protected by the saturated tunnel route being replaced route if those nodes are part of the LSP segment that is being protected by that tunnel route.
- Known methods used in creating new LSPs in the network 100 can be relied upon to determine whether it is possible to replace an existing tunnel route in the desired fashion. Note that the last node of the new tunnel must be the last node of the saturated path being replaced.
- the new (replacement) tunnel route is required to fraverse none of the nodes traversed by a saturated tunnel route, except for the first and last node of the saturated tunnel route. Therefore, the new tunnel route is more likely to consume unreserved bandwidth as the nodes which make up saturated tunnel routes are avoided.
- the last node of the new tunnel route is required to be the last node of the saturated tunnel route being augmented.
- the program element determines whether its search (step 450) revealed that a saturated tunnel route was amendable to replacement. In the affirmative, the program element executes step 465, wherein that specific tunnel route is in effect selected as the one to be replaced. If many of the existing but saturated tunnel routes are amenable to replacement by many possible replacement tunnel routes, selection of one particular tunnel route to replace one particular saturated tunnel route can be performed according to the criteria already described with respect to step 434.
- a bandwidth corresponding to the minimal bandwidth requirement associated with the LSPs previously protected by the saturated tunnel route in addition to the simultaneous minimal bandwidth requirement of the LSP PI is reserved in the nodes 110 j and links 120 ⁇ m defining the new (replacement) tunnel route.
- the saturated tunnel route is deleted from the list of tunnel routes and the program element stores in the memory 320 a data element representative of the new tunnel route for the protection of the LSP PI and of the LSPs formerly protected by the saturated tunnel route.
- step 460 if step 460 revealed that no new tunnel route could be established to protect LSP PI while protecting also other LSPs in the case of step 460, then the program element proceeds to step 470, which is the same step to be performed if step 430 revealed that no suitable tunnel route could be found to protect LSP PI .
- Step 470 thus consists of attempting to create a completely new tunnel route which would serve to protect only LSP PI. Since all the other tunnel routes that were found at steps 460 and 430 could not accommodate the bandwidth requirement of LSP PI, the new tunnel route will include at least one node excluded from any saturated tunnel route (i.e., saturated with respect to LSP PI) and also excluded from the tunnel routes in the sublist of qualifying tunnel routes.
- step 480 the program element then determines if at least one new tunnel route was indeed found at step 470 and, in the affirmative, proceeds to step 434 wherein a list of tunnel routes found at step 470 is processed in the same manner as any list of tunnel routes produced at step 430 would be processed. Specifically, steps 434 selects a tunnel route that involves resources capable of accommodating the bandwidth requirement of LSP PI.
- step 480 if step 480 reveals that no tunnel route can be found to protect LSP PI, the process is restarted.
- restarting of the process may be delayed by a timer which is started at step 490. After a predetermined period of time measured by such timer, at step 492, the first program component re-attempts to select a tunnel route to protect LSP PI by returning to step 420.
- the resources reserved to accommodate a particular tunnel route are the largest resources required to effect protection while accommodating, the service criteria of the protected LSPs in the case of a single node or link failure in the network, and not the largest resources required to effect protection while accommodating the service criteria of all the LSPs assigned for protection by the particular tunnel route.
- LSP P3 is also defined in the networks as a LSP between nodes 110, and 110 5 passing through nodes 110 2 , 110 8 and 110 4 .
- a particular tunnel route T2 between nodes 110 2 and 110 4 passing through node 110 9 is selected to protect the LSPs PI and P3.
- the service criteria associated with LSPs PI and P3 are a minimal bandwidth requirement of B bandwidth units.
- LSPs typically have a finite time during which they are needed.
- an LSP delete message is propagated through the nodes 110 j defining the deleted LSP. It is then highly desirable, to preserve resources in the network 100, that when a node 110 j receives the LSP delete message, the program element de-selects the deleted LSP from the protecting tunnel route to which it was assigned for protection. In addition, the program element frees the resources reserved for the deleted LSP in the protecting tunnel route. If the deleted LSP is the only LSP assigned for protection by the protecting tunnel route, the program element is operative for removing the protecting tunnel route from the list of tunnel routes.
- the program element is also operative for detecting failures in the protected LSPs. Upon detecting a failure in the portion of a given LSP which a particular tunnel route has been selected to protect in the event of downsfream link or node failures, the program element redirects over the particular tunnel route the data fraffic conveyed by the given LSP.
- a tunnel route e.g., tunnel route Tl
- a tunnel route Tl is assigned to the protection of many LSPs, e.g., LSPs PI, P2 and P3.
- the program component Upon the detection of a failure in the portion of one of the LSPs, e.g., LSP PI protected by the particular tunnel route, e.g., a failure of the node 110 3 , the program component is operative for redirecting the data fraffic conveyed by all the LSPs PI and P2 protected by the tunnel route Tl and including the point of failure in the network over the tunnel route Tl.
- the program element redirects the failed LSPs through stacking a redirection label to the data packet.
- Label stacking is well known in the art and will therefore not be described in further detail.
- each tunnel route and each LSP is characterized by a hold priority level and by a setup priority level stored in the memory.
- the tunnel route Tl can be deleted to allow the LSP PI to reserve the resources already reserved if the LSP PI has a higher priority level than the tunnel route Tl.
- the setup priority level and the hold priority levels each have the same purpose except that the setup priority level is a priority level characterizing a LSP or a tunnel route during its creation while the hold priority level characterized the LSP or the tunnel route after its creation.
- the program element can be enabled to delete a tunnel route, e.g., tunnel route Tl, from the list of tunnel routes if the setup priority level of the LSP P3, is higher than the hold priority level of the tunnel route Tl.
- the priority levels define the relative importance of the LSP and tunnel routes.
- the hold priority level of the particular tunnel route may be increased. This increase is desired because the particular tunnel route then conveys data fraffic which cannot be redirected elsewhere (as the protection is provided). If a new LSP to be created were then to be characterized by a setup priority level higher than the setup priority level of the particular tunnel route, the particular tunnel route would be deleted and the data fraffic conveyed over the particular tunnel route would stop being transmitted. To prevent this type of situation, the hold priority level is preferably increased to a maximal possible value. It should also be appreciated that the protection request message can be a new LSP creation message including a setup priority level above a predetermined threshold.
- the particular tunnel route instead of deleting a particular tunnel route from the list of tunnel routes when it stops protecting any LSP, it is possible to keep the particular tunnel route in the list of tunnel routes and to change its hold priority level to a very low priority level. Therefore, if the particular tunnel route needs to be called upon to protect an LSP at a later time, it will already be present in the list of tunnel routes and therefore the selection will be faster than if a new tunnel route had to be found in the network 100. Meanwhile, if the bandwidth reserved for the particular tunnel route is needed, for example to accommodate the creation of a new LSP, the low hold priority level characterizing the particular tunnel route would allow the newly created LSP to reserve this bandwidth due to the setup priority level characterizing the new LSP being higher than the hold priority level characterizing the particular tunnel route.
- each label in addition to being identified by a label associated with a given LSP, the data packets conveyed in the network 100 by the LSPs are also identified by an interface identification specifying the input interface at which they arrive. Accordingly, each label can be used for a plurality of LSPs arriving at a certain node without creating confusion between the LSPs, under the condition that different LSPs sharing a label arrive at the certain node via different interfaces. In this case, each protected LSP and the tunnel route selected for its protection will arrive at a respective attachment node through different interfaces.
- the attachment node will not be able to differentiate between the data packets of the various LSPs which arrive through the tunnel route.
- the present invention to define a new object in the protocol of choice, for example, to define a new "label synchronization object" in RSVP.
- a new "label synchronization object” in RSVP is used to obtain label mappings from the interface where the tunnel route ends for all the LSPs that are deemed protected by this tunnel route.
- the "label synchronization object” can be added to the PATH messages of the tunnel route if the "Global Label” flag in the "Label Record” sub-object add to the RRO in the Resv message of the protected LSP by the node were the tunnel route and the protected LSP merge is not set. It may contain an entry for each LSP mapped to this tunnel route that does not have a label mapping from the interface that is the egress point of the tunnel route. When the tunnel route is initiated (i.e. when the first PATH message is sent) this object will have one only entry.
- Each entry may have four fields, an LSP ID which has a local meaning to the interface that has sent the PATH message, the IP address of the interface that provided the mapping for this LSP (i.e. the interface where the data packet will arrive if they are not rerouted - this may be an interface on the node that is the egress node of the tunnel route), a flag field and the label that the previously mentioned interface has assigned to this LSP (because of the per-interface label space, this label is meaningful only to the interface that has assigned it).
- Routers that do not support this object will pass it unchanged downsfream, also routers that do support this extension and are not the egress node of the tunnel route forward this object unchanged downstream.
- the label space should be zero.
- the egress node of the tunnel route will use the interface id and the label in each entry to do a look up in the ilm table to find the output interface and the output label of this LSP. It will then assign another label to this LSP and add a new entry to the ilm with the new input label (and new interface id) and the old output label and output LSP. This new label is added to the label field in the "label synchronization object" and the object is sent back to the ingress node in the Resv message.
- each interface has its own ilm then the interfaces should communicate so that the output label and the output interface can be known to the interface receiving the PATH message of the tunnel route.
- the source node receives the Resv message with the Label synchronization object, it will enter the label for each LSP in the "LTBT" table. This is the label that will be used by the ingress node in the label stack when rerouting the LSPs.
- the ingress node can send a new PATH message for the tunnel route with a new "label synchronization object" that contains an entry for the new LSP. The LSP is not mapped to the tunnel route until the new mapping is received.
- the ingress node After receiving a mapping from the egress interface of the tunnel route for a specific LSP, the ingress node need not keep sending label synchronization requests for that LSP in future PATH messages. This will help keep the size of the "label synchronization object" small regardless of the number of LSPs mapped to the tunnel route, and will reduce computation time at the egress interface.
- the ingress node When an LSP is deleted, the ingress node sends a "label synchronization object" in the future tunnel route PATH message with an entry that has the flags field set to one.
- the IP address field in this case should be the address of the interface that is the target of the PATH message (i.e. the tunnel egress point), the label field should have the label that was assigned by tunnel egress interface to the deleted LSP (the label to be released), and the LSP ID is the same as the one sent in the label synchronization request.
- the egress interface sends back the same entry in a "label synchronization object" in the next tunnel route Resv message, the ingress node interprets that as a confirmation that the label has been released. If the ingress interface does not receive that entry in the Resv message, it should keep sending it in the next PATH messages until the entry in received in a Resv message. It should be understood that label synchronization requests and label releases can be sent together in the same "label synchronization object". When a tunnel route is deleted for any reason, the egress LSP considers it also as a label release for all the labels associated with that tunnel route and the egress node should not expect specific label releases for each label.
- the above described method is an improvement over specifying a global label space for protected LSPs, because with this method two per-interface labels are used for each LSP, while a global label is equivalent to "N" per-interface labels, where "N” is the number of interfaces. More importantly, if a global label space were used for protected LSPs and its access was controlled by a global controller, each interface will be required to send the label request to the global confroller and wait for the mapping. This could lead to a bottleneck problem at the global controller if the number of interfaces is large.
- each interface before sending a label mapping would communicate with all the other interfaces to make sure that no other interface is using (or will be using) the same label, and similar communication will also be needed when labels are released.
- Length a field containing the total object length
- Class-Num class "label synchronization object"
- a non-limiting example of a suitable body for the "label synchronization object" is a plurality of entries, each entry being as follows: LSP ID: A locally significant LSP ID assigned by the ingress interface of the tunnel route. May be returned unchanged in the Resv message, and may be the same as the label value sent with the label synchronization request.
- IPv4 The ip address of an interface on the egress node of the tunnel. This is the interface that received the PATH message and assigned the label for the protected LSP. May be returned unchanged in the Resv message.
- Flags for label synchronization request and label release.
- Label A 20 bit field that when in a PATH message specifies the label that was assigned by the interface defined in the previous entry for an LSP that will be mapped to the tunnel route signaled by this PATH message.
- the interface that will receive the PATH message at the egress node replaces this label with another label selected locally and returns the object in the Resv message back to the ingress node.
- the ingress node does not receive the "label synchronization object" in the Resv message after sending one in the PATH message, this means that the egress node does not support this extension.
- one possible solution to the per-interface problem is to extend the tunnel route by one node after the merge node. By doing so, the bottom label that is used in the label stack when fraffic is redirected (i.e. the label retrieved from the RRO from the protected LSPs' Resv message) will be the label sent upstream by a node further downsfream. And when the fraffic is redirected, this label will still be received (with the data packets) on the same interface on the node further downsfream, and so the label will be recognized correctly.
- the invention reduces the number of paths that must be created to protect new LSPs, as individual protection paths associated with every new created LSP do not need to be established. This facilitates the management of protection, especially in the case where the LPSs are each associated with a service criterion that must be maintained in case of a failure of the LSP.
- the management of protection is easier than if the protection was provisioned for the entire LSP from a single node.
- the tunnel routes can be easily reassigned to protect the LSPs when new LSPs require protection and when LSPs are deleted.
- the tunnel routes can be dynamically selected to protect the various LSPs without affecting these LSPs.
- the management of tunnel routes only involves a small number of nodes which are in close proximity to one another in the network 100, thereby mimmizing propagation delays in messages exchanged by these nodes.
- LSP label-switched path
- all or part of the functionality previously described herein with respect to the program element may be implemented as pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components.
- ASICs application specific integrated circuits
- EEPROMs electrically erasable programmable read-only memories
- all or part of the functionality previously described herein with respect to the program element may be implemented as software consisting of a series of instructions for execution by a computer system.
- the series of instructions could be stored on a medium which is fixed, tangible and readable directly by the computer system, (e.g., removable diskette, CD-ROM, ROM, or fixed disk), or the instructions could be stored remotely but fransmittable to the computer system via a modem or other interface device (e.g., a communications adapter) connected to a network over a transmission medium.
- the transmission medium may be either a tangible medium (e.g., optical or analog communications lines) or a medium implemented using wireless techniques (e.g., microwave, infrared or other transmission schemes).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2002322223A AU2002322223A1 (en) | 2001-07-25 | 2002-07-25 | Apparatus and method for establishing tunnel routes to protect paths established in a data network |
US10/484,620 US20060036892A1 (en) | 2001-07-25 | 2002-07-25 | Apparatus and method for establishing tunnel routes to protect paths established in a data network |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US30737301P | 2001-07-25 | 2001-07-25 | |
US60/307,373 | 2001-07-25 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2003010923A2 true WO2003010923A2 (en) | 2003-02-06 |
WO2003010923A3 WO2003010923A3 (en) | 2003-06-19 |
Family
ID=23189472
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CA2002/001164 WO2003010923A2 (en) | 2001-07-25 | 2002-07-25 | Apparatus and method for establishing tunnel routes to protect paths established in a data network |
Country Status (3)
Country | Link |
---|---|
US (1) | US20060036892A1 (en) |
AU (1) | AU2002322223A1 (en) |
WO (1) | WO2003010923A2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2876525A1 (en) * | 2004-10-08 | 2006-04-14 | France Telecom | METHOD AND DEVICE FOR CREATING A TUNNEL IN A LABEL SWITCHED TELECOMMUNICATION NETWORK |
WO2006066596A2 (en) | 2004-12-22 | 2006-06-29 | Novozymes A/S | Hybrid enzymes consisting of an endo-amylase first amino acid sequence and a carbohydrate -binding module as second amino acid sequence |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4328478B2 (en) * | 2001-08-27 | 2009-09-09 | 富士通株式会社 | Route changing method, label switching node and management node in label transfer network |
US7283466B1 (en) * | 2002-10-25 | 2007-10-16 | Ciena Corporation | Tracking physical route changes in optical switching network |
JP2004318743A (en) * | 2003-04-21 | 2004-11-11 | Hitachi Ltd | File transfer device |
US7477642B2 (en) * | 2004-02-03 | 2009-01-13 | Redback Networks, Inc. | MPLS traffic engineering for point-to-multipoint label switched paths |
TWI240520B (en) * | 2004-03-26 | 2005-09-21 | Ascen Vision Technology Inc | Packet processing apparatus and method |
US8107379B2 (en) * | 2005-05-04 | 2012-01-31 | Cisco Technology, Inc. | Dynamic TE-LSP priority and preemption |
DE102005035201B4 (en) * | 2005-07-27 | 2009-02-26 | Siemens Ag | Network node unit and method for forwarding data packets |
US7924875B2 (en) * | 2006-07-05 | 2011-04-12 | Cisco Technology, Inc. | Variable priority of network connections for preemptive protection |
US7826367B2 (en) * | 2007-06-28 | 2010-11-02 | Verizon Patent And Licensing Inc. | Systems and methods for protecting a trunk with multiple trunks |
US8327017B1 (en) * | 2008-03-12 | 2012-12-04 | United Services Automobile Association (Usaa) | Systems and methods for an autonomous intranet |
US9112791B2 (en) * | 2009-02-10 | 2015-08-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and apparatus for protecting a communications network |
US9497114B2 (en) * | 2013-11-14 | 2016-11-15 | AT&T Intellectual Propery I, L.P | Label stack identification for lawful interception of virtual private network traffic |
US10021017B2 (en) | 2015-03-18 | 2018-07-10 | Futurewei Technologies, Inc. | X channel to zone in zone routing |
US9998368B2 (en) * | 2015-06-11 | 2018-06-12 | Futurewei Technologies, Inc. | Zone routing system |
US10637775B2 (en) * | 2015-10-17 | 2020-04-28 | Cisco Technology, Inc. | Make-before-break mechanism for label switched paths |
EP3588857B1 (en) | 2018-06-25 | 2023-06-07 | Juniper Networks, Inc. | Using multiple ethernet virtual private network (evpn) routes for corresponding service interfaces of a subscriber interface |
US10693679B2 (en) * | 2018-06-25 | 2020-06-23 | Juniper Networks, Inc. | Using multiple ethernet virtual private network (EVPN) routes for corresponding service interfaces of a subscriber interface |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7380017B2 (en) * | 2001-05-03 | 2008-05-27 | Nortel Networks Limited | Route protection in a communication network |
-
2002
- 2002-07-25 AU AU2002322223A patent/AU2002322223A1/en not_active Abandoned
- 2002-07-25 US US10/484,620 patent/US20060036892A1/en not_active Abandoned
- 2002-07-25 WO PCT/CA2002/001164 patent/WO2003010923A2/en not_active Application Discontinuation
Non-Patent Citations (7)
Title |
---|
"Index of IETF Drafts as stored on IETF servers" IETF INDEX OF DIRECTORY, [Online] XP002237849 Internet Retrieved from the Internet: <URL: search.ietf.org:21> [retrieved on 2002-04-05] * |
AWDUCHE D O ET AL: "RSVP-TE: Extensions to RSVP for LSP Tunnels" IETF, 1 February 2001 (2001-02-01), XP002199928 Retrieved from the Internet: <URL:http://www.awduche.com/> [retrieved on 2002-05-15] * |
GAN D-H ET AL: "A Method for MPLS LSP Fast-Reroute Using RSVP Detours" IETF, 10 April 2001 (2001-04-10), XP002224746 Retrieved from the Internet: <URL:http://www.watersprings.org/links/mlr /id/draft-gan-fast-reroute-00.txt> [retrieved on 2002-12-11] * |
HASKIN,KRISHNAN: "a method for setting an alternative label switched paths to handle fast reroute, draft-haskin-mpls-fast-reroute-01.txt" IETF - DRAFT-HASKIN-MPLS-FAST-REROUTE-01.TXT, - 1 June 1999 (1999-06-01) XP002237848 * |
PAN P ET AL: "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" IETF, January 2002 (2002-01), XP002222575 Retrieved from the Internet: <URL:http://www.watersprings.org/pub/id/dr aft-ietf-mpls-rsvp-lsp-fastrerou te-00.txt> [retrieved on 2002-11-26] * |
SHARMA V ET AL: "Framework for MPLS-based Recovery" IETF, March 2001 (2001-03), XP002219128 Retrieved from the Internet: <URL:http://www.ietf.org/proceedings/01mar /I-D/mpls-recovery-frmwrk-02.txt> [retrieved on 2002-10-31] * |
SWALLOW, GOGUEN: "RSVP label allocation for Backup Tunnels - draft-swallow-rsvp-bypass-label-01.txt" IETF - DRAFT-SWALLOW-RSVP-BYPASS-LABEL-01.TXT, 30 November 2000 (2000-11-30), XP002237847 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2876525A1 (en) * | 2004-10-08 | 2006-04-14 | France Telecom | METHOD AND DEVICE FOR CREATING A TUNNEL IN A LABEL SWITCHED TELECOMMUNICATION NETWORK |
WO2006040430A1 (en) * | 2004-10-08 | 2006-04-20 | France Telecom | Method and device for creating a tunnel in a label-switched telecommunication network |
US7852840B2 (en) | 2004-10-08 | 2010-12-14 | France Telecom | Method and device for creating a tunnel in a label-switched telecommunication network |
WO2006066596A2 (en) | 2004-12-22 | 2006-06-29 | Novozymes A/S | Hybrid enzymes consisting of an endo-amylase first amino acid sequence and a carbohydrate -binding module as second amino acid sequence |
Also Published As
Publication number | Publication date |
---|---|
US20060036892A1 (en) | 2006-02-16 |
AU2002322223A1 (en) | 2003-02-17 |
WO2003010923A3 (en) | 2003-06-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7126907B2 (en) | Label switched communication network, a method of conditioning the network and a method of data transmission | |
CN111385206B (en) | Message forwarding method, network system, related equipment and computer storage medium | |
US20060036892A1 (en) | Apparatus and method for establishing tunnel routes to protect paths established in a data network | |
US7551551B2 (en) | Fast reroute (FRR) protection at the edge of a RFC 2547 network | |
US7035226B2 (en) | Path setup device and method for label switching network | |
US7826461B2 (en) | Packet switching system, packet switching method, routing apparatus, structure of packet, and packet generating method | |
US7209434B2 (en) | Path modifying method, label switching node and administrative node in label transfer network | |
US6970464B2 (en) | Method for recursive BGP route updates in MPLS networks | |
US7570649B2 (en) | Forwarding state sharing between multiple traffic paths in a communication network | |
US8917729B1 (en) | Fast reroute for multiple label switched paths sharing a single interface | |
US7133358B2 (en) | Failure control unit | |
US20050010685A1 (en) | Method and a system for enabling data to be stored in a computer network; a method and a system for storing data in a computer network | |
US20120239626A1 (en) | Method and Apparatus for Restoring Service Label Information | |
WO2006017982A1 (en) | A rerouting method in the multi-protocol label switch network | |
US20090041019A1 (en) | Multi-protocol label switching | |
US7463580B2 (en) | Resource sharing among network tunnels | |
US7647425B2 (en) | Efficient intra-domain routing in packet-switched networks | |
US20040090963A1 (en) | Communication control system, communication control method, routing controller and router suitably used for the same | |
US20050094636A1 (en) | Multi protocol label switching apparatus and method for forwarding IP/label-switched hybrid data | |
WO2010109895A1 (en) | Routing device, communications system, and routing method | |
JP2002368787A (en) | Explicit path designation relay device | |
JP6344005B2 (en) | Control device, communication system, communication method, and program | |
JP2022538527A (en) | Method and apparatus for routing traffic along IGP shortcut paths | |
CN116566894A (en) | Data routing method, device, electronic equipment and storage medium | |
CN114095552A (en) | BFD session establishment method, equipment and system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VN YU ZA ZM |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
ENP | Entry into the national phase |
Ref document number: 2006036892 Country of ref document: US Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10484620 Country of ref document: US |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase | ||
WWP | Wipo information: published in national office |
Ref document number: 10484620 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |