10 fn s44

525
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
525
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

10 fn s44

  1. 1. 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
  2. 2. 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
  3. 3. Ethernet Service OAM Drivers © Verizon 2010 All Rights Reserved Page - 3
  4. 4. 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
  5. 5. Ethernet Service OAM Standards © Verizon 2010 All Rights Reserved Page - 5
  6. 6. 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
  7. 7. Example Ethernet OAM © Verizon 2010 All Rights Reserved Page - 7
  8. 8. Verizon Interoperability Forum Overview © Verizon 2010 All Rights Reserved Page - 8
  9. 9. 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
  10. 10. Example Ethernet OAM © Verizon 2010 All Rights Reserved Page - 10
  11. 11. Global EVPL Two NIDs © Verizon 2010 All Rights Reserved Page - 11
  12. 12. VIF Lessons Learned To Date © Verizon 2010 All Rights Reserved Page - 12
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. Conclusions © Verizon 2010 All Rights Reserved Page - 19
  20. 20. 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
  21. 21. Thanks © Verizon 2010 All Rights Reserved Page - 21

×