Meeting the challenge of first-mile access for Multipoint Business Ethernet

Note: This article has been updated on 12 October 2009 from its original version, to include PWE3 as the possible “protocol of choice”.

Good time of day to you, dear reader. 🙂

Today I would like to talk briefly about the effort that is taking an important bit of my time as of recent – getting off the ground an interest in Carriers and Vendors to develop and deploy a solution to today’s woes of first mile access for Multipoint Business Ethernet services.

To set the mood, I would like to stress that I am mainly concerned with Multipoint Ethernet Services, sold directly to Business (Enterprise) customers, as opposed to other Carriers or wholesale purchasers, such as Systems Integrators.

What are those woes and what am I on about? Read on to find out.

Multipoint Ethernet WAN services play an ever-increasing role in the modern Data Service Provider’s arena – Enterprise market is by far the largest, and the level of its acceptance towards Multipoint Ethernet WAN services is growing steadily, thanks to a raft of factors outside of the scope of this post. As of recent, there also is an increasing shift of focus from basic Ethernet connectivity to the ability to offer feature-rich, value-add enabled services (application-aware QoS, for example).

Now, these Multipoint Business Ethernet services are significantly different from their backhaul and infrastructure application counterparts in terms of:

  • Unpredictable customer site locations;
  • Tight time constraints – businesses often want their services ASAP;
  • Wide spread “it is all or nothing” situation – all customers sites must be reached or no deal.

These differences dictate the widespread use of 3rd party arrangements for first/second mile connectivity, whereby a Service Provider (from here on referred to as “First Party”) combines a Multipoint Layer 2 VPN, delivered by its core MPLS platform (for example), with a mix of its own (where available) Access Tails and one or more 3rd party offerings.

When a particular Multipoint Layer 2 VPN is served via Access Tails with sufficiently different features, some of the value-add services may become unfeasible and cannot be offered to all sites of such VPN. Loss of such ability hampers First Party’s market competitiveness and is seen as undesirable.

An example of this would be mixing Access Tails which support bundling or all-to-one bundling with ones that don’t on the same mutlipoint to multipoint EVC (please read the MEF10.1 from or at least introduction slide pack for MEF6/MEF10.1, if you start feeling confused at this point – it will help a lot). In such case one Access Tail that doesn’t support bundling will very likely prevent the whole thing from working correctly, forcing it to fall back to the lowest common denominator and potentially killing the value proposition.

It is seen as unlikely that all Ethernet Access providers will align features of their Access Tails in a near future; therefore a way around the described problem must be developed.

The proposed solution is to design  a tunneling function, designed to cater for the needs of Ethernet Service carriage, and implement it in:

  • A First Party-owned Network Termination Unit (NTU), which is to be deployed at customer sites in addition to 3rd party demarcation device; and
  • A Tunnel Aggregation Unit (TAU), which is to be deployed by the First Party close to its core network, and which will terminate a large number of tunnels from NTUs.

These devices, when deployed in tandem, will allow “enveloping” a 3rd party tail to enable consistent physical and functional presentation of First Party’s Multipoint Layer 2 VPN product.

This consistency in presentation can be achieved in the following key areas:

  • MTU Size (by supporting fragmentation and reassembly);
  • C-VLAN tag transparency (for both VLAN ID  and CoS);
  • Service multiplexing and bundling; and
  • Full Layer 2 Control Protocol transparency.


The shaded devices in the picture above are the ones that we’re talking about in this post.

The benefits of this are manyfold:

  • Establishing an interconnect is easy – all you need is basic connectivity, and tunneling protocol will take care of the rest;
  • All 3rd party tails will “look and feel” very consistently indeed, which is good for your brand as a Carrier;
  • Sales process is vastly simplified, as you don’t need to talk customer through the maze of provisos and options that they may or may not have depending on what is available at their branch locations;
  • Chance of loosing a sale due to the absence of reach with particular features in a particular location is significantly reduced;
  • Offering Ethernet tails into remote countries is easy, too – IP VPNs are ubiqutous, and where there is IP, there is tunnel over it.

From a brief look at the available options, I think that PWE3 looks like the best all-round candidate for the tunneling function implementation, what with having all the necessary functionality, including fragmentation and reassembly (which is important for providing consistent large MTU size over underlying transmission that doesn’t support it).

One possible implementation would perform all the necessary “magic” inside the Native Service Processing (NSP) function of the PWE3 reference model (see RFC4448, Figure 3).

Comments are welcome! 🙂

About Dmitri Kalintsev

Some dude with a blog and opinions ;) View all posts by Dmitri Kalintsev

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: