--- 1/draft-ietf-pcn-3-in-1-encoding-09.txt 2012-03-22 18:13:59.026671286 +0100 +++ 2/draft-ietf-pcn-3-in-1-encoding-10.txt 2012-03-22 18:13:59.074670920 +0100 @@ -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 12, 2012 University of Tuebingen - March 11, 2012 +Expires: September 21, 2012 University of Tuebingen + March 20, 2012 Encoding 3 PCN-States in the IP header using a single DSCP - draft-ietf-pcn-3-in-1-encoding-09 + draft-ietf-pcn-3-in-1-encoding-10 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 12, 2012. + This Internet-Draft will expire on September 21, 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 @@ -60,51 +60,51 @@ 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. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 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.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 11 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 + 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.2. Behaviour of PCN-interior Nodes Using Two PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 5.2.3. Behaviour of PCN-interior Nodes Using One - PCN-marking . . . . . . . . . . . . . . . . . . . . . 14 + 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 . . . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 17 + 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 18 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 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 21 + Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 22 Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 Appendix D. Rationale for Difference Between the Schemes 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 @@ -160,20 +160,29 @@ 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-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: * 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. @@ -333,22 +341,25 @@ 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 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 | @@ -506,29 +516,29 @@ 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. + 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 emphatically NOT RECOMMENDED, because it - precludes the possibility that e2e ECN can co-exist with PCN as - a means of controlling congestion. + 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 @@ -702,20 +712,35 @@ 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 + Section 5.1 of the PCN architecture gives general guidance on fault + detection and diagnosis [RFC5559], 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 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 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