From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7571.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc7571.txt (limited to 'doc/rfc/rfc7571.txt') diff --git a/doc/rfc/rfc7571.txt b/doc/rfc/rfc7571.txt new file mode 100644 index 0000000..d384d77 --- /dev/null +++ b/doc/rfc/rfc7571.txt @@ -0,0 +1,507 @@ + + + + + + +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. + + - Bit number: 13 + + - Attribute flag carried in Path message: Yes + + - Attribute flag carried in Resv message: No + + - 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, + . + + [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, + . + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, DOI 10.17487/RFC3471, January 2003, + . + + [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, + . + + [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, . + + + + + + + + +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, + . + + [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, . + + [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, + . + +6.2. Informative References + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . + + [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, . + + [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, + . + + [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, + . + + + + + + + + + + + +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] + -- cgit v1.2.3