idnits 2.17.1 draft-ietf-ccamp-ospf-availability-extension-03.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 16, 2015) is 3109 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: 'RFC 4203' is mentioned on line 150, but not defined == Unused Reference: 'RFC4203' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 255, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASTE' Summary: 0 errors (**), 0 flaws (~~), 8 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: April 13, 2016 October 16, 2015 11 OSPF Routing Extension for Links with Variable Discrete Bandwidth 12 draft-ietf-ccamp-ospf-availability-extension-03.txt 14 Abstract 16 A network MAY contain links with variable discrete bandwidth, e.g., 17 copper, radio, etc. The bandwidth of such links may change 18 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 network that contains links with 23 variable discrete 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 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on April 13, 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 .................................................... 3 66 3. Extension to OSPF Routing Protocol........................... 4 67 3.1. Interface Switching Capacity Descriptor................. 4 68 3.2. ISCD Availability sub-TLV............................... 4 69 3.3. Signaling Process....................................... 5 70 4. Security Considerations...................................... 5 71 5. IANA Considerations ......................................... 5 72 6. References .................................................. 5 73 6.1. Normative References.................................... 5 74 6.2. Informative References.................................. 6 75 7. Acknowledgments ............................................. 6 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 89 SNR Signal-to-noise Ratio 91 LSP Label Switched Path 92 ISCD Interface Switching Capacity Descriptor 94 LSA Link State Advertisement 96 1. Introduction 98 Some data communication technologies, e.g., microwave, and copper, 99 allow seamless change of maximum physical bandwidth through a set of 100 known discrete values. The parameter availability [G.827, F.1703, 101 P.530] is often used to describe the link capacity during network 102 planning. The availability is a time scale that the requested 103 bandwidth is ensured. Assigning different availability classes to 104 different types of service over such kind of links provides more 105 efficient planning of link capacity. To set up an LSP across these 106 links, availability information is required for the nodes to verify 107 bandwidth satisfaction and make bandwidth reservation. The 108 availability information should be inherited from the availability 109 requirements of the services expected to be carried on the LSP. For 110 example, voice service usually needs "five nines" availability, 111 while non-real time services may adequately perform at four or three 112 nines availability. Since different service types may need different 113 availabilities guarantees, multiple pairs 114 may be required when signaling. The signaling extension for links 115 with discrete bandwidth is defined in [ASTE]. 117 For the route computation, the availability information should be 118 provided along with bandwidth resource information. In this document, 119 an extension on Interface Switching Capacity Descriptor (ISCD) 120 [RFC4202] for availability information is defined to support in 121 routing signaling. The extension reuses the reserved field in the 122 ISCD and also introduces an optional Availability sub-TLV. 124 If there is a hop that cannot support the Availability sub-TLV, the 125 Availability sub-TLV should be ignored. 127 2. Overview 129 A node which has link(s) with variable bandwidth attached should 130 contain a information list in its OSPF TE 131 LSA messages. The list provides the information that how much 132 bandwidth a link can support for a specified availability. This 133 information is used for path calculation by the node(s). 135 To setup a label switching path (LSP), a node may collect link 136 information which is spread in OSPF TE LSA messages by network nodes 137 to get know about the network topology, calculate out an LSP route 138 based on the network topology and send the calculated LSP route to 139 signaling to initiate a PATH/RESV message for setting up the LSP. 141 Availability information is required to carry in the signaling 142 message to better utilize the link bandwidth. The signaling 143 extension for availability can be found in [ASTE]. 145 3. Extension to OSPF Routing Protocol 147 3.1. Interface Switching Capacity Descriptor 149 The Interface Switching Capacity Descriptor (ISCD) sub-TLV is 150 defined in Section 1.4 of [RFC 4203]. 152 3.2. ISCD Availability sub-TLV 154 The Switching Capability field MAY be PSC-1, LSC. The Switching 155 Capability specific information field MAY include one or more ISCD 156 Availability sub-TLV(s). The ISCD Availability sub-TLV has the 157 following format: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Availability level | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | LSP Bandwidth at Availability level n | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Type: 0x01, 16 bits; 170 Length: 16 bits; 172 Availability level: 32 bits 174 This field is a 32-bit IEEE floating point number which 175 describes the decimal value of availability guarantee of the 176 switching capacity in the ISCD object which has the AI value 177 equal to Index of this sub-TLV. The value MUST be less than 178 1. 180 LSP Bandwidth at Availability level n: 32 bits 182 This field is a 32-bit IEEE floating point number which 183 describes the LSP Bandwidth at a certain Availability level 184 which was described in the Availability field. 186 3.3. Signaling Process 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. 198 4. Security Considerations 200 This document does not introduce new security considerations to the 201 existing OSPF protocol. 203 5. IANA Considerations 205 This document introduces an Availability sub-TLV of the ISCD sub-TLV 206 of the TE Link TLV in the TE Opaque LSA for OSPF v2. This document 207 proposes a suggested value for the Availability sub-TLV; it is 208 recommended that the suggested value be granted by IANA. Initial 209 values are as follows: 211 Type Length Format Description 213 --- ---- ------------------ ----------- 215 0 - Reserved Reserved value 217 0x01 8 see Section 3.2 Availability 219 6. References 221 6.1. Normative References 223 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 224 in Support of Generalized Multi-Protocol Label Switching 225 (GMPLS)", RFC 4203, October 2005. 227 [ASTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 228 "Ethernet Traffic Parameters with Availability 229 Information", Work in Progress, June, 2015 231 6.2. Informative References 233 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 234 Services", RFC 2210, September 1997. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", RFC 2119, March 1997 239 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 240 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 241 Tunnels", RFC 3209, December 2001. 243 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 244 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 245 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 247 [RFC4202] Kompella, K. and Rekhter, Y. (Editors), "Routing 248 Extensions in Support of Generalized Multi-Protocol Label 249 Switching (GMPLS)", RFC 4202, October 2005. 251 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 252 for Differentiated Services-aware Traffic Engineered 253 LSPs", Work in Progress, June 2006. 255 [G.827] ITU-T Recommendation, "Availability performance parameters 256 and objectives for end-to-end international constant bit- 257 rate digital paths", September, 2003. 259 [F.1703] ITU-R Recommendation, "Availability objectives for real 260 digital fixed wireless links used in 27 500 km 261 hypothetical reference paths and connections", January, 262 2005. 264 [P.530] ITU-R Recommendation," Propagation data and prediction 265 methods required for the design of terrestrial line-of- 266 sight systems", February, 2012 268 [EN 302 217] ETSI standard, "Fixed Radio Systems; Characteristics 269 and requirements for point-to-point equipment and 270 antennas", April, 2009 272 7. Acknowledgments 274 The authors would like to thank Lou Berger for his comments on the 275 document. 277 Authors' Addresses 279 Hao Long 280 Huawei Technologies Co., Ltd. 281 No.1899, Xiyuan Avenue, Hi-tech Western District 282 Chengdu 611731, P.R.China 284 Phone: +86-18615778750 285 Email: longhao@huawei.com 287 Min Ye 288 Huawei Technologies Co., Ltd. 289 No.1899, Xiyuan Avenue, Hi-tech Western District 290 Chengdu 611731, P.R.China 292 Email: amy.yemin@huawei.com 294 Greg Mirsky 295 Ericsson 297 Email: gregory.mirsky@ericsson.com 299 Alessandro D'Alessandro 300 Telecom Italia S.p.A 302 Email: alessandro.dalessandro@telecomitalia.it 304 Himanshu Shah 305 Ciena Corp. 306 3939 North First Street 307 San Jose, CA 95134 308 US 310 Email: hshah@ciena.com