Standardizing Ethernet ServicesStandardizing Ethernet Services

How it could open the floodgates on rollouts * New service types * Infrastructure options * Who's doing what

January 9, 2004

42 Min Read
Light Reading logo in a gray background | Light Reading

Much of the success of Ethernet in local area networks stems from standardization – the fact that vendors worked together to develop truly interoperable products and, as a result, drove up volumes and drove down prices in a way that benefitted everybody.

Efforts are now under way to repeat the success in telecom networks. Moves to develop technologies that will make Ethernet services “carrier class” – notably by adding operations, administration, and maintenance (OAM) capabilities – are being accompanied by a big push to develop standards in this area.

The goal is twofold.

First, to lay down a common way of specifying Ethernet services, so that users and carrier sales staff can compare offerings using terminology that they’re familiar with. This applies to comparing Ethernet services from different carriers, and comparing them with existing services such as Frame Relay and leased lines.

Second, to give carriers the confidence to charge ahead with widespread deployment of infrastructure supporting Ethernet services; knowing that the technology is now stable enough for standards to exist, and that it probably won’t be too long before they can start reaping the benefits of an open, competitive equipment market.

This second goal is a lot more complex than it sounds, because Ethernet developments are happening on many fronts. For a kickoff, Ethernet services can be provided over all sorts of infrastructure, from Sonet/SDH to IP/MPLS and from ATM to WDM and OTN (optical transport network) equipment, using different schemes. The result is multiple combinations of protocols, each of which needs standardization. Then there’s the addition of OAM functions; and, on top of that, Ethernet itself is being improved in areas such as the scaleability of VLAN technology and the development of a fast form of the Spanning Tree algorithm, used to automatically reroute traffic around failed devices.

The bottom line is that a lot’s happening, and much of it could have a profound influence on the future of telecom services. In other words, it’s time to come to grips with what’s going on, and this report provides an easy way of doing that. Here’s a hyperlinked summary:

  • Why Standardize?
    Because Ethernet services are moving into the mainstream – and getting complicated

  • Key Ingredients
    The common elements used to define and build Ethernet services

  • Ethernet Service Types
    E-line, E-LAN, private, virtual private

  • Infrastructure Issues
    The impact of using different transport mechanisms for delivering Ethernet services

  • ITU-T Work
    How Ethernet frames will be carried over SDH, OTN, ATM, and MPLS

  • IETF Work
    Pseudowire emulation and provider-provisioned VPNs

  • Metro Ethernet Forum Work
    Focusing on the way in which services will be sold to customers

  • IEEE Work
    Provider Bridges, Fast Spanning Tree, Link Aggregation, Ethernet in the First Mile, RPR

Related Light Reading Beginner's Guides:

  • Ethernet

  • Sonet (Synchronous Optical NETwork) and SDH (Synchronous Digital Hierarchy)

  • Multiprotocol Label Switching (MPLS)

  • Asynchronous Transfer Mode (ATM)

Related Light Reading Reports:

  • Making Sonet Ethernet-Friendly

  • Resilient Packet Ring Technology

  • Interworking

  • Next-Gen Sonet

Archives of Related Light Reading Webinars:

  • Ethernet Access: The Road to Revenues

  • Ethernet Services: Service Provider Challenges

  • Ethernet Services: The Economics Behind the Myth

  • Ethernet Services: What's in it for the Enterprise?

  • Interworking: Making the transition to MPLS

  • VPLS: Ethernet Virtual Private Networks, Made Real

  • GFP Systems: Enabling the Multiservice Edge

— Scott Clavenna, Chief Analyst, Heavy Reading

In the early days of any market, there are always trailblazers willing to forego standards in order to get an early lead. They ride the hype curve, get a few customers to sign on, and start reaping the benefits.

Ethernet services have gone through that phase, and now they’re onto the next. The incumbent operators are taking an interest, and, as a result, the focus of attention has switched to standardization.

Why? For a kickoff, if an ILEC, IXC, or PTT is going to roll out Ethernet services, they want to be able to talk to their customers about it in a language that is both familiar and trustworthy.

Enterprises used to buying Frame Relay services now expect to hear about committed information rate (CIR) and excess information rate (EIR). They expect to see an SLA (service-level agreement). And if they’re looking to add Ethernet to an existing WAN service, they will also ask about interworking with their other Layer 2 services, e.g., Frame Relay or ATM. The salesman who can only say “Well, I’ve got something called ‘Etherport’ I can sell you” may find himself shown the door.

Standardizing the way services are defined should solve the problem, but that’s just for starters.

Another big issue is that Ethernet services are about to get a lot more complicated, and standardization holds out the hope of ensuring complications are kept to the minimum.

Up until now, Ethernet services have fallen into two broad categories – Ethernet private lines, running over Sonet/SDH infrastructure, or transparent LANs over best-effort switches and dark fiber. The new standards now being developed define technologies that will allow operators to start moving into the lucrative space between these two ends of the spectrum, rolling out services that are flexible in their topologies and yet support true SLAs.

All of this is more challenging than it might seem on first blush, because the new Ethernet services can run over almost any infrastructure – which has its good and bad points. As various standards bodies seek to define just what constitutes an Ethernet service they quickly encounter a morass: Is it running over SDH, ATM, IP/MPLS, PDH, WDM, or OTN? Things can get even more complicated when GFP (generic framing procedure), virtual concatenation, and LCAS (Link Capacity Adjustment Scheme) are factored in, not to mention Resilient Packet Ring Technology.

The capabilities of each of these transport methods have a significant impact on how an Ethernet service can be defined. As a result, there’s a plethora of Ethernet service names in the market that have different capabilities, depending upon which transport method and vendor’s equipment is used to implement the service. Examples include Ethernet Private Line, Ethernet Virtual Private Line, Virtual Private Wire Service, Ethernet Wire Service, Ethernet Relay Service, Ethernet Virtual Private LAN, LAN Extension Service, Transparent LAN Service, Virtual Private LAN Service, and Ethernet Private LAN.

To make matters even more complicated, Ethernet itself is evolving. Regardless of the transport media, Ethernet services have often been relegated to “best-effort” class because the Ethernet service interface was unable to differentiate between an Ethernet frame carrying, say, an email message or a voice-over-packet call. Thus, no true service multiplexing was possible, in which different services are carried over the same UNI (user network interface).

Various solutions are being proposed for this shortcoming. Ethernet classes of service (COS) can be identified via IEEE 802.1Q, user priority bits (802.1p), MPLS EXP bits, or DiffServ Codepoints, depending upon the service delivery technology used and the service offering. However, no standards exist for Ethernet traffic management to support Ethernet COS. Therefore, proprietary solutions or solutions based on other standards, such as DiffServ, have been implemented. In addition, Ethernet over RPR supports three classes of traffic for transport across a packet ring.

All in all, this is making for some interesting debates in the networking community and adding a little spice to the normally mundane process of standards-making.

Consider how this is playing out: Sonet/SDH equipment providers argue they can support Ethernet services using a mix of GFP, VCAT, LCAS, and RPR, leveraging the installed base of transmission equipment and its proven OAM and protection. Multiservice ATM switch vendors say they can add Ethernet services blades to their products that can offer Ethernet-over-ATM Transparent LAN Service (TLS) with strict guaranteed QOS, while router vendors say they can support a range of Ethernet VPNs over an IP backbone with a little help from MPLS. It’s no wonder most carriers have no single Ethernet service delivery technology. Every box in the network supports it!

The answer may not be to choose an Ethernet services implementation and stick with it. Rather, the approach proposed today is to define Ethernet services generically and let carriers decide on which service delivery technologies will be profitable for them, without cannibalizing any existing services. In this regard, Ethernet services standards go a long way in sorting out the confusion around this new service type and let carriers make informed decisions on just how to introduce them without time-consuming trial and error.

"For the service provider, Ethernet can be added as an offering at a significantly lower cost compared to a new build-out," says Cecil Christie, director of optical marketing at Cisco Systems Inc. (Nasdaq: CSCO).

"The biggest benefit to enterprises wanting to leverage Ethernet as a service interface is that the service can originate and terminate on two completely separate transport networks, such as Sonet and IP," adds Christie. "This greatly increases the available service footprint.

In this report we’ll be taking a look at how Ethernet services are being standardized, from all the angles and all the fora, including the IEEE, the ITU-T, the IETF, and the Metro Ethernet Forum (MEF). We’ll begin by first describing the payoff: a range of Ethernet services meant to provide a path out of the legacy of private lines, Frame Relay, and ATM services to a more scaleable, user-friendly global networking solution.

There is at least tacit agreement among most carriers and vendors as to what Ethernet services should ultimately look like. Various standards bodies are calling these services by different names, but they all agree that Ethernet services should range from point-to-point to multipoint services over either dedicated or shared media.

The Metro Ethernet Forum probably does the best job of describing Ethernet services generically, in useful terminology. The MEF’s basic model of Ethernet services is based on three key ingredients:

  • The customer equipment (CE), either a switch (IEEE 802.1Q bridge) or a router.

  • An Ethernet User Network Interface (UNI), based on a standard IEEE 802.3 Ethernet PHY and MAC, from 10 Mbit/s to 10 Gbit/s. This could be an RJ45 socket on a service provider’s Ethernet switch, or an RJ45 plug on a service provider’s Ethernet cable.

    This Ethernet UNI is of particular importance, as it is based on the ubiquitous Ethernet port, familiar to enterprise and service provider alike. The Ethernet UNI will support multiple service classes, with different levels of QOS and bandwidth profiles, allowing operators to introduce new services to customers without requiring new hardware.

    As Ethernet services expand, an Ethernet NNI (network-to-network interface) will also be standardized so that different service providers can cooperate to support a single customer’s Ethernet service. The boundary between service providers will be mediated by the NNI.

  • The Metro Ethernet Network (MEN), which may use different transport and service delivery technologies, such as Sonet/SDH, WDM, RPR, MAC-in-MAC, Q-in-Q (VLAN stacking), or MPLS. The value of the MEN is its inherent scaleability and flexibility in supporting a wide range of services cost-effectively, compared to TDM, Frame Relay, or ATM.

    This metro Ethernet cloud can be divided into at least two areas – the provider edge and the core.

    The provider edge is the interesting part, as it is made up of the systems that present the Ethernet service to the customer. The provider edge can be a single system, such as an edge router or an MSPP with Ethernet ports, or it can be distributed – built from a small customer-located box managed and owned by the service provider that feeds a larger box back at the CO. The two work together to provide the necessary features for an Ethernet service presentation.

    The core is basically charged with transport and connectivity, so can be comprised of Sonet/SDH, OTN, DWDM, ATM, or IP/MPLS systems, depending on which service the operator is supporting.



45328_1.gif

Once this basic model of an Ethernet service is established, a fourth ingredient is added to complete the picture: the Ethernet Virtual Connection (EVC). The EVC is “an instance of association between two or more UNIs” and is therefore the logical representation of connectivity through the metro Ethernet “cloud.” There are point-to-point and multipoint-to-multipoint EVCs, and these are created by the service provider for a customer in much the same way Frame Relay PVCs are created and managed today.

Once the network is defined and you have EVCs to establish connectivity, the next step is defining features for that particular service. The four big ones are:

  • Service multiplexing, which associates a UNI with multiple EVCs so that a single port can accept multiple customers or multiple service connections from a single customer. The former is a key feature for Ethernet Internet access, where a single service provider POP UNI can multiplex many customers from the access network. The latter is applicable for a corporate network, where many service connections from remote offices converge on the headquarters.

  • VLAN Transparency, meaning the service provider does not change the customer’s VLAN tags as they enter the network for a switched service. VLAN Transparency is important for Transparent LAN services where the MEN appears to the customer as one big Ethernet switch. For Ethernet Internet Access, VLAN Transparency is less important because the customer’s VLAN tag is of little use when connecting to an ISP to the Internet.

  • Bundling, which allows more than one customer VLAN to map to the EVC at a UNI.

  • Layer 2 Control Protocol Processing, which determines which Ethernet control protocol frames from customer equipment is locally processed, discarded or passed (tunneled) through service provider Ethernet gear.



The MEF has been the most steadfast in defining Ethernet service types, and after much haggling and debate, it has boiled them down to two:

  • Ethernet Line (E-Line) for point-to-point connectivity. E-line services will be used to create Ethernet private line services, Ethernet-based Internet access services, and point-to-point Ethernet VPNs.

  • Ethernet LAN (E-LAN) for multipoint-to-multipoint (any-to-any) connectivity. E-LAN Services are designed for multipoint Ethernet VPNs and native Ethernet Transparent LAN services.

“The MEF heavily debated Ethernet service naming and ended up agreeing on generic service constructs called E-Line and E-LAN,” says Ralph Santitoro, director of network architecture at Nortel Networks Corp. (NYSE/Toronto: NT), co-author of the MEF’s three service specifications, and co-chair of the MEF Technical Marketing Committee.

“Service naming should be a marketing exercise for service providers. Standards bodies and fora must focus on defining service attributes and network capabilities and let the providers select the service attributes that differentiate their offerings,” says Santitoro.

Since E-Line and E-LAN services can operate over dedicated or shared bandwidth, four key types of Ethernet service have emerged, described below.

Ethernet Private Line

This service consists of a point-to-point EVC that uses dedicated bandwidth, be it virtually concatenated Sonet/SDH channels or reserved packet bandwidth in a packet switched network.

The bottom line is that the customer’s Ethernet frames stay strictly separated from others’ at the Ethernet layer. And the customer will always have available the committed or contracted bandwidth rate also known as CIR (committed information rate). In this regard, the Ethernet Private Line is much like today’s TDM-based private lines, yet offers the benefit of a native Ethernet interface to the customer and to the network operator’s edge equipment.

Like typical TDM private lines, the Ethernet Private Line can be deployed to support a number of different carrier services, such as Ethernet Internet or network services access, where the customer owns one end of the connection, or LAN-to-LAN interconnect, where a customer owns both ends of the connection.

The Ethernet Private Line is the most well defined today and simplest to deploy. Carriers typically provide these services from an MSPP (multiservice provisioning platform), which acts as the demarcation between the customer’s network and the carrier’s Sonet/SDH transport network.

The Ethernet Private Line, in this case, is created by encapsulating Ethernet frames into GFP (generic frame procedure) frames and transporting those through Sonet/SDH channels, a process known as GFP-F, or frame-mapped GFP. An option specific to Gigabit Ethernet private lines uses Transparent mode GFP mapping (GFP-T), which simply re-encodes the client’s Layer 1 8B/10B line code into more efficient 64B/65B codes, which are then packed into GFP-T frames. GFP-T isn’t as common as GFP-F, but it does make for very simple and low-latency transport for GigE over Sonet/SDH.

The MEF describes the Ethernet Private Line as built from dedicated UNIs with point-to-point EVCs. IP/MPLS networks can support the Ethernet private line as a “pseudowire,” using encapsulation techniques defined by the IETF to carry Ethernet frames over a packet switched network (PSN). In this case, the Ethernet private line is emulated across the PSN and provided dedicated, reserved bandwidth.

Ethernet Virtual Private Line

For the Ethernet Virtual Private Line, the rules are slightly different. In this service, the customer still gets point-to-point connectivity, but over shared bandwidth instead of dedicated. The shared bandwidth can be a TDM channel in the transport network or the switch fabric bandwidth of switches and routers in the packet network. Features such as committed information rates (CIR) and excess information rates (EIR) can be offered by the service provider, with service performance metrics to support true SLAs. This service is therefore quite similar to Frame Relay and its model of creating networks using PVCs (permanent virtual circuits).

The MEF defines the Ethernet Virtual Private Line service as a point-to-point Ethernet Virtual Connection (EVC) between two UNIs (subscribers). The EVPL supports a service multiplexed UNI, meaning multiple EVCs can share a single UNI, which is useful when creating hub-and-spoke architectures in which multiple remote offices all require access to a headquarters, multiple customers all require access to an ISP’s POP (point of presence), or a mix and match of the aforementioned connectivity services plus managed services from an operator.

Ethernet Private LAN

The Ethernet Private LAN (EPLan) service provides multipoint connectivity over dedicated bandwidth, i.e., it may connect two or more subscribers (UNIs). Subscriber data sent from one UNI can be received at one or more of the other UNIs. Each site (UNI) is connected to a multipoint-to-multipoint EVC and uses dedicated resources so different customers’ Ethernet frames are not multiplexed together. As new sites (UNIs) are added, they are connected to the same multipoint EVC thus simplifying provisioning and service activation. From a subscriber standpoint, an EPLan makes the MEN look like a LAN.

Ethernet Virtual Private LAN

The Ethernet Virtual Private LAN (EVPLan) has gone by many names over the past two years, from Virtual Private LAN Service (VPLS) to Transparent LAN Service (TLS), to Virtual Private Switched Network (VPSN). Regardless of how it is termed, the EVPLan is a network service providing Layer 2 multipoint connectivity between Ethernet edge devices. Customer separation is accomplished via encapsulation or Ethernet virtual connections.

The EVPLan is designed as the most cost-effective service for the carrier, as it can leverage shared transmission bandwidth in the network. Because it is a multipoint service, it can be complex to administer. Customer service separation by Provider VLAN tags is not likely to be sufficient because of the limited address space of Provider VLANs IDs (only 4096) and hence other service delivery technologies providing customer frame encapsulation must be used such as MPLS, MAC-in-MAC and RPR. The operator must also decide how to implement protection, bandwidth profiles, congestion management, buffering, etc., since these are much more complex to implement when compared to point-to-point services.

The EVPLan is the foundation for a new class of Transparent LAN services (TLS) that will hopefully do better than previous stabs at TLS. TLS has long been touted as an exciting new service, but it has never really taken off. Service providers have tended to offer TLS in two ways, each with drawbacks. In one scenario, the service provider interconnects customer routers or Ethernet switches to the service provider’s ATM network, which then provides the necessary multipoint connectivity, QOS, and protection. Though this supports a robust service that can extend over wide areas, it tends to be expensive and complex to engineer. The alternative is to build a dedicated TLS network based solely on Ethernet switches interconnected in a mesh over dedicated dark fiber. This supports a lower-cost service, but tends to be only “best-efforts,” since Ethernet switches today cannot support sub-50 millisecond protection or true QOS.

The EVPLan can be offered over a variety of infrastructures, so you’ll find the ITU-T is working on defining the EVPLan from an SDH perspective, while the IETF’s Layer 2 VPN working group is continuing to hone its VPLS standard. In a VPLS, customer edge devices do not really see the metro or wide area network; they only see other edge devices as connected via a single logical learning bridge with fully meshed ports. The packet network can utilize MPLS, L2TPv3 or even Q-in-Q VLAN stacking to accomplish this.

45328_2.gif

These standard definitions may not end up being what service providers call the service when advertising to customers, but they are important to both the service provider and vendor community in creating the proper gear and feature sets that conform to agreed-upon specifications. So operators will build services according to the service definition guidelines set out by the MEF and other standards bodies, yet at the same time give themselves some freedom to offer subtle varieties of these services with unique names.

Different infrastructures are suited to different Ethernet service types, which explains much of the confusion surrounding Ethernet services standards today. When it appears at first that many different standards bodies are working on the same thing, it becomes clear upon examination that each standards body is tied to a particular mission:

  • The ITU-T is adapting Ethernet to SDH and MPLS transport networks.

  • The IETF is emulating Ethernet links and LANs over a packet switched network.

  • The MEF is defining the service attributes and service parameters that enable a consistent set of features associated with various Ethernet services.



Because Ethernet can be supported over such a wide variety of infrastructures, it has broad appeal yet also creates a bit of a muddle when carriers look to roll it out. Below we have a look at how Ethernet is carried over different layers of the network and how standardization will enable carriers to support Ethernet services in a standardized way over any network.

Ethernet Switches and Dark Fiber

This is the cheap and dirty way to support Ethernet services today, and not surprisingly you get what you pay for. These networks tend to be comprised of large Ethernet switches at central offices interconnected in a mesh within a metro area.

Customers are added to the network via dedicated CPE and long-reach Ethernet interfaces or WDM. These solutions tend to rely on Ethernet-based protection schemes today such as Spanning Tree (IEEE 802.1w) or Link Aggregation (IEEE 802.3ad) which cannot guarantee sub-50 millisecond protection but do work sufficiently well for LAN interconnect.

That said, these solutions are best utilized for Ethernet Virtual Private Line and Virtual Private LAN services, since they cannot easily accommodate the dedicated transport and switching bandwidth to individual subscribers for Ethernet private lines. Yet another drawback here is that there is presently no true OAM associated with a pure Ethernet network, so these services can only be offered as “best-effort” today.

Sonet/SDH

In next-gen Sonet/SDH networks, Ethernet frames are encapsulated one at a time into GFP frames, which are then mapped into a Sonet channel using virtual concatentation for carriage across the embedded network. LCAS can be used to keep a connection running at a reduced rate if members of the virtual concatenation group fail, or add more members if the customer requests additional bandwidth.

For multipoint services, next-gen Sonet/SDH solutions require either a mesh of dedicated Ethernet private lines to be established, with provider or customer bridging functions added at each node, or integrated Ethernet switching within the Sonet/SDH node itself.

This will be the most common solution going forward, and most next-gen Sonet/SDH gear shipping in 2003 supports some level of integrated Ethernet Layer 2 switching.

Sonet/SDH networks are most often used for Ethernet Private Lines today, but will be evolving to support Ethernet Virtual Private Lines and Ethernet Virtual Private LANs through integrated Ethernet switching or RPR technology.

There is growing evidence today that RPR-over-Sonet/SDH is gaining widespread support among large carriers worldwide, as it offers the benefits of leveraging the legacy network while supporting multiple Ethernet service types (see Incumbents Grab RPR Mantle).

RPR

Resilient Packet Ring (RPR) is an emerging standard from the IEEE (802.17) that supports sub 50ms ring-based resiliency on packet switched network architectures. RPR can run over Sonet/SDH or native Ethernet transport networks, and supports a significant degree of bandwidth efficiency on rings through the implementation of bandwidth sharing, spatial reuse, and statistical multiplexing.

In practice today, RPR is most commonly found as a line card solution on MSPPs and is currently being used to support Ethernet Virtual Private Lines and Virtual Private LANs. In many cases an entire RPR is dedicated to a single enterprise within a metro area that could be used to offer an Ethernet Private LAN service. However, service providers are increasingly rolling out RPR infrastructure for the support of many customers in a metro access environment that could be offered as an Ethernet Virtual Private LAN service.

ATM

In an ATM network, the IEEE 802.1Q information in each Ethernet frame is used to map that frame to the right ATM virtual circuit and service class. This allows a network operator to support Ethernet services with the end-to-end QOS and resiliency associated with ATM SLAs. It also allows a great deal of flexibility in service topology, from point-to-point, to multipoint, with optional levels of oversubscription. Service providers with existing ATM infrastructures can offer carrier-grade SLAs for their Ethernet services. For green field deployments, ATM comes at a cost that may encourage operators to look more enthusiastically at IP/MPLS-based schemes.

IP/MPLS

Describing Ethernet over IP/MPLS networks can quickly get rather fuzzy. The basics are rather straightforward, however. First, Ethernet frames are encapsulated then transmitted through the packet network via a tunnel connecting at least two endpoints in a service. Things get a bit more complex from there, depending on which features of the service an operator wishes to implement. It is helpful first to understand how the IETF is defining Ethernet encapsulation and connectivity over an IP packet switched network, which is described in detail in the following section.

Table 1: Ethernet Services

Ethernet Services

Topologies

Important SLA Parameters

Features

Customer Separation

Protection

Layer 1

Ethernet private line (E-Line)

Point-to-point, mesh, hub-and-spoke

Jitter, latency, loss, availability, protection

Full-rate or subrate services via the same interface

Dedicated Sonet/SDH, WDM, or fiber

Sonet:1+1 APS; WDM: Optical Layer 1+1 protection

Layer 2

Ethernet virtual private line (E-Line)

Point-to-point

Latency, loss, availability, CIR, EIR

Shared bandwidth connection between two points; may also include shared switch resources; oversubscription; rate shaping

Packet tagging, encapsulation, or virtual circuits

Ethernet Spanning Tree, Rapid Spanning Tree, Link Aggregation

Ethernet virtual private LAN (E-LAN)

Multipoint

Latency, loss, availability, CIR, EIR

Shared bandwidth connectivity among multiple sites; broadcast and multicast; oversubscription; rate shaping

Packet tagging, encapsulation, or virtual circuits

Ethernet Spanning Tree, Rapid Spanning Tree, Link Aggregation

Ethernet private LAN (E-LAN)

Multipoint

Latency, availability, CIR, EIR

Dedicated bandwidth among multiple sites; bandwidth tuning on a per-port basis; broadcast and multicast; no oversubscription

Dedicated Sonet/SDH, WDM, or fiber

Ethernet Spanning Tree, Rapid Spanning Tree, Link Aggregation





The International Telecommunication Union, Standardization Sector (ITU-T) is the Vatican of telecommunications standards (at least in the old sense of the Vatican), in that no matter what is going on in regional standards organizations or industry fora, when the ITU-T publishes a recommendation carriers will follow those orders to the letter.

The ITU-T is principally concerned with what goes on inside a carrier’s network, rather than how it appears to the outside world, so their participation in Ethernet services standardization is to make abundantly clear how Ethernet frames will be carried over various transport networks, be it SDH, OTN, ATM, or MPLS.

Within Study Group 13 and Study Group 15 the ITU-T has been working quite actively on making telecom networks safe for Ethernet, and has already developed a whole framework for Ethernet and its place in carrier networks.

Here’s a rundown of what the ITU-T Study Group 15 is working on for Ethernet networking standards. The real important ones are being handled by Working Party 3, which is in charge of the Optical Transport Network (OTN) Structure – Ethernet over Transport work:

  • G.8010/Y.1306 (formerly G.ethna) Architecture of the Ethernet Layer Network. This in effect is a new functional architecture for Ethernet public networks. The recommendation defines a common layer network architecture to support Ethernet services. The process is complex, but makes good sense: Take what is already defined for Ethernet in IEEE 802.1D, 802.1Q and 802.3 and translate that into terms that a public network operator can understand. The reason for doing this is the same reason the ITU-T came up with a functional modeling language for SDH, ATM, and the OTN: to simplify the integration of a new technology by describing it in the same language as legacy technologies. The payoff, therefore, is much more clarity in the interface between technologies, correct OAM behavior between layers, and a formal description of networks that all operators adhere to. G.8010 also defines Ethernet Network Management Requirements. The basic Ethernet network layered structure is as follows:

    • Ethernet MAC layer network (connectionless)

    • Ethernet PHY layer network (connection-oriented)



  • G.8011/Y.1307 (Formerly G.ethsrv) Ethernet Service Framework. This recommendation takes what is defined in G.8010 and describes Ethernet service topologies from that network point of view. There is clearly some overlap here between what the MEF is doing and what the ITU-T is standardizing, because this standard does result in specifications for various service types and their attributes, from interface type, to traffic profiles, Layer 2 control plane processing and MAC learning options. G.8011 identifies the following Ethernet service topologies: Ethernet Private Line (EPL) – three types (point-to-point leased-line equivalent, point-to-point frame-by-frame encapsulation, and point-to-multipoint); Ethernet Virtual Private Line (EVPL); Ethernet Private LAN (EPLan); and Ethernet Virtual Private LAN (EVPLan).

  • G.8012.x/Y.1308 (Formerly G.eota, G.euni, and G.etnni) Ethernet over Transport Architecture. This series of Recommendations are about interconnecting two or more physical 802.3 Ethernet interfaces via a transport network, whether it’s SDH or OTN. It describes the functional architecture of the transport networks supporting Ethernet services. This standard will come out in stages. G.8012.1, for Ethernet Private Line Service, is first. The remaining service types will follow in subsequent G.8012.x recommendations. Steve Gorshe, co-editor of G.8012.1 and Principal Engineer in PMC-Sierra’s Product Research group says, “By choosing to develop a G.8012.x series, the different pieces can be discussed in parallel and released as soon as they are ready. There is broad technical agreement on the content of G.8012.1. After working on the text at the January Q12 experts meeting, G.8012.1 should be ready for consent at the April 2004 ITU-T SG15 meeting.”

  • G.eequ – Ethernet Equipment. This recommendation defines requirements for equipment which supports the Ethernet transport services defined in G.8012.x, the architecture of Ethernet transport networks defined in G.8010, the UNI and NNI defined in G.8012.x, and the Ethernet transport network performance monitoring and OAM capabilities defined in Y.17ethperf and Y.17ethoam. Essentially, in keeping with the ITU’s specification of SDH, this is the final document of the set that pulls all the pieces together to indicate what must be implemented in a particular piece of equipment in the network.

  • G.esm Ethernet Service Multiplexing. This recommendation defines Ethernet services multiplexing over transport networks. This is of huge importance to operators going forward, and there is much debate over how to accomplish this. There are at least four ways to perform service multiplexing and switching in the service provider’s network. The options include different forms of service provider (SP) encapsulation; use SP Ethernet (MAC-in-MAC) to allow MAC switching solutions, use SP Bridge (Q-in-Q) for link multiplexing, use extended GFP’s overhead to include space for service provider addressing and tagging of flows, or use the various MPLS solutions (Martini and pseudowire emulation -- PWE), which already have a well-defined and scalable method of managing service multiplexing. SP Bridge (Q-in-Q) solutions are being considered for link multiplexing and interconnect to ATM, IP, MPLS, and the Internet. MPLS has the support today for convergence in the WAN, but this standard remains in the heavily debated stage.

  • G.asm. When an operator puts an Ethernet service into place, they need the endpoints of that particular service to communicate with each other, and they also need a way to communicate with at least one of the endpoints from a centralized location. Where this standard started out as an attempt to define end-to-end management of Ethernet over Sonet/SDH, it is now broader in scope and seeks to define an “architecture for the management of services delivery in a multi-carrier multi-bearer environment.”

  • G.mta. This is an interesting one, as it will define “the Architecture of a MPLS bearer layer network,” which is certainly a mouthful but represents a real break from the old world of SDH and ATM into the new world of MPLS and the foundation for new services. This document is intended to be a companion to G.8010 –- to in effect translate MPLS into terms that a public network operator can understand. Services such as Ethernet Virtual Private Line and Virtual Private LAN will leverage this work.

  • G.985. This Ethernet access standard defines the requirements and architecture of 100-Mbit/s point-to-point Ethernet access.

  • G.ces. This work in progress sets out to define Circuit Emulation Services over Ethernet. This remains in its infancy.

  • G.capp. This standards work is rather tangential to Ethernet services, yet it does set out to define CWDM applications, including Ethernet transport over CWDM.



Here’s a quick summary of what the ITU-T Study Group 13 is working on for Ethernet networking standards. While it is expected this group will look at Ethernet performance and traffic management, the current focus is on Ethernet OAM. This work is being handled in Working Party 3 as well:

  • Y.1730 – Requirements for Ethernet OAM. This recommendation indicates that there are different domains for Ethernet OAM in a network resulting in several possible Ethernet OAM flows (e.g., end-to-end versus link). It further delineates the motivations and requirements for user-plane OAM (Operation, Administration and Maintenance) functionality for Ethernet-based networks. The scope of this recommendation includes the requirements for OAM functions for the point-to-point and multipoint-to-multipoint Ethernet connections including both dedicated and shared access.

  • Y.17ethoam – Ethernet OAM mechanisms. This recommendation is an implementation of the requirements of Y.1730 for between ‘maintenance entities’. These include Ethernet OAM mechanisms for fault management (e.g, loopback, keepalive, path trace, AIS/RDI), performance measurement and discovery. This standard will also define the Ethernet frame format for these OAM frames.



The IETF takes a rather packet-centric approach to Ethernet services, leaving things like Ethernet-over-Sonet/SDH to American National Standards Institute (ANSI) and the ITU-T.

There are two fundamental approaches in the IETF to Ethernet services: the pseudowire and the provider provisioned VPN.

The pseudowire is an emulation in a tunnel of point-to-point services, either Layer 1 (such as TDM private lines) or Layer 2 (data-link) point-to-point services. The beauty of pseudowires stems from their flexibility and simplicity. According to Gady Rosenfeld, director of strategic marketing at Corrigent Systems Inc., “PWE3 is a mechanism that emulates the essential attributes of a telecommunications service (such as a T1 leased line or Frame Relay) over a PSN. Using the pseudowire mechanism, an operator can migrate all his transport services to a converged network with a common bearer layer and control plane.”

Pseudowires will be an essential building block of many Ethernet-based services, including multiple Layer 2 VPN types as well as future Ethernet services delivered over a converged Sonet/SDH/MPLS layer network as defined by the ITU-T.

The provider provisioned VPN model uses these pseudowires to create Layer 2 VPN definitions, notably the Virtual Private Wire Service (VPWS) and the Virtual Private LAN Service (VPLS).

VPWS is a Layer 2 point-to-point service, so can be more than Ethernet, including ATM, Frame Relay, and PPP/HDLC. Encapsulation happens at the provider edge, typically using L2TPv3 or MPLS. Then a pseudowire virtual circuit is nailed up across the packet network. If the provider edge equipment has the right kind of intelligence, this service model can allow interworking between different Layer 2 attachment circuits. Depending on whether service multiplexing, VLAN transparency or All-to-One Bundling is employed, VPWS can be used to create port-based or VLAN-based Ethernet private lines.

VPLS differs in that it moves beyond a model of virtual circuits and instead transforms the packet network into a switched LAN. Thus, to the enterprise, the VPLS service makes the service provider network operate as a single VLAN, with a unique SLA, protection attributes, availability attributes and MAC address learning and forwarding for scalable multipoint configurations.

The VPLS can be created using Ethernet over MPLS or a stacked VLAN approach using the Q-in-Q approach. The VPLS also differs from VPWS in that it is designed for Ethernet only. It has in common with VPWS the ability to be provisioned as a port-based or VLAN-based service, based on the implementation of service multiplexing and VLAN transparency.

These service standards are at least two parts architecture, one part service definition, which has led to some confusion in the marketplace. They can all run over IP, L2TPv3, or MPLS, though MPLS has gotten the lion’s share of the attention thanks to the success of the “Draft Martini” approach to Layer 2 VPNs.

In the Martini approach to Ethernet services, an MPLS label-stacking technique is employed. When an Ethernet frame enters the provider edge device setting up the Martini VPN, two MPLS labels are added, based on destination information associated with that frame. This could include MAC address, port, 802.1p, or 802.1Q information. The first label is the tunnel label, which provides the necessary information to transport the frame across the provider backbone. The second label, nested within, is the VC label. This one is read by the egress label edge router and provides the information necessary to process the frame and send it to the proper destination Ethernet port.

The IETF’s work on Ethernet services can be found in two distinct working groups: Layer 2 VPN and pseudowire emulation edge to edge (PWE3).

Within the PWE3 working group documents are being formally drafted that include Ethernet pseudowire definitions and encapsulation procedures. The values of pseudowires have become eminently clear to service providers today, and include:

  • ATM/FR/PPP/HDLC/Ethernet over IP/MPLS

  • Enable deployment scaling far past Ethernet’s 4,096 VLAN limitation

  • Transport over non-Native Backbones

  • Co-existence with other Encapsulations

  • Service Interworking (i.e., swapping subscriber’s UNI encapsulation)



The pseudowire specs have the most momentum today and are being used by service providers to offer Layer 2 transport across their IP/MPLS cores. Because pseudowires are not specifically designed for Ethernet, they have much broader application and therefore much greater interest than the Ethernet-only VPLS spec coming out of the Layer 2 VPN working group.

45328_3.gif

The Layer 2 VPN working group is presently focusing on developing documents that specify the following:

  • Virtual Private LAN Service (VPLS) -- L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment.

  • Virtual Private Wire Service (VPWS) -- L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network.

  • IP-only L2 VPNs -- L2 service across an IP and an MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN segment or a point-to-point circuit.



Today, there is a certain amount of confusion surrounding the specifications coming out of both the Layer 2 VPN and Layer 3 VPN Working Group, made only worse by further skepticism surrounding the market viability of VPLS.

When it comes to VPLS, both service providers and customers have something to fear. Service providers see this as much more than traditional point-to-point “LAN interconnect” services, and instead view it as a true LAN emulation service, which creates the potential for cannibalization of their profitable Frame Relay and ATM services. That said, they will move cautiously into this space.

From the customer’s point of view, even though it is clearly more cost effective to move to WAN access gear with Ethernet interfaces instead of Frame Relay interfaces, a move to VPLS still requires new CPE. The customers that are interested today in VPLS are saying they’d rather see an incremental approach, where individual locations in a distributed corporate network can be upgraded to Ethernet one by one. This mandates service interworking in the carrier network between Frame Relay and Ethernet, which is both technically challenging and without clear standards.

The MEF is where things get interesting. All the arcane terminology and technical details of the ITU-T and IETF give way here to terminology we can all recognize as customers of data services. The MEF, to put it plainly, is making Ethernet services safe for the enterprise. “The Metro Ethernet Forum plays a key role in the industry by providing a common set of tools and terminology that will define consistent characteristics of these Ethernet services that service providers, system vendors, and enterprises will all be able to refer to regardless of the specific type of network infrastructure whether it is a Sonet/SDH, dark fiber, MPLS, ATM, or RPR,” according to Nav Chander, VP and marketing co-chair for the MEF.

The Metro Ethernet Forum was established to promote the widespread acceleration of Metro Ethernet services. With standards work underway in the IETF and the ITU-T, which was translating what the IEEE had already defined for Ethernet, the MEF has carved its niche by focusing on the end user rather than the network itself. What you’ll find at the MEF are documents that define metro Ethernet service types, attributes and the parameters of those attributes. In this way, the MEF is busy defining just what a service provider will offer the customer, rather than how the service provider will transport Ethernet over their particular network infrastructure, be it SDH or MPLS.

Just as the Frame Relay Forum once defined the Frame Relay UNI and the PVC, the MEF is at work defining the Ethernet UNI and EVC. Though this work may not seem as technically rigorous as what goes on at the ITU or IETF, this will likely produce the basic terminology of the Ethernet service, so that operators anywhere in the world can begin speaking the same language to their customers (bandwidth profiles, availability, delay, jitter, frame loss, etc.) and writing SLAs that customers recognize as valid and supportable. “Frame Relay is a ubiquitous service available worldwide. The MEF envisions Ethernet services becoming pervasive if they closely model the familiar Frame Relay definitions, terminology and concepts such as CIR, EIR, EVC, and UNI,” says Nortel's Ralph Santitoro.

This is more critical than it may first appear. What keeps Frame Relay so popular today, despite all the technical or operational liabilities an Ethernet advocate can throw at it, is customer familiarity. Service provider salespeople like that, and will keep pushing it, no matter how much Ethernet is hyped. But once that salesperson is outfitted with a menu and SLAs that look like Frame Relay but offer much greater bandwidth flexibility at a lower cost per bit, then they may just start pushing that service with some real zeal.

45328_4.gif

The MEF’s work on services standardization is proceeding using a phased approach. MEF Ethernet Service Definitions Phase 1 consists of 3 technical specifications:

  • Ethernet Services Model (ESM), ratified September 2003 into Technical Specification MEF 1.0

    • Defines Ethernet service building blocks which include the physical interface, bandwidth profiles, service frame delivery, and service multiplexing

    • Building blocks consist of Ethernet Service Attributes and Parameters defined for Ethernet UNI (User Network Interface) and Ethernet Virtual Connection (EVC)

    • Does not define Ethernet services

  • Ethernet Services Definitions (ESD)

    • Defines how to apply the ESM building blocks to create services

    • Defines Ethernet Line (E-Line) and Ethernet LAN (E-LAN) service types and service instances of them (Ethernet Private Line, Ethernet Virtual Private Line, Ethernet Internet Access, etc.)

  • Ethernet Traffic Management (ETM)

    • Defines traffic management and service performance attributes and parameters to create COS-based SLAs.

    • Service performance parameters include availability, frame delay, frame jitter, and frame loss determined via class of service ID (802.1p, for example) or on a per-port basis



According to the MEF, Phase 1 of the Ethernet Service Technical Specifications are scoped as follows:

  • The services defined are only those based on Ethernet. The various attributes are such that the service given to a particular Ethernet Service Frame is determined by only the contents of the Ethernet protocol and/or lower layers.

  • From the Subscriber equipment point of view, the protocol operating at the UNI is a Standard Ethernet protocol (PHY and MAC layers).

  • The services defined are limited to services between Ethernet UNIs. Future phases may define service attributes for other types of UNIs to the MEN.



Going forward, the MEF has a lot on its plate, including further standardization of Ethernet service parameters and the many attributes of those parameters. In addition, the MEF’s mission extends well beyond just Ethernet services definition, to defining carrier-class Ethernet-based metro transport technologies by specifying architecture, protocols and management for metro Ethernet. This will result in definitions and specifications for EVC protection, QOS, an Ethernet NNI, and OAM&P (operations, administration, maintenance and provisioning) for end-to-end management of Ethernet services, regardless of the underlying transport technology. The MEF will also be filling in gaps where other standards bodies have holes, such as definitions for circuit emulation over Ethernet networks and defining element management system and network management system requirements for metro Ethernet services.

“Looking ahead, the MEF also plans to increase its focus on generating collateral and applications that will educate the marketplace on the Metro Ethernet service advantages. This includes examining the economic and productivity benefits of Metro Ethernet services for service providers and enterprises with the support of emerging applications like storage, VOIP, and video conferencing to name a few,” says Chander.

The three publicly available MEF documents most relevant to the report are:

The IEEE standardized Ethernet years ago and continues to drive standardization of Ethernet technology today. That said, they will not be contributing much in the way of Ethernet service standards, but will provide the key technology ingredients that underpin the more broad service standards the other bodies are developing.

The key standards from the IEEE worth pointing out include:

802.1ad Provider Bridges

This standard builds on the IEEE’s 802.1Q (Virtual LANs) to enable stacked VLANs (see Smooth Sailing for VLAN Standard), commonly referred to as “Q-in-Q” tag stacking, a vital tool for service providers. With stacked VLANs, customer’s traffic is tagged with a service provider VLAN at the provider edge, allowing significant scalability of switched Ethernet service provider infrastructure, and separating subscriber spanning tree restoration from the service provider’s protection methods. In addition, 802.1ad will allow Layer 2 control protocol tunneling. Moving forward, 802.1ad will be a component of VPLS.

802.1w Fast Spanning Tree

This standard is an improvement on the rather slow (tens of seconds) Spanning Tree recovery algorithm typically implemented in Ethernet LANs. Rapid Spanning Tree goes to work when large switched Ethernet LANs or MANs recover following a device failure or change in link status. This is critical to Ethernet service infrastructures, since they are by their nature much larger than typical corporate LANs and will be supporting multimedia services that are sensitive to session timeouts and data loss.

802.3ad Link Aggregation

Link aggregation will be a useful tool to service providers offering Ethernet transport services between Ethernet switches or between Ethernet switches and high-end servers. The idea is simple: group multiple physical ports together on an Ethernet switch into a single logical port. The value is threefold: faster connections between switches managed as a single connection, load sharing and load balancing among the individual links within a logical connection, and a failure mechanism that allows a link to stay up at a reduced peak rate even if some of the physical ports go out of service. For the service provider, a final value is the ability to add or subtract bandwidth to a connection in whatever combination of bandwidths (10 Mbit/s, 100 Mbit/s, 1 Gbit/s) is available on that switch.

802.3ah Ethernet in the First Mile Taskforce

This standard's effort is primarily around defining Ethernet PHYs for first mile access, be it copper, PON, or point to point fiber, but this group is also standardizing Ethernet OAM, a critical ingredient in any Ethernet service.

In the Ethernet First Mile Task Force, OAM is being standardized to monitor link operation, health (discovery, connectivity verification, latency and loss measurement, delay variation measurement), and improve fault isolation, all of which Ethernet is currently terrible at. This means creating an Ethernet OAM protocol data unit (PDU) that is sent between two ends of a single link in the form of untagged 802.3 Slow Protocol frames. Ethernet OAM, implemented this way, can be used to support remote loopback, event notification (such as errored seconds), and information about link state and configuration.

This standard won’t include definitions for protection switching, provisioning, bandwidth allocation, or true end-to-end OAM communications, since it is focusing on single links. Ultimately, end-to-end Ethernet OAM will come from somewhere else -- the ITU-T, the Metro Ethernet Forum, or a combination of the two.

802.17 Resilient Packet Ring

You’re not likely to find another 802 standard so completely devoted to the service provider. Where FDDI was once used as both a metro service infrastructure and a LAN backbone, RPR will almost exclusively be deployed on metro optical networks to support Ethernet and other packet services transport with 50ms resiliency and a significant degree of bandwidth efficiency on a shared ring topology. This standard is not quite complete, but very near it. Ratification is predicted to occur mid-2004, and already pre-standard versions are widely deployed by cable MSOs, IXCs, and a few daring LECs.

The reasons for RPR’s increasing popularity, even before the standard is complete, include its transformation of the service provider access network into a distributed packet switch, with carrier-class performance, obviating the need to “supercharge” enterprise-class Ethernet switches through the creation of a new MAC layer specifically designed for metro services.

When RPR is used in a metro network to support Ethernet services, it provides a standards-based solution that offers multiple classes of service from best-efforts to video-grade, auto-discovery for easy addition of new nodes, rapid service provisioning without the requirement for circuit engineering, and efficient fiber utilization derived from spatial reuse of bandwidth around the ring.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like