Short version: CES architectures are completely different from
CEE architectures - and CES is very much superior
to CEE. There are no proposals which combine
elements of both.
I argue in a companion message:
Today's "IP addr. = ID = Loc" naming model
should be retained
that the current 2-level naming structure - in
which the IP address performs the roles of both
Identifier and Locator - is superior to the CEE
Loc/ID separation approach in which these roles
are played by two different objects, in different
namespaces.
While CEE makes life easy for the routing system,
it burdens all hosts with extra work, extra
traffic and extra delay just to establish almost
any communication session.
CES is superior to CEE because it maintains the
current naming system.
CES is also much easier to adopt than CEE.
CES provides immediate full benefits to all
adoptors - and provides routing scaling benefits
in direct proportion to the level of adoption.
CEE only provides substantial benefits to adopters
- or significant scaling benefits - after all, or
almost all networks have fully adopted it. This
means upgrading essentially every host stack and
rewriting essentially every application to use the
new CEE Identifier-based method of communication.
Hi Joel,
In "Re: [rrg] Multiple critiques, choice of single proposal, ..."
(msg05846) you wrote:
> If someone wants to add text on Identifier / Locator separation as a
> useful architectural principle, I guess I can't object.
Do you mean Core-Edge Elimination (CEE) or Core-Edge Separation
(CES)? Please see this recent message for my concerns about how this
term means different things to different people:
Terminology: Loc/Id sep., LISP, CEE & CES, namespace
http://www.ietf.org/mail-archive/web/rrg/current/msg05858.html
> And I consider the CEE / CES debate to be missing the point.
I completely disagree. These are both capable of solving the scaling
problem, but they are completely different approaches with completely
different costs and methods of achieving their goals.
A CES architecture (LISP, APT, Ivip, TRRP, TIDR or RANGER):
1 - Maintains the current 2 level naming arrangement - where the
FQDN is performs the "Text name" role and the Identifier and
Locator roles are both performed by the IP address.
Role Level Conventional IP & with CES
Text name <---- FQDN
Identifier <---] IP address
Locator <---]
2 - Scalable routing is achieved by creating an "edge" subset of
the global unicast address range - the remainder of which is
known as the core. The "edge" addresses are all covered by
DFZ-advertised prefixes, but these are few in number, since
each such prefix (a MAB - Mapped Address Block in Ivip) covers
a large number of "edge" addresses. This means the "edge"
addresses are not much of a burden on the DFZ control plane -
and do not add much to the numbers of routes to handled by
the RIBs and FIBs of DFZ routers.
A new set of network elements - ITRs, ETRs and a mapping
system - handle all packets addressed to an "edge" address -
by tunneling them across the DFZ to an ETR, which is always
on a "core" address. This is done in a way which supports
the portability, multihoming, inbound TE and ideally mobility
needs of end-user networks of all sizes.
Furthermore, this system enables the edge space to be divided
much more finely than is possible with the DFZ, since with
the IPv4 DFZ at least, there is a widely supported convention
not to propagate prefixes longer than /24. Ivip and LISP can
divide "edge" space down to single IPv4 addresses. Ivip for
IPv6 manages "edge" space in units of /64.
3 - Requires no change to host stacks, APIs or applications.
(Nonetheless, in Ivip the ITR function can optionally be
implemented in the sending host.)
4 - Does not affect most internal and DFZ routers, but requires
the new ITR and ETR functions to be performed in new devices
and/or existing routers.
5 - Provides benefits for adoptors immediately - full portability,
multihoming, inbound TE and ideally mobility benefits to each
adoptor, irrespective of how many other networks have adopted
it:
^
B |********* Core-Edge Separation (CES)
e |*********
n |*********
e |*********
f |*********
i |*********
t |*********
|*********
|*********
0--------->
Effort ~= level of adoption
6 - Provides routing scaling benefits in direct proportion to
how widely it is adopted, by two mechanisms. Firstly, more
end-user networks get the portability, multihoming etc. they
want/need. Secondly, they get these benefits without
significant load on the DFZ. This will lead to some reduction
in the number of PI prefixes in the DFZ as current PI-using
networks adopt the CES architecture. PI-using networks could
either convert their PI prefixes to "edge" space and being able
to use this space more flexibly, in finer slices - or they
could relinquish their PI space and rent some "edge" space.
Since "edge" space can be more finely divided, they probably
don't need as much of it as with PI space, for which the
finest chunk is /24.
^
B | * Core-Edge Separation (CES)
e | **
n | ***
e | ****
f | *****
i | ******
t | *******
| ********
|*********
0--------->
Effort ~= level of adoption
A CEE architecture (ILNP, GLI-split, Name Based Sockets, HIP etc.):
1 - Changes the current naming arrangement so there are separate
objects, with separate namespaces, for the Identifier and
Locator roles. I think most CEE approaches use 3 levels -
FQDNs for the "Text names", and separate levels to perform
the Identifier and Locator roles. In some CEE architectures
such as ILNP, the lower part of the IPv6 address performs
the Identifier role and the upper part of performs the
Locator role.
Role Level Some CEE architectures
such as HIP
Text name <---- FQDN
Identifier <---- HIT
Locator <---- IPv6 address
Role Level Some CEE architectures
such as ILNP
Text name <---- FQDN
Identifier <---- IIII IIII } Combined into
Locator <---- LLLL LLLL } one IPv6 address
I don't yet fully understand Name Based Sockets, but it has a
naming structure something like this. In practice, I think
the Identifier role may be performed by a combination of
Identifier and Locator, so a single text FQDN can be used
with "round-robin DNS" to select one of several separate
hosts, each of which must have a separate Identifier.
Role Level Name Based Sockets?
Text name <---] FQDN
Identifier <---]
Locator <---- IPv6 address
2 - Scalable routing is achieved by applications no longer being
dependent on stable IP addresses for session continuity. This
is because they use an Identifier to determine the host to which
each communication session is established and maintained. The
CEE stack figures out which of potentially multiple Locators
to use, and Locators can usually be added to and deleted from
the set of allowable Locators for any one Identifier, as the
session continues.
Identifiers are portable. Multihoming is achieved by the stack
managing multiple Locators to continue the session if the
end-user network becomes unreachable by the currently used
Locator. Inbound TE is achieved by which Locator is used in
outgoing packets - since in general the other host will send
packets back to this host using the Locators this host most
recently used in outgoing packets. Mobility is achieved by
doing all this, and maintaining sessions, despite frequent,
ad-hoc, changes of Locators.
When (almost) all a network's hosts are having (almost) all
their communications occurring with the new CEE arrangement,
then portability, multihoming and ideally mobility can be
provided just as well on PA prefixes as on PI. At this point
the routing scaling benefits finally occur - all networks can
do portability multihoming etc. Those which used to do these
things via conventional PI space no longer need this PI space.
3 - Before there can be substantial scaling benefits, all host
stacks and all applications must be upgraded to use the CEE
"Loc/ID separation" naming structure.
4 - Requires no changes to internal of DFZ routers. There is
typically a need for a new mapping system by which hosts
can look up an Identifier and receive the one or more Locators
that host is using. (Name Based Sockets uses the existing
DNS.)
5 - Provides portability, multihoming, inbound TE and ideally
mobility benefits to each adoptor, in proportion to how
many other networks have adopted it. This is because the
CEE host and its CEE applications can only provide these
benefits when communicating with other CEE applications
in other CEE hosts. (A good CES system provides these
benefits to packets sent by all hosts, including those
in networks without the CES's ITRs.)
For an adoptor (assuming their hosts communicate, in
general, with a mix of hosts in all other networks), the
proportion of communications with the benefits (portability,
multihoming, TE and ideally mobility) increases linearly
with the level of adoption.
However, for most networks, I think it is fair to say that
they only get real usable benefits when all, or nearly all,
of their communications are using the new system. Only then
can their network be fully portable and multihomed without
the need for PI space.
^
B | * Core-Edge Elimination (CEE)
e | .*
n | ..* . Proportion of communications
e | ...* with the benefits.
f | ....*
i | .....* * Actual total benefits generally
t | ......* only arise when all, or almost
| .......* all, communications have the
|........* benefits.
0--------->
Effort ~= level of adoption
6 - Provides routing scaling benefits in two forms:
A - When most or all networks which have PI space can
abandon it and use PA space instead. This is when
(almost) all of their communications use the new
system - which is when (almost) all other networks
have fully upgraded all their host stacks and all
their applications.
B - When those without PI space have all, or almost all
of their communications using the new system, for
the same reasons as above.
In both cases, the curve is:
^
B | * Core-Edge Elimination (CEE)
e | *
n | *
e | *
f | *
i | *
t | *
| *
| *
0--------->
Effort ~= level of adoption
CES and CEE are *completely* different ways of solving the routing
scaling problem.
I think everyone agrees that a good CES architecture is easier to
introduce on a voluntary basis than any CEE architecture, since the
adopting networks get full benefits immediately, don't need to alter
their host stacks, or require upgraded versions of their applications.
I think many people believe that the final state of the Internet with
good CEE architecture is a better than could be achieved with the
best CES architecture. I think this is because of two interdependent
beliefs:
1 - The routing system should be kept simple, if there is any
way hosts can be changed to achieve this.
2 - The current 2 level IP naming structure - making the IP
address perform both the Identifier and Locator roles -
is architecturally flawed and should be fixed to make
these independent levels, each with a different namespace.
The practical benefits of this are largely that the
routing system can be made to scale well, while remaining
as simple as it is today. The hosts themselves, with the
aid of an Identifier -> Locator mapping system, will do
all the portability, multihoming, TE and mobility work
themselves.
I disagree with this viewpoint.
I think the routing system should serve the hosts - and that it will
be easier to upgrade the routing system to make it scalable with a
CES architecture, than to upgrade all hosts and all their
applications to implement CEE.
I think the current 2 level IP naming structure is better than the
Loc/ID Separation CEE approach, as explained in the companion message.
Here is my understanding of the arguments for why CEE is the best
long-term arrangement for the Internet:
1 - Adding new network elements (as are required by CES) is
inefficient, expensive and contrary to the principle of
keeping the network simple and elegant, while implementing
as much of the total functionality of the Net in the hosts.
Host CPU power is inexpensive. Host software can be upgraded
without the need to buy new hardware or establish the
commercial mechanisms for building and running the ITRs, ETRs
and mapping system which is required for CES.
2 - The current IP naming model is fundamentally broken, because
it makes the one object - the one level of a 2 level system -
the IP address, play the roles of both Identifier and Locator.
This is architecturally wrong and it makes it difficult or
impossible to create a routing system which support large
numbers of end-user networks with portability, multihoming,
inbound TE and mobility.
The right way (as Tony would say) to do it is to create new
protocols so all hosts communicate with the use of independent
Identifiers and Locators.
Here are my arguments for why CES is superior to CEE:
1 - While CES involves adding significant new things to the
routing system, this is a lot easier than upgrading all
host stacks rewriting all applications.
CES early adopters get full benefits, no matter how many
other networks adopt it. So a CES is far easier to have
adopted at all, and then to have fully adopted, than any
CEE architecture.
While a CES architecture needs a mapping system, so do most
CEE architectures. The CES mapping system is arguably more
efficient and so can be less costly than that of a CEE
mapping system because:
a - The CES mapping system is only used by ITRs - and
each ITR caches the mapping and will frequently
use the same mapping to support the communications
of multiple hosts.
b - A CES mapping lookup is only required at the start
of communications sessions where the destination
address is in the "edge" subset. Even if CES is
adopted by all end-user networks which want or need
portability, multihoming etc. there will still be
a large number of hosts using PA space. This includes
almost all home, SOHO and small commercial customers
who are doing fine, and will continue to be happy with,
their one IPv4 (or later an IPv6 /64) of PI space.
A CEE lookup is needed by both the initiating and
responding hosts for almost all new communication
sessions. The only exceptions are where the
responding host - such as a DNS server - doesn't care
if the packet it sends goes to a host which has a
different Identifier to that used in the request
packet.
CEE can't be useful for IPv4, since multihoming a /18
network would require a /18 of PI space from one ISP and
another /18 from another ISP. So it would at least double
address consumption.
CEE can't work with hosts behind NAT. Ideally NAT won't
be used with IPv6, but this cannot be assured.
There is another difficulty which I foresee, which I don't
think has been discussed much - how a CEE copes with a
host which has one or more Locators on global unicast
space and one or more locators on one or more private
address spaces.
Global unicast Locators can be used to communicate with
other global unicast Locators - but not private Locators.
Two hosts with Locators in the same private network space
can use them to communicate. This would probably be
preferred over using the global unicast Locators. The
CEE stack and the various protocols between hosts will
need to cope with the various complications which arise
from this.
CEE hosts may need to inform a very large number of other
hosts they are communicating with if they adopt a new
Locator and stop using another. This information also
needs to be securely uploaded into the DNS and into
the Identifier -> Locator mapping system. This is a
lot of work, particularly for hosts on slow links which
are subject to congestion and packet loss due to radio
difficulties.
IPv6 addresses can have their lower 64 bits frequently
changed in order to make it difficult for anyone outside
the network to trace activity, such as to web servers, to
individual computers - and so by implications to individual
people. However, to be able to do this with CEE would also
involve each such host changing its Identifier as well.
This could be done, but it involves the creation and deletion
of state in the public global DNS and Identifier -> Locator
mapping systems. This would be onerous and may compromise
the privacy benefits of the technique. For CEE architectures
in which the lower 64 bits of an IP address is the Identifier
and where Identifiers must be globally unique, then this
means the randomization of Identifiers can only be within
a range restricted by whatever range of Identifier space the
network has been allocated.
2 - While CEE does involve a simpler network, this benefit is far
to slight to make up for greater effort hosts must make when
beginning new sessions. Please see the companion message:
Today's "IP addr. = ID = Loc" naming model should be
retained
for more details. This is particularly the case for the
future, in which most hosts will be running continually
from small batteries and will generally rely on 3G or similar
wireless links.
So while both CES and CEE architectures can both, in principle, solve
the routing scaling problem, they do so in completely different ways,
involve completely different adoption hurdles and result in
completely different host protocols in the final system.
> Firstly, many of the solutions and not purely one or the other. As Noel
> has observed, one can migrate LISP (ostensibly a CES solution) into the
> host.
Whether or not this is done, LISP remains entirely a CES
architecture. Just because a LISP MN can be its own ETR and ITR
doesn't mean that LISP in any way resembles a CEE system. The ITR
and ETR functions in such a host would be simple additions to th the
stack. The IP stack, its API and all applications would remain
unchanged. The two-layer IP naming structure remains unchanged.
> Architecturally, and in terms of the end state, I think that CEE is a
> much better target.
I hope you will respond to my arguments to the contrary.
> In terms of deployability and related issues, CES techniques tend to
> have a big advantage.
Yes.
> Hence, I have a personal preference for solutions which straddle this
> boundary,
What are these? I don't know of any such solutions.
> rather than seeing utility in arguing about which one we want.
There are huge differences between CEE and CES architectures.
> And I don't the the RG has a clear agreement on this at all.
Not yet.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
