<?xml version="1.0" standalone="no"?>
                    <!DOCTYPE div SYSTEM "/www/backend/www-xml-443/dtd/caidaML.dtd">
                    <!-- do NOT ERASE the DOCTYPE declaration! --><div>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>URL:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<a href="http://www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt">http://www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt</a>
</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Entry Date:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
2002-5-29


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>Abstract:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
   This document presents an alternative addressing architecture for
   IPv6 which controls global routing growth by very aggressive
   topological aggregation. It includes support for scalable
   multi-homing as a distinguished service.  It provides for future
   independent evolution of routing and forwarding models with
   essentially no impact on end systems.  Finally, it frees sites and
   service resellers from the tyranny of CIDR-based aggregation by
   providing transparent re-homing of both.


</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Results:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
  Describes a routing architecture for IPv6 in which location and
  identification of end systems are separated.
  Proposes an IPv6 address that contains a 6-byte 'Routing Goop' (a topological
  locator encoding the global connectivity of a site), a 2-byte 'Site Topology
  Partition' (internal routing information of the end system), and an 8-byte
  'End System Designator' (identifies the end system or an interface of an end
  system).
    
  <ul>
    <li>
    The routing goop is used for routing outside a site, in the Global
    Internet. The routing goop corresponds to an attachment of a site. For a
    multihomed site, there is one routing goop per attachment.  The routing
    goop is changed on rehoming.
  <br/>
    The structure of the routing goop reflects a hierarchical structuring of
    the Global Internet.  Each level in this hierarchy is a flat-routed region
    in the Internet (normally corresponding to a provider network it seems).
    The routing goop consists of a sequence of substrings, one for each
    provider that this attachment (as a path) traverses through the hierarchy.
    The routing goop is thus similar to a CIDR prefix.  The top level of the
    hierarchy (comprising <i>Large Structures</i>) provides a forwarding token of
    last resort, significantly limiting the minimally-sufficient information
    required for a default-free router. However, GSE allows cutting through the
    hierarchy as optimisations.
    </li>

    <li>
    The ESD and optionally the STP are used for routing within a site. Therefore
    intra-site routing is independent of the routing goop, and therefore also
    of the connectivity of a site.
    Since the ESD and STP are not used for routing outside the site, the
    internal topology of a site remains hidden.
  <br/>
    The ESD alone serves as identification in upper level protocols such as
    TCP.  Long-lived sessions can therefore be preserved under rehoming and
    multihoming events (however see below).
    </li>
  </ul>

  Addresses are distributed in two ways:
  <ul>

    <li>
    Through the packet source address. When a packet is sent, the ESD of the
    source address is supplied by the end system, and the routing
    goop by a boundary router of the source's site. Boundary routers
    know the routing goop(s) of the site. 
    </li>

    <li>
    Through DNS look-ups. An AAA record contains the ESD and STP parts and an
    RG record contains the routing goop. On rehoming only the RG record is
    modified.  A further indirection is suggested by placing a DNS name in the
    AAA record that will resolve to the RG record. The RG name can then use
    `upward delegation' to the provider through DNS to define the full routing
    goop.
    </li>
  </ul>

  Rehoming and multihoming events:
  <ul>
    <li>
    Multihoming a site.  There is a separate routing goop for each connection.
    On connection failure the provider will tunnel packets to one of the other
    providers of the site.
    </li>

    <li>
    Rehoming a site.
    Special case of multihoming. The site becomes multihomed during a period of
    time in order to sustain long-lived sessions (`rehoming courtesy').
    Subsequently the old connection can be taken down and the old provider
    will tunnel packets to the new provider as part of the rehoming courtesy.
    Note that long-lived sessions can only be maintained during this grace
    period.
    </li>

    <li>
    Rehoming a provider.  See rehoming a site, with a prefix of the routing
    goops of customer sites being replaced. This is mostly transparent to
    customers. Again note that long-lived sessions of sites will be affected
    after the grace period has expired.
    </li>

    <li>
    Multihoming a provider.  Similar to multihoming a site, in that there are
    different routing goop prefixes for different paths. Problem: which prefix
    is used for customers. The author appears to suggest picking one for all
    customers. But in that case traffic will surely be attracted towards just
    one of the provider's access points?
    </li>
  </ul>


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>Notes:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<ul>
<li>
<a href="http://www.join.uni-muenster.de/Dokumente/drafts/draft-ietf-ipngwg-esd-analysis-05.txt">draft-ietf-ipngwg-esd-analysis</a> provides an analysis of GSE, and in particular
the issue of separating locator and identifier.
</li>

<li>
This is a revision of an earlier proposal by the same author, called <i>8+8</i>.
</li>

</ul>



</font>
  </td>
</tr>
</div>

