idnits 2.17.1 draft-gmpls-ethernet-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 817. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2007) is 6012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Don Fedyk, Nortel 2 Category: Informational Lou Berger, LabN 3 Expiration Date: May 9, 2008 Loa Andersson, Acreo AB 5 November 9, 2007 7 GMPLS Ethernet Label Switching Architecture and Framework 9 draft-gmpls-ethernet-arch-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on May 9, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 There has been significant recent work in increasing the capabilities 43 of Ethernet switches. As a consequence, the role of Ethernet is 44 rapidly expanding into "transport networks" that previously were the 45 domain of other technologies such as SONET/SDH TDM and ATM. This 46 document defines an architecture and framework for a GMPLS based 47 control plane for Ethernet in this "transport network" capacity. 48 GMPLS has already been specified for similar technologies. Some 49 additional extensions to the GMPLS control plane are needed and this 50 document provides a framework for these extensions. 52 Contents 54 1 Introduction .............................................. 3 55 2 Background ................................................ 5 56 2.1 Ethernet Switching ........................................ 5 57 2.2 Operations, Administration, and Maintenance (OAM) ......... 7 58 2.3 Terminology ............................................... 8 59 2.3.1 Concepts .................................................. 8 60 2.3.2 Acronyms .................................................. 9 61 2.4 Ethernet and MPLS similarities and differences ............ 10 62 3 Framework ................................................. 10 63 4 GMPLS Routing and Addressing Model ........................ 12 64 4.1 GMPLS Routing ............................................. 13 65 4.2 Control Plane Network ..................................... 13 66 5 P2P Signaling ............................................ 13 67 6 Link Management .......................................... 14 68 7 Path Computation and Selection ............................ 15 69 8 Multiple Domains .......................................... 16 70 9 Security Considerations ................................... 16 71 10 IANA Considerations ....................................... 16 72 11 References ................................................ 16 73 11.1 Normative References ...................................... 16 74 11.2 Informative References .................................... 16 75 12 Acknowledgments ........................................... 18 76 13 Author's Addresses ........................................ 18 77 14 Full Copyright Statement .................................. 18 78 15 Intellectual Property ..................................... 19 79 Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 Document History 87 This is the initial draft of this document. 89 1. Introduction 91 There has been significant recent work in increasing the capabilities 92 of Ethernet switches. As a consequence, the role of Ethernet is 93 rapidly expanding into "transport networks" that previously were the 94 domain of other technologies such as SONET/SDH TDM and ATM. The 95 evolution and development of Ethernet capabilities in these areas is 96 a very active and ongoing process. 98 Multiple organizations have been active in extending Ethernet 99 technology. This activity has taken place in the IEEE 802.1 Working 100 Group, the ITU and the MEF. These groups have been focusing on 101 Ethernet forwarding, Ethernet management plane extensions and the 102 Ethernet Spanning Tree Control Plane, but not an explicitly routed, 103 constraint based control plane. 105 In the forwarding plane context, extensions have been, or are being, 106 defined to support different Ethernet forwarding models, protection 107 modes and service interfaces. Examples of such extensions include 108 [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. The provider extensions 109 allow for greater flexibility in the forwarding plane. In the 110 802.1Qay case the extensions allow for a departure from forwarding 111 based on Ethernet spanning tree. The greater flexibility in 112 forwarding is achieved through the addition of a "provider" address 113 space. 115 This document is a framework for GMPLS Ethernet Label switching 116 (GELS). It will be followed by technology specific documents. GELS 117 will require more than one switching type, and the GMPLS procedures 118 that will need to be changed is dependent on switching, and thus will 119 be covered in the technology specific documents. 121 In the new provider bridge model developed in the IEEE802.1ad-project 122 and amended to the IEEE802.1Q standard [802.1Q], an extra VLAN 123 identifier (VID) is added. This VLAN is referred to as the Service 124 VID, (S-VID and is carried in a Service TAG (S-TAG). In provider 125 backbone bridges (PBB) [802.1ah] a backbone VID (B-VID) and B-MAC 126 header with a Service Instance (I-TAG) encapsulates a customer 127 Ethernet frame or a service Ethernet frame. An example of Ethernet 128 protection extensions can be found in [G.8031]. In the IEEE802.1Q 129 standard the terms Provider Backbone Bridges (PBB) and Provider 130 Backbone Bridged Network (PBBN) is used in the context of these 131 extensions. 133 Ethernet operations, administration, and maintenance (OAM) is another 134 important area that is being extended to enable provider Ethernet 135 services. Related extensions can be found in [802.1ag] and [Y.1731]. 137 The Ethernet forwarding and management plane extensions explicitly 138 allow for the disabling of standard Ethernet spanning tree but do not 139 define an explicitly routed, constraint based control plane. The 140 IEEE802.1, in [802.1Qay], works on an new amendment that explicitly 141 allows for traffic engineering of Ethernet forwarding paths. 143 The IETF chartered the GMPLS work to specify a common control plane 144 for physical path and core tunneling technologies for the Internet 145 and telecommunication service providers. The GMPLS architecture is 146 specified in RFC3945 [RFC3945]. The protocols specified for GMPLS 147 have been used to control "Transport Networks", e.g. Optical and TDM 148 networks. 150 This document provides a framework for use of GMPLS to control 151 "transport" Ethernet. The GMPLS architecture already handles a number 152 of transport technologies but Ethernet adds a few new constraints 153 that must be documented. Some additional extensions to the GMPLS 154 control plane are needed and this document provides a framework for 155 these extensions. 157 This document introduces and explains the concept of an Ethernet 158 Label Switched Path (Eth-LSP). The data plane aspects of Eth-LSPs are 159 outside the scope of this document and IETF activities. 161 The intent of this document is to reuse and align with as much of the 162 GMPLS protocols as possible. For example reusing the IP control 163 plane addressing allows the existing signaling, routing, LMP and path 164 computation to be used as specified. Additions are made only to 165 accommodate features of Ethernet that are not already supported by 166 GMPLS. The GMPLS protocols support a set of tools for hierarchical 167 LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms 168 support a variety of networks from peer to peer to UNIs and NNIs. 170 2. Background 172 This section provides background to the types of switching and 173 services that are supported within the defined framework. The former 174 is particularly important as it identifies the switching functions 175 that GMPLS will need to represent and control. The intent is for this 176 document to allow for all standard forms of Ethernet switching and 177 services. 179 The material presented in this section is based on the on-going work 180 taking place in the IEEE 802.1 Working Group, the ITU and the MEF. 181 This section references and, to some degree, summarizes that work. 182 This section is not a replacement for, or an authoritative 183 description of that work. 185 2.1. Ethernet Switching 187 In Ethernet switching terminology, the bridge relay is responsible 188 for forwarding and replicating the frames. Bridge relays forward 189 frames based on the header fields: Virtual Local Area Network (VLAN) 190 Identifiers (VID) and Destination Media Access Control (DMAC) 191 address. PBB [802.1ah] has also introduced a Service Instance tag (I- 192 TAG). Across all the Ethernet extensions (already referenced in the 193 Introduction), multiple forwarding functions, or service interfaces, 194 have been defined using the combination of VIDs, DMACs, and I-TAGs. 195 PBB [802.1ah] provides a breakdown of the different types of Ethernet 196 switching services. Figure 1 reproduces this breakdown. 198 Service Types 199 _,,-' | '--.._ 200 _,.-'' | `'--.._ 201 _,.--' | `'--.. 202 Port based S-tagged I-tagged 203 _,- -. 204 _.' `. 205 _,' `. 206 one-to-one bundled 207 _.- =. 208 _.-' ``-.._ 209 _.-' `-.. 210 many-to-one all-to-one 211 | 212 | 213 | 214 Transparent 216 Figure 1: Ethernet Switching Service Types 218 The types are defined in Clause 25 of [802.1ah], and are consistent 219 with the definitions of Ethernet services supported in [G.8011] and 220 [MEF.6]. To summarize the definitions: 222 o Port based 223 This is a frame based service that supports specific frame types, 224 no Service VLAN tagging, with MAC address based switching. 226 o S-tagged 227 There are multiple Service VLAN tag (S-tag) aware services, 228 including: 230 + one-to-one 231 In this service, each VLAN identifier (VID) is mapped into a 232 different service. 234 + Bundled 235 Bundled S-tagged service supports the mapping of multiple VIDs 236 into a single service and include: 238 * many-to-one 239 In this frame based service, multiple VIDs are mapped into the 240 same service. 242 * all-to-one 243 In this frame based service, all VIDs are mapped into the same 244 service. 246 - transparent 247 This is a special case, all frames are mapped from a single 248 incoming port to a single destination Ethernet port. 250 o I-tagged 251 The edge of a PBBN consists of a combined backbone relay (B- 252 component relay) and service instance relay (I-component relay). 253 An I-Tag contains a service identifier (24 bit I-SID) and priority 254 markings as well as some other flags. An I-Tagged service is 255 typically between the edges of the PBBN and terminated at each edge 256 on an I-component that faces a customer port so the service is 257 often not visible except at the edges. However since the I- 258 component relay involves a distinct relay it is possible to have a 259 visible I-Tagged Service by separating the I component relay from 260 the B-component relay. Two examples where it makes sense to do 261 this are: an I-Tagged service between two PBBNs and as an 262 attachment to a customer's Provider Instance Port. 264 In general, the different types determine which of the Ethernet 265 header fields are used in the forwarding/switching function, e.g. VID 266 only or VID and DMACs. The types may also require the use of 267 additional Ethernet headers or fields. Services defined for UNIs tend 268 to use the headers on a hop-by-hop basis. 270 In most cases for bridging, the header fields cannot be changed hop- 271 by-hop, but some translations of VID field values are permitted 272 typically at the edges. Again, while not specifically described in 273 802.1ah, the Ethernet services being defined in the context of 274 [MEF.6] and [G.8011] also fall into the types defined in Figure 1. 276 Across all service types, the Ethernet data plane is bi-directional 277 congruent. This means that the forward and reverse paths share the 278 exact same set of nodes, ports and bi-directional links. This 279 property is fundamental. The 802.1 group has defined maintained this 280 bi-directional congruent property in the definition of Connectivity 281 Fault Management (CFM) which is part of the overall Operations 282 Administration and Management (OAM) capability. 284 2.2. Operations, Administration, and Maintenance (OAM) 286 Robustness is enhanced with the addition of data plane OAM to provide 287 both fault and performance management. 289 For the Eth LSP unicast mode of behavior, the hardware performs 290 unicast packet forwarding of known MAC addresses exactly as Ethernet 291 currently operates. The OAM currently defined, [802.1ag] and [Y.1731] 292 can also be reused without modification of the protocols. 294 OAM relies on domain wide path identifiers, for data plane 295 forwarding, utilizing the 60 bit unique connection ID (VID/DMAC). 296 Determining a broken path or misdirected packet in this case relies 297 on the connection ID not being altered on the Eth-LSP. These 298 identifiers are independent of the control plane so it works equally 299 well for provisioned or GMPLS controlled paths. 301 Ethernet OAM currently consists of: 302 Defined in both [802.1ag & Y.1731]: 303 - CCM/RDI: Connectivity Check, Remote Defect Indication 304 - LBM/LBR: Loopback Message, Loopback Reply 305 - LTM/LTR: Link trace Message, Link trace Reply 306 - VSM/VSR: Vendor-specific extensions Message/Reply 308 Additionally defined in [Y.1731]: 309 - AIS: Alarm Indication Signal 310 - LCK: Locked Signal 311 - TST: Test 312 - LMM/LMR: Loss Measurement Message/Reply 313 - DM/DMM/DMR: Delay Measurement 314 - EXM/EXR: Experimental 315 - APS, MCC: Automatic Protection Switching, Maintenance 316 Communication Channel 317 - Placeholders for ITU other standards 319 With some Eth-LSP label formats bidirectional transactions (e.g. 320 LBM/LBR) and reverse direction transactions MAY have a different VID 321 for each direction. Currently Y.1731 & 802.1ag makes no 322 representations with respect to this but work us underway to address 323 this in PBB-TE [802.1Qay]. 325 2.3. Terminology 327 2.3.1. Concepts 329 The following are basic Ethernet and GMPLS terms: 331 o Asymmetric Bandwidth 333 This term refers to the property of a Bi-directional LSP may have 334 differing bandwidth allocation in each direction. 336 o Bi-directional Congruent LSP 338 This term refers to the property that an LSP shared the same 339 nodes, ports and links. Ethernet data planes are normally bi- 340 directional congruent. 342 o Shared forwarding 344 Shared forwarding is a property of a data path where a single 345 forwarding entry (VID + DMAC) may be used for frames from 346 multiple sources (SMAC). Shared forwarding does not change any 347 data plane behavior it saves forwarding information base (FIB) 348 entries only. From all other aspects it behaves as if there were 349 multiple FIB entries. 351 o In-band GMPLS Signaling 353 In-band GMPLS Signaling is IP based signaling on the native 354 Ethernet links encapsulated by a single hop Ethernet header. 355 Logical links that use a dedicated VID on the same physical links 356 would be considered In-band signaling. 358 o Out-of-band GMPLS Signaling is IP based signaling between 359 Ethernet switches that uses some other links other than the 360 Ethernet data plane links. Out of band signaling typically shares 361 a different fate from the data links. 363 o Contiguous Eth-LSP is an Eth-LSP that maps one to one with and 364 LSP at a domain boundary. Stitched LSP are contiguous LSPs. 366 o Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and 367 tunneled either individually or bundled with other LSPs through a 368 domain. 370 2.3.2. Acronyms 372 The following acronyms are used in this document: 374 CFM Connectivity Fault Management 375 DMAC Destination MAC Address 376 CCM Continuity Check Message 377 Eth-LSP Ethernet Label Switched Path 378 I-SIDService Idenitifier 379 LMP Link Management Protocol 380 MAC Media Access Control 381 MP2MP Multipoint to multipoint 382 NMS Network Management System 383 OAM Operations, Administration and Maintenance 384 PBB Provider Backbone Bridges [802.1ah] 385 PBB-TE Provider Backbone Bridges Traffic Engineering 386 [802.1Qay] 387 P2P Point to Point 388 P2MP Point to Multipoint 389 QoS Quality of Service 390 SMAC Source MAC Address 391 S-TAG A service TAG defined in the 802.1 Standard 392 [802.1Q] 393 TE Traffic Engineering 394 TAG An Ethernet short form for a TAG Header 395 TAG Header An extension to an Ethernet frame carrying 396 priority and other information. 397 TSpec Traffic specification 398 VID VLAN Identifier 399 VLAN Virtual LAN 401 2.4. Ethernet and MPLS similarities and differences 403 Ethernet is similar to MPLS in that there is a default payload type. 404 In MPLS the default payload is either another MPLS label or an IP 405 packet. The IP packet may carry any type of service IP carries. 406 Ethernet assumes an Ethernet frame as the default payload. The actual 407 service can be anything that Ethernet carries. 409 In MPLS pseudo wires where other types of payloads are used natively 410 the payload may be identified implicitly or explicitly by using a 411 control word removing the need for the IP header. 413 Similarly, in Ethernet the option to carry other payloads by using 414 either implicit or explicit means is being discussed. 416 Ethernet bridging is different from MPLS in that while the switching 417 decision is taken on whatever is defined as the Ethernet label, that 418 label is usually not swapped at each hop. 420 3. Framework 422 As defined in the (GMPLS) Architecture [RFC3945], the GMPLS control 423 plane can be applied to a technology by controlling the data plane 424 and switching characteristics of that technology. The architecture 425 includes a clear separation between a control plane and a data plane. 426 Control plane and data plane separation allows the GMPLS control 427 plane to remain architecturally and functionally unchanged while 428 controlling different technologies. The architecture also requires 429 IP connectivity for the control plane to exchange information, but 430 does not otherwise require an IP data plane. 432 All aspects of GMPLS, i.e., addressing, signaling, routing and link 433 management, may be applied to Ethernet switching. GMPLS can provide 434 control for traffic engineered and protected Ethernet service paths. 435 This document defines the term "Eth-LSP" to refer to Ethernet service 436 paths that are controlled via GMPLS. As is the case with all GMPLS 437 controlled services, Eth-LSPs can leverage common traffic engineering 438 attributes such as: 440 - bandwidth profile; 441 - priority level; 442 - preemption characteristics; 443 - protection/resiliency capability; 444 - routing policy, such as an explicit route; 445 - bi-directional service; 446 - end-to-end and segment protection; 447 - hierarchy 449 The bandwidth profile may be used, to set committed information rate 450 and peak information rate, and policies based on either under- 451 subscription or over-subscription. Services covered by this 452 framework MUST have a TSpec that follows the Ethernet Traffic 453 parameters defined in [ETH-TSPEC]. 455 In applying GMPLS to Ethernet, GMPLS will be extended to work with 456 the Ethernet data plane and switching functions. The definition of 457 GMPLS support for Ethernet is multi-faceted due to the different 458 forwarding/switching functions inherent in the different service 459 types discussed in Section 2.1. In general, the header fields used in 460 the forwarding/switching function, e.g. VID and DMAC, can be 461 characterized as a data plane label. In some circumstances these 462 fields will be constant along the path of the Eth-LSP, and in others 463 they may vary hop-by-hop or at certain interfaces only along the 464 path. In the case where the "labels" must be forwarded unchanged, 465 there are a few constraints on the label allocation that are similar 466 to some other technologies such as lambda labels. 468 The general characteristics of the IEEE 802.1Q [802.1Q] data plane 469 are left unchanged. The VID is used as a "filter" pointing to a 470 particular forwarding table, and if the DMAC is found in that 471 forwarding table the forwarding decision is taken based on the DMAC. 472 When forwarding using an Ethernet spanning tree, if the DMAC is not 473 found the frame is broadcast over all outgoing interfaces for which 474 that VID is defined. This valid MAC checking and broadcast supports 475 Ethernet learning. The amendment to IEEE802.1Q that is specified 476 under IEEE802.1Qay allows for turning off learning and hence this 477 broadcast mechanism. A special case is when a VID is defined for only 478 two ports on one bridge, in that case all frames with that VID 479 received over one of these ports are forward over the over port. 481 This document does not define any specific format for an Eth-LSP 482 label. Rather, it is expected that service specific documents will 483 define any signaling and routing extensions needed to support that 484 specific Ethernet service. Depending on the requirements of a 485 service, it may be necessary to define multiple GMPLS extensions, 486 e.g., label formats, switching types, and Traffic Engineering (TE) 487 routing extensions. It is expected that all such extensions will be 488 consistent with this document. It is expected that there will be no 489 case where an Eth-LSP will be signaled, or an Eth-LSP supporting 490 interface will be represented, using the L2SC switching 491 type/capability. A new switching type/capability is required to 492 avoid any potential current usage of the L2SC switching 493 type/capability in support of Ethernet. 495 For discussion purposes, we decompose the problem of applying GMPLS 496 into the functions of Routing, Signaling, Link Management and Path 497 Selection. It is possible to use some functions of GMPLS alone or in 498 partial combinations. In most cases using all functions of GMPLS 499 leads to less operational overhead than partial combinations. 501 4. GMPLS Routing and Addressing Model 503 The GMPLS Routing and Addressing Model is not modified by this 504 document. GMPLS control for Eth-LSPs uses the Routing and Addressing 505 Model described in [RFC3945]. Most notably this includes the use of 506 IP addresses to identify interfaces and LSP end-points. It also 507 includes support for both numbered and unnumbered interfaces. 509 In the case where another address family or type of identifier is 510 required to support an Ethernet service, extensions may be defined to 511 provide mapping to an IP address. Extensions to support non-IP based 512 LSP identification in signaling, i.e., replacement of the IP address 513 in the RSVP SESSION or SENDER_TSPEC objects, are not permitted under 514 this framework. 516 4.1. GMPLS Routing 518 GMPLS routing [RFC4202] is IP routing with the opaque TLV extensions 519 for the purpose of distributing GMPLS related TE (router and link) 520 information. As is always the case with GMPLS, TE information is 521 populated with TE resources coordinated with LMP or from 522 configuration if LMP is not available. The bandwidth resources of the 523 links are tracked as Eth-LSPs are set up. Interfaces supporting the 524 switching of Eth-LSPs are identified using the appropriate Interface 525 Switching Capabilities. As mentioned in Section 2, it will be 526 necessary to define one or more new Interface Switching Capabilities 527 to support Eth-LSPs. The L2SC Interface Switching Capabilities MUST 528 NOT be used to represent interfaces capable of supporting Eth-LSPs. 529 Interface Switching Capability specific TE information may be defined 530 as needed to support the requirements of a specific Ethernet 531 Switching Service Type. 533 GMPLS Routing is an optional piece but it is highly valuable in 534 maintaining topology and distributing the TE database for path 535 management and dynamic path computation. 537 4.2. Control Plane Network 539 In order for a GMPLS control plane to operate, an IP network of 540 sufficient capacity to handle the information exchange between the 541 GMPLS routing and signaling protocols is necessary. 543 One way to implement this is with an IGP that views each switch as a 544 terminated IP adjacency. In other words, IP traffic and a simple 545 routing table are available for the control plane but there is no 546 requirement for a high performance IP data plane. 548 This IP connectivity can be provided as a separate independent 549 network (out of band) or integrated with the Ethernet switches (in- 550 band). 552 5. P2P Signaling 554 GMPLS signaling, see [RFC3471], is well suited to the control of Eth- 555 LSPs and Ethernet switches. Signaling enables the ability to 556 dynamically establish a path from one ingress or egress node. The 557 signaled path may be completely static and not change for the 558 duration of its lifetime. However, signaling also has the capability 559 to dynamically adjust the path in a coordinated fashion after the 560 path has been established. The range of signaling options from static 561 to dynamic are under operator control. Standardized signaling also 562 improves multi-vendor interoperability over simple management. 564 GMPLS signaling supports the establishment and control of 565 bidirectional and unidirectional data paths. Ethernet is bi- 566 directional by nature and the CFM has been built to leverage this. 567 Prior to CFM the emulation of a physical wire and the learning 568 requirements also mandated bi-direction connections. Given this, Eth- 569 LSPs MUST always use paths that share the same routes and fates. Eth- 570 LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also 571 allows for full and partial LSP protection; see [RFC4872] and 572 [RFC4873]. 574 Note that standard GMPLS does not support different bandwidth in each 575 direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric 576 bandwidth bidirectional LSPs are required. 578 6. Link Management 580 Link discovery has been specified for Ethernet in [IEEE802.1AB]. 581 However the 802.1AB capability is an optional feature and is not 582 necessarily operating before the Link is operational it primarily 583 supports the management plane. The benefits of running link discovery 584 in large systems are significant. Link discovery may reduce 585 configuration and reduce the possibility of undetected errors in 586 configuration as well as exposing misconnections. 588 In the GMPLS context, LMP [RFC4204] has been defined to support link 589 management and discovery features. LMP also supports the creation of 590 unnumbered interfaces can be automated. If LMP is not used there is 591 an additional provisioning requirement to add GMPLS link identifiers. 592 For large-scale implementations LMP would be beneficial. LMP also has 593 Fault Management capabilities that overlap with [IEEE802.1ag] and 594 [Y.1731]. It is recommended that LMP not be used for Fault 595 management and instead the native Ethernet methods be used. 597 LMP and 802.1AB are relatively independent. The LMP capability should 598 be sufficient to remove the need for 802.1AB but 802.1 AB can be run 599 in parallel or independently if desired. Figure 2 provides possible 600 ways of using LMP, 802.1AB and 802.1ag in combination. 602 Figure 2 illustrates the functional relationship of link management 603 and OAM schemes. It is intended that LMP would use functions of 604 link property correlation but that Ethernet mechanisms for OAM such 605 as CFM, link trace etc would be used for fault management and fault 606 trace. 608 +-------------+ +-------------+ 609 | +---------+ | | +---------+ | 610 | | | | | | | |GMPLS 611 | | LMP |-|<------>|-| LMP | |Link Property 612 | | | | | | | |Correlation 613 | | (opt) | |IP | | (opt) | | 614 | | | | | | | | Bundling 615 | +---------+ | | +---------+ | 616 | +---------+ | | +---------+ | 617 | | | | | | | | 618 | | 802.1AB |-|<------>|-| 802.1AB | |P2P 619 | | (opt) | |Ethernet| | (opt) | |link identifiers 620 | | | | | | | | 621 | +---------+ | | +---------+ | 622 | +---------+ | | +---------+ | 623 | | | | | | | |End to End 624 -----|-| 802.1ag |-|<------>|-| 802.1ag |-|------- 625 | | Y.1731 | |Ethernet| | Y.1731 | |Fault Management 626 | | | | | | | |Performance 627 | | | | | | | |Management 628 | +---------+ | | +---------+ | 629 +-------------+ +-------------+ 630 Switch 1 link Switch 2 632 Figure 2: Logical Link Management Options 634 7. Path Computation and Selection 636 GMPLS does not specify a specific method for selecting paths or 637 supporting path computation. GMPLS allows for a wide ranges of 638 possibilities supported from very simple path computation to very 639 elaborate path coordination where a large number of coordinated paths 640 are required. The path computation could take the form of paths 641 being computed either on a management station with local computation 642 for rerouting or more sophisticated path computation servers. 644 Eth-LSPs may be supported using any path selection or computation 645 mechanism. As is the case with any GMPLS path selection function, and 646 common to all path selection mechanisms, the path selection process 647 should take into consideration Switching Capabilities and Encoding 648 advertised for a particular interface. Eth-LSPs may also make use of 649 the emerging path computation and selection work; see [PATH-COMP] 651 8. Multiple Domains 653 This document will support the signaling of Ethernet parameters 654 across multiple domains supporting both contiguous Eth-LSP and 655 Hierarchical Ethernet LSPs. The intention is to support the GMPLS 656 tools of hierarchy supporting Peer to Peer models, UNIs and NNIs. 658 More detail will be added to the section in a later revision. 660 9. Security Considerations 662 The architecture for GMPLS controlled Ethernet assumes that the 663 network consists of trusted devices, but does not require that the 664 ports over which a UNI is defined is trusted, nor does equipment 665 connected to these ports need to be trusted. Access to the trusted 666 domain SHALL only occur through the protocols defined in the UNI or 667 NNI or through protected management interfaces. Where GMPLS is 668 applied to the control of VLAN only, the commonly known techniques 669 for mitigation of Ethernet DOS attacks may be required on UNI ports. 671 10. IANA Considerations 673 New values are required for signaling and error codes as indicated. 674 This section will be completed in a later version. 676 11. References 678 11.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC3471] Berger, L. (editor), "Generalized MPLS Signaling 684 Functional Description", January 2003, RFC3471. 686 [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in 687 Support of Generalized MPLS", RFC 4202, October 2005 689 11.2. Informative References 691 [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection 692 Switching. 694 [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over 695 Transport - Ethernet services framework. 697 [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label 698 Switching (GMPLS) Architecture", RFC 3495. 700 [IEEE802.1AB] "IEEE Standard for Local and Metropolitan Area 701 Networks, Station and Media Access Control 702 Connectivity Discovery". 704 [IEEE802.1ag] "IEEE Draft Standard for Connectivity Fault 705 Management", work in progress. 707 [802.1ah] "IEEE standard for Provider Backbone Bridges", work in 708 progress. 710 [802.1Qay] "IEEE standard for Provider Backbone Bridge Traffic 711 Engineering", work in progress. 713 [802.1Q] "IEEE standard for Virtual Bridged Local Area Networks 714 802.1Q-2005", May 19, 2006 716 [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" 717 RFC4204, October 2005 719 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services 720 Definitions - Phase I". 722 [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet 723 Services Attributes Phase 1". 725 [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to 726 Multipoint TE LSPs", IETF RFC 4875, May 2007 728 [PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) 729 Architecture", work in progress. 731 [RFC4872] Lang et.al., "RSVP-TE Extensions in support of 732 End-to-End Generalized Multi-Protocol Label Switching 733 (GMPLS)-based Recovery ", RFC 4872, May 2007. 735 [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 736 2007. 738 [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM 739 Functions and Mechanisms for Ethernet based Networks ", 740 work in progress. 742 [GMPLS-ASYM] Berger, L. et al., "GMPLS Asymmetric Bandwidth 743 Bidirectional LSPs", work in progress. 745 [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", work 746 in progress. 748 12. Acknowledgments 750 There were many people involved in the initiation of this work prior 751 to this document. The GELS framework draft and the PBB-TE extensions 752 drafts were two drafts the helped shape and justify this work. We 753 acknowledge the work of these authors of these initial drafts: 754 Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, 755 Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, 756 Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar. 758 George Swallow contributed significantly to this document. 760 13. Author's Addresses 762 Don Fedyk 763 Nortel Networks 764 600 Technology Park Drive 765 Billerica, MA, 01821 766 Phone: +1-978-288-3041 767 Email: dwfedyk@nortel.com 769 Lou Berger 770 LabN Consulting, L.L.C. 771 Phone: +1-301-468-9228 772 Email: lberger@labn.net 774 Loa Andersson 775 Acreo, AB 776 Phone:+46 8 632 77 14 777 Email: loa@pi.se 779 14. Full Copyright Statement 781 Copyright (C) The IETF Trust (2007). 783 This document is subject to the rights, licenses and restrictions 784 contained in BCP 78, and except as set forth therein, the authors 785 retain all their rights. 787 This document and the information contained herein are provided on an 788 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 789 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 790 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 791 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 792 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 793 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 795 15. Intellectual Property 797 The IETF takes no position regarding the validity or scope of any 798 Intellectual Property Rights or other rights that might be claimed 799 to pertain to the implementation or use of the technology 800 described in this document or the extent to which any license 801 under such rights might or might not be available; nor does it 802 represent that it has made any independent effort to identify any 803 such rights. Information on the procedures with respect to rights 804 in RFC documents can be found in BCP 78 and BCP 79. 806 Copies of IPR disclosures made to the IETF Secretariat and any 807 assurances of licenses to be made available, or the result of an 808 attempt made to obtain a general license or permission for the use 809 of such proprietary rights by implementers or users of this 810 specification can be obtained from the IETF on-line IPR repository 811 at http://www.ietf.org/ipr. 813 The IETF invites any interested party to bring to its attention 814 any copyrights, patents or patent applications, or other 815 proprietary rights that may cover technology that may be required 816 to implement this standard. Please address the information to the 817 IETF at ietf-ipr@ietf.org. 819 Acknowledgement 821 Funding for the RFC Editor function is provided by the IETF 822 Administrative Support Activity (IASA). 824 Generated on: Sat Nov 10 09:25:30 EST 2007