idnits 2.17.1 draft-ietf-ccamp-ospf-availability-extension-10.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 (August 8, 2017) is 2446 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: 'This ID' is mentioned on line 267, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GSCSI' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 ZTE 5 A.D'Alessandro 6 Telecom Italia S.p.A 7 H. Shah 8 Ciena 9 Expires: February 2018 August 8, 2017 11 OSPF-TE Link Availability Extension for Links with Variable Discrete 12 Bandwidth 13 draft-ietf-ccamp-ospf-availability-extension-10.txt 15 Abstract 17 A network may contain links with variable discrete bandwidth, e.g., 18 copper, radio, etc. The bandwidth of such links may change 19 discretely in reaction to changing external environment. 20 Availability is typically used for describing such links during 21 network planning. This document defines a new type of the 22 Generalized Switching Capability-specific information (SCSI) TLV to 23 extend the Generalized Multi-Protocol Label Switching (GMPLS) Open 24 Shortest Path First (OSPF) routing protocol. The extension can be 25 used for route computation in a network that contains links with 26 variable discrete bandwidth. Note, this document only covers the 27 mechanisms by which the availability information is distributed. The 28 mechanisms by which availability information of a link is determined 29 and the use of the distributed information for route computation are 30 outside the scope of this document. It is intended that technology- 31 specific documents will reference this document to describe specific 32 uses. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on February 8, 2018. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction ................................................ 3 75 2. Overview .................................................... 4 76 3. TE Metric Extension to OSPF-TE............................... 4 77 3.1. Availability SCSI-TLV................................... 4 78 3.2. Processing Procedures................................... 5 79 4. Security Considerations...................................... 6 80 5. IANA Considerations ......................................... 6 81 6. References .................................................. 7 82 6.1. Normative References.................................... 7 83 6.2. Informative References.................................. 7 84 7. Acknowledgments ............................................. 8 86 Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC-2119 [RFC2119]. 91 The following acronyms are used in this draft: 93 GMPLS Generalized Multi-Protocol Label Switching 95 LSA Link State Advertisement 97 ISCD Interface Switching Capability Descriptor 99 LSP Label Switched Path 101 OSPF Open Shortest Path First 103 PSN Packet Switched Network 105 SCSI Switching Capability-specific information 107 SNR Signal-to-noise Ratio 109 SONET-SDH Synchronous Optical Network - Synchronous Digital 110 Hierarchy 112 SPF Shortest Path First 114 TE Traffic Engineering 116 TLV Type Length Value 118 1. Introduction 120 Some data plane technologies, e.g., microwave, and copper, allow 121 seamless change of maximum physical bandwidth through a set of known 122 discrete values. The parameter, availability, as described in 123 [G.827], [F.1703] and [P.530] is often used to describe the link 124 capacity. The availability is a time scale, representing a proportion 125 of the operating time that the requested bandwidth is ensured. To 126 set up an LSP across these links, availability information is 127 required by the nodes to verify the bandwidth before making a 128 bandwidth reservation. Assigning different availability classes 129 over such links provides for a more efficient planning of link 130 capacity to support different types of services. The link 131 availability information will be determined by the operator and 132 statically configured. It will usually be determined from the 133 availability requirements of the services expected to be carried on 134 the LSP. For example, voice service usually needs "five nines" 135 availability, while non-real time services may adequately perform at 136 four or three nines availability. For the route computation, both 137 the availability information and the bandwidth resource information 138 are needed. Since different service types may need different 139 availability guarantees, multiple pairs 140 may be required to be associated with a link. 142 In this document, a new type of the Generalized SCSI TLV, 143 Availability TLV is defined. It is intended that technology-specific 144 documents will reference this document to describe specific uses. 145 The signaling extension to support links with discrete bandwidth is 146 defined in [ETPAI]. 148 2. Overview 150 A node which has link(s) with variable bandwidth attached should 151 include < availability, bandwidth> information list in its OSPF 152 Traffic Engineering (TE) LSA messages. The list provides the mapping 153 between the link nominal bandwidth and its availability level. This 154 information is used for path calculation by the node(s). The setup 155 of a Label Switched Path requires this information to be flooded in 156 the network and used by the nodes or the PCE for the path 157 computation. In this document, a new type of the Generalized SCSI 158 TLV, Availability TLV is defined. The computed path can then be 159 provisioned via the signaling protocol [ETPAI]. 161 Note, the mechanisms described in this document only distribute 162 availability information. The methods for measuring the information 163 or using the information for route computation are outside the scope 164 of this document. 166 3. TE Metric Extension to OSPF-TE 168 3.1. Availability SCSI-TLV 170 The Generalized SCSI is defined in [GSCSI]. The Availability TLV 171 defined in this document is a new type of Generalized SCSI-TLV. The 172 Availability SCSI-TLV can be included for one or more times. The 173 Availability SCSI-TLV has the following format: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Availability level | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | LSP Bandwidth at Availability level n | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Type: 0x01, 16 bits. 186 Length: A 16 bits field that expresses the length of the TLV in 187 bytes. 189 Availability level: 32 bits 191 This field is a 32-bit IEEE floating point number which describes 192 the decimal value of availability guarantee of the switching 193 capability in the Interface Switching Capability Descriptor (ISCD) 194 [RFC4202] object. The value MUST be less than 1. The Availability 195 level is usually expressed in the value of 196 0.99/0.999/0.9999/0.99999. 198 LSP Bandwidth at Availability level n: 32 bits 200 This field is a 32-bit IEEE floating point number which describes 201 the LSP Bandwidth for the Availability level represented in the 202 Availability field. The units are bytes per second. 204 3.2. Processing Procedures 206 A node advertising an interface with a Switching Capability which 207 supports variable bandwidth attached SHOULD contain one or more 208 Availability SCSI-TLVs in its OSPF TE LSA messages. Each 209 Availability SCSI-TLV provides the information about how much 210 bandwidth a link can support for a specified availability. This 211 information MAY be used for path calculation by the node(s). 213 The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching 214 Capability field values that have not been defined to support the 215 Availability SCSI-TLV. Non-supporting nodes would see such as a 216 malformed ISCD/LSA. 218 Absence of the Availability SCSI-TLV in an ISCD containing Switching 219 Capability field values that have been defined to support the 220 Availability SCSI-TLV, SHALL be interpreted as representing fixed- 221 bandwidth link with the highest availability value. 223 Only one Availability SCSI-TLV for the specific availability level 224 SHOULD be sent. If multiple are present, only the first Availability 225 SCSI-TLV for an availability level carried in the same ISCD SHALL be 226 processed. 228 4. Security Considerations 230 This document does not introduce security issues beyond those 231 discussed in [RFC4203]. As with [RFC4203], it specifies the content 232 of an Opaque LSAs in OSPFv2. As Opaque LSAs are not used for 233 Shortest Path First (SPF) computation or normal routing, the 234 extensions specified here have no direct effect on IP routing. 235 Tampering with GMPLS TE LSAs may have an impact on the ability to 236 set up connections in the underlying data plane network. As the 237 additional availability information may represent information that 238 an operator may wish to keep private, consideration should be given 239 to securing this information. [RFC3630] notes that the security 240 mechanisms described in [RFC2328] apply to Opaque LSAs carried in 241 OSPFv2. An analysis of the security of OSPF is provided in 242 [RFC6863] and applies to the extensions to OSPF as described in this 243 document. Any new mechanisms developed to protect the transmission 244 of information carried in Opaque LSAs will also automatically 245 protect the extensions defined in this document. 247 Please refer to [RFC5920] for details on security threats; defensive 248 techniques; monitoring, detection, and reporting of security 249 attacks; and requirements. 251 5. IANA Considerations 253 This document introduces a new type for availability of the 254 Generalized SCSI-TLV of the TE Link TLV in the TE Opaque LSA for 255 OSPF v2. Technology-specific documents will reference this document 256 to describe specific use of this Availability SCSI-TLV. 258 IANA has created a registry called the "Generalized SCSI (Switching 259 Capability Specific Information) TLVs Types" registry. The registry 260 is needed to be updated to include the Availability SCSI-TLV. This 261 document proposes a suggested value for the Availability SCSI-TLV; 262 it is requested that the suggested value be granted by IANA. 264 Type Description Reference 265 --- ------------------ ----------- 267 0x01 Availability [This ID] 269 The registration procedure for this registry is Standards Action as 270 defined in [RFC8126]. 272 6. References 274 6.1. Normative References 276 [GSCSI] Ceccarelli, D. and Berger, L., "Generalized Routing 277 Interface Switching Capability Descriptor Switching 278 Capability Specific Information", Work in Progress, 279 January, 2017. 281 [RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing 282 Extensions in Support of Generalized Multi-Protocol Label 283 Switching (GMPLS)", RFC 4202, October 2005. 285 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 286 in Support of Generalized Multi-Protocol Label Switching 287 (GMPLS)", RFC 4203, October 2005. 289 6.2. Informative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", RFC 2119, March 1997. 294 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 296 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 297 (TE) Extensions to OSPF Version 2", RFC 3630, September 298 2003. 300 [RFC8126] Cotton,M. and Leiba,B., and Narten T., "Guidelines for 301 Writing an IANA Considerations Section in RFCs", 302 RFC 8126, June 2017. 304 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 305 Networks", RFC 5920, July 2010. 307 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 308 According to the Keying and Authentication for Routing 309 Protocols (KARP) Design Guide", RFC 6863, March 2013. 311 [G.827] ITU-T Recommendation, "Availability performance parameters 312 and objectives for end-to-end international constant bit- 313 rate digital paths", September, 2003. 315 [F.1703] ITU-R Recommendation, "Availability objectives for real 316 digital fixed wireless links used in 27 500 km 317 hypothetical reference paths and connections", January, 318 2005. 320 [P.530] ITU-R Recommendation," Propagation data and prediction 321 methods required for the design of terrestrial line-of- 322 sight systems", February, 2012 324 [ETPAI] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 325 "Ethernet Traffic Parameters with Availability 326 Information", Work in Progress, August, 2016 328 7. Acknowledgments 330 The authors would like to thank Acee Lindem, Daniele Ceccarelli, Lou 331 Berger for their comments on the document. 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 ZTE 352 Email: gregimirsky@gmail.com 354 Alessandro D'Alessandro 355 Telecom Italia S.p.A 357 Email: alessandro.dalessandro@telecomitalia.it 359 Himanshu Shah 360 Ciena Corp. 361 3939 North First Street 362 San Jose, CA 95134 363 US 365 Email: hshah@ciena.com