Network Working Group Don Fedyk, David Allan, Nortel Internet Draft Greg Sunderwood, Bell Canada Category: Standards Track Himanshu Shah, Ciena Nabil Bitar, Verizon Attila Takacs, Diego Caviglia, Ericsson Alan McGuire, BT Nurit Sprecher, Nokia Siemens Networks Lou Berger, LabN May 2007 GMPLS control of Ethernet draft-fedyk-gmpls-ethernet-pbb-te-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in August 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Carrier Grade Ethernet transport solutions require the capability of flexible service provisioning and fast protection switching. Currently, Ethernet is being extended in IEEE to meet the scalability needs of transport networks. Fedyk et.al Expires November 2007 Page 1 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt The IETF specified GMPLS to control transport networks. To enable integration of Ethernet based transport solutions the extension of GMPLS control plane for Ethernet is of value. This memo describes how a GMPLS control plane may be applied to the Provider Backbone Bridges Traffic Engineering (PBB-TE 802.1Qay) amendment to 802.1Q and how GMPLS can be used to configure VLAN-aware Ethernet switches in order to establish Ethernet P2P and P2MP MAC switched paths and P2P/P2MP VID based trees. This document assumes any standard changes to IEEE data planes will be undertaken only in the IEEE. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Document History This document has under gone name changes to follow the standardization of Provider Backbone Bridges and the Traffic engineering capability. The original draft was: draft-fedyk-gmpls-ethernet-ivl-00.txt. This draft was renamed to reflect the Provider Backbone Transport (PBT) nomenclature to: draft-fedyk-gmpls-ethernet-pbt-00.txt This draft was then edited to: draft-fedyk-gmpls-ethernet-pbt-01.txt The standardization of PBT is called Provider Backbone Bridges Traffic Engineering (PBB-TE) and we have once again aligned the documents naming to this present draft. draft-fedyk-gmpls-ethernet-pbb-te-00.txt This is the second revision of this draft with editing to clarify the document and the addition of co-authors. draft-fedyk-gmpls-ethernet-pbb-te-01.txt Fedyk et al. Expires November 2007 Page 2 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt Table of Contents 1. Introduction...................................................5 2. Terminology....................................................5 3. GMPLS Control of PBB-TE Path creation and maintenance..........6 3.1 Using a GMPLS Control Plane for Ethernet.....................7 3.2 Control Plane Network........................................8 3.3 P2P Signaling................................................8 3.4 Ethernet Service.............................................9 3.5 GMPLS Link Management........................................9 3.6 GMPLS Routing...............................................10 3.7 Path Selection..............................................10 3.7.1 Combinations of GMPLS Features.............................11 3.8 Addresses, Interfaces, and Labels...........................11 4. Specific Procedures...........................................13 4.1 P2P connections.............................................13 4.1.1 Shared Forwarding..........................................14 4.1.2 P2P connections with shared forwarding.....................15 4.1.3 Dynamic P2P symmetry with shared forwarding................15 4.1.4 Planned P2P symmetry.......................................15 4.1.5 P2P Path Maintenance.......................................16 4.2 P2MP Signaling..............................................16 4.3 P2MP VID/DMAC Connections...................................16 4.3.1 Setup procedures...........................................16 4.3.2 Maintenance Procedures.....................................17 4.4 Ethernet Label..............................................17 4.5 OAM MEP ID and MA ID synchronization........................18 4.6 Protection Paths............................................18 5. Error conditions..............................................19 5.1 Invalid VID value for configured VID/DMAC range.............19 5.2 Invalid VID value for configured VID range..................19 5.3 Invalid MAC Address.........................................19 5.4 Invalid ERO for UPSTREAM_LABEL Object.......................19 5.5 Invalid ERO for LABEL_SET Object............................19 5.6 Switch is not SVL capable...................................19 5.7 Invalid VID in UPSTREAM_LABEL object........................19 6. Deployment Scenarios..........................................19 7. Security Considerations.......................................20 8. IANA Considerations...........................................20 9. References....................................................20 9.1 Normative References........................................20 9.2 Informative References......................................20 10. Author's Address............................................22 11. Intellectual Property Statement.............................23 12. Disclaimer of Validity......................................23 13. Copyright Statement.........................................23 14. Acknowledgments.............................................24 Appendix A.......................................................25 A 1. Aspects of configuring Ethernet Forwarding.................25 A 2. Overview of configuration of VID/DMAC tuples...............27 A 3. Overview of configuration of VID port membership...........30 A 4. OAM Aspects................................................30 A 5. QOS Aspects................................................31 Fedyk et al. Expires November 2007 Page 3 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt A 6. Resiliency Aspects.........................................31 A 6.1. E2E Path protection......................................31 Fedyk et al. Expires November 2007 Page 4 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt 1. Introduction Ethernet switches are increasing in capability. As a consequence the role of Ethernet is rapidly expanding in networks that were the domain of other technologies such as SONET/SDH TDM and ATM. The question of how Ethernet will evolve and what capabilities it can offer in these areas is still under development. The various standards bodies are responding to the strong demands by the operators for making the Ethernet a carrier-class transport solution. Following is a short list of major activities in different standards organization, - IEEE 802.1Q is amending VLAN-aware bridges to handle scalability and service provisioning needs of the operators - IEEE 802.1ad, Provider Bridges and 802.1ah Provider Backbone Bridges are developed to provide hierarchical solution to handle scalability - IEEE 802.1ag, Connectivity Fault Management is improving bridge functionalities to provide fault management and performance monitoring for Ethernet networks - ITU-T Y.1731 is specifying extensive OAM capabilities for Ethernet - G.8031 is defining protection switching in Ethernet based on CFM's continuity check protocol. This standard provides p2p VLAN-based Ethernet paths configurations at head and tail end for working and protection traffic. - IEEE 802.1 is embarking on Traffic Engineered Ethernet paths in the Provider Backbone Bridged network (PBB-TE 802.1Qay) based on managed objects that can be statically configured and no changes to Ethernet data plane. The main purpose of this document is to specify a GMPLS based control plane for PBB-TE. It should be noted that the behavior of Ethernet for the specified VLAN range is a new behavior and does not default to conventional Ethernet forwarding at any time. 2. Terminology In addition to well understood GMPLS terms, this memo uses terminology from IEEE 802.1 and introduces a few new terms: B-MAC Backbone MAC B-VID Backbone VLAN ID B-VLAN Backbone VLAN CCM Continuity Check Message COS Class of Service CLI Command Line Interface C-MAC Customer MAC Fedyk et al. Expires November 2007 Page 5 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt C-VID Customer VLAN ID C-VLAN Customer VLAN DMAC Destination MAC Address LBM Loopback Message LBR Loopback Reply LLDP Link Layer Discovery Protocol LMM Loss Measurement Message LMR Loss Measurement Reply MAC Media Access Control MP2MP Multipoint to multipoint PBB Provider Backbone Bridges PBB-TE Provider Backbone Bridges Traffic Engineering P2P Point to Point P2MP Point to Multipoint QOS Quality of Service SMAC Source MAC Address S-VID Service VLAN ID SVL Shared VLAN Learning VID VLAN ID VLAN Virtual LAN 3. GMPLS Control of PBB-TE Path creation and maintenance PBB-TE is an Ethernet connection oriented technology, being specified in the IEEE, which can be controlled by configuration of static filtering entries [see Appendix A]. PBB-TE paths are created switch by switch by simple configuration of Ethernet logical ports and assignment of PBB-TE labels. We term a PBB-TE path as a form of Ethernet LSP (Eth-LSP). PBB-TE paths may be configured by command line interface (CLI) on the switches or coordinated from a management system. This memo proposes GMPLS as a mechanism to automate set-up tear down, protection and recovery of PBB-TE paths. The advantages of using GMPLS or Network management system over simple manual provisioning are: - Reduction in number of configuration commands - Improvement in the coordination of commands that are required to establish and maintain an ETH-LSP - Capability to automate the dynamic modification of parameters - On-net/off-net path computations - Automatic reaction to network changes without manual intervention - Protection coordination The advantages of using GMPLS control plane over any provisioning are: - Single ended provisioning - Interoperable signaling between multi-vendor networks - Fast restoration of for some types of network failures Fedyk et al. Expires November 2007 Page 6 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt PBB-TE uses the Ethernet data plane in its native form. When configuring a PBB-TE path with GMPLS, the DMAC and VID are carried in a generalized label object and are assigned hop by hop but are invariant within a domain. This is similar to GMPLS operation in transparent optical networks. PBB-TE paths are composed of unidirectional label paths that are paired together in a single setup forming a symmetrically routed bi-directional Eth-LSP. The DMAC is domain wide unique in the two LSPs. The VID value may be the same or different in each direction as it is only used, from a data plane perspective, to identify the path co-jointly with the DMAC. As with other technologies controlled by GMPLS, PBB-TE paths are created first as an explicit route object (ERO) and data plane labels are assigned from the available label pool at the destination switch. As a result, each PBB-TE label is a domain wide unique label, with a unique VID + DMAC, for each direction. Several attributes may be associated with an Eth-LSP, including: - bandwidth requirements of the path. - priority level; - preemption characteristics; - protection/resiliency requirements; - routing policy, such as a pinned route or explicit route; - policing requirements On a node, the bandwidth can be used, to set committed information rate and peak information, and policies based on either under- subscription or over subscription. Note GMPLS currently does not support asymmetrical attributes in each direction for a bidirectional LSP. It has been proposed to modify GMPLS to allow asymmetric bandwidth in a single setup. [ASYM] 3.1 Using a GMPLS Control Plane for Ethernet GMPLS [RFC3945] has been defined to control SDH/SONET and optical switches for the purpose of managing SONET/SDH and optical paths. GMPLS signaling is well suited to setup paths with labels but it does require an IP control plane and an IP management plane but does not require the presence of any IP data plane. In many Ethernet deployment situations, the addition of a complete GMPLS control plane may be excessive for the switch technology or the network application. For this reason we consider partial application of GMPLS whereby either complete functionality is applied to a subset of the switches and/or partial functionality is applied to some or all switches. For discussion purposes, we decompose the problem of applying GMPLS into the functions of Signaling, Routing, Link Management and Path Selection where Path Selection is subordinated to the presence of Topology information. It is possible to use some functions of GMPLS alone or in partial Fedyk et al. Expires November 2007 Page 7 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt combinations. In most cases using all functions of GMPLS incurs less operational overhead than any partial combinations. 3.2 Control Plane Network In order to have a GMPLS control plane, an IP control plane is required. The control plane must include signaling; a link management function and typically also includes an IGP with TE extension and a path computation function. One way to implement this is with an IGP that views each switch as a terminated IP adjacency. This IGP is not required to be a distinct routed subnet for the purpose of carrying IP bearer traffic. In other words IP traffic and a simple routing table are available for the control plane but there is no requirement for a high performance IP data plane. This IP control plane can be provided as a separate independent network (out of band) or integrated with the Ethernet switches. For example, when the IP control plane is a separate network, it may be provided as a Layer 2 connected LAN where the Ethernet switches are connected via a bridged network or HUB. It may also be provided by an external network that provides IP connectivity but in this case, the control topology of the GMPLS/Ethernet switches is independent of the topology of the physical data plane network. Another option is to have the IP control plane integrated with the switches by a bridged VLAN that uses the Data bearing channels of the network between adjacent nodes. In this case a hop by hop Ethernet header is required with special processing for the IP control packets at each switch. This ties the fate of the controlled paths and the IP control plane links, which is not unlike the situation with MPLS networks or even some GMPLS optical networks. 3.3 P2P Signaling GMPLS signaling is well suited to the application of PBB-TE on Ethernet switches. GMPLS signaling [RFC3471] uses either numbered or unnumbered links where the link is either explicitly IP addressed or associated with a node's router ID. If LMP [RFC4204] is used, the creation of these unnumbered interfaces can be automated. If LMP is not used there is an additional provisioning requirement to add GMPLS link identifiers. For large-scale implementations LMP would be beneficial. As mentioned earlier, the primary benefit of signaling is the control of a path from an endpoint. GMPLS can be used to create bidirectional or unidirectional paths, bidirectional paths being the preferred mode of operation for numerous reasons (OAM consistency etc.). In this document we only consider paths that share the same route/resources/fate both for bidirectional P2P and bidirectional P2MP services. Signaling enables the ability to dynamically establish a path from one end of the connection. The signaled path may be completely static and not change for the duration of the service. However, Fedyk et al. Expires November 2007 Page 8 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt Signaling also has the capability to dynamically adjust the path in a coordinated fashion after the path has been established. The range of signaling options from static to dynamic are under operator control. Signaling also improves multi-vendor interoperability over simple management since the signaling is standard for either the static or the dynamic case. 3.4 Ethernet Service Ethernet Switched Paths that are setup either by configuration or signaling can be used to provide an Ethernet service to customers of the Ethernet network. The Metro Ethernet Forum has defined some services in MEF.6 (e.g., Ethernet Private Line), and these are also aligned with ITU-T G.8011-x Recommendations. Of particular interest are the bandwidth profile parameters in MEF.10 and whose associated bandwidth profile algorithm are based on [RFC4115] [RFC3270]. Consideration should be given to supporting these in any signaling extensions for Ethernet LSPs. This will be addressed in a future version of this specification. 3.5 GMPLS Link Management Link discovery is one of the building blocks of GMPLS. It is also a capability that has been specified for Ethernet in IEEE 802.1AB. However the 802.1AB capability is an optional feature and is not necessarily operated before the Link is operational it primarily supports the management plane. The benefits of running link discovery in large systems are significant. Link discovery may reduce configuration and reduce the possibility of undetected errors in configuration as well as exposing misconnections. LMP and 802.1AB are relatively independent. The LMP capability should be sufficient to remove the need for 802.1AB but 802.1 AB can be run in parallel or independently if desired. LMP also has Fault Management capabilities that overlap with [IEEE 802.1ag] and [Y.1731]. It is recommended that LMP not be used for Fault management and instead the native Ethernet methods be used. See Figure 3. Fedyk et al. Expires November 2007 Page 9 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt +-------------+ +-------------+ | +---------+ | | +---------+ | | | | | | | | |GMPLS | | LMP |-|<------>|-| LMP | |Link Property Correlation | | (opt) | |IP | | (opt) | |Bundling | | | | | | | | | +---------+ | | +---------+ | | +---------+ | | +---------+ | | | | | | | | | | | 802.1AB |-|<------>|-| 802.1AB | |P2P | | (opt) | |Ethernet| | (opt) | |link identifiers | | | | | | | | | +---------+ | | +---------+ | | +---------+ | | +---------+ | | | | | | | | |End to End -----|-| 802.1ag |-|<------>|-| 802.1ag |-|------- | | Y.1731 | |Ethernet| | Y.1731 | |Fault Management | | | | | | | |Performance Management | +---------+ | | +---------+ | +-------------+ +-------------+ Switch 1 link Switch 2 Figure 3 Logical Link Management Options 3.6 GMPLS Routing GMPLS routing [RFC4202] is IP routing with the opaque TLV extensions for the purpose of carrying around GMPLS TE information. The TE information is populated with TE resources from coordinated with LMP or from configuration if LMP is not available. The bandwidth resources of the links are tracked as Eth-LSPs are set up. Interfaces supporting the switching of Eth-LSPs are identified using the 802_1 (IANA) Interface Switching Capabilities. GMPLS Routing is an optional piece but it is highly valuable in maintaining topology and distributing the TE database for path management and dynamic path computation. 3.7 Path Selection There has been a lot of recent activity in the area of path computation [PATH-COMP] and selection. Originally MPLS and GMPLS path computation was performed locally in a TE database of a router. While this is non-optimal for situations where bandwidth is highly managed, it was acceptable when a few paths were required in a primarily connectionless environment; if a large number of coordinated paths are required, it is advantageous to have a more sophisticated path computation engine capable of optimizing the path routing of a sub network. The path computation could take the form of paths being computed either on a management station with local computation for rerouting or more sophisticated path computation servers. Fedyk et al. Expires November 2007 Page 10 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt Eth-LSPs may be supported using any path selection or computation mechanism. As is the case with any GMPLS path selection function, and common to all path selection mechanisms, the path selection process should take into consideration Switching Capabilities and Encoding advertised for a particular interface. 3.7.1 Combinations of GMPLS Features The combinations of LMP, Routing, Signaling and Path computation can be all supported on a switch or a subset of GMPLS features can be supported. Signaling is the minimal function that might be supported on a small switch. The ability to process Signaling messages with an ERO may be all that is desired on an end point. In this case the path computation would be performed off network. Routing for GMPLS is the next important function since it provides the forwarding of signaling functions and transport of TE information. There is no requirement to provide full IP routing for data traffic, only hop by hop routing for the control plane. However it is possible to design switches without routing that could proxy their routing to other larger switches. In the proxied case, there would be little difference in the routing database but the small switches would not have to perform routing operations. The information for the proxied routing might be configured or it might be data filled by an automated procedure. No new protocols are envisioned for the case where routing is proxied. LMP is optional. The primary benefit of LMP in addition to 802.1AB is LMP's capability to optimize routing information for the purpose of link bundling on large switches. LMP has the capability to compress the information required to represent a large number of parallel resources automatically and reduce the amount of configuration. 3.8 Addresses, Interfaces, and Labels This specification uses an addressing scheme and a label space for the ingress/egress connection; the hierarchical TE Router ID/Interface ID and the Ethernet VID/DMAC tuple or VID/Multicast MAC as a label space. This draft is intended to be consistent with GMPLS addressing [ADDRESS]. Fedyk et al. Expires November 2007 Page 11 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt TE Router ID TE Router ID | (TE Link) | V | V N=named port +----+ | +-----+ | | | label=VID/DMAC | | | PB | V label=VID/MMAC | | -----N N----------------------------N PBB N---------- | | |(MAC)| \ | | / | Customer +----+ /+-----+ Facing PBB-TE Transit Provider MAC PBB-TE edge Ports Switch Switch Figure 4 Ethernet/GMPLS Addressing & Label Space Depending on how the service is defined and set up one or more of these identifiers may be used for actual setup. An Ethernet port name is common to configured VID/DMAC, configured VID and bridging modes of operation. For a GMPLS based system, the TE Router ID/logical port is the logical signaling identifier for the control plane via which Ethernet layer label bindings are solicited. In order to create a P2P path an association must be made between the ingress and egress node. The actual label distributed via signaling and instantiated in the switch forwarding tables identifies the upstream and downstream egress VID/DMAC of the PBB-TE path (see Figure 4). GMPLS uses un-numbered identifiers in the form of 32 bit numbers which are in the IP address notation but are not IP addresses. The provider MAC port addresses are exchanged by the LLDP and by LMP if supported. However these identifiers are merely for link control and legacy Ethernet support and have local link scope. Actual label assignment is performed by the signaling initiator and terminator. A particular port on a provider network switch would have: - A VID/DMAC - A 32 bit IPv4 Switch address plus a 32 bit interface Identifier - One (or more) Mnemonic String Identifiers This multiple naming convention leaves the issue of resolving the set given one of the port identifiers. On a particular node, mapping is relatively straightforward. The preferred solution to this is to use the TE Router ID for signaling resolution. In so doing, the problem of setting up a path is reduced to figuring out what switch supports an egress MAC address and then finding the corresponding TE Router ID and performing all signaling and routing with respect to the TE Router ID. There are several options to achieve this: - Provisioning - Auto discovery protocols that carry MAC address Fedyk et al. Expires November 2007 Page 12 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt - Augmenting Routing TE with MAC Addresses - Name Servers with identifier/address registration The specific procedures will be clarified in a subsequent version of this document. 4. Specific Procedures 4.1 P2P connections The Data Plane for Ethernet MUST have three key fields: VID, DMAC and SMAC. A connection instance is uniquely identified, in the data plane, by the DMAC, the VID and the SMAC for the purpose of the provider network terminations. From a GMPLS control plane point of view an Ethernet LSP MAY also be identified as any other LSP using the 5-tuple [Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID, Extended_Tunnel_ID]. The VID and DMAC tuple identifies the forwarding multiplex at transit switches and a simple degenerate form of the multiplex is a single P2P connection. This results in unique labels end to end. The data streams MAY merge, the forwarding entries MAY be shared but the headers are still unique allowing the connection to be de-multiplexed downstream. On the initiating and terminating nodes, a function administers the VIDs associated with the SMAC and DMAC respectively. PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. Therefore in PBB-TE, the packet SMAC and DMAC pair is same in the forwarding path and the associated reverse path except they are flipped in the reverse direction. To initiate a bidirectional VID/DMAC P2P or P2MP path, the initiator of the PATH message uses procedures outlined in [RFC3473] possibly augmented with [RFC4875], it: 1) Sets the LSP encoding type to Ethernet. 2) Sets the LSP switching type to 802_1 [IANA to define]. 3) Sets the GPID to service type [IANA to define]. 4) Sets the UPSTREAM_LABEL to the VID/SMAC tuple where the VID is administered from the configured VID/DMAC range. 5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of VID/DMAC. Intermediate and egress node processing is not modified by this document, i.e., is per [RFC3473] and, in the case of P2MP, as extended in [RFC4875]. Note, as previously stated intermediate nodes supporting the 802_1 switching type may not modify LABEL values. Fedyk et al. Expires November 2007 Page 13 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt The VID/SMAC tuple contained in the UPSTREAM_LABEL is used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction. This behavior is inferred from the switching type which is 802_1 [IANA to define].The port derived from the RSVP_HOP object and the VID and DMAC included in the label constitute the static entry. At the destination, a VID is allocated in the local MAC range for the DMAC and the VID/DMAC tuple is passed in a LABEL object in the RESV message. As with the Path message, intermediate node processing is per [RFC3473] and [RFC4875], and the LABEL object is passed on unchanged, upstream. The VID/DMAC tuple contained in the LABEL Object is installed in the forwarding table as a static forwarding entry at each hop. This creates a bidirectional path as the PATH and RESV messages follow the same path. 4.1.1 Shared Forwarding One capability of a connectionless Ethernet data plane is to reuse destination forwarding entries for packets from any source within a VLAN to a destination. When setting up P2P PBB-TE connections for multiple sources sharing a common destination this capability MAY be preserved provided certain requirements are met. We refer to this capability as Shared Forwarding. Shared forwarding is invoked based on policy when conditions are met. It is a local decision by label allocation at each end. Shared forwarding has no impact on the actual paths setup, but it allows the reduction of forwarding entries. Shared forwarding paths are identical to independently routed paths with the exception that they share the same labels. To achieve shared forwarding, a Path computation engine should ensure the ERO is consistent with an existing path for the shared segments. If a path satisfies the consistency check, the upstream end of the signaling may chose to share an existing VID/DMAC for the upstream traffic with an existing Eth-LSP. The criteria for shared forwarding is the Eth-LSPs must share the same destination port and the paths of the Eth-LSP share one or more hops consecutively. Once the paths converge they must remain converged. If no existing path has this behavior when a new path is being created the new path will be created without sharing either by using another VID or another DMAC or both. In other words, shared forwarding is possible when paths share segments either from the source or the destination. There is no requirement that the paths share reservations or other attributes. For the source, the UPSTREAM_LABEL is chosen to be the same as an existing path that shares the ERO for some number of hops. Similarly for the destination, shared forwarding is possible when an existing path that shares segments with the new paths ERO, viewed from the destination switch. The downstream label in this case is chosen to be the same as the existing path. In this manner shared forwarding is a function that is controlled primarily by policy and Fedyk et al. Expires November 2007 Page 14 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt in combination with the local label allocation at the end points of the path. 4.1.2 P2P connections with shared forwarding The VID/DMAC MAY be considered to be a shared forwarding identifier or label for a multiplex consisting of some number of P2P connections distinctly identified by the MAC VID/DMAC/SMAC tuple. In some ways this is analogous to an LDP label merge but in the shared forwarding case only the forwarding entry is reused. Resources can continue to be allocated per LSP. VLAN tagged Ethernet packets include priority marking. Priority bits MAY be used to indicate class of Service (COS) and drop priority. Thus, traffic from multiple COSs could be multiplexed on the same Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are made based on the p-bits. This means that the queue selection can be done based on a per flow (i.e., Eth-LSP + priority) basis and is decoupled from the actual steering of the packet at any given node. A switch terminating an Eth-LSP will frequently have more than one suitable candidate path and it may choose to share a forwarding entry (common VID/DMAC, unique SMAC). It is a local decision of how this is performed but the best choice is a path that maximizes the shared forwarding. The concept of bandwidth management still applies equally well with shared forwarding. As an example consider a PBB-TE edge switch that terminates an Ethernet LSP with the following attributes: bandwidth B1, DMAC D, SMAC S1, VID V. A request to establish an additional Ethernet LSP with attributes (bandwidth B2, DMAC D, SMAC S2, VID V) can be accepted provided there is sufficient link capacity remaining. 4.1.3 Dynamic P2P symmetry with shared forwarding Similar to how a destination switch MAY select a VID/DMAC from the set of existing shared forwarding multiplexes rooted at the destination node, the originating switch MAY also do so for the reverse path. Once the initial ERO has been computed and the set of existing Ethernet LSPs that include the target DMAC have been pruned, the originating switch may select the optimal (by whatever criteria) existing shared forwarding multiplex for the new destination to merge with and offer its own VID/DMAC tuple for itself as a destination. 4.1.4 Planned P2P symmetry Normally the originating switch will not have knowledge of the set of shared forwarding paths rooted on the destination node. Use of a Path Computation Server or other planning style of tool with more complete knowledge of the network configuration may wish to impose pre-selection of shared forwarding multiplexes to use for both directions. In this scenario the originating switch uses the Fedyk et al. Expires November 2007 Page 15 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt LABEL_SET and UPSTREAM_LABEL objects to indicate complete selection of the shared forwarding multiplexes at both ends. This may also result in the establishment of a new VID/DMAC path as the LABEL_SET object may legitimately refer to a path that does not yet exist. 4.1.5 P2P Path Maintenance Make before break procedures can be employed to modify the characteristics of a P2P Ethernet LSP. As described in [RFC3209], the LSP ID in the sender template is updated as the new path is signaled. The procedures (including those for shared forwarding) are identical to those employed in establishing a new LSP, with the extended tunnel ID in the signaling exchange ensuring that double booking of the associated resources does not occur. Where individual paths in a protection group are modified, signaling procedures may be combined with Protection Switching (PS) coordination to administratively force PS switching operations such that modifications are only ever performed on the protection path. 4.2 P2MP Signaling To initiate a P2MP VID path the initiator of the PATH message uses procedures outlined in [RFC3473] and [RFC4875]. A P2MP tree consists of a VID or Multicast tree in the forward direction (from root to leaves) and a set of P2P paths running on identical paths from Tree to root in the reverse direction. The result is a composite path with VID/DMAC labels with a single Multicast DMAC in the forward direction and a symmetric unidirectional VID/DMAC label in the reverse direction: 1-4) Same points as P2P paths previously specified. 5) Sets the downstream label as the multicast VID/DMAC. 6) VID translation may optionally be permitted on a local basis between two switches by a downstream switch replying with a VID/DMAC other than the LABEL_SET. The upstream switch then sets a VID translation on the port associated with the label to allow VID translation. This flexibility allows the tree to be constructed with out having to worry about colliding with another tree using the same VID. 4.3 P2MP VID/DMAC Connections 4.3.1 Setup procedures The group DMAC is administered from a central pool of multicast addresses and the VLAN selected from the configured VID/DMAC range. The P2MP tree is constructed via incremental addition of leaves to the tree in signaling exchange where the root is the originating switch (as per (RFC4875). The multicast VID/DMAC is encoded in the Fedyk et al. Expires November 2007 Page 16 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt LABEL_SET (as a member of one) object using the Ethernet label encoding. Where a return path is required the unicast MAC corresponding to the originating interface and a VID selected from the configured VID/DMAC range is encoded as an Ethernet label in the UPSTREAM_LABEL object. 4.3.2 Maintenance Procedures Maintenance and modification to a P2MP tree can be achieved by a number of means. The preferred technique is to modify existing VLAN configuration vs. assignment of a new label and completely constructing a new tree. Make before break on a live tree reusing existing label assignments requires a 1:1 or 1+1 construct. The protection switch state of the traffic is forced on the working tree and locked (PS not allowed) while the backup tree is modified. Explicit path tear of leaves to be modified is required to ensure no loops are left behind as artifacts of tree modification. Once modifications are complete, a forced switch to the backup tree occurs and the original tree may be similarly modified. This also suggests that 1+1 or 1:1 resilience can be achieved for P2MP trees for any single failure (switch on any failure and use restoration techniques to repair the failed tree). 4.4 Ethernet Label The Ethernet label is a new generalized label with a suggested format of: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| VLAN ID | MAC (highest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The semantics of the new label type for a non-zero MAC address is that that the label is passed unchanged. This label is a domain wide label. This has similarity to the way in which a wavelength label is handled at an intermediate switch that cannot perform wavelength conversion, and is described in [RFC3473]. The option to allow just a VLAN to be signaled without a MAC (A zero MAC) is for cases where a single VLAN is desired to be signaled for P2MP trees in cases where a multicast MAC is not desired. These domain wide labels are allocated to switches that control the assignment of labels. There are two options for Ethernet MAC based domain wide unique labels. One option is to allocate the DMACs from globally unique addresses assigned to the either the switch Fedyk et al. Expires November 2007 Page 17 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt manufacturer or the owner. The other option is to use DMACs out of the local admin space and ensue these labels are unique within the domain. This local DMAC space does not have to be globally unique because the labels are only valid within a single provider domain. In the case of local label allocation there is less administrative overhead to allocate labels. However when using configuration, a tool would have to perform a consistency check to make sure that label terminations were unique. When using GMPLS signaling it is assumed a unique pool of labels would be assigned to each switch. The DMAC addresses are domain wide unique and so is the combination of VID/DMAC. It is intended that the VID/DMAC be only used by one destination. However, should an error occur and a somehow a duplicate label be assigned to one or more destination switches GMPLS signaling procedures would allow the first assignment of the label and prevent any duplicate label from colliding. If a collision occurs an alarm would be generated. In fact some of these procedures have been defined in GMPLS control of photonic networks where a lambda may exist as a form of domain wide label. 4.5 OAM MEP ID and MA ID synchronization The Maintenance end point IDs (MEP IDs) and maintenance association IDs for the switched path endpoints can be synchronized using the ETH-MCC (maintenance communication channel) transaction set once the switched path has been established. MEPs are located at the endpoints of the Ethernet LSP. Typical configuration associated with a MEP is Maintenance Domain Name, Short Maintenance Association Name, and MA Level, MEP ID, and CCM transmission rate (when ETH-CC functionality is desired). As part of the synchronization, it is verified that the Maintenance Domain Name, Short Maintenance Association Name, MA Level, and CCM transmission rate are the same. It is also determined that MEP IDs are unique for each MEP. Besides the unicast CCM functionality, the PBB-TE MEPs can also offer the LBM/LBR and LMM/LMR functionalities for on-demand connectivity verification and loss measurement purposes. 4.6 Protection Paths When protection is used for path recovery it is required to associate the working and protection paths into a protection group. This is achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION and PROTECTION objects. Protection may be used for P2P VID/DMAC, P2MP VID/DMAC and P2P/P2MP VID configured modes of operation. The 'P' bit in the protection object indicates the role (working or protection) of the LSP currently being signaled. If the initiating switch wishes to use G.8031 [G-8031] data plane protection switching coordination (vs. control plane notifications), Fedyk et al. Expires November 2007 Page 18 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt it sets the N bit to 1 in the protection object. This must be consistently applied for all paths associated as a protection group. If the terminating switch does not support G.8031, the error "Admission Control Failure/Unsupported Notification Type" is used. 5. Error conditions The following errors have been identified as being unique to these procedures and in addition to those already defined. This will be addressed in a proper IANA considerations section in a future version of the document: 5.1 Invalid VID value for configured VID/DMAC range The originator of the error is not configured to use the VID value in conjunction with GMPLS signaling of VID/DMAC tuples. This may be any switch along the path. 5.2 Invalid VID value for configured VID range 5.3 Invalid MAC Address The MAC address is out of a reserved range that cannot be used by then node which is processing the address. While almost all MAC addresses are valid there are a small number of reserved MAC addresses. 5.4 Invalid ERO for UPSTREAM_LABEL Object The ERO offered has discontinuities with the identified VID/DMAC path in the UPSTREAM_LABEL object. 5.5 Invalid ERO for LABEL_SET Object The ERO offered has discontinuities with the identified VID/DMAC path in the LABEL_SET object. 5.6 Switch is not SVL capable This error may arise only in P2MP VID Tree allocation. 5.7 Invalid VID in UPSTREAM_LABEL object The VID in the UPSTREAM_LABEL object for the "asymmetrical VID" P2MP tree did not correspond to the VID used in previous transactions. 6. Deployment Scenarios Fedyk et al. Expires November 2007 Page 19 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt This technique of GMPLS controlled Ethernet switching is applicable to all deployment scenarios considered by the design team [CCAMP- ETHERNET]. 7. Security Considerations The architecture assumes that the GMPLS controlled Ethernet subnet consists of trusted devices and that the UNI ports to the domain are untrusted. Care is required to ensure untrusted access to the trusted domain does not occur. Where GMPLS is applied to the control of VLAN only, the commonly known techniques for mitigation of Ethernet DOS attacks may be required on UNI ports. 8. IANA Considerations New values are required for signaling and error codes as indicated. This section will be completed in a later version. 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CCAMP-ETHERNET] Papadimitriou, D. et.al, "A Framework for Generalized MPLS (GMPLS) Ethernet", internet draft, draft- papadimitriou-ccamp-gmpls-ethernet-framework-00.txt, June 2005 [RFC3471] Berger, L. (editor), "Generalized MPLS Signaling Functional Description", January 2003, RFC3471. [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized MPLS", RFC 4202, October 2005 [RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003. 9.2 Informative References [RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", IETF RFC 4115, July 2005 [G-8031] ITU-T Draft Recommendation G.8031, Ethernet Protection Switching. [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3495. Fedyk et al. Expires November 2007 Page 20 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery". [IEEE 802.1ag] "IEEE Draft Standard for Connectivity Fault Management", work in progress. [IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", work in progress. [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, October 2005 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services Definitions - Phase I". [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services Attributes Phase 1". [RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services" IETF RFC 3270, May 2002. [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", IETF RFC 4875, May 2007 [MYERS] Myers et.al. "Rethinking the service model, scaling Ethernet to a million nodes", http://100x100network.org/papers/myers- hotnets2004.pdf. [PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) Architecture", work in progress. [PWoPBT] Allan et.al., "Pseudo Wires over Provider Backbone Transport", work in progress. [RFC3985] Bryant, S., Pate, P. et al., "Pseudo Wire Emulation Edge- to Edge (PWE3) Architecture", IETF RFC 3985, March 2005. [RFC4872] Lang et.al., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery ", RFC 4872, May 2007. [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 2007. [RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, December 2001. [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions and Mechanisms for Ethernet based Networks ", work in progress. Fedyk et al. Expires November 2007 Page 21 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt [ADDRESS] Shimoto, K., Papneja, R., Rabbat, R., "Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks", work in progress. [ASYM] Berger, L. et al., "GMPLS Asymmetric Bandwidth Bidirectional LSPs", work in progress. 10. Author's Address Don Fedyk Phone: +1-978-288-3041 Nortel Networks Email: dwfedyk@nortel.com 600 Technology Park Drive Billerica, MA, 01821 David Allan Phone: +1-613-763-6362 Nortel Networks Email: dallan@nortel.com 3500 Carling Ave. Ottawa, Ontario, CANADA Greg Sunderwood Phone: +1-604-648-7770 Bell Canada Email: greg.sunderwood@gt.ca Suite 1500, 1066 West Hastings Street Vancouver, BC, CANADA V6E 2X1 Himanshu Shah Phone: 978-489-2196 Ciena Email: hshah@ciena.com 35 Nagog Park, Acton, MA 01720 Nabil Bitar Phone: (781) 466-2161 Verizon, Email: nabil.n.bitar@verizon.com 40 Sylvan Rd., Waltham, MA 02451 Attila Takacs Email: attila.takacs@ericsson.com Ericsson 1. Laborc u. Budapest, HUNGARY 1037 Diego Caviglia Email: diego.caviglia@ericsson.com Ericsson Via Negrone 1/A Genoa, Italy 16153 Alan McGuire Phone: +44 1473 645010 BT Group PLC Email: alan.mcguire@bt.com OP6 Polaris House, Adastral Park, Martlesham Heath, Ipswich, Suffolk, IP5 3RE, UK Fedyk et al. Expires November 2007 Page 22 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt Nurit Sprecher Phone: +972 9 7751229 Nokia Siemens Networks, Email: nurit.sprecher@nsn.com GmbH & Co. KG COO RTP IE Fixed 3 Hanagar St. Neve Ne'eman B, 45241 Hod Hasharon, Israel Lou Berger Phone: +1-301-468-9228 LabN Consulting, L.L.C. Email: lberger@labn.net 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 12. Disclaimer of Validity "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Copyright Statement Copyright (C) The IETF Trust (2007). Fedyk et al. Expires November 2007 Page 23 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 14. Acknowledgments The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen Shew and Sandra Ballarte for their extensive contributions to this document. Fedyk et al. Expires November 2007 Page 24 Appendix A A 1. Aspects of configuring Ethernet Forwarding Ethernet as specified today is a complete system consisting of a data plane and a number of control plane functions. Spanning tree, data plane flooding and MAC learning combine to populate forwarding tables and produce resilient any-to-any behavior in a bridged network. Ethernet consists of a very simple and reliable data plane that has been optimized and mass produced. By simply disabling some Ethernet control plane functionality, it is possible to employ alternative control planes and obtain different forwarding behaviors. Customer Provider Provider Bridge/ Bridge Backbone Bridge C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID S-VID-----------802.1ad------------S-VID B-MAC---802.1ah---B-MAC B-VID---802.1ah---B-VID Figure 1 802.1 MAC/VLAN Hierarchy Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 are defining a separation of Ethernet functions permitting an increasing degree of provider control. The result is that the Ethernet service to the customer appears the same, yet the provider components and behaviors have become decoupled from the customer presentation and the provider has gained control of all VID/DMAC endpoints. One example of this is the 802.1ah work in hierarchical bridging whereby customer Ethernet frames are fully encapsulated into a provider Ethernet frame, isolating the customer VID/DMAC space from the provider VID/DMAC space. Another example would be the direct transport of pseudo wires PWs ["Dry Martini" or PW over layer 2] where the Ethernet network fulfills the role of the PSN in the PWE architecture [PWoPBT]. In both cases the behavior of the provider's network is as per 802.1Q. The Ethernet data plane provides protocol multiplexing via the ether type field which allows encapsulation of different protocols supporting various applications. More recently, the Carrier Ethernet effort has created provider and customer separation that enables another level of multiplexing. This in effect creates provider MAC endpoints in the Ethernet sub-network controlled by the provider. In this document we concentrate on the provider solutions and therefore subsequent references to VLAN, VID and MAC refer to those under provider control, be it in the backbone layer of 802.1ah or the PSN Fedyk et.al Expires November 2007 Page 25 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt layer of "Dry Martini". Also in the case where the Customer service is Ethernet, the Customer Ethernet service is the same native Ethernet service with functions such as bridging, learning and spanning trees all functioning over the provider infrastructure. With the provider in exclusive control of their Ethernet sub-network and all customer specific state pushed to the edges of that sub- network, the ability of the provider to exploit latent Ethernet behavior is facilitated. One key capability sought is to overcome limitations, such as single spanning tree path for all traffic within a VLAN, imposed by bridging (see [MYERS] for a discussion). Bridging offers a simple solution for any-to-any connectivity within a VLAN partition via the Spanning tree, flooding and MAC learning. Spanning tree provides some unnecessary capabilities for P2P services and since the Spanning tree must interconnect all MACs with the same VLAN IDs (VIDs) it consumes a scarce resource (VIDs). In this document we present that it is easier to modify Ethernet to scale engineered P2P services and this is the approach we take with PBB-TE and PW over Ethernet. (The number of usable VLANs IDs in conventional Ethernet bridging is constrained to 4094, therefore the use of VLAN only configuration for all forwarding could be limited for some applications where large number of P2P connections are required.) This is because in Ethernet, each Spanning tree is associated with one or more VLAN IDs. Also Port membership in a VLAN is configured which controls the connectivity of all MAC interfaces participating in the VLAN. The roots for PBB-TE capability exist in the Ethernet management plane. The management of Ethernet switches provides for static configuration of Ethernet forwarding. The Ethernet Control plane allows for forwarding entries that are statically provisioned or configured. In this document we are expanding the meaning of "configured" from an Ethernet Control plane sense to mean either provisioned, or controlled by GMPLS. The connectivity aspects of Ethernet forwarding is based upon VLANs and MAC addresses. In other words the VLAN + DMAC are an Ethernet Label that can be looked up at each switch to determine the egress link (or links in the case of link aggregation). In this document, we discuss, Point to Point(P2P) and point to multipoint (P2MP) connections via static configuration of VLAN/DMAC tuples. (MAC-only configuration is considered a degenerate case corresponding to VLAN zero). This is a finer granularity than traditional VLAN networks since each P2P connection is independent. By provisioning MAC addresses independently of Spanning tree in a domain, both the VLAN and the VLAN/DMAC configured forwarding can be exploited. This greatly extends the scalability of what can be achieved in a pure Ethernet bridged sub network. Fedyk et al. Expires November 2007 Page 26 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt For compatibility and flexibility with existing Ethernet hardware, we preserve the global/domain wide uniqueness and semantics of MAC addresses as interface names or multicast group addresses. (In Ethernet overlap of MAC addresses across VLANs is allowed. However for PBB-TE MAC addresses should be unique for all VLANs assigned to PBB-TE. With PBB-TE it is an operational choice if the operator uses PBT-TE labels out of the global MAC address space or the local admin space.) We then redefine the semantics associated with administration and uses of VLAN values for the case of explicit forwarding such as you get with statically configured Ethernet. The result is a new architecture where configured VID + DMAC provide a forwarding table that is consistent with existing Ethernet switching. At the same time it provides domain wide labels that can be controlled by a common GMPLS control plane. This makes GMPLS control and resource management procedures ideal to create paths. The outcome is that the GMPLS control plane can be utilized to set up the following atomic modes of connectivity: 1) P2P connectivity and MP2P multiplexed connectivity based on configuration of unicast MAC addresses in conjunction with a VID from a set of pre-configured VIDs. 2) P2MP connectivity based on configuration of multicast MAC address in conjunction with a VID from a set of pre- configured VIDs. This corresponds to (Source, Group) or (S,G) multicast. 3) P2MP connectivity based on configuration of VID port membership. This corresponds to (S,*) or (*,*) multicast (where * represents the extent of the VLAN Tree). 4) MP2MP connectivity based on configuration of VID port membership (P2MP trees in which leaves are permitted to communicate). Although, we caution that this approach poses resilience issues (discussed in section 5) and hence is not recommended. The modes above are not completely distinct. Some modes involve combinations of P2P connections in one direction and MP connectivity in the other direction. Also, more than one mode may be combined in a single GMPLS transaction. One example is the incremental addition of a leaf to a P2MP tree with a corresponding MP2P return path (analogous to a root initiated join). In order to realize the above connectivity modes, a partition of the VLAN IDs from traditional Ethernet needs to be established. The partition allows for a pool of Ethernet labels for manual configuration and/or for GMPLS control plane usage. The VID partition actually consists of a "configured VID/DMAC range" and "configured VID range" since in some instances the label is a VID/DMAC and sometimes the label is a VID/Mulitcast DMAC. A 2. Overview of configuration of VID/DMAC tuples Fedyk et al. Expires November 2007 Page 27 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt Statically configured MAC and VID entries are a complete 60 bit lookup The basic operation of an Ethernet switch is filtering on VID and forwarding on DMAC. The resulting operation is the same as performing a full 60 bit lookup (VID (12) + DMAC(48)) for P2P operations, only requiring uniqueness of the full 60 bits for forwarding to resolve correctly. We can call this an Ethernet domain wide label. We have complete route freedom for each domain wide label (60 bit VLAN/DMAC tuple) and the ability to define multiple connectivity instances or paths per DMAC for each of the VIDs in the "configured VID/DMAC range". We have preserved the semantics of MAC addresses, and simply broaden the potential interpretations of VLAN ID from spanning tree identifier to topology instance identifier. Therefore, we can concurrently operate both standard bridging and configured unicast/multicast operation side by side. We partition the VID space and allocate a range of VIDs (say 'n' VIDs) as only significant when combined with a configured DMAC address (the aforementioned "configured VID/DMAC range" of VIDs). We can then consider a VID in that range as an individual connectivity instance identifier for a configured P2P path terminating at the associated DMAC address. Or in the case of P2MP, a P2MP multicast tree corresponding to the destination multicast group address. Note that this is destination based forwarding consistent with how Ethernet works today. The only thing changed is the mechanism of populating the forwarding tables. Ethernet MAC addresses are typically globally unique since the 48 bits consists of 24 bit Organizational Unique Identifier and a 24 bit serial number. There is also a bit set aside for Multicast and for local addresses out of the OUI field. We define domain wide as within a single organization, or more strictly within a single network within an organization. For provider MAC addresses that will only be used in a domain wide sense we can define MAC addresses out of a either the local space or the global space since they both have the domain wide unique property. When used in the context of GMPLS, it is useful to think of a domain wide pool of labels where switches are assigned a set of MAC addresses. These labels are assigned traffic that terminates on the respective switches. It is also worth noting that unique identification of source in the form of the SMAC is carried e2e in the MAC header. So although we have a 60 bit domain wide unique label, it may be shared by multiple sources and the full connection identifier for an individual P2P instance is 108 bits (SMAC, VID and DMAC). The SMAC is not referenced in forwarding operations but it would allow additional context for tracing or other operations at the end of the path. GMPLS signaling procedures can be designed to create the bidirectional path delegating label allocation of the combined VID/DMAC Label to the destination/source associated with the MACs Fedyk et al. Expires November 2007 Page 28 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt for each direction of unicast forwarding. Creating P2P path is a well understood control plane requirement. For multicast group addresses, the VID/DMAC concatenated label can be distributed by the source but label assignment (as it encodes global multicast group information) requires coordination within the GMPLS controlled domain. As mentioned earlier, this technique results in a single unique and invariant identifier, in our case a VID/DMAC label associated with the path termination or the multicast group. There can be up to 4094 labels to any one MAC address. However, practically, from Ethernet network wide aspect; there would be only a handful of VLANs allocated for PBB-TE. In addition, all 48 bits are not completely available for the MAC addresses. One way to maximize the space is to use the locally administered space. This is a large number for P2P applications and even larger when shared or multiplexed forwarding is leveraged. In practice, most network scaling requirements may be met via allocation of only a small portion of the VID space, to the configured VID/DMAC range. The result is minimal impact on the number of remaining bridging VLANs that can be concurrently supported. In order to use this unique 60 bit label, we disable the normal mechanisms by which Ethernet populates the forwarding table for the allocated range of VIDs. When a path is setup, for a specific label across a contiguous sequence of Ethernet switches, a unidirectional connection is the functional building block for an Ethernet Label Switched path (Eth-LSP). In P2P mode a bidirectional path is composed of two unidirectional paths that are created with a single RSVP-TE session. The technique does not require the VID to be common in both directions. However, keeping in line with regular Ethernet these paths are symmetrical such that a single bidirectional connection is composed of two unidirectional paths that have common routing (i.e. traverse the same switches and links) in the network and hence share the same fate. In P2MP mode a bidirectional path is composed of a unidirectional tree and a number of P2P paths from the leaves of the tree to the root. Similarly these paths may have bandwidth and must have common routing as in the P2P case. There are a few modifications required to standard Ethernet to make this approach robust: 1. In Standard Ethernet, discontinuities in forwarding table configuration in the path of a connection will normally result in packets being flooded as "unknown". For configured operation (e.g. PBB-TE), unknown addresses are indicative of a fault or configuration error and the flooding of these is undesirable in meshed topologies. Therefore flooding of "unknown" unicast/multicast MAC addresses must be disabled for the "configured VID/DMAC range". Fedyk et al. Expires November 2007 Page 29 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt 2. MAC learning is not required, and although it will not interfere with management/control population of the forwarding tables, since static entries are not overridden, it appears prudent to explicitly disable MAC learning for the configured VID/DMAC and VID range. 3. Spanning tree is disabled for the allocated VID/DMAC and VID range and port blocking must be disabled to achieve complete configured route freedom. As noted earlier, it is a control plane requirement to ensure configured paths are loop free. All three modifications described above are within the scope of acceptable configuration options defined in IEEE802.1Q specification. A 3. Overview of configuration of VID port membership Procedures almost identical to that for configuration of P2P VID/DMAC tuples can also be used for the incremental configuration of P2MP VID trees. For the replication of forwarding in this case the label is common for the multipoint destinations. The MAC field is set to multicast address and is common to the multicast community. The VID is a distinguisher common to the multicast community. The signaling procedures are as per that for [RFC4875]. Since VID translation is relatively new and is not a ubiquitously deployed capability, we consider a VID to be a domain global value. Therefore, the VID value to be used by the originating switch may be assigned by management and nominally is required to be invariant across the network. The ability to indicate permissibility of translation will be addressed in a future version of the document. A procedure known as "asymmetrical VID" may be employed to constrain connectivity (root to leaves, and leaves to root only) when switches also support shared VLAN learning (or SVL). This would be consistent with the root as a point of failure. A 4. OAM Aspects Robustness is enhanced with the addition of data plane OAM to provide both fault and performance management. For the configured VID/DMAC unicast mode of behavior, the hardware performs unicast packet forwarding of known MAC addresses exactly as Ethernet currently operates. The OAM currently defined, [802.1ag and Y.1731] can also be reused without modification of the protocols. However currently if the VID for PBB-TE is different in each direction some modification of the OAM may be required. An additional benefit of domain wide path identifiers, for data plane forwarding, is the tight coupling of the 60 bit unique connection ID (VID/DMAC) and the associated OAM packets. It is a Fedyk et al. Expires November 2007 Page 30 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt simple matter to determine a broken path or misdirected packet since the unique connection ID cannot be altered on the Eth-LSP. This is in fact one of the most powerful and unique aspects of the domain wide label for any type of rapid diagnosis of the data plane faults. It is also independent of the control plane so it works equally well for provisioned or GMPLS controlled paths. Bidirectional transactions (e.g. ETH-LB) and reverse direction transactions MAY have a different VID for each direction. Currently Y.1731 & 802.1ag makes no representations with respect to this. For configured multicast VID/DMAC mode, the current versions of 802.1ag and Y.1731] make no representation as to how PDUs which are not using unicast addresses or which use OAM reserved multicast addresses are handled. Therefore this specification makes no representation as to whether such trees can be instrumented. When configured VID mode of operation is used PBB-TE can be forced to use the same VID in both directions, emulating the current Ethernet data plane and the OAM functions as defined in the current versions of 802.1ag and Y.1731 can be used with no restriction. A 5. QOS Aspects Ethernet VLAN tags include priority tagging in the form of the 802.1p priority bits. When combined with configuration of the paths via management or control plane, priority tagging produces the Ethernet equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged Ethernet PDUs self-identify the required queuing discipline independent of the configured connectivity. It should be noted that the consequence of this is that there is a common COS model across the different modes of configured operation specified in this document. The actual QOS objects required for signaling will be in a future version of this memo. A 6. Resiliency Aspects A 6.1. E2E Path protection One plus One(1+1) protection is a primary LSP with a disjoint dedicated back up LSP. One for one (1:1) protection is a primary LSP with a disjoint backup LSP that may share resources with other LSPs. One plus One and One for One Automatic Protection Switching strategies are supported. Such schemes offer: 1) Engineered disjoint protection paths that can protect both directions of traffic. 2) Fast switchover due to tunable OAM mechanisms. 3) Revertive path capability when primary paths are restored. 4) Option for redialing paths under failure. Fedyk et al. Expires November 2007 Page 31 Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-01.txt Specific procedures for establishment of protection paths and associating paths into "protection groups" are TBD. Note that E2E path protection is able to respond to failures with a number of configurable intervals. The loss of CCM OAM frames in the data plane can trigger paths to switch. In the case of CCM OAM frames, the detection time is typically 3.5 times the CCM interval plus the propagation delay from the fault. Fedyk et al. Expires November 2007 Page 32