(57)【特許請求の範囲】
【請求項１】
ＰＰＰプロトコルによる回線を介して複数の端末を収容し，複数のリモートＬＡＮのルータとＷＡＮの物理回線または論理回線で接続されるアクセスサーバにおける簡易ルーチング方式において，
前記アクセスサーバは，プロトコル識別子（ＰＩＤ）を変換するＰＩＤ変換手段と，ＰＰＰプロトコルにおけるＰＤＵの各プロトコル識別子に対応するＷＡＮ回線のプロトコルにおけるプロトコル識別子が格納されたＰＩＤ変換テーブルと，アドレス変換手段と，端末と接続制御により接続する回線番号または端末と固定接続する回線番号と前記各ルータと接続するＷＡＮの物理（または論理）回線番号とを対応付けるルーチングテーブルを備え，
端末からのフレームを受信すると，前記アドレス変換手段は前記端末が接続する回線番号により前記ルーチングテーブルを検索して，対応するＷＡＮの物理（または論理）回線番号を求め，受信したフレームのＰＩＤの変換によりＷＡＮ回線対応のデータとした上で求めたＷＡＮの物理（または論理）回線に送出することを特徴とする簡易ルーチング方式。
【請求項２】
ＰＰＰプロトコルによる回線を介して複数の端末を収容し，複数のリモートＬＡＮのルータとＷＡＮの物理回線または論理回線で接続されるアクセスサーバにおける簡易ルーチング方式において，
前記アクセスサーバは，プロトコル識別子（ＰＩＤ）を変換するＰＩＤ変換手段と，ＰＰＰプロトコルにおけるＰＤＵの各プロトコル識別子に対応するＷＡＮ回線のプロトコルにおけるプロトコル識別子が格納されたＰＩＤ変換テーブルと，アドレス変換手段と，端末毎のユーザに付与されているユーザＩＤと各ユーザＩＤに対応して設定されたリモートＬＡＮのルータと接続するＷＡＮの物理（または論理）回線番号とを対応付けるルーチングテーブルを備え，
前記アクセスサーバのアドレス変換手段は，端末からのフレームを受信すると，端末と接続制御における認証制御により得たユーザＩＤまたは端末と固定接続した回線に対応するユーザＩＤにより，上記ルーチングテーブルを検索して対応するＷＡＮの物理（または論理）回線番号を求め，受信したフレームのＰＩＤの変換によりＷＡＮ回線対応のデータとした上で求めたＷＡＮの物理（または論理）回線に送出することを特徴とする簡易ルーチング方式。
【請求項３】
請求項１または２のいずれかにおいて，
前記ルーチングテーブルは，端末と接続制御により接続する回線（または端末と固定接続する回線）番号または端末のユーザＩＤに対して，接続可能な複数のリモートＬＡＮのルータと接続する各ＷＡＮの物理（論理）回線を対応付けると共に第１方路，第２方路，…第ｎ方路という優先順位を表す属性を設定した構成を備え，
前記アドレス変換手段は，各回線番号またはユーザＩＤに対応するＷＡＮの物理（論理）回線の中から，使用可能な優先順位が上位の方路から選択を行うことを特徴とする簡易ルーチング方式。
【請求項４】
ＰＰＰプロトコルによる回線を介して複数の端末を収容し，リモートＬＡＮのルータとＷＡＮ回線で接続するアクセスサーバにおける圧縮データを含むフレームのルーチングを含む簡易ルーチング方式において，
前記ＰＰＰ回線上のデータ圧縮プロトコルとして，データ圧縮範囲をネットワーク層データ部分として，これを任意の圧縮アルゴリズムで圧縮したデータを含むフレームとするプロトコルを用い，
前記ＷＡＮ回線上のデータ圧縮プロトコルとして，データ圧縮範囲をネットワーク層データ部分として，これを前記ＰＰＰ回線の圧縮アルゴリズムと同じ圧縮アルゴリズムで圧縮したデータを含むフレームとするプロトコルとし，
前記アクセスサーバは，ＰＰＰ回線からの圧縮データを含むフレームを受信すると，データ部分については変更せず，アドレス，圧縮表示，及びプロトコル識別子（ＰＩＤ）をＷＡＮ回線の対応するアドレス，圧縮表示及びＰＩＤに変換する圧縮データ変換部を備え，
変換されたフレームをＷＡＮ回線に送信する手段を備えることを特徴とする簡易ルーチング方式。
【請求項５】
請求項４において，
前記アクセスサーバは，ＰＰＰ回線で接続する端末との間で，ＩＥＴＦが規定する圧縮方式のネゴシエーションのＣＣＰプロトコルにより，前記データ圧縮範囲及び圧縮アルゴリズムを含むネゴシエーションを行うことを特徴とする簡易ルーチング方式。
【請求項６】
請求項４において，
前記ＷＡＮ回線をフレームリレー回線で構成され，
前記アクセスサーバは，フレームリレー回線で接続するルータとの間で，フレームリレーフォーラムが規定する圧縮方式のネゴシエーションのＤＣＰＣＰプロトコルにより，前記データ圧縮範囲及び圧縮アルゴリズムを含むネゴシエーションを行うことを特徴とする簡易ルーチング方式。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はＰＰＰ（Point to Point Protocol)を使用してＬＡＮに接続されたサーバにアクセスするためのＰＰＰアクセス簡易ルーチング方式に関する。
【０００２】
近年，端末またはサーバから他の端末またはサーバに接続するため，ＰＰＰと呼ばれるプロトコルがインターネットのプロトコルとして利用されるようになった。このＰＰＰにより公衆網からＬＡＮに接続されたアクセスサーバにアクセスし，そのアクセスサーバからそのＬＡＮ内のサーバに直接接続したり，専用線等のルータネットワークを介して遠隔（リモート）のＬＡＮのサーバにアクセスすることができる。
【０００３】
このようなＰＰＰを使用する端末がアクセスサーバに接続した後，リモートＬＡＮのサーバにアクセスする場合，アクセスサーバでルーチング処理を行う必要があり，ルーチング処理をしないようにすると異なるリモートＬＡＮに接続できなくなったり，セキュリティの制御が複雑になり，更に異なるプロトコル間でデータ圧縮を行うための処理が複雑化する。
【０００４】
【従来の技術】
ＰＰＰは，Point to Point Protocol の略名であり，ＰＰＰの機能の詳細は，インターネットのプロトコルの標準化を行う米国の組織ＩＥＴＦ（Internet Engineering Task Force)により，ＲＦＣ(Request For Comments)と呼ぶドキュメントにまとめられている。なお，ＰＰＰは複数のＲＦＣで規定されていて，プロトコルの基本部分を規定するのはＲＦＣ１６６１である。
【０００５】
具体的にはＰＰＰは各種の通信プロトコルデータを専用線，ＩＳＤＮ交換回線，電話回線等のシリアル回線上に転送するためのプロトコルである。これらのシリアル回線上にデータを転送する場合，データの始まりと終了を検出する方法が必要であり，ＰＰＰはフラグと呼ばれる８ビットパターン「01111110」（Ｆで表す）をデータの開始と終了とするＨＤＬＣ（High level Data Link Control) フレーミングを使用する。
【０００６】
図２０にＰＰＰフレーム構成を示す。図中，Ｆはフラグ，Ａは１バイトのアドレスでありＰＰＰの場合「11111111」に固定される。Ｃは１バイトの制御を表し，ＰＰＰの場合「00000011」に固定される。ＰＩＤは２バイトのプロトコル識別子（Protocol IDentifire)，ＰＤＵはＰＰＰプロトコルの上位レイヤから渡されたデータ（制御データを含む）が設定されるプロトコルデータユニット，ＦＣＳは２バイトのフレームの正常受信を確認するためのフレームチェックシーケンスである。
【０００７】
ＰＰＰは大別すると次の▲１▼，▲２▼の２つのネットワークの形態で使用され，図２１，図２２を用いて説明する。
▲１▼図２１に示すＷＡＮ等のようなルータネットワーク経由のリモートＬＡＮへシリアル端末を収容する形態の場合
シリアル端末８０は電話回線，ＩＳＤＮ電話回線等のシリアル回線８１を介してＰＰＰによりアクセスサーバ（ＡＳで表示）８２（ＴＣＰ／ＩＰのアクセスポイント）に収容され，リモートＬＡＮ８６のサーバ８７に接続するためには，アクセスサーバ８２のＬＡＮ８３からルータ（Ｒで表示）８４と回線（専用線等）８５で構成するルータネットワークを経由して遠隔に設けられたリモートＬＡＮ８６のサーバ８７と接続される。
【０００８】
このネットワーク形態の場合，シリアル端末８０とアクセスサーバ（ＡＳ）８２間はＰＰＰプロトコルで通信する。通常アクセスサーバ（ＡＳ）８２はＰＰＰフレームをシリアル端末８０から受信し，ＰＰＰフレームのＰＩＤを参照してＰＤＵ部分をＰＩＤが示すプロトコル種別に応じたＬＡＮ８３のデータ形式に変換して，ＬＡＮ８３経由でルータ（Ｒ）８４に転送する。ルータ（Ｒ）８４は各プロトコルに応じたＰＤＵ内のネットワークアドレスによりルーチングを行い，次のルータに向けてデータを転送する。その後データはルータネットワークでルーチングされて，リモートＬＡＮ８６上にある目的のサーバ８７まで到達する。サーバ８７からシリアル端末８０までのデータ転送はその逆の処理で行われる。
【０００９】
▲２▼図２２に示すルータネットワーク無しのリモートＬＡＮへシリアル端末を収容する形態の場合
この形態は，上記▲１▼より単純で，アクセスサーバ（ＡＳ）に直接リモートＬＡＮ８６が接続され，シリアル端末８０とサーバ８７がルータを経由しないで接続される。
【００１０】
上記▲２▼のような形態では問題が少なく，▲１▼のように比較的規模の大きいネットワーク形態に適用される従来の技術を説明する。
ここでアクセスサーバ（ＡＳ）の機能は基本的には上記▲１▼で説明したように，ＰＰＰによるシリアル回線の制御と，ルータと接続するＬＡＮ回線の制御であるが，以下の説明ではアクセスサーバ（ＡＳ）とＬＡＮで接続されたルータ（Ｒ）を含めて考える。また，実際のアクセスサーバの製品にはルータ機能まで一つの物理装置として一体化したものが多く，その場合上記図２１のアクセスサーバ（ＡＳ）とルータは一体化し，両者を接続するＬＡＮは物理的に存在しない形になる。また，シリアル端末８０は，通常パーソナルコンピュータ（パソコン）であり，以下の説明ではシリアル端末の代わりにパソコンという用語も使用する。
【００１１】
次に異なる回線を介する従来のデータ圧縮について説明する。
回線を有効利用する方法の１つとしてデータ圧縮がある。データ圧縮についても標準化が進められているが，回線の種別により異なった標準化が行われているのが現状である。このため，アクセスサーバのように異なる通信回線の間を相互に接続する装置では，圧縮されたデータをそれぞれの回線種別に応じて圧縮し直す必要がある。
【００１２】
図２３は従来のデータ圧縮の説明図である。このネットワーク構成は，パソコンＡとアクセスサーバ（ＡＳ）の間はＰＰＰプロトコルによる回線であり，アクセスサーバ（ＡＳ）からリモートＬＡＮのルータまでのルータネットワークがフレームリレー回線である例である。この場合，パソコンからアクセスサーバ（ＡＳ）に向けて送出するデータａは，ＰＰＰのデータ圧縮のルール（上記ＩＥＴＦの規定するルール）に従って圧縮し，そのルールの圧縮識別子を付与してフレームｂとしてＰＰＰ回線に送出する。アクセスサーバ（ＡＳ）は，その圧縮データを受信して，一旦解凍して基のデータを復元する。次にフレームリレーの圧縮方式（フレームリレーフォーラムの規定するルール）に従って圧縮し，識別子を付与したフレームｃをフレームリレー回線に向けて送出する。ルータはフレームリレー回線からの受信データを識別子に従って解凍してデータｄを復元する。サーバからパソコン向けのデータに関しても同様である。
【００１３】
【発明が解決しようとする課題】
従来のシリアル端末（パソコン）からルータネットワークを介してリモートＬＡＮのサーバとデータを転送する場合の問題点を以下に図を用いて説明する。
【００１４】
(1) ネットワーク層ルーチングの処理負荷
従来の上記図２１に示す構成におけるアクセスサーバ（ＡＳ）は，シリアル回線からＰＰＰフレームを受信すると，受信したＰＰＰフレーム毎にＰＩＤフィールドのプロトコル識別子が示すネットワーク層プロトコル処理部（図示省略）にデータを渡し，そのプロトコル処理部でＰＤＵデータ内のネットワークアドレスに基づいたルーチング処理を行う。これは，ごく普通に行われる処理であり汎用性がある反面，次ような問題がある。
【００１５】
ネットワーク層のルーチング機能が必須である。すなわち，アクセスサーバは，ネットワーク層でルーチングするため，ネットワーク層のルーチング処理機能が必要である。この処理はＰＰＰ回線で送受信するすべてのデータ（フレームの一つ一つ）に対して行う必要があり，アクセスサーバのＣＰＵ負荷増大によるスループット低下や，各フレーム毎の処理によるデータ転送遅延が増大するという問題があった。
【００１６】
(2) パソコン（ユーザ）単位のデータ振り分け
上記(1) の問題は，データ内のネットワークアドレスによるルーチング処理をせずに，目的のリモートＬＡＮのルータまでデータを転送することで解決できる。しかし，この場合，１台のアクセスサーバに収容されたパソコンから，異なるリモートＬＡＮに接続する場合に，ネットワーク層のアドレスによるルーチング処理を行ってリモートＬＡＮを選択することができなくなるという問題が発生する。
【００１７】
これを図２４に示す問題点の説明図１を用いて説明する。この例は，パソコンＡがリモートＬＡＮＡのサーバＡに接続し（図中のａの経路），パソコンＢがリモートＬＡＮＢのサーバＢに接続する（図中のｂの経路）ようにしたい場合である。アクセスサーバがルーチング機能を持てば，データのネットワークアドレスによるルーチング処理で，サーバＡとサーバＢへ振り分けを行うことは容易であるが，フレームのＰＤＵ内のネットワークアドレスを処理する必要があるため上記(1) の問題を解決することができない。
【００１８】
(3) セキュリティ
ネットワーク層のアドレスでルーチングを行うアクセスサーバの場合，サーバへのアクセスを制限しようとすると，ルーチングの場合と同様パソコンから送信されるＰＰＰフレーム中のＰＤＵを参照し，ＰＤＵ内の発ネットワークアドレスをチェックして，これをアクセスサーバが規制するかどうかの制御が必要になる。
【００１９】
これを図２５に示す問題点の説明図２を用いて説明する。パソコンＡはリモートＬＡＮＡにだけアクセスを可能とし，パソコンＢはリモートＬＡＮＢにだけアクセスを可能とし，他へのアクセスを禁止する場合，例えば，パソコンＡがリモートＬＡＮＢのサーバＢにアクセスさせないようにしようとすると，アクセスサーバには，パソコンＡから受信したＰＰＰフレーム内のＰＤＵの発ネットワークアドレスを確認し，発ネットワークアドレスがＡで，宛先ネットワークアドレスがリモートＬＡＮＢになっているフレームを廃棄する処理が必要になる。この処理はルーチング処理以上に複雑であり，運用管理も複雑化する。このため，アクセスサーバの負荷を軽減しようとすると完全なセキュリティ確保が困難になるという問題がある。
【００２０】
(4) データ圧縮
図２３で説明した従来のデータ圧縮の問題点を具体例により説明する。
図２６はＰＰＰ上とフレームリレー上のフレーム構成を示し，ＰＤＵ内のプロトコルがインターネット標準プロトコルであるＩＰ（Internet Protocol)である例を示す。このＩＰデータ（図２６のａ）を専用線や電話回線に送出する時のフレーム形式はＰＰＰプロトコル（ＲＦＣ１６６１）で規定されており図２６のｂのようなＰＰＰアドレス，フレーム種別，ＩＰの識別子とＩＰデータ等で構成され，フレームリレー網に送出する時のフレーム形式はＩＴＵ−ＴのＱ．９２２及びＸ．３６で規定された図２６のｃに示す構成を備えている。
【００２１】
このようにＰＰＰとフレームリレーでは，同じＩＰデータに対する識別子が，それぞれ異なる。ここではＩＰを例として示すが，その他の種別のデータ（ＩＰＸやＣＬＮＰ等）に関してもそれぞれＰＰＰとフレームリレーではプロトコル識別子の数値が異なる。
【００２２】
このようなフレームを圧縮して転送する場合，フレーム形式はＰＰＰの場合はＩＥＴＦ，フレームリレーの場合はフレームリレーフォーラムで規定されており，いずれも元データの識別子（図２６のａ，ｂの太線で囲まれた部分）を含む範囲を圧縮することになっている。従って，同一の圧縮アルゴリズムで圧縮しても，圧縮されたデータ部分の中身が，ＰＰＰの場合とフレームリレーの場合とでは異なることになる。
【００２３】
これを更に図２７と２８を用いて説明すると，図２７はＰＰＰの場合の圧縮無しと圧縮有りのフレーム形式を示し，図２８はフレームリレーの場合の圧縮無しと圧縮有りのフレーム形式を示す。何れの場合もＰＤＵがＩＰデータの場合であり，ＰＰＰとフレームリレーでは圧縮対象範囲にあるプロトコル識別子部分の相違により，圧縮データ部分は同一にならないことが明らかである。このため，ＰＰＰ回線とフレームリレー回線の間でそれぞれの通信の仲介をするアクセスサーバは，一方から受信したデータが圧縮されたデータである場合，その圧縮データ部分を一旦解凍して元データに戻し，送出側の回線種別に従った圧縮アルゴリズムで圧縮しなおして送信するか，送信側は圧縮せずに送信するしか方法がなかった。
【００２４】
このように，種別の異なる回線間を接続するアクセスサーバでは，両方の回線で圧縮を行う場合，データ解凍・圧縮の処理が必要になるため，ＣＰＵやメモリ等のリソースを多く消費するという問題があった。
【００２５】
更に，アクセスサーバとしてデータ圧縮機能を持たない装置を設けた場合，パソコンやルータがデータ圧縮可能でも，上記図２３のエンド・エンド間通信においてデータ圧縮が不可能となり，元のデータのままの通信しかできないという問題があった。
【００２６】
本発明は上記の各問題を解決することを目的とし，具体的にはアクセスサーバにおける処理の負担を軽減することができるＰＰＰアクセス簡易ルーチング方式を提供することを目的とする。また，ユーザ単位のデータの振り分けを可能にすること，及びリモートＬＡＮへのアクセスを端末に応じて規制してセキュリティを保持すること，更にデータ圧縮をアクセスサーバに負担をかけることなく行うことができるＰＰＰアクセス簡易ルーチング方式を提供することを目的とする。
【００２７】
【課題を解決するための手段】
図１は本発明の第１の原理構成である。
図中，１はパソコン等の端末，２は電話網，専用線，ＩＳＤＮ等のＰＰＰ回線，３はアクセスサーバ（ＡＳ），３０はプロトコル識別子（ＰＩＤ:Protocol Identifire) 変換手段，３１はＰＰＰフレームのＰＩＤ（ＰＤＵのプロトコルを表すＰＰＰで規定したプロトコル識別子）に対応するＷＡＮ回線のプロトコルで規定したプロトコル識別子が格納されたＰＩＤ変換テーブル，４は専用線網等のＷＡＮ（Wide Area Network)回線，５はルータ，６はリモートＬＡＮ，７はサーバである。
【００２８】
本発明の第１の原理によれば，図１に示す端末１からＰＰＰ回線２を介してアクセスサーバ３に対してＰＰＰフレームによりデータを送ると，アクセスサーバ３ではフレーム内のＰＤＵを参照することなく，単に受信したＰＰＰフレーム内のＰＩＤ（フレーム内のＰＤＵのプロトコルに対応してＰＰＰにより規定された識別子が設定されている）を，ＰＩＤ変換テーブル３１を用いてＷＡＮ回線４のプロトコルにより規定されたＰＩＤ（ＰＩＤ’で表示）に変換する。この時，ＰＰＰフレームのアドレス（Ａ）については，ＷＡＮ回線４のリモートＬＡＮ６のサーバ７と接続する物理／論理回線のアドレス（Ａ’で表示）に変換する。変換されたフレームをＷＡＮ回線４に送出する。なお，ＷＡＮ回線へのフレームのＦＣＳは図示されないが当然変更される。
【００２９】
現実のネットワークでは，ＰＰＰプロトコルを有するパソコン等の端末は，特定のリモートＬＡＮにアクセスすることが普通であり，この場合フレームの一つのデータの中身（ＰＤＵの中）のネットワークアドレスまで処理を加える必要がないため，本発明のように処理することにより不都合を生じることなくアクセスサーバの負荷を軽減することができる。
【００３０】
図２は本発明の第２の原理構成である。図２にはアクセスサーバ（ＡＳ）だけ示し，図示省略されているが図１と同様に端末１，リモートＬＡＮ６，サーバ７が設けられている。
【００３１】
図２において，３０，３１は上記図１と同様であり，３２はアドレス変換手段，３３はルーチングテーブルである。
この第２の原理では，予めアクセスサーバ（ＡＳ）３に端末の回線番号またはアクセスサーバ３のポート番号（端末が着信したポートの番号）に対応してＷＡＮ回線を経由したリモートＬＡＮ６への回線（物理回線または論理回線）番号を設定したルーチングテーブル３３を設けておく。端末１がアクセスサーバ（ＡＳ）３にアクセスしてＰＰＰフレームが受信されると，そのＰＩＤを上記図１と同様にＰＩＤ変換手段３０によりＰＩＤ変換テーブル３１を用いて変換すると共に，アドレス変換手段３２は端末１の回線（またはポート）番号によりルーチングテーブル３３を参照して，対応するＷＡＮの回線番号を検出してアドレスを変換して，新たなＷＡＮ対応のフレームが構成される。これをＷＡＮ回線に送信する。この図２の場合も送信フレームのＦＣＳは当然変更される。
【００３２】
これにより，アクセスサーバ（ＡＳ）に接続する複数のパソコン等の端末はそれぞれの回線を備え，複数のリモートＬＡＮがＷＡＮに接続されていても，各端末からのＰＰＰ対応のデータは，アクセスサーバ（ＡＳ）においてフレームのＰＤＵ内の宛先ネットワークアドレスを参照することなく，ルーチングテーブル３３を用いて目的のリモートＬＡＮに向けて振り分けることができる。
【００３３】
図３は本発明の第３の原理構成である。図３には，上記図２と同様にアクセスサーバ（ＡＳ）だけ示し，端末１，リモートＬＡＮ６，サーバ７は図示省略されている。
【００３４】
図３において，３０，３１は上記図１の各符号と同様であり，３４はアドレス変換手段，３５は上記図２に示すルーチングテーブル３３と異なる内容を備え，ユーザＩＤとＷＡＮの回線番号の対応関係が格納されたルーチングテーブルである。
【００３５】
ＰＰＰプロトコルでは端末（パソコン）に対しユーザＩＤ（識別情報）を与えており，端末がＩＳＤＮ網等のＰＰＰ回線でアクセスサーバ３と接続する際に，アクセスサーバ３は端末との間でユーザＩＤにより接続された端末の識別を行う。この第３の原理では，アクセスサーバ３に予めこのユーザＩＤに対応してその端末が接続できるリモートＬＡＮへのＷＡＮの回線（物理回線または論理回線）番号を格納したルーチングテーブル３５を設け，端末からＰＰＰ回線を介してフレームを受信すると，そのＰＩＤを上記図１と同様に変換すると共に，アドレス変換手段３４により，接続時に識別した端末のユーザＩＤを用いてルーチングテーブル３５を参照して，対応するＷＡＮの回線番号を検出し，ＷＡＮ回線へのフレームのアドレスとして，フレームを送信する。この場合も，送信フレームのＦＣＳは当然変更される。
【００３６】
これにより，ＰＰＰデータのＰＤＵの宛先ネットワークアドレスを参照することなく端末からの送出データを目的のリモートＬＡＮに向けて振り分けることができる。
【００３７】
図３に示す構成により，端末は全て特定のルータ（ルータ経由で特定のリモートＬＡＮ）にのみダイレクトに接続することになる。これにより，リモートＬＡＮへのアクセスがアクセスサーバ３によって許容されていない（ルーチングテーブル３５により設定されていない）ユーザＩＤを持つ端末から各リモートＬＡＮへの直接アクセスを完全に防止し，リモートＬＡＮのセキュリティを確保することができる。
【００３８】
また，図３の構成に図２に示すルーチングテーブル３３を組み合わせることにより，ＰＰＰ回線（ポート）番号とユーザＩＤの両方を使用するテーブルを使用することで，端末が接続するリモートＬＡＮの選択の自由度とセキュリティの向上を同時に実現できる。
【００３９】
図４は本発明の第４の原理構成であり，端末からの圧縮データを含むフレームをアクセスサーバを介してリモートＬＡＮへ送信するための原理構成を示す。
図４において，１〜４の各符号は上記図１の同じ符号の各部に対応し，アクセスサーバ３内の３６は圧縮データ変換部であり，その中の３６ａはアドレス変換部，３６ｂは圧縮表示変換部，３６ｃはＰＩＤ（プロトコル識別子）変換部である。
【００４０】
本発明では，端末１でデータ圧縮を行う場合に，ＰＰＰフレーム内のデータ本体（ＰＤＵ）だけを圧縮し，該フレームに含まれたデータ本体のプロトコル種別を表すプロトコル識別子は圧縮の対象としない。ＰＰＰフレームの圧縮データを含むフレームには，アドレス，圧縮表示（圧縮データの識別子），プロトコル識別子（ＰＩＤ），圧縮データ，ＦＣＳを含む。このフレームはＰＰＰ回線２を介してアクセスサーバ（ＡＳ）３へ入力される。アクセスサーバ（ＡＳ）３では圧縮データについては何ら処理をせず，アドレス変換部３６ａ，圧縮表示変換部３６ｂ及びＰＩＤ変換部３６ｃにより，入力したフレームのアドレス，圧縮表示，ＰＩＤについてＷＡＮ回線のプロトコルに対応したアドレス，圧縮表示，ＰＩＤに変換する。なお，ＦＣＳについても当然新たな値に更新される。この圧縮データ変換部３６で変換されたフレームはＷＡＮ回線を介してリモートＬＡＮに送られると，圧縮表示に従って対応する解凍を行って元のデータが復元される。
【００４１】
これにより，端末とルータを接続するアクセスサーバ（ＡＳ）は，データの解凍／圧縮を行うこと無く圧縮データの中継を行うことが可能となる。これにより，ゲートウェイの負荷を軽減し，更に圧縮に必要な高価な機能（ハードウェアまたはソフトウェア）をアクセスサーバ（ＡＳ）に実装する必要がなくなる。
【００４２】
【発明の実施の形態】
図５はネットワークの構成例とフレーム変換の説明図である。
図５のＡ．は本発明が実施されるネットワークの構成例を示す。Ａ．において，１０は端末（図１の１）として一般に使用されているパソコン（パーソナルコンピュータ），２はＰＰＰプロトコルによる電話網，ＩＳＤＮ網，専用線等のシリアル回線（ＰＰＰ回線と同義），３はアクセスサーバ，４０はＷＡＮ回線（図１の４）の具体例であるフレームリレー回線（以下の実施例の構成でもフレームリレーの例を示す），５はリモートＬＡＮが接続されるルータ，６はリモートＬＡＮ，７はリモートＬＡＮのサーバである。
【００４３】
この図５のＡ．の場合，パソコン１０とアクセスサーバ間のデータはＰＰＰプロトコル，アクセスサーバとルータ５間はフレームリレーのプロトコルにより伝送される。
【００４４】
図５のＢ．はＰＰＰ回線上のＰＰＰフレームと，フレームリレー回線上のフレームリレーフレームの変換の具体例であり，上記図１に示す本発明の第１の原理構成により変換することができる。
【００４５】
Ｂ．において，各フレームのＦ，Ａ，Ｃ，ＰＩＤ，ＰＤＵ，ＦＣＳ，及びＦの各符号は上記図２０に示すＰＰＰフレームについて説明した通りであり，フレームリレーフレームについても同様である。この中の各フィールド名の下の記号は，１６進表示の数値であり，各プロトコルにより規定された実際の数値であり，＃１〜＃３は，次に説明する。
【００４６】
本発明のアクセスサーバ３は，ＰＤＵ内部に関して何ら処理を行わない。また，ＰＰＰフレームのＰＩＤ（プロトコル識別子，＃１）の具体値は，ＰＤＵ（プロトコルデータユニット）のプロトコル種別で決まり，インターネットプロトコル（ＩＰ）の場合は，１６進で「００２１」である（ＲＦＣ１３３２で規定）。フレームリレーのＰＩＤ（＃３）の具体値は，ＰＤＵのプロトコル種別で決まり，インターネットプロトコル（ＩＰ）の場合は，１６進で「ＣＣ」である（ＲＦＣ１４９０で規定）。
【００４７】
本発明のアクセスサーバ３は，ＰＰＰフレーム及びフレームリレーフレームのＰＩＤをそれぞれのＰＩＤが示すプロトコル種別に応じて，相互に変換する。フレームリレーフレームのアドレス部Ａ（＃２）は，ＰＰＰプロトコルを収容するシリアル回線と相互接続するルータと接続するフレームリレー回線の論理回線のＤＬＣＩ（データリンク識別子）を表すフレームリレーアドレスに変換される。この変換はＰＰＰ回線からのフレーム受信時に，ルーチングテーブルを参照して行なう。またその逆も同様である。
【００４８】
図５のＢ．は，ＰＰＰフレームのＰＤＵの内容がインターネットプロトコル（ＩＰ）に対応するデータである場合の例であるが，ＰＤＵが他のプロトコルによるデータであっても，ＰＩＤ変換テーブル（図１の３１）によりＰＰＰプロトコルにおける表示から，対応するフレームリレープロトコルにおける表示に変換することができる。
【００４９】
図６はルーチングテーブル１の構成例である。このルーチングテーブル１は上記図２に示す本発明の第２の原理構成に示すルーチングテーブル３３の具体例であり，各ＰＰＰ回線１〜ｎのそれぞれに対し，フレームリレー論理回線番号（ＤＬＣＩ＃１〜ＤＬＣＩ＃ｎ）が対応付けられている。
【００５０】
アクセスサーバ３は，シリアル回線から受信したＰＰＰフレームを上記図５のＢ．によりフレームリレーフレームに変換する。その際，フレームリレーフレームのＡ（アドレス）フィールドの値を，図６に示すルーチングテーブル１を参照して，ＰＰＰのシリアル回線の回線番号と対応するＤＬＣＩ値に変換する。これにより，シリアル回線から受信したデータを，ＰＰＰのシリアル回線番号対応に，フレームリレー回線の特定の論理回線（ＤＬＣＩ）に振り分けるルーチング処理が実現できる。
【００５１】
図７は回線番号による振り分けを行うネットワークの構成例を示す。この例は，アクセスサーバ（ＡＳ）にパソコンＡとパソコンＢがそれぞれ回線Ａ，回線Ｂにより収容され，ＷＡＮ回線であるフレームリレーネットワークを介してルータＡとルータＢがそれぞれリモートＬＡＮＡのサーバＡ，リモートＬＡＮＢのサーバＢと接続されている。アクセスサーバ（ＡＳ）には，上記図６に示すようなルーチングテーブル１が備えられ，これによりパソコンＡの回線Ａがフレームリレーの論理回線番号ＤＬＣＩＡに対応付けられ，パソコンＢの回線Ｂがフレームリレーの論理回線番号ＤＬＣＩＢに対応付けられている。なお，図中のＰＶＣは相手固定接続（Permanent Virtual Circuit)を表す。
【００５２】
図７に示す▲１▼〜▲４▼の方向のデータの送信は次のように行われる。
▲１▼パソコンＡから送出したＰＰＰプロトコルのフレームは，アクセスサーバ（ＡＳ）に入り，アクセスサーバ（ＡＳ）はシリアル回線の回線番号から，ルータＡ向けのＤＬＣＩＡを検索し，上記図５のＢ．の方法でこのＤＬＣＩ値を持ったフレームリレーフレームを組み立てて，ルータＡ向けにデータを送出する。
【００５３】
▲２▼サーバＡからの送出データは，ルータＡでネットワーク層のアドレスに基づくルーチング処理（従来技術による）されて，フレームリレー網を経由してアクセスサーバ（ＡＳ）に到達する。アクセスサーバ（ＡＳ）は，受信したフレームリレーフレームのＰＤＵ内のネットワーク層アドレスを参照して，どのパソコン向けデータであるかを検索し，そのパソコンを接続するシリアル回線に向けて上記図５のＢ．に示すＰＰＰフレームに変換したフレームを送出する。このように，フレーム内のＰＤＵを参照するのは，このパソコン向けデータの出回線を決定する時だけである。これはネットワークのルーチングとは別の処理であり本発明と関連するものではない。
【００５４】
▲３▼，▲４▼のパソコンＢとサーバＢ間も上記▲１▼，▲２▼と同様である。
上記パソコンＡとパソコンＢは同一でもよい。その場合，パソコンがサーバＡと接続する場合は，アクセスサーバ（ＡＳ）の回線Ａに接続し，サーバＢと接続したい場合は回線Ｂに接続することになる。シリアル回線として，電話網やＩＳＤＮ網を使用するが，アクセスサーバ（ＡＳ）の回線選択は，アクセスサーバ（ＡＳ）の回線の電話番号を選択することにより行うことができる。
【００５５】
次に上記６，図７に説明したルーチングテーブル１を用いた場合の端末とアクセスサーバ（ＡＳ）間の制御シーケンスとアクセスサーバ（ＡＳ）の処理動作を図８，図９を用いて説明する。
【００５６】
図８はネットワークの例であり，ＰＰＰの回線として電話またはＩＳＤＮ網が設けられ，複数の端末が電話／ＩＳＤＮ網を介して回線１〜回線５の５回線の何れかと接続することができ，アクセスサーバ（ＡＳ）からフレームリレー網を介して３つのリモートＬＡＮのルータと接続することができ，各ルータＡ〜Ｃはアクセスサーバ（ＡＳ）によりそれぞれＤＬＣＩ＃１，ＤＬＣＩ＃２，ＤＬＣＩ＃３によって接続することができる。
【００５７】
図９はルーチングテーブル１（図６参照）を用いた場合の端末とアクセスサーバ（ＡＳ）間の制御シーケンスとＡＳの処理動作を示し，上記図８のようなネットワークの例において実行される。端末からダイヤルを行うと（図９のａ），電話／ＩＳＤＮ網を介してアクセスサーバ（ＡＳ）３に着信し，アクセスサーバ（ＡＳ）３から端末に対して応答が行われる（同ｂ）。この時，アクセスサーバ（ＡＳ）では，着信回線番号でルーチングテーブル１（図６参照）を検索し，中継ＤＬＣＩを決定する（図９のＳ１）。この後，端末とアクセスサーバ（ＡＳ）の間でＬＣＰ（Link Control Protocol)ネゴシエーション（データ圧縮方式，データサイズ等を決定するためのネゴシエーション）が行われ（図９のｃ），続いて端末からユーザ認証のための情報（ユーザＩＤ等）が送られ（同ｄ），アクセスサーバ（ＡＳ）から認証ＯＫを返すと（同ｅ），ＮＣＰ（ネットワークコントロールプロトコル）ネゴシエーションが行われ（同ｆ），アクセスサーバ（ＡＳ）から端末に対してＩＰアドレスを付与する（同ｇ）。この制御シーケンスのｃ〜ｇの間はアクセスサーバ（ＡＳ）のＰＰＰ回線接続制御（標準動作）の処理として実行される（図９のＳ２）。
【００５８】
この後，端末からＰＰＰフレームによるデータが送られてくると（図９のｈ），アクセスサーバ（ＡＳ）は，上記の処理（Ｓ１）で決定したＤＬＣＩによりフレーム変換処理を行い（図９のＳ３），変換により得られたフレームリレー（ＦＲ）フレームをルータに向けて送信する。また，ルータから送信されたフレームリレーフレームはアクセスサーバ（ＡＳ）で変換されて端末に対しＰＰＰデータとして送信される（図９のｉ）。
【００５９】
図１０はルーチングテーブル２の構成例である。このルーチングテーブル２は上記図３に示す本発明の第３の原理構成に示すルーチングテーブル３５の具体例であり，各ユーザＩＤ１〜ｎのそれぞれに対し，フレームリレー論理回線番号（ＤＬＣＩ＃１〜ＤＬＣＩ＃ｎ）が設定されている。
【００６０】
このユーザＩＤは，パソコン（端末）のユーザ単位に付与するネットワーク加入者識別用のＩＤであり，パソコンがＰＰＰプロトコルでネットワークに接続する際のユーザ認証（認証もＲＦＣで規定されている）に使用する。
【００６１】
アクセスサーバは，シリアル回線から受信したＰＰＰフレームを上記図５のＢ．によりフレームリレーフレームに変換する。その際，フレームリレーフレームのアドレス（Ａ）フィールドの値は，図１０のルーチングテーブル２を参照して，ＰＰＰのシリアル回線のユーザＩＤ値と対応するＤＬＣＩ値を検出して，その値が設定される。これにより，シリアル回線から受信したデータをユーザ対応にフレームリレー回線の特定の論理回線（ＤＬＣＩ）に振り分けるルーチング処理が実現できる。
【００６２】
図１１はユーザＩＤによる振り分けを行うネットワークの構成例を示す。このネットワークの構成は上記図７と同様であるが，アクセスサーバ（ＡＳ）にユーザＡとユーザＢはそれぞれユーザＩＤＡとユーザＩＤＢを備え，アクセスサーバ（ＡＳ）には上記図１０と同様のユーザＩＤＡとユーザＩＤＢに対しそれぞれＤＬＣＩＡとＤＬＣＩＢが設定されたルーチングテーブル２（図１０参照）が備えられ，これによりユーザＩＤＡはフレームリレーの論理回線番号ＤＬＣＩＡに対応付けられ，ユーザＩＤＶがフレームリレーの論理回線番号ＤＬＣＩＢに対応付けられている。この場合，図中の▲１▼〜▲４▼の方向のデータの送信が次のように行われる。
【００６３】
▲１▼ユーザＡからの送出ＰＰＰデータは，アクセスサーバ（ＡＳ）に入る。アクセスサーバ（ＡＳ）は認証により得たユーザＩＤＡを用いて，ルーチングテーブル２からルータＡ向けのＤＬＣＩＡを検索し，上記図５のＢ．のようなフレームリレーフレームを組み立てルータＡ向けにデータを送出する。
【００６４】
▲２▼上記図７に対応する▲２▼の説明と同様の制御によりデータの宛先に対応するユーザのシリアル端末回線に向けＰＰＰデータに変換したフレームが送出される。
ユーザＢとサーバＢ間の▲３▼，▲４▼のデータの送信も同様に行われる。
【００６５】
図１２はルーチングテーブル２を用いた場合の端末とアクセスサーバ（ＡＳ）間の制御シーケンスとＡＳの処理動作を示し，上記図８のようなネットワークの例において実行される。
【００６６】
図１２の端末とアクセスサーバ（ＡＳ）との間の制御シーケンスは，上記図９のａ〜ｉと同様であり説明を省略する。一方，アクセスサーバ（ＡＳ）では，端末からの着信が発生すると，ＰＰＰ回線接続制御（標準動作）が行われる（図１２のＳ１）。この接続制御において端末からユーザ認証のためにユーザＩＤが入力されると，アクセスサーバ（ＡＳ）はユーザＩＤからルーチングテーブル２を検索し，中継ＤＬＣＩ（フレームリレー論理回線番号）を決定する（図１２のＳ２）。その後，端末からＰＰＰデータを受信すると，決定したＤＬＣＩによりフレーム変換（上記図５のＢ．参照）の処理を行い（図１２のＳ３），変換により得られたフレームリレーフレームをルータに向けて送信する。
【００６７】
上記に説明したルーチングテーブル１（図６），ルーチングテーブル２（図１０）を拡張して，各変換先のアドレスを複数個設定したルーチングテーブル３を設けて，アクセスサーバ（ＡＳ）による制御に使用することができる。
【００６８】
図１３はルーチングテーブル３とＤＬＣＩ状態テーブルの構成を示す。
図１３のＡ．はルーチングテーブルの構成例であり，上記ルーチングテーブル１（図６）に対して２個の変換先（第１方路，第２方路という）を設けた例である。同様にルーチングテーブル２（図１０）についても複数の変換先を設けることができる。また，方路は２個に限定することなく任意の個数設けることができる。
図１３のＡ．に示すルーチングテーブル３を使用したアクセスサーバ（ＡＳ）における基本動作において選択する論理回線は，ルーチングテーブル３の第１方路にある値を使用する。アクセスサーバ（ＡＳ）は，フレームリレー回線の各論理回線（ＤＬＣＩで識別する）の状態を常時監視し，図１３のＢ．に示すＤＬＣＩ状態テーブルに監視結果を設定する。この例では，ＤＬＣＩ０，ＤＬＣＩ１はアクティブ（使用可），ＤＬＣＩｋはインアクティブ（使用不可）である。
【００６９】
アクセスサーバ（ＡＳ）は，上記フレームリレーのＤＬＣＩ割り当て時に，第１方路のＤＬＣＩの状態をＤＬＣＩ状態テーブルで確認し，アクティブならばそのＤＬＣＩを使用し，インアクティブである場合は，第２方路のＤＬＣＩを使用する。
【００７０】
図１４はネットワークにおけるルーチングテーブル３を使用した場合の接続動作の説明図である。図１４の例では，パソコンＡが回線Ａによりアクセスサーバ（ＡＳ）と接続され，アクセスサーバ（ＡＳ）のルーチングテーブル３（図示せず）では第１方路としてルータＡへの論理回線（ＤＬＣＩＡ）が設定され，第２方式としてルータＢへの論理回線（ＤＬＣＩＢ）が設定されて，そのＤＬＣＩＡの状態がインアクティブである場合の例である。以下に▲１▼のパソコンＡからの送信，▲２▼のサーバＡからの送信の制御動作を説明する。
【００７１】
▲１▼パソコンＡからの送出したＰＰＰデータは，アクセスサーバ（ＡＳ）に入る。アクセスサーバ（ＡＳ）は，シリアル回線の回線番号からルーチングテーブル３のルータＡ向けの第１方路のＤＬＣＩＡを検索し，このＤＬＣＩの状態を確認する。このＤＬＣＩがインアクティブであるため，第２方路のＤＬＣＩＢを検索し，このＤＬＣＩＢの値を持ったフレームリレーフレームを組み立てて，ルータＢに向けてデータを送出する。ルータＢは，このフレームのＰＤＵ内のネットワークアドレスを参照することにより，通常のルーチング処理を行い，このデータをルータＡ向けに送出する。
【００７２】
▲２▼サーバＡからの送出データは，ルータＡでネットワーク層のアドレスに基づく従来のルーチング処理により，フレームリレーフレームのＰＤＵ内のネットワーク層アドレスを参照して，どのパソコン向けデータであるかを検索し，そのパソコンを接続するシリアル回線に向けてＰＰＰデータに変換したフレームを送出する。
【００７３】
図１５はルーチングテーブル３を用いた場合の端末とアクセスサーバ（ＡＳ）間の制御シーケンスとＡＳの処理動作を示し，上記図８のようなネットワーク構成において実行される。
【００７４】
図１５において，端末とアクセスサーバ（ＡＳ）との間の制御シーケンスは，上記図９及び図１２のａ〜ｉと同様であり説明を省略する。一方，アクセスサーバ（ＡＳ）では，端末からの着信が発生すると，着信回線で，ルーチングテーブル３（図１３のＡ．）を検索し，第１方路のＤＬＣＩを決定する（図１５のＳ１）。次にＤＬＣＩ状態テーブル（図１３のＢ．）を参照し（図１５のＳ２），状態を判別し（同Ｓ３），アクティブの場合は着呼応答（端末に対し着呼したことを応答する）を行う（同Ｓ４）。インアクティブの場合は，ルーチングテーブル３で第２方路のＤＬＣＩを決定し（図１５のＳ５），そのＤＬＣＩについてＤＬＣＩ状態テーブルを参照し（同Ｓ６），状態を判別する（同Ｓ７）。ここで，インアクティブであると着呼させず，アクティブであれば，着呼応答を行う。
【００７５】
着呼応答を行うと，ＰＰＰ回線接続制御（標準動作）を行い（図１５のＳ８），決定したＤＬＣＩによる上記図５のＢ．に示すフレーム変換処理を行う（同Ｓ９）。変換されたフレームはフレームリレー回線に送信される。
【００７６】
次に本発明によるＰＰＰ回線とフレームリレー上の圧縮プロトコルの具体例を示す。この具体例は，上記図４の本発明の第４の原理構成に示すアクセスサーバ（ＡＳ）による圧縮データを含むフレームの変換を実現するためのプロトコルの例である。
【００７７】
図１６はＰＰＰ上の圧縮プロトコルを示し，ＰＰＰ回線へパソコン（端末）またはアクセスサーバ（ＡＳ）から圧縮データを含むフレームを送出する場合に実行される。
【００７８】
図１６のａはＩＰデータを示し，ｂは圧縮なしの場合のＰＰＰ上のフレーム構成であり，ＰＰＰアドレス，フレーム種別（ＵＩ），ＩＰの識別子（ＰＩＤ），ＩＰデータ，ＦＣＳの順に配置され，この前後にフラグ（Ｆ）が付加される。
【００７９】
本発明では，このｂのフレームを圧縮する場合に，データ圧縮範囲を「ＩＰデータ」の部分に限定して，ｃのように圧縮データを含むフレーム構成とする。この時のデータ圧縮方式（圧縮データ識別子により示す）は，任意の既存の方式を使用することができる。ｃの圧縮ありのＰＰＰフレームでは，ＰＰＰアドレス，フレーム種別の値はｂと同じであるが，これに圧縮データの識別子（００ｈ，ＦＤｈの２バイト）が付加され，更にＩＰの識別子がｂと同様に設けられ，圧縮データ，ＦＣＳが配置されている。
【００８０】
図１７はフレームリレー上の圧縮プロトコルを示し，フレームリレー回線に圧縮データを含むフレームを送出する場合に実行される。
図１７のａはＩＰデータであり，ｂは圧縮なしの場合のフレームリレー上のフレーム構成を示し，Ｑ．９２２アドレス，フレーム種別（ＵＩ），ＩＰの識別子，ＩＰデータ及びＦＣＳの順に配置され，この前後にフラグ（Ｆ）が付加される。
【００８１】
本発明では，この図１７のｂのフレームを圧縮する場合に，データ圧縮範囲を上記図１６のＰＰＰ回線の場合と同じの「ＩＰデータ」の部分に限定して，ｃのように圧縮データを含むフレームリレー上のフレームの構成をとる。すなわち，Ｑ．９２２アドレス，フレーム種別の各値は，ｂと同様であり，続いて圧縮データの識別子とＤＣＰ（Data Comprssion Protcol)ヘッダが付加され，これにｂと同じＩＰの識別子，圧縮データ及びＦＣＳが配置される。なお，この時のＩＰデータのデータ圧縮方式は，上記図１６に示すＰＰＰ上の圧縮方式と同じ方式にする。
【００８２】
上記図１６と図１７のように圧縮データを含むフレームを構成することにより，元データ部分（この例では，ＩＰデータ）の圧縮アルゴリズム方式が同一であれば，ＰＰＰとフレームリレーのそれぞれの圧縮後の圧縮データ部分は同一のデータとなる。
【００８３】
ＰＰＰ回線上の圧縮方式のネゴシエーション機能
このＰＰＰ回線上のネゴシエーションは，ＩＥＴＦが規定する圧縮プロトコルのネゴシエーション機能であるＣＣＰプロトコルに準じたネゴシエーションにより行う。すなわち，パソコンに対して圧縮方式のネゴシエーションを行うためのConfigure-Req ／-Ack／-Nak／-Rejの各フレーム( ＣＣＰプロトコル参照）のデータ部分に搭載する圧縮方式を示す新たなオプションタイプ値を設ける。
【００８４】
図１８は圧縮方式を示すオプションタイプ値の例を示し，ａに示すように先頭のType＝０はＣＣＰの規定でベンダー独自（専用）の圧縮方式であることを示し，Length＝７はＣＣＰの規定で，オプションタイプ値の全体長（バイト長）を示し，ＯＵＩはＩＥＥＥ  ８０２委員会の定めるベンダー番号，Subtype とValuesはＣＣＰの規定で，ベンダーが自由に定義してもよい領域である。図１８のｂは，圧縮方法の例に対して定義したSubtype とValuesの例を示す。
【００８５】
フレームリレー回線上の圧縮方式のネゴシエーション機能
フレームリレーフォーラムが規定する圧縮プロトコルのネゴシエーション機能であるＤＣＰＣＰプロトコルに準じ，ルータに対して圧縮方式のネゴシエーションを行い，ＤＣＰＣＰのモード２フォーマットを使用する（ＤＣＰＣＰ参照）。この場合，ネゴシエーションフレームはＰＰＰのＣＣＰプロトコルと同一であり，Configure-Req ／-Ack／-Nak／-Rejの各フレームと同一構成になる。このため，データ部分に搭載する圧縮方式を示す新たなオプションタイプ値は上記図１８と同一である。
【００８６】
このように，ＰＰＰ側の圧縮方式とフレームリレー側の圧縮方式が，アクセスサーバによりそれぞれネゴシエーションされ，圧縮範囲の圧縮アルゴリズムが同一になる場合は，アクセスサーバにより復元・圧縮を行うことなくフレームの変換により中継を行うことができる。もし，いずれか（ＰＰＰ側かフレームリレー側）の圧縮範囲が本発明の方式と一致しない場合，または圧縮の範囲が一致してもその範囲の圧縮アルゴリズムが異なる場合は，ＰＰＰ側もフレームリレー側も圧縮なしの形で通信を行うように再度ネゴシエーションを行うことで，パソコン（端末）またはルータが本発明の圧縮方式をサポートしない場合でも，アクセスサーバ自体が圧縮機能を持たないでもフレーム中継は可能とする。
【００８７】
図１９はＰＰＰとフレームリレー間のアクセスサーバ（ＡＳ）での圧縮伝送の説明図である。
図１９に示すように，圧縮データ部分はＰＰＰとフレームリレーで共通であるため，アドレスの変更，圧縮表示ヘッダの変更，プロトコル識別子の変更及びＦＣＳの変更を行うが，圧縮データについては解凍及び再圧縮をせずにそのままである。このような圧縮データを変更しない点は，ＰＰＰフレームのフレームリレーフレームへの変換とフレームリレーフレームのＰＰＰフレームへの変換の両方に共通する。
【００８８】
参考文献
▲１▼The Compression Control Protocol(CCP)
URL:ftp://ds.internic.net/internetdrafts/draft-ietf-pppext-Compression-04. txt
▲２▼Data Compression Over Frame Relay Implementation Agreement
URL:ftp://ftp.frforum.com/pub/frame-relay/IA/frf9.ps
【００８９】
【発明の効果】
本発明の第１の原理によれば，ＰＰＰプロトコルの端末を収容するアクセスサーバでルーチング処理を行うことなくＷＡＮ回線を介したリモートＬＡＮにデータ転送を行うことが可能となり，アクセスサーバのＣＰＵの負荷を軽減し処理を高速化できる。
【００９０】
また，本発明の第２の原理によれば，端末と接続する回線番号に対応してリモートＬＡＮへの物理／論理回線への振り分けと転送処理を簡単に行うことができる。また，パソコンは接続するリモートＬＡＮに対応して，対応するアクセスサーバの回線を選択して接続することで複数のリモートＬＡＮの何れかのルータを選択することができる。
【００９１】
本発明の第３の原理によれば，ユーザＩＤにより受信データをどのリモートＬＡＮへ転送するかの振り分けが簡単に行うことができる。
また，上記第２，第３の原理により端末は全て特定のルータ（リモートＬＡＮ）にのみダイレクトに接続できるが，これにより，回線番号またはユーザＩＤに対して接続先として登録されていないリモートＬＡＮへの直接アクセスを禁止することができ，セキュリティの向上を実現できる。
【００９２】
また，本発明の圧縮データ方式によれば，異なる通信回線上の圧縮データの共通化及び圧縮対象を限定することで，アクセスサーバにおいてデータの解凍・圧縮を行うことなく圧縮データの中継が可能となる。これにより，アクセスサーバ（ゲートウェイ装置）の負荷軽減と圧縮に必要な高価の機能をアクセスサーバに実装する必要をなくすことができる。
【図面の簡単な説明】
【図１】本発明の第１の原理構成を示す図である。
【図２】本発明の第２の原理構成を示す図である。
【図３】本発明の第３の原理構成を示す図である。
【図４】本発明の第４の原理構成を示す図である。
【図５】ネットワークの構成例とフレーム変換の説明図である。
【図６】ルーチングテーブル１の構成例を示す図である。
【図７】回線番号による振り分けを行うネットワークの構成例を示す図である。
【図８】ネットワークの例を示す図である。
【図９】ルーチングテーブル１を用いた場合の端末とアクセスサーバ間の制御シーケンスとＡＳの処理動作を示す図である。
【図１０】ルーチングテーブル２の構成例を示す図である。
【図１１】ユーザＩＤによる振り分けを行うネットワークの構成例を示す図である。
【図１２】ルーチングテーブル２を用いた場合の端末とアクセスサーバ間の制御シーケンスとＡＳの処理動作を示す図である。
【図１３】ルーチングテーブル３とＤＬＣＩ状態テーブルの構成を示す図である。
【図１４】ネットワークにおけるルーチングテーブル３を使用した場合の接続動作の説明図である。
【図１５】ルーチングテーブル３を用いた場合の端末とアクセスサーバ間の制御シーケンスとＡＳの処理動作を示す図である。
【図１６】ＰＰＰ上の圧縮プロトコルを示す図である。
【図１７】フレームリレー上の圧縮プロトコルを示す図である。
【図１８】圧縮方式を示すオプションタイプ値の例を示す図である。
【図１９】ＰＰＰとフレームリレー間のアクセスサーバでの圧縮伝送の説明図である。
【図２０】ＰＰＰフレーム構成を示す図である。
【図２１】ＷＡＮ等のようなルータネットワーク経由のリモートＬＡＮへシリアル端末を収容する形態を示す図である。
【図２２】ルータネットワーク無しのリモートＬＡＮへシリアル端末を収容する形態を示す図である。
【図２３】従来のデータ圧縮の説明図である。
【図２４】問題点の説明図１である。
【図２５】問題点の説明図２である。
【図２６】ＰＰＰ上とフレームリレー上のフレーム構成を示す図である。
【図２７】ＰＰＰの場合の圧縮無しと圧縮有りのフレーム形式を示す図である。
【図２８】フレームリレーの場合の圧縮無しと圧縮有りのフレーム形式を示す図である。
【符号の説明】
１      端末
２      ＰＰＰ回線
３      アクセスサーバ（ＡＳ）
３０    プロトコル識別子（ＰＩＤ）変換手段
３１    ＰＩＤ変換テーブル
４      ＷＡＮ回線
５      ルータ
６      リモートＬＡＮ
７      サーバ
【図１】
0003735168.tif 000002
【図２】
0003735168.tif 000003
【図３】
0003735168.tif 000004
【図４】
0003735168.tif 000005
【図５】
0003735168.tif 000006
【図６】
0003735168.tif 000007
【図７】
0003735168.tif 000008
【図８】
0003735168.tif 000009
【図９】
0003735168.tif 000010
【図１０】
0003735168.tif 000011
【図１１】
0003735168.tif 000012
【図１２】
0003735168.tif 000013
【図１３】
0003735168.tif 000014
【図１４】
0003735168.tif 000015
【図１５】
0003735168.tif 000016
【図１６】
0003735168.tif 000017
【図１７】
0003735168.tif 000018
【図１８】
0003735168.tif 000019
【図１９】
0003735168.tif 000020
【図２０】
0003735168.tif 000021
【図２１】
0003735168.tif 000022
【図２２】
0003735168.tif 000023
【図２３】
0003735168.tif 000024
【図２４】
0003735168.tif 000025
【図２５】
0003735168.tif 000026
【図２６】
0003735168.tif 000027
【図２７】
0003735168.tif 000028
【図２８】
0003735168.tif 000029