One document matched: draft-ietf-mpls-tp-loss-delay-profile-03.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-03"
     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 the 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.</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>Several of the considerations discussed in <xref
      target="I-D.ietf-mpls-loss-delay" /> can be disregarded in the more
      restrictive context of MPLS-TP:

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

          <t>Considerations for direct LM in the presence of Label Switched
          Paths constructed via the Label Distribution Protocol (LDP) or
          utilizing Penultimate Hop Popping (Section 2.7.6 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>IEEE 1588 version 1</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>IEEE 1588 version 1</c>

          <c>Responder Timestamp Format (RTF)</c>
          <c>IEEE 1588 version 1</c>

          <c>Responder's Preferred Timestamp Format (RPTF)</c>
          <c>IEEE 1588 version 1</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.</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'?>

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