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

Network Working Group                                            J. Dong
Internet-Draft                                                   M. Chen
Intended status: Standards Track                     Huawei Technologies
Expires: July 27, 2015                                             Z. Li
                                                            China Mobile
                                                           D. Ceccarelli
                                                                Ericsson
                                                        January 23, 2015

        GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
                    draft-ietf-teas-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 July 27, 2015.

Dong, et al.              Expires July 27, 2015                 [Page 1]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

Copyright Notice

   Copyright (c) 2015 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.  Flag Definitions for LI and LB  . . . . . . . . . . . . . . .   3
     2.1.  Lock Instruct Indication  . . . . . . . . . . . . . . . .   3
     2.2.  Extensions for Loopback . . . . . . . . . . . . . . . . .   3
   3.  Operational Procedures  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Lock Instruct . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Loopback  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Attribute Flags . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  RSVP Error Value Sub-codes  . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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.

Dong, et al.              Expires July 27, 2015                 [Page 2]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

   [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE
   extensions for the configuration of pro-active MPLS-TP OAM functions,
   such as Continuity Check (CC), Connectivity Verification (CV), Delay
   Measurement (DM) and Loss Measurement (LM).  The provisioning of on-
   demand OAM functions such as LI and LB are not covered in that
   document.

   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
   applicable to technologies which use GMPLS as control plane.  For
   MPLS-TP network, the mechanisms defined in this document are
   complementary to [RFC6435].

2.  Flag Definitions for LI and LB

2.1.  Lock Instruct Indication

   In order to indicate the lock/unlock of the LSP, the A
   (Administratively down) bit in ADMIN_STATUS object [RFC3471]
   [RFC3473] is used.

2.2.  Extensions for Loopback

   In order to indicate the loopback mode of LSP, a new bit flag is
   defined in the Attribute Flags TLV [RFC5420].

   Loopback flag:

      This flag indicates a particular node on the LSP is required to
      enter loopback mode.  This can also be used for specifying the
      loopback state of the node.

      - Bit number: TBA

      - Attribute flag carried in Path message: Yes

      - Attribute flag carried in Resv message: No

      - Attribute flag carried in RRO Attributes subobject: Yes

3.  Operational Procedures

3.1.  Lock Instruct

   When an ingress node intends to put an LSP into lock mode, it MUST
   send a Path message with the Administratively down (A) bit defined
   above and the Reflect (R) bit in ADMIN_STATUS Object set.

Dong, et al.              Expires July 27, 2015                 [Page 3]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

   On receipt of this Path message, the egress node SHOULD try to take
   the LSP out of service.  If the egress node locks the LSP
   successfully, it MUST send a Resv message with the A bit in
   ADMIN_STATUS object set.  Otherwise, it MUST send a PathErr message
   with the Error Code "OAM Problem" [RFC7260] and the new Error Value
   "Lock Failure", and the following Resv messages MUST be sent with the
   A bit cleared.

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

   When the ingress node 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.

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

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

3.2.  Loopback

   The loopback request can be sent either to the egress node or to a
   particular intermediate node.  The mechanism defined in
   [I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback
   request to a particular node on the LSP.  The ingress node MUST
   ensure that the LSP is in lock mode before it requests setting a
   particular node on the LSP into loopback mode.

   When a ingress node intends to put a particular node on the LSP into
   loopback mode, it MUST send a Path message with the Loopback
   Attribute Flag defined above in the Attribute Flags TLV set.  The
   mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to
   address the loopback request to the particular node.  The ingress
   MUST ensure that the desired loopback mode is strictly identified in
   the ERO.  The Administratively down (A) bit in ADMIN_STATUS object
   MUST be kept set to indicate that the LSP is still in lock mode.

   On receipt of this Path message, the target node of the loopback
   request MUST check if the LSP is in lock mode by verifying that the
   Administratively down (A) bit is set in the ADMIN_STATUS object.  If
   the bit is not set, the loopback request MUST be ignored.  If the bit

Dong, et al.              Expires July 27, 2015                 [Page 4]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

   is set, the node MUST check that the desired loopback is strictly
   identified by verifying that the L bit is set to 0 in both the ERO
   Hop Attributes subobject and the prior subobject.  The prior
   subobject MUST also be checked to ensure that it provides strict
   identification.  Currently, the type value MUST be verified to be
   less than 32, and for type values 1 and 2 the prefix length MUST be
   32 and 128 respectively.  If the desired loopback is not strictly
   identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE
   object" error SHOULD be generated.  Otherwise, the node SHOULD try to
   put the LSP into loopback mode.  If the node puts the LSP into
   loopback mode successfully, it MUST set the Loopback Attribute Flag
   if it adds, per [RFC5420], an Attributes subobject to the
   RECORD_ROUTE Object (RRO) of a Path or Resv message.  The
   Administratively down (A) bit in ADMIN_STATUS object MUST be kept set
   in the message.  If the node cannot put the LSP into loopback mode,
   it MUST send a PathErr message with the Error Code "OAM Problem"
   [RFC7260] and the new Error Value "Loopback Failure".

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

   On receipt of this Path message, the target node SHOULD try to take
   the LSP out of loopback mode.  If the node takes the LSP out of
   loopback mode successfully, it MUST clear the Loopback Attribute Flag
   in the RRO Attributes subobject and push this subobject onto the RRO
   object in the corresponding Path or Resv message.  The
   Administratively down (A) Bit in ADMIN_STATUS Object MUST be kept set
   in the message.  Otherwise, the node MUST send a PathErr message with
   the Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit
   Loopback Failure".

   After the loopback mode is cleared successfully, the ingress node MAY
   remove the Lock Instruct using the mechanism defined in section 3.1.
   The ingress node MUST NOT request to exit lock mode if the LSP is
   still in loopback mode.  The egress node MUST ignore such request
   when the LSP is still in loopback mode.

4.  IANA Considerations

   IANA is requested to administer the assignment of new values defined
   in this document and summarized in this section.

Dong, et al.              Expires July 27, 2015                 [Page 5]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

4.1.  Attribute Flags

   IANA maintains a registry called "Resource Reservation Protocol-
   Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
   "Attribute Flags".

   IANA is requested to assign a new bit flag as follows:

  Bit |              | Attribute  | Attribute  |     |     |
  No. | Name         | Flags Path | Flags Resv | RRO | ERO |  Reference
  ----+--------------+------------+------------+-----+-----+-------------
  TBA | Loopback     |   Yes      |   No       | Yes | Yes |this document

4.2.  RSVP Error Value Sub-codes

   IANA maintains a registry called "Resource Reservation Protocol
   (RSVP) Parameters" with a sub-registry called "Error Codes and
   Globally-Defined Error Value Sub-Codes".

   IANA is requested to assign four new Error Value sub-codes for the
   "OAM Problem" Error Code:

      Value   |  Description                | Reference
   -----------+-----------------------------+--------------
       TBA    |  Lock Failure               | this document
       TBA    |  Unlock Failure             | this document
       TBA    |  Loopback Failure           | this document
       TBA    |  Exit Loopback Failure      | this document

5.  Security Considerations

   This document does not introduce any new security issues above those
   identified in [RFC3209] [RFC3473] and
   [I-D.ietf-teas-lsp-attribute-ro].  For a more comprehensive
   discussion of GMPLS security and attack mitigation techniques, please
   see the Security Framework for MPLS and GMPLS Networks [RFC5920].

6.  Acknowledgements

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

7.  References

Dong, et al.              Expires July 27, 2015                 [Page 6]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

7.1.  Normative References

   [I-D.ietf-teas-lsp-attribute-ro]
              Margaria, C., Martinelli, G., Balls, S., and B. Wright,
              "LSP Attribute in ERO", draft-ietf-teas-lsp-attribute-
              ro-01 (work in progress), December 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.

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

   [RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
              Extensions for Operations, Administration, and Maintenance
              (OAM) Configuration", RFC 7260, June 2014.

7.2.  Informative References

   [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
              Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
              Skoldstrom, P., and D. Ward, "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-15 (work in
              progress), January 2015.

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

Dong, et al.              Expires July 27, 2015                 [Page 7]
Internet-Draft        RSVP-TE Extensions for LI&LB          January 2015

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

   [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

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

   Email: daniele.ceccarelli@ericsson.com

Dong, et al.              Expires July 27, 2015                 [Page 8]