summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6510.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6510.txt')
-rw-r--r--doc/rfc/rfc6510.txt451
1 files changed, 451 insertions, 0 deletions
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.
+
+ <Path Message> ::= <Common Header> [ <INTEGRITY> ]
+ [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
+ [ <MESSAGE_ID> ]
+ <SESSION> <RSVP_HOP>
+
+
+
+Berger & Swallow Standards Track [Page 3]
+
+RFC 6510 RSVP Message Formats for LSP Attributes February 2012
+
+
+ <TIME_VALUES>
+ [ <EXPLICIT_ROUTE> ]
+ <LABEL_REQUEST>
+ [ <PROTECTION> ]
+ [ <LABEL_SET> ... ]
+ [ <SESSION_ATTRIBUTE> ]
+ [ <LSP_REQUIRED_ATTRIBUTES> ... ]
+ [ <LSP_ATTRIBUTES> ... ]
+ [ <NOTIFY_REQUEST> ]
+ [ <ADMIN_STATUS> ]
+ [ <POLICY_DATA> ... ]
+ <sender descriptor>
+ [<S2L sub-LSP descriptor list>]
+
+ 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].
+
+ <FF flow descriptor list> ::= <FF flow descriptor>
+ [ <FF flow descriptor list> ]
+
+ <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
+ [ <LSP_ATTRIBUTES> ... ]
+ [ <RECORD_ROUTE> ]
+ [ <S2L sub-LSP flow descriptor list> ]
+
+ <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
+
+ <SE filter spec list> ::= <SE filter spec>
+ [ <SE filter spec list> ]
+
+
+
+
+
+
+Berger & Swallow Standards Track [Page 5]
+
+RFC 6510 RSVP Message Formats for LSP Attributes February 2012
+
+
+ <SE filter spec> ::= <FILTER_SPEC> <LABEL>
+ [ <LSP_ATTRIBUTES> ... ]
+ [ <RECORD_ROUTE> ]
+ [ <S2L sub-LSP flow descriptor list> ]
+
+3.2. Resv Message Format -- Per S2L Operational Status
+
+ This section presents the Resv message format for LSPs as modified by
+ this document and [RFC5420], and can be used to report operational
+ status per S2L sub-LSP. Unmodified formats are not listed. The
+ following is based on [RFC4875].
+
+ <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
+ [ <RECORD_ROUTE> ]
+ [ <S2L sub-LSP flow descriptor list> ]
+
+ <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
+ [ <S2L sub-LSP flow descriptor list> ]
+
+ <S2L sub-LSP flow descriptor list> ::=
+ <S2L sub-LSP flow descriptor>
+ [ <S2L sub-LSP flow descriptor list> ]
+
+ <S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
+ [ <LSP_ATTRIBUTES> ... ]
+ [ <P2MP_SECONDARY_RECORD_ROUTE> ]
+
+3.2.1. Compatibility
+
+ A node that supports [RFC4875] and [RFC5420], but not this document,
+ will interpret the first LSP Attributes object present in a received
+ message, which is formatted as described in this document, as
+ representing LSP operational status rather than S2L sub-LSP status.
+ It is unclear if this is a significant issue as the LSP Attributes
+ object is currently considered to be an unsuitable mechanism for
+ reporting operational status of P2MP LSPs, for example, see Section
+ 2.1 of [RFC6511]. The intent of this document is to correct this
+ limitation; it is expected that networks that wish to make use of
+ such operational reporting will deploy this extension.
+
+4. Security Considerations
+
+ This document clarifies usage of objects defined in [RFC5420]. No
+ new information is conveyed; therefore, no additional security
+ considerations are included here. For a general discussion on MPLS-
+ and GMPLS-related security issues, see the MPLS/GMPLS security
+ framework [RFC5920].
+
+
+
+
+Berger & Swallow Standards Track [Page 6]
+
+RFC 6510 RSVP Message Formats for LSP Attributes February 2012
+
+
+5. Acknowledgments
+
+ The authors would like to acknowledge the contributions of Adrian
+ Farrel.
+
+6. References
+
+6.1. Normative References
+
+ [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.
+
+ [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation Protocol-
+ Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+ January 2003.
+
+ [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+ Yasukawa, Ed., "Extensions to Resource Reservation
+ Protocol - Traffic Engineering (RSVP-TE) for Point-to-
+ Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
+ 2007.
+
+ [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, February 2009.
+
+ [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+ Used to Form Encoding Rules in Various Routing Protocol
+ Specifications", RFC 5511, April 2009.
+
+6.2. Informative References
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, July 2010.
+
+ [RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
+ Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
+ Label Switched Paths", RFC 6511, February 2012.
+
+
+
+
+
+
+
+Berger & Swallow Standards Track [Page 7]
+
+RFC 6510 RSVP Message Formats for LSP Attributes February 2012
+
+
+Authors' Addresses
+
+ Lou Berger
+ LabN Consulting, L.L.C.
+ Phone: +1-301-468-9228
+ EMail: lberger@labn.net
+
+ George Swallow
+ Cisco Systems, Inc.
+ EMail: swallow@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Swallow Standards Track [Page 8]
+