EP1476991A1 - Methode de protection locale de chemins a commutation d etiq uettes avec partage de ressources - Google Patents

Methode de protection locale de chemins a commutation d etiq uettes avec partage de ressources

Info

Publication number
EP1476991A1
EP1476991A1 EP03727556A EP03727556A EP1476991A1 EP 1476991 A1 EP1476991 A1 EP 1476991A1 EP 03727556 A EP03727556 A EP 03727556A EP 03727556 A EP03727556 A EP 03727556A EP 1476991 A1 EP1476991 A1 EP 1476991A1
Authority
EP
European Patent Office
Prior art keywords
link
path
bypass
protected
failure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03727556A
Other languages
German (de)
English (en)
Inventor
Jean-Louis Le Roux
Géraldine Calvignac
Renaud Moignard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1476991A1 publication Critical patent/EP1476991A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • 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/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
    • 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]
    • H04L45/502—Frame based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/726—Reserving resources in multiple paths to be used simultaneously
    • H04L47/728—Reserving resources in multiple paths to be used simultaneously for backup paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/746—Reaction triggered by a failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS

Definitions

  • the present invention relates to a method for protecting label switched paths in an MPLS (MultiProtocol Label Switching) network. More particularly, the present invention relates to a method of local protection of such paths with sharing of resources.
  • MPLS MultiProtocol Label Switching
  • the MPLS standard published under the auspices of the IETF (Internet Engineering
  • FIG. 1 An MPLS network, 100, comprising a plurality of routers called LSR (Label Switching Routers) such as 110, 111, 120, 121, 130, 131, 140, linked together by IP links.
  • LSR Label Switching Routers
  • Ingress LSR the latter assigns a label (here 24) according to its IP header and concatenates it to said packet.
  • the router that receives the tagged packet replaces the (incoming) tag
  • an LSR router uses the label of the incoming packet (incoming label) to determine the output port and the label of the outgoing packet (outgoing label).
  • router A replaces the labels of the IP packets arriving on port 3 and of value 16 with labels of value 28 and then sends the packets thus relabelled on port 2.
  • LSP Label Switched Path
  • FEC Forward Equivalence Class
  • the MPLS protocol makes it possible to force IP packets to follow a pre-established LSP path which is generally not the optimal IP path in terms of number of hops or path metrics.
  • MPLS-TE MPLS Traffic Engineering
  • the determination of the path takes into account constraints on the available resources (constraint based routing), in particular in bandwidth on the various links of the network.
  • the determination of an LSP path is performed in a so-called explicit mode (explicitly routed LSP or ER-LSP) in which certain or all nodes in the path from the ingress router to the egress router.
  • explicit mode explicitly routed LSP or ER-LSP
  • An explicitly determined path is also called an MPLS tunnel.
  • the determination of one or more MPLS tunnels can be done centrally or distributed.
  • each router is informed about the network topology and the constraints affecting the different network links. To do this, each router determines transmits to its neighbors a message indicating its immediate links and the constraints (or attributes) associated therewith. These messages are then propagated from node to node by extended IGP messages, according to a flooding mechanism until all the routers are informed.
  • each router has its own database (called TED for Traffic Engineering Database) giving it the network topology and its constraints.
  • the determination of the label switching path is then carried out by the ingress router (Ingress LSR) also taking into account other constraints set by the network operator (for example avoiding this or that node or avoiding links of this or that type).
  • the entry router determines, for example by means of the Dijkstra algorithm, the shortest path satisfying all the constraints (Constraint Shortest Path First or CSPF), those affecting the links as those fixed by the operator.
  • This shortest path is then signaled to the nodes of the LSP path by means of the signaling protocols known by the abbreviations RSVP-TE (Resource reSerVation Protocol for Traffic Engineering) or CR-LDP (Constrained Route Label Distribution Protocol).
  • RSVP-TE Resource reSerVation Protocol for Traffic Engineering
  • CR-LDP Constrained Route Label Distribution Protocol
  • the input router A transmits, as shown in Fig. 3A, a “Path” message in an IP packet to the output router F.
  • This message specifies the list of nodes through which the LSP path must pass.
  • the message “Path” establishes the path and makes a reservation of state.
  • an "Resv” acknowledgment message is sent back by the same path to the input router, as shown in Fig. 3B.
  • the MPLS routing table is updated and the resource reservation is made.
  • the resource is a bandwidth and we wish to reserve 10 units (MHz) for the path, the bandwidths respectively allocated to each link are decremented by the value reserved (10) during the backpropagation of the message d 'acquittal / reservation.
  • the resource in question e.g. bandwidth
  • the acknowledgment message is received by the ingress router, the tunnel is established.
  • the determination of the LSP paths can be carried out centrally.
  • a server has knowledge of the network topology and takes into account the constraints on the links and the constraints set by the network operator to determine tunnels between the input routers and the output routers.
  • the input routers are then notified by the server of the tunnel (s) for which they are the input node.
  • the tunnels are then established as shown in Fig. 3A and 3B.
  • the centralized determination method has the advantage of great stability and predictability since only one body performs the preliminary calculation of all the tunnels. In return, it has the drawback of not easily adapting to rapid variations in the network topology, for example in the event of a physical link breaking, deleting the IP links that it supports.
  • tunnels are liable to be destroyed in the event of an underlying physical link being cut. It is then necessary to provide backup mechanisms making it possible to establish a new tunnel between the same entry router and the same exit router. We can distinguish the restoration mechanisms establishing a backup tunnel after the cut and the protection mechanisms pre-establishing a backup tunnel in anticipation of a possible cut.
  • the advantage of the protection mechanisms is that it allows traffic to resume very quickly, as a backup tunnel is already available. In return, they have the disadvantage of mobilizing significant resources from the network. More specifically, the protection mechanisms known from the prior art are divided into local protection methods and end-to-end protection methods. In the former, local backup tunnels are pre-established in anticipation of a failure of an element (node, link) of the initial tunnel. When the failure occurs, traffic is diverted through the local tunnel to bypass the failing element. In end-to-end protection methods, a backup tunnel is established from the ingress router to the egress router. Unlike restoration methods (where backup tunnels are created on demand), protection methods (where backup tunnels are created beforehand) consume network resources.
  • the upstream router which detects and repairs the tunnel failure by directing the packets to the backup tunnel is called PLR point (for "Point of Local Repair”).
  • the router downstream of the failure where the backup tunnel joins the initial tunnel is called point PM (for "Point of Merging”).
  • router C detects the failure of the CD link (symbolized by a lightning bolt) by the absence of RSVP "Hello" messages transmitted at regular intervals on the CD link by router D or by an alert of the physical layer underlying. Router C then redirects traffic from the initial tunnel to the CC'E bypass tunnel.
  • the junction between the initial tunnel and the bypass tunnel is carried out at E.
  • a first method of local protection of LSP path consists in creating for each element of the path to protect a local backup tunnel , also called “detour”. Illustrated in FIG. 5 a one-to-one type of local protection method.
  • Each element K of the path is protected by a detour denoted T (K).
  • T (K) a detour for a node N also protects the upstream link and the link downstream of the node. If the path has n nodes, there can therefore be up to (n-1) detours. If several paths are to be protected in the MPLS network, a series of detours must be provided for each of them. This protection method is therefore not extensible (scalable).
  • detours are created dynamically during the establishment of the path.
  • the detours are created in a distributed manner by the transit routers of the path, on the initiative of the entry router.
  • the detours will not necessarily be the same for the same route.
  • the detours creation procedure requires a modification of the RSVP signaling, as described in the above-mentioned document.
  • an emergency tunnel is provided by the operator to protect one or more elements (node, link) of the MPLS network .
  • Such a bypass tunnel can then be used to rescue a plurality of paths using said item (s).
  • the operator has planned to protect node C by configuring a bypass tunnel with BB'D'D as its path.
  • This bypass tunnel makes it possible to rescue the two paths T t and T 2 in the event of failure of the node C (or of one of the links BC, CD).
  • a bypass tunnel makes it possible to rescue a plurality of paths which intersect it upstream of the failure at a common point PLR and downstream of the failure at a common point PM.
  • the bypass tunnel takes advantage of the possibility of stacking labels (label stacking) by assigning them different levels of hierarchy to redirect packets transparently. More specifically, as shown in FIG. 6, the routers along the path T ⁇ switch the labels 12, 18, 45 and 37. When a failure of the node C occurs, the router B stacks a label (here 67) locally representing the bypass tunnel.
  • the label locally representing the bypass tunnel (here 38) is unstacked so that the point PM receives a label identical to that (45) of a packet which does not would not have been redirected.
  • bypass tunnels are determined beforehand, statically and / or centralized by a server without a priori taking into account the resource requirements of future LSP paths to be established.
  • the bandwidth of the bypass tunnel may not be sufficient to transport the required band of the path to be protected.
  • a bypass tunnel is present, it will not effectively rescue the path to be protected.
  • the problem underlying the invention is to propose a method of protecting LSP paths which consumes fewer resources than the protection methods known in the state of the art, while guaranteeing a high degree of scalability. and a good guarantee of efficiency.
  • the problem is solved by the object of the invention, defined as a method for protecting label switched paths in an MPLS network comprising a plurality of nodes connected by IP links, a path passing through a determined series of nodes. and links of said network, said elements of said path.
  • said bypass path of said second path is selected from a plurality of candidate paths not including said link, the selection being made by testing whether each link in the candidate path has a risk of default independent of the risk of failure of said link to be protected.
  • a group of links of said network affected by the failure of said physical element is determined for each physical element of said network.
  • said bypass path of said second path is selected from a plurality of candidate paths not including said node, the selection being made by testing whether each link of the candidate path presents a risk of failure independent of the risk of link failure, known as the upstream link, joining the node (PLR) upstream of said node to be protected and this latter node.
  • PLR node
  • Fig. 1 illustrates an MPLS network known from the state of the art
  • Fig. 2 schematically illustrates the creation of a switched label path
  • Fig. 3 A schematically illustrates a first phase of the procedure for establishing an LSP path
  • Fig. 3B schematically illustrates a second phase of the procedure for establishing an LSP path
  • Fig. 4 schematically illustrates the principle of local repair of a path
  • Fig. 5 schematically illustrates a distributed method of local protection of an LSP path, known from the state of the art
  • Fig. 6 schematically illustrates a centralized method of local protection of an LSP path, known from the state of the art
  • Fig. 7 illustrates the concept of shared risk entity
  • Fig. 8 schematically illustrates a method of local protection of LSP paths according to the present invention.
  • the idea underlying the invention starts from the observation that a failure in a network generally affects only one physical element of the network at the same time.
  • the failure of a physical element leads to the failure of a certain number of IP links and / or network nodes. Thus, in the event of failure of a physical element, only certain paths will be affected.
  • the basic idea of the invention is to share the protection resources making it possible to protect paths which are not affected at the same time by the failure of the same physical element. Thus, bypass tunnels protecting different paths can share protection resources and save network resources such as bandwidth.
  • we will obtain a good guarantee that the paths to be protected are effectively backed up in the event of failure.
  • SRLG Shared Risk Link Group
  • SRLG The list concept of SRLG will be better understood using the example in FIG. 7. It is assumed that three routers Ri, R, R 3 are interconnected by means of optical mixers (OXC) O 1; O 2 , O 3 . These optical crossovers are interconnected by means of optical fibers f 1; f 2 with WDM muliplexing. Let Si, S 2 , be the SRLGs associated respectively with the fibers f ! and f 2 .
  • the link R Î R 2 uses the only light path O ⁇ O 2 its list SRLG is ⁇ Si ⁇ .
  • the link R ⁇ R 3 uses the light path O 1 -O 2 -O 3 , its SRLG list is therefore ⁇ S ⁇ , S 2 ⁇ .
  • the link R 2 R 3 uses the light path O 2 -O 3 , its SRLG list therefore boils down to ⁇ S 2 ⁇ . It can therefore be seen that the links R t R 2 and R 2 R 3 have a diversity of SRLG but that these do not have any with the link with the link R 1 R 3 .
  • a failure of SRLG is defined as the failure of the physical resource shared by the various elements of the SRLG.
  • a failure of the SRLG S 2 corresponds to a failure of the fiber f 2 .
  • a failure of SRLG can cause the failure of several links.
  • failure of the SRLG S 2 will result in the failure of the links R Î R 3 and R 2 R 3 .
  • the failure of a given SRLG will result in the failure of the links whose SRLG lists contain it.
  • a failure of SRLG can occur independently of the failure of a link.
  • the failure of the link R 2 O 2 connecting R 2 to O leads to a failure of the link R 2 R 3 but not of the SRLG S 3 .
  • the failure of this link will not lead to that of the SRLG.
  • bypass tunnels There are two types of bypass tunnels: those which protect a link, also called NHOP bypass (for next-hop bypass) and those which protect a node orN HOP bypass (for next-next-hop bypass).
  • An NNHOP bypass tunnel begins at a PLR point and ends two hops downstream or even further. Of course, it must not use the node it protects or the link downstream from the PLR point. He must also present a diversity of SRLG with the latter. Note that an NNHOP bypass tunnel protects not only the node downstream from the PLR point but also the link downstream from the latter.
  • FR for Failure Risk
  • FR for Failure Risk
  • the TFRG of an NHOP bypass tunnel is the assembly formed by the downstream link and the SRLG list of this link.
  • the TFRG of an NNHOP bypass tunnel is the assembly formed by the node it protects, the link connecting the PLR point to this node and the SRLG list of this link.
  • bypass tunnel protects a link or a node (that is to say is of the NHOP or NNHOP type). It will be said that two bypass tunnels present a diversity of FRG (Failure Risk Group) if:
  • LFRG Link Failure Risk Group
  • protection bandwidth of a risk of failure ⁇ by a link L of a bypass tunnel protecting ⁇ (in other words whose TFRG contains ⁇ ), and we denote it BP ( ⁇ , L), the bandwidth reserved or to reserve on this link to protect ⁇ .
  • bandwidth is understood here to mean logical bandwidth and not physical bandwidth. More specifically, the physical bandwidth of a physical resource may include a primary bandwidth dedicated to normal traffic and a secondary bandwidth dedicated to protection. The entire secondary protection bandwidth is not necessarily reserved and for a dom ed link L a distinction will be made between the current value actually reserved for protection rBP (L) and the maximum value that can be reserved RBP (L).
  • the JFGK candidate bypass tunnel cannot be selected because the FG link does not have any diversity of SRLG with the JK link. Another bypass tunnel should then be sought.
  • SRLG ⁇ S 2 ⁇ .
  • the links JF, FG and GK have a diversity of SRLG with ⁇ S 2 ⁇ . If so, the JFGK tunnel can be selected.
  • the JFGK bypass tunnel must offer sufficient bandwidth to rescue traffic on the JK link.
  • LFRG (FG) ⁇ BC, C, JK, Si, S 2 ⁇
  • this last case corresponds to a failure of the underlying physical resource of S 2 .
  • the links BC and JK are simultaneously faulty and the bypass tunnels Bi, B 2 , B 3 are all activated.
  • the tunnels Bi, B 2 , B 3 do not have any diversity of FRG.
  • the tunnel B 3 cannot be retained.
  • SRLG ⁇ S ⁇ .
  • the links JF, FG and GK have a diversity of SRLG with ⁇ S 4 ⁇ . If so, in order for the JFGK tunnel to be definitively retained, the JFGK bypass tunnel must provide sufficient bandwidth to rescue traffic on the JK link.
  • LFRG (FG) ⁇ BC, C, JK, Si, S 2 , S 4 ⁇
  • Path B IEFGK is a candidate bypass tunnel that presents a diversity of SRLGs with the IJ link.
  • LFRG (FG) ⁇ BC, C, JK, J, Si, S 2 , S 4 ⁇
  • Tunnel B 4 is selected since rBP (FG) ⁇ RBP (FG). It will be noted that B 4 also makes it possible to protect the link IJ without additional reservation of bandwidth on the link FG.
  • the path B 5 JFGHL is a candidate bypass tunnel which presents a diversity of SRLG with the JK link.
  • LFRG (FG) ⁇ BC, C, JK, J, K, SS 2 , S 4 ⁇
  • Tunnel B 5 is selected since rBP (FG) ⁇ RBP (FG). It will be noted that B 5 also makes it possible to protect the link KL without additional reservation of bandwidth on the link FG.
  • the bypass tunnels are created centrally by a specialized server. This has the network topology and knows the bandwidths reserved for traffic and for protection on each of the network links. It also takes into account the operator's specifications for elements that are not susceptible to protection and / or those that cannot be used for protection.
  • the input router when a path is established through the network, the input router can specify that the path in question must be the object of protection.
  • the local database (TED) of each node thus contains information indicating the bypass tunnels created with their characteristics (NHOP, NNHOP, path, bandwidth, for example) as well as the elements they protect.
  • this router incorporates the following information into the “session attribute” or SAO (for Session_Attribute Object) object:
  • an LPD Local Protection Desired
  • NPD Node Protection Desired
  • BPD Bandwidth Protection Desired
  • a transit router R on the path in question receives a “Path” message from the RSVP-TE protocol, it firstly searches whether protection is required and what its type is (NHOP, NNHOP). Depending on the case, the protection concerns either the link or the node, downstream from the router on the way. Router R then searches in its local database if there is already at least one bypass tunnel passing through R. If not, it searches if it can build a bypass tunnel using partially or entirely elements of existing bypass tunnels. The router thus obtains a certain number of candidate bypass tunnels which are subject to the selection steps (2) to (5) indicated above. If one of the candidates is selected, the router, after having received the RSVP protocol “RESV” message, effectively creates the bypass tunnel and allocates the necessary bandwidth to it.
  • RSVP protocol “RESV” message effectively creates the bypass tunnel and allocates the necessary bandwidth to it.
  • rBP (L) max (BP ( ⁇ , L)) where ⁇ s LFRG (L). If the transit router cannot establish a bypass tunnel, for example due to insufficient bandwidth, it notifies the ingress router.
  • protection request and the reservation acknowledgment can also be transmitted by means of the CR-LDP protocol in place of the RSVP-TE protocol.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une méthode de protection de chemins à commutation d'étiquettes dans un réseau MPLS comprenant une pluralité de noeuds reliés par des liens IP; chaque chemin passant par une série déterminée de noeuds et de liens dudit réseau, dits éléments dudit chemin. Un élément d'un premier chemin ayant été protégé à l'aide d'un chemin, dit de bypass du premier chemin, partant d'un noeud du premier chemin en aval dudit élément à protéger et se terminant en un noeud du premier chemin en aval dudit élément à protéger et se terminant en un noeud du premier chemin en aval dudit élément à protéger, un certain nombre de ressources du réseau ayant été réservée pour ledit chemin de bypass du premier chemin, ce dernier étant actif en cas de défaillance dudit élément du premier chemin, on protíge un élément d'un second chemin à l'aide d'un chemin, dit de bypass du second chemin, partant d'un noeud du second chemin en amont de cet élément et se terminant en un noeud du second chemin en aval de cet élément, le chemin de bypass du premier chemin.

Description

Méthode de protection locale de chemins à commutation d'étiquettes avec partage de ressources
La présente invention concerne une méthode de protection de chemins à commutation d'étiquettes dans un réseau MPLS (MultiProtocol Label Switching). Plus particulièrement la présente invention a trait à une méthode de protection locale de tels chemins avec partage de ressources. La norme MPLS, publiée sous les auspices de l'IETF (Internet Engineering
Task Force) est une technique basée sur la permutation d'étiquettes (label switching) permettant de créer un réseau orienté connexion à partir d'un réseau de type datagramme comme le réseau IP. On trouvera une documentation détaillée du protocole MPLS sous le site www.ietf.org. On a représenté de manière schématique en Fig. 1 un réseau MPLS, 100, comprenant une pluralité de routeurs dénommés LSR (Label Switching Routers) tels que 110, 111, 120, 121, 130, 131, 140, reliés entre eux par des liens IP. Lorsqu'un paquet IP arrive sur un nœud périphérique d'entrée 110, dénommé Ingress LSR, ce dernier lui attribue une étiquette (ici 24) en fonction de son en-tête IP et la concatène audit paquet. Le routeur qui reçoit le paquet étiqueté remplace l'étiquette (entrante)
ÏQ IE DE CONFIRMATION par une étiquette sortante en fonction de sa table d'acheminement (dans l'exemple en question, 24 est remplacé par 13) et le processus se répète de nœud en nœud jusqu'au routeur de sortie 140 (encore dénommé Egress LSR) qui supprime l'étiquette avant de transmettre le paquet. Alternativement, la suppression d'étiquette peut être déjà effectuée par le pénultième routeur puisque le routeur de sortie n'utilise pas l'étiquette entrante.
Comme indiqué en Fig. 2, un routeur LSR utilise l'étiquette du paquet entrant (étiquette entrante) pour déterminer le port de sortie et l'étiquette du paquet sortant (étiquette sortante). Ainsi, par exemple, le routeur A remplace les étiquettes des paquets IP arrivant sur le port 3 et de valeur 16 par des étiquettes de valeur 28 puis envoie les paquets ainsi réétiquetés sur le port 2.
Le chemin parcouru par un paquet à travers le réseau du routeur d'entrée (Ingress LSR) jusqu'au routeur de sortie (Egress LSR) est appelé chemin à étiquettes commutées ou LSP (Label Switched Path). Les routeurs LSR traversés par le chemin et distincts des routeurs d'entrée et de sortie sont appelés routeurs de transit. D'autre part, on appelle classe d'équivalence ou FEC (Forward Equivalence Class) l'ensemble des paquets IP qui sont transmis le long d'un même chemin.
Le protocole MPLS permet de forcer les paquets IP à suivre un chemin LSP préétabli qui n'est en général pas le chemin IP optimal en terme de nombre de bonds ou de métrique de chemin. La technique de détermination du chemin ou des chemins à
emprunter est appelée ingénierie de trafic ou MPLS-TE (pour MPLS Traffic Engineering). La détermination du chemin prend en compte des contraintes sur les ressources disponibles (constraint based routing), notammment en bande passante sur les différents liens du réseau. Au contraire du routage IGP classique opérant selon un mode bond par bond (hop-by-hop routing), la détermination d'un chemin LSP est effectué selon un mode dit explicite (explicitly routed LSP ou ER-LSP) dans lequel on détermine certains ou tous les nœuds du chemin du routeur d'entrée jusqu'au routeur de sortie. Lorsque tous les nœuds du chemin sont fixés, on parle de routage explicite au sens strict. Un chemin déterminé selon un mode explicite est encore appelé tunnel MPLS.
La détermination d'un ou des tunnels MPLS peut se faire de manière centralisée ou distribuée. Selon la méthode distribuée encore appelée Constraint based Routing, chaque routeur est renseigné sur la topologie du réseau et les contraintes affectant les différents liens du réseau. Pour ce faire, chaque routeur détermine transmet à ses voisins un message indiquant ses liens immédiats et les contraintes (ou attributs) qui y sont associées. Ces messages sont ensuite propagés de nœud en nœud par des messages IGP étendu, selon un mécanisme d'inondation (flooding) jusqu'à ce que tous les routeurs soient renseignés. Ainsi, chaque routeur dispose en propre d'une base de données (dite TED pour Traffic Engineering Database) lui donnant la topologie du réseau et ses contraintes.
La détermination du chemin à commutaion d'étiquettes est ensuite effectuée par le routeur d'entrée (Ingress LSR) en prenant également en compte d'autres contraintes fixées par l'opérateur du réseau (par exemple éviter tel ou tel nœud ou éviter les liens de tel ou tel type). Le routeur d'entrée détermine alors, par exemple au moyen de l'algorithme de Dijkstra, le chemin le plus court satisfaisant à l'ensemble des contraintes (Constraint Shortest Path First ou CSPF), celles affectant les liens comme celles fixées par l'opérateur. Ce chemin le plus court est ensuite signalé aux nœuds du chemin LSP au moyen des protocoles de signalisation connus sous les abbréviations RSVP-TE (Resource reSerVation Protocol for Traffic Engineering) ou bien CR-LDP (Constrained Route Label Distribution Protocol). On trouvera une description du protocole RSVP-TE dans le document de D. Adwuche et al. intitulé « RSVP-TE : extensions to RSVP for LSP tunnels » disponible sous le site de 1TETF précité. Ces protocoles de signalisation MPLS permettent la distribution des étiquettes le long du chemin et la réservation des ressources.
Par exemple, si l'on utilise le protocole de signalisation RSVP, le routeur d'entrée A transmet, comme indiqué en Fig. 3A, un message « Path » dans un paquet IP au routeur de sortie F. Ce message spécifie la liste des nœuds par lesquels le chemin LSP doit passer. A chaque nœud le message « Path » établit le chemin et fait une réservation d'état. Lorsque le message « Path » atteint le routeur de sortie, un message d'acquittement « Resv » est renvoyé par le même chemin au routeur d'entrée, comme indiqué en Fig. 3B. A chaque nœud, la table de routage MPLS est actualisée et la réservation de ressource est effectuée. Par exemple, si la ressource est une bande passante et que l'on souhaite réserver 10 unités (MHz) pour le chemin, les bandes passantes respectivement affectées à chaque lien sont décrémentées de la valeur réservée (10) lors de la rétropropagation du message d'acquittement / réservation. Il convient de noter que la ressource en question (par exemple la bande passante) est une ressource logique sur le lien IP et non une ressource physique. Lorsque le message d'acquittement est reçu par le routeur d'entrée, le tunnel est établi.
Comme on l'a indiqué plus haut, la détermination des chemins LSP peut être réalisée de manière centralisée. Dans ce cas, un serveur a connaissance de la topologie du réseau et prend en compte les contraintes sur les liens et les contraintes fixées par l'opérateur du réseau pour déterminer des tunnels entre les routeurs d'entrée et les routeurs de sortie. Les routeurs d'entrée sont ensuite avertis par le serveur du ou des tunnels pour lesquels ils sont le nœud d'entrée. Les tunnels sont alors établis comme indiqué en Fig. 3A et 3B. La méthode de détermination centralisée présente l'avantage d'une grande stabilité et prédictibilité puisqu'un seul organe effectue le calcul préalable de tous les tunnels. Elle présente en contrepartie l'inconvénient de de pas s'adapter facilement aux variations rapides de la topologie du réseau, par exemple en cas de rupture d'une liaison physique, supprimant les liens IP qu'elle supporte.
Qu'ils aient été calculés de manière centralisée ou distribuée, les tunnels sont susceptibles d'être détruits en cas de coupure d'une liaison physique sous-jacente. Il faut alors prévoir des mécanismes de secours permettant d'établir un nouveau tunnel entre le même routeur d'entrée et le même routeur de sortie. On peut distinguer les mécanismes de restauration établissant un tunnel de secours après la coupure et les mécanismes de protection préétablissant un tunnel de secours en prévision d'une coupure possible.
L'avantage des mécanismes de protection est de permettre une reprise très rapide du trafic, un tunnel de secours étant déjà disponible. En contrepartie, ils présentent l'inconvénient de mobiliser des ressources importantes du réseau. Plus précisément, les mécanismes de protection connus de l'état de la technique se divisent en méthodes de protection locale et méthodes de protection de bout en bout. Dans les premières, des tunnels de secours locaux sont préétablis en prévision d'une défaillance d'un élément (nœud, lien) du tunnel initial. Lorsque la défaillance se produit, le trafic est détourné dans le tunnel local pour contourner l'élément défaillant. Dans les méthodes de protection de bout en bout, un tunnel de secours est établi du routeur d'entrée au routeur de sortie. A l'inverse des méthodes de restauration (où les tunnels de secours sont créés à la demande), les méthodes de protection (où les tunnels de secours sont créés au préalable) sont gourmandes en ressources de réseau.
On connaît de l'état de la technique, en particulier du document intitulé « Fast- Reroute Techniques in RSVP-TE » de P. Pan et al. disponible sur le site de 1TETF sus-mentionné sous la référence « draft-pan-rsvp-fastreroute-00.txt », différentes méthodes de protection locale (ou FRR pour Fast ReRoute) d'un tunnel. Le principe général de cette protection locale est rappelé en Fig. 4. Pour un élément (lien, nœud) du tunnel à protéger, on prévoit un tunnel de secours local pour le contourner. Par exemple pour contourner le lien CD, on prévoit un tunnel de secours T(CD) ayant pour chemin C,C',E. Le routeur en amont qui détecte et répare la défaillance du tunnel en orientant les paquets sur le tunnel de secours est dénommé point PLR (pour « Point of Local Repair »). Le routeur en aval de la défaillance où le tunnel de secours rejoint le tunnel initial est dénommé point PM (pour « Point of Merging »). Dans le cas présent, le routeur C détecte la défaillance du lien CD (symbolisée par un éclair) par l'absence de messages RSVP « Hello » transmis à intervalles réguliers sur le lien CD par le routeur D ou par une alerte de la couche physique sous-jacente. Le routeur C réachemine alors le trafic du tunnel initial sur le tunnel de bypass CC'E. La jonction entre le tunnel initial et le tunnel de bypass est réalisée en E. Une première méthode de protection locale de chemin LSP, dénommée « one- to-one », consiste à créer pour chaque élément du chemin à protéger un tunnel de secours local, encore appelé « détour ». On a illustré en Fig. 5 une méthode de protection locale de type « one-to-one ». Chaque élément K du chemin est protégé par un détour noté T(K). On notera qu'un détour T(N) pour un nœud N protège également le lien en amont et le lien en aval du nœud. Si le chemin comporte n nœuds, il peut donc y avoir jusqu'à (n-1) détours. Si plusieurs chemins sont à protéger dans le réseau MPLS, une série de détours devra être prévue pour chacun d'entre eux. Cette méthode de protection n'est donc pas extensible (scalable).
Il est important de noter que les détours sont créés dynamiquement lors de l'établissement du chemin. En outre, les détours sont créés de manière distribuée par les routeurs de transit du chemin, à l'initiative du routeur d'entrée. Ainsi en cas de changement de topologie du réseau ou de modification des contraintes de ressources, les détours ne seront pas nécessairement les mêmes pour un même chemin. La procédure de création des détours nécessite une modification de la signalisation RSVP, comme décrit dans le document sus-mentionné.
Selon une seconde méthode de protection locale de chemin LSP, dénommée « many-to-one », un tunnel de secours, dénommé tunnel de bypass, est prévu par l'opérateur pour protéger un ou plusieurs éléments (nœud, lien) du réseau MPLS. Un tel tunnel de bypass peut alors servir à secourir une pluralité de chemins empruntant ledit ou lesdits éléments. A titre d'exemple, on a illustré en Fig. 6 deux chemins à protéger T^ABCDE et T2=A'BCDE partageant le chemin BCDE. Dans le cas présent, l'opérateur a prévu de protéger le nœud C en configurant un tunnel de bypass ayant pour chemin BB'D'D. Ce tunnel de bypass permet de secourir les deux chemins Tt et T2 en cas de défaillance du nœud C (ou d'un des liens BC, CD). De manière générale, un tunnel de bypass permet de secourir une pluralité de chemins qui l'intersectent en amont de la défaillance en un point commun PLR et en aval de la défaillance en un point commun PM. Le tunnel de bypass tire parti de la possibilité d'empiler les étiquettes (label stacking) en leur attribuant différents niveaux de hiérarchie pour réacheminer les paquets de manière transparente. Plus précisément, comme indiqué sur la Fig. 6, les routeurs le long du chemin Tι commutent les étiquettes 12,18,45 et 37. Lorsqu'une défaillance du nœud C intervient, le routeur B empile une étiquette (ici 67) représentant localement le tunnel de bypass. Au pénultième nœud du tunnel de bypass (ici D'), l'étiquette représentant localement le tunnel de bypass (ici 38) est dépilée de sorte que le point PM reçoit une étiquette identique à celle (45) d'un paquet qui n'aurait pas été réacheminé.
Il est important de noter que les tunnels de bypass sont déterminés au préalable, de manière statique et/ou centralisée par un serveur sans tenir compte a priori des besoins en ressources des futurs chemins LSP à établir. En particulier la bande passante du tunnel de bypass peut ne pas être suffisante pour transporter la bande requise du chemin à protéger. Ainsi, bien qu'un tunnel de bypass soit présent, il ne permettra pas de secourir efficacement le chemin à protéger.
Le problème à la base de l'invention est de proposer une méthode de protection de chemins LSP qui consomme moins de ressources que les méthodes de protection connues de l'état de la technique, tout en garantissant un degré élevé d'extensibilité (scalability) et une bonne garantie d'efficacité.
Le problème est résolu par l'objet de l'invention, défini comme une méthode de protection de chemins à commutation d'étiquettes dans un réseau MPLS comprenant une pluralité de nœuds reliés par des liens IP, un chemin passant par une série déterminée de nœuds et de liens dudit réseau, dits éléments dudit chemin. Un élément d'un premier chemin ayant été protégé à l'aide d'un chemin, dit de bypass du premier chemin, partant d'un nœud du premier chemin en amont dudit élément à protéger et se terminant en un nœud du premier chemin en aval dudit élément à protéger et un certain nombre de ressources du réseau ayant été réservées pour ledit chemin de bypass du premier chemin, ce dernier étant actif en cas de défaillance dudit élément du premier chemin, on protège un élément d'un second chemin à l'aide d'un chemin, dit de bypass du second chemin, partant d'un nœud du second chemin en amont de cet élément et se terminant en un nœud du second chemin en aval de cet élément, le chemin de bypass du second chemin utilisant au moins une partie des ressources réservées pour le chemin de bypass du premier chemin .
On peut ainsi économiser les ressources du réseau en les partageant entre les premier et second chemins.
Avantageusement, si l'élément à protéger du second chemin est un lien, on sélectionne ledit chemin de bypass dudit second chemin parmi une pluralité de chemins candidats ne comprenant pas ledit lien, la sélection étant effectuée en testant si chaque lien du chemin candidat présente un risque de défaillance indépendant du risque de défaillance dudit lien à protéger.
Pour ce faire, on détermine pour chaque élément physique dudit réseau, un groupe de liens dudit réseau atteints par la défaillance dudit élément physique.
Réciproquement, pour chaque lien dudit réseau, on détermine la liste desdits groupes auxquels il appartient.
Pour tester si un lien du chemin candidat présente un risque de défaillance indépendant du risque de défaillance dudit lien à protéger, on détermine si les listes desdits groupes, respectivement associées au lien à protéger et au lien du chemin candidat sont disjointes.
Si l'élément à protéger du second chemin est un nœud, on sélectionne ledit chemin de bypass dudit second chemin parmi une pluralité de chemins candidats ne comprenant pas ledit nœud, la sélection étant effectuée en testant si chaque lien du chemin candidat présente un risque de défaillance indépendant du risque de défaillance du lien, dit lien amont, joignant le nœud (PLR) en amont dudit nœud à protéger et ce dernier nœud.
Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels :
La Fig. 1 illustre un réseau MPLS connu de l'état de la technique ;
La Fig. 2 illustre schématiquement la création d'un chemin à étiquettes commutées ; La Fig. 3 A illustre schématiquement une première phase de la procédure d'établissement d'un chemin LSP ;
La Fig. 3B illustre schématiquement une seconde phase de la procédure d'établissement d'un chemin LSP ; La Fig. 4 illustre schématiquement le principe de réparation locale d'un chemin
LSP ;
La Fig. 5 illustre schématiquement une méthode distribuée de protection locale d'un chemin LSP, connue de l'état de la technique ;
La Fig. 6 illustre schématiquement une méthode centralisée de protection locale d'un chemin LSP, connue de l'état de la technique ;
La Fig. 7 illustre le concept d'entité de risque partagé ;
La Fig. 8 illustre schématiquement une méthode de protection locale de chemins LSP selon la présente invention .
L'idée à la base de l'invention part de la constatation qu'une défaillance dans un réseau n'affecte généralement qu'un seul élément physique du réseau en même temps.
La défaillance d'un élément physique entraîne la défaillance d'un certain nombre de liens IP et/ou de nœuds du réseau. Ainsi, en cas de défaillance d'un élément physique, seuls certains chemins seront affectés. L'idée de base de l'invention est de partager les ressources de protection permettant de protéger des chemins qui ne sont pas affectés en même temps par la défaillance d'un même élément physique. Ainsi, des tunnels de bypass protégeant différents chemins pourront se partager des ressources de protection et économiser les ressources du réseau comme la bande passante. En outre en dimensionnant convenablement, les ressources partagées, on obtiendra une bonne garantie que les chemins à protéger soient effectivement secourus en cas de défaillance.
On appellera par la suite entité de risque partagé ou SRLG (pour Shared Risk Link Group) associé à un lien, l'ensemble des liens du réseau partageant une même ressource physique avec le lien précité et tous atteints par la défaillance de cette ressource physique. Ce concept d'entité de risque partagé a été introduit par K. Kompella et al. dans un document intitulé « Routing extensions in support of generalized MPLS » disponible sur le site de 1TETF sous la référence « draft-ietf- ccamp-gmpls-routing-01.txt ». Un lien peut appartenir à plusieurs SRLG ou n'en appartenir à aucun. On définit la liste SRLG d'un lien comme la liste des SRLG dans lesquels ce lien apparaît. Deux liens présentent une diversité de SRLG si leurs listes SRLG ont une intersection vide. En particulier deux liens n'appartenant à aucun SRLG ont une diversité de SRLG.
Le concept de liste de SRLG sera mieux compris à l'aide de l'exemple de la Fig. 7. On suppose que trois routeurs Ri, R , R3 sont interconnectés au moyen de brasseurs optiques (OXC) O1; O2, O3. Ces brasseurs optiques sont interconnectés au moyen de fibres optiques f1; f2 avec muliplexage WDM. Soient Si, S2, les SRLG associés respectivement aux fibres f! et f2. Le lien RÎR2 utilise le seulement trajet lumineux O^ O2 sa liste SRLG est {Si}. Le lien RιR3 utilise le trajet lumineux O1-O2-O3, sa liste SRLG est par conséquent {Sι,S2}. Le lien R2R3 utilise le trajet lumineux O2-O3, sa liste SRLG se résume donc à {S2}. On constate donc que les liens RtR2 et R2R3 ont une diversité de SRLG mais que ceux-ci n'en ont pas avec le lien avec le lien R1R3 .
On définit une défaillance de SRLG comme la défaillance de la ressource physique partagée par les différents éléments du SRLG. Ainsi, dans l'exemple précédent, une défaillance du SRLG S2 correspond à une défaillance de la fibre f2. Une défaillance de SRLG peut causer la défaillance de plusieurs liens. Ainsi, dans l'exemple précédent, la défaillance du SRLG S2 entraînera la défaillance des liens RÎR3 et R2R3. De manière générale, la défaillance d'un SRLG donné entraînera la défaillance des liens dont les listes de SRLG le contiennent.
Réciproquement, une défaillance de SRLG peut intervenir indépendamment de la défaillance d'un lien. Ainsi, dans l'exemple précédent, la défaillance du lien R2O2 connectant R2 à O entraîne une défaillance du lien R2R3 mais non du SRLG S3. De manière générale si un lien n'appartient pas à un SRLG, la défaillance de ce lien n'entraînera pas celle du SRLG.
On supposera dans ce qui suit que la probabilité pour que le réseau soit affecté de plus d'une défaillance de nœud ou de lien ou de SRLG est faible.
On distingue deux types de tunnels de bypass : ceux qui protègent un lien, encore appelés NHOP bypass (pour next-hop bypass) et ceux qui protègent un nœud ouN HOP bypass (pour next-next-hop bypass).
Un tunnel NNHOP bypass commence à un point PLR et se termine deux bonds en aval, voire plus loin. Bien entendu, il ne doit pas utiliser le nœud qu'il protège ni le lien en aval du point PLR. Il doit également présenter une diversité de SRLG avec ce dernier. On notera qu'un tunnel NNHOP bypass protège non seulement le nœud en aval du point PLR mais également le lien en aval de ce dernier. On définit également un risque de défaillance ou FR (pour Failure Risk) comme un lien, un nœud ou un SRLG. Bien entendu, pour un SRLG, le risque réel de défaillance concerne la ressource physique sous-jacente mais, par souci de simplification, on associera le SRLG à la ressource physique en question. En outre, on définit le groupe de risques de défaillance ou TFRG (pour Tunnel
Failure Risk Group) d'un tunnel de bypass B comme l'ensemble des risques de défaillance que protège ce tunnel. Ainsi, le TFRG d'un tunnel de bypass NHOP est l'ensemble formé par le lien en aval et la liste SRLG de ce lien. De même, le TFRG d'un tunnel de bypass NNHOP est l'ensemble formé par le nœud qu'il protège, le lien reliant le point PLR à ce nœud et la liste SRLG de ce lien.
On supposera par la suite qu'un tunnel de bypass protège un lien ou un nœud (c'est-à-dire est du type NHOP ou NNHOP). On dira que deux tunnels de bypass présentent une diversité de FRG (Failure Risk Group) si :
- ils ne protègent pas le même lien - ils ne protègent pas le même nœud
- les liens qu'ils protègent présentent une diversité de SRLG
Comme précédemment, on définit le groupe de risques de défaillance ou LFRG (pour Link Failure Risk Group) d'un lien comme l'ensemble des risques de défaillance que protègent les tunnels de bypass passant par ce lien. Enfin, on définit la bande passante de protection d'un risque de défaillance Φ par un lien L d'un tunnel de bypass protégeant Φ (autrement dit dont le TFRG contient Φ), et on la note BP(Φ,L), la bande passante réservée ou à réserver sur ce lien pour protéger Φ. Il convient de préciser que l'on entend ici par bande passante une bande passante logique et non une bande passante physique. Plus précisément la bande passante physique d'une ressource physique pourra comportera une bande passante primaire dédiée au trafic normal et une bande passante secondaire dédiée à la protection. La totalité de la bande passante de protection secondaire n'est pas nécessairement réservée et pour un lien dom é L on distinguera la valeur courante effectivement réservée à la protection rBP(L) de la valeur maximale réservable RBP(L).
On suppose maintenant que plusieurs chemins ont été créés dans le réseau MPLS entre routeurs d'entrée et routeurs de sortie, de manière centralisée ou distribuée comme on l'a vu dans la partie introductive. On cherche à créer des tunnels de bypass qui protégeront les éléments (nœud, lien) de chacun de ces chemins. L'opérateur peut avoir spécifié, pour certains de ces éléments ou pour le chemin tout entier, qu'il ne sera pas nécessaire de prévoir une protection. De même, il peut avoir spécifié, que certains éléments du réseau ne seront pas éligibles à une fonction de protection d'un chemin. En tenant compte de ces spécifications, la méthode de détermination des tunnels de bypass opère de la manière suivante, successivement pour chacun des chemins à protéger et dans un chemin, pour chaque élément à protéger:
(1) on détermine s'il existe déjà un tunnel de bypass à partir du PLR et, de manière plus générale, s'il existe déjà dans le réseau des tunnels de bypass dont on peut réutiliser partiellement ou totalement les éléments. On obtient ainsi des tunnels de bypass candidats. Les tunnels de bypass candidats ne peuvent utiliser l'élément à protéger.
(2) dans le cas d'un lien à protéger, on détermine pour chaque lien du tunnel de bypass candidat, s'il présente une diversité de SRLG avec ce lien : dans la négative le tunnel de bypass candidat n'est pas compatible en terme de risque et ne peut être retenu;
(3) dans le cas d'un nœud à protéger, on détermine pour chaque lien du tunnel de bypass candidat, s'il présente une diversité de SRLG avec le lien joignant le PLR et le nœud à protéger : dans la négative le tunnel de bypass n'est pas compatible en terme de risque et ne peut être retenu ;
(4) dans l'affirmative, en revanche, on simule une protection de d'élément considéré par le tunnel de bypass candidat et on calcule pour chaque lien du tunnel la nouvelle bande passante à réserver, soit rBP(L)=max (BP(Φ,L)) où Φ e LFRG(L);
(5) on teste si la condition rBP(L) < RBP(L) est vérifiée pour tous les liens du tunnel de bypass candidat, dans la négative le tunnel n'est pas retenu ;
(6) la procédure est répétée pour tous les tunnels de bypass candidats.
Un exemple permettra de mieux comprendre la mise en œuvre de la méthode de détermination des tunnels de bypass. Considérons le réseau MPLS de la Fig. 8 et supposons qu'un premier chemin LSPi≈AJBCD de bande passante 10 unités ait été établi dans le réseau. On suppose en outre que tous les liens IP ont une bande bassante de trafic de 10 unités, une bande passante de protection de 10 unités sauf le lien FG qui a une bande passante de protection de 20 unités. Les spécifications de l'opérateur indiquent que seuls le lien BC et le nœud C ont besoin d'être secourus. Ces deux éléments sont respectivement protégés par un premier tunnel de bypass NHOP Bi et un second tunnel de bypass NNHOP B2 ayant chacune une bande passante de 10 unités. On fait l'hypothèse que la liste SRLG du lien BC est {Si, S2} et que celle du lien FG est {S3} avec Si, S2, S3 distincts.
Supposons maintenant qu'il faille protéger un second chemin LSP2=IJKL de bande passante 10 unités. Les spécifications indiquent que seuls le lien JK et les nœuds J et K ont besoin d'être secourus. Aucun tunnel de bypass n'est disponible à partir de I et J. On considère le tunnel de bypass candidat Bs≈JFGK réutilisant le lien
FG de BL
lien JK
Supposons que le lien JK ait pour liste SRLG={S3, S } avec S distinct de Si, S2,
S3 . Dans ce cas, le tunnel de bypass candidat JFGK ne peut être retenu car le lien FG ne présente pas de diversité de SRLG avec le lien JK. Un autre tunnel de bypass doit alors être recherché.
Supposons maintenant que le lien JK ait pour liste SRLG={S2}. On teste successivement si les liens JF, FG et GK ont une diversité de SRLG avec {S2}. Dans l'affirmative, le tunnel JFGK peut être retenu. Pour l'être définitivement, le tunnel de bypass JFGK doit offrir une bande passante suffisante pour secourir le trafic sur le lien JK.
On simule la protection de JK par le tunnel de bypass candidat B3. On obtient :
LFRG(JF)={JK} et rBP(JF)=10 BP(JK,JF)=10
LFRG(GK)={JK} et rBP(GK)=10 BP(JK,GK)=10
LFRG(FG)={BC, C, JK, Si, S2}
BP(BC, FG)= bande passante (Bι)+ bande passante (B2)=20
BP(JK,FG)= bande passante (B3) =10 BP(C,FG)= bande passante (B2)=10
BP(Sι,FG)= bande passante (B.) + bande passante (B2)=20
BP(S2,FG)= bande passante (Bι)+ bande passante (B2) + bande passante (B3)= 30
On remarque que ce dernier cas correspond à une défaillance de la ressource physique sous-jacente de S2. Dans ce cas, les liens BC et JK sont simultanément défaillants et les tunnels de bypass Bi, B2, B3 sont tous trois activés. Autrement dit, les tunnels Bi, B2, B3 ne présentent pas de diversité de FRG.
rBP(FG)=max (BP(Φ, FG)) où Φ e LFRG(FG) c'est-à-dire, rBP(FG)=30>RBP(FG). Le tunnel B3 ne peut être retenu.
Supposons maintenant que le lien JK ait pour liste SRLG={S }. On teste comme précédemment si les liens JF, FG et GK ont une diversité de SRLG avec {S4}. Dans l'affirmative, pour que le tunnel JFGK soit définitivement retenu, le tunnel de bypass JFGK doit offrir une bande passante suffisante pour secourir le trafic sur le lien JK.
Le calcul de BP(JK,JF) et BP(JK,GK) est identique à celui ci-dessus. Cependant pour le lien FG :
LFRG(FG)={BC, C, JK, Si, S2, S4}
BP(BC, FG)= bande passante (Bι)+ bande passante (B2)=20
BP(JK,FG)= bande passante (B3) =10
BP(C,FG)= bande passante (B2)=10 BP(S i ,FG)= bande passante (B i) + bande passante (B2)=20
BP(S2,FG)= bande passante (Bι)+ bande passante (B2)=20
BP(S4,FG)= bande passante (B3)=10 c'est-à-dire, rBP(FG)=20. Puisque rBP(FG)≤RBP(FG) le tunnel B3 est retenu.
Ici la bande de protection à réserver est plus faible car les liens JK et BC présentent une diversité de SRLG. On gardera cette hypothèse dans la suite.
nœud J : Le chemin B =IEFGK est un tunnel de bypass candidat qui présente une diversité de SRLG avec le lien IJ. On obtient :
LFRG(IE)={J} etBP(J,IE)=10
LFRG(EF)={J} et BP(J,EF)=10
LFRG(GK)={J} et BP(J,GK)=10
LFRG(FG)={BC, C, JK, J, Si, S2, S4}
BP(BC,FG)= bande passante (Bι)+ bande passante (B2)=20
BP(C,FG)= bande passante (B2)=10
BP(JK,FG)= bande passante (B3) =10
BP(J,FG)= bande passante (B4)=10 BP(Sι,FG)= bande passante (Bi) + bande passante (B2)=20
BP(S2,FG)= bande passante (B + bande passante (B2)=20
BP(S4,FG)= bande passante (B3)=10
d'où rBP(FG)=20. Le tunnel B4 est retenu puisque rBP(FG)≤RBP(FG). On notera que B4 permet également de protéger le lien IJ sans réservation supplémentaire de bande passante sur le lien FG.
nœud K :
Le chemin B5=JFGHL est un tunnel de bypass candidat qui présente une diversité de SRLG avec le lien JK. On obtient :
LFRG(JF)={K} et BP(K,JF)=10 LFRG(GH)={K} et BP(K,GH)=10
LFRG(HL)={K} et BP(K,HL)=10
LFRG(FG)= {BC, C, JK, J, K, S S2, S4}
BP(BC,FG)= bande passante (Bι)+ bande passante (B2)=20 BP(C,FG)= bande passante (B2)=10 BP(JK,FG)= bande passante (B3) =10 BP(J,FG)= bande passante (B4)=10 BP(K,FG)=bande passante(B5)=10 BP(Sι,FG)= bande passante (Bi) + bande passante (B2)=20 BP(S2,FG)= bande passante (Bι)+ bande passante (B2)=20 BP(S4,FG)= bande passante (B3)=10
d'où, là aussi, rBP(FG)=20. Le tunnel B5 est retenu puisque rBP(FG)≤RBP(FG). On notera que B5 permet également de protéger le lien KL sans réservation supplémentaire de bande passante sur le lien FG.
Selon un premier mode de réalisation, les tunnels de bypass sont créés de manière centralisé par un serveur spécialisé. Celui-ci dispose de la topologie du réseau et connaît les bandes passantes réservées pour le trafic et pour la protection sur chacun des liens du réseau. Il prend en compte également les spécifications de l'opérateur quant aux éléments non susceptibles de protection et/ou ceux ne pouvant servir à la protection.
Selon un second mode de réalisation, de type distribué, lorsqu'un chemin est établi à travers le réseau, le routeur d'entrée peut spécifier que le chemin en question doit faire l'objet de protection. Pour ce faire, il est prévu une extension du protocole IGP (ou des protocoles ISIS ou OSPF qui sont des protocoles IGP déjà étendus pour l'ingénierie de trafic) permettant, selon un mécanisme d'inondation, de renseigner chaque nœud non seulement sur la topologie du réseau et sur les tunnels créés, comme dans l'état de la technique, mais également sur les tunnels de bypass déjà créés et les éléments respectifs protégés par ces tunnels. La base de données locale (TED) de chaque nœud contient ainsi une information indiquant les tunnels de bypass créés avec leurs caractéristiques (NHOP, NNHOP, chemin, bande passante, par exemple) ainsi que les éléments qu'ils protègent. Lorsqu'un tunnel de bypass est créé ou détruit, les nœuds du réseau en sont avertis au moyen de messages de création/ destruction permettant de mettre à jour leurs bases de données respectives.
La protection est demandée par le routeur d'entrée au moyen du message « Path » du protocole RSVP-TE, mentionné dans la partie introductive. Plus précisément, ce routeur incorpore dans l'objet « attribut de session » ou SAO (pour Session_Attribute Object) les informations suivantes :
- un bit LPD (Local Protection Desired) indiquant à chaque routeur de transit qu'une protection locale du chemin est requise ; - un bit NPD (Node Protection Desired) indiquant à chaque routeur de transit qu'un tunnel de bypass de type NNHOP est requis. A contrario, un tunnel de bypass de type NHOP est utilisé ;
- un bit BPD (Bandwidth Protection Desired) indiquant à chaque routeur qu'une protection de la bande passante est requise c'est-à-dire que le tunnel de bypass doit offrir une bande passante au moins égale à celle du chemin à protéger.
Lorsqu'un routeur de transit R sur le chemin en question reçoit un message « Path » du protocole RSVP-TE, il recherche tout d'abord si une protection est requise et quel est son type (NHOP, NNHOP). Selon le cas, la protection concerne soit le lien, soit le nœud, en aval du routeur sur le chemin. Le routeur R recherche ensuite dans sa base de données locale s'il existe déjà au moins un tunnel de bypass passant par R. Si ce n'est pas le cas, il recherche s'il peut construire un tunnel de bypass utilisant partiellement ou entièrement des éléments de tunnels de bypass existants. Le routeur obtient ainsi un certain nombre de tunnels de bypass candidats qui sont soumis aux étapes de sélection (2) à (5) indiquées plus haut. Si l'un des candidats est retenu, le routeur, après qu'il a reçu réception du message « RESV » du protocole RSVP, crée effectivement le tunnel de bypass et lui attribue la bande passante nécessaire. Pour chaque lien L constituant le tunnel de bypass on procède à une réservation de bande passante rBP(L)=max (BP(Φ, L)) où Φ s LFRG(L). Si le routeur de transit ne peut établir de tunnel de bypass, par exemple pour raison de bande passante insuffisante, il en avertit le routeur d'entrée.
Il est clair pour l'homme du métier que la requête de protection et l'acquittement de réservation peuvent également être transmis au moyen du protocole CR-LDP en lieu et place du protocole RSVP-TE.

Claims

REVENDICATIONS 1) Méthode de protection de chemins à commutation d'étiquettes dans un réseau MPLS comprenant une pluralité de nœuds reliés par des liens IP, un chemin passant par une série déterminée de nœuds et de liens dudit réseau, dits éléments dudit chemin, un élément d'un chemin pouvant être protégé au moyen d'au moins un tunnel de bypass dudit chemin, partant d'un nœud dudit chemin en amont dudit élément à protéger et se terminant en un nœud dudit chemin en aval dudit élément à protéger, caractérisée . en ce que, pour un élément de chemin à protéger d'une défaillance,
- pour chaque élément physique dudit réseau, on détermine un groupe (SRLG) de liens dudit réseau atteints par la défaillance dudit élément physique, puis pour chaque lien dudit réseau, on détermine la liste desdits groupes auxquels il appartient et,
- on sélectionne un tunnel de bypass, dit tunnel de bypass candidat, parmi un ensemble de tunnels de bypass susceptibles de protéger ledit élément de chemin à protéger,
- on détermine si les listes desdits groupes, respectivement associées au lien constituant ledit élément à protéger ou au lien en amont dudit élément à protéger et à chaque lien du tunnel candidat sont disjointes afin de tester si chaque lien du tunnel de bypass candidat présente un risque de défaillance indépendant du risque de défaillance dudit lien à protéger ou dudit lien amont,
- si tel n'est pas le cas, ledit tunnel de bypass est refusé et l'on sélectionne un autre tunnel de bypass candidat parmi tous ceux qui sont susceptibles de protéger ledit élément de chemin et on recommence les étapes précédentes,
- mais si tel est le cas, on teste si la bande passante à réserver sur chaque lien dudit tunnel de bypass candidat pour supporter ledit tunnel de bypass ou tous lesdits chemins de bypass passant par ledit lien est inférieure ou égale à la bande passante maximale dudit lien réservable à la protection et
- si tel est le cas, ledit tunnel de bypass est retenu alors qu'il est refusé dans le cas contraire. 2) Méthode de protection selon la revendication 1, caractérisée en ce que l'élément à protéger d'une défaillance étant un lien, on détermine si chacun desdits liens constituant ledit tunnel de bypass candidat présente un risque de défaillance indépendant du risque de défaillance dudit lien. 3) Méthode de protection selon la revendication 1, caractérisée en ce que l'élément à protéger d'une défaillance étant un noeud, on détermine si chacun desdits liens constituant ledit tunnel de bypass candidat présente un risque de défaillance indépendant du risque de défaillance du lien, dit lien amont, joignant le nœud en amont dudit nœud à protéger et ce dernier nœud.
4) Méthode de protection selon une des revendications précédentes, caractérisée en ce que la bande passante maximale d'un lien réservable à la protection est la somme maximale de toutes les bandes passantes des tunnels de bypass passant par ce lien et simultanément actifs. 5) Méthode de protection selon l'une des revendications précédentes, caractérisée en ce que lesdits tunnels de bypass sont déterminés de manière centralisé par un serveur.
6) Méthode de protection selon l'une des revendications 1 à 4, caractérisée en ce qu'un tunnel de bypass d'un élément d'un chemin à protéger est déterminé par un nœud en amont dudit élément sur ce dernier chemin.
EP03727556A 2002-02-21 2003-02-20 Methode de protection locale de chemins a commutation d etiq uettes avec partage de ressources Withdrawn EP1476991A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0202436 2002-02-21
FR0202436A FR2836313A1 (fr) 2002-02-21 2002-02-21 Methode de protection locale de chemins a commutation d'etiquettes avec partage de ressources
PCT/FR2003/000563 WO2003071746A1 (fr) 2002-02-21 2003-02-20 Methode de protection locale de chemins a commutation d'etiquettes avec partage de ressources

Publications (1)

Publication Number Publication Date
EP1476991A1 true EP1476991A1 (fr) 2004-11-17

Family

ID=27636441

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03727556A Withdrawn EP1476991A1 (fr) 2002-02-21 2003-02-20 Methode de protection locale de chemins a commutation d etiq uettes avec partage de ressources

Country Status (5)

Country Link
US (1) US20050188100A1 (fr)
EP (1) EP1476991A1 (fr)
AU (1) AU2003233843A1 (fr)
FR (1) FR2836313A1 (fr)
WO (1) WO2003071746A1 (fr)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100462408B1 (ko) * 2002-12-10 2004-12-17 한국전자통신연구원 Ｇｍｐｌｓ를 통한 빠른 재 루트 방법
US7343423B2 (en) * 2003-10-07 2008-03-11 Cisco Technology, Inc. Enhanced switchover for MPLS fast reroute
FR2869746B1 (fr) * 2004-04-29 2006-07-28 Alcatel Sa Dispositif de repartition de charge, multi-criteres, pour un equipement peripherique d'un reseau de comminications a commutation d'etiquettes
US7370119B2 (en) * 2004-05-21 2008-05-06 Cisco Technology, Inc. Scalable MPLS fast reroute switchover with reduced complexity
US7746793B2 (en) * 2004-06-18 2010-06-29 Cisco Technology, Inc. Consistency between MPLS forwarding and control planes
EP1763181A1 (fr) * 2005-09-12 2007-03-14 Siemens Aktiengesellschaft Méthode et appareils pour une modification de routage des paquets de données dans un réseau de communications
JP4491397B2 (ja) * 2005-10-07 2010-06-30 アラクサラネットワークス株式会社 トラフィック迂回機能を備えるパケット転送装置。
US7778248B2 (en) * 2005-10-28 2010-08-17 Cisco Technology, Inc. Method and apparatus for prioritized processing of routing information
US8688856B2 (en) * 2006-01-24 2014-04-01 Novell, Inc. Techniques for managing a network delivery path of content via a key
CN101079729B (zh) * 2006-05-23 2011-04-20 华为技术有限公司 对网络资源进行预留的方法
CN101087221B (zh) * 2006-06-07 2010-12-08 华为技术有限公司 资源预留协议节点及其交互方法
US7889641B2 (en) * 2006-07-18 2011-02-15 Opnet Technologies, Inc. Path flow formulation for fast reroute bypass tunnels in MPLS networks
CN100596100C (zh) * 2006-08-29 2010-03-24 华为技术有限公司 实现多协议标签交换网络差分业务流量工程的方法和系统
CN101136788A (zh) * 2006-08-30 2008-03-05 华为技术有限公司 一种mpls组播的故障定位方法及系统
CN101155064A (zh) * 2006-09-26 2008-04-02 华为技术有限公司 流量工程链路资源信息的处理方法
US8189482B2 (en) * 2007-02-20 2012-05-29 Cisco Technology, Inc. Probing-based mechanism to reduce preemption perturbation caused by higher priority tunnel establishment in a computer network
US8040792B2 (en) * 2007-08-02 2011-10-18 Foundry Networks, Llc Techniques for determining local repair connections
US8711676B2 (en) * 2007-08-02 2014-04-29 Foundry Networks, Llc Techniques for determining optimized local repair paths
US8145056B2 (en) * 2007-08-27 2012-03-27 Futurewei Technologies, Inc. Distributed wavelength conversion control for signaling protocols
US7782762B2 (en) * 2007-09-21 2010-08-24 Alcatel Lucent RSVP-TE enhancement for MPLS-FRR bandwidth optimization
US8358576B2 (en) * 2007-10-03 2013-01-22 Foundry Networks, Llc Techniques for determining local repair paths using CSPF
US8724637B2 (en) * 2008-06-04 2014-05-13 Futurewei Technologies, Inc. System and method for multi-topology support
US8374502B2 (en) * 2009-02-27 2013-02-12 Futurewei Technologies, Inc. Open shortest path first extensions in support of wavelength switched optical networks
US8243585B2 (en) * 2009-08-25 2012-08-14 Alcatel Lucent Method and apparatus for fault-resilient multicast using multiple sources
CN102143066B (zh) * 2011-02-17 2014-12-24 华为技术有限公司 建立标签交换路径的方法、节点设备和系统
US9356859B2 (en) 2011-08-16 2016-05-31 Brocade Communications Systems, Inc. Techniques for performing a failover from a protected connection to a backup connection
CN102870431B (zh) * 2012-06-20 2015-09-09 华为技术有限公司 一种恢复路径建立的方法、系统和节点设备
US10187298B2 (en) 2014-10-27 2019-01-22 Juniper Networks, Inc. Merge point determination in refresh interval independent fast reroute facility protection
US11863430B2 (en) * 2022-02-18 2024-01-02 At&T Intellectual Property I, L.P. Dynamic shared risk link group (SRLG) compression

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU7078500A (en) * 1999-09-14 2001-04-17 Megaxess, Inc. Method and apparatus for prevention of congestion in atm networks through atm protection switching
CA2310872A1 (fr) * 1999-12-22 2001-06-22 Nortel Networks Corporation Commutation de protection automatique au moyen de la redondance au niveau liaison en soutien a la commutation d'etiquettes multi-protocole
EP1130853A1 (fr) * 2000-02-29 2001-09-05 Siemens Aktiengesellschaft Dispositif de circuit pour la commutation de substitution d' installations de transmission dans des architectures d' anneau avec des paquets de MPLS
US7234001B2 (en) * 2000-12-20 2007-06-19 Nortel Networks Limited Dormant backup link for OSPF network protection
US20020112072A1 (en) * 2001-02-12 2002-08-15 Maple Optical Systems, Inc. System and method for fast-rerouting of data in a data communication network
JP3700596B2 (ja) * 2001-03-14 2005-09-28 日本電気株式会社 通信ネットワーク及びパス設定方法並びにパス設定用プログラム
WO2002087175A1 (fr) * 2001-04-19 2002-10-31 Fujitsu Limited Procede et appareil de restauration/protection
US6778492B2 (en) * 2002-01-17 2004-08-17 Cisco Technology, Inc. Load balancing for fast reroute backup tunnels
KR100420956B1 (ko) * 2002-02-09 2004-03-02 주식회사 케이티 Ｍｐｌｓ 망에서 대체 경로를 공유하는 방법, 대체 경로를설정하는 레이블 스위칭 라우터 및 그 시스템
US6978394B1 (en) * 2002-02-22 2005-12-20 Cisco Technology, Inc. Linear program-based technique for placing FRR TE tunnels with bandwidth guarantee
US7099286B1 (en) * 2002-05-22 2006-08-29 Cisco Technology, Inc. Method and system for finding shared risk diverse paths

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03071746A1 *

Also Published As

Publication number Publication date
FR2836313A1 (fr) 2003-08-22
US20050188100A1 (en) 2005-08-25
WO2003071746A1 (fr) 2003-08-28
AU2003233843A1 (en) 2003-09-09

Similar Documents

Publication Publication Date Title
EP1476991A1 (fr) Methode de protection locale de chemins a commutation d etiq uettes avec partage de ressources
WO2003071745A1 (fr) Methode dynamique et distribuee de protection locale d&#39;un chemin a commutation d&#39;etiquettes
EP2067317B1 (fr) Procédé de routage dans un réseau de commutation par étiquettes
JP5752127B2 (ja) ポイント・ツー・マルチポイント・ネットワークにおける重複トラフィック回避
EP2033380B1 (fr) Procede de routage de liens virtuels dans un reseau a commutation de trames a determinisme garanti
EP1650910B1 (fr) Contrôle des paramètres d&#39;une connexion Ethernet-GMPLS
FR2876525A1 (fr) Procede et dispositif de creation d&#39;un tunnel dans un reseau de telecommunication a permutation d&#39;etiquettes
FR2931604A1 (fr) Technique de protection dans un reseau de communication en mode connecte d&#39;un arbre primaire point a multipoint.
WO2011086250A1 (fr) Liason virtuelle entre operateur de reseau
EP2070268B1 (fr) Routeur coeur apte a securiser un routeur de sortie d&#39;un systeme autonome
EP1432184B1 (fr) Dispositif de détermination de chemins de communication dans un réseau de communications à commutation d&#39;étiquettes, en présence d&#39;attributs de sélection
FR2934450A1 (fr) Distribution de routes dans un reseau de routeurs.
Carvalho et al. Policy-based fault management for integrating IP over optical networks
EP2238718B1 (fr) Technique pour protéger un chemin à commutations d&#39;étiquettes en mode connecté lors d&#39;une panne affectant un noeud donné du chemin
EP1878172B1 (fr) Controle de la reservation de ressources partagees de chemins de connexion dans un reseau de communication a commutation d&#39;etiquettes de type &#34;non paquet&#34;
Clad Disruption-free routing convergence: computing minimal link-state update sequences
Das et al. A method of designing a path restoration scheme for MPLS based network
EP2235893B1 (fr) Technique pour protéger un chemin à commutation d&#39;étiquettes multipoint à multipoint en mode connecté lors d&#39;une panne affectant un noeud donné du chemin
EP2198573B1 (fr) Procédé pour faire communiquer entre eux une pluralité de noeuds d&#39;extrémité à travers un réseau de communication
Saidi et al. Targeted distribution of resource allocation for backup LSP computation
EP2119140B1 (fr) Procede d&#39;acheminement par un routeur d&#39;un paquet de donnees dans un reseau de communication par paquets supporte par un reseau de transport
Huang et al. Inter-domain, MPLS restoration

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040625

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100901