idnits 2.17.1 draft-ng-nemo-ce-req-02.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 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 720. 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 425: '...ization solution MUST operate even whe...' RFC 2119 keyword, line 439: '...ization solution MUST NOT increase the...' RFC 2119 keyword, line 464: '...ization solution MUST NOT expose the m...' RFC 2119 keyword, line 487: '...ization solution MUST NOT break or pre...' 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 (February 17, 2008) is 5910 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: August 20, 2008 Panasonic 5 A. Petrescu 6 Motorola 7 E. Paik 8 KT 9 February 17, 2008 11 Consumer Electronics Requirements for Network Mobility Route 12 Optimization 13 draft-ng-nemo-ce-req-02 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 August 20, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 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. Characteristics of Route Optimization for Consumer 59 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. Required Characteristics . . . . . . . . . . . . . . . . . 10 61 3.1.1. Req1: Unmodified LFNs . . . . . . . . . . . . . . . . 10 62 3.1.2. Req2: Low Processing Load . . . . . . . . . . . . . . 10 63 3.1.3. Req3: Security . . . . . . . . . . . . . . . . . . . . 11 64 3.1.4. Req4: Protocol Harmony . . . . . . . . . . . . . . . . 11 65 3.2. Desired Characteristics . . . . . . . . . . . . . . . . . 12 66 3.2.1. Des1: MR-to-MR Route Optimization . . . . . . . . . . 12 67 3.2.2. Des2: Nested-NEMO Route Optimization . . . . . . . . . 12 68 3.2.3. Des3: Intra-NEMO Route Optimization . . . . . . . . . 12 69 3.2.4. Des4: Separability . . . . . . . . . . . . . . . . . . 12 70 3.2.5. Des5: Multihoming . . . . . . . . . . . . . . . . . . 13 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13 75 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Intellectual Property and Copyright Statements . . . . . . . . . . 16 80 1. Introduction 82 Network Mobility (NEMO) Basic Support [3] allows a whole network to 83 change its point of attachment while maintaining reachability and 84 session continuity. [4] and [5] investigate the inefficiencies in 85 NEMO Basic Support, and analyze the solution space for Route 86 Optimization (RO) with NEMO from a technical perspective. 88 This document explores the different deployment scenarios of NEMO 89 from the perspective of consumer electronics. This mainly entails a 90 personal device, called the Personal Mobile Router, as the primary 91 node which a user utilizes to allow the user's other devices to 92 communicate with other nodes in the global Internet. This is 93 detailed in Section 2. From these deployments, a set of requirements 94 is inferred in Section 3. 96 It is expected for readers to be familiar with terminologies related 97 to mobility in [1] and NEMO related terms defined in [2]. Interested 98 readers may also refer to [6] and [7] for the requirements from the 99 automobile and aviation industries respectively. 101 2. Deployments of Personal Mobile Router 103 The Personal Mobile Router is generally envisaged as a mobile 104 communications device, most probably a cellular handphone, with 105 embedded router functionality so as to allow other personal devices 106 (such as MP3 Players, Digital Cameras) to access the global Internet. 107 In such a deployment, it is expected for the Personal Mobile Router 108 to provide all the routing capabilities of the personal area network. 109 This means that one would generally not expect devices (i.e. LFNs) 110 such as digital camera or music players to have routing capabilities. 111 In other words, LFNs are envisaged as simple IPv6 hosts. 113 However, it is possible for there to be a Local Mobile Node (MNN) in 114 the personal area network. For instance, a laptop or a WLAN-enabled 115 PDA can break off from the personal area network and connect to the 116 Internet on its own. Thus, the device becomes a MIPv6 host, with its 117 home address configured from the Mobile Network Prefix of the 118 personal area network. 120 This section illustrates three different deployment scenarios with 121 respect to the Personal Mobile Router. First is a simple personal 122 area network where NEMO services is provided by a service provider 123 (such as an telecommunications operator). Next is the deployment 124 where the Personal Mobile Router is docked within a car and serves as 125 an additional Mobile Router for the car network. The last scenario 126 is the case where the Personal Mobile Router obtains a network prefix 127 not directly from its Internet service providers. Instead, the 128 network prefix is allocated from the user's residence. 130 2.1. Simple Personal Area Network 132 The simplest deployment is when the Personal Mobile Router is simply 133 used to provide Internet access to other devices in a user's personal 134 area network. This is the case where the user subscribes to a 135 mobility service provider that allocates a network prefix for the 136 user's personal area network. One example of this is the 3GPP 137 Personal Network Management services [8]. 139 For this scenario, typical communications will be audio/video 140 streaming from a multimedia content server to the music/video player 141 in the user's personal area network. This is a case of 142 communications between a LFN with a CN in the global internet. 144 ---------- ---- 145 +-----------------| Internet |----| CN | 146 | ---------- ---- 147 ---------------- 148 |Mobility Service| 149 | Provider | 150 ---------------- 151 | 152 / | 3GPP 153 | -------- 154 | | laptop | (MR) 155 | -------- 156 PAN < | 157 (NEMO) | | wifi 158 | ------- 159 | | PDA | (LFN) 160 \ ------- 162 Figure 1: Simple PAN deployment 164 An alternative situation will be communications between devices from 165 two (or more) different personal area networks. For example, two 166 different users may engage in a game with their personal 167 entertainment devices (such as Nintendo or Play Station portables), 168 or share their audio files stored in their music players. This is a 169 case of communications between two LFNs from different NEMO. 171 ------------------ 172 | Mobility Service | 173 | Provider (*) | 174 / ------------------ \ 175 / \ 176 | | 177 | 3GPP | 3GPP 178 -------- -------- 179 | laptop | (MR) | laptop | (MR) 180 -------- -------- 181 | | 182 | Wired | wifi 183 | | 184 -------- -------- 185 |Nintendo| (LFN) |Nintendo| (LFN) 186 -------- -------- 188 (*) - The two MRs may subscribe to the same or different Mobility 189 Service Provider(s) 191 Figure 2: Communications between Two LFNs 193 An interesting scenario of a Personal Area Network that is beginning 194 to emerge is where the Personal Area Network is composed of a 195 Personal Mobile Router and wearable sensors. Typical deployment [9] 196 would be for a patient who wears wearable sensors that monitor his/ 197 her physical conditions (eg., heartbeat, body temperature, blood 198 pressure, etc) periodically and transmit the measurement to a 199 hospital server through the Personal Mobile Router. This is a case 200 of communications between LFNs and a CN wherein the main traffic from 201 the LFN to the CN. 203 ---------- ---------- 204 +--------| Internet |----| Hospital | (CN) 205 | ---------- ---------- 206 | GPRS 207 ------------ 208 | Cell Phone | (MR) 209 ------------ 210 | 211 +-----------+------------+ 212 | Bluetooth | 213 ---------- --------------- 214 (LFN) | Finger | | Earphone Body | (LFN) 215 | Oximeter | | Thermometer | 216 ---------- --------------- 218 Figure 3: Wearable Sensors Network for Medical Monitoring 220 A more complex use case for Personal Area Network can be described as 221 a dynamic change (scenario) between two different Personal Area 222 Network situations having the same entities. Each entity dynamically 223 changes its role (from, for example, MR to LFN), and, more 224 importantly, the routing task is moved from one entity to another. 226 Consider a Personal Area Network built from one PDA and one laptop. 227 In the first situation, the laptop is the Mobile Router. It uses its 228 WiMax interface to connect to the Internet and its WiFi interface to 229 offer access to the PDA. Following this, a second situation is 230 formed where the PDA connects its 3G interface to the Internet 231 (becoming the Mobile Router) and gives access to the laptop over 232 WiFi. This is illustrated in Figure 4 below. 234 ^ to Internet 235 | 236 | WiMax 237 -------- -------- 238 | laptop | (MR) | laptop | (LFN) 239 -------- \ -------- 240 | -----\ | 241 | wifi -----/ | wifi 242 | / | 243 ------- ------- 244 | PDA | (LFN) | PDA | (MR) 245 ------- ------- 246 | 3GPP 247 | 248 +-------> to Internet 250 Figure 4: Switching of Roles in PAN 252 Both these situations can exist independently, as there are existing 253 software that is currently supporting these. For example, both 254 Microsoft Windows XP (laptop) and Windows Mobile (PDA) have the 255 ability to connect one interface to Internet and offer access over 256 the other interface. 258 However, the automatic change between these two situations is not 259 possible without user intervention. The issues around this relate to 260 interface configuration, default route configuration and others. If 261 Mobile IP is used then there are additional issues with respect to 262 pre-established behavior (eg. use or do not use tunnels). 264 An example application where this support is needed is described 265 next. The scenario above describes the movement of the main routing 266 task from the laptop to the PDA. The routing task (run Mobile IP and 267 NEMO, and hide the LFN from mobility events) can be very consuming 268 and can compete with user interface events. For example, a user of a 269 laptop and PDA sets up the laptop as MR and PDA as LFN. The user 270 continues editing a document on the laptop. Then, another user 271 arrives with a laptop and needs access. At this point the first user 272 is actually interested in making the PDA to be MR (and not his/her 273 laptop) thus avoiding being disturbed by the more consuming routing 274 task of laptop (routing for two users is doubled). 276 Depending on the communicating applications, these kinds of scenarios 277 needing dynamic change of role of the entity performing the routing 278 task can be very numerous. 280 2.2. Personal Mobile Router in a Car 282 A second scenario involving the Personal Mobile Router is when the 283 user docks the Personal Mobile Router into a car network. This 284 allows the communications devices in the vehicle to use the Personal 285 Mobile Router to access information from the Internet. It also 286 allows the personal devices in the personal area network to use the 287 Mobile Router in the vehicle network to communicate with 288 correspondent nodes on the Internet. In other words, the two mobile 289 networks (personal area network and vehicle network) merges to form a 290 multihomed network. 292 There are two possible configurations that could arise. The first 293 possible configuration is where the car sensors and automotive 294 devices are connected to Car Mobile Router using a wired medium (such 295 as the Controller Area Network, etc), and the personal devices are 296 connected to the Personal Mobile Router using a wireless medium (such 297 as the Bluetooth or Ultra Wide Band). The Personal Mobile Router is 298 connected to the Car Mobile Router via a docking mechanism installed 299 in the car. This is illustrated in Figure 5 below. 301 WiMAX 3G 302 Car Sensors | | Personal Devices 303 & Automobile Devices | | (Eg. iPod, PSP, Lumix) 304 _ _ | | _ _ 305 |_| |_| -------- -------- |_| |_| 306 | | | Car | |Personal| | | 307 --+--+----+--+---| Mobile |======| Mobile |-----+--+--+-- 308 _ | _ | | Router | Dock | Router | _ | 309 |_|--+ |_|--+ -------- -------- |_|--+ 311 <----- CAR NEMO -----> <------- PAN ------> 313 Figure 5: Separate Links in Merged NEMO 315 In such a merged network, the vehicle network devices and the 316 personal area network devices will continue to use their own original 317 network prefixes to communicate with external nodes. Hence, one way 318 to view this is to treat it as if the two Mobile Routers attaches to 319 each other, and uses each other as an additional access router. This 320 implies that the a communication between a MNN and a correspondent 321 node may go through two Mobile Routers (e.g. the communication from 322 the car navigation device to a traffic condition server passes 323 through first the Mobile Router of the car, and then the Personal 324 Mobile Router). Hence, this can be viewed as a case of a nested 325 NEMO. 327 A second possibility is that the car network and the personal area 328 network fused into a single network with two mobile routers. One way 329 this can happen is when the two networks use the same wireless 330 technology such as Bluetooth or Wireless Universal Serial Bus as the 331 interconnection medium. This is shown in Figure 6 below. This is a 332 typical NEMO with multiple mobile routers and prefixes [10]. The car 333 devices are free to configure an address from the Mobile Network 334 Prefix of the Personal Mobile Router to communicate with other 335 correspondent nodes in the Internet (such as a realtime traffic 336 monitoring server). Similarly, the personal devices are free to 337 configure an address from the Mobile Network Prefix of the Car Mobile 338 Router to communicate with other correspondent nodes in the Internet 339 (such as a You-Tube video server). 341 WiMAX 3G 342 | | 343 -------- -------- 344 | Car | |Personal| 345 | Mobile | | Mobile | 346 | Router | | Router | 347 _ _ -------- -------- _ _ 348 |_| |_| | | |_| |_| 349 | | | | | | 350 --+--+----+--+---+---------------+-------+--+--+-- 351 _ | _ | _ | 352 |_|--+ |_|--+ |_|--+ 354 Car Sensors Personal Devices 355 & Automobile Devices (Eg. iPod, PSP, Lumix) 357 <------- Merged Into a Single NEMO ---------> 359 Figure 6: A Single Link in Merged NEMO 361 When the car network and the personal area network fused into a 362 single network, LFNs in this single network can communicate with each 363 other. For example, a sensor which was a LFN of the personal area 364 network senses the body temperature of the driver and send this 365 information to the activator which was a LFN of the car network to 366 make the car environment comfortable for the driver. Since the car 367 network and the personal area network became a single network, this 368 communication is a case of intra-NEMO communication. 370 2.3. Residence Home Network 372 This scenario is a special deployment as it differs from the usual 373 subscription model that is more commonly used. Basically, in this 374 scenario, the home network of the Personal Mobile Router (as far as 375 NEMO is concerned) is literally the "home" -- i.e. the residence of 376 the user. It is envisioned that the user deploys a residence-wide 377 network with a set-top box serving as the gateway. This set-top box 378 is connected to the Internet via broadband connection (cable or ADSL) 379 and obtains an IPv6 prefix from the ISP. Part of the IPv6 prefix 380 obtained is then assigned as the prefix for the user's personal are 381 network (i.e. the Mobile Network Prefix for the personal area 382 network). The set-top box is thus configured as the home agent of 383 the Personal Mobile Router. 385 Typically, the devices in the personal area network (i.e. LFNs) 386 would communicate mostly with other devices in the residence network 387 (e.g. personal video player accessing movie stored in a digital video 388 recorder in the residence). In such situation, route optimization is 389 redundant. However, there exist situations where multiple personal 390 area networks (each belonging to different family members) belong to 391 the same residence network. Devices from these different personal 392 area networks may communicate with each other often enough. In the 393 latter situation, it is a case of two MNNs from different NEMO 394 communicating with each other. 396 3. Characteristics of Route Optimization for Consumer Electronics 398 Not all communications involving personal area network require route 399 optimization. There are, however, two particular use cases where 400 route optimization is highly preferable. The first use case is when 401 devices in a personal area network are used for real time interactive 402 applications which are sensitive to round trip delays. Examples 403 include voice-over-IP communications and multiplayer gaming sessions. 404 This usually entails communications between two devices from two 405 different personal area network, as illustrated in Section 2.1 and 406 Section 2.3. In such cases, there might be two different home agents 407 involved (one for each NEMO), hence making the improvement in delay 408 reduction of route optimization more significant. The second use 409 case is when the home network is congested, or otherwise bandwidth- 410 limited. One example is the residence home network as described in 411 Section 2.3. Most broadband residence access are asymmetrical (i.e. 412 the uplink bandwidth is much smaller than the downlink bandwidth), 413 making it unsuitable for the home agent (e.g. set-top box) to forward 414 large amount of packets to Personal Mobile Routers. 416 Where route optimization is highly preferable, we can infer the 417 following requirements (denoted by "Req") in Section 3.1 and 418 desirable features (denoted by "Des") in Section 3.2 from the 419 deployment scenarios described in Section 2. 421 3.1. Required Characteristics 423 3.1.1. Req1: Unmodified LFNs 425 A route optimization solution MUST operate even when LFNs are 426 unmodified 428 Rationale: 430 Devices in the personal area network are envisaged as simple IPv6 431 node. The Personal Mobile Router is expected to provide route 432 optimization services for any consumer electronic devices that 433 connect to its personal area network. Thus, it is expected for 434 LFNs to remain unmodified and unaware of mobile network's movement 435 for route optimizations. 437 3.1.2. Req2: Low Processing Load 439 A route optimization solution MUST NOT increase the processing load 440 of the MR significantly 442 Rationale: 444 The Personal Mobile Router is a small mobile device (e.g. 445 handphone) that is limited in battery power. Hence, any route 446 optimization solution should not significantly increases the 447 processing load of the MR. 449 Processing load here is used to generally refer to the computation 450 load, signaling load, and memory storage requirements for 451 establishing and managing a route optimization 453 A quantitative requirement on what is the acceptable increase in 454 processing load is impossible to be specified; however, one 455 possibility is to use the current Mobile IPv6 Route Optimization 456 as a benchmark reference. A processing load increase for route 457 optimization of a session is acceptable if it is comparable to the 458 amount of additional processing for Mobile IPv6 Route Optimization 459 (i.e. the CoTI/CoT and HoTI/HoT signaling and adding of home 460 address destination option). 462 3.1.3. Req3: Security 464 A route optimization solution MUST NOT expose the mobile network to 465 additional security risk 467 Rationale: 469 Security is a prime consideration in the deployment of Personal 470 Mobile Router, since the personal area network may store private 471 information. In general, a personal area network would not allow 472 external devices to attach to the mobile network, hence the 473 Personal Mobile Router will the most important gateway in which 474 security of the personal area network is enforced. As such, any 475 route optimization solution should not expose the Personal Mobile 476 Router to additional risk as compared to NEMO Basic Support. 478 Particularly, it must not be possible for other nodes to claim 479 ownership of the Mobile Network Prefix (in entirety or in parts). 480 Additionally, denial-of service attacks on the Personal Mobile 481 Router (e.g. by forcing the Personal Mobile Router to send a huge 482 amount of signaling packets or to maintain a large number of 483 signaling states) must not be possible. 485 3.1.4. Req4: Protocol Harmony 487 A route optimization solution MUST NOT break or prevent the use of 488 existing protocols 490 Rationale: 492 As LFNs are assumed to be unmodified (see Req1), the 493 communications protocols used by them must not be modified as 494 well. A route optimization solution used by the Personal Mobile 495 Router must not cause any communications between the LFN and its 496 correspondent node to stop working. In other words, LFNs should 497 be able to continue to use any protocols that they are able to use 498 without route optimization. This includes IPSec and other IP 499 layer signaling protocols. 501 3.2. Desired Characteristics 503 3.2.1. Des1: MR-to-MR Route Optimization 505 As seen in Section 2, most of the communications we envisaged are in 506 the form of a MNN communicating with another MNN in different 507 personal area networks. As we do not expect MNNs to be involved in 508 route optimization signaling, a suitable route optimization would 509 likely be between the two MRs. This way, correspondent nodes would 510 not be impacted. 512 3.2.2. Des2: Nested-NEMO Route Optimization 514 In Section 2.2, a scenario is illustrated where the Personal Mobile 515 Router is attaching to the car mobile router for Internet access (and 516 vice versa). If the car mobile router performs route optimization 517 for its network, then the Personal Mobile Router can run a separate 518 route optimization session to achieve fully-optimized route. 519 Alternatively, it is also possible for the Personal Mobile Router to 520 support some mechanism that achieve nested-NEMO route optimization. 522 This desired feature can be generally extended to other forms of 523 nesting where the user brings a PAN into a larger mobile network, 524 such as in a plane, a train, or a ship. It is desired that a route 525 optimization solution should yield a fully optimized route regardless 526 of whether the Mobile Router of the larger mobile network performs 527 route optimization or not. 529 3.2.3. Des3: Intra-NEMO Route Optimization 531 In Section 2.2, a scenario is illustrated where nodes in a the car 532 network and nodes in the personal area network communicates with each 533 other. It is desirable that any route optimization solution would 534 work for intra-NEMO communications as well. It will be even 535 preferable if such intra-NEMO route optimizations can be achieved 536 without sending signalling messages out of the mobile network. 538 3.2.4. Des4: Separability 540 As route optimization would inevitably increase the processing load 541 of the Personal Mobile Router, it would be desired that the user be 542 able to select route optimization for some traffic and use the bi- 543 directional tunnel with home agent for other traffic. In other 544 words, a route optimization solution should preferably not be a "all- 545 or-nothing" mechanism. It should be possible to have both route 546 optimized flows and non-optimized sessions simultaneously. 548 3.2.5. Des5: Multihoming 550 As described in Section 2.1, it is likely for a PAN to be equipped 551 with multiple access technologies. Thus, it is desirable that a 552 route optimization solution be able to make use of multiple access 553 networks when available. It is also desirable to have this feature 554 regardless of whether all the available access to external networks 555 reside in one or multiple devices. For instance, in Section 2.2, a 556 scenario is described where there are two Mobile Routers in the 557 merged network. 559 4. IANA Considerations 561 This is an informational document and does not require any IANA 562 action. 564 5. Security Considerations 566 Security is a prime consideration in the deployment of Personal 567 Mobile Router. The requirements for security involving the Personal 568 Mobile Router are discussed in Section 3. 570 6. References 572 6.1. Normative Reference 574 [1] Manner, J. and M. Kojo, "Mobility Related Terminology", 575 RFC 3753, June 2004. 577 [2] Ernst, T. and H-Y. Lach, "Network Mobility Support 578 Terminology", RFC 4885, July 2007. 580 6.2. Informative Reference 582 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 583 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 584 January 2005. 586 [4] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 587 Route Optimization Problem Statement", RFC 4888, July 2007. 589 [5] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 590 Route Optimization Solution Space Analysis", RFC 4889, 591 July 2007. 593 [6] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route 594 Optimization", draft-baldessari-c2ccc-nemo-req-01 (work in 595 progress), July 2007. 597 [7] Eddy, W., "NEMO Route Optimization Requirements for Operational 598 Use in Aeronautics and Space Exploration Mobile Networks", 599 draft-eddy-nemo-aero-reqs-02 (work in progress), August 2007. 601 [8] "Service requirements for Personal Network Management (PNM)", 602 3GPP TS 22.259, June 2006. 604 [9] Oliver, N. and F. Flores-Mangas, "HealthGear: A Real-time 605 Wearable System for Monitoring and Analyzing Physiological 606 Signals", . 609 [10] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 610 Multihoming in Network Mobility Support", RFC 4980, 611 October 2007. 613 Appendix A. Change Log 615 o draft-ng-nemo-ro-req-02: 617 * Added "Protocol Harmony" as requirement 619 * Added "Separability" and "Multihoming" as desired feature 621 * Elaborated more on some of the explanations of requirements 623 o draft-ng-nemo-ro-req-01: 625 * Expanded Section 2.2 to include different possible 626 configurations 628 * New scenarios in Section 2.1 and Section 2.2 630 * Organized Section 3 to have one-liner requirements, followed by 631 the explanation to give a more concise presentation 633 * Added Jun, Eun Kyoung and Alexandru as co-authors 635 * Various other editorial fixes 637 o draft-ng-nemo-ro-req-00: 639 * Initial version. 641 Authors' Addresses 643 Chan-Wah Ng 644 Panasonic Singapore Laboratories Pte Ltd 645 Blk 1022 Tai Seng Ave #06-3530 646 Tai Seng Industrial Estate 647 Singapore 534415 648 SG 650 Phone: +65 65505420 651 Email: chanwah.ng@sg.panasonic.com 653 Jun Hirano 654 Matsushita Electric Industrial Co., Ltd. (Panasonic) 655 5-3 Hikarino-oka 656 Yokosuka, Kanagawa 239-0847 657 JP 659 Phone: +81 46 840 5123 660 Email: hirano.jun@jp.panasonic.com 662 Alexandru Petrescu 663 Motorola 664 Parc les Algorithmes Saint Aubin 665 Gif-sur-Yvette 91193 666 France 668 Email: Alexandru.Petrescu@motorola.com 670 Eun Kyoung Paik 671 KT 672 Portable Internet Team, Convergence Lab., KT 673 17 Woomyeon-dong, Seocho-gu 674 Seoul 137-792 675 Korea 677 Phone: +82-2-526-5233 678 Fax: +82-2-526-5200 679 Email: euna@kt.co.kr 680 URI: http://mmlab.snu.ac.kr/~eun/ 682 Full Copyright Statement 684 Copyright (C) The IETF Trust (2008). 686 This document is subject to the rights, licenses and restrictions 687 contained in BCP 78, and except as set forth therein, the authors 688 retain all their rights. 690 This document and the information contained herein are provided on an 691 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 692 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 693 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 694 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 695 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 696 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 698 Intellectual Property 700 The IETF takes no position regarding the validity or scope of any 701 Intellectual Property Rights or other rights that might be claimed to 702 pertain to the implementation or use of the technology described in 703 this document or the extent to which any license under such rights 704 might or might not be available; nor does it represent that it has 705 made any independent effort to identify any such rights. Information 706 on the procedures with respect to rights in RFC documents can be 707 found in BCP 78 and BCP 79. 709 Copies of IPR disclosures made to the IETF Secretariat and any 710 assurances of licenses to be made available, or the result of an 711 attempt made to obtain a general license or permission for the use of 712 such proprietary rights by implementers or users of this 713 specification can be obtained from the IETF on-line IPR repository at 714 http://www.ietf.org/ipr. 716 The IETF invites any interested party to bring to its attention any 717 copyrights, patents or patent applications, or other proprietary 718 rights that may cover technology that may be required to implement 719 this standard. Please address the information to the IETF at 720 ietf-ipr@ietf.org. 722 Acknowledgment 724 Funding for the RFC Editor function is provided by the IETF 725 Administrative Support Activity (IASA).