idnits 2.17.1 draft-ng-nemo-ce-req-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 641. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 411: '...ization solution MUST operate even whe...' RFC 2119 keyword, line 425: '...ization solution MUST NOT increase the...' RFC 2119 keyword, line 437: '...ization solution MUST NOT expose the m...' 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 18, 2007) is 5975 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 4885 (ref. '2') Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft J. Hirano 4 Expires: May 21, 2008 Panasonic 5 A. Petrescu 6 Motorola 7 E. Paik 8 KT 9 November 18, 2007 11 Consumer Electronics Requirements for Network Mobility Route 12 Optimization 13 draft-ng-nemo-ce-req-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document illustrates different deployments of Network Mobility 47 (NEMO) from the consumer electronics perspective. From these 48 deployments, a set of requirements is deduced for Route Optimization 49 (RO) with NEMO. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Deployments of Personal Mobile Router . . . . . . . . . . . . 3 55 2.1. Simple Personal Area Network . . . . . . . . . . . . . . . 4 56 2.2. Personal Mobile Router in a Car . . . . . . . . . . . . . 7 57 2.3. Residence Home Network . . . . . . . . . . . . . . . . . . 9 58 3. Consumer Electronics Requirements for Route Optimization . . . 9 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12 63 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12 64 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . . . . 15 68 1. Introduction 70 Network Mobility (NEMO) Basic Support [3] allows a whole network to 71 change its point of attachment while maintaining reachability and 72 session continuity. [4] and [5] investigate the inefficiencies in 73 NEMO Basic Support, and analyze the solution space for Route 74 Optimization (RO) with NEMO from a technical perspective. 76 This document explores the different deployment scenarios of NEMO 77 from the perspective of consumer electronics. This mainly entails a 78 personal device, called the Personal Mobile Router, as the primary 79 node which a user utilizes to allow the user's other devices to 80 communicate with other nodes in the global Internet. This is 81 detailed in Section 2. From these deployments, a set of requirements 82 is inferred in Section 3. 84 It is expected for readers to be familiar with terminologies related 85 to mobility in [1] and NEMO related terms defined in [2]. Interested 86 readers may also refer to [6] and [7] for the requirements from the 87 automobile and aviation industries respectively. 89 2. Deployments of Personal Mobile Router 91 The Personal Mobile Router is generally envisaged as a mobile 92 communications device, most probably a cellular handphone, with 93 embedded router functionality so as to allow other personal devices 94 (such as MP3 Players, Digital Cameras) to access the global Internet. 95 In such a deployment, it is expected for the Personal Mobile Router 96 to provide all the routing capabilities of the personal area network. 97 This means that one would generally not expect devices (i.e. LFNs) 98 such as digital camera or music players to have routing capabilities. 99 In other words, LFNs are envisaged as simple IPv6 hosts. 101 However, it is possible for there to be a Local Mobile Node (MNN) in 102 the personal area network. For instance, a laptop or a WLAN-enabled 103 PDA can break off from the personal area network and connect to the 104 Internet on its own. Thus, the device becomes a MIPv6 host, with its 105 home address configured from the Mobile Network Prefix of the 106 personal area network. 108 This section illustrates three different deployment scenarios with 109 respect to the Personal Mobile Router. First is a simple personal 110 area network where NEMO services is provided by a service provider 111 (such as an telecommunications operator). Next is the deployment 112 where the Personal Mobile Router is docked within a car and serves as 113 an additional Mobile Router for the car network. The last scenario 114 is the case where the Personal Mobile Router obtains a network prefix 115 not directly from its Internet service providers. Instead, the 116 network prefix is allocated from the user's residence. 118 2.1. Simple Personal Area Network 120 The simplest deployment is when the Personal Mobile Router is simply 121 used to provide Internet access to other devices in a user's personal 122 area network. This is the case where the user subscribes to a 123 mobility service provider that allocates a network prefix for the 124 user's personal area network. One example of this is the 3GPP 125 Personal Network Management services [8]. 127 For this scenario, typical communications will be audio/video 128 streaming from a multimedia content server to the music/video player 129 in the user's personal area network. This is a case of 130 communications between a LFN with a CN in the global internet. 132 ---------- ---- 133 +-----------------| Internet |----| CN | 134 | ---------- ---- 135 ---------------- 136 |Mobility Service| 137 | Provider | 138 ---------------- 139 | 140 / | 3GPP 141 | -------- 142 | | laptop | (MR) 143 | -------- 144 PAN < | 145 (NEMO) | | wifi 146 | ------- 147 | | PDA | (LFN) 148 \ ------- 150 Figure 1: Simple PAN deployment 152 An alternative situation will be communications between devices from 153 two (or more) different personal area networks. For example, two 154 different users may engage in a game with their personal 155 entertainment devices (such as Nintendo or Play Station portables), 156 or share their audio files stored in their music players. This is a 157 case of communications between two LFNs from different NEMO. 159 ------------------ 160 | Mobility Service | 161 | Provider (*) | 162 / ------------------ \ 163 / \ 164 | | 165 | 3GPP | 3GPP 166 -------- -------- 167 | laptop | (MR) | laptop | (MR) 168 -------- -------- 169 | | 170 | Wired | wifi 171 | | 172 -------- -------- 173 |Nintendo| (LFN) |Nintendo| (LFN) 174 -------- -------- 176 (*) - The two MRs may subscribe to the same or different Mobility 177 Service Provider(s) 179 Figure 2: Comunications between Two LFNs 181 An interesting scenario of a Personal Area Network that is beginning 182 to emerge is where the Personal Area Network is composed of a 183 Personal Mobile Router and wearable sensors. Typical deployment [9] 184 would be for a patient who wears wearable sensors that monitor his/ 185 her physical conditions (eg., heartbeat, body temperature, blood 186 pressure, etc) periodically and transmit the measurement to a 187 hospital server through the Personal Mobile Router. This is a case 188 of communications between LFNs and a CN wherein the main traffic from 189 the LFN to the CN. 191 ---------- ---------- 192 +--------| Internet |----| Hospital | (CN) 193 | ---------- ---------- 194 | GPRS 195 ------------ 196 | Cell Phone | (MR) 197 ------------ 198 | 199 +-----------+------------+ 200 | Bluetooth | 201 ---------- --------------- 202 (LFN) | Finger | | Earphone Body | (LFN) 203 | Oximeter | | Thermometer | 204 ---------- --------------- 206 Figure 3: Wearable Sensors Network for Medical Monitoring 208 A more complex use case for Personal Area Network can be described as 209 a dynamic change (scenario) between two different Personal Area 210 Network situations having the same entities. Each entity dynamically 211 changes its role (from, for example, MR to LFN), and, more 212 importantly, the routing task is moved from one entity to another. 214 Consider a Personal Area Network built from one PDA and one laptop. 215 In the first situation, the laptop is the Mobile Router. It uses its 216 WiMax interface to connect to the Internet and its WiFi interface to 217 offer access to the PDA. Following this, a second situation is 218 formed where the PDA connects its 3G interface to the Internet 219 (becoming the Mobile Router) and gives access to the laptop over 220 WiFi. This is illustrated in Figure 4 below. 222 ^ to Internet 223 | 224 | WiMax 225 -------- -------- 226 | laptop | (MR) | laptop | (LFN) 227 -------- \ -------- 228 | -----\ | 229 | wifi -----/ | wifi 230 | / | 231 ------- ------- 232 | PDA | (LFN) | PDA | (MR) 233 ------- ------- 234 | 3GPP 235 | 236 +-------> to Internet 238 Figure 4: Switching of Roles in PAN 240 Both these situations can exist independently, as there are existing 241 software that is currently supporting these. For example, both 242 Microsoft Windows XP (laptop) and Windows Mobile (PDA) have the 243 ability to connect one interface to Internet and offer access over 244 the other interface. 246 However, the automatic change between these two situations is not 247 possible without user intervention. The issues around this relate to 248 interface configuration, default route configuration and others. If 249 Mobile IP is used then there are additional issues with respect to 250 pre-established behavior (eg. use or do not use tunnels). 252 An example application where this support is needed is described 253 next. The scenario above describes the movement of the main routing 254 task from the laptop to the PDA. The routing task (run Mobile IP and 255 NEMO, and hide the LFN from mobility events) can be very consuming 256 and can compete with user interface events. For example, a user of a 257 laptop and PDA sets up the laptop as MR and PDA as LFN. The user 258 continues editing a document on the laptop. Then, another user 259 arrives with a laptop and needs access. At this point the first user 260 is actually interested in making the PDA to be MR (and not his/her 261 laptop) thus avoiding being disturbed by the more consuming routing 262 task of laptop (routing for two users is doubled). 264 Depending on the communicating applications, these kinds of scenarios 265 needing dynamic change of role of the entity performing the routing 266 task can be very numerous. 268 2.2. Personal Mobile Router in a Car 270 A second scenario involving the Personal Mobile Router is when the 271 user docks the Personal Mobile Router into a car network. This 272 allows the communications devices in the vehicle to use the Personal 273 Mobile Router to access information from the Internet. It also 274 allows the personal devices in the personal area network to use the 275 Mobile Router in the vehicle network to communicate with 276 correspondent nodes on the Internet. In other words, the two mobile 277 networks (personal area network and vehicle network) merges to form a 278 multihomed network. 280 There are two possible configurations that could arise. The first 281 possible configuration is where the car sensors and automotive 282 devices are connected to Car Mobile Router using a wired medium (such 283 as the Controller Area Network, etc), and the personal devices are 284 connected to the Personal Mobile Router using a wireless medium (such 285 as the Bluetooth or Ultra Wide Band). The Personal Mobile Router is 286 connected to the Car Mobile Router via a docking mechanism installed 287 in the car. This is illustrated in Figure 5 below. 289 WiMAX 3G 290 Car Sensors | | Personal Devices 291 & Automobile Devices | | (Eg. iPod, PSP, Lumix) 292 _ _ | | _ _ 293 |_| |_| -------- -------- |_| |_| 294 | | | Car | |Personal| | | 295 --+--+----+--+---| Mobile |======| Mobile |-----+--+--+-- 296 _ | _ | | Router | Dock | Router | _ | 297 |_|--+ |_|--+ -------- -------- |_|--+ 299 <----- CAR NEMO -----> <------- PAN ------> 301 Figure 5: Separate Links in Merged NEMO 303 In such a merged network, the vehicle network devices and the 304 personal area network devices will continue to use their own original 305 network prefixes to communicate with external nodes. Hence, one way 306 to view this is to treat it as if the two Mobile Routers attaches to 307 each other, and uses each other as an additional access router. This 308 implies that the a communication between a MNN and a correspondent 309 node may go through two Mobile Routers (e.g. the communication from 310 the car navigation device to a traffic condition server passes 311 through first the Mobile Router of the car, and then the Personal 312 Mobile Router). Hence, this can be viewed as a case of a nested 313 NEMO. 315 A second possibility is that the car network and the personal area 316 network fused into a single network with two mobile routers. One way 317 this can happen is when the two networks use the same wireless 318 technology such as Bluetooth or Wireless Universal Serial Bus as the 319 interconnection medium. This is shown in Figure 6 below. This is a 320 typical NEMO with multiple mobile routers and prefixes [10]. The car 321 devices are free to configure an address from the Mobile Network 322 Prefix of the Personal Mobile Router to communicate with other 323 correspondent nodes in the Internet (such as a realtime traffic 324 monitoring server). Similarly, the personal devices are free to 325 configure an address from the Mobile Network Prefix of the Car Mobile 326 Router to communicate with other correspondent nodes in the Internet 327 (such as a You-Tube video server). 329 WiMAX 3G 330 | | 331 -------- -------- 332 | Car | |Personal| 333 | Mobile | | Mobile | 334 | Router | | Router | 335 _ _ -------- -------- _ _ 336 |_| |_| | | |_| |_| 337 | | | | | | 338 --+--+----+--+---+---------------+-------+--+--+-- 339 _ | _ | _ | 340 |_|--+ |_|--+ |_|--+ 342 Car Sensors Personal Devices 343 & Automobile Devices (Eg. iPod, PSP, Lumix) 345 <------- Merged Into a Single NEMO ---------> 347 Figure 6: A Single Link in Merged NEMO 349 When the car network and the personal area network fused into a 350 single network, LFNs in this single network can communicate with each 351 other. For example, a sensor which was a LFN of the personal area 352 network senses the body temperature of the driver and send this 353 information to the activator which was a LFN of the car network to 354 make the car environment comfortable for the driver. Since the car 355 network and the personal area network became a single network, this 356 communication is a case of intra-NEMO communication. 358 2.3. Residence Home Network 360 This scenario is a special deployment as it differs from the usual 361 subscription model that is more commonly used. Basically, in this 362 scenario, the home network of the Personal Mobile Router (as far as 363 NEMO is concerned) is literally the "home" -- i.e. the residence of 364 the user. It is envisioned that the user deploys a residence-wide 365 network with a set-top box serving as the gateway. This set-top box 366 is connected to the Internet via broadband connection (cable or ADSL) 367 and obtains an IPv6 prefix from the ISP. Part of the IPv6 prefix 368 obtained is then assigned as the prefix for the user's personal are 369 network (i.e. the Mobile Network Prefix for the personal area 370 network). The set-top box is thus configured as the home agent of 371 the Personal Mobile Router. 373 Typically, the devices in the personal area network (i.e. LFNs) 374 would communicate mostly with other devices in the residence network 375 (e.g. personal video player accessing movie stored in a digital video 376 recorder in the residence). In such situation, route optimization is 377 redundant. However, there exist situations where multiple personal 378 area networks (each belonging to different family members) belong to 379 the same residence network. Devices from these different personal 380 area networks may communicate with each other often enough. In the 381 latter situation, it is a case of two MNNs from different NEMO 382 communicating with each other. 384 3. Consumer Electronics Requirements for Route Optimization 386 Not all communications involving personal area network require route 387 optimization. There are, however, two particular use cases where 388 route optimization is highly preferable. The first use case is when 389 devices in a personal area network are used for real time interactive 390 applications which are sensitive to round trip delays. Examples 391 include voice-over-IP communications and multiplayer gaming sessions. 392 This usually entails communications between two devices from two 393 different personal area network, as illustrated in Section 2.1 and 394 Section 2.3. In such cases, there might be two different home agents 395 involved (one for each NEMO), hence making the improvement in delay 396 reduction of route optimization more significant. The second use 397 case is when the home network is congested, or otherwise bandwidth- 398 limited. One example is the residence home network as described in 399 Section 2.3. Most broadband residence access are asymmetrical (i.e. 400 the uplink bandwidth is much smaller than the downlink bandwidth), 401 making it unsuitable for the home agent (e.g. set-top box) to forward 402 large amount of packets to Personal Mobile Routers. 404 Where route optimization is highly preferable, we can infer the 405 following requirements (denoted by "Req") and desirable features 406 (denoted by "Des") from the deployment scenarios described in 407 Section 2. 409 o Req1: Unmodified LFNs 411 A route optimization solution MUST operate even when LFNs are 412 unmodified 414 Rationale: 416 Devices in the personal area network are envisaged as simple 417 IPv6 node. The Personal Mobile Router is expected to provide 418 route optimization services for any consumer electronic devices 419 that connect to its personal area network. Thus, it is 420 expected for LFNs to remain unmodified and unaware of mobile 421 network's movement for route optimizations. 423 o Req2: Low Processing Load 425 A route optimization solution MUST NOT increase the processing 426 load of the MR significantly 428 Rationale: 430 The Personal Mobile Router is a small mobile device (e.g. 431 handphone) that is limited in battery power. Hence, any route 432 optimization solution should not significantly increases the 433 processing load of the MR. 435 o Req3: Security 437 A route optimization solution MUST NOT expose the mobile 438 network to additional security risk 440 Rationale: 442 Security is a prime consideration in the deployment of Personal 443 Mobile Router, since the personal area network may store 444 private information. In general, a personal area network would 445 not allow external devices to attach to the mobile network, 446 hence the Personal Mobile Router will the most important 447 gateway in which security of the personal area network is 448 enforced. As such, any route optimization solution should not 449 expose the Personal Mobile Router to additional risk as 450 compared to NEMO Basic Support. 452 Particularly, it must not be possible for other nodes to claim 453 ownership of the Mobile Network Prefix (in entirety or in 454 parts). Additionally, denial-of service attacks on the 455 Personal Mobile Router (e.g. by forcing the Personal Mobile 456 Router to send a huge amount of signaling packets or to 457 maintain a large number of signaling states) must not be 458 possible. 460 o Des1: MR-to-MR Route Optimization 462 As seen in Section 2, most of the communications we envisaged are 463 in the form of a MNN communicating with another MNN in different 464 personal area networks. As we do not expect MNNs to be involved 465 in route optimization signaling, a suitable route optimization 466 would likely be between the two MRs. This way, correspondent 467 nodes would not be impacted. 469 o Des2: Nested-NEMO Route Optimization 471 In Section 2.2, a scenario is illustrated where the Personal 472 Mobile Router is attaching to the car mobile router for Internet 473 access (and vice versa). If the car mobile router performs route 474 optimization for its network, then the Personal Mobile Router can 475 run a separate route optimization session to achieve fully- 476 optimized route. Alternatively, it is also possible for the 477 Personal Mobile Router to support some mechanism that achieve 478 nested-NEMO route optimization. 480 o Des3: Intra-NEMO Route Optimization 482 In Section 2.2, a scenario is illustrated where nodes in a the car 483 network and nodes in the personal area network communicates with 484 each other. It is desirable that any route optimization solution 485 would work for intra-NEMO communications as well. It will be even 486 preferable if such intra-NEMO route optimizations can be achieved 487 without sending signalling messages out of the mobile network. 489 4. IANA Considerations 491 This is an informational document and does not require any IANA 492 action. 494 5. Security Considerations 496 Security is a prime consideration in the deployment of Personal 497 Mobile Router. The requirements for security involving the Personal 498 Mobile Router are discussed in Section 3. 500 6. References 502 6.1. Normative Reference 504 [1] Manner, J. and M. Kojo, "Mobility Related Terminology", 505 RFC 3753, June 2004. 507 [2] Ernst, T. and H-Y. Lach, "Network Mobility Support 508 Terminology", RFC 4885, July 2007. 510 6.2. Informative Reference 512 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 513 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 514 January 2005. 516 [4] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 517 Route Optimization Problem Statement", RFC 4888, July 2007. 519 [5] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 520 Route Optimization Solution Space Analysis", RFC 4889, 521 July 2007. 523 [6] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route 524 Optimization", draft-baldessari-c2ccc-nemo-req-01 (work in 525 progress), July 2007. 527 [7] Eddy, W., "NEMO Route Optimization Requirements for Operational 528 Use in Aeronautics and Space Exploration Mobile Networks", 529 draft-eddy-nemo-aero-reqs-02 (work in progress), August 2007. 531 [8] "Service requirements for Personal Network Management (PNM)", 532 3GPP TS 22.259, June 2006. 534 [9] Oliver, N. and F. Flores-Mangas, "HealthGear: A Real-time 535 Wearable System for Monitoring and Analyzing Physiological 536 Signals", . 539 [10] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 540 Multihoming in Network Mobility Support", RFC 4980, 541 October 2007. 543 Appendix A. Change Log 545 o draft-ng-nemo-ro-req-01: 547 * Expanded Section 2.2 to include different possible 548 configurations 550 * New scenarios in Section 2.1 and Section 2.2 552 * Organized Section 3 to have one-liner requirements, followed by 553 the explanation to give a more concise presentation 555 * Added Jun, Eun Kyoung and Alexandru as co-authors 557 * Various other editorial fixes 559 o draft-ng-nemo-ro-req-00: 561 * Initial version. 563 Authors' Addresses 565 Chan-Wah Ng 566 Panasonic Singapore Laboratories Pte Ltd 567 Blk 1022 Tai Seng Ave #06-3530 568 Tai Seng Industrial Estate 569 Singapore 534415 570 SG 572 Phone: +65 65505420 573 Email: chanwah.ng@sg.panasonic.com 575 Jun Hirano 576 Matsushita Electric Industrial Co., Ltd. (Panasonic) 577 5-3 Hikarino-oka 578 Yokosuka, Kanagawa 239-0847 579 JP 581 Phone: +81 46 840 5123 582 Email: hirano.jun@jp.panasonic.com 583 Alexandru Petrescu 584 Motorola 585 Parc les Algorithmes Saint Aubin 586 Gif-sur-Yvette 91193 587 France 589 Email: Alexandru.Petrescu@motorola.com 591 Eun Kyoung Paik 592 KT 593 Portable Internet Team, Convergence Lab., KT 594 17 Woomyeon-dong, Seocho-gu 595 Seoul 137-792 596 Korea 598 Phone: +82-2-526-5233 599 Fax: +82-2-526-5200 600 Email: euna@kt.co.kr 601 URI: http://mmlab.snu.ac.kr/~eun/ 603 Full Copyright Statement 605 Copyright (C) The IETF Trust (2007). 607 This document is subject to the rights, licenses and restrictions 608 contained in BCP 78, and except as set forth therein, the authors 609 retain all their rights. 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 614 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 615 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 616 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Intellectual Property 621 The IETF takes no position regarding the validity or scope of any 622 Intellectual Property Rights or other rights that might be claimed to 623 pertain to the implementation or use of the technology described in 624 this document or the extent to which any license under such rights 625 might or might not be available; nor does it represent that it has 626 made any independent effort to identify any such rights. Information 627 on the procedures with respect to rights in RFC documents can be 628 found in BCP 78 and BCP 79. 630 Copies of IPR disclosures made to the IETF Secretariat and any 631 assurances of licenses to be made available, or the result of an 632 attempt made to obtain a general license or permission for the use of 633 such proprietary rights by implementers or users of this 634 specification can be obtained from the IETF on-line IPR repository at 635 http://www.ietf.org/ipr. 637 The IETF invites any interested party to bring to its attention any 638 copyrights, patents or patent applications, or other proprietary 639 rights that may cover technology that may be required to implement 640 this standard. Please address the information to the IETF at 641 ietf-ipr@ietf.org. 643 Acknowledgment 645 Funding for the RFC Editor function is provided by the IETF 646 Administrative Support Activity (IASA).