idnits 2.17.1 draft-briscoe-pcn-3-in-1-encoding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 340. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5660 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-pcn-marking-behaviour-01 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-01 == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-08 == Outdated reference: A later version (-07) exists of draft-ietf-pcn-baseline-encoding-01 == Outdated reference: A later version (-01) exists of draft-moncaster-pcn-3-state-encoding-00 == Outdated reference: A later version (-02) exists of draft-sarker-pcn-ecn-pcn-usecases-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre-Congestion B. Briscoe 3 Notification BT 4 Internet-Draft October 27, 2008 5 Intended status: Experimental 6 Expires: April 30, 2009 8 PCN 3-State Encoding Extension in a single DSCP 9 draft-briscoe-pcn-3-in-1-encoding-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Abstract 38 Pre-congestion notification (PCN) is a mechanism designed to protect 39 the quality of service of inelastic flows. It does this by marking 40 packets when traffic load on a link is approaching or has exceeded a 41 threshold below the physical link rate. This document specifies an 42 extension to the two-state PCN baseline encoding that enables three 43 encoding states to be carried in the IP header without using more 44 than one Diffserv codepoint. It presupposes a standards action has 45 removed the limit of two encoding states in current tunnelling 46 mechanisms. 48 1. Introduction 50 Pre-congestion notification provides information to support admission 51 control and flow termination at the boundary nodes of a Diffserv 52 region in order to protect the quality of service (QoS) of inelastic 53 flows [I-D.ietf-pcn-architecture]. This is achieved by marking 54 packets on interior nodes according to some metering function 55 implemented at each node. Excess traffic marking marks PCN packets 56 that exceed a certain reference rate on a link while threshold 57 marking marks all PCN packets on a link when the PCN traffic rate 58 exceeds a higher reference rate [I-D.ietf-pcn-marking-behaviour]. 59 These marks are monitored by the egress nodes of the PCN domain. 61 To fully support these two types of marking, three encoding states 62 are needed: one encoding for packets that are not marked plus two 63 encodings for the two types of marking. The baseline encoding 64 described in [I-D.ietf-pcn-baseline-encoding] provides for deployment 65 scenarios that only require two PCN encoding states using a single 66 Diffserv codepoint. This document describes an experimental 67 extension to the baseline-encoding that adds a third PCN encoding 68 state in the IP header, still using a single Diffserv codepoint. For 69 brevity it will be called the 3-in-1 PCN Encoding. 71 If more than three states are required, e.g. to support end-to-end 72 ECN as well as edge-to-edge PCN [I-D.sarker-pcn-ecn-pcn-usecases], 73 end-to-end ECN would have to be encapsulated in the inner header of a 74 tunnel through the PCN region, as outlined in 75 [I-D.ietf-pcn-architecture]. 77 General PCN-related terminology is defined in the PCN architecture 78 [I-D.ietf-pcn-architecture], and terminology specific to packet 79 encoding is defined in the PCN baseline encoding 80 [I-D.ietf-pcn-baseline-encoding]. 82 2. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 3. The Requirement for Three PCN Encoding States 90 The PCN architecture [I-D.ietf-pcn-architecture] describes proposed 91 PCN schemes that expect traffic to be metered and marked using both 92 Threshold and Excess Traffic schemes. In order to achieve this it is 93 necessary to allow for three PCN encoding states: one as a Not Marked 94 (NM) state and the other two to distinguish these two levels of 95 marking severity. The way tunnels process the ECN field severely 96 limits how to encode these states. 98 The two bit ECN field seems to offer four possible encoding states, 99 but one (00) is set aside for traffic controlled by transports that 100 do not understand PCN marking, so it would be irregular to use it as 101 a PCN encoding state. Of the three remaining ECN codepoints, only 102 one (11) can be introduced by a congested node within a tunnel and 103 still survive the decapsulation behaviour of a tunnel egress as 104 currently standardised. The two remaining codepoints are (10) and 105 (01). But if a node within the tunnel used either of these two 106 remaining codepoints to try to mark packets with a second severity 107 level, this marking would be removed on decapsulation. The ECN field 108 is constrained to two marking states in this way irrespective of 109 whether regular IP in IP tunnelling [RFC3168] or IPsec tunnelling 110 [RFC4301] is used. 112 One way to provide another encoding state that survives tunnelling is 113 to use a second Diffserv codepoint 114 [I-D.moncaster-pcn-3-state-encoding]. Instead, to avoid wasting 115 scarce Diffserv codepoints, we could modify standard tunnels in the 116 PCN region to remove the constraints imposed by standard tunnelling. 118 Therefore this document presupposes tunnels in the PCN region comply 119 with the newly proposed Comprehensive Decapsulation Rules defined in 120 Appendix C of [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of 121 standard tunnels no longer apply so this document can define a 122 3-state encoding for PCN within one Diffserv codepoint. 124 Note that [I-D.ietf-tsvwg-ecn-tunnel] only records the Comprehensive 125 Decapsulation Rules in an appendix, solely to allow us to discuss 126 whether they should be brought on to the standards track. So, if 127 they are not, the offending tunnelling constraints might not be 128 removed. However, [I-D.ietf-tsvwg-ecn-tunnel] carefully establishes 129 that the constraints imposed by standard tunnelling are actually 130 unnecessary; they are merely the result of an unfortunate sequence of 131 historical events. Then the analysis in Appendix C of 132 [I-D.ietf-tsvwg-ecn-tunnel] shows that the proposed new rules would 133 not introduce any compatibility issues; they only affect one 134 combination of inner and outer header which has never occured under 135 any legal transitions of any IETF tunnelling schemes. Therefore it 136 is a reasonable working assumption for the purposes of this document 137 that tunnelling constraints will one day be removed. 139 4. The 3-in-1 PCN Encoding 141 The 3-in-1 PCN Encoding scheme is based closely on that defined in 142 [I-D.ietf-pcn-baseline-encoding] so that there will be no 143 compatibility issues if a PCN-domain evolves from using the baseline 144 encoding scheme to the experimental scheme described here. The exact 145 manner in which the PCN encoding states are carried in the IP header 146 is shown in Table 1. 148 Codepoint in ECN field of IP header 149 151 +--------+--------------+-------------+-------------+---------+ 152 | DSCP | 00 | 10 | 01 | 11 | 153 +--------+--------------+-------------+-------------+---------+ 154 | DSCP n | Not-PCN | NM | ThM | ETM | 155 +--------+--------------+-------------+-------------+---------+ 157 Table 1: 3-in-1 PCN Encoding 159 In Table 1 the 3 PCN states are encoded in the ECN field ([RFC3168]) 160 of an IP packet with its Diffserv field ([RFC2474]) set to DSCP n, 161 which is any PCN-Compatible DiffServ codepoint as defined in Section 162 4.2 of the PCN baseline encoding [I-D.ietf-pcn-baseline-encoding]). 163 The PCN codepoint of a packet defines its marking state as follows: 165 Not-PCN: The packet is controlled by a transport that does not 166 understand PCN marking, therefore the only valid action to notify 167 congestion is to drop the packet; 169 NM: Not marked. A packet in the NM state has not (yet) had its 170 marking state changed to the ThM or ETM states, but it may be 171 changed to one of these states by a node experiencing congestion 172 or pre-congestion; 174 ThM: Threshold marked. Such a packet has had its marking state 175 changed by the threshold marking algorithm 176 [I-D.ietf-pcn-marking-behaviour]; 178 ETM: Excess traffic marking. Such a packet has had its marking 179 state changed by the excess rate marking algorithm 180 [I-D.ietf-pcn-marking-behaviour]. 182 Packets marked NM, ThM or ETM are termed PCN-Enabled packets because 183 they are controlled by edge nodes that understand how to process PCN 184 markings. 186 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 188 To be compliant with the 3-in-1 PCN Encoding, an PCN interior node 189 behaves as follows: 191 o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT 192 change a PCN-Enabled codepoint to Not-PCN; 194 o It MUST NOT change ThM to NM; 196 o It MUST NOT change ETM to ThM or to NM; 198 In other words, a PCN interior node may increase the severity of 199 packet marking but it MUST NOT decrease it, where the order of 200 severity increases from NM through ThM to ETM. 202 6. IANA Considerations 204 This memo includes no request to IANA. 206 Note to RFC Editor: this section may be removed on publication as an 207 RFC. 209 7. Security Considerations 211 The security concerns relating to this extended PCN encoding are 212 essentially the same as those in [I-D.ietf-pcn-baseline-encoding]. 214 8. Conclusions 216 The 3-in-1 PCN Encoding provides three states to encode PCN markings 217 in the ECN field of an IP packet using just one Diffserv codepoint. 218 One state is for not marked packets while the two others are for PCN 219 nodes to mark packets with increasing levels of severity. Use of the 220 encoding presupposes that any tunnels in the PCN region have been 221 updated to use proposed Comprehensive Decapsulation Rules because 222 standard tunnel decapsulation rules unnecessarily constrain PCN 223 marking. 225 9. Acknowledgements 227 Thanks to Phil Eardley for reviewing this. 229 10. Comments Solicited 231 Comments and questions are encouraged and very welcome. They can be 232 addressed to the IETF Congestion and Pre-Congestion working group 233 mailing list , and/or to the authors. 235 11. References 237 11.1. Normative References 239 [I-D.ietf-pcn-marking-behaviour] 240 Eardley, P., "Marking behaviour of PCN-nodes", 241 draft-ietf-pcn-marking-behaviour-01 (work in progress), 242 October 2008. 244 [I-D.ietf-tsvwg-ecn-tunnel] 245 Briscoe, B., "Layered Encapsulation of Congestion 246 Notification", draft-ietf-tsvwg-ecn-tunnel-01 (work in 247 progress), October 2008. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 253 "Definition of the Differentiated Services Field (DS 254 Field) in the IPv4 and IPv6 Headers", RFC 2474, 255 December 1998. 257 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 258 of Explicit Congestion Notification (ECN) to IP", 259 RFC 3168, September 2001. 261 11.2. Informative References 263 [I-D.ietf-pcn-architecture] 264 Eardley, P., "Pre-Congestion Notification (PCN) 265 Architecture", draft-ietf-pcn-architecture-08 (work in 266 progress), October 2008. 268 [I-D.ietf-pcn-baseline-encoding] 269 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 270 Encoding and Transport of Pre-Congestion Information", 271 draft-ietf-pcn-baseline-encoding-01 (work in progress), 272 October 2008. 274 [I-D.moncaster-pcn-3-state-encoding] 275 Moncaster, T., Briscoe, B., and M. Menth, "A three state 276 extended PCN encoding scheme", 277 draft-moncaster-pcn-3-state-encoding-00 (work in 278 progress), June 2008. 280 [I-D.sarker-pcn-ecn-pcn-usecases] 281 Sarker, Z. and I. Johansson, "Usecases and Benefits of end 282 to end ECN support in PCN Domains", 283 draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress), 284 May 2008. 286 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 287 Internet Protocol", RFC 4301, December 2005. 289 Author's Address 291 Bob Briscoe 292 BT 293 B54/77, Adastral Park 294 Martlesham Heath 295 Ipswich IP5 3RE 296 UK 298 Phone: +44 1473 645196 299 Email: bob.briscoe@bt.com 300 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 302 Full Copyright Statement 304 Copyright (C) The IETF Trust (2008). 306 This document is subject to the rights, licenses and restrictions 307 contained in BCP 78, and except as set forth therein, the authors 308 retain all their rights. 310 This document and the information contained herein are provided on an 311 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 312 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 313 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 314 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 315 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 316 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 318 Intellectual Property 320 The IETF takes no position regarding the validity or scope of any 321 Intellectual Property Rights or other rights that might be claimed to 322 pertain to the implementation or use of the technology described in 323 this document or the extent to which any license under such rights 324 might or might not be available; nor does it represent that it has 325 made any independent effort to identify any such rights. Information 326 on the procedures with respect to rights in RFC documents can be 327 found in BCP 78 and BCP 79. 329 Copies of IPR disclosures made to the IETF Secretariat and any 330 assurances of licenses to be made available, or the result of an 331 attempt made to obtain a general license or permission for the use of 332 such proprietary rights by implementers or users of this 333 specification can be obtained from the IETF on-line IPR repository at 334 http://www.ietf.org/ipr. 336 The IETF invites any interested party to bring to its attention any 337 copyrights, patents or patent applications, or other proprietary 338 rights that may cover technology that may be required to implement 339 this standard. Please address the information to the IETF at 340 ietf-ipr@ietf.org. 342 Acknowledgment 344 This document was produced using xml2rfc v1.33 (of 345 http://xml.resource.org/) from a source in RFC-2629 XML format.