idnits 2.17.1 draft-long-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 (July 3, 2013) is 3949 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 83, but not defined == Missing Reference: 'RFC2205' is mentioned on line 279, but not defined == Unused Reference: 'G.827' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 327, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.827' Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Long 2 Internet Draft M.Ye 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 G. Mirsky 5 Ericsson 6 A Alessandro 7 Telecom Italia S.p.A 8 Expires: January 2014 July 3, 2013 10 RSVP-TE Signaling Extension for Bandwidth availability 11 draft-long-ccamp-rsvp-te-bandwidth-availability-01.txt 13 Abstract 15 Packet switching network usually contains links with variable 16 bandwidth, e.g., copper, radio, etc. The bandwidth of such link is 17 sensitive to external environment. Availability is typically used 18 for describing the link during network planning. This document 19 describes an extension for RSVP-TE signaling for setting up a label 20 switching path (LSP) in a Packet Switched Network (PSN) network 21 which contains variable bandwidth link by introducing an optional 22 availability field in RSVP-TE signaling. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on January 7, 2009. 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................ 3 65 2. Overview .................................................... 4 66 3. Extension to RSVP-TE Signaling............................... 4 67 3.1. SENDER_TSPEC Object..................................... 4 68 3.1.1. Bandwidth Profile TLV.............................. 5 69 3.2. FLOWSPEC Object......................................... 6 70 3.3. Signaling Process....................................... 6 71 4. Security Considerations...................................... 7 72 5. IANA Considerations ......................................... 7 73 6. References .................................................. 7 74 6.1. Normative References.................................... 7 75 6.2. Informative References.................................. 8 76 7. Acknowledgments ............................................. 8 78 Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC-2119 [RFC2119]. 84 The following acronyms are used in this draft: 86 RSVP-TE Resource Reservation Protocol-Traffic Engineering 88 LSP Label Switched Path 90 PSN Packet Switched Network 92 SNR Signal-to-noise Ratio 93 TLV Type Length Value 95 PE Provider Edge 97 LSA Link State Advertisement 99 1. Introduction 101 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] 102 specify the signaling message including the bandwidth request for 103 setting up a label switching path in a PSN network. 105 There are some data communication technologies that allow seamless 106 change of maximum physical bandwidth. For example, in mobile 107 backhaul network, microwave links are very popular for providing 108 connection of last hops. In case of heavy rain, to maintain the link 109 connectivity, the microwave link will lower the modulation level 110 since demodulating lower modulation level need lower signal-to-noise 111 ratio (SNR). This is called adaptive modulation technology [EN 302 112 217]. However, lower modulation level also means lower link 113 bandwidth. When link bandwidth reduces by modulation down-shifting, 114 high priority traffic can be maintained, while lower priority 115 traffic is dropped. Similarly the cooper links may change their link 116 bandwidth due to external interference. 118 The parameter, availability [G.827, F.1703, P.530], is often used to 119 describe the link capacity during network planning. Assigning 120 different availability classes to different types of service over 121 such kind of links provides more efficient planning of link capacity. 122 To set up a LSP across these links, availability information is 123 required for the nodes to verify bandwidth satisfaction and make 124 bandwidth reservation. The availability information should be 125 inherited from the availability requirements of the services 126 expected to be carried on the LSP, voice service usually needs ''five 127 nines'' availability, while non-real time data packets may needs four 128 or three nines availability. Since different service types may need 129 different availabilities guarantee, multiple pairs may be required when signaling. 132 To fulfill LSP setup by signaling in these scenarios, this document 133 specifies the following extension: 135 o A new SENDER_TSPEC object is defined which includes multiple 136 bandwidth profiles with different availability. This object is 137 an extension on the Ethernet SENDER_TSPEC defined by [RFC6003] 138 which support multiple bandwidth profile TLVs, but limited in 139 the scope of Ethernet. The extension uses the object 140 generically, and amends availability information in the 141 bandwidth profile TLV. 143 2. Overview 145 A PSN tunnel may span one or more links in a network. To setup a 146 label switching path (LSP), a PE node may collect link information 147 which is spread in routing message, e.g., OSPF TE LSA message, by 148 network nodes to get know about the network topology, and calculate 149 out a LSP route based on the network topology, and send the 150 calculated LSP route to signaling to initiate a PATH/RESV message 151 for setting up the LSP. 153 In case that there is(are) link(s) with variable bandwidth in a 154 network, a requirement list should be 155 specified for a LSP. Each pair in the list 156 means a bandwidth with specified availability is required. The list 157 could be inherited from the result of service planning for the LSP. 159 When a PE node initiates a PATH/RESV signaling for setting up the 160 LSP, the PATH message should carry the 161 requirement list as bandwidth request, and the intermediate node(s) 162 will allocate the bandwidth resource for each availability 163 requirement from the remaining bandwidth with corresponding 164 availability. An error message may be returned if any request cannot be satisfied. 167 3. Extension to RSVP-TE Signaling 169 3.1. SENDER_TSPEC Object 171 The SENDER_TSPEC object (Class-Num = 12) has the following format: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Length | Class-Num (12)| C-Type | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Class-Specific Information (Optional) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 ~ TLVs ~ 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Class-Specific Information: 32 bits 187 This field indicates the specific information for each C-Type. 189 TLV (Type-Length-Value): 191 The SENDER_TSPEC object MUST include at least one TLV and MAY 192 include more than one TLV. 194 3.1.1. Bandwidth Profile TLV 196 The 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 | Profile | Index | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | ... ... | 206 ~ Traffic Parameters ~ 207 | ... ... | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Type: TBD, 16 bits; 212 Length: 16 bits; 214 Profile: 8 bits 216 This field is defined as a bit vector of binary flags. The 217 following flags are defined: 219 Flag 3 (bit 2): Availability Flag (AF) 221 When The Flag 3 is set to value 1, there is an availability 222 sub-TLV included in this Bandwidth Profile TLV. The 223 availability sub-TLV has the following format: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Availability | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type (2 octets): TBD 234 Length (2 octets): 4 235 Availability (4 octets): a 32-bit floating number describes 236 availability requirement for this bandwidth request. The 237 value must be less than 1. 239 Index: 8 bits 241 See [RFC6003] section 4.1. 243 Traffic Parameters: 245 This field includes the traffic parameters information. The 246 format is different for different C-Type. 248 C-Type = IntServ: See [RFC2210]; 249 C-Type = Ethernet: See [RFC6003]; 251 3.2. FLOWSPEC Object 253 The FLOWSPEC object (Class-Num = 9, Class-Type = TBD) has the same 254 format as the Ethernet SENDER_TSPEC object. 256 3.3. Signaling Process 258 The source node initiates PATH messages including one or more 259 Bandwidth Profile TLVs with different availability value in the 260 SENDER_TSPEC object. Each Bandwidth Profile TLV specifies the 261 portion of bandwidth request with referred availability requirement. 263 The destination nodes check whether it can satisfy the bandwidth 264 requirement by comparing each bandwidth requirement inside the 265 SENDER_TSPEC objects with the remaining link sub-bandwidth resource 266 with respective availability guarantee when received the PATH 267 message. 269 o If all bandwidth requirements can be satisfied, it should 270 reserve the bandwidth resource from each remaining sub- 271 bandwidth portion to set up this LSP. Optionally, the higher 272 availability bandwidth can be allocated to lower availability 273 request when the lower availability bandwidth cannot satisfy 274 the request. 276 o If at least one bandwidth requirement cannot be satisfied, it 277 should generate PathErr message with the error code "Traffic 278 Control Error" and the error value "Bad Tspec value" (see 279 [RFC2205]). 281 4. Security Considerations 283 This document does not introduce new security considerations to the 284 existing RSVP-TE signaling protocol. 286 5. IANA Considerations 288 TBD 290 6. References 292 6.1. Normative References 294 [RFC2210] Wroclawski, J., ''The Use of RSVP with IETF Integrated 295 Services'', RFC 2210, September 1997. 297 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 298 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 299 Tunnels", RFC 3209, December 2001. 301 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 302 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 303 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 305 [RFC6003] Papadimitriou, D. ''Ethernet Traffic Parameters'', RFC 306 6003, October 2010. 308 [G.827] ITU-T Recommendation, ''Availability performance parameters 309 and objectives for end-to-end international constant bit- 310 rate digital paths'', September, 2003. 312 [F.1703] ITU-R Recommendation, ''Availability objectives for real 313 digital fixed wireless links used in 27 500 km 314 hypothetical reference paths and connections'', January, 315 2005. 317 [P.530] ITU-R Recommendation,'' Propagation data and prediction 318 methods required for the design of terrestrial line-of- 319 sight systems'', February, 2012 321 [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics 322 and requirements for point-to-point equipment and 323 antennas'', April, 2009 325 6.2. Informative References 327 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 328 for Differentiated Services-aware Traffic Engineered 329 LSPs", Work in Progress, June 2006. 331 7. Acknowledgments 333 Authors' Addresses 334 Hao Long 335 Huawei Technologies Co., Ltd. 336 No.1899, Xiyuan Avenue, Hi-tech Western District 337 Chengdu 611731, P.R.China 339 Phone: +86-18615778750 340 Email: longhao@huawei.com 342 Min Ye 343 Huawei Technologies Co., Ltd. 344 No.1899, Xiyuan Avenue, Hi-tech Western District 345 Chengdu 611731, P.R.China 347 Email: amy.yemin@huawei.com 349 Greg Mirsky 350 Ericsson 352 Email: gregory.mirsky@ericsson.com 354 Alessandro D'Alessandro 355 Telecom Italia S.p.A 357 Email: alessandro.dalessandro@telecomitalia.it