|
|
||
| THINK Home | Digital Archive | Search | Feedback |
|
THINK ARPANET |
This paper explores the development and design issues relating to the conception and implementation of an effective and useful Telnet protocol, during the first years of it's existence within the ARPANET. The paper assumes a general understanding of ARPANET protocol layers but also provides a basic overview for the reader. Assistance with terminology is provided throughout the document by following the links. Much of the specific Telnet terminology can be found in RFC 854.
Telnet is defined by the IEEE as, "the remote terminal access protocol of the Internet Protocol Suite." [The DARPA Internet Protocol Suite] Today, we have two such protocols: rlogin and Telnet, where both provide a remote login to a server to run programs on that server. Yet rlogin and Telnet are not the same. Rlogin assumes both sides of the connection are UNIX hosts and thus allows for only homogenous interaction. Telnet works across heterogeneous systems, where no host type assumptions are made. Today's Telnet provides option negotiation between the client and server, only adding capabilities if both sides support them. This provides a bare bones implementation as a standard default Telnet, and a feature incremented system for systems that support more advanced features. The Telnet protocol is full duplex, and is essentially based on three general ideas: that of a Network Virtual Terminal (NVT), negotiated options and the symmetry of processes. Telnet operates as follows:
The ideas defined as: the Network Virtual Terminal (NVT), negotiated options and the symmetry of processes, form a decisive blueprint for the practical implementation of the Telnet protocol. This is indicative of a truly significant effort, by a group of incredibly talented networking pioneers between the late 1960's and mid-1970's. Telnet was the very first service implemented in the DARPA network system. In the earliest design, the goal was to allow a user with an interactive terminal attached to one time-sharing computer to use another computer as if the terminal were connected. Telnet was developed to provide considerable computing power at both ends of a host-to-host connection. [Internet Applications Using the DARPA Internet Suite] A primary goal in the development of this paper is to demonstrate that the evolution of today's useful, easy-to-use and functional Telnet protocol was essentially brought about through cooperation, persistence and resolve. Telnet's Early Design and Development In April of 1969, RFC 1 written by Steve Crocker discussed the preliminary requirements for the host-host software. He documents the underlying goal of "finding a host level protocol capable of facilitating a connection between two hosts, where the remote host acts as if the user were sitting directly at that terminal." [RFC 1] The RFC outlines some basic requirements by documenting the desire for, "the use of a TTY-like connection and a file-like connection in order to facilitate a complete connection between two hosts and the need for error checking." Thus began the search for a sequence of protocols, and more specifically, the applications protocols that would evolve into Telnet and FTP. Bolt, Baranek and Newman (BBN), a small acoustical consulting firm based in Cambridge, MA had won the contract to manufacture the first subnet routers (Interface Message Processors). BBN had assigned the responsibility of enabling the ARPA hosts to communicate with a remote host over the network to the host site teams. This collective, comprising mainly of graduate students under the supervision of Lawrence Roberts of Bolt, Baranek and Newman, was formally known as the Network Working Group (NWG), and they were faced with the daunting and heavily pressured task of designing and implementing specific protocols to provide user functionality to the newly forming ARPANET. RFC 15 written by C. Stephen Carr of Utah in September 1969 reads, "In addition to user program access, a convenient means for direct network access from the terminal is desirable. A sub-system called "Telnet" is proposed which is a shell program around the network system primitives, allowing a teletype or similar terminal at a remote host to function as a teletype at the serving host." When the ARPANET finally became a reality on October 1st 1969, Bill Duval, a Stanford Researcher, had written a very specific interim solution for the SDS 940 to display the most recent data sent to it by a remote host to which it was connected. Researchers at UCLA using a Sigma 7 machine and by directly dialing into the SRI host using a modem and a teletype, had by this time familiarized themselves with the SRI's time sharing system to prepare themselves for the first demonstrated login session. Summarizing this initial development process in RFC 1000, Reynolds and Postel wrote, "Lawrence Roberts and Barry Wessler came by for a visit on November 21, and we actually managed to demonstrate a Telnet-like connection to SRI." By December, the network had expanded to four IMPs and these were connected between the Stanford Research Institute host (SDS 940), UCLA host (Sigma 7), the University of Santa Barbara host (IBM 360/75) and the University of Utah host (DEC PDP-10). A rudimentary implementation of the 'Telecommunications Network' protocol, essentially the first network application, was demonstrated on the four-IMP network installed in December 1969. The NWG, feeling the strain to show something to ARPA, demonstrated a patched protocol that allowed for remote logins. According to Reynolds and Postel in RFC 1000, "only asymmetric, user-server relationships were supported." This indicates that the functions and mechanisms for controlling the network connection were used in only one direction between the two hosts. However, Telnet was a way to use the network, and not a lower level building block. Telnet allowed one terminal to reach multiple computers, but a remote login program by itself did not solve the problem of letting two computers work together. This patched version of Telnet had been implemented even before an official host-host protocol had been defined, and as such took on much of the responsibilities that would be assumed by the forthcoming NCP. Patching Telnet using the NCP (1970) It was a year later, in the summer of 1970, that a host-to-host communications protocol known as the Network Control Protocol (NCP) was completed. The NCP encapsulated the ideals Steve Crocker had essentially foreseen and documented in the first RFC, and those ideals Lawrence Roberts of BBN had envisioned and implemented through the Network Working Group. NCP originally meant the program within the operating system that managed connections. The layering approach to protocol design, put forth by Roberts, foresaw the separation of the user level protocols from the host layer, so as to separate applications from the operating system functions as much as possible. The Spring Joint Computer Conference in 1970 documented the way connectivity between Telnet processes interacting with the NCP were established via system calls. The NCP to NCP processes were connected across a link interacting via control commands, and as such they were able to perform their primary function to establish, break and switch connections and control flow between hosts. An NCP connection was simplex so that two connections were needed if two processes were to converse in two directions. One such command initiated the connection to a process listening for login requests, termed a 'logger'. This 'logger' was a set of processes in the serving system, listening on socket zero, that responded to the ICP and performed the initial interactions between user and server. (See the ICP protocol paper for a more in depth discussion of the socket switching process)
The first written proposal of the Telnet protocol was published in RFC 97, entitled "A First Cut at a Proposed Telnet Protocol" and was written by J.T. Melvin and R.W. Watson of SRI. This RFC was released on February 15, 1971, almost eighteen months after the first preliminary network connections had been established. Melvin and Watson stated that the need to set specifications would allow online access to the Network Information Center. The idea was that by focusing on a connection to the network in the form of the NIC or NLS as it was also referred, "may force us toward a more standard way of handling terminals and their character streams in our monitors and our terminal control hardware." [RFC 97] In defining basic assumptions about the functionality of making a terminal appear over a network, the first was that a user should be able to generate all the character codes that the serving system could generate. As the NIC was capable of 128 ASCII codes, this was set as the default requirement. There was a need for the user to be able to escape back to the local system from a server process running over the network and a call to standardize the interaction of systems using character-at-a-time systems and line-at-a-time systems. As the NIC used character-at-a-time, it is interesting to note that today's standard is indeed, character-at-a-time. RFC 97 states, "what characters are echoed for what keys struck is of no concern to the serving site." The serving site would assume that the user site, until "explicitly commanded otherwise" would perform echoing. Also, there needed to be an escape mechanism for the user to be able to switch between character mode and control mode, effectively breaking out of the program on the serving host, and back into control of the actual remote process being handled on the local system. There was a call to define format control characters: HT (horizontal tab), VT (vertical tab), FF (form feed), LF (line feed) and CR carriage (return). The carriage return character would prove to be a particular difficulty over heterogeneous systems, because some systems echoed nothing, while others a CR or a CRLF, and some others would echo CR, CRLF or EOL (end of line). It was also noted that for character or line at a time systems, the Telnet process might need to recognize a character to define the end of stream, to signify the end of the transmission of characters entirely. It was not until April 3rd, 1972, that Telnet was specifically detailed as to its actual implementation in an RFC. This was RFC 318, written by Jon Postel of UCLA under pressure by the NWG to produce a document that, "clearly and succinctly specified the official Telnet protocol". Even at the time RFC 318 was written, Postel was aware that the specifics of the protocol laid out in the RFC were unclear and unspecific. Postel notes to the reader that the RFC, "presents my understanding of the Telnet protocol", and that, "there are many who have serious questions about this protocol."
Standardization of the Protocol The issue of standardization revolved around the formalization of the Telnet protocol. Almost as soon as RFC 318 was released, a number of issues were addressed, and can be seen in RFCs 328, 340 and 393, between April and October 1972. The protocol specified in RFC 318 had mentioned two implementations of Telnet. The first was defined as a minimum version and the second, a standard version. Each Telnet implementation had to support the minimum implementation, but it had been devised that Telnet could add features up to level a specified in a standard version. This resulted in a number of different implementations of Telnet being released, where an incompatibility of features existed across them. This effectively meant that the only stable Telnet protocol was that specified for the initial implementation, and the standard with the envisioned upgraded features was, to a great extent, useless. A solution was first suggested and submitted by Jon Postel in RFC 328, which suggested that only one implementation be kept and it be the original basic standard. The protocol was also scrutinized, and its specifications defined more clearly, in several published conference papers, along with a plethora of suggested revisions, such as the suggestion to remove HIDE YOUR DATA and remove the provision for multiple character sets. Primarily however, the issues under discussion between 1972 and 1973 addressed three areas of concern: the standardization of the protocol, its asymmetry and an inadequate control structure. Asymmetry and an Inadequate Control Structure Bernie Cosell and Dave Walden at BBN in January 1973 released RFC 435. They outlined a solution for resolving the issue of asymmetry within the Telnet process. For example, to help solve the security problem of echoed passwords, a HIDE YOUR INPUT command had been defined, which instructed a system not to display characters. To turn it off, the ECHO command was used, and this actually turned echoing on, even if this was not the desired action. Moreover, some systems would send a character at a time over the connection, whereas others would buffer an entire line before sending it. In the original Telnet protocol, it was the end of line (CR followed by LF) that would signify when to send information in a line-at-a-time system. This caused a problem when a line-at-a-time mode was being used, since the user needed a reply from the server before the end of the line. Furthermore, even though the syntax of ECHO and NOECHO was symmetrical, their semantics were not. ECHO meant both ends could echo to each other, whereas NOECHO meant the other would not echo. Thus, there was also a problem with the control structure of the protocol. The realization was that a different control structure might solve both the echoing and the character parsing problems. The focus became three main principles: default implementation, negotiated options and symmetry.
The Tenex group, and in particular, Thomas, Burchfiel and Tomlinson, proposed that a new syntax be introduced, where there would be four prefixes available to each command for negotiating NVT ASCII. These would be sufficient to ensure completely symmetric echoing. Options are negotiated via an exchange of commands between the Telnet modules. The commands would be DO, DONT, WILL and WONT. Since options would be applied to each direction of data flow separately, the use of the option for each direction would be negotiated separately. These would determine the status of the command, and in this manner the systems that were communicating would negotiate an agreeable status. The commands have the following interpretations:
The adoption of symmetry meant that the previously defined DATA MARK / INS sequence which was used for interrupting a process, could no longer function between user and server. As this command essentially resulted in the flushing of the buffers from server to user, it was suggested that a CLEAR YOU BUFFER option be added. Following these specifications, a meeting hosted at UCLA on March 5th, 1973 formulated the new specification for the Telnet protocol. All the major players of the NWG were in attendance. The group proposed two key dates for, 'phasing in' the new Telnet protocol. Between January 1st, 1973 and January 1st, 1974, sites would need to, "gradually implement and test the interpreter for the new commands." Sites would be able to use the new codes from the earlier date without experiencing errors, while the latter date signified when the old code for interpreting the old commands should be discarded. The new Telnet would be implemented through the TCP specification on January 1st, 1974, closely followed by the FTP switch in February of the same year. Jon Postel, commenting on the seamless rollout for integrating the new standard for networking, wrote in ARPANET news in November 1973, "the user sitting at his terminal should not notice the changeover, and will not have to do anything different." [Issue 9 page 26] This meeting also forwarded additional negotiable options that are still in use today. [RFC 495] The final edition of the Telnet protocol took ten more years to fully develop, culminating in Internet Standard 8, in 1983. This was three years after the final TCP specification begun in 1973, was ratified in 1980. The complete Telnet Protocol Specification based on the Transmission Control Protocol, and formally constructed upon the three principles: the Network Virtual Terminal, the negotiated options and the symmetric view of terminals and processes, are laid out in RFC 854. Written in May 1983, this document specifies the standard for the Internet community. Telnet's remarkable stability deserves close study. Simplicity alone is held up as a classic cause: the NVT is an artful balance of features that can span the range from half-duplex teletypes to cell phone-PCs. Option negotiation was a farsighted addition at the time it was devised, although it did not become a hallmark of IETF protocol design until the late Eighties. Many other systems had hooks for new headers, new verbs, and so on, but few planned ahead with administrative procedures for managing the option space. As defined by RFC 97 in February 1971, the Network Information Center's NLS used character-at-a-time as the mode for sending characters across the Telnet connection, and was capable of 128 ASCII codes. It is interesting to note that today's standard is indeed, character-at-a-time and ASCII, by default. Steve Crocker has stated that, "As we gained experience with these initial protocols, the Host-Host protocol was seen as needing important changes, but the Telnet and FTP protocols remained relatively stable with only modest embellishments and changes over three decades." This comment would support the primary goal of this paper in that the evolution of today's useful, easy-to-use and functional Telnet protocol was essentially brought about through cooperation, persistence and resolve. With hindsight, it seems apparent that Telnet actually progressed and evolved steadily by building upon the strengths of the last implementation. Crocker's statement is therefore indicative of a learning process and protocol development that evolved gracefully into the strong, user-friendly protocol utilized by computer scientists today. Bibliography
"Official Initial Connection Protocol"; J. Postel, ARPA Network Working Group Document#2, NIC#7101, June 1971
The DARPA Internet Protocol Suite"; B.Leiner, J.Postel, R.Cole and D.Mills - IEEE Infocom 1985
|
|
|
Written by the THINK Protocols team,
CS Dept,
UT Austin
Please direct comments to Chris Edmondson-Yurkanan. |
(Using
illustrations, this document descibes how the function oriented protocols
work in relation to other protocols) 