Automated provisioning of Ethernet OAM in CarrierEthernet networks: the case of GRNET Leonidas Poulopoulos Michalis Mamalis Stauros Kroustouris GRNET NOC TNC2015, Porto, ,

The network (GRNET-4)

The architecture GRNET has deployed a massive Carrier (Ethernet) Network that provides E-{LINE, LAN} Currently, more than 400 L2VPNs serve our customers’ needs Collapsed L3 topology

Problem statement No monitoring of the actual service (data path) after service configuration and activation, No quality measurements.

The solution Massive deployment of Ethernet OAM over existing (and new) L2VPNs, Verifying Service Continuity and Service status: – By establishing and monitoring MEP-neighbor relationships Providing performance monitoring: – By configuring active measurements

The approach

The theory

Ethernet OAM related protocols IEEE 802.1ag: Connectivity Fault Management (CFM) ITU-T Y.1731: OAM functions and mechanisms for Ethernet based networks

CFM Overview Family of protocols that provides capabilities to monitor, detect and report end-to-end ethernet connectivity faults CFM frames are regular Ethernet frames that travel in-band with the customer traffic MEF 17 technical specification defines requirements that must be satisfied by both equipment vendor and service provider Nested Maintenance Domains (MDs) that break up the responsibilities for network administration of a given end-to-end service Maintenance Associations (MAs) that monitor service instances under a given MD Maintenance Points (MPs) that generate and respond to CFM PDUs

ITU-T.Y1731 overview Performance Management mechanism Frame Delay Frame Delay variation (jitter) Frame Loss (unsupported from hardware) two-way frame delay and frame delay variation values: based on the time difference between when the initiator MEP transmits a request frame and receives a reply frame from the responder MEP, subtracting the time elapsed at the responder MEP.

Implementation decisions Ethernet OAM deployed on MPLS Carrier Network (for the moment), a subset of the provider network, Maintenance Domain (MD) level appointed to 5, Each Maintenance Association (MA) monitors the connectivity of the L2VPN service provided (unified MA identifier = vpn) Maintenance End Points (MEP) define the boundaries of the L2VPN service and are associated with the vpn MA CFM PDUs are initiated from the port that the L2VPN service is delivered (UP MEP)

Under the hood

Toolshed VPN Management Web Application NETCONF PYTHON/DJANGO RRD TOOL ICINGA

Step 1: Configuration Applier The applier monitors the running configuration on the network by connecting via NETCONF with the devices, Compares with the VPN information stored in the VPN DB, The result is then stored in a Python dictionary which is applied to the network as the new OAM CFM configuration, At the end an report is sent to the network administrators about what changed and what stayed the same

Step 2: Icinga Configuration OAM application provides a way to monitor the state of the actual L2VPN service that is provided by the Carrier Network by defining Icinga passive checks: – OAM application is responsible for creating new Icinga checks by querying the VPNs DB – Icinga fetches the new checks from the OAM application (via HTTPs)

Step 3: Icinga checks An extra functionality is being deployed to check whether an OAM CFM session is UP To accomplish that the OAM application connects to each device via netconf and retrieves Ethernet OAM CFM state The result is then committed via NSCA to ICINGA

Step 4: Quality measurement graphs Finally the OAM application produces the necessary graphs that display the quality measurements running on the network To create the graphs we need a data source: – OAM statistics are stored in RRD files, updated every 5 minutes – OAM application serves the graphs via HTTPs with a nice detail: Graphs are generated on the fly and served as base64 (string) representation of the image

Putting it all together Quality Monitoring: Two-way delay, average/best/worst Two-way delay variation (jitter) SLA measurement by periodically transmitting ITU-Y.1731-compliant frames. Each SLA measurement cycle lasts for 5 minutes = the router polling interval

Putting it all together Fault Detection and Notification: continuity-check messages are sent every 1 second per MA, MEP Down = loss of 3 consecutive CFMs that will trigger a RDI message sent from the local Bridge, Holdtime of 7 minutes before the information about the remote MEP is aged from the local MEP database, Holdtime configured so there is enough time for Icinga checks to mark service as DOWN.

Thank you