idnits 2.17.1 draft-ietf-ccamp-ospf-availability-extension-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 : ---------------------------------------------------------------------------- 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 6, 2015) is 3216 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 82, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 158, but not defined == Unused Reference: 'RFC2210' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 315, 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.D'Alessandro 6 Telecom Italia S.p.A 7 H. Shah 8 Ciena 9 Expires: January 2016 July 6, 2015 11 OSPF Routing Extension for Links with Variable Discrete Bandwidth 12 draft-ietf-ccamp-ospf-availability-extension-02.txt 14 Abstract 16 A packet switching network MAY contain links with variable discrete 17 bandwidth, e.g., copper, radio, etc. The bandwidth of such links 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 introduces an OPTIONAL ISCD 21 Availability sub-TLV in OSPF routing protocol. This extension can be 22 used for route computation in a Packet Switched Network (PSN) that 23 contains links with discretely variable bandwidth. 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 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 6, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 OSPF Routing Protocol........................... 4 67 3.1. Interface Switching Capacity Descriptor................. 4 68 3.2. ISCD Availability sub-TLV............................... 5 69 3.3. Signaling Process....................................... 6 70 4. Security Considerations...................................... 7 71 5. IANA Considerations ......................................... 7 72 6. References .................................................. 7 73 6.1. Normative References.................................... 7 74 6.2. Informative References.................................. 8 75 7. Acknowledgments ............................................. 8 77 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC-2119 [RFC2119]. 83 The following acronyms are used in this draft: 85 OSPF Open Shortest Path First 87 PSN Packet Switched Network 88 SNR Signal-to-noise Ratio 90 LSP Label Switched Path 92 ISCD Interface Switching Capacity Descriptor 94 PE Provider Edge 96 LSA Link State Advertisement 98 1. Introduction 100 Some data communication technologies allow seamless change of 101 maximum physical bandwidth through a set of known discrete values. 102 For example, in mobile backhaul network, microwave links are very 103 popular for providing connection of last hops. In case of heavy rain, 104 to maintain the link connectivity, the microwave link MAY lower the 105 modulation level since demodulating the lower modulation level needs 106 lower signal-to-noise ratio (SNR). This is called adaptive 107 modulation technology [EN 302 217]. However, a lower modulation 108 level also means lower link bandwidth. When link bandwidth is 109 reduced because of modulation down-shifting, high-priority traffic 110 can be maintained, while lower-priority traffic is dropped. 111 Similarly, the copper links MAY change their effective link 112 bandwidth due to external interference. 114 The parameter availability [G.827, F.1703, P.530] is often used to 115 describe the link capacity during network planning. Assigning 116 different availability classes to different types of service over 117 such kind of links provides more efficient planning of link capacity. 118 To set up an LSP across these links, availability information is 119 required for the nodes to verify bandwidth satisfaction and make 120 bandwidth reservation. The availability information SHOULD be 121 inherited from the availability requirements of the services 122 expected to be carried on the LSP. For example, voice service 123 usually needs "five nines" availability, while non-real time 124 services MAY adequately perform at four or three nines availability. 126 For the route computation, the availability information SHOULD be 127 provided along with bandwidth resource information. In this document, 128 an extension on Interface Switching Capacity Descriptor (ISCD) 129 [RFC4202] for availability information is defined to support in 130 routing signaling. The extension reuses the reserved field in the 131 ISCD and also introduces an OPTIONAL Availability sub-TLV. 133 If there is a hop that cannot support the Availability sub-TLV, the 134 Availability sub-TLV SHOULD be ignored. 136 2. Overview 138 A node which has link(s) with variable bandwidth attached SHOULD 139 contain a information list in its OSPF TE 140 LSA messages. The list provides the information that how much 141 bandwidth a link can support for a specified availability. This 142 information is used for path calculation by the PE node(s). 144 To setup an label switching path (LSP), a PE node MAY collect link 145 information which is spread in OSPF TE LSA messages by network nodes 146 to get know about the network topology, calculate out an LSP route 147 based on the network topology and send the calculated LSP route to 148 signaling to initiate a PATH/RESV message for setting up the LSP. 150 Availability information is required to carry in the signaling 151 message to better utilize the link bandwidth. The signaling 152 extension for availability can be found in [ASTE]. 154 3. Extension to OSPF Routing Protocol 156 3.1. Interface Switching Capacity Descriptor 158 The Interface Switching Capacity Descriptor (ISCD) sub-TLV [RFC 4203] 159 has the following format: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Switching Cap | Encoding | AI | Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Max LSP Bandwidth at priority 0 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Max LSP Bandwidth at priority 1 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Max LSP Bandwidth at priority 2 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Max LSP Bandwidth at priority 3 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Max LSP Bandwidth at priority 4 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Max LSP Bandwidth at priority 5 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Max LSP Bandwidth at priority 6 | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Max LSP Bandwidth at priority 7 | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Switching Capacity-specific Information | 185 | (variable) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 The Switching Capability field MAY be PSC-1/LSC. The Switching 198 Capability specific information field MAY include one or more ISCD 199 Availability sub-TLV(s). The ISCD Availability sub-TLV has the 200 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 269 6. References 271 6.1. Normative References 273 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 274 Services", RFC 2210, September 1997. 276 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 277 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 278 Tunnels", RFC 3209, December 2001. 280 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 281 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 282 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 284 [RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing 285 Extensions in Support of Generalized Multi-Protocol Label 286 Switching (GMPLS)", RFC 4202, October 2005. 288 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 289 in Support of Generalized Multi-Protocol Label Switching 290 (GMPLS)", RFC 4203, October 2005. 292 [G.827] ITU-T Recommendation, "Availability performance parameters 293 and objectives for end-to-end international constant bit- 294 rate digital paths", September, 2003. 296 [F.1703] ITU-R Recommendation, "Availability objectives for real 297 digital fixed wireless links used in 27 500 km 298 hypothetical reference paths and connections", January, 299 2005. 301 [P.530] ITU-R Recommendation," Propagation data and prediction 302 methods required for the design of terrestrial line-of- 303 sight systems", February, 2012 305 [EN 302 217] ETSI standard, "Fixed Radio Systems; Characteristics 306 and requirements for point-to-point equipment and 307 antennas", April, 2009 309 [ASTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 310 "RSVP-TE Signaling Extension for Links with Variable 311 Discrete Bandwidth", Work in Progress, February, 2014 313 6.2. Informative References 315 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 316 for Differentiated Services-aware Traffic Engineered 317 LSPs", Work in Progress, June 2006. 319 7. Acknowledgments 321 Authors' Addresses 322 Hao Long 323 Huawei Technologies Co., Ltd. 324 No.1899, Xiyuan Avenue, Hi-tech Western District 325 Chengdu 611731, P.R.China 327 Phone: +86-18615778750 328 Email: longhao@huawei.com 330 Min Ye 331 Huawei Technologies Co., Ltd. 332 No.1899, Xiyuan Avenue, Hi-tech Western District 333 Chengdu 611731, P.R.China 335 Email: amy.yemin@huawei.com 337 Greg Mirsky 338 Ericsson 340 Email: gregory.mirsky@ericsson.com 342 Alessandro D'Alessandro 343 Telecom Italia S.p.A 345 Email: alessandro.dalessandro@telecomitalia.it 347 Himanshu Shah 348 Ciena Corp. 349 3939 North First Street 350 San Jose, CA 95134 351 US 353 Email: hshah@ciena.com