[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RAM] Re: Ivip (was ViP ...) diagram
Here is a diagram which might help with understanding Ivip.
I am maintaining a list of the longer messages I write about
Ivip at: http://www.firstpr.com.au/ip/ivip/
At present, this is the rambling Ivip documentation. I plan to
write a much more readable Internet Draft in August.
Dino wrote over a week ago that Ivip was like LISP 1.5. I have
tried to understand LISP 1.5 but have not been successful. I
hope he or Vince can explain it better to me, or ideally to the
list. I imagine many people have difficulty imagining concrete
examples of the LISP variants, because the descriptions in the
I-D are rather conceptual.
What I have written about LISP is just my understanding - and
doesn't include a bunch of LISP stuff such as ICMP messages,
multiple encapsulation etc.
I assume that both LISP and Ivip ITRs can have either a full
"push" copy of the central database or use "pull" and caching.
Here are four Edge Networks.
........ ..................
. .
Edge-A . . Edge-B
. .
H01 . . H04 IH01
. .
H02 . . H05 IH02
BR1 .
H03 . ETR1 H06 IH03
. TR1 TR2 . ETR2
........ ..................
ITR1 TR3
TR4 ITR2
............. ..................
. .
H10 IH07 ITR4 . ETR3 H07 IH04
ETR4 TR5 BR2
H11 IH08 . . ITR3 H08 IH05
. .
H12 IH09 . . H09 IH06
. .
. .
Edge-D . . Edge-C
.............. ...................
Key:
TRx Transit routers
BRx Border routers
ITRx Ingress Tunnel Routers } In this example, these are also
ETRx Egress Tunnel Routers } function as internal or BGP
} routers.
ETRs have at least one IP address which is a normal,
BGP-reachable, IP address.
Hxx Hosts with ordinary BGP-routable IP addresses, either
PI or PA. For instance desktop machines and servers.
IHxx Hosts with one or more IP addresses which are mapped
by the LISP/Ivip system. These could be routers
too. See my earlier messages for how each such IP
address is within one of the "master-subnets"
which all the ITRs advertise.
With LISP 2+, hosts in Edge-A can't send packets to any of the
IHxx hosts with LISP-mapped addresses, because those addresses
are not part of prefixes advertised in BGP. I think such
versions of LISP cannot be successfully deployed for this reason
- since no-one would want an IP address which some hosts
couldn't send packets to.
With Ivip, the mapped addresses are part of a BGP-advertised
prefix, so packets from Edge-A sent to such IP addresses are
forwarded to the nearest ITR, since all ITRs anycast advertise
the prefixes ("master-subnets") which Ivip maps.
There are five BGP advertised prefixes in this example. One for
each edge network and one for the Ivip system - though in
reality the Ivip system would probably handle many prefixes.
The diagram shows 4 groups of normal hosts H0 to H12, each of
which uses PA addresses from its edge network.
The 9 hosts with Ivip-mapped addresses can each use their one or
more Ivip-mapped addresses provided they are in an edge network
with an ETR and that edge network's routing system firstly
forwards the decapsulated packets to the host and secondly
allows packets from that host's IP address to be forwarded
normally: to any internal host or out via the border router to
ordinary BGP routers.
Here are descriptions of the networks, with the BGP prefixes
each one advertises.
Edge-A 11.0.0.0/16
------
An ordinary ISP or AS-end-user network with no special router
functions to support LISP or Ivip. The hosts in this network
are all ordinary hosts with conventional IP addresses which can
be reached from anywhere via the current BGP system. For this
example, I assume these hosts have addresses provided by Edge-A
- PA (Provider Assigned) addresses. So there is no portability
between ISPs (different edge networks) for the IP addresses used
by these hosts.
It would also be possible for one or more hosts to be run by
some organisation with an ASN, in which case that AS-end-user
can allow Edge-A to advertise one of its PI (Provider
Independent) subnets at its border router and the hosts can use
that address space. The primary purpose of LISP/Ivip is to
allow portability and multihoming to such end-users without them
needing to become Autonomous Systems or to have PI space
assigned to them.
Unless Ivip-mobile is used (which I have described in several
recent messages and which I will mention briefly below), the
hosts in this edge network cannot use LISP/Ivip-mapped
addresses. They can however send packets to and from with all
the IHxx hosts in other edge networks - which have Ivip-mapped
addresses - by using one of the "core-ITRs", probably ITR1 which
is closest.
Edge-B 12.0.0.0/16
------
This network has been upgraded so its border router also
performs ETR functions. The internal routing system has also
been configured to handle whatever the IP addresses are of three
hosts IH01, IH02 and IH03 which have LISP/Ivip-mapped IP addresses.
A second ETR2 function is implemented on an internal router.
Because there is no ITR in Edge-B, all its hosts rely on a
"core-ITR" when sending packets to any LISP/Ivip-mapped address
outside Edge-B.
Edge-C 14.0.0.0/16
------
Like Edge-B and Edge-D, this has a bunch of ordinary hosts and
IHxx hosts with LISP/Ivip-mapped addresses.
Any edge network with IHxx hosts needs at least one ETR. This
can be at the border router or at an internal router. Edge-C
has it in an internal router.
Edge-C has an ITR, also as in internal router.
These ITR and ETR functions are assumed to be additional to the
ordinary internal router functions. However they could be
performed by a specialised router or server which only does this
function, and has a single link to an internal or border router.
Also, the ITR and ETR functions could be performed by the same
router or server.
Edge-D 15.0.0.0/16
------
This has IHxx hosts too, and its single border router performs
both ITR and ETR functions. Hosts don't need to know where
ITRs are - Ivip-mapped packets are naturally forwarded to them.
Whoever runs each Ivip-mapped host does need to know the IP
address of the one or more ETRs in the edge network which can
decapsulate packets for it. However, the host itself does not
need any configuration.
There could be further ITRs and ETRs inside as well.
Note that all these IHxx hosts only have the IP address which is
LISP/Ivip-mapped to them. This is not like most mobile-IP
scenarios (all scenarios except Proxy Mobile IPv6?) where the
host has a care-of address and some special software to create a
tunnel to a home agent or some other device, where that tunnel
carries packets to and from the IP address the host keeps when
it moves from one edge network to another.
I suppose a host could have one or more of both kinds of IP
address. None of these hosts requires any special software.
All this applies to both IPv4 and IPv6, but I will use IPv4
example addresses.
I will assume a single Ivip system, but there could be multiple
such systems operating side-by-side, without any problems. Each
would have its own database and set of ITRs, but they could all
tunnel packets to the same ETRs in edge networks all over the
world, which require no coordination.
A Master-Subnet and the mapping
-------------------------------
There are likely to be multiple "master-subnets" handled by the
Ivip - maybe hundreds or a few thousand. Ideally they would be
larger subnets. As more and more address space is Ivip-mapped,
the previously isolated subnets would tend to adjoin each other,
so less BGP advertisements would be required.
Let's say the Ford Motor Company, which (as far as I know) is
currently assigned 19.0.0.0/8 but which does not advertise it
(and therefore doesn't use it publicly), decides to give control
of this of the Ivip system. That is 16,777,216 IP addresses.
Assuming the Ivip system doesn't also work with neighbouring
/8s, the Ivip system considers this as one of its
"master-subnets". Every ITR advertises this subnet (anycast)
and all the other "master subnets".
Here I give some example mappings for two tiny sections of this
large master-subnet.
IP address Host this Current mapping: the
to be mapped address is IP address of an ETR
mapped for
19.0.0.0 IH05 13.0.3.1 ETR3
1
2 IH06 13.0.3.1 ETR3
3 IH01 12.0.2.1 ETR1
4 IH08 14.0.8.8 ETR4
5 IH08 14.0.8.8 ETR4
6 IH08 14.0.8.8 ETR4
7 IH08 14.0.8.8 ETR4
8 IH02 12.0.2.1 ETR1
19.0.0.9 IH05 13.0.1.1 ETR3
. . . etc
19.75.0.0
1 IH03 12.0.2.1 ETR1
2
3 IH07 14.0.8.8 ETR4
4 IH04 13.0.1.1 ETR3
5 IH09 14.0.8.8 ETR4
6 IH02 12.0.7.7 ETR2
IH08 gets four contiguous IP addresses. They are on binary
boundaries, but there's nothing about the Ivip system which
makes this necessary. IH02 gets two IP addresses.
When the database changes the mapping for a large number of IP
addresses, say 1024 or so, it is generally faster and easier to
communicate this in a prefix format or as a range between two
addresses than to specify the change of mapping for each IP address.
If an ITR uses "pull" and enquires to the central database, or
some proxy server for it (perhaps a local "pull" database ITR?)
about 19.0.0.5, it would receive in the reply not just the
current mapping (14.0.8.8) but information indicating that the
same mapping applies for adjacent addresses 19.0.0.4 to 19.0.0.7
inclusive.
A multihomed host or router, not shown, could have two different
links such as via ADSL and a cable modem to Edge-B and Edge-C.
By changing the database entry for that host's or router's one
or more IP addresses from pointing to ETR2 to make them point to
ETR3, packets to the host would arrive on the Edge-C link rather
than from Edge-B.
Example packet flows
--------------------
---- Ordinary packets with their natural IP address.
~~~~ Packets encapsulated with an IP-in-IP header, so
the outer header's destination address is that
of whichever ETR the database currently specifies.
Normal <---> Ivip-mapped
H01->-BR1----TR1----ITR1~~~~~TR3~~~~TR2~~~~ETR1-->-IH02
H01-<-BR1----TR1--------------------TR2----ETR1--<-IH02
Left to right, the packet leaves Edge-A and is forwarded to the
nearest ITR. All ITRs advertise 19.0.0.0/8. ITR1 tunnels the
packet to 12.0.2.1, which is ETR1. ETR1 decapsulates it and
Edge-B's routing system delivers the packet to IH02.
This is a longer path than would be the case without Ivip,
because the packet takes a detour to reach the nearest ITR.
Ideally, there would be ITRs scattered through the core of the
network.
When the two edge networks are far apart, it doesn't matter much
if there are only one or a few ITRs somewhere in the path. All
that matters is that the packet does get to an ITR at some point.
If Edge-A and Edge-B were close to each other, but the nearest
ITR was a long way away, then the packets would travel on a
longer path than would otherwise be necessary.
With ITR functions located in transit routers, ideally they
would be one hop away from border routers, so there would be
little or no lengthening of the path.
A better result is if the ITR function is performed by the
border router, or an internal router. Then there is no longer
path - only a slightly longer part of the path with the small
burden of the IP-in-IP header.
In the reverse direction, H01's address is an ordinary
non-Ivip-mapped address so it is forwarded normally. ETR1 in
this case is acting as an ordinary border router.
Ivip-mapped <---> Ivip-mapped
In this case, I will illustrate packet flow between edge
networks which both have their own ITRs and ETRs, so there is no
increase in path length for using Ivip.
IH08->-ITR4~~~~~TR5~~~~~BR2~~~ETR3->-IH06
IH08-<-ETR4~~~~~TR5~~~~~BR2~~~ITR3-<-IH06
Ivip-mobile
-----------
All this means is that the ETR is a "TTR" (Translating Tunnel
Router). The database and ITRs don't need to know the packets
are directed to a TTR. I explained Ivip-mobile in greater
detail in previous messages.
The Mobile Host has some kind of Internet connection which gives
it a "care of" address. This is different from normal Ivip,
where the host has only (or at least only needs) the Ivip-mapped
address.
The Mobile Host establishes a two-way tunnel of some kind, maybe
IP-in-IP or some compressed, encrypted tunnel, with the TTR of
its choice. Ideally this would be inside the edge network the
host is currently connected to, or at its border router.
However the TTR could be at any location in the Net, including
inside other edge networks. All it needs is a normal IP
address. The host could be behind multiple layers of NAT - as
long as it can establish the tunnel.
There could be multiple independent networks of TTRs each with
TTRs in the core of the Internet, but ideally close to border
routers. Then a host can find one which is pretty close so the
packet paths generally won't be much longer than necessary.
Having the TTR in the same edge network is good because there is
no difference in path length in the core of the Net, and minimal
increase in path length when communicating with other hosts in
the same edge network.
- Robin
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram