idnits 2.17.1 draft-scharf-tsvwg-quick-start-flow-control-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 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 567. 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 (July 2, 2007) is 6144 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Scharf 3 Internet-Draft University of Stuttgart 4 Intended status: Experimental S. Floyd 5 Expires: January 3, 2008 ICIR 6 P. Sarolahti 7 Nokia Research Center 8 July 2, 2007 10 Avoiding Interactions of Quick-Start TCP and Flow Control 11 draft-scharf-tsvwg-quick-start-flow-control-01.txt 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 January 3, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes methods to avoid interactions between the 45 flow control of the Transmission Control Protocol (TCP) and the 46 Quick-Start TCP mechanism. Quick-Start is an optional TCP congestion 47 control extension that allows hosts to determine an allowed sending 48 rate from feedback of routers along the path. With Quick-Start, data 49 transfers can start with a potentially large congestion window and 50 avoid the time-consuming slow-start. In order to fully utilize the 51 data rate determined by Quick-Start, the sending host must not be 52 limited by the TCP flow control, i. e., the amount of free buffer 53 space advertised by the receive window. 55 There are two potential interactions between Quick-Start and the TCP 56 flow control: First, receivers might not provide sufficiently large 57 buffer space after connection setup, or they may implement buffer 58 allocation strategies that implicitly assume the slow-start behavior 59 on the sender side. This document therefore provides guidelines for 60 buffer allocation in hosts supporting the Quick-Start extension. 61 Second, the TCP receive window scaling mechanism interferes with 62 Quick-Start when being used in the initial three-way handshake 63 connection setup. This document describes a simple solution to 64 overcome this problem. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 70 3. Quick-Start TCP and Receive Buffer Dimensioning . . . . . . . 5 71 3.1. Receiver Buffer Allocation Strategies . . . . . . . . . . 5 72 3.2. Recommendations for Buffer Dimensioning in Presence of 73 Quick-Start Requests . . . . . . . . . . . . . . . . . . . 5 74 4. Quick-Start TCP and Receive Window Scaling . . . . . . . . . . 6 75 4.1. Receive Window Scaling . . . . . . . . . . . . . . . . . . 6 76 4.2. Problem Within the Three-way Handshake . . . . . . . . . . 6 77 4.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 7 78 4.4. Discussion and Deployment Considerations . . . . . . . . . 9 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 Appendix A. Applicability to Other Proposals . . . . . . . . . . 12 86 Appendix B. Alternative Solutions . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Intellectual Property and Copyright Statements . . . . . . . . . . 14 90 1. Introduction 92 Quick-Start is an experimental extension for the Transmission Control 93 Protocol (TCP) [RFC0793] that allows to speed up best effort data 94 transfers. The Quick-Start TCP extension is specified in [RFC4782]. 95 With Quick-Start, TCP hosts can request permission from the routers 96 along a network path to send at a higher rate than allowed by the 97 default TCP congestion control, in particular during connection setup 98 or after longer idle periods. The explicit router feedback avoids 99 the time-consuming capacity probing by the TCP slow-start and can 100 significantly improve transfer times over paths with a high 101 bandwidth-delay product [SAF07]. 103 The usage of Quick-Start significantly changes the TCP behavior 104 during connection setup. This is why special care is needed in order 105 to prevent interactions between Quick-Start and other TCP mechanisms. 106 Specifically, TCP flow control mechanisms have to be optimized for 107 the usage of Quick-Start, in particular when the TCP connection spans 108 a path with a large bandwidth-delay product (BDP). In such cases 109 both congestion and receive window should have large values in order 110 to achieve good TCP performance (see [RFC2488],[RFC3481]). 112 Unlike the standard slow-start mechanism, the Quick-Start TCP 113 extension allows the sender to use large congestion windows 114 immediately after connection setup. The usage of such large windows 115 raises two questions: First, what receiver buffer allocation 116 strategies should be used in combination with Quick-Start? And 117 second, how to appropriately signal these large windows? This 118 document addresses these issues and shows that Quick-Start requires 119 special mechanisms in both cases. The document thereby supplements 120 the Quick-Start TCP specification [RFC4782], where flow control 121 issues have not been addressed in detail. 123 The rest of this document is structured as follows: First, the 124 question of receive buffer allocation in combination with Quick-Start 125 is addressed and dimensioning guidelines are provided. Second, a 126 modification of the receive window scaling mechanism [RFC1323] is 127 specified, which is required to fully benefit from Quick-Start when 128 the Quick-Start request is used in the initial segment. 130 2. Requirements Notation 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Quick-Start TCP and Receive Buffer Dimensioning 138 3.1. Receiver Buffer Allocation Strategies 140 A sender can transmit up to the minimum of the congestion window and 141 the receive window (also called receiver's advertised window) 142 [RFC2581]. A small receive window prevents the TCP connection from 143 fully utilizing paths with a larger bandwidth-delay product. As a 144 consequence, on the one hand, a TCP receiver should advertise a 145 receive window that is big enough to allow an efficient utilization 146 of the connection path. On the other hand, hosts with a potentially 147 high number of TCP connections need to optimize the buffer and memory 148 usage to be able to serve a maximum possible number of TCP 149 connections. Finding a fixed receive buffer size that is optimal 150 between these two goals is difficult. 152 This is why many modern TCP implementations use an intelligent 153 dynamic buffer management. There are different auto-tuning 154 techniques and heuristics [Dun06] designed to prevent the receive 155 window from limiting the data rate at the sender. An implementation 156 using buffer size auto-tuning is described for instance in [SB05]. A 157 common characteristic of most of these buffer allocation strategies 158 is that they initially start with a rather small receive window. The 159 more data arrives, the more buffer is allocated to the corresponding 160 connection. This behavior is reasonable if the sender uses the 161 standard slow-start algorithm and thus starts with a small congestion 162 window anyway. However, when using Quick-Start, a large receive 163 buffer may be required immediately after connection setup. 165 3.2. Recommendations for Buffer Dimensioning in Presence of Quick-Start 166 Requests 168 When a host receives and approves a Quick-Start request, in 169 particular during the connection setup, it SHOULD announce a receive 170 window that is large enough so that a potential Quick-Start data 171 transfer can start with a high sending window. If buffer size auto- 172 tuning is used, it SHOULD be ensured that a sufficiently high initial 173 receive window is announced. The handling of buffer space upon 174 arrival of a Quick-Start request SHOULD be configurable by the 175 corresponding application. 177 If the TCP host has sufficient receive buffer space, it could 178 estimate the required buffer space as the product of the approved 179 Quick-Start rate and the round-trip time, and advertise a receive 180 window based on this required buffer space. This receive window 181 should allow the other TCP host to fully use the approved Quick-Start 182 Request. 184 If the TCP host doesn't know the round-trip time, the TCP host could 185 use an estimate of the round-trip time in calculating the required 186 buffer space. For instance, the buffer dimension could be done for a 187 configurable "worst-case" RTT such as 500 ms. Alternately, the TCP 188 host could base the advertised receive window on the available buffer 189 space, without calculating the buffer space required for the other 190 TCP host to fully use the approved Quick-Start Request. 192 4. Quick-Start TCP and Receive Window Scaling 194 4.1. Receive Window Scaling 196 The TCP header specified in [RFC0793] uses a 16 bit field to report 197 the receive window size to the sender. This effectively limits the 198 sending window to 64 KB. To circumvent this problem, the "Window 199 Scale" TCP extension [RFC1323] defines an implicit scale factor, 200 which is used to multiply the window size value found in a TCP header 201 to obtain a 32 bit window size. If enabled, the scale factor is 202 announced during connection setup by the "Window Scale" TCP option in 203 and segments. 205 In general, using receive window scaling is highly beneficial for TCP 206 connections over path with a large bandwidth-delay product 207 [RFC2488],[RFC3481]. Otherwise, the path capacity cannot fully be 208 utilized by TCP. Quick-Start TCP can significantly speed up data 209 transfers over such paths [RFC4782],[SAF07]. As a consequence, a 210 host supporting Quick-Start SHOULD enable receive window scaling 211 according to [RFC1323]. If Quick-Start is used in the initial three- 212 way handshake, the minimum required scaling factor MAY be obtained 213 from the required receive buffer space, which can be approximated as 214 described in the previous section. 216 4.2. Problem Within the Three-way Handshake 218 A problem arises when the Quick-Start mechanism is used within the 219 three-way handshake, and the Quick-Start request is added to the 220 initial segment: In this scenario, if the Quick-Start request 221 is approved by the routers along the path, the receiver echoes back 222 the Quick-Start response in the segment. This process is 223 illustrated in [RFC4782]. Upon reception of the with the 224 Quick-Start response, the sender can set the congestion window to the 225 determined value so that it can immediately start to send with the 226 approved data rate. 228 However, [RFC1323] defines that the "Window field in a SYN (i.e., a 229 or ) segment itself is never scaled." This means that 230 the maximum receive window that can be signaled to the sender in the 231 is 64 KB. As a consequence, the TCP flow control will 232 prevent the TCP sender from having more than 64 KB of outstanding 233 data, even if the receiver has much more free buffer, and the Quick- 234 Start feedback allows a much larger congestion window. 236 This effect essentially limits the maximum amount of data sent by 237 Quick-Start to 64 KB, when the sender sends the Quick-Start request 238 in the initial segment. Also, the congestion window after 239 quiting the Quick-Start rate pacing phase is at most 64 KB, as the 240 congestion window is set to the amount of data that has actually been 241 sent during the rate pacing phase. This is an undesirable 242 restriction for the Quick-Start mechanism, even if 64 KB is still 243 much more than the initial congestion window in slow-start that is 244 allowed by [RFC3390]. 246 This issue only occurs when Quick-Start is used in the three-way TCP 247 connection setup procedure, and only in the direction of the client 248 (connection originator) to the server. Still, this case is one of 249 the planned usage scenarios for the Quick-Start TCP extension. 251 4.3. Proposed Solution 253 The limitation imposed by the window scaling could be addressed in 254 different ways. This document proposes the following solution: If 255 necessary, the TCP host SHOULD send a scaled receive window in a 256 separate packet following the packet. 258 This means that when a host receives a segment with a Quick- 259 Start option, it processes the option as described in [RFC4782]. 260 Provided that the host has Quick-Start support enabled, the Quick- 261 Start response is echoed back in the segment. As 262 explained, this segment cannot announce receive windows larger than 263 64 KB. If the receiver allocates a buffer space larger than 64 KB, 264 an additional empty segment (without flag) SHOULD be sent after 265 the segment, in order to announce the true receive window. 266 The resulting message flow is depicted in Figure 1. 268 Sender Routers (approving QS request) Receiver 269 ------ ------- -------- 270 | | 271 | ------------------------------------------------>| 272 | QS request | 273 | TCP , unscaled receive window | 274 | window scaling and other options | 275 | | 276 | <------------------------------------------------| 277 | QS response | 278 | TCP , unscaled receive window | 279 | window scaling and other options | 280 | | 281 | <------------------------------------------------| 282 | Additional acknowledgment | 283 | TCP , scaled receive window | 284 | | 285 | ------------------------------------------------>| 286 | QS report | 287 | TCP | 288 | | 289 | ================================================>| 290 | ================================================>| 291 | Rate paced data transfer | 292 | | 293 | <------------------------------------------------| 294 | First new acknowledgment | 295 V V 297 Figure 1: Message sequence chart of the proposed mechanism 299 After having received this additional acknowledgment, the sender is 300 aware of the true available receive buffer. Provided that the Quick- 301 Start request is approved on the path and that the receive window is 302 sufficiently large, this allows the sender to send more than 64 KB 303 during the Quick-Start rate pacing phase. 305 We note that there is some degree of freedom as to when to send the 306 additional acknowledgment. The straightforward solution is to send 307 it immediately after the segment. But this is not 308 required: It is sufficient if the sender receives this segment before 309 reaching the limit of the unscaled receive window. As a consequence, 310 receivers could also delay the sending of this segment for some small 311 amount of time. 313 4.4. Discussion and Deployment Considerations 315 The method proposed in this document is compliant with the TCP 316 specifications: Sending empty segments to increase the receive window 317 is implicitly allowed by [RFC0793], and in [RFC2581] it is clearly 318 stated that sending an acknowledgment is allowed to update the 319 receive window. For standard-compliant TCP stacks, implementing the 320 method thus should require changes in the receiver TCP implementation 321 only. 323 However, sending an empty acknowledgment shortly after a 324 segment is an atypical TCP communication event. The and 325 the additional segment could get reordered in the network. In this 326 case, the sending host will typically ignore the additional segment, 327 as it is still awaiting the . Furthermore, middleboxes such 328 as state-full firewalls might drop the additional acknowledgment. 329 Even worse, this segment might also be dropped if a middlebox 330 receives it earlier than the segment from the sender. At this 331 point in time, from the viewpoint of the middlebox, the bi- 332 directional end-to-end TCP connection is not yet established. If the 333 additional segment gets dropped, the sender gets informed about the 334 unscaled receive window when the next new acknowledgment arrives, 335 which may limit the benefit of Quick-Start. Delaying the additional 336 acknowledgment for a short period of time could help to avoid such 337 problems. Further investigation is needed to analyze whether such a 338 delay is required. 340 A possible alternative to the message flow in Figure 1 would be to 341 piggyback the Quick-Start response on the additional acknowledgment 342 segment instead of the . However, this approach has several 343 drawbacks and is therefore not recommended: First, the Quick-Start 344 response would be received later, which could cause additional 345 delays. Second, the is immediately acknowledged by the 346 segment. The Quick-Start rate report can thus be piggybacked 347 on this . In contrast, if the Quick-Start response is included 348 in the additional acknowledgment, the Quick-Start report has to be 349 piggybacked to a data segment, i. e., it depends on the availability 350 of application data whether and when the Quick-Start report is sent. 352 The additional segment mandated by this document results in a network 353 overhead of one segment. In many potential usage scenarios this 354 overhead will be small compared to the network load caused by the 355 acknowledgments of a starting high-speed Quick-Start data transfer. 357 Instead of sending one additional acknowledgment, a host could also 358 send a small number of copies in order to improve robustness. This 359 could help to reduce the risk of reordering with the 360 segment. However, given the additional overhead, it is recommended 361 to send only one acknowlegdment unless there are indications that the 362 path suffers from frequent packet reordering. 364 5. Security Considerations 366 Quick-Start TCP imposes a number of security challenges. Known 367 security threats as well as counter-measures are discussed in the 368 section "Security Considerations" of [RFC4782]. Since this document 369 describes extensions to Quick-Start TCP, the security issues and 370 solutions identified in [RFC4782] apply here, too. 372 If a host allocates large amounts of buffer space during the three- 373 way handshake, this could increase the vulnerability to "syn 374 flooding" attacks: An attacker sending many Quick-Start requests 375 could try to allocate much buffer space at a host, which is then not 376 available any more for other TCP connections. If most involved 377 routers support Quick-Start, this type of attack is difficult to 378 realize, since the routers may reject many requests before they reach 379 a host. However, an attack could be possible if some routers on the 380 path do not support Quick-Start. A simple countermeasure would be to 381 set an upper limit on the total amount of buffer space granted to 382 connections with Quick-Start, and possibly to deny requests if they 383 arrive at a host with too high a frequency. The main impact of this 384 abuse is that Quick-Start may be rendered useless for other 385 connections. This can result in some performance degradation, 386 because the default slow-start must be used instead. In general, it 387 is an inherent weak point of Quick-Start that one can send much more 388 requests than required, which temporarily can block resources for 389 other earnest Quick-Start requests [RFC4782]. 391 It is an allowed behavior for a TCP connection endpoint to send an 392 additional acknowledgment segment in order to update the receive 393 window. The usage of the proposed mechanism causes some limited 394 network overhead, but it does not result in additional security 395 threats. 397 6. IANA Considerations 399 This document has no actions for IANA. 401 7. Acknowledgments 403 Special thanks to Haiko Strotbek, Martin Koehn, Simon Hauger, 404 Christian Mueller, and Gorry Fairhurst for suggestions and comments. 406 8. References 408 8.1. Normative References 410 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 411 RFC 793, September 1981. 413 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 414 for High Performance", RFC 1323, May 1992. 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 420 Control", RFC 2581, April 1999. 422 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 423 Initial Window", RFC 3390, October 2002. 425 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 426 Start for TCP and IP", RFC 4782, January 2007. 428 8.2. Informative References 430 [Dun06] Dunigan, T., "TCP auto-tuning zoo", available 431 at http://www.csm.ornl.gov/~dunigan/net100/auto.html, 432 February 2006. 434 [FPK07] Falk, A., Pryadkin, Y., and D. Katabi, "Specification for 435 the Explicit Control Protocol (XCP)", Internet Draft, work 436 in progress, June 2007. 438 [LAJ+07] Liu, D., Allman, M., Jin, S., and L. Wang, "Congestion 439 Control Without a Startup Phase", Proc. PFLDnet2007, 440 February 2007. 442 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 443 Over Satellite Channels using Standard Mechanisms", 444 BCP 28, RFC 2488, January 1999. 446 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and 447 F. Khafizov, "TCP over Second (2.5G) and Third (3G) 448 Generation Wireless Networks", BCP 71, RFC 3481, 449 February 2003. 451 [SAF07] Sarolahti, P., Allman, M., and S. Floyd, "Determining an 452 Appropriate Sending Rate Over an Underutilized Network 453 Path", Computer Networks, vol. 51, no. 7, 2007. 455 [SB05] Smith, M. and S. Bishop, "Flow Control in the Linux 456 Network Stack", available 457 at http://www.cl.cam.ac.uk/~pes20/Netsem/linuxnet.pdf, 458 February 2005. 460 Appendix A. Applicability to Other Proposals 462 Besides Quick-Start, there are some other related proposals for 463 behavior more aggressive than the standard slow-start. A 464 comprehensive survey of this related work can be found in [RFC4782]. 465 For instance, the Explicit Control Protocol (XCP) [FPK07] proposes a 466 new congestion control based on explicit router feedback. 467 Furthermore, there are discussions in the research community whether 468 a host could start to send with an arbitrarily high data rate, 469 combined with a conservative reaction in case of congestion [LAJ+07]. 471 Basically, the effects discussed in this document are not specific to 472 Quick-Start. An interaction with the TCP flow control could also 473 occur with other congestion control mechanisms that avoid the 474 standard TCP slow-start. Receive buffer dimensioning will be a non- 475 trivial task in all these cases. The amount of information that a 476 receiver can gain during a connection setup procedure differs from 477 proposal to proposal. However, the basic guideline to use a larger 478 inital receive buffer allocation applies to all proposals similar to 479 Quick-Start. 481 If the TCP header semantics apply, the interaction with receive 482 window scaling mechanism could also be a problem for other 483 approaches. In this case, the workaround of sending an additional 484 acknowledgment can be helpful, too. 486 Appendix B. Alternative Solutions 488 The limitation imposed by the window scaling could be addressed in 489 several ways. This document proposes to send an additional 490 acknowledgment to announce the true receive window, if needed. This 491 method is compliant with the current TCP standards. 493 Alternatively, one could circumvent [RFC1323] in several ways. For 494 instance, one could use a scaled receive window in and 495 segments, if they include Quick-Start options. The usage 496 of a scaled window could also be indicated by some other means (e. 497 g., a new TCP option). Still, such alternative solutions would 498 require changes in the TCP header semantics and might cause 499 interworking problems with currently deployed TCP implementations. 501 Authors' Addresses 503 Michael Scharf 504 University of Stuttgart 505 Pfaffenwaldring 47 506 D-70569 Stuttgart 507 Germany 509 Phone: +49 711 685 69006 510 Email: michael.scharf@ikr.uni-stuttgart.de 511 URI: http://www.ikr.uni-stuttgart.de/en/~scharf 513 Sally Floyd 514 ICIR (ICSI Center for Internet Research) 516 Phone: +1 (510) 666-2989 517 Email: floyd@icir.org 518 URI: http://www.icir.org/floyd/ 520 Pasi Sarolahti 521 Nokia Research Center 522 P.O. Box 407 523 FI-00045 NOKIA GROUP 524 Finland 526 Phone: +358 50 4876607 527 Email: pasi.sarolahti@iki.fi 529 Full Copyright Statement 531 Copyright (C) The IETF Trust (2007). 533 This document is subject to the rights, licenses and restrictions 534 contained in BCP 78, and except as set forth therein, the authors 535 retain all their rights. 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 540 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 541 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 542 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Intellectual Property 547 The IETF takes no position regarding the validity or scope of any 548 Intellectual Property Rights or other rights that might be claimed to 549 pertain to the implementation or use of the technology described in 550 this document or the extent to which any license under such rights 551 might or might not be available; nor does it represent that it has 552 made any independent effort to identify any such rights. Information 553 on the procedures with respect to rights in RFC documents can be 554 found in BCP 78 and BCP 79. 556 Copies of IPR disclosures made to the IETF Secretariat and any 557 assurances of licenses to be made available, or the result of an 558 attempt made to obtain a general license or permission for the use of 559 such proprietary rights by implementers or users of this 560 specification can be obtained from the IETF on-line IPR repository at 561 http://www.ietf.org/ipr. 563 The IETF invites any interested party to bring to its attention any 564 copyrights, patents or patent applications, or other proprietary 565 rights that may cover technology that may be required to implement 566 this standard. Please address the information to the IETF at 567 ietf-ipr@ietf.org. 569 Acknowledgment 571 Funding for the RFC Editor function is provided by the IETF 572 Administrative Support Activity (IASA).