MPLS Working Group                       Ken-ichi Nagami (Toshiba Corp.)
INTERNET DRAFT                          Noritoshi Demizu (SonyCSL/NAIST)
                                           Hiroshi Esaki (Toshiba Corp.)
                                         Paul Doolan (Ennovate Networks)
                                                              March 1998
                                                  Expires September 1998


                    VCID Notification over ATM link
                   <draft-ietf-mpls-vcid-atm-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 integrate Layer
   2 and Layer 3.  The ATM Label Switching Router (ATM-LSR) is one of
   the major applications of label switching. Because the ATM layer
   labels (VPI and VCI) associated with a VC may change on each VC of
   that VCC, it is not possible to use them to identify a VCC in label
   binding messages. The concept of Virtual Connection Identifier (VCID)
   is introduced to solve this problem.  VCID has the same value at both
   ends of a VCC.  This document specifies the procedures for the
   communication of VCID values between neighboring ATM-LSRs that must
   occur in order to ensure this property.


1. Introduction

   Several label switching schemes have been proposed to integrate Layer
   2 and Layer 3.  The ATM Label Switching Router (ATM-LSR) is one of the
   major applications of label switching.

   In the case of ATM VCCs, the VPI and VCI labels are, in the general



Nagami, et al.                                                 [Page  1]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998


   case, rewritten with new values at every switch node through which
   the VCC passes and cannot be used to provide end to end
   identification of a VCC.

   In the context of MPLS 'flows', which are classes of packets that
   have some common charachteristic that may be deduced by examination
   of the layer 3 header in the packets, are bound to layer 2 'labels'.
   We speak of flows being 'bound' to l abels.  These bindings are
   conveyed between peer LSRs by means of a Label Distributi on Protocol
   [LDP].

   In order to apply MPLS to ATM links, we need some way to identify ATM
   VCCs in LDP binding messages. In [VCID], an identifier called a
   Virtual Connection ID (VCID) is introduced. VCID has the same value
   at both ends of a VCC.  This document specifies the procedures for
   the communication of VCID values between neighboring ATM-LSRs that
   must occur in order to ensure this property.


2. Overview of VCID Notification Procedures

2.1 VCID Notification procedures

   The ATM has several types of VCCs (transparent point-to-point
   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 VCC.  For example,
   two nodes are directly connected (i.e., without intervening ATM
   switches) or are connected through a VP with the same VPI value at
   both ends of the VP.

   There are two broad categories of VCID notification procedures;
   inband and out of band. The categorisation refers to the connection
   over which the messages of the VCID notification procedure are
   forwarded. In the case of the inband procedures, those messages are
   forwarded over the VCC to which they refer. In contrast the out of
   band procedures transmit the messages over some other connection
   (than the VCC to which they refer).

   We list below the various types of link and briefly mention the VCID
   notification procedures employed and the rational for that
   choice. The procedures themselves are discussed in detail in later
   sections.


   Transparent point-to-point link : no VCID notification
      VCID notification procedure is not necessary because the label
      (i.e., VPI/VCI) is the same at each end of the VC.

   VP : inband notification (as a default mechanism)



Nagami, et al.                                                 [Page  2]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998


    - Inband notification
      VCID notification is needed because the VPI at each end of the VC
      may not be the same. Inband VCID notification [VCID] is used in
      this case.

    - No notification
      If a node has only one VP to a neighboring node, VCID notification
      procedure is not mandatory. The VCI can be used as the VCID. This
      is because the VCI value is the same at each end of the VP.

      [Note] For easier implementation, using inband notification even
             in the case of a single VP is recommended.

   PVC : inband notification
      Inband VCID notification [VCID] is used in this case because the
      labels at each end of the VC may not be the same.

   SVC : there are three possibilities
    - Out of band notification
      If a signaling message has a field which is large enough to carry
      a VCID value (e.g., UUS [UUS]), then the VCID is carried directly
      in it.

    - Outband notification using a small-sized field
      If a signaling message has a field which is not large enough to
      carry a VCID value, this procedure is used.

    - Inband notification
      If a signaling message can not carry user information, this
      procedure is used.

      When an LSP is a point-to-multipoint VC and an ATM switch in an
      LSR is not capable of VC merge, it may cause problems in
      performance and quality of service.  When the LSR wants to add a
      new leaf to the LSP, it needs to split the active LSP temporarily
      to send an inband notification message.


2.2 VCID Assignment

   A VCID value is assigned by either an upstream node or a downstream
   node depending on the type of VC.  For a point-to-point VC, either
   the upstream node or the downstream node could assign a VCID
   value. For a point-to-multipoint VC, only an upstream (root) node can
   assign a VCID value.


3. VCID Notification Procedures




Nagami, et al.                                                 [Page  3]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998


3.1 Inband Notification Procedures

3.1.1 Inband Notification for Point-to-point VC

   VCID notification is performed by transmitting a control message
   through the VCC newly established (by signalling or management) for
   use as an label switched path (LSP) [ARCH], The procedure for VCID
   notification between two nodes A and B is detailed below.

   0. Node A establishes a VCC to the destination LSR B. (by signalling
      or management)

   1. Node A selects a VCID value.

   2. Node A sends a message which contains the VCID value through the
      newly established VCC to Node B.

   3. Node A establishes an association between the label for the VC and
      the VCID value.

   4. Node B receives the message from the VCC and establishes an
      association between the VCID in the message and that VCC.

   5. Node B sends an ACK message to node A.

   6. After Node A receives the ACK message, node A and node B both
      associate the VCID with the same VCC.

       Node A           Node B
         |                |
         |--------------->|
         |     VCID       |
         |                |
         |<---------------|
         |      ACK       |


3.1.2 Inband notification for point-to-multipoint VC

   VCID notification is performed by sending a control message through
   the VCC to be used as an LSP. The upstream node must assign the VCID
   value, the procedure by which it notifies the downstream node of that
   value is given below. The procedure is used when a new VCC is created
   or a new leaf is added to the VCC.

   First, the procedure for establishing the first VC is described.

   1. The upstream node assigns a VCID value for the VCC.  When the VCID
      value is already assigned to a VCC, it is used for VCID.



Nagami, et al.                                                 [Page  4]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998



   2. The upstream node sends a message which contains the VCID value
      and the address of the upstream node through the VCC used for a
      label switched path. This message is transferred to all leaf
      nodes.

   3. The upstream node establishes an association between the label for
      the VC and the VCID value.

   4. The downstream nodes receiving the message check the address of
      the upstream node. If the address is not the same network prefix
      as own address, the message is discarded. Otherwise, the
      downstream nodes establish an association between the VCID in the
      message and the VC from which the message is received.

   5. The downstream nodes send an ACK message to the upstream node.

   6. After the upstream node receives the ACK messages, the upstream
      node and the downstream nodes share the VCID.

       Upstream        Downstream 1   Downstream 2
         |                |               |
         |-----------+--->|               |
         |     VCID  +------------------->|
         |                |               |
         |<---------------|               |
         |      ACK       |               |
         |<-------------------------------|
         |              ACK               |


   Second, the procedure for adding a leaf to the existing
   point-to-multipoint VC is described.

   0. The upstream node adds the downstream node, using the ATM
      signaling.

   1. The VCID value which already assigned to the VCC is used.

   2. The upstream node sends a message which contains the VCID value
      and the address of the upstream node through the VCC used for a
      label switched path. This message is transferred to all leaf
      nodes.

   3. The downstream nodes receiving the message check the address of
      the upstream node. If the address is not the same network prefix
      as own address, the message is discarded. Otherwise, the
      downstream nodes establish an association between the VCID in the
      message and the VC from which the message is received.



Nagami, et al.                                                 [Page  5]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998



   4. After the upstream node receives the ACK messages, the upstream
      node and the downstream nodes share the VCID.


3.2 Outband Notification using a small-sized field

   This method can be applied when a VC is established using a signaling
   message and the message has a field which is not large enough to
   carry a VCID value.

   The signaling SETUP message of 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 protocol field in the BLLI IE (Broadband Low Layer
   Information Information Element).

   The BLLI value is used as a temporary identifier for a VC during a
   VCID notification procedure.  This mechanism is defined as "Outband
   Notification using a small-sized field" described in [VCID]. The BLLI
   value of a new VC must not be assigned to other VCs during the
   procedure to avoid identifier conflict.  When the association among
   the BLLI value, a VCID value, and the corresponding VC is
   established, the BLLI value can be reused for a new VC. VCID values
   can be assigned independently from BLLI values.

       Node A           Node B
         |                |
         |<-------------->|
         | ATM Signaling  |
         | with BLLI      |
         |                |
         |--------------->|
         |  BLLI & VCID   |
         |                |
         |<---------------|
         |      ACK       |

   A point-to-multipoint VC can also be established using ADD_PARTY of
   ATM Forum Signaling.  ADD_PARTY adds a new VC leaf to an existing VC
   or an existing VC tree.  In this procedure, the BLLI value of
   ADD_PARTY has to be the same value as that used to establish the
   first point-to-point VC of the tree.  The same BLLI value can be used
   in different VC trees only when these VC trees can not add a leaf at
   the same time. As a result, the BLLI value used in the signaling must
   be determined by the root node of the multicast tree.

   [note]
      BLLI value is unique at the sender node.  But BLLI value is not
      unique at the reciever node because multiple sender nodes allocate



Nagami, et al.                                                 [Page  6]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998


      the same BLLI value.  So, the receiver node must recognize BLLI
      value and the sender address.  ATM Signaling messages(SETUP and
      ADD_PARTY) carry both the BLLI and the sender ATM address.  The
      receiver node can realize which node sends the BLLI message.


3.2.1 Outband notification using a small-sized field for point-to-point VC

   This subsection describes procedures for establishing a VCC and for
   notification of its VCID between neighboring LSRs for unicast
   traffic.  VC pool [VCPOOL] can be applied.

   For point-to-point VC, either an upstream LSR or a downstream LSR can
   allocate a VCID for a new VC.

   The procedure employed when the upstream LSR assigns a VCID is as
   follows.

   1. An upstream LSR establishes a VCC to the downstream LSR using ATM
      signaling and supplies a value in the BLLI field that it is not
      currently using for any other (incomplete) VCID notification
      transaction with this peer.

   2. The upstream LSR notifies the downstream LSR of the association
      between the BLLI and VCID values. The precise form of the message
      used is outside the scope of this document but it could be
      dedicated to this purpose or a modified LDP BIND message.

   3. The downstream LSR establishes the association between the VCC
      with the BLLI value and the VCID and sends an ACK message to the
      upstream LSR.  If the VCID is associated with some other VCC
      between the upstream and downstream LSRs, that old VCC is removed
      from service.

   4. After the upstream LSR receives the ACK message, it establishes
      the association between the VCC and the VCID. The VCC is ready to
      be used. At this time the BLLI value employed in this transaction
      is free for reuse.

   The procedure employed when a downstream LSR assigns a VCID is
   as follows:

   1. An upstream LSR establishes a VCC by ATM signaling between the
      downstream LSR with a unique BLLI value at this time.

   2. The downstream LSR notifies the upstream LSR of a paired BLLI
      value and VCID using a message dedicated for this purpose or
      together within a BIND message.




Nagami, et al.                                                 [Page  7]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998


   3. The upstream LSR establishes the association between the VCC with
      the BLLI value and the VCID and sends an ACK message to the
      downstream LSR. If the VCID is associated with some other VCC
      between the upstream and downstream LSRs, that old VCC is removed
      from service.

   4. After the downstream LSR receives the ACK message, it establishes
      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
      is free for reuse.


3.2.2 Outband notification using a small-sized field
      for point-to-multipoint VC

   This subsection describes procedures for establishing the first VC
   for a multicast tree and for adding a new VC leaf to an existing VCC
   tree including the notification of its VCID for a multicast stream
   using point-to-multipoint VCs.

   In this procedure, an upstream LSR determines both the VCID and BLLI
   value in the multicast case.  The reason that the BLLI value is
   determined by an upstream LSR is described above.

   First, the procedure for establishing the first VC is described.

   1. An upstream LSR establishes a VC by ATM Forum Signaling between
      the downstream LSR with a unique BLLI value at this time.

   2. The upstream LSR notifies the downstream LSR of a paired BLLI
      value and VCID using a message dedicated for this purpose or
      together within a BIND message.

   3. The downstream LSR establishes the association between the VC with
      the BLLI value and the VCID and sends an ACK message to the
      upstream LSR.  If the VCID is used by some other VC between the
      upstream and downstream LSRs, 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.

   Second, the procedure for adding a leaf to the existing
   point-to-multipoint VC is described.

   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.



Nagami, et al.                                                 [Page  8]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998



   2. Go to step 2 of the procedure for the first VC.


3.3 Outband notification

   This method can be applied when a VC is established using a signaling
   message and the message has a field (e.g., UUS [UUS]) which is large
   enough to carry a VCID value.

       Node A           Node B
         |                |
         |<-------------->|
         | ATM Signaling  |
         | with VCID      |


Security Considerations

   Security issues are not discussed in this document.


Intellectual Property Considerations

   Toshiba Corporation and Ennovate Networks 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 the valuable technical comments
   of the members of the LAST-WG of the WIDE Project.


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

   [ARCH] R. Callon, et al., "A Framework for Multiprotocol Label
      Switching", draft-ietf-mpls-framework-02.txt, Nov. 1997




Nagami, et al.                                                 [Page  9]

Internet Draft        draft-ietf-mpls-vcid-atm-00.txt         March 1998


   [UUS] M. Suzuki, "The Assignment of the Information Field and
      Protocol Identifier in the Q.2941 Generic Identifier and Q.2957
      User-to-user Signaling for the Internet Protocol",
      draft-suzuki-git-uus-assignment-00.txt, Nov. 1997

Authors Information

   Ken-ichi Nagami
   R&D Center, Toshiba Corporation,
   1 Komukai-Toshiba-cho, Saiwai-ku,
   Kawasaki, 210, Japan
   Phone: +81-44-549-2231
   Email: nagami@isl.rdc.toshiba.co.jp

   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

   Hiroshi Esaki
   Computer and Network Division,
   Toshiba Corporation,
   1-1-1 Shibaura,
   Minato-ku, 105-01, Japan
   Email: hiroshi@isl.rdc.toshiba.co.jp

   Paul Doolan
   Ennovate Networks
   330 Codman Hill Road
   Boxborough, MA
   Phone: 978-263-2002 x103
   Email: pdoolan@ennovatenetworks.com
















Nagami, et al.                                                 [Page 10]