idnits 2.17.1 draft-ietf-netlmm-nohost-ps-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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 578. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 21 has weird spacing: '... months and ...' == Line 26 has weird spacing: '... The list ...' == Line 92 has weird spacing: '... and scena...' == Line 96 has weird spacing: '... how it s...' == Line 97 has weird spacing: '...cussion of g...' == (21 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '10') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '13') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. '16') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 3220 (ref. '17') (Obsoleted by RFC 3344) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '18') (Obsoleted by RFC 5380) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Kempf, Editor 2 Document: draft-ietf-netlmm-nohost-ps-05.txt September, 2006 3 Expires: March, 2007 5 Problem Statement for Network-based Localized Mobility Management 6 (draft-ietf-netlmm-nohost-ps-05.txt) 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Localized mobility management is a well understood concept in the 35 IETF with a number of solutions already available. This document 36 looks at the principal shortcomings of the existing solutions, all 37 of which involve the host in mobility management, and makes a case 38 for network-based local mobility management. 40 Contributors 42 Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and 43 Marco Liebsch all contributed major effort to this document. Their 44 names are not included in the authors' section due to the RFC 45 Editor's limit of 5 names. 47 Table of Contents 49 1.0 Introduction............................................2 50 2.0 The Local Mobility Problem..............................4 51 3.0 Scenarios for Localized Mobility Management.............6 52 4.0 Problems with Existing Solutions........................7 53 5.0 Advantages of Network-based Localized Mobility 54 Management..............................................8 56 6.0 IANA Considerations.....................................9 57 7.0 Security Considerations.................................9 58 8.0 References..............................................9 59 9.0 Acknowledgements.......................................10 60 10.0 Author's Addresses.....................................10 61 11.0 IPR Statements.........................................11 62 12.0 Disclaimer of Validity.................................12 63 13.0 Copyright Notice.......................................12 65 1.0 Introduction 67 Localized mobility management has been the topic of much work in 68 the IETF. The experimental protocols developed from previous work, 69 namely FMIPv6 [13] and HMIPv6 [18], involve host-based solutions 70 that require host involvement at the IP layer similar to or in 71 addition to that required by Mobile IPv6 [10] for global mobility 72 management. However, recent developments in the IETF and the WLAN 73 infrastructure market suggest that it may be time to take a fresh 74 look at localized mobility management. 76 Firstly, new IETF work on global mobility management protocols that 77 are not Mobile IPv6, such as HIP [16] and MOBIKE [4], suggests that 78 future wireless IP nodes may support a more diverse set of global 79 mobility protocols. While it is possible that existing localized 80 mobility management protocols could be used with HIP and MOBIKE, 81 some would require additional effort to implement, deploy, or in 82 some cases even to specify in a non-Mobile IPv6 mobile environment. 84 Secondly, the success in the WLAN infrastructure market of WLAN 85 switches, which perform localized management without any host stack 86 involvement, suggests a possible paradigm that could be used to 87 accommodate other global mobility options on the mobile node while 88 reducing host stack software complexity expanding the range of 89 mobile nodes that could be accommodated. 91 This document briefly describes the general local mobility problem 92 and scenarios where localized mobility management would be 93 desirable. Then problems with existing or proposed IETF localized 94 mobility management protocols are briefly discussed. The network- 95 based mobility management architecture and a short description of 96 how it solves these problems is presented. A more detailed 97 discussion of goals for a network-based, localized mobility 98 management protocol and gap analysis for existing protocols can be 99 found in [11]. Note that IPv6 and wireless links are considered to 100 be the initial scope for a network-based localized mobility 101 management, so the language in this document reflects that scope. 102 However, the conclusions of this document apply equally to IPv4 and 103 wired links where nodes are disconnecting and reconnecting. 105 1.1 Terminology 106 Mobility terminology in this draft follows that in RFC 3753 107 [7], with the addition of some new and revised terminology 108 given here: 110 WLAN Switch 112 A Wireless LAN (WLAN) switch is an Ethernet [8]switch - that 113 is a multiport bridge that connects network segments but 114 allows a physical and logical star topology - which also 115 runs a protocol to control a collection of 802.11 [6] access 116 points. The access point control protocol allows the switch 117 to perform radio resource management functions such as power 118 control and terminal load balancing between the access 119 points. Most WLAN switches also support a proprietary 120 protocol for inter-subnet IP mobility, usually involving 121 some kind of inter-switch IP tunnel, which provides session 122 continuity when a terminal moves between subnets. 124 Access Network 126 An access network is a collection of fixed and mobile 127 network components allowing access to the Internet all 128 belonging to a single operational domain. It may consist of 129 multiple air interface technologies (for example 802.16e 130 [5], UMTS [1], etc.) interconnected with multiple types of 131 backhaul interconnections (such as SONET [9], metro Ethernet 132 [15] [8], etc.). 134 Local Mobility (revised) 136 Local Mobility is mobility over an access network. Note 137 that, although the area of network topology over which the 138 mobile node moves may be restricted, the actual geographic 139 area could be quite large, depending on the mapping between 140 the network topology and the wireless coverage area. 142 Localized Mobility Management 144 Localized Mobility Management is a generic term for any 145 protocol that maintains the IP connectivity and reachability 146 of a mobile node for purposes of maintaining session 147 continuitity when the mobile node moves, and whose signaling 148 is confined to an access network. 150 Localized Mobility Management Protocol 152 A protocol that supports localized mobility management. 154 Global Mobility Management Protocol 156 A Global Mobility Management Protocol is a mobility protocol 157 used by the mobile node to change the global, end-to-end 158 routing of packets for purposes of maintaining session 159 continuity when movement causes a topology change and thus 160 invalidates a global unicast address of the mobile node. 161 This protocol could be Mobile IP [10][17] but it could also 162 be HIP [14] or MOBIKE [4]. 164 Global Mobility Anchor Point 166 A node in the network where the mobile node maintains a 167 permanent address and a mapping between the permanent 168 address and the local temporary address where the mobile 169 node happens to be currently located. The Global Mobility 170 Anchor Point may be used for purposes of rendezvous and 171 possibly traffic forwarding. 173 Intra-Link Mobility 175 Intra-Link Mobility is mobility between wireless access 176 points within a link. Typically, this kind of mobility only 177 involves Layer 2 mechanisms, so Intra-Link Mobility is often 178 called Layer 2 mobility. No IP subnet configuration is 179 required upon movement since the link does not change, but 180 some IP signaling may be required for the mobile node to 181 confirm whether or not the change of wireless access point 182 also resulted in the previous access routers becoming 183 unreachable. If the link is served by a single access 184 point/router combination, then this type of mobility 185 is typically absent. See Figure 1. 187 2.0 The Local Mobility Problem 189 The local mobility problem is restricted to providing IP mobility 190 management for mobile nodes within an access network. The access 191 network gateways function as aggregation routers. In this case, 192 there is no specialized routing protocol (e.g. GTP, Cellular IP, 193 Hawaii, etc.) and the routers form a standard IP routed network 194 (e.g. OSPF, IS-IS, RIP, etc.). This is illustrated in Figure 1, 195 where the access network gateway routers are designated as "ANG". 196 Transitions between service providers in separate autonomous 197 systems or across broader topological "boundaries" within the same 198 service provider are excluded. 200 Figure 1 depicts the scope of local mobility in comparison to 201 global mobility. The Access Network Gateways (ANGs) GA1 and GB1 are 202 gateways to their access networks. The Access Routers (ARs) RA1 and 203 RA2 are in access network A, RB1 is in access network B. Note that 204 it is possible to have additional aggregation routers between ANG 205 GA1 and ANG GB1 and the access routers if the access network is 206 large. Access Points (APs) PA1 through PA3 are in access network A, 207 PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are 208 also possible, and other routers can separate the ARs from the 209 ANGs. The figure implies a star topology for the access network 210 deployment, and the star topology is the primary one of interest 211 since it is quite common, but the problems discussed here are 212 equally relevant to ring or mesh topologies in which ARs are 213 directly connected through some part of the network. 215 Access Network A Access Network B 217 +-------+ +-------+ 218 |ANG GA1| (other ANGs) |ANG GB1| (other ANGs) 219 +-------+ +-------+ 220 @ @ @ 221 @ @ @ 222 @ @ @ (other routers) 223 @ @ @ 224 @ @ @ 225 @ @ @ 226 +------+ +------+ +------+ 227 |AR RA1| |AR RA2|(other ARs) |AR RB1| (other ARs) 228 +------+ +------+ +------+ 229 * * * 230 * * * * * 231 * * * * * 232 * * * * * 233 * * * * * 234 * * * (other APs) * * (other APs) 235 /\ /\ /\ /\ /\ 236 /AP\ /AP\ /AP\ /AP\ /AP\ 237 /PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \ 238 ------ ------ ------ ------ ------ 240 +--+ +--+ +--+ +--+ 241 |MN|----->|MN|----->|MN|-------->|MN| 242 +--+ +--+ +--+ +--+ 243 Intra-link Local Global 244 (Layer 2) Mobility Mobility 245 Mobility 247 Figure 1. Scope of Local and Global Mobility Management 249 As shown in the figure, a global mobility protocol may be necessary 250 when a mobile node (MN) moves between two access networks. Exactly 251 what the scope of the access networks is depends on deployment 252 considerations. Mobility between two APs under the same AR 253 constitutes intra-link, or Layer 2, mobility, and is typically 254 handled by Layer 2 mobility protocols (if there is only one AP/cell 255 per AR, then intra-link mobility may be lacking). Between these two 256 lies local mobility. Local mobility occurs when a mobile node moves 257 between two APs connected to two different ARs. 259 Global mobility protocols allow a mobile node to maintain 260 reachability when the MN's globally routable IP address changes. It 261 does this by updating the address mapping between the permanent 262 address and temporary local address at the global mobility anchor 263 point, or even end to end by changing the temporary local address 264 directly at the node with which the mobile node is corresponding. A 265 global mobility management protocol can therefore be used between 266 ARs for handling local mobility. However, there are three well- 267 known problems involved in using a global mobility protocol for 268 every movement between ARs. Briefly, they are: 270 1) Update latency. If the global mobility anchor point and/or 271 correspondent node (for route optimized traffic) is at some 272 distance from the mobile node's access network, the global 273 mobility update may require a considerable amount of time. 274 During this time, packets continue to be routed to the old 275 temporary local address and are essentially dropped. 276 2) Signaling overhead. The amount of signaling required when a 277 mobile node moves from one last hop link to another can be 278 quite extensive, including all the signaling required to 279 configure an IP address on the new link and global mobility 280 protocol signaling back into the network for changing the 281 permanent to temporary local address mapping. The signaling 282 volume may negatively impact wireless bandwidth usage and real 283 time service performance. 284 3) Location privacy. The change in temporary local address as the 285 mobile node moves exposes the mobile node's topological 286 location to correspondents and potentially to eavesdroppers. An 287 attacker that can assemble a mapping between subnet prefixes in 288 the mobile node's access network and geographical locations can 289 determine exactly where the mobile node is located. This can 290 expose the mobile node's user to threats on their location 291 privacy. A more detailed discussion of location privacy for 292 Mobile IPv6 can be found in [12]. 294 These problems suggest that a protocol to localize the management 295 of topologically small movements is preferable to using a global 296 mobility management protocol on each movement to a new link. In 297 addition to these problems, localized mobility management can 298 provide a measure of local control, so mobility management can be 299 tuned for specialized local conditions. Note also that if localized 300 mobility management is provided, it is not strictly required for a 301 mobile node to support a global mobility management protocol since 302 movement within a restricted IP access network can still 303 be accommodated. Without such support, however, a mobile node 304 experiences a disruption in its traffic when it moves beyond the 305 border of the localized mobility management domain. 307 3.0 Scenarios for Localized Mobility Management 309 There are a variety of scenarios in which localized mobility 310 management is useful. 312 3.1 Large Campus 314 One scenario where localized mobility management would be 315 attractive is a campus wireless LAN deployment, in which the 316 geographical span of the campus, distribution of buildings, 317 availability of wiring in buildings, etc. preclude deploying all 318 WLAN access points as part of the same IP subnet. WLAN Layer 2 319 mobility could not be used across the entire campus. 321 In this case, the campus is divided into separate last hop links 322 each served by one or more access routers. This kind of deployment 323 is served today by wireless LAN switches that co-ordinate IP 324 mobility between them, effectively providing localized mobility 325 management at the link layer. Since the protocols are proprietary 326 and not interoperable, any deployments that require IP mobility 327 necessarily require switches from the same vendor. 329 3.2 Advanced Cellular Network 331 Next generation cellular protocols such as 802.16e [5] and Super 332 3G/3.9G [2] have the potential to run IP deeper into the access 333 network than the current 3G cellular protocols, similar to today's 334 WLAN networks. This means that the access network can become a 335 routed IP network. Interoperable localized mobility management can 336 unify local mobility across a diverse set of wireless protocols all 337 served by IP, including advanced cellular, WLAN, and personal area 338 wireless technologies such as UltraWide Band (UWB) [5] and 339 Bluetooth [3]. Localized mobility management at the IP layer does 340 not replace Layer 2 mobility (where available) but rather 341 complements it. A standardized, interoperable localized mobility 342 management protocol for IP can remove the dependence on IP layer 343 localized mobility protocols that are specialized to specific link 344 technologies or proprietary, which is the situation with today's 3G 345 protocols. The expected benefit is a reduction in maintenance cost 346 and deployment complexity. See [11] for a more detailed discussion 347 of the goals for a network-based localized mobility management 348 protocol. 350 3.3 Picocellular Network with Small But Node-Dense Last Hop Links 352 Future radio link protocols at very high frequencies may be 353 constrained to very short, line of sight operation. Even some 354 existing protocols, such as UWB [5] and Bluetooth [3], are designed 355 for low transmit power, short range operation. For such protocols, 356 extremely small picocells become more practical. Although picocells 357 do not necessarily imply "pico subnets", wireless sensors and other 358 advanced applications may end up making such picocellular type 359 networks node-dense, requiring subnets that cover small 360 geographical areas, such as a single room. The ability to aggregate 361 many subnets under a localized mobility management scheme can help 362 reduce the amount of IP signaling required on link movement. 364 4.0 Problems with Existing Solutions 366 Existing solutions for localized mobility management fall into 367 three classes: 369 1) Interoperable IP level protocols that require changes to the 370 mobile node's IP stack and handle localized mobility management 371 as a service provided to the mobile node by the access network, 373 2) Link specific or proprietary protocols that handle localized 374 mobility for any mobile node but only for a specific type of 375 link layer, for example, 802.11 [6]. 377 The dedicated localized mobility management IETF protocols for 378 Solution 1 are not yet widely deployed, but work continues on 379 standardization. Some Mobile IPv4 deployments use localized 380 mobility management. For Solution 1, the following are specific 381 problems: 383 1) The host stack software requirement limits broad usage even if 384 the modifications are small. The success of WLAN switches 385 indicates that network operators and users prefer no host stack 386 software modifications. This preference is independent of the 387 lack of widespread Mobile IPv4 deployment, since it is much 388 easier to deploy and use the network. 389 2) Future mobile nodes may choose other global mobility management 390 protocols, such as HIP or MOBIKE. The existing localized 391 mobility management solutions all depend on Mobile IP or 392 derivatives. 393 3) Existing localized mobility management solutions do not support 394 both IPv4 and IPv6. 395 4) Existing host-based localized mobility management solutions 396 require setting up additional security associations with network 397 elements in the access domain. 399 Market acceptance of WLAN switches has been very large, so Solution 400 2 is widely deployed and continuing to grow. Solution 2 has the 401 following problems: 403 1) Existing solutions only support WLAN networks with Ethernet 404 backhaul and therefore are not available for advanced cellular 405 networks or picocellular protocols, or other types of wired 406 backhaul. 407 2) Each WLAN switch vendor has its own proprietary protocol that 408 does not interoperate with other vendor's equipment. 409 3) Because the solutions are based on layer 2 routing, they may not 410 scale up to a metropolitan area, or local province particularly 411 when multiple kinds of link technologies are used in the 412 backbone. 414 5.0 Advantages of Network-based Localized Mobility Management 416 Having an interoperable, standardized localized mobility management 417 protocol that is scalable to topologically large networks, but 418 requires no host stack involvement for localized mobility 419 management is a highly desirable solution. The advantages that this 420 solution has over the Solutions 1 and 2 above are as follows: 422 1) Compared with Solution 1, a network-based solution requires no 423 localized mobility management support on the mobile node and is 424 independent of global mobility management protocol, so it can 425 be used with any or none of the existing global mobility 426 management protocols. The result is a more modular mobility 427 management architecture that better accommodates changing 428 technology and market requirements. 429 2) Compared with Solution 2, an IP level network-based localized 430 mobility management solution works for link protocols other 431 than Ethernet, and for wide area networks. 433 Reference [11] discusses a reference architecture for a network- 434 based, localized mobility protocol and goals the protocol design. 436 6.0 IANA Considerations 438 There are no IANA considerations in this document. 440 7.0 Security Considerations 442 Localized mobility management has certain security considerations, 443 one of which - need for access network to mobile node security - 444 was touched on in this document. Host-based localized mobility 445 management protocols have all the security problems involved with 446 providing a service to a host. Network-based localized mobility 447 management requires security among network elements equivalent to 448 what is needed for routing information security, and security 449 between the host and network equivalent to what is needed for 450 network access, but no more. A more complete discussion of the 451 security goals for network-based localized mobility management can 452 be found in [11]. 454 8.0 References 456 8.1 Informative References 458 [1] 3GPP, "UTRAN Iu interface: General aspects and principles", 459 3GPP TS 25.410, 2002. 460 [2] 3GPP, "3GPP System Architecture Evolution: Report on Technical 461 Options and Conclusions", TR 23.882, 2005, 462 http://www.3gpp.org/ftp/Specs/html-info/23882.htm. 463 [3] Bluetooth SIG, "Specification of the Bluetooth System", 464 November, 2004, available at http://www.bluetooth.com. 465 [4] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol 466 (MOBIKE)", RFC 4555, June, 2006. 467 [5] http://www.ieee802.org/15/pub/TG3a.htm 468 [6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical 469 Layer (PHY) specifications", IEEE Std. 802.11, 1999. 470 [7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan 471 Area Networks - Part 16: Air Interface for Fixed Broadband 472 Wireless Access Systems- Physical and Medium Access Control 473 Layers for Combined Fixed and Mobile Operation in Licensed 474 Bands", IEEE Std. 802.16e-2005, 2005. 475 [8] IEEE, "Carrier sense multiple access with collision detection 476 (CSMA/CD) access method and physical layer specifications", 477 IEEE Std. 802.3-2005, 2005. 479 [9] ITU-T, "Architecture of Transport Networks Based on the 480 Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, 481 2000. 482 [10] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 483 IPv6," RFC 3775. 484 [11] Kempf, J., editor, "Goals for Network-based Localized Mobility 485 Management", Internet Draft, work in progress. 486 [12] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 487 Problem Statement", Internet Draft, work in progress. 488 [13] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC 489 4068, July, 2005. 490 [14] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 491 3753, June, 2004. 492 [15] Metro Ethernet Forum, " Metro Ethernet Network Architecture 493 Framework - Part 1: Generic Framework", MEF 4, May, 2004. 494 [16] Moskowitz, R., and Nikander, P., "Host Identity Protocol (HIP) 495 Architecture", RFC 4423, May, 2006. 496 [17] Perkins, C., editor, "IP Mobility Support for IPv4", RFC 3220, 497 August, 2002. 498 [18] Soliman, H., Castelluccia, C., El Malki, K., and Bellier. L., 499 "Hierarchical Mobile IPv6 Mobility Management," RFC 4140, 500 August, 2005. 502 9.0 Acknowledgements 504 The authors would like to acknowledge the following for 505 particularly diligent reviewing: Vijay Devarapalli, Peter McCann, 506 Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred 507 Templin. 509 10.0 Author's Addresses 511 James Kempf 512 DoCoMo USA Labs 513 181 Metro Drive, Suite 300 514 San Jose, CA 95110 515 USA 516 Phone: +1 408 451 4711 517 Email: kempf@docomolabs-usa.com 519 Kent Leung 520 Cisco Systems, Inc. 521 170 West Tasman Drive 522 San Jose, CA 95134 523 USA 524 EMail: kleung@cisco.com 526 Phil Roberts 527 Motorola Labs 528 Schaumberg, IL 529 USA 530 Email: phil.roberts@motorola.com 532 Katsutoshi Nishida 533 NTT DoCoMo Inc. 534 3-5 Hikarino-oka, Yokosuka-shi 535 Kanagawa, 536 Japan 537 Phone: +81 46 840 3545 538 Email: nishidak@nttdocomo.co.jp 540 Gerardo Giaretta 541 Telecom Italia Lab 542 via G. Reiss Romoli, 274 543 10148 Torino 544 Italy 545 Phone: +39 011 2286904 546 Email: gerardo.giaretta@tilab.com 548 Marco Liebsch 549 NEC Network Laboratories 550 Kurfuersten-Anlage 36 551 69115 Heidelberg 552 Germany 553 Phone: +49 6221-90511-46 554 Email: marco.liebsch@ccrle.nec.de 556 11.0 IPR Statements 558 The IETF takes no position regarding the validity or scope of any 559 Intellectual Property Rights or other rights that might be claimed 560 to pertain to the implementation or use of the technology described 561 in this document or the extent to which any license under such 562 rights might or might not be available; nor does it represent that 563 it has made any independent effort to identify any such rights. 564 Information on the procedures with respect to rights in RFC 565 documents can be found in BCP 78 and BCP 79. 567 Copies of IPR disclosures made to the IETF Secretariat and any 568 assurances of licenses to be made available, or the result of an 569 attempt made to obtain a general license or permission for the use 570 of such proprietary rights by implementers or users of this 571 specification can be obtained from the IETF on-line IPR repository 572 at http://www.ietf.org/ipr. 574 The IETF invites any interested party to bring to its attention any 575 copyrights, patents or patent applications, or other proprietary 576 rights that may cover technology that may be required to implement 577 this standard. Please address the information to the IETF at ietf- 578 ipr@ietf.org. 580 12.0 Disclaimer of Validity 582 This document and the information contained herein are provided on 583 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 584 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 585 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 586 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 587 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 588 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 589 PARTICULAR PURPOSE. 591 13.0 Copyright Notice 593 Copyright (C) The Internet Society (2006). This document is 594 subject to the rights, licenses and restrictions contained in BCP 595 78, and except as set forth therein, the authors retain all their 596 rights.