Академический Документы
Профессиональный Документы
Культура Документы
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.
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.
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
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
Corporate HQ
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
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.
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
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.
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:
● 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.
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
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
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
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,
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
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.
Value-Added
NOC Services
Ethernet Service
Management Provider Core Network Management
Access (MPLS with L-2 VPN or Access
VPLS)
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
Value-Added
NOC Services
Carrier 1 Carrier 2
Circuit 1 SLA SLA Circuit 2
demarcation demarcation
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
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.
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
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.
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).
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.