idnits 2.17.1 draft-ietf-ccamp-ospf-availability-extension-06.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 19, 2016) is 2800 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 240, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) 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 Ericsson 5 A.D'Alessandro 6 Telecom Italia S.p.A 7 H. Shah 8 Ciena 9 Expires: February 2017 August 19, 2016 11 OSPF-TE Link Availability Extension for Links with Variable Discrete 12 Bandwidth 13 draft-ietf-ccamp-ospf-availability-extension-06.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 introduces an optional ISCD 22 Availability sub-TLV to extend the Open Shortest Path First (OSPF) 23 Generalized Multi-Protocol Label Switching (GMPLS). This extension 24 can be used for route computation in a network that contains links 25 with variable discrete bandwidth. 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." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on February 19, 2016. 49 Copyright Notice 51 Copyright (c) 2016 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 OSPF Routing Protocol........................... 4 69 3.1. ISCD Availability sub-TLV............................... 4 70 3.2. Signaling Process....................................... 5 71 4. Security Considerations...................................... 5 72 5. IANA Considerations ......................................... 6 73 6. References .................................................. 6 74 6.1. Normative References.................................... 6 75 6.2. Informative References.................................. 6 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 GMPLS Generalized Multi-Protocol Label Switching 88 LSA Link State Advertisement 90 ISCD Interface Switching Capacity Descriptor 92 LSP Label Switched Path 94 OSPF Open Shortest Path First 96 PSN Packet Switched Network 98 SNR Signal-to-noise Ratio 100 SONET-SDH Synchronous Optical Network - Synchronous Digital 101 Hierarchy 103 SPF Shortest Path First 105 1. Introduction 107 Some data communication technologies, e.g., microwave, and copper, 108 allow seamless change of maximum physical bandwidth through a set of 109 known discrete values. The parameter availability [G.827], [F.1703], 110 [P.530] is often used to describe the link capacity during network 111 planning. The availability is a time scale, which is a proportion of 112 the operating time that the requested bandwidth is ensured. 113 Assigning different availability classes to different types of 114 service over such kind of links provides more efficient planning of 115 link capacity. To set up an LSP across these links, availability 116 information is required for the nodes to verify bandwidth 117 satisfaction and make bandwidth reservation. The availability 118 information should be inherited from the availability requirements 119 of the services expected to be carried on the LSP. For example, 120 voice service usually needs "five nines" availability, while non- 121 real time services may adequately perform at four or three nines 122 availability. Since different service types may need different 123 availabilities guarantees, multiple pairs 124 may be required when signaling. The signaling extension for links 125 with discrete bandwidth is defined in [ETPAI]. 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. 132 2. Overview 134 A node which has link(s) with variable bandwidth attached should 135 include a information list in its OSPF TE 136 LSA messages. The list provides the mapping between the link nominal 137 bandwidth and its availability level. This information is used for 138 path calculation by the node(s).The setup of a Label Switched Path 139 requires this piece of information to be flooded in the network and 140 used by the nodes or the PCE for the path computation. The computed 141 path can then be provisioned via the signaling protocol. 143 For links with variable discrete bandwidth, Availability information 144 is needed to be carried by the signaling for a better link bandwidth 145 utilization. Extensions to RSVP-TE can be found in [ETPAI]. 147 3. Extension to OSPF-TE 149 3.1. ISCD Availability sub-TLV 151 The ISCD sub-TLV is defined in Section 1.4 of [RFC4203]. The ISCD 152 Availability sub-TLV is defined in this document as a sub-TLV of 153 ISCD. The Switching Capability specific information field of ISCD 154 MAY include one or more ISCD Availability sub-TLV(s). The ISCD 155 Availability sub-TLV has the following format: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Availability level | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | LSP Bandwidth at Availability level n | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Type: TBA by IANA, suggested value is 0x01, 16 bits; 168 Length: A 16 bits field that expresses the length of the TLV in 169 bytes; 171 Availability level: 32 bits 173 This field is a 32-bit IEEE floating point number which 174 describes the decimal value of availability guarantee of the 175 switching capability in the ISCD object. The value MUST be 176 less than 1. The Availability level is usually expressed in 177 the value of 0.99/0.999/0.9999/0.99999. 179 LSP Bandwidth at Availability level n: 32 bits 181 This field is a 32-bit IEEE floating point number which 182 describes the LSP Bandwidth at a certain Availability level 183 which was described in the Availability field. The units are 184 bytes per second. 186 3.2. Processing Procedures 188 A node which has link(s) with variable bandwidth attached SHOULD 189 contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA 190 messages. Each ISCD Availability sub-TLV provides the information 191 about how much bandwidth a link can support for a specified 192 availability. This information SHOULD be used for path calculation 193 by the node(s). 195 A node that doesn't support ISCD Availability sub-TLV SHOULD ignore 196 ISCD Availability sub-TLV. If a node who supports ISCD Availability 197 sub-TLVs doesn't receive the TLV, it indicates that the link is with 198 fixed bandwidth, and the availability can be interpreted as the 199 highest availability value, e.g., five nines. It's legal to send 200 multiple ISCD Availability sub-TLVs for the same availability level. 202 4. Security Considerations 204 This document extends [RFC4203]. As with [RFC4203], it specifies 205 the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used 206 for Shortest Path First (SPF) computation or normal routing, the 207 extensions specified here have no direct effect on IP routing. 208 Tampering with GMPLS TE LSAs may have an effect on the underlying 209 transport (optical and/or Synchronous Optical Network - Synchronous 210 Digital Hierarchy (SONET-SDH)) network. [RFC3630] notes that the 211 security mechanisms described in [RFC2328] apply to Opaque LSAs 212 carried in OSPFv2. An analysis of the security of OSPF is provided 213 in [RFC6863] and applies to the extensions to OSPF as described in 214 this document. Any new mechanisms developed to protect the 215 transmission of information carried in Opaque LSAs will also 216 automatically protect the extensions defined in this document. 218 Please refer to [RFC5920] for details on security threats; defensive 219 techniques; monitoring, detection, and reporting of security attacks; 220 and requirements. 222 5. IANA Considerations 224 This document introduces an Availability sub-TLV of the ISCD sub-TLV 225 of the TE Link TLV in the TE Opaque LSA for OSPF v2. IANA will 226 created and maintain a new sub-registry, the "Types for sub-TLV of 227 Interface Switching Capability Descriptor" registry under the "Open 228 Shortest Path First (OSPF) Traffic Engineering TLVs" registry, see 229 http://www.iana.org/assignments/ospf-traffic-eng-tlvs. 231 This document proposes a suggested value for the Availability sub- 232 TLV; it is recommended that the suggested value be granted by IANA. 234 Type Description Reference 236 --- ------------------ ----------- 238 0 Reserved [This ID] 240 0x01 Availability [This ID] 242 The registration procedure for this registry is Standards Action as 243 defined in [RFC5226]. 245 6. References 247 6.1. Normative References 249 [RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing 250 Extensions in Support of Generalized Multi-Protocol Label 251 Switching (GMPLS)", RFC 4202, October 2005. 253 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 254 in Support of Generalized Multi-Protocol Label Switching 255 (GMPLS)", RFC 4203, October 2005. 257 6.2. Informative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", RFC 2119, March 1997. 262 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 264 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 265 (TE) Extensions to OSPF Version 2", RFC 3630, September 266 2003. 268 [RFC5226] Narten,T. and H. Alvestrand, "Guidelines for Writing an 269 IANA Considerations Section in RFCs", RFC 5226, May 2008. 271 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", 272 RFC 5920, July 2010. 274 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 275 According to the Keying and Authentication for Routing 276 Protocols (KARP) Design Guide", RFC 6863, March 2013. 278 [G.827] ITU-T Recommendation, "Availability performance parameters 279 and objectives for end-to-end international constant bit- 280 rate digital paths", September, 2003. 282 [F.1703] ITU-R Recommendation, "Availability objectives for real 283 digital fixed wireless links used in 27 500 km 284 hypothetical reference paths and connections", January, 285 2005. 287 [P.530] ITU-R Recommendation," Propagation data and prediction 288 methods required for the design of terrestrial line-of- 289 sight systems", February, 2012 291 [ETPAI] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 292 "Ethernet Traffic Parameters with Availability 293 Information", Work in Progress, June, 2015 295 7. Acknowledgments 297 The authors would like to thank Acee Lindem, Daniele Ceccarelli, Lou 298 Berger for their comments on the document. 300 Authors' Addresses 301 Hao Long 302 Huawei Technologies Co., Ltd. 303 No.1899, Xiyuan Avenue, Hi-tech Western District 304 Chengdu 611731, P.R.China 306 Phone: +86-18615778750 307 Email: longhao@huawei.com 309 Min Ye 310 Huawei Technologies Co., Ltd. 311 No.1899, Xiyuan Avenue, Hi-tech Western District 312 Chengdu 611731, P.R.China 314 Email: amy.yemin@huawei.com 316 Greg Mirsky 317 Ericsson 319 Email: gregory.mirsky@ericsson.com 321 Alessandro D'Alessandro 322 Telecom Italia S.p.A 324 Email: alessandro.dalessandro@telecomitalia.it 326 Himanshu Shah 327 Ciena Corp. 328 3939 North First Street 329 San Jose, CA 95134 330 US 332 Email: hshah@ciena.com