One document matched: draft-geib-baseline-encoding-3state-00.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:33:57 |