summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6374.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6374.txt')
-rw-r--r--doc/rfc/rfc6374.txt2915
1 files changed, 2915 insertions, 0 deletions
diff --git a/doc/rfc/rfc6374.txt b/doc/rfc/rfc6374.txt
new file mode 100644
index 0000000..f62c498
--- /dev/null
+++ b/doc/rfc/rfc6374.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Frost
+Request for Comments: 6374 S. Bryant
+Category: Standards Track Cisco Systems
+ISSN: 2070-1721 September 2011
+
+
+ Packet Loss and Delay Measurement for MPLS Networks
+
+Abstract
+
+ Many service provider service level agreements (SLAs) depend on the
+ ability to measure and monitor performance metrics for packet loss
+ and one-way and two-way delay, as well as related metrics such as
+ delay variation and channel throughput. This measurement capability
+ also provides operators with greater visibility into the performance
+ characteristics of their networks, thereby facilitating planning,
+ troubleshooting, and network performance evaluation. This document
+ specifies protocol mechanisms to enable the efficient and accurate
+ measurement of these performance metrics in MPLS networks.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6374.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Frost & Bryant Standards Track [Page 1]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+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
+
+
+
+Frost & Bryant Standards Track [Page 2]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+
+Frost & Bryant Standards Track [Page 3]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 4]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 5]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+1.2. Terminology
+
+ Term Definition
+ ----- -------------------------------------------
+ ACH Associated Channel Header
+ DM Delay Measurement
+ ECMP Equal Cost Multipath
+ G-ACh Generic Associated Channel
+ LM Loss Measurement
+ LSE Label Stack Entry
+ LSP Label Switched Path
+ NTP Network Time Protocol
+ OAM Operations, Administration, and Maintenance
+ PTP Precision Time Protocol
+ TC Traffic Class
+
+1.3. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Overview
+
+ This section begins with a summary of the basic methods used for the
+ bidirectional measurement of packet loss and delay. These
+ measurement methods are then described in detail. Finally, a list of
+ practical considerations is discussed that may come into play to
+ inform or modify these simple procedures. This section is limited to
+ theoretical discussion; for protocol specifics, the reader is
+ referred to Sections 3 and 4.
+
+2.1. Basic Bidirectional Measurement
+
+ The following figure shows the reference scenario.
+
+ T1 T2
+ +-------+/ Query \+-------+
+ | | - - - - - - - - ->| |
+ | A |===================| B |
+ | |<- - - - - - - - - | |
+ +-------+\ Response /+-------+
+ T4 T3
+
+ This figure shows a bidirectional channel between two nodes, A and B,
+ and illustrates the temporal reference points T1-T4 associated with a
+ measurement operation that takes place at A. The operation consists
+ of A sending a query message to B, and B sending back a response.
+
+
+
+Frost & Bryant Standards Track [Page 6]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 7]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.)
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 8]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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).
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 9]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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
+
+
+
+Frost & Bryant Standards Track [Page 10]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 11]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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])
+
+
+
+
+Frost & Bryant Standards Track [Page 12]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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])
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 13]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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-
+
+
+
+Frost & Bryant Standards Track [Page 14]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+Frost & Bryant Standards Track [Page 15]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+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".
+
+
+
+Frost & Bryant Standards Track [Page 16]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+Frost & Bryant Standards Track [Page 17]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+
+
+
+
+Frost & Bryant Standards Track [Page 18]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+3. Message Formats
+
+ Loss Measurement and Delay Measurement messages flow over the MPLS
+ Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet
+ containing an LM or DM message contains an MPLS label stack, with the
+ G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by
+ an Associated Channel Header (ACH), which identifies the message
+ type, and the message body follows the ACH.
+
+ This document defines the following ACH Channel Types:
+
+ MPLS Direct Loss Measurement (DLM)
+ MPLS Inferred Loss Measurement (ILM)
+ MPLS Delay Measurement (DM)
+ MPLS Direct Loss and Delay Measurement (DLM+DM)
+ MPLS Inferred Loss and Delay Measurement (ILM+DM)
+
+ The message formats for direct and inferred LM are identical. The
+ formats of the DLM+DM and ILM+DM messages are also identical.
+
+ For these channel types, the ACH SHALL NOT be followed by the ACH TLV
+ Header defined in [RFC5586].
+
+ The fixed-format portion of a message MAY be followed by a block of
+ Type-Length-Value (TLV) fields. The TLV block provides an extensible
+ way of attaching subsidiary information to LM and DM messages.
+ Several such TLV fields are defined below.
+
+ All integer values for fields defined in this document SHALL be
+ encoded in network byte order.
+
+3.1. Loss Measurement Message Format
+
+ The format of a Loss Measurement message, which follows the
+ Associated Channel Header (ACH), is as follows:
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 19]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| Flags | Control Code | Message Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DFlags| OTF | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session Identifier | DS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Origin Timestamp |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Counter 1 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Counter 4 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ TLV Block ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Loss Measurement Message Format
+
+ Reserved fields MUST be set to 0 and ignored upon receipt. The
+ possible values for the remaining fields are as follows.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 20]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ Field Meaning
+ --------------------- -----------------------------------------------
+ Version Protocol version
+ Flags Message control flags
+ Control Code Code identifying the query or response type
+ Message Length Total length of this message in bytes
+ Data Format Flags Flags specifying the format of message data
+ (DFlags)
+ Origin Timestamp Format of the Origin Timestamp field
+ Format (OTF)
+ Reserved Reserved for future specification
+ Session Identifier Set arbitrarily by the querier
+ Differentiated Differentiated Services Code Point (DSCP) being
+ Services (DS) Field measured
+ Origin Timestamp 64-bit field for query message transmission
+ timestamp
+ Counter 1-4 64-bit fields for LM counter values
+ TLV Block Optional block of Type-Length-Value fields
+
+ The possible values for these fields are as follows.
+
+ Version: Currently set to 0.
+
+ Flags: The format of the Flags field is shown below.
+
+ +-+-+-+-+
+ |R|T|0|0|
+ +-+-+-+-+
+
+ Loss Measurement Message Flags
+
+ The meanings of the flag bits are:
+
+ R: Query/Response indicator. Set to 0 for a Query and 1 for a
+ Response.
+
+ T: Traffic-class-specific measurement indicator. Set to 1 when
+ the measurement operation is scoped to packets of a particular
+ traffic class (DSCP value), and 0 otherwise. When set to 1, the
+ DS field of the message indicates the measured traffic class.
+
+ 0: Set to 0.
+
+ Control Code: Set as follows according to whether the message is a
+ Query or a Response as identified by the R flag.
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 21]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ For a Query:
+
+ 0x0: In-band Response Requested. Indicates that this query has
+ been sent over a bidirectional channel and the response is
+ expected over the same channel.
+
+ 0x1: Out-of-band Response Requested. Indicates that the
+ response should be sent via an out-of-band channel.
+
+ 0x2: No Response Requested. Indicates that no response to the
+ query should be sent. This mode can be used, for example, if
+ all nodes involved are being controlled by a Network Management
+ System.
+
+ For a Response:
+
+ Codes 0x0-0xF are reserved for non-error responses. Error
+ response codes imply that the response does not contain valid
+ measurement data.
+
+ 0x1: Success. Indicates that the operation was successful.
+
+ 0x2: Notification - Data Format Invalid. Indicates that the
+ query was processed, but the format of the data fields in this
+ response may be inconsistent. Consequently, these data fields
+ MUST NOT be used for measurement.
+
+ 0x3: Notification - Initialization in Progress. Indicates that
+ the query was processed but this response does not contain
+ valid measurement data because the responder's initialization
+ process has not completed.
+
+ 0x4: Notification - Data Reset Occurred. Indicates that the
+ query was processed, but a reset has recently occurred that may
+ render the data in this response inconsistent relative to
+ earlier responses.
+
+ 0x5: Notification - Resource Temporarily Unavailable.
+ Indicates that the query was processed, but resources were
+ unavailable to complete the requested measurement and that,
+ consequently, this response does not contain valid measurement
+ data.
+
+ 0x10: Error - Unspecified Error. Indicates that the operation
+ failed for an unspecified reason.
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 22]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 0x11: Error - Unsupported Version. Indicates that the
+ operation failed because the protocol version supplied in the
+ query message is not supported.
+
+ 0x12: Error - Unsupported Control Code. Indicates that the
+ operation failed because the Control Code requested an
+ operation that is not available for this channel.
+
+ 0x13: Error - Unsupported Data Format. Indicates that the
+ operation failed because the data format specified in the query
+ is not supported.
+
+ 0x14: Error - Authentication Failure. Indicates that the
+ operation failed because the authentication data supplied in
+ the query was missing or incorrect.
+
+ 0x15: Error - Invalid Destination Node Identifier. Indicates
+ that the operation failed because the Destination Node
+ Identifier supplied in the query is not an identifier of this
+ node.
+
+ 0x16: Error - Connection Mismatch. Indicates that the
+ operation failed because the channel identifier supplied in the
+ query did not match the channel over which the query was
+ received.
+
+ 0x17: Error - Unsupported Mandatory TLV Object. Indicates that
+ the operation failed because a TLV Object received in the query
+ and marked as mandatory is not supported.
+
+ 0x18: Error - Unsupported Query Interval. Indicates that the
+ operation failed because the query message rate exceeded the
+ configured threshold.
+
+ 0x19: Error - Administrative Block. Indicates that the
+ operation failed because it has been administratively
+ disallowed.
+
+ 0x1A: Error - Resource Unavailable. Indicates that the
+ operation failed because node resources were not available.
+
+ 0x1B: Error - Resource Released. Indicates that the operation
+ failed because node resources for this measurement session were
+ administratively released.
+
+ 0x1C: Error - Invalid Message. Indicates that the operation
+ failed because the received query message was malformed.
+
+
+
+
+Frost & Bryant Standards Track [Page 23]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 0x1D: Error - Protocol Error. Indicates that the operation
+ failed because a protocol error was found in the received query
+ message.
+
+ Message Length: Set to the total length of this message in bytes,
+ including the Version, Flags, Control Code, and Message Length fields
+ as well as the TLV Block, if any.
+
+ DFlags: The format of the DFlags field is shown below.
+
+ +-+-+-+-+
+ |X|B|0|0|
+ +-+-+-+-+
+
+ Data Format Flags
+
+ The meanings of the DFlags bits are:
+
+ X: Extended counter format indicator. Indicates the use of
+ extended (64-bit) counter values. Initialized to 1 upon creation
+ (and prior to transmission) of an LM Query and copied from an LM
+ Query to an LM response. Set to 0 when the LM message is
+ transmitted or received over an interface that writes 32-bit
+ counter values.
+
+ B: Octet (byte) count. When set to 1, indicates that the Counter
+ 1-4 fields represent octet counts. The octet count applies to all
+ packets within the LM scope (Section 2.9.9), and the octet count
+ of a packet sent or received over a channel includes the total
+ length of that packet (but excludes headers, labels, or framing of
+ the channel itself). When set to 0, indicates that the Counter
+ 1-4 fields represent packet counts.
+
+ 0: Set to 0.
+
+ Origin Timestamp Format: The format of the Origin Timestamp field, as
+ specified in Section 3.4.
+
+ Session Identifier: Set arbitrarily in a query and copied in the
+ response, if any. This field uniquely identifies a measurement
+ operation (also called a session) that consists of a sequence of
+ messages. All messages in the sequence have the same Session
+ Identifier.
+
+ DS: When the T flag is set to 1, this field is set to the DSCP value
+ [RFC3260] that corresponds to the traffic class being measured. For
+ MPLS, where the traffic class of a channel is identified by the
+ three-bit Traffic Class in the channel's LSE [RFC5462], this field
+
+
+
+Frost & Bryant Standards Track [Page 24]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ SHOULD be set to the Class Selector Codepoint [RFC2474] that
+ corresponds to that Traffic Class. When the T flag is set to 0, the
+ value of this field is arbitrary, and the field can be considered
+ part of the Session Identifier.
+
+ Origin Timestamp: Timestamp recording the transmit time of the query
+ message.
+
+ Counter 1-4: Referring to Section 2.2, 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.
+
+ The mapping of counter types such as A_TxP to the Counter 1-4 fields
+ is designed to ensure that transmit counter values are always written
+ at the same fixed offset in the packet, and likewise for receive
+ counters. This property may be important for hardware processing.
+
+ 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.
+
+ TLV Block: Zero or more TLV fields.
+
+3.2. Delay Measurement Message Format
+
+ The format of a Delay Measurement message, which follows the
+ Associated Channel Header (ACH), is as follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 25]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| Flags | Control Code | Message Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | QTF | RTF | RPTF | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session Identifier | DS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timestamp 1 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timestamp 4 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ TLV Block ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Delay Measurement Message Format
+
+ The meanings of the fields are summarized in the following table.
+
+ Field Meaning
+ --------------------- -----------------------------------------------
+ Version Protocol version
+ Flags Message control flags
+ Control Code Code identifying the query or response type
+ Message Length Total length of this message in bytes
+ QTF Querier timestamp format
+ RTF Responder timestamp format
+ RPTF Responder's preferred timestamp format
+ Reserved Reserved for future specification
+ Session Identifier Set arbitrarily by the querier
+ Differentiated Differentiated Services Code Point (DSCP) being
+ Services (DS) Field measured
+
+ Timestamp 1-4 64-bit timestamp values
+ TLV Block Optional block of Type-Length-Value fields
+
+ Reserved fields MUST be set to 0 and ignored upon receipt. The
+ possible values for the remaining fields are as follows.
+
+ Version: Currently set to 0.
+
+
+
+
+Frost & Bryant Standards Track [Page 26]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ Flags: As specified in Section 3.1. The T flag in a DM message is
+ set to 1.
+
+ Control Code: As specified in Section 3.1.
+
+ Message Length: Set to the total length of this message in bytes,
+ including the Version, Flags, Control Code, and Message Length fields
+ as well as the TLV Block, if any.
+
+ Querier Timestamp Format: The format of the timestamp values written
+ by the querier, as specified in Section 3.4.
+
+ Responder Timestamp Format: The format of the timestamp values
+ written by the responder, as specified in Section 3.4.
+
+ Responder's Preferred Timestamp Format: The timestamp format
+ preferred by the responder, as specified in Section 3.4.
+
+ Session Identifier: As specified in Section 3.1.
+
+ DS: As specified in Section 3.1.
+
+ Timestamp 1-4: Referring to Section 2.4, 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.
+
+ The mapping of timestamps to the Timestamp 1-4 fields is designed to
+ ensure that transmit timestamps are always written at the same fixed
+ offset in the packet, and likewise for receive timestamps. This
+ property is important for hardware processing.
+
+ TLV Block: Zero or more TLV fields.
+
+3.3. Combined Loss/Delay Measurement Message Format
+
+ The format of a combined Loss and Delay Measurement message, which
+ follows the Associated Channel Header (ACH), is as follows:
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 27]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| Flags | Control Code | Message Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DFlags| QTF | RTF | RPTF | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session Identifier | DS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timestamp 1 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timestamp 4 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Counter 1 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Counter 4 |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ TLV Block ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Loss/Delay Measurement Message Format
+
+ The fields of this message have the same meanings as the
+ corresponding fields in the LM and DM message formats, except that
+ the roles of the OTF and Origin Timestamp fields for LM are here
+ played by the QTF and Timestamp 1 fields, respectively.
+
+3.4. Timestamp Field Formats
+
+ The following timestamp format field values are specified in this
+ document:
+
+ 0: Null timestamp format. This value is a placeholder indicating
+ that the timestamp field does not contain a meaningful timestamp.
+
+
+
+
+
+Frost & Bryant Standards Track [Page 28]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 1: Sequence number. This value indicates that the timestamp field
+ is to be viewed as a simple 64-bit sequence number. This provides
+ a simple solution for applications that do not require a real
+ absolute timestamp, but only an indication of message ordering; an
+ example is LM exception detection.
+
+ 2: Network Time Protocol version 4 64-bit timestamp format
+ [RFC5905]. This format consists of a 32-bit seconds field
+ followed by a 32-bit fractional seconds field, so that it can be
+ regarded as a fixed-point 64-bit quantity.
+
+ 3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time
+ Protocol timestamp format [IEEE1588]. This truncated format
+ consists of a 32-bit seconds field followed by a 32-bit
+ nanoseconds field, and is the same as the IEEE 1588v1 timestamp
+ format.
+
+ 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.
+
+ To ensure that it is possible to find an interoperable mode between
+ implementations, it is necessary to select one timestamp format as
+ the default. The timestamp format chosen as the default is the
+ truncated IEEE 1588 PTP format (format code 3 in the list above);
+ this format MUST be supported. The rationale for this choice is
+ discussed in Appendix A. Implementations SHOULD also be capable of
+ reading timestamps written in NTPv4 64-bit format and reconciling
+ them internally with PTP timestamps for measurement purposes.
+ Support for other timestamp formats is OPTIONAL.
+
+ The implementation MUST make clear which timestamp formats it
+ supports and the extent of its support for computation with and
+ reconciliation of different formats for measurement purposes.
+
+3.5. TLV Objects
+
+ The TLV Block in LM and DM messages consists of zero or more objects
+ with the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ TLV Format
+
+
+
+Frost & Bryant Standards Track [Page 29]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ The Type and Length fields are each 8 bits long, and the Length field
+ indicates the size in bytes of the Value field, which can therefore
+ be up to 255 bytes long.
+
+ The Type space is divided into Mandatory and Optional subspaces:
+
+ Type Range Semantics
+ -------------- ---------
+ 0-127 Mandatory
+ 128-255 Optional
+
+ Upon receipt of a query message including an unrecognized mandatory
+ TLV object, the recipient MUST respond with an Unsupported Mandatory
+ TLV Object error code.
+
+ The types defined are as follows:
+
+ Type Definition
+ -------------- ---------------------------------
+ Mandatory
+ 0 Padding - copy in response
+ 1 Return Address
+ 2 Session Query Interval
+ 3 Loopback Request
+ 4-126 Unallocated
+ 127 Experimental use
+
+ Optional
+ 128 Padding - do not copy in response
+ 129 Destination Address
+ 130 Source Address
+ 131-254 Unallocated
+ 255 Experimental use
+
+3.5.1. Padding
+
+ The two padding objects permit the augmentation of packet size; this
+ is mainly useful for delay measurement. The type of padding
+ indicates whether the padding supplied by the querier is to be copied
+ to, or omitted from, the response. Asymmetrical padding may be
+ useful when responses are delivered out-of-band or when different
+ maximum transmission unit sizes apply to the two components of a
+ bidirectional channel.
+
+ More than one padding object MAY be present, in which case they MUST
+ be contiguous. The Value field of a padding object is arbitrary.
+
+
+
+
+
+Frost & Bryant Standards Track [Page 30]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+3.5.2. Addressing
+
+ The addressing objects have the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Address ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Addressing Object Format
+
+ The Address Family field indicates the type of the address, and it
+ SHALL be set to one of the assigned values in the "IANA Address
+ Family Numbers" registry.
+
+ The Source and Destination Address objects indicate the addresses of
+ the sender and the intended recipient of the message, respectively.
+ The Source Address of a query message SHOULD be used as the
+ destination for an out-of-band response unless some other out-of-band
+ response mechanism has been configured, and unless a Return Address
+ object is present, in which case the Return Address specifies the
+ target of the response. The Return Address object MUST NOT appear in
+ a response.
+
+3.5.3. Loopback Request
+
+ The Loopback Request object, when included in a query, indicates a
+ request that the query message be returned to the sender unmodified.
+ This object has a Length of 0.
+
+ Upon receiving the reflected query message back from the responder,
+ the querier MUST NOT retransmit the message. Information that
+ uniquely identifies the original query source, such as a Source
+ Address object, can be included to enable the querier to
+ differentiate one of its own loopback queries from a loopback query
+ initiated by the far end.
+
+ This object may be useful, for example, when the querier is
+ interested only in the round-trip delay metric. In this case, no
+ support for delay measurement is required at the responder at all,
+ other than the ability to recognize a DM query that includes this
+ object and return it unmodified.
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 31]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+3.5.4. Session Query Interval
+
+ The Value field of the Session Query Interval object is a 32-bit
+ unsigned integer that specifies a time interval in milliseconds.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Session Query >
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ < Interval (ms) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Session Query Interval Object Format
+
+ This time interval indicates the interval between successive query
+ messages in a specific measurement session. The purpose of the
+ Session Query Interval (SQI) object is to enable the querier and
+ responder of a measurement session to agree on a query rate. The
+ procedures for handling this object SHALL be as follows:
+
+ 1. The querier notifies the responder that it wishes to be informed
+ of the responder's minimum query interval for this session by
+ including the SQI object in its query messages, with a Value of
+ 0.
+
+ 2. When the responder receives a query that includes an SQI object
+ with a Value of 0, the responder includes an SQI object in the
+ response with the Value set to the minimum query interval it
+ supports for this session.
+
+ 3. When the querier receives a response that includes an SQI object,
+ it selects a query interval for the session that is greater than
+ or equal to the Value specified in the SQI object and adjusts its
+ query transmission rate accordingly, including in each subsequent
+ query an SQI object with a Value equal to the selected query
+ interval. Once a response to one of these subsequent queries has
+ been received, the querier infers that the responder has been
+ apprised of the selected query interval and MAY then stop
+ including the SQI object in queries associated with this session.
+
+ Similar procedures allow the query rate to be changed during the
+ course of the session by either the querier or the responder. For
+ example, to inform the querier of a change in the minimum supported
+ query interval, the responder begins including a corresponding SQI
+ object in its responses, and the querier adjusts its query rate if
+ necessary and includes a corresponding SQI object in its queries
+ until a response is received.
+
+
+
+Frost & Bryant Standards Track [Page 32]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ Shorter query intervals (i.e., higher query rates) provide finer
+ measurement granularity at the expense of additional load on
+ measurement endpoints and the network; see Section 6 for further
+ discussion.
+
+4. Operation
+
+4.1. Operational Overview
+
+ A loss or delay measurement operation, also called a session, is
+ controlled by the querier and consists of a sequence of query
+ messages associated with a particular channel and a common set of
+ measurement parameters. If the session parameters include a response
+ request, then the receiving node or nodes will (under normal
+ conditions) generate a response message for each query message
+ received, and these responses are also considered part of the
+ session. All query and response messages in a session carry a common
+ session identifier.
+
+ Measurement sessions are initiated at the discretion of the network
+ operator and are terminated either at the operator's request or as
+ the result of an error condition. A session may be as brief as a
+ single message exchange, for example when a DM query is used by the
+ operator to "ping" a remote node, or it may extend throughout the
+ lifetime of the channel.
+
+ When a session is initiated for which responses are requested, the
+ querier SHOULD initialize a timer, called the SessionResponseTimeout,
+ that indicates how long the querier will wait for a response before
+ abandoning the session and notifying the user that a timeout has
+ occurred. This timer persists for the lifetime of the session and is
+ reset each time a response message for the session is received.
+
+ When a query message is received that requests a response, a variety
+ of exceptional conditions may arise that prevent the responder from
+ generating a response that contains valid measurement data. Such
+ conditions fall broadly into two classes: transient exceptions from
+ which recovery is possible and fatal exceptions that require
+ termination of the session. When an exception arises, the responder
+ SHOULD generate a response with an appropriate Notification or Error
+ control code according to whether the exception is, respectively,
+ transient or fatal. When the querier receives an Error response, the
+ session MUST be terminated and the user informed.
+
+ A common example of a transient exception occurs when a new session
+ is initiated and the responder requires a period of time to become
+ ready before it can begin providing useful responses. The response
+ control code corresponding to this situation is Notification -
+
+
+
+Frost & Bryant Standards Track [Page 33]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ Initialization in Progress. Typical examples of fatal exceptions are
+ cases where the querier has requested a type of measurement that the
+ responder does not support or where a query message is malformed.
+
+ When initiating a session, the querier SHOULD employ the Session
+ Query Interval mechanism (Section 3.5.4) to establish a mutually
+ agreeable query rate with the responder. Responders SHOULD employ
+ rate-limiting mechanisms to guard against the possibility of
+ receiving an excessive quantity of query messages.
+
+4.2. Loss Measurement Procedures
+
+4.2.1. Initiating a Loss Measurement Operation
+
+ An LM operation for a particular channel consists of sending a
+ sequence (LM[1], LM[2], ...) of LM query messages over the channel at
+ a specific rate and processing the responses received, if any. As
+ described in Section 2.2, the packet loss associated with the channel
+ during the operation is computed as a delta between successive
+ messages; these deltas can be accumulated to obtain a running total
+ of the packet loss for the channel or be used to derive related
+ metrics such as the average loss rate.
+
+ The query message transmission rate MUST be sufficiently high, given
+ the LM message counter size (which can be either 32 or 64 bits) and
+ the speed and minimum packet size of the underlying channel, that the
+ ambiguity condition noted in Section 2.2 cannot arise. In evaluating
+ this rate, the implementation SHOULD assume that the counter size is
+ 32 bits unless explicitly configured otherwise or unless (in the case
+ of a bidirectional channel) all local and remote interfaces involved
+ in the LM operation are known to be 64-bit-capable, which can be
+ inferred from the value of the X flag in an LM response.
+
+4.2.2. Transmitting a Loss Measurement Query
+
+ When transmitting an LM Query, the Version field MUST be set to 0.
+ The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and
+ only if, the measurement is specific to a particular traffic class,
+ in which case the DS field SHALL identify that traffic class.
+
+ The X flag MUST be set to 1 if the transmitting interface writes
+ 64-bit LM counters and otherwise MUST be set to 0 to indicate that
+ 32-bit counters are written. The B flag SHALL be set to 1 to
+ indicate that the counter fields contain octet counts or to 0 to
+ indicate packet counts.
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 34]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ The Control Code field MUST be set to one of the values for Query
+ messages listed in Section 3.1; if the channel is unidirectional,
+ this field MUST NOT be set to 0x0 (Query: In-band Response
+ Requested).
+
+ The Session Identifier field can be set arbitrarily.
+
+ The Origin Timestamp field SHALL be set to the time at which this
+ message is transmitted, and the Origin Timestamp Format field MUST be
+ set to indicate its format, according to Section 3.4.
+
+ The Counter 1 field SHOULD be set to the total count of units
+ (packets or octets, according to the B flag) transmitted over the
+ channel prior to this LM Query, or to 0 if this is the beginning of a
+ measurement session for which counter data is not yet available. The
+ Counter 2 field MUST be set to 0. If a response was previously
+ received in this measurement session, the Counter 1 and Counter 2
+ fields of the most recent such response MAY be copied to the Counter
+ 3 and Counter 4 fields, respectively, of this query; otherwise, the
+ Counter 3 and Counter 4 fields MUST be set to 0.
+
+4.2.3. Receiving a Loss Measurement Query
+
+ Upon receipt of an LM Query message, the Counter 2 field SHOULD be
+ set to the total count of units (packets or octets, according to the
+ B flag) received over the channel prior to this LM Query. If the
+ receiving interface writes 32-bit LM counters, the X flag MUST be set
+ to 0.
+
+ 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.
+
+ In the case of a fatal exception that prevents the requested
+ measurement from being made, the error SHOULD be reported, via either
+ a response, if one was requested, or else as a notification to the
+ user.
+
+4.2.4. Transmitting a Loss Measurement Response
+
+ When constructing a Response to an LM Query, the Version field MUST
+ be set to 0. The R flag MUST be set to 1. The value of the T flag
+ MUST be copied from the LM Query.
+
+
+
+
+Frost & Bryant Standards Track [Page 35]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ The X flag MUST be set to 0 if the transmitting interface writes
+ 32-bit LM counters; otherwise, its value MUST be copied from the LM
+ Query. The B flag MUST be copied from the LM Query.
+
+ The Session Identifier, Origin Timestamp, and Origin Timestamp Format
+ fields MUST be copied from the LM Query. The Counter 1 and Counter 2
+ fields from the LM Query MUST be copied to the Counter 3 and Counter
+ 4 fields, respectively, of the LM Response.
+
+ The Control Code field MUST be set to one of the values for Response
+ messages listed in Section 3.1. The value 0x10 (Unspecified Error)
+ SHOULD NOT be used if one of the other more specific error codes is
+ applicable.
+
+ If the response is transmitted in-band, the Counter 1 field SHOULD be
+ set to the total count of units transmitted over the channel prior to
+ this LM Response. If the response is transmitted out-of-band, the
+ Counter 1 field MUST be set to 0. In either case, the Counter 2
+ field MUST be set to 0.
+
+4.2.5. Receiving a Loss Measurement Response
+
+ Upon in-band receipt of an LM Response message, the Counter 2 field
+ is set to the total count of units received over the channel prior to
+ this LM Response. If the receiving interface writes 32-bit LM
+ counters, the X flag is set to 0. (Since the life of the LM message
+ in the network has ended at this point, it is up to the receiver
+ whether these final modifications are made to the packet. If the
+ message is to be forwarded on for external post-processing
+ (Section 2.9.7), then these modifications MUST be made.)
+
+ 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.
+
+ If the Control Code in an LM Response is anything other than 0x1
+ (Success), the counter values in the response MUST NOT be used for
+ purposes of loss measurement. If the Control Code indicates an error
+ condition, or if the response message is invalid, the LM operation
+ MUST be terminated and an appropriate notification to the user
+ generated.
+
+4.2.6. Loss Calculation
+
+ Calculation of packet loss is carried out according to the procedures
+ in Section 2.2. 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
+
+
+
+Frost & Bryant Standards Track [Page 36]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+ Note that the semantics of the X flag allow all devices to
+ interoperate regardless of their counter size support. Thus, an
+ implementation MUST NOT generate an error response based on the value
+ of this flag.
+
+4.2.7. Quality of Service
+
+ The TC field of the LSE corresponding to the channel (e.g., LSP)
+ being measured SHOULD be set to a traffic class equal to or better
+ than the best TC within the measurement scope to minimize the chance
+ of out-of-order conditions.
+
+4.2.8. G-ACh Packets
+
+ By default, direct LM MUST exclude packets transmitted and received
+ over the Generic Associated Channel (G-ACh). An implementation MAY
+ provide the means to alter the direct LM scope to include some or all
+ G-ACh messages. Care must be taken when altering the LM scope to
+ ensure that both endpoints are in agreement.
+
+4.2.9. Test Messages
+
+ In the case of inferred LM, the packets counted for LM consist of
+ test messages generated for this purpose, or of some other class of
+ packets deemed to provide a good proxy for data packets flowing over
+ the channel. The specification of test protocols and proxy packets
+ is outside the scope of this document, but some guidelines are
+ discussed below.
+
+ An identifier common to both the test or proxy messages and the LM
+ messages may be required to make correlation possible. The combined
+ value of the Session Identifier and DS fields SHOULD be used for this
+ purpose when possible. That is, test messages in this case will
+ include a 32-bit field that can carry the value of the combined
+ Session Identifier + DS field present in LM messages. When TC-
+ specific LM is conducted, the DS field of the LSE in the label stack
+ of a test message corresponding to the channel (e.g., LSP) over which
+ the message is sent MUST correspond to the DS value in the associated
+ LM messages.
+
+ A separate test message protocol SHOULD include a timeout value in
+ its messages that informs the responder when to discard any state
+ associated with a specific test.
+
+
+
+Frost & Bryant Standards Track [Page 37]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+4.2.10. Message Loss and Packet Misorder Conditions
+
+ Because an LM operation consists of a message sequence with state
+ maintained from one message to the next, LM is subject to the effects
+ of lost messages and misordered packets in a way that DM is not.
+ Because this state exists only on the querier, the handling of these
+ conditions is, strictly speaking, a local matter. This section,
+ however, presents recommended procedures for handling such
+ conditions. Note that in the absence of ECMP, packet misordering
+ within a traffic class is a relatively rare event.
+
+ 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 Section 2.2. Whether this is
+ so depends on the number of messages lost and the other variables
+ mentioned in that section, such as the LM message rate and the
+ channel parameters.
+
+ 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.
+
+ 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.
+
+ An implementation SHOULD identify a threshold value that indicates
+ the upper bound of lost packets measured in a single computation
+ beyond which the interval is considered unmeasurable. This is called
+ the "MaxLMIntervalLoss threshold". It is clear that this threshold
+ should be no higher than the maximum number of packets (or bytes) the
+ channel is capable of transmitting over the interval, but it may be
+ lower. Upon encountering an unmeasurable interval, the LM state
+ (i.e., data values from the last LM message received) SHOULD be
+ discarded.
+
+ With regard to lost LM messages, the MaxLMInterval (see Section 2.2)
+ indicates the maximum amount of time that can elapse before the LM
+ state is discarded. If some messages are lost, but a message is
+
+
+
+Frost & Bryant Standards Track [Page 38]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ subsequently received within MaxLMInterval, its timestamp or sequence
+ number will quantify the loss, and it MAY still be used for
+ measurement, although the measurement interval will in this case be
+ longer than usual.
+
+ If an LM message is received that has a timestamp less than or equal
+ to the timestamp of the last LM message received, this indicates that
+ an exception has occurred, and the current interval SHOULD be
+ considered unmeasurable unless the implementation has some other way
+ of handling this condition.
+
+4.3. Delay Measurement Procedures
+
+4.3.1. Transmitting a Delay Measurement Query
+
+ When transmitting a DM Query, the Version and Reserved fields MUST be
+ set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1,
+ and the remaining flag bits MUST be set to 0.
+
+ The Control Code field MUST be set to one of the values for Query
+ messages listed in Section 3.1; if the channel is unidirectional,
+ this field MUST NOT be set to 0x0 (Query: In-band Response
+ Requested).
+
+ 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
+ Section 3.4. The Responder Timestamp Format and Responder's
+ Preferred Timestamp Format fields MUST be set to 0.
+
+ The Session Identifier field can be set arbitrarily. The DS field
+ MUST be set to the traffic class being measured.
+
+ The Timestamp 1 field SHOULD be set to the time at which this DM
+ Query is transmitted, in the format indicated by the Querier
+ Timestamp Format field. The Timestamp 2 field MUST be set to 0. If
+ a response was previously received in this measurement session, the
+ Timestamp 1 and Timestamp 2 fields of the most recent such response
+ MAY be copied to the Timestamp 3 and Timestamp 4 fields,
+ respectively, of this query; otherwise, the Timestamp 3 and Timestamp
+ 4 fields MUST be set to 0.
+
+4.3.2. Receiving a Delay Measurement Query
+
+ Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be
+ set to the time at which this DM Query was received.
+
+
+
+
+
+Frost & Bryant Standards Track [Page 39]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+ In the case of a fatal exception that prevents the requested
+ measurement from being made, the error SHOULD be reported, via either
+ a response, if one was requested, or else as a notification to the
+ user.
+
+4.3.3. Transmitting a Delay Measurement Response
+
+ When constructing a Response to a DM Query, the Version and Reserved
+ fields MUST be set to 0. The R flag MUST be set to 1, the T flag
+ MUST be set to 1, and the remaining flag bits MUST be set to 0.
+
+ 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.
+
+ 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 Section 3.4.
+ Furthermore, the RTF field MUST be set equal to either the QTF or the
+ RPTF field. See Section 4.3.5 for guidelines on the selection of the
+ value for this field.
+
+ The Responder's Preferred Timestamp Format (RPTF) field MUST be set
+ to one of the values listed in Section 3.4 and SHOULD be set to
+ indicate the timestamp format with which the responder can provide
+ the best accuracy for purposes of delay measurement.
+
+ The Control Code field MUST be set to one of the values for Response
+ messages listed in Section 3.1. The value 0x10 (Unspecified Error)
+ SHOULD NOT be used if one of the other more specific error codes is
+ applicable.
+
+ 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.
+
+
+
+
+
+Frost & Bryant Standards Track [Page 40]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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.
+
+4.3.4. Receiving a Delay Measurement Response
+
+ Upon in-band receipt of a DM Response message, the Timestamp 2 field
+ is set to the time at which this DM Response was received. (Since
+ the life of the DM message in the network has ended at this point, it
+ is up to the receiver whether this final modification is made to the
+ packet. If the message is to be forwarded on for external post-
+ processing (Section 2.9.7), then these modifications MUST be made.)
+
+ 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.
+
+ If the Control Code in a DM Response is anything other than 0x1
+ (Success), the timestamp values in the response MUST NOT be used for
+ purposes of delay measurement. If the Control Code indicates an
+ error condition, or if the response message is invalid, the DM
+ operation MUST be terminated and an appropriate notification to the
+ user generated.
+
+4.3.5. Timestamp Format Negotiation
+
+ In case either the querier or the responder in a DM transaction is
+ capable of supporting multiple timestamp formats, it is desirable to
+ determine the optimal format for purposes of delay measurement on a
+ particular channel. The procedures for making this determination
+ SHALL be as follows.
+
+ Upon sending an initial DM Query over a channel, the querier sets the
+ Querier Timestamp Format (QTF) field to its preferred timestamp
+ format.
+
+ 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.
+
+ 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,
+
+
+
+
+
+Frost & Bryant Standards Track [Page 41]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ 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).
+
+ 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.
+
+4.3.5.1. Single-Format Procedures
+
+ When an implementation supports only one timestamp format, the
+ procedures above reduce to the following simple behavior:
+
+ o All DM Queries are transmitted with the same QTF;
+
+ o All DM Responses are transmitted with the same RTF, and the RPTF
+ is always set equal to the RTF;
+
+ o All DM Responses received with RTF not equal to QTF are discarded;
+
+ o On a unidirectional channel, all DM Queries received with QTF not
+ equal to the supported format are discarded.
+
+4.3.6. Quality of Service
+
+ The TC field of the LSE corresponding to the channel (e.g., LSP)
+ being measured MUST be set to the value that corresponds to the DS
+ field in the DM message.
+
+4.4. Combined Loss/Delay Measurement Procedures
+
+ The combined LM/DM message defined in Section 3.3 allows loss and
+ delay measurement to be carried out simultaneously. This message
+ SHOULD be treated as an LM message that happens to carry additional
+ timestamp data, with the timestamp fields processed as per delay
+ measurement procedures.
+
+5. Implementation Disclosure Requirements
+
+ This section summarizes the requirements placed on implementations
+ for capabilities disclosure. The purpose of these requirements is to
+ ensure that end users have a clear understanding of implementation
+
+
+
+
+
+Frost & Bryant Standards Track [Page 42]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ capabilities and characteristics that have a direct impact on how
+ loss and delay measurement mechanisms function in specific
+ situations. Implementations are REQUIRED to state:
+
+ o METRICS: Which of the following metrics are supported: packet
+ loss, packet throughput, octet loss, octet throughput, average
+ loss rate, one-way delay, round-trip delay, two-way channel delay,
+ packet delay variation.
+
+ o MP-LOCATION: The location of loss and delay measurement points
+ with respect to other stages of packet processing, such as
+ queuing.
+
+ o CHANNEL-TYPES: The types of channels for which LM and DM are
+ supported, including LSP types, pseudowires, and sections (links).
+
+ o QUERY-RATE: The minimum supported query intervals for LM and DM
+ sessions, both in the querier and responder roles.
+
+ o LOOP: Whether loopback measurement (Section 2.8) is supported.
+
+ o LM-TYPES: Whether direct or inferred LM is supported, and for the
+ latter, which test protocols or proxy message types are supported.
+
+ o LM-COUNTERS: Whether 64-bit counters are supported.
+
+ o LM-ACCURACY: The expected measurement accuracy levels for the
+ supported forms of LM, and the expected impact of exception
+ conditions such as lost and misordered messages.
+
+ o LM-SYNC: The implementation's behavior in regard to the
+ synchronization conditions discussed in Section 2.9.8.
+
+ o LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
+
+ o DM-ACCURACY: The expected measurement accuracy levels for the
+ supported forms of DM.
+
+ o DM-TS-FORMATS: The supported timestamp formats and the extent of
+ support for computation with and reconciliation of different
+ formats.
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 43]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+6. Congestion Considerations
+
+ An MPLS network may be traffic-engineered in such a way that the
+ bandwidth required both for client traffic and for control,
+ management, and OAM traffic is always available. The following
+ congestion considerations therefore apply only when this is not the
+ case.
+
+ The proactive generation of Loss Measurement and Delay Measurement
+ messages for purposes of monitoring the performance of an MPLS
+ channel naturally results in a degree of additional load placed on
+ both the network and the terminal nodes of the channel. When
+ configuring such monitoring, operators should be mindful of the
+ overhead involved and should choose transmit rates that do not stress
+ network resources unduly; such choices must be informed by the
+ deployment context. In case of slower links or lower-speed devices,
+ for example, lower Loss Measurement message rates can be chosen, up
+ to the limits noted at the end of Section 2.2.
+
+ In general, lower measurement message rates place less load on the
+ network at the expense of reduced granularity. For delay
+ measurement, this reduced granularity translates to a greater
+ possibility that the delay associated with a channel temporarily
+ exceeds the expected threshold without detection. For loss
+ measurement, it translates to a larger gap in loss information in
+ case of exceptional circumstances such as lost LM messages or
+ misordered packets.
+
+ When carrying out a sustained measurement operation such as an LM
+ operation or continuous proactive 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.
+
+ 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.
+
+7. Manageability Considerations
+
+ The measurement protocols described in this document are intended to
+ serve as infrastructure to support a wide range of higher-level
+ monitoring and diagnostic applications, from simple command-line
+
+
+
+Frost & Bryant Standards Track [Page 44]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ diagnostic tools to comprehensive network performance monitoring and
+ analysis packages. The specific mechanisms and considerations for
+ protocol configuration, initialization, and reporting thus depend on
+ the nature of the application.
+
+ In the case of on-demand diagnostics, the diagnostic application may
+ provide parameters such as the measurement type, the channel, the
+ query rate, and the test duration when initiating the diagnostic;
+ results and exception conditions are then reported directly to the
+ application. The system may discard the statistics accumulated
+ during the test after the results have been reported or retain them
+ to provide a historical measurement record.
+
+ Alternatively, measurement configuration may be supplied as part of
+ the channel configuration itself in order to support continuous
+ monitoring of the channel's performance characteristics. In this
+ case, the configuration will typically include quality thresholds
+ depending on the service level agreement, the crossing of which will
+ trigger warnings or alarms, and result reporting and exception
+ notification will be integrated into the system-wide network
+ management and reporting framework.
+
+8. Security Considerations
+
+ This document describes procedures for the measurement of performance
+ metrics over a pre-existing MPLS path (a pseudowire, LSP, or
+ section). As such, it assumes that a node involved in a measurement
+ operation has previously verified the integrity of the path and the
+ identity of the far end using existing MPLS mechanisms such as
+ Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
+ techniques, and considerations for securing MPLS paths are discussed
+ in detail in [RFC5920].
+
+ When such mechanisms are not available, and where security of the
+ measurement operation is a concern, reception of Generic Associated
+ Channel messages with the Channel Types specified in this document
+ SHOULD be disabled. Implementations MUST provide the ability to
+ disable these protocols on a per-Channel-Type basis.
+
+ Even when the identity of the far end has been verified, the
+ measurement protocols remain vulnerable to injection and man-in-the-
+ middle attacks. The impact of such an attack would be to compromise
+ the quality of performance measurements on the affected path. An
+ attacker positioned to disrupt these measurements is, however,
+ capable of causing much greater damage by disrupting far more
+ critical elements of the network such as the network control plane or
+ user traffic flows. At worst, a disruption of the measurement
+ protocols would interfere with the monitoring of the performance
+
+
+
+Frost & Bryant Standards Track [Page 45]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ aspects of the service level agreement associated with the path; the
+ existence of such a disruption would imply that a serious breach of
+ basic path integrity had already occurred.
+
+ If desired, such attacks can be mitigated by performing basic
+ validation and sanity checks, at the querier, of the counter or
+ timestamp fields in received measurement response messages. The
+ minimal state associated with these protocols also limits the extent
+ of measurement disruption that can be caused by a corrupt or invalid
+ message to a single query/response cycle.
+
+ Cryptographic mechanisms capable of signing or encrypting the
+ contents of the measurement packets without degrading the measurement
+ performance are not currently available. In light of the preceding
+ discussion, the absence of such cryptographic mechanisms does not
+ raise significant security issues.
+
+ Users concerned with the security of out-of-band responses over IP
+ networks SHOULD employ suitable security mechanisms such as IPsec
+ [RFC4301] to protect the integrity of the return path.
+
+9. IANA Considerations
+
+ Per this document, IANA has completed the following actions:
+
+ o Allocation of Channel Types in the "PW Associated Channel Type"
+ registry
+
+ o Creation of a "Measurement Timestamp Type" registry
+
+ o Creation of an "MPLS Loss/Delay Measurement Control Code" registry
+
+ o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value
+ (TLV) Object" registry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 46]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+9.1. Allocation of PW Associated Channel Types
+
+ As per the IANA considerations in [RFC5586], IANA has allocated the
+ following Channel Types in the "PW Associated Channel Type" registry:
+
+ Value Description TLV Follows Reference
+ ------ ---------------------------------------- ----------- ---------
+ 0x000A MPLS Direct Loss Measurement (DLM) No RFC 6374
+ 0x000B MPLS Inferred Loss Measurement (ILM) No RFC 6374
+ 0x000C MPLS Delay Measurement (DM) No RFC 6374
+ 0x000D MPLS Direct Loss and Delay Measurement No RFC 6374
+ (DLM+DM)
+ 0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374
+ (ILM+DM)
+
+9.2. Creation of Measurement Timestamp Type Registry
+
+ IANA has created a new "Measurement Timestamp Type" registry, with
+ format and initial allocations as follows:
+
+ Type Description Size in Bits Reference
+ ---- ----------------------------------------- ------------ ---------
+ 0 Null Timestamp 64 RFC 6374
+ 1 Sequence Number 64 RFC 6374
+ 2 Network Time Protocol version 4 64-bit 64 RFC 6374
+ Timestamp
+ 3 Truncated IEEE 1588v2 PTP Timestamp 64 RFC 6374
+
+ The range of the Type field is 0-15.
+
+ The allocation policy for this registry is IETF Review.
+
+9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry
+
+ IANA has created a new "MPLS Loss/Delay Measurement Control Code"
+ registry. This registry is divided into two separate parts, one for
+ Query Codes and the other for Response Codes, with formats and
+ initial allocations as follows:
+
+ Query Codes
+
+ Code Description Reference
+ ---- ------------------------------ ---------
+ 0x0 In-band Response Requested RFC 6374
+ 0x1 Out-of-band Response Requested RFC 6374
+ 0x2 No Response Requested RFC 6374
+
+
+
+
+
+Frost & Bryant Standards Track [Page 47]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ Response Codes
+
+ Code Description Reference
+ ---- ----------------------------------- ---------
+ 0x0 Reserved RFC 6374
+ 0x1 Success RFC 6374
+ 0x2 Data Format Invalid RFC 6374
+ 0x3 Initialization in Progress RFC 6374
+ 0x4 Data Reset Occurred RFC 6374
+ 0x5 Resource Temporarily Unavailable RFC 6374
+ 0x10 Unspecified Error RFC 6374
+ 0x11 Unsupported Version RFC 6374
+ 0x12 Unsupported Control Code RFC 6374
+ 0x13 Unsupported Data Format RFC 6374
+ 0x14 Authentication Failure RFC 6374
+ 0x15 Invalid Destination Node Identifier RFC 6374
+ 0x16 Connection Mismatch RFC 6374
+ 0x17 Unsupported Mandatory TLV Object RFC 6374
+ 0x18 Unsupported Query Interval RFC 6374
+ 0x19 Administrative Block RFC 6374
+ 0x1A Resource Unavailable RFC 6374
+ 0x1B Resource Released RFC 6374
+ 0x1C Invalid Message RFC 6374
+ 0x1D Protocol Error RFC 6374
+
+ IANA has indicated that the values 0x0 - 0xF in the Response Code
+ section are reserved for non-error response codes.
+
+ The range of the Code field is 0 - 255.
+
+ The allocation policy for this registry is IETF Review.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 48]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry
+
+ IANA has created a new "MPLS Loss/Delay Measurement TLV Object"
+ registry, with format and initial allocations as follows:
+
+ Type Description Reference
+ ---- --------------------------------- ---------
+ 0 Padding - copy in response RFC 6374
+ 1 Return Address RFC 6374
+ 2 Session Query Interval RFC 6374
+ 3 Loopback Request RFC 6374
+ 127 Experimental use RFC 6374
+ 128 Padding - do not copy in response RFC 6374
+ 129 Destination Address RFC 6374
+ 130 Source Address RFC 6374
+ 255 Experimental use RFC 6374
+
+ IANA has indicated that Types 0-127 are classified as Mandatory, and
+ that Types 128-255 are classified as Optional.
+
+ The range of the Type field is 0 - 255.
+
+ The allocation policy for this registry is IETF Review.
+
+10. Acknowledgments
+
+ The authors wish to thank the many participants of the MPLS working
+ group who provided detailed review and feedback on this document.
+ The authors offer special thanks to Alexander Vainshtein, Loa
+ Andersson, and Hiroyuki Takagi for many helpful thoughts and
+ discussions, to Linda Dunbar for the idea of using LM messages for
+ throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and
+ Ben Mack-Crane for their valuable comments.
+
+11. References
+
+11.1. Normative References
+
+ [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
+ Synchronization Protocol for Networked Measurement and
+ Control Systems", March 2008.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 49]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+ "Definition of the Differentiated Services Field (DS
+ Field) in the IPv4 and IPv6 Headers", RFC 2474,
+ December 1998.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+ Label Switching Architecture", RFC 3031, January 2001.
+
+ [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
+ P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
+ Protocol Label Switching (MPLS) Support of Differentiated
+ Services", RFC 3270, May 2002.
+
+ [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
+ Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
+ to "Traffic Class" Field", RFC 5462, February 2009.
+
+ [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
+ Associated Channel", RFC 5586, June 2009.
+
+ [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch,
+ "Network Time Protocol Version 4: Protocol and Algorithms
+ Specification", RFC 5905, June 2010.
+
+11.2. Informative References
+
+ [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+ Delay Metric for IPPM", RFC 2679, September 1999.
+
+ [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+ Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+ [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
+ Delay Metric for IPPM", RFC 2681, September 1999.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+ [RFC3260] Grossman, D., "New Terminology and Clarifications for
+ Diffserv", RFC 3260, April 2002.
+
+ [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+ Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+
+
+
+Frost & Bryant Standards Track [Page 50]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+ [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
+ Zekauskas, "A One-way Active Measurement Protocol
+ (OWAMP)", RFC 4656, September 2006.
+
+ [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding
+ Equal Cost Multipath Treatment in MPLS Networks",
+ BCP 128, RFC 4928, June 2007.
+
+ [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
+ Specification", RFC 5036, October 2007.
+
+ [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
+ Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
+ RFC 5357, October 2008.
+
+ [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
+ Applicability Statement", RFC 5481, March 2009.
+
+ [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+ "Bidirectional Forwarding Detection (BFD) for MPLS Label
+ Switched Paths (LSPs)", RFC 5884, June 2010.
+
+ [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, July 2010.
+
+ [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
+ Berger, "A Framework for MPLS in Transport Networks",
+ RFC 5921, July 2010.
+
+ [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
+ Profile Data Plane Architecture", RFC 5960, August 2010.
+
+ [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
+ Delay Measurement Profile for MPLS-Based Transport
+ Networks", RFC 6375, September 2011.
+
+ [Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and
+ Mechanisms for Ethernet based Networks", February 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 51]
+
+RFC 6374 MPLS Loss and Delay Measurement September 2011
+
+
+Appendix A. Default Timestamp Format Rationale
+
+ This document initially proposed the Network Time Protocol (NTP)
+ timestamp format as the mandatory default, as this is the normal
+ default timestamp in IETF protocols and thus would seem the "natural"
+ choice. However, a number of considerations have led instead to the
+ specification of the truncated IEEE 1588 Precision Time Protocol
+ (PTP) timestamp as the default. NTP has not gained traction in
+ industry as the protocol of choice for high-quality timing
+ infrastructure, whilst IEEE 1588 PTP has become the de facto time
+ transfer protocol in networks that are specially engineered to
+ provide high-accuracy time distribution service. The PTP timestamp
+ format is also the ITU-T format of choice for packet transport
+ networks, which may rely on MPLS protocols. Applications such as
+ one-way delay measurement need the best time service available, and
+ converting between the NTP and PTP timestamp formats is not a trivial
+ transformation, particularly when it is required that this be done in
+ real time without loss of accuracy.
+
+ The truncated IEEE 1588 PTP format specified in this document is
+ considered to provide a more than adequate wrap time and greater time
+ resolution than it is expected will be needed for the operational
+ lifetime of this protocol. By truncating the timestamp at both the
+ high and low order bits, the protocol achieves a worthwhile reduction
+ in system resources.
+
+Authors' Addresses
+
+ Dan Frost
+ Cisco Systems
+
+ EMail: danfrost@cisco.com
+
+
+ Stewart Bryant
+ Cisco Systems
+
+ EMail: stbryant@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant Standards Track [Page 52]
+