• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
10 fn s44

10 fn s44






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    10 fn s44 10 fn s44 Presentation Transcript

    • Ethernet OAM: A Case Study Version 1 Mike Bencheck Principal Member of Technical Staff Verizon Core Network Technology mike.bencheck@verizon.com © Verizon 2010 All Rights Reserved Page - 1
    • Agenda • Ethernet Service OAM Drivers • Service OAM Standards • Verizon Interoperability Forum (VIF) • VIF Lessons Learned to Date • Standards • Implementation • Management • Notifying a customer of a fault • Conclusions © Verizon 2010 All Rights Reserved Page - 2
    • Ethernet Service OAM Drivers © Verizon 2010 All Rights Reserved Page - 3
    • Drivers for Ethernet Service OAM Ethernet services are being widely adopted by customers and Service Providers Customers have high expectations for Carrier Ethernet – Premium services over Ethernet • Voice • Mission Critical Data – Expect SLAs – Use as TDM replacement Service Providers need end to end visibility to Ethernet service – Allow management of Ethernet similar to TDM services • Isolation of service affecting defects • Functions like link trace and loopback – Provide customer notification of EVC faults Support end to end SLA measurement – Performance characteristics • Frame Loss Ratio • Frame Delay • Inter-Frame Delay Variation • Availability • Throughput © Verizon 2010 All Rights Reserved Page - 4
    • Ethernet Service OAM Standards © Verizon 2010 All Rights Reserved Page - 5
    • Ethernet Service OAM Standards Two standards – IEEE 802.1ag • Fault Management – ITU-T Recommendation Y.1731 • Fault and Performance Management Differences exist between the two standards – Identified via MEF and liaisons sent to both bodies to address Standards define monitoring points on a per EVC basis – Monitoring End Point (MEP) • Upward facing • Downward facing – Monitoring Intermediate Point (MIP) Standards define eight levels of monitoring – Supports nesting of monitoring points – Levels assigned to Subscriber, Service Provider, Operator and Link Define Performance Measurement, Continuity Verification, Link Trace and Loopback functionality – Supports traditional OAM features from legacy services © Verizon 2010 All Rights Reserved Page - 6
    • Example Ethernet OAM © Verizon 2010 All Rights Reserved Page - 7
    • Verizon Interoperability Forum Overview © Verizon 2010 All Rights Reserved Page - 8
    • Ethernet OAM Verizon Interoperability Forum VIF is a forum where multiple vendor implementations are tested for interoperability – Ethernet OAM VIF focus is on • IEEE 802.1ag • ITU-T Y.1731 • IEEE 802.3, Clause 57 • MEF E-LMI (MEF 16), SOAM-FM and SOAM-PM Interworking Agreements VIF format is useful in eliminating unclear areas in standards – Agreements on interpretation of standards – Multiple vendors participate – Recommendations to standards based on findings Ethernet OAM VIF testing is being done in the Verizon Prototyping Facility in Richardson, TX 2009 focus was Fault Management – Nine vendors – IEEE 802.1ag – ITU-T Y.1731 AIS – Loopback – Linktrace 2010 focus is Performance Management – Performance metrics – Time of Day synchronization © Verizon 2010 All Rights Reserved Page - 9
    • Example Ethernet OAM © Verizon 2010 All Rights Reserved Page - 10
    • Global EVPL Two NIDs © Verizon 2010 All Rights Reserved Page - 11
    • VIF Lessons Learned To Date © Verizon 2010 All Rights Reserved Page - 12
    • Lessons Learned Standards – Differences between IEEE and ITU-T service OAM standards mean they cannot interoperate • Naming – Differences in MAID versus MEG » MEG ID defined in Y.1731 as 13 character ICC-based field » MAID is defined in 802.1ag as up to 43 characters • Link Trace – Differences in LTR » Y.1731 does not use the Relay Action field » 802.1ag requires use of the Relay Action field – Vendor support for IEEE leading ITU-T • Naming convention issues may introduce requirement for migration – Implementation of performance monitoring portion of Link OAM limited – MEF standards defining different MD levels than used in testing • MD Level 1 for UNI ME versus MD level 0 as an example © Verizon 2010 All Rights Reserved Page - 13
    • Lessons Learned Implementation – Support for both Up facing and Down facing MEPs required • Some interfaces must support Up and Down MEPs at different MD levels – Support for MIPs is required • Customer and network facing ports – Untagged MEPs • Most vendors can not support on interfaces configured for tagging • Requires using tagged MEPs a MD Level 0 or 1 • Tagged CCMs can be blocked by STP – Need to define Local and Remote MEPIDs per MA • Auto-discovery leaves possibility of MEPs being added to wrong MA and working with other MEPs in MA • Not all vendors support auto-discovery – IEEE format naming convention for MDs and MAs allows link to service ID – Continuity Check interval < 1 second not supported by many vendors • If used as fault detection method, 3 second minimum detection time • Not fast enough for all customer requests – Some requests for sub-second notification – Where NIDs create tunnels and are not service aware, monitoring services is not supported • Still researching methods to monitor tunnel © Verizon 2010 All Rights Reserved Page - 14
    • Lessons Learned Management – Provisioning of OAM across network is complex • OAM provisioned on a service type basis – Placement of MEPs and MIPs – Reaction to fault notifications • Not practical to manually configure in production • Requires network wide view of services and Network Elements – NMS for OAM may be required • Provides cross vendor provisioning capabilities • Can use vendor EMS or connect directly to NEs © Verizon 2010 All Rights Reserved Page - 15
    • Lessons Learned Customer Fault Notification Methods – Two methods reviewed to notify customers of a fault on an EVC • AIS – Defined in ITU-T Y.1731 • E-LMI Async Status Message – Defined in MEF 16 – Each can accomplish the same thing • Implementation will depend on what customer equipment supports – Service Providers want to offer the most flexibility – May need to support both options © Verizon 2010 All Rights Reserved Page - 16
    • Fault Notification using AIS Fault detected at Level 0 Propagates to defined client level (6) AIS sent to customer equipment © Verizon 2010 All Rights Reserved Page - 17
    • Fault Notification using E-LMI Fault detected at Level 0 Propagates to NID E-LMI asynchronous status message sent to customer equipment © Verizon 2010 All Rights Reserved Page - 18
    • Conclusions © Verizon 2010 All Rights Reserved Page - 19
    • Conclusions Ethernet OAM is becoming increasingly critical to achieve carrier class Ethernet networks Verizon testing shows basic interoperability – Fault Management – Continued equipment vendor development required to meet all carrier and customer expectations Lessons learned – Standards require minor modifications • Interoperability between IEEE and ITU-T – Implementation of standards is complex in a carrier network • Requires external management system to understand deployment • Requires equipment vendors to continue development of new features/functions to match changes in standards © Verizon 2010 All Rights Reserved Page - 20
    • Thanks © Verizon 2010 All Rights Reserved Page - 21