[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RAM] Ivip (was ViP ...)
Robin:
Thanks for your detail clarification. I just add a few points here.
In my opion, the difference between the mobile IP and Ivip is based on
the following points:
(1) types of addresses used to identify end hosts; (home address vs. PI
addresses)
(2) where the mapping information is maintained in; (home agent vs. ITR,
ETR, TTR)
(3) where tunnels start and where they end (home agents and mobile host
vs. ITR and ETR or TTR)
Home agents are confined to home networks whereas ITRs can be
distributed in the Internet. Home agents advertise the reachability to
mobile host's home addresses whereas ITRs advertise reachability to
Ivip-mapped addresses. Ivip assumes that many ITRs may advertise the
same prefix.
Mobile IP research is quite matured by now. From this experience, we can
explore if Mobile IP can be extended to cover the Ivip type distributed
mapping system by forming a federation of home agents and advertising
many network prefixes by each member of the federation. Ivips
distributed ETRs share some common features with the MAPs (mobility
anchor points) of hierarchical mobile IP. (How about pushing MAPs
further deep into the network, so that they function as TTR?)
Let's think if Ivip can get benefits from Mobile IP experience, or
Mobile IP can get benefits from the Ivip idea.
Ved
> -----Original Message-----
> From: Robin Whittle [mailto:rw at firstpr.com.au]
> Sent: Sunday, June 17, 2007 8:49 PM
> To: ram at iab.org
> Cc: Christian Vogt; Ved Kafle
> Subject: Re: [RAM] Ivip (was ViP ...)
>
>
> I am replying to Ved's and Christian's comments in "Re: ViP:
> Anycast ITRs in the DFZ & mobile tunnels", with "ViP" changed
> to "Ivip" (eye-vip).
>
> I apologise for the length again. It would probably not be
> so hard to describe Ivip to one person, face-to-face, with
> conversation and hand-drawn diagrams. Trying to do it for a
> bunch of people via email takes more words.
>
>
> VK> To me, the Ivip approach looks similar to the network mobility
> VK> (nemo) support approach being discussed in the IETF nemo WG. In
> VK> nemo, the mobile router's home agent advertises the
> mobile network
> VK> prefix such that the packets sent by a correspondent node to an
> VK> address belonging to the nemo prefix go to the home
> network of the
> VK> mobile network, where the home agent tunnels them to the current
> VK> location of the mobile router. The mobile router decapsulates and
> VK> forwards the packets to the addressed node.
>
> I threw this proposal together quickly without checking other
> protocols - and I don't claim it is highly original.
>
> There are two aspects to the proposal at present:
> "Ivip-basic" and "Ivip-mobile".
>
> Ivip-basic
> ----------
>
> H1---(ITR1)---\
> / \
> H2-/ \
> (ETR1)----RH
> /
> H3---(ITR2)----/
>
> (ITR3) (ETR2)
>
>
> Sending hosts H1, H2 and H3 are assumed to have ordinary IP
> addresses, reachable via BGP. The ITR function is generally
> performed in border routers or transit routers, but can be
> performed in interior routers of the edge network.
>
> Packets from the Receiving Host RH flow by ordinary BGP
> routers back to the sending hosts. If a sending host is also
> using an Ivip-mapped IP address, then the same process occurs
> in reverse, with the packet sent by RH finding their way to
> the first ITR, probably at or near the border router of its
> edge network, and being encapsulated and sent to the ETR for
> the host on the left side. None of this is shown in the
> above diagram.
>
> ETRs are provided by ISPs, or the AS-end-users who run the
> edge networks. They only serve receiving hosts in those
> edge networks.
>
> How does the edge network know that the decapsulated
> packets emerging from the ETR must be sent to a particular
> host in its network? The ETR and the routers nearby
> need to be configured to look out for this IP address,
> or the Ivip-mapped subnet, and route it internally to the
> receiving host. With Ivip, these packets are addressed to a
> prefix (a large subnet I call the "master-subnet") which is
> advertised in BGP. With LISP, they are not.
>
> To support either LISP-mapped or Ivip-mapped IP addresses,
> the edge network needs not only an ETR to decapsulate the
> packets, but it needs a routing rule specific for that IP
> address or subnet which directs packets addressed to that
> address or subnet to wherever the particular host is located.
>
> This is probably a non-trivial task for an edge network,
> but the are being paid by their customer with the host which
> uses LISP-mapped or Ivip-mapped addresses.
>
>
> Assuming a single global Ivip system, the ITRs may be
> provided by various operators, but work as a single system,
> without any constraints on whose packets they will encapsulate.
>
> What may be unique about Ivip is that these ITRs are numerous
> and located (usually) at border or transit routers where any
> sender's packets will eventually be sent to one. What may
> also be unique is the idea that all these ITRs advertise the
> same set of prefixes: whatever "master prefixes" the Ivip
> system handles.
>
> Generally, these "master prefixes" are split into many
> smaller sections, each with a different mapping to an ETR.
> This works fine down to individual IP addresses. There needs
> to be a single central system for controlling the mapping -
> and every ITR has an up-to-date copy of this database.
>
> Ivip-basic is a one-way, public, system. Ideally it would be
> provided for free, but there probably needs to be some fees
> for running the ITRs and administering the database. These
> could be paid for by the Ivip "customers" - those individuals
> and organisations etc. who pay for one or more IP addresses
> in the system.
>
> As shown above, the ETRs are in the edge network in which
> RHs are located or connected to.
>
> Each RH in this depiction has a single link to its ETR, but
> an RH could easily have links to two ETRs, especially in two
> edge networks, to achieve multihoming.
>
>
> Ivip-mobile
> -----------
>
> Ivip-mobile is an extension of the above, but would probably
> always be a commercial service. There could be any number of
> Ivip-mobile operators. Each would have a set of special ETRs
> called TTRs (Translating Tunnel Routers). These TTRs are in
> general either at border routers or more likely amongst the
> transit routers. TTRs could also be in edge networks.
>
> H1---(ITR1)---\
> / \
> H2-/ \
> (TTR1)~~~~~~~~MH
> / /
> H3---(ITR2)----/ /
> /
> (ITR3) (TTR2)~~~~/
>
>
> The Mobile Host (MH) could be behind NAT and always
> establishes an encrypted 2-way tunnel to at least one TTR.
> (I am assuming an encrypted and compressed 2-way VPN-like
> tunnel, but I guess it could also be done by simple two-way
> IP-in-IP tunnelling.)
>
> The Mobile Host may establish tunnels to multiple TTRs,
> including using completely different links, such as ADSL and
> GPRS radio.
>
> The Ivip system maps the MH's IP address (or prefix) to one
> of the TTRs, so all the encapsulated packets from the world's
> ITRs arrive at that TTR. Some central monitoring system
> could detect that one TTR is dead, or that its link to the MH
> is dead, and then the mapping could be changed to the other
> active TTR.
>
> To the Ivip system, which is really the ITRs and their
> controlling database, there is probably no way of telling
> whether the currently mapped-to IP address points to an ETR
> which is for Ivip-basic (meaning the RH is in an edge network
> and the ETR is a border or internal router of that edge
> network, with packets flowing back independently of these
> arrangements) or whether the mapped-to IP address points to
> a TTR.
>
> A TTR is simply an ETR which the MH tunnels to, and which
> therefore also acts like the MH because this TTR is where the
> MH's outgoing packets are first let loose on the Net.
>
> With mobile-IPv6 (as I understand it), there is exactly one
> router which the MH tunnels to - it is the router which runs
> the LAN in which the MH's home address is located.
>
> Mobile-IPv6 can also cause corresponding hosts (H1 to H3
> etc.) to send packets to and from the MH directly, rather
> than using the home router. This is more efficient, but
> requires the corresponding host to have special mobile-IPv6
> capabilities.
>
> Ivip-mobile is very different from mobile-IPv6 in that the MH
> can choose one or more TTRs to tunnel to. Ideally it will
> choose the ones which are closest to its current location.
> Also, there is no "home IP address" on a LAN, as there must
> be with mobile-IPv6.
>
> As far as I know, mobile-IPv4:
>
> http://www.mip4.org
>
> relies on a "home-router" and home IP address too.
>
> Likewise, as far as I know, NEMO does as well:
>
> http://tools.ietf.org/html/rfc3963
> http://tools.ietf.org/wg/nemo/
>
> Also, like LISP, Ivip works with single IP addresses or any
> number of IP addresses. I am not sure whether mobile-IPv6,
> mobile-IPv4 support subnets, but I guess they could do it as
> individual arrangements for multiple IP addresses. NEMO
> supports subnets.
>
>
> The reason a figment of our imagination like Ivip can boldly
> invoke a worldwide network of ITRs while mobile-IPv6/4 cannot
> is that now we are desperate.
>
> If we don't do something on a grand scale such as this, we
> will all be doomed to paying for endless upgrades to all the
> Internet's transit and multihomed border routers as the BGP
> routing table grows to 500,000, 1,000,000, 2,000,000 etc.
>
> LISP boldly invokes at least one ITR in every edge network
> which has a host which needs to communicate with a host or
> network whose IP address or subnet is handled by LISP. In
> practice, for LISP-mapped IP addresses to be attractive to
> anyone, this means most edge networks must have one or more ITRs.
>
> Ivip less boldly invokes ITR functions broadly distributed in
> the border routers and transit routers. I can get away with
> this, as can the LISP authors, because we are desperate.
>
> Both LISP and Ivip require the relatively modest ETRs to be
> installed in the edge network of any host which has its
> address or subnet handled by LISP or Ivip.
>
> Ivip could also exist as multiple independent networks of
> ITRs, each with its own "master-subnets" and its own central database.
>
> Since Ivip involves a bunch of souped-up routers at border
> router and transit router locations, it is not much more of a
> step to have some of these, or perhaps separate networks of
> routers, performing TTR functions. Each TTR system could be
> entirely independent of other TTR systems, and of the one or
> more ITR systems (provided the TTR did not also implement ITR
> functions). The multiple TTR systems could compete and
> provide commercial services to the customers who they provide
> Ivip-mapped address space for.
>
> Please see my previous long message where I write about
> my conception of Ivip or LISP, which I think is different of
> Dino's "BYO address space" vision for LISP.
>
> If there was a single Ivip system of ITRs, presumably the
> system would not be allowed to fail, so any address space it
> hands out via its mapping functions would be essentially
> "Provider Independent".
>
> If there were competing Ivip systems, then all of them,
> apart from perhaps one "universal public" one, would be
> dependent on some company, ISP etc. and be for-profit - so
> the IP address still depends on that company.
>
> However, in both cases, where the customer whose address is
> mapped by these systems chooses to attach to the Net (their
> choice of ISPs) is completely unrelated to the Ivip system(s).
>
> Any TTR systems could be independent of the Ivip systems.
>
> A customer could choose to use any number of competing TTR
> systems. They have nothing to do with IP addresses, since
> their TTRs are only of value to the customer if the ITRs
> tunnel packets to the TTRs, and since the customer pays for,
> or has control of, the mapping of their IP address, the
> customer only depends on the ITR system for the security of
> "tenure" of this address - and not at all on any TTR systems it uses.
>
>
> Each TTR could also act as an ITR for that system's
> "master-subnets". If there was a single, global, system of
> ITRs, it would be good if the privately run TTRs also acted
> as ITRs within the global Ivip system.
>
> Otherwise, packets would have to first find an ITR and be
> tunnelled to the TTR when they are going to an Ivip-mobile host.
>
> For simplicity, the following assumes there is a single
> set of "master-subnets" (AKA "master-prefixes") which are
> handled by a single Ivip system which includes an Ivip-mobile
> function as well.
>
> It is likely that a router which performs TTR functions will
> also act as an ITR.
>
> H1------(TR)------------(ETR1)------RH1
> \
> MH2~~~~~~(TTR1)~~~~~~~~MH1
> / \
> H2----(ITR1) \
> / (TR)
> H3----/ \
> \
> MH3~~~~~~~~~~~(TTR2)
>
> H1 and H2 have ordinary BGP routed IP addresses. Packets
> sent from H1 to MH1 are received by TTR1 which acts like an
> ITR. Ordinarily, an ITR encapsulates the packet and tunnels
> it to the ETR to which the destination (MH1) IP address is
> mapped to. In this case, TTR1 is the destination ETR, so
> there is no need to encapsulate the packet. It is simply
> placed on the VPN 2-way tunnel ~~~~~~~~ and sent to MH1.
>
> Packets from MH1 to H1 follow the reverse path - they come
> out of the VPN tunnel at TTR1 and are forwarded via normal
> BGP routing back to H1.
>
> The same would be true between H1 and MH2.
>
> Packets from H2 to MH1 (or MH2) would be encapsulated by ITR1
> and tunnelled (one way, IP-in-IP) to MH1's ETR, which is
> TTR1. TTR1 decapsulates them and sends them on the VPN tunnel to MH1.
>
> Packets from MH1 to H2 pop out of the VPN tunnel at TTR1 and
> use ordinary BGP forwarding to get to H2.
>
> RH1 has an Ivip-mapped IP address. It is not using
> Ivip-mobile - just Ivip-basic.
>
> In this diagram, the nearest ITR to H1 is TTR1. When H1
> sends a packet to RH1, it is forwarded by the TR transit
> router to TTR1, and encapsulated. TTR1 sends the packet in a
> 1-way IP-in-IP tunnel to ETR1 (at the border of, or within an
> edge network), which forwards it within the edge network to RH1.
>
> Packets from RH1 must be accepted by the border router of its
> edge network (which could be ETR1 or some other router not
> shown) and are sent via ordinary BGP forwarding to H1.
>
> A packet from MH3 to MH1 goes via 2-way VPN tunnel to TTR2
> where it is encapsulated and sent on a 1-way IP-in-IP tunnel
> to MH1's ETR, which is TTR1. This decapsulates it and sends
> the packet along its 2-way VPN tunnel to MH1. Packets going
> from MH1 to MH2 follow exactly the opposite path, with a
> 1-way encapsulated IP-in-IP tunnel from TTR1 to TTR2.
>
> Mobile-IPv6 doesn't assume anything about routers, except its
> home router. It doesn't assume anything about corresponding
> hosts, since ordinary hosts can simply communicate with the
> mobile host as if it was at its home location, with the home
> router tunnelling to and from the mobile host, wherever it is.
>
> Ivip doesn't assume anything about corresponding hosts, or
> the host whose IP address or subnet is mapped by Ivip.
>
> Ivip does assume there is a system of ITRs - ideally all
> around the Net at border routers and transit routers.
>
> Ivip requires the receiving host have at least one ETR. For
> Ivip-basic, there will be one ETR in the edge network where
> the receiving host is currently connected. This mapping can
> be switched to another ETR, for instance for multihoming.
> There could also be load balancing between multiple ETRs, as
> LISP proposes.
>
>
> VK> Analogy:
> VK> (1) Ivip routers are similar to the mobile network home agents,
> VK> except that the home agents are confined to home networks
> VK> where as Ivip routers may be distributed in the Internet.
>
> Yes, but the TTRs are similar to the home-agent. With
> Ivip-mobile the mobile host's IP address doesn't have a home
> anywhere. Packets from ordinary IP addresses are tunnelled
> by ITRs to the currently chosen ETR, and that ETR (in the
> case of a mobile host) is a TTR which the mobile host has a tunnel to.
>
> This means that wherever the mobile host is and wherever the
> corresponding hosts are, assuming there are plenty of ITRs
> and TTRs, the total path length will be the same as, or not
> much longer, than without Ivip.
>
> VK> If we suppose that home agents can be distributed like Ivip
> VK> routers, then these two approaches are exactly the same.
>
> In my perhaps faulty understanding of mobile-IPv4,
> mobile-IPv6 and NEMO, this could not occur, because the
> home-agent router needs to be connected to an edge network
> whose border router advertises the address range the router
> handles. It can't be moved somewhere else, assuming that
> router only handles a part of the subnet its edge network
> advertises, because to do so would create two or three BGP
> advertisements instead of one.
>
>
> VK> (2) Ivip's ETRs are similar to nemo mobile routers, which update
> VK> Ivip routers (home agent) with the tunnel-end addresses.
>
> I read the first ten pages of NEMO's RFC3963. NEMO extends
> mobile-IPv6 with a "mobile router". This is somewhat like a
> mobile-IPv6 mobile node, except it is a router which has
> links to the multiple mobile hosts. Also, there is no "route
> optimization" as in mobile-IPv6 where capable correspondent
> nodes can send packets directly to and from whatever IP
> address the mobile host (or NEMO mobile router) is currently
> located at. So with NEMO, all traffic to the multiple mobile
> nodes goes through the fixed location (I assume) home agent
> router, and then via a two-way tunnel to the mobile router
> - which can flit from one IP address to another, taking its
> flock of mobile nodes with it.
>
> I don't think there is much resemblance between any of these
> pre-existing mobile systems and either Ivip-basic or its
> Ivip-mobile extension.
>
> Ivip's notion of large numbers of public ITRs and TTRs (by
> paid-for access I guess) with the mobile host choosing which
> TTR to use at any time, does not seem to have a parallel in
> these pre-existing mobile systems, which assume a fixed
> home-agent router.
>
> Ivip-mobile will only be possible because there will be
> a global system of ITRs which tunnel packets to any
> BGP-reachable IP address is currently selected to act as the
> ETR for the mobile-host's Ivip-mapped IP address.
>
> Without that global ITR system, steering packets anywhere on
> the NET, the pre-existing technologies mobile-IPv4/6-NEMO
> must rely on all packets going to a home-agent router, except
> for mobile-IPv6 which can use "route-optimization" and set up
> smart-enough correspondent nodes to send packets directly to
> and from the mobile node.
>
> LISP could just as easily be extended as I suggest with
> Ivip-mobile. Ivip is similar to or identical to LISP, or at
> least some type of LISP, except that it should be easy to
> incrementally deploy and except that it does require all its
> "master-subnets" (hopefully few and large) to be advertised in BGP.
>
>
> VK> (3) In nemo, a bidirectional tunnel is set up to avoid packet
> VK> filtering at border routers. Whereas in Ivip, it is assumed
> VK> that the BRs forward packets with Ivip-mapped addresses.
>
> In Ivip-basic, with the receiving host semi-permanently in an
> edge network, I assume that the edge network's routers are
> programmed to allow packets from its IP address to be sent to
> the global BGP system. If not, then the receiving host would
> need to use Ivip-mobile with a TTR outside this edge network.
>
> I tend to think of the TTR function being implemented within
> routers which are already transit routers, or in routers
> which are located at peering points and are primarily
> connected to transit and border routers. However a TTR could
> be a border router or inside an edge network, as long as that
> border router or edge network allowed egress of the outgoing
> packets (which could have almost any source address) to the
> BGP routing system.
>
>
> VK> There are some well known problems associated with such anchor
> VK> point-based approaches, such as increased packet delivery delay,
> VK> non-optimal routing, tunnelling overhead, possibilities of single
> VK> point of failure, etc. To avoid these problems, route
> optimization
> VK> mechanisms are being investigated in the nemo WG.
> Shouldn't we look
> VK> for the ID-loc split solutions that avoid such problems
> as much as
> VK> possible?
>
> Ivip-basic isn't at all like these pre-existing mobile
> protocols. The Ivip-mobile extension only loosely resembles
> them, because there is no one fixed home agent.
>
> Altogether, Ivip-basic and Ivip-mobile should enable packets
> to flow without much extra distance or hops. There is still
> a tunnelling overhead, and perhaps problems with MTU limits.
>
>
> Christian Vogt quoted Ved Kafle and responded:
>
> VK> To me, the Ivip approach looks similar to the network mobility
> VK> (nemo) support approach being discussed in the IETF nemo WG. ...
> CV>
> CV> Absolutely. This is what I was saying.
>
> I think Ivip is very different from NEMO etc.
>
>
> VK> Analogy:
> VK> (1) Ivip routers are similar to the mobile network home agents,
> VK> except that the home agents are confined to home networks
> VK> where as Ivip routers may be distributed in the Internet.
> CV>
> CV> Actually, Ivip routers are confined in the same way as
> home agents
> CV> in that both can only support "home" prefixes that correspond to
> CV> their topological location in the Internet.
>
> As I explained above, and in a long message which started
> this thread, this is not the case. There are lots of TTRs to
> choose from, so ideally the mobile node will choose one close
> to it. This is only possible because there is a global
> network of ITRs, acting like a coordinated bunch of mirrors,
> tunnelling all the mobile node's traffic to this TTR, another
> TTR or wherever the mobile node (or some other control
> system) tells the ITRs to tunnel the packets to.
>
>
> CV> After all, the idea of Ivip routers is to have them advertise
> CV> sub-prefixes from their ISP's global routing prefix so that the
> CV> sub-prefixes can be aggregated with the global routing
> prefix and do
> CV> not require a separate slot in the DFZ routing table.
>
> An Ivip ITR is one of many which advertises one or more
> "master prefixes". Each ITR attracts packets addressed to
> these prefixes and tunnels them off to potentially millions
> of different ETRs. A TTR acts like an ETR as far as the ITR
> system is concerned. Its just that a TTR is probably not in
> an edge network - and it connects to the host which has the
> Ivip-mapped IP address via a two-way tunnel.
>
>
> VK> There are some well known problems associated with such anchor
> VK> point-based approaches, such as increased packet delivery delay,
> VK> non-optimal routing, tunnelling overhead, possibilities of single
> VK> point of failure, etc. ...
> CV>
> CV> Right. And things don't get better if we do the
> indirection for all
> CV> hosts, not just mobile hosts or hosts moving with mobile networks.
>
> Other than the central database, I don't think there is a
> central point of failure for Ivip-basic or its Ivip-mobile
> extension. Assuming the mobile host has a BGP reachable IP
> address, or is behind a NAT firewall which has such an
> address, it can set up a two-way tunnel to one or more TTRs.
> If one goes down, it can use another. Ideally it would use
> nearby ones.
>
> Ivip-basic, like LISP, relies on the receiving host having a
> connection to a particular ETR. LISP, Ivip-basic and
> Ivip-mobile all enable the receiving host to set up links to
> multiple ETRs and then (directly, or by some automatic
> system, since the receiving node could be out of contact
> after the failure of its active link) the ITRs can all be
> told to tunnel packets to whichever ETR is currently used.
>
> This is genuine multihoming, including for Ivip-mobile - if
> the two links to the two TTRs are by physically different networks.
>
>
> VK> To avoid these problems, route
> VK> optimization mechanisms are being investigated in the nemo WG.
> VK> Shouldn't we look for the ID-loc split solutions that avoid such
> VK> problems as much as possible?
>
>
> CV> Without an intention to prefer either mechanism, I just
> want to note
> CV> that the advantage of Ivip is a better transition path,
> whereas LISP
> CV> performs better from the perspective of packet
> propagation latencies
> CV> and fault tolerance.
>
> Thanks for agreeing with what I think is the most important
> difference - that Ivip looks like it would be easier to introduce.
>
>
> CV> As a matter of fact, LISP is nothing else but route
> optimization (in
> CV> Mobile IPv6 terms) for Ivip.
>
> LISP has the ITR function inside or at the border of the
> edge network. Ivip typically has the ITR function at the
> border router or amongst the transit routers.
>
> With LISP, if the ITR function is at the border router
> or in an internal router which is on the shortest path
> between the sending host and the border router, then the
> total path likely to be the same as for a direct packet
> (other than a potentially longer path in the destination
> edge network if the ETR isn't exactly on the shortest
> path to the receiving host).
>
> With Ivip, the same is true if either of the following
> typical conditions is true:
>
> 1 - The ITR function is at the border router of the
> sending edge network.
>
> 2 - The ITR function is in a transit router which is on
> the shortest path towards the destination edge
> network's border router.
>
> So Ivip's total path length would only be longer than LISP's
> if the ITR function was not in the sending edge network's
> border router but in a transit router (or perhaps another
> border router of another edge network) which is off the
> shortest path to the destination network's border router.
>
> If Ivip or some similar system is adopted, before long, any
> ISP or AS-end-user network with any substance would want to
> install the ITR function at its border routers and/or at
> internal routers - to reduce the processing load on the
> border routers. They would want to do this so their outgoing
> Ivip-mapped packets do not depend on anyone else's external ITRs.
>
> A fully hardware optimised ITR, with its big database and
> need for constant updates from the central Ivip database,
> could be quite expensive. But it has to be provided either
> by the edge network, or by some ISP or transit provider
> the edge-network uses for its upstream links.
>
> I am not sure how the economics would work best. Maybe
> for smaller ISPs and AS-end-user edge networks it would
> be better to pay their upstream provider to handle the
> ITR function.
>
> Over time, as ITR-capable hardware costs reduced, more and
> more smaller ISPs and AS-end-user networks would probably
> find it better to run their own ITR rather than pay to use
> their upstream provider's ITR.
>
> I think only those smaller edge-networks would not run
> ITRs in the long-run. The most important thing is that Ivip
> could start running with just a handful of ITRs somewhere in
> the Net. Ideally there would be multiple ITRs for each country.
>
> The only significant path-length increases with Ivip would
> occur when the sending edge network is nowhere near an ITR.
>
> This would occur in the early days of introduction.
>
> But once Ivip became established and a significant amount
> of traffic was reliant on ITRs, competition between
> upstream providers would cause them to ensure there were
> ITRs in upstream paths, rather than off to one side somewhere.
>
> There are two other situations of practical interest, in
> which Ivip would also produce no increase in total path
> length.
>
> Firstly, it is perfectly possible to install Ivip ITRs inside
> edge networks. Then, the situation would be identical to
> LISP: assuming the ITR was on the path from the sending host
> to the border router, there would be no extra path length.
>
> Edge networks could install internal ITRs to take the load
> off their border routers. However, this would slightly add
> to the traffic load inside the network, due to the IP-in-IP overhead.
>
> The second scenario is most likely to occur when the
> destination edge networks are very close or their routers are peers.
>
> If the sending edge network has no ITR, the packets are
> forwarded to the closest ITR, which is the border router of
> the destination edge network. This would work fine. That
> border router could encapsulate the packet and forward it to
> the ETR inside the edge network. There are a few variations
> on this . . .
>
> Firstly, maybe the border router is an ITR and the ETR is
> a separate router inside the network - but the border router
> has a route for the destination host's IP address already
> programmed into it, as part of the whole destination edge
> network being set up to send packets from the ETR to the
> destination host. Then, there would be no actual involvement
> of Ivip, other than this border router was advertising the
> whole "master-subnet" of which this destination IP address
> was a part. The fact that this border router received the
> packet means that it forwards it towards the destination host
> in its network. The ETR wouldn't be involved and there would
> be no encapsulation.
>
> This would be the case if the border router's FIB applied the
> local routing rules before the ITR function's rules - which it should.
>
> Secondly, if the border router's FIB applied the ITR
> functions first, then it would tunnel the packet to the ETR
> and all would be well. (Unless the ETR was itself, in which
> case it should just forward the packet on the internal
> routing system.)
>
> In either case, there would be no increase in path length -
> above any detour inside the destination network to reach the ETR.
>
> If the sending host and receiving host are in the same edge
> network, and if the whole edge network has its routers
> programmed to handle the IP address of the receiving host,
> then Ivip is not involved at all.
>
> If the sending host was in some other part of the edge
> network where the routers didn't know about how to route to
> the receiving host, then the packet would be forwarded
> towards the border router. En-route, if it encountered an
> ITR, all would be well. If the edge network had no ITR, then
> the packet would be forwarded out the border router and would
> find its way to the nearest ITR. Then it would be tunnelled
> back to the same edge network's ETR. This would definitely
> add to the path length!
>
>
> Here is a potential gotcha.
>
> Lets say a host has two links to ETRs in two edge networks
> A and B, and it is currently using the link to A. This means
> the global Ivip system's ITRs are tunnelling packets to A's ETR.
>
> Both edge networks must have their routing systems set up
> to forward packets for the recipient host's Ivip-mapped
> address (or subnet) to the link which leads to the receiving
> host. (For instance a router or a host computer with two
> fibre links to two ISPs.)
>
> Let's say there is a sending host in edge-network B. That
> sending host's packets will flow directly along the link from
> B to the recipient host, even though the recipient host is
> currently using the link to ISP for its connection to the Net.
>
> For absolutely full connectivity, either:
>
> 1 - The receiving host needs to accept packets from both
> links at once.
>
> or
>
> 2 - The network B needs to not forward the packets to the
> link to the recipient host until it somehow knows that
> the recipient host has switched to using network B's
> ETR.
>
> Option 1 sounds best.
>
>
> I apologise for the length of my messages. I hope that
> if you read them fully, you will understand Ivip and my
> idea of what LISP can be used for in a way which is
> independent of NEMO, mobile-IPv4/6 etc. I think the
> differences are more important than any similarities.
>
> - Robin
>
>
>
>
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram