diff options
Diffstat (limited to 'doc/rfc/rfc6387.txt')
| -rw-r--r-- | doc/rfc/rfc6387.txt | 619 |
1 files changed, 619 insertions, 0 deletions
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: + + <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> + [ <ADSPEC> ] + [ <RECORD_ROUTE> ] + [ <SUGGESTED_LABEL> ] + [ <RECOVERY_LABEL> ] + <UPSTREAM_LABEL> + <UPSTREAM_FLOWSPEC> + + The format of the flow descriptor list for bidirectional asymmetric + LSPs is: + + <flow descriptor list> ::= <FF flow descriptor list> + | <SE flow descriptor> + + <FF flow descriptor list> ::= <FLOWSPEC> + <UPSTREAM_TSPEC> [ <UPSTREAM_ADSPEC> ] + <FILTER_SPEC> + <LABEL> [ <RECORD_ROUTE> ] + | <FF flow descriptor list> + <FF flow descriptor> + + <FF flow descriptor> ::= [ <FLOWSPEC> ] + [ <UPSTREAM_TSPEC>] [ <UPSTREAM_ADSPEC> ] + <FILTER_SPEC> <LABEL> + [ <RECORD_ROUTE> ] + + <SE flow descriptor> ::= <FLOWSPEC> + <UPSTREAM_TSPEC> [ <UPSTREAM_ADSPEC> ] + <SE filter spec list> + + <SE filter spec list> is unmodified by this document. + +4. Compatibility + + This extension reuses and extends semantics and procedures defined in + [RFC2205], [RFC3209], and [RFC3473] to support bidirectional LSPs + with asymmetric bandwidth. Three new objects are defined to indicate + the use of asymmetric bandwidth. Each of these objects is defined + with class numbers in the form 0bbbbbbb. Per [RFC2205], nodes not + supporting this extension will not recognize the new class numbers + and will respond with an "Unknown Object Class" error. The error + message will propagate to the ingress, which can then take action to + avoid the path with the incompatible node or can simply terminate the + session. + + + + +Takacs, et. al. Standards Track [Page 7] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + +5. IANA Considerations + + The IANA has made the assignments described below in the "Class + Names, Class Numbers, and Class Types" section of the "RSVP + PARAMETERS" registry. + +5.1. UPSTREAM_FLOWSPEC Object + + The class named UPSTREAM_FLOWSPEC has been assigned in the 0bbbbbbb + range (120) with the following definition: + + Class Types or C-types: + + Same values as FLOWSPEC object (C-Num 9) + +5.2. UPSTREAM_TSPEC Object + + The class named UPSTREAM_TSPEC has been assigned in the 0bbbbbbb + range (121) with the following definition: + + Class Types or C-types: + + Same values as SENDER_TSPEC object (C-Num 12) + +5.3. UPSTREAM_ADSPEC Object + + The class named UPSTREAM_ADSPEC has been assigned in the 0bbbbbbb + range (122) with the following definition: + + Class Types or C-types: + + Same values as ADSPEC object (C-Num 13) + +6. Security Considerations + + This document introduces new message objects for use in GMPLS + signaling [RFC3473] -- specifically the UPSTREAM_TSPEC, + UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects. These objects + parallel the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but + are used in the opposite direction. As such, any vulnerabilities + that are due to the use of the old objects now apply to messages + flowing in the reverse direction. + + From a message standpoint, this document does not introduce any new + signaling messages or change the relationship between LSRs that are + adjacent in the control plane. As such, this document introduces no + additional message- or neighbor-related security considerations. + + + + +Takacs, et. al. Standards Track [Page 8] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + See [RFC3473] for relevant security considerations and [RFC5920] for + a more general discussion on RSVP-TE security discussions. + +7. References + +7.1. Normative References + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and + S. Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, September + 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services", RFC 2210, September 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. + +7.2. Informative References + + [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- + Protocol Label Switching (GMPLS) Extensions for + Synchronous Optical Network (SONET) and Synchronous + Digital Hierarchy (SDH) Control", RFC 4606, August 2006. + + [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Extensions for G.709 Optical + Transport Networks Control", RFC 4328, January 2006. + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, April 2009. + + [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., + Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS + Transport Profile", RFC 5654, September 2009. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + + +Takacs, et. al. Standards Track [Page 9] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + + [RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. + Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label + Switched Paths (LSPs)", RFC 5467, March 2009. + + [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC + 6003, October 2010. + + [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, + "Generalized Multiprotocol Label Switching (GMPLS) + Control of Ethernet Provider Backbone Traffic Engineering + (PBB-TE)", RFC 6060, March 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Takacs, et. al. Standards Track [Page 10] + +RFC 6387 Asymmetric Bandwidth Bidirectional LSP September 2011 + + +Authors' Addresses + + Attila Takacs + Ericsson + Konyves Kalman krt. 11. + Budapest, 1097 + Hungary + + EMail: attila.takacs@ericsson.com + + + Lou Berger + LabN Consulting, L.L.C. + + EMail: lberger@labn.net + + + Diego Caviglia + Ericsson + Via A. Negrone 1/A + Genova-Sestri Ponente, + Italy + + Phone: +390106003738 + Fax: + EMail: diego.caviglia@ericsson.com + + + Don Fedyk + Alcatel-Lucent + Groton, MA + USA + + EMail: donald.fedyk@alcatel-lucent.com + + + Julien Meuric + France Telecom Orange + 2, avenue Pierre Marzin + Lannion Cedex, 22307 + France + + EMail: julien.meuric@orange.com + + + + + + + + +Takacs, et. al. Standards Track [Page 11] + |