Running Internet protocols on top of the Connectionless Network Protocol can solve the Internet’s addressing and routing problems.

RmW.8D....H Dave Katz and Peter S. Ford

he Internet has evolved considerably from the growth rate since 1990. This graph only its original role of supporting research encompassesthose networks that are part of the pub- in packet-switched computer networking. liclnternet; thereis agreaternumberofIPnetworks In the last decade,the Internet has become allocated that are not connected to the global the computer network infrastructure public Internet. for the global research and education community. During the 1990s, the Internet continues to Limitations of IF Addressing evolve to meet the networkingrequirements of both IP addresses are fixed-length, four-octet values, the public and private sectors. The growth in net- addressing up to 4 billion hosts. IP source and works and hosts connected to the Internet has destination addresses are located in fixed loca- revealed problems in addressing and routing the tions in an IP header, so simply changing the Internet Protocol (IP)[21]. We propose using the length of IP addresses would require changingevery Connectionless Network Protocol (CLNP) [7] IP protocol engine. The designers of the Internet supported by the associated OS1 routing proto- suite of protocols did not anticipate the applica- cols, as a replacement for IP. The basis of the tion of IP in the environment of the large num- proposal is to run the Internet transport proto- bers of hosts and networks that the advent of cols, the Transmission Control Protocol (TCP) microprocessor technology makes possible: and the User Datagram Protocol (UDP), on top “TCP addressingis intimatelybound up in rout- of CLNP in an approach known as TCP and UDP ing issues,since a HOSTor GATEWAY must choose with bigger addresses (TUBA) [l]. a suitable destination HOST or GATEWAY for This paper details the fundamentals of CLNP an outgoing internetwork packet. Let us postu- and the OS1 connectionlessrouting architecture, the late the followingaddress format for the TCP address. operation of the IP suite with CLNP replacing IP, The choice of network identification (eight bits) the support of Internet applications operating on allows up to 256 distinct networks. This size top of TUBA, and a transition plan to a TUBA seems sufficient for the foreseeable future. Similarly, Internet. the TCPidentifier field permits up to 65,536 distinct TCPs to be addressed, which seems more than sufficient for any given network.” [3] Problems with Internet Growth Local areanetworks (LANs) have led togreater Growth use of computer networks and a reinvestigation Availability and use of the IP suite has resulted in of the IP address structure. The four-octet address many researchnetworksusing TCPAP, e.g.,the NASA space is currentlypartitioned into the following three Science Internet, the Department ofEnergy’s Ener- unicast address classes (see Fig. 2): gy Sciences Network, the European IP Backbone Class A - one octet of network id, three octets (EBONE), and Japan’s Widely Integrated Dis- of host id; tributed Environment (WIDE). U.S. and interna- 126 networks, 16 million hostshetwork. tional research networks subsequently have Class B - two octets of network id, two octets of interconnected,resulting in today’sInternet. Demand host id; DAVEKATZisa software for computer networking outside the research 16,000 networks, 65,000 hostslnetwork. engineer at Cisco Systems, and education community contributes to the con- Class C - three octets of network id, one octet Inc. tinued growth of the Internet. of host id; The growth in the number of individual net- 2 million networks, 250 hosts/network. PETERS. FORDisamem- works connected to the Internet is illustrated in ber of the technicalstaffat Fig. 1. The interconnection of organizations outside General Scaling Issues Los Alamos National Labo- of the research and educationcommunity has opened Scalability of aprotocol involvesmore thanjust being ratory. up a large market for Internet services as seen in able to address large numbers of hosts. As the

38 0890-8044/92/$03 00 OIEEE IEEE Network May 1993

--I_--____ - _- ._ ~-~ Internet grows, routing databases must grow more slowly than linearly with respect to the number of addressable hosts. To accomplish this, network addresses should (to some measure) reflect network topology - the greater the congruencebetween the address hier- archy and the network topology,the greater the abil- ity to use topological abstraction to reduce the size of routing information. This implies the need for multiple levels of hierarchy, and sufficiently flex- ible address structure and assignment to support them. Network addresses must be carefully assigned to achieve significant reductions in routing data base size. Wholesale addressing changes may be nec- essary as site connectivity is altered to avoid address- ing entropy. Routing protocols need to allow exceptions to the addressing hierarchy to be sup- ported at a reasonable cost, to ease addressing transitions and provide for the attachment of net- works to multiple service providers. Scaling Problems of IP Internet routing treats IP network numbers as a set of flat identifiers, with each network requiring a routing table entry. As a result, Internet routing becomes less tractable with respect to processor and memory requirements as the number of IP net- work addresses increases. Demand for Class B addresses will result in exhaustion of the B space before 1995.Then, Class C addresseswill be assigned to new Internet sites, and sites with more than 254 hosts will need to use multiple network addresses. The current load of 10,000 networks W Figure 1. Networks routed by NSFNET already taxes the routing infrastructure of the Internet, and the current system will not scale to 2 million Class C networks. Class A address Asolution to thescalingproblemsofthe IProut- I I I ing system is to hierarchically assign IP network 1 Onnnnnn I hhhhhhhh i hhhhhhhh i hhhhhhhh 1 addresses by allocating blocks of addresses to I I I sites from a block of addresses assigned to their Class 8 address network service provider. The routing system then routes blocks of addresses instead of routing I I I I 1-1 lOnnnnnn i nnnnnnnn I hhhhhhhh i hhhhhhhh 1 individual networks.Sites served by a single provider I I lie within a block, so routes to all of those sites may be represented by the single routing entry Cbsc address for the provider, allowing for significant abstrac- I: tion in the routing system. The application of 1 1 llOnnnnnn i nnnnnnnn i nnnnnnnn I hhhhhhhh 1 these techniques to IP is known as Classless I I I Interdomain Routing (CIDR) [SI, since the class structure of IP addresses is no longer used to n-mtworfcaddrassbit identify elements in the routing system. Although h-horti-bit CIDR has the potential to extend the useful life W Figure 2. Classes of IP addresses. of IP, it does not address the fundamental limita- tions of 32-bit addresses. cols, scaling to the size of a ubiquitous global internetwork can be achieved. By using the exist- Beyond 32-Bit Addresses ing Internet transport and application protocols, CIDR addresses the immediate routing limita- it is possible to continue to use the broad base of tions of IP. As the Internet becomes a global existing Internet applications on top of a CLNP public internet, it must be able to address all possible infrastructure. computer systems that wish to communicate. One can imagine each telephone termination evolving into a computer network, and that over time Motivation for TUBA there may be more computers(networks?) than there he TUBA approach is motivated primarily for are people. Thus, the global internet must be able T pragmatic reasons. CLNP and its associatedpro- to support millions, or perhaps billions of net- tocols are mature technologies, forwhichboth router works, connecting several billion hosts. and host implementations already exist in off-the- CLNP retains the overallarchitecture of IP, but shelf products from vendors. Furthermore, CLNP provides a much larger and more flexible address service in the Internet already is being deployed space. In conjunction with the OS1 routing proto- by many service providers. TUBA provides a way

39 ment), the DSP contains a DSP format identifier (effectively a version number), an administrative authority identifier (identifying the next level admin- I I istrative authority), a routing domain identifier, a i~~~ -___ reserved field (for future expansion), an area ID, Figure 3. OSI NSAP. ,a system ID, and an NSAP selector. OS1 NSAPaddresses were designed to be large enough to contain embedded addresses from other numbering plans, such as X.121 and E.164 addresses. Although primarily intended as a means of delegating address administration, these may prove to be useful as a way of deter- mining subnetwork address bindings if ubiquitous level-2 services (e.g., ATM) become available. On the surface, the ability to support multi- Figure 4. GOSIP NSAP address structure. ple address formats may seem needlessly complex and difficult to implement.In fact, however, the rout- to leverage this investment in development, ing protocols do not require a single, fixed, deployment,and trainingto addressthe growth prob- address structure to operate efficiently. Similarly, lems of the Internet. hosts do not need to know anything about the TUBA is explicitly not revolutionary, but structure of addresses, viewing them as opaque only evolutionary. Although some may believe strings.Furthermore, the ability to define new address that radical new technologies are necessary to structures allows for flexibility in the face of provide for data communication needs in the future technologies and deployment require- 1990s and beyond, it does not seem feasible to ments. This extensibility removes the need to define abandon the current internetwork paradigm, a single, fixed, global addressing plan. given the time required to design, implement, debug, One aspect about OS1 addressing that sets it and deploy protocols that are currently in the research apart from IP addressing is that network address- phase, if reliable and ubiquitous connectivity is to be es generally are assigned to systems, rather than maintained. Of course, research and develop- to interfaces. Routers and multihomed hosts typi- ment efforts into new approachesto data networking cally need only one address. Furthermore, there should be pursued, while preserving the integrity is no conceptual equivalent to an IP subnet of the global networking infrastructure. address (effectively the address of the subnet- work itself, e.g., a piece of Ethernet cable). Iden- tifying hosts instead of interfaces simplifies Addressing configuration, and can add robustness - if an etwork layer addresses for TUBA are stan- interface on an IP system fails, packets destined N dardOSInetworkservice access point (NSAP) to that interface’s IP address may be undeliver- addresses [6]. These are defined to be variable length able, even when the system is reachable through of up to 20 octets, although it is worth noting that another interface. This is not an issue if addresses CLNP itself does not impose this address length are not bound to interfaces. limitation (CLNP uses an octet to represent NSAP lengths and could support addresses approaching 100 octets in length, but thisshouldnot CLNP be necessary). he heart of the TUBAproposal is the OS1 CLNP The format of an NSAP address is shown T [7].Semantically it is similar to IP; in fact, it orig- in Fig. 3. The authority and format identifier inally was derived from IP. It is a datagram proto- (AFI) is an addressing plan identifier used to dis- col, carrying full source and destination addresses criminate between addressing and numbering plans in every packet. Independence from frame-sizecon- from internationally recognized organizations. straints imposed by subnetwork media is provid- IS0 and CCITT assign AFI codepoints to organi- ed by a fragmentationheassembly mechanism. zations willing and able to administer addressing Optional features include source routing and plans. The AFI and initial domain identifier route recording, as well as multiple types of ser- (IDI), taken together as the initial domain part (IDP), vice. Error diagnostics are provided by error describe the administrative authority for this part report packets. Echo request and reply packets of the address space. The administrative authori- provide low-level diagnostic capability. ty may be a country, a multinational entity, or Work is progressing at this time on exten- some other body. sions to CLNP, including network layer multicast Following the IDP is the domain specific capabilities, arbitrary packet coloring for policy part (DSP), which is formatted according to the routing purposes, and more flexible type of ser- authority described in the IDP. The DSP typically vice selection. is a combination of administrative and topologi- cal information. The last octet of the DSPis the NSAP Routing selector. This field is used to select among multi- ple transport layer entities in a system, serving much he OS1 network layer has a full complement the same function as a protocol ID field in other pro- T of routing protocols. TUBA uses these rout- tocols. ing protocols without modification. One example of a full NSAP address format The OS1 routingframework [8] describes aglob- is the0nedefinedbyU.S. GOSIP (Fig.4) [16].Oper- al routing environmentdivided into routing domains. ating under IDP 47/0005 (United States govern- A routing domain is a set of hosts, routers, and

40 IEEE Network May 1993 __ - - subnetworks operated according to a single policy model (most likely by a single administrative author- ity). A routing domain is expected to be very tightly coupled in terms of its routing, with a high degree of trust between member routers. Routing domains should be able to contain many thou- sands of hosts and still operate efficiently. Routing between domains, or interdomain rout- ing, iscontrolled by policy issues, rather than bypure- ly topological issues. Interdomain routing is expected to be much more loosely coupled, with only limit- edtrust between routing domains. Since it is respon- sible for establishing ubiquitous connectivity, interdomain routing must be able to scale to arbi- trarily large internetworks. W Figure 5. ES-IS routing. Routers and hosts are modeled with very dif- ferent capabilities. Thephilosophical approach used is that hosts should have virtually no routing Note that, in most cases, the frequencyof adver- intelligence whatsoever, allowing them to con- tisement by hosts can be set quite low, to reduce band- centrate on running applications, and avoiding archi- width utilization on shared media with many tectural limitations that could cause future hostspresent. Thecase of aroutercommencingoper- problems. ations on a subnetwork can be optimized by hav- ing the hosts send unicast hello packets to the router Routing Between Hosts and Routers when they first hear its hello packet. Routing between hosts (end systems) and routers (intermediate systems) is accomplished using the Populating Host Routing Caches - When a end system to intermediate system (ES-IS) protocol host wishes to emit a CLNP packet, it examines [9]. The ES-IS protocol has three major func- itsroutingcache to seewhether it has any information tions: the announcement of reachability between about the destination NSAP address. If so, the pack- hosts and routers (using hello packets), the popu- et is forwarded to the next hop subnetwork lation of host routing caches (using redirect pack- address contained in the cache. ets), and the configuration of host NSAP addresses If the host does not have any cached infor- (using assign address packets). mation about the destination address, the host simply forwards the packet to any router on the Reachability Maintenance - Hosts and routers subnetwork (because of the adjacency list built from periodically send one another ES-IS hello pack- incoming IS hellos). The router can be chosen by any ets that contain their network addresses. Two local algorithm. If the router chosen by the host multicast subnetwork addresses are used, one is not the best path to the destination (either because with the semantic “all routers,” and the other with the destination is better reached through another the semantic “all hosts.” Hosts typically do not router, or because the destination ison thesame sub- listen to the all routers multicast address; this has network as the source), the router sends an ES-IS the desirable property that hosts need not incur redirect packet back to the host, containing the appro- the overhead of processing the more numerous priate next hop and a holding time. The host then ES hello packets. The use of multicast, rather inserts the information contained in the redirect than broadcast, also means that other machines packet into its route cache (Fig. 5). on the subnetwork that are not participating in Once a route is cached, the cache entry can ES-IS will not have to receive (and ignore) these be refreshed by noting the arrival of reverse traf- packets. ficwith network and subnetwork addresses that match The mapping between subnetwork addresses the cache entry, thus reducing the number of and network addresses is noted from the subnet- redirect packets generated. work-specific envelope in which the hello packet If a host wishes to communicate with anoth- is carried, rather than being carried within the er host when no routers are present (known data portion of the packet itself. Each hello pack- because of the lack of router adjacencies), it sim- et contains a holding time, which tells the pack- ply multicasts the CLNP packet to the “all hosts” et’s receiver the length of time for which the subnetwork address. The target host will then information is valid. send a unicast ES hello back to the originating The result of this exchange is that each host host, allowing subsequent communication to be uni- knows the identity (and subnetwork address) of cast rather than multicast. all routers on the subnetwork, and all routers Two additional optimizations are possible when conversely know the identity of all hosts. This a router generates a redirect packet. First, the router information is aged, and will be deleted if not may choose to specify an equivalence class of des- refreshed periodically by subsequent hello pack- tinations for which the redirect applies by return- ets. The longevity of this information, and thus ing a mask in the redirect packet. Often this is possible the frequency of its advertisement, is config- for destinations located outside the local subnet- urable. Furthermore, routers can set the value of work. Second, if an equivalence class of addresses the holding time that the hosts put in their hellos, containing the target destination is known to allowing the entire subnetwork to be tuned from the have subnetwork addresses embedded within the routers. This provides a means of controlling the corresponding network addresses, the router may balance between overhead and rapid conver- relay this fact to the host. This is typically useful gence. only when the destinations share a common sub-

IEEE Network May 1993 41 a prefix. This approach requires minimal manual configuration; in fact, a brand new system could be uncrated, plugged into the network, and be able to communicate without any manual config- uration. Some may not view this ability as a virtue; another approach would be to keep very tight reins on the assignment of network addresses, only assigning them to those systems whose sub- network addresses have been preconfigured in a server. Intradomain Routing Routing within a routing domain is handled by the intermediate system-intermediate system (IS- IS) protocol [IS0 105891. IS-IS is a member of the link state protocols class. IS-IS views a routing domain as a connected set Figure 6.An IS-IS area. of areas, each of which is a connected set of routers and hosts (see Fig. 6). NSAP addresses are minimally constrained --AFereddraa I by IS-IS to having a fixed-length system ID adja- . cent to the NSEL. IS-IS expects NSAP addresses I I AFI I ID1 I Highorder DSP I System ID I SEL I I I 1 I I I I to have the format depicted in Fig. 7. The System ID must be unique within the Figure 7. IS-IS NSAP address structure. area. The IS-IS protocol allows system IDs of lengths one to eight octets (inclusive), but existing imple- mentations currently fix the size at six octets. This network with the source. allows the use of an IEEE 802 MAC address as a sys- Dynamic Addresshsignment- Network address- tem ID, if desired. es cannot be preconfigured in the way that sub- Each area may have multiple area addresses, network addresses typically are (using information allowing for phased address changes for an entire stored in ROM) because they are topologically domain, as well as for the splitting and combining significant - the location of a particular host in of areas. Area addresses need not share any com- the global network cannot be predetermined at mon prefix. the factory. IS-IS has a three-tiered view of routing: The ability for hosts to learn their own net- Intra-area (Level 1). work addresses without direct human interven- Inter-area (Level 2). tion has a number of useful properties. The most Exterior. obvious is that it reduces the complexity of managing Within an area, addressing and routing is a large number of hosts - the less information flat.This requires floodingroutes for each host with- that needs to be set up on a host-by-host basis, in the area, but allows a host to be moved any- the greater the probability that it will be done where within the area without having to change properly (and with less administrative overhead its address. To reduce routing overhead only the sys- as well). In addition, it is useful to be able to tem ID portion of the address is distributed.No rout- change the network addresses of all hosts in a ing information about individual hosts ever leaves network, something that is highly onerous with exist- an area. Conversely, no routing information ing networks. about other areas, or about destinations outside ES-IS provides a mechanism for hosts to the routing domain, ever enters the area. A router determine their network addresses dynamically. internal to an area (Level 1) knows only whether If a host wishes to find out its NSAP address, it the destination is inside the area (the address match- multicastsarequest addresspacket to the “all routes” es one of the area addresses) or outside the area; subnetwork address. One or more routers (or if it is outsidethe area, the packet is forwardedtoward perhaps an address assignment entity that resides the nearest inter-area router. on the subnetwork) may then respond directlyto the Level 2 (inter-area) routers operate over a host (via a unicast) with an assign address packet, flat space of area addresses within the domain which contains a network address to use as well (Fig. 8). Information about all area addresses as a holding time during which the address is within the routing domain is flooded to all Level valid. The host then choosesamong the possible mul- 2 routers, aswell as any exterior (interdomain) rout- tiple responses through local means. ing information imported into the domain. If a An entity sending an address assignment destination is within the routing domain, a Level may not assume that the host has chosen that 2 router will forward packets to the nearest entry particular address; that binding occurs later when point into the destination area, whereupon the pack- the host sends an ES hello. The assignor may not et will be forwarded according to Level 1 routing. re-use the address until the holding time expires, Routes to destinations outside the routing whether or not it ever hears an ES hello. domain are represented as addressprefixes with four- Themethodwithwhich the assignor determines bit granularity. Packets destined outside the domain the network address is deliberately left open in are forwarded along the route with the longest the standard. One obvious method is to build the prefixthat matches the destination. If there are mul- address out of the host’s subnetwork address tiple paths to the destination, the best path can (e.g., an IEEE 802 MAC address), combined with be selected either by virtue of the nearest exit

42 IEEE Network May 1993 point from the domain, or by an external metric (which is likely to reflect a ranking of the quality of interdomain paths). Within a routing domain, the Level 2 and each of the Level 1 topologies are expected to be connected. If a Level 1 area becomes partitioned, however, the partition may be healed at Level 2 so long as each component of the partitioned area still has Level 2 connectivity. Partitions at Level 2 cannot be healed completely with either Level 1 routing or interdomain routing. Area boundaries are modeled as occurring on links (rather than within a router). This implies that a single router cannot be used to connect two areas, a supposition that is borne out in existing implementations. However, it is feasible to implement a single router that can route between two areas, should such a capability prove necessary. Due to the flexible nature of area addressing, it has not yet appeared worthwhile to do so. Interdomain Routing The final component in the routing mechanism is the interdomain routing protocol (IDRP) (Fig. 9) [ll].ThisisthenewestpieceofworkintheOS1 rout- ing architecture, and is the only one that is not a full international standard (although it is expect- ed to become one during 1993). IDRP is based on the IP border gateway protocol [13], and has been generalized to be a protocol-independent interdomain routing proto- col. It is likely that protocols other than CLNP will be routed using IDRP in the future. Workalready has begun on specifying the use of IDRP for the inter- domain routing of IP, and interest has been expressed in using IDRP for other routable pro- tocols such as Novell’s IPX and Appletalk. No changes to the IDRP protocol itself are necessary for use with other protocols. Figure 9. Interdomain routing with confederations. IDRP calculates routes according to policy constraints, rather than by the shortest path. ume of routing data exchanged. When routes are This allows the interdomain topology physical- aggregated, their RD paths are merged, ensuring ly to be an arbitrary mesh, while still providing protection against loops. a means for ensuring that calculated routes Simply allowing aggregation of reachable meet transit policy constraints. Policy informa- destinations is not sufficient to allow scaling, tion is not carried in IDRP. Instead, each rout- since the size of the RD path will continue to ing domain is responsible for implementingits routing grow. Indeed, a default route (a zero-length pre- policies by first selecting among potential routes fix) will carry an RD path containing the set to a destination, and then by limitingthe further dis- union of all routing domains in the internetwork. tribution of the chosen route. This problem is solved by the routing domain Each route carried within IDRP contains confederation (RDC). An RDC is a connected two components - a list of reachable destina- set of routing domains that are grouped together tions, and a set of path attributes. The most as a single topological entity. An RDC is essen- important path attribute is the RD path, a repre- tially a SuperDomain, in the sense that, when sentation of the path of routing domains through viewed from the outside, an RDC is indistin- which a route passes. This provides automatic guishable from a single routing domain. This loop suppression, since a routing domain cannot eliminates all the detail of the inner workings of select an offered route that already traverses the RDC from the RD path, as the collection of itself. Additionally, the RD path supplies data on member RDs is replaced with the identifier of which policy determination can be made. When the RDC. RDCs may be disjoint, nested (form- the routing domain further distributes the select- ing confederations of confederations), or may ed route, it adds itself to the RD path. overlap. Scalability to extremely large internetworks Member routing domains of an RDC need is provided through two mechanisms. The first is not have coordinated routing policies beyond the representation of destinations as address what is normally necessary to provide connectivi- prefixes with bitwise granularity. This mechanism ty (i.e., the intersection of the policies should not allows many individual routes to be aggregated be null if there is to be any transit traffic). This into a single prefix, effectively providing numer- allows RDCs to be formed without a significant ous levels of routing and vastly reducing the vol- level of administrative and configuration over- ..... head. The RDC mechanism automatically impos- GOSIP next specifies a two-octet routing es the restriction that routes from one RDC domain number within carrier. This could be Using CLNP member to another cannot exit the RDC (neces- treated as a flat space of 65,000 domains, or may sary to maintain the loop-free property of IDRP). be subdivided into multiple levels. Either way, The multiprotocol capabilities of IDRP are this provides another order of lo4 allowing about in place of provided by carrying destination address infonna- lo9 destinations within a domain. tion and associated next hop network addresses The next two octets currently are declared to IP requires as opaque data, qualified by protocol ID. Infor- be reserved. Additional levels of hierarchy could mation for multiple protocols can be carried be inserted at this point, should it become necessary, that all the within a single instance of IDRP, as long as the providing routing over 104 superdomains,but for the routing domain boundaries of the various proto- moment this will not be considered. cols are congruent. If this restriction cannot be The next three octets (the administrative services of satisfied,separate instancesofIDRPcan be usedfor authorityidentifier)identify the camer. Ifwe assume each protocol. lo4carriers, we reach 1013 hosts within the GOSIP IP visible address space, which should be sufficient for the foreseeable future. from the Scaling Properties of NSAP The GOSIP space is identified by the high Addressed Networks order octets as being administered by the United States government.Other parts of the NSAP address transport ractable scaling is only possible if routing space are administered by other nations, allowing T complexity increases much more slowly than another level of information reduction if necessary. layer be linearly concerning the number of destinations. This type of growth can be achieved if routing information can be separated hierarchically, Mapping P Functionality to CLNP mapped to with bounded complexity at each level of the hierarchy. sing CLNP in place of IP requires that all the ser- CLNP, a In the OS1 routing architecture, the theoretical U vices of IP visible from the transport layer be number of levels is bounded only by the number mapped to CLNP. Since CLNP was originally derived of addressing bits that map to real topological from IP, this is a fairly straightforward task. Most func- fairly elements. In practical terms, however, the num- tionsofIPmapdirectlytomatchingfunctionsinCLNP ber of levels of routing is determined by the way [18]. A few aspects deserve further discussion. st r aigh tfor- that addresses are assigned, and by the actual topology of the Internet. Protocol Identification ward task. There is debate within the Internet commu- IP carries a one-octet protocol identifier,which spec- nity as to the best approach for address alloca- ifies the protocol being carried as payload in the data tion, with some favoring a very geographical portion of the packet. CLNP does not have a sep- bias to address assignment (similar to the tele- arate protocol ID field, but instead treats this phone numbering plan in North America), and functionalityas part of addressing,using a one-octet some promoting embedding carrier identification NSAP selector. For use with TUBA, the NSEL into addresses. By definition, the latter approach field in the destination NSAP address is set to the has the advantage that addressing and topology value normally carried in the IP protocol ID field are tightly coupled, providing very high efficiency (e.g., 6 = TCP, 17 = UDP). If OS1 transport and complexity reduction. The former approach layer protocols are to be usedwith the same network decouples individual destinations from their car- address as TUBA, NSEL values must be used riers, potentially allowing easy migration between that do not conflict with existing IP transport carriers, but places significant requirements on layerprotocols.Aprotocol IDvalue for the OSIcon- the relationships between carriers and their topo- nection-orientedtransport protocol already has been logical interconnection. assigned; another value can easily be assigned for The two approaches have similar scaling the OS1 connectionlesstransport protocol. Note that properties. OS1 routing can support either since NSELvalues are viewed in OS1 as being of local approach, or even both simultaneously.OS1 routing significance, changing existing NSEL usage to and addressing do not impose a particular address conform to these restrictions is consistent with format, other than the position of the system ID field, the intended OS1 usage. since all routing above the intra-area level is done based on address prefixes. Error Notification For purposes of illustration, we will assume the Error conditionsin IP, such as unreachable destina- use of GOSIP-format addresses in a carrier-based tions, expiration of packet lifetime, etc., are reported addressingscheme. It is the case in the current oper- using the Internet control message protocol(1CMP). ational Internet that routers in the central part CLNP has a separate packet type for error report- of the infrastructure handle about 10,000individual ing. Reference 18 contains the mapping between routes. This can beviewed as a feasible lower bound ICMP message types and CLNP error report types. for route table coinplexity at any given level in the routing hierarchy. TCP and UDP Pseudoheaders At the low-order end of the address, six The TCP and UDP protocols compute check- octets of system ID are used for intra-area rout- sums using not only information contained in the ing. GOSIP then allocates two octets to define transport layer segment, but also the source and the area within a routing domain. Routers at this destination IP addresses, the IP protocol ID, and level are likely to be less capable than infrastruc- total length of the transport layer segment. These ture routers, but should be able to easily handle transport protocols do not have separate connection lo5 destinations per routing domain. identifiers and use network layer addresses in

44 IEEE Network May 1993

-_____-__I___ - only hosts use IP to communicate with all other hosts...... TUBA-capable hosts use IP to talk to IP-only Applications hosts, but they use CLNP when talking to other The (Telnet, FTP, etc.) TUBA-capable hosts. Over time IP-only hosts will upgrade to TUBA-capable software and new systems will come equipped with TUBA-capable transition to software. Hosts using IP strictly for local commu- nication will not need to be upgraded. TUBA has The transition toTUBAhasastrongdependency on continued operation of the IP infrastructure, a strong since TUBA is a dual network layer strategy. The regional, national, and intercontinental IP networks form this IP infrastructure, making it a simple dependency matter for a site to attach andgainworldwide IPcon- nectivity. Initially, the TUBA transition augments on continued the capabilities of the current Internet infrastruc- ture to route and forward CLNP simultaneouslywith IP. Many infrastructure networks already carry CLNP operation (e.g., NSFNET, Alternet, ESnet, NSI, etc.). Most commercial routers already have CLNP routing and of the IP forwarding “out of the box,” so most infrastruc- ture networks are capable of managing CLNP infrastruc- traffic.’ Several countries have CLNP-based ini- Figure 10. Dual stacked host. tiatives and trials, and CLNP routing and address- ing plans exist to provide guidance for Internet ture, since part to demultiplex incoming packets. The check- providers [4]. sum over the pseudoheader protects this infor- The TUBA transition requires each host to have TUBA is mation as part of transport layer semantics. both IP and CLNP addresses. Systems currently TUBA preserves these semantics by includ- attached to the IP Internet will obtain NSAPsas they ing the source and destination NSAP addresses, add TUBA software and attach to the CLNP a dual including their lengths and selector values (in Internet. Over time, most hostswill beTUBA-capa- which the transport protocol is identified), in the ble and use CLNP for network layer services. If network pseudoheader checksum. the TUBA transition is vigorously pursued, the use of IP on the Internet could become vestigial layer Network Management before the exhaustion of IP addresses. Network management in the TUBA environment is done using the simple network management pro- IP Address Space Exhaustion strategy. tocol (SNMP)[2]. SNMP management informa- If TUBA transition is not vigorously pursued, tion bases exist for CLNP and its associated there may be asignificant amount of IP traffic on the routing protocols [24], and SNMP Version 2 con- Internet at the time IP addresses become scarce. tains explicit ASN.l definitions for OS1 address- Once the IP address space runs out, hosts that es. SNMPcan operate over either IPor CLNP in this are only capable of using IP will not be able to environment. In addition, standard network-layer communicate with all Internet hosts, since the IP diagnostic tools such as ping [25] and traceroute address space will be incapable of uniquely iden- are widely implemented. tifying each host in the Internet. IP address exhaustion would force the existence of islands of IP hosts that cannot communicate with Transition to TUBA each other using the current Internet infrastructure. TUBAtransition is a phased plan consisting of Before IP address space exhaustion, a block of IP addresses will be designated, such that addresses Infrastructure networks (e.g., internet service assigned from this block will not be globally providers) tum on CLNP capabilityin their routers. unique, and these network addresseswill not be rout- Root domain name servers deploy TUBA name ed across the Internet infrastructure. By adminis- services. trative control, these addresses can be guaranteed to TUBA host software becomes available. beuniquewithineachlocal IProutingdomain, so that Local routing domains at sites tum on CLNP rout- hosts with these addresses can use IP to communi- ing and register TUBAzones in their local domain cate with IP-only hosts within their own domain. New name servers. hosts will use CLNP to communicate globally, yet Hosts running TUBA software register in their continue to use IP for communicating with IP-only local domain name servers. hosts within their own IP routing domain. Old hosts may still use IP; however, they will reach an Transition Overview increasingly small subset of the Internet, since TUBA defines a method for hosts to run Internet most systems will be using CLNP. It is important transport protocols over a CLNP infrastructure. The to remember that as the Internet grows, most sys- transition plan for TUBA specifies that Internet tems will be new and TUBA-capablewhen purchased. hosts go through two stages: the initial phase The current demand for where a host only uses IP, and a second phase Host Name Resolution CLNP services is not where a host is TUBA capable and TCP and Routing and forwarding of data traffic is not the only suficient at present for UDP operate over both IP and CLNP (see Fig. critical piece of Internet infrastructure. The domain some networks to turn on 10). TUBA-capable hosts are dual-stacked. IP- name system [15] provides the operational name and manage CLNP. Availability scope (e.g., their local ethernet or routing domain). Document These hosts are not considered by the TUBA plan, The TUBA mailing list is archived and available by anonymous ftp from since TUBA expressly addresses the problem of merit.edu in the pub/tuba-archive directory. Subscription to the tuba list globally interconnected sites. As discussed earli- is available upon receipt of Internet mail to [email protected]. er, hosts with globally unique IP addresses still The full set of OS1 connectionlessnetworklayer protocol specifications will be able to communicate with one another. is available in electronic form via anonymous FTP. They can be found at There may be cases where IP-only hosts with- merit.edu, in the pub/iso directory: out globally unique IP addresses require global Inter- clnp.ps net connectivity, but will be unable to use CLNP. esis.ps It is possible to translate between IP datagrams and isis.ps CLNP datagrams, provided there is a simple idrp.ps mapping between the IP address and CLNP Request for comments (RFC) documents are available by anony- NSAP. A network layer translating gateway mous ftp from nic.ddn.mil. Several of the documents referenced are (NLTG) could convert TCP and UDP packets over internet-drafts that will become RFCs. They are availablein the nic.ddn.mil IP to TCP and UDP packets over CLNP. NLTGs anonymous ftp site. are prosthetics for hosts that cannot be converted to TUBA, and are not considered to be in the space upon which Internet services depend. Internet mainstream of TUBA transition planning. domain names will be used with TUBA, so the DNS will need to be augmented to map between domain names and CLNP addresses, as well as IP addresses. Current Status of TUBA Operationally, the root name servers will need to he bulk of implementation work for TUBA be upgraded to respond to DNS requests by T requires changing host software. There are TUBA-capable hosts, to respondwith IP and CLNP trial implementationson five separate hardware plat- addresses, and to delegate TUBA-basedzones. Sys- forms including personal computers, worksta- tems that are responsible for serving DNS zones will tions, and routers. Interoperability testing has subsequently convert to TUBA-capable imple- successfullydemonstrated interoperation of Telnet, mentations of the DNS when hosts within that TFTP, and Finger over TUBA. zone wish to become known to the TUBA Inter- net. Since the nature of TUBA capability is defined on a host-by-host basis, any host announc- Conclusion ing that it is TUBA capable is announcing it can ventually it will be necessary to provide the means use CLNP for all services expected of that host. E for addressing more hosts than is possible with the current version of the IP. OS1 NSAP address- Other Transition Issues es can address very large Internets, and with There are several Internet protocolsand servicesthat TUBA it is possible to use the applications and assume IP as the sole network layer. The most protocols that Internet users currently enjoy, run- common assumption made is that IP addresses are ning over CLNP in place of IP. TUBA is a pragmatic used to identify hosts. The file transferprotocol (FTP) solution to IP's lack of adequate address space, identifies the host IP address and port number to taking advantage of the current investment in be used when opening a data connection. This is Internet applications and protocols, as well as the a common practice in protocols and systems that development,testing, and deploymentof CLNP. We need to pass network bindings as data, such as remote envision a two-step transition to a TUBA Inter- procedure call protocols, authentication proto- net. Initially, IP transit networks add CLNP services, cols, and protocols that involve third partiesor prox- a step that already is in progress by many transit ies. These protocols and systemscan be re-engineered networks.Subsequently, a longer phase where Inter- to eliminate their dependence on a single proto- net services transition from using only IP to deliv- col by passing the name of the system instead of a ery of the same services using both IP and CLNP. network layer address. Another option would be to extend these protocols to pass network layer infor- Acknowledgments mation (e.g., addresses and port numbers) and an The authors would like to thank Dave Piscitello identifier for the network layer protocol. (Bellcore), Yakov Rekhter (T.J. Watson Research It is necessary to engineer applicationsto simul- Center, IBM Corp.), Sue Hares (MeritmSFNET), taneously offer services over both IP and CLNP Mark Knopper (Merit/NSFNET), Richard stacks. Hostscan run twoseparate applicationsoffer- Colella (NIST), and the ai:onymous reviewers for ing the same service, one over IP and the other comments that significantly improved this paper. over CLNP. Alternatively, a host could provide Peter Ford acknowledges support from the Unit- an application programming interface (API) ed States Department of Energy's Office of Ener- allowing a single version of the application to gy Research (Contract No. KC0702), Los Alamos access both CLNP and IP network services through National Laboratory (Contract No. W-7405- the same interface. The latter system architecture ENG-36) and the National Science Foundation.

is preferable, since it reduces the number of sepa- ___~ rate instances of essentially identical software. References [11 R. Callon. "TCP and UDP with Bigger Addresses (TUBA).A Sim- CLNP-IncupubleHosts ple Proposal for Internet Addressing and Routing," RFC 1347, Some hosts neverwill use CLNP, either because they June 1992. [21 J. D.Case et al.. "Simple Network Management Protocol (SNMP)." cannot, or because they choose not to convert to RFC 1157. Mq1990. TUBA. Many of these hosts do not need to com- [31 V. G. Cerf and R. E. Kahn, "A Protocol for Packet Network Intercom- munication."IEEETrans. Commun..vol. COM-22, no. 5. May 1974. municatewith the entire Internet, andwill onlyneed [41 R. Colella and R. Callon, "Guidelines for OS1 NSAP Allocation in to communicate with systems within some limited the Intemet."RFC1237. July 1991.

46 IEEENetwork. May1993 [51 V. Fuller et al.. "Supernetting: An Address Assignment and [I~~ 81 D. Piscitello."Useof ISOCLNPinTUBAEnvironments,"IntemetDraft Aggregation Strategy." RFC 1338. June 1992. draft-ietf-tubo-clnpOZM,Jan. 1993. [61 "Information Processing Systems - Data Communications - [191 J. B. Postel, "User Datagram Protocol." RFC 768, Aug. 1980. Network Service Definition Addendum 2: Network Layer Address- I201 J. B. Postel. "Internet Protocol," FlFC 791, Sept. 1981. ing," IS0 8348/Addendum 2, 1988. I211 J. B. Postel, 'Transmission Control Protocol," RFC 793. Sept. 1981. [71 "Protocol for Providing the Connectionless-mode Network Ser- [221 Y. Rekhter, ed. and T. Li. "A Border Gateway Protocol 4 (BGP-I)," vice." IS0 8473. 1988. Intemet Draft. Dec. 1992. I81 "OS1 Routing Framework," IS0 TR 9575, 1989. [231 Y. Rekhter and T. Li, "An Architecture for IP Address Allocation 191 "End System to Intermediate System Routing Exchange Protocol with ClDR," Internet Draft, Feb. 1993. for Use in Conjunction with the Protocol for Providing the Connec- I241 G. Satz, "CLNS MIB for Use with Connectionless Network Proto- tionless-mcde Network Service (IS0 8473)." IS0 9542. 1988. col (IS0 8473) and End System to Intermediate System (IS0 I101 "Intermediate Systemto Intermediate Systemlntradomain Routing 9542)."RFC 1238. June 1991. Information Exchange Protocol for Use in Conjunction with the 1251 C. Witthrodt, ed., "An Echo Function for IS0 8473." Internet Draft Protocol for Providing the Connectionless-mode Network Service draft-ietf-noopecho-OO.txt,Feb. 1993. (IS0 8473);' ISO/IEC 10589, 1992. [I 11 "Protocol for Exchange of Inter-domain Routing Information Among Intermediate Systems to Support Forwarding of IS0 8473 PDUs," ISO/IEC DIS 10747, 1992. Biographies [121 L. Kleinrock and K. Farouk, "Hierarchical Routing for Large Net- wor~,"CompuierNe~orksI (North-Holland publishing Company, PETER S. FORDreceived a B.G.S. from the University of Michigan. He 1977). is a member of the technical staffat Los Alamos National Laborato- I131 K. Lougheed. ed. and Y. Rekhter, "A Border Gateway Protocol 3 ry, Los Alamos. New Mexico, where he works on computer network- (BGP-3)."RFC 1267. Oct. 1991. ing and high performance computing. He is currently working with 1141 B. Manning, "DNS NSAP FlRs,"RFC 1348. July 1992. the National Science Foundation on the evolution of the NSFNET. 1151 P. V. Mockapetris, "Domain Names - Implementation and Spec- ification,"RFC 1035, Nov. 1987. DAVE KAT2 has been a software engineer at cisco Systems in Menlo (161 NIST. "U.S. Government Open Systems Interconnection Profile Park, California since 1992. Previously he worked on the NSFNET (GOSIP) Version 2.0," Oct. 1990. projectatMerit.1nc.inAnnArbor.Michigan.Hehasbeenactiveinstan- [171 D. Oran, "OS1 IS-IS Intra-domain Routing Protocol," RFC 1141, dards activities since 1986. involved with both TCP/IP (IETF) and Feb. 1990. OS1 (ANSIX3S3.3). concentrating on routing issues.

IEEE Network May 1993 47