Article 6563 of comp.protocols.tcp-ip: From: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) Subject: TCP/IP versus OSI Message-ID: <2145@cpoint.UUCP> Date: 15 Mar 89 12:37:56 GMT Reply-To: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) Organization: Clearpoint Research Corp., Hopkinton Mass. The following is an article which I am going to submit to Data Communications in reply to a column which William Stallings did on me a few months ago. I think people in this forum might be interested, and I would not mind some comments. Round 2 in the great TCP/IP versus OSI Debate I. INTRODUCTION When ISO published the first proposal for the ISO reference model in 1978, DARPA-sponsored research in packet switching for data communications had already been progressing for over 10 years. The NCP protocol suite, from which the X.25 packet-switching protocol suite originated, had already been rejected as unsuitable for genuine resource-sharing computer networks. The major architectural and protocol development for internetting over the ARPANET was completed during the 1978-79 period. The complete conversion of DARPA-sponsored networks to internetting occurred in January, 1983, when DARPA required all ARPANET computers to use TCP/IP. Since then, with an effective architecture, with working protocols on real networks, researchers and developers within the ARPA Internet community have been refining computer networking and providing continually more resource sharing at lower costs. At the same time, with no obvious architecture, with theoretical or idealized networks and while actively ignoring the work being done in the ARPA Internet context, the ISO OSI standards committees were developing basic remote terminal and file transfer protocols. The ISO OSI protocol suite generally provides potentially much less at much more cost than the ARPA Internet suite already provides. No one should be surprised that many computer networking system architects wish to debate the merits of the OSI reference model and that many relatively pleased business, technical and academic users of the ARPA Internet protocol suite would like such a debate to be actively pursued in the media. ______________________________________________________________ | | | Background | | | |Since June, 1988 William Stallings and I have been engaging| |in a guerilla debate in the reader's forum and the EOT| |feature on the technical and economic merits of OSI versus| |ARPANET-style networking. Enough issues have been raised to| |require a complete article to continue the discussion. The| |debate is of major interest because managers are now making| |strategic decisions which will affect the development, cost| |and functionality of corporate networks over the whole| |world. A valid approach to the debate deals with the| |technical, economic and logistic issues but avoids ad| |hominem attacks. I apologize for those comments in my forum| |letter which might be construed as personal attacks on| |William Stallings. | | | |Since I have not yet published many papers and my book is| |only 3/4s finished, I should introduce myself before I| |refute the ideas which Stallings presented in the September| |EOT feature. I am a system designer and implementer who is| |a founder and Project Director at Constellation Technologies| |which is a Boston-based start-up consulting and| |manufacturing company specializing in increasing the| |performance, reliability and security of standard low-level| |communications technologies for any of the plethora of| |computer networking environments currently available. | | | |I am not an "Arpanet Old Network Boy." My original| |experience is in telephony. I have implemented Signaling| |System 6, X.25, Q.921 and Q.931. During a one-year research| |position at MIT, I worked on TFTP and helped develop the X| |network transparent windowing protocol. Later I developed| |PC/NTS which uses IEEE 802.2 Type 2 to provide PC-Prime| |Series 50 connectivity over IEEE 802.3 (Ethernet) networks.| |My partner Tony Bono and I have attended various IEEE and| |CCITT standards-related committees in various official| |capacities. | _____________________________________________________________| II. THE DEBATE Part of the problem with debating is the lack of a mutually agreeable and understood set of concepts in which to frame the debate. I have yet to meet a communications engineer who had a sense of what a process might be. Having taught working software and hardware engineers at Harvard University and AT&T and having attended the international standards committees with many hardware, software and communications engineers, I have observed that overall system design concepts in computer networking need a lot more attention and understanding than they have been getting. Normally in the standardization process, this lack of attention would not be serious because official standards bodies usually simply make official already existing de facto standards like Ethernet 2.0 which had already proven themselves. In the case of OSI, the ISO committee, for no obvious reasons, chose to ignore the proven ARPA Internet de facto standard. ______________________________________________________________ | | | Architecture, | | Functional Specification, | | Design Specification | | | | |Nowadays, we read a lot of hype about CASE, object-oriented| |program techniques and languages designed to facilitate or| |to ease the development of large software projects. These| |tools generally duck the hardest and most interesting system| |design and development problem which is the design under| |constraint of major systems which somebody might actually| |want to buy. The hype avoids the real issue that student| |engineers are either simply not taught or do not learn| |system design in university engineering programs. If| |software engineers generally knew how to produce acceptable| |architectures, functional specifications and design| |specifications, the push for automatic tools would be much| |less. In fact, the development of CASE tools for automatic| |creation of systems architectures, functional specifications| |and design specifications requires understanding exactly how| |to produce proper architectures and specifications. But if| |engineers knew how to produce good architectures and| |specifications for software, presumably student engineers| |would receive reasonable instruction in producing| |architectures and specifications, and then there would be| |much less need for automatic CASE tools to produce system| |architectures, functional specifications or design| |specifications. | | | |Just as an architectural description of a building would| |point out that a building is Gothic or Georgian, an| |operating system architecture might point out that the| |operating system is multitasking, pre-emptively time-sliced| |with kernel privileged routines running at interrupt level.| |A system architecture would describe statically and| |abstractly the fundamental operating system entities. In| |Unix, the fundamental operating system entities on the user| |side would be the process and the file. The functional| |specification would describe the functionality to be| |provided to the user within the constraints of the| |architecture. A functional specification should not list the| |function calls used in the system. The design specification| |should specify the model by which the architecture is to be| |implemented to provide the desired functionality. A little| |pseudocode can be useful depending on the particular design| |specification detail level. Data structures, which are| |likely to change many times during implementations, should| |not appear in the design specification. | | | |Ancillary documents which treat financial and project| |management issues should be available to the development| |team. In all cases documents must be short. Otherwise,| |there is no assurance the all members of the development or| |product management teams will read and fully comprehend| |their documents. Detail and verbiage can be the enemy of| |clarity. Good architectures and functional specifications| |for moderately large systems like Unix generally require| |about 10-20 pages. A good high-level design specification| |for such a system would take about 25 pages. If the| |documents are longer, something may be wrong. The key is| |understanding what should not be included in such documents.| |The ISO OSI documents generally violate all these| |principles. | _____________________________________________________________| As a consequence, the ISO OSI committee and OSI boosters have an obligation to justify their viewpoint in debate and technical discussion with computer networking experts and system designers. Unfortunately, the debate over the use of OSI versus TCP/IP has so far suffered from three problems: o a lack of systems level viewpoint, o a lack of developer insight and o an hostility toward critical appraisal either technically or economically of the proposed ISO OSI standards. The following material is an attempt to engage in a critical analysis of OSI on the basis of system architecture, development principles and business economics. Note that in the following article unattributed quotations are taken from the itemized list which Stallings used in EOT to attempt to summarize my position. III. INTERNETWORKING: THE KEY SYSTEM LEVEL START POINT The most powerful system level architectural design concept in modern computer networking is internetworking. Internetworking is practically absent from the OSI reference model which concentrates on layering, which is an implementation technique, and on the virtual connection, which would be a feature of a proper architecture. Internetworking is good for the same reason Unix is good. The Unix architects and the ARPA Internet architects, after several missteps, concluded that the most useful designs are achieved by first choosing an effective computational or application model for the user and then figuring out how to implement this model on a particular set of hardware. Without taking a position on success or failure, I have the impression that the SNA and VMS architects by way of contrast set out to make the most effective use of their hardware. As a consequence both SNA and VMS are rather inflexible systems which are often rather inconvenient for users even though the hardware is often quite effectively used. Of course, starting from the user computational or application model does not preclude eventually making the most effective use of the hardware once the desired computational or application model has been implemented. ______________________________________________________________ | | | Internetworking | | | |The internetworking approach enables system designers and| |implementers to provide network users with a single, highly| |available, highly reliable, easily enlarged, easily| |modifiable, virtual network. The user does not need to know| |that this single virtual network is composed of a multitude| |of technologically heterogeneous wide area and local area| |networks with multiple domains of authority.| |Internetworking is achieved by means of a coherent system| |level view through the use of an obligatory internet| |protocol with ancillary monitoring protocol, gateways,| |exterior/internal gateway protocols and hierarchical domain| |name service. | | | |In the internetworking (not interworking) approach, if two| |hosts are attached to the same physical subnetwork of an| |internetwork, the hosts communicate directly with each| |other. If the hosts are attached to different physical| |subnetworks, the hosts communicate via gateways local to| |each host. Gateways understand and learn the internetwork| |topology dynamically at a subnetwork (not host level) and| |route data from the source subnetwork to destination| |subnetwork on a subnetwork hop by subnetwork hop basis. The| |detail of information required for routing and configuration| |is reduced by orders of magnitude. In the ARPA Internet,| |gateways learn topological information dynamically and| |provide reliability as well as availability by performing| |alternate routing of IP datagrams in cases of network| |congestion or network failures. | | | |An authoritative domain, Within the ARPA Internet, can| |conceal from the rest of the internetwork a lot of internal| |structural detail because gateways in other domains need| |only know about gateways within their own domain and| |gateways between authoritative domains. Thus, logical| |subnetworks of an internetwork may also themselves be| |catenets (concatenated networks) with internal gateways| |connecting different physical subnetworks within each| |catenet. For example, to send traffic to MIT, a gateway at| |U.C. Berkeley only need know about gateways between MIT and| |other domains and need know nothing about the internal| |structure of the MIT domain's catenet. | _____________________________________________________________| The ARPA Internet is one realization of the internetworking model. While I am not particularly enamored of some of the ARPA protocol features (nor of Unix features by the way),1 the ARPA Internet works well with capacity for expansion. SINet (described in "How to grow a world-class X.25 network," Data Communications, May 1988) is based on the CSNet subnetwork within the ARPA Internet. ____________________ 1 The use of local-IP-address, local-TCP-port, remote-IP- address, remote-TCP-port quadruples to uniquely identify a given TCP virtual circuit is an impediment to providing greater reliability and availability for a non-gateway multihomed host. A even larger problem with TCP/IP could lie in the possibly non-optimal partitioning of functionality between TCP, IP and ICMP. ____________________ ______________________________________________________________ | | | WANs and LANs | | | |OSI actually has an architecture. Like the ARPANET, OSI| |predicates the existence of a communications subnet| |consisting communications subnet processors (or subnet| |switches) and communications subnet access processors (or| |access switches). Access switches are also known as IMPs| |(Interface Message Processors) or PSNs (Packet Switch Nodes)| |in the ARPANET context. PSPDN (Packet-Switched Public Data| |Network) terminology usually designates access switches| |simply as packet switches. The communication subnet may be| |hierarchical and may contain adjunct processors other than| |subnet and access switches. The internal architecture of| |the communications subnet is quite distinct from the| |architecture presented to end-point hosts. The| |communications subnet may use protocols completely different| |from the protocols used for communication between two end-| |point hosts. An end-point host receives and transmits data| |to its attached access switch via a subnet access protocol.| |The communications subnet is responsible for taking a packet| |received at an access switch and transporting the packet to| |the access switch attached to the destination end-point| |host. The existence of such a well-defined communications| |subnet is the hall mark of a Wide-Area Network (WAN). | | |Unfortunately, from the standpoint of making computer| |networking generally and inexpensively available, access and| |subnet switches are expensive devices to build which need| |fairly complicated control software. DECNET gets around| |some of these problems by incorporating the communications| |subnet logic into end-point hosts. As a consequence,| |customers who wish to run DECNET typically have to purchase| |much more powerful machines than they might otherwise use.| |For the situation of a communications subnet which need| |support connectivity for only a small number of hosts, LAN| |developers found a more cost effective solution by| |developing a degenerate form of packet switches based on| |hardware-logic packet filtering rather than software| |controlled packet switching. These degenerate packet| |switches are installed in the end-point hosts, are accessed| |often via DMA2 as LAN controllers and are attached to| |extremely simplified communications subnets like coaxial| |cables. Direct host-to-switch (controller) access,| |degenerate packet-switching (packet-filtering) and| |simplified communications subnets are the distinguishing| |features of LANs. | | | |While ISO was ignoring the whole internetworking issue of| |providing universal connectivity between end-point hosts| |attached to different physical networks within internetworks| |composed of many WANs and even more LANs concatenated| |together, and while the IEEE was confusing all the issues by| |presenting as an end-to-end protocol a communications subnet| |protocol (IEEE 802.2) based on a communications subnet| |access protocol (X.25 level 2), the ARPA Internet community| |developed an internet architecture capable of providing the| |universal connectivity and resource sharing which business,| |technical and academic users really want and need. | ______________________________________________________________ ____________________ 2 Some machines like the Prime 50 Series do not use genuine DMA but instead use inefficient microcoded I/O. IBM machines generally use more efficient and somewhat more expensive internal switching. ____________________ The backbone of the ARPA Internet is the ARPANET. The ARPANET is a packet switched subnetwork within the ARPA Internet. The ARPANET communications subnet access protocol is 1822. CSNet was set up as an experiment to demonstrate that the ARPA Internet architecture and suite of protocols would function on a packet network whose communications subnet access protocol is X.25. Using an X.25-accessed packet network instead of an 1822-accessed packet network makes sense despite the glaring deficiencies of X.25,3 because X.25 controllers are available for many more systems than 1822 controllers and because many proprietary networking schemes like SNA and DECNET can use X.25-accessed packet networks but cannot use a packet network accessed by 1822. Yet, calling SINet a world class X.25 network is as reasonable as calling the ARPANET a world class 1822 network.4 Schlumberger has produced a world class TCP/IP network whose wires can be shared with SNA and DECNET hosts. Schlumberger has shown enthusiasm for the flexible, effective ARPANET suite of protocols but has given no support in the development of SINet to the idea that business should prepare to migrate to OSI based networks. I would be an OSI-enthusiast if ISO had reinvented internetworking correctly. Unfortunately, the ISO OSI reference model which first appeared in 1978 clearly ignored all the ARPA community work on intercomputer networking and resource sharing which was easily accessible in the literature of the time. Instead of building the OSI network on an internetworking foundation, ISO standardized on the older less effective host-to-packet-switch-to-packet-data- subnet-to-packet-switch-to-host (NCP) model which the DARPA ____________________ 3 For example, X.25 does flow control on the host to packet switch connection on the basis of packets transmitted rather than on the basis of consumption of advertised memory window. The exchange of lots of little packets on an X.25 connection can cause continual transmission throttling even though the receiver has lots of space for incoming data. 4 Or as much sense as calling Ethernet LANs DMA-based networks because the packet switches (an Ethernet controller is a degenerate case of a packet switch) on the LAN are typically accessed by DMA. ____________________ had abandoned 5 years earlier because of lack of flexibility and other problems. ______________________________________________________________ | | | Pieces of the ARPA Internet Conceptually | | | | | | | | | | | | | | (No Graphics) | | | | | ______________________________________________________________ Nowadays, mostly in response to US vendors and DARPA, pieces of the ARPA Internet architecture have resurfaced in the OSI reference model quite incoherently rather than as a consequence of an integrated correct architectural viewpoint. Connectionless-mode transmission is described in ISO/7498/DAD1 which is an addendum to ISO 7498 and not a core document. Because connectionless-mode transmission is defined in an addendum, the procedure apparently need not be implemented, and UK GOSIP, for example, explicitly rejects the use of the connectionless transmission mode. The introduction to the 1986 ISO 7498/DAD1 explicitly states, as follows, that ISO was extremely reluctant to incorporate a genuine datagram based protocol which could be used for internetworking. ISO 7498 describes the Reference Model of Open Systems Interconnection. It is the intention of that International standard that the Reference model should establish a framework for coordinating the development of existing and future standards for the interconnection of systems. The assumption that connection is a fundamental prerequisite for communication in the OSI environment permeates the Reference Model and is one of the most useful and important unifying concepts of the architecture which it describes. However, since the International Standard was produced it has been realized that this deeply-rooted connection orientation unnecessarily limits the power and scope of the Reference Model, since it excludes important classes of applications and important classes of communication network technology which have a fundamentally connectionless nature. An OSI connectionless-mode protocol packet may undergo something like fragmentation, but from the literature, this form of segmentation as used in OSI networks is hardly equivalent to ARPA Internet fragmentation. Stallings states the following in Handbook of Computer-Communications Standards, the Open Systems Interconnection (OSI) Model and OSI-Related Standards, on p. 18 (the only reference to anything resembling fragmentation in the book). Whether the application entity sends data in messages or in a continuous stream, lower level protocols may need to break up the data into blocks of some smaller bounded size. This process is called segmentation. Such a process is not equivalent to ARPA Internet fragmentation. In the ARPA Internet fragmentation is the process whereby the gateway software operating at the IP layer converts a single IP packet into several separate IP packets and then routes the packets. Each ARPA IP fragment has a full IP header. It is not obvious that each OSI segment has a complete packet header. The ARPA fragmentation procedure is not carried out by lower protocol layers. A N- layer packet in OSI is segmented at layer N-1 while the packet is routed (relayed) at layer N+1. This partitioning of basic internetworking procedures across layer 2 (N-1), layer 3 (N) and layer 4 (N+1) violates the following principles described in ISO/DIS 7498: Information Processing Systems -- Open Systems Interconnection -- Basic Reference Model. P1: do not create so many layers as to make the system engineering task of describing and integrating the layers more difficult than necessary [ISO uses three layers where one could be used]; P2: create a boundary at a point where the description of services can be small and the number or interactions across the boundary are minimized [by putting per-packet relaying in layer 4 at least two interactions across the boundary are required per packet]; P5: select boundaries at a point which past experience has demonstrated to be successful [the ARPA Internet layering boundaries which combine the addressing, fragmentation and routing in one layer has proven successful]; P6: create a layer where there is a need for a different level of abstraction in the handling of data, e.g. morphology, syntax, semantics [fragmentation, routing, and network addressing are all seem quit naturally to be part of network layer semantics as the ARPA Internet example shows]; P9: allow changes of functions or protocols to be made within a layer without affecting other layers [I would think changing the manner of addressing at layer 3 would affect relaying at layer 4]. Even if OSI N-1 segmentation and N+1 relaying could be used in the same way as fragmentation and routing in the ARPA Internet, it takes a lot more apparatus than simply permitting the use of the ISO connectionless "internet" protocol to achieve internetworking. The OSI documents almost concede this point because ISO 7498/DAD 1, ISO/DIS 8473 (Information Processing Systems -- Data Communications -- Protocol for Providing Connectionless-Mode Network Service) actually provide for N- layer segmentation (actually fragmentation) and N-layer routing right in the network layer in addition to the OSI standard N-1 segmentation and N+1 relaying. Providing such functionality directly in the network layer actually seems in greater accordance with OSI design principles, but if ISO is really conceding this point, ISO should go back and redesign the system rather than leaving this mishmash of N-1 segmentation, N segmentation, N routing and N+1 relaying. The current connectionless-mode network service is still insufficient for internetworking because the gateway protocols are not present and the connectionless-mode error PDUs (Protocol Data Units) do not provide the necessary ICMP functionality. The documents also indicate a major confusion between an internetwork gateway, which connects different subnetworks of one catenet (concatenated network), and a simple bridge, which connects several separate physical networks into a single network at the link layer, or an interworking unit, which is a subnet switch connecting two different communications subnets either under different administrative authorities or using different internal protocols.5 Tanenbaum writes the following about the ____________________ 5 This confusion is most distressing from a security standpoint. The November 2 ARPA Internet (Cornell) virus attack shows that one of the major threats to network security is insider attack which is a problem with even the most isolated corporate network. Because many ARPA Internet network authorities were assuming insider good behavior, ARPA Internet network administrators often did not erect security barriers or close trapdoors. Nevertheless, gateways have far more potential than bridges or interworking units to provide reasonable firewalls to hinder and frustrate insider attack. MIT/Project Athena which makes judicious use of gateways and which does not assume insider good behavior was relatively unaffected by the virus. Any document which confuses gateways, bridges and interworking units is encouraging security laxity. ____________________ connectionless-mode network service in Computer Networks, p. 321. In the OSI model, internetworking is done in the network layer. In all honesty, this is not one of the areas in which ISO has devised a model that has met with universal acclaim (network security is another one).6 From looking at the documents, one gets the feeling that internetworking was hastily grafted onto the main structure at the last minute. In particular, the objections from the ARPA Internet community did not carry as much weight as they perhaps should have, inasmuch as DARPA had 10 years experience running an internet with hundreds of interconnected networks, and had a good idea of what worked in practice and what did not. Internetworking, the key concept of modern computer networking, exists within the OSI reference model as a conceptual wart which violates even the OSI principles. If ISO had not tacked internetworking onto the OSI model, ISO was afraid that DARPA and that part of the US computer industry with experience with modern computer networking would have absolutely rejected the OSI reference model as unusable. ____________________ 6 Actually, I find ISO 7498/2 (Security Architecture) to be one of the more reasonable ISO documents. I would disagree that simple encryption is the only form of security which should be performed at the link layer because it seems sensible that if a multilevel secure mini is replaced by a cluster of PCs on a LAN, multilevel security might be desirable at the link layer. Providing multilevel security at the link layer would require more than simple encryption. Still, ISO 7498/2 has the virtue of not pretending to solve completely the network security problem. The document gives instead a framework indentifying fundamental concepts and building blocks for developing a security system in a networked environment. ____________________ IV. "GREATER RICHNESS" VERSUS DEVELOPER INSIGHT In view of this major conceptual flaw which OSI has with respect to internetworking, no one should therefore be surprised that instead of tight technical discussion and reasoning, implementers and designers like me are continually subjected to vague assertions of "greater richness" of the OSI protocols over the ARPA Internet protocols. In ARPA Internet RFCs, real-world practical discussion is common. I would not mind similar developer insight or even hints about the integration of these OSI protocol interpreters into genuine operating systems participating in an OSI interoperable environment. The customers should realize "greater richness" costs a lot of extra money even if a lot of the added features are useless to the customer. "Greater richness" might necessitate the use of a much more powerful processor if "greater richness" forced much more obligatory but purposeless protocol processing overhead. "Greater richness" might also represent a bad or less than optimal partitioning of the problem. A. OSI NETWORK MANAGEMENT AND NETVIEW Netview has so much "greater richness" than the network management protocols and systems under development in the ARPA Internet context that I have real problems with the standardization of Netview into OSI network management as the obligatory user interface and data analysis system. Netview is big, costly, hard to implement, and extremely demanding on the rest of the network management system. As OSI network management apparently subsumes most of the capabilities of Arpanet ICMP (Internet Control Monitoring Protocol) which is a sine qua non for internetworking, I am as a developer rather distressed that full blown OSI network management (possibly including a full implementation of FTAM) might have to run on a poor little laser printer with a dumb ethernet interface card and not much processing power. B. FTAM IS DANGEROUS The "greater richness" of FTAM seems to lie in the ability to transmit single records and in the ability to restart aborted file transfer sessions. Transmission of single records seems fairly useless in the general case since operating systems like Unix and DOS do not base their file systems on records while the records of file systems like those of Primos and VMS have no relationship whatsoever to one another. Including single record or partial file transfer in the remote transfer utility seems is a good example of bad partitioning of the problem. This capability really belongs in a separate network file system. A network file system should be separate from the remote file transfer system because the major issues in security, performance, data encoding translation and locating objects to be transferred are different in major ways for the two systems. The ability to restart aborted file transfers is more dangerous than helpful. If the transfer were aborted in an OSI network, it could have been aborted because one or both of the end hosts died or because some piece of the network died. If the network died, a checkpointed file transfer can probably be restarted. If a host died on the other hand, it may have gradually gone insane and the checkpoints may be useless. The checkpoints could only be guaranteed if end hosts have special self-diagnosing hardware (which is expensive). In the absence of special hardware and ways of determining exactly why a file transfer aborted, the file transfer must be restarted from the beginning. By the way, even with the greater richness of FTAM, it is not clear to me that a file could be transferred by FTAM from IBM PC A to a Prime Series 50 to IBM PC B in such a way that the file on PC A and on PC B could be guaranteed to be identical. C. X.400: E-MAIL AS GOOD AS THE POSTAL SERVICE As currently used and envisioned, the X.400 family message handling also has "greater richness." X.400 seems to include binary-encoded arbitrary message-transmission, simple mail exchange and notification provided by a Submission and Delivery Entity (SDE). In comparison with ARPA SMTP (Simple Mail Transfer Protocol), X.400 is overly complicated with hordes of User Agent Entities (UAEs), Message Transfer Agent Entities (MTAEs) and SDEs scurrying around potentially eating up -- especially during periods of high traffic -- lots of computer cycles on originator, target and intermediate host systems because the source UAE has to transfer mail through the local MTAE and intermediate MTAEs on a hop-by-hop basis to get to the target machine.7 ____________________ 7 I have to admit that if I were implementing X.400, I would probably implement the local UAE and MTAE in one process. The CCITT specification does not strictly forbid this design, but the specification does seem to discourage strongly such a design. I consider it a major flaw with a protocol specification when the simplest design is so strongly counterindicated. It does seem to be obligatory that mail traffic which passes through an Intermediate System (IS) must pass through an MTAE running on that IS. ____________________ The design is particularly obnoxious because X.400 increases the number of ways of getting mail transmission failure by using so many intermediate entities above the transport layer. The SMTP architecture is, by contrast, simple and direct. The user mail program connects to the target system SMTP daemon by a reliable byte stream (like a TCP virtual circuit) and transfers the mail. Hop-by-hop transfers through intermediate systems are possible when needed. One SMTP daemon simply connects to another the same way a user mail program connects to an SMTP daemon. The relatively greater complexity and obscurity of X.400 arises because a major purpose of X.400 seems to be to intermingle intercomputer mail service and telephony services like telex or teletex to fit the computer networking into the PTT (Post, Telegraph & Telephone administration) model of data communications (not an unreasonable goal for a CCITT protocol specification but probably not the best technical or cost-effective design for the typical customer). Mail gateways are apparently supposed to handle document interchange and conversion. Document interchange and conversion is a really hard problem requiring detailed knowledge at least of word processor file formats, operating system architecture, data encoding, and machine architecture. It may be impossible to develop a satisfactory network representation which can handle all possible document content, language and source/target hardware combinations as well as provide interconversion with tradition telephonic data transmission encodings. The cost of development of such a system might be hard to justify, and a customer might have a hard time justifying paying the price a manufacturer would probably have to charge for this product. A network file system or remote file transfer provides a much more reasonable means of document sharing or interchange than tacking an e-mail address into a file with a complicated internal structure, sending this file through the mail system and then removing the addressing information before putting the document through the appropriate document or graphics handler. A NETASCII-based e-mail system corresponds exactly to the obvious mapping of the typical physical letter, which does not usually contain complicated pictorial or tabular data, to an electronic letter and is sufficient for practically all electronic mail traffic. Special hybrid systems can be developed for that extremely tiny fraction of traffic for which NETASCII representations may be insufficient and for which a network file system or FTP may be insufficient. A correct partitioning of the electronic mail should be kept completely separate from telephony services, document interchange and document conversion. ______________________________________________________________ | | | X.400 Mail Connections | | | | | | | | | | | | | | (No Graphics) | | | | | ______________________________________________________________ D. ARPA SMTP: DESIGNING MAIL AND MESSAGING RIGHT The MIT environment at Project Athena, where IBM and DEC are conducting a major experiment in the productization of academic software, provides an instructive example of the differences between e-mail, messaging and notification. The mail system used at MIT is an implementation of the basic SMTP-based ARPA Internet mail system. More than four years ago the ARPA Internet mail system was extremely powerful and world-spanning. It enabled then and still enables electronic mail to reach users on any of well over 100,000 hosts in N. America, Europe, large portions of E. Asia and Israel. The Citicorp network (described in "How one firm created its own global electronic mail network," Data Communications, June 1988, p. 167), while probably sufficient for Citicorp's current needs, connects an insignificant number of CPUs (47), provides no potential for connectivity outside the Citicorp domain of authority and will probably not scale well with respect to routing or configuration as it grows. The MIT environment is complex and purposely (apparently in the strategies of DEC and IBM) anticipates the sort of environment which should become typical within the business world within the next few years. MIT is an authoritative domain within the ARPA Internet. The gateways out of the MIT domain communicate with gateways in other domains via the Exterior Gateway Protocol (EGP). Internally, currently used internal gateway protocols are GGP, RIP and HELLO. The MIT domain is composed of a multitude of Ethernet and other types of local area networks connected by a fiber-optic backbone physically and by gateway machines logically. This use of gateways provides firewalls between the different physical networks so that little sins (temporary network meltdowns caused by Chernobyl packets) do not become big sins propagating themselves throughout the network. The gatewayed architecture of the MIT network also permits a necessary traffic engineering by putting file system, paging and boot servers on the same physical network with their most likely clients so that this sort of traffic need not be propagate throughout the complete MIT domain. Difficult to reach locations achieve connectivity by means of non-switched telephone links. Since MIT has its own 5ESS, these links may be converted to ISDN at some point. While there are some minis and mainframes in the network, the vast majority of hosts within the MIT network are personal workstations with high resolution graphics displays of the Vaxstation and RT/PC type and personal computers of the IBM PC, PC/XT and PC/AT type. A few Apollos, Suns, Sonys and various workstations of the 80386 type as well as Lisp Machines and PCs from other manufacturers like Apple are also on the air. Most of the workstations are public. When a user logs in to such a workstation, after appropriate Kerberos (MIT security system) authentication, he has full access to his own network files and directory as well as access to those resources within the network which he has the right to use. To assist the administration of the MIT domain within the ARPA Internet, several network processes might be continually sending (possibly non-ASCII) event messages to a network management server which might every few hours perform some data analysis on received messages and then format a summary mail message to send to a network administrator. This mail message would be placed in that network administrator's mailbox by his mail home's SMTP daemon which then might check whether this network administrator is reachable somewhere within the local domain (maybe on a PC with a network interface which was recently turned on and then was dynamically assigned an IP address by a local authoritative dynamic IP address server after appropriate authentication). If this administrator is available, the SMTP daemon might notify him via the notification service (maybe by popping up a window on the administrator's display) that he has received mail which he could read from his remote location via a post office protocol. I have seen the above system being developed on top of the basic "static" TCP/IP protocol suite by researchers at MIT, DEC and IBM over the last 4 years. X.400 contains a lot this MIT network functionality mishmashed together but I as a customer or designer prefer the much more modular MIT mail system. It is an extensible, dynamically configurable TCP/IP-based architecture from which a customer could chose those pieces of the system which he needs. The MIT system requires relatively little static configuration. Yet by properly choosing the system pieces, coding an appropriate filter program and setting up a tiny amount of appropriate configuration data, a customer could even set up a portal to send e-mail to a fax machine. In comparison, X.400 requires complicated directory services and an immense amount of static configuration about the end user and end user machine to compensate for the internetworking-deficient or internetworking-incompatible addressing scheme. The need for such a level of static configuration is unfortunate for system users because in the real world a PC or workstation might easily be moved from one LAN to another or might be easily replaced by a workstation or PC of another type. An MIT-style mail system could also be much cheaper to develop and consequently could be much less costly to purchase than an X.400 mail system simply because it represents a much better partitioning of the problem. One or two engineers produced each module of the MIT mail system in approximately 6 months. Because of complexity and obscurity, the development of X.400 products (I saw an example at Prime) is measured in staff years. The executive who chooses X.400 will cost his firm an immense amount of money which will look utterly wasted when his firm joins with another firm in some venture and the top executives of both firms try to exchange mail via their X.400 mail systems. Simple mail exchange between such systems would likely be very hard to impossible because the different corporations could easily have made permissible but incompatible choices in their initial system set-up. At the very last complete reconfiguration of both systems could be necessary. Had the firms chosen an ARPA Internet mail system like the MIT system, once both firms had ARPA Internet connectivity or set up a domain-to-domain gateway, mail would simply work. ______________________________________________________________ | | | SMTP Mail Connections | | | | | | | | | | | | | | (No Graphics) | | | | | ______________________________________________________________ V. IS THE TCP/IP PROTOCOL SUITE "STATIC?" Because of the mail system development in progress at MIT, DEC and IBM, the X development which I and others have done and which is still continuing, SUN NFS (Network File System) development, IBM AFS (Andrew File System) development, Xenix-Net development, Kerberos development, and the other plethora of protocol systems being developed within the ARPA Internet context (including the VMTP transaction processing system and commercial distributed database systems like network Ingress), I am at the very least puzzled by Mr. Stallings' assertion that "[it] is the military standards that appear on procurement specifications and that have driven the development of interoperable commercially available TCP/IP products." ______________________________________________________________ | | | Partitioning the Problem | | | |The X window system is an example of a clearly and well| |partitioned system. In windowing, the first piece of the| |problem is virtualizing the high-resolution raster graphics| |device. Individual applications do not want or need to know| |about the details of the hardware. Thus, to provide| |hardware independence, applications should only deal with| |virtual high-resolution raster-graphics devices and should| |only know about its own virtual high resolution raster-| |graphics devices (windows). The next piece of the problem| |is to translate between virtual high-resolution raster| |graphics devices and the physical high-resolution raster| |graphics device (display). The final part of the problem| |lies in managing the windows on the display. This problem,| |with a little consideration clearly differentiates itself| |from translating between virtual and physical high-| |resolution raster-graphics devices. | | | | |In the X window system, communication between the| |application and its windows is handled by the X library and| |those libraries built on top of the basic X library.| |Virtual to physical and physical to virtual translation is| |handled by the X server. X display management is handled by| |the X window manager. | | | | | |After partitioning the problem, careful consideration of| |display management leads to the conclusion that if all| |windows on a display are treated as "children" of a single| |"root" window, all of which "belong" in some sense to the| |window manager, then the X window manager itself becomes an| |ordinary application which talks to the X server via the X| |library. As a consequence, developers can easily implement| |different display management strategies as ordinary| |applications without having to "hack" the operating system.| |The server itself may be partitioned (under operating| |systems which support the concept) into a privileged portion| |which directly accesses the display hardware and a non-| |privileged portion which requests services from the| |privileged part of the server. Under Unix, the privileged| |part of the server goes into the display, mouse and keyboard| |drivers while the non-privileged part becomes an ordinary| |application. In common parlance, X server usually refers to| |the non-privileged part of the X server which is implemented| |as an ordinary application. | | | |The last step in realizing the X window system is choosing| |the communications mechanism between the X server and| |ordinary applications or the display manager. Because the| |problem was nicely partitioned, the communications problem| |is completely extrinsic to the windowing problem as lives as| |an easily replaceable interface module. The initial choice| |at MIT was to use TCP/IP virtual circuits, which provided| |immediate network transparency, but in fact because X only| |requires sequenced reliable byte-streams so that DECNET VCs| |or shared-memory communications mechanisms can easily| |replace TCP/IP virtual circuits according to the| |requirements of the target environment. Systems built on| |well-partitioned approaches to solving problems often show| |such flexibility because of modularity of the approach and| |because a successful partitioning of the problem will often| |in its solution increase the understanding of the original| |problem that developers can perceive greater tractability| |and simplicity in the original and related problems than| |they might have originally seen. | _____________________________________________________________| It seems somewhat propagandistic to label the TCP/IP protocol suite static and military. New RFCs are continually being generated as Paul Strauss has pointed out in his September article. Such new protocols only become military standards slowly because the military standardization of new protocols and systems is a long tedious political process which once completed may require expensive conformance and verification procedures. After all, neither the obligatory ICMP nor the immensely useful UDP (User Datagram Protocol) have associated military standards. Often, after reviewing those products generated by market forces, the US military specifies and acquires products which go beyond existing military standards. By the way, hierarchical domain name servers and X are used on MILNET. VI. ENTERPRISE NETWORKING AND SOPHISTICATED APPLICATIONS: SELLING INTERCOMPUTER NETWORKING The military are not the only users "more interested in sophisticated applications than in a slightly enhanced version of Kermit." The whole DEC enterprise networking strategy is postulated on this observation. Stallings ignored my reference to network file systems as a sophisticated networking application. Yet, in several consulting jobs, I have seen brokers and investment bankers make extensive use of network file systems. I also believe network transparent graphics will be popular in the business world. At Saloman Brothers both IBM PCs and SUN workstations are extensively used. With X, it is possible for a PC user to run a SUN application remotely which uses the PC as the output device. This capability seems highly desirable in the Saloman Brothers environment. Unfortunately "OSI is unlikely ever to provide for [such] resource sharing because it is industry-driven." Wayne Rash Jr., a member of the professional staff of American Management Systems, Inc. (Arlington, Virginia) who acts as a US federal government microcomputer consultant, writes the following in "Is More Always Better," Byte, September 1988, p. 131. You've probably seen the AT&T television ads about this trend [toward downsizing and the development of LAN-based resource-sharing systems]. They feature two executives, one of whom is equipping his office with stand-alone microcomputers. He's being intimidated by another executive, who tells him in a very nasty scene, "Stop blowing your budget" on personal computers and hook all your users to a central system. This is one view of workgroup computing, although AT&T has the perverse idea that the intimidator is the forward thinker in the scene. AT&T and to an even greater extent the similarly inclined European PTTs have major input into OSI specification. VII. BIG AND SMALL PLAYERS CONSTRAIN OSI The inclinations of AT&T and the PTTs are not the only constraints under which the OSI reference model was developed. A proprietary computer networking system, sold to a customer, becomes a cow which the manufacturer can milk for years. Complete and effective official standards make it difficult for a company to lock a customer into a proprietary system. A customer could shop for the cheapest standard system, or could chose the offering of the manufacturer considered most reliable. It is proverbial that no MIS executive gets fired for choosing IBM. Small players have genuine reason to fear that a big player like Unisys, which no longer has a major proprietary computer networking installed base8, or AT&T, which never had a major proprietary computer networking installed base9, might try to establish themselves in the minds of customers as the ultimate authority for the supply of true OSI connectivity. Thus, small players fear that a complete and effective official standard might only benefit the big players. Players like AT&T or Unisys fear IBM might hi-jack the standard. IBM would prefer to preserve its own proprietary base and avoid competing with the little guys on a cost/performance basis in what could turn into a commodity marker. No such considerations were operative in the development of the ARPA Internet suite of protocols. DARPA had a specific need for intercomputer networking, was willing to pay top dollar to get the top experts in the intercomputer networking field to design the system right and was less concerned by issues of competition (except perhaps for turf battles within the U.S. government). By contrast, almost all players who have input into the ISO standardization process have had reasons and have apparently worked hard to limit the effectiveness of OSI systems. With all the limitations, which have been incorporated into the OSI design and suite of protocols, the small players have no reason to fear being overwhelmed by big players like Unisys or AT&T. The big players have the dilemma of either being non-standard or of providing an ineffective, incomplete but genuine international standards. Small vendors have lots of room to offer enhanced versions perhaps drawing from more sophisticated internetworking concepts. In any case, most small vendors, as well as DEC and IBM, are hedging their bets by offering both OSI and TCP/IP based products. IBM seems well positioned with on-going projects at the University of Michigan, CMU, MIT, Brown and Stanford and with IBM's creditability in the business world to set the standard for the business use of TCP/IP style ____________________ 8 BNA and DCA seem hardly to count even to the Unisys management. 9 Connecting computer systems to the telephone network is not computer networking in any real sense. ____________________ networking. By contrast, no major manufacturer really seems to want to build OSI products, and with the current state of OSI, there is really no reason to buy OSI products. VIII. MAP: FOLLOWING THE OSI MODEL MAP shows perfectly the result of following the OSI model to produce a computer networking system. GM analysts sold MAP to GM's top management on the basis of the predicted cost savings. Since GM engineers designed, sponsored and gave birth to MAP, I am not surprised that an internal GM study has found MAP products less expensive than non-MAP compliant products. If the internal study found anything else, heads would have to roll. Yet, as far as I know, neither IBM nor DEC have bought into the concept although both companies would probably supply MAP products for sufficient profit. Ungermann-Bass and other similar vendors have also announced a disinclination to produce IEEE 802.4 based products. Allen-Bradley has chosen DECNET in preference to a MAP-based manufacturing and materials handling system. This defection of major manufacturers, vendors and customers from the MAP market has to limit the amount of MAP products available for customers to purchase. Nowadays, GM can purchase equipment for its manufacturing floor from a limited selection of products, which are the computer networking equivalent of bows and arrows, whereas in the past GM was stuck with rocks and knives. Bows and arrows might be sufficient for the current GM applications; however, if my firm had designed MAP, GM would have the networking equivalent of nuclear weapons, for the MAP network would have been built around an internet with a genuine multimedium gatewayed easily modifiable environment so that in those locations where token-bus noise resistance is insufficient and where higher bandwidths might be needed, fiber media could be used. With the imminent deluge of fiber-based products, MAP looks excessively limited. (Actually, the MAP standards committees have shown some belated awareness that fiber might be useful in factories.) IX. EXTENDING OSI VIA PROTOCOL CONVERTERS: QUO VADIT? Interestingly enough, even when OSI systems try to overcome OSI limitations via protocol conversion to provide access to some of the sophisticated resource sharing to which ARPA Internet users have long been accustomed, the service is specified in such a way as to place major limitations on performance of more sophisticated applications. Just like IBM and other system manufacturers, I have no problems with providing to the customer at sufficient profit exactly those products which the customer specifies. Yet, if contracted for advice on a system like the NBS TCP/IP-to-OSI protocol converter IS (Intermediate System), described in "Getting there from here," Data Communications, August 1988, I might point out that such a system could easily double packet traffic on a single LAN, decrease network availability and reliability, prevent alternate routing, and harm throughput by creating a bottleneck at the IS which must perform both TCP/IP and OSI protocol termination. X. CONCLUSION Official standardization simply by itself does not make a proposal good. Good standards generally were already good before they became official standards. The IEEE and other standards bodies generate lots of standards for systems which quickly pass into oblivion. OSI was generated de novo, apparently with a conscious decision to ignore the already functioning ARPA Internet example. Unless a major rethinking of OSI (like redesigning OSI on the solid foundation of the internetworking concept) takes place in the near future, I must conclude that the ARPA Internet suite of protocols will be around for a long time and that users of OSI will be immensely disappointed by the cost, performance, flexibility and manageability of their networks. I. Introduction 1 II. The Debate 2 III. Internetworking: The Key System Level Start Point 4 IV. "Greater Richness" Versus Developer Insight 14 A. OSI Network Management and Netview 14 B. FTAM is Dangerous 14 C. X.400: E-Mail as Good as the Postal Service 15 D. ARPA SMTP: Designing Mail and Messaging Right 18 V. Is the TCP/IP Protocol Suite "Static?" 22 VI. Enterprise Networking and Sophisticated Applications: Selling Intercomputer Networking 24 VII. Big and Small Players Constrain OSI 24 VIII. MAP: Following the OSI Model 26 IX. Extending OSI Via Protocol Converters: Quo vadit? 26 X. Conclusion 27