[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Research Task Force                               L. Zhang, Ed.
Internet-Draft                                              S. Brim, Ed.
Intended status: Informational                            March 29, 2008
Expires: September 30, 2008


     A Taxonomy for New Routing and Addressing Architecture Designs
                       draft-rrg-taxonomy-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 30, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   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, and then uses the taxonomy to discuss
   and compare the proposed solutions.





Zhang & Brim           Expires September 30, 2008               [Page 1]


Internet-Draft               Design Taxonomy                  March 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Solution Directions  . . . . . . . . . . . . . . . . . . .  3
   3.  A functional model . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Where to Place the Split Between TAA and TIA . . . . . . . . .  6
     4.1.  Mapping Inside the Host  . . . . . . . . . . . . . . . . .  6
     4.2.  Mapping Point at Network Administrative Boundary . . . . .  7
     4.3.  Mapping Point at Prefix Aggregation Places . . . . . . . .  8
     4.4.  Granularity of Node and Common Issues  . . . . . . . . . .  8
   5.  Where to Put in Mapping: Two Basic Choices . . . . . . . . . .  8
   6.  Design Space of A New Mapping System . . . . . . . . . . . . .  9
     6.1.  Elements in Mapping Information Distribution/Discovery . .  9
     6.2.  Mapping Information Distribution: Push versus Pull . . . . 10
     6.3.  The Mapping Information Distribution Channel . . . . . . . 12
     6.4.  The Selection Decision among Multiple TAAs . . . . . . . . 12
   7.  Failure Handling in the Presence of Mapping  . . . . . . . . . 13
     7.1.  Failure Detection and Handling . . . . . . . . . . . . . . 13
     7.2.  Data Handling During Transient State . . . . . . . . . . . 14
     7.3.  Failures in Mapping System . . . . . . . . . . . . . . . . 14
   8.  Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

























Zhang & Brim           Expires September 30, 2008               [Page 2]


Internet-Draft               Design Taxonomy                  March 2008


1.  Introduction

   The Routing Research Group is tasked to design a new routing
   architecture to meet the challenges of scalability, multi-homing, and
   inter-domain traffic engineering.  With the imminent 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.

   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 tradeoffs in
   all the proposals.

   We identify dimensions of the design space by first identifying
   various different approaches from all the proposed solutions.  We
   then extract out common techniques to sketch out the solution space.
   To test whether we get the solution space right, we try to position
   the proposals in the design space, and this step helps identify
   missing issues.  As one can see this approach to taxonomy development
   is an iterative process.  We expect that this document will continue
   to be updated as our understanding of the solution space progresses.
   We also hope that it can serve as input to the final decisions by the
   Routing Research Group.

   This draft is organized into the following parts:

   o  Identify the solution directions;

   o  Identify a common functional model;

   o  Identify the dimensions of the design space;

   o  Identify the open issues; and

   o  Identify the tradeoffs in each of the approaches to resolving the
      open issues.


2.  The Solution Directions

   The fundamental goal of a scalable routing system design is to be
   able to support continued growth in the number of Internet users and
   flexibility in how they use the Internet.  One way to control routing
   system scalability in face of rapid growth is to enforce
   topologically aggregatable IP address assignment.  However, Internet



Zhang & Brim           Expires September 30, 2008               [Page 3]


Internet-Draft               Design Taxonomy                  March 2008


   users desire topology-independent (TI) prefixes to ease changing
   providers and to avoid renumbering.  The common practices of
   multihoming and traffic engineering also lead to prefix de-
   aggregation.

   Two basic directions have been proposed to solve this routing table
   scalability problem: either

   o  Find ways to handle the large and ever growing routing tables, or

   o  Route on topologically aggregatable addresses only.

   Several publications from academic research fall into the first
   category (add ref: ROLF, compact routing).  This class of solution
   models the Internet as a large, flat network, where any node may
   forward traffic for any other nodes.  Based on this model, one can
   determine the next hop for packet forwarding by applying distributed
   hashing algorithms instead of maintaining a routing table.  However,
   because the operational Internet is an interconnect of multiple
   networks under different administrations, routing policy plays an
   essential role in making the routing decisions.  It is not the case
   that any node would be willing to forward traffic for any other
   nodes, since traffic across AS boundaries means money changing hands.
   Furthermore, individual ASes are also unwilling to expose their
   internal topological connectivity to other domains as input to the
   hash algorithms.

   The proposals that have been made to the IETF/IRTF so far all fall
   into the second category, i.e., scaling the routing system by only
   providing routing for topologically aggregatable addresses (TAAs).
   However, as we mentioned earlier, Internet users desire topology-
   independent addresses (TIAs).  To both scale the routing system and
   satisfy user desires at the same time, there needs to be a point
   where use of a TAA ends and use of a TIA starts.  One important
   design decision is where to engineer this split between TAAs and
   TIAs.  Furthermore, one must also develop a mapping system to bridge
   the two.

   There is also another class of approaches aiming at only providing
   routing for topologically aggregatable addresses (TAAs): simply
   surpress fine granularity prefixes and inject only aggregated
   prefixes into the global routing.  IVIP and CRIO may be considered as
   example designs in this category.  These approaches require that the
   aggregation points be able to forward packets towards their real
   destinations (and tunneling can be one means to serve that purpose).
   One may view this class of aproaches as an intermediate point between
   today's routing systema and the approach described in the previous
   paragraph (separation and mapping between TAA and TIAs), but with the



Zhang & Brim           Expires September 30, 2008               [Page 4]


Internet-Draft               Design Taxonomy                  March 2008


   split being placed at the points where prefix aggregations occur,
   rather than at the user network administrative boundaries.

   In the rest of this draft, we focus on developing a framework to
   describe the choices of where to engineer the split, together with
   the design space for the mapping system.


3.  A functional model

   To make the discussion more concise, we first define terminology.  As
   we already mentioned, we call the part of the IP address space that
   is topologically aggregatable "TAA Space" and the associated prefixes
   TA Prefixes.  The (non-aggregatable) topology-independent addresses,
   which by design will not be covered in global routing, are called TI
   Addresses and TI Prefixes.  This terminology is chosen to avoid
   confusion.

      TI addresses/prefixes have also been called EIDs, in the sense
      that they IDentify Edge networks.  However in a different context,
      such as the work by HIP Research Group and Working Group, EID is
      used to refer to End host IDentifiers.  In this draft we will use
      TIAs and not EIDs.

   Here we sketch out an overall picture of a scalable routing system
   design.  Global routing runs over TA space, the Internet users by and
   large operate in TI space, and a mapping function bridges the two.
   In addition, there is a mapping information distribution mechanism in
   one form or another.

   Theoretically speaking, there are multiple places to make the TIA-TAA
   split, and multiple ways to provide the mapping information between
   the two.  In the solutions proposed to RRG so far, the predominant
   choices for the split point are either within the endpoint or at a
   network administrative boundary.  A closely related issue is points
   to which mapping information may be distributed.  So far the choices
   are usually either to inform the host, or to hide the mapping
   information from entire networks in TI space.  These are the subjects
   of the next two sections.

   Stepping up a level, this split between TAA and TIA makes a subtle
   change to the failure modes of the routing system.  In today's
   Internet, site multihoming is a common practice.  BGP performs flat
   routing at the inter-domain level, and dynamic routing picks one of
   the working links to reach a multihomed site.  In the presence of
   mapping, however, the selection of entry point to a multihomed site
   is done at the mapping point, be it in the source host or at source
   network border.  Therefore the system must be able to adjust to



Zhang & Brim           Expires September 30, 2008               [Page 5]


Internet-Draft               Design Taxonomy                  March 2008


   failures (and recoveries) of the current mapping selection.  We
   discuss the design choices for failure handling in Section X
   [reference].

   The addition of a mapping system also introduces at least one new
   target for malicious attacks.  In today's Internet, one can hijack
   data traffic by compromising the routing system.  With the new
   design, one might be able to hijack traffic by injecting false
   information into the mapping system.  One could also attempt to
   damage the mapping system by a DoS attack on one of its elements.  We
   discuss security considerations in Section XX [reference].


4.  Where to Place the Split Between TAA and TIA

   There is a close coupling between how the mapping is done and where
   the mapping is done.  Since end hosts perform DNS resolution before
   sending packets in general, a DNS-based mapping solution allows one
   to set the mapping point anywhere from inside the end host to all the
   way to the attachment point of an edge network.  Proposals that use a
   new mapping system tend to place the mapping point at network
   administrative boundaries.

4.1.  Mapping Inside the Host

   SHIM6 is a design that uses DNS to provide mapping information.  It
   places the boundary between TA and TI inside an endpoint stack, at
   the border between IP and transport layer.  A multihomed site will
   have multiple prefixes assigned to it by its providers, and SHIM6
   assigns multiple IP addressees to each internal node (add SHIM6
   refs).

   SHIM6 lets individual hosts select one destination prefix among
   multiple choices, which potentially influences the path taken by the
   packets.  This design aspect raised concerns from network operators
   and ISPs regarding their ability to perform traffic engineering, an
   important part of routing policy support.

   Variations of the basic SHIM6 design have been developed to address
   SHIM6's limitations.  One of them is SHIM6 proxy, which addresses the
   concern of having to change all the hosts.  Another variation of
   SHIM6 is Six/One, which addresses the traffic engineering concern.
   In Six/One, end hosts perform SHIM6, but routers at the network edge
   may rewrite the IP addresses to meet TE goals.  Although this hybrid
   solution can be used to support TE, it also introduces complexity due
   to the need for coordination between end hosts and the address
   rewriting routers.




Zhang & Brim           Expires September 30, 2008               [Page 6]


Internet-Draft               Design Taxonomy                  March 2008


   Another design that puts the split inside the host is a proposal from
   Mark Handley [reference].  Instead of hiding the multiple TAAs below
   the transport layer as SHIM6 does, the Handley proposal exposes the
   multiple TAAs directly to the transport layer.

4.2.  Mapping Point at Network Administrative Boundary

   GSE is another design that uses DNS to provide mapping information.
   In some sense one may view GSE as putting the split between TAA and
   TIA at the border between an edge network and its provider, although
   GSE does not really provide edge networks with globally unique
   topology-independent addresses.  GSE cuts the IP address into three
   parts, the upper part being a globally routeable prefix (called
   "routing goop", or RG), the middle part representing network topology
   inside a site (called the site topology partition, or STP), and the
   lower part being a globally unique identifier for the host (End
   System Designator, ESD).  The combination of the last two parts also
   makes a site-local address.

                        +-------------------------+
                        |   RG   | STP|    ESD    |
                        +--------+----+-----------+

   GSE shelters all the internal nodes from knowing any of the prefixes
   assigned by their transit providers.  Inside an edge network, all
   communications use site local addresses.  Only packets going outside
   the network will carry a full destination address.  A source host
   obtains the full destination address (including both the upper and
   lower portions) from a DNS lookup.  When the packet exits the source
   network, its border router replaces the site-local prefix of the
   source address with an appropriate transit prefix.  When the packet
   enters the destination network, the border router will keep the
   source address intact so that the receiving host can send reply
   packets to the source, but will replace the upper portion of the
   destination address (the external prefix) with a site-local prefix,
   so that nodes inside an edge network never see their own external
   prefixes.  This eases the change of providers since sites only need
   to obtain new RG and update the DNS.  However for a site with
   multiple topologically diversified locations, the network management
   can become difficult if each site uses the same default site-local
   prefixes.

   Another way to set the TA-TI split at the border between networks was
   first described in Map-n-Encap (RFC1955).  It assumes that border
   routers can obtain or access a mapping database that maps non-
   aggregatable prefixes to their routed TAA attachment points.  The
   border router can then use IP encapsulation to tunnel packets to the
   destination border router.  This approach has the advantages of (1)



Zhang & Brim           Expires September 30, 2008               [Page 7]


Internet-Draft               Design Taxonomy                  March 2008


   making no changes to the existing user networks and their operational
   practices, and (2) eliminating all renumbering induced by changing
   providers.  Several of the newly proposed solutions follow this
   approach, including APT, IVIP, and LISP.

4.3.  Mapping Point at Prefix Aggregation Places

   [Editor's note: this section is yet to be finished.]

   As we discussed in Section 2, one may consider an incremental step
   towards reducing the BGP routing table by simply aggregating fine
   granularity prefixes into shorter prefixes and only injecting the
   aggregated prefixes to the routing system.  This class of solutions
   fall into the same direction as the TAA-TIA split, as the longer
   prefixes being aggregated are essentially equivalent to TI prefixes.
   The challengings in pursuing this direction lie at where to engineer
   the aggregation points, which parties may perform the function, as
   well as how to evaluate the gains and the cost.

4.4.  Granularity of Node and Common Issues

   One may view the different choices of where to place mapping points
   as different points in the same spectrum, based on the granularity of
   the "node" the TAA reaches.  In the first approach, the TAA reaches
   end hosts directly; in the second approach, the TAA reaches an entry
   point to a network containing the end host, and the actual end host
   is reached by using the entry point's TIA.

   Although the above two approaches look rather different, they share a
   set of common issues that arise from site multihoming: choosing a TAA
   to reach the intended destination host (mapping), detecting failures
   of the TAA currently in use, and recovering from the failure while
   minimizing packet losses during failure recovery.  Furthermore, one
   must also secure the mapping distribution channel.  These issues will
   be discussed in Section XYZ (reference).


5.  Where to Put in Mapping: Two Basic Choices

   One way to get the mapping information is to utilize an existing
   look-up system, and DNS makes a readily available candidate.  In
   today's host implementations, almost all the applications perform a
   DNS lookup to get the IP address of their intended destinations.
   Thus one can simply piggyback the TAA to which the destination
   network is attached in a DNS reply.

   Putting the mapping information into DNS is conceptually a very
   simple solution, and has the advantage of avoiding any new design.



Zhang & Brim           Expires September 30, 2008               [Page 8]


Internet-Draft               Design Taxonomy                  March 2008


   Furthermore, letting the end host receiving this information may
   provide flexibility of engineering the TAA-TIA split at various
   different places, as we will see in the next section.

   However this simple solution also raises a few concerns.  The
   foremost is the requirement of making changes to all the end hosts.
   A more subtle issue is the circular dependency between DNS and data
   delivery: DNS assumes the availability of IP packet delivery, but in
   the new design data delivery will require getting the mapping
   information first.

   A second way of providing the mapping function is to develop a new
   mapping system.  To avoid having to make changes to all end hosts,
   all the proposed new mapping system designs put it outside the edge
   networks, so that within an edge network everything can run as today
   with no changes.  However the proposed solutions differ in a number
   of ways., which we will elaborate in later sections.


6.  Design Space of A New Mapping System

   At a high level, different designs can be sorted along the following
   dimensions:

   o  Push versus pull;

   o  A hierarchical system versus a flat distribution system; and

   o  A dedicated distribution system versus laying it on top of the
      existing routing system.

   Different combinations of the above three dimensions cover all the
   proposals currently on the table, although it is not necessarily an
   exhaustive list of all the significant dimensions in the design
   space.  The list will be updated as new important dimensions are
   identified.

6.1.  Elements in Mapping Information Distribution/Discovery

   Mapping information for an end host in a network must be made
   available to all sources which want to send packets to that end host.
   Generally speaking, one can identify the following five logical
   elements in a mapping information distribution design.

   1.  The mapping information for a network (e.g. a mapping for a TI
       prefix to one or more TAAs) is owned by the network's
       administrator, the owner.




Zhang & Brim           Expires September 30, 2008               [Page 9]


Internet-Draft               Design Taxonomy                  March 2008


   2.  There may exist an initial distributor which is distinct from the
       owner/originator of the information, so that owners do not have
       to be directly involved in mapping distribution system
       operations.  In some cases the owner also acts as the initial
       distributor.

   3.  The distribution channel.

   4.  In cases the distribution channel uses a push model, we need an
       entity to hold the information for future use.  This "holder" may
       be the user of the mapping information itself, or a node near the
       users of the information that can supply the information to them
       when they need it.

   5.  The user of the mapping information (when it is a different
       entity from the holder).

   Origination of mapping information (from owner to initial
   distributor) can be manual or automated by a protocol exchange.

      Consideration: how to authenticate each originator of the mapping
      information.

   One important consideration in designing a mapping information
   distribution system is how well it can scale with the number of
   entries.  Mapping information size is likely to grow to at least a
   few orders of magnitude larger than the current BGP table size, e.g.
   hundreds of millions.  Such a big size imposes limitations on the
   frequency of dynamic changes to mapping entries.

   Prompt and reliable mapping information distribution depends on how
   well the above entities -- the owner, initial distributor,
   distribution channel, the holder and the user -- of the mapping
   information can coordinate with each other.  Because the Internet is
   a collection of networks that belong to multiple parties with
   potentially conflicting interests, it is important to minimize the
   dependency between different parties in obtaining mapping
   information.

6.2.  Mapping Information Distribution: Push versus Pull

   Protocol-based distribution of mapping information can be push-based,
   pull-based, or a combination of the two.  Generally speaking, one may
   sort different types of distribution channels based on how far each
   pushes the mapping information from the originator to the user.

   o  The initial distributor may push mapping information to all user
      nodes (perhaps through intermediate steps).  An example of this



Zhang & Brim           Expires September 30, 2008              [Page 10]


Internet-Draft               Design Taxonomy                  March 2008


      approach is NERD [reference], where the originator injects mapping
      information into one or more centralized databases, then entire
      databases are pulled by user nodes to local storage.

   o  At the other end of design spectrum is a pure pull/look up model:
      the initial distributor holds the mapping information, and the
      user nodes or holders pull information when needed.

   o  A design can also take a middle ground, by pushing mapping
      information to some intermediate holder nodes, which can then be
      polled by the user nodes as needed.  An example design of this
      approach is APT, where the distribution channel pushes mapping
      information to Default Mappers (holders) in each AS, and ITRs
      (users) request mapping entries from the default mappers as
      needed.

   Designs based on pushing must include mechanisms to push the mapping
   information out.  The complexity of this step depends on where the
   holders are.  A centralized holder design is illustrated by NERD,
   where individual originators simply submit their mapping information
   to a central database (the holder) using an existing application
   protocol.  A distributed holder design is illustrated by APT, where a
   flooding mechanism is needed for the mapping information to be pushed
   from all originators to default mappers in all ASes.

   An important aspect of designs based on pulling is an indexing
   mechanism.  Because the input to mapping are multiple millions of
   unstructured TI prefixes, pull-based systems require a scalable
   indexing system to direct queries to the distributors with the
   requested mapping information.  Again multiple design choices exist.
   DHTs (dynamic hash tables) use algorithmic hashing to make the lookup
   of a large number of unordered items scalable.  Another design point
   is illustrated by CONS, where the indexing system is a hierarchy of
   TIA prefixes (in a way similar to DNS hierarchy, by replacing DNS
   domains with prefix aggregations).  Yet another design approach is
   ALT which pushes paths to specific mapping information to users.
   Just as there can be holders for pushed mapping information, there
   can also be holders of another kind of index information.

   Whenever a piece of mapping information is pulled to the user node,
   that piece can/may be cached at the user node, and also at some
   intermediate nodes along the pulling path if any such nodes exist.
   Examples of utilizing caching include the LISP and APT designs where
   the mapping information is pulled by ITRs and cached there.  In
   addition, CONS, one of LISP's mapping designs, uses a hierarchical
   structure to retrieve mapping information, thus those nodes along the
   pulling paths can also cache the information.




Zhang & Brim           Expires September 30, 2008              [Page 11]


Internet-Draft               Design Taxonomy                  March 2008


6.3.  The Mapping Information Distribution Channel

   A related, but separate, question is what to use for the distribution
   channel.  There are three distinguishable channel types.

   The first one is to add mapping information to the DNS.  In this
   case, the initial distributors are the authoritative DNS servers, the
   users are source hosts, and the distribution channel is pure pulling
   (DNS queries), thus there is no holder.

   Solutions that push the TAAs all the way to endpoint nodes, such as
   SHIM6 and the Handley proposal, require no changes to the DNS RR
   content.  Among solutions that keep TAAs out of edge networks, GSE
   does not need any major change to DNS because the TAA is the IP
   address, while tunneling-based solutions will need to retrieve from
   DNS the TAA for the destination TIA.  An example of this approach is
   an early version of eFIT (reference), where a DNS reply would carry
   an ETR RR, the source host puts that value in an IP header option
   field, and the ITR could use it to encapsulate the packet to the ETR.

   Another approach is to establish a new and distinct mapping
   distribution system.  This new system can be designed from scratch,
   or it can borrow from the existing DNS framework to various degrees,
   ranging from using a similar hierarchical structure to directly using
   DNS query protocols, even though the system is solely used for
   mapping information retrieval.

   A third approach is to distribute mapping information through the
   routing system.  This approach differs from the second one in that it
   uses routers, as opposed to separate and dedicated entities, to
   distribute mapping information.

6.4.  The Selection Decision among Multiple TAAs

   Another dimension is how a choice is made among multiple TAAs for a
   destination.  The answer to this question depends in part on the
   distribution channel.  Generally speaking, we can identify the
   following three cases.

   1.  If the distribution is pure push, then the user node receives the
       full mapping information, thus it can make its own decision based
       on preferences the originator has injected into the mapping
       system.  An example design using this approach is NERD.

   2.  If the distribution is pure pull, then the originator (the owner
       of the mapping information) can make the decision on whether to
       provide puller-dependent or puller-independent replies to mapping
       queries.  Puller-independent replies can be cached at various



Zhang & Brim           Expires September 30, 2008              [Page 12]


Internet-Draft               Design Taxonomy                  March 2008


       nodes along the pulling path, which can help reduce system
       overhead as well as speed up future pulling replies.  An example
       design using this approach is CONS.  On the other hand, if
       mapping replies are tailored specifically for each request in
       order to support sender-specific policies, they cannot be cached
       in the polling paths.  An example design using this approach is
       ALT.

   3.  If the distribution channel uses a combination of push and pull,
       then the mapping information holder can decide which TAAs shall
       be given to which mapping point.  An example of this approach is
       APT, where mapping information is pushed to all default mappers
       (holders) in each AS, which can then behave like policy
       controllers for the AS to dictate which ITRs use which TAAs.


7.  Failure Handling in the Presence of Mapping

   As explained earlier, a mapping point must be able to adjust the
   mapping selection upon detection of failures.  Failures do not
   invalidate mapping information, but only cause the selection of
   mapping entries to change, perhaps temporarily until the failure is
   recovered.

7.1.  Failure Detection and Handling

   Failure detection is directly coupled with the placement of the
   mapping points.  If the mapping point is inside the host, failure of
   the current mapping selection can be detected by the endpoints, by
   transport or upper layer protocols.  Since the proposed host-based
   solutions use DNS to pull mapping information, each host can also
   make a decision on which alternative mapping value to choose.

      One failure can affect many endpoints.  Putting mapping point
      inside hosts requires that all hosts detect and handle the
      failures independently.

   Those solutions that put the mapping point at a network
   administrative boundary need new mechanisms for detecting failure at
   mapping points.  Possibilities include

   o  data-triggered detection, i.e. packets reach a dead end

   o  routing-triggered detection, i.e. one learns from a routing
      protocol (IGP or BGP) that some TAA or TA prefix becomes
      unreachable.

   Once a failure is detected, one needs to notify affected parties to



Zhang & Brim           Expires September 30, 2008              [Page 13]


Internet-Draft               Design Taxonomy                  March 2008


   avoid the failure.  Design possibilities fall into a multi-
   dimensional space: whether sending separate control packets or
   piggybacking the notification on data packets; whether directly
   notifying involved mapping points (those who are sending to the
   failed demapping point), or notifying holders; and whether notifying
   everyone, or only the affected parties at the time of the failure
   (i.e. those who are actively sending).

   When a failure is remedied, the mapping system may indicate so, so
   that mapping points may revert to using the mappings they were before
   the failure.  Another consideration is which party holds the
   temporary failure information, and how it can be removed when
   recovery is complete.

7.2.  Data Handling During Transient State

   When a failure occurs, there can be in-flight packets heading towards
   a failed demapping point.  Another design consideration is how to
   handle these in-flight packets.

7.3.  Failures in Mapping System

   A mapping system design must consider various possible failures in
   the mapping system itself, and understand how robust the system can
   be in face of the failures.


8.  Security

   This section is unfinished.  Here are some considerations.

   o  What is the trust model/relationship between neighbor nodes in the
      mapping distribution chain?

   o  How to ensure and verify mapping information authenticity?

   o  How possible is it that data packets will be mis-delivered.

   o  How possible is it that control (mapping, signaling) packets will
      be mis-delivered

   o  Vulnerability to a flood of data packets.

   o  Vulnerability to a flood of control packets.

   o  Vulnerability of control to MITM attacks.





Zhang & Brim           Expires September 30, 2008              [Page 14]


Internet-Draft               Design Taxonomy                  March 2008


   o  Is it possible to physically separate control traffic from data
      traffic?

   o  Vulnerability to scanning attacks filling cache.


9.  References

9.1.  Normative References

   [ENDPOINTS]
              "Endpoints and Endpoint Names: A Proposed Enhancement to
              the Internet Architecture [unpublished]", June 1995,
              <http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt>.

9.2.  Informative References

   [PODC06]   Konjevod, G., Andrea, R., and D. Xia, "Optimal-Stretch
              Name-Independent Compact Routing in Doubling Metrics",
              <http://www.public.asu.edu/~dxia2/papers/ PODC06.pdf>.


Authors' Addresses

   Lixia Zhang (editor)

   Email: lixia@cs.ucla.edu


   Scott Brim (editor)

   Email: swb@employees.org



















Zhang & Brim           Expires September 30, 2008              [Page 15]


Internet-Draft               Design Taxonomy                  March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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).





Zhang & Brim           Expires September 30, 2008              [Page 16]