RFC 3471
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description 🎀
Part 1 of 7 💅
Okay bestie, the title block first! 🦋 Authors: L. Berger, Editor, from Movaz Networks. Category: Standards Track. Date: January 2003. Obsoletes/Updates: this header doesn't list anything it obsoletes or updates. ✨
Status of This Memo 💖
Lowkey the most important bit: this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) document. Distribution of this memo is unlimited! 🌸
Copyright Notice 📜
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🧚
Okay so this document describes extensions to Multi-Protocol Label Switching (MPLS) signaling that are required to support Generalized MPLS. GMPLS extends the MPLS control plane so it covers time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). It's giving "one control plane to rule them all" 👑
This doc gives a functional description of those extensions. The protocol specific formats and mechanisms, plus the technology specific details, are specified in separate documents. Iykyk 🫶
Table of Contents 🍓
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. Label Related Formats ..................................... 6
3.1 Generalized Label Request ............................... 6
3.2 Generalized Label ....................................... 11
3.3 Waveband Switching ...................................... 12
3.4 Suggested Label ......................................... 13
3.5 Label Set ............................................... 14
4. Bidirectional LSPs ......................................... 16
4.1 Required Information .................................... 17
4.2 Contention Resolution ................................... 17
5. Notification on Label Error ................................ 20
6. Explicit Label Control ..................................... 20
6.1 Required Information .................................... 21
7. Protection Information ..................................... 21
7.1 Required Information .................................... 22
8. Administrative Status Information .......................... 23
8.1 Required Information .................................... 24
9. Control Channel Separation ................................. 25
9.1 Interface Identification ................................ 25
9.2 Fault Handling .......................................... 27
10. Acknowledgments ............................................ 27
11. Security Considerations .................................... 28
12. IANA Considerations ........................................ 28
13. Intellectual Property Considerations ....................... 29
14. References ................................................. 29
14.1 Normative References ................................... 29
14.2 Informative References ................................. 30
15. Contributors ............................................... 31
16. Editor's Address ........................................... 33
17. Full Copyright Statement ................................... 341. Introduction ✨
Okay so the MPLS architecture [RFC3031] was defined to support forwarding data based on a label. In that architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that can do two things: (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). 🧠
The original architecture has recently been extended to cover LSRs whose forwarding plane recognizes neither packet nor cell boundaries. So these LSRs can't forward data based on the info in either packet or cell headers. Realistically, that means devices where the forwarding decision is based on time slots, wavelengths, or physical ports. Main character energy 🦋
So LSRs (or, more precisely, the interfaces on LSRs) can be split into these four classes:
- Interfaces that recognize packet/cell boundaries and can forward data based on the content of the packet/cell header. Examples include interfaces on routers that forward data based on the content of the "shim" header, and interfaces on (Asynchronous Transfer Mode) ATM-LSRs that forward data based on the ATM VPI/VCI. These are called Packet-Switch Capable (PSC). 📦
- Interfaces that forward data based on the data's time slot in a repeating cycle. An example is an interface on a SONET/SDH Cross-Connect. These are called Time-Division Multiplex Capable (TDM). ⏰
- Interfaces that forward data based on the wavelength the data is received on. An example is an interface on an Optical Cross-Connect that can operate at the level of an individual wavelength. These are called Lambda Switch Capable (LSC). 🌈
- Interfaces that forward data based on a position of the data in the real world physical spaces. An example is an interface on an Optical Cross-Connect that can operate at the level of a single (or multiple) fibers. These are called Fiber-Switch Capable (FSC). 🪞
Now the nested Label Switched Paths (LSPs) thing is so smart 😭 It lets the system scale by building a forwarding hierarchy. At the very top are FSC interfaces, then LSC, then TDM, and at the bottom are PSC interfaces. So an LSP that starts and ends on a PSC interface can get nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. That LSP can then get nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which can get nested (together with other LSPs) into an LSP that starts and ends on an FSC interface. For more on LSP hierarchies, see [MPLS-HIERARCHY]. 🪆
The LSPs that span only the first class of interfaces (PSC) are already defined in [RFC3036, RFC3212, RFC3209]. This document gives a functional description of the extensions needed to generalize the MPLS control plane so it supports each of the four classes of interfaces. Only signaling protocol independent formats and definitions are included here. The protocol specific formats are defined in [RFC3473] and [RFC3472]. Technology specific details are out of scope for this doc and will be specified in technology specific documents, such as [GMPLS-SONET]. 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 💜
2. Overview ✨
okay so bestie, generalized MPLS is basically traditional MPLS getting a glow-up 💅🎀 it supports MULTIPLE types of switching now: TDM, lambda, and fiber (port) switching. 🦋 that new stuff means the base MPLS functions had to be stretched a bit, and sometimes new features got added too. these changes hit the basic LSP properties, how labels get requested and communicated, the one-way nature of LSPs, how errors get passed around, and the info used to sync up the ingress and egress 🫶
in traditional MPLS TE, the links an LSP crosses can be a total mix of different label encodings 🌈 like an LSP might go router → router, router → ATM-LSR, and then ATM-LSR → ATM-LSR. generalized MPLS takes that even further by adding links where the label is a time slot, or a wavelength, or a position in real-world physical space 🧚 and just like traditional TE, where not every LSR can spot (IP) packet boundaries (ATM-LSRs can't, for example), generalized MPLS also supports LSRs that can't recognize (IP) packet boundaries in their forwarding plane 💀
here's the other big change: in traditional MPLS TE, an LSP carrying IP has to start and end on a router. generalized MPLS flips that by requiring an LSP to start and end on a similar type of LSR 👑 and the payloads are wilder too, now they can be SONET/SDH, or 1 or 10Gb Ethernet 🔥 all of these changes show up in how labels get requested and communicated, see Sections 3.1 and 3.2. there's also a special case of lambda switching called waveband switching, which you can read about in Section 3.3 🌸
okay now the non-PSC types of generalized MPLS LSPs (PSC meaning packet-switch capable) are different from traditional ones in one major way: bandwidth can only be allocated in discrete units, see Section 3.1.3 🙈 and there are probably (like, way) fewer labels on non-PSC links than on PSC links 😭 forwarding adjacencies (FA), see [MPLS-HIERARCHY], can help here! they may improve bandwidth utilization when allocation is only in discrete units, AND they aggregate forwarding state so you need fewer labels. iconic behavior 🍓
generalized MPLS lets an upstream node SUGGEST a label 🧚♀️ see Section 3.4. a downstream node can override that suggestion, but sometimes it costs higher LSP setup time ⭐ the suggestion is super valuable with certain optical gear where configuring the switching fabric takes forever (electrically speaking) 😩 like, micro mirrors may need to be lifted or moved, and that physical motion plus the settling time takes ages. if labels get configured in reverse (the norm), the MAPPING/Resv message might need to wait 10's of milliseconds per hop before there's a usable forwarding path 💜 suggested labels also help when recovering from nodal faults 🫶
generalized MPLS also extends the idea of restricting which labels a downstream node is allowed to pick, see Section 3.5 💅 an ingress or other upstream node can restrict the labels used by an LSP on a single hop or across the whole LSP path. this comes from the optical world, where the wavelengths used along the path have to be limited to a small subset of possible wavelengths, or even to ONE specific wavelength 🌈 why? because some equipment can only generate a few of the wavelengths the middle gear can switch, or the middle gear can't switch a wavelength at all and can only redirect it to a different fiber 🙄
traditional traffic engineered MPLS (and even LDP) is unidirectional, but generalized MPLS supports bidirectional LSPs, see Section 4 🦋 the need for them comes from non-PSC applications, for a few reasons. the big one is possible resource contention when reciprocal LSPs get allocated through separate signaling sessions 😬 and bidirectional LSPs also make failure restoration simpler in the non-PSC case. bonus perks: lower setup latency and fewer messages during setup ✨
generalized MPLS can communicate a specific label to use on a specific interface, see Section 6 🎀 [RFC3473] also has an RSVP-specific mechanism for rapid failure notification ⚡
generalized MPLS formalizes the possible separation of control and data channels, see Section 9 🌷 this matters a LOT for technologies where control traffic can't be sent in-band with the data traffic 🙌
and finally, generalized MPLS lets technology-specific parameters ride along in signaling 💖 the plan is for all of them to be carried in the SENDER_TSPEC and other related objects when using RSVP, and in the Traffic Parameters TLV when using CR-LDP. technology-specific formats will be defined on an as-needed basis, and for an example definition, check out [GMPLS-SONET] 🧚
3. Label Related Formats 🌸
okay so MPLS is getting dragged into the optical and time domains, which means several NEW forms of "label" are needed 🦋 these are collectively called a "generalized label" 💅 a generalized label has enough info for the receiving node to program its cross connect, no matter what type of cross connect it is, so the ingress segments of the path get properly joined 🫶 this section defines a generalized label request, a generalized label, support for waveband switching, suggested label, and label sets 🎀
quick note: since the nodes sending and receiving these new labels already know what kind of link they're using, the generalized label does NOT have a type field 🙈 the nodes are expected to know from context what type of label to expect 🧠
3.1. Generalized Label Request ✨
the Generalized Label Request communicates the characteristics needed to support the LSP being requested 💖 those characteristics include the LSP encoding and LSP payload 🌈 transit nodes might use them too, e.g., to support penultimate hop popping 🍓
the Generalized Label Request carries an LSP encoding parameter called LSP Encoding Type 🔥 it indicates the encoding type (e.g., SONET/SDH/GigE etc.) that'll be used with the data on the LSP 🧚 the LSP Encoding Type describes the nature of the LSP, NOT the nature of the links it crosses 👑 a link might support a set of encoding formats, where "support" means the link can carry and switch a signal in one or more of those formats, depending on resource availability and capacity 🫶
for example, picture an LSP signaled with "lambda" encoding 🦋 it's expected to be supported with no electrical conversion, and transit nodes don't need to know the modulation or speed 💫 other formats usually need framing knowledge, so their field parameters get split into framing type and speed, as shown below 🙌
the Generalized Label Request also indicates the type of switching requested on a link 💅 this field is normally consistent across ALL links of an LSP 😌
3.1.1. Required Information
okay so the Generalized Label Request carries exactly this info 💅✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+LSP Encoding Type: 8 bits 🎀
This tells you what encoding the LSP you're asking for is gonna use. Here's the permitted list and what each one means:
Value Type
----- ----
1 Packet
2 Ethernet
3 ANSI/ETSI PDH
4 Reserved
5 SDH ITU-T G.707 / SONET ANSI T1.105
6 Reserved
7 Digital Wrapper
8 Lambda (photonic)
9 Fiber
10 Reserved
11 FiberChannelANSI PDH and ETSI PDH are two separate networking techs, and DS1 and DS3 are examples of ANSI PDH LSPs 🌸 An E1 LSP would be ETSI PDH. Lambda is for an LSP that covers a whole wavelength, and Fiber is for an LSP that covers a whole fiber port 🦋
Switching Type: 8 bits 💖
This says what kind of switching should happen on a particular link. It only really matters for links that advertise more than one switching capability. The value should map to one of the ones advertised for that link in the routing Switching Capability Descriptor, see [GMPLS-RTG].
These are the currently defined values:
Value Type
----- ----
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 Layer-2 Switch Capable (L2SC)
100 Time-Division-Multiplex Capable (TDM)
150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)Generalized PID (G-PID): 16 bits 🧚
This is the ID for the payload the LSP is carrying, aka the client layer of that LSP. The nodes at the endpoints use it, and sometimes the penultimate hop does too 👑 Packet and Ethernet LSPs use standard Ethertype values. Everything else is in this table:
Value Type Technology
----- ---- ----------
0 Unknown All
1 Reserved
2 Reserved
3 Reserved
4 Reserved
5 Asynchronous mapping of E4 SDH
6 Asynchronous mapping of DS3/T3 SDH
7 Asynchronous mapping of E3 SDH
8 Bit synchronous mapping of E3 SDH
9 Byte synchronous mapping of E3 SDH
10 Asynchronous mapping of DS2/T2 SDH
11 Bit synchronous mapping of DS2/T2 SDH
12 Reserved
13 Asynchronous mapping of E1 SDH
14 Byte synchronous mapping of E1 SDH
15 Byte synchronous mapping of 31 * DS0 SDH
16 Asynchronous mapping of DS1/T1 SDH
17 Bit synchronous mapping of DS1/T1 SDH
18 Byte synchronous mapping of DS1/T1 SDH
19 VC-11 in VC-12 SDH
20 Reserved
21 Reserved
22 DS1 SF Asynchronous SONET
23 DS1 ESF Asynchronous SONET
24 DS3 M23 Asynchronous SONET
25 DS3 C-Bit Parity Asynchronous SONET
26 VT/LOVC SDH
27 STS SPE/HOVC SDH
28 POS - No Scrambling, 16 bit CRC SDH
29 POS - No Scrambling, 32 bit CRC SDH
30 POS - Scrambling, 16 bit CRC SDH
31 POS - Scrambling, 32 bit CRC SDH
32 ATM mapping SDH
33 Ethernet SDH, Lambda, Fiber
34 SONET/SDH Lambda, Fiber
35 Reserved (SONET deprecated) Lambda, Fiber
36 Digital Wrapper Lambda, Fiber
37 Lambda Fiber
38 ANSI/ETSI PDH SDH
39 Reserved SDH
40 Link Access Protocol SDH SDH
(LAPS - X.85 and X.86)
41 FDDI SDH, Lambda, Fiber
42 DQDB (ETSI ETS 300 216) SDH
43 FiberChannel-3 (Services) FiberChannel
44 HDLC SDH
45 Ethernet V2/DIX (only) SDH, Lambda, Fiber
46 Ethernet 802.3 (only) SDH, Lambda, Fiber3.1.2. Bandwidth Encoding
okay bandwidth time 🍓 Bandwidth gets carried in a 32 bit number in IEEE floating point format, and the unit is bytes per second. For non-packet LSPs it's handy to have discrete values that name the bandwidth, so here are some typical requested-bandwidth values. (These are guidelines, not rules 🙈) More values will get added as they're needed. How the bandwidth values get carried depends on the protocol, see [RFC3473] and [RFC3472].
Signal Type (Bit-rate) Value (Bytes/Sec)
(IEEE Floating point)
-------------- --------------- ---------------------
DS0 (0.064 Mbps) 0x45FA0000
DS1 (1.544 Mbps) 0x483C7A00
E1 (2.048 Mbps) 0x487A0000
DS2 (6.312 Mbps) 0x4940A080
E2 (8.448 Mbps) 0x4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 Mbps) 0x4A831A80
DS3 (44.736 Mbps) 0x4AAAA780
STS-1 (51.84 Mbps) 0x4AC5C100
Fast Ethernet (100.00 Mbps) 0x4B3EBC20
E4 (139.264 Mbps) 0x4B84D000
FC-0 133M 0x4B7DAD68
OC-3/STM-1 (155.52 Mbps) 0x4B9450C0
FC-0 266M 0x4BFDAD68
FC-0 531M 0x4C7D3356
OC-12/STM-4 (622.08 Mbps) 0x4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
FC-0 1062M 0x4CFD3356
OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0
OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
OC-768/STM-256 (39813.12 Mbps) 0x4F9450C03.2. Generalized Label
okay so the Generalized Label is the upgraded version of the regular label 🦋 A regular label only covers labels that travel in-band with the data packets. The Generalized one can also stand for time-slots, wavelengths, or space division multiplexed positions. For example, it can point at (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 carry a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI) ✨
A Generalized Label doesn't say what "class" the label belongs to. That's implied by the multiplexing abilities of the link it's used on 💜
A Generalized Label only carries one level of label, so it's non-hierarchical. If you need multiple levels (LSPs within LSPs), each LSP must be set up separately, see [MPLS-HIERARCHY].
Each Generalized Label object/TLV carries a variable length label parameter 🌈
3.2.1. Required Information
the info a Generalized Label carries is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Label: Variable Length 🫶
This carries the label info. What it means depends on the type of link the label is used on.
3.2.1.1. Port and Wavelength Labels
some configs of fiber switching (FSC) and lambda switching (LSC) use multiple data channels/links that are all controlled by one single control channel 🌸 In that case the label tells you which data channel/link to use for the LSP. Heads up, this is NOT the same thing as when [MPLS-BUNDLE] is in use ⭐
The info a Port and Wavelength label carries is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Label: 32 bits 💅
This indicates the port/fiber or lambda to use, from the sender's point of view. The values only mean something between two neighbors, so the receiver may need to convert what it gets into a value that makes sense locally 🦋 The values can be configured, or figured out dynamically with a protocol like [LMP].
3.2.1.2. Other Labels
generic MPLS labels and Frame Relay labels are encoded right justified in 32 bits (4 octets) 🎀 ATM labels are different: the VPI is right justified in bits 0-15, and the VCI is right justified in bits 16-31 💖
3.3. Waveband Switching
okay waveband switching is a special case of lambda switching 🌈 A waveband is a set of contiguous wavelengths that can get switched together as one new waveband. For optimization reasons, an optical cross connect might want to optically switch multiple wavelengths as a unit. That can cut down on distortion on the individual wavelengths and allow tighter separation between them ✨ The Waveband Label exists to support this special case.
Waveband switching naturally adds another level of label hierarchy, so the waveband gets treated the same way all the other upper layer labels do 👑
As far as the MPLS protocols are concerned, a waveband label and a wavelength label are pretty much the same, except that semantically a waveband can be split up into wavelengths, while a wavelength can only be split into time or statistically multiplexed labels 🧚
3.3.1. Required Information ✨
okay so waveband switching uses the same format as the generalized label, so go peek at section 3.2.1 if you need the basics 💅
here's the waveband version of the generalized label 🌈:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Waveband Id: 32 bits 🎀
A waveband identifier! The sender picks the value, and then it gets reused in every related message after that.
Start Label: 32 bits 🌸
This is the channel identifier of the lowest-valued wavelength making up the waveband, seen from the object/TLV sender's perspective.
End Label: 32 bits 🌸
This is the channel identifier of the highest-valued wavelength making up the waveband, seen from the object/TLV sender's perspective.
Channel identifiers are established either by configuration or by means of a protocol such as LMP [LMP]. They are normally used in the label parameter of the Generalized Label one PSC and LSC.
3.4. Suggested Label 🦋
The Suggested Label is how an upstream node tells a downstream node its label preference 💜 That lets the upstream node start configuring its hardware with the proposed label before the downstream node actually sends back a label. Early setup is a huge deal for systems that take a while to get a label working in hardware. It can cut setup latency, and it can matter for restoration, where backup LSPs may need to come up fast after network failures 🔥
The Suggested Label is only an optimization, so don't stress 🫶 If the downstream node passes a different label upstream, the upstream LSR reconfigures itself to use the label the downstream node gave it. That keeps the downstream node in control of the label. Also, just because a suggested label was sent doesn't mean it's usable yet. An ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream ⏳
The information in a suggested label is identical to a generalized label. Values in the label field of a suggested label are from the object/TLV sender's perspective.
3.5. Label Set 🍓
The Label Set limits which label choices a downstream node is allowed to make, to a set of acceptable labels. This limit applies on a per-hop basis.
We describe four cases where a Label Set is useful in the optical domain:
- The end equipment can only transmit on a small, specific set of wavelengths or bands.
- There's a sequence of interfaces that can't do wavelength conversion (CI-incapable) and need the same wavelength end-to-end, across a sequence of hops or even a whole path.
- It's desirable to limit how much wavelength conversion happens, to reduce distortion on the optical signals.
- The two ends of a link support different sets of wavelengths.
A Label Set is used to restrict the label ranges that may be used for a particular LSP between two peers. The receiver of a Label Set must restrict its choice of labels to one that's in the Label Set. Much like a label, a Label Set may be present across multiple hops. In that case, each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces 💅
The use of Label Set is optional. If it's not present, all labels from the valid label range may be used. Conceptually, the absence of a Label Set implies a Label Set whose value is {U}, the set of all valid labels ✨
3.5.1. Required Information 💖
A label set is made up of one or more Label_Set objects/TLVs. Each object/TLV holds one or more elements of the Label Set. Each element is called a subchannel identifier, and it has the same format as a generalized label.
The information carried in a Label_Set looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Action: 8 bits 🌷
0- Inclusive List: the object/TLV has one or more subchannel elements that are included in the Label Set.1- Exclusive List: the object/TLV has one or more subchannel elements that are excluded from the Label Set.2- Inclusive Range: the object/TLV has a range of labels. It carries two subchannel elements. The first is the start of the range and the second is the end. A value of zero means there's no bound on that part of the range.3- Exclusive Range: the object/TLV has a range of labels that are excluded from the Label Set. It carries two subchannel elements. The first is the start of the range and the second is the end. A value of zero means there's no bound on that part of the range.
Reserved: 10 bits 🫧
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Hands off, bestie 🙅♀️
Label Type: 14 bits 🧚
This tells you the type and format of the labels carried in the object/TLV. The values are specific to the signaling protocol.
Subchannel: 🌈
The subchannel is the label (wavelength, fiber ... ) that's eligible for allocation. It has the same format as described for labels under section 3.2.
Subchannel-to-local-channel-identifier mappings (e.g., wavelength) are a local matter 🤫
4. Bidirectional LSPs 🌈
This section defines direct support for bidirectional LSPs, and it's a whole vibe 🦋 Support is defined for LSPs that have the same traffic engineering requirements in each direction, including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter). In the rest of this section, "initiator" means the node that starts establishing an LSP, and "terminator" means the node that is the target of the LSP. For bidirectional LSPs there is only one "initiator" and one "terminator" 💜
Normally, to set up a bidirectional LSP when using [RFC3209] or [RFC3212], two unidirectional paths have to be established independently. Honestly this approach has some real downsides 😭
- The latency to set up the bidirectional LSP is one round trip signaling time plus one initiator-terminator signaling transit delay. That doesn't just slow down successful setup, it can also stretch the worst-case time to discover a failed LSP to as much as two times the initiator-terminator transit delay. These delays really matter for LSPs set up for restoration.
- The control overhead is twice that of a unidirectional LSP, because separate control messages (e.g., Path and Resv) must be generated for both segments of the bidirectional LSP.
- Since the resources are set up in separate segments, route selection gets complicated. There's also extra potential for race conditions when assigning resources, which lowers the overall chance of successfully establishing the bidirectional connection.
- It's harder to provide a clean interface for SONET/SDH equipment that may rely on bidirectional hop-by-hop paths for protection switching.
- Bidirectional optical LSPs (or lightpaths) are seen as a requirement by many optical networking service providers ✨
With bidirectional LSPs, both the downstream and upstream data paths (from initiator to terminator, and from terminator to initiator) are set up using a single set of signaling messages. That cuts setup latency down to about one initiator-terminator round trip time plus processing time, and keeps the control overhead to the same number of messages as a unidirectional LSP. Iconic 👑
4.1. Required Information 🎀
For bidirectional LSPs, two labels must be allocated. Bidirectional LSP setup is indicated by the presence of an Upstream Label object/TLV in the appropriate signaling message. An Upstream Label has the same format as the generalized label, see Section 3.2 🫶
4.2. Contention Resolution 💥
okay bestie, so label contention can happen when two bidirectional LSP setup requests are zooming in opposite directions 🦋 It's giving collision. It shows up when both sides grab the exact same resources (labels) at basically the same moment 😭 If there's no restriction on which labels can be used for bidirectional LSPs AND there are alternate resources, both nodes just pass different labels upstream and... no contention!! ✨ But if there is a restriction (like, they have to be physically coupled on a single I/O card 👀) or there are no more resources left, then the contention has to be resolved by other means 💅
To resolve it, the node with the higher node ID wins, and it MUST issue a PathErr/NOTIFICATION message with a "Routing problem/Label allocation failure" indication 👑 When that error lands, the node SHOULD try to allocate a different Upstream label (and a different Suggested Label, if one is being used) to the bidirectional path 🔁 But if no other resources are available? Then the node must proceed with standard error handling 💀
To lower the odds of contention even more, you can impose a policy where the lower-ID node never suggests a label in the downstream direction and always accepts a Suggested Label from an upstream node with a higher ID 🧚 Since labels can be exchanged using LMP, there's also an optional local policy 🌈 With respect to the higher numbered node's label set, the higher numbered node allocates labels from the high end of the label range, while the lower numbered node allocates from the low end. This would augment any close packing algorithms used for bandwidth (or wavelength) optimization. Iconic behavior, honestly 🤌
One special case to note when using RSVP with this approach: the neighbor's node ID might not be known yet when sending an initial Path message. When that happens, a node should suggest a label chosen at random from the available label space 🎲
Here's an example of contention between two nodes, PXC 1 and PXC 2, in Figure 1 🍓 PXC 1 assigns an Upstream Label for the channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and sends a Suggested Label for the channel corresponding to local BCId=1 (local BCId=6 on PXC 2). At the very same time, PXC 2 assigns an Upstream Label for its local BCId=6 (local BCId=1 on PXC 1) and sends a Suggested Label for its local BCId=7 (local BCId=2 on PXC 1). If there's no restriction on the labels for bidirectional LSPs and there are alternate resources available, then both PXC 1 and PXC 2 pass different labels upstream, and the contention is resolved naturally (see Fig. 2). But if there is a restriction on the labels (for example, if they must be physically coupled on a single I/O card), then the contention must be resolved using the node ID (see Fig. 3) 🫶
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + SL1,UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1, SL2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + + +
+ 3 +------------------------>+ 8 +
+ + + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 1. Label ContentionIn this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1).
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + L2 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 2. Label Contention Resolution without resource restrictionsIn this example, there's no restriction on the labels that the bidirectional connection can use, so there's no contention 🦋
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + L2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + UL1 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 3. Label Contention Resolution with resource restrictionsIn this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on PXC 2, respectively) must be used by the same bidirectional connection. Since PXC 2 has a higher node ID, it wins the contention, and PXC 1 must use a different set of labels 👑
5. Notification on Label Error 🚨
Okay so there are cases in traditional MPLS and in GMPLS that produce an error message with an "Unacceptable label value" indication, see [RFC3209], [RFC3472] and [RFC3473]. When that happens, it's super useful for the node that generated the error to say which labels would be acceptable 🙏 GMPLS introduces the ability to share that info via the "Acceptable Label Set". An Acceptable Label Set is carried in the appropriate protocol specific error messages, see [RFC3472] and [RFC3473].
The format of an Acceptable Label Set is identical to a Label Set, see section 3.5.1. Same vibes, different job 💜
6. Explicit Label Control 🎀
In traditional MPLS, the interfaces an LSP uses can be controlled with an explicit route, i.e., ERO or ER-Hop. This lets you include a particular node/interface, and terminate an LSP on a particular outgoing interface of the egress LSR. Whether the interface is numbered or unnumbered, see [MPLS-UNNUM] 🧭
But here's the tea: sometimes the existing explicit route semantics aren't enough to control the LSP the way you want 😤 That happens when the LSP initiator wants to pick a label used on a link. The problem is that ERO and ER-Hop don't support explicit label sub-objects. A great example of when you'd want this is when two LSPs need to be "spliced" together, meaning the tail of the first LSP gets spliced into the head of the second LSP. This last case is more likely to be used in the non-PSC classes of links 🍓
To cover all of this, the Label ERO subobject / ER Hop is introduced ✨
6.1. Required Information
The Label Explicit and Record Routes contains:
L: 1 bit: This bit must be set to 0.U: 1 bit: This bit indicates the direction of the label. It is 0 for the downstream label. It is set to 1 for the upstream label and is only used on bidirectional LSPs.Label: Variable: This field identifies the label to be used. The format of this field is identical to the one used by the Label field in Generalized Label, see Section 3.2.1.
Placement and ordering of these parameters are signaling protocol specific 🧩
7. Protection Information 🛡️
Protection Information is carried in a new object/TLV, and it's used to indicate link related protection attributes of a requested LSP. Using Protection Information for a particular LSP is optional 🌸 Right now, it only indicates the link protection type desired for the LSP. If a particular protection type (like 1+1 or 1:N) is requested, then a connection request only gets processed if that protection type can actually be honored 👀 The protection capabilities of a link may be advertised in routing, see [GMPLS-RTG]. Path computation algorithms can take this into account when computing paths for setting up LSPs. Smart, right? 🧠
Protection Information also says 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 not used until the primary LSP fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP using the resources for the secondary LSP MUST be preempted 😭 no cap, that's a whole plot twist 💀
7.1. Required Information 🎀
okay so Protection Information carries this stuff, bestie 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Secondary (S): 1 bit 🦋. When it's set, the requested LSP is a secondary LSP. Main character energy.
- Reserved: 25 bits 🌸. This field is reserved, so it MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes. Don't touch the reserved stuff, it's not yours 🙈
- Link Flags: 6 bits ✨. This is how you ask for a desired link protection type. Protection capabilities of a link may be advertised in routing, so you can check ahead. A value of
0means any link protection is fine, even none at all. You can set more than one bit if multiple protection types are acceptable. And when multiple bits are set and multiple protection types are available, picking the protection type is a local policy decision 💅
The flags you can use are:
0x20Enhanced 🔥: a protection scheme that's more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING. Very reliable, very iconic.0x10Dedicated 1+1 👑: a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP.0x08Dedicated 1:1 🍓: a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP.0x04Shared 🦋: a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP.0x02Unprotected 🫶: the LSP should not use any link layer protection.0x01Extra Traffic 🧚: the LSP should use links that are protecting other (primary) traffic. Lowkey risky, because these LSPs may be preempted when the links carrying the (primary) traffic being protected fail 💀
8. Administrative Status Information 🌈
okay, Administrative Status Information gets its own new object/TLV, and it's currently used in two ways 💜
In the first way, it tells you the administrative state of a particular LSP. State indications include "up" or "down", whether it's in a "testing" mode, and whether deletion is in progress. The actions a node takes based on that state are a local decision. One example: a node can inhibit alarm reporting when an LSP is in "down" or "testing" states, or report alarms tied to the connection at a priority equal to or less than "Non service affecting" ⭐
In the second way, it's a request to set an LSP's administrative state. This info is always relayed to the ingress node, and the ingress node is the one that acts on the request 🎀
The two usages are told apart in a protocol specific fashion. Check out [RFC3473] and [RFC3472] for the details. And using Administrative Status Information for a particular LSP is optional 🌸
8.1. Required Information ✨
Here's what goes in Administrative Status Information:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Reflect (R): 1 bit 🪞. When it's set, the edge node SHOULD reflect the object/TLV back in the appropriate message. This bit MUST NOT be set in state change request, i.e., Notify, messages. Don't set it in Notify messages, bestie, that's a hard no 🙅♀️
- Reserved: 28 bits 🌸. This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.
- Testing (T): 1 bit 🧪. When it's set, the local actions related to the "testing" mode should be taken.
- Administratively down (A): 1 bit ⬇️. When it's set, the local actions related to the "administratively down" state should be taken.
- Deletion in progress (D): 1 bit 🗑️. When it's set, the local actions related to LSP teardown should be taken. Edge nodes can use this flag to control connection teardown, so they're basically in charge of the drama 👑
9. Control Channel Separation 🧚
so the idea of a control channel being different from the data channel being signaled first showed up in MPLS with link bundling, see [MPLS-BUNDLE]. In GMPLS, the control and data channels can be separated for all kinds of reasons. Bundling is one, and so are data channels that can't carry in-band control information. This section covers two critical related issues: figuring out which data channels are being signaled, and handling control channel failures that don't hurt data channels 💖
9.1. Interface Identification 🦋
In traditional MPLS, there's an implicit one-to-one link between a control channel and a data channel. When that link is there, you don't need any extra info to tie a particular LSP setup transaction to a particular data channel. It's already baked in, because it's implicit in the control channel the signaling messages get sent over 🫶
When there isn't an explicit one-to-one association between control channels and data channels, you have to add extra info to signaling so you can identify the exact data channel being controlled. GMPLS supports explicit data channel identification through interface identification information. You can use a number of interface identification schemes: IPv4 or IPv6 addresses, interface indexes (see [MPLS-UNNUM]), and component interfaces (set up through configuration or a protocol such as [LMP]). Either way, the upstream node indicates which data interface it chose, using the addresses and identifiers that the upstream node uses 🌈
9.1.1. Required Information 💅
Here's what goes in Interface_ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And each TLV looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Length: 16 bits 📏. This is the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length isn't a multiple of four MUST be zero-padded so that the TLV is four-octet aligned. Padding is non-negotiable, bestie 🙅♀️
- Type: 16 bits 🏷️. This says what type of interface is being identified. The defined values are:
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 See below IF_INDEX (Interface Index)
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 See below COMPONENT_IF_UPSTREAM (Component interface)For types 3, 4 and 5, the Value field looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IP Address: 32 bits 🌐. This field can carry either the IP address of a link, or an IP address associated with the router. The associated address is the value carried in a router address TLV of routing.
- Interface ID: 32 bits 🆔. For type 3 usage, the Interface ID carries an interface identifier. For types 4 and 5, the Interface ID indicates a bundled component link. The special value
0xFFFFFFFFcan be used to indicate that the same label is to be valid across all component links 🔥
9.2. Fault Handling 🚨
There are two new faults you have to handle when the control channel is independent of the data channel. In the first, a link or some other failure limits how well neighboring nodes can pass control messages. So the neighbors can't exchange control messages for a while. Once communication comes back, the underlying signaling protocol must indicate that the nodes kept their state through the failure. The signaling protocol must also make sure that any state changes made during the failure get synchronized between the nodes 🫶
In the second, a node's control plane fails, restarts, and loses most of its state information. Now both the upstream and downstream nodes have to sync their state with the restarted node. For any resynchronization to happen, the restarting node has to preserve some information, such as its mappings of incoming to outgoing labels. Otherwise, there's nothing to sync back to 💀
Both cases are handled in protocol specific fashions. See [RFC3473] and [RFC3472] 🌸
Heads up: these cases only apply when there are mechanisms to detect data channel failures independently of control channel failures. No detection, no special handling, bestie 💜
10. Acknowledgments 🫶
this document is the work of loads of authors, and it's a composition of a bunch of previous documents in this area 🌈
Valuable comments and input came in from a bunch of people, including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this document are based on text proposed by Fong Liaw. Thank you, legends ✨
11. Security Considerations 🔐
okay, this part is SERIOUS, so pay attention 😭
This document introduces no new security considerations to either [RFC3212] or [RFC3209]. The security considerations mentioned in [RFC3212] or [RFC3209] apply to the respective protocol specific forms of GMPLS, see [RFC3473] and [RFC3472]. So go read those too, no skipping 💅
12. IANA Considerations ✨
okay so the IANA is the one who handles new values for the namespaces in this doc 📋 this section follows the vibe of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26] 🎀
This document defines these namespaces:
LSP Encoding Type: 8 bits 🌸Switching Type: 8 bits 🦋Generalized PID (G-PID): 16 bits 💜Action: 8 bits ✨Interface_ID Type: 16 bits 🧚
all future assignments should be allocated through IETF Consensus action or documented in a Specification. that's the rule, bestie 💅
LSP Encoding Type: the valid range is 1-255 and this doc defines values 1-11 🌈
Switching Type: the valid range is 1-255 and this doc defines values 1-4, 100, 150 and 200 🔥
Generalized PID (G-PID): the valid range is 0-1500 and this doc defines values 0-46 👑
Action: the valid range is 0-255 and this doc defines values 0-3 💖
Interface_ID Type: the valid range is 1-65535 and this doc defines values 1-5 🫶
13. Intellectual Property Considerations
this section is taken from Section 10.4 of [RFC2026] 🍓
so the IETF doesn't take a side on whether any IP rights people claim around this tech are valid or how far they reach, and it doesn't say whether licenses are available either 🙈 it also doesn't claim it went hunting for every possible right. info on how the IETF handles rights for standards-track and standards-related docs lives in BCP-11. if someone has filed claims of rights for publication, or promised to make licenses available, or tried to get a general license or permission for implementers or users to use proprietary rights, you can get those from the IETF Secretariat 📬
the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard ✨ send that info to the IETF Executive Director 💌
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC 3036,
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.
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors,
"Generalized Multi-Protocol Label Switching (GMPLS)
Signaling - Constraint-based Routed Label
Distribution Protocol (CR-LDP) Extensions", RFC
3472, January 2003.
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.14.2. Informative References
[GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support
of Generalized MPLS", Work in Progress.
[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH
Specifics", Work in Progress.
[LMP] Lang, et al., "Link Management Protocol", Work in
Progress.
[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link
Bundling in MPLS Traffic Engineering", Work in
Progress.
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC 2434, October 1998.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol label switching Architecture", RFC
3031, January 2001.15. Contributors
these are the lovely people who helped make this doc happen 🫶
Peter Ashwood-Smith
Nortel Networks Corp.
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
EMail: gregb@grotto-networking.com
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan
Axiowave Networks, Inc.
200 Nickerson Road
Marlborough, MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang
EMail: jplang@ieee.org
Eric Mannie
Independent Consultant
2 Avenue de la Folle Chanson
1050 Brussels
Belgium
EMail: eric_mannie@hotmail.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net
Debanjan Saha
EMail: debanjan@acm.org
Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang
EMail: botang01@yahoo.com16. Editor's Address
the editor's contact details are right here 💌
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com17. Full Copyright Statement
copyright (C) The Internet Society (2003). all rights reserved. 🎀
okay this part is a lot but it's important so read it all 🙈 you can copy and share this document, and you can make derivative works that comment on or explain it or help implement it. all of that is allowed without restriction, as long as the copyright notice and this paragraph stay on every copy and derivative work. the document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are when you're developing Internet standards (then the procedures for copyrights defined in the Internet Standards process must be followed) or when you're translating it into languages other than English. 💅
the limited permissions above are perpetual and the Internet Society or its successors or assigns will not revoke them ✨
this document and the information in it is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🙈💀
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society 🌈 thank you to them for keeping the lights on, bestie 🫶
📦 where this page comes from
- ietf: rfc3471 2003-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms