Bibliography Details

M. O'Dell, "GSE - An Alternate Addressing Architecture for IPv6" 1997.

GSE - An Alternate Addressing Architecture for IPv6
Authors:	M. O'Dell
Published:	INTERNET DRAFT, 1997
URL:	http://www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt
Entry Date:	2002-5-29
Abstract:	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.
Results:	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). 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. 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 Large Structures) 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. 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. 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). Addresses are distributed in two ways: 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. 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. Rehoming and multihoming events: 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. 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. 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. 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?
Notes:	draft-ietf-ipngwg-esd-analysis provides an analysis of GSE, and in particular the issue of separating locator and identifier. This is a revision of an earlier proposal by the same author, called 8+8.