From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3038.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc3038.txt (limited to 'doc/rfc/rfc3038.txt') diff --git a/doc/rfc/rfc3038.txt b/doc/rfc/rfc3038.txt new file mode 100644 index 0000000..11b7bbd --- /dev/null +++ b/doc/rfc/rfc3038.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group K. Nagami +Request for Comments: 3038 Y. Katsube +Category: Standards Track Toshiba Corp. + N. Demizu + WaterSprings.ORG + H. Esaki + Univ. of Tokyo + P. Doolan + Ennovate Networks + January 2001 + + VCID Notification over ATM link for LDP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is + one of the major applications of label switching. Because the ATM + layer labels (VPI and VCI) associated with a VC rewritten with new + value at every ATM switch nodes, it is not possible to use them to + identify a VC in label mapping messages. The concept of Virtual + Connection Identifier (VCID) is introduced to solve this problem. + VCID has the same value at both ends of a VC. This document + specifies the procedures for the communication of VCID values between + neighboring ATM-LSRs that must occur in order to ensure this + property. + +1. Introduction + + Several label switching schemes have been proposed to integrate Layer + 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of + the major applications of label switching. + + In the case of ATM VCs, the VPI and VCI labels are, in the general + case, rewritten with new values at every switch node through which + the VC passes and cannot be used to provide end to end identification + of a VC. + + + +Nagami, et al. Standards Track [Page 1] + +RFC 3038 VCID Notification for LDP January 2001 + + + In the context of MPLS 'stream', which are classes of packets that + have some common characteristic that may be deduced by examination of + the layer 3 header in the packets, are bound to layer 2 'labels'. We + speak of stream being 'bound' to labels. These bindings are conveyed + between peer LSRs by means of a Label Distribution Protocol [LDP]. + + In order to apply MPLS to ATM links, we need some way to identify ATM + VCs in LDP mapping messages. An identifier called a Virtual + Connection ID (VCID) is introduced. VCID has the same value at both + ends of a VC. This document specifies the procedures for the + communication of VCID values between neighboring ATM-LSRs that must + occur in order to ensure this property. + +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/SVC). A transparent point-to-point link is defined as + one that has the same VPI/VCI label at both ends of a VC. For + example, two nodes are directly connected (i.e., without intervening + ATM switches) or are connected through a VP with the same VPI value + at both ends of the VP. + + There are two broad categories of VCID notification procedures; + inband and outband. The categorization refers to the connection over + which the messages of the VCID notification procedure are forwarded. + In the case of the inband procedures, those messages are forwarded + over the VC to which they refer. In contrast the out of band + procedures transmit the messages over some other connection (than the + VC to which they refer). + + We list below the various types of link and briefly mention the VCID + notification procedures employed and the rational for that choice. + The procedures themselves are discussed in detail in later sections. + + Transparent point-to-point link : no VCID notification + VCID notification procedure 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. Inband VCID notification is used in this + case. + + + + + + +Nagami, et al. Standards Track [Page 2] + +RFC 3038 VCID Notification for LDP January 2001 + + + - VPID notification + VCID notification is needed because the VPI at each end of the VC + may not be the same. VPID notification is used in this case. + + - No notification + If a node has only one VP to a neighboring node, VCID notification + procedure is not mandatory. The VCI can be used as the VCID. + This is because the VCI value is the same at each end of the VP. + + PVC : inband notification + Inband VCID notification is used in this case 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 which is large enough to carry + a VCID value (e.g., GIT [GIT]), then the VCID is carried directly + in it. + + - Outband notification using a small-sized field + If a signaling message has a field which is not large enough to + carry a VCID value, this procedure is used. + + - Inband notification + If a signaling message can not carry user information, this + procedure is used. + + When an LSP is a point-to-multipoint VC and an ATM switch in an + LSR is not 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. + +2.2 VC direction + + A VC has a directionality. The VCID procedure for a VC is always + triggered from the upstream node of the VC, i.e., the upstream node + notifies the downstream node of the VCID. + + If bidirectional use of a label switched VC is allowed, the label + switched VC is said to be bidirectional. In this case, two VCID + procedures are taken, one for each direction. + + If bidirectional use of a label switched VC is not allowed, the label + switched VC is said to be unidirectional. In this case, only one + VCID procedure is taken for the allowed direction. + + VC directionality is communicated through LDP. + + + +Nagami, et al. Standards Track [Page 3] + +RFC 3038 VCID Notification for LDP January 2001 + + +3. VCID Notification Procedures + +3.1 Inband Notification Procedures + +3.1.1 Inband Notification for Point-to-point VC + + VCID notification is performed by transmitting a control message + through the VC newly established (by signalling or management) for + use as an label switched path (LSP). The procedure for VCID + notification between two nodes A and B is detailed below. + + 0. The node A establishes a VC to the destination node B (by + signalling or management). + + 1. The node A selects a VCID value. + + 2. The node A sends a VCID PROPOSE message which contains the VCID + value and a message ID through the newly established VC to the + node B. + + 3. The node A establishes an association between the outgoing label + (VPI/VCI) for the VC and the VCID value. + + 4. The 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 the node B receives the LDP + Request message, the node B discards any packet received over the + VC other than the VCID PROPOSE message. + + 5. The node B sends an ACK message to the node A. This message + contains the same VCID and message ID as specified in the received + message. This message is sent through the VC for LDP. + + 6. 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 are the same, node A regards that node B has + established the association between the VC and VCID. Otherwise, + the message is ignored. If the node A does not receive the ACK + message with the expected message ID and VCID during a given + period, the node A resends the VCID PROPOSE message to the node B. + + 7. After receiving the proposer ACK message, the node A sends an LDP + REQUEST message to the node B. It contains the message ID used + for VCID PROPOSE. When the node B receives the LDP REQUEST + message, it regards that the node A has received the ACK + correctly. The message exchange using VCID PROPOSE, VCID ACK, and + LDP REQUEST messages constitutes a 3-way handshake. The 3-way + handshake mechanism is required since the transmission of VCID + + + +Nagami, et al. Standards Track [Page 4] + +RFC 3038 VCID Notification for LDP January 2001 + + + PROPOSE message is unreliable. Once the 3-way handshake + completes, the node B ignores all VCID PROPOSE messages received + over the VC. The node B sends an LDP Mapping message, which + contains the VCID value in the label TLV. + + Node A Node B + | | + |--------------->| VCID PROPOSE + | | + |<---------------| VCID ACK + | | + |--------------->| LDP Label Request + | | + |<---------------| LDP Label Mapping + +3.1.2 Inband notification for point-to-multipoint VC + + Current LDP specification does not support multicast. But the VCID + notification procedure is defined for future use. VCID notification + is performed by sending a control message through the VC to be used + as an LSP. The upstream node assigns the VCID value. The procedure + by which it notifies the downstream node of that value is given + below. The procedure is used when a new VC is created or a new leaf + is added to the VC. + + First, the procedure for establishing the first VC is described. + + 1. The upstream node assigns a VCID value for the VC. When the VCID + value is already assigned to a VC, it is used for VCID. + + 2. The upstream node sends a message which contains the VCID value + and a message ID through the VC used for an LSP. This message is + transferred to all leaf nodes. + + 3. The upstream node establishes an association between the outgoing + label for the VC and the VCID value. + + 4. When the downstream nodes receiving the message already received + the LDP REQUEST message for the VC, the received message is + discarded. Otherwise, the downstream nodes establish an + association between the VCID in the message and the VC from which + the message is received. + + 5. The downstream nodes send an ACK message to the upstream node. + + 6. After the upstream node receives the ACK messages, the upstream + node and the downstream nodes share the VCID. The upstream node + sends the LDP REQUEST message in order to make a 3-way handshake. + + + +Nagami, et al. Standards Track [Page 5] + +RFC 3038 VCID Notification for LDP January 2001 + + + Upstream Downstream 1 Downstream 2 + | | | + |-----------+--->| | VCID PROPOSE + | +------------------->| + | | | + |<---------------| | + | VCID ACK | | + |<-------------------------------| VCID ACK + + Second, the procedure for adding a leaf to the existing point-to- + multipoint VC is described. + + 0. The upstream node adds the downstream node, using the ATM + signaling. + + 1. The VCID value which already assigned to the VC is used. + + 2. The upstream node sends a message which contains the VCID value + and a message ID through the VC used for an LSP. This message is + transferred to all leaf nodes. + + 3. When the downstream nodes receiving the message already received + the LDP REQUEST message for the VC, the received message is + discarded. Otherwise, the downstream nodes establish an + association between the VCID in the message and the VC from which + the message is received. + + 4. After the upstream node receives the ACK messages, the upstream + node and the downstream nodes share the VCID. The upstream node + sends the LDP REQUEST message in order to make a 3-way handshake. + +3.2 Outband Notification using a small-sized field + + This method can be applied when a VC is established using an ATM + signaling message and the message has a field which is not large + enough to carry a VCID value. + + SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory + field for the user. This is a user specific field in the Layer 3 + protocol field in the BLLI IE (Broadband Low Layer Information + Information Element). + + The BLLI value is used as a temporary identifier for a VC during a + VCID notification procedure. This mechanism is defined as "Outband + Notification using a small-sized field". The BLLI value of a new VC + must not be assigned to other VCs during the procedure to avoid + identifier conflict. When the association among the BLLI value, a + + + + +Nagami, et al. Standards Track [Page 6] + +RFC 3038 VCID Notification for LDP January 2001 + + + VCID value, and the corresponding VC is established, 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 Mapping + + A point-to-multipoint VC can also be established 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 as that used to establish the + first point-to-point VC of the tree. The same BLLI value can be used + in different VC trees only when these VC trees can not add a leaf at + the same time. As a result, the BLLI value used in the signaling + must be determined by the root node of the multicast tree. + + [note] + BLLI value is unique at the sender node. But BLLI value is not + unique at the receiver node because multiple sender nodes may + allocate the same BLLI value. So, the receiver node must + recognize BLLI value and the sender address. ATM Signaling + messages (SETUP and ADD_PARTY) carry both the BLLI and the sender + ATM address. The receiver node can realize which node sends the + BLLI message. + +3.2.1 Outband notification using a small-sized field for + point-to-point VC + + This subsection describes procedures for establishing a VC and for + notification of its VCID between neighboring LSRs for unicast + traffic. + + + + + + + + + + +Nagami, et al. Standards Track [Page 7] + +RFC 3038 VCID Notification for LDP January 2001 + + + The procedure employed when the upstream LSR assigns a VCID is as + follows. + + 1. An upstream LSR establishes a VC to the downstream LSR using ATM + signaling and supplies a value in the BLLI field that it is not + currently using for any other (incomplete) VCID notification + transaction with this peer. + + 2. The upstream LSR sends the VCID PROPOSE message through the VC for + LDP to notify the downstream LSR of the association between the + BLLI and VCID values. + + 3. The downstream LSR establishes the association between the VC with + the BLLI value and the VCID and sends an ACK message to the + upstream LSR. + + 4. After the upstream LSR receives the ACK message, it establishes + the association between the VC and the VCID. The VC is ready to + be used. At this time the BLLI value employed in this transaction + is free for reuse. + + 5. After VCID notification, the upstream node sends the LDP REQUEST + message to the downstream node. The downstream node sends 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 procedures for establishing the first VC + for a multicast tree and for adding a new VC leaf to an existing VC + tree including the notification of its VCID for a multicast stream + using point-to-multipoint VCs. + + In this procedure, an upstream LSR determines both the VCID and BLLI + value in the multicast case. The reason that the BLLI value is + determined by an upstream LSR is described above. + + First, the procedure for establishing the first VC is described. + + 1. An upstream LSR establishes a VC by the ATM Forum Signaling + between the downstream LSR with a unique BLLI value at this time. + + 2. The upstream LSR notifies the downstream LSR of a paired BLLI + value and VCID using a message dedicated for this purpose. + + + + + + +Nagami, et al. Standards Track [Page 8] + +RFC 3038 VCID Notification for LDP January 2001 + + + 3. The downstream LSR establishes the association between the VC with + the BLLI value and the VCID and sends an ACK message to the + upstream LSR. If the VCID is used by some other VC between the + upstream and downstream LSRs, the old VC is discarded. + + 4. After 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 is described. + + 1. The upstream LSR establishes a VC by the ATM Forum Signaling + between its downstream LSR with 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 completion + of the signaling procedure that is using this BLLI value. + + 2. Go to step 2 of the procedure for the first VC. + +3.3 Outband notification + + This method can be applied when a VC is established using a ATM + signaling message and the message has a field (e.g., GIT [GIT]) which + is large enough to carry a VCID value. Message format is described + in [GIT]. After the VCID notification, the node A sends the LDP + request message is sent 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 Mapping + +4 VPID Notification Procedure + + The approach that is used for the VCID notification procedure is also + applicable to share the same identifier between both ends for a VP. + VPID notification procedure is defined for this purpose. + + A distinct VPID notification procedure is performed for each + direction of each VP. + + + + + + +Nagami, et al. Standards Track [Page 9] + +RFC 3038 VCID Notification for LDP January 2001 + + + After the VPID notification is finished for a VP, a VCID of a VC in + the VP is constructed with the VPID(MSB) and VCI(LSB) of the VC. The + VCID can be used by LDP without performing VCID notification + procedure. The message sequence is given below. + + 1. An upstream node sends the VPID PROPOSE message. In the case of + bidirectional label switched VC, both the upstream and downstream + nodes use VCI=33. In the case of unidirectional label switched + VC, the node which has 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 VPID notification + procedure so that the same encapsulation method can be applied for + both VPID procedure and inband VCID procedure. + + 2. The downstream node sends the VPID ACK message. + + 3. The upstream node sends the LDP Label Request message. + + 4. 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 to be + used as an LSP. There is only the label stack header before the LDP + VCID PDU. A label value in the label stack entry [ENCAPS] for the + VCID PROPOSE inband message and the VPID PROPOSE message are 4. + Other messages are sent as TCP packets. This is the same as LDP. + + The VCID message type field is as follows: + + 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 = 0x0507 + +5.1.1 VCID Propose inband Message + + This message is sent as a null encapsulation packet with LDP header + and label stack header through a VC to be used as an LSP. The label + value is 4. The reserved label value is required because the + downstream node may receive this message after receiving the LDP + + + +Nagami, et al. Standards Track [Page 10] + +RFC 3038 VCID Notification for LDP January 2001 + + + Label Request message in the case of point-to-multipoint VC. The + downstream node must distinguish the VCID PROPOSE message from other + messages and ignore the VCID PROPOSE message when the node already + received the LDP Label Request message for the VC. + + 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 + Four octet integer used to identify this message. + + Label TLV + Label TLV contains VCID value. Type of 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 is sent through the VC for the LDP. + + 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 + Four octet integer used to identify this message. + + Label TLV + Label TLV contains VCID value. Type of label TLV is VCID(0x0203). + + + +Nagami, et al. Standards Track [Page 11] + +RFC 3038 VCID Notification for LDP January 2001 + + + Temporary ID TLV + 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 Type of + label TLV is VCID temporary ID(0x0702). + +5.1.3 VCID ACK Message + + An LSR send the VCID ACK message when the LSR accepts the VCID + PROPOSE message. + + 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 + Four octet integer used to identify this message. + + Label TLV + The label TLV contains the VCID value of the received VCID PROPOSE + message. Type of label TLV is VCID(0x0203). + + VCID Message ID + This value is the same as that of received VCID PROPOSE message. + +5.1.4 VCID NACK Message + + An LSR send the VCID NACK message when the LSR does not accept the + VCID PROPOSE message. + + + + + + + + + + + + + +Nagami, et al. Standards Track [Page 12] + +RFC 3038 VCID Notification for LDP January 2001 + + + 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 + Four octet integer used to identify this message. + + Label TLV + The label TLV contains the VCID value of the received VCID PROPOSE + message. Type of label TLV is VCID(0x0203). + + VCID Message ID + This value is the same as that of received VCID PROPOSE message. + +5.1.5 VPID Propose inband Message + + This message is sent as a null encapsulation packet with LDP header + and label stack header through a VC to be used as an LSP. The label + value is 4. The downstream node must distinguish the VPID PROPOSE + message from other messages and ignore the VPID PROPOSE message when + the node already received the LDP Label Request message for the VC. + + 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 + Four octet integer used to identify this message. + + + + + +Nagami, et al. Standards Track [Page 13] + +RFC 3038 VCID Notification for LDP January 2001 + + + VPID TLV + VPID TLV contains VPID value. Type of label TLV is VPID(0x0703). + +5.1.6 VPID ACK Message + + An LSR send the VPID ACK message when the LSR accepts the VPID + PROPOSE message. + + 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 + Four octet integer used to identify this message. + + VPID TLV + The VPID TLV contains the VPID value of the received VPID PROPOSE + message. + + VCID Message ID + This value is the same as that of received VCID PROPOSE message. + + + + + + + + + + + + + + + + + + + + +Nagami, et al. Standards Track [Page 14] + +RFC 3038 VCID Notification for LDP January 2001 + + +5.1.7 VPID NACK Message + + An LSR send the VPID NACK message when the LSR accepts the VPID + PROPOSE message. + + 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 + Four octet integer used to identify this message. + + VPID TLV + The VPID TLV contains the VPID value of the received VPID PROPOSE + message. + + VCID Message ID + This value is the same as that of received VCID PROPOSE message. + +5.2 Objects + +5.2.1 VCID Label TLV + + An LSR uses VCID Label TLV to encode labels for use on the link which + does not have the same data link label at both ends of a VC. + + 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 4 byte VCID value. + + + + + +Nagami, et al. Standards Track [Page 15] + +RFC 3038 VCID Notification for LDP January 2001 + + +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 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 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 2 byte VPID value. + + + + + + + +Nagami, et al. Standards Track [Page 16] + +RFC 3038 VCID Notification for LDP January 2001 + + +Security Considerations + + This document does not introduce new security issues other than those + present in the LDP and may use the same mechanisms proposed for this + technology. + +Acknowledgments + + The authors would like to acknowledge the valuable technical comments + of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, + George Swallow and members of the LAST-WG of the WIDE Project. + +References + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nagami, et al. Standards Track [Page 17] + +RFC 3038 VCID Notification for LDP January 2001 + + +Authors' Addresses + + 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.com + + + + + + + + +Nagami, et al. Standards Track [Page 18] + +RFC 3038 VCID Notification for LDP January 2001 + + +Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + +Nagami, et al. Standards Track [Page 19] + -- cgit v1.2.3