RFC 3038
VCID Notification over ATM link for LDP
RFC 3038: VCID Notification over ATM link for LDP 💖
okay so this one is from January 2001 and it's a Standards Track doc from the Network Working Group 🎀 It was written by K. Nagami, Y. Katsube (Toshiba Corp.), N. Demizu (WaterSprings.ORG), H. Esaki (Univ. of Tokyo), and P. Doolan (Ennovate Networks). The header doesn't list anything it obsoletes or updates, so it's just vibing on its own 🦋
Status of this Memo
this doc 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) ✨ distribution of this memo is unlimited, so share away bestie 💅
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🌸
Abstract
okay so the Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching 🧚 the thing is, the ATM layer labels (VPI and VCI) on a VC get rewritten with new values at every ATM switch node, so you literally can't use them to identify a VC in label mapping messages 😭 enter the Virtual Connection Identifier (VCID), which is the fix. the VCID has the same value at both ends of a VC, and this doc spells out how neighboring ATM-LSRs communicate VCID values so that property actually holds 💜
1. Introduction ✨
several label switching schemes have been proposed to integrate Layer 2 and Layer 3, and the ATM Label Switching Router (ATM-LSR) is one of the major applications 🔥
with ATM VCs, the VPI and VCI labels are, in the general case, rewritten with new values at every switch node the VC passes through, so they can't provide end to end identification of a VC 💀
now in the MPLS world, a 'stream' is a class of packets that share some common characteristic you can work out by looking at the layer 3 header. streams get 'bound' to layer 2 'labels' 🍓 those bindings get passed between peer LSRs by a Label Distribution Protocol [LDP] ⭐
so to apply MPLS to ATM links, we need a way to identify ATM VCs inside LDP mapping messages. enter the Virtual Connection ID (VCID) 👑 again, VCID has the same value at both ends of a VC, and this doc specifies how neighboring ATM-LSRs communicate VCID values to make that happen 🎀
2. Overview of VCID Notification Procedures 🌈
2.1 VCID Notification procedures
the ATM has several types of VCs: transparent point-to-point link, VP, PVC, and SVC 💖
a transparent point-to-point link is one with the same VPI/VCI label at both ends of a VC. for example, two nodes directly connected (no ATM switches in between) or connected through a VP that has the same VPI value at both ends 🦋
there are two broad categories of VCID notification procedures: inband and outband. the split is about which connection the notification messages travel over. with inband, the messages go over the VC they're talking about. outband sends them over some other connection instead ✨
here's the rundown of each link type and the notification procedure it uses, plus the reasoning behind it. the actual procedures get the full treatment in later sections 💅
Transparent point-to-point link : no VCID notification VCID notification is not necessary, because the label (i.e., VPI/VCI) is the same at each end of the VC. 🙈
VP : inband notification or VPID notification or no notification
- Inband notification VCID notification is needed because the VPI at each end of the VC may not be the same. So inband VCID notification gets used here. 🫶
- VPID notification VCID notification is needed because the VPI at each end of the VC may not be the same. So VPID notification gets used here. 🍓
- No notification if a node has only one VP to a neighboring node, VCID notification is not mandatory. the VCI can be used as the VCID, because the VCI value is the same at each end of the VP 🌸
PVC : inband notification inband VCID notification gets used here, because the labels at each end of the VC may not be the same 🧚
SVC : there are three possibilities
- Outband notification if a signaling message has a field that's big enough to carry a VCID value (e.g., GIT [GIT]), then the VCID gets carried directly in it ⭐
- Outband notification using a small-sized field if a signaling message has a field that's not big enough to carry a VCID value, this procedure is used 👑
- Inband notification if a signaling message can't carry user information, this procedure is used.
when an LSP is a point-to-multipoint VC and an ATM switch in an LSR isn't capable of VC merge, it may cause problems in performance and quality of service 😭 when the LSR wants to add a new leaf to the LSP, it needs to split the active LSP temporarily to send an inband notification message. yikes, but it's the way it goes 🙈
2.2 VC direction
a VC has a directionality 🦋 the VCID procedure for a VC is always triggered from the upstream node, so the upstream node notifies the downstream node of the VCID ✨
if bidirectional use of a label switched VC is allowed, the VC is called bidirectional. in that case, there are two VCID procedures, one for each direction 💜
if bidirectional use isn't allowed, the VC is called unidirectional. then only one VCID procedure gets taken, for the allowed direction 🎀
VC directionality gets communicated through LDP 🫶
3. VCID Notification Procedures 💅
3.1 Inband Notification Procedures
3.1.1 Inband Notification for Point-to-point VC
VCID notification happens by sending a control message through the VC that was newly established (by signalling or management) to be used as a label switched path (LSP). here's how the procedure goes between two nodes, A and B 🔥
- node A establishes a VC to the destination node B (by signalling or management). 🌈
- node A selects a VCID value. 💖
- node A sends a VCID PROPOSE message, which contains the VCID value and a message ID, through the newly established VC to node B. 🦋
- node A establishes an association between the outgoing label (VPI/VCI) for the VC and the VCID value. ✨
- node B receives the message from the VC and establishes an association between the VCID in the message and the incoming label (VPI/VCI) for the VC. until node B receives the LDP Request message, node B discards any packet received over the VC other than the VCID PROPOSE message. 🙈
- node B sends an ACK message to node A. this message contains the same VCID and message ID as in the received message. it's sent through the VC for LDP. 🫶
- when node A receives the ACK message, it checks whether the VCID and the message ID in the message are the same as the registered ones. if they match, node A regards that node B has established the association between the VC and VCID. otherwise, the message is ignored. if node A doesn't receive the ACK message with the expected message ID and VCID during a given period, node A resends the VCID PROPOSE message to node B. 😭
- after receiving the proposer ACK message, node A sends an LDP REQUEST message to node B. it contains the message ID used for VCID PROPOSE. when node B receives the LDP REQUEST message, it regards that node A has received the ACK correctly. the VCID PROPOSE, VCID ACK, and LDP REQUEST messages together make a 3-way handshake. the 3-way handshake mechanism is required since the transmission of VCID PROPOSE message is unreliable 💀 once the 3-way handshake completes, node B ignores all VCID PROPOSE messages received over the VC. then node B sends an LDP Mapping message, which contains the VCID value in the label TLV. 👑
here's the message flow 🧚
Node A Node B
| |
|--------------->| VCID PROPOSE
| |
|<---------------| VCID ACK
| |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mappingpart 1 of 4, so more is coming bestie 🌸✨
3.1.2 Inband notification for point-to-multipoint VC ✨
okay so the current LDP spec doesn't support multicast yet 🥺 but the VCID notification procedure is already defined for future use 🔮 the way it works is the upstream node sends a control message through the VC that's gonna be used as an LSP. the upstream node is the one that assigns the VCID value, and then there's a procedure for telling the downstream node what that value is. this procedure runs when a new VC gets created or when a new leaf gets added to the VC 💅
first up, the procedure for setting up the first VC 🎀
- the upstream node assigns a VCID value for the VC. if the VCID value is already assigned to a VC, that one gets used as the VCID.
- the upstream node sends a message with the VCID value and a message ID through the VC used for an LSP. this message gets transferred to all leaf nodes.
- the upstream node sets up an association between the outgoing label for the VC and the VCID value.
- when the downstream nodes get the message, if they already received the LDP REQUEST message for the VC, they throw the received message away. otherwise, the downstream nodes set up an association between the VCID in the message and the VC the message came in on.
- the downstream nodes send an ACK message back to the upstream node.
- once the upstream node has received the ACK messages, the upstream node and the downstream nodes share the VCID. then the upstream node sends the LDP REQUEST message to make a 3-way handshake 🤝
Upstream Downstream 1 Downstream 2
| | |
|-----------+--->| | VCID PROPOSE
| +------------------->|
| | |
|<---------------| |
| VCID ACK | |
|<-------------------------------| VCID ACKnext, the procedure for adding a leaf to an existing point-to-multipoint VC 🌈
- the upstream node adds the downstream node, using the ATM signaling.
- the VCID value that's already assigned to the VC gets used.
- the upstream node sends a message with the VCID value and a message ID through the VC used for an LSP. this message gets transferred to all leaf nodes.
- when the downstream nodes get the message, if they already received the LDP REQUEST message for the VC, they discard it. otherwise, the downstream nodes set up an association between the VCID in the message and the VC the message came in on.
- once the upstream node has received the ACK messages, the upstream node and the downstream nodes share the VCID. then the upstream node sends the LDP REQUEST message to make a 3-way handshake 🫶
3.2 Outband Notification using a small-sized field ✨
this method is for when a VC gets set up using an ATM signaling message, and that message has a field that's too small to carry a VCID value 🥹
the SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory field for the user. it's a user specific field inside the Layer 3 protocol field in the BLLI IE (Broadband Low Layer Information Information Element) 🧚
the BLLI value acts as a temporary identifier for a VC while a VCID notification procedure is happening. this mechanism is called "Outband Notification using a small-sized field" 💖 the BLLI value of a new VC must not be assigned to other VCs during the procedure, so there are no identifier conflicts 🙅♀️ once the association among the BLLI value, a VCID value, and the matching VC is set up, the BLLI value can be reused for a new VC. VCID values can be assigned independently from BLLI values 🌸
Node A Node B
| |
|--------------->| ATM Signaling with BLLI
|<---------------|
| |
|--------------->| VCID PROPOSE with BLLI
| |
|<---------------| VCID ACK
| |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mappinga point-to-multipoint VC can also be set up using ADD_PARTY of the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC or an existing VC tree 🌳 in this procedure, the BLLI value of ADD_PARTY has to be the same value that was used to set up the first point-to-point VC of the tree. the same BLLI value can be used in different VC trees only when those VC trees can't add a leaf at the same time. so the BLLI value used in the signaling must be decided by the root node of the multicast tree 👑
[note] the BLLI value is unique at the sender node, but it's not unique at the receiver node, because multiple sender nodes may allocate the same BLLI value. so the receiver node must recognize the BLLI value and the sender address 🕵️♀️ ATM Signaling messages (SETUP and ADD_PARTY) carry both the BLLI and the sender ATM address. that way, the receiver node can figure out which node sent the BLLI message ✨
3.2.1 Outband notification using a small-sized field for point-to-point VC 🎀
this subsection describes the procedures for setting up a VC and notifying its VCID between neighboring LSRs for unicast traffic 💅
this is the procedure used when the upstream LSR assigns a VCID:
- an upstream LSR sets up a VC to the downstream LSR using ATM signaling, and it supplies a value in the BLLI field that it isn't currently using for any other (incomplete) VCID notification transaction with this peer.
- the upstream LSR sends the VCID PROPOSE message through the VC for LDP to tell the downstream LSR about the association between the BLLI and VCID values.
- the downstream LSR sets up the association between the VC with the BLLI value and the VCID, and then sends an ACK message to the upstream LSR.
- once the upstream LSR gets the ACK message, it sets up the association between the VC and the VCID. the VC is ready to be used 🎉 at this point, the BLLI value used in this transaction is free to be reused.
- after VCID notification, the upstream node sends the LDP REQUEST message to the downstream node. the downstream node sends back the LDP mapping message, which contains the VCID value in the label TLV of LDP.
3.2.2 Outband notification using a small-sized field for point-to-multipoint VC 🦋
this subsection describes the procedures for setting up the first VC for a multicast tree, and for adding a new VC leaf to an existing VC tree. it includes notifying the VCID for a multicast stream that uses point-to-multipoint VCs 🌈
in this procedure, an upstream LSR decides both the VCID and the BLLI value for the multicast case. the reason the BLLI value is decided by an upstream LSR is explained above 🧠
first, the procedure for setting up the first VC:
- an upstream LSR sets up a VC by the ATM Forum Signaling with the downstream LSR, using a unique BLLI value at this time.
- the upstream LSR notifies the downstream LSR of a paired BLLI value and VCID, using a message dedicated for this purpose.
- the downstream LSR sets up the association between the VC with the BLLI value and the VCID, and then sends an ACK message to the upstream LSR. if the VCID is already used by some other VC between the upstream and downstream LSRs, the old VC is discarded 🗑️
- once the upstream LSR receives the ACK message, the VC is ready to be used, and the BLLI value can be used for another VC ✨
second, the procedure for adding a leaf to the existing point-to-multipoint VC:
- the upstream LSR sets up a VC by the ATM Forum Signaling with its downstream LSR, using the BLLI value that was used during the first signaling procedure. if another VC is using the BLLI value at the same time, the upstream waits for the signaling procedure that's using this BLLI value to finish 🕐
- go to step 2 of the procedure for the first VC.
3.3 Outband notification 🌸
this method can be applied when a VC is set up using an ATM signaling message, and that message has a field (for example, GIT [GIT]) that's large enough to carry a VCID value 💜 the message format is described in [GIT]. after the VCID notification, the node A sends the LDP request message to the node B. then the node B sends the LDP mapping message to the node A 📨
Node A Node B
| |
|--------------->| ATM signaling with VCID
|<---------------|
| |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping4 VPID Notification Procedure ✨
the approach used for the VCID notification procedure also works for sharing the same identifier between both ends of a VP 🧚 the VPID notification procedure is defined for this purpose 🎀
a distinct VPID notification procedure is performed for each direction of each VP 🔁
once the VPID notification is finished for a VP, a VCID for a VC in the VP is built from the VPID (MSB) and the VCI (LSB) of the VC. the VCID can be used by LDP without doing the VCID notification procedure 🙌 the message sequence is below:
- an upstream node sends the VPID PROPOSE message. for a bidirectional label switched VC, both the upstream and downstream nodes use VCI=33. for a unidirectional label switched VC, the node with the larger LDP Identifier uses VCI=33, and the other node uses VCI=34. note that VCI=32, which is used for unlabeled packet transfer, is not used for the VPID notification procedure, so the same encapsulation method can be applied for both the VPID procedure and the inband VCID procedure 💅
- the downstream node sends the VPID ACK message.
- the upstream node sends the LDP Label Request message.
- the downstream node sends the LDP Label Mapping message.
5 VCID Message Format 🌈
5.1 VCID Messages 💖
an LDP VCID message consists of the LDP [LDP] fixed header, followed by one or more TLV. a VCID PROPOSE inband message and a VPID PROPOSE message are sent as a null encapsulation packet through a VC that will be used as an LSP 🫧 there's only the label stack header before the LDP VCID PDU. the label value in the label stack entry [ENCAPS] for the VCID PROPOSE inband message and the VPID PROPOSE message is 4. other messages are sent as TCP packets, the same as LDP 🌸
the VCID message type field looks like this:
VCID Propose inband Message = 0x0501
VCID Propose Message = 0x0502
VCID ACK Message = 0x0503
VCID NACK Message = 0x0504
VPID Propose inband Message = 0x0505
VPID ACK Message = 0x0506
VPID NACK Message = 0x05075.1.1 VCID Propose inband Message ✨
okay bestie, this one gets sent as a null encapsulation packet with an LDP header and a label stack header, going through a VC that's about to be used as an LSP 🦋 The label value is 4. This reserved label is super important because the downstream node might receive this message after it already got the LDP Label Request message, and that can happen with a point-to-multipoint VC 💀 So the downstream node has to be able to tell the VCID PROPOSE message apart from the other messages, and it should ignore the VCID PROPOSE message if it already got the LDP Label Request message for that VC. no cap, that's a whole plot twist 😭
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|VCID Inband Propose (0x0501) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message Id 🎀 A four octet integer that identifies this message.
Label TLV 🌸 The Label TLV carries the VCID value. The type of this label TLV is VCID(0x0203).
5.1.2 VCID Propose Message 🫶
an LSR uses the VCID PROPOSE message for the VCID notification procedure of the outband notification using a small-sized field 🧚 this message gets sent through the VC for the LDP, so it's basically the LDP lane 🌈
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| VCID Propose (0x0502) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Temporary ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message ID 🎀 A four octet integer that identifies this message.
Label TLV 🌸 The Label TLV carries the VCID value. The type of this label TLV is VCID(0x0203).
Temporary ID TLV 💜 This carries the value from the user specific field in the layer 3 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0. The type of this label TLV is VCID temporary ID(0x0702).
5.1.3 VCID ACK Message 💖
an LSR sends the VCID ACK message when it accepts the VCID PROPOSE message. yesss, the "you're in" text 🙌
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| VCID ACK (0x0503) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message ID 🎀 A four octet integer that identifies this message.
Label TLV 🌸 The label TLV carries the VCID value from the received VCID PROPOSE message. The type of label TLV is VCID(0x0203).
VCID Message ID 🦋 This value is the same as the one in the received VCID PROPOSE message.
5.1.4 VCID NACK Message 🥀
an LSR sends the VCID NACK message when it does not accept the VCID PROPOSE message. the "nope, not this time" message, but make it iconic 💅
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| VCID NACK (0x0504) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message ID 🎀 A four octet integer that identifies this message.
Label TLV 🌸 The label TLV carries the VCID value from the received VCID PROPOSE message. The type of label TLV is VCID(0x0203).
VCID Message ID 🦋 This value is the same as the one in the received VCID PROPOSE message.
5.1.5 VPID Propose inband Message 🍓
this one is sent as a null encapsulation packet with an LDP header and a label stack header, through a VC that's gonna be used as an LSP 🌈 The label value is 4. The downstream node has to tell the VPID PROPOSE message apart from other messages, and it should ignore the VPID PROPOSE message if it already got the LDP Label Request message for that VC. it's giving déjà vu from 5.1.1 but for VPIDs 🙈
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|VPID Inband Propose (0x0505) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message Id 🎀 A four octet integer that identifies this message.
VPID TLV 🌷 The VPID TLV carries the VPID value. The type of label TLV is VPID(0x0703).
5.1.6 VPID ACK Message 💜
an LSR sends the VPID ACK message when it accepts the VPID PROPOSE message. the VPID version of the "you're in" text 🫶
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| VPID ACK (0x0506) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message ID 🎀 A four octet integer that identifies this message.
VPID TLV 🌷 The VPID TLV carries the VPID value from the received VPID PROPOSE message.
VCID Message ID 🦋 This value is the same as the one in the received VCID PROPOSE message.
5.1.7 VPID NACK Message 🥀
an LSR sends the VPID NACK message when it accepts the VPID PROPOSE message. 👀 yes, the text really says "accepts" here, even though the vibe is "nope". it's the original wording, so it stays exactly like that 🙈
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| VPID NACK (0x0507) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message ID 🎀 A four octet integer that identifies this message.
VPID TLV 🌷 The VPID TLV carries the VPID value from the received VPID PROPOSE message.
VCID Message ID 🦋 This value is the same as the one in the received VCID PROPOSE message.
5.2 Objects 🧸
5.2.1 VCID Label TLV 🌈
an LSR uses the VCID Label TLV to encode labels for use on the link that does not have the same data link label at both ends of a VC. (plot: the ends don't match, so this TLV does the matchmaking 💘)
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|VCID Label (0x0203) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+VCID 💖 This is a 4 byte VCID value.
5.2.2 VCID Message ID 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|VCID Message ID(0x0701) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+VCID Message ID 🦋 This is a 4 byte VCID Message ID.
5.2.3 VCID Temporary ID TLV 🦄
an LSR uses the VCID temporary ID TLV for the VCID notification procedure of the outband notification using a small-sized field 🧚
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| VCID Temporary ID (0x0702)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Temporary ID |
+-+-+-+-+-+-+-+-+Temporary ID 🌸 The value carried in the user specific field in the layer 3 protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0.
5.2.4 VPID Label TLV 🍬
an LSR uses the VPID TLV for the VPID notification procedure 💫
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| VPID (0x0703) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+VPID 💜 This is a 2 byte VPID value.
Security Considerations 🔐
Okay bestie, the security part is short but it's serious 💀. This document does not add any new security issues on top of the ones already in the LDP. It also says it may use the same mechanisms proposed for this technology. So, no new drama, just the LDP drama we already have 🫶
Acknowledgments 🌸
The authors gave a huge shoutout to the people who helped with their technical comments: Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, George Swallow, and the members of the LAST-WG of the WIDE Project. Iconic squad 👑
References 📚
Here's the reading list, with all the details:
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[GIT] Suzuki, M., "The Assignment of the Information Field and
Protocol Identifier in the Q.2941 Generic Identifier and
Q.2957 User-to-user Signaling for the Internet Protocol",
RFC 3033, January 2001.
[ENCAPS] Rosen, E., Viswanathan, A. and R. Callon, "MPLS Label Stack
Encoding", RFC 3032, January 2001.Authors' Addresses 🧚
Here's how to reach the squad, with all the contact info:
Ken-ichi Nagami
Computer & Network Development Center, Toshiba Corporation,
1, Toshiba-cho, Fuchu-shi,
Tokyo, 183-8511, Japan
Phone: +81-42-333-2884
EMail: ken.nagami@toshiba.co.jp
Noritoshi Demizu
WaterSprings.ORG
1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004, Japan
EMail: demizu@dd.iij4u.or.jp
Hiroshi Esaki
Computer Center, University of Tokyo,
2-11-16 Yayoi, Bunkyo-ku,
Tokyo, 113-8658, Japan
Phone: +81-3-3812-1111
EMail: hiroshi@wide.ad.jp
Yasuhiro Katsube
Computer & Network Development Center, Toshiba Corporation,
1, Toshiba-cho, Fuchu-shi,
Tokyo, 183-8511, Japan
Phone: +81-42-333-2844
EMail: yasuhiro.katsube@toshiba.co.jp
Paul Doolan
Ennovate Networks
60 Codman Hill Road
Boxborough, MA
Phone: 978-263-2002 x103
EMail: pdoolan@ennovatenetworks.comFull Copyright Statement 💜
Legal stuff, but make it cute 🎀 The copyright belongs to The Internet Society (2001), and all rights are reserved. The notice itself is kept exactly as written:
Copyright (C) The Internet Society (2001). 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. Thank you for reading, bestie 🫶✨
📦 where this page comes from
- ietf: rfc3038 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms