One document matched: draft-ietf-mpls-loss-delay-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-loss-delay-02"
ipr="trust200902">
<front>
<title abbrev="MPLS Loss and Delay Measurement">Packet Loss and Delay
Measurement for MPLS Networks</title>
<author fullname="Dan Frost" initials="D" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<email>danfrost@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<date year="2011" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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 evaluation. This document specifies protocol
mechanisms to enable the efficient and accurate measurement of these
performance metrics in MPLS networks.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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 evaluation. This document specifies protocol
mechanisms to enable the efficient and accurate measurement of these
performance metrics in MPLS networks.</t>
<t>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:
<list style="symbols">
<t>The LM and DM protocols are intended to be simple and to support
efficient hardware processing.</t>
<t>The LM and DM protocols operate over the MPLS Generic Associated
Channel (G-ACh) <xref target="RFC5586" /> and support measurement of
loss, delay, and related metrics over Label Switched Paths (LSPs),
pseudowires, and MPLS sections (links).</t>
<t>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 <xref
target="RFC5921" />, and MPLS-TP LSPs, pseudowires, and sections are
discussed in detail in <xref target="RFC5960" />.</t>
<t>The LM and DM protocols can be used for both continuous/proactive
and selective/on-demand measurement.</t>
<t>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.</t>
<t>The LM and DM protocols use query messages for unidirectional
loss and delay measurement. The measurement can either be carried
out at the downstream node(s) or at the querier if an out-of-band
return path is available.</t>
<t>The LM and DM protocols do not require that the transmit and
receive interfaces be the same when performing bidirectional
measurement.</t>
<t>The DM protocol is stateless.</t>
<t>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.</t>
<t>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.
<vspace blankLines="1" />
The direct LM method is also known as "frame-based" in the context
of Ethernet transport networks <xref target="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.
</t>
<t>The LM protocol supports measurement in terms of both packet
counts and octet counts.</t>
<t>The LM protocol supports both 32-bit and 64-bit counters.</t>
<t>The LM protocol can be used to measure channel throughput as well
as packet loss.</t>
<t>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.</t>
<t>The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes.</t>
</list>
</t>
<section title="Applicability and Scope">
<t>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.</t>
<t>Although the procedures in this document are presented in the
context of MPLS, they have no essential dependence on MPLS and
generalize easily to other types of packet networks. Such
generalizations are, however, outside the scope of this document.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>ACH</c>
<c>Associated Channel Header</c>
<c>DM</c>
<c>Delay Measurement</c>
<c>ECMP</c>
<c>Equal Cost Multipath</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>LM</c>
<c>Loss Measurement</c>
<c>LSE</c>
<c>Label Stack Entry</c>
<c>LSP</c>
<c>Label Switched Path</c>
<c>NTP</c>
<c>Network Time Protocol</c>
<c>OAM</c>
<c>Operations, Administration, and Maintenance</c>
<c>PTP</c>
<c>Precision Time Protocol</c>
<c>TC</c>
<c>Traffic Class</c>
</texttable>
</section>
</section>
<section title="Overview" anchor="ov">
<t>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 are 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 <xref
target="pf" /> and <xref target="op" />.</t>
<section title="Basic Bidirectional Measurement">
<t>The following figure shows the reference scenario.</t>
<figure align="center" anchor="ov_fig">
<artwork><![CDATA[
T1 T2
+-------+/ Query \+-------+
| | - - - - - - - - ->| |
| A |===================| B |
| |<- - - - - - - - - | |
+-------+\ Response /+-------+
T4 T3
]]></artwork>
</figure>
<t>The 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. Each
reference point indicates the point in time at which either the query
or the response message is transmitted or received over the
channel.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="ov_loss" title="Packet Loss Measurement">
<t>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: <list style="empty">
<t>A_TxLoss (transmit loss): the number of packets transmitted by
A over the channel but not received at B;</t>
<t>A_RxLoss (receive loss): the number of packets transmitted by B
over the channel but not received at A.</t>
</list></t>
<t>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: <list style="empty">
<t>A_TxP[n]: the total count of packets transmitted by A over the
channel prior to the time this message is transmitted.</t>
</list></t>
<t>When such a message is received at B, the following value is
recorded in the message: <list style="empty">
<t>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).</t>
</list></t>
<t>At this point, B transmits the message back to A, recording within
it the following value: <list style="empty">
<t>B_TxP[n]: the total count of packets transmitted by B over the
channel prior to the time this response is transmitted.</t>
</list></t>
<t>When the message response is received back at A, the following
value is recorded in the message: <list style="empty">
<t>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).</t>
</list></t>
<t>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:</t>
<t>A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
<vspace /> A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] -
A_RxP[n-1])</t>
<t>where the arithmetic is modulo the counter size.</t>
<t>(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.)</t>
<t>The derived values <list style="empty">
<t>A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...</t>
<t>A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...</t>
</list> are updated each time a response to an LM message is
received and processed, and represent the total transmit and receive
loss over the channel since the LM operation was initiated.</t>
<t>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. Consider for
example 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.</t>
<t>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.</t>
<t>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
proportionately.</t>
<t>In addition to absolute aggregate loss counts, the individual loss
counts yield additional 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
(<xref target="lm_anom" />).</t>
</section>
<section title="Throughput Measurement">
<t>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. Just as for loss measurement,
the interval counts can be accumulated to arrive at the throughput of
the channel since the start of the measurement operation, or used to
derive related metrics such as the average throughput rate. This
procedure also enables out-of-service throughput testing when combined
with a simple packet generator.</t>
</section>
<section anchor="ov_delay" title="Delay Measurement">
<t>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: <list style="symbols">
<t>The one-way delay associated with the forward (A to B)
direction of the channel;</t>
<t>The one-way delay associated with the reverse (B to A)
direction of the channel;</t>
<t>The two-way delay (A to B to A) associated with the
channel.</t>
</list></t>
<t>The one-way delay metric for packet networks is described in <xref
target="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 endpoint B. The "round-trip delay" is described in <xref
target="RFC2681" /> and includes in addition any delay associated with
remote endpoint processing.</t>
<t>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).</t>
<t>A measurement is accomplished by sending a Delay Measurement (DM)
query message over the channel to B which contains the following
timestamp: <list style="empty">
<t>T1: the time the DM query message is transmitted from A.</t>
</list></t>
<t>When the message arrives at B, the following timestamp is recorded
in the message: <list style="empty">
<t>T2: the time the DM query message is received at B.</t>
</list></t>
<t>At this point B transmits the message back to A, recording within
it the following timestamp: <list style="empty">
<t>T3: the time the DM response message is transmitted from B.</t>
</list></t>
<t>When the message arrives back at A, the following timestamp is
recorded in the message: <list style="empty">
<t>T4: the time the DM response message is received back at A.</t>
</list></t>
<t>(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.)</t>
<t>At this point, A can compute the two-way channel delay
associated with the channel as
<list style="empty">
<t>two-way channel delay = (T4 - T1) - (T3 - T2)</t>
</list>
and the round-trip delay as
<list style="empty">
<t>round-trip delay = T4 - T1.</t>
</list>
</t>
<t>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
<list style="empty">
<t>forward one-way delay = T2 - T1</t>
<t>reverse one-way delay = T4 - T3</t>
<t>two-way channel delay = forward delay + reverse delay.</t>
</list>
</t>
</section>
<section title="Delay Variation Measurement">
<t>Packet Delay Variation (PDV) <xref target="RFC3393" /> is another
performance metric important in some applications. The PDV of a pair
of packets within a stream of packets is defined for a selected pair
of packets in the stream going from measurement point 1 to measurement
point 2. The PDV is the difference between the one-way delay of the
selected packets.</t>
<t>A PDV measurement can therefore be derived from successive delay
measurements obtained through the procedures in <xref
target="ov_delay" />. An important point regarding PDV 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.</t>
</section>
<section title="Unidirectional Measurement">
<t>In the case that the channel from A to (B1, ..., Bk) is
unidirectional, i.e. is a unidirectional LSP, LM and DM
measurements can be carried out at B1, ..., Bk instead of at A.</t>
<t>For LM this is accomplished by initiating an LM operation at A and
carrying out the same procedures as 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,
i.e.</t>
<t>B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] -
B_RxP[n-1])</t>
<t>For DM, of course, only the forward one-way delay can be measured
and the clock synchronization requirement applies.</t>
<t>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.</t>
</section>
<section title="Dyadic Measurement">
<t>The basic procedures for bidirectional measurement assume that the
measurement process is conducted by and for the querier node A. It is
possible instead, 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.</t>
<t>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 attempt to specify a dyadic
operational mode. It is however 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.</t>
</section>
<section title="Loopback Measurement" anchor="loop">
<t>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.</t>
<t>For LM, the loss computation in this case is:</t>
<t>A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])</t>
<t>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.</t>
</section>
<section title="Measurement Considerations">
<t>A number of additional considerations apply in practice to the
measurement methods summarized above.</t>
<section title="Types of Channels">
<t>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 <xref
target="RFC5586" />.</t>
<t>Broadly, a channel in an MPLS network may be either a link, a
Label Switched Path (LSP) <xref target="RFC3031" />, or a pseudowire
<xref target="RFC3985" />. Links are bidirectional and are also
referred to as MPLS sections; see <xref target="RFC5586" /> and
<xref target="RFC5960" />. Pseudowires are bidirectional. Label
Switched Paths may be either unidirectional or bidirectional.</t>
<t>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.</t>
</section>
<section title="Quality of Service">
<t>Quality of Service (QoS) capabilities, in the form of the
Differentiated Services architecture, apply to MPLS as specified in
<xref target="RFC3270" /> and <xref target="RFC5462" />. Different
classes of traffic are distinguished by the three-bit Traffic Class
(TC) field of an MPLS Label Stack Entry (LSE). Delay measurement
therefore 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.</t>
</section>
<section title="Measurement Point Location">
<t>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-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.</t>
</section>
<section title="Equal Cost Multipath">
<t>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 <xref
target="RFC4928" />. The typical result of ECMP being performed on
an LSP which is subject to delay measurement will be that only the
delay of one of the available paths is and can be measured.</t>
<t>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.</t>
</section>
<section title="Intermediate Nodes">
<t>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. Often the motivation for
conducting measurements to intermediate nodes is 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.</t>
</section>
<section title="Different Transmit and Receive Interfaces">
<t>The overview of the bidirectional measurement process presented
in <xref target="ov" /> 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:
<list style="symbols">
<t>If different clocks are associated with transmit and receive
processing, these clocks must be synchronized in order to
compute the two-way delay.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="External Post-Processing" anchor="extpp">
<t>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.</t>
<t>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.</t>
</section>
<section title="Loss Measurement Modes" anchor="lm_modes">
<t>The summary of loss measurement at the beginning of <xref
target="ov" /> above 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".</t>
<t>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.</t>
<t>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.</t>
<t>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) <xref
target="RFC5036" /> as opposed to, for example, those based on
Traffic Engineering extensions to the Resource Reservation Protocol
(RSVP-TE) <xref target="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.</t>
<t>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) <xref target="RFC5884" /> session.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Loss Measurement Scope" anchor="lm_scope">
<t>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.</t>
</section>
<section title="Delay Measurement Accuracy">
<t>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 main difference in the two cases is one of measurement accuracy.
Implementations MUST make their delay measurement accuracy levels
clear to the user.</t>
</section>
<section title="Delay Measurement Timestamp Format">
<t>There are two significant timestamp formats in common use: the
timestamp format of the Internet standard Network Time Protocol
(NTP), described in <xref target="RFC5905" />, and the timestamp
format used in the IEEE 1588 Precision Time Protocol (PTP) <xref
target="IEEE1588" />.</t>
<t>The NTP format has the advantages of wide use and long deployment
in the Internet, and was specifically designed to make the
computation of timestamp differences as simple and efficient as
possible. On the other hand, there is also now a significant
deployment of equipment designed to support the PTP format.</t>
<t>The approach taken in this document is therefore to include in DM
messages fields which 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. Timestamp format support requirements are specified in
<xref target="pf_tsf" />.</t>
</section>
</section>
</section>
<section title="Message Formats" anchor="pf">
<t>Loss Measurement and Delay Measurement messages flow over the MPLS
Generic Associated Channel (G-ACh) <xref target="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.</t>
<t>This document defines the following ACH Channel Types:
<list style="empty">
<t>MPLS Direct Packet Loss Measurement (DLM) <vspace />
MPLS Inferred Packet Loss Measurement (ILM) <vspace />
MPLS Packet Delay Measurement (DM) <vspace />
MPLS Direct Packet Loss and Delay Measurement (DLM+DM) <vspace />
MPLS Inferred Packet Loss and Delay Measurement (ILM+DM)</t>
</list>
</t>
<t>The message formats for direct and inferred LM are identical, as are
the formats for the DLM+DM and ILM+DM messages.</t>
<t>For these channel types, the ACH SHALL NOT be followed by the ACH TLV
Header defined in <xref target="RFC5586" />.</t>
<t>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.</t>
<t>All integer values for fields defined in this document SHALL be
encoded in network byte order.</t>
<section anchor="pf_lm" title="Loss Measurement Message Format">
<t>The format of a Loss Measurement message, which follows the
Associated Channel Header (ACH), is as follows:</t>
<figure anchor="pf_lm_f" title="Loss Measurement Message Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows.</t>
<texttable align="left" style="headers">
<ttcol width="30%">Field</ttcol>
<ttcol>Meaning</ttcol>
<c>Version</c>
<c>Protocol version</c>
<c>Flags</c>
<c>Message control flags</c>
<c>Control Code</c>
<c>Code identifying the query or response type</c>
<c>Message Length</c>
<c>Total length of this message in bytes</c>
<c>Data Format Flags (DFlags)</c>
<c>Flags specifying the format of message data</c>
<c>Origin Timestamp Format (OTF)</c>
<c>Format of the Origin Timestamp field</c>
<c>Reserved</c>
<c>Reserved for future specification</c>
<c>Session Identifier</c>
<c>Set arbitrarily by the querier</c>
<c>Differentiated Services (DS) Field</c>
<c>Differentiated Services Code Point (DSCP) being measured</c>
<c> </c><c> </c>
<c>Origin Timestamp</c>
<c>Query message transmission timestamp</c>
<c>Counter 1-4</c>
<c>LM counter values</c>
<c>TLV Block</c>
<c>Optional block of Type-Length-Value fields</c>
</texttable>
<t>The possible values for these fields are as follows.</t>
<t>Version: Currently set to 0.</t>
<t>Flags: The format of the Flags field is shown below.</t>
<figure title="Loss Measurement Message Flags">
<artwork><![CDATA[
+-+-+-+-+
|R|T|0|0|
+-+-+-+-+
]]></artwork>
</figure>
<t>The meanings of the flag bits are:
<list style="empty">
<t>R: Query/Response indicator. Set to 0 for a Query and 1 for a
Response.</t>
<t>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.</t>
<t>0: Set to 0.</t>
</list></t>
<t>Control Code: Set as follows according to whether the message is a
Query or a Response as identified by the R flag. <list style="empty">
<t>For a Query:
<list style="empty">
<t>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.</t>
<t>0x1: Out-of-band Response Requested. Indicates that
the response should be sent via an out-of-band channel.</t>
<t>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.</t>
</list></t>
<t>For a Response:
<list style="empty">
<t>Codes 0x0-0xF are reserved for non-error responses.</t>
<t>0x1: Success. Indicates that the operation was
successful.</t>
<t>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.</t>
<t>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.</t>
<t>0x4: Notification - Data Reset Occurred. Indicates that
the query was processed but a reset has recently occurred
which may render the data in this response inconsistent
relative to earlier responses.</t>
<t>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.</t>
<t>0x10: Error - Unspecified Error. Indicates that the
operation failed for an unspecified reason.</t>
<t>0x11: Error - Unsupported Version. Indicates that the
operation failed because the protocol version supplied in the
query message is not supported.</t>
<t>0x12: Error - Unsupported Control Code. Indicates that the
operation failed because the Control Code requested an
operation that is not available for this channel.</t>
<t>0x13: Error - Unsupported Data Format. Indicates that the
operation failed because the data format specified in the
query is not supported.</t>
<t>0x14: Error - Authentication Failure. Indicates that the
operation failed because the authentication data supplied in
the query was missing or incorrect.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>0x18: Error - Unsupported Query Interval. Indicates that
the operation failed because the query message rate exceeded
the configured threshold.</t>
<t>0x19: Error - Administrative Block. Indicates that the
operation failed because it has been administratively
disallowed.</t>
<t>0x1A: Error - Resource Unavailable. Indicates that the
operation failed because node resources were not
available.</t>
<t>0x1B: Error - Resource Released. Indicates that the
operation failed because node resources for this measurement
session were administratively released.</t>
<t>0x1C: Error - Invalid Message. Indicates that the
operation failed because the received query message was
malformed.</t>
<t>0x1D: Error - Protocol Error. Indicates that the operation
failed because a protocol error was found in the received
query message.</t>
</list></t>
</list></t>
<t>Message Length: Set to the total length of this message in
bytes.</t>
<t>DFlags: The format of the DFlags field is shown below.</t>
<figure title="Loss Measurement Message Flags">
<artwork><![CDATA[
+-+-+-+-+
|X|B|0|0|
+-+-+-+-+
]]></artwork>
</figure>
<t>The meanings of the DFlags bits are:
<list style="empty">
<t>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.</t>
<t>B: Octet (byte) count. When set to 1, indicates that the
Counter 1-4 fields represent octet counts. When set to 0,
indicates that the Counter 1-4 fields represent packet counts.</t>
<t>0: Set to 0.</t>
</list></t>
<t>Origin Timestamp Format: The format of the Origin Timestamp field,
as specified in <xref target="pf_tsf" />.</t>
<t>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.</t>
<t>DS: When the T flag is set to 1, this field is set to the DSCP
value <xref target="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 <xref
target="RFC5462" />, this field SHOULD be set to the Class Selector
Codepoint <xref target="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.</t>
<t>Origin Timestamp: Timestamp recording the transmit time of the
query message.</t>
<t>Counter 1-4: Referring to <xref target="ov_loss" />, 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.</t>
<t>The mapping of counter types such as A_TxP to the counter fields
1-4 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.</t>
<t>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.</t>
<t>TLV Block: Zero or more TLV fields.</t>
</section>
<section anchor="pf_dm" title="Delay Measurement Message Format">
<t>The format of a Delay Measurement message, which follows the
Associated Channel Header (ACH), is as follows:</t>
<figure anchor="pf_dm_f" title="Delay Measurement Message Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<texttable align="left" style="headers">
<preamble>The meanings of the fields are summarized in the following
table.</preamble>
<ttcol width="30%">Field</ttcol>
<ttcol>Meaning</ttcol>
<c>Version</c>
<c>Protocol version</c>
<c>Flags</c>
<c>Message control flags</c>
<c>Control Code</c>
<c>Code identifying the query or response type</c>
<c>Message Length</c>
<c>Total length of this message in bytes</c>
<c>QTF</c>
<c>Querier timestamp format</c>
<c>RTF</c>
<c>Responder timestamp format</c>
<c>RPTF</c>
<c>Responder's preferred timestamp format</c>
<c>Reserved</c>
<c>Reserved for future specification</c>
<c>Session Identifier</c>
<c>Set arbitrarily by the querier</c>
<c>Differentiated Services (DS) Field</c>
<c>Differentiated Services Code Point (DSCP) being measured</c>
<c> </c><c> </c>
<c>Timestamp 1-4</c>
<c>64-bit timestamp values</c>
<c>TLV Block</c>
<c>Optional block of Type-Length-Value fields</c>
</texttable>
<t>Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows.</t>
<t>Version: Currently set to 0.</t>
<t>Flags: As specified in <xref target="pf_lm" />. The T flag in a DM
message is set to 1.</t>
<t>Control Code: As specified in <xref target="pf_lm" />.</t>
<t>Message Length: Set to the total length of this message in
bytes.</t>
<t>Querier Timestamp Format: The format of the timestamp values
written by the querier, as specified in <xref target="pf_tsf" />.</t>
<t>Responder Timestamp Format: The format of the timestamp values
written by the responder, as specified in <xref target="pf_tsf"
/>.</t>
<t>Responder's Preferred Timestamp Format: The timestamp format
preferred by the responder, as specified in <xref target="pf_tsf"
/>.</t>
<t>Session Identifier: As specified in <xref target="pf_lm" />.</t>
<t>DS: As specified in <xref target="pf_lm" />.</t>
<t>Timestamp 1-4: Referring to <xref target="ov_delay"></xref>, 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.</t>
<t>The mapping of timestamps to the timestamp fields 1-4 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.</t>
<t>TLV Block: Zero or more TLV fields.</t>
</section>
<section anchor="pf_lmdm" title="Combined Loss/Delay Measurement Message Format">
<t>The format of a combined Loss and Delay Measurement message, which
follows the Associated Channel Header (ACH), is as follows:</t>
<figure anchor="pf_lmdm_f" title="Loss/Delay Measurement Message Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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.</t>
</section>
<section anchor="pf_tsf" title="Timestamp Field Formats">
<t>The following timestamp format field values are specified in this
document: <list style="empty">
<t>0: Null timestamp format. This value is a placeholder
indicating that the timestamp field does not contain a meaningful
timestamp.</t>
<t>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.</t>
<t>2: Network Time Protocol version 4 64-bit timestamp format
<xref target="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.</t>
<t>3: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp
format <xref target="IEEE1588" />. This format consists of a
32-bit seconds field followed by a 32-bit nanoseconds field.</t>
</list></t>
<t>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.</t>
<t>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 IEEE 1588v1
PTP; this format MUST be supported. The rationale for this choice is
discussed in <xref target="ts_rationale" />. 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.</t>
<t>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.</t>
</section>
<section title="TLV Objects">
<t>The TLV Block in LM and DM messages consists of zero or more
objects with the following format:</t>
<figure title="TLV Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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.</t>
<t>The Type space is divided into Mandatory and Optional
subspaces:</t>
<texttable align="left" style="headers">
<ttcol width="20%">Type Range</ttcol>
<ttcol>Semantics</ttcol>
<c>0-127</c>
<c>Mandatory</c>
<c>128-255</c>
<c>Optional</c>
</texttable>
<t>Upon receipt of a query message including an unrecognized mandatory
TLV object, the recipient MUST respond with an Unsupported Mandatory
TLV Object error code.</t>
<texttable align="left" style="headers">
<preamble>The types defined are as follows:</preamble>
<ttcol width="20%">Type</ttcol>
<ttcol>Definition</ttcol>
<c>Mandatory</c>
<c></c>
<c>0</c>
<c>Padding - copy in response</c>
<c>1</c>
<c>Return Address</c>
<c>2</c>
<c>Session Query Interval</c>
<c>3</c>
<c>Loopback Request</c>
<c>4-119</c>
<c>Reserved</c>
<c>120-127</c>
<c>Implementation-specific usage</c>
<c> </c><c></c>
<c>Optional</c>
<c></c>
<c>128</c>
<c>Padding - do not copy in response</c>
<c>129</c>
<c>Destination Address</c>
<c>130</c>
<c>Source Address</c>
<c>131-247</c>
<c>Reserved</c>
<c>248-255</c>
<c>Implementation-specific usage</c>
</texttable>
<section title="Padding">
<t>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.</t>
<t>More than one padding object MAY be present, in which case they
SHOULD be continguous. Padding objects SHOULD occur at the end of
the TLV Block. The Value field of a padding object is
arbitrary.</t>
</section>
<section title="Addressing">
<t>The addressing objects have the following format:</t>
<figure title="Addressing Object Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Address Family field indicates the type of the address, and
SHALL be set to one of the assigned values in the IANA Address Family
Numbers registry.</t>
<t>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.</t>
</section>
<section title="Loopback Request">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Session Query Interval" anchor="sqi">
<t>The Value field of the Session Query Interval object is a 32-bit
unsigned integer that specifies a time interval in milliseconds:</t>
<figure title="Session Query Interval Object Format">
<artwork><![CDATA[
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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:
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
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.</t>
<t>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 <xref target="con_con" />
for further discussion.</t>
</section>
</section>
</section>
<section title="Operation" anchor="op">
<section title="Operational Overview">
<t>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.</t>
<t>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 may extend throughout the lifetime of the
channel.</t>
<t>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.</t>
<t>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 as the exception is, respectively, transient or
fatal. When the querier receives an Error response, the session MUST
be terminated and the user informed.</t>
<t>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 -
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.</t>
<t>When initiating a session the querier SHOULD employ the Session
Query Interval mechanism (<xref target="sqi" />) 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.</t>
</section>
<section title="Loss Measurement Procedures">
<section title="Initiating a Loss Measurement Operation">
<t>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 <xref target="ov_loss" />, 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 used to derive
related metrics such as the average loss rate.</t>
<t>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 <xref
target="ov_loss" /> cannot arise. The implementation SHOULD assume,
in evaluating this rate, 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.</t>
</section>
<section title="Transmitting a Loss Measurement Query">
<t>When transmitting an LM Query over a channel, 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.</t>
<t>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.</t>
<t>The Control Code field MUST be set to one of the values for Query
messages listed in <xref target="pf_lm" />; if the channel is
unidirectional, this field MUST NOT be set to 0x0 (Query: in-band
response requested).</t>
<t>The Session Identifier field can be set arbitrarily.</t>
<t>The Origin Timestamp field SHOULD 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 <xref
target="pf_tsf" />.</t>
<t>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.</t>
</section>
<section title="Receiving a Loss Measurement Query">
<t>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.</t>
<t>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.</t>
<t>In the case of a fatal exception that prevents the requested
measurement from being made, the error SHOULD be reported, either
via a response if one was requested or else as a notification to the
user.</t>
</section>
<section title="Transmitting a Loss Measurement Response">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The Control Code field MUST be set to one of the values for
Response messages listed in <xref target="pf_lm" />. The value 0x10
(Unspecified Error) SHOULD NOT be used if one of the other more
specific error codes is applicable.</t>
<t>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.</t>
</section>
<section title="Receiving a Loss Measurement Response">
<t>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
(<xref target="extpp" />) then these modifications MUST be
made.)</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Loss Calculation">
<t>Calculation of packet loss is carried out according to the
procedures in <xref target="ov_loss" />. 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 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.</t>
<t>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.</t>
</section>
<section title="Quality of Service">
<t>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.</t>
</section>
<section title="G-ACh Packets" anchor="lm_gach">
<t>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.</t>
</section>
<section title="Test Messages">
<t>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.</t>
<t>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 which 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.</t>
<t>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.</t>
</section>
<section title="Message Loss and Packet Misorder Conditions" anchor="lm_anom">
<t>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.</t>
<t>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 <xref target="ov_loss"
/>. 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>With regard to lost LM messages, the MaxLMInterval (see <xref
target="ov_loss" />) indicates the maximum amount of time that can
elapse before the LM state is discarded. If some messages are lost,
but a message is 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.</t>
<t>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.</t>
</section>
</section>
<section title="Delay Measurement Procedures">
<section title="Transmitting a Delay Measurement Query">
<t>When transmitting a DM Query over a channel, 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.</t>
<t>The Control Code field MUST be set to one of the values for Query
messages listed in <xref target="pf_lm"></xref>; if the channel
is unidirectional, this field MUST NOT be set to 0x0 (Query: in-band
response requested).</t>
<t>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 <xref
target="pf_tsf" />. The Responder Timestamp Format and Responder's
Preferred Timestamp Format fields MUST be set to 0.</t>
<t>The Session Identifier field can be set arbitrarily. The DS
field MUST be set to the traffic class being measured.</t>
<t>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.</t>
</section>
<section title="Receiving a Delay Measurement Query">
<t>Upon receipt of a DM Query message, the Timestamp 2 field SHOULD
be set to the time at which this DM Query is received.</t>
<t>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.</t>
<t>In the case of a fatal exception that prevents the requested
measurement from being made, the error SHOULD be reported, either
via a response if one was requested or else as a notification to the
user.</t>
</section>
<section title="Transmitting a Delay Measurement Response">
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="pf_tsf" />. Furthermore, the RTF field MUST be set equal
either to the QTF or the RPTF field. See <xref target="op_dm_tsfn"
/> for guidelines on selection of the value for this field.</t>
<t>The Responder's Preferred Timestamp Format (RPTF) field MUST be
set to one of the values listed in <xref target="pf_tsf" /> and
SHOULD be set to indicate the timestamp format with which the
responder can provide the best accuracy for purposes of delay
measurement.</t>
<t>The Control Code field MUST be set to one of the values for
Response messages listed in <xref target="pf_lm" />. The value 0x10
(Unspecified Error) SHOULD NOT be used if one of the other more
specific error codes is applicable.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Receiving a Delay Measurement Response">
<t>Upon in-band receipt of a DM Response message, the Timestamp 2
field is set to the time at which this DM Response is 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 (<xref target="extpp" />) then these
modifications MUST be made.)</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="op_dm_tsfn" title="Timestamp Format Negotiation">
<t>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.</t>
<t>Upon sending an initial DM Query over a channel, the querier
sets the Querier Timestamp Format (QTF) field to its preferred
timestamp format.</t>
<t>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.</t>
<t>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, 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).</t>
<t>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.</t>
<section title="Single-Format Procedures">
<t>When an implementation supports only one timestamp format, the
procedures above reduce to the following simple behavior:
<list style="symbols">
<t>All DM Queries are transmitted with the same QTF;</t>
<t>All DM Responses are transmitted with the same RTF, and the
RPTF is always set equal to the RTF;</t>
<t>All DM Responses received with RTF not equal to QTF are
discarded;</t>
<t>On a unidirectional channel, all DM Queries received
with QTF not equal to the supported format are discarded.</t>
</list>
</t>
</section>
</section>
<section title="Quality of Service">
<t>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.</t>
</section>
</section>
<section title="Combined Loss/Delay Measurement Procedures">
<t>The combined LM/DM message defined in <xref target="pf_lmdm" />
allows loss and delay measurement to be carried out simultaneously.
This message SHOULD be treated as an LM message which happens to carry
additional timestamp data, with the timestamp fields processed as per
delay measurement procedures.</t>
</section>
</section>
<section title="Implementation Disclosure Requirements">
<t>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
capabilities and characteristics that have a direct impact on how loss
and delay measurement mechanisms function in specific situations.
Implementations are REQUIRED to state:
<list style="symbols">
<t>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.</t>
<t>MP-LOCATION: The location of loss and delay measurement points
with respect to other stages of packet processing, such as
queuing.</t>
<t>CHANNEL-TYPES: The types of channels for which LM and DM are
supported, including LSP types, pseudowires, and sections
(links).</t>
<t>QUERY-RATE: The minimum supported query intervals for LM and DM
sessions, both in the querier and responder roles.</t>
<t>LOOP: Whether loopback measurement (<xref target="loop" />) is
supported.</t>
<t>LM-TYPES: Whether direct or inferred LM is supported, and for the
latter, which test protocols or proxy message types are
supported.</t>
<t>LM-COUNTERS: Whether 64-bit counters are supported.</t>
<t>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.</t>
<t>LM-SYNC: The implementation's behavior in regard to the
synchronization conditions discussed in <xref target="lm_modes"
/>.</t>
<t>LM-SCOPE: The supported LM scopes (<xref target="lm_scope" /> and
<xref target="lm_gach" />).</t>
<t>DM-ACCURACY: The expected measurement accuracy levels for the
supported forms of DM.</t>
<t>DM-TS-FORMATS: The supported timestamp formats and the extent of
support for computation with and reconciliation of different
formats.</t>
</list>
</t>
</section>
<section anchor="con_con" title="Congestion Considerations">
<t>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.</t>
<t>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 <xref target="ov_loss" />.</t>
<t>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.</t>
<t>When carrying out a sustained measurement operation such as an LM
operation or continuous pro-active 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.</t>
<t>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. Authentication procedures can
also be used to ensure that only queries from authorized devices are
processed.</t>
</section>
<section title="Security Considerations">
<t>There are three main types of security considerations associated with
the exchange of performance monitoring messages such as those described
in this document: the possibility of a malicious or misconfigured device
generating an excessive quantity of messages, causing service
impairment; the possibility of unauthorized alteration of messages in
transit; and the possibility of an unauthorized device learning the data
contained in or implied by such messages.</t>
<t>The first consideration is discussed in <xref target="con_con" />. If
reception or alteration of performance-related data by unauthorized
devices is an operational concern, authentication and/or encryption
procedures should be used to ensure message integrity and
confidentiality. Such procedures are outside the scope of this
document, but have general applicability to OAM protocols in MPLS
networks.</t>
</section>
<section title="IANA Considerations">
<t>This document makes the following requests of IANA:
<list style="symbols">
<t>Allocation of Channel Types in the PW Associated Channel Type
registry</t>
<t>Creation of a Measurement Timestamp Type registry</t>
<t>Creation of an MPLS Loss/Delay Measurement Control Code
registry</t>
<t>Creation of an MPLS Loss/Delay Measurement Type-Length-Value
(TLV) Object registry</t>
</list>
</t>
<section title="Allocation of PW Associated Channel Types">
<t>As per the IANA considerations in <xref target="RFC5586" />, IANA
is requested to allocate the following Channel Types in the PW
Associated Channel Type registry:</t>
<texttable align="left" style="headers">
<ttcol>Value</ttcol>
<ttcol width="10%">Description</ttcol>
<ttcol>TLV Follows</ttcol>
<ttcol>Reference</ttcol>
<c>TBD</c>
<c>MPLS Direct Packet Loss Measurement (DLM)</c>
<c>No</c>
<c>(this draft)</c>
<c>TBD</c>
<c>MPLS Inferred Packet Loss Measurement (ILM)</c>
<c>No</c>
<c>(this draft)</c>
<c>TBD</c>
<c>MPLS Packet Delay Measurement (DM)</c>
<c>No</c>
<c>(this draft)</c>
<c>TBD</c>
<c>MPLS Direct Packet Loss and Delay Measurement (DLM+DM)</c>
<c>No</c>
<c>(this draft)</c>
<c>TBD</c>
<c>MPLS Inferred Packet Loss and Delay Measurement (ILM+DM)</c>
<c>No</c>
<c>(this draft)</c>
</texttable>
<t>The values marked TBD are to be allocated by IANA as
appropriate.</t>
</section>
<section title="Creation of Measurement Timestamp Type Registry">
<t>IANA is requested to create a new Measurement Timestamp Type
registry, with format and initial allocations as follows:</t>
<texttable align="left" style="headers">
<ttcol>Type</ttcol>
<ttcol width="20%">Description</ttcol>
<ttcol>Size in bits</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>Null Timestamp</c>
<c>64</c>
<c>(this draft)</c>
<c>1</c>
<c>Sequence Number</c>
<c>64</c>
<c>(this draft)</c>
<c>2</c>
<c>Network Time Protocol version 4 64-bit Timestamp</c>
<c>64</c>
<c>(this draft)</c>
<c>3</c>
<c>IEEE 1588 version 1 Timestamp</c>
<c>64</c>
<c>(this draft)</c>
</texttable>
<t>The range of the Type field is 0-15.</t>
<t>The allocation policy for this registry is IETF Review.</t>
</section>
<section title="Creation of MPLS Loss/Delay Measurement Control Code Registry">
<t>IANA is requested to create 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:</t>
<texttable align="left" style="headers">
<preamble>Query Codes</preamble>
<ttcol>Code</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0x0</c>
<c>In-band Response Requested</c>
<c>(this draft)</c>
<c>0x1</c>
<c>Out-of-band Response Requested</c>
<c>(this draft)</c>
<c>0x2</c>
<c>No Response Requested</c>
<c>(this draft)</c>
</texttable>
<texttable align="left" style="headers">
<preamble>Response Codes</preamble>
<ttcol>Code</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0x0</c>
<c>Reserved</c>
<c>(this draft)</c>
<c>0x1</c>
<c>Success</c>
<c>(this draft)</c>
<c>0x2</c>
<c>Data Format Invalid</c>
<c>(this draft)</c>
<c>0x3</c>
<c>Initialization In Progress</c>
<c>(this draft)</c>
<c>0x4</c>
<c>Data Reset Occurred</c>
<c>(this draft)</c>
<c>0x5</c>
<c>Resource Temporarily Unavailable</c>
<c>(this draft)</c>
<c>0x10</c>
<c>Unspecified Error</c>
<c>(this draft)</c>
<c>0x11</c>
<c>Unsupported Version</c>
<c>(this draft)</c>
<c>0x12</c>
<c>Unsupported Control Code</c>
<c>(this draft)</c>
<c>0x13</c>
<c>Unsupported Data Format</c>
<c>(this draft)</c>
<c>0x14</c>
<c>Authentication Failure</c>
<c>(this draft)</c>
<c>0x15</c>
<c>Invalid Destination Node Identifier</c>
<c>(this draft)</c>
<c>0x16</c>
<c>Connection Mismatch</c>
<c>(this draft)</c>
<c>0x17</c>
<c>Unsupported Mandatory TLV Object</c>
<c>(this draft)</c>
<c>0x18</c>
<c>Unsupported Query Interval</c>
<c>(this draft)</c>
<c>0x19</c>
<c>Administrative Block</c>
<c>(this draft)</c>
<c>0x1A</c>
<c>Resource Unavailable</c>
<c>(this draft)</c>
<c>0x1B</c>
<c>Resource Released</c>
<c>(this draft)</c>
<c>0x1C</c>
<c>Invalid Message</c>
<c>(this draft)</c>
<c>0x1D</c>
<c>Protocol Error</c>
<c>(this draft)</c>
</texttable>
<t>IANA is also requested to indicate that the values 0x0 - 0xF in the
Response Code section are reserved for non-error response codes.</t>
<t>The range of the Code field is 0 - 255.</t>
<t>The allocation policy for this registry is IETF Review.</t>
</section>
<section title="Creation of MPLS Loss/Delay Measurement TLV Object Registry">
<t>IANA is requested to create a new MPLS Loss/Delay Measurement TLV
Object registry, with format and initial allocations as follows:</t>
<texttable align="left" style="headers">
<ttcol>Type</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>Padding - copy in response</c>
<c>(this draft)</c>
<c>1</c>
<c>Return Address</c>
<c>(this draft)</c>
<c>2</c>
<c>Session Query Interval</c>
<c>(this draft)</c>
<c>3</c>
<c>Loopback Request</c>
<c>(this draft)</c>
<c>120-127</c>
<c>Implementation-specific usage</c>
<c>(this draft)</c>
<c>128</c>
<c>Padding - do not copy in response</c>
<c>(this draft)</c>
<c>129</c>
<c>Destination Address</c>
<c>(this draft)</c>
<c>130</c>
<c>Source Address</c>
<c>(this draft)</c>
<c>248-255</c>
<c>Implementation-specific usage</c>
<c>(this draft)</c>
</texttable>
<t>IANA is also requested to indicate that Types 0-127 are classified
as Mandatory, and that Types 128-255 are classified as Optional.</t>
<t>The range of the Type field is 0 - 255.</t>
<t>The allocation policy for this registry is IETF Review, except for
the ranges marked "Implementation-specific usage", for which the
policy is Private Use.</t>
</section>
</section>
<section title="Acknowledgments">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2474'?>
<?rfc include='reference.RFC.3031'?>
<?rfc include='reference.RFC.3270'?>
<?rfc include='reference.RFC.5462'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.5905'?>
<reference anchor="IEEE1588">
<front>
<title>1588-2008 IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems</title>
<author surname="IEEE">
<organization abbrev="IEEE">IEEE</organization>
</author>
<date month="March" year="2008" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2679'?>
<?rfc include='reference.RFC.2681'?>
<?rfc include='reference.RFC.3209'?>
<?rfc include='reference.RFC.3260'?>
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.4928'?>
<?rfc include='reference.RFC.5036'?>
<?rfc include='reference.RFC.5884'?>
<?rfc include='reference.RFC.5921'?>
<?rfc include='reference.RFC.5960'?>
<?rfc include='reference.RFC.3393'?>
<reference anchor="Y.1731">
<front>
<title>OAM Functions and Mechanisms for Ethernet based
Networks</title>
<author surname="ITU-T Recommendation Y.1731">
<organization abbrev="ITU-T">ITU-T Recommendation
Y.1731</organization>
</author>
<date month="February" year="2008" />
</front>
</reference>
</references>
<section title="Default Timestamp Format Rationale" anchor="ts_rationale">
<t>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 IEEE1588 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 IEEE1588 PTP has
become the de facto time transfer protocol in networks which 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.</t>
<t>The truncated IEEE1588 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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:54:19 |