idnits 2.17.1 draft-ietf-ccamp-gmpls-dcsc-channel-ext-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 : ---------------------------------------------------------------------------- -- 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 (February 18, 2010) is 5178 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: August 18, 2010 6 February 18, 2010 8 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and 9 Channel Set Label Extensions 11 draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt 13 Abstract 15 This document describes two technology-independent extensions to 16 Generalized Multi-Protocol Label Switching. The first extension 17 defines the new switching type Data Channel Switching Capable. 18 Data Channel Switching Capable interfaces are able to support 19 switching of the whole digital channel presented on single channel 20 interfaces. The second extension defines a new type of 21 generalized label and updates related objects. The new label is 22 called the Generalized Channel_Set Label and allows more than one 23 data plane label to be controlled as part of an LSP. 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 months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 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/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on August 18, 2010 48 Copyright and License Notice 50 Copyright (c) 2010 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 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 ............................ 8 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 ........... 9 77 4.3 Generalized Channel_Set LABEL Object ................... 9 78 5 Security Considerations ................................ 10 79 6 References ............................................. 10 80 6.1 Normative References ................................... 10 81 6.2 Informative References ................................. 11 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, for example Ethernet terminated at the 138 physical (port) level and all traffic received on a port is switched 139 to a physical port at the LSP egress. 141 DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the 142 value TBA (by IANA). The DCSC value is carried in routing protocols 143 in the Interface Switching Capability Descriptor defined in 144 [RFC4202], and used in OSPF [RFC4203] and IS-IS [RFC5307]. These 145 documents are not otherwise modified by this document. 147 The DCSC Switching Type may be used with the Generalized Label 148 Request object, [RFC3473], or the Generalized Channel_Set 149 LABEL_REQUEST Object defined below. Port labels, as defined in 150 [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching 151 Type. 153 2.1. Compatibility 155 Transit and egress nodes that do not support the DCSC Switching Type 156 when receiving a Path message with a Label Request containing the 157 DCSC Switching Type will behave in the same way nodes generally 158 handle the case of an unsupported Switching Type. Specifically, per 159 [RFC3473], such nodes are required to generate a PathErr message, 160 with a "Routing problem/Unsupported Encoding" indication. 162 Ingress nodes initiating a Path message containing a Label Request 163 containing the DCSC Switching Type, receiving such a PathErr 164 messages, then notify the requesting application user as appropriate. 166 3. Generalized Channel_Set Label Related Formats 168 This section defines a new type of generalized label and updates 169 related objects. This section updates the label related definitions 170 of [RFC3473]. The ability to communicate more than one label as part 171 of the same LSP was motivated by the support for the communication of 172 one or more VLAN IDs. Simple concatenation of labels as is done in 173 [RFC4606] was deemed impractical given the large number of VLAN IDs 174 (up to 4096) that may need to be communicated. The formats defined 175 in this section are not technology specific and may be useful for 176 other switching technologies. The LABEL_SET object defined in 177 [RFC3473] serves as the foundation for the defined formats. 179 3.1. Generalized Channel_Set LABEL_REQUEST Object 181 The Generalized Channel_Set LABEL_REQUEST object is used to indicate 182 that the Generalized Channel_Set LABEL Object is to be used with the 183 associated LSP. The format of the Generalized Channel_Set 184 LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST 185 object and uses a C-Type of TBA. 187 3.2. Generalized Channel_Set LABEL Object 189 The Generalized Channel_Set LABEL Object communicates one or more 190 labels, all of which can be used equivalently in the data path 191 associated with a single LSP. The format of the Generalized 192 Channel_Set LABEL Object is based on the LABEL_SET object defined in 193 [RFC3473]. It differs from the the LABEL_SET object in that the full 194 set may be represented in a single object rather than the multiple 195 objects required by the [RFC3473] LABEL_SET object. The object MUST 196 be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST 197 object. The object MUST be processed per [RFC3473]. Make-before- 198 break procedures, see [RFC3209], SHOULD be used when modifying the 199 Channel_Set LABEL object. 201 The format of the Generalized Channel_Set LABEL object is: 203 o Generalized Channel_Set LABEL object: Class = 16, C-Type = TBA (By 204 IANA) 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Channel_Set Sub-Object 1 | 210 | ... | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 : : : 213 : : : 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Channel_Set Sub-Object N | 216 | ... | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 The Channel_Set Sub-Object size is measured in bytes and MUST always 220 be a multiple of 4, and at least 4, and has the following format: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Action | Num Subchannels | Label Type | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Subchannel 1 | 228 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | ... | : 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 231 : : : 232 : : : 233 : : : 234 : : : 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Subchannel N | 237 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ... | Padding | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Action: 8 bits 243 See [RFC3471] for definition of actions. Range actions SHOULD 244 be used when possible to minimize the size of the Channel_Set 245 LABEL Object. 247 Number of Subchannels: 10 bits 249 Indicates the number of subchannels carried in the sub-object. 250 When the number of subchannels required exceeds the limit of 251 the field, i.e., 1024, multiple Channel_Set Sub-Objects MUST be 252 used. Note that the size of the sub-object may result in a 253 Path message being larger than a single unfragmented IP packet. 254 See Section 4.4 of [GMPLS-ESVCS] for an example of how this 255 case may be handled. 257 A value of zero (0) has special meaning and MAY be used in 258 either the LABEL or UPSTREAM_LABEL object. A value of zero (0) 259 is used in a LABEL or UPSTREAM_LABEL object to indicate that 260 the subchannel(s) used in the corresponding (downstream or 261 upstream) direction MUST match the subchannel(s) carried in the 262 reverse directions label object. When value of zero (0) is 263 used, no Subchannels are included in the Channel_Set Sub-Object 264 and only one Channel_Set Sub-Object may be present. The zero 265 (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL 266 objects of the same LSP. Note that unacceptable label values 267 continue to be handled according to [RFC3209] and [RFC3473], 268 i.e., they result in PathErr or ResvErr messages with a 269 "Routing problem/Unacceptable label value" indication. For 270 example, in the case where a Resv message containing a zero (0) 271 in both the LABEL and UPSTREAM_LABEL objects is received, the 272 node would generate a ResvErr message. 274 Label Type: 14 bits 276 See [RFC3473] for a description of this field. 278 Subchannel: Variable 280 See [RFC3471] for a description of this field. Note that this 281 field might not be 32 bit aligned. 283 Padding: Variable 285 Padding is used to ensure that the length of a Channel_Set Sub- 286 Object meets the multiple of 4 byte size requirement stated 287 above. The field is only required when the Subchannel field is 288 not 32 bit aligned and the number of included Subchannel fields 289 result in the Sub-Object not being 32 bit aligned. 291 The Padding field MUST be included when the number of bits 292 represented in all the Subchannel fields included in a 293 Generalized Channel_Set Sub-Object result in the Sub-Object not 294 being 32 bit aligned. When present, the Padding field MUST 295 have a length that results in the Sub-Object being 32 bit 296 aligned. When present, the Padding field MUST be set to a zero 297 (0) value on transmission and MUST be ignored on receipt. 298 These bits SHOULD be passed through unmodified by transit 299 nodes. 301 Note that the overall length of a Channel_Set Sub-Object is 302 determined based on the value of the Num Subchannels field together 303 with the size of each Subchannel field as well as any required 304 padding. The size of the Subchannel field is uniquely identified by 305 the Label Type field. 307 3.3. Other Label Related Objects 309 The previous section introduced a new LABEL object. As such the 310 formats of the other label related objects and subobjects are also 311 impacted. Processing of these objects and subobjects is not modified 312 and remains per their respective specifications. The other label 313 related objects and subobjects are defined in [RFC3473] and include: 314 - SUGGESTED_LABEL object 315 - LABEL_SET object 316 - ACCEPTABLE_LABEL_SET object 317 - UPSTREAM_LABEL object 318 - RECOVERY_LABEL object 319 - Label ERO subobject 320 - Label RRO subobject 322 The label related objects and subobjects each contain a Label field, 323 all of which may carry any label type. As any label type may be 324 carried, the introduction of a new label type means that the new 325 label type may be carried in the Label field of each of the label 326 related objects and subobjects. No new definition needs to specified 327 as their original specification is label type agnostic. 329 3.4. Compatibility 331 Transit and egress nodes that do not support the Generalized 332 Channel_Set Label related formats will first receive a Path message 333 containing Generalized Channel_Set LABEL_REQUEST object. When such a 334 node receives the Path message, per [RFC3209], it will send a PathErr 335 with the error code "Unknown object C_Type". 337 Ingress nodes initiating a Path message containing a Generalized 338 Channel_Set LABEL_REQUEST object on receiving such a PathErr 339 messages, then notify the requesting application user as appropriate. 341 4. IANA Considerations 343 IANA is requested to administer assignment of new values for 344 namespaces defined in this document and summarized in this section. 346 4.1. Data Channel Switching Type 348 Upon approval of this document, IANA will make the assignment in the 349 "Switching Types" section of the "GMPLS Signaling Parameters" 350 registry located at http://www.iana.org/assignments/gmpls-sig- 351 parameters: 353 Value Type Reference 354 ----- --------------------------- --------- 355 125* Data Channel Switching Capable (DCSC) [This document] 357 (*) Suggested value. 359 It should be noted that the assigned value should be reflected in 360 IANAGmplsSwitchingTypeTC at 361 http://www.iana.org/assignments/ianagmplstc-mib. 363 4.2. Generalized Channel_Set LABEL_REQUEST Object 365 Upon approval of this document, IANA will make the assignment in the 366 "Class Names, Class Numbers, and Class Types" section of the "RSVP 367 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 368 parameters. 370 A new class type for the existing LABEL_REQUEST Object class number 371 (19) with the following definition: 373 Class Types or C-Types: 375 5* Generalized Channel_Set [This document] 377 (*) Suggested value. 379 4.3. Generalized Channel_Set LABEL Object 381 Upon approval of this document, IANA will make the assignment in the 382 "Class Names, Class Numbers, and Class Types" section of the "RSVP 383 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 384 parameters. 386 A new class type for the existing RSVP_LABEL Object class number (16) 387 with the following definition: 389 Class Types or C-Types: 391 4* Generalized Channel_Set [This document] 393 (*) Suggested value. 395 5. Security Considerations 397 This document introduces new message object formats for use in GMPLS 398 signaling [RFC3473]. It does not introduce any new signaling 399 messages, nor change the relationship between LSRs that are adjacent 400 in the control plane. As such, this document introduces no additional 401 security considerations. See [RFC3473] for relevant security 402 considerations. Additionally, the existing framework for MPLS and 403 GMPLS security is documented in [MPLS-SEC]. 405 6. References 407 6.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels," RFC 2119. 412 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 413 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 414 to RSVP for LSP Tunnels", RFC 3209, December 2001. 416 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 417 Switching (GMPLS) Signaling Functional Description", 418 RFC 3471, January 2003. 420 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 421 Switching (GMPLS) Signaling - Resource ReserVation 422 Protocol-Traffic Engineering (RSVP-TE) Extensions", 423 RFC 3473, January 2003. 425 [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label 426 Switching (GMPLS) Architecture", RFC 3945, October 427 2004. 429 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 430 Extensions in Support of Generalized Multi-Protocol 431 Label Switching (GMPLS)", RFC 4202, October 2005. 433 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in 434 Support of Generalized Multi-Protocol Label Switching 435 (GMPLS)", RFC 4203, October 2005. 437 [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in 438 Support of Generalized Multi-Protocol Label Switching 439 (GMPLS)", RFC 5307, October 2008. 441 6.2. Informative References 443 [GMPLS-ESVCS] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 444 Support For Metro Ethernet Forum and G.8011 Ethernet 445 Service Switching", Work in Progress, 446 draft-ietf-ccamp-gmpls-ether-svcs. 448 [GMPLS-MEF-UNI] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 449 Support For Metro Ethernet Forum and G.8011 450 User-Network Interface (UNI)", Work in Progress, 451 draft-ietf-ccamp-gmpls-mef-uni. 453 [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and 454 GMPLS Networks", Work in Progress, 455 draft-ietf-mpls-mpls-and-gmpls-security-framework. 457 [RFC4606] Mannie, E., et al "Generalized Multi-Protocol Label 458 Switching (GMPLS) Extensions for Synchronous Optical 459 Network (SONET) and Synchronous Digital Hierarchy (SDH) 460 Control", RFC 4606, August 2006. 462 7. Acknowledgments 464 Dimitri Papadimitriou provided substantial textual contributions to 465 this document and coauthored earlier versions of this document. 467 The authors would like to thank Evelyne Roch, Stephen Shew, and 468 Adrian Farrel for their valuable comments. 470 8. Author's Addresses 472 Lou Berger 473 LabN Consulting, L.L.C. 474 Phone: +1-301-468-9228 475 Email: lberger@labn.net 477 Don Fedyk 478 Alcatel-Lucent 479 Groton, MA, 01450 480 Phone: +1-978-467-5645 481 Email: donald.fedyk@alcatel-lucent.com 483 Generated on: Thu Feb 18 19:47:04 EST 2010