The Cisco & IETF LISP Protocol is not a Locator - Identifier
Protocol, because it does not involve a separate namespace for
Please see the page ../ for the full context of this.
2011-11-02 Robin Whittle email@example.com
Minor updates 2011-11-03
Here is a longer explanation which assumes no knowledge of the LISP
protocol or the IRTF Routing Research Group work in recent years on
The main purpose of scalable routing is "scalable multihoming" of large
numbers of end-user (AKA "edge") networks - to allow millions or
billions of separate end-user networks to retain their own global
unicast address space no matter which ISPs they use for connectivity,
without all the world's 200k+ BGP routers having to add a new prefix for
that end-user network into their Routing Information Bases and their
Forwarding Information Bases. It is expensive for each router to do so,
and there are something like 200k+ BGP routers (no-one knows for sure).
In addition to the cost of these routers going up with the 380k+ and
growing prefixes http://bgp.potaroo.net/ they handle today, this large
number of prefixes makes the global BGP system less able to do is job -
cope rapidly with failures and reconfigurations.
For more on Scalable Routing, see the main Ivip page: ../../ .
For more on the meaning of the term "namespace": ../ )
LISP, along with other proposed architectures such as my Ivip (derived
from some basic LISP principles) IRON, ILNP and others, is intended as a
scalable routing solution - something which can be adopted by the
current Internet to solve the scalable routing problems in the
long-term, and hopefully within not to many years.
LISP, or Ivip or whatever, is intended to provides a "scalable" approach
to multihoming in that it can, ideally, be expanded to millions or
hundreds of millions of end-user networks, each with their own
permanently assigned, ISP-portable, global unicast address space,
*without* burdening all the world's BGP routers with another prefix on
top of the 380k+ and growing prefixes they already struggle with (at
great expense to all ISPs and therefore all Internet users.)
The LISP Protocol & the Locator and Identifier functions of IP addresses
The LISP protocol doesn't affect hosts. The semantics of IP addresses
for hosts remains unchanged from today's arrangement in which the IP
address functions both as a routing Locator (used by routers to to
figure out how to get the packet to its destination) and as a "host
Identifier" (used by hosts to identify each other). Alternatively we
might think of the Identifier function being an "endpoint" Identifier,
since one host could have one or more physical interfaces, each of which
responds logically to one or more multiple IP addresses - and we can
think of each such IP address sending and receiving function as an
"endpoint". (This is my guess of what "endpoint" might mean. Other
people may use the term differently.)
I argue that this "overloading" of both Locator and Identifier
functionality on the one IP address is a very good thing - despite the
attraction many people have felt for using separate Identifier and
Locator objects, each with their own namespace:
"Overloading" of Loc & ID functions is good for hosts and should be
The host only interprets the IP address in the destination field of an
outgoing packet as a routing Locator if the host contains routing
functions - that is, if it has two or more physical interfaces and so
needs to decide which interface to send the packet from. Assuming that
the host doesn't contain any LISP protocol functionality (an ITR
function) then the host's routing function will use normal router
principles to figure out which interface to send the packet from.
(These normal router principles involve matching the
destination address to the most specific prefix - the
longest matching prefix - which is assigned to a given
interface, and sending the packet out that interface.
It is a simple, mechanistic, algorithm - but is expensive
to implement at gigabit speeds with hundreds of thousands
Generally speaking, the same is true of edge networks, if we assume (for
simplicity) that the LISP protocol's ITRs and ETRs are always located at
the borders of these edge networks: all hosts and routers within edge
networks are unaltered by introducing the LISP protocol, so they
interpret both the Identifier and Locator meanings of an IP address in
the same way as they always did. (Actually, ITRs can be inside the edge
networks, potentially inside the hosts and can also be in the DFZ = in
ISP networks rather then and-user edge networks.)
With the LISP protocol, the Identifier functionality of an IP address
never changes. There is no new Identifier namespace.
GSE, HIP and ILNP are Loc-ID Separation protocols, because they all
involve the creation of a new namespace for host (or "endpoint", if you
like) Identifiers. The objects which are used as identifiers may or may
not have the same format and number of bits as an IP address. If they
have a different number of bits, then they must have a different
namespace from the IP address namespace, because they can't be
interpreted according to the IP address namespace. Even the Identifier
objects have the same number of bits as an IP address, a Loc-ID
Separation architecture interprets them according to totally different
rules than for IP addresses. That is to say, these Identifiers are
interpreted according to a namespace which is different from the IP
With the LISP protocol, the IP address 184.108.40.206 (or any other IPv4
global unicast IP address) has exactly the same host/endpoint Identifier
functionality and semantics, no matter whether this IP address falls
within the LISP protocol's "EID" subset of the set of global unicast
addresses, or within the remaining subset, which in the LISP protocol
are called "RLOC" addresses.
The LISP protocol does not affect how the packet is handled within edge
networks. So within edge networks (hosts and routers) the routing
Locator semantics of the IP address are also unchanged by the LISP
protocol - again irrespective of whether the address is within one of
the LISP protocol's EID prefixes or not.
A LISP protocol's ITR's (Ingress Tunnel Router) job is to find packets
leaving an edge network for the "core" - the networks of ISPs, in which
BGP is used to handle routing between ISP networks. The "core" is also
broadly synonymous with the Default-Free Zone (DFZ) where BGP routers
have no single "upstream" interface, and so can't apply a "default
route" for a single interface to any packet whose destination address
does not match a relatively small set of prefixes of the current
end-user or ISP network.
The LISP protocol uses ITRs, ETRs (Egress tunnel routers - these are
Ingress into a tunnel and Egress out of the tunnel) and a global mapping
system to get packets across the core to end-user (edge) networks which
are using LISP-protocol-mapped EID address space. ITRs do this using an
algorithm which is totally different from the normal "longest matching
prefix" forwarding behavior of routers (whether the routers use an IGB
or the global BGP system).
In the LISP protocol, there is a subset of global unicast address space
which is known as "EID" space. IP addresses in this subset may be
referred to as "LISP-protocol-mapped", though I think this is not
official LISP protocol terminology. This means that a query to the LISP
protocol mapping system for any address within an EID prefix will return
a response that it is in such a prefix. If the end-user network, whose
EID prefix this is, is multi-homed via two or more ISPs, then the
mapping will contain two or more ETR addresses, one for each of the ETRs
which can be reached via the various ISPs.
The LISP protocol works by providing a new system of interpreting a
destination IP address for the purposes getting packets from one edge
network to another than by relying on the global BGP system. In other
words, between ITRs and ETRs (across the "core"), the LISP protocol has
a second way of interpreting the destination IP address for the purpose
of using it as a routing Locator - which is only used IF the destination
address matches one of the EID prefixes.
ITRs forward packets not addressed to EID prefixes in exactly the same
way as ordinary packets. (Since ETRs are not located in EID prefixes,
when an ITR tunnels a packet to an ETR, this packet with its new outer
header is handled by the normal router functionality of the ITR, and is
handled normally by all the non-LISP-protocol-aware conventional routers
between the ITR and the ETR.)
ITRs examine the destination addresses of outgoing packets, and when
they find one which matches an EID, the ITR obtains, via the mapping
system, the one, two or more ETR addresses by which the destination edge
network could be reached. Exactly which one of these to choose is up to
the ITR - and LISP protocol ITRs need to figure out this choice on their
own, independently, depending on what they decide about the reachability
of each ETR. (A problem is that there isn't a way they can be sure an
ETR can get the packet to a destination network.)
This this means each ITR will ideally be able to choose at least one ETR
by which it can deliver the packet. The packet is then encapsulated and
tunnelled to the chosen ETR. The ETR decapsulates it and forwards it to
the destination edge network, which uses perfectly ordinary routing
"Locator" semantics with the destination address to forward the packet
to the destination host.
So what the LISP protocol does is define a dynamically changeable (as
EID prefixes are added to the global LISP protocol system) subset of the
global unicast address space in which its ITRs and ETRs will implement
different "Locator" semantics to the semantics which is used by the
ordinary routing system. This is a perfectly excellent thing to do -
since it achieves the goal of edge networks being physically connected
via ISPs which do not advertise the edge-network's prefix(es) to the
DFZ, and being able to keep this address space no matter which ISP they
connect with, including dynamically if one ISP fails.
(The LISP protocol extends this to mobility, with each MN
being its own ETR - but this can't work behind NAT and
when the MN gets a new IP address, there's no way the
ITRs which are sending it packets can securely get the
new mapping information fast enough to maintain
connectivity suitable for VoIP.)
There's no new namespace.
There's just a subset of the global unicast address space, composed of
multiple EID prefixes, where the LISP protocol implements an alternative
and very helpful approach to the "Locator" function of a the destination
IP address of any packet which is sent to an EID address. Rather than
forwarding the packet normally and letting other routers forward it
according to best path for the longest prefix match of all the 380k+
IPv4 DFZ prefixes they figure out with BGP, the ITR tunnels it to an ETR.
That's it. There's no new namespace.
LISP has no separate namespace for Identifiers
A namespace is a context for interpreting a name or number.
The name "Robin" could be interpreted in a number of namespaces (AKA
according to a number of namespaces), for instance within the namespace
of birds, or within the namespace of a particular family whose surname
is "Hood", or within the namespace of another particular family whose
surname is "Whittle".
"9459 1234" is a string of text which we can think of as an 8 digit
decimal number. This number has no meaning on its own (unless we assume
the namespace of integers), because on its own, there's no specification
for which namespace to use.
If I say this should be interpreted according to the namespace of the
Australian 03 telephone number zone, then I am specifying a namespace
within which this number can be interpreted. In this namespace, (for
the sake of this example, though this is not my phone number) this
number uniquely identifies a particular phone service, probably not too
far from Heidelberg in Melbourne.
If we interpret the same number according to a different namespace, such
as the Australian 02 zone, then it will be a number somewhere in NSW,
probably in some Sydney suburb.
The same number could be interpreted as a catalogue number, a part
number or in any number of ways - each system of interpretation is a
different namespace, which ascribes to the one number a different meaning.
The subset of the 2^32 IPv4 addresses which makes up the global unicast
address space of IPv4 is a set of IP addresses which are all interpreted
according to the one "IPv4 global unicast" namespace, for both their
host/endpoint Identifier and their routing Locator semantics.
Currently, and with the LISP protocol, each such IP address such as
220.127.116.11 has both an Identifier and a Locator function (AKA semantics).
As far as hosts go (assuming the hosts have no inbuilt LISP protocol
functions, even though they may include router functions) the Identifier
and Locator aspects of a 18.104.22.168 are not affected by whether the
LISP protocol has been implemented or not, or - if it has been
implemented, whether this address is within an EID prefix or not.
The LISP protocol does not involve any new namespace for hosts to use
with respect to the 32 bit numbers found in packets - since hosts are
completely unaffected by the LISP protocol.
Within a LISP protocol box, such as an ITR, there is likewise no new
In an ITR, there is an alternative way of deciding how to handle an
incoming packet, for packets whose destination address matches an EID.
That's all - this is not a new namespace.
It is possible to imagine a Loc-ID Separation architecture which
happened to use 32 bit numbers for Identifiers, using a new namespace.
Then, the number 22.214.171.124 would have two entirely separate and
independent meanings, depending on whether it was used as an IPv4
address or as an Identifier in the new system.
The LISP protocol doesn't do this. It doesn't create a new namespace.
It is not a Locator-Identifier Protocol.
Loc-ID Separation protocols such as GSE, HIP and ILNP create a new
namespace for objects which are used purely as Identifiers. They have
separate namespaces for the two different classes of objects, with one
class of objects being used for Identifiers, according to one namespace
and the other class (typically today's IP addresses, but just in a
Locator sense) being used for Locators, according to a second namespace
(typically today's existing interpretation of an IP address in terms of
how routers get them to their destination).
Its a very good thing that LISP is not a Loc-ID Separation protocol.
Likewise Ivip and IRON. I listed the main disadvantages of Loc-ID
Separation protocols in:
Msg70239 refers to Noel Chiappa's 1999 (I think) document regarding
Loc-ID separation, and to a page at my site concerning the meaning of
the word "namespace": the parent page ../ to this one.
It was always a mistake to think that LISP involves a new namespace for
Identifiers. The fact that the world's biggest router company says it
is so: http://lisp.cisco.com/lisp_over.html doesn't make it so.
LISP, Ivip and IRON are Core-Edge Separation (CES) protocols. GSE, HIP,
ILNP and other Loc-ID Separation protocols are Core-Edge Elimination