Network Working Group Noritoshi Demizu (SonyCSL Inc.)
Internet Draft Ken-ichi Nagami (Toshiba Corp.)
Expiration Date: April 1998 Paul Doolan (Cisco Systems Inc.)
Hiroshi Esaki (Toshiba Corp.)
October 1997
ATM SVC Support for ATM-LSRs
<draft-demizu-mpls-atm-svc-00.txt>
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
Several label switching schemes have been proposed to fuse and
integrate Layer 2 and Layer 3. ATM Label Switching Router (ATM-LSR)
is one of the major applications of label switching. Some ATM-LSRs
will need to support ATM SVC services, which requires signaling to
establish VCs before employing them and to release VCs after
utilizing them. This document proposes procedures to deal with ATM
SVCs between ATM-LSRs.
1. Introduction
Several label switching schemes[ARIS][RFC2098][RFC1953][RFC2105] have
been proposed to fuse and integrate the cost-performance and QoS
assurance of Layer 2 devices and the flexibility and functionality of
Layer 3 protocols.
Demizu, et al. [Page 1]
Internet Draft draft-demizu-mpls-atm-svc-00.txt October 1997
These label switching schemes can be applied to various datalinks.
ATM Label Switching Router (ATM-LSR) is one of the major applications
of label switching. Some ATM-LSRs will need to support ATM SVC,
which requires signaling to establish Virtual Connections (VCs)
before employing them and to release VCs after utilizing them.
This document proposes procedures to deal with ATM SVCs between ATM-
LSRs.
Although ATM address selection is important to set up ATM SVCs, it is
out of the scope of this document. ATM-LSRs should have ATM address
selection mechanisms such as static configuration, ATM ARP, and NHRP.
2. ATM Forum Signaling
The ATM Forum defines a signaling protocol to set up SVCs. In this
document, it is called "ATM Forum Signaling".
Callers can transfer out-of-band information to callees by the ATM
Forum Signaling. BLLI is one of information that must be transferred
and is a user specific 7 bit field in the Layer 3 protocol field in
the BLLI IE (Broadband Low Layer Information, Information Element).
When a new VC is established by ATM Forum Signaling, the callee can
read the BLLI value and caller's ATM address of the VC.
In the proposal of this document, the BLLI value is used as a
temporary identifier for a VC during a VCID notification procedure,
which follows the "Outband Notification by using a small sized field"
method described in [VCID]. So the BLLI value of a new VC should not
be assigned for other VCs during the procedure to avoid conflicts.
After the association of the VC having the BLLI value to a VCID has
been completed, the BLLI value of the new VC can be assigned to other
VCs. VCID values can be assigned independently from BLLI values.
A point-to-multipoint VC can also be established by using ADD_PARTY
of ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing
VC or an existing VC tree and makes a point-to-multipoint VC tree as
a result. In this procedure, the BLLI value of ADD_PARTY should be
the same value as that was used to establish the first point-to-point
VC of the tree. However, different VC trees can use the same BLLI
value without any conflicts between them if VC trees that use the
same BLLI value do not establish VCs nor add VCs simultaneously. So
the BLLI value used for signaling should be determined by the root
node of multicast tree for consistency.
The remaining part of this document describes the outlines of
procedures to notify a VCID value between a caller and a callee.
Demizu, et al. [Page 2]
Internet Draft draft-demizu-mpls-atm-svc-00.txt October 1997
Detailed procedures should be defined for each label distribution
protocol.
3. Support for Unicast Traffic
This section proposes procedures to establish a VC and to notify its
VCID between neighboring LSRs for unicast traffic. VC pool[VCPOOL]
is used for unicast.
This document proposes following procedures, for when an upstream LSR
allocates a VCID for a new VC.
0. In the case where a downstream LSR starts to prepare a VC in
the VC pool, the downstream LSR sends a VC establishment
request message to its upstream LSR. Otherwise, skip step 0.
1. An upstream LSR establishes a VC by ATM Forum Signaling
between the downstream LSR with a unique BLLI value at this
moment.
(If the association between the VC and a VCID should be
postponed until the VC starts to be used, suspend here.)
2. The upstream LSR notifies a pair of the BLLI value and a
VCID to the downstream LSR by using a message dedicated
for this purpose or together within a BIND message.
3. The downstream LSR associates the VC having the BLLI value
with the VCID, and sends an ACK message to the upstream
LSR. If the VCID is used by some other VC between the
upstream, the old VC is discarded.
4. After the upstream LSR receives the ACK message,
it associates the VC with the VCID. The VC is ready to be
used at this step, and the BLLI value that was allocated to
the VC can be re-used for another VC.
This document proposes following procedures for when a downstream LSR
allocates a VCID for a new VC.
0. In the case where a downstream LSR starts to prepare a VC in
the VC pool, the downstream LSR sends a VC establishment
request message to its upstream LSR. Otherwise, skip step 0.
1. An upstream LSR establishes a VC by ATM Forum Signaling
between the downstream LSR with a unique BLLI value at this
moment.
(If the association between the VC and a VCID should be
postponed until the VC starts to be used, suspend here.)
2. The downstream LSR notifies a pair of the BLLI value and a
VCID to the upstream LSR by using a message dedicated for
Demizu, et al. [Page 3]
Internet Draft draft-demizu-mpls-atm-svc-00.txt October 1997
this purpose or together within a BIND message.
3. The upstream LSR associates the VC having the BLLI value
with the VCID, and sends an ACK message to the downstream
LSR. If the VCID is used by some other VC between the
downstream, the old VC is discarded.
4. After the downstream LSR receives the ACK message,
it associates the VC with the VCID. The VC is ready to be
used at this step, and the BLLI value that was allocated to
the VC can be re-used for other VC.
4. Support for multicast traffic
This section proposes procedures to establish the first VC for a
multicast stream and to add a new VC leaf to an existing VC tree
including the notification of its VCID for a multicast stream by
using point-to-multipoint VCs.
In this proposal, an upstream LSR determines both VCID and BLLI value
in the multicast case. The reason the BLLI value is determined by an
upstream LSR is described in Section 2. Since it is difficult to
recycle point-to-multipoint VCs, the VC pool is not used for
multicast.
This document proposes the following procedure to establish the first
VC.
1. An upstream LSR establishes a VC by ATM Forum Signaling
between the downstream LSR with a unique BLLI value at this
moment.
2. The upstream LSR notifies a pair of the BLLI value and a
VCID to the downstream LSR by using a message dedicated
for this purpose or together within a BIND message.
3. The downstream LSR associates the VC having the BLLI value
with the VCID, and sends an ACK message to the upstream
LSR. If the VCID is used by some other VC between the
upstream, 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.
This document proposes the following procedures for the second VC or
later.
1. The upstream LSR establishes a VC by 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
Demizu, et al. [Page 4]
Internet Draft draft-demizu-mpls-atm-svc-00.txt October 1997
waits for the completion of the signaling procedure that is
using this BLLI value.
2. Goto step 2 of the procedure for the first VC.
Security Considerations
Security issues are not discussed in this document.
Intellectual Property Considerations
Toshiba Corporation may seek patent or other intellectual property
protection for some of the aspects of the technology discussed in
this document. If any standards arising from this document are or
become protected by one or more patents assigned to Toshiba
Corporation, Toshiba intends to license them on reasonable and non-
discriminatory terms.
Acknowledgments
The authors would like to acknowledge valuable technical comments
from members of LAST-WG of WIDE Project.
References
[ARIS] A. Viswanathan, et al.,
"ARIS: Aggregate Route-Based IP Switching",
draft-viswanathan-aris-overview-00.txt, Mar 1997
[RFC2098] Y. Katsube, et al.,
"Toshiba's Router Architecture Extensions for ATM : Overview",
RFC2098, Feb 1997
[RFC1953] P. W. Edwards, et al.,
"Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0",
RFC1953, May 1996
[RFC2105] Y. Rekhter, et al.,
"Cisco Systems' Tag Switching Architecture Overview",
RFC2105, Feb 1997
[ATM_SVC] H. Esaki, et al.,
"IP Address Resolution and ATM Signaling for MPLS over ATM SVC services"
draft-katsube-mpls-over-svc-00.txt, Jun 1997
[TAG_ATM] B. Davie, et al.,
"Use of Tag Switching With ATM"
draft-davie-tag-switching-atm-01.txt, Jan 1997
[VCID] N. Demizu, et al.,
"VCID: Virtual Connection Identifier",
Demizu, et al. [Page 5]
Internet Draft draft-demizu-mpls-atm-svc-00.txt October 1997
draft-demizu-mpls-vcid-01.txt, Oct 1997
[VCPOOL] N. Demizu, et al.,
"VC pool",
draft-demizu-mpls-vcpool-00.txt, Oct 1997
Authors Information
Noritoshi Demizu
Sony Computer Science Laboratory, Inc.
Takanawa Muse Bldg.
3-14-13, Higashigotanda,
Shinagawa-ku, Tokyo, 141 Japan
Phone: +81-3-5448-4380
E-mail: demizu@csl.sony.co.jp
E-mail: nori-d@is.aist-nara.ac.jp
Ken-ichi Nagami
R&D Center, Toshiba Corporation,
1 Komukai-Toshiba-cho, Saiwai-ku,
Kawasaki, 210, Japan
Email: nagami@isl.rdc.toshiba.co.jp
Paul Doolan
cisco Systems, Inc.
250 Apollo Drive.
Chelmsford, MA 01824, USA
Phone: +1-508-244-8917
email: pdoolan@cisco.com
Hiroshi Esaki
Computer and Network Division,
Toshiba Corporation,
1-1-1 Shibaura,
Minato-ku, 105-01, Japan
Email: hiroshi@isl.rdc.toshiba.co.jp
Demizu, et al. [Page 6]