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

ゼロックス・ネットワーク・システム (Xerox Network Systems = XNS)は、ゼロックス・ネットワーク・システム・アーキテクチャ(Xerox Network Systems Architecture)の中でゼロックスによって開発されたコンピュータ・ネットワーキング・プロトコルスイート(プロトコル群)である。 XNSは、汎用のネットワーク通信、ネットワーク間のルーティングやパケット配信、(信頼性の高いストリーム)（英語版）やリモート・プロシージャ・コールなどの高レベルの機能を提供した 。 XNSは、OSI(Open Systems Interconnection)参照 ネットワーキングモデルの開発に先行して影響を与え、1980年代のローカルエリア・ネットワーキング設計に大きな影響を与えた。 しかし、それ以前に設計されたTCP/IPにはほとんど影響を与えなかった。

XNS

プロトコルスタック
目的	LAN
開発者	Xerox
導入	1977 年 (46年前) (1977)
派生先	(3+Share), Net/One, IPX/SPX, (VINES)
ハードウェア	Ethernet

XNSは、1980年代初頭にゼロックスPARCの研究を市場に出すことを担当していたゼロックス社のシステム開発部門(Xerox Systems Development Department)によって開発された。 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の物理層は、実は同じ時期にXeroxが開発していたイーサネットのローカルエリア・ネットワーク・システムであり、その設計上の決定事項の多くはその事実を反映している^[1]。 このシステムは、イーサネットを他のシステムに置き換えることができるように設計されていたが、そこにはプロトコルでは定義されていなかったし、定義する必要もなかった。

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

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

基本的なネットワーク間接続プロトコル

主なインターネットワーク層のプロトコルは、 インターネット・データグラム・プロトコル (Internet Datagram Protocol=IDP)である。 IDPがPupのインターネットワーク・プロトコルの近い末裔で、インターネット・プロトコル・スイートのインターネットプロトコル(Internet Protocol=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のようにパケットを断片化することはできない。

ルーティング・インフォメーション・プロトコル (Routing Information Protocol=RIP)は、Pupのゲートウェイ・インフォメーション・プロトコルの子孫で、ルーター情報交換システムとして使用され、(他のプロトコルスイートのアドレスの構文と一致するように少し修正されている) 今日でもインターネット・プロトコル・スイートなど他のプロトコルスイートで使用されている^[2]。

XNSはまた、IPのpingと同様に、ネットワークスタックの下位レベルで動作する、インターネットワーク層での単純なエコー・プロトコルを実装している。 pingのように、IPパケットのペイロードとしてICMPデータを追加する代わりに、XNSのエコーはコマンドを直接IDPパケット内に配置した^[2]。 IPにおいても、IPヘッダのICMPプロトコルフィールドを拡張することで、同じことが実現できる可能性はある。

トランスポート層プロトコル

トランスポート層プロトコルには2つの主要なものがあり、どちらもPupの前身とは異なる:

• シーケンスパケットプロトコル (Sequenced Packet Protocol=SPP) は、TCPに類似した定評あるトランスポートプロトコルである。主な技術的な違いは、シーケンス番号がTCPやPupのBSPのようにバイトではなく、パケットをカウントするという点で、Novellの IPX/SPX の直接の前身である。
• パケット交換プロトコル (Packet Exchange Protocol=PEP)は、UDPと似た性質を持つコネクションレスの信頼できないプロトコルで、Novell のPXPの前身となっている。

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

アプリケーションプロトコル

クーリエRPC

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

当初、XNSサービスロケーションは、一連の拡張リングブロードキャストを使用したリモートプロシージャコールのブロードキャストを介して実行することで取得された (ローカルルーターと協議して、より遠くのネットワークを取得するため)。その後、サービスロケーションをより遠くに取得するために、クリアリングハウス・プロトコル3レベルのディレクトリサービスが作成され、拡張リングブロードキャストは、初期のクリアリングハウスの位置を特定するためにのみ使用された^[2]。

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

認証

XNSプロトコルには、認証プロトコルとそれをサポートする認証サービスも含まれていた。 その「厳密な資格情報」(Strong credentials)は、後でKerberosで使用されたものと同じNeedham–Schroederプロトコルに基づいてた。このプロトコルは、認証サービスに資格証明のために接続した後、クーリエプロシージャコールの呼び出しにデジタル署名するための軽量な方法を提供し、それにより、受信者は、プロトコルの通信セッションの長さのために再び認証サービスに接続することなく、XNSインターネット上で署名を検証し、送信者を認証することができた^[3]。

印刷

ゼロックス社の印刷言語Interpressは、レーザープリンタを制御するためのバイナリ形式の標準である。 この言語の設計者であるジョン・ワーノック(John Warnock)とチャールズ・ゲシキ(Chuck Geschke)は、後にゼロックスPARCを離れてAdobe Systemsを設立した。 彼らは退職する前に、印刷ジョブをシリアル化する関数が煩雑で、誤った印刷ジョブをデバッグするのが困難なバイナリ印刷言語を特定することの難しさに気づいていた。 プログラム可能でデバッグが容易な印刷ジョブをASCIIで指定することの価値を理解するために、ワーノックとゲシキはAdobeでの最初の製品の1つとしてPostscript言語を作成した。

リモートデバッグプロトコル

ゼロックス社の社内イントラネット内にある8000台以上のマシンはすべてワイルドフラワー(Wildflower)アーキテクチャ(バトラー・ランプソン(Butler Lampson)が設計)を実行したため、マイクロコード用のリモートデバッグプロトコルが存在していた。 基本的には、マシンのメモリを覗いたり突いたりする機能により、地球上のどこにいてCシリーズまたはDシリーズマシンのマイクロコードの状態を停止して操作し、その後マシンを再起動することができた。

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

歴史

イーサネットとPUPの起源

ハーバード大学最終学年のボブ・メトカーフ(Bob Metcalfe)は、いくつかの企業の面接を受け、ゼロックスPARCの(ジェリー・エルカイド(Jerry Elkind))（英語版）とボブ・テイラー(Bob Taylor)に温かく迎えられ、ゼロックスAltoとなるネットワーク化されたコンピュータ・ワークステーションの開発に着手した。 彼は7月に卒論を終えた後、PARCへの入社を承諾した。 1970年、会議に出席していたスティーブ・クロッカー(Steve Crocker)の家で(カウチ・サーフィン)（英語版）をしていたメトカーフは、「Proceedings of the Fall Joint Computer Conference」を手に取り、読んでいるうちに眠りにつこうとした。 その代わりに、彼は初期の広域ネットワークシステムであるALOHAnetの記事に魅了された。 6月までには、彼はネットワーキングに関する独自の理論を開発し、教授に提示したが、教授はそれを拒否し「私の尻を叩いた」^[5]。

メトカーフは論文に失敗したにも関わらずPARCで歓迎され、すぐに当初「ALOHAnet in a wire」と呼ばれていたものの開発を開始した。彼はデビッド・ボグスとチームを組み、電子的な実装を助け、1973年の終わりには3Mbit/sで動作するハードウェアを構築していた。 2人はその後、システム上で実行されるシンプルなプロトコルに取り組み始めた。 これが(PARC Universal Packet)（英語版） (Pup) システムの開発につながり、1974年末にはPupのイーサネット上での動作に成功した。 彼らはこのコンセプトに関する特許を申請し、メトカーフは言及に値すると考えて他の名前をいくつか付け加え、そのコンセプトに関する論文をCommunications of the ACMに「イーサネット：ローカルコンピュータネットワークの分散パケットスイッチング」の論文を提出した^[5]。

PUPからXNSへ

Pupが完了するずっと前の1975年までに、メトカーフはすでにゼロックスの厳しい経営陣の下で苛立っていた。 メトカーフは会社がすぐにイーサネットを生産すべきだと考えていたが、上層部の間でほとんど関心を示さなかった。 1974年、マサチューセッツ工科大学(MIT)の有名な人工知能研究所(AIラボ)の教授たちが、研究室で使用するためにイーサネットを購入したいとゼロックスに打診したことがきっかけで、重要な出来事が起こった。 ゼロックスの経営陣は、イーサネットは自社の機器の販売するために使用する方が良いと考え、拒否した。 AIラボはその後、独自のバージョンのイーサネットである(Chaosnet)（英語版）を作ることになった^[6]。

メトカーフは最終的に1975年11月にゼロックスを退社し、シティバンクの先進的な製品開発を担当する部門であるトランザクションテクノロジに就職した。しかし、その7か月後に彼がゼロックスに戻ってきたのは、PARCのコンセプトを市場に投入するためにゼロックス内にシステム開発部門を組織したばかりの(デビッド・リドル(David Liddle))（英語版）によるものであった。 メトカーフはすぐにイーサネットを20Mbit/sで動作するように設計し直し、Pupを製品品質のバージョンに書き換える努力を始めた。 メトカーフはPupの助けを求めて、当時スタンフォード大学のヴィントン・サーフ(Vint Cerf)の下で論文を書き終えていたヨギン・ダラル(Yogin Dalal) (英語版) に声をかけた。 ダラルはまた、ボブ・カーン(Bob Kahn)のARPANETチーム (TCP/IPの研究をしていた)にも激しく勧誘されていたが、サーフがDARPAに移籍したため、ダラルはPARCに移ることに同意し、1977年にPARCで働き始めた^[7]。

ダラルは、(ウィリアム・クロウザー(William Crowther))（英語版）とハル・マレー(Hal Murray)を含むチームを作り、Pupの全面的な見直しから始めた。 ダラルは、DARPAで進められていたTCPの取り組みに関与しようとしたが、最終的には断念し、Pupに専念した。 ダラルはARPANETでの経験とPupのコンセプトと組み合わせ、1977年末にはXerox Network Systemの仕様書の最初のドラフトを発表した。 これは基本的には、Pupにソケットとインターネット・ネットワークの概念を加えたバージョンで、ルーターが接続されたネットワーク間でパケットを転送できるようになっていた^[8]。

1978年初頭までには、新しいシステムは機能してたが、経営陣はまだそれを商業化するための動きをしていなかった。 メトカーフはこう語っている:

私が1976年にゼロックスに戻ったときには、製品出荷から約2年半、1978年には製品出荷から約2年半が経過していた^[7]。

それ以上の行動が見られなくなったとき、メトカーフは1978年末に会社を退職した^[7]。

影響

ゼロックスがDocuTech 135 Publishing Systemとの通信に使用していたXNSは、IPの普及により、現在では使用されなていない。 しかし、XNSは1980年代のネットワーキング技術の発展において重要な役割を果たし、ソフトウェアとハードウェアのベンダーが2つ以上のネットワークプロトコルスタックを同時にサポートするコンピューティングプラットフォームの必要性を真剣に検討するように影響を与えた。

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

XNSはまた、インターネットプロトコルとは大きく異なる第二のプロトコル群を提供することで、 4.2BSDネットワークサブシステムの設計を検証するのにも役立った。 同じカーネルに両方のスタックを実装することで、(バークレーの研究者)（英語版）たちは、デザインが単なるIP以上のものに適していることを証明した^[11]。 オープンシステム相互接続(OSI参照モデル)プロトコルの全範囲をサポートするために、BSDの追加の修正が最終的に必要となった。

参照

• プロトコル戦争

• Xerox Character Code Standard(XCCS)

参考文献

引用

1. ^ ^{a b c d e f g h} Stephens 1989, p. 15.
2. ^ ^{a b c d e f g} cisco.
3. ^ “Xerox System Integration Standard 098404 - Authentication Protocol”. Xerox Corporation (1984年). 2020年11月6日閲覧。
4. ^ “World-stop debuggers” (1999年1月25日). 2013年7月5日閲覧。
5. ^ ^{a b} Pelkey, 6.7.
6. ^ Pelkey, 6.8.
7. ^ ^{a b c} Pelkey, 6.9.
8. ^ Pelkey, 6.10.
9. ^ Banyan VINES, cisco
10. ^ NetWare Protocols, cisco
11. ^ Larus (1983年). “On the performance of Courier Remote Procedure Calls under 4.1c BSD”. UC Berkeley ECE Department. 2013年7月5日閲覧。

参考文献

外部リンク

• (Xeroxネットワークシステムアーキテクチャ：XNS概要)
• Xeroxネットワークシステムアーキテクチャ：概説書
• カーネル空間での実際の実装例