OAM Overview

1. OAM Overview Nurit Sprecher Nokia Siemens Networks Nurit.sprecher@nsn.com • draft-ietf-opsawg-oam-overview-02.txt • Tal Mizrahi Marvell • Nurit Sprecher Nokia Siemens Networks • Elisa Bellagamba Ericsson • Yaacov Weingarten Nokia Siemens Networks

2. Status of the draft • A merge of two overlapping drafts: • draft-ietf-opsawg-oam-overview-00.txt • Provides overview of existing IETF OAM tools. • Compares them with OAM mechanisms defined by the IEEE and ITU-T. • draft-sprecher-mpls-tp-oam-primer-00.txt • Provides basic information on the existing OAM tools in IETF for MPLS. • Analyzes the tools relative to the set of requirements for OAM for MPLS-TP. • Highlights features that need to be extended in order to deliver the higher-quality OAM as required for transport applications. • The document focuses on data-plane OAM.

3. Purpose of the document • Presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF • Compares the IETF mechanisms to other OAM mechanisms that have been defined by the IEEE and ITU-T.

4. OAM Tools in Scope IETF Mechanisms ITU-T and IEEE ITU-T Y.1711 (MPLS OAM) ITU-T Y.1731 (Ethernet OAM) IEEE802.1ag (Ethernet OAM) IEEE802.3ah (Ethernet in the first mile) • ICMP • LSP Ping • BFD (for IP, MPLS LSP and PW) • VCCV • IP Performance Metrics (IPPM) • The different OAM standards use different terminology. • draft-ietf-opsawg-oam-overview-02.txt compares between the terminology used by each of the standards and provides definitions for terms such as Maintenance Entity, failure/fault/defect, continuity check and connectivity.

5. Internet Control Message Protocol (ICMP) • Provides connectivity verification function for IP. Supports both IPv4 and IPv6. • The originator transmits an echo request packet, and the receiver replies with an echo reply. • Both LSP Ping and VCCV are to some extent based on ICMP Ping.

6. MPLS LSP Ping • MPLS LSP Ping • Based on ICMP Ping. • Provides simple connectivity verification functionbetween two LSRs and hop-by-hop trace-route fault localization or route determination. • Supports P2P LSPs. Ongoing work to support P2MP. • Uses an extensive algorithm to verify the LSP’s control-plane against the data-plane (which can be easily bypassed). • Identification is based on full FEC information. • Can be easily extended to support additional functionality (using TLVs). ??? • Support both asynchronous and on-demand modes.

7. Bidirectional Forwarding Detection (BFD) • A unified OAM mechanism that provides bidirectional continuity check. • Can be supported by different protocols and in various medium types. So far define in IP, MPLS, PWE3 and ongoing work on MPLS-TP. • BFD control packets that are exchanged within a BFD session. • BFD sessions operate in one of two modes: Asynchronous mode (proactive) and demand (on-demand). • BFD control packets are sent independently in each direction of the link. • The session is identified by each endpoint with by local Discriminators which are exchanged at the time of session establishment. • The transmission rate is negotiated between the two end-points. • During normal operation of the session, i.e. no failures are detected; the BFD session is in the Up state. If no BFD Control packets are received during a fixed period of time, the session is declared to be Down. • The echo function is used for connectivity verification. A BFD echo packet is sent to a peer system, and is looped back to the originator. The echo function can be used proactively, or on-demand.

8. Virtual Circuit Connection Verification (VCCV) • Provides fault detection and diagnostics for PWs (Independently of the underlying tunneling technology) • Provides control channels associated with the PW being monitored. Thus, OAM packets are sent in-band with data traffic (using CC Type 1: In-band VCCV). • Consists of two components: • Signaled component to communicate VCCV capabilities • Switching component to cause the PW payload to be treated as a control packet. • Does not depend upon the presence of a control plane. • Currently, VCCV supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD. • ICMP and LSP Ping are IP encapsulated. • BFD for VCCV supports both IP/UDP encapsulated or PW-ACH encapsulated (with no IP/UDP header). • Supports AC status signaling • The PW label provides the context.

9. IP Performance Monitoring • The IETF IPPM WG defines common criteria and metrics for performance measurement in IP networks, as well as a protocol for measuring delay and packet loss. • Two protocols are used, a control plane protocol, and a test plane protocol. • The control protocols are used to initiate, start and stops test sessions and they run over TCP. • The test protocols creates test packets (according to the schedule) and record statistics of packet arrival. They run over UDP. • IPPM test results are not returned for each test packet sent. They are collected at the receiver and returned upon request. This makes it less suitable for real-time monitoring. • Supports optional authentication and encryption .

10. ITU-T Y.1711 (MPLS OAM) • OAM packets are sent in-band with data traffic. OAM alert label (label 14) is supported for exception handling. • Supports the following functions: • Connectivity verification* to detect los of continuity and misconnectivity. • Fast Failure Detection applicablefor protection switching. • Forward and backward defect indications which are used by an LSR to notify affected client layers of the defect (in forward and backward direction ), allowing them to suppress consequent alarms.

11. ITU-T Y.1731(Ethernet OAM) • Supports a SET of OAM tools for fault management and performance monitoring. • Applicable to Ethernet networks and services. • ITU-T and IEEE802.1 worked in close collaboration on OAM. IEEE802.1ag provides fault management functions. • There are a few differences between the standards in the terminology. • Designed for Ethernet • A connectionless technology , with specific behavior, such as flooding, learning, etc. • Relies on the Ethernet MAC addresses in the packet headers (which together provide unique identification of the element being monitored). • The OAM packets do not provide an indication on the layer being monitored. The information is included in the OAM payload (e.g. operator, SP, customer layers, etc.) and require DPI. • The mechanisms are not compatible with MPLS fault detection mechanisms and require special interworking functions. • Provides procedures and messages to perform packet loss measurement and on-demand (one/two-way) frame delay and delay variation measurements. Can be used as a reference to the design of OMA PM tools.

12. IEEE802.3ah – Ethernet in the first mile • Provides connectivity fault management for the first mile. • Remote failure indication allowing a node to notify a peer about a defect in the receive path. • Remote loopback used in a diagnostic to verify the link connectivity, and to measure the packet loss rate. • Link Monitoring • Can be used to monitor a single link.

13. MPLS-TP • Ongoing work to define a set of fault management and performance monitoring tools (operating in the data-plane) which are appropriate for transport networks and support the network and services at different nested levels. • The MPLS-TP MEAD team held intensive discussions on the OAM design in the meeting in July 2009. • The outcome of the discussions and the recommendations were presented to the IETF WG in IETF75 at Stockholm and approved. • The recommendations were recorded in “draft-ietf-mpls-tp-oam-analysis” by the secretary of the design team. • The OAM analysis document acts as a reference to the considerations and the agreed decisions . It also refers to the relevant documents for each of the OAM tools.

14. Summary of OAM Functions (from Tal’s Slides)

15. Thanks!

16. Summary of OAM Standards (from Tal’s slides)