One document matched: draft-ietf-mpls-tp-loss-delay-00.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-tp-loss-delay-00"
ipr="trust200902">
<front>
<title abbrev="MPLS-TP Loss and Delay Measurement">Packet Loss and Delay
Measurement for the MPLS Transport Profile</title>
<author fullname="Dan Frost" initials="D" role="editor" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<email>danfrost@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" role="editor"
surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<date year="2010" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>An essential Operations, Administration and Maintenance requirement
of the MPLS Transport Profile (MPLS-TP) is the ability to monitor
performance metrics for packet loss and one-way and two-way delay for
MPLS-TP pseudowires, Label Switched Paths, and Sections. This document
specifies protocol mechanisms to facilitate the efficient and accurate
measurement of these performance metrics.</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>The MPLS Transport Profile (MPLS-TP) <xref
target="I-D.ietf-mpls-tp-framework" /> comprises the set of protocol
functions that meet the requirements <xref target="RFC5654" /> for
the application of MPLS to the construction and operation of
packet-switched transport networks.</t>
<t>RFC 5860 <xref target="RFC5860" /> specifies Operations,
Administration and Maintenance (OAM) definitions and requirements for
the measurement of packet loss and one-way and two-way delay for MPLS-TP
pseudowires (PWs), Label Switched Paths (LSPs), and Sections. For
convenience these definitions and requirements are summarized in the
following subsections.</t>
<section title="Review of Requirements">
<section title="Requirements for Packet Loss Measurement">
<t>The MPLS-TP OAM toolset must provide a function to enable the
quantification of packet loss ratio over a PW, LSP or
Section.</t>
<t>The loss of a packet is defined in <xref target="RFC2680" />
(Section 2.4). This definition is used here.</t>
<t>Packet loss ratio is defined here to be the ratio of the
number of user packets lost to the total number of user packets
sent during a defined time interval.</t>
<t>This function may either be performed pro-actively or
on-demand.</t>
<t>This function should be performed between End Points of PWs,
LSPs and Sections.</t>
<t>It should be possible to rely on user traffic to perform this
function.</t>
<t>The protocol solution(s) developed to perform this function
must apply to point-to-point co-routed bidirectional LSPs,
point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint (unidirectional)
LSPs.</t>
</section>
<section title="Requirements for Delay Measurement" anchor="dmreq">
<t>The MPLS-TP OAM toolset must provide a function to enable the
quantification of the one-way, and if appropriate, the two-way,
delay of a PW, LSP or Section.</t>
<t><list style="symbols">
<t>The one-way delay is defined in <xref target="RFC2679" />
to be the time elapsed from the start of transmission of the
first bit of a packet by an End Point until the reception of
the last bit of that packet by the other End Point.</t>
<t>The two-way delay is defined in <xref target="RFC2681" />
to be the time elapsed from the start of transmission of the
first bit of a packet by an End Point until the reception of
the last bit of that packet by the same End Point.</t>
</list>
</t>
<t>Two-way delay may be quantified using data traffic loopback
at the remote End Point of the PW, LSP or Section.</t>
<t>Accurate quantification of one-way delay may require clock
synchronization, the means for which are outside the scope of
this document.</t>
<t>This function should be performed on-demand and may be
performed pro-actively.</t>
<t>This function should be performed between End Points of PWs,
LSPs and Sections.</t>
<t>In addition to point-to-point co-routed bidirectional LSPs,
the protocol solution(s) developed to perform this function must
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint
(unidirectional) LSPs, but only to enable the quantification of
the one-way delay.</t>
</section>
</section>
<section title="Protocol Summary">
<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 designed to be simple and to
support efficient hardware processing.</t>
<t>The LM and DM protocols support measurement of loss and
delay over MPLS-TP pseudowires and sections, over associated
and co-routed bidirectional point-to-point MPLS-TP LSPs, and
over unidirectional point-to-point and point-to-multipoint
MPLS-TP LSPs.</t>
<t>The LM and DM protocols support pro-active and on-demand
modes of operation.</t>
<t>The LM and DM protocols use a simple query/response model
over bidirectional connections that allows a single node - the
querier - to measure the loss or delay of both directions of
the connection.</t>
<t>The LM and DM protocols use query messages to measure the
loss or delay of a unidirectional connection. 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 at an endpoint of a
bidirectional connection.</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 provides perfect loss measurement if the
necessary implementation support is available.</t>
<t>The LM protocol supports both 32-bit and 64-bit packet
counters.</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>
<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>MPLS-TP</c>
<c>MPLS Transport Profile</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>The basic procedures for measuring loss and delay over a
bidirectional connection are conceptually simple. 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 connection 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 connection.</t>
<t>In this situation, A can arrange to measure the packet loss over the
connection 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 connection 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 connection from A (B_RxP), and the count of packets transmitted
prior to time T3 over the connection 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 connection 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 connection 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 connection. 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>
<t>In the case of a unidirectional connection rooted at A, the first
half of each of the above procedures can be carried out to measure the
forward one-way loss and delay associated with the connection. At this
point the measurement can either take place at the terminal node(s) of
the connection rather than at A, or an out-of-band channel can be used,
if available, to communicate the data back to A.</t>
<t>In the context of MPLS-TP, LM and DM messages flow over the Generic
Associated Channel (G-ACh) <xref target="RFC5586" /> of an MPLS-TP
pseudowire, LSP, or Section. The term "connection" is used in this
document to mean "pseudowire, LSP, or Section". Although this document
often speaks of "measuring the loss or delay associated with a
connection" for simplicity, LM and DM actually occur with respect to a
particular class of packets flowing over a connection. This is
discussed in more detail in <xref target="ppqos" />.</t>
<section title="Implementation Considerations">
<t>The challenge in carrying out the above procedures lies with the
implementation. For accurate loss measurement 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. For accurate delay measurement,
timestamps must be recorded in DM messages at a point in time as close
as possible to when the message is actually transmitted or received
over the connection.</t>
<t>These accuracy requirements imply that a hardware-based forwarding
implementation may require hardware support for the processing of LM
and DM messages. An important consideration of the LM/DM protocol and
message format is therefore support for efficient hardware
processing.</t>
<t>In situations where such accuracy is not required, or the necessary
level of support is not available, an implementation MAY still
generate and respond to LM and DM messages but SHOULD make its
accuracy limitations clear to the user. In general the DM procedures
described in this document remain viable under these conditions, but
the procedures for LM may be inadequate.</t>
<t>The LM procedures described in this document have the advantage of
providing perfect packet loss accounting if the necessary
implementation support is available. This is a desirable capability
in an LM protocol for MPLS-TP given that loss levels for typical
MPLS-TP connections are expected to be quite low, and that even small
amounts of loss on such connections may be unacceptable. This
capability, however, may well come at the expense of more costly
hardware, and in some environments this cost may be prohibitive. Thus
it is desirable to define an additional set of LM procedures for
MPLS-TP that support deployments in which perfect loss accounting is
not required. Such alternative procedures rely on the generation of
either existing or new MPLS-TP OAM message types, which are subjected
to loss accounting as a proxy for user traffic in order to infer
approximate loss levels of the latter. This alternative approach to
LM is for further study and will be described in a companion
document.</t>
</section>
<section anchor="ov_loss" title="Packet Loss Measurement">
<t>Suppose a bidirectional connection such as an MPLS-TP pseudowire,
bidirectional LSP, or Section exists between the LSRs A and B. The
objective is to measure at A the following two quantities associated
with the connection: <list style="empty">
<t>A_TxLoss (transmit loss): the number of packets transmitted by
A over the connection but not received at B;</t>
<t>A_RxLoss (receive loss): the number of packets transmitted by B
over the connection 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 connection 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
connection 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
connection 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
connection 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
connection 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 connection 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 times 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 connection, 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.</t>
</section>
<section anchor="ov_delay" title="Delay Measurement">
<t>Suppose a bidirectional connection such as an MPLS-TP pseudowire,
bidirectional LSP, or Section exists between the LSRs A and B. The
objective is to measure at A one or more of the following quantities
associated with the connection: <list style="symbols">
<t>The one-way delay associated with the forward (A to B)
direction of the connection;</t>
<t>The one-way delay associated with the reverse (B to A)
direction of the connection;</t>
<t>The two-way delay (A to B to A) associated with the
connection.</t>
</list></t>
<t>In the case of two-way delay, there are actually two possible
metrics of interest. The "strict" two-way delay is the sum of the
one-way delays in each direction and reflects the two-way delay of the
connection itself, irrespective of processing delays within the remote
endpoint B. The "loose" two-way delay is the definition of two-way
delay stated in <xref target="dmreq" /> 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 can be
measured directly even when this is not the case (provided A and B
have stable clocks).</t>
<t>The measurement is accomplished by sending a Delay Measurement (DM)
query message over the connection 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 strict two-way delay associated with the
connection as
<list style="empty">
<t>strict two-way delay = (T4 - T1) - (T3 - T2)</t>
</list>
and the loose two-way delay as
<list style="empty">
<t>loose two-way 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 strict two-way 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>strict two-way delay = forward delay + reverse delay.</t>
</list>
</t>
<section title="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="RFC1305"></xref> and <xref
target="RFC2030"></xref>, and the timestamp format used in the IEEE
1588 Precision Time Protocol (PTP) <xref
target="IEEE1588"></xref>.</t>
<t>[Editor's note: There are actually two PTP timestamp formats: the
1588v1 format consists of a 32-bit seconds field and a 32-bit
nanoseconds field; in 1588v2 the seconds field was extended to 48
bits.]</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 an LSR
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 title="Delay Variation Measurement">
<t>Packet Delay Variation <xref target="RFC3393"></xref> 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 MP1 to
measurement point MP2. 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"></xref>. 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 Connections">
<t>In the case that the connection 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 connections,
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
connection 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 connection from a terminal node B
back to A is available, the LM and DM message responses can be
communicated to A via this connection so that the measurements can be
carried out at A.</t>
</section>
<section title="Distributed Systems">
<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, as may occur when the
connection is an MPLS-TP LSP that is not co-routed. Some additional
considerations, however, do apply in this case:
<list style="symbols">
<t>If the transmit and receive interfaces reside on different line
cards, the clocks of those line cards 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
connection.</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>
<section title="Packet Format">
<t>Loss Measurement and Delay Measurement messages flow over the Generic
Associated Channel (G-ACh) <xref target="RFC5586"></xref> of an MPLS-TP
connection (pseudowire, LSP or Section).</t>
<t>[Editor's note: The question of ACH TLV usage and the manner of
supporting metadata such as authentication keys and node identifiers is
deliberately omitted. These issues will be addressed in a future version
of the document.]</t>
<section anchor="pf_lm" title="Loss Measurement Message Format">
<t>The format of a Loss Measurement message, beginning with 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0xHH (MPLS-TP Loss) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<texttable align="left" style="headers">
<preamble>The meanings of the fields following the ACH 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>Session Identifier</c>
<c>Set arbitrarily by the querier</c>
<c>Sequence Number</c>
<c>64-bit sequence number, incremented for each message</c>
<c>Counter 1-4</c>
<c>Packet counter values in network byte order</c>
</texttable>
<t>The possible values for these fields are as follows.</t>
<t>Version: Currently set to 0.</t>
<t>Flags: Each bit represents a message control flag. The flags,
listed in left-to-right (most- to least-significant-bit) order, are:
<list style="empty">
<t>Q/R: Set to 0 for a Query and 1 for a Response.</t>
<t>X: Extended data format. Indicates support for 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>Remaining bits: Reserved for future specification and 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 Q/R flag. <list style="empty">
<t>For a Query: <list style="empty">
<t>0x0: Query (in-band response requested). Indicates that
this query has been sent over a bidirectional connection and
the response is expected over the same connection.</t>
<t>0x1: Query (out-of-band response requested). Indicates that
the response should be sent via an out-of-band channel.</t>
<t>0x2: Query (no response requested). Indicates that no
response to the query should be sent.</t>
</list></t>
<t>For a Response: <list style="empty">
<t>0x1: Success. Indicates that the operation was
successful.</t>
<t>0x8: 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>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 connection.</t>
<t>0x13: Error - Authentication Failure. Indicates that the
operation failed because the authentication data supplied in
the query was missing or incorrect.</t>
<t>0x14: Error - Invalid Source Node Identifier. Indicates
that the operation failed because the Source Node Identifier
supplied in the query is not expected.</t>
<t>0x15: Error - Invalid Destination Node Identifier.
Indicates that the operation failed because the Destination
Node Identifier supplied in the query is not the identifier of
this node.</t>
<t>0x16: Error - Connection Mismatch. Indicates that the
operation failed because the connection identifier supplied in
the query did not match the connection over which the query
was received.</t>
<t>0x17: Error - Query Rate Exceeded. Indicates that the
operation failed because the rate of query messages exceeded
the configured threshold.</t>
<t>0x18: Error - Administrative Block. Indicates that the
operation failed because it has been administratively
disallowed.</t>
<t>0x19: Error - Temporary Resource Exhaustion. Indicates that
the operation failed because node resources were not
available.</t>
</list></t>
</list></t>
<t>Session Identifier: Set arbitrarily in a query and copied in the
response, if any.</t>
<t>Counter 1-4: Referring to <xref target="ov_loss"></xref>, 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. All counter values MUST
be in network byte order.</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>
</section>
<section anchor="pf_dm" title="Delay Measurement Message Format">
<t>The format of a Delay Measurement message, beginning with 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0xHH (MPLS-TP Delay) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | QTF | RTF | RPTF | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<texttable align="left" style="headers">
<preamble>The meanings of the fields following the ACH 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>Session Identifier</c>
<c>Set arbitrarily by the querier</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>Resv (Reserved)</c>
<c>Reserved for future specification</c>
<c>Timestamp 1-4</c>
<c>64-bit timestamp values</c>
<c>Padding</c>
<c>Optional padding</c>
</texttable>
<t>The possible values for these fields are as follows.</t>
<t>Version: Currently set to 0.</t>
<t>Flags: As specified in <xref target="pf_lm"></xref>.</t>
<t>Control Code: As specified in <xref target="pf_lm"></xref>.</t>
<t>Session Identifier: Set arbitrarily in a query and copied in the
response, if any.</t>
<t>Message Length: Set to the total length of this message, excluding
the ACH, in bytes.</t>
<t>Querier Timestamp Format: The format of the timestamp values
written by the querier, as specified in <xref
target="pf_tsf"></xref>.</t>
<t>Responder Timestamp Format: The format of the timestamp values
written by the responder, as specified in <xref
target="pf_tsf"></xref>.</t>
<t>Responder's Preferred Timestamp Format: The timestamp format
preferred by the responder, as specified in <xref
target="pf_tsf"></xref>.</t>
<t>Resv (Reserved): Currently set to 0.</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>Padding: One or more octets of padding may optionally follow the
Timestamp 4 field in a query, in order to allow for delay measurement
based on packets of a particular size. The value of the first octet
of padding provides information about the padding. If in a Query the
first bit of the first pad octet is 1, the padding SHALL be copied to
the response, assuming one was requested. If this bit is 0, the
response MUST NOT include padding. The remaining bits in the first
pad octet are reserved and SHALL be set to 0. The values of the
remaining pad octets, if present, are arbitrary.</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>0x0: Network Time Protocol version 4 timestamp format <xref
target="RFC2030"></xref>. 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>0x2: 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>
<section title="Operation">
<section title="Loss Measurement Procedures">
<section title="Initiating a Loss Measurement Operation">
<t>An LM operation for a particular MPLS-TP connection consists of
sending a sequence (LM[1], LM[2], ...) of LM query messages over the
connection at a specific rate and processing the responses received,
if any. As described in <xref target="ov_loss"></xref>, the packet
loss associated with the connection 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
connection.</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
connection, 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 connection) 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 an MPLS-TP connection, the
Version and Reserved fields MUST be set to 0. The Q/R flag MUST be
set to 0. 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 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 connection
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 Sequence Number field MUST be set to 0 for the first message
sent after device initialization or explicit reset, and incremented
by 1 for each subsequent message sent.</t>
<t>The Counter 1 field SHOULD be set to the total count of packets
transmitted over the connection 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 packets received over the connection
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 and
Reserved fields MUST be set to 0. The Q/R flag MUST be set to 1. The
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 remaining flag bits MUST be set to 0.</t>
<t>The Session Identifier and Sequence Number 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"></xref>. 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 packets transmitted over the
connection 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 packets received over the
connection 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>
</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"></xref>. 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 connection 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>[Editor's note: Text to be added here about handling the above
conditions with sequence numbers and thresholds.]</t>
</section>
</section>
<section title="Delay Measurement Procedures">
<section title="Transmitting a Delay Measurement Query">
<t>When transmitting a DM Query over an MPLS-TP connection, the
Version and Reserved fields MUST be set to 0. The Q/R flag MUST be
set to 0 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 connection
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 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"></xref>. The Responder Timestamp Format and
Responder's Preferred Timestamp Format fields MUST be set to 0.</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>
<t>One or more pad octets MAY follow the Timestamp 4 field, as
described in <xref target="pf_dm" />.</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 Q/R 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"></xref>. Furthermore, the RTF field MUST be set
equal either to the QTF or the RPTF field. See <xref
target="op_dm_tsfn"></xref> 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"></xref> 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"></xref>. 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>
<t>Padding SHALL be included in the response if, and only if,
padding was present in the DM Query and the first bit of the first
octet of that padding was set to 1, in which case the response
padding MUST be identical to the query padding.</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 connection. The procedures for making this
determination SHALL be as follows.</t>
<t>Upon sending an initial DM Query over a connection, 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 connection, all DM Queries received
with QTF not equal to the supported format are discarded.</t>
</list>
</t>
</section>
</section>
</section>
</section>
<section title="Packet Profiles and Quality of Service" anchor="ppqos">
<t>Although this document has referred, for simplicity, to measuring the
packet loss or delay associated with a connection, it is more precise to
say that these measurement operations occur with respect to a specific
class of packets transiting the connection. Such a class is referred to
as a "packet profile".</t>
<t>Care must be taken to ensure that the endpoints of an LM or DM
operation agree on the packet profile. For DM this reduces to ensuring
that query and response messages are assigned to the same traffic class,
while for LM it requires that the LM counters at each endpoint count the
same kinds of packets.</t>
<t>This document considers two aspects of packet profile support
pertinent to loss and delay measurement:
<list style="symbols">
<t>Quality of Service</t>
<t>Loss Measurement of OAM Messages</t>
</list>
</t>
<section title="Quality of Service">
<t>For connections that support multiple traffic classes, such as
those that employ the Traffic Class (TC) field <xref target="RFC5462"
/> in the MPLS Label Stack Entry (LSE) for Differentiated Services
<xref target="RFC3270" />, the implementation MUST provide the
capability to perform delay measurement on a per-traffic-class basis,
by assigning the DM messages themselves to the corresponding
class.</t>
<t>For connections that support multiple traffic classes, the
implementation SHOULD provide the capability to perform loss
measurement on a per-traffic-class basis, and MAY provide the more
general capability to perform loss measurement on a subset of the
traffic classes supported by the connection, by restricting the LM
packet profile (i.e. the class of packets counted by the LM counters)
accordingly. LM messages themselves SHOULD be assigned to a traffic
class equal to or better than the best traffic class within the LM
packet profile.</t>
</section>
<section title="Loss Measurement of OAM Messages">
<t>By default the LM packet profile MUST include packets transmitted
and received over the Generic Associated Channel (G-ACh) associated
with a connection. An implementation MAY provide the means to alter
the LM packet profile to exclude some or all G-ACh messages.</t>
</section>
</section>
<section anchor="con_con" title="Congestion Considerations">
<t>An MPLS-TP 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-TP
connection naturally results in a degree of additional load placed on
both the network and the terminal nodes of the connection. 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"></xref>.</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 connection 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 two 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; 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"></xref>. If reception of performance-related data by
unauthorized devices is an operational concern, message authentication
procedures such as those described in [xref] should be used to ensure
that only queries from authorized devices are processed.</t>
</section>
<section title="IANA Considerations">
<t>A future version of this document will detail IANA considerations
for: <list style="symbols">
<t>ACH Channel Types for LM and DM messages</t>
<t>Timestamp format registry</t>
<t>LM and DM Control Codes</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5654'?>
<?rfc include='reference.RFC.5860'?>
<?rfc include='reference.RFC.5586'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-mpls-tp-framework'?>
<?rfc include='reference.RFC.1305'?>
<?rfc include='reference.RFC.2030'?>
<?rfc include='reference.RFC.2679'?>
<?rfc include='reference.RFC.2680'?>
<?rfc include='reference.RFC.2681'?>
<?rfc include='reference.RFC.3270'?>
<?rfc include='reference.RFC.3393'?>
<?rfc include='reference.RFC.5462'?>
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:46 |