MPLS-TP Packet Loss and Delay Measurement draft-frost-mpls-tp-loss-delay-00 Dan Stewart IETF 76 November 2009 MPLS-TP

The Problem Protocol mechanisms to enable efficient and accurate measurement of  One-way and Two-way Packet Delay  Packet Loss for MPLS-TP PWs, LSPs, and Sections Applicable to  Bidirectional point-to-point  Unidirectional point-to-point  Unidirectional point-to-multipoint MPLS-TP LSPs

Considerations Accurate Delay Measurement (DM) and Loss Measurement (LM) may require hardware timestamping and “counterstamping” support Protocol design should support efficient hardware packet identification and processing Protocol should be simple, streamlined and fit to purpose Multiple timestamp formats in use in deployed networks and devices: NTP, IEEE 1588 v1/v2

Approach LM/DM approach follows basic measurement approach of ITU-T Recommendation Y.1731, adapted for MPLS-TP LM/DM messages flow over the Generic Associated Channel (G-ACh) of MPLS-TP PWs, LSPs, and Sections Only two message types: LM and DM. Packet formats are similar and can easily be combined into a third compound message type that performs both functions DM mechanism useful even without hardware support, but LM without hw support may require a different approach.  Other LM approaches include using existing OAM messages as a proxy for client packets to measure loss, and sustained invasive generation of test messages.  Currently out of scope of this draft, but may be worth exploring in parallel DM supports multiple timestamp formats

Measurement Model Bidirectional Connection: Measurement carried out at the initiator Unidirectional Connection: Measurement carried out either at the receiver or (if a backward out-of- band link is available) the initiator DM message contains 4 timestamp fields for T1-T4 LM message contains 4 counter fields for initiator/responder Tx/Rx packet counts DM protocol is stateless LM protocol is “almost” stateless: loss is measured as a delta between messages

Timestamp Formats Very simple mechanism to permit interop between devices with different preferred timestamp formats DM messages include three 4-bit fields that specify:  Querier Timestamp Format  Responder Timestamp Format  Responder’s Preferred Timestamp Format Querier sets QTF in the initial message to its preferred format. Responder sets RTF in the response either to QTF (if it can support it) or else to RPTF. Querier now knows the state of the world and can decide what to do Support for multiple timestamp formats is OPTIONAL. For an implementation that supports only one format, this procedure reduces to a no-op or single format compatibility test.

Work In Progress / Open Issues Say more about P2MP measurement options: measurement at TTL radii, message consolidation for multi-level monitoring Clarify LM/DM apply on a per-QoS-class basis Decide best way to handle lost/duplicated/out-of-order LM messages and misordering of data traffic relative to LM messages; adjust packet format accordingly (sequence number / timestamp) Determine/document approach for handling metadata such as node/connection identifiers and authentication keys Collaboration, comments and text welcome!

Thank you! 広島市 76