draft-ietf-mpls-loss-delay-00.txt   draft-ietf-mpls-loss-delay-01.txt 
MPLS D. Frost, Ed. MPLS D. Frost
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: June 26, 2011 December 23, 2010 Expires: August 8, 2011 February 4, 2011
Packet Loss and Delay Measurement for MPLS Networks Packet Loss and Delay Measurement for MPLS Networks
draft-ietf-mpls-loss-delay-00 draft-ietf-mpls-loss-delay-01
Abstract Abstract
Many service provider service level agreements (SLAs) depend on the Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This capability, in delay variation and channel throughput. This measurement capability
addition, provides operators with greater visibility into the also provides operators with greater visibility into the performance
performance characteristics of their networks, thereby facilitating characteristics of their networks, thereby facilitating planning,
planning, troubleshooting, and evaluation. This document specifies troubleshooting, and evaluation. This document specifies protocol
protocol mechanisms to enable the efficient and accurate measurement mechanisms to enable the efficient and accurate measurement of these
of these performance metrics in MPLS networks. performance metrics in MPLS networks.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 26, 2011. This Internet-Draft will expire on August 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2.2. Throughput Measurement . . . . . . . . . . . . . . . . . . 9 2.2. Throughput Measurement . . . . . . . . . . . . . . . . . . 9
2.3. Delay Measurement . . . . . . . . . . . . . . . . . . . . 9 2.3. Delay Measurement . . . . . . . . . . . . . . . . . . . . 9
2.4. Delay Variation Measurement . . . . . . . . . . . . . . . 11 2.4. Delay Variation Measurement . . . . . . . . . . . . . . . 11
2.5. Unidirectional Measurement . . . . . . . . . . . . . . . . 11 2.5. Unidirectional Measurement . . . . . . . . . . . . . . . . 11
2.6. Loopback Measurement . . . . . . . . . . . . . . . . . . . 12 2.6. Loopback Measurement . . . . . . . . . . . . . . . . . . . 12
2.7. Measurement Considerations . . . . . . . . . . . . . . . . 12 2.7. Measurement Considerations . . . . . . . . . . . . . . . . 12
2.7.1. Types of Channels . . . . . . . . . . . . . . . . . . 12 2.7.1. Types of Channels . . . . . . . . . . . . . . . . . . 12
2.7.2. Quality of Service . . . . . . . . . . . . . . . . . . 12 2.7.2. Quality of Service . . . . . . . . . . . . . . . . . . 12
2.7.3. Equal Cost Multipath . . . . . . . . . . . . . . . . . 13 2.7.3. Equal Cost Multipath . . . . . . . . . . . . . . . . . 13
2.7.4. Intermediate Nodes . . . . . . . . . . . . . . . . . . 13 2.7.4. Intermediate Nodes . . . . . . . . . . . . . . . . . . 13
2.7.5. Distributed Systems . . . . . . . . . . . . . . . . . 14 2.7.5. Different Transmit and Receive Interfaces . . . . . . 14
2.7.6. Loss Measurement Modes . . . . . . . . . . . . . . . . 14 2.7.6. Loss Measurement Modes . . . . . . . . . . . . . . . . 14
2.7.7. Loss Measurement Scope . . . . . . . . . . . . . . . . 16 2.7.7. Loss Measurement Scope . . . . . . . . . . . . . . . . 16
2.7.8. Delay Measurement Accuracy . . . . . . . . . . . . . . 16 2.7.8. Delay Measurement Accuracy . . . . . . . . . . . . . . 16
2.7.9. Delay Measurement Timestamp Format . . . . . . . . . . 16 2.7.9. Delay Measurement Timestamp Format . . . . . . . . . . 16
3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Loss Measurement Message Format . . . . . . . . . . . . . 17 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 17
3.2. Delay Measurement Message Format . . . . . . . . . . . . . 22 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 22
3.3. Combined Loss/Delay Measurement Message Format . . . . . . 24 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 24
3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 25 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 25
3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 27 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 27 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 27
3.5.3. Session Query Interval . . . . . . . . . . . . . . . . 28
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Loss Measurement Procedures . . . . . . . . . . . . . . . 28 4.1. Loss Measurement Procedures . . . . . . . . . . . . . . . 28
4.1.1. Initiating a Loss Measurement Operation . . . . . . . 28 4.1.1. Initiating a Loss Measurement Operation . . . . . . . 28
4.1.2. Transmitting a Loss Measurement Query . . . . . . . . 29 4.1.2. Transmitting a Loss Measurement Query . . . . . . . . 29
4.1.3. Receiving a Loss Measurement Query . . . . . . . . . . 29 4.1.3. Receiving a Loss Measurement Query . . . . . . . . . . 30
4.1.4. Transmitting a Loss Measurement Response . . . . . . . 30 4.1.4. Transmitting a Loss Measurement Response . . . . . . . 30
4.1.5. Receiving a Loss Measurement Response . . . . . . . . 30 4.1.5. Receiving a Loss Measurement Response . . . . . . . . 31
4.1.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 31 4.1.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 31
4.1.7. Quality of Service . . . . . . . . . . . . . . . . . . 31 4.1.7. Quality of Service . . . . . . . . . . . . . . . . . . 31
4.1.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 31 4.1.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 31
4.1.9. Test Messages . . . . . . . . . . . . . . . . . . . . 31 4.1.9. Test Messages . . . . . . . . . . . . . . . . . . . . 32
4.1.10. Message Loss and Packet Misorder Conditions . . . . . 32 4.1.10. Message Loss and Packet Misorder Conditions . . . . . 32
4.2. Delay Measurement Procedures . . . . . . . . . . . . . . . 33 4.2. Delay Measurement Procedures . . . . . . . . . . . . . . . 33
4.2.1. Transmitting a Delay Measurement Query . . . . . . . . 33 4.2.1. Transmitting a Delay Measurement Query . . . . . . . . 33
4.2.2. Receiving a Delay Measurement Query . . . . . . . . . 33 4.2.2. Receiving a Delay Measurement Query . . . . . . . . . 34
4.2.3. Transmitting a Delay Measurement Response . . . . . . 34 4.2.3. Transmitting a Delay Measurement Response . . . . . . 34
4.2.4. Receiving a Delay Measurement Response . . . . . . . . 34 4.2.4. Receiving a Delay Measurement Response . . . . . . . . 35
4.2.5. Timestamp Format Negotiation . . . . . . . . . . . . . 35 4.2.5. Timestamp Format Negotiation . . . . . . . . . . . . . 35
4.2.6. Quality of Service . . . . . . . . . . . . . . . . . . 36 4.2.6. Quality of Service . . . . . . . . . . . . . . . . . . 36
4.3. Combined Loss/Delay Measurement Procedures . . . . . . . . 36 4.3. Combined Loss/Delay Measurement Procedures . . . . . . . . 36
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 36 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Allocation of PW Associated Channel Types . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.2. Creation of Measurement Timestamp Type Registry . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 7.3. Creation of MPLS Loss/Delay Measurement Control Code
9.2. Informative References . . . . . . . . . . . . . . . . . . 38 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 7.4. Creation of MPLS Loss/Delay Measurement TLV Object
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
Many service provider service level agreements (SLAs) depend on the Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This capability, in delay variation and channel throughput. This measurement capability
addition, provides operators with greater visibility into the also provides operators with greater visibility into the performance
performance characteristics of their networks, thereby facilitating characteristics of their networks, thereby facilitating planning,
planning, troubleshooting, and evaluation. This document specifies troubleshooting, and evaluation. This document specifies protocol
protocol mechanisms to enable the efficient and accurate measurement mechanisms to enable the efficient and accurate measurement of these
of these performance metrics in MPLS networks. performance metrics in MPLS networks.
This document specifies two closely-related protocols, one for packet This document specifies two closely-related protocols, one for packet
loss measurement (LM) and one for packet delay measurement (DM). loss measurement (LM) and one for packet delay measurement (DM).
These protocols have the following characteristics and capabilities: These protocols have the following characteristics and capabilities:
o The LM and DM protocols are intended to be simple and to support o The LM and DM protocols are intended to be simple and to support
efficient hardware processing. efficient hardware processing.
o The LM and DM protocols operate over the MPLS Generic Associated o The LM and DM protocols operate over the MPLS Generic Associated
Channel (G-ACh) [RFC5586] and support measurement of loss and Channel (G-ACh) [RFC5586] and support measurement of loss, delay,
delay over Label Switched Paths (LSPs), pseudowires, and MPLS and related metrics over Label Switched Paths (LSPs), pseudowires,
sections (links). and MPLS sections (links).
o The LM and DM protocols are applicable to the LSPs, pseudowires, o The LM and DM protocols are applicable to the LSPs, pseudowires,
and sections of networks based on the MPLS Transport Profile and sections of networks based on the MPLS Transport Profile
(MPLS-TP), because the MPLS-TP is based on a standard MPLS data (MPLS-TP), because the MPLS-TP is based on a standard MPLS data
plane. The MPLS-TP is defined and described in [RFC5921], and plane. The MPLS-TP is defined and described in [RFC5921], and
MPLS-TP LSPs, pseudowires, and sections are discussed in detail in MPLS-TP LSPs, pseudowires, and sections are discussed in detail in
[RFC5960]. [RFC5960].
o The LM and DM protocols can be used for both continuous/proactive o The LM and DM protocols can be used for both continuous/proactive
and selective/on-demand measurement. and selective/on-demand measurement.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
a simple means for the two endpoints of a bidirectional connection a simple means for the two endpoints of a bidirectional connection
to agree on a preferred format. This procedure reduces to a to agree on a preferred format. This procedure reduces to a
triviality for implementations supporting only a single timestamp triviality for implementations supporting only a single timestamp
format. format.
o The DM protocol supports varying the measurement message size in o The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes. order to measure delays associated with different packet sizes.
1.1. Terminology 1.1. Terminology
Term Definition Term Definition
------- ------------------------------------------- ----- -------------------------------------------
ACH Associated Channel Header ACH Associated Channel Header
DM Delay Measurement DM Delay Measurement
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
LM Loss Measurement LM Loss Measurement
LSE Label Stack Entry LSE Label Stack Entry
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MPLS-TP MPLS Transport Profile NTP Network Time Protocol
NTP Network Time Protocol OAM Operations, Administration, and Maintenance
OAM Operations, Administration, and Maintenance PTP Precision Time Protocol
PTP Precision Time Protocol PW Pseudowire
PW Pseudowire TC Traffic Class
TC Traffic Class
2. Overview 2. Overview
This section begins with a summary of the basic methods used for the This section begins with a summary of the basic methods used for the
bidirectional measurement of packet loss and delay. These bidirectional measurement of packet loss and delay. These
measurement methods are then described in detail. Finally a list of measurement methods are then described in detail. Finally a list of
practical considerations are discussed that may come into play to practical considerations are discussed that may come into play to
inform or modify these simple procedures. inform or modify these simple procedures.
The following figure shows the reference scenario. The following figure shows the reference scenario.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
associated with the channel: associated with the channel:
o The one-way delay associated with the forward (A to B) direction o The one-way delay associated with the forward (A to B) direction
of the channel; of the channel;
o The one-way delay associated with the reverse (B to A) direction o The one-way delay associated with the reverse (B to A) direction
of the channel; of the channel;
o The two-way delay (A to B to A) associated with the channel. o The two-way delay (A to B to A) associated with the channel.
In the case of two-way delay, there are actually two possible metrics The one-way delay metric for packet networks is described in
of interest. The "strict" two-way delay is the sum of the one-way [RFC2679]. Measurement of the one-way delay quantities requires that
delays in each direction and reflects the two-way delay of the the clocks of A and B be synchronized, whereas the two-way delay can
channel itself, irrespective of processing delays within the remote be measured directly even when this is not the case (provided A and B
endpoint B. The "loose" two-way delay includes in addition any delay have stable clocks).
associated with remote endpoint processing.
Measurement of the one-way delay quantities requires that the clocks In the case of two-way delay, there are actually two possible metrics
of A and B be synchronized, whereas the two-way delay can be measured of interest. The "two-way channel delay" is the sum of the one-way
directly even when this is not the case (provided A and B have stable delays in each direction and reflects the delay of the channel
clocks). itself, irrespective of processing delays within the remote endpoint
B. The "round-trip delay" is described in [RFC2681] and includes in
addition any delay associated with remote endpoint processing.
The measurement is accomplished by sending a Delay Measurement (DM) A measurement is accomplished by sending a Delay Measurement (DM)
query message over the channel to B which contains the following query message over the channel to B which contains the following
timestamp: timestamp:
T1: the time the DM query message is transmitted from A. T1: the time the DM query message is transmitted from A.
When the message arrives at B, the following timestamp is recorded in When the message arrives at B, the following timestamp is recorded in
the message: the message:
T2: the time the DM query message is received at B. T2: the time the DM query message is received at B.
skipping to change at page 10, line 39 skipping to change at page 10, line 40
and transmits it back to A, recording within it the following and transmits it back to A, recording within it the following
timestamp: timestamp:
T3: the time the DM response message is transmitted from B. T3: the time the DM response message is transmitted from B.
When the message arrives back at A, the following timestamp is When the message arrives back at A, the following timestamp is
recorded in the message: recorded in the message:
T4: the time the DM response message is received back at A. T4: the time the DM response message is received back at A.
At this point, A can compute the strict two-way delay associated with At this point, A can compute the two-way channel delay associated
the channel as with the channel as
strict two-way delay = (T4 - T1) - (T3 - T2) two-way channel delay = (T4 - T1) - (T3 - T2)
and the loose two-way delay as and the round-trip delay as
loose two-way delay = T4 - T1. round-trip delay = T4 - T1.
If the clocks of A and B are known at A to be synchronized, then both If the clocks of A and B are known at A to be synchronized, then both
one-way delay values, as well as the strict two-way delay, can be one-way delay values, as well as the two-way channel delay, can be
computed at A as computed at A as
forward one-way delay = T2 - T1 forward one-way delay = T2 - T1
reverse one-way delay = T4 - T3 reverse one-way delay = T4 - T3
strict two-way delay = forward delay + reverse delay. two-way channel delay = forward delay + reverse delay.
2.4. Delay Variation Measurement 2.4. Delay Variation Measurement
Packet Delay Variation (PDV) [RFC3393] is another performance metric Packet Delay Variation (PDV) [RFC3393] is another performance metric
important in some applications. The PDV of a pair of packets within important in some applications. The PDV of a pair of packets within
a stream of packets is defined for a selected pair of packets in the a stream of packets is defined for a selected pair of packets in the
stream going from measurement point 1 to measurement point 2. The stream going from measurement point 1 to measurement point 2. The
PDV is the difference between the one-way delay of the selected PDV is the difference between the one-way delay of the selected
packets. packets.
skipping to change at page 12, line 16 skipping to change at page 12, line 16
Some bidirectional channels may be placed into a loopback state such Some bidirectional channels may be placed into a loopback state such
that query messages are looped back to the querier without that query messages are looped back to the querier without
modification. In this situation, LM and DM procedures can be used to modification. In this situation, LM and DM procedures can be used to
carry out measurements associated with the circular path. carry out measurements associated with the circular path.
For LM, the loss computation in this case is: 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]) A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
For DM, the loose two-way delay is computed. In this case, however, For DM, the round-trip delay is computed. In this case, however, the
the remote endpoint processing time component reflects only the time remote endpoint processing time component reflects only the time
required to loop the message from channel input to channel output. required to loop the message from channel input to channel output.
Query messages must include some form of source identifier in order Query messages must include some form of source identifier in order
for looped-back queries to be differentiated from queries initiated for looped-back queries to be differentiated from queries initiated
by the far end. by the far end.
2.7. Measurement Considerations 2.7. Measurement Considerations
A number of additional considerations apply in practice to the A number of additional considerations apply in practice to the
measurement methods summarized above. measurement methods summarized above.
skipping to change at page 14, line 17 skipping to change at page 14, line 17
the processing of the packet by the intermediate node occurs only as 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 the result of TTL expiry, and the handling of TTL expiry may occur at
a later processing stage in the implementation than the hardware- a later processing stage in the implementation than the hardware-
assisted measurement function. Often the motivation for conducting assisted measurement function. Often the motivation for conducting
measurements to intermediate nodes is an attempt to localize a measurements to intermediate nodes is an attempt to localize a
problem that has been detected on the LSP. In this case, if problem that has been detected on the LSP. In this case, if
intermediate nodes are not capable of performing hardware-assisted intermediate nodes are not capable of performing hardware-assisted
measurement, a less accurate - but usually sufficient - software- measurement, a less accurate - but usually sufficient - software-
based measurement can be conducted instead. based measurement can be conducted instead.
2.7.5. Distributed Systems 2.7.5. Different Transmit and Receive Interfaces
The overview of the bidirectional measurement process presented in The overview of the bidirectional measurement process presented in
Section 2 is also applicable when the transmit and receive interfaces Section 2 is also applicable when the transmit and receive interfaces
at A or B differ from one another. Some additional considerations, at A or B differ from one another. Some additional considerations,
however, do apply in this case: however, do apply in this case:
o If different clocks are associated with transmit and receive o If different clocks are associated with transmit and receive
processing, these clocks must be synchronized in order to compute processing, these clocks must be synchronized in order to compute
the two-way delay. the two-way delay.
skipping to change at page 18, line 12 skipping to change at page 18, line 12
The format of a Loss Measurement message, which follows the The format of a Loss Measurement message, which follows the
Associated Channel Header (ACH), is as follows: Associated Channel Header (ACH), is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| OTF | Reserved | | DFlags| OTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | TC | | Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Timestamp | | Origin Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 | | Counter 1 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
skipping to change at page 18, line 35 skipping to change at page 18, line 35
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Loss Measurement Message Format Figure 2: Loss Measurement Message Format
Reserved fields MUST be set to 0 and ignored upon receipt. The Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows. possible values for the remaining fields are as follows.
Field Meaning Field Meaning
------------------------- ------------------------------------------- --------------------- -----------------------------------------------
Version Protocol version Version Protocol version
Flags Message control flags Flags Message control flags
Control Code Code identifying the query or response type Control Code Code identifying the query or response type
Message Length Total length of this message in bytes Message Length Total length of this message in bytes
Data Format Flags Flags specifying the format of message data Data Format Flags Flags specifying the format of message data
(DFlags) (DFlags)
Origin Timestamp Format Format of the Origin Timestamp field Origin Timestamp Format of the Origin Timestamp field
(OTF) Format (OTF)
Reserved Reserved for future specification Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier Session Identifier Set arbitrarily by the querier
Traffic Class (TC) TC being measured Differentiated Differentiated Services Code Point (DSCP) being
Origin Timestamp Query message transmission timestamp Services (DS) Field measured
Counter 1-4 Packet counter values in network byte order
TLV Block Optional block of Type-Length-Value fields
Origin Timestamp Query message transmission timestamp
Counter 1-4 Packet counter values in network byte order
TLV Block Optional block of Type-Length-Value fields
The possible values for these fields are as follows. The possible values for these fields are as follows.
Version: Currently set to 0. Version: Currently set to 0.
Flags: The format of the Flags field is shown below. Flags: The format of the Flags field is shown below.
+-+-+-+-+ +-+-+-+-+
| Flags |
+-+-+-+-+
+-+-+-+-+
|R|T|0|0| |R|T|0|0|
+-+-+-+-+ +-+-+-+-+
Loss Measurement Message Flags Loss Measurement Message Flags
The meanings of the flag bits are: The meanings of the flag bits are:
R: Query/Response indicator. Set to 0 for a Query and 1 for a R: Query/Response indicator. Set to 0 for a Query and 1 for a
Response. Response.
T: Traffic-class-specific measurement indicator. Set to 1 when T: Traffic-class-specific measurement indicator. Set to 1 when
the measurement operation is scoped to packets of a particular the measurement operation is scoped to packets of a particular
traffic class, and 0 otherwise. When set to 1, the TC field of traffic class (DSCP value), and 0 otherwise. When set to 1, the
the message indicates the measured traffic class. DS field of the message indicates the measured traffic class.
0: Set to 0. 0: Set to 0.
Control Code: Set as follows according to whether the message is a Control Code: Set as follows according to whether the message is a
Query or a Response as identified by the R flag. Query or a Response as identified by the R flag.
For a Query: For a Query:
0x0: In-band Response Requested. Indicates that this query has 0x0: In-band Response Requested. Indicates that this query has
been sent over a bidirectional channel and the response is been sent over a bidirectional channel and the response is
skipping to change at page 21, line 5 skipping to change at page 20, line 49
0x16: Error - Connection Mismatch. Indicates that the 0x16: Error - Connection Mismatch. Indicates that the
operation failed because the channel identifier supplied in the operation failed because the channel identifier supplied in the
query did not match the channel over which the query was query did not match the channel over which the query was
received. received.
0x17: Error - Unsupported Mandatory TLV Object. Indicates that 0x17: Error - Unsupported Mandatory TLV Object. Indicates that
the operation failed because a TLV Object received in the query the operation failed because a TLV Object received in the query
and marked as mandatory is not supported. and marked as mandatory is not supported.
0x18: Error - Query Rate Exceeded. Indicates that the 0x18: Error - Unsupported Query Interval. Indicates that the
operation failed because the query message rate exceeded the operation failed because the query message rate exceeded the
configured threshold. configured threshold.
0x19: Error - Administrative Block. Indicates that the 0x19: Error - Administrative Block. Indicates that the
operation failed because it has been administratively operation failed because it has been administratively
disallowed. disallowed.
0x1A: Error - Temporary Resource Exhaustion. Indicates that 0x1A: Error - Temporary Resource Exhaustion. Indicates that
the operation failed because node resources were not available. the operation failed because node resources were not available.
Message Length: Set to the total length of this message in bytes. Message Length: Set to the total length of this message in bytes.
DFlags: The format of the DFlags field is shown below. DFlags: The format of the DFlags field is shown below.
+-+-+-+-+ +-+-+-+-+
| DFlags|
+-+-+-+-+
+-+-+-+-+
|X|B|0|0| |X|B|0|0|
+-+-+-+-+ +-+-+-+-+
Loss Measurement Message Flags Loss Measurement Message Flags
The meanings of the DFlags bits are: The meanings of the DFlags bits are:
X: Extended counter format indicator. Indicates the use of X: Extended counter format indicator. Indicates the use of
extended (64-bit) counter values. Initialized to 1 upon creation extended (64-bit) counter values. Initialized to 1 upon creation
(and prior to transmission) of an LM Query and copied from an LM (and prior to transmission) of an LM Query and copied from an LM
skipping to change at page 21, line 51 skipping to change at page 21, line 43
the Counter 1-4 fields represent packet counts. the Counter 1-4 fields represent packet counts.
0: Set to 0. 0: Set to 0.
Origin Timestamp Format: The format of the Origin Timestamp field, as Origin Timestamp Format: The format of the Origin Timestamp field, as
specified in Section 3.4. specified in Section 3.4.
Session Identifier: Set arbitrarily in a query and copied in the Session Identifier: Set arbitrarily in a query and copied in the
response, if any. response, if any.
TC: When the T flag is set to 1, this field is set to the TC being DS: When the T flag is set to 1, this field is set to the DSCP value
measured. When the T flag is set to 0, the value of this field is [RFC3260] that corresponds to the traffic class being measured. For
arbitrary, and the field can be considered part of the Session MPLS, where the traffic class of a channel is identified by the
Identifier. three-bit Traffic Class in the channel's LSE [RFC5462], this field
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 Origin Timestamp: Timestamp recording the transmit time of the query
message. message.
Counter 1-4: Referring to Section 2.1, when a query is sent from A, Counter 1-4: Referring to Section 2.1, when a query is sent from A,
Counter 1 is set to A_TxP and the other counter fields are set to 0. 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 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, 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 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 the response, Counter 1 is set to B_TxP. When the response is
skipping to change at page 23, line 12 skipping to change at page 23, line 12
The format of a Delay Measurement message, which follows the The format of a Delay Measurement message, which follows the
Associated Channel Header (ACH), is as follows: Associated Channel Header (ACH), is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved | | QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | TC | | Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 | | Timestamp 1 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 | | Timestamp 4 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Delay Measurement Message Format Figure 3: Delay Measurement Message Format
The meanings of the fields are summarized in the following table. The meanings of the fields are summarized in the following table.
Field Meaning Field Meaning
--------------------- ------------------------------------------- --------------------- -----------------------------------------------
Version Protocol version Version Protocol version
Flags Message control flags Flags Message control flags
Control Code Code identifying the query or response type Control Code Code identifying the query or response type
Message Length Total length of this message in bytes Message Length Total length of this message in bytes
QTF Querier timestamp format QTF Querier timestamp format
RTF Responder timestamp format RTF Responder timestamp format
RPTF Responder's preferred timestamp format RPTF Responder's preferred timestamp format
Reserved Reserved for future specification Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier Session Identifier Set arbitrarily by the querier
Traffic Class (TC) TC being measured Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Timestamp 1-4 64-bit timestamp values Timestamp 1-4 64-bit timestamp values
TLV Block Optional block of Type-Length-Value fields TLV Block Optional block of Type-Length-Value fields
Reserved fields MUST be set to 0 and ignored upon receipt. The Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows. possible values for the remaining fields are as follows.
Version: Currently set to 0. Version: Currently set to 0.
Flags: As specified in Section 3.1, except for the X flag, which is Flags: As specified in Section 3.1, except for the X flag, which is
set to 0, and the T flag, which is set to 1. set to 0, and the T flag, which is set to 1.
skipping to change at page 24, line 20 skipping to change at page 24, line 23
by the querier, as specified in Section 3.4. by the querier, as specified in Section 3.4.
Responder Timestamp Format: The format of the timestamp values Responder Timestamp Format: The format of the timestamp values
written by the responder, as specified in Section 3.4. written by the responder, as specified in Section 3.4.
Responder's Preferred Timestamp Format: The timestamp format Responder's Preferred Timestamp Format: The timestamp format
preferred by the responder, as specified in Section 3.4. preferred by the responder, as specified in Section 3.4.
Session Identifier: As specified in Section 3.1. Session Identifier: As specified in Section 3.1.
TC: Set to the TC being measured. DS: As specified in Section 3.1.
Timestamp 1-4: Referring to Section 2.3, when a query is sent from A, Timestamp 1-4: Referring to Section 2.3, when a query is sent from A,
Timestamp 1 is set to T1 and the other timestamp fields are set to 0. 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 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 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to
Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. 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 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 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 formats of the timestamp fields written by A and B are indicated by
the Querier Timestamp Format and Responder Timestamp Format fields the Querier Timestamp Format and Responder Timestamp Format fields
skipping to change at page 25, line 12 skipping to change at page 25, line 12
The format of a combined Loss and Delay Measurement message, which The format of a combined Loss and Delay Measurement message, which
follows the Associated Channel Header (ACH), is as follows: follows the Associated Channel Header (ACH), is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| QTF | RTF | RPTF | Reserved | | DFlags| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | TC | | Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 | | Timestamp 1 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 | | Timestamp 4 |
| | | |
skipping to change at page 25, line 47 skipping to change at page 25, line 47
Figure 4: Loss/Delay Measurement Message Format Figure 4: Loss/Delay Measurement Message Format
The LM/DM message fields have the same meanings as the corresponding The LM/DM message fields have the same meanings as the corresponding
fields in the LM and DM message formats. fields in the LM and DM message formats.
3.4. Timestamp Field Formats 3.4. Timestamp Field Formats
The following timestamp format field values are specified in this The following timestamp format field values are specified in this
document: document:
0x0: Null timestamp format. This value is a placeholder 0: Null timestamp format. This value is a placeholder indicating
indicating that the timestamp field does not contain a meaningful that the timestamp field does not contain a meaningful timestamp.
timestamp.
0x1: Sequence number. This value indicates that the timestamp 1: Sequence number. This value indicates that the timestamp field
field is to be viewed as a simple 64-bit sequence number. is to be viewed as a simple 64-bit sequence number.
0x2: Network Time Protocol version 4 64-bit timestamp format 2: Network Time Protocol version 4 64-bit timestamp format
[RFC5905]. This format consists of a 32-bit seconds field [RFC5905]. This format consists of a 32-bit seconds field
followed by a 32-bit fractional seconds field, so that it can be followed by a 32-bit fractional seconds field, so that it can be
regarded as a fixed-point 64-bit quantity. regarded as a fixed-point 64-bit quantity.
0x3: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp 3: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp
format [IEEE1588]. This format consists of a 32-bit seconds field format [IEEE1588]. This format consists of a 32-bit seconds field
followed by a 32-bit nanoseconds field. followed by a 32-bit nanoseconds field.
In recognition of the wide deployment, particularly in hardware-based In recognition of the wide deployment, particularly in hardware-based
timing implementations, of IEEE 1588 PTP, the PTP timestamp format is timing implementations, of IEEE 1588 PTP, the PTP timestamp format is
the default format used in Delay Measurement messages. This format the default format used in Delay Measurement messages. This format
MUST be supported. Support for other timestamp formats is OPTIONAL. MUST be supported. Support for other timestamp formats is OPTIONAL.
Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- 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- bit timestamp fields specified in this document using the n high-
skipping to change at page 27, line 12 skipping to change at page 27, line 12
TLV object, the recipient MUST discard the message or respond with an TLV object, the recipient MUST discard the message or respond with an
appropriate error code. appropriate error code.
The types defined are as follows: The types defined are as follows:
Type Definition Type Definition
-------------- --------------------------------- -------------- ---------------------------------
Mandatory Mandatory
0 Padding - copy in response 0 Padding - copy in response
1 Return Address 1 Return Address
2-119 Reserved 2 Session Query Interval
120-127 Vendor-specific usage 3-119 Reserved
120-127 Implementation-specific usage
Optional Optional
128 Padding - do not copy in response 128 Padding - do not copy in response
129 Destination Address 129 Destination Address
130 Source Address 130 Source Address
131-247 Reserved 131-247 Reserved
248-255 Vendor-specific usage 248-255 Implementation-specific usage
3.5.1. Padding 3.5.1. Padding
The two padding objects permit the augmentation of packet size; this The two padding objects permit the augmentation of packet size; this
is mainly useful for delay measurement. The type of padding is mainly useful for delay measurement. The type of padding
indicates whether the padding supplied by the querier is to be copied indicates whether the padding supplied by the querier is to be copied
to, or omitted from, the response. More than one padding object MAY to, or omitted from, the response. More than one padding object MAY
be present, in which case they SHOULD be continguous. Padding be present, in which case they SHOULD be continguous. Padding
objects SHOULD occur at the end of the TLV Block. The Value field of objects SHOULD occur at the end of the TLV Block. The Value field of
a padding object is arbitrary. a padding object is arbitrary.
3.5.2. Addressing 3.5.2. Addressing
The addressing objects have the following format: The addressing objects have the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | AType | Reserved | | Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addressing Object Format Addressing Object Format
The AType (Address Type) field indicates the type of the address. The Address Family field indicates the type of the address, and SHALL
Address types defined are: be set to one of the assigned values in the IANA Address Family
Numbers registry.
Type Definition
------- --------------------
0 IP version 4 address
1 IP version 6 address
The Source and Destination address objects indicate the addresses of The Source and Destination address objects indicate the addresses of
the sender and the intended recipient of the message, respectively. the sender and the intended recipient of the message, respectively.
The Source Address SHOULD be used as the destination for out-of-band
responses unless some other out-of-band response mechanism has been The Source Address of a query message SHOULD be used as the
configured, and unless a Return Address object is present, in which destination for an out-of-band response unless some other out-of-band
case the Return Address specifies the target of the response. 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. Session Query Interval
The Value field of the Session Query Interval object is a 32-bit
unsigned positive (nonzero) integer in network byte order that
specifies a time interval in milliseconds. When attached to a query
message, this time interval indicates the interval between successive
query messages in this measurement session. When attached to a
response, this time interval indicates the minimum query interval
supported by the responder for the measurement type indicated by the
query.
When initiating a new measurement session, the querier SHOULD include
this object to inform the responder of the rate at which it intends
to send query messages in this session. Upon receiving a non-error
response, the querier MAY then stop including this object in
subsequent messages in the session for as long as its query
transmission rate remains the same. When a query is received with a
Session Query Interval that is too low for the receiver to support,
the receiver SHOULD include this object when it generates an error
response.
Lower query intervals (i.e. higher query rates) provide finer
measurement granularity at the expense of additional load on
measurement endpoints and the network; see Section 5 for further
discussion.
4. Operation 4. Operation
4.1. Loss Measurement Procedures 4.1. Loss Measurement Procedures
4.1.1. Initiating a Loss Measurement Operation 4.1.1. Initiating a Loss Measurement Operation
An LM operation for a particular channel consists of sending a An LM operation for a particular channel consists of sending a
sequence (LM[1], LM[2], ...) of LM query messages over the channel at sequence (LM[1], LM[2], ...) of LM query messages over the channel at
a specific rate and processing the responses received, if any. As a specific rate and processing the responses received, if any. As
skipping to change at page 29, line 10 skipping to change at page 29, line 31
initialization delay and a permanent unavailability condition at the initialization delay and a permanent unavailability condition at the
far end. Alternatively, the receiver MAY respond, possibly in a far end. Alternatively, the receiver MAY respond, possibly in a
rate-limited manner, to queries received during this period with an rate-limited manner, to queries received during this period with an
appropriate notification code. appropriate notification code.
4.1.2. Transmitting a Loss Measurement Query 4.1.2. Transmitting a Loss Measurement Query
When transmitting an LM Query over a channel, the Version field MUST When transmitting an LM Query over a channel, the Version field MUST
be set to 0. The R flag MUST be set to 0. The T flag SHALL be set 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 to 1 if, and only if, the measurement is specific to a particular
traffic class, in which case the TC field SHALL identify that traffic traffic class, in which case the DS field SHALL identify that traffic
class. class.
The X flag MUST be set to 1 if the transmitting interface writes 64- 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 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 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 that the counter fields contain octet counts, or to 0 to indicate
packet counts. packet counts.
The Control Code field MUST be set to one of the values for Query 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, messages listed in Section 3.1; if the channel is unidirectional,
skipping to change at page 30, line 9 skipping to change at page 30, line 27
message MUST NOT be transmitted. If the Control Code field is set to message MUST NOT be transmitted. If the Control Code field is set to
0x0 (in-band response requested) or 0x1 (out-of-band response 0x0 (in-band response requested) or 0x1 (out-of-band response
requested), then an in-band or out-of-band response, respectively, requested), then an in-band or out-of-band response, respectively,
SHOULD be transmitted unless this has been prevented by an SHOULD be transmitted unless this has been prevented by an
administrative, security or congestion control mechanism. administrative, security or congestion control mechanism.
4.1.4. Transmitting a Loss Measurement Response 4.1.4. Transmitting a Loss Measurement Response
When constructing a Response to an LM Query, the Version field MUST 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 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, and if the value of the T flag is MUST be copied from the LM Query.
1, the value of the TC field MUST also be copied.
The X flag MUST be set to 0 if the transmitting interface writes 32- 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 bit LM counters; otherwise its value MUST be copied from the LM
Query. The B flag MUST be copied from the LM Query. Query. The B flag MUST be copied from the LM Query.
The Session Identifier, Origin Timestamp, and Origin Timestamp Format The Session Identifier, Origin Timestamp, and Origin Timestamp Format
fields MUST be copied from the LM Query. The Counter 1 and Counter 2 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 fields from the LM Query MUST be copied to the Counter 3 and Counter
4 fields, respectively, of the LM Response. 4 fields, respectively, of the LM Response.
skipping to change at page 31, line 47 skipping to change at page 32, line 16
4.1.9. Test Messages 4.1.9. Test Messages
In the case of inferred LM, the packets counted for LM consist of 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 test messages generated for this purpose, or of some other class of
packets deemed to provide a good proxy for data packets flowing over packets deemed to provide a good proxy for data packets flowing over
the channel. The specification of test protocols and proxy packets the channel. The specification of test protocols and proxy packets
is outside the scope of this document. is outside the scope of this document.
An identifier common to both the test or proxy messages and the LM An identifier common to both the test or proxy messages and the LM
messages may be required to make correlation possible. The combined messages may be required to make correlation possible. The combined
value of the Session Identifier and TC fields SHOULD be used for this value of the Session Identifier and DS fields SHOULD be used for this
purpose when possible. That is, test messages in this case will purpose when possible. That is, test messages in this case will
include a 32-bit field which can carry the value of the combined include a 32-bit field which can carry the value of the combined
Session Identifier + TC field present in LM messages. When TC- Session Identifier + DS field present in LM messages. When TC-
specific LM is conducted, the TC field of the LSE in the label stack 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 of a test message corresponding to the channel (e.g. LSP) over which
the message is sent MUST equal the TC value in the associated LM the message is sent MUST correspond to the DS value in the associated
messages. LM messages.
4.1.10. Message Loss and Packet Misorder Conditions 4.1.10. Message Loss and Packet Misorder Conditions
Because an LM operation consists of a message sequence with state Because an LM operation consists of a message sequence with state
maintained from one message to the next, LM is subject to the effects 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. 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 Because this state exists only on the querier, the handling of these
conditions is, strictly speaking, a local matter. This section, conditions is, strictly speaking, a local matter. This section,
however, presents recommended procedures for handling such however, presents recommended procedures for handling such
conditions. conditions.
skipping to change at page 33, line 36 skipping to change at page 34, line 6
messages listed in Section 3.1; if the channel is unidirectional, messages listed in Section 3.1; if the channel is unidirectional,
this field MUST NOT be set to 0x0 (Query: in-band response this field MUST NOT be set to 0x0 (Query: in-band response
requested). requested).
The Querier Timestamp Format field MUST be set to the timestamp The Querier Timestamp Format field MUST be set to the timestamp
format used by the querier when writing timestamp fields in this format used by the querier when writing timestamp fields in this
message; the possible values for this field are listed in message; the possible values for this field are listed in
Section 3.4. The Responder Timestamp Format and Responder's Section 3.4. The Responder Timestamp Format and Responder's
Preferred Timestamp Format fields MUST be set to 0. Preferred Timestamp Format fields MUST be set to 0.
The Session Identifier field can be set arbitrarily. The TC field The Session Identifier field can be set arbitrarily. The DS field
MUST be set to the traffic class being measured. MUST be set to the traffic class being measured.
The Timestamp 1 field SHOULD be set to the time at which this DM The Timestamp 1 field SHOULD be set to the time at which this DM
Query is transmitted, in the format indicated by the Querier Query is transmitted, in the format indicated by the Querier
Timestamp Format field. The other timestamp fields MUST be set to 0. Timestamp Format field. The other timestamp fields MUST be set to 0.
4.2.2. Receiving a Delay Measurement Query 4.2.2. Receiving a Delay Measurement Query
Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be
set to the time at which this DM Query is received. set to the time at which this DM Query is received.
skipping to change at page 34, line 14 skipping to change at page 34, line 32
requested), then an in-band or out-of-band response, respectively, requested), then an in-band or out-of-band response, respectively,
SHOULD be transmitted unless this has been prevented by an SHOULD be transmitted unless this has been prevented by an
administrative, security or congestion control mechanism. administrative, security or congestion control mechanism.
4.2.3. Transmitting a Delay Measurement Response 4.2.3. Transmitting a Delay Measurement Response
When constructing a Response to a DM Query, the Version and Reserved 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 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. MUST be set to 1, and the remaining flag bits MUST be set to 0.
The Session Identifier, TC, and Querier Timestamp Format (QTF) fields The Session Identifier and Querier Timestamp Format (QTF) fields MUST
MUST be copied from the DM Query. The Timestamp 1 and Timestamp 2 be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields
fields from the DM Query MUST be copied to the Timestamp 3 and from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4
Timestamp 4 fields, respectively, of the DM Response. fields, respectively, of the DM Response.
The Responder Timestamp Format (RTF) field MUST be set to the The Responder Timestamp Format (RTF) field MUST be set to the
timestamp format used by the responder when writing timestamp fields timestamp format used by the responder when writing timestamp fields
in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1;
the possible values for this field are listed in Section 3.4. the possible values for this field are listed in Section 3.4.
Furthermore, the RTF field MUST be set equal either to the QTF or the Furthermore, the RTF field MUST be set equal either to the QTF or the
RPTF field. See Section 4.2.5 for guidelines on selection of the RPTF field. See Section 4.2.5 for guidelines on selection of the
value for this field. value for this field.
The Responder's Preferred Timestamp Format (RPTF) field MUST be set The Responder's Preferred Timestamp Format (RPTF) field MUST be set
skipping to change at page 36, line 18 skipping to change at page 36, line 35
is always set equal to the RTF; is always set equal to the RTF;
o All DM Responses received with RTF not equal to QTF are discarded; 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 o On a unidirectional channel, all DM Queries received with QTF not
equal to the supported format are discarded. equal to the supported format are discarded.
4.2.6. Quality of Service 4.2.6. Quality of Service
The TC field of the LSE corresponding to the channel (e.g. LSP) The TC field of the LSE corresponding to the channel (e.g. LSP)
being measured MUST be set equal to the value of the TC field in the being measured MUST be set to the value that corresponds to the DS
DM message. field in the DM message.
4.3. Combined Loss/Delay Measurement Procedures 4.3. Combined Loss/Delay Measurement Procedures
The combined LM/DM message defined in Section 3.3 allows loss and The combined LM/DM message defined in Section 3.3 allows loss and
delay measurement to be carried out simultaneously. This message delay measurement to be carried out simultaneously. This message
SHOULD be treated as an LM message which happens to carry additional SHOULD be treated as an LM message which happens to carry additional
timestamp data, with the timestamp fields processed as per delay timestamp data, with the timestamp fields processed as per delay
measurement procedures. measurement procedures.
5. Congestion Considerations 5. Congestion Considerations
skipping to change at page 37, line 41 skipping to change at page 38, line 12
causing service impairment; the possibility of unauthorized causing service impairment; the possibility of unauthorized
alteration of messages in transit; and the possibility of an alteration of messages in transit; and the possibility of an
unauthorized device learning the data contained in or implied by such unauthorized device learning the data contained in or implied by such
messages. messages.
The first consideration is discussed in Section 5. If reception or The first consideration is discussed in Section 5. If reception or
alteration of performance-related data by unauthorized devices is an alteration of performance-related data by unauthorized devices is an
operational concern, authentication and/or encryption procedures operational concern, authentication and/or encryption procedures
should be used to ensure message integrity and confidentiality. Such should be used to ensure message integrity and confidentiality. Such
procedures are outside the scope of this document, but have general procedures are outside the scope of this document, but have general
applicability to OAM protocols in MPLS-TP networks. applicability to OAM protocols in MPLS networks.
7. IANA Considerations 7. IANA Considerations
A future version of this document will detail IANA considerations This document makes the following requests of IANA:
for:
o ACH Channel Types for LM and DM messages o Allocation of Channel Types in the PW Associated Channel Type
o Timestamp format registry registry
o LM and DM Control Codes o Creation of a Measurement Timestamp Type registry
o TLV Objects 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
7.1. Allocation of PW Associated Channel Types
As per the IANA considerations in [RFC5586], IANA is requested to
allocate the following Channel Types in the PW Associated Channel
Type registry:
Value Description TLV Follows Reference
----- -------------------------------------- ----------- ------------
TBD MPLS Direct Packet Loss Measurement No (this draft)
(DLM)
TBD MPLS Inferred Packet Loss Measurement No (this draft)
(ILM)
TBD MPLS Packet Delay Measurement (DM) No (this draft)
TBD MPLS Direct Packet Loss and Delay No (this draft)
Measurement (DLM+DM)
TBD MPLS Inferred Packet Loss and Delay No (this draft)
Measurement (ILM+DM)
The values marked TBD are to be allocated by IANA as appropriate.
7.2. Creation of Measurement Timestamp Type Registry
IANA is requested to create a new Measurement Timestamp Type
registry, with format and initial allocations as follows:
Type Description Size in bits Reference
---- -------------------------------------- ------------ ------------
0 Null Timestamp 64 (this draft)
1 Sequence Number 64 (this draft)
2 Network Time Protocol version 4 64-bit 64 (this draft)
Timestamp
3 IEEE 1588 version 1 Timestamp 64 (this draft)
The range of the Type field is 0-15.
7.3. Creation of MPLS Loss/Delay Measurement Control Code Registry
IANA is requested to create a new MPLS Loss/Delay Measurement Control
Code registry. This registry is divided into two separate parts, one
for Query Codes and the other for Response Codes, with formats and
initial allocations as follows:
Query Codes
Code Description Reference
---- ------------------------------ ------------
0x0 In-band Response Requested (this draft)
0x1 Out-of-band Response Requested (this draft)
0x2 No Response Requested (this draft)
Response Codes
Code Description Reference
---- ----------------------------------- ------------
0x1 Success (this draft)
0x2 Data Format Invalid (this draft)
0x3 Initialization In Progress (this draft)
0x4 Data Reset Occurred (this draft)
0x10 Unspecified Error (this draft)
0x11 Unsupported Version (this draft)
0x12 Unsupported Control Code (this draft)
0x13 Unsupported Data Format (this draft)
0x14 Authentication Failure (this draft)
0x15 Invalid Destination Node Identifier (this draft)
0x16 Connection Mismatch (this draft)
0x17 Unsupported Mandatory TLV Object (this draft)
0x18 Unsupported Query Interval (this draft)
0x19 Administrative Block (this draft)
0x1A Temporary Resource Exhaustion (this draft)
IANA is also requested to indicate 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.
7.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry
IANA is requested to create a new MPLS Loss/Delay Measurement TLV
Object registry, with format and initial allocations as follows:
Type Description Reference
------- --------------------------------- ------------
0 Padding - copy in response (this draft)
1 Return Address (this draft)
2 Session Query Interval (this draft)
120-127 Implementation-specific usage (this draft)
128 Padding - do not copy in response (this draft)
129 Destination Address (this draft)
130 Source Address (this draft)
248-255 Implementation-specific usage (this draft)
IANA is also requested to indicate 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.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank the many participants of the MPLS working The authors wish to thank the many participants of the MPLS working
group who provided detailed review and feedback on this document. group who provided detailed review and feedback on this document.
The authors offer special thanks to Alexander Vainshtein, Loa The authors offer special thanks to Alexander Vainshtein, Loa
Andersson, and Hiroyuki Takagi for many helpful thoughts and Andersson, and Hiroyuki Takagi for many helpful thoughts and
discussions, and to Linda Dunbar for the idea of using LM messages discussions, and to Linda Dunbar for the idea of using LM messages
for throughput measurement. for throughput measurement.
skipping to change at page 38, line 31 skipping to change at page 41, line 26
9.1. Normative References 9.1. Normative References
[IEEE1588] [IEEE1588]
IEEE, "1588-2008 IEEE Standard for a Precision Clock IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", March 2008. Control Systems", March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. 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 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
9.2. Informative References 9.2. Informative References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, 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., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3260] Grossman, D., "New Terminology and Clarifications for
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Diffserv", RFC 3260, April 2002.
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007. RFC 4928, June 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010. RFC 5921, July 2010.
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Profile Data Plane Architecture", RFC 5960, August 2010. Profile Data Plane Architecture", RFC 5960, August 2010.
Authors' Addresses Authors' Addresses
Dan Frost (editor) Dan Frost
Cisco Systems Cisco Systems
Email: danfrost@cisco.com Email: danfrost@cisco.com
Stewart Bryant
Stewart Bryant (editor)
Cisco Systems Cisco Systems
Email: stbryant@cisco.com Email: stbryant@cisco.com
 End of changes. 71 change blocks. 
160 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/