10 fn s44

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

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 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

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

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

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

10 fn s44

by Scott Foster on May 11, 2010

Accessibility

Upload Details

Usage Rights

Statistics

10 fn s44 Presentation Transcript