JPH08507909A

JPH08507909A - ワークステーションを複数個のコンピュータプラットホームにインタフェースする方法および装置

Info

Publication number: JPH08507909A
Application number: JP6516084A
Authority: JP
Inventors: ジョンソン，ロバート・エイ; ホーウィ，サラ・ケイ; スキルトン，ジョナサン・イー
Original assignee: ユニシス・コーポレイション
Priority date: 1992-12-31
Filing date: 1993-12-29
Publication date: 1996-08-20
Also published as: EP0677226A1; WO1994016510A2; US5539736A; US5379296A; WO1994016510A3

Abstract

(57)【要約】ＬＡＮ接続されたワークステーションが、同じ物理的な接続を介して、それぞれのネットワークアーキテクチャを有している複数個のコンピュータプラットホームと同時に通信するのを可能にするインタフェース。インタフェースは、ＬＡＮ接続からデータを受信し、データを調べ、かつ用いられているフォーマットを特定する。特定されたフォーマットに基づいて、インタフェースは、データの適切な宛先を決定し、かつその宛先にデータを送信する。さらに、インタフェースは、（１）メッセージセグメント化およびリアセンブリ、（２）最大パケットサイズのネゴシエーション、ならびに（３）ＬＡＮアドレスの発見、でＸＮＳプロトコルを向上することにより、ＸＮＳソフトウェアを搭載したワークステーションが、ＬＡＮ接続から利用可能な端末エミュレーションプログラムを増大した速度で実行する。

Description

【発明の詳細な説明】ワークステーションを複数個のコンピュータプラットホームにインタフェースする方法および装置発明の分野この発明は、一般にワークステーションが複数個のコンピュータプラットホームと通信するのを可能にするためのインタフェースに関し、より特定的には、ＬＡＮ接続されたワークステーション（LAN-connected workstation）が、それぞれに異なるデータリンクプロトコルを有している複数個のコンピュータプラットホームと同時に通信するのを可能にするためのインタフェースに関する。発明の背景今日の作業環境の益々複雑な情報処理要求は、ユーザが、さまざまなネットワークアーキテクチャを有しているさまざまなコンピュータシステムをアクセスできる、統合デスクトップの概念を含む。異なる計算機システムおよび関連するネットワークアーキテクチャの例は、伝送制御プロトコル／インタネットプロトコル（Transmission Control Protocol/Internet Protocol）（ＴＣＰ／ＩＰ）を用いるＵＮＩＸシステムと、バロースネットワークアーキテクチャ（Burroughs Network Architecture）（ＢＮＡ）を用いるユニシスＡシリーズ（Unisys A-ser ies）システムと、システムネットワークアーキテクチャ（Systems Network Architecture）（ＳＮＡ）を用いるＩＢＭメインフレームとを含む。そのようなネットワーク環境では、さまざまな計算機システムへのユーザのアクセスを透過的にする必要がある。言い換えると、ユーザは、自分の統合デスクトップ（たとえばＰＣ）を再構成する必要なしに、どの計算機システムへのアクセスも有するべきである。たとえばユーザは、Ａシリーズメニュー補助リソース制御（Menu-Assisted Resource Control）（ＭＡＲＣ）セションからＵ６０００Ｅメールに、またはＵＴＳセションから、ネットウェア（NetWare）サーバ上のデータファイルをアクセスしているスプレッドシートに、シームレスに移動しようと思うかもしれない。マイクロソフトウィンドウズ^TM（Microsoft Windows^TM）などのＰＣプラットホームでは、統合デスクトップは現実に存在するものであり、したがってネットワークアーキテクチャのインタオペラビリティは基本的な要求である。明らかに、統合化環境においてすべての計算機システムと通信するための、一貫した戦略および適切なシステムサポートが望ましい。この戦略の一部は、ローカルエリアネットワークを含み得る。ローカルエリアネットワークを介して接続されるワークステーションは、近年益々重要になってきている。なぜなら、それらは、記憶装置、入／出力装置、通信装置などの共通のリソースへの共用アクセスをコンピュータユーザに提供するからである。共通のリソースへのアクセスがローカルエリアネットワークの範囲を超えると、通信サーバまたはリレーがよく用いられる。なぜなら、リソースは同一のプロトコル「スタック」を有するシステムの間だけで共用可能であるからである。したがって、通信サーバは、通信が起こっているネットワーク層に依存して、必要なプロトコル変換を行ない、ネットワーク間（またはプロトコル間）通信を可能にする。リレーが動作し得る、可能なネットワーク層に対する背景として、図１ａは、ＬＡＮ相互接続を説明するための分類を示す。この分類は、ＬＡＮ相互接続装置とＩＳＯ参照モデル層（ISO Reference Model layer）とを対応づける。各装置は、それが情報を１つのネットワークから別のものへ中継する層と対応している。この場合のネットワークという用語は、下位層のＬＡＮセグメント、衛星回線、および地上回線から、上位層のネットワークアーキテクチャ（たとえはＯＳＩおよびＳＮＡ）の範囲にわたる。この分類において、リレーを行なっている層が上位層からの情報を用いないことに注目することが重要である。実際には、異なる上位層プロトコルが同じ下位層リレーを同時に用いることができる。一般に、リレー層が高いほど、リレーにより提供される製品およびプロトコルのセットがより特殊化される。また、オーバヘッドおよび複雑さなどの要因が、上位層の数とともに増大する。リレーは、データリンク層（典型的には２つの下位層、論理リンク制御（ＬＬＣ）および媒体アクセス制御（ＭＡＣ）層を含む）で動作する場合には、一般にブリッジと呼ばれる。ブリッジは、ローカルネットワーク間でパケットを転送する目的のためにデータリンクを接続し、それにより、実質上拡張されたローカルネットワークを形成する。リレーがネットワーク層で動作する場合は、それは一般にルータと呼ばれる。ルータがブリッジと異なるのは、ブリッジが一般に通信端末局に対し透過的に動作し、一方ルータが端末局により明示的にアドレス指定され、ルーチングサービスを必要とするという点である。さらに、リレーがいずれかの上位層で動作する場合は、それは一般にゲートウェイとして知られている。図１ｂは、ソースノードから中間ノード、宛先ノードへの、それぞれのネットワーク層を介するデータフローを図示する。ヘッダ（またはトレーラ）データの追加または除去は、各ネットワーク層で起こるかもしれないデータパケットの変形を示し、こうしてそれを次の層（上であろうと下であろうと）のために準備することが注目される。発明の概要この発明は、ワークステーションが複数個の異なるコンピュータプラットホームと通信するのを可能にする方法および装置において具体化される。ワークステーションは、ローカルエリアネットワーク接続を介してインタフェースプロセッサに結合され、インタフェースプロセッサは、多数のコンピュータプラットホームに結合される。特定のフォーマットのグループの１つを有しているデータは、ワークステーションによりコンピュータプラットホームの１つへ向けて送信されるか、またはコンピュータプラットホームの１つによりワークステーションへ向けて送信される。データはインタフェースプロセッサにより最初に受信される。データにより用いられている特定のフォーマットを最初は知らないインタフェースプロセッサは、そのフォーマットを特定するためにデータを調べる。次にインタフェースプロセッサは、データの宛先を決定し、かつデータを特定された宛先に伝送する。またインタフェースプロセッサは、多数のコンピュータプラットホームが共通の物理リンクを介して多数のワークステーションと通信するのを可能にする。図面の簡単な説明この発明は、添付の図面と関連して読まれると次の詳細な説明から最良に理解される。図１ａは、先行技術のＬＡＮ相互接続の分類を示すブロック図である。図１ｂは、ルータを介する、ソースノードから中間ノード、宛先ノードへのデータパケットのデータフローを図示する、先行技術のブロック図である。図２ａは、この発明とともに用いるのに適切なネットワーク環境を示すネットワーク／プロトコル層のチャートである。図２ｂは、図２ａのチャートに示されるネットワーク／プロトコル層を介する、可能なデータ経路を示す高レベルの機能ブロック図である。図３は、この発明とともに用いるのに適切な、例示的なシステムの機能ブロック図である。図４は、図３に示されるシステムの通信プロセッサ（ＣＰ）および回線モジュールによりサポートされるＬＡＮ局グループ（LAN Station Group）機能の機能ブロック図である。図５は、イーサネット（Ethernet）および８０２／ＣＰＬＡＮのためのフレームフォーマットを比較しかつ対照するデータ構造図である。図６は、さまざまなフレームフォーマットをパージングしかつ特定するための手順の疑似コードである。図７は、図６に示される手順と、ブロードキャストおよびマルチキャストフレームを処理するための手順との動作を示す機能ブロック図である。図８ａは、図３のワークステーションにおいて起こるメッセージセグメント化を示すフローチャート図である。図８ｂは、図３のＣＰにおいて起こるメッセージリアセンブリを示すフローチャート図である。図９は、図３のワークステーションとＣＰとの間で起こる最大パケットサイズの再ネゴシエーションを示すフローチャート図である。図１０ａ−１０ｃは、図３のＣＰにおいて起こるＬＡＮアドレスの発見を示すフローチャート図である。発明の詳細な説明Ｉ．概観この発明のインタフェースの１つの局面は、ワークステーションが、同時に、同じ物理的な接続を介して、それぞれに異なるネットワークアーキテクチャを有している複数個のコンピュータプラットホームと通信するのを可能にする。この発明のインタフェースの別の局面は、ＸＮＳソフトウェアを搭載したワークステーションが、たとえばポーリング／セレクト（Poll/Select）構成に対し、ＬＡＮ接続から利用可能である端末エミュレーションプログラムを増大した速度で実行するのを可能にする。図１ａの一般的な説明に対応する図２ａは、この発明の例示的な実施例によりサポートされる、潜在的なネットワークアーキテクチャ（および関連するネットワーク層）を示す。マルチプロトコルシステムをサポートする能力は、別個のマルチベンダシステムを１つのサイトに統合する要求が増すにつれて、重要になる。最上位層から始めると、さまざまなクライアント（またはネットワークアーキテクチャ）、たとえばＯＳＩ、ＳＮＡおよびＴＣＰ／ＩＰなどが、ＢＮＡバイアスルータ（Bias Router）およびＢＮＡ端末ゲートウェイ（Terminal Ｇateway）とともに提供され得る。クライアント層の下にはデータリンク層がある。データリンク層は、ＴＣＰ／ＩＰ環境を除いて、２つの下位層、媒体アクセス制御（ＭＡＣ）層および論理リンク制御（ＬＬＣ）層に分けられる。図２ａに示されるように、ＬＬＣ層では、ユニシス所有のＣＰＬＡＮ、サービスのクラス（Class of Service）１（ＣＯＳ１）、サービスのクラス２（ＣＯＳ２）、およびゼロックスネットワークシステム（Xerox Network Systems）（ＸＮＳ）とＬＡＮ接続されたワークステーション（ＬＣＷ）との組合せのプロトコルがサポートされる。この層のＣＯＳ１、ＣＯＳ２およびＸＮＳプロトコルは、この技術分野においてよく知られているが、ＬＣＷプロトコルは、新しい。このプロトコルは、ＸＮＳを搭載したワークステーションが、ＢＮＡ端末ゲートウェイを介して他のシステムをアクセスしかつ効果的に利用するのを可能にするために、ＸＮＳプロトコルの拡張を与える、この発明の局面を表わす。簡単に言えば、この拡張は、（１）メッセージセグメント化およびリアセンブリ、（２）最大パケットサイズの再ネゴシエーション、ならびに（３）ＬＡＮパートナーアドレスの発見を与えることを含む。ＸＮＳに対するこの拡張は、以前には遅いデータ通信速度（たとえば９，６００ボー）により制限されていたワークステーションが、はるかに速い速度（たとえばＬＡＮ接続によりサポートされる速度）で端末エミュレーションソフトウェアを実行するのを可能にする。こうして、ワークステーションのファイルサーバ接続が、高速端末移送機構として用いられる。さらに、いくつかの分散型アプリケーションシステムがサポートされる。この拡張は、表３ａ−３ｇを参照してＬＣＷセクションにおいてさらに説明する。再び図２ａを参照すると、ＭＡＣ層では、ユニシス所有のＣＰＬＡＮＭＡＣ、ＩＥＥＥ８０２．３ＭＡＣおよびイーサネットのプロトコルがサポートされる。最後に、最下段において図２ａは、物理層でのすべての接続がキャリア検出多重アクセス／衝突検出（ＣＳＭＡ／ＣＤ）技術を用いて行なわれることを示す。例示的な実施例では、インタフェースをアクセスするのにＣＳＭＡ／ＣＤが用いられるが、ＭＡＣ層のブリッジの補助とともに他の物理層方法を用いることができる。（たとえば、ＩＢＭ８２０９ブリッジと関連して用いられる場合には、トークンリングＬＡＮがサポートされ得る。）上で述べたように、この発明の別の局面は、ワークステーションが、同時に、同じ物理的な接続を介して、さまざまなネットワークアーキテクチャ（たとえばＳＮＡおよびＯＳＩ）によりサポートされるコンピュータプラットホームとシームレスに通信するのを可能にする。図３は、この発明とともに用いるのに適切である、ワークステーション３１０ａ−ｎ、インタフェースまたは通信プロセッサ（ＣＰ）３１２およびメインフレームコンピュータシステム３１４、３１６を含む例示的なシステムを示す機能ブロック図である。ワークステーション３１０ａ−ｎは、インタフェース３１１ａ −ｎを介してＬＡＮ３２０に相互接続される。ＬＡＮ３２０には、回線モジュール（ＬＭ）２５１を介してＣＰ３１２が接続される。次にＣＰ３１２は、回線モジュール３１５により、２つの異なるコンピュータシステム３１４、３１６（たとえばＡシリーズユニシスコンピュータおよびＩＢＭメインフレーム）に接続される。この発明の例示的な実施例では、コンピュータシステム３１４および３１６の各々は、ＬＭ２５１を介してＬＡＮ３２０への別個の接続を有する。この例では、ワークステーション３１０ａが複数個のコンピュータプラットホーム３１４、３１６とシームレスに通信するのを可能にする機能は、ＣＰ３１２にある。コンピュータシステム３１４および３１６の各々は、この例では、別個のデータリンクプロトコルを有する（たとえば、ＩＢＭメインフレームについては、データリンク層は８０２．３／ＣＯＳ２である）。同じ接続を通って、同時に異なるコンピュータプラットホームとシームレスに通信するということは、ワークステーションが、同じ物理的な接続を介して、同時にＡシリーズ３１４（プラットホーム１）およびＩＢＭメインフレーム３１６（プラットホーム２）の両方との通信リンクを保持できることを意味する。これは、ワークステーション上で実行するマルチプロトコルソフトウェアサポートを必要とするかもしれないが、この発明はそれをサポートできる。そのようなソフトウェアサポートの例は、ＤＯＳのためのＯＤＩシェルのためのノベル（Novell）のネットウェアガイド（NetWare guide）に見出される。ワークステーション３１０ａが、同じ接続を介して同時に複数個のコンピュータプラットホームと通信するのを可能にするために、ＣＰ３１２は、どのフォーマットでデータを受信するかを決定する。この決定は、受信されたデータだけに基づいて、すなわち前もっての知識なしに行なわれる。これを達成するために、ＣＰ３１２は、受信されたデータフレームの各々を調べ、かつそのフォーマット（たとえはＣＯＳ１、ＣＯＳ２、ＸＮＳなど）を特定する。検査および特定は、異なるプロトコルのためのフォーマットの違いに基づく。フォーマットが特定されると、ＣＰ３１２は、データフレームから情報を抽出して、データの宛先を決定し、かつこのデータを適切なクライアント（たとえばＳＮＡゲートウェイ、ＢＮＡ端末ゲートウェイ、ＩＰルータなど）に送ることにより、通信リンクを提供する。データ伝送のために用いられるプロトコルと関連する特定のフォーマットを受信し、調べ、かつ特定する、回線モジュール２５１により用いられるプロセスは、図２ｂに示される。これは、図２ａのさまざまなネットワーク層を介するデータフローを説明する、高レベルのデータフロー図である。図２ｂでは、データフレームがネットワークからＣＳＭＡ／ＣＤ回路２５０により最初に受信される。回路２５０がフレームを受信すると、それは回線モジュールプロセッサ（図示せず）に割込む。この割込は、ＭＡＣ受信割込ハンドラ２５２により処理され、これは、回路２５０からフレームを読出し、かつそれを受信フレームハンドラ２５４に送る。受信フレームハンドラ２５４は、フレームをパージングして、そのフォーマットを決定し、かつそれを適切なルーチンに送ってその宛先を決定する。これらのルーチンは、ＣＰＬＡＮルーチン２６０、８０２．２ＣＯＳ１ルーチン２６２、８０２．２ＣＯＳ２ルーチン２６４、イーサネット／ＩＰルーチン２６６およびＸＮＳルーチン２６８である。これらのルーチンの各々は、データフレームをデータリンクパケットに変換し、かつ回線モジュールがパケットをその宛先に伝送することを引起こす。ＣＰＬＡＮパケットについては、この伝送はＢＮＡｖ２バイアスルータ２７０を介し、ＣＯＳ１パケットについてはＯＳＩゲートウェイ２７２を介し、ＣＯＳ２パケットについてはＳＮＡゲートウェイ２７４を介し、イーサネットパケットについてはＩＰルータ２７６を介し、ＸＮＳパケットについてはＸＮＳＢＳＳルーチン２５８またはＸＮＳＬＣＷルーチン２５６のいずれか適切なものを介した端末ゲートウェイ２７８を介する。ＯＳＩ、ＳＮＡおよびＴＣＰ／ＩＰに特に重点を置いた、マルチベンダ、マルチプロトコルシステムの議論は、アール・ジェイ・シプサ（R.J. Cypser）、「協働システムのための通信」（Communications for Cooperating S ystems ）、アディソン・ウェズリー（Addison Wesley）（１９９１年）に見出され、これを引用によりここに援用する。この特徴の実際的な結果は、ＬＡＮ（すなわち統合デスクトップ）により接続されるワークステーションが、各々が異なるネットワークアーキテクチャを有している、多数のベンダからの計算機システムと、同じ物理的な接続を介して、シームレスにかつ同時に通信できることである。こうして、統合デスクトップは、効率的なかつ十分に統合化された処理環境のためのシステムサポートを与える。ＩＩ．実施例の詳細な説明この発明は概観で述べた局面を含み、マルチベンダおよびマルチプロトコル統合ならびに高速（すなわちＬＡＮ速度）端末エミュレーションを可能にする全体ネットワーク統合方式に寄与する。実施例では、この発明を採用する統合された処理環境の主要な構成部分は、ＬＡＮ３２０により接続されたワークステーション３１０ａ−ｎ、ＣＰ３１２（回線モジュール２５１および３１５を含む）、ならびにコンピュータプラットホーム３１４および３１６（図３参照）を含む。この発明のさまざまな局面に対するほとんどの機能はＣＰに備えられているが、この同じ機能が完全にいかなるワークステーションおよび／またはプラットホームにも備えられることが可能であり、またはこれらの間で分配されてもよいことがまた意図される。Ａ．通信プロセッサ（ＣＰ）この発明のさまざまな局面に対し周知の特徴／文脈を与えるのに適した通信プロセッサは、ユニシス社より入手可能なＣＰ２０００である。この発明はまた、ＣＰ２０００に加えられる新しい機能を用いる。ＣＰ３１２には複数の回線モジュール（たとえは２５１および３１５）が含まれる。実施例では、最大７つの回線モジュール（図示せず）が存在できる。図２ｂを参照して前述したように、回線モジュールは、この発明の１つの局面に対し、物理接続（ＣＳＭＡ／ＣＤ）でデータフレームを受信すること、データフレームを調ベフォーマットを識別すること、受信したフレームの宛先を決定すること、および最後に通信リンクにサービスすることを含む、ハードウェアプラットホームを提供する。データフレームは一般的に、ヘッダ（またはトレーラ）情報が加えられた、予め定められた有限サイズのデータのパケットである。さらに、新規のインタフェース機能は、メッセージのセグメント化および再アセンブル、最大パケットサイズのネゴシエート、ならびに相手側ＬＡＮアドレスの発見のための、ＸＮＳＳＰＰソフトウェアに対する拡張を含む。１．回線モジュール回線モジュール（ＬＭ）は、ＣＳＭＡ／ＣＤデータフレームを処理するための、８０２．３互換ハードウェア（８０２．３互換トランシーバを含む）を提供する。さらに、回線モジュールは、同時にアクティブである２つのＬＡＮ接続（メモリ調停を伴うデュアルアクティブ（Dual-Active）ＬＡＮ）を処理することができる。この発明の実施例において、ＬＭは、インテル８２５８６ＬＡＮコプロセッサ（Coprocessor）、８２５０１イーサネットシリアルインタフェース（Eth ernet Serial Interface）、および各アクティブＬＡＮ接続に対し１つずつの２つのバッファを含む。ＬＭ２５１の論理構造は、図２ｂに示される。２．ＬＡＮステーショングループ図４は、ＬＭによりサポートされるものとしてのＬＡＮステーショングループ（Station Group）（ＬＡＮＳＧ）４１０の主要モジュールおよびインタフェースを図示する、機能ブロック図である。ＬＡＮＳＧ４１０は、以下の新規の特徴のサポートを含む。それらは（１）イーサネット規格、（２）ＩＥＥＥ８０２．３（ＭＡＣ）レベル規格、（３）ＩＥＥＥ８０２．２（ＬＬＣ）レベル規格（すなわちＣＯＳ１およびＣＯＳ２）、（４）回線モジュールを介したデュアルアクティブＬＡＮ、（５）ＬＡＮ接続ワークステーション（LAN-Connected Workstations）（ＬＣＷ）、および（６）ブートサービスである。ＬＬＣレベルでは「ＣＬＡＳＳ」という接続属性が用いられ、どのタイプのプロトコルが実行されているかを決定する。この属性は設定可能であり、以前サポートされたユニシス所有ＣＰＬＡＮの規格がデフォルトである。エミュレートされるその他の「ＣＬＡＳＳ」タイプは、以下を含む。ＣＰＬＡＮ−ユニシス所有ＬＡＮステーションＣｌａｓｓ１−８０２ＣＯＳ１ステーションＥｔｈｉｐ−ＴＣＰ／ＩＰのためのイーサネットステーションＸＮＳ８０２−ＬＣＷのためのＸＮＳステーションＸＮＳＢＳＳ−ＢＳＳのためのＸＮＳステーションＣｌａｓｓ２−８０２ＣＯＳ２ステーションＣＰＬＡＮ８０２−ＩＥＥＥ８０２．３互換ＣＰＬＡＮステーションＬＡＮＳＧ４１０は、マルチキャスト／ブロードキャストフレーム、８０２フレーム、イーサネットフレームおよびＣＰＬＡＮフレームを含む共存する異なるタイプのフレームを処理する。イーサネットおよびＣＯＳ１ステーションはコネクションレスであり、したがって同時に異なるいくつかのデバイスと通信できる。したがって、必要なことは、サービスアクセスポイント（Service Access Point）（ＳＡＰ）につき１つのＣＯＳ１ステーション、またはイーサネットタイプにつき１つのイーサネットステーションを同時に構成することのみである。しかしながら、ステーショングループは、同時に２つ以上のＣＰＬＡＮステーション（１接続につき１つのステーション）をサポートできる。しかしながら、この発明の実施例において、ダウンラインロード（Down Line Load）（ＤＬＬ）の目的のため少なくとも１つのＣＰＬＡＮステーションが構成される。ＬＡＮＳＧ４１０は３つの主要構成部分を含む。それらは（１）ステーショングループ制御（Station Group Control）（ＳＧＣ）４１２、（２）フレームハンドラ（Frame Handler）（ＦＨ）２５４、（３）媒体アクセス制御（Medium Access Control）（ＭＡＣ）２５２である。ＦＨ２５４およびＭＡＣ２５２はまた、図２ｂに示される。ＳＧＣ４１２は、リンク層マネージャ（Link Layer Manager）（ＬＬＭ）４２０と、ＬＡＮＳＧ４１０の各構成部分との間にインタフェースを設ける。このインタフェースは、２つのキューｒｓｐ／ｒｐｔおよびｃｍｄを通して実現される。ＦＨ２５４は、受信される入力フレームのタイプ（たとえばイーサネット、ＣＰＬＡＮ、または８０２ＣＯＳ１）、およびフレームの宛先である特定のステーションを決定する。ＦＨ２５４は、ステーションインタフェース機能（Station Interface Function）（ＳＩＦ）４２８を介してネットワーク層エンティティ（Network Layer Entity）（ＮＬＥ）４２４へのインタフェースとなり、宛先ステーションのロケーションを決定する。ＮＬＥ４２４は、以下に述べる発見機能を通してこの情報を与える。上記のように、ＭＡＣ２５２は、媒体４３０（たとえばネットワーク３２０）からのフレームの物理的受信および送信をもたらす。ＦＨ２５４がフレームタイプおよび宛先ステーションを決定する方法は、フレームフォーマット、ソースアドレス、「ＣＬＡＳＳ」属性設定、およびもし存在するならば、宛先サービスアクセスポイント（Destination Service Access Poi nt）（ＤＳＡＰ）に基づく。これらの方法はさらに、フレーム識別部およびステーション識別部においてそれぞれ説明される。表１は、ＬＬＣによりサポートされる異なるフレームタイプを示す。ＣｌａｓｓＩ（ＣＯＳ１）ＬＬＣは、タイプ１のフレームおよび動作のみをサポートし、一方Ｃｌａｓｓ２（ＣＯＳ２）ＬＬＣはタイプ１およびタイプ２の動作両方をサポートすることに注目せねばならない。また、ＣＰＬＡＮはＣｌａｓｓＩＬＬＣである。表２は、表１に記載されたＸＩＤフレームのフォーマットを示す。ａ．フレーム識別ＦＨ２５４において、受信されたフレームはパーシングされ、ＣＰＬＡＮ、ＸＮＳ、イーサネット、ＣＯＳ１およびＣＯＳ２に対するフレームフォーマットおよびフィールド設定の相違を認識することにより識別される。図５は、イーサネットおよび８０２／ＣＰＬＡＮフレームに対するフレームフォーマットを示す。図示のとおり、データリンク層においてイーサネットフレームは、宛先アドレス、ソースアドレスおよびタイプフィールドを含む。イーサネットフレームの残りの部分は、クライアント層情報および４バイトのフレームチェックシーケンスである。対照的に、データリンク層における８０２／ＣＰＬＡＮフレームは、宛先アドレス、ソースアドレスおよび長さフィールドを含む。さらに、これはＬＣＣ層では宛先サービスアクセスポイント（ＤＳＡＰ）、ソースサービスアクセスポイント（Source Service Access Point）（ＳＳＡＰ）および制御フィールドを含む。８０２／ＣＰＬＡＮフレームの残り部分は、クライアント層情報および４バイトのフレームチェックシーケンスである。図５に示されるように、ＦＨ２５４が利用して特定のフレームタイプを識別するフレームフォーマットにはいくつかの違いがある。１つの違いは、タイプフィールドに対する長さフィールドである。前処理方法として、受信したフレームのタイプ／長さフィールドの値はＭＡＣ２５２により回復される。このフィールドは次に、イーサネットフレームとＣＯＳ１またはＣＰＬＡＮフレームとを区別するために使用される。イーサネットフレームに対し、このフィールドは常に１５００よりも大きい。イーサネットタイプフィールドに対する現在の値は以下のとおりである。Ｅｔｈ＿ＩＰ＝＃０８００（２０４８−クライアント層（Cliet Layer）：ＴＣＰ／ＩＰ）Ｅｔｈ＿ＡＲＰ＝＃０８０６（２０５４−クライアント層（Client Layer）：アドレス導出プロトコル（Address Resolution Protocol）ここで、＃ＮＮＮＮは、ＮＮＮＮという数字が１６進表記であることを示す。ＣＯＳ１フレームに対し、このフィールドは１５００よりも小さく、受信したフレームの長さを（バイトで）表わす。ＣＰＬＡＮおよびＣＰＬＡＮ８０２フレームに対し、このフィールドはフレームの長さを含むが、番号なし情報（unnumbered information）（ＵＩ）またはＴＥＳＴフレーム（表１参照）においては、この長さは６０００バイトもの大きさでもよい。加えて、ＣＰＬＡＮフレームは、その他のフレームフォーマットと比較しバイト反転の長さフィールドを含む。ブロードキャストおよびマルチキャストフレームの場合、これらはイーサネット、ＣＯＳ１およびＸＮＳのみにより処理される。フレームのグループアドレスビットがセット（ブロードキャストまたはマルチキャスト）されていれば、イーサネット、ＣＯＳ１またはＸＮＳのいずれかである。もしフレームがＸＮＳフレームであれば、ＭＡＣフィールドに続くフィールドにおける＃ＦＦＦＦのチェックサムを含む。ＸＮＳフレームはイーサネットまたは８０２．３フレームフォーマットのいずれかの上に存在し（図３参照）、そのためＸＮＳフレームは一旦認識されれば、ただちにＸＮＳハンドラに送信される。そうでなければ、タイプ／長さフィールドがチェックされ、フレームがイーサネットまたはＣＯＳ１であるかどうかを決定する。ブロードキャストまたはマルチキャストでないフレームは、上記のように、フォーマット固有の違いにより識別される。図６は、起こり得るフレームフォーマットをその違いに基づき調べて識別するプロセスの擬似コード表現である。このプロセスの第１のステップすなわちステップ６０２は、タイプ／長さフィールドが１５００よりも小さいかどうかを決定する。もしそうであれば、この手順はステップ６１０に分岐し、チェックサムフィールドがチェックされる。ステップ６１０において、もしチェックサムが＃ＦＦＦＦに等しければ、フレームはＸＮＳフレームとして識別され、この手順はステップ６２０に分岐し、終了する。しかしながら、もしステップ６１０においてフレームがＸＮＳフレームとして識別されなければ、手順はステップ６１２に進行する。ステップ６１２において、リモートアドレスリストがチェックされ、フレームのソースのアドレスと一致するものが存在するかどうかを見る。もし一致するものがなければ、手順はステップ６１８に分岐し、フレームをＣＯＳ１として識別し、終了する。もしステップ６１２において一致するものか発見されれば、クラス（Class）属性がチェックされ、ステップ６１４においてフレームがＣＰＬＡＮフレームであるかどうか、またはステップ６１６においてフレームがＣＯＳ２フレームであるかどうかを決定する。ステップ６０２において、もしタイプ／長さフィールドが１５００よりも大きければ、手順はステップ６０４に進行する。ステップ６０４においてもし制御フィールド（Control＿Field）（表１および２参照）が、ＵＩまたはＴＥＳＴに等しくＳＳＡＰ＝ルータ、ＤＳＡＰ＝ルータであれば、フレームはＣＰＬＡＮフレームとして識別され、この手順はステップ６２０に分岐し、終了する。もしステップ６０４の条件が満たされなければ、手順は次にステップ６０６に進行する。ステップ６０６において、もしチェックサム＝＃ＦＦＦＦであれば、フレームはＸＮＳフレームとして識別され、手順は終了する。ステップ６０６において、もしチェックサムが＃ＦＦＦＦに等しくなければ、ステップ６０８においてフレームはイーサネットフレームとして識別され、手順は終了する。イーサネットフレームが、上記のように特定した制御、ＤＳＡＰおよびＳＳＡＰフィールドとまさに一致するデータを含み得る可能性が僅かにあり、したがってＣＰＬＡＮフレームと間違えられる場合もあるため、このアルゴリズムは完全にフェールセーフというわけではないことに注目せねばならない。しかしながら、１５００よりも大きな長さを有するＣＰＬＡＮフレームを受信する可能性があるため、この問題は避けることができない。現在、ＴＣＰ／ＩＰおよびＡＲＰは、これらフィールドの値としてＣＰＬＡＮフレームで使用されるものとは異なる値を使用する。図７は、グループのネットワーク接続にアドレス指定された受信フレーム、または個々の接続にアドレス指定された受信フレームの処理を要約する。図７において、もし受信フレームがグループアドレス指定されていれば、プロセスは左側の決定フロー（ブロードキャスト）に従い、もし受信フレームが個々にアドレス指定されていれば、プロセスは右側の決定フロー（非ブロードキャスト）に従う。グループアドレス指定されたフレームに対し、もしタイプ／長さフィールドが１５００よりも大きく、チェックサムが＃ＦＦＦＦに等しければ、フレームはＸＮＳでありそうでなければイーサネットである。もしタイプ／長さフィールドが１５００よりも小さく、もしチェックサムが＃ＦＦＦＦに等しければ、フレームはＸＮＳとして識別され、そうでなければＣＯＳ１として識別される。図７の右側の決定フロー（非ブロードキャスト）は、個々にアドレス指定されたフレームを識別するための、図６の擬似コードに直接対応する。ｂ．ステーション識別上記の手順により一旦フレームフォーマットが決定されれば、フレームが宛先付けられるステーションは、もしあれば、フレームの宛先アドレスフィールドを用いて識別される。接続指向のステーションに対し、ステーション識別は、受信したフレームにより決定されたユニークなリモートアドレスを用いてステーションを発見することにより達成される。使用されるユニークなリモートアドレスは、ステーション情報ヘッダにストアされたリモートＭＡＣアドレスである。これはハッシュ表の指標となり、一致するステーションを発見するために用いられる。ハッシュ表は、ＣＰに既知である接続指向のステーションのリストである。コネクションレスのＣＯＳ１ステーションに対し、ステーションは、コネクションレスステーションリスト内に保持されるそのサービスアクセスポイント（ＳＡＰ）およびＣＬＡＳＳにより識別される。この発明の実施例においては、コネクションレスイーサネットステーションに対し、リスト内の、一致するＣＬＡＳＳ属性を有する最初のステーションが受信ステーションとして選択される。２つ以上のイーサネットステーションは必要ないためである。しかしながら、２つ以上のイーサネットステーションに対する必要性が生じれば、イーサネットステーションをさらにそのタイプにより識別し得るだろう。ステーションに対するローカルおよびリモートＳＡＰは、オープンステーションダイアログ（Open Station Dialog）（ＯＳＤ）動作を用いて決定される。ＯＳＤは、ＬＡＮステーショングループ内の特定的なＬＡＮステーション（またはデバイス）にコールを確立することにより開始する。この発明の実施例において、ＬＡＮステーションにはいくつかの異なるタイプ、すなわちＣＰＬＡＮステーション、ＣＰＬＡＮ８０２ステーション、イーサネットステーション、ＣＯＳ１ステーション、ＣＯＳ２ステーション、ＸＮＳステーションおよびＢＳＳステーションがある。さらに、ＣＬＡＳＳに指定されたステーション属性が、ＬＬＣレベル（たとえばＯＳＩＮＬＥに対しクラス１）でステーションタイプを決定するのに使用される。一旦宛先が決定されれば、フレームは、図２ｂに示されるように、ＢＮＡｖ２バイアスルータ２７０、ＯＳＩゲートウェイ２７２、ＳＮＡゲートウェイ２７４、ＩＰルータ２７６または端末ゲートウェイ２７８を通して、宛先にルーティングできる。Ｂ．ＬＡＮ−接続ワークステーションこの発明の実施例において、ワークステーションがＣＰ３１２の端末ゲートウェイ２７８（図２ａ、２ｂおよび３参照）と通信するのに使用するプロトコルは、ＸＮＳＳＰＰ標準ソフトウェア（またはノベル版：ＳＰＸ）である。ＸＮＳＳＰＰ標準およびＳＰＸへのプログラム的インタフェースは、この明細書中に引用により援用する以下の文書に述べられる。（１）「ゼロックスシステムズ統合規格（Xerox Systems Integration Standa rd）：インタネットトランスポートプロトコル（Internet Transport Protocols ）」（フォームＸＳＩＳ０２８１１２２）（２）「非同期イベントスケジューラを伴うアドバンストネットウェアインタネットワークパケット交換プロトコル（Advanced NetWare Internetwork Packet Exchange Protocol（IPX）with Asynchronous Event Sch eduler（AES））」（ノベルフォーム１０１−０００２４２−００１）（３）「アドバンストネットウェアシーケンストパケット交換プロトコル（Ad vanced NetWare Sequenced Packet Exchange Protocol）（SPX）」（ノベルフォーム１０１−０００２４３−００１）しかしながら、効果的に動作するためには、ＣＰ端末ゲートウェイは、接続指向で正しい順でのメッセージの配信を保証するステーションにサービスすることが望ましい。ＳＰＸはこれらのサービスの形式を提供するが、付随する制限は、ＬＣＷと称されるＳＰＰ（ＳＰＸとも互換性がある）へのいくつかの強化を行なうことにより克服された。ＬＣＷは、図２ａおよび２ｂに示されるように、ＸＮＳＳＰＰよりも上層のプロトコルで、ワークステーションおよびＣＰ両方において実行する。第１に、よく使用されているほとんどのＰＣＬＡＮアダプタは、送信または受信できるフレームの最大サイズに制限がある。典型的には、ＰＣが単一フレームで転送できる全バイト数は１，４９６バイトである。端末トラヒックには１，９２０バイト以上のメッセージサイズが必要なため、ＬＣＷソフトウェアはＳＰＸを強化し、メッセージをフレームにセグメント化しリンクの反対側でそれらを再アセンブルするようにした。第２に、最大フレームサイズはＰＣによって変化する可能性があり、ＳＰＸにより特定されるデフォルトサイズは僅か５３４バイトであるため、ＰＣとＣＰとの間でＳＰＸ接続がオープンされるとき、ネゴシエーションが発生する。ネゴシエーションの結果は、ＰＣおよびＣＰの両方が、ＰＣが転送できるフレームの最大サイズを知っているということである。第３に、各ＰＣに対しイーサネットアドレスを構成する負担を避けるために、ＬＣＷはＬＡＮアドレスの発見のためのメカニズムを含む。以下に説明されるフレームに対するフォーマットは、表３ａないし３ｇにおいて提示されることに注目されたい。１．セグメント化および再アセンブリ図８ａおよび８ｂを参照すれば、メッセージのセグメント化および再アセンブリのプロセスが示される。図８ａおよび８ｂのフローチャートは、ワークステーションからアプリケーションへの通信のみを示し、したがってアプリケーションからワークステーションへの通信は反対の順序で発生することに注目せねばならない。ＳＰＸおよび／またはＰＣＬＡＮアダプタは、１５１４バイトよりも大きなパケットサイズをサポートしないため、端末データストリームのセグメント化および再アセンブリが実行される。典型的な端末メッセージは、サイズにおいて２５００バイトまでの範囲であり、さらに大きなメッセージサイズを用いたいくつかのアプリケーションを伴う。ＳＰＸはセグメント化サービスを提供しないが、ＳＰＰフレームフォーマットは、アプリケーションによりセグメント化サービスが提供されることを可能とする。ＳＰＰヘッダ内には、接続制御フィールド（たとえば図３ｂ参照）がある。このフィールドは、フレームに関する情報を与えるビットマスクを含む。利用可能なビットの１つは、メッセージ終端（End-of-Message）（ＥＯＭ）ビットである。ＳＰＸはこのビットを使用しないが、ＳＰＸはこのビットをアプリケーションと受け渡しをし、したがってＬＣＷプロトコルはこのビットを使用する。図８ａのステップ８１０において、ワークステーションはメッセージを生成し、このメッセージをＬＣＷに与え、その宛先に転送される。ステップ８１１で、ＬＣＷにおいてメッセージが検査され、最大パケットサイズよりも大きいかどうかを決定する。もしそうであれば、ステップ８１２でＬＣＷは、各々が最大サイズよりも小さなパケットにメッセージをセグメント化するルーチンを呼び出す。ステップ８１４で、ＥＯＭビットは最後のフレームを除いてすべてのフレームにおいてリセットされる。ステップ８１６で、ＬＣＷはＳＰＸ３１１を介してメッセージセグメントをネットワーク３２０へと送る（図３参照）。図８ｂを参照すれば、ステップ８２０において、受信側のパートナーは、上記のようにネットワークからパケットを受信する。ステップ８２２において、ステップ８２４でＥＯＭがセットされたパケットが到着するまで、パケットを再アセンブルする。到着するとステップ８２６で、メッセージは完全であるとみなされ、アプリケーションに配信される。このようにして、ＬＣＷは、ＳＰＸを用いてセグメント化および再アセンブリを行ない、セグメントの送信／受信を行なう。この発明の実施例において、受信側のパートナーは、ワークステーション３１０とＣＰ３１２とのいずれでもあり得るので、アプリケーションはしたがって、コンピュータシステム３１４および３１６のうち一方またはワークステーション３１０でそれぞれ実行中ということになる。２．パケットサイズの再ネゴシエーション図９を参照すれば、最大パケットサイズを再ネゴシエートするプロセスが示される。図９のフローチャートは、再ネゴシエーションがワークステーション３１０ａ−ｎのうちの１つにより開始される場合、またはＣＰ３１２により開始される場合に当てはまることに注意されたい。ＬＣＷ接続のパフォーマンスは、接続のパートナー同志により交換されるパケットのサイズを増大することにより改良可能な場合もある。少なくともＩＰＸ（ＸＮＳＩＤＰのノベル版）に対し、パケットに対する特定のデフォルトサイズは、４２バイトのＳＰＸヘッダを含む５３４バイトである。いくつかのＬＡＮアダプタドライバは１５１４バイト（ＳＰＸヘッダを含む）までのパケットを許容する。パートナーの各々が任意的にネゴシエーション段階を開始してもよい。パートナーのひと（たとえばパートナーＡ）は、ステップ９１０で、ヘッダのデータストリームフィールドに値＃８０を、フレームのデータ部分にパートナーＡによる受信可能な最大サイズパケットを含むシーケンストパケット送信（Send Sequenc ed Packet）要求（セグメントサイズ決定要求、表３ｄ参照）を発行することにより、ネゴシエーション段階を開始する。データは、最初が上位バイトで最後が下位バイトである「ネットワーク順序」で常に提示される。ステップ９１２において、他方のパートナー（パートナーＢ）がこのセグメントサイズ決定要求を受信すると、データストリームフィールドに値＃８１を、および（１）要求されたパケットサイズと（２）送信のためにパートナーＢが構成される最大パケットサイズとのいずれか小さい方を含むシーケンスパケット送信（Send Sequence Packet）要求（セグメントサイズ決定応答、表３ｅ参照）を発行することにより、応答する。ステップ９１４で、パートナーＢは、パートナーＡからセグメントサイズ決定アクノリッジ（Segment Sizing Acknowled gment）（表３ｆ参照）を受信するまでいかなる非制御パケットもパートナーＡに送信してはならない。このアクノリッジは、データストリームフィールドに値＃８２、およびネットワーク順序の最終サイズ（セグメントサイズ決定応答における値よりも小さいかまたは等しい）を伴うデータフレームである。上記のシーケンスは、パートナーＢからパートナーＡに送信されるパケットの最大サイズを決定する。言い換えれば、パートナーは受信するパケットのサイズをネゴシエートしてもよい。いずれかのパートナーもいつでもネゴシエーションを開始できる。他方のパートナーはこのネゴシエーションプロセスの間はデータを送信すべきでない。セグメントサイズ決定応答およびアクノリッジにおいて送信される値は、先行するパケットにおける値よりも小さいかまたはそれに等しい。この発明の実施例において、ＣＰは、ワークステーションが最初に開始しなければパケットサイズネゴシエーションを開始しない。このことが意味するのは、特定のワークステーション３１０ａに対し、このワークステーションがＣＰ３１２との接続のためにパケットサイズの再ネゴシエーションを開始するまで、ＣＰはワークステーション３１０ａへの通信を開始しないであろうということであり、この理由はＣＰ３１２はワークステーションがその能力を伴うようにプログラムされているかどうかを知らないからである。（実際、このことはこの特徴を備えていないワークステーションとの下位互換性を確実なものとする。）しかしながら、もしＣＰがその受信パケットサイズをネゴシエートすれば、ＣＰはＢＮＡ接続のためのＭＡＸＩＮＰＵＴＭＥＳＳＡＧＥＳＩＺＥ（最大入力メッセージサイズ）属性に等しいサイズのパケットが送信されることを要求する。この値は典型的に２５００バイトまたはそれより大きいため、ワークステーションはＩＰＸおよびハードウェアによりサポートされる値を応答する。ワークステーションでのＬＣＷコードは、ＢＸレジスタ内の値＃ＯＤを伴うＩＰＸエントリポイントをコールすることにより、これを決定する。ＩＰＸからのリターンの後、ＡＸレジスタは、サポートされた最大パケットサイズを含む。この機能は、ＩＰＸバージョン３．１以上で利用可能である。３．ＬＡＮパートナーアドレスの発見ＸＮＳＳＰＰ（ノベルＳＰＸ）は、接続確立（Establish Connection）（ＥＣ）フレーム（表３ａ参照）を採用し、２つのパートナー間の接続をオープンする。このことが発生するプロセスは、図１０ａのフローチャートの図に示される。例示のプロセスに対し、ＥＣフレームは、宛先接続Ｉｄ（Destinatio n Connection Id）フイールドが＃ＦＦＦＦにセットされたシステムＳＰＰパケットである。ステップ１０１０でこのようなフレームを受信すると、ステップ１０１２でＳＰＰプロトコルモジュールは、入来ＥＣフレームの宛先ソケットＩＤと一致するソケットＩＤを伴う未解決の、リッスンフォーコネクション（Listen for Connection）（ＬｆＣ）要求に対するチェックを行なう。この発明の実施例では、ＬＣＷプロトコルは宛先およびソースソケットＩＤが等しいことを要求する。ステップ１０１２において、もし一致するＬｆＣが発見されれば、次にステップ１０１４において、パートナーのＬＡＮアドレスが記録され、ＥＣ応答（表３ｃ参照）がＳＰＸによりパートナーに送信される。このようにして接続がオープンされたとみなされる。そうでなければ、制御はステップ１０１０にリターンし、別のフレームが受信されるまで待機する。ＣＰ３１２での発見プロセスは、図１０ｂのフローチャートの図に示される。ステップ１０２０で、もしＲＥＭＯＴＥＡＤＤＲＥＳＳ属性がＣＰ接続において特定されなければ、またはもし０に設定されれば、ＣＰはその接続に対するいかなるＥＣフレームも発行しない。したがって、制御はステップ１０２２にうつり、ここでＣＰ３１２は一致するソケットＩＤを有する入来ＥＣまたは特別ブロードキャストＬＣＷグリーティング（Greeting）フレームのいずれかを待つ。ＬＣＷグリーティングフレーム（表３ａ参照）は、パケットタイプフィールドに＃ＦＥの値を有するＸＮＳＩＤＰ（ノベルＩＰＸ）パケットである。ステップ１０２２で、もしＥＣが受信されれば、次にステップ１０２４でワークステーションが構成されたターゲットＬＡＮアドレスを有すれば、上記のように、ステップ１０２６で接続がオープンする。ステップ１０２４で、もしワークステーションが特定されたターゲットアドレスを有さなければ、しかしステップ１０２８でＣＰが一致するソケットＩＤを有するＬＣＷグリーティングフレームを受信すれば、ステップ１０３０でＣＰはフレームからのソースＬＡＮアドレスを記録し、そのアドレスに戻るＥＣを発行する。パートナーワークステーションは、グリーティグフレームの発行に先行し、ＬｆＣをポストしていなければならない。もしポストしていれば、ステップ１０３２でＥＣ応答はリターンされ、検出され、接続を開く。図１０ｃに示されるように、ワークステーション３１０は、予め構成されたＬＡＮアドレスが不在であればＣＰと異なる行動をする。ステップ１０４０で、ワークステーション３１０が予め構成されたＬＡＮアドレスを有さないと決定するとき、入来ＥＣを待つ代わりに、ステップ１０４２で、ワークステーションＬＣＷコードは、ＬｆＣをポストし、次にＬＣＷグリーティングフレームをブロードキャストすることにより、ＣＰにＥＣの発行を強制しようとする。上記のように、グリーティングフレームはＣＰに対してワークステーションのＬＡＮアドレスを明らかにする。ステップ１０４４で、もしＬＣＷグリーティングフレームに応答してＥＣ要求が受信されなければ、ＣＰ接続はアクティブではない。この場合、ステップ１０４６で、ワークステーションＬＣＷコードは、予め定められたスケジュールに従いブロードキャストグリーティングフレームを再発行する。この発明の実施例において、このスケジュールは１分ごとに一度１秒の間隔で１０個のグリーティングを発行する。ＬＣＷは６バイトのＬＡＮアドレスのみを発見することに注目せねばならない。ＬＣＷは、特定の接続を識別し、パートナーの一致検出を容易にする２バイトのソケットＩＤを発見しない。もしいずれのターゲットＬＡＮアドレスも特定されなければ、これらのパートナーにより使用されるソケットＩＤは、起こり得る不整合な接続を避けるためにネットワーク内においてユニークでなければならないことにまた注目すべきである。４．フロー制御およびメッセージアクノリッジワークステーションのＸＮＳソフトウェア（ノベルのＩＰＸ）はすべてのＳＰＰフレームにおいてアクノリッジ要求（Acknowledgment-Requested）ビットをセットするが、ＣＰはセットしない。処理のオーバヘッドを最小とするために、ＣＰは、１）ＥＯＭビットがセットされるとき、および２）ＣＰＸＮＳソフトウェアがフロー制御割当ウィンドウが満杯であると決定するとき、の２つの状況において、アクノリッジ要求ビットをセットするのみである。このことは、メッセージがセグメント化されたとき、不必要なアクノリッジパケットがメッセージパケットと競合することを防止する。ＣＰは、送信されているフレームのシーケンス番号をパートナーから受信した最後のフレームの割当て番号と比較することにより、割当てウィンドウが満杯であると決定する。割当て番号は、パートナーにより受取られることになる最後のシーケンス番号を識別する。もし送信された最後のシーケンス番号が割当て番号と等しければ、受信側のパートナーが増加された割当て番号を伴うフレームを送信するまで、フレームはこれ以上送信されないであろう。最後のフレームのアクノリッジ要求ビットをセットすることにより、ＣＰはパートナーに、望ましくは増加された割当て番号を含む制御フレームのリターンを強制する。恐らくはアプリケーションが入来フレームを読出すのが遅いため、受信側のパートナーがより大きな数のフレームを割当てることができなければ、ＬＣＷソフトウェアはこの状況を検出し、できる限り早くさらなる割当てが与えられるようにしなければならない。受信側のパートナーは、最後の未解決の、リッスンフォーシーケンストパケット（Listen for Sequenced Packet）ＥＣＢがいつ完了したかに注目することにより、この状況を検出できる。次のリッスンフォーシーケンストパケットにＥＣＢがポストされるとき、受信側のパートナーのＬＣＷコードは、送信側のパートナーに、増加された割当て番号が与えられた割当てグラント（Allocation Grant）フレームを送信しなければならない。以下の３つの論文は、ＸＮＳへのＬＣＷ強化のさまざまな特徴およびその設定について述べており、この明細書中に引用により援用する。それらは、（１）Ｒ．Ａ．ジョンソン（Johnson），「ＢＮＡｖ２を介したＬＡＮ接続ワークステーション，パートＩ（LAN-Connected Workstations Via BNAv2，Part I）」，ユニスフェール（Unisphere），（1992年１月）、（２）Ｒ．Ａ．ジョンソン，「ＢＮＡｖ２を介したＬＡＮ接続ワークステーション，パートII」，ユニスフェール，（1992年２月）、（３）Ｒ．Ａ．ジョンソン，「ＢＮＡｖ２を介したＬＡＮ接続ワークステーション，パートIII」，ユニスフェール,（1992年５月）である。この発明は、実施例に基づいて説明されてきた。しかしながら、この発明は添付の特許請求の範囲内で修正を伴い実施されてもよく、修正のいくつかは上述のとおりであることが意図されている。

【手続補正書】特許法第１８４条の８【提出日】１９９５年１月２０日【補正内容】の要因が、上位層の数とともに増大する。リレーは、データリンク層（典型的には２つの下位層、論理リンク制御（ＬＬＣ）および媒体アクセス制御（ＭＡＣ）層を含む）で動作する場合には、一般にブリッジと呼ばれる。ブリッジは、ローカルネットワーク間でパケットを転送する目的のためにデータリンクを接続し、それにより、実質上拡張されたローカルネットワークを形成する。ブリッジの例はＥＰ−Ａ−Ｏ５０８８８６号に見出される。ＥＰ−Ａ−Ｏ５０８８８６号は、異なるＬＡＮ環境を「ブリッジする」方法および装置を開示する。すなわち、ＥＰ′８８６は、コンピュータネットワーク用語において「ブリッジ」と呼ばれるものを開示する。定義によると、ブリッジ（またはストアアンドフォワード装置）は、ネットワーク通信間のデータリンク層で動作する。さらに、ＥＰ′８８６に記載されるように、開示されたブリッジは、メッセージを別のネットワークに転送する前に、受信されたメッセージの宛先アドレスおよびプロトコルタイプフィールドの両方をスクリーニングすることにより、片方向フィルタとして作用する（欄５、行１３−１６参照）。受信されたメッセージのフォーマットは、ＥＰ′８８６に記載されかつ図２に図示されるように、ブリッジに知られている。ブリッジは、データリンク層より上のデータを処理しないので、既知のデータリンク層フォーマットの既知の宛先アドレスフィールドおよび既知のプロトコルタイプフィールドにストアされた情報を読出すだけである。ＥＰ′８８６のブリッジは、フォーマットを知っているので、プロトコルタイプを調べる前に、宛先アドレスを調べる能力を有する（欄６、行４３−４５参照）。それが動作するデータリンク層のデータフォーマットを知っていることが、ブリッジの動作には必須であるので、フォーマットを知らなければ、ＥＰ′８８６のブリッジは、どこに宛先アドレスが位置するかを知らないであろう。リレーがネットワーク層で動作する場合は、それは一般にルータと呼ばれる。ルータがブリッジと異なるのは、ブリッジが一般に通信端末局に対し透過的に動作し、一方ルータが端末局により明示的にアドレス指定され、ルーチングサービスを必要とするという点である。さらに、リレーがいずれかの上位層で動作する場合は、それは一般にゲートウェイとして知られている。図１ｂは、ソースノードから中間ノード、宛先ノードへの、それぞれのネットワーク層を介するデータフローを図示する。ヘッダ（またはトレーラ）データの追加または除去は、各ネットワーク層で起こるかもしれないデータパケットの変形を示し、こうしてそれを次の層（上であろうと下であろうと）のために準備することか注目される。発明の概要この発明は、ワークステーションが複数個の異なるコンピュータプラットホームと通信するのを可能にする方法および装置において具体化される。ワークステーションは、請求の範囲１．ワークステーション（３１０）が、少なくとも、データリンク層と、データリンク層より少なくとも１レベル上のクライアント層とを有している、それぞれのネットワークアーキテクチャと互換性のある複数個のコンピュータシステム（３１４）と通信するのを可能にする方法であって、前記ワークステーション（３１０）は、インタフェースプロセッサ（３１２）に結合され、かつ前記インタフェースプロセッサ（３１２）は、前記複数個のコンピュータシステム（３１４）に結合され、前記方法は、ａ）それぞれのネットワークアーキテクチャに対応する特定のデータ構造を有しているデータを、前記ワークステーション（３１０）から前記インタフェースプロセッサ（３１２）に前記コンピュータシステム（３１４）の１つを宛先として送信するステップを含み、前記特定のデータ構造は、前記インタフェースプロセッサ（３１２）には未知であり、さらにｂ）前記インタフェースプロセッサ（３１２）で、前記データを調べ、かつ前記データの特定のデータ構造と対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定するステップと、ｃ）ステップｂ）でなされた特定に基づいて、前記データの宛先を決定するステップと、ｄ）前記データを、ステップｃ）で決定された宛先をサービスしている、それぞれのネットワークアーキテクチャのクライアント層と関連するプロセスに配信するステップとを含むことを特徴とする、方法。２．ワークステーション（３１０）か、少なくとも、データリンク層と、データリンク層より少なくとも１レベル上のクライアント層とを有している、それぞれのネットワークアーキテクチャと互換性のある複数個のコンピュータシステム（３１４）と通信するのを可能にするシステムであって、前記ワークステーション（３１０）は、インタフェースプロセッサ（３１２）に結合され、かつ前記インタフェースプロセッサ（３１２）は、前記複数個のコンピュータシステム（３１４）に結合され、前記装置は、それぞれのネットワークアーキテクチャに対応する特定のデータ構造を有しているデータを、前記ワークステーション（３１０）から前記インタフェースプロセッサ（３１２）に前記コンピュータシステム（３１４）の１つを宛先として送信する手段を含み、前記特定のデータ構造は、前記インタフェースプロセッサ（３１２）には未知であり、前記装置はさらに、前記インタフェースプロセッサ（３１２）で、前記データを調べ、かつ前記データの特定のデータ構造と対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定する手段と、調べる手段によりなされた特定に基づいて、前記データの宛先を決定する手段と、前記決定する手段により決定された前記宛先におよび前記宛先から通信をサービスするためのクライアント層手段と、前記データを前記クライアント層手段に配信する手段とを含むことを特徴とする、システム。３．ワークステーション（３１０）が、少なくともデータリンク層およびクライアント層を有している、それぞれのネットワークアーキテクチャと互換性のある複数個のコンピュータシステム（３１４）と通信するのを可能にする方法であって、前記ワークステーション（３１０）は、インタフェースプロセッサ（３１２）に結合され、かつ前記インタフェースプロセッサ（３１２）は、前記複数個のコンピュータシステム（３１４）に結合され、前記方法は、ａ）それぞれのネットワークアーキテクチャに対応するフォーマットを有しているデータを、前記ワークステーション（３１０）から前記インタフェースプロセッサ（３１２）に前記コンピュータシステム（３１４）の１つを宛先として送信するステップを含み、前記フォーマットは、前記インタフェースプロセッサ（３１２）には未知であり、さらにｂ）前記インタフェースプロセッサ（３１２）で、前記データを調べ、かつ前記データのフォーマットと対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定するステップを含み、前記データは、それぞれのネットワークアーキテクチャに依存している、１つのタイプおよび長さを示すフィールド（タイプ／長さフィールド）と、チェックサムフィールドとを含み、ステップｂ）はさらに、ｂ１）タイプ／長さフィールドをバイト反転するステップと、ｂ２）バイト反転されたタイプ／長さフィールドにより表わされる値を調べるステップと、ｂ３）チェックサムフィールドの値を調べるステップと、ｂ４）ステップｂ２）およびステップｂ３）の検査に基づいて、前記データのフォーマットに対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定するステップとを含み、前記方法はさらに、ｃ）ステップｂ）でなされた特定に基づいて、前記データの宛先を決定するステップと、ｄ）ステップｃ）で決定された宛先をサービスしている、それぞれのネットワークアーキテクチャのクライアント層と関連するプロセスに前記データを配信するステップとを含むことを特徴とする、方法。４．ワークステーション（３１０）が、少なくともデータリンク層と、データリンク層より少なくとも１レベル上であるクライアント層とを有している、それぞれのネットワークアーキテクチャと互換性のある複数個のコンピュータシステム（３１４）と通信するのを可能にする方法であって、前記ワークステーション（３１０）は、インタフェースプロセッサ（３１２）に結合され、かつ前記インタフェースプロセッサ（３１２）は、前記複数個のコンピュータシステム（３１４）に結合され、前記方法は、ａ）それぞれのネットワークアーキテクチャに対応する特定のデータ構造を有しているデータを、前記ワークステーション（３１０）から前記インタフェースプロセッサ（３１２）に前記コンピュータシステム（３１４）の１つを宛先として送信するステップを含み、前記特定のデータ構造は、前記インタフェースプロセッサ（３１２）には未知であり、さらにｂ）前記インタフェースプロセッサ（３１２）で、前記データを調べ、かつ前記データの特定のデータ構造と対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定するステップと、ｃ）ステップｂ）でなされた特定に基づいて、前記データの宛先を決定するステップと、ｄ）前記データを、ステップｃ）で決定された宛先にサービスしている、それぞれのネットワークアーキテクチャのクライアント層と関連するプロセスに直接に配信するステップとを含むことを特徴とする、方法。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号庁内整理番号ＦＩＨ０４Ｌ 29/10 9371−5ＫＨ０４Ｌ 13/00 ３０９Ｂ (72)発明者ホーウィ，サラ・ケイアメリカ合衆国、19335 ペンシルバニア州、ダウニングタウン、ワシントン・アベニュ、317 (72)発明者スキルトン，ジョナサン・イーアメリカ合衆国、19401 ペンシルバニア州、ノーリスタウン、ラフター・ロード、 1033

Claims

【特許請求の範囲】１．ワークステーションが、少なくともデータリンク層およびクライアント層を有している、それぞれのネットワークアーキテクチャと互換性のある複数個のコンピュータシステムと通信するのを可能にする方法であって、前記ワークステーションはインタフェースプロセッサに結合され、かつ前記インタフェースプロセッサは前記複数個のコンピュータシステムに結合され、前記方法は、ａ）それぞれのネットワークアーキテクチャに対応するフォーマットを有しているデータを、前記ワークステーションから前記インタフェースプロセッサに前記コンピュータシステムの１つを宛先として送信するステップを含み、前記フォーマットは、前記インタフェエースプロセッサには未知であり、さらにｂ）前記インタフェースプロセッサで、前記データを調べ、かつ前記データのフォーマットと対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定するステップと、ｃ）ステップｂ）でなされた特定に基づいて、前記データの前記宛先を決定するステップと、ｄ）前記データを、ステップｃ）で決定された宛先にサービスしている、それぞれのネットワークアーキテクチャのクライアント層と関連するプロセスに配信するステップとを含む、方法。２．前記データのフォーマットと対応する、それぞれのネットワークアーキテクチャのデータリンク層は、イーサネット、ゼロックスネットワークシステム（ＸＮＳ）、サービスのクラス１（ＣＯＳ１）、サービスのクラス２（ＣＯＳ２）およびＣＰＬＡＮの１つである、請求項１に記載の方法。３．前記データは、それぞれのネットワークアーキテクチャに依存する、１つのタイプおよび長さを示すフィールド（タイプ／長さフィールド）と、チェックサムフィールドとを含み、ステップｂ）はさらに、ｂ１）タイプ／長さフィールドをバイト反転するステップと、ｂ２）バイト反転されたタイプ／長さフィールドにより表わされる値を調べるステップと、ｂ３）チェックサムフィールドの値を調べるステップと、ｂ４）ステップｂ２）およびステップｂ３）の検査に基づいて、前記データのフォーマットと対応する、それぞれのネットワークアーキテクチャのデータリンク層を決定するステップとを含む、請求項１に記載の方法。４．ローカルエリアネットワークＬＡＮ接続によりインタフェースプロセッサに結合された、少なくとも１つのワークステーションと、前記インタフェースプロセッサに結合された、少なくとも１つのコンピュータシステムとを有しているシステムにおいて、前記システムは、ネットワーク通信のためのデータリンク層およびクライアント層を有している、予め定められたネットワークアーキテクチャを含み、メッセージセグメント化およびリアセンブリを与える方法は、ａ）前記１つのワークステーションと前記コンピュータシステムとの間の接続のために特定された、予め定められた最大パケットサイズよりも大きい、多数のデータ値を有しているメッセージを作成するステップを含み、前記システムは、予め定められたネットワークアーキテクチャのデータリンク層でゼロックスネットワークシステム（ＸＮＳ）を用い、さらに、ｂ）メッセージを、各々が予め定められた最大パケットサイズを超えない複数個のパケットにセグメント化するステップと、ｃ）複数個のパケットを前記インタフェースプロセッサに伝送し、かつ複数個のパケットの最後のパケットのメッセージ終端標識を設定するステップと、ｄ）複数個のパケットをインタフェースプロセッサで受信するステップと、ｅ）複数個のパケットの各々が受信されるのに伴なってメッセージを再アセンブルし、かつ各パケットを受信するとメッセージ終端標識を検査するステップと、ｆ）メッセージ終端標識を有しているパケットを受信すると、メッセージのリアセンブリを完了し、かつ再アセンブルされたメッセージを、前記コンピュータシステムにサービスしている、それぞれのネットワークアーキテクチャのクライアント層と関連するプロセスに配信するステップとを含む、方法。５．ローカルエリアネットワークＬＡＮ接続によりインタフェースプロセッサに結合された、少なくとも１つのワークステーションと、前記インタフェースプロセッサに結合された、少なくとも１つのコンピュータシステムとを有しているシステムにおいて、前記システムは、ネットワーク通信のためのデータリンク層およびクライアント層を有している、予め定められたネットワークアーキテクチャを含み、最大パケットサイズのネゴシエーションを与える方法は、ａ）最大パケットサイズのネゴシエーションのために、前記１つのワークステーション、前記インタフェースプロセッサおよび前記１つのコンピュータから通信パートナーに好ましいパケットサイズを示す要求を発行するステップと、ｂ）通信パートナーが動作するように構成された最大パケットサイズと、前記好ましいパケットサイズとのうちの最小のものを示す応答を前記通信パートナーから発行するステップと、ｃ）前記１つのワークステーション、前記インタフェースプロセッサおよび前記１つのコンピュータシステムの１つにより、前記通信パートナーに前記応答に対する確認応答を発行するステップとを含み、前記システムは、予め定められたネットワークアーキテクチャのデータリンク層でゼロックスネットワークシステム（ＸＮＳ）を用いる、方法。６．ローカルエリアネットワーク（ＬＡＮ）接続により通信プロセッサに結合された、少なくとも１つのワークステーションと、前記通信プロセッサに結合された、少なくとも１つのコンピュータシステムとを有しているシステムにおいて、前記１つのワークステーションは、前記通信プロセッサに記録された、予め構成されたＬＡＮアドレスを有しておらず、前記システムは、ネットワークアーキテクチャのデータリンク層でゼロックスネットワークシステム（ＸＮＳ）を用い、前記１つのワークステーションのＬＡＮアドレスの発見を与える方法は、ａ）前記１つのワークステーションが接続を探していることを示すフレーム（ＬｆＣフレーム）をポストするステップと、ｂ）少なくとも１つのワークステーションのＬＡＮアドレスを特定するフレームを、前記１つのワークステーションからＬＡＮ接続を介して前記通信プロセッサにブロードキャストするステップと、ｃ）前記ブロードキャストフレームに応答して、接続確立（ＥＣ）フレームを前記通信プロセッサから前記１つのワークステーションに送信するステップと、ｄ）前記通信プロセッサからの前記ＥＣフレームに応答して、ＥＣフレームを前記１つのワークステーションから前記通信プロセッサに送信するステップと、ｅ）前記通信プロセッサで、前記ワークステーションと前記コンピュータシステムとの間の論理的な接続を開くステップと、ｆ）前記通信プロセッサで、前記ブロードキャストフレームに特定された前記ＬＡＮアドレスを用いて、前記論理的な接続を特定するステップとを含む、方法。７．ローカルエリアネットワーク（ＬＡＮ）接続によりインタフェースプロセッサに結合された、少なくとも１つのワークステーションと、前記インタフェースプロセッサに結合された、少なくとも１つのコンピュータシステムとを有しているシステムにおいて、前記システムは、ネットワーク通信のためのデータリンク層およびクライアント層を有している、予め定められたネットワークアーキテクチャを用い、ＬＡＮ速度で端末エミュレーション特徴を与える方法は、ａ）システムのＬＡＮ接続を通って通信パートナーに伝送されるメッセージをセグメント化するステップを含み、前記システムは、予め定められたネットワークアーキテクチャのデータリンク層でゼロックスネットワークシステム（ＸＮＳ）を用い、さらにｂ）通信パートナーからＬＡＮ接続上で受信されたメッセージを再アセンブルするステップと、ｃ）通信パートナーと最大パケットサイズをネゴシエーションするステップと、ｄ）必要であれば、予め構成されたＬＡＮアドレスを有していず、かつ接続を要求している前記１つのワークステーションのＬＡＮアドレスを発見するステップとを含む、方法。８．ワークステーションが、少なくともデータリンク層およびクライアント層を有している、それぞれのネットワークアーキテクチャと互換性のある複数個のコンピュータシステムと通信するのを可能にするシステムであって、前記ワークステーションはインタフェースプロセッサに結合され、かつ前記インタフェースプロセッサは前記複数個のコンピュータシステムに結合され、前記システムは、それぞれのネットワークアーキテクチャと対応するフォーマットを有しているデータを、前記ワークステーションから前記インタフェースプロセッサに前記コンピュータシステムの１つを宛先として送信する手段を含み、前記フォーマットは、前記インタフェースプロセッサには未知であり、さらに前記インタフェースプロセッサで、前記データを調べ、かつ前記データのフォーマットと対応する、それぞれのネットワークアーキテクチャのデータリンク層を特定する手段と、調べる手段によってなされた特定に基づいて、前記データの前記宛先を決定する手段と、前記決定する手段により決定された前記宛先へのおよび前記宛先からの通信をサービスするためのクライアント層手段と、前記データを前記クライアント層手段に配信する手段とを含む、システム。