--- 1/draft-ietf-pcn-baseline-encoding-06.txt 2009-09-25 17:12:17.000000000 +0200 +++ 2/draft-ietf-pcn-baseline-encoding-07.txt 2009-09-25 17:12:17.000000000 +0200 @@ -1,20 +1,20 @@ Congestion and Pre Congestion T. Moncaster Internet-Draft B. Briscoe Intended status: Standards Track BT -Expires: March 8, 2010 M. Menth +Expires: March 29, 2010 M. Menth University of Wuerzburg - September 4, 2009 + September 25, 2009 Baseline Encoding and Transport of Pre-Congestion Information - draft-ietf-pcn-baseline-encoding-06 + draft-ietf-pcn-baseline-encoding-07 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -33,21 +33,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 8, 2010. + This Internet-Draft will expire on March 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -66,39 +66,40 @@ encoding described here provides only two PCN encoding states: not- marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6 3.1. List of Abbreviations . . . . . . . . . . . . . . . . . . 7 - 4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 7 - 4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 8 - 4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 9 + 4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 8 + 4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 9 + 4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 10 4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10 - 4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 10 + 4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 11 5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11 - 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 + 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. PCN Deployment Considerations (Informational) . . . . 14 - A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 14 - A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 15 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Appendix A. PCN Deployment Considerations (Informational) . . . . 15 + A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 15 + A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 16 + Appendix B. Co-existence of PCN and ECN (Informational) . . . . . 17 1. Introduction The objective of the Pre-Congestion Notification (PCN) Architecture [RFC5559] is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable and robust fashion. 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. These configured rates are below the rate of the link thus providing notification before any @@ -112,20 +113,31 @@ header by re-using the bits of the Explicit Congestion Notification (ECN) field [RFC3168]. It also describes how packets are identified as belonging to a PCN-flow. Some deployment models require two PCN encoding states, others require more. The baseline encoding described here only provides for two PCN encoding states. However the encoding can be easily extended to provide more states. Rules for such extensions are given in Section 5. Changes from previous drafts (to be removed by the RFC Editor): + From -06 to -07: + + Changes made following IESG review comments. + + Changed Section 4 and added Appendix B to clarify the correct + behaviour when handling packets that already have values other + than not-ECT in their ECN field. + + Added paragraph to end of Section 6 clarifying that a PCN-domain + has "hard" edges. + From -05 to -06: Extensive changes to the text following IETF Last Call and Gen-ART review comments. Abstract updated following mailing list discussions after Gen-ART review by Spencer Dawkins. Added list of abbreviations @@ -138,21 +150,21 @@ Section 5. Removed any ambiguity about meaning of PCN-marked in such a context. Added requirements for experimental schemes to define which meter causes which mark. Clarified text in Section 6 relating to support for e2e ECN. Added text in Section 8 relating to injection of PCN-marks into the PCN-domain. Changed text of Appendix A.1 to reflect comments from Spencer - Dawkins and Philip Eardey. + Dawkins and Philip Eardley. From -04 to -05: Clarified throughout that the PCN WG is not requesting a specific DSCP for PCN. Rather we are recommending a set of DSCPs that might be suitable. Appendix A.1 has been re-written to reflect this. References to maintaining a list of PCN-compatible DSCPs have also been removed. Last sentence of Section 6 altered. @@ -335,23 +347,31 @@ The following rules apply to all PCN traffic: o 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.1 gives guidance to implementors on suitable DSCPs. Guidelines for mixing traffic-types within a PCN-domain are given in [I-D.ietf-pcn-marking-behaviour]. - o Any packet that is not-PCN but which shares the same Diffserv - codepoint as PCN-enabled traffic MUST have its ECN field set to - 00. + o Any packet arriving at the PCN-ingress that shares a PCN- + compatible DSCP and is not-PCN MUST be marked as not-PCN within + the PCN-domain. + + o If a packet arrives at the PCN-ingress with its ECN field already + set to a value other than not-ECT, then appropriate action MUST be + taken to meet the requirements of [RFC3168]. 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. 4.1. Marking Packets [I-D.ietf-pcn-marking-behaviour] states that any encoding scheme document must specify the required action to take if one of the marking algorithms indicates that a packet needs to be marked. For the baseline encoding scheme the required action is simply as follows: o If a marking algorithm indicates the need to mark a PCN-packet @@ -509,20 +529,29 @@ The baseline encoding specified in this document defines PCN- compatible Diffserv codepoints as no longer supporting the default ECN semantics. As such this document is compatible with BCP 124. On its own, this baseline encoding cannot support both ECN marking end to end and PCN marking within a PCN-domain. It is possible to do this by carrying e2e ECN across a PCN domain within the inner header of an IP in IP tunnel, or by using a richer encoding such as the proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding]. + 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 PCN + codepoint. PCN-egress-nodes then guarantee that the ECN-field of any + packet leaving the PCN-domain has the correct ECN semantics. This + prevents leakage of ECN marks into or out of the PCN-domain and thus + reduces backward compatibility issues. + 7. IANA Considerations This document makes no request to IANA. 8. 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 @@ -720,20 +748,67 @@ outside the controlled PCN-domain). o Incremental deployment: Either codepoint is suitable providing that the codepoints are used consistently. o Conceptual consistency with other schemes: ECT(0) is conceptually consistent with [RFC3168]. Overall this seemed to suggest ECT(0) was most appropriate to use. +Appendix B. Co-existence of PCN and ECN (Informational) + + This baseline encoding scheme redefines the ECN codepoints within the + PCN-domain. As packets with a PCN-compatible DSCP leave the PCN- + domain, their ECN field is reset to not-ECT (00). This is a problem + for the operator if packets with a PCN-compatible DSCP arrive at the + PCN-domain with any ECN codepoint other than not-ECN. If the ECN- + codepoint is ECT(0) (10) or ECT(1) (01), resetting the ECN field to + 00 effectively turns off end-to-end ECN. This is undesirable as it + removes the benefits of ECN but [RFC3168] states it is no worse than + dropping the packet. However, if a packet was marked with CE (11), + resetting the ECN field to 00 at the PCN egress node violates the + rule that CE-marks must never be lost except as a result of packet + drop [RFC3168]. + + A number of options exist to overcome this issue. The most + appropriate option will depend on the circumstances and has to be a + decision for the operator. The definition of the action is beyond + the scope of this document but we briefly explain the four broad + categories of solution below: tunnelling the packets, using an + extended encoding scheme, signalling to the end-systems to stop using + ECN or re-marking packets to a different DSCP. + + o Tunnelling the packets across the PCN-domain (for instance in an + IP-in-IP tunnel from the PCN-ingress-node to the PCN-egress-node) + preserves the original ECN marking on the inner header. + + o An extended encoding scheme can be designed that preserves the + original ECN codepoints. For instance if the PCN-egress-node can + determine from the PCN codepoint what the original ECN codepoint + was then it can reset the packet to that codepoint. + [I-D.ietf-pcn-3-state-encoding] partially achieves this but is + unable to recover ECN markings if the packet is PCN-marked in the + PCN-domain. + + o Explicit signalling to the end systems can indicate to the source + that ECN cannot be used on this path (because it does not support + ECN & PCN at the same time). Dropping the packet can be thought + of as a form of silent signal to the source as it will see any + ECT-marked packets it sends being dropped. + + o Packets that are not-PCN but which share a PCN-compatible DSCP can + be re-marked to a different local-use DSCP at the PCN-ingress-node + with the original DSCP restored at the PCN-egress. This preserves + the ECN codepoint on the packets, but it relies on there being + spare local-use DSCPs within the PCN-domain. + Authors' Addresses Toby Moncaster BT B54/70, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 648734