idnits 2.17.00 (12 Aug 2021) /tmp/idnits63249/draft-fedyk-gmpls-ethernet-pbt-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1017. ** 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: ---------------------------------------------------------------------------- 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 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 (October 2006) is 5690 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) == Unused Reference: 'PWoPBT' is defined on line 942, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'CCAMP-ETHERNET' == Outdated reference: A later version (-03) exists of draft-allan-pw-o-pbt-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Don Fedyk, David Allan, Nortel 3 Internet Draft Greg Sunderwood, Bell Canada 4 Category: Standards Track Himanshu Shah, Ciena 5 Nabil Bitar, Verizon 6 Attila Takacs, Diego Caviglia, Ericsson 8 October 2006 10 GMPLS control of Ethernet 11 draft-fedyk-gmpls-ethernet-pbt-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire in March 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Carrier Grade Ethernet transport solutions require the capability of 45 flexible service provisioning and fast protection switching. 46 Currently, Ethernet is being extended in IEEE to meet the scalability 47 needs of transport networks. 49 The IETF specified GMPLS to control transport networks. To enable 50 integration of Ethernet based transport solutions the extension of 51 GMPLS control plane for Ethernet is of value. 53 This memo describes how a GMPLS control plane may be applied to 54 Provider Backbone Transport (PBT) and how GMPLS can be used to 55 configure VLAN-aware Ethernet switches in order to establish Ethernet 56 P2P and P2MP MAC switched paths and P2P/P2MP VID based trees. This 57 document assumes any standard changes to IEEE data planes will be 58 undertaken only in the IEEE. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 Table of Contents 68 1. Introduction...................................................5 69 2. Terminology....................................................5 70 3. GMPLS Control of PBT Path creation and maintenance.............6 71 3.1 Using a GMPLS Control Plane for Ethernet.....................7 72 3.2 Control Plane Network........................................7 73 3.3 Signaling....................................................8 74 3.4 Ethernet Label..............................................10 75 3.5 Ethernet Service............................................11 76 3.6 GMPLS Link Discovery........................................11 77 3.7 GMPLS Routing...............................................12 78 3.8 Path Computation............................................12 79 3.8.1 Combinations of GMPLS Features.............................12 80 3.9 Addresses, Interfaces, and Labels...........................13 81 4. Specific Procedures...........................................14 82 4.1 PT to PT connections........................................14 83 4.1.1 P2P connections with shared forwarding.....................14 84 4.1.2 Dynamic P2P symmetry with shared forwarding................15 85 4.1.3 Planned P2P symmetry.......................................15 86 4.1.4 Path Maintenance...........................................16 87 4.2 P2MP VID/DMAC Connections...................................16 88 4.2.1 Setup procedures...........................................16 89 4.2.2 Maintenance Procedures.....................................16 90 4.3 P2P/P2MP VID Trees..........................................16 91 4.3.1 Setup Procedures...........................................17 92 4.3.2 Maintenance procedures.....................................17 93 4.4 OAM MEP ID and MA ID synchronization........................17 94 4.5 Protection Paths............................................18 95 5. Error conditions..............................................18 96 5.1 Invalid VID value for configured VID/DMAC range.............18 97 5.2 Invalid VID value for configured VID range..................18 98 5.3 Invalid MAC Address.........................................18 99 5.4 Invalid ERO for Upstream Label Object.......................18 100 5.5 Invalid ERO for Suggested Label Object......................19 101 5.6 Switch is not IVL capable...................................19 102 5.7 Switch is not SVL capable...................................19 103 5.8 Invalid VID in upstream label object........................19 104 6. Deployment Scenarios..........................................19 105 7. Security Considerations.......................................19 106 8. IANA Considerations...........................................19 107 9. References....................................................19 108 9.1 Normative References........................................19 109 9.2 Informative References......................................20 110 10. Author's Address............................................21 111 11. Intellectual Property Statement.............................22 112 12. Disclaimer of Validity......................................22 113 13. Copyright Statement.........................................22 114 14. Acknowledgments.............................................22 115 A 1. Aspects of configuring Ethernet Forwarding.................24 116 A 2. Overview of configuration of VID/DMAC tuples...............27 117 A 3. Overview of configuration of VID port membership...........29 118 A 4. OAM Aspects................................................29 119 A 5. QOS Aspects................................................30 120 A 6. Resiliency Aspects.........................................30 121 A 6.1 E2E Path protection........................................30 123 1. Introduction 125 Ethernet switches are increasing in capability. As a consequence the 126 role of Ethernet is rapidly expanding in networks that were the 127 domain of other technologies such as SONET/SDH TDM and ATM. The 128 question of how Ethernet will evolve and what capabilities it can 129 offer in these areas is still under development. 131 Operators are considering the deployment of Ethernet based transport 132 solutions. The IEEE is working on amendments of VLAN-aware bridges 133 (802.1Q) to meet scalability and service provisioning needs of 134 operators. The work on 802.1ad Provider Bridges (PB) has already been 135 finalized while the specification of 802.ah Provider Backbone Bridges 136 (PBB) is expected to be ready in 2007. Parallel to the improvements 137 of bridging functionalities standardization of 802.1ag Connectivity 138 Fault Management (CFM) is also ongoing. CFM will equip bridged 139 networks with service fault management and performance monitoring 140 capabilities. In ITU-T Y.1731 work is ongoing to specify extensive 141 OAM capabilities for Ethernet based on CFM. Moreover, in G.8031 142 Ethernet protection switching is being defined based on CFM's 143 continuity check protocol. ITU-T G.8031 relies on p2p Ethernet paths 144 configuration for working and protection traffic. P2p Ethernet paths 145 are constructed using a p2p VLAN configuration between the head-end 146 and tail-end of a protection segment. Note this is only a non- 147 exhaustive list summarizing major activities pursuing Carrier Grade 148 Ethernet transport. 149 The 802.1ad Provider Bridges and 802.1ah Provider Backbone Bridges 150 are the respective amendments of the 802.1Q standard. The newly 151 introduced functionalities add a hierarchical tunneling capability to 152 Ethernet networks based on VLANs. 154 For Ethernet transport service provisioning, IEEE provides managed 155 objects that can be statically configured through Network Management 156 Systems and/or dynamically controlled through an Ethernet control 157 Plane. 159 Provider Backbone Transport (PBT) is simply the data plane of 160 Ethernet (802.1Q, 802.1ah) without an form of Spanning tree control 161 plane. This document applies to PBT and is applicable to 802.1 when 162 used for a suitable Pseudo wire service as described in this 163 document. 165 The main purpose of this document is to specify a control plane for 166 PBT that uses techniques for Ethernet. 168 2. Terminology 170 In addition to well understood GMPLS terms, this memo uses 171 terminology from IEEE 802.1 and introduces a few new terms: 173 B-MAC Backbone MAC 174 B-VID Backbone VLAN ID 175 B-VLAN Backbone VLAN 176 COS Class of Service 177 C-MAC Customer MAC 178 C-VID Customer VLAN ID 179 C-VLAN Customer VLAN 180 DMAC Destination MAC Address 181 IVL Independent VLAN Learning 182 MAC Media Access Control 183 MP2MP Multipoint to multipoint 184 PBB Provider Backbone Bridge 185 PBT Provider Backbone Transport 186 P2P Point to Point 187 P2MP Point to Multipoint 188 QOS Quality of Service 189 SMAC Source MAC Address 190 S-VID Service VLAN ID 191 SVL Shared VLAN Learning 192 VID VLAN ID 193 VLAN Virtual LAN 195 3. GMPLS Control of PBT Path creation and maintenance 197 PBT is an Ethernet connection technology, being specified in the 198 IEEE, that can be controlled by configuration of static filtering 199 enties [see Appendix A]. PBT paths are created switch by switch by 200 simple configuration of Ethernet logical ports and assignment of PBT 201 labels. We term a PBT path a form of Ethernet LSP (Eth-LSP). PBT 202 paths may be configured by command line interface on the switches or 203 coordinated from a management system. This memo proposes GMPLS as a 204 mechanism to automate PBT paths. 206 One motive for using GMPLS over simple provisioning is GMPLS 207 provides a reduction in the number of commands and an improvement in 208 the coordination of commands required to establish and maintain an 209 Eth-LSP. It also provides the capability for automation by dynamic 210 modification of parameters, on-net/off-net path computation and 211 automatic reaction to network changes without manual intervention. 212 GMPLS utilizes per connection configuration and signaling both which 213 reduce the operational overhead of establishing a path. 215 PBT uses the Ethernet data plane in its native form. When 216 configuring a PBT path with GMPLS, the DMAC and VID are carried in a 217 generalized label and are assigned hop by hop and it is invariant 218 within a domain. PBT Eth-LSPs are by nature uni-directional since 219 the DMAC must be inherently different in the two directions. The VID 220 may be the same or different in each direction as it is only used to 221 used to identify the path co-jointly with the DMAC. To be consistent 222 with GMPLS terminology, paths are created first as an explicit route 223 object (ERO) and data plane labels are assigned from the available 224 label pool at the destination switches. Each PBT label is a domain 225 wide unique label, the VID/DMAC, for each direction. 227 Several attributes may be associated with an Eth-LSP, including: 228 - bandwidth requirements of the path. This can be used, for example, 229 to request a fixed bandwidth path, where the committed information 230 rate and peak information rate. 231 - priority level; 232 - preemption characteristics; 233 - protection/resiliency requirements; 234 - routing policy, such as an explicit route; 235 - policing requirements 237 Note GMPLS currently does not support unsymmetrical attributes in 238 each direction for a bidirectional LSP. GMPLS control of PBT should 239 allow these parmeters to be specified independently. 241 In addition to the above policies based on either under-subscription 242 or over-subscription can be supported. 244 3.1 Using a GMPLS Control Plane for Ethernet 246 GMPLS [RFC3495] has been adapted to the control of optical switches 247 for the purpose of managing optical paths. GMPLS signaling is well 248 suited to setup paths with labels but it does require an IP control 249 plane and IP connectivity. 251 In many Ethernet deployment situations, the addition of a complete 252 GMPLS control plane may be excessive for the switch technology or 253 the network application. For this reason we consider partial 254 application of GMPLS either complete functionality applied to a 255 subset of the switches and/or partial functionality applied to some 256 or all switches. For discussion purposes, we decompose the problem 257 of applying GMPLS into the functions of Signaling, Routing, Link 258 discovery and Path management. We can use some functions of GMPLS 259 alone or in partial combinations. In most cases using all functions 260 of GMPLS is less of an operational overhead than any partial 261 combinations. Also, using only some components of GMPLS can lead to 262 more provisioned overhead for some objects than a purely static 263 system (see "Combinations of GMPLS Features"). 265 3.2 Control Plane Network 267 In order to have a GMPLS control plane, an IP control plane 268 consisting of an IGP with TE extension needs to be established. This 269 IGP views each hop as a terminated IP adjacency and should not be 270 interpreted as a distinct routed subnet for the purpose of carrying 271 IP bearer traffic. In other words IP is the control plane but the 272 forwarding plane is not IP. 274 This IP control plane can be provided as a separate independent 275 network (out of band) or integrated with the Ethernet switches. 277 If the IP control plane is a separate network, it may be provided as 278 a Layer 2 connected LAN where the Ethernet switches are connected 279 via a bridged network or HUB. It may also be provided by an 280 external network that provides IP connectivity but in this case, the 281 control topology of the GMPLS/Ethernet switches may not be the same 282 topology as the physical data plane network. 284 If the IP control plane is integrated with the switches it may be 285 provided by a bridged VLAN that uses the Data bearing channels of 286 the network between adjacent nodes. This ties the fate of the 287 controlled paths and the IP control plane links, which is not unlike 288 the situation with MPLS networks or even some GMPLS optical 289 networks. 291 3.3 Signaling 293 GMPLS signaling is well suited to the set up of PBT on Ethernet 294 switches. GMPLS signaling uses either numbered or unnumbered links 295 where the link is either explicitly IP addressed or associated with 296 a switch loopback address. If LMP [RFC4204] is used, the creation of 297 these unnumbered interfaces can be automated. If LMP is not used 298 there is an additional provisioning requirement to add GMPLS link 299 identifiers. For large-scale implementations LMP would be 300 beneficial. As mentioned earlier, the primary benefit of signaling 301 is the control of a path from an endpoint. GMPLS can be used to 302 create bi-directional or unidirectional paths, bi-directional paths 303 being the preferred mode of operation for numerous reasons (OAM 304 consistency etc.). In this document we only consider bidirectional 305 paths that share the same route/resources both for P2P and P2MP 306 services. 308 Signaling enables the ability to dynamically establish a path and to 309 adjust the path in a coordinated fashion after the path has been 310 established. Signaling also improves multi-vendor interoperability 311 over simple management since the signaling is standard and handles a 312 number of dynamic functions. This allows the network to adapt to 313 changing conditions or failures with a single mechanism. Signaling 314 can be used for pure static configured paths as well. 316 To use GMPLS RSVP-TE signaling a few modifications are required. A 317 new label is defined that contains the VID/DMAC tuple. On the 318 initiating and terminating nodes, a function administers the VIDs 319 associated with the SMAC and DMAC respectively. PBT is designed to 320 be bidirectional and symmetric just like ethernet. Therefore in PBT 321 the packet SMAC is the same as the DMAC used for the associated 322 reverse PBT path and the DMAC is the same as the SMAC for the 323 reverse PBT path. 325 To initiate a bi-directional VID/DMAC P2P or P2MP path, the 326 initiator of the PATH message uses procedures outlined in [GMPLS- 327 SIGNALING] possibly augmented with [MPLS-P2MP], it: 329 1) Sets the LSP encoding type to Ethernet. 331 2) Sets the LSP switching type to MAC [IANA to define]. 333 3) Sets the GPID to Unknown (1) or Ethernet Multiplexed [IANA to 334 define]. 336 4) Sets the UPSTREAM_LABEL to the VID/SMAC tuple where the VID is 337 administered from the configured VID/DMAC range. Downstream switches 338 must use the SUGGESTED LABEL or return a path Error condition 339 indicating why the label could not be used. Alternatively, if the 340 optional LABEL SET object is implemented, the upstream switches can 341 use this to specify the required label. 343 At intermediate switches the UPSTREAM_LABEL object and value is 344 passed unmodified. The VID/SMAC tuple is used to create a static 345 forwarding entry in the Filtering Database of bridges at each hop 346 for the upstream direction. The port derived form the ERO and the 347 VID and DMAC included in the label constitute the static entry. 349 One capability of a connectionless Ethernet data plane is to reuse 350 destination forwarding entries for packets from any source within a 351 VLAN to a destination. When setting up point to point PBT 352 connections for multiple sources sharing a common destination this 353 capability can be preserved provided certain requirements are met. 354 We refer to this capability as Shared Forwarding. Shared forwarding 355 happens opportunistically when conditions are met as a local 356 decision by label allocation at each end for the traffic to that 357 end. To achieve shared forwarding, a Path computation engine should 358 ensure the ERO is consistent with an existing path for the shared 359 segments. If a path satisfies the consistency check, the upstream 360 end of the signaling may chose to share an existing DMAC for the 361 upstream traffic with an existing Eth-LSP. The consistency that the 362 Eth-LSP share the same port and the paths of the Eth-LSP share one 363 or more hops consecutively but once the paths diverge they must 364 remain divergent. If no existing path has this behavior the path 365 will be created unshared either by using another VID or another DMAC 366 or both. In other words shared forwarding happens when paths share 367 segments from the source and when the Upstream label is chosen to be 368 the same as the existing path. Similarly for the downstream path 369 shared forwarding happens when, an existing path that shares 370 segments with the new paths ERO, viewed from the destination switch 371 and when the downstream label is chosen to be the same and the 372 existing path. 373 In this manner shared forwarding is a function that is controlled 374 primarily by path calculation and in combination with the local 375 label allocation at the end points of the path. 377 At the destination, a VID is allocated in the local MAC range for 378 the DMAC and the VID/DMAC tuple is passed in the GENERALIZED_LABEL 379 in the RESV message. As with the UPSTREAM_LABEL, intermediate 380 switches use the GENERALIZED_LABEL object and pass it on unchanged, 381 upstream. The VID/DMAC tuple is installed in the forwarding table 382 at each hop. This creates a bi-directional path as the PATH and RESV 383 messages follow the same path. 385 To initiate a P2MP VID path the initiator of the PATH message uses 386 procedures outlined in [GMPLS-SIGNALING] and [MPLS-P2MP]. A P2MP 387 tree consists of a VID tree in the forward direction (from root to 388 leaves) and a set of P2P paths running on identical paths from Tree 389 to root in the reverse direction. VID labels with common MAC 390 addresses are allocated in the forward direction and a single 391 VID/DMAC label in the reverse direction: 393 1) Sets the LSP encoding type to Ethernet. 395 2) Sets the LSP switching type to L2SC. 397 3) Sets the GPID to unknown. 399 4) Set the technology specific information in the TSPEC to indicate 400 domain-wide label. 402 5) Sets the UPSTREAM LABEL specified as a single VID/DMAC from the 403 configured VID range. 405 6) VID translation may optionally be permitted on a local basis 406 between two switches by a downstream switch replying with a VID/DMAC 407 other than the SUGGESTED LABEL. The upstream switch then sets a VID 408 translation on the port associated with the label to allow VID 409 translation. This flexibility allows the tree to be constructed with 410 out having to worry about colliding with another tree using the same 411 VID. 413 3.4 Ethernet Label 415 The Ethernet label is a new generalized label with a suggested 416 format of: 418 0 1 2 3 419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 |0 0 0 0| VLAN ID | MAC (highest 2 bytes) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | MAC Address | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 The semantics of the new label type for a non-zero MAC address is 427 that that the label is passed unchanged. This label is a domain wide 428 label. This has similarity to the way in which a wavelength label 429 is handled at an intermediate switch that cannot perform wavelength 430 conversion, and is described in [GMPLS-RSVP]. 432 These domain wide labels are allocated to switches that control the 433 assignment of labels. This label space does not have to be globally 434 unique because the labels are only valid within a single provider. 435 When using configuration, a tool would have to perform a consistency 436 check to make sure that label terminations were unique. When using 437 GMPLS signaling it is assumed a unique pool of labels would be 438 assigned to each switch. The DMAC addresses are domain wide unique 439 and so is the combination of VID/DMAC. Should an error occur and a 440 duplicate label be assigned to one or more switches GMPLS signaling 441 procedures would allow the first assignment of the label and prevent 442 duplicate label from colliding. If a collision occurs an alarm would 443 be generated. In fact some of these procedures have been defined in 444 GMPLS control of photonic networks where a lambda may exist as a 445 form of domain wide label. 447 3.5 Ethernet Service 449 Ethernet Switched Paths that are setup either by configuration or 450 signaling can be used to provide an Ethernet service to customers of 451 the Ethernet network. The Metro Ethernet Forum has defined some 452 services in MEF.6 (e.g., Ethernet Private Line), and these are also 453 aligned with ITU-T G.8011-x Recommendations. Of particular interest 454 are the bandwidth profile parameters in MEF.10 and whose associated 455 bandwidth profile algorithm are based on [RFC4115][RFC3270]. 456 Consideration should be given to supporting these in any signaling 457 extensions for Ethernet LSPs. This will be addressed in a future 458 version of this specification. 460 3.6 GMPLS Link Discovery 462 Link discovery is one of the building blocks of GMPLS. It is also a 463 capability that has been specified for Ethernet in IEEE 802.1AB. 464 Link discovery is optional but the benefits of running link 465 discovery in large systems are significant. Link discovery reduces 466 configuration and the possibility of errors in configuration as well 467 as exposing misconnections. It is likely that a standard Ethernet 468 implementation would have 802.1AB functions. A recommendation is 469 that standard 802.1AB could be run with an extension to feed 470 information into an LMP [RFC4204] information model. LMP is a 471 superset capability while 802.1AB has certain capabilities just for 472 Ethernet. See Figure 3. 474 +---------+ +---------+ 475 | | | | 476 | LMP | ----------| LMP | 477 | +-------+ IP (opt) +-------+ | 478 | |802.1AB| ----------|802.1AB| | 479 +-+-------+ Ethernet +-------+-+ 481 Figure 3 Link Discovery Hierarchy 483 3.7 GMPLS Routing 485 GMPLS routing [GMPLS-ROUTING] is IP routing with the TLV extensions 486 for the purpose of carrying around GMPLS TE information. The TE 487 information is populated with TE resources from coordinated with LMP 488 or from configuration if LMP is not available. The bandwidth 489 resources of the links are tracked as Eth-LSPs are set up. GMPLS 490 Routing is an optional piece but it is highly valuable in 491 maintaining topology and distributing the TE database for path 492 management and dynamic path computation. 494 3.8 Path Computation 496 There has been a lot of recent activity in the area of path 497 computation [PATH-COMP]. Originally MPLS path computation was 498 performed locally in a TE database on a router. While this is non- 499 optimal for situations where bandwidth is highly managed, it was 500 acceptable when a few paths are required in a primarily 501 connectionless environment; if a large number of coordinated paths 502 are required, it is advantageous to have a more sophisticated path 503 computation engine capable of optimizing the path routing of a sub 504 network. The path computation could take the form of paths being 505 computed either on a management station with local computation for 506 rerouting or more sophisticated path computation servers. 508 3.8.1 Combinations of GMPLS Features 510 The combinations of LMP, Routing, Signaling and Path computation can 511 be all supported on a switch or a subset of GMPLS features can be 512 supported. 514 Signaling is the minimal function that might be supported on a small 515 switch. The ability to process Signaling messages with an ERO may be 516 all that is desired on an end point. In this case the path 517 computation would be performed off network. 519 Routing for GMPLS is the next important function since it provides 520 the forwarding of signaling functions and transport of TE 521 information. There is no requirement to provide full IP routing for 522 data traffic, only hop by hop routing for the control plane. However 523 it is possible to design switches without routing that could proxy 524 their routing to other larger switches. In the proxied case, there 525 would be little difference in the routing database but the small 526 switches would not have to perform routing operations. The 527 information for the proxied routing might be configured or it might 528 be data filled by an automated procedure. No new protocols are 529 envisioned for the case where routing is proxied. 531 LMP is optional. The primary benefit of LMP in addition to 802.1AB 532 is LMP's capability to optimize routing information for the purpose 533 of link bundling on large switches. LMP has the capability to 534 compress the information required to represent a large number of 535 parallel resources automatically and reduce the amount of 536 configuration. 538 3.9 Addresses, Interfaces, and Labels 540 This specification uses an addressing scheme and a label space for 541 the ingress/egress connection; the hierarchical GMPLS Switch 542 Address/Port ID and the Ethernet VID/DMAC tuple or VID/Multicast MAC 543 as a label space. 545 GMPLS Switch Address 546 | 547 V N=named port 548 +----+ +-----+ 549 | | label=VID/DMAC | | 550 | PB | label=VID/MMAC | | 551 -----N N----------------------------N PBB N---------- 552 | | |(MAC)| \ 553 | | / | Customer 554 +----+ /+-----+ Facing 555 PBT Transit Provider MAC PBT edge Ports 556 Switch Switch 558 Figure 4 Ethernet/GMPLS Addressing & Label Space 560 Depending on how the service is defined and set up one or more of 561 these identifiers may be used for actual setup. An Ethernet port name 562 is common to both configured VID/DMAC, configured VID and bridging 563 modes of operation. One implication of this is that a port index and 564 a MAC address of a port on the switch may be effectively 565 interchangeable for signaling purposes. 567 For a GMPLS based system, the GMPLS Switch Address/logical port is 568 the logical signaling identifier for the control plane via which 569 Ethernet layer label bindings are solicited. In order to create a 570 point to point path an association must be made between the ingress 571 and egress node. But the actual label distributed via signaling and 572 instantiated in the switch forwarding tables identifies the upstream 573 and downstream egress VID/DMAC of the PBT tunnel (see Figure 4). This 574 label is typically an internal provider hidden domain wide label that 575 is out of the locally administered label space. 577 GMPLS uses identifiers in the form of 32 bit numbers which are in the 578 IP address notation but these are not IP addresses. An IP routing 579 control plane for the propagation of TE information may be supported. 580 The provider MAC port addresses are exchanged by the LLDP and by LMP 581 if supported. However these identifiers are merely for link control 582 and legacy Ethernet support and have local link scope. Actual label 583 assignment is performed by the signaling initiator and terminator. 585 A particular port on a provider network switch would have: 586 - A MAC 587 - A 32 bit IPv4 Switch address or 128 bit IPv6 address plus 32 bit 588 port Identifier 589 - One (or more) Mnemonic String Identifiers 591 This multiple naming convention leaves the issue of resolving the set 592 given one of the port identifiers. On a particular node, mapping is 593 relatively straightforward. The preferred solution to this is to use 594 the GMPLS IP switch address for signaling resolution. In so doing, 595 the problem of setting up a path is reduced to figuring out what 596 switch supports an egress MAC address and then finding the 597 corresponding GMPLS IP switch address and performing all signaling 598 and routing with respect to the GMPLS switch address. 600 There are several options to achieve this: 601 - Provisioning 602 - Auto discovery protocols that carry MAC address 603 - Augmenting Routing TE with MAC Addresses 604 - Name Servers with identifier/address registration 606 This will be clarified in a subsequent version of this document. 608 4. Specific Procedures 610 4.1 PT to PT connections 612 The Data Plane for Ethernet has three key fields: VID, DMAC and SMAC. 613 A connection instance is uniquely identified by the DMAC, the VID and 614 the SMAC for the purpose of the provider network terminations. The 615 VID and DMAC tuple identifies the forwarding multiplex at transit 616 switches and a simple degenerate form of the multiplex is P2P (only 617 one VID/DMAC/SMAC connection uses the VID/DMAC tuple). 619 This results in unique labels end to end. The data streams may merge, 620 the forwarding entries may be shared but the headers are still unique 621 allowing the connection to be de-multiplexed downstream. 623 4.1.1 P2P connections with shared forwarding 625 The VID/DMAC can be considered to be a shared forwarding identifier 626 or label for a multiplex consisting of some number of P2P connections 627 distinctly identified by the MAC VID/DMAC/SMAC tuple. The reason for 628 using a shared forwarding entry is it reuses existing labels and 629 forwarding hardware. In some ways this is analogous to an LDP label 630 merge but in the shared forwarding case the path control only the 631 forwarding entry is reused. 633 VLAN tagged Ethernet packets include priority marking. Priority bits 634 can be used to indicate class of Service (COS) and drop priority. 635 Thus, traffic from multiple COSs could be multiplexed on the same ESP 636 (i.e., similar to E-LSPs) and queuing and drop decisions are made 637 based on the p-bits. This means that the queue selection can be done 638 based on a per flow (i.e., ESP + priority) basis and is decoupled 639 from the actual steering of the packet at any given node. 641 A switch terminating an ESP will frequently have more than one 642 suitable candidate path and it may choose to share a forwarding 643 entry.(common VID/DMAC , unique SMAC). It is a local decision of how 644 this is performed but the best choice is a path that maximizes the 645 shared forwarding. 647 The concept of bandwidth management still applies equally well with 648 shared forwarding. As an example consider a PBT edge switch that 649 terminates an Ethernet LSP with the following attributes: bandwidth 650 B1, DMAC D, SMAC S1, VID V. A request to establish an additional 651 Ethernet LSP with attributes (bandwidth B2, DMAC D, SMAC S2, VID V) 652 can be accepted provided there is sufficient link capacity remaining. 654 4.1.2 Dynamic P2P symmetry with shared forwarding 656 Similar to how a destination switch may select a VID/DMAC from the 657 set of existing shared forwarding multiplexes rooted at the 658 destination node, the originating switch may also do so for the 659 reverse path. Once the initial ERO has been computed and the set of 660 existing Ethernet LSPs that include the target DMAC have been pruned, 661 the originating switch may select the optimal (by whatever criteria) 662 existing shared forwarding multiplex for the new destination to merge 663 with and offer its own VID/DMAC tuple for itself as a destination. 664 This is identified via use of the UPSTREAM LABEL object. 666 4.1.3 Planned P2P symmetry 668 Normally the originating switch will not have knowledge of the set of 669 shared forwarding paths rooted on the destination node. 671 Use of a Path Computation Server or other planning style of tool with 672 more complete knowledge of the network configuration may wish to 673 impose pre-selection of shared forwarding multiplexes to use for both 674 directions. In this scenario the originating switch uses the 675 SUGGESTED LABEL and UPSTREAM LABEL objects to indicate complete 676 selection of the shared forwarding multiplexes at both ends. This may 677 also result in the establishment of a new VID/DMAC path as the 678 SUGGESTED LABEL object may legitimately refer to a path that does not 679 yet exist. 681 4.1.4 Path Maintenance 683 Make before break procedures can be employed to modify the 684 characteristics of a P2P Ethernet LSP. As described in [RFC3209], 685 the LSP ID in the sender template is updated as the new path is 686 signaled. The procedures (including those for shared forwarding) are 687 identical to those employed in establishing a new LSP, with the 688 extended tunnel ID in the signaling exchange ensuring that double 689 booking of the associated resources does not occur. 691 Where individual paths in a protection group are modified, signaling 692 procedures may be combined with Protection Switching (PS) 693 coordination to administratively force PS switching operations such 694 that modifications are only ever performed on the protection path. 696 4.2 P2MP VID/DMAC Connections 698 4.2.1 Setup procedures 700 The group DMAC is administered from a central pool of multicast 701 addresses and the VLAN selected from the configured VID/DMAC range. 702 The P2MP tree is constructed via incremental addition of leaves to 703 the tree in signaling exchange where the root is the originating 704 switch (as per (MPLS-P2MP). The multicast VID/DMAC are encoded in the 705 suggested label object using the Ethernet label encoding. 707 Where a return path is required the unicast MAC corresponding to the 708 originating interface and a VID selected from the configured VID/DMAC 709 range is encoded as an Ethernet label in the upstream label object. 711 4.2.2 Maintenance Procedures 713 Maintenance and modification to a P2MP tree can be achieved by a 714 number of means. The preferred technique being to modify existing 715 VLAN configuration vs. assignment of a new label and completely 716 constructing a new tree. 718 Make before break on a live tree reusing existing label assignments 719 requires a 1:1 or 1+1 construct. The protection switch state of the 720 traffic is forced on the working tree and locked (PS not allowed) 721 while the backup tree is modified. Explicit path tear of leaves to 722 be modified is required to ensure no loops are left behind as 723 artifacts of tree modification. Once modifications are complete, a 724 forced switch to the backup tree occurs and the original tree may be 725 similarly modified. This also suggests that 1+1 or 1:1 resilience 726 can be achieved for P2MP trees for any single failure (switch on any 727 failure and use restoration techniques to repair the failed tree). 729 4.3 P2P/P2MP VID Trees 730 4.3.1 Setup Procedures 732 The VID is administered from the central pool of VLAN IDs 733 corresponding to the configured VID range. The P2MP VID tree is 734 constructed via incremental addition of leaves to the tree in 735 signaling exchange where the root is the originating switch as per 736 [MPLS-P2MP]. 738 Where (*,*) connectivity is to be configured a single VID is employed 739 and encoded as an Ethernet label in the suggested label object with 740 MAC address set to zero. 742 Where communication is to be constrained to root to leaves and leaves 743 to root only, asymmetrical VID configuration is used with the 744 suggested label object encoding the root to leaf VID and the upstream 745 label object encoding the leaf to root VID. 747 4.3.2 Maintenance procedures 749 Maintenance and modification to a P2P or P2MP VID tree can be 750 achieved by a number of means. The preferred technique being to move 751 traffic off the tree, modify the tree and then shift traffic back to 752 the tree. This ensures that there are no transient loops in the tree 753 that are artifacts of interactions of the GMPLS control plane, soft 754 state and the Ethernet data plane. 756 Make before break on a live tree requires a 1:1 or 1+1 construct. 757 The protection switch state of the traffic is forced on the working 758 tree and locked (PS not allowed) while the backup tree is modified. 759 Explicit path tear of leaves to be modified is required to ensure no 760 loops are left behind as artifacts of tree modification. Once 761 modifications are complete, a forced switch to the backup tree 762 occurs and the original tree may be similarly modified. This also 763 suggests that 1+1 or 1:1 resilience can be achieved for P2MP trees 764 for any single failure (switch on any failure and use restoration 765 techniques to repair the failed tree). 767 4.4 OAM MEP ID and MA ID synchronization 769 The Maintenance end point IDs (MEP IDs) and maintenance association 770 IDs for the switched path endpoints can be synchronized using the 771 ETH-MCC (maintenance communication channel) transaction set once the 772 switched path has been established. 774 MEPs are located at the endpoints of the Ethernet LSP. Typical 775 configuration associated with a MEP is Maintenance Domain Name, 776 Short Maintenance Association Name, and MA Level, MEP ID, and CCM 777 transmission rate (when ETH-CC functionality is desired). As part of 778 the synchronization, it is verified that the Maintenance Domain 779 Name, Short Maintenance Association Name, MA Level, and CCM 780 transmission rate are the same. It is also determined that MEP IDs 781 are unique for each MEP. 783 Server MEPs can be considered at the intermediate points of the PBT 784 network. Upon network failures (e.g. physical link failures), the 785 Server MEPs can initiate the unicast AIS frames for each Ethernet 786 LSP end-point that is present in the forwarding table. The only 787 configuration required at the Server MEPs is the MA Level which 788 should be the same as the MA Level configured at the Ethernet LSP 789 MEPs. 791 Besides the unicast CCM and AIS functionality, the PBT MEPs can also 792 offer the LBM/LBR and LMM/LMR functionalities for on-demand 793 connectivity verification and loss measurement purposes. 795 4.5 Protection Paths 797 When protection is used for path recovery it is required to 798 associate the working and protection paths into a protection group. 799 This is achieved as defined in [RECOVERY_SIG] using the ASSOCIATION 800 and PROTECTION objects. Protection may be used for P2P VID/DMAC, 801 P2MP VID/DMAC and P2P/P2MP VID configured modes of operation. The 802 'P' bit in the protection object indicates the role (working or 803 protection) of the LSP currently being signaled. 805 If the initiating switch wishes to use G.8031 [G-8031] data plane 806 protection switching coordination (vs. control plane notifications), 807 it sets the N bit to 1 in the protection object. This must be 808 consistently applied for all paths associated as a protection group. 810 If the terminating switch does not support G.8031, the error 811 "Admission Control Failure/Unsupported Notification Type" is used. 813 5. Error conditions 815 The following errors have been identified as being unique to these 816 procedures and in addition to those already defined. This will be 817 addressed in a proper IANA considerations section in a future 818 version of the document: 820 5.1 Invalid VID value for configured VID/DMAC range 822 The originator of the error is not configured to use the VID value 823 in conjunction with GMPLS signaling of VID/DMAC tuples. This may be 824 any switch along the path. 826 5.2 Invalid VID value for configured VID range 828 5.3 Invalid MAC Address 830 The MAC address is out of a reserved range that cannot be used by 831 then node which is processing the address. 833 5.4 Invalid ERO for Upstream Label Object 834 The ERO offered has discontinuities with the identified VID/DMAC 835 path in the UPSTREAM LABEL object. 837 5.5 Invalid ERO for Suggested Label Object 839 The ERO offered has discontinuities with the identified VID/DMAC 840 path in the SUGGESTED LABEL object. 842 5.6 Switch is not IVL capable 844 This error may arise only in P2MP VID Tree allocation. 846 5.7 Switch is not SVL capable 848 This error may arise only in P2MP VID Tree allocation. 850 5.8 Invalid VID in upstream label object 852 The VID in the upstream label object for the "asymmetrical VID" 853 P2MP tree did not correspond to the VID used in previous 854 transactions. 856 6. Deployment Scenarios 858 This technique of GMPLS controlled Ethernet switching is applicable 859 to all deployment scenarios considered by the design team [CCAMP- 860 ETHERNET]. 862 7. Security Considerations 864 The architecture assumes that the GMPLS controlled Ethernet subnet 865 consists of trusted devices and that the UNI ports to the domain are 866 untrusted. Care is required to ensure untrusted access to the trusted 867 domain does not occur. Where GMPLS is applied to the control of VLAN 868 only, the commonly known techniques for mitigation of Ethernet DOS 869 attacks may be required on UNI ports. 871 8. IANA Considerations 873 New values are required for signaling and error codes as indicated. 874 This section will be completed in a later version. 876 9. References 878 9.1 Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, March 1997. 883 [CCAMP-ETHERNET] Papadimitriou, D. et.al, "A Framework for 884 Generalized MPLS (GMPLS) Ethernet", internet draft, draft- 885 papadimitriou-ccamp-gmpls-ethernet-framework-00.txt , June 2005 887 [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS -Signaling 888 Functional Description", January 2003, RFC3471. 890 [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in 891 Support of Generalized MPLS", RFC 4202, October 2005 893 [GMPLS-RSVP] Berger, L. et.al., "Generalized Multi-Protocol Label 894 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 895 Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003. 897 9.2 Informative References 899 [RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate, 900 Three-Color Marker with Efficient Handling of in-Profile Traffic", 901 IETF RFC 4115, July 2005 903 [G-8031] ITU-T Draft Recommendation G.8031, Ethernet Protection 904 Switching. 906 [RFC3495] E. Mannie, Ed., "Generalized Multi-Protocol Label 907 Switching (GMPLS) Architecture", RFC 3495. 909 [IEEE 802.1ab] "IEEE Draft Standard for Local and Metropolitan Area 910 Networks, Station and Media Access Control Connectivity 911 Discovery". 913 [IEEE 802.1ag] "IEEE standard for Connectivity Fault Management", 914 work in progress. 916 [IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", work in 917 progress. 919 [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, 920 October 2005 922 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services 923 Definitions - Phase I". 925 [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services 926 Attributes Phase 1". 928 [RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching 929 (MPLS) Support of Differentiated Services" IETF RFC 3270, May 930 2002. 932 [MPLS-P2MP] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to 933 Multipoint TE LSPs", work in progress. 935 [MYERS] Myers et.al. "Rethinking the service model, scaling Ethernet 936 to a million nodes", http://100x100network.org/papers/myers- 937 hotnets2004.pdf. 939 [PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) 940 Architecture", work in progress. 942 [PWoPBT] Allan et.al., "Pseudo Wires over Provider Backbone 943 Transport", draft-allan-pw-o-pbt-01.txt, work in progress. 945 [RFC3985] Bryant, S., Pate, P. et al., "Pseudo Wire Emulation Edge- 946 to Edge (PWE3) Architecture", IETF RFC 3985, March 2005. 948 [RECOVERY_SIG] Lang et.al., "RSVP-TE Extensions in support of End- 949 to-End Generalized Multi-Protocol Label Switching (GMPLS)-based 950 Recovery ", work in progress. 952 [RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP 953 Tunnels, IETF RFC 3209, December 2001. 955 [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions 956 and Mechanisms for Ethernet based Networks ", work in progress. 958 10. Author's Address 960 Don Fedyk 961 Nortel Networks 962 600 Technology Park Drive Phone: +1-978-288-3041 963 Billerica, MA, 01821 Email: dwfedyk@nortel.com 965 David Allan 966 Nortel Networks Phone: +1-613-763-6362 967 3500 Carling Ave. Email: dallan@nortel.com 968 Ottawa, Ontario, CANADA 970 Greg Sunderwood 971 Bell Canada Phone: +1-604-648-7770 972 Suite 1500, Email: greg.sunderwood@gt.ca 973 1066 West Hastings Street 974 Vancouver, BC, CANADA 975 V6E 2X1 977 Himanshu Shah 978 Ciena Phone: 978-489-2196 979 35 Nagog Park, Email: hshah@ciena.com 980 Acton, MA 01720 982 Nabil Bitar Phone: (781) 466-2161 983 Verizon, Email: nabil.n.bitar@verizon.com 984 40 Sylvan Rd., 985 Waltham, MA 02451 986 Attila Takacs 987 Ericsson 988 1. Laborc u. 989 Budapest, HUNGARY 1037 Email: attila.takacs@ericsson.com 991 Diego Caviglia 992 Ericsson 993 Email: diego.caviglia@ericsson.com 995 11. Intellectual Property Statement 997 The IETF takes no position regarding the validity or scope of any 998 Intellectual Property Rights or other rights that might be claimed to 999 pertain to the implementation or use of the technology described in 1000 this document or the extent to which any license under such rights 1001 might or might not be available; nor does it represent that it has 1002 made any independent effort to identify any such rights. Information 1003 on the procedures with respect to rights in RFC documents can be 1004 found in BCP 78 and BCP 79. 1006 Copies of IPR disclosures made to the IETF Secretariat and any 1007 assurances of licenses to be made available, or the result of an 1008 attempt made to obtain a general license or permission for the use of 1009 such proprietary rights by implementers or users of this 1010 specification can be obtained from the IETF on-line IPR repository at 1011 http://www.ietf.org/ipr. 1013 The IETF invites any interested party to bring to its attention any 1014 copyrights, patents or patent applications, or other proprietary 1015 rights that may cover technology that may be required to implement 1016 this standard. Please address the information to the IETF at 1017 ietf-ipr@ietf.org. 1019 12. Disclaimer of Validity 1021 This document and the information contained herein are provided on an 1022 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1023 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1024 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1025 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1026 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1029 13. Copyright Statement 1031 Copyright (C) The Internet Society (2006). This document is subject 1032 to the rights, licenses and restrictions contained in BCP 78, and 1033 except as set forth therein, the authors retain all their rights. 1035 14. Acknowledgments 1036 The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen 1037 Shew and Sandra Ballarte for their extensive contributions to this 1038 document. 1040 A 1. Aspects of configuring Ethernet Forwarding 1042 Ethernet as specified today is a complete system consisting of a 1043 data plane and a number of control plane functions. Spanning tree, 1044 data plane flooding and MAC learning combine to populate forwarding 1045 tables and produce resilient any-to-any behavior in a bridged 1046 network. 1048 Ethernet consists of a very simple and reliable data plane that has 1049 been optimized and mass produced. By simply disabling some Ethernet 1050 control plane functionality, it is possible to employ alternative 1051 control planes and obtain different forwarding behaviors. 1053 Customer Provider Provider 1054 Bridge/ Bridge Backbone 1055 Bridge 1057 C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID 1058 S-VID-----------802.1ad------------S-VID 1059 B-MAC---802.1ah---B-MAC 1060 B-VID---802.1ah---B-VID 1062 Figure 1 802.1 MAC/VLAN Hierarchy 1064 Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 1065 are defining a separation of Ethernet functions permitting an 1066 increasing degree of provider control. The result is that the 1067 Ethernet service to the customer appears the same, yet the provider 1068 components and behaviors have become decoupled from the customer 1069 presentation and the provider has gained control of all VID/DMAC 1070 endpoints. 1072 One example of this is the 802.1ah work in hierarchical bridging 1073 whereby customer Ethernet frames are fully encapsulated into a 1074 provider Ethernet frame, isolating the customer VID/DMAC space from 1075 the provider VID/DMAC space. Another example would be the direct 1076 transport of pseudo wires PWs ["Dry Martini" or PW over layer 2] 1077 where the Ethernet network fulfills the role of the PSN in the PWE 1078 architecture. In both cases the behavior of the provider's network 1079 is as per 802.1Q. 1081 The Ethernet data plane provides protocol multiplexing via the ether 1082 type field which allows encapsulation of different protocols 1083 supporting various applications. More recently, the Carrier Ethernet 1084 effort has created provider and customer separation that enables 1085 another level of multiplexing. This in effect creates provider MAC 1086 endpoints in the Ethernet sub-network controlled by the provider. In 1087 this document we concentrate on the provider solutions and therefore 1088 subsequent references to VLAN, VID and MAC refer to those under 1089 provider control, be it in the backbone layer of 802.1ah or the PSN 1090 layer of "Dry Martini". Also in the case where the Customer service 1091 is Ethernet, the Customer Ethernet service is the same native 1092 Ethernet service with functions such as bridging, learning and 1093 spanning trees all functioning over the provider infrastructure. 1095 With the provider in exclusive control of their Ethernet sub-network 1096 and all customer specific state pushed to the edges of that sub- 1097 network, the ability of the provider to exploit latent Ethernet 1098 behavior is facilitated. One key capability sought is to overcome 1099 limitations, such as single spanning tree path for all traffic 1100 within a VLAN, imposed by bridging (see [MYERS] for a discussion). 1102 Bridging offers a simple solution for any-to-any connectivity within 1103 a VLAN partition via the Spanning tree, flooding and MAC learning. 1104 Spanning tree provides some unnecessary capabilities for point to 1105 point services and since the Spanning tree must interconnect all 1106 MACs with the same VLAN IDs (VIDs) it consumes a scarce resource 1107 (VIDs). In this document we present that it is easier to modify 1108 Ethernet to scale engineered P2P services and this is the approach 1109 we take with PBT and PW over Ethernet. (The number of usable VLANs 1110 IDs in conventional Ethernet bridging is constrained to 4094, 1111 therefore the use of VLAN only configuration for all forwarding 1112 could be limited for some applications where large number of point 1113 to point connections are required.) This is because in Ethernet, 1114 each Spanning tree is associated with one or more VLAN IDs. Also 1115 Port membership in a VLAN is configured which controls the 1116 connectivity of all MAC interfaces participating in the VLAN. 1118 The roots for PBT capability exist in the Ethernet management plane. 1119 The management of Ethernet switches provides for static 1120 configuration of Ethernet forwarding. The Ethernet Control plane 1121 allows for forwarding entries that are statically provisioned or 1122 configured. In this document we are expanding the meaning of 1123 "configured" from an Ethernet Control plane sense to mean either 1124 provisioned, or controlled by GMPLS. The connectivity aspects of 1125 Ethernet forwarding is based upon VLANs and MAC addresses. In other 1126 words the VLAN + DMAC are an Ethernet Label that can be looked up at 1127 each switch to determine the egress link (or links in the case of 1128 link aggregation). 1130 In this document, we discuss, point to point (P2P) and point to 1131 multipoint (P2MP) connections via static configuration of VLAN/DMAC 1132 tuples. (MAC-only configuration is considered a degenerate case 1133 corresponding to VLAN zero). 1135 This is a finer granularity than traditional VLAN networks since 1136 each P2P connection is independent. By provisioning MAC addresses 1137 independently of Spanning tree in a domain, both the VLAN and the 1138 VLAN/DMAC configured forwarding can be exploited. This greatly 1139 extends the scalability of what can be achieved in a pure Ethernet 1140 bridged sub network. 1142 For compatibility and flexibility with existing Ethernet hardware, 1143 we preserve the global/domain wide uniqueness and semantics of MAC 1144 addresses as interface names or multicast group addresses. (In 1145 Ethernet overlap of MAC addresses across VLANs is allowed. However 1146 for PBT MAC addresses should be unique for all VLANs assigned to 1147 PBT. In many cases the MAC addresses can be out of the locally 1148 administered space) We then redefine the semantics associated with 1149 administration and uses of VLAN values for the case of explicit 1150 forwarding such as you get with statically configured IVL (or SVL) 1151 Ethernet. 1153 The result is a new architecture where configured VID + DMAC provide 1154 a forwarding table that is consistent with existing Ethernet 1155 switching. At the same time it provides domain wide labels that can 1156 be controlled by a common GMPLS control plane. This makes GMPLS 1157 control and resource management procedures ideal to create paths. 1158 The outcome is that the GMPLS control plane can be utilized to set 1159 up the following atomic modes of connectivity: 1161 1) P2P connectivity and MP2P multiplexed connectivity based 1162 on configuration of unicast MAC addresses in conjunction 1163 with a VID from a set of pre-configured VIDs. 1164 2) P2MP connectivity based on configuration of multicast MAC 1165 address in conjunction with a VID from a set of pre- 1166 configured VIDs. This corresponds to (Source, Group) or 1167 (S,G) multicast. 1168 3) P2MP connectivity based on configuration of VID port 1169 membership. This corresponds to (S,*) or (*,*) multicast 1170 (where * represents the extent of the VLAN Tree). 1171 4) MP2MP connectivity based on configuration of VID port 1172 membership (P2MP trees in which leaves are permitted to 1173 communicate). Although, we caution that this approach 1174 poses resilience issues (discussed in section 5) and hence 1175 is not recommended. 1177 Items 1 and 2 above are restricted to "Independent VLAN Learning" 1178 capable Ethernet switches [802.1Q]. 1180 The modes above are not completely distinct. Some modes involve 1181 combinations of P2P connections in one direction and MP connectivity 1182 in the other direction. Also, more than one mode may be combined in 1183 a single GMPLS transaction. One example is the incremental addition 1184 of a leaf to a P2MP tree with a corresponding MP2P return path 1185 (analogous to a root initiated join). 1187 In order to realize the above connectivity modes, a partition of the 1188 VLAN IDs from traditional Ethernet needs to be established. The 1189 partition allows for a pool of Ethernet labels for manual 1190 configuration and/or for GMPLS control plane usage. The VID 1191 partition actually consists of a "configured VID/DMAC range" and 1192 "configured VID range" since in some instances the label is a 1193 VID/DMAC and sometimes the label is a VID/Mulitcast DMAC. 1195 A 2. Overview of configuration of VID/DMAC tuples 1197 Existing Ethernet Switches may perform Independent VLAN Learning 1198 (IVL) based forwarding on the basis of a VID/DMAC tuple as described 1199 in 802.1Q. IVL is an example where the VLAN is partitioned and each 1200 is used as a unique filter for forwarding. In this document we build 1201 on that concept of IVL partitioning of the VID. The basic operation 1202 of an Ethernet switch is filtering on VID and forwarding on DMAC. 1203 The resulting operation is the same as performing a full 60 bit 1204 lookup (VID (12) + DMAC(48)) for point to point operations, only 1205 requiring uniqueness of the full 60 bits for forwarding to resolve 1206 correctly. We can call this an Ethernet domain wide label. 1208 We have complete route freedom for each domain wide label (60 bit 1209 VLAN/DMAC tuple) and the ability to define multiple connectivity 1210 instances or paths per DMAC for each of the VIDs in the "configured 1211 VID/DMAC range". 1213 We have preserved the semantics of MAC addresses, and simply broaden 1214 the potential interpretations of VLAN ID from spanning tree 1215 identifier to topology instance identifier. Therefore, we can 1216 concurrently operate both standard bridging and configured 1217 unicast/multicast operation side by side. We partition the VID space 1218 and allocate a range of VIDs (say 'n' VIDs) as only significant when 1219 combined with a configured DMAC address (the aforementioned 1220 "configured VID/DMAC range" of VIDs). We can then consider a VID in 1221 that range as an individual connectivity instance identifier for a 1222 configured P2P path terminating at the associated DMAC address. Or 1223 in the case of P2MP, a P2MP multicast tree corresponding to the 1224 destination multicast group address. Note that this is destination 1225 based forwarding consistent with how Ethernet works today. The only 1226 thing changed is the mechanism of populating the forwarding tables. 1228 Ethernet MAC addresses are typically globally unique since the 48 1229 bits consists of 24 bit Organizational Unique Identifier and a 24 1230 bit serial number. There is also a bit set aside for Multicast and 1231 for local addresses out of the OUI field. We define domain wide as 1232 within a single organization, or more strictly within a single 1233 network within an organization. For provider MAC addresses that will 1234 only be used in a domain wide sense we can define MAC addresses out 1235 of a either the local space or the global space since they both have 1236 the domain wide unique property. When used in the context of GMPLS, 1237 it is useful to think of a domain wide pool of labels where switches 1238 are assigned a set of MAC addresses. These labels are assigned 1239 traffic that terminates on the respective switches. 1241 It is also worth noting that unique identification of source in the 1242 form of the SMAC is carried e2e in the MAC header. So although we 1243 have a 60 bit domain wide unique label, it may be shared by multiple 1244 sources and the full connection identifier for an individual P2P 1245 instance is 108 bits (SMAC, VID and DMAC). The SMAC is not 1246 referenced in forwarding operations but it would allow additional 1247 context for tracing or other operations at the end of the path. 1249 GMPLS signaling procedures can be designed to create the bi- 1250 directional path delegating label allocation of the combined 1251 VID/DMAC Label to the destination/source associated with the MACs 1252 for each direction of unicast forwarding. Creating P2P path is a 1253 well understood control plane requirement. 1255 For multicast group addresses, the VID/DMAC concatenated label can 1256 be distributed by the source but label assignment (as it encodes 1257 global multicast group information) requires coordination within the 1258 GMPLS controlled domain. 1260 As mentioned earlier, this technique results in a single unique and 1261 invariant identifier, in our case a VID/DMAC label associated with 1262 the path termination or the multicast group. There can be up to 1263 4094 labels to any one MAC address. However, practically, from 1264 Ethernet network wide aspect, there would be only a handful of VLANs 1265 allocated for PBT. In addition, all 48 bits are not completely 1266 available for the MAC addresses. One way to maximize the space is 1267 to use the locally administered space. This is a large number for 1268 P2P applications and even larger when shared or multiplexed 1269 forwarding is leveraged. In practice, most network scaling 1270 requirements may be met via allocation of only a small portion of 1271 the VID space, to the configured VID/DMAC range. The result is 1272 minimal impact on the number of remaining bridging VLANs that can be 1273 concurrently supported. 1275 In order to use this unique 60 bit label, we disable the normal 1276 mechanisms by which Ethernet populates the forwarding table for the 1277 allocated range of VIDs. When a path is setup, for a specific label 1278 across a contiguous sequence of Ethernet switches, a unidirectional 1279 connection is the functional building block for an Ethernet Label 1280 Switched path (Eth-LSP). 1282 In P2P mode a bi-directional path is composed of two unidirectional 1283 paths that are created with a single RSVP-TE session. The technique 1284 does not require the VID to be common in both directions. However, 1285 keeping in line with regular Ethernet these paths are symmetrical 1286 such that a single bi-directional connection is composed of two 1287 unidirectional paths that have common routing (i.e. traverse the 1288 same switches and links) in the network and hence share the same 1289 fate. 1290 In P2MP mode a bi-directional path is composed of a unidirectional 1291 tree and a number of P2P paths from the leaves of the tree to the 1292 root. Similarly these paths may have bandwidth and must have common 1293 routing as in the P2P case. 1295 There are a few modifications required to standard Ethernet to make 1296 this approach robust: 1298 1. In Standard Ethernet, discontinuities in forwarding table 1299 configuration in the path of a connection will normally result in 1300 packets being flooded as "unknown". For configured operation (e.g. 1302 PBT), unknown addresses are indicative of a fault or configuration 1303 error and the flooding of these is undesirable in meshed topologies. 1304 Therefore flooding of "unknown" unicast/multicast MAC addresses must 1305 be disabled for the "configured VID/DMAC range". 1307 2. MAC learning is not required, and although it will not interfere 1308 with management/control population of the forwarding tables, since 1309 static entries are not overridden, it appears prudent to explicitly 1310 disable MAC learning for the configured VID/DMAC and VID range. 1312 3. Spanning tree is disabled for the allocated VID/DMAC and VID 1313 range and port blocking must be disabled to achieve complete 1314 configured route freedom. As noted earlier, it is a control plane 1315 requirement to ensure configured paths are loop free. 1317 All three modifications described above are within the scope of 1318 acceptable configuration options defined in IEEE802.1Q 1319 specification. 1321 A 3. Overview of configuration of VID port membership 1323 Procedures almost identical to that for configuration of P2P 1324 VID/DMAC tuples can also be used for the incremental configuration 1325 of P2MP VID trees. For the replication of forwarding in this case 1326 the label is common for the multipoint destinations. The MAC field 1327 is set to multicast address and is common to the multicast 1328 community. The VID is a distinguisher common to the multicast 1329 community. The signaling procedures are as per that for [MPLS-P2MP]. 1331 Since VID translation is relatively new and is not a ubiquitously 1332 deployed capability, we consider a VID to be a domain global value. 1333 Therefore, the VID value to be used by the originating switch may be 1334 assigned by management and nominally is required to be invariant 1335 across the network. The ability to indicate permissibility of 1336 translation will be addressed in a future version of the document. 1338 A procedure known as "asymmetrical VID" may be employed to constrain 1339 connectivity (root to leaves, and leaves to root only) when switches 1340 also support shared VLAN learning (or SVL). This would be consistent 1341 with the root as a point of failure. 1343 A 4. OAM Aspects 1345 Robustness is enhanced with the addition of data plane OAM to 1346 provide both fault and performance management. 1348 For the configured VID/DMAC unicast mode of behavior, the hardware 1349 performs unicast packet forwarding of known MAC addresses exactly as 1350 Ethernet currently operates. The OAM currently defined,[802.1ag and 1351 Y.1731] can also be reused without modification of the protocols. 1352 However currently if the VID for PBT is different in each direction 1353 some modification of the OAM may be required. 1355 An additional benefit of domain wide path identifiers for data plane 1356 forwarding, is the tight coupling of the 60 bit unique connection ID 1357 (VID/DMAC) and the associated OAM packets. It is a simple matter to 1358 determine a broken path or misdirected packet since the unique 1359 connection ID cannot be altered on the Eth-LSP. This is in fact one 1360 of the most powerful and unique aspects of the domain wide label for 1361 any type of rapid diagnosis of the data plane faults. It is also 1362 independent of the control plane so it works equally well for 1363 provisioned or GMPLS controlled paths. 1365 Bi-directional transactions (e.g. ETH-LB) and reverse direction 1366 transactions (e.g. ETH-AIS) MAY have a different VID for each 1367 direction. Currently Y.1731 & 802.1ag makes no representations with 1368 respect to this. 1370 For configured multicast VID/DMAC mode, the current versions of 1371 802.1ag and Y.1731] make no representation as to how PDUs which are 1372 not using unicast addresses or which use OAM reserved multicast 1373 addresses are handled. Therefore this specification makes no 1374 representation as to whether such trees can be instrumented. 1376 When configured VID mode of operation is used PBT can be forced to 1377 use the same VID in both directions, emulating the current Ethernet 1378 data plane and the OAM functions as defined in the current versions 1379 of 802.1ag and Y.1731 can be used with no restriction. 1381 A 5. QOS Aspects 1383 Ethernet VLAN tags include priority tagging in the form of the 1384 802.1p priority bits. When combined with configuration of the paths 1385 via management or control plane, priority tagging produces the 1386 Ethernet equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged 1387 Ethernet PDUs self-identify the required queuing discipline 1388 independent of the configured connectivity. 1390 It should be noted that the consequence of this is that there is a 1391 common COS model across the different modes of configured operation 1392 specified in this document. 1394 The actual QOS objects required for signaling will be in a future 1395 version of this memo. 1397 A 6. Resiliency Aspects 1399 A 6.1 E2E Path protection 1401 One for One(1:1) protection is a primary LSP with a disjoint 1402 dedicated back up LSP. One plus one (1+1) protection is a primary 1403 LSP with a disjoint backup LSP that may share resources with other 1404 LSPs. One for One and One plus One Automatic Protection Switching 1405 strategies are supported. Such schemes offer: 1407 1) Engineered disjoint protection paths that can protect both 1408 directions of traffic. 1409 2) Fast switchover due to tunable OAM mechanisms. 1410 3) Revertive path capability when primary paths are restored. 1411 4) Option for redialing paths under failure. 1413 Specific procedures for establishment of protection paths and 1414 associating paths into "protection groups" are TBD. 1416 Note that E2E path protection is able to respond to failures with a 1417 number of configurable intervals. The loss of CCM OAM cells or ETH- 1418 AIS cells in the data plane can trigger paths to switch. In the case 1419 of CCM OAM cells, the detection time is typically 3.5 times the CCM 1420 interval plus the propagation delay from the fault.