RFC1 を読む
RFC1 は今から 57 年前の 1967 年 4 月 7 日に発表された、ARPA Network（以下 ARPANET） におけるホスト間の通信プロトコルの叩き台としてまとめられた文書。
ARPANET の歴史を題材にしたノンフィクション "Where Wizards Stay Up Late" で RFC1 に興味を持ったので読んでみた。
英語としては特に難しい表現はないのだが、技術的な課題が 57 年前当時の状況に基づいてるので理解が難しい部分が多かった。内容については正確性に欠ける部分が多いかもしれない。
Introductions
The software for the ARPA Network exists partly in the IMPs and partly in the respective HOSTs. BB&N has specified the software of the IMPs and it is the responsibility of the HOST groups to agree on HOST software.
ARPANET は国防総省の研究機関 ARPA: Advanced Research Projects Agency が主導して構築されたコンピュータネットワークで、現在のインターネットの技術的な起源とされている。
ARPANET では各ホストが「IMP（Interface Message Processor）」と呼ばれるコンピュータで接続されていた。IMP はホスト間の通信を制御するためのコンピュータで、ルーティングやエラー処理、データの送受信等に責任を負っていた。
IMP の実装は BB&N（Bolt Baranek and Newman）というコンサルティング会社が担っていたが、彼らの主な仕事は IMP 間の通信制御であり、各ホスト間で実際に通信するためのプロトコルは事前に定められていなかった。
During the summer of 1968, representatives from the initial four sites met several times to discuss the HOST software and initial experiments on the network. There emerged from these meetings a working group of three, Steve Carr from Utah, Jeff Rulifson from SRI, and Steve Crocker of UCLA, who met during the fall and winter. The most recent meeting was in the last week of March in Utah. Also present was Bill Duvall of SRI who has recently started working with Jeff Rulifson.
Somewhat independently, Gerard DeLoche of UCLA has been working on the HOST-IMP interface.
ARPANET 開始時のホストは UCLA, UCSB, SRI（Stanford Research Institute）, University of Utah の 4 箇所だった。BB&N の IMP 実装と並行して各ホストの代表者が集まり、ホスト間の通信について議論していた。
I present here some of the tentative agreements reached and some of the open questions encountered. Very little of what is here is firm and reactions are expected.
この文書に RFC: Request for Comments という名前が付けられたのは文字通りこれを叩き台として議論するために作られたからで、当時 UCLA の大学院生だった提案者 Steve Crocker はどこかにいる「公式のプロトコルデザイナー」に遠慮してこのような名前をつけたらしい。実際にはそのような役割を持った人間は存在しなかった。
I. A Summary of the IMP Software
Messages
ホスト間でやり取りされるメッセージの仕様について。
Information is transmitted from HOST to HOST in bundles called messages. A message is any stream of not more than 8080 bits, together with its header. The header is 16 bits and contains the following information:
Destination 5 bits
Link 8 bits
Trace 1 bit
Spare 2 bits
情報は「Message」と呼ばれる塊でホストからホストに送られる。Message のヘッダーは 16 bit で Destination, Link, Trace, Spare という 4 つのフィールドで構成される。全体のサイズはヘッダー込みで 8080 bit 以下とされている。
当時はこれで十分と考えられていたのだろう。
The destination is the numerical code for the HOST to which the message should be sent. The trace bit signals the IMPs to record status information about the message and send the information back to the NMC (Network Measurement Center, i.e., UCLA). The spare bits are unused.
Destination は宛先となるホストの番号で、これが 5 bit ということはホストは 2^5 = 32 箇所までしか存在できない。当初はホストが 4 箇所しかなかったとはいえ、爆発的にネットワークが拡大するとは考えられていなかったようだ。
Trace の 1 bit は UCLA にある NMC: Network Measurement Center に送るための情報と書かれている。これは恐らく、ARPANET において最初の IMP が UCLA に置かれていたのでネットワークを運用監視する機能が UCLA にあったためと考えられる。
Spare は使われない。Link は後述。
Links
The link field is a special device used by the IMPs to limit certain kinds of congestion. They function as follows. Between every pair of HOSTs there are 32 logical full-duplex connections over which messages may be passed in either direction. The IMPs place the restriction on these links that no HOST can send two successive messages over the same link before the IMP at the destination has sent back a special message called an RFNM (Request for Next Message). This arrangement limits the congestion one HOST can cause another if the sending HOST is attempting to send too much over one link. We note, however, that since the IMP at the destination does not have enough capacity to handle all 32 links simultaneously, the links serve their purpose only if the overload is coming from one or two links. It is necessary for the HOSTs to cooperate in this respect.
Link フィールドの 8 bit は IMP による輻輳制御に使われる。
ARPANET において各 IMP の役割はホストから送られた Message をパケットとして分割し目的地の IMP まで転送することである。しかし、パケットを分割して目的地に送り目的地の IMP で組み立てる場合、ある特定の IMP への送信が集中すると（IMP のハードウェア上のバッファが不足することで）輻輳によりパケットの受付ができなくなってしまうという問題があった。
解決策としては、パケットを送信する前にバッファの空き状況を確認してから送信するという仕組みとなった。目的地の IMP は RFNM: Request for Next Message という特別なメッセージを送り返すので、送信元の IMP はそれを確認してメッセージを送る。各ホストの IMP は相互に 32 の論理的なリンクを持っており、どの IMP も RFNM を受け取るまで同じリンク上で 2 つの連続したメッセージを送信できないという制限がある。
少数のリンクから大量のメッセージが送られている場合はこの制限により輻輳を防ぐことができるが、全てのリンクから満遍なくメッセージが送られている場合は目的地の IMP でバッファが尽きる可能性があるため、IMP 間の通信だけではこの問題を解決できずホスト側が協力する必要がある。
Link フィールドはどのリンクを使ってメッセージを送るかを指定するために使われる。
The links have the following primitive characteristics. They are always functioning and there are always 32 of them.
By "always functioning," we mean that the IMPs are always prepared to transmit another message over them. No notion of beginning or ending a conversation is contained in the IMP software. It is thus not possible to query an IMP about the state of a link (although it might be possible to query an IMP about the recent history of a link -- quite a different matter!).
The other primitive characteristic of the links is that there are always 32 of them, whether they are in use or not. This means that each IMP must maintain 18 tables, each with 32 entries, regardless of the actual traffic.
The objections to the link structure notwithstanding, the links are easily programmed within the IMPs and are probably a better alternative to more complex arrangements just because of their simplicity.
IMP のソフトウェアにはメッセージの開始や終了という概念はなく、いつでもデータを伝送する準備ができている。リンクが使える状態かどうかをリアルタイムで IMP に問い合わせることはできない（最近の履歴を問い合わせることはできるかもしれないが、これは別の問題）。
IMP Transmission and Error Checking
After receiving a message from a HOST, an IMP partitions the message into one or more packets. Packets are not more than 1010 bits long and are the unit of data transmission from IMP to IMP. A 24 bit cyclic checksum is computed by the transmission hardware and is appended to an outgoing packet. The checksum is recomputed by the receiving hardware and is checked against the transmitted checksum. Packets are reassembled into messages at the destination IMP.
IMP はホストからのメッセージ 1 つ以上のパケットに分割して目的地の IMP に送信する。一つのパケットは 1,010 bit 以下で、メッセージの合計サイズは 8,080 bit 以下だから最大で 8 つに分割される。
パケットには 24 bit のチェックサムが付与される。チェックサムは目的地の IMP で再計算されて照合され、パケットは IMP でメッセージとして再組立される。
Open Questions on the IMP Software
- An 8 bit field is provided for link specification, but only 32 links are provided, why?
- The HOST is supposed to be able to send messages to its IMP. How does it do this?
- Can a HOST, as opposed to its IMP, control RFNMs?
- Will the IMPs perform code conversion? How is it to be controlled?
- リンク指定のために 8 ビットのフィールドが用意されていますが、32 リンクしか用意されていない。なぜか？
- HOST は IMP にメッセージを送ることができるはずです。どのようにするか？
- IMP とは対照的に、ホストは RFNM を制御できるか？
- IMP はコード変換を行うのか？どのように制御するのか？
質問を眺めると「こんなことも決まってなかったのか？」と思うが、ARPANET のプロジェクトが実際に開始されたのはこの年の年始で稼働が始まったのは年末なので、提案者らが議論していた頃（1969 年 3 月頃？）には未確定の事項も多かったのだろう。
II. Some Requirements Upon the Host-to-Host Software
Simple Use
As with any new facility, there will be a period of very light usage until the community of users experiments with the network and begins to depend upon it. One of our goals must be to stimulate the immediate and easy use by a wide class of users. With this goal, it seems natural to provide the ability to use any remote HOST as if it had been dialed up from a TTY (teletype) terminal. Additionally, we would like some ability to transmit a file in a somewhat different manner perhaps than simulating a teletype.
手元の端末から接続するかのように遠くにあるリモートのホストを利用できるような機能が欲しいという話。
Deep Use
One of the inherent problems in the network is the fact that all responses from a remote HOST will require on the order of a half-second or so, no matter how simple. For teletype use, we could shift to a half-duplex local-echo arrangement, but this would destroy some of the usefulness of the network. The 940 Systems, for example, have a very specialized echo.
When we consider using graphics stations or other sophisticated terminals under the control of a remote HOST, the problem becomes more severe. We must look for some method which allows us to use our most sophisticated equipment as much as possible as if we were connected directly to the remote computer.
遠く離れたリモートのホストに接続して結果を受け取って手元の端末で処理するには時間がかかるという話。"The 940 Systems" は SDS 940 のことと考えられる。
Error Checking
The point is made by Jeff Rulifson at SRI that error checking at major software interfaces is always a good thing. He points to some experience at SRI where it has saved much dispute and wasted effort. On these grounds, we would like to see some HOST to HOST checking. Besides checking the software interface, it would also check the HOST-IMP transmission hardware. (BB&N claims the HOST-IMP hardware will be as reliable as the internal registers of the HOST. We believe them, but we still want the error checking.)
ホストと IMP の通信など主要なソフトウェアのインターフェイスではエラーチェックが必要になるという話。エラーチェックによって無駄な論争を省くことができる、というのは本当にそうだと思う。
例えば BB&N は IMP のハードウェアとして Honeywell の DDP-516 というコンピュータを使用していたが、これは I/O の特定タイミングで処理が割り込んだ時クラッシュするという問題があった。これは結果的に Honeywell に fix してもらったのだが、当初は Honeywell に自社の問題ではないと拒絶されたそうだ。BB&N は DDP-516 に多大な負荷をかけた上でオシロスコープで信号を監視し仮説を立証する証拠を集めた上で Honeywell に報告した。このように「誰の責任か」を立証するためにエラーの情報はあって困ることはない。
III. The Host Software
Establishment of a Connection
The simplest connection we can imagine is where the local HOST acts as if it is a TTY and has dialed up the remote HOST. After some consideration of the problems of initiating and terminating such a connection , it has been decided to reserve link 0 for communication between HOST operating systems. The remaining 31 links are thus to be used as dial-up lines.
遠く離れたリモートのホストに接続する場合、ホストの OS 間の通信用にホスト間の 32 リンクのうち 1 つ（リンク 0）を確保しておくという話。
Each HOST operating system must provide to its user level programs a primitive to establish a connection with a remote HOST and a primitive to break the connection. When these primitives are invoked, the operating system must select a free link and send a message over link 0 to the remote HOST requesting a connection on the selected link. The operating system in the remote HOST must agree and send back an accepting message over link 0. In the event both HOSTs select the same link to initiate a connection and both send request messages at essentially the same time, a simple priority scheme will be invoked in which the HOST of lower priority gives way and selects another free link. One usable priority scheme is simply the ranking of HOSTS by their identification numbers. Note that both HOSTs are aware that simultaneous requests have been made, but they take complementary actions: The higher priority HOST disregards the request while the lower priority HOST sends both an acceptance and another request.
各ホストの OS は、接続を確立および切断する方法をユーザーに提供する。接続する場合は空いているリンクを選択し、どのリンクで接続するかを（予めホスト OS 間の通信用に確保しておいた）リンク 0 を通じてリモートのホストに送信する。
同じリンクを同時に複数のホストが使うことはできないので、競合状態が発生した場合にどちらのホストを優先するかを一定のルールで決める必要がある。ここではホストの識別番号で優先順位をつけることが提案されている。各ホストはこの優先順位のルールを認識し、それに従った行動をとる必要がある。
The connection so established is a TTY-like connection in the pre-log-in state. This means the remote HOST operating system will initially treat the link as if a TTY had just called up. The remote HOST will generate the same echos, expect the same log-in sequence and look for the same interrupt characters.
遠く離れたリモートのホストは手元の端末からホストに接続するのと同じように使いたい。
High Volume Transmission
Teletypes acting as terminals have two special drawbacks when we consider the transmission of a large file. The first is that some characters are special interrupt characters. The second is that special buffering techniques are often employed, and these are appropriate only for low-speed character at time transmission.
手元のテレタイプ端末から大容量のファイルを送る際の欠点として以下の 2 点がある。
- 特殊な割り込み文字があること
- テレタイプ端末のバッファリングはネットワーク越しにリモートのホストを呼び出すには適していないこと
We therefore define another class of connection to be used for the transmission of files or other large volumes of data. To initiate this class of link, user level programs at both ends of an established TTY-like link must request the establishment of a file-like connection parallel to the TTY-like link. Again the priority scheme comes into play, for the higher priority HOST sends a message over link 0 while the lower priority HOST waits for it. The user level programs are, of course, not concerned with this. Selection of the free link is done by the higher priority HOST.
File-like links are distinguished by the fact that no searching for interrupt characters takes place and buffering techniques appropriate for the higher data rates takes place.
大容量のデータを送信するために必要な種類の接続を定義する。基本的には通常のデータ伝送と同じようにリンクを確保して優先順位に沿ってメッセージを送る...という手順だが、大容量データの場合には割り込み文字を検索せず、より大きなデータに適したバッファリングを行うという違いがある。
A Summary of Primitives
Each HOST operating systems must provide at least the following primitives to its users. This list knows not to be necessary but not sufficient.
a) Initiate TTY-like connection with HOST x.
b) Terminate connection.
c) Send/Receive character(s) over TTY-like connection.
d) Initiate file-like connection parallel to TTY-like connection.
e) Terminate file-like connection.
f) Send/Receive over file-like connection.
各ホストの OS は、以下の機能をユーザーに提供しなければならない。
a) TTY のような接続を開始する
b) 接続を終了する
c) TTY ライクな接続で文字を送受信する
d) TTY ライクな接続と並行して、ファイルライクな接続を開始する
e) ファイル型接続を終了する
f) ファイル型接続で送受信する
Error Checking
We propose that each message carry a message number, bit count, and a checksum in its body, that is transparent to the IMP. For a checksum we suggest a 16-bit end-around-carry sum computed on 1152 bits and then circularly shifted right one bit. The right circular shift every 1152 bits is designed to catch errors in message reassembly by the IMPs.
各メッセージは IMP が見られるようにメッセージの番号や bit 数、チェックサムを含める。
Closer Interaction
The above described primitives suggest how a user can make simple use of a remote facility. They shed no light on how much more intricate use of the network is to be carried out. Specifically, we are concerned with the fact that as some sites a great deal of work has gone into making the computer highly responsive to a sophisticated console. Culler's consoles at UCSB and Englebart's at SRI are at least two examples. It is clear that delays of a half-second or so for trivial echo-like responses degrade the interaction to the point of making the sophistication of the console irrelevant.
今では手元のスマホや PC からインターネットを通じてテキストや動画、音声などに触れるのが当たり前になっているが、当時から遠く離れたコンピュータに手元の端末からアクセスして結果を受け取り...というインタラクションの体験をなるべく円滑にすることが重視されていたようだ。
画面がよく出来ていても反応が遅いと「使いづらいシステムだなぁ」と思ってしまうのでそれはそう。
We believe that most console interaction can be divided into two parts, an essentially local, immediate and trivial part and a remote, more lengthy and significant part. As a simple example, consider a user at a console consisting of a keyboard and refreshing display screen. The program the user is talking typing into accumulates a string of characters until a carriage return is encountered and then it processes the string. While characters are being typed, it displays the characters on the screen. When a rubout character is typed, it deletes the previous non-rubout character. If the user types H E L L O <- <- P <CR> where <- is rubout and <CR> is carriage-return, he has made nine keystrokes. If each of these keystrokes causes a message to be sent which in return invokes instructions to our display station we will quickly become bored.
手元のコンソールからリモートのホストにアクセスするとき、すべての入力された文字を Message として送信し結果を受け取って返しディスプレイに表示する...という体験は飽き飽きする（例えば H E L L O <- <- P <CR>（HELLO から最後の LO を削除し P を追加して最後に <CR> する）と入力すると 9 回の入力を行ったことになる）。本質的にローカルで完結すべき部分とリモートで処理される部分に分かれるべきと考えられる。
A better solution would be to have the front-end of the remote program -- that is the part scanning for <- and <CR> -- be resident in our computer. In that case, only one five character message would be sent, i.e., H E L P <CR>, and the screen would be managed locally.
リモートホストのフロントエンドとして存在する手元の端末では、<- や <CR> をスキャンする部分を手元の端末側で処理し、H E L P <CR>の 5 文字が送られる。
We propose to implement this solution by creating a language for console control. This language, current named DEL, would be used by subsystem designers to specify what components are needed in a terminal and how the terminal is to respond to inputs from its keyboard, Lincoln Wand, etc. Then, as a part of the initial protocol, the remote HOST would send to the local HOST, the source language text of the program which controls the console. This program would have been by the subsystem designer in DEL, but will be compiled locally.
The specifications of DEL are under discussion. The following diagrams show the sequence of actions.
コンソール制御のために DEL という言語を新たに作ることを提案している。DEL は Decode-Encode Language の略で、詳しくは RFC5 を参照。RFC1 には DEL の一連の挙動を示した図が記載されている。
ユーザーの手元にある端末がキーボード等からの入力にどのように応答するかを指定するために使用され、リモートのホストからユーザーの手元の端末のコンソールを制御するために送信される。
現代では使われていないが、1969 年における JavaScript のような存在だったのだろう。というか Telnet に近いかもしれない？
A. Before Link Establishment
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
b. After Link Establishment and Log-in
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /
c. After Receipt and Compilation of the DEL program
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
Open Questions
- If the IMPs do code conversion, the checksum will not be correct.
- The procedure for requesting the DEL front end is not yet specified.
- IMP がコード変換を行うと、チェックサムは正しくない
- DEL フロントエンドを要求する手順は、まだ規定されていない
ホストが送るメッセージにチェックサムを含めて送信すると IMP がなんらかの変換処理をした時に受信側でチェックサムが合わないという問題があったらしい。
IV. Initial Experiments
Experiment One
SRI is currently modifying their on-line retrieval system which will be the major software component on the Network Documentation Center so that it can be operated with model 35 teletypes. The control of the teletypes will be written in DEL. All sites will write DEL compilers and use NLS through the DEL program.
SRI が DEL 言語を通じてドキュメントの検索システムを操作できるようにソフトウェアを書いている。
Experiment Two
SRI will write a DEL front end for full NLS, graphics included. UCLA and UTAH will use NLS with graphics.
SRI は DEL フロントエンドを開発し、UCLA と UTAH はグラフィック付きの NLS を使用する。NLS（oNLine System）は SRI を率いていた Engelbart が開発していたシステムで、ハイパーテキストリンクやマウスなど現代のコンピュータの基礎になるような概念を実装していた。
Discussion