Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs
draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03

CCAMP Working Group                                         Mike Taillon
Internet-Draft                                                Tarek Saad
Intended Status: Standards Track                           Rakesh Gandhi
Expires: August 7, 2014                                        Zafar Ali
                                                    (Cisco Systems, Inc)
                                                            Manav Bhatia
                                                        (Alcatel-Lucent)
                                                             Lizhong Jin
                                                                      ()
                                                         Frederic Jounay
                                                             (Orange CH)
                                                        February 3, 2014

    Extensions to Resource Reservation Protocol For Fast Reroute of     
           Bidirectional Co-routed Traffic Engineering LSPs

           draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03

Abstract

   This document defines Resource Reservation Protocol - Traffic
   Engineering (RSVP-TE) signaling extensions to support Fast Reroute
   (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. 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. In
   addition, the RSVP-TE signaling extensions allow the coordination of
   bypass tunnel assignment protecting a common facility in both forward
   and reverse directions prior to or post failure occurrence.

Status of this Memo

   This Internet-Draft is submitted to IETF 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.

   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."
 

Taillon et al.           Expires August 7, 2014                 [Page 1]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

   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 (c) 2014 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
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Link Failure With Node-protection Bypass Tunnels  . . . . . . .  5
     3.1. Behavior Before Local Repair  . . . . . . . . . . . . . . .  5
       3.1.1. Downstream Merge Point Label Discovery  . . . . . . . .  5
       3.1.2. Upstream Merge Point Label Discovery  . . . . . . . . .  6
     3.2. Behavior Post Link Failure After FRR  . . . . . . . . . . .  6
     3.3. Behavior Post Link Failure To Re-coroute  . . . . . . . . .  6
   4. Bypass Tunnel Assignment Coordination . . . . . . . . . . . . .  7
     4.1. DOWNSTREAM_BYPASS_ASSIGNMENT Subobject  . . . . . . . . . .  8
     4.2. Bypass Tunnel Assignment Signaling Procedure  . . . . . . .  9
   5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 10
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.1.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

 

Taillon et al.           Expires August 7, 2014                 [Page 2]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

1. Introduction

   Co-routed bidirectional tunnels are signaled using GMPLS signaling
   procedures specified in [RFC3473] and [RFC3471]. Existing 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, and don't address
   issues that arise when employing FRR for bidirectional co-routed
   Label Switched Paths (LSPs).

   When using current FRR procedures with bidirectional co-routed LSPs,
   it is possible in some cases (e.g. when using node-protecting 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.

   When co-routed bidirectional bypass tunnels are used to locally
   protect bidirectional LSPs, the upstream and downstream PLRs may
   independently assign different bidirectional bypass tunnels in the
   forward and reverse directions. Currently, there is no means to
   coordinate the bypass tunnel selection between the downstream and
   upstream PLRs. In case of mismatch and after FRR, data traffic and
   signaling may flow over asymmetric paths in the forward and reverse
   directions which may be undesirable for certain applications.

   This document proposes solutions to the above problems by providing
   corrective actions in the control plane to complement FRR procedures
   of [RFC4090] in order to maintain the RSVP soft-state for
   bidirectional protected LSPs and achieve symmetry in the paths
   followed by data and signaling in the forward and reverse directions
   post FRR. The document extends RSVP signaling so that the bypass
   tunnel selected by the upstream PLR matches the one selected by the
   downstream PLR.

2. Terminology

   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].

   The reader is assumed to be familiar with the terminology in
 

Taillon et al.           Expires August 7, 2014                 [Page 3]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

   [RFC2205] and [RFC3209].

   LSR: Label-Switch Router.

   LSP: An MPLS Label-Switched Path.  In this document, an LSP will
   always be explicitly routed.

   Local Repair: Techniques used to repair LSP tunnels quickly when a
   node or link along the LSP's path fails.

   PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a
   detour LSP.

   Facility Bypass: A local repair method in which a bypass tunnel is
   used to protect one or more protected LSPs that traverse the PLR, the
   resource being protected, and the Merge Point in that order.

   Protected LSP: An LSP is said to be protected at a given hop if it
   has one or multiple associated bypass tunnels originating at that
   hop.

   Bypass Tunnel: An LSP that is used to protect a set of LSPs passing
   over a common facility.

   NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that
   bypasses a single link of the protected LSP.

   NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel
   that bypasses a single node of the protected LSP.

   MP: Merge Point. The LSR where one or more bypass tunnels rejoin the
   path of the protected LSP downstream of the potential failure. The
   same LSR may be both an MP and a PLR simultaneously.

   CSPF: Constraint-based Shortest Path First.

   Downstream PLR: A PLR that locally detects a fault and reroutes
   traffic in the same direction of the protected bidirectional LSP RSVP
   Path signaling.

   Upstream PLR: A PLR that locally detects a fault and reroutes traffic
   in the opposite direction of the protected bidirectional LSP RSVP
   Path signaling.

   Point of Remote Repair (PRR): an upstream PLR that triggers reroute
   of traffic and signaling based on procedures described in this
   document.

 

Taillon et al.           Expires August 7, 2014                 [Page 4]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

3. Link Failure With Node-protection Bypass Tunnels

                            T1
                       +<<--------->>+
                      /               \       <-RESV
            [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 1: Flow of RSVP signaling post FRR after failure

   Consider the Traffic Engineered (TE) network shown in Figure 1.
   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. Consider a link R3-R4 on the
   protected LSP path fails.

   The proposed solution introduces two phases to invoking FRR
   procedures by the PLR post 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 cases where they go over
   asymmetric paths (i.e. non co-routed) in the forward and reverse
   directions after the first phase.

3.1. Behavior Before Local Repair

   To correctly reroute data traffic over a node-protection 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.

3.1.1. Downstream Merge Point Label Discovery

   [RFC4090] defines procedures for the downstream PLR to obtain the
   protected LSP's downstream MP label from recorded labels in the RRO
 

Taillon et al.           Expires August 7, 2014                 [Page 5]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

   of the RSVP Resv message received at the downstream PLR.

3.1.2. Upstream Merge Point Label Discovery

   To obtain the upstream MP label, existing methods to record upstream
   MP label in the RRO of the RSVP Path message are used. The upstream
   PLR can obtain the upstream MP label from the recorded label in the
   RRO of the received RSVP Path message.

3.2. Behavior Post Link Failure After FRR

   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
   stops receiving RSVP Path refreshes for the protected bidirectional
   LSP while primary protected traffic continues to flow over bypass
   tunnels.

3.3. Behavior Post 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:

      - 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.

      - If found, checks whether the primary LSP traffic and signaling
        are already rerouted over the found bypass tunnel. If not, PRR
        R5 activates FRR reroute procedures to direct traffic and
        signaling (RSVP Resv) over the found bypass tunnel T3 in the
        reverse

      - If PRR R5 is unable to successfully find a bypass tunnel
        that terminates on the downstream PLR, it may send an immediate
        RSVP Notify message back to the head-end. The head-end may tear
        and re-setup the protected LSP immediately.

   If MP R5 receives multiple RSVP Path messages through multiple bypass
   tunnels (e.g. as a result of multiple failures), the PRR SHOULD
 

Taillon et al.           Expires August 7, 2014                 [Page 6]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

   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.

                                           <- RSVP RESV
            [R1]---[R2]----[R3]--X--[R4]---[R5]---[R6]
              RSVP PATH ->   \             /
                              +<<------->>+
                              Bypass Tunnel
                            traffic + signaling

                 Protected LSP:  {R1-R2-R3-R4-R5-R6}
                 R3's Bypass T2: {R3-R5}
                 R5's Bypass T3: {R5-R3}

         Figure 2: Flow of RSVP signaling post FRR after re-corouted

   Figure 2 describes the path taken by traffic and signaling after
   completing re-coroute of data and signaling in the forward and
   reverse paths described earlier.

   The MP MAY optionally support handling in data plane as follows. If
   the MP is preconfigured 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.

4. Bypass Tunnel Assignment Coordination

   This document defines a new subobject in RSVP RECORD_ROUTE object,
   DOWNSTREAM_BYPASS_ASSIGNMENT, to extend RSVP-TE for fast-reroute
   signaling.

 

Taillon et al.           Expires August 7, 2014                 [Page 7]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

4.1. DOWNSTREAM_BYPASS_ASSIGNMENT Subobject

   The DOWNSTREAM_BYPASS_ASSIGNMENT subobject is used to inform the MP
   of the bypass tunnel being used by the PLR. This can be used to
   coordinate the bypass tunnel used 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
   MUST only be inserted into the Path message by the downstream PLR and
   MUST NOT be changed by downstream LSRs. The
   DOWNSTREAM_BYPASS_ASSIGNMENT subobject has the following format:

       The IPv4 DOWNSTREAM_BYPASS_ASSIGNMENT subobject 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         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                IPv4 Bypass Source Address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                IPv4 Bypass Destination Address                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The IPv6 DOWNSTREAM_BYPASS_ASSIGNMENT subobject 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        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                IPv6 Bypass Source Address                     |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                IPv6 Bypass Destination Address                |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Taillon et al.           Expires August 7, 2014                 [Page 8]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

      Type

            Downstream Bypass Assignment

      Length

            The Length contains the total length of the subobject in
       bytes, including the Type and Length fields.

      Bypass Source Address

            The bypass tunnel source IPV4 or IPV6 address.

      Bypass Destination Address

            The bypass tunnel destination IPV4 or IPV6 address.

      Bypass Tunnel ID

            The bypass tunnel identifier.

4.2. Bypass Tunnel Assignment Signaling Procedure

   In cases where bidirectional bypass tunnels are used for FRR Local
   Repair for a bidirectional co-routed LSP, it is desirable to
   coordinate the bypass tunnel selected at the downstream and upstream
   PLRs so that rerouted traffic and signaling flows on symmetrical
   paths post 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 DOWNSTREAM_BYPASS_ASSIGNMENT subobject is added by each
   downstream PLR in the RSVP Path RECORD_ROUTE message of the 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
   DOWNSTREAM_BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE
   object prior to adding the node's IP address. A node MUST NOT add a
   DOWNSTREAM_BYPASS_ASSIGNMENT subobject without also adding an IPv4 or
   IPv6 subobject.

   The upstream PLR (downstream MP) that detects a
   DOWNSTREAM_BYPASS_ASSIGNMENT subobject whose bypass tunnel
   destination matching its own address assigns the matching
   bidirectional bypass tunnel in the reverse direction, and forwards
 

Taillon et al.           Expires August 7, 2014                 [Page 9]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

   the RSVP Path message downstream. Otherwise, the bypass tunnel
   assignment subobject is simply forwarded downstream along in the RSVP
   Path message.

   In the absence of DOWNSTREAM_BYPASS_ASSIGNMENT subobject, the
   downstream MP can independently assign a bypass tunnel in the reverse
   direction. In the case of downstream MP receiving multiple
   DOWNSTREAM_BYPASS_ASSIGNMENT subobjects from multiple downstream
   PLRs, the decision of selecting a bypass tunnel in the reverse
   direction can be based on local policy, for example, prefer link
   protection versus node protection bypass tunnel, or prefer the most
   upstream versus least upstream node protection bypass tunnel. Note,
   the bypass tunnel selection will be corrected for co-routeness after
   FRR based on the PRR behavior after failure.

5. Compatibility

   New RSVP subobject DOWNSTREAM_BYPASS_ASSIGNMENT is defined for
   RECORD_ROUTE in this document. Per [RFC2205], nodes not supporting
   this subobject will ignore but forward it, unexamined and unmodified,
   in all messages resulting from this message.

6. Security Considerations

   This document introduces one new RSVP subobject. Thus in the event of
   the interception of a signaling message, slightly more information
   could be deduced about the state of the network than was previously
   the case, but this is judged to be a very minor security risk as this
   information is 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].

7. IANA Considerations

   A new type for the new DOWNSTREAM_BYPASS_ASSIGNMENT subobject for
   RSVP RECORD_ROUTE object is required.

8. Acknowledgements

   Authors would like to thank George Swallow for his detailed and
   useful comments and suggestions.

 

Taillon et al.           Expires August 7, 2014                [Page 10]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

9. References

9.1.  Normative References

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              January 2003.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

9.1.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description", RFC
              3471, January 2003.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC5920, July 2010.

 

Taillon et al.           Expires August 7, 2014                [Page 11]
Internet-Draft   FRR for Bidirectional Co-routed TE LSP February 3, 2014

Authors' Addresses

   Mike Taillon
   Cisco Systems, Inc.

   EMail: mtaillon@cisco.com

   Tarek Saad
   Cisco Systems, Inc.

   EMail: tsaad@cisco.com

   Rakesh Gandhi
   Cisco Systems, Inc.

   EMail: rgandhi@cisco.com

   Zafar Ali
   Cisco Systems, Inc.

   EMail: zali@cisco.com

   Manav Bhatia
   Alcatel-Lucent
   India

   Email: manav.bhatia@alcatel-lucent.com

   Lizhong Jin
   Shanghai, China

   Email: lizho.jin@gmail.com

   Frederic Jounay
   Orange CH

   Email: frederic.jounay@orange.ch

Taillon et al.           Expires August 7, 2014                [Page 12]