Network Working Group P. Thubert
Internet-Draft M. Molteni
Expires: April 11, 2003 Cisco Systems
October 11, 2002
Taxonomy of Route Optimization models in the Nemo Context
draft-thubert-nemo-ro-taxonomy-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 April 11, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Nemo enables Mobile Networks by extending Mobile IP to support Mobile
Routers. This paper documents how the MIPv6 concept of Route
Optimization can to be adapted for Nemo to optimize:
1) the nested tunnels of the nested Nemo configuration
2) router-to-router within the infrastructure as opposed to end-to-
end.
and much more ... :)
Thubert & Molteni Expires April 11, 2003 [Page 1]
Internet-Draft RO-Taxonomy October 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 3
2.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 3
2.2 Route Optimization inside the Nested Mobile Network . . . . . 6
3. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. MIPv6 Route Optimization over Nemo . . . . . . . . . . . . . . 6
5. Optimization within the infrastructure . . . . . . . . . . . . 7
5.1 Route Optimization within a ISP network . . . . . . . . . . . 8
5.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 8
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
Thubert & Molteni Expires April 11, 2003 [Page 2]
Internet-Draft RO-Taxonomy October 2002
1. Introduction
This document assumes the reader is familiar with Mobile IPv6 defined
in [1], with the concept of Mobile Router (MR) and with the Nemo
terminology defined in [2].
From the discussions on the mailing list, it appears that the common
current understanding of the problem space of Route Optimization
(RO), in the Nemo context, is still limited.
This paper attempts to clarify the state of the discussion and
propose a taxonomy of the various aspects of the problem.
2. Nested Mobile Network
2.1 Nested Tunnels Optimization
Let us illustrate the problem by an example. In this example, the
nested Mobile Network has a tree topology. In the tree each node is
a basic Mobile Network, represented by its MR.
+---------------------+
| Internet |---CN
+---------------|-----+
/ Access Router
MR3_HA |
======?======
MR1
|
====?=============?==============?===
MR5 MR2 MR6
| | |
=========== ===?========= =============
MR3
|
==|=========?== Net3
LFN1 MR4
|
=========
An example nested Mobile Network
This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3)
inside the tree, represented by its mobile router MR3. The path to
the Top Level Mobile Router (TLMR) MR1 and then the Internet is:
MR3 -> MR2 -> MR1 -> Internet
Thubert & Molteni Expires April 11, 2003 [Page 3]
Internet-Draft RO-Taxonomy October 2002
Consider the case where a LFN belonging to Net3 sends a packet to a
Correspondent Node (CN) in the Internet, and the CN replies back.
With no Nested Tunnels Optimization, we would have three bi-
directional nested tunnels, as described in [3] and illustrated in
the following drawings:
-----------.
--------/ /-----------.
-------/ | | /-----------
CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN
MR3_HA -------\ | | \----------- MR3
MR2_HA --------\ \----------- MR2
MR1_HA ----------- MR1
No Nested Tunnels Optimization
Such a solution introduces the following problems:
"Pinball" routing
Both inbound and outbound packets will flow via the HAs of all the
MRs on their path within the NEMO, with increased latency, less
resilience and more bandwidth usage.
Packet size
An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [4] cannot be
applied because both the source and destination (the intermediate
MR and its HA), are different hop to hop.
On the other hand, with a Nested Tunnel Optimization, we would have
at most one bi-directional tunnel outside the Mobile Network, that
may depend on the traffic flow:
__- --_
Tunnel---------------------------- MR1 ( Mobile ) MR3
CN ----------( - - - - - - - - - - ( - - - - )--------- LFN
Endpoint---------------------------- MR1 ( Network ) MR3
--___---
Nested Tunnels Optimization
The end-point of such a Tunnel on the Mobile side may either be MR1
or MR3, depending on the solution. In the case of a Mobile Node
visiting Net3, that Mobile Node may also be the end-point.
Thubert & Molteni Expires April 11, 2003 [Page 4]
Internet-Draft RO-Taxonomy October 2002
The potential approaches for avoiding the nesting of tunnels include:
Mobile Aggregation
This model applies to a category of problems were the Mobile
Networks share a same administration and consistently move
together (e.g. a fleet at sea). In this model, there is a
cascade of Home Agents. The main Home Agent is fixed in the
infrastructure, and advertises an aggregated view of all the
Mobile Networks. This aggregation is actually divided over a
number of Mobile Routers, the TLMRs. The TLMRs subdivide some of
their address space to the other Mobile Routers forming their
fleet, for which they are Home Agent. As Home Agents, the TLMRs
terminate MIP Tunnels from the inside of the Mobile Network. As
Mobile Router, they also terminate their home Tunnels. As
routers, they forward packets between the 2 tunnels.
Surrogate
The TLMR acts as a proxy in the MIP registration, in a fashion of
MIPv4 Foreign Agent or HMIP MAP (see [7]). For instance, the TLMR
maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and
switches packets between the two.
Internal Routing and gateway
This item can be approached from a MANET standpoint. This was
already done for DSR (see [8]) and AODV (see [9] and [6]) From a
Nemo standpoint, a full MANET is not necessary since the goal is
to find a way to the infrastructure, as opposed to any-to-any
connectivity.
RRH
The Reverse Routing Header (RRH) approach avoids the multiple
encapsulation of the traffic but maintains the home tunnel of the
first MR on the egress path. It is described in details in [5].
The first MR on the way out (egress direction) encapsulates the
packet over its reverse tunnel, using a form of Record Route
header, the RRH.
The next MRs simply swap their CoA and the source of the packet,
saving the original source in the RRH. The HA transforms the RRH
in a Routing Header to perform a Source Routing across the nested
Mobile Network, along the ingress path to the target MR.
These approaches are generally difficult to secure unless all the
Mobile Routers and Visiting Mobile Node belong to a same
Thubert & Molteni Expires April 11, 2003 [Page 5]
Internet-Draft RO-Taxonomy October 2002
administrative domain and share predefined Security Associations.
The problem is global to the whole Mobile Network in the case of a
MANET-based solution. For an RRH-based solution, the threat comes
from on-axis MRs in the nested Mobile Network but is mostly limited
to denial of service. This is detailed in [5].
2.2 Route Optimization inside the Nested Mobile Network
This is not part of the Nemo Charter. The expectation is that the
mobile routes installed by Nemo can cohabit with a MANET support that
would perform the RO inside the Nested Mobile Network.
3. MR-to-CN
This section covers the case where the Route Optimization is
performed between the MR and the Correspondent Node.
A major issue is that the MIPv6 Reverse Routability test is broken,
since it is meant to ensure that the CoA (the MR) an the Home Address
(the Mobile Node) are collocated. With a Mobile Network, a LFN is
reachable via the Care-Of Address, but not at the Care-Of Address.
Some tricks may be performed on the fly by the MRs but it seems that
a clean MR-to-CN optimization for Nemo will impact the CN function.
Once we modify the CN behavior, we need to introduce a negotiation
from the start of the RR test to determine the protocol. In
particular, the Mobile Node and the CN must decide whether checking
the collocation is possible, and if not, whether a CN is willing to
accept the risk. If not, the optimization may be limited to
triangular routing MR->CN->HA->MR.
This is a major evolution from [1], since MIPv6 has no such
negotiation capability at this time.
4. MIPv6 Route Optimization over Nemo
When a Mobile Node visits a Mobile Network, the best Route
Optimization is obtained if the path in the Infrastructure is the
same as if the Mobile Network was attached at the attachment point of
the Mobile Router (i.e., there is not additional Tunneling that is
linked to Nemo).
An example of that is a Mobile Node with RRH capability. If the
Mobile Node emits packets with a RRH (as if it where the first MR),
then the MRs just add to the RRH but do not affect its path. The CN
must respond with RH type 2 based on RRH and if so, the MIP optimized
path can be used.
Thubert & Molteni Expires April 11, 2003 [Page 6]
Internet-Draft RO-Taxonomy October 2002
5. Optimization within the infrastructure
This section elaborates on cases where the Route Optimization is
performed within the Routing Infrastructure. In this model, both the
LFN behind the MR and the Correspondent can be MIP agnostic. The
drawback is the introduction of Mobile Routes in specific Routers,
causing additional signaling and load to the Routing Fabric.
The general idea is that there is a correspondent-side Router in the
infrastructure that is located "closer" to the Correspondent than the
HA. That Router can terminate MIP on behalf of the CN.
Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent
# n #
o # n # # :== Tunnel
o # n # o :== Optimized
o # n # n :== Non-Optimized
o # n #
################################## n #
C-Side oooooooooooooooooooooooooooooooo Mobile
Router ################################ Router
|
====Mobile Network=======
Optimization in the Infrastructure
This optimization is only valid when the path via the correspondent-
side Router is shorter than the path via the Home Agent.
The Optimization can take place independently for the 2 directions of
the traffic:
Egress
The MR locates the correspondent-side Router, establishes a Tunnel
with that Router and sets a route to the Correspondent via the
correspondent-side Router over the Tunnel. At this point, the
traffic to the Correspondent does not flow via the Home Agent
anymore.
Ingress
The correspondent-side Router is on the way of the traffic from
the Correspondent to the Home Agent. Also, it is aware of the MR
and the Mobile Networks behind the MR and establishes the
appropriate Tunnel and Route. At that point, it is able to
reroute the traffic to the Mobile Network over the Tunnel to the
MR.
Thubert & Molteni Expires April 11, 2003 [Page 7]
Internet-Draft RO-Taxonomy October 2002
5.1 Route Optimization within a ISP network
This form of Route Optimization provides local savings for a ISP.
This idea was described in Ohnishi's Mobile Border Gateway draft.
The goal is to locate the closest (BGP) gateway for a Correspondent
that is located outside of the domain, and tunnel between the MR and
that gateway as opposed to the Home Agent for that specific
Correspondent.
5.2 Correspondent Router
A globally better optimization is obtained if the tunnel from the MR
is terminated closer to the destination on the Correspondent side.
This is the role of a Correspondent Router (CR).
+-------------------+ # :== Tunnel
| Autonomous System | o :== Optimized
| ----------------- | n :== Non-Optimized
| |
| |
| Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent
| | # n #
| o | # n #
| o | # n #
| o | # n #
| o | # n #
| o | # n #
| #################################### ?
| CR oooooooooooooooooooooooooooooooooooooo Mobile
| #################################### Router
| | |
+-------------------+ ===========Mobile Network========
Correspondent Router
The MR locates the CR for a given Correspondent and establishes a
Tunnel to the CR for that destination and its prefix(es). Then, the
CR establishes the Tunnel back to the MR and the Mobile Routes to the
MR's Mobile Networks via that Tunnel.
Clearly, some extended MIP signaling has to be defined is to get
there in a secure fashion.
A key point is that the CR must be on the interception path of the
traffic from the Correspondent to the Mobile Networks in order to
reroute the traffic over the appropriate Tunnel. This can be
achieved in several fashions:
Thubert & Molteni Expires April 11, 2003 [Page 8]
Internet-Draft RO-Taxonomy October 2002
Redistribution
There's a limited Number of CRs that cover an Autonomous System.
They redistribute the Mobile Routes on the fly, or within rate and
amount limits. Garbage Collection is done at appropriate time to
limit the perturbation on the Routing.
Default Router
The CR is a Default Router for the Correspondent, or for the whole
AS of the Correspondent (it's a border gateway). In this case,
redistribution is not needed.
Core Routers
The Core Routers for the network of the Correspondent are all CRs.
If the path from the correspondent to the Home Agent does not pass
via a CR, then it's not worth optimizing. If it is, then the CRs
are on the way. Again, redistribution is not needed.
6. Conclusion
The Problem space of Route Optimization in the Nemo context is
multifold and can be split is several work areas. It will be
critical, though, that the solution to a given piece of the puzzle be
compatible and integrate smoothly with the others.
Hopefully, the solutions will build on MIPv6 ([1]), as recommended by
the Nemo Charter. On the other hand, MIPv6 seems to be evolving in a
direction that makes it more and more difficult to provide a Nemo
solution with backward compatibility, since:
1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,
2) The RR test has no negotiable option and is not open for
extension, and
3) The HaO and RH type 2 are designed for a collocated CareOf
Address. More specifically, they are not designed to be multi-hop as
RRH is, and not extensible, though RRH can be considered as an
extension of HaO.
The authors intent is to trigger fruitful discussions that in turn
will enhance our common understanding of the problem space so that at
some point, this paper turns into a problem statement for the Nemo
Route Optimization.
Thubert & Molteni Expires April 11, 2003 [Page 9]
Internet-Draft RO-Taxonomy October 2002
7. Acknowledgements
The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki
Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji
Wakikawa and Patrick Wetterwald for their various contributions.
References
[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July
2002.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ernst-monet-terminology-01 (work in progress), July 2002.
[3] Kniveton, T., "Mobile Router Support with Mobile IP", draft-
kniveton-mobrtr-02 (work in progress), July 2002.
[4] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-
deletion-00 (work in progress), November 2001.
[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks", draft-thubert-nemo-
reverse-routing-header-00 (work in progress), June 2002.
[6] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc
Networks", draft-wakikawa-manet-globalv6-01 (work in progress),
July 2002.
[7] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier,
"Hierarchical MIPv6 mobility management (HMIPv6)", draft-ietf-
mobileip-hmipv6-06 (work in progress), July 2002.
[8] Johnson, D., Maltz, D., Hu, Y. and J. Jetcheva, "The Dynamic
Source Routing Protocol for Mobile Ad Hoc Networks", draft-
ietf-manet-dsr-07 (work in progress), February 2002.
[9] Das, S., Perkins, C. and E. Royer, "Ad Hoc On Demand Distance
Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in
progress), July 2002.
[10] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
Thubert & Molteni Expires April 11, 2003 [Page 10]
Internet-Draft RO-Taxonomy October 2002
Authors' Addresses
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.com
Marco Molteni
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: mmolteni@cisco.com
Thubert & Molteni Expires April 11, 2003 [Page 11]
Internet-Draft RO-Taxonomy October 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Thubert & Molteni Expires April 11, 2003 [Page 12]