JPH1051465A - Ａｔｍ網におけるサーバー予測型呼管理方式 - Google Patents
Ａｔｍ網におけるサーバー予測型呼管理方式Info
- Publication number
- JPH1051465A JPH1051465A JP20680896A JP20680896A JPH1051465A JP H1051465 A JPH1051465 A JP H1051465A JP 20680896 A JP20680896 A JP 20680896A JP 20680896 A JP20680896 A JP 20680896A JP H1051465 A JPH1051465 A JP H1051465A
- Authority
- JP
- Japan
- Prior art keywords
- server
- call
- terminal
- information exchange
- calling means
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
(57)【要約】
【課題】ＬＡＮのプロトコルを、ＡＴＭ上に実装する網
に関し、ＬＡＮのプロトコルによるパケットの、発呼に
よる送信待ち時間を短縮するための、ＡＴＭ網における
サーバー予測呼管理方式を提供する。 【解決手段】ＬＡＮのプロトコルをＡＴＭ上に実装する
網において、ＬＡＮに属しかつＡＴＭ網に直結する各端
末に事前発呼手段１を設ける。そして事前発呼手段１
が、各サービスごとにサーバーを予測して、サーバーと
の間で事前発呼によって予め呼を張っておくことによっ
て、ＬＡＮのプロトコルに基づくパケットによる発呼要
求発生時、サーバーがパケットを各端末にブロードキャ
ストし、端末間の呼の発呼終了時、端末間の通信に切り
替えることによって、発呼に基づくパケット送信遅延を
減少させる。
に関し、ＬＡＮのプロトコルによるパケットの、発呼に
よる送信待ち時間を短縮するための、ＡＴＭ網における
サーバー予測呼管理方式を提供する。 【解決手段】ＬＡＮのプロトコルをＡＴＭ上に実装する
網において、ＬＡＮに属しかつＡＴＭ網に直結する各端
末に事前発呼手段１を設ける。そして事前発呼手段１
が、各サービスごとにサーバーを予測して、サーバーと
の間で事前発呼によって予め呼を張っておくことによっ
て、ＬＡＮのプロトコルに基づくパケットによる発呼要
求発生時、サーバーがパケットを各端末にブロードキャ
ストし、端末間の呼の発呼終了時、端末間の通信に切り
替えることによって、発呼に基づくパケット送信遅延を
減少させる。
Description
【０００１】
【発明の属する技術分野】本発明は、ＬＡＮ（Local Ar
ea Network）の事実上の標準プロトコルであるＩＰ（In
ternet Protocol ）を、ＡＴＭ（Asynchronous Transfe
r Mode）上に実装する方式であるＩＰＯＡ（IP over AT
M ）に関し、特にＩＰＯＡを実現する際に、発呼による
送信待ち時間を短縮するための、ＡＴＭ網におけるサー
バー予測型呼管理方式に関するものである。
ea Network）の事実上の標準プロトコルであるＩＰ（In
ternet Protocol ）を、ＡＴＭ（Asynchronous Transfe
r Mode）上に実装する方式であるＩＰＯＡ（IP over AT
M ）に関し、特にＩＰＯＡを実現する際に、発呼による
送信待ち時間を短縮するための、ＡＴＭ網におけるサー
バー予測型呼管理方式に関するものである。
【０００２】
【従来の技術】端末のマルチメディア化や、高速通信に
対応可能なネットワーク実現技術として、ＡＴＭ技術を
用いた広帯域通信網が着目され、そのＬＡＮに対する適
応が、各企業や大学等において進められている。そのた
め、ＬＡＮの事実上の標準プロトコルであるＩＰを、Ａ
ＴＭ上に実装する方式であるＩＰＯＡが、ＩＥＴＦ（In
ternet Engineering Task Force ）等において検討され
ており、その成果はＲＦＣ（Request for Comment ）１
５７７等において発表されている。
対応可能なネットワーク実現技術として、ＡＴＭ技術を
用いた広帯域通信網が着目され、そのＬＡＮに対する適
応が、各企業や大学等において進められている。そのた
め、ＬＡＮの事実上の標準プロトコルであるＩＰを、Ａ
ＴＭ上に実装する方式であるＩＰＯＡが、ＩＥＴＦ（In
ternet Engineering Task Force ）等において検討され
ており、その成果はＲＦＣ（Request for Comment ）１
５７７等において発表されている。
【０００３】ＲＦＣ１５７７では、ＬＩＳ（Logical IP
Subnet ）が定義され、同一のＬＩＳに属し、かつＡＴ
Ｍに直結している端末やネットワーク機器どうしが、Ｉ
Ｐパケットをやりとりする際には、直接、呼を張るが、
異なるＬＩＳに跨がる端末間の通信では、ルーターを経
由する呼を張る仕様となっている。
Subnet ）が定義され、同一のＬＩＳに属し、かつＡＴ
Ｍに直結している端末やネットワーク機器どうしが、Ｉ
Ｐパケットをやりとりする際には、直接、呼を張るが、
異なるＬＩＳに跨がる端末間の通信では、ルーターを経
由する呼を張る仕様となっている。
【０００４】図４は、ＲＦＣ１５７７の原理的構成を示
したものである。図示のように、ＬＩＳ−Ａに属する端
末Ａ，Ｂ，Ｃ、およびＬＩＳ−Ｂに属する端末Ｄ，Ｅ，
Ｆは、それぞれのＬＩＳ内において直接、呼を張って通
信することができるが、異なるＬＩＳに属する端末相互
間、例えば端末Ａ，Ｄ間においては、直接、呼を張るこ
とができず、ＡＴＭルーターを経由して呼を張って、通
信することが示されている。
したものである。図示のように、ＬＩＳ−Ａに属する端
末Ａ，Ｂ，Ｃ、およびＬＩＳ−Ｂに属する端末Ｄ，Ｅ，
Ｆは、それぞれのＬＩＳ内において直接、呼を張って通
信することができるが、異なるＬＩＳに属する端末相互
間、例えば端末Ａ，Ｄ間においては、直接、呼を張るこ
とができず、ＡＴＭルーターを経由して呼を張って、通
信することが示されている。
【０００５】
【発明が解決しようとする課題】このように、ＩＰＯＡ
では、イーサネット（Ethernet）やＦＤＤＩ（Fiber Di
stributed Data Interface）等のような、既存のＬＡＮ
と異なり、送信元がＩＰパケットを出力する際には、予
め送信先との間に、呼を張っておく必要がある。従っ
て、ＩＰパケット送信時に、相手端末との間に呼が張ら
れていない場合には、例えば発呼が終了するまで、ＩＰ
パケットの送信を行うことができないという問題が生じ
る。
では、イーサネット（Ethernet）やＦＤＤＩ（Fiber Di
stributed Data Interface）等のような、既存のＬＡＮ
と異なり、送信元がＩＰパケットを出力する際には、予
め送信先との間に、呼を張っておく必要がある。従っ
て、ＩＰパケット送信時に、相手端末との間に呼が張ら
れていない場合には、例えば発呼が終了するまで、ＩＰ
パケットの送信を行うことができないという問題が生じ
る。
【０００６】すなわちＩＰＯＡでは、ＩＰパケットを送
信する場合には、ＩＰアドレス→ＡＴＭアドレスの解決
を行ない、解決されたＡＴＭアドレスを用いて、送信先
に対して発呼する。このため、送信ＩＰパケットが発生
してから、アドレス解決と発呼を行う方法では、送信元
では、呼が確立するまでの間、ＩＰパケットを送信する
ことができない。
信する場合には、ＩＰアドレス→ＡＴＭアドレスの解決
を行ない、解決されたＡＴＭアドレスを用いて、送信先
に対して発呼する。このため、送信ＩＰパケットが発生
してから、アドレス解決と発呼を行う方法では、送信元
では、呼が確立するまでの間、ＩＰパケットを送信する
ことができない。
【０００７】このような問題点を解決する方法の一つと
して、ブロードキャストサーバーを使用することが考え
られる。ここでブロードキャストサーバーとは、例えば
ＬＩＳ内のすべての端末やネットワーク機器に対して、
ＩＰパケットをブロードキャストする機能を有する機器
を指している。
して、ブロードキャストサーバーを使用することが考え
られる。ここでブロードキャストサーバーとは、例えば
ＬＩＳ内のすべての端末やネットワーク機器に対して、
ＩＰパケットをブロードキャストする機能を有する機器
を指している。
【０００８】ブロードキャストサーバーを使用した場合
の、送信手順は次のようになる。 1．送信ＩＰパケット発生後、送信元と送信先との間に
呼が張られるまでの期間、送信端末は、ブロードキャス
トサーバーにＩＰパケットを送信する。 2. ブロードキャストサーバーは、受信したＩＰパケッ
トを、すべての端末に対してブロードキャストする。 3．送信元から送信先までの間に、呼が張られた後は、
送信端末は、ブロードキャストサーバーを使用せずに、
直接、ＩＰパケットを送信する。
の、送信手順は次のようになる。 1．送信ＩＰパケット発生後、送信元と送信先との間に
呼が張られるまでの期間、送信端末は、ブロードキャス
トサーバーにＩＰパケットを送信する。 2. ブロードキャストサーバーは、受信したＩＰパケッ
トを、すべての端末に対してブロードキャストする。 3．送信元から送信先までの間に、呼が張られた後は、
送信端末は、ブロードキャストサーバーを使用せずに、
直接、ＩＰパケットを送信する。
【０００９】しかしながら、ブロードキャストサーバー
を使用した場合には、次のような、ブロードキャストサ
ーバーを設置した故の、新たな問題が発生する。 1．ブロードキャストサーバーの設置が必要になる。 2．端末間の呼の発呼が終了した後に、ブロードキャス
トサーバー経由の送信経路から、ブロードキャストサー
バーを経由しない送信経路に、切り替えるための手順が
必要になる。
を使用した場合には、次のような、ブロードキャストサ
ーバーを設置した故の、新たな問題が発生する。 1．ブロードキャストサーバーの設置が必要になる。 2．端末間の呼の発呼が終了した後に、ブロードキャス
トサーバー経由の送信経路から、ブロードキャストサー
バーを経由しない送信経路に、切り替えるための手順が
必要になる。
【００１０】本発明は、このような従来技術の課題を解
決しようとするものであって、ＩＰＯＡ網を実現する際
に、各サービスごとにサーバーを予測して、送信ＩＰパ
ケットの発生に関係なく、予測したサーバーへ予め発呼
しておく（以下、この発呼動作を事前発呼と称する）こ
とによって、発呼による送信待ち時間を短縮して、迅速
なＩＰ通信を実現できるようにすることを目的としてい
る。
決しようとするものであって、ＩＰＯＡ網を実現する際
に、各サービスごとにサーバーを予測して、送信ＩＰパ
ケットの発生に関係なく、予測したサーバーへ予め発呼
しておく（以下、この発呼動作を事前発呼と称する）こ
とによって、発呼による送信待ち時間を短縮して、迅速
なＩＰ通信を実現できるようにすることを目的としてい
る。
【００１１】
【課題を解決するための手段】図１は、本発明の基本原
理を示したものである。本発明方式においては、図１に
示すように、ＬＩＳに属する各端末Ａ，Ｂ，Ｃ，Ｄは、
それぞれ事前発呼手段１を有している。各端末間におい
ては、事前発呼手段１を介して、各端末間にメッシュ状
に張られたパスである、定期情報交換パス２を介して、
各端末が、サービスごとに定期的に、送受信パケット数
を通知する（以下、このような通知のための一連の動作
を、定期情報交換と称する）。
理を示したものである。本発明方式においては、図１に
示すように、ＬＩＳに属する各端末Ａ，Ｂ，Ｃ，Ｄは、
それぞれ事前発呼手段１を有している。各端末間におい
ては、事前発呼手段１を介して、各端末間にメッシュ状
に張られたパスである、定期情報交換パス２を介して、
各端末が、サービスごとに定期的に、送受信パケット数
を通知する（以下、このような通知のための一連の動作
を、定期情報交換と称する）。
【００１２】定期情報交換の動作は、次のようにして行
われる。 1．任意の端末Ａ内の事前発呼手段に対して、任意のサ
ービスａについてのサーバーを決定する条件と、そのサ
ーバーへの発呼条件等、事前発呼に必要な条件を、ＯＳ
（Operating System）やユーザ等の上位レイヤが指示す
る。 2．端末Ａの事前発呼手段は、事前発呼手段を有する他
のすべての端末Ｂ，Ｃ，Ｄとの間で、定期情報交換パス
をメッシュ状に張る。このパスは、定期情報交換を行う
だけなので、帯域は小さくてもよい。 3．端末Ａの事前発呼手段は、端末Ｂ，Ｃ，Ｄのいずれ
かかに対して、前回の定期情報交換の結果等を問い合わ
せる。これによって、新規に加入した端末Ａは、次回の
定期情報交換を待たずに、サーバー予測を行うことがで
きる。
われる。 1．任意の端末Ａ内の事前発呼手段に対して、任意のサ
ービスａについてのサーバーを決定する条件と、そのサ
ーバーへの発呼条件等、事前発呼に必要な条件を、ＯＳ
（Operating System）やユーザ等の上位レイヤが指示す
る。 2．端末Ａの事前発呼手段は、事前発呼手段を有する他
のすべての端末Ｂ，Ｃ，Ｄとの間で、定期情報交換パス
をメッシュ状に張る。このパスは、定期情報交換を行う
だけなので、帯域は小さくてもよい。 3．端末Ａの事前発呼手段は、端末Ｂ，Ｃ，Ｄのいずれ
かかに対して、前回の定期情報交換の結果等を問い合わ
せる。これによって、新規に加入した端末Ａは、次回の
定期情報交換を待たずに、サーバー予測を行うことがで
きる。
【００１３】4．3.の予測結果を、1.の指示と照合する
ことによってサーバー予測を行なって、サーバーである
と予測した端末に対して、発呼を行う。 ５．端末Ａ，Ｂ，Ｃ，Ｄの事前発呼手段は、定期情報交
換によって、それぞれが送受信したパケット数を、サー
ビスごとに定期的に報告し合う。 6．５の定期情報交換の結果を、1.の指示と照合するこ
とによってサーバー予測を行なって、サーバーであると
予測した端末に対して、発呼を行う。
ことによってサーバー予測を行なって、サーバーである
と予測した端末に対して、発呼を行う。 ５．端末Ａ，Ｂ，Ｃ，Ｄの事前発呼手段は、定期情報交
換によって、それぞれが送受信したパケット数を、サー
ビスごとに定期的に報告し合う。 6．５の定期情報交換の結果を、1.の指示と照合するこ
とによってサーバー予測を行なって、サーバーであると
予測した端末に対して、発呼を行う。
【００１４】7．端末Ａの事前発呼手段は、3.や6.のサ
ーバー予測で張られた呼を、トラフィックがない場合で
も、1.の動作によって指定された条件に合致する限り維
持する。また、事前発呼手段のコントロール部は、定期
的に事前発呼中の呼の状態を調査して、なんらかの理由
で呼が切れた場合には、再発呼する。 8．定期情報交換によるサーバー予測の結果が、前回の
サーバー予測と異なっていた場合は、事前発呼手段は、
新たにサーバーとみなした端末に対して発呼し、それま
でサーバーであると予測していた端末への呼を切断す
る。 9．端末Ａが、6.の動作でサーバーであると予測した端
末に対して、サービスａのＩＰパケットを送信する場合
には、事前発呼した呼を用いて送信する。
ーバー予測で張られた呼を、トラフィックがない場合で
も、1.の動作によって指定された条件に合致する限り維
持する。また、事前発呼手段のコントロール部は、定期
的に事前発呼中の呼の状態を調査して、なんらかの理由
で呼が切れた場合には、再発呼する。 8．定期情報交換によるサーバー予測の結果が、前回の
サーバー予測と異なっていた場合は、事前発呼手段は、
新たにサーバーとみなした端末に対して発呼し、それま
でサーバーであると予測していた端末への呼を切断す
る。 9．端末Ａが、6.の動作でサーバーであると予測した端
末に対して、サービスａのＩＰパケットを送信する場合
には、事前発呼した呼を用いて送信する。
【００１５】このような動作を行うので、本発明方式
は、ＩＰＯＡ網の通信において、次のような特長を有し
ている。 1．特定のサービスに対する、サーバーを予測すること
によって、発呼によるＩＰパケットの送信待ち時間を短
縮して、迅速なＩＰ通信を実現することができる。
は、ＩＰＯＡ網の通信において、次のような特長を有し
ている。 1．特定のサービスに対する、サーバーを予測すること
によって、発呼によるＩＰパケットの送信待ち時間を短
縮して、迅速なＩＰ通信を実現することができる。
【００１６】2．送受信したパケット数を、サービスご
とに定期的に報告し合うことによって、網のダイナミッ
クな変動に対応したサーバー予測を実現することができ
る。 3．サーバー予測の条件を、各事前発呼手段ごとに設定
可能にすることによって、各端末やネットワーク機器に
応じた、サーバー予測を実現することができる。
とに定期的に報告し合うことによって、網のダイナミッ
クな変動に対応したサーバー予測を実現することができ
る。 3．サーバー予測の条件を、各事前発呼手段ごとに設定
可能にすることによって、各端末やネットワーク機器に
応じた、サーバー予測を実現することができる。
【００１７】以下、本発明の課題を解決するための具体
的手段を記述する。
的手段を記述する。
【００１８】(1) ＬＡＮのプロトコルをＡＴＭ上に実装
する網において、ＬＡＮに属しかつＡＴＭ網に直結する
各端末に事前発呼手段１を設け、事前発呼手段１が各サ
ービスごとにサーバーを予測して、サーバーとの間で事
前発呼によって予め呼を張っておくことによって、ＬＡ
Ｎのプロトコルに基づくパケットによる発呼要求発生
時、発呼に基づくパケット送信遅延を減少させる。
する網において、ＬＡＮに属しかつＡＴＭ網に直結する
各端末に事前発呼手段１を設け、事前発呼手段１が各サ
ービスごとにサーバーを予測して、サーバーとの間で事
前発呼によって予め呼を張っておくことによって、ＬＡ
Ｎのプロトコルに基づくパケットによる発呼要求発生
時、発呼に基づくパケット送信遅延を減少させる。
【００１９】(2) (1) の場合に、事前発呼手段１が、各
サービスごとに自端末のトラフィックを監視し、定期情
報交換によって、定期的にトラフィックの監視結果を相
互に通知することによって、網の動的な変更に追随して
サーバー予測を行う。
サービスごとに自端末のトラフィックを監視し、定期情
報交換によって、定期的にトラフィックの監視結果を相
互に通知することによって、網の動的な変更に追随して
サーバー予測を行う。
【００２０】(3) (2) の場合に、定期情報交換が、端末
と事前発呼手段を有する他のすべての端末との間に、定
期情報交換パス２をメッシュ状に張ることによって行わ
れる。
と事前発呼手段を有する他のすべての端末との間に、定
期情報交換パス２をメッシュ状に張ることによって行わ
れる。
【００２１】(4) (2) の場合に、事前発呼手段１が、定
期情報交換の結果に基づいて、各サービスごとにサーバ
ーを推測することによって、サービスごとにサーバーと
なる端末が異なる網においても、サーバー予測を実現す
る。
期情報交換の結果に基づいて、各サービスごとにサーバ
ーを推測することによって、サービスごとにサーバーと
なる端末が異なる網においても、サーバー予測を実現す
る。
【００２２】(5) (4) の場合に、サーバーの推測が、上
位レイヤが事前発呼手段１に指示したサーバー予測のた
めのトラフィックの条件と、定期情報交換に基づく各端
末のトラフィックの申告結果とが合致することによって
行われる。
位レイヤが事前発呼手段１に指示したサーバー予測のた
めのトラフィックの条件と、定期情報交換に基づく各端
末のトラフィックの申告結果とが合致することによって
行われる。
【００２３】(6) (1) の場合に、事前発呼手段１が、事
前発呼した呼の状態を定期的に確認し、呼が不慮に切断
しているときは、再度事前発呼を行って、発呼状態を復
旧する。
前発呼した呼の状態を定期的に確認し、呼が不慮に切断
しているときは、再度事前発呼を行って、発呼状態を復
旧する。
【００２４】(7) (1) の場合に、新規に網に加入した端
末が有する事前発呼手段が、他の任意の端末の事前発呼
手段から定期情報交換の結果を取得することによって、
次回の定期情報交換まで待つことなく、サーバー予測を
可能にする。
末が有する事前発呼手段が、他の任意の端末の事前発呼
手段から定期情報交換の結果を取得することによって、
次回の定期情報交換まで待つことなく、サーバー予測を
可能にする。
【００２５】
【発明の実施の形態】図２は、本発明の一実施形態を示
したものであって、事前発呼手段における機能ブロック
構成を示したものである。
したものであって、事前発呼手段における機能ブロック
構成を示したものである。
【００２６】図２において、コントロール部１１には、
ユーザやＯＳ等の上位レイヤから指示された、サービス
ごとにサーバーを決定するための条件と、そのサーバー
への発呼条件とが記憶されていて、事前発呼手段を有す
る各端末からの情報をもとにサーバー予測を行うほか
に、タイマー部１８から通知された時刻に、送受信した
それぞれのＩＰパケット数をサービス別に、定期情報交
換パスを介して通知するように、サービス別パケットカ
ウンタ部１３に指示する機能を有する。また、コントロ
ール部１１は、事前発呼管理メモリ部１２を制御して、
事前発呼された呼の管理を行う機能も有している。
ユーザやＯＳ等の上位レイヤから指示された、サービス
ごとにサーバーを決定するための条件と、そのサーバー
への発呼条件とが記憶されていて、事前発呼手段を有す
る各端末からの情報をもとにサーバー予測を行うほか
に、タイマー部１８から通知された時刻に、送受信した
それぞれのＩＰパケット数をサービス別に、定期情報交
換パスを介して通知するように、サービス別パケットカ
ウンタ部１３に指示する機能を有する。また、コントロ
ール部１１は、事前発呼管理メモリ部１２を制御して、
事前発呼された呼の管理を行う機能も有している。
【００２７】事前発呼管理メモリ部１２は、事前発呼さ
れた呼に関する情報を記憶するメモリであって、コント
ロール部１１が読み出し／書き込みを行う。
れた呼に関する情報を記憶するメモリであって、コント
ロール部１１が読み出し／書き込みを行う。
【００２８】サービス別パケットカウンタ部１３は、送
受信したそれぞれのＩＰパケット数を、サービスごとに
カウントするカウンタであって、コントロール部１１か
らの指示によって、定期的に定期情報交換パスを介し
て、他の事前発呼手段に対して通知する機能を有する。
受信したそれぞれのＩＰパケット数を、サービスごとに
カウントするカウンタであって、コントロール部１１か
らの指示によって、定期的に定期情報交換パスを介し
て、他の事前発呼手段に対して通知する機能を有する。
【００２９】セル−ＩＰパケット変換部１４は、セル送
受信部１９から渡されたセルを、ＩＰパケットに組み立
てて、定期情報交換受信部１７に渡すとともに、サービ
ス別パケットカウンタ部１３や制御パケット作成部１５
から渡されたＩＰパケットをセル化して、セル送受信部
１９へ渡す機能を有する。
受信部１９から渡されたセルを、ＩＰパケットに組み立
てて、定期情報交換受信部１７に渡すとともに、サービ
ス別パケットカウンタ部１３や制御パケット作成部１５
から渡されたＩＰパケットをセル化して、セル送受信部
１９へ渡す機能を有する。
【００３０】制御パケット作成部１５は、事前発呼に関
する種々の制御用のＩＰパケットを、コントロール部１
１からの指示に応じて作成する機能を有する。
する種々の制御用のＩＰパケットを、コントロール部１
１からの指示に応じて作成する機能を有する。
【００３１】発呼／切断部１６は、コントロール部１１
から指示された端末に対してシグナリングを行ない、ま
た同様に、コントロール部１１から指示された端末への
呼を切断する機能を有する。
から指示された端末に対してシグナリングを行ない、ま
た同様に、コントロール部１１から指示された端末への
呼を切断する機能を有する。
【００３２】定期情報交換受信部１７は、受信したＩＰ
パケットの中から、定期情報交換に関するパケットを抽
出して、コントロール部１１へ通知し、また定期情報交
換用ではないＩＰパケットは、サービス別パケットカウ
ンタ部１３へ送る機能を有する。
パケットの中から、定期情報交換に関するパケットを抽
出して、コントロール部１１へ通知し、また定期情報交
換用ではないＩＰパケットは、サービス別パケットカウ
ンタ部１３へ送る機能を有する。
【００３３】タイマー部１８は、定期情報交換を実施す
るように、定期的に、コントロール部１１へ通知する機
能を有する。セル送受信部１９は、セル／デセル化およ
び物理層レベルの送受信機能を有する。
るように、定期的に、コントロール部１１へ通知する機
能を有する。セル送受信部１９は、セル／デセル化およ
び物理層レベルの送受信機能を有する。
【００３４】以下、本発明方式の具体的な動作例を説明
する。図３は、定期情報交換の動作例を示したものであ
る。
する。図３は、定期情報交換の動作例を示したものであ
る。
【００３５】〔網への新規加入時および定期情報交換時
の動作〕 1．例えば、ＲＦＣ１５７７に準じて、事前発呼手段を
有する任意の端末ＡがＬＩＳに加入する。 2．ＯＳやユーザ等の上位レイヤが、コントロール部１
１に、サーバー予測のための条件を、サービスごとに指
示する。例えば、「ＤＮＳ（Domain NameSystem）のＩ
Ｐパケットを、ｘ個以上受信し、ｙ個以上送信した端末
のうちの任意の一つを、ＤＮＳサーバーと予測する」と
いう条件を、上位レイヤがコントロール部１１に指示す
る。
の動作〕 1．例えば、ＲＦＣ１５７７に準じて、事前発呼手段を
有する任意の端末ＡがＬＩＳに加入する。 2．ＯＳやユーザ等の上位レイヤが、コントロール部１
１に、サーバー予測のための条件を、サービスごとに指
示する。例えば、「ＤＮＳ（Domain NameSystem）のＩ
Ｐパケットを、ｘ個以上受信し、ｙ個以上送信した端末
のうちの任意の一つを、ＤＮＳサーバーと予測する」と
いう条件を、上位レイヤがコントロール部１１に指示す
る。
【００３６】3．コントロール部１１は、ＡＲＰ（Adres
s Resolution Protocol）サーバーから、ＬＩＳ内の全
端末のＡＴＭアドレスを取得し、それぞれの端末に定期
情報交換パスを発呼する旨を、発呼／切断部１６に指示
する。 4．ＬＩＳ内の全端末への発呼が完了した後、コントロ
ール部１１からの指示によって、接続先のそれぞれの端
末が、事前発呼手段を有しているか否かを問い合わせる
パケットを、制御パケット作成部１５が作成して送信す
る。 5．4.の動作によって送信されたＩＰパケットを受信し
た、端末Ａを除くＬＩＳ内のすべての端末の事前発呼手
段は、端末Ａに対して、リプライパケットを返す。
s Resolution Protocol）サーバーから、ＬＩＳ内の全
端末のＡＴＭアドレスを取得し、それぞれの端末に定期
情報交換パスを発呼する旨を、発呼／切断部１６に指示
する。 4．ＬＩＳ内の全端末への発呼が完了した後、コントロ
ール部１１からの指示によって、接続先のそれぞれの端
末が、事前発呼手段を有しているか否かを問い合わせる
パケットを、制御パケット作成部１５が作成して送信す
る。 5．4.の動作によって送信されたＩＰパケットを受信し
た、端末Ａを除くＬＩＳ内のすべての端末の事前発呼手
段は、端末Ａに対して、リプライパケットを返す。
【００３７】6．端末Ａのコントロール部１１は、5.の
動作によってリプライパケットを返した端末は、事前発
呼手段を有していると判断するとともに、リプライパケ
ットを返さなかった端末への定期情報交換パスを切断す
る。 7．端末Ａのコントロール部１１は、事前発呼手段を有
する任意の端末Ｂに対して、前回の定期情報交換の結
果，次回の定期情報交換の時刻，定期情報交換の間隔
等、定期情報交換に必要な条件を問い合わせるＩＰパケ
ットを作成／送信するように、制御パケット作成部１５
に対して指示する。これによって、新規にＬＩＳに加わ
った端末Ａの事前発呼手段は、定期情報交換を待たず
に、サーバー予測を行うことができる。
動作によってリプライパケットを返した端末は、事前発
呼手段を有していると判断するとともに、リプライパケ
ットを返さなかった端末への定期情報交換パスを切断す
る。 7．端末Ａのコントロール部１１は、事前発呼手段を有
する任意の端末Ｂに対して、前回の定期情報交換の結
果，次回の定期情報交換の時刻，定期情報交換の間隔
等、定期情報交換に必要な条件を問い合わせるＩＰパケ
ットを作成／送信するように、制御パケット作成部１５
に対して指示する。これによって、新規にＬＩＳに加わ
った端末Ａの事前発呼手段は、定期情報交換を待たず
に、サーバー予測を行うことができる。
【００３８】8．端末Ｂの事前発呼手段は、端末Ａから
の、7.の動作による問い合わせに対して、問い合わせら
れた項目の結果をリプライする。 9．端末Ａのコントロール部１１は、定期情報交換受信
部１７経由で、8.の動作によるリプライパケットを受信
して、2.の動作で指定した条件に合致する端末をサーバ
ーと予測する。 10. 端末Ａのコントロール部１１は、8.の動作によるリ
プライパケットから得られた、定期情報交換の時刻に関
する情報（定期情報交換の時刻，定期情報交換の間隔
等）をタイマー部１８にセットする。
の、7.の動作による問い合わせに対して、問い合わせら
れた項目の結果をリプライする。 9．端末Ａのコントロール部１１は、定期情報交換受信
部１７経由で、8.の動作によるリプライパケットを受信
して、2.の動作で指定した条件に合致する端末をサーバ
ーと予測する。 10. 端末Ａのコントロール部１１は、8.の動作によるリ
プライパケットから得られた、定期情報交換の時刻に関
する情報（定期情報交換の時刻，定期情報交換の間隔
等）をタイマー部１８にセットする。
【００３９】11. 端末Ａのコントロール部１１は、9.の
動作結果から、発呼／切断部１６に対して発呼指示を出
して、事前発呼する。 12. 端末Ａのコントロール部１１は、事前発呼管理メモ
リ部１２の内容を更新する。 13. 端末Ａのタイマー部１８は、定期情報交換の時刻に
なったら、その旨をコントロール部１１へ通知する。
動作結果から、発呼／切断部１６に対して発呼指示を出
して、事前発呼する。 12. 端末Ａのコントロール部１１は、事前発呼管理メモ
リ部１２の内容を更新する。 13. 端末Ａのタイマー部１８は、定期情報交換の時刻に
なったら、その旨をコントロール部１１へ通知する。
【００４０】14. 端末Ａのコントロール部１１は、サー
ビス別パケットカウンタ部１３に対して、カウント結果
を送信するように指示する。この場合の動作例は、図３
に示されている。
ビス別パケットカウンタ部１３に対して、カウント結果
を送信するように指示する。この場合の動作例は、図３
に示されている。
【００４１】図３の場合、端末ＡのＤＮＳ（Domain Nam
e System）の送信パケットはａａ個であって、受信パケ
ットはａｂ個である。端末ＢのＤＮＳの送信パケットは
ｂａ個であって、受信パケットはｂｂ個である。端末Ｃ
のＤＮＳの送信パケットはｃａ個であって、受信パケッ
トはｃｂ個である。端末ＤのＤＮＳの送信パケットはｄ
ａ個であって、受信パケットはｄｂ個である。
e System）の送信パケットはａａ個であって、受信パケ
ットはａｂ個である。端末ＢのＤＮＳの送信パケットは
ｂａ個であって、受信パケットはｂｂ個である。端末Ｃ
のＤＮＳの送信パケットはｃａ個であって、受信パケッ
トはｃｂ個である。端末ＤのＤＮＳの送信パケットはｄ
ａ個であって、受信パケットはｄｂ個である。
【００４２】同様に、端末ＡのＦＴＰ（File Transfer
Protocol）の送信パケットはａｃ個であって、受信パケ
ットはａｄ個である。端末ＢのＦＴＰの送信パケットは
ｂｃ個であって、受信パケットはｂｄ個である。端末Ｃ
のＦＴＰの送信パケットはｃｃ個であって、受信パケッ
トはｃｄ個である。端末ＤのＦＴＰの送信パケットはｄ
ｃ個であって、受信パケットはｄｄ個である。
Protocol）の送信パケットはａｃ個であって、受信パケ
ットはａｄ個である。端末ＢのＦＴＰの送信パケットは
ｂｃ個であって、受信パケットはｂｄ個である。端末Ｃ
のＦＴＰの送信パケットはｃｃ個であって、受信パケッ
トはｃｄ個である。端末ＤのＦＴＰの送信パケットはｄ
ｃ個であって、受信パケットはｄｄ個である。
【００４３】15. 端末Ａの定期情報交換受信部１７は、
他の端末の事前発呼手段から受信した、定期情報交換の
ＩＰパケットを抽出して、コントロール部１１に通知す
る。
他の端末の事前発呼手段から受信した、定期情報交換の
ＩＰパケットを抽出して、コントロール部１１に通知す
る。
【００４４】16. 15. の動作における通知によって、端
末Ａのコントロール部１１は、2.の動作で指定した条件
に合致する端末を選択する。 17. 端末Ａのコントロール部１１は、16. の動作による
選択結果を、事前発呼管理メモリ部１２の内容と照合し
て、新規に発呼する相手端末と、切断する相手端末とを
抽出して、この抽出結果から、発呼／切断部１６に対し
て指示を出す。
末Ａのコントロール部１１は、2.の動作で指定した条件
に合致する端末を選択する。 17. 端末Ａのコントロール部１１は、16. の動作による
選択結果を、事前発呼管理メモリ部１２の内容と照合し
て、新規に発呼する相手端末と、切断する相手端末とを
抽出して、この抽出結果から、発呼／切断部１６に対し
て指示を出す。
【００４５】18. 端末Ａのコントロール部１１は、事前
発呼管理メモリ部１２の内容を更新する。 19. 14. 〜18. の動作を、タイマー部１８に設定された
間隔で繰り返す。 20. 端末Ａのコントロール部１１は、事前発呼中の呼の
状態を調査するパケットの作成／送信を、制御パケット
作成部１５に定期的に指示する。
発呼管理メモリ部１２の内容を更新する。 19. 14. 〜18. の動作を、タイマー部１８に設定された
間隔で繰り返す。 20. 端末Ａのコントロール部１１は、事前発呼中の呼の
状態を調査するパケットの作成／送信を、制御パケット
作成部１５に定期的に指示する。
【００４６】21. 20. の動作によるパケットを受信し
た、端末Ａ以外の端末の事前発呼手段は、リプライパケ
ットを送信する。 22. 20. と21. の動作によって、なんらかの理由で、事
前発呼した呼が切れていたことがわかった場合には、端
末Ａの事前発呼手段は、再発呼を発呼／切断部１６へ指
示する。 23. ＩＰパケット発生によって、事前発呼した端末への
通信要求があった場合には、事前発呼した呼を使用して
通信を行う。
た、端末Ａ以外の端末の事前発呼手段は、リプライパケ
ットを送信する。 22. 20. と21. の動作によって、なんらかの理由で、事
前発呼した呼が切れていたことがわかった場合には、端
末Ａの事前発呼手段は、再発呼を発呼／切断部１６へ指
示する。 23. ＩＰパケット発生によって、事前発呼した端末への
通信要求があった場合には、事前発呼した呼を使用して
通信を行う。
【００４７】〔事前発呼していない端末への通信要求が
あった場合の動作〕 1. コントロール部１１が、事前発呼がない呼への発呼
要求をセル−ＩＰパケット変換部１４から受けた場合、
コントロール部１１は、サーバー予測が外れたか、また
はサーバー予測を行わないサービスかを判定する。
あった場合の動作〕 1. コントロール部１１が、事前発呼がない呼への発呼
要求をセル−ＩＰパケット変換部１４から受けた場合、
コントロール部１１は、サーバー予測が外れたか、また
はサーバー予測を行わないサービスかを判定する。
【００４８】2. サーバー予測が外れた場合は、コント
ロール部１１は、上記した「網への新規加入および定期
情報交換時の動作」の、2.に従って動作する。例えば、
ＤＮＳサービスでは、複数のサーバーを認めない旨の指
示が、ユーザや上位レイヤからコントロール部１１に対
してあった場合には、サーバー予測が外れた時点で、コ
ントロール部１１は、予測したサーバーへの呼の切断を
指示する。 3. サーバー予測が外れた場合、サーバー予測を行わな
いサービスのいずれであっても、コントロール部１１
は、宛先アドレスからＡＴＭアドレスへのアドレス解決
を行ない、次いで、発呼指示を発呼／切断部１６へ出
す。この場合、呼が張れるまで、ＩＰパケットは送信で
きない。
ロール部１１は、上記した「網への新規加入および定期
情報交換時の動作」の、2.に従って動作する。例えば、
ＤＮＳサービスでは、複数のサーバーを認めない旨の指
示が、ユーザや上位レイヤからコントロール部１１に対
してあった場合には、サーバー予測が外れた時点で、コ
ントロール部１１は、予測したサーバーへの呼の切断を
指示する。 3. サーバー予測が外れた場合、サーバー予測を行わな
いサービスのいずれであっても、コントロール部１１
は、宛先アドレスからＡＴＭアドレスへのアドレス解決
を行ない、次いで、発呼指示を発呼／切断部１６へ出
す。この場合、呼が張れるまで、ＩＰパケットは送信で
きない。
【００４９】以上の実施形態においては、ＬＡＮの事実
上の標準プロトコルであるＩＰを、ＡＴＭ上に実装して
パケットを送信する場合について説明したが、本発明は
これに限るものでなく、ＬＡＮにおける他の種類のプロ
トコルについても適用可能である。
上の標準プロトコルであるＩＰを、ＡＴＭ上に実装して
パケットを送信する場合について説明したが、本発明は
これに限るものでなく、ＬＡＮにおける他の種類のプロ
トコルについても適用可能である。
【００５０】
【発明の効果】以上説明したように本発明によれば、Ｉ
ＰＯＡ網において、次のような効果を得ることができ
る。すなわち、ＬＩＳ内において、定期情報交換の結果
に基づいて、サービスごとにサーバー予測することによ
って、発呼による送信待ち時間を短縮することが可能と
なる。
ＰＯＡ網において、次のような効果を得ることができ
る。すなわち、ＬＩＳ内において、定期情報交換の結果
に基づいて、サービスごとにサーバー予測することによ
って、発呼による送信待ち時間を短縮することが可能と
なる。
【００５１】また、タイマー部の設定に基づいて、定期
情報交換を行うことによって、サーバーが他の端末に代
わった場合でも、サーバー予測を行うことが可能とな
る。
情報交換を行うことによって、サーバーが他の端末に代
わった場合でも、サーバー予測を行うことが可能とな
る。
【００５２】従って、本発明方式によれば、ＩＰＯＡを
実現する際に、発呼による送信待ち時間の短縮に寄与す
るところが大きい。
実現する際に、発呼による送信待ち時間の短縮に寄与す
るところが大きい。
【図１】本発明の基本原理を示す図である。
【図２】本発明の一実施形態を示す図である。
【図３】定期情報交換の動作例を示す図である。
【図４】ＲＦＣ１５７７の原理的構成を示す図である。
１ 事前発呼手段 ２ 定期情報交換パス
Claims (7)
- 【請求項１】 ＬＡＮのプロトコルをＡＴＭ上に実装す
る網において、該ＬＡＮに属しかつＡＴＭ網に直結する
各端末に事前発呼手段を設け、 該事前発呼手段が各サービスごとにサーバーを予測し
て、該サーバーとの間で事前発呼によって予め呼を張っ
ておくことによって、該ＬＡＮのプロトコルに基づくパ
ケットによる発呼要求発生時、発呼に基づく前記パケッ
ト送信遅延を減少させることを特徴とするＡＴＭ網にお
けるサーバー予測型呼管理方式。 - 【請求項２】 前記事前発呼手段が、各サービスごとに
自端末のトラフィックを監視し、定期情報交換によっ
て、定期的に該トラフィックの監視結果を相互に通知す
ることによって、網の動的な変更に追随してサーバー予
測を行うことを特徴とする請求項１に記載のＡＴＭ網に
おけるサーバー予測型呼管理方式。 - 【請求項３】 前記定期情報交換が、前記端末と事前発
呼手段を有する他のすべての端末との間に、定期情報交
換パスをメッシュ状に張ることによって行われることを
特徴とする請求項２に記載のＡＴＭ網におけるサーバー
予測型呼管理方式。 - 【請求項４】 前記事前発呼手段が、前記定期情報交換
の結果に基づいて、各サービスごとにサーバーを推測す
ることによって、サービスごとにサーバーとなる端末が
異なる網においても、サーバー予測を実現することを特
徴とする請求項２に記載のＡＴＭ網におけるサーバー予
測型呼管理方式。 - 【請求項５】 前記サーバーの推測が、上位レイヤが事
前発呼手段に指示したサーバー予測のためのトラフィッ
クの条件と、定期情報交換に基づく各端末のトラフィッ
クの申告結果とが合致することによって行われることを
特徴とする請求項４に記載のＡＴＭ網におけるサーバー
予測型呼管理方式。 - 【請求項６】 前記事前発呼手段が、事前発呼した呼の
状態を定期的に確認し、呼が不慮に切断しているとき
は、再度事前発呼を行って、発呼状態を復旧することを
特徴とする請求項１に記載のＡＴＭ網におけるサーバー
予測型呼管理方式。 - 【請求項７】 請求項１に記載のＡＴＭ網におけるサー
バー予測型呼管理方式において、新規に該網に加入した
端末が有する事前発呼手段が、他の任意の端末の事前発
呼手段から定期情報交換の結果を取得することによっ
て、次回の定期情報交換まで待つことなく、サーバー予
測を可能にしたことを特徴とするＡＴＭ網におけるサー
バー予測型呼管理方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20680896A JPH1051465A (ja) | 1996-08-06 | 1996-08-06 | Ａｔｍ網におけるサーバー予測型呼管理方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20680896A JPH1051465A (ja) | 1996-08-06 | 1996-08-06 | Ａｔｍ網におけるサーバー予測型呼管理方式 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH1051465A true JPH1051465A (ja) | 1998-02-20 |
Family
ID=16529438
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20680896A Withdrawn JPH1051465A (ja) | 1996-08-06 | 1996-08-06 | Ａｔｍ網におけるサーバー予測型呼管理方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH1051465A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1999034558A1 (fr) * | 1997-12-25 | 1999-07-08 | Kabushiki Kaisha Toshiba | Repeteur mta et reseau le comprenant |
-
1996
- 1996-08-06 JP JP20680896A patent/JPH1051465A/ja not_active Withdrawn
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1999034558A1 (fr) * | 1997-12-25 | 1999-07-08 | Kabushiki Kaisha Toshiba | Repeteur mta et reseau le comprenant |
| US6781994B1 (en) | 1997-12-25 | 2004-08-24 | Kabushiki Kaisha Toshiba | Distributing ATM cells to output ports based upon destination information using ATM switch core and IP forwarding |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5581552A (en) | Multimedia server | |
| US6047330A (en) | Virtual router discovery system | |
| EP1763204B1 (en) | System and method for redundant switches taking into account learning bridge functionality | |
| US7724671B2 (en) | Architecture for resource management in a telecommunications network | |
| US7577131B2 (en) | System and method for voice over internet protocol (VoIP) and facsimile over internet protocol (FoIP) calling over the internet | |
| US5400325A (en) | Method and apparatus providing for hunt groups in an ATM network of the like | |
| US6246669B1 (en) | Method and system for optimizing connection set-up operations in a high speed digital network | |
| US6822961B1 (en) | Method and apparatus for reduction of call setup rate in an ATM network | |
| EP1727309A1 (en) | Methods and apparatus for monitoring link integrity for signaling traffic over a path traversing hybrid ATM/ethernet infrastructure in support of packet voice service provisioning | |
| JP4376457B2 (ja) | 構内または広域ネットワークのサービスの保証された品質を与える方法および装置 | |
| CN101741740A (zh) | 一种负载平衡的方法、系统和设备 | |
| KR100842256B1 (ko) | 지.엠.피.엘.에스 기반 네트워크에서 물리계층의 레이블 스위칭 경로에 대한 연결성 검사 방법 및 그 시스템 | |
| CN102316086A (zh) | 业务数据的中继方法及中继节点系统 | |
| US6819673B1 (en) | Method and system for establishing SNA sessions over wide area networks | |
| JP2002118570A (ja) | パケット通信方法および装置 | |
| CN100454861C (zh) | 级联组网系统中的节点寻址方法 | |
| JPH1051465A (ja) | Ａｔｍ網におけるサーバー予測型呼管理方式 | |
| US6834037B2 (en) | Method and arrangement in a telecommunication system | |
| JP3597765B2 (ja) | 通信網の品質制御管理システム | |
| US6717937B1 (en) | Method and apparatus for voice over internet protocol resource management | |
| JP3597776B2 (ja) | 通信網の品質制御管理システム | |
| JP2980049B2 (ja) | Ａｔｍアドレス管理装置 | |
| JP2004312380A (ja) | 帯域管理システム | |
| JP3866242B2 (ja) | 伝送装置 | |
| JP3189755B2 (ja) | Ｌａｎエミュレーションシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20031007 |