This document discusses Ethernet OAM and lessons learned from interoperability testing. Key points include: - Standards exist for Ethernet OAM but differences between IEEE and ITU-T standards prevent full interoperability. - Testing through the Verizon Interoperability Forum revealed implementation challenges across vendors in areas like naming, link trace, and performance monitoring support. - Managing OAM across complex carrier networks requires capabilities vendors have not fully developed, like cross-vendor provisioning and external network management systems. - Notifying customers automatically of faults requires supporting standards-based approaches like AIS or E-LMI messaging. Overall, while basic interoperability is achievable, continued work is needed

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. 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. Ethernet Service OAM Drivers
© Verizon 2010 All Rights Reserved Page - 3

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. Ethernet Service OAM Standards
© Verizon 2010 All Rights Reserved Page - 5

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. Example Ethernet OAM
© Verizon 2010 All Rights Reserved Page - 7

8. Verizon Interoperability Forum Overview
© Verizon 2010 All Rights Reserved Page - 8

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. Example Ethernet OAM
© Verizon 2010 All Rights Reserved Page - 10

11. Global EVPL Two NIDs
© Verizon 2010 All Rights Reserved Page - 11

12. VIF Lessons Learned
To Date
© Verizon 2010 All Rights Reserved Page - 12

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. 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. 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. 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. 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. 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. Conclusions
© Verizon 2010 All Rights Reserved Page - 19

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. Thanks
© Verizon 2010 All Rights Reserved Page - 21