RFC 6060
Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)
RFC 6060 🎀 Part 1
okay bestie, let's get into it 💖 this one is about running GMPLS control on Ethernet PBB-TE paths, and it's honestly giving main character energy 🦋
Title: Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) ✨
Published by: the IETF, March 2011 📅
Category: Standards Track, with ISSN 2070-1721 🔥
Authors: D. Fedyk (Alcatel-Lucent), H. Shah (Ciena), N. Bitar (Verizon), and A. Takacs (Ericsson) 👑
Obsoletes/Updates: the header doesn't list any RFCs it obsoletes or updates 🫶
Abstract 📝
okay so the abstract is saying this spec is the buddy of the GMPLS Ethernet Label Switching Architecture and Framework doc. It describes the technology-specific bits of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). It also lays out the GMPLS extensions and mechanisms you need to set up Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections 🌸 The best part is that it supports the standard IEEE data plane without modifying it. not me being impressed 💅
Status of This Memo 📋
This is an Internet Standards Track document. ⭐
This document is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🧚
Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6060 🍓
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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include 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 🫶
this part is serious, so read closely 🙈 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 💜
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Co-Authors .................................................3
2. Terminology .....................................................4
2.1. PBB-TE and GMPLS Terminology ...............................5
2.2. Conventions Used in This Document ..........................6
3. Creation and Maintenance of PBB-TE Paths Using GMPLS ............6
3.1. Shared Forwarding ..........................................9
3.2. P2P Connections Procedures for Shared Forwarding ..........10
4. Specific Procedures ............................................10
4.1. P2P Ethernet LSPs .........................................10
4.1.1. P2P Path Maintenance ...............................11
4.2. P2MP Ethernet-LSPs ........................................12
4.3. PBB-TE Ethernet Label .....................................12
4.4. Protection Paths ..........................................13
4.5. Service Instance Identification ...........................13
5. Error Conditions ...............................................15
5.1. ESP-VID-Related Errors ....................................15
5.1.1. Invalid ESP-VID Value in the PBB-TE
Ethernet Label .....................................15
5.1.2. Allocated ESP-VID Range is Exhausted ...............16
5.2. Invalid MAC Address .......................................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................19
9. Acknowledgments ................................................191. Introduction ✨
okay so the IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE802.1Qay] standard is what lets you set up explicitly routed, traffic engineered paths inside Provider Backbone Bridged (PBB) networks 🦋 It lets you turn off:
- the Spanning Tree Protocol
- unknown destination address forwarding
- source address learning
…but only for VLAN Identifiers that are administratively selected. 💅 With PBB-TE, an external provisioning system or a control plane can configure static entries in the managed objects of bridges, and that's how the traffic engineered paths get built in the network 🧚
Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols made for connection oriented and traffic engineering transport networks 🌸 It works with a bunch of network technologies, including L2SC networks (Layer 2 Switching Capable). So the point of this doc is to specify extensions for a GMPLS-based control plane that manages PBB-TE explicitly routed traffic engineered paths. It's the buddy of the GMPLS Ethernet Label Switching Architecture and Framework document [RFC5828] 💖
1.1. Co-Authors 👯
this doc was made by a huge team of authors and contributors 🫶 Here's the list of co-authors:
David Allan
Ericsson
EMail: david.i.allan@ericsson.comDiego Caviglia
Ericsson
Via Negrone 1/A
Genoa, Italy 16153
EMail: diego.caviglia@ericsson.comAlan McGuire
BT Group PLC
OP6 Polaris House,
Adastral Park, Martlesham Heath,
Ipswich, Suffolk, IP5 3RE, UK
EMail: alan.mcguire@bt.comNurit Sprecher
Nokia Siemens Networks,
GmbH & Co. KG
COO RTP IE Fixed
3 Hanagar St. Neve Ne'eman B,
45241 Hod Hasharon, Israel
EMail: nurit.sprecher@nsn.comLou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net2. Terminology 📚
besides the well-understood GMPLS terms, this memo uses the following terminology from IEEE 802.1 [IEEE802.1ah] [IEEE802.1Qay] 🌈
- BCB: Backbone Core Bridge
- BEB: Backbone Edge Bridge
- B-MAC: Backbone MAC
- B-VID: Backbone VLAN ID
- B-VLAN: Backbone VLAN
- CBP: Customer Backbone Port
- CCM: Continuity Check Message
- CNP: Customer Network Port
- C-MAC: Customer MAC
- C-VID: Customer VLAN ID
- C-VLAN: Customer VLAN
- ESP: Ethernet Switched Path
- ESP-MAC SA: ESP Source MAC Address
- ESP-MAC DA: ESP Destination MAC Address
- ESP-VID: ESP VLAN ID
- Eth-LSP: Ethernet Label Switched Path
- IB-BEB: A BEB comprised of both I- and B-components
- I-SID: Ethernet Service Instance Identifier
- TAG: An Ethernet Header Field with Type and Values
- MAC: Media Access Control
- PBB: Provider Backbone Bridges
- PBB-TE: Provider Backbone Bridges Traffic Engineering
- PIP: Provider Instance Port
- PNP: Provider Network Port
- PS: Protection Switching
- P2P: Point-to-Point
- P2MP: Point-to-Multipoint
- SVL: Shared VLAN Learning
- TESI: Traffic Engineering Service Instance
- VID: VLAN ID
- VIP: Virtual Instance Port
- VLAN: Virtual LAN
2.1. PBB-TE and GMPLS Terminology 🔥
okay so the PBB-TE spec [IEEE802.1Qay] defines some extra terminology to clarify the PBB-TE functions. We're repeating it here in expanded context so you can translate from IEEE terms to GMPLS terms 💅 The words "bridge" and "switch" are used interchangeably in this document. The signaling extensions here work just as well for a PBB-TE-capable bridge that supports GMPLS signaling, or for a GMPLS-capable switch that supports Ethernet PBB-TE forwarding 🧚
- Ethernet Switched Path (ESP): a provisioned traffic engineered unidirectional connectivity path between two or more Customer Backbone Ports (CBPs) that extends over a Provider Backbone Bridge Network (PBBN). The path is identified by the 3-tuple
<ESP-MAC DA, ESP-MAC SA, ESP-VID>. An ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP is analogous to a (unidirectional) point-to-point or point-to-multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS established ESPs 🦋 - Point-to-Point ESP: an ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's 3-tuple identifier are the individual MAC addresses of the two CBPs 🌸
- Point-to-Multipoint ESP: an ESP among one root CBP and n leaf CBPs. The ESP-DA in the ESP's 3-tuple identifier is a group MAC address identifying the n leaf CBPs, and the ESP-SA is the individual MAC address of the root 💖
- Point-to-Point PBB-TE Service Instance (P2P TESI): a service instance supported by two point-to-point ESPs where the ESPs' endpoints have the same CBP MAC addresses. The two unidirectional ESPs form a bidirectional service. the PBB-TE standard [IEEE802.1Qay] notes the following: for reasons relating to TE service monitoring diagnostics, operational simplicity, etc., the IEEE PBB-TE standard assumes that the point-to-point ESPs associated with a point-to-point TESI are co-routed. Support for a point-to-point TE services that comprises non-co-routed ESPs is problematic, and is not defined in this standard. So a GMPLS bidirectional LSP is analogous to a P2P TE Service Instance. We use the term "bidirectional Ethernet-LSP" for GMPLS-established P2P PBB-TE Service Instances 👑
2.2. 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] 🫶💜
3. Creation and Maintenance of PBB-TE Paths Using GMPLS ✨
okay so IEEE PBB-TE is a connection-oriented Ethernet technology 🎀 its ESPs get built bridge by bridge (or switch by switch) just by simple configuration of Ethernet forwarding entries 💅 this doc says GMPLS can be used as a valid control plane for setting up, tearing down, protecting, and recovering ESPs and TESIs 🦋 and it specifies the RSVP-TE extensions that are required for controlling PBB-TE Service Instances 🔥
PBB-TE ESPs and services always start and end on IB-Backbone Edge Bridges (IB-BEBs) 👑 an IB-BEB is made of an I component and a B component, which you can see in Figure 1 🌸 the B-component is the bit that relays frames identified by Backbone VLANs in a Provider Backbone Bridge 💜 the I-component relays frames identified by service instances (I-SIDs) in a Provider Backbone Bridge 🧚 PBB and PBB-TE relay frames with I-Component TAGs added in the I-component and VLAN TAGs in the B-component 🫶 they forward frames based on the VLAN ID in the VLAN TAG (in the PBB case a B-VID) until the destination MAC address is supported locally by a B-component on that bridge, which means the destination has been reached 🌈 then the B-VLAN tag gets removed and the processing or forwarding moves on to the next TAG (in the PBB case an I-Component TAG) until the I-component identified by the I-SID is reached ✨ at the I-component, the I-Component TAG gets removed and the next Ethernet type identifies the TAG, and so on 😭
An Ethernet service supported by a PBB-TE TESI is always attached to a Customer Network Port (CNP) of the I-component 🍓 an I-SID gets assigned for the service 💖 I-SIDs are only looked at by the source and destination (edge) bridges, so they're transparent to path operations and MAY be signaled 🦋 the I- and B-components have internal ports connected through an internal LAN 🎀 those internal ports are the Provider Instance Ports (PIPs) and Customer Backbone Ports (CBPs) 🌸 PIPs and CBPs are not visible outside the IB-BEB, so they stay hidden inside 🙈 ESPs are always originated and terminated on CBP ports and use that port's MAC address 💅 the I-component wraps the service frames arriving from the CNP by adding an I-SID and a complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA 🔥 then the B-component adds the ESP-VID 👑
This document defines GMPLS extensions to establish ESPs and TESIs 🌈 as you can tell from all that, it means both the I- and B-components of the IB-BEBs connected by the ESPs have to be configured 😭
In the GMPLS control plane, TE Router IDs identify the IB-BEBs and Backbone Core Bridges (BCBs) 💜 TE Links describe links connected to PNPs and CNPs 🧚 TE Links are not associated with CBPs or PIPs 🫶
Note that since multiple internal CBPs may exist, an IB-BEB that receives a PATH message MUST be able to determine the right CBP, which is the termination point of the Eth-LSP 🔥 to make that happen, IB-BEBs SHOULD advertise the CNP TE Links in the GMPLS control plane, and RSVP-TE signaling SHOULD use the CNP TE Links to identify the termination point of Eth-LSPs 💖 an IB-BEB that receives a PATH message specifying one of its CNPs can work out locally which CBPs have internal connectivity to the I-component supporting that CNP 🌸 if there's more than one suitable CBP, and no I-SID information is given in the PATH message or earlier in the associated Call setup, then the IB-BEB can freely decide which CBP to assign to the requested connection 🎀 but if there IS I-SID information about the service the ESP will support, then the IB-BEB MUST first determine which PIP and associated CBP is configured with that I-SID, and MUST assign that CBP to the ESP 👑 main character energy for sure 💅
Backbone Edge Bridge (BEB)
+------------------------------------------------------+
| <TE - Router ID > |
| |
| I-Component Relay B-Component Relay |
| +-----------------------+ +---------------------+ |
| | +---+ | | B-VID | |
| | |VIP| | | +---+ +---+ | | <TE Link>
| | +---+ | +---|CBP| |PNP|------
| | | | | +---+ +---+ | |
| | +---+ +---+ | | | | |
------|CNP| |PIP|----+ | | |
| | +---+ +---+ | | | |
| +-----------------------+ +---------------------+ |
| |
| PBB Edge Bridge |
+------------------------------------------------------+
^--------Configured--------------^
^-----------GMPLS or Configured------^
Figure 1: IB-BEBs and GMPLS IdentifiersHere's Figure 2 so you can see the whole picture 🦋 the control plane has TE Router IDs and a TE Link, and the data plane has the label space with ESP:VID/MAC DA 🎀
Control TE Router ID TE Router ID
Plane | (TE Link) |
V | V
+----+ | +-----+
Data | | | | |
Plane | | V label=ESP:VID/MAC DA | |
-----N N----------------------------N N----------
| | PBB-TE | | \ Network
| | / | Or
+----+ /+-----+ Customer
BCB ESP:MAC IB-BEB Facing
Ethernet
Ports
Figure 2: Ethernet/GMPLS Addressing and Label SpacePBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a unique connection identifier in the data plane 🌈 but the forwarding operation only uses the ESP-MAC DA and the ESP-VID in each direction 🧚 the ESP-VID typically comes from a small number of VIDs dedicated to PBB-TE 💜 ESP-VIDs can be reused across ESPs 💅 and there's no requirement that the ESP-VIDs for two ESPs forming a P2P TESI be the same 🫶
When you configure an ESP with GMPLS, the ESP-MAC DA and ESP-VID are carried in a generalized label object 🎀 they're assigned hop by hop, but they stay invariant within a domain 🌸 this invariance is similar to GMPLS operation in transparent optical networks 💖 as is typical with other technologies controlled by GMPLS, the data plane receiver MUST accept, and usually assigns, labels from its available label pool 🔥 that, together with the label invariance requirement above, means each PBB-TE Ethernet Label ends up being a domain-wide unique label, with a unique ESP-VID + ESP-MAC DA, for each direction 👑
Here's how PBB-TE Ethernet Labels and ESPs look for a P2P TESI 🦋
GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)
GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)
Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
Table 1: Labels and ESPs3.1. Shared Forwarding
one capability of a connectionless Ethernet data plane is reusing destination forwarding entries for packets from any source within a VLAN to a destination 🌸 when you set up P2P PBB-TE connections for multiple sources sharing a common destination, this capability MAY be preserved, as long as certain requirements are met 💖 we call this capability "shared forwarding" ✨ it gets invoked based on policy when conditions are met 🎀 it's a local decision made by label allocation at each end, plus the path constraints 🔥 shared forwarding has no impact on the actual paths that get set up, but it lets you cut down on forwarding entries 🧚 shared forwarding paths work the same as independently routed paths that share a path from an intersecting bridge or link, except they share a single forwarding entry 🫶
the forwarding memory savings from shared forwarding can be seriously dramatic in topologies that need a high degree of meshing 😭 but it's usually easier to pull off when the connectivity is known in advance 🌈 normally, the originating GMPLS switch won't know about the set of shared forwarding paths rooted on the source or destination switch 💅
using a Path Computation Element [RFC4655], or another planning-style tool with more complete knowledge of the network configuration, is one way to pre-select shared forwarding with multiple paths that use a single forwarding entry while optimizing for both directions 👑 in this scenario, the originating bridge uses the LABEL_SET and UPSTREAM_LABEL objects to indicate the selection of the shared forwarding labels at both ends 💜
3.2. P2P Connections Procedures for Shared Forwarding
the ESP-VID/ESP-MAC DA can be treated as a shared forwarding identifier, or label, made up of some number of P2P connections that are distinctly identified by the <ESP-MAC DA, ESP-MAC SA, ESP-VID> tuple 🦋 this is analogous to an LDP label merge, but in the shared forwarding case the ESP header holds enough information to identify the flow a packet belongs to 🎀 resources can keep being allocated per LSP with shared forwarding 🌸
VLAN-tagged Ethernet packets include priority marking 💖 priority bits MAY be used to indicate Class of Service (COS) and drop priority 🔥 so traffic from multiple COSs can get multiplexed on the same Eth-LSP (kind of like E-LSPs) and queuing and drop decisions are made based on the p-bits 🧚 that means queue selection can happen on a per-flow basis (Eth-LSP + priority), and it's decoupled from how the packet gets steered at any given bridge 🫶
a bridge terminating an Eth-LSP will often have more than one suitable candidate for sharing a forwarding entry (common ESP-VID/ESP-MAC DA, unique ESP-MAC SA) 😭 how that choice gets made is a local decision, but a good option is a path that cuts down on the need for new forwarding entries by reusing common existing paths 💅
the concept of bandwidth management still applies just as well with shared forwarding 👑
4. Specific Procedures 🌈
4.1. P2P Ethernet LSPs ✨
okay so PBB-TE is designed to be bidirectional and symmetrically routed, just like Ethernet 🫶 that means the complete, proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs 💅 so this section is all about setting up bidirectional Eth-LSPs 🦋
ngl there's a sneaky note here 🙈 it's also possible to use RSVP-TE to configure unidirectional ESPs, but only if the UPSTREAM_LABEL is not included in the PATH message.
okay, so to start a bidirectional Eth-LSP, the initiator of the PATH message MUST follow the procedures in [RFC3473], with these specifics 👑
- it MUST set the LSP encoding type to Ethernet (2) [RFC3471].
- it MUST set the LSP switching type to
"802_1 PBB-TE", value40. - it SHOULD set the Generalized Payload Identifier (G-PID) to Ethernet (33) [RFC3471].
- it MUST set the
UPSTREAM_LABELto theESP-VID1/ESP-MAC1tuple, where theESP-VID1is administered locally for the local MAC addressMAC1. - it SHOULD set the
LABEL_SETorSUGGESTED_LABELif it wants to influence the choice ofESP-VID/ESP-MAC DA🎀 - it MAY carry an I-SID via Call/Connection ID [RFC4974].
intermediate and egress bridge processing isn't changed by this document, i.e., it's per [RFC3473] 🌸 but, as we said before, intermediate bridges supporting the 802_1 PBB-TE switching type MUST NOT modify LABEL values 🚫
the ESP-VID1/ESP-MAC1 tuple in the UPSTREAM_LABEL is used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction 🧚 the switching type (802_1 PBB-TE) is what tells everyone this is happening. the port derived from the RSVP_HOP object, plus the ESP-VID1 and ESP-MAC1 in the PBB-TE Ethernet Label, make up that static entry.
at the destination, an ESP-VID (ESP-VID2) gets allocated for the local MAC address MAC2, and the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL object in the RESV message 💜 same as with the PATH message, intermediate bridge processing follows [RFC3473], and the LABEL object MUST be passed on unchanged, upstream. the ESP-VID2/ESP-MAC2 tuple in the LABEL object gets installed in the forwarding table as a static forwarding entry at each hop. this creates a bidirectional Eth-LSP because the PATH and RESV messages follow the same path, and that's the whole vibe ✨🔥
4.1.1. P2P Path Maintenance 🌈
make-before-break procedures can be used to change the characteristics of a P2P Eth-LSP 🦋 as described in [RFC3209], the LSP ID in the sender template gets updated as the new path is signaled. the procedures (including the ones for shared forwarding) are identical to the ones used when establishing a new LSP, and the extended tunnel ID in the signaling exchange makes sure double booking of an associated resource doesn't happen 🙌
where individual paths in a protection group are modified, signaling procedures MAY be combined with Protection Switching (PS) coordination, so that modification is only ever done on the protection path 🛡️ PS is a native capability of PBB-TE [IEEE802.1Qay], and it can operate when two paths are set up between two common endpoints. iconic, honestly 👑
4.2. P2MP Ethernet-LSPs 🌸
PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding 💖 in this case, the PBB-TE Ethernet Label is made up of a VID and a Group MAC address. the procedures in [RFC3473] and [RFC4875] could be adapted to signal P2MP LSPs for the source (point) to destination (multipoint) direction. each branch of the P2MP Eth-LSP would be associated with a reverse-path symmetric and congruent P2P Eth-LSP ✨
complete procedures for signaling bidirectional P2MP E-LSPs are out of scope for this document 🙈
4.3. PBB-TE Ethernet Label 🎀
the PBB-TE Ethernet Label is a new generalized label with the following format 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PBB-TE Ethernet Labelthis format MUST be used for both P2P and P2MP Eth-LSPs 💅 for P2P Eth-LSPs, the fields specify a VID and a unicast MAC address. for P2MP Eth-LSPs, a VID and a group MAC address get carried in the label instead. the PBB-TE Ethernet Label is a domain-wide unique label and MUST be passed unchanged at each hop. this is kinda similar to how a wavelength label gets handled at an intermediate bridge that can't do wavelength conversion, which is described in [RFC3473] 🌈
4.4. Protection Paths 🛡️
when protection is used for path recovery, it's required to associate the working and protection paths into a protection group 👑 this is done as defined in [RFC4872] and [RFC4873], using the ASSOCIATION and PROTECTION objects 💜
4.5. Service Instance Identification 🦋
the I-SID is used to uniquely identify services within the network 💖 unambiguous identification comes from making sure I-SIDs are globally unique within the network, or at least unique between any pair of edge bridges. on IB-BEBs, the Backbone Service Instance Table is used to configure the mapping between I-SIDs and ESPs. this configuration can be either manual or semi-automated by the signaling described here ✨
RSVP-TE Signaling MAY be used to automate I-SID to ESP mapping 🧚 by relying on signaling, you get the guarantee that the same I-SID is assigned to the service and mapped to the same ESP. also, by signaling the I-SID associated with the ESP, you can make sure IB-BEBs select the appropriate CBP port 🫶
CALL signaling [RFC4974] MAY be used to create an association between the Eth-LSP endpoints before the LSP is established. the CALL_ATTRIBUTES object can be used during CALL signaling, as described in [RFC4974], to indicate properties of the CALL. the Service ID TLV, defined below, can be carried in the CALL_ATTRIBUTES object to indicate the I-SID to ESP mapping for the Eth-LSP that will be set up in association with the CALL 🎀
alternatively, the GMPLS RSVP-TE PATH message can carry the I-SID association using the Service ID TLV in the LSP_ATTRIBUTES object [RFC5420] at the time of Eth-LSP signaling 🌸 with this mechanism, you can create the I-SID association either when the path is set up or later, using a PATH refresh. that's giving flexibility 😭
a new Service ID TLV is defined for the CALL_ATTRIBUTES and LSP_ATTRIBUTES objects 💅 the type value is 3 when carried in the CALL_ATTRIBUTES object, and the type value is 2 when carried in the LSP_ATTRIBUTES object. the format is shown below 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Service ID TLV- I-SID Set Object: this is used to define a list or range of I-SIDs. multiple I-SID Set Objects can be present. at least one I-SID Set Object MUST be present. in most cases, a single I-SID Set Object with a single I-SID value is used. the I-SID Set Object is used to define a list or range of I-SIDs. its format is based on the
LABEL_SETObject 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: I-SID Set Object- Action: 8 bits. the following actions are defined: list (0) and range (1). when a range is defined, there are only two I-SIDs: the beginning I-SID and the end of the range I-SID. when list is defined, a number of I-SIDs may be defined 💜
- Length: 16 bits. this indicates the length of the I-SID Set object 🍓
- I-SID: 24 bits. the I-SID value identifies a particular backbone service instance ✨
5. Error Conditions 💀
the following errors identify Eth-LSP-specific problems 🙈
in PBB-TE, a set of ESP-VIDs allocated to PBB-TE must be configured. so it's possible in some situations that one bridge's configuration isn't the same as the others. if the ESP-VIDs of various bridges have some ESP-VIDs in common, some paths might get set up before issues show up. this is a management issue, since all bridges should have the same ESP-VID range. configuration should be consistent, bestie 🫶
5.1. ESP-VID-Related Errors 🚨
the network operator administratively selects a set of VLAN Identifiers that can be used to set up ESPs. so any VID outside the allocated range is invalid, and an error MUST be generated wherever the mismatch is discovered 😭 the Error indication is carried in the PathErr message from any intermediate bridge that doesn't support the signaled source VID, or optionally the destination VID. the Error MAY be indicated in the ResvErr if the allocation error happens on the RESV message. in this case, a bridge that doesn't support the signaled destination VID MUST signal the error 💅
5.1.1. Invalid ESP-VID Value in the PBB-TE Ethernet Label 🎀
if a bridge isn't configured to use the ESP-VID value carried in the Label object for PBB-TE ESPs, it MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). handling of this error follows [RFC3209] 🌸
note that an originating bridge can reuse an ESP-VID with a different source or destination B-MAC address. by allocating a number of B-MACs and a number of ESP-VIDs, a large number of PBB-TE connections may be supported 🧚
note, this error may be originated by any bridge along the path 👑
5.1.2. Allocated ESP-VID Range is Exhausted 🎀
okay bestie, so once the destination bridge gets the PATH message, it has to assign a VID 💖. That VID plus its MAC address is what makes up the PBB-TE Ethernet Label ✨. An existing VID may be reused when shared forwarding is used or when there are no path conflicts 🦋. Otherwise, the bridge has to allocate a VID.
Depending on how big the allocated VLAN range is and how many Eth-LSPs end up terminated on one bridge, the available VIDs can run out 😭. When that happens, no PBB-TE Ethernet Label can be allocated. In this case, the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9) 🚨.
5.2. Invalid MAC Address 🙈
IEEE defines a set of reserved MAC addresses, from 01-80-C2-00-00-00 to 01-80-C2-00-00-0F, as explained in [IEEE802.1Q] 🧚. These addresses have special meaning and processing, and they follow specific forwarding rules, so they're not vibing with PBB-TE ESPs at all 💀. They cannot be used for PBB-TE ESPs. If the PBB-TE Ethernet Label refers to one of these MAC addresses, a bridge that runs into the mismatch MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6) 🔥. Handling of this error is according to [RFC3209].
6. Security Considerations 🔐
This document does not introduce new security issues; the considerations in [RFC4872] and [RFC4873] apply. 🫶
A GMPLS-controlled Ethernet PBB-TE system assumes that users and devices attached to User-to-Network Interfaces (UNIs) may behave maliciously, negligently, or incorrectly 👀. Intra-provider control traffic is trusted not to be malicious. Generally, these requirements are no different from the security requirements for operating any GMPLS network. Access to the trusted network will only occur through the protocols defined for the UNI or Network-to-Network Interface (NNI) or through protected management interfaces 🔒.
When in-band GMPLS signaling is used for the control plane, the security of the control plane and the data plane may affect each other 😬. When out-of-band GMPLS signaling is used for the control plane, the data-plane security is decoupled from the control plane. Therefore, the security of the data plane has less impact on overall security 🧠.
Where GMPLS is applied to the control of VLAN only, the commonly known techniques for mitigation of Ethernet denial-of-service (DoS) attacks may be required on UNI ports 🚧. PBB-TE has been designed to interwork with legacy VLANs, and the VLANs provide isolation from Ethernet legacy control planes 🌈.
Where control-plane communications are point-to-point over links that employ 802.1AE Media Access Control Security [MACSEC], it may reasonably be determined that no further security measures are used 🎀. In other cases, it is appropriate to use control-plane security where it is deemed necessary to secure the signaling messages. GMPLS signaling security measures are described in [RFC3471] and [RFC3473], and they inherit security techniques applicable to RSVP-TE, as described in [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security techniques, see [RFC5920] 📚.
7. IANA Considerations 🦋
A new Switching Type, "802_1 PBB-TE" (40), has been assigned in the Switching Types registry of the GMPLS Signaling Parameters registry ✨.
The Service ID TLV has been assigned in the Attributes TLV Space in the RSVP-TE Parameters registry. It is carried in the LSP_ATTRIBUTES object (class = 197, C-Type = 1) [RFC5420]. This new type has been registered as follows 💅:
Type: 2
Name: Service ID TLV
Allowed on LSP_ATTRIBUTES: Yes
Allowed on LSP_REQUIRED_ATTRIBUTES: NoThe Service ID TLV has been assigned value 3 in the Call Attributes TLV registry in the RSVP Parameters registry. It is carried in the CALL_ATTRIBUTES object (class = 202, C-Type = 1) defined by [RFC6001] 🎀.
8. References 📚
8.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [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.
- [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.
- [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Swicthing (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
- [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
- [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
- [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
- [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 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.
- [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
8.2. Informative References
- [IEEE802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", (2008)
- [IEEE802.1Q] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2005, May 19, 2006.
- [IEEE802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment : Provider Backbone Bridges Traffic Engineering", 2009.
- [MACSEC] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, August 18, 2006.
- [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.
- [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
- [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010.
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
9. Acknowledgments 🫶
The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen Shew, Dave Martin and Sandra Ballarte for their contributions to this document. The authors thank Deborah Brungard and Adrian Farrel for their review and suggestions to this document 💜.
Authors' Addresses ✨
Don Fedyk
Alcatel-Lucent
Groton, MA 01450
Phone: +1-978-467-5645
EMail: donald.fedyk@alcatel-lucent.com
Himanshu Shah
Ciena
1741 Technology Dr, #400
San Jose, CA 95110
Phone: 508-435-0448
EMail: hshah@ciena.com
Nabil Bitar
Verizon
40 Sylvan Rd.
Waltham, MA 02451
EMail: nabil.n.bitar@verizon.com
Attila Takacs
Ericsson
1. Laborc u.
Budapest, HUNGARY 1037
EMail: attila.takacs@ericsson.com📦 where this page comes from
- ietf: rfc6060 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms