idnits 2.17.1 draft-ietf-ccamp-gmpls-mef-uni-03.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 5309 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 User-Network Interface (UNI) 10 draft-ietf-ccamp-gmpls-mef-uni-03.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 a Generalized Multi-Protocol Label 55 Switching (GMPLS) based User-Network Interface (UNI). This document 56 supports the types of switching required by the Ethernet services 57 that have been defined in the context of the Metro Ethernet Forum 58 (MEF) and International Telecommunication Union (ITU) G.8011. This 59 document is the UNI companion to "Generalized MPLS (GMPLS) Support 60 For Metro Ethernet Forum and G.8011 Ethernet Service Switching". 61 This document does not define or limit the underlying intra-domain or 62 Internal NNI (I-NNI) technology used to support the UNI. 64 Table of Contents 66 1 Introduction ........................................... 3 67 1.1 Overview ............................................... 4 68 1.2 Conventions Used In This Document ...................... 5 69 2 Common Signaling Support ............................... 5 70 2.1 UNI Addressing ......................................... 5 71 2.2 Ethernet Endpoint (UNI) Identification ................. 6 72 2.2.1 Address Resolution ..................................... 6 73 2.3 Connection Identification .............................. 7 74 3 EPL Service ............................................ 7 75 4 EVPL Service ........................................... 7 76 4.1 Egress VLAN ID Control and VLAN ID preservation ........ 7 77 5 IANA Considerations .................................... 8 78 5.1 Error Value: Routing Problem/Unknown Endpoint .......... 8 79 6 Security Considerations ................................ 8 80 7 References ............................................. 8 81 7.1 Normative References ................................... 8 82 7.2 Informative References ................................. 9 83 8 Acknowledgments ........................................ 10 84 9 Author's Addresses ..................................... 10 86 1. Introduction 88 [MEF6] and [G.8011] provide parallel frameworks for defining network- 89 oriented characteristics of Ethernet services in transport networks. 90 The framework discusses general Ethernet connection characteristics, 91 Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network 92 Interfaces (NNIs). Within this framework, [G.8011.1] defines the 93 Ethernet Private Line (EPL) service and [G.8011.2] defines the 94 Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both 95 service types. [MEF10.1] defines service parameters and [MEF11] 96 provides UNI requirements and framework. 98 This document provides a method for GMPLS based control of LSPs that 99 support the transport services defined in the above documents at the 100 UNI network reference points. This document does not define or limit 101 the underlying intra-domain or Internal NNI (I-NNI) technology used 102 to support the UNI. This document makes use of the GMPLS extensions 103 defined in [GMPLS-ESVCS] and [GMPLS-EXT]. 105 The scope of this document covers Ethernet UNI applications, and it 106 is intended to be consistent with the GMPLS overlay model presented 107 in [RFC4208] and aligned with GMPLS Core Network signaling. The 108 scope and reference model used in this document are represented in 109 Figure 1, which is based on Figure 1 of [RFC4208]. 111 Figure 1 shows two core networks, each containing two core-nodes. 112 The core-nodes are labeled 'CN'. Connected to each CN is an edge- 113 node. The edge-nodes are labeled 'EN'. Each EN supports Ethernet 114 Networks and use Ethernet services provided by the core-nodes via a 115 UNI. Two services are represented; one EPL and one EVPL type 116 service. Signaling within the core network is out of scope of this 117 document and may include any technology that supports overlay UNI 118 services. The UNI function in the edge-node can be referred to as 119 the UNI client, or UNI-C, and in the CN as UNI network, or UNI-N. 121 Ethernet Ethernet 122 Network +----------+ +-----------+ Network 123 +---------+ | | | | +---------+ 124 | +----+ | | +-----+ | | +-----+ | | +----+ | 125 ------+ | | EPL | | | | | | | | EPL | | +------ 126 ------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------ 127 | | | | +--+--| +---+ | | +--+-----+-+ | | 128 | +----+ | | | +--+--+ | | | +--+--+ | | +----+ | 129 | | | | | | | | | | | | 130 +---------+ | | | | | | | | +---------+ 131 | | | | | | | | 132 +---------+ | | | | | | | | +---------+ 133 | | | | +--+--+ | | | +--+--+ | | | 134 | +----+ | | | | | | +-----+ | | | +----+ | 135 ------+ +-+--+ | | CN +---------+ CN | | | | +------ 136 ------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------ 137 | | | |EVPL | +-----+ | | +-----+ |EVPL | | | | 138 | +----+ | | | | | | +----+ | 139 | | +----------+ |-----------+ | | 140 +---------+ Core Network(s) +---------+ 141 Ethernet UNI UNI Ethernet 142 Network <-----> <-----> Network 143 Scope of this Document 145 Legend: EN - Edge Node 146 CN - Core Node 148 Figure 1: Ethernet UNI Reference Model 150 1.1. Overview 152 This document uses a common approach to supporting the switching 153 implied by the Ethernet services defined in [MEF6], [G.8011.1] and 154 [G.8011.2]. The approach builds on standard GMPLS mechanisms to 155 deliver the required control capabilities. This document reuses the 156 GMPLS mechanisms specified in [GMPLS-ESVCS], [RFC4208], and 157 [RFC4974]. 159 Support for P2P and MP2MP service is required by [G.8011] and 160 [MEF11]. P2P service delivery support is based on the GMPLS support 161 for Ethernet Services covered in [GMPLS-ESVCS]. As with [GMPLS- 162 ESVCS], the definition of support for MP2MP service is left for 163 future study and is not addressed in this document. 165 [MEF11] defines multiple types of control for UNI Ethernet services. 166 In MEF UNI Type 1, services are configured manually. In MEF UNI Type 167 2, services may be configured manually or via a link management 168 interface. In MEF UNI Type 3, services may be established and 169 managed via a signaling interface. As with [GMPLS-ESVCS] this 170 document is aimed at supporting the MEF UNI Type 3 mode of operation 171 (and not MEF UNI Types 1 and 2). As mentioned above, this document 172 is limited to covering UNI specific topics. 174 Common procedures used to signal Ethernet connections are described 175 in Section 2 of this document. Procedures related to signaling 176 switching in support of EPL services are described in Section 3. 177 Procedures related to signaling switching in support of EVPL services 178 are described in Section 4. 180 1.2. Conventions Used In This Document 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 2. Common Signaling Support 188 This section describes the common mechanisms for supporting a UNI 189 reference point for LSPs that provide the Ethernet Services described 190 in [GMPLS-ESVCS]. 192 Except as specifically modified in this document, the procedures 193 related to the processing of RSVP objects is not modified by this 194 document. The relevant procedures in existing documents, notably 195 [GMPLS-ESVCS], [GMPLS-EXT], [RFC4208] and [RFC4974], MUST be followed 196 in all cases not explicitly described in this document. 198 2.1. UNI Addressing 200 LSPs providing Ethernet connections controlled via the mechanisms 201 defined in this document MUST use the addressing and other procedures 202 defined in [RFC4208]. Of note, this includes the use of the egress 203 edge-node's IP address in the end-point address field in the SESSION 204 object. 206 One issue that presents itself with the addressing approach taken in 207 [RFC4208] is that an ingress edge-node may not receive the egress 208 edge-node's IP address as part of the management, or other, request 209 that results in the initiation of a new Ethernet connection. This 210 case is covered as described in Section 7.2 of [RFC4974] and modified 211 below in Section 2.2.1. 213 2.2. Ethernet Endpoint (UNI) Identification 215 UNI identification, except as noted below, MUST follow Ethernet 216 endpoint (UNI) identification as defined in [GMPLS-ESVCS]. There is 217 one additional case that is covered in this document where the scope 218 of the Ethernet endpoint identifier is relevant beyond the typical 219 case of just ingress and egress nodes. 221 2.2.1. Address Resolution 223 At the UNI reference point, it is possible for the ingress edge-node 224 to not have the egress edge-node's IP address when initiating an LSP. 225 This presents an issue as the egress edge-node's IP address is 226 carried in the SESSION object. This case is handled leveraging the 227 approach described in Section 7.2 of [RFC4974] to address call ID 228 assignment by the first core-node. 230 When an edge-node (the UNI-C) initiates an LSP and it has the egress 231 Ethernet endpoint identifier, but does not have its IP address, the 232 edge-node MUST create a Notify message as described in [RFC4974]. 233 The Notify message MUST include the CALL_ATTRIBUTES object with the 234 Endpoint ID TLV defined [GMPLS-ESVCS]. The tunnel end point address 235 field of the SESSION object in the Notify message MUST be set to zero 236 (0). The message MUST be addressed and sent to an address associated 237 with the first core-node. 239 When a core-node, i.e., the node providing the network side of the 240 UNI (the UNI-N), receives a Notify message with the tunnel end point 241 address field of the SESSION object set to zero, it MUST locate the 242 Endpoint ID TLV in the CALL_ATTRIBUTES object. If the object or TLV 243 are not present, the node MUST discard the message. In this case, a 244 Message ID Acknowledgment MUST NOT be sent for the Notify message. 246 When the Endpoint ID TLV is located, the node MUST map the Endpoint 247 ID into an IP address associated with the egress edge-node. If the 248 node is unable to obtain an egress address, it MUST issue an error 249 response Notify messages according to Section 6.2.2. of [RFC4974]. 250 The Error code and value SHOULD be "Routing Problem/Unknown 251 Endpoint." (To be assigned by IANA). 253 When the node is able to obtain an egress address, the end-point 254 address field of the SESSION object MUST be set to the obtained 255 address, and the Notify message should be sent according to the 256 standard processing defined in [RFC4974]. The downstream nodes will 257 then process the Notify according to standard processing rules. 259 When the ingress receives the response Notify message, it SHOULD 260 identify the call based on the Endpoint ID TLV and, when not set to 261 zero on the corresponding setup Notify message, the short and long 262 Call IDs. The end-point address field of the SESSION object carried 263 in the response Notify message will include the egress' IP address. 264 This returned address MUST be used in all subsequent messages 265 associated with the Ethernet connection. 267 Note that the procedure described in this section MAY be used when 268 the Call IDs are generated by the initiating UNI or generated by the 269 first core-node. 271 2.3. Connection Identification 273 With one exception, UNI signaling for Ethernet connections MUST 274 follow the Connection Identification procedures defined in [GMPLS- 275 ESVCS]. The exception is that the procedures defined in Section 7.2 276 of [RFC4974] MAY be used to provide support for allocation of Call 277 IDs by the first core-node rather than by the initiating edge-node. 279 3. EPL Service 281 There are no additional UNI specific requirements for signaling LSPs 282 supporting Ethernet Private Line (EPL) services. The procedures 283 defined in [GMPLS-ESVCS], as modified above, MUST be followed when 284 signaling an LSPs supporting an EPL Service. 286 4. EVPL Service 288 There is one additional UNI specific requirements for signaling LSPs 289 supporting an EVPL type service. Except as modified above and by 290 this section, the procedures defined in [GMPLS-ESVCS] MUST be 291 followed when signaling an EVPL Service. 293 4.1. Egress VLAN ID Control and VLAN ID preservation 295 Per [MEF6], the mapping of the single VLAN ID used at the ingress UNI 296 to a different VLAN ID at the egress UNI is allowed for EVPL services 297 that do not support both bundling and VLAN ID preservation. Such a 298 mapping MUST be requested and signaled based on the explicit label 299 control mechanism defined in [RFC4208], and not the mechanisms 300 defined in [GMPLS-ESVCS]. 302 As is the case in [GMPLS-ESVCS], when the explicit label control 303 mechanism is not used VLAN IDs MUST be preserved, i.e., not modified, 304 across the LSP. 306 5. IANA Considerations 308 IANA is requested to administer assignment of new values for 309 namespaces defined in this document and summarized in this section. 311 5.1. Error Value: Routing Problem/Unknown Endpoint 313 Upon approval of this document, IANA will make the assignment in the 314 "Error Codes and Globally-Defined Error Value Sub-Codes" section of 315 the "RSVP PARAMETERS" registry located at 316 http://www.iana.org/assignments/rsvp-parameters: 318 Error Code Meaning 319 24 Routing Problem [RFC3209] 321 This Error Code has the following globally-defined Error 322 Value sub-codes: 324 28* = Unknown Endpoint [This document] 326 (*) Suggested value. 328 6. Security Considerations 330 This document makes use of the mechanisms defined in [GMPLS-ESVCS] 331 and [RFC4974]. It does not in itself change the security models 332 offered in each. (Note that the address resolution discussed in 333 Section 2.2 above, parallels the replacement of information that 334 takes occurs per Section 7.2 of [RFC4974].) See [GMPLS-ESVCS] and 335 [RFC4974] for the security considerations that are relevant to and 336 introduced by the base mechanisms used by this document. 338 7. References 340 7.1. Normative References 342 [GMPLS-ESVCS] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) 343 Support 344 For Metro Ethernet Forum and G.8011 Ethernet Service 345 Switching", Work in Progress, 346 draft-ietf-ccamp-gmpls-ether-svcs. 348 [GMPLS-EXT] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Data 349 Channel Switching Capable (DCSC) and Channel Set Label 350 Extensions", draft-ietf-ccamp-gmpls-dcsc-channel-ext, 351 Work 352 in Progress. 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels," RFC 2119. 357 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 358 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 359 to RSVP for LSP Tunnels", RFC 3209, December 2001. 361 [RFC4208] Swallow, G., et al. "Generalized Multiprotocol Label 362 Switching (GMPLS) User-Network Interface (UNI): Resource 363 ReserVation Protocol-Traffic Engineering 364 (RSVP-TE) Support for the Overlay Model", RFC 4208, 365 October 2005. 367 [RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS 368 (GMPLS) RSVP-TE Signaling Extensions in support of Calls", 369 RFC 4974, August 2007. 371 7.2. Informative References 373 [G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport 374 Ethernet services framework", August 2004. 376 [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private 377 line service", August 2004. 379 [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual 380 private line service", September 2005. 382 [MEF6] The Metro Ethernet Forum, "Ethernet Services 383 Definitions - Phase I", MEF 6, June 2004 385 [MEF10.1] The Metro Ethernet Forum, "Ethernet Services 386 Attributes Phase 2", MEF 10.1, November 2006. 388 [MEF11] The Metro Ethernet Forum , "User Network 389 Interface (UNI) Requirements and Framework", 390 MEF 11, November 2004. 392 8. Acknowledgments 394 Dimitri Papadimitriou provided substantial textual contributions to 395 this document and coauthored earlier versions of this document. 397 The authors would like to thank Evelyne Roch and Stephen Shew for 398 their valuable comments. 400 9. Author's Addresses 402 Lou Berger 403 LabN Consulting, L.L.C. 404 Phone: +1-301-468-9228 405 Email: lberger@labn.net 407 Don Fedyk 408 Alcatel-Lucent 409 Groton, MA, 01450 410 Phone: +1-978-467-5645 411 Email: donald.fedyk@alcatel-lucent.com 413 Generated on: Wed Oct 14 14:48:05 EDT 2009