< draft-ietf-mpls-loss-delay-02.txt   draft-ietf-mpls-loss-delay-03.txt >
MPLS D. Frost MPLS D. Frost
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 22, 2011 April 20, 2011 Expires: December 3, 2011 June 1, 2011
Packet Loss and Delay Measurement for MPLS Networks Packet Loss and Delay Measurement for MPLS Networks
draft-ietf-mpls-loss-delay-02 draft-ietf-mpls-loss-delay-03
Abstract Abstract
Many service provider service level agreements (SLAs) depend on the Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning, characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol troubleshooting, and evaluation. This document specifies protocol
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 22, 2011. This Internet-Draft will expire on December 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.3.3. Transmitting a Delay Measurement Response . . . . . . 39 4.3.3. Transmitting a Delay Measurement Response . . . . . . 39
4.3.4. Receiving a Delay Measurement Response . . . . . . . . 40 4.3.4. Receiving a Delay Measurement Response . . . . . . . . 40
4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 40 4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 40
4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 41 4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 41
4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 41 4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 41
5. Implementation Disclosure Requirements . . . . . . . . . . . . 41 5. Implementation Disclosure Requirements . . . . . . . . . . . . 41
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 42 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8.1. Allocation of PW Associated Channel Types . . . . . . . . 44 8.1. Allocation of PW Associated Channel Types . . . . . . . . 44
8.2. Creation of Measurement Timestamp Type Registry . . . . . 44 8.2. Creation of Measurement Timestamp Type Registry . . . . . 45
8.3. Creation of MPLS Loss/Delay Measurement Control Code 8.3. Creation of MPLS Loss/Delay Measurement Control Code
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 45 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.4. Creation of MPLS Loss/Delay Measurement TLV Object 8.4. Creation of MPLS Loss/Delay Measurement TLV Object
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 46 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 48 10.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. Default Timestamp Format Rationale . . . . . . . . . 49 Appendix A. Default Timestamp Format Rationale . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Many service provider service level agreements (SLAs) depend on the Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning, characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol troubleshooting, and evaluation. This document specifies protocol
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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, delay, Channel (G-ACh) [RFC5586] and support measurement of loss, delay,
and related metrics over Label Switched Paths (LSPs), pseudowires, and related metrics over Label Switched Paths (LSPs), pseudowires,
and MPLS 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]. A profile describing the minimal functional subset of
the LM and DM protocols in the MPLS-TP context is provided in
[I-D.ietf-mpls-tp-loss-delay-profile].
o The LM and DM protocols can be used for both continuous/proactive o The LM and DM protocols can be used both for continuous/proactive
and selective/on-demand measurement. and selective/on-demand measurement.
o The LM and DM protocols use a simple query/response model for o The LM and DM protocols use a simple query/response model for
bidirectional measurement that allows a single node - the querier bidirectional measurement that allows a single node - the querier
- to measure the loss or delay in both directions. - to measure the loss or delay in both directions.
o The LM and DM protocols use query messages for unidirectional loss o The LM and DM protocols use query messages for unidirectional loss
and delay measurement. The measurement can either be carried out and delay measurement. The measurement can either be carried out
at the downstream node(s) or at the querier if an out-of-band at the downstream node(s) or at the querier if an out-of-band
return path is available. return path is available.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
unused, thereby providing B with equivalent information to that unused, thereby providing B with equivalent information to that
learned by A. learned by A.
The dyadic procedure has the advantage of halving the number of The dyadic procedure has the advantage of halving the number of
messages required for both A and B to perform a given kind of messages required for both A and B to perform a given kind of
measurement, but comes at the expense of each node's ability to measurement, but comes at the expense of each node's ability to
control its own measurement process independently, and introduces control its own measurement process independently, and introduces
additional operational complexity into the measurement protocols. additional operational complexity into the measurement protocols.
The quantity of measurement traffic is also expected to be low The quantity of measurement traffic is also expected to be low
relative to that of user traffic, particularly when 64-bit counters relative to that of user traffic, particularly when 64-bit counters
are used for LM. Consequently this document does not attempt to are used for LM. Consequently this document does not specify a
specify a dyadic operational mode. It is however still possible, and dyadic operational mode. It is however still possible, and may be
may be useful, for A to perform the extra copy, thereby providing useful, for A to perform the extra copy, thereby providing additional
additional information to B even when its participation in the information to B even when its participation in the measurement
measurement process is passive. process is passive.
2.8. Loopback Measurement 2.8. Loopback Measurement
Some bidirectional channels may be placed into a loopback state such Some bidirectional channels may be placed into a loopback state such
that messages are looped back to the sender without modification. In that messages are looped back to the sender without modification. In
this situation, LM and DM procedures can be used to carry out this situation, LM and DM procedures can be used to carry out
measurements associated with the circular path. This is done by measurements associated with the circular path. This is done by
generating "queries" with the Response flag set to 1. generating "queries" with the Response flag set to 1.
For LM, the loss computation in this case is: For LM, the loss computation in this case is:
skipping to change at page 17, line 47 skipping to change at page 17, line 47
The delay measurement procedures described in this document are The delay measurement procedures described in this document are
designed to facilitate hardware-assisted measurement and to function designed to facilitate hardware-assisted measurement and to function
in the same way whether or not such hardware assistance is used. The in the same way whether or not such hardware assistance is used. The
main difference in the two cases is one of measurement accuracy. main difference in the two cases is one of measurement accuracy.
Implementations MUST make their delay measurement accuracy levels Implementations MUST make their delay measurement accuracy levels
clear to the user. clear to the user.
2.9.11. Delay Measurement Timestamp Format 2.9.11. Delay Measurement Timestamp Format
There are two significant timestamp formats in common use: the There are two significant timestamp formats in common use: the
timestamp format of the Internet standard Network Time Protocol timestamp format of the Network Time Protocol (NTP), described in
(NTP), described in [RFC5905], and the timestamp format used in the [RFC5905], and the timestamp format used in the IEEE 1588 Precision
IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. Time Protocol (PTP) [IEEE1588].
The NTP format has the advantages of wide use and long deployment in The NTP format has the advantages of wide use and long deployment in
the Internet, and was specifically designed to make the computation the Internet, and was specifically designed to make the computation
of timestamp differences as simple and efficient as possible. On the of timestamp differences as simple and efficient as possible. On the
other hand, there is also now a significant deployment of equipment other hand, there is also now a significant deployment of equipment
designed to support the PTP format. designed to support the PTP format.
The approach taken in this document is therefore to include in DM The approach taken in this document is therefore to include in DM
messages fields which identify the timestamp formats used by the two messages fields which identify the timestamp formats used by the two
devices involved in a DM operation. This implies that a node devices involved in a DM operation. This implies that a node
attempting to carry out a DM operation may be faced with the problem attempting to carry out a DM operation may be faced with the problem
of computing with and possibly reconciling different timestamp of computing with and possibly reconciling different timestamp
formats. Timestamp format support requirements are specified in formats. To ensure interoperability it is necessary that support of
Section 3.4. at least one timestamp format is mandatory. This specification
requires the support of the IEEE 1588 PTP format. Timestamp format
support requirements are discussed in detail in Section 3.4.
3. Message Formats 3. Message Formats
Loss Measurement and Delay Measurement messages flow over the MPLS Loss Measurement and Delay Measurement messages flow over the MPLS
Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet
containing an LM or DM message contains an MPLS label stack, with the containing an LM or DM message contains an MPLS label stack, with the
G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by
an Associated Channel Header (ACH) which identifies the message type, an Associated Channel Header (ACH) which identifies the message type,
and the message body follows the ACH. and the message body follows the ACH.
This document defines the following ACH Channel Types: This document defines the following ACH Channel Types:
MPLS Direct Packet Loss Measurement (DLM) MPLS Direct Packet Loss Measurement (DLM)
MPLS Inferred Packet Loss Measurement (ILM) MPLS Inferred Packet Loss Measurement (ILM)
MPLS Packet Delay Measurement (DM) MPLS Packet Delay Measurement (DM)
MPLS Direct Packet Loss and Delay Measurement (DLM+DM) MPLS Direct Packet Loss and Delay Measurement (DLM+DM)
MPLS Inferred Packet Loss and Delay Measurement (ILM+DM) MPLS Inferred Packet Loss and Delay Measurement (ILM+DM)
The message formats for direct and inferred LM are identical, as are The message formats for direct and inferred LM are identical. The
the formats for the DLM+DM and ILM+DM messages. formats of the DLM+DM and ILM+DM messages are also identical.
For these channel types, the ACH SHALL NOT be followed by the ACH TLV For these channel types, the ACH SHALL NOT be followed by the ACH TLV
Header defined in [RFC5586]. Header defined in [RFC5586].
The fixed-format portion of a message MAY be followed by a block of The fixed-format portion of a message MAY be followed by a block of
Type-Length-Value (TLV) fields. The TLV block provides an extensible Type-Length-Value (TLV) fields. The TLV block provides an extensible
way of attaching subsidiary information to LM and DM messages. way of attaching subsidiary information to LM and DM messages.
Several such TLV fields are defined below. Several such TLV fields are defined below.
All integer values for fields defined in this document SHALL be All integer values for fields defined in this document SHALL be
skipping to change at page 20, line 20 skipping to change at page 20, line 20
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 of the Origin Timestamp field Origin Timestamp Format of the Origin Timestamp field
Format (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
Differentiated Differentiated Services Code Point (DSCP) being Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured Services (DS) Field measured
Origin Timestamp Query message transmission timestamp Origin Timestamp 64-bit field for query message transmission
Counter 1-4 LM counter values timestamp
Counter 1-4 64-bit fields for LM counter values
TLV Block Optional block of Type-Length-Value fields 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.
+-+-+-+-+ +-+-+-+-+
|R|T|0|0| |R|T|0|0|
skipping to change at page 21, line 19 skipping to change at page 21, line 21
0x1: Out-of-band Response Requested. Indicates that the 0x1: Out-of-band Response Requested. Indicates that the
response should be sent via an out-of-band channel. response should be sent via an out-of-band channel.
0x2: No Response Requested. Indicates that no response to the 0x2: No Response Requested. Indicates that no response to the
query should be sent. This mode can be used, for example, if query should be sent. This mode can be used, for example, if
all nodes involved are being controlled by a Network Management all nodes involved are being controlled by a Network Management
System. System.
For a Response: For a Response:
Codes 0x0-0xF are reserved for non-error responses. Codes 0x0-0xF are reserved for non-error responses. Error
response codes imply that the response does not contain valid
measurement data.
0x1: Success. Indicates that the operation was successful. 0x1: Success. Indicates that the operation was successful.
0x2: Notification - Data Format Invalid. Indicates that the 0x2: Notification - Data Format Invalid. Indicates that the
query was processed but the format of the data fields in this query was processed but the format of the data fields in this
response may be inconsistent. Consequently these data fields response may be inconsistent. Consequently these data fields
MUST NOT be used for measurement. MUST NOT be used for measurement.
0x3: Notification - Initialization In Progress. Indicates that 0x3: Notification - Initialization In Progress. Indicates that
the query was processed but this response does not contain the query was processed but this response does not contain
skipping to change at page 22, line 50 skipping to change at page 23, line 6
failed because node resources for this measurement session were failed because node resources for this measurement session were
administratively released. administratively released.
0x1C: Error - Invalid Message. Indicates that the operation 0x1C: Error - Invalid Message. Indicates that the operation
failed because the received query message was malformed. failed because the received query message was malformed.
0x1D: Error - Protocol Error. Indicates that the operation 0x1D: Error - Protocol Error. Indicates that the operation
failed because a protocol error was found in the received query failed because a protocol error was found in the received query
message. message.
Message Length: Set to the total length of this message in bytes. Message Length: Set to the total length of this message in bytes,
including the Version, Flags, Control Code, and Message Length
fields.
DFlags: The format of the DFlags field is shown below. DFlags: The format of the DFlags field is shown below.
+-+-+-+-+ +-+-+-+-+
|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:
skipping to change at page 25, line 34 skipping to change at page 25, line 35
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. The T flag in a DM message is Flags: As specified in Section 3.1. The T flag in a DM message is
set to 1. set to 1.
Control Code: As specified in Section 3.1. Control Code: As specified in Section 3.1.
Message Length: Set to the total length of this message in bytes. Message Length: Set to the total length of this message in bytes,
including the Version, Flags, Control Code, and Message Length
fields.
Querier Timestamp Format: The format of the timestamp values written Querier Timestamp Format: The format of the timestamp values written
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.
skipping to change at page 28, line 16 skipping to change at page 28, line 16
is to be viewed as a simple 64-bit sequence number. This provides is to be viewed as a simple 64-bit sequence number. This provides
a simple solution for applications that do not require a real a simple solution for applications that do not require a real
absolute timestamp, but only an indication of message ordering; an absolute timestamp, but only an indication of message ordering; an
example is LM exception detection. example is LM exception detection.
2: 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.
3: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp 3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time
format [IEEE1588]. This format consists of a 32-bit seconds field Protocol timestamp format [IEEE1588]. This truncated format
followed by a 32-bit nanoseconds field. consists of a 32-bit seconds field followed by a 32-bit
nanoseconds field, and is the same as the IEEE 1588v1 timestamp
format.
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-
order bits of the field. The remaining 64 - n low-order bits in the order bits of the field. The remaining 64 - n low-order bits in the
field SHOULD be set to 0 and MUST be ignored when reading the field. field SHOULD be set to 0 and MUST be ignored when reading the field.
To ensure that it is possible to find an interoperable mode between To ensure that it is possible to find an interoperable mode between
implementations it is necessary to select one timestamp format as the implementations it is necessary to select one timestamp format as the
default. The timestamp format chosen as the default is IEEE 1588v1 default. The timestamp format chosen as the default is the truncated
PTP; this format MUST be supported. The rationale for this choice is IEEE 1588 PTP format (format code 3 in the list above); this format
discussed in Appendix A. Implementations SHOULD also be capable of MUST be supported. The rationale for this choice is discussed in
reading timestamps written in NTPv4 64-bit format and reconciling Appendix A. Implementations SHOULD also be capable of reading
them internally with PTP timestamps for measurement purposes. timestamps written in NTPv4 64-bit format and reconciling them
Support for other timestamp formats is OPTIONAL. internally with PTP timestamps for measurement purposes. Support for
other timestamp formats is OPTIONAL.
The implementation MUST make clear which timestamp formats it The implementation MUST make clear which timestamp formats it
supports and the extent of its support for computation with and supports and the extent of its support for computation with and
reconciliation of different formats for measurement purposes. reconciliation of different formats for measurement purposes.
3.5. TLV Objects 3.5. TLV Objects
The TLV Block in LM and DM messages consists of zero or more objects The TLV Block in LM and DM messages consists of zero or more objects
with the following format: with the following format:
skipping to change at page 29, line 26 skipping to change at page 29, line 29
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 Session Query Interval 2 Session Query Interval
3 Loopback Request 3 Loopback Request
4-119 Reserved 4-126 Unallocated
120-127 Implementation-specific usage 127 Experimental use
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-254 Unallocated
248-255 Implementation-specific usage 255 Experimental use
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. Asymmetrical padding may be to, or omitted from, the response. Asymmetrical padding may be
useful when responses are delivered out-of-band or when different useful when responses are delivered out-of-band or when different
maximum transmission unit sizes apply to the two components of a maximum transmission unit sizes apply to the two components of a
bidirectional channel. bidirectional channel.
More than one padding object MAY be present, in which case they More than one padding object MAY be present, in which case they MUST
SHOULD be continguous. Padding objects SHOULD occur at the end of be contiguous. The Value field of a padding object is arbitrary.
the TLV Block. The Value field of 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 | Address Family | | Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 37 skipping to change at page 43, line 37
which a response is never received) and set a corresponding which a response is never received) and set a corresponding
Measurement Message Loss Threshold. If this threshold is exceeded, Measurement Message Loss Threshold. If this threshold is exceeded,
the measurement operation SHOULD be suspended so as not to exacerbate the measurement operation SHOULD be suspended so as not to exacerbate
the possible congestion condition. This suspension SHOULD be the possible congestion condition. This suspension SHOULD be
accompanied by an appropriate notification to the user so that the accompanied by an appropriate notification to the user so that the
condition can be investigated and corrected. condition can be investigated and corrected.
From the receiver perspective, the main consideration is the From the receiver perspective, the main consideration is the
possibility of receiving an excessive quantity of measurement possibility of receiving an excessive quantity of measurement
messages. An implementation SHOULD employ a mechanism such as rate- messages. An implementation SHOULD employ a mechanism such as rate-
limiting to guard against the effects of this case. Authentication limiting to guard against the effects of this case.
procedures can also be used to ensure that only queries from
authorized devices are processed.
7. Security Considerations 7. Security Considerations
There are three main types of security considerations associated with This document describes procedures for the measurement of performance
the exchange of performance monitoring messages such as those metrics over a pre-existing MPLS path (a pseudowire, LSP, or
described in this document: the possibility of a malicious or section). As such it assumes that a node involved in a measurement
misconfigured device generating an excessive quantity of messages, operation has previously verified the integrity of the path and the
causing service impairment; the possibility of unauthorized identity of the far end using existing MPLS mechanisms such as
alteration of messages in transit; and the possibility of an Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
unauthorized device learning the data contained in or implied by such techniques, and considerations for securing MPLS paths are discussed
messages. in detail in [RFC5920].
The first consideration is discussed in Section 6. If reception or When such mechanisms are not available, and where security of the
alteration of performance-related data by unauthorized devices is an measurement operation is a concern, reception of Generic Associated
operational concern, authentication and/or encryption procedures Channel messages with the Channel Types specified in this document
should be used to ensure message integrity and confidentiality. Such SHOULD be disabled. Implementations MUST provide the ability to
procedures are outside the scope of this document, but have general disable these protocols on a per-Channel-Type basis.
applicability to OAM protocols in MPLS networks.
Even when the identity of the far end has been verified, the
measurement protocols remain vulnerable to injection and man-in-the-
middle attacks. The impact of such an attack would be to compromise
the quality of performance measurements on the affected path. An
attacker positioned to disrupt these measurements is, however,
capable of causing much greater damage by disrupting far more
critical elements of the network such as the network control plane or
user traffic flows. A disruption of the measurement protocols would
at worst interfere with the monitoring of the performance aspects of
the service level agreement associated with the path; the existence
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.
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 8. IANA Considerations
This document makes the following requests of IANA: This document makes the following requests of IANA:
o Allocation of Channel Types in the PW Associated Channel Type o Allocation of Channel Types in the PW Associated Channel Type
registry registry
o Creation of a Measurement Timestamp Type registry o Creation of a Measurement Timestamp Type registry
skipping to change at page 45, line 11 skipping to change at page 45, line 30
IANA is requested to create a new Measurement Timestamp Type IANA is requested to create a new Measurement Timestamp Type
registry, with format and initial allocations as follows: registry, with format and initial allocations as follows:
Type Description Size in bits Reference Type Description Size in bits Reference
---- -------------------------------------- ------------ ------------ ---- -------------------------------------- ------------ ------------
0 Null Timestamp 64 (this draft) 0 Null Timestamp 64 (this draft)
1 Sequence Number 64 (this draft) 1 Sequence Number 64 (this draft)
2 Network Time Protocol version 4 64-bit 64 (this draft) 2 Network Time Protocol version 4 64-bit 64 (this draft)
Timestamp Timestamp
3 IEEE 1588 version 1 Timestamp 64 (this draft) 3 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft)
The range of the Type field is 0-15. The range of the Type field is 0-15.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
8.3. Creation of MPLS Loss/Delay Measurement Control Code Registry 8.3. Creation of MPLS Loss/Delay Measurement Control Code Registry
IANA is requested to create a new MPLS Loss/Delay Measurement Control IANA is requested to create a new MPLS Loss/Delay Measurement Control
Code registry. This registry is divided into two separate parts, one Code registry. This registry is divided into two separate parts, one
for Query Codes and the other for Response Codes, with formats and for Query Codes and the other for Response Codes, with formats and
skipping to change at page 47, line 5 skipping to change at page 47, line 5
The range of the Code field is 0 - 255. The range of the Code field is 0 - 255.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
8.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry 8.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry
IANA is requested to create a new MPLS Loss/Delay Measurement TLV IANA is requested to create a new MPLS Loss/Delay Measurement TLV
Object registry, with format and initial allocations as follows: Object registry, with format and initial allocations as follows:
Type Description Reference Type Description Reference
------- --------------------------------- ------------ ---- --------------------------------- ------------
0 Padding - copy in response (this draft) 0 Padding - copy in response (this draft)
1 Return Address (this draft) 1 Return Address (this draft)
2 Session Query Interval (this draft) 2 Session Query Interval (this draft)
3 Loopback Request (this draft) 3 Loopback Request (this draft)
120-127 Implementation-specific usage (this draft) 127 Experimental use (this draft)
128 Padding - do not copy in response (this draft) 128 Padding - do not copy in response (this draft)
129 Destination Address (this draft) 129 Destination Address (this draft)
130 Source Address (this draft) 130 Source Address (this draft)
248-255 Implementation-specific usage (this draft) 255 Experimental use (this draft)
IANA is also requested to indicate that Types 0-127 are classified as IANA is also requested to indicate that Types 0-127 are classified as
Mandatory, and that Types 128-255 are classified as Optional. Mandatory, and that Types 128-255 are classified as Optional.
The range of the Type field is 0 - 255. The range of the Type field is 0 - 255.
The allocation policy for this registry is IETF Review, except for The allocation policy for this registry is IETF Review, except for
the ranges marked "Implementation-specific usage", for which the the ranges marked "Implementation-specific usage", for which the
policy is Private Use. policy is Private Use.
skipping to change at page 48, line 27 skipping to change at page 48, line 27
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
10.2. Informative References 10.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 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 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.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010. RFC 5921, July 2010.
[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.
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms [Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms
for Ethernet based Networks", February 2008. for Ethernet based Networks", February 2008.
Appendix A. Default Timestamp Format Rationale Appendix A. Default Timestamp Format Rationale
This document initially proposed the Network Time Protocol (NTP) This document initially proposed the Network Time Protocol (NTP)
timestamp format as the mandatory default, as this is the normal timestamp format as the mandatory default, as this is the normal
default timestamp in IETF protocols and thus would seem the "natural" default timestamp in IETF protocols and thus would seem the "natural"
choice. However a number of considerations have led instead to the choice. However a number of considerations have led instead to the
specification of the truncated IEEE1588 Precision Time Protocol (PTP) specification of the truncated IEEE 1588 Precision Time Protocol
timestamp as the default. NTP has not gained traction in industry as (PTP) timestamp as the default. NTP has not gained traction in
the protocol of choice for high quality timing infrastructure, whilst industry as the protocol of choice for high quality timing
IEEE1588 PTP has become the de facto time transfer protocol in infrastructure, whilst IEEE 1588 PTP has become the de facto time
networks which are specially engineered to provide high accuracy time transfer protocol in networks which are specially engineered to
distribution service. The PTP timestamp format is also the ITU-T provide high accuracy time distribution service. The PTP timestamp
format of choice for packet transport networks, which may rely on format is also the ITU-T format of choice for packet transport
MPLS protocols. Applications such as one-way delay measurement need networks, which may rely on MPLS protocols. Applications such as
the best time service available, and converting between the NTP and one-way delay measurement need the best time service available, and
PTP timestamp formats is not a trivial transformation, particularly converting between the NTP and PTP timestamp formats is not a trivial
when it is required that this be done in real time without loss of transformation, particularly when it is required that this be done in
accuracy. real time without loss of accuracy.
The truncated IEEE1588 PTP format specified in this document is The truncated IEEE 1588 PTP format specified in this document is
considered to provide a more than adequate wrap time and greater time considered to provide a more than adequate wrap time and greater time
resolution than it is expected will be needed for the operational resolution than it is expected will be needed for the operational
lifetime of this protocol. By truncating the timestamp at both the lifetime of this protocol. By truncating the timestamp at both the
high and low order bits, the protocol achieves a worthwhile reduction high and low order bits, the protocol achieves a worthwhile reduction
in system resources. in system resources.
Authors' Addresses Authors' Addresses
Dan Frost Dan Frost
Cisco Systems Cisco Systems
 End of changes. 30 change blocks. 
82 lines changed or deleted 128 lines changed or added

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