idnits 2.17.1 draft-niccolini-sipping-siphandover-05.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. 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 ([1]), 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 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 (November 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3344 (ref. '2') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group S. Niccolini 3 Internet-Draft NEC 4 Intended status: Informational S. Salsano 5 Expires: May 7, 2009 Univ. of Rome Tor Vergata 6 H. Izumikawa 7 KDDI Labs 8 R. Lillie 9 Motorola Labs 10 L. Veltri 11 Univ. of Parma 12 Y. Kishi 13 KDDI Labs 14 November 3, 2008 16 Requirements for vertical handover of multimedia sessions using SIP 17 draft-niccolini-sipping-siphandover-05 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 7, 2009. 44 Abstract 46 A vertical handover occurs in heterogeneous networks when a session 47 media is moved among different access network technologies within the 48 same device. This document analyses the issue of handling the 49 vertical handover using the Session Initiation Protocol (SIP) [1]. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Scenario for vertical handover . . . . . . . . . . . . . . . . 5 56 4. Requirements for Vertical Handovers . . . . . . . . . . . . . 6 57 5. Taxonomy of possible approaches . . . . . . . . . . . . . . . 8 58 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 64 10.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . . . 14 68 1. Introduction 70 Let us consider a terminal (hereafter named "Mobile Host" or MH), 71 that is possibly equipped with different network interfaces (i.e. a 72 subset of WiFi, Bluetooth, GPRS, 3G, 3.5G (HSDPA), fixed Ethernet, 73 WiMax). A user needs to be able to access the Internet using the 74 same MH irrespective the type of network it connects to. Such 75 multimode terminals are already in the market, and we will be 76 gradually get surrounded by a heterogeneous network where several 77 access networks (ANs) supplement each other. Each interface of the 78 MH will receive an IP address from the corresponding AN it connects 79 to. Therefore the mobile host will have a set of different IP 80 addresses and will have to select which one to use when running 81 multimedia sessions with correspondent terminals. While the mobile 82 host moves, the "selected" interface may become not available due to 83 loss of signal, or could suffer high packet loss or packet delay. 84 Under these circumstances, the MH would like to switch to another 85 interface (using a different IP address) keeping the running sessions 86 active, and might adjust the service quality to be optimal depending 87 on circumstances. Even with a single interface the connected access 88 network can become not available anymore and the terminal could 89 connect to another Access Network (in this case on the same 90 technology), which provides a different IP address. If the switch to 91 the new AN is fast enough, the MH could also be interested in keeping 92 the running session active. 94 This problem can be addressed with many different approaches, at all 95 the different levels of the protocol stack from link layer to 96 application layer. For a review and comparison of these different 97 approaches, see for example [15] and [14]. We are interested here in 98 "application level" mobility solutions. The main advantage of 99 application level mobility solutions is that they do not require any 100 support at the networking level and below from the different access 101 networks, which only needs to provide plain IP connectivity. 102 Application level mobility can conduct flexible mobility management, 103 which is another advantage. Within IETF, discussions on using SIP 104 for mobility management date back several years ago and have been 105 mostly carried on in SIPPING WG. For example [11] analysed 106 preliminary requirements and identified issues that need to be 107 resolved in order to develop a mobility management mechanism in a SIP 108 environment. . Furthermore, session mobility using SIP [8] has been 109 discussed in SIPPING WG, and is now awaiting processing and 110 publishing as RFC. 112 This document addresses issues and requirements regarding a SIP based 113 "application level" mobility solution, focusing on "terminal 114 mobility". Although "terminal mobility" could be considered as a 115 sub-set of "session mobility", we believe that some requirements 116 (e.g. vertical handovers, fast switching) are not adequately covered 117 by the mobility features of current SIP specifications and therefore 118 they need a careful consideration within the SIPPING WG. 120 The relevance of this topic is also confirmed by the ongoing work 121 within 3GPP on "Voice Call Continuity" [17] and "Multimedia Session 122 Continuity" [18], which is providing specification of vertical 123 handover solutions using SIP. A discussion of mobility requirements 124 and solution within SIPPING WG provides the chance to consider this 125 3GGP work. 127 2. Terminology 129 This section presents a few terms used throughout the document. 131 o Vertical handover: A vertical handover refers to changing a MH's 132 point of attachment between different types of access networks, 133 e.g. GPRS and WiFi. The feature of a vertical handover is that 134 the transmission rate and latency may well differ significantly 135 before and after handover, respectively. 137 o Network level mobility: Network level mobility refers to managing 138 an MH's mobility at the network layer. Mobile IP (MIP) [2] and 139 Mobile IPv6 (MIPv6) [3] are well-known as network level mobility. 140 One of the merits of network level mobility is making the mobility 141 of an MH transparent to an application by keeping the same IP 142 address. This type of mobility management is useful to run 143 existing applications. However, an ubiquitous deployment of MIP/ 144 MIPv6 is needed if a MH's mobility is globally supported. In 145 addition, it is difficult for an application to recognize an 146 available bandwidth and delay before or during handoff and to 147 adjust a transmitting rate or buffer space to a target network 148 since network level mobility makes the MH's mobility transparent 149 to the upper layer. 151 o Application level mobility: Application level mobility refers to 152 managing an MH's mobility at the application layer. SIP mobility 153 [7] is well-known as application level mobility. Application 154 level mobility has its merits in terms of its ease of deployment. 155 This does not require whole networks to be changed. Therefore, 156 the mobility support can be more and more rapidly deployable using 157 application level mobility. Furthermore, SIP has an affinity for 158 applications, which can make handoff more flexible. The feature 159 can fit heterogeneous networks where an available bandwidth and 160 delay may well differ significantly among access networks. 162 o Terminal mobility: Terminal Mobility allows a device to move 163 between IP subnets, while continuing to be reachable for incoming 164 requests and maintaining sessions across subnet changes. 165 (Definition from [7]) 167 o Session mobility: Session mobility allows a user to maintain a 168 media session even while changing terminals. (Definition from 169 [7]) 171 3. Scenario for vertical handover 173 In this document, we focus on Terminal Mobility. The figure below 174 shows a Mobile Host that wants to communicate with a "Correspondent 175 Host" (CH). The Mobile Host can connect to different Access Networks 176 (AN1, AN2, AN3 are represented in the figure). The different ANs 177 could have different wireless or wired technologies and difference 178 bandwidth/delay, and the Mobile Host could be connected to more than 179 one Access Network at the same time if it has more than one physical 180 network interface. Note that the Access Networks can provide public 181 or private addresses to the mobile host (in most typical scenarios 182 the Access Networks are likely to provide private IP addresses). For 183 example in the figure below AN 1 and AN 3 provide a private address 184 (as shown by the NAT box), while AN2 provides a public address. 185 Similarly, the Correspondent Host can have a public address (like CH 186 1 in the figure) or a private IP address (like CH 2 in the figure). 188 +-------+ 189 | AN1 |-----+ 190 ----| | NAT | +--------+ 191 / +-------+-----+ |Corresp.| 192 +-------+ __________ | Host 1 | 193 | Mobile| +-------+ / \ +--------+ 194 | Host | | AN2 | / \ 195 +-------+ ----| | | INTERNET | 196 + - - - + \ / 197 \__________/ 198 \ +-------+ +--------+ 199 ----| AN3 |-----+ +-----|Corresp.| 200 | | NAT | | NAT | Host 2 | 201 +-------+-----+ +-----+--------+ 203 Figure 1 - Network architecture for vertical handover 205 The goal of the handover mechanism is to let the MH roam among 206 different Access Networks in a seamless way. Therefore we are 207 addressing the issue of "Terminal Mobility" as defined in previous 208 section. The mobility management mechanism should consider the 209 roaming of the MH both "off call" and during an active call. The MH 210 should be able to dynamically choose among the available ANs the one 211 that better suits its needs (e.g. perceived quality of media flows 212 and cost) in a given moment. It is important to notice that this 213 draft does not address the criteria and tools for selection of the 214 "best" access network, it only details the issues and the 215 requirements regarding the mobility management and handover execution 216 mechanism. 218 4. Requirements for Vertical Handovers 220 In this session we discuss a set of requirements that a mobility 221 management solution based on SIP should have. The requirements are 222 divided into two types, i.e., mandatory requirements and optional 223 requirements. 225 Mandatory Requirements 227 o The solution should take care of handover as fast as possible. 228 The goal is to provide a "seamless" handover with no perception 229 from the user point of view. If it is not possible to provide a 230 truly seamless solution, the impairment should be minimized. For 231 example, voip application is used to evaluate for the performance 232 of SIP-based terminal mobility in [9] and also video-phone is used 233 in [13]. According to the ITU requirement[19], one-way delay and 234 packet loss rate for conversational voice and video-phone are 235 required to be less than 150 ms and 3%, and 150 ms and 1%, 236 respectively. 238 o The handover solution should not require a support in the 239 different access network. The access networks are only required 240 to provide IP connectivity (either with public or private 241 addresses) for the forwarding of signalling SIP packets and media 242 RTP packets. 244 o Correspondent Host (CH) (which in general are not moving, but they 245 are communicating with a moving terminal) should be a basic User 246 Agent (UA) which only has basic SIP capabilities. If this 247 requirement is not fulfilled there is the need to change all SIP 248 terminals to support the handovers of Mobile Host. 250 o The handover solution should be compatible with NATted networks, 251 i.e. it should interoperate gracefully with NAT traversal 252 mechanisms for SIP signaling and for session media flows. 254 Optional Desirable Requirements 255 o The solution may support a "forward handover" (i.e. in which all 256 the procedure is performed on the new target Access Network). 257 This is important if the connection on the old Access Network is 258 suddenly broken. If possible (i.e. if the connection with the old 259 access network does not break suddenly) the solution could exploit 260 the communication on the old access network in order to better 261 control the handover procedure. Soft handovers (i.e. where the 262 two active connections can be exploited in the same moment to send 263 the session data) could be exploited. 265 o The switch of the "active" interface during a SIP transaction may 266 be supported. As an example the terminal should be able to send 267 (receive) an INVITE on the currently active interface, switch to 268 another interface and receive (send) the 200 OK on the other 269 interface. 271 o Decoupling of "user level" registration and mobility and "terminal 272 level" mobility may be allowed. As an example a user with AOR 273 "sip:user@domain.com" should be allowed to use different terminals 274 (i.e. Mobile Hosts supporting the handover solutions as well as 275 normal SIP terminals). These terminals can be used in sequence or 276 at the same time depending on the capability of his own "home" 277 registrar/proxy server, and this is independent of the vertical 278 handover solution which takes care of the mobility of only one 279 specific Mobile Host. A concrete example for this requirement is 280 to support a user "sip:user@domain.com" who owns three Mobile 281 Hosts (one could be his phone, one his PDA, one his laptop) and 282 two fixed terminals (his desktop and his home VoIP phone). The 283 vertical handover solution takes care of the mobility of the 284 phone, PDA and laptop as three separate Mobile Hosts (which can 285 also be all active in the same time). 287 o Providing privacy with respect to user location and user movements 288 would be preferable. 290 o Existing user agents for the Mobile Host may inter-work with the 291 handover procedure without the need to be updated. It would be 292 desirable to reuse existing SIP clients (User Agents) without 293 updating them to support the terminal mobility. 295 o It is desirable that the service quality is adjusted to optimal 296 levels according to the access network after every handover. 298 o Non-RTP media such as IM or file transfer using MSRP may be 299 supported. 301 5. Taxonomy of possible approaches 303 The application level terminal mobility solutions based on SIP can be 304 classified in "Correspondent host based" or "Intermediate Element 305 based". In addition, a session mobility is introduced just for 306 reference. 308 o Correspondent Host based terminal mobility solutions 310 RFC 3261 [1] has a built in mechanism for mobility management. The 311 "off-call" mobility management consists in the Registration process. 312 The "on-call" handover is performed using RE-INVITE messages towards 313 the Corresponding Node [7]. No intermediate entities are directly 314 involved in the handover process. This has the advantage that no 315 additional procedures for the handover need to be implemented in 316 intermediate elements, and that there is no additional load in the 317 networks due to the handovers. On the other hand, the procedure 318 requires that the Corresponding Node (which in general is not a 319 mobile host) supports the RE-INVITE mechanism. A second drawback is 320 that the handover delay is directly proportional to the end-to-end 321 delay, and this could be higher with respect to the delay occurring 322 between a mobile node and an intermediate element. 324 o Intermediate Element based terminal mobility solutions 326 In order to overcome the drawbacks of the Correspondent Host based 327 solutions, "intermediate" entities that take an active role in the 328 handover can be introduced. Several proposals can be found in the 329 literature, but to our knowledge no internet draft has been proposed 330 in this respect. Hereafter we mention some of the existing 331 proposals. In [6], intermediate entities are used only to speed up 332 the handover process, but the handover procedure still involves the 333 Corresponding Node as well. A similar approach is followed in [12], 334 which also deals with location based selection of the "optimal" 335 intermediate entity and of wireless access points. In [10] the 336 intermediate entities fully handle the user mobility, hiding the 337 mobility to the Corresponding Nodes. In [13], the intermediate 338 entities are used to support MH's mobility as well as adjusting 339 service quality to the MH's target access network. [16] also 340 describes different ways "intermediate element"-based approach can 341 expedite handover for single-interface-based terminals. 343 o Session mobility solutions 345 According to [8] session mobility is the transfer of media of an 346 ongoing communication session from one device to another. [5], based 347 on the previous work in [7] has defined a framework for session 348 mobility that allows a mobile node to discover available devices and 349 to include them in an active session. [5] has demonstrated the 350 suitability of employing either 3PCC (3PCC) [4] or SIP's REFER [5] 351 method as suitable mechanisms for session mobility between mobile 352 devices. 354 The problem of session mobility is more general and more complex than 355 the problem of terminal mobility that is addressed by this 356 requirement analysis. It is likely that a solution for the session 357 mobility problem can also solve the terminal mobility problem, but it 358 also needs to consider several aspects that are not relevant to 359 terminal mobility. Just to give two examples: 1) device discovery; 360 2) signaling procedures to communicate the intention or need to 361 transfer the session from the original device and the target devices. 362 These two aspects are not needed in a solution for terminal mobility, 363 as all the network interfaces are local to the terminal and they do 364 not need to be discovered nor there is the need to communicate the 365 session transfer from one interface to another. On the other hand, 366 there are some specific requirements that could be taken into 367 consideration in terminal mobility. One example is the avoidance of 368 media disruption during the handover. The gap of the media stream in 369 terminal mobility case (on the same terminal) would cause more severe 370 degradation in the user's experience than that in the session 371 mobility case. Such gap should be made minimum or avoided during the 372 handover in terminal mobility. 374 For the above reason, we believe that requirements for terminal 375 mobility should be addressed in a separate context than session 376 mobility. Obviously solutions for session mobility could become a 377 part of the solution for terminal mobility 379 6. Conclusions 381 As a concluding remark, we believe that it is important to consider a 382 new solution for vertical handover that meets the set of requirements 383 that has been analysed. This solution will help providing seamless 384 handover to SIP based application with a better performance and 385 overcoming some shortcomings of the current solution based on [1]. 387 7. Security considerations 389 The security considerations should be taken into account in the 390 design of the handover solution, so that no new additional security 391 issues will be introduced. 393 8. IANA Considerations 395 This memo includes no request to IANA. 397 9. Acknowledgments 399 The authors would like to thank a number of people that recently 400 contributed to the development of this draft in a more clear 401 direction pointing out the issues that need to be addressed to 402 advance this document. Acknowledgement go to people in the SIPPING 403 working group, including: Ashutosh Dutta, Salvatore Loreto, Henning 404 Schulzrinne and Henry Sinnreich. 406 10. References 408 10.1. Normative References 410 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 411 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 412 Session Initiation Protocol", RFC 3261, June 2002. 414 [2] Perkins, C., "Mobility Support in IPv6", RFC 3344, August 2002. 416 [3] Johnson, D., Perkins, C., and J. Arkko, "IP Mobility Support 417 for IPv4", RFC 3775, June 2004. 419 [4] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 420 "Best Current Practices for Third Party Call Control (3pcc) in 421 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 422 April 2004. 424 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 425 Method", RFC 3515, April 2003. 427 10.2. Informative References 429 [6] Banerjee, N., Acharya, A., and S. Das, "Seamless SIP-Based 430 Mobility for Multimedia Applications", IEEE Network , March/ 431 April 2006. 433 [7] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility 434 Using SIP", ACM Mobile Computing and Communications 435 Review Vol.4, No.3, July 2000. 437 [8] Shacham, R., "Session Initiation Protocol (SIP) Session 438 Mobility", draft-shacham-sipping-session-mobility-05 (work in 439 progress), November 2007. 441 [9] Salsano, S., Veltri , L., Polidoro , A., and A. Ordine , 442 "Architecture and testbed implementation of vertical handovers 443 based on SIP Session Border Controllers", Wireless Personal 444 Communications, Springer , November 2007. 446 [10] Salsano, S., Mingardi, C., Niccolini, S., Polidoro, A., and L. 447 Veltri, "SIP-based Mobility Management in Next Generation 448 Networks", IEEE Wireless Communication , April 2008. 450 [11] Vakil, F., Dutta, A., Chen, J-C., Baba, S., Nakajima, N., 451 Shobatake, Y., and H. Schulzrinne, "Mobility Management in a 452 SIP Environment Requirements, Functions and Issues", 453 draft-itsumo-sip-mobility-req-02.txt (work in progress), 454 December 2000. 456 [12] Tsiakkouris, S. and I. Tsiakkouris, "PROFITIS: architecture for 457 location-based vertical handovers supporting real-time 458 applications", 25th IEEE International Performance, Computing, 459 and Communications Conference (IPCCC 2006), April 2006. 461 [13] Izumikawa, H., Fukuhara, T., Matsunaka, T., and K. Sugiyama, 462 "User-centric Seamless Handover Scheme for Realtime 463 Applications", IEEE Internation Symposium on Personal, Indoor 464 and Mobile Radio Communications (PIMRC'07), September 2007. 466 [14] Le, D., Fu, X., and D. Hogrefe, "A review of Mobility Support 467 Paradigms for the Internet", IEEE Communications Surveys & 468 Tutorials Vol.8, No.1, 1st quarter 2006. 470 [15] Dutta, A., Lyles, B., Schulzrinne, H., Chiba, T., Yokota, H., 471 and A. Idoue, "Generalized Modeling Framework for Handoff 472 Analysis", 18th Annual IEEE International Symposium on 473 Personal, Indoor and Mobile Radio Communications (PIMRC 2007), 474 September 2007. 476 [16] Dutta, A., Madhani, S., Chen, W., and H. Schulzrinne, "Fast- 477 handoff Schemes for Application Layer Mobility Management", 478 15th Annual IEEE International Symposium on Personal, Indoor 479 and Mobile Radio Communications (PIMRC 2004), September 2004. 481 [17] 3GPP, "Voice call continuity between Circuit Switched (CS) and 482 IP Multimedia Subsystem (IMS) Study", 3GPP TR 23.806 7.0.0, 483 December 2005. 485 [18] 3GPP, "Feasibility study on multimedia session continuity; 486 Stage 2", 3GPP TR 23.893 8.0.0, June 2008. 488 [19] ITU-T, "ITU-T G.1010 End-user multimedia QoS categories", 2001. 490 Authors' Addresses 492 Saverio Niccolini 493 Network Laboratories, NEC Europe Ltd. 494 Kurfuersten-Anlage 36 495 Heidelberg 69115 496 Germany 498 Phone: +49 (0) 6221 43 42 118 499 Email: saverio.niccolini@netlab.nec.de 500 URI: http://www.netlab.nec.de 502 Stefano Salsano 503 DIE, University of Rome "TorVergata" 504 Via Politecnico, 1 505 Rome 00156 506 Italy 508 Phone: +39 06 7259 7770 509 Email: stefano.salsano@uniroma2.it 510 URI: http://netgroup.uniroma2.it/Stefano_Salsano 512 Haruki Izumikawa 513 KDDI Labs 514 Postfach 330440 515 Bremen 28334 516 Germany 518 Phone: +49-421/21863908 519 Email: izumikawa@kddilabs.jp 521 Ross Lillie 522 Motorola Labs 523 1301 East Algonquin Road, IL02/2240 524 Schaumburg, IL 60196 525 US 527 Phone: +1 847 576 0012 528 Email: ross.lillie@motorola.com 529 Luca Veltri 530 DII, University of Parma 531 Parco Area delle Scienze 181/A 532 Parma 43100 533 Italy 535 Phone: +39 0521 90 5768 536 Email: luca.veltri@unipr.it 537 URI: http://www.tlc.unipr.it/veltri 539 Yoji Kishi 540 KDDI Labs 541 2-1-15 Ohara 542 Fujimino 356-8502 543 Japan 545 Email: kishi@kddilabs.jp 547 Full Copyright Statement 549 Copyright (C) The IETF Trust (2008). 551 This document is subject to the rights, licenses and restrictions 552 contained in BCP 78, and except as set forth therein, the authors 553 retain all their rights. 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 558 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 559 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Intellectual Property 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at 585 ietf-ipr@ietf.org.