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
draft-whittle-ivip-glossary-00.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 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
BR:
Border Router of an ISP - where the ISP network connects to the
routers of other networks. See also PE and CE.
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.
BGP:
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.
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.
DITR:
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.
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 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
"default".
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
routing.)
EAF:
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.
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.
FIB:
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.
FMS:
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
micronets.
IPTM:
Ivip's "ITR Probes Tunnel MTU" arrangement for handling the
PMTUD problems inherent in encapsulated tunnels between the ITR
and ETR.
ITFH:
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.
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 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.
Ivip:
Internet vastly improved plumbing. The origins of the acronym
and guidance on capitalization are in the section following
this Glossary.
MHF:
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).
MAB:
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.
MABUS:
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.
Mapping:
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.)
Micronet:
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:
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.
MN:
Mobile Node. Synonymous with "mobile host".
MTU:
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
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. 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
second.
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.
PA:
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.
PE:
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
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. 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.
Portability:
"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".
PMTU:
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.
PMTUD:
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.
PLF:
Prefix Label Forwarding. The MHF (Modified Header Forwarding)
technique for IPv6 - as an alternative to encapsulation.
PTB:
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
QSC:
Caching query server. Responds to map requests from ITRs or
QSCs. Sends map requests to one or more upstream local QSCs
and/or QSDs.
QSD:
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.
Replicator:
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
boring.
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 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.
RUAS:
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.
Snapshot:
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.
SPI:
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.
SUMUC:
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.
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.
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
Mobility].
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 QSDs don't work
with UABs - only micronets.
UAS:
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.
UMUC:
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!)
WAG:
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
'L').
Whittle Expires July 17, 2010 [Page 17]
Internet-Draft Ivip Glossary January 2010
4. Security Considerations
None.
Whittle Expires July 17, 2010 [Page 18]
Internet-Draft Ivip Glossary January 2010
5. IANA Considerations
None.
Whittle Expires July 17, 2010 [Page 19]
Internet-Draft Ivip Glossary January 2010
6. 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.
[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 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]