メインコンテンツまでスキップ

RFC 1 - ホストソフトウェア (Host Software)

ネットワークワーキンググループ (Network Working Group): Steve Crocker
コメント要求 (Request for Comments): 1
機関: UCLA
日付: 1969年4月7日

概要​

本文書はARPANET史上初のRFCであり、ホストソフトウェアの設計考慮事項について論じています。本文書は、IMP (Interface Message Processor、インターフェースメッセージプロセッサ) ソフトウェアの概要、ホスト間ソフトウェアの要件、接続確立メカニズム、および予備実験計画を網羅しています。この文書は、インターネットプロトコル文書の伝統の始まりを示すものです。

目次 (CONTENTS)​

はじめに (INTRODUCTION)​

ARPAネットワークのソフトウェアは、一部はIMPに、一部はそれぞれのホスト (HOSTs) に存在します。BB&N社はIMPのソフトウェアを規定しており、ホストソフトウェアについて合意することはホストグループの責任です。

1968年の夏、最初の4つのサイトの代表者が、ホストソフトウェアとネットワーク上の初期実験について議論するために何度か会合を持ちました。これらの会議から、ユタ大学のSteve Carr、SRIのJeff Rulifson、UCLAのSteve Crockerの3人からなるワーキンググループが生まれ、秋と冬に何度か会合を持ちました。最近の会議は3月の最終週にユタで開催されました。また、最近Jeff Rulifsonと共同作業を始めたSRIのBill Duvallも出席していました。

やや独立して、UCLAのGerard DeLocheがホスト-IMPインターフェースに取り組んでいます。

ここでは、到達した暫定的な合意のいくつかと、遭遇した未解決の問題のいくつかを提示します。ここに記載されていることのほとんどは確定的ではなく、反応が期待されています。

I. IMPソフトウェアの概要 (A Summary of the IMP Software)​

メッセージ (Messages)​

情報は、メッセージ (messages) と呼ばれるバンドルでホストからホストへ伝送されます。メッセージとは、ヘッダーと共に8080ビット以下の任意のデータストリームです。ヘッダーは16ビットで、以下の情報を含みます:

宛先 (Destination)     5ビット
リンク (Link)          8ビット
トレース (Trace)       1ビット
予備 (Spare)           2ビット

宛先は、メッセージが送信されるべきホストの数値コードです。トレースビットは、IMPにメッセージに関するステータス情報を記録し、その情報をNMC (Network Measurement Center、ネットワーク測定センター、すなわちUCLA) に送り返すよう信号を送ります。予備ビットは未使用です。

リンクフィールドは、IMPが特定の種類の輻輳を制限するために使用する特別なデバイスです。その機能は以下の通りです。すべてのホストのペアの間には、32の論理的全二重接続 (logical full-duplex connections) があり、メッセージはどちらの方向にも渡すことができます。IMPはこれらのリンクに、宛先のIMPがRFNM (Request for Next Message、次のメッセージの要求) と呼ばれる特別なメッセージを送り返す前に、どのホストも同じリンク上で連続して2つのメッセージを送信できないという制限を課します。この配置は、送信ホストが1つのリンク上であまりにも多くを送信しようとする場合に、1つのホストが別のホストに引き起こす可能性のある輻輳を制限します。しかし、宛先のIMPには32のすべてのリンクを同時に処理するのに十分な容量がないため、リンクは過負荷が1つまたは2つのリンクから来ている場合にのみその目的を果たすことに注意します。ホストはこの点で協力する必要があります。

リンクには以下の基本的な特性があります。それらは常に機能しており、常に32あります。

「常に機能している」とは、IMPが常にその上で別のメッセージを送信する準備ができていることを意味します。会話を開始または終了するという概念はIMPソフトウェアに含まれていません。したがって、リンクの状態についてIMPに問い合わせることはできません (ただし、リンクの最近の履歴についてIMPに問い合わせることは可能かもしれません -- これはまったく別の問題です!)。

リンクのもう1つの基本的な特性は、使用されているかどうかにかかわらず、常に32あるということです。これは、実際のトラフィックに関係なく、各IMPが32のエントリを持つ18のテーブルを維持しなければならないことを意味します。

リンク構造に対する異議があるにもかかわらず、リンクはIMP内で簡単にプログラムでき、その単純さのためだけでも、より複雑な配置よりも優れた代替案である可能性があります。

IMP伝送とエラーチェック (IMP Transmission and Error Checking)​

ホストからメッセージを受信した後、IMPはメッセージを1つ以上のパケット (packets) に分割します。パケットは1010ビット以下の長さで、IMPからIMPへのデータ伝送の単位です。24ビットの巡回チェックサム (cyclic checksum) が伝送ハードウェアによって計算され、送信パケットに付加されます。チェックサムは受信ハードウェアによって再計算され、伝送されたチェックサムと照合されます。パケットは宛先IMPでメッセージに再組み立てされます。

IMPソフトウェアに関する未解決の問題 (Open Questions on the IMP Software)​

  1. リンク仕様のために8ビットフィールドが提供されていますが、32のリンクしか提供されていないのはなぜですか?

  2. ホストはそのIMPにメッセージを送信できるはずです。どのようにしてそれを行うのですか?

  3. ホストは、そのIMPとは対照的に、RFNMを制御できますか?

  4. IMPはコード変換を実行しますか?どのように制御されるのですか?

II. ホスト間ソフトウェアに対するいくつかの要件 (Some Requirements Upon the Host-to-Host Software)​

シンプルな使用 (Simple Use)​

他の新しい施設と同様に、ユーザーコミュニティがネットワークを実験し、それに依存し始めるまで、非常に軽い使用の期間があります。私たちの目標の1つは、幅広いクラスのユーザーによる即座で簡単な使用を刺激することでなければなりません。この目標により、TTY (teletype、テレタイプ) 端末からダイヤルアップされたかのように、任意のリモートホストを使用する能力を提供することが自然に思えます。さらに、テレタイプをシミュレートするのとは異なる方法でファイルを送信する能力も必要です。

高度な使用 (Deep Use)​

ネットワークに固有の問題の1つは、どんなに単純であっても、リモートホストからのすべての応答に約0.5秒程度の時間が必要であるという事実です。テレタイプの使用については、半二重ローカルエコー方式に切り替えることができますが、これはネットワークの有用性の一部を損なうことになります。たとえば、940システムには非常に特殊なエコーがあります。

リモートホストの制御下でグラフィックステーションやその他の高度な端末を使用することを考えると、問題はさらに深刻になります。リモートコンピュータに直接接続されているかのように、できるだけ高度な機器を使用できるようにする方法を探さなければなりません。

エラーチェック (Error Checking)​

SRIのJeff Rulifsonは、主要なソフトウェアインターフェースでのエラーチェックは常に良いことであると指摘しています。彼は、多くの論争と無駄な努力を節約したSRIでのいくつかの経験を指摘しています。これらの理由から、ホスト間チェックを実施したいと考えています。ソフトウェアインターフェースのチェックに加えて、ホスト-IMP伝送ハードウェアもチェックします。(BB&Nは、ホスト-IMPハードウェアがホストの内部レジスタと同じくらい信頼性が高いと主張しています。私たちは彼らを信じていますが、それでもエラーチェックが必要です。)

III. ホストソフトウェア (The Host Software)​

接続の確立 (Establishment of a Connection)​

私たちが想像できる最もシンプルな接続は、ローカルホストがTTYとして機能し、リモートホストにダイヤルアップする場合です。このような接続の開始と終了の問題を検討した後、ホストオペレーティングシステム間の通信のためにリンク0を予約することが決定されました。したがって、残りの31のリンクはダイヤルアップ回線として使用されます。

各ホストオペレーティングシステムは、そのユーザーレベルプログラムに、リモートホストとの接続を確立するためのプリミティブ (primitive) と、接続を切断するためのプリミティブを提供しなければなりません。これらのプリミティブが呼び出されると、オペレーティングシステムは空きリンクを選択し、選択したリンク上での接続を要求するメッセージをリンク0を介してリモートホストに送信しなければなりません。リモートホストのオペレーティングシステムは同意し、リンク0を介して受諾メッセージを送り返さなければなりません。両方のホストが接続を開始するために同じリンクを選択し、両方が本質的に同時に要求メッセージを送信する場合、単純な優先度スキームが呼び出され、優先度の低いホストが譲歩して別の空きリンクを選択します。使用可能な優先度スキームの1つは、単純にホストを識別番号でランク付けすることです。両方のホストが同時要求が行われたことを認識していますが、補完的なアクションを取ることに注意してください:優先度の高いホストは要求を無視し、優先度の低いホストは受諾と別の要求の両方を送信します。

このように確立された接続は、ログイン前の状態のTTYライクな接続です。これは、リモートホストオペレーティングシステムが最初にリンクをTTYがダイヤルアップしたかのように扱うことを意味します。リモートホストは同じエコーを生成し、同じログインシーケンスを期待し、同じ割り込み文字を探します。

大容量伝送 (High Volume Transmission)​

端末として機能するテレタイプには、大きなファイルの伝送を考えるときに2つの特別な欠点があります。1つ目は、一部の文字が特別な割り込み文字であることです。2つ目は、特別なバッファリング技術がよく採用されますが、これらは低速の文字単位の伝送にのみ適しています。

したがって、ファイルまたはその他の大量のデータの伝送に使用する別のクラスの接続を定義します。このクラスのリンクを開始するには、確立されたTTYライクなリンクの両端のユーザーレベルプログラムが、TTYライクなリンクと並行してファイルライクな接続の確立を要求しなければなりません。優先度スキームが再び機能します。優先度の高いホストがリンク0を介してメッセージを送信し、優先度の低いホストはそれを待ちます。もちろん、ユーザーレベルプログラムはこれを気にしません。空きリンクの選択は、優先度の高いホストによって行われます。

ファイルライクなリンクは、割り込み文字の検索が行われず、より高いデータレートに適したバッファリング技術が採用されるという点で区別されます。

プリミティブの要約 (A Summary of Primitives)​

各ホストオペレーティングシステムは、そのユーザーに少なくとも以下のプリミティブを提供しなければなりません。このリストは必要であることが知られていますが、十分ではありません。

a) ホストxとのTTYライクな接続を開始する

b) 接続を終了する

c) TTYライクな接続を介して文字を送信/受信する

d) TTYライクな接続と並行してファイルライクな接続を開始する

e) ファイルライクな接続を終了する

f) ファイルライクな接続を介して送信/受信する

エラーチェック​

各メッセージは、IMPに対して透過的な、その本体にメッセージ番号、ビットカウント、およびチェックサムを運ぶことを提案します。チェックサムについては、1152ビットで計算され、次に循環的に右に1ビットシフトされる16ビットのエンドアラウンドキャリーサム (end-around-carry sum) を提案します。1152ビットごとの右循環シフトは、IMPによるメッセージの再組み立てのエラーをキャッチするように設計されています。

より密接な相互作用 (Closer Interaction)​

上記のプリミティブは、ユーザーがリモート施設を簡単に使用する方法を示唆しています。ネットワークのより複雑な使用がどのように実行されるかについては何も明らかにしていません。具体的には、一部のサイトでは、コンピュータを高度なコンソールに非常に応答性の高いものにするために多くの作業が投入されているという事実に関心があります。UCSBのCullerコンソールとSRIのEnglebartコンソールは、少なくとも2つの例です。些細なエコーのような応答に対して0.5秒程度の遅延が、コンソールの高度さを無関係にする程度まで相互作用を低下させることは明らかです。

ほとんどのコンソール相互作用は2つの部分に分割できると考えています。本質的にローカルで即時かつ些細な部分と、リモートでより長く重要な部分です。簡単な例として、キーボードとリフレッシュディスプレイ画面で構成されるコンソールにいるユーザーを考えてみましょう。ユーザーが入力しているプログラムは、キャリッジリターンに遭遇するまで文字列を蓄積し、次に文字列を処理します。文字が入力されている間、画面に文字を表示します。ルバウト文字 (rubout) が入力されると、前の非ルバウト文字を削除します。ユーザーが H E L L O <- <- P <CR> を入力した場合 (<- はルバウト、<CR> はキャリッジリターン)、9回のキーストロークを行ったことになります。これらのキーストロークのそれぞれがメッセージの送信を引き起こし、そのメッセージが今度はディスプレイステーションへの命令を呼び出す場合、すぐに退屈になります。

より良い解決策は、リモートプログラムのフロントエンド -- つまり <- と <CR> をスキャンする部分 -- が私たちのコンピュータに常駐することです。その場合、5文字のメッセージ、つまり H E L P <CR> のみが送信され、画面はローカルで管理されます。

このソリューションを実装するために、コンソール制御用の言語を作成することを提案します。この言語は、現在DELと名付けられており、サブシステム設計者が端末に必要なコンポーネントと、端末がキーボード、Lincoln Wandなどからの入力にどのように応答するかを指定するために使用されます。次に、初期プロトコルの一部として、リモートホストはローカルホストに、コンソールを制御するプログラムのソース言語テキストを送信します。このプログラムはサブシステム設計者によってDELで記述されますが、ローカルでコンパイルされます。

DELの仕様は議論中です。以下の図は操作のシーケンスを示しています。

         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+                    +-----------+    |
        |     |     |     | Request connection |     |     |    |
   UCLA {     |     |     | -> over link 25    |     |     |    } SRI
        |     |   +-+-+   |  +-+          +-+  |   +-+-+   |    |
        |     |   | OS|---+-=|I|----------|I|=-+---| OS|   |    |
        |     |   +-+-+   |  +-+          +-+  |   +---+   |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST: SRI      |
         \                                                     /
         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+ "Please send front"+-----------+    |
        |     |     |     | end control"       |     |     |    |
   UCLA {     |     |     |        ->          |     |     |    } SRI ___
        |     |   +-+-+   |  +-+          +-+  |  +--+---+ |    |    /   |
        |     |   | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---|    |
        |     |   +-+-+   |  +-+          +-+  |  +------+ |    |   |___/
        |     |           |       DEL prog.    |           |    |   |    |
        |     |           |        <-          |           |    |   |____|
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST:SRI       |
         \                                                     /

C. DELプログラムの受信とコンパイル後 (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)​

  1. IMPがコード変換を行う場合、チェックサムは正しくありません。

  2. DELフロントエンドを要求する手順はまだ指定されていません。

IV. 初期実験 (Initial Experiments)​

実験1 (Experiment One)​

SRIは現在、ネットワークドキュメンテーションセンターの主要なソフトウェアコンポーネントとなるオンライン検索システムを、モデル35テレタイプで操作できるように修正しています。テレタイプの制御はDELで記述されます。すべてのサイトはDELコンパイラを記述し、DELプログラムを通じてNLSを使用します。

実験2 (Experiment Two)​

SRIは、グラフィックスを含む完全なNLS用のDELフロントエンドを記述します。UCLAとユタ大学は、グラフィックスを備えたNLSを使用します。

注: このRFCは、Celeste Andersonによって1997年3月にマシン可読形式に変換され、オンラインRFCアーカイブに入力されました。

関連リソース​

  • 公式テキスト: https://www.rfc-editor.org/rfc/rfc1.txt
  • 公式ページ: https://datatracker.ietf.org/doc/html/rfc1

歴史的意義​

RFC 1は、インターネット史上初のRFC文書であり、ARPANETと現代のインターネットプロトコル文書の伝統の始まりを示すものです。若い大学院生Steve Crockerによって書かれたこの文書では、彼は謙虚にこれらの文書を「コメント要求 (Request for Comments)」と呼び、この名称は今日まで続いています。この文書は、初期のインターネット先駆者たちの協力精神と開かれた態度を体現しています。

に最終更新