RFC 5828
Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework
RFC 5828: Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework ✨
Okay bestie, let's get into this one 🦋 It's RFC 5828, published by the IETF in March 2010. The authors are D. Fedyk (Alcatel-Lucent), L. Berger (LabN), and L. Andersson (Ericsson). It's Informational, so it's published for information and isn't a Standards Track spec. The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC 💅
Abstract 🌸
Ethernet switches have been getting seriously upgraded lately 🔥 Because of that, Ethernet is rapidly spreading into "transport networks", which used to be the turf of Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized-MPLS-based control plane for Ethernet in this "transport network" role. GMPLS has already been specified for similar technologies, but some extra extensions to the GMPLS control plane are needed, and this document gives a framework for those extensions 💖
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for informational purposes 🧚
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard. See Section 2 of RFC 5741.
Want the current status of this document, any errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc5828.
Copyright Notice 🎀
Copyright (c) 2010 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 in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 🫶
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.1.1. Concepts ............................................5
1.1.2. Abbreviations and Acronyms ..........................6
2. Background ......................................................7
2.1. Ethernet Switching .........................................7
2.2. Operations, Administration, and Maintenance (OAM) .........10
2.3. Ethernet Switching Characteristics ........................10
3. Framework ......................................................11
4. GMPLS Routing and Addressing Model .............................13
4.1. GMPLS Routing .............................................13
4.2. Control Plane Network .....................................14
5. GMPLS Signaling ................................................14
6. Link Management ................................................15
7. Path Computation and Selection .................................16
8. Multiple VLANs .................................................17
9. Security Considerations ........................................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
11. Acknowledgments ...............................................201. Introduction ✨
There has been a ton of recent work making Ethernet switches more capable 🔥 As a result, Ethernet is quickly moving into "transport networks", which used to be the domain of SONET/SDH, TDM, and ATM. Developing Ethernet for these areas is a very active, ongoing process 💅
Lots of organizations are working on this. The Institute of Electrical and Electronics Engineers (IEEE) 802.1 Working Group, the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T), and the Metro Ethernet Forum (MEF) are all in on it. These groups have been focused on Ethernet forwarding, Ethernet management plane extensions, and the Ethernet Spanning Tree Control Plane. What they haven't done is an explicitly routed, constraint-based control plane 👀
On the forwarding side, extensions have been defined (or are being defined) to support different transport Ethernet forwarding models, protection modes, and service interfaces. Examples include [802.1ah], [802.1Qay], [G.8011], and [MEF.6]. These extensions give the Ethernet forwarding plane more flexibility and, in some cases, let it move away from forwarding based on a spanning tree 🦋 For instance, with [802.1ah] you get more flexibility thanks to a "provider" address space. And [802.1Qay] supports provisioning systems and network control protocols that explicitly pick traffic-engineered paths. Iconic 👑
This document gives a framework for GMPLS Ethernet Label Switching (GELS). GELS will probably need more than one switching type to cover the different models. Since the GMPLS procedures that need extending depend on the switching type, those details will live in the technology-specific documents 🧚
In the provider bridge model, developed in the IEEE 802.1ad project and amended into the IEEE 802.1Q standard [802.1Q], an extra Virtual Local Area Network (VLAN) identifier (VID) gets added. This VID is called the Service VID (S-VID) and it's carried in a Service TAG (S-TAG) 💖 In Provider Backbone Bridges (PBBs) [802.1ah], a Backbone VID (B-VID) and a B-MAC header with a service instance (I-TAG) wrap around a customer Ethernet frame or a service Ethernet frame. Layers within layers, no cap 🌈
In IEEE 802.1Q, the terms Provider Backbone Bridges (PBBs) and Provider Backbone Bridged Network (PBBN) are used for these extensions.
An example of Ethernet protection extensions is in [G.8031]. Ethernet operations, administration, and maintenance (OAM) is another big area being extended to support provider Ethernet services. Related work is in [802.1ag] and [Y.1731] 🛠️
There's also an Ethernet-based service model being defined within the MEF and ITU-T. [MEF.6] and [G.8011] are parallel frameworks for describing network-oriented characteristics of Ethernet services in transport networks. They cover general Ethernet connection characteristics, Ethernet User-Network Interfaces (UNIs), and Ethernet Network-Network Interfaces (NNIs). [G.8011.1] defines the Ethernet Private Line (EPL) service, and [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6] covers both service types. All of this lines up with the types of Ethernet switching defined in [802.1ah] ✨
The Ethernet forwarding-plane and management-plane extensions allow standard Spanning Tree Protocols to be disabled, but they don't define an explicitly routed, constraint-based control plane. [802.1Qay] is the one that explicitly allows traffic engineering of Ethernet forwarding paths, which is the big plot twist 😭
The IETF's GMPLS work gives Internet and telecommunication service providers a common control plane for different data-plane technologies. The GMPLS architecture is specified in RFC 3945 [RFC3945]. The GMPLS protocols can control "Transport Network" technologies, like optical and TDM networks. GMPLS can also be used for packet and Layer 2 Switching (frame/cell-based networks) 🌸
This document gives a framework for using GMPLS to control "transport" Ethernet Label Switched Paths (Eth-LSPs). Transport Ethernet brings new constraints, so it has to be told apart from the technologies GMPLS already covers. Some extra GMPLS control plane extensions are needed, and this document gives a framework for them. All extensions for Eth-LSPs will be built on the GMPLS architecture and related specifications 💅
This document introduces and explains GMPLS control plane use for transport Ethernet, plus the concept of the Eth-LSP. The data-plane aspects of Eth-LSPs are outside the scope of this document and IETF activities 🙈
The goal here is to reuse GMPLS protocols and stay aligned with them as much as possible. For example, reusing the IP control-plane addressing lets existing signaling, routing, Link Management Protocol (LMP), and path computation work as specified. The GMPLS protocols support hierarchical LSPs as well as contiguous LSPs. GMPLS mechanisms also cover a range of network reference points, from UNIs to NNIs. New GMPLS capabilities will only be added to handle features that are unique to transport Ethernet 🫶
1.1. Terminology 🎀
To be continued, bestie, part 2 is coming up next 💜
1.1.1. Concepts 💖
okay so before we get into the good stuff, here are the basic Ethernet and GMPLS terms you need to know 🫶
- Asymmetric Bandwidth: this one refers to a property of a bidirectional service instance that has differing bandwidth allocation in each direction 🦋
- Bidirectional congruent LSP: this is the property of a bidirectional LSP that uses only the same nodes, ports, and links in both directions. Ethernet data planes are normally bidirectional congruent (sometimes known as reverse path congruent) ✨
- Contiguous Eth-LSP: a contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from multiple Eth-LSPs, each of which is operating within a VLAN and is mapped one-to-one at the VLAN boundaries. Stitched LSPs form contiguous LSPs 🧵
- Eth-LSP: this term refers to Ethernet Label Switched Paths that may be controlled via GMPLS 🌸
- Hierarchical Eth-LSP: hierarchical Eth-LSPs create a hierarchy of Eth-LSPs 🪜
- In-band GMPLS signaling: this is composed of IP-based control messages that are sent on the native Ethernet links encapsulated by a single-hop Ethernet header. Logical links that use a dedicated VID on the same physical links would be considered in-band signaling 📡
- Out-of-band GMPLS signaling: this is composed of IP-based control messages that are sent between Ethernet switches over links other than the links used by the Ethernet data plane. Out-of-band signaling typically shares a different fate from the data links 🙈
- Point-to-point (P2P) Traffic Engineering (TE) service instance: a TE service instance made up of a single bidirectional P2P or two P2P unidirectional Eth-LSPs 🎀
- Point-to-multipoint (P2MP) Traffic Engineering (TE) service instance: a TE service instance supported by a set of LSPs that comprises one P2MP LSP from a root to n leaves, plus a bidirectional congruent point-to-point (P2P) LSP from each of the leaves to the root 🌳
- Shared forwarding: this is a property of a data path where a single forwarding entry (VID + Destination MAC address) may be used for frames from multiple sources (Source MAC addresses). Shared forwarding does not change any data-plane behavior. It saves forwarding database (FDB) entries only, and it offers similar benefits to merging in the data plane. However, in shared forwarding, the Ethernet data packets are unchanged. With shared forwarding, dedicated control-plane states for all Eth-LSPs are maintained regardless of shared forwarding entries 💜
1.1.2. Abbreviations and Acronyms 📚
the following abbreviations and acronyms are used in this document 👑
CCM Continuity Check Message
CFM Connectivity Fault Management
DMAC Destination MAC Address
Eth-LSP Ethernet Label Switched Path
I-SID Backbone Service Identifier carried in the I-TAG
I-TAG A Backbone Service Instance TAG defined in the
IEEE 802.1ah Standard [802.1ah]
LMP Link Management Protocol
MAC Media Access Control
MP2MP Multipoint to multipoint
NMS Network Management System
OAM Operations, Administration, and Maintenance
PBB Provider Backbone Bridges [802.1ah]
PBB-TE Provider Backbone Bridges Traffic Engineering
[802.1Qay]
P2P Point to Point
P2MP Point to Multipoint
QoS Quality of Service
SMAC Source MAC Address
S-TAG A Service TAG defined in the IEEE 802.1 Standard
[802.1Q]
TE Traffic Engineering
TAG An Ethernet short form for a TAG Header
TAG Header An extension to an Ethernet frame carrying
priority and other information
TSpec Traffic specification
VID VLAN Identifier
VLAN Virtual LAN2. Background 🌸
this section gives you the background on the types of switching and services that are supported within the defined framework. The switching part is especially important, because it identifies the switching functions that GMPLS will need to represent and control. The goal is for this document to allow for all standard forms of Ethernet switching and services 🧚
the material in this section is based on both finished and ongoing work taking place in the IEEE 802.1 Working Group, the ITU-T, and the MEF. This section references and, to some degree, summarizes that work. It is not a replacement for or an authoritative description of that work 🙏
2.1. Ethernet Switching 🦋
in Ethernet switching terminology, the bridge relay is responsible for forwarding and replicating the frames. Bridge relays forward frames based on the Ethernet header fields: Virtual Local Area Network (VLAN) Identifiers (VIDs) and Destination Media Access Control (DMAC) address. PBB [802.1ah] has also introduced a Service Instance tag (I-TAG). Across all the Ethernet extensions (already referenced in the Introduction), multiple forwarding functions, or service interfaces, have been defined using the combination of VIDs, DMACs, and I-TAGs. PBB [802.1ah] provides a breakdown of the different types of Ethernet switching services, and Figure 1 reproduces that breakdown 🍓
PBB Network
Service Types
_,,-' | '--.._
_,.-'' | `'--.._
_,.--' | `'--..
Port based S-tagged I-tagged
_,- -.
_.' `.
_,' `.
one-to-one bundled
_.- =.
_.-' ``-.._
_.-' `-..
many-to-one all-to-one
|
|
|
Transparent
Figure 1: Ethernet Switching Service Typesthe switching types are defined in Clause 25 of [802.1ah]. While not specifically described in [802.1ah], the Ethernet services being defined in the context of [MEF.6] and [G.8011] also fall into the types defined in Figure 1 (with the exception of the newly defined I-tagged service type).
[802.1ah] defines a new I-tagged service type but does not specifically define the Ethernet services being defined in the context of [MEF.6] and [G.8011], which are also illustrated in Figure 1.
to summarize the definitions:
- Port based: this is a frame-based service that supports specific frame types; no Service VLAN tagging or MAC-address-based switching 🎀
- S-tagged: there are multiple S-TAG-aware services, including:
- one-to-one: in this service, each VLAN identifier (VID) is mapped into a different service 💅
- bundled: bundled S-tagged service supports the mapping of multiple VIDs into a single service and includes:
- many-to-one: in this frame-based service, multiple VIDs are mapped into the same service 🫧
- all-to-one: in this frame-based service, all VIDs are mapped into the same service
- transparent: this is a special case, where all frames are mapped from a single incoming port to a single destination Ethernet port 🔥
- I-tagged: the edge of a PBBN consists of a combined backbone relay (B-component relay) and service instance relay (I-component relay). An I-TAG contains a service identifier (24-bit I-SID) and priority markings as well as some other fields. An I-tagged service is typically between the edges of the PBBN and terminated at each edge on an I-component that faces a customer port, so the service is often not visible except at the edges. However, since the I-component relay involves a distinct relay, it is possible to have a visible I-tagged Service by separating the I-component relay from the B-component relay. Two examples where it makes sense to do this are an I-tagged service between two PBBNs and as an attachment to a customer's Provider Instance Port 🌈
in general, the different switching types determine which of the Ethernet header fields are used in the forwarding/switching function, e.g., VID only or VID and DMACs. The switching type may also require the use of additional Ethernet headers or fields. Services defined for UNIs tend to use the headers for requesting service (service delimiter), and they are relevant between the customer site and network edge 🛣️
in most bridging cases, the header fields cannot be changed, but some translations of VID field values are permitted, typically at the network edges 🔁
across all service types, the Ethernet data plane is bidirectional congruent. This means that the forward and reverse paths share the exact same set of nodes, ports, and bidirectional links. This property is fundamental. The 802.1 group has maintained this bidirectional congruent property in the definition of Connectivity Fault Management (CFM), which is part of the overall OAM capability 🪞
2.2. Operations, Administration, and Maintenance (OAM) 💅
robustness is enhanced with the addition of data-plane OAM, which provides both fault and performance management 🛡️
Ethernet OAM messages ([802.1ag] and [Y.1731]) rely on data-plane forwarding for both directions. Determining a broken path or misdirected packet in this case relies on OAM following the Eth-LSP. These OAM message identifiers are dependent on the data plane, so they work equally well for provisioned or GMPLS-controlled paths 🔍
Ethernet OAM currently consists of:
Defined in both [802.1ag] and [Y.1731]:
- CCM/RDI: Continuity Check Message / Remote Defect Indication
- LBM/LBR: Loopback Message/Reply
- LTM/LTR: Link Trace Message/Reply
- VSM/VSR: Vendor-Specific Message/Reply
Additionally defined in [Y.1731]:
- AIS: Alarm Indication Signal
- LCK: Locked Signal
- TST: Test
- LMM/LMR: Loss Measurement Message/Reply
- DM: Delay Measurement
- DMM/DMR: Delay Measurement Message/Reply
- EXM/EXR: Experimental Message/Reply
- APS, MCC: Automatic Protection Switching, Maintenance
Communication Channelthese functions are supported across all the standardized Eth-LSP formats 🌷
2.3. Ethernet Switching Characteristics ✨
Okay so Ethernet is kinda like MPLS 🎀 because it wraps up different packet and frame types for sending. In Ethernet, the stuff inside the wrapper is called MAC client data. The wrapper is an Ethernet MAC frame, with a header, a source address, a destination address, and an optional VLAN identifier, type, and length up front, then the MAC client data with optional padding, and a Frame Check Sequence at the very end 💅
The type of MAC client data is usually marked with an "Ethertype" value. That's an explicit type indication 🫶 but Ethernet also supports an implicit type indication, so it's not a one-trick pony.
Ethernet bridging switches based on a frame's destination MAC address and VLAN 🦋 The VLAN is what defines a virtual active set of bridges and LANs. The address is assumed to be unique and invariant within the VLAN. MAC addresses are often globally unique, but that isn't necessary for bridging, so don't panic if they aren't 🙈
3. Framework 🧚
So the GMPLS architecture [RFC3945] says the GMPLS control plane can be applied to a technology just by controlling that technology's data-plane and switching characteristics. The GMPLS architecture, per [RFC3945], already allowed for control of Ethernet bridges and other Layer 2 technologies using the Layer-2 Switch Capable (L2SC) switching type. BUT the control of Ethernet switching was not explicitly defined in [RFC3471], [RFC4202], or any other GMPLS reference document after them 😭
The GMPLS architecture has a clear separation between a control plane and a data plane 🌸 That separation lets the GMPLS control plane stay architecturally and functionally unchanged while it controls different technologies. The architecture also requires IP connectivity so the control plane can exchange information, but it doesn't otherwise require an IP data plane.
All aspects of GMPLS, i.e., addressing, signaling, routing and link management, may be applied to Ethernet switching. GMPLS can provide control for traffic-engineered and protected Ethernet service paths. This document defines the term "Eth-LSP" to refer to Ethernet service paths that are controlled via GMPLS. As with all GMPLS controlled services, Eth-LSPs can leverage common traffic engineering attributes such as:
- bandwidth profile;
- forwarding priority level;
- connection preemption characteristics;
- protection/resiliency capability;
- routing policy, such as an explicit route;
- bidirectional service;
- end-to-end and segment protection;
- hierarchy
The bandwidth profile may be used to set the committed information rate, peak information rate, and policies based on either under-subscription or over-subscription. Services covered by this framework will use a TSpec that follows the Ethernet Traffic parameters defined in [ETH-TSPEC] 💜
When we apply GMPLS to "transport" Ethernet, GMPLS will need to be extended to work with the Ethernet data plane and switching functions. The definition of GMPLS support for Ethernet is multifaceted, because the different service types discussed in Section 2.1 have different forwarding and switching functions. In general, header fields used in the forwarding/switching function, e.g., VID and DMAC, can be characterized as a data-plane label. In some circumstances these fields will be constant along the path of the Eth-LSP, and in others they may vary hop-by-hop, or only at certain interfaces along the path. When the "labels" must be forwarded unchanged, there are a few constraints on label allocation that are similar to some other technologies, such as lambda labels 🦋
The characteristics of the "transport" Ethernet data plane are not modified in order to apply GMPLS control. For example, look at the IEEE 802.1Q [802.1Q] data plane: the VID is used as a "filter" pointing to a particular forwarding table, and if the DMAC is found in that forwarding table, the forwarding decision is made based on the DMAC. When forwarding using a spanning tree, if the DMAC is not found, the frame is broadcast over all outgoing interfaces for which that VID is defined. This valid MAC checking and broadcast supports Ethernet learning. A special case is when a VID is defined for only two ports on one bridge, which effectively results in a P2P forwarding constraint. In this case, all frames tagged with that VID and received over one of these ports are forwarded over the other port without address learning 👑
[802.1Qay] allows learning to be turned off, and hence the broadcast mechanism that comes with it, which provides a means to create explicitly routed Ethernet connections ✨
This document does not define any specific format for an Eth-LSP label. Instead, it's expected that service-specific documents will define any signaling and routing extensions needed to support a specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS protocol extensions and procedures. It's expected that all such extensions will be consistent with this document 🫶
It's expected that a key requirement for service-specific documents will be describing label formats and encodings. It may also be necessary to provide a mechanism to identify the required Ethernet service type in signaling, and a way to advertise the capabilities of Ethernet switches in the routing protocols. These mechanisms must make it possible to distinguish between requests for different paradigms, including new, future, and existing paradigms 💖
The Switching Type and Interface Switching Capability Descriptor share a common set of values, and they're defined in [RFC3945], [RFC3471], and [RFC4202] as indicators of the type of switching that should ([RFC3471]) and can ([RFC4202]) be performed on a particular link for an LSP. The L2SC switching type may already be used by implementations performing Layer 2 Switching, including Ethernet. So, to allow continued use of that switching type and those implementations, and to tell the different Ethernet switching paradigms apart, a new switching type needs to be defined for each new Ethernet switching paradigm that is supported 🌈
For discussion purposes, we break the problem of applying GMPLS into the functions of routing, signaling, link management, and path selection. It's possible to use some functions of GMPLS alone or in partial combinations. In most cases, using all functions of GMPLS leads to less operational overhead than partial combinations 🍓
4. GMPLS Routing and Addressing Model 🌷
The GMPLS routing and addressing model is not modified by this document 💅 GMPLS control for Eth-LSPs uses the routing and addressing model described in [RFC3945]. Most notably, this includes the use of IP addresses to identify interfaces and LSP end-points. It also includes support for both numbered and unnumbered interfaces.
If another address family or type of identifier is required to support an Ethernet service, extensions may be defined to provide a mapping to an IP address. Support of Eth-LSPs is expected to strictly comply with the GMPLS protocol suite addressing as specified in [RFC3471], [RFC3473], and related documents 🎀
4.1. GMPLS Routing
GMPLS routing as defined in [RFC4202] uses IP routing protocols with opaque TLV extensions to distribute GMPLS-related TE (router and link) information. As is always the case with GMPLS, TE information is populated based on resource information obtained from LMP or from configured information. The bandwidth resources of the links are tracked as Eth-LSPs are set up. Interfaces that support switching of Eth-LSPs are identified using the appropriate Interface Switching Capabilities (ISC) Descriptor. As mentioned in Section 3, one or more new ISCs are expected to be defined to support Eth-LSPs. Again, the L2SC ISCs will not be used to represent interfaces capable of supporting Eth-LSPs defined by this document and subsequent documents supporting the transport Ethernet switching paradigms 🚫 In addition, ISC-specific TE information may be defined as needed to meet the requirements of a specific Ethernet Switching Service Type.
GMPLS routing is an optional functionality, but it's super valuable for keeping the topology maintained and distributing the TE database for path management and dynamic path computation 🧠✨
4.2. Control Plane Network
For a GMPLS control plane to operate, you need an IP connectivity network with sufficient capacity to handle the information exchange of the GMPLS routing and signaling protocols 🌐
One way to do this is an IP-routed network supported by an IGP that views each switch as a terminated IP adjacency. In other words, IP traffic and a simple routing table are available for the control plane, but there's no requirement for a high-performance IP data plane, or for forwarding user traffic over this IP network 🫧
This IP connectivity can be provided as a separate, independent network (out-of-band), or integrated with the Ethernet switches (in-band) 🍭
5. GMPLS Signaling 💌
GMPLS signaling ([RFC3471] and [RFC3473]) is well suited to controlling Eth-LSPs and Ethernet switches. Signaling provides the ability to dynamically establish a path from an ingress node to an egress node. The signaled path may be completely static and not change for the duration of its lifetime. However, signaling can also dynamically adjust the path in a coordinated fashion after the path has been established. The range of signaling options, from static to dynamic, is under operator control. Standardized signaling also improves multi-vendor interoperability 🤝
GMPLS signaling supports the establishment and control of bidirectional and unidirectional data paths. Ethernet is bidirectional by nature, and CFM has been built to leverage this. Prior to CFM, the emulation of a physical wire and the learning requirements also mandated bidirectional connections. Given this, Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full and partial LSP protection; see [RFC4872] and [RFC4873] 🛡️
Note that standard GMPLS does not support different bandwidth in each direction of a bidirectional LSP. [RFC5467], an Experimental document, provides procedures if asymmetric bandwidth bidirectional LSPs are required 🔥
6. Link Management ✨
okay so link discovery is already specified for links connecting IEEE 802.1 bridges in [802.1AB] 💖 and ngl, running discovery in big systems is giving major benefits. It can cut down on configuration work, it lowers the chance of undetected config errors, and it exposes misconnections 🙈. BUT 802.1AB is an optional feature, so it isn't necessarily running before a link is operational, and it mainly supports the management plane 🫶.
In the GMPLS context, LMP [RFC4204] was defined to handle GMPLS control-plane link management and discovery 🦋. LMP also supports the automated creation of unnumbered interfaces for the control plane, which is so helpful ✨. If LMP is not used, there's an extra configuration requirement for GMPLS link identifiers. For large-scale implementations, LMP is beneficial 💅. LMP also has optional fault management capabilities, mainly for opaque and transparent network technology. With IEEE's newer CFM [802.1ag] and ITU-T's capabilities [Y.1731], this optional capability may not be needed 🤷♀️. The whole goal of the GMPLS Ethernet architecture is to let you pick the best tool set for your user needs 🌈. The full functionality of Ethernet CFM should be supported when using a GMPLS control plane 💜.
LMP and 802.1AB are pretty independent of each other. The LMP capability should be sufficient to remove the need for 802.1AB, but 802.1 AB can be run in parallel or independently if you want 🌸. Figure 2 shows possible ways of combining LMP, 802.1AB, and 802.1ag 🎀.
Figure 2 shows the functional relationship between link management and OAM schemes. LMP is expected to be used for control-plane functions of link property correlation, while Ethernet OAM mechanisms like CFM, link trace, etc., would handle data-plane fault management and fault trace 🧚.
+-------------+ +-------------+
| +---------+ | | +---------+ |
| | | | | | | |GMPLS
| | LMP |-|<------>|-| LMP | |Link Property
| | | | | | | |Correlation
| | (opt) | |GMPLS | | (opt) | |
| | | | | | | | Bundling
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | | | | | | |
| | 802.1AB |-|<------>|-| 802.1AB | |P2P
| | (opt) | |Ethernet| | (opt) | |link identifiers
| | | | | | | |
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | | | | | | |End-to-End
-----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
| | Y.1731 | |Ethernet| | Y.1731 | |Fault Management
| | (opt) | | | | (opt) | |Performance
| | | | | | | |Management
| +---------+ | | +---------+ |
+-------------+ +-------------+
Switch 1 link Switch 2
Figure 2: Logical Link Management Options7. Path Computation and Selection
GMPLS doesn't pin down one specific method for selecting paths or supporting path computation 🗺️. It's super flexible, going from very simple path computation all the way to very elaborate path coordination where tons of coordinated paths are needed 💅. Path computation can happen in a fully distributed way, on a management station with local computation for rerouting, or on more sophisticated path computation servers ✨.
Eth-LSPs may be supported using any path selection or computation mechanism 🫶. As with any GMPLS path selection function, and common to all path selection mechanisms, the path selection process should take into consideration the Switching Capabilities and Encoding advertised for a particular interface 💖. Eth-LSPs may also make use of the emerging path computation element and selection work; see [RFC4655] 🦋.
8. Multiple VLANs
This document allows for signaling Ethernet parameters across multiple VLANs, supporting both contiguous Eth-LSPs and Hierarchical Ethernet LSPs 🌈. The idea is to reuse the GMPLS hierarchy to support peer-to-peer models, UNIs, and NNIs 👑.
9. Security Considerations
Okay, this part is serious, bestie 😭🔒. A GMPLS-controlled "transport" Ethernet system should assume that users and devices attached to UNIs may behave maliciously, negligently, or incorrectly 💀. Intra-provider control traffic is trusted to not be malicious. Generally, these requirements are no different from the security requirements for operating any GMPLS network. Access to the trusted network will only happen through the protocols defined for the UNI or 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, data-plane security is decoupled from the control plane, so 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 mitigating Ethernet denial-of-service attacks may be required on UNI ports 🚨.
For a more comprehensive discussion on GMPLS security, check out the MPLS and GMPLS Security Framework [SECURITY] 📚. Cryptography can be used to protect against many attacks described in [SECURITY] 🔐. One option for protecting "transport" Ethernet is 802.1AE Media Access Control Security [802.1AE], which provides encryption and authentication 💜. It is expected that solution documents will include a full analysis of the security issues that any protocol extensions introduce 🫶.
10. References
10.1. Normative References
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (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.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.10.2. Informative References
[802.1AB] "IEEE Standard for Local and Metropolitan Area Networks,
Station and Media Access Control Connectivity Discovery",
IEEE 802.1AB, 2009.
[802.1AE] "IEEE Standard for Local and metropolitan area networks
Media Access Control (MAC) Security", IEEE 802.1AE-2006,
August 2006.
[802.1ag] "IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks - Amendment 5:
Connectivity Fault Management", IEEE 802.1ag, 2007.
[802.1ah] "IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks - Amendment 6:
Provider Backbone Bridges", IEEE Std 802.1ah-2008, August
2008.
[802.1Q] "IEEE standard for Virtual Bridged Local Area Networks",
IEEE 802.1Q-2005, May 2006.
[802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks - Amendment 10:
Provider Backbone Bridge Traffic Engineering", IEEE Std
802.1Qay-2009, August 2009.
[ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", Work in
Progress, January 2010.
[G.8011] ITU-T Recommendation G.8011, "Ethernet over Transport -
Ethernet services framework", January 2009.
[G.8011.1] ITU-T Recommendation G.8011.1/Y.1307.1, "Ethernet private
line service", January 2009.
[G.8011.2] ITU-T Recommendation G.8011.2/Y.1307.2, "Ethernet virtual
private line service", January 2009.
[G.8031] ITU-T Recommendation G.8031, "Ethernet linear protection
switching", November 2009.
[MEF.6] The Metro Ethernet Forum MEF 6, "Ethernet Services
Definitions - Phase I", 2004.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[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.
[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.
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 5467, March 2009.
[SECURITY] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009.
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and
Mechanisms for Ethernet based Networks", February 2008.11. Acknowledgments
There were so many people involved in kicking off this work before this document existed 🙌. The GELS framework document and the PBB-TE extensions document were two big ones that helped shape and justify this work 💜. We acknowledge the work of the authors of these initial documents: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil Bitar 🫶🌟.
George Swallow contributed significantly to this document 👑.
Authors' Addresses
Don Fedyk Alcatel-Lucent Groton, MA, 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Loa Andersson Ericsson Phone: +46 10 717 52 13 EMail: loa.andersson@ericsson.com
📦 where this page comes from
- ietf: rfc5828 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms