No Working Group R. Wakikawa
Internet-Draft Keio University
Expires: January 2, 2008 T. Clausen
LIX, Ecole Polytechnique
B. McCarthy
Lancaster University
A. Petrescu
Motorola Labs
July 1, 2007
MANEMO Topology and Addressing Architecture
draft-wakikawa-manemoarch-00.txt
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 January 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wakikawa, et al. Expires January 2, 2008 [Page 1]
Internet-Draft MANEMO Architecture July 2007
Abstract
This document outlines the MANEMO architecture including possible
topology configuration and addressing assignment. The issues of
MANEMO (previously known as nested NEMO) are already summarized in
several documents. However, there are several ways how to comprehend
what is MANEMO. The MANEMO problems are related to several existing
working groups. This document provides the MANEMO architecture model
and differences of existing solutions so that IETF can classify the
problems and start working on the solutions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is Network Mobility (NEMO) Basic Support . . . . . . . . 4
3. MANEMO Topologies . . . . . . . . . . . . . . . . . . . . . . 7
3.1. MANEMO Basic Topologies . . . . . . . . . . . . . . . . . 7
3.2. MANEMO Advanced Topologies . . . . . . . . . . . . . . . . 9
4. Addressing Architecture of MANEMO . . . . . . . . . . . . . . 11
4.1. NEMO Addressing Approach (MANEMO Architecture) . . . . . . 11
4.2. AUTOCONF Approach (MANET Architecture) . . . . . . . . . . 14
4.3. Comparison of Two Approaches . . . . . . . . . . . . . . . 18
5. Solution Guideline . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative reference . . . . . . . . . . . . . . . . . . . 23
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Wakikawa, et al. Expires January 2, 2008 [Page 2]
Internet-Draft MANEMO Architecture July 2007
1. Introduction
When mobile routers and mobile nodes converge at the edge of the
Internet using wireless interfaces, they can form a wireless network
cloud and are able to provide Internet connectivity to one another.
This type of network is called a MANEMO Fringe Stub (MFS). Several
issues exist in the MFS such as network loop, sub-optimal route,
redundant tunnels, multiple exit routers selection, and HA dependency
of the NEMO Basic Support. While fixed routers provide connectivity
constantly, mobile routers can experience intermittent connectivity
to the Internet due to their movement. When the NEMO Basic Support
is used in this context, network loops naturally occur. NEMO forces
the packets to always travel through the home agent, which in turn
causes an sub-optimal route that can become a considerable problem
when mobile routers form a nested topology. Different types of
routers are able to provide Internet connectivity in the MFS,
including both mobile routers and fixed access routers. Any node
requiring Internet connectivity has to select the best exit router
toward the Internet, therefore it is necessary for mobile nodes to
maintain a local topology in the MFS and to utilize any available
connectivity with a degree of Intelligence. Unfortunately, MANEMO is
still not yet clearly defined and understood by IETF community, this
draft attempts to address that problem by identifying the topologies
that arise with MANEMO and analyzing their requirements.
It is still uncertain whether MANEMO configurations can be suitably
supported by MANET/AUTOCONF approaches. In order to determine
whether the MANEMO problem can be addressed by existing solutions, we
must analyze the expected topology formations, wireless technologies,
addressing, etc. We believe there are also missing pieces for MANEMO
in IETF. This draft is aimed at helping identify what are those
missing pieces. This document describes first the whole idea of the
NEMO Basic Support. Then, possible MANEMO topologies are given.
Finally we consider a typical MANEMO addressing scheme. We feel that
analyzing the problem area in this detail can help the reader's
understanding of what MANEMO is and its relationship with existing
activity.
Wakikawa, et al. Expires January 2, 2008 [Page 3]
Internet-Draft MANEMO Architecture July 2007
2. What is Network Mobility (NEMO) Basic Support
This section provides brief explanation of Network Mobility Basic
Support protocol. If readers are familiar with RFC3753 [1], RFC3775
[2], RFC3963 [3], draft-ietf-nemo-ro-problem-statement [6], please
skip this section.
A mobile network is defined in RFC3753 [1], "An entire network,
moving as a unit, which dynamically changes its point of attachment
to the Internet and thus its reachability in the topology. The
mobile network is composed of one or more IP-subnets and is connected
to the global Internet via one or more Mobile Routers (MR). The
internal configuration of the mobile network is assumed to be
relatively stable with respect to the MR.". A mobile network is seen
as just IPv6 subnet by any nodes except for Mobile Routers.
According to RFC3963, Figure 1 is the common interpretation of a
mobile router. Each Mobile Router has an egress interface(s) to
reach the home agent through the Internet and also an ingress
interface(s) attaching to the Mobile Network. A mobile router
obtains its care-of address at the egress interface and establishes a
bi-directional tunnel to the home agent. It routes all the packets
intercepted at the ingress interface to the bi-directional tunnel.
The packet's source address must belong to the mobile network prefix.
Only the packets sent to and from a mobile network are routed to the
tunnel by the mobile router.
Access Network
|
+-+-+
|AR |
+-+-+
| <-egress interface(s)
+-+-+
|MR1|
+-+-+
| <-ingress interface(s)
-+-+-+-+-+- Mobile Network
| | | | |
H H H H H Mobile Network Nodes (MNNs)
Figure 1: Mobile Router Configuration
Some known remarks from this NEMO Basic Support are:
o Unless a node (host or router) is connected to a mobile network,
NEMO guarantees the session continuity to the node.
Wakikawa, et al. Expires January 2, 2008 [Page 4]
Internet-Draft MANEMO Architecture July 2007
o Any nodes attached to the mobile network are unaware of the mobile
router's changing attachment point. The mobile network can be
seen as just an IPv6 network.
o An access router at the visiting network is not aware of a mobile
network existence behind a mobile router.
According to draft-ietf-nemo-terminology [4], several different
entities can be attached to the mobile network such as Fixed Router
in a mobile network and Mobile Network Node including Local Fixed
Node, Visiting Mobile Node and Local Mobile Node. In Figure 2, an
IPv6 router called Fixed Router is deployed in a mobile network. The
fixed router has a dedicated mobile network prefix. The dedicated
prefix can be delegated from the mobile network prefix of its mobile
router like Figure 2-a. The mobile router sends a binding update for
the aggregated mobile network prefix (2001:1::/48). Alternatively,
it can be configured with non-aggregated prefix as shown in
Figure 2-b. The mobile router sends a binding update containing two
mobile network prefix options for both mobile network prefixes (2001:
a::/64 and 2001:b::/64).
The Fixed Router sends ICMP route advertisements, in order to reach
other nodes in the moving network it needs to have routes installed,
and this can be achieved by static routes or by running a routing
protocol. The Mobile Router has to have a route towards the mobile
network prefix owned by the Fixed Router through Fixed Router's IP
address. That route can be manually installed, manually configured
in a routing protocol configuration file, or dynamically delegated
with DHCP Prefix Delegation.
Access Network Access Network
| <--- egress interface(s) ---> |
+-+-+ +-+-+
|MR | Mobile Router |MR |
+-+-+ +-+-+
| <-- ingress interface(s) --> |
------+------+----- ------+------+-----
Mobile Network/48 | Mobile Network/64 |
2001:1::/48 +-+-+ 2001:a::/64 +-+-+
|FR | |FR |
+-+-+ <-- Fixed Router --> +-+-+
| |
------+------ ------+------
Mobile Network-FR/64 Mobile Network-FR/64
2001:1:1::/64 2001:b::/64
a) b)
Wakikawa, et al. Expires January 2, 2008 [Page 5]
Internet-Draft MANEMO Architecture July 2007
Figure 2: Mobile Router Configuration with Fixed Router
When a visiting mobile node is attached to a mobile network, we call
this network formation as nested NEMO. Figure 3 shows the two cases
where either a mobile node or a mobile router is attached to a mobile
network. Specially, if a visiting mobile node is a mobile router,
the number of nested level goes longer (Figure 3-b)). Several issues
are raised when Nested NEMO is occurred. The nested NEMO issues are
already introduced in several documents [6], [7]
Access Network Access Network
| |
+-+-+ +-+-+
|AR | |AR |
+-+-+ +-+-+
| |
+-+-+ +-+-+
|MR | |MR1|
+-+-+ +-+-+
| |
-+---+---+- -----+---+-
| | |
+-+-+ +-+-+ +-+-+
|MN1| |MN2| |MR2|
+---+ +---+ +-+-+
:
a) :
+-+-+
|MRn|
+-+-+
|
b)
Figure 3: Nested NEMO Configuration
Wakikawa, et al. Expires January 2, 2008 [Page 6]
Internet-Draft MANEMO Architecture July 2007
3. MANEMO Topologies
The NEMO Basic Support protocol introduces two different interfaces
on a mobile router known as the egress interface and the ingress
interface. In MANEMO, several topologies can be expected by
attachment combination of these two interfaces.
3.1. MANEMO Basic Topologies
When considering MANEMO, following topology can be logically
possible.
1. Egress and Ingress (E-I) attachment
2. Egress and Egress (E-E) attachment
3. *Ingress and Ingress (I-I) attachment
4. **Egress/Ingress and Egress/Ingress (EI-EI) attachment
[*MANEMO does not consider this case. The reasons are given later in
this section.]
[**EI-EI is another configuration of E-E attachment. While the NEMO
Basic Support does not assume using single interface for both egress
and ingress, MANEMO consider this special configuration, too. See
Section 3.2 for details.]
The E-I attachment is the most common configuration of the NEMO Basic
Support. A mobile router connects to the other mobile routers'
mobile network by its egress interface. Figure 4 shows the example
topology. (e) and (i) in all the figures in this section indicate
egress and ingress interfaces.
Wakikawa, et al. Expires January 2, 2008 [Page 7]
Internet-Draft MANEMO Architecture July 2007
|e |e
+-----+ +-----+
| MR | | MR |
+-----+ +-----+
|i |i
| +---------+
|e | |e
+-----+ +-----+ +-----+
| MR | | MR | | MR |
+-----+ +-----+ +-----+
|i |i
| |
|e |e
+-----+ +-----+
| MR | | MR |
+-----+ +-----+
|i |i
Figure 4: Egress-Ingress (E-I) attachments.
Figure 5 shows the two (E-E and I-I) scenarios. The E-E attachment
is the case when a mobile router uses ad-hoc type of interfaces such
as 802.11b ad-hoc mode or 802.11s as its egress interface. Each
mobile router connects with egress interface. In MANEMO, this
scenario is also considered for inter vehicle networks, etc. (see
ref). On the other hand, although the ingress and ingress attachment
is logically possible, it is slightly unrealistic. First of all,
when ingress interfaces of different mobile routers are connected ,
two different mobile networks are merged in the single mobile
network. A mobile network node will obtain multiple IP addresses
from different mobile routers. For instance, in Figure 5, a mobile
network node of MR1 obtains an address of mobile network prefixes of
all the mobile routers (MR1, MR2 and MR3). Whenever a mobile router
leaves, the addresses of the entire mobile network node generated
from the mobile network prefix of leaved mobile router will go
unreachable. This configuration may break the fundamental features
of the NEMO Basic Support protocol (lack of movement transparency).
Thus, we do not consider I-I attachment scenario in MANEMO.
Wakikawa, et al. Expires January 2, 2008 [Page 8]
Internet-Draft MANEMO Architecture July 2007
e+-----+i e+-----+i
+--| MR |-- --| MR1 |--+
| +-----+ +-----+ |
| |
| e+-----+i e+-----+i |
+--| MR |-- --| MR2 |--+
| +-----+ +-----+ |
| |
| e+-----+i e+-----+i |
+--| MR |-- --| MR3 |--+
+-----+ +-----+
Figure 5: E-E and I-I Attachment
3.2. MANEMO Advanced Topologies
In MANEMO, the different scenarios from the basic topologies are also
considered. First, a mobile router only equips with single wireless
interfaces and utilizes it conceptually as both egress and ingress
interface. In the NEMO Basic Support, a mobile router is assumed to
have physically two different interfaces. However, in this context,
the ingress and egress interfaces are roles over the same physical
interface. A mobile router exposes its mobile network prefix to the
interface and also obtains a care-of address at the same interface
(named EI-EI attachment). Figure 6 shows the example topology.
e/i+-----+
+---| MR |
| +-----+
|
|e/i+-----+
+---| MR |
| +-----+
|
|e/i+-----+
+---| MR |
+-----+
Figure 6: EI-EI attachment
Another scenario is that a mobile router has a fixed router(s) in its
mobile network so that another visiting mobile router (a mobile
network node) connects to the mobile network through the fixed
router. Figure 7 gives two examples. There are several links where
a mobile network node can attach. In Figure 7-b), a mobile router
Wakikawa, et al. Expires January 2, 2008 [Page 9]
Internet-Draft MANEMO Architecture July 2007
attaches to the link between the mobile router (MR) and the fixed
router (FR). This topology is possible only if a mobile router
allows mobile network nodes to attach to this link. It totally
depends on the admission control of each mobile network. When
deploying the NEMO Basic Support protocol, it is necessary to
consider this fixed router availability in a mobile network.
......|......
: |e : |e
: +-----+ : +-----+
: | MR | : | MR |
: +-----+ : +-----+
: |i : |i
: | : +---------+
: | : | |
: +-----+ : +-----+ +-----+
: | FR | : | MR | | FR |
: +-----+ : +-----+ +-----+
: |i : |
:.....|...... |
|e |e
+-----+ +-----+
| MR | | MR |
+-----+ +-----+
|i |i
a) b)
Figure 7: Use of Fixed Routers
Wakikawa, et al. Expires January 2, 2008 [Page 10]
Internet-Draft MANEMO Architecture July 2007
4. Addressing Architecture of MANEMO
After the formation of the Nested NEMO, the argument is how to assign
an address to each mobile node and mobile router. There are two
different approaches today in IETF, 1) NEMO addressing approach and
2) AUTOCONF addressing approach. This section briefly explains the
two approaches and discusses their pros and cons.
4.1. NEMO Addressing Approach (MANEMO Architecture)
According to the NEMO Basic Support, an attached node to a mobile
network will get an address from the mobile network. Figure 8 gives
the simplest case. MR1 obtains an IP address (ANP::MR1 as CoA) from
the access router that advertised prefix is ANP::/64. The MR2
attached to a mobile network of MR1 generates its CoA from the
MNP1::/64. This is what the NEMO basic support is assumed in the
protocol design. (e) and (i) in all the figures in this section
indicate egress and ingress interfaces, too.
Access Network
|
+-+-+
|AR |
+-+-+
|
------+------ ANP::/64
e| ANP::MR1
+-+-+
|MR1|
+-+-+
i|
------+------ MNP1::/64
e| MNP1::MR2
+-+-+
|MR2|
+-+-+
i|
-----+------ MNP2::/64
Figure 8: NEMO Address Assignment for E-I attachment
Alternatively, Figure 9 gives another address assignment when a
mobile network is formed with a mobile router and a fixed router(s).
As discussed with Figure 2, two possible prefix assignment to the
fixed router is considered, (1) the mobile network prefix can be
divided into sub-prefixes that can be aggregated and one of the sub-
Wakikawa, et al. Expires January 2, 2008 [Page 11]
Internet-Draft MANEMO Architecture July 2007
prefixes can be assigned to a Fixed Router, (2) the mobile network
prefix and the Fixed Router's prefix can be totally different and not
necessarily aggregated. In both cases it's the administrator who
decides this addressing architecture, it is not the mobile router who
divides and assigns. In this Figure, the mobile router (MR1) owns
the mobile network prefix (MNP1::/48) and assigns sub-prefixes of the
mobile network to a fixed router (FR1). A mobile network node is
attached to a link of FR1 (MNP1:1::/64) and maybe not to a link of
MR1 (MNP1::/48). If a node is attached to the link of MR1, it turns
to the same configuration of Figure 8. In this example, MR2 is
attached to a link of FR1 and acquires the MNP1:1::MR2 address as its
CoA.
Access Network
|
+-+-+
|AR |
+-+-+
|
------+------ ANP::/64
e| ANP::MR1
+-+-+
|MR1|
+-+-+
i|
------+------ MNP1::/48
|
+-+-+
|FR1|
+-+-+
i'|
-----+------ MNP1:1::/64
e| MNP1:1::MR2
+-+-+
|MR2|
+-+-+
i|
-----+------ MNP2::/64
Figure 9: NEMO Address Assignment when Fixed Router is employed
According to Section 3, the other possible topology of the nested
NEMO are E-E and EI-EI attachments described in Figure 10. The
egress interface of each MR is connected in ad-hoc fashion by using
802.11b in ad-hoc mode. This is not originally assumed in the NEMO
Basic Support Protocol. Figure 10 is just an example which was
Wakikawa, et al. Expires January 2, 2008 [Page 12]
Internet-Draft MANEMO Architecture July 2007
discussed in the MANEMO mailing list. In this case, MR reveals its
mobile network prefix to its egress interface so that the attached MR
(MR2 for MR1) can obtain an IPv6 address (MNP1::MR2) from the upper
Mobile Router. The definition of egress interface is extended to
support some role of ingress interface. As shown in , two possible
scenarios can be given whether the mobile router has its physically
available ingress interface or not.
In the Scenario-1 (E-E attachment), each mobile router owns its
physically available ingress interface. Therefore, the mobile
network prefix is advertised to both ingress interface and egress
interface by using ICMP Router Advertisement, while the mobile router
acquires its care-of address from the upper router (ex. AR for MR1,
MR1 for MR2). Note that the NEMO Basic Support does not allow for a
mobile router to send ICMP router advertisements for its own mobile
network prefix from the egress interface. The mobile router must
support bridge functionality between the ingress interface and egress
interface. MNN1 (MNP1::MNN) and MR2's egress interface (MNP1::MR2)
must be located at the same link, otherwise the multilink subnet
issue [8] is occurred. However, this bridge functionality is not
currently supported by the NEMO Basic Support protocol.
On the other hand, the scenario-2 is simpler than the the scenario-1.
A mobile router does not necessarily support the bridge functionality
because it does not have an ingress interface. The mobile router
uses a single interface as an egress and ingress interfaces. A
mobile router must check the source address of all the packets to
decide whether the packets should be routed to the bi-directional
tunnel or not. In the packet's source address is the CoA of a mobile
router, it MUST NOT tunnel the packet. But the source address of a
packet is an address of its mobile network prefix, the packet MUST be
tunneled to the home agent. Again, this configuration is also not
considered by the NEMO Basic Support protocol and needs some
modifications to the NEMO Basic Support protocol.
Wakikawa, et al. Expires January 2, 2008 [Page 13]
Internet-Draft MANEMO Architecture July 2007
Scenario-1(E-E attachment) Scenario-2 (EI-EI attachment)
Access Network Access Network
| |
+-+-+ +-+-+
|AR | ANP::/64 |AR | ANP::/64
+-+-+ +-+-+
| |
------+------ ANP::/64 ------+------ ANP::/64
| |
ANP::MR1 e+---- ANP::MR1 ei +-----
+-+-+ \ +-+-+ \
|MR1| \ |MR1| \
+-+-+ \ +---+ \
i| \ __|
-+----+---- __| /ei|MNP1::MR2
| / e|MNP1::MR2 ______/ +-+-+
MNN1 ______/ +-+-+ / |MR2|
MNP1::MNN / |MR2| / +---+
/ +-+-+ |
| i| ei|MNP2::MR3
| ----+-+-+- +-+-+
| | | |MR3|
e|MNP2::MR3 MNN MNN +---+
+-+-+ (MNP2::MNNi)
|MR3|
+-+-+
i|
-+-+-+-+-+--
| | | | |
MNNs (MNP3::MNNi)
Figure 10: NEMO Address Assignment for E-E and EI-EI attachments
4.2. AUTOCONF Approach (MANET Architecture)
The Ad-hoc Network Autoconfiguration (AUTOCONF) working group
summarizes the MANET Architecture in [9]. This section gives brief
explanation how to apply the MANET architecture to the nested NEMO
topology. Figure 11 shows the case where each mobile router is
connected by its egress interface in ad-hoc fashion. This scenario
is very similar to what MANET is expected. Each mobile router
obtains an IPv6 address on its egress interface from the access
router called internet gateway in the MANET community. Thus, each
mobile router, at the end, obtains an address derived from the access
router's prefix (ANP::/64). Note that the egress interface can be
treated as a manet interface in this case. Thus, the address
Wakikawa, et al. Expires January 2, 2008 [Page 14]
Internet-Draft MANEMO Architecture July 2007
assigned to the manet interface must be unique as stated in [9]. [9]
suggests link-local addresses, IPv6 address/128, and unique prefix/n
(n < 128) per a manet interface. Although the link-local address
(LL-MRn-e/128) can be used for the MANET purpose at the manet
interface, each mobile router MUST obtain at least one global address
for sending a binding update. We will not discuss the use of link
local address in further section. Either ANP::MRn/128 or ANP:n::
MRn/64 can be possible for the address on the egress interface (i.e.
manet interface) as shown in Figure 11. When each mobile router
obtains a unique prefix from the access router, the access router
should manage the several prefixes in order to assign individual
prefix to every mobile router.
The mobile router uses the address (ANP::MRn/128 or ANP:n::MRn/64 in
Figure 11) as a care-of address and registers its binding to the home
agent. Note that in AUTCONF approach, E-E and EI-EI attachments can
be treated as a same, because a mobile router does not advertise its
mobile network prefix to the egress interface. Each mobile router
only obtains an IPv6 address from access router and not from
neighbors (other mobile routers).
Access Network
|
+-+-+
|AR | ANP::/64 or /48
+-+-+
|
+-----
ANP::MR1/128 or --> |e |
ANP:1::MR1/64 or +-+-+ \
LL-MR1-e/128 |MR1| |
+-+-+ \
i| \
-----+---- __|
/ e| <-- ANP::MR2/128 or
_____/ +-+-+ ANP:2::MR2/64 or
/ |MR2| LL-MR2-e/128
/ +-+-+
| i|
| ----+-----
e|<-- ANP::MR3/128 or
+-+-+ ANP:3::MR3/64 or
|MR3| LL-MR3-e/128
+-+-+
i|
-----+------
Wakikawa, et al. Expires January 2, 2008 [Page 15]
Internet-Draft MANEMO Architecture July 2007
Figure 11: AUTOCONF addressing assignment for E-E attachment
Figure 12 shows the AUTOCONF model when mobile routers are formed in
the E-I attachment. According to the MANET architecture [9], MR2 in
Figure 12 can obtain an address from the access router (ANP::MR2/128
or ANP:2::MR2/64), even in this configuration. Alternatively, MR2
can run the address autoconfiguration [5] at the attached link
(mobile network of MR1) and obtains the MNP1::MR2/64 on its egress
interface as a regular IPv6 address autoconfiguration. Thus, a
mobile router may obtain two different addresses such as one from the
access router and one from its upper mobile router. For example, the
mobile router (MR1) directly attached to the access router only
obtains an IPv6 address from the access router, because there are no
other upper mobile routers. On the other hand, MR2 gets two
addresses from upper mobile router (MR1) and the access router. The
mobile router should always select the address assigned from the
access router as a care-of address and registers it to the home
agent. By doing so, any of tunnel overhead issues raised in the
MANEMO problem statement are merely occurred. The loop issue can
also be avoided by running a manet routing protocol on its manet
interface. However, there is one big issue that the upper mobile
router's movement causes the effect to the attached nodes. For
example, if MR1 moves change its point of attachment, MR2 also
detects movement. This is not what the NEMO Basic Support protocol
is aimed for. The movement of a mobile router must be hidden from
any nodes in its mobile network. We discuss this in Section 4.3.
Access Network
|
+-+-+
|AR | ANP::/48 or /64
+-+-+
|
e| <-- ANP::MR1/128 or ANP:1::MR1/64
+-+-+
|MR1|
+-+-+
i| MNP1::/64
------+------
| <- MNP1::MR2/64 (NOT AUTOCONF address)
e| <-- ANP::MR2/128 or ANP:2::MR2/64
+-+-+
|MR2|
+-+-+
i|
-----+-----
Wakikawa, et al. Expires January 2, 2008 [Page 16]
Internet-Draft MANEMO Architecture July 2007
Figure 12: AUTOCONF Addressing Assignment for the basic Nested NEMO
Another problem of this configuration is explained with Figure 13.
If a fixed router (FR1) is located in the mobile network, the MANET
architecture treats this case as two separate manets inter-connecting
by a fixed router. Thus, conceptually, MR2 cannot obtain an address
from the access router because the fixed router separates MR1 and
MR2. Even if we extend the concept of the MANET architecture [9] in
order for the access router to deliver the global unique prefix to
the MR2, another problem can be caused. FR1 must have a route of the
MR2's prefix assigned by the access router. However, FR1 is just an
IPv6 router (i.e. supporting neither the NEMO Basic Support nor
AUTOCONF), there is no way that FR1 has a route of the access
router's prefix. FR1 cannot route the packet which destination is
MR2's address (ANP::MR2/128 or ANP:2::MR2/64) unless the route of
MR2's assigned address/prefix is installed in FR1.
Access Network
|
+-+-+
|AR | ANP::/48 or /64
+-+-+
|
e|<-- ANP::MR1/128 or ANP:1::MR1/64
+-+-+
|MR1|
+-+-+
i| MNP1::/48
------+------
|
+-+-+ <-- it should have routes of either one of
|FR1| [ANP:1::/64 & ANP:2::/64] or
+-+-+ [ANP::MR1/128 & ANP::MR2/128]
i'|MNP1:1::/64
-----+------
|<---MNP1:1::MR2 (NOT AUTOCONF address)
e|<--- ANP::MR2/128 or ANP:2::MR2/64 <-- how??
+-+-+
|MR2|
+-+-+
i|
-----+------
Figure 13: AUTOCONF Addressing Assignment when Fixed Router is
employed
Wakikawa, et al. Expires January 2, 2008 [Page 17]
Internet-Draft MANEMO Architecture July 2007
4.3. Comparison of Two Approaches
Before discussing the two approaches, the known MANEMO problems [10]
are listed here.
o Sub-optimal Route and Redundant tunnel
o Network Loop
o Multiple Exit Routers (Exit Router selection)
o No Communication capability without Home Agent Reachability
If the AUTOCONF approach (Section 4.2) is taken, every mobile router
may be expected to run a manet routing protocol such as DYMO, OLSR,
AODV. Although AUTOCONF approach may not apply to the MANEMO
scenarios without modification, MANET + AUTOCONF combination can
solve some of MANEMO issues. The sub-optimal route can be easily
solved because each mobile router can registers its care-of address
generated from the access network prefix. The packets are routed to
the access router by IP routing and then routed to the correspondent
mobile router by the manet routing. Thus, suboptimal route and
redundant tunnel are even not happened in this case. The loop free
topology formation is essential of a manet routing protocol, too.
The multiple exits may be solved if a manet routing protocol carries
additional information of exit routers along with the route
information. Finally, if manet routes between mobile routers are
established, mobile routers can communicate without reaching to the
home agent.
If the NEMO addressing approach is selected, None of the issues are
solved, because the MANEMO activity is begun on the assumption of the
NEMO addressing approach.
One thing we have to discuss here is the movement pattern. There are
two movement patterns in MANEMO, mobile router's alone movement and
grouped movement. For the mobile router's alone movement, a mobile
router just leaves its MANEMO and goes somewhere. Therefore, this
movement pattern is similar to what MANET is addressing (ex. random-
way point). On the other hand, the grouped mobility is very NEMO
specific movement pattern. When considering the use case such as
passenger's PAN enters in the train, all the mobile routers move all
together. We discuss the grouped mobility in further section.
Figure 14 shows an example of MANEMO topology. The arrows of the
left side of Figure 14 shows the extent of the impact when MR1
changes its attachment from AR1 to AR2 with grouped mobility pattern.
If the NEMO approach is used, the impact of MR1 change is hidden by
Wakikawa, et al. Expires January 2, 2008 [Page 18]
Internet-Draft MANEMO Architecture July 2007
MR1. In the AUTOCONF approach, the impact is propagated to entire
mobile routers that are located behind MR1. What the NEMO Basic
Support guarantees is movement transparency of a mobile router.
Thus, even if MR1 changes its point of attachment, this change is
perfectly hidden from MR2, MR3 and MR4. Even if MR1 changes its
attachment, the topology relationship among MR1 , MR2, MR3 and MR4 is
not changed. This movement transparency should be supported also in
nested NEMO formation because this is essential feature of the NEMO
Basic Support protocol. In the AUTOCONF and the MANET approach, this
feature is missed due to the AUTOCONF addressing assignment. A
mobile router obtains an address not from the upper mobile network,
but directly from the access router. If MR1 changes its attachment
to MR2, all the mobile routers behind MR1 (MR2, MR3 and MR4) are
affected by the change of MR1. MR2, MR3 and MR4 should obtain a new
address from AR2 after MR1 changes its attachment to AR2.
Access Networks
| |
+-+-+ +-+-+
|AR1| |AR2|
+-+-+ +-+-+
| ---> :
NEMO AUTOCONF |..................:
/|\ /|\ +-+-+
\|/ | |MR1|
| +-+-+
| |
| -----+-----
| |
| +-+-+
| |MR2|
| +-+-+
| |
| -+------+------+-
| | |
| +-+-+ +-+-+
| |MR3| |MR4|
| +-+-+ +-+-+
| | |
\|/ -----+----- -----+-----
Figure 14: Extent of the Impact from MR1 movement
Wakikawa, et al. Expires January 2, 2008 [Page 19]
Internet-Draft MANEMO Architecture July 2007
5. Solution Guideline
This section classifies existing and proposed solutions for the
MANEMO scenarios. We isolated 2 families:
1. Nested NEMO Route Optimization (NEMO centric approach): This is
the initial root problem of MANEMO. NEMO mobile routers attach
to one another, and MANEMO should optimize the resulting topology
for access to the infrastructure, provide a safe model for mobile
routers to help one another, some degree of inner routing etc.
As shown in Section 4.1, the topology of Nested NEMO becomes
tree. For this approach, Tree Discovery [11] has been proposed
to form a loop-free tree in MANEMO and NINA [12] provides some
routing in that space. Reverse Routing Header (RRH) [13] is a
solution how to bypass the number of home agents when mobile
routers form the nested NEMO.
2. Mobile ad hoc (MANET centric): This is when NEMO mobile routers
form a MANET. We found 3 categories:
1. "1 hop away" A mobile router only discovers a neighbor mobile
router(s) and communicate with them directly. The example
use case is the car 2 car. NANO [14] provides a very simple
solution.
2. "2 hops away" This is where the NHDP [15] could be inserted,
still no use of a real routing protocol. A mobile router
manages routes for 2-hop neighbor mobile routers.
3. "General MANET" In this case, we need a routing protocol of
the MANET family. MANEMO could still help in several
fashion, for instance provide scalability by splitting the
larger network in a number of more manageable islands,
interconnected by NEMO over the infrastructure.
Wakikawa, et al. Expires January 2, 2008 [Page 20]
Internet-Draft MANEMO Architecture July 2007
6. IANA considerations
This document does not require any IANA action.
Wakikawa, et al. Expires January 2, 2008 [Page 21]
Internet-Draft MANEMO Architecture July 2007
7. Security Considerations
This document is a architecture model and does not create any
security threat. It discusses the concepts of Capability,
Innocuousness and Anonymity in a nested NEMO.
Wakikawa, et al. Expires January 2, 2008 [Page 22]
Internet-Draft MANEMO Architecture July 2007
8. Acknowledgments
We would like to thank Teco Boot, Jim Bound, Jari Arkko and Lim Hyung
Jin for their comments on this document. We would also like to thank
all the people involved in MANEMO activity.
9. References
9.1. Normative reference
[1] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-06 (work in progress),
November 2006.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
9.2. Informative Reference
[6] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
progress), September 2006.
[7] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route
Optimisation Problem Statement",
draft-clausen-nemo-ro-problem-statement-00 (work in progress),
October 2004.
[8] Thaler, D., "Multilink Subnet Issues",
draft-iab-multilink-subnet-issues (work in progress),
January 2007.
[9] Chakeres, I., "Mobile Ad hoc Network Architecture",
draft-ietf-autoconf-manetarch-01 (work in progress),
March 2007.
[10] Wakikawa, R., "MANEMO Problem Statement",
Wakikawa, et al. Expires January 2, 2008 [Page 23]
Internet-Draft MANEMO Architecture July 2007
draft-wakikawa-manemo-problem-statement-00 (work in progress),
February 2007.
[11] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-04 (work in progress),
November 2006.
[12] Thubert, P., "Network In Node Advertisement",
draft-thubert-nina-00 (work in progress), February 2007.
[13] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-06 (work in
progress), September 2006.
[14] Petrescu, A. and C. Janneteau, "The NANO Draft (Scene Scenario
for Mobile Routers and MNP in RA)",
draft-petrescu-manemo-nano-00 (work in progress), March 2007.
[15] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-00 (work in progress), June 2006.
Wakikawa, et al. Expires January 2, 2008 [Page 24]
Internet-Draft MANEMO Architecture July 2007
Authors' Addresses
Wakikawa Ryuji
Keio University
Department of Environmental Information, Keio University.
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
Thomas Clausen
LIX, Ecole Polytechnique
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
McCarthy Ben
Lancaster University
Computing Department, Lancaster University.
InfoLab 21, South Drive
Lancaster, Lancashire LA1 4WA
UK
Phone: +44-1524-510-383
Fax: +44-1524-510-492
Email: b.mccarthy@lancaster.ac.uk
URI: http://www.network-mobility.org/
Alexandru Petrescu
Motorola Labs
Parc les Algorithmes Saint Aubin
Gif-sur-Yvette 91193
France
Email: Alexandru.Petrescu@motorola.com
Wakikawa, et al. Expires January 2, 2008 [Page 25]
Internet-Draft MANEMO Architecture July 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).
Wakikawa, et al. Expires January 2, 2008 [Page 26]