One document matched: draft-briscoe-pcn-3-in-1-encoding-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- Alterations to I-D/RFC boilerplate -->
<?rfc private="" ?>
<!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RFC -->
<?rfc topblock="yes" ?>
<!-- Default topblock="yes" put the famous header block on the first page -->
<?rfc footer="" ?>
<!-- Default footer="Expires <date>" override the center footer string -->
<?rfc header="" ?>
<!-- Default header="Internet-Draft" override the leftmost header string -->
<?rfc authorship="yes" ?>
<!-- Default authorship="yes" Render authors' addresses section -->
<?rfc rfcprocack="yes" ?>
<!-- Default rfcprocack="no" add a short sentence acknowledging xml2rfc -->
<?rfc strict="no" ?>
<!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="no" ?>
<!-- Default rfcedstyle="yes" attempt to closely follow finer details from the latest observable RFC-Editor style -->
<?rfc colonspace="no" ?>
<!-- Default colonspace="no" put two spaces instead of one after each colon (``:'') in txt or nroff files -->
<?rfc notedraftinprogress="yes" ?>
<!-- Default notedraftinprogress="yes" generates "(work in progress)", as appropriate -->
<?rfc refparent="References" ?>
<!-- Default refparent="References" title of the top-level section containing all references -->
<!-- IETF process -->
<?rfc iprnotified="no" ?>
<!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="no" ?>
<!-- Default toc="no" No Table of Contents -->
<?rfc tocappendix="yes" ?>
<!-- Default tocappendix="yes" control whether the word `Appendix' appears in the table-of-content -->
<?rfc tocdepth="3" ?>
<!-- Default tocdepth="3" if toc is "yes", then this determines the depth of the table-of-contents -->
<?rfc tocindent="yes" ?>
<!-- Default tocindent="yes" if toc is "yes", indent subsections in the table-of-contents -->
<?rfc tocnarrow="yes" ?>
<!-- Default tocnarrow="yes" affects horizontal spacing in the table-of-content -->
<?rfc tocompact="yes" ?>
<!-- Default tocompact="yes" if toc is "yes", then setting this to "no" will make it a little less compact -->
<!-- Cross referencing, footnotes, comments -->
<?rfc symrefs="yes" ?>
<!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes"?>
<!-- Default sortrefs="no" Don't sort references into order -->
<?rfc comments="yes" ?>
<!-- Default comments="no" Don't render comments -->
<?rfc inline="yes" ?>
<!-- Default inline="no" if comments is "yes", then render comments inline; otherwise render them in an `Editorial Comments' section -->
<?rfc editing="no" ?>
<!-- Default editing="no" Don't insert editing marks for ease of discussing draft versions -->
<!-- Pagination control -->
<?rfc compact="yes"?>
<!-- Default compact="no" Start sections on new pages -->
<?rfc subcompact="no"?>
<!-- Default subcompact="(as compact setting)" yes/no is not quite as compact as yes/yes -->
<?rfc autobreaks="yes" ?>
<!-- Default autobreaks="yes" avoid widows and orphans (not perfect) -->
<!-- HTML formatting control -->
<?rfc emoticonic="yes" ?>
<!-- Default emoticonic="no" Doesn't prettify HTML format -->
<?rfc background="" ?>
<!-- Default background="" when producing a html file, use this image -->
<?rfc useobject="no" ?>
<!-- Default useobject="no" use <object> not <src> when outputting HTML -->
<?rfc linkmailto="yes" ?>
<!-- Default linkmailto="yes" generate mailto: URL, as appropriate -->
<?rfc docmapping="no" ?>
<!-- Default docmapping="no" use hierarchical tags (e.g., <h1>, <h2>, etc.) for (sub)section titles -->
<?rfc slides="no" ?>
<!-- Default slides="no" when producing a html file, produce multiple files for a slide show -->
<rfc category="exp" docName="draft-briscoe-pcn-3-in-1-encoding-00"
     ipr="full3978">
  <front>
    <title abbrev="3-in-1 PCN Encoding">PCN 3-State Encoding Extension in a
    single DSCP</title>

    <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
      <organization>BT</organization>

      <address>
        <postal>
          <street>B54/77, Adastral Park</street>

          <street>Martlesham Heath</street>

          <city>Ipswich</city>

          <code>IP5 3RE</code>

          <country>UK</country>
        </postal>

        <phone>+44 1473 645196</phone>

        <email>bob.briscoe@bt.com</email>

        <uri>http://www.cs.ucl.ac.uk/staff/B.Briscoe/</uri>
      </address>
    </author>

    <date day="27" month="October" year="2008" />

    <area>Transport</area>

    <workgroup>Congestion and Pre-Congestion Notification</workgroup>

    <keyword>Quality of Service</keyword>

    <keyword>QoS</keyword>

    <keyword>Congestion Control</keyword>

    <keyword>Congestion Notification</keyword>

    <keyword>Tunnelling</keyword>

    <keyword>Encapsulation & Decapsulation</keyword>

    <keyword>Differentiated Services</keyword>

    <keyword>Integrated Services</keyword>

    <keyword>Signalling</keyword>

    <keyword>Protocol</keyword>

    <keyword>Flow Admission Control</keyword>

    <keyword>Flow Termination</keyword>

    <abstract>
      <t>Pre-congestion notification (PCN) is a mechanism designed to protect
      the quality of service of inelastic flows. It does this by marking
      packets when traffic load on a link is approaching or has exceeded a
      threshold below the physical link rate. This document specifies an
      extension to the two-state PCN baseline encoding that enables three
      encoding states to be carried in the IP header without using more than
      one Diffserv codepoint. It presupposes a standards action has removed
      the limit of two encoding states in current tunnelling mechanisms.</t>
    </abstract>
  </front>

  <middle>
    <!-- ================================================================ -->

    <section anchor="pcn3in1_Introduction" title="Introduction">
      <t>Pre-congestion notification provides information to support admission
      control and flow termination at the boundary nodes of a Diffserv region
      in order to protect the quality of service (QoS) of inelastic flows
      <xref target="I-D.ietf-pcn-architecture"></xref>. This is achieved by
      marking packets on interior nodes according to some metering function
      implemented at each node. Excess traffic marking marks PCN packets that
      exceed a certain reference rate on a link while threshold marking marks
      all PCN packets on a link when the PCN traffic rate exceeds a higher
      reference rate <xref target="I-D.ietf-pcn-marking-behaviour"></xref>.
      These marks are monitored by the egress nodes of the PCN domain.</t>

      <t>To fully support these two types of marking, three encoding states
      are needed: one encoding for packets that are not marked plus two
      encodings for the two types of marking. The baseline encoding described
      in <xref target="I-D.ietf-pcn-baseline-encoding"></xref> provides for
      deployment scenarios that only require two PCN encoding states using a
      single Diffserv codepoint. This document describes an experimental
      extension to the baseline-encoding that adds a third PCN encoding state
      in the IP header, still using a single Diffserv codepoint. For brevity
      it will be called the 3-in-1 PCN Encoding.</t>

      <t>If more than three states are required, e.g. to support end-to-end
      ECN as well as edge-to-edge PCN <xref
      target="I-D.sarker-pcn-ecn-pcn-usecases"></xref>, end-to-end ECN would
      have to be encapsulated in the inner header of a tunnel through the PCN
      region, as outlined in <xref
      target="I-D.ietf-pcn-architecture"></xref>.</t>

      <t>General PCN-related terminology is defined in the PCN architecture
      <xref target="I-D.ietf-pcn-architecture"></xref>, and terminology
      specific to packet encoding is defined in the PCN baseline encoding
      <xref target="I-D.ietf-pcn-baseline-encoding"></xref>.</t>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_Reqs_Lang" 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>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_Requirement"
             title="The Requirement for Three PCN Encoding States">
      <t>The PCN architecture <xref target="I-D.ietf-pcn-architecture"></xref>
      describes proposed PCN schemes that expect traffic to be metered and
      marked using both Threshold and Excess Traffic schemes. In order to
      achieve this it is necessary to allow for three PCN encoding states: one
      as a Not Marked (NM) state and the other two to distinguish these two
      levels of marking severity. The way tunnels process the ECN field
      severely limits how to encode these states.</t>

      <t>The two bit ECN field seems to offer four possible encoding states,
      but one (00) is set aside for traffic controlled by transports that do
      not understand PCN marking, so it would be irregular to use it as a PCN
      encoding state. Of the three remaining ECN codepoints, only one (11) can
      be introduced by a congested node within a tunnel and still survive the
      decapsulation behaviour of a tunnel egress as currently standardised.
      The two remaining codepoints are (10) and (01). But if a node within the
      tunnel used either of these two remaining codepoints to try to mark
      packets with a second severity level, this marking would be removed on
      decapsulation. The ECN field is constrained to two marking states in
      this way irrespective of whether regular IP in IP tunnelling <xref
      target="RFC3168"></xref> or IPsec tunnelling <xref
      target="RFC4301"></xref> is used.</t>

      <t>One way to provide another encoding state that survives tunnelling is
      to use a second Diffserv codepoint <xref
      target="I-D.moncaster-pcn-3-state-encoding"></xref>. Instead, to avoid
      wasting scarce Diffserv codepoints, we could modify standard tunnels in
      the PCN region to remove the constraints imposed by standard
      tunnelling.</t>

      <t>Therefore this document presupposes tunnels in the PCN region comply
      with the newly proposed Comprehensive Decapsulation Rules defined in
      Appendix C of <xref target="I-D.ietf-tsvwg-ecn-tunnel"></xref>. Then the
      constraints of standard tunnels no longer apply so this document can
      define a 3-state encoding for PCN within one Diffserv codepoint.</t>

      <t>Note that <xref target="I-D.ietf-tsvwg-ecn-tunnel"></xref> only
      records the Comprehensive Decapsulation Rules in an appendix, solely to
      allow us to discuss whether they should be brought on to the standards
      track. So, if they are not, the offending tunnelling constraints might
      not be removed. However, <xref
      target="I-D.ietf-tsvwg-ecn-tunnel"></xref> carefully establishes that
      the constraints imposed by standard tunnelling are actually unnecessary;
      they are merely the result of an unfortunate sequence of historical
      events. Then the analysis in Appendix C of <xref
      target="I-D.ietf-tsvwg-ecn-tunnel"></xref> shows that the proposed new
      rules would not introduce any compatibility issues; they only affect one
      combination of inner and outer header which has never occured under any
      legal transitions of any IETF tunnelling schemes. Therefore it is a
      reasonable working assumption for the purposes of this document that
      tunnelling constraints will one day be removed.</t>
    </section>

    <section anchor="pcn3in1_Encoding" title="The 3-in-1 PCN Encoding">
      <t>The 3-in-1 PCN Encoding scheme is based closely on that defined in
      <xref target="I-D.ietf-pcn-baseline-encoding"></xref> so that there will
      be no compatibility issues if a PCN-domain evolves from using the
      baseline encoding scheme to the experimental scheme described here. The
      exact manner in which the PCN encoding states are carried in the IP
      header is shown in <xref target="pcn3in1_Tab_Encoding"></xref>.</t>

      <texttable anchor="pcn3in1_Tab_Encoding" title="3-in-1 PCN Encoding">
        <preamble>Codepoint in ECN field of IP header<vspace
        blankLines="0" /><RFC3168 codepoint name></preamble>

        <ttcol align="center">DSCP</ttcol>

        <ttcol align="center">00 <Not-ECT></ttcol>

        <ttcol align="center">10 <ECT(0)></ttcol>

        <ttcol align="center">01 <ECT(1)></ttcol>

        <ttcol align="center">11 <CE></ttcol>

        <c>DSCP n</c>

        <c>Not-PCN</c>

        <c>NM</c>

        <c>ThM</c>

        <c>ETM</c>

        <postamble></postamble>
      </texttable>

      <t>In <xref target="pcn3in1_Tab_Encoding"></xref> the 3 PCN states are
      encoded in the ECN field (<xref target="RFC3168"></xref>) of an IP
      packet with its Diffserv field (<xref target="RFC2474"></xref>) set to
      DSCP n, which is any PCN-Compatible DiffServ codepoint as defined in
      Section 4.2 of the PCN baseline encoding <xref
      target="I-D.ietf-pcn-baseline-encoding"></xref>). The PCN codepoint of a
      packet defines its marking state as follows:<list style="hanging">
          <t hangText="Not-PCN:">The packet is controlled by a transport that
          does not understand PCN marking, therefore the only valid action to
          notify congestion is to drop the packet;</t>

          <t hangText="NM:">Not marked. A packet in the NM state has not (yet)
          had its marking state changed to the ThM or ETM states, but it may
          be changed to one of these states by a node experiencing congestion
          or pre-congestion;</t>

          <t hangText="ThM:">Threshold marked. Such a packet has had its
          marking state changed by the threshold marking algorithm <xref
          target="I-D.ietf-pcn-marking-behaviour"></xref>;</t>

          <t hangText="ETM:">Excess traffic marking. Such a packet has had its
          marking state changed by the excess rate marking algorithm <xref
          target="I-D.ietf-pcn-marking-behaviour"></xref>.</t>
        </list></t>

      <t>Packets marked NM, ThM or ETM are termed PCN-Enabled packets because
      they are controlled by edge nodes that understand how to process PCN
      markings.</t>
    </section>

    <section anchor="pcn3in1_Compliant_Node_Behaviour"
             title="Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding">
      <t>To be compliant with the 3-in-1 PCN Encoding, an PCN interior node
      behaves as follows:<list style="symbols">
          <t>It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST
          NOT change a PCN-Enabled codepoint to Not-PCN;</t>

          <t>It MUST NOT change ThM to NM;</t>

          <t>It MUST NOT change ETM to ThM or to NM;</t>
        </list>In other words, a PCN interior node may increase the severity
      of packet marking but it MUST NOT decrease it, where the order of
      severity increases from NM through ThM to ETM.</t>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_Sec_Consider" title="Security Considerations">
      <t>The security concerns relating to this extended PCN encoding are
      essentially the same as those in <xref
      target="I-D.ietf-pcn-baseline-encoding"></xref>.</t>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_Conclusions" title="Conclusions">
      <t>The 3-in-1 PCN Encoding provides three states to encode PCN markings
      in the ECN field of an IP packet using just one Diffserv codepoint. One
      state is for not marked packets while the two others are for PCN nodes
      to mark packets with increasing levels of severity. Use of the encoding
      presupposes that any tunnels in the PCN region have been updated to use
      proposed Comprehensive Decapsulation Rules because standard tunnel
      decapsulation rules unnecessarily constrain PCN marking.</t>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_Acknowledgements" title="Acknowledgements">
      <t>Thanks to Phil Eardley for reviewing this.</t>
    </section>

    <!-- ================================================================ -->

    <section anchor="pcn3in1_Comments_Solicited" title="Comments Solicited">
      <t>Comments and questions are encouraged and very welcome. They can be
      addressed to the IETF Congestion and Pre-Congestion working group
      mailing list <pcn@ietf.org>, and/or to the authors.</t>
    </section>
  </middle>

  <back>
    <!-- ================================================================ -->

    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>

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

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

      <?rfc include='localref.I-D.ietf-tsvwg-ecn-tunnel'?>

      <?rfc include='reference.I-D.ietf-pcn-marking-behaviour'?>
    </references>

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

      <?rfc include='reference.I-D.ietf-pcn-architecture'?>

      <?rfc include='reference.I-D.ietf-pcn-baseline-encoding'?>

      <?rfc include='reference.I-D.moncaster-pcn-3-state-encoding'?>

      <?rfc include='reference.I-D.sarker-pcn-ecn-pcn-usecases'?>
    </references>
  </back>
</rfc>