RFC1055 Serial Line Internet Protocol 日本語訳

はじめに

PPPの前身としてSerial Line Internet Protcolの名前を時々見る。いまさら実装する人がいるとも思えないが、メモとして書き出しておく。

本文

Network Working Group J. Romkey
Request for Comments: 1055 1988年7月

イントロダクション

このTCP/IP プロトコルファミリは、様々なネットワーク媒体を通して実行される: IEEE 802.3 (イーサネット) and 802.5 (トークンリング) LAN's, X.25 lines, 衛星通信、そしてシリアル通信である。これらのネットワークにおいては様々なカプセル化の標準があるが、シリアル通信にはない。SLIP、Serial Line IPは現在の事実上の標準で、TCP/IPを実行するポイント・ツー・ポイントのシリアル接続に一般的に使われている。これはインターネットの標準ではない。このメモの再配布は制限されない。

歴史

SLIPは1980年代初頭の3COM UNETのTCP/IPの実装に起源をもつ。これは単にパケットをフレーム化するプロトコルである: SLIPはIPパケットをフレーム化するシーケンスを定義し、それ以外は何もしない。アドレッシング、パケット型の定義、エラー検出/訂正や圧縮方式を提供しない。プロトコルが非常に小さいため、通常は実装が非常に簡単である。

1984年頃、RIck Adamsは4.2 Berkeley UnixとSum Microsystemsのワークステーションに対してSLIPを実装し、世界に公開した。これはすぐにシリアル通信でTCP/IP ホストやルータに接続する簡単で信頼性のある方法として人気を博した。

SLIPは時にはダイヤルアップの目的のために専用のシリアル接続で使われ、一般に1200bpsから19.2kbpsの間の回線速度で使われている。これは複数のホストとルータが相互に接続できるようにするために有用である(ホストとホスト、ホストとルータ、ルータとルータはすべて一般的なSLIPネットワークの構成である)。

可用性

SLIPは多くのBerkeley Unixベースのシステムで利用できる。これはバークレーの標準的な4.3 BSDリリースにに含まれている。SLIPはUltrix、Sun UNIXや他の多くのBereley派生のUNIXシステムで利用できる。複数の終端集線装置やIBM PCの実装でも利用できる。

Berkley UNITのSLIPはpub/sl.shar.Z内にあるuune.uu.netからの匿名FTPから入手できる。必ずバイナリモードでファイルを転送してから、UNIXの解凍プログラムを実行すること。結果のファイルを入手して、UNIXの/bin/shでシェルスクリプトとして実行する(/bin/sh sl.shar のように)。

プロトコル

SLIPプロトコルは2つの特殊文字を定義する: ENDとESC。ENDは8進数で300(10進数で192)、ESCは8進数で333(10進数で219)で、ASCIIのEscapeと混同しないようにする: 議論を避けるため、ESCはSLIP ESC文字を示すことにする。パケットを送るとき、SLIPホストは単にパケット内のデータを送り始める。もし、あるデータバイトがEND文字と同じコードであれば、2バイトのESCと8進数334(10進数で220)を代わりに送る。パケット末尾のバイトを送ってから、END文字を送信する。

Phil Karnは、パケットの終わりと同様にEND文字で開始する、アルゴリズムの簡単な変更を提案している。これは回線のノイズによって引き起こされた誤ったバイトを除去することを意図している。通常のケースでは、レシーバには単に連続したEND文字に見えると予想されるが、これは間違ったIPパケットを作り出す。もしSLIPの実装が長さ0のIPパケットを破棄しないならば、IPの実装がおそらくそうするだろう。もし配線ノイズがあっても、受信されたデータは後のパケットに影響を与えることなく破棄されるだろう。

SLIPには'標準的な'仕様がないために、最大のパケット長は定義されない。Berkley UNIX SLIPドライバで使われている最大のパケットサイズを受け入れることが最良であろう: これはIPと通信プロトコルのヘッダを含み1006バイトである(フレーミング文字を含まない)。したがって、新規のSLIP実装では1006バイトのデータグラムを受け入れられるように用意して、1つのデータグラムを1006バイトを超えて送らないようにするべきである。

不足

多くのユーザーがSLIPに実装してほしいと思っているがそうではない機能が多くある。公平のためにいうならば、SLIPはそれらの問題があまり重要でなかったくらいずっと前に設計された、単にとても単純なプロトコルである。以下は既存のSLIPプロトコルに対するよく知られた欠点である。

アドレッシング:

SLIP接続の両端のコンピュータはルーティングのためにお互いのアドレスを知る必要がある。また、ルータにダイヤルアップするホストでSLIPを使う場合、アドレッシングの方法は非常に動的になってしまい、ルータはダイヤルしてきているホストにIPアドレスを通知する必要があるだろう。現状のSLIPは、SLIP接続を通してホストにアドレッシングの情報を伝える方法を提供していない。

型識別:

SLIPには型識別のフィールドがない。そのため、1つのSLIP接続を通して1つのプロトコルしか実行できず、TCP/IPとDECnetの両方を実行している2台のDECコンピュータの構成では、SLIPを用いる限りTCP/IPとDECnetが1本のシリアル通信を共用する余地はない。しかしながら、SLIPは"Serial Line IP"であるから、もしシリアル通信がマルチプロトコルのコンピュータ2台間を接続しているのであれば、回線を通して複数のプロトコルを使用できるべきだろう。

エラー検出/訂正:

ノイズの多い電話回線では、通信の途中でパケットが破損するだろう。おそらく回線速度が非常に低い(2400ボーのように)ために、パケットの再送は非常に高コストである。どんなIPアプリケーションでも破損したパケットを検出しなければならないから、エラー検出はSLIPレベルでは絶対に必要とはいえないが、NFSのようないくつかの一般的なアプリケーションではチェックサムを省略し、破損したパケットの検出をネットワーク媒体に頼っている。回線ノイズによって引き起こされるパケット再送は非常に長い時間を要するため、SLIP自体に一種の単純なエラー訂正の機構があれば効率化されるだろう。

圧縮:

ダイヤルイン回線は非常に低速(一般に2400bps)であるために、パケット圧縮はパケットスループットを大きく改善するだろう。一般に、単一のTCP接続における一連のパケットではIPとTCPヘッダにはほとんど変化がないため、単純な圧縮アルゴリズムでは完全なヘッダの代わりにヘッダの変化した部分だけを送るかもしれない。

これらのいくつかまたはすべての問題に対処したSLIPの後継を設計、実装するために、様々なグループによって複数の活動が行われています。

SLIPドライバ

以下のC言語の関数は、SLIPパケットを送受信する。これらは、2種類のsend_char()とrecv_char()というシリアル回線を通して1文字を送受信する関数に依存している。

(以下コードのため省略)