RFC 3945
Generalized Multi-Protocol Label Switching (GMPLS) Architecture
RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture 🦋
Okay bestie, so the title block is giving us the main facts. The Network Working Group published this one, with E. Mannie, Ed. as the editor. It came out in October 2004 and sits in the Standards Track category. The title block doesn't list anything it obsoletes or updates. ✨
Status of this Memo
Okay so this is an Internet standards track protocol document 💅 It's here for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands in standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share it with everyone 🌸
Copyright Notice
Copyright (C) The Internet Society (2004) 🎀
Abstract
Okay, the future of data and transmission networks is going to be so iconic 😭 It'll have routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), and more. These all use Generalized Multi-Protocol Label Switching (GMPLS) to set up resources on the fly and to keep the network surviving with protection and restoration techniques 🔥
This document walks through the architecture of GMPLS. GMPLS extends MPLS so it covers time-division switching (SONET/SDH, PDH, G.709), wavelength switching (lambdas), and spatial switching (for example, going from an incoming port or fiber to an outgoing port or fiber) 🌈 The main focus is the control plane for these layers, since each one can run on physically different data or forwarding planes 💜 The goal is to cover both the signaling and the routing parts of that control plane ✨
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acronyms & Abbreviations. . . . . . . . . . . . . . . . 4
1.2. Multiple Types of Switching and Forwarding Hierarchies. 5
1.3. Extension of the MPLS Control Plane . . . . . . . . . . 7
1.4. GMPLS Key Extensions to MPLS-TE . . . . . . . . . . . . 10
2. Routing and Addressing Model. . . . . . . . . . . . . . . . . 11
2.1. Addressing of PSC and non-PSC layers. . . . . . . . . . 13
2.2. GMPLS Scalability Enhancements. . . . . . . . . . . . . 13
2.3. TE Extensions to IP Routing Protocols . . . . . . . . . 14
3. Unnumbered Links. . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Unnumbered Forwarding Adjacencies . . . . . . . . . . . 16
4. Link Bundling . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Restrictions on Bundling. . . . . . . . . . . . . . . . 17
4.2. Routing Considerations for Bundling . . . . . . . . . . 17
4.3. Signaling Considerations. . . . . . . . . . . . . . . . 18
4.3.1. Mechanism 1: Implicit Indication. . . . . . . . 18
4.3.2. Mechanism 2: Explicit Indication by Numbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.3.3. Mechanism 3: Explicit Indication by Unnumbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.4. Unnumbered Bundled Link . . . . . . . . . . . . . . . . 19
4.5. Forming Bundled Links . . . . . . . . . . . . . . . . . 20
5. Relationship with the UNI . . . . . . . . . . . . . . . . . . 20
5.1. Relationship with the OIF UNI . . . . . . . . . . . . . 21
5.2. Reachability across the UNI . . . . . . . . . . . . . . 21
6. Link Management . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Control Channel and Control Channel Management. . . . . 23
6.2. Link Property Correlation . . . . . . . . . . . . . . . 24
6.3. Link Connectivity Verification. . . . . . . . . . . . . 24
6.4. Fault Management. . . . . . . . . . . . . . . . . . . . 25
6.5. LMP for DWDM Optical Line Systems (OLSs). . . . . . . . 26
7. Generalized Signaling . . . . . . . . . . . . . . . . . . . . 27
7.1. Overview: How to Request an LSP . . . . . . . . . . . . 29
7.2. Generalized Label Request . . . . . . . . . . . . . . . 30
7.3. SONET/SDH Traffic Parameters. . . . . . . . . . . . . . 31
7.4. G.709 Traffic Parameters. . . . . . . . . . . . . . . . 32
7.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 33
7.6. Generalized Label . . . . . . . . . . . . . . . . . . . 34
7.7. Waveband Switching. . . . . . . . . . . . . . . . . . . 34
7.8. Label Suggestion by the Upstream. . . . . . . . . . . . 35
7.9. Label Restriction by the Upstream . . . . . . . . . . . 35
7.10. Bi-directional LSP. . . . . . . . . . . . . . . . . . . 36
7.11. Bi-directional LSP Contention Resolution. . . . . . . . 37
7.12. Rapid Notification of Failure . . . . . . . . . . . . . 37
7.13. Link Protection . . . . . . . . . . . . . . . . . . . . 38
7.14. Explicit Routing and Explicit Label Control . . . . . . 39
7.15. Route Recording . . . . . . . . . . . . . . . . . . . . 40
7.16. LSP Modification and LSP Re-routing . . . . . . . . . . 40
7.17. LSP Administrative Status Handling. . . . . . . . . . . 41
7.18. Control Channel Separation. . . . . . . . . . . . . . . 42
8. Forwarding Adjacencies (FA) . . . . . . . . . . . . . . . . . 43
8.1. Routing and Forwarding Adjacencies. . . . . . . . . . . 43
8.2. Signaling Aspects . . . . . . . . . . . . . . . . . . . 44
8.3. Cascading of Forwarding Adjacencies . . . . . . . . . . 44
9. Routing and Signaling Adjacencies . . . . . . . . . . . . . . 45
10. Control Plane Fault Handling. . . . . . . . . . . . . . . . . 46
11. LSP Protection and Restoration. . . . . . . . . . . . . . . . 47
11.1. Protection Escalation across Domains and Layers . . . . 48
11.2. Mapping of Services to P&R Resources. . . . . . . . . . 49
11.3. Classification of P&R Mechanism Characteristics . . . . 49
11.4. Different Stages in P&R . . . . . . . . . . . . . . . . 50
11.5. Recovery Strategies . . . . . . . . . . . . . . . . . . 50
11.6. Recovery mechanisms: Protection schemes . . . . . . . . 51
11.7. Recovery mechanisms: Restoration schemes. . . . . . . . 52
11.8. Schema Selection Criteria . . . . . . . . . . . . . . . 53
12. Network Management. . . . . . . . . . . . . . . . . . . . . . 54
12.1. Network Management Systems (NMS). . . . . . . . . . . . 55
12.2. Management Information Base (MIB) . . . . . . . . . . . 55
12.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.4. Fault Correlation Between Multiple Layers . . . . . . . 56
13. Security Considerations . . . . . . . . . . . . . . . . . . . 57
14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.1. Normative References. . . . . . . . . . . . . . . . . . 58
15.2. Informative References. . . . . . . . . . . . . . . . . 59
16. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 63
17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 68
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 691. Introduction ✨
This architecture covers the main building blocks you need to build a consistent control plane for multiple switching layers 🧚 It doesn't limit how those layers work together. You can use different models, like overlay, augmented, or integrated 💖 Also, each pair of neighboring layers can cooperate in different ways, so there are lots of combinations, and manufacturers and operators get to decide which ones they use 👑
The architecture also clearly separates the control plane from the forwarding plane 🌸 And it splits the control plane into two parts: the signaling plane, which holds the signaling protocols, and the routing plane, which holds the routing protocols 💅
This document generalizes the Multi-Protocol Label Switching (MPLS) architecture [RFC3031]. In some cases it might differ a little from that architecture, because non packet-based forwarding planes are now part of the picture 🦋 We're not going to re-explain concepts that are already in the current MPLS architecture, because that would be so repetitive 🙈 Instead, the goal is to describe the specific concepts of Generalized MPLS (GMPLS) 🎀
That said, some concepts here aren't part of the current MPLS architecture, but they apply to both MPLS and GMPLS. These are link bundling, unnumbered links, and LSP hierarchy 🌈 Since they came along with GMPLS and they're super important for running a GMPLS network, we're going to talk about them here 🔥
Here's how the rest of the document goes. We start with an intro to GMPLS. Then we present the specific GMPLS building blocks and show how they fit together to make a working GMPLS network. The details of each building block live in the matching documents, so go there for the deep dives 🫶
1.1. Acronyms & Abbreviations 💜
Here's the acronym cheat sheet, so you're never lost in the alphabet soup 🍓
AS Autonomous System
BGP Border Gateway Protocol
CR-LDP Constraint-based Routing LDP
CSPF Constraint-based Shortest Path First
DWDM Dense Wavelength Division Multiplexing
FA Forwarding Adjacency
GMPLS Generalized Multi-Protocol Label Switching
IGP Interior Gateway Protocol
LDP Label Distribution Protocol
LMP Link Management Protocol
LSA Link State Advertisement
LSR Label Switching Router
LSP Label Switched Path
MIB Management Information Base
MPLS Multi-Protocol Label Switching
NMS Network Management System
OXC Optical Cross-Connect
PXC Photonic Cross-Connect
RSVP ReSource reserVation Protocol
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Networks
STM(-N) Synchronous Transport Module (-N)
STS(-N) Synchronous Transport Signal-Level N (SONET)
TDM Time Division Multiplexing
TE Traffic Engineering1.2. Multiple Types of Switching and Forwarding Hierarchies ✨
Okay so, GMPLS is basically traditional MPLS with a major glow-up 🦋 because it supports multiple types of switching. That means it adds TDM, lambda, and fiber (port) switching on top of the usual stuff. Adding those new switching types meant GMPLS had to stretch some base MPLS functions and, in a few places, add brand-new ones 💅. It touches the core LSP properties too: how labels get requested and communicated, the unidirectional nature of LSPs, how errors get propagated, and the info used to sync the ingress and egress LSRs. Main character energy, honestly 👑.
The MPLS architecture [RFC3031] was built around forwarding data based on a label 🎀. In that picture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that can (a) recognize either packet or cell boundaries, and (b) process either packet headers (for LSRs that can recognize packet boundaries) or cell headers (for LSRs that can recognize cell boundaries).
Now this doc extends the original MPLS architecture to cover LSRs whose forwarding plane recognizes neither packet nor cell boundaries 😭. That means they can't forward data based on the info in packet or cell headers. Think devices that make switching decisions based on time slots, wavelengths, or physical ports. So these new LSRs (or, more precisely, their interfaces) get sorted into five classes:
- Packet Switch Capable (PSC) interfaces:
Interfaces that recognize packet boundaries and can forward data based on the content of the packet header. Examples include interfaces on routers that forward data based on the content of the IP header, and interfaces on routers that switch data based on the content of the MPLS "shim" header 🧚.
- Layer-2 Switch Capable (L2SC) interfaces:
Interfaces that recognize frame/cell boundaries and can switch data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that switch data based on the content of the MAC header, and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI 🌸.
- Time-Division Multiplex Capable (TDM) interfaces:
Interfaces that switch data based on the data's time slot in a repeating cycle ⏰. An example is the interface of a SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop Multiplexer (ADM). Other examples include interfaces providing G.709 TDM capabilities (the "digital wrapper") and PDH interfaces.
- Lambda Switch Capable (LSC) interfaces:
Interfaces that switch data based on the wavelength on which the data is received 🌈. An example is the interface of a Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can operate at the level of an individual wavelength. Additional examples include PXC interfaces that can operate at the level of a group of wavelengths (i.e., a waveband), and G.709 interfaces providing optical capabilities.
- Fiber-Switch Capable (FSC) interfaces:
Interfaces that switch data based on a position of the data in the (real world) physical spaces 🌍. An example is a PXC or OXC that can operate at the level of a single fiber or multiple fibers.
A circuit can be established only between, or through, interfaces of the same type 🔒. Depending on the technology used for each interface, different circuit names can be used, e.g., SDH circuit, optical trail, light-path, etc. But in the context of GMPLS, all of these circuits get one common name: Label Switched Path (LSP) 💜.
The concept of nested LSP (LSP within LSP) was already around in traditional MPLS, and it makes building a forwarding hierarchy (a hierarchy of LSPs) possible 🪆. This hierarchy can happen on the same interface, or between different interfaces.
For example, a hierarchy can be built if an interface can multiplex several LSPs from the same technology (layer) 🍓. Say a lower order SONET/SDH LSP (e.g., VT2/VC-12) gets nested in a higher order SONET/SDH LSP (e.g., STS-3c/VC-4). Several levels of signal (LSP) nesting are defined in the SONET/SDH multiplexing hierarchy.
Nesting can also happen between interface types 🫶. At the top of the hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by L2SC, and then PSC interfaces. So an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on an L2SC interface. That LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. That one can be nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on an FSC interface. It's a whole nesting doll situation and I'm obsessed 🪆💖
1.3. Extension of the MPLS Control Plane ✨
okay so the original MPLS and/or MPLS-TE control planes already cover LSPs that span only Packet Switch Capable (PSC) or Layer-2 Switch Capable (L2SC) interfaces 🌸 GMPLS stretches those control planes so they can handle each of the five classes of interfaces (i.e., layers) from the previous section 💅
Note that the GMPLS control plane supports an overlay model, an augmented model, and a peer (integrated) model 🦋 In the near term, GMPLS looks very suitable for controlling each layer independently, and this elegant approach will make it easier to deploy the other models later 💖
The GMPLS control plane is built from several building blocks, which get more detail in the following sections 🧚 These building blocks are based on well-known signaling and routing protocols that have been extended and/or modified for GMPLS. They use IPv4 and/or IPv6 addresses. Only one new specialized protocol is required to support GMPLS operations, a signaling protocol for link management [LMP] 🔥
GMPLS is indeed based on the Traffic Engineering (TE) extensions to MPLS, a.k.a. MPLS-TE [RFC2702], and that's because most of the technologies that can be used below the PSC level need some traffic engineering 🎀 Placing LSPs at these levels generally means considering several constraints (such as framing, bandwidth, protection capability, etc) and bypassing the legacy Shortest-Path First (SPF) algorithm 😭 Note, however, that this is not mandatory, and in some cases SPF routing can be applied 🍓
To make constraint-based SPF routing of LSPs work, nodes that set up LSPs need more information about the links in the network than standard intra-domain routing protocols provide 🌈 These TE attributes get distributed using the transport mechanisms already available in IGPs (e.g., flooding), and the LSP routing algorithm takes them into consideration ✨ Optimizing LSP routes may also need some external simulations using heuristics, which serve as input for the actual path calculation and LSP establishment process 🧠
By definition, a TE link is a representation, in the IS-IS/OSPF Link State advertisements and in the link state database, of certain physical resources and their properties between two GMPLS nodes 💜 TE Links are used by the GMPLS control plane (routing and signaling) to establish LSPs, so they're literally the main building blocks for the whole vibe 👑
Extensions to traditional routing protocols and algorithms are needed to uniformly encode and carry TE link information, and explicit routes (e.g., source routes) are required in the signaling 🫶 The signaling also needs to carry the circuit (LSP) parameters, such as the bandwidth, the type of signal, the desired protection and/or restoration, the position in a particular multiplex, etc. Most of these extensions were already defined for PSC and L2SC traffic engineering with MPLS 💅 GMPLS mainly adds extensions for TDM, LSC, and FSC traffic engineering, and only a very few elements are technology specific 🌸
So GMPLS extends the two signaling protocols defined for MPLS-TE signaling, RSVP-TE [RFC3209] and CR-LDP [RFC3212] 🦋 However, GMPLS does not specify which one of these two signaling protocols must be used. It's up to manufacturers and operators to evaluate the two possible solutions for their own interest 🙈
Since GMPLS signaling is based on RSVP-TE and CR-LDP, it mandates downstream-on-demand label allocation and distribution, with ingress initiated ordered control 🔥 Liberal label retention is normally used, but conservative label retention mode could also be used ✨
Furthermore, there is no restriction on the label allocation strategy. It can be request/signaling driven (obvious for circuit switching technologies), traffic/data driven, or even topology driven 🌈 There is also no restriction on route selection. Explicit routing is normally used (strict or loose), but hop-by-hop routing could be used as well 🧚
GMPLS also extends two traditional intra-domain link-state routing protocols that were already extended for TE purposes, OSPF-TE [OSPF-TE] and IS-IS-TE [ISIS-TE] 💖 However, if explicit (source) routing is used, the routing algorithms used by these protocols no longer need to be standardized. Extensions for inter-domain routing (e.g., BGP) are for further study 👑
The use of technologies like DWDM (Dense Wavelength Division Multiplexing) means we can now have a very large number of parallel links between two directly adjacent nodes (hundreds of wavelengths, or even thousands of wavelengths if multiple fibers are used) 🤯 Such a large number of links wasn't originally considered for an IP or MPLS control plane, although it could be done. So some slight adaptations of that control plane are needed if we want to reuse it in the GMPLS context 🛠️
For instance, the traditional IP routing model assumes a routing adjacency gets established over each link connecting two adjacent nodes 🙈 Having that many adjacencies does not scale well. Each node has to maintain each of its adjacencies one by one, and link state routing information must be flooded throughout the network 😭
To solve this issue, the concept of link bundling was introduced 🎀 Also, manual configuration and control of these links, even if they are unnumbered, becomes impractical. That's why the Link Management Protocol (LMP) was specified 💅
LMP runs between data plane adjacent nodes and is used to manage TE links 🫶 Specifically, LMP provides mechanisms to maintain control channel connectivity (IP Control Channel Maintenance), verify the physical connectivity of the data-bearing links (Link Verification), correlate the link property information (Link Property Correlation), and manage link failures (Fault Localization and Fault Notification). A unique feature of LMP is that it can localize faults in both opaque and transparent networks (i.e., independent of the encoding scheme and bit rate used for the data) 🌟
LMP is defined in the context of GMPLS, but it is specified independently of the GMPLS signaling specification since it is a local protocol running between data-plane adjacent nodes 🧚 Consequently, LMP can be used in other contexts with non-GMPLS signaling protocols 💜
MPLS signaling and routing protocols require at least one bi-directional control channel to communicate, even if two adjacent nodes are connected by unidirectional links 🌈 Several control channels can be used, and LMP can be used to establish, maintain and manage these control channels 🦋
GMPLS does not specify how these control channels must be implemented, but GMPLS requires IP to transport the signaling and routing protocols over them 🎀 Control channels can be either in-band or out-of-band, and several solutions can be used to carry IP. Note also that one type of LMP message (the Test message) is used in-band in the data plane and may not be transported over IP, but this is a particular case, needed to verify connectivity in the data plane 🙈
1.4. GMPLS Key Extensions to MPLS-TE 👑
Some key extensions that GMPLS brings to MPLS-TE are highlighted below 💖 Some of them are key advantages of GMPLS for controlling the TDM, LSC, and FSC layers 🔥
- In MPLS-TE, links traversed by an LSP can include an intermix of links with heterogeneous label encoding (e.g., links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. GMPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the (real world) physical space. ✨
- In MPLS-TE, an LSP that carries IP has to start and end on a router. GMPLS extends this by requiring an LSP to start and end on similar type of interfaces. 🧚
- The type of payload that can be carried in GMPLS by an LSP is extended to allow payloads such as SONET/SDH, G.709, 1Gb or 10Gb Ethernet, etc. 🌈
- The use of Forwarding Adjacencies (FA) provides a mechanism that can improve bandwidth utilization when bandwidth allocation can be performed only in discrete units. It also offers a mechanism to aggregate forwarding state, which allows the number of required labels to be reduced. 🦋
- GMPLS allows an upstream node to suggest a label to reduce the setup latency. This suggestion may be overridden by a downstream node, but in some cases that comes at the cost of higher LSP setup time. 🎀
- GMPLS extends the notion of restricting the range of labels that may be selected by a downstream node. In GMPLS, an upstream node may restrict the labels for an LSP along either a single hop or the entire LSP path. This feature is useful in photonic networks where wavelength conversion may not be available. 💅
- While traditional TE-based (and even LDP-based) LSPs are unidirectional, GMPLS supports the establishment of bi-directional LSPs. 🫶
- GMPLS supports the termination of an LSP on a specific egress port, i.e., the port selection at the destination side. 🌸
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid failure notification. 🌟
Note also some other key differences between MPLS-TE and GMPLS 🙈
- For TDM, LSC, and FSC interfaces, bandwidth allocation for an LSP can be performed only in discrete units. 😭
- It is expected to have (much) fewer labels on TDM, LSC, or FSC links than on PSC or L2SC links, because the former are physical labels instead of logical labels. 🧠
2. Routing and Addressing Model ✨
okay so GMPLS borrows the IP routing and addressing models, bestie 🎀 IPv4 and/or IPv6 addresses identify interfaces, and the traditional (distributed) IP routing protocols get reused too. Honestly, that's the whole vibe: the topology and the resource state of every link in a routing domain get discovered through these routing protocols 🦋
Here's the tea 🫶 Since the control and data planes are de-coupled in GMPLS, your control-plane neighbors (aka IGP-learnt neighbors) might NOT be your data-plane neighbors. So you need mechanisms like LMP to link TE links up with the neighboring nodes. Not me needing a whole extra tool just to figure out who's who 💀
IP addresses aren't just for IP hosts and routers, either. They identify any PSC and non-PSC interfaces 🧚. Same deal with routing: IP routing protocols find routes for IP datagrams using an SPF algorithm, and they also find routes for non-PSC circuits using a CSPF algorithm. iconic, honestly.
BUT (and it's a big but 😭) some extra mechanisms are needed to make these models more scalable and to handle the specific traffic engineering requirements of non-PSC layers. We'll get into those next 💅
Re-using existing IP routing protocols is lowkey genius, because non-PSC layers get to take advantage of everything that's been developed for IP routing over the years. That's especially true for intra-domain routing (link-state routing) and inter-domain routing (policy routing) ✨
In an overlay model, each non-PSC layer can be seen as a set of Autonomous Systems (ASs) connected together in an arbitrary way. Just like regular IP routing, each AS is managed by a single administrative authority. For example, an AS can be a SONET/SDH network run by a given carrier, and a bunch of interconnected ASs can be viewed as SONET/SDH internetworks 🌸
Exchanging routing info between ASs can be done with an inter-domain routing protocol like BGP-4. There's obviously a HUGE value in reusing the well-known policy routing facilities BGP gives you in a non-PSC context 🔥 Extensions for BGP traffic engineering (BGP-TE) in non-PSC layers are left for further study, so that's a later problem 🙈
Each AS can be sub-divided into different routing domains, and each of those can run a different intra-domain routing protocol. Then each routing domain can be divided into areas 🍓
A routing domain is made of GMPLS enabled nodes (aka network devices that include a GMPLS entity) 🧚 These nodes can be edge nodes (hosts, ingress LSRs or egress LSRs) or internal LSRs. An example of a non-PSC host is a SONET/SDH Terminal Multiplexer (TM). Another example is a SONET/SDH interface card inside an IP router or ATM switch 💖
Traffic engineering in the intra-domain requires the use of link-state routing protocols like OSPF or IS-IS. No way around it, bestie ⭐
GMPLS defines extensions to these protocols 💜 They're needed to disseminate the specific TDM, LSC and FSC static and dynamic characteristics of nodes and links. The current focus is on intra-area traffic engineering, but inter-area traffic engineering is also being investigated 👑
2.1. Addressing of PSC and non-PSC Layers
The fact that IPv4 and/or IPv6 addresses are used doesn't imply AT ALL that they should be allocated in the same addressing space as the public IPv4 and/or IPv6 addresses used for the Internet 🙈 Private IP addresses can be used if they don't need to be exchanged with any other operator. Otherwise, public IP addresses are required. Of course, if an integrated model is used, the two layers could share the same addressing space 🦋
Finally, TE links may be "unnumbered", i.e., not have any IP addresses. That's useful if IP addresses aren't available, or if the overhead of managing them is considered too high 🌈
Note that there's a benefit to using public IPv4 and/or IPv6 Internet addresses for non-PSC layers if an integrated model with the IP layer is foreseen ✨
If we look at the scalability enhancements in the next section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing spaces are both more than sufficient to accommodate any non-PSC layer. We can reasonably expect to have far fewer non-PSC devices (e.g., SONET/SDH nodes) than we have IP hosts and routers today. So no stress 💅
2.2. GMPLS Scalability Enhancements
TDM, LSC and FSC layers introduce new constraints on the IP addressing and routing models, because several hundreds of parallel physical links (e.g., wavelengths) can now connect two nodes 😭 Most carriers already have several tens of wavelengths per fiber between two nodes today. New generations of DWDM systems will allow several hundreds of wavelengths per fiber 🔥
It becomes rather impractical to give an IP address to each end of each physical link, to represent each link as its own routing adjacency, and to advertise and maintain link states for each one of them 💀 So for that reason, GMPLS enhances the MPLS routing and addressing models to make them more scalable 🫶
Two optional mechanisms can be used to increase the scalability of addressing and routing: unnumbered links and link bundling. You can combine these two mechanisms too. They require extensions to the signaling protocols (RSVP-TE and CR-LDP) and the routing protocols (OSPF-TE and IS-IS-TE) 🌸
2.3. TE Extensions to IP Routing Protocols
Traditionally, a TE link is advertised as an adjunct to a "regular" OSPF or IS-IS link, i.e., an adjacency is brought up on the link. When the link is up, both the regular IGP properties of the link (basically, the SPF metric) and the TE properties of the link get advertised 🎀
But GMPLS challenges this notion in three ways 👑
- First, links that are non-PSC may still have TE properties. However, an OSPF adjacency couldn't be brought up directly on such links 🙈
- Second, an LSP can be advertised as a point-to-point TE link in the routing protocol, i.e., as a Forwarding Adjacency (FA). So an advertised TE link no longer has to be between two OSPF direct neighbors. Forwarding Adjacencies (FA) are described further in Section 8 🦋
- Third, a number of links may be advertised as a single TE link (e.g., for improved scalability). So once again, there's no longer a one-to-one association between a regular adjacency and a TE link 🧚
So we now have a more general notion of a TE link ✨ A TE link is a logical link that has TE properties. Some of these properties may be configured on the advertising LSR, others may be obtained from other LSRs through some protocol, and yet others may be deduced from the component(s) of the TE link 💖
An important TE property of a TE link is related to the bandwidth accounting for that link. GMPLS will define different accounting rules for different non-PSC layers 🌈 Generic bandwidth attributes are still defined by the TE routing extensions and by GMPLS, though. Examples are the unreserved bandwidth, the maximum reservable bandwidth and the maximum LSP bandwidth 💜
In a dynamic environment, frequent changes of bandwidth accounting information are expected 🔥 A flexible policy for triggering link state updates based on bandwidth thresholds and link-dampening mechanisms can be implemented 🫶
TE properties associated with a link should also capture protection and restoration related characteristics 🍓 For instance, shared protection can be elegantly combined with bundling ✨ Protection and restoration are mainly generic mechanisms that also apply to MPLS. They're expected to be developed for MPLS first and generalized to GMPLS later on 🌸
A TE link between a pair of LSRs does NOT imply the existence of an IGP adjacency between those LSRs 🙈 A TE link must also have some means by which the advertising LSR can know it's alive (e.g., by using LMP hellos) 💅 When an LSR knows that a TE link is up and can determine its TE properties, the LSR may then advertise that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE objects/TLVs. The interfaces where GMPLS enhanced OSPF or IS-IS adjacencies get established are called "control channels" 🎀
3. Unnumbered Links
Unnumbered links (or interfaces) are links (or interfaces) that don't have IP addresses 🦋 Using them involves two capabilities: being able to specify unnumbered links in MPLS TE signaling, and being able to carry (TE) information about unnumbered links in the IGP TE extensions of IS-IS-TE and OSPF-TE 🫶
A. The ability to specify unnumbered links in MPLS TE signaling requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480] 💖 MPLS-TE signaling doesn't support unnumbered links by default, because there's no way to indicate an unnumbered link in its Explicit Route Object/TLV or in its Record Route Object (there's no such TLV for CR-LDP) 😭 GMPLS defines simple extensions to indicate an unnumbered link in these two Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub-TLV ✨
Since unnumbered links aren't identified by an IP address, each end needs some other identifier for MPLS TE purposes, one that's local to the LSR the link belongs to 🧚 LSRs at the two end-points of an unnumbered link exchange the identifiers they assign to the link with each other. This can happen by configuration, by means of a protocol such as LMP ([LMP]), by means of RSVP-TE/CR-LDP (especially when the link is a Forwarding Adjacency, see below), or by means of IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]) 🌈
Let's use an example 🍓 Say there's an (unnumbered) link between LSRs A and B. LSR A picks an identifier for that link, and so does LSR B. From A's perspective, the identifier A assigned to the link is called the "link local identifier" (or just "local identifier"), and the identifier B assigned to the link is called the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective, the identifier B assigned is the local identifier, and the identifier A assigned is the remote identifier 💜
The new Unnumbered Interface ID sub-object/sub-TLV for the ER Object/TLV contains the Router ID of the LSR at the upstream end of the unnumbered link, plus the link local identifier with respect to that upstream LSR 👑
The new Unnumbered Interface ID sub-object for the RR Object contains the link local identifier with respect to the LSR that adds it to the RR Object 🫶
B. The ability to carry (TE) information about unnumbered links in IGP TE extensions requires new sub-TLVs for the extended IS reachability TLV defined in IS-IS-TE, and for the TE LSA (which is an opaque LSA) defined in OSPF-TE 🦋 Two sub-TLVs are defined for this: a Link Local Identifier sub-TLV and a Link Remote Identifier sub-TLV 🔥
3.1. Unnumbered Forwarding Adjacencies 🦋
okay so if an LSR that originates an LSP advertises it as an unnumbered FA in IS-IS or OSPF, or uses this FA as an unnumbered component link of a bundled link, that LSR must allocate an Interface ID to the FA. if the LSP is bi-directional, the tail end does the same thing and allocates an Interface ID to the reverse FA. 💖
signaling got a glow-up too 💅 it can now carry the Interface ID of a FA in the new LSP Tunnel Interface ID object/TLV. this object/TLV holds the Router ID (of the LSR that generates it) plus the Interface ID. when it shows up in a Path/REQUEST message it's the Forward Interface ID, and when it shows up in the Resv/MAPPING message it's the Reverse Interface ID 🧚
4. Link Bundling ✨
the concept of link bundling is essential in certain networks that use the GMPLS control plane, as defined in [BUNDLE]. picture an optical meshed network where neighbouring optical cross-connects (LSRs) are linked by several hundreds of parallel wavelengths 🌈 in that kind of network, you'd look at link state routing protocols like OSPF or IS-IS, with suitable extensions for resource discovery and dynamic route computation. each wavelength has to be advertised separately to be used, unless link bundling is in play.
when a pair of LSRs is connected by multiple links, you can advertise several (or all) of those links as a single link into OSPF and/or IS-IS. that's called link bundling, or just bundling 🎀 the resulting logical link is a bundled link, and its physical links are called component links (identified by interface indexes).
a combination of three identifiers ((bundled) link identifier, component link identifier, label) is enough to unambiguously identify the resources an LSP uses. 🔥
the whole point of link bundling is better routing scalability, since there's less information for OSPF and/or IS-IS to handle. that works through information aggregation/abstraction. but literally any aggregation/abstraction loses some information, so to keep the losses small, you restrict what kind of information gets aggregated/abstracted. 🫶
4.1. Restrictions on Bundling 💅
the following restrictions are required for bundling links. all component links in a bundle must begin and end on the same pair of LSRs, and they must share some common characteristics or properties defined in [OSPF-TE] and [ISIS-TE]. that means they must have the same:
- Link Type (i.e., point-to-point or multi-access),
- TE Metric (i.e., an administrative cost),
- Set of Resource Classes at each end of the links (i.e., colors).
quick note: a FA can also be a component link ✨ a bundle can be a mix of point-to-point links and FAs, as long as they all share the same properties.
4.2. Routing Considerations for Bundling 🦋
a bundled link is just another kind of TE link, like the ones defined by [GMPLS-ROUTING]. the bundled link is alive whenever its component links are alive. it's alive when at least one of its component links is alive. a component link's liveness can be figured out in a few ways: IS-IS or OSPF hellos over the component link, RSVP Hello (hop local), LMP hellos (link local), or indications from layer 1 or layer 2 💖
heads up: according to the RSVP-TE specification [RFC3209], the RSVP Hello mechanism is meant for when notification of link layer failures isn't available and unnumbered links aren't used, or when the link layer's failure detection isn't good enough for timely node failure detection 👀
once a bundled link is alive, it can be advertised as a TE link and its TE information can be flooded. if IS-IS/OSPF hellos run over the component links, IS-IS/OSPF flooding can be limited to just one of the component links. 🌸
advertising a (bundled) TE link between a pair of LSRs does NOT mean there's an IGP adjacency between those LSRs tied to just that link. in some cases a TE link between a pair of LSRs can be advertised even with no IGP adjacency at all between them (for example, when the TE link is an FA). 🙈
forming a bundled link means aggregating the identical TE parameters of each component link into aggregated TE parameters. a TE link as defined by [GMPLS-ROUTING] has loads of parameters, and adequate aggregation rules have to be defined for each one 😭
some parameters can be sums of component characteristics, like the unreserved bandwidth and the maximum reservable bandwidth. bandwidth info is a big deal in a bundle advertisement, so it has to be clearly defined, since an abstraction is happening 💜
a GMPLS node with bundled links must apply admission control on a per-component link basis. 🔥
4.3. Signaling Considerations 🧚
typically, an LSP's explicit route (for example, one contained in an explicit route Object/TLV) picks the bundled link to be used for the LSP, but not the component link(s). that's because info about the bundled link gets flooded, but info about the component links doesn't 🍓
the upstream node is always the one that chooses the component link. if the LSP is bi-directional, the upstream node chooses a component link in each direction. 💅
there are three ways to tell the downstream node about that choice 👑
4.3.1. Mechanism 1: Implicit Indication ✨
this mechanism requires that each component link has a dedicated signaling channel (for example, the link is a Sonet/SDH link using the DCC for in-band signaling). the upstream node tells the receiver which component link to use by sending the message over the chosen component link's dedicated signaling channel. this signaling channel can be in-band or out-of-band. in the out-of-band case, the association between the signaling channel and that component link needs to be explicitly configured. 🌈
4.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID 🎀
this mechanism requires that the component link has a unique remote IP address. the upstream node indicates the choice of component link by including a new IF_ID RSVP_HOP object/IF_ID TLV that carries either an IPv4 or an IPv6 address in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively). for a bi-directional LSP, the upstream node provides a component link for each direction. 🦋
this mechanism doesn't require each component link to have its own control channel. it doesn't even require the whole (bundled) link to have its own control channel either 🫶
4.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID 💖
with this mechanism, each component link that's unnumbered gets a unique Interface Identifier (32 bits value). the upstream node indicates the choice of component link by including a new IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively).
this object/TLV carries the component interface ID in the downstream direction for a unidirectional LSP, and also the component interface ID in the upstream direction for a bi-directional LSP. ✨
the two LSRs at each end of the bundled link swap these identifiers. they can do that by configuration, by a protocol such as LMP (the preferred solution), by RSVP-TE/CR-LDP (especially when a component link is a Forwarding Adjacency), or by IS-IS or OSPF extensions. 🌸
this mechanism doesn't require each component link to have its own control channel, and it doesn't even require the whole (bundled) link to have its own control channel 🧚
4.4. Unnumbered Bundled Link 🎀
a bundled link can be numbered or unnumbered, no matter whether its component links are numbered or not. this affects how the bundled link gets advertised in IS-IS/OSPF and the format of LSP EROs that traverse the bundled link. 👀 also, the unnumbered Interface Identifiers for all unnumbered outgoing links of a given LSR (whether they're component links, Forwarding Adjacencies or bundled links) must be unique in the context of that LSR. 🔥
4.5. Forming Bundled Links 💜
the generic rule for bundling component links is to put links that are correlated in some way into the same bundle. if links can be correlated on multiple properties, bundling can be applied sequentially based on those properties. for instance, links might first be grouped on the first property, then each group is split into smaller groups based on the second property, and so on. the main principle here is that the properties of the resulting bundles should be concisely summarizable. link bundling can be done automatically or by configuration, and automatic bundling can apply the bundling rules one after another to produce bundles. 🫶
for example, the first property links could be correlated on might be the Interface Switching Capability [GMPLS-ROUTING]. the second could be the Encoding [GMPLS-ROUTING], the third could be the Administrative Weight (cost), the fourth could be the Resource Classes, and finally links may be correlated based on other metrics such as SRLG (Shared Risk Link Groups). 🌈
when routing an alternate path for protection, the general principle is that the alternate path isn't routed over any link that belongs to an SRLG that belongs to some link of the primary path. so the rule is to group links that belong to exactly the same set of SRLGs. 🛡️
this kind of sequential sub-division can result in a number of bundles between two adjacent nodes. in practice though, link properties may not vary much among component links between two adjacent nodes, so the number of bundles in practice may not be large. 🍓
5. Relationship with the UNI 👑
the interface between an edge GMPLS node and a GMPLS LSR on the network side may be called a User to Network Interface (UNI), while the interface between two network side LSRs may be called a Network to Network Interface (NNI). 🧚
GMPLS doesn't specify a UNI and an NNI separately. edge nodes connect to LSRs on the network side, and those LSRs connect to each other. of course, an edge node doesn't behave exactly like an LSR on the network side. also, an edge node may run a routing protocol, but in most cases it's expected not to (see also section 5.2 and the section about signaling with an explicit route) 💅
conceptually, a difference between UNI and NNI only makes sense if the two interfaces use completely different protocols, or if they use the same protocols with some outstanding differences. 🤔 in the first case, separate protocols are often defined one after another, with more or less success 😬
the GMPLS approach was to build a consistent model from day one, looking at both the UNI and NNI interfaces at the same time [GMPLS-OVERLAY]. for that reason, a very few specific UNI particularities were ignored at first. GMPLS has since been enhanced to support those particularities at the UNI through other standardization bodies (see hereafter). ✨💖
5.1. Relationship with the OIF UNI 🎀
okay so this bit is only here as a reference for the OIF work related to GMPLS, so don't panic 😭 The current OIF UNI specification [OIF-UNI] defines an interface between a client SONET/SDH equipment and a SONET/SDH network, and each one belongs to a different administrative authority. It's designed for an overlay model. The OIF UNI adds extra mechanisms on top of GMPLS for the UNI 💅
For example, OIF service discovery comes first before you can get any UNI services ✨ It lets a client find out the static parameters of the connection with the network, like the UNI signaling protocol, the type of concatenation, the transparency level, and the type of diversity (node, link, SRLG) the network supports 🦋
And since the current OIF UNI doesn't cover photonic networks, G.709 Digital Wrapper, etc, it's basically a subset of the GMPLS Architecture at the UNI 🌸
5.2. Reachability across the UNI 🧚
this section is about how an edge node picks an explicit route 👑 Picking the first LSR when an edge node is connected to multiple LSRs is part of that whole problem.
an edge node (a host or an LSR) can get involved in GMPLS routing more or less deeply 💜 There are four routing models that can be supported at the UNI: configuration based, partial peering, silent listening, and full peering. Let's go through them 🫶
- Configuration based: this model needs the edge node to be configured, manually or automatically, with a list of neighbor LSRs in preference order. Automatic configuration can be done with DHCP, for instance. No routing information gets exchanged at the UNI, except maybe that ordered list of LSRs. The only routing info the edge node uses is that list. By default, the edge node sends an LSP request to the preferred LSR. ICMP redirects could be sent by this LSR to redirect some LSP requests to another LSR connected to the edge node. GMPLS does not preclude that model 🍓
- Partial peering: limited routing information (mainly reachability) can be exchanged across the UNI using some extensions in the signaling plane. The reachability information exchanged at the UNI may be used to start an edge-node-specific routing decision over the network. GMPLS doesn't have any capability to support this model today 🥺
- Silent listening: the edge node can silently listen to routing protocols and make routing decisions based on what it learns. An edge node receives the full routing information, including the traffic engineering extensions. One LSR should forward all routing PDUs to the edge node transparently. An edge node can now compute a complete explicit route using all of the end-to-end routing information. GMPLS does not preclude this model ✨
- Full peering: on top of silent listening, the edge node takes part in the routing, establishes adjacencies with its neighbors, and advertises LSAs. This is only useful if there are benefits for edge nodes to advertise their own traffic engineering information. GMPLS does not preclude this model 💅
6. Link Management 🌈
okay this is where it gets spicy 🔥 In GMPLS, a pair of nodes (e.g., a photonic switch) may be connected by tens of fibers, and each fiber may carry hundreds of wavelengths if DWDM is used. Multiple fibers and/or multiple wavelengths may also be combined into one or more bundled links for routing purposes. And to let nodes talk to each other for routing, signaling, and link management, control channels must be set up between a node pair 🦋
Link management is a collection of useful procedures between adjacent nodes that provide local services like control channel management, link connectivity verification, link property correlation, and fault management ✨ The Link Management Protocol (LMP) [LMP] was defined to do these jobs. LMP started out in the context of GMPLS, but it's a generic toolbox that can be used in other contexts too 🧰
in GMPLS, the control channels between two adjacent nodes no longer have to use the same physical medium as the data links between those nodes 😭 The control channels that carry the GMPLS control-plane info also exist independently of the links they manage. So LMP was designed to manage the data links independently of the termination capabilities of those data links 💖
Control channel management and link property correlation procedures are mandatory per LMP. Link connectivity verification and fault management procedures are optional 🙈
6.1. Control Channel and Control Channel Management 🎀
LMP control channel management is used to set up and maintain control channels between nodes. Control channels exist independently of TE links, and they can be used to exchange MPLS control-plane information like signaling, routing, and link management info 💜
An "LMP adjacency" is formed between two nodes that support the same LMP capabilities. Multiple control channels may be active at the same time for each adjacency. A control channel can be either explicitly configured or automatically selected. However, LMP currently assumes that control channels are explicitly configured, while the configuration of the control channel capabilities can be dynamically negotiated 🫶
For the purposes of LMP, the exact implementation of the control channel is left unspecified 🌸 The control channel(s) between two adjacent nodes no longer has to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network 🧚
Here's the thing: letting the control channel(s) between two nodes be physically diverse from the associated data-bearing links means the health of a control channel doesn't necessarily correlate with the health of the data-bearing links, and vice versa 😳 That's why new mechanisms were developed in LMP to manage links, both for link provisioning and for fault isolation 👑
LMP doesn't specify the signaling transport mechanism used in the control channel. It does state that messages transported over a control channel must be IP encoded 💅 Since the messages are IP encoded, the link level encoding is not part of LMP. Each direction of a control channel is assigned a 32-bit non-zero integer Control Channel Identifier (CCId) 🍓
Each control channel negotiates its own control channel parameters individually and keeps connectivity up using a fast Hello protocol. The Hello protocol is required if lower-level mechanisms aren't available to detect link failures 🥺
The Hello protocol of LMP is meant to be a lightweight keep-alive mechanism that reacts to control channel failures rapidly, so that IGP Hellos aren't lost and the associated link-state adjacencies aren't removed for no reason ✨
The Hello protocol has two phases: a negotiation phase and a keep-alive phase 💖 The negotiation phase lets the nodes negotiate some basic Hello protocol parameters, like the Hello frequency. The keep-alive phase is a fast, lightweight, bi-directional Hello message exchange 🔥
If a group of control channels shares a common node pair and supports the same LMP capabilities, then LMP control channel messages (except Configuration messages and Hello messages) may be sent over any of the active control channels without coordination between the local and remote nodes 🦋
For LMP, it is essential that at least one control channel is always available 🫶 If a control channel fails, it may be possible to use an alternate active control channel without coordination 🌈
6.2. Link Property Correlation 💅
As part of LMP, a link property correlation exchange is defined ✨ The exchange is used to aggregate multiple data-bearing links (i.e., component links) into a bundled link, and to exchange, correlate, or change TE link parameters. The link property correlation exchange may be done at any time a link is up and is not in the Verification process (see next section) 🧚
It allows, for instance, adding component links to a link bundle, changing a link's minimum/maximum reservable bandwidth, changing port identifiers, or changing component identifiers in a bundle 💜 This mechanism is supported by an exchange of link summary messages 🎀
6.3. Link Connectivity Verification 🙈
Link connectivity verification is an optional procedure that may be used to verify the physical connectivity of data-bearing links, and also to exchange the link identifiers used in GMPLS signaling 🌸
This procedure should be performed initially when a data-bearing link is first established, and then periodically for all unallocated (free) data-bearing links 🍓
The verification procedure sends Test messages in-band over the data-bearing links. This requires that the unallocated links must be opaque 😭 But there are multiple degrees of opaqueness (e.g., examining overhead bytes, terminating the payload, etc.), so different mechanisms to transport the Test messages are specified too 💖 Note that the Test message is the only LMP message transmitted over the data-bearing link, and Hello messages keep being exchanged over the control channel during the link verification process 🥺 Data-bearing links are tested in the transmit direction because they're unidirectional. So it's possible for LMP neighboring nodes to exchange Test messages simultaneously in both directions 🔥
To start the link verification procedure, a node must first notify the adjacent node that it will begin sending Test messages over a particular data-bearing link, or over the component links of a particular bundled link ✨ The node must also indicate the number of data-bearing links to be verified, the interval at which the test messages will be sent, the encoding scheme, the transport mechanisms supported, and the data rate for Test messages. If the data-bearing links correspond to fibers, it must also indicate the wavelength over which the Test messages will be transmitted 🦋 At this same time, the local and remote bundled link identifiers are transmitted too, so the component link association with the bundled link identifiers can happen 🫶
6.4. Fault Management 🚨
Okay so fault management is a big deal from the operator side 😭 It usually covers three things: fault detection, fault localization, and fault notification. When something breaks and gets detected (fault detection), an operator needs to know exactly where it happened (fault localization), and a source node may need to be notified so it can take some action (fault notification). 🫶
Note that fault localization can also be used to support some specific (local) protection/restoration mechanisms ✨
In new tech like transparent photonic switching, there's currently no method defined to locate a fault 💀 so the mechanism that propagates the fault information has to be sent "out of band" (via the control plane). 🙈
LMP provides a fault localization procedure that can be used to rapidly localize link failures by notifying a fault up to the node upstream of that fault (i.e., through a fault notification procedure) 🦋
A downstream LMP neighbor that detects data link failures will send an LMP message to its upstream neighbor notifying it of the failure. When an upstream node gets a failure notification, it can correlate the failure with the corresponding input ports to figure out if the failure is between the two nodes. Once the failure has been localized, the signaling protocols can be used to initiate link or path protection/restoration procedures. 👑
6.5. LMP for DWDM Optical Line Systems (OLSs) 🌈
In an all-optical environment, LMP focuses on peer communications (e.g., OXC-to-OXC). A great deal of information about a link between two OXCs is known by the OLS (Optical Line System or WDM Terminal multiplexer). Exposing this info to the control plane can improve network usability by further reducing required manual configuration, and by greatly enhancing fault detection and recovery. It's giving efficiency 💅
LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC and an OLS. These extensions are intended to satisfy the Optical Link Interface Requirements described in [OLI-REQ] 🎀
Fault detection is especially an issue when the network is using all-optical photonic switches (PXC). Once a connection is established, PXCs have only limited visibility into the health of the connection 😩 Although the PXC is all-optical, long-haul OLSs typically terminate channels electrically and regenerate them optically. That gives us an opportunity to monitor the health of a channel between PXCs, and LMP-WDM can then be used by the OLS to provide this information to the PXC. Iconic 🧚
In addition to the link information known to the OLS that gets exchanged through LMP-WDM, some information known to the OXC may also be exchanged with the OLS through LMP-WDM. This is useful for alarm management and link monitoring (e.g., trace monitoring) 🔥 Alarm management matters because the administrative state of a connection, known to the OXC (e.g., this info may be learned through the Admin Status object of GMPLS signaling [RFC3471]), can be used to suppress spurious alarms. For example, the OXC may know that a connection is "up", "down", in a "testing" mode, or being deleted ("deletion-in-progress"). The OXC can use this to inhibit alarm reporting from the OLS when a connection is "down", "testing", or being deleted. Not the OLS spamming alarms when nothing's wrong 🙅♀️
It is important to note that an OXC may peer with one or more OLSs, and an OLS may peer with one or more OXCs 🍓 Although there are many similarities between an OXC-OXC LMP session and an OXC-OLS LMP session, particularly for control management and link verification, there are some differences too. These differences can mostly be attributed to the nature of an OXC-OLS link and the purpose of OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the basis for GMPLS signaling and routing at the optical layer. The info exchanged over LMP-WDM sessions is used to augment knowledge about the links between OXCs 🦋
For the info exchanged over the OXC-OLS LMP sessions to be used by the OXC-OXC session, the info must be coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP sessions run independently and must be maintained separately. One critical requirement when running an OXC-OLS LMP session is the ability of the OLS to make a data link transparent when it's not doing the verification procedure. This matters because the same data link may be verified between OXC-OLS and between OXC-OXC. The verification procedure of LMP is used to coordinate the Test procedure (and hence the transparency/opaqueness of the data links). To keep the sessions independent, it must be possible for the LMP sessions to come up in any order. In particular, it must be possible for an OXC-OXC LMP session to come up without an OXC-OLS LMP session being brought up, and vice-versa. Independence is the whole vibe 💜
7. Generalized Signaling 💖
The GMPLS signaling extends certain base functions of the RSVP-TE and CR-LDP signaling and, in some cases, adds functionality. These changes and additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and the info provided for synchronizing the ingress and egress. Main character energy 👑
The core GMPLS signaling specification is available in three parts:
- A signaling functional description [RFC3471].
- RSVP-TE extensions [RFC3473].
- CR-LDP extensions [RFC3472].
In addition, independent parts are available per technology:
- GMPLS extensions for SONET and SDH control [RFC3946].
- GMPLS extensions for G.709 control [GMPLS-G709].
The following MPLS profile, expressed in terms of MPLS features [RFC3031], applies to GMPLS:
- Downstream-on-demand label allocation and distribution.
- Ingress initiated ordered control.
- Liberal (typical), or conservative (could) label retention mode.
- Request, traffic/data, or topology driven label allocation strategy.
- Explicit routing (typical), or hop-by-hop routing.
The GMPLS signaling defines the following new building blocks on top of MPLS-TE 🧚
- A new generic label request format.
- Labels for TDM, LSC and FSC interfaces, generically known as Generalized Label.
- Waveband switching support.
- Label suggestion by the upstream for optimization purposes (e.g., latency).
- Label restriction by the upstream to support some optical constraints.
- Bi-directional LSP establishment with contention resolution.
- Rapid failure notification extensions.
- Protection information, currently focusing on link protection, plus primary and secondary LSP indication.
- Explicit routing with explicit label control for a fine degree of control.
- Specific traffic parameters per technology.
- LSP administrative status handling.
- Control channel separation.
We'll go into these building blocks in more detail below. A complete specification can be found in the corresponding documents 🎀
Note that GMPLS is highly generic and has many options 🌸 Only building blocks 1, 2 and 10 are mandatory, and only within the specific format that's needed. Typically, building blocks 6 and 9 should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are optional. ✨
A typical SONET/SDH switching network would implement building blocks 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks 7 and 8 are optional since the protection can be achieved using SONET/SDH overhead bytes 🦋
A typical wavelength switching network would implement building blocks 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building block 3 is only needed in the particular case of waveband switching 🌈
A typical fiber switching network would implement building blocks 1, 2 (the generic format), 6, 7, 8, 9 and 11 🍓
A typical MPLS-IP network would not implement any of these building blocks, since the absence of building block 1 would indicate regular MPLS-IP. Note however that building blocks 1 and 8 can be used to signal MPLS-IP as well. In that case, the MPLS-IP network can benefit from the link protection type (not available in CR-LDP, with some very basic form available in RSVP-TE). Building block 2 is here a regular MPLS label, so no new label format is required 💅
GMPLS does not specify any profile for RSVP-TE and CR-LDP implementations that have to support GMPLS, except for what's directly related to GMPLS procedures. It's up to the manufacturer to decide which optional elements and procedures of RSVP-TE and CR-LDP need to be implemented. Some optional MPLS-TE elements can be useful for TDM, LSC and FSC layers, for instance the setup and holding priorities that are inherited from MPLS-TE 🫶
7.1. Overview: How to Request an LSP ✨
A TDM, LSC or FSC LSP is established by sending a PATH/Label Request message downstream to the destination. This message contains a Generalized Label Request with the type of LSP (i.e., the layer concerned) and its payload type. An Explicit Route Object (ERO) is also normally added to the message, but this can be added and/or completed by the first/default LSR 🧚
The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC object, or in the CR-LDP Traffic Parameters TLV. Specific parameters for a given technology are carried in these traffic parameters, such as the type of signal, concatenation and/or transparency for a SONET/SDH LSP. For some other technologies there could be just one bandwidth parameter, indicating the bandwidth as a floating-point value 🔥
The requested local protection per link may be requested using the Protection Information Object/TLV. The end-to-end LSP protection is for further study and is introduced in the LSP protection/restoration section (see after) 🙈
If the LSP is a bi-directional LSP, an Upstream Label is also specified in the Path/Label Request message. This label will be the one to use in the upstream direction 💜
Additionally, a Suggested Label, a Label Set and a Waveband Label can also be included in the message. Other operations are defined in MPLS-TE 🌸
The downstream node will send back a Resv/Label Mapping message including one Generalized Label object/TLV, which can contain several Generalized Labels. For instance, if a concatenated SONET/SDH signal is requested, several labels can be returned 👑
In case of SONET/SDH virtual concatenation, a list of labels is returned, with each label identifying one element of the virtual concatenated signal. This limits virtual concatenation to remain within a single (component) link 🦋
In case of any type of SONET/SDH contiguous concatenation, only one label is returned. That label is the lowest signal of the contiguous concatenated signal (given an order specified in [RFC3946]) 💖
In case of SONET/SDH "multiplication", i.e., co-routing of circuits of the same type but without concatenation, all belonging to the same LSP, the explicit ordered list of all signals that take part in the LSP is returned 🌈
7.2. Generalized Label Request ✨
okay so the Generalized Label Request is a brand new object/TLV that goes into an RSVP-TE Path message instead of the regular Label Request, or it can ride along in a CR-LDP Request message next to the TLVs that already exist 💅. Only one label request can be used per message, so you can ask for a single LSP at a time per signaling message 🎀
This bad boy gives you three major characteristics (parameters) that the LSP needs: the LSP Encoding Type, the Switching Type that must be used, and the LSP payload type called Generalized PID (G-PID) 🧚
The LSP Encoding Type tells everyone what encoding will be used with the data on the LSP, aka what kind of technology we're dealing with. It can be SDH, SONET, Ethernet, ANSI PDH, etc. 🌸 It describes the nature of the LSP, not the nature of the links the LSP goes over, and each node uses it hop-by-hop.
A link can support a set of encoding formats, where "support" means the link can carry and switch a signal of one or more of those formats 🦋. The Switching Type then says what kind of switching should happen on a particular link for that LSP. This info is only needed for links that advertise more than one type of switching capability.
Nodes MUST verify that the type indicated in the Switching Type is supported on the corresponding incoming interface. If it isn't, the node MUST generate a notification message with a Routing problem/Switching Type indication 🙈
The LSP payload type (G-PID) tells you which payload the LSP is carrying, basically an identifier for the client layer of that LSP 💜. For some technologies it also shows the mapping the client layer uses, like byte synchronous mapping of E1. This MUST be interpreted according to the LSP encoding type. Nodes at the endpoints use it to figure out which client layer a request is meant for, and sometimes the penultimate hop uses it too 👑.
Other technology specific parameters aren't sent in the Generalized Label Request. They travel in technology specific traffic parameters instead, which we'll get into next. Right now two sets are defined: one for SONET/SDH and one for G.709 ✨
Note that it is expected than specific traffic parameters will be defined in the future for photonic (all optical) switching 🔮
7.3. SONET/SDH Traffic Parameters
The GMPLS SONET/SDH traffic parameters [RFC3946] are a seriously powerful set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707] 🔥
The first traffic parameter says what the elementary SONET/SDH signal in the requested LSP is, like VC-11, VT6, VC-4, STS-3c, and so on. Then you can stack up several transforms on that elementary signal to build the final signal the LSP actually asks for 🧁
The transforms are contiguous concatenation, virtual concatenation, transparency, and multiplication. Each one is optional, but they MUST be applied strictly in this order:
- First, contiguous concatenation can optionally be applied to the Elementary Signal, which gives you a contiguously concatenated signal.
- Second, virtual concatenation can optionally be applied either directly to the elementary Signal, or to the contiguously concatenated signal from the previous step.
- Third, some transparency can optionally be specified when you want a frame as the signal instead of a container. Several transparency packages are defined.
- Fourth, a multiplication can optionally be applied either directly to the elementary Signal, or to the contiguously concatenated signal from the first step, or to the virtually concatenated signal from the second step, or to any of these combined with some transparency.
For RSVP-TE, the SONET/SDH traffic parameters ride in a new SENDER_TSPEC and FLOWSPEC, and both use the same format. There's no Adspec tied to the SENDER_TSPEC. It's either left out or a default value gets used 🎀. The content of the FLOWSPEC object in a Resv message SHOULD be identical to the content of the SENDER_TSPEC from the matching Path message. In other words, the receiver is normally not allowed to change the traffic parameter values. Some negotiation can still happen, though, as explained in [RFC3946] 🤝
For CR-LDP, the SONET/SDH traffic parameters are just carried in a new TLV 💖
Note that a general discussion on SONET/SDH and GMPLS can be found in [SONET-SDH-GMPLS-FRM] 📚
7.4. G.709 Traffic Parameters
Simply said, a [ITUT-G.709] based network is split into two major layers: an optical layer (made of wavelengths) and a digital layer 🌈. Each of those layers has sub-layers, and switching happens at two specific sub-layers: the OCh (Optical Channel) optical layer and the ODU (Optical channel Data Unit) electrical layer. The ODUk notation is used to name ODUs at different bandwidths 💜.
The GMPLS G.709 traffic parameters [GMPLS-G709] are a powerful set of capabilities for ITU-T G.709 networks ✨
The first traffic parameter says what the elementary G.709 signal in the requested LSP is, like ODU1 or an OCh at 40 Gbps. Same deal as before: you can layer several transforms on that elementary signal to get the final signal the LSP asks for 🦋
The transforms here are virtual concatenation and multiplication. Each one is optional, and they MUST be applied strictly in this order:
- First, virtual concatenation can optionally be applied directly to the elementary Signal.
- Second, a multiplication can optionally be applied, either directly to the elementary Signal, or to the virtually concatenated signal from the first step.
Additional ODUk Multiplexing traffic parameters let you indicate an ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. G.709 supports these multiplexing capabilities: ODUj into ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3 🍓
For RSVP-TE, the G.709 traffic parameters ride in a new SENDER-TSPEC and FLOWSPEC, using the same format for both. Again there's no Adspec tied to the SENDER_TSPEC. It's omitted or a default value is used. The content of the FLOWSPEC object in a Resv message should be identical to the content of the SENDER_TSPEC from the matching Path message 🫶
For CR-LDP, the G.709 traffic parameters are simply carried in a new TLV 🌸
7.5. Bandwidth Encoding
Some technologies don't have specific traffic parameters yet, so they just need a bandwidth encoding sent in a generic form 💅. Bandwidth is carried in a 32-bit number in IEEE floating-point format, measured in bytes per second. The values get carried in a protocol specific way. For non-packet LSPs, it's useful to define discrete values that identify the LSP's bandwidth ⭐.
It should be noted that this bandwidth encoding does not apply to SONET/SDH and G.709, since their traffic parameters already fully define the requested signal 🙈
The bandwidth goes in the Peak Data Rate field of the Int-Serv objects for RSVP-TE, in the SENDER_TSPEC and FLOWSPEC objects. For CR-LDP, it goes in the Peak and Committed Data Rate fields of the CR-LDP Traffic Parameters TLV 🎀
7.6. Generalized Label
The Generalized Label is the upgraded version of the traditional MPLS label 🦋. It doesn't just cover labels that travel in-band with the data packets. It also covers (virtual) labels that identify time-slots, wavelengths, or space division multiplexed positions.
For example, a Generalized Label might identify (a) a single fiber in a bundle, (b) a single waveband within a fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It can also be a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI). The format can be as simple as an integer, like a wavelength label, or as fancy as a SONET/SDH or G.709 label 💖
SDH and SONET each define a multiplexing structure. These structures get used as naming trees to make unique labels. Such a label identifies the exact position (time-slot(s)) of a signal inside a multiplexing structure 🌳. Since the SONET multiplexing structure can be seen as a subset of the SDH one, the same label format works for both SDH and SONET. A similar idea is used to build a label at the G.709 ODU layer 🧚
The nodes sending and receiving the Generalized Label already know what kind of link they're using, so the Generalized Label doesn't identify its own type. The nodes are expected to figure out from context what type of label to expect 👑
A Generalized Label only carries a single level of label, so it's non-hierarchical. When you need multiple levels of labels (LSPs within LSPs), each LSP MUST be established separately 🙅♀️
7.7. Waveband Switching
Waveband switching is a special case of wavelength switching 🌈. A waveband is a set of contiguous wavelengths that can be switched together as a new waveband. For optimization reasons, a photonic cross-connect might want to optically switch multiple wavelengths as one unit. That can reduce the distortion on the individual wavelengths and allow tighter separation between them. A Waveband label is defined to support this special case ✨
Waveband switching naturally adds another level of label hierarchy, so the waveband gets treated the same way as all the other upper layer labels. As far as the MPLS protocols are concerned, there's barely any difference between a waveband label and a wavelength label. The one exception is that a waveband can be subdivided into wavelengths, whereas a wavelength can only be subdivided into time or statistically multiplexed labels 💅
In the context of waveband switching, the generalized label used to indicate a waveband has three fields: a waveband ID, a Start Label, and an End Label. The Start and End Labels are channel identifiers from the sender's perspective. They identify the lowest value wavelength and the highest value wavelength that make up the waveband 🦋
7.8. Label Suggestion by the Upstream
GMPLS lets an upstream node optionally suggest a label. A downstream node can override that suggestion, but sometimes that costs a longer LSP setup time 🙈. The suggested label is really valuable when you're setting up LSPs through certain optical equipment that can take a lengthy (in electrical terms) amount of time to configure its switching fabric. For example, micro mirrors might have to be lifted or moved, and that physical motion plus the settling afterwards takes time 🐢. If the labels, and therefore the switching fabric, get configured in the reverse direction (the norm), the Resv/MAPPING message may need to be delayed by 10's of milliseconds per hop before a usable forwarding path exists. This matters a lot for restoration, since alternate LSPs may need to be set up really fast after a network failure 🚨💜
7.9. Label Restriction by the Upstream 🎀
okay so an upstream node can optionally restrict (limit) which label a downstream node is allowed to pick 🫶. It does this by handing over a Label Set, which can be lists and/or ranges of inclusive (acceptable) or exclusive (unacceptable) labels. If no restriction is applied, all labels from the valid label range may be used ✨. There are at least four cases where this is useful in the "optical" domain 💅:
- Case 1: the end equipment is only capable of transmitting and receiving on a small specific set of wavelengths/wavebands.
- Case 2: there is a sequence of interfaces that cannot support wavelength conversion and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path.
- Case 3: it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals.
- Case 4: two ends of a link support different sets of wavelengths.
The receiver of a Label Set must restrict its choice of labels to one that is in the Label Set 🔥. A Label Set may be present across multiple hops. When that happens, each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable interfaces 🌈.
7.10. Bi-directional LSP 🦋
GMPLS allows establishment of bi-directional symmetric LSPs (not of asymmetric LSPs) 💜. A symmetric bi-directional LSP has the same traffic engineering requirements, including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter), in each direction.
In the rest of this section, "initiator" is the node that starts establishing an LSP, and "terminator" is the node that is the target of the LSP 🧚. For a bi-directional LSP, there is only one initiator and one terminator.
Normally, to establish a bi-directional LSP when using RSVP-TE [RFC3209] or CR-LDP [RFC3212], two unidirectional paths must be independently established. Honestly, this approach has some serious downsides 😭:
- The latency to establish the bi-directional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it also extends the worst-case latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes.
- The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bi-directional LSP.
- Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bi-directional connection.
- It is more difficult to provide a clean interface for SONET/SDH equipment that may rely on bi-directional hop-by-hop paths for protection switching. Note that existing SONET/SDH equipment transmits the control information in-band with the data.
- Bi-directional optical LSPs (or lightpaths) are seen as a requirement for many optical networking service providers.
With bi-directional LSPs, both the downstream and upstream data paths (i.e., from initiator to terminator and from terminator to initiator) are established using a single set of signaling messages 🙌. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.
For bi-directional LSPs, two labels must be allocated. Bi-directional LSP setup is indicated by the presence of an Upstream Label in the appropriate signaling message 🎀.
7.11. Bi-directional LSP Contention Resolution ⚔️
Contention for labels may occur between two bi-directional LSP setup requests traveling in opposite directions. This happens when both sides allocate the same resources (ports) at effectively the same time 🙈. GMPLS signaling defines a procedure to resolve that contention: the node with the higher node ID will win the contention. To reduce the probability of contention, some mechanisms are also suggested 🌸.
7.12. Rapid Notification of Failure 🚨
GMPLS defines several signaling extensions that enable expedited notification of failures and other events to the nodes responsible for restoring failed LSPs, and for error handling 💅.
- Acceptable Label Set for notification on Label Error:
There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication. When these cases occur, it can be useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol-specific error messages. The format of an Acceptable Label Set is identical to a Label Set.
- Expedited notification:
Extensions to RSVP-TE enable expedited notification of failures and other events to determined nodes. For CR-LDP, there is not currently a similar mechanism. The first extension identifies where event notifications are to be sent. The second provides for general expedited event notification with a Notify message. Such extensions can be used by fast restoration mechanisms. Notifications may be requested in both the upstream and downstream directions.
The Notify message is a generalized notification mechanism that differs from the currently defined error messages in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify message to the target node, similar to ResvConf processing in [RFC2205]; or (b) encapsulated in a new IP header whose destination is equal to the target IP address 🦋.
- Faster removal of intermediate states:
A specific RSVP optimization allows, in some cases, the faster removal of intermediate states. This extension is used to deal with specific RSVP mechanisms ✨.
7.13. Link Protection 🛡️
Protection information is carried in the new optional Protection Information Object/TLV 🫶. It currently indicates the desired link protection for each link of an LSP. If a particular protection type, i.e., 1+1 or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored 🔥. Note that GMPLS advertises the protection capabilities of a link in the routing protocols. Path computation algorithms may consider this information when computing paths for setting up LSPs 🧠.
Protection information also indicates whether the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are normally not used until the primary LSP fails, but they may be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP must be preempted 😤.
Six link protection types are currently defined as individual flags and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, unprotected, extra traffic. See [RFC3471] section 7.1 for a precise definition of each 🌈.
7.14. Explicit Routing and Explicit Label Control 👑
By using an explicit route, the path taken by an LSP can be controlled more or less precisely 💖. Typically, the node at the head-end of an LSP finds an explicit route and builds an Explicit Route Object (ERO) / Explicit Route (ER) TLV that contains that route. Possibly, the edge node does not build any explicit route, and just transmits a signaling request to a default neighbor LSR (as IP/MPLS hosts would). For instance, an explicit route could be added to a signaling message by the first switching node, on behalf of the edge node. Note also that an explicit route is altered by intermediate LSRs during its progression towards the destination 🧚.
The explicit route was originally defined by MPLS-TE as a list of abstract nodes (i.e., groups of nodes) along the explicit route. Each abstract node can be an IPv4 address prefix, an IPv6 address prefix, or an AS number. This capability allows the generator of the explicit route to have incomplete information about the details of the path. In the simplest case, an abstract node can be a full IP address (32 bits) that identifies a specific node (called a simple abstract node) 🌸.
MPLS-TE allows strict and loose abstract nodes. The path between a strict node and its preceding node must include only network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding abstract node may include other network nodes that are not part of the loose node or its preceding abstract node 🍓.
This explicit route was extended to include interface numbers as abstract nodes to support unnumbered interfaces, and was further extended by GMPLS to include labels as abstract nodes. Having labels in an explicit route is an important feature that allows controlling the placement of an LSP with a very fine granularity. This is more likely to be used for TDM, LSC and FSC links 🔥.
In particular, explicit label control in the explicit route allows terminating an LSP on a particular outgoing port of an egress node. Indeed, a label sub-object/TLV must follow a sub-object/TLV containing the IP address, or the interface identifier (in the case of an unnumbered interface), associated with the link on which it is to be used 💅.
This can also be used when it is desirable to "splice" two LSPs together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP 🫶.
When used together with an optimization algorithm, it can provide very detailed explicit routes, including the label (timeslot) to use on a link, in order to minimize the fragmentation of the SONET/SDH multiplex on the corresponding interface 🌈💖.
7.15. Route Recording 🛣️
Okay so, route recording exists to make the LSP being set up more reliable and easier to manage, and RSVP-TE brought it in for three jobs 🎀
- First, a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route (this mechanism is strictly exclusive with the use of explicit routing objects).
- Second, a route recording mechanism collects up-to-date detailed path information on a hop-by-hop basis during the LSP setup process. This mechanism provides valuable information to the source and destination nodes. Any intermediate routing change at setup time, in case of loose explicit routing, will be reported. 👀
- Third, a recorded route can be used as input for an explicit route. This is useful if a source node receives the recorded route from a destination node and applies it as an explicit route in order to "pin down the path". 📌
Within the GMPLS architecture, only the second and third functions are mainly applicable for TDM, LSC and FSC layers. 💅
7.16. LSP Modification and LSP Re-routing 🔁
LSP modification and re-routing are two features that already exist in MPLS-TE, so GMPLS isn't adding anything new here 🙌 Re-routing can be really elegant with "make-before-break". The old path stays in use while a new path gets set up, and the trick is that resources aren't reserved twice. Then the node doing the re-routing can swap onto the new path and close the old one ✨ This is supported with RSVP-TE (using shared explicit filters) and CR-LDP (using the action indicator flag).
LSP modification means changing some LSP parameters, but normally without changing the route. It uses the same mechanism as re-routing. The semantics of LSP modification will differ from one technology to the other, though 🥺 For instance, further studies are required to understand the impact of dynamically changing some SONET/SDH circuit characteristics such as the bandwidth, the protection type, the transparency, the concatenation, etc. 🧐
7.17. LSP Administrative Status Handling 🚦
GMPLS gives you the optional ability to indicate the administrative status of an LSP using a new Admin Status object/TLV 🎀 Administrative Status information is currently used in two ways.
In the first usage, the Admin Status object/TLV is carried in a Path/Label Request or Resv/Label Mapping message to show the administrative state of an LSP. The state can be "up" or "down", whether it's in a "testing" mode, and whether deletion is in progress 🧸
Based on that status, a node can make local decisions, like inhibiting alarm reporting when an LSP is in "down" or "testing" states, or reporting alarms tied to the connection at a priority equal to or less than "Non service affecting" 🔕
It's possible that some nodes along an LSP won't support the Admin Status Object/TLV. For a non-supporting transit node, the object passes through unmodified and normal processing can carry on 🫶
In some circumstances, especially optical networks, it's useful to set the administrative status of an LSP to "being deleted" before tearing it down, so you avoid generating alarms that aren't useful 🙅♀️ The ingress LSR gets this started by inserting an appropriate Admin Status Object/TLV into a Path/Label Request message (with the modification action indicator flag set to modify). Transit LSRs process the Admin Status Object/TLV and forward it on. The egress LSR answers with a Resv/Label Mapping message (with the modification action indicator flag set to modify) that carries the Admin Status object. Once the ingress node gets that message and object, it sends a PathTear/Release message downstream to remove the LSP, and normal RSVP-TE/CR-LDP processing takes place 🧹
In the second usage, the Admin Status object/TLV is carried in a Notification/Label Mapping message (with the modification action indicator flag set to modify) to request that the ingress node change the administrative state of an LSP 🙋♀️ This lets intermediate and egress nodes trigger the setting of administrative status. Specifically, it lets intermediate or egress LSRs ask for a release of an LSP that the ingress node initiated 💜
7.18. Control Channel Separation 🔌
In GMPLS, a control channel can be separated from the data channel 🫧 The control channel can be implemented completely out-of-band for various reason, e.g., when the data channel cannot carry in-band control information. This issue was even originally introduced to MPLS in the context of link bundling 🍓
In traditional MPLS, there's an implicit one-to-one association between a control channel and a data channel. When that association is present, no additional or special information is needed to tie a particular LSP setup transaction to a particular data channel 💖
Otherwise, extra information has to be carried in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. It allows a number of interface identification schemes, including IPv4 or IPv6 addresses, interface indexes (for unnumbered interfaces) and component interfaces (for bundled interfaces). Unnumbered bundled interfaces are also supported 🌸
The sender of the Path/Label Request message always chooses the data interface to use. It indicates that choice by including the data channel's interface identifier in the message, using a new RSVP_HOP object sub-type/Interface TLV 🧚
For bi-directional LSPs, the sender chooses the data interface in each direction. In all cases except bundling, the upstream interface is implied by the downstream interface. For bundling, the Path/Label Request sender explicitly identifies the component interface used in each direction. The new object/TLV is used in the Resv/Label Mapping message to indicate the downstream node's usage of the indicated interface(s) 🦋
The new object/TLV can contain a list of embedded TLVs. Each embedded TLV can be an IPv4 address, an IPv6 address, an interface index, a downstream component interface ID or an upstream component interface ID. In the last three cases, the embedded TLV contains an IP address plus an Interface ID, and the IP address is what identifies the interface ID (it can be the router ID, for instance) 🤓
There are cases where it's useful to point at a specific interface tied to an error. To support those, the IF_ID ERROR_SPEC RSVP Objects are defined 🚨
8. Forwarding Adjacencies (FA) 🌈
To make MPLS TE (and therefore GMPLS) more scalable, it can be useful to aggregate multiple TE LSPs inside a bigger TE LSP 🫶 Intermediate nodes only see the external LSP. They don't have to maintain forwarding states for each internal LSP, fewer signaling messages need to be exchanged, and the external LSP can be protected instead of (or in addition to) the internal LSPs. This can seriously boost the scalability of the signaling 🚀
The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (e.g., by using the label stack construct in the case of IP) 💅
ISIS/OSPF floods the information about "Forwarding Adjacencies" (FAs) just like it floods the information about any other links. Because of that flooding, an LSR has information in its TE link state database about not just conventional links, but FAs as well 👑
When an LSR does path computation, it uses not just conventional links, but FAs as well. Once a path is computed, the LSR uses RSVP-TE/CR-LDP to establish label bindings along the path. FAs need simple extensions to signaling and routing protocols 🎀
8.1. Routing and Forwarding Adjacencies 🗺️
Forwarding adjacencies can be represented as either unnumbered or numbered links. A FA can also be a bundle of LSPs between two nodes 🍭
FAs are advertised as GMPLS TE links, as defined in [HIERARCHY]. GMPLS TE links are advertised in OSPF and IS-IS as defined in [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications enhance [OSPF-TE] and [ISIS-TE], which define a base TE link 📚
When a FA is created dynamically, its TE attributes are inherited from the FA-LSP that induced its creation. [HIERARCHY] specifies how each TE parameter of the FA is inherited from the FA-LSP. Note that the bandwidth of the FA must be at least as big as the FA-LSP that induced it, but it may be bigger if only discrete bandwidths are available for the FA-LSP. In general, for dynamically provisioned forwarding adjacencies, a policy-based mechanism may be needed to associate attributes with forwarding adjacencies 🧠
A FA advertisement could contain information about the path taken by the FA-LSP associated with that FA. Other LSRs may use this information for path computation. This information is carried in a new OSPF and IS-IS TLV called the Path TLV 🧭
The underlying path information might change over time, through configuration updates or dynamic route modifications, which can change that TLV 🔄
If forwarding adjacencies are bundled (via link bundling), and the resulting bundled link carries a Path TLV, the underlying path followed by each of the FA-LSPs that form the component links must be the same 🧵
Forwarding adjacencies are expected not to be used for establishing IS-IS/OSPF peering relations between the routers at the ends of the adjacency 🙈
LSP hierarchy could exist with both the peer and the overlay models. In the peer model, the LSP hierarchy is realized via FAs, and an LSP is both created and used as a TE link by exactly the same instance of the control plane. Creating LSP hierarchies with overlays doesn't involve the concept of FA. In the overlay model, an LSP created (and maintained) by one instance of the GMPLS control plane is used as a TE link by another instance of the GMPLS control plane. On top of that, the nodes using a TE link are expected to have a routing and signaling adjacency 🌷
8.2. Signaling Aspects 📡
To process the explicit route in a Path/Request message for an LSP that's going to be tunneled over a forwarding adjacency, an LSR at the head-end of the FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP hop away) 🦋✨
8.3. Cascading of Forwarding Adjacencies 🧚
Okay so with an integrated model, several layers are controlled using the same routing and signaling protocols 💅 which means one network can end up with links that have totally different multiplexing/demultiplexing capabilities. Like, a node might be able to multiplex/demultiplex individual packets on one link, and multiplex/demultiplex channels inside a SONET payload on other links. Iconic range ✨
A new OSPF and IS-IS sub-TLV has been defined to advertise the multiplexing capability of each interface: PSC, L2SC, TDM, LSC or FSC. It's called the Interface Switching Capability Descriptor sub-TLV, and it complements the sub-TLVs defined in [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. The info in this sub-TLV is what gets used to construct LSP regions and figure out where each region's boundaries are 🗺️
Path computation can take region boundaries into account when it computes a path for an LSP. For example, path computation may restrict the path to only the links whose multiplexing/demultiplexing capability is PSC. When an LSP needs to cross a region boundary, it can trigger the establishment of an FA at the underlying layer (i.e., the L2SC layer). This can trigger a cascading of FAs between layers, with the following obvious order: L2SC, then TDM, then LSC, and then finally FSC. It's giving layered 🍓
9. Routing and Signaling Adjacencies 🦋
Okay, first the basics. By definition, two nodes have a routing (IS-IS/OSPF) adjacency if they are neighbors in the IS-IS/OSPF sense.
By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are RSVP-TE neighbors if they directly exchange RSVP-TE messages (Path/Resv), for example as described in sections 7.1.1 and 7.1.2 of [HIERARCHY]. The neighbor relationship includes exchanging RSVP-TE Hellos. 💌
By definition, a Forwarding Adjacency (FA) is a TE Link between two GMPLS nodes whose path transits one or more other (G)MPLS nodes in the same instance of the (G)MPLS control plane. 🪞 If two nodes have one or more non-FA TE Links between them, these two nodes are expected (although not REQUIRED) to have a routing adjacency. If two nodes do not have any non-FA TE Links between them, it is expected (although not REQUIRED) that these two nodes would not have a routing adjacency. To state the obvious, if the TE links between two nodes are going to be used for establishing LSPs, the two nodes MUST have a signaling adjacency. 🙈
If you want to establish a routing and/or signaling adjacency between two nodes, there MUST be an IP path between them. This IP path can be, for example, a TE Link with an interface switching capability of PSC, or anything that looks like an IP link (e.g., a GRE tunnel, or a (bi-directional) LSP with an interface switching capability of PSC). 🛤️
A TE link may not be capable of being used directly for maintaining routing and/or signaling adjacencies. This is because GMPLS routing and signaling adjacencies require exchanging data on a per frame/packet basis, and a TE link (e.g., a link between OXCs) may not be capable of exchanging data on a per packet basis. In this case, the routing and signaling adjacencies are maintained via a set of one or more control channels (see [LMP]). 🫶
Two nodes may have a TE link between them even if they do not have a routing adjacency. Naturally, each node MUST run OSPF/IS-IS with GMPLS extensions in order for that TE link to be advertised. More precisely, the node needs to run GMPLS extensions for TE Links with an interface switching capability (see [GMPLS-ROUTING]) other than PSC. Moreover, this node needs to run either GMPLS or MPLS extensions for TE links with an interface switching capability of PSC. 🧠
The mechanisms for Control Channel Separation [RFC3471] SHOULD be used, even if the IP path between two nodes is a TE link. In other words, RSVP-TE/CR-LDP signaling SHOULD use the Interface_ID (IF_ID) object to specify a particular TE link when establishing an LSP. 🎀
The IP path could consist of multiple IP hops. In this case, the mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] SHOULD be used, in addition to Control Channel Separation. 🌈
10. Control Plane Fault Handling 🚨
Two major types of faults can hit a control plane. The first is the control channel fault, which is when control communication gets lost between two neighboring nodes. If the control channel is embedded with the data channel, the data channel recovery procedure should solve the problem. If the control channel is independent of the data channel, additional procedures are REQUIRED to recover from that problem. 😭
The second is the nodal fault, which is when a node loses its control state (e.g., after a restart) but does not lose its data forwarding state. 💀
In transport networks, these kinds of control plane faults SHOULD NOT have service impact on existing connections. Under these circumstances, a mechanism MUST exist to detect a control communication failure, and a recovery procedure MUST guarantee connection integrity at both ends of the control channel. 🔒
For a control channel fault, once communication is restored, routing protocols are naturally able to recover, but the underlying signaling protocols MUST indicate that the nodes have maintained their state through the failure. The signaling protocol MUST also ensure that any state changes that were instantiated during the failure are synchronized between the nodes. 🔄
For a nodal fault, a node's control plane restarts and loses most of its state information. In this case, both upstream and downstream nodes MUST synchronize their state information with the restarted node. For any resynchronization to happen, the node undergoing the restart will need to preserve some information, such as its mappings of incoming to outgoing labels. 🏷️
These issues are handled in protocol-specific ways, see [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures. 👀
The LDP Fault tolerance (see [RFC3479]) specifies the procedures to recover from a control channel failure. [RFC3473] specifies how to recover from both a control channel failure and a node failure. 💜
11. LSP Protection and Restoration 🛡️
This section discusses Protection and Restoration (P&R) issues for GMPLS LSPs. It's driven by the requirements outlined in [RFC3386] and some of the principles outlined in [RFC3469]. It will be enhanced as more GMPLS P&R mechanisms get defined. Here's the scope of this section:
- This section only applies when a fault impacting LSP(s) happens in the data/transport plane. Section 10 deals with control plane fault handling for nodal and control channel faults. 🙌
- This section focuses on P&R at the TDM, LSC and FSC layers. There are specific P&R requirements at these layers that aren't present at the PSC layer. ✨
- This section focuses on intra-area P&R as opposed to inter-area P&R and even inter-domain P&R. P&R can be even more restricted, e.g., to a collection of like customer equipment, or a collection of equipment of like capabilities, in one single routing area. 🗺️
- This section focuses on intra-layer P&R (horizontal hierarchy as defined in [RFC3386]) as opposed to inter-layer P&R (vertical hierarchy). 🪜
- P&R mechanisms are generally designed to handle single failures, which makes SRLG diversity a necessity. Recovery from multiple failures requires further study. 🧩
- Both mesh and ring-like topologies are supported. 💫
In the following, we assume that:
- TDM, LSC and FSC devices are generally committing recovery resources in a non-best-effort way. Recovery resources are either allocated (and thus used) or at least logically reserved (whether used or not by preemptable extra traffic, but unavailable anyway for regular working traffic). 🔐
- Shared P&R mechanisms are valuable to operators in order to maximize their network utilization. 📈
- Sending preemptable excess traffic on recovery resources is a valuable feature for operators. 🍯
11.1. Protection Escalation across Domains and Layers 🪜
To describe the P&R architecture, one MUST consider two dimensions of hierarchy [RFC3386]:
- A horizontal hierarchy consisting of multiple P&R domains, which is important in an LSP-based protection scheme. The scope of P&R may extend over a link (or span), an administrative domain or sub-network, or an entire LSP.
An administrative domain may consist of a single P&R domain or a concatenation of several smaller P&R domains. The operator can configure P&R domains based on customers' requirements, and on network topology and traffic engineering constraints. 🧁
- A vertical hierarchy consisting of multiple layers of P&R with varying granularities (packet flows, STS trails, lightpaths, fibers, etc).
In the absence of adequate P&R coordination, a fault may propagate from one level to the next within a P&R hierarchy. It can lead to "collisions," and simultaneous recovery actions may lead to race conditions, reduced resource utilization, or instabilities [MANCHESTER]. Thus, a consistent escalation strategy is needed to coordinate recovery across domains and layers. The fact that GMPLS can be used at different layers could simplify this coordination. 🤝
There are two types of escalation strategies: bottom-up and top-down. The bottom-up approach assumes that "lower-level" recovery schemes are more expedient, so we can inhibit or hold off higher-level P&R. The top-down approach attempts service P&R at the higher levels before invoking "lower level" P&R. Higher-layer P&R is service selective, and permits "per-CoS" or "per-LSP" re-routing. 🎯
Service Level Agreements (SLAs) between network operators and their clients are needed to determine the necessary time scales for P&R at each layer and at each domain. ⏱️
11.2. Mapping of Services to P&R Resources 💖
okay so picking a P&R scheme is a total tradeoff bestie 🫶 it's basically network utilization (cost) vs service interruption time 😭 cheaper setup usually means you might be offline longer when something breaks. so network service providers are expected to offer a whole range of service offerings or service levels 💅
one can sort LSPs into a small set of service levels 🎀 and these levels define the reliability characteristics of the LSP. the service level tied to a given LSP gets mapped to one or more P&R schemes during LSP establishment. the lowkey best part is that this mapping lets an LSP use different P&E schemes in different segments of a network (e.g., some links may be span protected, whilst other segments of the LSP may utilize ring protection) 🌈 these details are likely to be service provider specific ✨
an alternative to service levels is for an application to name the specific P&R mechanisms it wants when the LSP gets established 🦋 this gives way more flexibility so the app can use different mechanisms to meet its own requirements 💜
the big differentiator between these service levels is service interruption time in case of network failures 🥺 that's the length of time between when a failure occurs and when connectivity is re-established. so the choice of service level (or P&R scheme) should be dictated by the service requirements of different applications 🍓
11.3. Classification of P&R Mechanism Characteristics 🧚
this figure is giving classification vibes 📊 it shows the possible provisioning types of recovery LSPs, plus the levels of overbooking that are possible for them 👑
+-Computed on +-Established +-Resources pre-
| demand | on demand | allocated
| | |
Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand
+--- Dedicated (1:1, 1+1)
|
|
+--- Shared (1:N, Ring, Shared mesh)
|
Level of |
Overbooking ---+--- Best effort11.4. Different Stages in P&R 🌸
recovery from a network fault or impairment happens in several stages, as discussed in [RFC3469] 🔥 those are fault detection, fault localization, notification, recovery (i.e., the P&R itself) and reversion of traffic (i.e., returning the traffic to the original working LSP or to a new one) 💀
- Fault detection is technology and implementation dependent 🙈 in general, failures get detected by lower layer mechanisms (e.g., SONET/SDH, Loss-of-Light (LOL)). when a node detects a failure, an alarm may be passed up to a GMPLS entity, which will take appropriate actions, or the alarm may be propagated at the lower layer (e.g., SONET/SDH AIS).
- Fault localization can be done with the help of GMPLS, e.g., using LMP for fault localization (see section 6.4) 🔍
- Fault notification can also be achieved through GMPLS, e.g., using GMPLS RSVP-TE/CR-LDP notification (see section 7.12) 📣
- this section focuses on the different mechanisms available for recovery and reversion of traffic once fault detection, localization and notification have already taken place ✨
11.5. Recovery Strategies 💜
network P&R techniques can be split into Protection and Restoration 🎀 in protection, resources between the protection endpoints are established before the failure, and connectivity after failure is achieved simply by switching performed at the protection end-points. restoration, on the other hand, uses signaling after failure to allocate resources along the recovery path 🫣
- Protection aims at extremely fast reaction times and may rely on the use of overhead control fields for achieving end-point coordination 🏃♀️ protection for SONET/SDH networks is described in [ITUT-G.841] and [ANSI-T1.105]. protection mechanisms can be further classified by the level of redundancy and sharing.
- Restoration mechanisms rely on signaling protocols to coordinate switching actions during recovery, and may involve simple re-provisioning, i.e., signaling only at the time of recovery; or pre-signaling, i.e., signaling prior to recovery 🧩
in addition, P&R can be applied on a local or end-to-end basis 🗺️ in the local approach, P&R is focused on the local proximity of the fault so service gets restored faster 💨 in the end-to-end approach, the LSP originating and terminating nodes control recovery 👑
using these strategies, the following recovery mechanisms can be defined 🌈
11.6. Recovery mechanisms: Protection schemes 🛡️
protection schemes are usually defined in technology specific ways, but that doesn't rule out other solutions 💅
- 1+1 Link Protection: two pre-provisioned resources are used in parallel. for example, data is transmitted simultaneously on two parallel links and a selector is used at the receiving node to choose the best source (see also [GMPLS-FUNCT]) ✨
- 1:N Link Protection: working and protecting resources (N working, 1 backup) are pre-provisioned 🎀 if a working resource fails, the data is switched to the protecting resource, using a coordination mechanism (e.g., in overhead bytes). more generally, N working and M protecting resources can be assigned for M:N link protection (see also [GMPLS-FUNCT]) 🦋
- Enhanced Protection: various mechanisms such as protection rings can be used to enhance the level of protection beyond single link failures, to include the ability to switch around a node failure or multiple link failures within a span, based on a pre-established topology of protection resources (note: no reference available at publication time) 🌸
- 1+1 LSP Protection: simultaneous data transmission on working and protecting LSPs, and tail-end selection, can be applied (see also [GMPLS-FUNCT]) 🫶
11.7. Recovery mechanisms: Restoration schemes 🔄
thanks to the use of a distributed control plane like GMPLS, restoration is possible in multiple of tenths of milliseconds ⚡ it's way harder when only an NMS is used, and in that case it can only be done in a multiple of seconds 🥲
- End-to-end LSP restoration with re-provisioning: an end-to-end restoration path is established after failure 🛠️ the restoration path may be dynamically calculated after failure, or pre-calculated before failure (often during LSP establishment). importantly, no signaling is used along the restoration path before failure, and no restoration bandwidth is reserved 😬 consequently, there is no guarantee that a given restoration path is available when a failure occurs. thus, one may have to crankback to search for an available path 🔙
- End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and no label pre-selection: an end-to-end restoration path is pre-calculated before failure, and a signaling message is sent along this pre-selected path to reserve bandwidth, but labels are not selected (see also [GMPLS-FUNCT]) 📨
the resources reserved on each link of a restoration path may be shared across different working LSPs that are not expected to fail simultaneously. local node policies can be applied to define the degree to which capacity is shared across independent failures 🧠 upon failure detection, LSP signaling is initiated along the restoration path to select labels, and to initiate the appropriate cross-connections 🔌
- End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and label pre-selection: an end-to-end restoration path is pre-calculated before failure, and a signaling procedure is initiated along this pre-selected path, on which bandwidth is reserved and labels are selected (see also [GMPLS-FUNCT]) 💖
the resources reserved on each link may be shared across different working LSPs that are not expected to fail simultaneously. in networks based on TDM, LSC and FSC technology, LSP signaling is used after failure detection to establish cross-connections at the intermediate switches on the restoration path, using the pre-selected labels 🎀
- Local LSP restoration: the above approaches can be applied on a local basis rather than end-to-end, in order to reduce recovery time (note: no reference available at publication time) 🏁
11.8. Schema Selection Criteria 💅
okay so this section is all about the criteria the operator can use to pick between the different P&R mechanisms 🎀 let's get into it
- Robustness: honestly, the less pre-planning the restoration path has, the more robust the restoration scheme is across a bunch of different failures 🛡️, as long as there are enough resources available. restoration schemes with pre-planned paths can't recover from network failures that hit both the working and restoration paths at the same time 😭. so these paths should ideally be as disjoint as possible (SRLG and node disjoint), so that no single failure event takes out both paths. the risk of both paths failing at once can be lowered by recalculating the restoration path whenever a failure happens along it 🔄
the pre-selection of a label gives less flexibility for multiple failure scenarios than no label pre-selection, not gonna lie 🙃. if failures hit two LSPs that share a label at a common node along their restoration routes, only one of them can be recovered, unless the label assignment gets changed.
the robustness of a restoration scheme also depends on how much restoration bandwidth is reserved. as the amount of restoration bandwidth sharing goes up (reserved bandwidth goes down), the restoration scheme gets less robust to failures 📉. restoration schemes with pre-signaled bandwidth reservation (with or without label pre-selection) can reserve enough bandwidth to recover from any specific set of failure events, like any single SRLG failure, any two SRLG failures, and so on 💖. obviously, more restoration capacity gets allocated if a higher degree of failure recovery is needed. so the degree to which the network is protected comes down to the policy that defines how much restoration bandwidth gets reserved 👑
- Recovery time: generally speaking, the more pre-planning of the restoration route, the faster the P&R scheme is ⚡. protection schemes usually recover faster than restoration schemes. restoration with pre-signaled bandwidth reservation is likely to be (significantly) faster than path restoration with re-provisioning, especially because crankback gets eliminated 🙌. local restoration will generally be faster than end-to-end schemes too.
recovery time objectives for SONET/SDH protection switching (not counting time to detect the failure) are specified in [ITUT-G.841] at 50 ms 🤯, taking into account constraints on distance, the number of connections involved, and, for ring enhanced protection, the number of nodes in the ring 💍
recovery time objectives for restoration mechanisms are being defined through a separate effort [RFC3386] 🧚
- Resource Sharing: 1+1 and 1:N link and LSP protection both need dedicated recovery paths with limited ability to share resources. 1+1 allows no sharing at all, while 1:N allows some sharing of protection resources and supports extra (pre-emptable) traffic 🦋. flexibility is limited by topology restrictions, like the fixed ring topology used by traditional enhanced protection schemes 🥲
for restoration schemes, how much sharing happens across multiple independent failures depends directly on the size of the restoration pool 🏊♀️. with re-provisioning, a pool of restoration capacity can be defined, and all restoration routes get picked from that pool after a failure. so the degree of sharing is set by how much restoration capacity is available. with restoration using pre-signaled bandwidth reservation, the amount of reserved restoration capacity is decided by the local bandwidth reservation policies. in all restoration schemes, pre-emptable resources can use spare restoration capacity whenever that capacity isn't being used for failure recovery 🌈
12. Network Management 🌸
okay network management is HUGE for Service Providers (SPs) 🧠. they use it to configure, monitor, and provision all kinds of devices in their network. and get this, an SP's equipment might be spread across geographically separate sites, which makes distributed management even more important 🗺️. the SP should use an NMS system and standard management protocols like SNMP (see [RFC3410], [RFC3411] and [RFC3416]) plus the relevant MIB modules as the standard interfaces for configuring, monitoring, and provisioning devices at different locations 💅. the SP may also want to use the command line interface (CLI) that vendors provide with their devices. but ngl, that's not a standard or recommended solution, because there's no standard CLI language or interface, which means N different CLIs in a network with devices from N different vendors 💀. in the GMPLS context, standard interfaces to the SP's devices (like SNMP) are extremely important because of the nature of the technology itself 🫶. GMPLS has tons of different layers of control-plane and data-plane technology, so management interfaces need to be flexible enough for the manager to manage GMPLS easily and in a standard way ✨
12.1. Network Management Systems (NMS) 💻
the NMS system should keep the collective info about each device in the system 📇. the NMS might actually be made up of several distributed applications (alarm aggregators, configuration consoles, polling applications, etc.) that together form the SP's NMS 🧩. that way it can make provisioning and maintenance decisions with the full picture of the entire SP's network 👀. configuration or provisioning info (like requests for new services) can be entered into the NMS and then distributed via SNMP to the remote devices 📬. this makes managing the network so much more compact and effortless, instead of having to manage each device one by one via CLI 😌
security and access control can be done with the SNMPv3 User-based Security Model (USM) [RFC3414] and the View-based Access Control Model (VACM) [RFC3415] 🔐. this approach works really well inside an SP's network, since the SP has access to and control over all devices in its domain 👑. standardized MIBs will need to be developed before this can be used everywhere to provision, configure, and monitor devices in non-heterogeneous networks or across SP network boundaries 🥺
12.2. Management Information Base (MIB) 📚
again, in the GMPLS context, standard interfaces to devices are extremely important because of the nature of the technology itself 🙌. since GMPLS has lots of different layers of control-plane technology, SNMP MIB modules in this area need to be flexible enough for the manager to manage the entire control plane 🎛️. this should happen with MIB modules that can cooperate (like coordinated row-creation on the agent), or through more generalized MIB modules that bundle some of the desired actions and push the details down to the devices. it's also important to note that in certain situations, it may be necessary to duplicate a small subset of manageable objects in new MIB modules for management convenience 🫠. some parts of GMPLS can also be controlled through existing MIB interfaces (like the existing SONET MIB) or through separate ones that are yet to be defined 🔮. MIB modules may have been defined in the IETF or the ITU already, and current MIB modules may need to be extended to support some of the new GMPLS functionality. in those cases, the working group should work on new versions of these MIB modules so the extensions can be added 🌟
12.3. Tools 🛠️
just like in traditional networks, standard tools like traceroute [RFC1393] and ping [RFC2151] are needed for debugging and performance monitoring of GMPLS networks 🔍. they're mainly for the control plane topology, which mirrors the data plane topology 🪞. these tools also give network reachability info. the GMPLS control protocols need to expose certain pieces of information so these tools can work properly and provide info that's relevant to GMPLS 💜. these tools should be available via the CLI, and they should also be available for remote invocation via the SNMP interface [RFC2925] 📟
12.4. Fault Correlation between Multiple Layers 🚨
because of how GMPLS works, and because potentially many layers can be involved in carrying GMPLS data and control information, a fault in one layer has to be passed up to the adjacent higher and lower layers so they get notified 📣. but with so many layers, it's possible and even probable that hundreds or even thousands of notifications end up passing between layers 😵💫. that's undesirable for a few reasons. first, all those notifications will overwhelm the device 🥴. second, if the devices are set up to emit SNMP Notifications [RFC3417], the huge number of notifications could overwhelm the network with a storm of notifications ⛈️. even if the device does emit them, the NMS that has to process them will either be overwhelmed or end up processing redundant info 🙃. for example, say 1000 interfaces at layer B are stacked above a single interface below them at layer A. if the interface at A goes down, the interfaces at layer B shouldn't emit notifications. instead, the interface at layer A should emit a single notification 🎯. the NMS that receives it should be able to figure out that this interface has many others stacked on top of it, and take appropriate action if needed 🧠
devices that support GMPLS should provide mechanisms for aggregating, summarizing, enabling, and disabling inter-layer notifications for the reasons above 🧚. in the context of SNMP MIB modules, every MIB module used by GMPLS must provide enable/disable objects for all notification objects. these MIBs must also provide notification summarization objects or functionality (as described above) 💖. NMS systems and standard tools that process notifications or track the many layers on any given device must be able to handle the massive amount of info that GMPLS devices might emit at any point in time 🌈
13. Security Considerations 🔐
okay bestie, this one is SERIOUS but also iconic 💅. GMPLS defines a control plane architecture for lots of different technologies and types of network elements. LSPs set up with GMPLS can carry huge amounts of data and eat up a lot of network resources, so security mechanisms are required to protect the underlying network from attacks on the control plane and/or unauthorized use of the data transport resources 😭. So the GMPLS control plane should include mechanisms that prevent or minimize the risk of attackers injecting and/or snooping on control traffic 👀.
How risky this is depends on two things: how much trust there is between the nodes that swap GMPLS control messages, and how the control channel is actually built and what its physical characteristics are. For example, an in-band, in-fiber control channel over SONET/SDH overhead bytes is, in general, considered less vulnerable than a control channel run over an out-of-band IP network. Lowkey a big difference 🫶.
Security mechanisms can give you authentication and confidentiality 🎀. Authentication covers origin verification, message integrity, and replay protection, while confidentiality makes sure a third party cannot decipher what a message says 🙈. If your GMPLS deployment mostly needs authentication, you can use the authentication mechanisms of the GMPLS component protocols (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). You can also use the IPsec suite of protocols (see [RFC2402], [RFC2406] and [RFC2409]) to provide authentication, confidentiality, or both for a GMPLS control channel 🔥. IPsec is iconic because it gives combined protection for all the GMPLS component protocols, plus key management ✨.
Next up is authorization, which is a whole other vibe 💖. Authorization decides whether a given party, who has presumably already been authenticated, actually has the right to access the resources they asked for. This is typically handled by local policy control [RFC2753], like setting limits on the total bandwidth available to a party when resources are contested 🌸. These policies can get really complex as you add more users, more types of resources, and fancier authorization rules 🧚.
After authenticating requests, control elements should check them against the local authorization policy 💅. These control elements must be able to make decisions based on who the requester is, as verified cryptographically and/or topologically 🦋. For example, a decision might depend on whether the request comes through an inter-domain or an intra-domain interface 👑. Using good local authorization policies can help limit the damage from security breaches in remote parts of a network 🛡️.
Finally, GMPLS itself doesn't add any new security considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), routing protocols (OSPF-TE, IS-IS-TE), or network management protocols (SNMP) 🌈. No new drama, just the same security story we already have ✨.
14. Acknowledgements 🫶
this document is the work of a LOT of authors and pulls together a bunch of earlier documents in this area 🍓.
big thanks to Ben Mack-Crane (Tellabs) for all the super useful SONET/SDH chats we had together 💜. Also a huge thank you to Pedro Falcao, Alexandre Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from Ebone for their SONET/SDH and optical technical advice and support 🌟. And finally, thanks so much to Krishna Mitra (Consultant), Curtis Villamizar (Avici), Ron Bonica (WorldCom), and Bert Wijnen (Lucent) for their revision work on Section 12 🎀. You all are literally the MVPs 👑😭.
15. References 📚
15.1. Normative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[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.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu,
R., Wu, L., Doolan, P., Worster, T., Feldman,
N., Fredette, A., Girish, M., Gray, E.,
Heinanen, J., Kilty, T., and A. Malis,
"Constraint-Based LSP Setup using LDP", RFC
3212, January 2002.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized
Multi-Protocol Label Switching (GMPLS)
Signaling Constraint-based Routed Label
Distribution Protocol (CR-LDP) Extensions", RFC
3472, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.15.2. Informative References ✨
okay bestie, these are the extra-credit reads 📚🦋 they're not required to get the core picture, but they're where all the GMPLS, SONET/SDH, and MPLS recovery backstory lives 💜
[ANSI-T1.105]"Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, And Formats," ANSI T1.105, 2000. 🌸[BUNDLE]Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress. 🎀[GMPLS-FUNCT]Lang, J.P., Ed. and B. Rajagopalan, Ed., "Generalized MPLS Recovery Functional Specification", Work in Progress. 💅[GMPLS-G709]Papadimitriou, D., Ed., "GMPLS Signaling Extensions for G.709 Optical Transport Networks Control", Work in Progress. ✨[GMPLS-OVERLAY]Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "GMPLS UNI: RSVP Support for the Overlay Model", Work in Progress. 🦋[GMPLS-ROUTING]Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress. 🌈[RFC3946]Mannie, E., Ed. and Papadimitriou D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. 👑[HIERARCHY]Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress. 🧚[ISIS-TE]Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. 🍓[ISIS-TE-GMPLS]Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress. 💖[ITUT-G.707]ITU-T, "Network Node Interface for the Synchronous Digital Hierarchy", Recommendation G.707, October 2000. ⭐[ITUT-G.709]ITU-T, "Interface for the Optical Transport Network (OTN)," Recommendation G.709 version 1.0 (and Amendment 1), February 2001 (and October 2001). 🔥[ITUT-G.841]ITU-T, "Types and Characteristics of SDH Network Protection Architectures," Recommendation G.841, October 1998. 🫶[LMP]Lang, J., Ed., "Link Management Protocol (LMP)", Work in Progress. 🌸[LMP-WDM]Fredette, A., Ed. and J. Lang Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", Work in Progress. 🎀[MANCHESTER]J. Manchester, P. Bonenfant and C. Newton, "The Evolution of Transport Network Survivability," IEEE Communications Magazine, August 1999. 💅[OIF-UNI]The Optical Internetworking Forum, "User Network Interface (UNI) 1.0 Signaling Specification - Implementation Agreement OIF-UNI-01.0," October 2001. ✨[OLI-REQ]Fredette, A., Ed., "Optical Link Interface Requirements," Work in Progress. 🦋[OSPF-TE-GMPLS]Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress. 🌈[OSPF-TE]Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. 👑[RFC1393]Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993. 🧚[RFC2151]Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997. 🍓[RFC2205]Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 💖[RFC2385]Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. ⭐[RFC2402]Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. 🔥[RFC2406]Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. 🫶[RFC2409]Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 🌸[RFC2702]Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 🎀[RFC2747]Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. 💅[RFC2753]Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. ✨[RFC2925]White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000. 🦋[RFC3036]Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. 🌈[RFC3386]Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002. 👑[RFC3410]Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 🧚[RFC3411]Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 🍓[RFC3414]Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 💖[RFC3415]Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. ⭐[RFC3416]Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. 🔥[RFC3417]Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 🫶[RFC3469]Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003. 🌸[RFC3477]Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. 🎀[RFC3479]Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003. 💅[RFC3480]Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003. ✨[SONET-SDH-GMPLS-FRM]Bernstein, G., Mannie, E., and V. Sharma, "Framework for GMPLS-based Control of SDH/SONET Networks", Work in Progress. 🦋
16. Contributors ✨
okay bestie, this is the squad list 🫶 these are the people who helped build this spec, and honestly the lineup is iconic. The contact details are kept exactly as written so you can reach out to anyone who worked on it 💌
Peter Ashwood-Smith
Nortel
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7, Canada
EMail: petera@nortelnetworks.com
Eric Mannie
Consult
Phone: +32 2 648-5023
Mobile: +32 (0)495-221775
EMail: eric_mannie@hotmail.com
Daniel O. Awduche
Consult
EMail: awduche@awduche.com
Thomas D. Nadeau
Cisco
250 Apollo Drive
Chelmsford, MA 01824, USA
EMail: tnadeau@cisco.com
Ayan Banerjee
Calient
5853 Rue Ferrari
San Jose, CA 95138, USA
EMail: abanerjee@calient.net
Lyndon Ong
Ciena
10480 Ridgeview Ct
Cupertino, CA 95014, USA
EMail: lyong@ciena.com
Debashis Basak
Accelight
70 Abele Road, Bldg.1200
Bridgeville, PA 15017, USA
EMail: dbasak@accelight.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel.be
Lou Berger
Movaz
7926 Jones Branch Drive
MCLean VA, 22102, USA
EMail: lberger@movaz.com
Dimitrios Pendarakis
Tellium
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: dpendarakis@tellium.com
Greg Bernstein
Grotto
EMail: gregb@grotto-networking.com
Bala Rajagopalan
Tellium
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: braja@tellium.com
Sudheer Dharanikota
Consult
EMail: sudheer@ieee.org
Yakov Rekhter
Juniper
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
EMail: yakov@juniper.net
John Drake
Calient
5853 Rue Ferrari
San Jose, CA 95138, USA
EMail: jdrake@calient.net
Debanjan Saha
Tellium
2 Crescent Place
Oceanport, NJ 07757-0901, USA
EMail: dsaha@tellium.com
Yanhe Fan
Axiowave
200 Nickerson Road
Marlborough, MA 01752, USA
EMail: yfan@axiowave.com
Hal Sandick
Shepard M.S.
2401 Dakota Street
Durham, NC 27705, USA
EMail: sandick@nc.rr.com
Don Fedyk
Nortel
600 Technology Park Drive
Billerica, MA 01821, USA
EMail: dwfedyk@nortelnetworks.com
Vishal Sharma
Metanoia
1600 Villa Street, Unit 352
Mountain View, CA 94041, USA
EMail: v.sharma@ieee.org
Gert Grammel
Alcatel
Lorenzstrasse, 10
70435 Stuttgart, Germany
EMail: gert.grammel@alcatel.de
George Swallow
Cisco
250 Apollo Drive
Chelmsford, MA 01824, USA
EMail: swallow@cisco.com
Dan Guo
Turin
1415 N. McDowell Blvd,
Petaluma, CA 95454, USA
EMail: dguo@turinnetworks.com
Z. Bo Tang
Tellium
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: btang@tellium.com
Kireeti Kompella
Juniper
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
EMail: kireeti@juniper.net
Jennifer Yates
AT&T
180 Park Avenue
Florham Park, NJ 07932, USA
EMail: jyates@research.att.com
Alan Kullberg
NetPlane
888 Washington
St.Dedham, MA 02026, USA
EMail: akullber@netplane.com
George R. Young
Edgeflow
329 March Road
Ottawa, Ontario, K2K 2E1, Canada
EMail: george.young@edgeflow.com
Jonathan P. Lang
Rincon Networks
EMail: jplang@ieee.org
John Yu
Hammerhead Systems
640 Clyde Court
Mountain View, CA 94043, USA
EMail: john@hammerheadsystems.com
Fong Liaw
Solas Research
Solas Research, LLC
EMail: fongliaw@yahoo.com
Alex Zinin
Alcatel
1420 North McDowell Ave
Petaluma, CA 94954, USA
EMail: alex.zinin@alcatel.com17. Author's Address 🦋
and the last one is for the main author, Eric Mannie, who's a consultant in Brussels 🧚 here's where to find them 💜
Eric Mannie (Consultant)
Avenue de la Folle Chanson, 2
B-1050 Brussels, Belgium
Phone: +32 2 648-5023
Mobile: +32 (0)495-221775
EMail: eric_mannie@hotmail.comFull Copyright Statement 💅
the legal bit, so pay attention 👀 this one is copyright The Internet Society (2004), and it's a whole thing about rights:
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
⚠️ Everything in the paragraph below is in capitals on purpose, so read it as-is. It says the document is provided "AS IS", and that THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
this part is about who owns what. the IETF doesn't take a position on whether any IPR (intellectual property rights) might cover the tech in this doc, or whether you can get a license for it. it also doesn't claim it went looking for any of those rights 🙈 the IETF's rules on IPR for its documents live in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🌈
Acknowledgement 🎀
last but not least, the RFC Editor function is funded by the Internet Society, so a big thank you to them for keeping the lights on 🫶✨
📦 where this page comes from
- ietf: rfc3945 2004-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms