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]