--- 1/draft-ietf-pcn-3-in-1-encoding-10.txt 2012-04-20 14:13:57.771087361 +0200 +++ 2/draft-ietf-pcn-3-in-1-encoding-11.txt 2012-04-20 14:13:57.827087437 +0200 @@ -1,21 +1,21 @@ 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: September 21, 2012 University of Tuebingen - March 20, 2012 +Expires: October 19, 2012 University of Tuebingen + April 17, 2012 Encoding 3 PCN-States in the IP header using a single DSCP - draft-ietf-pcn-3-in-1-encoding-10 + draft-ietf-pcn-3-in-1-encoding-11 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 @@ -38,21 +38,21 @@ 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 September 21, 2012. + This Internet-Draft will expire on October 19, 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 @@ -62,53 +62,53 @@ 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 . . . . . . . . . . . . . . . . 8 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 + 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 11 - 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 + 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 12 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 12 - 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 - 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 + 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 15 + 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 15 5.2.2. Behaviour of PCN-interior Nodes Using Two - PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 + PCN-markings . . . . . . . . . . . . . . . . . . . . . 15 5.2.3. Behaviour of PCN-interior Nodes Using One - PCN-marking . . . . . . . . . . . . . . . . . . . . . 15 - 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 . . . . . . . . . . . . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 18 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 21 - Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 22 + PCN-marking . . . . . . . . . . . . . . . . . . . . . 16 + 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 17 + 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 17 + 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 17 + 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 18 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 19 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 22 + Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 23 Appendix C. Example Mapping between Encoding of PCN-Marks in - IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 + IP and in MPLS Shim Headers . . . . . . . . . . . . . 26 Appendix D. Rationale for Difference Between the Schemes - using One PCN-Marking . . . . . . . . . . . . . . . . 25 + using One PCN-Marking . . . . . . . . . . . . . . . . 27 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, @@ -160,20 +160,39 @@ 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-10 to -11: + + * Pointed out that any DSCP re-mapping must precede PCN-ingress + processing; + + * Ingress behaviour for ECN-capable PCN-packets: allowed any PCN- + capable encapsulation, not just IP-in-IP tunnelling. Added + cautionary note about MPLS PHP; + + * PCN-policing at ingress: + + + Clarified what per-flow policing entails; + + + Clarified that a DSCP of zero is '000000'; + + + For policed packets, added SHOULD log, MAY alarm; + + * Updated refs and acks. + From draft-ietf-pcn-3-in-1-encoding-09 to -10: * Added cautionary management advice to S6.2 (backwards compatibility with RFC5696) * Removed "emphatically" from normative "NOT RECOMMENDED" text. * Minor editoral changes. From draft-ietf-pcn-3-in-1-encoding-08 to -09: @@ -431,21 +451,21 @@ [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. 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 + [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 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. @@ -483,73 +503,92 @@ 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 - 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 packets arrive from another Diffserv domain, any re-mapping of + Diffserv codepoints MUST happen before PCN-ingress processing. - 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. + 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 + 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 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: - * 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). + * Encapsulate ECN-capable PCN-packets across the PCN-domain: - This tunnelling policy is the RECOMMENDED choice, and - implementations SHOULD use it as the default. + + either within another IP header using an RFC6040 tunnel; - * 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). + + 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 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. * Drop the packet. This policy is also NOT RECOMMENDED, because it precludes the possibility that e2e ECN can co-exist with PCN as a means of controlling congestion. * 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], + 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. [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 @@ -563,31 +602,38 @@ * 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. + default an implementation SHOULD re-mark the DSCP to zero + (000000). - 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. + 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, Diffserv codepoints SHOULD be chosen that are already defined for use with admission- controlled traffic. Appendix A gives guidance to implementors on suitable DSCPs. @@ -781,22 +826,22 @@ 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 Philip Eardley for providing extensive feedback, criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, - Ruediger Geib, Georgios Karagiannis, Adrian Farrel and everyone else - who has commented on the document. + Ruediger Geib, Georgios Karagiannis, James Polk, Tom Taylor, 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 @@ -833,45 +878,49 @@ 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-12 - (work in progress), - February 2012. + ietf-pcn-cl-edge-behaviour-14 + (work in progress), April 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-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-09 (work in - progress), February 2012. + edge-behaviour-12 (work in + progress), April 2012. [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