idnits 2.17.1 draft-demizu-mpls-vcpool-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1997) is 9690 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'VCID' is defined on line 186, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ARIS' ** Downref: Normative reference to an Informational RFC: RFC 2098 ** Downref: Normative reference to an Informational RFC: RFC 1953 ** Downref: Normative reference to an Informational RFC: RFC 2105 -- Possible downref: Normative reference to a draft: ref. 'VCID' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Noritoshi Demizu (SonyCSL Inc.) 2 Internet Draft Ken-ichi Nagami (Toshiba Corp.) 3 Expiration Date: April 1998 Paul Doolan (Cisco Systems Inc.) 4 Hiroshi Esaki (Toshiba Corp.) 5 October 1997 7 VC Pool 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 Several label switching schemes have been proposed to fuse and 32 integrate Layer 2 and Layer 3. They can be applied to various 33 datalinks including intermittent links such as ATM SVC. 35 Intermittent links require signaling to establish VCs before 36 employing them and to release VCs after utilizing them. Because 37 signaling often introduces delays and costs, some kind of 38 optimization is necessary. 40 This document proposes to introduce a VC pool to reduce the delays 41 and the costs of signaling. 43 1. Introduction 45 Several label switching schemes[ARIS][RFC2098][RFC1953][RFC2105] have 46 been proposed to fuse and integrate the cost-performance and QoS 47 assurance of Layer 2 devices and the flexibility and functionality of 48 Layer 3 protocols. 50 These label switching schemes can be applied to various datalinks 51 including intermittent links such as ATM SVC. Intermittent links 52 require signaling to establish Virtual Connections (VCs) before 53 employing them and to release VCs after utilizing them. Because 54 signaling often takes long time and carriers may charge each VC 55 establishment, connection time and/or the amount of traffic, some 56 kind of optimization is necessary to reduce the delays and the costs 57 of signaling. 59 This document proposes to introduce a VC pool to reduce them. 61 2. Proposal of VC pool 63 A VC pool is where a number of established VCs is prepared a priori. 64 VCs can be picked immediately from the VC pool on BIND procedures and 65 will be put back to the VC pool on UNBIND procedures. So, VCs can be 66 recycled without unnecessary signaling. If there are too many VCs in 67 a VC pool, some of them may be released to reduce the costs to 68 maintain these VCs. 70 Each established VC in a VC pool should be associated with a VCID, 71 because it is sometimes impossible to use datalink specific 72 information as an identifier for a VC in a VC pool due to its small 73 range. For example, the BLLI field of ATM Forum Signaling cannot be 74 used to distinguish more than 128 VCs. However, the association 75 between a VC and a VCID can be postponed until the VC will be used if 76 protocol optimization is necessary. 78 A Label Switching Router (LSR) may have multiple VC pools for each VC 79 class. Examples of VC classes are UBR VCs, CBR VCs, point-to- 80 multipoint VCs, etc. 82 The advantages of VC pool are: 84 - It is possible to reduce delays and costs of signaling. 85 - It hides the details of signaling procedures of each datalink from 86 Label Distribution Protocols (LDPs). 87 - It becomes easy to use both directions of bi-directional VCs such 88 as ATM SVC with a VC pool, because each direction of a VC can be 89 used independently. 91 Note that the idea of VC pool does not conflict with current 92 implementations that do not have a VC pool, because they can be 93 considered to have a special case of VC pool, where all VCs are 94 prepared a priori and there is no need to establish VCs nor to 95 release VCs. Also note that VC pool can be applied to intermittent 96 datalinks other than ATM. 98 3. Parameters of VC Pool 100 A VC pool might have the following parameters: 102 Low water mark: 103 - At least this number of VCs should be prepared in the VC pool. 104 High water mark: 105 - If the number of VCs in the pool exceeds this number, excess 106 VCs should be released under the constraint of the hold time 107 parameter. 108 Hold time: 109 - It is required to wait for at least hold time seconds before 110 releasing VCs after its use. Releasing can be postponed 111 until just before next charging time. 112 Limit: 113 - The total number of established VCs, including both those in 114 the VC pool and those in use, must not exceed this number. 115 Arrary consisting of Min and Max VCID pairs: 116 - Each Min and Max VCID pair specifies a usable VCID range. 117 Thus, the union of the members given in this array specifies 118 the entire range of usable VCIDs. 120 4. Examples of Parameters 122 Parameters of a VC pool should be carefully chosen to reduce delays 123 and costs case by case, by considering various characteristics of 124 datalinks, binding schemes, tariff, etc. Bellow are some example 125 cases. 127 Case 1: ATM SVC with a traffic-driven scheme: 128 - All VCs are UBR 129 - Low_water = 5, High_water = 20, Hold_time = several seconds 130 - Min, Max, Limit are given 131 (Effective if signaling takes long time or signaling is expensive) 133 Case 2: ATM SVC with a topology-driven scheme: 134 - All VCs are UBR 135 - Low_water = 0, High_water = 0, Hold_time = several seconds 136 - Min, Max, Limit are given. 137 (Effective if signaling takes long time or signaling is 138 expensive, especially when topology changes) 140 Case 3: When it is difficult to recycle VCs, for instance, VCs with 141 reserved resources or point-to-multipoint VCs: 142 - Low_water = 0, High_water = 0, Hold_time = several seconds 143 - Min, Max, Limit are given 145 Case 4: ATM VP or PVC: 146 - Low_water = High_water = Limit = the number of available VCs 147 - Hold_time = 0 148 - Min, Max are given. 149 (VC pool need not be implemented for this case.) 151 Note that case 4 is the same as current implementations that do not 152 incorporate a VC pool. 154 Security Considerations 156 Security issues are not discussed in this document. 158 Intellectual Property Considerations 160 Toshiba Corporation may seek patent or other intellectual property 161 protection for some of the aspects of the technology discussed in 162 this document. If any standards arising from this document are or 163 become protected by one or more patents assigned to Toshiba 164 Corporation, Toshiba intends to license them on reasonable and non- 165 discriminatory terms. 167 Acknowledgments 169 The authors would like to acknowledge valuable technical comments 170 from members of LAST-WG of WIDE Project. 172 References 174 [ARIS] A. Viswanathan, et al., 175 "ARIS: Aggregate Route-Based IP Switching", 176 draft-viswanathan-aris-overview-00.txt, Mar 1997 177 [RFC2098] Y. Katsube, et al., 178 "Toshiba's Router Architecture Extensions for ATM : Overview", 179 RFC2098, Feb 1997 180 [RFC1953] P. W. Edwards, et al., 181 "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", 182 RFC1953, May 1996 183 [RFC2105] Y. Rekhter, et al., 184 "Cisco Systems' Tag Switching Architecture Overview", 185 RFC2105, Feb 1997 186 [VCID] N. Demizu, et al., 187 "VCID: Virtual Connection Identifier", 188 draft-demizu-mpls-vcid-01.txt, Oct 1997 190 Authors Information 192 Noritoshi Demizu 193 Sony Computer Science Laboratory, Inc. 194 Takanawa Muse Bldg. 195 3-14-13, Higashigotanda, 196 Shinagawa-ku, Tokyo, 141 Japan 197 Phone: +81-3-5448-4380 198 E-mail: demizu@csl.sony.co.jp 199 E-mail: nori-d@is.aist-nara.ac.jp 201 Ken-ichi Nagami 202 R&D Center, Toshiba Corporation, 203 1 Komukai-Toshiba-cho, Saiwai-ku, 204 Kawasaki, 210, Japan 205 Email: nagami@isl.rdc.toshiba.co.jp 207 Paul Doolan 208 cisco Systems, Inc. 209 250 Apollo Drive. 210 Chelmsford, MA 01824, USA 211 Phone: +1-508-244-8917 212 email: pdoolan@cisco.com 214 Hiroshi Esaki 215 Computer and Network Division, 216 Toshiba Corporation, 217 1-1-1 Shibaura, 218 Minato-ku, 105-01, Japan 219 Email: hiroshi@isl.rdc.toshiba.co.jp