idnits 2.17.1 draft-clausen-nemo-ro-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 441. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2007) is 6261 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-ro-space-analysis (ref. '3') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-ro-problem-statement (ref. '4') Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 (MA)NEMO E. Baccelli 3 Internet-Draft INRIA 4 Expires: September 6, 2007 T. Clausen 5 LIX, Ecole Polytechnique, France 6 R. Wakikawa 7 Keio University, WIDE 8 March 5, 2007 10 NEMO Route Optimisation Problem Statement 11 draft-clausen-nemo-ro-problem-statement-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 6, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The NEMO basic support specification is not limited to a single level 45 of mobile networks attaching to the stationary Internet. Rather, 46 arbitrary levels of nested mobile networks are supported, employing 47 for each level of nesting the same attachment, encapsulation and 48 tunnelling mechanisms. With arbitrarily deep nested mobile networks, 49 paths taken by data traffic can be extremely sub-optimal both inside 50 the nested topology through successive mobile routers, and outside 51 the nested topology, through successive Home Agents over the 52 Internet. Moreover, the overhead incurred through tunnelling and 53 encapsulation of data traffic can become prohibitively large. This 54 document analyses the scenarios in which these problems are 55 particularly acute. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Internet - Nested NEMO Communication . . . . . . . . . . . 5 63 3.2. Intra Nested NEMO Communication . . . . . . . . . . . . . 6 64 3.3. RFC3963 Loops . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Lack of Nested Topology State Information . . . . . . . . 8 67 4.2. Goals of Route Optimization for Nested NEMO networks . . . 9 68 4.3. Solution Guidelines . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Introduction 77 The NEMO basic support specification [1] extends the notion of edge- 78 mobility on the Internet to include that of network mobility. This 79 implies that a set of nodes, along with their mobile router, change 80 their point of attachment and that traffic to these nodes is 81 tunnelled to be delivered through their new point of attachment. 82 This mechanism is transparent to applications in that existing 83 traffic to a node is being encapsulated and tunnelled, regardless of 84 where the network containing the destination node is attached. 86 The NEMO basic support specification is furthermore not limited to a 87 single level of mobile networks attaching to the stationary Internet. 88 Rather, arbitrary levels of nested mobile networks are supported, 89 employing for each level of nesting the same transparent mechanisms 90 relying on attachment, encapsulation and tunnelling. 92 However, with arbitrarily deep nested mobile networks, paths taken by 93 data traffic can become extremely sub-optimal both (i) inside the 94 nested topology through successive mobile routers, and (ii) outside 95 the nested topology, through successive Home Agents over the 96 Internet. Moreover, the overhead incurred through tunnelling and 97 encapsulation of data traffic can become prohibitively large. 99 This document describes cases where problems due to sub-optimal data 100 traffic paths and encapsulation overhead are acute, providing a 101 discussion of which cases and to what extent route optimisation is 102 desirable with NEMO. 104 2. Terminology 106 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [5]. 110 It is moreover assumed that readers are familiar with NEMO 111 terminology as described and employed in [1] and [2]. 113 3. Deployment Scenarios 115 Two categories of scenarios exist, where route optimisation is 116 desirable. Those are, respectively: (i) when a host from the 117 Internet wishes to communicate with a host in a nested NEMO, and (ii) 118 when a host in a nested NEMO wishes to communicate with a host in 119 another nested NEMO which is part of the same nested NEMO topology. 120 Some of these issues are also elaborated in [4]. 122 3.1. Internet - Nested NEMO Communication 124 In this category of scenario, a number of NEMO networks are nested to 125 one another, and a host in the Internet wishes to communicate with a 126 host in one of the NEMO networks. For the purpose of describing this 127 scenario, the example depicted in Fig. 1 below is considered. 129 ---------- ---------- ---------- ---------- 130 | | | | | | | | 131 | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Host 1 | 132 | | | | | | | | | 133 ---------- ---------- ---------- | ---------- 134 | ---------- 135 ---------- | | | 136 | | |----| HA 2 | 137 | HA 1 |---------| | | 138 | | | ---------- 139 ---------- | 140 ---------- 141 | | 142 | HA 3 | 143 | | 144 ---------- 146 Figure 1: Nested NEMO networks -- Internet-to-NEMO communication 148 We assume that each box labelled "NEMO x" refers to a Mobile Router 149 (MR), running the NEMO protocol, as well as the hosts attached to 150 that mobile router. We further assume, that each line indicates a 151 direct connection between routers -- i.e. the mobile router in "NEMO 152 1" has a direct connection to the mobile router in "NEMO 2". Each 153 box labelled "HA x" refers to the Home Agent for the NEMO network x 154 -- i.e. that HA 1 is the Home Agent for the mobile network NEMO 1. 156 The host labelled "Host 1" wishes to communicate with a host in NEMO 157 1. Data traffic will first be routed through HA 1 the Home Agent of 158 NEMO 1. At HA 1, a binding would exist, identifying NEMO 1 as being 159 attached to the network of NEMO 2. Thus, the traffic would be 160 encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA 2, a 161 binding would exist, identifying that, indeed, NEMO 2 is attached to 162 the network of NEMO 3. Another encapsulation would ensure, and the 163 traffic sent to HA 3. At HA 3, a binding would identify the point of 164 attachment of NEMO 3 to the internet, and the data traffic would be 165 encapsulated one final time prior to being delivered to NEMO 3 -- 166 where decapsulation and handoff to NEMO 2, then NEMO 1 occurs. 168 This simple example scenario therefore involves communication with 169 (i) triple encapsulation of the data, and (ii) its transmission via 3 170 arbitrary locations across the Internet. More generally, if instead 171 of a depth 3 the nested NEMO structure had a depth N, the 172 communication would involve worst case N levels of encapsulation of 173 the data, and its transmission via N arbitrary locations across the 174 Internet. This is thus very sub-optimal communication across the 175 Internet ([3]. 177 3.2. Intra Nested NEMO Communication 179 In this category of scenario, a number of NEMO networks are nested to 180 one another, and hosts in the different nested NEMOs are 181 communicating with one another. For the purpose of describing this 182 scenario, the example depicted in Fig. 2 below is considered. 184 ---------- ---------- ---------- 185 | | | | | | 186 | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet 187 | | | | | | | 188 ---------- ---------- ---------- | 189 | ---------- 190 ---------- | | | 191 | | |----| HA 2 | 192 | HA 1 |---------| | | 193 | | | ---------- 194 ---------- | 195 ---------- 196 | | 197 | HA 3 | 198 | | 199 ---------- 201 Fig. 2: Nested NEMO networks -- NEMO-to-NEMO communication 203 If a host from NEMO 3 wishes to communicate with a host from NEMO 1, 204 then the data traffic would first be sent out the nested NEMO 205 network, over the Internet to HA 1. The data traffic would then be 206 encapsulated and tunnelled to HA 2, which will in turn add another 207 layer of encapsulation and tunnel the traffic to HA3 which will do 208 the same before the data returns to our nested NEMO network. 209 Successive decapsulation and transmission via NEMO 3, NEMO 2 and NEMO 210 1 will then happen before data is delivered to the destination. 212 Again, this simple example scenario involves communication with (i) 213 triple encapsulation of the data, and (ii) its transmission via 3 214 arbitrary locations across the Internet. And again, more generally, 215 if instead of a depth 3 the nested NEMO structure had a depth N, the 216 communication would involve N levels of encapsulation of the data, 217 and its transmission via N arbitrary locations across the Internet. 218 This is therefore very sub-optimal communication across the Internet, 219 as communication inside the nested NEMO network should be sufficient. 221 3.3. RFC3963 Loops 223 [1] allows for NEMO mobile routers to nest to one another, however 224 does not stipulate how to form the links of the nest. In particular, 225 [1] allows for, as is illustrated in the following Fig. 3, NEMO 1 to 226 select NEMO 2 as its point of attachment, with NEMO 2 selecting NEMO 227 3 as point of attachment and NEMO 3 selecting NEMO 1 - thereby 228 forming a loop. Absent other mechanisms, this loop will persist, 229 potentially disconnecting both NEMO 1, NEMO 2 and NEMO 3 from the 230 wider network, from the Internet, and - if traffic between NEMO nodes 231 is tunnelled through HAs, also from each other. [1] does not provide 232 functionality allowing to detect this loop: a MR cannot know whether 233 it connects to a mobile network or a general IPv6 network. 235 ---------- ---------- 236 | |--| | 237 | NEMO 1 | | NEMO 2 | 238 | | | | 239 ---------- ---------- 240 | | 241 ---------- 242 | | 243 | NEMO 3 | 244 | | 245 ---------- 247 Fig. 3: Loop in Nested NEMO networks 249 4. Problem Statement 251 Encapsulation and tunnelling specified by NEMO basic support [1] are 252 governed by the following principles: 254 1. A router which forwards data traffic does not know where the 255 destination is located and therefore assumes that it is at its 256 Home Network; 258 2. A Home Agent does not know if a NEMO is directly or indirectly 259 bound to the Internet, which in particular means that: 261 3. No router knows the topology of the nested NEMO network(s). 263 While these principles are functional, they have the consequences 264 that are described in the following. 266 4.1. Lack of Nested Topology State Information 268 The lack of state information about the nested NEMO topology and its 269 point(s) of attachment to the Internet causes routing to involve 270 logical hops (from source to Home Agent of destination, or from Home 271 Agent to Home Agent), each of those adding a layer of encapsulation 272 and a detour across the Internet, until a point of attachment between 273 the Internet and the nested NEMO network is reached. 275 This lack causes extreme data paths sub-optimality and extreme data 276 encapsulation overhead in cases where the nested topology is of depth 277 greater than 2, as depicted in Section 3.2 and Section 3.1. 279 The following items summarise the problems incurring from lack of 280 nested topology state information: 282 Internet Route Suboptimality - where traffic from the internet 283 transverses more than one HA, incurring both route sub-optimality 284 and nested encapsulation; 286 Intra-NEMO Route Suboptimality - where traffic between hosts in the 287 nested NEMO network is forced through the Internet gateway and 288 subsequently through one or more HAs, incurring both route sub- 289 optimality and nested encapsulation; 291 Intra-NEMO loops - where, due to unfortunate selection of which MR 292 is attaching to which MR, loops occur. 294 4.2. Goals of Route Optimization for Nested NEMO networks 296 The goal of route optimisation for nested NEMO is to alleviate the 297 problems regarding (i) Internet route sub-optimality, (ii) Intra-NEMO 298 route sub-optimality, and (iii) Intra-NEMO loops. Additional 299 information about the nested topology must be available to Mobile 300 Routers and/or Home agents, which: 302 o may serve to allow NEMO MRs to detect and alleviate loops or to 303 prevent such from occurring in the first place. Specifically, 304 this allows a NEMO MR to ensure that a loop-free path to the 305 Internet Gateway exists; 307 o may serve to establish and maintain an intra-NEMO routing mesh, 308 allowing to bypass the Internet Gateway and HAs for intra-NEMO 309 communications; 311 o may serve to bypass dog-leg routing in communications from sources 312 on the Internet to a mobile node in the nested NEMO network. 314 4.3. Solution Guidelines 316 A solution to the NEMO Route Optimisation problem will: 318 o provide a mechanism whereby each MR has sufficient topological 319 awareness such that it may select the router(s) to which it 320 attaches such that routing loops are avoided; 322 o provide a mechanism whereby each MR has sufficient topological 323 awareness such that it may select a suitable path towards the 324 Internet Gateway for communication towards the Internet and - in 325 particular - towards its HA; 327 o provide a mechanism whereby each Internet Gateway has sufficient 328 topological awareness such that it may select a suitable path 329 towards each MR in the nested NEMO network for which it is 330 providing Internet access; 332 o provide a mechanism whereby each MR has sufficient topological 333 awareness such that it may select a suitable path towards another 334 MR within the NEMO without transversing the Internet Gateway; 336 o provide a mechanism whereby each MR has sufficient topological 337 awareness such that it may provide suitable binding updates with 338 its HA. A particular case of this is if the MR can provide 339 binding updates such that multiple encapsulations and sub-optimal 340 routes on the Internet can be avoided when a MR is connected to 341 the Internet Gateway through multiple intermediate MRs in the NEMO 342 nest. 344 Mechanisms developed for maintaining and using such information must 345 address the distributed, multi-hop nature of nested NEMO networks, 346 and be able to follow topology and connectivity changes by updating 347 state information in Mobile Routers and/or Home Agents accordingly. 349 Solutions must achieve their task while being conservative in their 350 network resource consumption and while avoiding prohibitively long 351 delays. 353 5. Security Considerations 355 This document does currently not specify security considerations. 357 6. IANA Considerations 359 This document does currently not specify IANA considerations. 361 7. References 363 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 364 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 365 2005. 367 [2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", 368 draft-ietf-nemo-terminology-06 (work in progress), 2006. 370 [3] NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 371 Route Optimization Solution Space Analysis", 372 draft-ietf-nemo-ro-space-analysis-03 (work in progress), 2006. 374 [4] NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 375 Route Optimization Problem Statement", 376 draft-ietf-nemo-ro-problem-statement-03 (work in progress), 377 2006. 379 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 380 Levels", RFC 2119, 1997. 382 Authors' Addresses 384 Emmanuel Baccelli 385 INRIA 387 Phone: +33 1 69 33 55 11 388 Email: Emmanuel.Baccelli@inria.fr 390 Thomas Heide Clausen 391 LIX, Ecole Polytechnique, France 393 Phone: +33 6 6058 9349 394 Email: T.Clausen@computer.org 395 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 397 Ryuji Wakikawa 398 Keio University, WIDE 400 Phone: +81-466-49-1394 401 Email: Ryuji@sfc.wide.ad.jp 403 Full Copyright Statement 405 Copyright (C) The IETF Trust (2007). 407 This document is subject to the rights, licenses and restrictions 408 contained in BCP 78, and except as set forth therein, the authors 409 retain all their rights. 411 This document and the information contained herein are provided on an 412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 414 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 415 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 416 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 419 Intellectual Property 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed to 423 pertain to the implementation or use of the technology described in 424 this document or the extent to which any license under such rights 425 might or might not be available; nor does it represent that it has 426 made any independent effort to identify any such rights. Information 427 on the procedures with respect to rights in RFC documents can be 428 found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use of 433 such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository at 435 http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at 441 ietf-ipr@ietf.org. 443 Acknowledgment 445 Funding for the RFC Editor function is provided by the IETF 446 Administrative Support Activity (IASA).