One document matched: draft-whittle-ivip-glossary-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="exp" ipr="trust200902" docName="draft-whittle-ivip-glossary-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev='Ivip Glossary'>
Glossary of some Ivip and scalable routing terms
</title>
<author initials='R' surname="Whittle" fullname='Robin Whittle'>
<organization> First Principles </organization>
<address>
<email>rw@firstpr.com.au</email>
<uri>http://www.firstpr.com.au/ip/ivip/</uri>
</address>
</author>
<date year='2010' month='January' day='13'/>
<workgroup></workgroup>
<keyword>Routing</keyword>
<keyword>Addressing</keyword>
<keyword>BGP</keyword>
<keyword>Scalable Routing</keyword>
<keyword>Routing and Addressing Workshop</keyword>
<keyword>Routing Research Group</keyword>
<keyword>Routing table growth</keyword>
<keyword>Core-Edge Separation Scheme</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Please see the Ivip-arch ID <xref target="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.
</t>
</section>
<section title="Glossary">
<t>
<list style="hanging" hangIndent="6">
<t hangText="BR:">
<vspace />
Border Router of an ISP - where the ISP network connects to the routers of
other networks. See also PE and CE.
</t>
<t hangText="CE:">
<vspace />
Customer Edge router. A router in an end-user network which connects to
one or more ISP networks. See also BR and PE.
</t>
<t hangText="Core-Edge Elimination (CEE):">
<vspace />
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.
</t>
<t hangText="Core-Edge Separation (CES):">
<vspace />
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.
</t>
<t hangText="BGP:">
<vspace />
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.
</t>
<t hangText="COTS:">
<vspace />
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.
</t>
<t hangText="DITR:">
<vspace />
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 which
are sent to them, with full support for portability, multihoming and TE.
</t>
<t hangText="DFZ:">
<vspace />
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".
</t>
<t hangText="DFZ Control Plane">
<vspace />
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.)
</t>
<t hangText="EAF:">
<vspace />
ETR Address Forwarding. The MHF (Modified Header Forwarding) technique
for IPv4 - as an alternative to encapsulation.
</t>
<t hangText="End-user network:">
<vspace />
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.
</t>
<t hangText="FEC:">
<vspace />
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.
</t>
<t hangText="FIB:">
<vspace />
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. 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.
</t>
<t hangText="FMS:">
<vspace />
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.
</t>
<t hangText="IPTM:">
<vspace />
Ivip's "ITR Probes Tunnel MTU" arrangement for handling the PMTUD problems
inherent in encapsulated tunnels between the ITR and ETR.
</t>
<t hangText="ITFH:">
<vspace />
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.
</t>
<t hangText="ITR:">
<vspace />
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 MHF (Modified Header Forwarding) instead of
encapsulation.
</t>
<t hangText="Ivip:">
<vspace />
Internet vastly improved plumbing. The origins of the acronym and guidance on
capitalization are in the section following this Glossary.
</t>
<t hangText="MHF:">
<vspace />
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).
</t>
<t hangText="MAB:">
<vspace />
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.
</t>
<t hangText="MABUS:">
<vspace />
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.
</t>
<t hangText="Mapping:">
<vspace />
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.
</t>
<t hangText="Mapping distribution system:">
<vspace />
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. 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.)
</t>
<t hangText="Micronet:">
<vspace />
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.
</t>
<t hangText="Mobility:">
<vspace />
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.
</t>
<t hangText="MN:">
<vspace />
Mobile Node. Synonymous with "mobile host".
</t>
<t hangText="MTU:">
<vspace />
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.
</t>
<t hangText="Multihoming:">
<vspace />
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.
</t>
<t hangText="Outer header:">
<vspace />
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.
</t>
<t hangText="PA:">
<vspace />
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.
</t>
<t hangText="PE:">
<vspace />
Provider Edge router. A router in an ISP network which connects to
one or more end-user networks. See also BR and CE.
</t>
<t hangText="PI:">
<vspace />
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.
</t>
<t hangText="Portability:">
<vspace />
"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".
</t>
<t hangText="PMTU:">
<vspace />
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.
</t>
<t hangText="PMTUD:">
<vspace />
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 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.
</t>
<t hangText="PLF:">
<vspace />
Prefix Label Forwarding. The MHF (Modified Header Forwarding) technique
for IPv6 - as an alternative to encapsulation.
</t>
<t hangText="PTB:">
<vspace />
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.
</t>
<t hangText="Query Server:">
<vspace />
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.
</t>
<t hangText="QSC:">
<vspace />
Caching query server. Responds to map requests from ITRs or QSCs. Sends map
requests to one or more upstream local QSCs and/or QSDs.
</t>
<t hangText="QSD:">
<vspace />
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.
</t>
<t hangText="Replicator:">
<vspace />
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.
</t>
<t hangText="RIB:">
<vspace />
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.
</t>
<t hangText="RUAS:">
<vspace />
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 Replicator system. Each RUAS company is responsible for
the mapping of typically many MABs.
</t>
<t hangText="Snapshot:">
<vspace />
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.
</t>
<t hangText="SPI:">
<vspace />
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.
</t>
<t hangText="SUMUC:">
<vspace />
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.
</t>
<t hangText="TE:">
<vspace />
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.
</t>
<t hangText="TTR Mobility architecture:">
<vspace />
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 - since the access network the MN is connected to
will probably not forward packets with such a source address. See:
<xref target="TTR Mobility" />.
</t>
<t hangText="UAB:">
<vspace />
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.
</t>
<t hangText="UAS:">
<vspace />
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.
</t>
<t hangText="UMUC:">
<vspace />
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!)
</t>
<t hangText="WAG:">
<vspace />
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.
</t>
</list>
</t>
</section>
<section title="The Ivip acronym">
<t>
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.
</t><t>
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.)
</t><t>
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').
</t>
</section>
<section title="Security Considerations">
<t>
None.
</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
</middle>
<back>
<references title='Informative References'>
<reference anchor='I-D.whittle-ivip-arch'>
<front>
<title>Ivip (Internet Vastly Improved Plumbing) Architecture</title>
<author initials='R' surname='Whittle' fullname='Robin Whittle'>
<organization />
</author>
<date year='2010' month='January' day='13' />
</front>
<seriesInfo name='Internet-Draft' value='draft-whittle-ivip-arch-03' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-whittle-ivip-arch-03.txt' />
</reference>
<reference anchor="TTR Mobility" target="http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf">
<front>
<title>TTR Mobility Extensions for Core-Edge Separation Solutions to the Internets Routing Scaling Problem</title>
<author initials='R' surname='Whittle' fullname='Robin Whittle'>
<organization />
</author>
<author initials='S' surname='Russert' fullname='Steve Russert'>
<organization />
</author>
<date year='2008' month='August' day='28' />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 14:13:59 |