はじめに
1970年8月12日、私は BBN で、BBN と MIT の代表者と会い、第三レベルプロトコルについて議論した。
ダイヤルアップ 次の提案ダイヤルアッププロトコルは会議で合意された。
このプロトコルの目的は、一方のサイト(以下、利用側サイト)にあるプロセスを、他方のサイト(以下、提供側サイト)にあるロガーと接触させることである。
接触を開始するため、利用プロセスは受信ソケット US を割り当て、提供側ホストのソケット 1 へのコネクションを要求する。したがって利用側 NCP は次を送る
1 4 4 1
---------------------------------------------------
|RTS | US | 1 | p|
---------------------------------------------------
|ALL | P | space |
-------------------------------
リンク 1 上で、ここで US は利用者の受信ソケット、p はリンク、space は何らかの公称空間割り当てである。
提供側ホストは接触を拒否することを決めるかもしれず、その場合には標準の CLS で応答する。しかし接触を受け入れる場合には、コネクション上でちょうど偶数の 32 ビット数を送り、コネクションを閉じる。この偶数の 32 ビット数は、提供側ホスト内の受信ソケットの名前である。このソケットと、その次に大きい番号のソケットは、利用者との接触のために予約される。したがって提供側 NCP は次を送る
1 4 1
----------------------------
| STR | 1 | US|
----------------------------
リンク 1 上で、続いて
4
-----------
| SS |
-----------
リンク p 上で。SS は偶数でなければならないことに注意。
サーバーソケット番号 SS を送った後、NCP は次を送る
1 4 4
-------------------------------------
|CLS | 1 | US |
-------------------------------------
|STR | SS+1 | US |
------------------------------------------
|RTS | SS | US+1 | q |
------------------------------------------
|ALL | q | space |
-----------------------------
利用側ホストもまた、次を送ることによってこれらのコネクションを設定する
1 4 4
----------------------------------------
| CLS | US | 1 |
----------------------------------------
| STR | US+1 | SS |
--------------------------------------------
| RTS | US | SS+1 | r |
--------------------------------------------
この時点で、利用者は提供側サイトのロガーに接続されているはずである。
標準コンソール
次に我々は、初期のネットワーク標準コンソールについて合意した。すなわち、8ビットフィールドに入れた 7ビット ASCII で、第8ビットをオンにし、連続したストリームとして伝送する。具体的なコードは、IMP Operations manual、BBN report #1877 の付録 H に列挙されている。これは PDP-10 ではいくらか苦労を伴ってのみ動作し、他のすべてにとっては問題ないようである。
ブレークまたは割り込みには、多くのシステムが標準文字の一つを使用する。別の種類の信号を必要とするシステムについては、
1 1
------------
|INR | r |
------------
制御リンク上で送られるものが十分であろう。
注: この RFC は、Gottfried Janik によって 2/98 に、オンライン RFC アーカイブへ登録するために機械可読形式にされた。