(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]