--- 1/draft-ietf-pcn-3-in-1-encoding-08.txt 2012-03-12 02:13:59.602672868 +0100 +++ 2/draft-ietf-pcn-3-in-1-encoding-09.txt 2012-03-12 02:13:59.650721516 +0100 @@ -1,113 +1,114 @@ Congestion and Pre-Congestion B. Briscoe Notification BT Internet-Draft T. Moncaster Obsoletes: 5696 (if approved) Moncaster Internet Consulting Intended status: Standards Track M. Menth -Expires: February 19, 2012 University of Tuebingen - August 18, 2011 +Expires: September 12, 2012 University of Tuebingen + March 11, 2012 Encoding 3 PCN-States in the IP header using a single DSCP - draft-ietf-pcn-3-in-1-encoding-08 + draft-ietf-pcn-3-in-1-encoding-09 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 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. 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. This encoding 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. + 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - - This Internet-Draft will expire on February 19, 2012. + This Internet-Draft will expire on September 12, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Changes in This Version (to be removed by RFC Editor) . . 5 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 - 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8 - 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9 - 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9 + 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 + 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 + 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 10 - 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10 + 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 - 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11 - 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 + 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 + 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 5.2.2. Behaviour of PCN-interior Nodes Using Two - PCN-markings . . . . . . . . . . . . . . . . . . . . . 12 + PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 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 RFC5696 Encoding . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18 - Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 19 + PCN-marking . . . . . . . . . . . . . . . . . . . . . 14 + 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 15 + 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 16 + 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 20 + Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 21 Appendix C. Example Mapping between Encoding of PCN-Marks in - IP and in MPLS Shim Headers . . . . . . . . . . . . . 21 + IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 Appendix D. Rationale for Difference Between the Schemes - using One PCN-Marking . . . . . . . . . . . . . . . . 22 + using One PCN-Marking . . . . . . . . . . . . . . . . 25 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, @@ -132,47 +133,68 @@ 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 [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains utilising the controlled load edge behaviour [I-D.ietf-pcn-cl-edge-behaviour] 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, - still using a single Diffserv codepoint. This encoding scheme is + 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 sub-set of the same capabilities. - The full version of this 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 where - the PCN-domain only uses the excess-traffic-marking behaviour and - where the threshold-marking behaviour is deactivated. This is + 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 + 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]. 1.2. Changes in This Version (to be removed by RFC Editor) + From draft-ietf-pcn-3-in-1-encoding-08 to -09: + + * Added note about fail-safe to protect other traffic in the + event of tunnel misconfiguration. + + * Changed section heading to be about applicability of + environments to the encoding, rather than the encoding to the + environments. + + * Completely re-wrote PCN-ingress Node Behaviour section. + + * Changed PCN interior node to PCN-node where the term was + intended to include all PCN-nodes. + + * 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. + + * A few clarifying editorial amendments and updated refs. + From draft-ietf-pcn-3-in-1-encoding-07 to -08: Editorial corrections and clarifications. From draft-ietf-pcn-3-in-1-encoding-06 to -07: * 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. * Removed statements about the PCN working group, given RFCs are @@ -283,75 +305,75 @@ metering function [RFC5670]. Abbreviated to ThM. 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. Not-marked codepoint: a codepoint that indicates PCN-packets that are not PCN-marked. Abbreviated to NM. - not-PCN codepoint: a codepoint that indicates packets that are not + 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 IP = Internet protocol - o NM = Not-marked - o PCN = Pre-Congestion Notification o ThM = Threshold-marked 3. Definition of 3-in-1 PCN Encoding - The 3-in-1 PCN encoding scheme allows for two or three PCN-marking - states to be encoded within the IP header. The full encoding is - shown in Figure 1. + 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 | | | +--------------+-------------+-------------+---------+ | | 00 | 10 | 01 | 11 | +--------+--------------+-------------+-------------+---------+ | DSCP n | Not-PCN | NM | ThM | ETM | +--------+--------------+-------------+-------------+---------+ + Figure 1: 3-in-1 PCN Encoding - A PCN-node (i.e. a node within a PCN-domain) 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. Within 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]. + 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: @@ -368,242 +390,339 @@ ETM: Excess-traffic-marked. Indicates a PCN-packet that has been marked by an excess-traffic-marker [RFC5670]. 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 -marking, and PCN- - ingress-nodes mark them as Not-marked (PCN-colouring). Any node in - the PCN-domain may perform PCN-metering and -marking and mark PCN- - packets if needed. There are two different metering and marking - behaviours: threshold-marking and excess-traffic-marking [RFC5670]. - Some edge behaviors require only a single marking behaviour + 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 [I-D.ietf-pcn-sm-edge-behaviour], others require both [I-D.ietf-pcn-cl-edge-behaviour]. 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 + 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). + (the Not-PCN codepoint). - In all current PCN edge behaviors that use two marking behaviours + In all current PCN edge behaviours that use two marking behaviours [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], 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. + 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 RFC6040 removed the tunnelling constraints that existed when the encoding of [RFC5696] was written (see section 3.3.2 of [I-D.ietf-pcn-encoding-comparison]). 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 + 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. + 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. -4.3. Applicability of 3-in-1 PCN Encoding + 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 throughout the PCN-domain (see + 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). - It may not be possible 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 endpoint 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 endpoints might be present within the PCN domain, - the 3-in-1 encoding is not applicable. + 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 - 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. - Appendix A gives guidance to implementors on suitable DSCPs. - Guidelines for mixing traffic types within a PCN-domain are given in - [RFC5670]. + Each ingress link into a PCN domain will apply the four functions + described in section 4.2 of [RFC5559] to arriving packets. These + functions are applied in the following order: classify, police, PCN- + colour, meter. This section describes these four steps, but only the + aspects relevant to packet encoding: - If a packet arrives at the PCN-ingress-node that shares a PCN- - compatible DSCP and is not a PCN-packet, the PCN-ingress-node MUST - mark it as not-PCN. + 1. Packet 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. - If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress-node - MUST change the PCN codepoint to Not-marked. + 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 [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: - If a PCN-packet arrives at the PCN-ingress-node with its ECN field - already set to a value other than not-ECT, then appropriate action - MUST be taken to meet the requirements of [RFC4774]. The simplest - appropriate action is to just drop such packets. However, this is a - drastic action that an operator may feel is undesirable. Appendix B - provides more information and summarises other alternative actions - that might be taken. + * Tunnel ECN-capable PCN-packets across the PCN-domain, using an + RFC6040 tunnel. This tunnelling step MUST precede PCN-policing + and PCN-colouring so that the tunnel is logically outside the + PCN domain (see Appendix B and specifically Figure 2). + + This tunnelling policy is the RECOMMENDED choice, and + implementations SHOULD use it as the default. + + * If tunnelling is not possible, the PCN-ingress-node can allow + through ECN-capable packets without tunnelling, but it MUST + drop CE-marked packets at this stage. Failure to drop CE would + risk congestion collapse, because without a tunnel there is no + mechanism to propagate the CE markings across the PCN-domain + (see Appendix B). + + This policy is emphatically 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. + + * Drop the packet. + + This policy is also emphatically NOT RECOMMENDED, because it + precludes the possibility that e2e ECN can co-exist 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 co-existence 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, but these are specified in the relevant + edge-behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour], + [I-D.ietf-pcn-cl-edge-behaviour]. + + 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 + + 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 with a DSCP in the outer + header that is not PCN-compatible; + + * 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, by + default an implementation SHOULD re-mark the DSCP to zero. + + 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, Diffserv codepoints 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 Not-PCN to any other codepoint. - Interior nodes MUST NOT change NM to not-PCN. + 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 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. + the PCN-interior-node MUST change NM to ThM. 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 NM to ETM; - o the PCN-interior node MUST change ThM 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 - [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark + [I-D.ietf-pcn-sm-edge-behaviour] 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 + 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 NM to ETM; - o the PCN-interior node MUST change ThM to ETM. It SHOULD also + 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 + 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; + o the PCN-interior-node MUST change NM to ThM; - o the PCN-interior node MUST NOT change ETM to any other codepoint. + 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 + 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 codepoints. + 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 and, if only threshold- + 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 instance since this means there is some + 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 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. - On its own, the 3-in-1 encoding cannot support both ECN marking end- - to-end (e2e) and PCN-marking within a PCN-domain. 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. Although - Appendix B recommends various approaches over others, it is merely - informative and all such schemes are beyond the normative scope of - this document. + 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. 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 RFC5696 Encoding - A PCN node implemented to use the obsoleted RFC5696 encoding could + 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 such an - implementation and no reason to believe that such an implementation - would ever have been built. Therefore, it seems safe to ignore this - issue. + 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. 7. IANA Considerations This memo includes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations @@ -635,24 +754,24 @@ 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]. 10. Acknowledgements - Many thanks to Phil Eardley for providing extensive feedback, + Many thanks to Philip Eardley for providing extensive feedback, criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, - Ruediger Geib, Georgios Karaginannis and everyone else who has - commented on the document. + Ruediger Geib, Georgios Karagiannis, Adrian Farrel and everyone else + who has commented on the document. 11. Comments Solicited 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 , and/or to the authors. 12. References @@ -689,38 +808,39 @@ Notification", RFC 6040, November 2010. 12.2. Informative References [I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", draft- - ietf-pcn-cl-edge-behaviour-09 - (work in progress), June 2011. + ietf-pcn-cl-edge-behaviour-12 + (work in progress), + February 2012. [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., Moncaster, T., Menth, M., Eardley, P., and B. Briscoe, "Overview of Pre-Congestion Notification Encoding", draft- - ietf-pcn-encoding-comparison-06 - (work in progress), June 2011. + ietf-pcn-encoding-comparison-09 + (work in progress), March 2012. [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth, M., and T. Taylor, "PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation", draft-ietf-pcn-sm- - edge-behaviour-06 (work in - progress), June 2011. + edge-behaviour-09 (work in + progress), February 2012. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An @@ -805,111 +924,119 @@ 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]. + 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. Co-existence of ECN and PCN - This appendix is informative, not normative. + 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. - 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. Appendix B of [RFC5696] (obsoleted) included advice - on handling ECN traffic within a PCN-domain. This appendix - reiterates and clarifies that advice. + 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 re-uses 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 and non-admission-controlled traffic. - - Admission-controlled traffic will be re-marked to a PCN-compatible - DSCP by the PCN-ingress-node. Two mechanisms can be used to identify - such traffic: - - a. Flow signalling, which associates a filterspec with a need for - admission control (e.g. through RSVP or some equivalent message, - e.g. from a SIP server to the ingress); the PCN-ingress-node re- - marks traffic matching that filterspec to a PCN-compatible DSCP. + traffic (PCN-traffic) and non-admission-controlled traffic (non-PCN- + traffic). - b. Traffic arrives with a DSCP that implies it requires admission - control such as VOICE-ADMIT [RFC5865] or Real-Time Interactive, - Broadcast Video when used for video on demand, and multimedia - conferencing [RFC4594][RFC5865] (see Appendix A). + 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 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. - ECN [RFC3168] is an end-to-end congestion notification mechanism. As - such it is possible that some traffic entering the PCN-domain may - also be ECN capable. - Unless specified otherwise, for any of the cases in the list below, - an IP-in-IP tunnel 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 the following figure: + an IP-in-IP tunnel that complies with[RFC6040] 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 + Figure 2. 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. , . . . . . 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 admission control: + a) Traffic that does not require PCN admission control: 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: * 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 not-PCN in the - outer header; note that this turns off ECN for this traffic - within the PCN domain. + 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. - The first option is recommended unless the operator is short of - local DSCPs. + 3. 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. + + The first or second options are recommended unless the operator + is short of local DSCPs. 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 @@ -907,43 +1034,42 @@ 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 DCSP 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 admission control where the endpoints ask to - see PCN marks: + 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 + 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- + 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]. 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 @@ -985,36 +1110,39 @@ 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 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 - Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic + Section 5.2.3.1 and Section 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 + 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 + not be safe practice and would require different code in the data- plane compared to the common behaviour. Authors' Addresses Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK