idnits 2.17.1 draft-moncaster-pcn-3-state-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. 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 (June 23, 2008) is 5784 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-03 == Outdated reference: A later version (-02) exists of draft-moncaster-pcn-baseline-encoding-01 Summary: 1 error (**), 0 flaws (~~), 3 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: Experimental B. Briscoe 5 Expires: December 25, 2008 BT & UCL 6 M. Menth 7 University of Wuerzburg 8 June 23, 2008 10 A three state extended PCN encoding scheme 11 draft-moncaster-pcn-3-state-encoding-00 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 December 25, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 Pre-congestion notification (PCN) is a mechanism designed to protect 45 the Quality of Service of inelastic flows. It does this by marking 46 packets when traffic load on a link is approaching or has exceeded a 47 threshold below the physical link rate. This baseline encoding 48 specified how two encoding states could be encoded into the IP 49 header. This document specified an extension to the baseline 50 encoding that enables three encoding states to be carried in the IP 51 header as well as enabling limited support for end-to-end ECN. 53 Status 55 This memo is posted as an Internet-Draft with an intent to eventually 56 be published as an experimental RFC. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. The Requirement for Three PCN Encoding States . . . . . . . . 4 64 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 4 65 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 5 66 6.1. Forwarding Traffic Out of the PCN-domain . . . . . . . . . 6 67 7. PCN domain support for the PCN extension encoding . . . . . . 6 68 7.1. End-to-End transport behaviour compliant with the PCN 69 extension encoding . . . . . . . . . . . . . . . . . . . . 7 70 7.2. PCN-boundary-node behaviour compliant with the PCN 71 extension encoding . . . . . . . . . . . . . . . . . . . . 7 72 7.2.1. Behaviour for packets belonging to a PCN-flow . . . . 7 73 7.2.2. Behaviour for packets belonging to a 74 PCN-enabled-ECN-flow . . . . . . . . . . . . . . . . . 8 75 7.3. PCN-interior-node behaviour compliant with the PCN 76 extension encoding . . . . . . . . . . . . . . . . . . . . 8 77 7.4. Behaviour of any PCN node compliant with the PCN 78 extension encoding . . . . . . . . . . . . . . . . . . . . 8 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 9 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 87 Appendix A. Tunnelling Constraints . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 89 Intellectual Property and Copyright Statements . . . . . . . . . . 13 91 1. Introduction 93 Pre-congestion notification provides information to support admission 94 control and flow termination at the boundary nodes of a Diffserv 95 region in order to protect the quality of service (QoS) of inelastic 96 flows [PCN-arch]. This is achieved by marking packets on interior 97 nodes according to some metering function implemented at each node. 98 Excess traffic marking marks PCN packets that exceed a certain 99 reference rate on a link while threshold marking marks all PCN 100 packets on a link when the PCN traffic rate exceeds a higher 101 reference rate. These marks are monitored by the egress nodes of the 102 PCN domain. 104 The baseline encoding described in [PCN-base-encode] provides for 105 deployment scenarios that only require two PCN encoding states. This 106 document describes an experimental extension to the base-encoding in 107 the IP header that adds two capabilities: 109 o the encoding of a third PCN encoding state in the IP header 111 o preservation of the end-to-end semantics of the ECN field even 112 though PCN uses the field within a PCN-region that interrupts the 113 end-to-end path 115 2. Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Terminology 123 Most of the terminology used in this document is defined either in 124 [PCN-arch] or in [PCN-base-encode]. The following additional terms 125 are defined in this document: 127 o PCN-flow - a flow covered by a reservation but which hasn't 128 signalled that it requires end-to-end ECN support. 130 o PCN-enabled-ECN-flow - a flow covered by reservation and for which 131 the end-to-end transport has explicitly negotiated ECN support 132 from the PCN-boundary-nodes. 134 o Not-Marked (xxx), where xxx represents a standard ECN codepoint - 135 packets that are PCN capable but carry no PCN mark. Also NM(xxx). 136 The (xxx) represents the ECN codepoint that the packet arrived 137 with at the PCN-ingress-node e.g. NM(CE) represents a PCN capable 138 packet that has no PCN marking but which arrived with the ECN bits 139 set to congestion experienced. 141 4. The Requirement for Three PCN Encoding States 143 The PCN architecture [PCN-arch] describes proposed PCN schemes that 144 require 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. The constraints imposed by the 147 way tunnels process the ECN field severely limit how to encode these 148 states as explained in [PCN-base-encode]. The obvious way to provide 149 one more encoding state than the base encoding is through the use of 150 an additional PCN enabled DiffServ codepoints. One aim of this 151 document is to allow for experiments to show whether such schemes are 152 better than those that only employ two PCN encoding states. As such 153 the additional DSCP will be taken from as the EXP/LU pools defined in 154 [RFC2474]. If the experiments demonstrate that PCN schemes employing 155 three encoding states are significantly better than those only 156 employing two then at a later date IANA might be asked to assign a 157 new PCN enabled DSCP from pool 1. 159 5. Adding Limited End-to-End ECN Support to PCN 161 [ecn-pcn-usecases] suggests a number of use-cases where explicit 162 preservation of end-to-end ECN semantics might be needed across a PCN 163 domain. One of the use-cases suggests that the end-nodes might be 164 running rate-adaptive codecs that would respond to ECN marks by 165 reducing their transmission rate. If the sending transport sets the 166 ECT codepoint, the setting of the ECN field as it arrives at the PCN 167 ingress node will need to be re-instated as it leaves the PCN egress 168 node. 170 If a PCN region is starting to suffer pre-congestion then it may make 171 sense to expose marks generated within the PCN region by forwarding 172 CE marks from the PCN egress to such a rate-adaptive endpoint., They 173 would be in addition to any CE marks generated elsewhere on the end- 174 to-end path. This would allow the endpoints to reduce the traffic 175 rate. This will in turn help to alleviate the pre-congestion, 176 potentially averting any need for call blocking or termination. 177 However, the 'leaking' of CE marks out of the PCN region is 178 potentially dangerous and could violate [RFC4774] if the end hosts 179 don't understand ECN (see section 18.1.4 of [RFC3168]). 181 Therefore, a PCN region can only support end-to-end ECN if the PCN 182 edge nodes are sure that the end-to-end transport is ECN-capable. 184 That way the PCN egress nodes can ensure that they only expose CE 185 marks to those receivers that will correctly interpret them as a 186 notification of congestion. The end-points may indicate they are 187 ECN-capable through some signalling process that sets up their 188 reservation with the PCN boundary nodes. The exact process of 189 negotiation is beyond the scope of this document but is likely to 190 involve explicit two way signalling between the end-host and the PCN- 191 domain. 193 In the absence of such signalling the default behaviour of the PCN 194 egress node will be to clear the ECN field to 00 as in the baseline 195 PCN encoding [PCN-base-encode]. 197 6. Encoding Three PCN States in IP 199 The three state PCN encoding scheme is based closely on that defined 200 in [PCN-base-encode] so that there will be no compatibility issues if 201 a PCN-domain changes from using the baseline encoding scheme to the 202 experimental scheme described here. The exact manner in which the 203 PCN encoding states are carried in the IP header is shown in Table 1. 204 In the following table ThM refers to packets that have been metered 205 and marked according to a Threshold Markins scheme and ETM refers to 206 packets that have been metered and marked according to an Excess 207 Traffic Marking scheme. 209 +--------+--------------+-------------+-------------+---------+ 210 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 211 +--------+--------------+-------------+-------------+---------+ 212 | DSCP 1 | Not-PCN | NM(Not-ECT) | NM(CE) | ThM | 213 | DSCP 2 | Not-PCN | NM(ECT(0)) | NM(ECT(1)) | ETM | 214 +--------+--------------+-------------+-------------+---------+ 216 Where DSCP 1 is a PCN-enabled DiffServ codepoint (see 217 [PCN-base-encode]) and DSCP 2 is a PCN-enabled-DSCP from the EXP/LU 218 pools as defined in [RFC2474] 220 Table 1: Encoding three PCN states in IP 222 The four different Not Marked (NM) states allow for the addition of 223 limited end-to-end ECN support as explained in the previous section. 225 Warning 226 6.1. Forwarding Traffic Out of the PCN-domain 228 As each packet exits the PCN-domain, the PCN-egress-node MUST check 229 whether it belongs to a PCN-enabled-ECN-flow. If it belongs to such 230 a flow then the following table shows how the ECN field should be re- 231 set. In addition all packets should have their DSCP reset to the 232 appropriate DSCP for the next hop. If the next hop is not another 233 PCN region this will not be a PCN enabled DSCP, and by default will 234 be the best-efforts DSCP. Alterntively higher layer signalling 235 mechanisms may allow the DSCP that packets entered the PCN-domain 236 with to be re-instated. 238 +-------+-------------+-----------------+-----------------+---------+ 239 | DSCP | 00 | 10 | 01 | 11 | 240 +-------+-------------+-----------------+-----------------+---------+ 241 | DSCP | Not PCN --> | NM(Not-ECT) --> | NM(CE) --> CE | ThM --> | 242 | 1 | Not ECT | not-ECT | | CE | 243 | DSCP | Not PCN --> | NM(ECT(0)) --> | NM(ECT(1)) --> | ETM --> | 244 | 2 | Not ECT | ECT(0) | ECT(1) | CE | 245 +-------+-------------+-----------------+-----------------+---------+ 247 Where each cell gives the incoming PCN state and the outgoing ECN 248 state. 250 Table 2: Egress rules for resetting ECN field for PCN Enabled ECN 251 Flows 253 For packets belonging to a PCN-flow the ECN field MUST be reset to 254 not-ECT (00) as defined in [PCN-base-encode]. 256 7. PCN domain support for the PCN extension encoding 258 PCN traffic MUST be marked with a DiffServ codepoint that indicates 259 PCN is enabled. To comply with the PCN extension encoding, this 260 codepoint is either a PCN enabled DSCP assigned by IANA for use with 261 the baseline PCN encoding [PCN-base-encode] or a DSCP from pools 2 or 262 3 for experimental and local use [RFC2474]. The exact DSCP may vary 263 between PCN-domains but MUST be fixed within each PCN-domain. 265 All nodes within a PCN-domain MUST understand and support the three 266 PCN states of the PCN extension coding. Therefore if any PCN-node 267 does not support three PCN encoding states, any node in the same PCN- 268 domain MUST NOT be configured to use three PCN encoding states as 269 defined here. 271 7.1. End-to-End transport behaviour compliant with the PCN extension 272 encoding 274 Transports wishing to use both a reservation and end-to-end ECN MUST 275 establish that their path supports this combination. Support of end- 276 to-end ECN by PCN boundary nodes is OPTIONAL. Therefore transports 277 MUST check with both the PCN-ingress-node and PCN-egress-node for 278 each flow. The sending of such a request MUST NOT be taken to mean 279 the request has been granted. The PCN-boundary-nodes MAY choose to 280 inform the end-node of a successful request. The exact mechanism for 281 such negotiation is beyond the scope of this document. A transport 282 that receives no response or a negative response to a request to 283 support end-to-end ECN within a flow reservation MUST set the ECN 284 field of all subsequent packets in that flow to Not-ECT if it wishes 285 to guarantee that the flow will receive PCN treatment. 287 7.2. PCN-boundary-node behaviour compliant with the PCN extension 288 encoding 290 o If both the PCN ingress and egress nodes support end-to-end ECN, 291 and the transport has successfully requested end-to-end ECN the 292 flow becomes a PCN-enabled-ECN-flow. 294 o If either of a PCN ingress-egress pair does not support end-to-end 295 ECN or if the end-to-end transport does not request support for 296 end-to-end ECN then the PCN-boundary-nodes MUST assume the packet 297 belongs to a PCN-flow. 299 7.2.1. Behaviour for packets belonging to a PCN-flow 301 o If a packet belongs to a PCN-flow arrives at the PCN-ingress-node 302 with its ECN field already marked as CE or ECT, it SHOULD be 303 dropped. Alternatively it MAY be downgraded to a lower (non-PCN) 304 service class or MAY be tunnelled through the PCN region. It MUST 305 NOT be admitted to the PCN region directly. 307 o When a packet belonging to a PCN-flow carrying the not-ECT 308 codepoint arrives at the PCN-ingress-node, the ECN field MUST be 309 set to ECT(0) (10) and the DiffServ field set to DSCP 1. 311 o When a packet belonging to a PCN-flow leaves the PCN-domain 312 through the PCN-egress-node, the ECN bits MUST be set to not-ECT 313 (00). 315 7.2.2. Behaviour for packets belonging to a PCN-enabled-ECN-flow 317 o When a packet belonging to a PCN-enabled-ECN-flow arrives at the 318 PCN-ingress-node, then the ECN field and DSCP MUST be set to the 319 appropriate NM(xxx) setting as shown in Table 1. 321 o When a packet belonging to a PCN-enabled-ECN-flow leaves the PCN- 322 region through a PCN-egress-node, the ECN bits MUST be set 323 according to Table 2 and the DSCP MUST be set to the appropriate 324 DSCP for the next hop as discussed in Section 6.1 above. 326 7.3. PCN-interior-node behaviour compliant with the PCN extension 327 encoding 329 o If a PCN interior node indicates that a packet is to be threshold 330 marked then the ThM codepoint MUST be set by changing the ECN bits 331 to 11 and ensuring the Diffserv field is set to DSCP1. 333 o If a PCN interior node indicates that a packet is to be excess 334 traffic marked then the EM codepoint MUST be set by changing the 335 ECN bits to 11 and ensuring the Diffserv field is set to DSCP2 as 336 defined above. 338 7.4. Behaviour of any PCN node compliant with the PCN extension 339 encoding 341 o PCN nodes MUST NOT change not-PCN to another codepoint and they 342 MUST NOT change a PCN-Capable codepoint to not-PCN. 344 o ThM MUST NOT be changed to NM. 346 o ETM MUST NOT be changed to ThM or to NM. 348 8. IANA Considerations 350 This document asks IANA to assign one DiffServ codepoint from Pool 2 351 or Pool 3 (for experimental/local use)[RFC2474]. Should any of the 352 three encoding state experimental PCN schemes prove sufficiently 353 successful then, at a later date, IANA will be requested in a later 354 document to assign a dedicated DiffServ codepoint from pool 1 for 355 standards use. 357 9. Security Considerations 359 The security concerns relating to this extended PCN encoding are 360 essentially the same as those in [PCN-base-encode]. 362 This extension coding gives end-to-end support for the ECN nonce 363 [RFC3540], which is intended to protect the sender against the 364 receiver or against network elements concealing a congestion 365 experienced marking or a lost packet. PCN-based reservations 366 combined with end-to-end ECN are intended for partially inelastic 367 traffic using rate-adaptive codecs. Therefore the end-to-end 368 transport is unlikely to be TCP, but at this time the nonce has only 369 been defined for TCP transports. 371 10. Conclusions 373 This document describes an extended encoding scheme for PCN that 374 provides for three encoding states as well as support for end-to-end 375 ECN. The encoding scheme builds on the baseline encoding described 376 in [PCN-base-encode]. Using this encoding scheme it is possible for 377 operators to conduct experiments to check whether the addition of an 378 extra encoding state will significantly improve the performance of 379 PCN. It will also allow experiments to determine whether there is a 380 need for end-to-end ECN support within the PCN-domain (as against 381 end-to-end ECN support through the use of IP-in-IP tunnelling or by 382 downgrading the traffic to a lower service class). 384 11. Acknowledgements 386 This document builds extensively on work done in the PCN working 387 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Joe 388 Babiarz and others. Full details of alternative schemes that were 389 considered for adoption can be found in the document 390 [pcn-enc-compare]. 392 12. Comments Solicited 394 Comments and questions are encouraged and very welcome. They can be 395 addressed to the IETF Transport Area working group mailing list 396 , and/or to the authors. 398 13. References 400 13.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 406 Explicit Congestion Notification (ECN) Field", BCP 124, 407 RFC 4774, November 2006. 409 13.2. Informative References 411 [PCN-arch] 412 Eardley, P., "Pre-Congestion Notification Architecture", 413 draft-ietf-pcn-architecture-03 (work in progress), 414 February 2008. 416 [PCN-base-encode] 417 Moncaster, T., Briscoe, B., and M. Menth, "A three state 418 extended PCN encoding scheme", 419 draft-moncaster-pcn-baseline-encoding-01 (work in 420 progress), June 2008. 422 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 423 "Definition of the Differentiated Services Field (DS 424 Field) in the IPv4 and IPv6 Headers", RFC 2474, 425 December 1998. 427 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 428 of Explicit Congestion Notification (ECN) to IP", 429 RFC 3168, September 2001. 431 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 432 Congestion Notification (ECN) Signaling with Nonces", 433 RFC 3540, June 2003. 435 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 436 Internet Protocol", RFC 4301, December 2005. 438 [ecn-pcn-usecases] 439 Sarker, Z. and I. Johansson, "Usecases and Benefits of end 440 to end ECN support in PCN Domains", 441 draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress), 442 May 2008. 444 [pcn-enc-compare] 445 Chan, K., Karagiannis, G., Moncaster, T., Menth, M., 446 Eardley, P., and B. Briscoe, "Pre-Congestion Notification 447 Encoding Comparison", 448 draft-chan-pcn-encoding-comparison-03 (work in progress), 449 February 2008. 451 Appendix A. Tunnelling Constraints 453 The rules that govern the behaviour of the ECN field for IP-in-IP 454 tunnels were defined in [RFC3168]. This allowed for two tunnel modes 455 to exist. The limited functionality mode sets the outer header to 456 Not ECT, regardless of the value of the inner header. The full 457 functionality mode copies the inner ECN field into the outer header 458 if the inner header is Not ECT or either of the 2 ECT codepoints. If 459 the inner header is CE then the outer header is set to ECT(0). On 460 decapsulation, if the CE codepoint is set on the outer header then 461 this is copied into the inner header. Otherwise the inner header is 462 left unchanged. The reason for blocking CE from being copied to the 463 outer header was to prevent this from being used as a covert channel 464 through IPSec tunnels. 466 The IPSec protocol [RFC4301] changed the ECN tunnelling rule to allow 467 IPSec tunnels to simply copy the inner header into the outer header. 468 This was because the security community had decided the available 469 bandwidth of the covert channel offered by ECN was too low to be a 470 significant threat. On decapsulation the outer header is discarded 471 and the ECN field is only copied down if it is set to CE. Because of 472 the possible existence of tunnels, only CE (11) can be used as a PCN 473 marking as it is the only mark that will survive decapsulation. 475 There is a further issue involving tunnelling. In [RFC3168], IP in 476 IP tunnels are expected to set the ECN field to ECT(0) if the inner 477 ECN field is set to CE. This leads to the possibility that some 478 packets within the PCN field that have already been marked may have 479 that mark concealed further into the region. This is undesirable for 480 many PCN schemes and thus standard IP in IP tunnels SHOULD NOT be 481 used within a PCN region. 483 Authors' Addresses 485 Toby Moncaster 486 BT 487 B54/70, Adastral Park 488 Martlesham Heath 489 Ipswich IP5 3RE 490 UK 492 Phone: +44 1473 648734 493 Email: toby.moncaster@bt.com 494 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 495 Bob Briscoe 496 BT & UCL 497 B54/77, Adastral Park 498 Martlesham Heath 499 Ipswich IP5 3RE 500 UK 502 Phone: +44 1473 645196 503 Email: bob.briscoe@bt.com 505 Michael Menth 506 University of Wuerzburg 507 room B206, Institute of Computer Science 508 Am Hubland 509 Wuerzburg D-97074 510 Germany 512 Phone: +49 931 888 6644 513 Email: menth@informatik.uni-wuerzburg.de 515 Full Copyright Statement 517 Copyright (C) The IETF Trust (2008). 519 This document is subject to the rights, licenses and restrictions 520 contained in BCP 78, and except as set forth therein, the authors 521 retain all their rights. 523 This document and the information contained herein are provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 526 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 527 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 528 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 531 Intellectual Property 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Acknowledgments 557 Funding for the RFC Editor function is provided by the IETF 558 Administrative Support Activity (IASA). This document was produced 559 using xml2rfc v1.32 (of http://xml.resource.org/) from a source in 560 RFC-2629 XML format.