RFC 6374
Packet Loss and Delay Measurement for MPLS Networks
Internet Engineering Task Force (IETF) D. Frost Request for Comments: 6374 S. Bryant Category: Standards Track Cisco Systems ISSN: 2070-1721 September 2011 Packet Loss and Delay Measurement for MPLS NetworksAbstract
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6374. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3 1.1. Applicability and Scope ....................................5 1.2. Terminology ................................................6 1.3. Requirements Language ......................................6 2. Overview ........................................................6 2.1. Basic Bidirectional Measurement ............................6 2.2. Packet Loss Measurement ....................................7 2.3. Throughput Measurement ....................................10 2.4. Delay Measurement .........................................10 2.5. Delay Variation Measurement ...............................12 2.6. Unidirectional Measurement ................................12 2.7. Dyadic Measurement ........................................13 2.8. Loopback Measurement ......................................13 2.9. Measurement Considerations ................................14 2.9.1. Types of Channels ..................................14 2.9.2. Quality of Service .................................14 2.9.3. Measurement Point Location .........................14 2.9.4. Equal Cost Multipath ...............................15 2.9.5. Intermediate Nodes .................................15 2.9.6. Different Transmit and Receive Interfaces ..........16 2.9.7. External Post-Processing ...........................16 2.9.8. Loss Measurement Modes .............................16 2.9.9. Loss Measurement Scope .............................18 2.9.10. Delay Measurement Accuracy ........................18 2.9.11. Delay Measurement Timestamp Format ................18 3. Message Formats ................................................19 3.1. Loss Measurement Message Format ...........................19 3.2. Delay Measurement Message Format ..........................25 3.3. Combined Loss/Delay Measurement Message Format ............27 3.4. Timestamp Field Formats ...................................28 3.5. TLV Objects ...............................................29 3.5.1. Padding ............................................30 3.5.2. Addressing .........................................31 3.5.3. Loopback Request ...................................31 3.5.4. Session Query Interval .............................32 4. Operation ......................................................33 4.1. Operational Overview ......................................33 4.2. Loss Measurement Procedures ...............................34 4.2.1. Initiating a Loss Measurement Operation ............34 4.2.2. Transmitting a Loss Measurement Query ..............34 4.2.3. Receiving a Loss Measurement Query .................35 4.2.4. Transmitting a Loss Measurement Response ...........35 4.2.5. Receiving a Loss Measurement Response ..............36 4.2.6. Loss Calculation ...................................36 4.2.7. Quality of Service .................................37 4.2.8. G-ACh Packets ......................................37
4.2.9. Test Messages ......................................37
4.2.10. Message Loss and Packet Misorder Conditions .......38
4.3. Delay Measurement Procedures ..............................39
4.3.1. Transmitting a Delay Measurement Query .............39
4.3.2. Receiving a Delay Measurement Query ................39
4.3.3. Transmitting a Delay Measurement Response ..........40
4.3.4. Receiving a Delay Measurement Response .............41
4.3.5. Timestamp Format Negotiation .......................41
4.3.5.1. Single-Format Procedures ..................42
4.3.6. Quality of Service .................................42
4.4. Combined Loss/Delay Measurement Procedures ................42
5. Implementation Disclosure Requirements .........................42
6. Congestion Considerations ......................................44
7. Manageability Considerations ...................................44
8. Security Considerations ........................................45
9. IANA Considerations ............................................46
9.1. Allocation of PW Associated Channel Types .................47
9.2. Creation of Measurement Timestamp Type Registry ...........47
9.3. Creation of MPLS Loss/Delay Measurement Control
Code Registry .............................................47
9.4. Creation of MPLS Loss/Delay Measurement TLV Object
Registry ..................................................49
10. Acknowledgments ...............................................49
11. References ....................................................49
11.1. Normative References .....................................49
11.2. Informative References ...................................50
Appendix A. Default Timestamp Format Rationale ....................52
1. Introduction
Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning,
troubleshooting, and network performance evaluation. This document
specifies protocol mechanisms to enable the efficient and accurate
measurement of these performance metrics in MPLS networks.
This document specifies two closely related protocols, one for packet
loss measurement (LM) and one for packet delay measurement (DM).
These protocols have the following characteristics and capabilities:
o The LM and DM protocols are intended to be simple and to support
efficient hardware processing.
o The LM and DM protocols operate over the MPLS Generic Associated
Channel (G-ACh) [RFC5586] and support measurement of loss, delay,
and related metrics over Label Switched Paths (LSPs), pseudowires,
and MPLS sections (links).
o The LM and DM protocols are applicable to the LSPs, pseudowires,
and sections of networks based on the MPLS Transport Profile
(MPLS-TP), because the MPLS-TP is based on a standard MPLS data
plane. The MPLS-TP is defined and described in [RFC5921], and
MPLS-TP LSPs, pseudowires, and sections are discussed in detail in
[RFC5960]. A profile describing the minimal functional subset of
the LM and DM protocols in the MPLS-TP context is provided in
[RFC6375].
o The LM and DM protocols can be used both for continuous/proactive
and selective/on-demand measurement.
o The LM and DM protocols use a simple query/response model for
bidirectional measurement that allows a single node -- the querier
-- to measure the loss or delay in both directions.
o The LM and DM protocols use query messages for unidirectional loss
and delay measurement. The measurement can be carried out either
at the downstream node(s) or at the querier if an out-of-band
return path is available.
o The LM and DM protocols do not require that the transmit and
receive interfaces be the same when performing bidirectional
measurement.
o The DM protocol is stateless.
o The LM protocol is "almost" stateless: loss is computed as a delta
between successive messages, and thus the data associated with the
last message received must be retained.
o The LM protocol can perform two distinct kinds of loss
measurement: it can measure the loss of specially generated test
messages in order to infer the approximate data-plane loss level
(inferred measurement) or it can directly measure data-plane
packet loss (direct measurement). Direct measurement provides
perfect loss accounting, but may require specialized hardware
support and is only applicable to some LSP types. Inferred
measurement provides only approximate loss accounting but is
generally applicable.
The direct LM method is also known as "frame-based" in the context
of Ethernet transport networks [Y.1731]. Inferred LM is a
generalization of the "synthetic" measurement approach currently
in development for Ethernet networks, in the sense that it allows
test messages to be decoupled from measurement messages.
o The LM protocol supports measurement in terms of both packet
counts and octet counts.
o The LM protocol supports both 32-bit and 64-bit counters.
o The LM protocol can be used to measure channel throughput as well
as packet loss.
o The DM protocol supports multiple timestamp formats, and provides
a simple means for the two endpoints of a bidirectional connection
to agree on a preferred format. This procedure reduces to a
triviality for implementations supporting only a single timestamp
format.
o The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes.
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way
Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities
for the measurement of various performance metrics in IP networks.
These protocols are not streamlined for hardware processing and rely
on IP and TCP, as well as elements of the Network Time Protocol
(NTP), which may not be available or optimized in some network
environments; they also lack support for IEEE 1588 timestamps and
direct-mode LM, which may be required in some environments. The
protocols defined in this document thus are similar in some respects
to, but also differ from, these IP-based protocols.
1.1. Applicability and Scope
This document specifies measurement procedures and protocol messages
that are intended to be applicable in a wide variety of circumstances
and amenable to implementation by a wide range of hardware- and
software-based measurement systems. As such, it does not attempt to
mandate measurement quality levels or analyze specific end-user
applications.
1.2. Terminology
Term Definition ----- ------------------------------------------- ACH Associated Channel Header DM Delay Measurement ECMP Equal Cost Multipath G-ACh Generic Associated Channel LM Loss Measurement LSE Label Stack Entry LSP Label Switched Path NTP Network Time Protocol OAM Operations, Administration, and Maintenance PTP Precision Time Protocol TC Traffic Class1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].2. Overview
This section begins with a summary of the basic methods used for the bidirectional measurement of packet loss and delay. These measurement methods are then described in detail. Finally, a list of practical considerations is discussed that may come into play to inform or modify these simple procedures. This section is limited to theoretical discussion; for protocol specifics, the reader is referred to Sections 3 and 4.2.1. Basic Bidirectional Measurement
The following figure shows the reference scenario. T1 T2 +-------+/ Query \+-------+ | | - - - - - - - - ->| | | A |===================| B | | |<- - - - - - - - - | | +-------+\ Response /+-------+ T4 T3 This figure shows a bidirectional channel between two nodes, A and B, and illustrates the temporal reference points T1-T4 associated with a measurement operation that takes place at A. The operation consists of A sending a query message to B, and B sending back a response.
Each reference point indicates the point in time at which either the query or the response message is transmitted or received over the channel. In this situation, A can arrange to measure the packet loss over the channel in the forward and reverse directions by sending Loss Measurement (LM) query messages to B, each of which contains the count of packets transmitted prior to time T1 over the channel to B (A_TxP). When the message reaches B, it appends two values and reflects the message back to A: the count of packets received prior to time T2 over the channel from A (B_RxP) and the count of packets transmitted prior to time T3 over the channel to A (B_TxP). When the response reaches A, it appends a fourth value: the count of packets received prior to time T4 over the channel from B (A_RxP). These four counter values enable A to compute the desired loss statistics. Because the transmit count at A and the receive count at B (and vice versa) may not be synchronized at the time of the first message, and to limit the effects of counter wrap, the loss is computed in the form of a delta between messages. To measure at A the delay over the channel to B, a Delay Measurement (DM) query message is sent from A to B containing a timestamp recording the instant at which it is transmitted, i.e., T1. When the message reaches B, a timestamp is added recording the instant at which it is received (T2). The message can now be reflected from B to A, with B adding its transmit timestamp (T3) and A adding its receive timestamp (T4). These four timestamps enable A to compute the one-way delay in each direction, as well as the two-way delay for the channel. The one-way delay computations require that the clocks of A and B be synchronized; mechanisms for clock synchronization are outside the scope of this document.2.2. Packet Loss Measurement
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A the following two quantities associated with the channel: A_TxLoss (transmit loss): the number of packets transmitted by A over the channel but not received at B; A_RxLoss (receive loss): the number of packets transmitted by B over the channel but not received at A.
This is accomplished by initiating a Loss Measurement (LM) operation
at A, which consists of transmission of a sequence of LM query
messages (LM[1], LM[2], ...) over the channel at a specified rate,
such as one every 100 milliseconds. Each message LM[n] contains the
following value:
A_TxP[n]: the total count of packets transmitted by A over the
channel prior to the time this message is transmitted.
When such a message is received at B, the following value is recorded
in the message:
B_RxP[n]: the total count of packets received by B over the
channel at the time this message is received (excluding the
message itself).
At this point, B transmits the message back to A, recording within it
the following value:
B_TxP[n]: the total count of packets transmitted by B over the
channel prior to the time this response is transmitted.
When the message response is received back at A, the following value
is recorded in the message:
A_RxP[n]: the total count of packets received by A over the
channel at the time this response is received (excluding the
message itself).
The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n]
within the measurement interval marked by the messages LM[n-1] and
LM[n] are computed by A as follows:
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
where the arithmetic is modulo the counter size.
(Strictly speaking, it is not necessary that the fourth count,
A_RxP[n], actually be written in the message, but this is convenient
for some implementations and useful if the message is to be forwarded
on to an external measurement system.)
The derived values
A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...
A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...
are updated each time a response to an LM message is received and
processed, and they represent the total transmit and receive loss
over the channel since the LM operation was initiated.
When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n], the
possibility of counter wrap must be taken into account. For example,
consider the values of the A_TxP counter at sequence numbers n-1 and
n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a
value equal to or greater than A_TxP[n-1], the computation of an
unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore, the
LM message rate MUST be sufficiently high, given the counter size and
the speed and minimum packet size of the underlying channel, that
this condition cannot arise. For example, a 32-bit counter for a
100-Gbps link with a minimum packet size of 64 bytes can wrap in 2^32
/ (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on
the LM message interval under such conditions. This bound will be
referred to as the MaxLMInterval of the channel. It is clear that
the MaxLMInterval will be a more restrictive constraint in the case
of direct LM and for smaller counter sizes.
The loss measurement approach described in this section has the
characteristic of being stateless at B and "almost" stateless at A.
Specifically, A must retain the data associated with the last LM
response received, in order to use it to compute loss when the next
response arrives. This data MAY be discarded, and MUST NOT be used
as a basis for measurement, if MaxLMInterval elapses before the next
response arrives, because in this case an unambiguous measurement
cannot be made.
The foregoing discussion has assumed the counted objects are packets,
but this need not be the case. In particular, octets may be counted
instead. This will, of course, reduce the MaxLMInterval accordingly.
In addition to absolute aggregate loss counts, the individual loss
counts yield other metrics, such as the average loss rate over any
multiple of the measurement interval. An accurate loss rate can be
determined over time even in the presence of anomalies affecting
individual measurements, such as those due to packet misordering
(Section 4.2.10).
Note that an approach for conducting packet loss measurement in IP networks is documented in [RFC2680]. This approach differs from the one described here, for example by requiring clock synchronization between the measurement points and lacking support for direct-mode LM.2.3. Throughput Measurement
If LM query messages contain a timestamp recording their time of transmission, this data can be combined with the packet or octet counts to yield measurements of the throughput offered and delivered over the channel during the interval in terms of the counted units. For a bidirectional channel, for example, given any two LM response messages (separated in time by not more than the MaxLMInterval), the difference between the counter values tells the querier the number of units successfully transmitted and received in the interval between the timestamps. Absolute offered throughput is the number of data units transmitted and absolute delivered throughput is the number of data units received. Throughput rate is the number of data units sent or received per unit time. Just as for loss measurement, the interval counts can be accumulated to arrive at the absolute throughput of the channel since the start of the measurement operation or be used to derive related metrics such as the throughput rate. This procedure also enables out-of- service throughput testing when combined with a simple packet generator.2.4. Delay Measurement
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A one or more of the following quantities associated with the channel: o The one-way delay associated with the forward (A to B) direction of the channel; o The one-way delay associated with the reverse (B to A) direction of the channel; o The two-way delay (A to B to A) associated with the channel. The one-way delay metric for packet networks is described in [RFC2679]. In the case of two-way delay, there are actually two possible metrics of interest. The "two-way channel delay" is the sum of the one-way delays in each direction and reflects the delay of the channel itself, irrespective of processing delays within the remote
endpoint B. The "round-trip delay" is described in [RFC2681] and includes in addition any delay associated with remote endpoint processing. Measurement of the one-way delay quantities requires that the clocks of A and B be synchronized, whereas the two-way delay metrics can be measured directly even when this is not the case (provided A and B have stable clocks). A measurement is accomplished by sending a Delay Measurement (DM) query message over the channel to B that contains the following timestamp: T1: the time the DM query message is transmitted from A. When the message arrives at B, the following timestamp is recorded in the message: T2: the time the DM query message is received at B. At this point, B transmits the message back to A, recording within it the following timestamp: T3: the time the DM response message is transmitted from B. When the message arrives back at A, the following timestamp is recorded in the message: T4: the time the DM response message is received back at A. (Strictly speaking, it is not necessary that the fourth timestamp, T4, actually be written in the message, but this is convenient for some implementations and useful if the message is to be forwarded on to an external measurement system.) At this point, A can compute the two-way channel delay associated with the channel as two-way channel delay = (T4 - T1) - (T3 - T2) and the round-trip delay as round-trip delay = T4 - T1.
If the clocks of A and B are known at A to be synchronized, then both
one-way delay values, as well as the two-way channel delay, can be
computed at A as
forward one-way delay = T2 - T1
reverse one-way delay = T4 - T3
two-way channel delay = forward delay + reverse delay.
Note that this formula for the two-way channel delay reduces to the
one previously given, and clock synchronization is not required to
compute this metric.
2.5. Delay Variation Measurement
Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV)
[RFC5481] are performance metrics derived from one-way delay
measurement and are important in some applications. IPDV represents
the difference between the one-way delays of successive packets in a
stream. PDV, given a measurement test interval, represents the
difference between the one-way delay of a packet in the interval and
that of the packet in the interval with the minimum delay.
IPDV and PDV measurements can therefore be derived from delay
measurements obtained through the procedures in Section 2.4. An
important point regarding delay variation measurement, however, is
that it can be carried out based on one-way delay measurements even
when the clocks of the two systems involved in those measurements are
not synchronized with one another.
2.6. Unidirectional Measurement
In the case that the channel from A to (B1, ..., Bk) (where B2, ...,
Bk refers to the point-to-multipoint case) is unidirectional, i.e.,
is a unidirectional LSP, LM and DM measurements can be carried out at
B1, ..., Bk instead of at A.
For LM, this is accomplished by initiating an LM operation at A and
carrying out the same procedures as used for bidirectional channels,
except that no responses from B1, ..., Bk to A are generated.
Instead, each terminal node B uses the A_TxP and B_RxP values in the
LM messages it receives to compute the receive loss associated with
the channel in essentially the same way as described previously, that
is:
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
For DM, of course, only the forward one-way delay can be measured and the clock synchronization requirement applies. Alternatively, if an out-of-band channel from a terminal node B back to A is available, the LM and DM message responses can be communicated to A via this channel so that the measurements can be carried out at A.2.7. Dyadic Measurement
The basic procedures for bidirectional measurement assume that the measurement process is conducted by and for the querier node A. Instead, it is possible, with only minor variation of these procedures, to conduct a dyadic or "dual-ended" measurement process in which both nodes A and B perform loss or delay measurement based on the same message flow. This is achieved by stipulating that A copy the third and fourth counter or timestamp values from a response message into the third and fourth slots of the next query, which are otherwise unused, thereby providing B with equivalent information to that learned by A. The dyadic procedure has the advantage of halving the number of messages required for both A and B to perform a given kind of measurement, but comes at the expense of each node's ability to control its own measurement process independently, and introduces additional operational complexity into the measurement protocols. The quantity of measurement traffic is also expected to be low relative to that of user traffic, particularly when 64-bit counters are used for LM. Consequently, this document does not specify a dyadic operational mode. However, it is still possible, and may be useful, for A to perform the extra copy, thereby providing additional information to B even when its participation in the measurement process is passive.2.8. Loopback Measurement
Some bidirectional channels may be placed into a loopback state such that messages are looped back to the sender without modification. In this situation, LM and DM procedures can be used to carry out measurements associated with the circular path. This is done by generating "queries" with the Response flag set to 1. For LM, the loss computation in this case is: A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
For DM, the round-trip delay is computed. In this case, however, the remote endpoint processing time component reflects only the time required to loop the message from channel input to channel output.2.9. Measurement Considerations
A number of additional considerations apply in practice to the measurement methods summarized above.2.9.1. Types of Channels
There are several types of channels in MPLS networks over which loss and delay measurement may be conducted. The channel type may restrict the kinds of measurement that can be performed. In all cases, LM and DM messages flow over the MPLS Generic Associated Channel (G-ACh), which is described in detail in [RFC5586]. Broadly, a channel in an MPLS network may be either a link, a Label Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are bidirectional and are also referred to as MPLS sections; see [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label Switched Paths may be either unidirectional or bidirectional. The LM and DM protocols discussed in this document are initiated from a single node: the querier. A query message may be received either by a single node or by multiple nodes, depending on the nature of the channel. In the latter case, these protocols provide point-to- multipoint measurement capabilities.2.9.2. Quality of Service
Quality of Service (QoS) capabilities, in the form of the Differentiated Services architecture, apply to MPLS as specified in [RFC3270] and [RFC5462]. Different classes of traffic are distinguished by the three-bit Traffic Class (TC) field of an MPLS Label Stack Entry (LSE). Delay measurement applies on a per-traffic- class basis, and the TC values of LSEs above the G-ACh Label (GAL) that precedes a DM message are significant. Packet loss can be measured with respect either to the channel as a whole or to a specific traffic class.2.9.3. Measurement Point Location
The location of the measurement points for loss and delay within the sending and receiving nodes is implementation dependent but directly affects the nature of the measurements. For example, a sending implementation may or may not consider a packet to be "lost", for LM purposes, that was discarded prior to transmission for queuing-
related reasons; conversely, a receiving implementation may or may not consider a packet to be "lost", for LM purposes, if it was physically received but discarded during receive-path processing. The location of delay measurement points similarly determines what, precisely, is being measured. The principal consideration here is that the behavior of an implementation in these respects MUST be made clear to the user.2.9.4. Equal Cost Multipath
Equal Cost Multipath (ECMP) is the behavior of distributing packets across multiple alternate paths toward a destination. The use of ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical result of ECMP being performed on an LSP that is subject to delay measurement will be that only the delay of one of the available paths is, and can be, measured. The effects of ECMP on loss measurement will depend on the LM mode. In the case of direct LM, the measurement will account for any packets lost between the sender and the receiver, regardless of how many paths exist between them. However, the presence of ECMP increases the likelihood of misordering both of LM messages relative to data packets and of the LM messages themselves. Such misorderings tend to create unmeasurable intervals and thus degrade the accuracy of loss measurement. The effects of ECMP are similar for inferred LM, with the additional caveat that, unless the test packets are specially constructed so as to probe all available paths, the loss characteristics of one or more of the alternate paths cannot be accounted for.2.9.5. Intermediate Nodes
In the case of an LSP, it may be desirable to measure the loss or delay to or from an intermediate node as well as between LSP endpoints. This can be done in principle by setting the Time to Live (TTL) field in the outer LSE appropriately when targeting a measurement message to an intermediate node. This procedure may fail, however, if hardware-assisted measurement is in use, because the processing of the packet by the intermediate node occurs only as the result of TTL expiry, and the handling of TTL expiry may occur at a later processing stage in the implementation than the hardware- assisted measurement function. The motivation for conducting measurements to intermediate nodes is often an attempt to localize a problem that has been detected on the LSP. In this case, if intermediate nodes are not capable of performing hardware-assisted measurement, a less accurate -- but usually sufficient -- software- based measurement can be conducted instead.
2.9.6. Different Transmit and Receive Interfaces
The overview of the bidirectional measurement process presented in Section 2 is also applicable when the transmit and receive interfaces at A or B differ from one another. Some additional considerations, however, do apply in this case: o If different clocks are associated with transmit and receive processing, these clocks must be synchronized in order to compute the two-way delay. o The DM protocol specified in this document requires that the timestamp formats used by the interfaces that receive a DM query and transmit a DM response agree. o The LM protocol specified in this document supports both 32-bit and 64-bit counter sizes, but the use of 32-bit counters at any of the up to four interfaces involved in an LM operation will result in 32-bit LM calculations for both directions of the channel.2.9.7. External Post-Processing
In some circumstances, it may be desirable to carry out the final measurement computation at an external post-processing device dedicated to the purpose. This can be achieved in supporting implementations by, for example, configuring the querier, in the case of a bidirectional measurement session, to forward each response it receives to the post-processor via any convenient protocol. The unidirectional case can be handled similarly through configuration of the receiver or by including an instruction in query messages for the receiver to respond out-of-band to the appropriate return address. Post-processing devices may have the ability to store measurement data for an extended period and to generate a variety of useful statistics from them. External post-processing also allows the measurement process to be completely stateless at the querier and responder.2.9.8. Loss Measurement Modes
The summary of loss measurement at the beginning of Section 2 made reference to the "count of packets" transmitted and received over a channel. If the counted packets are the packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode". If, on the other hand, the counted packets are selected control packets from which the approximate loss characteristics of the channel are being inferred, the loss measurement is said to operate in "inferred mode".
Direct LM has the advantage of being able to provide perfect loss accounting when it is available. There are, however, several constraints associated with direct LM. For accurate direct LM to occur, packets must not be sent between the time the transmit count for an outbound LM message is determined and the time the message is actually transmitted. Similarly, packets must not be received and processed between the time an LM message is received and the time the receive count for the message is determined. If these "synchronization conditions" do not hold, the LM message counters will not reflect the true state of the data plane, with the result that, for example, the receive count of B may be greater than the transmit count of A, and attempts to compute loss by taking the difference will yield an invalid result. This requirement for synchronization between LM message counters and the data plane may require special support from hardware-based forwarding implementations. A limitation of direct LM is that it may be difficult or impossible to apply in cases where the channel is an LSP and the LSP label at the receiver is either nonexistent or fails to identify a unique sending node. The first case happens when Penultimate Hop Popping (PHP) is used on the LSP, and the second case generally holds for LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as opposed to, for example, those based on Traffic Engineering extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. These conditions may make it infeasible for the receiver to identify the data-plane packets associated with a particular source and LSP in order to count them, or to infer the source and LSP context associated with an LM message. Direct LM is also vulnerable to disruption in the event that the ingress or egress interface associated with an LSP changes during the LSP's lifetime. Inferred LM works in the same manner as direct LM except that the counted packets are special control packets, called test messages, generated by the sender. Test messages may be either packets explicitly constructed and used for LM or packets with a different primary purpose, such as those associated with a Bidirectional Forwarding Detection (BFD) [RFC5884] session. The synchronization conditions discussed above for direct LM also apply to inferred LM, the only difference being that the required synchronization is now between the LM counters and the test message generation process. Protocol and application designers MUST take these synchronization requirements into account when developing tools for inferred LM, and make their behavior in this regard clear to the user.
Inferred LM provides only an approximate view of the loss level associated with a channel, but is typically applicable even in cases where direct LM is not.2.9.9. Loss Measurement Scope
In the case of direct LM, where data-plane packets are counted, there are different possibilities for which kinds of packets are included in the count and which are excluded. The set of packets counted for LM is called the "loss measurement scope". As noted above, one factor affecting the LM scope is whether all data packets are counted or only those belonging to a particular traffic class. Another is whether various "auxiliary" flows associated with a data channel are counted, such as packets flowing over the G-ACh. Implementations MUST make their supported LM scopes clear to the user, and care must be taken to ensure that the scopes of the channel endpoints agree.2.9.10. Delay Measurement Accuracy
The delay measurement procedures described in this document are designed to facilitate hardware-assisted measurement and to function in the same way whether or not such hardware assistance is used. The measurement accuracy will be determined by how closely the transmit and receive timestamps correspond to actual packet departure and arrival times. As noted in Section 2.4, measurement of one-way delay requires clock synchronization between the devices involved, while two-way delay measurement does not involve direct comparison between non-local timestamps and thus has no synchronization requirement. The measurement accuracy will be limited by the quality of the local clock and, in the case of one-way delay measurement, by the quality of the synchronization.2.9.11. Delay Measurement Timestamp Format
There are two significant timestamp formats in common use: the timestamp format of the Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. The NTP format has the advantages of wide use and long deployment in the Internet, and it was specifically designed to make the computation of timestamp differences as simple and efficient as possible. On the other hand, there is now also a significant deployment of equipment designed to support the PTP format.
The approach taken in this document is therefore to include in DM messages fields that identify the timestamp formats used by the two devices involved in a DM operation. This implies that a node attempting to carry out a DM operation may be faced with the problem of computing with and possibly reconciling different timestamp formats. To ensure interoperability, it is necessary that support of at least one timestamp format is mandatory. This specification requires the support of the IEEE 1588 PTP format. Timestamp format support requirements are discussed in detail in Section 3.4.
(page 19 continued on part 2)
