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/rfc6387.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc6387.txt (limited to 'doc/rfc/rfc6387.txt') diff --git a/doc/rfc/rfc6387.txt b/doc/rfc/rfc6387.txt new file mode 100644 index 0000000..54fe803 --- /dev/null +++ b/doc/rfc/rfc6387.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Takacs +Request for Comments: 6387 Ericsson +Obsoletes: 5467 L. Berger +Category: Standards Track LabN Consulting, L.L.C. +ISSN: 2070-1721 D. Caviglia + Ericsson + D. Fedyk + Alcatel-Lucent + J. Meuric + France Telecom Orange + September 2011 + + + GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) + +Abstract + + This document defines a method for the support of GMPLS asymmetric + bandwidth bidirectional Label Switched Paths (LSPs). The approach + presented is applicable to any switching technology and builds on the + original Resource Reservation Protocol (RSVP) model for the transport + of traffic-related parameters. This document moves the experiment + documented in RFC 5467 to the standards track and obsoletes RFC 5467. + +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/rfc6387. + + + + + + + + + + + + + + +Takacs, et. al. Standards Track [Page 1] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + +Copyright Notice + + Copyright (c) 2011 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 + 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Approach Overview . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Conventions Used in This Document . . . . . . . . . . . . 4 + 2. Generalized Asymmetric Bandwidth Bidirectional LSPs . . . . . 4 + 2.1. UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . . 5 + 2.1.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. UPSTREAM_TSPEC Object . . . . . . . . . . . . . . . . . . 5 + 2.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . . 6 + 2.3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 5.1. UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . . 8 + 5.2. UPSTREAM_TSPEC Object . . . . . . . . . . . . . . . . . . 8 + 5.3. UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 + +1. Introduction + + GMPLS [RFC3473] introduced explicit support for bidirectional Label + Switched Paths (LSPs). The defined support matched the switching + technologies covered by GMPLS, notably Time Division Multiplexing + (TDM) and lambdas; specifically, it only supported bidirectional LSPs + with symmetric bandwidth allocation. Symmetric bandwidth + requirements are conveyed using the semantics objects defined in + [RFC2205] and [RFC2210]. + + + +Takacs, et. al. Standards Track [Page 2] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + GMPLS asymmetric bandwidth bidirectional LSPs are bidirectional LSPs + that have different bandwidth reservations in each direction. + Support for bidirectional LSPs with asymmetric bandwidth was + previously discussed in the context of Ethernet, notably [RFC6060] + and [RFC6003]. In that context, asymmetric bandwidth support was + considered to be a capability that was unlikely to be deployed, and + hence [RFC5467] was published as Experimental. The MPLS Transport + Profile, MPLS-TP, requires that asymmetric bandwidth bidirectional + LSPs be supported (see [RFC5654]); therefore, this document is being + published on the Standards Track. This document has no technical + changes from the approach defined in [RFC5467]. This document moves + the experiment documented in [RFC5467] to the standards track and + obsoletes [RFC5467]. This document also removes the Ethernet- + technology-specific alternative approach discussed in the appendix of + [RFC5467] and maintains only one approach that is suitable for use + with any technology. + +1.1. Background + + Bandwidth parameters are transported within RSVP ([RFC2210], + [RFC3209], and [RFC3473]) via several objects that are opaque to + RSVP. While opaque to RSVP, these objects support a particular model + for the communication of bandwidth information between an RSVP + session sender (ingress) and receiver (egress). The original model + of communication, defined in [RFC2205] and maintained in [RFC3209], + used the SENDER_TSPEC and ADSPEC objects in Path messages and the + FLOWSPEC object in Resv messages. The SENDER_TSPEC object was used + to indicate a sender's data generation capabilities. The FLOWSPEC + object was issued by the receiver and indicated the resources that + should be allocated to the associated data traffic. The ADSPEC + object was used to inform the receiver and intermediate hops of the + actual resources available for the associated data traffic. + + With the introduction of bidirectional LSPs in [RFC3473], the model + of communication of bandwidth parameters was implicitly changed. In + the context of [RFC3473] bidirectional LSPs, the SENDER_TSPEC object + indicates the desired resources for both upstream and downstream + directions. The FLOWSPEC object is simply confirmation of the + allocated resources. The definition of the ADSPEC object is either + unmodified and only has meaning for downstream traffic, or is + implicitly or explicitly ([RFC4606] and [RFC6003]) irrelevant. + +1.2. Approach Overview + + The approach for supporting asymmetric bandwidth bidirectional LSPs + defined in this document builds on the original RSVP model for the + transport of traffic-related parameters and GMPLS's support for + bidirectional LSPs. + + + +Takacs, et. al. Standards Track [Page 3] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + The defined approach is generic and can be applied to any switching + technology supported by GMPLS. With this approach, the existing + SENDER_TSPEC, ADSPEC, and FLOWSPEC objects are complemented with the + addition of new UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and + UPSTREAM_FLOWSPEC objects. The existing objects are used in the + original fashion defined in [RFC2205] and [RFC2210], and refer only + to traffic associated with the LSP flowing in the downstream + direction. The new objects are used in exactly the same fashion as + the old objects, but refer to the upstream traffic flow Figure 1 + shows the bandwidth-related objects used for asymmetric bandwidth + bidirectional LSPs. + + |---| Path |---| + | I |------------------->| E | + | n | -SENDER_TSPEC | g | + | g | -ADSPEC | r | + | r | -UPSTREAM_FLOWSPEC | e | + | e | | s | + | s | Resv | s | + | s |<-------------------| | + | | -FLOWSPEC | | + | | -UPSTREAM_TSPEC | | + | | -UPSTREAM_ADSPEC | | + |---| |---| + + Figure 1: Generic Asymmetric Bandwidth Bidirectional LSPs + + The extensions defined in this document are limited to Point-to-Point + (P2P) LSPs. Support for Point-to-Multipoint (P2MP) bidirectional + LSPs is not currently defined and, as such, not covered in this + document. + +1.3. 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. Generalized Asymmetric Bandwidth Bidirectional LSPs + + The setup of an asymmetric bandwidth bidirectional LSP is signaled + using the bidirectional procedures defined in [RFC3473] together with + the inclusion of the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC, and + UPSTREAM_ADSPEC objects. + + The new upstream objects carry the same information and are used in + the same fashion as the existing downstream objects; they differ in + that they relate to traffic flowing in the upstream direction while + + + +Takacs, et. al. Standards Track [Page 4] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + the existing objects relate to traffic flowing in the downstream + direction. The new objects also differ in that they are carried in + messages traveling in the opposite direction. + +2.1. UPSTREAM_FLOWSPEC Object + + The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC + object [RFC2210]. This includes the definition of class types and + their formats. The class number of the UPSTREAM_FLOWSPEC object is + 120 (of the form 0bbbbbbb). + +2.1.1. Procedures + + The Path message of an asymmetric bandwidth bidirectional LSP MUST + contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional + LSP formats and procedures defined in [RFC3473]. The C-Type of the + UPSTREAM_FLOWSPEC object MUST match the C-Type of the SENDER_TSPEC + object used in the Path message. The contents of the + UPSTREAM_FLOWSPEC object MUST be constructed using a format and + procedures consistent with those used to construct the FLOWSPEC + object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]. + + Nodes processing a Path message containing an UPSTREAM_FLOWSPEC + object MUST use the contents of the UPSTREAM_FLOWSPEC object in the + upstream label and the resource allocation procedure defined in + Section 3.1 of [RFC3473]. Consistent with [RFC3473], a node that is + unable to allocate a label or internal resources based on the + contents of the UPSTREAM_FLOWSPEC object MUST issue a PathErr message + with a "Routing problem/MPLS label allocation failure" indication. + +2.2. UPSTREAM_TSPEC Object + + The format of an UPSTREAM_TSPEC object is the same as a SENDER_TSPEC + object, which includes the definition of class types and their + formats. The class number of the UPSTREAM_TSPEC object is 121 (of + the form 0bbbbbbb). + +2.2.1. Procedures + + The UPSTREAM_TSPEC object describes the traffic flow that originates + at the egress. The UPSTREAM_TSPEC object MUST be included in any + Resv message that corresponds to a Path message containing an + UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object + MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object. + The contents of the UPSTREAM_TSPEC object MUST be constructed using a + format and procedures consistent with those used to construct the + FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or + [RFC4328]. The contents of the UPSTREAM_TSPEC object MAY differ from + + + +Takacs, et. al. Standards Track [Page 5] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + contents of the UPSTREAM_FLOWSPEC object based on application data + transmission requirements. + + When an UPSTREAM_TSPEC object is received by an ingress, the ingress + MAY determine that the original reservation is insufficient to + satisfy the traffic flow. In this case, the ingress MAY tear down + the LSP and send a PathTear message. Alternatively, the ingress MAY + issue a Path message with an updated UPSTREAM_FLOWSPEC object to + modify the resources requested for the upstream traffic flow. This + modification might require the LSP to be re-routed, and in extreme + cases might result in the LSP being torn down when sufficient + resources are not available along the path of the LSP. + +2.3. UPSTREAM_ADSPEC Object + + The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC + object. This includes the definition of class types and their + formats. The class number of the UPSTREAM_ADSPEC object is 122 (of + the form 0bbbbbbb). + +2.3.1. Procedures + + The UPSTREAM_ADSPEC object MAY be included in any Resv message that + corresponds to a Path message containing an UPSTREAM_FLOWSPEC object. + The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the + C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents + of the UPSTREAM_ADSPEC object MUST be constructed using a format and + procedures consistent with those used to construct the ADSPEC object + that will be used for the LSP, e.g., [RFC2210] or [RFC6003]. The + UPSTREAM_ADSPEC object is processed using the same procedures as the + ADSPEC object and, as such, MAY be updated or added at transit nodes. + +3. Packet Formats + + This section presents the RSVP message-related formats as modified by + this section. This document modifies formats defined in [RFC2205], + [RFC3209], and [RFC3473]. See [RFC5511] for the syntax used by RSVP. + Unmodified formats are not listed. Three new objects are defined in + this section: + + Object name Applicable RSVP messages + --------------- ------------------------ + UPSTREAM_FLOWSPEC Path, PathTear, PathErr, and Notify + (via sender descriptor) + UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr, and + Notify (via flow descriptor list) + UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr, and + Notify (via flow descriptor list) + + + +Takacs, et. al. Standards Track [Page 6] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + The format of the sender description for bidirectional asymmetric + LSPs is: + + ::= + [ ] + [ ] + [ ] + [ ] + + + + The format of the flow descriptor list for bidirectional asymmetric + LSPs is: + + ::= + | + + ::= + [ ] + +