--- 1/draft-ietf-teas-gmpls-lsp-fastreroute-04.txt 2016-06-03 18:15:50.058910293 -0700 +++ 2/draft-ietf-teas-gmpls-lsp-fastreroute-05.txt 2016-06-03 18:15:50.094911201 -0700 @@ -1,162 +1,157 @@ TEAS Working Group M. Taillon Internet-Draft T. Saad, Ed. Intended Status: Standards Track R. Gandhi, Ed. -Expires: July 29, 2016 Z. Ali - (Cisco Systems, Inc.) - M. Bhatia - L. Jin - - January 26, 2016 +Expires: December 5, 2016 Z. Ali + Cisco Systems + June 3, 2016 Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs - draft-ietf-teas-gmpls-lsp-fastreroute-04 + draft-ietf-teas-gmpls-lsp-fastreroute-05 Abstract This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling - extensions allow the coordination of bidirectional bypass tunnel + extensions allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. 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/1id-abstracts.html - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Copyright and License Notice +Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 5 - 4.1. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5 - 4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6 - 4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 - 4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6 - 4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6 - 4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . 7 - 4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 8 - 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 9 - 5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10 - 5.2. Revertive Behavior Post Link Failure After FRR . . . . . . 10 - 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10 - 6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11 - 6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11 - 6.3. Revertive Behavior Post Link Failure . . . . . . . . . . . 13 + 4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 5 + 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5 + 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6 + 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 + 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 6 + 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling + Procedure . . . . . . . . . . . . . . . . . . . . . . 7 + 4.5.2. Bidirectional Bypass Tunnel Assignment Policy . . . . 8 + 4.5.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 9 + 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10 + 5.1. Behavior After Link Failure After FRR . . . . . . . . . . 10 + 5.2. Revertive Behavior After Link Failure After FRR . . . . . 11 + 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 11 + 6.1. Behavior After FRR and Link Failure . . . . . . . . . . . 11 + 6.2. Behavior After Link Failure To Re-coroute . . . . . . . . 12 + 6.3. Revertive Behavior After Link Failure . . . . . . . . . . 13 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . 14 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . 15 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction - Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are signaled using Generalized Multi-Protocol Label Switching (GMPLS) signaling procedures specified in [RFC3473] for both unidirectional and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely - deployed in the packet TE networks today and is preferred for TE - GMPLS tunnels. Using FRR methods also allows to leverage existing - mechanisms for failure detection and restoration in the deployed + deployed in the packet TE networks today and is desirable for TE + GMPLS LSPs. Using FRR methods also allows the leveraging of existing + mechanisms for failure detection and restoration in deployed networks. - FRR procedures defined in [RFC4090] describe the behavior of the + The FRR procedures defined in [RFC4090] describe the behavior of the Point of Local Repair (PLR) to reroute traffic and signaling onto the bypass tunnel in the event of a failure for unidirectional LSPs. These procedures are applicable to unidirectional protected LSPs signaled using either RSVP-TE [RFC3209] or GMPLS procedures - [RFC3473], however don't address issues that arise when employing FRR - for bidirectional co-routed GMPLS Label Switched Paths (LSPs). + [RFC3473], but they do not address issues that arise when employing + FRR for bidirectional co-routed GMPLS Label Switched Paths (LSPs). When bidirectional bypass tunnels are used to locally protect bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs may independently assign different bidirectional bypass tunnels in - the forward and reverse directions. There is no mechanism in FRR + the forward and reverse directions. There is no mechanism in the FRR procedures defined in [RFC4090] to coordinate the bidirectional bypass tunnel selection between the downstream and upstream PLRs. When using FRR procedures with bidirectional co-routed GMPLS LSPs, it - is possible in some cases (e.g. when using node protection bypass - tunnels post a link failure event and when RSVP signaling is sent - in-fiber and in-band with data), the RSVP signaling refreshes may - stop reaching some nodes along the primary bidirectional LSP path - after the PLRs complete rerouting traffic and signaling onto the - bypass tunnels. This is caused by the asymmetry of paths that may be - taken by the bidirectional LSP's signaling in the forward and reverse - directions after FRR reroute. In such cases, the RSVP soft-state - timeout eventually causes the protected bidirectional LSP to be - destroyed, and consequently impacts protected traffic flow after FRR. + is possible in some cases for the RSVP signaling refreshes to stop + reaching some nodes along the primary LSP path after the PLRs finish + rerouting signaling onto the bypass tunnels. This may occur when + using node protection bypass tunnels after a link failure event and + when RSVP signaling is sent in-fiber and in-band with data. This is + caused by the asymmetry of paths that may be taken by the + bidirectional LSP's signaling in the forward and reverse directions + after FRR reroute. In such cases, the RSVP soft-state timeout + causes the protected bidirectional LSP to be destroyed, with + subsequent traffic loss after FRR. Protection State Coordination Protocol [RFC6378] is applicable to FRR [RFC4090] for local protection of bidirectional co-routed LSPs in order to minimize traffic disruptions in both directions. However, this does not address the above mentioned problem of RSVP soft-state timeout in control plane. This document proposes solutions to the above mentioned problems by - providing mechanisms in the control plane to complement FRR + providing mechanisms in the control plane to complement the FRR procedures of [RFC4090] in order to maintain the RSVP soft-state for bidirectional co-routed protected GMPLS LSPs and achieve symmetry in the paths followed by the traffic and signaling in the forward and - reverse directions post FRR. The document further extends RSVP + reverse directions after FRR. The document further extends RSVP signaling so that the bidirectional bypass tunnel selected by the upstream PLR matches the one selected by the downstream PLR node for a bidirectional co-routed LSP. - Unless otherwise specified in this document, fast reroute procedures - defined in [RFC4090] are not modified for GMPLS signaled tunnels. + Procedures defined in this document apply to co-routed GMPLS signaled + PSC bidirectional TE primary and FRR bypass LSPs. Unless otherwise + specified in this document, the FRR procedures defined in [RFC4090] + are not modified by this document. 2. Conventions Used in This Document 2.1. Key Word Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology @@ -200,412 +195,447 @@ Upstream PLR: A PLR that locally detects a fault and reroutes traffic in the opposite direction of the protected bidirectional LSP RSVP Path signaling. An upstream PLR has a corresponding upstream MP. Point of Remote Repair (PRR): An upstream PLR that triggers reroute of traffic and signaling based on procedures described in this document. 3. Fast Reroute For Unidirectional GMPLS LSPs - FRR procedures defined in [RFC4090] are applicable to unidirectional - protected LSPs signaled using either RSVP-TE or GMPLS procedures and - are not modified by the extensions defined in this document. These - FRR procedures also apply to bidirectional associated GMPLS LSPs - where two unidirectional GMPLS LSPs are bound together by using - association signaling [RFC7551]. + The FRR procedures defined in [RFC4090] are applicable to + unidirectional protected LSPs signaled using either RSVP-TE or GMPLS + procedures and are not modified by the extensions defined in this + document. These FRR procedures also apply to bidirectional + associated GMPLS LSPs where two unidirectional GMPLS LSPs are bound + together by using association signaling [RFC7551]. 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs This section describes signaling procedures for bidirectional bypass tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE LSPs. -4.1. Merge Point Labels +4.1. Bidirectional GMPLS Bypass Tunnel Direction + + This document defines procedures where GMPLS bypass tunnels are + provisioned in the same direction as the GMPLS primary LSPs. In + other words, the GMPLS bypass tunnels originate on the downstream PLR + and terminate on the downstream MP. As the originating downstream + PLR node has the policy information about the locally provisioned + bypass tunnels, it always initiates the bypass tunnel assignment. + The GMPLS bypass tunnels originating from the upstream PLR and + terminating on the upstream MP are outside the scope of this + document. + +4.2. Merge Point Labels To correctly reroute data traffic over a node protection bypass tunnel, the downstream and upstream PLRs have to know, in advance, - the downstream and upstream Merge Point (MP) labels so that data in - the forward and reverse directions can be tunneled through the bypass - tunnel post FRR respectively. + the downstream and upstream MP labels so that data in the forward and + reverse directions can be redirected through the bypass tunnel after + FRR respectively. [RFC4090] defines procedures for the downstream PLR to obtain the protected LSP's downstream MP label from recorded labels in the RRO of the RSVP Resv message received at the downstream PLR. - To obtain the upstream MP label, existing methods [RFC4090] to record - upstream MP label are used in the RRO of the RSVP Path message. The - upstream PLR can obtain the upstream MP label from the recorded label - in the RRO of the received RSVP Path message. + To obtain the upstream MP label, the procedures specified in + [RFC4090] are used to record the upstream MP label in the RRO of the + RSVP Path message. The upstream PLR obtains the upstream MP label + from the recorded labels in the RRO of the received RSVP Path + message. -4.2. Merge Point Addresses +4.3. Merge Point Addresses To correctly assign a bidirectional bypass tunnel, the downstream and upstream PLRs have to know, in advance, the downstream and upstream - Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR - to obtain the protected LSP's merge point address in multi-domain - routing networks where a domain is defined as an Interior Gateway - Protocol (IGP) area or an Autonomous System (AS). + MP addresses. [RFC4561] defines procedures for the downstream PLR to obtain the - protected LSP's downstream merge point address from the recorded - node-IDs in the RRO of the RSVP Resv message received at the - downstream PLR. + protected LSP's downstream MP address from the recorded node-IDs in + the RRO of the RSVP Resv message received at the downstream PLR. - To obtain the upstream MP address, existing methods [RFC4561] to - record upstream MP node-ID are used in the RRO of the RSVP Path - message. The upstream PLR can obtain the upstream MP address from - the recorded node-IDs in the RRO of the received RSVP Path message. + To obtain the upstream MP address, the procedures specified in + [RFC4561] are used to record upstream MP node-ID in the RRO of the + RSVP Path message. The upstream PLR obtains the upstream MP address + from the recorded node-IDs in the RRO of the received RSVP Path + message. -4.3. RRO IPv4/IPv6 Subobject Flags +4.4. RRO IPv4/IPv6 Subobject Flags RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 - and are applicable to the FRR procedure for the bidirectional GMPLS - tunnels. + and are equally applicable to the FRR procedure for bidirectional + GMPLS LSPs. - [RFC4090] defined procedure is used by the downstream PLR - independently to signal the Ipv4/IPv6 subobject flags in the RRO of - the RSVP Path message. Similarly, this procedure is used by the - upstream PLR independently to signal the IPv4/IPv6 subobject flags in - the RRO of the RSVP Resv message. + The procedures defined in [RFC4090] are used by the downstream PLR to + signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP + Resv message. Similarly, these procedures are used by the downstream + PLR to signal the IPv4/IPv6 subobject flags downstream in the RRO of + the RSVP Path message. -4.4. Bypass Tunnel Assignment Co-ordination +4.5. Bidirectional Bypass Tunnel Assignment Co-ordination - This document defines signaling procedure and a new BYPASS_ASSIGNMENT - subobject in RSVP RECORD_ROUTE object used to co-ordinate the - bidirectional bypass tunnel selection between the downstream and - upstream PLRs. + This document defines signaling procedures and a new + BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object used to + co-ordinate the bidirectional bypass tunnel assignment between the + downstream and upstream PLRs. -4.4.1. Bypass Tunnel Assignment Signaling Procedure +4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure It is desirable to coordinate the bidirectional bypass tunnel selected at the downstream and upstream PLRs so that rerouted traffic - and signaling flow on co-routed paths post FRR. To achieve this, a - new RSVP subobject is defined for RECORD_ROUTE object (RRO) that + and signaling flow on co-routed paths after FRR. To achieve this, a + new RSVP subobject is defined for RECORD_ROUTE Object (RRO) that identifies a bidirectional bypass tunnel that is assigned at a downstream PLR to protect a bidirectional LSP. - The BYPASS_ASSIGNMENT subobject is added by each downstream PLR in - the RSVP Path RECORD_ROUTE message of the GMPLS signaled + The BYPASS_ASSIGNMENT subobject SHOULD be added by each downstream + PLR in the RSVP Path RECORD_ROUTE message of the GMPLS signaled bidirectional primary LSP to record the downstream bidirectional bypass tunnel assignment. This subobject is sent in the RSVP Path RECORD_ROUTE message every time the downstream PLR assigns or updates - the bypass tunnel assignment so the upstream PLR may reflect the - assignment too. + the bypass tunnel assignment. The upstream PLR (downstream MP) + simply reflects the bypass tunnel assignment in the reverse + direction. When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE - object: + Object: - o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node- - ID subobject containing the node's address. + o The BYPASS_ASSIGNMENT subobject MUST be added prior to the + Node-ID subobject containing the node's address. o The Node-ID subobject MUST also be added. o The IPv4 or IPv6 subobject MUST also be added. + o The Label subobject MUST also be added. + In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR - SHOULD NOT assign a bypass tunnel in the reverse direction. This - allows the downstream PLR to always initiate the bypass assignment - and upstream PLR to simply reflect the bypass assignment. + (downstream MP) SHOULD NOT assign a bypass tunnel in the reverse + direction. This allows the downstream PLR to always initiate the + bypass assignment and upstream PLR (downstream MP) to simply reflect + the bypass assignment. The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT - subobject, whose bypass tunnel and the node-ID subobject when used as - a "bypass tunnel source" terminates locally, assigns the matching - bidirectional bypass tunnel in the reverse direction, and forwards - the RSVP Path message downstream. Otherwise, the bypass tunnel - assignment subobject is simply forwarded downstream along in the RSVP - Path message. + subobject, selects a reverse bypass tunnel that terminates locally + with the matching tunnel-ID and has a source address matching the + node-ID sub-object received in the subobject. The RRO containing + BYPASS_ASSIGNMENT subobject(s) is then simply forwarded downstream in + the RSVP Path message. - Bypass assignment co-ordination procedure described above can be used - for both one-to-one backup described in Section 3.1 of [RFC4090] and - facility backup described in Section 3.2 of [RFC4090]. + An upstream PLR (downstream MP) SHOULD examine the entire Path RRO + and look at all BYPASS_ASSIGNMENT subobjects in order to assign a + reverse bypass tunnel. The choice of a reverse bypass tunnel (if + multiple bypass tunnels exist) is based on the local policy on the + downstream MP and is discussed in Section 4.5.2 of this document. -4.4.2. Bypass Tunnel Assignment Policy + The bypass assignment co-ordination procedure described in this + Section can be used for both one-to-one backup described in Section + 3.1 of [RFC4090] and facility backup described in Section 3.2 of + [RFC4090]. - In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT - subobjects from multiple downstream PLRs, the decision of selecting a - bypass tunnel in the reverse direction can be based on a local - policy, for example, prefer link protection versus node protection - bypass tunnel, or prefer the most upstream versus least upstream node - protection bypass tunnel. However, it is recommended that nodes - along the LSP path employ identical policy for bypass tunnel - assignment. +4.5.2. Bidirectional Bypass Tunnel Assignment Policy - When different policies are used for bypass tunnel assignment on the - LSP path, it may result in some links in the reverse direction not - assigned bypass protection as shown in examples below. + In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT + subobjects from multiple downstream PLRs, the selection of a bypass + tunnel in the reverse direction can be based on local policy. + Examples of such a policy could be to prefer link protection over + node protection, or to prefer the bypass tunnel to the furthest + upstream node. When different policies are used for bypass tunnel + assignment on the LSP path, it may result in some links in the + reverse direction not assigned bypass protection during LSP setup as + shown in examples below. As shown in Example 1, node A assigns a node protection bypass tunnel - in the forward direction but node C does not assign a node protection - bypass tunnel in the reverse direction for a protected bidirectional - GMPLS LSP. Both nodes B and C assign a link protection bypass - tunnel. As a result, there is no fast reroute protection available - in the reverse direction for link A-B for this LSP. + in the forward direction but node C does not reflect the node + protection bypass tunnel in the reverse direction for a protected + bidirectional GMPLS LSP A-B-C. Both nodes B and C assign a link + protection bypass tunnel. As a result, there is no fast reroute + protection available in the reverse direction for link A-B for this + LSP during the LSP setup. Note that this is corrected by node C + during the re-coroute procedure after the FRR failure on link A-B as + specified in Section 6 of this document since GMPLS bypass tunnels + are bidirectional. +------->>------+ / +->>-+ \ / / \ \ / / \ \ - A -------- B --------- C - \ / + A --->>--- B --->>---- C + -> PATH \ / \ / +-<<-+ Example 1: An example of different bypass assignment policy As shown in Example 2, nodes A and C assign a node protection bypass - tunnel for a protected bidirectional GMPLS LSP. Node B assigns a - link protection bypass tunnel but node C does not assign a reverse - link protection bypass tunnel. As a result, there is no fast reroute - protection available in the reverse direction for link A-B for this - LSP. + tunnel for a protected bidirectional GMPLS LSP A-B-C. Node B assigns + a link protection bypass tunnel but node C does not reflect the + reverse link protection bypass tunnel. As a result, there is no fast + reroute protection available in the reverse direction for link A-B + for this LSP during the LSP setup. Note that this is corrected by + node C during the re-coroute procedure after the FRR failure on link + A-B as specified in Section 6 of this document since GMPLS bypass + tunnels are bidirectional. +------>>------+ / +->>-+ \ / / \ \ / / \ \ - A -------- B --------- C - \ / + A --->>--- B --->>---- C + \ -> PATH / \ / \ / +------<<-------+ Example 2: An example of different bypass assignment policy -4.4.3. BYPASS_ASSIGNMENT Subobject +4.5.3. BYPASS_ASSIGNMENT Subobject - The BYPASS_ASSIGNMENT subobject is used to inform the MP of the - bypass tunnel being assigned by the PLR. This can be used to + The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP + of the bypass tunnel being assigned by the PLR. This can be used to coordinate the bypass tunnel assignment for the protected LSP by the downstream and upstream PLRs in the forward and reverse directions - respectively prior or post the failure occurrence. This subobject - SHOULD only be inserted into the RSVP Path message by the downstream - PLR and MUST NOT be changed by downstream LSRs. + respectively prior or after the failure occurrence. + + This subobject SHOULD be inserted into the Path RRO by the downstream + PLR. It SHOULD NOT be inserted into an RRO by a node which is not a + downstream PLR. It MUST NOT be changed by downstream LSRs and MUST + NOT be added to a Resv RRO. The BYPASS_ASSIGNMENT subobject in RRO has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Bypass Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - Downstream Bypass Assignment. + Downstream Bypass Assignment. Value is TBA by IANA. Length The Length contains the total length of the subobject in - bytes, including the Type and Length fields. + bytes, including the Type and Length fields. The length is + always 4 bytes. Bypass Tunnel ID The bypass tunnel identifier (16 bits). 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs When a bidirectional link protection bypass tunnel is used, after a - link failure, downstream PLR reroutes RSVP Path and traffic over - bypass tunnel using procedures defined in [RFC4090]. Upstream PLR - may reroute traffic and RSVP Resv upon detecting the link failure or - upon receiving RSVP Path message over a bidirectional bypass tunnel. - This allows both traffic and RSVP signaling to flow on symmetric - paths in the forward and reverse directions of a bidirectional - tunnel. + link failure, the downstream PLR reroutes traffic and RSVP messages + over the bypass tunnel using the procedures defined in [RFC4090]. + Upstream PLR reroutes traffic upon detecting the link failure or upon + receiving RSVP Path message over a bidirectional bypass tunnel. + Upstream PLR reroutes RSVP Resv signaling upon receiving RSVP Path + message over a bidirectional bypass tunnel. This allows both traffic + and RSVP signaling to flow on symmetric paths in the forward and + reverse directions of a bidirectional LSP. <-RESV - [R1]---[R2]----[R3]------x-----[R4]-----[R5] + [R1]---[R2]----[R3]------x-----[R4]----[R5] -> PATH \ / - +<<-------->>+ + +<<--------->>+ T3 -> PATH RESV <- Protected LSP: {R1-R2-R3-R4-R5} R3's Bypass T3: {R3-R4} - Figure 1: Flow of RSVP signaling post FRR after link failure + Figure 1: Flow of RSVP signaling after FRR and link failure Consider the Traffic Engineered (TE) network shown in Figure 1. Assume every link in the network is protected with a link protection bypass tunnel (e.g. bypass tunnel T3). For the protected - bidirectional co-routed LSP whose (active) head-end is on router R1 - and (passive) tail-end is on router R5, each traversed router (a - potential PLR) assigns a link protection bidirectional co-routed - bypass tunnel. + bidirectional co-routed LSP whose head-end is on node R1 and tail-end + is on node R5, each traversed node (a potential PLR) assigns a link + protection bidirectional co-routed bypass tunnel. -5.1. Behavior Post Link Failure After FRR +5.1. Behavior After Link Failure After FRR Consider a link R3-R4 on the protected LSP path fails. The downstream PLR R3 and upstream PLR R4 independently trigger fast reroute procedures to redirect traffic onto bypass tunnels T3 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path state onto the bypass tunnel T3 using procedures described in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the reverse bypass tunnel T3 upon receiving RSVP Path message over bypass tunnel T3. -5.2. Revertive Behavior Post Link Failure After FRR +5.2. Revertive Behavior After Link Failure After FRR Revertive behavior as defined in [RFC4090], Section 6.5.2, is applicable to the link protection of GMPLS bidirectional LSPs. When using the local revertive mode, when downstream MP receives Path messages over the restored path, it starts sending Resv over the restored path and stops sending Resv over the reverse bypass tunnel. No additional procedure other than that specified in [RFC4090] is introduced for revertive behavior by this document. 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs T1 +<<--------->>+ / \ <-RESV - [R1]---[R2]----[R3]--x--[R4]---[R5]---[R6] + [R1]---[R2]----[R3]--x--[R4]----[R5]---[R6] -> PATH \ / - +<<--------->>+ + +<<---------->>+ T2 Protected LSP: {R1-R2-R3-R4-R5-R6} R3's Bypass T2: {R3-R5} R4's Bypass T1: {R4-R2} - Figure 2: Flow of RSVP signaling post FRR after link failure + Figure 2: Flow of RSVP signaling after FRR and link failure Consider the Traffic Engineered (TE) network shown in Figure 2. Assume every link in the network is protected with a node protection bypass tunnel. For the protected bidirectional co-routed LSP whose - (active) head-end is on router R1 and (passive) tail-end is on router - R6, each traversed router (a potential PLR) assigns a node protection - bidirectional co-routed bypass tunnel. + head-end is on node R1 and tail-end is on node R6, each traversed + node (a potential PLR) assigns a node protection bidirectional co- + routed bypass tunnel. The proposed solution introduces two phases to invoking FRR - procedures by the PLR post the link failure. The first phase + procedures by the PLR after the link failure. The first phase comprises of FRR procedures to fast reroute data traffic onto bypass tunnels in the forward and reverse directions. The second phase re-coroutes the data and signaling in the forward and reverse directions after the first phase. -6.1. Behavior Post Link Failure After FRR +6.1. Behavior After FRR and Link Failure Consider a link R3-R4 on the protected LSP path fails. The downstream PLR R3 and upstream PLR R4 independently trigger fast reroute procedures to redirect traffic onto respective bypass tunnels T2 and T1 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path state onto the bypass tunnel T2 using - procedures described in [RFC4090]. Note, at this point, router R4 + procedures described in [RFC4090]. Note, at this point, node R4 stops receiving RSVP Path refreshes for the protected bidirectional LSP while primary protected traffic continues to flow over bypass tunnels. -6.2. Behavior Post Link Failure To Re-coroute +6.2. Behavior After Link Failure To Re-coroute - The downstream Merge Point (MP) R5 that receives rerouted protected - LSP RSVP Path message through the bypass tunnel, in addition to the - regular MP processing defined in [RFC4090], gets promoted to a Point - of Remote Repair (PRR role) and performs the following actions to - re-coroute signaling and data traffic over the same path in both - directions: + The downstream MP R5 that receives rerouted protected LSP RSVP Path + message through the bypass tunnel, in addition to the regular MP + processing defined in [RFC4090], gets promoted to a Point of Remote + Repair (PRR) role and performs the following actions to re-coroute + signaling and data traffic over the same path in both directions: - o Finds the bypass tunnel in the reverse direction - that terminates on the Downstream PLR R3. Note: the Downstream - PLR R3's address is extracted from the "IPV4 tunnel sender - address" in the SENDER_TEMPLATE object. + o Finds the bypass tunnel in the reverse direction that terminates + on the downstream PLR R3. Note: the downstream PLR R3's address + can be extracted from the "IPV4 tunnel sender address" in the + SENDER_TEMPLATE Object of the primary LSP (see [RFC4090], Section + 6.1.1). - o If reverse bypass tunnel is found and the primary LSP traffic - and signaling are not already rerouted over the found bypass - tunnel, the PRR R5 activates FRR reroute procedures to direct - traffic and RSVP Resv over the found bypass tunnel T2 in the + o If reverse bypass tunnel is found and the primary LSP traffic is + not already rerouted over the found bypass tunnel T2, the PRR R5 + activates FRR reroute procedures to direct traffic over the found + bypass tunnel T2 in the reverse direction. In addition, the PRR + R5 also reroutes RSVP Resv over the bypass tunnel T2 in the reverse direction. - o If reverse bypass tunnel is not found, the PRR R5 signals a new - reverse bypass tunnel that terminates on the downstream PLR R3 - and activates FRR reroute procedures over the new bypass tunnel - to direct traffic and RSVP Resv in the reverse direction. - - o If reverse bypass tunnel can not be successfully signaled, - the PRR R5 immediately tears down the primary LSP. - - If downstream MP R5 receives multiple RSVP Path messages through - multiple bypass tunnels (e.g. as a result of multiple failures), the - PRR SHOULD identify a bypass tunnel that terminates on the farthest - downstream PLR along the protected LSP path (closest to the primary - bidirectional tunnel head-end) and activate the reroute procedures - mentioned above. + o If reverse bypass tunnel is not found, the PRR R5 immediately + tears down the primary LSP. <- RESV - [R1]---[R2]----[R3]--X--[R4]---[R5]---[R6] + [R1]---[R2]----[R3]--X--[R4]----[R5]---[R6] PATH -> \ / - +<<------->>+ + +<<-------->>+ Bypass Tunnel T2 traffic + signaling Protected LSP: {R1-R2-R3-R4-R5-R6} R3's Bypass T2: {R3-R5} - Figure 3: Flow of RSVP signaling post FRR after re-corouted + Figure 3: Flow of RSVP signaling after FRR and re-corouted Figure 3 describes the path taken by the traffic and signaling after completing re-coroute of data and signaling in the forward and - reverse paths described earlier. + reverse paths described earlier. Node R4 will stop receiving the + Path and Resv messages and it will timeout the RSVP soft-state, + however, this will not cause the LSP to be torn down. RSVP signaling + at node R2 is not affected by the FRR and re-corouting. + + If the link failure is unidirectional in the direction of R4 to R3, + node R3 will stop receiving the RSVP Resv messages from node R4 and + this will cause RSVP soft-state to timeout on node R3. However, + unidirectional link failure in the opposite direction will not result + in RSVP soft-state timeout as node R5 will trigger the re-coroute + procedure after receiving RSVP Path message over the bypass tunnel + from node R3. + + If downstream MP R5 receives multiple RSVP Path messages through + multiple bypass tunnels (e.g. as a result of multiple failures), the + PRR SHOULD identify a bypass tunnel that terminates on the farthest + downstream PLR along the protected LSP path (closest to the primary + bidirectional LSP head-end) and activate the reroute procedures + mentioned above. The downstream MP MAY optionally support re-corouting in data plane as follows. If the downstream MP is pre-configured with bidirectional bypass tunnel, as soon as the MP node receives the - primary tunnel packets on this bypass tunnel, it MAY switch the - upstream traffic on to this bypass tunnel. In order to identify the - primary tunnel packets through this bypass tunnel, Penultimate Hop - Popping (PHP) of the bypass tunnel MUST be disabled. The signaling - procedure described above in this Section will still apply, and MP - checks whether the primary tunnel traffic and signaling is already - rerouted over the found bypass tunnel, if not, perform the above - signaling procedure. + primary LSP packets on this bypass tunnel, it MAY switch the upstream + traffic on to this bypass tunnel. In order to identify the primary + LSP packets through this bypass tunnel, Penultimate Hop Popping (PHP) + of the bypass tunnel MUST be disabled. The signaling procedure + described above in this Section will still apply, and MP checks + whether the primary LSP traffic and signaling is already rerouted + over the found bypass tunnel, if not, perform the above signaling + procedure. -6.3. Revertive Behavior Post Link Failure +6.3. Revertive Behavior After Link Failure Revertive behavior as defined in [RFC4090], Section 6.5.2, is applicable to node protection of GMPLS bidirectional LSPs. When using the local revertive mode, when downstream MP (R4) (before re-corouting) and PRR (R5) (after re-corouting) receive Path messages over the restored path, they start sending Resv over the restored path and stop sending Resv over the reverse bypass tunnel. No additional procedure other than that specified in [RFC4090] is introduced for revertive behavior by this document. 7. Compatibility New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE Object in this document. Per [RFC2205], nodes not supporting this subobject will ignore the subobject but forward it without modification. 8. Security Considerations - This document introduces one new RSVP subobject that is carried in a - signaling message. Thus in the event of the interception of a - signaling message, slightly more information about the state of the - network could be deduced than was previously the case. This is - judged to be a very minor security risk as this information is - already available by other means. + This document introduces a new BYPASS_ASSIGNMENT subobject for the + RECORD_ROUTE Object that is carried in an RSVP signaling message. + Thus in the event of the interception of a signaling message, more + information about LSP's fast reroute protection can be deduced than + was previously the case. This is judged to be a very minor security + risk as this information is already available by other means. Otherwise, this document introduces no additional security considerations. For general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. 9. IANA Considerations IANA manages the "RSVP PARAMETERS" registry located at . IANA is requested to assign a value for the new BYPASS_ASSIGNMENT subobject in the "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. - This document introduces a new RECORD_ROUTE subobject: + This document introduces a new subobject for RECORD_ROUTE Object: +--------+-------------------+---------+---------+---------------+ | Value | Description | Carried | Carried | Reference | | | | in Path | in Resv | | +--------+-------------------+---------+---------+---------------+ | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | | IANA | subobject | | | | +--------+-------------------+---------+---------+---------------+ 10. References @@ -646,30 +676,38 @@ Networks", RFC 5920, July 2010. [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011. Acknowledgements Authors would like to thank George Swallow for his detailed and useful comments and suggestions. Authors would also like to thank - Nobo Akiya, Loa Andersson and Gregory Mirsky for reviewing this - document. + Nobo Akiya, Loa Andersson, Matt Hartley and Gregory Mirsky for + reviewing this document. Contributors Frederic Jounay Orange CH EMail: frederic.jounay@orange.ch + Manav Bhatia Ionos Networks Banglore India + + EMail: manav@ionosnetworks.com + + Lizhong Jin Shanghai, China + + EMail: lizho.jin@gmail.com + Authors' Addresses Mike Taillon Cisco Systems, Inc. EMail: mtaillon@cisco.com Tarek Saad (editor) Cisco Systems, Inc. @@ -677,20 +715,10 @@ Rakesh Gandhi (editor) Cisco Systems, Inc. EMail: rgandhi@cisco.com Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com - - Manav Bhatia - India - - EMail: manav@ionosnetworks.com - - Lizhong Jin - Shanghai, China - - EMail: lizho.jin@gmail.com