idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-02.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 (March 08, 2010) is 5161 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-08 ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-02) exists of draft-ietf-pcn-3-state-encoding-01 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 March 08, 2010 6 Expires: September 9, 2010 8 PCN 3-State Encoding Extension in a single DSCP 9 draft-ietf-pcn-3-in-1-encoding-02 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 September 9, 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. Threshold-traffic-marking marks all PCN packets once they 85 exceed the threshold-traffic-rate on a link while Excess-traffic- 86 marking marks only those PCN packets that exceed the excess-traffic- 87 rate, which is higher than the threshold-traffic-rate [RFC5670]. 88 These marks are monitored by the egress 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-01 to -02: 108 * Corrected mistake in introduction, which wrongly stated that 109 the threshold-traffic rate is higher than the excess-traffic 110 rate. Other minor corrections. 112 * Updated acks & refs. 114 From draft-ietf-pcn-3-in-1-encoding-00 to -01: 116 * Altered the wording to make sense if 117 [I-D.ietf-tsvwg-ecn-tunnel] moves to proposed standard. 119 * References updated 121 From draft-briscoe-pcn-3-in-1-encoding-00 to 122 draft-ietf-pcn-3-in-1-encoding-00: 124 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 126 * Introduction altered to include new template description of 127 PCN. 129 * References updated. 131 * Terminology brought into line with [RFC5670]. 133 * Minor corrections. 135 2. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. The Requirement for Three PCN Encoding States 143 The PCN architecture [RFC5559] describes proposed PCN schemes that 144 expect traffic to be metered and marked using both Threshold and 145 Excess Traffic schemes. In order to achieve this it is necessary to 146 allow for three PCN encoding states: one as a Not Marked (NM) state 147 and the other two to distinguish these two levels of marking severity 148 [RFC5670]. The way tunnels processed the ECN field before 149 [I-D.ietf-tsvwg-ecn-tunnel] severely limited how to encode these 150 states. 152 The two bit ECN field seems to offer four possible encoding states, 153 but one (00) is set aside for traffic controlled by transports that 154 do not understand PCN marking [RFC5696], so it would be irregular and 155 risky to use it as a PCN encoding state. Of the three remaining ECN 156 codepoints, only one (11) can be introduced by a congested node 157 within a tunnel and still survive the decapsulation behaviour of a 158 tunnel egress not updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. 159 The two remaining codepoints are (10) and (01). But if a node within 160 the tunnel used either of these two remaining codepoints to try to 161 mark packets with a second severity level, a tunnel not updated to 162 comply with [I-D.ietf-tsvwg-ecn-tunnel] would remove this marking on 163 decapsulation. The ECN field was constrained to two marking states 164 in this way irrespective of which earlier ECN tunnelling 165 specification the tunnel complied with, whether regular IP in IP 166 tunnelling [RFC3168] or IPsec tunnelling [RFC4301]. 168 One way to provide another encoding state that survives tunnelling is 169 to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding]. 170 Instead, to avoid wasting scarce Diffserv codepoints, a network 171 operator can require tunnels in a PCN region to comply with 172 [I-D.ietf-tsvwg-ecn-tunnel], thus removing the constraints imposed by 173 earlier tunnelling specifications. 175 Therefore this document presupposes tunnels in the PCN region comply 176 with the newly proposed decapsulation rules defined in 177 [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard 178 tunnels no longer apply so this document can define a 3-state 179 encoding for PCN within one Diffserv codepoint. 181 4. The 3-in-1 PCN Encoding 183 The 3-in-1 PCN Encoding scheme is based closely on the baseline 184 encoding defined in [RFC5696] so that there will be no compatibility 185 issues if a PCN-domain evolves from using the baseline encoding 186 scheme to the experimental scheme described here. The exact manner 187 in which the PCN encoding states are carried in the IP header is 188 shown in Figure 1. 189 +--------+----------------------------------------------------+ 190 | | Codepoint in ECN field of IP header | 191 | DSCP | | 192 | +--------------+-------------+-------------+---------+ 193 | | 00 | 10 | 01 | 11 | 194 +--------+--------------+-------------+-------------+---------+ 195 | DSCP n | Not-PCN | NM | ThM | ETM | 196 +--------+--------------+-------------+-------------+---------+ 198 Figure 1: 3-in-1 PCN Encoding 200 In Figure 1 the 3 PCN states are encoded in the ECN field [RFC3168] 201 of an IP packet with its Diffserv field [RFC2474] set to DSCP n, 202 which is any PCN-Compatible DiffServ codepoint as defined in Section 203 4.2 of the PCN baseline encoding [RFC5696]). The PCN codepoint of a 204 packet defines its marking state as follows: 206 Not-PCN: The packet is controlled by a transport that does not 207 understand PCN marking, therefore the only valid action to notify 208 congestion is to drop the packet; 210 NM: Not marked. A packet in the NM state has not (yet) had its 211 marking state changed to the ThM or ETM states, but it may be 212 changed to one of these states by a node experiencing congestion 213 or pre-congestion; 215 ThM: Threshold-marked. Such a packet has had its marking state 216 changed by the threshold-meter function [RFC5670]; 218 ETM: Excess-traffic-marked. Such a packet has had its marking state 219 changed by the excess-traffic-meter function [RFC5670]. 221 Packets marked NM, ThM or ETM are termed PCN-packets. Their entry 222 into the pcn-domain is controlled by edge nodes that understand how 223 to process PCN markings [RFC5559]. 225 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 227 To be compliant with the 3-in-1 PCN Encoding, an PCN interior node 228 behaves as follows: 230 o Except where explicitly stated otherwise, it MUST comply with the 231 baseline encoding specified in [RFC5696] 233 o It MUST change NM to ThM if the threshold-meter function indicates 234 to mark the packet. 236 o It MUST change NM or ThM to ETM if the excess-traffic-meter 237 function indicates to mark the packet. 239 o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT 240 change a PCN-Enabled codepoint to Not-PCN; 242 o It MUST NOT change ThM to NM; 244 o It MUST NOT change ETM to ThM or to NM; 246 In other words, a PCN interior node may increase the severity of 247 packet marking but it MUST NOT decrease it, where the order of 248 severity increases from NM through ThM to ETM. 250 6. IANA Considerations 252 This memo includes no request to IANA. 254 Note to RFC Editor: this section may be removed on publication as an 255 RFC. 257 7. Security Considerations 259 The security concerns relating to this extended PCN encoding are the 260 same as those in [RFC5696]. 262 8. Conclusions 264 The 3-in-1 PCN Encoding provides three states to encode PCN markings 265 in the ECN field of an IP packet using just one Diffserv codepoint. 266 One state is for not marked packets while the two others are for PCN 267 nodes to mark packets with increasing levels of severity. Use of 268 this encoding presupposes that any tunnels in the PCN region have 269 been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. 271 9. Acknowledgements 273 Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Michael Menth for 274 reviewing this. 276 10. Comments Solicited 278 To be removed by RFC Editor: Comments and questions are encouraged 279 and very welcome. They can be addressed to the IETF Congestion and 280 Pre-Congestion working group mailing list , and/or to 281 the authors. 283 11. References 285 11.1. Normative References 287 [I-D.ietf-tsvwg-ecn-tunnel] 288 Briscoe, B., "Tunnelling of Explicit Congestion 289 Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in 290 progress), March 2010. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 296 "Definition of the Differentiated Services Field (DS 297 Field) in the IPv4 and IPv6 Headers", RFC 2474, 298 December 1998. 300 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 301 of Explicit Congestion Notification (ECN) to IP", 302 RFC 3168, September 2001. 304 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 305 Architecture", RFC 5559, June 2009. 307 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 308 Nodes", RFC 5670, November 2009. 310 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 311 Encoding and Transport of Pre-Congestion Information", 312 RFC 5696, November 2009. 314 11.2. Informative References 316 [I-D.ietf-pcn-3-state-encoding] 317 Briscoe, B., Moncaster, T., and M. Menth, "A PCN encoding 318 using 2 DSCPs to provide 3 or more states", 319 draft-ietf-pcn-3-state-encoding-01 (work in progress), 320 February 2010. 322 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 323 Internet Protocol", RFC 4301, December 2005. 325 Authors' Addresses 327 Bob Briscoe 328 BT 329 B54/77, Adastral Park 330 Martlesham Heath 331 Ipswich IP5 3RE 332 UK 334 Phone: +44 1473 645196 335 Email: bob.briscoe@bt.com 336 URI: http://bobbriscoe.net/ 338 Toby Moncaster 339 BT 340 c/o B54/70, Adastral Park 341 Martlesham Heath 342 Ipswich IP5 3RE 343 UK 345 Phone: +44 1206 332805 346 Email: toby.moncaster@bt.com