draft-ietf-mpls-loss-delay-03.txt   draft-ietf-mpls-loss-delay-04.txt 
MPLS D. Frost MPLS D. Frost
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 3, 2011 June 1, 2011 Expires: January 20, 2012 July 19, 2011
Packet Loss and Delay Measurement for MPLS Networks Packet Loss and Delay Measurement for MPLS Networks
draft-ietf-mpls-loss-delay-03 draft-ietf-mpls-loss-delay-04
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 measurement capability delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning, characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol troubleshooting, and evaluation. This document specifies protocol
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 December 3, 2011. This Internet-Draft will expire on January 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 5 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Basic Bidirectional Measurement . . . . . . . . . . . . . 6 2.1. Basic Bidirectional Measurement . . . . . . . . . . . . . 6
2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7 2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8
2.3. Throughput Measurement . . . . . . . . . . . . . . . . . . 9 2.3. Throughput Measurement . . . . . . . . . . . . . . . . . . 10
2.4. Delay Measurement . . . . . . . . . . . . . . . . . . . . 10 2.4. Delay Measurement . . . . . . . . . . . . . . . . . . . . 10
2.5. Delay Variation Measurement . . . . . . . . . . . . . . . 11 2.5. Delay Variation Measurement . . . . . . . . . . . . . . . 12
2.6. Unidirectional Measurement . . . . . . . . . . . . . . . . 12 2.6. Unidirectional Measurement . . . . . . . . . . . . . . . . 12
2.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 12 2.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 13
2.8. Loopback Measurement . . . . . . . . . . . . . . . . . . . 13 2.8. Loopback Measurement . . . . . . . . . . . . . . . . . . . 13
2.9. Measurement Considerations . . . . . . . . . . . . . . . . 13 2.9. Measurement Considerations . . . . . . . . . . . . . . . . 14
2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 13 2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 14
2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 13 2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 14
2.9.3. Measurement Point Location . . . . . . . . . . . . . . 14 2.9.3. Measurement Point Location . . . . . . . . . . . . . . 14
2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 14 2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 15
2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 14 2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 15
2.9.6. Different Transmit and Receive Interfaces . . . . . . 15 2.9.6. Different Transmit and Receive Interfaces . . . . . . 15
2.9.7. External Post-Processing . . . . . . . . . . . . . . . 15 2.9.7. External Post-Processing . . . . . . . . . . . . . . . 16
2.9.8. Loss Measurement Modes . . . . . . . . . . . . . . . . 16 2.9.8. Loss Measurement Modes . . . . . . . . . . . . . . . . 16
2.9.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 17 2.9.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 18
2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 17 2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 18
2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 17 2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 18
3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Loss Measurement Message Format . . . . . . . . . . . . . 19 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 19
3.2. Delay Measurement Message Format . . . . . . . . . . . . . 24 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 25
3.3. Combined Loss/Delay Measurement Message Format . . . . . . 26 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 27
3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 27 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 28
3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 29 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 30 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 31
3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 30 3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 31
3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 31 3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 32
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 32 4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 33
4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 33 4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 34
4.2.1. Initiating a Loss Measurement Operation . . . . . . . 33 4.2.1. Initiating a Loss Measurement Operation . . . . . . . 34
4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 33 4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 34
4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 34 4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 35
4.2.4. Transmitting a Loss Measurement Response . . . . . . . 34 4.2.4. Transmitting a Loss Measurement Response . . . . . . . 35
4.2.5. Receiving a Loss Measurement Response . . . . . . . . 35 4.2.5. Receiving a Loss Measurement Response . . . . . . . . 36
4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 35 4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 36
4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 36 4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 37
4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 36 4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 37
4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 36 4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 37
4.2.10. Message Loss and Packet Misorder Conditions . . . . . 37 4.2.10. Message Loss and Packet Misorder Conditions . . . . . 38
4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 38 4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 39
4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 38 4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 39
4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 38 4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 39
4.3.3. Transmitting a Delay Measurement Response . . . . . . 39 4.3.3. Transmitting a Delay Measurement Response . . . . . . 40
4.3.4. Receiving a Delay Measurement Response . . . . . . . . 40 4.3.4. Receiving a Delay Measurement Response . . . . . . . . 41
4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 40 4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 41
4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 41 4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 42
4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 41 4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 42
5. Implementation Disclosure Requirements . . . . . . . . . . . . 41 5. Implementation Disclosure Requirements . . . . . . . . . . . . 42
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 42 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7. Manageability Considerations . . . . . . . . . . . . . . . . . 44
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8.1. Allocation of PW Associated Channel Types . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
8.2. Creation of Measurement Timestamp Type Registry . . . . . 45 9.1. Allocation of PW Associated Channel Types . . . . . . . . 46
8.3. Creation of MPLS Loss/Delay Measurement Control Code 9.2. Creation of Measurement Timestamp Type Registry . . . . . 47
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 45 9.3. Creation of MPLS Loss/Delay Measurement Control Code
8.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry . . . . . . . . . . . . . . . . . . . . . . . . . 47
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 46 9.4. Creation of MPLS Loss/Delay Measurement TLV Object
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Informative References . . . . . . . . . . . . . . . . . . 48 11.1. Normative References . . . . . . . . . . . . . . . . . . . 49
Appendix A. Default Timestamp Format Rationale . . . . . . . . . 49 11.2. Informative References . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix A. Default Timestamp Format Rationale . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
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 measurement capability delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning, characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol troubleshooting, and evaluation. This document specifies protocol
skipping to change at page 5, line 44 skipping to change at page 5, line 44
o The DM protocol supports multiple timestamp formats, and provides o The DM protocol supports multiple timestamp formats, and provides
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.
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 in some environments may be required. 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 1.1. Applicability and Scope
This document specifies measurement procedures and protocol messages This document specifies measurement procedures and protocol messages
that are intended to be applicable in a wide variety of that are intended to be applicable in a wide variety of
circumstances, and amenable to implementation by a wide range of circumstances, and amenable to implementation by a wide range of
hardware- and software-based measurement systems. As such, it does hardware- and software-based measurement systems. As such, it does
not attempt to mandate measurement quality levels or analyze specific not attempt to mandate measurement quality levels or analyze specific
end-user applications. end-user applications.
Although the procedures in this document are presented in the context
of MPLS, they have no essential dependence on MPLS and generalize
easily to other types of packet networks. Such generalizations are,
however, outside the scope of this document.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
----- ------------------------------------------- ----- -------------------------------------------
ACH Associated Channel Header ACH Associated Channel Header
DM Delay Measurement DM Delay Measurement
ECMP Equal Cost Multipath ECMP Equal Cost Multipath
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
LM Loss Measurement LM Loss Measurement
LSE Label Stack Entry LSE Label Stack Entry
skipping to change at page 9, line 36 skipping to change at page 9, line 48
characteristic of being stateless at B and "almost" stateless at A. characteristic of being stateless at B and "almost" stateless at A.
Specifically, A must retain the data associated with the last LM 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 received, in order to use it to compute loss when the next
response arrives. This data MAY be discarded, and MUST NOT be used response arrives. This data MAY be discarded, and MUST NOT be used
as a basis for measurement, if MaxLMInterval elapses before the next as a basis for measurement, if MaxLMInterval elapses before the next
response arrives, because in this case an unambiguous measurement response arrives, because in this case an unambiguous measurement
cannot be made. cannot be made.
The foregoing discussion has assumed the counted objects are packets, The foregoing discussion has assumed the counted objects are packets,
but this need not be the case. In particular, octets may be counted but this need not be the case. In particular, octets may be counted
instead. This will, of course, reduce the MaxLMInterval instead. This will, of course, reduce the MaxLMInterval accordingly.
proportionately.
In addition to absolute aggregate loss counts, the individual loss In addition to absolute aggregate loss counts, the individual loss
counts yield additional metrics such as the average loss rate over counts yield additional metrics such as the average loss rate over
any multiple of the measurement interval. An accurate loss rate can any multiple of the measurement interval. An accurate loss rate can
be determined over time even in the presence of anomalies affecting be determined over time even in the presence of anomalies affecting
individual measurements, such as those due to packet misordering individual measurements, such as those due to packet misordering
(Section 4.2.10). (Section 4.2.10).
Note that an approach for conducting packet loss measurement in IP
networks is documented in [RFC2680]. This approach differs from the
one described here, for example by requiring clock synchronization
between the measurement points and lacking support for direct-mode
LM.
2.3. Throughput Measurement 2.3. Throughput Measurement
If LM query messages contain a timestamp recording their time of If LM query messages contain a timestamp recording their time of
transmission, this data can be combined with the packet or octet transmission, this data can be combined with the packet or octet
counts to yield measurements of the throughput offered and delivered counts to yield measurements of the throughput offered and delivered
over the channel during the interval. Just as for loss measurement, over the channel during the interval in terms of the counted units.
the interval counts can be accumulated to arrive at the throughput of
the channel since the start of the measurement operation, or used to For a bidirectional channel, for example, given any two LM response
derive related metrics such as the average throughput rate. This messages (separated in time by not more than the MaxLMInterval), the
procedure also enables out-of-service throughput testing when difference between the counter values tells the querier the number of
combined with a simple packet generator. 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 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 2.4. Delay Measurement
Suppose a bidirectional channel exists between the nodes A and B. The 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 objective is to measure at A one or more of the following quantities
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;
skipping to change at page 11, line 36 skipping to change at page 12, line 15
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 two-way channel 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
two-way channel delay = forward delay + reverse delay. 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 2.5. Delay Variation Measurement
Packet Delay Variation (PDV) [RFC3393] is another performance metric Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV)
important in some applications. The PDV of a pair of packets within [RFC5481] are performance metrics derived from one-way delay
a stream of packets is defined for a selected pair of packets in the measurement and are important in some applications. IPDV represents
stream going from measurement point 1 to measurement point 2. The the difference between the one-way delays of successive packets in a
PDV is the difference between the one-way delay of the selected stream. PDV, given a measurement test interval, represents the
packets. difference between the one-way delay of a packet in the interval and
that of the packet in the interval with the minimum delay.
A PDV measurement can therefore be derived from successive delay IPDV and PDV measurements can therefore be derived from delay
measurements obtained through the procedures in Section 2.4. An measurements obtained through the procedures in Section 2.4. An
important point regarding PDV measurement, however, is that it can be important point regarding delay variation measurement, however, is
carried out based on one-way delay measurements even when the clocks that it can be carried out based on one-way delay measurements even
of the two systems involved in those measurements are not when the clocks of the two systems involved in those measurements are
synchronized. not synchronized with one another.
2.6. Unidirectional Measurement 2.6. Unidirectional Measurement
In the case that the channel from A to (B1, ..., Bk) is In the case that the channel from A to (B1, ..., Bk) (where B2, ...,
unidirectional, i.e. is a unidirectional LSP, LM and DM measurements Bk refer to the point-to-multipoint case) is unidirectional, i.e. is
can be carried out at B1, ..., Bk instead of at A. 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 For LM this is accomplished by initiating an LM operation at A and
carrying out the same procedures as for bidirectional channels, carrying out the same procedures as for bidirectional channels,
except that no responses from B1, ..., Bk to A are generated. 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 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 LM messages it receives to compute the receive loss associated with
the channel in essentially the same way as described previously, i.e. the channel in essentially the same way as described previously, i.e.
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
skipping to change at page 17, line 40 skipping to change at page 18, line 24
whether various "auxiliary" flows associated with a data channel are whether various "auxiliary" flows associated with a data channel are
counted, such as packets flowing over the G-ACh. Implementations counted, such as packets flowing over the G-ACh. Implementations
MUST make their supported LM scopes clear to the user, and care must 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. be taken to ensure that the scopes of the channel endpoints agree.
2.9.10. Delay Measurement Accuracy 2.9.10. Delay Measurement Accuracy
The delay measurement procedures described in this document are The delay measurement procedures described in this document are
designed to facilitate hardware-assisted measurement and to function designed to facilitate hardware-assisted measurement and to function
in the same way whether or not such hardware assistance is used. The in the same way whether or not such hardware assistance is used. The
main difference in the two cases is one of measurement accuracy. measurement accuracy will be determined by how closely the transmit
Implementations MUST make their delay measurement accuracy levels and receive timestamps correspond to actual packet departure and
clear to the user. 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 synchonization.
2.9.11. Delay Measurement Timestamp Format 2.9.11. Delay Measurement Timestamp Format
There are two significant timestamp formats in common use: the There are two significant timestamp formats in common use: the
timestamp format of the Network Time Protocol (NTP), described in timestamp format of the Network Time Protocol (NTP), described in
[RFC5905], and the timestamp format used in the IEEE 1588 Precision [RFC5905], and the timestamp format used in the IEEE 1588 Precision
Time Protocol (PTP) [IEEE1588]. Time Protocol (PTP) [IEEE1588].
The NTP format has the advantages of wide use and long deployment in The NTP format has the advantages of wide use and long deployment in
the Internet, and was specifically designed to make the computation the Internet, and was specifically designed to make the computation
skipping to change at page 23, line 28 skipping to change at page 24, line 9
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
Query to an LM response. Set to 0 when the LM message is Query to an LM response. Set to 0 when the LM message is
transmitted or received over an interface that writes 32-bit transmitted or received over an interface that writes 32-bit
counter values. counter values.
B: Octet (byte) count. When set to 1, indicates that the Counter B: Octet (byte) count. When set to 1, indicates that the Counter
1-4 fields represent octet counts. When set to 0, indicates that 1-4 fields represent octet counts. The octet count applies to all
the Counter 1-4 fields represent packet counts. 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. 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. This field uniquely identifies a measurement response, if any. This field uniquely identifies a measurement
operation (also called a session) that consists of a sequence of operation (also called a session) that consists of a sequence of
messages. All messages in the sequence have the same Session messages. All messages in the sequence have the same Session
skipping to change at page 33, line 41 skipping to change at page 34, line 41
ambiguity condition noted in Section 2.2 cannot arise. The ambiguity condition noted in Section 2.2 cannot arise. The
implementation SHOULD assume, in evaluating this rate, that the implementation SHOULD assume, in evaluating this rate, that the
counter size is 32 bits unless explicitly configured otherwise, or counter size is 32 bits unless explicitly configured otherwise, or
unless (in the case of a bidirectional channel) all local and remote unless (in the case of a bidirectional channel) all local and remote
interfaces involved in the LM operation are known to be 64-bit- 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 capable, which can be inferred from the value of the X flag in an LM
response. response.
4.2.2. Transmitting a Loss Measurement Query 4.2.2. Transmitting a Loss Measurement Query
When transmitting an LM Query over a channel, the Version field MUST When transmitting an LM Query, the Version field MUST be set to 0.
be set to 0. The R flag MUST be set to 0. The T flag SHALL be set The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and
to 1 if, and only if, the measurement is specific to a particular only if, the measurement is specific to a particular traffic class,
traffic class, in which case the DS field SHALL identify that traffic 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,
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 Session Identifier field can be set arbitrarily. The Session Identifier field can be set arbitrarily.
The Origin Timestamp field SHOULD be set to the time at which this The Origin Timestamp field SHALL be set to the time at which this
message is transmitted, and the Origin Timestamp Format field MUST be message is transmitted, and the Origin Timestamp Format field MUST be
set to indicate its format, according to Section 3.4. set to indicate its format, according to Section 3.4.
The Counter 1 field SHOULD be set to the total count of units The Counter 1 field SHOULD be set to the total count of units
(packets or octets, according to the B flag) transmitted over the (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 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 measurement session for which counter data is not yet available. The
Counter 2 field MUST be set to 0. If a response was previously Counter 2 field MUST be set to 0. If a response was previously
received in this measurement session, the Counter 1 and Counter 2 received in this measurement session, the Counter 1 and Counter 2
fields of the most recent such response MAY be copied to the Counter fields of the most recent such response MAY be copied to the Counter
skipping to change at page 38, line 19 skipping to change at page 39, line 19
If an LM message is received that has a timestamp less than or equal 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 to the timestamp of the last LM message received, this indicates that
an exception has occurred, and the current interval SHOULD be an exception has occurred, and the current interval SHOULD be
considered unmeasurable unless the implementation has some other way considered unmeasurable unless the implementation has some other way
of handling this condition. of handling this condition.
4.3. Delay Measurement Procedures 4.3. Delay Measurement Procedures
4.3.1. Transmitting a Delay Measurement Query 4.3.1. Transmitting a Delay Measurement Query
When transmitting a DM Query over a channel, the Version and Reserved When transmitting a DM Query, the Version and Reserved fields MUST be
fields MUST be set to 0. The R flag MUST be set to 0, the T flag set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1,
MUST be set to 1, and the remaining flag bits MUST be set to 0. and the remaining flag bits MUST be set to 0.
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,
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
skipping to change at page 43, line 39 skipping to change at page 44, line 39
the measurement operation SHOULD be suspended so as not to exacerbate the measurement operation SHOULD be suspended so as not to exacerbate
the possible congestion condition. This suspension SHOULD be the possible congestion condition. This suspension SHOULD be
accompanied by an appropriate notification to the user so that the accompanied by an appropriate notification to the user so that the
condition can be investigated and corrected. condition can be investigated and corrected.
From the receiver perspective, the main consideration is the From the receiver perspective, the main consideration is the
possibility of receiving an excessive quantity of measurement possibility of receiving an excessive quantity of measurement
messages. An implementation SHOULD employ a mechanism such as rate- messages. An implementation SHOULD employ a mechanism such as rate-
limiting to guard against the effects of this case. limiting to guard against the effects of this case.
7. Security Considerations 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
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 This document describes procedures for the measurement of performance
metrics over a pre-existing MPLS path (a pseudowire, LSP, or metrics over a pre-existing MPLS path (a pseudowire, LSP, or
section). As such it assumes that a node involved in a measurement section). As such it assumes that a node involved in a measurement
operation has previously verified the integrity of the path and the operation has previously verified the integrity of the path and the
identity of the far end using existing MPLS mechanisms such as identity of the far end using existing MPLS mechanisms such as
Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
techniques, and considerations for securing MPLS paths are discussed techniques, and considerations for securing MPLS paths are discussed
in detail in [RFC5920]. in detail in [RFC5920].
skipping to change at page 44, line 28 skipping to change at page 46, line 8
of such a disruption would imply that a much more serious breach of of such a disruption would imply that a much more serious breach of
basic path integrity had already occurred. basic path integrity had already occurred.
Such attacks can be mitigated if desired by performing basic Such attacks can be mitigated if desired by performing basic
validation and sanity checks, at the querier, of the counter or validation and sanity checks, at the querier, of the counter or
timestamp fields in received measurement response messages. The timestamp fields in received measurement response messages. The
minimal state associated with these protocols also limits the extent minimal state associated with these protocols also limits the extent
of measurement disruption that can be caused by a corrupt or invalid of measurement disruption that can be caused by a corrupt or invalid
message to a single query/response cycle. 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 Users concerned with the security of out-of-band responses over IP
networks SHOULD employ suitable security mechanisms such as IPsec networks SHOULD employ suitable security mechanisms such as IPsec
[RFC4301] to protect the integrity of the return path. [RFC4301] to protect the integrity of the return path.
8. IANA Considerations 9. IANA Considerations
This document makes the following requests of IANA: This document makes the following requests of IANA:
o Allocation of Channel Types in the PW Associated Channel Type o Allocation of Channel Types in the PW Associated Channel Type
registry registry
o Creation of a Measurement Timestamp 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 Control Code registry
o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV)
Object registry Object registry
8.1. Allocation of PW Associated Channel Types 9.1. Allocation of PW Associated Channel Types
As per the IANA considerations in [RFC5586], IANA is requested to As per the IANA considerations in [RFC5586], IANA is requested to
allocate the following Channel Types in the PW Associated Channel allocate the following Channel Types in the PW Associated Channel
Type registry: Type registry:
Value Description TLV Follows Reference Value Description TLV Follows Reference
----- -------------------------------------- ----------- ------------ ----- -------------------------------------- ----------- ------------
TBD MPLS Direct Packet Loss Measurement No (this draft) TBD MPLS Direct Packet Loss Measurement No (this draft)
(DLM) (DLM)
TBD MPLS Inferred Packet Loss Measurement No (this draft) TBD MPLS Inferred Packet Loss Measurement No (this draft)
(ILM) (ILM)
TBD MPLS Packet Delay Measurement (DM) No (this draft) TBD MPLS Packet Delay Measurement (DM) No (this draft)
TBD MPLS Direct Packet Loss and Delay No (this draft) TBD MPLS Direct Packet Loss and Delay No (this draft)
Measurement (DLM+DM) Measurement (DLM+DM)
TBD MPLS Inferred Packet Loss and Delay No (this draft) TBD MPLS Inferred Packet Loss and Delay No (this draft)
Measurement (ILM+DM) Measurement (ILM+DM)
The values marked TBD are to be allocated by IANA as appropriate. The values marked TBD are to be allocated by IANA as appropriate.
8.2. Creation of Measurement Timestamp Type Registry 9.2. Creation of Measurement Timestamp Type Registry
IANA is requested to create a new Measurement Timestamp Type IANA is requested to create a new Measurement Timestamp Type
registry, with format and initial allocations as follows: registry, with format and initial allocations as follows:
Type Description Size in bits Reference Type Description Size in bits Reference
---- -------------------------------------- ------------ ------------ ---- -------------------------------------- ------------ ------------
0 Null Timestamp 64 (this draft) 0 Null Timestamp 64 (this draft)
1 Sequence Number 64 (this draft) 1 Sequence Number 64 (this draft)
2 Network Time Protocol version 4 64-bit 64 (this draft) 2 Network Time Protocol version 4 64-bit 64 (this draft)
Timestamp Timestamp
3 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft) 3 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft)
The range of the Type field is 0-15. The range of the Type field is 0-15.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
8.3. Creation of MPLS Loss/Delay Measurement Control Code Registry 9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry
IANA is requested to create a new MPLS Loss/Delay Measurement Control IANA is requested to create a new MPLS Loss/Delay Measurement Control
Code registry. This registry is divided into two separate parts, one Code registry. This registry is divided into two separate parts, one
for Query Codes and the other for Response Codes, with formats and for Query Codes and the other for Response Codes, with formats and
initial allocations as follows: initial allocations as follows:
Query Codes Query Codes
Code Description Reference Code Description Reference
---- ------------------------------ ------------ ---- ------------------------------ ------------
skipping to change at page 46, line 36 skipping to change at page 48, line 36
0x1C Invalid Message (this draft) 0x1C Invalid Message (this draft)
0x1D Protocol Error (this draft) 0x1D Protocol Error (this draft)
IANA is also requested to indicate that the values 0x0 - 0xF in the IANA is also requested to indicate that the values 0x0 - 0xF in the
Response Code section are reserved for non-error response codes. Response Code section are reserved for non-error response codes.
The range of the Code field is 0 - 255. The range of the Code field is 0 - 255.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
8.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry 9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry
IANA is requested to create a new MPLS Loss/Delay Measurement TLV IANA is requested to create a new MPLS Loss/Delay Measurement TLV
Object registry, with format and initial allocations as follows: Object registry, with format and initial allocations as follows:
Type Description Reference Type Description Reference
---- --------------------------------- ------------ ---- --------------------------------- ------------
0 Padding - copy in response (this draft) 0 Padding - copy in response (this draft)
1 Return Address (this draft) 1 Return Address (this draft)
2 Session Query Interval (this draft) 2 Session Query Interval (this draft)
3 Loopback Request (this draft) 3 Loopback Request (this draft)
skipping to change at page 47, line 22 skipping to change at page 49, line 22
128 Padding - do not copy in response (this draft) 128 Padding - do not copy in response (this draft)
129 Destination Address (this draft) 129 Destination Address (this draft)
130 Source Address (this draft) 130 Source Address (this draft)
255 Experimental use (this draft) 255 Experimental use (this draft)
IANA is also requested to indicate that Types 0-127 are classified as IANA is also requested to indicate that Types 0-127 are classified as
Mandatory, and that Types 128-255 are classified as Optional. Mandatory, and that Types 128-255 are classified as Optional.
The range of the Type field is 0 - 255. The range of the Type field is 0 - 255.
The allocation policy for this registry is IETF Review, except for The allocation policy for this registry is IETF Review.
the ranges marked "Implementation-specific usage", for which the
policy is Private Use.
9. Acknowledgments 10. 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, to Linda Dunbar for the idea of using LM messages for discussions, to Linda Dunbar for the idea of using LM messages for
throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and
Ben Mack-Crane for their valuable comments. Ben Mack-Crane for their valuable comments.
10. References 11. References
10.1. Normative References 11.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, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
skipping to change at page 48, line 25 skipping to change at page 50, line 24
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. 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.
10.2. Informative References 11.2. Informative References
[I-D.ietf-mpls-tp-loss-delay-profile] [I-D.ietf-mpls-tp-loss-delay-profile]
Frost, D. and S. Bryant, "A Packet Loss and Delay Frost, D. and S. Bryant, "A Packet Loss and Delay
Measurement Profile for MPLS-based Transport Networks", Measurement Profile for MPLS-based Transport Networks",
draft-ietf-mpls-tp-loss-delay-profile-03 (work in draft-ietf-mpls-tp-loss-delay-profile-03 (work in
progress), April 2011. progress), April 2011.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. 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 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. 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.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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 [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.
[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, [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.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 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.
 End of changes. 43 change blocks. 
121 lines changed or deleted 201 lines changed or added

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