Ivip network elements
To the main Ivip
From my RRG message on
interesting Core-Edge Separation (CES) architecture
Ivip's network elements are in logical groups:
All but the ETR would share some common code elements. These "network
elements" could be
"roles" - so a single server or router could perform
multiple 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
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:
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,
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
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
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.
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
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.
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
Works with ITRs to handle PMTUD problems caused by