As per Relevance of the word downstream, we have this rfc below:
Network Working Group K.
Request for Comments: 3038 Y.
Category: Standards Track Toshiba Corp
N.
WaterSprings.
H.
Univ. of
P.
Ennovate
January 2001
VCID Notification over ATM link for
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR)
one of the major applications of label switching. Because the
layer labels (VPI and VCI) associated with a VC rewritten with
value at every ATM switch nodes, it is not possible to use them
identify a VC in label mapping messages. The concept of
Connection Identifier (VCID) is introduced to solve this problem
VCID has the same value at both ends of a VC. This
specifies the procedures for the communication of VCID values
neighboring ATM-LSRs that must occur in order to ensure
property
1.
Several label switching schemes have been proposed to integrate
2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one
the major applications of label switching
In the case of ATM VCs, the VPI and VCI labels are, in the
case, rewritten with new values at every switch node through
the VC passes and cannot be used to provide end to end
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
have some common characteristic that may be deduced by examination
the layer 3 header in the packets, are bound to layer 2 'labels'.
speak of stream being 'bound' to labels. These bindings are
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
VCs in LDP mapping messages. An identifier called a
Connection ID (VCID) is introduced. VCID has the same value at
ends of a VC. This document specifies the procedures for
communication of VCID values between neighboring ATM-LSRs that
occur in order to ensure this property
2. Overview of VCID Notification
2.1 VCID Notification
The ATM has several types of VCs (transparent point-to-
link/VP/PVC/SVC). A transparent point-to-point link is defined
one that has the same VPI/VCI label at both ends of a VC.
example, two nodes are directly connected (i.e., without
ATM switches) or are connected through a VP with the same VPI
at both ends of the VP
There are two broad categories of VCID notification procedures
inband and outband. The categorization refers to the connection
which the messages of the VCID notification procedure are forwarded
In the case of the inband procedures, those messages are
over the VC to which they refer. In contrast the out of
procedures transmit the messages over some other connection (than
VC to which they refer).
We list below the various types of link and briefly mention the
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
VCID notification procedure is not necessary because the
(i.e., VPI/VCI) is the same at each end of the VC
VP : inband notification or VPID notification or no
- Inband
VCID notification is needed because the VPI at each end of the
may not be the same. Inband VCID notification is used in
case
Nagami, et al. Standards Track [Page 2]
RFC 3038 VCID Notification for LDP January 2001
- VPID
VCID notification is needed because the VPI at each end of the
may not be the same. VPID notification is used in this case
- No
If a node has only one VP to a neighboring node, VCID
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
Inband VCID notification is used in this case because the
at each end of the VC may not be the same
SVC : there are three
- Outband
If a signaling message has a field which is large enough to
a VCID value (e.g., GIT [GIT]), then the VCID is carried
in it
- Outband notification using a small-sized
If a signaling message has a field which is not large enough
carry a VCID value, this procedure is used
- Inband
If a signaling message can not carry user information,
procedure is used
When an LSP is a point-to-multipoint VC and an ATM switch in
LSR is not capable of VC merge, it may cause problems
performance and quality of service. When the LSR wants to add
new leaf to the LSP, it needs to split the active LSP
to send an inband notification message
2.2 VC
A VC has a directionality. The VCID procedure for a VC is
triggered from the upstream node of the VC, i.e., the upstream
notifies the downstream node of the VCID
If bidirectional use of a label switched VC is allowed, the
switched VC is said to be bidirectional. In this case, two
procedures are taken, one for each direction
If bidirectional use of a label switched VC is not allowed, the
switched VC is said to be unidirectional. In this case, only
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
3.1 Inband Notification
3.1.1 Inband Notification for Point-to-point
VCID notification is performed by transmitting a control
through the VC newly established (by signalling or management)
use as an label switched path (LSP). The procedure for
notification between two nodes A and B is detailed below
0. The node A establishes a VC to the destination node B (
signalling or management).
1. The node A selects a VCID value
2. The node A sends a VCID PROPOSE message which contains the
value and a message ID through the newly established VC to
node B
3. The node A establishes an association between the outgoing
(VPI/VCI) for the VC and the VCID value
4. The node B receives the message from the VC and establishes
association between the VCID in the message and the
label(VPI/VCI) for the VC. Until the node B receives the
Request message, the node B discards any packet received over
VC other than the VCID PROPOSE message
5. The node B sends an ACK message to the node A. This
contains the same VCID and message ID as specified in the
message. This message is sent through the VC for LDP
6. When node A receives the ACK message, it checks whether the
and the message ID in the message are the same as the
ones. If they are the same, node A regards that node B
established the association between the VC and VCID. Otherwise
the message is ignored. If the node A does not receive the
message with the expected message ID and VCID during a
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
REQUEST message to the node B. It contains the message ID
for VCID PROPOSE. When the node B receives the LDP
message, it regards that the node A has received the
correctly. The message exchange using VCID PROPOSE, VCID ACK,
LDP REQUEST messages constitutes a 3-way handshake. The 3-
handshake mechanism is required since the transmission of
Nagami, et al. Standards Track [Page 4]
RFC 3038 VCID Notification for LDP January 2001
PROPOSE message is unreliable. Once the 3-way
completes, the node B ignores all VCID PROPOSE messages
over the VC. The node B sends an LDP Mapping message,
contains the VCID value in the label TLV
Node A Node
| |
|--------------->| VCID
| |
|<---------------| VCID
| |
|--------------->| LDP Label
| |
|<---------------| LDP Label
3.1.2 Inband notification for point-to-multipoint
Current LDP specification does not support multicast. But the
notification procedure is defined for future use. VCID
is performed by sending a control message through the VC to be
as an LSP. The upstream node assigns the VCID value. The
by which it notifies the downstream node of that value is
below. The procedure is used when a new VC is created or a new
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
value is already assigned to a VC, it is used for VCID
2. The upstream node sends a message which contains the VCID
and a message ID through the VC used for an LSP. This message
transferred to all leaf nodes
3. The upstream node establishes an association between the
label for the VC and the VCID value
4. When the downstream nodes receiving the message already
the LDP REQUEST message for the VC, the received message
discarded. Otherwise, the downstream nodes establish
association between the VCID in the message and the VC from
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
node and the downstream nodes share the VCID. The upstream
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
| +------------------->|
| | |
|<---------------| |
| VCID ACK | |
|<-------------------------------| VCID
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
signaling
1. The VCID value which already assigned to the VC is used
2. The upstream node sends a message which contains the VCID
and a message ID through the VC used for an LSP. This message
transferred to all leaf nodes
3. When the downstream nodes receiving the message already
the LDP REQUEST message for the VC, the received message
discarded. Otherwise, the downstream nodes establish
association between the VCID in the message and the VC from
the message is received
4. After the upstream node receives the ACK messages, the
node and the downstream nodes share the VCID. The upstream
sends the LDP REQUEST message in order to make a 3-way handshake
3.2 Outband Notification using a small-sized
This method can be applied when a VC is established using an
signaling message and the message has a field which is not
enough to carry a VCID value
SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit
field for the user. This is a user specific field in the Layer 3
protocol field in the BLLI IE (Broadband Low Layer
Information Element).
The BLLI value is used as a temporary identifier for a VC during
VCID notification procedure. This mechanism is defined as "
Notification using a small-sized field". The BLLI value of a new
must not be assigned to other VCs during the procedure to
identifier conflict. When the association among the BLLI value,
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
can be reused for a new VC. VCID values can be
independently from BLLI values
Node A Node
| |
|--------------->| ATM Signaling with
|<---------------|
| |
|--------------->| VCID PROPOSE with
| |
|<---------------| VCID
| |
|--------------->| LDP Label
| |
|<---------------| LDP Label
A point-to-multipoint VC can also be established using ADD_PARTY
the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an
VC or an existing VC tree. In this procedure, the BLLI value
ADD_PARTY has to be the same value as that used to establish
first point-to-point VC of the tree. The same BLLI value can be
in different VC trees only when these VC trees can not add a leaf
the same time. As a result, the BLLI value used in the
must be determined by the root node of the multicast tree
[note
BLLI value is unique at the sender node. But BLLI value is
unique at the receiver node because multiple sender nodes
allocate the same BLLI value. So, the receiver node
recognize BLLI value and the sender address. ATM
messages (SETUP and ADD_PARTY) carry both the BLLI and the
ATM address. The receiver node can realize which node sends
BLLI message
3.2.1 Outband notification using a small-sized field
point-to-point
This subsection describes procedures for establishing a VC and
notification of its VCID between neighboring LSRs for
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
follows
1. An upstream LSR establishes a VC to the downstream LSR using
signaling and supplies a value in the BLLI field that it is
currently using for any other (incomplete) VCID
transaction with this peer
2. The upstream LSR sends the VCID PROPOSE message through the VC
LDP to notify the downstream LSR of the association between
BLLI and VCID values
3. The downstream LSR establishes the association between the VC
the BLLI value and the VCID and sends an ACK message to
upstream LSR
4. After the upstream LSR receives the ACK message, it
the association between the VC and the VCID. The VC is ready
be used. At this time the BLLI value employed in this
is free for reuse
5. After VCID notification, the upstream node sends the LDP
message to the downstream node. The downstream node sends the
mapping message, which contains the VCID value in the label TLV
LDP
3.2.2 Outband notification using a small-sized
for point-to-multipoint
This subsection describes procedures for establishing the first
for a multicast tree and for adding a new VC leaf to an existing
tree including the notification of its VCID for a multicast
using point-to-multipoint VCs
In this procedure, an upstream LSR determines both the VCID and
value in the multicast case. The reason that the BLLI value
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
between the downstream LSR with a unique BLLI value at this time
2. The upstream LSR notifies the downstream LSR of a paired
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
the BLLI value and the VCID and sends an ACK message to
upstream LSR. If the VCID is used by some other VC between
upstream and downstream LSRs, the old VC is discarded
4. After the upstream LSR receives the ACK message, the VC is
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
between its downstream LSR with the BLLI value that was
during the first signaling procedure. If another VC is using
BLLI value at the same time, the upstream waits for the
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
This method can be applied when a VC is established using a
signaling message and the message has a field (e.g., GIT [GIT])
is large enough to carry a VCID value. Message format is
in [GIT]. After the VCID notification, the node A sends the
request message is sent to the node B. Then, the node B sends
LDP mapping message to the node A
Node A Node
| |
|--------------->| ATM signaling with
|<---------------|
| |
|--------------->| LDP Label
| |
|<---------------| LDP Label
4 VPID Notification
The approach that is used for the VCID notification procedure is
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
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
the VP is constructed with the VPID(MSB) and VCI(LSB) of the VC.
VCID can be used by LDP without performing VCID
procedure. The message sequence is given below
1. An upstream node sends the VPID PROPOSE message. In the case
bidirectional label switched VC, both the upstream and
nodes use VCI=33. In the case of unidirectional label
VC, the node which has larger LDP Identifier uses VCI=33 and
other node uses VCI=34. Note that VCI=32, which is used
unlabeled packet transfer, is not used for VPID
procedure so that the same encapsulation method can be applied
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
5.1 VCID
An LDP VCID message consists of the LDP [LDP] fixed header
by one or more TLV. A VCID PROPOSE inband message and a VPID
message are sent as a null encapsulation packet through a VC to
used as an LSP. There is only the label stack header before the
VCID PDU. A label value in the label stack entry [ENCAPS] for
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
This message is sent as a null encapsulation packet with LDP
and label stack header through a VC to be used as an LSP. The
value is 4. The reserved label value is required because
downstream node may receive this message after receiving the
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.
downstream node must distinguish the VCID PROPOSE message from
messages and ignore the VCID PROPOSE message when the node
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
Four octet integer used to identify this message
Label
Label TLV contains VCID value. Type of label TLV is VCID(0x0203).
5.1.2 VCID Propose
An LSR uses the VCID PROPOSE message for the VCID
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
Four octet integer used to identify this message
Label
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
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
label TLV is VCID temporary ID(0x0702).
5.1.3 VCID ACK
An LSR send the VCID ACK message when the LSR accepts the
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
Four octet integer used to identify this message
Label
The label TLV contains the VCID value of the received VCID
message. Type of label TLV is VCID(0x0203).
VCID Message
This value is the same as that of received VCID PROPOSE message
5.1.4 VCID NACK
An LSR send the VCID NACK message when the LSR does not accept
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
Four octet integer used to identify this message
Label
The label TLV contains the VCID value of the received VCID
message. Type of label TLV is VCID(0x0203).
VCID Message
This value is the same as that of received VCID PROPOSE message
5.1.5 VPID Propose inband
This message is sent as a null encapsulation packet with LDP
and label stack header through a VC to be used as an LSP. The
value is 4. The downstream node must distinguish the VPID
message from other messages and ignore the VPID PROPOSE message
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
Four octet integer used to identify this message
Nagami, et al. Standards Track [Page 13]
RFC 3038 VCID Notification for LDP January 2001
VPID
VPID TLV contains VPID value. Type of label TLV is VPID(0x0703).
5.1.6 VPID ACK
An LSR send the VPID ACK message when the LSR accepts the
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
Four octet integer used to identify this message
VPID
The VPID TLV contains the VPID value of the received VPID
message
VCID Message
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
An LSR send the VPID NACK message when the LSR accepts the
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
Four octet integer used to identify this message
VPID
The VPID TLV contains the VPID value of the received VPID
message
VCID Message
This value is the same as that of received VCID PROPOSE message
5.2
5.2.1 VCID Label
An LSR uses VCID Label TLV to encode labels for use on the link
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
This is 4 byte VCID Message
5.2.3 VCID Temporary ID
An LSR uses the VCID temporary ID TLV for the VCID
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is 2 byte VPID value
Nagami, et al. Standards Track [Page 16]
RFC 3038 VCID Notification for LDP January 2001
Security
This document does not introduce new security issues other than
present in the LDP and may use the same mechanisms proposed for
technology
The authors would like to acknowledge the valuable technical
of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki
George Swallow and members of the LAST-WG of the WIDE Project
[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
Protocol Identifier in the Q.2941 Generic Identifier
Q.2957 User-to-user Signaling for the Internet Protocol",
RFC 3033, January 2001.
[ENCAPS] Rosen, E., Viswanathan, A. and R. Callon, "MPLS Label
Encoding", RFC 3032, January 2001.
Nagami, et al. Standards Track [Page 17]
RFC 3038 VCID Notification for LDP January 2001
Authors'
Ken-ichi
Computer & Network Development Center, Toshiba Corporation
1, Toshiba-cho, Fuchu-shi
Tokyo, 183-8511,
Phone: +81-42-333-2884
EMail: ken.nagami@toshiba.co.
Noritoshi
WaterSprings.
1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004,
EMail: demizu@dd.iij4u.or.
Hiroshi
Computer Center, University of Tokyo
2-11-16 Yayoi, Bunkyo-ku
Tokyo, 113-8658,
Phone: +81-3-3812-1111
EMail: hiroshi@wide.ad.
Yasuhiro
Computer & Network Development Center, Toshiba Corporation
1, Toshiba-cho, Fuchu-shi
Tokyo, 183-8511,
Phone: +81-42-333-2844
EMail: yasuhiro.katsube@toshiba.co.
Paul
Ennovate
60 Codman Hill
Boxborough,
Phone: 978-263-2002 x103
EMail: pdoolan@ennovatenetworks.
Nagami, et al. Standards Track [Page 18]
RFC 3038 VCID Notification for LDP January 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Nagami, et al. Standards Track [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
