One document matched: draft-ietf-pcn-3-in-1-encoding-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY draft-ietf-pcn-cl-edge-behaviour SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcn-cl-edge-behaviour.xml">
<!ENTITY draft-ietf-pcn-sm-edge-behaviour SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcn-sm-edge-behaviour.xml">
<!ENTITY draft-ietf-pcn-encoding-comparison SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcn-encoding-comparison.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC5670 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5670.xml">
<!ENTITY RFC5696 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5696.xml">
<!ENTITY RFC5559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5559.xml">
<!ENTITY RFC5129 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5129.xml">
]>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-ietf-pcn-3-in-1-encoding-11"
ipr="trust200902" obsoletes="5696">
<front>
<title abbrev="3-in-1 PCN Encoding">Encoding 3 PCN-States in the IP header
using 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://bobbriscoe.net/</uri>
</address>
</author>
<author fullname="Toby Moncaster" initials="T." surname="Moncaster">
<organization>Moncaster Internet Consulting</organization>
<address>
<postal>
<street>Dukes</street>
<street>Layer Marney</street>
<city>Colchester</city>
<code>CO5 9UZ</code>
<country>UK</country>
</postal>
<phone>+44 7764 185416</phone>
<email>toby@moncaster.com</email>
<uri>http://www.moncaster.com/</uri>
</address>
</author>
<author fullname="Michael Menth" initials="M." surname="Menth">
<organization>University of Tuebingen</organization>
<address>
<postal>
<street>Sand 13</street>
<code>72076</code>
<city>Tuebingen</city>
<country>Germany</country>
</postal>
<phone>+49 7071 2970505</phone>
<email>menth@informatik.uni-tuebingen.de</email>
</address>
</author>
<date day="17" month="April" year="2012" />
<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. Egress nodes pass information about these PCN-marks
to decision points which then decide whether to admit or block new flow
requests or to terminate some already-admitted flows during serious
pre-congestion.</t>
<t>This document specifies how PCN-marks are to be encoded into the IP
header by re-using the Explicit Congestion Notification (ECN) codepoints
within a PCN-domain. The PCN wire protocol for non-IP protocol headers
will need to be defined elsewhere. Nonetheless, this document clarifies
the PCN encoding for MPLS in an informational Appendix. The encoding for
IP provides for up to three different PCN marking states using a single
DSCP: Not-marked (NM), Threshold-marked (ThM) and Excess-traffic-marked
(ETM). Hence, it is called the 3-in-1 PCN encoding. This document
obsoletes RFC5696.</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 flow termination to
terminate some existing flows during serious pre-congestion. 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 real congestion occurs (hence "pre-congestion
notification").</t>
<t><xref target="RFC5670"></xref> provides for two metering and marking
functions that are generally configured with different reference rates.
Threshold-marking marks all PCN packets once their traffic rate on a
link exceeds the configured reference rate (PCN-threshold-rate).
Excess-traffic-marking marks only those PCN packets that exceed the
configured reference rate (PCN-excess-rate). The PCN-excess-rate is
typically larger than the PCN-threshold-rate <xref
target="RFC5559"></xref>. Egress nodes monitor the PCN-marks of received
PCN-packets and pass information about these PCN-marks to decision
points which then decide whether to admit new flows or terminate
existing flows <xref target="I-D.ietf-pcn-cl-edge-behaviour"></xref>,
<xref target="I-D.ietf-pcn-sm-edge-behaviour"></xref>.</t>
<t>The encoding defined in <xref target="RFC5696"></xref> described how
two PCN marking states (Not-marked and PCN-Marked) could be encoded into
the IP header using a single Diffserv codepoint. It defined 01 as an
experimental codepoint (EXP), along with guidelines for its use. Two PCN
marking states are sufficient for the Single Marking edge behaviour
<xref target="I-D.ietf-pcn-sm-edge-behaviour"></xref>. However,
PCN-domains utilising the controlled load edge behaviour <xref
target="I-D.ietf-pcn-cl-edge-behaviour"></xref> require three PCN
marking states. This document extends the RFC5696 encoding by redefining
the experimental codepoint as a third PCN marking state in the IP
header, but still using a single Diffserv codepoint. This encoding
scheme is therefore called the "3-in-1 PCN encoding". It obsoletes the
<xref target="RFC5696"></xref> encoding, which provides only a sub-set
of the same capabilities.</t>
<t>The full version of the 3-in-1 encoding requires any tunnel endpoint
within the PCN-domain to support the normal tunnelling rules defined in
<xref target="RFC6040"></xref>. There is one limited exception to this
constraint where the PCN-domain only uses the excess-traffic-marking
behaviour and where the threshold-marking behaviour is deactivated. This
is discussed in <xref target="pcn3in1_interior_ETM_only"></xref>.</t>
<t>This document only concerns the PCN wire protocol encoding for IP
headers, whether IPv4 or IPv6. It makes no changes or recommendations
concerning algorithms for congestion marking or congestion response.
Other documents will define the PCN wire protocol for other header
types. <xref target="pcn3in1_app_map_IP_MPLS"></xref> discusses a
possible mapping between IP and MPLS.</t>
<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"></xref>.</t>
</section>
<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-10 to -11:"><list
style="symbols">
<t>Pointed out that any DSCP re-mapping must precede
PCN-ingress processing;</t>
<t>Ingress behaviour for ECN-capable PCN-packets: allowed any
PCN-capable encapsulation, not just IP-in-IP tunnelling. Added
cautionary note about MPLS PHP;</t>
<t>PCN-policing at ingress: <list style="symbols">
<t>Clarified what per-flow policing entails;</t>
<t>Clarified that a DSCP of zero is '000000';</t>
<t>For policed packets, added SHOULD log, MAY alarm;</t>
</list></t>
<t>Updated refs and acks.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-09 to -10:"><list
style="symbols">
<t>Added cautionary management advice to S6.2 (backwards
compatibility with RFC5696)</t>
<t>Removed "emphatically" from normative "NOT RECOMMENDED"
text.</t>
<t>Minor editoral changes.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-08 to -09:"><list
style="symbols">
<t>Added note about fail-safe to protect other traffic in the
event of tunnel misconfiguration.</t>
<t>Changed section heading to be about applicability of
environments to the encoding, rather than the encoding to the
environments.</t>
<t>Completely re-wrote PCN-ingress Node Behaviour section.</t>
<t>Changed PCN interior node to PCN-node where the term was
intended to include all PCN-nodes.</t>
<t>Clarified status of ECN/PCN co-existence appendix. Removed
inconsistent assertion in this appendix that an
admission-control DSCP alone can indicate that arriving
traffic is PCN-traffic.</t>
<t>A few clarifying editorial amendments and updated refs.</t>
</list></t>
<t
hangText="From draft-ietf-pcn-3-in-1-encoding-07 to -08:">Editorial
corrections and clarifications.</t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-06 to -07:"><list
style="symbols">
<t>Clarified that each operator not the IETF chooses which
DSCP(s) are PCN-compatible, and made it unambiguous that only
PCN-nodes recognise that PCN-compatible DSCPs enable the
3-in-1 encoding.</t>
<t>Removed statements about the PCN working group, given RFCs
are meant to survive beyond the life of a w-g.</t>
<t>Corrected the final para of "Rationale for Different
Behaviours in Schemes with Only One Marking"</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-05 to -06:"><list
style="symbols">
<t>Draft re-written to obsolete baseline encoding <xref
target="RFC5696"></xref>.</t>
<t>New section defining utilising this encoding for only one
PCN-Marking. Added an appendix explaining an apparent
inconsistency within this section.</t>
<t>Moved (and updated) informative appendixes from <xref
target="RFC5696"></xref> to this document. Original Appendix C
was omitted as it is now redundant.</t>
<t>Significant re-structuring of document.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-04 to -05:"><list
style="symbols">
<t>Draft moved to standards track as per working group
discussions.</t>
<t>Added <xref target="pcn3in1_app_ecn_coexist"></xref>
discussing ECN handling in the PCN-domain.</t>
<t>Clarified that this document modifies <xref
target="RFC5696"></xref>.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-03 to -04:"><list
style="symbols">
<t>Updated document to reflect RFC6040.</t>
<t>Re-wrote introduction.</t>
<t>Re-wrote section on applicability.</t>
<t>Re-wrote section on choosing encoding scheme.</t>
<t>Updated author details.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-02 to -03:"><list
style="symbols">
<t>Corrected mistakes in introduction and improved overall
readability.</t>
<t>Added new terminology.</t>
<t>Rewrote a good part of Section 4 and 5 to achieve more
clarity.</t>
<t>Added appendix explaining when to use which encoding scheme
and how to encode them in MPLS shim headers.</t>
<t>Added new co-author.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-01 to -02:"><list
style="symbols">
<t>Corrected mistake in introduction, which wrongly stated
that the threshold-traffic rate is higher than the
excess-traffic rate. Other minor corrections.</t>
<t>Updated acks & refs.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-00 to -01:"><list
style="symbols">
<t>Altered the wording to make sense if
draft-ietf-tsvwg-ecn-tunnel 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_defs_reqs_abbrev"
title="Definitions and Abbreviations">
<section anchor="pcn3in1_Terminology" title="Terminology">
<t>The terms PCN-domain, PCN-node, PCN-interior-node,
PCN-ingress-node, PCN-egress-node, PCN-boundary-node, PCN-traffic,
PCN-packets and PCN-marking are used as defined in <xref
target="RFC5559"></xref>. The following additional terms are defined
in this document: <list style="hanging">
<t hangText="PCN encoding:">mapping of PCN marking states to
specific codepoints in the packet header.</t>
<t hangText="PCN-compatible Diffserv codepoint:">a Diffserv
codepoint indicating packets for which the ECN field carries
PCN-markings rather than <xref target="RFC3168"></xref> markings.
Note that an operator configures PCN-nodes to recognise
PCN-compatible DSCPs, whereas the same DSCP has no PCN-specific
meaning to a node outside the PCN domain.</t>
<t hangText="Threshold-marked codepoint:">a codepoint that
indicates a packet has been threshold-marked; that is a packet
that has been marked at a PCN-interior-node as a result of an
indication from the threshold-metering function <xref
target="RFC5670"></xref>. Abbreviated to ThM.</t>
<t hangText="Excess-traffic-marked codepoint:">a codepoint that
indicates packets that have been marked at a PCN-interior-node as
a result of an indication from the excess-traffic-metering
function <xref target="RFC5670"></xref>. Abbreviated to ETM.</t>
<t hangText="Not-marked codepoint:">a codepoint that indicates
PCN-packets that are not PCN-marked. Abbreviated to NM.</t>
<t hangText="Not-PCN codepoint:">a codepoint that indicates
packets that are not PCN-packets.</t>
</list></t>
</section>
<section anchor="pcn_enc_abbreviations" title="List of Abbreviations">
<t>The following abbreviations are used in this document: <list
style="symbols">
<t>AF = Assured Forwarding <xref target="RFC2597"></xref></t>
<t>CE = Congestion Experienced <xref target="RFC3168"></xref></t>
<t>CS = Class Selector <xref target="RFC2474"></xref></t>
<t>DSCP = Diffserv codepoint</t>
<t>e2e = end-to-end</t>
<t>ECN = Explicit Congestion Notification <xref
target="RFC3168"></xref></t>
<t>ECT = ECN Capable Transport <xref target="RFC3168"></xref></t>
<t>EF = Expedited Forwarding <xref target="RFC3246"></xref></t>
<t>ETM = Excess-traffic-marked</t>
<t>EXP = Experimental</t>
<t>NM = Not-marked</t>
<t>PCN = Pre-Congestion Notification</t>
<t>PHB = Per-hop behaviour <xref target="RFC2474"></xref></t>
<t>ThM = Threshold-marked</t>
</list></t>
</section>
</section>
<section anchor="pcn3in1_Encoding"
title="Definition of 3-in-1 PCN Encoding">
<t>The 3-in-1 PCN encoding scheme supports networks that need three
PCN-marking states to be encoded within the IP header, as well as those
that need only two. The full encoding 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>A PCN-node will be configured to recognise certain DSCPs as
PCN-compatible. <xref target="pcn3in1_app_DSCP_choice"></xref> discusses
the choice of suitable DSCPs. In <xref
target="pcn3in1_Fig_Encoding"></xref> 'DSCP n' indicates such a
PCN-compatible DSCP. In the PCN-domain, any packet carrying a
PCN-compatible DSCP and with the ECN-field anything other than 00
(Not-PCN) is a PCN-packet as defined in <xref
target="RFC5559"></xref>.</t>
<t>PCN-nodes MUST interpret the ECN field of a PCN-packet using the
3-in-1 PCN encoding, rather than <xref target="RFC3168"></xref>. This
does not change the behaviour for any packet with a DSCP that is not
PCN-compatible, or for any node outside a PCN-domain. In all such cases
the 3-in-1 encoding is not applicable and so by default the node will
interpret the ECN field using <xref target="RFC3168"></xref>.</t>
<t>When using the 3-in-1 encoding, the codepoints of the ECN field have
the following meanings:<list style="hanging">
<t hangText="Not-PCN:">indicates a non-PCN-packet, i.e., a packet
that uses a PCN-compatible DSCP but is not subject to PCN metering
and marking.</t>
<t hangText="NM:">Not-marked. Indicates a PCN-packet that has not
yet been marked by any PCN marker.</t>
<t hangText="ThM:">Threshold-marked. Indicates a PCN-packet that has
been marked by a threshold-marker <xref
target="RFC5670"></xref>.</t>
<t hangText="ETM:">Excess-traffic-marked. Indicates a PCN-packet
that has been marked by an excess-traffic-marker <xref
target="RFC5670"></xref>.</t>
</list></t>
</section>
<section anchor="pcn3in1_Requirement_head"
title="Requirements for and Applicability of 3-in-1 PCN Encoding">
<section anchor="pcn3in1_Requirement" title="PCN Requirements">
<t>In accordance with the PCN architecture <xref
target="RFC5559"></xref>, PCN-ingress-nodes control packets entering a
PCN-domain. Packets belonging to PCN-controlled flows are subject to
PCN-metering and -marking, and PCN-ingress-nodes mark them as
Not-marked (PCN-colouring). All nodes in the PCN-domain perform
PCN-metering and PCN-mark PCN-packets if needed. There are two
different metering and marking behaviours: threshold-marking and
excess-traffic-marking <xref target="RFC5670"></xref>. Some edge
behaviours require only a single marking behaviour <xref
target="I-D.ietf-pcn-sm-edge-behaviour"></xref>, others require both
<xref target="I-D.ietf-pcn-cl-edge-behaviour"></xref>. In the latter
case, three PCN marking states are needed: Not-marked (NM) to indicate
not-marked packets, Threshold-marked (ThM) to indicate packets marked
by the threshold-marker, and Excess-traffic-marked (ETM) to indicate
packets marked by the excess-traffic-marker <xref
target="RFC5670"></xref>. Threshold-marking and excess-traffic-marking
are configured to start marking packets at different load conditions,
so one marking behaviour indicates more severe pre-congestion than the
other. Therefore, a fourth PCN marking state indicating that a packet
is marked by both markers is not needed. However a fourth codepoint is
required to indicate packets that use a PCN-compatible DSCP but do not
use PCN-marking (the Not-PCN codepoint).</t>
<t>In all current PCN edge behaviours that use two marking behaviours
<xref target="RFC5559"></xref>, <xref
target="I-D.ietf-pcn-cl-edge-behaviour"></xref>,
excess-traffic-marking is configured with a larger reference rate than
threshold-marking. We take this as a rule and define
excess-traffic-marked as a more severe PCN-mark than
Threshold-marked.</t>
</section>
<section anchor="pcn3in1_Requirements_Tunnelling"
title="Requirements Imposed by Tunnelling">
<t><xref target="RFC6040"></xref> defines rules for the encapsulation
and decapsulation of ECN markings within IP-in-IP tunnels. The
publication of RFC6040 removed the tunnelling constraints that existed
when the encoding of <xref target="RFC5696"></xref> was written (see
Section 3.3.2 of <xref
target="I-D.ietf-pcn-encoding-comparison"></xref>).</t>
<t>Nonetheless, there is still a problem if there are any legacy
(pre-RFC6040) decapsulating tunnel endpoints within a PCN domain. If a
PCN-node Threshold-marks the outer header of a tunnelled packet that
has a Not-marked codepoint on the inner header, a legacy decapsulator
will forward the packet as Not-marked, losing the Threshold-marking.
The rules on applicability in <xref
target="pcn3in1_Requirements_Applicability"></xref> below are designed
to avoid this problem.</t>
<t>Even if an operator accidentally breaks these applicability rules,
the order of severity of the 3-in-1 codepoints was chosen to protect
other PCN or non-PCN traffic. Although legacy pre-RFC6040 tunnels did
not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have
always propagated '11' correctly. Therefore '11' was chosen to signal
the most severe pre-congestion (ETM), so it would act as a reliable
fail-safe even if an overlooked legacy tunnel was suppressing 01 (ThM)
signals.</t>
</section>
<section anchor="pcn3in1_Requirements_Applicability"
title="Applicable Environments for the 3-in-1 PCN Encoding">
<t>The 3-in-1 encoding is applicable in situations where two marking
behaviours are being used in the PCN-domain. The 3-in-1 encoding can
also be used with only one marking behaviour, in which case one of the
codepoints MUST NOT be used anywhere in the PCN-domain (see <xref
target="pcn3in1_interior_one_mark_behaviour"></xref>).</t>
<t>With one exception (see next paragraph), any tunnel endpoints
(IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN
encapsulation and decapsulation rules set out in <xref
target="RFC6040"></xref> (see <xref
target="pcn3in1_Requirements_Tunnelling"></xref>).</t>
<t>Operators may not be able to upgrade every pre-RFC6040 tunnel
endpoint within a PCN-domain. In such circumstances a limited version
of the 3-in-1 encoding can still be used but only under the following
stringent condition. If any pre-RFC6040 tunnel decapsulator exists
within a PCN-domain then every PCN-node in the PCN-domain MUST be
configured so that it never sets the ThM codepoint. PCN-interior-nodes
in this case MUST solely use the Excess-traffic-marking function, as
defined in <xref target="pcn3in1_interior_ETM_only"></xref>. In all
other situations where legacy tunnel decapsulators might be present
within the PCN domain, the 3-in-1 encoding is not applicable.</t>
</section>
</section>
<section anchor="pcn3in1_Compliant_Node_Behaviour"
title="Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding">
<t>Any tunnel endpoint implementation on a PCN-node MUST comply with
<xref target="RFC6040"></xref>. Since PCN is a new capability, this is
considered a reasonable requirement.</t>
<section anchor="pcn3in1_common_ingress_behaviour"
title="PCN-ingress Node Behaviour">
<t>If packets arrive from another Diffserv domain, any re-mapping of
Diffserv codepoints MUST happen before PCN-ingress processing.</t>
<t>At each logical ingress link into a PCN domain, each PCN-ingress
node will apply the four functions described in Section 4.2 of <xref
target="RFC5559"></xref> to arriving packets. These functions are
applied in the following order: PCN-classify, PCN-police, PCN-colour,
PCN-rate-meter. This section describes these four steps, but only the
aspects relevant to packet encoding:</t>
<t><list style="hanging">
<t hangText="1. PCN-classification:">The PCN-ingress-node
determines whether each packet matches the filter spec of an
admitted flow. Packets that match are defined as PCN-packets.</t>
<t hangText="1b. Extra step if ECN and PCN co-exist:">If a packet
classified as a PCN-packet arrives with the ECN field already set
to a value other than Not-ECT (i.e. it is from an ECN-capable
transport) then to comply with BCP 124 <xref
target="RFC4774"></xref> it MUST pass through one of the following
preparatory steps before the PCN-policing and PCN-colouring steps.
The choice between these four actions depends on local
policy:<list style="symbols">
<t>Encapsulate ECN-capable PCN-packets across the
PCN-domain:<list style="symbols">
<t>either within another IP header using an RFC6040
tunnel;</t>
<t>or within a lower layer protocol capable of being PCN
marked, such as MPLS (see <xref
target="pcn3in1_app_map_IP_MPLS"></xref>).</t>
</list>Encapsulation using either of these methods is the
RECOMMENDED policy for ECN-capable PCN-packets, and
implementations SHOULD use IP-in-IP tunnelling as the
default.<vspace blankLines="1" />If encapsulation is used, it
MUST precede PCN-policing and PCN-colouring so that the
encapsulator and decapsulator are logically outside the PCN
domain (see <xref target="pcn3in1_app_ecn_coexist"></xref> and
specifically <xref target="pcn3in1_Fig_Tunnel"></xref>).
<vspace blankLines="1" />If MPLS encapsulation is used, note
that penultimate hop popping <xref target="RFC3031"></xref> is
incompatible with PCN, unless the penultimate hop applies the
PCN-egress node behaviour before it pops the PCN-capable MPLS
label.</t>
<t>If some form of encapsulation is not possible, the
PCN-ingress-node can allow through ECN-capable packets without
encapsulation, but it MUST drop CE-marked packets at this
stage. Failure to drop CE would risk congestion collapse,
because without encapsulation there is no mechanism to
propagate the CE markings across the PCN-domain (see <xref
target="pcn3in1_app_ecn_coexist"></xref>).<vspace
blankLines="1" />This policy is NOT RECOMMENDED because there
is no tunnel to protect the e2e ECN capability, which is
otherwise disabled when the PCN-egress-node zeroes the ECN
field.</t>
<t>Drop the packet.<vspace blankLines="1" />This policy is
also NOT RECOMMENDED, because it precludes the possibility
that e2e ECN can co-exist with PCN as a means of controlling
congestion.</t>
<t>Any other action that complies with <xref
target="RFC4774"></xref> (see <xref
target="pcn3in1_app_ecn_coexist"></xref> for an example).</t>
</list><xref target="pcn3in1_app_ecn_coexist"></xref> provides
more information about the co-existence of PCN and ECN.</t>
<t hangText="2. PCN-Policing:">The PCN-policing function only
allows appropriate packets into the PCN behaviour aggregate.
Per-flow policing actions may be required to block rejected flows
and to rate-police accepted flows, but these are specified in the
relevant edge-behaviour document, e.g. <xref
target="I-D.ietf-pcn-sm-edge-behaviour"></xref>, <xref
target="I-D.ietf-pcn-cl-edge-behaviour"></xref>. <vspace
blankLines="1" />Here we only specify packet-level PCN-policing,
which prevents packets that are not PCN-packets from being
forwarded into the PCN-domain if PCN-interior-nodes would
otherwise mistake them for PCN-packets. A non-PCN-packet will be
confused with a PCN-packet if on arrival it meets all three of the
following conditions: <list style="format %c)">
<t>it is not classified as a PCN-packet</t>
<t>it already carries a PCN-compatible DSCP</t>
<t>its ECN field carries a codepoint other than Not-ECT.</t>
</list>The PCN-ingress-node MUST police packets that meet all
three conditions (a-c) by subjecting them to one of the following
treatments:<list style="symbols">
<t>re-mark the DSCP to a DSCP that is not PCN-compatible;</t>
<t>tunnel the packet to the PCN-egress with a DSCP in the
outer header that is not PCN-compatible;</t>
<t>drop the packet (NOT RECOMMENDED—see below).</t>
</list><vspace blankLines="1" />The choice between these actions
depends on local policy. In the absence of any operator-specific
configuration for this case, by default an implementation SHOULD
re-mark the DSCP to zero (000000).<vspace
blankLines="1" />Whichever policing action is chosen, the
PCN-ingress-node SHOULD log the event and MAY also raise an alarm.
Alarms SHOULD be rate-limited so that the anomalous packets will
not amplify into a flood of alarm messages.<vspace
blankLines="1" />Rationale: Traffic that meets all three of the
above conditions (a-c) is not PCN-traffic, therefore ideally a
PCN-ingress ought not to interfere with it, but it has to do
something to avoid ambiguous packet markings. Clearing the ECN
field is not an appropriate policing action, because a network
node ought not to interfere with an e2e signal. Even if such
packets seem like an attack, drop would be overkill, because such
an attack can be neutralised by just re-marking the DSCP. And DSCP
re-marking in the network is legitimate, because the DSCP is not
considered an e2e signal.</t>
<t hangText="3. PCN-colouring:">If a packet has been classified as
a PCN-packet, once it has been policed, the PCN-ingress-node:<list
style="symbols">
<t>MUST set a PCN-compatible Diffserv codepoint on all
PCN-packets. To conserve DSCPs, Diffserv codepoints SHOULD be
chosen that are already defined for use with
admission-controlled traffic. <xref
target="pcn3in1_app_DSCP_choice"></xref> gives guidance to
implementors on suitable DSCPs.</t>
<t>MUST set the PCN codepoint of all PCN-packets to Not-marked
(NM).</t>
</list></t>
<t hangText="4. PCN rate-metering:">This fourth step may be
necessary depending on the edge-behaviour in force. It is listed
for completeness, but it is not relevant to this encoding
document.</t>
</list></t>
</section>
<section anchor="pcn3in1_interior_behaviour"
title="PCN-interior Node Behaviour">
<section anchor="pcn3in1_common_interior_behaviour"
title="Behaviour Common to all PCN-interior Nodes">
<t>Interior nodes MUST NOT change Not-PCN to any other
codepoint.</t>
<t>Interior nodes MUST NOT change NM to Not-PCN.</t>
<t>Interior nodes MUST NOT change ThM to NM or Not-PCN.</t>
<t>Interior nodes MUST NOT change ETM to any other codepoint.</t>
</section>
<section anchor="pcn3in1_two_mark_behaviour"
title="Behaviour of PCN-interior Nodes Using Two PCN-markings">
<t>If the threshold-meter function indicates a need to mark a
packet, the PCN-interior-node MUST change NM to ThM.</t>
<t>If the excess-traffic-meter function indicates a need to mark a
packet:<list style="symbols">
<t>the PCN-interior-node MUST change NM to ETM;</t>
<t>the PCN-interior-node MUST change ThM to ETM.</t>
</list></t>
<t>If both the threshold meter and the excess-traffic meter indicate
the need to mark a packet, the Excess-traffic-marking rules MUST
take precedence.</t>
</section>
<section anchor="pcn3in1_interior_one_mark_behaviour"
title="Behaviour of PCN-interior Nodes Using One PCN-marking">
<t>Some PCN edge behaviours require only one PCN-marking within the
PCN-domain. The Single Marking edge behaviour <xref
target="I-D.ietf-pcn-sm-edge-behaviour"></xref> requires
PCN-interior-nodes to mark packets using the excess-traffic-meter
function <xref target="RFC5670"></xref>. It is possible that future
schemes may require only the threshold-meter function. <xref
target="pcn3in1_app_rationale_diff_sm"></xref> explains the
rationale for the behaviours defined in this section.</t>
<section anchor="pcn3in1_interior_ETM_only"
title="Marking Using only the Excess-traffic-meter Function">
<t>The threshold-traffic-meter function SHOULD be disabled and
MUST NOT trigger any packet marking.</t>
<t>The PCN-interior-node SHOULD raise a management alarm if it
receives a ThM packet, but the frequency of such alarms SHOULD be
limited.</t>
<t>If the excess-traffic-meter function indicates a need to mark
the packet:<list style="symbols">
<t>the PCN-interior-node MUST change NM to ETM;</t>
<t>the PCN-interior-node MUST change ThM to ETM. It SHOULD
also raise an alarm as above.</t>
</list></t>
</section>
<section anchor="pcn3in1_interior_ThM_only"
title="Marking using only the Threshold-meter Function">
<t>The excess-traffic-meter function SHOULD be disabled and MUST
NOT trigger any packet marking.</t>
<t>The PCN-interior-node SHOULD raise a management alarm if it
receives an ETM packet, but the frequency of such alarms SHOULD be
limited.</t>
<t>If the threshold-meter function indicates a need to mark the
packet:<list style="symbols">
<t>the PCN-interior-node MUST change NM to ThM;</t>
<t>the PCN-interior-node MUST NOT change ETM to any other
codepoint. It SHOULD raise an alarm as above if it encounters
an ETM packet.</t>
</list></t>
</section>
</section>
</section>
<section anchor="pcn3in1_egress_behaviour"
title="PCN-egress Node Behaviour">
<t>A PCN-egress-node SHOULD set the Not-PCN (00) codepoint on all
packets it forwards out of the PCN-domain.</t>
<t>The only exception to this is if the PCN-egress-node is certain
that revealing other codepoints outside the PCN-domain won't
contravene the guidance given in <xref target="RFC4774"></xref>. For
instance, if the PCN-ingress-node has explicitly informed the
PCN-egress-node that this flow is ECN-capable, then it might be safe
to expose other ECN codepoints. <xref
target="pcn3in1_app_ecn_coexist"></xref> gives details of how such
schemes might work, but such schemes are currently only tentative
ideas.</t>
<t>If the PCN-domain is configured to use only Excess-traffic-marking,
the PCN-egress-node MUST treat ThM as ETM and, if only
threshold-marking is used, it SHOULD treat ETM as ThM. However it
SHOULD raise a management alarm in either case since this means there
is some misconfiguration in the PCN-domain.</t>
</section>
</section>
<section anchor="pcn3in1_Backward_Compatibility"
title="Backward Compatibility">
<section title="Backward Compatibility with ECN">
<t>BCP 124 <xref target="RFC4774"></xref> gives guidelines for
specifying alternative semantics for the ECN field. It sets out a
number of factors to be taken into consideration. It also suggests
various techniques to allow the co-existence of default ECN and
alternative ECN semantics. The encoding specified in this document
uses one of those techniques; it defines PCN-compatible Diffserv
codepoints as no longer supporting the default ECN semantics within a
PCN domain. As such, this document is compatible with BCP 124.</t>
<t>There is not enough space in one IP header for the 3-in-1 encoding
to support both ECN marking end-to-end and PCN-marking within a
PCN-domain. The non-normative <xref
target="pcn3in1_app_ecn_coexist"></xref> discusses possible ways to do
this, e.g. by carrying e2e ECN across a PCN-domain within the inner
header of an IP-in-IP tunnel. The normative text in <xref
target="pcn3in1_common_ingress_behaviour"></xref> requires one of
these methods to be configured at the PCN-ingress-node and recommends
that implementations offer tunnelling as the default.</t>
<t>In any PCN deployment, traffic can only enter the PCN-domain
through PCN-ingress-nodes and leave through PCN-egress-nodes.
PCN-ingress-nodes ensure that any packets entering the PCN-domain have
the ECN field in their outermost IP header set to the appropriate
codepoint. PCN-egress-nodes then guarantee that the ECN field of any
packet leaving the PCN-domain has appropriate ECN semantics. This
prevents unintended leakage of ECN marks into or out of the
PCN-domain, and thus reduces backward-compatibility issues.</t>
</section>
<section title="Backward Compatibility with the RFC5696 Encoding">
<t>Section 5.1 of the PCN architecture gives general guidance on fault
detection and diagnosis <xref target="RFC5559"></xref>, including
management analysis of PCN markings arriving at PCN-egress nodes to
detect early signs of potential faults. Because the PCN encoding has
gone through an obsoleted earlier stage <xref
target="RFC5696"></xref>, misconfiguration mistakes may be more
likely. Therefore extra monitoring, such as in the following example,
may be necessary to detect and diagnose potential problems:<list
style="empty">
<t>Informational example: In a controlled-load edge-behaviour
scenario it could be worth the PCN-egress node detecting the onset
of excess-traffic marking without any prior threshold-marking.
This might indicate that an interior node has been wrongly
configured to mark only ETM (which would have been correct for the
single-marking edge-behaviour).</t>
</list></t>
<t>A PCN-node implemented to use the obsoleted RFC5696 encoding could
conceivably have been configured so that the Threshold-meter function
marked what is now defined as the ETM codepoint in the 3-in-1
encoding. However, there is no known deployment of this rather
unlikely variant of RFC5696 and no reason to believe that such an
implementation would ever have been built. Therefore, it seems safe to
ignore this issue.</t>
</section>
</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>PCN-marking only carries a meaning within the confines of a
PCN-domain. This encoding document is intended to stand independently of
the architecture used to determine how specific packets are authorised
to be PCN-marked, which will be described in separate documents on
PCN-boundary-node behaviour.</t>
<t>This document assumes the PCN-domain to be entirely under the control
of a single operator, or a set of operators who trust each other.
However, future extensions to PCN might include inter-domain versions
where trust cannot be assumed between domains. If such schemes are
proposed, they must ensure that they can operate securely despite the
lack of trust. However, such considerations are beyond the scope of this
document.</t>
<t>One potential security concern is the injection of spurious PCN-marks
into the PCN-domain. However, these can only enter the domain if a
PCN-ingress-node is misconfigured. The precise impact of any such
misconfiguration will depend on which of the proposed PCN-boundary-node
behaviours is used, but in general spurious marks will lead to admitting
fewer flows into the domain or potentially terminating too many flows.
In either case, good management should be able to quickly spot the
problem since the overall utilisation of the domain will rapidly
fall.</t>
</section>
<section anchor="pcn3in1_Conclusions" title="Conclusions">
<t>The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field
to encode PCN-marks. One codepoint allows non-PCN traffic to be carried
with the same PCN-compatible DSCP and three other codepoints support
three PCN marking states with different levels of severity. In general,
the use of this PCN encoding scheme presupposes that any tunnel
endpoints within the PCN-domain comply with <xref
target="RFC6040"></xref>.</t>
</section>
<section anchor="pcn3in1_Acknowledgements" title="Acknowledgements">
<t>Many thanks to Philip Eardley for providing extensive feedback,
criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, Ruediger
Geib, Georgios Karagiannis, James Polk, Tom Taylor, Adrian Farrel and
everyone else who has commented on the document.</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.6040" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2597" ?>
<?rfc include="reference.RFC.3031" ?>
<?rfc include="reference.RFC.3246" ?>
<?rfc include="reference.RFC.3540" ?>
<?rfc include="reference.RFC.4594" ?>
<?rfc include="reference.RFC.4774" ?>
<?rfc include="reference.RFC.5127" ?>
<?rfc include="reference.RFC.5129" ?>
<?rfc include="reference.RFC.5462" ?>
<?rfc include="reference.RFC.5696" ?>
<?rfc include="reference.RFC.5865" ?>
<!--
<reference anchor="I-D.ietf-pcn-cl-edge-behaviour">
<front>
<title>PCN Boundary Node Behaviour for the Controlled Load (CL) Mode
of Operation</title>
<author fullname="Anna Charny" initials="A" surname="Charny">
<organization></organization>
</author>
<author fullname="Fortune Huang" initials="F" surname="Huang">
<organization></organization>
</author>
<author fullname="Georgios Karagiannis" initials="G"
surname="Karagiannis">
<organization></organization>
</author>
<author fullname="Michael Menth" initials="M" surname="Menth">
<organization></organization>
</author>
<author fullname="Tom Taylor" initials="T" surname="Taylor">
<organization></organization>
</author>
<date day="22" month="February" year="2012" />
<abstract>
<t>Pre-congestion notification (PCN) is a means for protecting the
quality of service for inelastic traffic admitted to a Diffserv
domain. The overall PCN architecture is described in RFC 5559.
This memo is one of a series describing possible boundary node
behaviours for a PCN-domain. The behaviour described here is that
for a form of measurement-based load control using three PCN
marking states, not- marked, threshold-marked, and
excess-traffic-marked. This behaviour is known informally as the
Controlled Load (CL) PCN-boundary-node behaviour.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-pcn-cl-edge-behaviour-12" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-12.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-pcn-sm-edge-behaviour">
<front>
<title>PCN Boundary Node Behaviour for the Single Marking (SM) Mode
of Operation</title>
<author fullname="Anna Charny" initials="A" surname="Charny">
<organization></organization>
</author>
<author fullname="Georgios Karagiannis" initials="G"
surname="Karagiannis">
<organization></organization>
</author>
<author fullname="Michael Menth" initials="M" surname="Menth">
<organization></organization>
</author>
<author fullname="Tom Taylor" initials="T" surname="Taylor">
<organization></organization>
</author>
<date day="22" month="February" year="2012" />
<abstract>
<t>Pre-congestion notification (PCN) is a means for protecting the
quality of service for inelastic traffic admitted to a Diffserv
domain. The overall PCN architecture is described in RFC 5559.
This memo is one of a series describing possible boundary node
behaviours for a PCN-domain. The behaviour described here is that
for a form of measurement-based load control using two PCN marking
states, not- marked, and excess-traffic-marked. This behaviour is
known informally as the Single Marking (SM) PCN-boundary-node
behaviour.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-pcn-sm-edge-behaviour-09" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-09.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-pcn-encoding-comparison">
<front>
<title>Overview of Pre-Congestion Notification Encoding</title>
<author fullname="Georgios Karagiannis" initials="G"
surname="Karagiannis">
<organization></organization>
</author>
<author fullname="Kwok Chan" initials="K" surname="Chan">
<organization></organization>
</author>
<author fullname="Toby Moncaster" initials="T" surname="Moncaster">
<organization></organization>
</author>
<author fullname="Michael Menth" initials="M" surname="Menth">
<organization></organization>
</author>
<author fullname="Philip Eardley" initials="P" surname="Eardley">
<organization></organization>
</author>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<date day="8" month="March" year="2012" />
<abstract>
<t>The objective of Pre-Congestion Notification (PCN) is to
protect the quality of service (QoS) of inelastic flows within a
Diffserv domain. On every link in the PCN domain, the overall rate
of the PCN-traffic is metered, and PCN-packets are appropriately
marked when certain configured rates are exceeded. Egress nodes
provide decision points with information about the PCN-marks of
PCN-packets which allows them to take decisions about whether to
admit or block a new flow request, and to terminate some already
admitted flows during serious pre- congestion. The PCN Working
Group explored a number of approaches for encoding this
pre-congestion information into the IP header. This document
provides details of all those approaches along with an explanation
of the constraints that had to be met by any solution.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-pcn-encoding-comparison-09" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-09.txt"
type="TXT" />
</reference>
-->
&draft-ietf-pcn-cl-edge-behaviour;
&draft-ietf-pcn-sm-edge-behaviour;
&draft-ietf-pcn-encoding-comparison;
</references>
<section anchor="pcn3in1_app_DSCP_choice" title="Choice of Suitable DSCPs">
<t>This appendix is informative, not normative.</t>
<t>A single DSCP has not been defined for use with PCN for several
reasons. Firstly, the PCN mechanism is applicable to a variety of
different traffic classes. Secondly, Standards Track DSCPs are in
increasingly short supply. Thirdly, PCN is not a scheduling behaviour --
rather, it should be seen as being a marking behaviour similar to ECN
but intended for inelastic traffic. The choice of which DSCP is most
suitable for a given PCN-domain is dependent on the nature of the
traffic entering that domain and the link rates of all the links making
up that domain. In PCN-domains with sufficient aggregation, the
appropriate DSCPs would currently be those for the Real-Time Treatment
Aggregate <xref target="RFC5127"></xref>. It is suggested that admission
control could be used for the following service classes (defined in
<xref target="RFC4594"></xref> unless otherwise stated): <list
style="symbols">
<t>Telephony (EF)</t>
<t>Real-time interactive (CS4)</t>
<t>Broadcast Video (CS3)</t>
<t>Multimedia Conferencing (AF4)</t>
<t>the VOICE-ADMIT codepoint defined in <xref
target="RFC5865"></xref>.</t>
</list>CS5 is excluded from this list since PCN is not expected to be
applied to signalling traffic.</t>
<t>PCN-marking is intended to provide a scalable admission-control
mechanism for traffic with a high degree of statistical multiplexing.
PCN-marking would therefore be appropriate to apply to traffic in the
above classes, but only within a PCN-domain containing sufficiently
aggregated traffic. In such cases, the above service classes may well
all be subject to a single forwarding treatment (treatment aggregate
<xref target="RFC5127"></xref>). However, this does not imply all such
IP traffic would necessarily be identified by one DSCP -- each service
class might keep a distinct DSCP within the highly aggregated region
<xref target="RFC5127"></xref>.</t>
<t>Guidelines for conserving DSCPs by allowing
non-admission-controlled-traffic to compete with PCN-traffic are given
in Appendix B.1 of <xref target="RFC5670"></xref>.</t>
<t>Additional service classes may be defined for which admission control
is appropriate, whether through some future standards action or through
local use by certain operators, e.g., the Multimedia Streaming service
class (AF3). This document does not preclude the use of PCN in more
cases than those listed above.</t>
<t>Note: The above discussion is informative not normative, as operators
are ultimately free to decide whether to use admission control for
certain service classes and whether to use PCN as their mechanism of
choice.</t>
</section>
<section anchor="pcn3in1_app_ecn_coexist"
title="Co-existence of ECN and PCN">
<t>This appendix is informative, not normative. It collects together
material relevant to co-existence of ECN and PCN, including that spread
throughout the body of this specification. If this results in any
conflict or ambiguity, the normative text in the body of the
specification takes precedence.</t>
<t>ECN <xref target="RFC3168"></xref> is an e2e congestion notification
mechanism. As such it is possible that some traffic entering the
PCN-domain may also be ECN-capable. The PCN encoding described in this
document re-uses the bits of the ECN field in the IP header.
Consequently, this disables ECN within the PCN domain.</t>
<t>For the purposes of this appendix we define two forms of traffic that
might arrive at a PCN-ingress-node. These are admission-controlled
traffic (PCN-traffic) and non-admission-controlled traffic
(non-PCN-traffic).</t>
<t>Flow signalling identifies admission controlled traffic, by
associating a filterspec with the need for admission control (e.g.
through RSVP or some equivalent message, e.g. from a SIP server to the
ingress or from a logically centralised network control system). The
PCN-ingress-node re-marks admission-conrolled traffic matching that
filterspec to a PCN-compatible DSCP. Note that the term flow need not
imply just one microflow, but instead could match an aggregate and/or
could depend on the incoming DSCP (see <xref
target="pcn3in1_app_DSCP_choice"></xref>).</t>
<t>All other traffic can be thought of as non-admission-controlled (and
therefore outside the scope of PCN). However such traffic may still need
to share the same DSCP as the admission-controlled traffic. This may be
due to policy (for instance if it is high priority voice traffic), or
may be because there is a shortage of local DSCPs.</t>
<t>Unless specified otherwise, for any of the cases in the list below,
an IP-in-IP tunnel that complies with<xref target="RFC6040"></xref> can
be used to preserve ECN markings across the PCN domain. The tunnelling
action should be applied wholly outside the PCN-domain as illustrated in
<xref target="pcn3in1_Fig_Tunnel"></xref>. Then, by the rules of
RFC6040, the tunnel egress propagates the ECN field from the inner
header, because the PCN-egress will have zeroed the outer ECN field.</t>
<figure anchor="pcn3in1_Fig_Tunnel"
title="Separation of tunnelling and PCN actions">
<artwork><![CDATA[
, . . . . . PCN-domain . . . . . .
. ,--------. ,--------. .
. _| PCN- |___________________| PCN- |_ .
. / | ingress | | egress | \ .
.| '---------' '--------' |.
| . . . . . . . . . . . . . . .|
,--------. ,--------.
_____| Tunnel | | Tunnel |____
| Ingress | - - ECN preserved inside tunnel - - | Egress |
'---------' '--------'
]]></artwork>
</figure>
<t>There are three cases for how e2e ECN traffic may wish to be treated
while crossing a PCN domain: <list style="hanging">
<t
hangText="a) Traffic that does not require PCN admission control:"><vspace
blankLines="0" />For example, traffic that does not match flow
signaling being used for admission control. In this case the e2e ECN
traffic is not treated as PCN-traffic. There are two possible
scenarios:<list style="symbols">
<t>Arriving traffic does not carry a PCN-compatible DSCP: no
action required.</t>
<t>Arriving traffic carries a DSCP that clashes with a
PCN-compatible DSCP. There are two options:<list style="numbers">
<t>The ingress maps the DSCP to a local DSCP with the same
scheduling PHB as the original DSCP, and the egress re-maps
it to the original PCN-compatible DSCP.</t>
<t>The ingress tunnels the traffic, setting the DSCP in the
outer header to a local DSCP with the same scheduling PHB as
the original DSCP.</t>
<t>The ingress tunnels the traffic, using the original DSCP
in the outer but setting Not-PCN in the outer header; note
that this turns off ECN for this traffic within the PCN
domain.</t>
</list>The first or second options are recommended unless the
operator is short of local DSCPs.</t>
</list></t>
<t hangText="b) Traffic that requires admission-control:"><vspace
blankLines="0" />In this case the e2e ECN traffic is treated as
PCN-traffic across the PCN domain. There are two options.<list
style="symbols">
<t>The PCN-ingress-node places this traffic in a tunnel with a
PCN-compatible DSCP in the outer header. The PCN-egress zeroes
the ECN-field before decapsulation.</t>
<t>The PCN-ingress-node drops CE-marked packets and otherwise
sets the ECN-field to NM and sets the DCSP to a PCN-compatible
DSCP. The PCN-egress zeroes the ECN field of all PCN packets;
note that this turns off e2e ECN.</t>
</list>The second option is emphatically not recommended, unless
perhaps as a last resort if tunnelling is not possible for some
insurmountable reason.</t>
<t
hangText="c) Traffic that requires PCN admission control where the endpoints ask to see PCN marks:"><vspace
blankLines="0" />Note that this scheme is currently only a tentative
idea.<vspace blankLines="1" />For real-time data generated by an
adaptive codec, schemes have been suggested where PCN marks may be
leaked out of the PCN-domain so that end hosts can drop to a lower
data-rate, thus deferring the need for admission control. Currently
such schemes require further study and the following is for guidance
only.<vspace blankLines="1" />The PCN-ingress-node needs to tunnel
the traffic as in <xref target="pcn3in1_Fig_Tunnel"></xref>, taking
care to comply with <xref target="RFC6040"></xref>. In this case the
PCN-egress does not zero the ECN field contrary to the
recommendation in <xref target="pcn3in1_egress_behaviour"></xref>,
so that the <xref target="RFC6040"></xref> tunnel egress will
preserve any PCN-marking. Note that a PCN-interior-node may change
the ECN-field from 10 to 01 (NM to ThM), which would be interpreted
by the e2e ECN as a change from ECT(0) into ECT(1). This would not
be compatible with the (currently experimental) ECN nonce <xref
target="RFC3540"></xref>.</t>
</list></t>
</section>
<section anchor="pcn3in1_app_map_IP_MPLS"
title="Example Mapping between Encoding of PCN-Marks in IP and in MPLS Shim Headers">
<t>This appendix is informative not normative.</t>
<t>The 6 bits of the DS field in the IP header provide for 64
codepoints. When encapsulating IP traffic in MPLS, it is useful to make
the DS field information accessible in the MPLS header. However, the
MPLS shim header has only a 3-bit traffic class (TC) field <xref
target="RFC5462"></xref> providing for 8 codepoints. The operator has
the freedom to define a site-local mapping of the 64 codepoints of the
DS field onto the 8 codepoints in the TC field.</t>
<t><xref target="RFC5129"></xref> describes how ECN markings in the IP
header can also be mapped to codepoints in the MPLS TC field. Appendix A
of <xref target="RFC5129"></xref> gives an informative description of
how to support PCN in MPLS by extending the way MPLS supports ECN. <xref
target="RFC5129"></xref> was written while PCN specifications were in
early draft stages. The following provides a clearer example of a
mapping between PCN in IP and in MPLS using the PCN terminology and
concepts that have since been specified.</t>
<t>To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n')
needs codepoints to be provided in the TC field for all the PCN-marks
used. That means, when for instance only excess-traffic-marking is used
for PCN purposes, the operator needs to define a site-local mapping to
two codepoints in the MPLS TC field for IP headers with: <list
style="symbols">
<t>DSCP n and NM</t>
<t>DSCP n and ETM</t>
</list> If both excess-traffic-marking and threshold-marking are used,
the operator needs to define a site-local mapping to codepoints in the
MPLS TC field for IP headers with all three of the 3-in-1 codepoints:
<list style="symbols">
<t>DSCP n and NM</t>
<t>DSCP n and ThM</t>
<t>DSCP n and ETM</t>
</list></t>
<t>In either case, if the operator wishes to support the same Diffserv
PHB but without PCN marking, it will also be necessary to define a
site-local mapping to an MPLS TC codepoint for IP headers marked with:
<list style="symbols">
<t>DSCP n and Not-PCN</t>
</list></t>
<t>The above sets of codepoints are required for every PCN-compatible
DSCP. Clearly, given so few TC codepoints are available, it may be
necessary to compromise by merging together some capabilities.
Guidelines for conserving TC codepoints by allowing
non-admission-controlled-traffic to compete with PCN-traffic are given
in Appendix B.1 of <xref target="RFC5670"></xref>.</t>
</section>
<section anchor="pcn3in1_app_rationale_diff_sm"
title="Rationale for Difference Between the Schemes using One PCN-Marking">
<t>Readers may notice a difference between the two behaviours in <xref
target="pcn3in1_interior_ETM_only"></xref> and <xref
target="pcn3in1_interior_ThM_only"></xref>. With only
Excess-traffic-marking enabled, an unexpected ThM packet can be
re-marked to ETM. However, with only Threshold-marking, an unexpected
ETM packet cannot be re-marked to ThM.</t>
<t>This apparent inconsistency is deliberate. The behaviour with only
Threshold-marking keeps to the rule of <xref
target="pcn3in1_common_interior_behaviour"></xref> that ETM is more
severe and must never be changed to ThM even though ETM is not a valid
marking in this case. Otherwise implementations would have to allow
operators to configure an exception to this rule, which would not be
safe practice and would require different code in the data-plane
compared to the common behaviour.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:30:11 |