(MA)NEMO E. Baccelli Internet-Draft INRIA Expires: September 6, 2007 T. Clausen LIX, Ecole Polytechnique, France R. Wakikawa Keio University, WIDE March 5, 2007 NEMO Route Optimisation Problem Statement draft-clausen-nemo-ro-problem-statement-01 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Baccelli, et al. Expires September 6, 2007 [Page 1] Internet-Draft NEMO RO Problem Statement March 2007 Abstract The NEMO basic support specification is not limited to a single level of mobile networks attaching to the stationary Internet. Rather, arbitrary levels of nested mobile networks are supported, employing for each level of nesting the same attachment, encapsulation and tunnelling mechanisms. With arbitrarily deep nested mobile networks, paths taken by data traffic can be extremely sub-optimal both inside the nested topology through successive mobile routers, and outside the nested topology, through successive Home Agents over the Internet. Moreover, the overhead incurred through tunnelling and encapsulation of data traffic can become prohibitively large. This document analyses the scenarios in which these problems are particularly acute. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 3.1. Internet - Nested NEMO Communication . . . . . . . . . . . 5 3.2. Intra Nested NEMO Communication . . . . . . . . . . . . . 6 3.3. RFC3963 Loops . . . . . . . . . . . . . . . . . . . . . . 7 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Lack of Nested Topology State Information . . . . . . . . 8 4.2. Goals of Route Optimization for Nested NEMO networks . . . 9 4.3. Solution Guidelines . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Baccelli, et al. Expires September 6, 2007 [Page 2] Internet-Draft NEMO RO Problem Statement March 2007 1. Introduction The NEMO basic support specification [1] extends the notion of edge- mobility on the Internet to include that of network mobility. This implies that a set of nodes, along with their mobile router, change their point of attachment and that traffic to these nodes is tunnelled to be delivered through their new point of attachment. This mechanism is transparent to applications in that existing traffic to a node is being encapsulated and tunnelled, regardless of where the network containing the destination node is attached. The NEMO basic support specification is furthermore not limited to a single level of mobile networks attaching to the stationary Internet. Rather, arbitrary levels of nested mobile networks are supported, employing for each level of nesting the same transparent mechanisms relying on attachment, encapsulation and tunnelling. However, with arbitrarily deep nested mobile networks, paths taken by data traffic can become extremely sub-optimal both (i) inside the nested topology through successive mobile routers, and (ii) outside the nested topology, through successive Home Agents over the Internet. Moreover, the overhead incurred through tunnelling and encapsulation of data traffic can become prohibitively large. This document describes cases where problems due to sub-optimal data traffic paths and encapsulation overhead are acute, providing a discussion of which cases and to what extent route optimisation is desirable with NEMO. Baccelli, et al. Expires September 6, 2007 [Page 3] Internet-Draft NEMO RO Problem Statement March 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [5]. It is moreover assumed that readers are familiar with NEMO terminology as described and employed in [1] and [2]. Baccelli, et al. Expires September 6, 2007 [Page 4] Internet-Draft NEMO RO Problem Statement March 2007 3. Deployment Scenarios Two categories of scenarios exist, where route optimisation is desirable. Those are, respectively: (i) when a host from the Internet wishes to communicate with a host in a nested NEMO, and (ii) when a host in a nested NEMO wishes to communicate with a host in another nested NEMO which is part of the same nested NEMO topology. Some of these issues are also elaborated in [4]. 3.1. Internet - Nested NEMO Communication In this category of scenario, a number of NEMO networks are nested to one another, and a host in the Internet wishes to communicate with a host in one of the NEMO networks. For the purpose of describing this scenario, the example depicted in Fig. 1 below is considered. ---------- ---------- ---------- ---------- | | | | | | | | | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Host 1 | | | | | | | | | | ---------- ---------- ---------- | ---------- | ---------- ---------- | | | | | |----| HA 2 | | HA 1 |---------| | | | | | ---------- ---------- | ---------- | | | HA 3 | | | ---------- Figure 1: Nested NEMO networks -- Internet-to-NEMO communication We assume that each box labelled "NEMO x" refers to a Mobile Router (MR), running the NEMO protocol, as well as the hosts attached to that mobile router. We further assume, that each line indicates a direct connection between routers -- i.e. the mobile router in "NEMO 1" has a direct connection to the mobile router in "NEMO 2". Each box labelled "HA x" refers to the Home Agent for the NEMO network x -- i.e. that HA 1 is the Home Agent for the mobile network NEMO 1. The host labelled "Host 1" wishes to communicate with a host in NEMO 1. Data traffic will first be routed through HA 1 the Home Agent of Baccelli, et al. Expires September 6, 2007 [Page 5] Internet-Draft NEMO RO Problem Statement March 2007 NEMO 1. At HA 1, a binding would exist, identifying NEMO 1 as being attached to the network of NEMO 2. Thus, the traffic would be encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA 2, a binding would exist, identifying that, indeed, NEMO 2 is attached to the network of NEMO 3. Another encapsulation would ensure, and the traffic sent to HA 3. At HA 3, a binding would identify the point of attachment of NEMO 3 to the internet, and the data traffic would be encapsulated one final time prior to being delivered to NEMO 3 -- where decapsulation and handoff to NEMO 2, then NEMO 1 occurs. This simple example scenario therefore involves communication with (i) triple encapsulation of the data, and (ii) its transmission via 3 arbitrary locations across the Internet. More generally, if instead of a depth 3 the nested NEMO structure had a depth N, the communication would involve worst case N levels of encapsulation of the data, and its transmission via N arbitrary locations across the Internet. This is thus very sub-optimal communication across the Internet ([3]. 3.2. Intra Nested NEMO Communication In this category of scenario, a number of NEMO networks are nested to one another, and hosts in the different nested NEMOs are communicating with one another. For the purpose of describing this scenario, the example depicted in Fig. 2 below is considered. ---------- ---------- ---------- | | | | | | | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet | | | | | | | ---------- ---------- ---------- | | ---------- ---------- | | | | | |----| HA 2 | | HA 1 |---------| | | | | | ---------- ---------- | ---------- | | | HA 3 | | | ---------- Fig. 2: Nested NEMO networks -- NEMO-to-NEMO communication Baccelli, et al. Expires September 6, 2007 [Page 6] Internet-Draft NEMO RO Problem Statement March 2007 If a host from NEMO 3 wishes to communicate with a host from NEMO 1, then the data traffic would first be sent out the nested NEMO network, over the Internet to HA 1. The data traffic would then be encapsulated and tunnelled to HA 2, which will in turn add another layer of encapsulation and tunnel the traffic to HA3 which will do the same before the data returns to our nested NEMO network. Successive decapsulation and transmission via NEMO 3, NEMO 2 and NEMO 1 will then happen before data is delivered to the destination. Again, this simple example scenario involves communication with (i) triple encapsulation of the data, and (ii) its transmission via 3 arbitrary locations across the Internet. And again, more generally, if instead of a depth 3 the nested NEMO structure had a depth N, the communication would involve N levels of encapsulation of the data, and its transmission via N arbitrary locations across the Internet. This is therefore very sub-optimal communication across the Internet, as communication inside the nested NEMO network should be sufficient. 3.3. RFC3963 Loops [1] allows for NEMO mobile routers to nest to one another, however does not stipulate how to form the links of the nest. In particular, [1] allows for, as is illustrated in the following Fig. 3, NEMO 1 to select NEMO 2 as its point of attachment, with NEMO 2 selecting NEMO 3 as point of attachment and NEMO 3 selecting NEMO 1 - thereby forming a loop. Absent other mechanisms, this loop will persist, potentially disconnecting both NEMO 1, NEMO 2 and NEMO 3 from the wider network, from the Internet, and - if traffic between NEMO nodes is tunnelled through HAs, also from each other. [1] does not provide functionality allowing to detect this loop: a MR cannot know whether it connects to a mobile network or a general IPv6 network. ---------- ---------- | |--| | | NEMO 1 | | NEMO 2 | | | | | ---------- ---------- | | ---------- | | | NEMO 3 | | | ---------- Fig. 3: Loop in Nested NEMO networks Baccelli, et al. Expires September 6, 2007 [Page 7] Internet-Draft NEMO RO Problem Statement March 2007 4. Problem Statement Encapsulation and tunnelling specified by NEMO basic support [1] are governed by the following principles: 1. A router which forwards data traffic does not know where the destination is located and therefore assumes that it is at its Home Network; 2. A Home Agent does not know if a NEMO is directly or indirectly bound to the Internet, which in particular means that: 3. No router knows the topology of the nested NEMO network(s). While these principles are functional, they have the consequences that are described in the following. 4.1. Lack of Nested Topology State Information The lack of state information about the nested NEMO topology and its point(s) of attachment to the Internet causes routing to involve logical hops (from source to Home Agent of destination, or from Home Agent to Home Agent), each of those adding a layer of encapsulation and a detour across the Internet, until a point of attachment between the Internet and the nested NEMO network is reached. This lack causes extreme data paths sub-optimality and extreme data encapsulation overhead in cases where the nested topology is of depth greater than 2, as depicted in Section 3.2 and Section 3.1. The following items summarise the problems incurring from lack of nested topology state information: Internet Route Suboptimality - where traffic from the internet transverses more than one HA, incurring both route sub-optimality and nested encapsulation; Intra-NEMO Route Suboptimality - where traffic between hosts in the nested NEMO network is forced through the Internet gateway and subsequently through one or more HAs, incurring both route sub- optimality and nested encapsulation; Intra-NEMO loops - where, due to unfortunate selection of which MR is attaching to which MR, loops occur. Baccelli, et al. Expires September 6, 2007 [Page 8] Internet-Draft NEMO RO Problem Statement March 2007 4.2. Goals of Route Optimization for Nested NEMO networks The goal of route optimisation for nested NEMO is to alleviate the problems regarding (i) Internet route sub-optimality, (ii) Intra-NEMO route sub-optimality, and (iii) Intra-NEMO loops. Additional information about the nested topology must be available to Mobile Routers and/or Home agents, which: o may serve to allow NEMO MRs to detect and alleviate loops or to prevent such from occurring in the first place. Specifically, this allows a NEMO MR to ensure that a loop-free path to the Internet Gateway exists; o may serve to establish and maintain an intra-NEMO routing mesh, allowing to bypass the Internet Gateway and HAs for intra-NEMO communications; o may serve to bypass dog-leg routing in communications from sources on the Internet to a mobile node in the nested NEMO network. 4.3. Solution Guidelines A solution to the NEMO Route Optimisation problem will: o provide a mechanism whereby each MR has sufficient topological awareness such that it may select the router(s) to which it attaches such that routing loops are avoided; o provide a mechanism whereby each MR has sufficient topological awareness such that it may select a suitable path towards the Internet Gateway for communication towards the Internet and - in particular - towards its HA; o provide a mechanism whereby each Internet Gateway has sufficient topological awareness such that it may select a suitable path towards each MR in the nested NEMO network for which it is providing Internet access; o provide a mechanism whereby each MR has sufficient topological awareness such that it may select a suitable path towards another MR within the NEMO without transversing the Internet Gateway; o provide a mechanism whereby each MR has sufficient topological awareness such that it may provide suitable binding updates with its HA. A particular case of this is if the MR can provide binding updates such that multiple encapsulations and sub-optimal routes on the Internet can be avoided when a MR is connected to the Internet Gateway through multiple intermediate MRs in the NEMO Baccelli, et al. Expires September 6, 2007 [Page 9] Internet-Draft NEMO RO Problem Statement March 2007 nest. Mechanisms developed for maintaining and using such information must address the distributed, multi-hop nature of nested NEMO networks, and be able to follow topology and connectivity changes by updating state information in Mobile Routers and/or Home Agents accordingly. Solutions must achieve their task while being conservative in their network resource consumption and while avoiding prohibitively long delays. Baccelli, et al. Expires September 6, 2007 [Page 10] Internet-Draft NEMO RO Problem Statement March 2007 5. Security Considerations This document does currently not specify security considerations. Baccelli, et al. Expires September 6, 2007 [Page 11] Internet-Draft NEMO RO Problem Statement March 2007 6. IANA Considerations This document does currently not specify IANA considerations. Baccelli, et al. Expires September 6, 2007 [Page 12] Internet-Draft NEMO RO Problem Statement March 2007 7. References [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 2005. [2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), 2006. [3] NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in progress), 2006. [4] NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03 (work in progress), 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 1997. Baccelli, et al. Expires September 6, 2007 [Page 13] Internet-Draft NEMO RO Problem Statement March 2007 Authors' Addresses Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Thomas Heide Clausen LIX, Ecole Polytechnique, France Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ Ryuji Wakikawa Keio University, WIDE Phone: +81-466-49-1394 Email: Ryuji@sfc.wide.ad.jp Baccelli, et al. Expires September 6, 2007 [Page 14] Internet-Draft NEMO RO Problem Statement March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baccelli, et al. Expires September 6, 2007 [Page 15]