--- 1/draft-ietf-mpls-loss-delay-00.txt 2011-02-04 13:15:50.000000000 +0100 +++ 2/draft-ietf-mpls-loss-delay-01.txt 2011-02-04 13:15:50.000000000 +0100 @@ -1,30 +1,30 @@ -MPLS D. Frost, Ed. -Internet-Draft S. Bryant, Ed. +MPLS D. Frost +Internet-Draft S. Bryant 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 - draft-ietf-mpls-loss-delay-00 + draft-ietf-mpls-loss-delay-01 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 capability, in - addition, provides operators with greater visibility into the - performance characteristics of their networks, thereby facilitating - planning, troubleshooting, and evaluation. This document specifies - protocol mechanisms to enable the efficient and accurate measurement - of these performance metrics in MPLS networks. + 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 + mechanisms to enable the efficient and accurate measurement of these + performance metrics in MPLS networks. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -33,25 +33,25 @@ 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 June 26, 2011. + This Internet-Draft will expire on August 8, 2011. 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. 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 @@ -66,85 +66,92 @@ 2.2. Throughput Measurement . . . . . . . . . . . . . . . . . . 9 2.3. Delay Measurement . . . . . . . . . . . . . . . . . . . . 9 2.4. Delay Variation Measurement . . . . . . . . . . . . . . . 11 2.5. Unidirectional Measurement . . . . . . . . . . . . . . . . 11 2.6. Loopback Measurement . . . . . . . . . . . . . . . . . . . 12 2.7. Measurement Considerations . . . . . . . . . . . . . . . . 12 2.7.1. Types of Channels . . . . . . . . . . . . . . . . . . 12 2.7.2. Quality of Service . . . . . . . . . . . . . . . . . . 12 2.7.3. Equal Cost Multipath . . . . . . . . . . . . . . . . . 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.7. Loss Measurement Scope . . . . . . . . . . . . . . . . 16 2.7.8. Delay Measurement Accuracy . . . . . . . . . . . . . . 16 2.7.9. Delay Measurement Timestamp Format . . . . . . . . . . 16 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 17 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 22 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 24 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 25 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 26 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 27 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 27 + 3.5.3. Session Query Interval . . . . . . . . . . . . . . . . 28 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1. Loss Measurement Procedures . . . . . . . . . . . . . . . 28 4.1.1. Initiating a Loss Measurement Operation . . . . . . . 28 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.5. Receiving a Loss Measurement Response . . . . . . . . 30 + 4.1.5. Receiving a Loss Measurement Response . . . . . . . . 31 4.1.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 31 4.1.7. Quality of Service . . . . . . . . . . . . . . . . . . 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.2. Delay Measurement Procedures . . . . . . . . . . . . . . . 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.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.6. Quality of Service . . . . . . . . . . . . . . . . . . 36 4.3. Combined Loss/Delay Measurement Procedures . . . . . . . . 36 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 7.1. Allocation of PW Associated Channel Types . . . . . . . . 38 + 7.2. Creation of Measurement Timestamp Type Registry . . . . . 39 + 7.3. Creation of MPLS Loss/Delay Measurement Control Code + Registry . . . . . . . . . . . . . . . . . . . . . . . . . 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 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 capability, in - addition, provides operators with greater visibility into the - performance characteristics of their networks, thereby facilitating - planning, troubleshooting, and evaluation. This document specifies - protocol mechanisms to enable the efficient and accurate measurement - of these performance metrics in MPLS networks. + 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 + mechanisms to enable the efficient and accurate measurement of these + performance metrics in MPLS networks. This document specifies two closely-related protocols, one for packet loss measurement (LM) and one for packet delay measurement (DM). These protocols have the following characteristics and capabilities: o The LM and DM protocols are intended to be simple and to support efficient hardware processing. o The LM and DM protocols operate over the MPLS Generic Associated - Channel (G-ACh) [RFC5586] and support measurement of loss and - delay over Label Switched Paths (LSPs), pseudowires, and MPLS - sections (links). + Channel (G-ACh) [RFC5586] and support measurement of loss, delay, + and related metrics over Label Switched Paths (LSPs), pseudowires, + and MPLS sections (links). o The LM and DM protocols are applicable to the LSPs, pseudowires, and sections of networks based on the MPLS Transport Profile (MPLS-TP), because the MPLS-TP is based on a standard MPLS data plane. The MPLS-TP is defined and described in [RFC5921], and MPLS-TP LSPs, pseudowires, and sections are discussed in detail in [RFC5960]. o The LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurement. @@ -191,29 +198,28 @@ 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. 1.1. Terminology Term Definition - ------- ------------------------------------------- + ----- ------------------------------------------- ACH Associated Channel Header DM Delay Measurement G-ACh Generic Associated Channel LM Loss Measurement LSE Label Stack Entry LSP Label Switched Path LSR Label Switching Router - MPLS-TP MPLS Transport Profile NTP Network Time Protocol OAM Operations, Administration, and Maintenance PTP Precision Time Protocol PW Pseudowire TC Traffic Class 2. Overview This section begins with a summary of the basic methods used for the bidirectional measurement of packet loss and delay. These @@ -380,33 +386,34 @@ associated with the channel: o The one-way delay associated with the forward (A to B) direction of the channel; o The one-way delay associated with the reverse (B to A) direction of the channel; o The two-way delay (A to B to A) associated with the channel. - In the case of two-way delay, there are actually two possible metrics - of interest. The "strict" two-way delay is the sum of the one-way - delays in each direction and reflects the two-way delay of the - channel itself, irrespective of processing delays within the remote - endpoint B. The "loose" two-way delay includes in addition any delay - associated with remote endpoint processing. + The one-way delay metric for packet networks is described in + [RFC2679]. Measurement of the one-way delay quantities requires that + the clocks of A and B be synchronized, whereas the two-way delay can + be measured directly even when this is not the case (provided A and B + have stable clocks). - Measurement of the one-way delay quantities requires that the clocks - of A and B be synchronized, whereas the two-way delay can be measured - directly even when this is not the case (provided A and B have stable - clocks). + In the case of two-way delay, there are actually two possible metrics + of interest. The "two-way channel delay" is the sum of the one-way + delays in each direction and reflects the delay of the channel + itself, irrespective of processing delays within the remote 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 timestamp: T1: the time the DM query message is transmitted from A. When the message arrives at B, the following timestamp is recorded in the message: T2: the time the DM query message is received at B. @@ -414,37 +421,37 @@ and transmits it back to A, recording within it the following timestamp: T3: the time the DM response message is transmitted from B. When the message arrives back at A, the following timestamp is recorded in the message: T4: the time the DM response message is received back at A. - At this point, A can compute the strict two-way delay associated with - the channel as + At this point, A can compute the two-way channel delay associated + 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 - 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 forward one-way delay = T2 - T1 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 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. @@ -482,22 +489,22 @@ Some bidirectional channels may be placed into a loopback state such that query messages are looped back to the querier without modification. In this situation, LM and DM procedures can be used to carry out measurements associated with the circular path. 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]) - For DM, the loose two-way delay is computed. In this case, however, - the remote endpoint processing time component reflects only the time + For DM, the round-trip delay is computed. In this case, however, the + remote endpoint processing time component reflects only the time required to loop the message from channel input to channel output. Query messages must include some form of source identifier in order for looped-back queries to be differentiated from queries initiated by the far end. 2.7. Measurement Considerations A number of additional considerations apply in practice to the measurement methods summarized above. @@ -581,21 +588,21 @@ the processing of the packet by the intermediate node occurs only as the result of TTL expiry, and the handling of TTL expiry may occur at a later processing stage in the implementation than the hardware- assisted measurement function. Often the motivation for conducting measurements to intermediate nodes is an attempt to localize a problem that has been detected on the LSP. In this case, if intermediate nodes are not capable of performing hardware-assisted measurement, a less accurate - but usually sufficient - software- based measurement can be conducted instead. -2.7.5. Distributed Systems +2.7.5. Different Transmit and Receive Interfaces The overview of the bidirectional measurement process presented in Section 2 is also applicable when the transmit and receive interfaces at A or B differ from one another. Some additional considerations, however, do apply in this case: o If different clocks are associated with transmit and receive processing, these clocks must be synchronized in order to compute the two-way delay. @@ -757,21 +764,21 @@ The format of a Loss Measurement message, which follows the Associated Channel Header (ACH), is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DFlags| OTF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Session Identifier | TC | + | Session Identifier | DS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Origin Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . @@ -788,54 +795,51 @@ possible values for the remaining fields are as follows. Field Meaning ------------------------- ------------------------------------------- Version Protocol version Flags Message control flags Control Code Code identifying the query or response type Message Length Total length of this message in bytes Data Format Flags Flags specifying the format of message data (DFlags) - Origin Timestamp Format Format of the Origin Timestamp field - (OTF) + Origin Timestamp Format of the Origin Timestamp field + Format (OTF) Reserved Reserved for future specification Session Identifier Set arbitrarily by the querier - Traffic Class (TC) TC being measured + Differentiated Differentiated Services Code Point (DSCP) being + Services (DS) Field measured + 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. Version: Currently set to 0. Flags: The format of the Flags field is shown below. +-+-+-+-+ - | Flags | - +-+-+-+-+ - - +-+-+-+-+ |R|T|0|0| +-+-+-+-+ Loss Measurement Message Flags The meanings of the flag bits are: R: Query/Response indicator. Set to 0 for a Query and 1 for a Response. T: Traffic-class-specific measurement indicator. Set to 1 when the measurement operation is scoped to packets of a particular - traffic class, and 0 otherwise. When set to 1, the TC field of - the message indicates the measured traffic class. + traffic class (DSCP value), and 0 otherwise. When set to 1, the + DS field of the message indicates the measured traffic class. 0: Set to 0. Control Code: Set as follows according to whether the message is a Query or a Response as identified by the R flag. For a Query: 0x0: In-band Response Requested. Indicates that this query has been sent over a bidirectional channel and the response is @@ -894,40 +898,36 @@ 0x16: Error - Connection Mismatch. Indicates that the operation failed because the channel identifier supplied in the query did not match the channel over which the query was received. 0x17: Error - Unsupported Mandatory TLV Object. Indicates that the operation failed because a TLV Object received in the query and marked as mandatory is not supported. - 0x18: Error - Query Rate Exceeded. Indicates that the + 0x18: Error - Unsupported Query Interval. Indicates that the operation failed because the query message rate exceeded the configured threshold. 0x19: Error - Administrative Block. Indicates that the operation failed because it has been administratively disallowed. 0x1A: Error - Temporary Resource Exhaustion. Indicates that the operation failed because node resources were not available. Message Length: Set to the total length of this message in bytes. DFlags: The format of the DFlags field is shown below. +-+-+-+-+ - | DFlags| - +-+-+-+-+ - - +-+-+-+-+ |X|B|0|0| +-+-+-+-+ Loss Measurement Message Flags The meanings of the DFlags bits are: X: Extended counter format indicator. Indicates the use of extended (64-bit) counter values. Initialized to 1 upon creation (and prior to transmission) of an LM Query and copied from an LM @@ -940,24 +940,28 @@ 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. - TC: When the T flag is set to 1, this field is set to the TC being - measured. 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. + DS: When the T flag is set to 1, this field is set to the DSCP value + [RFC3260] that corresponds to the traffic class being measured. For + MPLS, where the traffic class of a channel is identified by the + three-bit Traffic Class in the channel's LSE [RFC5462], this field + SHOULD be set to the Class Selector Codepoint [RFC2474] that + corresponds to that Traffic Class. When the T flag is set to 0, the + value of this field is arbitrary, and the field can be considered + part of the Session Identifier. Origin Timestamp: Timestamp recording the transmit time of the query message. Counter 1-4: Referring to Section 2.1, when a query is sent from A, Counter 1 is set to A_TxP and the other counter fields are set to 0. When the query is received at B, Counter 2 is set to B_RxP. At this point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, and re-initializes Counter 1 and Counter 2 to 0. When B transmits the response, Counter 1 is set to B_TxP. When the response is @@ -980,51 +984,53 @@ The format of a Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QTF | RTF | RPTF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Session Identifier | TC | + | Session Identifier | DS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp 4 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLV Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Delay Measurement Message Format The meanings of the fields are summarized in the following table. Field Meaning - --------------------- ------------------------------------------- + --------------------- ----------------------------------------------- Version Protocol version Flags Message control flags Control Code Code identifying the query or response type Message Length Total length of this message in bytes QTF Querier timestamp format RTF Responder timestamp format RPTF Responder's preferred timestamp format Reserved Reserved for future specification Session Identifier Set arbitrarily by the querier - Traffic Class (TC) TC being measured + Differentiated Differentiated Services Code Point (DSCP) being + Services (DS) Field measured + Timestamp 1-4 64-bit timestamp values TLV Block Optional block of Type-Length-Value fields Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows. Version: Currently set to 0. 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. @@ -1037,21 +1043,21 @@ by the querier, as specified in Section 3.4. Responder Timestamp Format: The format of the timestamp values written by the responder, as specified in Section 3.4. Responder's Preferred Timestamp Format: The timestamp format preferred by the responder, as specified in Section 3.4. Session Identifier: As specified in Section 3.1. - 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 is set to T1 and the other timestamp fields are set to 0. When the query is received at B, Timestamp 2 is set to T2. At this point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. When B transmits the response, Timestamp 1 is set to T3. When the response is received at A, Timestamp 2 is set to T4. The actual formats of the timestamp fields written by A and B are indicated by the Querier Timestamp Format and Responder Timestamp Format fields @@ -1069,21 +1075,21 @@ The format of a combined Loss and Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DFlags| QTF | RTF | RPTF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Session Identifier | TC | + | Session Identifier | DS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp 4 | | | @@ -1104,33 +1110,32 @@ Figure 4: Loss/Delay Measurement Message Format The LM/DM message fields have the same meanings as the corresponding fields in the LM and DM message formats. 3.4. Timestamp Field Formats The following timestamp format field values are specified in this document: - 0x0: Null timestamp format. This value is a placeholder - indicating that the timestamp field does not contain a meaningful - timestamp. + 0: Null timestamp format. This value is a placeholder indicating + that the timestamp field does not contain a meaningful timestamp. - 0x1: Sequence number. This value indicates that the timestamp - field is to be viewed as a simple 64-bit sequence number. + 1: Sequence number. This value indicates that the timestamp field + 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 followed by a 32-bit fractional seconds field, so that it can be 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 followed by a 32-bit nanoseconds field. In recognition of the wide deployment, particularly in hardware-based timing implementations, of IEEE 1588 PTP, the PTP timestamp format is the default format used in Delay Measurement messages. This format MUST be supported. Support for other timestamp formats is OPTIONAL. 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- @@ -1165,68 +1170,94 @@ TLV object, the recipient MUST discard the message or respond with an appropriate error code. The types defined are as follows: Type Definition -------------- --------------------------------- Mandatory 0 Padding - copy in response 1 Return Address - 2-119 Reserved - 120-127 Vendor-specific usage + 2 Session Query Interval + 3-119 Reserved + 120-127 Implementation-specific usage Optional 128 Padding - do not copy in response 129 Destination Address 130 Source Address 131-247 Reserved - 248-255 Vendor-specific usage + 248-255 Implementation-specific usage 3.5.1. Padding The two padding objects permit the augmentation of packet size; this is mainly useful for delay measurement. The type of padding indicates whether the padding supplied by the querier is to be copied to, or omitted from, the response. More than one padding object MAY be present, in which case they SHOULD be continguous. Padding objects SHOULD occur at the end of the TLV Block. The Value field of a padding object is arbitrary. 3.5.2. Addressing The addressing objects have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | AType | Reserved | + | Type | Length | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addressing Object Format - The AType (Address Type) field indicates the type of the address. - Address types defined are: - - Type Definition - ------- -------------------- - 0 IP version 4 address - 1 IP version 6 address + The Address Family field indicates the type of the address, and SHALL + be set to one of the assigned values in the IANA Address Family + Numbers registry. The Source and Destination address objects indicate the addresses of the sender and the intended recipient of the message, respectively. - The Source Address SHOULD be used as the destination for out-of-band - responses unless some other out-of-band response mechanism has been - configured, and unless a Return Address object is present, in which - case the Return Address specifies the target of the response. + + The Source Address of a query message SHOULD be used as the + destination for an out-of-band response unless some other out-of-band + response mechanism has been configured, and unless a Return Address + object is present, in which case the Return Address specifies the + target of the response. The Return Address object MUST NOT appear in + a response. + +3.5.3. 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.1. Loss Measurement Procedures 4.1.1. Initiating a Loss Measurement Operation An LM operation for a particular channel consists of sending a sequence (LM[1], LM[2], ...) of LM query messages over the channel at a specific rate and processing the responses received, if any. As @@ -1254,21 +1285,21 @@ initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. 4.1.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 TC field SHALL identify that traffic + 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, @@ -1299,22 +1330,21 @@ message MUST NOT be transmitted. If the Control Code field is set to 0x0 (in-band response requested) or 0x1 (out-of-band response requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security or congestion control mechanism. 4.1.4. Transmitting a Loss Measurement Response When constructing a Response to an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 1. The value of the T flag - MUST be copied from the LM Query, and if the value of the T flag is - 1, the value of the TC field MUST also be copied. + MUST be copied from the LM Query. The X flag MUST be set to 0 if the transmitting interface writes 32- bit LM counters; otherwise its value MUST be copied from the LM Query. The B flag MUST be copied from the LM Query. The Session Identifier, Origin Timestamp, and Origin Timestamp Format fields MUST be copied from the LM Query. The Counter 1 and Counter 2 fields from the LM Query MUST be copied to the Counter 3 and Counter 4 fields, respectively, of the LM Response. @@ -1382,28 +1412,28 @@ 4.1.9. Test Messages In the case of inferred LM, the packets counted for LM consist of test messages generated for this purpose, or of some other class of packets deemed to provide a good proxy for data packets flowing over the channel. The specification of test protocols and proxy packets is outside the scope of this document. An identifier common to both the test or proxy messages and the LM messages may be required to make correlation possible. The combined - value of the Session Identifier and 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 include a 32-bit field which can carry the value of the combined - Session Identifier + TC field present in LM messages. When TC- - specific LM is conducted, the TC field of the LSE in the label stack + Session Identifier + DS field present in LM messages. When TC- + specific LM is conducted, the DS field of the LSE in the label stack of a test message corresponding to the channel (e.g. LSP) over which - the message is sent MUST equal the TC value in the associated LM - messages. + the message is sent MUST correspond to the DS value in the associated + LM messages. 4.1.10. Message Loss and Packet Misorder Conditions Because an LM operation consists of a message sequence with state maintained from one message to the next, LM is subject to the effects of lost messages and misordered packets in a way that DM is not. Because this state exists only on the querier, the handling of these conditions is, strictly speaking, a local matter. This section, however, presents recommended procedures for handling such conditions. @@ -1468,21 +1498,21 @@ messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: in-band response requested). The Querier Timestamp Format field MUST be set to the timestamp format used by the querier when writing timestamp fields in this message; the possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's Preferred Timestamp Format fields MUST be set to 0. - The Session Identifier field can be set arbitrarily. The TC field + The Session Identifier field can be set arbitrarily. The DS field MUST be set to the traffic class being measured. The Timestamp 1 field SHOULD be set to the time at which this DM Query is transmitted, in the format indicated by the Querier Timestamp Format field. The other timestamp fields MUST be set to 0. 4.2.2. Receiving a Delay Measurement Query Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be set to the time at which this DM Query is received. @@ -1494,24 +1524,24 @@ requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security or congestion control mechanism. 4.2.3. Transmitting a Delay Measurement Response When constructing a Response to a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 1, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0. - The Session Identifier, TC, and Querier Timestamp Format (QTF) fields - MUST be copied from the DM Query. The Timestamp 1 and Timestamp 2 - fields from the DM Query MUST be copied to the Timestamp 3 and - Timestamp 4 fields, respectively, of the DM Response. + The Session Identifier and Querier Timestamp Format (QTF) fields MUST + be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields + from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 + fields, respectively, of the DM Response. The Responder Timestamp Format (RTF) field MUST be set to the timestamp format used by the responder when writing timestamp fields in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; the possible values for this field are listed in Section 3.4. Furthermore, the RTF field MUST be set equal either to the QTF or the RPTF field. See Section 4.2.5 for guidelines on selection of the value for this field. The Responder's Preferred Timestamp Format (RPTF) field MUST be set @@ -1593,22 +1623,22 @@ is always set equal to the RTF; o All DM Responses received with RTF not equal to QTF are discarded; o On a unidirectional channel, all DM Queries received with QTF not equal to the supported format are discarded. 4.2.6. Quality of Service 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 - DM message. + being measured MUST be set to the value that corresponds to the DS + field in the DM message. 4.3. Combined Loss/Delay Measurement Procedures The combined LM/DM message defined in Section 3.3 allows loss and delay measurement to be carried out simultaneously. This message SHOULD be treated as an LM message which happens to carry additional timestamp data, with the timestamp fields processed as per delay measurement procedures. 5. Congestion Considerations @@ -1664,33 +1694,130 @@ causing service impairment; the possibility of unauthorized alteration of messages in transit; and the possibility of an unauthorized device learning the data contained in or implied by such messages. The first consideration is discussed in Section 5. If reception or alteration of performance-related data by unauthorized devices is an operational concern, authentication and/or encryption procedures should be used to ensure message integrity and confidentiality. Such 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 - A future version of this document will detail IANA considerations - for: + This document makes the following requests of IANA: - o ACH Channel Types for LM and DM messages - o Timestamp format registry + o Allocation of Channel Types in the PW Associated Channel Type + 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 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, and to Linda Dunbar for the idea of using LM messages for throughput measurement. @@ -1699,71 +1826,84 @@ 9.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, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. + [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, + P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- + Protocol Label Switching (MPLS) Support of Differentiated + Services", RFC 3270, May 2002. + + [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching + (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic + Class" Field", RFC 5462, February 2009. + [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. 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., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 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. + [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. [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. - [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, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010. Authors' Addresses - Dan Frost (editor) + Dan Frost Cisco Systems Email: danfrost@cisco.com - - Stewart Bryant (editor) + Stewart Bryant Cisco Systems Email: stbryant@cisco.com