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


                                  VC-ID

                        <draft-demizu-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 are proposed to fuse and integrate the
cost-performance and QoS assurance of devices of Layer 2 and the
flexibility and functionality of protocols of Layer 3.

Some of these proposals assume that Label Switching Routers (LSRs) are
placed in a homogeneous LSRs cloud in a campus area network or a
backbone network.  However, this assumption sometimes cannot be
satisfied in the real world.  For example, campuses will be connected
by using carrier's ATM SVC service.  Furthermore, it will be common to
construct LSR networks hierarchically, and some of LSR networks will
use other LSR networks as their underlying networks, which may include
heterogeneous datalinks such as ATM, Ethernet and IEEE 1394.

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


1. Introduction

Several label switching schemes[ARIS][RFC2098][RFC2105][RFC1953] are
proposed to fuse and integrate the cost-performance and QoS assurance
of devices of Layer 2 (L2) and the flexibility and functionality
protocols of Layer 3 (L3).

Some of these proposals assume that Label Switching Routers (LSRs) are
placed in a homogeneous LSRs cloud in a campus area network or a
backbone network.  That is, each LSR is assumed to be connected
directly to other LSRs.  This assumption lead some of proposed label
distribution protocols (LDPs) to assume that Virtual Connections (VCs)
between peer LSRs and their label space exist statically, and an input
label at an ingress node and the corresponding output label at an
egress node of each VC are always the same.

However, in the real world, campuses will be connected by using 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 of LSR networks will use other LSR networks
as their underlying networks[INT_LSP].  In this case, LSRs of higher
levels should use Label Switched Paths (LSPs) traversing among lower
level LSRs, which may obey other schemes.  And 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 those 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 origination point and the corresponding output label at a
termination point are always the same.

To solve this problem, this document proposes a VC-ID.


2. Proposal of VC-ID

To identify a VC between peer LSRs that are separated by L2 switches,
this document proposes to introduce VC identifier called VC-ID to be
used instead of the 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 to 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], where a label is defined as an identifier of a
stream.

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. VC-ID value

VC-ID value for each 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 VC-ID value, as well as in the
case where an input label of a VC at an LSR and the corresponding
output label of the VC at the other LSR can be made always the same.

However, in other cases, peer LSRs have to negotiate VC-ID for each
VC.  The negotiation may be performed by either using an extended LDP,
a supplementary negotiation protocol or a signaling protocol of the
datalink.  The detail of the negotiation procedure depends on each LDP
and underlying networks, and is out of scope of this document.  Note
that VC-ID negotiation does not introduce any conflict to current
schemes.


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 to introduce a VC-ID to identify a VC in any layer of
hierarchy.  Peer LSRs have to negotiate VC-ID for each VC where VC-ID
is necessary.  VC-ID idea does not conflict with current schemes.


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 acknowledge Paul Doolan.


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
[RFC2098] Y. Katsube, et. al.,
	"Toshiba's Router Architecture Extensions for ATM : Overview",
	RFC2098, Feb 1997
[RFC2105] Y. Rekhter, et. al.,
	 "Cisco Systems' Tag Switching Architecture Overview",
	RFC2105, Feb 1997
[RFC1953] P. W. Edwards, et. al.,
	"Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0",
	RFC1953, May 1996
[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


Author 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