Congestion and Pre-Congestion B. Briscoe Notification BT Internet-Draft T. Moncaster Obsoletes: 5696 (if approved) Moncaster Internet Consulting Intended status: Standards TrackMoncaster Internet Consulting Expires: November 22, 2011M. Menth Expires: January 11, 2012 University of TuebingenMay 21,July 10, 2011 Encoding 3 PCN-States in the IP header using a single DSCPdraft-ietf-pcn-3-in-1-encoding-05draft-ietf-pcn-3-in-1-encoding-06 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, theThe overall rate of the PCN-traffic ismetered,metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodesprovide decision points withpass information aboutthethese PCN-marksof PCN-packets which allows themtotake decisions aboutdecision points which then decide whether to admit or blockanew flowrequest, andrequests or to terminate somealready admittedalready-admitted flows during seriouspre- congestion.pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encodingbuilds on the baseline encoding of RFC5696 andprovides for up to three different PCN 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. This document obsoletes RFC5696. Status of this Memo 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). 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 onNovember 22, 2011.January 11, 2012. 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 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) . .42.1.1. Requirements Language . . . . . . . . . . . . . . . . . .. .52.1. Terminology . . . . . .1.2. Changes in This Version (to be removed by RFC Editor) . . 5 2. Definitions and Abbreviations . . . . . . . . . . . . . . .5 3. Requirements for and Applicability of 3-in-1 PCN Encoding. 7 2.1. Terminology .5 3.1. PCN Requirements. . . . . . . . . . . . . . . . . . . . .5 3.2. Requirements Imposed by Baseline Encoding. 7 2.2. List of Abbreviations . . . . . . .6 3.3. Applicability of 3-in-1 PCN Encoding. . . . . . . . . . . 74.3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . .7 5. Behaviour8 4. Requirements for and Applicability ofa PCN Node Compliant with the3-in-1 PCN Encoding . . 9 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9 4.2. Requirements Imposed by Tunnelling . . . .8 6. Backward Compatibility .. . . . . . . . 9 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . .8 6.1. Backward Compatibility10 5. Behaviour of a PCN-node to Comply withPre-existingthe 3-in-1 PCNImplementations . . . . . . . .Encoding . . . . . . . . . . . . .9 6.2. Recommendations for the Use of PCN Encoding Schemes. . .9 6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking. . . . . . . . . . . 10 5.1. PCN-ingress Node Behaviour . . . . . . .10 6.2.2. Unique Use of Excess-Traffic-Marking. . . . . . . . . 106.2.3. Unique Use of Threshold-Marking5.2. PCN-interior Node Behaviour . . . . . . . . . . .10 7. IANA Considerations. . . . 11 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings . . . . . . . . . . .10 8. Security Considerations. . . . . . . . . . 11 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking . . . . . . . . .10 9. Conclusions. . . . . . . . . . . . 11 5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . .11 10. Acknowledgements. 12 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 6.1. Backward Compatibility with ECN . .11 11. Comments Solicited. . . . . . . . . . . 13 6.2. Backward Compatibility with the Baseline Encoding . . . . 13 7. IANA Considerations . . . . . . .11. . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . .1115 12.1. Normative References . . . . . . . . . . . . . . . . . . .1115 12.2. Informative References . . . . . . . . . . . . . . . . . .1215 Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16 Appendix B. Co-existence of ECN and PCN(informative). . . . . .13. . . . . . . 18 Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in MPLS Shim Headers . . . . . . . . . . . . . 20 Appendix D. Rationale for different behaviours for single marking schemes . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1521 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, 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 real congestion occurs (hence "pre-congestion notification"). [RFC5670] provides for two metering and marking functions that are generally configured with different reference rates.Threshold-markingThreshold- marking marks all PCN packets once their traffic rate on a link exceeds the configured reference rate (PCN-threshold-rate).Excess-traffic-markingExcess- traffic-marking marks only those PCN packets that exceed the configured reference rate (PCN-excess-rate). The PCN-excess-rate is typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of received PCN-packets andprovidepass information aboutthethese PCN-marks to decision points whichtake decisions about flow admission and termination on this basisthen decide whether to admit new flows or terminate existing flows [I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour]. The baseline encoding defined in [RFC5696]describesdescribed how two PCN marking states (Not-marked and PCN-Marked)cancould be encoded into the IP header using a single Diffserv codepoint. It alsoprovidesprovided an experimental codepoint (EXP), along with guidelines for the use of that codepoint.To support the application of two differentTwo PCN markingalgorithms in a PCN- domain,states are sufficient forexample as required in [I-D.ietf-pcn-cl-edge-behaviour],the Single Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains utilising the controlled load edge behaviour [I-D.ietf-pcn-cl-edge-behaviour] require three PCN markingstates are needed.states. This documentdescribes an extension toextends the baseline encodingthat usesby redefining the EXP codepoint to provide a third PCN marking state in the IP header, still using a single Diffserv codepoint. This encoding scheme is therefore called the "3-in-1 PCN encoding". It obsoletes the baseline encoding [RFC5696], which provides only a sub-set of the same capabilities. The full version of this encoding requires any tunnel endpoint within the PCN-domain to support the normal tunnelling rules defined in [RFC6040]. There is one limited exception to this constraint where the PCN-domain only uses the excess-traffic-marking behaviour and where the threshold-marking behaviour is deactivated. This is discussed in Section 5.2.3.1. This document only concerns the PCN wire protocol encoding forallIP headers, whether IPv4 or IPv6. It makes no changes or recommendations concerning algorithms for congestion marking or congestion response. Other documents will define the PCN wire protocol for other header types.For example, the MPLS encoding is defined in [RFC5129] andAppendixA of that document provides an informative example forC discusses a possible mapping betweenthe encodings inIP andinMPLS. 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-05 to -06: * Draft re-written to obsolete baseline encoding [RFC5696]. * New section defining utilising this encoding for single marking. Added an appendix explaining an apparent inconsistency relating to single marking. * Moved (and updated) informative appendixes from [RFC5696] to this document. Original Appendix C was omitted as it is now redundant. * Significant re-structuring of document. From draft-ietf-pcn-3-in-1-encoding-04 to -05: * Draft moved to standards track as per working group discussions. * Added AppendixAB 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. * Updated author details. 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 draft-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 LanguageDefinitions and Abbreviations 2.1. Terminology Thekey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and"OPTIONAL" in this documentPCN- marking areto be interpretedused asdescribed in [RFC2119]. 2.1. Terminology General PCN-related terminology isdefined inthe PCN architecture [RFC5559], and terminology specific to packet encoding is[RFC5559]. The following additional terms are defined inthe PCN baseline encoding [RFC5696]. Additional terminology is defined below.this document: PCN encoding: mapping of PCN marking states to specific codepoints in the packet header.3. RequirementsPCN-compatible Diffserv codepoint: a Diffserv codepoint indicating packets forand Applicability of 3-in-1 PCN Encoding 3.1. PCN Requirements In accordance withwhich thePCN architecture [RFC5559], PCN-ingress-nodes control packets entering a PCN-domain. Packets belonging to PCN- controlled flows are subjectECN field is used toPCN-metering and -marking, and PCN- ingress-nodes mark them as Not-marked (PCN-colouring). Any node in the PCN-domain may perform PCN-metering and -marking and mark PCN- packets if needed. There are two different metering and marking schemes: threshold-marking and excess-traffic-marking [RFC5670]. Some edge behaviors require onlycarry PCN-markings rather than [RFC3168] markings (see Appendix A). Threshold-marked codepoint: asingle marking scheme [I-D.ietf-pcn-sm-edge-behaviour], others require both [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN marking states are needed: not-marked (NM) to indicate not-marked packets, threshold-marked (ThM) to indicatecodepoint that indicates packets that have been markedbyat a PCN-interior-node as a result of an indication from thethreshold-marker, and excess-traffic-marked (ETM)threshold-metering function [RFC5670]. Abbreviated toindicateThM. Excess-traffic-marked codepoint: a codepoint that indicates packets that have been markedbyat a PCN-interior-node as a result of an indication from theexcess-traffic-markerexcess-traffic-metering function [RFC5670].Threshold-marking and excess-traffic-marking are configuredAbbreviated tostart marking packets at different load conditions, so one marking scheme indicates more severe pre-congestion than the other. Therefore,ETM. Not-marked codepoint: afourth PCN marking state indicatingcodepoint thata packet is marked by both markers isindicates PCN-packets but that are notneeded. HoweverPCN-marked. Abbreviated to NM. not-PCN codepoint: afourthcodepointis required to indicatethat indicates packets that are notPCN-capable (the not-PCN codepoint). In all current PCN edge behaviors that use two marking schemes [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking is configured with a larger reference rate than threshold-marking. We take this as a rule and define excess-traffic-marked as a more severe PCN-mark than threshold-marked. 3.2. Requirements Imposed by Baseline EncodingPCN-packets. 2.2. List of Abbreviations Thebaseline encoding scheme [RFC5696] was defined so that it could be extended to accommodate an additional marking state. It provides rules to embed the encodingfollowing abbreviations are used in this document: o AF = Assured Forwarding [RFC2597] o CE = Congestion Experienced [RFC3168] o CS = Class Selector [RFC2474] o DSCP = Diffserv codepoint o ECN = Explicit Congestion Notification [RFC3168] o ECT = ECN Capable Transport [RFC3168] o EF = Expedited Forwarding [RFC3246] o ETM = Excess-traffic-marked o EXP = Experimental o IP = Internet protocol o NM = Not-marked o PCN = Pre-Congestion Notification o ThM = Threshold-marked 3. Definition oftwo3-in-1 PCN Encoding The 3-in-1 PCN encoding scheme allows for two or three PCN-marking statesinto be encoded within the IP header. The full encoding is shown in Figure1 shows the structure of the former type-of-service field. It contains the 6-bit Differentiated Services (DS) field that holds the DS codepoint (DSCP) [RFC2474] and the 2-bit1. +--------+----------------------------------------------------+ | | Codepoint in ECN field[RFC3168]. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+of IP header |DS FIELD|ECN FIELDDSCP | <RFC3168 codepoint name> | | +--------------+-------------+-------------+---------+ | | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | +--------+--------------+-------------+-------------+---------+ | DSCP n |+-----+-----+-----+-----+-----+-----+-----+-----+Not-PCN | NM | ThM | ETM | +--------+--------------+-------------+-------------+---------+ Figure 1:Structure3-in-1 PCN Encoding As mentioned above, the 3-in-1 PCN encoding is an extension of theformer type-of-service field in IP Baselinebaseline encodingdefines that[RFC5696]. Like theDSCP must be set tobaseline encoding it uses aPCN- compatiblecombination of a PCN-compatible DSCP (DSCP n in Figure 1) and theECN-field [RFC3168] indicatesECN field for thespecific PCN-mark. Baseline encoding offers four possibleencodingstates within a single DSCP withof PCN-marks. Appendix A discusses the choice of suitable DSCPs. The PCN-marks have the followingrestrictions. o Codepoint `00' (not-ECT)meaning. Not-PCN: indicates a non-PCN-packet, i.e., a packet that isusednot subject toindicate non-PCN traffic as "not-PCN". This allows bothPCN metering andnon-PCN traffic to use the same DSCP. o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN traffic. o Codepoint `11' (CE) is used to indicate the most severe PCN-mark. o Codepoint `01' (ECT(1)) is availablemarking. 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]. 4. Requirements forexperimental useandmay be re-used by otherApplicability of 3-in-1 PCNencodings such asEncoding 4.1. PCN Requirements In accordance with thepresently defined 3-in-1PCNencoding (subjectarchitecture [RFC5559], PCN-ingress-nodes control packets entering a PCN-domain. Packets belonging tothe rules definedPCN- controlled flows are subject to PCN-metering and -marking, and PCN- ingress-nodes mark them as Not-marked (PCN-colouring). Any node in[RFC5696]). [RFC6040] defines rules fortheencapsulationPCN-domain may perform PCN-metering anddecapsulation of ECN markings within IP-in-IP tunnels. This RFC removes some of the constraints that existed when [RFC5696] was written. Happily the rules for use of the EXP codepoint-marking and mark PCN- packets if needed. There arefully compatible with [RFC6040].two different metering and marking behaviours: threshold-marking and excess-traffic-marking [RFC5670]. Some edge behaviors require only a single marking behaviour [I-D.ietf-pcn-sm-edge-behaviour], others require both [I-D.ietf-pcn-cl-edge-behaviour]. Inparticular,therelative severity of eachlatter case, three PCN markingisstates are needed: not-marked (NM) to indicate not-marked packets, threshold-marked (ThM) to indicate packets marked by thesame: CE (PM) is more severe than ECT(1) (EXP) isthreshold-marker, and excess-traffic-marked (ETM) to indicate packets marked by the excess-traffic-marker [RFC5670]. Threshold-marking and excess-traffic-marking are configured to start marking packets at different load conditions, so one marking behaviour indicates more severe pre-congestion thanECT(0) (NM). Thisthe other. Therefore, a fourth PCN marking state indicating that a packet isdiscussed in more detail inmarked by both markers is not needed. However a fourth codepoint is required to indicate packets that do not use PCN (the not-PCN codepoint). In all current PCN edge behaviors that use two marking behaviours [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking is configured with a larger reference rate than threshold-marking. We take this as a rule and define excess-traffic-marked as a more severe PCN-mark than threshold-marked. 4.2. Requirements Imposed by Tunnelling [RFC6040] defines rules for the encapsulation and decapsulation of ECN markings within IP-in-IP tunnels. The publication of RFC6040 removed the tunnelling constraints that existed when the baseline encodingdocument[RFC5696]andwas written (see section 3.3.2 of [I-D.ietf-pcn-encoding-comparison]). Nonetheless, there is still a problem if there are any legacy (pre- RFC6040) decapsulating tunnel endpoints within a PCN domain. If a PCN node Threshold-marks the outer header of a tunnelled packet with a Not-marked codepoint on the inner header, the legacy decapsulator will revert the Threshold-marking to Not-marked. The rules on applicability in[I-D.ietf-pcn-encoding-comparison]. 3.3.Section 4.3 below are designed to avoid this problem. 4.3. Applicability of 3-in-1 PCN Encoding The 3-in-1 encoding is applicable in situations where two markingschemesbehaviours are being used in the PCN-domain.In some circumstances itThe 3-in-1 encoding can also be usedin PCN-domainswith onlya singleone markingschemebehaviour, inuse. Further guidance on choosing an encoding scheme canwhich case one of the codepoints MUST NOT befound inused throughout the PCN-domain (see Section6.2. All nodes5.2.3). For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP and IPsec) within the PCN-domain MUSTbe fully compliantcomply with the ECN encapsulation and decapsulation rules set out in[RFC6040]. As[RFC6040] (see Section 4.2). There is one exception to this rule outlined next. It may not be possible to upgrade every pre-RFC6040 tunnel endpoint within a PCN-domain. In such cirsumstances a limited version of the 3-in-1 encoding can still be used but only under the following stringent condition. If any pre-RFC6040 tunnel endpoint exists within a PCN-domain then every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint. The behaviour of PCN-interior nodes in this case isnot applicabledefined in Section 5.2.3.1. In all other situations where legacytunnelstunnel endpoints mightexist. 4. Definition of 3-in-1be present within the PCNEncoding Thedomain, the 3-in-1PCNencodingschemeisan extensionnot applicable. 5. Behaviour of a PCN-node to Comply with thebaseline encoding scheme defined in [RFC5696]. The3-in-1 PCNrequirements and the extension rules for baseline encoding presentedEncoding As mentioned inthe previous section determine how PCN encoding statesSection 4.3 above, all PCN-nodes MUST comply with [RFC6040]. 5.1. PCN-ingress Node Behaviour PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. To conserve DSCPs, Diffserv codepoints SHOULD be chosen that arecarriedalready defined for use with admission-controlled traffic. Appendix A gives guidance to implementors on suitable DSCPs. Guidelines for mixing traffic types within a PCN-domain are given in [RFC5670]. If a packet arrives at theIP 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 usesPCN-ingress-node that shares aPCNPCN- compatible DSCPnand is not a PCN-packet, the PCN-ingress MUST mark it as not-PCN. If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST change the PCN codepoint to Not-marked. If a PCN-packet arrives at the PCN-ingress-node with its ECN fieldforalready set to a value other than not-ECT, then appropriate action MUST be taken to meet theencodingrequirements ofPCN-marks.[RFC4774]. ThePCN-marks have the following meaning. Not-PCN: indicates a non-PCN-packet, i.e., a packet thatsimplest appropriate action isnot subjecttoPCN metering and marking. NM: Not-marked. Indicatesjust drop such packets. However, this is aPCN-packetdrastic action thathas 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 byanexcess-traffic-marker [RFC5670]. 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding Tooperator may feel is undesirable. Appendix B provides more information and summarises other alternative actions that might becompliant with the 3-in-1 PCN Encoding, an PCN interior node behaves as follows: o Ittaken. 5.2. PCN-interior Node Behaviour 5.2.1. Behaviour Common to all PCN-interior Nodes Interior nodes MUST NOT change not-PCN to any other codepoint. Interior nodes MUST NOT change NM to not-PCN. Interior nodes MUST NOT change ThMifto NM or not-PCN. Interior nodes MUST NOT change ETM to any other codepoint. 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings If the threshold-meter function indicates a need to mark thepacket; o Itpacket, the PCN-interior node MUST change NMor ThMtoETM ifThM. If the excess-traffic-meter function indicates a need to mark thepacket;packet: oItthe PCN-interior node MUSTNOTchangenot-PCNNM toNM, ThM, orETM; oIt MUST NOT change a NM, ThM, or ETM to not-PCN; o It MUST NOT change ThM to NM; o Itthe PCN-interior node MUSTNOTchangeETM toThMortoNM; In other words, a PCN interior node MUST NOT mark PCN-packets into non-PCN packets and vice-versa,ETM. If both the threshold meter andit may increasetheseverity ofexcess-traffic meter indicate thePCN-mark ofneed to mark aPCN-packet, but it MUST NOT decrease it. 6. Backward Compatibility Discussion of backward compatibility between PCN encoding schemes and previous uses ofpacket, theECN field is given in Section 6excess traffic marking rules MUST take priority. 5.2.3. Behaviour of[RFC5696]. 6.1. Backward Compatibility with Pre-existingPCN-interior Nodes Using One PCN-marking Some PCNImplementations This encoding complies with the rules for extendingedge behaviours require only one PCN-marking within thebaseline PCN encoding schemes in Section 5 of [RFC5696].PCN- domain. Theterm "compatibility" is meant inSingle Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark packets using thefollowing sense.excess-traffic-meter function [RFC5670]. It is possibleto operate nodes with baseline encoding [RFC5696] and 3-in-1 encoding inthat future schemes may require only thesame PCN domain.threshold-meter function. Observant readers may spot an apparent inconsistency between the two following cases. Appendix D explains the rationale behind this inconsistency. 5.2.3.1. Marking using only the Excess-traffic-meter Function Thenodes with baseline encodingthreshold-traffic-meter function SHOULD be disabled and MUSTperform excess-traffic-marking becauseNOT trigger any packet marking. The PCN-interior node SHOULD raise a management alarm if it receives a ThM packet, but the11 codepoint of 3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodesfrequency of suchdomains are required to interpretalarms SHOULD be limited. If thefull 3-in-1 encoding and not just baseline encoding, otherwise they cannot interpretexcess-traffic-meter function indicates a need to mark the01 codepoint. Using nodes that perform only excess-traffic-marking may make sense in networks usingpacket: o theCL edge behavior [I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are ablePCN-interior node MUST change NM tonotifyETM; o theegress only about severe pre-congestion when traffic needsPCN-interior node MUST change ThM to ETM. It SHOULD also raise an alarm as above. 5.2.3.2. Marking using only the Threshold-meter Function The excess-traffic-meter function SHOULD beterminated. This seems reasonable for locations that are not expected to seedisabled and MUST NOT trigger anypre-congestion,packet marking. The PCN-interior node SHOULD raise a management alarm if it receives an ETM packet, butexcess-traffic-marking gives themthe frequency of such alarms SHOULD be limited. If the threshold-meter function indicates ameansneed toterminate traffic if unexpected overload occurs. 6.2. Recommendations formark the packet: o the PCN-interior node MUST change NM to ThM; o theUsePCN-interior node MUST NOT change ETM to any other codepoint. It SHOULD raise an alarm as above. 5.3. Behaviour ofPCN Encoding Schemes NOTE: This sub-sectionPCN-egress Nodes A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all packets it forwards out of the PCN-domain. The only exception to this isinformative not normative. When deciding which PCN encodingif the PCN-egress-node issuitable an operator needscertain that revealing other codepoints outside the PCN-domain won't contravene the guidance given in [RFC4774]. For instance, if the PCN-ingress- node has explicitly informed the PCN-egress-node that this flow is ECN-capable, then it might be safe totake accountexpose other codepoints. Appendix B gives details of howmany 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. +------------------------+--------------------------------+ | Markingsuch schemesin 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 | | +------------------------+--------------------------------+ Figure 3: Guidelines for choosing PCN encodingmight work, but such schemes6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Markingare currently experimental. Ifboth excess-traffic-markingthe PCN-domain is configured to use only excess-traffic marking, the PCN-egress node MUST treat ThM as ETM andthreshold-marking are enabled in a PCN-domain, 3-in-1 encoding should beif only threshold- marking is used it should treat ETM asdescribedThM. However it SHOULD raise a management alarm in either instance since thisdocument. 6.2.2. Unique Use of Excess-Traffic-Marking If only excess-traffic-markingmeans there isenabledsome misconfiguration in the PCN-domain. 6. Backward Compatibility 6.1. Backward Compatibility with ECN BCP 124 [RFC4774] gives guidelines for specifying alternative semantics for the ECN field. It sets out aPCN-domain, baseline encoding or 3-in-1 encoding maynumber of factors to beused. They leadtaken into consideration. It also suggests various techniques to allow thesame encoding because PCN-boundary nodes will interpret baseline "PCN- marked (PM)" as "excess-traffic-marked (ETM)". 6.2.3. Unique Useco-existence ofThreshold-Marking No scheme is currently proposed that solelydefault ECN and alternative ECN semantics. The encoding specified in this document usesthreshold-marking. If such a scheme is proposed, the choiceone ofencoding scheme will depend on whether nodes are compliant with [RFC6040] or not. Wherethose techniques; it defines PCN-compatible Diffserv codepoints as no longer supporting the default ECN semantics. As such, this document iscertain that all nodes incompatible with BCP 124. On its own, thePCN-domain are compliant then either3-in-1 encodingor baseline encoding are suitable. If legacy tunnel decapsulators existcannot support both ECN marking end- to-end (e2e) and PCN-marking withinthe PCN-domain then baseline encoding SHOULD be used. 7. IANA Considerations This memo includes no requesta PCN-domain. Appendix B discusses possible ways to do this, e.g. by carrying e2e ECN across a PCN-domain within the inner header of an IP-in-IP tunnel. Although Appendix B recommends various approaches over others, it is merely informative and all such schemes are beyond the normative scope of this document. 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 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 Baseline Encoding A PCN node implemented to use the obsoleted baseline 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, thre is no known deployment of such an implementation 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 This memo includes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security ConsiderationsThe security concerns relating to this extended PCN encoding arePCN-marking only carries a meaning within thesame as those in [RFC5696]. In summary, PCN-boundary nodes are responsible for ensuring inappropriate PCN markings do not leak into or outconfines of aPCN domain, and the current phasePCN- domain. This encoding document is intended to stand independently of thePCNarchitecture used to determine how specific packets are authorised to be PCN-marked, which will be described in separate documents on PCN-boundary-node behaviour. This document assumesthat allthenodes of aPCN-domainareto be entirely under the control of a single operator, or a set of operators who trust each other.Given the only differenceHowever, future extensions to PCN might include inter-domain versions where trust cannot be assumed between domains. If such schemes are proposed, they must ensure that they can operate securely despite thebaseline encoding andlack of trust. However, such considerations are beyond thepresent 3-in-1 encodingscope of this document. One potential security concern is theuseinjection of spurious PCN-marks into the01 codepoint, no new security issues are raised, as this codepoint was already available for experimental usePCN-domain. However, these can only enter the domain if a PCN-ingress-node is misconfigured. The precise impact of any such misconfiguration will depend on which of the proposed PCN-boundary- node behaviours is used, but in general spurious marks will lead to admitting fewer flows into thebaseline encoding.domain or potentially terminating too many flows. In either case, good management should be able to quickly spot the problem since the overall utilisation of the domain will rapidly fall. 9. Conclusions 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.TheIn general, the use of this PCN encoding scheme presupposes that anytunnels intunnel endpoints within thePCN region have been updated toPCN-domain comply with [RFC6040]. 10. AcknowledgementsThanksMany thanks to PhilEardley,Eardley for providing extensive feedback, critcism and advice. Thanks also to Teco Boot, Kwok HoChan andChan, Ruediger Geib, Georgios Karaginannisfor reviewing thisand everyone else who has commented on the 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. 12. References 12.1. Normative References [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.[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-08draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),December 2010.June 2011. [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., Moncaster, T., Menth, M., Eardley, P., and B. Briscoe, "Overview of Pre-Congestion Notification Encoding",draft-ietf-pcn-encoding-comparison-05draft-ietf-pcn-encoding-comparison-06 (work in progress),AprilJune 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-05draft-ietf-pcn-sm-edge-behaviour-06 (work in progress),December 2010. Appendix A. Co-existence of ECNJune 2011. [RFC2597] Heinanen, J., Baker, F., Weiss, W., andPCN (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 appendixJ. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008. [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 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. Appendix A. Choice of Suitable DSCPs This appendix is informative, not normative. The PCN working group chose not to define a single DSCP for use with PCN for several reasons. Firstly, the PCN mechanism is applicable to a variety of different traffic classes. Secondly, Standards Track DSCPs are in increasingly short supply. Thirdly, PCN is not a scheduling behaviour -- rather, it should be seen as being a marking behaviour similar to ECN but intended for inelastic traffic. The choice of which DSCP is most suitable for a given PCN-domain is dependent on the nature of the traffic entering that domain and the link rates of all the links making up that domain. In PCN-domains with sufficient aggregation, the appropriate DSCPs would currently be those for the Real-Time Treatment Aggregate [RFC5127]. The PCN working group suggests using admission control for the following service classes (defined in [RFC4594]): o Telephony (EF) o Real-time interactive (CS4) o Broadcast Video (CS3) o Multimedia Conferencing (AF4) CS5 is excluded from this list since PCN is not expected to be applied to signalling traffic. PCN can also be applied to the VOICE- ADMIT codepoint defined in [RFC5865]. PCN-marking is intended to provide a scalable admission-control mechanism for traffic with a high degree of statistical multiplexing. PCN-marking would therefore be appropriate to apply to traffic in the above classes, but only within a PCN-domain containing sufficiently aggregated traffic. In such cases, the above service classes may well all be subject to a single forwarding treatment (treatment aggregate [RFC5127]). However, this does not imply all such IP traffic would necessarily be identified by one DSCP -- each service class might keep a distinct DSCP within the highly aggregated region [RFC5127]. Additional service classes may be defined for which admission control is appropriate, whether through some future standards action or through local use by certain operators, e.g., the Multimedia Streaming service class (AF3). This document does not preclude the use of PCN in more cases than those listed above. Note: The above discussion is informative not normative, as operators are ultimately free to decide whether to use admission control for certain service classes and whether to use PCN as their mechanism of choice. Appendix B. Co-existence of ECN and PCN This appendix is informative, not normative. 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] (obsoleted) included advice on handling ECN traffic within a PCN-domain. This appendix reiterates and clarifies that advice. For the purposes of this appendix we define twoformsforms 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 a 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, e.g. 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 (and therefore outside the scope of PCN). 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. Unless specified otherwise, for any of the cases in the list below, an IP-in-IP tunnel can be used to preserve ECN markings across the PCN domain. However the tunnelling action should be applied 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 2: Separation of tunneling and PCN actions There are 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 trafficthat might arrive atin a tunnel with a PCN- compatible DSCP in the outer header. The PCN-egress zeroes the ECN-field before decapsulation. * The PCN-ingressnode. These are Admission-controlled trafficdrops CE-marked packets andNon-admission-controlled traffic.the PCN-egress zeros the ECN field of all PCN packets. The second option is emphatically not recommended, unless perhaps as a last resort if tunnelling is not possible for some insurmountable reason. ECN-capable Admission-controlled trafficwill be remarkedwhere the e2e transport somehow indicates that it wants to see PCN marks: NOTE this is currently tentative only. Schemes have been suggested where PCN marks may be leaked out of thePCN-compatible DSCPPCN-domain and used by thePCN-ingress node. Two mechanisms can be usedend hosts toidentifymodify realtime data rates. Currently all suchtraffic: a. flow signalling associates a filterspecschemes require further study and the following is for guidance only. The PCN-ingress needs to tunnel the traffic, taking care to comply with [RFC6040]. In this case the PCN-egress should not zero the ECN field, and then the [RFC6040] tunnel egress will preserve any PCN-marking. Note that aneedPCN interior node may turn ECT(0) into ECT(1), which would not be compatible with the (currently experimental) ECN nonce [RFC3540]. Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in MPLS Shim Headers This appendix is informative not normative. The 6 bits of the DS field in the IP header provide foradmission control (e.g. through RSVP or some equivalent message down from a SIP server64 codepoints. When encapsulating IP traffic in MPLS, it is useful to make theingress), andDS field information accessible in thePCN-ingress remarksMPLS header. However, the MPLS shim header has only a 3-bit trafficmatching that filterspecclass (TC) field [RFC5462] providing for 8 codepoints. The operator has the freedom to define aPCN-compatible DSCP, as its chosen admission control mechanism. b. Traffic arrives withsite-local mapping of aDSCP 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 thoughtsubset ofas Non-admission-controlled. However such traffic may still need to sharethesame DSCP as64 codepoints of theAdmission-controlled traffic. This may be dueDS field topolicy (for instance if it is high priority voice traffic), or may be because there is a shortage of local DSCPs.the 8 codepoints in the TC field. [RFC5129] describes how ECN[RFC3168] is an end-to-end congestion notification mechanism. As such it is possible that some traffic enteringmarkings in thePCN-domain mayIP header can also beECN capable The following listsmapped to codepoints in thefour cases forMPLS TC field. Appendix A of [RFC5129] gives an informative description of howe2e ECN traffic may wishtobe treatedsupport PCN in MPLS by extending the way MPLS supports ECN. But [RFC5129] was written whilecrossingPCN specifications were in early draft stages. The following provides a clearer example of a mapping between PCNdomain: ECN capable traffic that does not require admission controlin IP anddoes not carry a DSCP that the PCN-ingress isin MPLS usingfor PCN-capable traffic. This requires no action. ECN capable trafficthe PCN terminology and concepts thatdoes not require admission control but carrieshave since been specified. To support PCN in aDSCP thatMPLS domain, codepoints for all used PCN-marks need to be provided in thePCN-ingressTC field. That means, when e.g. only excess-traffic-marking isusingused forPCN-capable traffic. There are two options. * The ingress mapsPCN purposes, theDSCPoperator needs to define alocal DSCP with the same scheduling PHB as the original DSCP, and the egress re-maps itsite-local mapping tothe original PCN-compatible DSCP. * The ingress tunnels the traffic, setting not-PCNcodepoints in theouter header; note that this turns off ECNMPLS TC field forthis traffic within the PCN domain. The first option is recommended unlessIP headers with: o DSCP n and ECT(0) o DSCP n and CE If both excess-traffic-marking and threshold-marking are used, the operatoris short of local DSCPs. ECN-capable Admission-controlled traffic: There are two options. * The PCN-ingress places this traffic in a tunnel withneeds to define aPCN- compatible DSCPsite-local mapping to codepoints in theouter header. The PCN-egress zeroesMPLS TC field for IP headers with all three of theECN-field before decapsulation. * The PCN-ingress drops CE-marked packets3-in-1 codepoints: o DSCP n and ECT(0) o DSCP n and ECT(1) o DSCP n and CE In either case, if thePCN-egress zerosoperator wishes to support theECN field of allsame Diffserv PHB but without PCNpackets. The second option is not recommended unless tunnelling is not possible for some reason.. ECN-capable Admission-controlled where the e2e transport somehow indicates thatmarking, itwantswill also be necessary tosee PCN marks: NOTE this is currently experimental only. Schemes have been suggested where PCN marksdefine a site-local mapping to an MPLS TC codepoint for IP headers marked with: o DSCP n and Not-ECT Appendix D. Rationale for different behaviours for single marking schemes Readers maybe leaked out ofnotice an apparent discrepancy between thePCN-domaintwo single marking behaviours in Section 5.2.3.1 andused bySection 5.2.3.2. For theend hosts to modify realtime data rates. Currently all such schemes are experimental andexcess-traffic only marking an unexpected ThM marked packet is remarked as ETM. For thefollowingthreshold only marking, an unexpected ETM marked packet is simply ignored (apart from an optional management alarm). There are two reasons forguidance only. The PCN-ingress needs to tunnel the traffic using [RFC6040]. The PCN-egress should not zero the ECN field, andhaving these seemingly contradictory requirements. Firstly these behaviours conform with thetunnel egress should use [RFC6040] normal mode (preserving any PCN-marking). Note that this may turn ECT(0) into ECT(1)expected behaviour where both metering functions are being used for marking-- ETM is always a more severe marking than ThM and sois not compatible withshould never be re-marked. Secondly theexperimental ECN nonce [RFC3540]. Inthreshold-metering behaviour in [RFC5670] uses thelist above any formcurrent marking state ofIP-in-IP tunnel canthe arriving packet to determine what action to take. Consequently, in the ETM only marking it would beused unless specified otherwise. NB, We assume a logical separation of tunneling and PCN actionspotentially unsafe to allow ThM packets to propagate forward inboth PCN-ingress and PCN-egress nodes. That is, any tunneling action happens wholly outsidethePCN-domainnetwork asillustrated inthey may adversely affect thefollowing figure: , . . . . . PCN-domain . . . . . . . ,--------. ,--------. . . _| PCN- |___________________| PCN- |_ . . / | ingress | | egress | \ . .| '---------' '--------' |. | . . . . . . . . . . . . . . .| ,--------. ,--------. _____| Tunnel | | Tunnel |____ | Ingress | - - ECN preserved inside tunnel - - | Egress | '---------' '--------' Figure 4: Separation of tunneling and PCN actionsthreshold-metering function. 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 Moncaster Moncaster Internet Consulting Dukes 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 Tuebingen 72076 Germany Phone: +49 7071 2970505 Email: menth@informatik.uni-tuebingen.de