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/rfc6510.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6510.txt (limited to 'doc/rfc/rfc6510.txt') diff --git a/doc/rfc/rfc6510.txt b/doc/rfc/rfc6510.txt new file mode 100644 index 0000000..6d17648 --- /dev/null +++ b/doc/rfc/rfc6510.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Berger +Request for Comments: 6510 LabN +Updates: 4875, 5420 G. Swallow +Category: Standards Track Cisco +ISSN: 2070-1721 February 2012 + + + Resource Reservation Protocol (RSVP) Message Formats for + Label Switched Path (LSP) Attributes Objects + +Abstract + + Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) + established using the Resource Reservation Protocol Traffic + Engineering (RSVP-TE) extensions may be signaled with a set of LSP- + specific attributes. These attributes may be carried in both Path + and Resv messages. This document specifies how LSP attributes are to + be carried in RSVP Path and Resv messages using the Routing Backus- + Naur Form and clarifies related Resv message formats. This document + updates RFC 4875 and RFC 5420. + +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/rfc6510. + +Copyright Notice + + Copyright (c) 2012 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 + + + + + +Berger & Swallow Standards Track [Page 1] + +RFC 6510 RSVP Message Formats for LSP Attributes February 2012 + + + 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 + 1.1. Conventions Used in This Document ..........................3 + 2. Path Messages ...................................................3 + 2.1. Path Message Format ........................................3 + 3. Resv Messages ...................................................4 + 3.1. Resv Message Format -- Per LSP Operational Status ..........5 + 3.2. Resv Message Format -- Per S2L Operational Status ..........6 + 3.2.1. Compatibility .......................................6 + 4. Security Considerations .........................................6 + 5. Acknowledgments .................................................7 + 6. References ......................................................7 + 6.1. Normative References .......................................7 + 6.2. Informative References .....................................7 + +1. Introduction + + Signaling in support of Multiprotocol Label Switching (MPLS) and + Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) + is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling + support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs. + + Two LSP Attributes objects are defined in [RFC5420]. These objects + may be used to provide additional information related to how an LSP + should be set up when carried in a Path message and, when carried in + a Resv message, how an LSP has been established. The definition of + the objects includes a narrative description of related message + formats (see Section 9 of [RFC5420]). This definition does not + provide the related Routing Backus-Naur Form (BNF) [RFC5511] that is + typically used to define how messages are to be constructed using + RSVP objects. The current message format description has led to the + open question of how the LSP Attributes objects are to be processed + in Resv messages of P2MP LSPs (which are defined in [RFC4875]). + + This document provides the BNF for Path and Resv messages carrying + the LSP Attributes object. The definition clarifies how the objects + are to be carried for all LSP types. Both Path and Resv message BNF + is provided for completeness. + + + + + + + + +Berger & Swallow Standards Track [Page 2] + +RFC 6510 RSVP Message Formats for LSP Attributes February 2012 + + + This document presents the related RSVP message formats as modified + by [RFC5420]. This document modifies formats defined in [RFC3209], + [RFC3473], and [RFC4875]. See [RFC5511] for the syntax used by RSVP. + Unmodified formats are not listed. An example of a case where the + modified formats are applicable is described in [RFC6511]. + +1.1. Conventions Used in This Document + + 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 [RFC2119]. + +2. Path Messages + + This section updates [RFC4875]. Path message formatting is + unmodified from the narrative description provided in Section 9 of + [RFC5420]: + + The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object + MAY be carried in a Path message.... + + The order of objects in RSVP-TE messages is recommended, but + implementations must be capable of receiving the objects in any + meaningful order. + + On a Path message, the LSP_ATTRIBUTES object and + LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed + immediately after the SESSION_ATTRIBUTE object if it is present, + or otherwise immediately after the LABEL_REQUEST object. + + If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES + object are present, the LSP_REQUIRED_ATTRIBUTES object is + RECOMMENDED to be placed first. + + LSRs MUST be prepared to receive these objects in any order in any + position within a Path message. Subsequent instances of these + objects within a Path message SHOULD be ignored and MUST be + forwarded unchanged. + +2.1. Path Message Format + + This section presents the Path message format as modified by + [RFC5420]. Unmodified formats are not listed. + + ::= [ ] + [ [ | ] ...] + [ ] + + + + +Berger & Swallow Standards Track [Page 3] + +RFC 6510 RSVP Message Formats for LSP Attributes February 2012 + + + + [ ] + + [ ] + [ ... ] + [ ] + [ ... ] + [ ... ] + [ ] + [ ] + [ ... ] + + [] + + Note that PathErr and PathTear messages are not impacted by the + introduction of the LSP Attributes objects. + +3. Resv Messages + + This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420] + contains the following text regarding Resv messages: + + The LSP_ATTRIBUTES object MAY be carried in a Resv message. + + The order of objects in RSVP-TE messages is recommended, but + implementations must be capable of receiving the objects in any + meaningful order. + + ... + + On a Resv message, the LSP_ATTRIBUTES object is placed in the flow + descriptor and is associated with the FILTER_SPEC object that + precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be + placed immediately after the LABEL object. + + LSRs MUST be prepared to receive this object in any order in any + position within a Resv message, subject to the previous note. + Only one instance of the LSP_ATTRIBUTES object is meaningful + within the context of a FILTER_SPEC object. Subsequent instances + of the object SHOULD be ignored and MUST be forwarded unchanged. + + This means that LSP attributes may be present per sender (LSP) and + allows for the LSP Attributes object to be modified using make- + before-break (see [RFC3209]). This definition is sufficient for + point-to-point ([RFC3209] and [RFC3473]) LSPs and the special case + where all point-to-multipoint source-to-leaf (S2L) sub-LSPs + ([RFC4875]) report the same operational status (as used in + [RFC5420]). However, this definition does not allow for different + + + +Berger & Swallow Standards Track [Page 4] + +RFC 6510 RSVP Message Formats for LSP Attributes February 2012 + + + egress Label Switching Routers (LSRs) to report different operational + statuses. In order to allow such reporting, this document adds the + following definition: + + An LSR that wishes to report the operational status of a (point- + to-multipoint) S2L sub-LSP may include the LSP Attributes object + in a Resv message or update the object that is already carried in + a Resv message. LSP Attributes objects representing S2L sub-LSP + status MUST follow a S2L_SUB_LSP object. Only the first instance + of the LSP Attributes object is meaningful within the context of a + S2L_SUB_LSP object. Subsequent instances of the object SHOULD be + ignored and MUST be forwarded unchanged. + + When an LSP Attributes object is present before the first + S2L_SUB_LSP object, the LSP Attributes object represents the + operational status of all S2L sub-LSPs identified in the message. + Subsequent instances of the object (e.g., in the filter spec or + the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be + forwarded unchanged. When a branch node is combining Resv state + from multiple receivers into a single Resv message and an LSP + Attributes object is present before the first S2L_SUB_LSP object + in a received Resv message, the received LSP Attributes object + SHOULD be moved to follow the first received S2L_SUB_LSP object + and then SHOULD be duplicated for, and placed after, each + subsequent S2L_SUB_LSP object. + +3.1. Resv Message Format -- Per LSP Operational Status + + This section presents the Resv message format for LSPs as modified by + [RFC5420] and can be used to report operational status per LSP. + Unmodified formats are not listed. The following is based on + [RFC4875]. + + ::= + [ ] + + ::= [ ]