--- 1/draft-ietf-mpls-loss-delay-03.txt 2011-07-19 18:16:49.000000000 +0200 +++ 2/draft-ietf-mpls-loss-delay-04.txt 2011-07-19 18:16:49.000000000 +0200 @@ -1,18 +1,18 @@ MPLS D. Frost Internet-Draft S. Bryant 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 - draft-ietf-mpls-loss-delay-03 + draft-ietf-mpls-loss-delay-04 Abstract Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol @@ -33,110 +33,111 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 5 + 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Basic Bidirectional Measurement . . . . . . . . . . . . . 6 - 2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7 - 2.3. Throughput Measurement . . . . . . . . . . . . . . . . . . 9 + 2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8 + 2.3. Throughput 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.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 12 + 2.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 13 2.8. Loopback Measurement . . . . . . . . . . . . . . . . . . . 13 - 2.9. Measurement Considerations . . . . . . . . . . . . . . . . 13 - 2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 13 - 2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 13 + 2.9. Measurement Considerations . . . . . . . . . . . . . . . . 14 + 2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 14 + 2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 14 2.9.3. Measurement Point Location . . . . . . . . . . . . . . 14 - 2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 14 - 2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 14 + 2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 15 + 2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 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.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 17 - 2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 17 - 2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 17 - 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18 + 2.9.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 18 + 2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 18 + 2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 18 + 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 19 - 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 24 - 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 26 - 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 27 - 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 28 - 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 29 - 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 30 - 3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 30 - 3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 31 - 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 32 - 4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 33 - 4.2.1. Initiating a Loss Measurement Operation . . . . . . . 33 - 4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 33 - 4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 34 - 4.2.4. Transmitting a Loss Measurement Response . . . . . . . 34 - 4.2.5. Receiving a Loss Measurement Response . . . . . . . . 35 - 4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 35 - 4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 36 - 4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 36 - 4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 36 - 4.2.10. Message Loss and Packet Misorder Conditions . . . . . 37 - 4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 38 - 4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 38 - 4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 38 - 4.3.3. Transmitting a Delay Measurement Response . . . . . . 39 - 4.3.4. Receiving a Delay Measurement Response . . . . . . . . 40 - 4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 40 - 4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 41 - 4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 41 - 5. Implementation Disclosure Requirements . . . . . . . . . . . . 41 - 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 42 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 - 8.1. Allocation of PW Associated Channel Types . . . . . . . . 44 - 8.2. Creation of Measurement Timestamp Type Registry . . . . . 45 - 8.3. Creation of MPLS Loss/Delay Measurement Control Code - Registry . . . . . . . . . . . . . . . . . . . . . . . . . 45 - 8.4. Creation of MPLS Loss/Delay Measurement TLV Object - Registry . . . . . . . . . . . . . . . . . . . . . . . . . 46 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 48 - Appendix A. Default Timestamp Format Rationale . . . . . . . . . 49 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 + 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 25 + 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 27 + 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 28 + 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 29 + 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 30 + 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 31 + 3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 31 + 3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 32 + 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 33 + 4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 34 + 4.2.1. Initiating a Loss Measurement Operation . . . . . . . 34 + 4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 34 + 4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 35 + 4.2.4. Transmitting a Loss Measurement Response . . . . . . . 35 + 4.2.5. Receiving a Loss Measurement Response . . . . . . . . 36 + 4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 36 + 4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 37 + 4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 37 + 4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 37 + 4.2.10. Message Loss and Packet Misorder Conditions . . . . . 38 + 4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 39 + 4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 39 + 4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 39 + 4.3.3. Transmitting a Delay Measurement Response . . . . . . 40 + 4.3.4. Receiving a Delay Measurement Response . . . . . . . . 41 + 4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 41 + 4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 42 + 4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 42 + 5. Implementation Disclosure Requirements . . . . . . . . . . . . 42 + 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 43 + 7. Manageability Considerations . . . . . . . . . . . . . . . . . 44 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 + 9.1. Allocation of PW Associated Channel Types . . . . . . . . 46 + 9.2. Creation of Measurement Timestamp Type Registry . . . . . 47 + 9.3. Creation of MPLS Loss/Delay Measurement Control Code + Registry . . . . . . . . . . . . . . . . . . . . . . . . . 47 + 9.4. Creation of MPLS Loss/Delay Measurement TLV Object + Registry . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 49 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 50 + Appendix A. Default Timestamp Format Rationale . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol @@ -212,34 +213,40 @@ o The DM protocol supports multiple timestamp formats, and provides a simple means for the two endpoints of a bidirectional connection to agree on a preferred format. This procedure reduces to a triviality for implementations supporting only a single timestamp format. o The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes. + The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way + Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities + for the measurement of various performance metrics in IP networks. + These protocols are not streamlined for hardware processing and rely + on IP and TCP, as well as elements of the Network Time Protocol + (NTP), which may not be available or optimized in some network + environments; they also lack support for IEEE 1588 timestamps and + direct-mode LM, which 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 This document specifies measurement procedures and protocol messages that are intended to be applicable in a wide variety of circumstances, and amenable to implementation by a wide range of hardware- and software-based measurement systems. As such, it does not attempt to mandate measurement quality levels or analyze specific end-user applications. - 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 Term Definition ----- ------------------------------------------- ACH Associated Channel Header DM Delay Measurement ECMP Equal Cost Multipath G-ACh Generic Associated Channel LM Loss Measurement LSE Label Stack Entry @@ -395,41 +401,56 @@ characteristic of being stateless at B and "almost" stateless at A. Specifically, A must retain the data associated with the last LM response received, in order to use it to compute loss when the next response arrives. This data MAY be discarded, and MUST NOT be used as a basis for measurement, if MaxLMInterval elapses before the next response arrives, because in this case an unambiguous measurement cannot be made. The foregoing discussion has assumed the counted objects are packets, but this need not be the case. In particular, octets may be counted - instead. This will, of course, reduce the MaxLMInterval - proportionately. + instead. This will, of course, reduce the MaxLMInterval accordingly. In addition to absolute aggregate loss counts, the individual loss counts yield additional metrics such as the average loss rate over any multiple of the measurement interval. An accurate loss rate can be determined over time even in the presence of anomalies affecting individual measurements, such as those due to packet misordering (Section 4.2.10). + Note that an approach for conducting packet loss measurement in IP + networks is documented in [RFC2680]. This approach differs from the + one described here, for example by requiring clock synchronization + between the measurement points and lacking support for direct-mode + LM. + 2.3. Throughput Measurement If LM query messages contain a timestamp recording their time of transmission, this data can be combined with the packet or octet counts to yield measurements of the throughput offered and delivered - over the channel during the interval. Just as for loss measurement, - the interval counts can be accumulated to arrive at the throughput of - the channel since the start of the measurement operation, or used to - derive related metrics such as the average throughput rate. This - procedure also enables out-of-service throughput testing when - combined with a simple packet generator. + over the channel during the interval in terms of the counted units. + + For a bidirectional channel, for example, given any two LM response + messages (separated in time by not more than the MaxLMInterval), the + difference between the counter values tells the querier the number of + units successfully transmitted and received in the interval between + the timestamps. Absolute offered throughput is the number of data + units transmitted and absolute delivered throughput is the number of + data units received. Throughput rate is the number of data units + sent or received per unit time. + + Just as for loss measurement, the interval counts can be accumulated + to arrive at the absolute throughput of the channel since the start + of the measurement operation, or used to derive related metrics such + as the throughput rate. This procedure also enables out-of-service + throughput testing when combined with a simple packet generator. 2.4. Delay Measurement Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A one or more of the following quantities associated with the channel: o The one-way delay associated with the forward (A to B) direction of the channel; @@ -490,41 +512,47 @@ If the clocks of A and B are known at A to be synchronized, then both one-way delay values, as well as the two-way channel delay, can be computed at A as forward one-way delay = T2 - T1 reverse one-way delay = T4 - T3 two-way channel delay = forward delay + reverse delay. + Note that this formula for the two-way channel delay reduces to the + one previously given, and clock synchronization is not required to + compute this metric. + 2.5. Delay Variation Measurement - Packet Delay Variation (PDV) [RFC3393] is another performance metric - 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 - stream going from measurement point 1 to measurement point 2. The - PDV is the difference between the one-way delay of the selected - packets. + Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV) + [RFC5481] are performance metrics derived from one-way delay + measurement and are important in some applications. IPDV represents + the difference between the one-way delays of successive packets in a + stream. PDV, given a measurement test interval, represents the + difference between the one-way delay of a packet in the interval and + that of the packet in the interval with the minimum delay. - 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 - important point regarding PDV measurement, however, is that it can be - carried out based on one-way delay measurements even when the clocks - of the two systems involved in those measurements are not - synchronized. + important point regarding delay variation measurement, however, is + that it can be carried out based on one-way delay measurements even + when the clocks of the two systems involved in those measurements are + not synchronized with one another. 2.6. Unidirectional Measurement - In the case that the channel from A to (B1, ..., Bk) is - unidirectional, i.e. is a unidirectional LSP, LM and DM measurements - can be carried out at B1, ..., Bk instead of at A. + In the case that the channel from A to (B1, ..., Bk) (where B2, ..., + Bk refer to the point-to-multipoint case) is unidirectional, i.e. is + a unidirectional LSP, LM and DM measurements can be carried out at + B1, ..., Bk instead of at A. For LM this is accomplished by initiating an LM operation at A and carrying out the same procedures as for bidirectional channels, except that no responses from B1, ..., Bk to A are generated. Instead, each terminal node B uses the A_TxP and B_RxP values in the LM messages it receives to compute the receive loss associated with the channel in essentially the same way as described previously, i.e. B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) @@ -783,23 +811,31 @@ whether various "auxiliary" flows associated with a data channel are counted, such as packets flowing over the G-ACh. Implementations MUST make their supported LM scopes clear to the user, and care must be taken to ensure that the scopes of the channel endpoints agree. 2.9.10. Delay Measurement Accuracy The delay measurement procedures described in this document are designed to facilitate hardware-assisted measurement and to function in the same way whether or not such hardware assistance is used. The - main difference in the two cases is one of measurement accuracy. - Implementations MUST make their delay measurement accuracy levels - clear to the user. + measurement accuracy will be determined by how closely the transmit + and receive timestamps correspond to actual packet departure and + arrival times. + + As noted in Section 2.4, measurement of one-way delay requires clock + synchronization between the devices involved, while two-way delay + measurement does not involve direct comparison between non-local + timestamps and thus has no synchronization requirement. The + measurement accuracy will be limited by the quality of the local + clock and, in the case of one-way delay measurement, by the quality + of the synchonization. 2.9.11. Delay Measurement Timestamp Format There are two significant timestamp formats in common use: the timestamp format of the Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. The NTP format has the advantages of wide use and long deployment in the Internet, and was specifically designed to make the computation @@ -1043,22 +1079,26 @@ The meanings of the DFlags bits are: X: Extended counter format indicator. Indicates the use of extended (64-bit) counter values. Initialized to 1 upon creation (and prior to transmission) of an LM Query and copied from an LM Query to an LM response. Set to 0 when the LM message is transmitted or received over an interface that writes 32-bit counter values. B: Octet (byte) count. When set to 1, indicates that the Counter - 1-4 fields represent octet counts. When set to 0, indicates that - the Counter 1-4 fields represent packet counts. + 1-4 fields represent octet counts. The octet count applies to all + packets within the LM scope (Section 2.9.9), and the octet count + of a packet sent or received over a channel includes the total + length of that packet (but excludes headers, labels or framing of + the channel itself). When set to 0, indicates that the Counter + 1-4 fields represent packet counts. 0: Set to 0. Origin Timestamp Format: The format of the Origin Timestamp field, as specified in Section 3.4. Session Identifier: Set arbitrarily in a query and copied in the response, if any. This field uniquely identifies a measurement operation (also called a session) that consists of a sequence of messages. All messages in the sequence have the same Session @@ -1507,40 +1549,39 @@ ambiguity condition noted in Section 2.2 cannot arise. The implementation SHOULD assume, in evaluating this rate, that the counter size is 32 bits unless explicitly configured otherwise, or unless (in the case of a bidirectional channel) all local and remote interfaces involved in the LM operation are known to be 64-bit- capable, which can be inferred from the value of the X flag in an LM response. 4.2.2. Transmitting a Loss Measurement Query - When transmitting an LM Query 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 - to 1 if, and only if, the measurement is specific to a particular - traffic class, in which case the DS field SHALL identify that traffic - class. + When transmitting an LM Query, the Version field MUST be set to 0. + The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and + only if, the measurement is specific to a particular traffic class, + in which case the DS field SHALL identify that traffic class. The X flag MUST be set to 1 if the transmitting interface writes 64- bit LM counters, and otherwise MUST be set to 0 to indicate that 32- bit counters are written. The B flag SHALL be set to 1 to indicate that the counter fields contain octet counts, or to 0 to indicate packet counts. The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: in-band response requested). The Session Identifier field can be set arbitrarily. - The Origin Timestamp field 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 set to indicate its format, according to Section 3.4. The Counter 1 field SHOULD be set to the total count of units (packets or octets, according to the B flag) transmitted over the channel prior to this LM Query, or to 0 if this is the beginning of a measurement session for which counter data is not yet available. The Counter 2 field MUST be set to 0. If a response was previously received in this measurement session, the Counter 1 and Counter 2 fields of the most recent such response MAY be copied to the Counter @@ -1727,23 +1768,23 @@ If an LM message is received that has a timestamp less than or equal to the timestamp of the last LM message received, this indicates that an exception has occurred, and the current interval SHOULD be considered unmeasurable unless the implementation has some other way of handling this condition. 4.3. Delay Measurement Procedures 4.3.1. Transmitting a Delay Measurement Query - When transmitting a DM Query over a channel, the Version and Reserved - fields MUST be set to 0. The R flag MUST be set to 0, the T flag - MUST be set to 1, and the remaining flag bits MUST be set to 0. + When transmitting a DM Query, the Version and Reserved fields MUST be + set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1, + and the remaining flag bits MUST be set to 0. The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: in-band response requested). The Querier Timestamp Format field MUST be set to the timestamp format used by the querier when writing timestamp fields in this message; the possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's @@ -1983,21 +2024,48 @@ the measurement operation SHOULD be suspended so as not to exacerbate the possible congestion condition. This suspension SHOULD be accompanied by an appropriate notification to the user so that the condition can be investigated and corrected. From the receiver perspective, the main consideration is the possibility of receiving an excessive quantity of measurement messages. An implementation SHOULD employ a mechanism such as rate- limiting to guard against the effects of this case. -7. 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 metrics over a pre-existing MPLS path (a pseudowire, LSP, or section). As such it assumes that a node involved in a measurement operation has previously verified the integrity of the path and the identity of the far end using existing MPLS mechanisms such as Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, techniques, and considerations for securing MPLS paths are discussed in detail in [RFC5920]. @@ -2020,76 +2088,82 @@ of such a disruption would imply that a much more serious breach of basic path integrity had already occurred. Such attacks can be mitigated if desired by performing basic validation and sanity checks, at the querier, of the counter or timestamp fields in received measurement response messages. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid message to a single query/response cycle. + Cryptographic mechanisms capable of signing or encrypting the + contents of the measurement packets without degrading the measurement + performance are not currently available. In light of the preceding + discussion, the absence of such cryptographic mechanisms does not + raise significant security issues. + Users concerned with the security of out-of-band responses over IP networks SHOULD employ suitable security mechanisms such as IPsec [RFC4301] to protect the integrity of the return path. -8. IANA Considerations +9. IANA Considerations This document makes the following requests of IANA: o Allocation of Channel Types in the PW Associated Channel Type registry o Creation of a Measurement Timestamp Type registry o Creation of an MPLS Loss/Delay Measurement Control Code registry o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object registry -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 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. -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 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 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft) The range of the Type field is 0-15. 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 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 ---- ------------------------------ ------------ @@ -2121,21 +2195,21 @@ 0x1C Invalid Message (this draft) 0x1D Protocol Error (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. 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 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) 3 Loopback Request (this draft) @@ -2143,37 +2217,35 @@ 128 Padding - do not copy in response (this draft) 129 Destination Address (this draft) 130 Source Address (this draft) 255 Experimental use (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. - The allocation policy for this registry is IETF Review, except for - the ranges marked "Implementation-specific usage", for which the - policy is Private Use. + The allocation policy for this registry is IETF Review. -9. Acknowledgments +10. Acknowledgments The authors wish to thank the many participants of the MPLS working group who provided detailed review and feedback on this document. The authors offer special thanks to Alexander Vainshtein, Loa Andersson, and Hiroyuki Takagi for many helpful thoughts and discussions, to Linda Dunbar for the idea of using LM messages for throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and Ben Mack-Crane for their valuable comments. -10. References +11. References -10.1. Normative References +11.1. Normative References [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, @@ -2193,58 +2265,68 @@ (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. -10.2. Informative References +11.2. Informative References [I-D.ietf-mpls-tp-loss-delay-profile] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks", draft-ietf-mpls-tp-loss-delay-profile-03 (work in progress), April 2011. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. + [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Packet Loss Metric for IPPM", RFC 2680, September 1999. + [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. - [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- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 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 Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. + Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", + RFC 5357, October 2008. + + [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation + Applicability Statement", RFC 5481, March 2009. + [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.