One document matched: draft-ietf-mpls-tp-loss-delay-profile-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-mpls-tp-loss-delay-profile-04"
     ipr="trust200902">
  <front>
    <title abbrev="MPLS-TP Loss and Delay Measurement">
      A Packet Loss and Delay Measurement Profile for MPLS-based Transport
      Networks
    </title>

    <author fullname="Dan Frost" initials="D" role="editor" surname="Frost">
      <organization>Cisco Systems</organization>

      <address>
        <email>danfrost@cisco.com</email>
      </address>
    </author>

    <author fullname="Stewart Bryant" initials="S" role="editor"
            surname="Bryant">
      <organization>Cisco Systems</organization>

      <address>
        <email>stbryant@cisco.com</email>
      </address>
    </author>

    <date year="2011" />

    <area>Routing</area>

    <workgroup>MPLS</workgroup>

    <keyword>MPLS</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Procedures and protocol mechanisms to enable efficient and accurate
      measurement of packet loss, delay, and throughput in MPLS networks are
      defined in RFC XXXX.</t>

      <t>The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol
      functions applicable to the construction and operation of packet-
      switched transport networks.</t>

      <t>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.</t>

      <t>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.</t>

      <t>This Informational Internet-Draft is aimed at achieving IETF
      Consensus before publication as an RFC and will be subject to an IETF
      Last Call.</t>

      <t>[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.]</t>

      <t>[RFC Editor, please replace XXXX with the RFC number assigned to
      draft-ietf-mpls-loss-delay.]</t>
    </abstract>

<!--
    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
-->
  </front>

  <middle>
    <section title="Introduction">
      <t>Procedures for the measurement of packet loss, delay, and throughput
      in MPLS networks are defined in <xref target="I-D.ietf-mpls-loss-delay"
      />.  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 <xref target="RFC5921" /> as defined in
      <xref target="RFC5860" />.  This profile is presented for the
      convenience of implementors who are concerned exclusively with the
      transport network context.</t>

      <t>The use of the profile specified in this document is purely optional.
      Implementors wishing to provide enhanced functionality that is within
      the scope of <xref target="I-D.ietf-mpls-loss-delay" /> but outside the
      scope of this profile may do so, whether or not the implementation is
      restricted to the transport network context.</t>

      <t>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 <xref
      target="I-D.ietf-mpls-loss-delay" /> apply, and further information
      on MPLS-TP network management can be found in <xref target="RFC5950"
      />.</t>

      <t>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.</t>
    </section>

    <section title="MPLS-TP Measurement Considerations">
      <t>The measurement considerations discussed in Section 2.9 of <xref
      target="I-D.ietf-mpls-loss-delay" /> apply also in the context of
      MPLS-TP, except for the following, which pertain to topologies excluded
      from MPLS-TP:

        <list style="symbols">
          <t>Equal Cost Multipath considerations (Section 2.9.4 of <xref
          target="I-D.ietf-mpls-loss-delay" />)</t>

          <t>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 <xref target="I-D.ietf-mpls-loss-delay" />)</t>
        </list>
      </t>
    </section>

    <section title="Packet Loss Measurement (LM) Profile">
      <t>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:</t>

        <texttable align="left" style="headers">
          <ttcol width="60%">Parameter</ttcol>
          <ttcol>Default Value</ttcol>

          <c>Query control code</c>
          <c>In-band response requested</c>

          <c>Byte/packet Count (B) Flag</c>
          <c>Packet count</c>

          <c>Traffic-Class-specific (T) Flag</c>
          <c>Traffic-class-scoped</c>

          <c>Origin Timestamp Format (OTF)</c>
          <c>Truncated IEEE 1588v2</c>
        </texttable>

       <t>A simple implementation may assume that external configuration will
       ensure that both ends of the communication are using the default values
       for these parameters.  Implementations are, however, strongly advised
       to validate the values of these parameters in received messages so that
       configuration inconsistencies can be detected and reported.</t>

       <t>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:</t>

        <texttable align="left" style="headers">
          <ttcol width="20%">Message Type</ttcol>
          <ttcol>Supported Intervals</ttcol>

          <c>LM Message</c>
          <c>100 milliseconds, 1 second, 10 seconds, 1 minute, 10 minutes</c>

          <c>Test Message</c>
          <c>10 milliseconds, 100 milliseconds, 1 second, 10 seconds, 1 minute</c>
        </texttable>
    </section>

    <section title="Packet Delay Measurement (DM) Profile">
      <t>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:</t>

        <texttable align="left" style="headers">
          <ttcol width="60%">Parameter</ttcol>
          <ttcol>Default Value</ttcol>

          <c>Query control code</c>
          <c>In-band response requested</c>

          <c>Querier Timestamp Format (QTF)</c>
          <c>Truncated IEEE 1588v2</c>

          <c>Responder Timestamp Format (RTF)</c>
          <c>Truncated IEEE 1588v2</c>

          <c>Responder's Preferred Timestamp Format (RPTF)</c>
          <c>Truncated IEEE 1588v2</c>
        </texttable>

       <t>This profile uses the MPLS Delay Measurement (DM) Channel Type
       in the Associated Channel Header (ACH).</t>

       <t>A simple implementation may assume that external configuration will
       ensure that both ends of the communication are using the default values
       for these parameters.  Implementations are, however, strongly advised
       to validate the values of these parameters in received messages so that
       configuration inconsistencies can be detected and reported.</t>

       <t>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.</t>
    </section>

    <section title="Security Considerations">
      <t>This document delineates a subset of the procedures specified in
      <xref target="I-D.ietf-mpls-loss-delay" />, and as such introduces
      no new security considerations in itself.  The security
      considerations discussed in <xref target="I-D.ietf-mpls-loss-delay"
      /> apply also to the profile presented in this document.  General
      considerations for MPLS-TP network security can be found in <xref
      target="I-D.ietf-mpls-tp-security-framework" />.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document introduces no new IANA considerations.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.5586'?>

      <?rfc include='reference.RFC.5860'?>

      <?rfc include='reference.I-D.ietf-mpls-loss-delay'?>

    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5921'?>

      <?rfc include='reference.RFC.5950'?>

      <?rfc include='reference.I-D.ietf-mpls-tp-security-framework'?>

    </references>
  </back>
</rfc>