draft-ietf-mpls-vcid-atm-03.txt   draft-ietf-mpls-vcid-atm-04.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 (Univ. Tokyo) Hiroshi Esaki (Univ. Tokyo)
Yasuhiro Katsube (Toshiba Corp.) Yasuhiro Katsube (Toshiba Corp.)
Paul Doolan (Ennovate Networks) Paul Doolan (Ennovate Networks)
April 1999 July 1999
Expires October 1999 Expires January 2000
VCID Notification over ATM link VCID Notification over ATM link for LDP
<draft-ietf-mpls-vcid-atm-03.txt> <draft-ietf-mpls-vcid-atm-04.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 characteristic 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 mapping messages. In [VCID], an identifier called a VCs in LDP mapping messages. An identifier called a Virtual
Virtual Connection ID (VCID) is introduced. VCID has the same value Connection ID (VCID) is introduced. VCID has the same value at both
at both ends of a VC. This document specifies the procedures for ends of a VC. This document specifies the procedures for the
the communication of VCID values between neighboring ATM-LSRs that communication of VCID values between neighboring ATM-LSRs that must
must occur in order to ensure this property. 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
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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
Information Element). Information Element).
The BLLI value is used as a temporary identifier for a VC during a The BLLI value is used as a temporary identifier for a VC during a
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". The BLLI value of a new VC
value of a new VC must not be assigned to other VCs during the must not be assigned to other VCs during the procedure to avoid
procedure to avoid identifier conflict. When the association among identifier conflict. When the association among the BLLI value, a
the BLLI value, a VCID value, and the corresponding VC is VCID value, and the corresponding VC is established, the BLLI value
established, the BLLI value can be reused for a new VC. VCID values can be reused for a new VC. VCID values can be assigned independently
can be assigned independently from BLLI values. from BLLI values.
Node A Node B Node A Node B
| | | |
|--------------->| ATM Signaling with BLLI |--------------->| ATM Signaling with BLLI
|<---------------| |<---------------|
| | | |
|--------------->| VCID PROPOSE with BLLI |--------------->| VCID PROPOSE with BLLI
| | | |
|<---------------| VCID ACK |<---------------| VCID ACK
| | | |
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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.
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 sends the VCID PROPOSE message through the VC for 2. The upstream LSR sends the VCID PROPOSE message through the VC for
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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. upstream LSR.
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.
5. After VCID notification, the upstream node sends the LDP REQUEST 5. After VCID notification, the upstream node sends the LDP REQUEST
message to the downstream node. The downstream node sends the LDP message to the downstream node. The downstream node sends the LDP
mapping message, which contains the VCID value in the label TLV of LDP. mapping message, which contains the VCID value in the label TLV of
LDP.
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 page 15, line 9 skipping to change at page 15, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| VPID (0x0703) | Length | |U|F| VPID (0x0703) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID | | VPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPID VPID
This is 2 byte VPID value. This is 2 byte VPID value.
Security Considerations Security Considerations
Security issues are not discussed in this document. 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 Acknowledgments
The authors would like to acknowledge the valuable technical comments The authors would like to acknowledge the valuable technical comments
of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki,
George Swallow and members of the LAST-WG of the WIDE Project. George Swallow and members of the LAST-WG of the WIDE Project.
References References
[VCID] N. Demizu, et al., "VCID: Virtual Connection Identifier",
draft-demizu-mpls-vcid-01.txt, Oct. 1997
[VCPOOL] N. Demizu, et al., "VC pool",
draft-demizu-mpls-vcpool-00.txt, Oct. 1997
[LDP] L. Andersson, et al., "LDP Specification", [LDP] L. Andersson, et al., "LDP Specification",
draft-ietf-mpls-ldp-03.txt, Jan. 1999 Work in Progress, June 1999
[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", Work in Progress, June 1999
[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-02.txt, March 1999 Work in Progress, July 1999
[ENCAPS] E. Rosen, et al., "MPLS Label Stack Encoding", [ENCAPS] E. Rosen, et al., "MPLS Label Stack Encoding",
draft-ietf-mpls-label-encaps-03.txt, Sep. 1998 Work in Progress, April 1999
Authors Information Authors Information
Ken-ichi Nagami Ken-ichi Nagami
Infomation & Communication Lab., Toshiba Corporation, Infomation & Communication Lab., Toshiba Corporation,
3-1-1 Asahigaoka, Hino, 3-1-1 Asahigaoka, Hino,
Tokyo, 191-8555, Japan Tokyo, 191-8555, Japan
Phone: +81-42-585-3299 Phone: +81-42-585-3299
Email: ken.nagami@toshiba.co.jp Email: ken.nagami@toshiba.co.jp
 End of changes. 

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