doc: Add RFC documents

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]
+