Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)
obsoletes
- rfc-5696 — Baseline Encoding and Transport of Pre-Congestion Information
Extracted elements (25)
A fourth codepoint (not-PCN = '00') is required because a DSCP is shared between PCN and non-PCN traffic; nodes need a way to identify packets carrying a PCN-compatible DSCP that are not subject to PCN metering and marking, without ambiguity with the NM state.
No single globally defined DSCP was reserved for PCN because PCN applies to multiple traffic classes, Standards Track DSCPs are scarce, and PCN is a marking behaviour (like ECN) rather than a scheduling behaviour; operators select appropriate existing admission-controlled DSCPs such as EF, CS4, CS3, AF4, or VOICE-ADMIT.
The codepoint '11' (CE) was assigned to ETM (the most severe PCN state) because legacy pre-RFC6040 tunnels always propagated '11' correctly but did not reliably propagate '01'. This makes ETM a fail-safe signal even if a misconfigured legacy tunnel suppresses ThM ('01') marks.
When only Threshold-marking is active, an unexpected ETM packet is not re-marked to ThM even though ETM is invalid in that configuration. This preserves the global invariant that ETM is more severe and MUST never be downgraded, avoiding the need for a data-plane code path exception and reducing misconfiguration risk.
MPLS shim headers provide only a 3-bit Traffic Class field (8 codepoints), so a site-local mapping from PCN IP codepoints to MPLS TC codepoints must be defined by the operator; when both marking behaviours are used, at least three TC codepoints per PCN-compatible DSCP are required, plus one for not-PCN.
The 3-in-1 encoding redefines the experimental '01' codepoint from RFC 5696 as the ThM state, obsoleting RFC 5696. Implementations configured to use the RFC 5696 threshold-marking to write the ETM codepoint would be misconfigured under this encoding, though no known deployment of that variant existed.
The encoding is compatible with BCP 124 (RFC 4774) for alternate ECN semantics: it designates PCN-compatible DSCPs as no longer supporting default ECN semantics within the PCN-domain. Ingress and egress nodes prevent unintended ECN mark leakage into or out of the domain.
A PCN-egress-node SHOULD set the not-PCN ('00') codepoint on all packets it forwards out of the PCN-domain, preventing leakage of PCN or ECN marks. An exception is allowed only if the egress is certain that exposing other codepoints complies with RFC 4774.
A PCN-ingress-node MUST police packets that carry a PCN-compatible DSCP, are not classified as PCN-packets, and have an ECN field codepoint other than Not-ECT, by re-marking the DSCP to a non-PCN-compatible value, tunnelling with a non-PCN DSCP, or dropping. In the absence of operator-specific configuration, an implementation SHOULD re-mark the DSCP to zero.
Any tunnel endpoint implementation on a PCN-node MUST comply with RFC 6040. Since PCN is a new capability, full RFC 6040 compliance is considered a reasonable baseline requirement for any deployment.
At the PCN-ingress, if a packet classified as a PCN-packet arrives with the ECN field set to a value other than Not-ECT (i.e., it is ECN-capable), it MUST pass through one of four preparatory steps before PCN-policing and PCN-colouring; the RECOMMENDED policy is encapsulation using an RFC 6040 IP-in-IP tunnel.
If any pre-RFC6040 tunnel decapsulator exists within a PCN-domain, every PCN-node in that domain MUST be configured so that it never sets the ThM codepoint; PCN-interior-nodes MUST solely use the Excess-traffic-marking function.
If no encapsulation is used for ECN-capable PCN-packets, the PCN-ingress-node MUST drop CE-marked packets to avoid congestion collapse, because there is no mechanism to propagate CE markings across the PCN-domain without a tunnel.
PCN-nodes MUST interpret the ECN field of a PCN-packet using the 3-in-1 PCN encoding rather than RFC 3168. Nodes outside a PCN-domain and packets with non-PCN-compatible DSCPs continue to use RFC 3168 semantics.
The PCN-ingress-node MUST set a PCN-compatible DSCP on all PCN-packets and MUST set the PCN codepoint of all PCN-packets to not-marked (NM) during PCN-colouring.
When only excess-traffic-marking is used (e.g., Single Marking edge behaviour), the threshold-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking. Unexpected ThM packets MUST be re-marked to ETM.
When only threshold-marking is used, the excess-traffic-meter SHOULD be disabled and MUST NOT trigger any packet marking; ETM packets MUST NOT be changed to any other codepoint, preserving the rule that ETM is always the most severe marking.
When the 3-in-1 encoding is used with only one marking behaviour, the unused marking codepoint MUST NOT be used anywhere in the PCN-domain, ensuring the encoding remains unambiguous.
When using two PCN-markings, if the excess-traffic-meter indicates a need to mark, the PCN-interior-node MUST change NM to ETM and MUST change ThM to ETM. If both meters indicate a need to mark, the Excess-traffic-marking rules MUST take precedence.
With one exception for domains using only excess-traffic-marking, any IP-in-IP or IPsec tunnel endpoints within a PCN-domain MUST comply with the ECN encapsulation and decapsulation rules of RFC 6040.
A PCN-compatible Diffserv codepoint is a DSCP configured on PCN-nodes to indicate that the ECN field carries PCN-markings rather than RFC 3168 markings. Outside the PCN-domain, the same DSCP has no PCN-specific meaning; suitable DSCPs include those for Telephony (EF), Real-time interactive (CS4), Broadcast Video (CS3), Multimedia Conferencing (AF4), and VOICE-ADMIT.
Injection of spurious PCN-marks into the PCN-domain is a potential attack vector, but can only succeed if a PCN-ingress-node is misconfigured. The effect is to admit fewer flows or terminate existing flows prematurely, causing visible under-utilisation that good management should quickly detect.
PCN-marking is meaningful only within a PCN-domain assumed to be under the control of a single operator or mutually trusting operators. Future inter-domain PCN extensions must address the lack of trust between domains, but that is out of scope for this document.
PCN-interior-node codepoint transition rules: NM may be upgraded to ThM (threshold-marking trigger) or ETM (excess-traffic trigger); ThM may be upgraded to ETM (excess-traffic trigger); ETM MUST NOT be changed to any other codepoint; NM MUST NOT be changed to not-PCN; not-PCN MUST NOT be changed to any other codepoint. Excess-traffic-marking rules take precedence when both meters fire simultaneously.
The 3-in-1 PCN encoding maps four states onto the ECN field of an IP header bearing a PCN-compatible DSCP: '00' (Not-ECT) = not-PCN, '10' (ECT(0)) = NM (not-marked), '01' (ECT(1)) = ThM (threshold-marked), '11' (CE) = ETM (excess-traffic-marked). This reuses all four ECN codepoints within a PCN-domain.