idnits 2.17.1 draft-ietf-ccamp-ospf-availability-extension-00.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 (October 8, 2014) is 3460 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: 'RFC 4203' is mentioned on line 159, but not defined == Unused Reference: 'RFC2210' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 316, 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. 'ASTE' Summary: 0 errors (**), 0 flaws (~~), 9 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: April 2015 October 8, 2014 11 OSPF Routing Extension for Links with Variable Discrete Bandwidth 12 draft-ietf-ccamp-ospf-availability-extension-00.txt 14 Abstract 16 Packet switching network MAY contain links with variable discrete 17 bandwidth, e.g., copper, radio, etc. The bandwidth of such link MAY 18 change discretely in reaction to changing external environment. 19 Availability is typically used for describing such links during 20 network planning. This document describes an extension for OSPF 21 routing for route computation in a Packet Switched Network (PSN) 22 which contains links with variable discrete bandwidth by introducing 23 an OPTIONAL Availability sub-TLV. 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 April 8, 2014. 48 Copyright Notice 50 Copyright (c) 2014 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 .................................................... 3 67 3. Extension to OSPF Routing Protocol........................... 4 68 3.1. Interface Switching Capacity Descriptor................. 4 69 3.2. ISCD Availability sub-TLV............................... 5 70 3.3. Signaling Process....................................... 6 71 4. Security Considerations...................................... 6 72 5. IANA Considerations ......................................... 6 73 6. References .................................................. 6 74 6.1. Normative References.................................... 6 75 6.2. Informative References.................................. 7 76 7. Acknowledgments ............................................. 7 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 OSPF Open Shortest Path First 88 PSN Packet Switched Network 90 SNR Signal-to-noise Ratio 92 LSP Label Switched Path 94 ISCD Interface Switching Capacity Descriptor 95 PE Provider Edge 97 LSA Link State Advertisement 99 1. Introduction 101 Some data communication technologies allow seamless change of 102 maximum physical bandwidth through a set of known discrete values. 103 For example, in mobile backhaul network, microwave links are very 104 popular for providing connection of last hops. In case of heavy rain, 105 to maintain the link connectivity, the microwave link MAY lower the 106 modulation level since demodulating lower modulation level need 107 lower signal-to-noise ratio (SNR). This is called adaptive 108 modulation technology [EN 302 217]. However, lower modulation level 109 also means lower link bandwidth. When link bandwidth reduced because 110 of modulation down-shifting, high priority traffic can be maintained, 111 while lower priority traffic is dropped. Similarly the cooper links 112 MAY change their effective link bandwidth due to external 113 interference. 115 The parameter availability [G.827, F.1703, P.530] is often used to 116 describe the link capacity during network planning. Assigning 117 different availability classes to different types of service over 118 such kind of links provides more efficient planning of link capacity. 119 To set up an LSP across these links, availability information is 120 required for the nodes to verify bandwidth satisfaction and make 121 bandwidth reservation. The availability information SHOULD be 122 inherited from the availability requirements of the services 123 expected to be carried on the LSP. For example, voice service 124 usually needs ''five nines'' availability, while non-real time 125 services MAY adequately perform at four or three nines availability. 127 For the route computation, the availability information SHOULD be 128 provided along with bandwidth resource information. In this document, 129 an extension on Interface Switching Capacity Descriptor (ISCD) 130 [RFC4202] for availability information is defined to support in 131 routing signaling. The extension reuses the reserved field in the 132 ISCD and also introduces an OPTIONAL Availability sub-TLV. 134 If there is a hop that cannot support the Availability sub-TLV, the 135 Availability sub-TLV SHOULD be ignored. 137 2. Overview 139 A node which has link(s) with variable bandwidth attached SHOULD 140 contain a information list in its OSPF TE 141 LSA messages. The list provides the information that how much 142 bandwidth a link can support for a specified availability. This 143 information is used for path calculation by the PE node(s). 145 To setup an label switching path (LSP), a PE node MAY collect link 146 information which is spread in OSPF TE LSA messages by network nodes 147 to get know about the network topology, calculate out an LSP route 148 based on the network topology and send the calculated LSP route to 149 signaling to initiate a PATH/RESV message for setting up the LSP. 151 Availability information is required to carry in the signaling 152 message to better utilize the link bandwidth. The signaling 153 extension for availability can be found in [ASTE]. 155 3. Extension to OSPF Routing Protocol 157 3.1. Interface Switching Capacity Descriptor 159 The Interface Switching Capacity Descriptor (ISCD) sub-TLV [RFC 4203] 160 has the following format: 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Switching Cap | Encoding | AI | Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Max LSP Bandwidth at priority 0 | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Max LSP Bandwidth at priority 1 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Max LSP Bandwidth at priority 2 | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Max LSP Bandwidth at priority 3 | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Max LSP Bandwidth at priority 4 | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Max LSP Bandwidth at priority 5 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Max LSP Bandwidth at priority 6 | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Max LSP Bandwidth at priority 7 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Switching Capacity-specific Information | 186 | (variable) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 A new AI field is defined in this document. 190 AI: ISCD Availability sub-TLV index, 8 bits 192 This new field is the index of Availability sub-TLV for this 193 ISCD sub-TLV. 195 3.2. ISCD Availability sub-TLV 197 When the Switching Capability field is PSC-1, PSC-2, PSC-3, PSC-4, 198 the Switching Capability specific information field MAY include one 199 or more ISCD Availability sub-TLV(s). The ISCD Availability sub-TLV 200 has the following format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Index | Reserved | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Availability level | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | LSP Bandwidth at Availability level n | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Type: 0x01, 16 bits; 215 Length: 16 bits; 217 Index: 8 bits 219 This field is the index of this Availability sub-TLV, 220 referred by the AI field of the ISCD sub-TLV. 222 Availability level: 32 bits 224 This field is a 32-bit IEEE floating point number which 225 describes the decimal value of availability guarantee of the 226 switching capacity in the ISCD object which has the AI value 227 equal to Index of this sub-TLV. The value MUST be less than 228 1. 230 LSP Bandwidth at Availability level n: 32 bits 232 This field is a 32-bit IEEE floating point number which 233 describes the LSP Bandwidth at a certain Availability level 234 which was described in the Availability field. 236 3.3. Signaling Process 238 A node which has link(s) with variable bandwidth attached SHOULD 239 contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA 240 messages. Each ISCD Availability sub-TLV provides the information 241 about how much bandwidth a link can support for a specified 242 availability. This information SHOULD be used for path calculation 243 by the PE node(s). 245 A node that doesn't support ISCD Availability sub-TLV SHOULD ignore 246 ISCD Availability sub-TLV. 248 4. Security Considerations 250 This document does not introduce new security considerations to the 251 existing OSPF protocol. 253 5. IANA Considerations 255 This document introduces an Availability sub-TLV of the ISCD sub-TLV 256 of the TE Link TLV in the TE Opaque LSA for OSPF v2. This document 257 proposes a suggested value for the Availability sub-TLV; it is 258 recommended that the suggested value be granted by IANA. Initial 259 values are as follows: 261 Type Length Format Description 263 --- ---- ------------------ ----------- 265 0 - Reserved Reserved value 267 0x01 8 see Section 3.2 Availability sub- 268 TLV 270 6. References 272 6.1. Normative References 274 [RFC2210] Wroclawski, J., ''The Use of RSVP with IETF Integrated 275 Services'', RFC 2210, September 1997. 277 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 278 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 279 Tunnels", RFC 3209, December 2001. 281 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 282 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 283 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 285 [RFC4202] Kompella, K. and Rekhter, Y. (Editors), ''Routing 286 Extensions in Support of Generalized Multi-Protocol Label 287 Switching (GMPLS)", RFC 4202, October 2005. 289 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 290 in Support of Generalized Multi-Protocol Label Switching 291 (GMPLS)", RFC 4203, October 2005. 293 [G.827] ITU-T Recommendation, ''Availability performance parameters 294 and objectives for end-to-end international constant bit- 295 rate digital paths'', September, 2003. 297 [F.1703] ITU-R Recommendation, ''Availability objectives for real 298 digital fixed wireless links used in 27 500 km 299 hypothetical reference paths and connections'', January, 300 2005. 302 [P.530] ITU-R Recommendation,'' Propagation data and prediction 303 methods required for the design of terrestrial line-of- 304 sight systems'', February, 2012 306 [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics 307 and requirements for point-to-point equipment and 308 antennas'', April, 2009 310 [ASTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 311 ''RSVP-TE Signaling Extension for Links with Variable 312 Discrete Bandwidth'', Work in Progress, February, 2014 314 6.2. Informative References 316 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 317 for Differentiated Services-aware Traffic Engineered 318 LSPs", Work in Progress, June 2006. 320 7. Acknowledgments 322 Authors' Addresses 323 Hao Long 324 Huawei Technologies Co., Ltd. 325 No.1899, Xiyuan Avenue, Hi-tech Western District 326 Chengdu 611731, P.R.China 328 Phone: +86-18615778750 329 Email: longhao@huawei.com 331 Min Ye 332 Huawei Technologies Co., Ltd. 333 No.1899, Xiyuan Avenue, Hi-tech Western District 334 Chengdu 611731, P.R.China 336 Email: amy.yemin@huawei.com 338 Greg Mirsky 339 Ericsson 341 Email: gregory.mirsky@ericsson.com 343 Alessandro D'Alessandro 344 Telecom Italia S.p.A 346 Email: alessandro.dalessandro@telecomitalia.it 348 Himanshu Shah 349 Ciena Corp. 350 3939 North First Street 351 San Jose, CA 95134 352 US 354 Email: hshah@ciena.com