--- 1/draft-ietf-pcn-3-state-encoding-01.txt 2012-03-12 23:14:01.535087779 +0100 +++ 2/draft-ietf-pcn-3-state-encoding-02.txt 2012-03-12 23:14:01.563087834 +0100 @@ -1,113 +1,116 @@ -Congestion and Pre Congestion B. Briscoe -Internet-Draft BT & UCL -Intended status: Experimental T. Moncaster -Expires: August 14, 2010 BT +Congestion and Pre Congestion T. Moncaster +Internet-Draft University of Cambridge +Intended status: Historic B. Briscoe +Expires: September 13, 2012 BT M. Menth - University of Wuerzburg - February 10, 2010 + University of Tuebingen + March 12, 2012 A PCN encoding using 2 DSCPs to provide 3 or more states - draft-ietf-pcn-3-state-encoding-01 + draft-ietf-pcn-3-state-encoding-02 Abstract Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme provides 6 states, enough for limited end- to-end support for ECN as well. +Status + + Since its original publication, the baseline encoding (RFC5696) on + which this document depends has become obsolete. The PCN working + Group has chosen to publish this as a historical document to preserve + the details of the encoding and to allow it to be cited in other + documents. + Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + 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), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + 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." - 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 August 14, 2010. + This Internet-Draft will expire on September 13, 2012. Copyright Notice - Copyright (c) 2010 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 BSD License. + described in the Simplified BSD License. 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 the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Changes from Previous Drafts (to be removed by the RFC - Editor) . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. The Requirement for Three PCN Encoding States . . . . . . . . 5 - 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 5 - 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 6 - 6.1. Basic Three State Encoding . . . . . . . . . . . . . . . . 6 - 6.2. Full Three State Encoding . . . . . . . . . . . . . . . . 6 - 6.3. Common Diffserv Per-Hop Behaviour . . . . . . . . . . . . 7 + Editor) . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. The Requirement for Three PCN Encoding States . . . . . . . . 6 + 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 7 + 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 7 + 6.1. Basic Three State Encoding . . . . . . . . . . . . . . . . 8 + 6.2. Full Three State Encoding . . . . . . . . . . . . . . . . 8 + 6.3. Common Diffserv Per-Hop Behaviour . . . . . . . . . . . . 9 6.4. Valid and invalid codepoint transitions at - PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . 8 + PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . 9 6.5. Valid and invalid codepoint transitions at - PCN-interior-nodes . . . . . . . . . . . . . . . . . . . . 8 - 6.6. Forwarding traffic out of the PCN-domain . . . . . . . . . 9 - 7. PCN-domain support for the PCN extension encoding . . . . . . 9 + PCN-interior-nodes . . . . . . . . . . . . . . . . . . . . 10 + 6.6. Forwarding traffic out of the PCN-domain . . . . . . . . . 10 + 7. PCN-domain support for the PCN extension encoding . . . . . . 11 7.1. End-to-End transport behaviour compliant with the PCN - extension encoding . . . . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + extension encoding . . . . . . . . . . . . . . . . . . . . 11 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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. 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 congestion @@ -132,22 +135,40 @@ doing it are discussed in Section 5. As in the baseline encoding, this extension encoding re-uses the ECN bits within the IP header within a controlled PCN-domain. This extension requires the use of two DSCPs as described later in this document. This experimental scheme is one of three that are being proposed within the PCN working group. The aim is to allow implementors to decide which scheme is most suitable for possible future standardisation. + Following the publication of new rules relating to the tunnelling of + ECN marks [RFC6040], the PCN workign group decided to obsolete + [RFC5696] in favour of the 3-in-1 encoding + [I-D.ietf-pcn-3-in-1-encoding]. A side-effect of this decision was + to make the encoding described in this document obsolete. However + the PCN working group feels it is useful to have a formal historical + record of this encoding. This ensures details of the encoding are + not lost and also allows it to be cited in other documents. + 1.1. Changes from Previous Drafts (to be removed by the RFC Editor) + From draft-ietf-pcn-3-state-encoding-01 to 02: + + o Changed the document from teh experimental to the historic track + + o Added notes to the Introduciton and Abstract explaining the change + to historical + + o Updated refs + From draft-ietf-pcn-3-state-encoding-00 to 01: o Removed text implying the two DSCPs have different priority and added Section 6.3 specifying they must both have the same PHB. o Made IANA considerations text more precise. o Changed variable names for DSCP 1 & DSCP 2 to DSCP n & DSCP m to be consistent with baseline encoding. @@ -197,47 +218,46 @@ represents a PCN capable packet that has no PCN marking but which arrived with the ECN bits set to congestion experienced. 4. The Requirement for Three PCN Encoding States The PCN Marking Behaviours document [RFC5670] describes proposed PCN schemes that require traffic to be metered and marked using both Threshold and Excess Traffic schemes. In order to achieve this it is necessary to allow for three PCN encoding states. The constraints imposed by the way tunnels process the ECN field severely limit how - to encode these states as explained in [RFC5696] and - [I-D.ietf-tsvwg-ecn-tunnel]. The obvious way to provide one more - encoding state than the base encoding is through the use of an - additional PCN-compatible DiffServ codepoint. + to encode these states as explained in [RFC5696] and [RFC6040]. The + obvious way to provide one more encoding state than the base encoding + is through the use of an additional PCN-compatible DiffServ + codepoint. One aim of this document is to allow for experiments to show whether such schemes are better than those that only employ two PCN encoding states. As such, the additional DSCP will be taken from the EXP/LU pools defined in [RFC2474]. If the experiments demonstrate that PCN schemes employing three encoding states are significantly better than those only employing two, then at a later date IANA might be asked to assign a new PCN enabled DSCP from pool 1. Note that there are other experimental encoding schemes being considered which only use one DSCP but require either alternative tunnel semantics ([I-D.ietf-pcn-3-in-1-encoding]) or additional signalling ([I-D.ietf-pcn-psdm-encoding])in order to work. 5. Adding Limited End-to-End ECN Support to PCN - [I-D.sarker-pcn-ecn-pcn-usecases] suggests a number of use-cases - where explicit preservation of end-to-end ECN semantics might be - needed across a PCN domain. One of the use-cases suggests that the - end-nodes might be running rate-adaptive codecs that would respond to - ECN marks by reducing their transmission rate. If the sending - transport sets the ECT codepoint, the setting of the ECN field as it - arrives at the PCN ingress node will need to be re-instated as it - leaves the PCN egress node. + There are a number of use-cases where explicit preservation of end- + to-end ECN semantics might be needed across a PCN domain. One of the + use-cases suggests that the end-nodes might be running rate-adaptive + codecs that would respond to ECN marks by reducing their transmission + rate. If the sending transport sets the ECT codepoint, the setting + of the ECN field as it arrives at the PCN ingress node will need to + be re-instated as it leaves the PCN egress node. If a PCN region is starting to suffer pre-congestion then it may make sense to expose marks generated within the PCN region by forwarding CE marks from the PCN egress to such a rate-adaptive endpoint. They would be in addition to any CE marks generated elsewhere on the end- to-end path. This would allow the endpoints to reduce the traffic rate. This will in turn help to alleviate the pre-congestion, potentially averting any need for call blocking or termination. However, the 'leaking' of CE marks out of the PCN region is potentially dangerous and could violate [RFC4774] if the end hosts @@ -300,34 +320,32 @@ (where DSCP n is a PCN-compatible DiffServ codepoint (see [RFC5696]) and DSCP m is a PCN-compatible DSCP from the EXP/LU pools as defined in [RFC2474]) Table 2: Encoding three PCN states in IP The four different Not-marked (NM) states allow for the addition of limited end-to-end ECN support as explained in the previous section. -Warning - - In order to comply with this encoding all the nodes within the PCN- - domain MUST be configured with this encoding scheme. However there - may be operators who choose not to be fully compliant with the - scheme. If an operator chooses to leave some PCN-interior-nodes that - only support two marking states (the baseline encoding [RFC5696]), - then they must be aware of the following: Ideally such nodes would be - configured to indicate pre-congestion or congestion using the ETM - state since this would ensure they could notify worst-case - congestion, however this is not possible since it requires the - packets to be re-marked to DSCP m (hence altering the baseline - encoding). This means that such nodes will only be able to indicate - ThM traffic. + WARNING: In order to comply with this encoding all the nodes within + the PCN-domain MUST be configured with this encoding scheme. + However there may be operators who choose not to be fully + compliant with the scheme. If an operator chooses to leave some + PCN-interior-nodes that only support two marking states (the + baseline encoding [RFC5696]), then they must be aware of the + following: Ideally such nodes would be configured to indicate pre- + congestion or congestion using the ETM state since this would + ensure they could notify worst-case congestion, however this is + not possible since it requires the packets to be re-marked to DSCP + m (hence altering the baseline encoding). This means that such + nodes will only be able to indicate ThM traffic. 6.3. Common Diffserv Per-Hop Behaviour Packets carrying Diffserv codepoint 'DSCP n' or 'DSCP m' MUST all be treated with the same Diffserv PHB [RFC2474]. The choice of PHB is discussed in [RFC5559] and [RFC5696]. Two DSCPs are merely used to provide sufficient PCN encoding states, there is no need or intention to provide different scheduling or drop preference for each row in the table of PCN codepoints. @@ -529,87 +548,79 @@ [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. 13.2. Informative References [I-D.ietf-pcn-3-in-1-encoding] - Briscoe, B. and T. Moncaster, "PCN 3-State Encoding - Extension in a single DSCP", - draft-ietf-pcn-3-in-1-encoding-01 (work in progress), - February 2010. + Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN- + States in the IP header using a single DSCP", + draft-ietf-pcn-3-in-1-encoding-09 (work in progress), + March 2012. [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-01 (work in progress), - October 2009. + 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-psdm-encoding] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, - "PCN Encoding for Packet-Specific Dual Marking (PSDM)", - draft-ietf-pcn-psdm-encoding-00 (work in progress), - June 2009. - - [I-D.ietf-tsvwg-ecn-tunnel] - Briscoe, B., "Tunnelling of Explicit Congestion - Notification", draft-ietf-tsvwg-ecn-tunnel-06 (work in - progress), December 2009. - - [I-D.sarker-pcn-ecn-pcn-usecases] - Sarker, Z. and I. Johansson, "Usecases and Benefits of end - to end ECN support in PCN Domains", - draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress), - May 2008. + "PCN Encoding for Packet-Specific Dual Marking (PSDM + Encoding)", draft-ietf-pcn-psdm-encoding-01 (work in + progress), March 2010. [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. [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009. + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, November 2010. + Authors' Addresses - Bob Briscoe - BT & UCL - B54/77, Adastral Park - Martlesham Heath - Ipswich IP5 3RE + Toby Moncaster + University of Cambridge + Computer Laboratory + JJ Thomson Avenue + Cambridge CB3 0FD UK - Phone: +44 1473 645196 - Email: bob.briscoe@bt.com + Phone: +44 1223 763654 + Email: toby@moncaster.com - Toby Moncaster + Bob Briscoe BT - B54/70, Adastral Park + B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK - Phone: +44 1473 648734 - Email: toby.moncaster@bt.com - URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ - + Phone: +44 1473 645196 + Email: bob.briscoe@bt.com + URI: http://www.bobbriscoe.net Michael Menth - University of Wuerzburg - room B206, Institute of Computer Science - Am Hubland - Wuerzburg D-97074 + University of Tuebingen + Department of Computer Science + Sand 13 + Tuebingen D-72076 Germany - Phone: +49 931 888 6644 - Email: menth@informatik.uni-wuerzburg.de + Phone: +49 07071 29 70505 + Email: menth@informatik.uni-tuebingen.de + URI: http://www.kn.inf.uni-tuebingen.de