idnits 2.17.1 draft-clausen-nemo-ro-problem-statement-00.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 3667, Section 5.1 on line 22. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 14) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (15 October 2004) is 7133 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) == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-02 ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '2') == Outdated reference: A later version (-01) exists of draft-wakikawa-nemo-orc-00 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-00 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Experimental RFC: RFC 3561 (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '8') -- No information found for draft-na-nemo-path-con-trol-header - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-04) exists of draft-thubert-nemo-ro-taxonomy-02 -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Normative reference to a draft: ref. '11' -- No information found for draft-thu-bert-nemo-reverse-routing-header - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-03 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Clausen 2 IETF NEMO Working Group Emmanuel Baccelli 3 Expiration: 15 April 2005 LIX, Ecole Polytechnique, France 4 Ryuji Wakikawa 5 Keio University/WIDE 6 15 October 2004 8 NEMO Route Optimisation Problem Statement 9 draft-clausen-nemo-ro-problem-statement-00.txt 11 Status of this Memo 13 This document is a submission to the Network Mobility Working Group 14 of the Internet Engineering Task Force (IETF). Comments should be 15 submitted to the nemo@ietf.org mailing list. 17 Distribution of this memo is unlimited. 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 or will be disclosed, and any of which I become aware will be 22 disclosed, in accordance with RFC 3668. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC 2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 The NEMO working group has developed a protocol suite, extending the 45 notion of edge-mobility on the Internet to include that of network 46 mobility. This implies that a set of nodes, along with their mobile 47 router, change their point of attachment and that traffic to these 48 nodes is tunneled to be delivered through their new point of 49 attachment. This mechanism is transparent to applications in that 50 existing traffic to a node is being encapsulated and tunneled, 51 regardless of where the network containing the destination node is 52 attached. 54 The NEMO specification is not limited to a single level of mobile 55 networks, attaching to the stationary Internet. Rather, arbitrary 56 levels of nested mobile networks are supported, employing for each 57 level of nesting the same encapsulation and tunneling mechanisms. 59 With arbitrarily deep nested mobile networks, the overhead incurred 60 through tunneling and encapsulation of data traffic can, however, 61 become large. As a consequence, a number of different proposals 62 exist, which aim at performing "route optimization" for nested mobile 63 networks. 65 This document aims at describing the different scenarios in which 66 route-optimization is desired, as well as the different proposed 67 solutions for achieving route-optimization in nested mobile networks. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.1.1. Route Optimization Mechanisms Within Nested NEMO . . . . . . 9 80 3.1.2. Ad-hoc Network of Mobile Routers . . . . . . . . . . . . . . 9 81 3.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.2.1. Route Optimization Mechanisms Initiated by MR or MNN . . . . 11 83 3.2.2. Route Optimization Initiated by a Non-Mobile Router . . . . . 12 84 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 The NEMO protocol suite extends Mobile IP in enabling a set of nodes, 94 along with their mobile router, to change their point of attachment 95 to the Internet. NEMO enables the traffic to these nodes to be tun- 96 neled for delivery through their new point of attachment. The use of 97 tunneling makes this mechanism transparent to applications, wherever 98 the new point of attachement, even in case of several layers of 99 nested mobility (i.e. mobile nodes, or mobile routers, indirectly 100 accessing the Internet through other mobile routers). 102 However, this approach is not without a certain cost: with arbitrar- 103 ily deep nested mobile networks, the overhead due to tunneling, dog- 104 leg routing and encapsulation of data traffic can become large. A 105 number of different solutions have been proposed in order to optimize 106 this routing in some of these cases. 108 A review of some of these solutions is provided in this document, as 109 well as the discussion of which cases and to what extent route opti- 110 mization is desireable with NEMO. 112 1.1. Terminology 114 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC2119 [5]. 118 It is assumed that readers are familiar with NEMO terminology as 119 described and employed in [1] and [8]. 121 1.2. Applicability 123 This document aims at discussing scenarios where route optimization 124 is desirable in a NEMO environment, and what level of route optimiza- 125 tion is desired in those cases. A review of some existing solutions 126 and ideas is thereby provided. 128 2. Scenarios 130 At least two distinct scenarios exist, where route optimization is 131 desireable. Those are, respectively, when a node in a NEMO network 132 wishes to communicate with a node in another NEMO network which is 133 part of the same nesting, and when a node from the Internet wishes to 134 communicate with a node in a nested NEMO network. 136 While the scenarios may have commonalities, their possible solution- 137 space differs and they are therefore described seperately below. 139 2.1. NEMO-to-NEMO 141 In this scenario, a number of NEMO networks are nested to one 142 another, and nodes in the different NEMO networks are communicating 143 with one another. For the purpose of this scenario description, refer 144 to the schematics below: 146 ---------- ---------- ---------- 147 | | | | | | 148 | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet 149 | | | | | | | 150 ---------- ---------- ---------- | 151 | ---------- 152 ---------- | | | 153 | | |----| HA 2 | 154 | HA 1 |---------| | | 155 | | | ---------- 156 ---------- | 157 ---------- 158 | | 159 | HA 3 | 160 | | 161 ---------- 163 Figure 1: Nested NEMO networks -- NEMO-to-NEMO communication 165 We assume that each box labeled "NEMO x" refers to a Mobile Router 166 (MR), running the NEMO protocol, as well as the nodes attached to 167 that mobile router. We further assume, that each line indicates a 168 direct connection between routers -- i.e. the mobile router in "NEMO 169 1" has a direct connection to the mobile router in "NEMO 2". Each box 170 labeled "HA x" refers to the Home Agent for the NEMO network x -- 171 i.e. that HA 1 is the Home Agent for the mobile network NEMO 1. 173 If a node from NEMO 3 wishes to communicate with a node from "NEMO 174 1", then the data traffic would first be sent to the Home Agent of 175 NEMO 1 -- i.e. to HA 1. At HA 1, a binding would exist, identifying 176 NEMO 1 as being attached to the network of NEMO 2. Thus, the traffic 177 would be encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA 178 2, a binding would exist, identifying that, indeed, NEMO 2 is 179 attached to the network of NEMO 3. Another encapsulation would 180 ensure, and the traffic sent to HA 3. At HA 3, a binding would 181 identify the point of attachment of NEMO 3 to the internet, and the 182 data traffic would be encapsulated one final time prior to being 183 delivered to NEMO 3 -- where decapsulation and handoff to NEMO 2, 184 then NEMO 1 occurs. 186 In this scenario, short path between NEMO 1 and NEMO 3, without 187 transversing the Internet and HA1-3, exists, however is not used in 188 the current NEMO specification. 190 More generally, assume a set of NEMO networks forming a connected 191 network via their mobile routers without transversing the Internet. 192 For communication between nodes in these NEMO networks, a solution 193 should exist, which provides routes between the nodes without 194 transversing the Internet and without incuring excessive nested 195 encapsulations. 197 2.2. Internet-to-NEMO 199 In this scenario, a number of NEMO networks are nested to one 200 another, and a node in the Internet wishes to communicate to a node 201 in one of the NEMO networks. For the purpose of this scenario 202 description, refer to the schematics below: 204 ---------- ---------- ---------- ---------- 205 | | | | | | | | 206 | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Node 1 | 207 | | | | | | | | | 208 ---------- ---------- ---------- | ---------- 209 | ---------- 210 ---------- | | | 211 | | |----| HA 2 | 212 | HA 1 |---------| | | 213 | | | ---------- 214 ---------- | 215 ---------- 216 | | 217 | HA 3 | 218 | | 219 ---------- 221 Figure 2: Nested NEMO networks -- Internet-to-NEMO communication 223 The node labeled "Node 1" wishes to communicate with a node in NEMO 224 1. Similarly to the previous scenario, this will happen through con- 225 necting to HA 1, then encapsulation and tunneling data to HA 2 and 226 HA3 before the data arrives at the edge of our nested NEMO network. 228 Only then can decapsulation and transmission via NEMO 3, NEMO 2 and 229 NEMO 1 happen. 231 In this scenario, while no direct link exists between Node 1 and the 232 node in NEMO 1, triple encapsulation and transmission via HA1-3 233 occurs. 235 More generally, a path between a node in the Internet and the edge of 236 the nested NEMO networks exists, which does not necessarilly involve 237 any of the Home Agents for the NEMO networks. For such communication, 238 a solution should exist which avoids nested encapsulations (i.e. 239 allows data to be encapsulated only once, in order to arrive at the 240 edge of the nested NEMO networks), and which does not force a path 241 which involves all the Home Agents of the nested NEMO networks on the 242 path to the destination. 244 In addition, nested encapsulation brings a limitation to the number 245 of nested levels, due to MTU size. For example, the current NEMO 246 basic support specification does not allow a level higher than 40 in 247 nesting in NEMO (with usual MTU = 1500 bytes), due to the size of the 248 40 IPv6 headers, i.e. 40 bytes x 40 > MTU. In this case IP fragmen- 249 tation does not help, since the total size of IPv6 headers exceeds 250 the MTU. Thus, the avoidance of nested encapsulations also eliminates 251 the limitation on the level of nesting in NEMO. 253 3. Solutions 255 Common for the scenarios from the previous section is, that the 256 encapsulation and tunneling is due to the facts that: 258 - the node which originates data traffic does not know where the 259 destination node is located and therefore assumes that the 260 node is at its Home Network; 262 - no router knows the full path to the destination, which in 263 particular means that: 265 - no router knows the topology of the nested NEMO network(s). 267 As a concequence, each logical hop (from source to Home Agent of des- 268 tination, or from Home Agent to Home Agent of the nested NEMO net- 269 works) adds layers of encapsulation, until the point of attachment 270 between the Internet and the NEMO edge, the Access Router (AR) is 271 reached. 273 Concequently, if the source node, or any intermediate node, had addi- 274 tional information about the network topology, more beneficial 275 tunnels could be created, and less encapsulation would be required. 277 For example if, in figure 2 above, Node 1 knew directly that the 278 gateway from the Internet to "the network where nodes from NEMO 1 are 279 attached" was the Access Router of NEMO 3, and if the mobile router 280 in NEMO 3 knew the topology of the nested NEMO network, a tunnel 281 could be directly created from Node 1 to NEMO 3, with assurance that 282 the mobile router in NEMO 3 would be able to route data packets cor- 283 rectly to the destination. 285 3.1. NEMO-to-NEMO 287 The NEMO-to-NEMO problem, as described in section 2.1, is one of how 288 to avoid transversing the Internet in order to communicate between 289 two nodes which are part of the same nested NEMO network. More gener- 290 ally, this can be expressed as "how traffic is routed within the NEMO 291 network". 293 NEMO basic support [1] specifies that traffic be routed via Home 294 Agents, indicating an assumption of limited depth of nested networks 295 and traffic patterns being predominantly traffic of the Internet-to- 296 NEMO type. Each mobile router in a NEMO network knows only of its 297 attachments, i.e. its access router and the nodes within its own 298 mobile network. A mobile router in NEMO does not know about any nest- 299 ings, i.e. it does not know the topology of the nested NEMO network 300 -- and as such, can only provide routes to the Home Agents on the 301 Internet. 303 In order to avoid the scenario described in section 2.1, where data 304 packets for delivery within the nested NEMO network are routed 305 through the Internet and the nested networks Home Agents, when a more 306 localized aproach would have been possible, additional state can be 307 maintained in the nested NEMO networks. A number of approaches for 308 maintaining state in mobile routers and/or Home Agents of mobile net- 309 works have been discussed, including [3], [4], [9], [10], [11], [12], 310 [13], in which techniques such as route caching are discussed. These 311 techniques can be deployed in Home Agents, in routers, specifically 312 designated as aggregation points for NEMO tunnels, as well as within 313 the mobile routers in order to optimize routes within a nested NEMO 314 network. This is detailed in section 3.1.1. 316 Essentially, however, the issue of route optimization within a nested 317 NEMO network is one of routing: maintaining state in each mobile 318 router such that an intelligent forwarding decision can be made. 319 I.e., if the destination can be detected to be "local" to the nest of 320 NEMO networks, a route to the destination can be constructed directly 321 through the NEMO mobile routers without passing through the Home 322 Agents. Alternatively, if the destination is not local, data are 323 routed to the Home Agent, where basic NEMO tunneling and encapsula- 324 tion take effect. Deploying a routing protocol for maintaining suffi- 325 cient state in the nodes in the nested NEMO network is detailed in 326 section 3.1.2. 328 3.1.1. Route Optimization Mechanisms Within Nested NEMO 330 Some approaches have been proposed to tackle the problem of route 331 optimization inside nested NEMO networks. For instance, Nested NEMO 332 Tree Discovery [4] offers a mechanism that aims at avoiding routing 333 loops by organizing and maintaining a tree structure within the net- 334 work of nested NEMOs, the root being the Access Router or the Mobile 335 Router directly connected to the Access Router (the Top Level Mobile 336 Router). 338 Source routing is also proposed to be used in this environment. 339 Approaches like RRH [12] use the recording of the sequences of tra- 340 versed Mobile Routers on the way out of the nested NEMO network (to 341 the Internet, say, to bind) in order to forward traffic efficiently 342 in the nested NEMO network. 344 On the other hand, approaches like ORC (Optimized Route Cache Proto- 345 col [3]) could be adapted to serve the purpose of insuring some level 346 of optimized routing inside nested NEMO networks. Some router, say 347 the top level mobile router, could be configured to play a role simi- 348 lar to a correspondent router, organizing the forwarding of packets 349 inside the nested NEMO network. This special router could be dynami- 350 cally discovered inside the nested NEMO network. 352 A more general form of this mechanism would be to have each MR in the 353 nested NEMO network possess this extended information about the 354 nested NEMO network. This does then, de-facto, become a situation 355 where each MR knows the entire topology of the nested NEMO network, 356 and will be able to act in the capacity of router for such traffic. 357 This generalized mechanism is described in more details in section 358 3.1.2. 360 3.1.2. Ad-hoc Network of Mobile Routers 362 A NEMO network consists of a mobile router, to which a set of nodes 363 are (statically) attached. The mobile router communicates with (i.e. 364 has direct links with) other mobile routers, and possibly with the 365 Internet at large. As such, a NEMO network is not much different from 366 any other network. What makes NEMO networks different from other net- 367 works is, that they may change their point of attachment at will -- 368 i.e. the topology formed by NEMO mobile routers is dynamic. 370 Thus, in order to provide routes between any two nodes in the nested 371 NEMO network, a mechanism must be in place which ensures that the 372 dynamic topology of the nested NEMO network can be accurately tracked 373 and used for routing table calculations. 375 The IETF MANET working group has been developing routing protocols 376 for dynamic ad-hoc networks, such as OLSR [2] and AODV [6] (both 377 RFC), with the characteristics that the developed protocols should be 378 light-weight, able to react to rapid topology changes and limit the 379 signalling overhead. An approach to route optimization within the 380 NEMO-to-NEMO scenario could therefore be to consider the mobile 381 routers of the nested NEMO networks as nodes in an ad-hoc network, 382 and run an ad-hoc routing protocol to ensure that each mobile router 383 would be able to determine if data could be locally (i.e. within the 384 nested NEMO network) delivered, or had to be tunneled back to the 385 Home Agent. 387 OLSR [2], for example, provides light-weight OSPF-like [7] routing 388 functionality. This includes efficient maintenance of the topology 389 spanned by the links between the mobile routers in the face of net- 390 work dynamics, as well as the ability for a mobile router to adver- 391 tize associated nodes which do not run the OLSR routing protocol 392 (e.g. nodes associated to a mobile router, which are not themself 393 mobile routers). It is also possible for Mobile Network Nodes to 394 obtain global connectivity, as described in [16]. 396 Employing a protocol such as OLSR among the mobile routers in a 397 nested NEMO network would yield the ability for any mobile router to 398 determine if a destination can be reached through a path local to the 399 nested NEMO network, or if forwarding to the Home Agent is required. 400 Additionally, this would also ease the Internet-to-NEMO scenario. In 401 order to deliver an IP datagram to a node in the nested NEMO network, 402 only a path to the access router between the nested NEMO network and 403 the Internet would be required: once an IP datagram arrives in the 404 nested NEMO network, the routing tables in the mobile routers, as 405 provided by OLSR, would allow direct routing to the destination. 406 Thus, there would no longer be a requirement to do nested encapsula- 407 tion on each logical hop (i.e. each transversal of a Home Agent) in 408 order to be able to decapsulate and correctly forward IP datagrams in 409 the nested NEMO network. 411 Thus even if no route optimizations are performed in the Internet-to- 412 NEMO scenario, an overhead reduction can still be achieved through 413 much lower encapsulation requirements. 415 3.2. Internet-to-NEMO 417 The goal here is, again, to avoid unnecessary encapsulation and dog- 418 leg routing. Indeed, it is desirable to avoid letting the level of 419 nested mobility on the edges of the network dictating the number of 420 Home Agents (and therefore the amount of encapsulation) the packets 421 have to go through. There should be a way to limit the level of tun- 422 neling to only one encapsulation IP in IP, and at the same time, min- 423 imize the traffic relayed by Home Agents. 425 Existing solution to route optimization problems in NEMO therefore 426 aim at, basically, minimizing the required amount of tunneling in 427 various nested mobility cases. They can be categorized as follows: 429 - route optimization initiated by Mobile Routers (MR) or Mobile 430 Network Nodes (MNN); 432 - route optimization initiated by intermediate non-mobile 433 routers on the path to Corresponding Nodes. 435 The following sub-sections briefly review these solutions. 437 3.2.1. Route Optimization Mechanisms Initiated by MR or MNN 439 In case of nested mobility (i.e. a mobile router attaches to another 440 mobile router, or a visiting mobile node attaches to a mobile 441 router), several encapsulations will occur on top of each other, and 442 a sub-optimal path will be used to reach the destination, going 443 through each and every Home Agent. In order to slim this down, sev- 444 eral nested tunnel optimizations have been discussed. 446 The HMIP-like mechanisms suggested in [15] or the TLMR (Top Level 447 Mobile Router [11]) approach use one or more Mobile Routers chosen 448 for their location (closest to the Access Router) to act as proxy for 449 Mobile IP, and/or act as Home Agents for other mobile nodes inside 450 the attached mobile networks, like proposed in [14]. Instead of 451 adding another layer encapsulation, those TLMR switch between ingress 452 and egress tunnels and can reduce the amount of binding. 454 Similarily, ARO (Access Router Option [13]) proposes nested tunnel 455 optimizations based on the registration of the top level Access 456 Router of any nested NEMO to the Home Agent in order to bypass the 457 HAs of all the MR on the way to the Access Router. 459 On the other hand, source routing approaches like RRH (Reverse 460 Routing Header [12]) or Path Control Header [9] use loose source 461 routing in order to avoid IP encapsulation. However, source routing 462 is not always desirable, and might not be widely accepted. 464 3.2.2. Route Optimization Initiated by a Non-Mobile Router 466 Some approaches such as ORC (Optimized Route Cache Protocol [3]) or 467 other proposals using so called Anchor Routers or Correspondent side 468 routers (see [10] for further references), advocate the adding of new 469 functionalities in some routers that are ideally chosen to be opti- 470 mally placed with respect to traffic flows between ASs. Those routers 471 intercept and terminate the tunneling on behalf of the Correspondent 472 Node, therefore optimizing the route from then on. However, this is 473 not easy to deploy, and the optimization is partial. 475 4. Acknowledgements 477 The authors would like to thank Hitachi Labs Europe for their support. 479 5. Authors' Addresses 481 Thomas Heide Clausen, 482 Project PCRI 483 Pole Commun de Recherche en Informatique du plateau de Saclay, 484 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 485 Ecole polytechnique, 486 Laboratoire d'informatique, 487 91128 Palaiseau Cedex, France 488 Phone: +33 1 69 33 40 73, 489 Email: T.Clausen@computer.org 491 Emmanuel Baccelli 492 HITACHI Labs Europe/ Project PCRI, 493 Pole Commun de Recherche en Informatique du plateau de Saclay, 494 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 495 Ecole polytechnique, 496 Laboratoire d'informatique, 497 91128 Palaiseau Cedex, France 498 Phone: +33 1 69 33 40 73, 499 Email: Emmanuel.Baccelli@inria.fr 501 Ryuji Wakikawa 502 Keio University and WIDE 503 5322 Endo Fujisawa Kanagawa 504 252 JAPAN 505 Phone: +81-466-49-1394 506 EMail: ryuji@sfc.wide.ad.jp 507 Fax: +81-466-49-1395 509 6. References 511 [1] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo 512 Basic Support Protocol (work in progress). Internet Draft (draft- 513 ietf-nemo-basic-support-02), Internet Engineering Task Force, 514 December 2003. 516 [2] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol. 517 Request for Comments (Experimental) 3626, October 2003. 519 [3] R. Wakikawa, M. Watari. Optimized Route Cache Protocol (ORC) (work 520 in progress). Internet Draft (draft-wakikawa-nemo-orc-00.txt), 521 Internet Engineering Task Force, July 2004. 523 [4] P. Thubert, N. Montavont. Nested Nemo Tree Discovery (work in 524 progress). Internet Draft (draft-thubert-tree-discovery-00.txt), 525 Internet Engineering Task Force, May 2004. 527 [5] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev- 528 els. Request for Comments (Best Current Practice) 2119, Internet 529 Engineering Task Force, March 1997. 531 [6] C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vec- 532 tor (AODV) Routing, Request for Comments (Experimental) 3561, July 533 2003 535 [7] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 537 [8] T. Ernst, H-Y. Lach. Network Mobility Support Terminology (work in 538 progress). Internet Draft (draft-ietf-nemo-terminology-01), Inter- 539 net Engineering Task Force, February 2004. 541 [9] Jongkeun Na et al. Route Optimization Scheme based on Path Control 542 Header (work in progress). Internet Draft (draft-na-nemo-path-con- 543 trol-header-00), Internet Engineering Task Force, April 2004. 545 [10] P. Thubert et al. Taxonomy of Route Optimization models in the Nemo 546 Context (work in progress). Internet Draft (draft-thubert-nemo-ro- 547 taxonomy-02), Internet Engineering Task Force, February 2004. 549 [11] H. Kang et al. Route Optimization for Mobile Network by Using Bi- 550 directional Between Home Agent and Top Level Mobile Router (work in 551 progress). Internet Draft (draft-hkang-nemo-ro-tlmr-00.txt), Inter- 552 net Engineering Task Force, June 2003. 554 [12] P. Thubert et al. IPv6 Reverse Routing Header and its application 555 to Mobile Networks (work in progress). Internet Draft (draft-thu- 556 bert-nemo-reverse-routing-header-05), Internet Engineering Task 557 Force, June 2004. 559 [13] C. Ng et al. Securing Nested Tunnels Optimization with Access 560 Router Option (work in progress). Internet Draft (draft-ng-nemo- 561 access-router-option-01), Internet Engineering Task Force, July 562 2004. 564 [14] E. Perera et al. Extended Network Mobility Support (work in 565 progress). Internet Draft (draft-perera-nemo-extended-00.txt), 566 Internet Engineering Task Force, July 2003. 568 [15] H. Ohnishi et al. HMIP based Route Optimization Method in a Mobile 569 Network (work in progress). Internet Draft (draft-ohnishi-nemo-ro- 570 hmip-00.txt), Internet Engineering Task Force, April 2003. 572 [16] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net- 573 works (work in progress). Internet Draft (draft-wakikawa-manet- 574 globalv6-03.txt), Internet Engineering Task Force, October 2003. 576 7. Changes 578 This is the initial version of this specification. 580 8. IANA Considerations 582 This document does currently not specify IANA considerations. 584 9. Security Considerations 586 This document does not specify any security considerations. 588 10. Copyright 589 Copyright (C) The Internet Society (2004). This document is subject 590 to the rights, licenses and restrictions contained in BCP 78, and 591 except as set forth therein, the authors retain all their rights. 593 This document and the information contained herein are provided on an 594 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 595 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 596 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 597 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 598 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 599 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.