idnits 2.17.1 draft-moncaster-pcn-3-state-encoding-01.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.ii 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pcn-baseline-encoding]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5525 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-09 == Outdated reference: A later version (-07) exists of draft-ietf-pcn-baseline-encoding-02 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: Experimental B. Briscoe 5 Expires: September 10, 2009 BT & UCL 6 M. Menth 7 University of Wuerzburg 8 March 9, 2009 10 A three state extended PCN encoding scheme 11 draft-moncaster-pcn-3-state-encoding-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 10, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 Pre-congestion notification (PCN) is a mechanism designed to protect 60 the Quality of Service of inelastic flows. It does this by marking 61 packets when traffic load on a link is approaching or has exceeded a 62 threshold below the physical link rate. This baseline encoding 63 specified how two encoding states could be encoded into the IP 64 header. This document specified an extension to the baseline 65 encoding that enables three encoding states to be carried in the IP 66 header as well as enabling limited support for end-to-end ECN. 68 Status (to be removed by RFC Editor) 70 This memo is posted as an Internet-Draft with an intent to eventually 71 be published as an experimental RFC. The PCN Working Group will be 72 asked to adopt this memo as a Working Group document describing one 73 of several possible experimental PCN encoding schemes. The intention 74 is that the title of this document will change to avoid confusion 75 with the three state marking scheme. 77 Changes from previous drafts 79 From 00 to 01: 81 o Checked terminology for consistency with 82 [I-D.ietf-pcn-baseline-encoding] 84 o Minor editorial changes. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 90 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 91 4. The Requirement for Three PCN Encoding States . . . . . . . . 5 92 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 5 93 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 6 94 6.1. Basic Three State Encoding . . . . . . . . . . . . . . . . 6 95 6.2. Full Three State Encoding . . . . . . . . . . . . . . . . 7 96 6.2.1. Forwarding Traffic Out of the PCN-domain . . . . . . . 7 97 7. PCN domain support for the PCN extension encoding . . . . . . 8 98 7.1. End-to-End transport behaviour compliant with the PCN 99 extension encoding . . . . . . . . . . . . . . . . . . . . 8 100 7.2. PCN-boundary-node behaviour compliant with the PCN 101 extension encoding . . . . . . . . . . . . . . . . . . . . 9 102 7.2.1. Behaviour for packets belonging to a PCN-flow . . . . 9 103 7.2.2. Behaviour for packets belonging to a 104 PCN-enabled-ECN-flow . . . . . . . . . . . . . . . . . 9 105 7.3. PCN-interior-node behaviour compliant with the PCN 106 extension encoding . . . . . . . . . . . . . . . . . . . . 10 107 7.4. Behaviour of any PCN node compliant with the PCN 108 extension encoding . . . . . . . . . . . . . . . . . . . . 10 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 111 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 112 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 113 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 115 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 116 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 119 1. Introduction 121 Pre-congestion notification provides information to support admission 122 control and flow termination at the boundary nodes of a Diffserv 123 region in order to protect the quality of service (QoS) of inelastic 124 flows [I-D.ietf-pcn-architecture]. This is achieved by marking 125 packets on interior nodes according to some metering function 126 implemented at each node. Excess traffic marking marks PCN packets 127 that exceed a certain reference rate on a link while threshold 128 marking marks all PCN packets on a link when the PCN traffic rate 129 exceeds a higher reference rate. These marks are monitored by the 130 egress nodes of the PCN-domain. 132 The baseline encoding described in [I-D.ietf-pcn-baseline-encoding] 133 provides for deployment scenarios that only require two PCN encoding 134 states. This document describes an experimental extension to the 135 base-encoding in the IP header that adds two capabilities: 137 o the encoding of a third PCN encoding state in the IP header 139 o preservation of the end-to-end semantics of the ECN field even 140 though PCN uses the field within a PCN-region that interrupts the 141 end-to-end path 143 The second of these capabilities is optional and the reasons for 144 doing it are discussed in 146 2. Requirements notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 3. Terminology 154 Most of the terminology used in this document is defined either in 155 [I-D.ietf-pcn-architecture] or in [I-D.ietf-pcn-baseline-encoding]. 156 The following additional terms are defined in this document: 158 o PCN-flow - a flow covered by a reservation but which hasn't 159 signalled that it requires end-to-end ECN support. 161 o PCN-enabled-ECN-flow - a flow covered by reservation and for which 162 the end-to-end transport has explicitly negotiated ECN support 163 from the PCN-boundary-nodes. 165 o Not-Marked (xxx), where xxx represents a standard ECN codepoint - 166 packets that are PCN capable but carry no PCN mark. Also NM(xxx). 167 The (xxx) represents the ECN codepoint that the packet arrived 168 with at the PCN-ingress-node e.g. NM(CE) represents a PCN capable 169 packet that has no PCN marking but which arrived with the ECN bits 170 set to congestion experienced. 172 4. The Requirement for Three PCN Encoding States 174 The PCN architecture [I-D.ietf-pcn-architecture] describes proposed 175 PCN schemes that require traffic to be metered and marked using both 176 Threshold and Excess Traffic schemes. In order to achieve this it is 177 necessary to allow for three PCN encoding states. The constraints 178 imposed by the way tunnels process the ECN field severely limit how 179 to encode these states as explained in 180 [I-D.ietf-pcn-baseline-encoding] and [I-D.ietf-tsvwg-ecn-tunnel]. 181 The obvious way to provide one more encoding state than the base 182 encoding is through the use of an additional PCN-compatible DiffServ 183 codepoints. One aim of this document is to allow for experiments to 184 show whether such schemes are better than those that only employ two 185 PCN encoding states. As such, the additional DSCP will be taken from 186 as the EXP/LU pools defined in [RFC2474]. If the experiments 187 demonstrate that PCN schemes employing three encoding states are 188 significantly better than those only employing two then at a later 189 date IANA might be asked to assign a new PCN enabled DSCP from pool 190 1. 192 5. Adding Limited End-to-End ECN Support to PCN 194 [I-D.sarker-pcn-ecn-pcn-usecases] suggests a number of use-cases 195 where explicit preservation of end-to-end ECN semantics might be 196 needed across a PCN domain. One of the use-cases suggests that the 197 end-nodes might be running rate-adaptive codecs that would respond to 198 ECN marks by reducing their transmission rate. If the sending 199 transport sets the ECT codepoint, the setting of the ECN field as it 200 arrives at the PCN ingress node will need to be re-instated as it 201 leaves the PCN egress node. 203 If a PCN region is starting to suffer pre-congestion then it may make 204 sense to expose marks generated within the PCN region by forwarding 205 CE marks from the PCN egress to such a rate-adaptive endpoint. They 206 would be in addition to any CE marks generated elsewhere on the end- 207 to-end path. This would allow the endpoints to reduce the traffic 208 rate. This will in turn help to alleviate the pre-congestion, 209 potentially averting any need for call blocking or termination. 210 However, the 'leaking' of CE marks out of the PCN region is 211 potentially dangerous and could violate [RFC4774] if the end hosts 212 don't understand ECN (see section 18.1.4 of [RFC3168]). 214 Therefore, a PCN region can only support end-to-end ECN if the PCN 215 edge nodes are sure that the end-to-end transport is ECN-capable. 216 That way the PCN egress nodes can ensure that they only expose CE 217 marks to those receivers that will correctly interpret them as a 218 notification of congestion. The end-points may indicate they are 219 ECN-capable through some higher-layer signalling process that sets up 220 their reservation with the PCN boundary nodes. The exact process of 221 negotiation is beyond the scope of this document but is likely to 222 involve explicit two way signalling between the end-host and the PCN- 223 domain. 225 In the absence of such signalling the default behaviour of the PCN 226 egress node will be to clear the ECN field to 00 as in the baseline 227 PCN encoding [I-D.ietf-pcn-baseline-encoding]. 229 6. Encoding Three PCN States in IP 231 The three state PCN encoding scheme is based closely on that defined 232 in [I-D.ietf-pcn-baseline-encoding] so that there will be no 233 compatibility issues if a PCN-domain changes from using the baseline 234 encoding scheme to the experimental scheme described here. There are 235 two versions of the scheme. The basic three state scheme allows for 236 carrying both Threshold Marked (ThM) and Excess traffic MArked (ETM) 237 traffic. The full scheme additionally allows us to carry end-to-end 238 ECN. 240 6.1. Basic Three State Encoding 242 The following table shows how to encode the three PCN states in IP. 243 The authors spent some time trying to establish which way round to 244 put the two marked states before settling on this. Because it is 245 envisaged that DSCP 2 will be of lower priority than DSCP 1 the 246 change in marking from Threshold to Excess Traffic involves 247 downgrading the traffic which seems to be consistent with the 248 requirement that such changes should not be reversed. 250 +--------+--------------+-------------+-------------+---------+ 251 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 252 +--------+--------------+-------------+-------------+---------+ 253 | DSCP 1 | Not-PCN | NM | CU | ThM | 254 | DSCP 2 | Not-PCN | CU | CU | ETM | 255 +--------+--------------+-------------+-------------+---------+ 257 Where DSCP 1 is a PCN-compatible DiffServ codepoint (see 258 [I-D.ietf-pcn-baseline-encoding]) and DSCP 2 is a PCN-compatible DSCP 259 from the EXP/LU pools as defined in [RFC2474] 261 Table 1: Encoding three PCN states in IP 263 6.2. Full Three State Encoding 265 Table 2 shows how to additionally carry the end-to-end ECN state in 266 the IP header. 268 +--------+--------------+-------------+-------------+---------+ 269 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 270 +--------+--------------+-------------+-------------+---------+ 271 | DSCP 1 | Not-PCN | NM(Not-ECT) | NM(CE) | ThM | 272 | DSCP 2 | Not-PCN | NM(ECT(0)) | NM(ECT(1)) | ETM | 273 +--------+--------------+-------------+-------------+---------+ 275 Where DSCP 1 is a PCN-compatible DiffServ codepoint (see 276 [I-D.ietf-pcn-baseline-encoding]) and DSCP 2 is a PCN-compatible DSCP 277 from the EXP/LU pools as defined in [RFC2474] 279 Table 2: Encoding three PCN states in IP 281 The four different Not Marked (NM) states allow for the addition of 282 limited end-to-end ECN support as explained in the previous section. 284 Warning 286 6.2.1. Forwarding Traffic Out of the PCN-domain 288 As each packet exits the PCN-domain, the PCN-egress-node MUST check 289 whether it belongs to a PCN-enabled-ECN-flow. If it belongs to such 290 a flow then the following table shows how the ECN field should be re- 291 set. In addition all packets should have their DSCP reset to the 292 appropriate DSCP for the next hop. If the next hop is not another 293 PCN region this will not be a PCN-compatible DSCP, and by default 294 will be the best-efforts DSCP. Alterntively higher layer signalling 295 mechanisms may allow the DSCP that packets entered the PCN-domain 296 with to be re-instated. 298 +-------+-------------+-----------------+-----------------+---------+ 299 | DSCP | 00 | 10 | 01 | 11 | 300 +-------+-------------+-----------------+-----------------+---------+ 301 | DSCP | Not PCN --> | NM(Not-ECT) --> | NM(CE) --> CE | ThM --> | 302 | 1 | Not ECT | not-ECT | | CE | 303 | DSCP | Not PCN --> | NM(ECT(0)) --> | NM(ECT(1)) --> | ETM --> | 304 | 2 | Not ECT | ECT(0) | ECT(1) | CE | 305 +-------+-------------+-----------------+-----------------+---------+ 307 Where each cell gives the incoming PCN state and the outgoing ECN 308 state. 310 Table 3: Egress rules for resetting ECN field for PCN Enabled ECN 311 Flows 313 For packets belonging to a PCN-flow the ECN field MUST be reset to 314 not-ECT (00) as defined in [I-D.ietf-pcn-baseline-encoding]. 316 7. PCN domain support for the PCN extension encoding 318 PCN traffic MUST be marked with a DiffServ codepoint that indicates 319 PCN is enabled. To comply with the PCN extension encoding, this 320 codepoint is either a PCN-compatible DSCP assigned by IANA for use 321 with the baseline PCN encoding [I-D.ietf-pcn-baseline-encoding] or a 322 DSCP from pools 2 or 3 for experimental and local use [RFC2474]. The 323 exact choice of DSCP may vary between PCN-domains but MUST be fixed 324 within each PCN-domain. 326 All nodes within a PCN-domain MUST understand and support the three 327 PCN states of the PCN extension coding. Therefore if any PCN-node 328 does not support three PCN encoding states, any node in the same PCN- 329 domain MUST NOT be configured to use three PCN encoding states as 330 defined here. 332 7.1. End-to-End transport behaviour compliant with the PCN extension 333 encoding 335 Transports wishing to use both a reservation and end-to-end ECN MUST 336 establish that their path supports this combination. Support of end- 337 to-end ECN by PCN boundary nodes is OPTIONAL. Therefore transports 338 MUST check with both the PCN-ingress-node and PCN-egress-node for 339 each flow. The sending of such a request MUST NOT be taken to mean 340 the request has been granted. The PCN-boundary-nodes MAY choose to 341 inform the end-node of a successful request. The exact mechanism for 342 such negotiation is beyond the scope of this document. A transport 343 that receives no response or a negative response to a request to 344 support end-to-end ECN within a flow reservation MUST set the ECN 345 field of all subsequent packets in that flow to Not-ECT if it wishes 346 to guarantee that the flow will receive PCN treatment. 348 If a domain wishes to use the full scheme described in Table 2 all 349 nodes in that domain MUST be configured to understand the full 350 scheme. 352 7.2. PCN-boundary-node behaviour compliant with the PCN extension 353 encoding 355 o If both the PCN ingress and egress nodes support end-to-end ECN, 356 and the transport has successfully requested end-to-end ECN the 357 flow becomes a PCN-enabled-ECN-flow. 359 o If either of a PCN ingress-egress pair does not support end-to-end 360 ECN or if the end-to-end transport does not request support for 361 end-to-end ECN then the PCN-boundary-nodes MUST assume the packet 362 belongs to a PCN-flow. 364 7.2.1. Behaviour for packets belonging to a PCN-flow 366 o If a packet belongs to a PCN-flow arrives at the PCN-ingress-node 367 with its ECN field already marked as CE or ECT, it SHOULD be 368 dropped. Alternatively it MAY be downgraded to a lower (non-PCN) 369 service class or MAY be tunnelled through the PCN region. It MUST 370 NOT be admitted to the PCN region directly. 372 o When a packet belonging to a PCN-flow carrying the not-ECT 373 codepoint arrives at the PCN-ingress-node, the ECN field MUST be 374 set to ECT(0) (10) and the DiffServ field set to DSCP 1. 376 o When a packet belonging to a PCN-flow leaves the PCN-domain 377 through the PCN-egress-node, the ECN bits MUST be set to not-ECT 378 (00). 380 7.2.2. Behaviour for packets belonging to a PCN-enabled-ECN-flow 382 o When a packet belonging to a PCN-enabled-ECN-flow arrives at the 383 PCN-ingress-node, then the ECN field and DSCP MUST be set to the 384 appropriate NM(xxx) setting as shown in Table 2. 386 o When a packet belonging to a PCN-enabled-ECN-flow leaves the PCN- 387 region through a PCN-egress-node, the ECN bits MUST be set 388 according to Table 3 and the DSCP MUST be set to the appropriate 389 DSCP for the next hop as discussed in Section 6.2.1 above. 391 7.3. PCN-interior-node behaviour compliant with the PCN extension 392 encoding 394 o If a PCN interior node indicates that a packet is to be threshold 395 marked then the ThM codepoint MUST be set by changing the ECN bits 396 to 11 and ensuring the Diffserv field is set to DSCP1. 398 o If a PCN interior node indicates that a packet is to be excess 399 traffic marked then the EM codepoint MUST be set by changing the 400 ECN bits to 11 and ensuring the Diffserv field is set to DSCP2 as 401 defined above. 403 7.4. Behaviour of any PCN node compliant with the PCN extension 404 encoding 406 o PCN nodes MUST NOT change not-PCN to another codepoint and they 407 MUST NOT change a PCN-Capable codepoint to not-PCN. 409 o ThM MUST NOT be changed to NM. 411 o ETM MUST NOT be changed to ThM or to NM. 413 8. IANA Considerations 415 This document asks IANA to assign one DiffServ codepoint from Pool 2 416 or Pool 3 (for experimental/local use)[RFC2474]. Should any of the 417 three encoding state experimental PCN schemes prove sufficiently 418 successful then, at a later date, IANA will be requested in a later 419 document to assign a dedicated DiffServ codepoint from pool 1 for 420 standards use. 422 9. Security Considerations 424 The security concerns relating to this extended PCN encoding are 425 essentially the same as those in [I-D.ietf-pcn-baseline-encoding]. 427 This extension coding gives end-to-end support for the ECN nonce 428 [RFC3540], which is intended to protect the sender against the 429 receiver or against network elements concealing a congestion 430 experienced marking or a lost packet. PCN-based reservations 431 combined with end-to-end ECN are intended for partially inelastic 432 traffic using rate-adaptive codecs. Therefore the end-to-end 433 transport is unlikely to be TCP, but at this time the nonce has only 434 been defined for TCP transports. 436 10. Conclusions 438 This document describes an extended encoding scheme for PCN that 439 provides for three encoding states as well as support for end-to-end 440 ECN. The encoding scheme builds on the baseline encoding described 441 in [I-D.ietf-pcn-baseline-encoding]. Using this encoding scheme it 442 is possible for operators to conduct experiments to check whether the 443 addition of an extra encoding state will significantly improve the 444 performance of PCN. It will also allow experiments to determine 445 whether there is a need for end-to-end ECN support within the PCN- 446 domain (as against end-to-end ECN support through the use of IP-in-IP 447 tunnelling or by downgrading the traffic to a lower service class). 449 11. Acknowledgements 451 This document builds extensively on work done in the PCN working 452 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Joe 453 Babiarz and others. Full details of alternative schemes that were 454 considered for adoption can be found in the document 455 [I-D.chan-pcn-encoding-comparison]. 457 12. Comments Solicited 459 Comments and questions are encouraged and very welcome. They can be 460 addressed to the IETF Transport Area working group mailing list 461 , and/or to the authors. 463 13. References 465 13.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 471 Explicit Congestion Notification (ECN) Field", BCP 124, 472 RFC 4774, November 2006. 474 13.2. Informative References 476 [I-D.chan-pcn-encoding-comparison] 477 Chan, K., Karagiannis, G., Moncaster, T., Menth, M., 478 Eardley, P., and B. Briscoe, "Pre-Congestion Notification 479 Encoding Comparison", 480 draft-chan-pcn-encoding-comparison-04 (work in progress), 481 February 2008. 483 [I-D.ietf-pcn-architecture] 484 Eardley, P., "Pre-Congestion Notification (PCN) 485 Architecture", draft-ietf-pcn-architecture-09 (work in 486 progress), January 2009. 488 [I-D.ietf-pcn-baseline-encoding] 489 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 490 Encoding and Transport of Pre-Congestion Information", 491 draft-ietf-pcn-baseline-encoding-02 (work in progress), 492 February 2009. 494 [I-D.ietf-tsvwg-ecn-tunnel] 495 Briscoe, B., "Layered Encapsulation of Congestion 496 Notification", draft-ietf-tsvwg-ecn-tunnel-01 (work in 497 progress), October 2008. 499 [I-D.sarker-pcn-ecn-pcn-usecases] 500 Sarker, Z. and I. Johansson, "Usecases and Benefits of end 501 to end ECN support in PCN Domains", 502 draft-sarker-pcn-ecn-pcn-usecases-02 (work in progress), 503 November 2008. 505 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 506 "Definition of the Differentiated Services Field (DS 507 Field) in the IPv4 and IPv6 Headers", RFC 2474, 508 December 1998. 510 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 511 of Explicit Congestion Notification (ECN) to IP", 512 RFC 3168, September 2001. 514 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 515 Congestion Notification (ECN) Signaling with Nonces", 516 RFC 3540, June 2003. 518 Authors' Addresses 520 Toby Moncaster 521 BT 522 B54/70, Adastral Park 523 Martlesham Heath 524 Ipswich IP5 3RE 525 UK 527 Phone: +44 1473 648734 528 Email: toby.moncaster@bt.com 529 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 531 Bob Briscoe 532 BT & UCL 533 B54/77, Adastral Park 534 Martlesham Heath 535 Ipswich IP5 3RE 536 UK 538 Phone: +44 1473 645196 539 Email: bob.briscoe@bt.com 541 Michael Menth 542 University of Wuerzburg 543 room B206, Institute of Computer Science 544 Am Hubland 545 Wuerzburg D-97074 546 Germany 548 Phone: +49 931 888 6644 549 Email: menth@informatik.uni-wuerzburg.de