idnits 2.17.1 draft-berger-ccamp-swcaps-update-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4202, but the abstract doesn't seem to directly say this. It does mention RFC4202 though, so this could be OK. -- The draft header indicates that this document updates RFC4203, but the abstract doesn't seem to directly say this. It does mention RFC4203 though, so this could be OK. -- The draft header indicates that this document updates RFC3471, but the abstract doesn't seem to directly say this. It does mention RFC3471 though, so this could be OK. -- The draft header indicates that this document updates RFC5307, but the abstract doesn't seem to directly say this. It does mention RFC5307 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3471, updated by this document, for RFC5378 checks: 2000-10-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 20, 2012) is 4358 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 3471, 4202, 4203, 5307 Julien Meuric (France Telecom) 3 Category: Standards Track 4 Expiration Date: November 20, 2012 6 May 20, 2012 8 Revised Definition of The GMPLS Switching Capability and Type Fields 10 draft-berger-ccamp-swcaps-update-01.txt 12 Abstract 14 GMPLS provides control for multiple switching technologies, and 15 hierarchical switching within a technology. GMPLS routing and 16 signaling use common values to indicate switching technology type. 17 These values are carried in routing in the Switching Capability 18 field, and in signaling in the Switching Type field. While the 19 values using in these fields are the primary indicators of the 20 technology and hierarchy level being controlled, the values are 21 not consistently defined and used across the different 22 technologies supported by GMPLS. This document is intended to 23 resolve the inconsistent definition and use of the Switching 24 Capability and Type fields by narrowly scoping the meaning and use 25 of the fields. This document updates any document that uses the 26 GMPLS Switching Capability and Types fields, in particular RFC 27 3471, RFC 4202, RFC 4203, and RFC 5307. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on November 20, 2012 52 Copyright and License Notice 54 Copyright (c) 2012 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 1. Introduction 69 Generalized Multi-Protocol Label Switching (GMPLS) provides control 70 for multiple switching technologies. It also supports hierarchical 71 switching within a technology. The original GMPLS Architecture, per 72 [RFC3945], included support for five types of switching capabilities. 73 An additional type was also been defined in [RFC6002]. The switching 74 types defined in these documents include: 75 1. Packet Switch Capable (PSC) 76 2. Layer-2 Switch Capable (L2SC) 77 3. Time-Division Multiplex Capable (TDM) 78 4. Lambda Switch Capable (LSC) 79 5. Fiber-Switch Capable (FSC) 80 6. Data Channel Switching Capable (DCSC) 82 Support for the original types was defined for routing in [RFC4202], 83 [RFC4203] and [RFC5307], where the types were represented in the 84 Switching Capability (Switching Cap) field. In general, hierarchy 85 within a type is addressed in a type-specific fashion and a single 86 Switching Capability field value is defined per type. The exception 87 to this is PSC which was assigned four values to indicate four levels 88 of hierarchy: PSC-1, PSC-2, PSC-3 and PSC-4. The same values used in 89 routing are defined for signaling in [RFC3471], and are carried in 90 the Switching Type field. Following the IANA registry, we refer to 91 the values used in the routing Switching Capability field and 92 signaling Switching Type field as Switching Types. 94 In general, a Switching Type does not indicate a specific data plane 95 technology, but rather this needs to be inferred from context. For 96 example L2SC was defined to cover Ethernet and ATM, and TDM was 97 defined to cover both SONET/SDH [RFC4606] and G.709 [RFC4328]. The 98 basic assumption was that different technologies of the same type 99 would never operate within the same control, i.e., signaling and 100 routing, domains. 102 The past approach in assignment of Switching Types has proven to be 103 problematic from two perspectives. The first issue is that there are 104 examples of switching technologies were there are different levels of 105 switching that can be performed within the same technology. For 106 example, there are multiple types of Ethernet switching that may 107 occur within a provider network. The second issues is that the 108 Switching Capability field value is used in routing to indicate the 109 format of the Switching Capability-specific information (SCSI) field, 110 and that an implicit mapping of type to SCSI format is impractical 111 for implementations that support multiple switching technologies. 112 These issues led to the introduction of two new types for Ethernet in 113 [RFC6004] and [RFC6060], namely: 114 7. Ethernet Virtual Private Line (EVPL) 115 8. 802_1 PBB-TE 117 An additional value is also envisioned to be assigned in support of 118 G.709v3 by [GMPLS-G709] in order to disambiguate the format of the 119 SCSI field. 121 While a common representation of hierarchy levels within a switching 122 technology certainly fits the design objectives of GMPLS, the 123 definition of multiple PSC Switching Types has also proven to be of 124 little value. Notably, there are no known uses of PSC-2, PSC-3 and 125 PSC-4. 127 This document proposes to resolve such inconsistent definitions and 128 uses of the Switching Types by reducing the scope of the related 129 fields and narrowing their use. In particular this document proposes 130 deprecating the use of the Switching Types as an identifier of 131 hierarchy levels within a switching technology, and limit its use to 132 identification of a per-switching technology SCSI field format. This 133 document also defines, for routing, a generic method for identifying 134 a hierarchy levels within a switching technology. 136 An alternate approach, which is not advocated by this document, is to 137 ensure that Switching Types are assigned for all hierarchy levels 138 within a switching technology as part of any new work, e.g., as part 139 of [GMPLS-G709]. 141 This document updates any document that uses the GMPLS Switching 142 Capability and Switching Type fields, in particular RFCs 3471, 4202, 143 4203, and 5307. 145 1.1. Current Switching Type Definition 147 The Switching Type values are carried in both routing and signaling. 148 Values are identified in the IANA GMPLS Signaling Parameters 149 Switching Type registry, which is currently located at 150 http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- 151 parameters.xml 153 For routing, a common information element is defined to carry 154 switching type values for both OSPF and IS-IS routing protocols in 155 [RFC4202]. Per [RFC4202], switching type values are carried in a 156 Switching Capability (Switching Cap) field in an Interface Switching 157 Capability Descriptor. This information shares a common formatting 158 in both OSPF, as defined by [RFC4203] and in IS-IS, as defined by 159 [RFC5307]: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Switching Cap | Encoding | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Switching Capability-specific information | 169 | (variable) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 and 174 The content of the Switching Capability specific information field 175 depends on the value of the Switching Capability field. 177 Similarly, the Switching Type field is defined as part of a common 178 format for use by GMPLS signaling protocols in [RFC3471] and is used 179 by [RFC3473]: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | LSP Enc. Type |Switching Type | G-PID | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Switching Type: 8 bits 189 Indicates the type of switching that should be performed on a 190 particular link. This field is needed for links that advertise 191 more than one type of switching capability. This field should 192 map to one of the values advertised for the corresponding link 193 in the routing Switching Capability Descriptor ... 195 1.2. Conventions Used In This Document 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 2. Revised Switching Type Definition 203 This document modifies the definition of Switching Type. The 204 definitions are slightly different for routing and signaling and are 205 described in the following sections. 207 2.1. Routing -- Switching Cap Field 209 For routing, i.e., [RFC4202], [RFC4203] and [RFC5307], the following 210 definition should be used for Switching Cap field: 212 The Switching Cap field indicates the type of switching being 213 advertised via GMPLS Switching Type values. A different Switching 214 Type value SHOULD be used for each data plane technology even when 215 those technologies share the same type of multiplexing or 216 switching. For example, Time Division Multiplexing (TDM) 217 technologies that have different multiplexing structures, such as 218 SDH [G.707] and OTN [G.709], should use two different Switching 219 Types. 221 As the format of the Switching Capability specific information 222 field is dependent on the value of this field, a different 223 Switching Type value MUST be used to differentiate between 224 different Switching Capability specific information field formats. 226 This definition does not modify the format of the Interface 227 Switching Capability Descriptor. 229 Note that from a practical standpoint, this means that any time a new 230 switching technology might use a different Switching Capability 231 specific information field format, that a new Switching Type SHOULD 232 be used. 234 2.2. Signaling -- Switching Type Field 236 For signaling, i.e., [RFC3471] which is used by [RFC3473], the 237 following definition should be used for Switching Type field: 239 Indicates the type of switching that should be performed on a 240 particular link via GMPLS Switching Type values. This field maps 241 to one of the values advertised for the corresponding link in the 242 routing Switching Capability Descriptor, see [RFC4203] and 243 [RFC5307]. 245 Note that from a practical standpoint, there is no change in the 246 definition of this field. 248 2.3. Assigned Switching Types 250 This document deprecates the following Switching Types: 252 Value Name 253 2 Packet-Switch Capable-2 (PSC-2) 254 3 Packet-Switch Capable-3 (PSC-3) 255 4 Packet-Switch Capable-4 (PSC-4) 257 These values SHOULD NOT be treated as reserved values, i.e., 258 SHOULD NOT be generated and SHOULD be ignored upon receipt. 260 3. Intra-Technology Hierarchy 262 [Authors note: This section is for discussion and may be dropped. 263 Particularly, need to revisit MLN/IACD/XRO implications to ensure 264 there are no gating issues.] 266 Multiple switching technologies support forms of hierarchical 267 switching within a particular data plane technology. As discussed 268 above, GMPLS routing originally envisioned support for such cases for 269 packet networks using PSC-2, 3, 4. In other cases, GMPLS defined 270 support using technology specific mechanisms, for example Signal Type 271 was defined for SONET/SDH, see [RFC4606]. Given that one of the 272 objectives of GMPLS is to generalize control plane protocols, it is 273 reasonable to define a method for supporting hierarchical switching 274 within a particular data plane technology that is not specific to any 275 particular technology. This section defines such a mechanism for 276 routing. No additional mechanism is defined for signaling. 278 In order to support hierarchical switching within a particular data 279 plane technology in routing, this section defines the Intra- 280 Technology Hierarchy, or ITH, field. This field allows for 281 representation of up to 15 levels of hierarchical switching. It, for 282 example, can represent the bottom most level of a multiplexing 283 hierarchy. The ITH field is carried in a portion of the previously 284 defined reserved field of the Interface Switching Capability 285 Descriptor and has the following format: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Switching Cap | Encoding | Reserved | ITH | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 For compatibility reasons, an ITH value of 0 indicates that the ITH 294 field is not being used. The mapping of ITH values to specific 295 levels of hierarchy within a data plane technology is specific to 296 each switching technology and is therefore outside the scope of this 297 document. 299 4. Compatibility 301 This document has two impacts on existing implementations. Both 302 routing and signaling impacts must be considered. 304 For existing implementations, the primary impact is deprecating the 305 use of PSC-2, 3 and 4. At the time of publication of this document, 306 there are no known deployments (or even implementations) that make 307 use of these values so there is no compatibility issues for current 308 routing and signaling implementations. 310 A secondary impact is the use of the previously reserved field of the 311 routing Interface Switching Capability Descriptor. For existing 312 routing implementations, this field should be set to all zeros when 313 generating a Descriptor, and should be ignored on receipt. 314 Furthermore, existing nodes are expected to propagate reserved fields 315 without any modification. Therefore the use of this reserved field 316 is not considered to result in any compatibility issues in routing. 317 As this field is not used in signaling, there are no signaling 318 compatibility issues. 320 5. Security Considerations 322 This document impacts the values carried in a single field in 323 signaling and routing. As no new protocol formats or mechanisms are 324 defined, there are no particular security implications raised by this 325 document. 327 For a general discussion on MPLS and GMPLS related security issues, 328 see the MPLS/GMPLS security framework [RFC5920]. 330 6. IANA Considerations 332 IANA needs to deprecate and redefine the registry. 334 7. Acknowledgments 336 We thank John Drake for highlighting the current inconsistent 337 definitions associated with the Switching Capability and Type Fields. 338 Daniele Ceccarelli provided valuable feedback on this document. 340 8. References 342 8.1. Normative References 344 [RFC2119] Bradner, S., "RFC Key Words Key words for use in RFCs to 345 Indicate Requirement Levels", RFC 2119, March 1997. 347 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 348 (GMPLS) Signaling Functional Description", RFC 3471, 349 January 2003. 351 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in 352 Support of Generalized Multi-Protocol Label Switching 353 (GMPLS)", RFC 4202, October 2005. 355 [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support 356 of Generalized Multi-Protocol Label Switching (GMPLS)", 357 RFC 4203, October 2005. 359 [RFC5307] Kompella, K., Rekhter, Y., "IS-IS Extensions in Support 360 of Generalized Multi-Protocol Label Switching (GMPLS)", 361 RFC 5307, October 2008. 363 8.2. Informative References 365 [G.707] ITU-T Recommendation G.707/Y.1322 (2007), "Network node 366 interface for the synchronous digital hierarchy (SDH)". 368 [G.709] ITU-T Recommendation G.709/Y.1331 (2009), "Interfaces for 369 the Optical Transport Network (OTN)". 371 [GMPLS-G709] Zhang, F., Li, D., Li, H., Belotti, S., Ceccarelli, 372 D., "Framework for GMPLS and PCE Control of G.709 373 Optical Transport Networks", work in progress, 374 draft-ietf-ccamp-gmpls-g709-framework. 376 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 377 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 378 Engineering (RSVP-TE) Extensions", RFC 3473, January 379 2003. 381 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 382 (GMPLS) Architecture", RFC 3945, October 2004. 384 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 385 Switching (GMPLS) Signaling Extensions for G.709 Optical 386 Transport Networks Control", RFC 4328, January 2006. 388 [RFC4606] Mannie, E., Papadimitriou, D., "Generalized 389 Multi-Protocol Label Switching (GMPLS) Extensions for 390 Synchronous Optical Network (SONET) and Synchronous 391 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 393 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 394 Networks", RFC 5920, July 2010. 396 [RFC6002] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Data 397 Channel Switching Capable (DCSC) and Channel Set Label 398 Extensions", RFC 6002, October 2010. 400 [RFC6004] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Support 401 for Metro Ethernet Forum and G.8011 Ethernet Service 402 Switching", RFC 6004, front 2010. 404 [RFC6060] Fedyk, D., Shah, H., Bitar, N., Takacs, A., "Generalized 405 Multiprotocol Label Switching (GMPLS) Control of 406 Ethernet Provider Backbone Traffic Engineering 407 (PBB-TE)", RFC 6060, March 2011. 409 9. Authors' Addresses 411 Lou Berger 412 LabN Consulting, L.L.C. 413 Phone: +1-301-468-9228 414 Email: lberger@labn.net 416 Julien Meuric 417 France Telecom 418 Research & Development 419 2, avenue Pierre Marzin 420 22307 Lannion Cedex - France 421 Phone: +33 2 96 05 28 28 422 Email: julien.meuric@orange-ftgroup.com 424 Generated on: Fri, May 18, 2012 5:29:08 PM