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.
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.
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.
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
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
This slide depicts the functions as they are applied within the protocol stack for each Ethernet CES frame that transits the MEN.
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.
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.
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.
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.
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
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,
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
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.
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 126.96.36.199) 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.
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.
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.
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).
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
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).
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
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
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 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
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 .
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.
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.
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.
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.
MEF 8 is aligned and compatible with ITU-T recommendation Y.1413
MEF 8 is aligned and compatible with these IETF drafts
Introducing the Specifications of the Metro Ethernet Forum * MEF 10 * replaced MEF 1 and MEF 5 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
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
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
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
MEF Specifications Overview Audience Equipment Manufacturers supporting devices that provide Circuit Emulation over Carrier Ethernet Services. Useful for Service Providers architecting their systems. Purpose Circuit Emulation Service “tunnels” TDM traffic through a Metro Ethernet network allowing inclusion of legacy networks within a Carrier Ethernet environment 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 Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks MEF 3 Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks MEF 8 Technical Committee Service Area 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 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
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
Customer Premises Customer Premises Metro Ethernet Network CESoETH Ethernet UNI Ethernet UNI Ethernet E-Line Service Ethernet TDM TDM CES IWF CES IWF TDM subscriber demarcation TDM subscriber demarcation Service Provider Network
Application: Access to a remote network (e.g. PSTN)
Customer Premises Metro Ethernet Network CESoETH Ethernet UNI Ethernet UNI Ethernet E-Line Service Ethernet TDM TDM CES IWF CES IWF TDM subscriber demarcation TDM Network Interface Service Provider Network PSTN
Customer Premises Customer Premises Metro Ethernet Network CESoETH Ethernet UNI and subscriber demarcation Ethernet UNI and subscriber demarcation Ethernet E-Line Service Ethernet TDM TDM CES IWF CES IWF Service Provider Network
Metro Ethernet Metro Ethernet Network Network UNI to UNI UNI to UNI first bit in first bit in time CE CE CE CE Frame Frame Delay Delay Variation1 Frame 1 Frame 1 last bit out first bit in Frame 2 Frame 2 Last bit out Frame Delay Variation 2
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
For Full Details … Service Provider 1 Metro Ethernet Network Service Provider 2 Metro Ethernet Network Internet Global/National Carrier Ethernet Metro Carrier Ethernet Access Carrier Ethernet Hosts, Legacy Services, Remote Subscribers etc … visit www.metroethernetforum.org to access the full specification Subscriber Site Subscriber Site Subscriber Site Subscriber Site Video Source