idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2009) is 5405 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-pcn-baseline-encoding-04 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-02 == Outdated reference: A later version (-02) exists of draft-ietf-pcn-3-state-encoding-00 == Outdated reference: A later version (-05) exists of draft-ietf-pcn-marking-behaviour-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre-Congestion B. Briscoe 3 Notification T. Moncaster 4 Internet-Draft BT 5 Intended status: Experimental July 1, 2009 6 Expires: January 2, 2010 8 PCN 3-State Encoding Extension in a single DSCP 9 draft-ietf-pcn-3-in-1-encoding-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 2, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The objective of Pre-Congestion Notification (PCN) is to protect the 48 quality of service (QoS) of inelastic flows within a Diffserv domain. 50 The overall rate of the PCN-traffic is metered on every link in the 51 PCN-domain, and PCN-packets are appropriately marked when certain 52 configured rates are exceeded. The level of marking allows the 53 boundary nodes to make decisions about whether to admit or block a 54 new flow request, and (in abnormal circumstances) whether to 55 terminate some of the existing flows, thereby protecting the QoS of 56 previously admitted flows. This document specifies how such marks 57 are to be encoded into the IP header by re-using the Explicit 58 Congestion Notification (ECN) codepoints within this controlled 59 domain. This encoding builds on the baseline encoding and provides 60 for three PCN encoding states: Not-marked, Threshold-marked and 61 Excess-traffic-marked. 63 1. Introduction 65 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 66 protect the quality of service (QoS) of inelastic flows within a 67 Diffserv domain, in a simple, scalable, and robust fashion. Two 68 mechanisms are used: admission control, to decide whether to admit or 69 block a new flow request, and (in abnormal circumstances) flow 70 termination to decide whether to terminate some of the existing 71 flows. To achieve this, the overall rate of PCN-traffic is metered 72 on every link in the domain, and PCN-packets are appropriately marked 73 when certain configured rates are exceeded. These configured rates 74 are below the rate of the link thus providing notification to 75 boundary nodes about overloads before any congestion occurs (hence 76 "pre-congestion notification"). 78 The level of marking allows boundary nodes to make decisions about 79 whether to admit or terminate. This is achieved by marking packets 80 on interior nodes according to some metering function implemented at 81 each node. Excess-traffic-marking marks PCN packets that exceed a 82 certain reference rate on a link while threshold marking marks all 83 PCN packets on a link when the PCN traffic rate exceeds a higher 84 reference rate [I-D.ietf-pcn-marking-behaviour]. These marks are 85 monitored by the egress nodes of the PCN domain. 87 To fully support these two types of marking, three encoding states 88 are needed. The baseline encoding described in 89 [I-D.ietf-pcn-baseline-encoding] provides for deployment scenarios 90 that only require two PCN encoding states using a single Diffserv 91 codepoint. This document describes an experimental extension to the 92 baseline-encoding that adds a third PCN encoding state in the IP 93 header, still using a single Diffserv codepoint. For brevity it will 94 be called the 3-in-1 PCN Encoding. 96 General PCN-related terminology is defined in the PCN architecture 98 [RFC5559], and terminology specific to packet encoding is defined in 99 the PCN baseline encoding [I-D.ietf-pcn-baseline-encoding]. Note 100 that [I-D.ietf-pcn-baseline-encoding] requires the PCN Working Group 101 to maintain a list of all DSCPs used for PCN experiments. 103 1.1. Changes in This Version (to be removed by RFC Editor) 105 From draft-briscoe-pcn-3-in-1-encoding-00: 107 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 109 * Introduction altered to include new standard description of 110 PCN. 112 * References updated. 114 * Terminology brought into line with 115 [I-D.ietf-pcn-marking-behaviour]. 117 * Minor corrections. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. The Requirement for Three PCN Encoding States 127 The PCN architecture [RFC5559] describes proposed PCN schemes that 128 expect traffic to be metered and marked using both Threshold and 129 Excess Traffic schemes. In order to achieve this it is necessary to 130 allow for three PCN encoding states: one as a Not Marked (NM) state 131 and the other two to distinguish these two levels of marking severity 132 [I-D.ietf-pcn-marking-behaviour]. The way tunnels process the ECN 133 field severely limits how to encode these states. 135 The two bit ECN field seems to offer four possible encoding states, 136 but one (00) is set aside for traffic controlled by transports that 137 do not understand PCN marking [I-D.ietf-pcn-baseline-encoding], so it 138 would be irregular and risky to use it as a PCN encoding state. Of 139 the three remaining ECN codepoints, only one (11) can be introduced 140 by a congested node within a tunnel and still survive the 141 decapsulation behaviour of a tunnel egress as currently standardised. 142 The two remaining codepoints are (10) and (01). But if a node within 143 the tunnel used either of these two remaining codepoints to try to 144 mark packets with a second severity level, this marking would be 145 removed on decapsulation. The ECN field is constrained to two 146 marking states in this way irrespective of whether regular IP in IP 147 tunnelling [RFC3168] or IPsec tunnelling [RFC4301] is used. 149 One way to provide another encoding state that survives tunnelling is 150 to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding]. 151 Instead, to avoid wasting scarce Diffserv codepoints, we could modify 152 standard tunnels in the PCN region to remove the constraints imposed 153 by standard tunnelling. 155 Therefore this document presupposes tunnels in the PCN region comply 156 with the newly proposed decapsulation rules defined in 157 [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard 158 tunnels no longer apply so this document can define a 3-state 159 encoding for PCN within one Diffserv codepoint. 161 4. The 3-in-1 PCN Encoding 163 The 3-in-1 PCN Encoding scheme is based closely on that defined in 164 [I-D.ietf-pcn-baseline-encoding] so that there will be no 165 compatibility issues if a PCN-domain evolves from using the baseline 166 encoding scheme to the experimental scheme described here. The exact 167 manner in which the PCN encoding states are carried in the IP header 168 is shown in Table 1. 170 Codepoint in ECN field of IP header 171 173 +--------+--------------+-------------+-------------+---------+ 174 | DSCP | 00 | 10 | 01 | 11 | 175 +--------+--------------+-------------+-------------+---------+ 176 | DSCP n | Not-PCN | NM | ThM | ETM | 177 +--------+--------------+-------------+-------------+---------+ 179 Table 1: 3-in-1 PCN Encoding 181 In Table 1 the 3 PCN states are encoded in the ECN field ([RFC3168]) 182 of an IP packet with its Diffserv field ([RFC2474]) set to DSCP n, 183 which is any PCN-Compatible DiffServ codepoint as defined in Section 184 4.2 of the PCN baseline encoding [I-D.ietf-pcn-baseline-encoding]). 185 The PCN codepoint of a packet defines its marking state as follows: 187 Not-PCN: The packet is controlled by a transport that does not 188 understand PCN marking, therefore the only valid action to notify 189 congestion is to drop the packet; 191 NM: Not marked. A packet in the NM state has not (yet) had its 192 marking state changed to the ThM or ETM states, but it may be 193 changed to one of these states by a node experiencing congestion 194 or pre-congestion; 196 ThM: Threshold-marked. Such a packet has had its marking state 197 changed by the threshold-meter function 198 [I-D.ietf-pcn-marking-behaviour]; 200 ETM: Excess-traffic-marked. Such a packet has had its marking state 201 changed by the excess-traffic-meter function 202 [I-D.ietf-pcn-marking-behaviour]. 204 Packets marked NM, ThM or ETM are termed PCN-packets because their 205 entry into the pcn-domain is controlled by edge nodes that understand 206 how to process PCN markings. 208 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 210 To be compliant with the 3-in-1 PCN Encoding, an PCN interior node 211 behaves as follows: 213 o Except where explicitly stated otherwise, it MUST comply with 214 [I-D.ietf-pcn-baseline-encoding] 216 o It MUST change NM TO ThM if the threshold-meter function indicates 217 to mark the packet. 219 o It MUST change NM or ThM TO ETM if the excess-traffic-meter 220 function indicates to mark the packet. 222 o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT 223 change a PCN-Enabled codepoint to Not-PCN; 225 o It MUST NOT change ThM to NM; 227 o It MUST NOT change ETM to ThM or to NM; 229 In other words, a PCN interior node may increase the severity of 230 packet marking but it MUST NOT decrease it, where the order of 231 severity increases from NM through ThM to ETM. 233 6. IANA Considerations 235 This memo includes no request to IANA. 237 Note to RFC Editor: this section may be removed on publication as an 238 RFC. 240 7. Security Considerations 242 The security concerns relating to this extended PCN encoding are 243 essentially the same as those in [I-D.ietf-pcn-baseline-encoding]. 245 8. Conclusions 247 The 3-in-1 PCN Encoding provides three states to encode PCN markings 248 in the ECN field of an IP packet using just one Diffserv codepoint. 249 One state is for not marked packets while the two others are for PCN 250 nodes to mark packets with increasing levels of severity. Use of 251 this encoding presupposes that any tunnels in the PCN region have 252 been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. 254 9. Acknowledgements 256 Thanks to Phil Eardley for reviewing this. 258 10. Comments Solicited 260 To be removed by RFC Editor: Comments and questions are encouraged 261 and very welcome. They can be addressed to the IETF Congestion and 262 Pre-Congestion working group mailing list , and/or to 263 the authors. 265 11. References 267 11.1. Normative References 269 [I-D.ietf-pcn-baseline-encoding] 270 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 271 Encoding and Transport of Pre-Congestion Information", 272 draft-ietf-pcn-baseline-encoding-04 (work in progress), 273 May 2009. 275 [I-D.ietf-tsvwg-ecn-tunnel] 276 Briscoe, B., "Tunnelling of Explicit Congestion 277 Notification", draft-ietf-tsvwg-ecn-tunnel-02 (work in 278 progress), March 2009. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 284 "Definition of the Differentiated Services Field (DS 285 Field) in the IPv4 and IPv6 Headers", RFC 2474, 286 December 1998. 288 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 289 of Explicit Congestion Notification (ECN) to IP", 290 RFC 3168, September 2001. 292 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 293 Architecture", RFC 5559, June 2009. 295 11.2. Informative References 297 [I-D.ietf-pcn-3-state-encoding] 298 Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding 299 using 2 DSCPs to provide 3 or more states", 300 draft-ietf-pcn-3-state-encoding-00 (work in progress), 301 April 2009. 303 [I-D.ietf-pcn-marking-behaviour] 304 Eardley, P., "Metering and marking behaviour of PCN- 305 nodes", draft-ietf-pcn-marking-behaviour-04 (work in 306 progress), June 2009. 308 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 309 Internet Protocol", RFC 4301, December 2005. 311 Authors' Addresses 313 Bob Briscoe 314 BT 315 B54/77, Adastral Park 316 Martlesham Heath 317 Ipswich IP5 3RE 318 UK 320 Phone: +44 1473 645196 321 Email: bob.briscoe@bt.com 322 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 323 Toby Moncaster 324 BT 325 c/o B54/70, Adastral Park 326 Martlesham Heath 327 Ipswich IP5 3RE 328 UK 330 Phone: +44 1206 332805 331 Email: toby.moncaster@bt.com