GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6374

Internet Engineering Task Force (IETF) D. Frost Request for Comments: 6374 S. Bryant Category: Standards Track Cisco Systems ISSN: 2070-1721 September 2011

        Packet Loss and Delay Measurement for MPLS Networks

Abstract

 Many service provider service level agreements (SLAs) depend on the
 ability to measure and monitor performance metrics for packet loss
 and one-way and two-way delay, as well as related metrics such as
 delay variation and channel throughput.  This measurement capability
 also provides operators with greater visibility into the performance
 characteristics of their networks, thereby facilitating planning,
 troubleshooting, and network performance evaluation.  This document
 specifies protocol mechanisms to enable the efficient and accurate
 measurement of these performance metrics in MPLS networks.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6374.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Frost & Bryant Standards Track [Page 1] RFC 6374 MPLS Loss and Delay Measurement September 2011

Table of Contents

 1. Introduction ....................................................3
    1.1. Applicability and Scope ....................................5
    1.2. Terminology ................................................6
    1.3. Requirements Language ......................................6
 2. Overview ........................................................6
    2.1. Basic Bidirectional Measurement ............................6
    2.2. Packet Loss Measurement ....................................7
    2.3. Throughput Measurement ....................................10
    2.4. Delay Measurement .........................................10
    2.5. Delay Variation Measurement ...............................12
    2.6. Unidirectional Measurement ................................12
    2.7. Dyadic Measurement ........................................13
    2.8. Loopback Measurement ......................................13
    2.9. Measurement Considerations ................................14
         2.9.1. Types of Channels ..................................14
         2.9.2. Quality of Service .................................14
         2.9.3. Measurement Point Location .........................14
         2.9.4. Equal Cost Multipath ...............................15
         2.9.5. Intermediate Nodes .................................15
         2.9.6. Different Transmit and Receive Interfaces ..........16
         2.9.7. External Post-Processing ...........................16
         2.9.8. Loss Measurement Modes .............................16
         2.9.9. Loss Measurement Scope .............................18
         2.9.10. Delay Measurement Accuracy ........................18
         2.9.11. Delay Measurement Timestamp Format ................18
 3. Message Formats ................................................19
    3.1. Loss Measurement Message Format ...........................19
    3.2. Delay Measurement Message Format ..........................25
    3.3. Combined Loss/Delay Measurement Message Format ............27
    3.4. Timestamp Field Formats ...................................28
    3.5. TLV Objects ...............................................29
         3.5.1. Padding ............................................30
         3.5.2. Addressing .........................................31
         3.5.3. Loopback Request ...................................31
         3.5.4. Session Query Interval .............................32
 4. Operation ......................................................33
    4.1. Operational Overview ......................................33
    4.2. Loss Measurement Procedures ...............................34
         4.2.1. Initiating a Loss Measurement Operation ............34
         4.2.2. Transmitting a Loss Measurement Query ..............34
         4.2.3. Receiving a Loss Measurement Query .................35
         4.2.4. Transmitting a Loss Measurement Response ...........35
         4.2.5. Receiving a Loss Measurement Response ..............36
         4.2.6. Loss Calculation ...................................36
         4.2.7. Quality of Service .................................37
         4.2.8. G-ACh Packets ......................................37

Frost & Bryant Standards Track [Page 2] RFC 6374 MPLS Loss and Delay Measurement September 2011

         4.2.9. Test Messages ......................................37
         4.2.10. Message Loss and Packet Misorder Conditions .......38
    4.3. Delay Measurement Procedures ..............................39
         4.3.1. Transmitting a Delay Measurement Query .............39
         4.3.2. Receiving a Delay Measurement Query ................39
         4.3.3. Transmitting a Delay Measurement Response ..........40
         4.3.4. Receiving a Delay Measurement Response .............41
         4.3.5. Timestamp Format Negotiation .......................41
                4.3.5.1. Single-Format Procedures ..................42
         4.3.6. Quality of Service .................................42
    4.4. Combined Loss/Delay Measurement Procedures ................42
 5. Implementation Disclosure Requirements .........................42
 6. Congestion Considerations ......................................44
 7. Manageability Considerations ...................................44
 8. Security Considerations ........................................45
 9. IANA Considerations ............................................46
    9.1. Allocation of PW Associated Channel Types .................47
    9.2. Creation of Measurement Timestamp Type Registry ...........47
    9.3. Creation of MPLS Loss/Delay Measurement Control
         Code Registry .............................................47
    9.4. Creation of MPLS Loss/Delay Measurement TLV Object
         Registry ..................................................49
 10. Acknowledgments ...............................................49
 11. References ....................................................49
    11.1. Normative References .....................................49
    11.2. Informative References ...................................50
 Appendix A. Default Timestamp Format Rationale ....................52

1. Introduction

 Many service provider service level agreements (SLAs) depend on the
 ability to measure and monitor performance metrics for packet loss
 and one-way and two-way delay, as well as related metrics such as
 delay variation and channel throughput.  This measurement capability
 also provides operators with greater visibility into the performance
 characteristics of their networks, thereby facilitating planning,
 troubleshooting, and network performance evaluation.  This document
 specifies protocol mechanisms to enable the efficient and accurate
 measurement of these performance metrics in MPLS networks.
 This document specifies two closely related protocols, one for packet
 loss measurement (LM) and one for packet delay measurement (DM).
 These protocols have the following characteristics and capabilities:
 o  The LM and DM protocols are intended to be simple and to support
    efficient hardware processing.

Frost & Bryant Standards Track [Page 3] RFC 6374 MPLS Loss and Delay Measurement September 2011

 o  The LM and DM protocols operate over the MPLS Generic Associated
    Channel (G-ACh) [RFC5586] and support measurement of loss, delay,
    and related metrics over Label Switched Paths (LSPs), pseudowires,
    and MPLS sections (links).
 o  The LM and DM protocols are applicable to the LSPs, pseudowires,
    and sections of networks based on the MPLS Transport Profile
    (MPLS-TP), because the MPLS-TP is based on a standard MPLS data
    plane.  The MPLS-TP is defined and described in [RFC5921], and
    MPLS-TP LSPs, pseudowires, and sections are discussed in detail in
    [RFC5960].  A profile describing the minimal functional subset of
    the LM and DM protocols in the MPLS-TP context is provided in
    [RFC6375].
 o  The LM and DM protocols can be used both for continuous/proactive
    and selective/on-demand measurement.
 o  The LM and DM protocols use a simple query/response model for
    bidirectional measurement that allows a single node -- the querier
    -- to measure the loss or delay in both directions.
 o  The LM and DM protocols use query messages for unidirectional loss
    and delay measurement.  The measurement can be carried out either
    at the downstream node(s) or at the querier if an out-of-band
    return path is available.
 o  The LM and DM protocols do not require that the transmit and
    receive interfaces be the same when performing bidirectional
    measurement.
 o  The DM protocol is stateless.
 o  The LM protocol is "almost" stateless: loss is computed as a delta
    between successive messages, and thus the data associated with the
    last message received must be retained.
 o  The LM protocol can perform two distinct kinds of loss
    measurement: it can measure the loss of specially generated test
    messages in order to infer the approximate data-plane loss level
    (inferred measurement) or it can directly measure data-plane
    packet loss (direct measurement).  Direct measurement provides
    perfect loss accounting, but may require specialized hardware
    support and is only applicable to some LSP types.  Inferred
    measurement provides only approximate loss accounting but is
    generally applicable.

Frost & Bryant Standards Track [Page 4] RFC 6374 MPLS Loss and Delay Measurement September 2011

    The direct LM method is also known as "frame-based" in the context
    of Ethernet transport networks [Y.1731].  Inferred LM is a
    generalization of the "synthetic" measurement approach currently
    in development for Ethernet networks, in the sense that it allows
    test messages to be decoupled from measurement messages.
 o  The LM protocol supports measurement in terms of both packet
    counts and octet counts.
 o  The LM protocol supports both 32-bit and 64-bit counters.
 o  The LM protocol can be used to measure channel throughput as well
    as packet loss.
 o  The DM protocol supports multiple timestamp formats, and provides
    a simple means for the two endpoints of a bidirectional connection
    to agree on a preferred format.  This procedure reduces to a
    triviality for implementations supporting only a single timestamp
    format.
 o  The DM protocol supports varying the measurement message size in
    order to measure delays associated with different packet sizes.
 The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way
 Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities
 for the measurement of various performance metrics in IP networks.
 These protocols are not streamlined for hardware processing and rely
 on IP and TCP, as well as elements of the Network Time Protocol
 (NTP), which may not be available or optimized in some network
 environments; they also lack support for IEEE 1588 timestamps and
 direct-mode LM, which may be required in some environments.  The
 protocols defined in this document thus are similar in some respects
 to, but also differ from, these IP-based protocols.

1.1. Applicability and Scope

 This document specifies measurement procedures and protocol messages
 that are intended to be applicable in a wide variety of circumstances
 and amenable to implementation by a wide range of hardware- and
 software-based measurement systems.  As such, it does not attempt to
 mandate measurement quality levels or analyze specific end-user
 applications.

Frost & Bryant Standards Track [Page 5] RFC 6374 MPLS Loss and Delay Measurement September 2011

1.2. Terminology

 Term  Definition
 ----- -------------------------------------------
 ACH   Associated Channel Header
 DM    Delay Measurement
 ECMP  Equal Cost Multipath
 G-ACh Generic Associated Channel
 LM    Loss Measurement
 LSE   Label Stack Entry
 LSP   Label Switched Path
 NTP   Network Time Protocol
 OAM   Operations, Administration, and Maintenance
 PTP   Precision Time Protocol
 TC    Traffic Class

1.3. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

2. Overview

 This section begins with a summary of the basic methods used for the
 bidirectional measurement of packet loss and delay.  These
 measurement methods are then described in detail.  Finally, a list of
 practical considerations is discussed that may come into play to
 inform or modify these simple procedures.  This section is limited to
 theoretical discussion; for protocol specifics, the reader is
 referred to Sections 3 and 4.

2.1. Basic Bidirectional Measurement

 The following figure shows the reference scenario.
                           T1              T2
                 +-------+/     Query       \+-------+
                 |       | - - - - - - - - ->|       |
                 |   A   |===================|   B   |
                 |       |<- - - - - - - - - |       |
                 +-------+\     Response    /+-------+
                           T4              T3
 This figure shows a bidirectional channel between two nodes, A and B,
 and illustrates the temporal reference points T1-T4 associated with a
 measurement operation that takes place at A.  The operation consists
 of A sending a query message to B, and B sending back a response.

Frost & Bryant Standards Track [Page 6] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Each reference point indicates the point in time at which either the
 query or the response message is transmitted or received over the
 channel.
 In this situation, A can arrange to measure the packet loss over the
 channel in the forward and reverse directions by sending Loss
 Measurement (LM) query messages to B, each of which contains the
 count of packets transmitted prior to time T1 over the channel to B
 (A_TxP).  When the message reaches B, it appends two values and
 reflects the message back to A: the count of packets received prior
 to time T2 over the channel from A (B_RxP) and the count of packets
 transmitted prior to time T3 over the channel to A (B_TxP).  When the
 response reaches A, it appends a fourth value: the count of packets
 received prior to time T4 over the channel from B (A_RxP).
 These four counter values enable A to compute the desired loss
 statistics.  Because the transmit count at A and the receive count at
 B (and vice versa) may not be synchronized at the time of the first
 message, and to limit the effects of counter wrap, the loss is
 computed in the form of a delta between messages.
 To measure at A the delay over the channel to B, a Delay Measurement
 (DM) query message is sent from A to B containing a timestamp
 recording the instant at which it is transmitted, i.e., T1.  When the
 message reaches B, a timestamp is added recording the instant at
 which it is received (T2).  The message can now be reflected from B
 to A, with B adding its transmit timestamp (T3) and A adding its
 receive timestamp (T4).  These four timestamps enable A to compute
 the one-way delay in each direction, as well as the two-way delay for
 the channel.  The one-way delay computations require that the clocks
 of A and B be synchronized; mechanisms for clock synchronization are
 outside the scope of this document.

2.2. Packet Loss Measurement

 Suppose a bidirectional channel exists between the nodes A and B.
 The objective is to measure at A the following two quantities
 associated with the channel:
    A_TxLoss (transmit loss): the number of packets transmitted by A
    over the channel but not received at B;
    A_RxLoss (receive loss): the number of packets transmitted by B
    over the channel but not received at A.

Frost & Bryant Standards Track [Page 7] RFC 6374 MPLS Loss and Delay Measurement September 2011

 This is accomplished by initiating a Loss Measurement (LM) operation
 at A, which consists of transmission of a sequence of LM query
 messages (LM[1], LM[2], ...) over the channel at a specified rate,
 such as one every 100 milliseconds.  Each message LM[n] contains the
 following value:
    A_TxP[n]: the total count of packets transmitted by A over the
    channel prior to the time this message is transmitted.
 When such a message is received at B, the following value is recorded
 in the message:
    B_RxP[n]: the total count of packets received by B over the
    channel at the time this message is received (excluding the
    message itself).
 At this point, B transmits the message back to A, recording within it
 the following value:
    B_TxP[n]: the total count of packets transmitted by B over the
    channel prior to the time this response is transmitted.
 When the message response is received back at A, the following value
 is recorded in the message:
    A_RxP[n]: the total count of packets received by A over the
    channel at the time this response is received (excluding the
    message itself).
 The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n]
 within the measurement interval marked by the messages LM[n-1] and
 LM[n] are computed by A as follows:
 A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
 A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
 where the arithmetic is modulo the counter size.
 (Strictly speaking, it is not necessary that the fourth count,
 A_RxP[n], actually be written in the message, but this is convenient
 for some implementations and useful if the message is to be forwarded
 on to an external measurement system.)

Frost & Bryant Standards Track [Page 8] RFC 6374 MPLS Loss and Delay Measurement September 2011

 The derived values
    A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...
    A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...
 are updated each time a response to an LM message is received and
 processed, and they represent the total transmit and receive loss
 over the channel since the LM operation was initiated.
 When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n], the
 possibility of counter wrap must be taken into account.  For example,
 consider the values of the A_TxP counter at sequence numbers n-1 and
 n.  Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a
 value equal to or greater than A_TxP[n-1], the computation of an
 unambiguous A_TxLoss[n-1,n] value will be impossible.  Therefore, the
 LM message rate MUST be sufficiently high, given the counter size and
 the speed and minimum packet size of the underlying channel, that
 this condition cannot arise.  For example, a 32-bit counter for a
 100-Gbps link with a minimum packet size of 64 bytes can wrap in 2^32
 / (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on
 the LM message interval under such conditions.  This bound will be
 referred to as the MaxLMInterval of the channel.  It is clear that
 the MaxLMInterval will be a more restrictive constraint in the case
 of direct LM and for smaller counter sizes.
 The loss measurement approach described in this section has the
 characteristic of being stateless at B and "almost" stateless at A.
 Specifically, A must retain the data associated with the last LM
 response received, in order to use it to compute loss when the next
 response arrives.  This data MAY be discarded, and MUST NOT be used
 as a basis for measurement, if MaxLMInterval elapses before the next
 response arrives, because in this case an unambiguous measurement
 cannot be made.
 The foregoing discussion has assumed the counted objects are packets,
 but this need not be the case.  In particular, octets may be counted
 instead.  This will, of course, reduce the MaxLMInterval accordingly.
 In addition to absolute aggregate loss counts, the individual loss
 counts yield other metrics, such as the average loss rate over any
 multiple of the measurement interval.  An accurate loss rate can be
 determined over time even in the presence of anomalies affecting
 individual measurements, such as those due to packet misordering
 (Section 4.2.10).

Frost & Bryant Standards Track [Page 9] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Note that an approach for conducting packet loss measurement in IP
 networks is documented in [RFC2680].  This approach differs from the
 one described here, for example by requiring clock synchronization
 between the measurement points and lacking support for direct-mode
 LM.

2.3. Throughput Measurement

 If LM query messages contain a timestamp recording their time of
 transmission, this data can be combined with the packet or octet
 counts to yield measurements of the throughput offered and delivered
 over the channel during the interval in terms of the counted units.
 For a bidirectional channel, for example, given any two LM response
 messages (separated in time by not more than the MaxLMInterval), the
 difference between the counter values tells the querier the number of
 units successfully transmitted and received in the interval between
 the timestamps.  Absolute offered throughput is the number of data
 units transmitted and absolute delivered throughput is the number of
 data units received.  Throughput rate is the number of data units
 sent or received per unit time.
 Just as for loss measurement, the interval counts can be accumulated
 to arrive at the absolute throughput of the channel since the start
 of the measurement operation or be used to derive related metrics
 such as the throughput rate.  This procedure also enables out-of-
 service throughput testing when combined with a simple packet
 generator.

2.4. Delay Measurement

 Suppose a bidirectional channel exists between the nodes A and B.
 The objective is to measure at A one or more of the following
 quantities associated with the channel:
 o  The one-way delay associated with the forward (A to B) direction
    of the channel;
 o  The one-way delay associated with the reverse (B to A) direction
    of the channel;
 o  The two-way delay (A to B to A) associated with the channel.
 The one-way delay metric for packet networks is described in
 [RFC2679].  In the case of two-way delay, there are actually two
 possible metrics of interest.  The "two-way channel delay" is the sum
 of the one-way delays in each direction and reflects the delay of the
 channel itself, irrespective of processing delays within the remote

Frost & Bryant Standards Track [Page 10] RFC 6374 MPLS Loss and Delay Measurement September 2011

 endpoint B.  The "round-trip delay" is described in [RFC2681] and
 includes in addition any delay associated with remote endpoint
 processing.
 Measurement of the one-way delay quantities requires that the clocks
 of A and B be synchronized, whereas the two-way delay metrics can be
 measured directly even when this is not the case (provided A and B
 have stable clocks).
 A measurement is accomplished by sending a Delay Measurement (DM)
 query message over the channel to B that contains the following
 timestamp:
    T1: the time the DM query message is transmitted from A.
 When the message arrives at B, the following timestamp is recorded in
 the message:
    T2: the time the DM query message is received at B.
 At this point, B transmits the message back to A, recording within it
 the following timestamp:
    T3: the time the DM response message is transmitted from B.
 When the message arrives back at A, the following timestamp is
 recorded in the message:
    T4: the time the DM response message is received back at A.
 (Strictly speaking, it is not necessary that the fourth timestamp,
 T4, actually be written in the message, but this is convenient for
 some implementations and useful if the message is to be forwarded on
 to an external measurement system.)
 At this point, A can compute the two-way channel delay associated
 with the channel as
    two-way channel delay = (T4 - T1) - (T3 - T2)
 and the round-trip delay as
    round-trip delay = T4 - T1.

Frost & Bryant Standards Track [Page 11] RFC 6374 MPLS Loss and Delay Measurement September 2011

 If the clocks of A and B are known at A to be synchronized, then both
 one-way delay values, as well as the two-way channel delay, can be
 computed at A as
    forward one-way delay = T2 - T1
    reverse one-way delay = T4 - T3
    two-way channel delay = forward delay + reverse delay.
 Note that this formula for the two-way channel delay reduces to the
 one previously given, and clock synchronization is not required to
 compute this metric.

2.5. Delay Variation Measurement

 Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV)
 [RFC5481] are performance metrics derived from one-way delay
 measurement and are important in some applications.  IPDV represents
 the difference between the one-way delays of successive packets in a
 stream.  PDV, given a measurement test interval, represents the
 difference between the one-way delay of a packet in the interval and
 that of the packet in the interval with the minimum delay.
 IPDV and PDV measurements can therefore be derived from delay
 measurements obtained through the procedures in Section 2.4.  An
 important point regarding delay variation measurement, however, is
 that it can be carried out based on one-way delay measurements even
 when the clocks of the two systems involved in those measurements are
 not synchronized with one another.

2.6. Unidirectional Measurement

 In the case that the channel from A to (B1, ..., Bk) (where B2, ...,
 Bk refers to the point-to-multipoint case) is unidirectional, i.e.,
 is a unidirectional LSP, LM and DM measurements can be carried out at
 B1, ..., Bk instead of at A.
 For LM, this is accomplished by initiating an LM operation at A and
 carrying out the same procedures as used for bidirectional channels,
 except that no responses from B1, ..., Bk to A are generated.
 Instead, each terminal node B uses the A_TxP and B_RxP values in the
 LM messages it receives to compute the receive loss associated with
 the channel in essentially the same way as described previously, that
 is:
 B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

Frost & Bryant Standards Track [Page 12] RFC 6374 MPLS Loss and Delay Measurement September 2011

 For DM, of course, only the forward one-way delay can be measured and
 the clock synchronization requirement applies.
 Alternatively, if an out-of-band channel from a terminal node B back
 to A is available, the LM and DM message responses can be
 communicated to A via this channel so that the measurements can be
 carried out at A.

2.7. Dyadic Measurement

 The basic procedures for bidirectional measurement assume that the
 measurement process is conducted by and for the querier node A.
 Instead, it is possible, with only minor variation of these
 procedures, to conduct a dyadic or "dual-ended" measurement process
 in which both nodes A and B perform loss or delay measurement based
 on the same message flow.  This is achieved by stipulating that A
 copy the third and fourth counter or timestamp values from a response
 message into the third and fourth slots of the next query, which are
 otherwise unused, thereby providing B with equivalent information to
 that learned by A.
 The dyadic procedure has the advantage of halving the number of
 messages required for both A and B to perform a given kind of
 measurement, but comes at the expense of each node's ability to
 control its own measurement process independently, and introduces
 additional operational complexity into the measurement protocols.
 The quantity of measurement traffic is also expected to be low
 relative to that of user traffic, particularly when 64-bit counters
 are used for LM.  Consequently, this document does not specify a
 dyadic operational mode.  However, it is still possible, and may be
 useful, for A to perform the extra copy, thereby providing additional
 information to B even when its participation in the measurement
 process is passive.

2.8. Loopback Measurement

 Some bidirectional channels may be placed into a loopback state such
 that messages are looped back to the sender without modification.  In
 this situation, LM and DM procedures can be used to carry out
 measurements associated with the circular path.  This is done by
 generating "queries" with the Response flag set to 1.
 For LM, the loss computation in this case is:
 A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])

Frost & Bryant Standards Track [Page 13] RFC 6374 MPLS Loss and Delay Measurement September 2011

 For DM, the round-trip delay is computed.  In this case, however, the
 remote endpoint processing time component reflects only the time
 required to loop the message from channel input to channel output.

2.9. Measurement Considerations

 A number of additional considerations apply in practice to the
 measurement methods summarized above.

2.9.1. Types of Channels

 There are several types of channels in MPLS networks over which loss
 and delay measurement may be conducted.  The channel type may
 restrict the kinds of measurement that can be performed.  In all
 cases, LM and DM messages flow over the MPLS Generic Associated
 Channel (G-ACh), which is described in detail in [RFC5586].
 Broadly, a channel in an MPLS network may be either a link, a Label
 Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985].  Links are
 bidirectional and are also referred to as MPLS sections; see
 [RFC5586] and [RFC5960].  Pseudowires are bidirectional.  Label
 Switched Paths may be either unidirectional or bidirectional.
 The LM and DM protocols discussed in this document are initiated from
 a single node: the querier.  A query message may be received either
 by a single node or by multiple nodes, depending on the nature of the
 channel.  In the latter case, these protocols provide point-to-
 multipoint measurement capabilities.

2.9.2. Quality of Service

 Quality of Service (QoS) capabilities, in the form of the
 Differentiated Services architecture, apply to MPLS as specified in
 [RFC3270] and [RFC5462].  Different classes of traffic are
 distinguished by the three-bit Traffic Class (TC) field of an MPLS
 Label Stack Entry (LSE).  Delay measurement applies on a per-traffic-
 class basis, and the TC values of LSEs above the G-ACh Label (GAL)
 that precedes a DM message are significant.  Packet loss can be
 measured with respect either to the channel as a whole or to a
 specific traffic class.

2.9.3. Measurement Point Location

 The location of the measurement points for loss and delay within the
 sending and receiving nodes is implementation dependent but directly
 affects the nature of the measurements.  For example, a sending
 implementation may or may not consider a packet to be "lost", for LM
 purposes, that was discarded prior to transmission for queuing-

Frost & Bryant Standards Track [Page 14] RFC 6374 MPLS Loss and Delay Measurement September 2011

 related reasons; conversely, a receiving implementation may or may
 not consider a packet to be "lost", for LM purposes, if it was
 physically received but discarded during receive-path processing.
 The location of delay measurement points similarly determines what,
 precisely, is being measured.  The principal consideration here is
 that the behavior of an implementation in these respects MUST be made
 clear to the user.

2.9.4. Equal Cost Multipath

 Equal Cost Multipath (ECMP) is the behavior of distributing packets
 across multiple alternate paths toward a destination.  The use of
 ECMP in MPLS networks is described in BCP 128 [RFC4928].  The typical
 result of ECMP being performed on an LSP that is subject to delay
 measurement will be that only the delay of one of the available paths
 is, and can be, measured.
 The effects of ECMP on loss measurement will depend on the LM mode.
 In the case of direct LM, the measurement will account for any
 packets lost between the sender and the receiver, regardless of how
 many paths exist between them.  However, the presence of ECMP
 increases the likelihood of misordering both of LM messages relative
 to data packets and of the LM messages themselves.  Such misorderings
 tend to create unmeasurable intervals and thus degrade the accuracy
 of loss measurement.  The effects of ECMP are similar for inferred
 LM, with the additional caveat that, unless the test packets are
 specially constructed so as to probe all available paths, the loss
 characteristics of one or more of the alternate paths cannot be
 accounted for.

2.9.5. Intermediate Nodes

 In the case of an LSP, it may be desirable to measure the loss or
 delay to or from an intermediate node as well as between LSP
 endpoints.  This can be done in principle by setting the Time to Live
 (TTL) field in the outer LSE appropriately when targeting a
 measurement message to an intermediate node.  This procedure may
 fail, however, if hardware-assisted measurement is in use, because
 the processing of the packet by the intermediate node occurs only as
 the result of TTL expiry, and the handling of TTL expiry may occur at
 a later processing stage in the implementation than the hardware-
 assisted measurement function.  The motivation for conducting
 measurements to intermediate nodes is often an attempt to localize a
 problem that has been detected on the LSP.  In this case, if
 intermediate nodes are not capable of performing hardware-assisted
 measurement, a less accurate -- but usually sufficient -- software-
 based measurement can be conducted instead.

Frost & Bryant Standards Track [Page 15] RFC 6374 MPLS Loss and Delay Measurement September 2011

2.9.6. Different Transmit and Receive Interfaces

 The overview of the bidirectional measurement process presented in
 Section 2 is also applicable when the transmit and receive interfaces
 at A or B differ from one another.  Some additional considerations,
 however, do apply in this case:
 o  If different clocks are associated with transmit and receive
    processing, these clocks must be synchronized in order to compute
    the two-way delay.
 o  The DM protocol specified in this document requires that the
    timestamp formats used by the interfaces that receive a DM query
    and transmit a DM response agree.
 o  The LM protocol specified in this document supports both 32-bit
    and 64-bit counter sizes, but the use of 32-bit counters at any of
    the up to four interfaces involved in an LM operation will result
    in 32-bit LM calculations for both directions of the channel.

2.9.7. External Post-Processing

 In some circumstances, it may be desirable to carry out the final
 measurement computation at an external post-processing device
 dedicated to the purpose.  This can be achieved in supporting
 implementations by, for example, configuring the querier, in the case
 of a bidirectional measurement session, to forward each response it
 receives to the post-processor via any convenient protocol.  The
 unidirectional case can be handled similarly through configuration of
 the receiver or by including an instruction in query messages for the
 receiver to respond out-of-band to the appropriate return address.
 Post-processing devices may have the ability to store measurement
 data for an extended period and to generate a variety of useful
 statistics from them.  External post-processing also allows the
 measurement process to be completely stateless at the querier and
 responder.

2.9.8. Loss Measurement Modes

 The summary of loss measurement at the beginning of Section 2 made
 reference to the "count of packets" transmitted and received over a
 channel.  If the counted packets are the packets flowing over the
 channel in the data plane, the loss measurement is said to operate in
 "direct mode".  If, on the other hand, the counted packets are
 selected control packets from which the approximate loss
 characteristics of the channel are being inferred, the loss
 measurement is said to operate in "inferred mode".

Frost & Bryant Standards Track [Page 16] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Direct LM has the advantage of being able to provide perfect loss
 accounting when it is available.  There are, however, several
 constraints associated with direct LM.
 For accurate direct LM to occur, packets must not be sent between the
 time the transmit count for an outbound LM message is determined and
 the time the message is actually transmitted.  Similarly, packets
 must not be received and processed between the time an LM message is
 received and the time the receive count for the message is
 determined.  If these "synchronization conditions" do not hold, the
 LM message counters will not reflect the true state of the data
 plane, with the result that, for example, the receive count of B may
 be greater than the transmit count of A, and attempts to compute loss
 by taking the difference will yield an invalid result.  This
 requirement for synchronization between LM message counters and the
 data plane may require special support from hardware-based forwarding
 implementations.
 A limitation of direct LM is that it may be difficult or impossible
 to apply in cases where the channel is an LSP and the LSP label at
 the receiver is either nonexistent or fails to identify a unique
 sending node.  The first case happens when Penultimate Hop Popping
 (PHP) is used on the LSP, and the second case generally holds for
 LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as
 opposed to, for example, those based on Traffic Engineering
 extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209].
 These conditions may make it infeasible for the receiver to identify
 the data-plane packets associated with a particular source and LSP in
 order to count them, or to infer the source and LSP context
 associated with an LM message.  Direct LM is also vulnerable to
 disruption in the event that the ingress or egress interface
 associated with an LSP changes during the LSP's lifetime.
 Inferred LM works in the same manner as direct LM except that the
 counted packets are special control packets, called test messages,
 generated by the sender.  Test messages may be either packets
 explicitly constructed and used for LM or packets with a different
 primary purpose, such as those associated with a Bidirectional
 Forwarding Detection (BFD) [RFC5884] session.
 The synchronization conditions discussed above for direct LM also
 apply to inferred LM, the only difference being that the required
 synchronization is now between the LM counters and the test message
 generation process.  Protocol and application designers MUST take
 these synchronization requirements into account when developing tools
 for inferred LM, and make their behavior in this regard clear to the
 user.

Frost & Bryant Standards Track [Page 17] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Inferred LM provides only an approximate view of the loss level
 associated with a channel, but is typically applicable even in cases
 where direct LM is not.

2.9.9. Loss Measurement Scope

 In the case of direct LM, where data-plane packets are counted, there
 are different possibilities for which kinds of packets are included
 in the count and which are excluded.  The set of packets counted for
 LM is called the "loss measurement scope".  As noted above, one
 factor affecting the LM scope is whether all data packets are counted
 or only those belonging to a particular traffic class.  Another is
 whether various "auxiliary" flows associated with a data channel are
 counted, such as packets flowing over the G-ACh.  Implementations
 MUST make their supported LM scopes clear to the user, and care must
 be taken to ensure that the scopes of the channel endpoints agree.

2.9.10. Delay Measurement Accuracy

 The delay measurement procedures described in this document are
 designed to facilitate hardware-assisted measurement and to function
 in the same way whether or not such hardware assistance is used.  The
 measurement accuracy will be determined by how closely the transmit
 and receive timestamps correspond to actual packet departure and
 arrival times.
 As noted in Section 2.4, measurement of one-way delay requires clock
 synchronization between the devices involved, while two-way delay
 measurement does not involve direct comparison between non-local
 timestamps and thus has no synchronization requirement.  The
 measurement accuracy will be limited by the quality of the local
 clock and, in the case of one-way delay measurement, by the quality
 of the synchronization.

2.9.11. Delay Measurement Timestamp Format

 There are two significant timestamp formats in common use: the
 timestamp format of the Network Time Protocol (NTP), described in
 [RFC5905], and the timestamp format used in the IEEE 1588 Precision
 Time Protocol (PTP) [IEEE1588].
 The NTP format has the advantages of wide use and long deployment in
 the Internet, and it was specifically designed to make the
 computation of timestamp differences as simple and efficient as
 possible.  On the other hand, there is now also a significant
 deployment of equipment designed to support the PTP format.

Frost & Bryant Standards Track [Page 18] RFC 6374 MPLS Loss and Delay Measurement September 2011

 The approach taken in this document is therefore to include in DM
 messages fields that identify the timestamp formats used by the two
 devices involved in a DM operation.  This implies that a node
 attempting to carry out a DM operation may be faced with the problem
 of computing with and possibly reconciling different timestamp
 formats.  To ensure interoperability, it is necessary that support of
 at least one timestamp format is mandatory.  This specification
 requires the support of the IEEE 1588 PTP format.  Timestamp format
 support requirements are discussed in detail in Section 3.4.

3. Message Formats

 Loss Measurement and Delay Measurement messages flow over the MPLS
 Generic Associated Channel (G-ACh) [RFC5586].  Thus, a packet
 containing an LM or DM message contains an MPLS label stack, with the
 G-ACh Label (GAL) at the bottom of the stack.  The GAL is followed by
 an Associated Channel Header (ACH), which identifies the message
 type, and the message body follows the ACH.
 This document defines the following ACH Channel Types:
    MPLS Direct Loss Measurement (DLM)
    MPLS Inferred Loss Measurement (ILM)
    MPLS Delay Measurement (DM)
    MPLS Direct Loss and Delay Measurement (DLM+DM)
    MPLS Inferred Loss and Delay Measurement (ILM+DM)
 The message formats for direct and inferred LM are identical.  The
 formats of the DLM+DM and ILM+DM messages are also identical.
 For these channel types, the ACH SHALL NOT be followed by the ACH TLV
 Header defined in [RFC5586].
 The fixed-format portion of a message MAY be followed by a block of
 Type-Length-Value (TLV) fields.  The TLV block provides an extensible
 way of attaching subsidiary information to LM and DM messages.
 Several such TLV fields are defined below.
 All integer values for fields defined in this document SHALL be
 encoded in network byte order.

3.1. Loss Measurement Message Format

 The format of a Loss Measurement message, which follows the
 Associated Channel Header (ACH), is as follows:

Frost & Bryant Standards Track [Page 19] RFC 6374 MPLS Loss and Delay Measurement September 2011

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| Flags |  Control Code |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | DFlags|  OTF  |                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Session Identifier          |    DS     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Origin Timestamp                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Counter 1                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Counter 4                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           TLV Block                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Loss Measurement Message Format
 Reserved fields MUST be set to 0 and ignored upon receipt.  The
 possible values for the remaining fields are as follows.

Frost & Bryant Standards Track [Page 20] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Field                 Meaning
 --------------------- -----------------------------------------------
 Version               Protocol version
 Flags                 Message control flags
 Control Code          Code identifying the query or response type
 Message Length        Total length of this message in bytes
 Data Format Flags     Flags specifying the format of message data
 (DFlags)
 Origin Timestamp      Format of the Origin Timestamp field
 Format (OTF)
 Reserved              Reserved for future specification
 Session Identifier    Set arbitrarily by the querier
 Differentiated        Differentiated Services Code Point (DSCP) being
 Services (DS) Field   measured
 Origin Timestamp      64-bit field for query message transmission
                       timestamp
 Counter 1-4           64-bit fields for LM counter values
 TLV Block             Optional block of Type-Length-Value fields
 The possible values for these fields are as follows.
 Version: Currently set to 0.
 Flags: The format of the Flags field is shown below.
                             +-+-+-+-+
                             |R|T|0|0|
                             +-+-+-+-+
                    Loss Measurement Message Flags
 The meanings of the flag bits are:
    R: Query/Response indicator.  Set to 0 for a Query and 1 for a
    Response.
    T: Traffic-class-specific measurement indicator.  Set to 1 when
    the measurement operation is scoped to packets of a particular
    traffic class (DSCP value), and 0 otherwise.  When set to 1, the
    DS field of the message indicates the measured traffic class.
    0: Set to 0.
 Control Code: Set as follows according to whether the message is a
 Query or a Response as identified by the R flag.

Frost & Bryant Standards Track [Page 21] RFC 6374 MPLS Loss and Delay Measurement September 2011

    For a Query:
       0x0: In-band Response Requested.  Indicates that this query has
       been sent over a bidirectional channel and the response is
       expected over the same channel.
       0x1: Out-of-band Response Requested.  Indicates that the
       response should be sent via an out-of-band channel.
       0x2: No Response Requested.  Indicates that no response to the
       query should be sent.  This mode can be used, for example, if
       all nodes involved are being controlled by a Network Management
       System.
    For a Response:
       Codes 0x0-0xF are reserved for non-error responses.  Error
       response codes imply that the response does not contain valid
       measurement data.
       0x1: Success.  Indicates that the operation was successful.
       0x2: Notification - Data Format Invalid.  Indicates that the
       query was processed, but the format of the data fields in this
       response may be inconsistent.  Consequently, these data fields
       MUST NOT be used for measurement.
       0x3: Notification - Initialization in Progress.  Indicates that
       the query was processed but this response does not contain
       valid measurement data because the responder's initialization
       process has not completed.
       0x4: Notification - Data Reset Occurred.  Indicates that the
       query was processed, but a reset has recently occurred that may
       render the data in this response inconsistent relative to
       earlier responses.
       0x5: Notification - Resource Temporarily Unavailable.
       Indicates that the query was processed, but resources were
       unavailable to complete the requested measurement and that,
       consequently, this response does not contain valid measurement
       data.
       0x10: Error - Unspecified Error.  Indicates that the operation
       failed for an unspecified reason.

Frost & Bryant Standards Track [Page 22] RFC 6374 MPLS Loss and Delay Measurement September 2011

       0x11: Error - Unsupported Version.  Indicates that the
       operation failed because the protocol version supplied in the
       query message is not supported.
       0x12: Error - Unsupported Control Code.  Indicates that the
       operation failed because the Control Code requested an
       operation that is not available for this channel.
       0x13: Error - Unsupported Data Format.  Indicates that the
       operation failed because the data format specified in the query
       is not supported.
       0x14: Error - Authentication Failure.  Indicates that the
       operation failed because the authentication data supplied in
       the query was missing or incorrect.
       0x15: Error - Invalid Destination Node Identifier.  Indicates
       that the operation failed because the Destination Node
       Identifier supplied in the query is not an identifier of this
       node.
       0x16: Error - Connection Mismatch.  Indicates that the
       operation failed because the channel identifier supplied in the
       query did not match the channel over which the query was
       received.
       0x17: Error - Unsupported Mandatory TLV Object.  Indicates that
       the operation failed because a TLV Object received in the query
       and marked as mandatory is not supported.
       0x18: Error - Unsupported Query Interval.  Indicates that the
       operation failed because the query message rate exceeded the
       configured threshold.
       0x19: Error - Administrative Block.  Indicates that the
       operation failed because it has been administratively
       disallowed.
       0x1A: Error - Resource Unavailable.  Indicates that the
       operation failed because node resources were not available.
       0x1B: Error - Resource Released.  Indicates that the operation
       failed because node resources for this measurement session were
       administratively released.
       0x1C: Error - Invalid Message.  Indicates that the operation
       failed because the received query message was malformed.

Frost & Bryant Standards Track [Page 23] RFC 6374 MPLS Loss and Delay Measurement September 2011

       0x1D: Error - Protocol Error.  Indicates that the operation
       failed because a protocol error was found in the received query
       message.
 Message Length: Set to the total length of this message in bytes,
 including the Version, Flags, Control Code, and Message Length fields
 as well as the TLV Block, if any.
 DFlags: The format of the DFlags field is shown below.
                             +-+-+-+-+
                             |X|B|0|0|
                             +-+-+-+-+
                           Data Format Flags
 The meanings of the DFlags bits are:
    X: Extended counter format indicator.  Indicates the use of
    extended (64-bit) counter values.  Initialized to 1 upon creation
    (and prior to transmission) of an LM Query and copied from an LM
    Query to an LM response.  Set to 0 when the LM message is
    transmitted or received over an interface that writes 32-bit
    counter values.
    B: Octet (byte) count.  When set to 1, indicates that the Counter
    1-4 fields represent octet counts.  The octet count applies to all
    packets within the LM scope (Section 2.9.9), and the octet count
    of a packet sent or received over a channel includes the total
    length of that packet (but excludes headers, labels, or framing of
    the channel itself).  When set to 0, indicates that the Counter
    1-4 fields represent packet counts.
    0: Set to 0.
 Origin Timestamp Format: The format of the Origin Timestamp field, as
 specified in Section 3.4.
 Session Identifier: Set arbitrarily in a query and copied in the
 response, if any.  This field uniquely identifies a measurement
 operation (also called a session) that consists of a sequence of
 messages.  All messages in the sequence have the same Session
 Identifier.
 DS: When the T flag is set to 1, this field is set to the DSCP value
 [RFC3260] that corresponds to the traffic class being measured.  For
 MPLS, where the traffic class of a channel is identified by the
 three-bit Traffic Class in the channel's LSE [RFC5462], this field

Frost & Bryant Standards Track [Page 24] RFC 6374 MPLS Loss and Delay Measurement September 2011

 SHOULD be set to the Class Selector Codepoint [RFC2474] that
 corresponds to that Traffic Class.  When the T flag is set to 0, the
 value of this field is arbitrary, and the field can be considered
 part of the Session Identifier.
 Origin Timestamp: Timestamp recording the transmit time of the query
 message.
 Counter 1-4: Referring to Section 2.2, when a query is sent from A,
 Counter 1 is set to A_TxP and the other counter fields are set to 0.
 When the query is received at B, Counter 2 is set to B_RxP.  At this
 point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4,
 and re-initializes Counter 1 and Counter 2 to 0.  When B transmits
 the response, Counter 1 is set to B_TxP.  When the response is
 received at A, Counter 2 is set to A_RxP.
 The mapping of counter types such as A_TxP to the Counter 1-4 fields
 is designed to ensure that transmit counter values are always written
 at the same fixed offset in the packet, and likewise for receive
 counters.  This property may be important for hardware processing.
 When a 32-bit counter value is written to one of the counter fields,
 that value SHALL be written to the low-order 32 bits of the field;
 the high-order 32 bits of the field MUST, in this case, be set to 0.
 TLV Block: Zero or more TLV fields.

3.2. Delay Measurement Message Format

 The format of a Delay Measurement message, which follows the
 Associated Channel Header (ACH), is as follows:

Frost & Bryant Standards Track [Page 25] RFC 6374 MPLS Loss and Delay Measurement September 2011

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| Flags |  Control Code |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  QTF  |  RTF  | RPTF  |              Reserved                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Session Identifier          |    DS     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp 1                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp 4                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           TLV Block                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Delay Measurement Message Format
 The meanings of the fields are summarized in the following table.
 Field                 Meaning
 --------------------- -----------------------------------------------
 Version               Protocol version
 Flags                 Message control flags
 Control Code          Code identifying the query or response type
 Message Length        Total length of this message in bytes
 QTF                   Querier timestamp format
 RTF                   Responder timestamp format
 RPTF                  Responder's preferred timestamp format
 Reserved              Reserved for future specification
 Session Identifier    Set arbitrarily by the querier
 Differentiated        Differentiated Services Code Point (DSCP) being
 Services (DS) Field   measured
 Timestamp 1-4         64-bit timestamp values
 TLV Block             Optional block of Type-Length-Value fields
 Reserved fields MUST be set to 0 and ignored upon receipt.  The
 possible values for the remaining fields are as follows.
 Version: Currently set to 0.

Frost & Bryant Standards Track [Page 26] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Flags: As specified in Section 3.1.  The T flag in a DM message is
 set to 1.
 Control Code: As specified in Section 3.1.
 Message Length: Set to the total length of this message in bytes,
 including the Version, Flags, Control Code, and Message Length fields
 as well as the TLV Block, if any.
 Querier Timestamp Format: The format of the timestamp values written
 by the querier, as specified in Section 3.4.
 Responder Timestamp Format: The format of the timestamp values
 written by the responder, as specified in Section 3.4.
 Responder's Preferred Timestamp Format: The timestamp format
 preferred by the responder, as specified in Section 3.4.
 Session Identifier: As specified in Section 3.1.
 DS: As specified in Section 3.1.
 Timestamp 1-4: Referring to Section 2.4, when a query is sent from A,
 Timestamp 1 is set to T1 and the other timestamp fields are set to 0.
 When the query is received at B, Timestamp 2 is set to T2.  At this
 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to
 Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0.
 When B transmits the response, Timestamp 1 is set to T3.  When the
 response is received at A, Timestamp 2 is set to T4.  The actual
 formats of the timestamp fields written by A and B are indicated by
 the Querier Timestamp Format and Responder Timestamp Format fields
 respectively.
 The mapping of timestamps to the Timestamp 1-4 fields is designed to
 ensure that transmit timestamps are always written at the same fixed
 offset in the packet, and likewise for receive timestamps.  This
 property is important for hardware processing.
 TLV Block: Zero or more TLV fields.

3.3. Combined Loss/Delay Measurement Message Format

 The format of a combined Loss and Delay Measurement message, which
 follows the Associated Channel Header (ACH), is as follows:

Frost & Bryant Standards Track [Page 27] RFC 6374 MPLS Loss and Delay Measurement September 2011

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| Flags |  Control Code |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | DFlags|  QTF  |  RTF  | RPTF  |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Session Identifier          |    DS     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp 1                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp 4                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Counter 1                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Counter 4                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           TLV Block                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Loss/Delay Measurement Message Format
 The fields of this message have the same meanings as the
 corresponding fields in the LM and DM message formats, except that
 the roles of the OTF and Origin Timestamp fields for LM are here
 played by the QTF and Timestamp 1 fields, respectively.

3.4. Timestamp Field Formats

 The following timestamp format field values are specified in this
 document:
    0: Null timestamp format.  This value is a placeholder indicating
    that the timestamp field does not contain a meaningful timestamp.

Frost & Bryant Standards Track [Page 28] RFC 6374 MPLS Loss and Delay Measurement September 2011

    1: Sequence number.  This value indicates that the timestamp field
    is to be viewed as a simple 64-bit sequence number.  This provides
    a simple solution for applications that do not require a real
    absolute timestamp, but only an indication of message ordering; an
    example is LM exception detection.
    2: Network Time Protocol version 4 64-bit timestamp format
    [RFC5905].  This format consists of a 32-bit seconds field
    followed by a 32-bit fractional seconds field, so that it can be
    regarded as a fixed-point 64-bit quantity.
    3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time
    Protocol timestamp format [IEEE1588].  This truncated format
    consists of a 32-bit seconds field followed by a 32-bit
    nanoseconds field, and is the same as the IEEE 1588v1 timestamp
    format.
 Timestamp formats of n < 64 bits in size SHALL be encoded in the
 64-bit timestamp fields specified in this document using the n high-
 order bits of the field.  The remaining 64 - n low-order bits in the
 field SHOULD be set to 0 and MUST be ignored when reading the field.
 To ensure that it is possible to find an interoperable mode between
 implementations, it is necessary to select one timestamp format as
 the default.  The timestamp format chosen as the default is the
 truncated IEEE 1588 PTP format (format code 3 in the list above);
 this format MUST be supported.  The rationale for this choice is
 discussed in Appendix A.  Implementations SHOULD also be capable of
 reading timestamps written in NTPv4 64-bit format and reconciling
 them internally with PTP timestamps for measurement purposes.
 Support for other timestamp formats is OPTIONAL.
 The implementation MUST make clear which timestamp formats it
 supports and the extent of its support for computation with and
 reconciliation of different formats for measurement purposes.

3.5. TLV Objects

 The TLV Block in LM and DM messages consists of zero or more objects
 with the following format:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |        Value                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              TLV Format

Frost & Bryant Standards Track [Page 29] RFC 6374 MPLS Loss and Delay Measurement September 2011

 The Type and Length fields are each 8 bits long, and the Length field
 indicates the size in bytes of the Value field, which can therefore
 be up to 255 bytes long.
 The Type space is divided into Mandatory and Optional subspaces:
 Type Range     Semantics
 -------------- ---------
 0-127          Mandatory
 128-255        Optional
 Upon receipt of a query message including an unrecognized mandatory
 TLV object, the recipient MUST respond with an Unsupported Mandatory
 TLV Object error code.
 The types defined are as follows:
 Type           Definition
 -------------- ---------------------------------
 Mandatory
 0              Padding - copy in response
 1              Return Address
 2              Session Query Interval
 3              Loopback Request
 4-126          Unallocated
 127            Experimental use
 Optional
 128            Padding - do not copy in response
 129            Destination Address
 130            Source Address
 131-254        Unallocated
 255            Experimental use

3.5.1. Padding

 The two padding objects permit the augmentation of packet size; this
 is mainly useful for delay measurement.  The type of padding
 indicates whether the padding supplied by the querier is to be copied
 to, or omitted from, the response.  Asymmetrical padding may be
 useful when responses are delivered out-of-band or when different
 maximum transmission unit sizes apply to the two components of a
 bidirectional channel.
 More than one padding object MAY be present, in which case they MUST
 be contiguous.  The Value field of a padding object is arbitrary.

Frost & Bryant Standards Track [Page 30] RFC 6374 MPLS Loss and Delay Measurement September 2011

3.5.2. Addressing

 The addressing objects have the following format:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |        Address Family         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           Address                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Addressing Object Format
 The Address Family field indicates the type of the address, and it
 SHALL be set to one of the assigned values in the "IANA Address
 Family Numbers" registry.
 The Source and Destination Address objects indicate the addresses of
 the sender and the intended recipient of the message, respectively.
 The Source Address of a query message SHOULD be used as the
 destination for an out-of-band response unless some other out-of-band
 response mechanism has been configured, and unless a Return Address
 object is present, in which case the Return Address specifies the
 target of the response.  The Return Address object MUST NOT appear in
 a response.

3.5.3. Loopback Request

 The Loopback Request object, when included in a query, indicates a
 request that the query message be returned to the sender unmodified.
 This object has a Length of 0.
 Upon receiving the reflected query message back from the responder,
 the querier MUST NOT retransmit the message.  Information that
 uniquely identifies the original query source, such as a Source
 Address object, can be included to enable the querier to
 differentiate one of its own loopback queries from a loopback query
 initiated by the far end.
 This object may be useful, for example, when the querier is
 interested only in the round-trip delay metric.  In this case, no
 support for delay measurement is required at the responder at all,
 other than the ability to recognize a DM query that includes this
 object and return it unmodified.

Frost & Bryant Standards Track [Page 31] RFC 6374 MPLS Loss and Delay Measurement September 2011

3.5.4. Session Query Interval

 The Value field of the Session Query Interval object is a 32-bit
 unsigned integer that specifies a time interval in milliseconds.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            Session Query      >
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     <        Interval (ms)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Session Query Interval Object Format
 This time interval indicates the interval between successive query
 messages in a specific measurement session.  The purpose of the
 Session Query Interval (SQI) object is to enable the querier and
 responder of a measurement session to agree on a query rate.  The
 procedures for handling this object SHALL be as follows:
 1.  The querier notifies the responder that it wishes to be informed
     of the responder's minimum query interval for this session by
     including the SQI object in its query messages, with a Value of
     0.
 2.  When the responder receives a query that includes an SQI object
     with a Value of 0, the responder includes an SQI object in the
     response with the Value set to the minimum query interval it
     supports for this session.
 3.  When the querier receives a response that includes an SQI object,
     it selects a query interval for the session that is greater than
     or equal to the Value specified in the SQI object and adjusts its
     query transmission rate accordingly, including in each subsequent
     query an SQI object with a Value equal to the selected query
     interval.  Once a response to one of these subsequent queries has
     been received, the querier infers that the responder has been
     apprised of the selected query interval and MAY then stop
     including the SQI object in queries associated with this session.
 Similar procedures allow the query rate to be changed during the
 course of the session by either the querier or the responder.  For
 example, to inform the querier of a change in the minimum supported
 query interval, the responder begins including a corresponding SQI
 object in its responses, and the querier adjusts its query rate if
 necessary and includes a corresponding SQI object in its queries
 until a response is received.

Frost & Bryant Standards Track [Page 32] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Shorter query intervals (i.e., higher query rates) provide finer
 measurement granularity at the expense of additional load on
 measurement endpoints and the network; see Section 6 for further
 discussion.

4. Operation

4.1. Operational Overview

 A loss or delay measurement operation, also called a session, is
 controlled by the querier and consists of a sequence of query
 messages associated with a particular channel and a common set of
 measurement parameters.  If the session parameters include a response
 request, then the receiving node or nodes will (under normal
 conditions) generate a response message for each query message
 received, and these responses are also considered part of the
 session.  All query and response messages in a session carry a common
 session identifier.
 Measurement sessions are initiated at the discretion of the network
 operator and are terminated either at the operator's request or as
 the result of an error condition.  A session may be as brief as a
 single message exchange, for example when a DM query is used by the
 operator to "ping" a remote node, or it may extend throughout the
 lifetime of the channel.
 When a session is initiated for which responses are requested, the
 querier SHOULD initialize a timer, called the SessionResponseTimeout,
 that indicates how long the querier will wait for a response before
 abandoning the session and notifying the user that a timeout has
 occurred.  This timer persists for the lifetime of the session and is
 reset each time a response message for the session is received.
 When a query message is received that requests a response, a variety
 of exceptional conditions may arise that prevent the responder from
 generating a response that contains valid measurement data.  Such
 conditions fall broadly into two classes: transient exceptions from
 which recovery is possible and fatal exceptions that require
 termination of the session.  When an exception arises, the responder
 SHOULD generate a response with an appropriate Notification or Error
 control code according to whether the exception is, respectively,
 transient or fatal.  When the querier receives an Error response, the
 session MUST be terminated and the user informed.
 A common example of a transient exception occurs when a new session
 is initiated and the responder requires a period of time to become
 ready before it can begin providing useful responses.  The response
 control code corresponding to this situation is Notification -

Frost & Bryant Standards Track [Page 33] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Initialization in Progress.  Typical examples of fatal exceptions are
 cases where the querier has requested a type of measurement that the
 responder does not support or where a query message is malformed.
 When initiating a session, the querier SHOULD employ the Session
 Query Interval mechanism (Section 3.5.4) to establish a mutually
 agreeable query rate with the responder.  Responders SHOULD employ
 rate-limiting mechanisms to guard against the possibility of
 receiving an excessive quantity of query messages.

4.2. Loss Measurement Procedures

4.2.1. Initiating a Loss Measurement Operation

 An LM operation for a particular channel consists of sending a
 sequence (LM[1], LM[2], ...) of LM query messages over the channel at
 a specific rate and processing the responses received, if any.  As
 described in Section 2.2, the packet loss associated with the channel
 during the operation is computed as a delta between successive
 messages; these deltas can be accumulated to obtain a running total
 of the packet loss for the channel or be used to derive related
 metrics such as the average loss rate.
 The query message transmission rate MUST be sufficiently high, given
 the LM message counter size (which can be either 32 or 64 bits) and
 the speed and minimum packet size of the underlying channel, that the
 ambiguity condition noted in Section 2.2 cannot arise.  In evaluating
 this rate, the implementation SHOULD assume that the counter size is
 32 bits unless explicitly configured otherwise or unless (in the case
 of a bidirectional channel) all local and remote interfaces involved
 in the LM operation are known to be 64-bit-capable, which can be
 inferred from the value of the X flag in an LM response.

4.2.2. Transmitting a Loss Measurement Query

 When transmitting an LM Query, the Version field MUST be set to 0.
 The R flag MUST be set to 0.  The T flag SHALL be set to 1 if, and
 only if, the measurement is specific to a particular traffic class,
 in which case the DS field SHALL identify that traffic class.
 The X flag MUST be set to 1 if the transmitting interface writes
 64-bit LM counters and otherwise MUST be set to 0 to indicate that
 32-bit counters are written.  The B flag SHALL be set to 1 to
 indicate that the counter fields contain octet counts or to 0 to
 indicate packet counts.

Frost & Bryant Standards Track [Page 34] RFC 6374 MPLS Loss and Delay Measurement September 2011

 The Control Code field MUST be set to one of the values for Query
 messages listed in Section 3.1; if the channel is unidirectional,
 this field MUST NOT be set to 0x0 (Query: In-band Response
 Requested).
 The Session Identifier field can be set arbitrarily.
 The Origin Timestamp field SHALL be set to the time at which this
 message is transmitted, and the Origin Timestamp Format field MUST be
 set to indicate its format, according to Section 3.4.
 The Counter 1 field SHOULD be set to the total count of units
 (packets or octets, according to the B flag) transmitted over the
 channel prior to this LM Query, or to 0 if this is the beginning of a
 measurement session for which counter data is not yet available.  The
 Counter 2 field MUST be set to 0.  If a response was previously
 received in this measurement session, the Counter 1 and Counter 2
 fields of the most recent such response MAY be copied to the Counter
 3 and Counter 4 fields, respectively, of this query; otherwise, the
 Counter 3 and Counter 4 fields MUST be set to 0.

4.2.3. Receiving a Loss Measurement Query

 Upon receipt of an LM Query message, the Counter 2 field SHOULD be
 set to the total count of units (packets or octets, according to the
 B flag) received over the channel prior to this LM Query.  If the
 receiving interface writes 32-bit LM counters, the X flag MUST be set
 to 0.
 At this point, the LM Query message must be inspected.  If the
 Control Code field is set to 0x2 (No Response Requested), an LM
 Response message MUST NOT be transmitted.  If the Control Code field
 is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band
 Response Requested), then an in-band or out-of-band response,
 respectively, SHOULD be transmitted unless this has been prevented by
 an administrative, security, or congestion control mechanism.
 In the case of a fatal exception that prevents the requested
 measurement from being made, the error SHOULD be reported, via either
 a response, if one was requested, or else as a notification to the
 user.

4.2.4. Transmitting a Loss Measurement Response

 When constructing a Response to an LM Query, the Version field MUST
 be set to 0.  The R flag MUST be set to 1.  The value of the T flag
 MUST be copied from the LM Query.

Frost & Bryant Standards Track [Page 35] RFC 6374 MPLS Loss and Delay Measurement September 2011

 The X flag MUST be set to 0 if the transmitting interface writes
 32-bit LM counters; otherwise, its value MUST be copied from the LM
 Query.  The B flag MUST be copied from the LM Query.
 The Session Identifier, Origin Timestamp, and Origin Timestamp Format
 fields MUST be copied from the LM Query.  The Counter 1 and Counter 2
 fields from the LM Query MUST be copied to the Counter 3 and Counter
 4 fields, respectively, of the LM Response.
 The Control Code field MUST be set to one of the values for Response
 messages listed in Section 3.1.  The value 0x10 (Unspecified Error)
 SHOULD NOT be used if one of the other more specific error codes is
 applicable.
 If the response is transmitted in-band, the Counter 1 field SHOULD be
 set to the total count of units transmitted over the channel prior to
 this LM Response.  If the response is transmitted out-of-band, the
 Counter 1 field MUST be set to 0.  In either case, the Counter 2
 field MUST be set to 0.

4.2.5. Receiving a Loss Measurement Response

 Upon in-band receipt of an LM Response message, the Counter 2 field
 is set to the total count of units received over the channel prior to
 this LM Response.  If the receiving interface writes 32-bit LM
 counters, the X flag is set to 0.  (Since the life of the LM message
 in the network has ended at this point, it is up to the receiver
 whether these final modifications are made to the packet.  If the
 message is to be forwarded on for external post-processing
 (Section 2.9.7), then these modifications MUST be made.)
 Upon out-of-band receipt of an LM Response message, the Counter 1 and
 Counter 2 fields MUST NOT be used for purposes of loss measurement.
 If the Control Code in an LM Response is anything other than 0x1
 (Success), the counter values in the response MUST NOT be used for
 purposes of loss measurement.  If the Control Code indicates an error
 condition, or if the response message is invalid, the LM operation
 MUST be terminated and an appropriate notification to the user
 generated.

4.2.6. Loss Calculation

 Calculation of packet loss is carried out according to the procedures
 in Section 2.2.  The X flag in an LM message informs the device
 performing the calculation whether to perform 32-bit or 64-bit
 arithmetic.  If the flag value is equal to 1, all interfaces involved
 in the LM operation have written 64-bit counter values, and 64-bit

Frost & Bryant Standards Track [Page 36] RFC 6374 MPLS Loss and Delay Measurement September 2011

 arithmetic can be used.  If the flag value is equal to 0, at least
 one interface involved in the operation has written a 32-bit counter
 value, and 32-bit arithmetic is carried out using the low-order 32
 bits of each counter value.
 Note that the semantics of the X flag allow all devices to
 interoperate regardless of their counter size support.  Thus, an
 implementation MUST NOT generate an error response based on the value
 of this flag.

4.2.7. Quality of Service

 The TC field of the LSE corresponding to the channel (e.g., LSP)
 being measured SHOULD be set to a traffic class equal to or better
 than the best TC within the measurement scope to minimize the chance
 of out-of-order conditions.

4.2.8. G-ACh Packets

 By default, direct LM MUST exclude packets transmitted and received
 over the Generic Associated Channel (G-ACh).  An implementation MAY
 provide the means to alter the direct LM scope to include some or all
 G-ACh messages.  Care must be taken when altering the LM scope to
 ensure that both endpoints are in agreement.

4.2.9. Test Messages

 In the case of inferred LM, the packets counted for LM consist of
 test messages generated for this purpose, or of some other class of
 packets deemed to provide a good proxy for data packets flowing over
 the channel.  The specification of test protocols and proxy packets
 is outside the scope of this document, but some guidelines are
 discussed below.
 An identifier common to both the test or proxy messages and the LM
 messages may be required to make correlation possible.  The combined
 value of the Session Identifier and DS fields SHOULD be used for this
 purpose when possible.  That is, test messages in this case will
 include a 32-bit field that can carry the value of the combined
 Session Identifier + DS field present in LM messages.  When TC-
 specific LM is conducted, the DS field of the LSE in the label stack
 of a test message corresponding to the channel (e.g., LSP) over which
 the message is sent MUST correspond to the DS value in the associated
 LM messages.
 A separate test message protocol SHOULD include a timeout value in
 its messages that informs the responder when to discard any state
 associated with a specific test.

Frost & Bryant Standards Track [Page 37] RFC 6374 MPLS Loss and Delay Measurement September 2011

4.2.10. Message Loss and Packet Misorder Conditions

 Because an LM operation consists of a message sequence with state
 maintained from one message to the next, LM is subject to the effects
 of lost messages and misordered packets in a way that DM is not.
 Because this state exists only on the querier, the handling of these
 conditions is, strictly speaking, a local matter.  This section,
 however, presents recommended procedures for handling such
 conditions.  Note that in the absence of ECMP, packet misordering
 within a traffic class is a relatively rare event.
 The first kind of anomaly that may occur is that one or more LM
 messages may be lost in transit.  The effect of such loss is that
 when an LM Response is next received at the querier, an unambiguous
 interpretation of the counter values it contains may be impossible,
 for the reasons described at the end of Section 2.2.  Whether this is
 so depends on the number of messages lost and the other variables
 mentioned in that section, such as the LM message rate and the
 channel parameters.
 Another possibility is that LM messages are misordered in transit, so
 that, for instance, the response to LM[n] is received prior to the
 response to LM[n-1].  A typical implementation will discard the late
 response to LM[n-1], so that the effect is the same as the case of a
 lost message.
 Finally, LM is subject to the possibility that data packets are
 misordered relative to LM messages.  This condition can result, for
 example, in a transmit count of 100 and a corresponding receive count
 of 101.  The effect here is that the A_TxLoss[n-1,n] value (for
 example) for a given measurement interval will appear to be extremely
 (if not impossibly) large.  The other case, where an LM message
 arrives earlier than some of the packets, simply results in those
 packets being counted as lost.
 An implementation SHOULD identify a threshold value that indicates
 the upper bound of lost packets measured in a single computation
 beyond which the interval is considered unmeasurable.  This is called
 the "MaxLMIntervalLoss threshold".  It is clear that this threshold
 should be no higher than the maximum number of packets (or bytes) the
 channel is capable of transmitting over the interval, but it may be
 lower.  Upon encountering an unmeasurable interval, the LM state
 (i.e., data values from the last LM message received) SHOULD be
 discarded.
 With regard to lost LM messages, the MaxLMInterval (see Section 2.2)
 indicates the maximum amount of time that can elapse before the LM
 state is discarded.  If some messages are lost, but a message is

Frost & Bryant Standards Track [Page 38] RFC 6374 MPLS Loss and Delay Measurement September 2011

 subsequently received within MaxLMInterval, its timestamp or sequence
 number will quantify the loss, and it MAY still be used for
 measurement, although the measurement interval will in this case be
 longer than usual.
 If an LM message is received that has a timestamp less than or equal
 to the timestamp of the last LM message received, this indicates that
 an exception has occurred, and the current interval SHOULD be
 considered unmeasurable unless the implementation has some other way
 of handling this condition.

4.3. Delay Measurement Procedures

4.3.1. Transmitting a Delay Measurement Query

 When transmitting a DM Query, the Version and Reserved fields MUST be
 set to 0.  The R flag MUST be set to 0, the T flag MUST be set to 1,
 and the remaining flag bits MUST be set to 0.
 The Control Code field MUST be set to one of the values for Query
 messages listed in Section 3.1; if the channel is unidirectional,
 this field MUST NOT be set to 0x0 (Query: In-band Response
 Requested).
 The Querier Timestamp Format field MUST be set to the timestamp
 format used by the querier when writing timestamp fields in this
 message; the possible values for this field are listed in
 Section 3.4.  The Responder Timestamp Format and Responder's
 Preferred Timestamp Format fields MUST be set to 0.
 The Session Identifier field can be set arbitrarily.  The DS field
 MUST be set to the traffic class being measured.
 The Timestamp 1 field SHOULD be set to the time at which this DM
 Query is transmitted, in the format indicated by the Querier
 Timestamp Format field.  The Timestamp 2 field MUST be set to 0.  If
 a response was previously received in this measurement session, the
 Timestamp 1 and Timestamp 2 fields of the most recent such response
 MAY be copied to the Timestamp 3 and Timestamp 4 fields,
 respectively, of this query; otherwise, the Timestamp 3 and Timestamp
 4 fields MUST be set to 0.

4.3.2. Receiving a Delay Measurement Query

 Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be
 set to the time at which this DM Query was received.

Frost & Bryant Standards Track [Page 39] RFC 6374 MPLS Loss and Delay Measurement September 2011

 At this point, the DM Query message must be inspected.  If the
 Control Code field is set to 0x2 (No Response Requested), a DM
 Response message MUST NOT be transmitted.  If the Control Code field
 is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band
 Response Requested), then an in-band or out-of-band response,
 respectively, SHOULD be transmitted unless this has been prevented by
 an administrative, security, or congestion control mechanism.
 In the case of a fatal exception that prevents the requested
 measurement from being made, the error SHOULD be reported, via either
 a response, if one was requested, or else as a notification to the
 user.

4.3.3. Transmitting a Delay Measurement Response

 When constructing a Response to a DM Query, the Version and Reserved
 fields MUST be set to 0.  The R flag MUST be set to 1, the T flag
 MUST be set to 1, and the remaining flag bits MUST be set to 0.
 The Session Identifier and Querier Timestamp Format (QTF) fields MUST
 be copied from the DM Query.  The Timestamp 1 and Timestamp 2 fields
 from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4
 fields, respectively, of the DM Response.
 The Responder Timestamp Format (RTF) field MUST be set to the
 timestamp format used by the responder when writing timestamp fields
 in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1;
 the possible values for this field are listed in Section 3.4.
 Furthermore, the RTF field MUST be set equal to either the QTF or the
 RPTF field.  See Section 4.3.5 for guidelines on the selection of the
 value for this field.
 The Responder's Preferred Timestamp Format (RPTF) field MUST be set
 to one of the values listed in Section 3.4 and SHOULD be set to
 indicate the timestamp format with which the responder can provide
 the best accuracy for purposes of delay measurement.
 The Control Code field MUST be set to one of the values for Response
 messages listed in Section 3.1.  The value 0x10 (Unspecified Error)
 SHOULD NOT be used if one of the other more specific error codes is
 applicable.
 If the response is transmitted in-band, the Timestamp 1 field SHOULD
 be set to the time at which this DM Response is transmitted.  If the
 response is transmitted out-of-band, the Timestamp 1 field MUST be
 set to 0.  In either case, the Timestamp 2 field MUST be set to 0.

Frost & Bryant Standards Track [Page 40] RFC 6374 MPLS Loss and Delay Measurement September 2011

 If the response is transmitted in-band and the Control Code in the
 message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields
 MUST have the same format, which will be the format indicated in the
 Responder Timestamp Format field.

4.3.4. Receiving a Delay Measurement Response

 Upon in-band receipt of a DM Response message, the Timestamp 2 field
 is set to the time at which this DM Response was received.  (Since
 the life of the DM message in the network has ended at this point, it
 is up to the receiver whether this final modification is made to the
 packet.  If the message is to be forwarded on for external post-
 processing (Section 2.9.7), then these modifications MUST be made.)
 Upon out-of-band receipt of a DM Response message, the Timestamp 1
 and Timestamp 2 fields MUST NOT be used for purposes of delay
 measurement.
 If the Control Code in a DM Response is anything other than 0x1
 (Success), the timestamp values in the response MUST NOT be used for
 purposes of delay measurement.  If the Control Code indicates an
 error condition, or if the response message is invalid, the DM
 operation MUST be terminated and an appropriate notification to the
 user generated.

4.3.5. Timestamp Format Negotiation

 In case either the querier or the responder in a DM transaction is
 capable of supporting multiple timestamp formats, it is desirable to
 determine the optimal format for purposes of delay measurement on a
 particular channel.  The procedures for making this determination
 SHALL be as follows.
 Upon sending an initial DM Query over a channel, the querier sets the
 Querier Timestamp Format (QTF) field to its preferred timestamp
 format.
 Upon receiving any DM Query message, the responder determines whether
 it is capable of writing timestamps in the format specified by the
 QTF field.  If so, the Responder Timestamp Format (RTF) field is set
 equal to the QTF field.  If not, the RTF field is set equal to the
 Responder's Preferred Timestamp Format (RPTF) field.
 The process of changing from one timestamp format to another at the
 responder may result in the Timestamp 1 and Timestamp 4 fields in an
 in-band DM Response having different formats.  If this is the case,

Frost & Bryant Standards Track [Page 41] RFC 6374 MPLS Loss and Delay Measurement September 2011

 the Control Code in the response MUST NOT be set to 0x1 (Success).
 Unless an error condition has occurred, the Control Code MUST be set
 to 0x2 (Notification - Data Format Invalid).
 Upon receiving a DM Response, the querier knows from the RTF field in
 the message whether the responder is capable of supporting its
 preferred timestamp format: if it is, the RTF will be equal to the
 QTF.  The querier also knows the responder's preferred timestamp
 format from the RPTF field.  The querier can then decide whether to
 retain its current QTF or to change it and repeat the negotiation
 procedures.

4.3.5.1. Single-Format Procedures

 When an implementation supports only one timestamp format, the
 procedures above reduce to the following simple behavior:
 o  All DM Queries are transmitted with the same QTF;
 o  All DM Responses are transmitted with the same RTF, and the RPTF
    is always set equal to the RTF;
 o  All DM Responses received with RTF not equal to QTF are discarded;
 o  On a unidirectional channel, all DM Queries received with QTF not
    equal to the supported format are discarded.

4.3.6. Quality of Service

 The TC field of the LSE corresponding to the channel (e.g., LSP)
 being measured MUST be set to the value that corresponds to the DS
 field in the DM message.

4.4. Combined Loss/Delay Measurement Procedures

 The combined LM/DM message defined in Section 3.3 allows loss and
 delay measurement to be carried out simultaneously.  This message
 SHOULD be treated as an LM message that happens to carry additional
 timestamp data, with the timestamp fields processed as per delay
 measurement procedures.

5. Implementation Disclosure Requirements

 This section summarizes the requirements placed on implementations
 for capabilities disclosure.  The purpose of these requirements is to
 ensure that end users have a clear understanding of implementation

Frost & Bryant Standards Track [Page 42] RFC 6374 MPLS Loss and Delay Measurement September 2011

 capabilities and characteristics that have a direct impact on how
 loss and delay measurement mechanisms function in specific
 situations.  Implementations are REQUIRED to state:
 o  METRICS: Which of the following metrics are supported: packet
    loss, packet throughput, octet loss, octet throughput, average
    loss rate, one-way delay, round-trip delay, two-way channel delay,
    packet delay variation.
 o  MP-LOCATION: The location of loss and delay measurement points
    with respect to other stages of packet processing, such as
    queuing.
 o  CHANNEL-TYPES: The types of channels for which LM and DM are
    supported, including LSP types, pseudowires, and sections (links).
 o  QUERY-RATE: The minimum supported query intervals for LM and DM
    sessions, both in the querier and responder roles.
 o  LOOP: Whether loopback measurement (Section 2.8) is supported.
 o  LM-TYPES: Whether direct or inferred LM is supported, and for the
    latter, which test protocols or proxy message types are supported.
 o  LM-COUNTERS: Whether 64-bit counters are supported.
 o  LM-ACCURACY: The expected measurement accuracy levels for the
    supported forms of LM, and the expected impact of exception
    conditions such as lost and misordered messages.
 o  LM-SYNC: The implementation's behavior in regard to the
    synchronization conditions discussed in Section 2.9.8.
 o  LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
 o  DM-ACCURACY: The expected measurement accuracy levels for the
    supported forms of DM.
 o  DM-TS-FORMATS: The supported timestamp formats and the extent of
    support for computation with and reconciliation of different
    formats.

Frost & Bryant Standards Track [Page 43] RFC 6374 MPLS Loss and Delay Measurement September 2011

6. Congestion Considerations

 An MPLS network may be traffic-engineered in such a way that the
 bandwidth required both for client traffic and for control,
 management, and OAM traffic is always available.  The following
 congestion considerations therefore apply only when this is not the
 case.
 The proactive generation of Loss Measurement and Delay Measurement
 messages for purposes of monitoring the performance of an MPLS
 channel naturally results in a degree of additional load placed on
 both the network and the terminal nodes of the channel.  When
 configuring such monitoring, operators should be mindful of the
 overhead involved and should choose transmit rates that do not stress
 network resources unduly; such choices must be informed by the
 deployment context.  In case of slower links or lower-speed devices,
 for example, lower Loss Measurement message rates can be chosen, up
 to the limits noted at the end of Section 2.2.
 In general, lower measurement message rates place less load on the
 network at the expense of reduced granularity.  For delay
 measurement, this reduced granularity translates to a greater
 possibility that the delay associated with a channel temporarily
 exceeds the expected threshold without detection.  For loss
 measurement, it translates to a larger gap in loss information in
 case of exceptional circumstances such as lost LM messages or
 misordered packets.
 When carrying out a sustained measurement operation such as an LM
 operation or continuous proactive DM operation, the querier SHOULD
 take note of the number of lost measurement messages (queries for
 which a response is never received) and set a corresponding
 Measurement Message Loss Threshold.  If this threshold is exceeded,
 the measurement operation SHOULD be suspended so as not to exacerbate
 the possible congestion condition.  This suspension SHOULD be
 accompanied by an appropriate notification to the user so that the
 condition can be investigated and corrected.
 From the receiver perspective, the main consideration is the
 possibility of receiving an excessive quantity of measurement
 messages.  An implementation SHOULD employ a mechanism such as rate-
 limiting to guard against the effects of this case.

7. Manageability Considerations

 The measurement protocols described in this document are intended to
 serve as infrastructure to support a wide range of higher-level
 monitoring and diagnostic applications, from simple command-line

Frost & Bryant Standards Track [Page 44] RFC 6374 MPLS Loss and Delay Measurement September 2011

 diagnostic tools to comprehensive network performance monitoring and
 analysis packages.  The specific mechanisms and considerations for
 protocol configuration, initialization, and reporting thus depend on
 the nature of the application.
 In the case of on-demand diagnostics, the diagnostic application may
 provide parameters such as the measurement type, the channel, the
 query rate, and the test duration when initiating the diagnostic;
 results and exception conditions are then reported directly to the
 application.  The system may discard the statistics accumulated
 during the test after the results have been reported or retain them
 to provide a historical measurement record.
 Alternatively, measurement configuration may be supplied as part of
 the channel configuration itself in order to support continuous
 monitoring of the channel's performance characteristics.  In this
 case, the configuration will typically include quality thresholds
 depending on the service level agreement, the crossing of which will
 trigger warnings or alarms, and result reporting and exception
 notification will be integrated into the system-wide network
 management and reporting framework.

8. Security Considerations

 This document describes procedures for the measurement of performance
 metrics over a pre-existing MPLS path (a pseudowire, LSP, or
 section).  As such, it assumes that a node involved in a measurement
 operation has previously verified the integrity of the path and the
 identity of the far end using existing MPLS mechanisms such as
 Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
 techniques, and considerations for securing MPLS paths are discussed
 in detail in [RFC5920].
 When such mechanisms are not available, and where security of the
 measurement operation is a concern, reception of Generic Associated
 Channel messages with the Channel Types specified in this document
 SHOULD be disabled.  Implementations MUST provide the ability to
 disable these protocols on a per-Channel-Type basis.
 Even when the identity of the far end has been verified, the
 measurement protocols remain vulnerable to injection and man-in-the-
 middle attacks.  The impact of such an attack would be to compromise
 the quality of performance measurements on the affected path.  An
 attacker positioned to disrupt these measurements is, however,
 capable of causing much greater damage by disrupting far more
 critical elements of the network such as the network control plane or
 user traffic flows.  At worst, a disruption of the measurement
 protocols would interfere with the monitoring of the performance

Frost & Bryant Standards Track [Page 45] RFC 6374 MPLS Loss and Delay Measurement September 2011

 aspects of the service level agreement associated with the path; the
 existence of such a disruption would imply that a serious breach of
 basic path integrity had already occurred.
 If desired, such attacks can be mitigated by performing basic
 validation and sanity checks, at the querier, of the counter or
 timestamp fields in received measurement response messages.  The
 minimal state associated with these protocols also limits the extent
 of measurement disruption that can be caused by a corrupt or invalid
 message to a single query/response cycle.
 Cryptographic mechanisms capable of signing or encrypting the
 contents of the measurement packets without degrading the measurement
 performance are not currently available.  In light of the preceding
 discussion, the absence of such cryptographic mechanisms does not
 raise significant security issues.
 Users concerned with the security of out-of-band responses over IP
 networks SHOULD employ suitable security mechanisms such as IPsec
 [RFC4301] to protect the integrity of the return path.

9. IANA Considerations

 Per this document, IANA has completed the following actions:
 o  Allocation of Channel Types in the "PW Associated Channel Type"
    registry
 o  Creation of a "Measurement Timestamp Type" registry
 o  Creation of an "MPLS Loss/Delay Measurement Control Code" registry
 o  Creation of an "MPLS Loss/Delay Measurement Type-Length-Value
    (TLV) Object" registry

Frost & Bryant Standards Track [Page 46] RFC 6374 MPLS Loss and Delay Measurement September 2011

9.1. Allocation of PW Associated Channel Types

 As per the IANA considerations in [RFC5586], IANA has allocated the
 following Channel Types in the "PW Associated Channel Type" registry:
 Value  Description                              TLV Follows Reference
 ------ ---------------------------------------- ----------- ---------
 0x000A MPLS Direct Loss Measurement (DLM)       No          RFC 6374
 0x000B MPLS Inferred Loss Measurement (ILM)     No          RFC 6374
 0x000C MPLS Delay Measurement (DM)              No          RFC 6374
 0x000D MPLS Direct Loss and Delay Measurement   No          RFC 6374
        (DLM+DM)
 0x000E MPLS Inferred Loss and Delay Measurement No          RFC 6374
        (ILM+DM)

9.2. Creation of Measurement Timestamp Type Registry

 IANA has created a new "Measurement Timestamp Type" registry, with
 format and initial allocations as follows:
 Type Description                               Size in Bits Reference
 ---- ----------------------------------------- ------------ ---------
 0    Null Timestamp                            64           RFC 6374
 1    Sequence Number                           64           RFC 6374
 2    Network Time Protocol version 4 64-bit    64           RFC 6374
      Timestamp
 3    Truncated IEEE 1588v2 PTP Timestamp       64           RFC 6374
 The range of the Type field is 0-15.
 The allocation policy for this registry is IETF Review.

9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry

 IANA has created a new "MPLS Loss/Delay Measurement Control Code"
 registry.  This registry is divided into two separate parts, one for
 Query Codes and the other for Response Codes, with formats and
 initial allocations as follows:
 Query Codes
 Code Description                    Reference
 ---- ------------------------------ ---------
 0x0  In-band Response Requested     RFC 6374
 0x1  Out-of-band Response Requested RFC 6374
 0x2  No Response Requested          RFC 6374

Frost & Bryant Standards Track [Page 47] RFC 6374 MPLS Loss and Delay Measurement September 2011

 Response Codes
 Code Description                         Reference
 ---- ----------------------------------- ---------
 0x0  Reserved                            RFC 6374
 0x1  Success                             RFC 6374
 0x2  Data Format Invalid                 RFC 6374
 0x3  Initialization in Progress          RFC 6374
 0x4  Data Reset Occurred                 RFC 6374
 0x5  Resource Temporarily Unavailable    RFC 6374
 0x10 Unspecified Error                   RFC 6374
 0x11 Unsupported Version                 RFC 6374
 0x12 Unsupported Control Code            RFC 6374
 0x13 Unsupported Data Format             RFC 6374
 0x14 Authentication Failure              RFC 6374
 0x15 Invalid Destination Node Identifier RFC 6374
 0x16 Connection Mismatch                 RFC 6374
 0x17 Unsupported Mandatory TLV Object    RFC 6374
 0x18 Unsupported Query Interval          RFC 6374
 0x19 Administrative Block                RFC 6374
 0x1A Resource Unavailable                RFC 6374
 0x1B Resource Released                   RFC 6374
 0x1C Invalid Message                     RFC 6374
 0x1D Protocol Error                      RFC 6374
 IANA has indicated that the values 0x0 - 0xF in the Response Code
 section are reserved for non-error response codes.
 The range of the Code field is 0 - 255.
 The allocation policy for this registry is IETF Review.

Frost & Bryant Standards Track [Page 48] RFC 6374 MPLS Loss and Delay Measurement September 2011

9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry

 IANA has created a new "MPLS Loss/Delay Measurement TLV Object"
 registry, with format and initial allocations as follows:
 Type Description                       Reference
 ---- --------------------------------- ---------
 0    Padding - copy in response        RFC 6374
 1    Return Address                    RFC 6374
 2    Session Query Interval            RFC 6374
 3    Loopback Request                  RFC 6374
 127  Experimental use                  RFC 6374
 128  Padding - do not copy in response RFC 6374
 129  Destination Address               RFC 6374
 130  Source Address                    RFC 6374
 255  Experimental use                  RFC 6374
 IANA has indicated that Types 0-127 are classified as Mandatory, and
 that Types 128-255 are classified as Optional.
 The range of the Type field is 0 - 255.
 The allocation policy for this registry is IETF Review.

10. Acknowledgments

 The authors wish to thank the many participants of the MPLS working
 group who provided detailed review and feedback on this document.
 The authors offer special thanks to Alexander Vainshtein, Loa
 Andersson, and Hiroyuki Takagi for many helpful thoughts and
 discussions, to Linda Dunbar for the idea of using LM messages for
 throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and
 Ben Mack-Crane for their valuable comments.

11. References

11.1. Normative References

 [IEEE1588]  IEEE, "1588-2008 IEEE Standard for a Precision Clock
             Synchronization Protocol for Networked Measurement and
             Control Systems", March 2008.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

Frost & Bryant Standards Track [Page 49] RFC 6374 MPLS Loss and Delay Measurement September 2011

 [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black,
             "Definition of the Differentiated Services Field (DS
             Field) in the IPv4 and IPv6 Headers", RFC 2474,
             December 1998.
 [RFC3031]   Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
             Label Switching Architecture", RFC 3031, January 2001.
 [RFC3270]   Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
             P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
             Protocol Label Switching (MPLS) Support of Differentiated
             Services", RFC 3270, May 2002.
 [RFC5462]   Andersson, L. and R. Asati, "Multiprotocol Label
             Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
             to "Traffic Class" Field", RFC 5462, February 2009.
 [RFC5586]   Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
             Associated Channel", RFC 5586, June 2009.
 [RFC5905]   Mills, D., Martin, J., Burbank, J., and W. Kasch,
             "Network Time Protocol Version 4: Protocol and Algorithms
             Specification", RFC 5905, June 2010.

11.2. Informative References

 [RFC2679]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
             Delay Metric for IPPM", RFC 2679, September 1999.
 [RFC2680]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
             Packet Loss Metric for IPPM", RFC 2680, September 1999.
 [RFC2681]   Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
             Delay Metric for IPPM", RFC 2681, September 1999.
 [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.
 [RFC3260]   Grossman, D., "New Terminology and Clarifications for
             Diffserv", RFC 3260, April 2002.
 [RFC3985]   Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
             Edge (PWE3) Architecture", RFC 3985, March 2005.
 [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005.

Frost & Bryant Standards Track [Page 50] RFC 6374 MPLS Loss and Delay Measurement September 2011

 [RFC4656]   Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
             Zekauskas, "A One-way Active Measurement Protocol
             (OWAMP)", RFC 4656, September 2006.
 [RFC4928]   Swallow, G., Bryant, S., and L. Andersson, "Avoiding
             Equal Cost Multipath Treatment in MPLS Networks",
             BCP 128, RFC 4928, June 2007.
 [RFC5036]   Andersson, L., Minei, I., and B. Thomas, "LDP
             Specification", RFC 5036, October 2007.
 [RFC5357]   Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
             Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
             RFC 5357, October 2008.
 [RFC5481]   Morton, A. and B. Claise, "Packet Delay Variation
             Applicability Statement", RFC 5481, March 2009.
 [RFC5884]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
             "Bidirectional Forwarding Detection (BFD) for MPLS Label
             Switched Paths (LSPs)", RFC 5884, June 2010.
 [RFC5920]   Fang, L., "Security Framework for MPLS and GMPLS
             Networks", RFC 5920, July 2010.
 [RFC5921]   Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
             Berger, "A Framework for MPLS in Transport Networks",
             RFC 5921, July 2010.
 [RFC5960]   Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
             Profile Data Plane Architecture", RFC 5960, August 2010.
 [RFC6375]   Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
             Delay Measurement Profile for MPLS-Based Transport
             Networks", RFC 6375, September 2011.
 [Y.1731]    ITU-T Recommendation Y.1731, "OAM Functions and
             Mechanisms for Ethernet based Networks", February 2008.

Frost & Bryant Standards Track [Page 51] RFC 6374 MPLS Loss and Delay Measurement September 2011

Appendix A. Default Timestamp Format Rationale

 This document initially proposed the Network Time Protocol (NTP)
 timestamp format as the mandatory default, as this is the normal
 default timestamp in IETF protocols and thus would seem the "natural"
 choice.  However, a number of considerations have led instead to the
 specification of the truncated IEEE 1588 Precision Time Protocol
 (PTP) timestamp as the default.  NTP has not gained traction in
 industry as the protocol of choice for high-quality timing
 infrastructure, whilst IEEE 1588 PTP has become the de facto time
 transfer protocol in networks that are specially engineered to
 provide high-accuracy time distribution service.  The PTP timestamp
 format is also the ITU-T format of choice for packet transport
 networks, which may rely on MPLS protocols.  Applications such as
 one-way delay measurement need the best time service available, and
 converting between the NTP and PTP timestamp formats is not a trivial
 transformation, particularly when it is required that this be done in
 real time without loss of accuracy.
 The truncated IEEE 1588 PTP format specified in this document is
 considered to provide a more than adequate wrap time and greater time
 resolution than it is expected will be needed for the operational
 lifetime of this protocol.  By truncating the timestamp at both the
 high and low order bits, the protocol achieves a worthwhile reduction
 in system resources.

Authors' Addresses

 Dan Frost
 Cisco Systems
 EMail: danfrost@cisco.com
 Stewart Bryant
 Cisco Systems
 EMail: stbryant@cisco.com

Frost & Bryant Standards Track [Page 52]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6374.txt · Last modified: 2011/09/18 17:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki