tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6374

 Errata 
Proposed STD
Pages: 52
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

Packet Loss and Delay Measurement for MPLS Networks

Part 1 of 3, p. 1 to 19
None       Next RFC Part

Updated by:    7214


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part