1. Introducing the Specifications of the Metro Ethernet Forum

2. Introducing the Specifications of the Metro Ethernet Forum
MEF 2 Requirements and Framework for Ethernet Service Protection
MEF 3 Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks
MEF 4 Metro Ethernet Network Architecture Framework Part 1: Generic Framework
MEF 6 Metro Ethernet Services Definitions Phase I
MEF 7 EMS-NMS Information Model
MEF 8 Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks
MEF 9 Abstract Test Suite for Ethernet Services at the UNI
MEF 10 Ethernet Services Attributes Phase I
MEF 11 User Network Interface (UNI) Requirements and Framework
MEF 12 Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer
MEF 13 User Network Interface (UNI) Type 1 Implementation Agreement
MEF 14 Abstract Test Suite for Ethernet Services at the UNI
MEF 15 Requirements for Management of Metro Ethernet Phase 1 Network Elements
MEF 16 Ethernet Local Management Interface
* MEF 10 * replaced MEF 1 and MEF 5

3. This Presentation Purpose Audience Other Documents
This presentation is intended as an introduction and companion to both the MEF 3 and MEF 8 Specifications
These are the two principal specifications relating to services that carry Circuit Emulation/TM traffic across Carrier Ethernet
Audience
It is intended for Product Marketing, Engineering staff of member companies, for members of other standards bodies, Enterprise networking staff, and service providers who
Would like a quick overview of the specifications
Plan to read the specifications in detail
Other Documents
Presentations of the other specifications and an overview of all specifications is available on the MEF web site
Other materials such as white papers and case studies are also available

4. MEF Specifications Overview
Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks
Purpose
Circuit Emulation Service “tunnels” TDM traffic through a Metro Ethernet network allowing inclusion of legacy networks within a Carrier Ethernet environment
Audience
Equipment Manufacturers supporting devices that provide Circuit Emulation over Carrier Ethernet Services. Useful for Service Providers architecting their systems.
Technical Committee Service Area
MEF 8
Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks
Purpose
Gives precise instructions for implementing interoperable CES equipment that reliably transport TDM circuits across Metro Ethernet Networks while meeting the required performance of circuit emulated TDM services as defined in ITU-T and ANSI TDM standards
Audience
Equipment Manufacturers supporting devices that provide Circuit Emulation over Carrier Ethernet Services. Useful for Service Providers architecting their systems.
Technical Committee Service Area

5. MEF 3: CES Framework & Requirement MEF 8: CES Implementation Agreement
Industry’s first formal definition of CES standards over Ethernet
A services description
Types of TDM services offered over Metro Ethernet,
PDH and SONET/SDH
DS1E1, DS3/E3, OC-3/STM-1, OC-12/STM-4
A requirement document
Comprehensive CES requirements for providing TDM services over Ethernet
SLA service quality parameters as specified by the ITU for TDM services
An implementation agreement for Ethernet
Practical agreement as to how to implement the CES over Ethernet

6. What is Circuit Emulation Service over Carrier Ethernet?
Circuit Emulation Service “tunnels” TDM traffic through a Metro Ethernet network
packet network “emulates” a circuit-switched network, re-creating the TDM circuit at the far end
invisible to TDM source and destination equipment
runs on a standard Ethernet Line Service (E-Line)
Metro Ethernet Network
This slide is the intro to CES. The main message is that the T1/E1 stream passes through the MEN transparently and that the timing and signalling is also transmitted.
TDM Circuits
(e.g. T1/E1 Lines)
TDM Circuits
(e.g. T1/E1 Lines)
TDM Pipe

7. MEF 3 TDM Circuit Emulation
Support Traditional PDH/SONET/SDH hand-offs to existing customer voice equipment
Allow Interworking onto Ethernet EVCS across the MEN.
Unstructured is a mere transparent pass through of TDM traffic.
- Requires tight E-LINE SLAs for this traffic but not much more on the providers part
Structured allows for more efficient handling of traffic – at lower rates without the TDM (SONET/SDH) overhead
- Allows for more value added service provider functions, and potentially less bandwidth.
Types: 1)Unstructured - all bits in must be sent across to the destination
2) Structured - Requires only sending TDM payloads not the over head

8. Circuit Emulation Services Relationship to the Metro Ethernet Network
MEF 3 specifies how the TDM and circuit emulation functions inter-work with the concepts for supporting Ethernet services across a MEN as laid out and defined in MEF 5 and MEF 10.
The Goal is to allow TDM Circuits to be emulated and transported over Ethernet virtual circuits across a MEN and Recovered and converted back to TDM traffic on the other side.
This slide lays out the major functions and how they interact. The following slide defines the CES functions as specified in MEF 3.
CES functions in relation to those specified by the MEF for the MEN

9. Functions Defined
TSP - Optional TDM mux/demux function –prior to Ethernet interworking
IWF - Interworking function of TDM to Ethernet frames
ECDX - Identifier function for proper forwarding and demultiplexing
EFTF –Addressing and FCS functions.
Model concept and nomenclature as defined in MEF 3.
Major required functions:
Interworking of TDM traffic into Ethernet Frames (Including the optional multiplexing of individual lower rate circuits at the TDM layer into a single TDM circuit prior to interworking into Ethernet frames)
Identifier function –for proper end to end processing of multiple CES circuits, and marking for MEN routing of traffic
Destination addressing and marking for MEN routing of traffic

10. Functions applied
MEN
This slide provides more detail (Specified in MEF 8) as to what actions apply at each of the functional areas as previously defined.
TXP is optional as a TDM circuit multiplexing function and is not specified in MEF 3 or 8.
IFW as describer earlier encapsulates the TDM frame or just the payload (Structured service) into an Ethernet frame
ECDX multiplex multiple CES frames together if required for delivery over a single EVC. This is useful for aggregating separate generated CES circuits prior to entering the MEN for delivery to a single destination. It also makes the frames with a unique identifier (ECID) and Markets the Ether type so other devices in the MEN will know it contains CES traffic
EFTF provides the Final Addressing for transport into and from the MEN
ECDX as shown is effectively a multiplexing function allowing multiple CES circuits to share a single EVC

11. Functional Layering, and mapping onto encapsulation headers
This slide depicts the functions as they are applied within the protocol stack for each Ethernet CES frame that transits the MEN.
Treats the MEN as a “virtual wire” between two TDM networks

12. MEF Service Definitions
TDM Line Service (T-Line):
Application: Leased line replacement
Customer
Premises
Customer
Premises
CESoETH
CES IWF
CES IWF
TDM
Ethernet
Metro Ethernet Network
Ethernet
TDM
MEF 3 defines 3 types of services. The first is a service provider based circuit emulated TDM service that runs between two customer sites. This allows an Ethernet service provider to provide connectivity for TDM based customer traffic – without changes required by the customer. Benefit is convergence – allowing the Ethernet service provider to carry both Ethernet and TDM based traffic over the same access link/ network core.
E-Line Service
Ethernet UNI
Ethernet UNI
Service Provider Network
TDM subscriber demarcation
TDM subscriber demarcation

13. MEF Service Definitions
TDM Access Line Service (TALS):
Application: Access to a remote network (e.g. PSTN)
Customer
Premises
CESoETH
CES IWF
CES IWF
PSTN
TDM
Ethernet
Metro Ethernet Network
Ethernet
TDM
The 2nd is a service provider based circuit emulated TDM service that runs between a customer site and another providers TDM network (Such as the PSTN). This allows an Ethernet service provider to provide connectivity for TDM based – PSTN bound customer traffic – without changes required by the customer. Benefit is access link convergence – allowing the Ethernet service provider to carry both Ethernet and TDM based traffic over the same access link. The MEN can route the Ethernet data traffic as needed via EVC(s) to other customer sites, while it sends the TDM traffic over a separate EVC bound for the PSTN network hand-off location.
E-Line Service
Ethernet UNI
Ethernet UNI
Service Provider Network
TDM subscriber demarcation
TDM Network Interface

14. MEF Service Definitions
Customer-Operated CES:
Application: Toll-bypass
Customer
Premises
Customer
Premises
CESoETH
CES IWF
CES IWF
TDM
Ethernet
Metro Ethernet Network
Ethernet
TDM
The 3rd is a variant on the first. Where the Customer provides the CES interworking function and connects to a service provider based Metro Ethernet service. This allows the customer to control its own traffic and use any Ethernet service provider to provide connectivity for TDM and Ethernet based customer traffic. Benefit is low service charges to support convergence between sites.
Note the customer needs to find a MEN service that conforms to traffic handling requirements that can adequate support the quality required to regenerate the TDM traffic.
E-Line Service
Ethernet UNI and subscriber demarcation
Ethernet UNI and subscriber demarcation
Service Provider Network

15. Structured Vs Unstructured CES
Comparison of Structured vs. unstructured frame formats. Unstructured passes all traffic received. Its simpler in that the TDM overhead –including signaling, timing and fault detection (Alarms) are preserved and passed through end to end. This limits the MEN’s need to perform/participate in these functions
Structured strips off the TDM overhead and just passes the voice payloads. It allows for more efficient use of MEN bandwidth, fewer circuits, and better network aggregation. But it also requires the IWF function to participate in the handling of signaling, timing and fault detection (alarm) functions.
Unstructured allows for transparent tunneled TDM services - that are easy to set up, and run along side other data services, only proper QoS is required of the MEN to ensure timely packet delivery. Customer-Operated CES service is an unstructured CES service example.

16. TDM services supported (MEF 3)
TDM Service Interface
Unstructured TDM Service
Structured TDM Service
Structured TDM Service Granularity
DS1
Yes
Nx64 kbit/s
DS3
DS1, Nx64 kbit/s E1 E3
E1, Nx64 kbit/s, DS0
OC-1
STS-1, VT-1.5, VT-2
OC-3
OC-3c
STS-3c
STM-1
VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other)
STM-1c
VC-4, VC-3, VC-11, VC-12
OC-12
VT-1.5 (DS1), VT-2 (E1), STS-1 (DS3, E3, other), STS-3c
OC-12c
STS-12c
STM-4
VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other), VC-4
STM-4c
VC-4-4c
TDM (PDH and SDH/SONET) service types supported as defined by MEF 3. PDH services down to the Nx64, DS1 and E1 levels are specified ranging up to E3 and DS3 at fractional Nx64 structured TDM service granularity.
Synchronous services (SONET and SDH) services are also specified ranging from OC1- OC12 for SONET and STM1 to STM 4 for SDH

17. MEN CoS Performance Parameters
To ensure proper CES IWF operation service quality:
Ethernet Frame Delay should be minimized
to meet MEF 5 defined parameters
Ethernet Frame Delay Variation
MEN EVCS jitter up to 10 ms max
Ethernet Frame Loss
ESR and SESR should meet TDM requirements
Network availability
should meet 99.95% TDM requirement
MEN CoS performance Requirements as specified in MEF 3. These have been determined by the MEF to provide the proper thresholds to ensure the MEN can meet the network requirements as spelled out by the ITU for maintaining toll grade voice quality.
More detail is provided in MEF 10 as how Frame Delay and Frame Delay variation is measured,

18. PDH Interoperability Agreement –MEF 8
Specifies Interoperability requirements for:
Connectivity
Timing
Signaling
MEN performance criteria
MEN services OAM
MEF 8 provides further detail on how to implement the requirements specified in MEF 3 when supporting PDH services over a Metro Ethernet Network (MEN).
In particular these 5 functions are specified with particular attention paid to Connectivity, Timing and Signaling issues for structured Ethernet services. MEN performance criteria specified in MEF 3 is supplemented as well

19. Emulated Circuit Identifier
ECID
– identifies the emulated circuit being carried.
Separates the identification of the emulated circuit from the Ethernet layer,
allowing the MEN operator to multiplex several emulated circuits across a single EVC where required.
This is added by the ECDX.
ECID – identifies the emulated circuit being carried.
Separates the identification of the emulated circuit from the Ethernet layer, this allows the MEN operator to multiplex several emulated circuits across a single EVC where required.

20. CESoETH control word Provides sequencing and signaling of defects
such as AIS of the TDM circuit, or packet loss detected in the MEN.
This is added by the CES IWF.
L Local TDM failure: when set, indicates that the MEN-bound IWF has detected or has been informed of a TDM defect impacting the TDM data. When the L bit is set the contents of the frame may not be meaningful, and the payload may be suppressed in order to conserve bandwidth.
R Remote Loss of Frames indication: when set by a MEN-bound IWF, the R bit indicates that its local TDM-bound IWF is not receiving frames from the MEN, and consequently has entered a Loss of Frames State (LOFS). Thus the setting of the R bit indicates failure of the connection in the opposite direction. This may indicate MEN congestion or other network related faults.
M Modifier bits: set by the MEN-bound IWF to supplement the meaning of the L bit, as shown in MEF 8 Table 6-1
FRG Fragmentation bits – This field is used for fragmenting multiframe structures into multiple CESoETH frames.
LEN Length – This is an unsigned binary number indicating the length of the payload, should the CESoETH frame require padding to meet the minimum frame size of 64 octets. The length of the payload is defined as the sum in octets of the following quantities:
size of the CESoETH control word (4 octets)
size of the optional RTP header (12 octets, if present)
size of the TDM payload;
Where the length equals or exceeds 42 octets, the Length field shall be set to zero. Therefore a non-zero length field indicates the presence of padding. (Note: the payload length does not include the size of the ECID defined in section )
SN Sequence number – a 16 bit unsigned binary number which increments by one for each frame sent. It wraps to zero, in common with the behavior of the RTP sequence number. The receiving IWF uses it primarily to detect frame loss and to restore frame sequence.

21. Standards for Synchronization
E1 standards (2.048 Mbps)
Traffic interface (G.823, Table 2)
18 s over 1000s
T1 standards (1.544 Mbps)
Traffic interface (T1.403, section )
8.4 s over 900s
18 s over 24 hours
Central Office
Remote Terminal
Customer
Premises
PRS
PSTN
PSN
CESoP IWF
CESoP IWF
TDM
Equipment
TDM services have strict synchronization of timing requirements to provide what is known as toll grade voice quality
ITU has specified limits to variation in the timing used to recover the voice traffic from one end of network to another.
These requirements must be maintained through a MEN just like any other network.
T1/E1
T1/E1
CES induced wander < 18 ms
Max. end-to-end wander (traffic interface) 18 ms

22. Timing
Synchronous services require timing be provided
Line, through, external or internal timing mode options
Applies to structure aware only
Synchronization.
the clock used to play out the data at the TDM-bound IWF must be the same frequency as the clock used to input the data at the MEN-bound IWF,
otherwise frame slips will occur over time
A means to provide timing is critical for structure aware services
Timing must meet the Delay and Jitter specs as defined for TDM services by the ITU etc….
There are several timing options as we will discuss on the next slide.

23. Timing options TDM line timing External timing Free run timing
use the clock from the incoming TDM line
External timing
use an external reference clock source
Free run timing
use a free-running oscillator
Ethernet line timing
recovering the clock from the Ethernet interface
Line timing (from the CE) – This mode is used to recover timing from a CE. In order for this timing mode to PRS traceable, the CE must be provisioned to recover and transmit PRS traceable timing. Line timing should be used if synchronization messaging is available (e.g., SONET or SDH line timing sources).
Line timing (from the MEN) – This mode is used to recover timing from the MEN. In order for this timing mode to be PRS traceable, the adjacent Ethernet NE (in the MEN) must be provisioned to recover and transmit PRS traceable timing. Line timing should be used if synchronization messaging is available (e.g., SONET or SDH line timing sources). Line timing can also include deriving a clock from incoming Ethernet packets (e.g. use of adaptive or differential clock recovery methods).
External Timing – This mode is used to recover PRS traceable timing from a co-located building integrated timing supply (BITS). Timing is typically sent to the TSP/IWF as an all ones DS1 or E1 with framing. Synchronization status messaging (SSMs) may also be transmitted over the DS1 link using a “blue signal” (all ones without framing) or via SSMs on the ESF data link as defined by ANSI T1.101.
Free-Run – This mode is considered a standalone mode. It should only be used when a suitable line or external timing reference is not available. The frequency and stability of this timing mode is determined by the TSP/IWF’s internal oscillator.
Holdover – This mode is usually considered a backup or protection timing mode. Holdover mode may be initiated when the external or line timing references have been lost due to a failure. This failure is indicated to the CES IWF via a loss of frame (LOF), loss of signal (LOS) or SSM indication. Unlike free-run, this timing mode relies on the TSP/IWF’s internal oscillator that has been trained by an external timing reference (e.g., PRS traceable timing source). See ANSI T1.101 for performance specifications of this and other timing modes. Holdover may also be used when there is a cessation of activity on the MEN-bound TDM interface (e.g. due to the normal operation of a variable bit rate IWF).

24. Signaling Structure Aware CESoETH must provide signaling
CE Common Channel Signaling (CCS)
Can be carried within the emulated service data
CE Common Channel Signaling (CAS)
Must be handled separately for Nx64 service Encoding Format for CAS
Note must have a separate Control Word from the Data, but can share same ECID
CE applications interconnected over a CESoETH service may exchange signaling in addition to TDM data. The typical example is telephony applications that exchange their state (e.g. off-hook/on-hook) in addition to TDM data carrying PCM-encoded voice.
With structure-agnostic emulation, it is not required to intercept or process CE signaling. Signaling is embedded in the TDM data stream, and hence it is carried end-to-end across the emulated circuit.
With structure-aware emulation, transport of Common Channel Signaling (CCS) may be achieved by carrying the signaling channel with the emulated service (e.g. channel 23 for DS1, or channel 16 for E1). However, Channel Associated Signaling (CAS) (e.g. DS1 Robbed Bit Signaling or E1 CAS) requires knowledge of the relationship of the timeslot to the trunk multi-frame structure. This is indicated by the framing bits, which may not be preserved by N x 64 kbit/s basic service.
Note

25. Performance Monitoring
Facility Data Link
May monitor but not change DS1 Extended Super Frame message data
Errored Data
CESoETH should be capable of monitoring Frame Error ratio
MEF 3 and 8 allow for the ability to access the performance monitoring payloads available within the TDM layer for PDH & SDH/SONET services. Note they prohibit the altering or manipulation of this data. This ensures the integrity of this data at TDM layer (Between the TDM end points).

26. MEN Service & SLA Requirements
MEN service quality assurance is critical to maintain consistent quality of the carried TDM service
SLA service quality parameters should support to those specified by the ITU for TDM services
Nx64 Services require CAS Signaling in MEN
SDH/SONET requires pointer adjustments in MEN
Specified MEN Quality Parameters:
Frame Delay: <25ms
Jitter (Delay Variation): <10ms
Frame Loss/Errors Ratio (FER)
For SONET/SDH:
Errored Seconds (ES)
Severely Errored Sec (SES)
Background block SES (BFER)
Maintaining or regenerating timing clock is critical for service quality
Timing Options:
Line timing - from the TDM Customer edge, or Through timing – remote CE derived, or External timing via a BITS, or internal timing via the IWF internal oscillator
SLA service quality parameters are specified to be the same for TDM services as specified by the ITU [G.826]. As well as ANSI [T1.503/.510/.514].
MEN quality parameters have been provided to ensure proper delivery quality
Frame Loss and Frame errors both contribute to diminished voice quality. A measure for both combined is calculated on a per second basis. MEF 3 specifies the error rates and sets three thresholds (Errored Seconds, Severely Errored Seconds and Background block severely errored seconds). MEF 3 specifies acceptable parameters for Frame Delay, jitter, as well as the Frame Loss/Errors Ratio

27. Frame Delay Defined
The time required to transmit a service frame from source to destination across the MEN.
One way frame delay measurement is depicted in this diagram as: First bit in at the ingress UNI to last bit out at the egress UNI. Note these measurements are taken from the MEF 10 specification
Measured from 1st bit in to last bit out

28. Frame Delay Variation Defined
The difference in delay of two service frames. CE CE CE CE
Metro Ethernet
Metro Ethernet
Frame 1
Network
Network
time
first bit in
first bit in
UNI to UNI
UNI to UNI
Frame
Delay
Variation1
Frame
Delay
Frame 2
first bit in
Frame Delay variation depicts the difference in time gap between two subsequent frames at the ingress UNI in comparison to the delay measured between the arrival of the same frames at the egress UNI. Note these measurements are taken from the MEF 10 specification
Frame 1 last bit out
Frame
Delay
Variation 2
Frame 2 Last bit out

29. Frame Loss Defined
Frame loss is a measure of the number of lost service frames inside the MEN.
Frame loss ratio is % = # frames lost / # frames sent
time CE CE CE CE
Metro Ethernet
Metro Ethernet
Network
Network
5000 frames in
UNI to UNI
UNI to UNI
Frame loss is measured as a ratio of the number of frames lost (lost or discarded at egress due to FCS indicated error) measured at the Egress UNI divided by the number of frames sent as measured at the ingress UNI.
Note these measurements are taken from the MEF 10 specification
4995 frames out
5 frames lost/or received as errored
0.1% Frame Loss Ratio (5/5000)

30. MEN Frame Loss Errors – PDH Limits
PDH ES
PDH SES
PDH circuits Frame Loss Errors thresholds per PDH service types are specified in MEF 3 and represented in the graphs above. The following the requirements as spelled out by in [T1.403] for DS1 and [G.704] for E1 .

31. Other MEN Parameters Emulated Circuit Availability
99.95%
Emulated Circuit Restoral
< 50 ms
Suggested MEN Bandwidth increments
100 kbps
Other service parameters will also have an effect on quality consistency. (Consistency of service quality). These include service availability requirements measured end to end, as well as service restoral times for line or node outages.
Finally MEF 3 also recommends (But does not require) a lower bandwidth increment than what is defined in the other MEF service and framework specifications. This will allow for better bandwidth utilization or CES service loading through a MEN.

32. MEF Services OAM Misconnection alarm (section 6.6.1)
Loss of Frames alarm (section 6.6.2)
Late Frames alarm (section 6.6.3)
Malformed Frames alarm (section 6.6.4)
Jitter buffer overrun alarm (section 6.6.5)
The CES should allow the operation of the normal mechanisms for monitoring the performance of the TDM service, as specified in [G.826]. Performance monitoring in line with [G.826] is one-way, and occurs between two end-points.
The MEN needs to perform specific alarm functions for Structured serves as specified in MEF 3 – section 6.
In particular alarms need to be generated by the MEN for EVC circuit misconnections when carrying CES traffic as well Lost, Late or Malformed frame alarms and those for Jitter buffer over-runs. Such alarms will notify the Service provider of conditions that will negatively impact Service Level Objectives.

33. Management – Alarms Misconnection Alarms – MEN defects:
Stray Frames Must be discarded
CES IWF must check the Ethernet Source address field
Should report an alarm
if stray frames persists above set threshold (Default 2.5 seconds)
Alarm should be cleared
if no stray frames received for a configurable period of time (Default 10 seconds)
Mechanism for detection of lost frames Must Not be affected by reception of stray frames
Misconnection of CES – MEF 3 dictate how frames should be handled in such a condition as well as when to generate and when to clear such alarms.

34. Management – Alarm Statistics Counters
MEN bound
Frames transmitted
Payload octets transmitted
TDM bound
Frames received
Payload octets received
Lost frames detected
Out-of Sequence frames
Transitions to the LOFS (Loss of frame state)
Malformed frames received
Jitter buffer overruns
Jitter buffer underruns
MEF 3 and MEF 8 specify the statistics that must be collected by the CES function in the MEN bound as well as the TDM bound directions.

35. Similar work in other bodies
ITU-T: Recommendation Y.1413
Very similar to MEF8, but for MPLS networks rather than Metro Ethernet
Payload and encapsulation formats are identical
Equipment supporting Y.1413 should also be capable of supporting MEF8
MEF 8 is aligned and compatible with ITU-T recommendation Y.1413

36. Similar work in other bodies
IETF: draft-ietf-pwe3-satop-01.txt, draft-ietf-pwe3-cesopsn-02.txt, draft-ietf-pwe3-tdmoip-03.txt
Very similar to MEF8, but for IP and MPLS networks rather than Metro Ethernet
As with Y.1413, payload and encapsulation formats are identical
Equipment supporting Y.1413 should also be capable of supporting these IETF drafts
MEF 8 is aligned and compatible with these IETF drafts

37. … visit www.metroethernetforum.org to access the full specification
For Full Details …
… visit
to access the full specification
Video Source
Global/National
Carrier
Ethernet
Metro
Carrier
Ethernet
Access
Carrier
Ethernet
Internet
Hosts, Legacy Services, Remote Subscribers etc
Service Provider 1
Metro Ethernet Network
Service Provider 2
Metro Ethernet Network
Subscriber Site
Subscriber Site
Subscriber Site
Subscriber Site