[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                         R. Whittle
Internet-Draft                                          First Principles
Intended status: Experimental                           January 13, 2010
Expires: July 17, 2010

            Glossary of some Ivip and scalable routing terms


   This glossary is intended to help with the understanding of terms
   used in the Ivip core-edge separation architecture and of some non-
   Ivip terms which are pertinent to scalable routing.  These are not
   "official" definitions of terms as used in scalable routing, but I
   hope they will help newcomers to the field.  Please suggest
   corrections, additions and improvements.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 17, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Whittle                   Expires July 17, 2010                 [Page 1]

Internet-Draft                Ivip Glossary                 January 2010

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Ivip acronym . . . . . . . . . . . . . . . . . . . . . . . 17
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21

Whittle                   Expires July 17, 2010                 [Page 2]

Internet-Draft                Ivip Glossary                 January 2010

1.  Introduction

   Please see the Ivip-arch ID [I-D.whittle-ivip-arch] and other IDs
   mentioned there for a detailed description of Ivip.  Significant
   developments regarding Ivip are at http://www.firstpr.com.au/id/ivip/
   along with links to the IRTF Routing Research Group wiki, mailing
   list etc.  I assume anyone with an interest in scalable routing is
   keeping up with the RRG mailing list discussions.

Whittle                   Expires July 17, 2010                 [Page 3]

Internet-Draft                Ivip Glossary                 January 2010

2.  Glossary

         Border Router of an ISP - where the ISP network connects to the
         routers of other networks.  See also PE and CE.

         Customer Edge router.  A router in an end-user network which
         connects to one or more ISP networks.  See also BR and PE.

   Core-Edge Elimination (CEE):
         This class of scalable routing architectures is also properly
         referred to as "Locator / Identifier Separation" - despite LISP
         being an example of the other kind of architecture: Core-Edge
         Separation.  CEE is a scalable routing architecture in which
         hosts in end-user networks gain one or more "Locator" AKA
         "physical" addresses from each upstream ISP.  These addresses
         can be scalably supplied to many end-user networks, since they
         are part of larger ISP prefixes.  End-user networks do not
         retain these Locator addresses when they choose another ISP.
         Host applications use a separate system (separate namespace) of
         "logical" AKA "edge" or "Identifier" addresses.  The host's
         stack determines how to create addresses for packets which the
         routing system will use to get the packet to the correct
         destination network via one of its ISPs, as determined by which
         "Locator" address the stack affixes to the packet.  The
         "Identifier" addresses are retained by the end-user network no
         matter which ISPs they use.  There are no "core" or "edge"
         addresses - just two separate systems of addresses: one to
         identify hosts and the other to use as a routing locator to get
         the packet from one network to another.  All such systems
         involve changes to existing host stacks and perhaps
         applications.  They generally attempt to be backwards
         compatible with IPv6 rather than IPv4.  Some architectures
         allow ISP routers to alter locator addresses to control packet
         flows.  Generally, the hosts have to do more work than at
         present since there are no ITRs or ETRs or the like in the
         network.  The network remains simple, compared to the
         additional elements added to create a Core-Edge Separation
         architecture.  There is usually at least one additional global
         mapping lookup system, or an extension to DNS to support
         mapping lookups, such as using an Identifier to find that
         host's valid Locator or Locators.  HIP and ILNP are examples of
         Core-Edge Elimination architectures.  See also the start of the
         Architectural Choices section in Ivip-arch.

Whittle                   Expires July 17, 2010                 [Page 4]

Internet-Draft                Ivip Glossary                 January 2010

   Core-Edge Separation (CES):
         A scalable routing architecture in which hosts in end-user
         networks use a subset of the global unicast address space which
         are called "edge" (AKA "EID" or "SPI") addresses.  The
         remainder of this space retains its current properties and is
         known as "core" (AKA "RLOC" or "conventional") space.  End-user
         networks retain their edge address space no matter which one or
         more ISPs they use for Internet access.  A system of ITRs, ETRs
         and a mapping system transports packets addressed to "edge"
         addresses across the DFZ by tunneling from the ITR to the ETR
         address.  Only a small number of large (short) prefixes need to
         be advertised in the DFZ to cover very large numbers of these
         "edge" prefixes (AKA, in Ivip, micronets of SPI space), so the
         impact on the DFZ is very small.  This edge space can be sliced
         into many small pieces for very large number of end-user
         networks.  The "edge" addresses are separated out from the
         "core" addresses, but remain part of the same namespace.  Only
         ITRs treat packets differently according to whether the
         destination address is "edge" or "core".  Hosts on both kinds
         of address communicate normally and the host requires no new
         protocols or knowledge of whether an address is "core" or
         "edge".  LISP, APT, Ivip, TRRP and TIDR are all CES
         architectures.  See also the start of the Architectural Choices
         section in Ivip-arch.

         Border Gateway Protocol.  A protocol by which routers
         communicate in order that each can develop an optimal, or at
         least a good, set of best-path rules for its FIB, to handle
         packets matching all the prefixes the router handles.  BGP is
         used in the DFZ.

         Commercial Off The Shelf server - no specific brand.  For
         instance a rack-mount server running Gnu/Linux, BSD, or any
         other operating system - usually remote controlled, and so
         without display or keyboard.  High performance COTS servers
         today typically have multicore CPUs from Intel or AMD,
         gigabytes of RAM and one or more hard drives.

         A Default ITR in the DFZ.  Previously known as an OITRD (Open
         ITR in the DFZ) and before that, erroneously, as an "Anycast
         ITR in the core/DFZ".  The LISP equivalent is the PTR (Proxy
         Tunnel Router).  DITRs advertise MABs and so attract packets
         addressed to SPI space which were sent by hosts in networks
         which have no ITRs.  DITRs (or PTRs) are essential for ensuring
         that networks adopting SPI (EID) space get all the packets

Whittle                   Expires July 17, 2010                 [Page 5]

Internet-Draft                Ivip Glossary                 January 2010

         which are sent to them, with full support for portability,
         multihoming and TE.

         Default-Free Zone.  The large subset of the interdomain routing
         system which consists of routers which have more than one
         "upstream" link - meaning there is more than one path to "the
         rest of the Internet".  If the router is a BR of an ISP or a
         PI-using end-user network which connects to the DFZ, then it
         will have ne or more other links which take packets to this
         local network.  If the router has no "local network" then it is
         a transit router in the DFZ and is operated by a transit
         provider.  A router at the border of an ISP or PI-using end-
         user network which has a single upstream link (probably to an
         ISP network) can have the interface for upstream link as the
         "default path" in its FIB and RIB.  Routers with two or more
         links to the rest of the Net can't have such a default route,
         and so are considered to be in the default-free part of the
         interdomain routing system.  DFZ routers need to have a route
         in their FIB and RIB for every prefix (route) which is
         advertised in the interdomain routing system.  (Often "DFZ" is
         used to refer to the interdomain routing system.)  Since there
         are 300k or more such prefixes, this means the router needs to
         have a fast route processor (main CPU) to run its RIB and BGP
         sessions with neighbours.  It also needs a high capacity (and
         typically very expensive) FIB to figure out, for each incoming
         packet, which of the 300k+ prefixes best matches the packet's
         source address.  DFZ routers are regarded as being multihomed.
         A "single-homed" router has a single upstream link.  Its RIB
         and FIB have much fewer demands placed upon them, since they
         contain routes for the local network, accessible by one or more
         interfaces, and then a "default" rule, which catches all
         packets not yet matched, which causes the FIB to forward those
         packets to the single upstream link.  "Single-homed" routers
         don't need their RIB or FIB to consider all the 300k prefixes
         which are advertised in the DFZ - just the ones this router
         advertises.  DFZ routers are very expensive and there are an
         unknown number of them - maybe 100,000 or so of them.  They are
         run mainly by ISPs (who sell connectivity to end-user networks)
         and transit providers (who sell connectivity to ISPs and other
         transit providers.  DFZ routers may also be operated by larger
         PI-using end-user networks, such as those of universities,
         which are multihomed to two or more upstream ISPs, and which
         choose to send out packets on the link with the optimal path to
         the destination, rather than just nominating one link as the

Whittle                   Expires July 17, 2010                 [Page 6]

Internet-Draft                Ivip Glossary                 January 2010

   DFZ Control Plane
         Broadly speaking, the system of all DFZ routers and their route
         processors communicating with each other using BGP messages so
         that each one can determine the optimal (or at least "good
         enough") best path for packets which are addressed to every
         prefix (route) which is advertised in the interdomain routing
         system.  The entire global system behaves as a system -
         although its exact behaviour is not necessarily understood.
         The "control plane" is separate from the "data plane" - which
         actually handles traffic packets.  The "control plane" includes
         the RIBs of all the DFZ routers.  It is an essential goal of
         scalable routing to contain the growing load on the DFZ's
         control plane while providing portability, multihoming and TE
         for far more end-user networks than currently have these
         things.  (Reducing the load on the DFZ data plane is not
         possible in terms of the number of packets, but anything which
         reduces the load by limiting or reducing the number of prefixes
         in DFZ routers' FIBs, while allowing many more multihoming end-
         user networks, would also be achieving a vital goal of scalable

         ETR Address Forwarding.  The MHF (Modified Header Forwarding)
         technique for IPv4 - as an alternative to encapsulation.

   End-user network:
         A network which is not used for selling Internet connectivity.
         Most of the end-user networks referred to in scalable routing
         are those which want or need portability, multihoming and TE.
         However, this is just a subset of end-user networks.  Most end-
         user networks, such as those of home and SOHO users, are fine
         without portability, multihoming or TE.

         Forwarding Equivalence Class.  Within a router, FEC can be
         thought of as a number of some kind which the FIB chooses for
         each incoming packet.  A simple type of FEC is which interface
         to forward the packet from.  However, routers may maintain
         multiple queues for packets going out a single interface, so as
         to give priority to different types of packet.  Each such queue
         would be identified by a different FEC.

         Forwarding Information Base.  This refers either to the body of
         data in a router which directly controls how traffic packets
         are processed, and/or to the hardware and software which
         performs this plus the data which controls them.  Earlier
         routers had a single FIB, with multiple input/output

Whittle                   Expires July 17, 2010                 [Page 7]

Internet-Draft                Ivip Glossary                 January 2010

         interfaces.  Some modern high-speed routers integrate an FIB
         into each interface to handle the packets arriving on that
         interface alone - or have multiple FIBs each dedicated to one
         or more interfaces.  The FIB has arguably the most demanding
         task of any part of the router - though the interconnect
         between the interfaces/FIBs is has a daunting task too.

         Ivip's Fast push Mapping distribution System.  Starts with
         mapping update commands, being handled by UASes (Update
         Authorization Servers) and then being passed to a RUAS\ (Root
         Update Authorization Server), Launch Server and then through
         several levels of Replicator to the QSD (full database local
         query server).  QSDs respond to ITR requests (perhaps with
         intermediate caching QSC query servers) and send mapping update
         commands to ITRs which need them.  So the whole FMS links end-
         user networks, or their appointees, to ITRs which are tunneling
         packets which are addressed to one of the end-user network's

         Ivip's "ITR Probes Tunnel MTU" arrangement for handling the
         PMTUD problems inherent in encapsulated tunnels between the ITR
         and ETR.

         ITR Function in sending Host.  An ITR which is implemented
         purely by software which is added to a host, and which only
         processes the packets that host sends.

         Ingress Tunnel Router.  An existing router, or a function
         within a server or existing host, which accepts packets
         addressed to an SPI address and which alters the packet in some
         way so the DFZ routing system (plus any internal routers of
         ISPs and end-user networks which are on path) will transport
         ("tunnel") the modified packet to an ETR, which reverses the
         modifications and forwards the packet to the destination
         network.  ITRs need to look up some mapping for each packet -
         and they need to get the mapping quickly when a packet arrives
         which they have no cached mapping for.  The ITR then caches the
         mapping for some time, so it can handle packets addressed to
         this address (or any other address in the micronet which
         contained the first packet's destination address) without
         requesting mapping again.  ITRs in the DFZ are called DITRs.
         An ITR function in a sending host is called an ITFH.  ITRs in
         other core-edge separation schemes always use encapsulation to
         tunnel the packet to the ETR.  Ivip ITRs will be able to use

Whittle                   Expires July 17, 2010                 [Page 8]

Internet-Draft                Ivip Glossary                 January 2010

         MHF (Modified Header Forwarding) instead of encapsulation.

         Internet vastly improved plumbing.  The origins of the acronym
         and guidance on capitalization are in the section following
         this Glossary.

         Modified Header Forwarding.  An method for ITR tunneling
         traffic packets to an ETR - as an alternative to encapsulation.
         The IP header is modified, so all routers between the ITR and
         ETR must be upgraded to handle the new format.  For IPv4: ETR
         Address Forwarding (EAF) and for IPv6: Prefix Label Forwarding

         Mapped Address Block.  A DFZ-advertised prefix containing SPI
         space - typically the UABs and their constituent micronets for
         many end-user networks.  This is an Ivip term with no
         equivalent in LISP, although LISP too has the same concept.
         The MABs are advertised by ITRs in the local routing system and
         by DITRs in the DFZ.

         Mapped Address Block Update Stream.  A second-by-second stream
         of mapping updates, assembled by an RUAS, from potentially many
         of its subsidiary UASes.  Contains all the mapping updates for
         a given MAB which the RUAS is responsible for.

         Information which tells an ITR which ETR to tunnel a packet to,
         when the destination address (always in the SPI subset of the
         global unicast address range) matches a particular micronet.
         In Ivip, the mapping of a micronet consists purely of a single
         ETR address.  In LISP and other core-edge separation schemes,
         the mapping of an EID prefix (~AKA "micronet") typically
         consists of multiple ETR addresses with various priorities and
         weightings so the ITR (or Default Mapper, in APT) can choose
         one for the purposes of load balancing TE and/or multihoming
         service continuity.

   Mapping distribution system:
         Core-Edge Separation architectures need a method by which ITRs
         can quickly find the mapping which applies to a particular
         "edge" (AKA SPI or EID) address which is the destination
         address of a packet.  The device which physically controls this
         mapping could be anywhere in the world - and there could be
         very large numbers of such devices, scattered all over the Net.

Whittle                   Expires July 17, 2010                 [Page 9]

Internet-Draft                Ivip Glossary                 January 2010

         The Mapping Distribution system is how the ITRs get the mapping
         - as quickly and reliably as possible.  Full-push mapping
         distribution involves all mapping being pushed to all ITRs, so
         the ITR already has the mapping. (e.g.  LISP-NERD.)  Full-pull
         involves a global system by which the ITR's request is directed
         to an authoritative query server which has the mapping - and
         which sends back the map reply to the ITR. (e.g.  LISP-CONS,
         LISP-ALT and TRRP.)  A third approach is to push all mapping to
         "local" full database query servers, such as in each ISP.  ITRs
         request mapping from these. (e.g.  APT and Ivip.)

         A contiguous range of SPI address space which is mapped to a
         single ETR address.  A UAB contains one or more micronets.  The
         units of splitting SPI space are IPv4 addresses and IPv6 /64s.
         Micronets and UABs are integer numbers of these units.  The
         equivalent in LISP is an "EID" prefix.

         Mobility in TCP/IP networks refers not directly to a host being
         physically mobile and connecting to different networks.  Nor
         does it necessarily imply the device has wireless interfaces to
         those networks.  It generally refers to the ability of a host
         to maintain its communication sessions while it is changing its
         physical point of connection.  Some mobility systems meet these
         requirements by giving the host the same IP address no matter
         where it physically connects to a particular access network.  A
         global approach to mobility would enable session continuity
         when the host connects to any network at all, and so may have
         completely different IP addresses from time-to time.  One
         approach is to use special IP protocol stack capabilities so
         applications are not affected by changes in physical address.
         Another is to keep the current host stack and (with some
         additional software and usually the involvement of some devices
         in the network, such as ITRs and TTRs) give the host a single
         IP address no matter how or where it is connected.

         Mobile Node.  Synonymous with "mobile host".

         Maximum Transmission Unit.  The maximum length of a packet,
         measured in bytes, which a particular interface of a router, or
         the data link it drives, can handle.  See also PMTU and PMTUD.

Whittle                   Expires July 17, 2010                [Page 10]

Internet-Draft                Ivip Glossary                 January 2010

         The ability of an end-user network (as large as a corporation
         network, or as small as a home network or handheld wireless
         device) to maintain all its communication sessions, and the
         identity of all its hosts, when the connection it is using via
         one ISP fails, and is replaced quickly by that of another ISP.
         One way of doing this is to ensure the hosts never see any
         changes - that is, the hosts always retain their own IP
         addresses.  Another is to have the host IP stack manage the
         host identity address in a stable way so that applications are
         unaware of the ISP link changes, while operating from either a
         physical address obtained from the first ISP or that obtained
         from the second.  Core-edge separation schemes use the former
         technique and core-edge elimination schemes usually use the

   Outer header:
         When a packet AA is encapsulated, another one or more headers
         is prepended to it.  The outer header is the IP header of the
         new packet BB which contains just the original packet AA
         (Ivip), or (LISP) a UDP header and a LISP header, which is
         followed by the AA packet.  The destination address of the
         outer header will be recognised by all routers and the packet
         will be forwarded towards that address - which in the case of
         ITR encapsulation, will be an ETR which can decapsulate the
         packet an forward it to the destination network.

         Provider Assigned - address space, prefix or IP address.
         Global unicast address space which is used by an end-user
         network and comes from an ISP's prefix.  Typically the prefix
         it comes from is a large (short) prefix which is therefore not
         a problem in terms of scalable routing, and which the ISP uses
         for its own internal purposes and for many other end-user
         networks.  PA prefixes are good for scalable routing, but bad
         for any end-user network which wants portability, since they
         only get these particular addresses with a particular ISP.
         Likewise, unless special techniques are used, an end-user
         network can't achieve multihoming (with session continuity
         during an outage of one ISP or the link to that ISP) with PA
         space - or inbound TE.  See also PI space.

         Provider Edge router.  A router in an ISP network which
         connects to one or more end-user networks.  See also BR and CE.

Whittle                   Expires July 17, 2010                [Page 11]

Internet-Draft                Ivip Glossary                 January 2010

         Provider Independent address space, prefix or IP address.
         Global unicast address space which is used by an end-user
         network and which the network retains no matter which ISPs it
         uses for connecting to the Net. PI space is good for the end-
         user network, since it is portable and can be used for
         multihoming and TE, with full session continuity in the event
         of failure, by having its two or more ISPs advertise the prefix
         in the DFZ - or to have one advertise it and the other
         advertise it if the link to the first ISP fails.  This use of
         PI prefixes is bad for routing scalability, since each such PI
         prefix and any changes to its advertisement is an additional
         burden on all DFZ routers and on the DFZ control plane in
         general.  See also PA and SPI.

         "Portable address space" means the ability of an end-user
         network to retain its address space when using any ISP.  This
         may involve the network having a single link to one ISP or it
         having multiple, and so being multihomed.  Being free to change
         ISPs is important for competition and flexibility.  While there
         have been proposals, especially for IPv6, to make it easy to
         change host and network addresses so as to make it easy to
         change to a new ISP's PI address space, this has never been
         accepted as providing the convenience, low cost and reliability
         of actual portable address space.  "Ease of choosing ISPs" has
         been one way of stating a major goal of scalable routing, and
         some people have stated it in terms of assuming the end-user
         network can't keep its own address space: "ease of renumbering
         when changing ISPs".  However, the only practical way the needs
         of end-user networks can be met when choosing another ISP is to
         retain the current address space - which means this address
         space must be "portable".

         Path MTU.  The MTU (maximum packet length, in bytes) not of a
         single interface but of a path from one device to another - and
         so of all the devices, input and output interfaces and data
         links in that path.  In a core-edge separation architecture the
         PMTU of most interest is that between the ITR and the ETR,
         since encapsulation disrupts the RFC 1191 PMTU Discovery
         process which normally operates with all routers between the
         sending and destination hosts.

         Path MTU Discovery.  RFC 1191 PMTUD is a protocol by which the
         sending host can try sending different length packets (which
         must be unfragmentable in IPv4: DF=0 - in IPv6, all packets are

Whittle                   Expires July 17, 2010                [Page 12]

Internet-Draft                Ivip Glossary                 January 2010

         fragmentable) to a destination host and being able to choose
         the longest packet length which will fit in the PMTU, by using
         ICMP PTB (Packet Too Big) messages from any router where the
         packet will not fit within the next-hop MTU.  There is also a
         more complex and recent PMTUD technique - RFC 4821.  This does
         not rely on PTBs, but involves applications discovering the
         PMTU to a host by end-to-end means, and then sharing that PMTU
         information with other applications.  RFC 1191 is universally
         used and as far as I know, RFC 4821 is hardly used at all.

         Prefix Label Forwarding.  The MHF (Modified Header Forwarding)
         technique for IPv6 - as an alternative to encapsulation.

         ICMP Packet Too Big message.  Part of RFC 1191 Path MTU
         Discovery (PMTUD).  Ordinarily sent to the sending host by a
         router which determined that the packet was too long for either
         the data link or next device in the next-hop.  The PTB includes
         initial parts of the original packet, and an MTU number which
         the sending host can use as a maximum packet length, so that
         future packets will not breach this limit.  When ITRs use
         encapsulation to tunnel packets to an ETR, the routers between
         the ITR and ETR are unable to generate a valid PTB to the
         sending host (unless they were specially modified, in some
         way).  So the ITR has to take care of whatever MTU limits exist
         between it and the ETR, and generate PTBs to the sending host
         in order to ensure its packets are not longer than the PMTU
         (Path MTU) of the path to the ITR.

   Query Server:
         In Ivip, a "query server" is a server which responds to queries
         about mapping.  The querier may be an ITR or a caching query
         server (QSC).  Full database query servers are QSDs.  Ivip QSDs
         and QSCs remember the map replies they sent, with their caching
         times, and will send a mapping update message to whichever
         device (an ITR or a QSC) made the query, if the mapping changes
         during the caching time.  LISP and APT do not use the term
         "query server", but I use it to describe whatever it is in
         these architectures which responds to the ITR's request for
         mapping.  In LISP-ALT, the query servers are either ETRs or
         MSes (Map Servers) - and are distributed all over the Net. So
         LISP ALT is a global query server system.  APT's query servers
         are local to the ISP and are called Default Mappers.

Whittle                   Expires July 17, 2010                [Page 13]

Internet-Draft                Ivip Glossary                 January 2010

         Caching query server.  Responds to map requests from ITRs or
         QSCs.  Sends map requests to one or more upstream local QSCs
         and/or QSDs.

         Full database query server.  Responds to map requests from ITRs
         or QSCs.  Receives a full feed of mapping updates from two or
         more upstream Replicators.

         Server within the Ivip fast-push mapping distribution system.
         Receives two or more streams of update packets from upstream
         devices (Replicators or Launch servers) with each stream's set
         of packets containing identical mapping data.  Failure of one
         packet to arrive from one stream will usually be covered by the
         arrival of a packet with the the same payload from another
         stream.  As soon as the first packet for a given payload
         arrives, the Replicator generates 20 or so packets with this
         payload, to downstream devices, which may be Replicators or
         QSDs.  The Replicator system can be viewed as creating multiple
         parallel multicast fan-out trees, and cross linking them at all
         levels.  Alternatively it can be viewed as a directional
         flooding scheme in which 8 Launch servers flood a larger number
         of level 1 Replicators which instantly flood a still larger
         number of level 1 Replicators.  Flooding increases total
         bandwidth used, and greatly improves robustness, without
         slowing down the propagation of information.  If this term is
         too reminiscent of a sci-fi monster, I could call them Directed
         Flooding Mapping Dissemination Servers or something similarly

         Routing Information Base.  Within a router, the RIB is the body
         of data - as maintained by software which controls the route
         processor (administrative CPU of the router) - by which the
         router decides how it will handle traffic packets.  When the
         router is running BGP (as all DFZ routers do) the RIB is not
         just a product of messages received, but also controls the BGP
         messages which will be sent to neighbours.  The RIB is used to
         generate data which is written into the FIB so the FIB
         classifies, processes and forwards packets in the manner
         specified by the RIB.

         Root Update Authorization Server.  Each RUAS organisation runs
         one of these to coordinate its output of mapping changes each
         second to the Launch server system which sends them to the

Whittle                   Expires July 17, 2010                [Page 14]

Internet-Draft                Ivip Glossary                 January 2010

         Replicator system.  Each RUAS company is responsible for the
         mapping of typically many MABs.

         Compressed data containing full mapping information for a MAB,
         at a particular instant in time.  Produced by the RUAS which is
         responsible for the MAB.  Downloaded by QSDs when intializing
         their database, or re-synching after some kind of corruption or
         loss of updates.

         Scalable Provider Independent address space.  The Ivip term for
         the subset of the global unicast space which is suitable for
         end-user networks, providing portability, multihoming and
         inbound TE in a manner which is "scalable" - does not overly
         burden the interdomain routing system (~AKA DFZ routers).  The
         LISP equivalent is "EID".  Global unicast space which is not
         SPI is known as "conventional" - or in LISP, as "RLOC" - space.

         Signed User Mapping Update Command.  Body of data containing a
         UMUC (mapping changes for the UAB of a particular end-user) but
         signed by the UAS which accepted these commands.  A SUMUC is
         accepted by a downstream system - an RUAS or another UAS - as
         being valid, on account of the signature being validated.

         Traffic Engineering.  Most references to TE in the scalable
         routing field refer to inbound TE - steering incoming traffic
         streams between two or more ISPs and their data links.  Both
         inbound and outbound TE is typically practised to balance
         traffic volumes over multiple links to make best use of each
         link's capacity.  Other reasons for preferring one link over
         another for particular subsets of the total traffic include one
         link being more reliable, lower latency or lower cost.  Also,
         it may be desired for various policy reasons to avoid some
         traffic traversing one link, which would cause it to pass
         through some ISP or country jurisdiction which was not desired.

   TTR Mobility architecture:
         A Translating Tunnel Router behaves like an ETR to the core-
         edge separation scheme and communicates with the Mobile Node
         (MN) by a two-way tunnel initiated by the MN.  The TTR is
         ideally topologically close to the MN - no more than 1000km or
         so distant.  The MN tunnels to one or more TTRs.  TTRs are
         commercially operated and are ideally numerous and well
         connected.  The MN's outgoing packets from its SPI address are
         sent out to the TTR which forwards them to the destination -

Whittle                   Expires July 17, 2010                [Page 15]

Internet-Draft                Ivip Glossary                 January 2010

         since the access network the MN is connected to will probably
         not forward packets with such a source address.  See: [TTR

         User Address Block.  A contiguous range of SPI address
         controlled by a single end-user network.  May be used as a
         single micronet or split into multiple micronets.  A MAB
         typically contains many UABs.  ITRs, QSCs and QSDs don't work
         with UABs - only micronets.

         Update Authorization Server.  Either the end-user interface
         system by which RUASes interact with customers of the RUAS
         company, or a system owned by another company which does the
         same job - for other end-user networks.  An RUAS may delegate
         responsibility for one or more MABs it is responsible for to
         one or more UASes, including having a UAS handle the mapping of
         one or more MABs.

         User Mapping Update Command.  After an end-user, or some person
         or device with the credentials provided by the end-user,
         executes a mapping change command with a UAS, this is the body
         of data containing that change.  This may include a set of
         changes to multiple micronets, including changing their ETR
         address, and joining or splitting them into different
         micronets.  (Sorry about the muddy sounding acronyms!)

         Wild Assed Guess.  Technique employed where some kind of figure
         is required, but the constraints on the realistic range for the
         figure are unknown or difficult to use precisely.  Synonymous
         with Stab in the Dark.

Whittle                   Expires July 17, 2010                [Page 16]

Internet-Draft                Ivip Glossary                 January 2010

3.  The Ivip acronym

   The "vip" in "Ivip" comes from the 1961 Doris Day, Rock Hudson and
   Tony Randall romp "Lover Come Back".  Advertising executive Jerry
   Webster (Rock Hudson) finds himself in trouble - from which he
   believes he can extract himself by convincing a dancer (Edie Adams)
   that he will introduce her to Hollywood by making her the star of a
   promotional campaign for a hot new product.  She is keen and keeps
   asking him what the product is.  Casting his eyes around the room, he
   sees a newspaper with a headline about a VIP.  "Vip!" he exclaims -
   and spends the rest of the movie trying to figure out what this great
   new product will be.

   Capitalization of the four characters is user selectable but defaults
   to "Ivip".  Lower-case 'i' is not recommended since "iVIP" might be
   mistaken for an abrasive bath and sink cleanser from Apple Inc. (A
   low cost product for those unable to afford a Macintosh computer or
   i**** product - the mere possession of which instantly renders the
   whole dwelling spic-and-span.)

   The capital 'I' raises a potential problem with sans-serif fonts such
   as Helvetica, since it is indistinguishable from lower-case "L".
   This has bedevilled the 3GGP term "Iub" (capital 'i') which seems to
   be more widely known outside the organisation as "lub" (lower-case

Whittle                   Expires July 17, 2010                [Page 17]

Internet-Draft                Ivip Glossary                 January 2010

4.  Security Considerations


Whittle                   Expires July 17, 2010                [Page 18]

Internet-Draft                Ivip Glossary                 January 2010

5.  IANA Considerations


Whittle                   Expires July 17, 2010                [Page 19]

Internet-Draft                Ivip Glossary                 January 2010

6.  Informative References

              Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
              Architecture", draft-whittle-ivip-arch-03 (work in
              progress), January 2010.

   [TTR Mobility]
              Whittle, R. and S. Russert, "TTR Mobility Extensions for
              Core-Edge Separation Solutions to the Internets Routing
              Scaling Problem", August 2008,

Whittle                   Expires July 17, 2010                [Page 20]

Internet-Draft                Ivip Glossary                 January 2010

Author's Address

   Robin Whittle
   First Principles

   Email: rw@firstpr.com.au
   URI:   http://www.firstpr.com.au/ip/ivip/

Whittle                   Expires July 17, 2010                [Page 21]