idnits 2.17.1 draft-berger-ccamp-gmpls-mef-uni-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. 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 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 (February 25, 2008) is 5905 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) -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ESVCS' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Category: Standards Track 3 Expiration Date: August 25, 2008 Don Fedyk (Nortel) 5 February 25, 2008 7 Generalized MPLS (GMPLS) Support For Metro Ethernet Forum 8 and G.8011 User-Network Interface (UNI) 10 draft-berger-ccamp-gmpls-mef-uni-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on August 25, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes a method for controlling two specific types 44 of Ethernet switching via a Generalized Multi-Protocol Label 45 Switching (GMPLS) based User-Network Interface (UNI). This document 46 supports the types of switching required to implied by the Ethernet 47 services that have been defined in the context of the Metro Ethernet 48 Forum (MEF) and International Telecommunication Union (ITU) G.8011. 49 This document is the UNI companion to "Generalized MPLS (GMPLS) 50 Support For Metro Ethernet Forum and G.8011 Ethernet Service 51 Switching". This document does not define or limit the underlying 52 intra-domain or Internal NNI (I-NNI) technology used to support the 53 UNI. 55 Contents 57 1 Introduction .............................................. 3 58 1.1 Overview .................................................. 4 59 1.2 Conventions used in this document ......................... 5 60 2 Common Signaling Support .................................. 5 61 2.1 UNI Addressing ............................................ 5 62 2.2 Ethernet Endpoint (UNI) Identification .................... 6 63 2.2.1 Address Resolution ........................................ 6 64 2.3 Connection Identification ................................. 7 65 3 EPL Service ............................................... 7 66 4 EVPL Service .............................................. 7 67 4.1 Egress VLAN ID Control and VLAN ID preservation ........... 7 68 5 IANA Considerations ....................................... 8 69 5.1 Error Value: Routing Problem/Unknown Endpoint ............. 8 70 6 Security Considerations ................................... 8 71 7 References ................................................ 8 72 7.1 Normative References ...................................... 8 73 7.2 Informative References .................................... 9 74 8 Acknowledgments ........................................... 10 75 9 Author's Addresses ........................................ 10 76 10 Full Copyright Statement .................................. 10 77 11 Intellectual Property ..................................... 11 78 1. Introduction 80 [MEF6] and [G.8011] provide parallel frameworks for defining network- 81 oriented characteristics of Ethernet services in transport networks. 82 The framework discusses general Ethernet connection characteristics, 83 Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network 84 Interfaces (NNIs). Within this framework, [G.8011.1] defines the 85 Ethernet Private Line (EPL) service and [G.8011.2] defines the 86 Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both 87 service types. [MEF10.1] defines service parameters and [MEF11] 88 provides UNI requirements and framework. 90 This document provides a method for GMPLS based control of LSPs that 91 support the transport services defined in the above documents at the 92 UNI network reference points. This document does not define or limit 93 the underlying intra-domain or Internal NNI (I-NNI) technology used 94 to support the UNI. This document makes use of the GMPLS extensions 95 defined in [GMPLS-ESVCS]. 97 The scope of this document covers Ethernet UNI applications, and it 98 is intended to be consistent with the GMPLS overlay model presented 99 in [RFC4208] and aligned with GMPLS Core Network signaling. The 100 scope and reference model used in this document are represented in 101 Figure 1, which is based on Figure 1 of [RFC4208]. 103 Figure 1 shows two core networks, each containing two core-nodes. 104 The core-nodes are labeled 'CN'. Connected to each CN is an edge- 105 node. The edge-nodes are labeled 'EN'. Each EN supports Ethernet 106 Networks and use Ethernet services provided by the core-nodes via a 107 UNI. Two services are represented; one EPL and one EVPL type 108 service. Signaling within the core network is out of scope of this 109 document and may include any technology that supports overlay UNI 110 services. The UNI function in the edge-node can be referred to as 111 the UNI client, or UNI-C, and in the CN as UNI network, or UNI-N. 113 Ethernet Ethernet 114 Network UNI +----------+ +-----------+ UNI Network 115 +---------+ | | | | +---------+ 116 | +----+ | | +-----+ | | +-----+ | | +----+ | 117 ------+ | | EPL | | | | | | | | EPL | | +------ 118 ------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------ 119 | | | | +--+--| +---+ | | +--+-----+-+ | | 120 | +----+ | | | +--+--+ | | | +--+--+ | | +----+ | 121 | | | | | | | | | | | | 122 +---------+ | | | | | | | | +---------+ 123 | | | | | | | | 124 +---------+ | | | | | | | | +---------+ 125 | | | | +--+--+ | | | +--+--+ | | | 126 | +----+ | | | | | | +-----+ | | | +----+ | 127 ------+ +-+--+ | | CN +---------+ CN | | | | +------ 128 ------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------ 129 | | | |EVPL | +-----+ | | +-----+ |EVPL | | | | 130 | +----+ | | | | | | +----+ | 131 | | +----------+ |-----------+ | | 132 +---------+ Core Network(s) +---------+ 133 Ethernet Ethernet 134 Network <-----> <-----> Network 135 Scope of this Document 137 Legend: EN - Edge Node 138 CN - Core Node 140 Figure 1: Ethernet UNI Reference Model 142 1.1. Overview 144 This document uses a largely common approach to supporting the 145 switching implied by the Ethernet services defined in [MEF6], 146 [G.8011.1] and [G.8011.2]. The approach builds on standard GMPLS 147 mechanisms to deliver the required control capabilities. This 148 document reuses the GMPLS mechanisms specified in [GMPLS-ESVCS], 149 [RFC4208], and [RFC4974]. 151 Support for P2P and MP2MP service is required by [G.8011] and 152 [MEF11]. P2P service delivery support is based on the GMPLS support 153 for Ethernet Services covered in [GMPLS-ESVCS]. As with [GMPLS- 154 ESVCS], the definition of support for MP2MP service is left for 155 future study and is not addressed in this document. 157 [MEF11] defines multiple types of control for UNI Ethernet services. 158 In MEF UNI Type 1, services are configured manually. In MEF UNI Type 159 2, services may be configured manually or via a link management 160 interface. In MEF UNI Type 3, services may be established and 161 managed via a signaling interface. As with [GMPLS-ESVCS] this 162 document is aimed at supporting the MEF UNI Type 3 mode of operation 163 (and not MEF UNI Types 1 and 2). As mentioned above, this document 164 is limited to covering UNI specific topics. 166 Common procedures used to signal Ethernet connections are described 167 in Section 2 of this document. Procedures related to signaling 168 switching in support of EPL services are described in Section 3. 169 Procedures related to signaling switching in support of EVPL services 170 are described in Section 4. 172 1.2. Conventions used in this document 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 2. Common Signaling Support 180 This section describes the common mechanisms for supporting a UNI 181 reference point for LSPs that provide the Ethernet Services described 182 in [GMPLS-ESVCS]. 184 Except as specifically modified in this document, the procedures 185 related to the processing of RSVP objects is not modified by this 186 document. The relevant procedures in existing documents, notably 187 [GMPLS-ESVCS] and [RFC4208], MUST be followed in all cases not 188 explicitly described in this document. 190 2.1. UNI Addressing 192 LSPs providing Ethernet connections controlled via the mechanisms 193 defined in this document MUST use the addressing and other procedures 194 defined in [RFC4208]. Of note, this includes the use of the egress 195 edge-node's IP address in the end-point address field in the SESSION 196 object. 198 One issue that presents itself with the addressing approach taken in 199 [RFC4208] is that an ingress edge-node may not receive the egress 200 edge-node's IP address as part of the management, or other, request 201 that results in the initiation of a new Ethernet connection. This 202 case is covered as described in Section 7.2 of [RFC4974] and modified 203 below in Section 2.2.1. 205 2.2. Ethernet Endpoint (UNI) Identification 207 UNI identification, except as noted below, MUST follow Ethernet 208 endpoint (UNI) identification as defined in [GMPLS-ESVCS]. There is 209 one additional case that is covered in this document where the scope 210 of the Ethernet endpoint identifier is relevant beyond the typical 211 case of just ingress and egress nodes. 213 2.2.1. Address Resolution 215 At the UNI reference point, it is possible for the ingress edge-node 216 to not have the egress edge-node's IP address when initiating an LSP. 217 This presents an issue as the egress edge-node's IP address is 218 carried in the SESSION object. This case is handled leveraging the 219 approach described in Section 7.2 of [RFC4974] to address call ID 220 assignment by the first core-node. 222 When an edge-node (the UNI-C) initiates an LSP and it has the egress 223 Ethernet endpoint identifier, but does not have its IP address, the 224 edge-node MUST create a Notify message as described in [RFC4974]. 225 The Notify message MUST include the LSP_ATTRIBUTES object with the 226 Endpoint ID TLV defined [GMPLS-ESVCS]. The tunnel end point address 227 field of the SESSION object in the Notify message MUST be set to zero 228 (0). The message MUST be addressed and sent to an address associated 229 with the first core-node. 231 When a core-node, i.e., the node providing the network side of the 232 UNI (the UNI-N), receives a Notify message with the tunnel end point 233 address field of the SESSION object set to zero, it MUST locate the 234 Endpoint ID TLV in the LSP_ATTRIBUTES object. If the object or TLV 235 are not present, the node MUST discard the message. In this case, a 236 Message ID Acknowledgment MUST NOT be sent for the Notify message. 238 When the Endpoint ID TLV is located, the node MUST map the Endpoint 239 ID into an IP address associated with the egress edge-node. If the 240 node is unable to obtain an egress address, it MUST issue an error 241 response Notify messages according to Section 6.2.2. of [RFC4974]. 242 The Error code and value SHOULD be "Routing Problem/Unknown 243 Endpoint." (To be assigned by IANA). 245 When the node is able to obtain an egress address, the end-point 246 address field of the SESSION object MUST be set to the obtained 247 address, and the Notify message should be sent according to the 248 standard processing defined in [RFC4974]. The downstream nodes will 249 then process the Notify according to standard processing rules. 251 When the ingress receives the response Notify message, it SHOULD 252 identify the call based on the Endpoint ID TLV and, when not set to 253 zero on the corresponding setup Notify message, the short and long 254 Call IDs. The end-point address field of the SESSION object carried 255 in the response Notify message will include the egress' IP address. 256 This returned address MUST be used in all subsequent messages 257 associated with the Ethernet connection. 259 Note that the procedure described in this section MAY be used when 260 the Call IDs are generated by the initiating UNI or generated by the 261 first core-node. 263 2.3. Connection Identification 265 With one exception, UNI signaling for Ethernet connections MUST 266 follow the Connection Identification procedures defined in [GMPLS- 267 ESVCS]. The exception is that the procedures defined in Section 7.2 268 of [RFC4974] MAY be used to provide support for allocation of Call 269 IDs by the first core-node rather than by the initiating edge-node. 271 3. EPL Service 273 There are no additional UNI specific requirements for signaling LSPs 274 supporting Ethernet Private Line (EPL) services. The procedures 275 defined in [GMPLS-ESVCS], as modified above, MUST be followed when 276 signaling an LSPs supporting an EPL Service. 278 4. EVPL Service 280 There is one additional UNI specific requirements for signaling LSPs 281 supporting an EVPL type service. Except as modified above and by 282 this section, the procedures defined in [GMPLS-ESVCS] MUST be 283 followed when signaling an EVPL Service. 285 4.1. Egress VLAN ID Control and VLAN ID preservation 287 Per [MEF6], the mapping of the single VLAN ID used at the ingress UNI 288 to a different VLAN ID at the egress UNI is allowed for EVPL services 289 that do not support both bundling and VLAN ID preservation. Such a 290 mapping MUST be requested and signaled based on the explicit label 291 control mechanism defined in [RFC4208], and not the mechanism define 292 in [GMPLS-ESVCS]. 294 As is the case in [GMPLS-ESVCS], when the explicit label control 295 mechanism is not used VLAN IDs MUST be preserved, i.e., not modified, 296 across the LSP. 298 5. IANA Considerations 300 IANA is requested to administer assignment of new values for 301 namespaces defined in this document and reviewed in this section. 303 5.1. Error Value: Routing Problem/Unknown Endpoint 305 Upon approval of this document, the IANA will make the assignment in 306 the "Error Codes and Globally-Defined Error Value Sub-Codes" section 307 of the "RSVP PARAMETERS" registry located at 308 http://www.iana.org/assignments/rsvp-parameters: 310 Error Code Meaning 311 24 Routing Problem [RFC3209] 313 This Error Code has the following globally-defined Error 314 Value sub-codes: 316 28* = Unknown Endpoint [This document] 318 (*) Suggested value. 320 6. Security Considerations 322 This document introduces new message object formats for use in GMPLS 323 signaling [RFC3473]. It does not introduce any new signaling 324 messages, nor change the relationship between LSRs that are adjacent 325 in the control plane. As such, this document introduces no additional 326 security considerations. See [RFC3473] for relevant security 327 considerations. 329 7. References 331 7.1. Normative References 333 [GMPLS-ESVCS] Berger, L., Papadimitriou, P., Fedyk, D., 334 "Generalized MPLS (GMPLS) Support For Metro Ethernet 335 Forum and G.8011 Ethernet Service Switching", Work in 336 Progress, draft-berger-ccamp-gmpls-ether-svcs-01.txt, 337 February 2008. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels," RFC 2119. 342 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 343 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 344 to RSVP for LSP Tunnels", RFC 3209, December 2001. 346 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 347 Switching (GMPLS) Signaling - Resource ReserVation 348 Protocol-Traffic Engineering (RSVP-TE) Extensions", 349 RFC 3473, January 2003. 351 [RFC4208] Swallow, G., et al. "Generalized Multiprotocol Label 352 Switching (GMPLS) User-Network Interface (UNI): Resource 353 ReserVation Protocol-Traffic Engineering 354 (RSVP-TE) Support for the Overlay Model", RFC 4208, 355 October 2005. 357 [RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS 358 (GMPLS) RSVP-TE Signaling Extensions in support of Calls", 359 RFC 4974, August 2007. 361 7.2. Informative References 363 [G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport 364 Ethernet services framework", August 2004. 366 [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private 367 line service", August 2004. 369 [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual 370 private line service", September 2005. 372 [MEF6] The Metro Ethernet Forum, "Ethernet Services 373 Definitions - Phase I", MEF 6, June 2004 375 [MEF10.1] The Metro Ethernet Forum, "Ethernet Services 376 Attributes Phase 2", MEF 10.1, November 2006. 378 [MEF11] The Metro Ethernet Forum , "User Network 379 Interface (UNI) Requirements and Framework", 380 MEF 11, November 2004. 382 8. Acknowledgments 384 The authors would like to thank Evelyne Roch and Stephen Shew for 385 their valuable comments. 387 9. Author's Addresses 389 Lou Berger 390 LabN Consulting, L.L.C. 391 Phone: +1-301-468-9228 392 Email: lberger@labn.net 394 Dimitri Papadimitriou 395 Alcatel Lucent 396 Francis Wellesplein 1, 397 B-2018 Antwerpen, Belgium 398 Phone: +32 3 240-8491 399 Email: Dimitri.Papadimitriou@alcatel-lucent.be 401 Don Fedyk 402 Nortel Networks 403 600 Technology Park Drive 404 Billerica, MA, 01821 405 Phone: +1-978-288-3041 406 Email: dwfedyk@nortel.com 408 10. Full Copyright Statement 410 Copyright (C) The IETF Trust (2008). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 420 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 421 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 11. Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed 428 to pertain to the implementation or use of the technology 429 described in this document or the extent to which any license 430 under such rights might or might not be available; nor does it 431 represent that it has made any independent effort to identify any 432 such rights. Information on the procedures with respect to rights 433 in RFC documents can be found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use 438 of such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository 440 at http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention 443 any copyrights, patents or patent applications, or other 444 proprietary rights that may cover technology that may be required 445 to implement this standard. Please address the information to the 446 IETF at ietf-ipr@ietf.org. 448 Acknowledgement 450 Funding for the RFC Editor function is provided by the IETF 451 Administrative Support Activity (IASA). 453 Generated on: Mon Feb 25 11:44:43 EST 2008