idnits 2.17.1 draft-dimitri-gels-framework-00.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(186): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 910. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2006) is 6638 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) -- Looks like a reference, but probably isn't: '1' on line 57 == Missing Reference: 'P2MP' is mentioned on line 256, but not defined == Missing Reference: 'ID-FRM' is mentioned on line 258, but not defined == Missing Reference: 'RSVP-ID' is mentioned on line 702, but not defined == Unused Reference: 'RFC2119' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'MRN-REQ' is defined on line 801, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) -- No information found for draft-ietf-ccamp-gmpls-mrn-reqs - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Papadimitriou (Alcatel) 3 Internet Draft N. Sprecher (Siemens) 4 J. Cho (ETRI) 5 Expires: July 2006 L. Andersson (Acreo AB) 6 D. Fedyk, D.Allan (Nortel) 7 P. Busschbach (Lucent) 8 A. Tak�cs (Ericsson) 9 T. Eriksson (TeliaSonera) 10 D. Caviglia (Marconi) 12 February 2006 14 A Framework for GMPLS-controlled Ethernet Label Switching 16 draft-dimitri-gels-framework-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 For potential updates to the above required-text see: 41 http://www.ietf.org/ietf/1id-guidelines.txt 43 Abstract 45 This framework introduces the service models that should be 46 supported. It describes the architecture and the information exchange 47 between the different elements that sustain the reference models. It 48 defines the Ethernet label. The framework also specifies the changes/ 49 extensions that are required to the GMPLS in order to support the 50 service models. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [1]. 58 1. Terminology 60 L2SC Label Switch Router (LSR): LSR whose interfaces are capable to 61 recognize Layer 2 frame boundaries and can switch data based on the 62 content of the Layer 2 frame header. In the context of this document, 63 L2SC interfaces are limited to Ethernet interfaces. 65 Ethernet Label Edge Router (E-LER): LER that resides either at the 66 edge of the provider's GMPLS network (a.k.a. Provider Edge or PE) or 67 at the edge to customer's network (a.k.a. Customer Edge or CE). In 68 the former case, the Ethernet LER interfaces the customer�s network 69 equipment. The E-LER has the functionality required for initiating 70 and terminating point-to-point and point-to-multipoint Ethernet 71 connectivity across the GMPLS network. 73 Ethernet Label Switching Router (E-LSR): LSR that either resides at 74 the core of the provider's GMPLS network (a.k.a. Provider node or P) 75 or at the edge to provider's GMPLS network (a.k.a. Provider Edge or 76 PE). In the former case, the Ethernet LSRs have no direct interfaces 77 towards the customers' networks. The Ethernet LSR performs Ethernet 78 label switching operation by means of a LIB configured by GMPLS. 80 Ethernet Label Switched Path (LSP): Label Switched Path established 81 between two Ethernet LERs using GMPLS signaling. 83 Label Information Base (LIB): table that specifies associations 84 between incoming and outgoing Ethernet Labels included in Layer 2 85 frame headers and outgoing ports. If different to the incoming label 86 it also specifies the outgoing label. 88 2. Motivations 90 2.1 Motivation for connection-oriented Ethernet 92 Ethernet has become widely used within the Service Provider networks, 93 in particular as part of their metro/aggregation infrastructure. The 94 Ethernet brings high-speed interfaces, cost-saving efficiency and 95 flexibility to the carrier market, together with a reduction in CAPEX 96 (Capital Expenditure). 98 While the traditional Ethernet, which is a connectionless, broadcast 99 technology that relies on Spanning Tree Protocols (and variations 100 such as Rapid Spanning Tree Protocol, RSTP) to create loop free 101 topologies, is appropriate for services like Residential Multicast 102 (Broadband TV), and Ethernet Transparent LAN services, it does not 103 properly address the increasing demand of the service providers for 104 scalability, fast recovery time, Traffic Engineering and end-to-end 105 QoS for the different service requirements. These are required for 106 business-critical services associated with stringent Service Level 107 Agreements (SLAs). The deployment of Ethernet in the core and in the 108 transport networks changes the intrinsic nature of Ethernet 109 technology, from a connectionless to a connection-oriented 110 technology. 112 For example, with traditional/legacy IEEE 802.1 bridged Ethernet 113 equipment, service providers can implement traffic differentiation on 114 a per-switch basis. However, due to the Spanning Tree topology and 115 reconfiguration upon failures, it is difficult to predict the exact 116 traffic flows and to manage QoS on an end-to-end basis. Service 117 providers require advanced traffic management capabilities to enforce 118 and guarantee the QoS parameters of customers� SLAs. Service 119 providers can increase profitability with an assortment of higher 120 margin differentiated services. With "connection-oriented" Ethernet 121 (CO-Ethernet), it is possible to set up paths based on the service 122 definition, and to enforce the SLAs. Apart from its cost-saving 123 effects and flexibility, service providers will allow network 124 providers to offer new services that can be tailored to the 125 individual needs of the customer. 127 By eliminating the need for Spanning Tree Protocol and gaining route 128 freedom for configured Ethernet paths, service providers can use more 129 comprehensive forms of traffic engineering to optimize network usage 130 through load sharing and switching paths around bottlenecks to less 131 congested links. 133 Network resiliency plays a critical factor in delivering reliable 134 services. Network availability is a significant contributor to 135 revenue and profit. Service guarantee in the form of SLAs requires a 136 resilient network that instantaneously detects facility or node 137 failures and restores network operation immediately to meet the terms 138 of the SLA. Network restoration through the use of IEEE 139 Rapid/Spanning Tree Protocol 802.1d/w � being a Distance Vector 140 protocol � has inherent limitations that make fast restoration time 141 performance objectives difficult to accomplish. Connection-oriented 142 Ethernet can provide the required availability to ensure guaranteed 143 services. Through mechanisms like OAM, dedicated backup routes and/or 144 fast reroute mechanisms, the transport Ethernet network can provide 145 the tens of milliseconds fail over times needed to meet stringent SLA 146 obligations. Connection-oriented Ethernet also addresses the 147 carriers' needs for MAC scalability and VLAN scalability. It 148 eliminates the MAC scalability problem in case switching operation is 149 independent of the destination MAC address. 151 In addition, service providers require network architectures that 152 enable services to scale effectively as the customer base grows, in 153 order to minimize capital expenditures and drive down operational 154 costs. 156 Scalable services require the separation of traffic from different 157 users, with no limitations on the number or locations of customers 158 connected to the network. With connection-oriented Ethernet the cost 159 effectiveness is achieved. 161 Due to its connectionless nature, especially its use of self-learning 162 bridges, traditional Ethernet is vulnerable to unwanted connectivity 163 (either through mis-configuration or malicious attacks). In the case 164 of connection-oriented Ethernet switches are explicitly provisioned 165 and therefore provide enhanced security. 167 2.2 Motivation to improve Ethernet Control Plane 169 In order to enable fast, dynamic and reliable service provisioning in 170 multi-vendor and multi-domain environments through standardized 171 protocols that guarantee interoperability, a control plane is 172 required. Managed by a standard-based distributed control plane and 173 augmented with Ethernet specific data plane OAM features currently 174 being specified by the IEEE (see 802.1ag), the dynamic transport 175 network will support Ethernet traffic with carrier-grade reliability, 176 optimal network efficiency, multiple QoS levels, cross-vendor 177 provisioning and scalability. The control plane will facilitate the 178 service goal of providing seamless connectivity and service assurance 179 end-to-end. 181 Using the control plane the reliable service provisioning and 182 management will be automatic. The control-plane protocols will make 183 the provisioning and the management operations more efficient, 184 thereby offering the potential of lowering network operation 185 expenses, or at least limiting their rate of increase as the size of 186 the service provider�s network increases. As the networks change, and 187 get larger and more complex with increased dynamics, the network 188 operation becomes increasingly complex and resource intensive to 189 operate. 191 The control plane can also optimize network usage through load 192 sharing by switching paths around bottlenecks to less congested 193 links. Using a control plane that provides Traffic Engineering, 194 constraint based routing and explicit path control will minimize 195 capital expense by making efficient use of network resources, hence 196 helping to avoid unnecessary additional investments. These are 197 requirements of the core/transport networks. 199 The use of a control plane that has the inherent ability to setup 200 paths based on the service definition, with capabilities for quality- 201 of-service (QoS) and Traffic Engineering will enforce the SLAs. 202 Traffic Engineering is accomplished by addressing traffic oriented 203 performance requirements (like throughput, delay, packet loss, etc.), 204 while utilizing network resources economically and reliably. 205 The control plane can enable resiliency and reliability to be built 206 into service providers� networks, increasing the availability and 207 value of the network to their customers. When outages occur, traffic 208 can be automatically rerouted around failed facilities. 210 This framework proposes to use the Generalized Multi-Protocol Label 211 Switching (GMPLS) as the control plane of choice for the Ethernet 212 networks. The GMPLS protocol suite [RFC3945] has been standardized by 213 the IETF CCAMP WG. GMPLS extends MPLS to support four new classes of 214 interfaces including L2SC (L2 Switch Capable) interfaces. It 215 facilitates the transport of client Ethernet flows without additional 216 intermediate packet layer LSPs (which require pre-provisioning as 217 network trunks). 219 The GMPLS control plane provides Traffic Engineering (including 220 support for Differentiated service-TE), provisioning and maintenance 221 of (unidirectional and bi-directional) Ethernet LSPs in core and 222 transport networks including multi-layer networks (MLNs). 224 GMPLS has inherent support for fast recovery mechanisms. It delivers 225 a range of control plane driven recovery capabilities. GMPLS 226 protection and re-routing techniques (both end-to-end and segment) 227 and can be reused for GMPLS Ethernet LSPs and LSP segments. 229 GMPLS capabilities support the carriers' requirements for control 230 plane resiliency, like graceful restart of the control plane (with no 231 traffic interruption) and graceful deletion of Ethernet LSPs. 233 Having a homogenous/unified set of signaling and Traffic Engineering 234 mechanisms for controlling Ethernet network resources, will ease the 235 integration towards a common carrier-grade network control 236 infrastructure. The CCAMP WG is currently envisaging a single 237 instance of control plane between IP/MPLS, Ethernet, SDH/SONET and 238 optical networks. Henceforth, GMPLS controlled Ethernet label 239 switching approach positions Ethernet as a carrier-grade packet- 240 switching connection-oriented technology. 242 4. Architecture 244 This section presents the architectural framework for GMPLS- 245 controlled Ethernet Label Switching. It defines the reference model 246 for the GMPLS-enabled Ethernet network, the various protocol elements 247 and their functions. 249 Generalized Multi-Protocol Label Switching (GMPLS) is a suite of 250 protocol extensions to MPLS. The purpose of these extensions is to 251 broaden the scope of MPLS applications, and to support multiple 252 network layers and new services. Specifically, this specification 253 describes how GMPLS can be used to dynamically setup, delete, 254 maintain and operate Point-to-Point Traffic Engineered Ethernet LSPs. 255 The specification must be extensible such as to support Point-to- 256 Multipoint Traffic Engineered Ethernet LSPs [P2MP] and to include the 257 extension of the Traffic Engineered Ethernet LSPs over multiple 258 domains [ID-FRM]. 260 4.1 GMPLS-controlled Ethernet Network Elements 262 The GMPLS-controlled Ethernet network consists of the following 263 network elements: 265 o) Ethernet Label Edge Router (E-LER) 267 The Ethernet LER either resides at the edge of the provider's GMPLS 268 network (PE role) or at the edge to customer's network (CE role). In 269 the former case, the Ethernet LER interfaces the customer's network 270 equipment. 272 The E-LER has the functionality required for initiating and 273 terminating point-to-point and point-to-multipoint Ethernet 274 connectivity across the GMPLS network. 276 At the ingress to the GMPLS network, the Ethernet LER takes an 277 incoming native frame from a non-label controlled interface, if 278 necessary adapts it to an Ethernet frame, adds an Ethernet label and 279 forwards it via the appropriate label-controlled interface over a 280 Ethernet point-to-point or point-to-multipoint LSP. 282 At the egress to the GMPLS network, the Ethernet LER removes the 283 Ethernet label from a frame received on a label-controlled interface, 284 if necessary extracts the payload, and forwards the native frame 285 appropriately towards its destination via a non-labeled-controlled 286 interface. 288 o) Ethernet Label Switching Router (E-LSR) 290 The Ethernet LSR either resides at the core of the provider's GMPLS 291 network (P role) or at the edge to provider's GMPLS network (PE 292 role). In the former case, the Ethernet LSRs have no direct 293 interfaces towards the customers' networks. The Ethernet LSR takes an 294 incoming labeled Ethernet frame from a labeled-controlled interface, 295 switch the frame using the Ethernet label and forwards the frame 296 towards its destination via the appropriate label-controlled 297 interface. 299 Each GMPLS-enabled network element may function as an Ethernet LER 300 and/or as an Ethernet LSR. This means that the path from the Ethernet 301 ingress LER to the Ethernet LER might pass through another Ethernet 302 LER. 304 4.2 Ethernet LSP 306 An Ethernet point-to-point LSP is defined as an LSP established 307 between two Ethernet label-controlled interfaces of E-LERs. These 308 interfaces are capable of recognizing the Ethernet frame boundaries 309 and can switch data based on the content of the standard IEEE 802.1 310 Ethernet frame. The Ethernet LSP originates on an ingress Ethernet 311 LER and terminates on an egress Ethernet LER. For a point-to-point 312 bi-directional LSP, the same pair of E-LERs acts as both ingress and 313 egress E-LERs. 315 An Ethernet point-to-multipoint LSP is defined as a unidirectional 316 LSP terminating on more than one Ethernet label-controlled interfaces 317 of E-LERs. 319 At the E-LER, the frame is assigned to an LSP tunnel, and no further 320 header analysis is required by subsequent Ethernet LSRs. Throughout 321 the GMPLS-enabled Ethernet network, the forwarding operation is 322 driven by the labels which are encoded in the standard IEEE 802.1 323 frame header (either 802.1ad or 802.1ah). 325 4.3 Reference Architectures 327 o) Edge-to-edge Reference model 329 Figure 1depicts the "edge-to-edge" network reference model for a 330 point-to-point Ethernet LSP across a GMPLS-enabled Ethernet network. 331 In this model, the CE (Customer Edge) network element is attached to 332 a PE (Provider Edge) network element via a CE-PE interface. The PE 333 network element functions as an E-LER. The Ethernet LSP is 334 established between a pair of directly connected E-LERs across the 335 GMPLS-enabled Ethernet network, or via a set of P (Provider) network 336 elements which function as Ethernet LSR (E-LSR) nodes. 338 ----GMPLS Ethernet Network---- 339 | | 340 PE P PE 341 +------+ +------+-------+ +-------+ +------+-----+ +------+ 342 | | | | | | | | | | | | 343 | CE |---| Pre |Ingress|---| E-LSR |---|Egress| Post|---| CE | 344 | | | Proc.| E-LER | | | |E-LER | Proc| | | 345 | | | | | | | | | | | | 346 +------+ +------+-------+ +-------+ +------+-----+ +------+ 348 Figure 1: Edge-to-edge Reference Model 350 A point-to-point/point-to-multipoint Ethernet LSP is established to 351 provide point-to-point/point-to-multipoint data path between E-LERs. 352 When a frame/packet enters an ingress PE via a CE-PE interface, the 353 PE processes the incoming traffic flow by performing a number of pre- 354 processing operations on the frame. Detailed description of the pre- 355 processing operations that may include, for example, VID translation, 356 VID insertion/ stripping, etc. are beyond the scope of this 357 specification. Note that the CE-PE interface is not restricted to any 358 kind of specific interface (hence, not restricted to interfaces 359 carrying Ethernet frames) and this, in order to enable to Ethernet to 360 be a transport layer for multiple services. 362 The pre-processed frame is then presented to the ingress E-LER 363 function that 1) maps the corresponding incoming frame to a 364 particular Ethernet LSP according to different criteria such as the 365 destination, the class of service, etc. and 2) adds an Ethernet label 366 to the frame and forwards it via the appropriate label-controlled 367 interface along the Ethernet LSP. 369 The egress E-LER terminates the Ethernet LSP by removing the Ethernet 370 label on incoming frames. The PE then performs post-processing 371 operations on the incoming frame and forwards it on the appropriate 372 CE-PE interface. Detailed description of these post-processing 373 operations that may include, for example, VID translation, VID 374 insertion/ stripping, etc. are beyond the scope of this 375 specification. 377 o) "End-to-end" Reference Model 379 Figure 2 depicts the "end-to-end" network reference model for a 380 point-to-point Ethernet LSP across a GMPLS-enabled Ethernet network. 381 In this model, the CE (Customer Edge) network element is attached to 382 a PE (Provider Edge) network element via a CE-PE interface. The CE 383 network element functions as an E-LER. The Ethernet LSP is 384 established between a pair of directly connected E-LERs across the 385 GMPLS-enabled Ethernet network, or via a set of P (Provider) network 386 elements which function as Ethernet LSR (E-LSR) nodes. 388 ---------------GMPLS Ethernet Network---------------- 389 | | 390 CE PE P PE CE 391 +------+-------+ +-------+ +-------+ +-------+ +------+-----+ 392 | | | | | | | | | | | | 393 | Pre |Ingress|---| E-LSR |---| E-LSR |---| E-LSR |---|Egress| Post| 394 | Proc.| E-LER | | | | | | | |E-LER | Proc| 395 | | | | | | | | | | | | 396 +------+-------+ +-------+ +-------+ +-------+ +------+-----+ 398 Figure 2: End-to-end Reference Model 400 Operations driving pre-processing/ingress E-LER function (at ingress 401 CE-side), E-LSR function (at PE and P-side) and Egress E-LER/post- 402 processing function (at egress CE-side) are identical of those of the 403 edge-to-edge model. 405 The GMPLS-enabled Ethernet network may be part of a Multi-Layer 406 Network (MLN) where multiple switching technologies are supported, 407 i.e. multiple regions are supported [MLN_REQ]. Figure 3 presents an 408 example of a multi-regional scheme and indicates the relationships 409 between the control and data plane entities in a GMPLS-enabled 410 network, where the three data planes are controlled by the same GMPLS 411 control plane instance. In this figure, node A corresponds to the CE 412 and node B to the PE (as depicted in Figure 2). 414 +-----------+ +-------------+ +-------------+ 415 | A | | B | | C | 416 | +-------+ | | +---------+ | | +---------+ | 417 | | PSC | |OSPF-TE| | L2SC | |OSPF-TE| | LSC | | 418 | | LSR |<--------->| LSR |<--------->| LSR | | 419 control| | | |RSVP-TE| |Ethernet | |RSVP-TE| | CP | | 420 plane 421 | +-------+ | | +---------+ | | +---------+ | 422 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 423 | +-------+ | | | | | 424 | | PSC | | | | | | 425 | | LSR |----+ | | | | 426 IP/MPLS| | | | | | | | | 427 | | | | | | | | | 428 | +-------+ | | | | | | 429 +-----------+ | | | | | 430 .................................................................... 431 | | +---------+ | | | 432 | | | L2SC | | | | 433 +------| LSR |----+ | | 434 Ethernet | | | | | | | 435 | |Ethernet | | | | | 436 | +---------+ | | | | 437 +-------------+ | | | 438 .................................................................... 439 | | +---------+ | 440 | | | LSC | | 441 +------| LSR | | 443 lambda | | | | 444 | | lambda | | 445 | +---------+ | 446 +-------------+ 448 Figure 3: Data plane and control plane 450 The aggregation of traffic into the same LSP is possible in this 451 multi-regional scheme. LSP nesting may be supported as well, for 452 example, packet LSPs may be nested into an Ethernet LSP and Ethernet 453 LSPs may be nested into lambda LSPs. 455 4.4 GMPLS Control Plane Elements 457 The E-LER and the E-LSR network elements implement the GMPLS control 458 protocol to enable constraint-based routing and explicit routing, and 459 to automatically configure the Forwarding Information Base (FIB) with 460 the forwarding state. 462 IPv4 and/or IPv6 addressing are used to identify the Ethernet L2SC 463 interfaces. Unnumbered links and bundled links should be used to 464 enhance the addressing scalability and to eliminate the need to apply 465 an IP address to each Ethernet L2SC interface. 467 The OSPF-TE/IS-IS TE routing protocols can be used to distribute the 468 network element capabilities and to disseminate TE routing 469 information over the interfaces. The bandwidth, as well as the other 470 TE attributes, of each port/bundled link, or the bandwidth of each 471 Ethernet LSP, can be treated as a constraint during path computation. 473 The GMPLS RSVP-TE is used to support Ethernet point-to-point LSP 474 setup, maintenance and tear down. In order to be compatible with the 475 global GMPLS framework and provide a global unified TE framework, 476 multiple switching layers may be supported and ownership/trust models 477 (e.g. overlay, peer) may be applied. For details, see below the 478 Multi-Layer Network (MLN) model. 480 4.5 Ethernet Label 482 GMPLS makes use of the structure of the standard IEEE 802.1 Ethernet 483 frame. The Ethernet label is inserted in the Ethernet encapsulation 484 and is part of the Ethernet MAC frame header. A GMPLS Ethernet- 485 labeled frame is defined as an Ethernet MAC frame whose header 486 encodes the label value. The coding of the Ethernet label does not 487 modify the format of the standard Ethernet frame, although it may add 488 new semantics to one or more fields. The switching decision is based 489 on the label part of the Ethernet frame header. Figure 4 depicts a 490 logical view of the protocol layers. 492 +---------------------------+ 493 | Payload | 494 +---------------------------+ 495 | Ethernet | 496 +---------------------------+ 497 | Physical | 498 +---------------------------+ 500 Figure 4: Logical Protocol Layering Model 502 The Ethernet MAC frame header includes the EtherType, different VLAN 503 TAGs, and the destination and source MAC addresses. 505 GMPLS Ethernet switches need to be able to correctly handle all types 506 of Ethernet MAC frames, including GMPLS-labeled frames, to ensure co- 507 existence with legacy Ethernet switches. GMPLS functionality can co- 508 exist with IEEE 802.1 bridge control and management functionalities 509 on the same network element. The common network resources should be 510 either pre-partitioning or dynamically selected. 512 The architecture allows different label encoding techniques. A 513 specific encoding technique may be selected according to the 514 capability of the GMPLS-enabled Ethernet network element and/or to 515 the capability of the label-controlled Ethernet interface, etc. 517 Labels are locally assigned, interpreted and have local significance. 518 This does not preclude that the same label value can be assigned by 519 consecutive hops. Also Ethernet label and label switching technique 520 must be extensible for the establishment and support of multiple- 521 domain Ethernet LSP, point-to-multipoint LSPs (carrying Ethernet 522 multicast traffic) and easily support exchange of Ethernet broadcast 523 traffic. 525 The techniques are considered as candidate for the encoding of the 526 Ethernet label. 528 o) Link-local label: IEEE 802.1ad S-VID (amendment to IEEE Std 529 802.1Q-1998) 531 Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet 532 frame. 534 TAG 535 --------- 536 / \ 537 +-----------+------------+----+----+----+---------------+--------+ 538 | | | | | | | | 539 | MAC Dest | MAC Src |TPID|TCI |LEN\| Payload | FCS | 540 | Address | Address | | |Type| | | 541 | | | | | | | | 542 +-----------+------------+----+----+----+---------------+--------+ 544 Figure 5: Standard IEEE 802.1Q Frame Format 546 The TAG protocol Identifier (TPID) is a 16-bit length field which is 547 set a value of 0x88a8 to identify the frame as an IEEE 802.1ad tagged 548 frame. The TAG Control Information (TCI) is a 16-bit length field. 550 In this technique, the Ethernet label is encoded in the TCI field of 551 the S-VLAN TCI (see Figure 6). The length of the Ethernet label is 12 552 bits providing for a label space of 4k values per link. 554 S-VID translation is used in this technique. S-VID processing is 555 supported on most Ethernet switches. MAC address learning may be 556 inhibited, depending on the behavior of the forwarding entity. 558 GMPLS signaling is used to configure the S-VIDs along the nodes 559 traversed by the Ethernet LSP. 561 Figure 6 depicts the S-VLAN TAG Control Information (TCI) 563 Oct: 1 2 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | PCP |D| VID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 569 Figure 6: TCI Format 571 The Priority Code Point (PCP) is a 3-bit length field, which is used 572 to convey priority and drop eligibility parameters. This 3-bit field 573 refers to the 802.1p priority. 575 The D bit (1 bits) is the Drop Eligible Indicator (DEI) bit. 577 The VLAN Identifier (VID) is a 12-bit length field uniquely 578 identifying the VLAN to which the frame belongs. Its value can be 579 between 0 and 4,095. 581 o) Link-local label: IEEE 802.1ad Stacked VLAN (QinQ) 583 Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with 584 Stacked VLAN (QinQ). 586 S-TAG C-TAG 587 -------- ------- 588 / \ / \ 590 +----------+----------+----+----+----+----+----+---------------+---+ 591 | | | | | | | | | | 592 | MAC Dest | MAC Src |TPID|TCI |TPID|TCI |LEN\| Payload |FCS| 593 | Address | Address | | | | |Type| | | 594 | | | | | | | | | | 595 +----------+----------+----+----+----+----+----+---------------+---+ 597 Figure 7: Standard IEEE 802.1ad Format with Stacked VLAN. 599 In this technique the concatenation of the S-VID (i.e. the VID of the 600 S-TAG) and the C-VID (i.e. the VID of the C-TAG) is used as the 601 Ethernet label, resulting in a unique 24-bit length label. 603 This technique makes use of VID translation. Neither MAC learning nor 604 flooding for the range of VIDs are required. GMPLS is used to 605 configure the 24-bit label. 607 o) Domain-wide label: IEEE 802.1ah B-VID concatenated with B-MAC DA 609 In this technique, the concatenation of the VID (encoded in the TCI 610 immediately following the DA and SA MACs) and the Destination MAC 611 Address (DA MAC) is used as the Ethernet label, resulting in a unique 612 60-bit label. The VID can be a Q-TAG (Ethertype for TCI=0x8100), a 613 802.1ad S-TAG (Ethertype for TCI=0x8a88) or a 802.1ah B-TAG 614 (Ethertype TBD) depending on the network context. This technique 615 provides for a private sub-network labeling solution as the MAC 616 address space is "sub-network specific". This solution mandates 617 enforcement of unicast only traffic exchange for the specified (pre- 618 configured) VID range. 620 In order to use the unique 60-bit label, the normal mechanisms by 621 which Ethernet populates the forwarding table for the allocated range 622 of VIDs should be disabled, for example, MAC learning and flooding 623 are disabled for an allocated VID range, blocking is disabled, etc. 624 GMPLS is used to configure the 60-bit label. 626 Note that having a label encoding technique which uses a network wide 627 label space definition requires that the support of the whole network 628 in this technique, even in case of multiple domains. 630 5. Control Plane Operations 632 The IP control channel between GMPLS L2SC nodes can be out-of-band or 633 in-band. The exchange of signaling and routing information between 634 adjacent GMPLS nodes and processing MUST be strictly independent of 635 the control channel implementation. 637 5.1. TE/Routing information distribution 638 To facilitate IGP operations, such as forming neighbor adjacencies, 639 flooding link state database packets, and representing topology, 640 routing should treat the Ethernet broadcast point-to-point control 641 channel between adjacent E-LSRs as a point-to-point circuit. 643 The routing distribution must support the exchange of TE (intra- 644 domain) and reachability (intra and inter-domain) information across 645 the GMPLS Ethernet network(s). 647 In order to support different label-encoding techniques, it may be 648 necessary to extend the TE information distribution protocols (OSPF- 649 TE [RFC3630]/ISIS-TE [RFC3784]) with the following capabilities: 650 Label-controlled Ethernet Interface Switching Capability Descriptors 651 as an label-controlled Ethernet interface may support more than label 652 switching technique. 654 These capabilities will be distributed as part of the routing 655 distribution and will be considered as constraints during path 656 selection. 658 5.2. Signaling 660 The signaling protocol utilizes downstream-on-demand label allocation 661 and distribution, with ingress-initiated ordered control. The 662 signaling mechanisms MUST apply to both the bi-directional and 663 unidirectional Ethernet LSP setup. 665 GMPLS RSVP-TE [RFC3473] signaling for setup/teardown of Ethernet LSPs 666 (across GMPLS-enabled Ethernet network elements) should be supported 667 and it must keep RSVP sessions significant on an end-to-end basis. 669 The Generalized Label Request is defined in [RFC3471]. The Ethernet 670 LSP encoding type and switching type to be used for requesting an 671 Ethernet label are "Ethernet" and "L2SC" respectively. In order to 672 support different label-encoding techniques, it may be necessary to 673 extend possible values for the LSP encoding type. 675 The specific label-controlled Ethernet LSP parameters should be 676 described in the signaled traffic parameters (t_spec/r_spec). These 677 parameters must include the L2 link type that comprises the requested 678 Ethernet LSP, for example, the Ethernet port and the MTU value. They 679 MUST also be capable of describing the traffic parameters for this 680 Ethernet LSP, such as the Peak Rate (PIR and PBS), the Committed Rate 681 (CIR and CBS), and the Excess Rate (EIR and EBS). 683 Explicit and record routing must be supported for scenarios making 684 use of source routing, for example, for those that provide 685 constraint-based routing (for resource and/or data traffic oriented 686 TE) and loop avoidance. Explicit routing, when used, must follow the 687 procedures defined in [RFC3209], [RFC3473], and [RFC3477]. Record 688 routing, when used, must follow the procedures defined in [RFC3209], 689 [RFC3473], and [RFC3477]. Explicit label control should be supported 690 during provisioning of Ethernet LSPs. 692 The GMPLS re-routing mechanisms should be usable for the recovery of 693 Ethernet LSPs, including, end-to-end and segment LSPs. Ethernet LSP 694 notification and graceful deletion procedures [RFC3473] should be 695 supported. Graceful restart upon a control channel and node failure 696 should also be supported. 698 Nesting of Ethernet LSPs or PSC LSPs into an FA LSP should be 699 supported when the head/tail end-nodes provide de/multiplexing 700 capabilities. 702 Ethernet LSP splicing [RFC3471] and Ethernet LSP stitching [RSVP-ID] 703 must be envisioned in the context of multi-domain environments. The 704 solution must support both edge-to-edge and end-to-end models and 705 their specific signaling operations. 707 5.3. Link discovery 709 Nodes are inter-connected by point-to-point L2SC links. GMPLS L2SC 710 nodes MUST support discovery of per-TE link capabilities. 712 In addition, GMPLS link discovery SHOULD provide the following: 713 - Data link property correlation to support the aggregation of 714 multiple data links into a single TE link and the synchronization of 715 their properties 716 - Data link verification to check the data links' physical 717 connectivity and to verify the mapping of the interface ID to link ID 718 and their local-remote associations 720 Optionally, fault management MAY be provided to suppress alarms and 721 localize failures. It may be required to extend the LMP in order to 722 provide this functionality for GMPLS-controlled Ethernet networks. 724 5.4. Security 726 The introduction of Ethernet LSP signaling MUST prevent attacks by 727 offering adequate filters (like ACLs or other new systems). 729 The Ethernet LSP SHOULD reduce data plane threats, as the number of 730 network entry points to control is reduced. An Ethernet LSP is by 731 nature a hermetic tunnel with a single entry point (ingress E-LER). 732 Policing and filtering is required only on the ingress E-LER. 734 Some mechanisms MUST be provided at the network edges (on the ingress 735 E-LERs) to rate limit the amount of traffic that can transit into a 736 given Ethernet LSP. 738 5.4.1 Attacks on the Control Plane 740 There are two threats that concern the control plane. The first 741 relates to signaling support by the client side. As LSP tunnels MAY 742 be signaled from the client site using RSVP-TE, control of such 743 activity MUST be provided to prevent it from being used to fail the 744 entire network. Different trust models MUST be supported. 746 There MUST be a way to limit, by configuration, the number of 747 Ethernet LSPs that can be signaled by a particular client. In 748 addition, there must be a way to rate limit RSVP-TE client-control 749 plane traffic (mainly via the refresh interval). Moreover, the 750 operator MUST be able to rate limit, by configuration, the total 751 amount of memory and/or CPU allocated to the RSVP engine, and to 752 react appropriately when this limit is reached. 754 The second threat derives from the introduction of IP control 755 functions in Ethernet equipment (such as the handling of multicast). 756 GMPLS Ethernet networks will inherit the security issues of IP 757 networks similar to other GMPLS client networks, and the appropriate 758 trust models MUST be supported. 760 6. Security Considerations 762 See Section 5.4.1 764 7. References 766 7.1. Normative References 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 772 V., and G. Swallow, "RSVP-TE: Extensions to RSVP 773 for LSP Tunnels", RFC 3209, December 2001. 775 [RFC3477] K.Kompella et al. "Signalling Unnumbered Links in 776 Resource ReSerVation Protocol - Traffic Engineering 777 (RSVP-TE)", RFC 3477, January 2003. 779 [RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to 780 OSPF Version 2", RFC 3630, September 2003. 782 [RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate 783 System (IS-IS) Extensions for Traffic 784 Engineering (TE)," RFC 3784, June 2004. 786 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 787 Switching (GMPLS) Signaling Functional Description", 788 RFC 3471, January 2003. 790 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 791 Switching (GMPLS) Signaling Resource ReserVation 792 Protocol-Traffic Engineering (RSVP-TE) Extensions", 793 RFC 3473, January 2003. 795 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label 796 Switching (GMPLS) Architecture", RFC 3945, October 797 2004. 799 7.2. Informative References 801 [MRN-REQ] K.Shiomoto et al., "Requirements for GMPLS-based 802 Multi-Region Networks (MRN)", Work in Progress, draft- 803 ietf-ccamp-gmpls-mrn-reqs-00.txt. 805 8. Acknowledgments 807 9. Author's Addresses 809 Dimitri Papadimitriou 810 Alcatel 811 Francis Wellesplein 1, 812 B-2018 Antwerpen, Belgium 813 Phone: +32 3 2408491 814 Email: dimitri.papadimitriou@alcatel.be 816 Nurit Sprecher 817 Siemens AG (Seabridge Networks) 818 3 Hanagar St. Neve Ne'eman B 819 Hod Hasharon, 45241 Israel 820 Email: nurit.sprecher@seabridgenetworks.com 822 Jaihyung Cho 823 Electronics and Telecommunications Research Institute (ETRI) 824 161 Gajung-dong, Yuseong-gu 825 Daejeon 305-350, Korea 826 Phone: +82 42 860 5514 827 Email: jaihyung@etri.re.kr 829 Loa Andersson 830 Acreo AB 831 Email: loa@pi.se 833 Attila Tak�cs 834 Traffic Lab, Ericsson Research 835 Ericsson Hungary Ltd. 836 Laborc 1. 837 Budapest, Hungary, H-1037 838 Email: attila.takacs@ericsson.com 840 Peter Busschbach 841 Lucent Technologies 842 67 Whippany Rd 843 Whippany, NJ 07981, USA 844 Phone: +1 973 386 8244 845 Email: busschbach@lucent.com 847 Don Fedyk 848 Nortel Networks 849 600 Technology Park 850 Billerica, Massachusetts 851 01821 U.S.A 852 Phone: +1 (978) 288 3041 853 Email: dwfedyk@nortel.com 855 Dave Allan 856 Nortel 857 3500 Carling Ave. 858 Ottawa, Ontario 859 K1Y 4H7 860 Phone: (613) 763-6362 861 Email: dallan@nortel.com 863 Thomas Eriksson 864 TeliaSonera AB 865 Vitsandsgatan 9, Pv2 866 12386 Farsta Sweden 867 Email: thomas.a.eriksson@teliasonera.com 869 Diego Caviglia 870 Email: diego.caviglia@ericsson.com 872 Full Copyright Statement 874 Copyright (C) The Internet Society (2006). 876 This document is subject to the rights, licenses and restrictions 877 contained in BCP 78, and except as set forth therein, the authors 878 retain all their rights. 880 This document and the information contained herein are provided on an 881 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 882 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 883 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 884 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 885 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 886 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 888 Intellectual Property 890 The IETF takes no position regarding the validity or scope of any 891 Intellectual Property Rights or other rights that might be claimed to 892 pertain to the implementation or use of the technology described in 893 this document or the extent to which any license under such rights 894 might or might not be available; nor does it represent that it has 895 made any independent effort to identify any such rights. Information 896 on the procedures with respect to rights in RFC documents can be 897 found in BCP 78 and BCP 79. 899 Copies of IPR disclosures made to the IETF Secretariat and any 900 assurances of licenses to be made available, or the result of an 901 attempt made to obtain a general license or permission for the use of 902 such proprietary rights by implementers or users of this 903 specification can be obtained from the IETF on-line IPR repository at 904 http://www.ietf.org/ipr. 906 The IETF invites any interested party to bring to its attention any 907 copyrights, patents or patent applications, or other proprietary 908 rights that may cover technology that may be required to implement 909 this standard. Please address the information to the IETF at ietf- 910 ipr@ietf.org.