• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,821
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
42
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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 6.2.2.1) 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

Transcript

  • 1. 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
  • 2. This Presentation
    • Purpose
      • 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
  • 3. 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
  • 4. 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
  • 5. 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)
    TDM Circuits (e.g. T1/E1 Lines) TDM Pipe Metro Ethernet Network TDM Circuits (e.g. T1/E1 Lines)
  • 6. 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.
    Types: 1) Unstructured - all bits in must be sent across to the destination 2) Structured - Requires only sending TDM payloads not the over head
  • 7. Circuit Emulation Services Relationship to the Metro Ethernet Network
    • CES functions in relation to those specified by the MEF for the MEN
  • 8. 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.
  • 9. Functions applied
    • ECDX as shown is effectively a multiplexing function allowing multiple CES circuits to share a single EVC
    MEN
  • 10. Functional Layering, and mapping onto encapsulation headers
    • Treats the MEN as a “virtual wire” between two TDM networks
  • 11. MEF Service Definitions
    • TDM Line Service (T-Line):
      • Application: Leased line replacement
    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
  • 12. MEF Service Definitions
    • TDM Access Line Service (TALS):
      • 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
  • 13. MEF Service Definitions
    • Customer-Operated CES:
      • Application: Toll-bypass
    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
  • 14. Structured Vs Unstructured CES
    • Structured Removes the TDM overhead
  • 15. TDM services supported (MEF 3) VC-4-4c Yes Yes STM-4c VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other), VC-4 Yes Yes STM-4 STS-12c Yes Yes OC-12c VT-1.5 (DS1), VT-2 (E1), STS-1 (DS3, E3, other), STS-3c Yes Yes OC-12 VC-4, VC-3, VC-11, VC-12 Yes Yes STM-1c VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other) Yes Yes STM-1 STS-3c Yes Yes OC-3c STS-1, VT-1.5, VT-2 Yes Yes OC-3 STS-1, VT-1.5, VT-2 Yes Yes OC-1 E1, Nx64 kbit/s, DS0 Yes Yes E3 Nx64 kbit/s Yes Yes E1 DS1, Nx64 kbit/s Yes Yes DS3 Nx64 kbit/s Yes Yes DS1 Structured TDM Service Granularity Structured TDM Service Unstructured TDM Service TDM Service Interface
  • 16. 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
  • 17. PDH Interoperability Agreement –MEF 8
    • Specifies Interoperability requirements for:
    • Connectivity
    • Timing
    • Signaling
    • MEN performance criteria
    • MEN services OAM
  • 18. 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.
  • 19. 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.
  • 20. 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 6.3.1.2)
      • 8.4  s over 900s
      • 18  s over 24 hours
    Central Office Remote Terminal CESoP IWF CESoP IWF T1/E1 Max. end-to-end wander (traffic interface) 18  s CES induced wander < 18  s PRS Customer Premises TDM Equipment T1/E1 PSTN PSN
  • 21. 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
  • 22. Timing options
    • TDM line 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
  • 23. 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
  • 24. 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
  • 25. 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)
  • 26. Frame Delay Defined
    • The time required to transmit a service frame from source to destination across the MEN.
    Measured from 1 st bit in to last bit out
  • 27. Frame Delay Variation Defined
    • The difference in delay of two service frames.
    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
  • 28. 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
    Metro Ethernet Metro Ethernet Network Network UNI to UNI UNI to UNI 5000 frames in CE CE CE CE 4995 frames out time 5 frames lost/or received as errored 0.1% Frame Loss Ratio (5/5000)
  • 29. MEN Frame Loss Errors – PDH Limits
    • PDH ES
    • PDH SES
  • 30. Other MEN Parameters
    • Emulated Circuit Availability
      • 99.95%
    • Emulated Circuit Restoral
      • < 50 ms
    • Suggested MEN Bandwidth increments
      • 100 kbps
  • 31. MEF Services OAM
    • Alarms
      • 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)
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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