MPLSTP OAM based on Y 1731 Italo Busi

MPLS-TP OAM based on Y. 1731 Italo Busi (Editor) Huub van Helvoort (Editor) Jia He (Editor)

Current contributors Christian Addeo (Alcatel-Lucent), Simon Delord (Uecomm), John Hoffmans (KPN), Ruiquan Jing (China Telecom), Julien Meuric (France Telecom), Philippe Niger (France Telecom), Manuel Paul (Deutsche Telekom), Josef Roese (Deutsche Telekom), Vincenzo Sestito (Alcatel-Lucent), Nurit Sprecher (Nokia Siemens Networks), Yaakov Stein (RAD), Yuji Tochio (Fujitsu), Munefumi Tsurusawa (KDDI R&D Labs), Maarten Vissers (Huawei), Yaacov Weingarten (Nokia Siemens Networks)

Scope • ITU-T Recommendation Y. 1731 specifies: – OAM PDUs and procedures (state machines) that meet the transport networks requirements for OAM – Encapsulation mechanisms to carry these OAM PDUs within Ethernet frames to provide Ethernet OAM capabilities in Ethernet networks • Proposal is to capitalize on the technologyindependent OAM PDUs and procedures of Y. 1731 within MPLS-TP to monitor MPLS-TP LSP, PW (any PW type) and Sections • This is NOT Ethernet centric/focused

Advantages of the approach • Reuse existing mechanisms – Availability of MPLS-TP OAM functions in the near terms, since these OAM functions are already supported and deployed – Reduce the complexity and increase the reuse of code for implementation in packet transport devices that may support both VPLS and MPLS-TP capabilities – Operational benefit of reusing the same OAM protocols in LSP, PW and VPLS (i. e. the operator has to test and maintain a single protocol set rather than two)

Relationship • IEEE 802. 1 ag – IEEE 802. 1 ag and ITU-T Y. 1731 have been developed in cooperation by IEEE and ITU – IEEE 802. 1 ag applicable to enterprise networks – ITU-T Y. 1731 applicable to transport networks • Other MPLS and PW OAM mechanisms – No deprecation of existing MPLS and PW OAM mechanisms – No preclusion to define other MPLS-TP OAM tools

Encapsulation Option 1 • One ACH codepoint identifies Y. 1731 OAM PDU and Op. Code identifies the specific PDU 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0| Y. 1731 Channel Type (0 x. XX) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | Op. Code | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | OAM function specific fields | | (Y. 1731 based) | + + : . . . : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Encapsulation Option 2 • The ACH codepoint identifies the specific PDU 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0| Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEL | Version | Op. Code | Flags | TLV Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | OAM function specific fields | | (Y. 1731 based) | + + : . . . : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OAM Mechanisms and Requirements • CCM – Proactive CC & CV – Proactive remote defect indication – Proactive loss measurement • LBM/LBR – On-demand CC & CV – Bidirectional diagnostic test (in-service and outof-service)

OAM Mechanisms and Requirements • TST – Unidirectional diagnostic test (in-service and out-of-service) • AIS – Alarm suppression in case of server failures • LCK – Alarm suppression in case of server administratively locked

OAM Mechanisms and Requirements • LMM/LMR – On-demand (and pro-active) packet loss measurement • DMM/DMR – On-demand (and pro-active) 2 -ways delay measurement • 1 DM – On-demand (and pro-active) 1 -way delay measurement

What is NOT proposed • VSM/VSR and EXM/EXR – Experimental code-points defined in draft-ietf-gach-gal must be used instead • MCC – The solution in draft-beller-mpls-tp-gach-dcn should be used instead • LTM/LTR – Not applicable to MPLS-TP because it addresses an Ethernet specific function to test the MAC “filtering rule”

Open Issues • Applicability to IP/MPLS – Is ACH TLV sufficient? – Do we need an IP-based encapsulation? • Encoding of Target MEP/MIP ID in LBM – Use of ACH TLV? – Use of LBM TLV (within LBM PDU)? • Clarify relationship with other MPLS-TP OAM solution drafts

Next Steps • Complete the OAM mechanisms description • Close the open issue • Address comments from the WG(s)