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.
AbstractThe 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.
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.
- 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.
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
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.
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.
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. 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. 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
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. 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
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).
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).
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.
VPID TLV VPID TLV contains VPID value. Type of label TLV is VPID(0x0703).
[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.
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.