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
VC Pool
<draft-demizu-mpls-vcpool-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 Layer 2 and Layer 3. They can be applied to various
datalinks including intermittent links such as ATM SVC.
Intermittent links require signaling to establish VCs before
employing them and to release VCs after utilizing them. Because
signaling often introduces delays and costs, some kind of
optimization is necessary.
This document proposes to introduce a VC pool to reduce the delays
and the costs of signaling.
1. Introduction
Several label switching schemes[ARIS][RFC2098][RFC1953][RFC2105] have
Demizu, et al. [Page 1]
Internet Draft draft-demizu-mpls-vcpool-00.txt October 1997
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.
These label switching schemes can be applied to various datalinks
including intermittent links such as ATM SVC. Intermittent links
require signaling to establish Virtual Connections (VCs) before
employing them and to release VCs after utilizing them. Because
signaling often takes 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.
This document proposes to introduce a VC pool to reduce them.
2. Proposal of VC pool
A VC pool is where a number of established 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 VCID,
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. For example, the BLLI field of ATM Forum Signaling cannot be
used to distinguish more than 128 VCs. However, the association
between a VC and a VCID can be postponed until the VC will be used if
protocol optimization is necessary.
A Label Switching Router (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:
- It is possible to reduce delays and costs of signaling.
- It hides the details of signaling procedures of each datalink from
Label Distribution Protocols (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
Demizu, et al. [Page 2]
Internet Draft draft-demizu-mpls-vcpool-00.txt October 1997
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.
3. Parameters of VC Pool
A VC pool might have the following parameters:
Low water mark:
- At least this number of VCs should be prepared in the VC pool.
High water mark:
- If the number of VCs in the pool exceeds this number, excess
VCs should be released under the constraint of the hold time
parameter.
Hold time:
- It is required to wait for at least hold time seconds before
releasing VCs after its use. Releasing can be postponed
until just before next charging time.
Limit:
- The total number of established VCs, including both those in
the VC pool and those in use, must not exceed this number.
Arrary consisting of Min and Max VCID pairs:
- Each Min and Max VCID pair specifies a usable VCID range.
Thus, the union of the members given in this array specifies
the entire range of usable VCIDs.
4. Examples of Parameters
Parameters of a VC pool should be carefully chosen to reduce delays
and costs case by case, by considering various characteristics of
datalinks, binding schemes, tariff, etc. Bellow are some example
cases.
Case 1: ATM SVC with a traffic-driven scheme:
- All VCs are UBR
- Low_water = 5, High_water = 20, Hold_time = several seconds
- Min, Max, Limit are given
(Effective if signaling takes long time or signaling is expensive)
Case 2: ATM SVC with a topology-driven scheme:
- All VCs are UBR
- Low_water = 0, High_water = 0, Hold_time = several seconds
- Min, Max, Limit are given.
(Effective if signaling takes long time or signaling is
expensive, especially when topology changes)
Demizu, et al. [Page 3]
Internet Draft draft-demizu-mpls-vcpool-00.txt October 1997
Case 3: When it is difficult to recycle VCs, for instance, VCs with
reserved resources or point-to-multipoint VCs:
- Low_water = 0, High_water = 0, Hold_time = several seconds
- Min, Max, Limit are given
Case 4: ATM VP or PVC:
- Low_water = High_water = Limit = the number of available VCs
- Hold_time = 0
- Min, Max are given.
(VC pool need not be implemented for this case.)
Note that case 4 is the same as current implementations that do not
incorporate a VC pool.
Security Considerations
Security issues are not discussed in this document.
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
[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
[RFC1953] P. W. Edwards, et al.,
"Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0",
RFC1953, May 1996
[RFC2105] Y. Rekhter, et al.,
Demizu, et al. [Page 4]
Internet Draft draft-demizu-mpls-vcpool-00.txt October 1997
"Cisco Systems' Tag Switching Architecture Overview",
RFC2105, Feb 1997
[VCID] N. Demizu, et al.,
"VCID: Virtual Connection Identifier",
draft-demizu-mpls-vcid-01.txt, Oct 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 5]