GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7571

Internet Engineering Task Force (IETF) J. Dong Request for Comments: 7571 M. Chen Category: Standards Track Huawei Technologies ISSN: 2070-1721 Z. Li

                                                          China Mobile
                                                         D. Ceccarelli
                                                              Ericsson
                                                             July 2015
      GMPLS RSVP-TE Extensions for Lock Instruct and Loopback

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 that use Generalized MPLS
 (GMPLS) for the control plane.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7571.

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.

Dong, et al. Standards Track [Page 1] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
 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 . . . . . . . . . . . . . . . . . . . . .   6
   4.1.  Attribute Flags . . . . . . . . . . . . . . . . . . . . .   6
   4.2.  RSVP Error Value Sub-Codes  . . . . . . . . . . . . . . .   6
   4.3.  Allocation Rule for ERO Subobjects  . . . . . . . . . . .   6
 5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
 6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
   6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

 The requirements for Lock Instruct (LI) and Loopback (LB) in the
 Multiprotocol Label Switching Transport Profile (MPLS-TP) are
 specified in [RFC5860], and the framework of LI and LB is specified
 in [RFC6371].  A Label Switched Path (LSP) that is locked, using LI,
 is prevented from carrying user data traffic.  The LB function can
 only be applied to an LSP that has been previously locked.
 In general, the LI and LB are useful Operations, Administration, and
 Maintenance (OAM) functions for technologies that use Generalized
 MPLS (GMPLS) for the 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.
 [RFC7487] specifies the RSVP-TE extensions for the configuration of
 proactive 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 LSPs.  The mechanisms are applicable to technologies

Dong, et al. Standards Track [Page 2] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

 that use GMPLS for the control plane.  For a network supporting MPLS-
 TP, the mechanisms defined in this document are complementary to
 [RFC6435].

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

2. Flag Definitions for LI and LB

2.1. Lock Instruct Indication

 In order to indicate the lock/unlock status of the LSP, the A
 (Administratively down) bit in the Administrative Status
 (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.
  1. Bit number: 13
  1. Attribute flag carried in Path message: Yes
  1. Attribute flag carried in Resv message: No
  1. Attribute flag carried in the Record Route Object (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 used as
 specified above and the Reflect (R) bit in the ADMIN_STATUS Object
 set.

Dong, et al. Standards Track [Page 3] RFC 7571 RSVP-TE Extensions for LI & LB July 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 the
 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 the 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 the 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 the
 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 the 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 [RFC7570] 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 an 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 [RFC7570] is used to address the loopback
 request to the particular node.  The ingress node MUST ensure that
 the entity at which loopback is intended to occur is explicitly
 identified by the immediately preceding subobject of the Explicit
 Route Object (ERO) Hop Attributes subobject.  The Administratively
 down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate
 that the LSP is still in lock mode.

Dong, et al. Standards Track [Page 4] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

 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
 is set, the node MUST check that the desired loopback entity is
 explicitly identified by the ERO subobject prior to the ERO Hop
 Attributes subobject.  Currently, the type value MUST be verified to
 be less than 32 (i.e., able to identify a specific entity where a
 loopback can occur; see Section 4.3), and for type values 1 (IPv4
 prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128,
 respectively.  If the desired loopback entity is not explicitly
 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.  The loopback SHOULD be enabled on
 the entity identified by the ERO subobject immediately prior to the
 ERO Hop Attributes subobject.  If the immediately preceding subobject
 is a label subobject [RFC3473], the loopback SHOULD be enabled for
 the direction indicated by the U bit of the label subobject.
 If the node puts the LSP into loopback mode successfully, it MUST set
 the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop
 Attributes subobject to the RRO of a Path or Resv message.  The
 Administratively down (A) bit in the 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 [RFC7570] is used to indicate that the particular node
 SHOULD exit loopback mode for this LSP.  The Administratively down
 (A) bit in the 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 Hop Attributes subobject and push this subobject onto the
 RRO object in the corresponding Path or Resv message.  The
 Administratively down (A) bit in the 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

Dong, et al. Standards Track [Page 5] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

 still in loopback mode.  The egress node MUST ignore such a request
 when the LSP is still in loopback mode.

4. IANA Considerations

 IANA has assigned new values defined in this document and summarized
 in this section.

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 has assigned a new bit flag as follows:
  Bit |           | Attribute  | Attribute  |     |     |
  No. | Name      | Flags Path | Flags Resv | RRO | ERO |  Reference
 -----+-----------+------------+------------+-----+-----+-------------
   13 | 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 has assigned four new Error Value sub-codes for the "OAM
 Problem" Error Code:
    Value   |  Description                | Reference
 -----------+-----------------------------+--------------
      26    |  Lock Failure               | this document
      27    |  Unlock Failure             | this document
      28    |  Loopback Failure           | this document
      29    |  Exit Loopback Failure      | this document

4.3. Allocation Rule for ERO Subobjects

 IANA maintains a registry called "Resource Reservation Protocol
 (RSVP) Parameters" with a sub-registry called "Class Names, Class
 Numbers, and Class Types".
 For Explicit Route Object, the allocation rule for subobject types in
 the range 5-31 (0x05 - 0x1F) has been updated as:
 5-31     Unassigned    (For explicit resource identification)

Dong, et al. Standards Track [Page 6] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

5. Security Considerations

 This document does not introduce any new security issues beyond those
 identified in [RFC3209], [RFC3473], and [RFC7570].  For a more
 comprehensive discussion of GMPLS security and attack mitigation
 techniques, please see "Security Framework for MPLS and GMPLS
 Networks" [RFC5920].
 In addition, the reporting of the loopback status using the RRO may
 reveal details about the node that the operator wishes to remain
 confidential.  The privacy considerations as described in paragraph 3
 of Section 5 of [RFC7570] also apply to this document.

6. References

6.1. 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>.
 [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
            <http://www.rfc-editor.org/info/rfc3209>.
 [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Functional Description", RFC
            3471, DOI 10.17487/RFC3471, January 2003,
            <http://www.rfc-editor.org/info/rfc3471>.
 [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Resource ReserVation Protocol-
            Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
            DOI 10.17487/RFC3473, January 2003,
            <http://www.rfc-editor.org/info/rfc3473>.
 [RFC5420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
            Ayyangarps, "Encoding of Attributes for MPLS LSP
            Establishment Using Resource Reservation Protocol Traffic
            Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
            February 2009, <http://www.rfc-editor.org/info/rfc5420>.

Dong, et al. Standards Track [Page 7] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

 [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
            "Requirements for Operations, Administration, and
            Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
            DOI 10.17487/RFC5860, May 2010,
            <http://www.rfc-editor.org/info/rfc5860>.
 [RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
            Extensions for Operations, Administration, and Maintenance
            (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
            2014, <http://www.rfc-editor.org/info/rfc7260>.
 [RFC7570]  Margaria, C., Ed., Martinelli, G., Balls, S., and B.
            Wright, "Label Switched Path (LSP) Attribute in the
            Explicit Route Object (ERO)", RFC 7570,
            DOI 10.17487/RFC7570, July 2015,
            <http://www.rfc-editor.org/info/rfc7570>.

6.2. Informative References

 [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
            Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
            <http://www.rfc-editor.org/info/rfc5920>.
 [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
            Administration, and Maintenance Framework for MPLS-Based
            Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
            September 2011, <http://www.rfc-editor.org/info/rfc6371>.
 [RFC6435]  Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
            Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
            Profile Lock Instruct and Loopback Functions", RFC 6435,
            DOI 10.17487/RFC6435, November 2011,
            <http://www.rfc-editor.org/info/rfc6435>.
 [RFC7487]  Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
            Skoldstrom, P., and D. Ward, "Configuration of Proactive
            Operations, Administration, and Maintenance (OAM)
            Functions for MPLS-Based Transport Networks Using RSVP-
            TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
            <http://www.rfc-editor.org/info/rfc7487>.

Dong, et al. Standards Track [Page 8] RFC 7571 RSVP-TE Extensions for LI & LB July 2015

Acknowledgments

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

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. Standards Track [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7571.txt · Last modified: 2015/07/09 22:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki