Network Working Group                                   Noritoshi Demizu
Internet Draft                                                   SonyCSL
Expiration Date: February 1998                            September 1997


            VC-ID, VC Pool, and ATM SVC Support for ATM-LSRs
                    <draft-demizu-mpls-vcid-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 the cost-performance and QoS assurance of Layer 2 devices
   and the flexibility and functionality of Layer 3 protocols.

   Some of these proposals assume that Label Switching Routers (LSRs)
   are placed in a homogeneous LSR cloud in a campus area network or a
   backbone network, and they are permanently connected directly to each
   other without intermittent connections.  However, this assumption
   sometimes does not hold true in the real situation.  For example,
   some of campuses will be connected via ATM SVC services, and LSR
   networks will be constructed hierarchically.  Furthermore, LSR
   networks will consist of heterogeneous datalinks such as ATM,
   Ethernet, and IEEE 1394.

   To deal with Virtual Connections (VCs) in these environments, this
   document proposes VC-ID and VC pool.  This document also proposes
   procedures to deal with ATM SVC services in ATM-LSRs.



Demizu                                                          [Page 1]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


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 (L2) devices and the flexibility and
   functionality of Layer 3 (L3) protocols.

   Some of these proposals assume that Label Switching Routers (LSRs)
   are placed in a homogeneous LSR cloud in a campus area network or a
   backbone network, and they are permanently connected directly each
   other without intermittent connections.  This assumption leads some
   proposed label distribution protocols (LDPs) [ARISP][RFC1953][TDP] to
   assume that an input label at an ingress node and the corresponding
   output label at an egress node of each Virtual Connections (VC) are
   always the same.

   However, in real situation, campuses will be connected via ATM VP,
   PVC, SVC, etc., and LSRs inside campuses may need to use existing ATM
   LANs such as LANE[LANE] as their underlying datalinks.  Furthermore,
   it will be common to construct LSR networks hierarchically, and some
   LSR networks will use other LSR networks for their underlying
   networks[INT_LSP].  In this case, higher level LSRs should use Label
   Switched Paths (LSPs) traversing lower level LSRs, that may obey
   other schemes.  Even L2 networks could be designed by applying label
   switching technology and could constitute hierarchical label
   switching networks at the bottom level[ARISLAN][PLASMA].  Moreover,
   hierarchical LSR networks will be constructed with heterogeneous
   datalinks such as ATM, Ethernet, and IEEE 1394.

   In these environments, a label often cannot be used as an identifier
   of a VC or an LSP (both will be denoted as a VC in this document),
   because it is very difficult to set up labels such that an input
   label at an originating node and the corresponding output label at a
   terminating node are always the same.

   Furthermore, certain types of VCs including ATM SVC require signaling
   to establish VCs before employing them and to release VCs after
   utilizing them.  Because signaling may take long time and carriers
   may charge each VC establishment, connection time and/or the amount
   of traffic, some kind of optimization is necessary to reduce the
   delays and the costs of signaling.

   To solve these problems, this document proposes to identify a VC with
   a VC-ID, which is independent from datalink specific information such
   as a label, and to introduce a VC pool to reduce the delays and the
   costs of VC establishment due to signaling.  This document also
   proposes procedures to deal with ATM SVC services in ATM-LSRs.




Demizu                                                          [Page 2]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


2. VC-ID Proposal

   To identify a VC between peer LSRs that are separated by L2 switches,
   this document proposes to introduce a new VC identifier called VC-ID
   to be used instead of a label such as VPI/VCI to identify a VC.  VC-
   ID is significant between peer LSRs on the same hierarchical level.
   The value of a VC-ID is conceptually independent from the value of
   the label or any other datalink specific information of the VC.  The
   length and the range of VC-ID would vary for each LDP and may be
   constrained by an environment where each LSR runs.

   In this document, a label is re-defined as a short fixed length
   physically contiguous index that specifies where and how the cells or
   frames should be forwarded by layers lower than L3.

   A VC-ID value for a VC should be significant between peer LSRs.  In
   the case where peer LSRs are connected directly, it is easy to
   achieve this by using the label value as the VC-ID value.  However,
   in other cases, peer LSRs have to communicate with each other to
   determine a VC-ID value for each VC.  The notification may be
   performed by either using an extended LDP, a supplementary protocol
   or a signaling protocol used by the datalink.  The details of this
   communication procedure depend on each LDP and underlying network,
   and is out of the scope of this document.  Note that this
   notification that determines the VC-ID value does not introduce any
   conflict to current schemes.


3. VC Pool Proposal

   A VC pool is where a number of VCs is prepared a priori.  VCs can be
   picked immediately from the VC pool on BIND procedures and will be
   put back to the VC pool on UNBIND procedures.  So, VCs can be
   recycled without unnecessary signaling.  If there are too many VCs in
   a VC pool, some of them may be released to reduce the costs to
   maintain these VCs.

   Each established VC in a VC pool should be associated with a VC-ID,
   because it is sometimes impossible to use datalink specific
   information as an identifier for a VC in a VC pool due to its small
   range.  However, the association between a VC and a VC-ID can be
   postponed until the VC will be used if protocol optimization is
   necessary.

   An LSR may have multiple VC pools for each VC class.  Examples of VC
   classes are UBR VCs, CBR VCs, point-to-multipoint VCs, etc.

   The advantages of VC pool are:



Demizu                                                          [Page 3]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


     - It is possible to reduce delays and costs of signaling.
     - It hides the details of signaling procedures of each datalink from
       LDPs.
     - It becomes easy to use both directions of bi-directional VCs such
       as ATM SVC with a VC pool, because each direction of a VC can be
       used independently.

   Note that the idea of VC pool does not conflict with current
   implementations that do not have a VC pool, because they can be
   considered to have a special case of VC pool, where all VCs are
   prepared a priori and there is no need to establish VCs nor to
   release VCs.  Also note that VC pool can be applied to intermittent
   datalinks other than ATM.


4. ATM SVC Support for ATM-LSRs

4.1 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 L3 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 VC-ID notification procedure.
   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 VC-ID has been completed, the BLLI
   value of the new VC can be assigned to other VCs.  VC-ID 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.




Demizu                                                          [Page 4]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


   There can be another method to exchange identity information of VCs
   between neighboring LSRs.  For example, a caller can send an in-band
   control message to a callee over the established new VC in order to
   notify the identity information of the VC.  This method works well in
   the unicast case, but causes a problem in multicast.  The caller
   needs to temporarily splice the active VC each time a new leaf LSR
   joins the multicast tree in order to send such in-band messages to
   the leaf.  This will cause serious degradation in the performance at
   the LSR.  Otherwise, we should mandate non-interleaving switching
   fabric for the LSR.  So this document does not employ this method.

   The remaining part of this section describes procedures to notify a
   VC-ID between a caller and a callee.  Detailed procedures should be
   defined for each label distribution protocol.  How to get the ATM
   address of a callee at a caller is out of the scope of this document.


4.2 Support for Unicast Traffic

   This section proposes procedures to establish a VC and to notify its
   VC-ID between neighboring LSRs for unicast traffic.

   This document proposes following procedures, for when an upstream LSR
   allocates a VC-ID 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 VC-ID should be
            postponed until the VC starts to be used, resume here.)
        2. The upstream LSR notifies a pair of the BLLI value and a
           VC-ID 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 VC-ID, and sends an ACK message to the upstream
           LSR.  If the VC-ID 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 VC-ID. 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 VC-ID for a new VC.



Demizu                                                          [Page 5]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


        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 VC-ID should be
            postponed until the VC starts to be used, resume here.)
        2. The downstream LSR notifies a pair of the BLLI value and a
           VC-ID to the upstream LSR by using a message dedicated for
           this purpose or together within a BIND message.
        3. The upstream LSR associates the VC having the BLLI value
           with the VC-ID, and sends an ACK message to the downstream
           LSR. If the VC-ID 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 VC-ID. 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.3 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 VC-ID for a multicast stream by
   using point-to-multipoint VCs.

   In this proposal, an upstream LSR determines both VC-ID and BLLI value
   in the multicast case.  The reason the BLLI value is determined by an
   upstream LSR is described in Section 4.1.  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
           VC-ID 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 VC-ID, and sends an ACK message to the upstream
           LSR.  If the VC-ID is used by some other VC between the
           upstream, the old VC is discarded.



Demizu                                                          [Page 6]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


        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 procedure to establish 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
           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.


4. Conclusion

   Label switching will be applied to various networks including
   backbone networks, campus area networks and home area networks.  In
   these environments, LSR networks will be constructed hierarchically.
   However, hierarchical label switching has several issues to be solved
   in both vertical and horizontal directions.

   This document focuses on some issues in the vertical direction and
   proposes VC-ID and VC pool.  The VC-ID makes it possible to identify
   a VC in any layer of the hierarchy, and the VC pool reduces the
   delays and the costs of establishing and releasing VCs and VC-ID
   notification.  Both VC-ID and VC pool do not conflict with current
   schemes.

   This document also proposes procedures to use ATM SVCs from LSRs.
   This proposal hides the limitation from the range of BLLI and avoids
   modifications to the core messages of label distribution protocols.


Security Considerations

   Security issues are not discussed in this document.


Acknowledgments

   The author would like to acknowledge valuable technical comments from
   members of LAST-WG of WIDE Project, in particular from Kenichi
   Nagami, Hiroshi Esaki and Yasuhiro Katsube.  The author also would
   like to thank Paul Doolan for his valuable technical comments.




Demizu                                                          [Page 7]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


References

[MPLSFW] R. Callon, et. al.,
     "A Framework for Multiprotocol Label Switching",
     draft-ietf-mpls-framework-01.txt, Jul 1997
[ARIS]    A. Viswanathan, et. al.,
     "ARIS: Aggregate Route-Based IP Switching",
     draft-viswanathan-aris-overview-00.txt, Mar 1997
[ARISP]   N. Feldman, A. Viswanathan,
     "ARIS Specification",
     draft-feldman-aris-spec-00.txt, Mar 1997
[RFC2098] Y. Katsube, et. al.,
     "Toshiba's Router Architecture Extensions for ATM : Overview",
     RFC2098, Feb 1997
[RFC2129] K. Nagami, et. al.,
     "Toshiba's Flow Attribute Notification Protocol (FANP) Specification",
     RFC2129, Apr 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
[TDP]     P. Doolan et. al.,
     "Tag Distribution Protocol",
     draft-doolan-tdp-spec-01.txt, May 1997
[LANE]    ATM Forum, "LAN Emulation over ATM Specification Ver.1.0",
     April, 1995.
[PLASMA] K. Fujikawa,
     "Point-to-point Link Assembly for Simple Multiple Access (PLASMA)",
     draft-fujikawa-plasma-00.txt, Mar 1997
[ARISLAN] Steven Blake, et. al.,
     "ARIS Support for LAN Media Switching",
     draft-blake-aris-lan-00.txt, Mar 1997
[INT_LSP] Y. Katsube, H. Esaki,
     "Interoperation Between Distinct Types of Label Switched Paths",
     draft-katsube-interop-between-lsps-00.txt, Jun 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

Author Information

   Noritoshi Demizu
   Sony Computer Science Laboratory, Inc.



Demizu                                                          [Page 8]


Internet Draft        draft-demizu-mpls-vcid-00.txt       September 1997


   Takanawa Muse Bldg.
   3-14-13, Higashigotanda,
   Shinagawa-ku, Tokyo, 141 Japan
   Phone: +81-3-5448-4380
   E-mail: demizu@csl.sony.co.jp














































Demizu                                                          [Page 9]