[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RAM] Ivip (was ViP ...)
Hi Ved,
I agree with your summary of differences, except that with:
> (1) types of addresses used to identify end hosts; (home
> address vs. PI addresses)
One way I am envisaging this is that the PI address space is
really assigned (in a typically large subnet) to some central
system which runs the Ivip system and that system splits it up
into smaller subnets and individual IP addresses, which then
become effectively PI for whoever the central system assigns
them to.
Alternatively, maybe an ISP or AS-end-user with PI space
dedicates the space "Y" to the Ivip system. Then, it alone
controls how that is mapped. Maybe it maps the whole subnet to
a single ETR, which gives it portability (which it already has)
or perhaps some other benefit. This doesn't really reduce the
size of the BGP routing table, unless that subnet adjoins two
other subnets which are already mapped via Ivip. Then, what was
previously three entries in the global BGP routing table:
X >> BGP mapped to all the ITRs in the world.
Y >> BGP mapped to some border router on an edge network.
Z >> BGP mapped to all the ITRs in the world.
becomes a single entry:
X }
Y }>> BGP mapped to all the ITRs in the world.
Z }
This improves things for all the world's DFZ routers, and the
owner of this PI space can do what they like with their Y space,
changing the mapping, splitting it up etc. without causing any
fuss whatsoever for all the world's non-ITR BGP routers.
Most likely, the owner of the PI space will split up the mapping
as it likes down to single IP addresses, and then use them as it
wishes. Some it may use for its own purposes. Others it may
assign to customers. In that case, the customer does not really
have eternally portable PI space, because they still depend on
the existence, management expertise, billing system etc. of the
ISP or AS-end-user who owns the "master-subnet" Y, or the Y part
of the larger "master-subnet" XYZ. But as long as they maintain
good relations, the customer can use that IP address or subnet
via whichever edge network they like, because the customer
controls the mapping of their IP addresses or subnet.
Also, with:
> (2) where the mapping information is maintained in; (home
> agent vs. ITR, ETR, TTR)
The mapping information for Ivip or LISP is contained in a
central, or perhaps distributed, database. For each IP address
or subnet it is under the control of whoever the system has
assigned that IP address or subnet to. In a mobile situation,
or a multihomed situation, there may need to be rapidly executed
changes of mapping, when one link fails for instance. There
could be a number of systems which detect the changed situation
and use automatic, cryptographically secured, access to the
central database to change the mapping.
The central database information is either pushed to ITRs or the
ITRs have to pull the mapping, using a query and time-cached
response system.
Either way, the ITRs all over the world which are tunnelling
packets have the same mapping information for this particular IP
address or subnet.
The ETR is not involved in the mapping at all. It just receives
any IP-in-IP packet sent to it, and pops off the outer header to
reveal the original packet. (Maybe it does something with
hopcount.)
If the ETR is a TTR for a 2-way tunnel to the mobile host, this
TTR is still not directly involved in the mapping. Perhaps this
TTR would have functions to control the central database mapping
for this mobile host's IP address or subnet. However, I think
it would be better for some completely different, system to do
this. Then, if this particular TTR dies, that separate system
can detect this and change the database's mapping (and
therefore, within a few seconds ideally, the behavior of all the
world's ITRs) to an alternative TTR with which the mobile device
also has established a 2-way tunnel.
Also:
> (3) where tunnels start and where they end (home agents and
> mobile host vs. ITR and ETR or TTR)
being pernickety, I think someone reading this could think there
is a 2-way tunnel tunnel between an ITR and an ETR or TTR.
Mobile IP, as I understand it, apart from "route optimization"
involves a 2-way tunnel between the mobile host and the home
agent, or Mobile Anchor Point (MAP). I guess this may be
encrypted and compressed, but not necessarily.
The same kind of 2-way tunnel exists between an Ivip-mobile
mobile host and its TTR. The mobile host may also have tunnels
to other TTRs, but at any one time only one of them will be the
TTR which all the ITRs are tunnelling (1-way) packets to.
The Ivip mobile host must have its own IP address of some kind
and it must establish this tunnel to the TTR. It somehow should
choose one or more "nearby" TTRs, where "nearby" could mean
totally different TTRs in geographically and topologically
different parts of the Net, if the two links the mobile host are
via different edge networks, such as one GSM-GPRS edge network
and the other ADSL via NAT. In that case, the mobile host would
have two separate edge-network-provided IP addresses it uses for
tunnelling to its two TTRs.
The tunnelling from ITR to TTR is purely 1-directional, unless
the ITR also operates as the ETR in the reverse direction, which
would be likely if this ITR/ETR is a border router.
Assuming the correspondent host has an ordinary IP address,
packets from it to the mobile host enter a 1-way tunnel from the
ITR to the TTR. There, they pop out of the tunnel and are put
into a separate 2-way tunnel to the mobile host. There is
typically only one 2-way tunnel from the TTR to the mobile host.
However, the mobile host can establish multiple tunnels via
different edge networks (or even the same one, I guess) to that
TTR, or more likely to other TTRs.
There could be hundred or even thousand of ITRs at any one point
in time tunnelling (1-way) packets to the currently active TTR
for this mobile host. When the mapping in the database changes,
all the ITRs will switch their 1-way tunnels to the new TTR.
There will be a transition time, depending on how the ITRs do
their updates, so ideally the mobile host will receive packets
on all the tunnels it has to TTRs.
Outgoing packets from the mobile host to the correspondent hosts
will flow back along the 2-way tunnel to the TTR. Then, if they
are addressed to ordinary (meaning direct BGP-reachable) IP
addresses, the TTR will let them be carried by the ordinary BGP
system to the correspondent hosts. If the destination address
of a correspondent host is Ivip-mapped, the TTR may act as an
ITR and encapsulate it, then let it be carried by normal means
to the ETR which is currently the ETR for that correspondent
host. (Except for when that ETR is the same router as this TTR.)
So the flow of packets from correspondent hosts, left to right,
to the mobile host MH1 is like this:
[CH1]-----(ITR1)-------------(TTR1)~~~~~~~~[MH1]
/ | \
[CH2-ITR]--------(BR1)------/ | \~~~~~~~~[MH2]
ETR /
/
[CMH3]~~~~~~(TTR2)----------/
CH1's packets are raw to ITR1, 1-way tunnelled to ITR1 and then
2-way ~~~~ tunnelled to MH1.
CH2 has its own ITR encapsulation function, so there is a 1-way
tunnel from it to TTR1 where it joins the 2-way tunnel to MH1.
CHM3 has a 2-way tunnel to its TTR2, which sends on a 1-way
tunnel to TTR1 where it joins the 2-way tunnel to MH1. Traffic
back from MH1 to CMH3 goes on a 2-way tunnel to TTR1 and then on
a 1-way tunnel in the opposite direction (so maybe it is a 2-way
IP-in-IP tunnel) from TTR1 to TTR2. Then it goes on the 2-way
tunnel to CMH3.
Traffic between MH1 and MH2 is simply via two-way tunnels
through TTR1.
Traffic coming out of MH1 to CH1 or CH2 goes via a 2-way tunnel
to TTR1.
Let's say CH1 has an ordinary IP address. TTR1 simply pops the
packets addressed to CH1 out and forwards them by the ordinary
BGP system.
In this example, CH2 has an Ivip-mapped address. It has its
mapping set so all the world's ITRs' 1-way tunnel packets go to
the ETR which is implemented at the Border Router BR1 of its
edge network.
In this example, I assume TTR1 also acts as an ITR, so it sends
packets to CH2 via a 1-way IP-in-IP tunnel to BR1. BR1's ETR
function pops off the IP-in-IP header and the local routing
system is configured to forward the packet to CH2.
This is a long-winded way of saying that I think your phrase:
"where tunnels start and where they end"
doesn't capture the fact that these are one, two or three
different tunnels of different types in series, and some of them
are 1-way tunnels converging on a single TTR. I figure you
understand this, but I just wanted to point out that there isn't
really a single tunnel, for instance, between CH1 and MH1.
You wrote:
> Let's think if Ivip can get benefits from Mobile IP experience, or
> Mobile IP can get benefits from the Ivip idea.
I am sure Ivip or similar can benefit from people who work with
Mobile IP. I only have a cursory understanding of Mobile IP.
With either LISP or Ivip, the ITRs are like a massive,
steerable, set of reflectors which can beam packets to whichever
ETR/MAP/TTR the destination host specifies, or which some other
system decides should be used to maintain contact with the
destination host. All that is needed there is an ETR function,
and the ITR/Ivip system doesn't really know or care whether that
is an ordinary ETR or a MAP/TTR.
Mobile IP people probably dreamed of such a thing in the past,
but didn't have the impetus to make it happen. The crisis in
routing and addressing means that one or more global systems of
ITRs are probably going to be built. The ITR system would
enable Mobile IP to be Vastly(tm) more mobile and efficient
because the mobile host can pick and choose dynamically between
whatever TTRs suit it best as it moves.
In my last message I wrote it would be good if host operating
systems could perform the ITR functions of looking up mapping
and encapsulating the host's outgoing packets.
That won't work for most home or office desktop computers or
internal servers, because they will be behind NAT. The outgoing
packets will be to an ETR in the destination host's network and
the packets in the return direction will be from the IP address
of the destination host - so the NAT won't know how to rewrite
the packet and forward it to whichever of its local hosts
initiated the communication.
Generally, I think it would be friendly if operating systems had
an option to do these ITR functions, but first they need a
reliable way of determining whether they are behind a NAT.
I understand that ICE is the framework to do this within:
http://tools.ietf.org/html/draft-ietf-mmusic-ice
There are three circumstances where I think a host could and
maybe should encapsulate its own outgoing packets:
1 - If it has an ordinary BGP-reachable IP address.
2 - If it has an Ivip-mapped address and is using Ivip-basic.
3?- If it has an Ivip-mapped address and is using a 2-way
tunnel to a TTR (Ivip-mobile).
However mobile devices may have long link delays, so it could
take quite a while to get the mapping information, delaying the
application programs packets from being sent, adding to storage
requirements etc. Maybe, for any host using a TTR, it would be
best to expect the TTR to act also as an ITR, since it probably
has more memory and CPU grunt and has a much faster connection
to the Net to make queries. (Ideally, the TTR's ITR function
would have a full copy of the database.)
Maybe I am thinking of the term "mobile" too literally.
Generally speaking any host on a long-delay final link, such as
a GPRS or worse, GSM data call (~1 second ping times...),
especially a link which is congested or flaky, shouldn't be
busying itself with looking up mapping information and
encapsulating packets, which makes them longer.
Also, the NAT device's outgoing packets might well be
encapsulated by the NAT device - but only if that NAT device
could be sure it was the outside layer of NAT.
I don't think it matters whether the NAT device has its own
normal BGP IP address, or whether it has an Ivip-mapped address
- just as long as it is not behind a NAT itself.
I hope Ivip/LISP encapsulation in ITRs, in hosts or in NAT
egress ports themselves wouldn't upset STUN, TURN or ICE - all
of which are having enough trouble dealing with the unknown and
likely unpredictable behavior of one or more layers of suspected
NAT.
I guess that BEHAVE, RFC4787, which seeks to standardise NAT
behavior, also needs to be considered.
There are many scenarios to consider when trying ensure that a
major architectural change such as we are considering won't be
another can of worms like NAT.
- Robin http://www.firstpr.com.au/ip/ivip/
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram