idnits 2.17.1 draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. 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 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 (August 8, 2008) is 5738 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) == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-ether-svcs-02 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-gmpls-mef-uni-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 11 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 (Nortel) 3 Category: Standards Track 4 Expiration Date: February 8, 2009 6 August 8, 2008 8 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and 9 Channel Set Label Extensions 11 draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on February 8, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes two technology independent extensions to 45 Generalized Multi-Protocol Label Switching. The first extension 46 defines the new switching type Data Channel Switching Capable. Data 47 Channel Switching Capable interfaces are able to support switching of 48 the whole digital channel presented on single channel interfaces. 49 The second extension defines a new type of generalized label and 50 updates related objects. The new label is called the Generalized 51 Channel_Set Label and allows more than one data plane label to be 52 controlled as part of an LSP. 54 Table of Contents 56 1 Introduction .............................................. 3 57 1.1 Conventions used in this document ......................... 3 58 2 Data Channel Switching .................................... 3 59 3 Generalized Channel_Set Label Related Formats ............. 4 60 3.1 Generalized Channel_Set LABEL_REQUEST Object .............. 4 61 3.2 Generalized Channel_Set LABEL Object ...................... 4 62 3.3 Other Label related Objects ............................... 7 63 4 IANA Considerations ....................................... 7 64 4.1 Data Channel Switching Type ............................... 7 65 4.2 Generalized Channel_Set LABEL_REQUEST Object .............. 7 66 4.3 Generalized Channel_Set LABEL Object ...................... 8 67 5 Security Considerations ................................... 8 68 6 References ................................................ 8 69 6.1 Normative References ...................................... 8 70 6.2 Informative References .................................... 9 71 7 Acknowledgments ........................................... 9 72 8 Author's Addresses ........................................ 10 73 9 Full Copyright Statement .................................. 10 74 10 Intellectual Property ..................................... 10 75 1. Introduction 77 This document describes two technology independent extensions to 78 Generalized Multi-Protocol Label Switching (GMPLS). Both of 79 extensions were initially defined to in the context of Ethernet 80 services, see [GMPLS-ESVCS] and [GMPLS-MEF-UNI], but are generic in 81 nature and may be useful to any switching technology controlled via 82 GMPLS. 84 The first extension defines a new switching type, which is called 85 Data Channel Switching Capable, or DCSC. DCSC interfaces are able to 86 support switching of the whole digital channel presented on single 87 channel interfaces. The second extension defines a new type of 88 generalized label and updates related objects. The new label is 89 called the Generalized Channel_Set Label and allows more than one 90 data plane label to be controlled as part of an LSP. 92 1.1. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Data Channel Switching 100 Current GMPLS switching types are defined in [RFC3945] and [RFC3471] 101 and support switching at the packet (PSC), frame (L2SC), time-slot 102 (TDM), frequency (LSC) and fiber (FSC) granularities. One type of 103 switching that is not well represented in this current set switching 104 that takes all data received on an ingress port and switches it 105 through a network to an egress port. While there are similarities 106 between this level of switching and the "opaque single wavelength" 107 case described in Section 3.5 of [RFC4202], such port-to-port 108 switching is not limited to the optical switching technology implied 109 by the LSC type. Therefore, a new switching type is defined. 111 The new switching type is called Data Channel Switching Capable 112 (DCSC). (Port switching seems a more intuitive name, but it collides 113 with PSC so isn't used.) DCSC interfaces are able to support 114 switching of the whole digital channel presented on single channel 115 interfaces. Interfaces that inherently support multiple channels, 116 e.g., WDM and channelized TDM interfaces, are specifically excluded 117 from this type. Any interface that can be represented as a single 118 digital channel are included. Examples include concatenated TDM and 119 line encoded interfaces. Framed interfaces may also be included when 120 they support switching on an interface granularity. 122 DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the 123 value TBA (by IANA). 125 Port labels, as defined in [RFC3471], SHOULD be used for LSPs 126 signaled using the DCSC Switching Type. 128 3. Generalized Channel_Set Label Related Formats 130 This section defines a new type of generalized label and updates 131 related objects. This section updates the label related definitions 132 of [RFC3473]. The ability to communicate more than one label as part 133 of the same LSP was motivated by the support for the communication of 134 one or more VLAN IDs, but the formats defined in this section are not 135 technology specific and may be useful for other switching 136 technologies. 138 3.1. Generalized Channel_Set LABEL_REQUEST Object 140 The Generalized Channel_Set LABEL_REQUEST object is used to indicate 141 that the Generalized Channel_Set LABEL Object is to be used with the 142 associated LSP. The format of the Generalized Channel_Set 143 LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST 144 object and uses of C-Type of TBA. 146 3.2. Generalized Channel_Set LABEL Object 148 The Generalized Channel_Set LABEL Object communicates one or more 149 labels, all of which can be used equivalently in the data path 150 associated with a single LSP. The format of the Generalized 151 Channel_Set LABEL Object is based on the LABEL_SET object defined in 152 [RFC3473]. It differs from the the LABEL_SET object in that the full 153 set may be represented in a single object rather than the multiple 154 objects required by the [RFC3473] LABEL_SET object. The object MUST 155 be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST 156 object. The object MUST be processed per [RFC3473]. Make-before- 157 break procedures, see [RFC3209], SHOULD be used when modifying the 158 Channel_Set LABEL object. 160 The format of the Generalized Channel_Set LABEL object is: 162 o Generalized Channel_Set LABEL object: Class = 16, C-Type = TBA (By 163 IANA) 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Channel_Set Sub-Object 1 | 169 | ... | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 : : : 172 : : : 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Channel_Set Sub-Object N | 175 | ... | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 The Channel_Set Sub-Object size is measured in bytes and MUST always 179 be a multiple of 4, and at least 4, and has the following format: 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 | Action | Num Subchannels | Label Type | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Subchannel 1 | 187 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | ... | : 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 190 : : : 191 : : : 192 : : : 193 : : : 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Subchannel N | 196 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | ... | Padding | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Action: 8 bits 202 See [RFC3471] for definition of actions. Range actions SHOULD 203 be used when possible to minimize the size of the Channel_Set 204 LABEL Object. 206 Number of Subchannels: 10 bits 208 Indicates the number of subchannels carried in the sub-object. 209 When the number of subchannels required exceeds the limit of 210 the field, i.e., 1024, multiple Channel_Set Sub-Objects MUST be 211 used. Note that the size of the sub-object may result in a 212 Path message being larger than a single unfragmented IP packet. 213 See section 4.4 for an example of how this case may be handled. 215 A value of zero (0) has special meaning and MAY be used in 216 either the LABEL or UPSTREAM_LABEL object. A value of zero (0) 217 is used in a LABEL or UPSTREAM_LABEL object to indicate that 218 the subchannel(s) used in the corresponding (downstream or 219 upstream) direction MUST match the subchannel(s) carried in the 220 reverse directions label object. When value of zero (0) is 221 used, no Subchannels are included in the Channel_Set Sub-Object 222 and only one Channel_Set Sub-Object may be present. The zero 223 (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL 224 object of the same LSP. 226 Label Type: 14 bits 228 See [RFC3473] for a description of this field. 230 Subchannel: Variable 232 See [RFC3471] for a description of this field. Note that this 233 field may not be 32 bit aligned. 235 Padding: Variable 237 Padding is used to ensure that the length of a Channel_Set Sub- 238 Object meets the multiple of 4 byte size requirement stated 239 above. The field is only required when the Subchannel field is 240 not 32 bit aligned and the number of included Subchannel fields 241 result in the Sub-Object not being 32 bit aligned. 243 The Padding field MUST be included when the number of bits 244 represented in all the Subchannel fields included in a 245 Generalized Channel_Set Sub-Object result in the Sub-Object not 246 being 32 bit aligned. When present, the Padding field MUST 247 have a length that results in the Sub-Object being 32 bit 248 aligned. When present, the Padding field MUST be set to a zero 249 (0) value on transmission and MUST be ignored on receipt. 250 These bits SHOULD be passed through unmodified by transit 251 nodes. 253 3.3. Other Label related Objects 255 The previous section introduces a new LABEL object. As such the 256 formats of the other label related objects are also impacted. 257 Processing of these objects is not modified and remain per their 258 respective specifications. The other label related objects are 259 defined in [RFC3473] and include: 260 - SUGGESTED_LABEL object 261 - LABEL_SET object 262 - ACCEPTABLE_LABEL_SET object 263 - UPSTREAM_LABEL object 264 - RECOVERY_LABEL object 266 4. IANA Considerations 268 IANA is requested to administer assignment of new values for 269 namespaces defined in this document and reviewed in this section. 271 4.1. Data Channel Switching Type 273 Upon approval of this document, the IANA will make the assignment in 274 the "Switching Types" section of the "GMPLS Signaling Parameters" 275 registry located at http://www.iana.org/assignments/gmpls-sig- 276 parameters: 278 Value Type Reference 279 ----- --------------------------- --------- 280 125* Data Channel Switching Capable (DCSC) [This document] 282 (*) Suggested value. 284 4.2. Generalized Channel_Set LABEL_REQUEST Object 286 Upon approval of this document, the IANA will make the assignment in 287 the "Class Names, Class Numbers, and Class Types" section of the 288 "RSVP PARAMETERS" registry located at 289 http://www.iana.org/assignments/rsvp-parameters. 291 A new class type for the existing LABEL_REQUEST Object class number 292 (19) with the following definition: 294 Class Types or C-Types: 296 5* Generalized Channel_Set [This document] 298 (*) Suggested value. 300 4.3. Generalized Channel_Set LABEL Object 302 Upon approval of this document, the IANA will make the assignment in 303 the "Class Names, Class Numbers, and Class Types" section of the 304 "RSVP PARAMETERS" registry located at 305 http://www.iana.org/assignments/rsvp-parameters. 307 A new class type for the existing RSVP_LABEL Object class number (16) 308 with the following definition: 310 Class Types or C-Types: 312 4* Generalized Channel_Set [This document] 314 (*) Suggested value. 316 5. Security Considerations 318 This document introduces new message object formats for use in GMPLS 319 signaling [RFC3473]. It does not introduce any new signaling 320 messages, nor change the relationship between LSRs that are adjacent 321 in the control plane. As such, this document introduces no additional 322 security considerations. See [RFC3473] for relevant security 323 considerations. 325 6. References 327 6.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels," RFC 2119. 332 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 333 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 334 to RSVP for LSP Tunnels", RFC 3209, December 2001. 336 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 337 Switching (GMPLS) Signaling Functional Description", 338 RFC 3471, January 2003. 340 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 341 Switching (GMPLS) Signaling - Resource ReserVation 342 Protocol-Traffic Engineering (RSVP-TE) Extensions", 343 RFC 3473, January 2003. 345 [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label 346 Switching (GMPLS) Architecture", RFC 3945, October 347 2004. 349 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 350 Extensions in Support of Generalized Multi-Protocol 351 Label Switching (GMPLS)", RFC 4202, October 2005. 353 6.2. Informative References 355 [GMPLS-ESVCS] Berger, L., Papadimitriou, P., Fedyk, D., 356 "Generalized MPLS (GMPLS) Support For Metro Ethernet 357 Forum and G.8011 Ethernet Service Switching", Work in 358 Progress, draft-ietf-ccamp-gmpls-ether-svcs-02.txt, 359 August 2008. 361 [GMPLS-MEF-UNI] Berger, L., Papadimitriou, P., Fedyk, D., 362 "Generalized MPLS (GMPLS) Support For Metro 363 Ethernet Forum and G.8011 User-Network Interface 364 (UNI)", Work in Progress, 365 draft-ietf-ccamp-gmpls-mef-uni-01.txt, 366 August 2008. 368 7. Acknowledgments 370 Dimitri Papadimitriou provided substantial textual contributions to 371 this document and coauthored earlier versions of this document. 373 The authors would like to thank Evelyne Roch, Stephen Shew, and 374 Adrian Farrel for their valuable comments. 376 8. Author's Addresses 378 Lou Berger 379 LabN Consulting, L.L.C. 380 Phone: +1-301-468-9228 381 Email: lberger@labn.net 383 Don Fedyk 384 Nortel Networks 385 600 Technology Park Drive 386 Billerica, MA, 01821 387 Phone: +1-978-288-3041 388 Email: dwfedyk@nortel.com 390 9. Full Copyright Statement 392 Copyright (C) The IETF Trust (2008). 394 This document is subject to the rights, licenses and restrictions 395 contained in BCP 78, and except as set forth therein, the authors 396 retain all their rights. 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 401 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 402 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 10. Intellectual Property 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed 410 to pertain to the implementation or use of the technology 411 described in this document or the extent to which any license 412 under such rights might or might not be available; nor does it 413 represent that it has made any independent effort to identify any 414 such rights. Information on the procedures with respect to rights 415 in RFC documents can be found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use 420 of such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository 422 at http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention 425 any copyrights, patents or patent applications, or other 426 proprietary rights that may cover technology that may be required 427 to implement this standard. Please address the information to the 428 IETF at ietf-ipr@ietf.org. 430 Acknowledgement 432 Funding for the RFC Editor function is provided by the IETF 433 Administrative Support Activity (IASA). 435 Generated on: Fri Aug 8 09:53:22 EDT 2008