[RAM] 3 Database - ITR update rates, mobility etc.

[Robin Whittle <[e-mail]>]

Here are some thoughts about user requirements for how quickly and
how often the mapping of an IP address or prefix will be, and some
technical and administrative approaches to achieving this.  I will
write about my Ivip ideas, but much of this probably applies to
LISP too.

I can think of these broad purposes for which Ivip is used to map
individual IP addresses or prefixes.

1 - Portability of single IP addresses (singlehomed)

    For end-users with a single link to an ISP or a single host
    which physically resides in the ISP's building, I think that
    portability of a single IP address shouldn't be a strong
    requirement, because any host or user network which depends on
    only one IP address should be easy to configure to another
    address when they use a different ISP.  There is no need to
    worry about continuity of communications etc.  It is just a
    matter of having one stable PA address or another and updating
    a zone file in a nameserver somewhere.  I suppose if they ran
    a hundred websites from that IP address, there would be a
    hundred zone files to change.

    However, maybe there is a company with a thousand branch
    offices.  Each one has a single IP address.  The company
    wants them to be portable IP addresses because it would
    be costly and disruptive reconfiguring all the routers
    for different IP addresses in other sites every time
    one of them changed to another ISP.

    Overall, I don't think this is an important goal of Ivip,
    except perhaps to support the branch-office scenario.

      Promptness: Within a few minutes would probably be fine.

      Frequency:  Very low - once every year or two.

      Activation: Manual.

      Traffic:    Potentially high - a single IP address could be
                  for a whole home or office LAN behind NAT.


2 - Portability of a prefix (singlehomed)

    There is more justification for portability with a prefix or a
    larger number of IP addresses (not necessarily on binary
    boundaries) because the user may face considerable cost and
    risk of disruption having to renumber routers and hosts when
    they move to a new ISP.

    I think this should be an important goal.

      Promptness: Within a few minutes would probably be fine.

      Frequency:  Very low - once every year or two.

      Activation: Manual.

      Traffic:    Potentially very high.  Could be an entire
                  university, hospital, corporation etc. or
                  at least part of their total system, if
                  there are multiple sites, each with their
                  own subnet of Ivip-mapped addresses.



3 - Multihoming of a single IP address or prefix

    This goal implies portability, but requires rapid responses,
    ideally within a few seconds.  The shorter the better, but
    many networks can probably cope if there is a minute or two
    of down time in the rare (say every 6 months to a year)
    times when a link or some equipment fails and they need
    to switch the mapping to point to a second ETR in another
    ISP.

    I think this is the most important goal.  If we can achieve
    this reliably, then it will remove most of the pressure for
    tens to hundreds of thousands (ultimately millions) of
    businesses and other organisations to get an ASN, PI space,
    a multihomed BGP router, expertise etc. for the sole purpose
    of achieving multihoming so their network is always available
    and at the same addresses.

      Promptness: Ideally, a few seconds or within a minute.

      Frequency:  Very low - once every year or two.

      Activation: Probably some separate system, distributed
                  in multiple edge networks, or in some really
                  solid site in the "core", which constantly
                  monitors connectivity and is able to change
                  the database the moment one link, ETR, ISP,
                  fails.

      Traffic:    Potentially very high.


4 - Mobility, ideally with continuity

    I am thinking of a device like a laptop or 3G cellphone which
    get either a singe IPv4 address or a complete IPv6 /64 and have
    a variety of links to the Net, in different edge networks,
    with periods of no connection and with periods of having
    two or more connections.  For instance, a laptop could be
    plugged in with an Ethernet cable, including behind NAT, and
    this would be a link to the Net (via finding the nearest TTR)
    without any prior arrangement with the edge network.  At the
    same time, it could be using 802.11 to do the same via
    multiple edge networks, though I guess one at a time.  It would
    find another TTR, which is near to the mobile host's location
    in that edge network.

    Meanwhile, it could be using UMTS or GPRS to connect to a
    2.5G/3G cellular network.  All these links are likely to be
    via completely different edge networks, and in each case, the
    device needs to find a nearby TTR and make a two-way tunnel to
    it.  Some central controller system orchestrates by telling
    the mobile host which TTR to tunnel to, and by telling the
    TTR to expect it.  (These TTR systems do not need to be part
    of the Ivip system - they are just ETRs as far as Ivip is
    concerned.)

    The central control system for the particular commercial TTR
    network the mobile host is using will monitor connectivity
    through each of the currently active TTRs and controls the
    mapping of the Ivip-mapped address or prefix to one of the
    currently active TTRs.

    In principle, the same approach should also work when the
    mobile node has a connection to an edge network using
    the ETR-border, ETR-eternal or ETR-host scenarios, where
    the mobile host doesn't need a TTR, since the edge network
    supports its outgoing packets.

    The TTRs may or may not be in the edge network with which
    the mobile node has gained a temporary care-of address.

    If they are not in the edge network, then the end-user will
    need to pay for access to them.  There is no need for TTRs
    or commercial global systems of TTRs to be coordinated with
    the Ivip system.  So there can be competing commercial TTR
    systems, with secure access to their TTRs.  TTRs in an edge
    network could be open to all devices connected to that
    edge network, probably without any extra fee.


      Promptness: Ideally, fractions of a second or a few seconds.
                  Smooth handover when leaving a 3G cell and
                  switching to a home 802.11 link would be ideal.

                  In practice, I doubt that any general purpose
                  global, publicly run Ivip system is going to
                  be so responsive for glitch-free handover to
                  support VoIP to moving handheld devices.
                  The best place to handle that sort of agility
                  is in the mobile network itself.

                  I am not suggesting that every time some
                  all singing all dancing cellphone, MP3 player,
                  laptop, games machine (whatever) works best
                  from WiFi and then from 3G and then from WiFi
                  again that the Ivip database and all the world's
                  ITRDs need to know about it ASAP ~unless~ the
                  mobile user wants to pay for every such change!

                  Maybe there could be multiple competing
                  commercial networks of ITRs and TTRs which
                  are optimised for this very fast switching.
                  They could also tunnel traffic to ordinary
                  ETRs, and not all the TTRs they use need
                  to be owned by the same operator.  Assuming
                  there was a consistent technical standard
                  for TTRs, the commercial system could use
                  its own TTRs or TTRs in edge networks.

                  When the mobile node loses all its links,
                  which will be a frequent occurrence, the
                  system needs to be able get packets to
                  a newly chosen TTR within a few seconds,
                  and ideally, the newly connected mobile
                  node needs to be able to contact a central
                  control system within a few seconds and
                  set up a tunnel to a TTR within a few
                  seconds.  Ideally, 5 to 10 seconds after
                  gaining any kind of care-of IP address,
                  IPv4 or IPv6, the mobile node should be
                  fully connected via a nearby TTR.

      Frequency:  Potentially very frequent.  The end-user
                  must pay per change.

      Activation: Probably some separate system, distributed
                  in multiple edge networks, or in some really
                  solid site in the "core", which constantly
                  monitors connectivity and is able to change the
                  database the moment one link, ETR, ISP etc.
                  fails to cause the traffic to be tunneled to
                  an alternative ETR.

      Traffic:    Presumably lower than the above scenarios
                  since highly mobile devices generally use
                  3G or 802.11 links and are not servers or
                  sites full of servers.


There is no difference for the ITR whether it is tunneling packets
to an ETR, a TTR or a host which does its own ETR functions.  So
there's no reason regarding the ETR/TTR why a single Ivip system
can't be used for all the above purposes at once.

However, there are big differences in requirements for Promptness,
Frequency and Traffic.

All but the single-homing purposes ideally need a Promptness time
of a few seconds or less.  Since multihoming is the most important
purpose, I think the Ivip system needs to be able to change its
mapping in a few seconds, even when there is no anticipation that
a change might be required.  For instance, a multihomed site might
work fine for months or years on a link to ISP-A and its ETR, but
if that fails, the Ivip system should ideally respond within
seconds - or at least within a minute or so.


In principle, a push-ITR can respond very rapidly to database
changes.  Depending on the system of servers which replicates the
stream of updates, I guess a few seconds may elapse between the
command being made to the central database and all the ITRDs
switching their tunnels to a new ETR.   In message 5 I discuss
cache-based ITRs, with pull and notify, rather than push.

 - Robin         http://www.firstpr.com.au/ip/ivip/





_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram