idnits 2.17.1 draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 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 (October 14, 2009) is 5305 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: 1 error (**), 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, 3473, 3945, 4202 Don Fedyk (Alcatel-Lucent) 3 Category: Standards Track 4 Expiration Date: April 14, 2010 6 October 14, 2009 8 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and 9 Channel Set Label Extensions 11 draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on April 14, 2010. 41 Copyright and License Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents in effect on the date of 48 publication of this document (http://trustee.ietf.org/license-info). 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 Abstract 54 This document describes two technology-independent extensions to 55 Generalized Multi-Protocol Label Switching. The first extension 56 defines the new switching type Data Channel Switching Capable. Data 57 Channel Switching Capable interfaces are able to support switching of 58 the whole digital channel presented on single channel interfaces. 59 The second extension defines a new type of generalized label and 60 updates related objects. The new label is called the Generalized 61 Channel_Set Label and allows more than one data plane label to be 62 controlled as part of an LSP. 64 Table of Contents 66 1 Introduction ........................................... 3 67 1.1 Conventions used in this document ...................... 3 68 2 Data Channel Switching ................................. 3 69 2.1 Compatibility .......................................... 4 70 3 Generalized Channel_Set Label Related Formats .......... 4 71 3.1 Generalized Channel_Set LABEL_REQUEST Object ........... 5 72 3.2 Generalized Channel_Set LABEL Object ................... 5 73 3.3 Other Label related Objects ............................ 7 74 3.4 Compatibility .......................................... 8 75 4 IANA Considerations .................................... 8 76 4.1 Data Channel Switching Type ............................ 8 77 4.2 Generalized Channel_Set LABEL_REQUEST Object ........... 8 78 4.3 Generalized Channel_Set LABEL Object ................... 9 79 5 Security Considerations ................................ 9 80 6 References ............................................. 9 81 6.1 Normative References ................................... 9 82 6.2 Informative References ................................. 10 83 7 Acknowledgments ........................................ 11 84 8 Author's Addresses ..................................... 11 86 1. Introduction 88 This document describes two technology independent extensions to 89 Generalized Multi-Protocol Label Switching (GMPLS). Both of these 90 extensions were initially defined to in the context of Ethernet 91 services, see [GMPLS-ESVCS] and [GMPLS-MEF-UNI], but are generic in 92 nature and may be useful to any switching technology controlled via 93 GMPLS. 95 The first extension defines a new switching type, which is called 96 Data Channel Switching Capable (DCSC). DCSC interfaces are able to 97 support switching of the whole digital channel presented on single 98 channel interfaces. The second extension defines a new type of 99 generalized label and updates related objects. The new label is 100 called the Generalized Channel_Set Label and allows more than one 101 data plane label to be controlled as part of an 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. One type of 114 switching that is not well represented in this current set is 115 switching that occurs when all data received on an ingress port is 116 switched through a network to an egress port. While there are 117 similarities between this level of switching and the "opaque single 118 wavelength" case described in Section 3.5 of [RFC4202], such port-to- 119 port switching is not limited to the optical switching technology 120 implied by the LSC type. FSC is also similar, but it is restricted to 121 fiber ports and also supports multiple data channels with-in the 122 fiber port. 124 This document defines the new switching type called Data Channel 125 Switching Capable (DCSC). Port switching seems a more intuitive name, 126 but this naming collides with PSC so it isn't used. DCSC interfaces 127 are able to support switching of the whole digital channel presented 128 on single channel interfaces. Interfaces that inherently support 129 multiple channels, e.g., WDM and channelized TDM interfaces, are 130 specifically excluded from this type. Any interface that can be 131 represented as a single digital channel are included. Examples 132 include concatenated TDM and line encoded interfaces. Framed 133 interfaces may also be included when they support switching on an 134 interface granularity. 136 DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the 137 value TBA (by IANA). 139 Port labels, as defined in [RFC3471], SHOULD be used for LSPs 140 signaled using the DCSC Switching Type. The DCSC Switching Type may 141 be used with the Generalized Label Request object, [RFC3473], or the 142 Generalized Channel_Set LABEL_REQUEST Object defined below. 144 2.1. Compatibility 146 Transit and egress nodes that do not support the DCSC Switching Type 147 when receiving a Path message with a Label Request containing the 148 DCSC Switching Type will behave in the same way nodes generally 149 handle the case of an unsupported Switching Type. Specifically, per 150 [RFC3473], such nodes are required to generate a PathErr message, 151 with a "Routing problem/Unsupported Encoding" indication. 153 Ingress nodes initiating a Path message containing a Label Request 154 containing the DCSC Switching Type, receiving such a PathErr 155 messages, then notify the requesting application user as appropriate. 157 3. Generalized Channel_Set Label Related Formats 159 This section defines a new type of generalized label and updates 160 related objects. This section updates the label related definitions 161 of [RFC3473]. The ability to communicate more than one label as part 162 of the same LSP was motivated by the support for the communication of 163 one or more VLAN IDs. Simple concatenation of labels as is done in 164 [RFC4606] was deemed impractical given the large number of VLAN IDs 165 (up to 4096) that may need to be communicated. The formats defined 166 in this section are not technology specific and may be useful for 167 other switching technologies. The LABEL_SET object defined in 168 [RFC3473] serves as the foundation for the defined formats. 170 3.1. Generalized Channel_Set LABEL_REQUEST Object 172 The Generalized Channel_Set LABEL_REQUEST object is used to indicate 173 that the Generalized Channel_Set LABEL Object is to be used with the 174 associated LSP. The format of the Generalized Channel_Set 175 LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST 176 object and uses a C-Type of TBA. 178 3.2. Generalized Channel_Set LABEL Object 180 The Generalized Channel_Set LABEL Object communicates one or more 181 labels, all of which can be used equivalently in the data path 182 associated with a single LSP. The format of the Generalized 183 Channel_Set LABEL Object is based on the LABEL_SET object defined in 184 [RFC3473]. It differs from the the LABEL_SET object in that the full 185 set may be represented in a single object rather than the multiple 186 objects required by the [RFC3473] LABEL_SET object. The object MUST 187 be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST 188 object. The object MUST be processed per [RFC3473]. Make-before- 189 break procedures, see [RFC3209], SHOULD be used when modifying the 190 Channel_Set LABEL object. 192 The format of the Generalized Channel_Set LABEL object is: 194 o Generalized Channel_Set LABEL object: Class = 16, C-Type = TBA (By 195 IANA) 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Channel_Set Sub-Object 1 | 201 | ... | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 : : : 204 : : : 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Channel_Set Sub-Object N | 207 | ... | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 The Channel_Set Sub-Object size is measured in bytes and MUST always 211 be a multiple of 4, and at least 4, and has the following format: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Action | Num Subchannels | Label Type | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Subchannel 1 | 219 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | ... | : 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 222 : : : 223 : : : 224 : : : 225 : : : 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Subchannel N | 228 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | ... | Padding | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Action: 8 bits 234 See [RFC3471] for definition of actions. Range actions SHOULD 235 be used when possible to minimize the size of the Channel_Set 236 LABEL Object. 238 Number of Subchannels: 10 bits 240 Indicates the number of subchannels carried in the sub-object. 241 When the number of subchannels required exceeds the limit of 242 the field, i.e., 1024, multiple Channel_Set Sub-Objects MUST be 243 used. Note that the size of the sub-object may result in a 244 Path message being larger than a single unfragmented IP packet. 245 See section 4.4 for an example of how this case may be handled. 247 A value of zero (0) has special meaning and MAY be used in 248 either the LABEL or UPSTREAM_LABEL object. A value of zero (0) 249 is used in a LABEL or UPSTREAM_LABEL object to indicate that 250 the subchannel(s) used in the corresponding (downstream or 251 upstream) direction MUST match the subchannel(s) carried in the 252 reverse directions label object. When value of zero (0) is 253 used, no Subchannels are included in the Channel_Set Sub-Object 254 and only one Channel_Set Sub-Object may be present. The zero 255 (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL 256 object of the same LSP. 258 Label Type: 14 bits 260 See [RFC3473] for a description of this field. 262 Subchannel: Variable 264 See [RFC3471] for a description of this field. Note that this 265 field might not be 32 bit aligned. 267 Padding: Variable 269 Padding is used to ensure that the length of a Channel_Set Sub- 270 Object meets the multiple of 4 byte size requirement stated 271 above. The field is only required when the Subchannel field is 272 not 32 bit aligned and the number of included Subchannel fields 273 result in the Sub-Object not being 32 bit aligned. 275 The Padding field MUST be included when the number of bits 276 represented in all the Subchannel fields included in a 277 Generalized Channel_Set Sub-Object result in the Sub-Object not 278 being 32 bit aligned. When present, the Padding field MUST 279 have a length that results in the Sub-Object being 32 bit 280 aligned. When present, the Padding field MUST be set to a zero 281 (0) value on transmission and MUST be ignored on receipt. 282 These bits SHOULD be passed through unmodified by transit 283 nodes. 285 3.3. Other Label related Objects 287 The previous section introduced a new LABEL object. As such the 288 formats of the other label related objects are also impacted. 289 Processing of these objects is not modified and remains per their 290 respective specifications. The other label related objects are 291 defined in [RFC3473] and include: 292 - SUGGESTED_LABEL object 293 - LABEL_SET object 294 - ACCEPTABLE_LABEL_SET object 295 - UPSTREAM_LABEL object 296 - RECOVERY_LABEL object 298 3.4. Compatibility 300 Transit and egress nodes that do not support the Generalized 301 Channel_Set Label related formats will first receive a Path message 302 containing Generalized Channel_Set LABEL_REQUEST object. When such a 303 node receives the Path message, per [RFC3209], it will send a PathErr 304 with the error code "Unknown object C_Type". 306 Ingress nodes initiating a Path message containing a Generalized 307 Channel_Set LABEL_REQUEST object on receiving such a PathErr 308 messages, then notify the requesting application user as appropriate. 310 4. IANA Considerations 312 IANA is requested to administer assignment of new values for 313 namespaces defined in this document and summarized in this section. 315 4.1. Data Channel Switching Type 317 Upon approval of this document, IANA will make the assignment in the 318 "Switching Types" section of the "GMPLS Signaling Parameters" 319 registry located at http://www.iana.org/assignments/gmpls-sig- 320 parameters: 322 Value Type Reference 323 ----- --------------------------- --------- 324 125* Data Channel Switching Capable (DCSC) [This document] 326 (*) Suggested value. 328 It should be noted that the assigned value should be reflected in 329 IANAGmplsSwitchingTypeTC at 330 http://www.iana.org/assignments/ianagmplstc-mib. 332 4.2. Generalized Channel_Set LABEL_REQUEST Object 334 Upon approval of this document, IANA will make the assignment in the 335 "Class Names, Class Numbers, and Class Types" section of the "RSVP 336 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 337 parameters. 339 A new class type for the existing LABEL_REQUEST Object class number 340 (19) with the following definition: 342 Class Types or C-Types: 344 5* Generalized Channel_Set [This document] 346 (*) Suggested value. 348 4.3. Generalized Channel_Set LABEL Object 350 Upon approval of this document, IANA will make the assignment in the 351 "Class Names, Class Numbers, and Class Types" section of the "RSVP 352 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 353 parameters. 355 A new class type for the existing RSVP_LABEL Object class number (16) 356 with the following definition: 358 Class Types or C-Types: 360 4* Generalized Channel_Set [This document] 362 (*) Suggested value. 364 5. Security Considerations 366 This document introduces new message object formats for use in GMPLS 367 signaling [RFC3473]. It does not introduce any new signaling 368 messages, nor change the relationship between LSRs that are adjacent 369 in the control plane. As such, this document introduces no additional 370 security considerations. See [RFC3473] for relevant security 371 considerations. Additionally, the existing framework for MPLS and 372 GMPLS security is documented in [MPLS-SEC]. 374 6. References 376 6.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels," RFC 2119. 381 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 382 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 383 to RSVP for LSP Tunnels", RFC 3209, December 2001. 385 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 386 Switching (GMPLS) Signaling Functional Description", 387 RFC 3471, January 2003. 389 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 390 Switching (GMPLS) Signaling - Resource ReserVation 391 Protocol-Traffic Engineering (RSVP-TE) Extensions", 392 RFC 3473, January 2003. 394 [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label 395 Switching (GMPLS) Architecture", RFC 3945, October 396 2004. 398 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 399 Extensions in Support of Generalized Multi-Protocol 400 Label Switching (GMPLS)", RFC 4202, October 2005. 402 6.2. Informative References 404 [GMPLS-ESVCS] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 405 Support For Metro Ethernet Forum and G.8011 Ethernet 406 Service Switching", Work in Progress, 407 draft-ietf-ccamp-gmpls-ether-svcs. 409 [GMPLS-MEF-UNI] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 410 Support For Metro Ethernet Forum and G.8011 411 User-Network Interface (UNI)", Work in Progress, 412 draft-ietf-ccamp-gmpls-mef-uni. 414 [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and 415 GMPLS Networks", Work in Progress, 416 draft-ietf-mpls-mpls-and-gmpls-security-framework. 418 [RFC4606] Mannie, E., et al "Generalized Multi-Protocol Label 419 Switching (GMPLS) Extensions for Synchronous Optical 420 Network (SONET) and Synchronous Digital Hierarchy (SDH) 421 Control", RFC 4606, August 2006. 423 7. Acknowledgments 425 Dimitri Papadimitriou provided substantial textual contributions to 426 this document and coauthored earlier versions of this document. 428 The authors would like to thank Evelyne Roch, Stephen Shew, and 429 Adrian Farrel for their valuable comments. 431 8. Author's Addresses 433 Lou Berger 434 LabN Consulting, L.L.C. 435 Phone: +1-301-468-9228 436 Email: lberger@labn.net 438 Don Fedyk 439 Alcatel-Lucent 440 Groton, MA, 01450 441 Phone: +1-978-467-5645 442 Email: donald.fedyk@alcatel-lucent.com 444 Generated on: Wed Oct 14 14:46:36 EDT 2009