idnits 2.17.1 draft-berger-ccamp-gmpls-ether-svcs-01.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 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 969. 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 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 (February 25, 2008) is 5904 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 (-10) exists of draft-ietf-ccamp-ethernet-traffic-parameters-03 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 3 Category: Standards Track Don Fedyk (Nortel) 4 Expiration Date: August 25, 2008 6 February 25, 2008 8 Generalized MPLS (GMPLS) Support For Metro Ethernet Forum 9 and G.8011 Ethernet Service Switching 11 draft-berger-ccamp-gmpls-ether-svcs-01.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 August 25, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes a method for controlling two specific types 45 of Ethernet switching via Generalized Multi-Protocol Label Switching 46 (GMPLS). This document supports the types of switching required to 47 implied by the Ethernet services that have been defined in the 48 context of the Metro Ethernet Forum (MEF) and International 49 Telecommunication Union (ITU) G.8011. Specifically, switching in 50 support of Ethernet private line service and Ethernet virtual private 51 line service. Support for MEF and ITU defined parameters are also 52 covered. Some of the extensions defined in this document are generic 53 in nature and not specific to Ethernet. 55 Contents 57 1 Introduction .............................................. 3 58 1.1 Overview .................................................. 3 59 1.2 Conventions used in this document ......................... 5 60 2 Common Signaling Support .................................. 5 61 2.1 Ethernet Endpoint Identification .......................... 5 62 2.1.1 Endpoint ID TLV ........................................... 6 63 2.2 Connection Identification ................................. 7 64 2.2.1 Procedures ................................................ 7 65 2.3 Traffic Parameters ........................................ 7 66 2.3.1 L2 Control Protocol TLV ................................... 8 67 2.4 Bundling and VLAN Identification .......................... 9 68 3 EPL Service ............................................... 9 69 3.1 EPL Service Parameters .................................... 10 70 4 EVPL Service .............................................. 10 71 4.1 EVPL Generalized Label Format ............................. 11 72 4.2 Egress VLAN ID Control and VLAN ID preservation ........... 11 73 4.3 Single Call - Single LSP .................................. 12 74 4.4 Single Call - Multiple LSPs ............................... 12 75 5 Generic GMPLS Extensions .................................. 12 76 5.1 Notify Message Format ..................................... 13 77 5.2 Data Channel Switching .................................... 13 78 5.3 Generalized Channel_Set Label Related Formats ............. 14 79 5.3.1 Generalized Channel_Set LABEL_REQUEST Object .............. 14 80 5.3.2 Generalized Channel_Set LABEL Object ...................... 14 81 5.3.3 Other Label related Objects ............................... 17 82 6 IANA Considerations ....................................... 17 83 6.1 Endpoint ID Attributes TLV ................................ 17 84 6.2 Line LSP Encoding ......................................... 17 85 6.3 Data Channel Switching Type ............................... 18 86 6.4 Generalized Channel_Set LABEL_REQUEST Object .............. 18 87 6.5 Generalized Channel_Set LABEL Object ...................... 18 88 7 Security Considerations ................................... 19 89 8 References ................................................ 19 90 8.1 Normative References ...................................... 19 91 8.2 Informative References .................................... 20 92 9 Acknowledgments ........................................... 21 93 10 Author's Addresses ........................................ 21 94 11 Full Copyright Statement .................................. 21 95 12 Intellectual Property ..................................... 22 96 1. Introduction 98 [MEF6] and [G.8011] provide parallel frameworks for defining network- 99 oriented characteristics of Ethernet services in transport networks. 100 The framework discusses general Ethernet connection characteristics, 101 Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network 102 Interfaces (NNIs). Within this framework, [G.8011.1] defines the 103 Ethernet Private Line (EPL) service and [G.8011.2] defines the 104 Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both 105 service types. [MEF10.1] defines service parameters and [MEF11] 106 provides UNI requirements and framework. 108 [MEF6] and [G.8011] are focused on service interfaces and not the 109 underlying technology used to support the service. For example, 110 [G.8011] refers to the defined services being transported over one of 111 several possible "server layers". This document focuses on the types 112 of switching that may directly support these services and provides a 113 method for GMPLS based control of such switching technologies. This 114 document defines the GMPLS extensions needed to support such 115 switching, but does not define the UNI or External NNI (E-NNI) 116 reference points. See [GMPLS-MEF-UNI] for a description of the UNI 117 reference point. This document makes use of the traffic parameters 118 defined in [MEF-TRAFFIC]. 120 Some of the extensions defined in this document are generic in nature 121 and not specific to Ethernet, or [MEF6] and [G.8011] related 122 switching. [AUTHORS' NOTE: These extensions are presented in a 123 separate section and may be split into their own document as this 124 work progresses.] 126 1.1. Overview 128 This document uses a largely common approach to supporting the 129 switching implied by the Ethernet services defined in [MEF6], 130 [G.8011.1] and [G.8011.2]. The approach builds on standard GMPLS 131 mechanisms to deliver the required control capabilities. This 132 document reuses the GMPLS mechanisms specified in [RFC3473] and 133 [RFC4974]. The document also expands expands the set of signaling 134 parameters in a fashion consistent with existing GMPLS signaling. 136 [AUTHORS' NOTE: As mentioned above, several extensions defined in 137 this document are generic in nature and may be moved into their own 138 document as this work progresses.] 140 Two types of connectivity between Ethernet endpoints are defined in 141 [MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to- 142 multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to 143 refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) 144 to refer to multipoint-to-multipoint virtual connections. [G.8011] 145 also identifies point-to-multipoint (P2MP) as an area for "further 146 study." Within the context of GMPLS, support is defined for point- 147 to-point unidirectional and bidirectional TE Label Switched Paths 148 (LSPs), see [RFC3473], and unidirectional point-to-multipoint TE 149 LSPs, see [RFC4875]. 151 Support for P2P and MP2MP service is required by [G.8011] and 152 [MEF11]. Note that while [MEF11] requires MP2MP, [G.8011.1] and 153 [G.8011.2] only require P2P. There is a clear correspondence between 154 E-Line/P2P service and GMPLS P2P TE LSPs, and support for such LSPs 155 are included in the scope of this document. There is no such clear 156 correspondence between E-LAN/MP2MP service and GMPLS TE LSPs. 157 Although it is possible to emulate the service using multiple P2P or 158 P2MP TE LSPs. The definition of support for MP2MP service is left 159 for future study and is not addressed in this document. 161 [MEF11] defines multiple types of control for UNI Ethernet services. 162 In MEF UNI Type 1, services are configured manually. In MEF UNI Type 163 2, services may be configured manually or via a link management 164 interface. In MEF UNI Type 3, services may be established and 165 managed via a signaling interface. From the MEF perspective, this 166 document along with [GMPLS-MEF-UNI] are aimed at the network control 167 needed to support the MEF UNI Type 3 mode of operation. 169 [G.8011.1], [G.8011.2] and [MEF11] together with [MEF10.1] define a 170 set of service attributes that are associated with each Ethernet 171 connection. Some of these attributes are based on the provisioning 172 of the local physical connection and are not modifiable or selectable 173 per connection. Other attributes are specific to a particular 174 connection, or must be consistent across the connection. The 175 approach taken in this document to communicate these attributes is to 176 exclude the static class of attributes from signaling. This class of 177 attributes will not be explicitly discussed in this document. The 178 other class of attributes are communicated via signaling and will be 179 reviewed in the sections below. The major attributes that will be 180 supported in signaling include: 181 - Endpoint identifiers 182 - Connection identifiers 183 - Traffic parameters (see [MEF-TRAFFIC]) 184 - Bundling / VLAN IDs map (EVPL only) 185 - VLAN ID Preservation (EVPL only) 187 Common procedures used to support Ethernet LSPs are described in 188 Section 2 of this document. Procedures related to signaling 189 switching in support of EPL services are described in Section 3. 191 Procedures related to signaling switching in support of EVPL services 192 are described in Section 4. Section 5 covers the generic GMPLS 193 extensions proposed by this document. 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. Common Signaling Support 203 This section describes the common mechanisms for supporting GMPLS 204 signaled control of LSPs that provide Ethernet connections as defined 205 in [MEF11], [G.8011.1] and [G.8011.2]. 207 Except as specifically modified in this document, the procedures 208 related to the processing of RSVP objects is not modified by this 209 document. The relevant procedures in existing documents, such as 210 [RFC3473], MUST be followed in all cases not explicitly described in 211 this document. 213 2.1. Ethernet Endpoint Identification 215 Ethernet endpoint identifiers, as they are defined in [G.8011] and 216 [MEF10.1], differ significantly from the identifiers used by GMPLS. 217 Specifically, the Ethernet endpoint identifiers are character based 218 as apposed to the GMPLS norm of being IP address based. 220 The approach taken by this document to address this disparity 221 leverages the solution used for connection identification, see 222 Section 2.2 and [RFC4974], and the LSP attributes object, see 223 [RFC4420]. The solution makes use of the [RFC4974] short call ID, 224 and supports the Ethernet endpoint identifier much like [RFC4974] 225 supports the long call ID. That is, the SENDER_TEMPLATE and SESSION 226 objects carry IP addresses and a short call ID, and long identifiers 227 are carried in the attributes object. As with the long call ID, the 228 Ethernet endpoint identifier is typically only relevant at the 229 ingress and egress nodes. 231 As defined below, the Ethernet endpoint identifier is carried in the 232 LSP_ATTRIBUTES object in a new TLV. The new TLV is referred to as 233 the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels 234 the processing of the long call ID in [RFC4974]. This processing 235 requires the inclusion of the LSP_ATTRIBUTES object in a Notify 236 message, see Section 5.1. 238 2.1.1. Endpoint ID TLV 240 The Endpoint ID TLV follows the Attributes TLV format defined in 241 [RFC4420]. The Endpoint ID TLV has uses the Type value of TBA (by 242 IANA). 244 The TLV has the following format: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type (TBA) | Length (variable) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Endpoint ID | 252 | ... | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 See [RFC4420] for a description of the Type and Length fields. 256 Note that per [RFC4420], the Length field is set to the unpadded 257 length of the Endpoint ID field. 259 Endpoint ID 261 The Endpoint ID field is a variable length field that carries 262 an endpoint identifier, see [MEF10.1] and [G.8011]. This field 263 MUST be null padded as defined in [RFC4420]. 265 2.1.1.1. Procedures 267 The use of the Endpoint ID TLV is required during call management. 268 When a call is established or torn down per [RFC4974], an 269 LSP_ATTRIBUTES object containing an Endpoint ID TLV MUST be included 270 in the Notify message along with the Long Call ID. 272 Short Call ID processing, including those procedures related to call 273 and connection processing, is not modified by this document and MUST 274 proceed according to [RFC4974]. 276 An LSP_ATTRIBUTES object containing an Endpoint ID TLV MAY be 277 included in the signaling messages of an LSP (connection) associated 278 with an established call. Such objects are processed according to 279 [RFC4420]. 281 Transit nodes supporting this document MUST propagate the Endpoint ID 282 TLV without modification. 284 2.2. Connection Identification 286 Signaling for Ethernet connections follows the procedures defined in 287 [RFC4974]. In particular the Call related mechanisms are reused to 288 support endpoint identification. In the context of Ethernet 289 connections, a call only exists when one or more LSPs (connections in 290 [RFC4974] terms) are present. An LSP will always be established 291 within the context of a call and, typically, only one LSP will be 292 used per call. See Section 4.4 for the case where more than one LSP 293 may exist within a call. 295 2.2.1. Procedures 297 Any node that supports Ethernet connections MUST be able to accept 298 and process call setups per [RFC4974]. Ethernet connections 299 established according to this document MUST treat the Ethernet 300 (virtual) connection identifier as the long "Call identifier (ID)", 301 described in [RFC4974]. The short Call ID MUST be used as described 302 in [RFC4974]. Use of the LINK_CAPABILITY object is OPTIONAL. Both 303 network-initiated and user-initiated Calls MUST be supported. 305 When establishing an Ethernet connection the initiator MUST first 306 establish a Call per the procedures defined in [RFC4974]. LSP 307 management, including removal and addition, then follows [RFC4974]. 308 As stated in [RFC4974], once a Call is established the initiator 309 SHOULD establish at least one Ethernet LSP. Also, when the last LSP 310 associated with a Call is removed, the Call SHOULD be torn down per 311 the procedures in [RFC4974]. 313 2.3. Traffic Parameters 315 Several types of service attributes are carried in the traffic 316 parameters defined in [MEF-TRAFFIC]. These parameters are carried in 317 the FLOWSPEC and TSPEC objects as discussed in [MEF-TRAFFIC]. The 318 service attributes that are carried are: 319 - Bandwidth Profile 320 - VLAN CoS Preservation 321 - Layer Two (L2) Control Protocol Processing (see Section 2.3.1) 323 Ethernet connections established according to this document MUST use 324 the traffic parameters defined in [MEF-TRAFFIC] in the FLOWSPEC and 325 TSPEC objects. 327 2.3.1. L2 Control Protocol TLV 329 [MEF10.1], [8011.1] and [8011.2] define service attributes that 330 impact the layer two (L2) control protocol processing at the ingress 331 and egress. [MEF-TRAFFIC] does not define support for these service 332 attributes, but does allow the attributes to be carried in a TLV. 333 This section defines the L2 Control Protocol (L2CP) TLV to carry the 334 L2 control protocol processing related service attributes. 336 The format of the L2 Control Protocol (L2CP) TLV is as follows: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type=2 | Length=4 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | IL2CP | EL2CP | Reserved | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 See [MEF-TRAFFIC] for a description of the Type and Length fields. 347 Per [MEF-TRAFFIC], the Type field MUST be set to two (2), and the 348 Length field MUST be set to four (4) for the L2CP TLV. 350 Ingress Layer 2 Control Processing (IL2CP): 4 bits 352 This field controls processing of Layer 2 Control Protocols 353 on a receiving interface. Valid usage is service specific, 354 see [MEF10.1], [8011.1] and [8011.2]. 356 Permitted values are: 358 Value Description Reference 359 ----- ----------- --------- 360 0 Reserved 361 1 Discard/Block [MEF10.1], [8011.1] and [8011.2] 362 2 Peer/Process [MEF10.1], [8011.1] and [8011.2] 363 3 Pass to EVC/Pass [MEF10.1], [8011.1] and [8011.2] 364 4 Peer and Pass to EVC [MEF10.1] 366 Egress Layer 2 Control Processing (EL2CP): 4 bits 368 This field controls processing of Layer 2 Control Protocols on 369 a transmitting interface. When MEF services are used a value 370 of 1 MUST be used, other valid usage is service specific, see 371 [8011.1] and [8011.2]. 373 Permitted values are: 375 Value Description Reference 376 ----- ----------- --------- 377 0 Reserved 378 1 Based on IL2CP Value [MEF10.1] 379 2 Generate [8011.1] and [8011.2] 380 3 None [8011.1] and [8011.2] 381 4 Reserved 383 Reserved: 24 bits 385 This field is reserved. It MUST be set to zero on transmission 386 and MUST be ignored on receipt. This field SHOULD be passed 387 unmodified by transit nodes. 389 Ethernet connections established according to this document MUST 390 include the L2CP TLV in the [MEF-TRAFFIC] traffic parameters carried 391 in the FLOWSPEC and TSPEC objects. 393 2.4. Bundling and VLAN Identification 395 The control of bundling and listing of VLAN identifiers is only 396 supported for EVPL services. EVPL service specific details are 397 provided in Section 4. 399 3. EPL Service 401 Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL) 402 services. In the words of [G.8011.1], EPL services carry "Ethernet 403 characteristic information over dedicated bandwidth, point-to-point 404 connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer 405 networks." [G.8011.1] defines two types of Ethernet Private Line 406 (EPL) services. Both types present a service where all data 407 presented on a port is transported to the corresponding connect port. 408 The types differ in that EPL type 1 service operates at the MAC frame 409 layer, while EPL type 2 service operates at the line (e.g., 8B/10B) 410 encoding layer. [MEF6] only defines one type of EPL service, and it 411 matches [G.8011.1] EPL type 1 service. Signaling for LSPs that 412 support both types of EPL services are detailed below. 414 3.1. EPL Service Parameters 416 Signaling for the EPL service types only differ in the LSP Encoding 417 Type used. The LSP Encoding Type used for each are: 419 EPL Service LSP Encoding Type 420 ----------- ----------------- 421 Type 1/MEF Ethernet (2) [RFC3471] 422 Type 2 Line (e.g., 8B/10B) (TBA by IANA) 424 The other LSP parameters specific to EPL Service are: 426 Parameter Value 427 -------------- ----- 428 Switching Type DCSC (See Section 5.2) 429 G-PID Ethernet (33) [RFC3471] 431 The parameters defined in this section MUST be used when establishing 432 and controlling LSPs that provide EPL service type Ethernet 433 switching. The procedures defined in Section 2 and the other 434 procedures defined in [RFC3473] for the establishment and management 435 of bidirectional LSPs MUST be followed when establishing and 436 controlling LSPs that provide EPL service type Ethernet switching. 438 4. EVPL Service 440 EVPL service is defined within the context of both [G.8011.2] and 441 [MEF6]. EVPL service allows for multiple Ethernet connections per 442 port, each of which supports a specific set of VLAN IDs. The service 443 attributes identify different forms of EVPL services, e.g., bundled 444 or unbundled. Independent of the different forms, LSPs supporting 445 EVPL Ethernet type switching are signaled using the same mechanisms 446 to communicate the one or more VLAN IDs associated with a particular 447 LSP (Ethernet connection). 449 The relevant [RFC3471] parameter values that MUST be used for EVPL 450 connections are: 452 Parameter Value 453 -------------- ----- 454 Switching Type TBD [NOTE: use of L2SC under discussion] 455 LSP Encoding Type Ethernet (2) 456 G-PID Ethernet (33) 458 As with EPL, the procedures defined in Section 2 and the other 459 procedures defined in [RFC3473] for the establishment and management 460 of bidirectional LSPs MUST be followed when establishing and 461 controlling LSPs that provide EVPL service type Ethernet switching. 463 LSPs that provide EVPL service type Ethernet switching MUST use the 464 EVPL Generalized Label Format per Section 4.1, and the Generalized 465 Channel_Set Label Objects per Section 5.2. A notable implication of 466 bundled EVPL services and carrying multiple VLAN IDs is that a Path 467 message may grow to be larger than a single (fragmented or non- 468 fragmented) IP packet. The basic approach to solving this is to 469 allow for multiple LSPs which are associated with a single call, see 470 Section 2.2. The specifics of this approach are describe below in 471 Section 4.4. 473 4.1. EVPL Generalized Label Format 475 Bundled EVPL services requires the use of a service specific label, 476 called the EVPL Generalized Label. For consistency, Non-bundled EVPL 477 services also use the same label. 479 The format for the Generalized Label (Label Type value 2) used with 480 EVPL services is: 482 0 1 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Rsvd | VLAN ID | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Reserved: 4 bits 490 This field is reserved. It MUST be set to zero on transmission 491 and MUST be ignored on receipt. This field SHOULD be passed 492 unmodified by transit nodes. 494 VLAN ID: 12 bits 496 A VLAN identifier. 498 4.2. Egress VLAN ID Control and VLAN ID preservation 500 Per [MEF6], the mapping of the single VLAN ID used at the incoming 501 interface of the ingress to a different VLAN ID at the outgoing 502 interface at the egress UNI is allowed for EVPL services that do not 503 support both bundling and VLAN ID preservation. Such a mapping MUST 504 be requested and signaled based on the explicit label control 505 mechanism defined in [RFC3473] and clarified in [RFC4003]. 507 When the explicit label control mechanism is not used, VLAN IDs MUST 508 be preserved, i.e., not modified, across an LSP. 510 4.3. Single Call - Single LSP 512 For simplicity in management, a single LSP SHOULD be used for each 513 EVPL type LSP whose Path and Resv messages fit within a single 514 unfragmented IP packet. This allows the reuse of all standard LSP 515 modification procedures. Of particular note is the modification of 516 the VLAN IDs associated with the Ethernet connection. Specifically, 517 per Section 5.3, make-before-break procedures SHOULD be used to 518 modify the Channel_Set LABEL object. 520 4.4. Single Call - Multiple LSPs 522 Multiple LSPs MAY be used to support an EVPL service connection. All 523 such LSPs MUST be established within the same call and follow call 524 related procedures, see Section 2.2. The primary purpose of multiple 525 LSPs is to support the case where the related objects result in a 526 Path message being larger than a single unfragmented IP packet. 528 When using multiple LSPs, all LSPs associated with the same call / 529 EVPL connection MUST be signaled with the same LSP objects with the 530 exception of the SENDER_TEMPLATE, SESSION and label related objects. 531 All such LSPs SHOULD share resources. When using multiple LSPs, VLAN 532 IDs MAY be added to the EVPL connection using either a new LSP or 533 make-before-break procedures, see [RFC3209]. Make-before-break 534 procedures on individual LSPs SHOULD be used to remove VLAN IDs. 536 To change other service parameters it is necessary to resignal all 537 LSPs associated with the call via make-before-break procedures. 539 5. Generic GMPLS Extensions 541 This section presents extensions to GMPLS that, while motivated by 542 EPL and EVPL service, are generic in nature and may be useful to any 543 switching technology controlled via GMPLS. 545 [AUTHORS' NOTE: The extensions presented in this section and may be 546 split into one or more independent documents as this work 547 progresses.] 549 5.1. Notify Message Format 551 The Notify message format is extended based on the format defined in 552 [RFC4974] to allow for the use of the LSP_ATTRIBUTES object as 553 defined in this document. The inclusion of an LSP_ATTRIBUTES object 554 in Notify messages is optional. When present, the LSP_ATTRIBUTES 555 object SHOULD follow the SESSION_ATTRIBUTE object. 557 The format of the Notify Message is updated as follows: 559 ::= see [RFC4974] 561 ::= [ ] 562 [ ...] 563 [ ] 564 [ ] 565 [ ] 566 [ | ] 568 ::= see [RFC3473] 570 ::= see [RFC3473] 572 5.2. Data Channel Switching 574 Current GMPLS switching types are defined in [RFC3945] and [RFC3471] 575 and support switching at the packet (PSC), frame (L2SC), time-slot 576 (TDM), frequency (LSC) and fiber (FSC) granularities. One type of 577 switching that is not well represented in this current set switching 578 that takes all data received on an ingress port and switches it 579 through a network to an egress port. While there are similarities 580 between this level of switching and the "opaque single wavelength" 581 case described in Section 3.5 of [RFC4202], such port-to-port 582 switching is not limited to the optical switching technology implied 583 by the LSC type. Therefore, a new switching type is defined. 585 The new switching type is called Data Channel Switching Capable 586 (DCSC). (Port switching seems a more intuitive name, but it collides 587 with PSC so isn't used.) DCSC interfaces are able to support 588 switching of the whole digital channel presented on single channel 589 interfaces. Interfaces that inherently support multiple channels, 590 e.g., WDM and channelized TDM interfaces, are specifically excluded 591 from this type. Any interface that can be represented as a single 592 digital channel are included. Examples include concatenated TDM and 593 line encoded interfaces. Framed interfaces may also be included when 594 they support switching on an interface granularity. 596 DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the 597 value TBA (by IANA). 599 Port labels, as defined in [RFC3471], SHOULD be used for LSPs 600 signaled using the DCSC Switching Type. 602 5.3. Generalized Channel_Set Label Related Formats 604 This section defines a new type of generalized label and updates 605 related objects. This section updates the label related definitions 606 of [RFC3473]. The ability to communicate more than one label as part 607 of the same LSP was motivated by the support for the communication of 608 one or more VLAN IDs, but the formats defined in this section are not 609 technology specific and may be useful for other switching 610 technologies. 612 5.3.1. Generalized Channel_Set LABEL_REQUEST Object 614 The Generalized Channel_Set LABEL_REQUEST object is used to indicate 615 that the Generalized Channel_Set LABEL Object is to be used with the 616 associated LSP. The format of the Generalized Channel_Set 617 LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST 618 object and uses of C-Type of TBA. 620 5.3.2. Generalized Channel_Set LABEL Object 622 The Generalized Channel_Set LABEL Object communicates one or more 623 labels, all of which can be used equivalently in the data path 624 associated with a single LSP. The format of the Generalized 625 Channel_Set LABEL Object is based on the LABEL_SET object defined in 626 [RFC3473]. It differs from the the LABEL_SET object in that the full 627 set may be represented in a single object rather than the multiple 628 objects required by the [RFC3473] LABEL_SET object. The object MUST 629 be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST 630 object. The object MUST be processed per [RFC3473]. Make-before- 631 break procedures, see [RFC3209], SHOULD be used when modifying the 632 Channel_Set LABEL object. 634 The format of the Generalized Channel_Set LABEL object is: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Length | Class-Num (16)| C-Type (TBA) | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Channel_Set Sub-Object 1 | 642 | ... | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 : : : 645 : : : 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Channel_Set Sub-Object N | 648 | ... | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 The Channel_Set Sub-Object size is measured in bytes and MUST always 652 be a multiple of 4, and at least 4, and has the following format: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Action | Num Subchannels | Label Type | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Subchannel 1 | 660 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | ... | : 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 663 : : : 664 : : : 665 : : : 666 : : : 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Subchannel N | 669 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | ... | Padding | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Action: 8 bits 675 See [RFC3471] for definition of actions. Range actions SHOULD 676 be used when possible to minimize the size of the Channel_Set 677 LABEL Object. 679 Number of Subchannels: 10 bits 681 Indicates the number of subchannels carried in the sub-object. 682 When the number of subchannels required exceeds the limit of 683 the field, i.e., 1024, multiple Channel_Set Sub-Objects MUST be 684 used. Note that the size of the sub-object may result in a 685 Path message being larger than a single unfragmented IP packet. 686 See section 4.4 for an example of how this case may be handled. 688 A value of zero (0) has special meaning and MAY be used in 689 either the LABEL or UPSTREAM_LABEL object. A value of zero (0) 690 is used in a LABEL or UPSTREAM_LABEL object to indicate that 691 the subchannel(s) used in the corresponding (downstream or 692 upstream) direction MUST match the subchannel(s) carried in the 693 reverse directions label object. When value of zero (0) is 694 used, no Subchannels are included in the Channel_Set Sub-Object 695 and only one Channel_Set Sub-Object may be present. The zero 696 (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL 697 object of the same LSP. 699 Label Type: 14 bits 701 See [RFC3473] for a description of this field. 703 Subchannel: Variable 705 See [RFC3471] for a description of this field. Note that this 706 field may not be 32 bit aligned. 708 Padding: Variable 710 Padding is used to ensure that the length of a Channel_Set Sub- 711 Object meets the multiple of 4 byte size requirement stated 712 above. The field is only required when the Subchannel field is 713 not 32 bit aligned and the number of included Subchannel fields 714 result in the Sub-Object not being 32 bit aligned. 716 The Padding field MUST be included when the number of bits 717 represented in all the Subchannel fields included in a 718 Generalized Channel_Set Sub-Object result in the Sub-Object not 719 being 32 bit aligned. When present, the Padding field MUST 720 have a length that results in the Sub-Object being 32 bit 721 aligned. When present, the Padding field MUST be set to a zero 722 (0) value on transmission and MUST be ignored on receipt. 723 These bits SHOULD be passed through unmodified by transit 724 nodes. 726 5.3.3. Other Label Related Objects 728 The previous section introduces a new LABEL object. As such the 729 formats of the other label related objects are also impacted. 730 Processing of these objects is not modified and remain per their 731 respective specifications. The other label related objects are 732 defined in [RFC3473] and include: 733 - SUGGESTED_LABEL object 734 - LABEL_SET object 735 - ACCEPTABLE_LABEL_SET object 736 - UPSTREAM_LABEL object 737 - RECOVERY_LABEL object 739 6. IANA Considerations 741 IANA is requested to administer assignment of new values for 742 namespaces defined in this document and reviewed in this section. 744 6.1. Endpoint ID Attributes TLV 746 Upon approval of this document, the IANA will make the assignment in 747 the "Attributes TLV Space" section of the "RSVP TE Parameters" 748 registry located at http://www.iana.org/assignments/rsvp-te- 749 parameters: 751 Allowed on Allowed on 752 Type Name LSP_ATTRIBUTES LSP_REQUIRED_ATTRIBUTES Reference 753 ---- ----------- -------------- ----------------------- --------- 754 2* Endpoint ID Yes Yes [This document] 756 (*) Suggested value. 758 6.2. Line LSP Encoding 760 Upon approval of this document, the IANA will make the assignment in 761 the "LSP Encoding Types" section of the "GMPLS Signaling Parameters" 762 registry located at http://www.iana.org/assignments/gmpls-sig- 763 parameters: 765 Value Type Reference 766 ----- --------------------------- --------- 767 14* Line (e.g., 8B/10B) [This document] 769 (*) Suggested value. 771 6.3. Data Channel Switching Type 773 Upon approval of this document, the IANA will make the assignment in 774 the "Switching Types" section of the "GMPLS Signaling Parameters" 775 registry located at http://www.iana.org/assignments/gmpls-sig- 776 parameters: 778 Value Type Reference 779 ----- --------------------------- --------- 780 125* Data Channel Switching Capable (DCSC) [This document] 782 (*) Suggested value. 784 6.4. Generalized Channel_Set LABEL_REQUEST Object 786 Upon approval of this document, the IANA will make the assignment in 787 the "Class Names, Class Numbers, and Class Types" section of the 788 "RSVP PARAMETERS" registry located at 789 http://www.iana.org/assignments/rsvp-parameters. 791 A new class type for the existing LABEL_REQUEST Object class number 792 (19) with the following definition: 794 Class Types or C-Types: 796 5* Generalized Channel_Set [This document] 798 (*) Suggested value. 800 6.5. Generalized Channel_Set LABEL Object 802 Upon approval of this document, the IANA will make the assignment in 803 the "Class Names, Class Numbers, and Class Types" section of the 804 "RSVP PARAMETERS" registry located at 805 http://www.iana.org/assignments/rsvp-parameters. 807 A new class type for the existing RSVP_LABEL Object class number (16) 808 with the following definition: 810 Class Types or C-Types: 812 4* Generalized Channel_Set [This document] 814 (*) Suggested value. 816 7. Security Considerations 818 This document introduces new message object formats for use in GMPLS 819 signaling [RFC3473]. It does not introduce any new signaling 820 messages, nor change the relationship between LSRs that are adjacent 821 in the control plane. As such, this document introduces no additional 822 security considerations. See [RFC3473] for relevant security 823 considerations. 825 8. References 827 8.1. Normative References 829 [MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic 830 Parameters," 831 draft-ietf-ccamp-ethernet-traffic-parameters-03.txt, 832 Work in progress, November 2007. 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels," RFC 2119. 837 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 838 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 839 to RSVP for LSP Tunnels", RFC 3209, December 2001. 841 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 842 Switching (GMPLS) Signaling Functional Description", 843 RFC 3471, January 2003. 845 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 846 Switching (GMPLS) Signaling - Resource ReserVation 847 Protocol-Traffic Engineering (RSVP-TE) Extensions", 848 RFC 3473, January 2003. 850 [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label 851 Switching (GMPLS) Architecture", RFC 3945, October 852 2004. 854 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 855 Control", RFC 4003, February 2005. 857 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 858 Extensions in Support of Generalized Multi-Protocol 859 Label Switching (GMPLS)", RFC 4202, October 2005. 861 [RFC4420] Farrel, A., et al. "Encoding of Attributes for 862 Multiprotocol Label Switching (MPLS) Label Switched Path 863 (LSP) Establishment Using Resource ReserVation 864 Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, 865 February 2006. 867 [RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS 868 (GMPLS) RSVP-TE Signaling Extensions in support of Calls", 869 RFC 4974, August 2007. 871 8.2. Informative References 873 [G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport 874 Ethernet services framework", August 2004. 876 [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private 877 line service", August 2004. 879 [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual 880 private line service", September 2005. 882 [GMPLS-MEF-UNI] Berger, L., Papadimitriou, P., Fedyk, D., 883 "Generalized MPLS (GMPLS) Support For Metro 884 Ethernet Forum and G.8011 User-Network Interface 885 (UNI)", Work in Progress, 886 draft-berger-ccamp-gmpls-mef-uni-02.txt, 887 February 2008. 889 [MEF6] The Metro Ethernet Forum, "Ethernet Services 890 Definitions - Phase I", MEF 6, June 2004 892 [MEF10.1] The Metro Ethernet Forum, "Ethernet Services 893 Attributes Phase 2", MEF 10.1, November 2006. 895 [MEF11] The Metro Ethernet Forum , "User Network 896 Interface (UNI) Requirements and Framework", 897 MEF 11, November 2004. 899 [RFC4875] Aggarwal, R., Papadimitriou, P., Yasukawa, S., 900 Eds, "Extensions to Resource Reservation 901 Protocol - Traffic Engineering (RSVP-TE) for 902 Point-to-Multipoint TE Label Switched Paths 903 (LSPs)", RFC 4875, May 2007. 905 9. Acknowledgments 907 The authors would like to thank Evelyne Roch and Stephen Shew for 908 their valuable comments. 910 10. Author's Addresses 912 Lou Berger 913 LabN Consulting, L.L.C. 914 Phone: +1-301-468-9228 915 Email: lberger@labn.net 917 Dimitri Papadimitriou 918 Alcatel Lucent 919 Francis Wellesplein 1, 920 B-2018 Antwerpen, Belgium 921 Phone: +32 3 240-8491 922 Email: Dimitri.Papadimitriou@alcatel-lucent.be 924 Don Fedyk 925 Nortel Networks 926 600 Technology Park Drive 927 Billerica, MA, 01821 928 Phone: +1-978-288-3041 929 Email: dwfedyk@nortel.com 931 11. Full Copyright Statement 933 Copyright (C) The IETF Trust (2008). 935 This document is subject to the rights, licenses and restrictions 936 contained in BCP 78, and except as set forth therein, the authors 937 retain all their rights. 939 This document and the information contained herein are provided on an 940 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 941 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 942 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 943 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 944 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 945 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 947 12. Intellectual Property 949 The IETF takes no position regarding the validity or scope of any 950 Intellectual Property Rights or other rights that might be claimed 951 to pertain to the implementation or use of the technology 952 described in this document or the extent to which any license 953 under such rights might or might not be available; nor does it 954 represent that it has made any independent effort to identify any 955 such rights. Information on the procedures with respect to rights 956 in RFC documents can be found in BCP 78 and BCP 79. 958 Copies of IPR disclosures made to the IETF Secretariat and any 959 assurances of licenses to be made available, or the result of an 960 attempt made to obtain a general license or permission for the use 961 of such proprietary rights by implementers or users of this 962 specification can be obtained from the IETF on-line IPR repository 963 at http://www.ietf.org/ipr. 965 The IETF invites any interested party to bring to its attention 966 any copyrights, patents or patent applications, or other 967 proprietary rights that may cover technology that may be required 968 to implement this standard. Please address the information to the 969 IETF at ietf-ipr@ietf.org. 971 Acknowledgement 973 Funding for the RFC Editor function is provided by the IETF 974 Administrative Support Activity (IASA). 976 Generated on: Fri Feb 15 10:37:43 EST 2008