1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc6375.txt b/doc/rfc/rfc6375.txt
new file mode 100644
index 0000000..13a8336
--- /dev/null
+++ b/doc/rfc/rfc6375.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     D. Frost, Ed.
+Request for Comments: 6375                                S. Bryant, Ed.
+Category: Informational                                    Cisco Systems
+ISSN: 2070-1721                                           September 2011
+
+
+              A Packet Loss and Delay Measurement Profile
+                   for MPLS-Based Transport Networks
+
+Abstract
+
+   Procedures and protocol mechanisms to enable efficient and accurate
+   measurement of packet loss, delay, and throughput in MPLS networks
+   are defined in RFC 6374.
+
+   The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol
+   functions applicable to the construction and operation of packet-
+   switched transport networks.
+
+   This document describes a profile of the general MPLS loss, delay,
+   and throughput measurement techniques that suffices to meet the
+   specific requirements of MPLS-TP.
+
+   This document is a product of a joint Internet Engineering Task Force
+   (IETF) / International Telecommunication Union Telecommunication
+   Standardization Sector (ITU-T) effort to include an MPLS Transport
+   Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
+   (PWE3) architectures to support the capabilities and functionalities
+   of a packet transport network as defined by the ITU-T.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   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.
+
+   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.
+
+
+
+
+
+
+Frost & Bryant                Informational                     [Page 1]
+
+RFC 6375           MPLS-TP Loss and Delay Measurement     September 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   Procedures for the measurement of packet loss, delay, and throughput
+   in MPLS networks are defined in [RFC6374].  This document describes a
+   profile, i.e., a simplified subset, of these procedures that suffices
+   to meet the specific requirements of MPLS-based transport networks
+   [RFC5921] as defined in [RFC5860].  This profile is presented for the
+   convenience of implementors who are concerned exclusively with the
+   transport network context.
+
+   The use of the profile specified in this document is purely optional.
+   Implementors wishing to provide enhanced functionality that is within
+   the scope of [RFC6374] but outside the scope of this profile may do
+   so, whether or not the implementation is restricted to the transport
+   network context.
+
+   The assumption of this profile is that the devices involved in a
+   measurement operation are configured for measurement by a means
+   external to the measurement protocols themselves, for example, via a
+   Network Management System (NMS) or separate configuration protocol.
+   The manageability considerations in [RFC6374] apply, and further
+   information on MPLS-TP network management can be found in [RFC5950].
+
+   This document is a product of a joint Internet Engineering Task Force
+   (IETF) / International Telecommunication Union Telecommunication
+   Standardization Sector (ITU-T) effort to include an MPLS Transport
+   Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
+   (PWE3) architectures to support the capabilities and functionalities
+   of a packet transport network as defined by the ITU-T.
+
+
+
+
+
+
+
+Frost & Bryant                Informational                     [Page 2]
+
+RFC 6375           MPLS-TP Loss and Delay Measurement     September 2011
+
+
+2.  MPLS-TP Measurement Considerations
+
+   The measurement considerations discussed in Section 2.9 of [RFC6374]
+   apply also in the context of MPLS-TP, except for the following, which
+   pertain to topologies excluded from MPLS-TP:
+
+   o  Equal Cost Multipath considerations (Section 2.9.4 of [RFC6374])
+
+   o  Considerations for direct Loss Measurement (LM) in the presence of
+      Label Switched Paths constructed via the Label Distribution
+      Protocol (LDP) or utilizing Penultimate Hop Popping (Section 2.9.8
+      of [RFC6374])
+
+3.  Packet Loss Measurement (LM) Profile
+
+   When an LM session is externally configured, the values of several
+   protocol parameters can be fixed in advance at the endpoints involved
+   in the session, so that negotiation of these parameters is not
+   required.  These parameters, and their default values as specified by
+   this profile, are as follows:
+
+   Parameter                                 Default Value
+   ----------------------------------------- --------------------------
+   Query control code                        In-band Response Requested
+   Byte/packet Count (B) Flag                Packet count
+   Traffic-class-specific (T) Flag           Traffic-class-scoped
+   Origin Timestamp Format (OTF)             Truncated IEEE 1588v2
+
+   A simple implementation may assume that external configuration will
+   ensure that both ends of the communication are using the default
+   values for these parameters.  However, implementations are strongly
+   advised to validate the values of these parameters in received
+   messages so that configuration inconsistencies can be detected and
+   reported.
+
+   LM message rates (and test message rates, when inferred LM is used)
+   should be configurable by the network operator on a per-channel
+   basis.  The following intervals should be supported:
+
+   Message Type   Supported Intervals
+   -------------- ------------------------------------------------------
+   LM Message     100 milliseconds, 1 second, 10 seconds, 1 minute, 10
+                  minutes
+   Test Message   10 milliseconds, 100 milliseconds, 1 second, 10
+                  seconds, 1 minute
+
+
+
+
+
+
+Frost & Bryant                Informational                     [Page 3]
+
+RFC 6375           MPLS-TP Loss and Delay Measurement     September 2011
+
+
+4.  Packet Delay Measurement (DM) Profile
+
+   When a DM session is externally configured, the values of several
+   protocol parameters can be fixed in advance at the endpoints involved
+   in the session, so that negotiation of these parameters is not
+   required.  These parameters, and their default values as specified by
+   this profile, are as follows:
+
+   Parameter                                  Default Value
+   ------------------------------------------ --------------------------
+   Query control code                         In-band Response Requested
+   Querier Timestamp Format (QTF)             Truncated IEEE 1588v2
+   Responder Timestamp Format (RTF)           Truncated IEEE 1588v2
+   Responder's Preferred Timestamp Format     Truncated IEEE 1588v2
+   (RPTF)
+
+   A simple implementation may assume that external configuration will
+   ensure that both ends of the communication are using the default
+   values for these parameters.  However, implementations are strongly
+   advised to validate the values of these parameters in received
+   messages so that configuration inconsistencies can be detected and
+   reported.
+
+   DM message rates should be configurable by the network operator on a
+   per-channel basis.  The following message intervals should be
+   supported: 1 second, 10 seconds, 1 minute, 10 minutes.
+
+5.  Security Considerations
+
+   This document delineates a subset of the procedures specified in
+   [RFC6374], and as such introduces no new security considerations in
+   itself.  The security considerations discussed in [RFC6374] also
+   apply to the profile presented in this document.  General
+   considerations for MPLS-TP network security can be found in
+   [SECURITY-FRAMEWORK].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant                Informational                     [Page 4]
+
+RFC 6375           MPLS-TP Loss and Delay Measurement     September 2011
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
+              Operations, Administration, and Maintenance (OAM) in MPLS
+              Transport Networks", RFC 5860, May 2010.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374, September 2011.
+
+6.2.  Informative References
+
+   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
+              Berger, "A Framework for MPLS in Transport Networks",
+              RFC 5921, July 2010.
+
+   [RFC5950]  Mansfield, S., Gray, E., and K. Lam, "Network Management
+              Framework for MPLS-based Transport Networks", RFC 5950,
+              September 2010.
+
+   [SECURITY-FRAMEWORK]
+              Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
+              Security Framework", Work in Progress, May 2011.
+
+Authors' Addresses
+
+   Dan Frost (editor)
+   Cisco Systems
+
+   EMail: danfrost@cisco.com
+
+
+   Stewart Bryant (editor)
+   Cisco Systems
+
+   EMail: stbryant@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frost & Bryant                Informational                     [Page 5]
+