[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         R. Whittle
Internet-Draft                                          First Principles
Intended status: Experimental                             March 06, 2010
Expires: September 7, 2010


            Glossary of some Ivip and scalable routing terms
                   draft-whittle-ivip-glossary-01.txt

Abstract

   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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 7, 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 September 7, 2010               [Page 1]


Internet-Draft                Ivip Glossary                   March 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  BR - Border Router . . . . . . . . . . . . . . . . . . . .  5
     2.2.  CE - Customer Edge router  . . . . . . . . . . . . . . . .  5
     2.3.  Core-Edge Elimination (CEE)  . . . . . . . . . . . . . . .  5
     2.4.  Core-Edge Separation (CES) . . . . . . . . . . . . . . . .  6
     2.5.  BGP - Border Gateway Protocol  . . . . . . . . . . . . . .  6
     2.6.  COTS . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.7.  DITR - Default ITR in the DFZ  . . . . . . . . . . . . . .  7
     2.8.  DFZ - Default-Free Zone  . . . . . . . . . . . . . . . . .  7
     2.9.  DFZ Control Plane  . . . . . . . . . . . . . . . . . . . .  8
     2.10. DSOC - DITR-site Operating Company . . . . . . . . . . . .  9
     2.11. EAF - ETR Address Forwarding . . . . . . . . . . . . . . .  9
     2.12. EUN - End-User Network . . . . . . . . . . . . . . . . . . 10
     2.13. FEC - Forwarding Equivalence Class . . . . . . . . . . . . 10
     2.14. FIB - Forwarding Information Base  . . . . . . . . . . . . 10
     2.15. IPTM . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     2.16. ITFH - ITR Function in sending Host  . . . . . . . . . . . 11
     2.17. ITR - Ingress Tunnel Router  . . . . . . . . . . . . . . . 11
     2.18. Ivip . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     2.19. MHF - Modified Header Forwarding . . . . . . . . . . . . . 12
     2.20. MAB - Mapped Address Block . . . . . . . . . . . . . . . . 12
     2.21. MABOC - MAB Operating Company  . . . . . . . . . . . . . . 12
     2.22. Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     2.23. Mapping Distribution System  . . . . . . . . . . . . . . . 13
     2.24. Micronet . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.25. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.26. MN - Mobile Node . . . . . . . . . . . . . . . . . . . . . 15
     2.27. MTU - Maximum Transmission Unit  . . . . . . . . . . . . . 15
     2.28. Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 15
     2.29. Outer header . . . . . . . . . . . . . . . . . . . . . . . 15
     2.30. PA - Provider Aggregatable . . . . . . . . . . . . . . . . 16
     2.31. PE - Provider Edge router  . . . . . . . . . . . . . . . . 16
     2.32. PI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     2.33. PLF - Prefix Label Forwarding  . . . . . . . . . . . . . . 17
     2.34. PMTU - Path Maximum Transmission Unit  . . . . . . . . . . 17
     2.35. PMTUD - Path MTU Discovery . . . . . . . . . . . . . . . . 17



Whittle                 Expires September 7, 2010               [Page 2]


Internet-Draft                Ivip Glossary                   March 2010


     2.36. Portability  . . . . . . . . . . . . . . . . . . . . . . . 17
     2.37. PTB - Packet Too Big ICMP message  . . . . . . . . . . . . 18
     2.38. Query Server . . . . . . . . . . . . . . . . . . . . . . . 18
     2.39. QSA - Authoritative Query Server . . . . . . . . . . . . . 19
     2.40. QSC - Caching Query Server . . . . . . . . . . . . . . . . 20
     2.41. QSD (obsolete term)  . . . . . . . . . . . . . . . . . . . 20
     2.42. QSR - Resolving Query Server . . . . . . . . . . . . . . . 20
     2.43. Replicator (obsolete term) . . . . . . . . . . . . . . . . 21
     2.44. RIB - Routing Information Base . . . . . . . . . . . . . . 21
     2.45. SPI - Scalable Provider Independent  . . . . . . . . . . . 22
     2.46. TE - Traffic Engineering . . . . . . . . . . . . . . . . . 22
     2.47. TTR Mobility architecture  . . . . . . . . . . . . . . . . 22
     2.48. TTROC - TTR Operating Company  . . . . . . . . . . . . . . 23
     2.49. UAB - User Address Block . . . . . . . . . . . . . . . . . 23
     2.50. WAG ...  . . . . . . . . . . . . . . . . . . . . . . . . . 23
   3.  The Ivip acronym . . . . . . . . . . . . . . . . . . . . . . . 25
   4.  History of Ivip's mapping system . . . . . . . . . . . . . . . 26
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 31
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32






























Whittle                 Expires September 7, 2010               [Page 3]


Internet-Draft                Ivip Glossary                   March 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.

   For a discussion of the meaning of Core-Edge Elimination (CEE) and
   Core-Edge Separation (CES), the history of these important terms and
   some debates about their true meaning, or value, please see my
   February 2010 RRG message: "CES & CEE: GLI-Split; GSE, Six/One
   Router; 2008 sep./elim. paper (v3)"
   http://www.ietf.org/mail-archive/web/rrg/current/msg06110.html and
   any later versions or discussion which follows.



































Whittle                 Expires September 7, 2010               [Page 4]


Internet-Draft                Ivip Glossary                   March 2010


2.  Glossary

2.1.  BR - Border Router

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

2.2.  CE - Customer Edge router

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

2.3.  Core-Edge Elimination (CEE)

   This class of scalable routing architectures implements the "Locator
   / Identifier Separation" naming model, which is different from that
   used by IPv4 and IPv6 today.  (LISP - the "Locator / Identifier
   Separation Protocol" - is badly named, since it does not do this and
   is 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 (or
   perhaps the application) 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 "Identifiers" (which are not regarded as "addresses") are
   retained by the hosts of the end-user network no matter which ISPs
   they use.  There are no "core" or "edge" addresses - just two
   separate systems: one to identify hosts and the other to use as a
   routing locator to get the packet from one network to another.  So
   "Elimination" refers to the elimination of the need for two different
   classes of address space - there being no need for special "edge"
   prefixes.  All such systems involve changes to existing host stacks
   and perhaps applications.  They generally attempt to be backwards
   compatible with IPv6.  They are not practical for IPv4, for several
   reasons of which one is that a multihomed EUN (End User Network)
   consumes at least two or perhaps more times the address space it
   provides for its hosts.

   Some architectures allow ISP routers to alter locator addresses to



Whittle                 Expires September 7, 2010               [Page 5]


Internet-Draft                Ivip Glossary                   March 2010


   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.
   (However some CEE architectures do involve significant new
   functionality in routers.)  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.

2.4.  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.  In Ivip, these DFZ-advertised
   covering prefixes are known as MABs (Mapped Address Blocks).

   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".  IRON-RANGER
   LISP, APT, Ivip, TRRP and TIDR are all CES architectures.  See also
   the start of the Architectural Choices section in Ivip-arch.

2.5.  BGP - Border Gateway Protocol

   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 interdomain routing
   system, which is also loosely referred to as the DFZ.





Whittle                 Expires September 7, 2010               [Page 6]


Internet-Draft                Ivip Glossary                   March 2010


2.6.  COTS

   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.

2.7.  DITR - Default ITR in the DFZ

   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 (Mapped Address Blocks) 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 which are sent to them, with full
   support for portability, multihoming and TE.  In principle, a DITR
   could advertise every MAB in the Ivip system.  In practice, there are
   likely to be multiple independent sets of DITRs, with each set having
   at least one DITR in a DITR-site, with these sites typically being
   widely distributed around the world to reduce the total path length
   between sending host the ETR used by the destination network.  Since
   DITRs will generally be run by, or for, the MABOC (MAB Operating
   Companies) who lease SPI space to thousands of EUNs (end-user
   networks), the one or more DITRs at any one site will typically only
   advertise the MABs of the MABOCs this site is serving.  See also
   "DSOC".

2.8.  DFZ - 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 one 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



Whittle                 Expires September 7, 2010               [Page 7]


Internet-Draft                Ivip Glossary                   March 2010


   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.

   Each DFZ router 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.  See the
   August 2007 RRG thread "Routers in DFZ - reliable figures from
   iPlane".

   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 "default".

   A router which is inside a large network and is operating as a Route
   Reflector may also be considered part of the DFZ, if it needs to
   carry all DFZ routes in its RIB.

2.9.  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 well understood.  Geoff Huston's site
   http://bgp.potaroo.net is an excellent source of information on the
   BGP control plane.  Please also see his 2010-3-01 message to the RRG
   (msg06152) which contains his latest analysis of the DFZ control



Whittle                 Expires September 7, 2010               [Page 8]


Internet-Draft                Ivip Glossary                   March 2010


   plane's burdens.

   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
   routing.)

2.10.  DSOC - DITR-site Operating Company

   A MABOC which runs its own DITRs is typically runs them at multiple
   (perhaps 5 to 30 or more) DITR-sites.  In this case, the MABOC is its
   own DSOC.  A MABOC or some other company which is a DSOC may also run
   the DITR(s) and QSA(s) (Authoritative Query Servers) at that site to
   handle the MABs of multiple MABOCs.

   In principle, a single DITR-site could handle all MABs in the Ivip
   system, but in general it is assumed that there will be multiple
   DSOCs and that each will have multiple, ideally numerous, DITR sites
   - each of which handles a subset of all the MABs.  In addition to
   running these DITR routers/servers and QSA servers, the DSOC needs to
   do at least two other things.

   Firstly, they need to get real time mapping changes from each MABOC's
   system which collects mapping change commands from EUNs (or their
   appointees) and reliably, securely and rapidly fan this out to all
   the QSAs in their DITR-sites.  The one or more QSAs at each site are
   used by the DITRs and for answering mapping queries from the QSRs
   (Resolving Query Servers) of typically nearby ISPs and EUNs which
   have ITRs and QSRs.

   Secondly, they need to collect traffic statistics on the usage of the
   DITRs in a manner that they can charge the MABOCs for this work, and
   so the MABOCs can charge their individual EUNs who use the space in
   each MAB.

2.11.  EAF - ETR Address Forwarding

   ETR Address Forwarding.  The MHF (Modified Header Forwarding)
   technique for IPv4 - as an alternative to encapsulation.  See:
   [I-D.whittle-ivip-etr-addr-forw]




Whittle                 Expires September 7, 2010               [Page 9]


Internet-Draft                Ivip Glossary                   March 2010


2.12.  EUN - End-User Network

   A network which is not used for selling Internet connectivity -
   although the term "end-user network" does apply to a network such as
   that of a hosting company, which leases the capacity of its servers
   to its customers.  "Internet connectivity" in this sense means
   connecting a user's network or mobile device to the Internet, which
   is what ISPs do.

   Most of the end-user networks referred to in scalable routing are
   those which want or need portability, multihoming and inbound traffic
   engineering (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 inbound TE.  With
   TTR (Translating Tunnel Router) mobility, each mobile node (MN) is
   regarded as a separate EUN, though it may have only a single IPv4
   address and isn't really a "network" since it is a single host.  An
   MN could also have multiple IPv4 addresses, multiple prefixes of IPv6
   addresses etc.  The network of a passenger jet or cruise ship is
   physically mobile and is also regarded as a mobile EUN, even though
   in practice this network may charge its customers for Internet
   connectivity to their PCs etc.

2.13.  FEC - 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.

2.14.  FIB - Forwarding Information Base

   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 interfaces.  Many modern, larger, 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.





Whittle                 Expires September 7, 2010              [Page 10]


Internet-Draft                Ivip Glossary                   March 2010


2.15.  IPTM

   Ivip's "ITR Probes Tunnel MTU" arrangement for handling the PMTUD
   problems inherent in encapsulated tunnels between the ITR and ETR.
   This will be the subject of a future ID.  For now please refer to:
   http://www.firstpr.com.au/ip/ivip/pmtud-frag/ .

2.16.  ITFH - ITR Function in sending Host

   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.  The host can be on a conventional "core"
   address or on an SPI ("edge") address.  It cannot be behind NAT.
   Generally, ITFH should not be implemented on hosts with slow or
   unreliable links, such as any host relying on a 3G or similar
   wireless link.

2.17.  ITR - 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.  The altered packet is forwarded 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 MHF (Modified Header Forwarding) instead of
   encapsulation.

2.18.  Ivip

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







Whittle                 Expires September 7, 2010              [Page 11]


Internet-Draft                Ivip Glossary                   March 2010


2.19.  MHF - Modified Header Forwarding

   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 (PLF).

2.20.  MAB - Mapped Address Block

   A Mapped Address Block is a DFZ-advertised prefix containing SPI
   space - typically the UABs (User Address Blocks) and their
   constituent micronets for many end-user networks.

   This is an Ivip term with no direct equivalent in LISP, although LISP
   too has the same concept.  (In the RRG list, Dino Farinacci has used
   the term "coarse prefix" to refer to the LISP equivalent of Ivip's
   MABs.)

   MABs are advertised by ITRs in the local routing system and by DITRs
   in the DFZ.  Typically an ordinary ITR (an ITR inside an EUN or an
   ISP's network - all ITRs except DITRs) will advertise all the MABs of
   the Ivip system while DITRs will only typically advertise a subset of
   MABs.  ITFH functions in sending hosts don't "advertise" MABs, but
   they intercept all outgoing packets with destination addresses which
   match any MAB.

2.21.  MABOC - MAB Operating Company

   Mapped Address Block Operating Company.  An organization, here
   assumed to be a company (otherwise MABOO...) which controls the
   address space within a MAB.

   Most MABOCs will use this space to lease SPI space to large numbers
   of EUNs, each of which is therefore a customer of the MABOC.  A MABOC
   my have one or many MABs.  The space leased to a given EUN is a User
   Address Block (UAB).  Within each UAB, each EUN dynamically assigns
   the space into one or more micronets, each with its own mapping.
   However, if the UAB may be just a single IPv4 address or IPv6 /64,
   then it can only be used as a single micronet.

   An EUN may also have a complete MAB, in which case it is the MABOC of
   this MAB.  Perhaps it leases SPI space to other EUNs, or perhaps not.
   A network which leasing SPI space to others is perhaps no longer
   strictly speaking an EUN, but it is not providing actual Internet
   connectivity - so we do not regard it as an ISP.  A MABOC may or may
   not be an ISP.




Whittle                 Expires September 7, 2010              [Page 12]


Internet-Draft                Ivip Glossary                   March 2010


   MABOCs are also responsible for handling the mapping changes for all
   micronets in their MABs and for running DITRs to advertise these MABs
   and so handle packets addressed to any micronet in the MAB which are
   sent from hosts in networks without ITRs.  MABOCs are also
   responsible for providing multiple QSAs (Authoritative Query Servers)
   which are typically numerous and widely dispersed so that ISPs and
   other networks with ITRs and QSRs (Resolving Query Servers) can
   quickly and reliably obtain mapping for any micronet in this MABOC's
   MABs.  Therefore, a MABOC may run DITRs and QSAs at its own DITR-
   sites, or it may contract another company to perform these functions
   - a DSOC.

2.22.  Mapping

   In a CES architecture such as Ivip, mapping is information which
   tells an ITR which ETR to tunnel a packet to, when the destination
   address matches one of the MAB prefixes - when the packet's
   destination address is in the SPI "edge" subset of the global unicast
   address range.  There is only mapping for SPI addresses.

   In Ivip, a range of contiguous addresses covered by one mapping is a
   "micronet" and the mapping consists purely of a single ETR address.
   In LISP and other CES architectures, 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.

2.23.  Mapping Distribution System

   CES 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 traffic packet the ETR is
   handling .  The device which ultimately controls this mapping could
   be anywhere in the world - and there could be very large numbers of
   such devices, scattered all over the Net. 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 the one authoritative query server (or one of just a few
   such servers) which is the authoritative source of the mapping - and
   which sends back the map reply to the ITR. (e.g.  LISP-CONS, LISP-ALT
   and TRRP.)




Whittle                 Expires September 7, 2010              [Page 13]


Internet-Draft                Ivip Glossary                   March 2010


   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 before DRTM [I-D.whittle-ivip-drtm].)

   From late February 2010, Ivip uses DRTM - in which DSOCs and MABOCs
   push the full mapping database, with real-time updates, to QSAs
   (Authoritative Query Servers) at multiple DITR-sites.  These QSAs are
   not "local" as were the QSDs in the previous approach to Ivip, but
   are typically "nearby" enough to the querying QSRs (Resolving Query
   Servers) to provide mapping replies reliably and within a few tens of
   milliseconds.  DRTM is therefore "push" to the QSA, "pull" in the
   sense of the ITR requesting, via a QSR, from the QSA, the mapping -
   and also "push" from the QSA to the ITRs for any Cache Updates
   changes affecting micronets whose mapping was sent to the ITRs within
   the current caching time.

2.24.  Micronet

   A micronet is a contiguous range of SPI address space which is mapped
   to a single ETR address.  A UAB (User Address Block) 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
   - so they are not restricted to being binary boundary prefixes.  The
   equivalent in LISP is an "EID" prefix.

2.25.  Mobility

   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 - Translating Tunnel Routers) give the host a
   single IP address no matter how or where it is connected.  Such a
   system is the TTR Mobility architecture.  [TTR Mobility]





Whittle                 Expires September 7, 2010              [Page 14]


Internet-Draft                Ivip Glossary                   March 2010


2.26.  MN - Mobile Node

   Mobile Node.  Synonymous with "mobile host".

2.27.  MTU - Maximum Transmission Unit

   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.

2.28.  Multihoming

   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.  This is
   achieved with the currently only approach to multihoming - having the
   EUN advertise its own PI prefix in the DFZ.  CES architectures also
   maintain the host's IP address, but enable multihoming to be done in
   a scalable way - without each EUN's address space being separately
   advertised in the DFZ.

   Another approach, as used by CEE architectures is to have the host IP
   stack manage the host identity (which suitably written application
   programs use to set up and maintain communications with other hosts
   rather than using IP addresses) in a stable way so that applications
   are unaware of the ISP link changes, while operating from either a
   physical (Locator) address obtained from the first ISP or that
   obtained from the second.  CEE use the Locator / Identifier
   Separation naming model for this purpose.

2.29.  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.






Whittle                 Expires September 7, 2010              [Page 15]


Internet-Draft                Ivip Glossary                   March 2010


2.30.  PA - Provider Aggregatable

   Provider Aggregatable - address space, prefix or IP address.
   ("Provider Assigned" is also in common use, but "Provider
   Aggregatable" seems to be more appropriate.  See Brian Carpenter's
   message to the RRG on 2010-02-28.)  Global unicast address space
   which is used by an end-user network (EUN) 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 due to there not
   being too many of such prefixes in the DFZ.  The same large (short)
   prefix which the ISP advertised may be used for its own internal
   purposes and for many other EUNs.  The provider (the ISP) is said to
   be able to aggregate many such PA prefixes into a single prefix of
   its own which it advertises in the DFZ.  ISPs typically do so via
   multiple uptream links to other ISPs or transit providers - so this
   single large (short) prefix is multihomed via these links.

   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 (CEE), 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.

2.31.  PE - Provider Edge router

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

2.32.  PI

   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 and which is advertised as a separate prefix in the DFZ.  SPI
   (Scalable PI) space is also Provider Independent, but each EUN's SPI
   space is not separately advertised in the DFZ.

   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.  PI space is



Whittle                 Expires September 7, 2010              [Page 16]


Internet-Draft                Ivip Glossary                   March 2010


   also too costly to obtain and advertise in the DFZ for many EUNs.  A
   further problem, at least with IPv4, is the convention of not
   propagating prefixes longer than /24 between ASes (Autonomous
   Systems) in the DFZ - so every prefix of PI space uses at least 256
   IP addresses.  See also PA and SPI.

2.33.  PLF - Prefix Label Forwarding

   Prefix Label Forwarding.  The MHF (Modified Header Forwarding)
   technique for IPv6 - as an alternative to encapsulation.  See:
   http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/ .

2.34.  PMTU - Path Maximum Transmission Unit

   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 or RFC 1981 PMTU Discovery process which normally operates
   with all routers between the sending and destination hosts.

2.35.  PMTUD - Path MTU Discovery

   Path MTU Discovery.  RFC 1191 (IPv4) and RFC 1981 (IPv6) 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 unfragmentable) 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.  RFC 1191 and RFC 1981 are
   universally used, but there are some problems.  See the 2010-02-03
   RRG thread "Fred's IPv4 PMTUD research: RFC1191 support frequently
   broken".

   There is also a more complex and recent PMTUD technique - RFC 4821 -
   which has not been adopted to any significant degree.  RFC 4821 does
   not rely on PTBs, but involves stack packetization layers such as TCP
   and the packetization layers of applications discovering the PMTU to
   a host by end-to-end means, and then sharing that PMTU information
   with other such layers.

2.36.  Portability

   "Portable address space" means the ability of an end-user network to
   retain its address space when using different ISPs.  This may involve
   the network having a single link to one ISP - or multiple links, and
   so being multihomed.  Being free to change ISPs is important for



Whittle                 Expires September 7, 2010              [Page 17]


Internet-Draft                Ivip Glossary                   March 2010


   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 this 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".  The impossibility of making renumbering
   acceptably free of cost and risk is in part due to EUNs having the
   addresses of their hosts, or of their entire network, in
   configuration files, DNS zone files, ACLs (Access Control Lists) etc.
   in places outside their direct control.  Having to get these changed,
   correctly, at exactly the right time, is impossible or at least so
   impractical as to preclude renumbering from being a viable approach
   to "ease of choosing ISPs".  Therefore, "portability" of a network's
   address space is the only way of enabling them to choose a new ISP
   without unreasonable cost or risk of disruption.

2.37.  PTB - Packet Too Big ICMP message

   ICMP Packet Too Big message.  Part of RFC 1191 and RFC 1981 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.

2.38.  Query Server

   In Ivip, a "query server" is a server which responds to queries about
   mapping.  See: QSA, QSC, QSD (obsolete) and QSR.

   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



Whittle                 Expires September 7, 2010              [Page 18]


Internet-Draft                Ivip Glossary                   March 2010


   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.

2.39.  QSA - Authoritative Query Server

   QSAs are authoritative mapping query servers for the one or more MABs
   they serve.

   In principle, a single QSA could be authoritative for all MABs, in
   which case it would resemble the now obsolete "QSD".  With DRTM
   [I-D.whittle-ivip-drtm], there is no need for any QSA to carry
   mapping for all MABs, so it is assumed that each QSA carries the full
   mapping database for one or more MABs, but not for all of them.

   QSAs require a secure, robust, real-time feed of mapping updates for
   all the MABs they serve.  QSAs are typically located at DITR-sites.
   Since the DITRs at DITR-sites are likely to be busy, they need a
   close-by QSA - such as a server in the same rack - so as not to have
   to rely on sending packets to a QSA at some other site.  A QSA could
   be implemented in the same device as the DITR, but it is generally
   assumed it would be implemented in a separate COTS server.  The term
   "QSA" applies both to QSAs which serve the one or more local DITRs,
   and to those which handle queries from QSRs (Resolving Query Servers)
   in (typically) nearby ISP networks and EUNs.

   A QSA at a DITR-site is "full-database" for all the MABs this DITR
   site serves.  However, the one DITR-site could have multiple QSAs
   accepting queries from QSRs, and it would be possible for some of
   those QSAs to handle one subset of the DITR-site's MABs and other
   QSAs to handle other subsets.  In principle, it would also be
   possible for a QSA to be located somewhere other than at a DITR site.
   For instance if the MABOC for a set of MABs was happy with having 10
   DITR sites, but wanted to establish a larger number of QSAs to spread
   the query load better, or to be closer to some QSRs than is possible
   with the DITR-sites, then it could run QSAs in other places.

   QSAs need a reliable, robust, feed of mapping updates for all the
   MABs they serve.  How they get this is not at present defined in
   Ivip, since it needs to be achieved solely within the networks of a
   DSOC and however many MABOCs whose MABs the DSOC handles.  The
   limited scaling and interoperability challenges of doing this are
   assumed to be solvable, but in the future it would be good to have a
   protocol by which MABOCs could send updates to DSOCs, and which DSOCs
   could use for their internal real-time fanning out of this
   information to their DITR-sites.





Whittle                 Expires September 7, 2010              [Page 19]


Internet-Draft                Ivip Glossary                   March 2010


2.40.  QSC - Caching Query Server

   Caching query servers responds to map requests from ITRs or other
   QSCs.  Each QSC sends map requests to one or more upstream local QSCs
   and/or QSRs.  Each QSC also receives Cache Update messages from
   whatever device it queries and then passes on Cache Update messages
   to the one or more queriers which were sent mapping for the micronet
   concerned, during the current caching time.

   QSCs are generally always in EUNs or ISP networks.  They are not
   usually used in DITR-sites, since a DITR-site should have its own QSA
   and it probably makes sense for the one or more DITRs at the site to
   query the QSA directly.  However, QSCs could also be used in a DITR-
   site, to reduce the load on the QSA.  Since QSCs cache the map reply
   information they receive, they will sometimes - perhaps frequently -
   be able to answer map requests from their queriers from their cached
   mapping, so eliminating the need to query whatever query server they
   would normally query.  Likewise, if multiple queriers (ITRs or other
   QSCs) have recently (in the current caching time) been sent mapping
   for a given micronet and the QSC receives a Cache Update for that
   micronet, it will send out multiple Cache Update messages to those
   queriers - so saving its upstream QSC or QSR from having to send more
   than one Cache Update.

2.41.  QSD (obsolete term)

   Prior to the introduction of DRTM [I-D.whittle-ivip-drtm] in late
   February 2010, the QSD - Full database query server - played a
   central part in Ivip.

   Each ISP or EUN with its own ITRs was to run within its network one
   or ideally two or three QSDs, each of which received the full feed of
   mapping updates for all MABs.  An EUN with ITRs could also use the
   QSDs of its one or more ISPs.  In March 2010, Ivip no longer needs
   QSDs.  There role is taken by QSRs - Resolving Query Servers.  QSRs
   are caching query servers, but it will remain an option for a QSR to
   be sent full feeds of mapping updates for one or more MABs.  If such
   a QSR received full mapping feeds for all MABs, then it would be
   functioning identically to a pre-February 2010 QSD.  A QSD never
   needs to ask any other device for mapping information, whereas to the
   extent that a QSR is caching, it always has to ask QSAs for mapping
   information.  Ivip should be able to scale to the greatest levels
   required with purely caching QSRs.

2.42.  QSR - Resolving Query Server

   Resolving query server.  With DRTM [I-D.whittle-ivip-drtm], this
   takes the role previously performed by the now obsolete "QSD".



Whittle                 Expires September 7, 2010              [Page 20]


Internet-Draft                Ivip Glossary                   March 2010


   An ISP which has its own ITRs, and or which has customer networks
   with ITRs needs at least one, and ideally two or three, QSRs in its
   network.  EUNs with ITRs can also install their own QSRs, or they may
   be able to use the QSRs of their one or more ISPs instead.

   QSRs answer mapping queries from devices internal to the network in
   which they are located - ITRs or QSCs.  They can also send Cache
   Updates to these queriers.  While an ITR may be configured to send
   queries to one or a few upstream query servers - QSCs or QSRs, always
   in its own network, or in an ISP network used by its own network -
   and while the optional, intermediate, caching QSCs do the same, a QSR
   does not query any server in its own network.  It only queries
   authoritative QSAs, which are typically located "nearby" (within a
   few thousand km).  Since QSAs are typically only authoritative for a
   subset of MABs, each QSA needs to automatically discover two or three
   ideally "nearby" QSAs for each of the MABs in the Ivip system.

   Since MABs will generally be run by a smaller number of MABOCs, and
   since the MABOCs will directly or indirectly run a still smaller
   number of DITR-sites, where the QSAs are located, for each set of
   DITR-sites, the QSA will typically find one or ideally two or three,
   "nearby" QSAs at these sites.  This discovery is done automatically
   and on a continuing basis via a DNS-based system as described in
   [I-D.whittle-ivip-drtm].

2.43.  Replicator (obsolete term)

   Replicators" were a central part of Ivip's mapping distribution
   system until late February 2010, when they were made unnecessary by
   DRTM [I-D.whittle-ivip-drtm].  A Replicator was a COTS server within
   the Ivip fast-push mapping distribution system and is still described
   in [I-D.whittle-ivip-fpr].  A Replicator receives two or more streams
   of update packets from upstream devices, such as other Replicators as
   part of a fully or partially meshed flooding system for rapidly and
   robustly propagating real-time changes to mapping to full database
   query servers (QSDs - also now obsolete).

   As noted in the QSD section above, these are no longer needed with
   DTRM, but remain an option which could be used either within the
   networks of DSOCs or as part of pushing real-time mapping feeds for
   one or more MABs to QSRs, which, instead of being purely caching, are
   made to be full-database for one or more MABS.

2.44.  RIB - 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



Whittle                 Expires September 7, 2010              [Page 21]


Internet-Draft                Ivip Glossary                   March 2010


   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.
   Many routers, in addition to running BGP, also run other routing
   protocols - and the RIB contains routes generated by those systems
   too.

2.45.  SPI - Scalable Provider Independent

   Scalable Provider Independent address space.  The Ivip term for the
   new "edge" 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 DFZ
   control plane.

   The LISP equivalent is "EID".

   Global unicast space which is not SPI is known as "conventional" or
   "core" space - or in LISP, as "RLOC" - space.

2.46.  TE - 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.

2.47.  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 (by TTROCs) and
   are ideally numerous and well connected.




Whittle                 Expires September 7, 2010              [Page 22]


Internet-Draft                Ivip Glossary                   March 2010


   The MN's outgoing packets from its SPI address are sent out to the
   TTR which forwards them to the destination - since the access network
   the MN is connected to will probably not forward packets with such a
   source address.  See: [TTR Mobility].

2.48.  TTROC - TTR Operating Company

   An organization, assumed to be a company, which operates a complete
   (typically global) system of TTRs.  The entire TTR system of a TTROC
   operates as a single system and instructs how MNs choose which TTRs
   to tunnel to.  The MN user is therefore a customer of the TTROC,
   since they pay for access to the TTROCs network of TTRs.

   The MN user may provide their own SPI address space - such as a
   single IPv4 micronet of one IPv4 address - for use by their MN with
   the TTROC's system.  Alternatively, the TTROC may supply this
   micronet - in which case it is either a MABOC or is obtaining the
   micronet from a MABOC.  In both cases, the TTROC controls the mapping
   of the micronet as long as the MN is using its TTR network.

   Multiple TTROCs can compete.  If there was a standardised tunneling
   and management protocol for all MNs to use with all TTRs, then a
   single piece of software in MNs could be used for all TTROC systems.
   Since there is considerable scope for innovation, service
   differentiation etc. in the TTR Mobility field, it may be more likely
   that TTROCs will develop their own specialised software for the major
   types of MN, and distribute this to their MN customers.
   Theoretically a single MN could operate with the TTR systems of
   multiple TTROCs at the same time, but each system would provide it
   with a separate micronet of SPI space.

2.49.  UAB - 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 QSRs
   and QSAs don't work with UABs - they only work with micronets.  As
   with micronets, UABs are of integer length, with any starting point
   within the MAB - and the units are IPv4 addresses or IPv6 /64
   prefixes.

   Each micronet must be fully contained within a UAB - and each UAB
   must be fully contained within a MAB.

2.50.  WAG ...

   Wild Assed Guess.  Technique employed where some kind of figure is
   required, but the constraints on the realistic range for the figure



Whittle                 Expires September 7, 2010              [Page 23]


Internet-Draft                Ivip Glossary                   March 2010


   are unknown or difficult to use precisely.

   Useful for discussing order-of-magnitude questions concerning future
   Internet developments, due to our current inability to obtain data
   about the future.  Similar to "Stab in the Dark", but used for
   serious technical discussions and made with full awareness of its
   speculative nature.












































Whittle                 Expires September 7, 2010              [Page 24]


Internet-Draft                Ivip Glossary                   March 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
   owner's 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
   'L').

   Ivip predates and has absolutely no connection with the UK "IVIP"
   iPhone application.























Whittle                 Expires September 7, 2010              [Page 25]


Internet-Draft                Ivip Glossary                   March 2010


4.  History of Ivip's mapping system

   DRTM (Distributed Real Time Mapping) was first described on the RRG
   list on 2010-02-26, but it took about two weeks to update the IDs
   accordingly.  If you have not read any Ivip material before this, and
   if you are not concerned about critiques of Ivip made according to
   the pre-DRTM version of Ivip, and if you are not interested in
   Replicators, Lost Payload Servers and the like, then there's no need
   to read this section.

   The terms "Plan A" etc. are purely to help describe how the design of
   Ivip's mapping system has progressed - these terms are not used in
   the IDs themselves.

   Plan-A
   2007-07-15: Original system with a tree-like structure of
               Replicators - with the top-level being "Launch
               Servers" with a fancy protocol between them.

                 ivip-arch-00/01/02      } All
                 ivip-db-fast-push-00/01 } obsolete.

   2010-01-13: Same system, but all-new ivip-arch and revised
               ivip-db-fast-push.

                 ivip-arch-03          Completely rewritten.

                 ivip-db-fast-push-02  Better documentation of the
                                       original Launch Server
                                       system.

   Plan-B
   2010-01-18: "Launch servers" replaced by Level 0 Replicators
               which are fully meshed and have a flooding arrange-
               ment which is simpler, faster and more robust.

                 ivip-db-fast-push-03  Significant simplifications
                                       and new material to give an
                                       overview of Plan-B.

                 ivip-fpr-00           All new ID with goals and
                                       non-goals, better description
                                       of Replicators and the best
                                       Plan-B documentation.

   Plan-C
   2010-02-07: Ivip's (short-lived, and not fully documented)
               distributed mapping distribution system which also



Whittle                 Expires September 7, 2010              [Page 26]


Internet-Draft                Ivip Glossary                   March 2010


               used Replicators, but not in a single global system.
               Described in RRG message msg05975.html

               This keeps the Replicator concept, but has no central
               inverted tree structure of Replicators.  Instead, one
               or more ISPs (or large end-user networks) make their
               own small tree (or non-tree-structured mesh) of
               Replicators, and get feeds of mapping changes for the
               MABs of all MABOCs from the one or typically more
               than one mapping coordination companies (now known as
               DSOCs) or the MABOCs themselves - whoever runs the
               nearest one or two DITR-Sites for each MABOC.  So
               there is no central inverted tree of Replicators -
               just smaller trees or meshes or even single QSDs
               getting feeds from MABOC-run DITR-Site sources of
               mapping generally not too far away.

               In Plan-A and Plan-B, the MABOCs were either RUAS
               (Root Update Authorisation Server) companies, or
               contracted RUAS companies to handle the mapping of
               the micronets in their MABs.  The RUAS companies
               collectively ran a decentralised but still unified
               inverted tree-like structure of Replicators to fan
               out mapping changes in real-time all over the world
               to ISPs' full database QSDs.

               In Plan-C, there is no global inverted tree of
               Replicators and the MABOCs invest more and reach out
               to ISPs from their widely distributed DITR-Sites.
               ISPs don't absolutely need ITRs and QSDs (and
               therefore mapping feeds and probably Replicators) but
               they will probably want them after a while (assuming
               some of their customers are using SPI space) since
               having their own ITRs will reduce traffic going out
               to a DITR and returning to these customers' ETRs.

               Missing Payload Servers are also needed so the ISP's
               QSDs can get mapping which is somehow missing from
               the two or more upstream Replicators - due to
               temporary outages affecting the two or more feeds.


   Plan-D
   2010-02-24: DRTM - Distributed Real Time Mapping - no need for
               Replicators, Missing Payload Servers or QSDs.

               ISPs (or EUNs) which want to run their own ITRs can
               still use the Plan-C approach of having their own



Whittle                 Expires September 7, 2010              [Page 27]


Internet-Draft                Ivip Glossary                   March 2010


               full-database QSDs, with full feeds, Replicators,
               Missing Payload servers etc.  However this is
               entirely optional and as far as I know, is not
               required for Ivip to scale well to the largest
               numbers of micronets and EUNs imaginable.


               The main plan is for ISPs (and end-user networks)
               which want ITRs to use new query servers at these
               nearby MABOC-operated (directly or indirectly) sites
               where the DITRs are.  These QSAs (referred to in the
               RRG message as "DITR-Site-QSD query servers") are
               "full database" for the subset of MABs each such
               DITR-site handles.  The ISP's ITRs query these via
               a QSR - which is like a  caching QSC query server but
               which knows, for each MAB, the addresses of two or
               more of these typically "nearby" QSAs authoritative,
               full-database, query servers for each MAB.

               Therefore, the ITRs in an ISP or an EUN are relying
               on full-database query servers are no longer strictly
               "local" - as they were in Plans A, B and C.  They are
               (typically) "nearby".  This means that they are
               normally "close" or "close enough" that delay times
               and query/response packet losses are insignificant.
               So this is fully distributed, but is not a "global"
               query server system like LISP-ALT: with queries and
               responses frequently traversing the Earth - with
               consequent delays, losses and scaling problems.

   Figure 1: History of Ivip's mapping system, to early March 2010.




















Whittle                 Expires September 7, 2010              [Page 28]


Internet-Draft                Ivip Glossary                   March 2010


5.  Security Considerations

   None.
















































Whittle                 Expires September 7, 2010              [Page 29]


Internet-Draft                Ivip Glossary                   March 2010


6.  IANA Considerations

   None.
















































Whittle                 Expires September 7, 2010              [Page 30]


Internet-Draft                Ivip Glossary                   March 2010


7.  Informative References

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

   [I-D.whittle-ivip-drtm]
              Whittle, R., "DRTM - Distributed Real Time Mapping for
              Ivip and LISP", draft-whittle-ivip-drtm-01 (work in
              progress), March 2010.

   [I-D.whittle-ivip-etr-addr-forw]
              Whittle, R., "Ivip4 ETR Address Forwarding",
              draft-whittle-ivip-etr-addr-forw-00 (work in progress),
              January 2010.

   [I-D.whittle-ivip-fpr]
              Whittle, R., "Fast Payload Replication mapping
              distribution for Ivip", draft-whittle-ivip-fpr-01 (work in
              progress), March 2010.

   [TTR Mobility]
              Whittle, R. and S. Russert, "TTR Mobility Extensions for
              Core-Edge Separation Solutions to the Internets Routing
              Scaling Problem", August 2008,
              <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
























Whittle                 Expires September 7, 2010              [Page 31]


Internet-Draft                Ivip Glossary                   March 2010


Author's Address

   Robin Whittle
   First Principles

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












































Whittle                 Expires September 7, 2010              [Page 32]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/