Internet Draft Internet Architecture Board July 1992 Expires: January 1993 IP Version 7 **DRAFT 8** Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.auto to learn the current status of any Internet Draft. Abstract Internet growth has created serious problems of address space consumption and routing information explosion. A solution to these problems requires a new version of the Internet Protocol, which we call IP version 7 ("IPv7"). This memo presents architectural guidelines that any IPv7 should meet. It then discusses how an IPv7 based upon the OSI CLNP protocol would meet these requirements, and presents the reasons for the IAB's preference for this solution. Finally, it makes a three-part recommendation: (1) proceed at full speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3) continue to pursue research in advanced routing and other future extensions of the Internet architecture. TABLE OF CONTENTS 1. INTRODUCTION .................................................. 2 2. ARCHITECTURAL PRINCIPLES ...................................... 4 3. POSSIBLE APPROACHES TO IPv7 ................................... 9 4. RESEARCH AREAS ................................................ 13 5. THE WAY FORWARD ............................................... 14 REFERENCES ....................................................... 15 IAB [Page 1] Internet Draft IP v7 July 1992 1. INTRODUCTION 1.1 The Need for IPv7 The rapid growth of the Internet has exposed the consequences of a design choice made 15 years ago, the choice of a fixed-length 32- bit address field for IP [IEN-005]. At that time, 32 bits appeared to be a very wide field, allowing many thousands of networks and millions of hosts, several orders of magnitude beyond the likely size of the Internet. However, the Internet has now grown to this order of magnitude, leading to two different scaling problems: * Routing Information Explosion The cost and complexity of Internet routing grow very rapidly with the number of networks. This growth is creating increasingly serious operational problems. * Address Space Consumption Current IP addresses are 32 bits. While this seems to be a very large number (4*10**9), its division into host and network parts and into class A, B, and C networks significantly reduces the available space. Projections are difficult and highly arguable, but at the current rate of growth, the existing space may be used up in the foreseeable future. We believe that the current Internet Protocol, version 4 ("IPv4"), cannot practically be extended to solve these problems, and that a new version of IP is needed. We follow current nomenclature by calling the next generation Internet Protocol "IP version 7" or "IPv7". 1.2 History The IAB took its first step towards considering the IP scaling problems during a workshop on "The Future of the Internet Architecture" in July 1991. [RFC-1287]. The results of this group's deliberations were reported to the November 1991 IETF meeting. Partly as an IAB initiative and partly as a result of internal IETF working group discussions, a task group known as "ROAD" was formed in November 1991. This group worked very intensively for the following three months, with the mandate of developing one or more plausible architectural starting points for attacking the scaling problems. Although the ROAD group did not reach a definitive recommendation, it turned out to be enormously helpful in structuring the problem, and laid the groundwork for IAB [Page 2] Internet Draft IP v7 July 1992 this memo [ROAD]. More recently, there has been an intense debate on various mailing lists and a profusion of new suggestions. Each of these reflects careful thought by informed people. All of this prior work has been factored into the contents of this document. In particular, a recent paper by Callon [TUBA] is very complementary to our discussion in Section 3. This document presents a summary of the IAB's analysis of the ROAD issues and its resulting specific recommendations. A more complete description of the way in which these conclusions were reached would be valuable, and will be included in a later version. 1.3 Overall Plan In ROAD discussions, it was useful to divide the solution of the IP scaling problems into short-term, medium-term, and long-term phases [ROAD]. The real situation is much more complicated, with considerable overlap as well as uncertainty about time frames, yet this is a useful model for planning. We support the ROAD group model that IPv7 belongs to the mid-term time frame, in the sense that: (1) more immediate steps must be taken to avoid exhaustion of the address space before IPv7 can be deployed; and (2) there are substantial research questions which must be pursued, but which cannot be expected to be resolved until after IPv7 is deployed. For the short-term effort, we support the ROAD group suggestion of CIDR (Classless Inter-domain Routing) [CIDR], a form of "super- netting". CIDR will provide short-term relief from exhaustion of the address space by breaking the rigidly fixed boundaries that define class A, B, and C IP addresses, using a more flexible bit- level mask (or equivalently a variable-length address prefix) to distinguish the network number. To attack the routing information explosion, CIDR will select addresses to match topology, allowing the aggregation of routes. As we point out later, this aggregation will carry over to, and indeed is important to the success of, IPv7. We do not dwell on CIDR here; there are already several CIDR- related engineering efforts in progress in the IETF. This memo emphasizes IPv7. Section 2 introduces a set of requirements that must be satisfied by any IPv7 architecture, while Section 3 discusses two alternative approaches for realizing IPv7. One IAB [Page 3] Internet Draft IP v7 July 1992 approach is based upon encapsulation and the other is based upon OSI CLNP. Section 4 briefly surveys some of the important research problems and efforts that are vital to a long-term solution to the problems posed by a billion-node Internet. Section 5 summarizes proposed directions and actions for the community. 2. ARCHITECTURAL PRINCIPLES To guide our work and to help sort out the competing proposals, an overall set of design principles is needed. It is customary to refer to such a set of principles as the "architecture". We believe that a viable IPv7 should obey the following basic principles. * Architectural simplicity, * Globally unique addresses, * Larger address space, * Distributed address registration, * Route aggregation, * Topology independence, * Extensibility, * Compatibility, and * Interoperability. All of these are discussed in later sections. This list is in no sense ordered; we believe all of these requirements to be important. An actual engineering solution will naturally involve detailed trade-offs among these objectives, but there are no simple precedence relations among them. Before discussing these principles, we make a basic philosophical point: whatever the choice for IPv7, its "change control" must rest with the IAB/IETF. Despite our desire to eventually converge with other standards groups, the ability for protocol and architectural evolution within the IRTF and IETF is absolutely essential to the continued success of the Internet. IAB [Page 4] Internet Draft IP v7 July 1992 2.1. Architectural Simplicity We believe that the success of the Internet architecture (as evidenced by the growth problem discussed in this memo) rests on its simplicity, which should be retained to the extent possible. As an example of simplicity, we would prefer an architecture that does not introduce any new logical boundaries into the Internet. Such boundaries could make the job of address registration and route aggregation harder. 2.2. Globally-Unique Addresses We believe that an important characteristic of the Internet architecture is the availability of "globally unique" addresses. The alternative would be to allocate temporary local addresses dynamically through an address translation scheme, relying upon directory or name service to map these addresses. Globally-unique addresses permeate the design of many applications. For example, (1) Globally-unique addresses are passed by applications like FTP to identify third parties. (2) Globally-unique addresses are very useful for a number of security schemes. (3) Globally-unique addresses are important for system management of the global Internet. The lack of a globally-unique address would break a number of applications, impose severe boundary problems in the network, and make security more difficult. In addition, the directory mechanism itself would introduce substantial new security risks. It would also require much more robust and closely-managed servers, speedily updated, than we have in today's DNS. A consequence of globally-unique addresses is that when the IPv4 address space becomes totally exhausted, "old" hosts (those which speak only IPv4) will be unable to communicate with some "new" hosts. We are prepared to accept this, in the belief that continuing evolution is a necessary and desirable property of the Internet, and that we will be able to provide a more-than- reasonable period for conversion to IPv7 by all hosts. In the asymptotic situation, application-level gateways can be used to provide continued connectivity (with reduced functionality) for old hosts. IAB [Page 5] Internet Draft IP v7 July 1992 2.3. Larger Address Space Since we require globally unique addresses and since the current address space is too small, we must escape the limitations imposed by the current 32-bit addresses. The new architecture must allow much wider address fields, to accommodate: (1) registering several millions, or even billions, of networks; (2) allowing some degree of inefficiency in the address registration; (3) permitting the expression of a hierarchy in the address; (4) allowing for new addressing architectures in the future, if the need arises. Here (2) and (3) are needed in order to allow decentralized registration and route aggregation (see Sections 2.4 and 2.5). This move to a new address format is likely to impact much host and router software; every piece of software that handles an Internet address will have to be modified to handle wider addresses. It is important to note the nature of this impact: broad (many modules affected) but shallow (very specific, localized changes). We furthermore argue in favor of a variable-length address format, with a known upper bound. This upper bound will need to be large, potentially increasing the IP header size significantly. However, with a reasonable address assignment scheme, most networks numbers will be much smaller. Indeed, it might be desirable to use the existing 4-byte IP addresses for many hosts during a transition. 2.4. Distributed Address Registration As the Internet becomes more and more international, it is no longer appropriate to centralize all address registration in one country. The new IP architecture must allow a decentralized address registration scheme, for example by means of a multi-layer hierarchical structure [RFC-1174]. Furthermore, decentralized registration will be required even within single countries, as the scale of the Internet increases. Another important requirement is the capability to embed the existing IP addresses into the new address space. This will avoid separate old and new routing tables for IP, and it will prevent network administrators having to form a huge queue in front of the new registration agencies during the transition to IPv7. IAB [Page 6] Internet Draft IP v7 July 1992 2.5. Route Aggregation Current IP addresses have three components: a "network number", an optional "subnet" number, and a "host" number. Networks are logically grouped into autonomous domains, but the space of network numbers is flat, without any internal structure. This flat addressing space leads to routing tables and routing updates that grow nearly linearly with the total number of networks in the Internet. Thus, adding a new network has a cost for all the routers. It may be objected that, in practice, many routing tables grow much more slowly than linearly with the number of networks because of the use of default routes. While this is true, the use of defaults implies careful route engineering. Such engineering is the norm in the Internet today, but growth is making it increasingly difficult. For example, adding a second link to a stub Autonomous Systems will result in its networks being announced on two entry points instead of one, and this will require far distant parts of the Internet to administratively decide which path to use. Soon, such planning will become impossible. Another drawback of defaults is that they restrict the amount of implicit policy routing that can be achieved. Finally, there will always be a core of border routers that must know all destinations, and whose tables must grow linearly with the number of networks in the Internet. To solve this problem, the Internet must aggregate routes, i.e., allow one routing table entry to define the next hop for a group of networks. This requires some structure in the addresses. When all networks belonging to the same "routing domain" share addresses whose most significant bits are the same, we can represent this group of networks by a single entry in the routing tables. Moreover, this aggregation scheme can be used hierarchically, so that, for example, all networks in the Hawaiian archipelago may appear as a single group to the Internet, and all networks of the island of Oahu as a single group in the archipelago [Kleinrock&Kamoun] 2.6. Topology Independence We believe that an important long-term objective is to free the assignment of addresses from dependence upon the routing topology, just as domain names are assigned independently of network connectivity. Managing the allocation of the address space to match the topology will be an administrative nightmare (which unfortunately we cannot avoid in the short- and medium-term). There should be a level of indirection between addressing (naming) IAB [Page 7] Internet Draft IP v7 July 1992 a destination and routing to it. This would allow addresses to have a hierarchical structure determined purely by the administrative decentralization of address assignment. A directory service lookup of some sort would be necessary to map these topology-free names into routes. This lookup would need to be performed by routers in the forwarding path, but it could be partially circumvented with route cacheing. Such a scheme would result in the cost of a new network being felt primarily by those routers that are actually trying to reach it. It is clear that such an indirection scheme with route cacheing is a hard problem, and at present it must be the subject of research. Until that research is completed, we will have to accept some topological constraints on addressing and routing. General "policy routing" is another research topic that is not ready for engineering at this time. Further research on these topics is essential, as discussed in Section 4. 2.7. Extensibility Evolution from IPv4 to IPv7 will be occurring at the same time that research work is on the verge of requiring architectural extensions in other areas. Two important examples are supporting real time applications (e.g., packet voice and video) [Realtime], and providing better security services. IPv7 should provide easy extensibility in order to support such new areas. In particular, it is vital to escape the 60 byte limit on the IPv4 header, in order to have more space available for options. 2.8. Compatibility As mentioned above, larger addresses should by no means imply a change in the overall Internet architecture. In particular, it should certainly not imply a reduction in the network functionality. For example, it is mandatory that IPv7 should continue to support the IP multicast architecture. Also, the current techniques for debugging (e.g., "ping" and "traceroute") should still be possible. There are many "tendrils" from IPv4 that reach up into the transport and application layers [RFC-1122]. Examples are the receipt of ICMP Unreachable, Redirect, and Source Quench messages, and setting TOS and TTL values and/or source routes. Other examples arise in the use of Internet addresses by applications, e.g., IP. We would ideally like to minimize the impact on the layers above IP, although this may not prove entirely feasible. IAB [Page 8] Internet Draft IP v7 July 1992 2.9. Interoperability Transition from IPv4 to IPv7 must occupy a number of years, so it will be necessary for IPv4 hosts to be able to interoperate with IPv7 hosts. A general scheme for handling old/new host interoperability, based upon the DNS, is given in [TUBA]. In order to ease the transition and ensure connectivity within the Internet, the addressing plan should allow the address space to be *embedded* into the IPv7 space. For example, this will avoid the need to maintain parallel routing tables. The following diagram shows the protocol stack that a host may expect to implement. During the transition to IPv7 (which is likely to be lengthy), an Internet host must support both IPv4 and IPv7. It would use IPv4 for communication with an unmodified host [TUBA]. _________________________________ | | | | | TCP/UDP | | | |_________________________________| | | | | | | | IPv4 | IPv7 | | | | |_______________|_________________| 3. POSSIBLE APPROACHES TO IPv7 Two divergent approaches have been suggested for IPv7. (1) Some form of IP encapsulation. A good example of this approach is the IP Address Encapsulation proposal [IPAE]. Encapsulation schemes maximize Internet-layer protocol compatibility by design; however, these schemes also represent a significant change in the IP architecture. (2) Keep the IP architecture essentially unchanged, but change the format of an IP header to expand the addresses. A solution based on the existing CLNP protocol is a recent candidate for the expanded header format [TUBA]. CLNP can be IAB [Page 9] Internet Draft IP v7 July 1992 regarded as a revision of IP to fit into the OSI framework, following the IP architecture without much added functionality. The primary technical difference between IPv4 and CLNP is the latter's much wider address fields, variable length up to 20 bytes. After consideration of the principles of Section 2, the IAB favors the second class of solutions, and in particular, basing IPv7 on CLNP. It is important to understand exactly what we mean by basing IPv7 on CLNP; the rest of this section is therefore devoted to expanding on this topic. The IAB proposal is to adopt the CLNP protocol specification and packet formats for IPv7. The eventual consequence of this decision will be the publication, at some point in the future, of a complete IPv7 specification that is functionally and syntactically compatible with CLNP (defined by the second edition of the ISO 8473 standard, published in 1992). The intent is to run the existing and future Internet transport protocols -- in particular, TCP and UDP -- above IPv7. This would let us benefit from the larger addresses of CLNP while maintaining the present Internet architecture, without inventing a new protocol specification and without losing change control. We must of course avoid gratuitous changes, but the IAB/IETF must be able to make any changes that are necessary for successful deployment, operation, and evolution of IPv7. In the longer term, the use of CLNP will contribute to the inevitable convergence of the OSI and TCP/IP protocol suites in the Internet (IAB/IETF) context. The next section reviews the advantages of this CLNP-based solution. Section 3.2.discusses the issues that must be resolved before a CLNP- based IPv7 can be deployed in the Interne. 3.1. The case for (and against) CLNP An advantage of CLNP is simply that the protocol is already specified, and several implementations exist. Adopting (and adapting; see the next section) the CLNP format will avoid design of a new protocol from scratch, a process that would consume valuable time and delay testing and deployment. Besides the change to variable-length 20 bytes addresses, CLNP has another important technical advantage: it frees us from the 60-byte limitation on an IP header. CLNP has a limit of 254, and there is an escape code (length 255) that could allow an extended header; this will allow more extensive use of IP options for future extensions. We should admit frankly some technical limitations of CLNP, which IAB [Page 10] Internet Draft IP v7 July 1992 it shares with IPv4: * Maximum packet length is limited to 64K bytes. * The message identifier uses a 16-bit field. * The Time-to-live field is one byte. * If full-size (20 byte) addresses are used in options, the 255 byte limit gets used up fast. For example, the largest source route with 20-byte addresses will be 8 hops. In addition, CLNP has awkward boundary alignments for RISC- architecture machines. We do not regard any of these as show- stoppers. 3.2 Additional Issues with CLNP. To adopt the CNLP format for IPv7, a number of issues must be resolved. Callon has provided one analysis of the changes needed and the interoperability issues for using CLNP as the basis for IPv7 [TUBA]. * Address Format and Registration Plan The existing NSAP registration plans [OSI-NSAP], which were designed for OSI usage, will have to be reviewed in light of the Internet needs. One requirement is to embed the existing Internet addresses. * Protocol Identification A substitute for the IPv4 "protocol identification" field will have to be defined. A plausible solution would be to use the "last address byte" (the "NSEL" or "NSAP selector" field, which is defined to be the last byte of the NSAP address by ANSI standard X3.210-1992). * Transport Pseudo-Header The transport protocols TCP and UDP currently include in their checksums a "pseudo-header" constructed out of the address and length fields abstracted from the IP header. A suitable modification to the pseudo-header will have to be designed (or the pseudo-header dropped from TCP and UDP). This problem is well-described in [TUBA]. * Layer Interactions IAB [Page 11] Internet Draft IP v7 July 1992 The impact upon all the other layers will have to be worked out in detail. * Error Reporting Most important is the reporting of errors from the IP layer. It might be that the most effective and economical solution will be to continue to use ICMP with IPv7. Otherwise, it will be necessary to modify the error-handling strategy of existing transport protocols to use the OSI error reporting mechanism. * Address Resolution A related issue is whether to continue to use ARP for address resolution on broadcast networks, or whether to adopt the OSI ES-IS protocol [ES-IS], which essentially combines ICMP and ARP functions. * Domain Name Lookups It will be necessary to modify the DNS to return the new wide addresses. This problem is well described in [TUBA]. * Header Size The possible problems posed by increasing the size of the IP header will have to be evaluated. The impact on slow Internet links may be alleviated by adapting header compression algorithms analogous to Jacobson's [RFC-1144]. * Multicasting The proposed extensions to CLNP for multicasting will have to be incorporated. In general, a very careful review will be required to quickly locate the potential problems and to cure them. In line with the Internet tradition of "learning from experience", this will need early experiments, which will have to be taken into account in the transition timing. Note that the IPv7 implementation may differ from the OSI CLNP implementation by having a different "service" interface to the transport layer. That is, IPv7 implementors may choose to minimize changes on the transport side of the interface [RFC-1122]. Thus, a host that supports both the Internet and the OSI stacks may have the following protocol stacks: IAB [Page 12] Internet Draft IP v7 July 1992 ________________ _________________________________ | || | | || | | TP4 || TCP/UDP | | || | |________________||_________________________________| | || | | | || | | | OSI CLNP || IPv4 | IPv7 | | || | | |________________||_______________|_________________| It is of course a long-term objective to work towards a single unified internet protocol layer for the entire Internet. In the OSI framework, IS-IS and IDRP are the currently-defined IGP and EGP routing protocols, respectively. A careful study may be needed to evaluate whether to adopt ISO routing protocols or to evolve IP routing protocols to support IPV7. The routing protocols currently in use in the Internet represent a huge investment that should be thrown away only for compelling reasons. Furthermore, we must facilitate further research in routing protocols. In order to survive the transition to IPv7, the existing routing protocols will have to be upgraded to handle long variable-length addresses and masks/prefixes. The careful study of routing protocols is an important element in the success of the migration. 4. RESEARCH AREAS A number of long-term approaches have been suggested for major advances in Internet routing. These include IDPR, NIMROD, and PIP. We urge that these ideas be aggressively researched. Section 2.5 exhibited weak points of the current Internet architecture and routing technology. Extending the number of connected networks or the number of Internet links causes additional cost for all (or at least many) Internet routers. Ideally, the cost would be borne only by those who intend to engage in exchanges with the new networks or over the new links. Furthermore, the assignment of addresses is tied to the topology, to allow route aggregation. Removing these constraints requires the development of an indirection and route cacheing mechanism. This is very important for the future, but it is definitely a research project. One definition of research is "a project which is allowed to fail", and indeed it is a matter of conjecture that a route lookup mechanism can be designed with IAB [Page 13] Internet Draft IP v7 July 1992 sufficient speed and robustness to satisfy the requirements. Research in this area should be a critical task for the long-term evolution of Internet routing. General policy-based routing is another issue that we regard as a research topic, for the long term. 5. THE WAY FORWARD In order to guarantee the survival of the Internet, work should start now on the various items detailed in this document. Delaying by a few more months in order to gather more information would be very unlikely to help us make a decision, and would encourage people to spend their time crafting arguments for why CLNP is or is not a better solution than some alternative, rather than working on the detailed specification of how CLNP can be used as the basis for IPv7 and resolving the technical questions (particularly in the area of address administration and the effect on existing application software) that must be answered in order to specify a deployment plan for IPv7. We therefore recommend: 1. An immediate IETF effort to engineer CIDR, including the extensions to the inter-AD routing protocols to allow masks/prefixes, and the associated address administration paradigm. The latter is critical to the success of CIDR. The routing information explosion is upon us now. Already, some pockets of the Internet are showing restricted connectivity due to routing table overflow. With the rapid pace of Internet growth, the problem has to be addressed immediately, even before introducing IPv7 and its large addresses. We urge that route aggregation be incorporated as soon as possible, using the CIDR scheme. 2. An immediate IETF effort to prepare a detailed technical and organizational plan for using CLNP as the basis for IPv7. The IAB favors CLNP, which retains the general Internet architecture and its principles unchanged while changing the IP packet format to accommodate wider addresses. 3. That the long-term research discussed in Section 4 be continued and encouraged. It is important to observe that CIDR uses 32 bit addresses with the L first bits used for routing. Here L is determined distinctly for each routing table entry. Projecting this onto IPv7, we see that IPv7 will IAB [Page 14] Internet Draft IP v7 July 1992 use X bit addresses with the L first bits used for routing, where X is to be determined. Thus, we see that CIDR is a natural step along the route to IPv7, and a step that needs to be started as soon as possible. REFERENCES [CIDR] Fuller, V., Li, T., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC in preparation, April 10, 1992. [CLNP] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, 1988. [ES-IS] "End-System to Intermediate System Routing Exchange Protocol for use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service", ISO 9542, 1987. [IEN-005] Cerf, V., "TCP Version 2 Specification", Internet Experiment Note IEN-005, March 1977. [IPAE] Hinden, R. and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses", RFC in preparation. [Kleinrock&Kamoun] Kleinrock, L. and K. Kamoun, "Hierarchical Routing for Large Networks: Performance Evaluation and Optimization", Computer Networks, 1, 155-174, 1977. [OSI-NSAP] Collella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP Allocation in the Internet", RFC-1237, July 1991. [RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", RFC-1122, October 1989. [RFC-1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC-1144, February 1990. IAB [Page 15] Internet Draft IP v7 July 1992 [RFC-1174] Cerf, V., "IAB Recommended Policy on Distributing Internet Identifier Assignment", RFC-1174, August 1990. [Realtime] Braden, R., "Integrated Service in the Internet Architecture", High-Performance Network Research Report, ISI, October 1991. [ROAD] "The Internet Routing and Addressing Task Force: Summary Report", Brim, S. and P. Ford, Working Draft, 23 June 1992. [TUBA] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple Proposal for Internet Addressing and Routing", RFC-1347, June 1992. Security Considerations Support for privacy and security is fundamental to the architectural choice of globally unique addresses, as noted in Section 2.2. Author's Address Internet Architecture Board c/o Robert Braden, IAB Executive Director USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Phone: 310-822-1511 Fax: 310-823-6714 Email: Braden@ISI.EDU IAB [Page 16]