idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (February 10, 2010) is 5189 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-03 ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-02) exists of draft-ietf-pcn-3-state-encoding-00 Summary: 2 errors (**), 0 flaws (~~), 3 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 February 10, 2010 6 Expires: August 14, 2010 8 PCN 3-State Encoding Extension in a single DSCP 9 draft-ietf-pcn-3-in-1-encoding-01 11 Abstract 13 The objective of Pre-Congestion Notification (PCN) is to protect the 14 quality of service (QoS) of inelastic flows within a Diffserv domain. 15 The overall rate of the PCN-traffic is metered on every link in the 16 PCN-domain, and PCN-packets are appropriately marked when certain 17 configured rates are exceeded. The level of marking allows the 18 boundary nodes to make decisions about whether to admit or block a 19 new flow request, and (in abnormal circumstances) whether to 20 terminate some of the existing flows, thereby protecting the QoS of 21 previously admitted flows. This document specifies how such marks 22 are to be encoded into the IP header by re-using the Explicit 23 Congestion Notification (ECN) codepoints within this controlled 24 domain. This encoding builds on the baseline encoding and provides 25 for three PCN encoding states: Not-marked, Threshold-marked and 26 Excess-traffic-marked. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on August 14, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 1. Introduction 68 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 69 protect the quality of service (QoS) of inelastic flows within a 70 Diffserv domain, in a simple, scalable, and robust fashion. Two 71 mechanisms are used: admission control, to decide whether to admit or 72 block a new flow request, and (in abnormal circumstances) flow 73 termination to decide whether to terminate some of the existing 74 flows. To achieve this, the overall rate of PCN-traffic is metered 75 on every link in the domain, and PCN-packets are appropriately marked 76 when certain configured rates are exceeded. These configured rates 77 are below the rate of the link thus providing notification to 78 boundary nodes about overloads before any congestion occurs (hence 79 "pre-congestion notification"). 81 The level of marking allows boundary nodes to make decisions about 82 whether to admit or terminate. This is achieved by marking packets 83 on interior nodes according to some metering function implemented at 84 each node. Excess-traffic-marking marks PCN packets that exceed a 85 certain reference rate on a link while threshold marking marks all 86 PCN packets on a link when the PCN traffic rate exceeds a higher 87 reference rate [RFC5670]. These marks are monitored by the egress 88 nodes of the PCN domain. 90 To fully support these two types of marking, three encoding states 91 are needed. The baseline encoding described in [RFC5696] provides 92 for deployment scenarios that only require two PCN encoding states 93 using a single Diffserv codepoint. This document describes an 94 experimental extension to the baseline-encoding that adds a third PCN 95 encoding state in the IP header, still using a single Diffserv 96 codepoint. For brevity it will be called the 3-in-1 PCN Encoding. 98 General PCN-related terminology is defined in the PCN architecture 99 [RFC5559], and terminology specific to packet encoding is defined in 100 the PCN baseline encoding [RFC5696]. Note that [RFC5696] requires 101 the PCN Working Group to maintain a list of all DSCPs used for PCN 102 experiments. 104 1.1. Changes in This Version (to be removed by RFC Editor) 106 From draft-ietf-pcn-3-in-1-encoding-00 to -01: 108 * Altered the wording to make sense if 109 [I-D.ietf-tsvwg-ecn-tunnel] moves to proposed standard. 111 * References updated 113 From draft-briscoe-pcn-3-in-1-encoding-00 to 114 draft-ietf-pcn-3-in-1-encoding-00: 116 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 118 * Introduction altered to include new template description of 119 PCN. 121 * References updated. 123 * Terminology brought into line with [RFC5670]. 125 * Minor corrections. 127 2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 3. The Requirement for Three PCN Encoding States 135 The PCN architecture [RFC5559] describes proposed PCN schemes that 136 expect traffic to be metered and marked using both Threshold and 137 Excess Traffic schemes. In order to achieve this it is necessary to 138 allow for three PCN encoding states: one as a Not Marked (NM) state 139 and the other two to distinguish these two levels of marking severity 140 [RFC5670]. The way tunnels processed the ECN field before 141 [I-D.ietf-tsvwg-ecn-tunnel] severely limited how to encode these 142 states. 144 The two bit ECN field seems to offer four possible encoding states, 145 but one (00) is set aside for traffic controlled by transports that 146 do not understand PCN marking [RFC5696], so it would be irregular and 147 risky to use it as a PCN encoding state. Of the three remaining ECN 148 codepoints, only one (11) can be introduced by a congested node 149 within a tunnel and still survive the decapsulation behaviour of a 150 tunnel egress not updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. 151 The two remaining codepoints are (10) and (01). But if a node within 152 the tunnel used either of these two remaining codepoints to try to 153 mark packets with a second severity level, a tunnel not updated to 154 comply with [I-D.ietf-tsvwg-ecn-tunnel] would remove this marking on 155 decapsulation. The ECN field was constrained to two marking states 156 in this way irrespective of which earlier ECN tunnelling 157 specification the tunnel complied with, whether regular IP in IP 158 tunnelling [RFC3168] or IPsec tunnelling [RFC4301]. 160 One way to provide another encoding state that survives tunnelling is 161 to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding]. 162 Instead, to avoid wasting scarce Diffserv codepoints, a network 163 operator can require tunnels in a PCN region to comply with 164 [I-D.ietf-tsvwg-ecn-tunnel], thus removing the constraints imposed by 165 earlier tunnelling specifications. 167 Therefore this document presupposes tunnels in the PCN region comply 168 with the newly proposed decapsulation rules defined in 169 [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard 170 tunnels no longer apply so this document can define a 3-state 171 encoding for PCN within one Diffserv codepoint. 173 4. The 3-in-1 PCN Encoding 175 The 3-in-1 PCN Encoding scheme is based closely on the baseline 176 encoding defined in [RFC5696] so that there will be no compatibility 177 issues if a PCN-domain evolves from using the baseline encoding 178 scheme to the experimental scheme described here. The exact manner 179 in which the PCN encoding states are carried in the IP header is 180 shown in Figure 1. 182 +--------+----------------------------------------------------+ 183 | | Codepoint in ECN field of IP header | 184 | DSCP | | 185 | +--------------+-------------+-------------+---------+ 186 | | 00 | 10 | 01 | 11 | 187 +--------+--------------+-------------+-------------+---------+ 188 | DSCP n | Not-PCN | NM | ThM | ETM | 189 +--------+--------------+-------------+-------------+---------+ 191 Figure 1: 3-in-1 PCN Encoding 193 In Figure 1 the 3 PCN states are encoded in the ECN field [RFC3168] 194 of an IP packet with its Diffserv field [RFC2474] set to DSCP n, 195 which is any PCN-Compatible DiffServ codepoint as defined in Section 196 4.2 of the PCN baseline encoding [RFC5696]). The PCN codepoint of a 197 packet defines its marking state as follows: 199 Not-PCN: The packet is controlled by a transport that does not 200 understand PCN marking, therefore the only valid action to notify 201 congestion is to drop the packet; 203 NM: Not marked. A packet in the NM state has not (yet) had its 204 marking state changed to the ThM or ETM states, but it may be 205 changed to one of these states by a node experiencing congestion 206 or pre-congestion; 208 ThM: Threshold-marked. Such a packet has had its marking state 209 changed by the threshold-meter function [RFC5670]; 211 ETM: Excess-traffic-marked. Such a packet has had its marking state 212 changed by the excess-traffic-meter function [RFC5670]. 214 Packets marked NM, ThM or ETM are termed PCN-packets. Their entry 215 into the pcn-domain is controlled by edge nodes that understand how 216 to process PCN markings [RFC5559]. 218 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 220 To be compliant with the 3-in-1 PCN Encoding, an PCN interior node 221 behaves as follows: 223 o Except where explicitly stated otherwise, it MUST comply with the 224 basealine encoding specified in [RFC5696] 226 o It MUST change NM TO ThM if the threshold-meter function indicates 227 to mark the packet. 229 o It MUST change NM or ThM TO ETM if the excess-traffic-meter 230 function indicates to mark the packet. 232 o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT 233 change a PCN-Enabled codepoint to Not-PCN; 235 o It MUST NOT change ThM to NM; 237 o It MUST NOT change ETM to ThM or to NM; 239 In other words, a PCN interior node may increase the severity of 240 packet marking but it MUST NOT decrease it, where the order of 241 severity increases from NM through ThM to ETM. 243 6. IANA Considerations 245 This memo includes no request to IANA. 247 Note to RFC Editor: this section may be removed on publication as an 248 RFC. 250 7. Security Considerations 252 The security concerns relating to this extended PCN encoding are the 253 same as those in [RFC5696]. 255 8. Conclusions 257 The 3-in-1 PCN Encoding provides three states to encode PCN markings 258 in the ECN field of an IP packet using just one Diffserv codepoint. 259 One state is for not marked packets while the two others are for PCN 260 nodes to mark packets with increasing levels of severity. Use of 261 this encoding presupposes that any tunnels in the PCN region have 262 been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. 264 9. Acknowledgements 266 Thanks to Phil Eardley for reviewing this. 268 10. Comments Solicited 270 To be removed by RFC Editor: Comments and questions are encouraged 271 and very welcome. They can be addressed to the IETF Congestion and 272 Pre-Congestion working group mailing list , and/or to 273 the authors. 275 11. References 277 11.1. Normative References 279 [I-D.ietf-tsvwg-ecn-tunnel] 280 Briscoe, B., "Tunnelling of Explicit Congestion 281 Notification", draft-ietf-tsvwg-ecn-tunnel-03 (work in 282 progress), July 2009. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 288 "Definition of the Differentiated Services Field (DS 289 Field) in the IPv4 and IPv6 Headers", RFC 2474, 290 December 1998. 292 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 293 of Explicit Congestion Notification (ECN) to IP", 294 RFC 3168, September 2001. 296 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 297 Architecture", RFC 5559, June 2009. 299 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 300 Nodes", RFC 5670, November 2009. 302 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 303 Encoding and Transport of Pre-Congestion Information", 304 RFC 5696, November 2009. 306 11.2. Informative References 308 [I-D.ietf-pcn-3-state-encoding] 309 Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding 310 using 2 DSCPs to provide 3 or more states", 311 draft-ietf-pcn-3-state-encoding-00 (work in progress), 312 April 2009. 314 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 315 Internet Protocol", RFC 4301, December 2005. 317 Authors' Addresses 319 Bob Briscoe 320 BT 321 B54/77, Adastral Park 322 Martlesham Heath 323 Ipswich IP5 3RE 324 UK 326 Phone: +44 1473 645196 327 Email: bob.briscoe@bt.com 328 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 330 Toby Moncaster 331 BT 332 c/o B54/70, Adastral Park 333 Martlesham Heath 334 Ipswich IP5 3RE 335 UK 337 Phone: +44 1206 332805 338 Email: toby.moncaster@bt.com