No Working Group R. Wakikawa
Internet-Draft Keio University
Expires: January 10, 2008 P. Thubert
Cisco
T. Boot
Infinity Networks
J. Bound
HP
B. McCarthy
Lancaster University
July 9, 2007
Problem Statement and Requirements for MANEMO
draft-wakikawa-manemo-problem-statement-01.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 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wakikawa, et al. Expires January 10, 2008 [Page 1]
Internet-Draft PS. and Req. for MANEMO July 2007
Abstract
The NEMO Basic Support protocol has well-known issues when multiple
mobile routers are connected to each other in a nested fashion.
These issues have been already analyzed in the NEMO Working Group.
However, solutions are not yet considered and discussed in the IETF.
MANEMO (MANET for NEMO) is an approach to resolve these issues.
Although most of issues are relevant to what the MANET working group
is chartered to deliver, a different approach may be required. This
document identifies the problems which MANEMO will solve and provides
the MANEMO requirements.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. MANEMO Characteristic . . . . . . . . . . . . . . . . . . . . 6
4. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 10
5. Existing Solutions and MANEMO approach . . . . . . . . . . . . 12
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative reference . . . . . . . . . . . . . . . . . . . 18
10.2. Informative Reference . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log From Previous Version . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Wakikawa, et al. Expires January 10, 2008 [Page 2]
Internet-Draft PS. and Req. for MANEMO July 2007
1. Introduction
Mobile Ad-hoc Network mechanisms have been standardized for local
communication when wireless nodes are connected in an ad-hoc fashion.
Several routing protocols were already standardized within the MANET
working group and almost ready for deployment. The AUTOCONF working
group has been recently formed to standardize the IP address
configuration (both local address and global address). On the other
hand, the NEMO working group has standardized the NEMO Basic Support
Protocol [1] for global mobility of networks to support network
movement transparency. The MANET/AUTOCONF and the NEMO working
groups discuss their solutions separately without the consideration
of integrating them. In the NEMO Working Group, the well-known
issues caused by nested NEMO are addressed. Some of them are very
similar to what the MANET/AUTOCONF working groups deal with as a
problem space. However, the NEMO Basic Support protocol requires
always connected Home Agent reachability and network movement
transparency in relation to a mobile network. These multiple effort
creates some contradiction between MANET/AUTOCONF and NEMO. We
discuss this contradiction briefly in this document and also in [11].
In addition to that, the MANET protocols (DYMO [12] and OLSR [13])
may solve many of the upcoming problems introduced by new
technologies, but implementing all functionalities of the MANET
routing protocols may not be always desired for some specific issues.
As the 6lowpan Working Group works on how to apply MANET protocols to
LoWPANs (ex. RSN mailing list: Routing Sensor Network), it may be
required to determine the possibility of either extending or
downsizing the existing MANET/ AUTOCONF solutions for the nested NEMO
problems for a sensor network. Since the nested NEMO problems are
minor issues caused only within the NEMO Basic Support model, it may
be time to look at a light-weight approach for the issues within the
IETF.
Solutions for MANEMO have already been proposed within the IETF such
as [14] and [15]. The NEMO Working Group has the analysis document
[16] for the nested NEMO issue. MANEMO is possibly related to the
following on- going work in IETF.
o Existing Routing Protocols (MANET, OSPF)
o Network Mobility Support (NEMO)
o Mobile Ad-hoc Network and Auto Configuration (AUTOCONF)
o Mobile Ad-hoc Sensor Network (6LOWPAN)
Wakikawa, et al. Expires January 10, 2008 [Page 3]
Internet-Draft PS. and Req. for MANEMO July 2007
o Mobile Nodes and Multiple Interfaces in IPv6 (Monami6)
Wakikawa, et al. Expires January 10, 2008 [Page 4]
Internet-Draft PS. and Req. for MANEMO July 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 RFC 2119 [2]
Readers are expected to be familiar with all the terms defined in the
RFC3753 [3] and the NEMO Terminology draft [4]
MANEMO Fringe Stub (MFS) The MANEMO Fringe Stub is a cloud of Mobile
Routers connected by wireless or wired links. Any type of link
supporting IPv6 connectivity can be used, including partly meshed
wireless topologies. An MFS is a stub at the edge of the
Internet, interconnecting various types of devices which discover
each other and form a network in an ad-hoc fashion to provide
global connectivity to one another. Many disjunctive MFS can be
connected to the Internet. An MFS can also be floating, which
means the cloud is not connected to the Internet.
Exit Router The Exit Router is a router which provides connectivity
to the Internet and acts as a layer-3 sink for the MFS. The Exit
Router can be a fixed Access Router supporting MANEMO or a mobile
router (root-MR) connected directly to the Internet. Multiple
Exit Routers may be available in an MFS.
MANEMO MANET for NEMO. MANEMO provides the necessary additions to
existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to
find the most suited exit towards the Internet. MANEMO enables
some internal connectivity within the nested NEMO whether the
Internet is reachable or not. MANEMO is not MANET + NEMO. MANET
+ NEMO could suggest a MANET protocol reuse whereas MANET for NEMO
suggests the development of a new protocol.
Nested NEMO The Nested NEMO is a network configuration where one or
more mobile routers are connected in a nested formation. The
detailed issues can be found in [17] and [18].
Wakikawa, et al. Expires January 10, 2008 [Page 5]
Internet-Draft PS. and Req. for MANEMO July 2007
3. MANEMO Characteristic
Before discussing the detail of MANEMO problems, we highlight the
characteristics of MANEMO Fringe Stub (MFS) by comparing it with a
traditional ad-hoc network (MANET) in this section.
Mobile routers of RFC3963 are the core nodes of an MFS. A mobile
network served by a mobile router is seen as a normal IPv6 network.
It is possible for a mobile router to connect to another mobile
router's mobile network. As a result, mobile routers are connected
and form a nested topology which is known as nested NEMO. In MFS,
not only mobile routers, but also mobile hosts, fixed nodes (host and
router) are considered. Fixed hosts and routers can be connected to
one of the mobile networks and can also be located in the Internet.
Access routers to provide wireless connectivity are also considered
as a node within an MFS. All these nodes may be involved within the
MANEMO protocol. Figure 1 shows the abstract topology of mobile
routers. Two exit routers (ER1 and ER2) are identified and each
number indicates a mobile router. In order to highlight the MANEMO
characteristic, we only show the mobile routers in the topology. We
discuss all the possible topologies of mobile routers in MFS in the
MANEMO architecture [11]. Each mobile router owns an assigned prefix
from its home agent. The prefix is configured for a mobile network.
A mobile router acquires a topologically correct address (care-of
address) at the egress interface and tunnels all the data to its home
agent by using the care-of address.
Although MANET supports Internet connectivity, because of NEMO Basic
Support, the reachability to its home agent for home registration is
a fundamental aspect of MANEMO. Without home registration, it cannot
communicate to other nodes with its mobile network prefix according
to RFC3963. If the binding registration is completed, all the
traffic from the mobile network is tunneled to the home agent. In
NEMO context, at least one exit router for MFS is required. MR1 and
MR3 of Figure 1 can be away from the wireless attach facility and
loose connectivity to the network. The disconnected MFS can also
occur. Moreover, on the MANEMO mailing list, we currently discuss
the case when each mobile router is connected by the egress interface
and forms a MANET-like network. This case can be seen as "mobile
routers forming a mobile ad-hoc network". Except for the assigned
prefix to each mobile router, the characteristic of this scenario may
be same as mobile ad-hoc network.
Wakikawa, et al. Expires January 10, 2008 [Page 6]
Internet-Draft PS. and Req. for MANEMO July 2007
+-------------------+ Internet (Wired/Wireless)
| | |
| | \|/
ER1 ER2 /|\
| / |
1---2 3 |
|\ / | Wireless Links
4 5---6---7----8--9 |
| \ \ |
10---11 12 13---14 \|/
Figure 1: Example Topology
Figure 2 shows the difference of communication model between MANET
and MANEMO. A mobile router (MR6) communicates with another mobile
router (MR14) . The Figure 2-a shows the basic MANET communication
model. MANET protocols maintain local routing information so that
they can communicate directly inside this ad-hoc network. Even if
there are multi-paths between nodes, most of the MANET routing
protocols select the shortest path in default. If many sessions are
in process within the network, the congestion at some links can be
obviously observed. The links between MR6 to MR8 in Figure 2 may
become possible bottlenecks if many nodes are communicating at the
same time. Figure 2-b, on the other hand, shows the MANEMO
communication model. The default communication path between MR6 and
MR14 is through the Internet. Each mobile router transmits packets
to the exit router even if the destination node is located nearby.
Thus, packets are traveled over the Internet (through several home
agents if it is required) and routed to the exit router to which the
destination mobile router belongs. Even if the path length may
increase, the path over the Internet is often more reliable than the
shortest link. Note that it is true that the link between ER1-MR1
and ER2-MR3 become the bottleneck for all the traffic coming in and
out of the MFS. Additional latency may also be observed, but it is a
trade-off of several aspects such as latency, congestion, reliability
and costs of local routing management (MANET routing protocol). In
MANEMO, it is still possible to maintain the neighboring mobile
routers. End nodes can communicate to the destination directly along
the shortest path (not through the exit routers). Each mobile router
should be able to decide whether the packets are routed to the exit
router or to the destination directly. MANEMO does not identify how
to manage local routing, but the primarily goal is to manage the path
to the exit router as a default.
Wakikawa, et al. Expires January 10, 2008 [Page 7]
Internet-Draft PS. and Req. for MANEMO July 2007
(Internet)
+===== HAn =======+
ER1 ER2
|| //
1---2 3 1---2 3
|\ / |\\ //
4 5---6<==7====8--9 4 5==>6---7----8--9
| \ \\ | \ \\
10---11 12 13==>14 10---11 12 13==>14
a) MANET b) MANEMO
Figure 2: Communication Model
When a mobile router changes its point of attachment, it must hide
the changes from any nodes located in its mobile network [1]. Since
nodes in the mobile network are moved all together, sets of mobile
routers can move at once in MFS. Nodes can be an IPv6 node, a mobile
host of RFC3775, and a mobile router of RFC3963. For instance, in
Figure 3, a mobile router (MR4) moves its point of attachment. Even
if MR4 moves, the movement has minimum impact to any nodes including
mobile routers (MR10 and MR11) located in the MR4's mobile network.
The mobile network nodes must be completely unaware of the movement.
On the other hand, within most of the MANET and AUTOCONF schemes, the
change of MR4's attachment effects the neighboring nodes (possibly
the entire network). Most of the routing protocols require the route
re-calculation or route re-discovery (route maintenance) when
topology changes are occurred. This should be avoided because it
breaks the nature of the NEMO basic support protocol. A detailed
explanation can be found in [11].
+------------------+ +------------------+
ER1 ER2 ER1 ER2
| / | /
1---2 3 ==> 1---2 3
|\ / \ /
|4| 5---6---7----8--9 5---6---7----8--9
| \ \ \ \
10---11 12 13---14 12 13---14
|
Router-4 moves to Router-12 |4|
>|
> 10---11
^^^^^^^
Wakikawa, et al. Expires January 10, 2008 [Page 8]
Internet-Draft PS. and Req. for MANEMO July 2007
movement transparency
Figure 3: Movement Model
Another aspect of MANEMO characteristic is that each mobile router
can be connected by different wireless technology, while a default
MANET assumption is to use a single wireless interface in ad-hoc mode
(ex. 802.11b ad-hoc mode). Each mobile router has, at least two
interfaces such as egress and ingress interfaces. For example, MR3
connects to ER2 by 3G (HSDPA), MR3 and MR8 are connected by 802.11b,
MR8 and MR13 are by 802.11g, and so on. as described in Figure 4.
+------------------+
ER1 ER2
| WiMAX / <-3G(HSDPA)
1---2 3
|\ / <-wifi(802.11b)
4 5---6---7----8--9
| \ \ <-wifi(802.11g)
10---11 12 13---14
wifi(802.11a)
Figure 4: Movement Model
The final difference is the routing capability. In MANET, each
router can route the packet received at the manet interface [19]. A
route can receive a packet from a manet interface and can send the
packet from the same manet interface according to its routing table.
However, in the NEMO Basic Support model, a mobile router can route
only the tunneled packet to and from its mobile network. Without the
bi- directional tunnel, the mobile router never routes the non-
tunneled packet according to [1]. The packet sent from the ingress
interface is always routed to the mobile router's home agent by using
IP encapsulation. The incoming packets must always be tunneled from
the mobile router's home agent except for the packets sent to the
mobile node itself.
Wakikawa, et al. Expires January 10, 2008 [Page 9]
Internet-Draft PS. and Req. for MANEMO July 2007
4. Problem Statements
Radio connectivity and movement have disrupted the concept of a link
as we know it in the wired environment. Specific modes for specific
radios are proposed to restore that concept, which is essential for
IP operations, as single hop (802.11 infrastructure mode) or multihop
(802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified
solution to reconstruct a minimum topological abstraction at layer 3
for the use of NEMO.
The MANEMO problems are already observed in several Working Groups
and some are specified in [17], [20]
1. Sub-optimal route and Redundant tunnel: This issue is described
in Section 2.1, 2.3 and 2.6 of [17] and in Appendix B.1, B.2,
B.3, B.4 of [17].
2. No Communication capability without Home Agent Reachability: This
issue is described in Section 2.6 of [17]
3. Exit Router Selection: This problem occurs when a mobile node
obtains multiple Exit Routers toward the Internet. In the
illustrated case, the mobile node should attempt to obtain some
information about each Exit Router in order to more efficiently
utilize them. MANEMO may carry this information about each Exit
Router and present it to the connected mobile node.
. . . . . . . . . . . ..
. .
. The Internet .
. .
.. . . . . . . . . . . .
| |
+-+-+ +-+-+
|AR1| |AR2+--+
+-+-+ +-+-+ |
| +---+ | |
+-----|MR1|----+ |
+-+-+ |
| +-+-+
+--------+MR2|
+---+
Figure 5: Multiple Exit Routers
Wakikawa, et al. Expires January 10, 2008 [Page 10]
Internet-Draft PS. and Req. for MANEMO July 2007
4. Network Loop: A network loop can occur when multiple mobile
routers are nested and suddenly the Exit Router (root-MR, i.e.
MR1) looses connectivity to the Internet and connects to the
mobile network of a lower hierarchical MR (i.e. MR2 in the
figure). In this case, the loop is observed between mobile
routers. Each mobile network is designed to have movement
transparency from the NEMO Basic Support Protocol. Any node
connecting to a mobile network cannot know whether the access
network is a mobile network or not. Moreover, it is impossible
to know whether a connecting mobile router has managed Internet
connectivity or not. The mobile router may loose Internet
Connectivity, temporarily.
Internet Internet
| |
+-+-+ +-+-+
|AR | |AR |
+-+-+ +---+
|
+-+-+ +---+
|MR1| --> |MR1+->+
+-+-+ +-+-+ |
| /|\ |
| | |
+-+-+ +-+-+ \|/
|MR2| |MR2|<-+
+---+ +---+
Figure 6: Network Loop
Section 4.8 of [20] discussed the loop problem when a mobile
router is multihomed.
Wakikawa, et al. Expires January 10, 2008 [Page 11]
Internet-Draft PS. and Req. for MANEMO July 2007
5. Existing Solutions and MANEMO approach
Several approaches can be taken for the problems listed in Section 4.
Some analysis can be found in [21].
[MANET Routing Protocol and AUTOCONF] While manet routing protocols
maintain the local connectivity, the primary goal of MANEMO is to
discover an exit router and to maintain the path to the Internet
through the exit router for binding registration and traffic over
the bidirectional tunnel. Only for this purpose, MANET routing
protocols have excess functionalities such as flooding messages
for route discovery or route updates, etc. The primary goal of
the MANET routing protocols is to maintain local connectivity.
However, the local connectivity management should not be mandated
to the MANEMO solution, although MANEMO may be interested in the
local routing in the future. The NEMO Basic Support protocol
basically requires tunneling the packets to the Internet. NHDP
[22] is alternate solution to discover neighboring nodes, but it
is limited to only two hop neighbors' information. There is a
case that an exit router is more than 2 hops away. The AUTOCONF
working group discusses the address assignment scheme for ad-hoc
networks. However, the addressing architecture is slightly
different from what the NEMO basic support protocol is expecting.
More details can be found in [11].
[NEMO Route Optimization Scheme] There is no route optimization
scheme in IETF. Only the analysis document is available in [16].
Contrary to the existing solutions, MANEMO arranges a tree structure
towards the Internet. This tree is the simplest network topology
connecting Mobile Routers within an MFS to a single Exit Router. The
Exit Router is the root of the MANEMO Tree. The packets from MFS are
routed along the tree and are routed to the destination. Routing to
multiple home agents should be avoided as much as possible. Basic
required functionalities for MANEMO are:
1. Discovering and Selecting exit routers
2. Forming loop-free Tree by making an exit router as a root
3. Maintaining the path to the exit router
4. Bypassing Home Agents for the traffic from MFS
The MANEMO work focus is on a Neighbor Discovery (ND) [5] based
solution that is required to provide multihop reachability while
supporting the inner movements within the nested NEMO. ND provides
the means to discover neighbors and the prefix on a link, which are
Wakikawa, et al. Expires January 10, 2008 [Page 12]
Internet-Draft PS. and Req. for MANEMO July 2007
pervasive across IPv6 nodes and link types. Mobile IPv6 [6] and NEMO
[1] rely heavily on ND for roaming and Home Link activities.
Considering that NEMO already uses ND for Router Discovery, it makes
sense to extend ND in MANEMO as opposed to providing a second peering
mechanism.
ND has already been extended to expose some layer 3 information, such
as router selection hints [7]. ND is consistently being improved for
mobility, in particular with Mobile IPv6 [6] and DNA [23], and for
security with Secure ND [8]. ND operates on bidirectional links,
whereas this is a restriction from the MANET standpoint, this
condition enables simpler solutions for MANEMO. Neighbor Discovery
is well suited for providing hints for composing a path to the
Internet access router. The Exit Routes connect MFS to the Internet.
Multicast support could be provided by using the loop-free MANEMO
Tree to forward packets to the Internet. Down-tree forwarding would
use MLD-proxy [24], either with native MLD [9][10] / ICMP packets or
send with the ND extensions to increase efficiency.
Wakikawa, et al. Expires January 10, 2008 [Page 13]
Internet-Draft PS. and Req. for MANEMO July 2007
6. Requirements
MANEMO has the following requirements:
R1: MANEMO must enable the discovery of multihop topologies at layer
3 from mere reachability and elaborate links for IPv6 usage,
regardless of the wired or wireless media.
R2: MANEMO must enable packets transmitted from nodes visiting the
MFS to reach the Internet via an optimized path towards the
nearest Exit Router, and back.
R3: MANEMO must enable IP connectivity within the MFS whether
Internet is reachable or not.
R4: MANEMO must enable packets transmitted from nodes visiting the
MFS to reach the Internet with a topologically correct address.
R5: MANEMO should aim at minimizing radio interference with itself
as the control messages get propagated in the MFS.
R6: MANEMO must enable inner movements within MFS to occur, and
ensure propagating details of this movement is kept at a minimum.
R7: An MFS may split to become two separate MFSs, in this case
MANEMO must continue to maintain local connectivity within the
separate MFSs and connectivity between the split MFSs. MFSs may
merge, in this case inner MFS connectivity optimization must be
restored.
R8: MANEMO should enable and optimize the trade-off between ensuring
some reciprocity between MFS peers and maintaining a safe degree
of CIA properties between the peer Mobile Routers.
R9: MANEMO must support ad-hoc operation, for isolated MFSs (R3) and
multi-hop access to the Internet (R2).
R10: MANEMO must not require modifications to any node other than
nodes that participates to the MFS, including HA. It must support
fixed nodes, mobile hosts and mobile routers in the MFS, and
ensure backward compatibility with other standards defined by the
IETF.
R11: MANEMO should enable multicast communication, for nodes within
the MFS and on the Internet.
Wakikawa, et al. Expires January 10, 2008 [Page 14]
Internet-Draft PS. and Req. for MANEMO July 2007
R12: MANEMO must optimize the path to the Internet using cross-layer
metrics.
R13: MANEMO may provide direct peer to peer reachability for nearby
nodes.
Wakikawa, et al. Expires January 10, 2008 [Page 15]
Internet-Draft PS. and Req. for MANEMO July 2007
7. IANA considerations
This document does not require any IANA action.
Wakikawa, et al. Expires January 10, 2008 [Page 16]
Internet-Draft PS. and Req. for MANEMO July 2007
8. Security Considerations
This document is a problem statement 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 10, 2008 [Page 17]
Internet-Draft PS. and Req. for MANEMO July 2007
9. Acknowledgments
We would like to thank all the people who have provided comments on
this draft, and also co-authors of earlier documents in which authors
of this present document have been engaged. As such, we would like
to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham
Soliman, Carlos Jesus Bernardos Cano and many others.
10. References
10.1. Normative reference
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-06 (work in progress),
November 2006.
[5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005.
[8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
Wakikawa, et al. Expires January 10, 2008 [Page 18]
Internet-Draft PS. and Req. for MANEMO July 2007
10.2. Informative Reference
[11] Wakikawa, R., "MANEMO Topology and Addressing Architecture",
draft-wakikawa-manemoarch-00 (work in progress), July 2007.
[12] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO)
Routing", draft-ietf-manet-dymo-10 (work in progress),
July 2007.
[13] Clausen, T., "The Optimized Link State Routing Protocol version
2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007.
[14] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-07 (work in
progress), February 2007.
[15] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-06 (work in progress), July 2007.
[16] Ng, C., "Network Mobility Route Optimization Solution Space
Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in
progress), September 2006.
[17] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
progress), September 2006.
[18] Clausen, T., "NEMO Route Optimisation Problem Statement",
draft-clausen-nemo-ro-problem-statement-01 (work in progress),
March 2007.
[19] Chakeres, I., "Mobile Ad hoc Network Architecture",
draft-chakeres-manet-arch-01 (work in progress), October 2006.
[20] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-07 (work in progress),
February 2007.
[21] Boot, T., "Analysis of MANET and NEMO",
draft-boot-manet-nemo-analysis-01 (work in progress),
June 2007.
[22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-04 (work in progress), July 2007.
[23] Kempf, J., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-06 (work in progress),
Wakikawa, et al. Expires January 10, 2008 [Page 19]
Internet-Draft PS. and Req. for MANEMO July 2007
June 2007.
[24] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD-
Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in
progress), April 2004.
Wakikawa, et al. Expires January 10, 2008 [Page 20]
Internet-Draft PS. and Req. for MANEMO July 2007
Appendix A. Change Log From Previous Version
o Removed Use-Case Scenarios
o Updated the Section4: use the references to existing documents
o Removed the Approach Rationale
Authors' Addresses
Ryuji Wakikawa
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/
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Teco Boot
Infinity Networks B.V.
Elperstraat 4
Schoonloo 9443TL
Netherlands
Email: teco@inf-net.nl
Wakikawa, et al. Expires January 10, 2008 [Page 21]
Internet-Draft PS. and Req. for MANEMO July 2007
Jim Bound
Hewlett-Packard
PO BOX 570
Hollis, NH 03049
USA
Phone: +603 465 3130
Email: jim.bound@hp.com
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/
Wakikawa, et al. Expires January 10, 2008 [Page 22]
Internet-Draft PS. and Req. for MANEMO 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 10, 2008 [Page 23]