TEAS Working Group                                           J. He
Internet Draft                                             I. Busi
Updates (if published): RFC 4872                            Huawei
Intended status: Standards Track

Expires: July 14, 2019                            January 15, 2019

          GMPLS Signaling Extensions for Shared Mesh Protection
               draft-ietf-teas-gmpls-signaling-smp-00.txt


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
   https://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 July 14, 2019.



Copyright Notice

   Copyright (c) 2018 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.





<He, et al.>            Expires July 14, 2019               [Page 1]


Internet-Draft         GMPLS Extension for SMP           January 2019


Abstract

   ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects
   of a shared mesh protection (SMP) mechanism, where the difference
   between SMP and shared mesh restoration (SMR) is also identified.
   ITU-T Recommendation G.873.3 [G873.3] defines the protection
   switching operation and associated protocol for shared mesh
   protection (SMP) at the optical data unit (ODU) layer. RFC 7412
   provides requirements for any mechanism that would be used to
   implement SMP in an MPLS-TP network.

   This document updates RFC 4872 to provide the extensions to the
   Generalized Multi-Protocol Label Switching (GMPLS) signaling to
   support the control of the shared mesh protection.

Table of Contents


   1. Introduction ................................................2
   2. Conventions used in this document............................3
   3. SMP Definition ..............................................3
   4. GMPLS Signaling Extension for SMP............................4
      4.1. Identifiers ............................................5
      4.2. Signaling Primary LSPs..................................6
      4.3. Signaling Secondary LSPs................................6
   5. Updates to PROTECTION Object.................................7
      5.1. New Protection Type.....................................7
      5.2. Other Updates ..........................................7
   6. Security Considerations......................................8
   7. IANA Considerations .........................................8
   8. References ..................................................8
      8.1. Normative References....................................8
      8.2. Informative References..................................9

1. Introduction

   RFC 4872 [RFC4872] defines extension of RSVP-TE to support shared
   mesh restoration (SMR) mechanism. Shared mesh restoration can be
   seen as a particular case of pre-planned LSP rerouting that
   reduces the recovery resource requirements by allowing multiple
   protecting LSPs to share common link and node resources. The
   recovery resources for the protecting LSPs are pre-reserved during
   the provisioning phase, and an explicit restoration signaling is
   required to activate (i.e., commit resource allocation at the data
   plane) a specific protecting LSP instantiated during the
   provisioning phase.



<He, et al.>            Expires July 14, 2019               [Page 2]


Internet-Draft         GMPLS Extension for SMP           January 2019


   ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects
   of a shared mesh protection (SMP) mechanism. ITU-T Recommendation
   G.873.3 [G873.3] defines the protection switching operation and
   associated protocol for shared mesh protection (SMP) at the optical
   data unit (ODU) layer. RFC 7412 provides requirements for any
   mechanism that would be used to implement SMP in an MPLS-TP network.

   SMP differs from SMR in the activation/protection switching
   operation. The former activates a protecting LSP via the automatic
   protection switching (APS) protocol in the data plane when the
   working LSP fails, while the latter via the control plane
   signaling. It is therefore necessary to distinguish SMP from SMR
   during provisioning so that each node involved behaves
   appropriately in the recovery phase when activation of a
   protecting LSP is done.

   This document updates RFC 4872 to provide the extensions to the
   Generalized Multi-Protocol Label Switching (GMPLS) signaling to
   support the control of the shared mesh protection mechanism. Only
   the generic aspects for signaling SMP are addressed by this
   document. The technology-specific aspects are expected to be
   addressed by other drafts.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", and   "OPTIONAL" in this document are to be interpreted as
   described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

   In addition, the reader is assumed to be familiar with the
   terminology used in [RFC4872] and [RFC4426].



3. SMP Definition

   ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects
   of a shared mesh protection (SMP) mechanism. ITU-T Recommendation
   G.873.3 [G873.3] defines the protection switching operation and
   associated protocol for shared mesh protection (SMP) at the optical
   data unit (ODU) layer. RFC 7412 provides requirements for any
   mechanism that would be used to implement SMP in an MPLS-TP network.

   The SMP mechanism is based on pre-computed protection transport
   entities that are pre-configured into the network elements. Pre-


<He, et al.>            Expires July 14, 2019               [Page 3]


Internet-Draft         GMPLS Extension for SMP           January 2019


   configuration here means pre-reserving resources for the
   protecting LSPs without activating a particular protecting LSP
   (e.g. in circuit networks, the cross-connects in the intermediate
   nodes of the protecting LSP are not pre-established). Pre-
   configuring but not activating the protecting LSP allows the
   common link and node resources in a protecting LSP to be shared by
   multiple working LSPs that are physically (i.e., link, node, SRLG,
   etc.) disjoint. Protecting LSPs are activated in response to
   failures of working LSPs or operator's commands by means of the
   APS protocol that operates in the data plane. SMP is always
   revertive.

   SMP has a lot of similarity to SMR except that the activation in
   case of SMR is achieved by control plan signaling during the
   recovery operation while SMP is done by APS protocol in the data
   plane. SMP has advantages with regard to the recovery speed
   compared with SMR.



4. GMPLS Signaling Extension for SMP

   Consider the following network topology:

                                  A---B---C---D
                                   \         /
                                    E---F---G
                                   /         \
                                  H---I---J---K

   The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by
   [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order
   to achieve resource sharing during the signaling of these
   protecting LSPs, they must have the same Tunnel Endpoint Address
   (as part of their SESSION object). However, these addresses are
   not the same in this example. Similar to SMR, a new LSP Protection
   Type of the secondary LSP is defined as "Shared Mesh Protection"
   (see PROTECTION object defined in [RFC4872]) to allow resource
   sharing along nodes E, F, and G. In this case, the protecting LSPs
   are not merged (which is useful since the paths diverge at G), but
   the resources along E, F, G can be shared.

   When a failure is detected on one of the working LSPs (say working
   LSP [A,B,C,D]), the switching operation for the egress node (say
   node A) will be triggered by an Signal Degrade (SD) or Signal Fail
   (SF) on the working LSP. The egress node A will send a protection


<He, et al.>            Expires July 14, 2019               [Page 4]


Internet-Draft         GMPLS Extension for SMP           January 2019


   switching request APS message (for example SF) to its adjacent
   (downstream) intermediate node (say node E) to activate setting up
   the corresponding protecting LSP. If the protection resource is
   available, Node E will send a confirmation message to the egress node
   A and forward the switching request APS message to its adjacent
   (downstream) node (say node F). When the confirmation message is
   received by node A and the protection resource is available, the
   cross-connection on node A is established. At this time the traffic
   is bridged to and selected from the protecting LSP at node A. The
   node E will wait for the confirmation message from node F, which
   triggers node E to set up the cross-connection for the protection
   transport entity being activated. If the protection resource is not
   available (due to failure or being used by higher priority
   connections), the switching will not be successful; the intermediate
   node may send a message to notify the end node, or keep trying until
   the resource is available or the switching request is cancelled. If
   the resource is in use by a lower priority protection entity, the
   lower priority service will be removed and then the intermediate node
   will follow the procedure as described for the case when the resource
   is available.

   The following subsections detail how shared mesh protection can be
   implemented in an interoperable fashion using GMPLS RSVP-TE
   extensions (see [RFC3473]). This includes:

   (1)  the ability to identify a "secondary protecting LSP" (hereby
   called the "secondary LSP") used to recover another primary
   working LSP (hereby called the "protected LSP")

   (2)  the ability to associate the secondary LSP with the protected
   LSP

   (3)  the capability to include information about the resources
   used by the protected LSP while instantiating the secondary LSP.

   (4)  the capability to instantiate during the provisioning phase
   several secondary LSPs in an efficient manner.

   (5)  the capability to support activation of a secondary LSP after
   failure occurrence via APS protocol in the data plane.

4.1. Identifiers

   To simplify association operations, both LSPs (i.e., the protected
   and the secondary LSPs) belong to the same session. Thus, the
   SESSION object MUST be the same for both LSPs. The LSP ID,



<He, et al.>            Expires July 14, 2019               [Page 5]


Internet-Draft         GMPLS Extension for SMP           January 2019


   however, MUST be different to distinguish between the protected
   LSP carrying working traffic and the secondary LSP.

   A new LSP Protection Type "Shared Mesh Protection" is introduced
   to the LSP Flags of PROTECTION object (see [RFC4872]) to set up
   the two LSPs.  This LSP Protection Type value is applicable to
   both uni- and bidirectional LSPs.


4.2. Signaling Primary LSPs


   The PROTECTION object (see [RFC4872]) is included in the Path
   message during signaling of the primary working LSPs, with the LSP
   Protection Type value set to "Shared Mesh Protection".

   Primary working LSPs are signaled by setting in the POTECTION
   object the S bit to 0, the P bit to 0, the N bit to 1 and in the
   ASSOCIATION object, the Association ID to the associated secondary
   protecting LSP_ID.

   Note: N bit is set to indicate that the protection switching
   signaling is done via data plane.



4.3. Signaling Secondary LSPs


   The PROTECTION object (see [RFC4872]) is included in the Path
   message during signaling of the secondary protecting LSPs, with
   the LSP Protection Type value set to "Shared Mesh Protection".

   Secondary protecting LSPs are signaled by setting in the
   PROTECTION object the S bit and the P bit to 1, the N bit to 1 and
   in the ASSOCIATION object, the Association ID to the associated
   primary working LSP_ID, which MUST be known before signaling of
   the secondary LSP. Moreover, the Path message used to instantiate
   the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE
   object (see [RFC4872]) that further allows for recovery resource
   sharing at each intermediate node along the secondary path.

   With this setting, the resources for the secondary LSP SHOULD be
   pre-reserved, but not committed at the data plane level, meaning
   that the internals of the switch need not be established until
   explicit action is taken to activate this LSP.  Activation of a


<He, et al.>            Expires July 14, 2019               [Page 6]


Internet-Draft         GMPLS Extension for SMP           January 2019


   secondary LSP and protection switching to the activated protecting
   LSP is done using APS protocol in the data plane.

   After protection switching completes the protecting LSP SHOULD be
   signaled with the S bit set to 0 and O bit set to 1 in the
   PROTECTION object. At this point, the link and node resources must
   be allocated for this LSP that becomes a primary LSP (ready to
   carry normal traffic). The formerly working LSP MAY be signaled
   with the A bit set in the ADMIN_STATUS object (see [RFC3473]).

5. Updates to PROTECTION Object

   GMPLS extension requirements for SMP introduce several updates to
   the Protection Object (see [RFC4872]).

5.1. New Protection Type

   A new LSP protection type "Shared Mesh Protection" is added in the
   protection object. This LSP Protection Type value is applicable to
   both uni- and bidirectional LSPs.

   LSP (Protection Type) Flags

   0x11   Shared Mesh Protection



5.2. Other Updates

   N bit and O bit in the Protection object as defined in [RFC4872]
   are also updated to include applicability to SMP.

   Notification (N): 1 bit

   When set to 1, this bit indicates that the control plane message
   exchange is only used for notification during protection
   switching.  When set to 0 (default), it indicates that the control
   plane message exchanges are used for protection-switching
   purposes.  The N bit is only applicable when the LSP Protection
   Type Flag is set to either 0x04 (1:N Protection with Extra-
   Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1
   Bidirectional Protection), or 0x11 (Shared Mesh Protection).  The
   N bit MUST be set to 0 in any other case.



   Operational (O): 1 bit


<He, et al.>            Expires July 14, 2019               [Page 7]


Internet-Draft         GMPLS Extension for SMP           January 2019


   When set to 1, this bit indicates that the protecting LSP is
   carrying the normal traffic after protection switching.  The O bit
   is only applicable when the P bit is set to 1, and the LSP
   Protection Type Flag is set to either 0x04 (1:N Protection with
   Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10
   (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection).
   The O bit MUST be set to 0 in any other case.

6. Security Considerations

   No further security considerations than [RFC4872].

7. IANA Considerations

   There are no IANA actions required.



8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 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., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January
             2003.

   [RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
             "Generalized Multi-Protocol Label Switching (GMPLS)
             Recovery Functional Specification", RFC 4426, March
             2006.

   [RFC4872] Lang, J.P., 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, May 2007.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
             May 2017.


<He, et al.>            Expires July 14, 2019               [Page 8]


Internet-Draft         GMPLS Extension for SMP           January 2019


   [G808.3]  ITU-T, "Generic protection switching - Shared mesh
             protection", G.808.3, October 2012.

8.2. Informative References

   [G873.3]  ITU-T, "Optical transport network - Shared mesh
             protection", G.873.3, September 2017.

   [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., Mirsky,
             G., "Requirements for MPLS Transport Profile (MPLS-TP)
             Shared Mesh Protection", RFC 7412, December 2014.



Authors' Addresses

   Jia He
   Huawei Technologies Co.,Ltd.
   F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang
   District, Shenzhen, China

   Email: hejia@huawei.com


   Italo Busi
   Huawei

   Email: italo.busi@huawei.com




















<He, et al.>            Expires July 14, 2019               [Page 9]