One document matched: draft-ietf-pcn-3-state-encoding-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="historic" docName="draft-ietf-pcn-3-state-encoding-02"
ipr="pre5378Trust200902">
<?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="3 State PCN Encoding">A PCN encoding using 2 DSCPs to
provide 3 or more states</title>
<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 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.bobbriscoe.net</uri>
</address>
</author>
<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>
<date day="12" month="March" year="2012" />
<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 mechanism designed to protect
the Quality of Service of inelastic flows within a controlled domain. 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
experimental encoding scheme specifies how three encoding states can be
carried in the IP header using a combination of two DSCPs and the ECN
bits. The Basic scheme only allows for three encoding states. The Full
scheme provides 6 states, enough for limited end-to-end support for ECN
as well.</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_3_enc_intro" 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. 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. These configured rates are below
the rate of the link thus providing notification before any congestion
occurs (hence "pre-congestion notification"). 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.</t>
<t>The baseline encoding described in <xref target="RFC5696"></xref>
provides for deployment scenarios that only require two PCN encoding
states. This document describes an experimental extension to the
base-encoding in the IP header that adds two capabilities: <list
style="symbols">
<t>the addition of a third PCN encoding state in the IP header</t>
<t>preservation of the end-to-end semantics of the ECN field even
though PCN uses the field within a PCN-region that interrupts the
end-to-end path</t>
</list> The second of these capabilities is optional and the reasons
for doing it are discussed in <xref
target="pcn_3_enc_ecn_support"></xref>.</t>
<t>As in the baseline encoding, this extension encoding re-uses the ECN
bits within the IP header within a controlled PCN-domain. This extension
requires the use of two DSCPs as described later in this document. This
experimental scheme is one of three that are being proposed within the
PCN working group. The aim is to allow implementors to decide which
scheme is most suitable for possible future standardisation.</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 encoding described in this document 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 title="Changes from Previous Drafts (to be removed by the RFC Editor)">
<t>From draft-ietf-pcn-3-state-encoding-01 to 02:<list style="symbols">
<t> Changed the document from teh experimental to the historic track </t>
<t> Added notes to the Introduciton and Abstract explaining the change
to historical</t>
<t>Updated refs</t>
</list></t>
<t>From draft-ietf-pcn-3-state-encoding-00 to 01:<list style="symbols">
<t>Removed text implying the two DSCPs have different priority and
added <xref target="pcn_3_enc_PHB"></xref> specifying they must
both have the same PHB.</t>
<t>Made IANA considerations text more precise.</t>
<t>Changed variable names for DSCP 1 & DSCP 2 to DSCP n &
DSCP m to be consistent with baseline encoding.</t>
<t>Updated refs</t>
</list></t>
<t>From draft-moncaster-pcn-3-state-encoding-01 to
draft-ietf-pcn-3-state-encoding-00: <list style="symbols">
<t>Changed to WG draft. Title changed from "A three state extended
PCN encoding scheme"</t>
<t>Imposed new structure on document. This structure is intended
to be followed by all extensions to the baseline PCN encoding
scheme.</t>
<t>Extensive changes throughout to ensure consistency with the
baseline PCN encoding scheme.</t>
</list></t>
<t>From draft-moncaster-pcn-3-state-encoding-00 to 01: <list
style="symbols">
<t>Checked terminology for consistency with <xref
target="RFC5696"></xref></t>
<t>Minor editorial changes.</t>
</list></t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_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 anchor="pcn_3_enc_terminology" title="Terminology">
<t>Most of the terminology used in this document is defined either in
<xref target="RFC5559"></xref> or in <xref target="RFC5696"></xref>. The
following additional terms are defined in this document: <list
style="symbols">
<t>PCN-flow - a flow covered by a reservation but which hasn't
signalled that it requires end-to-end ECN support.</t>
<t>PCN-enabled-ECN-flow - a flow covered by reservation and for
which the end-to-end transport has explicitly negotiated ECN support
from the PCN-boundary-nodes.</t>
<t>Not-marked (xxx), where xxx represents a standard ECN codepoint -
packets that are PCN capable but carry no PCN mark. Abbreviated as
NM(xxx). The (xxx) represents the ECN codepoint that the packet
arrived with at the PCN-ingress-node e.g. NM(CE) represents a PCN
capable packet that has no PCN marking but which arrived with the
ECN bits set to congestion experienced.</t>
</list></t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_why"
title="The Requirement for Three PCN Encoding States">
<t>The PCN Marking Behaviours document <xref target="RFC5670"></xref>
describes proposed PCN schemes that require 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. The
constraints imposed by the way tunnels process the ECN field severely
limit how to encode these states as explained in <xref
target="RFC5696"></xref> and <xref
target="RFC6040"></xref>. The obvious way to provide
one more encoding state than the base encoding is through the use of an
additional PCN-compatible DiffServ codepoint.</t>
<t>One aim of this document is to allow for experiments to show whether
such schemes are better than those that only employ two PCN encoding
states. As such, the additional DSCP will be taken from the EXP/LU pools
defined in <xref target="RFC2474"></xref>. If the experiments
demonstrate that PCN schemes employing three encoding states are
significantly better than those only employing two, then at a later date
IANA might be asked to assign a new PCN enabled DSCP from pool 1. Note
that there are other experimental encoding schemes being considered
which only use one DSCP but require either alternative tunnel semantics
(<xref target="I-D.ietf-pcn-3-in-1-encoding"></xref>) or additional
signalling (<xref target="I-D.ietf-pcn-psdm-encoding"></xref>)in order
to work.</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_ecn_support"
title="Adding Limited End-to-End ECN Support to PCN">
<t>There are a
number of use-cases where explicit preservation of end-to-end ECN
semantics might be needed across a PCN domain. One of the use-cases
suggests that the end-nodes might be running rate-adaptive codecs that
would respond to ECN marks by reducing their transmission rate. If the
sending transport sets the ECT codepoint, the setting of the ECN field
as it arrives at the PCN ingress node will need to be re-instated as it
leaves the PCN egress node.</t>
<t>If a PCN region is starting to suffer pre-congestion then it may make
sense to expose marks generated within the PCN region by forwarding CE
marks from the PCN egress to such a rate-adaptive endpoint. They would
be in addition to any CE marks generated elsewhere on the end-to-end
path. This would allow the endpoints to reduce the traffic rate. This
will in turn help to alleviate the pre-congestion, potentially averting
any need for call blocking or termination. However, the 'leaking' of CE
marks out of the PCN region is potentially dangerous and could violate
<xref target="RFC4774"></xref> if the end hosts don't understand ECN
(see section 18.1.4 of <xref target="RFC3168"></xref>).</t>
<t>Therefore, a PCN region can only support end-to-end ECN if the
PCN-boundary-nodes are sure that the end-to-end transport is
ECN-capable. That way the PCN-egress-nodes can ensure that they only
expose CE marks to those receivers that will correctly interpret them as
a notification of congestion. The end-points may indicate they are
ECN-capable through some higher-layer signalling process that sets up
their reservation with the PCN boundary nodes. The exact process of
negotiation is beyond the scope of this document but is likely to
involve explicit two way signalling between the end-host and the
PCN-domain.</t>
<t>In the absence of such signalling the default behaviour of the PCN
egress node will be to clear the ECN field to 00 as in the baseline PCN
encoding <xref target="RFC5696"></xref>.</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_IP" title="Encoding Three PCN States in IP">
<t>The three state PCN encoding scheme is based closely on that defined
in <xref target="RFC5696"></xref> so that there will be no compatibility
issues if a PCN-domain changes from using the baseline encoding scheme
to the experimental scheme described here. There are two versions of the
scheme. The basic three state scheme allows for carrying both
Threshold-marked (ThM) and Excess-traffic-marked (ETM) traffic. The full
scheme additionally allows end-to-end ECN to be carried across the
PCN-domain.</t>
<section anchor="pcn_3_enc_base" title="Basic Three State Encoding">
<t><xref target="pcn_3_enc_Tab_3_state_base"></xref> below shows how
to encode the three PCN states in IP.</t>
<texttable anchor="pcn_3_enc_Tab_3_state_base"
title="Encoding three PCN states in IP">
<ttcol align="center">DSCP</ttcol>
<ttcol align="center">Not-ECT (00)</ttcol>
<ttcol align="center">ECT(0) (10)</ttcol>
<ttcol align="center">ECT(1) (01)</ttcol>
<ttcol align="center">CE (11)</ttcol>
<c>DSCP n</c>
<c>Not-PCN</c>
<c>NM</c>
<c>CU</c>
<c>ThM</c>
<c>DSCP m</c>
<c>Not-PCN</c>
<c>CU</c>
<c>CU</c>
<c>ETM</c>
<postamble>(where DSCP n is a PCN-compatible DiffServ codepoint (see
<xref target="RFC5696"></xref>) and DSCP m is a PCN-compatible DSCP
from the EXP/LU pools as defined in <xref
target="RFC2474"></xref>)</postamble>
</texttable>
</section>
<section anchor="pcn_3_enc_full" title="Full Three State Encoding">
<t><xref target="pcn_3_enc_Tab_3_state_full" /> shows how to
additionally carry the end-to-end ECN state in the IP header.</t>
<texttable anchor="pcn_3_enc_Tab_3_state_full"
title="Encoding three PCN states in IP">
<ttcol align="center">DSCP</ttcol>
<ttcol align="center">Not-ECT (00)</ttcol>
<ttcol align="center">ECT(0) (10)</ttcol>
<ttcol align="center">ECT(1) (01)</ttcol>
<ttcol align="center">CE (11)</ttcol>
<c>DSCP n</c>
<c>Not-PCN</c>
<c>NM(Not-ECT)</c>
<c>NM(CE)</c>
<c>ThM</c>
<c>DSCP m</c>
<c>Not-PCN</c>
<c>NM(ECT(0))</c>
<c>NM(ECT(1))</c>
<c>ETM</c>
<postamble>(where DSCP n is a PCN-compatible DiffServ codepoint (see
<xref target="RFC5696" />) and DSCP m is a PCN-compatible DSCP from
the EXP/LU pools as defined in <xref
target="RFC2474" />)</postamble>
</texttable>
<t>The four different Not-marked (NM) states allow for the addition of
limited end-to-end ECN support as explained in the previous
section.</t>
<t><list style="hanging">
<t hangText="WARNING:"> In order to comply with this encoding all the nodes within the
PCN-domain MUST be configured with this encoding scheme. However
there may be operators who choose not to be fully compliant with the
scheme. If an operator chooses to leave some PCN-interior-nodes that
only support two marking states (the baseline encoding <xref
target="RFC5696" />), then they must be aware of the following:
Ideally such nodes would be configured to indicate pre-congestion or
congestion using the ETM state since this would ensure they could
notify worst-case congestion, however this is not possible since it
requires the packets to be re-marked to DSCP m (hence altering the
baseline encoding). This means that such nodes will only be able to
indicate ThM traffic.</t></list></t>
</section>
<section anchor="pcn_3_enc_PHB"
title="Common Diffserv Per-Hop Behaviour">
<t>Packets carrying Diffserv codepoint 'DSCP n' or 'DSCP m' MUST all
be treated with the same Diffserv PHB <xref target="RFC2474"></xref>.
The choice of PHB is discussed in <xref target="RFC5559"></xref> and
<xref target="RFC5696"></xref>.</t>
<t>Two DSCPs are merely used to provide sufficient PCN encoding
states, there is no need or intention to provide different scheduling
or drop preference for each row in the table of PCN codepoints.
Specifically:<list style="symbols">
<t>Both DSCPs MUST be served in the same queue to prevent
reordering within an application flow.</t>
<t>Both DSCPs MUST be assigned the same drop preference. Note that
<xref target="RFC5670"></xref> already provides for preferential
drop of excess-rate-marked packets, so assigning additional drop
preference at the coarser granularity of each DSCP would be
incorrect.</t>
</list></t>
</section>
<section anchor="pcn_3_enc_valid_ingress"
title="Valid and invalid codepoint transitions at PCN-ingress-nodes">
<t>A PCN-ingress-node operating the Basic version of the 3-State
Encoding scheme MUST set the Not-marked codepoint on any arriving
packet that belongs to a PCN-flow. It MUST set the not-PCN codepoint
on any other packet.</t>
<t>A PCN-ingress-node operating the Full version of the 3-State
Encoding scheme MUST establish whether a packet is a member of a
PCN-enabled-ECN-flow. If it is, the PCN-ingress-node MUST set the
appropriate NM(xxx) codepoint depending on the value carried in the
ECN field of that packet. To be clear: <list style="symbols">
<t>A packet carrying the not-ECT codepoint in the ECN field MUST
be assigned the NM(not-ECT) codepoint</t>
<t>A packet carrying the ECT(0) codepoint in the ECN field MUST be
assigned the NM(ECT(0)) codepoint</t>
<t>A packet carrying the ECT(1) codepoint in the ECN field MUST be
assigned the NM(ECT(1)) codepoint</t>
<t>A packet carrying the CE codepoint in the ECN field MUST be
assigned the NM(CE) codepoint</t>
</list> If it is not a member of such a flow then the behaviour MUST
be the same as for the Basic version of the Encoding scheme.</t>
</section>
<section anchor="pcn_3_enc_valid_interior"
title="Valid and invalid codepoint transitions at PCN-interior-nodes">
<t>A PCN-interior-node MUST obey the following rules: <list
style="symbols">
<t>It MUST NOT change the not-PCN codepoint to any other
codepoint.</t>
<t>It MAY change any Not-marked codepoint to either the
Threshold-marked or Excess-traffic-marked codepoints.</t>
<t>It MUST NOT change a Not-marked codepoint to the not-PCN
codepoint.</t>
<t>A Not-marked codepoint MUST NOT be changed to any other
Not-marked codepoint.</t>
<t>It MAY change the ThM codepoint to the ETM codepoint but it
MUST NOT change the ThM codepoint to any other codepoint.</t>
<t>It MUST NOT change the ETM codepoint to any other
codepoint.</t>
</list> Obviously in every case a codepoint can remain unchanged.
The precise rules governing which valid transition to use are set out
in <xref target="RFC5670"></xref></t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_forward"
title="Forwarding traffic out of the PCN-domain">
<t>As each packet exits the PCN-domain, the PCN-egress-node MUST check
whether it belongs to a PCN-enabled-ECN-flow. If it belongs to such a
flow then the following rules dictate how the ECN field should be
reset: <list style="symbols">
<t>A packet carrying the not-PCN codepoint MUST be given the
not-ECT codepoint.</t>
<t>A packet carrying the NM(not-ECT) codepoint MUST be assigned
the not-ECT codepoint.</t>
<t>A packet carrying the NM(ECT(0)) codepoint MUST be assigned the
ECT(0) codepoint.</t>
<t>A packet carrying the NM(ECT(1)) codepoint MUST be assigned the
ECT(1) codepoint.</t>
<t>A packet carrying the NM(CE) codepoint MUST be assigned the CE
codepoint.</t>
<t>A packet carrying the ThM codepoint MUST be assigned CE
codepoint.</t>
<t>A packet carrying the ETM codepoint MUST be assigned CE
codepoint.</t>
</list> If the packet is part of a PCN-flow then it MUST be assigned
the not-ECT codepoint regardless of which PCN-codepoint it
carried.</t>
<t>In addition all packets should have their DSCP reset to the
appropriate DSCP for the next hop. If the next hop is not another PCN
region this will not be a PCN-compatible DSCP, and by default will be
the best-efforts DSCP. Alterntively, higher layer signalling
mechanisms may allow the DSCP that packets entered the PCN-domain with
to be reinstated.</t>
</section>
<!-- ================================================================ -->
</section>
<section anchor="pcn_3_enc_protocol"
title="PCN-domain support for the PCN extension encoding">
<t>PCN traffic MUST be marked with a DiffServ codepoint that indicates
PCN is enabled. To comply with the PCN extension encoding, codepoint
'DSCP n' MUST be a PCN-compatible DSCP assigned by IANA for use with the
baseline PCN encoding <xref target="RFC5696"></xref> while 'DSCP m' can
be a DSCP from pools 2 or 3 for experimental and local use <xref
target="RFC2474"></xref>. The exact choice of DSCP may vary between
PCN-domains but MUST be fixed within each PCN-domain.</t>
<section anchor="pcn_3_enc_transport"
title="End-to-End transport behaviour compliant with the PCN extension encoding">
<t>Transports wishing to use both PCN and end-to-end ECN MUST
establish that their path supports this combination. Support of
end-to-end ECN by PCN-boundary-nodes is OPTIONAL. Therefore transports
MUST check with both the PCN-ingress-node and PCN-egress-node for each
flow. The sending of such a request MUST NOT be taken to mean the
request has been granted. The PCN-boundary-nodes MAY choose to inform
the end-node of a successful request. The exact mechanism for such
negotiation is beyond the scope of this document. A transport that
receives no response or a negative response to a request to support
end-to-end ECN within a flow reservation MUST set the ECN field of all
subsequent packets in that flow to Not-ECT if it wishes to guarantee
that the flow will receive PCN treatment.</t>
<t>If a domain wishes to use the full scheme described in <xref
target="pcn_3_enc_Tab_3_state_full"></xref> all nodes in that domain
MUST be configured to understand the full scheme.</t>
<t>If either of a PCN ingress-egress pair does not support end-to-end
ECN or if the end-to-end transport does not request support for
end-to-end ECN then the PCN-boundary-nodes MUST assume the packet
belongs to a PCN-flow.</t>
</section>
</section>
<!-- ================================================================ -->
<section title="IANA Considerations">
<t>This document asks IANA to assign one DiffServ codepoint from Pool 2
or Pool 3 (for experimental/local use)<xref target="RFC2474"></xref>.
Should this experimental PCN scheme prove sufficiently successful then
IANA will be requested in a later document to assign a dedicated
DiffServ codepoint from pool 1 for standards use and the experimental
codepoint will be returned to its IANA pool.</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_security" title="Security Considerations">
<t>The security concerns relating to this extended PCN encoding are
essentially the same as those in <xref target="RFC5696"></xref>.</t>
<t>This extension coding gives end-to-end support for the ECN nonce
<xref target="RFC3540"></xref>, which is intended to protect the sender
against the receiver or against network elements concealing a congestion
experienced marking or a lost packet. PCN-based reservations combined
with end-to-end ECN are intended for partially inelastic traffic using
rate-adaptive codecs. Therefore the end-to-end transport is unlikely to
be TCP, but at this time the nonce has only been defined for TCP
transports.</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_3_enc_Conclusions" title="Conclusions">
<t>This document describes an extended encoding scheme for PCN that
provides for three encoding states as well as optional support for
end-to-end ECN. The encoding scheme builds on the baseline encoding
described in <xref target="RFC5696"></xref>. Using this encoding scheme
it is possible for operators to conduct experiments to check whether the
addition of an extra encoding state will significantly improve the
performance of PCN. It will also allow experiments to determine whether
there is a need for end-to-end ECN support within the PCN-domain (as
against end-to-end ECN support through the use of IP-in-IP tunnelling or
by downgrading the traffic to a lower service class).</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_enc_Acknowledgements" title="Acknowledgements">
<t>This document builds extensively on work done in the PCN working
group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Joe Babiarz
and others. Full details of alternative schemes that were considered for
adoption can be found in the document <xref
target="I-D.ietf-pcn-encoding-comparison"></xref>.</t>
</section>
<!-- ================================================================ -->
<section anchor="pcn_enc_Comments_Solicited" title="Comments Solicited">
<t>(Section to be removed by RFC_Editor) Comments and questions are
encouraged and very welcome. They can be addressed to the IETF Transport
Area working group mailing list <tsvwg@ietf.org>, and/or to the
authors.</t>
</section>
</middle>
<back>
<!-- ================================================================ -->
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4774" ?>
<?rfc include="reference.RFC.5670" ?>
<?rfc include="reference.RFC.5696" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6040" ?>
<?rfc include="reference.RFC.2474" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.3540" ?>
<?rfc include="reference.RFC.5559" ?>
<?rfc include="reference.I-D.ietf-pcn-encoding-comparison" ?>
<?rfc include="reference.I-D.ietf-pcn-3-in-1-encoding" ?>
<?rfc include="reference.I-D.ietf-pcn-psdm-encoding" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:17:40 |