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]