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 (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
2.  Glossary
3.  The Ivip acronym
4.  Security Considerations
5.  IANA Considerations
6.  Informative References
§  Author's Address

1.  Introduction

Please see the Ivip-arch ID [I‑D.whittle‑ivip‑arch] (Whittle, R., “Ivip (Internet Vastly Improved Plumbing) Architecture,” January 2010.) 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.

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.

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

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

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.

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

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 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 - since the access network the MN is connected to will probably not forward packets with such a source address. See: [TTR Mobility] (Whittle, R. and S. Russert, “TTR Mobility Extensions for Core-Edge Separation Solutions to the Internets Routing Scaling Problem,” August 2008.).

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.

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

4.  Security Considerations

None.

5.  IANA Considerations

None.

6. Informative References

Author's Address