One document matched: draft-ietf-pcn-psdm-encoding-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<rfc ipr="trust200902" docName="draft-ietf-pcn-psdm-encoding-02" category="historic">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- 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 -->
<!-- IETF process -->
<?rfc iprnotified="no" ?> <!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="yes" ?> <!-- 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="no" ?> <!-- 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 -->
<front>
<title abbrev="PCN packet specific dual marking">
PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)
</title>
<author initials="M." surname="Menth" fullname="Michael Menth">
<organization>University of Tuebingen</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>Sand 13</street>
<city> Tuebingen</city>
<code>D-72076</code>
<country>Germany</country>
</postal>
<phone>+49 07071 29 70505</phone>
<email>menth@informatik.uni-tuebingen.de</email>
<uri>http://www.kn.inf.uni-tuebingen.de</uri>
</address>
</author>
<author initials="J." surname="Babiarz" fullname="Jozef Babiarz">
<organization>3inova Networks Inc</organization>
<address>
<postal>
<street>CRC Innovation Centre</street>
<street>Bldg 94 Room 216D </street>
<street>3701 Carling Avenue</street>
<city> Ottawa</city>
<code>K2H 8S2</code>
<country>Canada</country>
</postal>
<phone>+1-613-298-0438</phone>
<email>j.babiarz@3inovanetworks.com</email>
</address>
</author>
<author initials="T." surname="Moncaster" fullname="Toby Moncaster">
<organization>University of Cambridge</organization>
<address>
<postal>
<street>Computer Laboratory</street>
<street>JJ Thomson Avenue</street>
<city>Cambridge</city>
<code>CB3 0FD</code>
<country>UK</country>
</postal>
<phone>+44 1223 763654</phone>
<email>toby@moncaster.com</email>
</address>
</author>
<author initials="B." surname="Briscoe" fullname="Bob 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.bobbriscoe.net</uri>
</address>
</author>
<date day="12" month="March" year="2012"></date>
<area>Transport</area>
<workgroup>Congestion and Pre Congestion</workgroup>
<keyword>Quality of Service</keyword>
<keyword>QoS</keyword>
<keyword>Congestion Control</keyword>
<keyword>Differentiated Services</keyword>
<keyword>Admission Control</keyword>
<keyword>Signalling</keyword>
<keyword>Protocol</keyword>
<keyword>Pre-emption</keyword>
<abstract>
<t>
Pre-congestion notification (PCN) is a link-specific and load-dependent
packet re-marking mechanism and provides in Differentiated Services networks
feedback to egress nodes about load conditions within the domain. It is used
to support admission control and flow termination decision in a simple way.
This document proposes how PCN marks can be encoded into the IP header for
packet-specific dual marking (PSDM). PSDM encoding provides three different
codepoints: not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark
not-ETM-packets to PM and threshold-marking may re-mark not-ThM-packets to PM.
</t>
</abstract>
<!-- ================================================================ -->
<note title="Status">
<t> Since its original publication, the baseline encoding (RFC5696) on which
this document depends has become obsolete. The PCN working GRoup has chosen
to publish this as a historical document to preserve the details of the encoding
and to allow it to be cited in other documents.
</t>
</note>
</front>
<!-- ================================================================ -->
<!-- ================================================================ -->
<middle>
<!-- ================================================================ -->
<section anchor="pcn_psdm_intro" title="Introduction">
<t>
The objective of Pre-Congestion Notification (PCN) <xref target="RFC5559"/> 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 (AC), to decide whether to admit or
block a new flow request, and (in abnormal circumstances) flow
termination (FT) 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 lower
reference rate <xref target="RFC5670"/>. These marks are monitored by the egress
nodes of the PCN domain.
</t>
<t>This document proposes how PCN marks can be encoded into the IP header
when packet-specific dual marking (PSDM) is used to re-mark packets <xref target="Menth09f"/>.
That means, both excess-traffic-marking and threshold-marking are activated on
the links within a PCN domain, but packets are subject to re-marking by only one
of them. The encoding of
unmarked PCN packets indicates whether they are subject to either
excess-traffic-marking (not-ETM) or threshold-marking (not-ThM) and
they may be re-marked to PCN-marked (PM).
</t>
<t>
PSDM encoding can be applied in networks implementing
<list style="symbols">
<t>only AC based on threshold-marking (reference rate = PCN-admissible-rate),</t>
<t>only FT based on excess-traffic-marking (reference rate = PCN-supportable-rate),</t>
<t>both AC and FT based on excess-traffic-marking (reference rate = PCN-admissible-rate)</t>
<t>Probe-based AC based on threshold-marking (reference rate = PCN-admissible-rate)
and FT based on excess-traffic-marking (reference rate = PCN-supportable-rate)<xref target="Menth09f"/>.</t>
</list>
</t>
<t>
The motivation for PSDM encoding is that probe packets are subject only to
threshold-marking and that data packets are subject only to
excess-traffic-marking. Nevertheless, routers should not need to differentiate explicitly
between probe and data packets since packets are a priori marked with an appropriate
codepoint (not-ETM, not-ThM) indicating the marking mechanism applying to them.
</t>
<t>
Following the publication of new rules relating to the tunnelling of ECN marks <xref target="RFC6040"/>, the PCN workign group decided to obsolete <xref target="RFC5696"/> in favour of the 3-in-1 encoding <xref target="I-D.ietf-pcn-3-in-1-encoding" />. A side-effect
of this decision was to make the PSDM encoding obsolete. However the PCN working group
feels it is useful to have a formal historical record of this encoding. This ensures
details of the encoding are not lost and also allows it to be cited in other documents.
</t>
<!-- ================================================================ -->
<section anchor="pcn_psdm_Reqs_notation" title="Requirements notation">
<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"></xref>.
</t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="pcn_psdm_terminology" title="Terminology">
<t> Most of the terminology used in this document is defined in
<xref target="RFC5559"/>. The following additional terms are defined
in this document:
<list style="symbols">
<t>PCN-capable flow - a flow subject to PCN-based admission control and/or flow termination </t>
<t>PCN-enabled DSCP - DSCP indicating within a PCN domain that packets possibly
belong to a PCN-capable flow </t>
<t>PCN-capable ECN codepoint (PCN codepoint) - DSCP set to a PCN-enabled DSCP
and ECN field set to a codepoint indicating that a packet belongs to a PCN-capable
flow (not-ThM, not-ETM, or PM, explained below) </t>
<t>PCN packet - a packet belonging to a PCN capable flow within a PCN domain, must
have a PCN-enabled DSCP and a PCN-capable ECN codepoint</t>
<t>not-PCN capable (not-PCN) - new ECN codepoint for packets of non-PCN-capable
flows when a PCN-enabled DSCP is set</t>
<t>not-excess-traffic-marked (not-ETM) - new ECN codepoint for unmarked PCN packets that
are subject to excess-traffic-marking</t>
<t>not-threshold-marked (not-ThM) - new ECN codepoint for unmarked PCN packets
that are subject to threshold-marking</t>
<t>PCN-marked (PM) - new ECN codepoint for re-marked PCN packets regardless whether they
were subject to excess-traffic-marking or threshold-marking.</t>
</list>
</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_psdm_PSDM-enc" title="Encoding for Packet-Specific Dual Marking">
<t>
In this section the encoding for packet-specific dual marking (PSDM) is presented
and the reasons for the proposed design are outlined.
</t>
<section anchor="pcn_psdm_proposal" title="Proposed Encoding and Expected Node Behavior">
<t>
The encoding reuses a PCN-enabled DSCP
to indicate packets of PCN-capable flows within a PCN domain.
</t>
<section anchor="pcn_psdm_codepoints" title="PCN Codepoints">
<t>The ECN field of packets with a PCN-enabled DSCP is interpreted within a
PCN domain as PCN codepoint while it is interpreted as ECN codepoint outside
PCN domains. Four new PCN codepoints are defined in
<xref target="pcn_psdm_Tab_encoding"/>. PSDM encoding
can be seen as an extension of baseline encoding <xref target="RFC5696"/>
<figure anchor='pcn_psdm_Tab_encoding' title="PSDM encoding.">
<artwork>
+--------+----------------------------------------------------+
| | 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 | not-ETM | not-ThM | PM |
+--------+--------------+-------------+-------------+---------+
</artwork>
</figure>
</t>
</section>
<section anchor="pcn_psdm_ingress" title="Codepoint Handling by PCN Ingress Nodes">
<t>
When packets belonging to PCN flows arrive at the ingress router of the PCN domain,
the ingress router first drops all CE-marked packets.
Then, it sets the DSCP of the remaining PCN packets to an
PCN-enabled DSCP and re-marks the ECN field of all PCN packets that
are subject to threshold-marking to not-ThM (e.g. probe packets),
and all PCN packets that are subject to excess-traffic-marking to not-ETM
(e.g. data packets). If packets with a PCN-enabled DSCP arrive that
belong to non-PCN flows,
the PCN ingress node re-marks their ECN field to not-PCN or re-marks their
DSCP to a different one while preserving the contents of the ECN field.
</t>
</section>
<section anchor="pcn_psdm_internal" title="Codepoint Handling by PCN Interfaces">
<t>
If the meter for excess-traffic-marking of a PCN node indicates that a PCN packet
should be re-marked, its ECN field is set to PCN-marked (PM) only if it was not-ETM before.
If the meter for threshold-marking of a PCN node indicates that a PCN
packet should be re-marked, its ECN field is set to PCN-marked (PM) only if it was
not-ThM before.
</t>
</section>
<section anchor="pcn_psdm_egress" title="Codepoint Handling by PCN Egress Nodes">
<t>
If the egress node of a PCN domain receives a PM-packet, it infers
somehow whether the packet was not-ETM or not-ThM by the PCN ingress node
to interpret the marking. This can be done as probe packets must be
distinguishable from PCN data packets anyway. The egress node resets the ECN
field of all packets with PCN-enabled DSCPs to not-ECT. This breaks the
ECN capability for all flows with PCN-enabled DSCPs, regardless whether
they are PCN-capable or not. Appropriate tunnelling across a PCN domain
can preserve the ECN marking of packets with PCN-enabled DSCPs and the
ECN-capability of their flows (see <xref target="pcn_psdm_ecn_handle"/>).
When the DSCPs in the headers of packets belonging to flows with PCN-enabled
DSCPs have been changed to another DSCP, the egress node should reverse that
change.
</t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="pcn_psdm_reasons" title="Reasons for the Proposed Encoding">
<section anchor="pcn_psdm_dscps" title="Scarcity of DSCPs">
<t>
DSCPs are a scarce resource in the IP header so that at most one should
be used for PCN encoding.
</t>
</section>
<section anchor="pcn_psdm_tunneling" title="Problems with Tunneling">
<t>
The encoding scheme must cope with tunnelling within PCN domains. However,
various tunnelling schemes limit the persistence of ECN marks in the top-most
IP header to a different degree. Two IP-in-IP tunnelling modes are defined in
<xref target="RFC3168"/> and a third one in <xref target="RFC4301"/>
for IP-in-IPsec tunnels.
</t>
<t>
The limited-functionality option in <xref target="RFC3168"/> requires
that the ECN codepoint in the outer header is set to not-ECT so that
ECN is disabled for all tunnel routers, i.e., they drop packets instead
of mark them in case of congestion. The tunnel egress just decapsulates
the packet and leaves the ECN codepoints of the inner packet header unchanged.
<list style="symbols">
<t>This mode protects the inner IP header from being PCN-marked upon decapsulation. It can be used to tunnel ECN marks across PCN domains such that PCN marking is applied to the outer header without affecting the inner header.</t>
<t>This mode is not useful to tunnel PCN traffic with PCN-enabled DSCP and PCN-capable PCN-codepoints within PCN domain because the ECN marking information from the outer ECN fields is lost upon decapsulation.</t>
</list>
</t>
<t>
The full-functionality option in <xref target="RFC3168"/> requires
that the ECN codepoint in the outer header is copied from the inner header
unless the inner header codepoint is CE. In this case, the outer header
codepoint is set to ECT(0). This choice has been made to disable the ECN
fields of the outer header as a covert channel. Upon decapsulation, the
ECN codepoint of the inner header remains unchanged unless the outer header
ECN codepoint is CE. In this case, the inner header codepoint is also set to
CE. This preserves outer header information if it is CE. However, the fact
that CE marks of the inner header are not visible in the outer header may be a
problem for excess-traffic-marking as it takes already marked traffic into account
and for some required packet drop policies.
</t>
<t>
Tunnelling with IPsec copies the inner header ECN field to the outer header
ECN field <xref target="RFC4301">RFC4301, Sect. 5.1.2.1</xref> upon encapsulation.
Upon decapsulation, CE-marks of the outer header are copied into the inner
header, the other marks are ignored. With this tunnelling mode, CE marks
of the inner header become visible to all meters, markers, and droppers
for tunnelled traffic. In addition, limited information from the outer
header is propagated into the inner header. Therefore, only IPsec tunnels
should be used inside PCN domains when ECN bits are reused for PCN encoding.
Another consequence is that CE is the only codepoint to which packets can
be re-marked along a tunnel within a PCN domain so that the changed
codepoint survives decapsulation.
</t>
</section>
<section anchor="pcn_psdm_ecn" title="Problems with the ECN Field">
<t>
The guidelines in <xref target="RFC4774"></xref> describe how the ECN bits
can be reused while being compatible with <xref target="RFC3168"></xref>.
A CE mark of a packet must never be changed to another ECN codepoint.
Furthermore, a not-ECT mark of a packet must never be changed to one
of the ECN-capable codepoints ECT(0), ECT(1), or CE. Care must be taken
that this rule is enforced when PCN packets leave the PCN domain. As a
consequence, all CE-marked PCN packets must be dropped before
entering a PCN domain and the ECN field of all PCN packets must
be reset to not-ECT when leaving a PCN domain.
</t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="pcn_psdm_ecn_handle" title="Handling of ECN Traffic">
<t>
ECN is intended to control elastic traffic as TCP reacts to ECN marks.
Inelastic real-time traffic is mostly not transmitted over TCP such that
this application of ECN is not appropriate. However, there have been
proposals made that would re-use the PCN signals for rate adaptation.
Therefore, two different options might be useful.
<list style="symbols">
<t>preserve ECN
marks from outside a PCN domain, i.e. CE-marked packets should not
be dropped. To handle this case, ECN packets should be tunnelled
through a PCN domain such that the ECN marking is hidden from the PCN
control and PCN marking is applied only to the outer header.
</t>
<t>add PCN markings to the ECN field if applications wish to receive
the PCN markings for whatever purpose. In that case IPsec tunnels should
be used for tunnelling. This, however, must be done only if end systems
are ECN capable and signal that they wish to receive this additional
PCN marking information. If this is useful, the required signalling
needs to be defined.
</t>
</list>
Both options are an independent of the way how PCN marks are encoded. Therefore, they are not in the scope of this document.
</t>
</section>
</section>
<!-- ================================================================ -->
<section title="IANA Considerations">
<t>This document makes no request to IANA.</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_psdm_security" title="Security Considerations">
<t>
{ToDo}
</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_psdm_Conclusions" title="Conclusions">
<t>This document describes an encoding scheme with the following benefits:
{ToDo}
</t>
</section>
<!-- ================================================================ -->
<!--<section anchor="pcn_psdm_Acknowledgements" title="Acknowledgements">
<t>This document builds extensively on work done in the PCN working group by
Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, and others.
</t>
</section>-->
<!-- ================================================================ -->
<section anchor="pcn_psdm_Comments_Solicited" title="Comments Solicited">
<t>Comments and questions are encouraged and very welcome. They can be
addressed to the IETF PCN 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.3168" ?>
<?rfc include="reference.RFC.4301" ?>
<?rfc include="reference.RFC.4774" ?>
<?rfc include="reference.RFC.5559" ?>
<?rfc include="reference.RFC.5670" ?>
<?rfc include="reference.RFC.5696" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6040" ?>
<?rfc include="reference.I-D.ietf-pcn-3-in-1-encoding" ?>
<reference anchor='Menth09f'>
<front>
<title>Pre-Congestion Notification Using Packet-Specific Dual Marking</title>
<author initials="M.M." surname="Menth" fullname="Michael Menth">
<organization>University of Wuerzburg</organization>
</author>
<author initials="J.B." surname="Babiarz" fullname="Jozef Babiarz">
<organization></organization>
</author>
<author initials="P.E." surname="Eardley" fullname="Philip Eardley">
<organization></organization>
</author>
<date month="June" year="2009"/>
</front>
<seriesInfo name="Proceedings of the" value="International Workshop on the Network of the Future (Future-Net), IEEE, Dresden, Germany"/>
</reference>
</references>
<!--
<section anchor="pcn_psdm_appendix" title="Additional Comments on ECN and Tunneling">
<t>
Encoding for packet-specific single marking (PSSN) destroys the end-to-end
capability of all ECN flows with PCN-enabled DSCPs, e.g. Voice-Admit. To cope
with this side effect, packets of ECN-enabled flows can be tunnelled through
PCN domains in plain IP-in-IP tunnels that do not modify the information of
the inner header upon decapsulation. If end systems wish that PCN markings
should be added to ECN markings, IPSec tunnels should be used for tunnelling.
This, however, must be done only if end systems are ECN capable and signal
that they wish to receive this additional PCN marking information. If this is
useful, the required signalling needs to be defined.
</t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:21:47 |