PROPOSAL: Identifier-Locator Network Protocol (ILNP) KEY IDEAS: - Provide crisp separation of Identifiers from Locators. - Identifiers name nodes, not interfaces. - Locators name subnetworks, rather than interfaces, so they are equivalent to an IP routing prefix. - Identifiers are never used for network-layer routing, whilst Locators are never used for Node Identity. - Transport-layer sessions (e.g. TCP session state) use only Identifiers, never Locators, meaning that changes in location have no adverse impact on an IP session.
BENEFITS: - The underlying protocol mechanisms support fully scalable site multi-homing, node multi-homing, site mobility, and node mobility. - ILNP enables topological aggregation of location information while providing stable and topology-independent identities for nodes. - In turn, this topological aggregation reduces both the routing prefix "churn" rate and the overall size of the Internet's global routing table, by eliminating the value and need for more-specific routing state currently carried throughout the global (default-free) zone of the routing system. - ILNP enables improved Traffic Engineering capabilities without adding any state to the global routing system. TE capabilities include both provider-driven TE and also end-site-controlled TE. - ILNP's mobility approach: - eliminates the need for special-purpose routers (e.g. Home Agent and/or Foreign Agent now required by Mobile IP & NEMO). - eliminates "triangle routing" in all cases. - supports both "make before break" and "break before make" layer-3 handoffs. - ILNP improves resilience and network availability while reducing the global routing state (as compared with the currently deployed Internet). - ILNP is Incrementally Deployable: - No changes are required to existing IPv6 (or IPv4) routers. - Upgraded nodes gain benefits immediately ("day one"); those benefits gain in value as more nodes are upgraded (this follows Metcalfe's Law). - Incremental Deployment approach is documented. - ILNP is Backwards Compatible: - ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully backwards compatible with IPv4). - Reuses existing known-to-scale DNS mechanisms to provide identifier/locator mapping. - Existing DNS Security mechanisms are reused without change. - Existing IP Security mechanisms are reused with one minor change (IPsec Security Associations replace current use of IP Addresses with new use of Locator values). - NB: IPsec is also backwards compatible. - Backwards Compatibility approach is documented. - No new or additional overhead is required to determine or to maintain locator/path liveness. - ILNP does not require locator rewriting (NAT); ILNP permits and tolerates NAT should that be desirable in some deployment(s). - Changes to upstream network providers do not require node or subnetwork renumbering within end-sites. - Compatible with and can facilitiate transition from current single-path TCP to multi-path TCP. - ILNP can be implemented such that existing applications (e.g. applications using the BSD Sockets API) do NOT need any changes or modifications to use ILNP. COSTS: - End systems need to be enhanced incrementally to support ILNP in addition to IPv6 (or IPv4 or both). - DNS servers supporting upgraded end systems also should be upgraded to support new DNS resource records for ILNP. (DNS protocol & DNS security do not need any changes.) DOCUMENTATION: Numerous peer-reviewed research papers, several presentations, and several Internet Drafts are kept updated at the ILNP project web site: <http://ilnp.cs.st-andrews.ac.uk> Most of the above documentation is focused on ILNP for IPv6 (ILNPv6), but the ILNP architecture can also be adopted for IPv4 (ILNPv4). Engineering details necessarily vary between ILNPv6 and ILNPv4, but the architecture is identical. Revised ILNP Internet-Drafts are expected to be published online in early January 2010. U. St Andrews has an ILNP prototype. EOF _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg