White Paper: IP VPN and Ethernet WAN Services

Carrier Ethernet Services

Introduction
For some years now, the principal 'Next Generation Network' offerings of Telecoms Service Providers, for
mid to large sized Enterprises, have been based on IP Virtual Private Network (IP VPN) technologies.

The term 'Next Generation Network' is one of those wonderfully flexible marketing phrases which has
been used (and possibly abused!) for many years. In reality, the term has never referred to a single, well
defined architecture. Essentially the phrase originated in relation to Wide Area Network architectures, as
packet-based networks emerged after the long-time dominance of TDM based PDH/SDH network
infrastructures. Generally, of late, it has become synonymous with the deployment of IP Routed networks,
underpinned by Multi-protocol Label Switching (MPLS). Out of this core technology has emerged an array
of commercial IP VPN services, which are attractive primarily through support of both 'Quality of Service'
features and flexibility of Access technology.

More recently Ethernet, the ubiquitous technology of the Corporate Local Area Network (LAN), has
evolved to the extent of becoming a viable choice for Wide Area Network (WAN) deployment. For some
time, Ethernet has been one of the Access options for IP VPN networks, but increasingly Ethernet 'Layer-
2' WAN Services are now being adopted, as a either a competitive or complementary approach to IP
VPNs.

This paper provides a brief overview of both IP VPN and Ethernet WAN services, looking at the pros and
cons of both, from the perspective of both Service Provider and customer, and then considers some of
the challenges facing the Service Provider community, both in meeting increasing customer demands for
'Wires Only' Ethernet Access to IP VPNs and in making the transition to the provision of Layer-2 Ethernet
WAN services. Not least of these challenges is the ability of the Service Provider to offer strong customer
service value to their clients in relation to provisioning and troubleshooting, when local connectivity is
almost invariably provided via wholesale 'tail' circuits offering little or no management visibility to the
Service Provider at the point of hand off from WAN to LAN at the customer's premises.

Backgrounder - Next Generation Networks and MPLS
Thinking back in history a little, (to around the mid '80s), Wide Area Networks used to link Ethernet LAN
domains, were initially Bridged, i.e. decisions as to whether to forward particular Ethernet packets across
the WAN link were based upon algorithms requiring the 'learning' of Ethernet 'Media Access Control'
(MAC) addresses of end-station devices. The rapid uptake thereafter of protocol-specific Routers, and the
increasing ubiquity of IP as the protocol of choice, gave greater scalability, resilience and security to WAN
architectures.

IP Routers offer the potential for building resilient mesh networks, but in a traditional routed IP network,
each Router makes an independent forwarding decision for every packet based on the packet’s IP
address header. A simple Routed mesh network is shown in Fig. 1.

B

A C
Fig. 1: Each Router in a traditional IP Router
network must make 'next hop' forwarding
decisions for each packet in turn

D E

Ethernet WAN Services
Page 1 of 12

When a packet arrives at a Router port, that Router has to determine where best to forward the packet for
the 'next hop', in order to reach the required destination. Ultimately, in a large and high throughput
network, this becomes performance limiting. In the mid '90s, the mechanism of 'Label Switching' was
developed, largely to ease the congestion caused by Route calculations in IP Core networks, leading to
the development of the standard for 'Multi-protocol Label Switching', MPLS. In fact, MPLS was
architected to support various Network transports, including ATM and Frame Relay, but we will consider
here the way in which MPLS brings a 'connection oriented' approach to the essentially 'connectionless'
protocols of IP and Ethernet.

In an MPLS environment, packets entering the network are handled in a particular way based on a
definition known as 'Forward Equivalence Class' (FEC). FEC typically relates not only to the IP Subnet
associated with a packet, but also to service Class, and packets exhibiting similar FEC characteristics are
treated essentially as members of a 'group' and are assigned a similar 'label', i.e. a short packet header,
which will determine the path to be taken for such packets across the MPLS network. Packets with
different FEC characteristics will be assigned a different label and may take a different path through the
network. Each Router in the network maintains a table indicating how to handle packets determined by
the label, so once the packet has entered the network, Routers no longer need to perform IP address
analysis and can make rapid and consistent forwarding decisions depending upon the label.

One of the key benefits of MPLS is that it separates forwarding mechanisms from the underlying data-link
service. MPLS can be used to create forwarding tables for data streams independently of the network
access mechanism and traffic type, so Service Providers can use MPLS to deliver a wide variety of
services and to support a wide array of access technologies. The two most popular traffic types supported
over MPLS are Layer-3 (IP) BGP/MPLS VPNs (based on RFC 2547) and Layer-2 (or pseudowire) VPNs.

RFC 2547 VPNs have been very widely implemented. The implementation defines a peering architecture
in which customer edge (CE) Routers exchange routes with Service Provider edge Routers, denoted
'Provider Edge' (PE). These then deliver VPN tunnelling across the Service Provider's MPLS 'Label
Switching Router' (LSR) network, using paths defined by the label switching mechanism. For IP VPN
services, the MPLS VPN backbone uses Border Gateway Protocol (BGP) for routing, and once the CE-
PE peering is implemented using BGP, thereafter the Service Provider's MPLS network takes full
responsibility for secure, reliable end-to-end packet delivery.

For many Service Providers, the above scenario encapsulates the essence of the term 'Next Generation
Network', and services based on the IP VPN approach are offered for a variety of different access media,
as illustrated in Fig. 2 below.

Remote Sites

Home Workers

ADSL SDSL
ADSL

Internet IP VPN over MPLS Core Network

2Mbps 'E1' Leased Line

Secure Access Storage and Application Servers
For Home & Mobile
Workers
Ethernet 1Gbps
Regional Office

Corporate HQ

Fig. 2: Multi-access IP VPN Network

Page 2 of 12

Note that in the case of IP VPNs, the Service Provider is very much involved in the overall IP Routing
topology of the customer, which inevitably means a high level of complexity (and, by association, cost) for
the Service Provider at the time of network commissioning and a subsequent degree of 'shared
responsibility' between customer and Service Provider for any adds, moves and changes which are
required thereafter.

Ethernet into the WAN
We have already seen, in Fig. 2, that Ethernet is commonly used as one of the access vehicles for
Corporate IP VPN networks. The scalability of bandwidth and familiarity of Ethernet lends itself to this
role. In reality, Ethernet might be delivered across into the WAN cloud via a number of different Access
media, including multiple bonded copper pairs for lower-speed connections (the so-called 'Ethernet in the
First Mile' or 'EFM' offerings based on SHDSL technology) and fibre for higher speeds.

In some instances, particularly those in which the customer requires high connection speeds, protocol
transparency and may wish not to have a Service Provider involved in their overall Routing topology, then
as an alternative to the 'Virtual Routing' nature of an IP VPN, the customer may prefer the greater
transparency, flexibility and connection speed scalability of a Switched Ethernet service for their WAN
backbone. Depending on the complexity of the WAN architecture (i.e., single site, multi-site...), this might
mean that either one or more point-to-point Switched Ethernet links are appropriate, or alternatively that a
Multi-point 'Virtual Ethernet' network architecture is preferred.

Since we have already established that Service Providers' New Generation (let's call them that, rather
than 'next generation' !) Core Networks have become almost exclusively built around MPLS, what options
exist for supporting 'raw' Layer-2 Ethernet connectivity in an MPLS environment (i.e. rather than Ethernet
simply being the Access vehicle for a Layer-3 IP network)? Essentially, two main models have emerged,
corresponding to the two scenarios outlined above. They are generally termed (i) 'Virtual Private Wire
Service', for Point-to-Point links, and (ii) 'Virtual Private LAN Service' (VPLS), for Point to Multipoint
networks.

Virtual Private Wire Service implementations use effectively Label Switched 'pseudowire' tunnels, which
are created between the Service Provider's PE Routers across the MPLS network, delivering Ethernet
packets between two points across the MPLS 'cloud'.

Virtual Private LAN Service (VPLS) implementations use potentially a number of slightly different
mechanisms, by which the MPLS Core network can emulate one or more 'flat' Ethernet network domains.

Layer-2 Ethernet
VC Connections

CE CE
Customer
Customer
Site
PE PE Site

MPLS CORE NETWORK
Meshed
Pseudowire
Links
PE Fig. 3: A full mesh
of pseudowires is
used to connect all
CE (typically a switch) provider edge (PE)
devices supporting
a given VPLS VPN
Customer
Site

Page 3 of 12

Different equipment vendors have proposed a number of variations in the areas of discovery of members
to include within a given Layer-2 Virtual Network, and of signalling used to establish and tear-down
individual Layer-2 pseudowire connections, but the net result is the same.

Using MPLS like this for Ethernet has some 'knock-on' benefits in terms of overcoming the distance
limitations within traditional switched Ethernet Networks and extending Ethernet broadcast domains
potentially across a whole WAN infrastructure. Effectively, a single PE can transmit Ethernet packets to
multiple remote PEs, connecting a customer site to any or all other customer sites as required. A
schematic VPLS network is shown in Fig. 3

After all this talk of the 'inner workings' of Service Provider networks, it may just be worth mentioning that
various evolutions to MPLS, notably MPLS-TP (Transport Profile), have emerged, as a vehicle for
optimisation of MPLS when carrying purely packet-based traffic, i.e. IP &/or Ethernet. An alternative
transport mechanism, optimised for Ethernet delivery across Core Carrier networks, known as 'Provider
Backbone Bridging, with Traffic Engineering' (PBB-TE) has also been mooted, although at the time of
writing this White Paper, it would seem that the ubiquity of MPLS is speaking volumes in relation to the
likely outcome of this particular battle!

Of more significance in relation to the focus for this Paper, is a consideration of the positioning, for both
Service Providers and customers, of IP VPN vs. Ethernet WAN services.

IP VPN Characteristics
IP VPN WAN services have been available for several years and are offered by both 1st tier
National/International Carriers and 2nd tier Service Providers worldwide. A large number of enterprises
have adopted IP VPN services, allowing them to interconnect hundreds or thousands of disparate
regional, national, and global locations very effectively.

As always, there are both benefits and disadvantages associated with any service. However, the most
important characteristics of IP VPN services are:

● Flexibility of Access
IP VPN architectures support a wide range of Access technologies and media. These can include
traditional SDH/PDH Leased Lines, DSL services, Frame relay, ATM and Ethernet. This is a great
strength of IP VPN services in that connections from individual users or small office locations, right up
to regional or HQ locations, may be made to the corporate VPN service, through a variety of available
Access networks, at an appropriate bandwidth.

● Scalability
IP VPNs are essentially IP routed networks. As such, they offer a highly scalable platform for
supporting very large enterprise networks with hundreds or even thousands of enterprise locations.

Routed connections between Service Providers, and the large number of Service Providers offering
IP VPN services, can enable connections for an enterprise customer to extend geographically on a
regional, national or global basis, with the possibility for rapid expansion.

● Routing control Outsourced
By deploying IP VPNs, enterprise IT managers effectively adopt a single architecture for WAN
connectivity, eliminating the challenges of operational and resource planning and of maintaining the
traditional plethora of separate networks. The status of the Service Provider becomes that of a
'trusted partner', responsible for managing all aspects of WAN connectivity.

Critically, the enterprise effectively outsources control over network Routing, which some IT
managers may feel compromises their ability to manage security throughout the enterprise, i.e. within
both LAN and WAN environments. The Service Provider also typically takes responsibility for traffic
policies within the WAN, such as the prioritisation of critical applications and the effective handling of

Page 4 of 12

latency-sensitive real-time applications including VoIP and Video, using the 'Class of Service' (CoS)
tools inherent within IP VPN architectures.

The enterprise undoubtedly becomes reliant upon the expertise and processes of the Service
Provider. This is true not only at commissioning time and during day-to-day operations, but also
whenever the enterprise makes any changes to their applications or environment. The Service
Provider remains integrally linked with the enterprise and routing re-configurations associated with
adds, moves and changes are managed by the Service Provider.

Ethernet WAN Characteristics
Ethernet WAN services have evolved rapidly over the past few years. Initially, they were restricted largely
to Metro area networks, but are now available Nationally and Internationally from leading Service
Providers.

The key drivers for Enterprise adoption of Ethernet WAN services have been low cost, ease of
implementation and a familiarity with Ethernet. Since its launch in the early '80s, with the final demise of
IBM's Token Ring by the end of the '90s and despite brief incursions by the likes of FDDI and then ATM
as LAN transports during that decade, Ethernet has achieved the status of becoming the singular
universal technology of fixed infrastructure LANs over the past twelve or so years.

Ethernet WANs use the same familiar industry-standard technologies which have evolved from early
Ethernet LAN Bridging and Switching, including:

● Ethernet MAC addresses are used for forwarding traffic, with conventional MAC address 'learning'
used by WAN Access points. Edge switches learn which addresses exist on particular paths through
the WAN and maintain a table of addresses such that only packets destined for a given address are
forwarded across the appropriate WAN link, improving overall network performance.

● 'Virtual LAN' (VLAN) constructs are accommodated. VLANs definitions may be applied, using a
number of different criteria, to groups of devices on one or more LAN segments which can then be
treated as members of the same physical network whilst remaining logically separate for security or
performance purposes. Single or multiple 'VLAN Tags' (i.e. packets embedded within in the Ethernet
frame header) are applied to denote such logical groupings and may be either embedded within the
data stream in a customer network prior to presentation to the WAN service, or added by the Service
Provider at the point of access to the WAN, as a mechanism for determining destination paths across
the WAN. Since multiple VLAN tags may exist within the Ethernet frame header structure, then they
become an important aspect of packet handling in both LAN and WAN.

● Support for CoS, alternatively known as 'Quality of Service' (QoS). LAN users are familiar with the
application of prioritisation (typically defined by the application of the 802.1p prioritisation field to the
VLAN header of an Ethernet frame) to signify the relative importance of handling particular frames,
corresponding to certain traffic types, in a timely manner. At the WAN edge, Packets of different
prioritisation are generally applied to different queues which may be then serviced at different rates
for preferential transmission into the WAN. This is particularly significant for real-time applications
such as VoIP, which is generally prioritised over less critical Internet data.

As noted previously, Ethernet WAN services can be either point-to-point or multipoint in nature.

Ethernet WAN services offer a number of potential benefits to both customer and Service Provider,
including scalability, reliability, reduced complexity, management and flexibility. Ethernet WAN services
have the following key characteristics:

● Routing control is retained by the customer
Unlike the case of IP VPNs, Routing control in the WAN is maintained by the enterprise customer.
Certain enterprises prefer not to share their routing topology and schema and do not wish to
outsource this potentially sensitive aspect of their operational control. With an Ethernet WAN service,

Page 5 of 12

the customer implements and maintains fully its own end-to-end network routing decisions. The
customer can change its routing environment according to the evolving requirements of the
enterprise, without having to involve the Service Provider, thus retaining a greater degree of control
over security.

● Protocol transparency
Ethernet WANs have the inherent ability to transport all legacy application protocols. Ethernet is a
'Layer-2' protocol and can support any higher-order network protocol, making it an ideal method of
supporting legacy applications that are still in use by some enterprises. It is nevertheless true to say
that by far the majority of traffic in today's networks comprises IP packets.

● Ethernet Operations and Maintenance (OAM)
Ethernet WANs offer a more comprehensive OAM toolkit than historic Layer-2 WAN architectures.
The Metro Ethernet Forum (MEF), the International Telecommunications Union (ITU), and the
Institute of Electrical and Electronics Engineers (IEEE) have developed a number of OAM standard
protocols which provide mechanisms to manage and monitor the performance of communications on
the Ethernet WAN, including, most recently, the ability to monitor the key parameters of Throughput,
Frame Loss, Latency (i.e. traffic delay across the network) and Jitter (i.e. variations in traffic delay).

Comparison summary of Ethernet WAN Services vs. IP VPN
A summary of the essential differences which have been outlined (plus some which are a consequence of
the relative complexities of the two environments) between IP VPN services and Native Layer-2 Ethernet
WAN services, are shown in Table 1 below.

Attributes IP VPN Ethernet Virtual Private Wire Ethernet Virtual Private LAN
Access technology Any Ethernet Ethernet
Enterprise protocol IP only Multi-protocol Multi-protocol
Connection topology Multi-point Layer-3 (IP) Routed Point-to-Point Layer-2 Switched Multipoint Layer-2 Switched
C0S / Q0S Support Yes Yes Yes
SLA Support Yes Yes Yes
Routing responsibility Shared between Service Provider Service Provider for L-2 Switching, Service Provider for L-2 Switching,
and customer customer for L-3 Routing customer for L-3 Routing
Troubleshooting Higher Low Low
complexity
Typical connection 64kbps - 1Gbps 1Mbps - 10Gbps 1Mbps - 10Gbps
speeds
Latency Generally higher than Layer-2 Low Low
services
Provisioning complexity High, close collaboration between Low Low
Service Provider and customer
Complexity of adds, Relatively high, Routing tables to be Point-to-point service only Lower than IP VPN
moves and changes updated, close collaboration required

Bandwidth upgrades Complex, Service Provider must re- Rapid Rapid
provision through Routed network
Cost 'per unit bandwidth' Generally higher than for pure Layer- Generally lower than IP VPN due to Generally lower than IP VPN due to
to the customer 2 services, due to higher complexity lower complexity lower complexity

Table 1. Comparisons between Ethernet and IP VPN WAN Services

In real-word deployments, there is rarely a 'one size fits all' solution, and not surprisingly there are a
growing number of 'hybrid' networks offered by Service Providers, promoting a combination of Ethernet
WAN services and IP VPNs. One such example is that Ethernet WANs can be an excellent choice for
high bandwidth connections between Corporate HQs and Data centres, with IP VPN 'domains' being

Page 6 of 12

used to extend corporate backbone connectivity out to smaller branch office locations serviced by a
variety of Access technologies.

Network Management challenges for the Service Provider
It is not surprising, given the comparison table above, that the key aspects which have been identified by
many market analysis companies over the few years, regarding the likely evolution of Ethernet WAN
services, are the simplicity, familiarity, throughput scalability, latency and, above all low cost (measured
both in terms of initial commissioning and 'through life TCO') of Ethernet services. Current indicators are
that whilst both IP VPN and Ethernet WAN service volumes are growing (to a combined total of over
$80bn during 2016, according to Infonetics), the key factors above are set to drive the growth of Ethernet
WAN services well above that of IP VPN throughout the decade to 2020.

One challenge facing Service Providers in the delivery of both Ethernet Private Wire (or 'E-Line' as
termed by the Metro Ethernet Forum) and VPLS (or 'E-LAN') services is already well known by those
providers choosing to offer 'Wires-Only' Ethernet connections today for IP VPN services. Consider the
model in Fig. 4 below;
Value-Added
NOC Services

INTERNET
PSTN
(via SIP G/W)
Service Provider
Core Network
Service Provider provisions
and manages Routers and IP/ MPLS
IP addressing schema

Customer Customer
Service Provider's
Site A Site B
Managed CPE Routers

Customer Customer
Ethernet demarcation demarcation Ethernet
connection connection

Fig. 4: IP VPN with Managed CPE Routers

In this classic Service Provider topology, the provider has full manageability not only of the core MPLS
network, but also right up to the point of the Customer's LAN connections, i.e. via Managed 'Customer
Premise Equipment' (CPE) Routers.

As we've said earlier, not every customer will wish to pay the premium for an edge Router device to be
installed, configured and managed by the Service Provider within their own premises. Moreover, many
Service Providers look to third party Integrators and Resale partners to promote their core services, but
such partners often wish to bring their own 'added value' to their customers, including providing
management of their WAN environment, for which they may wish to install their own managed Routers at
customer premises, in place of those of the Service Provider shown in Fig. 4.

Either way, the Service Provider is faced with offering a so called 'wires only' service, for which they have
no physical equipment at the actual point of connection to the ultimate customer's LAN.

So, what's the problem with this? Well, the picture of Fig. 4 is somewhat simplified. In reality, most often
the Service Provider is not actually the same company which provides the physical copper or fibre over
which the core WAN connects into the customer site. Even those large National Carriers such as BT,

Page 7 of 12

which owns the majority of 'last mile' infrastructure in the UK, may be forced by the terms of Telecoms
market deregulation, to separate control of that infrastructure via a largely independent company, in BT's
case OpenReach. Consider now the more complete case shown in Fig. 5.

Value-Added
NOC Services

INTERNET PSTN
(via SIP G/W)
Service Provider
Core Network
Service Provider must still
take an active role in
IP addressing schema IP/ MPLS

Infrastructure Carrier Infrastructure Carrier
Ethernet Circuit Ethernet Circuit
(Typ. via wholesale) (Typ. via wholesale)
Problem!
Lack of Management Customer
Customer Visibility here for the SP Site B
Site A

Customer demarcation
(Ethernet connection)

Customer's Routers

Fig. 5: 'Wires only' IP VPN showing 3rd party 'Tail' circuits to customer premises

In this case, we see that the customer site Router equipment is now owned by the customer themselves
(or alternatively by an Integration partner of the Service Provider, but either way not by the MPLS WAN
network provider). Moreover, the connection from the core MPLS network to the customer site is now
shown provided by 3rd party 'tail circuits', typically supplied via wholesale arrangements. In fact, these tails
may not simply comprise a straightforward 'last mile' connection, but may be quite complex, involving
potentially more than one infrastructure provider, and extending from wherever the customer requires
connection back to the location of the Service Provider's nearest point of MPLS network presence.

In this increasingly common scenario, we see that the Service Provider not only has no visibility at the
point of connection to the customer's LAN, but that in the worst case there may potentially be a long and
complex multi-hop, multi-organisation link from the customer's site back to the nearest point of
management access for the Service Provider. It's quite easy to understand how this can lead to a great
deal of planning complexity for the Service Provider at the time of initial commissioning, and a real
challenge for any subsequent troubleshooting. It is very often the case that the Service Provider has no
rd
visibility inside the 3 party infrastructure and must either be reliant on a strong SLA for each such link, or
be prepared, at considerable cost, potentially to dispatch skilled staff with relatively complex test
equipment in order to be able to check different elements of the network well outside of the MPLS core.

So, if this can be the case for Service Providers using Ethernet as an access vehicle for IP VPN networks
over MPLS, what happens in the case of 'pure' Layer-2 Ethernet WAN deployments?

Essentially, the picture is little different, except that in this case the Service Provider will definitely not be
installing an Edge Router as a customer CPE, since Layer-3 Routing architecture is always the
responsibility of the customer in the case of Ethernet WANs. Just as in Fig. 5, the Service Provider lacks
visibility at the point of customer connection, which may typically be either to a Router or in fact directly to
an Ethernet LAN switch.

Page 8 of 12

In both the case of wires only IP VPN and full Ethernet WAN deployments, one answer to the problems
highlighted above is for the Service Provider to deploy, for all such connections, a manageable 'Ethernet
Demarcation Device' (EDD), sometimes alternatively known variously as a 'Network Interface Device'
(NID) or 'Network Termination Unit' (NTU). Fig. 6, below, shows the example of an Ethernet WAN service
terminated with basic EDDs at the customer premises.

Value-Added
NOC Services

Ethernet Service
Management Provider Core Network Management
Access (MPLS with L-2 VPN or Access
VPLS)

Customer Infrastructure Carrier Infrastructure Carrier Customer
Site A Ethernet Circuit 1 Ethernet Circuit 2 Site B

Service Provider Service Provider
demarcation Basic Ethernet Demarcation Devices provide End- demarcation
Point Manageability, typically via dedicated
Management 'Carrier VLAN' (Q-in-Q S-Tag), or via
protected 'Customer VLAN' (Reserved C-Tag)

Fig. 6: Ethernet WAN service including Ethernet Demarcation Devices

The role of Ethernet Demarcation Devices is, at minimum, to provide management visibility and
information regarding the customer connection point. At the least, they should be able to indicate
connection status and traffic levels looking both towards the core network and towards the customer's first
connected device.

For Ethernet WAN networks, such as that of Fig. 6, it is possible that seamless end-to-end Ethernet
connectivity exists between customer end-point sites (shown as 'Site A' and 'Site B' above), which
enables the possibility for more advanced diagnostic and monitoring services to be available from the
EDD units in relation to the full end-to-end link. In the case of Ethernet used as an Access technology for
an IP VPN network, it's likely instead that management visibility from the Service Provider's 'Network
Operations Centre' (NOC) might be limited to individual 'core to customer-site' links. Nevertheless, in
either case, such visibility and diagnostic tools offer considerable benefits in terms of network
commissioning and troubleshooting, more than offsetting the comparatively low cost of EDDs.

As shown in Fig. 6, in a Switched Ethernet WAN normally specific 'VLAN Tagging' is used to differentiate
User traffic from the Service Provider's Management traffic, and the EDD should be sufficiently flexible to
offer a number of different Tagging modes by which to identify and isolate both Management traffic and
indeed potentially different classes of User traffic.

Let us finally consider a more comprehensive picture of a typical Point-to-Point example of an Ethernet
WAN service, as shown in Fig. 7. In this case, we have highlighted the fact that it may very well be the
case (as for BT OpenReach 'EAD' Services in the UK, for example) that the tail circuit provider is able to
offer the main Service Provider information about the status of such individual links, including both
connection status and even potentially validation to specific Service Level Agreements (SLAs) relating to

Page 9 of 12

characteristics of the tail circuit. Nevertheless, since any given tail may comprise one or more links and
the tail servicing 'Customer Site A' may not be sourced from the same Infrastructure provider as that
servicing 'Customer Site B', this may be of little overall benefit to the end-to-end Service Provider,
particularly because it is unlikely that the tail circuit provider will make available direct Management
access to their own demarcation devices, if indeed such devices are deployed.

Value-Added
NOC Services

Management Ethernet Management
Access Service Provider Access
Core Network

Customer Infrastructure Carrier Infrastructure Carrier Customer
Site A Ethernet Circuit 1 Ethernet Circuit 2 Site B

Carrier 1 Carrier 2
Circuit 1 SLA SLA Circuit 2
demarcation demarcation

Service Provider Service Provider
Service Provider's
demarcation demarcation
End-to-End SLA

Infrastructure Carriers may offer a clear SLA for their short or long-haul circuits, but this does
not provide full end-to-end SLA assurance. Advanced EDD equipment offers this functionality

Fig. 7: End-to-end SLA verification and monitoring facilitated by Advanced EDDs

By deploying their own advanced EDDs at each end of the link above, the Service Provider can,
irrespective of the number and variety of 3rd party tail circuits, potentially verify both the connection status
and Service characteristics of the complete end-to-end link.

Management visibility vs Performance assurance
Over the past few years, each of three Industry standards bodies, namely the Institute of Electrical and
Electronic Engineers (IEEE), the International Telecommunications Union (ITU) and the Metro Ethernet
Forum (MEF) have been active in developing and promoting both capabilities and standards in relation to
Carrier (i.e. WAN) Ethernet Services. Most significantly, with respect to the challenges which we have
discussed here, a number of 'Operations, Administration and Management' (OAM) protocols have been
developed relating to Ethernet WAN deployments.

Relatively simple visibility and connectivity checking of single segment Ethernet connections is supported
by the 'Link OAM', or 'Ethernet First Mile' (EFM) protocol, formalised initially as IEEE 802.3ah, by which it
is still generally best known, albeit that this functionality has now been fully incorporated into the core of
the 802.3 standard itself.

An additional level of connectivity assurance is offered by those Demarcation Devices including the
'Connectivity Fault Management' (CFM) protocol, formalised under the standard IEEE 802.1ag. CFM
offers the ability for a number of end-point devices to establish and monitor a 'community' of reachable

Page 10 of 12

end-points and mid-points corresponding to a customer's network, which can offer some degree of pro-
activity to the Service Provider with regard to connectivity fault detection.

Above and beyond connectivity management though, customers are increasingly asking of their Service
Providers that they provision multiple traffic streams across their Ethernet 'pipe' connections, to which
potentially different criteria may apply for key network performance parameters, including acceptable
frame loss ratio, 'latency' (i.e. traffic delay)and 'jitter' (delay variation), together with comprehensive traffic
throughput 'policing'.

In more advanced deployments, a Service Provider may need to provision multiple services per physical
Ethernet connection. They may then be faced with the challenge to demonstrate to their customer, at the
time of provisioning, that specific performance parameters are complied with for each individual Service
data stream within a given end-to-end Ethernet connection. Such parameters may be detailed within a
tightly defined 'Service Level Agreement' (SLA), to which compliance should be verified.

Furthermore, Service Providers may not only need to demonstrate SLA compliance at the time of
commissioning, but they may be required to subsequently monitor 'in service' traffic and take pro-active
steps with regard to any potential breach of SLA.

Ethernet Demarcation Devices equipped with more advanced packet processing capabilities can offer a
very effective tool to Service Providers in this regard. For example if a Service Provider, from a Network
Operations Centre, can interact with an EDD in such a manner as to configure this device to issue one or
more test traffic streams across the network to a corresponding remote end-point, at which traffic may be
'looped' and returned, this can be highly beneficial. Such test stream(s) can enable accurate reporting of
throughput, packet loss, latency and jitter, for the end-to-end network link. Demarcation Devices with such
capabilities are now available. Necessarily, such devices contain more than simple switch and
management processing functionality. Dedicated packet processing hardware is required in order to
ensure accurate time-stamping, test collation and reporting in real-time for line rates up to 1Gbps and
beyond.

Another of the OAM protocols, this time the ITU-T's Y.1731 suite, relates to the ability to provide in-
service testing and reporting of SLA compliance, which is very much to the fore in the MEF's definitions
for Carrier Ethernet service and to which is often referred as 'Performance Assured Ethernet' (PAE).

All of these capabilities, incorporated within the most recent generation of Advanced Ethernet
Demarcation Devices, combine to make these an extremely useful addition to the Service Provider's
portfolio of devices to ensure that their customers experience strength and depth in support.

Metrodata Ltd Ethernet Demarcation Devices
Metrodata Ltd. is a long-standing UK developer and manufacturer of Interface Conversion and Network
Access solutions. The company has been a supplier to Governments, Corporations and Telecoms
Service Providers worldwide since 1989.

Within the company's MetroCONNECT range of Ethernet Service Delivery solutions, Metrodata offers
both Basic and Advanced Demarcation Devices for use with both wires-only IP VPN and Layer-2 Ethernet
WAN solutions.

The FCM9002 product supports Copper (RJ45) or Fibre (SFP) Network Connection up to 1Gbps with
RJ45 connectivity to Customer equipment. Management visibility is offered to Customer site connections
and the product supports the OAM protocols of IEEE 802.3ah (EFM) and IEEE 802.1ag (CFM). One of
the most common frustrations experienced by Service Providers is that of network faults being reported
from customers which eventually are found to be due to simple power-downs of interface equipment. The
FCM9002 provides indication of local power-down to the Service Provider via both SNMP Trap and OAM
protocol alerting when power is withdrawn from the device (or alternatively should the PSU of the EDD
itself fail).

Page 11 of 12

The advanced FCM9004 Demarcation Device additionally supports a range of functions above and
beyond simple end-point visibility, at a very cost-effective price point, making this a natural choice for
Service Providers for CPE installation for services in the range of 100Mbps to 1Gbps.

Fig. 8: MetroCONNECT FCM9004 Ethernet Demarcation Device
(AC and -48V DC PSU variants)

In addition to the features of the FCM9002, the FCM9004 offers:

 Service Multiplexing with advanced C-Tag, Q-in-Q S-Tag and Multi-Tag VLAN handling
 Per-flow Traffic Policing and Colour Marking for multiple services up to 1Gbps
 ITU-T Y.1731 for in-service performance monitoring and alerting
 Dedicated hardware Service Assurance Module, 'MetroSAM', providing 'Performance Assurance'
capabilities for Core-Edge and End-End network applications, including:
 Embedded wirespeed test traffic generator with packet time-stamping
 Layer 2/3 SA/DA Loopback for assurance measurement over extended networks
 Throughput, Frame Loss Ratio, Frame Latency and Jitter analysis
 Off-line configuration toolset to enable remote profiling of customer connection requirements prior to
installation
 Zero Touch Commissioning (ZTC) toolset, enabling simple installation with automatic detection and
download of pre-prepared configuration

Full information regarding the MetroCONNECT family of Ethernet Demarcation Devices, may be found
here:

http://www.metrodata.co.uk/solutions/ethernet-extension/carrier-ethernet-demarcation-devices.htm

Metrodata Ltd.
Fortune House, Eversley Way
EGHAM, Surrey TW20 8RY U.K.

+44 (0)1784 744700
sales@metrodata.co.uk
www.metrodata.co.uk

Page 12 of 12

White Paper: IP VPN and Ethernet WAN Services

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to White Paper: IP VPN and Ethernet WAN Services

Similar to White Paper: IP VPN and Ethernet WAN Services (20)

Recently uploaded

Recently uploaded (20)

White Paper: IP VPN and Ethernet WAN Services