idnits 2.17.1 draft-ietf-ccamp-rsvp-te-bandwidth-availability-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2016) is 2987 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) == Missing Reference: 'RFC2119' is mentioned on line 84, but not defined == Missing Reference: 'RFC2205' is mentioned on line 249, but not defined == Missing Reference: 'This ID' is mentioned on line 276, but not defined == Unused Reference: 'G.827' is defined on line 295, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Long, M. Ye 2 Internet Draft Huawei Technologies Co., Ltd 3 Intended status: Standards Track G. Mirsky 4 Ericsson 5 A.D'Alessandro 6 Telecom Italia S.p.A 7 H. Shah 8 Ciena 9 Expires: August 2016 February 19, 2016 11 Ethernet Traffic Parameters with Availability Information 12 draft-ietf-ccamp-rsvp-te-bandwidth-availability-04.txt 14 Abstract 16 A Packet switching network may contain links with variable bandwidth, 17 e.g., copper, radio, etc. The bandwidth of such links is sensitive 18 to external environment. Availability is typically used for 19 describing the link during network planning. This document 20 introduces an optional Availability TLV in Resource ReSerVation 21 Protocol -- Traffic Engineer (RSVP-TE) signaling. This extension can 22 be used to set up a label switching path (LSP) in a Packet Switched 23 Network (PSN) that contains links with discretely variable bandwidth. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on August 19, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction ................................................ 3 66 2. Overview .................................................... 4 67 3. Extension to RSVP-TE Signaling............................... 4 68 3.1. Availability TLV........................................ 4 69 3.2. Signaling Process....................................... 5 70 4. Security Considerations...................................... 6 71 5. IANA Considerations ......................................... 6 72 5.1 Ethernet Sender TSpec TLVs ............................. 6 73 6. References .................................................. 7 74 6.1. Normative References.................................... 7 75 6.2. Informative References.................................. 7 76 7. Appendix: Bandwidth Availability Example..................... 8 77 8. Acknowledgments ............................................. 9 79 Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC-2119 [RFC2119]. 85 The following acronyms are used in this draft: 87 RSVP-TE Resource Reservation Protocol-Traffic Engineering 89 LSP Label Switched Path 91 PSN Packet Switched Network 93 SNR Signal-to-noise Ratio 94 TLV Type Length Value 96 LSA Link State Advertisement 98 1. Introduction 100 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] 101 specify the signaling message including the bandwidth request for 102 setting up a label switching path in a PSN network. 104 Some data communication technologies allow seamless change of 105 maximum physical bandwidth through a set of known discrete values. 106 The parameter availability [G.827, F.1703, P.530] is often used to 107 describe the link capacity during network planning. The availability 108 is a time scale that the requested bandwidth is ensured. A more 109 detailed example on the bandwidth availability can be found in 110 Appendix A. Assigning different availability classes to different 111 types of service over such kind of links provides more efficient 112 planning of link capacity. To set up an LSP across these links, 113 availability information is required for the nodes to verify 114 bandwidth satisfaction and make bandwidth reservation. The 115 availability information should be inherited from the availability 116 requirements of the services expected to be carried on the LSP. For 117 example, voice service usually needs ''five nines'' availability, 118 while non-real time services may adequately perform at four or three 119 nines availability. Since different service types may need different 120 availabilities guarantees, multiple pairs 121 may be required when signaling. 123 If the availability requirement is not specified in the signaling 124 message, the bandwidth will be reserved as the highest availability. 125 For example, the bandwidth with 99.999% availability of a link is 126 100 Mbps; the bandwidth with 99.99% availability is 200 Mbps. When a 127 video application requests for 120 Mbps without availability 128 requirement, the system will consider the request as 120 Mbps with 129 99.999% availability, while the available bandwidth with 99.999% 130 availability is only 100 Mbps, therefore the LSP path cannot be set 131 up. But in fact, video application doesn't need 99.999% availability; 132 99.99% availability is enough. In this case, the LSP could be set up 133 if availability is specified in the signaling message. 135 To fulfill LSP setup by signaling in these scenarios, this document 136 specifies an Availability TLV. The Availability TLV can be 137 applicable to any kind of physical links with variable discrete 138 bandwidth, such as microwave or DSL. Multiple Availability TLVs 139 together with multiple Ethernet Bandwidth Profiles can be carried in 140 the Ethernet SENDER_TSPEC object. 142 2. Overview 144 A PSN tunnel may span one or more links in a network. To setup a 145 label switching path (LSP), a node may collect link information 146 which is spread in routing message, e.g., OSPF TE LSA message, by 147 network nodes to get to know about the network topology, and 148 calculate out an LSP route based on the network topology, and send 149 the calculated LSP route to signaling to initiate a PATH/RESV 150 message for setting up the LSP. 152 In case that there is(are) link(s) with variable discrete bandwidth 153 in a network, a requirement list should be 154 specified for an LSP. Each pair in the 155 list means that listed bandwidth with specified availability is 156 required. The list could be inherited from the results of service 157 planning for the LSP. 159 A node which has link(s) with variable discrete bandwidth attached 160 should contain a information list in its 161 OSPF TE LSA messages. The list provides the information that how 162 much bandwidth a link can support for a specified availability. This 163 information is used for path calculation by the node(s). The routing 164 extension for availability can be found in [ARTE]. 166 When a node initiates a PATH/RESV signaling to set up an LSP, the 167 PATH message should carry the requirement 168 list as bandwidth request. Intermediate node(s) will allocate the 169 bandwidth resource for each availability requirement from the 170 remaining bandwidth with corresponding availability. An error 171 message may be returned if any request 172 cannot be satisfied. 174 3. Extension to RSVP-TE Signaling 176 3.1. Availability TLV 178 An Availability TLV is defined as a TLV of the Ethernet 179 SENDEDR_TSPEC object [RFC6003] in this document. The Ethernet 180 SENDER_TSPEC object MAY include more than one Availability TLV. The 181 Availability TLV has the following format: 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Index | Reserved | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Availability | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: Availability TLV 193 Index (1 octet): 195 The Availability TLV MUST come along with Ethernet Bandwidth 196 Profile TLV. If the bandwidth requirements in the multiple 197 Ethernet Bandwidth Profile TLVs have different Availability 198 requirements, multiple Availability TLVs SHOULD be carried. In 199 such a case, the Availability TLV has one to one correspondence 200 with Ethernet Bandwidth Profile TLV by having the same value of 201 Index field. If all the bandwidth requirements in the Ethernet 202 Bandwidth Profile have the same Availability requirement, one 203 Availability TLV SHOULD be carried. In this case, the Index field 204 is set to 0. 206 Reserved (3 octets): These bits SHOULD be set to zero when sent 207 and MUST be ignored when received. 209 Availability (4 octets): a 32-bit floating number describes the 210 decimal value of availability requirement for this bandwidth 211 request. The value MUST be less than 1. 213 3.2. Signaling Process 215 The source node initiates PATH messages which carry a number of 216 bandwidth request information, including one or more Ethernet 217 Bandwidth Profile TLVs and one or more Availability TLVs. Each 218 Ethernet Bandwidth Profile TLV corresponds to an availability 219 parameter in the Availability TLV. 221 The intermediate and destination nodes check whether they can 222 satisfy the bandwidth requirements by comparing each bandwidth 223 requirement inside the SENDER_TSPEC objects with the remaining link 224 sub-bandwidth resource with respective availability guarantee on the 225 local link when received the PATH message. 227 o If all requirements can be 228 satisfied (the requested bandwidth under each availability 229 parameter is smaller than or equal to the remaining bandwidth 230 under the corresponding availability parameter on its local 231 link), it SHOULD reserve the bandwidth resource from each 232 remaining sub-bandwidth portion on its local link to set up 233 this LSP. Optionally, the higher availability bandwidth can be 234 allocated to lower availability request when the lower 235 availability bandwidth cannot satisfy the request. 237 o If at least one requirement cannot 238 be satisfied, it SHOULD generate PathErr message with the error 239 code "Admission Control Error" and the error value "Requested 240 Bandwidth Unavailable" (see [RFC2205]). 242 If two LSPs request for the bandwidth with the same availability 243 requirement, a way to resolve the contention is comparing the node 244 ID, the node with the higher node ID will win the contention. More 245 details can be found in [RFC3473]. 247 If a node does not support Availability TLV, it SHOULD generate 248 PathErr message with the error code "Extended Class-Type Error" and 249 the error value "Class-Type mismatch" (see [RFC2205]). 251 4. Security Considerations 253 This document does not introduce new security considerations to the 254 existing RSVP-TE signaling protocol. 256 5. IANA Considerations 258 IANA maintains registries and sub-registries for RSVP-TE used by 259 GMPLS. IANA is requested to make allocations from these registries 260 as set out in the following sections. 262 5.1 Ethernet Sender TSpec TLVs 264 IANA maintains a registry of GMPLS parameters called ''Generalized 265 Multi-Protocol Label Switching (GMPLS) Signaling Parameters''. 267 IANA has created a new sub-registry called ''Ethernet Sender TSpec 268 TLVs / Ethernet Flowspec TLVs'' to contain the TLV type values for 269 TLVs carried in the Ethernet SENDER_TSPEC object. A new type for 270 Availability TLV is defined as follow: 272 Type Description Reference 274 ----- ----------------------------------- --------- 276 TBD Availability [This ID] 278 6. References 280 6.1. Normative References 282 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 283 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 284 Tunnels", RFC 3209, December 2001. 286 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 287 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 288 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 290 [RFC6003] Papadimitriou, D. ''Ethernet Traffic Parameters'', RFC 6003, 291 October 2010. 293 6.2. Informative References 295 [G.827] ITU-T Recommendation, ''Availability performance parameters 296 and objectives for end-to-end international constant bit- 297 rate digital paths'', September, 2003. 299 [F.1703] ITU-R Recommendation, ''Availability objectives for real 300 digital fixed wireless links used in 27 500 km 301 hypothetical reference paths and connections'', January, 302 2005. 304 [P.530] ITU-R Recommendation,'' Propagation data and prediction 305 methods required for the design of terrestrial line-of- 306 sight systems'', February, 2012 308 [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics 309 and requirements for point-to-point equipment and 310 antennas'', April, 2009 312 [ARTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 313 ''OSPF Routing Extension for Links with Variable Discrete 314 Bandwidth'', Work in Progress, June, 2015 316 7. Appendix: Bandwidth Availability Example 318 In mobile backhaul network, microwave links are very popular for 319 providing connection of last hops. In case of heavy rain, to 320 maintain the link connectivity, the microwave link MAY lower the 321 modulation level since demodulating the lower modulation level needs 322 a lower Signal-to-Noise Ratio (SNR). This is called adaptive 323 modulation technology [EN 302 217]. However, a lower modulation 324 level also means lower link bandwidth. When link bandwidth is 325 reduced because of modulation down-shifting, high-priority traffic 326 can be maintained, while lower-priority traffic is dropped. 327 Similarly, the copper links MAY change their link bandwidth due to 328 external interference. 330 Presuming that a link has three discrete bandwidth levels: 332 The link bandwidth under modulation level 1, e.g., QPSK, is 100 Mbps; 334 The link bandwidth under modulation level 2, e.g., 16QAM, is 200 335 Mbps; 337 The link bandwidth under modulation level 3, e.g., 256QAM, is 400 338 Mbps. 340 In sunny day, the modulation level 3 can be used to achieve 400 Mbps 341 link bandwidth. 343 A light rain with X mm/h rate triggers the system to change the 344 modulation level from level 3 to level 2, with bandwidth changing 345 from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the 346 local area is 52 minutes in a year. Then the dropped 200 Mbps 347 bandwidth has 99.99% availability. 349 A heavy rain with Y(Y>X) mm/h rate triggers the system to change the 350 modulation level from level 2 to level 1, with bandwidth changing 351 from 200 Mbps to 100 Mbps. The probability of Y mm/h rain in the 352 local area is 26 minutes in a year. Then the dropped 100 Mbps 353 bandwidth has 99.995% availability. 355 For the 100M bandwidth of the modulation level 1, only the extreme 356 weather condition can cause the whole system unavailable, which only 357 happens for 5 minutes in a year. So the 100 Mbps bandwidth of the 358 modulation level 1 owns the availability of 99.999%. 360 In a word, the maximum bandwidth is 400 Mbps. According to the 361 weather condition, the sub-bandwidth and its availability are shown 362 as follows: 364 Sub-bandwidth(Mbps) Availability 366 ------------------ ------------ 368 200 99.99% 370 100 99.995% 372 100 99.999% 374 8. Acknowledgments 376 The authors would like to thank Khuzema Pithewan, Lou Berger, Yuji 377 Tochio, Dieter Beller, and Autumn Liu for their comments on the 378 document. 380 Authors' Addresses 381 Hao Long 382 Huawei Technologies Co., Ltd. 383 No.1899, Xiyuan Avenue, Hi-tech Western District 384 Chengdu 611731, P.R.China 386 Phone: +86-18615778750 387 Email: longhao@huawei.com 389 Min Ye (editor) 390 Huawei Technologies Co., Ltd. 391 No.1899, Xiyuan Avenue, Hi-tech Western District 392 Chengdu 611731, P.R.China 394 Email: amy.yemin@huawei.com 396 Greg Mirsky (editor) 397 Ericsson 399 Email: gregory.mirsky@ericsson.com 401 Alessandro D'Alessandro 402 Telecom Italia S.p.A 404 Email: alessandro.dalessandro@telecomitalia.it 406 Himanshu Shah 407 Ciena Corp. 408 3939 North First Street 409 San Jose, CA 95134 410 US 412 Email: hshah@ciena.com