idnits 2.17.1 draft-ietf-ccamp-gmpls-dcsc-channel-ext-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4202, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4203, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3945, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3471, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5307, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to mention this, which it should. 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 (January 19, 2010) is 5210 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 (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 3471, 3473, 3945, 4202, 4203, 5307 Don Fedyk (Alcatel-Lucent) 3 Category: Standards Track 4 Expiration Date: July 19, 2010 6 January 19, 2010 8 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and 9 Channel Set Label Extensions 11 draft-ietf-ccamp-gmpls-dcsc-channel-ext-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 19, 2010. 36 Copyright and License Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 This document describes two technology-independent extensions to 54 Generalized Multi-Protocol Label Switching. The first extension 55 defines the new switching type Data Channel Switching Capable. Data 56 Channel Switching Capable interfaces are able to support switching of 57 the whole digital channel presented on single channel interfaces. 58 The second extension defines a new type of generalized label and 59 updates related objects. The new label is called the Generalized 60 Channel_Set Label and allows more than one data plane label to be 61 controlled as part of an LSP. 63 Table of Contents 65 1 Introduction ........................................... 3 66 1.1 Conventions used in this document ...................... 3 67 2 Data Channel Switching ................................. 3 68 2.1 Compatibility .......................................... 4 69 3 Generalized Channel_Set Label Related Formats .......... 4 70 3.1 Generalized Channel_Set LABEL_REQUEST Object ........... 5 71 3.2 Generalized Channel_Set LABEL Object ................... 5 72 3.3 Other Label related Objects ............................ 7 73 3.4 Compatibility .......................................... 8 74 4 IANA Considerations .................................... 8 75 4.1 Data Channel Switching Type ............................ 8 76 4.2 Generalized Channel_Set LABEL_REQUEST Object ........... 8 77 4.3 Generalized Channel_Set LABEL Object ................... 9 78 5 Security Considerations ................................ 9 79 6 References ............................................. 9 80 6.1 Normative References ................................... 9 81 6.2 Informative References ................................. 10 82 7 Acknowledgments ........................................ 11 83 8 Author's Addresses ..................................... 11 85 1. Introduction 87 This document describes two technology independent extensions to 88 Generalized Multi-Protocol Label Switching (GMPLS). Both of these 89 extensions were initially defined in the context of Ethernet 90 services, see [GMPLS-ESVCS] and [GMPLS-MEF-UNI], but are generic in 91 nature and may be useful to any switching technology controlled via 92 GMPLS. 94 The first extension defines a new switching type, which is called 95 Data Channel Switching Capable (DCSC). DCSC interfaces are able to 96 support switching of the whole digital channel presented on single 97 channel interfaces. The second extension defines a new type of 98 generalized label and updates related objects. The new label is 99 called the Generalized Channel_Set Label and allows more than one 100 data plane label to be controlled as part of a GMPLS label-switched 101 path (LSP). 103 1.1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Data Channel Switching 111 Current GMPLS switching types are defined in [RFC3945] and [RFC3471] 112 and support switching at the packet (PSC), frame (L2SC), time-slot 113 (TDM), frequency (LSC) and fiber (FSC) granularities. Parallel 114 definitions for these switching types are also made in [RFC4202], 115 [RFC4203] and [RFC5307]. 117 One type of switching that is not well represented in this current 118 set is switching that occurs when all data received on an ingress 119 port is switched through a network to an egress port. While there 120 are similarities between this level of switching and the "opaque 121 single wavelength" case described in Section 3.5 of [RFC4202], such 122 port-to-port switching is not limited to the optical switching 123 technology implied by the LSC type. FSC is also similar, but it is 124 restricted to fiber ports and also supports multiple data channels 125 within a fiber port. 127 This document defines a new switching type called Data Channel 128 Switching Capable (DCSC). Port switching seems a more intuitive name, 129 but this naming collides with PSC so is not used. DCSC interfaces 130 are able to support switching of the whole digital channel presented 131 on single channel interfaces. Interfaces that inherently support 132 multiple channels, e.g., WDM and channelized TDM interfaces, are 133 specifically excluded from this type. Any interface that can be 134 represented as a single digital channel are included. Examples 135 include concatenated TDM and line encoded interfaces. Framed 136 interfaces may also be included when they support switching on an 137 interface granularity. 139 DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the 140 value TBA (by IANA). The DCSC value is carried in routing protocols 141 in the Interface Switching Capability Descriptor defined in 142 [RFC4202], and used in OSPF [RFC4203] and IS-IS [RFC5307]. These 143 documents are not otherwise modified by this document. 145 The DCSC Switching Type may be used with the Generalized Label 146 Request object, [RFC3473], or the Generalized Channel_Set 147 LABEL_REQUEST Object defined below. Port labels, as defined in 148 [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching 149 Type. 151 2.1. Compatibility 153 Transit and egress nodes that do not support the DCSC Switching Type 154 when receiving a Path message with a Label Request containing the 155 DCSC Switching Type will behave in the same way nodes generally 156 handle the case of an unsupported Switching Type. Specifically, per 157 [RFC3473], such nodes are required to generate a PathErr message, 158 with a "Routing problem/Unsupported Encoding" indication. 160 Ingress nodes initiating a Path message containing a Label Request 161 containing the DCSC Switching Type, receiving such a PathErr 162 messages, then notify the requesting application user as appropriate. 164 3. Generalized Channel_Set Label Related Formats 166 This section defines a new type of generalized label and updates 167 related objects. This section updates the label related definitions 168 of [RFC3473]. The ability to communicate more than one label as part 169 of the same LSP was motivated by the support for the communication of 170 one or more VLAN IDs. Simple concatenation of labels as is done in 171 [RFC4606] was deemed impractical given the large number of VLAN IDs 172 (up to 4096) that may need to be communicated. The formats defined 173 in this section are not technology specific and may be useful for 174 other switching technologies. The LABEL_SET object defined in 175 [RFC3473] serves as the foundation for the defined formats. 177 3.1. Generalized Channel_Set LABEL_REQUEST Object 179 The Generalized Channel_Set LABEL_REQUEST object is used to indicate 180 that the Generalized Channel_Set LABEL Object is to be used with the 181 associated LSP. The format of the Generalized Channel_Set 182 LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST 183 object and uses a C-Type of TBA. 185 3.2. Generalized Channel_Set LABEL Object 187 The Generalized Channel_Set LABEL Object communicates one or more 188 labels, all of which can be used equivalently in the data path 189 associated with a single LSP. The format of the Generalized 190 Channel_Set LABEL Object is based on the LABEL_SET object defined in 191 [RFC3473]. It differs from the the LABEL_SET object in that the full 192 set may be represented in a single object rather than the multiple 193 objects required by the [RFC3473] LABEL_SET object. The object MUST 194 be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST 195 object. The object MUST be processed per [RFC3473]. Make-before- 196 break procedures, see [RFC3209], SHOULD be used when modifying the 197 Channel_Set LABEL object. 199 The format of the Generalized Channel_Set LABEL object is: 201 o Generalized Channel_Set LABEL object: Class = 16, C-Type = TBA (By 202 IANA) 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Channel_Set Sub-Object 1 | 208 | ... | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 : : : 211 : : : 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Channel_Set Sub-Object N | 214 | ... | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The Channel_Set Sub-Object size is measured in bytes and MUST always 218 be a multiple of 4, and at least 4, and has the following format: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Action | Num Subchannels | Label Type | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Subchannel 1 | 226 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | ... | : 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 229 : : : 230 : : : 231 : : : 232 : : : 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Subchannel N | 235 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | ... | Padding | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Action: 8 bits 241 See [RFC3471] for definition of actions. Range actions SHOULD 242 be used when possible to minimize the size of the Channel_Set 243 LABEL Object. 245 Number of Subchannels: 10 bits 247 Indicates the number of subchannels carried in the sub-object. 248 When the number of subchannels required exceeds the limit of 249 the field, i.e., 1024, multiple Channel_Set Sub-Objects MUST be 250 used. Note that the size of the sub-object may result in a 251 Path message being larger than a single unfragmented IP packet. 252 See section 4.4 for an example of how this case may be handled. 254 A value of zero (0) has special meaning and MAY be used in 255 either the LABEL or UPSTREAM_LABEL object. A value of zero (0) 256 is used in a LABEL or UPSTREAM_LABEL object to indicate that 257 the subchannel(s) used in the corresponding (downstream or 258 upstream) direction MUST match the subchannel(s) carried in the 259 reverse directions label object. When value of zero (0) is 260 used, no Subchannels are included in the Channel_Set Sub-Object 261 and only one Channel_Set Sub-Object may be present. The zero 262 (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL 263 objects of the same LSP. Note that unacceptable label values 264 continue to be handled according to [RFC3209] and [RFC3473], 265 i.e., they result in PathErr or ResvErr messages with a 266 "Routing problem/Unacceptable label value" indication. For 267 example, in the case where a Resv message containing a zero (0) 268 in both the LABEL and UPSTREAM_LABEL objects is received, the 269 node would generate a ResvErr message. 271 Label Type: 14 bits 273 See [RFC3473] for a description of this field. 275 Subchannel: Variable 277 See [RFC3471] for a description of this field. Note that this 278 field might not be 32 bit aligned. 280 Padding: Variable 282 Padding is used to ensure that the length of a Channel_Set Sub- 283 Object meets the multiple of 4 byte size requirement stated 284 above. The field is only required when the Subchannel field is 285 not 32 bit aligned and the number of included Subchannel fields 286 result in the Sub-Object not being 32 bit aligned. 288 The Padding field MUST be included when the number of bits 289 represented in all the Subchannel fields included in a 290 Generalized Channel_Set Sub-Object result in the Sub-Object not 291 being 32 bit aligned. When present, the Padding field MUST 292 have a length that results in the Sub-Object being 32 bit 293 aligned. When present, the Padding field MUST be set to a zero 294 (0) value on transmission and MUST be ignored on receipt. 295 These bits SHOULD be passed through unmodified by transit 296 nodes. 298 3.3. Other Label related Objects 300 The previous section introduced a new LABEL object. As such the 301 formats of the other label related objects are also impacted. 302 Processing of these objects is not modified and remains per their 303 respective specifications. The other label related objects are 304 defined in [RFC3473] and include: 305 - SUGGESTED_LABEL object 306 - LABEL_SET object 307 - ACCEPTABLE_LABEL_SET object 308 - UPSTREAM_LABEL object 309 - RECOVERY_LABEL object 311 3.4. Compatibility 313 Transit and egress nodes that do not support the Generalized 314 Channel_Set Label related formats will first receive a Path message 315 containing Generalized Channel_Set LABEL_REQUEST object. When such a 316 node receives the Path message, per [RFC3209], it will send a PathErr 317 with the error code "Unknown object C_Type". 319 Ingress nodes initiating a Path message containing a Generalized 320 Channel_Set LABEL_REQUEST object on receiving such a PathErr 321 messages, then notify the requesting application user as appropriate. 323 4. IANA Considerations 325 IANA is requested to administer assignment of new values for 326 namespaces defined in this document and summarized in this section. 328 4.1. Data Channel Switching Type 330 Upon approval of this document, IANA will make the assignment in the 331 "Switching Types" section of the "GMPLS Signaling Parameters" 332 registry located at http://www.iana.org/assignments/gmpls-sig- 333 parameters: 335 Value Type Reference 336 ----- --------------------------- --------- 337 125* Data Channel Switching Capable (DCSC) [This document] 339 (*) Suggested value. 341 It should be noted that the assigned value should be reflected in 342 IANAGmplsSwitchingTypeTC at 343 http://www.iana.org/assignments/ianagmplstc-mib. 345 4.2. Generalized Channel_Set LABEL_REQUEST Object 347 Upon approval of this document, IANA will make the assignment in the 348 "Class Names, Class Numbers, and Class Types" section of the "RSVP 349 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 350 parameters. 352 A new class type for the existing LABEL_REQUEST Object class number 353 (19) with the following definition: 355 Class Types or C-Types: 357 5* Generalized Channel_Set [This document] 359 (*) Suggested value. 361 4.3. Generalized Channel_Set LABEL Object 363 Upon approval of this document, IANA will make the assignment in the 364 "Class Names, Class Numbers, and Class Types" section of the "RSVP 365 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 366 parameters. 368 A new class type for the existing RSVP_LABEL Object class number (16) 369 with the following definition: 371 Class Types or C-Types: 373 4* Generalized Channel_Set [This document] 375 (*) Suggested value. 377 5. Security Considerations 379 This document introduces new message object formats for use in GMPLS 380 signaling [RFC3473]. It does not introduce any new signaling 381 messages, nor change the relationship between LSRs that are adjacent 382 in the control plane. As such, this document introduces no additional 383 security considerations. See [RFC3473] for relevant security 384 considerations. Additionally, the existing framework for MPLS and 385 GMPLS security is documented in [MPLS-SEC]. 387 6. References 389 6.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels," RFC 2119. 394 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 395 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 396 to RSVP for LSP Tunnels", RFC 3209, December 2001. 398 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 399 Switching (GMPLS) Signaling Functional Description", 400 RFC 3471, January 2003. 402 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 403 Switching (GMPLS) Signaling - Resource ReserVation 404 Protocol-Traffic Engineering (RSVP-TE) Extensions", 405 RFC 3473, January 2003. 407 [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label 408 Switching (GMPLS) Architecture", RFC 3945, October 409 2004. 411 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 412 Extensions in Support of Generalized Multi-Protocol 413 Label Switching (GMPLS)", RFC 4202, October 2005. 415 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in 416 Support of Generalized Multi-Protocol Label Switching 417 (GMPLS)", RFC 4203, October 2005. 419 [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in 420 Support of Generalized Multi-Protocol Label Switching 421 (GMPLS)", RFC 5307, October 2008. 423 6.2. Informative References 425 [GMPLS-ESVCS] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 426 Support For Metro Ethernet Forum and G.8011 Ethernet 427 Service Switching", Work in Progress, 428 draft-ietf-ccamp-gmpls-ether-svcs. 430 [GMPLS-MEF-UNI] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 431 Support For Metro Ethernet Forum and G.8011 432 User-Network Interface (UNI)", Work in Progress, 433 draft-ietf-ccamp-gmpls-mef-uni. 435 [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and 436 GMPLS Networks", Work in Progress, 437 draft-ietf-mpls-mpls-and-gmpls-security-framework. 439 [RFC4606] Mannie, E., et al "Generalized Multi-Protocol Label 440 Switching (GMPLS) Extensions for Synchronous Optical 441 Network (SONET) and Synchronous Digital Hierarchy (SDH) 442 Control", RFC 4606, August 2006. 444 7. Acknowledgments 446 Dimitri Papadimitriou provided substantial textual contributions to 447 this document and coauthored earlier versions of this document. 449 The authors would like to thank Evelyne Roch, Stephen Shew, and 450 Adrian Farrel for their valuable comments. 452 8. Author's Addresses 454 Lou Berger 455 LabN Consulting, L.L.C. 456 Phone: +1-301-468-9228 457 Email: lberger@labn.net 459 Don Fedyk 460 Alcatel-Lucent 461 Groton, MA, 01450 462 Phone: +1-978-467-5645 463 Email: donald.fedyk@alcatel-lucent.com 465 Generated on: Wed Jan 20 13:22:05 EST 2010