Presentation on theme: "Introducing the Specifications of the Metro Ethernet Forum"— Presentation transcript:
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 ProtectionMEF 3 Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet NetworksMEF 4 Metro Ethernet Network Architecture Framework Part 1: Generic FrameworkMEF 6 Metro Ethernet Services Definitions Phase IMEF 7 EMS-NMS Information ModelMEF 8 Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet NetworksMEF 9 Abstract Test Suite for Ethernet Services at the UNIMEF 10 Ethernet Services Attributes Phase IMEF 11 User Network Interface (UNI) Requirements and FrameworkMEF 12 Metro Ethernet Network Architecture Framework Part 2: Ethernet Services LayerMEF 13 User Network Interface (UNI) Type 1 Implementation AgreementMEF 14 Abstract Test Suite for Ethernet Services at the UNIMEF 15 Requirements for Management of Metro Ethernet Phase 1 Network ElementsMEF 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 SpecificationsThese are the two principal specifications relating to services that carry Circuit Emulation/TM traffic across Carrier EthernetAudienceIt is intended for Product Marketing, Engineering staff of member companies, for members of other standards bodies, Enterprise networking staff, and service providers whoWould like a quick overview of the specificationsPlan to read the specifications in detailOther DocumentsPresentations of the other specifications and an overview of all specifications is available on the MEF web siteOther 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 NetworksPurposeCircuit Emulation Service “tunnels” TDM traffic through a Metro Ethernet network allowing inclusion of legacy networks within a Carrier Ethernet environmentAudienceEquipment Manufacturers supporting devices that provide Circuit Emulation over Carrier Ethernet Services. Useful for Service Providers architecting their systems.Technical Committee Service AreaMEF 8Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet NetworksPurposeGives 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 standardsAudienceEquipment 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 EthernetA services descriptionTypes of TDM services offered over Metro Ethernet,PDH and SONET/SDHDS1E1, DS3/E3, OC-3/STM-1, OC-12/STM-4A requirement documentComprehensive CES requirements for providing TDM services over EthernetSLA service quality parameters as specified by the ITU for TDM servicesAn implementation agreement for EthernetPractical 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 networkpacket network “emulates” a circuit-switched network, re-creating the TDM circuit at the far endinvisible to TDM source and destination equipmentruns on a standard Ethernet Line Service (E-Line)Metro Ethernet NetworkThis 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 equipmentAllow 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 partStructured 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 destination2) 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 DefinedTSP - Optional TDM mux/demux function –prior to Ethernet interworkingIWF - Interworking function of TDM to Ethernet framesECDX - Identifier function for proper forwarding and demultiplexingEFTF –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 trafficDestination addressing and marking for MEN routing of traffic
10 Functions appliedMENThis 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 frameECDX 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 trafficEFTF provides the Final Addressing for transport into and from the MENECDX 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 replacementCustomerPremisesCustomerPremisesCESoETHCES IWFCES IWFTDMEthernetMetro Ethernet NetworkEthernetTDMMEF 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 ServiceEthernet UNIEthernet UNIService Provider NetworkTDM subscriber demarcationTDM subscriber demarcation
13 MEF Service Definitions TDM Access Line Service (TALS):Application: Access to a remote network (e.g. PSTN)CustomerPremisesCESoETHCES IWFCES IWFPSTNTDMEthernetMetro Ethernet NetworkEthernetTDMThe 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 ServiceEthernet UNIEthernet UNIService Provider NetworkTDM subscriber demarcationTDM Network Interface
14 MEF Service Definitions Customer-Operated CES:Application: Toll-bypassCustomerPremisesCustomerPremisesCESoETHCES IWFCES IWFTDMEthernetMetro Ethernet NetworkEthernetTDMThe 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 ServiceEthernet UNI and subscriber demarcationEthernet UNI and subscriber demarcationService 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 functionsStructured 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 InterfaceUnstructured TDM ServiceStructured TDM ServiceStructured TDM Service GranularityDS1YesNx64 kbit/sDS3DS1, Nx64 kbit/sE1E3E1, Nx64 kbit/s, DS0OC-1STS-1, VT-1.5, VT-2OC-3OC-3cSTS-3cSTM-1VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other)STM-1cVC-4, VC-3, VC-11, VC-12OC-12VT-1.5 (DS1), VT-2 (E1), STS-1 (DS3, E3, other), STS-3cOC-12cSTS-12cSTM-4VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other), VC-4STM-4cVC-4-4cTDM (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 minimizedto meet MEF 5 defined parametersEthernet Frame Delay VariationMEN EVCS jitter up to 10 ms maxEthernet Frame LossESR and SESR should meet TDM requirementsNetwork availabilityshould meet 99.95% TDM requirementMEN 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:ConnectivityTimingSignalingMEN performance criteriaMEN services OAMMEF 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-1FRG 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 1000sT1 standards (1.544 Mbps)Traffic interface (T1.403, section )8.4 s over 900s18 s over 24 hoursCentral OfficeRemote TerminalCustomerPremisesPRSPSTNPSNCESoP IWFCESoP IWFTDMEquipmentTDM services have strict synchronization of timing requirements to provide what is known as toll grade voice qualityITU 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/E1T1/E1CES induced wander < 18 msMax. end-to-end wander (traffic interface) 18 ms
22 TimingSynchronous services require timing be providedLine, through, external or internal timing mode optionsApplies to structure aware onlySynchronization.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 timeA means to provide timing is critical for structure aware servicesTiming 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 lineExternal timinguse an external reference clock sourceFree run timinguse a free-running oscillatorEthernet line timingrecovering the clock from the Ethernet interfaceLine 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 dataCE Common Channel Signaling (CAS)Must be handled separately for Nx64 service Encoding Format for CASNote must have a separate Control Word from the Data, but can share same ECIDCE 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 LinkMay monitor but not change DS1 Extended Super Frame message dataErrored DataCESoETH should be capable of monitoring Frame Error ratioMEF 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 serviceSLA service quality parameters should support to those specified by the ITU for TDM servicesNx64 Services require CAS Signaling in MENSDH/SONET requires pointer adjustments in MENSpecified MEN Quality Parameters:Frame Delay: <25msJitter (Delay Variation): <10msFrame 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 qualityTiming 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 oscillatorSLA 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 qualityFrame 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 DefinedThe 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 specificationMeasured from 1st bit in to last bit out
28 Frame Delay Variation Defined The difference in delay of two service frames.CECECECEMetro EthernetMetro EthernetFrame 1NetworkNetworktimefirst bit infirst bit inUNI to UNIUNI to UNIFrameDelayVariation1FrameDelayFrame 2first bit inFrame 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 specificationFrame 1 last bit outFrameDelayVariation 2Frame 2 Last bit out
29 Frame Loss DefinedFrame loss is a measure of the number of lost service frames inside the MEN.Frame loss ratio is % = # frames lost / # frames senttimeCECECECEMetro EthernetMetro EthernetNetworkNetwork5000 frames inUNI to UNIUNI to UNIFrame 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 specification4995 frames out5 frames lost/or received as errored0.1% Frame Loss Ratio (5/5000)
30 MEN Frame Loss Errors – PDH Limits PDH ESPDH SESPDH 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 msSuggested MEN Bandwidth increments100 kbpsOther 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 discardedCES IWF must check the Ethernet Source address fieldShould report an alarmif stray frames persists above set threshold (Default 2.5 seconds)Alarm should be clearedif 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 framesMisconnection 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 boundFrames transmittedPayload octets transmittedTDM boundFrames receivedPayload octets receivedLost frames detectedOut-of Sequence framesTransitions to the LOFS (Loss of frame state)Malformed frames receivedJitter buffer overrunsJitter buffer underrunsMEF 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.1413Very similar to MEF8, but for MPLS networks rather than Metro EthernetPayload and encapsulation formats are identicalEquipment supporting Y.1413 should also be capable of supporting MEF8MEF 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.txtVery similar to MEF8, but for IP and MPLS networks rather than Metro EthernetAs with Y.1413, payload and encapsulation formats are identicalEquipment supporting Y.1413 should also be capable of supporting these IETF draftsMEF 8 is aligned and compatible with these IETF drafts
37 … visit www.metroethernetforum.org to access the full specification For Full Details …… visitto access the full specificationVideo SourceGlobal/NationalCarrierEthernetMetroCarrierEthernetAccessCarrierEthernetInternetHosts, Legacy Services, Remote Subscribers etcService Provider 1Metro Ethernet NetworkService Provider 2Metro Ethernet NetworkSubscriber SiteSubscriber SiteSubscriber SiteSubscriber Site