idnits 2.17.1 draft-ietf-ccamp-gmpls-ether-svcs-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 5307 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Category: Standards Track Don Fedyk (Alcatel-Lucent) 3 Expiration Date: April 14, 2010 5 October 14, 2009 7 Generalized MPLS (GMPLS) Support For Metro Ethernet Forum 8 and G.8011 Ethernet Service Switching 10 draft-ietf-ccamp-gmpls-ether-svcs-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 14, 2010. 40 Copyright and License Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document describes a method for controlling two specific types 54 of Ethernet switching via Generalized Multi-Protocol Label Switching 55 (GMPLS). This document supports the types of switching corresponding 56 to the Ethernet services that have been defined in the context of the 57 Metro Ethernet Forum (MEF) and International Telecommunication Union 58 (ITU) G.8011. Specifically, switching in support of Ethernet private 59 line and Ethernet virtual private line services are covered. Support 60 for MEF and ITU defined parameters is also covered. 62 Table of Contents 64 1 Introduction ........................................... 3 65 1.1 Overview ............................................... 3 66 1.2 Conventions used in this document ...................... 5 67 2 Common Signaling Support ............................... 5 68 2.1 Ethernet Endpoint Identification ....................... 5 69 2.1.1 Endpoint ID TLV ........................................ 6 70 2.2 Connection Identification .............................. 6 71 2.2.1 Procedures ............................................. 7 72 2.3 Traffic Parameters ..................................... 7 73 2.3.1 L2 Control Protocol TLV ................................ 7 74 2.4 Bundling and VLAN Identification ....................... 9 75 3 EPL Service ............................................ 9 76 3.1 EPL Service Parameters ................................. 9 77 4 EVPL Service ........................................... 10 78 4.1 EVPL Generalized Label Format .......................... 11 79 4.2 Egress VLAN ID Control and VLAN ID preservation ........ 11 80 4.3 Single Call - Single LSP ............................... 12 81 4.4 Single Call - Multiple LSPs ............................ 12 82 5 IANA Considerations .................................... 12 83 5.1 Endpoint ID Attributes TLV ............................. 12 84 5.2 Line LSP Encoding ...................................... 13 85 5.3 Ethernet Virtual Private Line (EVPL) Switching Type .... 13 86 6 Security Considerations ................................ 13 87 7 References ............................................. 14 88 7.1 Normative References ................................... 14 89 7.2 Informative References ................................. 15 90 8 Acknowledgments ........................................ 15 91 9 Author's Addresses ..................................... 16 93 1. Introduction 95 [MEF6] and [G.8011] provide parallel frameworks for defining network- 96 oriented characteristics of Ethernet services in transport networks. 97 The framework discusses general Ethernet connection characteristics, 98 Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network 99 Interfaces (NNIs). Within this framework, [G.8011.1] defines the 100 Ethernet Private Line (EPL) service and [G.8011.2] defines the 101 Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both 102 service types. [MEF10.1] defines service parameters and [MEF11] 103 provides UNI requirements and framework. 105 [MEF6] and [G.8011] are focused on service interfaces and not the 106 underlying technology used to support the service. For example, 107 [G.8011] refers to the defined services being transported over one of 108 several possible "server layers". This document focuses on the types 109 of switching that may directly support these services and provides a 110 method for GMPLS based control of such switching technologies. This 111 document defines the GMPLS extensions needed to support such 112 switching, but does not define the UNI or External NNI (E-NNI) 113 reference points. See [GMPLS-MEF-UNI] for a description of the UNI 114 reference point. This document makes use of the traffic parameters 115 defined in [ETH-TRAFFIC] and the generic extensions defined in 116 [GMPLS-EXT]. 118 1.1. Overview 120 This document uses a common approach to supporting the switching 121 corresponding to the Ethernet services defined in [MEF6], [G.8011.1] 122 and [G.8011.2]. The approach builds on standard GMPLS mechanisms to 123 deliver the required control capabilities. This document reuses the 124 GMPLS mechanisms specified in [RFC3473] and [RFC4974]. The document 125 uses the extensions defined in [GMPLS-EXT]. 127 Two types of connectivity between Ethernet endpoints are defined in 128 [MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to- 129 multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to 130 refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) 131 to refer to multipoint-to-multipoint virtual connections. [G.8011] 132 also identifies point-to-multipoint (P2MP) as an area for "further 133 study." Within the context of GMPLS, support is defined for point- 134 to-point unidirectional and bidirectional TE Label Switched Paths 135 (LSPs), see [RFC3473], and unidirectional point-to-multipoint TE 136 LSPs, see [RFC4875]. 138 Support for P2P and MP2MP services is defined by [G.8011] and 139 required by [MEF11]. Note that while [MEF11] and [G.8011] discuss 140 MP2MP, [G.8011.1] and [G.8011.2] only define support for P2P. There 141 is a clear correspondence between E-Line/P2P service and GMPLS P2P TE 142 LSPs, and support for such LSPs is included in the scope of this 143 document. There is no such clear correspondence between E-LAN/MP2MP 144 service and GMPLS TE LSPs. Although, it is possible to emulate this 145 service using multiple P2P or P2MP TE LSPs, the definition of support 146 for MP2MP service is left for future study and is not addressed in 147 this document. 149 [MEF11] defines multiple types of control for UNI Ethernet services. 150 In MEF UNI Type 1, services are configured manually. In MEF UNI Type 151 2, services may be configured manually or via a link management 152 interface. In MEF UNI Type 3, services may be established and 153 managed via a signaling interface. From the MEF perspective, this 154 document along with [GMPLS-MEF-UNI] is aimed at the network control 155 needed to support the MEF UNI Type 3 mode of operation. 157 [G.8011.1], [G.8011.2] and [MEF11] together with [MEF10.1] define a 158 set of service attributes that are associated with each Ethernet 159 connection. Some of these attributes are based on the provisioning 160 of the local physical connection and are not modifiable or selectable 161 per connection. Other attributes are specific to a particular 162 connection, or must be consistent across the connection. The 163 approach taken in this document to communicate these attributes is to 164 exclude the static class of attributes from signaling. This class of 165 attributes will not be explicitly discussed in this document. The 166 other class of attributes is communicated via signaling and will be 167 reviewed in the sections below. The major attributes that will be 168 supported in signaling include: 169 - Endpoint identifiers 170 - Connection identifiers 171 - Traffic parameters (see [ETH-TRAFFIC]) 172 - Bundling / VLAN IDs map (EVPL only) 173 - VLAN ID Preservation (EVPL only) 175 Common procedures used to support Ethernet LSPs are described in 176 Section 2 of this document. Procedures related to the signaling of 177 switching in support of EPL services are described in Section 3. 178 Procedures related to the signaling of switching in support of EVPL 179 services are described in Section 4. 181 1.2. Conventions used in this document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 2. Common Signaling Support 189 This section describes the common mechanisms for supporting GMPLS 190 signaled control of LSPs that provide Ethernet connections as defined 191 in [MEF11], [G.8011.1] and [G.8011.2]. 193 Except as specifically modified in this document, the procedures 194 related to the processing of RSVP objects are not modified by this 195 document. The relevant procedures in existing documents, such as 196 [RFC3473], MUST be followed in all cases not explicitly described in 197 this document. 199 2.1. Ethernet Endpoint Identification 201 Ethernet endpoint identifiers, as they are defined in [G.8011] and 202 [MEF10.1], differ significantly from the identifiers used by GMPLS. 203 Specifically, the Ethernet endpoint identifiers are character based 204 as opposed to the GMPLS norm of being IP address based. 206 The approach taken by this document to address this disparity 207 leverages the solution used for connection identification, see 208 Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in 209 this document. The solution makes use of the [RFC4974] short call 210 ID, and supports the Ethernet endpoint identifier similar to 211 [RFC4974] supports the long call ID. That is, the SENDER_TEMPLATE 212 and SESSION objects carry IP addresses and a short call ID, and long 213 identifiers are carried in the CALL_ATTRIBUTES object. As with the 214 long call ID, the Ethernet endpoint identifier is typically only 215 relevant at the ingress and egress nodes. 217 As defined below, the Ethernet endpoint identifier is carried in the 218 CALL_ATTRIBUTES object in a new TLV. The new TLV is referred to as 219 the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels 220 the processing of the long call ID in [RFC4974]. This processing 221 requires the inclusion of the CALL_ATTRIBUTES object in a Notify 222 message. 224 2.1.1. Endpoint ID TLV 226 The Endpoint ID TLV follows the Attributes TLV format defined in 227 [GMPLS-MRN]. The Endpoint ID TLV has the following format: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type (TBA) | Length (variable) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Endpoint ID | 235 | ... | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Type and Length fields are defined in [GMPLS-MRN]. Note that as 239 defined in [GMPLS-MRN], the Length field is set to length of the 240 whole TLV including the Type, Length and Endpoint ID fields. 242 Endpoint ID 244 The Endpoint ID field is a variable size field that carries an 245 endpoint identifier, see [MEF10.1] and [G.8011]. This field 246 MUST be null padded as defined in [GMPLS-MRN]. 248 2.1.1.1. Procedures 250 The use of the Endpoint ID TLV is required during call management. 251 When a call is established or torn down per [RFC4974], a 252 CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included 253 in the Notify message along with the Long Call ID. 255 Short Call ID processing, including those procedures related to call 256 and connection processing, is not modified by this document and MUST 257 proceed according to [RFC4974]. 259 2.2. Connection Identification 261 Signaling for Ethernet connections follows the procedures defined in 262 [RFC4974]. In particular the Call related mechanisms are used to 263 support endpoint identification. In the context of Ethernet 264 connections, a call is only established when one or more LSPs 265 (connections in [RFC4974] terms) are needed. An LSP will always be 266 established within the context of a call and, typically, only one LSP 267 will be used per call. See Section 4.4 for the case where more than 268 one LSP may exist within a call. 270 2.2.1. Procedures 272 Any node that supports Ethernet connections MUST be able to accept 273 and process call setups per [RFC4974]. Ethernet connections 274 established according to this document MUST treat the Ethernet 275 (virtual) connection identifier as the long "Call identifier (ID)", 276 described in [RFC4974]. The short Call ID MUST be used as described 277 in [RFC4974]. Use of the LINK_CAPABILITY object is OPTIONAL. Both 278 network-initiated and user-initiated Calls MUST be supported. 280 When establishing an Ethernet connection the initiator MUST first 281 establish a Call per the procedures defined in [RFC4974]. LSP 282 management, including removal and addition, then follows [RFC4974]. 283 As stated in [RFC4974], once a Call is established, the initiator 284 SHOULD establish at least one Ethernet LSP. Also, when the last LSP 285 associated with a Call is removed, the Call SHOULD be torn down per 286 the procedures in [RFC4974]. 288 2.3. Traffic Parameters 290 Several types of service attributes are carried in the traffic 291 parameters defined in [ETH-TRAFFIC]. These parameters are carried in 292 the FLOWSPEC and TSPEC objects as discussed in [ETH-TRAFFIC]. The 293 service attributes that are carried are: 294 - Bandwidth Profile 295 - VLAN CoS Preservation 296 - Layer Two (L2) Control Protocol Processing (see Section 2.3.1) 298 Ethernet connections established according to this document MUST use 299 the traffic parameters defined in [ETH-TRAFFIC] in the FLOWSPEC and 300 TSPEC objects. Additionally, the Switching Granularity field of the 301 Ethernet SENDER_TSPEC object MUST be set to zero (0). 303 2.3.1. L2 Control Protocol TLV 305 [MEF10.1], [8011.1] and [8011.2] define service attributes that 306 impact the layer two (L2) control protocol processing at the ingress 307 and egress. [ETH-TRAFFIC] does not define support for these service 308 attributes, but does allow the attributes to be carried in a TLV. 309 This section defines the L2 Control Protocol (L2CP) TLV to carry the 310 L2 control protocol processing related service attributes. 312 The format of the L2 Control Protocol (L2CP) TLV is as follows: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type=3 | Length=8 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | IL2CP | EL2CP | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 See [ETH-TRAFFIC] for a description of the Type and Length fields. 323 Per [ETH-TRAFFIC], the Type field MUST be set to three (3), and 324 the Length field MUST be set to eight (8) for the L2CP TLV. 326 Ingress Layer 2 Control Processing (IL2CP): 4 bits 328 This field controls processing of Layer 2 Control Protocols 329 on a receiving interface. Valid usage is service specific, 330 see [MEF10.1], [8011.1] and [8011.2]. 332 Permitted values are: 334 Value Description Reference 335 ----- ----------- --------- 336 0 Reserved 337 1 Discard/Block [MEF10.1], [8011.1] and [8011.2] 338 2 Peer/Process [MEF10.1], [8011.1] and [8011.2] 339 3 Pass to EVC/Pass [MEF10.1], [8011.1] and [8011.2] 340 4 Peer and Pass to EVC [MEF10.1] 342 Egress Layer 2 Control Processing (EL2CP): 4 bits 344 This field controls processing of Layer 2 Control Protocols on 345 a transmitting interface. When MEF services are used a value 346 of 1 MUST be used, other valid usage is service specific, see 347 [8011.1] and [8011.2]. 349 Permitted values are: 351 Value Description Reference 352 ----- ----------- --------- 353 0 Reserved 354 1 Based on IL2CP Value [MEF10.1] 355 2 Generate [8011.1] and [8011.2] 356 3 None [8011.1] and [8011.2] 357 4 Reserved 359 Reserved: 24 bits 361 This field is reserved. It MUST be set to zero on transmission 362 and MUST be ignored on receipt. This field SHOULD be passed 363 unmodified by transit nodes. 365 Ethernet connections established according to this document MUST 366 include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried 367 in the FLOWSPEC and TSPEC objects. 369 2.4. Bundling and VLAN Identification 371 The control of bundling and listing of VLAN identifiers is only 372 supported for EVPL services. EVPL service specific details are 373 provided in Section 4. 375 3. EPL Service 377 Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL) 378 service. In the words of [G.8011.1], EPL services carry "Ethernet 379 characteristic information over dedicated bandwidth, point-to-point 380 connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer 381 networks." [G.8011.1] defines two types of Ethernet Private Line 382 (EPL) services. Both types present a service where all data 383 presented on a port is transported to the corresponding connect port. 384 The types differ in that EPL type 1 service operates at the MAC frame 385 layer, while EPL type 2 service operates at the line (e.g., 8B/10B) 386 encoding layer. [MEF6] only defines one type of EPL service, and it 387 matches [G.8011.1] EPL type 1 service. Signaling for LSPs that 388 support both types of EPL services are detailed below. 390 3.1. EPL Service Parameters 392 Signaling for the EPL service types only differ in the LSP Encoding 393 Type used. The LSP Encoding Type used for each are: 395 EPL Service LSP Encoding Type 396 ----------- ----------------- 397 Type 1/MEF Ethernet (2) [RFC3471] 398 Type 2 Line (e.g., 8B/10B) [This document] (TBA by IANA) 400 The other LSP parameters specific to EPL Service are: 402 Parameter Value 403 -------------- ----- 404 Switching Type DCSC [GMPLS-EXT] 405 G-PID Ethernet (33) [RFC3471] 407 The parameters defined in this section MUST be used when establishing 408 and controlling LSPs that provide EPL service type Ethernet 409 switching. The procedures defined in Section 2 and the other 410 procedures defined in [RFC3473] for the establishment and management 411 of bidirectional LSPs MUST be followed when establishing and 412 controlling LSPs that provide EPL service type Ethernet switching. 414 4. EVPL Service 416 EVPL service is defined within the context of both [G.8011.2] and 417 [MEF6]. EVPL service allows for multiple Ethernet connections per 418 port, each of which supports a specific set of VLAN IDs. The service 419 attributes identify different forms of EVPL services, e.g., bundled 420 or unbundled. Independent of the different forms, LSPs supporting 421 EVPL Ethernet type switching are signaled using the same mechanisms 422 to communicate the one or more VLAN IDs associated with a particular 423 LSP (Ethernet connection). 425 The relevant [RFC3471] parameter values that MUST be used for EVPL 426 connections are: 428 Parameter Value 429 -------------- ----- 430 Switching Type EVPL [This document] (TBA by IANA) 431 LSP Encoding Type Ethernet (2) 432 G-PID Ethernet (33) 434 As with EPL, the procedures defined in Section 2 and the other 435 procedures defined in [RFC3473] for the establishment and management 436 of bidirectional LSPs MUST be followed when establishing and 437 controlling LSPs that provide EVPL service type Ethernet switching. 439 LSPs that provide EVPL service type Ethernet switching MUST use the 440 EVPL Generalized Label Format per Section 4.1, and the Generalized 441 Channel_Set Label Objects per [GMPLS-EXT]. A notable implication of 442 bundled EVPL services and carrying multiple VLAN IDs is that a Path 443 message may grow to be larger than a single (fragmented or non- 444 fragmented) IP packet. The basic approach to solving this is to 445 allow for multiple LSPs which are associated with a single call, see 446 Section 2.2. The specifics of this approach are describe below in 447 Section 4.4. 449 4.1. EVPL Generalized Label Format 451 Bundled EVPL services require the use of a service specific label, 452 called the EVPL Generalized Label. For consistency, Non-bundled EVPL 453 services also use the same label. 455 The format for the Generalized Label (Label Type value 2) used with 456 EVPL services is: 458 0 1 459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Rsvd | VLAN ID | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Reserved: 4 bits 466 This field is reserved. It MUST be set to zero on transmission 467 and MUST be ignored on receipt. This field SHOULD be passed 468 unmodified by transit nodes. 470 VLAN ID: 12 bits 472 A VLAN identifier. 474 4.2. Egress VLAN ID Control and VLAN ID preservation 476 When an EVPL service is not configured for both bundling and VLAN ID 477 preservation, [MEF6] allows VLAN ID mapping. In particular, the 478 single VLAN ID used at the incoming interface of the ingress may be 479 mapped to a different VLAN ID at the outgoing interface at the egress 480 UNI. Such mapping MUST be requested and signaled based on the 481 explicit label control mechanism defined in [RFC3473] and clarified 482 in [RFC4003]. 484 When the explicit label control mechanism is not used, VLAN IDs MUST 485 be preserved, i.e., not modified, across an LSP. 487 4.3. Single Call - Single LSP 489 For simplicity in management, a single LSP SHOULD be used for each 490 EVPL type LSP whose Path and Resv messages fit within a single 491 unfragmented IP packet. This allows the reuse of all standard LSP 492 modification procedures. Of particular note is the modification of 493 the VLAN IDs associated with the Ethernet connection. Specifically, 494 [GMPLS-EXT], make-before-break procedures SHOULD be used to modify 495 the Channel_Set LABEL object. 497 4.4. Single Call - Multiple LSPs 499 Multiple LSPs MAY be used to support an EVPL service connection. All 500 such LSPs MUST be established within the same call and follow call 501 related procedures, see Section 2.2. The primary purpose of multiple 502 LSPs is to support the case where the related objects result in a 503 Path message being larger than a single unfragmented IP packet. 505 When using multiple LSPs, all LSPs associated with the same call / 506 EVPL connection MUST be signaled with the same LSP objects with the 507 exception of the SENDER_TEMPLATE, SESSION and label related objects. 508 All such LSPs SHOULD share resources. When using multiple LSPs, VLAN 509 IDs MAY be added to the EVPL connection using either a new LSP or 510 make-before-break procedures, see [RFC3209]. Make-before-break 511 procedures on individual LSPs SHOULD be used to remove VLAN IDs. 513 To change other service parameters it is necessary to resignal all 514 LSPs associated with the call via make-before-break procedures. 516 5. IANA Considerations 518 IANA is requested to administer assignment of new values for 519 namespaces defined in this document and summarized in this section. 521 5.1. Endpoint ID Attributes TLV 523 Upon approval of this document, IANA will make the assignment in the 524 "CALL_ATTRIBUTES TLV Space" section of the "RSVP TE Parameters" 525 registry located at http://www.iana.org/assignments/rsvp-te- 526 parameters: 528 Type Name Reference 529 ---- ----------- --------- 530 2* Endpoint ID [This document] 532 (*) Suggested value. 534 5.2. Line LSP Encoding 536 Upon approval of this document, IANA will make the assignment in the 537 "LSP Encoding Types" section of the "GMPLS Signaling Parameters" 538 registry located at http://www.iana.org/assignments/gmpls-sig- 539 parameters: 541 Value Type Reference 542 ----- --------------------------- --------- 543 14* Line (e.g., 8B/10B) [This document] 545 (*) Suggested value. 547 5.3. Ethernet Virtual Private Line (EVPL) Switching Type 549 Upon approval of this document, IANA will make the assignment in the 550 "Switching Types" section of the "GMPLS Signaling Parameters" 551 registry located at http://www.iana.org/assignments/gmpls-sig- 552 parameters: 554 Value Type Reference 555 ----- --------------------------- --------- 556 30* Ethernet Virtual Private Line (EVPL) [This document] 558 (*) Suggested value. 560 It should be noted that the assigned value should be reflected in 561 IANAGmplsSwitchingTypeTC at 562 http://www.iana.org/assignments/ianagmplstc-mib. 564 6. Security Considerations 566 This document introduces new message object formats for use in GMPLS 567 signaling [RFC3473]. It does not introduce any new signaling 568 messages, nor change the relationship between LSRs that are adjacent 569 in the control plane. As such, this document introduces no additional 570 security considerations. See [RFC3473] for relevant security 571 considerations. 573 7. References 575 7.1. Normative References 577 [ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters," 578 draft-ietf-ccamp-ethernet-traffic-parameters, 579 Work in progress. 581 [GMPLS-EXT] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Data 582 Channel Switching Capable (DCSC) and Channel Set 583 Label Extensions", 584 draft-ietf-ccamp-gmpls-dcsc-channel-ext, Work in 585 Progres. 587 [GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol 588 Label Switching (GMPLS) Protocol Extensions for 589 Multi-Layer and Multi-Region Networks (MLN/MRN)", 590 draft-ietf-ccamp-gmpls-mln-extensions, 591 Work in progress. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels," RFC 2119. 596 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 597 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 598 to RSVP for LSP Tunnels", RFC 3209, December 2001. 600 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 601 Switching (GMPLS) Signaling Functional Description", 602 RFC 3471, January 2003. 604 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 605 Switching (GMPLS) Signaling - Resource ReserVation 606 Protocol-Traffic Engineering (RSVP-TE) Extensions", 607 RFC 3473, January 2003. 609 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 610 Control", RFC 4003, February 2005. 612 [RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS 613 (GMPLS) RSVP-TE Signaling Extensions in support of Calls", 614 RFC 4974, August 2007. 616 7.2. Informative References 618 [G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport 619 Ethernet services framework", August 2004. 621 [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private 622 line service", August 2004. 624 [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual 625 private line service", September 2005. 627 [GMPLS-MEF-UNI] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 628 Support For Metro Ethernet Forum and G.8011 629 User-Network Interface (UNI)", 630 draft-ietf-ccamp-gmpls-mef-uni, Work in Progress. 632 [MEF6] The Metro Ethernet Forum, "Ethernet Services 633 Definitions - Phase I", MEF 6, June 2004 635 [MEF10.1] The Metro Ethernet Forum, "Ethernet Services 636 Attributes Phase 2", MEF 10.1, November 2006. 638 [MEF11] The Metro Ethernet Forum , "User Network 639 Interface (UNI) Requirements and Framework", 640 MEF 11, November 2004. 642 [RFC4875] Aggarwal, R., Papadimitriou, P., Yasukawa, S., 643 Eds, "Extensions to Resource Reservation 644 Protocol - Traffic Engineering (RSVP-TE) for 645 Point-to-Multipoint TE Label Switched Paths 646 (LSPs)", RFC 4875, May 2007. 648 8. Acknowledgments 650 Dimitri Papadimitriou provided substantial textual contributions to 651 this document and coauthored earlier versions of this document. 653 The authors would like to thank Evelyne Roch, Stephen Shew, and Yoav 654 Cohen for their valuable comments. 656 9. Author's Addresses 658 Lou Berger 659 LabN Consulting, L.L.C. 660 Phone: +1-301-468-9228 661 Email: lberger@labn.net 663 Don Fedyk 664 Alcatel-Lucent 665 Groton, MA, 01450 666 Phone: +1-978-467-5645 667 Email: donald.fedyk@alcatel-lucent.com 669 Generated on: Wed Oct 14 14:47:45 EDT 2009