draft-ietf-mpls-tp-loss-delay-profile-04.txt   rfc6375.txt 
MPLS D. Frost, Ed. Internet Engineering Task Force (IETF) D. Frost, Ed.
Internet-Draft S. Bryant, Ed. Request for Comments: 6375 S. Bryant, Ed.
Intended status: Informational Cisco Systems Category: Informational Cisco Systems
Expires: January 20, 2012 July 19, 2011 ISSN: 2070-1721 September 2011
A Packet Loss and Delay Measurement Profile for MPLS-based Transport A Packet Loss and Delay Measurement Profile
Networks for MPLS-Based Transport Networks
draft-ietf-mpls-tp-loss-delay-profile-04
Abstract Abstract
Procedures and protocol mechanisms to enable efficient and accurate Procedures and protocol mechanisms to enable efficient and accurate
measurement of packet loss, delay, and throughput in MPLS networks measurement of packet loss, delay, and throughput in MPLS networks
are defined in RFC XXXX. are defined in RFC 6374.
The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol
functions applicable to the construction and operation of packet- functions applicable to the construction and operation of packet-
switched transport networks. switched transport networks.
This document describes a profile of the general MPLS loss, delay, This document describes a profile of the general MPLS loss, delay,
and throughput measurement techniques that suffices to meet the and throughput measurement techniques that suffices to meet the
specific requirements of MPLS-TP. specific requirements of MPLS-TP.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities (PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T. of a packet transport network as defined by the ITU-T.
This Informational Internet-Draft is aimed at achieving IETF Status of This Memo
Consensus before publication as an RFC and will be subject to an IETF
Last Call.
[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF consensus.]
[RFC Editor, please replace XXXX with the RFC number assigned to
draft-ietf-mpls-loss-delay.]
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 20, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6375.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
Procedures for the measurement of packet loss, delay, and throughput Procedures for the measurement of packet loss, delay, and throughput
in MPLS networks are defined in [I-D.ietf-mpls-loss-delay]. This in MPLS networks are defined in [RFC6374]. This document describes a
document describes a profile, i.e. a simplified subset, of these profile, i.e., a simplified subset, of these procedures that suffices
procedures that suffices to meet the specific requirements of MPLS- to meet the specific requirements of MPLS-based transport networks
based transport networks [RFC5921] as defined in [RFC5860]. This [RFC5921] as defined in [RFC5860]. This profile is presented for the
profile is presented for the convenience of implementors who are convenience of implementors who are concerned exclusively with the
concerned exclusively with the transport network context. transport network context.
The use of the profile specified in this document is purely optional. The use of the profile specified in this document is purely optional.
Implementors wishing to provide enhanced functionality that is within Implementors wishing to provide enhanced functionality that is within
the scope of [I-D.ietf-mpls-loss-delay] but outside the scope of this the scope of [RFC6374] but outside the scope of this profile may do
profile may do so, whether or not the implementation is restricted to so, whether or not the implementation is restricted to the transport
the transport network context. network context.
The assumption of this profile is that the devices involved in a The assumption of this profile is that the devices involved in a
measurement operation are configured for measurement by a means measurement operation are configured for measurement by a means
external to the measurement protocols themselves, for example via a external to the measurement protocols themselves, for example, via a
Network Management System (NMS) or separate configuration protocol. Network Management System (NMS) or separate configuration protocol.
The manageability considerations in [I-D.ietf-mpls-loss-delay] apply, The manageability considerations in [RFC6374] apply, and further
and further information on MPLS-TP network management can be found in information on MPLS-TP network management can be found in [RFC5950].
[RFC5950].
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities (PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T. of a packet transport network as defined by the ITU-T.
2. MPLS-TP Measurement Considerations 2. MPLS-TP Measurement Considerations
The measurement considerations discussed in Section 2.9 of The measurement considerations discussed in Section 2.9 of [RFC6374]
[I-D.ietf-mpls-loss-delay] apply also in the context of MPLS-TP, apply also in the context of MPLS-TP, except for the following, which
except for the following, which pertain to topologies excluded from pertain to topologies excluded from MPLS-TP:
MPLS-TP:
o Equal Cost Multipath considerations (Section 2.9.4 of o Equal Cost Multipath considerations (Section 2.9.4 of [RFC6374])
[I-D.ietf-mpls-loss-delay])
o Considerations for direct Loss Measurement (LM) in the presence of o Considerations for direct Loss Measurement (LM) in the presence of
Label Switched Paths constructed via the Label Distribution Label Switched Paths constructed via the Label Distribution
Protocol (LDP) or utilizing Penultimate Hop Popping (Section 2.9.8 Protocol (LDP) or utilizing Penultimate Hop Popping (Section 2.9.8
of [I-D.ietf-mpls-loss-delay]) of [RFC6374])
3. Packet Loss Measurement (LM) Profile 3. Packet Loss Measurement (LM) Profile
When an LM session is externally configured, the values of several When an LM session is externally configured, the values of several
protocol parameters can be fixed in advance at the endpoints involved protocol parameters can be fixed in advance at the endpoints involved
in the session, so that negotiation of these parameters is not in the session, so that negotiation of these parameters is not
required. These parameters, and their default values as specified by required. These parameters, and their default values as specified by
this profile, are as follows: this profile, are as follows:
Parameter Default Value Parameter Default Value
----------------------------------------- -------------------------- ----------------------------------------- --------------------------
Query control code In-band response requested Query control code In-band Response Requested
Byte/packet Count (B) Flag Packet count Byte/packet Count (B) Flag Packet count
Traffic-Class-specific (T) Flag Traffic-class-scoped Traffic-class-specific (T) Flag Traffic-class-scoped
Origin Timestamp Format (OTF) Truncated IEEE 1588v2 Origin Timestamp Format (OTF) Truncated IEEE 1588v2
A simple implementation may assume that external configuration will A simple implementation may assume that external configuration will
ensure that both ends of the communication are using the default ensure that both ends of the communication are using the default
values for these parameters. Implementations are, however, strongly values for these parameters. However, implementations are strongly
advised to validate the values of these parameters in received advised to validate the values of these parameters in received
messages so that configuration inconsistencies can be detected and messages so that configuration inconsistencies can be detected and
reported. reported.
LM message rates (and test message rates, when inferred LM is used) LM message rates (and test message rates, when inferred LM is used)
should be configurable by the network operator on a per-channel should be configurable by the network operator on a per-channel
basis. The following intervals should be supported: basis. The following intervals should be supported:
Message Type Supported Intervals Message Type Supported Intervals
-------------- ------------------------------------------------------ -------------- ------------------------------------------------------
skipping to change at page 4, line 26 skipping to change at page 4, line 15
4. Packet Delay Measurement (DM) Profile 4. Packet Delay Measurement (DM) Profile
When a DM session is externally configured, the values of several When a DM session is externally configured, the values of several
protocol parameters can be fixed in advance at the endpoints involved protocol parameters can be fixed in advance at the endpoints involved
in the session, so that negotiation of these parameters is not in the session, so that negotiation of these parameters is not
required. These parameters, and their default values as specified by required. These parameters, and their default values as specified by
this profile, are as follows: this profile, are as follows:
Parameter Default Value Parameter Default Value
------------------------------------------ -------------------------- ------------------------------------------ --------------------------
Query control code In-band response requested Query control code In-band Response Requested
Querier Timestamp Format (QTF) Truncated IEEE 1588v2 Querier Timestamp Format (QTF) Truncated IEEE 1588v2
Responder Timestamp Format (RTF) Truncated IEEE 1588v2 Responder Timestamp Format (RTF) Truncated IEEE 1588v2
Responder's Preferred Timestamp Format Truncated IEEE 1588v2 Responder's Preferred Timestamp Format Truncated IEEE 1588v2
(RPTF) (RPTF)
This profile uses the MPLS Delay Measurement (DM) Channel Type in the
Associated Channel Header (ACH).
A simple implementation may assume that external configuration will A simple implementation may assume that external configuration will
ensure that both ends of the communication are using the default ensure that both ends of the communication are using the default
values for these parameters. Implementations are, however, strongly values for these parameters. However, implementations are strongly
advised to validate the values of these parameters in received advised to validate the values of these parameters in received
messages so that configuration inconsistencies can be detected and messages so that configuration inconsistencies can be detected and
reported. reported.
DM message rates should be configurable by the network operator on a DM message rates should be configurable by the network operator on a
per-channel basis. The following message intervals should be per-channel basis. The following message intervals should be
supported: 1 second, 10 seconds, 1 minute, 10 minutes. supported: 1 second, 10 seconds, 1 minute, 10 minutes.
5. Security Considerations 5. Security Considerations
This document delineates a subset of the procedures specified in This document delineates a subset of the procedures specified in
[I-D.ietf-mpls-loss-delay], and as such introduces no new security [RFC6374], and as such introduces no new security considerations in
considerations in itself. The security considerations discussed in itself. The security considerations discussed in [RFC6374] also
apply to the profile presented in this document. General
[I-D.ietf-mpls-loss-delay] apply also to the profile presented in considerations for MPLS-TP network security can be found in
this document. General considerations for MPLS-TP network security [SECURITY-FRAMEWORK].
can be found in [I-D.ietf-mpls-tp-security-framework].
6. IANA Considerations
This document introduces no new IANA considerations.
7. References
7.1. Normative References
[I-D.ietf-mpls-loss-delay] 6. References
Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks",
draft-ietf-mpls-loss-delay-03 (work in progress),
June 2011.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 6.1. Normative References
Associated Channel", RFC 5586, June 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
7.2. Informative References [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[I-D.ietf-mpls-tp-security-framework] 6.2. Informative References
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework",
draft-ietf-mpls-tp-security-framework-01 (work in
progress), May 2011.
[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.
[RFC5950] Mansfield, S., Gray, E., and K. Lam, "Network Management [RFC5950] Mansfield, S., Gray, E., and K. Lam, "Network Management
Framework for MPLS-based Transport Networks", RFC 5950, Framework for MPLS-based Transport Networks", RFC 5950,
September 2010. September 2010.
[SECURITY-FRAMEWORK]
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework", Work in Progress, May 2011.
Authors' Addresses Authors' Addresses
Dan Frost (editor) Dan Frost (editor)
Cisco Systems Cisco Systems
Email: danfrost@cisco.com EMail: danfrost@cisco.com
Stewart Bryant (editor) Stewart Bryant (editor)
Cisco Systems Cisco Systems
Email: stbryant@cisco.com EMail: stbryant@cisco.com
 End of changes. 28 change blocks. 
88 lines changed or deleted 56 lines changed or added

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