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

10 fn s44

on

  • 700 views

 

Statistics

Views

Total Views
700
Views on SlideShare
700
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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