idnits 2.17.1 draft-ietf-ccamp-rsvp-te-bandwidth-availability-02.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 are 2 instances 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 (July 2, 2015) is 3219 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 296, but not defined == Missing Reference: 'This ID' is mentioned on line 341, but not defined == Unused Reference: 'RFC2210' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 395, 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: 1 error (**), 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: January 2016 July 2, 2015 11 RSVP-TE Signaling Extension for Links with Variable Discrete 12 Bandwidth 13 draft-ietf-ccamp-rsvp-te-bandwidth-availability-02.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 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on January 6, 2016. 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............................... 4 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 Reference .................................. 9 80 7. Appendix: Bandwidth Availability Example..................... 9 81 8. Acknowledgments ............................................ 11 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 95 PSN Packet Switched Network 97 SNR Signal-to-noise Ratio 99 TLV Type Length Value 101 PE Provider Edge 103 LSA Link State Advertisement 105 1. Introduction 107 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] 108 specify the signaling message including the bandwidth request for 109 setting up a label switching path in a PSN network. 111 Some data communication technologies allow seamless change of 112 maximum physical bandwidth through a set of known discrete values. 113 The parameter availability [G.827, F.1703, P.530] is often used to 114 describe the link capacity during network planning. The availability 115 is a time scale that the requested bandwidth is ensured. A more 116 detailed example on the bandwidth availability can be found in 117 Appendix A. Assigning different availability classes to different 118 types of service over such kind of links provides more efficient 119 planning of link capacity. To set up an LSP across these links, 120 availability information is required for the nodes to verify 121 bandwidth satisfaction and make bandwidth reservation. The 122 availability information SHOULD be inherited from the availability 123 requirements of the services expected to be carried on the LSP. For 124 example, voice service usually needs ''five nines'' availability, 125 while non-real time services MAY adequately perform at four or three 126 nines availability. Since different service types MAY need different 127 availabilities guarantees, multiple pairs 128 MAY be required when signaling. 130 If the availability requirement is not specified in the signaling 131 message, the bandwidth will be reserved as the highest availability. 132 For example, the bandwidth with 99.999% availability of a link is 133 100 Mbps; the bandwidth with 99.99% availability is 200 Mbps. When a 134 video application requests for 120 Mbps without availability 135 requirement, the system will consider the request as 120 Mbps with 136 99.999% availability, while the available bandwidth with 99.999% 137 availability is only 100 Mbps, therefore the LSP path cannot be set 138 up. But in fact, video application doesn't need 99.999% availability; 139 99.99% availability is enough. In this case, the LSP could be set up 140 if availability is specified in the signaling message. 142 To fulfill LSP setup by signaling in these scenarios, this document 143 specifies an Extended Ethernet Bandwidth Profile and an Availability 144 sub-TLV. The Availability sub-TLV can be applicable to any kind of 145 physical links with variable discrete bandwidth, such as microwave 146 or DSL. Multiple Extended Ethernet Bandwidth Profiles with different 147 availability can be carried in the Ethernet SENDER_TSPEC object. 149 2. Overview 151 A PSN tunnel MAY span one or more links in a network. To setup a 152 label switching path (LSP), a PE node MAY collect link information 153 which is spread in routing message, e.g., OSPF TE LSA message, by 154 network nodes to get to know about the network topology, and 155 calculate out an LSP route based on the network topology, and send 156 the calculated LSP route to signaling to initiate a PATH/RESV 157 message for setting up the LSP. 159 In case that there is(are) link(s) with variable discrete bandwidth 160 in a network, a requirement list SHOULD be 161 specified for an LSP. Each pair in the 162 list means that listed bandwidth with specified availability is 163 required. The list could be inherited from the results of service 164 planning for the LSP. 166 A node which has link(s) with variable discrete bandwidth attached 167 SHOULD contain a information list in its 168 OSPF TE LSA messages. The list provides the information that how 169 much bandwidth a link can support for a specified availability. This 170 information is used for path calculation by the PE node(s). The 171 routing extension for availability can be found in [ARTE]. 173 When a PE node initiates a PATH/RESV signaling to set up an LSP, the 174 PATH message SHOULD carry the requirement 175 list as bandwidth request. Intermediate node(s) will allocate the 176 bandwidth resource for each availability requirement from the 177 remaining bandwidth with corresponding availability. An error 178 message MAY be returned if any request 179 cannot be satisfied. 181 3. Extension to RSVP-TE Signaling 183 The initial idea is to define an Availability sub-TLV under Ethernet 184 Bandwidth Profile TLV [RFC6003]. However the Ethernet Bandwidth 185 Profile TLV doesn't have the ability to carry a sub-TLV according to 186 RFC6003. Therefore, an Extend Ethernet Bandwidth Profile TLV is 187 defined in this document to avoid the backward compatibility issue. 188 The Extended Ethernet Bandwidth Profile TLV includes Ethernet BW TLV 189 and has variable length. It MAY include Availability sub-TLV which 190 is also defined in this document. 192 3.1.1. Extended Ethernet Bandwidth Profile TLV 194 The Extended Ethernet Bandwidth Profile TLV is included in the 195 Ethernet SENDER_TSPEC, and MAY be included for more than one time. 196 The Extended Ethernet Bandwidth Profile TLV has the following format. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |Pro|A| | Index | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | CIR | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | CBS | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | EIR | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | EBS | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | sub-TLV(OPTIONAL) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1: A new ''AF'' filed in Extended Ethernet Bandwidth Profile TLV 218 The difference between the Extended Ethernet Bandwidth Profile TLV 219 and Ethernet Bandwidth Profile TLV is that a new AF field to 220 indicate the sub-TLV is defined in the Extended Ethernet Bandwidth 221 Profile TLV. The rest definitions are the same. 223 A new filed is defined in this document: 225 AF filed (bit 2): Availability Field (AF) 227 If the AF filed is set to 1, Availability sub-TLV MUST be included 228 in the Extended Ethernet Bandwidth Profile TLV. If the AF field is 229 set to value 0, then an Availability sub-TLV SHOULD NOT be included. 231 3.1.2. Availability sub-TLV 233 The Availability sub-TLV has the following format: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Availability | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 2: Availability sub-TLV 245 Type (2 octets): TBD 247 Length (2 octets): 4 249 Availability (4 octets): a 32-bit floating number describes the 250 decimal value of availability requirement for this bandwidth 251 request. The value MUST be less than 1. 253 As the Extended Ethernet Bandwidth Profile TLV can be carried for 254 one or more times in the Ethernet SENDER_TSPEC object, the 255 Availability sub-TLV can also be present for one or more times. 257 3.2. FLOWSPEC Object 259 The FLOWSPEC object (Class-Num = 9, Class-Type = TBD) has the same 260 format as the Ethernet SENDER_TSPEC object. 262 3.3. Signaling Process 264 The source node initiates PATH messages including one or more 265 Extended Bandwidth Profile TLVs with different availability values 266 in the SENDER_TSPEC object. Each Extended Bandwidth Profile TLV 267 specifies the portion of the bandwidth request with referred 268 availability requirement. 270 The intermediate and destination nodes check whether they can 271 satisfy the bandwidth requirements by comparing each bandwidth 272 requirement inside the SENDER_TSPEC objects with the remaining link 273 sub-bandwidth resource with respective availability guarantee when 274 received the PATH message. 276 o If all requirements can be 277 satisfied, it SHOULD reserve the bandwidth resource from each 278 remaining sub-bandwidth portion to set up this LSP. Optionally, 279 the higher availability bandwidth can be allocated to lower 280 availability request when the lower availability bandwidth 281 cannot satisfy the request. 283 o If at least one requirement cannot 284 be satisfied, it SHOULD generate PathErr message with the error 285 code "Admission Control Error" and the error value "Requested 286 Bandwidth Unavailable" (see [RFC2205]). 288 If two LSPs request for the bandwidth with the same availability 289 requirement, a way to resolve the contention is comparing the node 290 ID, the node with the higher node ID will win the contention. More 291 details can be found in [RFC3473]. 293 If a node does not support the Extended Bandwidth Profile TLV and 294 Availability sub-TLV, it SHOULD generate PathErr message with the 295 error code "Extended Class-Type Error" and the error value "Class- 296 Type mismatch" (see [RFC2205]). 298 4. Security Considerations 300 This document does not introduce new security considerations to the 301 existing RSVP-TE signaling protocol. 303 5. IANA Considerations 305 IANA maintains registries and sub-registries for RSVP-TE used by 306 GMPLS. IANA is requested to make allocations from these registries 307 as set out in the following sections. 309 5.1 Ethernet Sender TSpec TLVs 311 IANA maintains a registry of GMPLS parameters called ''Generalized 312 Multi-Protocol Label Switching (GMPLS) Signaling Parameters''. 314 IANA has created a new sub-registry called ''Ethernet Sender TSpec 315 TLVs / Ethernet Flowspec TLVs'' to contain the TLV type values for 316 TLVs carried in the Ethernet SENDER_TSPEC object. A new value is as 317 follow: 319 Type Description Reference 320 ----- ----------------------------------- --------- 322 TBD Extended Ethernet Bandwidth Profile [This ID] 324 5.2 Extended Ethernet Bandwidth Profile TLV 326 IANA has created a new sub-registry called ''Extended Ethernet 327 Bandwidth Profiles'' to contain bit flags carried in the Extended 328 Ethernet Bandwidth Profile TLV of the Ethernet SENDER_TSPEC object. 330 Bits are to be allocated by Standards Action. Bits are numbered from 331 bit 0 as the low order bit. A new bit field is as follow: 333 Bit Hex Description Reference 335 --- ---- ------------------ ----------- 337 0 0x01 Coupling Flag (CF) [RFC6003] 339 1 0x02 Color Mode (CM) [RFC6003] 341 2 0x04 Availability Field (AF) [This ID] 343 Sub-TLV types for Extended Ethernet Bandwidth Profiles are to be 344 allocated by Standards Action. Initial values are as follows: 346 Type Length Format Description 348 --- ---- ------------------ ----------- 350 0 - Reserved Reserved value 352 0x01 4 see Section 3.1.2 of this ID Availability 354 6. References 356 6.1. Normative References 358 [RFC2210] Wroclawski, J., ''The Use of RSVP with IETF Integrated 359 Services'', RFC 2210, September 1997. 361 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 362 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 363 Tunnels", RFC 3209, December 2001. 365 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 366 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 367 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 369 [RFC6003] Papadimitriou, D. ''Ethernet Traffic Parameters'', RFC 6003, 370 October 2010. 372 [G.827] ITU-T Recommendation, ''Availability performance parameters 373 and objectives for end-to-end international constant bit- 374 rate digital paths'', September, 2003. 376 [F.1703] ITU-R Recommendation, ''Availability objectives for real 377 digital fixed wireless links used in 27 500 km 378 hypothetical reference paths and connections'', January, 379 2005. 381 [P.530] ITU-R Recommendation,'' Propagation data and prediction 382 methods required for the design of terrestrial line-of- 383 sight systems'', February, 2012 385 [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics 386 and requirements for point-to-point equipment and 387 antennas'', April, 2009 389 [ARTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 390 ''OSPF Routing Extension for Links with Variable Discrete 391 Bandwidth'', Work in Progress, February, 2014 393 6.2. Informative References 395 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 396 for Differentiated Services-aware Traffic Engineered 397 LSPs", Work in Progress, June 2006. 399 7. Appendix: Bandwidth Availability Example 401 In mobile backhaul network, microwave links are very popular for 402 providing connection of last hops. In case of heavy rain, to 403 maintain the link connectivity, the microwave link MAY lower the 404 modulation level since demodulating the lower modulation level needs 405 a lower Signal-to-Noise Ratio (SNR). This is called adaptive 406 modulation technology [EN 302 217]. However, a lower modulation 407 level also means lower link bandwidth. When link bandwidth is 408 reduced because of modulation down-shifting, high-priority traffic 409 can be maintained, while lower-priority traffic is dropped. 410 Similarly, the copper links MAY change their link bandwidth due to 411 external interference. 413 Presuming that a link has three discrete bandwidth levels: 415 The link bandwidth under modulation level 1, e.g., QPSK, is 100 Mbps; 417 The link bandwidth under modulation level 2, e.g., 16QAM, is 200 418 Mbps; 420 The link bandwidth under modulation level 3, e.g., 256QAM, is 400 421 Mbps. 423 In sunny day, the modulation level 3 can be used to achieve 400 Mbps 424 link bandwidth. 426 A light rain with X mm/h rate triggers the system to change the 427 modulation level from level 3 to level 2, with bandwidth changing 428 from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the 429 local area is 52 minutes in a year. Then the dropped 200 Mbps 430 bandwidth has 99.99% availability. 432 A heavy rain with Y(Y>X) mm/h rate triggers the system to change the 433 modulation level from level 2 to level 1, with bandwidth changing 434 from 200 Mbps to 100 Mbps. The probability of Y mm/h rain in the 435 local area is 26 minutes in a year. Then the dropped 100 Mbps 436 bandwidth has 99.995% availability. 438 For the 100M bandwidth of the modulation level 1, only the extreme 439 weather condition can cause the whole system unavailable, which only 440 happens for 5 minutes in a year. So the 100 Mbps bandwidth of the 441 modulation level 1 owns the availability of 99.999%. 443 In a word, the maximum bandwidth is 400 Mbps. According to the 444 weather condition, the sub-bandwidth and its availability are shown 445 as follows: 447 Sub-bandwidth(Mbps) Availability 449 ------------------ ------------ 451 200 99.99% 453 100 99.995% 455 100 99.999% 457 8. Acknowledgments 459 The authors would like to thank Khuzema Pithewan, Lou Berger, Yuji 460 Tochio, Dieter Beller, and Autumn Liu for their comments on the 461 document. 463 Authors' Addresses 464 Hao Long 465 Huawei Technologies Co., Ltd. 466 No.1899, Xiyuan Avenue, Hi-tech Western District 467 Chengdu 611731, P.R.China 469 Phone: +86-18615778750 470 Email: longhao@huawei.com 472 Min Ye (editor) 473 Huawei Technologies Co., Ltd. 474 No.1899, Xiyuan Avenue, Hi-tech Western District 475 Chengdu 611731, P.R.China 477 Email: amy.yemin@huawei.com 479 Greg Mirsky (editor) 480 Ericsson 482 Email: gregory.mirsky@ericsson.com 484 Alessandro D'Alessandro 485 Telecom Italia S.p.A 487 Email: alessandro.dalessandro@telecomitalia.it 489 Himanshu Shah 490 Ciena Corp. 491 3939 North First Street 492 San Jose, CA 95134 493 US 495 Email: hshah@ciena.com