(57)【特許請求の範囲】
【請求項１】
ヘッダ圧縮／圧縮解除をサポートする１個または複数のデータ端末装置（ＤＴＥ）と、ヘッダ圧縮／圧縮解除をサポートしない１個または複数のデータ端末装置（ＤＴＥ）とを含み、各データ端末装置（ＤＴＥ）がプロセッサとメモリとプログラム命令とを含むコンピュータ・システムであり、通信ネットワーク内のローカル位置にあるローカルＤＴＥと遠隔地にある遠隔ＤＴＥとの間で所定の通信プロトコルを用いて通信を行うためヘッダ圧縮／圧縮解除を使用する方法において、
ネットワーク・リンクを介してローカルＤＴＥから出された、遠隔ＤＴＥに対する第１のコール要求を開始するステップと、
前記ローカルＤＴＥがヘッダ圧縮／圧縮解除を使用する能力を有することを示す、前記第１コール要求に関連する特定プロトコル識別子（ＰＩＤ）を割り当てるステップと、
前記遠隔ＤＴＥがヘッダ圧縮／圧縮解除をサポートするように適合されているかどうかを示すメッセージを、前記遠隔ＤＴＥにより前記ローカルＤＴＥに返すステップと、
前記遠隔ＤＴＥから返されたメッセージにしたがって前記ローカルＤＴＥ内の経路指定テーブルを更新して、前記遠隔ＤＴＥが前記ヘッダ圧縮／圧縮解除をサポートできる能力を有しているか否かを示すようにするステップと、
前記遠隔ＤＴＥが前記ヘッダ圧縮／圧縮解除をサポートできることを前記遠隔ＤＴＥが示す場合に、前記ネットワーク・リンクにおいて前記ヘッダ圧縮／圧縮解除を使用するステップと
を含むことを特徴とする、前記プログラム命令によって実施される、ヘッダ圧縮／圧縮解除を使用する方法。
【請求項２】
ヘッダ圧縮／圧縮解除がサポートされないことを前記遠隔ＤＴＥが示す場合に、前記ローカルＤＴＥが前記特定ＰＩＤを、標準の非圧縮ヘッダが使用されることを示す標準ＰＩＤに変更するステップと、
前記遠隔ＤＴＥに前記標準ＰＩＤを含む第２のコール要求を伝送するステップと、
前記遠隔ＤＴＥが標準の非圧縮ヘッダを受諾することを示すメッセージを、前記遠隔ＤＴＥが前記ローカルＤＴＥに返すステップと、
前記ローカルＤＴＥと前記遠隔ＤＴＥの間での通信のために、前記ネットワーク・リンクにおけるヘッダ圧縮なしに前記通信プロトコルを使用するステップと
をさらに含む請求項１に記載された方法。
【請求項３】
Ｘ.２５パケット交換リンクを使用し、ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートする１個または複数のデータ端末装置（ＤＴＥ）と、ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートしない１個または複数のデータ端末装置（ＤＴＥ）とを含み、各データ端末装置（ＤＴＥ）がプロセッサとメモリとプログラム命令とを含むコンピュータ・システムであり、ＴＣＰ／ＩＰ通信プロトコルを用いて通信ネットワーク内のローカル位置にあるローカルＤＴＥと遠隔地にある遠隔ＤＴＥとの間で通信を行うためＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用する方法において、
ＴＣＰ／ＩＰ／ Ｘ.２５ネットワーク・リンクを介してローカルＤＴＥから出された、遠隔ＤＴＥに対する第１のコール要求を開始するステップと、
前記ローカルＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用していることを示す特定プロトコル識別子（ＰＩＤ）を、前記第１コール要求を含むコール要求パケットのユーザ・データ・フィールド内で使用するステップと、
前記遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするように適合されているかどうかを示すメッセージを、前記遠隔ＤＴＥにより前記ローカルＤＴＥに返すステップと、
前記遠隔ＤＴＥから返されたメッセージにしたがって前記ローカルＤＴＥ内の経路指定テーブルを更新して、前記遠隔ＤＴＥが前記ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートできる能力を有しているか否かを示すようにするステップと、
前記遠隔ＤＴＥが前記ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートできることを前記遠隔ＤＴＥが示す場合に、前記ＴＣＰ／ＩＰ／ Ｘ.２５ネットワーク・リンクにおいて前記ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用するステップと
を含むことを特徴とする、前記プログラム命令によって実施される、ヘッダ圧縮／圧縮解除を使用する方法。
【請求項４】
ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除がサポートされないことを前記遠隔ＤＴＥが示す場合に、前記ローカルＤＴＥが前記特定ＰＩＤを、標準のＴＣＰ／ＩＰ非圧縮ヘッダが使用されることを示す標準ＰＩＤに変更するステップと、
前記遠隔ＤＴＥに前記標準ＰＩＤを含む第２のコール要求を伝送するステップと、
前記遠隔ＤＴＥが標準のＴＣＰ／ＩＰ非圧縮ヘッダを受諾することを示すメッセージを、前記遠隔ＤＴＥが前記ローカルＤＴＥに返すステップと、
前記ローカルＤＴＥと前記遠隔ＤＴＥの間での通信のために、前記ＴＣＰ／ＩＰ／ Ｘ.２５ネットワーク・リンクにおけるヘッダ圧縮なしに前記ＴＣＰ／ＩＰ通信プロトコルを使用するステップと
をさらに含む請求項３に記載された方法。
【請求項５】
前記ローカルＤＴＥ内の経路指定テーブルを、前記遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするか否かを示す特定指標値で更新するステップをさらに含み、前記特定指標値が前記第１コール要求の送信前にシステム管理者によって設定可能であり、前記第１コール要求に応答して前記遠隔ＤＴＥから前記メッセージが戻された結果として前記ローカルＤＴＥによって前記特定指標値が設定可能であることを特徴とする請求項３に記載の方法。
【請求項６】
メッセージ・ヘッダ圧縮／圧縮解除の使用をサポートできる１個または複数のデータ端末装置（ＤＴＥ）とメッセージ・ヘッダ圧縮／圧縮解除の使用をサポートできない１個または複数のデータ端末装置（ＤＴＥ）とを備えるネットワーク・リンクを備えた遠隔通信システムにおいて、
プロセッサとメモリと前記メモリ内のプログラムとを備え、前記プログラムが通信を制御するための命令を含む、ローカル位置にあるローカルＤＴＥと、
前記ネットワーク・リンクを介して前記ローカルＤＴＥに接続された遠隔位置にある遠隔ＤＴＥと、
前記ネットワーク・リンクを介して前記遠隔ＤＴＥに第１のコール要求を伝送し、その第１コール要求が、特定プロトコル識別子（ＰＩＤ）を含み、その特定ＰＩＤが、前記ローカルＤＴＥがメッセージ・ヘッダ圧縮／圧縮解除の使用をサポートすることを示す、前記ローカルＤＴＥ内の第１の装置と、
前記第１コール要求中のＰＩＤを認識し、かつ前記遠隔ＤＴＥが前記メッセージ・ヘッダ圧縮／圧縮解除をサポートしているか否かを示すメッセージで前記ローカルＤＴＥに応答する前記遠隔ＤＴＥ内の第２の装置と
前記遠隔ＤＴＥから応答されたメッセージにしたがって前記ローカルＤＴＥ内の経路指定テーブルを更新して、前記遠隔ＤＴＥが前記ヘッダ圧縮／圧縮解除をサポートできる能力を有しているか否かを示すようにする更新手段と、
を備える遠隔通信システム。
【請求項７】
ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除の使用をサポートできる１個または複数のデータ端末装置（ＤＴＥ）とＴＣＰ／ＩＰヘッダ圧縮／圧縮解除の使用をサポートできない１個または複数のデータ端末装置（ＤＴＥ）とを備えるＴＣＰ／ＩＰ／ Ｘ.２５ネットワーク・リンクを備えた遠隔通信システムにおいて、
プロセッサとメモリと前記メモリ内のプログラムとを備え、前記プログラムが通信を制御するための命令を含む、ローカル位置にあるローカルＤＴＥと、
前記ネットワーク・リンクを介して前記ローカルＤＴＥに接続可能な遠隔位置にある遠隔ＤＴＥと、
前記ＴＣＰ／ＩＰ／ Ｘ.２５ネットワーク・リンクを介して前記遠隔ＤＴＥに第１のコール要求を伝送し、前記第１コール要求が、特定プロトコル識別子（ＰＩＤ）を含み、前記ローカルＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除の使用をサポートすることを前記特定ＰＩＤが示す、前記ローカルＤＴＥ内の第１の装置と、
前記第１コール要求中のＰＩＤを認識することができ、かつ前記遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするか否かを示すメッセージで前記ローカルＤＴＥに応答する前記遠隔ＤＴＥ内の第２の装置と
前記遠隔ＤＴＥから返されたメッセージにしたがって前記ローカルＤＴＥ内の経路指定テーブルを更新して、前記遠隔ＤＴＥが前記ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートできる能力を有しているか否かを示すようにする更新手段と、
を備える遠隔通信システム。
【請求項８】
プロセッサとメモリと前記メモリ内のプログラムとを含み、前記プログラムが通信を制御するための命令を含む、ローカル位置にあるローカル・データ端末装置（ＤＴＥ）において、
メッセージ・ヘッダ圧縮／圧縮解除の使用をサポートできる１個または複数のＤＴＥとメッセージ・ヘッダ圧縮／圧縮解除の使用をサポートできない１個または複数のＤＴＥとを備えるネットワーク・リンクを介して、前記ローカルＤＴＥから遠隔位置にある遠隔・データ端末装置（ＤＴＥ）に第１のコール要求を伝送することができ、前記第１コール要求が特定プロトコル識別子（ＰＩＤ）を含み、前記特定ＰＩＤが、前記ローカルＤＴＥがメッセージ・ヘッダ圧縮／圧縮解除の使用をサポートすることを示している、前記ローカルＤＴＥ内の第１の装置と、
前記遠隔ＤＴＥが前記メッセージ・ヘッダ圧縮／圧縮解除をサポートするか否かを示す、前記遠隔ＤＴＥからのメッセージを認識することができる、前記ローカルＤＴＥ内の第２の装置と
前記遠隔ＤＴＥから返されたメッセージにしたがって前記ローカルＤＴＥ内の経路指定テーブルを更新して、前記遠隔ＤＴＥが前記ヘッダ圧縮／圧縮解除をサポートできる能力を有しているか否かを示すようにする更新手段と、
を備えるローカル・データ端末装置（ＤＴＥ）。
【請求項９】
プロセッサとメモリと前記メモリ内のプログラムとを含み、前記プログラムが通信を制御するための命令を含む、ローカル位置にあるローカル・データ端末装置（ＤＴＥ）であって、
ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除の使用をサポートできる１個または複数のＤＴＥとＴＣＰ／ＩＰヘッダ圧縮／圧縮解除の使用をサポートできない１個または複数のＤＴＥとを備えるＴＣＰ／ＩＰ／ Ｘ.２５ネットワーク・リンクを介して、前記ローカルＤＴＥから遠隔位置にある遠隔・データ端末装置（ＤＴＥ）に第１のコール要求を伝送することができ、前記第１コール要求が特定プロトコル識別子（ＰＩＤ）を含むことができ、前記特定ＰＩＤが、前記ローカルＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除の使用をサポートすることを示している、前記ローカルＤＴＥ内の第１の装置と、
前記遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするか否かを示す、前記遠隔ＤＴＥからのメッセージを認識することができる、前記ローカルＤＴＥ内の第２の装置と
前記遠隔ＤＴＥから返されたメッセージにしたがって前記ローカルＤＴＥ内の経路指定テーブルを更新して、前記遠隔ＤＴＥが前記ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートできる能力を有しているか否かを示すようにする更新手段と、
を備えるローカル・データ端末装置（ＤＴＥ）。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ通信ネットワークの分野に関し、より詳細には、パケット交換ネットワークの制御に  Ｘ．２５プロトコルを使用するネットワークを介するメッセージの伝送効率を高めるための改良型装置および方法に関する。
【０００２】
【従来の技術】
コンピュータ間通信ネットワークが次第に大型化してきており、このネットワーク上でのメッセージ・トラフィックが指数関数的に増大している。したがって、こうしたネットワーク上でのメッセージ伝送をできるだけ効率的にすることが望ましい。
【０００３】
これまで、ローカル・エリア・ネットワーク（ＬＡＮ）を介してデータを伝送する際に必要なオーバヘッドを制御する専用プロトコルを開発し、所与のタイプのネットワークに固有の何らかの特徴を利用して、所与の通信セッションにおけるメッセージのオーバーヘッドを最小限に抑えようとする試みが行われてきた。メッセージ・オーバーヘッドとは、メッセージのデータ部分に付加されるヘッダ情報のことである。こうしたヘッダ情報は、コンピュータ間でデータを送信するのに必要な管理タスクおよび手順タスクをネットワークの様々な部分で追跡できるようにするために必要である。オーバーヘッドの効率を見る１つの尺度は、データとデータ＋ヘッダの比率である。すなわち、必要なヘッダ情報の量が少なくてすむほど、ネットワーク・プロトコルの効率は高くなる。プロトコルの効率を高めるための１つの試みは、Ｖ．Ｊａｃｏｂｓｏｎの”ＣｏｍｐｒｅｓｓｉｎｇＴＣＰ／ＩＰ  Ｈｅａｄｅｒｓ  ｆｏｒ  Ｌｏｗ−Ｓｐｅｅｄ  ＳｅｒｉａｌＬｉｎｋｓ，”Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ：１１４４、１９９０年２月（以下では、「Ｖａｎ  Ｊａｃｏｂｓｏｎ論文」または「ＲＦＣ１１４４」と称する）に概述されるヘッダ圧縮方法である。この論文全体を参照により本明細書に合体する。ＴＣＰ／ＩＰは異種コンピュータ間の通信を扱う１組のプロトコルである、伝送制御プロトコル／インターネット・プロトコルの頭字語である。ＴＣＰは、伝送すべきメッセージをデータグラム（単一メッセージとして送られるデータの集合体）に分解し、通信ネットワークの他端で再組立てし、失われたものがあれば再送信し、正しい順序に戻す責任を負う。ＩＰは、個々のデータグラムの経路指定を行う責任を負う。ＴＣＰは単に宛先付きのデータグラムをＩＰに渡す。ＩＰは、このデータグラムがその前または後のデータグラムとどんな関係があるのか知らない。発信元ポート番号、宛先ポート番号、データグラム連続番号、チェックサム、その他の制御データなどの詳細を追跡するため、ＴＣＰは各データグラムにヘッダを付加し、ヘッダ＋データグラムの組合せをＩＰに渡す。次にＩＰはこの「ＴＣＰヘッダ＋データグラム」に自分のヘッダを付加し、したがって得られるデータ・パケットは、「ＩＰヘッダ＋ＴＣＰヘッダ＋データグラム」のようになる。アプリケーションが、ｔｅｌｎｅｔ、ｒｌｏｇｉｎ、ｘｔｅｒｍ、ｆｔｐ制御チャネルのような文字ベースのものである場合、ヘッダは転送データの各バイトごとに４０バイトまたはそれ以上の長さとすることができる。「データグラム」と「パケット」の話はしばしば混用されるが、「データグラム」は正しく定義すると、そのプロトコルで扱われるデータ単位であり、「パケット」は、Ｅｔｈｅｒｎｅｔあるいは何らかの回線上に現れる物理的な存在である。大抵の場合、パケットはデータグラムを１個含む。しかし、ＬＡＮがＥｔｈｅｒｎｅｔやＰＤＮ（公衆データ網）など他のネットワークに接続されているときは、ＴＣＰ／ＩＰデータグラムをより小さな断片に分解し（たとえばデータグラムが大きなファイルである場合）、この小さな断片または「パケット」のそれぞれに別のヘッダを付加する���たとえば、  Ｘ．２５（端末とＰＤＮパケット交換ネットワークの間のインターフェースを定義するプロトコルおよびメッセージ・フォーマットに関するＣＣＩＴＴ規格）の上でＴＣＰ／ＩＰを使用する場合、  Ｘ．２５インターフェースはデータグラムを１２８バイトのパケットに分解し、それぞれにさらに  Ｘ．２５ヘッダを付加する。データグラムをＴＣＰ／ＩＰに戻す前にパケットは通信リンクの他端で再度組立てられるので、これはＩＰには見えない。とはいえ、ＴＣＰ／ＩＰヘッダ圧縮技法を使用しない伝送では、さらに多くの「ヘッダ」が使用されることがある。上述の文字アプリケーションの場合、ＴＣＰ／ＩＰヘッダ＋データには別の  Ｘ．２５ヘッダが付加される。ＴＣＰ／ＩＰに関する他の基礎情報については、Ｃｈａｒｌｅｓ  Ｌ．Ｈｅｄｒｉｃｋの”Ｉｎｔｒｏｄｕｃｔｉｏｎ  ｔｏ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌｓ”，Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅｓ  Ｆａｃｉｌｉｔｉｅｓ  Ｇｒｏｕｐ，Ｒｕｔｇｅｒｓ  Ｕｎｉｖｅｒｓｉｔｙ，１９８７年７月を参照のこと。
【０００４】
現在のコンピュータは、ＬＡＮを世界規模のネットワークに接続しており、通常はネットワーク接続のある部分でＰＤＮを使用している。専用回線（  Ｘ．２５サービスの主な代替手段）はより高価でかつ米国外ではより得ることが難しく、国境を越えては存在しないことがしばしばである。  Ｘ．２５はヨーロッパと極東では米国内よりも広く使用されているので、小企業ならびに世界規模の遠隔通信技術に対する依存性が高まっている世界中にオフィスをもつ大きな国際企業でより多く使用されている。公共  Ｘ．２５ネットワークの使用コストを規定する大きな特性として次の２点がある。
１．ネットワークの使用料金は、通常は送信されるデータ量に基づく。
２．接続速度が高くなるほど接続のレンタル料が急速に増大する。
したがって、ＰＤＮ    Ｘ．２５ネットワークを使用する際にＴＣＰ／ＩＰの効率が高まると、１）送られるデータの総量が減少し、かつ２）Ｖａｎ  Ｊａｃｏｂｓｏｎ方式を使用したヘッダ圧縮により必要な総帯域幅が減少するためより安価な  Ｘ．２５接続の使用が可能になるので、コストが削減される。
【０００５】
残念ながら、現在は２つのシステムが  Ｘ．２５ネットワークを介して通信する際にＶａｎ  Ｊａｃｏｂｓｏｎヘッダ圧縮方式は使用されていない。というのは、パケット交換システムを使用する際に遠隔システムがＶａｎ  Ｊａｃｏｂｓｏｎ圧縮システムをサポートするかどうかを通常はアプリオリに決定できないからである。したがって、その使用を可能にする何らかの手段が必要である。
【０００６】
【発明が解決しようとする課題】
以下により詳しく述べる本発明は、ＴＣＰ／ＩＰ／  Ｘ．２５ネットワークにおける遠隔ノード間でのＶａｎ  Ｊａｃｏｂｓｏｎヘッダ圧縮／圧縮解除方式の使用を可能にし、それによってＰＤＮの  Ｘ．２５サービスを介して伝送されるヘッダ・データの大幅な削減をもたらし、かつそのことをそのセッション用のネットワーク経路指定ファイルに自動的に記憶して維持するための方法および装置である。さらに、本発明は、ＴＣＰ／ＩＰ／  Ｘ．２５ネットワークにおいてＶａｎ  Ｊａｃｏｂｓｏｎヘッダ圧縮／圧縮解除方式の使用を実施するためのエレガントな方法を提供する。
【０００７】
ＲＦＣ１１４４  ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用できる能力を有するローカル・データ端末装置（ＤＴＥ）が、ＴＣＰ／ＩＰ／  Ｘ．２５ネットワーク・リンクの他端に位置する未知の遠隔ＤＴＥと通信して、遠隔ＤＴＥもＲＦＣ１１４４  ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートしているかどうか判定することのできる方法および装置が開示される。ここに開示する装置および方法を用いると、ユーザがローカルＤＴＥに、遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートすることがわかっていると知らせることが可能になり、それによりローカルＤＴＥがこの情報を記録するためその経路指定情報を設定する。別法として、ローカルＤＴＥが自動的に未知の遠隔ＤＴＥを照会して、それがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするかどうか判定し、その判定に応じてその経路指定情報を設定することもできる。
【０００８】
ネットワーク中で  Ｘ．２５パケット変換リンクを使用する通信ネットワークでＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用する方法は、ネットワーク中の第１ＤＴＥが遠隔ＤＴＥに対して第１のコール要求を出すプロセスを含む。この第１コール要求は、第１ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用することを示す特定の通信プロトコル識別子（ＰＩＤ）をユーザ・データ・フィールド中に含む。遠隔ＤＴＥは、このＰＩＤを感知すると、自分もＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用できることを示すコール受諾メッセージ、またはＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートできないことを示すコール・クリア・メッセージを返す。第１ＤＴＥは遠隔ＤＴＥからどちらの戻り信号を受け取ろうと、それに応じてその内部制御を、ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用するようにまたはしないように調節する。
【０００９】
本発明は、遠隔通信システムと、ＴＣＰ／ＩＰ／  Ｘ．２５ネットワークを使用し、かつ遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除に対処できるか否かを自動的に判定できる能力を有するＤＴＥを含む。
【００１０】
本発明のシステムの目的、特徴および利点は、以下の説明から明らかになるであろう。
【００１１】
【発明の実施の形態】
概念および用語
以下の詳細な説明は、主としてコンピュータ・メモリ内のデータ・ビットに対する操作のプロセスおよび記号表現によって提示する。これらのプロセス記述および表現は、データ処理技術の当業者がその仕事の内容を他の当業者に最も効果的に伝えるために使用する手段である。
【００１２】
プロセスとは、本明細書では、一般においてもそうであるが、所期の結果をもたらす自己整合的な一連のステップである。これらのステップは、物理量の物理的操作を必要とするものである。必ずという訳ではないが通常これらの量は電気信号または磁気信号の形をとり、記憶、転送、組合せ、比較、およびその他の操作が可能である。主として一般に使用されていることから、これらの信号を、ビット、値、要素、記号、文字、項、番号などと呼ぶのが時として好都合である。ただし、これらおよび類似の用語はすべて適当な物理量に関連するものであり、こうした量に付けた便利なラベルにすぎないことを銘記されたい。
【００１３】
さらに、実施される操作はしばしば、一般に人間の操作員が行う精神作用に関連する、加算や比較などの表現で呼ばれる。ここで述べ、本発明の一部分を構成するどの操作においても、人間の操作員のそのような能力は必要とされず、また大抵の場合は望ましくもない。操作とはマシン操作のことである。本発明の操作を実施するための有用なマシンには、汎用デジタル・コンピュータや類似の装置がある。いずれの場合にも、コンピュータを操作する際の方法操作と、計算方法自体との区別を念頭に置くべきである。本発明は、電気信号または他の（たとえば機械的、化学的）物理信号を処理して他の所望の物理信号を生成する際にコンピュータを操作するための方法ステップに関する。
【００１４】
本発明はまた、これらの操作を実施するための装置にも関する。この装置は、必要な目的に合わせて特別に構築することもでき、あるいはコンピュータに記憶されているコンピュータ・プログラムによって選択的に活動化または再構成された、汎用コンピュータを備えることもできる。ここに提示するプロセスは、特定のコンピュータその他の装置に本来的に関係するものではない。具体的に言うと、本明細書の教示に従って作成したプログラムを組み込んだ様々な汎用マシンを使用することができ、あるいは必要な方法ステップを実施するための専用装置を構築する方が好都合なこともある。こうした多様なマシンの必要な構造は以下の説明から明らかになるであろう。
【００１５】
Ｖａｎ  Ｊａｃｏｂｓｏｎヘッダ圧縮システム（参照により本明細書に合体されるＲＦＣ１１４４で定義されている）は、パケット・ヘッダを符号化してそのサイズを減少させることによりＴＣＰ／ＩＰベースのアプリケーションの効率を改善する方法である。その結果、データ・バイトの数とネットワークを介して送られる総バイト数の比が改善される。
【００１６】
このシステムはどんなＴＣＰ／ＩＰアプリケーションにも適用できるが、ｔｅｌｎｅｔ、ｒｌｏｇｉｎ、ｘｔｅｒｍ、ｆｔｐ制御チャネルなど文字ベースのアプリケーションを使用するとき特に効果が著しい。こうした場合、プロトコル情報４０バイト分が転送されるデータの各バイトごとにＩＰヘッダ中で送られる。テストにおいて、このヘッダ圧縮システムが、典型的なＴｅｌｎｅｔセッションの効率を最大６倍まで改善できることが判明している。現在、ＲＦＣ１１４４はＩＰ／ＳＬＩＰおよびＩＰ／ＰＰＰ用に指定されているが、ＰＤＮ    Ｘ．２５パケット交換リンクがネットワーク・リンクの接続部分を構成し、一部の端末がヘッダ圧縮／圧縮解除をサポートでき、他の端末がサポートできないネットワークにおいて、ＲＦＣ１１４４を使用するための扱いやすい手段は今まで存在しなかった。
【００１７】
ＲＦＣ１１４４  ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除を使用する能力のあるローカル・データ端末装置（ＤＴＥ）が、ＴＣＰ／ＩＰ／  Ｘ．２５ネットワーク・リンクの他端にある未知の遠隔ＤＴＥと交渉して、その遠隔ＤＴＥもＲＦＣ１１４４  ＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするかどうか判定することができる方法および装置を開示する。ここに開示する装置および方法を使用すると、ユーザ（たとえばシステム管理者）がローカルＤＴＥに、遠隔ＤＴＥがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートすることがわかっていると知らせることが可能になり、それによりローカルＤＴＥが、以下でより詳しく述べるように、この情報を記録するためその経路指定情報を設定する。別法として、ローカルＤＴＥが自動的に未知の遠隔ＤＴＥを照会して、それがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするかどうか判定し、その判定に応じてその経路指定情報を設定することもできる。本発明は、ＤＴＥとして機能する任意のコンピュータ・プログラム・プロダクトを含む適当などんなＴＣＰ／ＩＰ／  Ｘ．２５ネットワーク環境でも使用できるが、ここでは例示的に、特定のタイプのネットワーク制御システムおよび例示的プログラミング・システムの環境で本発明の実施態様を説明する。ただし、当業者には、この開示で述べる方法およびシステムについて理解し、他の様々なネットワーク・システムおよび関連ツールを使用してそれを実施するのに、例示システムに関する具体的知識は不要である。本発明は、ヘッダ圧縮／解除をサポートする端末とサポートしない端末を有するどんなネットワーク上でも実施できる。
【００１８】
操作環境
本発明が適用される環境としては、汎用コンピュータ、ワークステーションまたはパーソナル・コンピュータが様々なタイプの通信リンクを介してクライアント・サーバ配列で接続され、多くはオブジェクトの形のプログラムとデータが、システムの他のメンバによる実行およびアクセスのため、システムの様々なメンバによって使用可能にされ共用される汎用分散コンピューティング・システムが含まれる。汎用ワークステーション・コンピュータ２０の一部の要素を図１に示す。図１において、プロセッサ１は、入出力部２と中央処理装置（ＣＰＵ）３とメモリ部４を有する。入出力部２は、キーボード５、表示装置６、ディスク記憶装置９、およびＣＤ−ＲＯＭ駆動装置７に接続されている。ＣＤ−ＲＯＭ装置７は、一般にプログラム１０とデータを格納したＣＤ−ＲＯＭ媒体８を読み取ることができる。表示装置６上にコンピュータ表示アイコン１１が示されている。通信経路によって同様のワークステーション同士を接続して分散コンピュータ・システムを形成することができ、本明細書ではこれを一般にデータ端末装置（ＤＴＥ）と称することにする。
【００１９】
次に基本的背景と基礎となる技術に関して本発明の考察を行って、本発明がどんなものか、およびどのように機能するかの要約を示し、続いて本発明の使用方法について詳しく説明する。
【００２０】
基礎となる技術
Ｘ．２５プロトコル
Ｘ．２５とは、国際電気通信連合（ＩＴＵ）の規格制定部門である国際電信電話諮問委員会（ＣＣＩＴＴ）の作成したデータ通信プロトコルである。  Ｘ．２５は１９７６年に始まり、パケット・モード・データ端末装置（ＤＴＥ、ユーザ端にある装置）とデータ回線終端装置（ＤＣＥ、ネットワーク端にある装置）の間の接続を支配するプロトコルであると定義される。  Ｘ．２５は、他のデータ通信プロトコルと同じく、任意の２システム間でどれだけ多くのデータを確実にかつ流れを制御しながら交換できるかを指定する。このプロトコルは、コール・セットアップおよび終了（「クリア」とも呼ぶ）機能ならびにデータ通信リンクの円滑な機能に必要な他の機能用の機構を定義する。ＣＣＩＴＴ    Ｘ．２５仕様は、ＤＣＥによって実行されるプロトコルとＤＴＥによって実行されるそれとは異なるプロトコルを記述している。一般に公用／専用データ・ネットワーク（ＰＤＮ）が  Ｘ．２５のＤＣＥ実施態様を提供し、コンピュータのベンダが  Ｘ．２５のＤＴＥ実施態様を提供する。ＣＣＩＴＴ    Ｘ．２５勧告は、  Ｘ．２５プロトコルの完全な説明を提供する。本発明で使用する例示システムの説明では、１９８８年のＣＣＩＴＴ    Ｘ．２５仕様に基づくシステムを使用する。
【００２１】
ＴＣＰ／ＩＰプロトコル
ＴＣＰ／ＩＰプロトコルについては背景の部で簡単に定義したが、より詳しくは様々なＲＦＣに記述されており、そのうち最も重要なものは、ｔｈｅ  ＤＤＮＰｒｏｔｏｃｏｌ  Ｈａｎｄｂｏｏｋ、ＳＲＩ  Ｉｎｔｅｒｎａｔｉｏｎａｌ、米国９４０２５カリフォルニア州Ｍｅｎｌｏ  Ｐａｒｋ、３巻にまとめられており、一般にｓｒｉ−ｎｉｃ．ａｒｐａから無名ＦＴＰを介してファイルｒｆｃ：ｒｆｃ−ｉｎｄｅｘ．ｔｘｔ  およびｒｆｃ：ｒｆｃｘｘｘｘ．ｔｘｔ  で入手できる。
【００２２】
次に図２を参照すると、通信のためにＴＣＰおよびＩＰがどう構成されるかを示し、全通信施設が多数のネットワーク（サブネットワーク）から構成できることを例示するため、典型的なＴＣＰ／ＩＰシステム２０が示してある。トークン・リングやＦＤＤＩなどある種のネットワーク・アクセス・プロトコルを使ってＤＴＥをサブネットワークに接続する。図２において、ＤＴＥとして働くホスト・コンピュータ２２は、オペレーティング・システム（ＯＳ）３０、アプリケーション・プログラム２４、ホスト間プロトコル（ＴＣＰ）２６、インターネット・プロトコル・インプリメンテーション（ＩＰ）のコピー２８、および第１のネットワーク・アクセス・プロトコル（ＮＡＰ１）３２を含む。この第１ネットワーク・アクセス・プロトコル３２は、ホスト２２が、第１サブネットワーク３４を横切ってルータ３６にデータを送信できるようにする。ルータ３６は、ＩＰ３８のインプリメンテーション、第１ネットワーク・アクセス・プロトコル３２のコピーＮＡＰ１  ４０および第２ネットワーク・アクセス・プロトコル４８のコピーＮＡＰ２  ４２を含み、第２ネットワーク・アクセス・プロトコル４８は第２のホスト５８にあって、一般にホスト５８が別のサブネットワーク４４を介してルータ３６と通信できるようにする。第２のホスト５８も、ＯＳ４６、アプリケーション５６、ＴＣＰ層５２およびＩＰ層５０を有する。ＩＰは端末システムとルータのすべてで実施される。ＩＰは、データのブロックをあるホストから１つまたは複数のルータを介して別のホストに運ぶ中継器として働く。ＴＣＰは、端末システム内でのみ実施され、そこですべてのデータ・ブロックが確実に適切なアプリケーションに配送されるようデータ・ブロックを追跡する。
【００２３】
ある通信システム中の様々なホストをリンクするサブネットワークの１つは、ＰＤＮ    Ｘ．２５パケット交換ネットワークとすることができる。たとえば、図３において、外部ホスト６２が  Ｘ．２５サブネットワーク６４に接続され、サブネットワーク６４自体はＥｔｈｅｒｎｅｔサブネットワーク７８に接続されたＳｕｎＬｉｎｋ    Ｘ．２５ゲートウェイ６８と別のＥｔｈｅｒｎｅｔサブネットワーク７６に接続された別のＳｕｎＬｉｎｋ    Ｘ．２５ゲートウェイ７４とに接続されている。これらの各システム（すなわち、外部ホスト６２、ＳｕｎＬｉｎｋＸ．２５ゲートウェイ６８、ＳｕｎＬｉｎｋ    Ｘ．２５ゲートウェイ７４）において、プロトコル・スタック８０は図４に示すようなものとすることができる。図４において、ホスト１  ８２は、そのＯＳ８４、アプリケーション８６、ＴＣＰ層８８、ＩＰ層９０およびＰＤＮ    Ｘ．２５ネットワーク９４と通信するための  Ｘ．２５ネットワーク・アクセス・プロトコル層９２を含んでいる。ホスト２  ９６も同様に、そのＯＳ９８、アプリケーション１００、ＴＣＰ層１０２、ＩＰ層１０４および  Ｘ．２５ネットワーク・アクセス・プロトコル層１０６を有する。ゲートウェイは、ＩＰ層と  Ｘ．２５プロトコル層のみを有することもできる。
【００２４】
図４のＴＣＰ／ＩＰ／  Ｘ．２５ネットワーク・リンクにおいて、ホスト（またはＤＴＥ）からホスト（ＤＴＥ）に送られるデータ・パケットは、一般に図５に示すような構成である。図５のデータ構成システム１１０において、ユーザ・データのブロック１１２が示されている。（これは「データグラム」）と呼ばれ、１文字でもよく１５００オクテットもの大きさでもよい。「オクテット」は、システムによっては８ビットより多数のビットを意味するのに「バイト」を使用することがあるため、インターネット文書で８ビットを意味するのに使用される用語である。）このデータグラム１１２はＴＣＰヘッダ１１６を付加されてＴＣＰセグメント１１４になる。このＴＣＰセグメント１１４はＩＰヘッダ１２０を付加されてＩＰデータグラム１１８となる。ＩＰデータグラム１１８が１２８バイトより小さい場合、  Ｘ．２５ヘッダ１２４を付加されて  Ｘ．２５パケット１２２になる。しかし、ＩＰデータグラム１１８が１２８バイトより大きい場合は、１２８バイトのパケット１３０〜１３６に分解され、それぞれに  Ｘ．２５ヘッダが付加される。
【００２５】
上記に指摘した通り、アプリケーションがｔｅｌｎｅｔ、ｒｌｏｇｉｎ、ｘｔｅｒｍまたはｆｔｐ制御チャネルなど文字ベースのものである場合、転送される各データ・バイトごとにヘッダは４０バイト以上とすることができる。したがって、効率およびコスト削減の点から、これらのヘッダをできるだけ小さくすることが不可欠であり、現在既知の最も効果的なＴＣＰヘッダ圧縮方式はＶａｎ  Ｊａｃｏｂｓｏｎ方式である。したがって、あるＴＣＰ／ＩＰ／  Ｘ．２５リンク上の未知の２つのホストが可能ならばＶａｎ  Ｊａｃｏｂｓｏｎ  ＴＣＰヘッダ圧縮／圧縮解除方式を使用できるようにする方法が求められている。
【００２６】
発明
好ましい実施の態様においては、２つのホスト／ＤＴＥ間での交渉のための方法および装置が、本発明の譲受人であるＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ  Ｉｎｃ．の製品ＳｕｎＬｉｎｋ    Ｘ．２５と呼ばれるシステムの枠内で実施される（ＳＵＮ、ＳＵＮ  ＭＩＣＲＯＳＹＳＴＥＭＳ、ＳＵＮＬＩＮＫはすべてＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ  Ｉｎｃ．の登録商標）。しかし、本発明の方法は、いかなるプログラミング方法においても、ＴＣＰ／ＩＰプロトコルと  Ｘ．２５プロトコルを使用するいかなるコンピュータ、ＤＴＥ、通信システムまたはネットワーク・アクセス・プロセスにおいても、あるいはヘッダ圧縮／圧縮解除をサポートできる端末とできない端末を含むいかなるネットワークにおいても実施できることは、当業者には理解できよう。
【００２７】
ＴＣＰ／ＩＰ／  Ｘ．２５ネットワーク・リンク上の遠隔ＤＴＥによるＶａｎ  Ｊａｃｏｂｓｏｎ  ＴＣＰヘッダ圧縮／圧縮解除の使用または不使用を判定する方法は２つある。
【００２８】
１）ローカル・ホスト（すなわちＤＴＥ）に含まれる経路指定情報の一部として、遠隔システムがＴＣＰヘッダ圧縮／圧縮解除方式をサポートすることがわかっているかどうかが指定される。好ましい実施の態様においては、この情報は経路指定テーブルに格納され、このテーブルを使用し通信アドレスに基づいてリンクとＳＮＰＡアドレスを選択する。あるいは、このデータを、既存の  Ｘ．２５用経路指定テーブルまたは専用の経路指定テーブルに格納することもできる。この情報は、システム管理者が供給することもでき、あるいは下記に示すように自動的に決定することもできる。
【００２９】
２）好ましい実施の態様においては、コールを開始するシステム／ＤＴＥはコール要求パケット５００のユーザ・データ・フィールド（図１０の５１６）中の特定プロトコル識別子（ＰＩＤ）を使用して、ＲＦＣ１１４４（Ｖａｎ  Ｊａｃｏｂｓｏｎ方式）を使用しているＩＰが使用中であることを示す。ＰＩＤはユーザ・データ５１６の最初の１バイトまたは数バイトを占める。たとえば、ＰＩＤ＝ＣＣの場合、ユーザ・データはＣＣを含む単一バイトだけの可能性もある。好ましい実施の態様では、この特定ＰＩＰは値０ＸＥＦをとる。この特定ＰＩＤを含むコール要求が遠隔システム／ＤＴＥによって拒絶された場合、非圧縮ＴＣＰ／ＩＰ用の標準ＰＩＤである０ＸＣＣにＰＩＤが設定された第２のコール要求が試みられる。圧縮方式の使用が合意されていようとそうでなかろうと、上記１に指定した経路指定テーブルを更新しなければならない。図６の交渉プロセス１５０は、この方法を図示したものである。図６ａで、第１のシステム／ＤＴＥ１５２は、特定ＰＩＤ１５４を含むコール要求パケットを遠隔システム／ＤＴＥ１５６に送る。特定ＰＩＤを感知し、それがＴＣＰ／ＩＰヘッダ圧縮／圧縮解除をサポートするように適合されていることを確認した遠隔システム／ＤＴＥ１５６は、発信元システム／ＤＴＥ１５２にコール受諾１５８パケットを返すことになる。図６ｂでも、第１のシステム／ＤＴＥ１５２が特定ＰＩＤ１５４を含むコール要求パケットを遠隔システム／ＤＴＥ１６０に送る。この遠隔システム／ＤＴＥ１６０は特定ＰＩＤ１５４を理解できず、したがってコール・クリア１６２パケットを返す。第１のシステム／ＤＴＥ１５２は、コール・クリア１６２パケットを受け取ると、遠隔システム／ＤＴＥ１６がＴＣＰ／ＩＰヘッダ圧縮／圧縮解除方式をサポートできないことに気づき、したがって遠隔システム／ＤＴＥ１６０がこの  Ｘ．２５ネットワーク・リンクを介して非圧縮のＴＣＰ／ＩＰデータを受諾できるかどうか調べる。発信元システム／ＤＴＥ１５２は、この特定ＰＩＤ（ＰＩＤ＝０ｘＥＦ）を標準のＰＩＤ（ＰＩＤ＝０ｘＣＣ）で置き換え、別のコール要求パケット１６４を送信する。遠隔システム／ＤＴＥ１６０がこの  Ｘ．２５ネットワーク・リンクを介して非圧縮ＴＣＰ／ＩＰデータを受諾できる場合、遠隔システム／ＤＴＥ１６０はコール受諾パケット１６６を返し、リンクが確立される。
【００３０】
好ましい実施の態様では、このコール制御交渉およびＲＦＣ１１４４の制御は、「ＩＰ  ｔｏ    Ｘ．２５カプセル化」モジュール（ＩＸＥ）に対する増補として実施される。次に図７を参照すると、本発明の好ましい実施の態様が、ＳｕｎＬｉｎｋ    Ｘ．２５バージョン９．０  ２００の環境で図示してある。図７においては、ＩＰモジュール２０６がリンク２０８を介してＩＸＥモジュール２１２にデータを供給する。経路指定テーブル２１６と構成ツール２１４を使用するＩＸＥモジュール２１２は、ＩＰを  Ｘ．２５上で走れるようにし、米国防データ・ネットワーク（ＤＤＮ）  Ｘ．２５標準サービスのサポートを含んでいる。ＩＸＥモジュール２１２は「ＲＦＣ１１４４／コール制御」モジュール２１８に接続され、このモジュール２１８は、該当する場合にＶａｎ  Ｊａｃｏｂｓｏｎヘッダ圧縮／圧縮解除を実行し、かつメッセージ開始時に、Ｊａｃｏｂｓｏｎヘッダ圧縮／圧縮解除プロセスが特定の２つの通信位置間で適当であるかどうか判定する。ＲＦＣ１１４４／コール制御モジュール２１８は「  Ｘ．２５パケット層プロトコル」モジュール２２０に接続され、このモジュール２２０は、「リンク・アクセス手順平衡」（ＬＡＰＢ）モジュール２３８と「論理リンク制御タイプ２」（ＬＬＣ２）モジュール２４０に接続されている。ＬＡＰＢモジュール２３８は広域ネットワーク（ＷＡＮ）に  Ｘ．２５の層２を与え、ＬＬＣ２モジュール２４０は、  Ｘ．２５がローカル・エリア・ネットワーク（ＬＡＮ）上で走れるようにする「接続志向型」操作を可能にする。
【００３１】
ＩＸＥ、  Ｘ．２５  ＰＬＰ、ＬＡＰＢ、ＬＬＣ２の各モジュールは、当技術分野で周知のプロトコルおよび手順を実施するものであり、詳細を省いて一般的に説明する。
【００３２】
ＩＸＥ（ＩＰ  ｔｏ   Ｘ．２５カプセル化）
このモジュールは、基本的にＭ−Ｎマルチプレクサ（ｍｕｘ）である。このマルチプレクサは、ＩＰが  Ｘ．２５上で走れるようにし、静的接続と動的接続を共に可能にする。静的接続とは、  Ｘ．２５接続が常に上にある接続であり、動的接続とは、ユーザが指定した量の遊休時間の経過後に  Ｘ．２５接続が下になるものをいう。ＩＸＥモジュール（図７の２１２）の上側には、  Ｘ．２５を使用する各ＩＰサブネット２０８、２１０ごとに１つのストリームがある。下側には、「仮想回線」（ＶＣ）２３６、２３４ごとに１つのストリームがある。これらの「ストリーム」からこのモジュールへのインターフェースは、モジュール２０８、２１０の上側の「無接続データ・リンク・プロバイダ・インターフェース」（ＤＬＰＩ）（ＵＮＩＸインターナショナルから層２へのインターフェース）であり、ＩＸＥモジュール２１２の下側には「ネットワーク層インターフェース」（ＮＬＩ）（Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．から層３へのインターフェース）が使用される。ＮＬＩストリームまたは入出力システムの代わりに当技術分野で周知の適当な任意のプロトコル層３へのインターフェースが使用できるが、元来Ｄｅｎｎｉｓ  ＲｉｃｈｉｅによりリサーチＵＮＩＸの第８版用に設計されたものであり、当技術分野では周知であるのでこれ以上詳しくは説明しない。たとえば、Ｗ．Ｒｉｃｈａｒｄ  Ｓｔｅｖｅｎｓの”ＵＮＩＸ  ＮｅｔｗｏｒｋＰｒｏｇｒａｍｍｉｎｇ”、ＰＴＲ  Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ、１９９０年、ｐｐ．３７４〜３７８を参照のこと。
【００３３】
Ｘ．２５  ＰＬＰ（パケット層プロトコル）
Ｘ．２５  ＰＬＰモジュール２２０は、Ｍ−Ｎマルチプレクサである。その上側２３６、２３４には、仮想回線ごとに１つのストリームがある。管理用に使用されるストリームもあり得る。  Ｘ．２５  ＰＬＰモジュール２２０の下側には、リンク（ＷＡＮまたはＬＡＮ）２４２、２４４ごとに１本のストリームがある。ストリーム・インターフェースは、上側２３４、２３６ではＮＬＩであり、モジュールの下側２４２、２４４では”Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のリンク層インターフェース”（ＳＬＩ）である。このプロトコル層２は当技術分野で周知であり、  Ｘ．２５  ＰＬＰモジュール２２０から層２へのインターフェースを作成するどのインターフェース機構もこれと等値である。ＤＬＰＩは、ＳＬＩへの周知の代替インターフェースである。
【００３４】
ＬＡＰＢ
ＬＡＰＢモジュール２３８はストリーム・マルチプレクサである。このマルチプレクサは、ＬＡＰプロトコルとＬＡＰＢプロトコルを共にサポートする。上側２４２にはＷＡＮリンクごとに１つのストリームがあり、下側にも（図７には示さず）リンクごとに１つのストリームがある。このモジュールでは多重化は行われない。上側は追跡および統計収集用の追加のストリームがあることもある。これらのストリーム・インターフェースは、上側２４２ではＳＬＩ、下側（図示せず）ではＳｕｎのＷＡＮドライバ・インターフェースである。このマルチプレクサは、また将来上側で接続志向型ＤＬＰＩインターフェースを使用できるように適合させることができ、かつＩＳＤＮ  Ｂチャネル・プロトコル・スタックならびに  Ｘ．２５  ＰＬＰの下で走るように適合させることができる。
【００３５】
ＬＣＣ１／２
このストリーム・ドライバ（Ｍ−１マルチプレクサ）は、ＬＬＣ１とＬＬＣ２を共にサポートする。  Ｘ．２５にはＬＬＣ２だけが必要であるが、ＬＬＣ１はＬＡＮ上で無接続ネットワーク・プロトコル（ＣＬＮＰ）を走らせるために必要である。ＣＬＮＰおよびその接続ネットワーク・サービス（ＣＬＮＳ）はＩＰの開放型相互接続（ＯＳＩ）プロトコル等価物である。マルチプレクサ２４４の上側に、サービス・アクセス点（ＳＡＰ）／ＬＡＮ接続対ごとに１つのストリームがあることがある。たとえば、ＳＡＰにＬＬＣで登録された  Ｘ．２５のようなプロトコルが１つしかなく、かつその下に２つのＬＡＮ装置がある場合、ＬＬＣマルチプレクサに対して２つの活動上側ストリームがあることになる。ＳＡＰごとにＬＣＣ１用とＬＬＣ２用に別々のストリームがある。下側には、ＬＡＮドライバごとに１つのストリームがある。ＬＡＮドライバが複数個ある場合、ＬＣＣ１／２はＭ−Ｎマルチプレクサである。これらのストリーム・インターフェースは、上側ではＳＬＩおよびＤＬＰＩ（ＬＬＣ２には接続志向型、ＬＬＣ１には無接続型）、下側では無接続ＤＬＰＩである。ＳＬＩインターフェースのサポートは、ＤＬＰＩに適合する  Ｘ．２５マルチプレクサで置き換えることもできる。
【００３６】
発明の詳細
次に図８および図９を参照して、本発明の方法３００の現在好ましい実施の態様の、ＲＦＣ１１４４／コール制御モジュール内で動作する場合の流れ図について説明する。図８において、ＩＰ／  Ｘ．２５トラフィック３０２が検出されたとき、プロセスが開始する。まず、このメッセージに適した既存の  Ｘ．２５接続があるかどうか判定する（３０４）。存在する場合（３０６）、既存の接続が使用され（３０８）、データ転送が実施され（３５６）、その後は通常の  Ｘ．２５コールとして処理される。このメッセージに適した既存の  Ｘ．２５接続がない場合（３１２）、「構成」ファイルを検査して（３１４）、このファイル中で「圧縮の使用」が示されているかどうか判定する。「構成」ファイルは、  Ｘ．２５接続上のすべてのＩＰ用の主な大域構成ファイルである。構成ファイル中で圧縮の使用が示されていない場合（３１６）、標準のＰＩＤ「ＣＣ」を使用して標準の（すなわちヘッダ圧縮のない）  Ｘ．２５圧縮を確立する試みが行われる（３４６）。遠隔端末が「ＣＣ」接続を受諾する場合（３５０）、経路指定テーブルがその事実で更新され、データ転送が続行される（３５６）。構成ファイル中で圧縮の使用が示されている場合（３２０）、さらにテストを行って、構成ファイル中で「常に圧縮試行」フラグがセットされているかどうか判定する（３２２）。セットされている場合（３２４）、「ＥＦ」にセットされたＰＩＤを使用して接続を確立する試みを行う（３３４）。接続が受諾された場合（３４２）、遠隔ホスト用のエントリが存在しない場合はこのファイルにエントリを付加し、存在する場合はそのホスト用の既存のエントリを上書きするように「経路指定」ファイルを更新する（３４４）。この場合も前と同様にデータ転送ステップ３５６を実行する。遠隔ホストがＰＩＤ＝ＥＦを使用する接続を受諾しない場合（３３８）、経路指定テーブルがこの事実を反映するように更新され（３４０）、ＰＩＤが「ＣＣ」に変更され、再度接続が試みられる（３４６）。プロセスのこの分岐は前述のように続く。ステップ３２２に戻って、構成ファイル中の「常に圧縮試行」フラグがセットされていない場合（３２６）、「経路指定」ファイルをテストする（３２８）。この「経路指定」ファイルは、所与のホストによって圧縮がサポートされるか否かを含めて、個々のホストへの経路に関する情報を含む。経路指定ファイルが、特定のホストが圧縮をサポートすることを示す場合（３３２）、システムはＰＩＤをＥＦに等しく設定し、前述のように接続が試みられる（３３４）。経路指定ファイルが、特定のホストが圧縮をサポートしないことを示す場合（３３０）、システムはＰＩＤをＣＣに等しく設定し、前述のように接続が試みられる（３４６）。標準の非圧縮  Ｘ．２５接続であるＣＣ接続が受諾されない場合（３５２）、システムは要求側ホストに、接続が行えないことを示す信号エラーを返す（３５４）。
【００３７】
経路指定テーブルにおけるＰＩＤの設定と関連するフラグに基づいて、データ転送プロセス３５６は次に、メッセージが着信メッセージであるか発信メッセージであるかテストして調べるプロセスを含み、着信メッセージの場合はヘッダを圧縮解除することができ、発信メッセージの場合はフラグの示す圧縮サポートに応じてヘッダが圧縮されあるいは圧縮されない。これは次のようにして実施される。データ転送セクション３５６内で、「圧縮使用中」フラグがテストされ（３６０）、それが「イエス」に設定され、データが  Ｘ．２５データから着信する場合（３６８）、ヘッダが圧縮解除され、（３８０）、ＩＰに渡される（３８４）。「圧縮使用中」フラグが「イエス」に設定され（３６２）、データが  Ｘ．２５データに発信する場合（３７０）、ヘッダが圧縮され（３８２）、  Ｘ．２５処理に渡される（３９０）。「圧縮使用中」フラグがテストされ（３６０）、それが「ノー」に設定され（３６４）、データが  Ｘ．２５データから着信する場合（３８６）、データがＩＰに渡され（３８４）、「圧縮使用中」フラグが「ノー」に設定され（３６４）、データが  Ｘ．２５データから着信しない場合（３８８）、データは  Ｘ．２５処理に渡される（３９０）。
【００３８】
本発明を図１ないし図１０に関して説明したが、これらの図は例示のためのものにすぎず、本発明に対する「制限」と見なすべきでないことはいうまでもない。同様に、本発明のこの実施の態様は、特定のプログラム、モジュール、モジュール間のプロトコル・インターフェースおよびその他の具体的実施態様に関して記述したが、これらの具体例は例示のためのものにすぎず、本発明に対する制限と見なすべきでないこともネットワーク・システム技術の当業者には明らかであろう。
【図面の簡単な説明】
【図１】遠隔通信ネットワークにおけるデータ端末装置（ＤＴＥ）として使用できる典型的なワークステーションを示す図である。
【図２】典型的なＴＣＰ／ＩＰローカル・エリア・ネットワーク（ＬＡＮ）接続を示す図である。
【図３】典型的なＬＡＮ／  Ｘ．２５ネットワーク構成を示す図である。
【図４】典型的なＴＣＰ／ＩＰ／  Ｘ．２５プロトコル・スタック配列を示す図である。
【図５】可能なＴＣＰ／ＩＰ／  Ｘ．２５ヘッダ・データ構成を示す図である。
【図６】ＤＴＥ  Ｂが要求された構成を受諾する場合の、ＤＴＥ  ＡからＤＴＥ  Ｂへのコール要求手段を示す図（ａ）とＤＴＥ  Ｂが初期コール要求は拒絶するが第２コール要求は受諾する場合の、ＤＴＥ  ＡからＤＴＥ  Ｂへのコール要求手段を示す図（ｂ）である。
【図７】ＳｕｎＬｉｎｋ    Ｘ．２５バージョン９．０システムの環境における本発明の位置を示す図である。
【図８】本発明のＲＦＣ１１４４およびコール制御システムのブロック図である。
【図９】本発明のコール要求・応答手順のブロック図である。
【図１０】Ｘ．２５パケット・フォーマットを示す図である。
【符号の説明】
２２  ホスト、２４  アプリケーション、２６  ＴＣＰ、２８  ＩＰ、３０  ＯＳ、３２  ネットワーク・アクセス・プロトコル１、３４  サブネットワーク、３６  ルータ。
【図１】
0003601885.tif 000002
【図２】
0003601885.tif 000003
【図３】
0003601885.tif 000004
【図４】
0003601885.tif 000005
【図５】
0003601885.tif 000006
【図６】
0003601885.tif 000007
【図７】
0003601885.tif 000008
【図８】
0003601885.tif 000009
【図９】
0003601885.tif 000010
【図１０】
0003601885.tif 000011