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/ |