One document matched: draft-ietf-mpls-loss-delay-01.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-01"
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
packets 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.</t>
<t>The LM protocol supports both 32-bit and 64-bit packet
counters.</t>
<t>The LM protocol supports measurement in terms of both packet
counts and octet counts.</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="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>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>LSR</c>
<c>Label Switching Router</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>PW</c>
<c>Pseudowire</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.</t>
<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 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 inserts an appropriate response code into the
message and transmits it 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>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>
</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 a measurement of the throughput sustained over the
channel during the interval. This metric can be called the delivered
throughput. As for loss measurement, the interval counts can be
accumulated to arrive at the delivered throughput of the channel since
the start of the measurement operation. 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" />. Measurement of the one-way delay quantities
requires that the clocks of A and B be synchronized, whereas the
two-way delay can be measured directly even when this is not the case
(provided A and B have stable clocks).</t>
<t>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>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 inserts an appropriate response code into the
message and transmits it 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>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="Loopback Measurement">
<t>Some bidirectional channels may be placed into a loopback state
such that query messages are looped back to the querier without
modification. In this situation, LM and DM procedures can be used to
carry out measurements associated with the circular path.</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>
<t>Query messages must include some form of source identifier in order
for looped-back queries to be differentiated from queries initiated by
the far end.</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>
<t>Another aspect of packet processing which often arises in the
context of QoS concerns the location of the measurement points for
loss and delay within the sending and receiving nodes, which is
implementation-dependent. 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 impacts what, precisely, is being
measured. The principal consideration here is that the behavior of
an implementation in these respects SHOULD 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>
[Editor's note: The last two restrictions could be relaxed if
desired, at the expense of some additional protocol complexity.]
</t>
</section>
<section title="Loss Measurement 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
limitations 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>Another 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.</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">
<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 SHOULD 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 SHOULD 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. Support for multiple timestamp formats is OPTIONAL. An
implementation SHOULD, however, make clear which timestamp formats
it supports and the extent of its support for computation with and
reconciliation of different formats for purposes of delay
measurement.</t>
<t>In recognition of the wide deployment, particularly in
hardware-based timing implementations, of IEEE 1588 PTP, the PTP
timestamp format is the default format used in DM messages. This
format MUST be supported.</t>
</section>
</section>
</section>
<section title="Message Formats">
<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>
<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>Packet counter values in network byte order</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.</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>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 - Temporary Resource Exhaustion. Indicates that
the operation failed because node resources were not
available.</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.</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 is important for hardware
processing.</t>
<t>All counter values MUST be in network byte order. 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" />, except for the X
flag, which is set to 0, and the T flag, which 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 LM/DM message fields have the same meanings as the
corresponding fields in the LM and DM message formats.</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.</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>In recognition of the wide deployment, particularly in
hardware-based timing implementations, of IEEE 1588 PTP, the PTP
timestamp format is the default format used in Delay Measurement
messages. This format MUST be supported. Support for other timestamp
formats is OPTIONAL.</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>
</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 discard the message or respond with an
appropriate 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-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. 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="Session Query Interval">
<t>The Value field of the Session Query Interval object is a 32-bit
unsigned positive (nonzero) integer in network byte order that
specifies a time interval in milliseconds. When attached to a query
message, this time interval indicates the interval between
successive query messages in this measurement session. When
attached to a response, this time interval indicates the minimum
query interval supported by the responder for the measurement type
indicated by the query.</t>
<t>When initiating a new measurement session, the querier SHOULD
include this object to inform the responder of the rate at which it
intends to send query messages in this session. Upon receiving a
non-error response, the querier MAY then stop including this object
in subsequent messages in the session for as long as its query
transmission rate remains the same. When a query is received with a
Session Query Interval that is too low for the receiver to support,
the receiver SHOULD include this object when it generates an error
response.</t>
<t>Lower 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">
<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.</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>
<t>When initiating an LM operation, the far end may require a period
of time to become ready for the requested measurement operation.
During this period, LM queries MAY simply be discarded, and the
querier expecting a response SHOULD be prepared for this situation,
for example by setting a timer to differentiate between an
acceptable initialization delay and a permanent unavailability
condition at the far end. Alternatively, the receiver MAY respond,
possibly in a rate-limited manner, to queries received during this
period with an appropriate notification code.</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. The remaining Counter 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>
</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 SHOULD be 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 MUST be set to 0.</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. When the Control Code indicates an
error condition, the LM operation SHOULD be suspended and an
appropriate notification to the user generated. If a temporary error
condition is indicated, the LM operation MAY be restarted
automatically.</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">
<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.</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>
</section>
<section title="Message Loss and Packet Misorder Conditions">
<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.</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, which is usually what is
desired.</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 other timestamp 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>
</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 SHOULD be set to the time at which this DM Response is
received.</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. When the Control Code indicates an
error condition, an appropriate notification to the user SHOULD be
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 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>
</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>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>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>Temporary Resource Exhaustion</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>
</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>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>
</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, and to Linda
Dunbar for the idea of using LM messages for throughput measurement.</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'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:53:19 |