[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 draft-ietf-mpls-summary-frr-rsvpte

MPLS Working Group                                            M. Taillon
Internet-Draft                                              T. Saad, Ed.
Intended status: Standards Track                       Cisco Systems Inc
Expires: September 19, 2016                                       N. Tan
                                                         Arista Networks
                                                             A. Deshmukh
                                                                 M. Jork
                                                               V. Beeram
                                                        Juniper Networks
                                                          March 18, 2016


        RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels
               draft-mtaillon-mpls-summary-frr-rsvpte-04

Abstract

   This document defines RSVP-TE signaling extensions that reduce the
   amount of RSVP signaling required for Fast Reroute (FRR) procedures
   and subsequently improve the scalability of the RSVP-TE signaling
   when undergoing FRR convergence post a link or node failure.  Such
   extensions allow the RSVP message exchange between the Point of Local
   Repair (PLR) and the Merge Point (MP) to be independent of the number
   of protected Label Switched Paths (LSP)s traversing between them (eg.
   when bypass LSP FRR protection is used).  The new signaling
   extensions are fully backwards compatible with nodes that do not
   support them.

Status of This Memo

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

   This Internet-Draft will expire on September 19, 2016.







Taillon, et al.        Expires September 19, 2016               [Page 1]


Internet-Draft             RSVP-TE Summary FRR                March 2016


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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Summary FRR Signaling Procedures  . . . . . . . . . . . . . .   3
     2.1.  Signaling Procedures Prior to Failure . . . . . . . . . .   4
       2.1.1.  Extended ASSOCIATION Object . . . . . . . . . . . . .   4
       2.1.2.  PLR Summary FRR Signaling Procedure . . . . . . . . .   9
       2.1.3.  MP Summary FRR Signaling Procedure  . . . . . . . . .   9
     2.2.  Signaling Procedures Post Failure . . . . . . . . . . . .  10
       2.2.1.  SUMMARY_FRR_BYPASS Object . . . . . . . . . . . . . .  10
       2.2.2.  PLR Summary FRR Signaling Procedure . . . . . . . . .  12
       2.2.3.  MP Summary FRR Signaling Procedure  . . . . . . . . .  12
     2.3.  Refreshing Summary FRR Active LSPs  . . . . . . . . . . .  13
   3.  Compatibilty  . . . . . . . . . . . . . . . . . . . . . . . .  13
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   FRR procedures defined in [RFC4090] describe the mechanisms for the
   PLR to reroute traffic and signaling of a protected RSVP-TE LSP onto
   the bypass tunnel in the event of a TE link or node failure.  Such
   signaling procedures are performed individually for each affected
   protected LSP.  This may eventually lead to control plane scalability
   and latency issues under limited (memory and CPU processing)
   resources after failure that affects a large number of protected LSPs
   traversing the same PLR and MP.





Taillon, et al.        Expires September 19, 2016               [Page 2]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   In a large RSVP-TE LSPs scale deployment, a single LSR acting as a
   PLR node may host tens of thousands of protected RSVP-TE LSPs
   egressing the same link, and likewise, act as a Merge Point (MP) node
   for similar number of LSPs ingressing the same link.  In the event of
   the failure of the link or neighbor node, the RSVP-TE control plane
   of the node when acting as PLR becomes busy rerouting protected LSPs
   signaling over the bypass tunnel(s) in one direction, and when acting
   as an MP node becomes busy merging RSVP states from signaling
   received over bypass tunnels for LSP(s) in the reverse direction.
   Subsequently, the head-end LER(s) that are notified of the local
   repair at downstream LSR will attempt to (re)converge affected RSVP-
   TE LSPs onto newly computed paths - possibly traversing the same
   previously affected LSR(s).  As a result, the RSVP-TE control plane
   at the PLR and MP becomes overwhelmed by the amount of FRR RSVP-TE
   processing overhead following the link or node failure, and the
   competing other control plane protocol(s) (e.g. the IGP) that undergo
   their convergence at the same time.

   The extensions defined in this document enable an MP node to become
   aware of the PLR node's bypass tunnel assignment and allow FRR
   procedures between PLR node and MP node to be signaled and processed
   on groups of LSPs.  Further, the MESSAGE_ID for the rerouted PATH and
   RESV states are exchanged a priori to the fault such that Summary
   Refresh procedures defined in [RFC2961] can continue to be used to
   refresh the rerouted state(s) after FRR has occurred.

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.  Summary FRR Signaling Procedures

   The RSVP ASSOCIATION object was defined in [RFC4872] as a means to
   associate LSPs with each other.  For example, in the context of
   GMPLS-controlled LSP(s), the object is used to associate recovery
   LSPs with the LSP they are protecting.  The Extended ASSOCIATION
   object was also introduced in [RFC6780] to expand on the possible
   usage of the ASSOCIATION object and generalize the definition of the
   Association ID field.

   This document proposes the use of the Extended ASSOCIATION object to
   carry the Summary FRR information and associate the protected LSP(s)
   with the bypass tunnel that protects them.  To this extent, a new
   Association Type for the ASSOCIATION object, and a new Association ID




Taillon, et al.        Expires September 19, 2016               [Page 3]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   are proposed in this draft to describe the Bypass Summary FRR
   (B-SFRR) association.

   The ASSOCIATION object is defined with a class number in the form
   11bbbbbb, which ensures compatibility with non-supporting node.  As
   per [RFC2205], such nodes will ignore the object but forward it
   without modification.

   This document also defines a new RSVP ACTIVE SUMMARY_FRR_BYPASS
   object that is sent within the RSVP Path message of a bypass LSP to
   inform the MP node that one or more groups of protected LSPs that are
   being protected by the bypass tunnel are being rerouted.

   The PLR creates and manages the Summary FRR LSP groups
   (Bypass_Group_Identifiers) and shares them with the MP via signaling.
   Protected LSPs sharing the same egress link and bypass assignment are
   grouped together and are assigned the same group.  The MP maintains
   the PLR group assignments learned via signaling, and acknowledges the
   group assignments via signaling.  Once the PLR receives the
   acknowledgment, FRR signaling can proceed as group based.

   The PLR node that supports Summary FRR procedures adds the Extended
   ASSOCIATION object with Bypass Summary FRR Association Type -
   referred to thereon in this document as B-SFRR Extended ASSOCIATION
   object- in a the RSVP Path message of the protected LSP to inform the
   MP of the PLR's assigned bypass tunnel, Summary FRR
   Bypass_Group_Identifier, and the MESSAGE_ID object that the PLR will
   use to refresh the protected LSP PATH state after FRR occurs.

   The MP node that supports Summary FRR procedures adds the B-SFRR
   Extended ASSOCIATION object in a RSVP Resv message of the protected
   LSP to acknowledge the PLR's bypass tunnel assignment, and provide
   the MESSAGE_ID object that the MP node will use to refresh the
   protected LSP RESV state after FRR occurs.

2.1.  Signaling Procedures Prior to Failure

   Before Summary FRR procedures can be used, a handshake MUST be
   completed between the PLR and MP.  This handshake is performed using
   B-SFRR Extended ASSOCIATION object that is carried in both the RSVP
   Path and Resv messages of the protected LSP.

2.1.1.  Extended ASSOCIATION Object

   The B-SFRR Extended ASSOCIATION object is populated using the rules
   defined below to associate the Summary FRR enabled protected LSP with
   the bypass LSP that is protecting it.




Taillon, et al.        Expires September 19, 2016               [Page 4]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   The Association Type, Association ID, and Association Source MUST be
   set as defined in [RFC4872] for the ASSOCIATION Object.  More
   specifically:

   Association Source:

     The Association Source is set to an address selected by the node
     that originates the association. For Bypass Summary FRR association
     it is set to an address of the PLR node.

   Association Type:

     The Association Type is set to indicate the Bypass Summary FRR
     association. A new Association Type is defined as follows:

     Value      Type
     -------    ------
     (TBD-1)    Bypass Summary FRR Association (B-SFRR)

   Extended Association ID:

    The Extended Association ID is populated by the node originating the
    association -- i.e. the PLR for the Bypass Summary FRR association.
    The rules to populate the Extended Association ID in this case is
    described in Section below.

2.1.1.1.  IPv4 Extended Association ID

   The IPv4 Extended Association ID for Summary FRR bypass assignment
   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Bypass_Tunnel_ID        |         Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Bypass_Source_IPv4_Address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Bypass_Destination_IPv4_Address                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Bypass_Group_Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                MESSAGE_ID                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Taillon, et al.        Expires September 19, 2016               [Page 5]


Internet-Draft             RSVP-TE Summary FRR                March 2016


     Bypass_Tunnel_ID: 16 bits

           The bypass tunnel identifier.

     Reserved: 16 bits

           Reserved for future use.

     Bypass_Source_IPv4_Address: 32 bits

           The bypass tunnel source IPV4 address.

     Bypass_Destination_IPv4_Address: 32 bits

           The bypass tunnel destination IPV4 address.

     Bypass_Group_Identifier: 32 bits

           The bypass tunnel group identifier.

     MESSAGE_ID

           A MESSAGE_ID object as defined by {{RFC2961}}.

2.1.1.2.  IPv6 Extended Association ID

   The IPv6 Extended Association ID field for the Summary FRR
   information has the following format:























Taillon, et al.        Expires September 19, 2016               [Page 6]


Internet-Draft             RSVP-TE Summary FRR                March 2016


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Bypass_Tunnel_ID        |         Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                Bypass_Source_IPv6_Address                     +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                Bypass_Destination_IPv6_Address                +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Bypass_Group_Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                MESSAGE_ID                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


























Taillon, et al.        Expires September 19, 2016               [Page 7]


Internet-Draft             RSVP-TE Summary FRR                March 2016


     Bypass_Tunnel_ID: 16 bits

           The bypass tunnel identifier.

     Reserved: 16 bits

           Reserved for future use.

     Bypass_Source_IPv6_Address: 128 bits

           The bypass tunnel source IPV4 address.

     Bypass_Destination_IPv6_Address: 128 bits

           The bypass tunnel destination IPV4 address.

     Bypass_Group_Identifier: 32 bits

           The bypass tunnel group identifier.

     MESSAGE_ID

           A MESSAGE_ID object as defined by {{RFC2961}}.

   The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each
   protected LSP.  The same Bypass_Group_Identifier is used for the set
   of protected LSPs that share the same bypass tunnel and traverse the
   same egress link and are not already rerouted.  The PLR also
   generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and
   Message_Identifier MUST be set according to [RFC2961]).

   The PLR MUST generate a new Message_Identifier each time the contents
   of the B-SFRR Extended ASSOCIATION object change; for example, when
   PLR node changes the bypass tunnel assignment.

   The PLR node notifies the MP node of the bypass tunnel assignment via
   adding a B-SFRR Extended ASSOCIATION object in the RSVP Path message
   for the protected LSP using procedures described in Section 2.2.

   The MP node acknowledges the PLR node's assignment by signaling the
   B-SFRR Extended Association object within the RSVP Resv messsage of
   the protected LSP.  With exception of the MESSAGE_ID objects, all
   other fields of the received B-SFRR Extended ASSOCIATION object in
   the RSVP Path message are copied into the B-SFRR Extended ASSOCIATION
   object to be added in the Resv message.  The MESSAGE_ID object is set
   according to [RFC2961] with the Flags being clear.  A new
   Message_Identifier MUST be used to acknowledge an updated PLR
   assignment.



Taillon, et al.        Expires September 19, 2016               [Page 8]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   The PLR considers the protected LSP as Summary FRR capable only if
   the B-SFRR Extended ASSOCIATION objects sent in the RSVP Path message
   and the one received in the RSVP Resv message (with exception of the
   MESSAGE_ID) match.  If it does not match, or if B-SFRR Extended
   Association object is absent in a subsequent refresh, the PLR node
   MUST consider the protected LSP as not Summary FRR capable.

2.1.2.  PLR Summary FRR Signaling Procedure

   The B-SFRR Extended ASSOCIATION object is added by each PLR in the
   RSVP Path message of the protected LSP to record the bypass tunnel
   assignment.  This object is updated every time the PLR updates the
   bypass tunnel assignment (which triggers an RSVP Path change
   message).

   Upon receiving an RSVP Resv message with B-SFRR Extended ASSOCIATION
   object, the PLR node checks if the expected subobjects in the B-SFRR
   Extended ASSOCIATION ID are present.  If present, the PLR determines
   if the MP has acknowledged the current PLR assignment.

   To be a valid acknowledgement, the received B-SFRR Extended
   ASSOCIATION object contents within the RSVP Resv message of the
   protected LSP MUST match the latest B-SFRR Extended ASSOCIATION
   object contents that the PLR node had sent within the RSVP Path
   message (with exception of the MESSAGE_ID)

   Note, when forwarding an RSVP Resv message upstream, the PLR node
   SHOULD remove any/all B-SFRR Extended ASSOCIATION objects whose
   Association Source matches the PLR node's address.

2.1.3.  MP Summary FRR Signaling Procedure

   Upon receiving an RSVP Path message with an B-SFRR Extended
   ASSOCIATION object, the MP node processes all (there may be multiple
   PLRs for a single MP) B-SFRR Extended ASSOCIATION objects that has
   the MP node address as Bypass Destination address in the Association
   ID.

   The MP node first ensures the existence of the bypass tunnel and that
   the Bypass_Group_Identifier is not already FRR active.  That is, an
   LSP cannot join a group that is already FRR rerouted.

   The MP node builds a mirrored Summary FRR Group database per PLR,
   which is determined using the Bypass_Source_Address field.  The
   MESSAGE_ID is extracted and recorded for the protected LSP PATH
   state.  The MP node signals a B-SFRR Extended Association object
   within the RSVP Resv messsage of the protected LSP.  With exception
   of the MESSAGE_ID objects, all other fields of the received B-SFRR



Taillon, et al.        Expires September 19, 2016               [Page 9]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   Extended ASSOCIATION object in the RSVP Path message are copied into
   the B-SFRR Extended ASSOCIATION object to be added in the Resv
   message.  The MESSAGE_ID object is set according to [RFC2961] with
   the Flags being clear.

   Note, an MP may receive more than one RSVP Path message with the
   B-SFRR Extended ASSOCIATION object from different upstream PLR
   node(s).  In this case, the MP node is expected to save all the
   received MESSAGE_IDs from the different upstream PLR node(s).  Post
   failure, the MP node determines and activates the associated Sumamry
   Refresh ID to use once it receives and processes the RSVP Path
   message with ACTIVE SUMMARY_FRR_BYPASS object over the bypass LSP
   from the PLR.

   When forwarding an RSVP Path message downstream, the MP SHOULD remove
   any/all B-SFRR Extended ASSOCIATION object(s) whose Association ID
   contains Bypass_Destination_Address matching the MP node address.

2.2.  Signaling Procedures Post Failure

   Upon detection of the fault (egress link or node failure) the PLR
   first performs the object modification procedures described by
   Section 6.4.3 of [RFC4090] for all affected protected LSPs.  For
   Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP
   and SENDER_TEMPLATE MUST be used.

   The PLR MUST signal non-Summary FRR enabled LSPs over the bypass
   tunnel before signaling the Summary FRR enabled LSPs.  This is needed
   to allow for the case when the PLR node has recently changed a bypass
   assignment and the MP has not processed the change yet.

   A new object ACTIVE SUMMARY_FRR_BYPASS is defined in Section 2.2.1
   and sent within the RSVP Path message of the bypass LSP to reroute
   RSVP state of Summary FRR enabled LSPs.

2.2.1.  SUMMARY_FRR_BYPASS Object

   The SUMMARY_FRR_BYPASS object is carried in the Path message of a
   bypass LSP.  The ACTIVE SUMMARY_FRR_BYPASS is added by the PLR node
   to indicate to the MP node (bypass tunnel destination) that one or
   more groups of protected LSPs that are being protected by the
   specified bypass tunnel are being rerouted over the bypass tunnel.

   The ACTIVE SUMMARY_FRR_BYPASS object is assigned the C-Type (TBD-3).
   The ACTIVE SUMMARY_FRR_BYPASS object has the below format.

   SUMMARY_FRR_BYPASS Class-Num = (TBD-2) (of the form 11bbbbbb) Class-
   Name = SUMMARY_FRR_BYPASS Class, ACTIVE C-Type = (TBD-3)



Taillon, et al.        Expires September 19, 2016              [Page 10]


Internet-Draft             RSVP-TE Summary FRR                March 2016


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             | Class-N(TBD-2)| C-Type (TBD-3)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved           |       Num-BGIDs               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Bypass_Group_Identifier                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                 :                             |
      //                                :                            //
      |                                 :                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Bypass_Group_Identifier                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           RSVP_HOP_Object                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           TIMES_VALUE                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved: 16 bits

      Reserved for future use.

   Bypass_Group_Identifier: 32 bits

   Bypass_Group_Identifier field previously exchanged using the Extended
   Association object corresponding to all LSPs that the bypass headend
   (PLR) advertised this specific Bypass_Group_Identifier for.  One or
   more Bypass_Group_Identifiers may be included.

   Num-BGIDs: 32 bits

      Number of Bypass_Group_Identifier fields.

   RSVP_HOP_Object: Class 3, as defined by [RFC2205]

      Replacement HOP object to be applied to all LSPs associated
      with each of the following Bypass_Group_Identifiers.

   TIME_VALUES object: Class 5, as defined by [RFC2205]

    Replacement TIMES_VALUES object to be applied to all LSPs associated
    with each of the following Bypass_Group_Identifiers.







Taillon, et al.        Expires September 19, 2016              [Page 11]


Internet-Draft             RSVP-TE Summary FRR                March 2016


2.2.2.  PLR Summary FRR Signaling Procedure

   Post a failure event, when using the Summary FRR path signaling
   procedures, an individual RSVP Path message for each Summary FRR LSP
   is not signaled.  Instead, to reroute Summary FRR LSPs via the bypass
   tunnel, the PLR adds the ACTIVE SUMMARY_FRR_BYPASS object in the RSVP
   Path message of the RSVP session of the bypass tunnel.

   The RSVP_HOP_Object field of the ACTIVE SUMMARY_FRR_BYPASS object is
   set to the common RSVP_HOP that was used by the PLR in Section 2.2.

   The previously received MESSAGE_ID from the MP is activated.  As a
   result, the MP may refresh the protected rerouted RESV state using
   Summary Refresh procedures.

   For each affected Summary FRR group, its group identifier is added to
   the ACTIVE SUMMARY_FRR_BYPASS object.

2.2.3.  MP Summary FRR Signaling Procedure

   Upon receiving an RSVP Path message with a ACTIVE SUMMARY_FRR_BYPASS
   object, the MP performs normal merging processing for each protected
   LSP associated with each Bypass_Group_Identifier, as if it received
   individual RSVP Path messages for the LSP.

   For each Summary FRR LSP being merged, the MP first modifies the Path
   state as follows:

   1.  The RSVP_HOP object is copied from the ACTIVE SUMMARY_FRR_BYPASS
       RSVP_HOP_Object field.

   2.  The TIMES_VALUE object is copied from the ACTIVE
       SUMMARY_FRR_BYPASS TIMES_VALUE field.

   3.  The SENDER_TEMPLATE object SrcAddress field is copied from the
       bypass tunnel SENDER_TEMPLATE object.  For the case where PLR is
       also the headend, and SENDER_TEMPLATE SrcAddress of the protected
       LSP and bypass tunnel are the same, the MP MUST use the modified
       HOP Hop Address field instead.

   4.  The ERO object is modified as per Section 6.4.4. of [RFC4090].
       Once the above modifications are completed, the MP then performs
       the merge processing as per [RFC4090].

   5.  The previously received MESSAGE_ID from the PLR is activated,
       meaning that the PLR may now refresh the protected rerouted PATH
       state using Summary Refresh procedures.




Taillon, et al.        Expires September 19, 2016              [Page 12]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   A failure during merge processing of any individual rerouted LSP MUST
   result in an RSVP Path Error message.

   An individual RSVP Resv message for each successfully merged Summary
   FRR LSP is not signaled.  The MP node SHOULD immediately use Summary
   Refresh procedures to refresh the protected LSP RESV state.

2.3.  Refreshing Summary FRR Active LSPs

   Refreshing of Summary FRR active LSPs is performed using Summary
   Refresh as defined by [RFC2961].

3.  Compatibilty

   The (Extended) ASSOCIATION object is defined in [RFC4872] with a
   class number in the form 11bbbbbb, which ensures compatibility with
   non-supporting node(s).  Such nodes will ignore the object and
   forward it without modification.

   The new ACTIVE SUMMARY_FRR_BYPASS object is to be defined with a
   class number in the form 11bbbbbb, which ensures compatibility with
   non-supporting nodes.  Per [RFC2205], the nodes not supporting this
   extension will ignore the object but forward it, unexamined and
   unmodified, in all messages.

4.  Security Considerations

   This document updates an existing RSVP object, and introduces a new
   RSVP object.  Thus in the event of the interception of a signaling
   message, slightly more could be deduced about the state of the
   network than was previously the case.

5.  IANA Considerations

   IANA maintains the "Generalized Multi-Protocol Label Switching
   (GMPLS) Signaling Parameters" registry (see
   http://www.iana.org/assignments/gmpls-sig-parameters ).  The
   "Association Type" subregistry is included in this registry.

   This registry has been updated by new Association Types for
   ASSOCIATION and Extended ASSOCIATION Objects defined in this document
   as follows:

    Value    Name                                          Reference
    -----    ----                                          ---------
    TBD-1    Bypass Summary FRR Association (B-SFRR)       Section 2.1.1





Taillon, et al.        Expires September 19, 2016              [Page 13]


Internet-Draft             RSVP-TE Summary FRR                March 2016


   IANA also maintains and assigns the values for the RSVP-TE protocol
   parameters "Resource Reservation Protocol (RSVP) Parameters" (see
   http://www.iana.org/assignments/rsvp-parameters).

   From this registry, a new RSVP Class (TBD-2) and of the form 11bbbbbb
   and a new C-Type (TBD-3) are requested for the new ACTIVE
   SUMMARY_FRR_BYPASS object defined in this document.

6.  Acknowledgments

   The authors would like to thank Loa Andersson, Lou Berger, Eric
   Osborne, Gregory Mirsky, and Mach Chen for reviewing and providing
   valuable comments to this document.

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <http://www.rfc-editor.org/info/rfc2205>.

   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
              <http://www.rfc-editor.org/info/rfc2961>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <http://www.rfc-editor.org/info/rfc4090>.

   [RFC4872]  Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
              Ed., "RSVP-TE Extensions in Support of End-to-End
              Generalized Multi-Protocol Label Switching (GMPLS)
              Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
              <http://www.rfc-editor.org/info/rfc4872>.

   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
              ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/
              RFC6780, October 2012,
              <http://www.rfc-editor.org/info/rfc6780>.





Taillon, et al.        Expires September 19, 2016              [Page 14]


Internet-Draft             RSVP-TE Summary FRR                March 2016


Authors' Addresses

   Mike Taillon
   Cisco Systems Inc

   Email: mtaillon@cisco.com


   Tarek Saad (editor)
   Cisco Systems Inc

   Email: tsaad@cisco.com


   Nicholas Tan
   Arista Networks

   Email: ntan@arista.com


   Abhishek Deshmukh
   Juniper Networks

   Email: adeshmukh@juniper.net


   Markus Jork
   Juniper Networks

   Email: mjork@juniper.net


   Vishnu Pavan Beeram
   Juniper Networks

   Email: vbeeram@juniper.net















Taillon, et al.        Expires September 19, 2016              [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/