Ivip network elements

Robin Whittle rw@firstpr.com.au 2010-04-01

To the main Ivip page

From my RRG message on 2010-03-31:

  IRON-RANGER, an interesting Core-Edge Separation (CES) architecture

Ivip's network elements are in logical groups:

   ITR        QSC          QSR        QSA      ETR
   DITR       (Optional)

All but the ETR would share some common code elements. 
These "network
elements" could be "roles" - so a single server or router could perform
  such roles.  Generally I refer to these as separate classes of
device.  All these could be implemented as software on a COTS (Commercial
Off The Shelf) server.

Please see the text and diagrams at:


for how all these fit together, and for how initial services and
substantial scalable routing benefits will result without any ISP
investment, just by using DITRs, QSAs and ETRs.  Please also see:


   ITR     Learn about all the "edge" space, such as by getting
           a list of MABs, from their local QSR (perhaps via
           one or more intermediate QSCs) - or a simpler list
           which doesn't mention individual MABs when two or
           more are adjacent.

           Advertise this "edge" space in the local routing system
           and so tunnel each received traffic packet which is
           addressed to an "edge" address to an ETR.

           If the ITR has no cached mapping matching the destination
           address, buffer the packet and send a Map Request (which
           includes a nonce and the packet's destination address) to
           a local QSR or QSC.  (Each ITR will auto-discover, or be
           configured with, the address of 3 or so QSRs or QSCs
           which it uses for all its Map Queries.  The ITR needs
           to resend the Map Request if no Map Reply arrives within,
           say, 80ms.)

           The Map Reply specifies a micronet of SPI (Scalable PI =
           "edge" space) and a single ETR address, with a caching
           time.  When this mapping arrives, tunnel the buffered
           packet to the single ETR specified in the mapping.

           If the mapping is already cached, when the traffic
           packet arrives, tunnel the packet to the single ETR
           specified in the mapping.

           Cache this mapping for the caching time, together with
           the nonce of the original request, and accept Map Update
           messages from the QSR or QSC, which will be secured by
           the same nonce.  These updates will either change the
           ETR address or tell the ITR to flush this micronet from
           the cache.  (The latter would be for when the existing
           micronet is split or joined to some other micronet - so
           if the ITR is still handling packets addressed to the
           old micronet, it will buffer them and make a new Map
           Request, to receive mapping for a different micronet which
           covers the destination address.)

           ITRs can be in ISP and EUNs, including EUNs using
           conventional edge space and those using SPI "edge"
           space.  So ITRs can be on a micronet address - SPI "edge"
           space.  ITRs cannot be behind NAT in the current design.

           ITRs work with ETRs to handle PMTUD problems caused by

   DITR    Like an ITR, but:

             1 - Advertises only a subset of the "edge" space -
                 specific MABs (Mapped Address Blocks) into the
                 DFZ, and so receives packets addressed to these
                 MABs.  An ordinary ITR receives packets addressed
                 to all MABs.

                 A DITR doesn't need to know all the MABs or all
                 "edge" space - it just gets the list of MABs it
                 needs to advertise from its QSA.

             2 - Looks up the mapping, if it is not already cached.
                 Sends a Map Request to a QSA which is in the same
                 rack at the same DITR site, so there is a fast
                 100% reliable, connection, and only a few ms
                 delay in being able to tunnel the packet.

             3 - Is located at a DITR site, where the site and its
                 one or more DITRs and QSAs typically only handle
                 a subset of the MABs.  (According to which MABOCs
                 this DITR site operator is working for.)

             4 - Analyses traffic so the company which operates the
                 DITR site can bill the MABOCs (MAB Operating
                 Companies) for the traffic handled for each MAB.
                 This analysis will include time and micronet
                 details so the MABOC can bill its SPI-leasing
                 EUN customers for each such customer's DITR traffic.

             5 - May connect to the QSA via a QSC, but most likely
                 just sends Map Requests, and receives Map Replies
                 and Map Updates, directly to the QSA which is at
                 the same site, and presumably in the same rack.

                 Conceptually, there is a single QSA, but in
                 fact there may be two or more for redundancy,
                 and perhaps the DITR will be configured to use
                 a QSA at another DITR site run by the same
                 company as a backup if its own site's QSAs
                 fail.  (This last option is not mentioned in
                 the DRTM ID or in Ivip-arch.)

             6 - Stops advertising its MABs in the DFZ if its
                 QSA is dead, or can't get up-to-date mapping.

   ITFH    Like an ITR, but is built into the sending host.

           Handles traffic packets sent to all MABs, but does
           not "advertise" routes to these - it simply intercepts
           outgoing packets generated by the host's otherwise
           conventional stack.

           The sending host can be on conventional space or on
           "edge" space (SPI, micronet space).  In the current
           Ivip design, it can't be behind NAT.

   QSA     Authoritative Query Server.  These are only located at
           DITR sites.  In theory a QSA could be authoritative for
           the mapping of all MABs, but in practice, each DITR site
           will only support a subset of MABs.

           Gets, by some means, a real-time feed of mapping changes
           for all its MABs and so maintains a complete mapping
           database for each MAB.  (How this is done is not
           currently specified, but since this is only for the QSAs
           in a single DITR network, and since each such network only
           handles a subset of MABs and will probably have no more
           than a few dozen DITR sites, this is assumed to be
           possible in secure, scalable, fashion.  Private network
           links could be used between these sites.)

           Responds to Map Requests from DITRs at this site -
           sending them Map Reply messages within a few milliseconds
           and sending them Map Update messages if and when

           Conceptually, there is a single QSA at each DITR site.
           In reality, there may be one for the use of the DITRs
           there and one or more for accepting Map Replies from
           typically nearby QSRs.

           QSAs are in DITR sites.  A single DITR network might have
           one or two dozen such sites, each handling the same
           subset of MABs.  These would be scattered around the Net
           to share the load and generally minimise total path

   QSR     Caching Resolving Query Server.  ISPs run 1 or more
           likely 2 or 3 of these for their own ITRs and for the
           ITRs in their customer networks.

           Auto-discovers, via a DNS mechanism, all the MABs and
           provides a form of this information - the complete set of
           "edge" space - to all the ITRs it serves.  Also, for each
           MAB, discovers the address of 2 or 3 typically nearby QSAs
           which handle that MAB.

           Accepts Map Requests from queriers (ITRs and QSCs) and
           sends them Map Replies and Map Updates.

           Answers the queries from its own cached mapping or by
           sending a query to one of the nearby QSAs, depending
           on which MAB the queried address lies within.

           Sends its own Map Requests to QSAs, depending on which
           VP the queried address fits within.  Accepts Map Replies
           and later potentially Map Updates from these QSAs.

   QSC     This is an optional device - a Caching Query Server.

           It accepts Map Requests from ITRs and/or other QSCs -
           and sends them Map Replies and Map Updates.

           It sends its own Map Requests (when it receives a
           Map Request it can't answer from its cache) to
           one of the handful of QSRs and/or QSCs which are
           "upstream".   QSCs, when they serve multiple ITRs,
           can frequently answer Map Requests from their cache
           - since a previous request by another ITR filled the
           cache.  So QSCs can reduce the workload of QSRs.

           (The code for the ITR/DITR, QSA, QSR and QSC functions
           will have many common elements.)

   ETR     Egress Tunnel Router.  Accepts the tunneled traffic
           packets from ITRs and forwards them to the destination
           network.  May be in the ISP network and so shared by
           multiple destination networks, or may be located in
           the destination network, such as on a PA address from
           the ISP.

           Works with ITRs to handle PMTUD problems caused by