Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6374

Packet Loss and Delay Measurement for MPLS Networks

Pages: 52
Proposed Standard
Errata
Updated by:  7214
Part 1 of 3 – Pages 1 to 19
None   None   Next

Top   ToC   RFC6374 - Page 1
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.
Top   ToC   RFC6374 - Page 2

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
Top   ToC   RFC6374 - Page 3
           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.
Top   ToC   RFC6374 - Page 4
   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.
Top   ToC   RFC6374 - Page 5
      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.
Top   ToC   RFC6374 - Page 6

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.
Top   ToC   RFC6374 - Page 7
   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.
Top   ToC   RFC6374 - Page 8
   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.)
Top   ToC   RFC6374 - Page 9
   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).
Top   ToC   RFC6374 - Page 10
   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
Top   ToC   RFC6374 - Page 11
   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.
Top   ToC   RFC6374 - Page 12
   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])
Top   ToC   RFC6374 - Page 13
   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])
Top   ToC   RFC6374 - Page 14
   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-
Top   ToC   RFC6374 - Page 15
   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.
Top   ToC   RFC6374 - Page 16

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".
Top   ToC   RFC6374 - Page 17
   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.
Top   ToC   RFC6374 - Page 18
   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.
Top   ToC   RFC6374 - Page 19
   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.



(page 19 continued on part 2)

Next Section