summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3038.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3038.txt')
-rw-r--r--doc/rfc/rfc3038.txt1067
1 files changed, 1067 insertions, 0 deletions
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]
+