RFC 3472
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions ✨
- RFC: 3472
- Authors: P. Ashwood-Smith (Editor, Nortel Networks) and L. Berger (Editor, Movaz Networks) 👑
- Working group: Network Working Group
- Category: Standards Track 🎀
- Date: January 2003 🌸
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🫶
Status of this Memo 📜
bestie, this one is an Internet standards track protocol for the Internet community, and it's basically asking for discussion and suggestions to make it better 💖. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved. 💅
Abstract 🌈
okay so this doc describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling that are required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to cover 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) 🔥. This doc gives a CR-LDP specific description of those extensions. A generic functional description can be found in separate documents 🧚.
Table of Contents 🍓
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request ............................... 3
2.2 Generalized Label ....................................... 4
2.3 Waveband Switching ...................................... 5
2.4 Suggested Label ......................................... 6
2.5 Label Set ............................................... 6
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 8
4. Notification on Label Error ............................... 9
5. Explicit Label Control .................................. 9
5.1 Procedures .............................................. 9
6. Protection TLV ............................................ 10
6.1 Procedures .............................................. 11
7. Administrative Status Information ......................... 11
7.1 Admin Status TLV ........................................ 11
7.2 REQUEST and MAPPING Message Procedures .................. 12
7.3 Notification Message Procedures ......................... 13
8. Control Channel Separation ................................ 14
8.1 Interface Identification ................................ 14
8.2 Errored Interface Identification ........................ 15
9. Fault Handling ......................................... 17
10 Acknowledgments ........................................... 17
11. Security Considerations ................................... 17
12. IANA Considerations ....................................... 17
13. Intellectual Property Considerations ...................... 18
14. References ................................................ 18
14.1 Normative References ................................... 18
14.2 Informative References ................................. 19
15. Contributors .............................................. 19
16. Editors' Addresses ........................................ 22
17. Full Copyright Statement ................................... 231. Introduction ✨
okay so Generalized MPLS takes MPLS beyond packet (PSC) interfaces and switching and adds three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC) 🦋. The functional description of the extensions to MPLS signaling that these new classes need is in [RFC3471]. This doc gives the CR-LDP specific formats and mechanisms needed to support all four classes of interfaces 💅. RSVP-TE extensions can be found in [RFC3473].
[RFC3471] is basically the bestie of this doc 🫶, and this doc's format parallels [RFC3471]. It should be noted that the RSVP-TE specific version of Generalized MPLS includes RSVP specific support for rapid failure notification, see Section 4 [RFC3473]. For CR-LDP there is not currently a similar mechanism 💀. When a failure is detected, it gets propagated with RELEASE/WITHDRAW messages radially outward from the point of failure 🔥. Resources are to be released in this phase, and actual resource information may be fed back to the source using a feedback mechanisms.
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. Label Related Formats 🌸
this section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets 🍓.
2.1. Generalized Label Request 💖
A REQUEST message SHOULD contain as specific an LSP (Label Switched Path) Encoding Type as possible, so there's maximum flexibility in switching by transit LSRs 🧚. A Generalized Label Request Type, Length, and Value (TLV) gets set by the ingress node, is transparently passed along by transit nodes, and is used by the egress node. The Switching Type field may also be updated hop-by-hop ✨.
the format of a Generalized Label Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0824) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+see [RFC3471] for a description of parameters 📖.
2.1.1. Procedures 🔥
a node processing a REQUEST message that contains a Generalized Label Request must verify that the requested parameters can be satisfied by the incoming interface, the node and the outgoing interface 👑. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked 💅.
note that local node policy dictates when tunnels may be used and when they may be created 🌈. Local policy may allow tunnels to be dynamically established, or they may be solely administratively controlled. For more information on tunnels and processing of ER (Explicit Route) hops when using tunnels, see [MPLS-HIERARCHY] 🦋.
Transit and egress nodes MUST verify that the node itself and, where appropriate, the outgoing interface or tunnel can support the requested LSP Encoding Type 🚨. If the encoding can't be supported, the node MUST generate a NOTIFICATION message with a Routing problem/Unsupported Encoding indication 💀.
Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface 🫶. If the type can't be supported, the node MUST generate a NOTIFICATION message with a Routing problem/Switching Type indication 😭.
The G-PID parameter is normally only examined at the egress 🧚. If the indicated G-PID can't be supported, then the egress MUST generate a NOTIFICATION message with a Routing problem/Unsupported G-PID indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G-PID during the processing of the MAPPING message 🍓. In this case, if the G-PID is not supported, then the penultimate hop MUST generate a NOTIFICATION message with a Routing problem/Unacceptable label value indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4 ✨.
When an error message is not generated, normal processing occurs. In the transit case, this will typically result in a REQUEST message being propagated. In the egress case and the PHP special case, this will typically result in a MAPPING message being generated 🌸.
2.1.2. Bandwidth Encoding 💖
Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. See [RFC3471] for a definition of values to be used for specific signal types. These values are set in the Peak and Committed Data Rate fields of the Traffic Parameters TLV. Other bandwidth/service related parameters in the TLV are ignored and carried transparently 🎀.
2.2. Generalized Label 🦋
the format of a Generalized Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0825) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+see [RFC3471] for a description of parameters and encoding of labels 🧚.
2.2.1. Procedures ✨
The Generalized Label travels in the upstream direction in MAPPING messages 🌈.
The presence of both a generalized and a normal label TLV in a MAPPING message is a protocol error and should treated as a malformed message by the recipient 💀.
The recipient of a MAPPING message containing a Generalized Label verifies that the values passed are acceptable 🔍. If the label is unacceptable, then the recipient MUST generate a NOTIFICATION message with a Routing problem/MPLS label allocation failure indication 😭. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4 🫶.
2.3. Waveband Switching 🌊
Waveband switching uses the same format as the generalized label, see section 2.2. The type 0x0828 is assigned for the Waveband Label 💜.
in the context of waveband switching, the generalized label has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0828) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+see [RFC3471] for a description of parameters 📖.
2.3.1. Procedures 🎀
okay so the procedures from Section 2.2.1 apply to waveband switching too 💅 That includes sending a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable 😭
this next part is my fave ngl 🪞 When a waveband gets switched to another waveband, the wavelengths inside it can get mirrored around a center frequency. When that kind of switching is used, the start and end label in the waveband label TLV MUST be swapped before the label TLV gets forwarded with the new waveband Id. That way an egress/ingress LSR that receives a waveband label with those values flipped knows it has to flip its own egress association too, so it grabs the right wavelengths 🦋 Without this, and with an odd number of mirrored switching operations, the egress LSRs would have no clue that an input wavelength of say L1 comes out of the waveband tunnel as L100 💀
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established 🫶
2.4. Suggested Label 🌸
the format of a suggested label is exactly the same as a generalized label 🧚 It's used in REQUEST messages, and Suggested Label uses type = 0x904.
Errors in received Suggested Labels MUST be ignored 🙈 This includes any received inconsistent or unacceptable values.
okay, so per [RFC3471], if a downstream node passes a label value that's different from the suggested label, the upstream LSR MUST either reconfigure itself so it uses the label the downstream node gave, or generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication 👑 Also, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes the corresponding label upstream. bestie, be patient 🥹
2.5. Label Set 🦋
the format of a Label Set 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0827) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Label Type is 14 bits 🍓 It tells you the type and format of the labels carried in the TLV, and the values match the TLV type of the appropriate Label TLV.
see [RFC3471] for a description of the other parameters ✨
2.5.1. Procedures 💖
a Label Set is defined through one or more Label Set TLVs. Specific labels/subchannels can be added to or excluded from a Label Set using Action zero (0) and one (1) TLVs, and ranges can be added or excluded using Action two (2) and three (3) TLVs. When the Label Set TLVs only list labels/subchannels to exclude, that means all the other labels are acceptable 🫶
no Label Set TLVs at all means every label is acceptable. A Label Set gets included when a node wants to restrict the label(s) that can be used downstream 🔥
when a REQUEST message comes in, the receiving node restricts its choice to one label that's in the Label Set. Nodes that can do label conversion may also remove the Label Set before forwarding the REQUEST message. If the node can't pick a label from the Label Set, or there's a problem parsing the Label Set TLVs, the request gets terminated and a NOTIFICATION message with a "Routing problem/Label Set" indication MUST be generated 😭 It's a local matter whether the Label Set gets stored for later selection on the MAPPING message or the selection happens right away for propagation in the MAPPING message.
also, on reception of a REQUEST message, the Label Set in the message gets compared against the set of available labels at the downstream interface, and the resulting intersecting Label Set is forwarded in a REQUEST message. When the resulting Label Set is empty, the REQUEST must be terminated, and a NOTIFICATION message, and a "Routing problem/Label Set" indication MUST be generated. Note that the intersection is based on the physical labels (actual wavelength/band values), which may have different logical values on different links. So it's the node's job to map these values so they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists 🧠
when processing a MAPPING message at an intermediate node, the label propagated upstream MUST fall within the Label Set 🎀
and note, on reception of a MAPPING message, a node that can't do label conversion has no other choice than to use the same physical label (wavelength/band) it received in the MAPPING message. In that case, using and propagating a Label Set will significantly reduce the chances that this allocation fails 💅
3. Bidirectional LSPs 🦋
bidirectional LSP setup is indicated by the presence of an Upstream Label in the REQUEST message. An Upstream Label has the same format as the generalized label, see Section 2.2. Upstream Label uses type = 0x0826 🧚
3.1. Procedures 🌈
setting up a bidirectional LSP follows the same steps as a unidirectional LSP, with a few extras 💖 To support bidirectional LSPs, an Upstream Label gets added to the REQUEST message. The Upstream Label MUST indicate a label that is valid for forwarding at the time the REQUEST message is sent 🫶
when a REQUEST message with an Upstream Label arrives, the receiver first checks that the upstream label is acceptable. If it isn't, the receiver MUST issue a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4 ✨
an intermediate node also has to allocate a label on the outgoing interface and set up its internal data paths before it fills in an outgoing Upstream Label and propagates the REQUEST message. If an intermediate node can't allocate a label or the internal resources, it MUST issue a NOTIFICATION message with a "Routing problem/Label allocation failure" indication 😭
terminator nodes process REQUEST messages as usual, except the upstream label can be used right away to carry data traffic for the LSP upstream towards the initiator 👑
and when a bidirectional LSP is removed, both the upstream and downstream labels get invalidated, so it's no longer valid to send data using those labels 💀
4. Notification on Label Error 💅
this section defines the Acceptable Label Set TLV so we can do Notification on Label Error per [RFC3471]. An Acceptable Label Set TLV uses a type value of 0x082a, and the rest of the TLV has the identical format as the Label Set TLV, see Section 2.5 🍓
Acceptable Label Set TLVs may be carried in NOTIFICATION messages. The procedures for defining an Acceptable Label Set follow the procedures for defining a Label Set, see Section 2.5.1 🧚 So an Acceptable Label Set is defined through one or more Acceptable Label Set TLVs. Specific labels/subchannels can be added to or excluded from it using Action zero (0) and one (1) TLVs, and ranges using Action two (2) and three (3) TLVs. When the Acceptable Label Set TLVs only list labels/subchannels to exclude, that means all the other labels are acceptable 🌸
including Acceptable Label Set TLVs is optional. If you do include them, the NOTIFICATION message SHOULD contain a "Routing problem/Unacceptable label value" indication. And the absence of Acceptable Label Set TLVs doesn't have any specific meaning 🙈
5. Explicit Label Control 🔥
the Label ER-Hop TLV is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x0829) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+see [RFC3471] for a description of the L, U and Label parameters 🦋
5.1. Procedures 🎀
the Label ER-Hop follows an ER-Hop that contains the IP address, or the interface identifier [MPLS-UNNUM], associated with the link it's going to be used on. You can have up to two label ER-Hops, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE" errors 😭
- If the first label ER-Hop is not preceded by an ER-Hop containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link.
- For a label ER-Hop to follow an ER-Hop that has the L-bit set.
- On unidirectional LSP setup, for there to be a label ER-Hop with the U-bit set.
- For there to be two label ER-Hops with the same U-bit values.
to support the label ER-Hop, a node has to check whether the ER-Hop following its associated address/interface is a label ER-Hop. If it is, one ER-Hop gets examined for unidirectional LSPs and two ER-Hops for bidirectional LSPs. If the U-bit of the ER-Hop being examined is clear (0), the value of the label is copied into a new Label Set TLV. This Label Set TLV MUST be included on the corresponding outgoing REQUEST message 🫶
if the U-bit of the ER-Hop being examined is set (1), the value of the label is the label to be used for upstream traffic associated with the bidirectional LSP. If this label isn't acceptable, a "Bad EXPLICIT_ROUTE" error SHOULD be generated. If the label is acceptable, it gets copied into a new Upstream Label TLV, and this Upstream Label TLV MUST be included on the corresponding outgoing REQUEST message 🌈
after processing, the label ER-Hops are removed from the ER ✨
and note, an implication of all this is that the label ER-Hop should never be the first ER-Hop in a newly received message. If the label ER-Hop is the first ER-Hop in a received ER, it SHOULD be treated as a "Bad strict node" error 💀
procedures by which an LSR at the head-end of an LSP gets the information needed to construct the Label ER-Hop are outside the scope of this document 🧚
6. Protection TLV ✨
okay so the Protection TLV is totally optional 🎀 it's just there to flag the specific protection vibes an LSP wants. here's what the packet looks like 👇
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0835) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters. 📚
6.1. Procedures 💅
bestie, this part is very important 😭 transit nodes that get a REQUEST with a Protection TLV MUST check that the outgoing interface or tunnel (FA) can actually give the protection that was asked for. if it can't, the node MUST generate a NOTIFICATION message with a "Routing problem/Unsupported Link Protection" indication. no vibes-only protection allowed 🙅♀️🔥
7. Administrative Status Information 🌸
the Admin Status TLV carries admin state info for a particular LSP 🧚 it gets used in two ways. first, it rides along in REQUEST and MAPPING messages to show what state the LSP is in. second, it shows up in a Notification message to ask for a state change 💜
7.1. Admin Status TLV 🎀
using the Admin Status TLV is optional, and its Type is 0x082b. here's the layout for REQUEST, MAPPING and Notification messages 👇
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082b) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters. 📚
7.2. REQUEST and MAPPING Message Procedures 🦋
so the Admin Status TLV is how every node along the path finds out what's up with the LSP 👀 each node reads the status according to its local policy, then passes it on in the outgoing messages. the ingress node decides whether to put the TLV in a REQUEST, and if it's missing, that's the same as getting one with everything set to zero 🫶
transit nodes that get a REQUEST with an Admin Status TLV update their local state, do whatever local action makes sense for that status, and then forward the same TLV in the outgoing REQUEST 💖
edge nodes do the same local update and action, but they also get a special job 🍓 when an Admin Status TLV arrives with the R bit set, the receiving edge node should reflect those values back in a matching MAPPING message. specifically, if an egress node gets a Request message with the R bit of the Admin_Status TLV set and the node the node SHOULD send a Mapping message with an Admin_Status TLV carrying the same values as the received Request, except the R bit 🪞✨
7.2.1. Deletion procedure 💀
in some situations, especially optical networks, it's super useful to set an LSP's admin status before tearing it down 🌈 so here's the deal.
when the ingress is deleting an LSP, the SHOULD-level procedure is:
- the ingress node kicks things off by putting an Admin Status TLV into a Notification Message, with the Reflect (R) and Delete (D) bits set 🎀
- transit nodes handle the Admin Status TLV by passing the Notification message along. the egress node May respond with a Notification message that also carries the Admin Status TLV 💜
- when the egress gets an Admin Status TLV with the Delete (D) bit set in the Notification message, it SHOULD respond with a LABEL WITHDRAW message, and normal CR-LDP processing takes place 🧚
and when the egress is the one deleting an LSP, the SHOULD-level procedure goes like this:
- the egress node says it wants deletion by putting an Admin Status TLV into a Notification message and setting the Delete (D) bit 🙈
- transit nodes handle the Admin Status TLV the same way as described above 🦋
- when the ingress gets an Admin Status TLV with the Delete (D) bit set in the Notification message, it sends a LABEL RELEASE message downstream to remove the LSP, and normal CR-LDP processing takes place 🔥
7.3. Notification Message Procedures 🌸
more Admin Status messaging can happen through Notification Messages 💅 the ingress can start propagating a Notification Message with an Admin Status TLV. each subsequent node passes the Notification with the Admin Status TLV from the ingress toward the egress, and then the egress returns the Notification messages back Upstream carrying the Admin Status TLV 🔁
intermediate and egress nodes can also trigger admin status changes with Notification messages 🫶 to do that, the node generates a Notification message with the matching upstream notify session information. the Admin Status TLV MUST be included in that session information, with the right bit or bits set. the Reflect (R) bit MUST NOT be set. 🚫
and if an ingress or egress node gets a Notification message with an Admin Status TLV that has the Delete (D) bit set, it SHOULD start the deletion procedure from the previous section 💜
7.3.1. Compatibility and Error Procedures ⭐
okay this part handles the awkward stuff 😭 like nodes that don't support the Admin Status TLV, and other error conditions. specifically, a node that sends a Notification message with an Admin Status TLV that has the Down (D) bit set MUST check that it gets a matching LABEL RELEASE message within a configurable amount of time. by default that time SHOULD be 30 seconds ⏰ if the node doesn't get that LABEL RELEASE message, it SHOULD send a Label Release message downstream and a LABEL WITHDRAW message upstream 🌧️
8. Control Channel Separation 🦋
this section has the protocol-specific formats and procedures needed to support a control channel that isn't in-band with the data channel 🧚♀️ it's giving separation of concerns, honestly 👑
8.1. Interface Identification 💖
the sender of the REQUEST message is always the one who picks the data interface 🎯 the sender says which one by including the data channel's interface identifier in the message, using a new Interface TLV type. for bidirectional LSPs, the sender picks the data interface in each direction. in every case except bundling, the upstream interface is implied by the downstream interface. but for bundling, the REQUEST sender has to explicitly identify the component interface used in each direction 🍓
8.1.1. Interface ID TLV 🎀
here's the IPv4 Interface ID format for REQUEST and MAPPING messages 👇
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the IPv6 Interface ID TLV format for REQUEST and MAPPING messages 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [RFC3471] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters.
See [RFC3212] for a description of signaling address. See [RFC3471] for a description of parameters and encoding of TLVs. 📚
8.1.2. Procedures 💅
an IF_ID TLV gets used on links where a control channel doesn't map one-to-one onto a data channel, see [RFC3471] 🔗
the LDP session uses the IF_ID TLV to figure out which data channel(s) belong to the LSP. for a unidirectional LSP, a downstream data channel MUST be indicated. for bidirectional LSPs, a common downstream and upstream data channel is normally indicated. there's one special case: a bidirectional LSP crossing a bundled link can name a downstream data channel that's different from the upstream one 🧩 data channels are always specified from the viewpoint of the REQUEST sender. and the IF_ID TLV SHOULD NOT be used when no TLVs are needed 🙅♀️
when a node gets one or more IF_ID TLVs in a REQUEST message, it saves their values and sends them back in the next MAPPING message to the node that started the TLVs 🔁
heads up 🚨 the node that originates an IF_ID TLV MUST make sure the selected outgoing interface, as named in the IF_ID TLV, matches the ERO. a node that gets an IF_ID TLV SHOULD check whether that info matches what's in the received ERO. if it doesn't, it MUST send a LABEL ABORT Message with the error code "Routing Error" and error value "Bad Explicit Routing TLV Error" back toward the sender. this check CANNOT be done when the initial ERO subobject isn't the incoming interface 😬
8.2. Errored Interface Identification 🌧️
sometimes it's really useful to point at a specific interface that's tied to an error 🎯 so to support that, the IF_ID Status TLV is defined.
8.2.1. IF_ID Status TLVs 💖
okay so here's the IPv4 IF_ID Status TLV layout 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x082f) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and now the IPv6 IF_ID Status TLV 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x0830) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+for the status code value fields, go read [RFC3036] 🧚 and for the parameters and TLV encoding stuff, [RFC3471] is where it's at ✨
8.2.2. Procedures 🌸
okay this part is the important bit 😭 nodes that want to say "hey, this error is about one specific interface" SHOULD use the matching IF_ID Status TLV in the LABEL WITHDRAW or LABEL RELEASE message. and the IF_ID Status TLV SHOULD be generated and processed like any other Status TLV, see [RFC3036] 💅
9. Fault Handling 🌈
in optical transport networks, failures in the out-of-fiber signaling communication or optical control plane should not have service impact on the existing optical connections 🔥 so basically the vibe is don't let the signaling drama break the connections that are already up 🫶
under those circumstances, a mechanism MUST exist to detect a signaling communication failure, and a recovery procedure SHALL guarantee connection integrity at both ends of the signaling channel 💀 no notes, that's the whole energy.
the LDP Fault tolerant document [LDP-FT] is the one that spells out how LDP and CR-LDP sessions get recovered after a failure 🦋 for recovering optical connections, go read his document. the Fault tolerant document already covers a lot of the common failure modes for a separated control and data plane 👑
10. Acknowledgments 🫶
this document is the work of numerous authors, and it's a composition of a bunch of previous documents in this area 🌸
valuable comments and input were received from a number of people, notably Adrian Farrel 💜
11. Security Considerations 🔥
this document introduces no new security considerations to [RFC3212]. no new drama here, but the existing [RFC3212] stuff still applies, bestie 💀🙈
12. IANA Considerations ✨
this document uses the LDP [RFC3036] name spaces. see http://www.iana.org/assignments/ldp-namespaces, which lists the assignments for the following TLVs:
- Generalized Label Request (TLV 0x0824)
- Generalized Label (TLV 0x0825)
- Upstream Label (TLV 0x0826)
- Label Set (TLV 0x0827)
- Waveband Label (TLV 0x0828)
- ER-Hop (TLV 0x0829)
- Acceptable Label Set (TLV 0x082a)
- Admin Status (TLV 0x082b)
- Interface ID (TLV 0x082c)
- IPV4 Interface ID (TLV 0x082d)
- IPV6 Interface ID (TLV 0x082e)
- IPv4 IF_ID Status (TLV 0x082f)
- IPv6 IF_ID Status (TLV 0x0830)
- Protection (TLV 0x0835)
13. Intellectual Property Considerations 🎀
this section is taken from Section 10.4 of [RFC2026] 🌈
the IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. neither does it represent that it has made any effort to identify any such rights. information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. copies of claims of rights made available for publication, and 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 implementors or users of this specification, can be obtained from the IETF Secretariat 🧚
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. please address the information 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.
[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., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.14.2. Informative References 🦋
[LDP-FT] Farrel, A., et al, "Fault Tolerance for LDP and CR-
LDP", Work in Progress.
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
[MPLS-UNNUM] Kompella, K., Rekhter, Y. and A. Kullberg,
"Signalling Unnumbered Links in CR-LDP", Work in
Progress.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, October 1996.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling - Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 3473, January 2003.15. Contributors 🌟
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
Yanhe Fan
Axiowave Networks, Inc.
200 Nickerson Road
Marlborough, MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Don Fedyk
Nortel Networks Corp.
600 Technology Park
Billerica MA 01821
Phone: +1 978 288 3041
Fax: +1 978 288 0620
EMail: dwfedyk@nortelnetworks.com
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
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. Editors' Addresses 🖊️
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
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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein 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 💖
📦 where this page comes from
- ietf: rfc3472 2003-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms