JPH10173708A - 簡易ルーチング方式 - Google Patents

Abstract

(57)【要約】 【課題】本発明はＰＰＰプロトコルによる回線を介して
複数の端末を収容し，リモートＬＡＮのルータとＷＡＮ
回線で接続するアクセスサーバにおける簡易ルーチング
方式に関し，アクセスサーバにおける処理の負担を軽減
することができることを目的とする。 【解決手段】アクセスサーバは，プロトコル識別子を変
換する手段と，ＰＰＰプロトコルにおけるＰＤＵの各プ
ロトコル識別子に対応するＷＡＮ回線のプロトコルにお
けるプロトコル識別子が格納された変換テーブルを備え
る。ＰＰＰ回線から受信したＰＰＰフレームのＰＤＵ内
のネットワークアドレス等の情報を参照することなく，
受信したＰＰＰフレームのプロトコル識別子を用いて対
応するＷＡＮ回線のプロトコル識別子を変換テーブルに
より検出して，検出したＰＩＤにより前記ＰＰＰフレー
ムのＰＩＤを変換してＰＤＵをそのままＷＡＮ回線のフ
レームにカプセル化してルータ向けに転送するよう構成
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はＰＰＰ（Point to P
oint Protocol)を使用してＬＡＮに接続されたサーバに
アクセスするためのＰＰＰアクセス簡易ルーチング方式
に関する。

【０００２】近年，端末またはサーバから他の端末また
はサーバに接続するため，ＰＰＰと呼ばれるプロトコル
がインターネットのプロトコルとして利用されるように
なった。このＰＰＰにより公衆網からＬＡＮに接続され
たアクセスサーバにアクセスし，そのアクセスサーバか
らそのＬＡＮ内のサーバに直接接続したり，専用線等の
ルータネットワークを介して遠隔（リモート）のＬＡＮ
のサーバにアクセスすることができる。

【０００３】このようなＰＰＰを使用する端末がアクセ
スサーバに接続した後，リモートＬＡＮのサーバにアク
セスする場合，アクセスサーバでルーチング処理を行う
必要があり，ルーチング処理をしないようにすると異な
るリモートＬＡＮに接続できなくなったり，セキュリテ
ィの制御が複雑になり，更に異なるプロトコル間でデー
タ圧縮を行うための処理が複雑化する。

【０００４】

【従来の技術】ＰＰＰは，Point to Point Protocol の
略名であり，ＰＰＰの機能の詳細は，インターネットの
プロトコルの標準化を行う米国の組織ＩＥＴＦ（Intern
et Engineering Task Force)により，ＲＦＣ(Request F
or Comments)と呼ぶドキュメントにまとめられている。
なお，ＰＰＰは複数のＲＦＣで規定されていて，プロト
コルの基本部分を規定するのはＲＦＣ１６６１である。

【０００５】具体的にはＰＰＰは各種の通信プロトコル
データを専用線，ＩＳＤＮ交換回線，電話回線等のシリ
アル回線上に転送するためのプロトコルである。これら
のシリアル回線上にデータを転送する場合，データの始
まりと終了を検出する方法が必要であり，ＰＰＰはフラ
グと呼ばれる８ビットパターン「01111110」（Ｆで表
す）をデータの開始と終了とするＨＤＬＣ（High level
Data Link Control) フレーミングを使用する。

【０００６】図２０にＰＰＰフレーム構成を示す。図
中，Ｆはフラグ，Ａは１バイトのアドレスでありＰＰＰ
の場合「11111111」に固定される。Ｃは１バイトの制御
を表し，ＰＰＰの場合「00000011」に固定される。ＰＩ
Ｄは２バイトのプロトコル識別子（Protocol IDentifir
e)，ＰＤＵはＰＰＰプロトコルの上位レイヤから渡され
たデータ（制御データを含む）が設定されるプロトコル
データユニット，ＦＣＳは２バイトのフレームの正常受
信を確認するためのフレームチェックシーケンスであ
る。

【０００７】ＰＰＰは大別すると次の，の２つのネ
ットワークの形態で使用され，図２１，図２２を用いて
説明する。 図２１に示すＷＡＮ等のようなルータネットワーク経
由のリモートＬＡＮへシリアル端末を収容する形態の場
合 シリアル端末８０は電話回線，ＩＳＤＮ電話回線等のシ
リアル回線８１を介してＰＰＰによりアクセスサーバ
（ＡＳで表示）８２（ＴＣＰ／ＩＰのアクセスポイン
ト）に収容され，リモートＬＡＮ８６のサーバ８７に接
続するためには，アクセスサーバ８２のＬＡＮ８３から
ルータ（Ｒで表示）８４と回線（専用線等）８５で構成
するルータネットワークを経由して遠隔に設けられたリ
モートＬＡＮ８６のサーバ８７と接続される。

【０００８】このネットワーク形態の場合，シリアル端
末８０とアクセスサーバ（ＡＳ）８２間はＰＰＰプロト
コルで通信する。通常アクセスサーバ（ＡＳ）８２はＰ
ＰＰフレームをシリアル端末８０から受信し，ＰＰＰフ
レームのＰＩＤを参照してＰＤＵ部分をＰＩＤが示すプ
ロトコル種別に応じたＬＡＮ８３のデータ形式に変換し
て，ＬＡＮ８３経由でルータ（Ｒ）８４に転送する。ル
ータ（Ｒ）８４は各プロトコルに応じたＰＤＵ内のネッ
トワークアドレスによりルーチングを行い，次のルータ
に向けてデータを転送する。その後データはルータネッ
トワークでルーチングされて，リモートＬＡＮ８６上に
ある目的のサーバ８７まで到達する。サーバ８７からシ
リアル端末８０までのデータ転送はその逆の処理で行わ
れる。

【０００９】図２２に示すルータネットワーク無しの
リモートＬＡＮへシリアル端末を収容する形態の場合 この形態は，上記より単純で，アクセスサーバ（Ａ
Ｓ）に直接リモートＬＡＮ８６が接続され，シリアル端
末８０とサーバ８７がルータを経由しないで接続され
る。

【００１０】上記のような形態では問題が少なく，
のように比較的規模の大きいネットワーク形態に適用さ
れる従来の技術を説明する。ここでアクセスサーバ（Ａ
Ｓ）の機能は基本的には上記で説明したように，ＰＰ
Ｐによるシリアル回線の制御と，ルータと接続するＬＡ
Ｎ回線の制御であるが，以下の説明ではアクセスサーバ
（ＡＳ）とＬＡＮで接続されたルータ（Ｒ）を含めて考
える。また，実際のアクセスサーバの製品にはルータ機
能まで一つの物理装置として一体化したものが多く，そ
の場合上記図２１のアクセスサーバ（ＡＳ）とルータは
一体化し，両者を接続するＬＡＮは物理的に存在しない
形になる。また，シリアル端末８０は，通常パーソナル
コンピュータ（パソコン）であり，以下の説明ではシリ
アル端末の代わりにパソコンという用語も使用する。

【００１１】次に異なる回線を介する従来のデータ圧縮
について説明する。回線を有効利用する方法の１つとし
てデータ圧縮がある。データ圧縮についても標準化が進
められているが，回線の種別により異なった標準化が行
われているのが現状である。このため，アクセスサーバ
のように異なる通信回線の間を相互に接続する装置で
は，圧縮されたデータをそれぞれの回線種別に応じて圧
縮し直す必要がある。

【００１２】図２３は従来のデータ圧縮の説明図であ
る。このネットワーク構成は，パソコンＡとアクセスサ
ーバ（ＡＳ）の間はＰＰＰプロトコルによる回線であ
り，アクセスサーバ（ＡＳ）からリモートＬＡＮのルー
タまでのルータネットワークがフレームリレー回線であ
る例である。この場合，パソコンからアクセスサーバ
（ＡＳ）に向けて送出するデータａは，ＰＰＰのデータ
圧縮のルール（上記ＩＥＴＦの規定するルール）に従っ
て圧縮し，そのルールの圧縮識別子を付与してフレーム
ｂとしてＰＰＰ回線に送出する。アクセスサーバ（Ａ
Ｓ）は，その圧縮データを受信して，一旦解凍して基の
データを復元する。次にフレームリレーの圧縮方式（フ
レームリレーフォーラムの規定するルール）に従って圧
縮し，識別子を付与したフレームｃをフレームリレー回
線に向けて送出する。ルータはフレームリレー回線から
の受信データを識別子に従って解凍してデータｄを復元
する。サーバからパソコン向けのデータに関しても同様
である。

【００１３】

【発明が解決しようとする課題】従来のシリアル端末
（パソコン）からルータネットワークを介してリモート
ＬＡＮのサーバとデータを転送する場合の問題点を以下
に図を用いて説明する。

【００１４】(1) ネットワーク層ルーチングの処理負荷 従来の上記図２１に示す構成におけるアクセスサーバ
（ＡＳ）は，シリアル回線からＰＰＰフレームを受信す
ると，受信したＰＰＰフレーム毎にＰＩＤフィールドの
プロトコル識別子が示すネットワーク層プロトコル処理
部（図示省略）にデータを渡し，そのプロトコル処理部
でＰＤＵデータ内のネットワークアドレスに基づいたル
ーチング処理を行う。これは，ごく普通に行われる処理
であり汎用性がある反面，次ような問題がある。

【００１５】ネットワーク層のルーチング機能が必須で
ある。すなわち，アクセスサーバは，ネットワーク層で
ルーチングするため，ネットワーク層のルーチング処理
機能が必要である。この処理はＰＰＰ回線で送受信する
すべてのデータ（フレームの一つ一つ）に対して行う必
要があり，アクセスサーバのＣＰＵ負荷増大によるスル
ープット低下や，各フレーム毎の処理によるデータ転送
遅延が増大するという問題があった。

【００１６】(2) パソコン（ユーザ）単位のデータ振り
分け 上記(1) の問題は，データ内のネットワークアドレスに
よるルーチング処理をせずに，目的のリモートＬＡＮの
ルータまでデータを転送することで解決できる。しか
し，この場合，１台のアクセスサーバに収容されたパソ
コンから，異なるリモートＬＡＮに接続する場合に，ネ
ットワーク層のアドレスによるルーチング処理を行って
リモートＬＡＮを選択することができなくなるという問
題が発生する。

【００１７】これを図２４に示す問題点の説明図１を用
いて説明する。この例は，パソコンＡがリモートＬＡＮ
ＡのサーバＡに接続し（図中のａの経路），パソコンＢ
がリモートＬＡＮＢのサーバＢに接続する（図中のｂの
経路）ようにしたい場合である。アクセスサーバがルー
チング機能を持てば，データのネットワークアドレスに
よるルーチング処理で，サーバＡとサーバＢへ振り分け
を行うことは容易であるが，フレームのＰＤＵ内のネッ
トワークアドレスを処理する必要があるため上記(1) の
問題を解決することができない。

【００１８】(3) セキュリティ ネットワーク層のアドレスでルーチングを行うアクセス
サーバの場合，サーバへのアクセスを制限しようとする
と，ルーチングの場合と同様パソコンから送信されるＰ
ＰＰフレーム中のＰＤＵを参照し，ＰＤＵ内の発ネット
ワークアドレスをチェックして，これをアクセスサーバ
が規制するかどうかの制御が必要になる。

【００１９】これを図２５に示す問題点の説明図２を用
いて説明する。パソコンＡはリモートＬＡＮＡにだけア
クセスを可能とし，パソコンＢはリモートＬＡＮＢにだ
けアクセスを可能とし，他へのアクセスを禁止する場
合，例えば，パソコンＡがリモートＬＡＮＢのサーバＢ
にアクセスさせないようにしようとすると，アクセスサ
ーバには，パソコンＡから受信したＰＰＰフレーム内の
ＰＤＵの発ネットワークアドレスを確認し，発ネットワ
ークアドレスがＡで，宛先ネットワークアドレスがリモ
ートＬＡＮＢになっているフレームを廃棄する処理が必
要になる。この処理はルーチング処理以上に複雑であ
り，運用管理も複雑化する。このため，アクセスサーバ
の負荷を軽減しようとすると完全なセキュリティ確保が
困難になるという問題がある。

【００２０】(4) データ圧縮 図２３で説明した従来のデータ圧縮の問題点を具体例に
より説明する。図２６はＰＰＰ上とフレームリレー上の
フレーム構成を示し，ＰＤＵ内のプロトコルがインター
ネット標準プロトコルであるＩＰ（Internet Protocol)
である例を示す。このＩＰデータ（図２６のａ）を専用
線や電話回線に送出する時のフレーム形式はＰＰＰプロ
トコル（ＲＦＣ１６６１）で規定されており図２６のｂ
のようなＰＰＰアドレス，フレーム種別，ＩＰの識別子
とＩＰデータ等で構成され，フレームリレー網に送出す
る時のフレーム形式はＩＴＵ−ＴのＱ．９２２及びＸ．
３６で規定された図２６のｃに示す構成を備えている。

【００２１】このようにＰＰＰとフレームリレーでは，
同じＩＰデータに対する識別子が，それぞれ異なる。こ
こではＩＰを例として示すが，その他の種別のデータ
（ＩＰＸやＣＬＮＰ等）に関してもそれぞれＰＰＰとフ
レームリレーではプロトコル識別子の数値が異なる。

【００２２】このようなフレームを圧縮して転送する場
合，フレーム形式はＰＰＰの場合はＩＥＴＦ，フレーム
リレーの場合はフレームリレーフォーラムで規定されて
おり，いずれも元データの識別子（図２６のａ，ｂの太
線で囲まれた部分）を含む範囲を圧縮することになって
いる。従って，同一の圧縮アルゴリズムで圧縮しても，
圧縮されたデータ部分の中身が，ＰＰＰの場合とフレー
ムリレーの場合とでは異なることになる。

【００２３】これを更に図２７と２８を用いて説明する
と，図２７はＰＰＰの場合の圧縮無しと圧縮有りのフレ
ーム形式を示し，図２８はフレームリレーの場合の圧縮
無しと圧縮有りのフレーム形式を示す。何れの場合もＰ
ＤＵがＩＰデータの場合であり，ＰＰＰとフレームリレ
ーでは圧縮対象範囲にあるプロトコル識別子部分の相違
により，圧縮データ部分は同一にならないことが明らか
である。このため，ＰＰＰ回線とフレームリレー回線の
間でそれぞれの通信の仲介をするアクセスサーバは，一
方から受信したデータが圧縮されたデータである場合，
その圧縮データ部分を一旦解凍して元データに戻し，送
出側の回線種別に従った圧縮アルゴリズムで圧縮しなお
して送信するか，送信側は圧縮せずに送信するしか方法
がなかった。

【００２４】このように，種別の異なる回線間を接続す
るアクセスサーバでは，両方の回線で圧縮を行う場合，
データ解凍・圧縮の処理が必要になるため，ＣＰＵやメ
モリ等のリソースを多く消費するという問題があった。

【００２５】更に，アクセスサーバとしてデータ圧縮機
能を持たない装置を設けた場合，パソコンやルータがデ
ータ圧縮可能でも，上記図２３のエンド・エンド間通信
においてデータ圧縮が不可能となり，元のデータのまま
の通信しかできないという問題があった。

【００２６】本発明は上記の各問題を解決することを目
的とし，具体的にはアクセスサーバにおける処理の負担
を軽減することができるＰＰＰアクセス簡易ルーチング
方式を提供することを目的とする。また，ユーザ単位の
データの振り分けを可能にすること，及びリモートＬＡ
Ｎへのアクセスを端末に応じて規制してセキュリティを
保持すること，更にデータ圧縮をアクセスサーバに負担
をかけることなく行うことができるＰＰＰアクセス簡易
ルーチング方式を提供することを目的とする。

【００２７】

【課題を解決するための手段】図１は本発明の第１の原
理構成である。図中，１はパソコン等の端末，２は電話
網，専用線，ＩＳＤＮ等のＰＰＰ回線，３はアクセスサ
ーバ（ＡＳ），３０はプロトコル識別子（ＰＩＤ:Proto
col 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-iet
f-pppext-Compression-04. txt Data Compression Over Frame Relay Implementation
Agreement URL:ftp://ftp.frforum.com/pub/frame-relay/IA/frf9.
ps

【００８９】

【発明の効果】本発明の第１の原理によれば，ＰＰＰプ
ロトコルの端末を収容するアクセスサーバでルーチング
処理を行うことなくＷＡＮ回線を介したリモートＬＡＮ
にデータ転送を行うことが可能となり，アクセスサーバ
のＣＰＵの負荷を軽減し処理を高速化できる。

【００９０】また，本発明の第２の原理によれば，端末
と接続する回線番号に対応してリモートＬＡＮへの物理
／論理回線への振り分けと転送処理を簡単に行うことが
できる。また，パソコンは接続するリモートＬＡＮに対
応して，対応するアクセスサーバの回線を選択して接続
することで複数のリモートＬＡＮの何れかのルータを選
択することができる。

【００９１】本発明の第３の原理によれば，ユーザＩＤ
により受信データをどのリモートＬＡＮへ転送するかの
振り分けが簡単に行うことができる。また，上記第２，
第３の原理により端末は全て特定のルータ（リモートＬ
ＡＮ）にのみダイレクトに接続できるが，これにより，
回線番号またはユーザＩＤに対して接続先として登録さ
れていないリモートＬＡＮへの直接アクセスを禁止する
ことができ，セキュリティの向上を実現できる。

【００９２】また，本発明の圧縮データ方式によれば，
異なる通信回線上の圧縮データの共通化及び圧縮対象を
限定することで，アクセスサーバにおいてデータの解凍
・圧縮を行うことなく圧縮データの中継が可能となる。
これにより，アクセスサーバ（ゲートウェイ装置）の負
荷軽減と圧縮に必要な高価の機能をアクセスサーバに実
装する必要をなくすことができる。

【図面の簡単な説明】

【図１】本発明の第１の原理構成を示す図である。

【図２】本発明の第２の原理構成を示す図である。

【図３】本発明の第３の原理構成を示す図である。

【図４】本発明の第４の原理構成を示す図である。

【図５】ネットワークの構成例とフレーム変換の説明図
である。

【図６】ルーチングテーブル１の構成例を示す図であ
る。

【図７】回線番号による振り分けを行うネットワークの
構成例を示す図である。

【図８】ネットワークの例を示す図である。

【図９】ルーチングテーブル１を用いた場合の端末とア
クセスサーバ間の制御シーケンスとＡＳの処理動作を示
す図である。

【図１０】ルーチングテーブル２の構成例を示す図であ
る。

【図１１】ユーザＩＤによる振り分けを行うネットワー
クの構成例を示す図である。

【図１２】ルーチングテーブル２を用いた場合の端末と
アクセスサーバ間の制御シーケンスとＡＳの処理動作を
示す図である。

【図１３】ルーチングテーブル３とＤＬＣＩ状態テーブ
ルの構成を示す図である。

【図１４】ネットワークにおけるルーチングテーブル３
を使用した場合の接続動作の説明図である。

【図１５】ルーチングテーブル３を用いた場合の端末と
アクセスサーバ間の制御シーケンスとＡＳの処理動作を
示す図である。

【図１６】ＰＰＰ上の圧縮プロトコルを示す図である。

【図１７】フレームリレー上の圧縮プロトコルを示す図
である。

【図１８】圧縮方式を示すオプションタイプ値の例を示
す図である。

【図１９】ＰＰＰとフレームリレー間のアクセスサーバ
での圧縮伝送の説明図である。

【図２０】ＰＰＰフレーム構成を示す図である。

【図２１】ＷＡＮ等のようなルータネットワーク経由の
リモートＬＡＮへシリアル端末を収容する形態を示す図
である。

【図２２】ルータネットワーク無しのリモートＬＡＮへ
シリアル端末を収容する形態を示す図である。

【図２３】従来のデータ圧縮の説明図である。

【図２４】問題点の説明図１である。

【図２５】問題点の説明図２である。

【図２６】ＰＰＰ上とフレームリレー上のフレーム構成
を示す図である。

【図２７】ＰＰＰの場合の圧縮無しと圧縮有りのフレー
ム形式を示す図である。

【図２８】フレームリレーの場合の圧縮無しと圧縮有り
のフレーム形式を示す図である。

【符号の説明】

１ 端末 ２ ＰＰＰ回線 ３ アクセスサーバ（ＡＳ） ３０ プロトコル識別子（ＰＩＤ）変換手段 ３１ ＰＩＤ変換テーブル ４ ＷＡＮ回線 ５ ルータ ６ リモートＬＡＮ ７ サーバ

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ＰＰＰプロトコルによる回線を介して複
   数の端末を収容し，リモートＬＡＮのルータとＷＡＮ回
   線で接続するアクセスサーバにおける簡易ルーチング方
   式において，アクセスサーバは，プロトコル識別子（Ｐ
   ＩＤ）を変換するＰＩＤ変換手段と，ＰＰＰプロトコル
   におけるＰＤＵの各プロトコル識別子に対応するＷＡＮ
   回線のプロトコルにおけるプロトコル識別子が格納され
   たＰＩＤ変換テーブルを備え，アクセスサーバは，ＰＰ
   Ｐ回線から受信したＰＰＰフレームのＰＤＵ内のネット
   ワークアドレス等の情報を参照することなく，受信した
   ＰＰＰフレームのプロトコル識別子を用いて対応するＷ
   ＡＮ回線のプロトコル識別子を前記ＰＩＤ変換テーブル
   により検出して，検出したＰＩＤにより前記ＰＰＰフレ
   ームのＰＩＤを変換してＰＤＵをそのままＷＡＮ回線の
   フレームにカプセル化してルータ向けに転送することを
   特徴とする簡易ルーチング方式。
2. 【請求項２】 請求項１に記載のアクセスサーバであっ
   て，前記アクセスサーバが複数のリモートＬＡＮのルー
   タとＷＡＮの物理回線または論理回線で接続され，前記
   アクセスサーバは，アドレス変換手段と，端末と接続制
   御により接続する回線の番号または端末と固定接続する
   回線番号と前記各ルータと接続するＷＡＮの物理（また
   は論理）回線番号とを対応付けるルーチングテーブルを
   備え，端末からのフレームを受信すると，前記アドレス
   変換手段は前記端末が接続する回線番号により前記ルー
   チングテーブルを検索して，対応するＷＡＮの物理（ま
   たは論理）回線番号を求め，受信したフレームのＰＩＤ
   の変換によりＷＡＮ回線対応のデータとした上で求めた
   ＷＡＮの物理（または論理）回線に送出することを特徴
   とする簡易ルーチング方式。
3. 【請求項３】 請求項１において，前記アクセスサーバ
   が複数のリモートＬＡＮのルータとＷＡＮの物理回線ま
   たは論理回線と接続され，前記アクセスサーバは，アド
   レス変換手段と，端末毎のユーザに付与されているユー
   ザＩＤと各ユーザＩＤに対応して設定されたリモートＬ
   ＡＮのルータと接続するＷＡＮの物理（または論理）回
   線番号とを対応付けるルーチングテーブルを備え，アク
   セスサーバのアドレス変換手段は，端末からのフレーム
   を受信すると，端末と接続制御における認証制御により
   得たユーザＩＤまたは端末と固定接続した回線に対応す
   るユーザＩＤにより，上記ルーチングテーブルを検索し
   て対応するＷＡＮの物理（または論理）回線番号を求
   め，受信したフレームのＰＩＤの変換によりＷＡＮ回線
   対応のデータとした上で求めたＷＡＮの物理（または論
   理）回線に送出することを特徴とする簡易ルーチング方
   式。
4. 【請求項４】 請求項２または３のいずれかにおいて，
   ルーチングテーブルは，端末と接続制御により接続する
   回線（または端末と固定接続する回線）番号または端末
   のユーザＩＤに対して，接続可能な複数のリモートＬＡ
   Ｎのルータと接続する各ＷＡＮの物理（論理）回線を対
   応付けると共に第１方路，第２方路，…第ｎ方路という
   優先順位を表す属性を設定した構成を備え，前記アドレ
   ス変換手段は，各回線番号またはユーザＩＤに対応する
   ＷＡＮの物理（論理）回線の中から，使用可能な上位の
   方路から選択を行うことを特徴とする簡易ルーチング方
   式。
5. 【請求項５】 ＰＰＰプロトコルによる回線を介して複
   数の端末を収容し，リモートＬＡＮのルータとＷＡＮ回
   線で接続するアクセスサーバにおける圧縮データを含む
   フレームのルーチングを含む簡易ルーチング方式におい
   て，前記ＰＰＰ回線上のデータ圧縮プロトコルとして，
   データ圧縮範囲をネットワーク層データ部分として，こ
   れを任意の圧縮アルゴリズムで圧縮したデータを含むフ
   レームとするプロトコルを用い，前記ＷＡＮ回線上のデ
   ータ圧縮プロトコルとして，データ圧縮の範囲をネット
   ワーク層データ部分として，これを前記ＰＰＰ回線の圧
   縮アルゴリズムと同じ圧縮アルゴリズムで圧縮したデー
   タを含むフレームとするプロトコルとし，前記アクセス
   サーバは，ＰＰＰ回線からの圧縮データを含むフレーム
   を受信すると，データ部分については変更せず，アドレ
   ス，圧縮表示，及びプロトコル識別子（ＰＩＤ）をＷＡ
   Ｎ回線の対応するアドレス，圧縮表示及びＰＩＤに変換
   する圧縮データフレーム変換部を備え，変換されたフレ
   ームをＷＡＮ回線に送信する手段を備えることを特徴と
   する簡易ルーチング方式。
6. 【請求項６】 請求項５において，前記アクセスサーバ
   は，ＰＰＰ回線で接続する端末との間で，ＩＥＴＦが規
   定する圧縮方式のネゴシエーションのＣＣＰプロトコル
   により，前記データ圧縮範囲及び圧縮アルゴリズムを含
   むネゴシエーションを行うことを特徴とする簡易ルーチ
   ング方式。
7. 【請求項７】 請求項５において，前記ＷＡＮ回線をフ
   レームリレー回線で構成され，前記アクセスサーバは，
   フレームリレー回線で接続するルータとの間で，フレー
   ムリレーフォーラムが規定する圧縮方式のネゴシエーシ
   ョンのＤＣＰＣＰプロトコルにより，前記データ圧縮範
   囲及び圧縮アルゴリズムを含むネゴシエーションを行う
   ことを特徴とする簡易ルーチング方式。