idnits 2.17.1 draft-ietf-pcn-baseline-encoding-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. 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 14, 2008) is 5666 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-moncaster-pcn-3-state-encoding-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre Congestion T. Moncaster 3 Internet-Draft BT 4 Intended status: Standards Track B. Briscoe 5 Expires: April 17, 2009 BT & UCL 6 M. Menth 7 University of Wuerzburg 8 October 14, 2008 10 Baseline Encoding and Transport of Pre-Congestion Information 11 draft-ietf-pcn-baseline-encoding-01 13 Status of This Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 17, 2009. 38 Abstract 40 Pre-congestion notification (PCN) provides information to support 41 admission control and flow termination in order to protect the 42 Quality of Service of inelastic flows. It does this by marking 43 packets when traffic load on a link is approaching or has exceeded a 44 threshold below the physical link rate. This document specifies how 45 such marks are to be encoded into the IP header. The baseline 46 encoding described here provides for only two PCN encoding states. 47 It is designed to be easily extended to provide more encoding states 48 but such schemes will be described in other documents. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 5 56 4.1. Rationale for Encoding . . . . . . . . . . . . . . . . . . 5 57 4.2. PCN-Compatible DiffServ Codepoints . . . . . . . . . . . . 6 58 5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 6 59 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 8 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 12.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Appendix A. Tunnelling Constraints . . . . . . . . . . . . . . . 9 69 Appendix B. PCN Node Behaviours . . . . . . . . . . . . . . . . . 10 70 Appendix C. Deployment Scenarios for PCN Using Baseline 71 Encoding . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Pre-congestion notification (PCN) provides information to support 76 admission control and flow termination in order to protect the 77 quality of service (QoS) of inelastic flows. This is achieved by 78 marking packets according to the level of pre-congestion at nodes 79 within a PCN-domain. These markings are evaluated by the egress 80 nodes of the PCN-domain. [pcn-arch] describes how PCN packet markings 81 can be used to assure the QoS of inelastic flows within a single 82 DiffServ domain. 84 This document specifies how these PCN marks are encoded into the IP 85 header. It also describes how packets are identified as belonging to 86 a PCN flow. Some deployment models require two PCN encoding states, 87 others require more. The baseline encoding described here only 88 provides for two PCN encoding states. An extension of the baseline 89 encoding described in [PCN-3-enc-state] provides for three PCN 90 encoding states. Other extensions have also been suggested all of 91 which can build on the baseline encoding. In order to ensure 92 backward compatibility any alternative encoding schemes that claim 93 compliance with PCN standards MUST extend this baseline scheme. 95 Changes from previous drafts (to be removed by the RFC Editor): 97 From -00 to -01: 99 Added section on restrictions for extension encoding schemes. 101 Included table in Appendix showing encoding transitions at 102 different PCN nodes. 104 Checked for consistency of terminology. 106 Minor language changes for clarity. 108 Changes from previous filename 110 Filename changed from draft-moncaster-pcn-baseline-encoding. 112 Terminology changed for clarity (PCN-compatible DSCP and PCN- 113 enabled packet). 115 Minor changes throughout. 117 Modified meaning of ECT(1) state to EXP. 119 Moved text relevant to behaviour of nodes into appendix for later 120 transfer to new document on edge behaviours. 122 From draft-moncaster -01 to -02: 124 Minor changes throughout including tightening up language to 125 remain consistent with the PCN Architecture terminology 127 From draft-moncaster -00 to -01: 129 Change of title from "Encoding and Transport of (Pre-)Congestion 130 Information from within a DiffServ Domain to the Egress" 132 Extensive changes to Introduction and abstract. 134 Added a section on the implications of re-using a DSCP. 136 Added appendix listing possible operator scenarios for using this 137 baseline encoding. 139 Minor changes throughout. 141 2. Requirements notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Terminology 149 The following terms are used in this document: 151 o Not-PCN - packets that are not PCN-enabled. 153 o PCN-marked - codepoint indicating packets that have been marked at 154 a PCN-interior-node using some PCN marking behaviour. Also PM. 156 o Not-marked - codepoint indicating packets that are PCN-capable but 157 are not PCN-marked. Also NM. 159 o PCN-enabled codepoints - collective term for all the NM and PM 160 codepoints. 162 o PCN-compatible Diffserv codepoint - a Diffserv codepoint for which 163 the ECN field is used to carry PCN markings rather than [RFC3168] 164 markings. 166 In addition the document uses the terminology defined in [pcn-arch]. 168 4. Encoding two PCN States in IP 170 The PCN encoding states are defined using a combination of the DSCP 171 and ECN fields within the IP header. The baseline PCN encoding 172 closely follows the semantics of ECN [RFC3168]. It allows the 173 encoding of two PCN states: Not-Marked and PCN-Marked. It also 174 allows for traffic that is not PCN capable to be marked as such (not- 175 PCN). Given the scarcity of codepoints within the IP header the 176 baseline encoding leaves one codepoint free for experimental use. 177 The following table defines how to encode these states in IP: 179 +---------------+-------------+-------------+-------------+---------+ 180 | ECN codepoint | not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) | 181 | | (00) | | | | 182 +---------------+-------------+-------------+-------------+---------+ 183 | DSCP n | not-PCN | NM | EXP | PM | 184 +---------------+-------------+-------------+-------------+---------+ 186 Where DSCP n is a PCN-compatible DiffServ codepoint (see Section 4.2) 187 and EXP means available for Experimental use. 189 Table 1: Encoding PCN in IP 191 The following rules apply to all PCN traffic: 193 o PCN-traffic MUST be marked with a PCN-compatible DiffServ 194 Codepoint. To conserve DSCPs, DiffServ Codepoints SHOULD be 195 chosen that are already defined for use with admission controlled 196 traffic, such as the Voice-Admit codepoint defined in 197 [voice-admit]. Guidelines for mixing traffic-types within a PCN- 198 domain are given in [pcn-marking-behaviour]. 200 o Any packet that is not PCN-enabled (not-PCN) but which shares the 201 same DiffServ codepoint as PCN-enabled traffic MUST have the ECN 202 field equal to 00. 204 4.1. Rationale for Encoding 206 The exact choice of encoding was dictated by the constraints imposed 207 by existing IETF RFCs, in particular [RFC3168] and [RFC4774]. One of 208 the tightest constraints was the need for any PCN encoding to survive 209 being tunnelled through either an IP in IP tunnel or an IPSec Tunnel. 210 Appendix A explains this in detail. The main effect of this 211 constraint is that any PCN marking has to carry the 11 codepoint in 212 the ECN field. If the packet is being tunneled then only the 11 213 codepoint gets copied into the inner header upon decapsulation. An 214 additional constraint is the need to minimise the use of DiffServ 215 codepoints as there is a limited supply of standards track codepoints 216 remaining. Section 4.2 explains how we have minimised this still 217 further by reusing pre-existing Diffserv codepoint(s) such that non- 218 PCN traffic can still be distinguished from PCN traffic. There are a 219 number of factors that were considered before deciding to set 10 as 220 the NM state. These included similarity to ECN, presence of tunnels 221 within the domain, leakage into and out of PCN-domain and incremental 222 deployment. 224 The encoding scheme above seems to meet all these constraints and 225 ends up looking very similar to ECN. This is perhaps not surprising 226 given the similarity in architectural intent between PCN and ECN. 228 4.2. PCN-Compatible DiffServ Codepoints 230 Equipment complying with the baseline PCN encoding MUST allow PCN to 231 be enabled for certain Diffserv codepoints. This document defines 232 the term "PCN-compatible Diffserv codepoint" for such a DSCP. 233 Enabling PCN for a DSCP switches on PCN marking behaviour for packets 234 with that DSCP, but only if those packets also have their ECN field 235 set to indicate a codepoint other than not-PCN. 237 Enabling PCN marking behaviour disables any other marking behaviour 238 (e.g. enabling PCN disables the default ECN marking behaviour 239 introduced in [RFC3168]). All traffic scheduling and conditioning 240 behaviours are discussed in [pcn-marking-behaviour]. 242 5. Rules for Experimental Encoding Schemes 244 Any experimental encoding scheme MUST follow these rules to ensure 245 backward compatibility with this baseline scheme: 247 o The 00 codepoint in the ECN field MUST mean not-PCN. 249 o The 11 codepoint in the ECN field MUST mean PCN-marked (though 250 this doesn't exclude other codepoints from carrying the same 251 meaning). 253 o Once set the 11 codepoint in the ECN field MUST NOT be changed to 254 any other codepoint. 256 6. Backwards Compatibility 258 BCP 124 [RFC4774] gives guidelines for specifying alternative 259 semantics for the ECN field. It sets out a number of factors to be 260 taken into consideration. It also suggests various techniques to 261 allow the co-existence of default ECN and alternative ECN semantics. 262 The baseline encoding specified in this document defines PCN- 263 compatible DiffServ codepoints as no longer supporting the default 264 ECN semantics. As such this document is compatible with BCP 124. It 265 should be noted that this baseline encoding blocks end-to-end ECN 266 except where mechanisms are put in place to tunnel such traffic 267 across the PCN-domain. 269 7. IANA Considerations 271 This document makes no request to IANA. 273 8. Security Considerations 275 Packets claim entitlement to be PCN marked by carrying a PCN- 276 Compatible DSCP and a PCN-Enabled ECN codepoint. This encoding 277 document is intended to stand independently of the architecture used 278 to determine whether specific packets are authorised to be PCN 279 marked, which will be described in a future separate document on PCN 280 edge-node behaviour (see Appendix B). 282 The PCN working group has initially been chartered to only consider a 283 PCN-domain to be entirely under the control of one operator, or a set 284 of operators who trust each other [PCN-charter]. However there is a 285 requirement to keep inter-domain scenarios in mind when defining the 286 PCN encoding. One way to extend to multiple domains would be to 287 concatenate PCN-domains and use PCN-boundary-nodes back to back at 288 borders. Then any one domain's security against its neighbours would 289 be described as part of the proposed edge-node behaviour document. 291 One proposal on the table allows one to extend PCN across multiple 292 domains without PCN-boundary-nodes back-to-back at borders [re-PCN]. 293 It is believed that the encoding described here would be compatible 294 with the security framework described there. 296 9. Conclusions 298 This document defines the baseline PCN encoding utilising a 299 combination of a PCN-enabled DSCP and the ECN field in the IP header. 300 This baseline encoding allows the existence of two PCN encoding 301 states, not-Marked and PCN-Marked. It also allows for the co- 302 existence of competing traffic within the same DSCP so long as that 303 traffic doesn't require end-to-end ECN support. The encoding scheme 304 is conformant with [RFC4774]. 306 10. Acknowledgements 308 This document builds extensively on work done in the PCN working 309 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Anna 310 Charny, Joe Babiarz and others. Thanks to Ruediger Geib for 311 providing detailed comments on this document. 313 11. Comments Solicited 315 Comments and questions are encouraged and very welcome. They can be 316 addressed to the IETF congestion and pre-congestion working group 317 mailing list , and/or to the authors. 319 12. References 321 12.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to 324 Indicate Requirement Levels", BCP 14, 325 RFC 2119, March 1997. 327 [RFC4774] Floyd, S., "Specifying Alternate Semantics 328 for the Explicit Congestion Notification 329 (ECN) Field", BCP 124, RFC 4774, 330 November 2006. 332 [pcn-arch] Eardley, P., "Pre-Congestion Notification 333 (PCN) Architecture", 334 draft-ietf-pcn-architecture-07 (work in 335 progress), September 2008. 337 12.2. Informative References 339 [PCN-3-enc-state] Moncaster, T., Briscoe, B., and M. Menth, "A 340 three state extended PCN encoding scheme", 341 draft-moncaster-pcn-3-state-encoding-00 342 (work in progress), June 2008. 344 [PCN-charter] IETF, "IETF Charter for Congestion and Pre- 345 Congestion Notification Working Group". 347 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, 348 "The Addition of Explicit Congestion 349 Notification (ECN) to IP", RFC 3168, 350 September 2001. 352 [RFC4301] Kent, S. and K. Seo, "Security Architecture 353 for the Internet Protocol", RFC 4301, 354 December 2005. 356 [ecn-tunnelling] Briscoe, B., "Layered Encapsulation of 357 Congestion Notification", 358 draft-briscoe-tsvwg-ecn-tunnel-01 (work in 359 progress), July 2008. 361 [pcn-marking-behaviour] Eardley, P., "Marking behaviour of PCN- 362 nodes", draft-ietf-pcn-marking-behaviour-00 363 (work in progress), October 2008. 365 [re-PCN] Briscoe, B., "Emulating Border Flow Policing 366 using Re-ECN on Bulk Data", 367 draft-briscoe-re-pcn-border-cheat-00 (work 368 in progress), July 2007. 370 [voice-admit] Baker, F., Polk, J., and M. Dolly, "DSCPs 371 for Capacity-Admitted Traffic", 372 draft-ietf-tsvwg-admitted-realtime-dscp-04 373 (work in progress), February 2008. 375 Appendix A. Tunnelling Constraints 377 The rules that govern the behaviour of the ECN field for IP-in-IP 378 tunnels were defined in [RFC3168]. This allowed for two tunnel 379 modes. The limited functionality mode sets the outer header to not- 380 ECT, regardless of the value of the inner header, in other words 381 disabling ECN within the tunnel. The full functionality mode copies 382 the inner ECN field into the outer header if the inner header is not- 383 ECT or either of the 2 ECT codepoints. If the inner header is CE 384 then the outer header is set to ECT(0). On decapsulation, if the CE 385 codepoint is set on the outer header then this is copied into the 386 inner header. Otherwise the inner header is left unchanged. The 387 stated reason for blocking CE from being copied to the outer header 388 was to prevent this from being used as a covert channel through IPSec 389 tunnels. 391 The IPSec protocol [RFC4301] changed the ECN tunnelling rule to allow 392 IPSec tunnels to simply copy the inner header into the outer header. 393 On decapsulation the outer header is discarded and the ECN field is 394 only copied down if it is set to CE. 396 Because of the possible existence of tunnels, only CE (11) can be 397 used as a PCN marking as it is the only mark that will always survive 398 decapsulation. However there is a need for caution with all 399 tunneling within the PCN-domain. RFC3168 full functionality IP in IP 400 tunnels are expected to set the ECN field to ECT(0) if the inner ECN 401 field is set to CE. This leads to the possibility that some packets 402 within the PCN-domain that have already been marked may have that 403 mark concealed further into the domain. This is undesirable for many 404 PCN schemes and thus the PCN working group needs to decide whether to 405 advise against the use of full functionality RFC3168 IP in IP tunnels 406 within a PCN-domain to support the ongoing work within the Transport 407 Area to rationalise the behaviour of IP in IP tunnels in respect to 408 the ECN field and bring them in line with the behaviour of IPSec 409 tunnels [ecn-tunnelling]. 411 Appendix B. PCN Node Behaviours 413 The following table of valid and invalid transitions, while necessary 414 for the correct functioning of PCN they is not strictly part of the 415 encoding scheme. The PCN working group needs to decide whether to 416 include this in this baseline encoding or whether to transfer it to 417 an alternative document. 419 +-----------+-------------+-----------------+-----------------------+ 420 | PCN node | Codepoint | Valid codepoint | Invalid codepoint out | 421 | type | in | out | | 422 +-----------+-------------+-----------------+-----------------------+ 423 | ingress | Any | NM (or Not-PCN) | PM | 424 | interior | NM | NM or PM | not-PCN | 425 | interior | Not-PCN | Not-PCN | Any other codepoint | 426 | egress | Any | 00 | Any other codepoint * | 427 +-----------+-------------+-----------------+-----------------------+ 428 * Except where the egress node knows that other marks may be safely 429 exposed outside the PCN-domain (e.g. [PCN-3-enc-state]). 431 Table 2: Valid and Invalid Transitions at PCN nodes 433 It is also necessary to define a safe behaviour for baseline- 434 compliant nodes to follow should they unexpectedly encounter a packet 435 carrying the EXP (01) codepoint. The obvious safe behaviour would be 436 to treat this as if it were a NM packet but to raise an alarm at a 437 higher layer to check why the packet was there. An alternative safe 438 approach is to treat it as a not-PCN packet but this might jeopardise 439 partial deployment of any future experimental encoding scheme. 441 Appendix C. Deployment Scenarios for PCN Using Baseline Encoding 443 This appendix illustrates possible PCN deployment scenarios where the 444 baseline encoding can be used and also explain a case for which 445 baseline encoding is not sufficient. {Note this appendix is provided 446 for information only}. 448 1. an operator requires only admission control. Then admission 449 control is triggered from PCN-packets that are threshold-marked 450 and this baseline encdoding scheme suffices. 452 2. an operator requires only flow termination. Then flow 453 termination is triggered from PCN-packets that are excess- 454 traffic-marked and this baseline encdoding scheme suffices. 456 3. an operator requires both admission control and flow termination. 457 If both admission control and flow termination are triggered from 458 PCN-packets that are excess-traffic-marked then this baseline 459 encoding scheme suffices. 461 4. an operator requires both admission control triggered by packets 462 that are threshold-marked and flow termination triggered by 463 packets that are excess-traffic-marked. In this case the 464 baseline encoding provides insufficient encoding states to 465 achieve this. 467 Authors' Addresses 469 Toby Moncaster 470 BT 471 B54/70, Adastral Park 472 Martlesham Heath 473 Ipswich IP5 3RE 474 UK 476 Phone: +44 1473 648734 477 EMail: toby.moncaster@bt.com 479 Bob Briscoe 480 BT & UCL 481 B54/77, Adastral Park 482 Martlesham Heath 483 Ipswich IP5 3RE 484 UK 486 Phone: +44 1473 645196 487 EMail: bob.briscoe@bt.com 489 Michael Menth 490 University of Wuerzburg 491 room B206, Institute of Computer Science 492 Am Hubland 493 Wuerzburg D-97074 494 Germany 496 Phone: +49 931 888 6644 497 EMail: menth@informatik.uni-wuerzburg.de 499 Full Copyright Statement 501 Copyright (C) The IETF Trust (2008). 503 This document is subject to the rights, licenses and restrictions 504 contained in BCP 78, and except as set forth therein, the authors 505 retain all their rights. 507 This document and the information contained herein are provided on an 508 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 509 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 510 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 511 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 512 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 513 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 515 Intellectual Property 517 The IETF takes no position regarding the validity or scope of any 518 Intellectual Property Rights or other rights that might be claimed to 519 pertain to the implementation or use of the technology described in 520 this document or the extent to which any license under such rights 521 might or might not be available; nor does it represent that it has 522 made any independent effort to identify any such rights. Information 523 on the procedures with respect to rights in RFC documents can be 524 found in BCP 78 and BCP 79. 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use of 529 such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository at 531 http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention any 534 copyrights, patents or patent applications, or other proprietary 535 rights that may cover technology that may be required to implement 536 this standard. Please address the information to the IETF at 537 ietf-ipr@ietf.org. 539 Acknowledgement 541 This document was produced using xml2rfc v1.33 (of 542 http://xml.resource.org/) from a source in RFC-2629 XML format.