idnits 2.17.1 draft-thubert-nemo-ro-taxonomy-04.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1439. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 21, 2005) is 7004 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '5') == Outdated reference: A later version (-01) exists of draft-zhao-nemo-ro-ps-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-watari-nemo-nested-cn-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-hmipv6 (ref. '10') == Outdated reference: A later version (-02) exists of draft-thubert-nemo-global-haha-00 -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-05 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' -- Possible downref: Normative reference to a draft: ref. '17' -- Possible downref: Normative reference to a draft: ref. '18' -- Possible downref: Normative reference to a draft: ref. '19' -- Possible downref: Normative reference to a draft: ref. '20' -- Possible downref: Normative reference to a draft: ref. '21' -- Possible downref: Normative reference to a draft: ref. '22' == Outdated reference: A later version (-02) exists of draft-droms-nemo-dhcpv6-pd-01 -- Possible downref: Normative reference to a draft: ref. '23' -- Possible downref: Normative reference to a draft: ref. '24' -- Possible downref: Normative reference to a draft: ref. '25' -- Possible downref: Normative reference to a draft: ref. '26' Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group C. Ng 2 Internet-Draft Panasonic Singapore Labs 3 Expires: August 25, 2005 P. Thubert 4 Cisco Systems 5 H. Ohnishi 6 NTT 7 E. Paik 8 KT 9 February 21, 2005 11 Taxonomy of Route Optimization models in the NEMO Context 12 draft-thubert-nemo-ro-taxonomy-04 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 25, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 With current Network Mobility (NEMO) Basic Support, all 48 communications to and from Mobile Network Nodes must go through the 49 MR-HA tunnel when the mobile network is away. This results in 50 increased length of packet route and increased packet delay. To 51 overcome these limitations, one might have to turn to Route 52 Optimization (RO) for NEMO. This memo documents various types of 53 Route Optimization in NEMO, and explores the benefits and tradeoffs 54 in different aspects of NEMO Route Optimization. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Problem Statement of NEMO Route Optimization . . . . . . . . . 5 60 2.1 Sub-Optimality with NEMO Basic Support . . . . . . . . . . 5 61 2.2 Nesting of Mobile Networks . . . . . . . . . . . . . . . . 6 62 2.3 MIPv6 Host in Mobile Networks . . . . . . . . . . . . . . 8 63 2.4 Communications within a Mobile Network . . . . . . . . . . 8 64 3. Benefits of NEMO Route Optimization . . . . . . . . . . . . . 9 65 4. Solution Space of NEMO Route Optimization . . . . . . . . . . 10 66 4.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . . . 10 67 4.2 Infrastructure Optimization . . . . . . . . . . . . . . . 10 68 4.3 Nested Tunnels Optimization . . . . . . . . . . . . . . . 12 69 4.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 13 70 4.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 14 71 5. Issues of Route Optimization . . . . . . . . . . . . . . . . . 16 72 5.1 Additional Signaling Overhead . . . . . . . . . . . . . . 16 73 5.2 Increased Protocol Complexity . . . . . . . . . . . . . . 17 74 5.3 Mobility Awareness . . . . . . . . . . . . . . . . . . . . 17 75 5.4 New Functionalities . . . . . . . . . . . . . . . . . . . 17 76 5.5 Other Considerations . . . . . . . . . . . . . . . . . . . 19 77 6. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 20 78 6.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . . . 20 79 6.2 Infrastructure Optimization . . . . . . . . . . . . . . . 22 80 6.3 Nested Tunnels Optimization . . . . . . . . . . . . . . . 22 81 6.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 24 82 6.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 25 83 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 87 A. Proposed Route Optimizations . . . . . . . . . . . . . . . . . 32 88 A.1 MR-to-CN Optimizations . . . . . . . . . . . . . . . . . . 32 89 A.2 Infrastructure Optimizations . . . . . . . . . . . . . . . 32 90 A.3 Nested Tunnel Optimizations . . . . . . . . . . . . . . . 33 91 A.4 MIPv6-over-NEMO Optimizations . . . . . . . . . . . . . . 35 92 A.5 Intra-NEMO Optimizations . . . . . . . . . . . . . . . . . 36 93 Intellectual Property and Copyright Statements . . . . . . . . 37 95 1. Introduction 97 With current Network Mobility (NEMO) Basic Support [1], all 98 communications to and from nodes in a mobile network must go through 99 the bi-directional tunnel established between the Mobile Router (MR) 100 and its Home Agent (HA) when the mobile network is away. Although 101 such an arrangement allows Mobile Network Nodes (MNNs) to reach and 102 be reached by any node on the Internet, there are associated 103 limitations which might be unacceptable for certain applications. In 104 particular, voice over IP has strict requirements on packet jotter 105 and latency. To substantially improve on NEMO Basic Support, one 106 might have to turn to Route Optimization (RO) for NEMO. Here, we use 107 the term "Route Optimization" to loosely refer to any approach that 108 optimize the transmission of packets between a Mobile Network Node 109 and Correspondent Node (CN). 111 This document explores limitations inherent in NEMO Basic Support, 112 and analyze the possible approaches to Route Optimization with NEMO. 113 It is expected for readers to be familiar with general terminologies 114 related to mobility in [2] and [3], and NEMO related terms defined in 115 [4]. In addition, it is beneficial to keep in mind the design 116 requirements of NEMO [5]. A point to note is that since this 117 document discusses aspects of Route Optimization, the readers may 118 assume that a mobile network or a mobile host is away when they are 119 mentioned throughout this document, unless it is explicitly specified 120 that they are at home. 122 It is the objective of this document to address the need for a Route 123 Optimization analysis in the NEMO Working Group. To quote the 124 charter of the NEMO Working Group: 126 "... The WG will work on: ... ... [an] informational document 127 which specifies a detailed problem statement for Route 128 Optimization and looks at various approaches to solving this 129 problem. This document will look into the issues and tradeoffs 130 involved in making the network's movement visible to some nodes, 131 by optionally making them 'NEMO aware'. The interaction between 132 Route Optimization and IP routing will also be described in this 133 document. Furthermore, security considerations for the various 134 approaches will also be considered. ..." 136 To such end, this document first describes the problem of Route 137 Optimization in NEMO in Section 2. Next, Section 3 discusses the 138 benefits route optimization might bring to NEMO. Follwing this, 139 Section 4 explores possible approaches to solve Route Optimization 140 problems. Section 5 then discusses general considerations concerning 141 a Route Optimization solution, and Section 6 goes into detail 142 considerations of each specific approach described in the solution 143 space. Finally, Section 7 concludes this memo. In addition, we 144 attempt to list various proposed solutions for Route Optimization in 145 Appendix A, and classify them according to the solution space 146 described in Section 4. 148 2. Problem Statement of NEMO Route Optimization 150 In essence, the goal of Route Optimization in NEMO is to reduce 151 limitations, or sub-optimality, introduced by the bi-directional 152 tunnel between a Mobile Router and its Home Agent (also known as the 153 MR-HA tunnel). In the following sub-sections, we will describe the 154 effects of sub-optimal routing with NEMO Basic Support, and how they 155 get amplified with nesting of mobile networks. We will also look 156 into the nesting of a Mobile IPv6 (MIPv6) host in a mobile network. 157 In addition, we will explore the impact of MR-HA tunnel on 158 communications between two Mobile Network Nodes (MNNs) on different 159 links of the same mobile network. 161 Readers might be interested to note the availability of [6] which 162 also discusses the problem statement of NEMO Route Optimization. 164 2.1 Sub-Optimality with NEMO Basic Support 166 With NEMO Basic Support, all packets sent between a Mobile Network 167 Node and its Correspondent Node are forwarded through the MR-HA 168 tunnel. This results in a sub-optimal routing, also known as 169 "dog-leg routing", with NEMO Basic Support. This sub-optimality has 170 the following undesirable effects: 172 o Longer route leading to increased delay 174 Because a packet must transit from a mobile network to the Home 175 Agent then to the Correspondent Node, the transit time of the 176 packet is always higher than if the packet were to go straight 177 from the mobile network to the Correspondent Node. In the best 178 case, where the Correspondent Node resides near the Home Agent, 179 the increase in packet delay is minimal. In the worst case, where 180 both the mobile network and the Correspondent Node are located at 181 a point furthest away from the Home Agent on the Internet, the 182 increase in delay is tremendous. Applications such as real-time 183 multimedia streaming may not be able to tolerate such increase in 184 packet delay. 186 o Increased packets overhead 188 The encapsulation of packets in the MR-HA tunnel results in 189 increased packet size due to addition of an outer packet. This 190 reduces the bandwidth efficiency, as IPv6 header can be quite 191 substantial (at least 40 bytes). 193 o Increased processing delay 195 The encapsulation of packets in the MR-HA tunnel also results in 196 increased processing delay at the points of encapsulation and 197 decapsulation. 199 o Increased chances of packet fragmentation 201 The increased in packet size due to packet encapsulation may 202 increase the chances of the packet being fragmented along the 203 MR-HA tunnel. This can occur if there is no prior path MTU 204 discovery conducted, or if the MTU discovery mechanism did not 205 take into account the encapsulation of packets. Packets 206 fragmentation will result in a further increase in packet delays, 207 and further reduction of bandwidth efficiency. 209 2.2 Nesting of Mobile Networks 211 With nesting of mobile networks, the use of NEMO Basic Support 212 further amplifies the sub-optimality of routing. We call this the 213 amplification effect of nesting, where the (undesirable) effects of 214 sub-optimal routing with NEMO Basic Support are amplified with each 215 level of nesting of mobile networks. This is best illustrated by an 216 example shown in Figure 1. 218 HAofMR1 219 +-----------|---------+ 220 HAofMR2 --| Internet |---CN 221 +---------------|-----+ 222 / Access Router 223 HAofMR3 | 224 ====?======== 225 MR1 226 | 227 ====?===========?===========?=== 228 MR5 MR2 MR6 229 | | | 230 ==|======= ===?====== ======|== 231 LFN2 MR3 LFN3 232 | 233 ==|=========?== 234 LFN1 MR4 235 | 236 ========= 238 Figure 1: An example of nested Mobile Network 240 Using NEMO Basic Support, the flow of packets between a Local Fixed 241 Node LFN1 and a Correspondent Node CN would need to go through three 242 separate tunnels, illustrated in Figure 2 below. 244 ----------. 245 --------/ /----------. 246 -------/ | | /------- 247 CN ------( - - | - - - | - - - | - - - | - - (------- LFN 248 HAofMR3-------\ | | \-------MR3 249 HAofMR2--------\ \----------MR2 250 HAofMR1---------MR1 252 Figure 2: Nesting of Bi-Directional Tunnels 254 This leads to the following problems: 256 o 'Pinball' routing 258 Both inbound and outbound packets will flow via the HAs of all the 259 MRs on their path within the NEMO, with increased latency, less 260 resilience and more bandwidth usage. To illustrate this effect, 261 Figure 3 below shows the route taken by a packet sent from LFN1 to 262 CN: 264 +--> HAofMR3 ---------------------+ 265 | | 266 +----------------- HAofMR2 <--+ | 267 | | 268 +---------------+ | 269 | V 270 HAofMR1 <------+ CN 271 | 272 | 273 LFN1 --> MR3 --> MR2 --> MR1 275 Figure 3: 'Pinball' Routing 277 For more illustration of the pinball routing, see [7]. 279 o Increased Packet Size 281 An extra IPv6 header is added per level of nesting to all the 282 packets. The header compression suggested in [8] cannot be 283 applied because both the source and destination (the intermediate 284 MR and its HA), are different hop to hop. 286 2.3 MIPv6 Host in Mobile Networks 288 When a MIPv6 mobile node joins a mobile network, it becomes a 289 Visiting Mobile Node (VMN) of the mobile network. Packets sent to 290 and from the Visiting Mobile Node will have to be routed not only to 291 the Home Agent of the Visiting Mobile Node, but also to the Home 292 Agent of the Mobile Router in the mobile network. This suffers the 293 same amplification effect of nested Mobile Router mentioned in 294 Section 2.2. 296 In addition, although Mobile IPv6 [2] allows a mobile host to perform 297 Route Optimization with its Correspondent Node to avoid tunneling 298 with its Home Agent, the "optimized" route is no longer optimized 299 when the mobile host is attached to a mobile network. This is 300 because the route between the mobile host and its Correspondent Node 301 is subjected to the sub-optimality introduced by the MR-HA tunnel. 302 Interested readers may refer to [7] for examples of how the routes 303 will appear with nesting of MIPv6 hosts in mobile networks. 305 2.4 Communications within a Mobile Network 307 The reliance on the MR-HA tunnel has its implications on MNNs in a 308 nested mobile network communicating with each other. Let us consider 309 the previous example illustrated in Figure 1. Suppose LFN1 and LFN2 310 are communicating with each other. With NEMO Basic Support, a packet 311 sent from LFN1 to LFN2 will follow the path of: LFN1 -> MR3 -> MR2 -> 312 MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 -> 313 MR5 -> LFN2. A round-about trip indeed where the direct path would 314 be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2. 316 The consequences of increase packet delay and packet size have been 317 discussed in previous sub-sections. Here, there is an additional 318 effect that is undesirable: should MR1 loses its connection to the 319 global Internet, LFN1 and LFN2 can no longer communicates with each 320 other, even though the direct path from LFN1 to LFN2 is unaffected! 322 3. Benefits of NEMO Route Optimization 324 To address the problems discussed in Section 2, one can incorporate 325 Route Optimization into NEMO. This is also known as the NEMO 326 Extended Support. Although a standardized NEMO Extended Support has 327 yet to materialize, one can expect it to show some of the following 328 benefits: 330 o Shorter Delay 332 Route optimization involves the selection and utilization of a 333 shorter (or faster) route to be taken for traffic between a Mobile 334 Network Nodes and Correspondent Node. Hence, Route Optimization 335 should improve the latency of the data traffic between the two end 336 nodes. This may possibly in turn leads to better overall Quality 337 of Services characteristics, such as reduced jitter and packet 338 loss. 340 o Reduced Consumption of Overall Network Resources 342 Through the selection of a shorter route, the total link 343 utilization for all links used by traffic between the two end 344 nodes should be much lower than that used if Route Optimization is 345 not carried out. This would result in a lighter network load with 346 reduced congestion. 348 o Less Susceptibility to Link Failure 350 If a link on the MR-HA path is disrupted, all traffic to and from 351 the mobile network will be affected until IP routing recovers from 352 the failure. An optimized route would conceivably utilize a 353 lesser number of links between the two end nodes. Hence, the 354 probability of a loss of connectivity due to a single point of 355 failure at a link should be lower as compared to the longer 356 non-optimized route. 358 o Greater Data Efficiency 360 Depending on the actual solution for NEMO Extended Support, the 361 data packets exchanged between the two end nodes may not require 362 as many levels of encapsulation as required by NEMO Basic Support. 363 This would mean less packet overheads, and higher data efficiency. 364 In particular, avoiding packet fragmentation that may be induced 365 by the multiple levels of tunneling is critical for end to end 366 efficiency from the viewpoints of buffering and transport 367 protocols. 369 4. Solution Space of NEMO Route Optimization 371 There are multiple proposals for providing various forms of route 372 optimizations for NEMO (see Appendix A). In the following 373 sub-sections, we describe the solution space of Route Optimization by 374 listing different types of approach to Route Optimization. Readers 375 might be interested to take note of a Route Optimization model 376 described in [9] which describes route optimization model based on 377 the variations of tunnel end-points. 379 4.1 MR-to-CN Optimization 381 o Binding Update with Network Prefix 383 A straight-forward approach to Route Optimization in NEMO is for 384 the Mobile Router to attempt Route Optimization with Correspondent 385 Node. This can be viewed as a logical extension to NEMO Basic 386 Support, where the Mobile Router would send binding updates 387 containing one or more Mobile Network Prefix options to the 388 Correspondent Node. The Correspondent Node having received the 389 binding update, can then set up a bi-directional tunnel with the 390 Mobile Router at the current care-of address of the Mobile Router, 391 and inject a route to its routing table so that packets destined 392 for addresses in the mobile network prefix will be routed through 393 the bi-directional tunnel. 395 This approach is particularly useful when a lot of MNNs in a 396 mobile network is communicating with a few corresponding nodes. 397 In such cases, a single Binding Update can optimize the routes of 398 many flows between the Correspondent Node and the MNNs. 400 o MR as a Proxy 402 A somewhat similar approach is for the Mobile Router to act as a 403 "proxy" for the MNNs in its mobile network. In this case, The MR 404 uses standard MIPv6 Route Optimization procedure to bind the 405 address of a MNN to its care-of address. This has the advantage 406 of keeping the implementations of MNNs and correspondent nodes 407 unchanged. 409 4.2 Infrastructure Optimization 411 There are two known approaches to achieve infrastructure 412 optimization. The first approach involves the introduction of an 413 entity known as a correspondent-side router (C-side Router), or 414 sometimes known simply as a Correspondent Router (CR) within the 415 routing infrastructure. As long as the Correspondent Router is 416 located "closer" to the Correspondent Node than the Home Agent of the 417 Mobile Router, the route between MNN and the Correspondent Node can 418 be said to have optimized. This is illustrated in Figure 4. 420 ************************** HAofMR 421 * #*# 422 * #*# +---------------------+ 423 CN #*# | LEGEND | 424 o #*# +---------------------+ 425 o ############### #*# | #: Tunnel | 426 CR ooooooooooooooo MR | *: NEMO Basic route | 427 ############### | | o: Optimized route | 428 MNN +---------------------+ 430 Figure 4: Infrastructure Optimization 432 This form of optimization can take place independently for the 2 433 directions of the traffic: 435 o From MNN to CN 437 The Mobile Router locates the Correspondent Router, establishes a 438 tunnel with that correspondent router and sets a route to the 439 Correspondent Node via the Correspondent Router over the tunnel. 440 After this, traffic to the Correspondent Node does not flow 441 through the Home Agent anymore. 443 o From CN to MNN 445 The Correspondent Router is on the path of the traffic from the 446 Correspondent Node to the Home Agent. In addition, it has an 447 established tunnel with the current care-of address of the Mobile 448 Router and is aware of the mobile network prefix(es) managed by 449 the Mobile Router. The Correspondent Router can thus intercept 450 packets going to the mobile network, and forward them to the 451 Mobile Router over the established tunnel. 453 The advantage of this approach is that no additional functionality is 454 required for the Correspondent Node and Mobile Network Nodes. 456 The second approach is to have optimizations carried out fully in 457 infrastructure. One example is to make use of mobile anchor points 458 (MAP) in HMIPv6 [10] to optimize routes between themselves. Another 459 example is to make use of the global HAHA protocol [11]. In this 460 case, proxy Home Agents are distributed in the infrastructure and 461 Mobile Routers bind to the closest proxy. The proxy performs, in 462 turn, a primary binding with a real Home Agent for that Mobile 463 Router. Then, the proxy might establish secondary bindings with 464 other Home Agents or proxies in the infrastructure, in order to 465 improve the end-to-end path. In this case, the proxies discover each 466 other, establish a tunnel and exchange the relevant mobile network 467 prefix information in the form of explicit prefix routes. There is 468 no need for return routability test or its like since the security is 469 built in the infrastructure, one way or an other, and the proxies 470 belong to the infrastructure. 472 4.3 Nested Tunnels Optimization 474 Nested tunnels optimization is targeted at nested mobile networks, 475 where there will be multiple levels of MR-HA tunnels with NEMO Basic 476 Support. Such a solution will seek to minimize the number of 477 tunnels, possibly by collapsing the amount of tunnels required 478 through some form of signaling between Mobile Routers, or between 479 Mobile Routers and their Home Agents. This limits the consequences 480 of the amplification effect of tunnel nesting, and at best, the 481 performance of a nested mobile network will be the same as though 482 there were no nesting of mobile networks. 484 There have been various proposals on nested tunnels optimization, and 485 we can model them according to: 487 o Sending Information of Upstream Mobile Routers 489 This involves sending information on upstream Mobile Router(s) to 490 the Home Agent of a nested Mobile Router, thereby enabling the 491 Home Agent to forward tunneled packets directly to the nested 492 Mobile Router via the upstream Mobile Router(s), skipping the Home 493 Agents of upstream Mobile Router(s). This usually involves the 494 use of a routing header to route packets through the upstream 495 Mobile Router(s). 497 The information of upstream Mobile Router (for simplicity, we 498 refer to it as "upstream information") may contain information on 499 the entire chain of upstream Mobile Routers, or it may only 500 contain information on the immediate parent mobile router. For 501 the former, the Home Agent can build a multihop routing header 502 from a single transmission of the information. For the latter, 503 each upstream mobile router may have to send Binding Update to the 504 Home Agent of the nested Mobile Router, thereby enabling the Home 505 Agent of the nested Mobile Router to build a multihop routing 506 header recursively. 508 o Prefix Delegation 510 An alternative approach to nested tunnels optimization is to use 511 prefix delegation. Here, each Mobile Router in a nested mobile 512 network is delegated a mobile network prefix from the access 513 router using DHCP Prefix Delegation [12]. Each Mobile Router also 514 autoconfigures its care-of address from this delegated prefix. In 515 this way, the care-of addresses of each Mobile Router are all from 516 an aggregatable address space starting from the access router. 517 This may be used to eliminate any nesting of tunnels. It may also 518 be used to achieve MIPv6-over-NEMO optimization (see Section 4.4) 519 if MIPv6 hosts autoconfigure their care-of addresses from the 520 prefix as well. 522 o Mobile Home 524 This model applies to a category of problems where the mobile 525 networks share a same administration and consistently move 526 together (e.g. a fleet at sea). In this model, there is a 527 cascade of Home Agents. The main Home Agent is fixed in the 528 infrastructure, and advertises an aggregated view of all the 529 mobile networks. This aggregation is actually divided over a 530 number of mobile routers, the root-MRs. The root-MRs subdivide 531 some of their address space to the other Mobile Routers forming 532 their fleet, for which they are Home Agent. As Home Agents, the 533 root-MRs terminate tunnels from the inside of the mobile network. 534 As Mobile Router, they also terminate their home tunnels. As 535 routers, they forward packets between the 2 tunnels. 537 o MANET Routing 539 It is possible for nodes within a mobile network to use MANET 540 routing for packets forwarding between nodes in the same mobile 541 network. An approach of doing so might involves a router acting 542 as a gateway for connecting nodes in the mobile network to the 543 global Internet. All nodes in the mobile network would configure 544 their care-of addresses from a prefix advertised by that gateway. 545 Packets are transferred between the gateway and other Mobile 546 Network Nodes using MANET routing. Such a gateway may be the 547 top-level Mobile Router, or a fixed access router. 549 4.4 MIPv6-over-NEMO Optimization 551 MIPv6-over-NEMO optimization involves providing optimization for a 552 Visiting Mobile Node within a mobile network. There are two aspects 553 to MIPv6-over-NEMO optimization: 555 o Nested Tunnels 557 This aims to reduce the amplification effect of nested tunnels due 558 to the nesting of the tunnel between the Visiting Mobile Node and 559 its Home Agent within the tunnel between the Mobile Router of the 560 mobile network and the Home Agent of the Mobile Router. 562 This is very similar to "Nested Tunnels Optimization" described in 563 Section 4.3. Thus, a possible approach is to extend the solution 564 for nested tunnels optimization to Visiting Mobile Node as well. 566 o MIPv6 Route Optimization 568 This aims to remove the sub-optimality of a MR-HA tunnel from the 569 MIPv6 Route Optimization established between a Visiting Mobile 570 Node and Correspondent Node. One approach is to simply extend the 571 solution for nested tunnels optimization to Correspondent Node. 572 Another (arguably "evil") approach is for the Mobile Router to 573 "play some trick" to the MIPv6 Route Optimization, such as 574 altering messages exchanged during the return routability 575 procedure between the Visiting Mobile Node and Correspondent Node, 576 so that packets sent from Correspondent Node to the Visiting 577 Mobile Node will be routed to the care-of address of the Mobile 578 Router once Route Optimization is established (see Section 4.1: 579 "MR as a Proxy"). Alternatively, the Mobile Router can perform 580 return routability procedure on behalf of the Visiting Mobile 581 Node. This would most likely require some signaling protocol 582 between the Visiting Mobile Node and the Mobile Router, but may be 583 able to keep the functionality of the Correspondent Node 584 unchanged. 586 4.5 Intra-NEMO Optimization 588 A Route Optimization solution may seek to improve the communications 589 between two Mobile Network Nodes within a nested mobile network. An 590 example will be the optimization of packets route taken between LFN1 591 and LFN2 of Figure 1. 593 One may be able to extend a well-designed solution for MR-to-CN 594 optimization to provide Intra-NEMO optimization, where, for example 595 in Figure 1, LFN1 is treated as a Correspondent Node in the view of 596 MR5, and LFN2 is treated as a Correspondent Node in the view of MR3. 598 Another possibility is for the infrastructure optimization technique 599 to be applied here. Using the same example of communication between 600 LFN1 and LFN2, MR3 may treat MR5 as a Correspondent Router for LFN2, 601 and MR5 treats MR3 as a Correspondent Router for LFN1. 603 Yet a different approach would be the use of MANET routing within a 604 mobile network, as described in Section 4.3. In such an approach, 605 the Mobile Routers expose their Mobile Network Prefix over a 606 prefix-enabled MANET protocol. MANET based IP routing establishes 607 the route between the LFNs within the same nested structure. 609 5. Issues of Route Optimization 611 Although Route Optimization, or NEMO Extended Support, can bring 612 benefits as described in previous section, it does so with some 613 tradeoffs. The actual type and degree of tradeoffs depend greatly on 614 the solution; however, in general, one would expect the costs 615 described in the following sub-sections to be incurred. 617 5.1 Additional Signaling Overhead 619 The nodes involved in performing Route Optimization would be expected 620 to exchange additional signaling information in order to establish 621 Route Optimization. The cost of such signaling may be high, 622 depending on the actual solution. Such a cost may scale to 623 unacceptable height when the number of mobile network nodes and/or 624 Correspondent Nodes is increased. 626 This signaling overhead is often in the form of Binding Update sent 627 to Home Agents or Correspondent Nodes. One issue that may impact 628 Route Optimization solution is known as the phenomenon of "Binding 629 Update Storm". This occurs when a change in point of attachment of 630 the mobile networks is accompanied with a sudden burst of Binding 631 Update messages being generated, resulting in temporary congestion, 632 packet delays or even packet lost. 634 There has been argument that Binding Update storm may not be as 635 significant as it seems. For instance, consider a mobile network 636 where Mobile Network Nodes is receiving x video stream at 25 packets 637 per seconds. On the average, the mobile network is handling a total 638 traffic of 25*x packets per second. Assuming one Binding Update has 639 to be sent for each video stream server, a change in point of 640 attachment would result in at most 6*x signaling messages (if we 641 include the return routability procedure messages and a binding 642 acknowledgment). Thus the signaling overhead is small compared to 643 the normal data traffic that the mobile network is handling, and 644 hence the effect of Binding Update storm is small. On the other 645 hand, if the normal data rate is small, the effect of Binding Update 646 storm may have a greater impact. From this discussion, it appears 647 that the significance of Binding Update storm may depend on the 648 application type (eg. high or low data rate, tolerance on packets 649 delay, etc). 651 It is also possible to further moderate the effect of Binding Update 652 Storm by having some sort of "exponential back-off" mechanism in 653 place for the sending of binding updates. Such a scheme aims to 654 spread the burst of Binding Update transmissions over a longer period 655 of time, thereby reducing possibility of congestion and packet drops. 657 5.2 Increased Protocol Complexity 659 Some nodes will be required to have additional functionalities in 660 order to incorporate NEMO Extended Support. This increases the node 661 complexity. It may not be feasible to implement new functionalities 662 on legacy nodes. If such nodes are mobile, this may prove to be a 663 significant cost due to the limited memory resources such devices 664 usually have. 666 Coupled with the increased in protocol complexity, nodes that are 667 involved in the establishment and maintenance of Route Optimization 668 will have to bear increased processing load. If such nodes are 669 mobile, this may prove to be a significant cost due to the limited 670 power and processing resources such devices usually have. 672 5.3 Mobility Awareness 674 One advantage of NEMO Basic Support is that the Correspondent Nodes 675 and mobile network nodes need not be aware of the actual location and 676 mobility of the mobile network. With Route Optimization, it might be 677 necessary to reveal the current care-of address and any change of 678 point of attachment of the Mobile Router to other nodes, such as the 679 Mobile Network Nodes or Correspondent Node. This may mean a tradeoff 680 between location privacy and Route Optimization. In MIPv6, the 681 mobile node can decide whether or not to perform Route Optimization 682 with a given Correspondent Node. Thus, the mobile node is in control 683 of whether to trade location privacy for an optimized route. It will 684 be desirable that such control is also available in a route optimized 685 solution of NEMO should the solution contain the same tradeoff. 686 However, for solutions where Route Optimization decision is made by 687 Mobile Router, it will be difficult for Mobile Network Nodes to 688 control the decision of having this tradeoff. 690 5.4 New Functionalities 692 All Route Optimization approaches require some sort of new 693 functionalities be implemented on some nodes. In general, it is 694 desirable to keep the number of nodes that require new 695 functionalities as small as possible. This allows for easier 696 adoption of the solution, and also creates less impact on the 697 existing infrastructure. 699 In addition, if Route Optimization solution requires new 700 functionalities on the part of some other nodes other than nodes 701 within the mobile network, a mechanism for other nodes (such as 702 Mobile Router) to detect if support for the new functionalities are 703 available should also be provided. Furthermore, it is desirable for 704 there to be a graceful fall back procedure the required 705 functionalities are unavailable. 707 Possible nodes that are required to be changed includes: 709 o Local Fixed Nodes 711 It is generally undesirable to affect local fixed nodes. However, 712 some approaches require Mobile Network Nodes to implement new 713 functionalities to enjoy benefits of route optimizations. 715 o Visiting Mobile Nodes 717 Visiting mobile nodes in general should already have implemented 718 MIPv6 functionalities, and since MIPv6 is a relatively new 719 standard, there is still a considerable window to allow mobile 720 devices to implement new functionalities. 722 o Mobile Routers 724 It is expected for Mobile Routers to implement new functionalities 725 in order to enable route optimizations. 727 o Access Routers 729 Some approaches require access routers, or nodes in the access 730 network to implement some new functionalities. A clear example 731 will be prefix delegation approach. 733 o Home Agents 735 Although it is likely that vendors and operators would not mind 736 having new functionalities in Home Agents, few route optimizations 737 approaches would impact the Home Agents. 739 o Correspondent Nodes 741 It is generally undesirable for Correspondent Nodes to be required 742 to implement new functionalities. 744 o Correspondent Routers 746 Correspondent Routers are new entity to be deployed in the 747 infrastructure. Such addition would generally cause the least 748 disruption to the existing routing infrastructure. 750 5.5 Other Considerations 752 There are other considerations when analyzing the Route Optimization 753 solution space. These may not be a 'tradeoff" so to speak, but are 754 beneficial to keep in mind when considering a Route Optimization 755 solutions. 757 o Compatibility with NEMO Basic Support 759 It will be beneficial to vendors if a route optimized solution for 760 NEMO is compatible with NEMO Basic Support. This reduces the 761 complexity and achieves greater reuse of existing functionalities. 763 o In-Plane Signaling versus Off-Plane Signaling 765 There is also considerations of whether Route Optimization 766 signaling should be done in-plane and off-plane. In-plane 767 signaling involves embedding signaling information into headers of 768 data packets (a good example would be the Reverse Routing Header 769 [13]). Off-plane signaling involves separating the signaling 770 packets from the data packets. Most proposals involving sending 771 of binding updates fall within this category. 773 6. Analysis of Solution Space 775 Many of the tradeoffs discussed previously in Section 5 are dependent 776 on the actual Route Optimization approach. In the following 777 sub-sections, we will explore deeper into the issues involved in each 778 specific type of Route Optimization approach. 780 6.1 MR-to-CN Optimization 782 One approach of MR-to-CN optimization involves the Mobile Router 783 sending binding update messages with mobile network prefix 784 information to the Correspondent Node. This raised several issues: 786 o Security Considerations 788 With Mobile Router sending Binding Update containing network 789 prefix information to Correspondent Node, there is a question on 790 the additional risk imposed on the Correspondent Node. Although 791 return routability procedure allows the correspondent node to 792 verify that the care-of and home addresses of the Mobile Router 793 are indeed collocated, it does not allow the Correspondent Node to 794 verify the validity of the network prefix. If the Correspondent 795 Node accepts the binding without verification, it will be exposed 796 to a class of attacks where the attacker tricks the Correspondent 797 Node into forwarding packets destined for a mobile network to the 798 attacker. 800 Hence, MR-to-CN optimization would most likely require an extended 801 return routability procedure to be developed for Correspondent 802 Node to authenticate the validity of the mobile network prefix. 803 This require additional functionality on the correspondent node, 804 and a mechanism must be provided for the Mobile Router to check if 805 the correspondent node has such functionality implemented. 807 o Mobility Awareness 809 By sending Binding Update with mobile network prefix to the 810 Correspondent Node, the Mobile Router is effectively revealing the 811 location and mobility of the mobile network to the Correspondent 812 Node. Hence this is a case of trading location privacy for Route 813 Optimization. However, since Route Optimization in this case is 814 initiated by the Mobile Router, the Mobile Network Nodes may not 815 have an influence to the decision of whether the tradeoff should 816 be made. 818 o Binding Update Storm 820 If the Mobile Network Nodes in a mobile network are communicating 821 with a lot of Correspondent Nodes, whenever the Mobile Router 822 changes its point of attachment, it needs to send out a large 823 number of binding updates to Correspondent Nodes. This is further 824 worsen by the fact that the Mobile Router has to perform the 825 return routability procedure prior to sending binding updates. 827 Another approach involves the Mobile Router acting as a proxy for 828 MNNs behind it. This has the following issues: 830 o Security Considerations 832 Having the Mobile Router alters packets (such as inserting home 833 address destination option and removing type 2 routing header) 834 raise considerable security concerns. Such a scheme may break 835 existing IPSec protocols, and cause packets to be dropped. 837 o Complexity 839 This also greatly increases the complexity of a Mobile Router, as 840 it needs to look beyond the standard IPv6 headers for 841 ingress/egress packets, and performs hacks appropriately. The 842 Mobile Router is also required to maintain some form of state 843 information for each pair of MNN and CN, resulting in scaling 844 issues. This scheme also places all processing burden on the 845 Mobile Router, which may be undesirable for mobile device with 846 limited power and processing resources. 848 o Binding Update Storm 850 Whenever the Mobile Router changes its point of attachment, it 851 needs to perform binding updates with every Correspondent Node. 852 Some CN selection scheme may be required to moderate the effect of 853 Binding Update storm and processing burden on the Mobile Router. 855 o A Hack of Existing Protocol 857 There have been comments on the NEMO WG mailing list that such an 858 approach is essentially a hack of the existing return routability 859 procedure. The disadvantages of it being a hack is that firstly a 860 change/extension in the current return routability procedure would 861 render this hack broken, and secondly, it might be very difficult 862 to accommodate other protocols that are not aware of such hacks 863 (IPSec being an excellent example). 865 o Nesting of Mobile Routers 867 Should one Mobile Router be attached to another Mobile Router, it 868 is unclear how this solution will work if both Mobile Routers try 869 to perform Route Optimization on behalf of the same Mobile Network 870 Nodes. Using Figure 1 as an example, if MR5 perform Route 871 Optimization on behalf of LFN2, and then MR1 again tries to act as 872 a proxy to MR5, the results might be messy without any 873 co-ordination between these Mobile Routers. 875 6.2 Infrastructure Optimization 877 An infrastructure optimization approach using correspondent routers 878 may face the following issues: 880 o Security Considerations 882 The first security-related issue is how do the Mobile Router 883 verify the validity of a Correspondent Router. In other words, 884 the Mobile Router needs some mechanism to ascertain that the 885 Correspondent Router is indeed a valid correspondent router 886 capable of forwarding packets to and from the Correspondent Node. 888 A second security-related issue is how can the Correspondent 889 Router verify the validity of a Mobile Router. In other words, 890 the Correspondent Router needs some mechanism to ascertain that 891 the Mobile Router is indeed managing the mobile network prefix it 892 claims to be managing. This is related to the issues discussed in 893 Section 6.1. 895 o Mobility Awareness 897 Infrastructure optimization requires the Correspondent Router to 898 be informed of the location and mobility of the mobile network. 899 Correspondent nodes and mobile network nodes remain ignorant of 900 the mobile network's mobility. 902 o Discovery of Correspondent Routers 904 How should a Mobile Router discover a Correspondent Router given a 905 particular Correspondent Node? The discovery mechanism may have 906 impact on the security issue discussed earlier. 908 6.3 Nested Tunnels Optimization 910 Nested tunnels optimization usually involves the nested Mobile Router 911 sending information of upstream Mobile Router(s). 913 o Security Considerations 914 One issue for consideration is whether the Home Agent should trust 915 the upstream information supplied by the nested Mobile Router. If 916 the upstream information falsely points to a victim node, the Home 917 Agent may unconsciously flood the victim with packets intended for 918 the nested mobile network. 920 This risk can be minimized if the upstream information is 921 protected by security association between the nested Mobile Router 922 and its Home Agent (e.g. the upstream information may be 923 transmitted in a Binding Update that is protected from tampering). 924 However, this does not protect against a malicious Mobile Router 925 intentionally supplying false upstream information to its Home 926 Agent, with the intent of launching a flooding attack against a 927 victim node. 929 o Mobility Awareness 931 Usually, nested tunnels optimization involves the nested Mobile 932 Router sending upstream information to its Home Agent. This 933 implies that the upstream Mobile Router will have to reveal some 934 information to sub-Mobile Routers. Such information may reveal 935 the location and mobility of the upstream Mobile Router. 937 o Binding Update Storm 939 Depending on the specifics of a solution for nested tunnels 940 optimization, the upstream information may be the care-of address 941 of the upstream Mobile Router. This will leads to the a burst of 942 Binding Update messages whenever an upstream Mobile Router changes 943 its point of attachment, since all its sub-MRs must send binding 944 updates to their Home Agents to update the new upstream 945 information. 947 o Complexity 949 Sending of upstream information for nested tunnels optimization 950 requires the Home Agent to store the upstream information in order 951 to build a routing header. Complexity of the Home Agent is 952 further increased if the upstream information is sent individually 953 by all upstream Mobile Routers, requiring the Home Agent to 954 recursively build a routing header. 956 Alternatively, a prefix delegation approach may be used to achieve 957 nested tunnel optimization by eliminating the need for nesting. This 958 approach may face the following issues: 960 o Protocol Complexity 961 This approach requires the access router (or some other entity 962 within the access network) to possess prefix delegation 963 functionality, and also maintains information on what prefix is 964 delegated to which node. 966 o Binding Update Storm 968 A change in the point of attachment of the root Mobile Router will 969 require every nested Mobile Router (and possibly Visiting Mobile 970 Nodes) to change their care-of addresses and delegated prefixes. 971 These will cause a burst of Binding Update and prefix delegation 972 activities where every Mobile Routers and Visiting Mobile Nodes 973 start sending binding updates to their Home Agents and possibly 974 Correspondent Nodes. 976 6.4 MIPv6-over-NEMO Optimization 978 If MIPv6 Route Optimization is not used, the optimization for 979 MIPv6-over-NEMO is very similar to nested tunnels optimization, where 980 the MIPv6 mobile node acts like a visiting Mobile Router. The 981 analysis of such optimization is thus similar to those discussed in 982 Section 6.3, and hence will not be repeated here. In this section, 983 we explore the issues if MIPv6 Route Optimization is used. 985 As described in Section 4.4, MIPv6-over-NEMO optimization can be 986 achieved using various approaches. One approach involves including 987 upstream information (see nested tunnels optimization) in the Binding 988 Update sent from the Visiting Mobile Node to the Correspondent Node. 989 This approach has the following considerations: 991 o Security Considerations 993 A security-related issue is how can the Correspondent Node verify 994 the validity of the supplied upstream information. See also 995 Section 6.3. 997 o Mobility Awareness 999 The Visiting Mobile Node will need to acquire the upstream 1000 information, most likely including the mobility and location 1001 information of the upstream Mobile Routers. 1003 On the other hand, the Mobile Router can perform some hacks on the 1004 return routability messages exchanged between the Visiting Mobile 1005 Node and Correspondent Node to achieve MIPv6-over-NEMO optimization. 1006 This, is generally undesirable due to: 1008 o Security Considerations 1010 Such a scheme may break existing security related protocols, as it 1011 requires the Mobile Router to make changes to contents of a packet 1012 that is not originated by the Mobile Router. 1014 Alternatively, the Mobile Router can perform return routability 1015 procedure on behalf of the Visiting Mobile Node. Here the issues 1016 are: 1018 o Security Considerations 1020 Such a scheme require the Visiting Mobile Node to place 1021 considerable trust on the Mobile Router, as the mobility 1022 management key is now transfered to the Mobile Router. 1024 o Mobility Awareness 1026 This approach aims to keep the functionality of the Correspondent 1027 Node to be identical as those required by MIPv6 Route 1028 Optimization. The expense will be that a new form of signaling 1029 between the Visiting Mobile Node and mobile router would most 1030 likely be required. 1032 o Processing Burden 1034 This approach also increases the processing burden of the Mobile 1035 Router, as it needs to maintain information necessary for Route 1036 Optimization to work for every Correspondent Node that is 1037 communicating with each visiting mobile node. This may not scale 1038 very well when one consider, for example, a train network, where 1039 there are hundreds of Visiting Mobile Nodes in one mobile network. 1041 6.5 Intra-NEMO Optimization 1043 As mentioned in Section 4.5, it is likely that any MR-to-CN 1044 optimization may be able to fulfill the role of an intra-NEMO 1045 optimization. Such solutions will face the same issues as described 1046 in Section 6.1, as well as the following: 1048 o Reliance on Outside Infrastructure 1050 Most MR-to-CN optimization rely on the operations of Home Agent in 1051 one way or another. For instance, the return routability 1052 procedure requires a Home Test (HoT) or Home Test Init (HoTI) 1053 messages be forwarded by the Home Agent. This means that should 1054 the path to the Internet be broken, such optimization techniques 1055 can no longer be used (and thus LFN1 can no longer communicates 1056 with LFN2 in the example of Figure 1). 1058 7. Conclusion 1060 The problem space of Route Optimization in the NEMO context is 1061 multifold and can be split into several work areas. It will be 1062 critical, though, that the solution to a given piece of the puzzle be 1063 compatible and integrate smoothly with the others. 1065 This memo explored into various problems of sub-optimality of NEMO 1066 Basic Support, and discussed different aspects of a route optimized 1067 solution in NEMO. The intent of this document is to trigger fruitful 1068 discussions that in turn will enhance our common understanding of the 1069 Route Optimization problem and solution space. 1071 8. Acknowledgments 1073 The authors wish to thank: Greg Daley, Thierry Ernst, Erik Nordmark, 1074 T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa 1075 and Patrick Wetterwald for their various contributions. In addition, 1076 the authors would also like to extend their heart-felt gratitude to 1077 Marco Molteni, who was a co-author for the earlier versions of this 1078 document. 1080 9. References 1082 [1] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 1083 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1084 January 2005. 1086 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1087 IPv6", RFC 3775, June 2004. 1089 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 1090 RFC 3753, June 2004. 1092 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1093 Internet-Draft draft-ietf-nemo-terminology-02, October 2004. 1095 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 1096 Internet-Draft draft-ietf-nemo-requirements-03, October 2004. 1098 [6] Zhao, F., "NEMO Route Optimization Problem Statement, 1099 Requirements and Evaluation Considerations", 1100 Internet-Draft draft-zhao-nemo-ro-ps-00, October 2004. 1102 [7] Ernst, T., "Route Optimization with Nested Correspondent 1103 Nodes", Internet-Draft draft-watari-nemo-nested-cn-00, October 1104 2004. 1106 [8] Deering, S. and B. Zill, "Redundant Address Deletion when 1107 Encapsulating IPv6 in IPv6", 1108 Internet-Draft draft-deering-ipv6-encap-addr-deletion-00, 1109 November 2001. 1111 [9] Na, J., "Generic Route Optimization Model for NEMO Extended 1112 Support", Internet-Draft draft-na-nemo-gen-ro-model-00, July 1113 2004. 1115 [10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, 1116 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 1117 Internet-Draft draft-ietf-mipshop-hmipv6-04, December 2004. 1119 [11] Thubert, P., "Global HA to HA protocol", 1120 Internet-Draft draft-thubert-nemo-global-haha-00, October 2004. 1122 [12] Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6", 1123 Internet-Draft draft-troan-dhcpv6-opt-prefix-delegation-01, May 1124 2002. 1126 [13] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 1127 its application to Mobile Networks", 1128 Internet-Draft draft-thubert-nemo-reverse-routing-header-05, 1129 June 2004. 1131 [14] Ng, C., "Extending Return Routability Procedure for Network 1132 Prefix (RRNP)", Internet-Draft draft-ng-nemo-rrnp-00, October 1133 2004. 1135 [15] Bernardos, C., Bagnulo, M. and M. Calderon, "MIRON: MIPv6 Route 1136 Optimization for NEMO", ASWN 2004, 1137 Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf. 1139 [16] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization 1140 with Access Router Option", 1141 Internet-Draft draft-ng-nemo-access-router-option-01, July 1142 2004. 1144 [17] Na, J., "Route Optimization Scheme based on Path Control 1145 Header", Internet-Draft draft-na-nemo-path-control-header-00, 1146 April 2004. 1148 [18] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", 1149 Internet-Draft draft-wakikawa-nemo-orc-01, November 2004. 1151 [19] Na, J., "Secure Nested Tunnels Optimization using Nested Path 1152 Information", Internet-Draft draft-na-nemo-nested-path-info-00, 1153 September 2003. 1155 [20] Kang, H., "Route Optimization for Mobile Network by Using 1156 Bi-directional Between Home Agent and Top Level Mobile 1157 Router", Internet-Draft draft-hkang-nemo-ro-tlmr-00, June 2003. 1159 [21] Ohnishi, H., "HMIP based Route optimization method in a mobile 1160 network", Internet-Draft draft-ohnishi-nemo-ro-hmip-00, October 1161 2003. 1163 [22] Paakkonen, P. and J. Latvakoski, "Mobile Network Prefix 1164 Delegation extension for Mobile IPv6", 1165 Internet-Draft draft-paakkonen-nemo-prefix-delegation-00, March 1166 2003. 1168 [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 1169 Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004. 1171 [24] Lee, K., "Route Optimization for Mobile Nodes in Mobile Network 1172 based on Prefix Delegation", 1173 Internet-Draft draft-leekj-nemo-ro-pd-02, February 2004. 1175 [25] Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes 1176 in Mobile Network", 1177 Internet-Draft draft-jeong-nemo-ro-ndproxy-02, February 2004. 1179 [26] Perera, E., "Extended Network Mobility Support", 1180 Internet-Draft draft-perera-nemo-extended-00, July 2003. 1182 Authors' Addresses 1184 Chan-Wah Ng 1185 Panasonic Singapore Laboratories Pte Ltd 1186 Blk 1022 Tai Seng Ave #06-3530 1187 Tai Seng Industrial Estate 1188 Singapore 534415 1189 SG 1191 Phone: +65 65505420 1192 Email: cwng@psl.com.sg 1194 Pascal Thubert 1195 Cisco Systems Technology Center 1196 Village d'Entreprises Green Side 1197 400, Avenue Roumanille 1198 Biot - Sophia Antipolis 06410 1199 FRANCE 1201 Email: pthubert@cisco.com 1203 Hiroyuki Ohnishi 1204 NTT network service systems laboratories, NTT cooperation 1205 9-11, Midori-Cho 3-Chome 1206 Musashino-shi 1207 Tokyo 180-8585 1208 JAPAN 1210 Email: ohnishi.hiroyuki@lab.ntt.co.jp 1211 Paik, Eun Kyoung 1212 KT 1213 Portable Internet Team, Convergence Lab., KT 1214 17 Woomyeon-dong, Seocho-gu 1215 Seoul 137-792 1216 Korea 1218 Phone: +82-2-526-5233 1219 Fax: +82-2-526-5200 1220 Email: euna@kt.co.kr 1221 URI: http://mmlab.snu.ac.kr/~eun/ 1223 Appendix A. Proposed Route Optimizations 1225 Here, we attempt to list the numerous proposed solutions according to 1226 the solution space defined in Section 4. Although we made effort in 1227 listing all possible solutions, sincere apology is extended to 1228 authors of solutions that we might have missed out. 1230 A.1 MR-to-CN Optimizations 1232 Most MR-to-CN optimizations proposals are implicitly achieved by 1233 sending mobile network prefixes to Correspondent Nodes. The Return 1234 Routability procedure with Network Prefix (RRNP) [14] proposed an 1235 extension to return routability procedure for verifying the validity 1236 of mobile network prefixes. 1238 One approach that uses the Mobile Router as a proxy for establishing 1239 Route Optimization on behalf of Mobile Network Nodes can be found in 1240 [15]. 1242 In addition, various nested tunnel optimizations proposals (see 1243 Appendix A.3) can also be extended to correspondent node, thus 1244 enabling the MR-to-CN optimizations. Example includes the Reverse 1245 Routing Header (RRH) [13], Access Router Option (ARO) [16]. 1247 A.2 Infrastructure Optimizations 1249 All known infrastructure optimization proposals defines the entity 1250 known as correspondent router capable of terminating bi-directional 1251 tunnels from Mobile Routers on behalf of Correspondent Nodes, thereby 1252 achieving Route Optimization. The difference between these proposals 1253 is mainly the way correspondent routers are discovered. Proposals 1254 include: 1256 o Path Control Header (PCH) [17] 1258 The PCH approach requires the Home Agent to piggyback a Path 1259 Control Header on the packet when forwarding packets arriving from 1260 a bi-directional tunnel to a Correspondent Node. Because PCH is a 1261 hop-by-hop option header, all intermediate routers lying between 1262 the Home Agent and the Correspondent Node will inspect the PCH. 1263 If a Correspondent Router exists among these intermediate router, 1264 it can contact the Mobile Router (identified in the PCH) and 1265 establish a optimized tunnel with the Mobile Router. 1267 o Optimized Routing Cache (ORC) [18] 1269 The ORC approach defines the functionality of a Correspondent 1270 Router able to terminate bi-directional tunnels from Mobile 1271 Routers. Mobile routers discover correspondent routers by sending 1272 a query message to a multicast address corresponding to "all 1273 Correspondent Router" address. The query message contains the 1274 address of the Correspondent Node for which the Mobile Router 1275 wishes to send packets to. The Correspondent Router managing the 1276 network within which the Correspondent Node resides will responds 1277 to this query. The proposal also suggest Correspondent Router to 1278 inform Mobile Routers the prefix information of the network it is 1279 capable of managing, so that any other traffic flows that 1280 originate and end at the mobile network and the network the 1281 Correspondent Router is managing can also enjoy Route 1282 Optimization. 1284 A.3 Nested Tunnel Optimizations 1286 Many proposed solutions for NEMO Extended Support targets the nested 1287 tunnel optimization. Most of these involves sending of upstream 1288 information to the Home Agent of a nested Mobile Router, including 1290 o Reverse Routing Header (RRH) [13] 1292 The RRH approach avoids the multiple encapsulation of the traffic 1293 but maintains the home tunnel of the first Mobile Router on the 1294 egress path. The first Mobile Router on the way out (egress 1295 direction) encapsulates the packet over its reverse tunnel, using 1296 a form of Record Route header, the RRH. 1298 The upstream Mobile Routers simply swap their care-of address and 1299 the source of the packet, saving the original source in the RRH. 1300 The Home Agent transforms the RRH in a Routing Header to perform 1301 source routing across the nested mobile network, along the ingress 1302 path to the target Mobile Router. 1304 o Access Router Option (ARO) [16] 1306 The ARO approach is somewhat similar to the RRH in that only the 1307 home tunnel of the first nested Mobile Router in the egress path 1308 is maintained. This is done by having the nested Mobile Router to 1309 send an ARO in Binding Update to inform its Home Agent the address 1310 of its access router (i.e. an upstream Mobile Router). Using 1311 this information, the Home Agent can build a Routing Header to 1312 source-route a packet to the nested Mobile Router within in a 1313 nested mobile network. Upstream Mobile Routers can also send 1314 Binding Update messages to the Home Agent of the nested Mobile 1315 Router, thus allowing a complete routing header be built 1316 recursively by the Home Agent. 1318 o Nested Path Info (NPI) [19] 1320 The NPI approach is somewhat similar to the ARO approach, except 1321 that instead of sending only the home address of the upstream 1322 Mobile Router to its Home Agent, a nested Mobile Router send a 1323 nested information on the care-of addresses of all upstream Mobile 1324 Routers. Using this information, the Home Agent can build a 1325 Routing Header to source-route a packet to the nested Mobile 1326 Router within in a nested mobile network. 1328 o Top Level Mobile Router (TLMR) [20] 1330 In TLMR, each visiting Mobile Router obtains the address of the 1331 root-MR through router advertisement messages. This information 1332 is passed to its Home Agent in a Binding Update message. The 1333 visiting Mobile Router also registers with the root-MR. With 1334 these registrations, the root-MR maintains a topology of the 1335 mobile network. In addition, the root MR also establish tunnels 1336 with the Home Agents of every visiting Mobile Router. This way, 1337 packet to and from each nested mobile network will be relayed 1338 through the root-MR, through an additional tunnel between the 1339 root-MR and the Home Agent of the nested mobile network. 1341 o Hierarchical Mobile IP (HMIP) [21] 1343 This approach proposes an adaptation of HMIPv6 [10] for NEMO. 1344 Here, information on the root-MR (acting as a Mobile Anchor Point, 1345 MAP) is passed to nested Mobile Routers in the MAP option of a 1346 router advertisement. Nested Mobile Routers then register their 1347 regional and local care-of address with the root-MR. Packets are 1348 then transfered to and from a nested Mobile Router through two 1349 separate tunnels: one between the nested Mobile Router and the 1350 root-MR, the other between the root-MR and the Home Agent of the 1351 nested Mobile Router. 1353 Other approaches that does not really require the sending of upstream 1354 information to Home Agent includes: 1356 o Prefix Delegation [22][23][24] 1358 The prefix delegation approach is somewhat to HMIPv6 what NEMO is 1359 to MIPv6. The Access Router of the nested structure is both a 1360 NEMO Home Agent and a DHCP-PD server, for an aggregation that it 1361 owns and advertises to the infrastructure. When visiting the 1362 nested structure, each Mobile Router is delegated a mobile network 1363 prefix from the access router using DHCP-Prefix Delegation. The 1364 Mobile Router registers this delegated prefix to the access router 1365 that is acting as a NEMO Home Agent. The Mobile Router also 1366 autoconfigures an address from the delegated prefix and uses it as 1367 a care-of address to register its own mobile network prefix(es) to 1368 its own Home Agent using NEMO Basic Support. It is possible for a 1369 Mobile Router to protect its own mobile network prefixes while 1370 advertising in the clear the local prefix for other Mobile Routers 1371 to roam into. This allows a strict privacy of visited and 1372 visitors, and enables some specific policies in each Mobile 1373 Router. 1375 o Neighbor Discovery Proxy (ND-Proxy) [25] 1377 The ND-Proxy approach achieves Route Optimization by having Mobile 1378 Routers to act as neighbor discovery proxy. Mobile router will 1379 configure a care-of address from the network prefix advertised by 1380 its access router, and also relay this prefix to its subnets. As 1381 ND-Proxy, Mobile Routers will also handle neighbor discovery on 1382 behalf of Visiting Mobile Nodes in its subnets. As such, the 1383 entire mobile network and its access network forms a logical 1384 multilink subnet, thus eliminating any nesting. This solution 1385 also lends itself well to achieve MIPv6-over-NEMO optimization. 1387 A.4 MIPv6-over-NEMO Optimizations 1389 Some solutions proposed for nested tunnels optimization can be 1390 extended for MIPv6-over-NEMO optimization, including Access Router 1391 Option (ARO) [16], Top Level Mobile Router (TLMR) [20], Prefix 1392 Delegation approaches [22][23][24], and Neighbor Discovery Proxy 1393 (ND-Proxy) [25]. One solution that caters specifically for 1394 MIPv6-over-NEMO optimization is: 1396 o Extended Network Mobility Support [26] 1398 This approach is somewhat similar to the Prefix Delegation in 1399 which the Mobile Router would obtain a prefix from its access 1400 network, and allows visiting mobile network nodes to autoconfigure 1401 their care-of addresses from this prefix. By doing so, packets 1402 destined to any MIPv6 node within the mobile network will not go 1403 through the Home Agent of the Mobile Router, thereby achieving 1404 MIPv6-over-NEMO optimization. This solution also allows the 1405 Mobile Router to act as Home Agent for local fixed nodes and local 1406 mobile nodes within the mobile network in an attempt to allow 1407 these nodes to achieve Route Optimization (using standard MIPv6 1408 techniques). 1410 A.5 Intra-NEMO Optimizations 1412 Currently, there are no proposals that specifically target intra-NEMO 1413 optimization, though as explained previously, most solutions that 1414 achieves MN-to-CN optimizations can also achieve intra-NEMO 1415 optimization. 1417 Intellectual Property Statement 1419 The IETF takes no position regarding the validity or scope of any 1420 Intellectual Property Rights or other rights that might be claimed to 1421 pertain to the implementation or use of the technology described in 1422 this document or the extent to which any license under such rights 1423 might or might not be available; nor does it represent that it has 1424 made any independent effort to identify any such rights. Information 1425 on the procedures with respect to rights in RFC documents can be 1426 found in BCP 78 and BCP 79. 1428 Copies of IPR disclosures made to the IETF Secretariat and any 1429 assurances of licenses to be made available, or the result of an 1430 attempt made to obtain a general license or permission for the use of 1431 such proprietary rights by implementers or users of this 1432 specification can be obtained from the IETF on-line IPR repository at 1433 http://www.ietf.org/ipr. 1435 The IETF invites any interested party to bring to its attention any 1436 copyrights, patents or patent applications, or other proprietary 1437 rights that may cover technology that may be required to implement 1438 this standard. Please address the information to the IETF at 1439 ietf-ipr@ietf.org. 1441 Disclaimer of Validity 1443 This document and the information contained herein are provided on an 1444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1446 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1447 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1448 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1451 Copyright Statement 1453 Copyright (C) The Internet Society (2005). This document is subject 1454 to the rights, licenses and restrictions contained in BCP 78, and 1455 except as set forth therein, the authors retain all their rights. 1457 Acknowledgment 1459 Funding for the RFC Editor function is currently provided by the 1460 Internet Society.