Congestion and Pre-Congestion B. Briscoe Notification BT Internet-Draft T. MoncasterInternet-Draft BTIntended status: ExperimentalMarch 08, 2010Independent Expires:September 9,January 13, 2011 M. Menth University of Wuerzburg July 12, 2010PCN 3-StateEncodingExtension3 PCN-States in the IP header using a single DSCPdraft-ietf-pcn-3-in-1-encoding-02draft-ietf-pcn-3-in-1-encoding-03 Abstract The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.TheOn every link in the PCN domain, the overall rate of the PCN-traffic ismetered on every link in the PCN-domain,metered, and PCN-packets are appropriately marked when certain configured rates are exceeded.The levelEgress nodes provide decision points with information about the PCN-marks ofmarkingPCN-packets which allowsthe boundary nodesthem tomaketake decisions about whether to admit or block a new flow request, and(in abnormal circumstances) whetherto terminate someof the existing flows, thereby protecting the QoS of previouslyalready admittedflows.flows during serious pre- congestion. This document specifies howsuch marksPCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints withinthis controlled domain.a PCN-domain. This encoding builds on the baseline encoding of RFC5696 and provides for three different PCNencoding states: Not-marked, Threshold-marked and Excess-traffic-marked.marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. Status of this Memo This Internet-Draft is submittedto IETFin 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.(IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts.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 onSeptember 9, 2010.January 13, 2011. Copyright Notice Copyright (c) 2010 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Changes in This Version (to be removed by RFC Editor) . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . 6 4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 6.1. Backward Compatibility with Pre-existing PCN Implementations . . . . . . . . . . . . . . . . . . . . . 8 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 6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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(in abnormal circumstances)flow termination to decide whether to terminate someof the existing flows.already admitted flows during serious pre-congestion. To achieve this, the overall rate of PCN-traffic is metered on every link in the 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 to boundary nodes about overloads before any congestion occurs (hence"pre-congestion"pre- congestion notification").The level ofTwo metering and markingallows boundary nodes to make decisions about whether to admit or terminate. This is achieved byfunctions are proposed in [RFC5670] that are configured with reference rates. Threshold- markingpackets on interior nodes according to some metering function implemented at each node. Threshold-traffic-markingmarks all PCN packets oncethey exceed the threshold-traffic-ratetheir traffic rate on a linkwhile Excess-traffic- markingexceeds the configured reference rate (PCN-threshold-rate). Excess-traffic-marking marks only those PCN packets that exceed theexcess-traffic- rate, which is higher than the threshold-traffic-rate [RFC5670]. These marks are monitored byconfigured reference rate (PCN-excess-rate). The PCN-excess-rate is typically larger than theegressPCN-threshold-rate [RFC5559]. Egress nodesofmonitor thePCN domain. To fully support these two typesPCN-marks ofmarking, three encoding states are needed.received PCN-packets and provide information about the PCN-marks to decision points which take decisions about flow admission and termination on this basis [I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour]. The baseline encodingdescribeddefined in [RFC5696]provides for deployment scenarios that only requiredescribes how two PCNencodingmarking states can be encoded using a single Diffserv codepoint. However, to support the application of two different marking algorithms in a PCN-domain, for example as required in [I-D.ietf-pcn-cl-edge-behaviour], three PCN marking states are needed. This document describes anexperimentalextension to thebaseline-encodingbaseline encoding that adds a third PCNencodingmarking state in the IP header, still using a single Diffserv codepoint.For brevity it will beThis encoding scheme is calledthe 3-in-1ao˛3-in-1 PCNEncoding. General PCN-related terminology is defined in theencodingaoˇ. All PCNarchitecture [RFC5559], and terminology specific to packetencodingis defined in theschemes require an additional marking state to indicate non-PCN traffic. Therefore, four codepoints are required to encode three PCNbaseline encoding [RFC5696]. Note that [RFC5696] requiresmarking states. This document only concerns the PCNWorking Group to maintain a list ofwire protocol encoding for allDSCPs usedIP headers, whether IPv4 or IPv6. It makes no changes or recommendations concerning algorithms for congestion marking or congestion response. Other documents define the PCNexperiments.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. 1.1. Changes in This Version (to be removed by RFC Editor) From draft-ietf-pcn-3-in-1-encoding-02 to -03: * Corrected mistakes in introduction and improved overall readability. * Added new terminology. * Rewrote a good part of Section 4 and 5 to achieve more clarity. * Added appendix explaining when to use which encoding scheme and how to encode them in MPLS shim headers. * Added new co-author. From draft-ietf-pcn-3-in-1-encoding-01 to -02: * Corrected mistake in introduction, which wrongly stated that the threshold-traffic rate is higher than the excess-traffic rate. Other minor corrections. * Updated acks & refs. From draft-ietf-pcn-3-in-1-encoding-00 to -01: * Altered the wording to make sense if [I-D.ietf-tsvwg-ecn-tunnel] moves to proposed standard. * References updated From draft-briscoe-pcn-3-in-1-encoding-00 to draft-ietf-pcn-3-in-1-encoding-00: * Filename changed to draft-ietf-pcn-3-in-1-encoding. * Introduction altered to include new template description of PCN. * References updated. * Terminology brought into line with [RFC5670]. * Minor corrections. 2. 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 inRFC 2119[RFC2119]. 2.1. Terminology General PCN-related terminology is defined in the PCN architecture [RFC5559], and terminology specific to packet encoding is defined in the PCN baseline encoding [RFC5696]. Additional terminology is defined below. PCN encoding: mapping of PCN marking states to specific codepoints in the packet header. 3.The RequirementRequirements forThreeand Applicability of 3-in-1 PCN EncodingStates3.1. PCN Requirements The PCN architecture [RFC5559]describes proposed PCN schemesdefines thatexpect traffic to be metered and marked using both Threshold and Excess Traffic schemes. In orderPCN-ingress-nodes of a PCN-domain control incoming packets. Packets belonging toachieve this it is necessaryPCN- controlled flows are subject toallow for threePCNencoding states: one as a Not Marked (NM) statemetering and marking, they are termed PCN-packets, and PCN-ingress-nodes mark them as not-marked (PCN-colouring). Any node in theother two to distinguish thesePCN-domain may perform PCN metering and marking and mark PCN-packets if needed. There are twolevels ofdifferent metering and marking schemes: threshold-marking and excess-traffic- markingseverity[RFC5670].The way tunnels processedSome edge behaviors require only a single marking scheme [I-D.ietf-pcn-sm-edge-behaviour], others require both [I-D.ietf-pcn-cl-edge-behaviour]. In theECN field before [I-D.ietf-tsvwg-ecn-tunnel] severely limited howlatter case, three PCN marking states are needed: not-marked (NM) toencode these states. The two bit ECN field seemsindicate not-marked packets, threshold-marked (ThM) tooffer four possible encoding states, but one (00) is set aside for traffic controlledindicate packets marked bytransports that do not understand PCN marking [RFC5696], so it would be irregularthe threshold-marker, andriskyexcess-traffic-marked (ETM) touse it as a PCN encoding state. Ofindicate packets marked by thethree remaining ECN codepoints, onlyexcess-traffic-marker [RFC5670]. As threshold-marking and excess-traffic-marking start marking packets at different load conditions, one(11) can be introduced bymarking scheme indicates more severe pre-congestion than the other in terms of higher load. If acongested node withinpacket has been marked by both atunnelthreshold-marker andstill survivean excess-traffic-marker, it is marked with thedecapsulation behaviour ofmore severe state. Therefore, atunnel egressfourth PCN marking state indicating that a packet is marked by both markers is notupdatedneeded. Nonetheless, in addition tocomply with [I-D.ietf-tsvwg-ecn-tunnel]. The two remainingcodepointsare (10) and (01). But if a node withinfor thetunnel used either of these two remaining codepoints to trythree PCN marking states a fourth codepoint is required tomarkindicate packetswith a second severity level, a tunnelthat are notupdated to comply with [I-D.ietf-tsvwg-ecn-tunnel] would remove this marking on decapsulation. The ECN field was constrained toPCN-capable (termed the not-PCN codepoint). In all current PCN edge behaviors that use two markingstates in this way irrespective of which earlier ECN tunnelling specification the tunnel complied with, whether regular IP in IP tunnelling [RFC3168] or IPsec tunnelling [RFC4301]. One way to provide another encoding state that survives tunnellingschemes [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking isto use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding]. Instead, to avoid wasting scarce Diffserv codepoints, a network operator can require tunnels in a PCN region to comply with [I-D.ietf-tsvwg-ecn-tunnel], thus removing the constraints imposed by earlier tunnelling specifications. Therefore this document presupposes tunnels in the PCN region complyconfigured withthe newly proposed decapsulation rules defined in [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard tunnels no longer apply soa larger reference rate than threshold-marking. We take thisdocument canas a rule and define excess-traffic-marked as a3-state encoding for PCN within one Diffserv codepoint. 4. The 3-in-1 PCNmore severe PCN-mark than threshold-marked. 3.2. Requirements Imposed by Baseline Encoding The3-in-1 PCN Encoding scheme is based closely on thebaseline encodingdefined inscheme [RFC5696] was defined so thatthere willit could beno compatibility issues if a PCN-domain evolves from using the baseline encoding schemeextended to accommodate an additional marking state. It provides rules to embed theexperimental scheme described here. The exact manner in which the PCNencoding of two PCN statesare carriedin the IPheader is shown inheader. Figure1. +--------+----------------------------------------------------+ | | Codepoint in ECN field1 shows the structure ofIP header | | DSCP | <RFC3168the former type-of-service field. It contains the 6-bit Differentiated Services (DS) field that holds the DS codepointname> | | +--------------+-------------+-------------+---------+ | | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | +--------+--------------+-------------+-------------+---------+ | DSCP n | Not-PCN | NM(DSCP) [RFC2474] and the 2-bit ECN field [RFC3168]. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ |ThMDS FIELD |ETMECN FIELD |+--------+--------------+-------------+-------------+---------++-----+-----+-----+-----+-----+-----+-----+-----+ Figure 1:3-in-1 PCN Encoding In Figure 1 the 3 PCN states are encoded inStructure of theECNformer type-of-service field[RFC3168] of anin IPpacket with its Diffserv field [RFC2474]Baseline encoding defines that the DSCP must be set to a PCN- compatible DSCPn, which is any PCN-Compatible DiffServ codepoint as defined in Section 4.2 ofn and thePCN baselineECN-field [RFC3168] indicates the specific PCN-mark. Baseline encoding[RFC5696]). The PCN codepoint of a packet defines its marking state as follows: Not-PCN: The packet is controlled byoffers four possible encoding states within atransport that does not understand PCN marking, thereforesingle DSCP with theonly valid action to notify congestionfollowing restrictions. o Codepoint `00' (not-ECT) is used todrop the packet; NM: Not marked. A packet inindicate non-PCN traffic as "not-PCN". This allows theNM state has not (yet) had its marking state changeduse of a DSCP for both PCN and non-PCN traffic. o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN traffic. o Codepoint `11' (CE) is used to indicate theThM or ETM states, but itmost severe PCN-mark. o Codepoint `01' (ECT(1)) is available for experimental use and may bechanged to one of these states by a node experiencing congestion or pre-congestion; ThM: Threshold-marked. Such a packet has had its marking state changedre-used by other PCN encodings such as thethreshold-meter function [RFC5670]; ETM: Excess-traffic-marked. Suchpresently defined 3-in-1 PCN encoding. 3.3. Applicability of 3-in-1 PCN Encoding When PCN traffic is tunneled IP-in-IP within apacket has had its marking state changedPCN-domain, PCN-marks must be preserved in all outer IP headers after encapsulation and decapsulation. This property is violated by legacy encapsulation and decapsulation rules [RFC3168], [RFC4301] due to theexcess-traffic-meter function [RFC5670]. Packets marked NM, ThM or ETM are termed PCN-packets. Their entry intoway they treat thepcn-domain is controlled by edge nodes that understand howECN field. This led toprocess PCN markings [RFC5559]. 5. Behaviourstrong limitations regarding how PCN- marks can be encoded using the ECN field ofa PCN Node Compliantthe IP header [I-D.ietf-pcn-encoding-comparison]. Therefore, baseline encoding [RFC5696] was defined which works well with legacy tunnels but supports only two PCN marking states. Since then, new rules have been defined for IP-in-IP tunneling [I-D.ietf-tsvwg-ecn-tunnel] so that the present 3-in-1 PCNEncoding To be compliant withencoding has more freedom to accommodate PCN-marks using the ECN field. From this follows that 3-in-1 PCNEncoding, an PCN interior node behaves as follows: o Except where explicitly stated otherwise, it MUSTencoding may be applied only in PCN- domains that comply with [I-D.ietf-tsvwg-ecn-tunnel] or do not use tunneling. 4. Definition of 3-in-1 PCN Encoding The 3-in-1 PCN encoding scheme is an extension of the baseline encodingspecifiedscheme defined in[RFC5696][RFC5696]. The PCN requirements and the extension rules for baseline encoding presented in the previous section determine how PCN encoding states are carried in the IP headers. This is shown in Figure 2. +--------+----------------------------------------------------+ | | Codepoint in ECN field of IP header | | DSCP | <RFC3168 codepoint name> | | +--------------+-------------+-------------+---------+ | | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | +--------+--------------+-------------+-------------+---------+ | DSCP n | Not-PCN | NM | ThM | ETM | +--------+--------------+-------------+-------------+---------+ Figure 2: 3-in-1 PCN Encoding Like baseline encoding, 3-in-1 PCN encoding also uses a PCN compatible DSCP n and the ECN field for the encoding of PCN-marks. The PCN-marks have the following meaning. Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not subject to PCN metering and marking. NM: Not-marked. Indicates a PCN-packet that has not yet been marked by any PCN marker. ThM: Threshold-marked. Indicates a PCN-packet that has been marked by a threshold-marker [RFC5670]. ETM: Excess-traffic-marked. Indicates a PCN-packet that has been marked by an excess-traffic-marker [RFC5670]. 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding To be compliant with the 3-in-1 PCN Encoding, an PCN interior node behaves as follows: o It MUST change NM to ThM if the threshold-meter function indicates to mark the packet. o It MUST change NM or ThM to ETM if the excess-traffic-meter function indicates to mark the packet. o It MUST NOT changeNot-PCNnot-PCN toa PCN-Enabled codepointNM, ThM, or ETM, and MUST NOT change aPCN-Enabled codepointNM, ThM, or ETM toNot-PCN;not-PCN; o It MUST NOT change ThM to NM; o It MUST NOT change ETM to ThM or to NM; In other words, a PCN interior node MUST NOT mark PCN-packets into non-PCN packets and vice-versa, and it may increase the severity ofpacket markingthe PCN-mark of a PCN-packet, but it MUST NOT decreaseit, whereit. 6. Backward Compatibility Discussion of backward compatibility between PCN encoding schemes and previous uses of the ECN field is given in Section 6 of [RFC5696]. 6.1. Backward Compatibility with Pre-existing PCN Implementations This encoding complies with the rules for extending the baseline PCN encoding schemes in Section 5 of [RFC5696]. The term "compatibility" is meant in the following sense. It is possible to operate nodes with baseline encoding [RFC5696] and 3-in-1 encoding in the same PCN domain. The nodes with baseline encoding MUST perform excess-traffic-marking because the 11 codepoint of 3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodes of such domains are required to interpret the full 3-in-1 encoding and not just baseline encoding, otherwise they cannot interpret the 01 codepoint. Using nodes that perform only excess-traffic-marking may make sense in networks using the CL edge behavior [I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the egress only about severe pre-congestion when traffic needs to be terminated. This seems reasonable for locations that are not expected to see any pre-congestion, but excess-traffic-marking gives them a means to terminate traffic if unexpected overload still occurs. 6.2. Recommendations for the Use of PCN Encoding Schemes This sub-section is informative not normative. +------------------------+------------------------------------+ | Used marking schemes | Recommended PCN 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 | | +------------------------+------------------------------------+ Figure 3: Use of PCN encoding schemes Figure 3 gives guidelines under which conditions baseline encoding and 3-in-1 PCN encoding would typically be used. 6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking If both excess-traffic-marking and threshold-marking are enabled in a PCN-domain, 3-in-1 encoding should be used as described in this document. 6.2.2. Unique Use of Excess-Traffic-Marking If only excess-traffic-marking is enabled in a PCN-domain, baseline encoding or 3-in-1 encoding may be used. They lead to the same encoding because PCN-boundary nodes will interpret baseline "PCN- marked (PM)" as "excess-traffic-marked (ETM)". 6.2.3. Unique Use of Threshold-Marking No scheme is currently proposed to solely use threshold-marking. However, if only threshold-marking is enabled in a PCN-domain, baseline encoding SHOULD be used. This is because threshold marking will work in combination with legacy tunnel decapsulators within the PCN-domain, while using threshold marking with the 3-in-1 encoding requires that tunnel decapsulators within a PCN-domain comply with [I-D.ietf-tsvwg-ecn-tunnel]. 7. IANA Considerations This memo includes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations The security concerns relating to this extended PCN encoding are the same as those in [RFC5696]. In summary, PCN-boundary nodes are responsible for ensuring inappropriate PCN markings do not leak into or out of a PCN domain, and the current phase of the PCN architecture assumes that all the nodes of a PCN-domain are entirely under the control of a single operator, or a set of operators who trust each other. Given the only difference between the baseline encoding and the present 3-in-1 encoding is theorderuse ofseverity increases from NM through ThM to ETM. 6. IANA Considerations This memo includesthe 01 codepoint, norequest to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations Thenew securityconcerns relating to this extended PCN encodingissues arethe sameraised, asthosethis codepoint was already available for experimental use in[RFC5696]. 8.the baseline encoding. 9. Conclusions The 3-in-1 PCNEncoding provides three states to encode PCN markings inencoding uses a PCN-compatible DSCP and the ECN fieldof an IP packet using just one Diffserv codepoint.to encode PCN-marks. Onestate is for not marked packets whilecodepoint allows non-PCN traffic to be carried with thetwo others are forsame PCN-compatible DSCP and three other codepoints support three PCNnodes to mark packetsmarking states withincreasingdifferent levels of severity.UseThe use of this PCN encoding scheme presupposes that any tunnels in the PCN region have been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel].9.10. Acknowledgements Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chanand Michael Menthfor reviewingthis. 10.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 <pcn@ietf.org>, and/or to the authors.11.12. References11.1.12.1. Normative References[I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of Explicit Congestion Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in progress), March 2010.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [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.11.2.12.2. Informative References[I-D.ietf-pcn-3-state-encoding] Briscoe, B.,[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-06 (work in progress), June 2010. [I-D.ietf-pcn-encoding-comparison] Chan, K., Karagiannis, G., Moncaster, T.,and M.Menth,"A PCN encoding using 2 DSCPs to provide 3 or more states", draft-ietf-pcn-3-state-encoding-01M., Eardley, P., and B. Briscoe, "Pre-Congestion Notification Encoding Comparison", draft-ietf-pcn-encoding-comparison-02 (work in progress),FebruaryMarch 2010.[RFC4301] Kent, S.[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth, M., andK. Seo, "Security ArchitectureT. Taylor, "PCN Boundary Node Behaviour for theInternet Protocol", RFC 4301, December 2005.Single Marking (SM) Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-03 (work in progress), June 2010. [I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of Explicit Congestion Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in progress), March 2010. Authors' Addresses Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 645196 Email: bob.briscoe@bt.com URI: http://bobbriscoe.net/ Toby MoncasterBT c/o B54/70, Adastral Park Martlesham Heath Ipswich IP5 3RE UKIndependent Email: toby@moncaster.com Michael Menth University of Wuerzburg room B206, Institute of Computer Science Am Hubland Wuerzburg 97074 Germany Phone:+44 1206 332805+49 931 31 86644 Email:toby.moncaster@bt.commenth@informatik.uni-wuerzburg.de