Baseline Encoding and Transport of Pre-Congestion Information
obsoleted by
- rfc-6660 — Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)
Extracted elements (22)
A not-PCN state (00) is provided so that non-PCN traffic can share a PCN-compatible DSCP; since PCN redefines the ECN field meaning for that DSCP, operators still need a way to distinguish non-PCN-capable packets.
ECT(0) was chosen as the Not-marked codepoint over ECT(1) for conceptual consistency with RFC 3168, and because ECT(1) (the nonce, RFC 3540) has seen little deployment, making ECT(1) leakage into the PCN-domain less likely and thus safer to reserve for EXP.
PCN-marking must use the 11 (CE) codepoint because it is the only ECN codepoint guaranteed to be copied into the forwarded inner header upon decapsulation from an IP-in-IP or IPsec tunnel. This was the tightest constraint on the encoding choice.
The PCN working group chose not to define a single DSCP for PCN because the mechanism applies to multiple traffic classes, Standards Track DSCPs are scarce, and PCN is a marking behavior (like ECN) rather than a scheduling behavior.
If a packet marked CE (11) by end-to-end ECN enters the PCN-domain, the PCN-egress-node's reset of the ECN field to 00 violates RFC 3168's rule that CE marks must never be lost except via packet drop. Mitigations include tunneling, extended encoding, explicit signaling, or re-marking to a local DSCP.
The baseline encoding cannot simultaneously support both end-to-end ECN marking and PCN marking within a PCN-domain. Supporting both requires either IP-in-IP tunneling to carry e2e ECN in the inner header, or a richer experimental encoding scheme.
A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all packets it forwards out of the PCN-domain, unless it is certain that revealing other codepoints outside the domain will not contravene RFC 4774 guidance.
A PCN-ingress-node MUST set the Not-marked (10) codepoint on any arriving packet belonging to a PCN-flow, and MUST set the not-PCN (00) codepoint on all other packets sharing a PCN-compatible DSCP.
Any experimental encoding scheme MUST include details of all valid and invalid codepoint transitions at any PCN-nodes.
Any packet arriving at the PCN-ingress-node that shares a PCN-compatible DSCP but is not a PCN-packet MUST be marked as not-PCN (codepoint 00) within the PCN-domain.
Equipment complying with the baseline PCN encoding MUST allow PCN to be enabled for certain Diffserv codepoints (PCN-compatible DSCPs).
Experimental encoding schemes MUST interpret the 00 codepoint as not-PCN and MUST NOT change it; the 11 codepoint MUST indicate PCN-marking by one or both meters; once set to 11, it MUST NOT be changed to any other codepoint.
If a marking algorithm indicates the need to mark a PCN-packet, that packet MUST have its PCN codepoint set to 11 (PCN-marked).
If a packet arrives at the PCN-ingress-node with its ECN field already set to a value other than not-ECT, appropriate action MUST be taken to meet the requirements of RFC 3168. The simplest action is to drop such packets.
If both the 01 and 11 codepoints indicate PCN-marked in an experimental scheme, the 11 codepoint MUST be taken as the more severe marking, and the choice of which meter sets which mark MUST be defined.
PCN-nodes implementing only the baseline encoding MUST be able to PCN-mark packets that arrive with the EXP (01) codepoint, to ease incremental deployment alongside experimental nodes.
PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are already defined for use with admission-controlled traffic.
The PCN-compatible Diffserv codepoint is a DSCP for which the ECN field carries PCN markings instead of RFC 3168 ECN markings. Enabling PCN for a DSCP replaces the default ECN marking behavior with PCN metering and marking per RFC 5670.
Injection of spurious PCN-marks into the domain can only occur via a misconfigured PCN-ingress-node. The effect is admission of fewer flows or premature termination of flows; rapid utilization drops should allow operators to detect the misconfiguration quickly.
PCN-marking carries meaning only within the PCN-domain, which is assumed to be entirely under control of a single trusted operator or a set of mutually trusting operators. Inter-domain PCN extensions cannot assume such trust and must address security separately.
Valid codepoint transitions at PCN-interior-nodes are: not-PCN→not-PCN, NM→NM, NM→PM, EXP→EXP, EXP→PM, PM→PM. All other transitions (e.g., NM→not-PCN, PM→NM) are invalid. EXP→PM MAY trigger a management alarm.
PCN encoding is expressed as a combination of a PCN-compatible DSCP and the 2-bit ECN field in the IP header. The four ECN codepoints map to: not-PCN (00), Not-marked/NM (10), Experimental/EXP (01), and PCN-marked/PM (11).