diff options
Diffstat (limited to 'doc/rfc/rfc1077.txt')
| -rw-r--r-- | doc/rfc/rfc1077.txt | 2579 |
1 files changed, 2579 insertions, 0 deletions
diff --git a/doc/rfc/rfc1077.txt b/doc/rfc/rfc1077.txt new file mode 100644 index 0000000..75a5a64 --- /dev/null +++ b/doc/rfc/rfc1077.txt @@ -0,0 +1,2579 @@ + + + + + + +Network Working Group Gigabit Working Group +Request for Comments: 1077 B. Leiner, Editor + November 1988 + + + Critical Issues in High Bandwidth Networking + + +Status of this Memo + + This memo presents the results of a working group on High Bandwidth + Networking. This RFC is for your information and you are encouraged + to comment on the issues presented. Distribution of this memo is + unlimited. + +ABSTRACT + + At the request of Maj. Mark Pullen and Maj. Brian Boesch of DARPA, an + ad-hoc working group was assembled to develop a set of + recommendations on the research required to achieve a ubiquitous + high-bandwidth network as discussed in the FCCSET recommendations for + Phase III. + + This report outlines a set of research topics aimed at providing the + technology base for an interconnected set of networks that can + provide highbandwidth capabilities. The suggested research focus + draws upon ongoing research and augments it with basic and applied + components. The major activities are the development and + demonstration of a gigabit backbone network, the development and + demonstration of an interconnected set of networks with gigabit + throughput and appropriate management techniques, and the development + and demonstration of the required overall architecture that allows + users to gain access to such high bandwidth. + + + + + + + + + + + + + + + + + + +Gigabit Working Group [Page 1] + +RFC 1077 November 1988 + + + 1. Introduction and Summary + + + + 1.1. Background + + + The computer communications world is evolving toward both high- + bandwidth capability and high-bandwidth requirements. The recent + workshop conducted under the auspices of the FCCSET Committee on High + Performance Computing [1] identified a number of areas where + extremely high-bandwidth networking is required to support the + scientific research community. These areas range from remote + graphical visualization of supercomputer results through the movement + of high rate sensor data from space to the ground-based scientific + investigator. Similar requirements exist for other applications, + such as military command and control (C2) where there is a need to + quickly access and act on data obtained from real-time sensors. The + workshop identified requirements for switched high-bandwidth service + in excess of 300 Mbit/s to a single user, and the need to support + service in the range of a Mbit/s on a low-duty-cycle basis to + millions of researchers. When added to the needs of the military and + commercial users, the aggregate requirement for communications + service adds up to many billions of bits per second. The results of + this workshop were incorporated into a report by the FCCSET [2]. + + Fortunately, technology is also moving rapidly. Even today, the + installed base of fiber optics communications allows us to consider + aggregate bandwidths in the range of Gbit/s and beyond to limited + geographical regions. Estimates arrived at in the workshop lead one + to believe that there will be available raw bandwidth approaching + terabits per second. + + The critical question to be addressed is how this raw bandwidth can + be used to satisfy the requirements identified in the workshop: 1) + provide bandwidth on the order of several Gbit/s to individual users, + and 2) provide modest bandwidth on the order of several Mbit/s to a + large number of users in a cost-effective manner through the + aggregation of their traffic. + + Through its research funding, the Defense Advanced Research Projects + Agency (DARPA) has played a central role in the development of + packet-oriented communications, which has been of tremendous benefit + to the U.S. military in terms of survivability and interoperability. + DARPA-funded research has resulted in the ARPANET, the first packet- + switched network; the SATNET, MATNET and Wideband Network, which + demonstrated the efficient utilization of shared-access satellite + channels for communications between geographically diverse sites; + + + +Gigabit Working Group [Page 2] + +RFC 1077 November 1988 + + + packet radio networks for mobile tactical environments; the Internet + and TCP/IP protocols for interconnection and interoperability between + heterogeneous networks and computer systems; the development of + electronic mail; and many advances in the areas of network security, + privacy, authentication and access control for distributed computing + environments. Recognizing DARPA's past accomplishments and its + desire to continue to take a leading role in addressing these issues, + this document provides a recommendation for research topics in + gigabit networking. It is meant to be an organized compendium of the + critical research issues to be addressed in developing the technology + base needed for such a high bandwidth ubiquitous network. + + + 1.2. Ongoing Activities + + + The OSTP report referred to above recommended a three-phase approach + to achieving the required high-bandwidth networking for the + scientific and research community. Some of this work is now well + underway. An ad-hoc committee, the Federal Research Internet + Coordinating Committee (FRICC) is coordinating the interconnection of + the current wide area networking systems in the government; notably + those of DARPA, Department of Energy (DoE), National Science + Foundation (NSF), National Aeronautics and Space Administration + (NASA), and the Department of Health and Human Services (HHS). In + accordance with Phases I and II of the OSTP report, this activity + will provide for an interconnected set of networks to support + research and other scholarly pursuits, and provide a basis for future + networking for this community. The networking is being upgraded + through shared increased bandwidth (current plans are to share a 45 + Mbit/s backbone) and coordinated interconnection with the rest of the + world. In particular, the FRICC is working with the European + networking community under the auspices of another ad-hoc group, the + Coordinating Committee for Intercontinental Research Networks + (CCIRN), to establish effective US-Europe networking. + + However, as the OSTP recommendations note, the required bandwidth for + the future is well beyond currently planned public, private, and + government networks. Achieving the required gigabit networking + capabilities will require a strong research activity. There is + considerable ongoing research in relevant areas that can be drawn + upon; particularly in the areas of high-bandwidth communication + links, high-speed computer switching, and high-bandwidth local area + networks. Appendix A provides some pointers to current research + efforts. + + + + + + +Gigabit Working Group [Page 3] + +RFC 1077 November 1988 + + + 1.3. Document Overview + + + This report outlines a set of research topics aimed at providing the + technology base for an interconnected set of networks that can + provide the required high-bandwidth capabilities discussed above. + The suggested research focus draws upon ongoing research and augments + it with basic and applied components. The major activities are the + development and demonstration of a Gigabit Backbone network (GB) [3], + the development and demonstration of an interconnected set of + networks with gigabit throughput and appropriate management + techniques, and the development and demonstration of the required + overall architecture that allows users to gain access to such high + bandwidth. Section 2 discusses functional and performance goals + along with the anticipated benefits to the ultimate users of such a + system. Section 3 provides the discussion of the critical research + issues needed to achieve these goals. It is organized into the major + areas of technology that need to be addressed: general architectural + issues, high-bandwidth switching, high-bandwidth host interfaces, + network management algorithms, and network services. The discussion + in some cases contains examples of ongoing relevant research or + potential approaches. These examples are intended to clarify the + issues and not to propose that particular approach. A discussion of + the relationship of the suggested research to other ongoing + activities and optimal methods for pursuing this research is provided + in Section 4. + + + 2. Functional and Performance Goals + + + In this section, we provide an assessment of the types of services a + GN (four or five orders of magnitude faster than the current + networks) should provide to its users. In instances where we felt + there would be a significant impact on performance, we have provided + an estimate of the amount of bandwidth needed and delay allowable to + provide these services. + + + 2.1. Networking Application Support + + + It is envisioned that the GN will be capable of supporting all of the + following types of networking applications. + + + + + + + +Gigabit Working Group [Page 4] + +RFC 1077 November 1988 + + + Currently Provided Packet Services + + It is important that the network provide the users with the + equivalent of services that are already available in packet- + switched networks, such as interactive data exchange, mail + service, file transfer, on-line access to remote computing + resources, etc., and allow them to expand to other more advanced + services to meet their needs as they become available. + + Multi-Media Mail + + This capability will allow users to take advantage of different + media types (e.g., graphics, images, voice, and video as well as + text and computer data) in the transfer of messages, thereby + increasing the effectiveness of message exchange. + + Multi-Media Conferencing + + Such conferencing requires the exchange of large amounts of + information in short periods of time. Hence the requirement for + high bandwidth at low delay. We estimate that the bandwidth would + range from 1.5 to 100 Mbit/s, with an end-to-end delay of no more + than a few hundred msec. + + Computer-Generated Real-time Graphics + + Visualizing computer results in the modern world of supercomputers + requires large amounts of real time graphics. This in turn will + require about 1.5 Mbit/s of bandwidth and no more than several + hundred msec. delay. + + High-Speed Transaction Processing + + One of the most important reasons for having an ultra-high-speed + network is to take advantage of supercomputing capability. There + are several scenarios in which this capability could be utilized. + For example, there could be instances where a non-supercomputer + may require a supercomputer to perform some processing and provide + some intermediate results that will be used to perform still + further processing, or the exchange may be between several + supercomputers operating in tandem and periodically exchanging + results, such as in a battle management, war gaming, or process + control applications. In such cases, extremely short response + times are necessary to accomplish as many as hundreds of + interactions in real time. This requires very high bandwidth, on + the order of 100 Mbit/s, and minimum delay, on the order of + hundreds of msec. + + + + +Gigabit Working Group [Page 5] + +RFC 1077 November 1988 + + + Wide-Area Distributed Data/Knowledge Base Management Systems + + Computer-stored data, information, and knowledge is distributed + around the country for a variety of reasons. The ability to + perform complex queries, updates, and report generation as though + many large databases are one system would be extremely powerful, + yet requires low-delay, high-bandwidth communication for + interactive use. The Corporation for National Research + Initiatives (NRI) has promoted the notion of a National Knowledge + base with these characteristics. In particular, an attractive + approach is to cache views at the user sites, or close by to allow + efficient repeated queries and multi-relation processing for + relations on different nodes. However, with caching, a processing + activity may incur a miss in the midst of a query or update, + causing it to be delayed by the time required to retrieve the + missing relation or portion of relation. To minimize the overhead + for cache directories, both at the server and client sites, the + unit of caching should be large---say a megabyte or more. In + addition, to maintain consistency at the caching client sites, + server sites need to multicast invalidations and/or updates. + Communication requirements are further increased by replication of + the data. The critical parameter is latency for cache misses and + consistency operations. Taking the distance between sites to be + on average 1/4 the diameter of the country, a one Gbit/s data rate + is required to reduce the transmission time to be roughly the same + as the propagation delay, namely around 8 milliseconds for this + size of unit. Note that this application is supporting far more + sophisticated queries and updates than normally associated with + transaction processing, thus requiring larger amount of data to be + transferred. + + + 2.2. Types of Traffic and Communications Modes + + + Different types of traffic may impose different constraints in terms + of throughput, delay, delay dispersion, reliability and sequenced + delivery. Table 1 summarizes some of the main characteristics of + several different types of traffic. + + + + + + + + + + + + +Gigabit Working Group [Page 6] + +RFC 1077 November 1988 + + + Table 1: Communication Traffic Requirements + + +------------------------+-------------+-------------+-------------+ + | | | | Error-free | + | Traffic | Delay | Throughput | Sequenced | + | Type | Requirement | Requirement | Delivery | + +------------------------+-------------+-------------+-------------+ + | Interactive Simulation | Low |Moderate-High| No | + +------------------------+-------------+-------------+-------------+ + | Network Monitoring | Moderate | Low | No | + +------------------------+-------------+-------------+-------------+ + | Virtual Terminal | Low | Low | Yes | + +------------------------+-------------+-------------+-------------+ + | Bulk Transfer | High | High | Yes | + +------------------------+-------------+-------------+-------------+ + | Message | Moderate | Moderate | Yes | + +------------------------+-------------+-------------+-------------+ + | Voice |Low, constant| Moderate | No | + +------------------------+-------------+-------------+-------------+ + | Video |Low, constant| High | No | + +------------------------+-------------+-------------+-------------+ + | Facsimile | Moderate | High | No | + +------------------------+-------------+-------------+-------------+ + | Image Transfer | Variable | High | No | + +------------------------+-------------+-------------+-------------+ + | Distributed Computing | Low | Variable | Yes | + +------------------------+-------------+-------------+-------------+ + | Network Control | Moderate | Low | Yes | + +------------------------+-------------+-------------+-------------+ + + The topology among users can be of three types: point-to-point (one- + to-one connectivity), multicast (one sender and multiple receivers), + and conferencing (multiple senders and multiple receivers). There + are three types of transfers that can take place among users. They + are connection-oriented network service, connectionless network + service, and stream or synchronous traffic. Connection and + connectionless services are asynchronous. A connection-oriented + service assumes and provides for relationships among the multiple + packets sent over the connection (e.g., to a common destination) + while connectionless service assumes each packet is a complete and + separate entity unto itself. For stream or synchronous service a + reservation scheme is used to set up and guarantee a constant and + steady amount of bandwidth between any two subscribers. + + + + + + + + +Gigabit Working Group [Page 7] + +RFC 1077 November 1988 + + + 2.3. Network Backbone + + + The GB needs to be of high bandwidth to support a large population of + users, and additionally to provide high-speed connectivity among + certain subscribers who may need such capability (e.g., between two + supercomputers). These users may access the GN from local area + networks (LANs) directly connected to the backbone or via high-speed + intermediate regional networks. The backbone must also minimize + end-to-end delay to support highly interactive high-speed + (supercomputer) activities. + + It is important that the LANs that will be connected to the GN be + permitted data rates independent of the data rates of the GB. LAN + speeds should be allowed to change without affecting the GB, and the + GB speeds should be allowed to change without affecting the LANs. In + this way, development of the technology for LANs and the GB can + proceed independently. + + Access rate requirements to the GB and the GN will vary depending on + user requirements and local environments. The users may require + access rates ranging from multi-kbit/s in the case of terminals or + personal computers connected by modems up to multi-Mbit/s and beyond + for powerful workstations up to the Gbit/s range for high-speed + computing and data resources. + + + 2.4. Directory Services + + + Directory services similar to those found in CCITT X.500/ISO DIS 9594 + need to be provided. These include mapping user names to electronic + mail addresses, distribution lists, support for authorization + checking, access control, and public key encryption schemes, + multimedia mail capabilities, and the ability to keep track of mobile + users (those who move from place to place and host computer to host + computer). The directory services may also list facilities available + to users via the network. Some examples are databases, + supercomputing or other special-purpose applications, and on-line + help or telephone hotlines. + + The services provided by X.500 may require some extension for GN. + For example, there is no provision for multilevel security, and the + approach taken to authentication must be studied to ensure that it + meets the requirements of GN and its user community. + + + + + + +Gigabit Working Group [Page 8] + +RFC 1077 November 1988 + + + 2.5. Network Management and Routing + + + The objective of network management is to ensure that the network + functions smoothly and efficiently, and consists of the following: + accounting, security, performance monitoring, fault isolation and + configuration control. + + Accounting ensures that users are properly billed for the services + that the network provides. Accounting enforces a tariff; a tariff + expresses a usage policy. The network need only keep track of those + items addressed by the tariff, such as allocated bandwidth, number of + packets sent, number of ports used, etc. Another type of accounting + may need to be supported by the network to support resource sharing, + namely accounting analogous to telephone "900" numbers. This + accounting performed by the network on behalf of resource providers + and consumers is a pragmatic solution to the problem of getting the + users and consumers into a financial relationship with each other + which has stymied previous attempts to achieve widespread use of + specialized resources. + + Performance monitoring is needed so that the managers can tell how + the network is performing and take the necessary actions to keep its + performance at a level that will provide users with satisfactory + service. Fault isolation using technical control mechanisms is + needed for network maintenance. Configuration management allows the + network to function efficiently. + + Several new types of routing will be required by GN. In addition to + true type-of-service, needed to support diverse distributed + applications, real-time applications, interactive applications, and + bulk data transfer, there will be need for traffic controls to + enforce various routing policies. For example, policy may dictate + that traffic from certain users, applications, or hosts may not be + permitted to traverse certain segments of the network. + Alternatively, traffic controls may be used to promote fairness; that + is, to make sure that busy link or network segment isn't dominated by + a particular source or destination. The ability of applications to + reserve network bandwidth in advance of its use, and the use of + strategies such as soft connections, will also require development of + new routing algorithms. + + + 2.6. Network Security Requirements + + + Security is a critical factor within the GN and one of those features + that are difficult to provide. It is envisioned that both + + + +Gigabit Working Group [Page 9] + +RFC 1077 November 1988 + + + unclassified and classified traffic will utilize the GN, so + protection mechanisms must be an integral part of the network access + strategy. Features such as authentication, integrity, + confidentiality, access control, and nonrepudiation are essential to + provide trusted and secure communication services for network users. + + A subscriber must have assurance that the person or system he is + exchanging information with is indeed who he says he is. + Authentication provides this assurance by verifying that the claimed + source of a query request, control command, response, etc., is the + actual source. Integrity assures that the subscriber's information + (such as requests, commands, data, responses, etc.) is not changed, + intentionally or unintentionally, while in transit or by replays of + earlier traffic. Unauthorized users (e.g., intruders or network + viruses) would be denied use of GN assets through access control + mechanisms which verify that the authenticated source is authorized + to receive the requested information or to initiate the specified + command. In addition, nonrepudiation services can be offered to + assure a third party that the transmitted information has not been + altered. And finally, confidentiality will ensure that the contents + of a message are not divulged to unauthorized individuals. + Subscribers can decide, based upon their own security needs and + particular activities, which of these services are necessary at a + given time. + + + 3. Critical Research Issues + + + In the section above, we discussed the goals of a research program in + gigabit networking; namely to provide the technology base for a + network that will allow gigabit service to be provided in an + effective way. In this section, we discuss those issues which we + feel are critical to address in a research program to achieve such + goals. + + + 3.1. General Architectural Issues + + + In the last generation of networks, it was assumed that bandwidth was + the scarce resource and the design of the switch was dictated by the + need to manage and allocate the bandwidth effectively. The most + basic change in the next generation network is that the speeds of the + trunks are rising faster than the speeds of the switching elements. + + This change in the balance of speeds has manifested itself in several + ways. In most current designs for local area networks, where + + + +Gigabit Working Group [Page 10] + +RFC 1077 November 1988 + + + bandwidth is not expensive, the design decision was to trade off + effective use of the bandwidth for a simplified switching technique. + In particular, networks such as Ethernet use broadcast as the normal + distribution method, which essentially eliminates the need for a + switching element. + + As we look at still higher speed networks, and in particular networks + in which the bandwidth is still the expensive component, we must + design new options for switching which will permit effective use of + bandwidth without the switch itself becoming the bottleneck. + + The central thrust of new research must thus be to explore new + network architectures that are consistent with these very different + speed assumptions. + + The development of computer communications has been tremendously + distorted by the characteristics of wide-area networking: normally + high cost, low speed, high error rate, large delay. The time is ripe + for a revolution in thinking, technology, and approaches, analogous + to the revolution caused by VCR technology over 8 and 16 mm. film + technology. + + Fiber optics is clearly the enabling technology for high-speed + transmission, in fact, so much so that there is an expectation that + the switching elements will now hold down the data rates. Both + conventional circuit switching and packet switching have significant + problems at higher data rates. For instance, circuit switching + requires increasing delays for FTDM synchronization to handle skew. + In the case of packet switching, traditional approaches require too + much processing per packet to handle the tremendous data flow. The + problem for both switching regimes is the "intelligence" in the + switches, which in turn requires electronics technology. + + Besides intelligence, another problem for wide-area networks is + storage, both because it ties us to electronics (for the foreseeable + future) and because it produces instabilities in a large-scale + system. (See, for instance, the work by Van Jacobson on self- + organizing phenomena for self-destruction in the Internet.) + Techniques are required to eliminate dependence on storage, such as + cut-through routing. + + Overall, high-speed WANs are the greatest agents of change, the + greatest catalyst both commercially and militarily, and the area ripe + for revolution. Judging by the attributes of current high-speed + network research prototypes, WANs of the future will be photonic, + multi-gigabit networks with enormous throughput, low delay, and low + error rate. + + + + +Gigabit Working Group [Page 11] + +RFC 1077 November 1988 + + + A zero-based budgeting approach is required to develop the new high- + speed internetwork architecture. That is, the time is ripe to + significantly rethink the Internet, building on experience with this + system. Issues of concern are manageability, understanding + evolvability and support for the new communication requirements, + including remote procedure call, real-time, security and fault- + tolerance. + + The GN must be able to deal with two sources of high-bandwidth + requirements. There will be some end devices (computers) connected + more or less directly to the GN because of their individual + requirements for high bandwidth (e.g., supercomputers needing to + drive remote high-bandwidth graphics devices). In addition, the + aggregate traffic due to large numbers of moderate rate users + (estimates are roughly up to a million potential users needing up to + 1 Mbit/s at any given time) results in a high-bandwidth requirement + in total on the GN. The statistics of such traffic are different and + there are different possible technical approaches for dealing with + them. Thus, an architectural approach for dealing with both must be + developed. + + Overall, the next-generation architecture has to be, first and + foremost, a management architecture. The directions in link speeds, + processor speeds and memory solve the performance problems for many + communication situations so well that manageability becomes the + predominant concern. (In fact, fast communication makes large + systems more prone to performance, reliability, and security + problems.) In many ways, the management system of the internetwork + is the ultimate distributed system. The solution to this tough + problem may well require the best talents from the communications, + operating systems and distributed systems communities, perhaps even + drawing on database and parallelism research. + + + 3.1.1. High-Speed Internet using High-Speed Networks + + + The GN will need to take advantage of a multitude of different and + heterogeneous networks, all of high speed. In addition to networks + based on the technology of the GB, there will be high-speed LANs. A + key issue in the development of the GN will be the development of a + strategy for interconnecting such networks to provide gigabit service + on an end to end basis. This will involve techniques for switching, + interfacing, and management (as discussed in the sections below) + coupled with an architecture that allows the GN to take full + advantage of the performance of the various high-speed networks. + + + + + +Gigabit Working Group [Page 12] + +RFC 1077 November 1988 + + + 3.1.2. Network Organization + + + The GN will need an architecture that supports the need to manage the + system as well as obtain high performance. We note that almost all + human-engineered systems are hierarchically structured from the + standpoint of control, monitoring, and information flow. A + hierarchical design may be the key to manageability in the next- + generation architecture. + + One approach is to use a general three-level structure, corresponding + to interadministrational, intraadministrational, and cluster + networks. The first level interconnects communication facilities of + truly separate administrations where there is significant separation + of security, accounting, and goals. The second level interconnects + subadministrations which exist for management convenience in large + organizations. For example, a research group within a university may + function as a subadministration. The cluster level consists of + networks configured to provides maximal performance among hosts which + are in frequent communication, such as a set of diskless workstations + and their common file server. These hosts are typically, but not + necessarily, geographically collocated. For example, two remote + networks may be tightly coupled by a fiber optic link that bridges + between the two physical networks, making them function as one. + + Research along these lines should study the interorganizational + characteristics of communications, such as those being investigated + by the IAB Task Force on Autonomous Networks. Based on current + results, we expect that such work would clearly demonstrate that + considerable communication takes place between particular + subadministrations in different administrations; communication + patterns are not strictly hierarchical. For example, there might be + intense direct communication between the experimental physics + departments of two independent universities, or between the computer + support group of one company and the operating system development + group of another. In addition, (sub)administrations may well also + require divisions into public information and private information. + + + 3.1.3. Fault-Tolerant System + + + Although the GN will be developed as part of an experimental research + program, it will also serve as part of the infrastructure for + researchers who are experimenting with applications which will use + such a network. The GN must have reasonably high availability to + support these research activities. In addition to facilitate the + transfer of this technology to future operational military and + + + +Gigabit Working Group [Page 13] + +RFC 1077 November 1988 + + + commercial users, it will need to be designed to become highly + reliable. This can be accomplished through diversity of transmission + paths, the development of fault-tolerant switches, use of a + distributed control structure with self-correcting algorithms, and + the protection of network control traffic. The architecture of a GN + should support and allow for all of these things. + + + 3.1.4. Functional Division of Control Between Network Elements + + + Current protocol architectures use the layered model of functional + decomposition first developed in the early work on ARPANET protocols. + The concept of layering has been a powerful concept which has allowed + dramatic variation in network technologies without requiring the + complete reimplementation of applications. The concept of layering + has had a first-order impact on the development of international + standards for data communication---witness the ISO "Reference Model + for Open Systems Interconnection." + + Unfortunately, however, the powerful concept of layering has been + paired, both in the DoD Internet work and the ISO work, with an + extremely weak concept of the interface between layers. The + interface designs are all organized around the idea of commands and + responses plus an error indicator. For example, the TCP service + interface provides the user with commands to set up or close a TCP + connection and commands to send and receive datagrams. The user may + well "know" whether they are using a file transfer service or a + character-at-a- time virtual terminal, but can't tell the TCP. The + underlying network may "know" that failures have reduced the path to + the user's destination to a single 9.6 kbit/s link, but it also can't + tell the TCP implementation. + + All of the information that an analyst would consider crucial in + diagnosing system performance is carefully hidden from adjacent + layers. One "solution" often discussed (but rarely implemented) is + to condense all of this information into a few bits of "Type of + Service" or "Quality of Service" request flowing in one direction + only---from application to network. It seems likely that this + approach cannot succeed, both because it applies too much compression + to the knowledge available and because it does not provide two-way + flow. + + We believe it to be likely that the next-generation network will + require a much richer interface between every pair of adjacent layers + if adequate performance is to be achieved. Research is needed into + the conceptual mechanisms, both indicators and controls, that can be + implemented at these interfaces and that, when used, will result in + + + +Gigabit Working Group [Page 14] + +RFC 1077 November 1988 + + + better performance. If real differences in performance can be + observed, then the implementors of every layer will have a strong + incentive to make use of the mechanisms. + + We can observe the first glimmers of this sort of coordination + between layers in current work. For example, in the ISO work there + are 5 classes of transport protocol which are supposed to provide a + range of possible matches between application needs and network + capabilities. Unfortunately, it is the case today that the class of + transport protocol is chosen statically, by the implementer, rather + than dynamically. The DARPA Wideband net offers a choice of stream + or datagram service, but typically a given host uses all one or all + the other---again, a static rather than a dynamic choice. The + research that we believe is needed, therefore, is not how to provide + alternatives, but how to provide them and choose among them on a + dynamic, real-time basis. + + + 3.1.5. Different Switch Technologies + + + One approach to high-performance networking is to design a technology + that is expected to work as a stand-alone demonstration, without + addressing the need for interconnection to other networks. Such an + experiment may be very valuable for rapid exploration of the design + space. However, our experience with the Internet project suggests + that a primary research goal should be the development of a network + architecture that permits the interconnection of a number of + different switching technologies. + + The Internet project was successful to a large extent because it + could incorporate a number of new and preexisting network + technologies: various local area networks, store and forward + switching networks, broadcast satellite nets, packet radio networks, + and so on. In this way, it decoupled the use of the protocols from a + particular technology base. In fact, the technology base evolved + rapidly, but the Internet protocols themselves provided a stability + that led to their success. + + The next-generation architecture must similarly deal with a diverse + and evolving technology base. We see "fast-packet" switching now + being developed (for example in B-ISDN); we see photonic switching + and wavelength division multiplexing as more advanced technologies. + We must divorce our architecture from dependence on any one of these. + + At the host interface, we must divorce the multiplexing of the medium + from the form of data that the host sees. Today the packet is used + both as multiplexing and interface element. In the future, the host + + + +Gigabit Working Group [Page 15] + +RFC 1077 November 1988 + + + may see the network as a message-passing system, or as memory. At + the same time, the network may use classic packets, wavelength + division, or space division switching. + + A number of basic functions must be rethought to provide an + architecture that is not dependent on the underlying switching model. + For example, our transport protocols assume that data will be lost in + units of a packet. If part of a packet is lost, we discard the whole + thing. And if several packets are systematically lost in sequence, + we may not recover effectively. There must be a host-level unit of + error recovery that is independent of the network. This sort of + abstraction must be applied to all the aspects of service + specification: error recovery, flow control, addressing, and so on. + + + 3.1.6. Network Operations, Monitoring, and Control + + + There is a hierarchy of progressively more effective and + sophisticated techniques for network management that applies + regardless of network bandwidth and application considerations: + + 1. Reactive problem management + + 2. Reactive resource management + + 3. Proactive problem management + + 4. Proactive resource management. + + Today's network management strategies are primarily reactive rather + than proactive: Problem management is initiated in response to user + complaints about service outages; resource allocation decisions are + made when users complain about deterioration of quality of service. + Today's network management systems are stuck at step 1 or perhaps + step 2 of the hierarchy. + + Future network management systems will provide proactive problem + management---problem diagnosis and restoral of service before users + become aware that there was a problem; and proactive resource + management---dynamic allocation of network bandwidth and switching + resources to ensure that an acceptable level of service is + continuously maintained. + + The GN management system should be expected to provide proactive + problem and resource management capabilities. It will have to do so + while contending with three important changes in the managed network + environment: + + + +Gigabit Working Group [Page 16] + +RFC 1077 November 1988 + + + 1. More complicated devices under management + + 2. More diverse types of devices + + 3. More variety of application protocols. + + Performance under these conditions will require that we seriously + re-think how a network management system handles the expected high + volumes of raw management-related data. It will become especially + important for the system to provide thresholding, filtering, and + alerting mechanisms that can save the human operator from drowning in + data, while still permitting access to details when diagnostic or + fault isolation modes are invoked. + + The presence of expert assistant capabilities for early fault + detection, diagnosis, and problem resolution will be mandatory. + These capabilities are highly desirable today, but they will be + essential to contend with the complexity and diversity of devices and + applications in the Gigabit Network. + + In addition to its role in dealing with complexity, automation + provides the only hope of controlling and reducing the high costs of + daily management and operation of a GN. + + Proactive resource management in GNs must be better understood and + practiced, initially as an effort requiring human intervention and + direction. Once this is achieved, it too must become automated to a + high degree in the GN. + + + 3.1.7. Naming and Addressing Strategies + + + Current networks, both voice (telephone) and data, use addressing + structures which closely tie the address to the physical location on + the network. That is, the address identifies a physical access + point, rather than the higher-level entity (computer, process, human) + attached to that access point. In future networks, this physical + aspect of addressing must be removed. + + Consider, for example, finding the desired party in the telephone + network of today. For a person not at his listed number, finding the + number of the correct telephone may require preliminary calls, in + which advice is given to the person placing the call. This works + well when a human is placing the call, since humans are well equipped + to cope with arbitrary conversations. But if a computer is placing + the call, the process of obtaining the correct address will have to + be incorporated in the architecture as a core service of the network. + + + +Gigabit Working Group [Page 17] + +RFC 1077 November 1988 + + + Since it is reasonable to expect mobile hosts, hosts that are + connected to multiple networks, and replicated hosts, the issue of + mapping to the physical address must be properly resolved. + + To permit the network to maintain the dynamic mapping to current + physical address, it is necessary that high-level entities have a + name (or logical address) that identifies them independently of + location. The name is maintained by the network, and mapped to the + current physical location as a core network service. For example, + mobile hosts, hosts that are connected to multiple networks, and + replicated hosts would have static names whose mapping to physical + addresses (many-to-one, in some cases) would change with time. + + Hosts are not the only entities whose physical location varies. + Users' electronic mail addresses change. Within distributed systems, + processes and files migrate from host to host. In a computing + environment where robustness and survivability are important, entire + applications may move about, or they may be redundant. + + The needed function must be considered in the context of the mobility + and address resolution rates if all addresses in a global data + network were of this sort. The distributed network directory + discussed elsewhere in this report should be designed to provide the + necessary flexibility, and responsiveness. The nature and + administration of names must also be considered. + + Names that are arbitrary or unwieldy would be barely better than the + addresses used now. The name space should be designed so that it can + easily be partitioned among the agencies that will assign names. The + structure of names should facilitate, rather than hinder, the mapping + function. For example, it would be hard to optimize the mapping + function if names were flat and unstructured. + + + 3.2. High-Speed Switching + + + The term "high-speed switching" refers to changing the switching at a + high rate, rather than switching high-speed links, because the latter + is not difficult at low speeds. (Consider, for example, manual + switching of fiber connections). The switching regime chosen for the + network determines various aspects of its performance, its charging + policies, and even its effective capabilities. As an example of the + latter, it is difficult to expect a circuit-switched network to + provide strong multicast support. + + A major area of debate lies in the choice between packet switching + and circuit switching. This is a key research issue for the GN, + + + +Gigabit Working Group [Page 18] + +RFC 1077 November 1988 + + + considering also the possibility of there being combinations of the + two approaches that are feasible. + + + 3.2.1. Unit of Management vs. Multiplexing + + + With very high data rates, either the unit of management and + switching must be larger or the speed of the processor elements for + management and switching must be faster. For example, at a gigabit, + a 576 byte packet takes roughly 5 microseconds to be received so a + packet switch must act extremely fast to avoid being the dominant + delay in packet times. Moreover, the storage time for the packet in + a conventional store and forward implementation also becomes a + significant component of the delay. Thus, for packet switching to + remain attractive in this environment, it appears necessary to + increase the size of packets (or switch on packet groups), do so- + called virtual cut-through and use high-speed routing techniques, + such as high-speed route caches and source routing. + + Alternatively, for circuit switching to be attractive, it must + provide very fast circuit setup and tear-down to support the bursty + nature of most computer communication. This problem is rendered + difficult (and perhaps impossible for certain traffic loads) because + the delay across the country is so large relative to the data rate. + That is, even with techniques such as so-called fast select, + bandwidth is reserved by the circuit along the path for almost twice + the propagation time before being used. + + With gigabit circuit switching, because it is not feasible to + physically switch channels, the low-level switching is likely doing + FTDM on micro-packets, as is currently done in telephony. Performing + FTDM at gigabit data rates is a challenging research problem if the + skew introduced by wide-area communication is to be handled with + reasonable overhead for spacing of this micro-packets. Given the + lead and resources of the telephone companies, this area of + investigation should, if pursued, be pursued cooperatively. + + + 3.2.2. Bandwidth Reservation Algorithms + + + Some applications, such as real-time video, require sustained high + data rate streams over a significant period of time, such as minutes + if not hours. Intuitively, it is appealing for such applications to + pre-allocate the bandwidth they require to minimize the switching + load on the network and guarantee that the required bandwidth is + available. Research is required to determine the merits of bandwidth + + + +Gigabit Working Group [Page 19] + +RFC 1077 November 1988 + + + reservation, particular in conjunction with the different switching + technologies. There is some concern to raise that bandwidth + reservation may require excessive intelligence in the network, + reducing the performance and reliability of the network. In + addition, bandwidth reservation opens a new option for denial of + service by an intruder or malicious user. Thus, investigations in + this area need to proceed in concert with work on switching + technologies and capabilities and security and reliability + requirements. + + + 3.2.3. Multicast Capabilities + + + It is now widely accepted that multicast should be provided as a + user-level service, as described in RFC 1054 for IP, for example. + However, further research is required to determine the best way to + support this facility at the network layer and lower. It is fairly + clear that the GN will be built from point-to-point fiber links that + do not provide multicast/broadcast for free. At the most + conservative extreme, one could provide no support and require that + each host or gateway simulate multicast by sending multiple, + individually addressed packets. However, there are significant + advantages to providing very low level multicast support (besides the + obvious performance advantages). For example, multicast routing in a + flooding form provides the most fault-tolerant, lowest-delay form of + delivery which, if reserved for very high priority messages, provides + a good emergency facility for high-stress network applications. + Multicast may also be useful as an approach to defeat traffic + analysis. + + Another key issue arises with the distinction between so-called open + group multicast and closed group multicast. In the former, any host + can multicast to the group, whereas in the latter, only members of + the group can multicast to it. The latter is easier to support and + adequate for conferencing, for example. However, for more client- + server structured applications, such as using file/database server, + computation servers, etc. as groups, open multicast is required. + Research is needed to address both forms of multicast. In addition, + security issues arise in controlling the membership of multicast + groups. This issue should be addressed in concert with work on + secure forms of routing in general. + + + + + + + + + +Gigabit Working Group [Page 20] + +RFC 1077 November 1988 + + + 3.2.4. Gateway Technologies + + + With the wide-area interconnection of local networks by the GN, + gateways are expected to become a significant performance bottleneck + unless significant advances are made in gateway performance. In + addition, many network management concerns suggest putting more + functionality (such as access control) in the gateways, further + increasing their load and the need for greater capacity. This would + then raise the issue of the trade-off between general-purpose + hardware and special-purpose hardware. + + On the general-purpose side, it may be feasible to use a general- + purpose multiprocessor based on high-end microprocessors (perhaps as + exotic as the GaAs MIPS) in conjunction with a high-speed block + transfer bus, as proposed as part of the FutureBus standard (which is + extendible to higher speeds than currently commercially planned) and + intelligent high-speed network adaptors. This would also allow the + direct use of hardware, operating systems, and software tools + developed as part of other DARPA programs, such as Strategic + Computing. It also appears to make this gateway software more + portable to commercial machines as they become available in this + performance range. + + The specialized hardware approach is based on the assumption that + general-purpose hardware, particularly the interconnection bus, + cannot be fast enough to support the level of performance required. + The expected emphasis is on various interconnection network + techniques. These approaches appear to require greater expense, less + commercial availability and more specialized software. They need to + be critically evaluated with respect to the general-purpose gateway + hardware approach, especially if the latter is using multiple buses + for fault-tolerance as well as capacity extension (in the absence of + failure). + + The same general-purpose vs. special-purpose contention is an issue + with operating system software. Conventionally, gateways run + specialized run-time executives that are designed specifically for + the gateway and gateway functions. However, the growing + sophistication of the gateway makes this approach less feasible. It + appears important to investigate the feasibility of using a standard + operating system foundation on the gateways that is known to provide + the required security and reliability properties (as well as real- + time performance properties). + + + + + + + +Gigabit Working Group [Page 21] + +RFC 1077 November 1988 + + + 3.2.5. VLSI and Optronics Implementations + + + It appears fairly clear that gigabit communication will use fiber + optics for at least the near future. Without major advances in + optronics to allow effectively for optical computers, communication + must cross the optical-electronic boundary two or more times. There + are significant cost, performance, reliability, and security benefits + for minimizing the number of such crossings. (As an example of a + security benefit, optics is not prone to electronic surveillance or + jamming while electronics clearly is, so replacing an optic- + electronic-optic node with a pure optic node eliminates that + vulnerability point.) + + The benefits of improved technology in optronics is so great that its + application here is purely another motivation for an already active + research area (that deserves strong continued support). Therefore, + we focus here in the issue of matching current (and near-term + expected) optronics capabilities with network requirements. + + The first and perhaps greatest area of opportunity is to achieve + totally (or largely) photonic switches in the network switching + nodes. That is, most packets would be switched without crossing the + optics-electronics boundary at all. For this to be feasible, the + switch must use very simple switching logic, require very little + storage and operate on packets of a significant size. The source- + routed packet switches with loopback on blockage of Blazenet + illustrate the type of techniques that appear required to achieve + this goal. + + Research is required to investigate the feasibility of optronic + implementation of switches. It appears highly likely that networks + will at some point in the future be totally photonically switched, + having the impact on networking comparable to the effect of + integrated circuits on processors and memories. + + A next level of focus is to achieve optical switching in the common + case in gateways. One model is a multiprocessor with an optical + interconnect. Packets associated with established paths through the + gateway are optically switched and processed through the + interconnect. Other packets are routed to the multiprocessor, + crossing into the electronics domain. Research is required to marry + the networking requirements and technology with optronics technology, + pushing the state of the art in both areas in the process. + + Given the long-term presence of the optic-electronic boundary, + improvements in technology in this area are also important. However, + it appears that there is already enormous commercial research + + + +Gigabit Working Group [Page 22] + +RFC 1077 November 1988 + + + activity in this area, particularly within the telephone companies. + This is another area in which collaborative investigation appears far + better than an new independent research effort. + + VLSI technology is an established technology with active research + support. The GN effort does not appear to require major new + initiatives in the VLSI area, yet one should be open to significant + novel opportunities not identified here. + + + 3.2.6. High-Speed Transfer Protocols + + + To achieve the desired speeds, it will be necessary to rethink the + form of protocols. + + 1. The simple idea of a stateless gateway must be replaced by a + more complex model in which the gateway understands the + desired function of the end point and applies suitable + optimizations to the flow. + + 2. If multiplexing is done in the time domain, the elements of + multiplexing are probably so small that no significant + processing can be performed on each individually. They must + be processed as an aggregate. This implies that the unit of + multiplexing is not the same as the unit of processing. + + 3. The interfaces between the structural layers of the + communication system must change from a simple + command/response style to a richer system which includes + indications and controls. + + 4. An approach must be developed that couples the memory + management in the host and the structure of the transmitted + data, to allow efficient transfers into host memory. + + The result of rethinking these problems will be a new style of + communications and protocols, in which there is a much higher degree + of shared responsibility among the components (hosts, switches, + gateways). This may have little resemblance to previous work either + in the DARPA or commercial communities. + + + 3.3. High-Speed Host Interfaces + + + As networks get faster, the most significant bottleneck will turn out + to be the packet processing overhead in the host. While this does + + + +Gigabit Working Group [Page 23] + +RFC 1077 November 1988 + + + not restrict the aggregate rates we can achieve over trunks, it + prevents delivery of high data rate flows to the host-based + applications, which will prevent the development of new applications + needing high bandwidth. The host bottleneck is thus a serious + impediment to networked use of supercomputers. + + To build a GN we need to create new ways for hosts and their high + bandwidth peripherals to connect to networks. We believe that + pursuing research in the ways to most effectively isolate host and + LAN development paths from the GN is the most productive way to + proceed. By decoupling the development paths, neither is restricted + by the momentary performance of capability bottlenecks of the other. + The best context in which to view this separation is with the notion + of a network front end (NFE). The NFE can take the electronic input + data at many data rates and transform it into gigabit light data + appropriately packetized to traverse the GN. The NFE can accept + inputs from many types of gateways, hosts, host peripherals, and LANS + and provide arbitration and path set-up facilities as needed. Most + importantly, the NFE can perform protocol arbitration to retain + upward compatibility with the existing Internet protocols while + enabling those sophisticated network input sources to execute GN + specific high-throughput protocols. Of course, this introduces the + need for research into high-speed NFEs to avoid the NFE becoming a + bottleneck. + + + 3.3.1. VLSI and Optronics Implementations + + + In a host interface, unless the host is optical (an unlikely prospect + in the near-term), the opportunities for optronic support are + limited. In fact, with a serial-to-parallel conversion on reception + stepping the clock rate down by a factor of 32 (assuming a 32-bit + data path on the host interface), optronic speeds are not required in + the immediate future. + + One exception may be for encryption. Current VLSI implementations of + standard encryption algorithms run in the 10 Mbit/s range. Optronic + implementation of these encryption techniques and encryption + techniques specifically oriented to, or taking advantage of, optronic + capabilities appears to be an area of some potential (and enormous + benefit if achieved). + + The potential of targeted VLSI research in this area appears limited + for similar reasons discussed above with its application in high- + speed switching. The major benefits will arise from work that is + well-motivated by other research (such as high-performance + parallelism) and by strong commercial interest. Again, we need to be + + + +Gigabit Working Group [Page 24] + +RFC 1077 November 1988 + + + open to imaginative opportunities not foreseen here while keeping + ourselves from being diverted into low-impact research without + further insights being put forward. + + + 3.3.2. High-Performance Transport Protocols + + + Current transport protocols exhibit some severe problems for maximal + performance, especially for using hardware support. For example, TCP + places the checksum in the packet header, forcing the packet to be + formed and read fully before transmission begins. ISO TP4 is even + worse, locating the checksum in a variable portion of the header at + an indeterminate offset, making hardware implementation extremely + difficult. + + The current Internet has thrived and grown due to the existence of + TCP implementations for a wide variety of classes of host computers. + These various TCP implementations achieve robust interoperability by + a "least common denominator" approach to features and options. Some + applications have arisen in the current Internet, and analogs can be + envisioned for the GN environment, which need qualities of service + not generally supported by the ubiquitous generic TCP, and therefore + special purpose transport protocols have been developed. Examples + include special purpose transport protocols such as UDP (user + datagram protocol), RDP (reliable datagram protocol), LDP + (loader/debugger protocol), NETBLT (high-speed block transfer + protocol), NVP (network voice protocol) and PVP (packet video + protocol). Efforts are also under way to develop a new generic + transport protocol VMTP (versatile message transaction protocol) + which will remedy some of deficiencies of TCP, without the need to + resort to special purpose protocols for some applications. Research + is needed in this area to understand how transport level protocols + should be constructed for a GN which provide adequate qualities of + service and ease of implementation. + + A new transport protocol of reasonable success can be expected to + last for ten years more. Therefore, a new protocol should not be + over optimized for current networks and must not ignore the + functional deficiencies of current protocols. These deficiencies are + essential to remedy before it is feasible to deploy even current + distributed systems technology for military and commercial + applications. + + Forward Error Correction (FEC) is a useful approach when the + bandwidth/delay ratio of the physical medium is high, as can be + expected in transcontinental photonic links. A degenerate form of + FEC is to simply transmit multiple copies of the data; this allows + + + +Gigabit Working Group [Page 25] + +RFC 1077 November 1988 + + + one to trade bandwidth for delay and reliability, without requiring + much intelligence. In fact, it is generally true that reliability, + bandwidth, and delay are interrelated and an improvement in one + generally comes at the expense of the others for a given technology. + Research is required to find appropriate operating points in networks + using transmission components which offer extremely high bandwidth + with very good bit-error-rate performance. + + + 3.3.3. Network Adaptors + + + With the promised speed of networks, the future network adaptor must + be viewed as a memory interconnect, tying the memory in one host to + another, at least if the data rate and the low latency made possible + by the network is to be realized at the host-to-host or process-to- + process level. The challenge is too great to be met by just + implementing protocols in custom VLSI. + + Research is required to investigate the impact of network + interconnection on a machine architecture and to define and evaluate + new network adaptor architectures. Of key importance is integration + of network adaptor into the operating system so that process-to- + process communications performance matches that offered by the + network. In particular, we conjecture that the transport level will + be implemented largely, if not entirely, in the network adaptor, + providing the host with reliable memory-to-memory transfer at memory + speeds with a minimum of interrupt processing bus overhead and packet + processing. + + Drawing an analogy to RISC technology again, maximal performance + requires a well-designed and coordinated protocol, software, and + hardware (network adaptor) design. Current standard protocols are + significantly flawed for hardware compatibility, suggesting a need + for considerable further research on high-performance protocol + design. + + + 3.3.4. Host Operating System Software + + + Conventionally, communication has been an add-on to an operating + system. With the GN, the network may well become the fastest + "peripheral" connected to most nodes. High-performance process-to- + process (or application to application) communication will not be + achieved until the operating system is well designed for fast access + to and from the network. For example, incorporating templates of the + network packet header directly in the process descriptor may allow a + + + +Gigabit Working Group [Page 26] + +RFC 1077 November 1988 + + + process to initiate communications with minimal overhead. Similarly, + memory mapping can be used to eliminate copies between data arriving + from the network and it being delivered to the applications. With a + GN, an extra copy forced by the operating system may easily double + the perceived transfer time for a packet between applications. + + Besides matching data transfer mechanisms, operating systems must be + well-matched in security design to that supported by the host + interface and network as well. Otherwise, all but the most trivial + additional security actions by the operating system in common case + communication can easily eliminate the performance benefits of the + GN. For example, if the host has to do further encryption or + decryption, the throughput is likely to be at least halved and the + latency doubled. + + Research effort is required to further refine operating systems for + the level of performance offered by the GN. This effort may well be + best realized with coupling existing efforts in distributed systems + with the GN activities, as opposed to starting new separate efforts. + + + 3.4. Advanced Network Management Algorithms + + + An important emphasis for research into network management should be + on decentralized approaches. The ratio of propagation delay across + the country to data rates in a GN appear to be too great to deal + effectively with resource management centrally when traffic load is + bursty and unstable (and if it is not, one might argue there is no + problem). In addition, important principles of fault containment and + minimal privilege for reliability and security suggest that a + centralized management approach is infeasible. In particular, + compromising the security of one portion of the network should not + compromise the security of the whole network. Similarly, a failure + or fault should affect at most a local region of the network. + + The challenge is clearly to provide decentralized management + techniques that lead to good global behavior in the normal case and + acceptable behavior in expected worst-case failures, traffic + variations and security intrusions. + + + 3.4.1. Control Flow vs. Data Flow + + + Network operational communications can be separated into flow of user + data and flow of management/control data. However, the user data + must contain some amount of control data. One question that needs to + + + +Gigabit Working Group [Page 27] + +RFC 1077 November 1988 + + + be explored in light of changes in communications and computing costs + and performance is the trade-off between these two flows. An example + of a potential approach is to use data units which contain predefined + path indicators. The switch can perform a simple table look-up which + maps the path indicator onto the preferred outbound link and + transmits the packet immediately. There is a path set-up packet + which fills in the appropriate tables. Path set-up occurs before the + first data packet flows and then, while data is flowing, to improve + the routes during the lifetime of the connection. This concept has + been discussed in the Internet engineering group under the name of + soft connections. + + We note that separating the data flow from the control flow in the GN + has security and reliability advantages as well. We could encrypt + most of the packet header to provide confidentiality within the GN + and to limit the ability of intruders to perform traffic analysis. + And, by separating the control flow, we can encrypt all the control + exchanges between switches and the host front ends thereby offering + confidentiality and integrity. No unauthorized entity will be able + to alter or examine the control traffic. By employing a path set-up + procedure, we can assure that the GN NFE-to-NFE path is functioning + and also include user-specific requirements in the route. For + example, we could request a certain bandwidth allocation and simplify + the job of the switches in handling flow control. We could also set + up backup paths in case the output link will be busy for so many + microseconds that the packet cannot be stored until the link is + freed. + + + 3.4.2. Resource Management Algorithms + + + Most current networks deliver one quality of service. X.25 networks + deliver a reliable byte-stream. Most LANs deliver a best-effort + unreliable service. There are few networks today that can support + multiple types of service, and allocate their resources among them. + Indeed, for many networks, such as best-effort unreliable service, + there is little management of resources at all. The next generation + of network will require a much more controlled allocation of + resources. + + There will be a much wider range of desired types of service, with + current services such as remote procedure call mixing with new + services such as video streams. Unless these are separately + recognized and controlled, there is little reason to believe that + effective service can be delivered unless the network is very lightly + loaded. + + + + +Gigabit Working Group [Page 28] + +RFC 1077 November 1988 + + + In order to support multiple types of service, two things must + happen, both a change from current practice. First, the application + must describe to the network what type of service is required. + Second, the network must use this information to make resource + allocation decisions. Both of these practices present difficulties. + + Past experience suggests that application code is not prepared to + know or specify what service it needs. By custom, operating systems + provide a virtual world, and the applications in this world are + unaware of the relation between this and the reality of time and + space. Resource requests must be in real terms. Allocation of + resources in the network is difficult, because it requires that + decisions be made in the network, but as network packet throughput + increases, there is less time for decisions. + + The resolution of this latter conflict is to observe that decisions + must be made on larger units than the unit of multiplexing such as + the packet. This in turn implies that packets must be visible to the + network as being part of a sequence, as opposed to the pure datagram + model previously exploited. As suggested earlier in this report, + research is required to support this more complex form of switch + without compromising robustness. + + To permit the application to specify the service it needs, it will be + necessary to propose some abstraction of service class. By clever + design of this abstraction, it should be possible to allow the + application to describe its needs effectively. For example, an + application such as file transfer or mail has two modes of operation; + bulk data transfer and remote procedure call. The application may + not be able to predict when it will be in which mode, but if it just + describes both of them, the system may be able to adapt by observing + its current operation. + + Experimentation needs to be done to determine a suitable service + specification interface. This experimentation could be done in the + context of the current protocols, and could thus be undertaken at + once. + + + 3.4.3. Adaptive Protocols + + + Network operating conditions can vary quickly and over a wide range. + This is true of the current Internet, and is likely to affect the GN + too. Protocols that can adapt to changing circumstances would + provide more even and robust service than is currently possible. For + example, when error rates increased, a protocol implementation might + decide to use smaller packets, thus reducing the burden caused by + + + +Gigabit Working Group [Page 29] + +RFC 1077 November 1988 + + + retransmissions. + + The environment in which a protocol operates can be described in + terms of the service it is getting from the next lower layer. A + protocol implementation can adapt to changes in that service by + tuning its internal mechanisms (time-outs, retransmission strategies, + etc.). Therefore, to design adaptive protocols, we must understand + the interaction between protocol layers and the mechanisms used + within them. There has been some work done in this area. For + example, the SATNET measurement task force has looked at the + interactions between the protocol used by the SIMP, IP, and TCP. + What is needed is a more complete characterization of the + interactions at various layer boundaries, and the development of + appropriate protocol designs and mechanisms to provide for necessary + adaptations and renegotiations. + + + 3.4.4. Error Recovery Mechanisms + + + Being large and complex, GNs will experience a variety of faults such + as link or nodal failure, excessive buffer overflow due to faulty + flow and congestion control, and partial failure of switching fabric. + These failures, which also exist in today's networks, will have a + stronger effect in GNs where a large amount of data will be "stored" + in transit and, to expedite the switching, nodes will apply only + minimal processing to the packets traversing them. In source + routing, for example, a link failure may cause the loss of all + packets sent until the source is notified about the change in + topology. The longer is the delay in recovering from failures, the + higher is the degradation in performance observed by the users. + + To minimize the effects of failures, GNs will need to employ error + recovery mechanisms whereby the network detects failures and error + conditions, reconfigures itself to adapt to the new network state, + and notifies peripheral devices of the new configuration. Such + protocols, which have to be developed, will respond quickly, will be + decentralized or distributed to minimize the possibility of fatal + failures, and will complement, rather than replicate, the error + correction mechanisms of the end-to-end protocols, and the two must + operate in coordinated manner. To this end, the peripheral devices + will have to be knowledgeable about the intranet recovery mechanisms + and interact continuously with them to minimize the effect on the + connections they manage. + + + + + + + +Gigabit Working Group [Page 30] + +RFC 1077 November 1988 + + + 3.4.5. Flow Control + + + As networks become faster, two related problems arise. First, + existing flow control mechanisms such as windows do not work well, + because the window must be opened to such an extent to achieve + desired bandwidth that effective flow control cannot be achieved. + Second, especially for long-haul networks, the larger number of bits + in transit at one time becomes so large that most computer messages + will fit into one window. This means that traditional congestion + control schemes will cease to work well. + + What is needed is a combination of two approaches, both new. First, + for messages that are small (most messages generated by computers + today will be small, since they will fit into one round-trip time of + future networks), open-loop controls on flow and congestion are + needed. For longer messages (voice or video streams, for example), + some explicit resource commitment will be required. + + + 3.4.6. Latency Control and Real-Time Operations + + + Currently, there are several distinct approaches to latency control. + First, there are some networks which are physically short, more like + multiprocessor buses. Applications in these networks are built + assuming that delays will be short. + + Second, there are networks where the physical length is not + constrained by the design and may differ by orders of magnitude, + depending on the scope of the network. Most general purpose networks + fall in this category. In these networks, one of two things happens. + Either the application takes special steps to deal with variable + latency, such as echo suppression in voice networks, or these + applications are not supported. + + For most applications today, the latency in the network is not an + obvious issue so long as the network is not overloaded (which leads + to losses and long queues), because the protocol overhead masks the + variation in the network latency. This balance will change. The + latency due to the speed of light will obviously remain the same, but + the overhead will drop (of necessity if we are to achieve high + performance) which will leave speed of light and queueing as the most + critical sources of delay. + + This conclusion implies that if queueing delay can be controlled, it + will be possible to build networks with stable and controlled + latency. If applications exist that require this class of service, + + + +Gigabit Working Group [Page 31] + +RFC 1077 November 1988 + + + it can be supported. Either the network must be underloaded, so that + queues do not develop at all, or a specific class of service must be + supported in which resources are allocated to stabilize the delay. + + If this service is provided, it will still leave the application with + delays that can vary by several orders of magnitude, depending on the + physical size of the network. Research at the application level will + be required to see how applications can be designed to cope with this + variation. + + + 3.4.7. High-Speed Internetworking and Administrational Domains + + + Internetworking recognized that the value of communication services + increases significantly with wider interconnection but ignored + management and the role of administrations. As a consequence we see + that: + + 1. The Internet is more or less unmanageable, as evidenced by + performance, reliability, and security problems. + + 2. The Internet is being stressed by administrators that are + building networks to match their organization rather than the + geography. An example is a set of Ethernets at different + company locations operating as a single Internet network but + geographically dispersed and connected by satellite or leased + lines. + + The next generation of internetworking must focus on administration + and management. Internetworking must support cohesion within an + administration and a healthy separation between administrations. To + illustrate by analogy, the American and Soviet embassies in Mexico + City are geographically closer to each other than to their respective + home countries but further in administrational distance, including + security, accounting, etc. The emerging revolution in WANs makes + this issue that much more critical. The amount of communication to + exchange the state of systems is bound to increase enormously. The + potential cost of failures and security violations is frightening. + + A promising approach appears to be high-level gateways that guard + between administrations and require negotiations to set up access + paths between administrations. These paths are set up, and labeled + with agreements on authorization, security, accounting, and possible + resource limits. These administrative virtual circuits provide + transparency to the physical and geographical interconnection, but + need not support more than datagram packet delivery. One view is + that of communication contracts with high-level gateways acting as + + + +Gigabit Working Group [Page 32] + +RFC 1077 November 1988 + + + contract monitors at each end. The key is the focus on controlled + interadministrational connectivity, not the conventional protocol + concerns. + + Focus is required on developing an (inter)network management + architecture and the specifics of high-level gateways. The + structures of such gateways will have to take advantage of advances + in multi-processor architectures to handle the processing load. + Moreover, a key issue is being able to optimize communication between + administrations once the contract is in place, but without losing + control. Related is the issue of allowing high-speed interconnection + within a single administration, although geographical dispersed. + Another issue is fault-tolerance. High-level gateways contain state + information whose loss typically disrupts communication. How does + one minimize this problem? + + A key goal of these administrational gateways has to be failure + containment: How to protect against external (to administration) + problems and how to prevent local problems imposing liability on + others. A particular area of concern is the self-organizing problems + of large-scale systems, observed by Van Jacobson in the Internet. + Gateways must serve to damp out oscillations and control wide load + swings. Rate control appears to be a key area to investigate as a + basis for buffer management and for congestion control, as well as to + control offered load. + + Given the speed of new networks, and the sophistication of the + gateways suggested above, another key area to investigate is the + provision of high-speed network interface adaptors. + + + 3.4.8. Policy-Based Algorithms + + + Networks of today generally select routes based on minimizing some + measure such as delay. However, in the real world, route selection + will commonly be constrained at the global level by policy issues, + such as access rights to resources and accounting and billing for + usage. + + It is difficult for connectionless protocols such as Internet to deal + with policy controls, because a lack of state in the gateway implies + that a separate policy decision must be made for each packet in + isolation. As networks get faster, the cost of this processing will + be intolerable. One possible approach, discussed above, is to move + to a more sophisticated model in which there is knowledge in the + gateways of the ongoing flows. Alternatively, it may be possible to + design gateways that simply cache recent policy evaluations and apply + + + +Gigabit Working Group [Page 33] + +RFC 1077 November 1988 + + + them to successive packets. + + Routing based on policy is particularly difficult because a route + must be globally consistent to be useful; otherwise it may loop. + This implies that the every policy decision must be propagated + globally. Since there can be expected to be a large number of + policies, this global passing of information might easily lead to an + information explosion. + + There are at least two solutions. One is to restrict the possible + classes of policy. Another is to use some form of source route, so + that the route consistent with some set of policies is computed at + one point only, and then attached to the packet. Both of these + approaches have problems. A two-pronged research program is needed, + in which mechanisms are proposed, and at the same time the needed + policies are defined. + + The same trade-off can be seen for accounting and billing. A single + accounting metric, such as "bytes times distance", could be proposed. + This might be somewhat simple to implement, but would not permit the + definition of individual billing policies, as is now done in the + parts of the telephone system. The current connectionless transport + architectures such as TCP/IP or the connectionless ISO configuration + using TP4 do not have good tools for accounting for traffic, or for + restricting traffic from certain resources. Building these tools is + difficult in a connectionless environment, because an accounting or + control facility must deal with each packet in isolation, which + implies a significant processing burden as part of packet forwarding. + This burden is an increasing problem as switches are expected to + operate faster. + + The lack of these tools is proving a significant problem for network + design. Not only are accounting and control needed to support + management requirements, they are needed as a building block to + support enforcement of such things as multiple qualities of service, + as discussed above. + + Network accounting is generally considered to be simply a step that + leads to billing, and thus is often evaluated in terms of how simple + or difficult it will be to implement. Yet an accounting and billing + procedure is a mechanism for implementing a policy considered to be + desirable for reasons beyond the scope of accounting per se. For + example, a policy might be established either to encourage or + discourage network use, while fully recovering operational cost. A + policy of encouraging use could be implemented by a relatively high + monthly attachment charge and a relatively low per-packet charge. A + policy of discouraging use could be implemented by a low monthly + charge and a high per-packet charge. + + + +Gigabit Working Group [Page 34] + +RFC 1077 November 1988 + + + Network administrators have a relatively small number of variables + with which to implement policy objectives. Nevertheless, these + variables can be combined in a number of innovative ways. Some of + the possibilities include: + + 1. Classes of users (e.g., large or small institutions, for- + profit or non-profit). + + 2. Classes of service. + + 3. Time varying (e.g., peak and off-peak). + + 4. Volume (e.g., volume discounts, or volume surcharges). + + 5. Access charges (e.g., per port, or port * [bandwidth of + port]). + + 6. Distance (e.g., circuit-miles, airline miles, number of hops). + + Generally, an accounting procedure can be developed to support + voluntary user cooperation with almost any single policy objective. + Difficulties most often arise when there are multiple competing + policy objectives, or when there is no clear policy at all. + + Another aspect of accounting and billing procedures which must be + carefully considered is the cost of accumulating and processing the + data on which billing is based. Of particular concern is collection + of detailed data on a per-packet basis. As network circuit data + rates increase, the number of instructions which must be executed on + a per-packet basis can become the limiting factor in system + throughput. Thus, it may be appropriate to prefer accounting and + billing policies and procedures which minimize the difficulty of + collecting data, even if this approach requires a compromise of other + objectives. Similarly, node memory required for data collection and + any network bandwidth required for transmission of the data to + administrative headquarters are factors which must be traded off + against the need to process user packets. + + + 3.4.9. Priority and Preemption + + + The GN should support multiple levels of priority for traffic and the + preemption of network resources for higher priority use. Network + control traffic should be given the highest priority to ensure that + it is able to pass through the network unimpeded by congestion caused + by user-level traffic. There may be additional military uses for + multiple levels of priority which correspond to rank or level of + + + +Gigabit Working Group [Page 35] + +RFC 1077 November 1988 + + + importance of a user or the mission criticality of some particular + data. + + The use of and existence of priority levels may be different for + different types of traffic. For example, datagram traffic may not + have multiple priority levels. Because the network's transmission + speed is so high and traffic bursts may be short, it may not make + sense to do any processing in the switches to deal with different + priority levels. Priority will be more important for flow- (or + soft-connection-) oriented data or hard connections in terms of + permitting higher priority connections to be set up ahead of lower + priority connections. Preemption will permit requests for high + priority connections to reclaim network resources currently in use by + lower priority traffic. + + Networks such as the Wideband Satellite Network, which supports + datagram and stream traffic, implement four priority levels for + traffic with the highest reserved for network control functions and + the other three for user traffic. The Wideband Network supports + preemption of lower priority stream allocations by higher priority + requests. An important component of the use of priority and + preemption is the ability to notify users when requests for service + have been denied, or allocations have been modified or disrupted. + Such mechanisms have been implemented in the Wideband Network for + streams and dynamic multicast groups. + + Priority and preemption mechanisms for a GN will have to be + implemented in an extremely simple way so that they can take effect + very quickly. It is likely that they will have to built into the + hardware of the switch fabric. + + + 3.5. User and Network Services + + + As discussed in Section 2 above, there will need to be certain + services provided as part of the network operation to the users + (people) themselves and to the machines that connect to the network. + These services, which include such capabilities as white and yellow + pages (allowing users to determine what the appropriate network + identification is for other users and for network-available computing + resources) and distributed fault identification and isolation, are + needed in current networks and will continue to be required in the + networks of the future. The speed of the GN will serve to accentuate + this requirement, but at the same time will allow for new + architectures to be put in place for such services. For example, + Ethernet speeds in the local environment have allowed for more usable + services to be provided. + + + +Gigabit Working Group [Page 36] + +RFC 1077 November 1988 + + + 3.5.1. Impact of High Bandwidth + + + One issue that will need to be addressed is the impact on the user of + such high-bandwidth capabilities. Users are already becoming + saturated by information in the modern information-rich environment. + (Many of us receive more than 50 electronic mail messages each day, + each requiring some degree of human attention.) Methods will be + needed to allow users to cope with this ever-expanding access to + data, or we will run the risk of users turning back to the relative + peace and quiet of the isolated office. + + + 3.5.2. Distributed Network Directory + + + A distributed network directory can support the user-level directory + services and the lower-level name-to-address mapping services + described elsewhere in this report. It can also support distributed + systems and network management facilities by storing additional + information about named objects. For example, the network directory + might store node configurations or security levels. + + Distributing the directory eases and decentralizes the administrative + burdens and provides a more robust and survivable implementation. + + One approach toward implementing a distributed network directory + would be to base it upon the CCITT X.500/ISO DIS 9594 standard. This + avoids starting from ground zero and has the advantage of + facilitating interoperability with other communications networks. + However, research and development will be required even if this path + is chosen. + + One area in which research and development are required is in the + services supplied by the distributed network directory. The X.500 + standard is very general and powerful, but so far specific provisions + have been made only for storing information about network users and + applications. As mentioned elsewhere, multilevel security is not + addressed by X.500, and the approach taken toward authentication must + be carefully considered in view of DoD requirements. Also, X.500 + assumes that administration of the directory will be done locally and + without the need for standardization; this may not be true of GN or + the larger national research network. + + The model and algorithms used by a distributed network directory + constitute a second area of research. The model specified by X.500 + must be extended into a framework that provides the necessary + flexibility in terms of services, responsiveness, data management + + + +Gigabit Working Group [Page 37] + +RFC 1077 November 1988 + + + policies, and protocol layer utilization. Furthermore, the internal + algorithms and mechanisms of X.500 must be extended in a number of + areas; for example, to support redundancy of the X.500 database, + internal consistency checking, fuller sharing of information about + the distribution of data, and defined access-control mechanisms. + + + 4. Avenues of Approach + + + Ongoing research and commercial activities provide an opportunity for + more rapidly attacking some of the above research issues. At the + same time, there needs to be attention paid to the overall technical + approach used to allow multiple potential solutions to be explored + and allow issues to be attacked in parallel. + + + 4.1. Small Prototype vs. Nationwide Network + + + The central question is how far to jump, and how far can the current + approaches get. That is, how far will connectionless network service + get us, how far will packet switching get us, and how far do we want + to go. If our goal is a Gbit/s net, then that is what we should + build. Building a 100 Mbit/s network to achieve a GN is analogous to + climbing a tree to get to the moon. It may get you closer, but it + will never get you there. + + There are currently some network designs which can serve as the basis + for a GN prototype. The next step is some work by experts in + photonics and possibly high-speed electronics to explore ease of + implementation. Developing a prototype 3-5 node network at a Gbit/s + data rate is realistic at this point and would demonstrate wide-area + (40 km or more) Gbit/s networking. + + DARPA should consider installing a Gbit/s cross-country set of + connected links analogous to the NSF backbone in 2 years. A Gbit/s + link between the east and west coasts would open up a whole new + generation of (C3I), distributed computing, and parallel computing + research possibilities and would reestablish DARPA as the premier + network research funding agency in the country. This will require + getting "dark" fiber from one or more of the common carriers and some + collaboration with these organizations on repeaters, etc. With this + collaboration, the time to a commercial network in the Gbit/s range + would be substantially reduced, and the resulting nationwide GN would + give the United States an enormous technical and economic advantage + over countries without it. + + + + +Gigabit Working Group [Page 38] + +RFC 1077 November 1988 + + + Demonstrating a high-bandwidth WAN is not enough, however. As one + can see from the many research issues identified above, it will be + necessary to pursue via study and experiment the issues involved in + interconnecting high-bandwidth networks into a high-bandwidth + internet. These experiments can be done through use of a new + generation of internet, even if it requires starting at lower speeds + (e.g., T1 through 100 Mbit/s). Appropriate care must be given, + however, to assure that the capabilities that are demonstrated are + applicable to the higher bandwidths (Gbit/s) as they emerge. + + + 4.2. Need for Parallel Efforts/Approaches + + + Parallel efforts will therefore be required for two major reasons. + First is the need to pursue alternative approaches (e.g., different + strategies for high-bandwidth switching, different addressing + techniques, etc). This is the case for most research programs, but + it is made more difficult here by the costs of prototyping. Thus, it + is necessary that appropriate review take place in the decisions as + to which efforts are supported through prototyping. + + In addition, it will be necessary to pursue the different aspects of + the program in parallel. It will not be possible to wait until the + high-bandwidth network is available before starting on prototyping + the high-bandwidth internet. Thus, a phased and evolutionary + approach will be needed. + + + 4.3. Collaboration with Common Carriers + + + Computer communication networks in the United States today + practically ignore the STN (the Switched Telephone Network), except + for buying raw bandwidth through it. However, advances in network + performance are based on improvements in the underlying communication + media, including satellite communication, fiber optics, and photonic + switching. + + In the past we used "their" transmission under "our" switching. An + alternative approach is to utilize the common-carrier switching + capabilities as an integral part of the networking architecture. We + must take an objective scientific and economic look and reevaluate + this question. + + Another place for cooperation with the common carriers is in the area + of network addressing. Their addressing scheme ("numbering plan") + has a few advantages such as proven service to 300 million users [4]. + + + +Gigabit Working Group [Page 39] + +RFC 1077 November 1988 + + + On the other hand, the common carriers have far fewer administrative + domains (area codes) than the current plethora of locally + administered local area networks in the internet system. + + It is likely that future networks will eventually be managed and + operated by commercial communications providers. A way to maximize + technology transfer from the research discussed here to the + marketplace is to involve the potential carriers from the start. + However, it is not clear that the goals of commercial communications + providers, who have typically been most interested in meeting the + needs of 90+ percent of the user base, will be compatible with the + goals of the research described here. Thus, while we recommend that + the research program involve an appropriate amalgam of academia and + industry, paying particular attention to involvement of the potential + system developers and operators, we also caution that the specific + and unique goals of the DARPA program must be retained. + + + 4.4. Technology Transfer + + + As we said above, it is our belief that future networks will + ultimately be managed and operated by commercial communications + providers. (Note that this may not be the common carriers as we know + them today, but may be value-added networks using common carrier + facilities.) The way to assure technology transfer, in our belief, is + to involve the potential system developers from the start. We + therefore believe that the research program would benefit from an + appropriate amalgam of university and industry, with provision for + close involvement of the potential system developers and operators. + + + 4.5. Standards + + + The Internet program was a tremendous success in influencing national + and international standards. While there were changes to the + protocols, the underlying technology and approaches used by CCITT and + ISO in the standardization of packet-switched networks clearly had + its roots in the DARPA internet. Nevertheless, this has had some + negative impact on the research program, as the evolution of the + standards led to pressure to adopt them in the research environment. + + Thus, it appears that there is a "catch-22" here. It is desirable + for the technology base developed in the research program to have + maximal impact on the standards activities. This is expedited by + doing the research in the context of the standards environment. + However, standards by their very nature will always lag behind the + + + +Gigabit Working Group [Page 40] + +RFC 1077 November 1988 + + + research environment. + + The only reasonable approach, therefore, appears to be an occasional + "checkpointing" of the research environment, where the required + conversions take place to allow a new plateau of standards to be used + for future evolution and research. A good example is conducting + future research in mail using X.400 and X.500 where possible. + + + 5. Conclusions + + + We hope that this document has provided a useful compendium of those + research issues critical to achieving the FCCSET phase III + recommendations. These problems interact in a complex way. If the + only goal of a new network architecture was high speed, reasonable + solutions would not be difficult to propose. But if one must achieve + higher speeds while supporting multiple services, and at the same + time support the establishment of these services across + administrative boundaries, so that policy concerns (e.g., access + control) must be enforced, the interactions become complex. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gigabit Working Group [Page 41] + +RFC 1077 November 1988 + + + APPENDIX + +A. Current R and D Activities + + In this appendix, we provide pointers to some ongoing activities in + the research and development community of which the group was aware + relevant to the goal of achieving the GN. In some cases, a short + abstract is provided of the research. Neither the order of the + listing (which is random) nor the amount of detail provided is meant + to indicate in any way the significance of the activity. We hope + that this set of pointers will be useful to anyone who chooses to + pursue the research issues discussed in this report. + + 1. Grumman (at Bethpage) is working on a three-year DARPA + contract, started in January 1988 to develop a 1.6 Gbit/s LAN, + for use on a plane or ship, or as a "building block". It is + really raw transport capacity running on two fibers in a + token-ring like mode. First milestone (after one year?) is to + be a 100 Mbit/s demonstration. + + 2. BBN Laboratories, as part of its current three-year DARPA + Network-Oriented Systems contract, has proposed design + concepts for a 10-100 Gbit/s wide area network. Work under + this effort will include wavelength division multiplexing, + photonic switching, self-routing packets, and protocol design. + + 3. Cheriton (Stanford) research on Blazenet, a high-bandwidth + network using photonic switching. + + 4. Acampora (Bell Labs) research on the use of wavelength + division multiplexing for building a shared optical network. + + 5. Yeh is reserching a VLSI approach to building high-bandwidth + parallel processing packet switch. + + 6. Bell Labs is working on a Metropolitan Area Network called + "Manhattan Street Net." This work, under Dr. Maxemchuck, is + similar to Blazenet. It is in the prototype stage for a small + number of street intersections; ultimately it is meant to be + city-wide. Like Blazenet, is uses photonic switching 2 x 2 + lithium niobate block switches. + + 7. Ultra Network Technologies is a Silicon Valley company which + has a (prototype) Gbit/s fiber link which connects backplanes. + This is based on the ISO-TP4 transport protocol. + + 8. Jonathan Turner, Washington University, is working on a + Batcher-Banyan Multicast Net, based on the "SONET" concept, + + + +Gigabit Working Group [Page 42] + +RFC 1077 November 1988 + + + which provides 150 Mbit/s per pipe. + + 9. David Sincowskie, Bellcore, is working with Batcher-Banyan + design and has working 32x32 switches. + + 10. Stratacom has a commercial product which is really a T1 voice + switch implemented internally by a packet switch, where the + packet is 192 bits (T1 frame). This switch can pass 10,000 + packets per second. + + 11. Stanford NAB provides 30-50 Mbit/s throughput on 100 Mbit/s + connection using Versatile Message Transaction Protocol (VMTP) + [see RFC 1045] + + 12. The December issue of IEEE Journal on Selected Areas in + Communications, provides much detail concerning interconnects. + + 13. Ultranet Technology has a 480 Mbit/s connection using modified + ISO TP4. + + 14. At MIT, Dave Clark has an architecture proposal of interest. + + 15. At CMU, the work of Eric Cooper is relevant. + + 16. At Protocol Engines, Inc., Greg Chesson is working on an XTP- + based system. + + 17. Larry Landweber at Wisconsin University is doing relevant + work. + + 18. Honeywell is doing relevant work for NASA. + + 19. Kung at CMU is working on a system called "Nectar" based on a + STARLAN on fiber connecting dissimilar processors. + + 20. Burroughs (now Unisys) has some relevant work within the IEEE + 802.6 committee. + + 21. Bellcore work in "Switched Multimedia Datanet Service" (SMDS) + is relevant (see paper supplied by Dave Clark). + + 22. FDDI-2, a scheme for making TDMA channel allocations at 200 + Mbit/s. + + 23. NRI, Kahn-Farber Proposal to NSF, is a paper design for high- + bandwidth network. + + 24. Barry Goldstein work, IBM-Yorktown. + + + +Gigabit Working Group [Page 43] + +RFC 1077 November 1988 + + + 25. Bell Labs S-Net, 1280 Mbit/s prototype. + + 26. Fiber-LAN owned by Bell South and SECOR, a pre-prototype 575 + Mbit/s Metro Area Net. + + 27. Bellcore chip implementation of FASTNET (1.2 Gbit/s). + + 28. Scientific Computer Systems, San Diego, 1.4 Gbit/s prototype. + + 29. BBN Monarch Switch, Space Division pre-prototype, chips being + fabricated, 64 Mbit/s per path. + + 30. Proteon, 80 Mbit/s token ring. + + 31. Toronto University, 150 Mbit/s "tree"--- really a LAN. + + 32. NSC Hyperchannel II, reputedly available at 250 Mbit/s. + + 33. Tobagi at Stanford working on EXPRESSNET; not commercially + available. + + 34. Columbia MAGNET-- 150 Mbit/s. + + 35. Versatile Message Transaction Protocol (VMTP). + + 36. ST integrated with IP. + + 37. XTP (Chesson). + + 38. Stanford Transport Gateway. + + 39. X.25/X.75. + + 40. Work of the Internet Activities Board. + + + + + + + + + + + + + + + + + +Gigabit Working Group [Page 44] + +RFC 1077 November 1988 + + +B. Gigabit Working Group Members + +Member Affiliation + +Gordon Bell Ardent Computers +Steve Blumenthal BBN Laboratories +Vint Cerf Corporation for National Research Initiatives +David Cheriton Stanford University +David Clark Massachusetts Institute of Technology +Barry Leiner (Chairman) Research Institute for Advanced Computer Science +Robert Lyons Defense Communication Agency +Richard Metzger Rome Air Development Center +David Mills University of Delaware +Kevin Mills National Bureau of Standards +Chris Perry MITRE +Jon Postel USC Information Sciences Institute +Nachum Shacham SRI International +Fouad Tobagi Stanford University + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gigabit Working Group [Page 45] + +RFC 1077 November 1988 + + +End Notes + + [1] Workshop on Computer Networks, 17-19 February 1987, San Diego, + CA. + + [2] "A Report to the Congress on Computer Networks to Support + Research in the United States: A Study of Critical Problems and + Future Options", White House Office of Scientific and Technical + Policy (OSTP), November 1987. + + [3] We distinguish in the report between development of a backbone + network providing gigabit capacity, the GB, and an + interconnected set of high-speed networks providing high- + bandwidth service to the user, the Gigabit Network (GN). + + [4] Incidentally, they already manage to serve 150 million + subscribers in an 11-digit address-space (about 1:600 ratio). + We have a 9.6-digit address-space and are running into troubles + with much less than 100,000 users (less than 1:30,000 ratio). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gigabit Working Group [Page 46] + |