Internet Draft 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]