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


                  VCID: Virtual Connection Identifier
                    <draft-demizu-mpls-vcid-01.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 connected directly to each other.
   However, this assumption sometimes does not hold true in the real
   situation.  For example, some campuses will be connected via ATM SVC
   service, and LSR networks will be constructed hierarchically.

   To deal with Virtual Connections (VCs) in these environments, this
   document proposes to identify a VC with a VCID instead of a label.

1. Introduction



Demizu, et al.                                                  [Page 1]


Internet Draft        draft-demizu-mpls-vcid-01.txt         October 1997


   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 connected directly each other.  This
   assumption leads some proposed label distribution protocols (LDPs)
   [ARISP][RFC1953][TDP] to assume that an input label at an ingress
   node of a Virtual Connections (VC) and the corresponding output label
   at an egress node of the VC are always the same.

   However, in real situation, some campus gateway LSRs will be
   connected via ATM VP, PVC, SVC, Frame Relay, etc., and LSRs inside
   campuses will be connected via ATM, IEEE 1394, etc.  Furthermore, it
   will be common to construct LSR networks hierarchically, where higher
   level LSRs will treat Label Switched Paths (LSPs) traversing lower
   level LSRs as VCs of underlying networks.

   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 ingress node of a VC and the corresponding output label
   at an egress node of the VC are always the same.

   To solve this problem, this document proposes to identify a VC with a
   VCID instead of a label.


2. Proposal of VCID

   To identify a VC between peer LSRs that are separated by L2 switches,
   this document proposes to introduce a new VC identifier called VCID
   to be used instead of a label such as VPI/VCI to identify a VC.  VCID
   is significant only between peer LSRs on the same hierarchical level.

   The value of a VCID is conceptually independent from the value of the
   label or any other datalink specific information of the VC.  The
   length and the range of VCID 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.  This definition
   is different from the one in the MPLS framework document[MPLSFW] and
   MPLS Architecture document[MPLSARC], where a label is defined as an
   identifier of a stream.



Demizu, et al.                                                  [Page 2]


Internet Draft        draft-demizu-mpls-vcid-01.txt         October 1997


   In other words, this document proposes to split the role of a label
   into a VC identifier and an index, and to use them properly.


3. VCID Value

   A VCID value for a VC should be the same 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 VCID value.  It is also easy if
   an input label of a VC at an LSR and the corresponding output label
   of the VC at its peer LSR can be made always the same.

   However, in other cases, peer LSRs have to communicate with each
   other to determine a VCID value for each VC.  The notification can be
   performed by either using an extended LDP, a supplementary protocol,
   or a signaling protocol used by the datalink.  The notification
   methods can be categorized into following three:

       1. Outband Notification
       2. Outband Notification by using a small sized field
       3. Inband Notification

   Brief explanation for each method follows this section.  However, the
   details of this communication procedure depend on each LDP and
   datalink, and is out of the scope of this document.  Note that this
   notification that determines the VCID value does not introduce any
   conflict to current schemes.


3.1. Outband Notification

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

   In this method, a VCID value is notified by using some field of a
   signaling message.  The procedure is the following.

   A node establishes a VC using a signaling message.  It carries a
   label value.  In addition to this, a VCID value is carried in some
   field in the signaling message.  (It depends on datalink which field
   is preferable to carry a VCID value.)  If the signaling succeeds,
   nodes located each end of the VC can share the same VCID value for
   the VC and has a mapping between the VCID and the label.


3.2. Outband Notification by using a small sized field




Demizu, et al.                                                  [Page 3]


Internet Draft        draft-demizu-mpls-vcid-01.txt         October 1997


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

   In this method, at first a temporary identifier of a VC is notified
   by using some field of a signaling message.  Then, the association of
   the temporary identifier and a VCID value is notified by using an LDP
   or a supplementary protocol.  The procedure is the following.

   A node establishes a VC using a signaling message.  It carries a
   label value.  In addition to this, a temporary identifier is carried
   in some field in the signaling message.  (It depends on datalink
   which field is preferable to carry a VCID value.)  If the signaling
   succeeded, nodes located each end of the VC can share the same
   temporary identifier for the VC and has a mapping between the
   temporary identifier and the label.  After that, the nodes exchange a
   mapping between the temporary identifier and a VCID value using an
   LDP message or a supplementary protocol.  Then the nodes can share
   the same VCID value and have a mapping between the VCID and the
   label.


3.3. Inband Notification

   In this method, VCID is notified through an established new VC by
   using a control message of a supplementary protocol.  The procedure
   is following.

   The message contains a VCID value.  It is sent through the VC.  A
   node sending the message has a mapping between the label for the VC
   and the VCID value in the message.  A node receiving the message has
   a mapping between a label for the VC receiving the message and the
   VCID in the message.  Both nodes can share the same VCID value for
   the VC.

   This method works well in a unicast LSP, but causes a problem in a
   multicast LSP and cell based datalink without VC merge switch.  In
   that case, the sender needs to temporarily splice the active LSP 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.  If we use a non-interleaving switching
   fabric for the LSR or flame based datalink, this problem does not
   occur.


Security Considerations

   Security issues are not discussed in this document.



Demizu, et al.                                                  [Page 4]


Internet Draft        draft-demizu-mpls-vcid-01.txt         October 1997


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

[MPLSFW] R. Callon, et al.,
     "A Framework for Multiprotocol Label Switching",
     draft-ietf-mpls-framework-01.txt, Jul 1997
[MPLSARC] E. Rosen, A Viswanathan, R. Callon,
     "A Proposed Architecture for MPLS",
     draft-rosen-mpls-arch-00.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
[INT_LSP] Y. Katsube, H. Esaki,
     "Interoperation Between Distinct Types of Label Switched Paths",
     draft-katsube-interop-between-lsps-00.txt, Jun 1997



Demizu, et al.                                                  [Page 5]


Internet Draft        draft-demizu-mpls-vcid-01.txt         October 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]