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]