idnits 2.17.1 draft-ietf-ccamp-ospf-availability-extension-04.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 (February 19, 2016) is 2981 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 149, but not defined == Unused Reference: 'RFC4203' is defined on line 219, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'MCOS' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'G.827' is defined on line 251, 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: August 2016 February 19, 2016 11 OSPF Routing Extension for Links with Variable Discrete Bandwidth 12 draft-ietf-ccamp-ospf-availability-extension-04.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 August 19, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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. ISCD Availability sub-TLV............................... 4 68 3.2. Signaling Process....................................... 5 69 4. Security Considerations...................................... 5 70 5. IANA Considerations ......................................... 5 71 6. References .................................................. 5 72 6.1. Normative References.................................... 5 73 6.2. Informative References.................................. 6 74 7. Acknowledgments ............................................. 6 76 Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC-2119 [RFC2119]. 82 The following acronyms are used in this draft: 84 OSPF Open Shortest Path First 86 PSN Packet Switched Network 88 SNR Signal-to-noise Ratio 90 LSP Label Switched Path 91 ISCD Interface Switching Capacity Descriptor 93 LSA Link State Advertisement 95 1. Introduction 97 Some data communication technologies, e.g., microwave, and copper, 98 allow seamless change of maximum physical bandwidth through a set of 99 known discrete values. The parameter availability [G.827, F.1703, 100 P.530] is often used to describe the link capacity during network 101 planning. The availability is a time scale that the requested 102 bandwidth is ensured. Assigning different availability classes to 103 different types of service over such kind of links provides more 104 efficient planning of link capacity. To set up an LSP across these 105 links, availability information is required for the nodes to verify 106 bandwidth satisfaction and make bandwidth reservation. The 107 availability information should be inherited from the availability 108 requirements of the services expected to be carried on the LSP. For 109 example, voice service usually needs ''five nines'' availability, 110 while non-real time services may adequately perform at four or three 111 nines availability. Since different service types may need different 112 availabilities guarantees, multiple pairs 113 may be required when signaling. The signaling extension for links 114 with discrete bandwidth is defined in [ASTE]. 116 For the route computation, the availability information should be 117 provided along with bandwidth resource information. In this document, 118 an extension on Interface Switching Capacity Descriptor (ISCD) 119 [RFC4202] for availability information is defined to support in 120 routing signaling. The extension reuses the reserved field in the 121 ISCD and also introduces an optional Availability sub-TLV. 123 If there is a hop that cannot support the Availability sub-TLV, the 124 Availability sub-TLV should be ignored. 126 2. Overview 128 A node which has link(s) with variable bandwidth attached should 129 contain a information list in its OSPF TE 130 LSA messages. The list provides the information that how much 131 bandwidth a link can support for a specified availability. This 132 information is used for path calculation by the node(s). 134 To setup a label switching path (LSP), a node may collect link 135 information which is spread in OSPF TE LSA messages by network nodes 136 to get know about the network topology, calculate out an LSP route 137 based on the network topology and send the calculated LSP route to 138 signaling to initiate a PATH/RESV message for setting up the LSP. 140 Availability information is required to carry in the signaling 141 message to better utilize the link bandwidth. The signaling 142 extension for availability can be found in [ASTE]. 144 3. Extension to OSPF Routing Protocol 146 3.1. ISCD Availability sub-TLV 148 The Interface Switching Capacity Descriptor (ISCD) sub-TLV is 149 defined in Section 1.4 of [RFC 4203]. The ISCD Availability sub-TLV 150 is defined in this document as a sub-TLV of ISCD. The Switching 151 Capability specific information field of ISCD MAY include one or 152 more ISCD Availability sub-TLV(s). The ISCD Availability sub-TLV has 153 the following format: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Availability level | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | LSP Bandwidth at Availability level n | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Type: 0x01, 16 bits; 166 Length: 16 bits; 168 Availability level: 32 bits 170 This field is a 32-bit IEEE floating point number which 171 describes the decimal value of availability guarantee of the 172 switching capacity in the ISCD object which has the AI value 173 equal to Index of this sub-TLV. The value MUST be less than 174 1. 176 LSP Bandwidth at Availability level n: 32 bits 178 This field is a 32-bit IEEE floating point number which 179 describes the LSP Bandwidth at a certain Availability level 180 which was described in the Availability field. 182 3.2. Signaling Process 184 A node which has link(s) with variable bandwidth attached SHOULD 185 contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA 186 messages. Each ISCD Availability sub-TLV provides the information 187 about how much bandwidth a link can support for a specified 188 availability. This information SHOULD be used for path calculation 189 by the node(s). 191 A node that doesn't support ISCD Availability sub-TLV SHOULD ignore 192 ISCD Availability sub-TLV. 194 4. Security Considerations 196 This document does not introduce new security considerations to the 197 existing OSPF protocol. 199 5. IANA Considerations 201 This document introduces an Availability sub-TLV of the ISCD sub-TLV 202 of the TE Link TLV in the TE Opaque LSA for OSPF v2. This document 203 proposes a suggested value for the Availability sub-TLV; it is 204 recommended that the suggested value be granted by IANA. Initial 205 values are as follows: 207 Type Length Format Description 209 --- ---- ------------------ ----------- 211 0 - Reserved Reserved value 213 0x01 8 see Section 3.2 Availability 215 6. References 217 6.1. Normative References 219 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 220 in Support of Generalized Multi-Protocol Label Switching 221 (GMPLS)", RFC 4203, October 2005. 223 [ASTE] H., Long, M., Ye, Mirsky, G., Alessandro, A., Shah, H., 224 ''Ethernet Traffic Parameters with Availability 225 Information'', Work in Progress, June, 2015 227 6.2. Informative References 229 [RFC2210] Wroclawski, J., ''The Use of RSVP with IETF Integrated 230 Services'', RFC 2210, September 1997. 232 [RFC2119] Bradner, S., ''Key words for use in RFCs to Indicate 233 Requirement Levels'', RFC 2119, March 1997 235 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 236 V.,and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 237 Tunnels", RFC 3209, December 2001. 239 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 240 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 241 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 243 [RFC4202] Kompella, K. and Rekhter, Y. (Editors), ''Routing 244 Extensions in Support of Generalized Multi-Protocol Label 245 Switching (GMPLS)", RFC 4202, October 2005. 247 [MCOS] Minei, I., Gan, D., Kompella, K., and X. Li, "Extensions 248 for Differentiated Services-aware Traffic Engineered 249 LSPs", Work in Progress, June 2006. 251 [G.827] ITU-T Recommendation, ''Availability performance parameters 252 and objectives for end-to-end international constant bit- 253 rate digital paths'', September, 2003. 255 [F.1703] ITU-R Recommendation, ''Availability objectives for real 256 digital fixed wireless links used in 27 500 km 257 hypothetical reference paths and connections'', January, 258 2005. 260 [P.530] ITU-R Recommendation,'' Propagation data and prediction 261 methods required for the design of terrestrial line-of- 262 sight systems'', February, 2012 264 [EN 302 217] ETSI standard, ''Fixed Radio Systems; Characteristics 265 and requirements for point-to-point equipment and 266 antennas'', April, 2009 268 7. Acknowledgments 270 The authors would like to thank Lou Berger for his comments on the 271 document. 273 Authors' Addresses 275 Hao Long 276 Huawei Technologies Co., Ltd. 277 No.1899, Xiyuan Avenue, Hi-tech Western District 278 Chengdu 611731, P.R.China 280 Phone: +86-18615778750 281 Email: longhao@huawei.com 283 Min Ye 284 Huawei Technologies Co., Ltd. 285 No.1899, Xiyuan Avenue, Hi-tech Western District 286 Chengdu 611731, P.R.China 288 Email: amy.yemin@huawei.com 290 Greg Mirsky 291 Ericsson 293 Email: gregory.mirsky@ericsson.com 295 Alessandro D'Alessandro 296 Telecom Italia S.p.A 298 Email: alessandro.dalessandro@telecomitalia.it 300 Himanshu Shah 301 Ciena Corp. 302 3939 North First Street 303 San Jose, CA 95134 304 US 306 Email: hshah@ciena.com