idnits 2.17.00 (12 Aug 2021) /tmp/idnits9585/draft-ong-ccamp-gmpls-ospf-sdh-00.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 ([BA-TLV]), 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 == Line 235 has weird spacing: '...ensions for G...' -- The document date (Oct 18, 2010) is 4226 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 71, but not defined == Missing Reference: 'G.7715' is mentioned on line 75, but not defined == Missing Reference: 'G.7715.1' is mentioned on line 75, but not defined == Missing Reference: 'RFC4606' is mentioned on line 100, but not defined == Unused Reference: 'RFC3630' is defined on line 228, 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 (~~), 8 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: April 18, 2011 6 Oct 18, 2010 8 Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) 9 Control of SONET/SDH Networks 10 draft-ong-ccamp-gmpls-ospf-sdh-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 12, 2011. 35 Abstract 37 This draft defines an optimization for bandwidth advertisement for 38 SONET/SDH that removes the need to carry multiple copies of the ISCD 39 sub-TLV and has been designed to be consistent with the work on 40 Technology Agnostic OSPF Traffic Engineering Extensions for 41 Generalized MPLS (GMPLS) [BA-TLV]. 43 These formats are based on previous experience prototyping and 44 testing control plane for ASON networks and are proposed for 45 adoption as a Standards Track RFC for support of ASON routing. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Optimization of bandwidth advertisement for SONET/SDH. . . . . 3 57 2.1. Requirements for Multi-layer SONET/SDH Links . . . . . . . 3 58 2.2. Bandwidth Accounting Sub-TLV for SONET/SDH. . . . . . . . 4 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. Normative References. . . . . . . . . . . . . . . . . . . . 6 64 6.2. Informative References. . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 7 68 1. Introduction 70 The ITU-T defines the architecture of the Automatically Switched 71 Optical Network (ASON) in [G.8080]. 73 [RFC4258] details the routing requirements for the GMPLS suite of 74 routing protocols to support the capabilities and functionality of 75 ASON control planes identified in [G.7715] and in [G.7715.1]. 77 [RFC4652] evaluates the IETF Link State Routing Protocols against the 78 requirements identified in [RFC4258]. Section 7.1 of [RFC4652] 79 summarizes the capabilities to be provided by OSPFv2 [RFC2328] in 80 support of ASON routing. [RFC5787] is an Experimental RFC that 81 defines extensions to OSPFv2 to support these requirements. It 82 notes that the Interface Switching Capability Descriptor may 83 be included for each layer of a multi-layer link [RFC4202] to meet 84 ASON needs. However, for some types SONET/SDH links there can be 85 several data plane layers supported by a single link, and as a 86 result a need to carry several copies of the ISCD. 88 This draft defines the application of the Bandwidth Accounting 89 sub-TLV defined in [BA-TLV] for SONET/SDH, 90 to address the issues identified above. 92 2. Optimization of bandwidth advertisement for SONET/SDH 94 2.1 Requirements for Multi-layer SONET/SDH Links 96 [RFC4652] notes that in the ASON context, bandwidth accounting 97 representations are possible, taking the form of a set of tuples 98 , and that this 99 representation may also require definition of additional signal 100 types (from those defined in [RFC4606]) to represent support of 101 contiguously concatenated signals, 102 i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. 104 It notes that the ISCD defined in [RFC4202] can be used to 105 support ASON without requiring any bandwidth accounting 106 change from an LSR perspective. However, the ISCD defined 107 in [RFC4202} must be advertised once per signal type 108 (identified by the Minimum Reservable Bandwidth value) in 109 order to provide an accurate advertisement of bandwidth 110 for each signal. For SONET/SDH links, it is common to support 111 4-5 signal types (e.g., STS-1, 3c, 12c, 48c and 192c) at once, 112 and advertisement of 4-5 ISCD sub-TLVs would consume about 113 200 bytes as compared to 20-30 bytes for a tuple format. 115 Most of the ISCD bytes are required to advertise 8 levels of 116 priority. We believe this overhead can be reduced as (a) ASON 117 specifications do not identify priority as an ASON service; and 118 (b) TDM networks generally to not support preemption priority 119 and do not require 8 levels of priority. 121 2.2. Bandwidth Accounting Sub-TLV for SONET/SDH 123 [BA-TLV] defines a Bandwidth 124 Accounting Sub-TLV that can be used to carry SONET/SDH bandwidth 125 availability at multiple link component signal 126 types as supplementary information to the ISCD sub-TLV. 128 When multiple SONET/SDH signal types are advertised, a single ISCD 129 is given for the smallest bandwidth signal type and the BA sub-TLV 130 is also advertised to provide compact bandwidth availability 131 advertisement for all signal types. 133 The type used for the sub-TLV is TBD. 135 [BA-TLV] defines this format: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Switching Cap | Encoding | Reserved | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Service Type | M | T.S. Flags | Reserved |Prior| 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Bandwidth | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Service Type | M | T.S. Flags | Reserved |Prior| 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Bandwidth | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Service Type | M | T.S. Flags | Reserved |Prior| 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Bandwidth | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 ~ ... ~ 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Service Type | M | T.S. Flags | Reserved |Prior| 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Bandwidth | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 For SONET/SDH networks, the Switching Capability field and the 162 Encoding field MUST take the following values: Switching 163 Capability (8 bits)=100 (TDM). Encoding (8 bits)=5 (Sonet/SDH). 165 If no priority is supported, just the 0 priority MUST be advertised. 167 Service Type (8 bits) takes values as below for 168 SONET/SDH Signal Type: 170 Value Type (Elementary Signal) 171 ----- ------------------------ 172 TBD STS-1 SPE / VC-3 173 TBD STS-3c SPE / VC-4 174 TBD STS-12c SPE/VC-4-4c 175 TBD STS-48c SPE/VC-4-16c 176 TBD STS-192c SPE/VC-4-64c 178 Bandwidth (32 bits) is used to specify the number of identical 179 unallocated timeslots per Service 180 Type and per TE Link. As such, the initial value(s) of this TLV 181 indicates the total capacity in terms of number of timeslots per TE 182 link. The service type included in the BW sub-TLV is specific to 183 the layer link being reported and is not derived from some other 184 signal type (e.g. STS-48c is not announced as 16 x STS-3c). 186 For instance on an OC-192/STM-64 interface the bandwidth for 187 service type STS-3c SPE/VC-4 may be initially equal to 64, and 188 the bandwidth for service type STS-48c SPE/VC-4-16c may be equal to 189 4 depending on the interface capabilities. Once one timeslot is 190 occupied by being allocated for a connection at the same or a larger 191 service type or being blocked due to the allocation of part of 192 the timeslot for a connection at a smaller service type, the 193 bandwidth is decreased by the number of timeslots 194 this connection implies. 196 3. IANA Considerations 198 IANA will allocate codepoints for the Service Type of the 199 Bandwidth Availability sub-TLV for SONET/SDH from the 200 standard range. Five Service Type values are requested. 202 4. Security Considerations 204 This document defines an optimization for SONET/SDH link bandwidth 205 advertisement consistent with the requirements in [RFC4258] and 206 [RFC4652]. No additional security issues are identified. 208 5. Acknowledgements 210 The authors would like to thank the following OIF members for their 211 comments and support for this document: 213 Richard Graveman (Department of Defense) 214 Hans-Martin Foisel (Deutsche Telekom) 215 Thierry Marcot (France Telecom) 216 Evelyne Roch (Nortel Networks) 217 Jonathan Sadler (Tellabs) 218 Yoshiaki Sone (NTT Corporation) 219 Takehiro Tsuritani (KDDI R&D Laboratories) 221 6. References 223 6.1. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328,April 1998. 228 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 229 (TE) Extensions to OSPF Version 2", RFC 3630, 230 September 2003. 231 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 232 Support of Generalized Multi-Protocol Label Switching 233 (GMPLS)", RFC 4202,February 2005. 234 [BA-TLV] D. Ceccarelli, et al, " Technology Agnostic OSPF Traffic 235 Engineering Extensions for Generalized MPLS (GMPLS)", 236 draft-bccdg-ccamp-gmpls-ospf-agnostic-00.txt, Oct 2010. 238 6.2. Informative References 240 [RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocol Extensions 241 for ASON Routing," RFC 5787, March 2010. 242 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 243 Label Switching (GMPLS) Routing for the Automatically 244 Switched Optical Network (ASON)", RFC 4258, November 2005. 245 [RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D. 246 Ward, "Evaluation of Existing Routing Protocols against 247 Automatic Switched Optical Network (ASON) Routing 248 Requirements", RFC 4652, February 2006. 250 Authors' Addresses 252 Lyndon Ong 253 Ciena 254 P.O.Box 308 255 Cupertino CA 95015 256 USA 258 Phone: +1 408 962 4929 259 Email: lyong@ciena.com 261 Andrew Malis 262 Verizon 263 117 West St. 264 Waltham, MA 02451 265 USA 267 Email: andrew.g.malis@verizon.com 268 Phone: +1 781 466 2362 270 Remi Theillaud 271 Marben Products 272 176 rue Jean Jaures 273 Puteaux 92800 274 France 276 Email: remi.theillaud@marben-products.com 278 Copyright Notice 280 Copyright (c) 2010 IETF Trust and the persons identified as the 281 document authors. All rights reserved. 283 This document is subject to BCP 78 and the IETF Trust's Legal 284 Provisions Relating to IETF Documents 285 (http://trustee.ietf.org/license-info) in effect on the date of 286 publication of this document. Please review these documents 287 carefully, as they describe your rights and restrictions with 288 respect to this document.