--- 1/draft-ietf-pcn-3-in-1-encoding-04.txt 2011-05-21 14:15:21.000000000 +0200 +++ 2/draft-ietf-pcn-3-in-1-encoding-05.txt 2011-05-21 14:15:21.000000000 +0200 @@ -1,21 +1,21 @@ Congestion and Pre-Congestion B. Briscoe Notification BT Internet-Draft T. Moncaster -Intended status: Experimental Moncaster Internet Consulting -Expires: July 15, 2011 M. Menth +Intended status: Standards Track Moncaster Internet Consulting +Expires: November 22, 2011 M. Menth University of Tuebingen - January 11, 2011 + May 21, 2011 Encoding 3 PCN-States in the IP header using a single DSCP - draft-ietf-pcn-3-in-1-encoding-04 + draft-ietf-pcn-3-in-1-encoding-05 Abstract The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, @@ -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 July 15, 2011. + This Internet-Draft will expire on November 22, 2011. Copyright Notice Copyright (c) 2011 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 @@ -70,35 +70,36 @@ 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 6.1. Backward Compatibility with Pre-existing PCN - Implementations . . . . . . . . . . . . . . . . . . . . . 8 + Implementations . . . . . . . . . . . . . . . . . . . . . 9 6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 6.2.1. Use of Both Excess-Traffic-Marking and - Threshold-Marking . . . . . . . . . . . . . . . . . . 9 - 6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9 + Threshold-Marking . . . . . . . . . . . . . . . . . . 10 + 6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10 6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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, @@ -130,25 +131,36 @@ extension to the baseline encoding that uses the EXP codepoint to provide a third PCN marking state in the IP header, still using a single Diffserv codepoint. This encoding scheme is called "3-in-1 PCN encoding". This document only concerns the PCN wire protocol encoding for all IP headers, whether IPv4 or IPv6. It makes no changes or recommendations concerning algorithms for congestion marking or congestion response. Other documents define the PCN wire protocol for other header types. For example, the MPLS encoding is defined in - [RFC5129]. Appendix A provides an informative example for a mapping - between the encodings in IP and in MPLS. + [RFC5129] and Appendix A of that document provides an informative + example for a mapping between the encodings in IP and in MPLS. 1.1. Changes in This Version (to be removed by RFC Editor) + From draft-ietf-pcn-3-in-1-encoding-04 to -05: + + * Draft moved to standards track as per working group + discussions. + + * Added Appendix A discussing ECN handling in the PCN-domain. + + * Clarified that this document modifies [RFC5696]. + + * ....... + From draft-ietf-pcn-3-in-1-encoding-03 to -04: * Updated document to reflect RFC6040. * Re-wrote introduction. * Re-wrote section on applicability. * Re-wrote section on choosing encoding scheme. @@ -388,21 +398,21 @@ 6.2. Recommendations for the Use of PCN Encoding Schemes NOTE: This sub-section is informative not normative. When deciding which PCN encoding is suitable an operator needs to take account of how many PCN states need to be encoded. The following table gives guidelines on which encoding to use with either threshold-marking, excess-traffic marking or both. +------------------------+--------------------------------+ - | Used marking schemes | Recommended encoding scheme | + | Marking schemes in use | Recommended encoding scheme | +------------------------+--------------------------------+ | Only threshold-marking | Baseline encoding [RFC5696] | +------------------------+--------------------------------+ | Only excess-traffic- | Baseline encoding [RFC5696] | | marking | or 3-in-1 PCN encoding | +------------------------+--------------------------------+ | Threshold-marking and | 3-in-1 PCN encoding | | excess-traffic-marking | | +------------------------+--------------------------------+ @@ -457,22 +467,22 @@ 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. The use of this PCN encoding scheme presupposes that any tunnels in the PCN region have been updated to comply with [RFC6040]. 10. Acknowledgements - Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing - this document. + Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios + Karaginannis for reviewing this 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 @@ -483,61 +493,176 @@ [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. + [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit + Congestion Notification (ECN) Signaling with Nonces", + RFC 3540, June 2003. + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + August 2006. + [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008. [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. [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. + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 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-08 (work in progress), December 2010. [I-D.ietf-pcn-encoding-comparison] - Chan, K., Karagiannis, G., Moncaster, T., Menth, M., - Eardley, P., and B. Briscoe, "Pre-Congestion Notification - Encoding Comparison", - draft-ietf-pcn-encoding-comparison-03 (work in progress), - October 2010. + Karagiannis, G., Chan, K., Moncaster, T., Menth, M., + Eardley, P., and B. Briscoe, "Overview of Pre-Congestion + Notification Encoding", + draft-ietf-pcn-encoding-comparison-05 (work in progress), + April 2011. [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-05 (work in progress), December 2010. +Appendix A. Co-existence of ECN and PCN (informative) + + 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] included advice on handling + ECN traffic within a PCN-domain. This appendix clarifies that + advice. + + 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 remarked to the PCN-compatible + DSCP by the PCN-ingress node. Two mechanisms can be used to identify + such traffic: + + a. flow signalling associates a filterspec with a need for admission + control (e.g. through RSVP or some equivalent message down from a + SIP server to the ingress), and the PCN-ingress remarks traffic + matching that filterspec to a PCN-compatible DSCP, as its chosen + admission control mechanism. + + b. Traffic arrives with a DSCP that implies it requires admission + control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, + Broadcast TV when used for video on demand, and Multimedia + Conferencing [RFC4594][RFC5865]. + + All other traffic can be thought of as Non-admission-controlled. + 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 The following lists the four cases for how e2e + ECN traffic may wish to be treated while crossing a PCN domain: + + ECN capable traffic that does not require admission control and does + not carry a DSCP that the PCN-ingress is using for PCN-capable + traffic. This requires no action. + + ECN capable traffic that does not require admission control but + carries a DSCP that the PCN-ingress is using for PCN-capable + traffic. There are two options. + + * 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. + + * 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. + + The first option is recommended unless the operator is short of + local DSCPs. + + ECN-capable Admission-controlled traffic: There are two options. + + * The PCN-ingress 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 drops CE-marked packets and the PCN-egress + zeros the ECN field of all PCN packets. + + The second option is not recommended unless tunnelling is not + possible for some reason.. + + ECN-capable Admission-controlled where the e2e transport somehow + indicates that it wants to see PCN marks: NOTE this is currently + experimental only. + + Schemes have been suggested where PCN marks may be leaked out of + the PCN-domain and used by the end hosts to modify realtime data + rates. Currently all such schemes are experimental and the + following is for guidance only. + + The PCN-ingress needs to tunnel the traffic using [RFC6040]. The + PCN-egress should not zero the ECN field, and the tunnel egress + should use [RFC6040] normal mode (preserving any PCN-marking). + Note that this may turn ECT(0) into ECT(1) and so is not + compatible with the experimental ECN nonce [RFC3540]. + + In the list above any form of IP-in-IP tunnel can be used unless + specified otherwise. NB, We assume a logical separation of tunneling + and PCN actions in both PCN-ingress and PCN-egress nodes. That is, + any tunneling action happens wholly outside the PCN-domain as + illustrated in the following figure: + + , . . . . . PCN-domain . . . . . . + . ,--------. ,--------. . + . _| PCN- |___________________| PCN- |_ . + . / | ingress | | egress | \ . + .| '---------' '--------' |. + | . . . . . . . . . . . . . . .| + ,--------. ,--------. + _____| Tunnel | | Tunnel |____ + | Ingress | - - ECN preserved inside tunnel - - | Egress | + '---------' '--------' + + Figure 4: Separation of tunneling and PCN actions + Authors' Addresses Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 645196 @@ -550,15 +675,15 @@ Layer Marney Colchester CO5 9UZ UK Phone: +44 7764 185416 Email: toby@moncaster.com URI: http://www.moncaster.com/ Michael Menth University of Tuebingen Sand 13 - 72076 Tuebingen + Tuebingen 72076 Germany Phone: +49 7071 2970505 Email: menth@informatik.uni-tuebingen.de