idnits 2.17.1 draft-ietf-ccamp-rsvp-te-bandwidth-availability-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2015) is 3341 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 88, but not defined == Missing Reference: 'RFC2205' is mentioned on line 306, but not defined == Missing Reference: 'This ID' is mentioned on line 352, but not defined == Unused Reference: 'RFC2210' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 406, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.827' -- Possible downref: Non-RFC (?) normative reference: ref. 'ARTE' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). 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: September 2015 March 4, 2015 11 RSVP-TE Signaling Extension for Links with Variable Discrete 12 Bandwidth 13 draft-ietf-ccamp-rsvp-te-bandwidth-availability-01.txt 15 Abstract 17 A Packet switching network MAY contain links with variable bandwidth, 18 e.g., copper, radio, etc. The bandwidth of such linkS is sensitive 19 to external environment. Availability is typically used for 20 describing the link during network planning. This document 21 introduces an Extended Ethernet Bandwidth Profile TLV and an 22 OPTIONAL Availability sub-TLV in RSVP-TE signaling. This extension 23 can be used to set up a label switching path (LSP) in a Packet 24 Switched Network (PSN) that contains links with discretely variable 25 bandwidth. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on September 6, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction ................................................ 3 67 2. Overview .................................................... 4 68 3. Extension to RSVP-TE Signaling............................... 5 69 3.1.1. Extended Ethernet Bandwidth Profile TLV............ 5 70 3.1.2. Availability sub-TLV............................... 6 71 3.2. FLOWSPEC Object......................................... 6 72 3.3. Signaling Process....................................... 6 73 4. Security Considerations...................................... 7 74 5. IANA Considerations ......................................... 7 75 5.1 Ethernet Sender TSpec TLVs ............................. 7 76 5.2 Extended Ethernet Bandwidth Profile TLV ................ 8 77 6. References .................................................. 8 78 6.1. Normative References.................................... 8 79 6.2. Informative References.................................. 9 80 7. Appendix: Bandwidth Availability Example..................... 9 81 8. Acknowledgments ............................................ 10 83 Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [RFC2119]. 89 The following acronyms are used in this draft: 91 RSVP-TE Resource Reservation Protocol-Traffic Engineering 93 LSP Label Switched Path 94 PSN Packet Switched Network 96 SNR Signal-to-noise Ratio 98 TLV Type Length Value 100 PE Provider Edge 102 LSA Link State Advertisement 104 1. Introduction 106 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] 107 specify the signaling message including the bandwidth request for 108 setting up a label switching path in a PSN network. 110 Some data communication technologies allow seamless change of 111 maximum physical bandwidth through a set of known discrete values. 112 For example, in mobile backhaul network, microwave links are very 113 popular for providing connection of last hops. In case of heavy rain, 114 to maintain the link connectivity, the microwave link MAY lower the 115 modulation level since demodulating the lower modulation level needs 116 a lower Signal-to-Noise Ratio (SNR). This is called adaptive 117 modulation technology [EN 302 217]. However, a lower modulation 118 level also means lower link bandwidth. When link bandwidth is 119 reduced because of modulation down-shifting, high-priority traffic 120 can be maintained, while lower-priority traffic is dropped. 121 Similarly, the copper links MAY change their link bandwidth due to 122 external interference. 124 The parameter availability [G.827, F.1703, P.530] is often used to 125 describe the link capacity during network planning. A more detailed 126 example on the bandwidth availability can be found in Appendix A. 127 Assigning different availability classes to different types of 128 service over such kind of links provides more efficient planning of 129 link capacity. To set up an LSP across these links, availability 130 information is required for the nodes to verify bandwidth 131 satisfaction and make bandwidth reservation. The availability 132 information SHOULD be inherited from the availability requirements 133 of the services expected to be carried on the LSP. For example, 134 voice service usually needs "five nines" availability, while non- 135 real time services MAY adequately perform at four or three nines 136 availability. Since different service types MAY need different 137 availabilities guarantees, multiple pairs 138 MAY be required when signaling. 140 If the availability requirement is not specified in the signaling 141 message, the bandwidth will be reserved as the highest availability. 142 For example, the bandwidth with 99.999% availability of a link is 143 100 Mbps; the bandwidth with 99.99% availability is 200 Mbps. When a 144 video application requests for 120 Mbps without availability 145 requirement, the system will consider the request as 120 Mbps with 146 99.999% availability, while the available bandwidth with 99.999% 147 availability is only 100 Mbps, therefore the LSP path cannot be set 148 up. But in fact, video application doesn't need 99.999% availability; 149 99.99% availability is enough. In this case, the LSP could be set up 150 if availability is specified in the signaling message. 152 To fulfill LSP setup by signaling in these scenarios, this document 153 specifies an Extended Ethernet Bandwidth Profile and an Availability 154 sub-TLV. The Availability sub-TLV can be applicable to any kind of 155 physical links with variable discrete bandwidth, such as microwave 156 or DSL. Multiple Extended Ethernet Bandwidth Profiles with different 157 availability can be carried in the Ethernet SENDER_TSPEC object. 159 2. Overview 161 A PSN tunnel MAY span one or more links in a network. To setup a 162 label switching path (LSP), a PE node MAY collect link information 163 which is spread in routing message, e.g., OSPF TE LSA message, by 164 network nodes to get to know about the network topology, and 165 calculate out an LSP route based on the network topology, and send 166 the calculated LSP route to signaling to initiate a PATH/RESV 167 message for setting up the LSP. 169 In case that there is(are) link(s) with variable discrete bandwidth 170 in a network, a requirement list SHOULD be 171 specified for an LSP. Each pair in the 172 list means that listed bandwidth with specified availability is 173 required. The list could be inherited from the results of service 174 planning for the LSP. 176 A node which has link(s) with variable discrete bandwidth attached 177 SHOULD contain a information list in its 178 OSPF TE LSA messages. The list provides the information that how 179 much bandwidth a link can support for a specified availability. This 180 information is used for path calculation by the PE node(s). The 181 routing extension for availability can be found in [ARTE]. 183 When a PE node initiates a PATH/RESV signaling to set up an LSP, the 184 PATH message SHOULD carry the requirement 185 list as bandwidth request. Intermediate node(s) will allocate the 186 bandwidth resource for each availability requirement from the 187 remaining bandwidth with corresponding availability. An error 188 message MAY be returned if any request 189 cannot be satisfied. 191 3. Extension to RSVP-TE Signaling 193 The initial idea is to define an Availability sub-TLV under Ethernet 194 Bandwidth Profile TLV [RFC6003]. However the Ethernet Bandwidth 195 Profile TLV doesn't have the ability to carry a sub-TLV according to 196 RFC6003. Therefore, an Extend Ethernet Bandwidth Profile TLV is 197 defined in this document to avoid the backward compatibility issue. 198 The Extended Ethernet Bandwidth Profile TLV includes Ethernet BW TLV 199 and has variable length. It MAY include Availability sub-TLV which 200 is also defined in this document. 202 3.1.1. Extended Ethernet Bandwidth Profile TLV 204 The Extended Ethernet Bandwidth Profile TLV is included in the 205 Ethernet SENDER_TSPEC, and MAY be included for more than one time. 206 The Extended Ethernet Bandwidth Profile TLV has the following format. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |Pro|A| | Index | Reserved | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | CIR | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | CBS | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | EIR | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | EBS | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | sub-TLV(OPTIONAL) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 1: A new "AF" filed in Extended Ethernet Bandwidth Profile TLV 228 The difference between the Extended Ethernet Bandwidth Profile TLV 229 and Ethernet Bandwidth Profile TLV is that a new AF field to 230 indicate the sub-TLV is defined in the Extended Ethernet Bandwidth 231 Profile TLV. The rest definitions are the same. 233 A new filed is defined in this document: 235 AF filed (bit 2): Availability Field (AF) 237 If the AF filed is set to 1, Availability sub-TLV MUST be included 238 in the Extended Ethernet Bandwidth Profile TLV. If the AF field is 239 set to value 0, then an Availability sub-TLV SHOULD NOT be included. 241 3.1.2. Availability sub-TLV 243 The Availability sub-TLV has the following format: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Availability | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2: Availability sub-TLV 255 Type (2 octets): TBD 257 Length (2 octets): 4 259 Availability (4 octets): a 32-bit floating number describes the 260 decimal value of availability requirement for this bandwidth 261 request. The value MUST be less than 1. 263 As the Extended Ethernet Bandwidth Profile TLV can be carried for 264 one or more times in the Ethernet SENDER_TSPEC object, the 265 Availability sub-TLV can also be present for one or more times. 267 3.2. FLOWSPEC Object 269 The FLOWSPEC object (Class-Num = 9, Class-Type = TBD) has the same 270 format as the Ethernet SENDER_TSPEC object. 272 3.3. Signaling Process 274 The source node initiates PATH messages including one or more 275 Extended Bandwidth Profile TLVs with different availability values 276 in the SENDER_TSPEC object. Each Extended Bandwidth Profile TLV 277 specifies the portion of the bandwidth request with referred 278 availability requirement. 280 The intermediate and destination nodes check whether they can 281 satisfy the bandwidth requirements by comparing each bandwidth 282 requirement inside the SENDER_TSPEC objects with the remaining link 283 sub-bandwidth resource with respective availability guarantee when 284 received the PATH message. 286 o If all requirements can be 287 satisfied, it SHOULD reserve the bandwidth resource from each 288 remaining sub-bandwidth portion to set up this LSP. Optionally, 289 the higher availability bandwidth can be allocated to lower 290 availability request when the lower availability bandwidth 291 cannot satisfy the request. 293 o If at least one requirement cannot 294 be satisfied, it SHOULD generate PathErr message with the error 295 code "Admission Control Error" and the error value "Requested 296 Bandwidth Unavailable" (see [RFC2205]). 298 If two LSPs request for the bandwidth with the same availability 299 requirement, a way to resolve the contention is comparing the node 300 ID, the node with the higher node ID will win the contention. More 301 details can be found in [RFC3473]. 303 If a node does not support the Extended Bandwidth Profile TLV and 304 Availability sub-TLV, it SHOULD generate PathErr message with the 305 error code "Extended Class-Type Error" and the error value "Class- 306 Type mismatch" (see [RFC2205]). 308 4. Security Considerations 310 This document does not introduce new security considerations to the 311 existing RSVP-TE signaling protocol. 313 5. IANA Considerations 315 IANA maintains registries and sub-registries for RSVP-TE used by 316 GMPLS. IANA is requested to make allocations from these registries 317 as set out in the following sections. 319 5.1 Ethernet Sender TSpec TLVs 321 IANA maintains a registry of GMPLS parameters called "Generalized 322 Multi-Protocol Label Switching (GMPLS) Signaling Parameters". 324 IANA has created a new sub-registry called "Ethernet Sender TSpec 325 TLVs / Ethernet Flowspec TLVs" to contain the TLV type values for 326 TLVs carried in the Ethernet SENDER_TSPEC object. A new value is as 327 follow: 329 Type Description Reference 331 ----- ----------------------------------- --------- 333 TBD Extended Ethernet Bandwidth Profile [This ID] 335 5.2 Extended Ethernet Bandwidth Profile TLV 337 IANA has created a new sub-registry called "Extended Ethernet 338 Bandwidth Profiles" to contain bit flags carried in the Extended 339 Ethernet Bandwidth Profile TLV of the Ethernet SENDER_TSPEC object. 341 Bits are to be allocated by Standards Action. Bits are numbered from 342 bit 0 as the low order bit. A new bit field is as follow: 344 Bit Hex Description Reference 346 --- ---- ------------------ ----------- 348 0 0x01 Coupling Flag (CF) [RFC6003] 350 1 0x02 Color Mode (CM) [RFC6003] 352 2 0x04 Availability Field (AF) [This ID] 354 Sub-TLV types for Extended Ethernet Bandwidth Profiles are to be 355 allocated by Standards Action. Initial values are as follows: 357 Type Length Format Description 359 --- ---- ------------------ ----------- 361 0 - Reserved Reserved value 363 0x01 4 see Section 3.1.2 of this ID Availability 365 6. References 367 6.1. Normative References 369 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 370 Services", RFC 2210, September 1997. 372 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 373 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 374 Tunnels", RFC 3209, December 2001. 376 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 377 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 378 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 380 [RFC6003] Papadimitriou, D. "Ethernet Traffic Parameters", RFC 6003, 381 October 2010. 383 [G.827] ITU-T Recommendation, "Availability performance parameters 384 and objectives for end-to-end international constant bit- 385 rate digital paths", September, 2003. 387 [F.1703] ITU-R Recommendation, "Availability objectives for real 388 digital fixed wireless links used in 27 500 km 389 hypothetical reference paths and connections", January, 390 2005. 392 [P.530] ITU-R Recommendation," Propagation data and prediction 393 methods required for the design of terrestrial line-of- 394 sight systems", February, 2012 396 [EN 302 217] ETSI standard, "Fixed Radio Systems; Characteristics 397 and requirements for point-to-point equipment and 398 antennas", April, 2009 400 [ARTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 401 "OSPF Routing Extension for Links with Variable Discrete 402 Bandwidth", Work in Progress, February, 2014 404 6.2. Informative References 406 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 407 for Differentiated Services-aware Traffic Engineered 408 LSPs", Work in Progress, June 2006. 410 7. Appendix: Bandwidth Availability Example 412 Presuming that a link has three discrete bandwidth levels: 414 The link bandwidth under modulation level 1, e.g., QPSK, is 100 Mbps; 416 The link bandwidth under modulation level 2, e.g., 16QAM, is 200 417 Mbps; 418 The link bandwidth under modulation level 3, e.g., 256QAM, is 400 419 Mbps. 421 In sunny day, the modulation level 3 can be used to achieve 400 Mbps 422 link bandwidth. 424 A light rain with X mm/h rate triggers the system to change the 425 modulation level from level 3 to level 2, with bandwidth changing 426 from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the 427 local area is 52 minutes in a year. Then the dropped 200 Mbps 428 bandwidth has 99.99% availability. 430 A heavy rain with Y(Y>X) mm/h rate triggers the system to change the 431 modulation level from level 2 to level 1, with bandwidth changing 432 from 200 Mbps to 100 Mbps. The probability of Y mm/h rain in the 433 local area is 26 minutes in a year. Then the dropped 100 Mbps 434 bandwidth has 99.995% availability. 436 For the 100M bandwidth of the modulation level 1, only the extreme 437 weather condition can cause the whole system unavailable, which only 438 happens for 5 minutes in a year. So the 100 Mbps bandwidth of the 439 modulation level 1 owns the availability of 99.999%. 441 In a word, the maximum bandwidth is 400 Mbps. According to the 442 weather condition, the sub-bandwidth and its availability are shown 443 as follows: 445 Sub-bandwidth(Mbps) Availability 447 ------------------ ------------ 449 200 99.99% 451 100 99.995% 453 100 99.999% 455 8. Acknowledgments 457 The authors would like to thank Khuzema Pithewan, Lou Berger, Yuji 458 Tochio, Dieter Beller, and Autumn Liu for their comments on the 459 document. 461 Authors' Addresses 463 Hao Long 464 Huawei Technologies Co., Ltd. 465 No.1899, Xiyuan Avenue, Hi-tech Western District 466 Chengdu 611731, P.R.China 468 Phone: +86-18615778750 469 Email: longhao@huawei.com 471 Min Ye (editor) 472 Huawei Technologies Co., Ltd. 473 No.1899, Xiyuan Avenue, Hi-tech Western District 474 Chengdu 611731, P.R.China 476 Email: amy.yemin@huawei.com 478 Greg Mirsky (editor) 479 Ericsson 481 Email: gregory.mirsky@ericsson.com 483 Alessandro D'Alessandro 484 Telecom Italia S.p.A 486 Email: alessandro.dalessandro@telecomitalia.it 488 Himanshu Shah 489 Ciena Corp. 490 3939 North First Street 491 San Jose, CA 95134 492 US 494 Email: hshah@ciena.com