Network Working Group D. Jen
Internet-Draft L. Zhang
Intended status: Informational UCLA
Expires: April 22, 2010 October 19, 2009
Understand Mapping
draft-jen-mapping-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This draft discusses the different requirements that mapping to
support mobility has versus mapping to support routing scalability.
In mobility solutions, packets are forwarded to the location where
Jen & Zhang Expires April 22, 2010 [Page 1]
Internet-Draft Understand Mapping October 2009
mapping information is stored so that they can be encapsulated to the
final destination. In routing scalability solutions, mapping
information needs to be available at packet entry points to the
network. Attempts to use one mapping system for both purposes can
lead to high overhead in either mapping information distribution or
otherwise mapping information discovery, as well as stale mapping
information being used for data forwarding.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Mapping for Routing Scalability . . . . . . . . . . . . . . . . 3
3. Mapping for Mobility Support . . . . . . . . . . . . . . . . . 4
4. Differences in Mapping Requirements: Mobility Support vs
Scalable Routing . . . . . . . . . . . . . . . . . . . . . . . 5
5. Concluding Remarks: Separating Mobility Support from
Scalable Routing . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Jen & Zhang Expires April 22, 2010 [Page 2]
Internet-Draft Understand Mapping October 2009
1. Introduction
Since early 2007, the IRTF has recharted the Routing Research Group
(RRG) to develop a scalable routing architecture. Over the last two
years a number of proposed solutions have been presented to the RRG.
Although the final recommendation is still being worked on, the
general direction taken by most RRG proposals is based on the map &
encap approach [RFC1955]. This has led many people to ask the same
recurring question: since mapping is needed to solve the routing
scalability problem, and since mobility solutions typically involve a
binding/mapping function between an identifier and a mobile's current
IP address, can the same mapping solution for routing scalability be
used to support mobility?
We believe that some basic differences exist between the requirements
for the mapping needed for mobility support and that for routing
scalability. This draft is an attempt to articulate the basic
differences.
2. Mapping for Routing Scalability
Mapping for routing scalability is meant to reduce the information
storage requirements at routers. Scaling the routing system requires
an effective way to remove some number of entries in today's routing
sytem from some routers, without losing reachability to any
destinations. Once this is done, not all routers have routing
information for all destinations anymore. Thus packets are mapped
and then either encapsulated or translated before being forwarded
over a network of routers that do not have the specific routing
information for the packet destinations.
Since part of the current routing information is replaced by mapping
information, the mapping information must be stored in some
locations. The number and placement of these locations differ vastly
from one RRG proposal to another. They range from the distribution
of a full mapping database to all entry points to the network (thus
only reducing the routing table size of internal routers), to keeping
the mapping information at distributed locations and building a
search tree to find individual pieces.
NERD represents one extreme point of the mapping system design by
distributing the full mapping table to all network entry points.
NERD assumes a central database to collect all the mapping
information and updates, from which all the ITRs (ingress tunnel
router) fetch the full mapping table and updates periodically. This
design enables ITRs to encapsulate incoming packets directly to ETRs.
A few other schemes such as IVIP and APT can be viewed as variations
Jen & Zhang Expires April 22, 2010 [Page 3]
Internet-Draft Understand Mapping October 2009
of NERD in terms of mapping information distribution. APT assumes
that a small number of nodes in every AS (collectively) hold the full
mapping table, while ITRs query for mapping entries and cache the
results(which prevents suboptimal paths and overload of the mapping
holders). Although such variations reduce the number of nodes that
hold the full mapping table, all mapping entry changes still must be
pushed out to many nodes.
LISP ALT may be viewed as representing the other extreme point on the
design spectrum. Instead of distributing mapping information out,
ALT builds a hierarchical search tree for non-globally-routable IP
addresses (the "EID space" in LISP terminology), so that each ITR can
find the mapping for a given destination address by walking up and
down the tree. ALT avoids the cost of any nodes holding a full
table, by paying the cost of delay in finding the mapping
information. In addition, because the hierarchical search tree is
shared by all ITRs for all destinations, the tree itself, especially
nodes at the top, can become overloaded. ALT lets ITRs cache the
mapping information to avoid the lookup delay and reduce the load on
the search tree.
3. Mapping for Mobility Support
The basic question for mobility support is how to reach a moving
receiver. Whoever sends packets to a moving receiver must be able to
identify the receiver via a piece of stable information (stable in
the sense that it does not change as the receiver moves). However,
if the sender's knowledge about the receiver does not change while
the receiver moves, some means must exist to bind that unchanging
identifier of the receiver with its dynamically changing location.
Locations in the Internet are represented by IP addresses.
The above leads to the following intuitive observations: mobility
support essentially involves three basic concepts: a stable
identifier for a moving receiver, an IP address of the receiver's
current location, and a mapping in between. Different mobility
support designs are simply different ways of choosing receiver
identifiers and different approaches to providing mappings between
the identifiers and the receivers' current IP addresses.
One example of a mobility support scheme is Mobile IP [RFC3344]. It
uses a home agent IP address as the moving host's identifier. This
address plays a dual role of being both an identifier and also an IP
address to send packets to. MIP requires that a home agent be able
to keep track of the current location of the moving host and to
intercept packets sent to the mobile's home address. Mobility means
potentially constant movement of mobile nodes, hence constant changes
Jen & Zhang Expires April 22, 2010 [Page 4]
Internet-Draft Understand Mapping October 2009
to the mapping between mobile identifers and their current locations.
Individual home agents keep track of dynamic mapping changes for the
mobile nodes under their care. All packets to mobile nodes are sent
to corresponding home agents, thus home agents do not need to
propagate the dynamic mapping changes anywhere. All senders wishing
to communicate with the same mobile node obtains its home agent
address via DNS lookup, and they send data directly to that IP
address. If a single node wants to serve as a home agent for a large
number of mobiles, it will receive all the traffic for all the mobile
nodes.
4. Differences in Mapping Requirements: Mobility Support vs Scalable
Routing
A fundamental difference between the two mapping systems is as
follows. In scalable routing solutions, generally speaking some
information is deliberately removed from nodes to relieve their
routing storage and associated update processing requirements.
Destinations are subtracted from routing tables. Subsequently, nodes
do not know how to route to all IP addresses. Mapping is required to
map the many unroutable destinations to routable addresses for
encapsulation (or translation) and delivery. In mobility support
solutions such as MIP, however, mapping and encapsulation serve an
entirely different purpose. Unlike in scalable routing schemes,
mobility solutions assume that all IP addresses are reachable in the
global Internet (it is up to the routing system to assure that).
Rather, new reachability information is to the tables of home agents
in the form of mappings. Home agents map mobile node identifiers to
their most recent IP addresses. Since mobility is made transparent
to a correspondent, it always sends packets to the mobile node's home
address, the packets are then intercepted by the home agent and
encapsulated to reach the mobile node. The home agent keeps the
mapping information, but does not need to distribute it anywhere,
because all packets going to the mobile are sent to the home subnet
that the home agent sits on. The encapsulation simply preserves the
original packet as sent by the correspondent.
From the observations above, one can see that a number of issues
arise if one tries to add mobility support to the same mapping system
used for routing scalability. Recall that movement leads to mapping
changes. As more and more portable devices are becoming Internet-
capable, the number of mobile nodes will likely grow larger and
larger over time, which would lead to more and more overall mapping
changes (even if the movement frequency of a single node remains
steady). If one tries to push the changes out to all the nodes that
hold full mapping tables as needed in NERD, IVIP, and APT, this
simply does not scale well enough to support networks with large
Jen & Zhang Expires April 22, 2010 [Page 5]
Internet-Draft Understand Mapping October 2009
numbers of mobile nodes and subnets. On the other hand, if one uses
the distributed mapping nodes themselves as "home agent" equivalents,
so that mapping changes can simply be kept at "home agents" without
being propagated anywhere, such as the case in ALT, this also comes
with its own issues. In mobility schemes such as MIP, packets to the
mobile node go directly to the home address and get redirected by the
home agent. However, in the scalable routing context, ITR routers do
not know the ETRs (=home agent) which hold the mapping information;
packets have to walk up and down the search tree to reach ETRs. This
would overload the search tree with packets. This problem is exactly
why caching was introduced into scalability schemes in the first
place. However, caching here conflicts with mobility support. Once
a entry router caches the current address of a mobile nodes, it has
no way to know when the mobile moves again, resulting in stale cache
entries being used for packet forwarding. So far there has been no
good solution to this problem. Using short TTLs for caching simply
lead us back to an overload of the mapping system.
Having each mobile node keep track of its current correspondents and
directly informing them of movement can help with the stale cache
problem for existing communications, but does not help new senders
who rely on ITRs having the correct mapping information to contact
mobiles. Even for the ongoing communication, when both ends are
mobiles and move at the same time, one falls back to the mapping
system to get reconnected again. A fundamental problem with stale
mapping information at ITRs is a failure in packet delivery that end
hosts have no way to get around. Caching is mandatory for mapping in
scalable routing solutions, yet caching makes the mapping system no
longer support mobility very well anymore.
5. Concluding Remarks: Separating Mobility Support from Scalable
Routing
It is very tempting to believe that the same mapping service can
provide both mobility and scalability, since so many mobility and
scalability solutions all involve some type of mapping. However,
attempts to inject mobility mappings into the scalability mapping
system have revealed that the two do not fit together very well. We
hope this draft clarifies the reasons that mobility mappings and
scalability mappings do not mix. It is still very possible that a
mobility solution can co-exist with a scalability solution, but one
must be careful not to try to bundle both solutions into one mapping
system.
Jen & Zhang Expires April 22, 2010 [Page 6]
Internet-Draft Understand Mapping October 2009
6. References
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, 1996.
Authors' Addresses
Dan Jen
UCLA
4805 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Email: jenster@cs.ucla.edu
Lixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Email: lixia@cs.ucla.edu
Jen & Zhang Expires April 22, 2010 [Page 7]