idnits 2.17.00 (12 Aug 2021) /tmp/idnits52847/draft-thubert-nemo-ro-taxonomy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 279 has weird spacing: '... C-Side ooooo...' -- 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 (October 11, 2002) is 7162 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) == Unused Reference: '10' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 449, but no explicit reference was found in the text == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-03) exists of draft-kniveton-mobrtr-02 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-01 -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: draft-ietf-manet-dsr has been published as RFC 4728 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '8') == Outdated reference: draft-ietf-manet-aodv has been published as RFC 3561 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-aodv (ref. '9') ** Obsolete normative reference: RFC 2460 (ref. '11') (Obsoleted by RFC 8200) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thubert 3 Internet-Draft M. Molteni 4 Expires: April 11, 2003 Cisco Systems 5 October 11, 2002 7 Taxonomy of Route Optimization models in the Nemo Context 8 draft-thubert-nemo-ro-taxonomy-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 11, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 Nemo enables Mobile Networks by extending Mobile IP to support Mobile 40 Routers. This paper documents how the MIPv6 concept of Route 41 Optimization can to be adapted for Nemo to optimize: 43 1) the nested tunnels of the nested Nemo configuration 45 2) router-to-router within the infrastructure as opposed to end-to- 46 end. 48 and much more ... :) 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 3 54 2.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 3 55 2.2 Route Optimization inside the Nested Mobile Network . . . . . 6 56 3. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. MIPv6 Route Optimization over Nemo . . . . . . . . . . . . . . 6 58 5. Optimization within the infrastructure . . . . . . . . . . . . 7 59 5.1 Route Optimization within a ISP network . . . . . . . . . . . 8 60 5.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 8 61 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 63 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 This document assumes the reader is familiar with Mobile IPv6 defined 70 in [1], with the concept of Mobile Router (MR) and with the Nemo 71 terminology defined in [2]. 73 From the discussions on the mailing list, it appears that the common 74 current understanding of the problem space of Route Optimization 75 (RO), in the Nemo context, is still limited. 77 This paper attempts to clarify the state of the discussion and 78 propose a taxonomy of the various aspects of the problem. 80 2. Nested Mobile Network 82 2.1 Nested Tunnels Optimization 84 Let us illustrate the problem by an example. In this example, the 85 nested Mobile Network has a tree topology. In the tree each node is 86 a basic Mobile Network, represented by its MR. 88 +---------------------+ 89 | Internet |---CN 90 +---------------|-----+ 91 / Access Router 92 MR3_HA | 93 ======?====== 94 MR1 95 | 96 ====?=============?==============?=== 97 MR5 MR2 MR6 98 | | | 99 =========== ===?========= ============= 100 MR3 101 | 102 ==|=========?== Net3 103 LFN1 MR4 104 | 105 ========= 107 An example nested Mobile Network 109 This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3) 110 inside the tree, represented by its mobile router MR3. The path to 111 the Top Level Mobile Router (TLMR) MR1 and then the Internet is: 113 MR3 -> MR2 -> MR1 -> Internet 115 Consider the case where a LFN belonging to Net3 sends a packet to a 116 Correspondent Node (CN) in the Internet, and the CN replies back. 118 With no Nested Tunnels Optimization, we would have three bi- 119 directional nested tunnels, as described in [3] and illustrated in 120 the following drawings: 122 -----------. 123 --------/ /-----------. 124 -------/ | | /----------- 125 CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN 126 MR3_HA -------\ | | \----------- MR3 127 MR2_HA --------\ \----------- MR2 128 MR1_HA ----------- MR1 130 No Nested Tunnels Optimization 132 Such a solution introduces the following problems: 134 "Pinball" routing 136 Both inbound and outbound packets will flow via the HAs of all the 137 MRs on their path within the NEMO, with increased latency, less 138 resilience and more bandwidth usage. 140 Packet size 142 An extra IPv6 header is added per level of nesting to all the 143 packets. The header compression suggested in [4] cannot be 144 applied because both the source and destination (the intermediate 145 MR and its HA), are different hop to hop. 147 On the other hand, with a Nested Tunnel Optimization, we would have 148 at most one bi-directional tunnel outside the Mobile Network, that 149 may depend on the traffic flow: 151 __- --_ 152 Tunnel---------------------------- MR1 ( Mobile ) MR3 153 CN ----------( - - - - - - - - - - ( - - - - )--------- LFN 154 Endpoint---------------------------- MR1 ( Network ) MR3 155 --___--- 157 Nested Tunnels Optimization 159 The end-point of such a Tunnel on the Mobile side may either be MR1 160 or MR3, depending on the solution. In the case of a Mobile Node 161 visiting Net3, that Mobile Node may also be the end-point. 163 The potential approaches for avoiding the nesting of tunnels include: 165 Mobile Aggregation 167 This model applies to a category of problems were the Mobile 168 Networks share a same administration and consistently move 169 together (e.g. a fleet at sea). In this model, there is a 170 cascade of Home Agents. The main Home Agent is fixed in the 171 infrastructure, and advertises an aggregated view of all the 172 Mobile Networks. This aggregation is actually divided over a 173 number of Mobile Routers, the TLMRs. The TLMRs subdivide some of 174 their address space to the other Mobile Routers forming their 175 fleet, for which they are Home Agent. As Home Agents, the TLMRs 176 terminate MIP Tunnels from the inside of the Mobile Network. As 177 Mobile Router, they also terminate their home Tunnels. As 178 routers, they forward packets between the 2 tunnels. 180 Surrogate 182 The TLMR acts as a proxy in the MIP registration, in a fashion of 183 MIPv4 Foreign Agent or HMIP MAP (see [7]). For instance, the TLMR 184 maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and 185 switches packets between the two. 187 Internal Routing and gateway 189 This item can be approached from a MANET standpoint. This was 190 already done for DSR (see [8]) and AODV (see [9] and [6]) From a 191 Nemo standpoint, a full MANET is not necessary since the goal is 192 to find a way to the infrastructure, as opposed to any-to-any 193 connectivity. 195 RRH 197 The Reverse Routing Header (RRH) approach avoids the multiple 198 encapsulation of the traffic but maintains the home tunnel of the 199 first MR on the egress path. It is described in details in [5]. 200 The first MR on the way out (egress direction) encapsulates the 201 packet over its reverse tunnel, using a form of Record Route 202 header, the RRH. 204 The next MRs simply swap their CoA and the source of the packet, 205 saving the original source in the RRH. The HA transforms the RRH 206 in a Routing Header to perform a Source Routing across the nested 207 Mobile Network, along the ingress path to the target MR. 209 These approaches are generally difficult to secure unless all the 210 Mobile Routers and Visiting Mobile Node belong to a same 211 administrative domain and share predefined Security Associations. 213 The problem is global to the whole Mobile Network in the case of a 214 MANET-based solution. For an RRH-based solution, the threat comes 215 from on-axis MRs in the nested Mobile Network but is mostly limited 216 to denial of service. This is detailed in [5]. 218 2.2 Route Optimization inside the Nested Mobile Network 220 This is not part of the Nemo Charter. The expectation is that the 221 mobile routes installed by Nemo can cohabit with a MANET support that 222 would perform the RO inside the Nested Mobile Network. 224 3. MR-to-CN 226 This section covers the case where the Route Optimization is 227 performed between the MR and the Correspondent Node. 229 A major issue is that the MIPv6 Reverse Routability test is broken, 230 since it is meant to ensure that the CoA (the MR) an the Home Address 231 (the Mobile Node) are collocated. With a Mobile Network, a LFN is 232 reachable via the Care-Of Address, but not at the Care-Of Address. 233 Some tricks may be performed on the fly by the MRs but it seems that 234 a clean MR-to-CN optimization for Nemo will impact the CN function. 236 Once we modify the CN behavior, we need to introduce a negotiation 237 from the start of the RR test to determine the protocol. In 238 particular, the Mobile Node and the CN must decide whether checking 239 the collocation is possible, and if not, whether a CN is willing to 240 accept the risk. If not, the optimization may be limited to 241 triangular routing MR->CN->HA->MR. 243 This is a major evolution from [1], since MIPv6 has no such 244 negotiation capability at this time. 246 4. MIPv6 Route Optimization over Nemo 248 When a Mobile Node visits a Mobile Network, the best Route 249 Optimization is obtained if the path in the Infrastructure is the 250 same as if the Mobile Network was attached at the attachment point of 251 the Mobile Router (i.e., there is not additional Tunneling that is 252 linked to Nemo). 254 An example of that is a Mobile Node with RRH capability. If the 255 Mobile Node emits packets with a RRH (as if it where the first MR), 256 then the MRs just add to the RRH but do not affect its path. The CN 257 must respond with RH type 2 based on RRH and if so, the MIP optimized 258 path can be used. 260 5. Optimization within the infrastructure 262 This section elaborates on cases where the Route Optimization is 263 performed within the Routing Infrastructure. In this model, both the 264 LFN behind the MR and the Correspondent can be MIP agnostic. The 265 drawback is the introduction of Mobile Routes in specific Routers, 266 causing additional signaling and load to the Routing Fabric. 268 The general idea is that there is a correspondent-side Router in the 269 infrastructure that is located "closer" to the Correspondent than the 270 HA. That Router can terminate MIP on behalf of the CN. 272 Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent 273 # n # 274 o # n # # :== Tunnel 275 o # n # o :== Optimized 276 o # n # n :== Non-Optimized 277 o # n # 278 ################################## n # 279 C-Side oooooooooooooooooooooooooooooooo Mobile 280 Router ################################ Router 281 | 282 ====Mobile Network======= 284 Optimization in the Infrastructure 286 This optimization is only valid when the path via the correspondent- 287 side Router is shorter than the path via the Home Agent. 289 The Optimization can take place independently for the 2 directions of 290 the traffic: 292 Egress 294 The MR locates the correspondent-side Router, establishes a Tunnel 295 with that Router and sets a route to the Correspondent via the 296 correspondent-side Router over the Tunnel. At this point, the 297 traffic to the Correspondent does not flow via the Home Agent 298 anymore. 300 Ingress 302 The correspondent-side Router is on the way of the traffic from 303 the Correspondent to the Home Agent. Also, it is aware of the MR 304 and the Mobile Networks behind the MR and establishes the 305 appropriate Tunnel and Route. At that point, it is able to 306 reroute the traffic to the Mobile Network over the Tunnel to the 307 MR. 309 5.1 Route Optimization within a ISP network 311 This form of Route Optimization provides local savings for a ISP. 312 This idea was described in Ohnishi's Mobile Border Gateway draft. 313 The goal is to locate the closest (BGP) gateway for a Correspondent 314 that is located outside of the domain, and tunnel between the MR and 315 that gateway as opposed to the Home Agent for that specific 316 Correspondent. 318 5.2 Correspondent Router 320 A globally better optimization is obtained if the tunnel from the MR 321 is terminated closer to the destination on the Correspondent side. 322 This is the role of a Correspondent Router (CR). 324 +-------------------+ # :== Tunnel 325 | Autonomous System | o :== Optimized 326 | ----------------- | n :== Non-Optimized 327 | | 328 | | 329 | Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent 330 | | # n # 331 | o | # n # 332 | o | # n # 333 | o | # n # 334 | o | # n # 335 | o | # n # 336 | #################################### ? 337 | CR oooooooooooooooooooooooooooooooooooooo Mobile 338 | #################################### Router 339 | | | 340 +-------------------+ ===========Mobile Network======== 342 Correspondent Router 344 The MR locates the CR for a given Correspondent and establishes a 345 Tunnel to the CR for that destination and its prefix(es). Then, the 346 CR establishes the Tunnel back to the MR and the Mobile Routes to the 347 MR's Mobile Networks via that Tunnel. 349 Clearly, some extended MIP signaling has to be defined is to get 350 there in a secure fashion. 352 A key point is that the CR must be on the interception path of the 353 traffic from the Correspondent to the Mobile Networks in order to 354 reroute the traffic over the appropriate Tunnel. This can be 355 achieved in several fashions: 357 Redistribution 359 There's a limited Number of CRs that cover an Autonomous System. 360 They redistribute the Mobile Routes on the fly, or within rate and 361 amount limits. Garbage Collection is done at appropriate time to 362 limit the perturbation on the Routing. 364 Default Router 366 The CR is a Default Router for the Correspondent, or for the whole 367 AS of the Correspondent (it's a border gateway). In this case, 368 redistribution is not needed. 370 Core Routers 372 The Core Routers for the network of the Correspondent are all CRs. 373 If the path from the correspondent to the Home Agent does not pass 374 via a CR, then it's not worth optimizing. If it is, then the CRs 375 are on the way. Again, redistribution is not needed. 377 6. Conclusion 379 The Problem space of Route Optimization in the Nemo context is 380 multifold and can be split is several work areas. It will be 381 critical, though, that the solution to a given piece of the puzzle be 382 compatible and integrate smoothly with the others. 384 Hopefully, the solutions will build on MIPv6 ([1]), as recommended by 385 the Nemo Charter. On the other hand, MIPv6 seems to be evolving in a 386 direction that makes it more and more difficult to provide a Nemo 387 solution with backward compatibility, since: 389 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side, 391 2) The RR test has no negotiable option and is not open for 392 extension, and 394 3) The HaO and RH type 2 are designed for a collocated CareOf 395 Address. More specifically, they are not designed to be multi-hop as 396 RRH is, and not extensible, though RRH can be considered as an 397 extension of HaO. 399 The authors intent is to trigger fruitful discussions that in turn 400 will enhance our common understanding of the problem space so that at 401 some point, this paper turns into a problem statement for the Nemo 402 Route Optimization. 404 7. Acknowledgements 406 The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki 407 Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji 408 Wakikawa and Patrick Wetterwald for their various contributions. 410 References 412 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 413 IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 414 2002. 416 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 417 draft-ernst-monet-terminology-01 (work in progress), July 2002. 419 [3] Kniveton, T., "Mobile Router Support with Mobile IP", draft- 420 kniveton-mobrtr-02 (work in progress), July 2002. 422 [4] Deering, S. and B. Zill, "Redundant Address Deletion when 423 Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr- 424 deletion-00 (work in progress), November 2001. 426 [5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 427 its application to Mobile Networks", draft-thubert-nemo- 428 reverse-routing-header-00 (work in progress), June 2002. 430 [6] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc 431 Networks", draft-wakikawa-manet-globalv6-01 (work in progress), 432 July 2002. 434 [7] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier, 435 "Hierarchical MIPv6 mobility management (HMIPv6)", draft-ietf- 436 mobileip-hmipv6-06 (work in progress), July 2002. 438 [8] Johnson, D., Maltz, D., Hu, Y. and J. Jetcheva, "The Dynamic 439 Source Routing Protocol for Mobile Ad Hoc Networks", draft- 440 ietf-manet-dsr-07 (work in progress), February 2002. 442 [9] Das, S., Perkins, C. and E. Royer, "Ad Hoc On Demand Distance 443 Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in 444 progress), July 2002. 446 [10] Postel, J., "Internet Protocol", STD 5, RFC 791, September 447 1981. 449 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 450 Specification", RFC 2460, December 1998. 452 Authors' Addresses 454 Pascal Thubert 455 Cisco Systems Technology Center 456 Village d'Entreprises Green Side 457 400, Avenue Roumanille 458 Biot - Sophia Antipolis 06410 459 FRANCE 461 EMail: pthubert@cisco.com 463 Marco Molteni 464 Cisco Systems Technology Center 465 Village d'Entreprises Green Side 466 400, Avenue Roumanille 467 Biot - Sophia Antipolis 06410 468 FRANCE 470 EMail: mmolteni@cisco.com 472 Full Copyright Statement 474 Copyright (C) The Internet Society (2002). All Rights Reserved. 476 This document and translations of it may be copied and furnished to 477 others, and derivative works that comment on or otherwise explain it 478 or assist in its implementation may be prepared, copied, published 479 and distributed, in whole or in part, without restriction of any 480 kind, provided that the above copyright notice and this paragraph are 481 included on all such copies and derivative works. However, this 482 document itself may not be modified in any way, such as by removing 483 the copyright notice or references to the Internet Society or other 484 Internet organizations, except as needed for the purpose of 485 developing Internet standards in which case the procedures for 486 copyrights defined in the Internet Standards process must be 487 followed, or as required to translate it into languages other than 488 English. 490 The limited permissions granted above are perpetual and will not be 491 revoked by the Internet Society or its successors or assigns. 493 This document and the information contained herein is provided on an 494 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 495 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 496 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 497 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 498 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Acknowledgement 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society.