One document matched: draft-ietf-mpls-tp-loss-delay-profile-00.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-00"
     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="2010" />

    <area>Routing</area>

    <workgroup>MPLS</workgroup>

    <keyword>MPLS</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Procedures for the measurement of packet loss, delay, and throughput
      in MPLS networks are defined in RFC XXXX.  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.</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>[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>
    </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.frost-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.frost-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="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 inspection or negotiation of these
      parameters is not required:

         <list style="symbols">
           <t>The Query control code</t>
           <t>The byte/packet count (B) flag</t>
           <t>The extended data format (X) flag</t>
           <t>The Traffic-Class-specific (T) flag</t>
           <t>The Traffic Class (TC)</t>
           <t>The Origin Timestamp Format (OTF)</t>
         </list>
      </t>

      <t>The default values for these parameters are specified by this
      profile as follows:
         <list style="symbols">
           <t>Query control code: In-band response requested</t>
           <t>B flag: packet count</t>
           <t>X flag: 32-bit</t>
           <t>T flag: traffic-class-scoped</t>
           <t>OTF: IEEE 1588 version 1</t>
         </list>
       The TC field is set according to the class of traffic to be
       measured.</t>

       <t>This profile is restricted to direct-mode LM and therefore uses
       the MPLS Direct Packet Loss Measurement (DLM) Channel Type in the
       Associated Channel Header (ACH).</t>

       <t>A simple implementation may assume externally-determined
       configuration and need only support the functionality required by
       these defaults.</t>
    </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 inspection or negotiation of these
      parameters is not required:

         <list style="symbols">
           <t>The Query control code</t>
           <t>The Querier Timestamp Format (QTF) field</t>
           <t>The Responder Timestamp Format (RTF) field</t>
           <t>The Responder's Preferred Timestamp Format (RPTF) field</t>
           <t>The Traffic Class (TC)</t>
         </list>
      </t>

      <t>The default values for these parameters are specified by this
      profile as follows:
         <list style="symbols">
           <t>Query control code: In-band response requested</t>
           <t>QTF: IEEE 1588 version 1</t>
           <t>RTF: IEEE 1588 version 1</t>
           <t>RPTF: IEEE 1588 version 1</t>
           <t>T flag: traffic-class-scoped</t>
         </list>
       The TC field is set according to the class of traffic to be
       measured.</t>

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

       <t>A simple implementation may assume externally-determined
       configuration and need only support the functionality required by
       these defaults.</t>
    </section>

    <section title="Security Considerations">
      <t>This document delineates a subset of the procedures specified in
      <xref target="I-D.frost-mpls-loss-delay" />, and as such introduces
      no new security considerations in itself.  The security
      considerations discussed in <xref target="I-D.frost-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.frost-mpls-loss-delay'?>

    </references>

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

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