Internet Draft 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]