idnits 2.17.1 draft-ietf-ccamp-gmpls-ethernet-arch-09.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 (January 14, 2010) is 5187 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.8011.1' is mentioned on line 148, but not defined == Missing Reference: 'G.8011.2' is mentioned on line 149, but not defined -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-ethernet-traffic-parameters-09 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Don Fedyk, Alcatel-Lucent 2 Category: Informational Lou Berger, LabN 3 Expiration Date: July 14, 2010 Loa Andersson, Ericsson AB 5 January 14, 2010 7 Generalized Multi-Protocol Label Switching (GMPLS) Ethernet 8 Label Switching Architecture and Framework 10 draft-ietf-ccamp-gmpls-ethernet-arch-09.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 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on July 14, 2010. 35 Copyright and License Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 There has been significant recent work in increasing the capabilities 49 of Ethernet switches and Ethernet forwarding models. As a 50 consequence, the role of Ethernet is rapidly expanding into 51 "transport networks" that previously were the domain of other 52 technologies such as Synchronous Optical Network (SONET)/Synchronous 53 Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and 54 Asynchronous Transfer Mode (ATM). This document defines an 55 architecture and framework for a Generalized MPLS based control plane 56 for Ethernet in this "transport network" capacity. GMPLS has already 57 been specified for similar technologies. Some additional extensions 58 to the GMPLS control plane are needed and this document provides a 59 framework for these extensions. 61 Table of Contents 63 1 Introduction ........................................... 4 64 1.1 Terminology ............................................ 6 65 1.1.1 Concepts ............................................... 6 66 1.1.2 Abbreviations and Acronyms ............................. 7 67 2 Background ............................................. 8 68 2.1 Ethernet Switching ..................................... 8 69 2.2 Operations, Administration, and Maintenance (OAM) ...... 11 70 2.3 Ethernet Switching Characteristics ..................... 11 71 3 Framework .............................................. 12 72 4 GMPLS Routing and Addressing Model ..................... 14 73 4.1 GMPLS Routing .......................................... 14 74 4.2 Control Plane Network .................................. 15 75 5 GMPLS Signaling ........................................ 15 76 6 Link Management ........................................ 16 77 7 Path Computation and Selection ......................... 17 78 8 Multiple VLANs ......................................... 18 79 9 Security Considerations ................................ 18 80 10 IANA Considerations .................................... 19 81 11 References ............................................. 19 82 11.1 Normative References ................................... 19 83 11.2 Informative References ................................. 19 84 12 Acknowledgments ........................................ 21 85 13 Author's Addresses ..................................... 21 87 1. Introduction 89 There has been significant recent work in increasing the capabilities 90 of Ethernet switches. As a consequence, the role of Ethernet is 91 rapidly expanding into "transport networks" that previously were the 92 domain of other technologies such as SONET/SDH, TDM and ATM. The 93 evolution and development of Ethernet capabilities in these areas is 94 a very active and ongoing process. 96 Multiple organizations have been active in extending Ethernet 97 Technology to support transport networks. This activity has taken 98 place in the Institute of Electrical and Electronics Engineers (IEEE) 99 802.1 Working Group, the International Telecommunication Union - 100 Telecommunication Standardization Sector (ITU-T) and the Metro 101 Ethernet Forum (MEF). These groups have been focusing on Ethernet 102 forwarding, Ethernet management plane extensions and the Ethernet 103 Spanning Tree Control Plane, but not on an explicitly routed, 104 constraint-based control plane. 106 In the forwarding plane context, extensions have been, or are being, 107 defined to support different transport Ethernet forwarding models, 108 protection modes, and service interfaces. Examples of such 109 extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These 110 extensions allow for greater flexibility in the Ethernet forwarding 111 plane and, in some cases, the extensions allow for a departure from 112 forwarding based on Spanning tree. For example, in the [802.1Qah] 113 case, greater flexibility in forwarding is achieved through the 114 addition of a "provider" address space. [802.1Qay] supports the use 115 of provisioning systems and network control protocols that explicitly 116 select traffic engineered paths. 118 This document provides a framework for GMPLS Ethernet Label Switching 119 (GELS). GELS will likely require more than one switching type to 120 support the different models, and as the GMPLS procedures that will 121 need to be extended are dependent on switching type, these will be 122 covered in the technology specific documents. 124 In the provider bridge model developed in the IEEE 802.1ad project 125 and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual 126 Local Area Network (VLAN) identifier (VID) is added. This VLAN is 127 referred to as the Service VID, (S-VID) and is carried in a Service 128 TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah], a backbone 129 VID (B-VID) and B-MAC header with a service instance (I-TAG) 130 encapsulates a customer Ethernet frame or a service Ethernet frame. 132 In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB) 133 and Provider Backbone Bridged Network (PBBN) are used in the context 134 of these extensions. 136 An example of Ethernet protection extensions can be found in 137 [G.8031]. Ethernet operations, administration, and maintenance (OAM) 138 is another important area that is being extended to enable provider 139 Ethernet services. Related extensions can be found in [802.1ag] and 140 [Y.1731]. 142 An Ethernet based service model is being defined within the context 143 of the MEF and ITU-T. [MEF.6] and [G.8011] provide parallel 144 frameworks for defining network-oriented characteristics of Ethernet 145 services in transport networks. These framework documents discuss 146 general Ethernet connection characteristics, Ethernet User-Network 147 Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs). 148 [G.8011.1] defines the Ethernet Private Line (EPL) service and 149 [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. 150 [MEF.6] covers both service types. These activities are consistent 151 with the types of Ethernet switching defined in [802.1ah]. 153 The Ethernet forwarding and management plane extensions allow for the 154 disabling of standard Spanning tree but do not define an explicitly 155 routed, constraint-based control plane. For example [802.1Qay] is an 156 amendment to IEEE 802.1Q that explicitly allows for traffic 157 engineering of Ethernet forwarding paths. 159 The IETF's GMPLS work provides a common control plane for different 160 data plane technologies for Internet and telecommunication service 161 providers. The GMPLS architecture is specified in RFC3945 [RFC3945]. 162 The protocols specified for GMPLS can be used to control "Transport 163 Network" technologies, e.g. Optical and TDM networks. GMPLS can also 164 be used for packet and Layer 2 Switching (frame/cell based networks). 166 This document provides a framework for use of GMPLS to control 167 "transport" Ethernet Label Switched Paths (Eth-LSP). Transport 168 Ethernet adds new constraints which require it to be distinguished 169 from the previously specified technologies for GMPLS. Some additional 170 extensions to the GMPLS control plane are needed and this document 171 provides a framework for these extensions. All extensions to support 172 Eth-LSPs will build on the GMPLS architecture and related 173 specifications. 175 This document introduces and explains GMPLS control plane use for 176 transport Ethernet and the concept of the Ethernet Label Switched 177 Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the 178 scope of this document and IETF activities. 180 The intent of this document is to reuse and align with as much of the 181 GMPLS protocols as possible. For example, reusing the IP control 182 plane addressing allows existing signaling, routing, LMP and path 183 computation to be used as specified. The GMPLS protocols support 184 hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol 185 mechanisms support a variety of network reference points from UNIs to 186 NNIs. Additions to existing GMPLS capabilities will only be made to 187 accommodate features unique to transport Ethernet. 189 1.1. Terminology 191 1.1.1. Concepts 193 The following are basic Ethernet and GMPLS terms: 195 o Asymmetric Bandwidth 197 This term refers to a property of a Bidirectional service 198 instance that has differing bandwidth allocation in each 199 direction. 201 o Bidirectional Congruent LSP 203 This term refers to the property of a bidirectional LSP that uses 204 only the same nodes, ports, and links in both directions. 205 Ethernet data planes are normally bidirectional congruent 206 (sometimes known as reverse path congruent). 208 o Contiguous Eth-LSP 210 A contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from 211 multiple Eth-LSPs each operating within a VLAN and that are 212 mapped one-to-one at the VLAN boundaries. Stitched LSPs form 213 contiguous LSPs. 215 o Eth-LSP 217 This term refers to Ethernet label switched paths that may be 218 controlled via GMPLS. 220 o Hierarchical Eth-LSP 222 Hierarchical Eth-LSPs aggregate Eth-LSPs by creating a hierarchy 223 of Eth-LSPs. 225 o In-band GMPLS Signaling 227 In-band GMPLS Signaling is IP based control messages which are 228 sent on the native Ethernet links encapsulated by a single hop 229 Ethernet header. Logical links that use a dedicated VID on the 230 same physical links would be considered In-band signaling. 232 o Out-of-band GMPLS Signaling 234 Out-of-band GMPLS Signaling is composed of IP based control 235 messages that are sent between Ethernet switches over links other 236 than the links used by the Ethernet data plane. Out of band 237 signaling typically shares a different fate from the data links. 239 o Point-to-point (P2P) Traffic Engineering (TE) service instance 241 A TE service instance made up of a single bidirectional P2P or 242 two P2P unidirectional Eth-LSPs. 244 o Point-to-multipoint (P2MP) Traffic Engineering (TE) service 245 instance 247 A TE service instance supported by a set of LSPs which comprises 248 one P2MP LSP from a root to n leaves plus a Bidirectional 249 Congruent point-to-point (P2P) LSP from each of the leaves to the 250 root. 252 o Shared forwarding 254 Shared forwarding is a property of a data path where a single 255 forwarding entry (VID + DMAC) may be used for frames from 256 multiple sources (SMAC). Shared forwarding does not change any 257 data plane behavior. Shared forwarding saves forwarding database 258 (FDB) entries only. Shared forwarding offers similar benefits to 259 merging in the data plane. However in shared forwarding the 260 Ethernet data packets are unchanged when using shared forwarding. 261 With shared forwarding dedicated control plane states for all 262 Eth-LSPs are maintained regardless of shared forwarding entries. 264 1.1.2. Abbreviations and Acronyms 266 The following abbreviations and acronyms are used in this document: 268 CCM Continuity Check Message 269 CFM Connectivity Fault Management 270 DMAC Destination MAC Address 271 Eth-LSP Ethernet Label Switched Path 272 I-SID Backbone Service Identifier carried in the I-TAG 273 I-TAG A Backbone Service Instance TAG defined in the 274 IEEE 802.1ah Standard [802.1ah] 275 LMP Link Management Protocol 276 MAC Media Access Control 277 MP2MP Multipoint to multipoint 278 NMS Network Management System 279 OAM Operations, Administration and Maintenance 280 PBB Provider Backbone Bridges [802.1ah] 281 PBB-TE Provider Backbone Bridges Traffic Engineering 282 [802.1Qay] 283 P2P Point to Point 284 P2MP Point to Multipoint 285 QoS Quality of Service 286 SMAC Source MAC Address 287 S-TAG A Service TAG defined in the IEEE 802.1 Standard 288 [802.1Q] 289 TE Traffic Engineering 290 TAG An Ethernet short form for a TAG Header 291 TAG Header An extension to an Ethernet frame carrying 292 priority and other information. 293 TSpec Traffic specification 294 VID VLAN Identifier 295 VLAN Virtual LAN 297 2. Background 299 This section provides background to the types of switching and 300 services that are supported within the defined framework. The former 301 is particularly important as it identifies the switching functions 302 that GMPLS will need to represent and control. The intent is for this 303 document to allow for all standard forms of Ethernet switching and 304 services. 306 The material presented in this section is based on both finished and 307 on-going work taking place in the IEEE 802.1 Working Group, the ITU-T 308 and the MEF. This section references and, to some degree, summarizes 309 that work. This section is not a replacement for, or an 310 authoritative description of that work. 312 2.1. Ethernet Switching 314 In Ethernet switching terminology, the bridge relay is responsible 315 for forwarding and replicating the frames. Bridge relays forward 316 frames based on the Ethernet header fields: Virtual Local Area 317 Network (VLAN) Identifiers (VID) and Destination Media Access Control 318 (DMAC) address. PBB [802.1ah] has also introduced a Service Instance 319 tag (I-TAG). Across all the Ethernet extensions (already referenced 320 in the Introduction), multiple forwarding functions, or service 321 interfaces, have been defined using the combination of VIDs, DMACs, 322 and I-TAGs. PBB [802.1ah] provides a breakdown of the different 323 types of Ethernet switching services. Figure 1 reproduces this 324 breakdown. 326 PBB Network 327 Service Types 328 _,,-' | '--.._ 329 _,.-'' | `'--.._ 330 _,.--' | `'--.. 331 Port based S-tagged I-tagged 332 _,- -. 333 _.' `. 334 _,' `. 335 one-to-one bundled 336 _.- =. 337 _.-' ``-.._ 338 _.-' `-.. 339 many-to-one all-to-one 340 | 341 | 342 | 343 Transparent 345 Figure 1: Ethernet Switching Service Types 347 The switching types are defined in Clause 25 of [802.1ah]. While not 348 specifically described in [802.1ah], the Ethernet services being 349 defined in the context of [MEF.6] and [G.8011] also fall into the 350 types defined in Figure 1 (with the exception of the newly defined I- 351 tagged service type). 353 [802.1ah] defines a new I-tagged service type but does not 354 specifically define the Ethernet services being defined in the 355 context of [MEF.6] and [G.8011] which are also illustrated in Figure 356 1. 358 To summarize the definitions: 360 o Port based 361 This is a frame based service that supports specific frame types, 362 no Service VLAN tagging or MAC address based switching. 364 o S-tagged 365 There are multiple Service VLAN tag (S-tag) aware services, 366 including: 368 + one-to-one 369 In this service, each VLAN identifier (VID) is mapped into a 370 different service. 372 + Bundled 373 Bundled S-tagged service supports the mapping of multiple VIDs 374 into a single service and include: 376 * many-to-one 377 In this frame based service, multiple VIDs are mapped into the 378 same service. 380 * all-to-one 381 In this frame based service, all VIDs are mapped into the same 382 service. 384 - transparent 385 This is a special case, all frames are mapped from a single 386 incoming port to a single destination Ethernet port. 388 o I-tagged 389 The edge of a PBBN consists of a combined backbone relay (B- 390 component relay) and service instance relay (I-component relay). 391 An I-Tag contains a service identifier (24 bit I-SID) and priority 392 markings as well as some other fields. An I-Tagged service is 393 typically between the edges of the PBBN and terminated at each edge 394 on an I-component that faces a customer port so the service is 395 often not visible except at the edges. However, since the I- 396 component relay involves a distinct relay, it is possible to have a 397 visible I-Tagged Service by separating the I component relay from 398 the B-component relay. Two examples where it makes sense to do 399 this are: an I-Tagged service between two PBBNs and as an 400 attachment to a customer's Provider Instance Port. 402 In general, the different switching types determine which of the 403 Ethernet header fields are used in the forwarding/switching function, 404 e.g. VID only or VID and DMACs. The switching type may also require 405 the use of additional Ethernet headers or fields. Services defined 406 for UNIs tend to use the headers for requesting service (service 407 delimiter) and are relevant between the customer site and network 408 edge. 410 In most bridging cases, the header fields cannot be changed, but some 411 translations of VID field values are permitted, typically at the 412 network edges. 414 Across all service types, the Ethernet data plane is bidirectional 415 congruent. This means that the forward and reverse paths share the 416 exact same set of nodes, ports and bidirectional links. This 417 property is fundamental. The 802.1 group has maintained this 418 bidirectional congruent property in the definition of Connectivity 419 Fault Management (CFM) which is part of the overall Operations 420 Administration and Maintenance (OAM) capability. 422 2.2. Operations, Administration, and Maintenance (OAM) 424 Robustness is enhanced with the addition of data plane OAM to provide 425 both fault and performance management. 427 Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane 428 forwarding for both directions. Determining a broken path or 429 misdirected packet in this case relies on OAM following the Eth-LSP. 430 These OAM message identifiers are dependent on the data plane so they 431 work equally well for provisioned or GMPLS controlled paths. 433 Ethernet OAM currently consists of: 434 Defined in both [802.1ag & Y.1731]: 435 - CCM/RDI: Connectivity Check, Remote Defect Indication 436 - LBM/LBR: Loopback Message, Loopback Reply 437 - LTM/LTR: Link trace Message, Link trace Reply 438 - VSM/VSR: Vendor-specific extensions Message/Reply 440 Additionally defined in [Y.1731]: 441 - AIS: Alarm Indication Signal 442 - LCK: Locked Signal 443 - TST: Test 444 - LMM/LMR: Loss Measurement Message/Reply 445 - DM/DMM/DMR: Delay Measurement 446 - EXM/EXR: Experimental 447 - APS, MCC: Automatic Protection Switching, Maintenance 448 Communication Channel 450 These functions are supported across all the Standardized Eth-LSP 451 formats. 453 2.3. Ethernet Switching Characteristics 455 Ethernet is similar to MPLS as it encapsulates different packet and 456 frame types for data transmission. In Ethernet, the encapsulated 457 data is referred to as MAC client data. The encapsulation is an 458 Ethernet MAC frame with a header, a source address, destination 459 address, optional VLAN identifier, Type and length on the front of 460 the MAC client data with optional padding and a Frame Check Sequence 461 at the end of the frame. 463 The type of MAC client data is typically identified by an "Ethertype" 464 value. This is an explicit type indication but Ethernet also supports 465 an implicit type indication. 467 Ethernet bridging switches based on a frame's destination MAC address 468 and VLAN. The VLAN identifies a virtual active set of Bridges and 469 LANs. The address is assumed to be unique and invariant within the 470 VLAN. MAC addresses are often globally unique but this is not 471 necessary for bridging. 473 3. Framework 475 As defined in the GMPLS Architecture [RFC3945], the GMPLS control 476 plane can be applied to a technology by controlling the data plane 477 and switching characteristics of that technology. The GMPLS 478 architecture, per [RFC3945], allowed for control of Ethernet bridges 479 and other layer 2 technologies using the Layer-2 Switch Capable 480 (L2SC) switching type. But, the control of Ethernet switching was 481 not explicitly defined in [RFC3471], [RFC4202] or any other 482 subsequent GMPLS reference document. 484 The GMPLS architecture includes a clear separation between a control 485 plane and a data plane. Control plane and data plane separation 486 allows the GMPLS control plane to remain architecturally and 487 functionally unchanged while controlling different technologies. The 488 architecture also requires IP connectivity for the control plane to 489 exchange information, but does not otherwise require an IP data 490 plane. 492 All aspects of GMPLS, i.e., addressing, signaling, routing and link 493 management, may be applied to Ethernet switching. GMPLS can provide 494 control for traffic engineered and protected Ethernet service paths. 495 This document defines the term "Eth-LSP" to refer to Ethernet service 496 paths that are controlled via GMPLS. As is the case with all GMPLS 497 controlled services, Eth-LSPs can leverage common traffic engineering 498 attributes such as: 500 - bandwidth profile; 501 - forwarding priority level; 502 - connection preemption characteristics; 503 - protection/resiliency capability; 504 - routing policy, such as an explicit route; 505 - bidirectional service; 506 - end-to-end and segment protection; 507 - hierarchy 509 The bandwidth profile may be used to set committed information rate, 510 peak information rate, and policies based on either under- 511 subscription or over-subscription. Services covered by this 512 framework will use a TSpec that follows the Ethernet Traffic 513 parameters defined in [ETH-TSPEC]. 515 In applying GMPLS to "transport" Ethernet, GMPLS will need to be 516 extended to work with the Ethernet data plane and switching 517 functions. The definition of GMPLS support for Ethernet is multi- 518 faceted due to the different forwarding/switching functions inherent 519 in the different service types discussed in Section 2.1. In general, 520 the header fields used in the forwarding/switching function, e.g. VID 521 and DMAC, can be characterized as a data plane label. In some 522 circumstances these fields will be constant along the path of the 523 Eth-LSP, and in others they may vary hop-by-hop or at certain 524 interfaces only along the path. In the case where the "labels" must 525 be forwarded unchanged, there are a few constraints on the label 526 allocation that are similar to some other technologies such as lambda 527 labels. 529 The characteristics of the "transport" Ethernet data plane are not 530 modified in order to apply GMPLS control. For example, consider the 531 IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter" 532 pointing to a particular forwarding table, and if the DMAC is found 533 in that forwarding table the forwarding decision is taken based on 534 the DMAC. When forwarding using an Spanning tree, if the DMAC is not 535 found the frame is broadcast over all outgoing interfaces for which 536 that VID is defined. This valid MAC checking and broadcast supports 537 Ethernet learning. A special case is when a VID is defined for only 538 two ports on one bridge, effectively resulting in a p2p forwarding 539 constraint. In this case all frames tagged with that VID received 540 over one of these ports are forward over the other port without 541 address learning. 543 [802.1Qay] allows for turning off learning and hence the broadcast 544 mechanism providing means to create explicitly routed Ethernet 545 connections. 547 This document does not define any specific format for an Eth-LSP 548 label. Rather, it is expected that service specific documents will 549 define any signaling and routing extensions needed to support a 550 specific Ethernet service. Depending on the requirements of a 551 service, it may be necessary to define multiple GMPLS protocol 552 extensions and procedures. It is expected that all such extensions 553 will be consistent with this document. 555 It is expected that a key requirement for service specific documents 556 will be to describe label formats and encodings. It may also be 557 necessary to provide a mechanism to identify the required Ethernet 558 service type in signaling and a way to advertise the capabilities of 559 Ethernet switches in the routing protocols. These mechanisms must 560 make it possible to distinguish between requests for different 561 paradigms including new, future, and existing paradigms. 563 The Switching Type and Interface Switching Capability Descriptor 564 share a common set of values and are defined in [RFC3945], [RFC3471], 565 and [RFC4202] as indicators of the type of switching that should 566 ([RFC3471]) and can ([RFC4202]) be performed on a particular link for 567 an LSP. The L2SC switching type may already be used by 568 implementations performing layer 2 switching including Ethernet. As 569 such, and to allow the continued use of that switching type and those 570 implementations, and to distinguish the different Ethernet switching 571 paradigms, a new switching type needs to be defined for each new 572 Ethernet switching paradigm that is supported. 574 For discussion purposes, we decompose the problem of applying GMPLS 575 into the functions of Routing, Signaling, Link Management and Path 576 Selection. It is possible to use some functions of GMPLS alone or in 577 partial combinations. In most cases using all functions of GMPLS 578 leads to less operational overhead than partial combinations. 580 4. GMPLS Routing and Addressing Model 582 The GMPLS routing and addressing model is not modified by this 583 document. GMPLS control for Eth-LSPs uses the routing and Addressing 584 Model described in [RFC3945]. Most notably this includes the use of 585 IP addresses to identify interfaces and LSP end-points. It also 586 includes support for both numbered and unnumbered interfaces. 588 In the case where another address family or type of identifier is 589 required to support an Ethernet service, extensions may be defined to 590 provide mapping to an IP address. Support of Eth-LSPs is expected to 591 strictly comply to the GMPLS protocol suite addressing as specific in 592 [RFC3471], [RFC3473] and related documents. 594 4.1. GMPLS Routing 596 GMPLS routing as defined in [RFC4202] uses IP routing protocols with 597 opaque TLV extensions for the purpose of distributing GMPLS related 598 TE (router and link) information. As is always the case with GMPLS, 599 TE information is populated based on resource information obtained 600 from LMP or from configured information. The bandwidth resources of 601 the links are tracked as Eth-LSPs are set up. Interfaces supporting 602 the switching of Eth-LSPs are identified using the appropriate 603 Interface Switching Capabilities Descriptor. As mentioned in Section 604 3, the definition of one or more new Interface Switching Capabilities 605 to support Eth-LSPs is expected. Again, the L2SC Interface Switching 606 Capabilities will not be used to represent interfaces capable of 607 supporting Eth-LSPs defined by this document and subsequent documents 608 in support of the transport Ethernet switching paradigms. In 609 addition, Interface Switching Capability specific TE information may 610 be defined as needed to support the requirements of a specific 611 Ethernet Switching Service Type. 613 GMPLS routing is an optional functionality but it is highly valuable 614 in maintaining topology and distributing the TE database for path 615 management and dynamic path computation. 617 4.2. Control Plane Network 619 In order for a GMPLS control plane to operate, an IP connectivity 620 network of sufficient capacity to handle the information exchange of 621 the GMPLS routing and signaling protocols is necessary. 623 One way to implement this is with an IP routed network supported by 624 an IGP that views each switch as a terminated IP adjacency. In other 625 words, IP traffic and a simple routing table are available for the 626 control plane but there is no requirement for needing a high 627 performance IP data plane, or for forwarding user traffic over this 628 IP network. 630 This IP connectivity can be provided as a separate independent 631 network (out of band) or integrated with the Ethernet switches (in- 632 band). 634 5. GMPLS Signaling 636 GMPLS signaling, see [RFC3471][RFC3473], is well suited to the 637 control of Eth-LSPs and Ethernet switches. Signaling provides the 638 ability to dynamically establish a path from an ingress node to an 639 egress node. The signaled path may be completely static and not 640 change for the duration of its lifetime. However, signaling also has 641 the capability to dynamically adjust the path in a coordinated 642 fashion after the path has been established. The range of signaling 643 options from static to dynamic are under operator control. 644 Standardized signaling also improves multi-vendor interoperability. 646 GMPLS signaling supports the establishment and control of 647 bidirectional and unidirectional data paths. Ethernet is 648 bidirectional by nature and CFM has been built to leverage this. 649 Prior to CFM, the emulation of a physical wire and the learning 650 requirements also mandated bidirectional connections. Given this, 651 Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either 652 P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full 653 and partial LSP protection; see [RFC4872] and [RFC4873]. 655 Note that standard GMPLS does not support different bandwidth in each 656 direction of a bidirectional LSP. [RFC5467], an Experimental 657 document, provides procedures if asymmetric bandwidth bidirectional 658 LSPs are required. 660 6. Link Management 662 Link discovery has been specified for links interconnecting IEEE 663 802.1 bridges in [802.1AB]. The benefits of running link discovery 664 in large systems are significant. Link discovery may reduce 665 configuration and reduce the possibility of undetected errors in 666 configuration as well as exposing misconnections. However the 802.1AB 667 capability is an optional feature, it is not necessarily operating 668 before a link is operational, and it primarily supports the 669 management plane. 671 In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS 672 control plane link management and discovery features. LMP also 673 supports for the control plane the automated creation of unnumbered 674 interfaces. If LMP is not used there is an additional configuration 675 requirement for GMPLS link identifiers. For large-scale 676 implementations LMP is beneficial. LMP also has optional fault 677 management capabilities, primarily for opaque and transparent network 678 technology. With IEEE's newer CFM [802.1ag] and ITU-T's [Y.1731] 679 capabilities, this optional capability may not be needed. It is the 680 goal of the GMPLS Ethernet architecture to allow the selection of the 681 best tool set for the user needs. The full functionality of Ethernet 682 CFM should be supported when using a GMPLS control plane. 684 LMP and 802.1AB are relatively independent. The LMP capability should 685 be sufficient to remove the need for 802.1AB but 802.1 AB can be run 686 in parallel or independently if desired. Figure 2 provides possible 687 ways of using LMP, 802.1AB and 802.1ag in combination. 689 Figure 2 illustrates the functional relationship of link management 690 and OAM schemes. It is expected that LMP would be used for control 691 plane functions of link property correlation but that Ethernet 692 mechanisms for OAM such as CFM, link trace, etc. would be used for 693 data plane fault management and fault trace. 695 +-------------+ +-------------+ 696 | +---------+ | | +---------+ | 697 | | | | | | | |GMPLS 698 | | LMP |-|<------>|-| LMP | |Link Property 699 | | | | | | | |Correlation 700 | | (opt) | |GMPLS | | (opt) | | 701 | | | | | | | | Bundling 702 | +---------+ | | +---------+ | 703 | +---------+ | | +---------+ | 704 | | | | | | | | 705 | | 802.1AB |-|<------>|-| 802.1AB | |P2P 706 | | (opt) | |Ethernet| | (opt) | |link identifiers 707 | | | | | | | | 708 | +---------+ | | +---------+ | 709 | +---------+ | | +---------+ | 710 | | | | | | | |End to End 711 -----|-| 802.1ag |-|<------>|-| 802.1ag |-|------- 712 | | Y.1731 | |Ethernet| | Y.1731 | |Fault Management 713 | | (opt) | | | | (opt) | |Performance 714 | | | | | | | |Management 715 | +---------+ | | +---------+ | 716 +-------------+ +-------------+ 717 Switch 1 link Switch 2 719 Figure 2: Logical Link Management Options 721 7. Path Computation and Selection 723 GMPLS does not specify a specific method for selecting paths or 724 supporting path computation. GMPLS allows for a wide range of 725 possibilities supported from very simple path computation to very 726 elaborate path coordination where a large number of coordinated paths 727 are required. Path computation can take the form of paths being 728 computed in a fully distributed fashion, on a management station with 729 local computation for rerouting, or on more sophisticated path 730 computation servers. 732 Eth-LSPs may be supported using any path selection or computation 733 mechanism. As is the case with any GMPLS path selection function, and 734 common to all path selection mechanisms, the path selection process 735 should take into consideration Switching Capabilities and Encoding 736 advertised for a particular interface. Eth-LSPs may also make use of 737 the emerging path computation element and selection work; see 738 [RFC4655]. 740 8. Multiple VLANs 742 This document allows for the support of the signaling of Ethernet 743 parameters across multiple VLANs supporting both contiguous Eth-LSP 744 and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS 745 hierarchy for the support of Peer to Peer models, UNIs and NNIs. 747 9. Security Considerations 749 A GMPLS controlled "transport" Ethernet system should assume that 750 users and devices attached to UNIs may behave maliciously, 751 negligently, or incorrectly. Intra-provider control traffic is 752 trusted to not be malicious. In general, these requirements are no 753 different from the security requirements for operating any GMPLS 754 network. Access to the trusted network will only occur through the 755 protocols defined for the UNI or NNI or through protected management 756 interfaces. 758 When in-band GMPLS signaling is used for the control plane the 759 security of the control plane and the data plane may affect each 760 other. When out-of-band GMPLS signaling is used for the control 761 plane the data plane security is decoupled from the control plane and 762 therefore the security of the data plane has less impact on overall 763 security. 765 Where GMPLS is applied to the control of VLAN only, the commonly 766 known techniques for mitigation of Ethernet DOS attacks may be 767 required on UNI ports. 769 For a more comprehensive discussion on GMPLS security please see the 770 MPLS and GMPLS Security Framework [SECURITY]. Cryptography can be 771 used to protect against many attacks described in [SECURITY]. One 772 option for protecting "transport" Ethernet is the use of 802.1AE 773 Media Access Control Security, [MACSEC] which provides encryption and 774 authentication." 776 It is expected that solution documents will include a full analysis 777 of the security issues that any protocol extensions introduce. 779 10. IANA Considerations 781 No new values are specified in this document. 783 11. References 785 11.1. Normative References 787 [RFC3471] Berger, L. (editor), "Generalized MPLS Signaling 788 Functional Description", January 2003, RFC3471. 790 [RFC3473] Berger, L. (editor), "Generalized Multi-Protocol Label 791 Switching (GMPLS) Signaling Resource ReserVation 792 Protocol-Traffic Engineering (RSVP-TE) Extensions", 793 January 2003, RFC3473. 795 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in 796 Support of Generalized MPLS", RFC 4202, October 2005 798 [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label 799 Switching (GMPLS) Architecture", RFC 3495. 801 11.2. Informative References 803 [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection 804 Switching. 806 [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over 807 Transport - Ethernet services framework. 809 [802.1AB] "IEEE Standard for Local and Metropolitan Area 810 Networks, Station and Media Access Control 811 Connectivity Discovery" (2004). 813 [802.1ag] "IEEE Standard for Local and Metropolitan Area 814 Networks - Virtual Bridged Local Area Networks 815 - Amendment 5:Connectivity Fault Management", 816 (2007). 818 [802.1ah] "IEEE Standard for Local and Metropolitan Area 819 Networks - Virtual Bridged Local Area Networks 820 - Amendment 6: Provider Backbone Bridges", 821 IEEE Std 802.1Qah-2008, 14 August 2008. 823 [802.1Qay] "IEEE Standard for Local and Metropolitan Area 824 Networks - Virtual Bridged Local Area Networks 825 Provider Backbone Bridge Traffic Engineering 826 - Amendment 10: ", IEEE Std 802.1Qay-2009, 827 August 5th, 2009. 829 [802.1Q] "IEEE standard for Virtual Bridged Local Area Networks 830 802.1Q-2005", May 19, 2006. 832 [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" 833 RFC4204, October 2005. 835 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services 836 Definitions - Phase I". 838 [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet 839 Services Attributes Phase 1". 841 [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to 842 Multipoint TE LSPs", IETF RFC 4875, May 2007. 844 [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) 845 Architecture", RFC 4655, August 2006. 847 [RFC4872] Lang et.al., "RSVP-TE Extensions in support of 848 End-to-End Generalized Multi-Protocol Label Switching 849 (GMPLS)-based Recovery ", RFC 4872, May 2007. 851 [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 852 2007. 854 [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM 855 Functions and Mechanisms for Ethernet based Networks ", 856 work in progress. 858 [RFC5467] Berger, L. et al., "GMPLS Asymmetric Bandwidth 859 Bidirectional LSPs", RFC5467, March 2009. 861 [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", 862 draft-ietf-ccamp-ethernet-traffic-parameters-09.txt, 863 work in progress. 865 [SECURITY] Luyuan Fang, Ed., "Security Framework for MPLSand GMPLS 866 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 867 framework-07.txt, work in progress. 869 [MACSEC] "IEEE Standard for Local and metropolitan area networks 870 Media Access Control (MAC) Security 871 IEEE 802.1AE-2006", August 18, 2006. 873 12. Acknowledgments 875 There were many people involved in the initiation of this work prior 876 to this document. The GELS framework draft and the PBB-TE extensions 877 drafts were two drafts the helped shape and justify this work. We 878 acknowledge the work of these authors of these initial drafts: 879 Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, 880 Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, 881 Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil Bitar. 883 George Swallow contributed significantly to this document. 885 13. Author's Addresses 887 Don Fedyk 888 Alcatel-Lucent 889 Groton, MA, 01450 890 Phone: +1-978-467-5645 891 Email: donald.fedyk@alcatel-lucent.com 893 Lou Berger 894 LabN Consulting, L.L.C. 895 Phone: +1-301-468-9228 896 Email: lberger@labn.net 898 Loa Andersson 899 Ericsson AB 900 Phone: +46 10 717 52 13 901 Email: loa.andersson@ericsson.com 903 Generated on: Thu Jan 14 15:15:38 EST 2010