10 fn s44

© Verizon 2010 All Rights Reserved Page - 1

Ethernet OAM: A Case Study

Mike Bencheck

Principal Member of Technical Staff

Verizon Core Network Technology

[email protected]

Version 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


Ethernet Service OAM Drivers


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


Ethernet Service OAM Standards


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


Example Ethernet OAM


Verizon Interoperability Forum Overview


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


Example Ethernet OAM


Global EVPL Two NIDs


VIF Lessons Learned

To Date


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


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


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


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


Fault Notification using AIS

Fault detected at Level 0

Propagates to defined client level (6)

AIS sent to customer equipment


Fault Notification using E-LMI

Fault detected at Level 0

Propagates to NID

E-LMI asynchronous status message sent to customer

equipment


Conclusions


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


Thanks

10 fn s44

Documents

rights reserved page

rights reserved page

vif lessons learned

level 0 propagates

fault notification

oam

verizon 2010

support