ゼロックス ネットワーク システム

Xerox Network Systems ( XNS )は、 Xerox Network Systems Architecture内でXeroxが開発したコンピュータ ネットワーク プロトコル スイートです。汎用ネットワーク通信、インターネットワークルーティングとパケット配信、および信頼性の高いストリームやリモート プロシージャ コールなどの高レベル機能を提供します。XNS は、開放型システム間相互接続(OSI) ネットワーク モデルの開発に先行して影響を与え、 1980 年代の ローカル エリア ネットワーク設計に大きな影響を与えました。

XNS は、ゼロックス PARCの研究成果を市場に投入する任務を負っていたゼロックス システム開発部門によって 1980 年代初頭に開発されました。XNS は、1970 年代後半の以前の (そして同様に影響力のあった) PARC Universal Packet (PUP) スイートに基づいています。XNS スイートの一部のプロトコルは、Pup スイートのプロトコルをわずかに変更したバージョンです。XNS では、ネットワーク番号の概念が追加され、複数の小さなネットワークから大規模なネットワークを構築できるようになりました。ルーターは、ネットワーク間の情報の流れを制御します。

XNS のプロトコル スイート仕様は1977 年にパブリック ドメインになりました。これにより、XNS は標準的なローカル エリア ネットワークプロトコルとなり、1990 年代まで使用されていたほぼすべてのネットワーク システムでさまざまな程度にコピーされました。XNS は、3Comの3+ShareおよびUngermann-Bassの Net/One で変更されずに使用されました。また、修正を加えてNovell NetWareおよびBanyan VINESの基盤としても使用されました。XNS はAppleNetシステムの基盤として使用されましたが、これは商用化されませんでした。一般的な問題に対する XNS のソリューションの多くは、AppleNet の代替であるAppleTalkで使用されました。

OSIモデルの7層と比較すると、XNSは後のインターネットプロトコルスイートと同様に5層システムです^[1]。

OSI モデルの物理層とデータリンク層は、XNS の物理層 (レイヤー 0) に対応します。XNS は、基盤となるハードウェアのトランスポート メカニズムを使用するように設計されており、データリンクは分離されていません。具体的には、XNS の物理層は実際にはイーサネット ローカル エリア ネットワークシステムであり、これは Xerox によって同時に開発されており、その設計上の決定の多くはその事実を反映しています。^[1]このシステムは、イーサネットを他のシステムに置き換えることができるように設計されていましたが、それはプロトコルによって定義されていませんでした (定義する必要もありませんでした)。

XNS の主要部分は、OSI のネットワーク層に対応する内部トランスポート層 (レイヤー 1) の定義であり、ここで主要なインターネットワーキング プロトコルである IDP が定義されています。XNS は、OSI のセッション層とトランスポート層を単一のプロセス間通信層 (レイヤー 2) に統合しました。レイヤー 3 は、OSI のプレゼンテーションに似たリソース制御でした。^{[1] [2]}

最後に、両方のモデルの上にはアプリケーション層がありますが、これらの層はXNS標準では定義されていません。^[1]

主なインターネットワーク層プロトコルはインターネットデータグラムプロトコル（IDP ）です。IDPはPupのインターネットワークプロトコルの近似子孫であり、インターネットプロトコルスイートのインターネットプロトコル（IP）層にほぼ相当します。 ^[1]

IDP は、イーサネットの 48 ビット アドレスを独自のネットワーク アドレス指定の基礎として使用し、通常はマシンのMAC アドレスを主要な一意の識別子として使用します。これに、ネットワーク機器によって提供される別の 48 ビットのアドレス セクションが追加されます。32 ビットはルーターによって提供され、インターネットワーク内のネットワーク番号を識別し、別の 16 ビットは単一のホスト内でのサービス選択用のソケット番号を定義します。アドレスのネットワーク番号部分には、ネットワーク番号を (まだ) 知らないホストが使用する「このネットワーク」を意味する特別な値も含まれています。^[2]

TCP/IP とは異なり、ソケット番号は IDP ヘッダーの完全なネットワーク アドレスの一部であるため、上位層プロトコルは多重分離を実装する必要がありません。IDP はパケット タイプも提供します (これも IP とは異なります)。IDP にはパケット全体をカバーするチェックサムも含まれていますが、これは必須ではなくオプションです。これは、LAN のエラー率が一般的に低いという事実を反映しており、XNS はパフォーマンスを向上させるために下位レベルのプロトコルからエラー訂正を削除しました。エラー訂正は、プロトコル スタックの上位レベル、たとえば XNS 独自の SPP プロトコルでオプションで追加できます。この設計ノートのおかげで、XNS は IP よりも高速であると広く認識されていました。^[1]

XNS は、低遅延の LAN 接続に合わせて短いパケット サイズを使用します。これにより、エラー率が低く、ターンアラウンド タイムが短い場合にパフォーマンスが向上します。IDP パケットは、30 バイトの IDPヘッダーを含めて最大 576 バイト長です。^[2]これに対して、IP ではすべてのホストが少なくとも576 バイトをサポートすることを要求しますが、最大 65K バイトのパケットをサポートします。特定のネットワーク上の個々の XNS ホスト ペアは、より大きなパケットを使用することがありますが、それらを処理するために XNS ルーターは必要なく、介在するルーターがより大きなパケットをサポートしているかどうかを検出するメカニズムは定義されていません。また、IP のようにパケットを断片化することはできません。

Pupのゲートウェイ情報プロトコルの後継であるルーティング情報プロトコル（RIP）は、ルーター情報交換システムとして使用されており、（他のプロトコルスイートのアドレス構文と一致するようにわずかに変更されています）インターネットプロトコルスイートなどの他のプロトコルスイートでも現在でも使用されています。^[2]

XNS は、IP のpingに似た、ネットワーク間レイヤーでシンプルな echo プロトコルも実装していますが、ネットワーク スタックのより低いレベルで動作します。ping のように ICMP データを IP パケットのペイロードとして追加する代わりに、XNS の echo はコマンドを基礎となる IDP パケット内に直接配置します。^[2] IP ヘッダーの ICMPプロトコルフィールドを拡張することで、同じことを IP でも実現できます。

主要なトランスポート層プロトコルは 2 つあり、どちらも Pup の前身とは大きく異なります。

• シーケンス パケット プロトコル( SPP ) は、 TCPに類似した 3 ウェイ ハンドシェイクを備えた確認応答トランスポート プロトコルです。主な技術的な違いの 1 つは、シーケンス番号がパケットをカウントするのに対し、TCP や PUP の BSP ではバイトをカウントする点です。これはNovell の IPX/SPXの直接の前身です。
• パケット交換プロトコル( PEP ) は、本質的にUDPに似たコネクションレスの非信頼性プロトコルであり、 Novell のPXPの前身です。

XNSはPupと同様に、パケットのドロップなどの問題を報告するシステムとしてEP （エラープロトコル）を使用します。これにより、問題を探すためにフィルタリングできる独自のパケットセットが提供されます。 ^[2]

オリジナルのゼロックスのコンセプトでは、リモート印刷、ファイリング、メールなどのアプリケーション プロトコルは、Courierというリモート プロシージャ コールプロトコルを採用していました。 Courier には、ゼロックスのMesa プログラミング言語関数呼び出しのほとんどの機能を実装するためのプリミティブが含まれていました。 アプリケーションは、 Courier で関数呼び出しを手動でシリアル化およびデシリアル化する必要がありました。関数アクティベーション フレームを RPC に自動変換する機能はなかった (つまり、「RPC コンパイラ」は利用できなかった)。 Courier はすべてのアプリケーションで使用されていたため、XNS アプリケーション プロトコル ドキュメントでは、 Courier 関数呼び出しインターフェイスと、モジュール + 関数バインディング タプルのみが指定されていました。 Courier には、関数呼び出しでバルク データを送受信できるようにする特別な機能がありました。^[2]

当初、XNSサービスロケーションは、一連の拡張リングブロードキャストを使用したリモートプロシージャコールのブロードキャストによって実行されました（ローカルルータと相談して、距離が増加するネットワークを取得します）。その後、サービスロケーションを実行するためにクリアリングハウスプロトコル3レベルディレクトリサービスが作成され、拡張リングブロードキャストは最初のクリアリングハウスを見つけるためにのみ使用されました。^[2]

基盤技術として Mesa と緊密に統合されているため、従来の高レベル プロトコルの多くは XNS システム自体の一部ではありませんでした。つまり、XNS プロトコルを使用するベンダーはすべて、ファイル共有とプリンターサポート用の独自のソリューションを作成しました。これらのサード パーティ製品の多くは、理論的にはパケット レベルで相互に通信できましたが、互いのアプリケーション サービスを呼び出す機能はほとんどありませんでした。これにより、XNS 市場は完全に断片化され、IP が XNS を簡単に置き換えた理由の 1 つとして挙げられています。^[1]

XNS プロトコルには、認証プロトコルとそれをサポートする認証サービスも含まれていました。その「強力な認証情報」は、後にKerberosで使用されたNeedham-Schroeder プロトコルと同じものに基づいていました。認証サービスに認証情報を取得した後、このプロトコルは Courier プロシージャ呼び出しにデジタル署名する軽量な方法を提供しました。これにより、受信者は署名を検証し、XNS インターネット経由で送信者を認証することができ、プロトコル通信セッションの間、認証サービスに再度アクセスする必要がなくなりました。^[3]

Xerox の印刷言語Interpressは、レーザー プリンターを制御するためのバイナリ形式の標準でした。この言語の設計者である John Warnock と Chuck Geschke は、後に Xerox PARC を離れ、Adobe Systems を設立しました。退職する前に、2 人はバイナリ印刷言語を指定することの難しさに気付きました。バイナリ印刷言語では、印刷ジョブをシリアル化する関数が煩雑で、誤った印刷ジョブのデバッグが困難でした。ASCII でプログラム可能かつ簡単にデバッグできる印刷ジョブを指定することの価値を理解するために、Warnock と Geschke は Adob​​e での最初の製品の 1 つとして Postscript 言語を作成しました。

Xerox の企業イントラネットにある 8000 台以上のマシンはすべて Wildflower アーキテクチャ (Butler Lampson 設計) を実行していたため、マイクロコード用のリモート デバッグ プロトコルがありました。基本的に、ピーク アンド ポーク機能により、地球上のどこにいても C シリーズまたは D シリーズ マシンのマイクロコード状態を停止して操作し、マシンを再起動することができました。

また、ワールドスワップデバッガー用のリモートデバッグプロトコルもありました。^[4] このプロトコルは、デバッガー「nub」を介してワークステーションをフリーズさせ、メモリのさまざまな部分を調べたり、変数を変更したり、実行を継続したりできます。デバッグシンボルが利用可能であれば、クラッシュしたマシンを地球上のどこからでもリモートデバッグできます。

ハーバード大学での最終学年、ボブ・メトカーフはいくつかの企業で面接を受け始め、ゼロックス・パロアルトとなるネットワーク化されたコンピュータワークステーションの開発に着手していたゼロックス・パロアルト研究所のジェリー・エルキンドとボブ・テイラーから温かい歓迎を受けた。彼は論文審査を終えた7月にパロアルト研究所に入所することに同意した。1970年、会議に出席するためにスティーブ・クロッカーの家でカウチサーフィンをしていたとき、メトカーフはテーブルから秋季合同コンピュータ会議の議事録を拾い、読みながら眠ろうと思った。しかし、彼はそれよりも前の広域ネットワークシステムであるALOHAnetに関する記事に魅了された。6月までに彼はネットワークに関する独自の理論を作り上げ、教授たちに発表したが、教授たちはそれを却下し、彼は「追い出された」^{[5] 。}

メトカーフは論文が不成功に終わったにもかかわらずPARCに迎え入れられ、すぐに当時「有線ALOHAnet」と呼ばれていたものの開発を開始した。彼は電子実装を手伝うためにデビッド・ボッグスとチームを組み、1973年末までに3Mbit/sで動作するハードウェアを製作した。その後、2人はシステムで動作する簡単なプロトコルの開発に着手した。これがPARCユニバーサルパケット（Pup）システムの開発につながり、1974年後半までに2人はPupをイーサネット上で正常に動作させた。彼らはこのコンセプトの特許を申請し、メトカーフは言及に値すると考え、他のいくつかの名前も追加した。その後、このコンセプトに関する論文をCommunications of the ACMに提出し、 「イーサネット：ローカルコンピュータネットワーク用の分散パケットスイッチング」と題して1976年7月に出版された。^[5]

PUP が完成するずっと前の 1975 年までに、メトカーフは既にゼロックスの堅苦しい経営陣に苛立ちを感じていた。彼は同社がすぐにイーサネットを生産に投入すべきだと考えたが、上層部はほとんど関心を示さなかった。1974年にMITの有名な人工知能研究所の教授らがゼロックスにイーサネットを購入して自社の研究室で使用したいと持ちかけたことで、画期的な出来事が起こった。ゼロックスの経営陣は、イーサネットは自社の機器を販売するのに使う方がよいと考え、この申し出を断った。その後、AI 研究所は独自のイーサネット バージョンであるChaosnet を作成することになった。^[6]

メトカーフは結局、1975年11月にゼロックスを離れ、シティバンクの高度な製品開発を担当する部門であるトランザクションテクノロジーに移った。しかし、7か月後、ゼロックス内にPARCのコンセプトを市場に投入するためにシステム開発部門を組織したばかりだったデビッド・リドルに誘われてゼロックスに戻った。メトカーフはすぐにイーサネットを20Mbit/sで動作するように再設計し、Pupを製品品質バージョンに書き直す作業を開始した。Pupの支援を求めて、メトカーフは当時スタンフォード大学でヴィント・サーフの指導の下で博士論文を仕上げていたヨゲン・ダラルにアプローチした。ダラルはボブ・カーンのARPANETチーム（TCP/IPに取り組んでいた）からも熱心にリクルートされていたが、サーフがDARPAに移ったため、ダラルはPARCへの異動に同意し、1977年にそこで働き始めた。^[7]

ダラルはウィリアム・クロウザーとハル・マレーを含むチームを結成し、Pup の完全なレビューを開始しました。ダラルは DARPA で進行中の TCP の取り組みにも関与しようとしましたが、最終的には諦めて Pup に完全に集中しました。ダラルは ARPANET での経験と Pup のコンセプトを組み合わせ、1977 年末までにゼロックス ネットワーク システム仕様の最初のドラフトを公開しました。これは基本的に、絶対 48 ビット ホスト ID と、シーケンス パケット プロトコルの TCP の 3 ウェイ ハンドシェイクを備えた Pup のバージョンでした。^[8]

1978 年初頭までに新しいシステムは機能し始めたが、経営陣は依然としてそれを商業化するための動きを見せていなかった。メトカーフは次のように述べている。

1976年にゼロックス社に戻ったとき、製品の出荷まで約2年半あり、1978年にも製品の出荷まで約2年半ありました。^[7]

それ以上の措置が取られなかったため、メトカーフは1978年末に会社を去った。^[7]

XNS は、Xerox がDocuTech 135 Publishing Systemとの通信に最後に使用したプロトコルで、IP の普及により現在は使用されていません。しかし、ソフトウェア ベンダーやハードウェア ベンダーが、コンピューティング プラットフォームが複数のネットワーク プロトコル スタックを同時にサポートする必要性について真剣に検討するきっかけとなり、1980 年代のネットワーク テクノロジの開発に重要な役割を果たしました。

さまざまな独自ネットワーク システムが XNS を直接ベースにしていたか、またはテーマに若干のバリエーションを提供していました。これらの中には、Net/One、3+、^[1]、 Banyan VINES ^[9]、Novell のIPX/SPX などがあります。^[10]これらのシステムは、XNS のアドレス指定およびルーティング システムの上に独自の概念を追加しました。VINES は他のサービスとともにディレクトリ サービスを追加し、Novell NetWare は印刷やファイル共有などのユーザー向けサービスを多数追加しました。AppleTalkはXNS のようなルーティングを使用しましたが、短い番号を使用する互換性のないアドレスがありました。

XNSは、インターネットプロトコルとは大きく異なる2番目のプロトコルスイートを提供することで、4.2BSDネットワークサブシステムの設計の検証にも役立ちました。両方のスタックを同じカーネルに実装することで、バークレーの研究者は、その設計がIP以外にも適していることを実証しました。^{[11]最終的には、}オープンシステム相互接続（OSI）プロトコル の全範囲をサポートするために、BSDの追加変更が必要になりました。

ゼロックス ネットワーク システム アーキテクチャ ゼロックス ネットワーク システム入門(XNSG 058504) は、「ゼロックス ネットワーク システムを使用することで、オフィスの従業員がどのように効率と生産性を高めることができるかを知りたい人向けの一般的な説明です。」^{[12] : p.5}

ゼロックスネットワークシステムアーキテクチャのコンポーネントについては、ゼロックスネットワークシステムアーキテクチャ一般情報マニュアル（XNSG 068504）に簡単に説明されています。^[13]

ゼロックスシステム研究所文献カタログには、16個の個別のプロトコル記述が記載されています。^[12]これらの標準のより新しいバージョンとしては、次のようなものがあります。

• 認証プロトコル（XSIS 098404）^[3]
• バルクデータ転送（Courier の付録 f）、1984 年 4 月（XNSS 038112/XSIS 038112）
• 文字コード標準、1986 年 5 月 (XNSS 058605)
• クリアリングハウス プロトコル、1984 年 4 月 (XNSS 078404/XSIS 078404)
• クリアリングハウスエントリーフォーマット、1984年4月（XNSS 168404/XSIS 168404）^[14]
• クーリエ：リモートプロシージャコールプロトコル、1981年12月（XNSS 038112 / XSIS 038112）^[15]
• イーサネット。ローカルエリアネットワーク：データリンク層および物理層仕様（ブルーブック、バージョン2.0）、1982年11月（XNSS 018211/XSIS 018211）^[16]
• 1986年5月の提出議定書（XNSS 108605）^[17]
• フォント交換標準、1985年12月（XNSS 238512）^[18]
• インターネットトランスポートプロトコル、1981年12月（XNSS 028112/XSIS 028112）^[19]
• インタープレス電子印刷規格、バージョン3.0、1986年1月（XNSS 048601）^[20]
• 印刷サービス統合標準、1985 年 6 月 (XNSS 198506)
• 印刷プロトコル、1984 年 4 月 (XNSS 118404/XSIS 118404)
• ラスター エンコーディング標準、1985 年 6 月 (XNSS 178506)
• 同期ポイントツーポイントプロトコル、1984 年 12 月 (XNSS 158412)
• タイムプロトコル、1984 年 4 月 (XNSS 088404/XSIS 088404)

• プロトコル戦争

• ゼロックス文字コード標準

引用

文献

• ゼロックス ネットワーク システム アーキテクチャ: ゼロックス ネットワーク システムの概要
• Xerox ネットワーク システム アーキテクチャ: 一般情報マニュアル
• カーネル空間での実際の実装例