RFC 6387
GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
RFC 6387: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) 💖
okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's a Standards Track doc, so it's actual protocol spec, not just a vibe 🧚
- Authors: A. Takacs (Ericsson), L. Berger (LabN Consulting, L.L.C.), D. Caviglia (Ericsson), D. Fedyk (Alcatel-Lucent), and J. Meuric (France Telecom Orange) 👑
- Date: September 2011 📅
- ISSN: 2070-1721
- Obsoletes: RFC 5467 (it's the upgraded version of that one, which was an Experimental doc)
Abstract ✨
so this doc defines a way to support GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs) 🦋 The approach works with any switching technology and it's built on the original Resource Reservation Protocol (RSVP) model for carrying traffic-related parameters. It basically takes the experiment from RFC 5467, moves it onto the standards track, and obsoletes RFC 5467. no cap, that's a glow-up 🌸
Status of This Memo 🎀
this is an Internet Standards Track document 💅
it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. more info on Internet Standards is in Section 2 of RFC 5741 📚
for the current status of this doc, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6387 🫶
Copyright Notice 🌈
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date it was published. please actually read these, bestie, they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 . . . . . . . . . . . . . . . . . . 91. Introduction 🧚
GMPLS [RFC3473] brought in explicit support for bidirectional Label Switched Paths (LSPs). the support it defined matched the switching technologies GMPLS covers, like Time Division Multiplexing (TDM) and lambdas. the catch is that it only handled bidirectional LSPs with symmetric bandwidth allocation, so both directions got the same amount. the symmetric bandwidth requirements are carried using the objects defined in [RFC2205] and [RFC2210] 💅
GMPLS asymmetric bandwidth bidirectional LSPs are bidirectional LSPs where each direction has a different bandwidth reservation. asymmetric bandwidth for bidirectional LSPs was discussed earlier in the context of Ethernet, especially in [RFC6060] and [RFC6003]. back then, people figured asymmetric bandwidth support was unlikely to get deployed, so [RFC5467] was published as Experimental. but the MPLS Transport Profile, MPLS-TP, requires that asymmetric bandwidth bidirectional LSPs be supported (see [RFC5654]), so this doc is going on the Standards Track 🚀 it has no technical changes from the approach in [RFC5467]. it moves that experiment to the standards track and obsoletes [RFC5467]. it also drops the Ethernet-technology-specific alternative approach that was discussed in the appendix of [RFC5467], and keeps just one approach that works with any technology. one approach for all, iykyk 🌷
1.1. Background 📚
bandwidth parameters get carried inside RSVP ([RFC2210], [RFC3209], and [RFC3473]) through several objects that RSVP treats as opaque. even though RSVP can't read them, these objects support a particular model for sharing bandwidth info between an RSVP session sender (ingress) and receiver (egress). the original model, defined in [RFC2205] and kept in [RFC3209], used the SENDER_TSPEC and ADSPEC objects in Path messages and the FLOWSPEC object in Resv messages. the SENDER_TSPEC object showed a sender's data generation capabilities. the FLOWSPEC object came from the receiver and said which resources should be allocated to the matching data traffic. the ADSPEC object told the receiver and intermediate hops about the actual resources available for that data traffic 🌸
then bidirectional LSPs showed up in [RFC3473], and the way bandwidth parameters were shared changed without anyone officially saying so 👀 in [RFC3473] bidirectional LSPs, the SENDER_TSPEC object carries the desired resources for both the upstream and downstream directions. the FLOWSPEC object is just a confirmation of what got allocated. the ADSPEC object is either unchanged and only means something for downstream traffic, or it's implicitly or explicitly irrelevant ([RFC4606] and [RFC6003]) ✨
1.2. Approach Overview 🦋
the approach for supporting asymmetric bandwidth bidirectional LSPs in this doc builds on the original RSVP model for carrying traffic-related parameters, plus GMPLS's support for bidirectional LSPs 🫶
the approach is generic, so it works with any switching technology GMPLS supports. the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects get company from the new UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects. the existing objects keep being used the way [RFC2205] and [RFC2210] define, and they only refer to traffic on the LSP flowing in the downstream direction. the new objects get used in exactly the same way as the old ones, but they 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 in this doc are limited to Point-to-Point (P2P) LSPs. support for Point-to-Multipoint (P2MP) bidirectional LSPs is not currently defined, so this doc doesn't cover it 🙅♀️
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 gets signaled using the bidirectional procedures from [RFC3473], plus the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC, and UPSTREAM_ADSPEC objects 🧚
the new upstream objects carry the same info and get used the same way as the existing downstream objects. the difference is that they relate to traffic flowing upstream, while the existing objects relate to traffic flowing downstream. the new objects also travel in messages going the opposite direction 🔥
2.1. UPSTREAM_FLOWSPEC Object 👑
the format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC object [RFC2210]. that includes the 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 it 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 built using a format and procedures consistent with the ones used to build the FLOWSPEC object that the LSP will use, e.g., [RFC2210] or [RFC4328] ⚠️
nodes processing a Path message that contains an UPSTREAM_FLOWSPEC object MUST use the contents of that object in the upstream label and the resource allocation procedure defined in Section 3.1 of [RFC3473]. consistent with [RFC3473], a node that can't 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, including the class types and their formats. the class number of the UPSTREAM_TSPEC object is 121 (of the form 0bbbbbbb) 🌷
2.2.1. Procedures ✨
Okay so the UPSTREAM_TSPEC object describes the traffic flow that starts at the egress 🦋 It 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 built with a format and procedures that match the ones used for the FLOWSPEC object that will be used for the LSP, like [RFC2210] or [RFC4328] 💅 The contents of the UPSTREAM_TSPEC object MAY be different from the contents of the UPSTREAM_FLOWSPEC object, depending on what the application's data transmission needs are 🌈
When an ingress gets an UPSTREAM_TSPEC object, the ingress MAY decide that the original reservation isn't enough for the traffic flow 😭 In that case, the ingress MAY tear down the LSP and send a PathTear message. Or, the ingress MAY send a Path message with an updated UPSTREAM_FLOWSPEC object to change the resources requested for the upstream traffic flow. This change might mean the LSP has to be re-routed, and in extreme cases the LSP could get torn down if there aren't enough resources along its path. Dramatic, I know 💀
2.3. UPSTREAM_ADSPEC Object 🌸
The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC object. That includes the class types and their formats too 🧚 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 built with a format and procedures that are consistent with the ones used for the ADSPEC object that will be used for the LSP, like [RFC2210] or [RFC6003]. The UPSTREAM_ADSPEC object is handled with the same procedures as the ADSPEC object, so it MAY be updated or added at transit nodes 🫶
3. Packet Formats 🎀
This section shows the RSVP message-related formats as they're modified by this section. This document modifies formats defined in [RFC2205], [RFC3209], and [RFC3473]. See [RFC5511] for the syntax used by RSVP. Formats that aren't modified aren't listed here. 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)Here's the format of the sender description for bidirectional asymmetric LSPs 👑
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
<UPSTREAM_FLOWSPEC>And here's the format of the flow descriptor list for bidirectional asymmetric LSPs 🔥
<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 the semantics and procedures defined in [RFC2205], [RFC3209], and [RFC3473] to support bidirectional LSPs with asymmetric bandwidth. Three new objects are defined to signal that asymmetric bandwidth is being used. Each of these objects is defined with class numbers in the form 0bbbbbbb. Per [RFC2205], nodes that don't support this extension won't recognize the new class numbers and will respond with an "Unknown Object Class" error 🙈 That error message will travel back to the ingress, which can then avoid the path with the incompatible node or just end the session.
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. So any vulnerabilities that come from the old objects now apply to messages flowing in the reverse direction 😱
From a message standpoint, this document doesn't introduce any new signaling messages or change the relationship between LSRs that are adjacent in the control plane. So this document adds no extra message- or neighbor-related security considerations 🙌
See [RFC3473] for the relevant security considerations, and [RFC5920] for a broader discussion of RSVP-TE security 🛡️
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.
[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.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📦 where this page comes from
- ietf: rfc6387 2011-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms