<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-halpern-rrg-taxonomy-01.txt" 
    ipr="full3978">
<front>
<title abbrev="Design Taxonomy">A Taxonomy for New Routing and
Addressing Architecture Designs</title>
<author fullname="Joel M. Halpern" initials="J." role="editor" 
    surname="Halpern">
<organization></organization>
<address>
        <postal>
          <street>P. O. Box 6049</street>
          <city>Leesburg</city>
          <region>VA</region>
          <code>20178</code>
          <country>US</country>
        </postal>
<email>jmh@joelhalpern.com</email>
</address>
</author>
<date month="July" year="2008" />
<workgroup>Internet Research Task Force</workgroup>
<keyword>routing</keyword>

    <abstract>
      <t>The Routing Research Group is tasked to design a new routing
	architecture to meet the challenges of scalability in face of
	pervasive multi-homing and inter-domain traffic engineering. A
	number of solutions have been proposed. This draft describes a
	taxonomy for the design space.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Routing Research Group is tasked to recommend a new routing
	architecture to meet the challenges of scalability,
	multi-homing, and inter-domain traffic engineering. With the
	approaching exhaustion of IPv4 address space, the discussion and
	some initial deployment of IPv6 has moved from the back burner
	to the front stage. However, one of the major issues
	concerning IPv6 deployment is its potential impact on
	scalability of the already stressed routing system.
      </t>

      <t>A number of approaches to scaling the Internet's routing
	system have been submitted. We expect this taxonomy to
	facilitate discussion of both existing and future
	proposals, to position each proposal in the design space, and
	to help evaluation of various design trade-offs in all the
	proposals.  In addition, in order to facilitate both this
analysis and research group discussion, this document proposes a set
of terminology and meanings for those terms.  While this document
attempts to avoid redefining existing terms, the discussion space is
very crowded, and many terms are already quite overloaded with meanings.
      </t>

<t>
It would be desirable to be able to decompose the solution space
being explored into a set of orthogonal dimensions, each of which
could be further decomposed.  And that is the structure this document
attempts to overlay on the space.  However, the dimensions are not
actually orthogonal, and the choices are not independent.  For
example, the question of where certain kinds of lookups are done is
not completely independent of the question of what kinds of lookups
are needed.  
</t>

<t>
Following this introduction, the document has a section on
terminology, providing at least the terms as they are used here, and
one hopes also providing terms for more general discussion.  Following
that are a series of sections discussing separate dimensions along
which to understand potential solutions to the problems under
discussion.  These are not evaluation criteria, but rather ways in
which solutions may differ.  The main portion of the document ends
with a discussion of open issues.
</t>
    </section> <!-- end of section "Introduction" -->

    <section title="Terminology">
<t>
Core Aggregatable Address -- An address that can be used by
routing and which can be included in a collective
(i.e. aggregated) advertisement when used in Internet core routing.
For this purpose, core is an approximate term which can be thought of
as the current default free zone in BGP.  Core Aggregatable Addresses
are currently globally unique, although some proposals remove that
property.  (Some proposals treat the core as just another region.
There are also proposals where the core does not need to be
aggregatable.  Better terminology is still sought.) 
</t>
<t>
Scoped Address -- An address that can be used by routing within some
meaningful scope.  For most purposes, this scope is distinct from the
core of the global Internet, although as mentioned under Core
Aggregatable Address, some proposal treat the core as just another
scope.  It is of course the case that a locally scoped address, even 
one with a very small routability scope, may be globally unique.
</t>
<t>
[Editorial Digression: It is understood that even terms such as the
above two are actually
quite fuzzy.  For example, in a hypothetical environment where IPv6 is
widely deployed, a globally unique ISP allocated IPv6 address is a
Core Aggregatable address.  If that same
IPv6 addresses are used only for routing within a site, then they are
Scoped Addresses.  And in a more likely environment where for a long
time IPv6 routing makes extensive use of tunnels, but has service
providers that route IPv6 addresses and behave like an Internet Core,
it is not clear which term would be appropriate to describe an IPv6
address used to direct delivery of a packet.]
</t>
<t>Communicating Entity Identifier -- A bit string used to identify an
entity participating in the Internet.  In the traditional IPv4 and
IPv6 Internet, the IP address is used as both the address for the
packet forwarding system, and the Communicating Entity Identifier.
There is an additional important distinction in the intended use of
this term, as compared with current IP addressing.  IP addresses name
interfaces.  When communicating with a host, to the degree that the
address is used to identify the communicating entity, it also
constrains the physical interface over which that communication takes
places.  Thus, it is frequently said that an IP address names an
interface.   Communicating Entity Identifier names the communicating
entity, not just a specific interface of the entity.
</t>
<t>
Pure Entity Identifier -- A string (typically, but not always binary)
used to identify an entity participating in the Internet in a way that
is completely insensitive to the connectivity of that entity to the
Internet.  Note that some routing systems may use such strings for
packet forwarding.  The determination of whether it is a Pure Entity
Identifier is not related to how other systems track or map the
identifier.  This terms is introduced largely to distinguish from
a Scoped Identifier.  It is also introduced to avoid the free standing
term Identifier since, like Address, the term has been used by
different folks to mean different things.
</t>
<t>
Scoped Entity Identifier -- A string (typically but not always binary) used
to identify an entity participating in the Internet.  A Scoped
Identifier is assigned by a connected region of the Internet, and
typically must change if the entity leaves that scope.  A scoped
identifier may or may not change when the entity moves or the Internet
connectivity changes within the scope that has assigned the
identifier.
</t>
<t>
It should be noted that whether an identifier is Scoped or Pure is a
property of the assignment / definition process of the identifier as
defined by the system.  So a Pure Entity Identifier may be used by
routing / packet forwarding in some scope as an address.  It may well
be in fact a scoped address for forwarding purposes.  But if the
definition of the bit string is such that it does not change when the
entity is moved to a different scope on the Internet, then the
identifier is a Pure Entity Identifier.  Similarly, if the system
defines a Communicating Entity Identifier as being assigned by the
scope, then it is a Scoped Entity Identifier even if the system
permits (and some scopes choose) the use of globally unique arbitrary
bits strings as identifiers, since when the Entity moves it has to get
an identifier appropriate to the scope it moves into.
</t>
<t>
Routing Locator -- the bit string used by the routing system in the
Internet core to deliver a packet across that core.  In most of the
proposals under discussion, this is a Core Aggregatable Address.  In
some approaches that have been suggested in the past, this may not be
aggregatable, or may be a flow identifier, or even something more
exotic.
</t>
    </section> <!-- end of section "Terminology" -->

    <section title="New Math or New Naming">
<t>
One question that can be asked about a proposal is how much change
does it make to the basics of routing as it is practiced today. The
choices conceptually range from leaving the system alone through
choices such as Nimrod, or alternatively through geographic or AS
based ideas, and then to ideas that take a very different mathematical
approach to the routing and forwarding system.
</t>
<t>
Most
of the proposals under discussion in the Routing Research Group take
as a premise that the ISP based routing system can (may not have to,
but is permitted to) remain operating the way it is today.  This can
be viewed as being based on a conclusion that the current approach is
good enough, or on a view that deployability requires leaving some
parts of the system fixed, or likely other motivations.  These
proposals generally rely on splitting the packet destination naming
problem (and, of course, source naming) into two parts.  One part,
often called the identifier space, is used to anchor the communication
session.  The other part is some form of address that is used to
actually deliver the packets.  By stretching the notion of mapping (to
allow for a wide range of places that mapping may occur) we can refer
to all of these solutions as mapping based solutions.  
</t>
<t>
There are some proposals which attempt to address the dynamics and
aggregatability of the routing system by basing it on values, carried
in packets, which have somewhat better behaviors than current IP
addresses.  Such ideas include geographic based addressing and AS
based addressing.
</t>
<t>
There are also theoretical approaches such as compact routing [ed
note, ROLF?] which take a very different approach to routing,
addressing, and packet forwarding.  In theory, these approaches could
have highly scalable table sizes while allowing arbitrary bit strings
as the names used in packets for destinations.
</t>
    </section> <!-- end of section "New Math or New Naming" -->

    <section title="Divide and Conquer">
<t>
As was discussed above, most of the solution under discussion attempt
to address the systemic routing problems by a divide and conquer
approach focused on splitting communication entity identification
from the bit strings that are used to forward packets.  These
forwarding bit strings are called Routing Locators, or RLOCs, in one
of the proposals on the table, and that seems a clear term for that
function. 
</t>
<t>
Looking at the string used for identifying communicating entities,
there seem to be four sorts of approaches to this.
	<list style="symbols">
        <t>Identification by name;</t>
	<t>Identification by globally unique location insensitive bit
string;</t> 
	<t>Identification by globally unique location sensitive bit
string;</t>
	<t>Identification by purely local identifiers;</t>
	</list>
</t>
<t>
Of these, the first would be exemplified by using a DNS name as an
identifier.  Such approaches tend to avoid shipping the identifier in
most packets.  For example, the DNS name or a string derived from it
might be shipped in the first application / transport packet, to
create end-to-end state, and only shipped thereafter in packets that
modify that state.  
</t>
<t>
The second category of splitting is exemplified by solutions such as
GSE, where entities are identified by globally unique bit strings.
These IDs are what the terminology section of this document calls Pure
Entity Identifiers.
</t>
<t>
The third category is similar to the second.  It differs in that the
bit string used for communicating entity identification is assigned
by a connected region of the Internet (typically a site.)  This
simplifies the process of assigning identifiers within the region,
since the regional authority can perform the assignment.  To some
degree, it also simplifies the potential optimization of using the
communication identifier for local packet delivery.
</t>
<t>
The fourth category basically treats the Internet as a collection of
regions, with completely different naming in each region.   An example
of such an approach would be a system which required a description of
the path from the source communication domain to the destination
communication domain in order to establish communication.  The author
does not believe any such approaches are under discussion in the
research group, but it is included here to try to help complete the
taxonomy.
</t>
	<section title="What Mappings?">
<t>
In order to utilize these various forms of splitting of the problem,
it is necessary for some devices to be able to determine the correct
bit strings to use.  There are several mappings which may apply.  Not
all of these mappings are needed by all of the solutions:
	<list style="symbols">
	<t>Mapping from the application handle (e.g. DNS name) to a
communication entity identifier;</t>
	<t>Mapping from the application handle (e.g. DNS name) to a
routing locator;</t>
	<t>Mapping from a communication entity identifier to an
RLOC;</t>
	<t>Mapping from an RLOC to a communicating entity
identifier;</t>
	</list>
In fact, some of these mappings are not merely unnecessary, but are
meaningless for some of the solutions under discussion.
</t>
	</section> <!-- end of section "What Mappings?">

        <section title="Where Mapping?">
<t>
Mapping based systems require a mapping function to determine a Core
Aggregatable Address from a destination Communication Entity
Identifier.  This functionality can be delivered in a number of
different locations.  Some solutions require a specific location for
the function, others allow a range of placement.  Most solutions that
do not require a specific placement also do not require consistency in
placement as long as the behavior can ensure that the mapping takes
place.
For this description, the mapping function is considered to be the
process of starting from the identification, and resolving to a Core
Aggregatable Address in the packet.  The placement for this purpose is
the place where the packet modification takes place.
</t>
<t>
Host placement is one obvious alternative.  This placement can
frequently leverage the fact that a host knows when it is establishing
communication, and is often prepared to deal with a slight delay for
mapping as it will be unnoticed when properly combined with other host
functions.
</t>
<t>
Outside of the host, there are three common placements that are
discussed in solutions.  The mapping could be provided by the customer
edge routing device.  This places the function under control of the
site, who is using it.  And allows a small number of places to apply
policy and to deliver functionality to and for the site.  Similarly,
the mapping could be placed in a provider edge router, facing the
customer.  This enables the provider to offer the capabilities as a
service to the customer, and to leverage the deployment of such
devices to enable the scaling of the mapping function.  Finally, with
suitable traffic engineering one could use dedicated devices in an ISP
to provide this function to a range of customers.  This is
particularly useful for early deployments as it avoids having to
upgrade the edge equipment to offer capabilities to customers.  
</t>
<t>
It is actually possible of course to extend these placements, and have
an ISP who offers this mapping service to customer ISP, placing the
function either on a central box or at the edge facing the customer
ISPs.
</t>
        </section> <!-- end of section "Where Mapping?" -->

        <section title="How Mapping? or Map Distribution?">
<t>
In the above description, we focused on the placement of the function
to update the information in a packet.  A closely related question is
how enough information is made available to perform this operation.
As discussed below, some solution approaches are designed to avoid
needing this operation since it can be a source of complexity.
There are two basic approaches to such distribution, and several
hybrids.
</t>
<t>
One approach which has significant simplicity is a pure full push
solution.  Simply distribute the entire table of mappings to all the
places that could possibly need it.  This means that whenever
information is needed, it is available.  Conversely, this may need to
distribute a lot of information to a lot of places, which introduces
scale questions that must be resolved if this kind of approach is to
be adopted.
</t>
<t>
The pure alternative to that approach is have each piece of
information stored in a distributed database, and anyone who needs a
mapping consults the database to get the needed information.  DNS is a
classic example of such a database.  LISP-CONS proposes such a
database, with information distribution for the purpose of steering
the information extraction.  This family of solutions are often called
pull based solutions, as devices only get the information when they
need it.  Even the purest pull solution actually makes use of caching
to reduce the need to request the same information repeatedly.  One
question with pull based approaches is what latency penalty is
incurred to allow the pull to occur.  Clearly, when a lookup is
needed, traversing such a system takes some noticeable amount of
time.  Conversely,  this lookup is only needed when the first packet
for a destination identifier is being handled by a mapper.  Subsequent
packets, within a reasonable time period, even from distinct sources,
will get the benefit of the caching to get effective mapping.  Making
it more likely that one will get this sort of cache hit is one of the
drivers for using scoped identifiers.  If someone needs to communicate
with a host in a site, it is frequently likely that communication will
occur with other hosts in the same site.
</t>
<t>
It is also practical to use a range of hybrid solutions.  Approaches
like APT and Ivip use a push based solution to deliver the full
information to a subset of all devices, such that every device that
needs to perform the mapping has and knows of a nearby device that has
the information.  This kind of hybrid reduces the scale of the
information distribution, while keeping the latency for the mapping
function significantly smaller than a pure pull would be likely to
need.  The question of how much gain this provides depends upon the
likelihood of cache hits and misses in the actual edge device, as
discussed above.
</t>
        </section> <!-- end of section
            "How Mapping? or Map Distribution?" -->
    </section> <!-- end of section "Divide and Conquer" -->

    <section title="Tunneling, Rewriting, or Separate Identification">
<t>
In order to ensure that the routing system scales and stabilizes
better, without utilizing new mathematical approaches to that system,
the solutions under discussion all try to ensure that the address as
seen by the routing system in the core of the network is a core
aggregatable address.  This enables the routing system to utilize the
aggregation properties it was designed for in an effective manner.
There are a range of ways that this is achieved in different
proposals. 
</t>
    <section title="Tunneling">
<t>
One common approach is tunneling.  This involves taking the existing
packet with the existing information (which appears as addressing
information to the packet forwarding system) and modifying the packet
by adding new destination (and usually source) addressing information,
while preserving the original information.
</t>
<t>
One aspect of tunnels and tunneling or encapsulation is the question
of whether the two ends of the tunnels have shared state.  In many
VPN solutions that use tunnels, the two ends of explicit shared state
to enable cryptographic protections of various kinds.  On the other
hand, in some tunneling mechanisms used with IPv6 overlays, there is
no need for such shared state.  Either there is no need for shared
information, or anything needed is carried in the packet.  It has been
suggested that if a tunnel is not using shared state than it is just
encapsulation, and should be called encapsulation.  The tunneling
solutions under consideration for routing scaling all avoid pairwise shared
state for the tunnels, as that helps many aspects of the solution.  It
is for further discussion whether these approaches should be referred
to as encapsulation-based approaches rather than tunneling
approaches.  In this document, the two terms are used interchangeably,
according to which term fits the specific context better.
</t>
<t>
The most common mechanism
for this is to add a new IP header, and possibly an intermediate
informational header.  The intermediate header allows for additional
information which can affect the far end behavior.  The use of an
encapsulating IP header also allows for a different outer header
version and inner header version, increasing the versatility of this approach.
</t>
<t>
Other alternative tunneling mechanisms have been suggested, such as
using a new IP option field to carry the old header information.  
There are three properties that appear relevant for the taxonomy that
distinguish tunneling from other approaches.
	<list style="symbols">
	<t>The technique is applied to all data packets.  Additional
techniques may be used, but this strategy centers on using tunneling
for almost all data packets.  [Editors note: If tunneling is done such that
intra-site packets are not tunneled, we still consider this to
apply.  Possibly the description should say "all inter-site packets?"
But that seems too specific.]</t>
	<t>The technique makes the data packets larger</t>
	<t>The technique preserves the original addressing
information.  This is generally used so that the communicating
entities see the same addresses or identifiers.  Some tunneling
systems introduce an exception to this property for backwards
compatibility.</t>
	</list>
Tunneling generally requires that the device performing the
encapsulation be able to perform the mapping from the identifier to
the Core Aggregatable Address to be used in the outer, encapsulating,
header. Tunneling can be used in conjunction with any of the described
placements of the mapping logic, including in the host, as long as the
mapping device is performing the encapsulation.  Tunneling can be used
with any version of IP, or even mixed versions.
</t>
    </section> <!-- end of section Tunneling -->

    <section title="Rewriting">
<t>
Tunneling is not the only strategy to ensure that the packet carries
Core Aggregatable Addressing information when it is used in the
Internet core.  Another strategy which still relies on mapping between
identifiers and Core Aggregataeble Addresses is to rewrite the
addressing in place.
</t>
<t>
At its simplest, this would seem to be a description of NAT.  While
NAT tends to reverse this (rewriting source address on entry to the
Internet core and rewriting destination address on exit from the
Internet core) it does match that description.  And NAT with its many
problems is not going to solve the issues at hand.  
</t>
<t>
However, if the identifying information can be preserved through the
NAT, without encapsulation, something effective can be achieved.  An
example of this is the use of IPv6, where some or all of the upper 8
bytes of the IPv6 address field are rewritten, based on identification
information carried in the lower 8 bytes.  This has the property that
the size of the packet is not affected by the process.
</t>
<t>
Like Tunneling, rewriting approaches can be used with any placement of
the mapping function.  When used with mapping in the host, it may be
difficult to distinguish between this sort of approach and a Separate
Identification approach, except in terms of the semantic description.
To date, this sort of rewriting is only envisioned for use with IPv6.
</t>
    </section> <!-- end of section "Rewriting" -->

    <section title="Separate Identification">
<t>
For systems designed to be deployed in hosts, there is another class
of approach.  This approach separates out the mapping, and sometimes
even eliminates it entirely.  The first distinguishing property of
these approaches is that most of the data packets do not carry
identifiers on the wire, even in their originating or destination
scopes.  Instead, the packets carry suitable Core Aggregatable
Addresses.
</t>
<t>
The oversimplified form of this solution family would be to simply
declare, as IPv6 initially attempted, that all IP addresses used in
packets shall be Core Aggregatable.  And to stop there as if that
solved the problem.  That is clearly insufficient.
</t>
<t>
Other approaches rely on establishing paired state in the
communicating entities
so as to enable multiple Core Aggregatable Addresses to be used on
individual data packets.  Suitable updating packets are used to allow
for changes in the set, and provide suitable security.  Some of these
solutions use an explicit identifier, while others use the first Core
Aggregatable Address used as the hook for anchoring a given
communication.  It has also been suggested to use the original DNS
name as the identifier, carrying a reference to it in certain packets
where necessary.  This does assume that all hosts get DNS names.
Hybrid approaches where packets carry extra connection information,
but not necessarily full identification in additional headers, driven
from the host, make the boundary between these approaches and
tunneling more difficult to determine.  One complication with these
approaches is ensuring that they can work with TCP, SCTP, UDP, and
DCCP, as it is not the routing systems job to determine what transport
protocol the applications utilize.
</t>
<t>
One advantage of this sort of Separate Identification is that by
leveraging extant host information gathering (DNS lookups, for
example) or by using existing information as the communications
anchor, the system can avoid the need for custom distribution
techniques to handle the mapping information.
</t>
<t>
To avoid confusion, there is one other kind of separate identification
that should be mentioned, as it is intended that the above candidates
NOT be so broad as to include solutions that require state
establishment in the network.  For example, a solution which
established MPLS LSPs from each source to each destination host would
clearly be establishing network state.  Even solutions which required
the communication initiator to establish and maintain state in remote
edge devices should probably be considered part of some other space of
active state maintenance solutions.  Requirements to ensure state in
ones own border devices, in order to meet communications control
requirements, may well fit within the category of Separate
Identification.
</t>
<t>
Typically, Separate Identification techniques expect (some may not
require) a degree of visibility into the routing connectivity.  This
may be provided purely be a set of prefix announcements.  It may be
augmented by observations and probes of traffic behavior.  It may also
make use of suggested protocols to allow the routing system to provide
state and policy hints to the hosts to assist the host processing.
</t>
    </section> <!-- end of section "Separate Identification" -->

</section> <!-- end of section
        "Tunneling, Rewriting, or Separate Identification" -->

    <section title="Scoping">
<t>
One of the aspects that makes discussion of these solutions
complicated is the uses of scoping.  There are two separate but
related notions.
</t>
<t>
Address Scoping is the scoping of address information as used for packet
forwarding (i.e. traditional routing.)  Routing has always tried to
keep local information about reachability local, so as to ensure
aggregatability.  Success in this endeavor has varied.  The approaches
discussed here aim to ensure that addresses used in the global or Core
Internet scope are highly aggregatable.  In conjunction with that,
many of the solutions discussed here use different addresses for
delivery of packets within a site.  These addresses are usually
globally unique, but are not usable for packet forwarding outside of a
site.  Frequently, this involves using the Communicating Entity
Identifier as the address for local delivery.  While one could use
other addresses, such solutions would likely incur additional mapping
for little additional value and have not been explored to date.
</t>
<t>
Separately, there is the question of the scope of the identifiers used
for the communicating entities.  The scope of a Communicating Entity
Identifier is the scope (or range of places in or attached to the
Internet) where the entity can use that identifier.  Some solutions,
such as GSE, HIP, or Ivip, use identifiers that can be used anywhere
in the Internet.  The identifiers does not change, even if the entity
moves.  Other solution use identifiers which are tied
to an administrative or routing scope.  This allows the routing system
to somewhat more easily identify its local entities, and to forward
packets using the identifier to those local entities.  It also tends
to mean that entities which share core Internet reachability will be
in an aggregatable block of identifiers, potentially making caching of
mapping information more effective.
</t>
    </section> <!-- end of section "Scoping" -->

    <section title="Version Requirements">
<t>Different approaches under consideration make different assumptions
about what versions of the undcerlying communciations protocols are in
use by hosts, sites, and the Internet Core.  This conceptually
includes both the quesiton of IPv4 versus IPv6 and the question of
other kinds of modificaitons to host stacks or various routers.  Some
of this comes up in terms of the earlier discussion of where functions
are placed.  It is probably the case that in a pure architectural
sense it would be better if these considerations were kept out of a
taxonomky of the architectural work.   But as the topics come up
repeatedly, and seem to affect the view of solutions very strongly, it
is mentioned here.
</t>
<t>Some of the proposals under
consideration are designed to apply to almost any underlying Internet
Protocol.  In particular, there is a large class of interesting
proposals (mostly in the mapping and encapsulation family) which work
equally well for IPv4 and IPv6.
</t>
<t>Some of the solutions under discussion assume that at least some
portions of the infrastructure are using IPv6.  Those solutions make
use of the larger address size from IPv6 to enable modes of operation
that can not be fit into an existing IPv4 address.  Obviously, and
such solution must deal with the reality that communication with and
over the existing IPv4 network is an essential practical requirement.
</t>
<t>As mentioned, while most solutions assume that the current version
of host software can be used, some itneresting proposals require some
degree of host modification.  For example, proposals which move the
identification of communicating parties to or above the transport
protocol obvious will require new versions of host software.
</t>
    </section> <!-- end of section "Version Requirements -->

    <section title="Mobility">
<t>
One issue that comes up is whether the improvements to the routing
system can or should help deal with mobile devices or mobile
networks.  There is an argument that given that mobility will become
more important, and more widespread, it is important to address
mobility in the core design of the routing system.  Conversely, given
that mobility occurs over a range of time a topology scales, with a
range of needs, there is an argument that it should be addressed by a
range of techniques (potentially including locally mobility
management, hierarchical mobility management, and a variety of
tunneling and VPN tools.)
</t>
<t>
It does seem that some of the solutions under discussion offer tools
that can help the mobility situation.  If globally scoped identifiers
are used for communicating entities, those identifiers can serve as a
reference to be used by mobility solutions.  For mobile networks,
potentially including  mapping information aggregator in the set of
things that move may allow more effective global reachability
information, depending upon the approaches.  In general, to date, the
routing research group has viewed benefits to mobility as a nice
result, but not a driver in the architectural process.
</t>
    </section> <!-- end section :Mobility" -->

    <section title="Acknowledgments">
<t>
This draft owes significant debt to the earlier draft done by Lixia
Zhang and Scott Brim <xref target="ZBTaxonomy"/> that began to address
this question. 
</t>
    </section> <!-- end of section "Acknowledgments" -->
  </middle>

<back>
<references title="Normative References">
</references>

<references title="Informative References">
<reference anchor="ZBTaxonomy">
<front>
<title>
A Taxonomy for New Routing and Addressing Architecture Designs
</title>
<author initials="L." surname="Zhang"></author>
<author initials="S." surname="Brim"></author>
<date month="March" year="2008"/>
</front>
<seriesInfo name="work in" value="progress"/>
<seriesInfo name="" value="draft-rrg-taxonomy-00.txt"/>
</reference>
</references>
</back>

</rfc>