draft-ietf-mpls-vcid-atm-01.txt   draft-ietf-mpls-vcid-atm-02.txt 
MPLS Working Group Ken-ichi Nagami (Toshiba Corp.) MPLS Working Group Ken-ichi Nagami (Toshiba Corp.)
INTERNET DRAFT Noritoshi Demizu (NAIST) INTERNET DRAFT Noritoshi Demizu (NAIST)
Hiroshi Esaki (Toshiba Corp.) Hiroshi Esaki (Univ. Tokyo)
Yasuhiro Katsube (Toshiba Corp.)
Paul Doolan (Ennovate Networks) Paul Doolan (Ennovate Networks)
August 1998 December 1998
Expires February 1999 Expires June 1999
VCID Notification over ATM link VCID Notification over ATM link
<draft-ietf-mpls-vcid-atm-01.txt> <draft-ietf-mpls-vcid-atm-02.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 33 skipping to change at page 1, line 36
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The ATM Label Switching Router (ATM-LSR) is one of the major The ATM Label Switching Router (ATM-LSR) is one of the major
applications of label switching. Because the ATM layer labels (VPI applications of label switching. Because the ATM layer labels (VPI
and VCI) associated with a VC may change on each VC of that VC, it is and VCI) associated with a VC rewritten with new value at every ATM
not possible to use them to identify a VC in label binding switch nodes, it is not possible to use them to identify a VC in
messages. The concept of Virtual Connection Identifier (VCID) is label mapping messages. The concept of Virtual Connection Identifier
introduced to solve this problem. VCID has the same value at both (VCID) is introduced to solve this problem. VCID has the same value
ends of a VC. This document specifies the procedures for the at both ends of a VC. This document specifies the procedures for the
communication of VCID values between neighboring ATM-LSRs that must communication of VCID values between neighboring ATM-LSRs that must
occur in order to ensure this property. occur in order to ensure this property.
1. Introduction 1. Introduction
Several label switching schemes have been proposed to integrate Layer 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 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the
major applications of label switching. major applications of label switching.
In the case of ATM VCs, the VPI and VCI labels are, in the general 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 case, rewritten with new values at every switch node through which
the VC passes and cannot be used to provide end to end the VC passes and cannot be used to provide end to end
identification of a VC. identification of a VC.
In the context of MPLS 'stream', which are classes of packets that In the context of MPLS 'stream', which are classes of packets that
have some common charachteristic that may be deduced by examination have some common characteristic that may be deduced by examination
of the layer 3 header in the packets, are bound to layer 2 'labels'. 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 We speak of stream being 'bound' to labels. These bindings are
conveyed between peer LSRs by means of a Label Distribution Protocol conveyed between peer LSRs by means of a Label Distribution Protocol
[LDP]. [LDP].
In order to apply MPLS to ATM links, we need some way to identify ATM In order to apply MPLS to ATM links, we need some way to identify ATM
VCs in LDP binding messages. In [VCID], an identifier called a VCs in LDP mapping messages. In [VCID], an identifier called a
Virtual Connection ID (VCID) is introduced. VCID has the same value Virtual Connection ID (VCID) is introduced. VCID has the same value
at both ends of a VC. This document specifies the procedures for at both ends of a VC. This document specifies the procedures for
the communication of VCID values between neighboring ATM-LSRs that the communication of VCID values between neighboring ATM-LSRs that
must occur in order to ensure this property. must occur in order to ensure this property.
2. Overview of VCID Notification Procedures 2. Overview of VCID Notification Procedures
2.1 VCID Notification procedures 2.1 VCID Notification procedures
The ATM has several types of VCs (transparent point-to-point 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 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, 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 two nodes are directly connected (i.e., without intervening ATM
switches) or are connected through a VP with the same VPI value at switches) or are connected through a VP with the same VPI value at
both ends of the VP. both ends of the VP.
There are two broad categories of VCID notification procedures; There are two broad categories of VCID notification procedures;
inband and out of band. The categorisation refers to the connection inband and outband. The categorization refers to the connection
over which the messages of the VCID notification procedure are over which the messages of the VCID notification procedure are
forwarded. In the case of the inband procedures, those messages 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 forwarded over the VC to which they refer. In contrast the out of
band procedures transmit the messages over some other connection band procedures transmit the messages over some other connection
(than the VC to which they refer). (than the VC to which they refer).
We list below the various types of link and briefly mention the VCID We list below the various types of link and briefly mention the VCID
notification procedures employed and the rational for that notification procedures employed and the rational for that
choice. The procedures themselves are discussed in detail in later choice. The procedures themselves are discussed in detail in later
sections. sections.
Transparent point-to-point link : no VCID notification Transparent point-to-point link : no VCID notification
VCID notification procedure is not necessary because the label VCID notification procedure is not necessary because the label
(i.e., VPI/VCI) is the same at each end of the VC. (i.e., VPI/VCI) is the same at each end of the VC.
VP : inband notification (as a default mechanism) VP : inband notification or no notification
- Inband notification - Inband notification
VCID notification is needed because the VPI at each end of the VC VCID notification is needed because the VPI at each end of the VC
may not be the same. Inband VCID notification [VCID] is used in may not be the same. Inband VCID notification [VCID] is used in
this case. this case.
- No notification - No notification
If a node has only one VP to a neighboring node, VCID 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 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. is because the VCI value is the same at each end of the VP.
PVC : inband notification PVC : inband notification
Inband VCID notification [VCID] is used in this case because the Inband VCID notification [VCID] is used in this case because the
labels at each end of the VC may not be the same. labels at each end of the VC may not be the same.
SVC : there are three possibilities SVC : there are three possibilities
- Out of band notification - Outband notification
If a signaling message has a field which is large enough to carry 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 a VCID value (e.g., GIT [GIT]), then the VCID is carried directly
in it. in it.
- Outband notification using a small-sized field - Outband notification using a small-sized field
If a signaling message has a field which is not large enough to If a signaling message has a field which is not large enough to
carry a VCID value, this procedure is used. carry a VCID value, this procedure is used.
- Inband notification - Inband notification
If a signaling message can not carry user information, this If a signaling message can not carry user information, this
procedure is used. procedure is used.
When an LSP is a point-to-multipoint VC and an ATM switch in an 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 LSR is not capable of VC merge, it may cause problems in
performance and quality of service. When the LSR wants to add a 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 new leaf to the LSP, it needs to split the active LSP temporarily
to send an inband notification message. to send an inband notification message.
2.2 VCID Assignment
A VCID value is assigned by either an upstream node or a downstream
node depending on the type of VC. For a point-to-point VC, either
the upstream node or the downstream node could assign a VCID
value. For a point-to-multipoint VC, only an upstream (root) node can
assign a VCID value.
3. VCID Notification Procedures 3. VCID Notification Procedures
3.1 Inband Notification Procedures 3.1 Inband Notification Procedures
3.1.1 Inband Notification for Point-to-point VC 3.1.1 Inband Notification for Point-to-point VC
VCID notification is performed by transmitting a control message VCID notification is performed by transmitting a control message
through the VC newly established (by signalling or management) for through the VC newly established (by signalling or management) for
use as an label switched path (LSP) [FRAME], The procedure for VCID use as an label switched path (LSP) [FRAME]. The procedure for VCID
notification between two nodes A and B is detailed below. notification between two nodes A and B is detailed below.
0. Node A establishes a VC to the destination LSR B. (by signalling 0. The node A establishes a VC to the destination node B. (by signalling
or management) or management)
1. Node A selects a VCID value. 1. The node A selects a VCID value.
2. Node A sends a message which contains the VCID value through the 2. The node A sends a VCID PROPOSE message which contains the VCID
newly established VC to Node B. value and a message ID through the newly established VC to the
node B.
3. Node A establishes an association between the outgoing label 3. The node A establishes an association between the outgoing label
(VPI/VCI) for the VC and the VCID value. (VPI/VCI) for the VC and the VCID value.
4. Node B receives the message from the VC and establishes an 4. The node B receives the message from the VC and establishes an
association between the VCID in the message and the incomming association between the VCID in the message and the incoming
label(VPI/VCI) for the VC. 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. Node B sends an ACK message to node A. 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. After Node A receives the ACK message, node A and node B both 6. When node A receives the ACK message, it checks whether the VCID
associate the VCID with the same VC. 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 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 Node A Node B
| | | |
|--------------->| |--------------->| VCID PROPOSE
| VCID |
| | | |
|<---------------| |<---------------| VCID ACK
| ACK | | |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping
3.1.2 Inband notification for point-to-multipoint VC 3.1.2 Inband notification for point-to-multipoint VC
VCID notification is performed by sending a control message through Current LDP specification does not support multicast. But the VCID
the VC to be used as an LSP. The upstream node must assign the VCID notification procedure is defined for future use. VCID notification
value. The procedure by which it notifies the downstream node of that is performed by sending a control message through the VC to be used
value is given below. The procedure is used when a new VC is created as an LSP. The upstream node assigns the VCID value. The procedure by
or a new leaf is added to the VC. 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. First, the procedure for establishing the first VC is described.
1. The upstream node assigns a VCID value for the VC. When the VCID 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. value is already assigned to a VC, it is used for VCID.
2. The upstream node sends a message which contains the VCID value 2. The upstream node sends a message which contains the VCID value
and the address of the upstream node through the VC used for a and a message ID through the VC used for an LSP. This message is
label switched path. This message is transferred to all leaf transferred to all leaf nodes.
nodes.
3. The upstream node establishes an association between the outgoing 3. The upstream node establishes an association between the outgoing
label for the VC and the VCID value. label for the VC and the VCID value.
4. The downstream nodes receiving the message check the address of 4. When the downstream nodes receiving the message already received
the upstream node. If the address is not the same network prefix the LDP REQUEST message for the VC, the received message is
as its address, the message is discarded. Otherwise, the discarded. Otherwise, the downstream nodes establish an
downstream nodes establish an association between the VCID in the association between the VCID in the message and the VC from which
message and the VC from which the message is received. the message is received.
5. The downstream nodes send an ACK message to the upstream node. 5. The downstream nodes send an ACK message to the upstream node.
6. After the upstream node receives the ACK messages, the upstream 6. After the upstream node receives the ACK messages, the upstream
node and the downstream nodes share the VCID. node and the downstream nodes share the VCID. The upstream node
sends the LDP REQUEST message in order to make a 3-way handshake.
Upstream Downstream 1 Downstream 2 Upstream Downstream 1 Downstream 2
| | | | | |
|-----------+--->| | |-----------+--->| | VCID PROPOSE
| VCID +------------------->| | +------------------->|
| | | | | |
|<---------------| | |<---------------| |
| ACK | | | VCID ACK | |
|<-------------------------------| |<-------------------------------| VCID ACK
| ACK |
Second, the procedure for adding a leaf to the existing Second, the procedure for adding a leaf to the existing
point-to-multipoint VC is described. point-to-multipoint VC is described.
0. The upstream node adds the downstream node, using the ATM 0. The upstream node adds the downstream node, using the ATM
signaling. signaling.
1. The VCID value which already assigned to the VC is used. 1. The VCID value which already assigned to the VC is used.
2. The upstream node sends a message which contains the VCID value 2. The upstream node sends a message which contains the VCID value
and the address of the upstream node through the VC used for a and a message ID through the VC used for an LSP. This message is
label switched path. This message is transferred to all leaf transferred to all leaf nodes.
nodes.
3. The downstream nodes receiving the message check the address of 3. When the downstream nodes receiving the message already received
the upstream node. If the address is not the same network prefix the LDP REQUEST message for the VC, the received message is
as its address, the message is discarded. Otherwise, the discarded. Otherwise, the downstream nodes establish an
downstream nodes establish an association between the VCID in the association between the VCID in the message and the VC from which
message and the VC from which the message is received. the message is received.
4. After the upstream node receives the ACK messages, the upstream 4. After the upstream node receives the ACK messages, the upstream
node and the downstream nodes share the VCID. 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 3.2 Outband Notification using a small-sized field
This method can be applied when a VC is established using an ATM 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 signaling message and the message has a field which is not large
enough to carry a VCID value. enough to carry a VCID value.
SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory 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 field for the user. This is a user specific field in the Layer 3
protocol field in the BLLI IE (Broadband Low Layer Information protocol field in the BLLI IE (Broadband Low Layer Information
skipping to change at line 262 skipping to change at page 6, line 22
VCID notification procedure. This mechanism is defined as "Outband VCID notification procedure. This mechanism is defined as "Outband
Notification using a small-sized field" described in [VCID]. The BLLI Notification using a small-sized field" described in [VCID]. The BLLI
value of a new VC must not be assigned to other VCs during the value of a new VC must not be assigned to other VCs during the
procedure to avoid identifier conflict. When the association among procedure to avoid identifier conflict. When the association among
the BLLI value, a VCID value, and the corresponding VC is the BLLI value, a VCID value, and the corresponding VC is
established, the BLLI value can be reused for a new VC. VCID values established, the BLLI value can be reused for a new VC. VCID values
can be assigned independently from BLLI values. can be assigned independently from BLLI values.
Node A Node B Node A Node B
| | | |
|<-------------->| |--------------->| ATM Signaling with BLLI
| ATM Signaling | |<---------------|
| with BLLI |
| | | |
|--------------->| |--------------->| VCID PROPOSE with BLLI
| BLLI & VCID |
| | | |
|<---------------| |<---------------| VCID ACK
| ACK | | |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping
A point-to-multipoint VC can also be established using ADD_PARTY of 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 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 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 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 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 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 the same time. As a result, the BLLI value used in the signaling must
be determined by the root node of the multicast tree. be determined by the root node of the multicast tree.
[note] [note]
BLLI value is unique at the sender node. But BLLI value is not BLLI value is unique at the sender node. But BLLI value is not
unique at the reciever node because multiple sender nodes may unique at the receiver node because multiple sender nodes may
allocate the same BLLI value. So, the receiver node must allocate the same BLLI value. So, the receiver node must
recognize BLLI value and the sender address. ATM Signaling recognize BLLI value and the sender address. ATM Signaling
messages(SETUP and ADD_PARTY) carry both the BLLI and the sender messages(SETUP and ADD_PARTY) carry both the BLLI and the sender
ATM address. The receiver node can realize which node sends the ATM address. The receiver node can realize which node sends the
BLLI message. BLLI message.
3.2.1 Outband notification using a small-sized field for point-to-point VC 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 This subsection describes procedures for establishing a VC and for
notification of its VCID between neighboring LSRs for unicast notification of its VCID between neighboring LSRs for unicast
traffic. VC pool [VCPOOL] can be applied. traffic. VC pool [VCPOOL] can be applied.
For point-to-point VC, either an upstream LSR or a downstream LSR can
allocate a VCID for a new VC.
The procedure employed when the upstream LSR assigns a VCID is as The procedure employed when the upstream LSR assigns a VCID is as
follows. follows.
1. An upstream LSR establishes a VC to the downstream LSR using ATM 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 signaling and supplies a value in the BLLI field that it is not
currently using for any other (incomplete) VCID notification currently using for any other (incomplete) VCID notification
transaction with this peer. transaction with this peer.
2. The upstream LSR notifies the downstream LSR of the association 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. between the BLLI and VCID values.
3. The downstream LSR establishes the association between the VC 3. The downstream LSR establishes the association between the VC
with the BLLI value and the VCID and sends an ACK message to the with the BLLI value and the VCID and sends an ACK message to the
upstream LSR. If the VCID is associated with some other VC upstream LSR.
between the upstream and downstream LSRs, that old VC is removed
from service.
4. After the upstream LSR receives the ACK message, it establishes 4. After the upstream LSR receives the ACK message, it establishes
the association between the VC and the VCID. The VC is ready to 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 be used. At this time the BLLI value employed in this transaction
is free for reuse. is free for reuse.
The procedure employed when a downstream LSR assigns a VCID is 5. After VCID notification, the upstream node sends the LDP REQUEST
as follows: message to the downstream node. The downstream node sends the LDP
mapping message, which contains the VCID value in the label TLV of LDP.
1. An upstream LSR establishes a VC by ATM signaling between the
downstream LSR with a unique BLLI value at this time.
2. The downstream LSR notifies the upstream LSR of a paired BLLI
value and VCID using a message dedicated for this purpose.
3. The upstream LSR establishes the association between the VC with
the BLLI value and the VCID and sends an ACK message to the
downstream LSR. If the VCID is associated with some other VC
between the upstream and downstream LSRs, that old VC is removed
from service.
4. After the downstream 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.
3.2.2 Outband notification using a small-sized field 3.2.2 Outband notification using a small-sized field
for point-to-multipoint VC for point-to-multipoint VC
This subsection describes procedures for establishing the first 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 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 tree including the notification of its VCID for a multicast stream
using point-to-multipoint VCs. using point-to-multipoint VCs.
In this procedure, an upstream LSR determines both the VCID and BLLI In this procedure, an upstream LSR determines both the VCID and BLLI
skipping to change at line 385 skipping to change at page 8, line 21
at the same time, the upstream waits for the completion of the at the same time, the upstream waits for the completion of the
signaling procedure that is using this BLLI value. signaling procedure that is using this BLLI value.
2. Go to step 2 of the procedure for the first VC. 2. Go to step 2 of the procedure for the first VC.
3.3 Outband notification 3.3 Outband notification
This method can be applied when a VC is established using a ATM 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 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 is large enough to carry a VCID value. Message format is described in
[GIT]. [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 Node A Node B
| | | |
|<-------------->| |--------------->| ATM signaling with VCID
| ATM Signaling | |<---------------|
| with VCID | | |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping
4 VCID Message Format 4 VCID Message Format
4.1 VCID Class Messages 4.1 VCID Messages
VCID class messages are added to the LDP specification [LDP]. An LDP An LDP VCID message consists of the LDP [LDP] fixed header followed
VCID PDU consists of an LDP common header followed by one or more by one or more VCID TLV. VCID PROPOSE inband message is sent as a
objects. VCID PROPOSE inband message is sent as a null encapsulation null encapsulation packet through a VC to be used as an LSP. There is
packet through a VC to be used as an LSP. A label value in the label only the label stack header before the LDP VCID PDU. A label value in
stack entry for VCID PROPOSE inband message is 4, that should be the label stack entry [ENCAPS] for VCID PROPOSE inband message is 4.
added as a reserved label value to the section 2.1 of [ENCAPS]. Other messages are sent as TCP packets. This is the same as LDP.
Other messages are sent as TCP packets.
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
4.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
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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Class | PDU Length | |U|VCID Inband Propose (0x0501) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Reserved | Msg Length | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Objects | | Label TLV |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Objects | | Optional Parameters |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Message Id
One octet unsigned integer containing the version number of the Four octet integer used to identify this message.
protocol. This version of the specification specifies protocol
Version = 0x01.
Msg Class
One octet integer defining the class of the LDP message.
VCID Class = 0x04
PDU Length
Two octet integer specifying the total length of this PDU in
bytes, excluding the common header.
LDP Identifier
Six octet field that uniquely identifiers the label space for
which this PDU applies. The first four octets encode an IP
address assigned to the LSR. This address should be the router-
id, also used in LSR-path-vector loop detection/prevention
objects. The last two octets identify a label space within the
LSR. For a platform-wide label space, these should both be
zero.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Type
The MsgType field identifies the type of message. The following
discovery messages are supported:
VCID Propose inband Message = 0x01
VCID Propose Message = 0x02
VCID ACK Message = 0x02
VCID NACK Message = 0x03
Msg Length
Two octet integer specifying the total length of all objects
associated with the message type.
4.1.1 VCID Propose inband Message
This message is sent as a null encapsulation packet with a label
value 4 through a VC to be used as an LSP.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+ Label TLV
| MANDATORY OBJECT | Type | Label TLV contains VCID value. Type of label TLV is VCID(0x0203).
+-----------------------+----------+
| VCID | 0x01 |
+-----------------------+----------+
| Address | 0x03 |
+-----------------------+----------+
4.1.2 VCID Propose Message 4.1.2 VCID Propose Message
Mandatory Objects An LSR uses the VCID PROPOSE message for the VCID notification
At least one of each mandatory object with associated object headers. procedure of the outband notification using a small-sized field.
This message is sent through the VC for the LDP.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| VCID | 0x01 |
+-----------------------+----------+
| Temporary ID | 0x02 |
+-----------------------+----------+
4.1.3 VCID ACK Message
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+ 0 1 2 3
| MANDATORY OBJECT | Type | 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
+-----------------------+----------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID | 0x01 | |U| VCID Propose (0x0502) | Message Length |
+-----------------------+----------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Temporary ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.4 VCID NACK Message Message Id
Four octet integer used to identify this message.
Mandatory Objects Label TLV
At least one of each mandatory object with associated object headers. Label TLV contains VCID value. Type of label TLV is VCID(0x0203).
+-----------------------+----------+ Temporary ID TLV
| MANDATORY OBJECT | Type | 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
| VCID | 0x01 | Type of label TLV is VCID temporary ID(0x0902).
+-----------------------+----------+
4.2 VCID Class Objects 4.1.3 VCID ACK Message
4.2.1 Object Header
All objects in a VCID message must begin with the following object An LSR send the VCID ACK message when the LSR accepts the VCID
header. This header is the same as LDP specification. PROPOSE message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Obj Type | Sub Type | Length | |U| VCID ACK (0x0503) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type Message Id
VCID_OBJECT = 0x01 Four octet integer used to identify this message. This value is the
TEMPORARY_ID_OBJECT = 0x02 same as that of received VCID PROPOSE message.
ADDRESS_OBJECT = 0x03
4.2.2 VCID Object Label TLV
The label TLV contains the VCID value of the received VCID PROPOSE
message. Type of label TLV is VCID(0x0203).
+-----------------------+-------+--------------------------+----------+ 4.1.4 VCID NACK Message
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| VCID | 0x01 | 0x01 Default | 4 |
+-------------------------------+--------------------------+----------+
Subtype = 0x01 Default An LSR send the VCID NACK message when the LSR does not accept the
VCID PROPOSE message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID | |U| VCID NACK (0x0504) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.3 Temporary ID Object Message Id
Four octet integer used to identify this message. This value is the
+-----------------------+-------+--------------------------+----------+ same as that of received VCID PROPOSE message.
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Temporary ID | 0x02 | 0x01 BLLI | 1 |
+-------------------------------+--------------------------+----------+
Subtype = 0x01 Default
0 Label TLV
0 1 2 3 4 5 6 7 8 The label TLV contains the VCID value of the received VCID PROPOSE
+-+-+-+-+-+-+-+-+-+ message. Type of label TLV is VCID(0x0203).
| BLLI |
+-+-+-+-+-+-+-+-+-+
4.2.4 Address Object 4.2 Objects
4.2.1 VCID Label TLV
+-----------------------+-------+--------------------------+----------+ An LSR uses VCID Label TLV to encode labels for use on the link which
| OBJECT | Type | Subtype(s) | Length | does not have the same data link label at both ends of a VC.
+-----------------------+-------+--------------------------+----------+
| Address | 0x02 | 0x01 Default | variable |
+-------------------------------+--------------------------+----------+
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address List Family |Source Address (variable length) |U|F|VCID Label (0x0203) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address (variable length) | | VCID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family VCID
This 16 bit quantity contains a value from ADDRESS FAMILY NUM- This is 4 byte VCID value.
BERS in Assigned Numbers [RFC1700] that encodes the address family
that the network layer addresses in the Addresses field are from.
Addresses
Two addresses encoded according to the Address Family Field,
padded to a 16-bit boundary. First address is a source address of
this object. Second address is a destination address of this
object.
4.3 Mapping messages
4.3.1 Label Object
An VCID subtype is added to label object of an advertisment class 4.2.2 VCID Temporary ID TLV
message in the LDP specification. This object is used for a label
mapping between SMD and VCID.
+-----------------------+-------+--------------------------+----------+ An LSR uses the VCID temporary ID TLV for the VCID notification
| OBJECT | Type | Subtype(s) | Length | procedure of the outband notification using a small-sized field.
+-----------------------+-------+--------------------------+----------+
| Label | 0x03 | 0x03 VCID | 4 |
+-------------------------------+--------------------------+----------+
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID | |U|F| VCID Temporary ID (0x0601)| 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
Security Considerations Security Considerations
Security issues are not discussed in this document. Security issues are not discussed in this document.
Intellectual Property Considerations Intellectual Property Considerations
Toshiba Corporation and Ennovate Networks may seek patent or other Toshiba Corporation and Ennovate Networks may seek patent or other
intellectual property protection for some of the aspects of the intellectual property protection for some of the aspects of the
technology discussed in this document. If any standards arising from technology discussed in this document. If any standards arising from
skipping to change at line 622 skipping to change at page 12, line 4
Intellectual Property Considerations Intellectual Property Considerations
Toshiba Corporation and Ennovate Networks may seek patent or other Toshiba Corporation and Ennovate Networks may seek patent or other
intellectual property protection for some of the aspects of the intellectual property protection for some of the aspects of the
technology discussed in this document. If any standards arising from technology discussed in this document. If any standards arising from
this document are or become protected by one or more patents assigned this document are or become protected by one or more patents assigned
to Toshiba Corporation, Toshiba intends to license them on reasonable to Toshiba Corporation, Toshiba intends to license them on reasonable
and non- discriminatory terms. and non- discriminatory terms.
Acknowledgments Acknowledgments
The authors would like to acknowledge the valuable technical comments The authors would like to acknowledge the valuable technical comments
of Shigeo Matsuzawa, Akiyoshi Mogi, Yasuhiro Katsube, Muneyoshi of Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, George Swallow
Suzuki, George Swallow and members of the LAST-WG of the WIDE Project. and members of the LAST-WG of the WIDE Project.
References References
[VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier", [VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier",
draft-demizu-mpls-vcid-01.txt, Oct. 1997 draft-demizu-mpls-vcid-01.txt, Oct. 1997
[VCPOOL] N. Demizu, et al., "VC pool", [VCPOOL] N. Demizu, et al., "VC pool",
draft-demizu-mpls-vcpool-00.txt, Oct. 1997 draft-demizu-mpls-vcpool-00.txt, Oct. 1997
[LDP] L. Andersson, et al., "LDP Specification",
draft-ietf-mpls-ldp-02.txt, Nov. 1998
[FRAME] R. Callon, et al., "A Framework for Multiprotocol Label [FRAME] R. Callon, et al., "A Framework for Multiprotocol Label
Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997 Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997
[GIT] M. Suzuki, "The Assignment of the Information Field and [GIT] M. Suzuki, "The Assignment of the Information Field and
Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 Protocol Identifier in the Q.2941 Generic Identifier and Q.2957
User-to-user Signaling for the Internet Protocol", User-to-user Signaling for the Internet Protocol",
draft-ietf-mpls-git-uus-assignment-00.txt, June 1998 draft-ietf-mpls-git-uus-01.txt, Dec. 1998
[ENCAPS] E. Rossen, et al., "MPLS Label Stack Encoding",
draft-ietf-mpls-label-encaps-02.txt, July 1998
[rfc1700] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, ISI, [ENCAPS] E. Rosen, et al., "MPLS Label Stack Encoding",
October 1994 draft-ietf-mpls-label-encaps-03.txt, Sep. 1998
Authors Information Authors Information
Ken-ichi Nagami Ken-ichi Nagami
R&D Center, Toshiba Corporation, Infomation & Communication Lab., Toshiba Corporation,
1 Komukai-Toshiba-cho, Saiwai-ku, 3-1-1 Asahigaoka, Hino,
Kawasaki, 210, Japan Tokyo, 191-8555, Japan
Phone: +81-44-549-2231 Phone: +81-42-585-3299
Email: nagami@isl.rdc.toshiba.co.jp Email: ken.nagami@toshiba.co.jp
Noritoshi Demizu Noritoshi Demizu
Graduate School of Information Science, Graduate School of Information Science,
Nara Institute of Science and Technology Nara Institute of Science and Technology
8916-5 Takayama, Ikoma, Nara 630-0101, Japan 8916-5 Takayama, Ikoma, Nara 630-0101, Japan
Phone: +81-743-72-5348 Phone: +81-743-72-5348
E-mail: nori-d@is.aist-nara.ac.jp Email: nori-d@is.aist-nara.ac.jp
Hiroshi Esaki Hiroshi Esaki
Computer and Network Division, Computer Center, University of Tokyo,
Toshiba Corporation, 2-11-16 Yayoi, Bunkyo-ku,
1-1-1 Shibaura, Tokyo, 113-8658, Japan
Minato-ku, 105-01, Japan Phone: +81-3-3812-1111
Email: hiroshi@isl.rdc.toshiba.co.jp Email: hiroshi@wide.ad.jp
Yasuhiro Katsube
Infomation & Communication Lab., Toshiba Corporation,
3-1-1 Asahigaoka, Hino,
Tokyo, 191-8555, Japan
Phone: +81-42-585-3299
Email: yasuhiro.katsube@toshiba.co.jp
Paul Doolan Paul Doolan
Ennovate Networks Ennovate Networks
330 Codman Hill Road 330 Codman Hill Road
Boxborough, MA Boxborough, MA
Phone: 978-263-2002 x103 Phone: 978-263-2002 x103
Email: pdoolan@ennovatenetworks.com Email: pdoolan@ennovatenetworks.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/