idnits 2.17.00 (12 Aug 2021) /tmp/idnits52257/draft-ong-gmpls-ason-routing-exper-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4202], [RFC5787]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 4324 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: 'G.8080' is mentioned on line 77, but not defined == Missing Reference: 'G.7715' is mentioned on line 81, but not defined == Missing Reference: 'G.7715.1' is mentioned on line 81, but not defined == Unused Reference: 'RFC3630' is defined on line 239, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5787 (Obsoleted by RFC 6827) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Ong, Ciena 3 Internet-Draft A. Malis, Verizon 4 Intended status: Standards Track R. Theillaud, Marben Products 5 Expires: January 12, 2011 6 July 12, 2010 8 Optimization of GMPLS BW advertisement for SONET/SDH 9 draft-ong-gmpls-ason-routing-exper-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 12, 2011. 34 Abstract 36 IETF CCAMP WG has defined a set of extensions to OSPFv2 to support 37 ASON routing requirements in [RFC5787]. No extensions were defined 38 for bandwidth advertisement as the Interface Switching Capability 39 Descriptor may optionally be included for each layer of a multi-layer 40 link [RFC4202]. However, for some types SONET/SDH links there can be 41 several data plane layers supported by a single link, and as a 42 result a need to carry several copies of the ISCD. 44 This draft defines an optimization for bandwidth advertisement for 45 SONET/SDH that removes the need to carry multiple copies of the ISCD 46 sub-TLV and has been designed to be consistent with advertisement 47 of bandwidth for OTN. 49 These formats are based on previous experience prototyping and 50 testing control plane for ASON networks and are proposed for 51 adoption as a Standards Track RFC for support of ASON routing. 53 Requirements Language 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Optimization of bandwidth advertisement for SONET/SDH. . . . . 3 63 2.1. Requirements for Multi-layer SONET/SDH Links . . . . . . . 3 64 2.2. Link Component Availability Sub-TLV. . . . . . . . . . . . 4 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Normative References. . . . . . . . . . . . . . . . . . . . 6 70 6.2. Informative References. . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Intellectual Property and Copyright Statements . . . . . . . . . . 7 74 1. Introduction 76 The ITU-T defines the architecture of the Automatically Switched 77 Optical Network (ASON) in [G.8080]. 79 [RFC4258] details the routing requirements for the GMPLS suite of 80 routing protocols to support the capabilities and functionality of 81 ASON control planes identified in [G.7715] and in [G.7715.1]. 83 [RFC4652] evaluates the IETF Link State Routing Protocols against the 84 requirements identified in [RFC4258]. Section 7.1 of [RFC4652] 85 summarizes the capabilities to be provided by OSPFv2 [RFC2328] in 86 support of ASON routing. [RFC5787] is an Experimental RFC that 87 defines extensions to OSPFv2 to support these requirements. It 88 notes that the Interface Switching Capability Descriptor may 89 be included for each layer of a multi-layer link [RFC4202] to meet 90 ASON needs. However, for some types SONET/SDH links there can be 91 several data plane layers supported by a single link, and as a 92 result a need to carry several copies of the ISCD. 94 This draft defines an optimization for bandwidth advertisement for 95 SONET/SDH that removes the need to carry multiple copies of the ISCD 96 sub-TLV and has been designed to be consistent with advertisement 97 of bandwidth for OTN. 99 2. Optimization of bandwidth advertisement for SONET/SDH 101 2.1 Requirements for Multi-layer SONET/SDH Links 103 [RFC4652] notes that in the ASON context, bandwidth accounting 104 representations are possible, taking the form of a set of tuples 105 , and that this 106 representation may also require definition of additional signal 107 types (from those defined in [RFC4606]) to represent support of 108 contiguously concatenated signals, 109 i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. 111 It notes that the ISCD defined in [RFC4202] can be used to 112 support ASON without requiring any bandwidth accounting 113 change from an LSR perspective. However, the ISCD defined 114 in [RFC4202} must be advertised once per signal type 115 (identified by the Minimum Reservable Bandwidth value) in 116 order to provide an accurate advertisement of bandwidth 117 for each signal. For SONET/SDH links, it is common to support 118 4-5 signal types (e.g., STS-1, 3c, 12c, 48c and 192c) at once, 119 and advertisement of 4-5 ISCD sub-TLVs would consume about 120 200 bytes as compared to 20-30 bytes for a tuple format. 122 Most of the ISCD bytes are required to advertise 8 levels of 123 priority. We believe this overhead can be reduced as (a) ASON 124 specifications do not identify priority as an ASON service; and 125 (b) TDM networks generally to not support preemption priority 126 and do not require 8 levels of priority. 128 2.2. Link Component Availability Sub-TLV 130 A Link Component Availability Sub-TLV is defined that carries an 131 indication of SONET/SDH bandwidth at multiple link component signal 132 types as supplementary information to the ISCD sub-TLV. 134 When multiple SONET/SDH signal types are advertised, a single ISCD 135 is given for the smallest bandwidth signal type and the LCA sub-TLV 136 is also advertised to provide compact bandwidth availability 137 advertisement for all signal types. 139 The type used for the sub-TLV is TBD. 141 The following format is defined: 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type (tbd) | Length = 8 + n*4 | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Switching Cap | Encoding | Reserved | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |7|6|5|4|3|2|1|0| Reserved | Reserved | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Signal Type | Number of Unallocated Timeslots | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Signal Type | Number of Unallocated Timeslots | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 // ... // 158 | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Signal Type | Number of Unallocated Timeslots | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Note: n defines the number of signal types supported on this link, 164 and thus has a value greater than or equal to 1. Inherited from 165 [RFC4202], the Switching Capability field and the Encoding field MUST 166 take the following values for Sonet/SDH interfaces: Switching 167 Capability (8 bits)=100 (TDM). Encoding (8 bits)=5 (Sonet/SDH). 169 Priority flags (8 bits): Indicate the priorities supported on the 170 advertised link (0 is highest and 7 is lowest). When the flag is set, 171 the corresponding priority is supported and for each signal type, a 172 "row" (i.e. signal type + unreserved bandwidth field) is included, 173 in order from the highest to the lowest priority. 175 If no priority is supported, just the 0 priority MUST be advertised. 177 Signal Type (8 bits) (as defined in [RFC4606]): 179 Value Type (Elementary Signal) 180 ----- ------------------------ 181 5 STS-1 SPE / VC-3 [RFC4606] 182 6 STS-3c SPE / VC-4 [RFC4606] 183 TBD STS-12c SPE/VC-4-4c 184 TBD STS-48c SPE/VC-4-16c 185 TBD STS-192c SPE/VC-4-64c 187 Number of Unallocated Timeslots (24 bits): 189 Specifies the number of identical unallocated timeslots per Signal 190 Type and per TE Link. As such, the initial value(s) of this TLV 191 indicates the total capacity in terms of number of timeslots per TE 192 link. The signal type included in the BW announcement is specific to 193 the layer link being reported and is not derived from some other 194 signal type (e.g. STS-48c is not announced as 16 x STS-3c). 196 For instance on an OC-192/STM-64 interface either the number of 197 STS-3c SPE/VC-4 unallocated timeslots is initially equal to 64, or 198 the number of STS-48c SPE/VC-4-16c unallocated timeslots is equal to 199 4 or even a combination of both type of signals depending on the 200 interface capabilities. Once one of these timeslots is occupied 201 either by being allocated for a connection at the same or a larger 202 signal type or by being blocked due to the allocation of part of 203 the timeslot for a connection at a smaller signal type, the number 204 of unallocated timeslots is decreased by the number of timeslots 205 this connection implies. 207 3. IANA Considerations 209 IANA will allocate codepoints for the new Link Component 210 Allocation sub-TLV and its associated sub-fields from the 211 standard range. Three new Signal Type values are needed. 213 4. Security Considerations 215 This document defines an optimization for SONET/SDH link bandwidth 216 advertisement consistent with the requirements in [RFC4258] and 217 [RFC4652]. No additional security issues are identified. 219 5. Acknowledgements 221 The authors would like to thank the following OIF members for their 222 comments and support for this document: 224 Richard Graveman (Department of Defense) 225 Hans-Martin Foisel (Deutsche Telekom) 226 Thierry Marcot (France Telecom) 227 Evelyne Roch (Nortel Networks) 228 Jonathan Sadler (Tellabs) 229 Yoshiaki Sone (NTT Corporation) 230 Takehiro Tsuritani (KDDI R&D Laboratories) 232 6. References 234 6.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328,April 1998. 239 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 240 (TE) Extensions to OSPF Version 2", RFC 3630, 241 September 2003. 242 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 243 Support of Generalized Multi-Protocol Label Switching 244 (GMPLS)", RFC 4202,February 2005. 245 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 246 Protocol Label Switching (GMPLS) Extensions for 247 Synchronous Optical Network (SONET) and Synchronous 248 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 250 6.2. Informative References 252 [RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocol Extensions 253 for ASON Routing," RFC 5787, March 2010. 254 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 255 Label Switching (GMPLS) Routing for the Automatically 256 Switched Optical Network (ASON)", RFC 4258, November 2005. 257 [RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D. 258 Ward, "Evaluation of Existing Routing Protocols against 259 Automatic Switched Optical Network (ASON) Routing 260 Requirements", RFC 4652, February 2006. 262 Authors' Addresses 264 Lyndon Ong 265 Ciena 266 P.O.Box 308 267 Cupertino CA 95015 268 USA 270 Phone: +1 408 962 4929 271 Email: lyong@ciena.com 273 Andrew Malis 274 Verizon 275 117 West St. 276 Waltham, MA 02451 277 USA 279 Email: andrew.g.malis@verizon.com 280 Phone: +1 781 466 2362 282 Remi Theillaud 283 Marben Products 284 176 rue Jean Jaures 285 Puteaux 92800 286 France 288 Email: remi.theillaud@marben-products.com 290 Copyright Notice 292 Copyright (c) 2010 IETF Trust and the persons identified as the 293 document authors. All rights reserved. 295 This document is subject to BCP 78 and the IETF Trust's Legal 296 Provisions Relating to IETF Documents 297 (http://trustee.ietf.org/license-info) in effect on the date of 298 publication of this document. Please review these documents 299 carefully, as they describe your rights and restrictions with 300 respect to this document.