White Paper: IP VPN and Ethernet WAN Services

Carrier Ethernet Services

Ethernet WAN Services Page 1 of 12

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.

Fig. 1: Each Router in a traditional IP Router network must make 'next hop' forwarding

decisions for each packet in turn

A

B

C

D E



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.

Fig. 2: Multi-access IP VPN Network

Internet

Corporate HQ

Ethernet 1Gbps

Remote Sites

ADSL SDSL

Home Workers

ADSL

Regional Office

2Mbps 'E1' Leased Line

Secure AccessFor Home & Mobile

Workers

IP VPN over MPLS Core Network

Storage and Application Servers

Internet

Corporate HQ

Ethernet 1Gbps

Remote Sites

ADSL SDSL

Home Workers

ADSL

Regional Office

2Mbps 'E1' Leased Line

Secure AccessFor Home & Mobile

Workers

IP VPN over MPLS Core Network

Storage and Application Servers



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.

Fig. 3: A full mesh of pseudowires is

used to connect all provider edge (PE) devices supporting a given VPLS VPN

PE PE

PE

CustomerSite

CustomerSite Customer

Site

CE (typically a switch)

CECE

MPLS CORE NETWORK

MeshedPseudowire

Links

Layer-2 EthernetVC Connections

PE PE

PE

CustomerSite

CustomerSite Customer

Site

CE (typically a switch)

CECE

MPLS CORE NETWORK

MeshedPseudowire

Links

Layer-2 EthernetVC Connections



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



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,



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.

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

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 and customer

Service Provider for L-2 Switching, customer for L-3 Routing


Troubleshooting complexity

Higher Low Low

Typical connection speeds

64kbps - 1Gbps 1Mbps - 10Gbps 1Mbps - 10Gbps

Latency Generally higher than Layer-2 services

Low Low

Provisioning complexity High, close collaboration between Service Provider and customer

Low Low

Complexity of adds, moves and changes

Relatively high, Routing tables to be updated, close collaboration required

Point-to-point service only Lower than IP VPN

Bandwidth upgrades Complex, Service Provider must re-provision through Routed network

Rapid Rapid

Cost 'per unit bandwidth' to the customer

Generally higher than for pure Layer-2 services, due to higher complexity

Generally lower than IP VPN due to lower complexity


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 and customer



Troubleshooting complexity

Higher Low Low

Typical connection speeds

64kbps - 1Gbps 1Mbps - 10Gbps 1Mbps - 10Gbps

Latency Generally higher than Layer-2 services

Low Low

Provisioning complexity High, close collaboration between Service Provider and customer

Low Low

Complexity of adds, moves and changes

Relatively high, Routing tables to be updated, close collaboration required

Point-to-point service only Lower than IP VPN

Bandwidth upgrades Complex, Service Provider must re-provision through Routed network

Rapid Rapid

Cost 'per unit bandwidth' to the customer

Generally higher than for pure Layer-2 services, due to higher complexity





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;

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,

CustomerSite A

NOC

CustomerSite B

Value-AddedServices

INTERNET

Service ProviderCore Network

PSTN(via SIP G/W)

IP/ MPLS

Service Provider'sManaged CPE Routers

Customerdemarcation

CustomerdemarcationEthernet

connectionEthernet

connection

Service Provider provisions and manages Routers and

IP addressing schema

CustomerSite A

NOC

CustomerSite B

Value-AddedServices

INTERNET


PSTN(via SIP G/W)

IP/ MPLS

Service Provider'sManaged CPE Routers

Customerdemarcation

CustomerdemarcationEthernet

connectionEthernet

connection

Service Provider provisions and manages Routers and




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.

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 visibility inside the 3rd 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.

Problem!Lack of Management

Visibility here for the SP

Problem!Lack of Management

Visibility here for the SPCustomerSite A

NOC

CustomerSite B

Value-AddedServices

INTERNET


Customer's Routers

IP/ MPLS

Infrastructure CarrierEthernet Circuit

(Typ. via wholesale)

Infrastructure CarrierEthernet Circuit


Service Provider must still take an active role in


PSTN(via SIP G/W)

Customer demarcation(Ethernet connection)



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.

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

CustomerSite A

Ethernet ServiceProvider Core Network(MPLS with L-2 VPN or

VPLS)

NOC

CustomerSite B

Service Providerdemarcation

Value-AddedServices


Infrastructure CarrierEthernet Circuit 2




Basic Ethernet Demarcation Devices provide End-Point Manageability, typically via dedicated

Management 'Carrier VLAN' (Q-in-Q S-Tag), or via protected 'Customer VLAN' (Reserved C-Tag)

ManagementAccess

ManagementAccess



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.

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

CustomerSite A

Service Provider'sEnd-to-End SLA

EthernetService Provider

Core Network

NOC

CustomerSite B

ManagementAccess

Circuit 1demarcation

Circuit 2demarcation

Carrier 1SLA

Carrier 2SLA


Value-AddedServices


ManagementAccess

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







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).



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 [email protected] www.metrodata.co.uk

Technology

White Paper: IP VPN and Ethernet WAN Services