<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-geib-baseline-encoding-3state-00" ipr="full3978">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="3state signaling with baseline encoding">Signaling 3 PCN states with baseline encoding</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Ruediger Geib" initials="R." 
            surname="Geib">
      <organization>Deutsche Telekom</organization>

      <address>
        <postal>
          <street>Heinrich Hertz Str. 3-7</street>

          <!-- Reorder these if your country does things differently -->

          <code>64295</code>
          
          <city>Darmstadt</city>

          <region></region>

          <country>Germany</country>
        </postal>

        <phone>+49 6151 628 2747</phone>

        <email>Ruediger.Geib@telekom.de</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="September" year="2008" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Transport</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>PCN, experimental, coding, marking</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>Layer 2 transport services like MPLS offer only 2 states to encode 
      ECN state, if DiffServ based Class of Service is operated. Still, 
      a mechanism by which PCN egress nodes can differentiate between the normal 
      behaviour state, admission stop state control state and flow termination 
      state, by using PCN marking of packets is desirable. 
      This document describes how threshold and excess marking 
      can be combined with PCN baseline encoding. A minimalistic approach like 
      the one described in the following has some obvious shortcomings. 
      These shortcomings are also presented and discussed. Currently, the aim 
      of this document is to trigger experimentation feasability studies. 
      Standardisation will be pursued in the future based on the results of 
      the studies. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>DiffServ and MPLS are state of the art technologies operated in many carrier backbones. 
      Following  <xref target="RFC5129">RFC 5129</xref>, only PCN 
      <xref target="pcn-baseline-encoding">baseline encoding</xref> is applicable within MPLS 
      networks. Still, it may be desirable to differentiate operation of a pre congested PCN 
      domain interface in the admission stop state from operation in the termination state at 
      the egress and do so without any extra signaling but "M/CE" marked PCN packets.</t>
       
      <t>This draft proposes a method to combine threshold and excess marking with PCN baseline 
      encoding. As the PCN egress node must infer the operational state of a domain's 
      pre-congested PCN interface(s) by marking patterns, shortcomings of the proposed 
      method are obvious. They will be discussed briefly in this document. The intent of this
      draft is to start experimentation rather than standardisation. Any form of 
      standardisation will only be started, if experiments show, that the known drawbacks 
      of the proposed two state marking with PCN baseline encoding can be overcome without 
      introducing complex solutions.
      </t>

      <section 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>
    
    <section title="Terminology">
      <t> This draft does not introduce any new functionalities. The 
      terminology in this document follows the one used by the PCN WG 
      at the time of writing,  in detail:</t>
     <t><list style="symbols">
       <t><xref target="pcn-architecture">draft-ietf-pcn-architecture-06</xref>,</t>
       <t><xref target="pcn-baseline-encoding">draft-moncaster-pcn-baseline-encoding-02</xref>,</t>
       <t><xref target="pcn-marking-behaviour">draft-eardley-pcn-marking-behaviour-01</xref>, and</t>
       <t><xref target="pcn-psdm-encoding">draft-menth-pcn-psdm-encoding-00</xref>.</t>
     </list></t>
    </section>

    <section title="Signaling 3 PCN states with baseline encoding">
      <t> PCN based admission control functions best with threshold marking. This 
      means, that once PCN traffic is above a links PCN-threshold-rate, all PCN packets 
      passing this link are marked. With baseline encoding, only two codepoints are
      available to signal a links pre-congestion state. As all PCN traffic is marked
      with the single available codepoint to indicate any (pre) congestion state, there's little 
      solution space to further differentiate crossing of the PCN-excess-rate by a codepoint
      or by excess marking (the latter being the more suitable marking behaviour to indicate that a 
      links PCN load reached termination state).       
      </t>

     <section title="Three state signaling with PCN baseline encoding">
      <t>Admission control is realised by threshold marking of PCN traffic, once the PCN 
      traffic is above a links PCN-treshold-rate. If <xref target="pcn-psdm-encoding">PSDM</xref> 
      is applied, no PCN egress measurement functionalities need to be supported to 
      operate admission control. Admission control is thus operated as suggested by combining 
      mechanisms already proposed for standardisation.</t> 
      
      <t>Assuming that the PCN rate is strictly limited above the PCN-excess-rate 
      by the links physical bandwidth or by a policer and further assuming this PCN rate 
      limit to be, say, no more than 10% above the PCN-excess-rate, then excess marking 
      would result in no more than 10% of the packets above PCN-excess-rate to 
      be marked. If admission control is applied to path coupled signaling packets 
      with a piggybacked probing functionality between PCN boundary nodes (which 
      consists of setting the ECN field of that signaling packet), starting to mark 
      only packets above the PCN-excess-rate as "M/CE" once the latter is passed 
      doesn't result in desirable operational conditions. As only a small percentage
      of traffic is marked, most PSDM coded admission requests have a good 
      chance to pass the pre-congested link without being marked and lead to 
      admission of new PCN traffic. If however the operational regime of the 
      excess rate marker is "inverted", and the percentage of traffic excessing the 
      PCN-excess-rate is left unmarked (i.e. "NM" coded), then PSDM admission 
      control will prevent admission of 90% or more of the user sessions requesting 
      admission. Please note, that the threshold marker still continues to mark all 
      packets crossing the link and so the excess marker would indeed have to unmark
      packets again (if marking is realised eg. by sequential single rate token 
      buckets).</t> 
      
      <t>The marking behaviour as described in <xref target="pcn-marking-behaviour">pcn-marking-behaviour</xref>
      has to further be changed in the following way to support the functionalities 
      specified by this document.</t>
      
      <t>Two encoding states are available:</t>
      <t><list style="symbols">
          <t>one for "PCN-marked"</t>

          <t>one for "not PCN-marked".</t></list></t>
      
      <t>The metering and marking function MUST be implemented to support the 
      following threshold and excess-traffic marking functions:</t>
      
      <t>All PCN packets MUST be counted by the PCN meter.</t>
      
      <t>Threshold marking MUST be executed prior to (or simultaneously with) excess 
      traffic marking.</t> 
      
      <t>To threshold mark a packet, its PCN mark is set to "PCN-marked" (M/CE following
      <xref target="pcn-baseline-encoding">pcn-baseline-encoding</xref>).</t>
      
      <t>To excess-traffic mark a packet, its PCN mark is set to "not PCN-marked" 
      (NM/ECT0 following <xref target="pcn-baseline-encoding">pcn-baseline-encoding</xref>).</t>

      <t>Additionally, this document has outlined already, that two marking behaviours 
      are combined with PCN baseline encoding and this so far isn't part of 
      <xref target="pcn-marking-behaviour">pcn-marking-behaviour</xref>.</t>
      
      <t>The concept is illustrated by <xref target="Figure 1"> </xref>.</t>
      
            <figure align="center" anchor="Figure 1">
        <preamble> </preamble>

        <artwork align="left"><![CDATA[
         Rate of    ^
    PCN-traffic on  |
   bottleneck link  |                             (as below and also)
                    |     (as below)              Drop some PCN-pkts
                    |
    scheduler rate -| -----------------------------------------------
   (for PCN-traffic)|
                    |    Some pkts                Terminate some
                    |  "not PCN-marked"           admitted flows
                    |         &                        &
                    |     Rest of pkts         Block most new flows
                    |    "PCN-marked"
                    |
   PCN-excess-rate -|------------------------------------------------
                    |
                    |      All pkts               Block new flows
                    |    "PCN-marked"
                    |
PCN-threshold-rate -|------------------------------------------------
                    |
                    |      All pkts               Admit new flows
                    |   "not PCN-marked"                   
        ]]></artwork>

        <postamble>Schematic of how PCN's baseline encoding-3state 
        admission control and flow termination mechanisms kick in as the 
        rate of PCN-traffic increases, for a PCN-domain with three encoding 
        states (modified from [architecture]). <xref 
        target="pcn-architecture">pcn-architecture</xref>.</postamble>
      </figure>
      
      <t>A way to further increase the probability of blocking new flows 
      requesting admission, while a PCN interface reached termination state is 
      to generally "unmark" only a known share of the excess traffic (say 50% 
      or 10% of the packets to be unmarked at the excess rate instead of all 
      of them). This however may make it more difficult for an egress node 
      to correctly determine the termination rate of a small PCN aggregate 
      that has passed a link in termination state.</t> 
     </section>
      
    <section title="Benefits of three state signaling with PCN baseline encoding">      
      <t>If the behaviour exposed in the case of termination marking allows an egress 
      node to non ambiguously identify termination state for an aggregate, then it 
      can request the sources to terminate (or reduce) their traffic. </t>
      
      <t>As only a single code point is used to signal pre congestion states and two 
      different marking behaviours indicate the pre-congestion status, this 
      solution may be deployed within MPLS networks, where only 8 Codepoints are 
      available to support DiffServ and ECN.</t>
      
      <t>Finally, it should be noted that by support of PSDM no rate measurements are 
      required for admission control and that for termination, the egress node is 
      able to measure traffic rates and take decisions on termination without 
      having to provide feedback to another PCN node within its PCN domain.</t>
     </section>
     
     <section title="Simple experimental deployment">
      <t> Experimental simulation may not require the development of new code for 
      policers if egress and ingress policers can be simulated on both ends of a PCN 
      link. The egress policer of the PCN egress interface operates the threshold 
      policer at the PCN-threshold-rate. The ingress policer of the ingress interface 
      of the PCN node connected by the link is set to meter packets marked as 
      "PCN/CE". Operated in "excess mode", it starts to mark packets as "PCN/NM",
      once the rate of PCN/CE marked packets crosses the "PCN-excess-rate" 
      which it is configured for. Obviously, the termination threshold MUST be 
      bigger or equal to the admissible rate configured at the other end of the
      link.</t>
      
      <t>Routers supporting ingress and egress policing could also be used, which 
      would allow experiments with real equipment, if desired.
      </t>
     </section>

     <section title="Known issues of three state signalling with PCN baseline encoding">
      <t>The question, whether it is at all possible to infer the current 
      operational state of one or more pre-congested interface(s) of a 
      PCN domain by interpretation of the marking behaviour observed by the
      PCN egress nodes can't be answered yet. This section lists a few 
      operational conditions under which the proposed two state marking 
      three state signaling method must work reliably or reasonably 
      stable, respectively.
      </t>
 
      <t><list style="symbols">
          <t>Differing oscillating "admission"/"admission stop" state from 
          termination state. This operational condition is likely to be 
          present and the egress node MUST be able to reliably differ 
          admission stop state from termination, if such oscillating 
          "admission"/"admission stop" state is occurring.</t>

          <t>Admission of sessions during termination state. As a 
          certain percentage of packets will pass the pre congested 
          interface unmarked during termination state, a number of new 
          sessions will be admitted while others are terminated. The 
          egress nodes MUST be able to terminate more traffic swiftly 
          to push the PCN traffic rate below the PCN-excess-rate despite 
          admission of new sessions while this link is in termination state.</t>
          
          <t>If traffic that has passed a PCN interface in termination 
          state later on passes a PCN interface in admission stop state, 
          an end node will no longer be able to recognise the termination
          state of the prior PCN node, as all packets passing the 
          interface in admission stop state will be "PCN-marked".</t>
          
          <t>If traffic that has passed a PCN interface in termination 
          state later on passes another PCN interface in termination state, 
          an end node will only recognise the termination state of the 
          last PCN node by the relation of "not PCN-marked" to 
          "PCN-marked" packets as created by the last interface in 
          termination mode.
          </t>
      </list></t>
   
     </section>

     
    </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Ana Charney, Bob Briscoe and Joe Babiarz for brief 
      discussions on the idea and thanks to Steven Blake for the 
      opportunity to present 3 slides on the idea. Thanks also to 
      Mayutan Arumaithurai of University of Göttingen for a 
      review of this draft.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

      </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security section of <xref 
        target="pcn-architecture">pcn-architecture</xref>
        applies also to this draft. It does not introduce additional 
        security issues.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
    <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
     <!-- <reference anchor="RFC2119"> -->
    
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5129.xml"?>
      <!-- <reference anchor="RFC5129"> -->
     
    <reference anchor="pcn-architecture">
        <front>
            <title>Pre-Congestion Notification Architecture</title>
            <author initials="P." surname="Eardley"
                    fullname="Philip Eardley">
                <organization abbrev="BT">
                BT
                </organization>
            </author>

            <date day="7" month="August" year="2008" />
        </front>
        <seriesInfo name="draft" value="-ietf-pcn-architecture-05, (work in progress)" />
       </reference>
       
      <reference anchor="pcn-baseline-encoding">
        <front>
            <title>Baseline Encoding and Transport of Pre-Congestion Information</title>
            <author initials="T." surname="Moncaster"
                    fullname="Toby Moncaster">
                <organization abbrev="BT">
                BT
                </organization>
            </author>
            <author initials="B." surname="Briscoe"
                    fullname="Bob Briscoe">
                <organization abbrev="BT & UCL">
                BT & University College London
                </organization>
            </author>
            <author initials="M." surname="Menth"
                    fullname="Michael Menth">
                <organization abbrev="University of Wuerzburg">
                University of Wuerzburg
                </organization>
            </author>

            <date day="11" month="July" year="2008" />
        </front>
        <seriesInfo name="draft" value="-moncaster-pcn-baseline-encoding-02, (work in progress)" />
       </reference>
       
     <reference anchor="pcn-marking-behaviour">
        <front>
            <title>Marking behaviour of PCN-nodes</title>
            <author initials="P." surname="Eardley"
                    fullname="Philip Eardley">
                <organization abbrev="BT">
                BT
                </organization>
            </author>

            <date day="25" month="June" year="2008" />
        </front>
        <seriesInfo name="draft" value="-eardley-pcn-marking-behaviour-01 (work in progress)" />
       </reference>
       
     <reference anchor="pcn-psdm-encoding">
        <front>
            <title>PCN Encoding for Packet-Specific Dual Marking (PSDM)</title>
            <author initials="M." surname="Menth"
                    fullname="Michael Menth">
                <organization abbrev="University of Wuerzburg">
                University of Wuerzburg
                </organization>
            </author>
            <author initials="J." surname="Babiarz"
                    fullname="Joe Babiarz">
                <organization abbrev="Nortel">
                Nortel
                </organization>
            </author>

            <author initials="T." surname="Moncaster"
                    fullname="Toby Moncaster">
                <organization abbrev="BT">
                BT
                </organization>
            </author>
            <author initials="B." surname="Briscoe"
                    fullname="Bob Briscoe">
                <organization abbrev="BT & UCL">
                BT & University College London
                </organization>
            </author>
            <date day="7" month="July" year="2008" />
        </front>
        <seriesInfo name="draft" value="-menth-pcn-psdm-encoding-00 (work in progress)" />
       </reference> 
      </references>
 
  
    <!-- Change Log

v00 2008-09-16  RG   Initial version -->

  </back>
</rfc>
