idnits 2.17.1 draft-long-ccamp-rsvp-te-bandwidth-availability-05.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 4, 2014) is 3556 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 305, but not defined == Missing Reference: 'This ID' is mentioned on line 351, but not defined == Unused Reference: 'RFC2210' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 405, 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.Alessandro 6 Telecom Italia S.p.A 7 H. Shah 8 Ciena 9 Expires: January 2015 July 4, 2014 11 RSVP-TE Signaling Extension for Links with Variable Discrete 12 Bandwidth 13 draft-long-ccamp-rsvp-te-bandwidth-availability-05.txt 15 Abstract 17 Packet switching network MAY contain links with variable bandwidth, 18 e.g., copper, radio, etc. The bandwidth of such link is sensitive to 19 external environment. Availability is typically used for describing 20 the link during network planning. This document describes an 21 extension for RSVP-TE signaling for setting up a label switching 22 path (LSP) in a Packet Switched Network (PSN) network which contains 23 links with discretely variable bandwidth by introducing an Extended 24 Ethernet Bandwidth Profile TLV and an OPTIONAL Availability sub_TLV 25 in RSVP-TE signaling. 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 January 4, 2014. 49 Copyright Notice 51 Copyright (c) 2014 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. Acknowledgments ............................................. 9 81 Appendix A ..................................................... 9 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 lower modulation level need 116 lower signal-to-noise ratio (SNR). This is called adaptive 117 modulation technology [EN 302 217]. However, lower modulation level 118 also means lower link bandwidth. When link bandwidth reduced because 119 of modulation down-shifting, high priority traffic can be maintained, 120 while lower priority traffic is dropped. Similarly the cooper links 121 MAY change their link bandwidth due to external interference. 123 The parameter availability [G.827, F.1703, P.530] is often used to 124 describe the link capacity during network planning. A more detailed 125 example on the bandwidth availability can be found in Appendix A. 126 Assigning different availability classes to different types of 127 service over such kind of links provides more efficient planning of 128 link capacity. To set up an LSP across these links, availability 129 information is required for the nodes to verify bandwidth 130 satisfaction and make bandwidth reservation. The availability 131 information SHOULD be inherited from the availability requirements 132 of the services expected to be carried on the LSP. For example, 133 voice service usually needs ''five nines'' availability, while non- 134 real time services MAY adequately perform at four or three nines 135 availability. Since different service types MAY need different 136 availabilities guarantee, multiple pairs 137 MAY be required when signaling. 139 If the availability requirement is not specified in the signaling 140 message, the bandwidth will be reserved as the highest availability. 142 For example, the bandwidth with 99.999% availability of a link is 143 100Mbps; the bandwidth with 99.99% availability is 200Mbps. When a 144 video application requests for 120Mbps without availability 145 requirement, the system will compare 120Mbps with 100Mbps, therefore 146 cannot set up the LSP path. But in fact, video application doesn't 147 need 99.999% availability, 99.99% availability is enough. In this 148 case, the LSP could be set up if availability is specified in the 149 signaling message. 151 To fulfill LSP setup by signaling in these scenarios, this document 152 specifies an Extended Ethernet Bandwidth Profile and an Availability 153 sub-TLV. The Availability sub-TLV can be applicable to any kind of 154 physical links with variable discrete bandwidth, such as microwave 155 or DSL. Multiple Extended Ethernet Bandwidth Profiles with different 156 availability can be carried in the Ethernet SENDER_TSPEC object. 158 2. Overview 160 A PSN tunnel MAY span one or more links in a network. To setup a 161 label switching path (LSP), a PE node MAY collect link information 162 which is spread in routing message, e.g., OSPF TE LSA message, by 163 network nodes to get to know about the network topology, and 164 calculate out an LSP route based on the network topology, and send 165 the calculated LSP route to signaling to initiate a PATH/RESV 166 message for setting up the LSP. 168 In case that there is(are) link(s) with variable discrete bandwidth 169 in a network, a requirement list SHOULD be 170 specified for an LSP. Each pair in the 171 list means that listed bandwidth with specified availability is 172 required. The list could be inherited from the results of service 173 planning for the LSP. 175 A node which has link(s) with variable discrete bandwidth attached 176 SHOULD contain a information list in its 177 OSPF TE LSA messages. The list provides the information that how 178 much bandwidth a link can support for a specified availability. This 179 information is used for path calculation by the PE node(s). The 180 routing extension for availability can be found in [ARTE]. 182 When a PE node initiates a PATH/RESV signaling to set up an LSP, the 183 PATH message SHOULD carry the requirement 184 list as bandwidth request. Intermediate node(s) will allocate the 185 bandwidth resource for each availability requirement from the 186 remaining bandwidth with corresponding availability. An error 187 message MAY be returned if any request 188 cannot be satisfied. 190 3. Extension to RSVP-TE Signaling 192 The initial idea is to define an Availability sub_TLV under Ethernet 193 Bandwidth Profile TLV [RFC6003]. However the Ethernet Bandwidth 194 Profile TLV doesn't have the ability to carry a sub_TLV according to 195 RFC6003. Therefore, an Extend Ethernet Bandwidth Profile TLV is 196 defined in this document to avoid the backward compatibility issue. 197 The Extended Ethernet Bandwidth Profile TLV includes Ethernet BW TLV 198 and has variable length. It MAY include Availability sub-TLV which 199 is also defined in this document. 201 3.1.1. Extended Ethernet Bandwidth Profile TLV 203 The Extended Ethernet Bandwidth Profile TLV is included in the 204 Ethernet SENDER_TSPEC, and MAY be included for more than one time. 205 The Extended Ethernet Bandwidth Profile TLV has the following format. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type | Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |Pro|A| | Index | Reserved | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | CIR | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | CBS | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | EIR | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | EBS | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | sub_TLV(OPTIONAL) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: A new ''AF'' filed in Extended Ethernet Bandwidth Profile TLV 227 The difference between the Extended Ethernet Bandwidth Profile TLV 228 and Ethernet Bandwidth Profile TLV is that a new AF field to 229 indicate the sub_TLV is defined in the Extended Ethernet Bandwidth 230 Profile TLV. The rest definitions are the same. 232 A new filed is defined in this document: 234 AF filed (bit 2): Availability Field (AF) 236 If the AF filed is set to 1, Availability sub-TLV MUST be included 237 in the Extended Ethernet Bandwidth Profile TLV. If the AF field is 238 set to value 0, then an Availability sub-TLV SHOULD NOT be included. 240 3.1.2. Availability sub-TLV 242 The Availability sub-TLV has the following format: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Availability | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2: Availability sub-TLV 254 Type (2 octets): TBD 256 Length (2 octets): 4 258 Availability (4 octets): a 32-bit floating number describes the 259 decimal value of availability requirement for this bandwidth 260 request. The value MUST be less than 1. 262 As the Extended Ethernet Bandwidth Profile TLV can be carried for 263 one or more times in the Ethernet SENDER_TSPEC object, the 264 Availability sub-TLV can also be present for one or more times. 266 3.2. FLOWSPEC Object 268 The FLOWSPEC object (Class-Num = 9, Class-Type = TBD) has the same 269 format as the Ethernet SENDER_TSPEC object. 271 3.3. Signaling Process 273 The source node initiates PATH messages including one or more 274 Extended Bandwidth Profile TLVs with different availability value in 275 the SENDER_TSPEC object. Each Extended Bandwidth Profile TLV 276 specifies the portion of bandwidth request with referred 277 availability requirement. 279 The intermediate and destination nodes checks whether they can 280 satisfy the bandwidth requirements by comparing each bandwidth 281 requirement inside the SENDER_TSPEC objects with the remaining link 282 sub-bandwidth resource with respective availability guarantee when 283 received the PATH message. 285 o If all requirements can be 286 satisfied, it SHOULD reserve the bandwidth resource from each 287 remaining sub-bandwidth portion to set up this LSP. Optionally, 288 the higher availability bandwidth can be allocated to lower 289 availability request when the lower availability bandwidth 290 cannot satisfy the request. 292 o If at least one requirement cannot 293 be satisfied, it SHOULD generate PathErr message with the error 294 code "Admission Control Error" and the error value "Requested 295 Bandwidth Unavailable" (see [RFC2205]). 297 If two LSPs request for the bandwidth with the same availability 298 requirement, a way to resolve the contention is comparing the node 299 ID, the node with the higher node ID will win the contention. More 300 details can be found in [RFC3473]. 302 If a node does not support the Extended Bandwidth Profile TLV and 303 Availability sub-TLV, it SHOULD generate PathErr message with the 304 error code "Extended Class-Type Error" and the error value "Class- 305 Type mismatch" (see [RFC2205]). 307 4. Security Considerations 309 This document does not introduce new security considerations to the 310 existing RSVP-TE signaling protocol. 312 5. IANA Considerations 314 IANA maintains registries and sub-registries for RSVP-TE used by 315 GMPLS. IANA is requested to make allocations from these registries 316 as set out in the following sections. 318 5.1 Ethernet Sender TSpec TLVs 320 IANA maintains a registry of GMPLS parameters called ''Generalized 321 Multi-Protocol Label Switching (GMPLS) Signaling Parameters''. 323 IANA has created a new sub-registry called ''Ethernet Sender TSpec 324 TLVs / Ethernet Flowspec TLVs'' to contain the TLV type values for 325 TLVs carried in the Ethernet SENDER_TSPEC object. A new value is as 326 follow: 328 Type Description Reference 330 ----- ----------------------------------- --------- 332 TBD Extended Ethernet Bandwidth Profile [This ID] 334 5.2 Extended Ethernet Bandwidth Profile TLV 336 IANA has created a new sub-registry called ''Extended Ethernet 337 Bandwidth Profiles'' to contain bit flags carried in the Extended 338 Ethernet Bandwidth Profile TLV of the Ethernet SENDER_TSPEC object. 340 Bits are to be allocated by IETF Standards Action. Bits are numbered 341 from bit 0 as the low order bit. A new bit field is as follow: 343 Bit Hex Description Reference 345 --- ---- ------------------ ----------- 347 0 0x01 Coupling Flag (CF) [RFC6003] 349 1 0x02 Color Mode (CM) [RFC6003] 351 2 0x03 Availability Field (AF) [This ID] 353 Sub-TLV types for Extended Ethernet Bandwidth Profiles are to be 354 allocated by IETF Standard Action. Initial values are as follows: 356 Type Length Format Description 358 --- ---- ------------------ ----------- 360 0 - Reserved Reserved value 362 0x01 4 see Section 3.1.2 Availability sub-TLV 364 6. References 366 6.1. Normative References 368 [RFC2210] Wroclawski, J., ''The Use of RSVP with IETF Integrated 369 Services'', RFC 2210, September 1997. 371 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 372 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 373 Tunnels", RFC 3209, December 2001. 375 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 376 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 377 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 379 [RFC6003] Papadimitriou, D. ''Ethernet Traffic Parameters'', RFC 6003, 380 October 2010. 382 [G.827] ITU-T Recommendation, ''Availability performance parameters 383 and objectives for end-to-end international constant bit- 384 rate digital paths'', September, 2003. 386 [F.1703] ITU-R Recommendation, ''Availability objectives for real 387 digital fixed wireless links used in 27 500 km 388 hypothetical reference paths and connections'', January, 389 2005. 391 [P.530] ITU-R Recommendation,'' Propagation data and prediction 392 methods required for the design of terrestrial line-of- 393 sight systems'', February, 2012 395 [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics 396 and requirements for point-to-point equipment and 397 antennas'', April, 2009 399 [ARTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 400 ''OSPF Routing Extension for Links with Variable Discrete 401 Bandwidth'', Work in Progress, February, 2014 403 6.2. Informative References 405 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 406 for Differentiated Services-aware Traffic Engineered 407 LSPs", Work in Progress, June 2006. 409 7. Acknowledgments 411 The authors would like to thank Khuzema Pithewan, Lou Berger, Yuji 412 Tochio, Dieter Beller, and Autumn Liu for their comments on the 413 document. 415 Appendix A 417 Presuming that a link has three discrete bandwidth levels: 419 The link bandwidth under modulation level 1, e.g., QPSK, is 100Mbps; 421 The link bandwidth under modulation level 2, e.g., 16QAM, is 200Mbps; 422 The link bandwidth under modulation level 3, e.g., 256QAM, is 423 400Mbps. 425 In sunny day, the modulation level 3 can be used to achieve 400Mbps 426 link bandwidth. 428 A light rain with X mm/h rate triggers the system to change the 429 modulation level from level 3 to level 2, with bandwidth changing 430 from 400Mbps to 200Mbps. The probability of X mm/h rain in the local 431 area is 52 minutes in a year. Then the dropped 200Mbps bandwidth has 432 99.99% availability. 434 A heavy rain with Y(Y>X) mm/h rate triggers the system to change the 435 modulation level from level 2 to level 1, with bandwidth changing 436 from 200Mbps to 100Mbps. The probability of Y mm/h rain in the local 437 area is 26 minutes in a year. Then the dropped 100Mbps bandwidth has 438 99.995% availability. 440 For the 100M bandwidth of the modulation level 1, only the extreme 441 weather condition can cause the whole system unavailable, which only 442 happens for 5 minutes in a year. So the 100Mbps bandwidth of the 443 modulation level 1 owns the availability of 99.999%. 445 In a word, the maximum bandwidth is 400Mbps. According to the 446 weather condition, the sub-bandwidth and its availability are shown 447 as follows: 449 Sub-bandwidth(Mbps) Availability 451 ------------------ ------------ 453 200 99.99% 455 100 99.995% 457 100 99.999% 458 Authors' Addresses 460 Hao Long 461 Huawei Technologies Co., Ltd. 462 No.1899, Xiyuan Avenue, Hi-tech Western District 463 Chengdu 611731, P.R.China 465 Phone: +86-18615778750 466 Email: longhao@huawei.com 468 Min Ye (editor) 469 Huawei Technologies Co., Ltd. 470 No.1899, Xiyuan Avenue, Hi-tech Western District 471 Chengdu 611731, P.R.China 473 Email: amy.yemin@huawei.com 475 Greg Mirsky (editor) 476 Ericsson 478 Email: gregory.mirsky@ericsson.com 480 Alessandro D'Alessandro 481 Telecom Italia S.p.A 483 Email: alessandro.dalessandro@telecomitalia.it 485 Himanshu Shah 486 Ciena Corp. 487 3939 North First Street 488 San Jose, CA 95134 489 US 491 Email: hshah@ciena.com