Network Working Group JL. Le Roux Internet Draft France Telecom R&D Expiration Date: August 2002 G. Calvignac France Telecom R&D February 2002 A method for an Optimized Online Placement of MPLS Bypass Tunnels draft-leroux-mpls-bypass-placement-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The present document focuses on the MPLS Fast Reroute many-to-one solution. It defines on the one hand, a specific PLR behavior for the dynamic setup of bypass LSPs, and on the other hand a distributed bypass LSP path computation mechanism, taking into account the possibility to share protection resources. It proposes ISIS-TE/OSPF-TE and RSVP-TE extensions required to support the described functionality. Le Roux et al. Expires August 2002 [Page 1] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 Table of Contents 1. Introduction................................................3 1.1. Abbreviations...............................................4 2. Definitions.................................................4 3. Solution overview...........................................5 4. Dynamic bypass tunnel setup.................................7 4.1. SESSION_ATTRIBUTE parameters................................8 4.2. Bandwidth protection........................................8 4.3. Bypass LSP properties.......................................9 4.3.1. Bypass bandwidth............................................9 4.3.2. Bypass priority............................................10 4.3.3. Parallel links.............................................10 4.4. Dynamic bypass creation on PLRs............................11 4.4.1. PLR behavior...............................................11 4.4.2. Example....................................................13 5. Protection bandwidth: Definition, sharing and accounting...14 5.1. Protection bandwidth pool..................................14 5.2. Protection Resource Sharing principle: PRS.................14 5.3. SRLG information...........................................15 5.4. Failure Risks: FR..........................................17 5.4.1. Protected Failure Risk Group of a Bypass LSP: PFRG(B)......17 5.4.2. Protected Failure Risk Group on a link: PFRG(L)............18 5.4.3. Protection Bandwidth on a link L, for a Failure Risk F: PB(L, F).................................................18 5.4.4. Example....................................................19 5.5. PRS-aware accounting of reserved protection bandwidth......20 5.6. PRS-aware bypass admission control on a link...............21 6. PRS-aware online bypass path computation...................22 7. Routing extensions for PRS-aware bypass path computation...24 7.1. New TE link parameters for protection......................24 7.1.1. Protection bandwidth.......................................24 7.1.2. SRLG.......................................................25 7.2. Bypass advertisement.......................................26 7.2.1. Tail Router ID sub-TLV.....................................26 7.2.2. Path sub-TLV...............................................27 7.2.3. Bypass Information sub-TLV.................................27 7.3. PLR processing.............................................28 7.4. Bypass database............................................29 8. RSVP-TE extensions for bypass LSPs setup...................29 8.1. Bypass object..............................................29 8.2. Processing of the Bypass Object............................31 9. Security Considerations....................................31 10. Intellectual property consideration........................31 11. Acknowledgment.............................................31 12. References.................................................32 13. Authors Information........................................32 Le Roux et al. Expires August 2002 [Page 2] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 1. Introduction MPLS local protection consists in establishing, locally, backup LSPs to protect against link or node failure. Backup LSPs start at a point of local repair (PLR) and end at a merge point (MP). In case of failure on the protected node or link, the PLR splices the traffic onto the corresponding backup LSPs. [FRR] proposes two main solutions for the local protection of TE LSPs, the one-to-one solution, which consists in establishing one "detour" LSP per primary LSP to be locally repaired, and the many-to- one solution, which allows the protection of many LSPs by the same "bypass" LSP using LSP nesting technique. The solution here is based on the many-to-one scheme, i.e. on bypass LSPs. Several options are mentioned in [FRR] for the creation and placement of bypass LSPs: -They can be setup initially or dynamically. -Their path can be statically configured on each PLR, it can be computed by an offline tool, or it can also be computed online by PLRs. This document focuses, firstly on the dynamic setup of bypass LSPs, and secondly on an online bypass path computation by PLRs. A specific PLR behavior is proposed for dynamic setup of bypass LSPs, triggered by LSPs requiring local repair. A distributed bypass path computation algorithm is proposed, which takes into account the possibility to share protection resources. This requires several routing and signalling extensions, which are proposed at the end of the document. The main characteristics of the proposed solution are: -Scalability, as it is based on the many-to-one scheme. -Automaticity, as it does not require manual intervention to configure bypass LSPs on each PLR. -Distributed computation, as it does not require a centralized server. -Optimisation, as it proposes a path computation taking into account protection resource sharing, PRS. Le Roux et al. Expires August 2002 [Page 3] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 1.1. Abbreviations BAC Bypass Admission Control BEB Best Effort Bypass PB Protection Bandwidth on a link, for a failure risk. BPB Bandwidth Protection Bypass BPD Bandwidth Protection Desired BPU Bandwidth Protection Undesired. CSPF Constraint-based Shortest Path First algorithm FR Failure Risk LPD Local Protection Desired LSP Label Switched Path LSR Label Switching Router MP Merge Point MRPbw Maximum Reservable Protection bandwidth NHOP Next Hop NPD Node Protection Desired NNHOP Next Next Hop PFRG Protected Failure Risk Group of a link or bypass LSP. PLR Point of Local Repair PRS Protection Resource Sharing RPbw Protection Bandwidth Reserved on a link RRO RSVP Record-Route Object SAO RSVP Session_Attribute Object SRLG Shared Risk Link Group TE Traffic Engineering 2. Definitions This document is in full conformance with the sections of [FRR] defining the bypass mechanisms for the many-to-one solution. This document only proposes several extensions for the purpose of an online bypass path computation taking into account protection resources sharing. A bypass tunnel is an LSP, which is used to protect a downstream link or node. Many primary LSPs can use the bypass facility in case of failure, using LSP nesting principle. RSVP-TE extensions (mainly SAO and RRO) and specific processing for bypass tunnels utilisation are defined in [FRR]. This document is in full conformance with these extensions. The PLR (Point of Local Repair) is the bypass head-end node. It splices traffic on the bypass LSP in case of failure. The MP (Merge Point) is the bypass tail-end node. On this point, backup LSPs are merged into corresponding primary LSPs. Two types of bypass tunnels are defined in [FRR], regarding the entities they protect: Le Roux et al. Expires August 2002 [Page 4] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 -A link protection bypass tunnel (also called NHOP bypass tunnel) protects against failures occurring on a downstream link connecting a PLR and a PLR next-hop node. The head end is the PLR and the tail-end is the PLR next hop. It may be used, in case of failure, by primary LSPs using the downstream link. -A node protection bypass tunnel (also called NNHOP bypass tunnel) protects against several failures occurring on a downstream node. The head end is a PLR, the tail end is a PLR next-next-hop. It may be used, in case of failure by primary LSP whose path includes the PLR->PLR_NHOP->PLR_NNHOP trunk. Note that node protection implies also protection of the downstream link PLR->PLR_NHOP. This document does not modify basic bypass mechanisms. 3. Solution overview Firstly, in 4, we propose a specific PLR behavior and several rules, for dynamic setup of bypass LSPs, triggered by primary LSPs requiring local protection. Basically, it consists in setting up bypass tunnels dynamically and mutualizing the bypass tunnels as much as possible, for the particular entity (node/link) to be protected: In case a new primary LSP requiring local protection is being established, if a bypass tunnel already exists then use that one as long as there is enough bandwidth left on the links it goes through, and increment the bandwidth of this bypass tunnel (if bandwidth protection is desired). If there is no bypass tunnel, or no available bandwidth on existing bypass paths, then compute and establish a new bypass tunnel, which handles the local protection requirement. The bandwidth of the new bypass should be equal to the primary LSP bandwidth if bandwidth protection is desired, if not then it should be 0. Note that two types of bypass LSPs are distinguished: Bypass LSPs which reserve protection resources (ie bw>0), called Bandwidth Protection Bypass, and bypass LSPs which do not reserve protection resources (ie bw=0), called Best Effort Bypass. The second part of the document (section 5,6,7 and 8) focuses on a distributed solution for Protection Resource Sharing, PRS. It is not relevant for Best Effort Bypass LSPs, which do not reserve protection resources. The main concept behind this is that, in most cases, failures will impact a single entity (node/link/SRLG) at a time. Therefore protection resources can possibly be shared between bypass tunnels protecting different entities, since in case of failure, only the bypass tunnels, which will actually be used by the impacted protected LSP, will make use of the protection resource. Le Roux et al. Expires August 2002 [Page 5] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 Here we propose a PRS-aware online bypass path computation mechanism, and a PRS-aware bypass local admission control. It requires several routing and signalling extensions. In 5, we define a new protection bandwidth pool dedicated to bypass LSPs. Two new link parameters are defined: The Maximum Reservable Protection bandwidth, MRPbw, and the Reserved Protection bandwidth, RPbw. The reserved protection bandwidth can be expressed as the highest cumulated bandwidth of bypass tunnels that could be active at the same time in case of failure. An algorithm is then proposed for the accounting of reserved protection bandwidth. Based on this algorithm we define a PRS-aware admission control on links, for bypass tunnels. This admission control requires having knowledge of all bypass tunnels that goes through a link, and the entities they are protecting. In 6, we propose a PRS-aware CSPF for bypass path computation by PLRs. It consists in modifying classical CSPF to take into account PRS. Basically a PRS-aware admission control must be performed on all candidate links for the path. Links that do not support the required protection bandwidth must be pruned from topology. To perform this PRS-aware admission control on a link, the PLR must have knowledge of all bypass LSPs that are already established on the link, and the entities they are protecting. Thus, a LSR has to have knowledge of the whole bypass topology. Routing extensions are required to advertise the whole bypass topology. In 7, we propose extensions to ISIS-TE/OSPF-TE to support PRS-aware online bypass path computation. A new sub-TLV is defined to advertise the Maximum Reservable Protection Bandwidth on a link. It must be included in the ISIS-TE IS reachability TLV, and OSPF-TE Link TLV, to support the proposed functionality. A new TLV is defined to advertise a bypass LSP attached on a given PLR, and its properties (path, bandwidth, protected link, protected node). To support the proposed functionality, it may be included in the ISIS LSP and in the OSPF TE-LSA. This new TLV enables to distribute the whole bypass topology. The information may be used by LSRs to maintain a bypass database that will be used during bypass path computation to verify if protection resource can be shared. In 8, we propose an RSVP-TE extension for bypass LSP setup. The local admission control of bypass LSPs requires the knowledge of the entity they are protecting. A new object is defined, to advertise that an LSP is a bypass LSP, and to specify the entities it is protecting. To support the proposed functionality, it must be included in the path message corresponding to a bypass LSP. Le Roux et al. Expires August 2002 [Page 6] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 4. Dynamic bypass tunnel setup Bypass tunnels can be pre-established, but this requires a centralized server or a manual intervention at each node. Another option, that minimizes operational costs, is a dynamic bypass path computation by PLR, triggered by an LSP requiring protection. Note this dynamic bypass creation is mentioned in [FRR] (bypass section), and we intend here to specify more precisely a possible PLR behavior. In this section we just focus on the triggering mechanism. In 5 and 6 we will propose a distributed protection resources sharing mechanism, and, in 7 and 8, the required routing and signalling extensions. Basically, the triggering mechanism is the following: When a primary LSP is established with local repair required, each transit LSR on the primary path must check if there is already a bypass tunnel that can address the required protection (link or node, bandwidth). If a bypass is found, its bandwidth may be updated depending on the protection bandwidth required by the primary LSP. This bypass will be used by the primary LSP in case of failure. If there is no such bypass available, transit LSRs try to compute and establish a new bypass tunnel addressing constraints, which may be subsequently reused to protect other primary LSPs. Note that the bandwidth of this new bypass must be initially equal to the bandwidth of the triggering LSP, if bandwidth protection is required, or else 0. Note that two types of bypass LSPs are distinguished: Bypass LSPs that ensure bandwidth protection, and Bypass LSPs that do not ensure bandwidth protection. When a primary LSP is torn down, bandwidth of bypass tunnels protecting this LSP may be decremented. Bypass tunnels that were protecting only this LSP may also be torn down. It MUST be possible to deactivate, by configuration, dynamic bypass creation on a node, if the network administrator does not want this node to establish bypass tunnels. In that case, the node must ignore local repair request. Le Roux et al. Expires August 2002 [Page 7] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 4.1. SESSION_ATTRIBUTE parameters All information concerning the desired protection for an LSP is included in the RSVP SESSION_ATTRIBUTE Object (SAO). The head-end LSR can specify the desired protection (Link or Node protection, Bandwidth protection) by setting the appropriate flags in the SAO. - The local protection desired bit (LPD) indicates, if set, that transit LSR may protect this LSP using a bypass tunnel. - The node protection desired bit (NPD) indicates, if set, that NNHOP bypass tunnels should be used to protect this LSPs (except the penultimate hop). - The bandwidth protection desired bit (BPD) indicates, if set, that the bypass tunnel should offer to the protected LSP, an equivalent bandwidth. These parameters are specified in detail in [FRR] (many-to-one section). Note that BPD bit should not be set if LSP bandwidth is zero. Notation: A BPD LSP is an LSP with bandwidth protection desired. A BPU (Undesired) LSP is an LSP without bandwidth protection desired. 4.2. Bandwidth protection In section 4 of [FRR], it is mentioned the possibility to maintain protected LSP bandwidth after failure. This is called bandwidth protection. So there are to types of protected LSPs: -Bandwidth protected LSPs -Bandwidth unprotected LSPs. These two types of LSPs must be protected by distinct bypass LSPs. So we define two types of bypass LSPs: -Bypass LSPs that ensure bandwidth protection. They are called Bandwidth Protection Bypass (BPB). -Bypass LSPs that do not ensure bandwidth protection. They are called Best Effort Bypass (BEB). Bandwidth protection bypass LSPs should protect only BPD LSPs. Best Effort bypass LSPs should protect BPU LSPs, and also BPD LSPs whose bandwidth protection request can't be enforced. Le Roux et al. Expires August 2002 [Page 8] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 The only parameter that distinguishes these two types of bypass LSPs is their bandwidth. -Bandwidth of BPB must be equal to the cumulated bandwidth of LSPs that they protect. They reserve protection resources (bw(BPB)>0). -Bandwidth of BEB must be zero. They do not reserve protection resources (bw(BEB) = 0). In the rest of the document we don't make distinction between these two types. We only deal with "bypass LSPs". BEB are only a particular case of bypass LSP, with zero bandwidth. Example: Let's assume that 3 LSPs require NHOP local repair, for the same link, on the same PLR: -LSP 1: bw 50M, BPD. -LSP 2: bw 30M, BPU. -LSP 3: bw 40M, BPU. Two bypass tunnels are required to ensure the protection: A bypass LSP with bandwidth 50M, to protect LSP1. A bypass LSP with bandwidth 0, to protect LSP 2 and 3. Note that this is obviously not sufficient to ensure bandwidth protection. A DiffServ mechanism could be used to differentiate BEB and BPB, and to ensure bandwidth guaranties to BPB. 4.3. Bypass LSP properties 4.3.1. Bypass bandwidth The bandwidth of a bypass LSP must be signalled as a classical LSP in the RSVP Sender_Tspec and Flow_Spec objects. As mentioned previously, -bw(BPB)= sum (bw( protected LSPs)) > 0 -bw(BEB)= 0. As explained latter in the document, a new bandwidth pool, the link protection bandwidth, is defined for bypass LSPs (see 5.1). So there is a distinct admission control for primary and bypass LSPs. Thus primary and bypass LSP must be distinguished in signaling. A new RSVP object is defined in 8, for the setup of bypass LSPs. It is used to indicate that an LSP is a bypass LSP, and specific bypass properties. Le Roux et al. Expires August 2002 [Page 9] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 4.3.2. Bypass priority In this first specification, pre-emption of bypass LSPs is not supported. All bypass LSPs have the same priorities (7,7) whatever the priorities of the primary LSPs they are protecting may be. Note that primary LSPs and bypass LSPs work on two separate bandwidth pools (see 5.1). Thus there is no competition between them. 4.3.3. Parallel links For a better protection resource sharing (see section 5), it's better to isolate failure risk, so we defines the following rules: -A NHOP bypass is protecting only one downstream link. -A NNHOP bypass is protecting only one couple (downstream link, downstream node). --------------- | | | | figure 1 |----|1--------|----| |----| | A |2--------| B |--------| C | |----|3--------|----| |----| | | |----------------------------| So, for instance, on figure 1: A NHOP bypass LSP, B1, is established from A to B, to protect link A1->B. It can be used only to protect LSPs going through A1->B. Other NHOP bypass LSPs must be setup to protect LSPs going through A2->B or A3->B. A NNHOP bypass LSP B2 is established from A to C to protect (link A2- >B, node B). It can be used only by LSPs going through A2->B->C. Other NNHOP bypass LSPS must be setup to protect LSPs going through A1->B->C and A2->B->C. There is a lost in terms of scalability. The reason for these rules is a better protection resources sharing by isolating failures as much as possible. Note that a trade-off must be found between high scalability and protection resource sharing. Le Roux et al. Expires August 2002 [Page 10] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 4.4. Dynamic bypass creation on PLRs 4.4.1. PLR behavior The mechanism proposed here consists in an automatic bypass establishment, triggered by primary LSP requiring protection. It must be possible to Activate/Deactivate this triggering on an LSR, by configuration, globally or on a specific interface. We define distinct processing, for PBD and PBU LSP. When there is not enough protection bandwidth to protect a PBD LSP, it may be handled as a PBU LSP. -PBD LSP processing: When an LSR receives a Resv message for an LSP l, desiring local protection, and also bandwidth protection, it must performs the following tasks: 1- Check among its bandwidth protection bypass LSPs (ie bypass LSPs with bw > 0) already established, if there are candidates to protect l. A candidate bypass tunnel, in case of link protection, is a tunnel which protects l downstream link and whose tail-end is l next-hop. In case of node protection, it's a tunnel which protects l downstream link, l downstream node, and whose tail- end is l next-next hop. Then remove from the candidate list, bypass LSPs whose path cannot address the required protection bandwidth. For this, for each candidate bypass tunnel B, check if all the links along the path of B can support the bandwidth increment bw(B)+bw(l). A mechanism to perform these protection resources verifications is proposed in section 5, and more particularly in section 5.6. 2- If there are still one or more candidate bypass LSPs, then select one of them, B, and, modify bw(B) by a make-before-break mechanism (bw(B)=bw(B)+ bw(l)). Then update the protection database (i.e. map l to B). 3- If there is no candidate bypass LSP, and if bypass triggering is activated globally or on downstream interface of l, then compute a path for a new bypass tunnel which addresses the protection required by l (Link or node, bandwidth). If a path is found, establish the bypass LSP, B, with bw(B)=bw(l) . Then update the protection database (by mapping l to B). A mechanism for bypass path computation by PLR is proposed latter in the document (section 6). If no path is found, the bandwidth protection request cannot be addressed by the PLR. The PLR may process the LSP has a PBU LSP, and try to protect it with a Best Effort bypass LSP. The PLR may periodically try to recompute and setup a bandwidth Le Roux et al. Expires August 2002 [Page 11] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 protection bypass LSP. -PBU LSP processing: When an LSR receives a Resv message for an LSP l, with local protection desired, and bandwidth protection not desired it must performs the following tasks: 1- Check among its best effort bypass LSPs (ie bypass LSPs with bw = 0), already established, candidates to protect l. 2- If there are candidates, then select one of them, B, and update the protection database (by mapping l to B) 3-If there are no candidate then compute a bypass path with bandwidth zero. If a path is found, establish bypass B, and update protection database (by mapping l to B). If no path is found then the local repair request can't be ensured. The LSR may try periodically to find a path. Each transit LSR must then update the RRO with the result of the process: Local Protection available or not, bandwidth protection available or not (RRO). When the PLR computes a new bandwidth protection bypass path, or checks if there is available protection bandwidth on the existing bypass links to protect a supplementary primary LSP, it must also take into consideration the possibility to share bandwidth with other bypass tunnels which go through the same links, but protect different nodes/links and thus may not be active at the same time. Indeed, if two bypass tunnels B1 and B2 go through a common link L and protect distinct links that are SRLG diverse, or distinct nodes, in case of node protection, (this means that they will not be active at the same time), they can share bandwidth. The protection bandwidth reserved on L (RPbw(L)) must then be equal to RPbw(L)=Max(bw(B1), bw(B2)), in the particular case of only two bypass tunnels going over L. To perform these controls, the PLR must be aware of all bypass tunnels that go through a link, their bandwidth, and the entity (link, node), they are protecting. Mechanisms for bypass local admission control and bypass path computation, taking into account sharing of protection resources are defined in 5, 6 and the required routing/signalling extensions in 7, 8. Le Roux et al. Expires August 2002 [Page 12] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 4.4.2. Example Figure 2 [A]-----[B]-----[C]-----[D] | | | | [E]-----[F]-----[G]-----[H] | | | | [I]-----[J]-----[K]-----[L] Let's assume, that a new bandwidth pool, dedicated to protection (protection bandwidth), is configurable on each link and that bypass tunnel bandwidth reservation is performed on this protection bandwidth pool (see section 5.1 ). On all links the Max reservable Protection Bandwidth is set to 10M. Initially, no bypass tunnels are established. Bypass triggering is activated only on nodes F, G and K. A 5M LSP is established from E to H through F and G with local protection and bandwidth protection desired, and node protection not desired. F and G determine that here is not already a bypass tunnel protecting respectively links F->G and G->H. They compute a path for a bypass tunnel, respectively B1 and B2, with bandwidth 5M according to primary bandwidth. The paths computed are respectively F->B->C->G and G->C->D->H. The RRO received on E indicates that local protection and bandwidth protection are available only on F and G. The reserved protection bandwidth on links F->B, B->C, C->G , G->C, C->D, D->H is now 5M. A second LSP is established from I to H through J, K and G. Its bandwidth is 3M. The existing bypass B2, G->C->D->H, is a candidate bypass to protect this LSP. G checks if there is enough bandwidth on links G->C, C->D and D->H. It is the case, and bw(B2) is updated to 8M, using make- before-break. Note that there is no new RSVP session; this is a big advantage of the many-to-one solution. In return on K there is not yet a bypass tunnel to protect K->G. K computes and establishes a bypass B3, with bandwidth 3M from K to G through J and F. The protection bandwidth reserved on links K->J, J- >F, F->G is now 3M. Le Roux et al. Expires August 2002 [Page 13] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 5. Protection bandwidth: Definition, sharing and accounting 5.1. Protection bandwidth pool For good protection resources optimization and sharing, it is convenient to split the link resources into two pools: A primary bandwidth, which can be used by primary LSPs (it corresponds to classical TE bandwidth), and a protection bandwidth, which is used by bypass LSPs. This new resource pool must be advertised by IGP-TE protocols, as an additive TE parameter. In fact two parameters must be advertised: - The maximum reservable protection bandwidth (MRPbw), - The reserved protection bandwidth (RPbw). These extensions are described in section 7. Note that these values have unidirectional meaning, as classical TE bw. Links A->B and B->A may have distinct values, depending on bypass tunnels established through A->B and B->A and on configuration (for the max value). Bypass tunnels cannot be pre-empted, so only one value is advertised in IGP (not a value at each priority level). Note that protection bandwidth may be used by low priority LSPs that are pre-empted in case of failure on protected LSPs. This requires signaling extensions that are out of the scope of this document. Note that Best Effort Bypass LSPs do not reserve protection bandwidth. So all the following is relevant only for Bandwidth Protection bypass tunnels, ie bypass LSPs that reserve protection bandwidth. 5.2. Protection Resource Sharing principle: PRS There are different ways to count the protection bandwidth reserved on a link. The easiest way consists in adding the bandwidth reserved by each bypass tunnel. But this will result rapidly in the saturation of protection bandwidth. Example with figure 2: Let's assume that MRPbw is 0 on C->B, and 10M on all other links. A NNHOP bypass B1, B->C->G->K->J is already established, protecting node F with bandwidth 8M. So reserved protection bandwidth on B->C, C->G, G->K and K->J is 8M. Le Roux et al. Expires August 2002 [Page 14] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 D wants to establish a NHOP bypass, B2, to H, protecting link D-H, with bandwidth 3M. B2 cannot use C->B, in so far as there is no protection bandwidth on C->B. If C->G is used, reserved protection bandwidth on this link would become: bw(B1)+bw(B2)= 11M. So C->G cannot be used by B2, and there is no solution for this bypass. In fact, if we assume a single point of failure in a network, and if B-F and D-H do not share a common resource (fiber, DXC, OXC) then B2 could use link C->G, because both bypass tunnels will never be active at the same time. Indeed, in case of failure the protection bandwidth in use on C->G would be 8M, ie Max(bw(B1), bw(B2)). So B2 path could be D->C->G->H and the reserved protection bandwidth (RPbw) on C->G, would remain 8M. This is the concept of protection resource sharing. But for this mechanism to work, D must be aware of the first bypass already established, it must know its path, its bandwidth, and also which link and node this bypass is protecting. This requires extension to IGP-TE to advertise bypass tunnels, their properties and the entities they are protecting. In return, a NNHOP bypass LSP established by G to E, protecting node F could not share resources on link G->K and K->J, with the first bypass LSP established by B to J, protecting also F, because in case of failure of node F both bypass LSPs could be active. Thus for these two bypass tunnels, bandwidth must be added and not "maximized". In the following we define some rules for Protection resources sharing. 5.3. SRLG information The concept of SRLG is defined in [GMPLS-RTG]. A SRLG is a set of links that share a common resource whose failure may impact all links in the set. For instance two POS links using the same fiber belong to the same SRLG. An SRLG is defined by a 32 bit id, unique to the area. A link can belong to multiple SRLG, so the SRLG information of a link is a set of SRLG ids the link belongs to. Two links are said SRLG diverse if their SRLG sets are disjoint. By extension, two links that do not belong to any SRLG are said to be SRLG diverse. This information must be advertised in the routing protocol. If a link does not belong to any SRLG, no SRLG information is announced. Note that a node is not considered as a resource for a link. Two links that start at the same node are not necessarily in the same SRLG, even if node failure can impact both links at the same time. Le Roux et al. Expires August 2002 [Page 15] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 The SRLG set of an LSP is a concatenation of SRLG sets of links used by the LSPs. Two LSPs are said SRLG diverse if their SRLG set are disjoint. Example on figure 3: [R1] \ [O1] figure 3 | f1| | | | f2 [R2]-[O2]------[O3] | [R3] 3 routers R1, R2, R3 are connected to three OXC O1, O2, O3. OXC are interconnected by fibers f1 and f2 with WDM. 3 IP links are setup: R1-R2, R1-R3 and R2-R3. SRLG 1 and 2 are defined by the set of IP links going through fibers f1 and f2 respectively. R1-R2 uses the lightpath O1-O2, so its SRLG set is {1}. R1-R3 uses the lightpath O1-O2-O3, so its SRLG set is {1,2}. R2-R3 uses the lightpath O2-O3, so its SRLG set is {2}. Thus R1-R2 and R2-R3 are SRLG diverse. In return R1-R2 and R1, and, R1-R3 and R2-R3, are not SRLG diverse. We define a SRLG failure as the failure of the resource shared by all members of the SRLG. For instance, SRLG 2 failure corresponds to fiber 2 failure. A SRLG failure, or more exactly the failure of the shared resource, may trigger several link failures. For instance, SRLG 3 failure will trigger links R2-R3 and R1-R3 failures. In return, a link failure maybe independent from an SRLG failure. For instance a failure on the link R2-O2, connecting R2 to R3, triggers R2-R3 failure, and is independent from SRLG 2, indeed R1-R3 does not fail in that case. That is the reason why we distinguish link failure from SRLG failure. A SRLG failure trigger link failures, but a link failure maybe independent from any SRLG failure, for instance if a link does not belong to any SRLG! Le Roux et al. Expires August 2002 [Page 16] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 Note that we can configure a common SRLG on two links, even if there is no shared resource, if we want to be protected against multiple points of failure: This is the concept of Virtual SRLG. Note that the SRLG concept may be extended to nodes. A Shared Risk Node Group (SRNG) is a set of nodes that share, for instance, the same building. This is not supported in this document, but it is the same approach, and requires only a few extensions to what is described above. 5.4. Failure Risks: FR For protection bandwidth sharing purpose, it is necessary to identify the entities whose failure may activate a bypass LSP. Two bypass LSPs that protect a same entity cannot share protection bandwidth, whereas bypass LSPs that protect distinct entities can. We call these entities Failure Risks. We distinguish three types of FRs: a link, a node, or an SRLG. A SRLG FR corresponds to the risk of failure of the shared resource. We need to consider both link and SRLG FRs, to encompass links that do not belong to any SRLG. We gives in the following, several definitions, that will be useful the reserved bandwidth accounting method 5.4.1. Protected Failure Risk Group of a Bypass LSP: PFRG(B) As mentioned previously, there are two types of bypass tunnels: link protection and node protection bypass tunnels. A link protection bypass tunnel (NHOP bypass) starts at a PLR an ends at the PLR's next-hop. Of course it must not use the link it is protecting, but it must also be SRLG diverse with the link it is protecting. A node protection bypass tunnel (NNHOP bypass) starts at a PLR an ends at the PLR next-next-hop. It must not use the downstream node and link it is protecting, and it must also be SRLG diverse with the downstream link. A NNHOP bypass protects not only the downstream node, but also the downstream link. We define the Protected Failure Risk Group of a bypass LSP B, PFRG(B) as the set of FRs protected by B, i.e. the set of FRs whose failure will activate B utilisation. Le Roux et al. Expires August 2002 [Page 17] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 The PFRG of an NHOP bypass tunnel is the concatenation of the downstream link and its SRLG set. The PFRG of a NNHOP bypass tunnel is the concatenation of the downstream node it is protecting, but also, in so far as node protection encompasses attached link protection, the downstream link, and its SRLG set. The three conditions for bypass tunnels to be PFRG diverse are: 1- they do not protect the same link. 2- the link they protect are SRLG diverse. 3- they do not protect the same node (In case of NNHOP). 5.4.2. Protected Failure Risk Group on a link: PFRG(L) We define the protected Failure Risk group on a link L (unidirectional meaning), PFRG(L), as the set of FRs that are protected on the link. It corresponds to the concatenation of PFRG of bypass LSPs going through the link. Here "link" has a unidirectional meaning, there is no relationship between PFRG(I->J) and PFRG(J->I). 5.4.3. Protection Bandwidth on a link L, for a Failure Risk F: PB(L, F) We define the Protection Bandwidth, on a link L (unidirectional meaning), for a Failure Risk F, PBR(L, F), as the cumulated bandwidth of bypass LSPs protecting F, an using L. PB(L, F)= sum {bw(B)}, over B, where B goes through L and F belongs to PFRG(B). This corresponds to the aggregate bandwidth, of bypass LSPs that will be in use on L in case of failure F. Le Roux et al. Expires August 2002 [Page 18] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 5.4.4. Example Let's assume, on figure 2, that B-C belongs to SRLG 1 and 2, and J-K to SRLG 2. A NHOP bypass LSP B1 is established by B, to protect B->C, with bandwidth 10M. It goes through B->F, F->G and G->C. A NNHOP bypass LSP B2 is established by B to D, protecting node C, with bandwidth 10M. It goes through B->F, F->G, G->H and H->D. A NHOP bypass LSP B3 is established by J to L, to protect node K, with bandwidth 10M. It goes through J->F, F->G, G->H, H->L. A NNHOP bypass LSP B4 is established by I to K, protecting node J, with bandwidth 10M. It goes through I->E, E->F, F->G, G->K. The protected failure risk groups of bypass LSPs are: PFRG(B1) = {Link B-C, SRLG 1, SRLG 2}. PFRG(B2) = {Link B-C, Node C, SRLG 1, SRLG 2}. PFRG(B3) = {Link J-K, Node K, SRLG 2}. PFRG(B4) = {Link I-J, Node J}. On link F->G, 4 bypass tunnels are established: B1, B2, B3 and B4. The PFRG(F->G) is {Link B-C, Link J-K, Link I-J, Node C, Node K, Node J, SRLG 1, SRLG 2}. The protection bandwidth on link F->G, are for each protected FR: PB(F->G, Link B-C)=bw(B1)+bw(B2)=20M. PB(F->G, Link J-K)=bw(B3)=10M. PB(F->G, Link I-J)=bw(B4)=10M. PB(F->G, Node C)=bw(B2)=10M. PB(F->G, Node K)=bw(B3)=10M. PB(F->G, Node J)=bw(B4)=10M. PB(F->G, SRLG 1)=bw(B1)+bw(B2)=20M. PB(F->G, SRLG 2)=bw(B1)+bw(B2)+bw(B3)=30M. Le Roux et al. Expires August 2002 [Page 19] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 5.5. PRS-aware accounting of reserved protection bandwidth We assume in all the following that there are only single points of failure. That means that only one link or one node or one SRLG fails. Bandwidth of bypass tunnels and protection bandwidth effectively reserved on a link must not be confused. The reserved protection bandwidth on a link L, RPbw(L), is defined as the highest cumulated bandwidth, of bypass LSPs that could be in use at the same time. The basic sharing concept is that bypass tunnels, which are PFRG diverse can share protection resources. Let's assume that N bypass tunnels B1, B2, ... BN of bandwidth bw(B1), bw(B2), ... bw(BN) use the same link L (unidirectional meaning). How to account the reserved protection bandwidth? It's quite easy in two particular cases: 1- All bypass LSPs are PFRG diverse: In that case RPbw(L)=max{bw(B1),…,bw(BN)}. 2- All bypass share at least a common FR: In that case RPbw(L)=sum{bw(B1),…,bw(BN)}. In the general case, we have to consider each FR. Indeed, if we go back to the definition, bypass tunnels that can be active at the same time are bypass tunnels that protect a same FR, and the cumulated bandwidth of bypass that share a same FR F on a link L is, as defined in 5.4.3, the protection bandwidth on L for F, PB(L, F). So the reserved protection bandwidth on a link L, is the highest PB( L, F). It can be expressed as following: RPbw(L) = max {PB(L,F)}, F belonging to PFRG(L). Example: In the previous case, we derive the reserved protection bandwidth on link F->G: 30M RPbw(F->G)= Max { PB(F->G, Link B-C), PB(F->G, Link J-K), PB(F->G, Link I-J), PB(F->G, Node C,), PB(F->G, Node K), PB(F->G, Node J), PB(F->G, SRLG 1), PB(F->G, SRLG 2)} = PB(F->G, SRLG 2)= 30M Le Roux et al. Expires August 2002 [Page 20] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 5.6. PRS-aware bypass admission control on a link The admission control of a bypass tunnel B on a link L (unidirectional meaning) consists in computing the resulting reserved protection bandwidth RPbw adding B on L. B can use L if the resulting reserved protection bandwidth on L remains <= Maximum reservable protection bandwidth on L ( RPbw(L)<= MRPbw(L)) This is similar in concept to a classical TE admission control, but the main distinction here is that protection bandwidth can be shared between bypass tunnels. Admission control example: Let's assume that the maximum protection bandwidth on link F->G is 50M. Given the previous configuration, a new NHOP bypass B5 protecting link F-J (SRLG 1), with bandwidth 30M can use F->G. Indeed RPbw(F->G) would become 50M. In return, a new NHOP bypass B6 protecting link B-F (SRLG 2) with bandwidth 25M cannot use F->G because RPbw(F->G) would become 55M. Here there is no longer a simple relationship between current reserved protection bandwidth and resulting reserved protection bandwidth with a new added bypass LSP. The determination of the resulting reserved protection bandwidth with a new bypass requires the knowledge of all current bypass tunnels that are using the link, and their properties (bypass bandwidth, bypass PFRG). Thus information required to perform bypass admission control on a link, is not the reserved protection bandwidth, but all the bypass tunnels, which are using this link, their bandwidth and PFRG, and also the maximum reservable bandwidth. Bypass admission control on links, is performed, distantly, by PLRs, when computing a bypass path, or checking if existing bypass bandwidth can be increased, and, locally, by transit LSRs on a bypass LSP path when handling RSVP Path/Resv messages for bypass setup. A PLR, which has to compute a bypass path must prune from the topology all the links, which cannot support the bypass. In other words, it must perform a bypass admission control on each candidate link for the path. To perform these controls it must have knowledge of all bypass LSPs that use a link, and their properties (PFRG, bw). Links for which bypass admission control fails must be pruned from the topology database. Thus, it must have knowledge of all bypass tunnels existing in the area, in order to verify, if the bypass being computed can share protection resources on a link, with other existing bypass going through this link. This requires several IGP-TE routing extensions in order to distribute the whole bypass topology. Le Roux et al. Expires August 2002 [Page 21] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 Bypass local admission control by transit LSR, on the bypass LSP path, requires RSVP-TE extensions. RSVP-TE must be extended to indicate that a LSP is a bypass LSP, and to indicate the entities it is protecting, i.e. its PFRG. Extensions are proposed in 8. With this extension, a LSR has all the information to perform local bypass admission controls. 6. PRS-aware online bypass path computation Bypass tunnel computation may be performed by a PLR. It is triggered by primary LSP requiring local repair, or by configuration. The constraint based Dijkstra algorithm (CSPF) used for computation of classical MPLS-TE LSP must be modified for Bypass LSPs. Firstly, protected and bypass tunnels must be diversely routed: - For a NHOP bypass tunnel, the path computed must not use the downstream link and it must be SRLG diverse with the downstream link. - For a NNHOP bypass tunnel, the path computed must not use the downstream node, and it must be SRLG diverse with the downstream link. Secondly, a bypass admission control must be performed by the PLR, on each candidate link for the path. Links that cannot support the bypass tunnel are pruned from computation. As mentioned in 5.6 bypass admission control on a link requires that the PLR knows all existing bypass going through the link, their bandwidth and their PFRG. The proposed solution to distribute the whole bypass topology consists in extending IGP TE so that each PLR advertises its bypass in link state advertisements. The advertisement must include: - The type of bypass (NHOP or NNHOP) - The path followed by the bypass - The bypass bandwidth - The bypass PFRG (link, SRLG, node protected). New TLVs is defined for ISIS/OSPF in 7. Note that the maximum reservable protection bandwidth of links must also be advertised in the IGP. These extensions may be used by each potential PLR to build a bypass database which contains, for each unidirectional link, all FRs protected on this link, i.e. the PFRG of the link, and their PB, and also the max reservable protection bandwidth. This database may be used during bypass path computation to perform bypass admission control on all links and to prune links that cannot handle the required bandwidth. Le Roux et al. Expires August 2002 [Page 22] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 To summarize, a PLR, when computing a bypass LSP path, must have knowledge the whole bypass topology, in order to know if the bypass LSP can share protection resources with other existing bypass LSPs. Example: Let's go back to figure 3. We assume that MRPbw on all links is set to 50M, and that B-C and J-K do not belong to any SRLG. Let's assume that a NHOP bypass B1 is already established from B to C, protecting B->C, with bandwidth 50M. It goes through B->F->G->C. B is advertising this bypass to all router by piggybacking the information about the bypass path bandwidth and PFRG, into the LSA. So the bypass database embedded on each router contains the following information for link F->G entry: Link F->G: PFRG {link B-C, PB 50M; node C, PB 50M}, MRPbw 50M. A LSP is established from I to L through I->J->K->L with bandwidth 50M, node protection and bandwidth protection desired. On transit LSR J, there is no bypass LSP that can protect the LSP. Thus bypass creation is triggered. J has to compute a NNHOP bypass path from J to L, to protect node K, with bandwidth 50M. J has to prune from bypass database all links that can't handle B2. The only link that could eventually be pruned is link F->G. The resulting reserved protection with B2 remains 50M in so far as B1 and B2 are PFRG disjoints. So link F->G is not pruned from computation. Thus the B2 path computed by J is J->F->G->K. B2 is then established, with bandwidth 50M. B2 is then advertised by J, into the IGP. Le Roux et al. Expires August 2002 [Page 23] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 7. Routing extensions for PRS-aware bypass path computation In this section, we propose several routing extensions, required to support online PRS-aware bypass CSPF. Extensions are defined for ISIS-TE and OSPF-TE. Classical TE link properties are extended to advertise maximal reservable protection bandwidth and reserved protection bandwidth. The SRLG extensions defined in [GMPLS-ISIS] and [GMPLS-OSPF] must also be used. Note that reserved protection bandwidth advertisement is optional, in so far as it is not used in PRS-aware bypass path computation. Each LSR must have knowledge of the whole bypass topology. For this purpose, a new TLV, the bypass TLV, is defined to advertise a bypass LSP and its parameters. 7.1. New TE link parameters for protection [OSPF-TE] and [ISIS-TE] both define TE parameters that are announced in LSA/LSP to describe TE link properties (affinity, maximum reservable bandwidth, available bandwidth…). These TE properties are encoded in sub-TLV, included in Link TLVs of TE LSA for OSPF, and in IS reachability TLVs for ISIS. New TE parameters are defined to advertise protection bandwidth properties. Note that SRLG TLV defined in GMPLS-RTG must also be added in ISIS-TE/OSPF-TE LSA/LSPs, to support the proposed functionality. 7.1.1. Protection bandwidth Two new sub TLVs are defined: -Max reservable protection bandwidth sub-TLV: this sub-TLV contains the maximum protection bandwidth that can be reserved on this link in this direction (from the node originating the LSA to its neighbors). The maximum protection bandwidth is encoded in 32 bits in IEEE floating-point format. The units are bytes per second. OSPF and ISIS type are TBD. Le Roux et al. Expires August 2002 [Page 24] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max res prot bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Reserved Protection bandwidth sub-TLV: This sub-TLV contains the effective bandwidth reserved by bypass tunnels on the link in this direction. This is not the sum of bypass tunnel bandwidths, but the highest cumulated bandwidth of bypass tunnels that could be activated at the same time on the link, in case of single network failure. By active bypass tunnel we means a bypass tunnel currently in use to recover from a network failure. The reserved protection bandwidth is encoded in 32 bits in IEEE floating-point format. The units are bytes per second. OSPF and ISIS type are TBD. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved prot bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To support the proposed functionality, these sub-TLVs must be included into IS reacheability TLV for ISIS and Link TLV for OSPF. Note that reserved protection bandwidth is optional, in so far as it is not relevant for PRS-aware bypass admission control. 7.1.2. SRLG The SRLG TLV is already defined in [OSPF-GMPLS] and [ISIS-GMPLS]. It indicates the set of SRLG the link belongs to. It is defined as a new TLV in ISIS Link State PDU, and as a new sub-TLV of the Link TLV in OSPF TE LSA. Note that another option could be to reuse link administrative groups. Le Roux et al. Expires August 2002 [Page 25] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 7.2. Bypass advertisement As explained before, to compute a bypass path, taking into account protection resource sharing, the PLR must know the whole bypass topology. That means that each bypass LSP must be advertised by IGP- TE. The relevant information is the bypass path, the bypass bandwidth, and the failure risks protected (Node, Link, SRLG), i.e. the PFRG. A bypass TLV is defined to advertise bypass LSPs and their properties. This new TLV must be added in OSPF TE LSA or ISIS Link State PDU. To support the proposed functionality, each LSR must include, in its Link State Advertisement, a bypass TLV for each, non-zero bandwidth bypass LSP, for which it is the head-end. Note that there is no need to advertise Best Effort Bypass LSPs, which do not reserve bandwidth. This new TLV contains three sub-TLVs: - Bypass tail Router Id - Bypass Path - Bypass Information. Its type is TBD. 7.2.1. Tail Router ID sub-TLV This sub-TLV contains a 4-octet IPv4 address used to identify the bypass LSP merge point, i.e. the bypass LSP tail-end node. This is actually the merge point router ID. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Roux et al. Expires August 2002 [Page 26] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 7.2.2. Path sub-TLV This sub-TLV is already defined in [LSP-HIER]. It contains the information about the path taken by the bypass tunnel. It should be used for bypass path computation purpose, to determine the bypass tunnels that use a given link. In both IS-IS and OSPF, this TLV is encoded as follows: the type is TBD, the length is 4 times the path length, and the value is a list of 4 octet IPv4 addresses identifying the links in the order that they form the path of the bypass tunnel. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | 4 * No. of links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2.3. Bypass Information sub-TLV. This new TLV contains information required for bypass CSPF, i.e. bypass type, bandwidth, and PFRG. It is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Link Local IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Link Neighbour Ipv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Roux et al. Expires August 2002 [Page 27] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 Type is TBD, length is 20 bytes. T: 1 bit Indicates, if set, that the Bypass is NNHOP, and not set, that the bypass is NHOP. Note that this info could also be deduced from the path sub-TLV. Bit 33 to 64 are reserved for future extensions Protected Router ID: 32 bits IPv4 address: The router ID of the protected downstream node. zero if type=NNHOP. Protected Link Local IPv4 address: 32 bit Local IPv4 address of the protected link. Protected Link Neighbour IPv4 Address: Neighbour IPv4 address of the protected link Bypass Bandwidth: 32 bit IEEE floating point number. This sub-TLV enables to determine the PFRG, and bandwidth of the bypass tunnel. Protected Router Id identifies the downstream node, and Local/Neigbour IPv4 address identifies the downstream link. The SRLG of the protected downstream link can be found in the TLV corresponding to the link. The SRLG information of the protected downstream link is not added again here, in so far as it is already advertised as a TE link parameter. 7.3. PLR processing A LSR must include in its periodically flooded LSA, the information corresponding to each, non zero bandwidth bypass tunnel, for which it is the head-end. That means that when flooding is completed, each LSR has the knowledge of the whole bypass topology. Bypass bandwidth may change dynamically due to protected LSP being setup or torn down. These changes must be advertised to the whole network. Several triggering rules may be defined for LSA flooding, in order to limit flooding overload. Le Roux et al. Expires August 2002 [Page 28] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 7.4. Bypass database To facilitate bypass CSPF, each LSR could maintain a database which contains, for each link, all the FRs F protected on the link, i.e. PFRG(L), and the corresponding protection bandwidths PB(L, F) (cf 6). This table is created by analyzing each bypass TLV. To perform a bypass admission control on a link L, during the bypass path computation, the PLR has just to check the entry corresponding to L, computes the resulting reserved protection bandwidth, and compares it with the maximum reservable bandwidth of L. Links which cannot support the required protection must be pruned from the computation. 8. RSVP-TE extensions for bypass LSPs setup In [FRR] a many-to-one bypass LSP is signaled as a normal LSP. Whereas in the solution proposed here, primary LSPs and bypass LSPs work on distinct bandwidth pools, a different admission control must be performed for these LSPs. Each transit LSR on a bypass LSP path must perform a PRS-aware bypass admission control. This requires information such as bypass bandwidth, and the PFRG of the bypass. Thus RSVP-TE must be extended for the establishment of bypass LSPs. A new Object is defined for bypass LSPs. It contains the bypass type (NHOP or NNHOP) and the bypass PFRG (link, SRLG, node protected). 8.1. Bypass object To support the proposed functionality, this object must be added to the Path and Resv messages for the setup of bypass tunnels. It indicates that the LSP is a bypass tunnel, which must be handled separately. It also indicates the downstream node, link and its SRLG, protected by the bypass. Class = TBD, C_Type= 1 Length= 16 + N * SRLGnum. Le Roux et al. Expires August 2002 [Page 29] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Local IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Neighbour IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............................................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T: 1 bit If set, it indicates that the bypass is NNHOP. else that the bypass is NHOP. Reserved: 31 bit This field is reserved. It must be set to zero on transmission and ignored on receipt. Protected Router ID: 32 bit The IPv4 router id of the downstream node protected by the bypass. Zero if Type=NHOP Protected Local IPv4 address: 32 bit The local IPv4 address of the link protected by the bypass. Protected Neighbour IPv4 address: 32 bit The neighbour IPv4 address of the link protected by the bypass. SRLG: 32 bit 32 bit ids indicating SRLGs the link belongs to. Note that bypass LSP bandwidth is encoded, as classical LSPs, in the SenderTspec and FlowSpec objects. The presence of this object indicates that the LSP is a bypass tunnel; it also indicates the bypass type and PFRG. Le Roux et al. Expires August 2002 [Page 30] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 8.2. Processing of the Bypass Object The RSVP global state machine is not modified. The presence of the Bypass object in Path/Resv messages, just indicates that a local admission control specific to bypass LSPs must be performed. In case a node does not recognize the Bypass Object, it must send a PathErr message, upstream to the PLR with an error code "Bypass Not Supported". The bypass local admission control consists, as mentioned in 5.4, in computing the resulting reserved protection bandwidth with this new bypass, on the downstream link, taking into account its PFRG and other bypass already established on the link. If the resulting bandwidth remains lower than the maximum reservable protection bandwidth then the reservation request is accepted, else it is rejected. Note that, this control is not needed for zero bandwidth bypass LSPs. Note that, for bypass local admission control purpose, each LSR may contain a table, maintaining, for each attached link, the set of FRs protected on the link, and the corresponding protected bandwidth. When a request for a new bypass arrives, the resulting reserved protection bandwidth is easily computed, checking this table. 9. Security Considerations This document does not introduce new security issues. 10. Intellectual property consideration France Telecom is seeking patent protection on the specification described in this Internet-Draft. If it is adopted as a standard, France Telecom agrees to licence, on reasonable and non- discriminatory terms, any patent rights it obtains covering the specification to the extent necessary to comply with the standard. 11. Acknowledgment We acknowledge the helpful comments and discussions with Renaud Moignard and Jean-Yves Mazeas. Le Roux et al. Expires August 2002 [Page 31] Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002 12. References [FRR] Pan, et al, "Fast-Reroute Techniques in RSVP-TE", draft-ping-rsvp-fastreroute-00.txt (work in pogress). [ATLAS] Atlas, A. et al., "RSVP-TE Interoperability for Local Protection/ Fast Reroute", draft-atlas-rsvp-local-protect-interop-02.txt (work in progress) [RSVP-TE] D. Adwuche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3209 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-02.txt (work in progress) [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) [HIER] Rekter, Y., Kompella, K., "LSP Hierarchy with MPLS-TE", draft-ietf-mpls-lsp-hierarchy-03.txt (work in progress) [GMPLS-RTG] "Routing Extensions in Support of Generalized MPLS", draft-many-ccamp-gmpls-routing-00.txt [OSPF-G] Kompella, K. et al., "OSPF Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-00.txt [ISIS-G] Kompella, K. et al., "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-extensions-04.txt 13. Authors Information Jean-Louis Le Roux France Telecom R & D Avenue Pierre Marzin 22300 Lannion, France email: jeanlouis.leroux@francetelecom.com phone: +33 2 96 05 30 20 Geraldine Calvignac France Telecom R & D Avenue Pierre Marzin 22300 Lannion, France email: geraldine.calvignac@francetelecom.com phone: +33 2 96 05 10 59 Le Roux et al. Expires August 2002 [Page 32]