[Ila] Proposed charter

[Tom Herbert <[e-mail]>]

Here is a first stab at a charter. Please comment!

Tom
--------------------------

Identifier-locator addressing (ILA) is a method of identifier/locator
split used with IPv6 that eschews encapsulation. It is a means to
implement network overlays based on translations between
application-visible, non-topological “identifier”  addresses, and
topological “locator” addresses. Locator addresses allow packets to be
forwarded to the network location where a logical or mobile node
currently resides or is attached. Before delivery to the ultimate
destination or application, addresses are reverse translated back to
the original application visible addresses. A database of identifier
to locator mappings is maintained to facilitate translation.  Nodes
can be mobile such that their identifier to locator mapping changes,
but identifier addresses are persistent. ILA is similar to ILNP,
however ILA is confined to the network layer, not limited to end node
deployment, and doesn’t require extension headers.


The goal of this group is to define and standardize the ILA datapath
and control plane. The ILA datapath defines the address structure and
mechanisms for translating between application visible identifier
addresses and locator addresses.The control plane includes protocols
to disseminate identifier to locator mappings. Similar to IP routing,
different control plane protocols might be defined for different
needs.


The use cases of ILA include mobility, datacenter virtualization, and
network virtualization; these will be elaborated on by the group.
There are several benefits of ILA compared to existing solutions. ILA
enables anchor-less mobility, benefits user privacy, and provides
advantages over traditional encapsulation methods in terms of
performance, efficiency, and compatibility with deployed networking
hardware.


Nodes performing ILA translation maintain a table of identifier to
locator mappings. A node might might contain a full set of mappings
(ILA routers) or a working set cache of mappings (ILA forwarding nodes
and ILA hosts). Similar to IP routing protocols, different protocols
may be employed for these two cases. There are three basic methods for
populating the cache: push, pull, and redirects. The methods chosen
must be considered in light of security considerations and potential
for Denial of Service attacks.


This group will pay particular attention to privacy, secure, and
scalability characteristics of the solution. A goal of ILA is to
facilitate strong user privacy in addresses; this is acheived by
purging IP addresses of hierarchy that could be used to infer
geo-location, and also by allowing applications to use source
addresses for different flows to prevent unwanted correlations being
being made by a third party . The mapping system contains personally
identifiable information (PII) that can reveal user identities or
physical location of users, hence access to the mapping system must be
strictly controlled. Scalability of both the deployment architecture
and mapping system is important since the number of identifiers in a
network is expected to be in the billions.


This group will try to reuse relevant technologies from existing
mobility and encapsulation solutions. It will also leverage recent
work in scalable distributed databases and key-value stores. The work
produced by this group may be relevant to DMM, nvo3, LISP, int-area,
v6ops working groups in IETF, as well as other SDOs such as 3GPP.