MPLS-TP OAM Analysisdraft-ietf-mpls-tp-oam-analysis-00.txt

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

IETF 76, Hiroshima

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

Provide input to the decision process Continue to track information, analysis, and decisions about OAM

Organization of the Document

Provide an overview on the existing OAM tools The existing tools are evaluated based on the

different OAM requirements, and gaps (if they exist) are identified.

Recommendations and guidelines are provided. Report the conclusions of the discussions

concerning the MPLS-TP OAM tools and the organization of the OAM documents at IETF75.

Add new sections reporting conclusions of further discussions of OAM

Guidelines RFC 5654 requires that “the The MPLS-TP design

SHOULD as far as reasonably possible reuse existing MPLS standards” and that “mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate” 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, (2) includes only relevant information, and (3) extensible.

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

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.

Draft Status Authors updated the document to

include a report of the conclusions of the discussions concerning the MPLS-TP OAM tools and the organization of the OAM documents at IETF75.

Authors addressed comments received from the design team and from individuals on the mailing list.

The document is now an MPLS WG document.

Next Steps Authors plan to work further on the text and

address comments recently received on the MPLS-TP mailing list.

Keep it as a living document, keep revisiting the document as the OAM solutions are developed, and update it as needed.

Ultimately, the intention is to progress the document to provide a reference for the issues, considerations and the agreed decisions (informational or historic document).

Questions

Thanks

Backup Slides

Recommendations (1)

Recommendation Function

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

Proactive Continuity Check & Connectivity Verification (CC&V)

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

On-demand Connectivity Verification (CV)

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

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

Alarm Reporting

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

Lock Reporting

Recommendations (2)

Recommendation Function

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

Extend LSP-Ping Route Tracing

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

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

Client Fault Indication (CFI)

Define a new PDU, use G-ACH.

We intend to base the functionality on Y.1731.

Packet Loss (pro-active and on-demand)

Recommendations (3)

Recommendation Function

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)

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

Define a new PDU, use G-ACH.

Requires more study.

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