Network Working Group                                            J. Dong
Internet-Draft                                                   M. Chen
Intended status: Standards Track                     Huawei Technologies
Expires: October 24, 2014                                          Z. Li
                                                            China Mobile
                                                           D. Ceccarelli
                                                                Ericsson
                                                          April 22, 2014


        GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
                   draft-ietf-ccamp-rsvp-te-li-lb-03

Abstract

   This document specifies extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
   Loopback (LB) mechanisms for Label Switched Paths (LSPs).  These
   mechanisms are applicable to technologies which use Generalized
   Multi-Protocol Label Switching (GMPLS) as control plane.

Requirements Language

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

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 October 24, 2014.








Dong, et al.            Expires October 24, 2014                [Page 1]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


Copyright 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Extensions to RSVP-TE . . . . . . . . . . . . . . . . . . . .   3
   3.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Lock Instruct . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Loopback  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The requirements for Lock Instruct (LI) and Loopback (LB) in
   Multiprotocol Label Switching Transport Profile (MPLS-TP) are
   specified in [RFC5860], and the framework of LI and LB is specified
   in [RFC6371].

   In general the LI and LB are useful Operations, Administration and
   Maintenance (OAM) functions for technologies which use Generalized
   Multi-Protocol Label Switching (GMPLS) as control plane, e.g. time-
   division multiplexing, wavelength-division multiplexing and packet
   switching.  It is natural to use and extend the GMPLS control plane
   protocol to provide a unified approach for LI and LB provisioning in
   all these technologies.

   This document specifies extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) to support lock instruct and loopback
   mechanisms for Label Switched Paths (LSPs).  The mechanisms are



Dong, et al.            Expires October 24, 2014                [Page 2]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


   applicable to technologies which use GMPLS as control plane.  For
   MPLS-TP network, the mechanisms defined in this document are
   complementary to [RFC6435].

2.  Extensions to RSVP-TE

   The A (Administratively down) bit in ADMIN_STATUS object [RFC3471]
   [RFC3473] is used to indicate the lock/unlock of the LSP.  Format of
   ADMIN_STATUS Object is as below:

       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-Num(196)|   C-Type (1)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R|                        Reserved               |H|L|I|C|T|A|D|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reflect (R): 1 bit - see [RFC3471]
   Handover (H): 1 bit - see [RFC5852]
   Lockout (L): 1 bit - see [RFC4872]
   Inhibit Alarm Indication (I): 1 bit - see [RFC4783]
   Call Control (C): 1 bit - see [RFC4974]
   Testing (T): 1 bit - see [RFC3471]
   Administratively down (A): 1 bit - see [RFC3471], reused for Lock
   Deletion in progress (D): 1 bit - see [RFC3471]

   A new bit is defined in Attribute Flags TLV [RFC5420] to indicate the
   loopback mode.  The bit number is TBA.

Bit Number   Name and Usage
TBA          Loopback mode desired.
             This flag indicates a particular node on the LSP is required
             to enter loopback mode.
             This MAY also be used for specifying the loopback state
             of the node.

3.  Operations

3.1.  Lock Instruct

   When an ingress LSR intends to put an LSP into lock mode, it MUST
   send a Path message with the Administratively down (A) bit and the
   Reflect (R) bit in ADMIN_STATUS Object set.  The intermediate nodes
   SHOULD forward the message with the A bit unchanged to the downstream
   .





Dong, et al.            Expires October 24, 2014                [Page 3]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


   On receipt of this Path message, the egress LSR SHOULD try to take
   the LSP out of service.  If the egress Label Switching Router (LSR)
   locks the LSP successfully, it SHOULD send a Resv message with the A
   bit in ADMIN_STATUS object set.  Otherwise, it SHOULD send a PathErr
   message with the Error Code "OAM Problem"
   [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value "Lock
   Failure", and the following Resv messages SHOULD be sent with the A
   bit cleared.  With this procedure, the intermediate nodes would also
   be aware of whether the LSP is in Lock mode or not.

   When an LSP is put in lock mode, the subsequent Path and Resv
   messages SHOULD keep the A bit in ADMIN_STATUS Object set.

   When the ingress LSR intends to take the LSP out of the lock mode, it
   MUST send a Path message with the A bit in ADMIN_STATUS Object
   cleared.  The intermediate nodes SHOULD forward this message with the
   A bit unchanged to the downstream.

   On receipt of this Path message, the egress LSR SHOULD try to bring
   the LSP back to service.  If the egress LSR unlocks the LSP
   successfully, it SHOULD send a Resv message with the A bit in
   ADMIN_STATUS Object cleared.  Otherwise, it SHOULD send a PathErr
   message with the Error Code "OAM Problem"
   [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value
   "Unlock Failure", and the following Resv messages SHOULD be sent with
   the A bit set.

   When an LSP is taken out of lock mode, the subsequent Path and Resv
   messages SHOULD keep the A bit in ADMIN_STATUS Object cleared.

3.2.  Loopback

   The loopback request can be sent either to the egress LSR or to a
   particular intermediate node.  The mechanism defined in
   [I-D.ietf-ccamp-lsp-attribute-ro] is used for addressing the loopback
   request to a particular node on the LSP.  The loopback request is
   acceptable only when the LSP is in lock mode.

   When a ingress LSR intends to put a particular LSR on the LSP into
   loopback mode, it MUST send a Path message with the Loopback bit in
   the Attribute Flags TLV set.  The mechanism defined in
   [I-D.ietf-ccamp-lsp-attribute-ro] is used to address the loopback
   request to the particular LSR.  The Administratively down (A) bit in
   ADMIN_STATUS object SHOULD be set to keep the LSP in lock mode.

   On receipt of this Path message, the target LSR of the loopback
   request SHOULD try to put the LSP into loopback mode.  If the node
   puts the LSP into loopback mode successfully, it SHOULD set the



Dong, et al.            Expires October 24, 2014                [Page 4]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


   Loopback (B) bit in the Record Route Object (RRO) Attribute subobject
   [RFC5420] and push this subobject onto the RRO object in the
   corresponding Resv message.  The Administratively down (A) bit in
   ADMIN_STATUS object SHOULD also be set in the Resv message.  If the
   node cannot put the LSP into loopback mode, it SHOULD send a PathErr
   message with the Error Code "OAM Problem"
   [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value
   "Loopback Failure".

   When the ingress LSR intends to take the LSP out of loopback mode, it
   MUST send a Path message with the Loopback (B) bit in the Attribute
   Flags TLV cleared.  The mechanism defined in
   [I-D.ietf-ccamp-lsp-attribute-ro] is used to indicate that the
   particular LSR SHOULD exit loopback mode for this LSP.  The
   Administratively down (A) bit in ADMIN_STATUS object SHOULD be set.

   On receipt of this Path message, the target LSR SHOULD try to take
   the LSP out of loopback mode.  If the node takes the LSP out of
   loopback mode successfully, it SHOULD clear the Loopback (B) Bit in
   the RRO Attribute subobject and push this subobject onto the RRO
   object in the corresponding Resv message.  The Administratively down
   (A) Bit in ADMIN_STATUS Object SHOULD be set.  Otherwise, the node
   SHOULD send a PathErr message with the Error Code "OAM Problem"
   [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value "Exit
   Loopback Failure".

4.  IANA Considerations

   One bit number "Loopback" needs to be assigned in the Attribute Flags
   registry.

   Four new Error Values need to be allocated for "OAM Problem" Error
   Code:

     Value      Error
     TBA        Lock Failure
     TBA        Unlock Failure
     TBA        Loopback Failure
     TBA        Exit Loopback Failure

5.  Security Considerations

   This document does not introduce any new security issues above those
   identified in [RFC3209] and [RFC3473].







Dong, et al.            Expires October 24, 2014                [Page 5]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


6.  Acknowledgements

   The authors would like to thank Greg Mirsky, Lou Berger and Francesco
   Fondelli for their comments and suggestions.

7.  References

7.1.  Normative References

   [I-D.ietf-ccamp-lsp-attribute-ro]
              Margaria, C., Martinelli, G., Balls, S., and B. Wright,
              "LSP Attribute in ERO", draft-ietf-ccamp-lsp-attribute-
              ro-03 (work in progress), February 2014.

   [I-D.ietf-ccamp-oam-configuration-fwk]
              Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE
              extensions for OAM Configuration", draft-ietf-ccamp-oam-
              configuration-fwk-13 (work in progress), February 2014.

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

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

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

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, February 2009.

   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
              Operations, Administration, and Maintenance (OAM) in MPLS
              Transport Networks", RFC 5860, May 2010.






Dong, et al.            Expires October 24, 2014                [Page 6]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
              Maintenance Framework for MPLS-Based Transport Networks",
              RFC 6371, September 2011.

7.2.  Informative References

   [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
              Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D.,
              and A. Takacs, "Configuration of Pro-Active Operations,
              Administration, and Maintenance (OAM) Functions for MPLS-
              based Transport Networks using RSVP-TE", draft-ietf-ccamp-
              rsvp-te-mpls-tp-oam-ext-12 (work in progress), June 2013.

   [RFC6435]  Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
              and X. Dai, "MPLS Transport Profile Lock Instruct and
              Loopback Functions", RFC 6435, November 2011.

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   Mach(Guoyi) Chen
   Huawei Technologies
   Huawei Campus, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: mach.chen@huawei.com


   Zhenqiang Li
   China Mobile
   Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave.
   Beijing  100053
   China

   Email: lizhenqiang@chinamobile.com







Dong, et al.            Expires October 24, 2014                [Page 7]


Internet-Draft        RSVP-TE Extensions for LI&LB            April 2014


   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com












































Dong, et al.            Expires October 24, 2014                [Page 8]