Originally designed for Local Area Networks, Ethernet is moving toward Metro Area Networks, and is now considered by many carriers as a future transport network technology. This paper studies the latest standardization effort toward a control plane for carrier-grade Ethernet, in the light of carrier-grade Ethernet data plane and management plane.
Ethernet as a transport network technology is a very attractive solution for carriers. The Metro Ethernet Forum (MEF) provides good material about why this is the case. Because most business offices traffic originates from Ethernet LANs anyway, it simply makes sense for Ethernet to extend its reach inside the metropolitan network. Ethernet is a widely deployed solution, making Ethernet equipments relatively cheaper to buy and to operate, thus allowing CAPEX and OPEX savings, compared to other predominant metropolitan technologies such as ATM or SONET/SDH. Last, but not least, Ethernet is a packet-switching technology that provides the right flexibility to carry the ever-growing IP-based traffic. The existing SONET/SDH infrastructure for instance, lacks the ability to provide the right granularity or to easily adapt to traffic bursts - although the VCAT/LCAS capabilities implemented in latest MSPPs somehow mitigate this statement.
On the other hand, until recently, Ethernet itself did not meet transport-network requirements. Among the most significant issues were:
In the past few years however, several standardization bodies have tackled these issues, in order to provide transport-network capabilities to Ethernet, thus allowing for a kind of "connection-oriented" Ethernet data plane. Significant efforts have also been carried out for the associated management plane, and the control plane specification is now under way.
IEEE has addressed most of Ethernet Provider Bridges limitations with its Provider Backbone Bridges (PBB, 802.1ah) specification. It removes the scalability issues of Provider Bridges, and opens the way for the support of protection mechanisms or end-to-end QOS. This is mainly achieved by encapsulating customer frames into service-provider frames (PBB is also referred to as “MAC-in-MAC”), and introducing a 24-bits service identifier: the former alleviate the needs for core switches to learn about customers’ MAC addresses, while the latter removes the 4094 VLAN identifiers limit.
IEEE has also significantly improved Ethernet OAM with the Configuration and Fault Management functions defined in IEEE 802.1ag. Last, IEEE has amended PBB in order to allow for admission control, explicit routing and therefore end-to-end QOS: this specification, PBB-TE, is defined in IEEE 802.1Qay. The control of such networks is intended to be supported by other control planes than the native Ethernet one.
Shortest-Path Bridging, IEEE 802.1aq, is another specification proposing to control a 802.1Q network or a PBB network, using the IS-IS routing protocol (with small extensions). Although it does not provide Traffic Engineering capabilities, it does address the sub-optimal path issue of STP-based native Ethernet control plane, by allowing the computation of, and packets forwarding along shortest-path-trees across the networks.
MEF has focused its works on the definition of Ethernet services (see MEF.6 and MEF.10 specifications). Two service types are defined: E-LINE provides point-to-point Ethernet Virtual Connection (EVC), and E-LAN provides multipoint-to-multipoint EVCs – an EVC is defined as an association between two UNIs (User Network Interfaces). Several services are then defined: EPL and EVPL services are based on the E-LINE service type; Transparent LAN Service (TLS) is based on the E-LAN service type.
MEF.11 defines different UNIs: MEF UNI Type 3 proposes a true control plane based UNI.
ITU-T has recently published a set of recommendations for an Ethernet layer network. Using the ITU-T modeling framework , G.8010 defines two layers: an Ethernet MAC layer, whose links are supported by either the Ethernet PHY layer (IEEE 802.3), or by other transport layer networks (such as ATM, SDH, MPLS …). G.8011 and G.8011.x provide Ethernet services definitions such as EPL, EVPL, EVPLAN, etc., and G.8012 specifies UNI and NNI interfaces. ITU-T is also specifying protection mechanisms for the Ethernet layer, similar to those defined for other transport layers, such as linear-protection switching (G.8031) and ring-protection switching (G.8032).
Last but not least, ITU-T specified OAM capabilities for Ethernet: Y.1731 addresses fault and performance management, and therefore can be seen as a superset of IEEE 802.1ag. About fault detection, fault localization and tracing functions, both recommendations are mostly aligned.
As a summary, ITU-T has shaped Ethernet into a layer network that looks familiar to those carriers used to manage and control transport networks. It is worth noting that the ITU-T has done a similar work for MPLS, referred to as T-MPLS2 , and that T-MPLS can be used to carry Ethernet flows, and therefore can fulfill carrier-grade Ethernet requirements.
At this time, ITU-T has not yet started any work about how its ASON framework could provide a control plane for Ethernet PBB-TE.
OIF (Optical Interworking Forum) has been focusing on promoting interoperability between ASON-compliant equipment vendors. Although it started with the control plane of SONET/SDH networks, OIF is now supporting other switching technologies such as OTN and Ethernet. The latest OIF UNI 2.0 implementation agreement supports EPL and EVPL services across the UNI; which is proposed as a candidate to fulfill MEF UNI Type 3 requirements.
During the ECOC 2007 exhibition, OIF demonstrated the support of EPL services at the UNI interface, while the multi-carriers/multi-vendors service provider networks was supporting such services at E-NNI interfaces, over VCAT/LCAS and SONET/SDH layers.
IETF is addressing carrier-grade Ethernet issues in multiple ways. The pseudowires emulation (PWE3) and L2VPN working groups have defined an infrastructure, and all protocol extensions to control it, in order to carry Ethernet flows over a packet-switched network such as MPLS. Those Ethernet flows are carried over traffic-engineered tunnels. This core network may for instance inter-connect Provider Bridges networks, while addressing carrier-grade requirements such as scalability, end-to-end QOS and protection.
The CCAMP working group is discussing a draft, extending GMPLS overlay model3 , which fulfills MEF UNI Type 3, and MEF.6 and ITU-T G.8011 services – only point-to-point services are considered. Another draft proposes signaling extensions to provide such services across a GMPLS-controlled network – again, only point-to-point services are considered.
With the advent of IEEE Provider Backbone Bridges and PBB-TE, the CCAMP working group is now working on extensions to its GMPLS protocols suite, in order to provide a control plane for PBB-TE.
The IETF PWE3 and L2VPN working groups have designed pseudo-wires in order to carry Ethernet flows over a traffic engineered network, such as MPLS. Pseudo-wires are one hop point-to-point or point-to-multipoint LSPs, tunneled into TE-LSPs setup across a Packet-Switched Network (PSN), as shown in Figure 1. The TE-LSP provides for end-to-end QOS and may be recoverable (protection or rerouting). A control plane is used to setup both pseudo-wires and the TE tunnels.
Typically, the RSVP-TE protocol allows TE-LSPs signaling across an MPLS network. The LDP protocol allows exchanging a label between two Provider-Edges (PEs) for each direction - a pseudo-wire requires two LDP LSPs. Because multiple pseudo-wires may be tunneled within the same TE-LSP, the label essentially acts as a de-multiplexer identifier. Pseudo-wire encapsulation across an MPLS PSN is depicted in Figure 2:
The BGP protocol may be used to provide peer PE and VPN membership discovery.
A VPLS service can be achieved by connecting all PEs with a full mesh of pseudo-wires. Multi-segments pseudo-wires are being standardized by the IETF to address cases where a full-mesh would not scale well.
Multi-segments pseudo-wires are also a way to address inter-provider issues, and heterogeneous PSN networks. The IETF PWE3 working group has also addressed some OAM requirements for pseudo-wires. It allows pseudo-wire connectivity verification and diagnostic. Ideally, it should be possible to translate such information into the client Ethernet layer, to allow end-to-end OAM capabilities.
The ITU-T Ethernet over Transport (EoT) recommendations pursues a similar approach, although more generic. The traffic-engineered network may be any transport network, typically T-MPLS, SONET/SDH or OTN. Multi-segment support is implicit in transport network models considered by ITU-T.
IEEE 802.1ah, or Provider Backbone Bridges (PBB), has removed 802.1ad Provider Bridges scalability limitations. A typical PBB network is shown in Figure 3:
An Ethernet frame entering a PBB network (PBBN) is encapsulated into another Ethernet frame – PBB is called “MAC-in-MAC”, as shown in Figure 4:
The source and destination MAC addresses of the outer header belongs to the PBBN, therefore only backbone MAC addresses (B-MACs) need to be learned by core bridges (BCBs), which really behave as 802.1ad Provider Bridges. The outer header also carries a 24-bit service identifier, which removes the 4094 VLAN ID limits of 802.1ad Provider Bridges: Entering the PBB network, this service identifier (I-SID) is translated to a Backbone VLAN identifier (B-VID) – multiple I-SIDs can map to the same B-VID. At the outer edge of the PBB network, this service identifier may be translated from/to the (S-)VLAN identifiers used at the PBBN edges (the same service identifier can map to different VLAN identifiers on each PBBN edge). Therefore, while the VLAN identifier was used both for customer/service identification and switching segregation in 802.1ad networks, PBB respectively uses the I-SID and the B-VID for each purpose.
IEEE 802.1Qay, or PBB-TE, allows Provider Backbone Bridge networks to be controlled by an external control plane, which may provide traffic engineering capabilities (such as end-to-end QOS, protection and/or rerouting mechanisms …). The encapsulating frame is switched across the PBB network, along an Ethernet Switched Path (ESP). A candidate for such a control plane is GMPLS, and the IETF CCAMP working group has been recently re-chartered to tackle this work. Added to PBB scalability properties, a GMPLS-controlled PBB-TE network fulfills carrier-grade Ethernet requirements.
Because GMPLS requires that the nodes, links and reachability information under its control are assigned identifiers whose format complies with the one of IPv4 or IPv6 addresses, the current IETF draft proposes to assign TE Router identifiers to PBB-TE bridges, and either IP addresses or identifiers (if unnumbered) to PNPs – Provider Network Ports are BCBs ports, or BEB ports facing the PBB network. The draft considers MAC addresses for ESP endpoints, but does not propose any solution for advertising them throughout the network (e.g. for path computation); those ESP endpoints are PIP/CBP ports. The GMPLS label itself would carry a Backbone VLAN Identifier (B-VID) and a destination Backbone MAC address (B-MAC DA). Together with the source Backbone MAC address (B-MAC SA), they identify an ESP. It is worth noting that this label is domain wide and thus does not change along the ESP path – no label-switching occurs.
Although rejected by the standards community, another approach has been implemented, relying on an MPLS control plane and a data plane that performs VLAN switching – in a much similar way MPLS is switching labels. The proponents of such an approach claim that it would better fit the original MPLS architecture.
Ethernet is moving from enterprise networks toward carriers’ metropolitan networks and even further down the core network. Such a move requires Ethernet data, management and control plane adaptations or extensions to fulfill carriers’ requirements. Several standardization bodies have tackled the issue of providing a carrier-grade Ethernet, relying on a (G)MPLS based control plane. Those proposals complete, or overlap, sometimes even compete, with each other, leaving equipment manufacturers and carriers facing the issue of choosing the solution that best match their requirements and existing network infrastructure.
Marben Products has been a leading telecommunication software editor for more than 25 years. Its portfolio includes transport plane agnostic GMPLS and PCE protocol stack implementations and emulators. Marben Products is committed to offer products that conform to the latest standards, and is a member of OIF and ITU-T SG15, as well as involved in IETF work.
_________________________________________
1 G.805, G.809, G.800 2 The IETF recently identified some issues with T-MPLS, potentially preventing MPLS and T-MPLS data planes Interworking. IETF and ITU-T have agreed to jointly work in resolving such issues. The outcome of such work is now referred to as MPLS-TP – MPLS Transport Profile. 3 RFC 4208
