summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6660.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6660.txt')
-rw-r--r--doc/rfc/rfc6660.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6660.txt b/doc/rfc/rfc6660.txt
new file mode 100644
index 0000000..1bea4d4
--- /dev/null
+++ b/doc/rfc/rfc6660.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Briscoe
+Request for Comments: 6660 BT
+Obsoletes: 5696 T. Moncaster
+Category: Standards Track University of Cambridge
+ISSN: 2070-1721 M. Menth
+ University of Tuebingen
+ July 2012
+
+
+ Encoding Three Pre-Congestion Notification (PCN) States
+ in the IP Header Using a Single Diffserv Codepoint (DSCP)
+
+Abstract
+
+ 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 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 that then decide whether to admit
+ or block new flow requests or to terminate some already admitted
+ flows during serious pre-congestion.
+
+ This document specifies how PCN-marks are to be encoded into the IP
+ header by reusing 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 Diffserv codepoint (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
+ RFC 5696.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6660.
+
+
+
+
+Briscoe, et al. Standards Track [Page 1]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
+ 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4
+ 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 5
+ 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 6
+ 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 7
+ 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 7
+ 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 7
+ 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 8
+ 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
+ Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1. PCN-Ingress-Node Behaviour . . . . . . . . . . . . . . . . 8
+ 5.2. PCN-Interior-Node Behaviour . . . . . . . . . . . . . . . 11
+ 5.2.1. Behaviour Common to All PCN-Interior-Nodes . . . . . . 11
+ 5.2.2. Behaviour of PCN-Interior-Nodes Using Two
+ PCN-Markings . . . . . . . . . . . . . . . . . . . . . 11
+ 5.2.3. Behaviour of PCN-Interior-Nodes Using One
+ PCN-Marking . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3. PCN-Egress-Node Behaviour . . . . . . . . . . . . . . . . 13
+ 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13
+ 6.2. Backward Compatibility with the Encoding in RFC 5696 . . . 14
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
+ Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18
+ Appendix B. Coexistence of ECN and PCN . . . . . . . . . . . . . 19
+
+
+
+Briscoe, et al. Standards Track [Page 2]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ Appendix C. Example Mapping between Encoding of PCN-Marks in
+ IP and in MPLS Shim Headers . . . . . . . . . . . . . 22
+ Appendix D. Rationale for Difference between the Schemes
+ Using One PCN-Marking . . . . . . . . . . . . . . . . 23
+
+1. Introduction
+
+ The objective of Pre-Congestion Notification (PCN) [RFC5559] is to
+ protect the quality of service (QoS) of inelastic flows within a
+ Diffserv domain in a simple, scalable, and robust fashion. Two
+ mechanisms are used: admission control, 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").
+
+ [RFC5670] 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 [RFC5559]. Egress nodes
+ monitor the PCN-marks of received PCN-packets and pass information
+ about these PCN-marks to Decision Points that then decide whether to
+ admit new flows or terminate existing flows [RFC6661] [RFC6662].
+
+ The encoding defined in [RFC5696] 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 [RFC6662]. However, PCN-domains utilising the controlled
+ load edge behaviour [RFC6661] require three PCN marking states. This
+ document extends the encoding that originally appeared in RFC 5696 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 [RFC5696] encoding, which provides only a subset of the
+ same capabilities.
+
+ 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 [RFC6040]. There is one limited exception to this constraint
+
+
+
+Briscoe, et al. Standards Track [Page 3]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ where the PCN-domain only uses the excess-traffic-marking behaviour
+ and where the threshold-marking behaviour is deactivated. This is
+ discussed in Section 5.2.3.1.
+
+ 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. Appendix C discusses a possible
+ mapping between IP and MPLS.
+
+1.1. Requirements Language
+
+ 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 [RFC2119].
+
+2. Definitions and Abbreviations
+
+2.1. Terminology
+
+ 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 [RFC5559]. The following
+ additional terms are defined in this document:
+
+ PCN encoding: mapping of PCN marking states to specific codepoints
+ in the packet header.
+
+ PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating
+ packets for which the ECN field carries PCN-markings rather than
+ [RFC3168] 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.
+
+ 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 [RFC5670]. Abbreviated to ThM codepoint.
+
+ 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 [RFC5670].
+ Abbreviated to ETM codepoint.
+
+ Not-marked codepoint: a codepoint that indicates PCN-packets that
+ are not PCN-marked. Abbreviated to NM codepoint.
+
+
+
+
+Briscoe, et al. Standards Track [Page 4]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ Not-PCN codepoint: a codepoint that indicates packets that are not
+ PCN-packets.
+
+2.2. List of Abbreviations
+
+ The following abbreviations are used in this document:
+
+ o AF = Assured Forwarding [RFC2597]
+
+ o CE = Congestion Experienced [RFC3168]
+
+ o CS = Class Selector [RFC2474]
+
+ o DSCP = Diffserv codepoint
+
+ o e2e = end-to-end
+
+ o ECN = Explicit Congestion Notification [RFC3168]
+
+ o ECT = ECN Capable Transport [RFC3168]
+
+ o EF = Expedited Forwarding [RFC3246]
+
+ o ETM = excess-traffic-marked
+
+ o EXP = Experimental
+
+ o NM = not-marked
+
+ o PCN = Pre-Congestion Notification
+
+ o PHB = Per-hop behaviour [RFC2474]
+
+ o ThM = threshold-marked
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 5]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+3. Definition of 3-in-1 PCN Encoding
+
+ 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 Figure 1.
+
+ +--------+----------------------------------------------------+
+ | | 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 |
+ +--------+--------------+-------------+-------------+---------+
+
+ Figure 1: 3-in-1 PCN Encoding
+
+ A PCN-node will be configured to recognise certain DSCPs as PCN-
+ compatible. Appendix A discusses the choice of suitable DSCPs. In
+ Figure 1, '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
+ [RFC5559].
+
+ PCN-nodes MUST interpret the ECN field of a PCN-packet using the
+ 3-in-1 PCN encoding, rather than [RFC3168]. 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 [RFC3168].
+
+ When using the 3-in-1 encoding, the codepoints of the ECN field have
+ the following meanings:
+
+ 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.
+
+ NM: not-marked. Indicates a PCN-packet that has not yet been marked
+ by any PCN marker.
+
+ ThM: threshold-marked. Indicates a PCN-packet that has been marked
+ by a threshold-marker [RFC5670].
+
+ ETM: excess-traffic-marked. Indicates a PCN-packet that has been
+ marked by an excess-traffic-marker [RFC5670].
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 6]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+4. Requirements for and Applicability of 3-in-1 PCN Encoding
+
+4.1. PCN Requirements
+
+ In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes
+ control packets entering a PCN-domain. Packets belonging to PCN-
+ controlled flows are subject to PCN-metering and PCN-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 [RFC5670]. Some edge
+ behaviours require only a Single Marking behaviour [RFC6662], others
+ require both [RFC6661]. 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 [RFC5670]. 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).
+
+ In all current PCN edge behaviours that use two marking behaviours
+ [RFC5559] [RFC6661], 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.
+
+4.2. Requirements Imposed by Tunnelling
+
+ [RFC6040] defines rules for the encapsulation and decapsulation of
+ ECN markings within IP-in-IP tunnels. The publication of RFC 6040
+ removed the tunnelling constraints that existed when the encoding of
+ [RFC5696] was written (see Section 3.3.2 of [RFC6627]).
+
+ 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 Section 4.3 below are designed to avoid
+ this problem.
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 7]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ 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.
+
+4.3. Applicable Environments for the 3-in-1 PCN Encoding
+
+ 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
+ Section 5.2.3).
+
+ 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 [RFC6040] (see
+ Section 4.2).
+
+ 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 Section 5.2.3.1. In
+ all other situations where legacy tunnel decapsulators might be
+ present within the PCN-domain, the 3-in-1 encoding is not applicable.
+
+5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding
+
+ Any tunnel endpoint implementation on a PCN-node MUST comply with
+ [RFC6040]. Since PCN is a new capability, this is considered a
+ reasonable requirement.
+
+5.1. PCN-Ingress-Node Behaviour
+
+ If packets arrive from another Diffserv domain, any re-mapping of
+ Diffserv codepoints MUST happen before PCN-ingress processing.
+
+ At each logical ingress link into a PCN-domain, each PCN-ingress-node
+ will apply the four functions described in Section 4.2 of [RFC5559]
+ to arriving packets. These functions are applied in the following
+ order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter. This
+
+
+
+Briscoe, et al. Standards Track [Page 8]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ section describes these four steps, but only the aspects relevant to
+ packet encoding:
+
+ 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.
+
+ 1b. Extra step if ECN and PCN coexist: 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 [RFC4774] 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:
+
+ * Encapsulate ECN-capable PCN-packets across the PCN-domain:
+
+ + either within another IP header using an RFC6040 tunnel;
+
+ + or within a lower-layer protocol capable of being PCN-
+ marked, such as MPLS (see Appendix C).
+
+ 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.
+
+ 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 Appendix B and
+ specifically Figure 2).
+
+ If MPLS encapsulation is used, note that penultimate hop
+ popping [RFC3031] is incompatible with PCN, unless the
+ penultimate hop applies the PCN-egress-node behaviour before it
+ pops the PCN-capable MPLS label.
+
+ * 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-marked packets would risk congestion
+ collapse, because without encapsulation there is no mechanism
+ to propagate the CE markings across the PCN-domain (see
+ Appendix B).
+
+ 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.
+
+
+
+
+Briscoe, et al. Standards Track [Page 9]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ * Drop the packet.
+
+ This policy is also NOT RECOMMENDED, because it precludes the
+ possibility that e2e ECN can coexist with PCN as a means of
+ controlling congestion.
+
+ * Any other action that complies with [RFC4774] (see Appendix B
+ for an example).
+
+ Appendix B provides more information about the coexistence of PCN
+ and ECN.
+
+ 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., [RFC6662] or [RFC6661].
+
+ 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:
+
+ a) it is not classified as a PCN-packet;
+
+ b) it already carries a PCN-compatible DSCP; and
+
+ c) its ECN field carries a codepoint other than Not-ECT.
+
+ The PCN-ingress-node MUST police packets that meet all three
+ conditions (a-c) by subjecting them to one of the following
+ treatments:
+
+ * re-mark the DSCP to a DSCP that is not PCN-compatible;
+
+ * tunnel the packet to the PCN-egress-node with a DSCP in the
+ outer header that is not PCN-compatible; or
+
+ * drop the packet (NOT RECOMMENDED -- see below).
+
+ The choice between these actions depends on local policy. In the
+ absence of any operator-specific configuration for this case, an
+ implementation SHOULD re-mark the DSCP to zero (000000) by
+ default.
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 10]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ 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.
+
+ 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.
+
+ 3. PCN-colouring: If a packet has been classified as a PCN-packet,
+ once it has been policed, the PCN-ingress-node:
+
+ * MUST set a PCN-compatible Diffserv codepoint on all PCN-
+ packets. To conserve DSCPs, DSCPs SHOULD be chosen that are
+ already defined for use with admission-controlled traffic.
+ Appendix A gives guidance to implementors on suitable DSCPs.
+
+ * MUST set the PCN codepoint of all PCN-packets to not-marked
+ (NM).
+
+ 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.
+
+5.2. PCN-Interior-Node Behaviour
+
+5.2.1. Behaviour Common to All PCN-Interior-Nodes
+
+ Interior nodes MUST NOT change not-PCN to any other codepoint.
+
+ Interior nodes MUST NOT change NM to not-PCN.
+
+ Interior nodes MUST NOT change ThM to NM or not-PCN.
+
+ Interior nodes MUST NOT change ETM to any other codepoint.
+
+5.2.2. Behaviour of PCN-Interior-Nodes Using Two PCN-Markings
+
+ If the threshold-meter function indicates a need to mark a packet,
+ the PCN-interior-node MUST change NM to ThM.
+
+
+
+
+Briscoe, et al. Standards Track [Page 11]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ If the excess-traffic-meter function indicates a need to mark a
+ packet:
+
+ o the PCN-interior-node MUST change NM to ETM;
+
+ o the PCN-interior-node MUST change ThM to ETM.
+
+ 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.
+
+5.2.3. Behaviour of PCN-Interior-Nodes Using One PCN-Marking
+
+ Some PCN edge behaviours require only one PCN-marking within the PCN-
+ domain. The Single Marking edge behaviour [RFC6662] requires PCN-
+ interior-nodes to mark packets using the excess-traffic-meter
+ function [RFC5670]. It is possible that future schemes may require
+ only the threshold-meter function. Appendix D explains the rationale
+ for the behaviours defined in this section.
+
+5.2.3.1. Marking Using Only the Excess-Traffic-Meter Function
+
+ The threshold-traffic-meter function SHOULD be disabled and MUST NOT
+ trigger any packet marking.
+
+ The PCN-interior-node SHOULD raise a management alarm if it receives
+ a ThM packet, but the frequency of such alarms SHOULD be limited.
+
+ If the excess-traffic-meter function indicates a need to mark the
+ packet:
+
+ o the PCN-interior-node MUST change NM to ETM;
+
+ o the PCN-interior-node MUST change ThM to ETM. It SHOULD also
+ raise an alarm as above.
+
+5.2.3.2. Marking Using Only the Threshold-Meter Function
+
+ The excess-traffic-meter function SHOULD be disabled and MUST NOT
+ trigger any packet marking.
+
+ The PCN-interior-node SHOULD raise a management alarm if it receives
+ an ETM packet, but the frequency of such alarms SHOULD be limited.
+
+ If the threshold-meter function indicates a need to mark the packet:
+
+ o the PCN-interior-node MUST change NM to ThM;
+
+
+
+
+Briscoe, et al. Standards Track [Page 12]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ o 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.
+
+5.3. PCN-Egress-Node Behaviour
+
+ A PCN-egress-node SHOULD set the not-PCN ('00') codepoint on all
+ packets it forwards out of the PCN-domain.
+
+ 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 [RFC4774]. 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.
+ Appendix B gives details of how such schemes might work, but such
+ schemes are currently only tentative ideas.
+
+ If the PCN-domain is configured to use only Excess-traffic-marking,
+ the PCN-egress-node MUST treat ThM as ETM; 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.
+
+6. Backward Compatibility
+
+6.1. Backward Compatibility with ECN
+
+ BCP 124 [RFC4774] 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 coexistence 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.
+
+ 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 Appendix B 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 Section 5.1
+ requires one of these methods to be configured at the PCN-ingress-
+ node and recommends that implementations offer tunnelling as the
+ default.
+
+ 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.
+
+
+
+Briscoe, et al. Standards Track [Page 13]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ 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.
+
+6.2. Backward Compatibility with the Encoding in RFC 5696
+
+ Section 5.1 of the PCN architecture [RFC5559] gives general guidance
+ on fault detection and diagnosis, 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 [RFC5696], misconfiguration mistakes may be
+ more likely. Therefore, extra monitoring, such as in the following
+ example, may be necessary to detect and diagnose potential problems:
+
+ 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).
+
+ A PCN-node implemented to use the obsoleted encoding in RFC 5696
+ 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 RFC 5696 and no reason to believe that
+ such an implementation would ever have been built. Therefore, it
+ seems safe to ignore this issue.
+
+7. Security Considerations
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 14]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ 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; however, 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.
+
+8. Conclusions
+
+ 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 [RFC6040].
+
+9. Acknowledgements
+
+ 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.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+ "Definition of the Differentiated Services Field (DS
+ Field) in the IPv4 and IPv6 Headers", RFC 2474,
+ December 1998.
+
+ [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+ of Explicit Congestion Notification (ECN) to IP",
+ RFC 3168, September 2001.
+
+ [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
+ Architecture", RFC 5559, June 2009.
+
+ [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
+ Nodes", RFC 5670, November 2009.
+
+
+
+
+Briscoe, et al. Standards Track [Page 15]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
+ Notification", RFC 6040, November 2010.
+
+10.2. Informative References
+
+ [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+ "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+ Label Switching Architecture", RFC 3031, January 2001.
+
+ [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
+ J., Courtney, W., Davari, S., Firoiu, V., and D.
+ Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+ Behavior)", RFC 3246, March 2002.
+
+ [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
+ Congestion Notification (ECN) Signaling with Nonces",
+ RFC 3540, June 2003.
+
+ [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
+ Guidelines for DiffServ Service Classes", RFC 4594,
+ August 2006.
+
+ [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
+ Explicit Congestion Notification (ECN) Field", BCP 124,
+ RFC 4774, November 2006.
+
+ [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
+ Diffserv Service Classes", RFC 5127, February 2008.
+
+ [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
+ Marking in MPLS", RFC 5129, January 2008.
+
+ [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
+ (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+ Class" Field", RFC 5462, February 2009.
+
+ [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
+ Encoding and Transport of Pre-Congestion Information",
+ RFC 5696, November 2009.
+
+ [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
+ Services Code Point (DSCP) for Capacity-Admitted Traffic",
+ RFC 5865, May 2010.
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 16]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ [RFC6627] Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
+ Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
+ Notification Encoding", RFC 6627, July 2012.
+
+ [RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
+ Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-
+ Node Behaviour for the Controlled Load (CL) Mode of
+ Operation", RFC 6661, July 2012.
+
+ [RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T.
+ Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-
+ Node Behaviour for the Single Marking (SM) Mode of
+ Operation", RFC 6662, July 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 17]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+Appendix A. Choice of Suitable DSCPs
+
+ This appendix is informative not normative.
+
+ 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 [RFC5127]. It is suggested that
+ admission control could be used for the following service classes
+ (defined in [RFC4594] unless otherwise stated):
+
+ o Telephony (EF)
+
+ o Real-time interactive (CS4)
+
+ o Broadcast Video (CS3)
+
+ o Multimedia Conferencing (AF4)
+
+ o the VOICE-ADMIT codepoint defined in [RFC5865].
+
+ CS5 is excluded from this list since PCN is not expected to be
+ applied to signalling traffic.
+
+ 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 [RFC5127]). 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
+ [RFC5127].
+
+ Guidelines for conserving DSCPs by allowing non-admission-controlled-
+ traffic to compete with PCN-traffic are given in Appendix B.1 of
+ [RFC5670].
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 18]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ 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.
+
+ 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.
+
+Appendix B. Coexistence of ECN and PCN
+
+ This appendix is informative not normative. It collects together
+ material relevant to coexistence 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.
+
+ ECN [RFC3168] 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 reuses the
+ bits of the ECN field in the IP header. Consequently, this disables
+ ECN within the PCN-domain.
+
+ 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).
+
+ Flow signalling identifies admission-controlled traffic, by
+ associating a filter spec with the need for admission control (e.g.,
+ through RSVP or some equivalent message, such as from a SIP server to
+ the ingress or from a logically centralised network control system).
+ The PCN-ingress-node re-marks admission-controlled traffic matching
+ that filter spec 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 Appendix A).
+
+ 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.
+
+ Unless specified otherwise, for any of the cases in the list below,
+ an IP-in-IP tunnel that complies with [RFC6040] can be used to
+ preserve ECN markings across the PCN-domain. The tunnelling action
+
+
+
+Briscoe, et al. Standards Track [Page 19]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ should be applied wholly outside the PCN-domain as illustrated in
+ Figure 2. Then, by the rules of RFC 6040, the tunnel egress
+ propagates the ECN field from the inner header, because the PCN-
+ egress will have zeroed the outer ECN field.
+
+ . . . . . . PCN-domain . . . . . .
+ . ,---------. ,--------. .
+ . _| PCN- |___________________| PCN- |_ .
+ . / | ingress | | egress | \ .
+ .| `---------' `--------' |.
+ | . . . . . . . . . . . . . . .|
+ ,---------. ,--------.
+ _____| Tunnel | | Tunnel |____
+ | Ingress | - - ECN preserved inside tunnel - - | Egress |
+ `---------' `--------'
+
+ Figure 2: Separation of Tunnelling and PCN Actions
+
+ There are three cases for how e2e ECN traffic may wish to be treated
+ while crossing a PCN-domain:
+
+ a) Traffic that does not require PCN admission control:
+ For example, traffic that does not match flow signalling being
+ used for admission control. In this case, the e2e ECN traffic is
+ not treated as PCN-traffic. There are two possible scenarios:
+
+ * Arriving traffic does not carry a PCN-compatible DSCP: no
+ action required.
+
+ * Arriving traffic carries a DSCP that clashes with a PCN-
+ compatible DSCP. There are two options:
+
+ 1. 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.
+
+ 2. 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.
+
+ 3. The ingress tunnels the traffic, using the original DSCP in
+ the outer header but setting not-PCN in the outer header;
+ note that this turns off ECN for this traffic within the
+ PCN-domain.
+
+ The first or second options are recommended unless the operator
+ is short of local DSCPs.
+
+
+
+
+Briscoe, et al. Standards Track [Page 20]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ b) Traffic that requires admission-control:
+ In this case, the e2e ECN traffic is treated as PCN-traffic across
+ the PCN-domain. There are two options.
+
+ * 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.
+
+ * The PCN-ingress-node drops CE-marked packets and otherwise sets
+ the ECN-field to NM and sets the DSCP to a PCN-compatible DSCP.
+ The PCN-egress zeroes the ECN field of all PCN packets; note
+ that this turns off e2e ECN.
+
+ The second option is emphatically not recommended, unless perhaps
+ as a last resort if tunnelling is not possible for some
+ insurmountable reason.
+
+ c) Traffic that requires PCN admission control where the endpoints
+ ask to see PCN marks:
+ Note that this scheme is currently only a tentative idea.
+
+ 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.
+
+ The PCN-ingress-node needs to tunnel the traffic as in Figure 2,
+ taking care to comply with [RFC6040]. In this case, the PCN-
+ egress does not zero the ECN field (contrary to the recommendation
+ in Section 5.3), so that the [RFC6040] 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 [RFC3540].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 21]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in
+ MPLS Shim Headers
+
+ This appendix is informative not normative.
+
+ 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 [RFC5462] 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.
+
+ [RFC5129] describes how ECN markings in the IP header can also be
+ mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129]
+ gives an informative description of how to support PCN in MPLS by
+ extending the way MPLS supports ECN. [RFC5129] 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.
+
+ 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:
+
+ o DSCP n and NM
+
+ o DSCP n and ETM
+
+ 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:
+
+ o DSCP n and NM
+
+ o DSCP n and ThM
+
+ o DSCP n and ETM
+
+ 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:
+
+ o DSCP n and not-PCN
+
+
+
+
+Briscoe, et al. Standards Track [Page 22]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+ 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 [RFC5670].
+
+Appendix D. Rationale for Difference between the Schemes Using One
+ PCN-Marking
+
+ Readers may notice a difference between the two behaviours in
+ Sections 5.2.3.1 and 5.2.3.2. 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.
+
+ This apparent inconsistency is deliberate. The behaviour with only
+ Threshold-marking keeps to the rule of Section 5.2.1 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 23]
+
+RFC 6660 3-in-1 PCN Encoding July 2012
+
+
+Authors' Addresses
+
+ Bob Briscoe
+ BT
+ B54/77, Adastral Park
+ Martlesham Heath
+ Ipswich IP5 3RE
+ UK
+
+ Phone: +44 1473 645196
+ EMail: bob.briscoe@bt.com
+ URI: http://bobbriscoe.net/
+
+
+ Toby Moncaster
+ University of Cambridge Computer Laboratory
+ William Gates Building, J J Thomson Avenue
+ Cambridge CB3 0FD
+ UK
+
+ EMail: toby.moncaster@cl.cam.ac.uk
+
+
+ Michael Menth
+ University of Tuebingen
+ Sand 13
+ 72076 Tuebingen
+ Germany
+
+ Phone: +49-7071-2970505
+ EMail: menth@uni-tuebingen.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe, et al. Standards Track [Page 24]
+