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
