One document matched: draft-ietf-pcn-3-in-1-encoding-01.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-ietf-pcn-3-in-1-encoding-01"
ipr="trust200902">
<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>
<author fullname="Toby Moncaster" initials="T." surname="Moncaster">
<organization>BT</organization>
<address>
<postal>
<street>c/o B54/70, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1206 332805</phone>
<email>toby.moncaster@bt.com</email>
</address>
</author>
<date day="10" month="February" year="2010" />
<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>The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
The overall rate of the PCN-traffic is metered on every link in the
PCN-domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. The level of marking allows the boundary
nodes to make decisions about whether to admit or block a new flow
request, and (in abnormal circumstances) whether to terminate some of
the existing flows, thereby protecting the QoS of previously admitted
flows. This document specifies how such marks are to be encoded into the
IP header by re-using the Explicit Congestion Notification (ECN)
codepoints within this controlled domain. This encoding builds on the
baseline encoding and provides for three PCN encoding states:
Not-marked, Threshold-marked and Excess-traffic-marked.</t>
</abstract>
</front>
<middle>
<!-- ================================================================ -->
<section anchor="pcn3in1_Introduction" title="Introduction">
<t>The objective of Pre-Congestion Notification (PCN) <xref
target="RFC5559"></xref> is to protect the quality of service (QoS) of
inelastic flows within a Diffserv domain, in a simple, scalable, and
robust fashion. Two mechanisms are used: admission control, to decide
whether to admit or block a new flow request, and (in abnormal
circumstances) flow termination to decide whether to terminate some of
the existing flows. To achieve this, the overall rate of PCN-traffic is
metered on every link in the domain, and PCN-packets are appropriately
marked when certain configured rates are exceeded. These configured
rates are below the rate of the link thus providing notification to
boundary nodes about overloads before any congestion occurs (hence
"pre-congestion notification").</t>
<t>The level of marking allows boundary nodes to make decisions about
whether to admit or terminate. 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="RFC5670"></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. The baseline encoding described in <xref
target="RFC5696"></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>General PCN-related terminology is defined in the PCN architecture
<xref target="RFC5559"></xref>, and terminology specific to packet
encoding is defined in the PCN baseline encoding <xref
target="RFC5696"></xref>. Note that <xref target="RFC5696"></xref>
requires the PCN Working Group to maintain a list of all DSCPs used for
PCN experiments.</t>
<section anchor="pcn3in1_Changes"
title="Changes in This Version (to be removed by RFC Editor)">
<t><list style="hanging">
<t hangText="From draft-ietf-pcn-3-in-1-encoding-00 to -01:"><list
style="symbols">
<t>Altered the wording to make sense if <xref
target="I-D.ietf-tsvwg-ecn-tunnel"></xref> moves to proposed
standard.</t>
<t>References updated</t>
</list></t>
<t
hangText="From draft-briscoe-pcn-3-in-1-encoding-00 to draft-ietf-pcn-3-in-1-encoding-00:"><list
style="symbols">
<t>Filename changed to draft-ietf-pcn-3-in-1-encoding.</t>
<t>Introduction altered to include new template description of
PCN.</t>
<t>References updated.</t>
<t>Terminology brought into line with <xref
target="RFC5670"></xref>.</t>
<t>Minor corrections.</t>
</list></t>
</list></t>
</section>
</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="RFC5559"></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 <xref target="RFC5670"></xref>. The way tunnels processed the
ECN field before <xref target="I-D.ietf-tsvwg-ecn-tunnel"></xref>
severely limited 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 <xref target="RFC5696"></xref>, so it would
be irregular and risky 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 not updated to comply with <xref
target="I-D.ietf-tsvwg-ecn-tunnel"></xref>. 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, a tunnel not updated to comply with <xref
target="I-D.ietf-tsvwg-ecn-tunnel"></xref> would remove this marking on
decapsulation. The ECN field was constrained to two marking states in
this way irrespective of which earlier ECN tunnelling specification the
tunnel complied with, whether regular IP in IP tunnelling <xref
target="RFC3168"></xref> or IPsec tunnelling <xref
target="RFC4301"></xref>.</t>
<t>One way to provide another encoding state that survives tunnelling is
to use a second Diffserv codepoint <xref
target="I-D.ietf-pcn-3-state-encoding"></xref>. Instead, to avoid
wasting scarce Diffserv codepoints, a network operator can require
tunnels in a PCN region to comply with <xref
target="I-D.ietf-tsvwg-ecn-tunnel"></xref>, thus removing the
constraints imposed by earlier tunnelling specifications.</t>
<t>Therefore this document presupposes tunnels in the PCN region comply
with the newly proposed decapsulation rules defined in <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>
</section>
<section anchor="pcn3in1_Encoding" title="The 3-in-1 PCN Encoding">
<t>The 3-in-1 PCN Encoding scheme is based closely on the baseline
encoding defined in <xref target="RFC5696"></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_Fig_Encoding"></xref>.</t>
<figure anchor="pcn3in1_Fig_Encoding" title="3-in-1 PCN Encoding">
<artwork><![CDATA[ +--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
]]></artwork>
</figure>
<t>In <xref target="pcn3in1_Fig_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="RFC5696"></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-meter function <xref
target="RFC5670"></xref>;</t>
<t hangText="ETM:">Excess-traffic-marked. Such a packet has had its
marking state changed by the excess-traffic-meter function <xref
target="RFC5670"></xref>.</t>
</list></t>
<t>Packets marked NM, ThM or ETM are termed PCN-packets. Their entry
into the pcn-domain is controlled by edge nodes that understand how to
process PCN markings <xref target="RFC5559"></xref>.</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>Except where explicitly stated otherwise, it MUST comply with the
basealine encoding specified in <xref target="RFC5696"></xref></t>
<t>It MUST change NM TO ThM if the threshold-meter function
indicates to mark the packet.</t>
<t>It MUST change NM or ThM TO ETM if the excess-traffic-meter
function indicates to mark the packet.</t>
<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 the
same as those in <xref target="RFC5696"></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 this encoding
presupposes that any tunnels in the PCN region have been updated to
comply with <xref target="I-D.ietf-tsvwg-ecn-tunnel"></xref>.</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>To be removed by RFC Editor: 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='reference.RFC.5559'?>
<?rfc include='reference.RFC.5670'?>
<?rfc include='reference.RFC.5696'?>
<?rfc include='reference.I-D.ietf-tsvwg-ecn-tunnel'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.I-D.ietf-pcn-3-state-encoding'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:40 |