idnits 2.17.1 draft-whittle-ivip-glossary-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2010) is 5216 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-whittle-ivip-arch-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Whittle 3 Internet-Draft First Principles 4 Intended status: Experimental January 13, 2010 5 Expires: July 17, 2010 7 Glossary of some Ivip and scalable routing terms 8 draft-whittle-ivip-glossary-00.txt 10 Abstract 12 This glossary is intended to help with the understanding of terms 13 used in the Ivip core-edge separation architecture and of some non- 14 Ivip terms which are pertinent to scalable routing. These are not 15 "official" definitions of terms as used in scalable routing, but I 16 hope they will help newcomers to the field. Please suggest 17 corrections, additions and improvements. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 17, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. The Ivip acronym . . . . . . . . . . . . . . . . . . . . . . . 17 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 64 6. Informative References . . . . . . . . . . . . . . . . . . . . 20 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 1. Introduction 69 Please see the Ivip-arch ID [I-D.whittle-ivip-arch] and other IDs 70 mentioned there for a detailed description of Ivip. Significant 71 developments regarding Ivip are at http://www.firstpr.com.au/id/ivip/ 72 along with links to the IRTF Routing Research Group wiki, mailing 73 list etc. I assume anyone with an interest in scalable routing is 74 keeping up with the RRG mailing list discussions. 76 2. Glossary 78 BR: 79 Border Router of an ISP - where the ISP network connects to the 80 routers of other networks. See also PE and CE. 82 CE: 83 Customer Edge router. A router in an end-user network which 84 connects to one or more ISP networks. See also BR and PE. 86 Core-Edge Elimination (CEE): 87 This class of scalable routing architectures is also properly 88 referred to as "Locator / Identifier Separation" - despite LISP 89 being an example of the other kind of architecture: Core-Edge 90 Separation. CEE is a scalable routing architecture in which 91 hosts in end-user networks gain one or more "Locator" AKA 92 "physical" addresses from each upstream ISP. These addresses 93 can be scalably supplied to many end-user networks, since they 94 are part of larger ISP prefixes. End-user networks do not 95 retain these Locator addresses when they choose another ISP. 96 Host applications use a separate system (separate namespace) of 97 "logical" AKA "edge" or "Identifier" addresses. The host's 98 stack determines how to create addresses for packets which the 99 routing system will use to get the packet to the correct 100 destination network via one of its ISPs, as determined by which 101 "Locator" address the stack affixes to the packet. The 102 "Identifier" addresses are retained by the end-user network no 103 matter which ISPs they use. There are no "core" or "edge" 104 addresses - just two separate systems of addresses: one to 105 identify hosts and the other to use as a routing locator to get 106 the packet from one network to another. All such systems 107 involve changes to existing host stacks and perhaps 108 applications. They generally attempt to be backwards 109 compatible with IPv6 rather than IPv4. Some architectures 110 allow ISP routers to alter locator addresses to control packet 111 flows. Generally, the hosts have to do more work than at 112 present since there are no ITRs or ETRs or the like in the 113 network. The network remains simple, compared to the 114 additional elements added to create a Core-Edge Separation 115 architecture. There is usually at least one additional global 116 mapping lookup system, or an extension to DNS to support 117 mapping lookups, such as using an Identifier to find that 118 host's valid Locator or Locators. HIP and ILNP are examples of 119 Core-Edge Elimination architectures. See also the start of the 120 Architectural Choices section in Ivip-arch. 122 Core-Edge Separation (CES): 123 A scalable routing architecture in which hosts in end-user 124 networks use a subset of the global unicast address space which 125 are called "edge" (AKA "EID" or "SPI") addresses. The 126 remainder of this space retains its current properties and is 127 known as "core" (AKA "RLOC" or "conventional") space. End-user 128 networks retain their edge address space no matter which one or 129 more ISPs they use for Internet access. A system of ITRs, ETRs 130 and a mapping system transports packets addressed to "edge" 131 addresses across the DFZ by tunneling from the ITR to the ETR 132 address. Only a small number of large (short) prefixes need to 133 be advertised in the DFZ to cover very large numbers of these 134 "edge" prefixes (AKA, in Ivip, micronets of SPI space), so the 135 impact on the DFZ is very small. This edge space can be sliced 136 into many small pieces for very large number of end-user 137 networks. The "edge" addresses are separated out from the 138 "core" addresses, but remain part of the same namespace. Only 139 ITRs treat packets differently according to whether the 140 destination address is "edge" or "core". Hosts on both kinds 141 of address communicate normally and the host requires no new 142 protocols or knowledge of whether an address is "core" or 143 "edge". LISP, APT, Ivip, TRRP and TIDR are all CES 144 architectures. See also the start of the Architectural Choices 145 section in Ivip-arch. 147 BGP: 148 Border Gateway Protocol. A protocol by which routers 149 communicate in order that each can develop an optimal, or at 150 least a good, set of best-path rules for its FIB, to handle 151 packets matching all the prefixes the router handles. BGP is 152 used in the DFZ. 154 COTS: 155 Commercial Off The Shelf server - no specific brand. For 156 instance a rack-mount server running Gnu/Linux, BSD, or any 157 other operating system - usually remote controlled, and so 158 without display or keyboard. High performance COTS servers 159 today typically have multicore CPUs from Intel or AMD, 160 gigabytes of RAM and one or more hard drives. 162 DITR: 163 A Default ITR in the DFZ. Previously known as an OITRD (Open 164 ITR in the DFZ) and before that, erroneously, as an "Anycast 165 ITR in the core/DFZ". The LISP equivalent is the PTR (Proxy 166 Tunnel Router). DITRs advertise MABs and so attract packets 167 addressed to SPI space which were sent by hosts in networks 168 which have no ITRs. DITRs (or PTRs) are essential for ensuring 169 that networks adopting SPI (EID) space get all the packets 170 which are sent to them, with full support for portability, 171 multihoming and TE. 173 DFZ: 174 Default-Free Zone. The large subset of the interdomain routing 175 system which consists of routers which have more than one 176 "upstream" link - meaning there is more than one path to "the 177 rest of the Internet". If the router is a BR of an ISP or a 178 PI-using end-user network which connects to the DFZ, then it 179 will have ne or more other links which take packets to this 180 local network. If the router has no "local network" then it is 181 a transit router in the DFZ and is operated by a transit 182 provider. A router at the border of an ISP or PI-using end- 183 user network which has a single upstream link (probably to an 184 ISP network) can have the interface for upstream link as the 185 "default path" in its FIB and RIB. Routers with two or more 186 links to the rest of the Net can't have such a default route, 187 and so are considered to be in the default-free part of the 188 interdomain routing system. DFZ routers need to have a route 189 in their FIB and RIB for every prefix (route) which is 190 advertised in the interdomain routing system. (Often "DFZ" is 191 used to refer to the interdomain routing system.) Since there 192 are 300k or more such prefixes, this means the router needs to 193 have a fast route processor (main CPU) to run its RIB and BGP 194 sessions with neighbours. It also needs a high capacity (and 195 typically very expensive) FIB to figure out, for each incoming 196 packet, which of the 300k+ prefixes best matches the packet's 197 source address. DFZ routers are regarded as being multihomed. 198 A "single-homed" router has a single upstream link. Its RIB 199 and FIB have much fewer demands placed upon them, since they 200 contain routes for the local network, accessible by one or more 201 interfaces, and then a "default" rule, which catches all 202 packets not yet matched, which causes the FIB to forward those 203 packets to the single upstream link. "Single-homed" routers 204 don't need their RIB or FIB to consider all the 300k prefixes 205 which are advertised in the DFZ - just the ones this router 206 advertises. DFZ routers are very expensive and there are an 207 unknown number of them - maybe 100,000 or so of them. They are 208 run mainly by ISPs (who sell connectivity to end-user networks) 209 and transit providers (who sell connectivity to ISPs and other 210 transit providers. DFZ routers may also be operated by larger 211 PI-using end-user networks, such as those of universities, 212 which are multihomed to two or more upstream ISPs, and which 213 choose to send out packets on the link with the optimal path to 214 the destination, rather than just nominating one link as the 215 "default". 217 DFZ Control Plane 218 Broadly speaking, the system of all DFZ routers and their route 219 processors communicating with each other using BGP messages so 220 that each one can determine the optimal (or at least "good 221 enough") best path for packets which are addressed to every 222 prefix (route) which is advertised in the interdomain routing 223 system. The entire global system behaves as a system - 224 although its exact behaviour is not necessarily understood. 225 The "control plane" is separate from the "data plane" - which 226 actually handles traffic packets. The "control plane" includes 227 the RIBs of all the DFZ routers. It is an essential goal of 228 scalable routing to contain the growing load on the DFZ's 229 control plane while providing portability, multihoming and TE 230 for far more end-user networks than currently have these 231 things. (Reducing the load on the DFZ data plane is not 232 possible in terms of the number of packets, but anything which 233 reduces the load by limiting or reducing the number of prefixes 234 in DFZ routers' FIBs, while allowing many more multihoming end- 235 user networks, would also be achieving a vital goal of scalable 236 routing.) 238 EAF: 239 ETR Address Forwarding. The MHF (Modified Header Forwarding) 240 technique for IPv4 - as an alternative to encapsulation. 242 End-user network: 243 A network which is not used for selling Internet connectivity. 244 Most of the end-user networks referred to in scalable routing 245 are those which want or need portability, multihoming and TE. 246 However, this is just a subset of end-user networks. Most end- 247 user networks, such as those of home and SOHO users, are fine 248 without portability, multihoming or TE. 250 FEC: 251 Forwarding Equivalence Class. Within a router, FEC can be 252 thought of as a number of some kind which the FIB chooses for 253 each incoming packet. A simple type of FEC is which interface 254 to forward the packet from. However, routers may maintain 255 multiple queues for packets going out a single interface, so as 256 to give priority to different types of packet. Each such queue 257 would be identified by a different FEC. 259 FIB: 260 Forwarding Information Base. This refers either to the body of 261 data in a router which directly controls how traffic packets 262 are processed, and/or to the hardware and software which 263 performs this plus the data which controls them. Earlier 264 routers had a single FIB, with multiple input/output 265 interfaces. Some modern high-speed routers integrate an FIB 266 into each interface to handle the packets arriving on that 267 interface alone - or have multiple FIBs each dedicated to one 268 or more interfaces. The FIB has arguably the most demanding 269 task of any part of the router - though the interconnect 270 between the interfaces/FIBs is has a daunting task too. 272 FMS: 273 Ivip's Fast push Mapping distribution System. Starts with 274 mapping update commands, being handled by UASes (Update 275 Authorization Servers) and then being passed to a RUAS\ (Root 276 Update Authorization Server), Launch Server and then through 277 several levels of Replicator to the QSD (full database local 278 query server). QSDs respond to ITR requests (perhaps with 279 intermediate caching QSC query servers) and send mapping update 280 commands to ITRs which need them. So the whole FMS links end- 281 user networks, or their appointees, to ITRs which are tunneling 282 packets which are addressed to one of the end-user network's 283 micronets. 285 IPTM: 286 Ivip's "ITR Probes Tunnel MTU" arrangement for handling the 287 PMTUD problems inherent in encapsulated tunnels between the ITR 288 and ETR. 290 ITFH: 291 ITR Function in sending Host. An ITR which is implemented 292 purely by software which is added to a host, and which only 293 processes the packets that host sends. 295 ITR: 296 Ingress Tunnel Router. An existing router, or a function 297 within a server or existing host, which accepts packets 298 addressed to an SPI address and which alters the packet in some 299 way so the DFZ routing system (plus any internal routers of 300 ISPs and end-user networks which are on path) will transport 301 ("tunnel") the modified packet to an ETR, which reverses the 302 modifications and forwards the packet to the destination 303 network. ITRs need to look up some mapping for each packet - 304 and they need to get the mapping quickly when a packet arrives 305 which they have no cached mapping for. The ITR then caches the 306 mapping for some time, so it can handle packets addressed to 307 this address (or any other address in the micronet which 308 contained the first packet's destination address) without 309 requesting mapping again. ITRs in the DFZ are called DITRs. 310 An ITR function in a sending host is called an ITFH. ITRs in 311 other core-edge separation schemes always use encapsulation to 312 tunnel the packet to the ETR. Ivip ITRs will be able to use 313 MHF (Modified Header Forwarding) instead of encapsulation. 315 Ivip: 316 Internet vastly improved plumbing. The origins of the acronym 317 and guidance on capitalization are in the section following 318 this Glossary. 320 MHF: 321 Modified Header Forwarding. An method for ITR tunneling 322 traffic packets to an ETR - as an alternative to encapsulation. 323 The IP header is modified, so all routers between the ITR and 324 ETR must be upgraded to handle the new format. For IPv4: ETR 325 Address Forwarding (EAF) and for IPv6: Prefix Label Forwarding 326 (PLF). 328 MAB: 329 Mapped Address Block. A DFZ-advertised prefix containing SPI 330 space - typically the UABs and their constituent micronets for 331 many end-user networks. This is an Ivip term with no 332 equivalent in LISP, although LISP too has the same concept. 333 The MABs are advertised by ITRs in the local routing system and 334 by DITRs in the DFZ. 336 MABUS: 337 Mapped Address Block Update Stream. A second-by-second stream 338 of mapping updates, assembled by an RUAS, from potentially many 339 of its subsidiary UASes. Contains all the mapping updates for 340 a given MAB which the RUAS is responsible for. 342 Mapping: 343 Information which tells an ITR which ETR to tunnel a packet to, 344 when the destination address (always in the SPI subset of the 345 global unicast address range) matches a particular micronet. 346 In Ivip, the mapping of a micronet consists purely of a single 347 ETR address. In LISP and other core-edge separation schemes, 348 the mapping of an EID prefix (~AKA "micronet") typically 349 consists of multiple ETR addresses with various priorities and 350 weightings so the ITR (or Default Mapper, in APT) can choose 351 one for the purposes of load balancing TE and/or multihoming 352 service continuity. 354 Mapping distribution system: 355 Core-Edge Separation architectures need a method by which ITRs 356 can quickly find the mapping which applies to a particular 357 "edge" (AKA SPI or EID) address which is the destination 358 address of a packet. The device which physically controls this 359 mapping could be anywhere in the world - and there could be 360 very large numbers of such devices, scattered all over the Net. 362 The Mapping Distribution system is how the ITRs get the mapping 363 - as quickly and reliably as possible. Full-push mapping 364 distribution involves all mapping being pushed to all ITRs, so 365 the ITR already has the mapping. (e.g. LISP-NERD.) Full-pull 366 involves a global system by which the ITR's request is directed 367 to an authoritative query server which has the mapping - and 368 which sends back the map reply to the ITR. (e.g. LISP-CONS, 369 LISP-ALT and TRRP.) A third approach is to push all mapping to 370 "local" full database query servers, such as in each ISP. ITRs 371 request mapping from these. (e.g. APT and Ivip.) 373 Micronet: 374 A contiguous range of SPI address space which is mapped to a 375 single ETR address. A UAB contains one or more micronets. The 376 units of splitting SPI space are IPv4 addresses and IPv6 /64s. 377 Micronets and UABs are integer numbers of these units. The 378 equivalent in LISP is an "EID" prefix. 380 Mobility: 381 Mobility in TCP/IP networks refers not directly to a host being 382 physically mobile and connecting to different networks. Nor 383 does it necessarily imply the device has wireless interfaces to 384 those networks. It generally refers to the ability of a host 385 to maintain its communication sessions while it is changing its 386 physical point of connection. Some mobility systems meet these 387 requirements by giving the host the same IP address no matter 388 where it physically connects to a particular access network. A 389 global approach to mobility would enable session continuity 390 when the host connects to any network at all, and so may have 391 completely different IP addresses from time-to time. One 392 approach is to use special IP protocol stack capabilities so 393 applications are not affected by changes in physical address. 394 Another is to keep the current host stack and (with some 395 additional software and usually the involvement of some devices 396 in the network, such as ITRs and TTRs) give the host a single 397 IP address no matter how or where it is connected. 399 MN: 400 Mobile Node. Synonymous with "mobile host". 402 MTU: 403 Maximum Transmission Unit. The maximum length of a packet, 404 measured in bytes, which a particular interface of a router, or 405 the data link it drives, can handle. See also PMTU and PMTUD. 407 Multihoming: 408 The ability of an end-user network (as large as a corporation 409 network, or as small as a home network or handheld wireless 410 device) to maintain all its communication sessions, and the 411 identity of all its hosts, when the connection it is using via 412 one ISP fails, and is replaced quickly by that of another ISP. 413 One way of doing this is to ensure the hosts never see any 414 changes - that is, the hosts always retain their own IP 415 addresses. Another is to have the host IP stack manage the 416 host identity address in a stable way so that applications are 417 unaware of the ISP link changes, while operating from either a 418 physical address obtained from the first ISP or that obtained 419 from the second. Core-edge separation schemes use the former 420 technique and core-edge elimination schemes usually use the 421 second. 423 Outer header: 424 When a packet AA is encapsulated, another one or more headers 425 is prepended to it. The outer header is the IP header of the 426 new packet BB which contains just the original packet AA 427 (Ivip), or (LISP) a UDP header and a LISP header, which is 428 followed by the AA packet. The destination address of the 429 outer header will be recognised by all routers and the packet 430 will be forwarded towards that address - which in the case of 431 ITR encapsulation, will be an ETR which can decapsulate the 432 packet an forward it to the destination network. 434 PA: 435 Provider Assigned - address space, prefix or IP address. 436 Global unicast address space which is used by an end-user 437 network and comes from an ISP's prefix. Typically the prefix 438 it comes from is a large (short) prefix which is therefore not 439 a problem in terms of scalable routing, and which the ISP uses 440 for its own internal purposes and for many other end-user 441 networks. PA prefixes are good for scalable routing, but bad 442 for any end-user network which wants portability, since they 443 only get these particular addresses with a particular ISP. 444 Likewise, unless special techniques are used, an end-user 445 network can't achieve multihoming (with session continuity 446 during an outage of one ISP or the link to that ISP) with PA 447 space - or inbound TE. See also PI space. 449 PE: 450 Provider Edge router. A router in an ISP network which 451 connects to one or more end-user networks. See also BR and CE. 453 PI: 454 Provider Independent address space, prefix or IP address. 455 Global unicast address space which is used by an end-user 456 network and which the network retains no matter which ISPs it 457 uses for connecting to the Net. PI space is good for the end- 458 user network, since it is portable and can be used for 459 multihoming and TE, with full session continuity in the event 460 of failure, by having its two or more ISPs advertise the prefix 461 in the DFZ - or to have one advertise it and the other 462 advertise it if the link to the first ISP fails. This use of 463 PI prefixes is bad for routing scalability, since each such PI 464 prefix and any changes to its advertisement is an additional 465 burden on all DFZ routers and on the DFZ control plane in 466 general. See also PA and SPI. 468 Portability: 469 "Portable address space" means the ability of an end-user 470 network to retain its address space when using any ISP. This 471 may involve the network having a single link to one ISP or it 472 having multiple, and so being multihomed. Being free to change 473 ISPs is important for competition and flexibility. While there 474 have been proposals, especially for IPv6, to make it easy to 475 change host and network addresses so as to make it easy to 476 change to a new ISP's PI address space, this has never been 477 accepted as providing the convenience, low cost and reliability 478 of actual portable address space. "Ease of choosing ISPs" has 479 been one way of stating a major goal of scalable routing, and 480 some people have stated it in terms of assuming the end-user 481 network can't keep its own address space: "ease of renumbering 482 when changing ISPs". However, the only practical way the needs 483 of end-user networks can be met when choosing another ISP is to 484 retain the current address space - which means this address 485 space must be "portable". 487 PMTU: 488 Path MTU. The MTU (maximum packet length, in bytes) not of a 489 single interface but of a path from one device to another - and 490 so of all the devices, input and output interfaces and data 491 links in that path. In a core-edge separation architecture the 492 PMTU of most interest is that between the ITR and the ETR, 493 since encapsulation disrupts the RFC 1191 PMTU Discovery 494 process which normally operates with all routers between the 495 sending and destination hosts. 497 PMTUD: 498 Path MTU Discovery. RFC 1191 PMTUD is a protocol by which the 499 sending host can try sending different length packets (which 500 must be unfragmentable in IPv4: DF=0 - in IPv6, all packets are 501 fragmentable) to a destination host and being able to choose 502 the longest packet length which will fit in the PMTU, by using 503 ICMP PTB (Packet Too Big) messages from any router where the 504 packet will not fit within the next-hop MTU. There is also a 505 more complex and recent PMTUD technique - RFC 4821. This does 506 not rely on PTBs, but involves applications discovering the 507 PMTU to a host by end-to-end means, and then sharing that PMTU 508 information with other applications. RFC 1191 is universally 509 used and as far as I know, RFC 4821 is hardly used at all. 511 PLF: 512 Prefix Label Forwarding. The MHF (Modified Header Forwarding) 513 technique for IPv6 - as an alternative to encapsulation. 515 PTB: 516 ICMP Packet Too Big message. Part of RFC 1191 Path MTU 517 Discovery (PMTUD). Ordinarily sent to the sending host by a 518 router which determined that the packet was too long for either 519 the data link or next device in the next-hop. The PTB includes 520 initial parts of the original packet, and an MTU number which 521 the sending host can use as a maximum packet length, so that 522 future packets will not breach this limit. When ITRs use 523 encapsulation to tunnel packets to an ETR, the routers between 524 the ITR and ETR are unable to generate a valid PTB to the 525 sending host (unless they were specially modified, in some 526 way). So the ITR has to take care of whatever MTU limits exist 527 between it and the ETR, and generate PTBs to the sending host 528 in order to ensure its packets are not longer than the PMTU 529 (Path MTU) of the path to the ITR. 531 Query Server: 532 In Ivip, a "query server" is a server which responds to queries 533 about mapping. The querier may be an ITR or a caching query 534 server (QSC). Full database query servers are QSDs. Ivip QSDs 535 and QSCs remember the map replies they sent, with their caching 536 times, and will send a mapping update message to whichever 537 device (an ITR or a QSC) made the query, if the mapping changes 538 during the caching time. LISP and APT do not use the term 539 "query server", but I use it to describe whatever it is in 540 these architectures which responds to the ITR's request for 541 mapping. In LISP-ALT, the query servers are either ETRs or 542 MSes (Map Servers) - and are distributed all over the Net. So 543 LISP ALT is a global query server system. APT's query servers 544 are local to the ISP and are called Default Mappers. 546 QSC: 547 Caching query server. Responds to map requests from ITRs or 548 QSCs. Sends map requests to one or more upstream local QSCs 549 and/or QSDs. 551 QSD: 552 Full database query server. Responds to map requests from ITRs 553 or QSCs. Receives a full feed of mapping updates from two or 554 more upstream Replicators. 556 Replicator: 557 Server within the Ivip fast-push mapping distribution system. 558 Receives two or more streams of update packets from upstream 559 devices (Replicators or Launch servers) with each stream's set 560 of packets containing identical mapping data. Failure of one 561 packet to arrive from one stream will usually be covered by the 562 arrival of a packet with the the same payload from another 563 stream. As soon as the first packet for a given payload 564 arrives, the Replicator generates 20 or so packets with this 565 payload, to downstream devices, which may be Replicators or 566 QSDs. The Replicator system can be viewed as creating multiple 567 parallel multicast fan-out trees, and cross linking them at all 568 levels. Alternatively it can be viewed as a directional 569 flooding scheme in which 8 Launch servers flood a larger number 570 of level 1 Replicators which instantly flood a still larger 571 number of level 1 Replicators. Flooding increases total 572 bandwidth used, and greatly improves robustness, without 573 slowing down the propagation of information. If this term is 574 too reminiscent of a sci-fi monster, I could call them Directed 575 Flooding Mapping Dissemination Servers or something similarly 576 boring. 578 RIB: 579 Routing Information Base. Within a router, the RIB is the body 580 of data - as maintained by software which controls the route 581 processor (administrative CPU of the router) - by which the 582 router decides how it will handle traffic packets. When the 583 router is running BGP (as all DFZ routers do) the RIB is not 584 just a product of messages received, but also controls the BGP 585 messages which will be sent to neighbours. The RIB is used to 586 generate data which is written into the FIB so the FIB 587 classifies, processes and forwards packets in the manner 588 specified by the RIB. 590 RUAS: 591 Root Update Authorization Server. Each RUAS organisation runs 592 one of these to coordinate its output of mapping changes each 593 second to the Launch server system which sends them to the 594 Replicator system. Each RUAS company is responsible for the 595 mapping of typically many MABs. 597 Snapshot: 598 Compressed data containing full mapping information for a MAB, 599 at a particular instant in time. Produced by the RUAS which is 600 responsible for the MAB. Downloaded by QSDs when intializing 601 their database, or re-synching after some kind of corruption or 602 loss of updates. 604 SPI: 605 Scalable Provider Independent address space. The Ivip term for 606 the subset of the global unicast space which is suitable for 607 end-user networks, providing portability, multihoming and 608 inbound TE in a manner which is "scalable" - does not overly 609 burden the interdomain routing system (~AKA DFZ routers). The 610 LISP equivalent is "EID". Global unicast space which is not 611 SPI is known as "conventional" - or in LISP, as "RLOC" - space. 613 SUMUC: 614 Signed User Mapping Update Command. Body of data containing a 615 UMUC (mapping changes for the UAB of a particular end-user) but 616 signed by the UAS which accepted these commands. A SUMUC is 617 accepted by a downstream system - an RUAS or another UAS - as 618 being valid, on account of the signature being validated. 620 TE: 621 Traffic Engineering. Most references to TE in the scalable 622 routing field refer to inbound TE - steering incoming traffic 623 streams between two or more ISPs and their data links. Both 624 inbound and outbound TE is typically practised to balance 625 traffic volumes over multiple links to make best use of each 626 link's capacity. Other reasons for preferring one link over 627 another for particular subsets of the total traffic include one 628 link being more reliable, lower latency or lower cost. Also, 629 it may be desired for various policy reasons to avoid some 630 traffic traversing one link, which would cause it to pass 631 through some ISP or country jurisdiction which was not desired. 633 TTR Mobility architecture: 634 A Translating Tunnel Router behaves like an ETR to the core- 635 edge separation scheme and communicates with the Mobile Node 636 (MN) by a two-way tunnel initiated by the MN. The TTR is 637 ideally topologically close to the MN - no more than 1000km or 638 so distant. The MN tunnels to one or more TTRs. TTRs are 639 commercially operated and are ideally numerous and well 640 connected. The MN's outgoing packets from its SPI address are 641 sent out to the TTR which forwards them to the destination - 642 since the access network the MN is connected to will probably 643 not forward packets with such a source address. See: [TTR 644 Mobility]. 646 UAB: 647 User Address Block. A contiguous range of SPI address 648 controlled by a single end-user network. May be used as a 649 single micronet or split into multiple micronets. A MAB 650 typically contains many UABs. ITRs, QSCs and QSDs don't work 651 with UABs - only micronets. 653 UAS: 654 Update Authorization Server. Either the end-user interface 655 system by which RUASes interact with customers of the RUAS 656 company, or a system owned by another company which does the 657 same job - for other end-user networks. An RUAS may delegate 658 responsibility for one or more MABs it is responsible for to 659 one or more UASes, including having a UAS handle the mapping of 660 one or more MABs. 662 UMUC: 663 User Mapping Update Command. After an end-user, or some person 664 or device with the credentials provided by the end-user, 665 executes a mapping change command with a UAS, this is the body 666 of data containing that change. This may include a set of 667 changes to multiple micronets, including changing their ETR 668 address, and joining or splitting them into different 669 micronets. (Sorry about the muddy sounding acronyms!) 671 WAG: 672 Wild Assed Guess. Technique employed where some kind of figure 673 is required, but the constraints on the realistic range for the 674 figure are unknown or difficult to use precisely. Synonymous 675 with Stab in the Dark. 677 3. The Ivip acronym 679 The "vip" in "Ivip" comes from the 1961 Doris Day, Rock Hudson and 680 Tony Randall romp "Lover Come Back". Advertising executive Jerry 681 Webster (Rock Hudson) finds himself in trouble - from which he 682 believes he can extract himself by convincing a dancer (Edie Adams) 683 that he will introduce her to Hollywood by making her the star of a 684 promotional campaign for a hot new product. She is keen and keeps 685 asking him what the product is. Casting his eyes around the room, he 686 sees a newspaper with a headline about a VIP. "Vip!" he exclaims - 687 and spends the rest of the movie trying to figure out what this great 688 new product will be. 690 Capitalization of the four characters is user selectable but defaults 691 to "Ivip". Lower-case 'i' is not recommended since "iVIP" might be 692 mistaken for an abrasive bath and sink cleanser from Apple Inc. (A 693 low cost product for those unable to afford a Macintosh computer or 694 i**** product - the mere possession of which instantly renders the 695 whole dwelling spic-and-span.) 697 The capital 'I' raises a potential problem with sans-serif fonts such 698 as Helvetica, since it is indistinguishable from lower-case "L". 699 This has bedevilled the 3GGP term "Iub" (capital 'i') which seems to 700 be more widely known outside the organisation as "lub" (lower-case 701 'L'). 703 4. Security Considerations 705 None. 707 5. IANA Considerations 709 None. 711 6. Informative References 713 [I-D.whittle-ivip-arch] 714 Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 715 Architecture", draft-whittle-ivip-arch-03 (work in 716 progress), January 2010. 718 [TTR Mobility] 719 Whittle, R. and S. Russert, "TTR Mobility Extensions for 720 Core-Edge Separation Solutions to the Internets Routing 721 Scaling Problem", August 2008, 722 . 724 Author's Address 726 Robin Whittle 727 First Principles 729 Email: rw@firstpr.com.au 730 URI: http://www.firstpr.com.au/ip/ivip/