idnits 2.17.00 (12 Aug 2021) /tmp/idnits56922/draft-fedyk-gmpls-ethernet-pbb-te-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 963. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 19, 2007) is 5290 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 Himanshu Shah, Ciena 4 Category: Standards Track Nabil Bitar, Verizon 5 Attila Takacs, Diego Caviglia, Ericsson 6 Alan McGuire, BT 7 Nurit Sprecher, Nokia Siemens Networks 8 Lou Berger, LabN 9 November 19, 2007 11 GMPLS control of Ethernet PBB-TE 12 draft-fedyk-gmpls-ethernet-pbb-te-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire in May 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This memo is complementary to [ARCH] and describes how a GMPLS 46 control plane may be applied to the Provider Backbone Bridges Traffic 47 Engineering (PBB-TE) [IEEE 802.1Qay] amendment to 802.1Q and how 48 GMPLS can be used to configure VLAN-aware Ethernet switches in order 49 to establish Ethernet point to point (P2P) and P2MP MAC switched 50 paths and P2P/P2MP VID based trees. This document supports, but does 51 not modify, the standard IEEE data. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Document History 61 This document has under gone name changes to follow the 62 standardization of Provider Backbone Bridges and the Traffic 63 engineering capability. 65 draft-fedyk-gmpls-ethernet-ivl-00.txt. 67 This was the original draft. 69 draft-fedyk-gmpls-ethernet-pbt-00.txt 70 draft-fedyk-gmpls-ethernet-pbt-01.txt 72 This draft was renamed to reflect the Provider Backbone Transport 73 (PBT) nomenclature. Several co-authors joined the draft. 75 draft-fedyk-gmpls-ethernet-pbb-te-00.txt 77 The standardization of PBT is called Provider Backbone Bridges 78 Traffic Engineering (PBB-TE). The draft was aligned the PBB-TE 79 Technology. 81 draft-fedyk-gmpls-ethernet-pbb-te-01.txt 83 This is the second revision of the PBB-TE draft with editing to 84 clarify the document and the addition of co-authors. 86 draft-fedyk-gmpls-ethernet-pbb-te-02.txt 88 This is a third revision with the general aspects of Ethernet being 89 move to the architecture and framework [ARCH] and the specifics for 90 PBB-TE becoming more clear. 92 Table of Contents 94 1. Introduction..................................................4 95 2. Terminology...................................................4 96 2.1 PBB-TE Terminology..........................................5 97 3. GMPLS creation and maintenance of PBB-TE Service Instances....5 98 3.1 Ethernet Service............................................6 99 3.2 Addresses, Interfaces, and Labels...........................7 100 4. Specific Procedures...........................................9 101 4.1 P2P connections.............................................9 102 4.1.1 Shared Forwarding........................................ 10 103 4.1.2 P2P connections with shared forwarding................... 11 104 4.1.3 Dynamic P2P symmetry with shared forwarding.............. 12 105 4.1.4 Planned P2P symmetry..................................... 12 106 4.1.5 P2P Path Maintenance..................................... 12 107 4.2 P2MP Signaling............................................ 13 108 4.3 P2MP VID/ESP-MAC DA Connections........................... 13 109 4.3.1 Setup procedures......................................... 13 110 4.3.2 Maintenance Procedures................................... 13 111 4.4 Ethernet Label............................................ 14 112 4.5 OAM MEP ID and MA ID synchronization...................... 15 113 4.6 Protection Paths.......................................... 15 114 5. Error conditions............................................ 16 115 5.1 Invalid ESP-VID value for PBB-TE MSTI range............... 16 116 5.2 Invalid MAC Address....................................... 16 117 5.3 Invalid ERO for UPSTREAM_LABEL Object..................... 16 118 5.4 Invalid ERO for LABEL_SET Object ......................... 16 119 5.5 Switch is not ESP P2MP capable............................ 16 120 5.6 Invalid ESP-VID in UPSTREAM_LABEL object ................. 16 121 6. Deployment Scenarios........................................ 16 122 7. Security Considerations .................................... 16 123 8. IANA Considerations......................................... 17 124 9. References.................................................. 17 125 9.1 Normative References...................................... 17 126 9.2 Informative References.................................... 17 127 10. Author's Address.......................................... 18 128 11. Intellectual Property Statement........................... 19 129 12. Disclaimer of Validity.................................... 20 130 13. Copyright Statement....................................... 20 131 14. Acknowledgments........................................... 20 132 Appendix A..................................................... 21 133 Rational and mechanism for PBB_TE Ethernet Forwarding.......... 21 134 A 1. Overview of configuration of VID/DMAC tuples............. 23 135 A 2. Overview of configuration of VID port membership......... 26 136 A 3. OAM Aspects ............................................. 26 137 A 4. QOS Aspects ............................................. 27 138 A 5. Resiliency Aspects ...................................... 27 139 A 5.1. E2E Path protection.................................... 27 141 1. Introduction 143 IEEE 802.1 is specifying Traffic Engineered Ethernet paths in the 144 Provider Backbone Bridged network (PBB-TE) [IEEE 802.1Qay] based on 145 managed objects that can be separated from the Spanning Tree Control 146 Plane and statically configured or managed by a another control 147 plane. These paths have minor changes to Ethernet data plane 148 specified in the IEEE. IEEE 802 termed these paths "PBB-TE service 149 instances". 151 The purpose of this document is to specify extensions for a GMPLS 152 based control plane to manage PBB-TE service instances. This draft 153 is aligned with GMPLS Ethernet Label Switching Architecture and 154 Framework [ARCH]. 156 It should be noted that due to the changes in the separation of the 157 Spanning Tree Control plane and the PBB-TE forwarding, the behavior 158 of PBB-TE for the specified VLAN range is a new behavior. (It does 159 not default to conventional Ethernet forwarding with learning at any 160 time). Appendix A summarized the rational for this data plane 161 technology until the IEEE specification is more mature. 163 2. Terminology 165 In addition to well understood GMPLS terms, this memo uses 166 terminology from IEEE 802.1 and introduces a few new terms: 168 B-MAC Backbone MAC 169 B-VID Backbone VLAN ID 170 B-VLAN Backbone VLAN 171 CBP Customer Backbone Port 172 CCM Continuity Check Message 173 COS Class of Service 174 CLI Command Line Interface 175 CIP Customer Instance Port 176 C-MAC Customer MAC 177 C-VID Customer VLAN ID 178 C-VLAN Customer VLAN 179 DMAC Destination MAC Address 180 ESP Ethernet Switched Path 181 Eth-LSP Ethernet Label switched Path 182 I-SID Ethernet Service Instance Identifier 183 LBM Loopback Message 184 LBR Loopback Reply 185 LLDP Link Layer Discovery Protocol 186 LMM Loss Measurement Message 187 LMR Loss Measurement Reply 188 MAC Media Access Control 189 MMAC Multicast MAC 190 MSTI Multiple Spanning Tree Instance 191 MP2MP Multipoint to multipoint 192 PBB Provider Backbone Bridges 193 PBB-TE Provider Backbone Bridges Traffic Engineering 194 PIP Provider Instance Port 195 PNP Provider Network Port 196 P2P Point to Point 197 P2MP Point to Multipoint 198 QOS Quality of Service 199 ESP-MAC SA Source MAC Address 200 S-VID Service VLAN ID 201 SVL Shared VLAN Learning 202 VID VLAN ID 203 VLAN Virtual LAN 205 2.1 PBB-TE Terminology 207 The PBB-TE specification has defiend some additional termminology to 208 clarify the PBB-TE functions. We repeat these here in expanded 209 context to translate from IEEE to GMPLS terminology. 211 - Ethernet Switched Path (ESP): A provisioned traffic engineered 212 unidirectional connectivity path between two or more Customer 213 Backbone Ports(CBPs) which extends over a Provider Backbone Bridge 214 Network (PBBN). The path is identified by the 3-tuple where the ESP-VID value is allocated to the 216 PBB-TE Multiple Spanning Tree Instance (MSTI)(A set of VIDs for 217 PBB-TE is allocated as a set of MSTIs). An ESP is analogous to an 218 GMPLS LSP. 220 - PBB-TE Region: A set of PBB switches and PB switches by a set of 221 Service-VLANs allocated to provisioned Ethernet Switched Paths 222 (ESPs). 224 - PBB-TE service instance: A Point-to-Point or a Point-to-Multipoint 225 PBB-TE service instance. 227 - PBB-TE Trunk: A Point-to-Point PBB-TE service instance. 229 - Point-to-Point PBB-TE service instance: An instance of the MAC 230 service provided by two unidirectional co-routed ESPs forming a 231 bidirectional service. A GMPLS bidirectional path is analogous to 232 a P2P PBB-TE Service instance. 234 - Point-to-Multipoint PBB-TE service instance: An instance of the 235 MAC service provided by a set of ESPs which comprises one 236 multipoint ESP plus n unidirectional point-to-point ESPs, routed 237 along the leaves of the multicast ESP. A P2MP GMPLS bidirectional 238 tree is analogous to a P2MP PBB-TE service instance. 240 3. GMPLS creation and maintenance of PBB-TE Service Instances 242 PBB-TE is an Ethernet connection oriented technology, being 243 specified in the IEEE, which can be controlled by configuration of 244 static filtering entries [see Appendix A] for some details on the 245 rational for the data plane. PBB-TE ESPs are created switch by 246 switch by simple configuration of Ethernet logical ports and 247 assignment of PBB-TE labels or by a control plane. This document 248 describes GMPLS as a valid control plane for Eth-LSPs that are based 249 on PBB-TE ESPs. A Point-to-Point PBB-TE service instance is a form 250 of Ethernet LSP (Eth-LSP) which is more broadly defined in [ARCH]. 251 This memo describes GMPLS as a mechanism to automate set-up 252 teardown, protection and recovery of PBB-TE ESPs and specifies the 253 specific TLVs for control of PBB-TE service instances. 255 When configuring a PBB-TE ESP with GMPLS, the ESP-MAC DA and ESP-VID 256 are carried in a generalized label object and are assigned hop by 257 hop but are invariant within a domain. This invariance is similar to 258 GMPLS operation in transparent optical networks. As is typical with 259 other technologies controlled by GMPLS, the data plane receiver must 260 accept, and usually assigns, labels from its available label pool. 261 This, together with the label invariance requirement mentioned 262 above, result in each PBB-TE label being a domain wide unique label, 263 with a unique ESP-VID + ESP-MAC DA, for each direction. 265 The following illustrates the identifiers for Labels and ESPs. 267 GMPLS Upstream Label (60 bits) 268 GMPLS Downstream Label (60 bits) 269 Upstream PBB-TE ESP 3-tuple (108 bits) 270 Downstream PBB-TE ESP 3-tuple (108 bits) 272 Table 1 Labels and ESPs 274 The MAC is domain wide unique in the network. PBB-TE defines the 275 tuple of as a unique connection 276 identifier in the data plane but the forwarding operation only uses 277 the ESP-MAC DA (DMAC) and the ESP-VID in each direction. Note that 278 the MAC addresses for PBB-TE are part of the Backbone Component 279 Relay (B-Component) and are associated with Provider addresses 280 corresponding to the Backbone Customer ports as described in section 281 3.2. The ESP-VID (VID) typically comes from a small number of VIDs 282 dedicated to PBB-TE MSTI. The ESP-VID (VID) can be reused across 283 ESPs. There is no requirement the ESP-VID for two ESPs that for a 284 PBB-TE Service instance be the same. 286 Several attributes may be associated with an Eth-LSP. These are 287 reviewed in Section 3 of [ARCH]. Several other aspects of GMPLS 288 covered by [ARCH] also apply equally to PBB-TE. This includes the 289 GMPLS routing and addressing model, link management, path 290 computation and selection, and multiple domains. 292 3.1 Ethernet Service 294 Ethernet Switched Paths that are setup either by configuration or 295 signaling can be used to provide an Ethernet service to customers of 296 the Ethernet network. The Metro Ethernet Forum has defined some 297 services in [MEF.6] (e.g., Ethernet Private Line), and these are also 298 aligned with ITU-T G.8011-x Recommendations. Of particular interest 299 are the bandwidth profile parameters in [MEF.10] and whose associated 300 bandwidth profile algorithm are based on [RFC4115] [RFC3270]. 301 Consideration should be given to supporting these in any signaling 302 extensions for Ethernet LSPs. This will be addressed in a future 303 version of this specification. 305 3.2 Addresses, Interfaces, and Labels 307 This specification uses an addressing scheme and a label space for 308 the ingress/egress connection; the hierarchical TE Router 309 ID/Interface ID and the Ethernet ESP-VID/ESP-MAC DA tuple or ESP- 310 VID/Multicast MAC as a label space. This draft is intended to be 311 consistent with GMPLS addressing and Routing [ARCH]. 313 PBB-TE is defined for a PBB IB-Bridge. This is illustrated in Figure 314 1. The Ethernet service is attached to a Customer Instance Port 315 (CIP) of the Backbone Service Instance (I-component) Relay. The CIP 316 is interfaced to a Virtual instance port (VIP) which is identified 317 with a configured service instance (I-SID) and attached to a Provider 318 Instance Port (PIP). The PIP is configured to be attached to a 319 customer Backbone port (CBP). (A point to point service instance is 320 illustrated. A point to multipoint service could allow more than one 321 CBP to be attached to a single PIP.) The CBP has a BMAC that defines 322 the MAC for the PBB-TE Service Instance. The B-Component relay adds 323 the ESP Header the ESP-MAC DA, ESP-MAC SA and the ESP-VID. GMPLS is 324 being defined here to connect CPB MACs to signal the PBB-TE service 325 Instance before the association of ESP-MAC DA and ESP-MAC SA is 326 defined. 328 The diagram also shows the addition of a TE Router ID to the PBB 329 switch and the TE Link identifier to enable GMPLS. TE Links are not 330 associated with CPBs. TE Links are associated with PNPs. TE links are 331 associated with node identifiers of backbone edge bridges (BEB) and 332 backbone core bridges (BCB). CBPs are also associated with these node 333 ids. For GMPLS the node IDs are expressed as IP addresses as TE- 334 Router IDs. [ADDRESS] 335 Backbone Edge Bridge (BEB) 336 +------------------------------------------------------+ 337 | | 338 | | 339 | I-Component Relay B-Component Relay | 340 | +-----------------------+ +---------------------+ | 341 | | +---+ | | B-VID | | 342 | | |VIP| | | +---+ +---+ | | 343 | | +---+ | +---|CBP| |PNP|------ 344 | | | | | +---+ +---+ | | 345 | | +---+ +---+ | | | | | 346 ------|CIP| |PIP|----+ | | | 347 | | +---+ +---+ | | | | 348 | +-----------------------+ +---------------------+ | 349 | | 350 | PBB Edge Bridge | 351 +------------------------------------------------------+ 353 ^--------Configured--------------^ 354 ^-GMPLS or Configured-. 356 Figure 2 Ethernet/GMPLS Addressing & Label Space 358 TE Router ID TE Router ID 359 | (TE Link) | 360 V | V N=named port 361 +----+ | +-----+ 362 | | | label=ESP:VID/MAC DA | | 363 | PB | V label=ESP:VID/MMAC | | 364 -----N N----------------------------N PBB N---------- 365 | | |(MAC)| \ 366 | | / | Customer 367 +----+ /+-----+ Facing 368 BCB ESP:MAC BEB Ports 370 Figure 3 Ethernet/GMPLS Addressing & Label Space 372 For a GMPLS based system, the TE Router ID/logical port is the 373 logical signaling identifier for the control plane via which Ethernet 374 layer label bindings are solicited. In order to create a P2P path an 375 association must be made between the ingress and egress node. The 376 actual label distributed via signaling and instantiated in the switch 377 forwarding tables identifies the upstream and downstream egress ESP- 378 VID/ESP-MAC DA of the PBB-TE ESP (see Figure 4). 380 GMPLS uses identifiers in the form of 32 bit numbers which are in the 381 IP address notation which may or may not be IP addresses. The 382 provider MAC port addresses are exchanged by the LLDP [IEEE 802.1AB] 383 and by LMP [RFC4204] if supported. However these identifiers are 384 merely for link control and legacy Ethernet support and have local 385 link scope. Actual label assignment is performed by the ingress and 386 egress nodes using CPB MAC addresses. 388 A particular PNP would have: 389 - A VID/MAC 390 - An IP address, which is typically the TE router ID, plus a 32 bit 391 interface Identifier also call an unnumbered link. 392 - One (or more) Mnemonic String Identifiers 394 This multiple naming convention leaves the issue of resolving the set 395 given one of the port identifiers. On a particular node, mapping is 396 relatively straightforward. Per [ARCH], standard GMPLS mechanisms 397 are used for signaling resolution. In so doing, the problem of 398 setting up a path is reduced to figuring out what switch supports an 399 egress CBP MAC address and then finding the corresponding egress IP 400 address and performing all signaling and routing with respect to the 401 egress. 403 There are several options to achieve this: 404 - Provisioning 405 - Auto discovery protocols that carry MAC address 406 - Augmenting Routing TE with MAC Addresses 407 - Name Servers with identifier/address registration 408 The specific procedures will be clarified in a subsequent version of 409 this document. 411 4. Specific Procedures 413 4.1 P2P connections 415 The PBB-TE Service Instance is defined by the ESP 3-tuples for each 416 of the unidirectional ESPs. From a GMPLS control plane point of view 417 an Ethernet LSP MAY also be identified as any other LSP using the 5- 418 tuple [Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID, 419 Extended_Tunnel_ID]. The ESP-VID and ESP-MAC DA tuple identifies the 420 forwarding multiplex at transit switches and a simple degenerate form 421 of the multiplex is a single P2P connection. 423 This results in unique labels end to end. The data streams MAY merge, 424 the forwarding entries MAY be shared but the headers are still unique 425 allowing the connection to be de-multiplexed downstream. 427 On the initiating and terminating nodes, a function administers the 428 ESP-VIDs associated with the ESP-MAC SA and ESP-MAC DA respectively. 429 PBB-TE is designed to be bidirectional and symmetrically routed just 430 like Ethernet. Therefore in PBB-TE, the packet ESP-MAC SA and ESP- 431 MAC DA pair is same in the forwarding path and the associated 432 reverse path except they are flipped in the reverse direction. 434 To initiate a bidirectional ESP-VID/ESP-MAC DA P2P or P2MP path, the 435 initiator of the PATH message uses procedures outlined in [RFC3473] 436 possibly augmented with [RFC4875], it: 438 1) Sets the LSP encoding type to Ethernet. 440 2) Sets the LSP switching type to 802_1 PBB-TE [IANA to define]. 442 3) Sets the GPID to service type [IANA to define]. 444 4) Sets the UPSTREAM_LABEL to the ESP-VID/ESP-MAC SA tuple where the 445 ESP-VID is administered from the configured ESP-VID/ESP-MAC DA 446 range. 448 5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to 449 influence the choice of ESP-VID/ESP-MAC DA. 451 6) Optionally look at Call / Connection ID for Carrying I-SID. 453 Intermediate and egress node processing is not modified by this 454 document, i.e., is per [RFC3473] and, in the case of P2MP, as 455 extended in [RFC4875]. Note, as previously stated intermediate nodes 456 supporting the 802_1 switching type may not modify LABEL values. 458 The ESP-VID/ESP-MAC SA tuple contained in the UPSTREAM_LABEL is used 459 to create a static forwarding entry in the Filtering Database of 460 bridges at each hop for the upstream direction. This behavior is 461 inferred from the switching type which is 802_1 [IANA to define]. 462 The port derived from the RSVP_HOP object and the ESP-VID and ESP- 463 MAC DA included in the label constitute the static entry. 465 At the destination, a ESP-VID is allocated in the local MAC range 466 for the ESP-MAC DA and the ESP-VID/ESP-MAC DA tuple is passed in a 467 LABEL object in the RESV message. As with the Path message, 468 intermediate node processing is per [RFC3473] and [RFC4875], and the 469 LABEL object is passed on unchanged, upstream. The ESP-VID/ESP-MAC 470 DA tuple contained in the LABEL Object is installed in the 471 forwarding table as a static forwarding entry at each hop. This 472 creates a bidirectional path as the PATH and RESV messages follow 473 the same path. 475 4.1.1 Shared Forwarding 477 One capability of a connectionless Ethernet data plane is to reuse 478 destination forwarding entries for packets from any source within a 479 VLAN to a destination. When setting up P2P PBB-TE connections for 480 multiple sources sharing a common destination this capability MAY be 481 preserved provided certain requirements are met. We refer to this 482 capability as Shared Forwarding. Shared forwarding is invoked based 483 on policy when conditions are met. It is a local decision by label 484 allocation at each end. Shared forwarding has no impact on the 485 actual paths setup, but it allows the reduction of forwarding 486 entries. Shared forwarding paths are identical to independently 487 routed paths with the exception that they share the same labels and 488 same path from the merge point. 490 To achieve shared forwarding, a Path computation engine [PATHCOMP] 491 should ensure the ERO is consistent with an existing path for the 492 shared segments. If a path satisfies the consistency check, the 493 upstream end of the signaling may chose to share an existing ESP- 494 VID/ESP-MAC DA for the upstream traffic with an existing Eth-LSP. 495 The criteria for shared forwarding is the Eth-LSPs must share the 496 same destination port and the paths of the Eth-LSP share one or more 497 hops consecutively. Once the paths converge they must remain 498 converged. If no existing path has this behavior when a new path is 499 being created, the new path will be created without sharing either 500 by using another ESP-VID or another ESP-MAC DA or both. 502 In other words, shared forwarding is possible when paths share 503 segments either from the source or the destination. There is no 504 requirement that the paths share reservations or other attributes. 505 For the source, the UPSTREAM_LABEL is chosen to be the same as an 506 existing path that shares the ERO for some number of hops. 507 Similarly for the destination, shared forwarding is possible when an 508 existing path that shares segments with the new paths ERO, viewed 509 from the destination switch. The downstream label in this case is 510 chosen to be the same as the existing path. In this manner shared 511 forwarding is a function that is controlled primarily by policy and 512 in combination with the local label allocation at the end points of 513 the path. 515 4.1.2 P2P connections with shared forwarding 517 The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding 518 identifier or label for a multiplex consisting of some number of P2P 519 connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- 520 MAC SA tuple. In some ways this is analogous to an LDP label merge 521 but in the shared forwarding case only the forwarding entry is 522 reused. Resources can continue to be allocated per LSP. 524 VLAN tagged Ethernet packets include priority marking. Priority bits 525 MAY be used to indicate class of Service (COS) and drop priority. 526 Thus, traffic from multiple COSs could be multiplexed on the same 527 Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are 528 made based on the p-bits. This means that the queue selection can be 529 done based on a per flow (i.e., Eth-LSP + priority) basis and is 530 decoupled from the actual steering of the packet at any given node. 532 A switch terminating an Eth-LSP will frequently have more than one 533 suitable candidate path and it may choose to share a forwarding entry 534 (common ESP-VID/ESP-MAC DA, unique ESP-MAC SA). It is a local 535 decision of how this is performed but the best choice is a path that 536 maximizes the shared forwarding. 538 The concept of bandwidth management still applies equally well with 539 shared forwarding. As an example consider a PBB-TE edge switch that 540 terminates an Ethernet LSP with the following attributes: bandwidth 541 B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an 542 additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D, 543 ESP-MAC SA S2, ESP-VID V) can be accepted provided there is 544 sufficient link capacity remaining. 546 4.1.3 Dynamic P2P symmetry with shared forwarding 548 Similar to how a destination switch MAY select a ESP-VID/ESP-MAC DA 549 from the set of existing shared forwarding multiplexes rooted at the 550 destination node, the originating switch MAY also do so for the 551 reverse path. Once the initial ERO has been computed and the set of 552 existing Ethernet LSPs that include the target ESP-MAC DA have been 553 pruned, the originating switch may select the optimal (by whatever 554 criteria) existing shared forwarding multiplex for the new 555 destination to merge with and offer its own ESP-VID/ESP-MAC DA tuple 556 for itself as a destination. 558 4.1.4 Planned P2P symmetry 560 Normally the originating switch will not have knowledge of the set of 561 shared forwarding paths rooted on the destination node. 563 Use of a Path Computation Server [PATHCOMP] or other planning style 564 of tool with more complete knowledge of the network configuration may 565 wish to impose pre-selection of shared forwarding multiplexes to use 566 for both directions. In this scenario the originating switch uses the 567 LABEL_SET and UPSTREAM_LABEL objects to indicate complete selection 568 of the shared forwarding multiplexes at both ends. This may also 569 result in the establishment of a new ESP-VID/ESP-MAC DA path as the 570 LABEL_SET object may legitimately refer to a path that does not yet 571 exist. 573 4.1.5 P2P Path Maintenance 575 Make before break procedures can be employed to modify the 576 characteristics of a P2P Ethernet LSP. As described in [RFC3209], 577 the LSP ID in the sender template is updated as the new path is 578 signaled. The procedures (including those for shared forwarding) are 579 identical to those employed in establishing a new LSP, with the 580 extended tunnel ID in the signaling exchange ensuring that double 581 booking of the associated resources does not occur. 583 Where individual paths in a protection group are modified, signaling 584 procedures may be combined with Protection Switching (PS) 585 coordination to administratively force PS switching operations such 586 that modifications are only ever performed on the protection path. 588 4.2 P2MP Signaling 590 Note specifics for P2MP paths are being defined. This section will 591 be updated to align with the PBB-TE specification [IEEE 802.1Qay]. 593 To initiate a P2MP VID/Multicast MAC (MMAC) path the initiator of 594 the PATH message uses procedures outlined in [RFC3473] and 595 [RFC4875]. A P2MP tree consists of a VID tree or MMAC tree in the 596 forward direction (from root to leaves) and a set of P2P paths 597 running on identical paths from Tree to root in the reverse 598 direction. The result is a composite path with Multicast VID/ESP- 599 MMAC DA labels with a single ESP-MMAC DA in the forward direction 600 and a symmetric unidirectional ESP-VID/ESP-MAC DA label in the 601 reverse direction: 603 1-4) Same points as P2P paths previously specified. 605 5) Sets the downstream label as the Multicast VID/ESP-MMAC DA. 607 6) VID translation may optionally be permitted on a local basis 608 between two switches by a downstream switch replying with a 609 Multicast VID/ESP-MMAC DA other than the LABEL_SET. The upstream 610 switch then sets a VID translation on the port associated with the 611 label to allow VID translation. This flexibility allows the tree to 612 be constructed with out having to worry about colliding with another 613 tree using the same VID. (Inclusion of this point is TBD by [IEEE 614 802.1Qay]) 616 4.3 P2MP VID/ESP-MAC DA Connections 618 4.3.1 Setup procedures 620 The group ESP-MMAC DA is administered from a central pool of 621 multicast addresses and the VLAN selected from the PBB-TE MSTI range. 622 The P2MP tree is constructed via incremental addition of leaves to 623 the tree in signaling exchange where the root is the originating 624 switch (as per (RFC4875). The multicast VID/ESP-MAC DA is encoded in 625 the LABEL_SET (as a member of one) object using the Ethernet label 626 encoding. 628 Where a return path is required the unicast MAC corresponding to the 629 originating interface and a VID selected from the configured VID/ESP- 630 MAC DA range is encoded as an Ethernet label in the UPSTREAM_LABEL 631 object. 633 4.3.2 Maintenance Procedures 635 Maintenance and modification to a P2MP tree can be achieved by a 636 number of means. The preferred technique is to modify existing VLAN 637 configuration vs. assignment of a new label and completely 638 constructing a new tree. 640 Make before break on a live tree reusing existing label assignments 641 requires a 1:1 or 1+1 construct. The protection switch state of the 642 traffic is forced on the working tree and locked (PS not allowed) 643 while the backup tree is modified. Explicit path tear of leaves to 644 be modified is required to ensure no loops are left behind as 645 artifacts of tree modification. Once modifications are complete, a 646 forced switch to the backup tree occurs and the original tree may be 647 similarly modified. This also suggests that 1+1 or 1:1 resilience 648 can be achieved for P2MP trees for any single failure (switch on any 649 failure and use restoration techniques to repair the failed tree). 651 4.4 Ethernet Label 653 The Ethernet label is a new generalized label with a suggested 654 format of: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | ESP MAC | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 This format can be used to carry P2P and P2MP labels. For P2P labels 665 the fields specify ESP . The semantics for P2MP label o 666 using a MMAC DA is that that the label is passed unchanged. This 667 label is also a domain wide label. This has similarity to the way 668 in which a wavelength label is handled at an intermediate switch 669 that cannot perform wavelength conversion, and is described in 670 [RFC3473]. The option to allow just a Multicast VID to be signaled 671 without a MAC (A zero MAC) is for cases where a single VID is 672 desired to be signaled for P2MP trees in cases where a multicast MAC 673 is not desired. 675 These domain wide labels are allocated to switches that control the 676 assignment of labels. There are two options for Ethernet MAC based 677 domain wide unique labels. One option is to allocate the ESP-MAC DAs 678 from globally unique addresses assigned to the either the switch 679 manufacturer or the owner. The other option is to use ESP-MAC DAs 680 out of the local admin space and ensue these labels are unique 681 within the domain. This local ESP-MAC DA space does not have to be 682 globally unique because the labels are only valid within a single 683 provider domain. 685 In the case of local label allocation there is less administrative 686 overhead to allocate labels. However when using configuration, a 687 tool would have to perform a consistency check to make sure that 688 labels were unique. When using GMPLS signaling it is assumed a 689 unique pool of labels would be assigned to each switch. The ESP-MAC 690 DA addresses are domain wide unique and so is the combination of ESP 691 . It is intended that the ESP be only 692 used by one destination. However, should an error occur and a 693 somehow a duplicate label be assigned to one or more destination 694 switches GMPLS signaling procedures would allow the first assignment 695 of the label and prevent any duplicate label from colliding. If a 696 collision occurs an alarm would be generated. In fact some of these 697 procedures have been defined in GMPLS control of photonic networks 698 where a lambda may exist as a form of domain wide label. 700 4.5 OAM MEP ID and MA ID synchronization 702 This section is aligned with [IEEE 802.1Qay]. At present it Ethernet 703 OAM is signaled in Ethernet packet data units. 705 The Maintenance end point IDs (MEP IDs) and maintenance association 706 IDs for the switched path endpoints can be synchronized using the 707 ETH-MCC (maintenance communication channel) transaction set once the 708 switched path has been established. 710 MEPs are located at the endpoints of the Ethernet LSP. Typical 711 configuration associated with a MEP is Maintenance Domain Name, 712 Short Maintenance Association Name, and MA Level, MEP ID, and CCM 713 transmission rate (when ETH-CC functionality is desired). As part of 714 the synchronization, it is verified that the Maintenance Domain 715 Name, Short Maintenance Association Name, MA Level, and CCM 716 transmission rate are the same. It is also determined that MEP IDs 717 are unique for each MEP. 719 Besides the unicast CCM functionality, the PBB-TE MEPs can also 720 offer the LBM/LBR and LMM/LMR functionalities for on-demand 721 connectivity verification and loss measurement purposes. 723 4.6 Protection Paths 725 The IEEE is currently defining protection procedures for PBB-TE 726 [IEEE 802.1Qay]. This section will be updated when these procedures 727 are documented. 729 When protection is used for path recovery it is required to 730 associate the working and protection paths into a protection group. 731 This is achieved as defined in [RFC4872] and [RFC4873] using the 732 ASSOCIATION and PROTECTION objects. Protection may be used for P2P 733 VID/ESP-MAC DA, P2MP VID/ESP-MAC DA and P2MP VID configured modes of 734 operation. The 'P' bit in the protection object indicates the role 735 (working or protection) of the LSP currently being signaled. 737 If the initiating switch wishes to use G.8031 [G-8031] data plane 738 protection switching coordination (vs. control plane notifications), 739 it sets the N bit to 1 in the protection object. This must be 740 consistently applied for all paths associated as a protection group. 742 If the terminating switch does not support G.8031, the error 743 "Admission Control Failure/Unsupported Notification Type" is used. 745 5. Error conditions 747 The following errors have been identified as being unique to these 748 procedures and in addition to those already defined. This will be 749 addressed in a proper IANA considerations section in a future 750 version of the document: 752 5.1 Invalid ESP-VID value for PBB-TE MSTI range 754 The originator of the error is not configured to use the ESP-VID 755 value in conjunction with GMPLS signaling of 756 tuples. This may be any switch along the path. 758 5.2 Invalid MAC Address 760 The MAC address is out of a reserved range that cannot be used by 761 then node which is processing the address. While almost all MAC 762 addresses are valid there are a small number of reserved MAC 763 addresses. 765 5.3 Invalid ERO for UPSTREAM_LABEL Object 767 The ERO offered has discontinuities with the identified ESP- 768 VID/ESP-MAC DA path in the UPSTREAM_LABEL object. 770 5.4 Invalid ERO for LABEL_SET Object 772 The ERO offered has discontinuities with the identified ESP-VID/ESP- 773 MAC DA path in the LABEL_SET object. 775 5.5 Switch is not ESP P2MP capable 777 This error may arise only in P2MP VID Tree allocation. 779 5.6 Invalid ESP-VID in UPSTREAM_LABEL object 781 The ESP-VID in the UPSTREAM_LABEL object for the "asymmetrical ESP- 782 VID" P2MP tree did not correspond to the ESP-VID used in previous 783 transactions. 785 6. Deployment Scenarios 787 This technique of GMPLS controlled Ethernet switching is applicable 788 to all deployment scenarios considered by the design team [CCAMP- 789 ETHERNET]. 791 7. Security Considerations 792 The architecture assumes that the GMPLS controlled Ethernet subnet 793 consists of trusted devices and that the UNI ports to the domain are 794 untrusted. Care is required to ensure untrusted access to the trusted 795 domain does not occur. Where GMPLS is applied to the control of VLAN 796 only, the commonly known techniques for mitigation of Ethernet DOS 797 attacks may be required on UNI ports. 799 8. IANA Considerations 801 New values are required for signaling and error codes as indicated. 802 This section will be completed in a later version. 804 9. References 806 9.1 Normative References 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 [ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label 812 Switching Architecture and Framework", work in progress. 814 [RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label 815 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 816 Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003. 818 9.2 Informative References 820 [IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic 821 Engineering", work in progress. 823 [RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate, 824 Three-Color Marker with Efficient Handling of in-Profile Traffic", 825 IETF RFC 4115, July 2005 827 [G-8031] ITU-T Draft Recommendation G.8031, Ethernet Protection 828 Switching. 830 [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area 831 Networks, Station and Media Access Control Connectivity 832 Discovery". 834 [IEEE 802.1ag] "IEEE Draft Standard for Connectivity Fault 835 Management", work in progress. 837 [IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", work in 838 progress. 840 [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, 841 October 2005 843 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services 844 Definitions - Phase I". 846 [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services 847 Attributes Phase 1". 849 [RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching 850 (MPLS) Support of Differentiated Services" IETF RFC 3270, May 851 2002. 853 [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to 854 Multipoint TE LSPs", IETF RFC 4875, May 2007 856 [PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE) 857 Architecture", work in progress. 859 [RFC3985] Bryant, S., Pate, P. et al., "Pseudo Wire Emulation Edge- 860 to Edge (PWE3) Architecture", IETF RFC 3985, March 2005. 862 [RFC4872] Lang et.al., "RSVP-TE Extensions in support of End-to-End 863 Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery 864 ", RFC 4872, May 2007. 866 [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 867 2007. 869 [RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP 870 Tunnels, IETF RFC 3209, December 2001. 872 [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions 873 and Mechanisms for Ethernet based Networks ", work in progress. 875 [ADDRESS] Shimoto, K., Papneja, R., Rabbat, R., "Use of Addresses in 876 Generalized Multi-Protocol Label Switching (GMPLS) Networks", 877 work in progress. 879 [CCAMP-ETHERNET] Papadimitriou, D. et.al, "A Framework for 880 Generalized MPLS (GMPLS) Ethernet", internet draft, draft- 881 papadimitriou-ccamp-gmpls-ethernet-framework-00.txt, June 2005 883 10. Author's Address 885 Don Fedyk 886 Nortel Networks 887 600 Technology Park Drive 888 Billerica, MA, 01821 889 Email: dwfedyk@nortel.com 891 David Allan 892 Nortel Networks 893 3500 Carling Ave. 894 Ottawa, Ontario, CANADA 895 Email: dallan@nortel.com 897 Himanshu Shah 898 Ciena 899 35 Nagog Park, 900 Acton, MA 01720 901 Email: hshah@ciena.com 903 Nabil Bitar 904 Verizon, 905 40 Sylvan Rd., 906 Waltham, MA 02451 907 Email: nabil.n.bitar@verizon.com 909 Attila Takacs 910 Ericsson 911 1. Laborc u. 912 Budapest, HUNGARY 1037 913 Email: attila.takacs@ericsson.com 915 Diego Caviglia 916 Ericsson 917 Via Negrone 1/A 918 Genoa, Italy 16153 919 Email: diego.caviglia@ericsson.com 921 Alan McGuire 922 BT Group PLC 923 OP6 Polaris House, 924 Adastral Park, Martlesham Heath, 925 Ipswich, Suffolk, IP5 3RE, UK 926 Email: alan.mcguire@bt.com 928 Nurit Sprecher 929 Nokia Siemens Networks, 930 GmbH & Co. KG 931 COO RTP IE Fixed 932 3 Hanagar St. Neve Ne'eman B, 933 45241 Hod Hasharon, Israel 934 Email: nurit.sprecher@nsn.com 936 Lou Berger 937 LabN Consulting, L.L.C. 938 Phone: +1-301-468-9228 939 Email: lberger@labn.net 941 11. Intellectual Property Statement 943 The IETF takes no position regarding the validity or scope of any 944 Intellectual Property Rights or other rights that might be claimed to 945 pertain to the implementation or use of the technology described in 946 this document or the extent to which any license under such rights 947 might or might not be available; nor does it represent that it has 948 made any independent effort to identify any such rights. Information 949 on the procedures with respect to rights in RFC documents can be 950 found in BCP 78 and BCP 79. 952 Copies of IPR disclosures made to the IETF Secretariat and any 953 assurances of licenses to be made available, or the result of an 954 attempt made to obtain a general license or permission for the use of 955 such proprietary rights by implementers or users of this 956 specification can be obtained from the IETF on-line IPR repository at 957 http://www.ietf.org/ipr. 959 The IETF invites any interested party to bring to its attention any 960 copyrights, patents or patent applications, or other proprietary 961 rights that may cover technology that may be required to implement 962 this standard. Please address the information to the IETF at 963 ietf-ipr@ietf.org. 965 12. Disclaimer of Validity 967 "This document and the information contained herein are provided on 968 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 969 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 970 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 971 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 972 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 973 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 974 PARTICULAR PURPOSE. 976 13. Copyright Statement 978 Copyright (C) The IETF Trust (2007). 980 This document is subject to the rights, licenses and restrictions 981 contained in BCP 78, and except as set forth therein, the authors 982 retain all their rights. 984 14. Acknowledgments 986 The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen 987 Shew and Sandra Ballarte for their contributions to this document. 989 Rational and mechanism for PBB_TE Ethernet Forwarding 991 This appendix describes work currently being undertaken in the 801.1 992 PBB-TE [IEEE 802.1Qay] project. This information is for reference 993 only and will be removed when 802.1Qay becomes mature. This text 994 captures some of the original rational for changing Ethernet 995 forwarding. The PBB-TE [IEEE 802.1Qay] document simply documents the 996 PBB-TE data plane. 998 Ethernet as specified today is a complete system consisting of a 999 data plane and a number of control plane functions. Spanning tree, 1000 data plane flooding and MAC learning combine to populate forwarding 1001 tables and produce resilient any-to-any behavior in a bridged 1002 network. 1004 Ethernet consists of a very simple and reliable data plane that has 1005 been optimized and mass produced. By simply disabling some Ethernet 1006 control plane functionality, it is possible to employ alternative 1007 control planes and obtain different forwarding behaviors. 1009 Customer Provider Provider 1010 Bridge/ Bridge Backbone 1011 Bridge 1013 C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID 1014 S-VID-----------802.1ad------------S-VID 1015 B-MAC---802.1ah---B-MAC 1016 B-VID---802.1ah---B-VID 1018 Figure 1 802.1 MAC/VLAN Hierarchy 1020 Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 1021 are defining a separation of Ethernet functions permitting an 1022 increasing degree of provider control. The result is that the 1023 Ethernet service to the customer appears the same, yet the provider 1024 components and behaviors have become decoupled from the customer 1025 presentation and the provider has gained control of all VID/DMAC 1026 endpoints. 1028 One example of this is the 802.1ah work in hierarchical bridging 1029 whereby customer Ethernet frames are fully encapsulated into a 1030 provider Ethernet frame, isolating the customer VID/DMAC space from 1031 the provider VID/DMAC space. In this case, the forwarding behavior 1032 of the of the Backbone MAC in the provider's network is as per 1033 802.1Q. 1035 The Ethernet data plane provides protocol multiplexing via the ether 1036 type field which allows encapsulation of different protocols 1037 supporting various applications. More recently, the Carrier Ethernet 1038 effort has created provider and customer separation that enables 1039 another level of multiplexing. This in effect creates provider MAC 1040 endpoints in the Ethernet sub-network controlled by the provider. In 1041 this appendix we concentrate on the provider solutions and therefore 1042 subsequent references to VLAN, VID and MAC refer to those under 1043 provider control, be it in the backbone layer of 802.1ah. The 1044 Customer Ethernet service is the same native Ethernet service with 1045 functions such as bridging, learning and spanning trees all 1046 functioning over the provider infrastructure. 1048 Bridging offers a simple solution for any-to-any connectivity within 1049 a VLAN partition via the Spanning tree, flooding and MAC learning. 1050 Spanning tree provides some unnecessary capabilities for P2P 1051 services and since the Spanning tree must interconnect all MACs with 1052 the same VLAN IDs (VIDs) it consumes a scarce resource (VIDs). In 1053 this document we present that it is easier to modify Ethernet to 1054 scale engineered P2P services and this is the approach we take with 1055 PBB-TE. (The number of usable VLANs IDs in conventional Ethernet 1056 bridging is constrained to 4094, therefore the use of VLAN only 1057 configuration for all forwarding could be limited for some 1058 applications where large number of P2P connections are required.) 1059 This is because in Ethernet, each Spanning tree is associated with 1060 one or more VLAN IDs. Also Port membership in a VLAN is configured 1061 which controls the connectivity of all MAC interfaces participating 1062 in the VLAN. 1064 The roots for PBB-TE capability exist in the Ethernet management 1065 plane. The management of Ethernet switches provides for static 1066 configuration of Ethernet forwarding. The Ethernet Control plane 1067 allows for forwarding entries that are statically provisioned or 1068 configured. In this document we are expanding the meaning of 1069 "configured" from an Ethernet Control plane sense to mean either 1070 provisioned, or controlled by GMPLS. The connectivity aspects of 1071 Ethernet forwarding is based upon VLANs and MAC addresses. In other 1072 words the VLAN + DMAC are an Ethernet Label that can be looked up at 1073 each switch to determine the egress link (or links in the case of 1074 link aggregation). 1076 This is a finer granularity than traditional VLAN networks since 1077 each P2P connection is independent. By provisioning MAC addresses 1078 independently of Spanning tree in a domain, both the VLAN and the 1079 VLAN/DMAC configured forwarding can be exploited. This greatly 1080 extends the scalability of what can be achieved in a pure Ethernet 1081 bridged sub network. 1083 The global/domain wide uniqueness and semantics of MAC addresses as 1084 interface names or multicast group addresses has been preserved. (In 1085 Ethernet overlap of MAC addresses across VLANs is allowed. However 1086 for PBB-TE MAC addresses should be unique for all VLANs assigned to 1087 PBB-TE. With PBB-TE it is an operational choice if the operator uses 1088 PBT-TE labels out of the global MAC address space or the local admin 1089 space.) We then redefine the semantics associated with 1090 administration and uses of VLAN values for the case of explicit 1091 forwarding such as you get with statically configured Ethernet. 1093 The PBB_TE is Ethernet Forwarding where configured VID + DMAC 1094 provide a forwarding table that is consistent with existing PBB and 1095 Ethernet switching. At the same time it provides domain wide labels 1096 that can be controlled by a common GMPLS control plane. This makes 1097 GMPLS control and resource management procedures ideal to create 1098 paths. The outcome is that the GMPLS control plane can be utilized 1099 to set up the following atomic modes of connectivity: 1101 1) P2P connectivity and MP2P multiplexed connectivity based 1102 on configuration of unicast MAC addresses in conjunction 1103 with a VID from a set of pre-configured VIDs. 1104 2) P2MP connectivity based on configuration of multicast MAC 1105 address in conjunction with a VID from a set of pre- 1106 configured VIDs. This corresponds to (Source, Group) or 1107 (S,G) multicast. 1108 3) P2MP connectivity based on configuration of VID port 1109 membership. This corresponds to (S,*) or (*,*) multicast 1110 (where * represents the extent of the VLAN Tree). 1111 4) MP2MP connectivity based on configuration of VID port 1112 membership (P2MP trees in which leaves are permitted to 1113 communicate). Although, we caution that this approach 1114 poses resilience issues (discussed in section 5) and hence 1115 is not recommended. 1117 The modes above are not completely distinct. Some modes involve 1118 combinations of P2P connections in one direction and MP connectivity 1119 in the other direction. Also, more than one mode may be combined in 1120 a single GMPLS transaction. One example is the incremental addition 1121 of a leaf to a P2MP tree with a corresponding MP2P return path 1122 (analogous to a root initiated join). 1124 In order to realize the above connectivity modes, a partition of the 1125 VLAN IDs from traditional Ethernet needs to be established. The 1126 partition allows for a pool of Ethernet labels for manual 1127 configuration and/or for GMPLS control plane usage. The VID 1128 partition actually consists of a "configured VID/DMAC range" and 1129 "configured VID range" since in some instances the label is a VID/ 1130 DMAC and sometimes the label is a VID/Multicast DMAC. 1132 A 1. Overview of configuration of VID/DMAC tuples 1134 Statically configured MAC and VID entries are a complete 60 bit 1135 lookup. The basic operation of an Ethernet switch is filtering on 1136 VID and forwarding on DMAC. The resulting operation is the same as 1137 performing a full 60 bit lookup (VID (12) + DMAC(48)) for P2P 1138 operations, only requiring uniqueness of the full 60 bits for 1139 forwarding to resolve correctly. This is an Ethernet domain wide 1140 label. 1142 Complete route freedom is available for each domain wide label (60 1143 bit VLAN/DMAC tuple) and the ability to define multiple connectivity 1144 instances or paths per DMAC for each of the VIDs in the "configured 1145 VID/DMAC range". 1147 The semantics of MAC addresses are preserved, and simply broaden the 1148 potential interpretations of VLAN ID from spanning tree identifier 1149 to topology instance identifier. Therefore, operation of both 1150 standard bridging and configured unicast/multicast operation is 1151 available side by side. The VID space is partitioned and a range of 1152 VIDs is allocated(say 'n' VIDs) as only significant when combined 1153 with a configured DMAC address (the aforementioned "configured 1154 VID/DMAC range" of VIDs). A VID in that range is considered as an 1155 individual connectivity instance identifier for a configured P2P 1156 path terminating at the associated DMAC address. Or in the case of 1157 P2MP, a P2MP multicast tree corresponding to the destination 1158 multicast group address. Note that this is destination based 1159 forwarding consistent with how Ethernet works today. The only thing 1160 changed is the mechanism of populating the forwarding tables. 1162 Ethernet MAC addresses are typically globally unique since the 48 1163 bits consists of 24 bit Organizational Unique Identifier and a 24 1164 bit serial number. There is also a bit set aside for Multicast and 1165 for local addresses out of the OUI field. We define domain wide as 1166 within a single organization, or more strictly within a single 1167 network within an organization. For provider MAC addresses that will 1168 only be used in a domain wide sense we can define MAC addresses out 1169 of a either the local space or the global space since they both have 1170 the domain wide unique property. When used in the context of GMPLS, 1171 it is useful to think of a domain wide pool of labels where switches 1172 are assigned a set of MAC addresses. These labels are assigned 1173 traffic that terminates on the respective switches. 1175 It is also worth noting that unique identification of source in the 1176 form of the ESP-MAC SA is carried e2e in the MAC header. So although 1177 we have a 60 bit domain wide unique label, it may be shared by 1178 multiple sources and the full connection identifier for an 1179 individual P2P instance is 108 bits (ESP-MAC SA, VID and DMAC). The 1180 ESP-MAC SA is not referenced in forwarding operations but it would 1181 allow additional context for tracing or other operations at the end 1182 of the path. 1184 For multicast group addresses, the VID/DMAC concatenated label can 1185 be distributed by the source but label assignment (as it encodes 1186 global multicast group information) requires coordination within the 1187 GMPLS controlled domain. 1189 As mentioned earlier, this technique results in a single unique and 1190 invariant identifier, in our case a VID/DMAC label associated with 1191 the path termination or the multicast group. There can be up to 1192 4094 labels to any one MAC address. However, practically, from 1193 Ethernet network wide aspect; there would be only a handful of VLANs 1194 allocated for PBB-TE. In addition, all 48 bits are not completely 1195 available for the MAC addresses. One way to maximize the space is 1196 to use the locally administered space. This is a large number for 1197 P2P applications and even larger when shared or multiplexed 1198 forwarding is leveraged. In practice, most network scaling 1199 requirements may be met via allocation of only a small portion of 1200 the VID space, to the configured VID/DMAC range. The result is 1201 minimal impact on the number of remaining bridging VLANs that can be 1202 concurrently supported. 1204 In order to use this unique 60 bit label, we disable the normal 1205 mechanisms by which Ethernet populates the forwarding table for the 1206 allocated range of VIDs. When a path is setup, for a specific label 1207 across a contiguous sequence of Ethernet switches, a unidirectional 1208 connection is the functional building block for an Ethernet Label 1209 Switched path (Eth-LSP). 1211 In P2P mode a bidirectional path is composed of two unidirectional 1212 paths that are created with a single RSVP-TE session. The technique 1213 does not require the VID to be common in both directions. However, 1214 keeping in line with regular Ethernet these paths are symmetrical 1215 such that a single bidirectional connection is composed of two 1216 unidirectional paths that have common routing (i.e. traverse the 1217 same switches and links) in the network and hence share the same 1218 fate. 1220 In P2MP mode a bidirectional path is composed of a unidirectional 1221 multicast tree and a number of P2P paths from the leaves of the tree 1222 to the root. Similarly these paths may have bandwidth and must have 1223 common routing as in the P2P case. 1225 There are a few modifications required to standard Ethernet to make 1226 this approach robust: 1228 1. In Standard Ethernet, discontinuities in forwarding table 1229 configuration in the path of a connection will normally result in 1230 packets being flooded as "unknown". For configured operation (e.g. 1231 PBB-TE), unknown addresses are indicative of a fault or 1232 configuration error and the flooding of these is undesirable in 1233 meshed topologies. Therefore flooding of "unknown" unicast/multicast 1234 MAC addresses must be disabled for the "configured VID/DMAC range". 1236 2. MAC learning is not required, and although it will not interfere 1237 with management/control population of the forwarding tables, since 1238 static entries are not overridden, it appears prudent to explicitly 1239 disable MAC learning for the configured VID/DMAC and VID range. 1241 3. Spanning tree is disabled for the allocated VID/DMAC and VID 1242 range and port blocking must be disabled to achieve complete 1243 configured route freedom. As noted earlier, it is a control plane 1244 requirement to ensure configured paths are loop free. 1246 All three modifications described above are within the scope of 1247 acceptable configuration options defined in IEEE802.1Q 1248 specification. 1250 A 2. Overview of configuration of VID port membership 1252 Procedures almost identical to that for configuration of P2P 1253 VID/DMAC tuples can also be used for the incremental configuration 1254 of P2MP VID trees. For the replication of forwarding in this case 1255 the label is common for the multipoint destinations. The MAC field 1256 is set to multicast address and is common to the multicast 1257 community. The VID is a distinguisher common to the multicast 1258 community. The signaling procedures are as per that for [RFC4875]. 1260 Since VID translation is relatively new and is not a ubiquitously 1261 deployed capability, we consider a VID to be a domain global value. 1262 Therefore, the VID value to be used by the originating switch may be 1263 assigned by management and nominally is required to be invariant 1264 across the network. The ability to indicate permissibility of 1265 translation will be addressed in a future version of the document. 1267 A procedure known as "asymmetrical VID" may be employed to constrain 1268 connectivity (root to leaves, and leaves to root only) when switches 1269 also support shared VLAN learning (or SVL). This would be consistent 1270 with the root as a point of failure. 1272 A 3. OAM Aspects 1274 Robustness is enhanced with the addition of data plane OAM to 1275 provide both fault and performance management. 1277 For the configured VID/DMAC unicast mode of behavior, the hardware 1278 performs unicast packet forwarding of known MAC addresses exactly as 1279 Ethernet currently operates. The OAM currently defined, [802.1ag and 1280 Y.1731] can also be reused without modification of the protocols. 1281 However currently if the VID for PBB-TE is different in each 1282 direction some modification of the OAM may be required. 1284 An additional benefit of domain wide path identifiers, for data 1285 plane forwarding, is the tight coupling of the 60 bit unique 1286 connection ID (VID/DMAC) and the associated OAM packets. It is a 1287 simple matter to determine a broken path or misdirected packet since 1288 the unique connection ID cannot be altered on the Eth-LSP. This is 1289 in fact one of the most powerful and unique aspects of the domain 1290 wide label for any type of rapid diagnosis of the data plane faults. 1291 It is also independent of the control plane so it works equally well 1292 for provisioned or GMPLS controlled paths. 1294 Bidirectional transactions (e.g. ETH-LB) and reverse direction 1295 transactions MAY have a different VID for each direction. PBB-TE is 1296 specifying this aspect of CFM. 1298 For configured multicast VID/DMAC mode, the current versions of 1299 802.1ag and Y.1731] make no representation as to how PDUs which are 1300 not using unicast addresses or which use OAM reserved multicast 1301 addresses are handled. Therefore this specification makes no 1302 representation as to whether such trees can be instrumented. 1304 When configured VID mode of operation is used PBB-TE can be forced 1305 to use the same VID in both directions, emulating the current 1306 Ethernet data plane and the OAM functions as defined in the current 1307 versions of 802.1ag and Y.1731 can be used with no restriction. 1309 A 4. QOS Aspects 1311 Ethernet VLAN tags include priority tagging in the form of the 1312 802.1p priority bits. When combined with configuration of the paths 1313 via management or control plane, priority tagging produces the 1314 Ethernet equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged 1315 Ethernet PDUs self-identify the required queuing discipline 1316 independent of the configured connectivity. 1318 It should be noted that the consequence of this is that there is a 1319 common COS model across the different modes of configured operation 1320 specified in this document. 1322 The actual QOS objects required for signaling will be in a future 1323 version of this memo. 1325 A 5. Resiliency Aspects 1327 A 5.1. E2E Path protection 1329 One plus One(1+1) protection is a primary LSP with a disjoint 1330 dedicated back up LSP. One for one (1:1) protection is a primary LSP 1331 with a disjoint backup LSP that may share resources with other LSPs. 1332 One plus One and One for One Automatic Protection Switching 1333 strategies are supported. Such schemes offer: 1334 1) Engineered disjoint protection paths that can protect both 1335 directions of traffic. 1336 2) Fast switchover due to tunable OAM mechanisms. 1337 3) Revertive path capability when primary paths are restored. 1338 4) Option for redialing paths under failure. 1340 Specific procedures for establishment of protection paths and 1341 associating paths into "protection groups" are TBD. 1343 Note that E2E path protection is able to respond to failures with a 1344 number of configurable intervals. The loss of CCM OAM frames in the 1345 data plane can trigger paths to switch. In the case of CCM OAM 1346 frames, the detection time is typically 3.5 times the CCM interval 1347 plus the propagation delay from the fault.