MPLS-TP OAM Analysisdraft-sprecher-mpls-tp-oam-analysis-03.txt

Nurit Sprecher / Nokia Siemens NetworksHuub van Helvoort / HuaweiYaacov Weingarten / Nokia Siemens NetworksElisa Bellagamba / Ericsson

Draft Status

The design team f2f meeting last week, worked on the OAM design.

This presentation reflects the outcome of the design team meeting.

The draft will be updated to reflect the recommendations of that meeting.

Purpose of the Document

Analyze whether existing IETF/ITU-T OAM tools can fulfill the functional requirements Identify which tools may be extended in order to support the functional requirements Identify whether new tools need to be defined to fulfill certain functional requirements

MPLS-TP OAM Requirements Draft

(draft-ietf-mpls-tp-oam-requirements-02.txt)

IETF existing OAM Tools for LSPs:

- LSP Ping

- MPLS BFD

IETF existing OAM tools for PWs:

• VCCV supporting ICMP Ping

• VCCV supporting LSP Ping

• VCCV supporting BFD (with and

without IP/UDP encapsulation)

ITU-T Y.1731

Remote

Defect

IndicationAlarm

Suppression

Organization of the Document

The existing tools are evaluated based on the different OAM requirements and gaps (if they exist) are identified.

Recommendations and guidelines are provided.

Architectural

Requirements

General

Principles

of

Operations

Connectivity

Verification

Continuity &

Connectivity

Verification

Requirements for the OAM Functions

Analysis of OAM Requirements

Findings LSP-Ping can easily be extended to support some of the

functions between MEP-to-MEP and MEP-to-MIP. BFD can be extended to support some of the functions

between MEP-to-MEP Some of the OAM functions defined in Y.1731 (especially

for performance monitoring) can be adapted. The PDU format of Y.1731 includes many fields that are not

relevant to the MPLS-TP environment. Using Y.1731 PDU for MPLS-TP OAM messages, will be densely populated with zero bits.

Guidelines Re-use/extend existing IETF protocols where

applicable (fault management) Define new message format for each of the

rest of the OAM functions, which are (1) aligned with the ACH and ACH TLV definitions, and (2) includes only relevant information.

Adapt Y.1731 functionality where applicable (mainly for performance monitoring).

Recommendations (1)

FunctionRecommendation

Proactive Continuity Check & Connectivity Verification (CC&V)

Extend BFD (e.g. maintenance entities, unique global identification, G-ACH, P2MP, etc.)

On-demand Connectivity Verification (CV)

Extend LSP-Ping (e.g. maintenance entities, identifiers other than IP , G-ACH, MIP identification, bypass of CP/DP verification, etc.)

Alarm ReportingFor data-plane implementation, define a new PDU and use G-ACH.

Support in control-plane and management-plane should also be described.

Lock ReportingDefine a new PDU and use G-ACH. Use the same procedures as for Alarm Reporting

Recommendations (2)

FunctionRecommendation

Remote Defect Indication (RDI)Extend BFD. Signal will be passed via BFD.

Route TracingExtend LSP-Ping

Lock Instruct (MEP-to-MEP)Extend LSP-Ping

Client Fault Indication (CFI)Use PWE3 tool to transmit the indication via ACH.

Two proposed tools in PWE3: draft-martini-pwe3-static-pw-status-01.txt and draft-he-mpls-tp-csf-00.txt

Packet Loss (pro-active and on-demand)

Define a new PDU, use G-ACH.

We intend to base the functionality on Y.1731.

Recommendations (3)

FunctionRecommendation

Delay Measurement (pro-active and on-demand), one-way and two-way

Define a new PDU, use G-ACH.

We intend to base the functionality on Y.1731.

Requires expertise in time synchronization (as one-way delay measurement is dependent upon a certain degree of synchronization between the time clocks of the two-ends of the transport path)

Diagnostics, on-demand (verify bandwidth throughput, bit errors, loopback, etc. )

Define a new PDU, use G-ACH.

Requires more study.

Next Steps

Update the document to reflect the design team review

Progress the document to provide a reference for the considerations and the agreed decisions

Questions