JPH11243394A - Ｉｐ−ａｔｍハイブリッド通信装置および通信網 - Google Patents
Ｉｐ−ａｔｍハイブリッド通信装置および通信網Info
- Publication number
- JPH11243394A JPH11243394A JP4387198A JP4387198A JPH11243394A JP H11243394 A JPH11243394 A JP H11243394A JP 4387198 A JP4387198 A JP 4387198A JP 4387198 A JP4387198 A JP 4387198A JP H11243394 A JPH11243394 A JP H11243394A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- atm
- cut
- setting
- terminal
- 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.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
(57)【要約】
【課題】 トラヒックの増加によるスループットの低下
を回避するとともに、不正のユーザによるシステム侵入
の発生を回避する。 【解決手段】 ＩＰ通信中に大量のデータの転送を行な
う必要が生じた場合には、端末間のＩＰ通信によってＡ
ＴＭ論理回線を設定することを申し合わせ、申し合わせ
にしたがい端末間にＡＴＭ論理回線を設定してデータを
転送する。さらに端末は事前に設定の申し合わせを行っ
ていないＡＴＭ論理回線を端末間に設定して行う通信を
拒否する手段および端末間に設定されたＡＴＭ論理回線
上で実行可能なアプリケーションを限定する手段を備え
ることとする。
を回避するとともに、不正のユーザによるシステム侵入
の発生を回避する。 【解決手段】 ＩＰ通信中に大量のデータの転送を行な
う必要が生じた場合には、端末間のＩＰ通信によってＡ
ＴＭ論理回線を設定することを申し合わせ、申し合わせ
にしたがい端末間にＡＴＭ論理回線を設定してデータを
転送する。さらに端末は事前に設定の申し合わせを行っ
ていないＡＴＭ論理回線を端末間に設定して行う通信を
拒否する手段および端末間に設定されたＡＴＭ論理回線
上で実行可能なアプリケーションを限定する手段を備え
ることとする。
Description
【０００１】
【発明の属する技術分野】本発明は、ＡＴＭ通信とＩＰ
通信とが混在する通信に利用する。本発明は、ＩＰ通信
中にＡＴＭ通信を行う技術に関する。
通信とが混在する通信に利用する。本発明は、ＩＰ通信
中にＡＴＭ通信を行う技術に関する。
【０００２】
【従来の技術】まず、従来のＩＰ通信についてインター
ネットの例で説明する。米国ＩＳＯＣで標準化されたＩ
ｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）は多くの通
信装置間で用いられているパケット転送プロトコルであ
る。ＩＰによる通信（ＩＰ通信）では情報はＩＰパケッ
トと呼ばれるパケットに格納され、ＩＰルータと呼ばれ
る装置を連結して構成される網（ＩＰルーチング網）に
より転送される。
ネットの例で説明する。米国ＩＳＯＣで標準化されたＩ
ｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）は多くの通
信装置間で用いられているパケット転送プロトコルであ
る。ＩＰによる通信（ＩＰ通信）では情報はＩＰパケッ
トと呼ばれるパケットに格納され、ＩＰルータと呼ばれ
る装置を連結して構成される網（ＩＰルーチング網）に
より転送される。
【０００３】ＩＰパケットには宛先ＩＰアドレスと呼ば
れる宛先の通信端末を示すアドレスが記入されており、
ＩＰルータは受信したＩＰパケットの宛先ＩＰアドレス
を理解し、可能であれば宛先端末に対してＩＰパケット
を送信し、これが不可能であれば連結されたＩＰルータ
の中から適切なものを次段ルータとして選びＩＰパケッ
トを転送する（ＩＰルーチング処理）。連結されたＩＰ
ルータの数を増やすことにより広域な通信網が構成さ
れ、パケットが複数のＩＰルータを経る遠隔通信が可能
となる。
れる宛先の通信端末を示すアドレスが記入されており、
ＩＰルータは受信したＩＰパケットの宛先ＩＰアドレス
を理解し、可能であれば宛先端末に対してＩＰパケット
を送信し、これが不可能であれば連結されたＩＰルータ
の中から適切なものを次段ルータとして選びＩＰパケッ
トを転送する（ＩＰルーチング処理）。連結されたＩＰ
ルータの数を増やすことにより広域な通信網が構成さ
れ、パケットが複数のＩＰルータを経る遠隔通信が可能
となる。
【０００４】例えば電話やＦＡＸでは通信相手に対し情
報を送るのに事前に網に通信相手を通知し、回線（コネ
クション）の設定を行う。この通信形態をコネクション
オリエンテッド通信（ＣＯ通信）と呼ぶ。これに対しＩ
Ｐ通信は事前のコネクション設定を必要とせず、任意の
端末に対する情報の送出をいきなり開始することができ
る。この通信形態をコネクションレス通信（ＣＬ通信）
と呼ぶ。
報を送るのに事前に網に通信相手を通知し、回線（コネ
クション）の設定を行う。この通信形態をコネクション
オリエンテッド通信（ＣＯ通信）と呼ぶ。これに対しＩ
Ｐ通信は事前のコネクション設定を必要とせず、任意の
端末に対する情報の送出をいきなり開始することができ
る。この通信形態をコネクションレス通信（ＣＬ通信）
と呼ぶ。
【０００５】またＩＰパケットには宛先アドレスに加え
てさらにポート番号と呼ばれる識別子が記入されてい
る。図４３はＩＰインタフェースを説明するための図で
ある。図４３に示すように、ＩＰ通信機能を実装してい
るコンピュータではＩＰパケットを処理する層をアプリ
ケーションとは独立して実装し、この層でポート番号に
もとづいて到着パケットの内容を各関係アプリケーショ
ンへ転送する。これにより一つのＩＰインタフェースの
上で同時に複数のアプリケーションが複数の通信を行う
ことが可能となる。
てさらにポート番号と呼ばれる識別子が記入されてい
る。図４３はＩＰインタフェースを説明するための図で
ある。図４３に示すように、ＩＰ通信機能を実装してい
るコンピュータではＩＰパケットを処理する層をアプリ
ケーションとは独立して実装し、この層でポート番号に
もとづいて到着パケットの内容を各関係アプリケーショ
ンへ転送する。これにより一つのＩＰインタフェースの
上で同時に複数のアプリケーションが複数の通信を行う
ことが可能となる。
【０００６】今日では「インターネット」と呼ばれる世
界的規模で構築されたＩＰルーチング網があり、公のＩ
Ｐルーチング網として互いに知らないユーザの通信端末
間の通信を実現する手段として広く用いられている。イ
ンターネットは、接続ユーザ数の増加、アプリケーショ
ンの増加などといった点で近年急速に成長しており、以
下の問題を抱えている 問題１．トラヒックの増加によるスループットの低下：
ユーザ数の増加したこと、ユーザの端末が高性能化し一
通信で転送する情報量が増加したことにより網内で転送
されるパケットの量（トラヒック）が指数関数的に増大
し続けており、トラヒックの増加に対して網のパケット
転送能力の向上が追いつけないために、インターネット
上で達成可能な通信のスループットがユーザまたはアプ
リケーションが満足するレベルに達せなくなっている。
界的規模で構築されたＩＰルーチング網があり、公のＩ
Ｐルーチング網として互いに知らないユーザの通信端末
間の通信を実現する手段として広く用いられている。イ
ンターネットは、接続ユーザ数の増加、アプリケーショ
ンの増加などといった点で近年急速に成長しており、以
下の問題を抱えている 問題１．トラヒックの増加によるスループットの低下：
ユーザ数の増加したこと、ユーザの端末が高性能化し一
通信で転送する情報量が増加したことにより網内で転送
されるパケットの量（トラヒック）が指数関数的に増大
し続けており、トラヒックの増加に対して網のパケット
転送能力の向上が追いつけないために、インターネット
上で達成可能な通信のスループットがユーザまたはアプ
リケーションが満足するレベルに達せなくなっている。
【０００７】問題２．不正なユーザによるシステム侵入
の発生：さまざまなユーザ間での通信が可能となったた
め、悪意を持つユーザが他人の端末、システムに侵入
し、被害を与える事件が発生している。
の発生：さまざまなユーザ間での通信が可能となったた
め、悪意を持つユーザが他人の端末、システムに侵入
し、被害を与える事件が発生している。
【０００８】次に、従来のＡＴＭ通信について説明す
る。一方、高速データ転送網を構築することを目的とし
た情報転送技術としてＡＴＭ技術があり、ＩＴＵ−Ｔ，
ＡＴＭＦｏｒｕｍなどにより既に標準化されている。Ａ
ＴＭによる通信ではＡＴＭスイッチと呼ばれる装置を連
結して網を構成する。情報はセルと呼ばれる５３バイト
のパケットに格納されて網内を転送される。セルにはＶ
ＰＩ／ＶＣＩと呼ばれるラベルが記入されている。
る。一方、高速データ転送網を構築することを目的とし
た情報転送技術としてＡＴＭ技術があり、ＩＴＵ−Ｔ，
ＡＴＭＦｏｒｕｍなどにより既に標準化されている。Ａ
ＴＭによる通信ではＡＴＭスイッチと呼ばれる装置を連
結して網を構成する。情報はセルと呼ばれる５３バイト
のパケットに格納されて網内を転送される。セルにはＶ
ＰＩ／ＶＣＩと呼ばれるラベルが記入されている。
【０００９】ＡＴＭスイッチは物理回線を接続するため
の複数のポートを持つ。セルがスイッチへあるポートか
ら入力され、あるポートから出力されるとき、セルが入
力されるポートを入力ポートと呼び、出力されるポート
を出力ポートと呼ぶ。また入力時のセルのラベルの値を
入力ラベルと呼び、出力時のラベルの値を出力ラベルと
呼ぶことにする。ＡＴＭスイッチはセルの転送処理にお
ける入力ポート、入力ラベルと出力ポート、出力ラベル
の関係（以下「ルーチングテーブルエントリ」）を記憶
管理する手段（ルーチングテーブル）を持つ。セルが到
着するとセルの入力ポート、入力ラベルによりルーチン
グテーブルを検索して出力ポート、出力ラベルを決定
し、セルを出力ポートへ転送し、ラベルの値を出力値に
書き換えて、出力する（セル転送処理）。ＡＴＭ通信網
はＣＯ通信を前提として運用され、ルーチングテーブル
エントリはコネクションの生成と同時に生成され、コネ
クションの解放と同時に消去される。
の複数のポートを持つ。セルがスイッチへあるポートか
ら入力され、あるポートから出力されるとき、セルが入
力されるポートを入力ポートと呼び、出力されるポート
を出力ポートと呼ぶ。また入力時のセルのラベルの値を
入力ラベルと呼び、出力時のラベルの値を出力ラベルと
呼ぶことにする。ＡＴＭスイッチはセルの転送処理にお
ける入力ポート、入力ラベルと出力ポート、出力ラベル
の関係（以下「ルーチングテーブルエントリ」）を記憶
管理する手段（ルーチングテーブル）を持つ。セルが到
着するとセルの入力ポート、入力ラベルによりルーチン
グテーブルを検索して出力ポート、出力ラベルを決定
し、セルを出力ポートへ転送し、ラベルの値を出力値に
書き換えて、出力する（セル転送処理）。ＡＴＭ通信網
はＣＯ通信を前提として運用され、ルーチングテーブル
エントリはコネクションの生成と同時に生成され、コネ
クションの解放と同時に消去される。
【００１０】ＡＴＭ通信網のコネクションはＶＣ(Virtu
al Channel) と呼ばれる。またコネクションの設定、解
放を行うための網と端末との間のメッセージ手順をシグ
ナリングと呼び、コネクションの設定を要求する端末を
発呼端末、この際、通信相手として指定される端末を着
呼端末と呼ぶ。コネクションの設定手順において、発呼
端末は自身を収容しているＡＴＭスイッチに対しＳＥＴ
ＵＰと呼ばれるメッセージを送出する。
al Channel) と呼ばれる。またコネクションの設定、解
放を行うための網と端末との間のメッセージ手順をシグ
ナリングと呼び、コネクションの設定を要求する端末を
発呼端末、この際、通信相手として指定される端末を着
呼端末と呼ぶ。コネクションの設定手順において、発呼
端末は自身を収容しているＡＴＭスイッチに対しＳＥＴ
ＵＰと呼ばれるメッセージを送出する。
【００１１】すると、コネクションの経路に従いＡＴＭ
スイッチ間で制御メッセージが転送され、必要なＡＴＭ
スイッチの状態更新が行われ、着呼端末を収容するＡＴ
Ｍスイッチに制御メッセージが届くと、このＡＴＭスイ
ッチが着呼端末に対しＳＥＴＵＰメッセージを送出す
る。着呼端末はＳＥＴＵＰメッセージの内容から呼を受
け付けるか否かの判断（呼受付可否判断）を行い、呼を
受け付ける場合は応答としてＣＯＮＮＥＣＴと呼ばれる
メッセージをスイッチに送出し、呼を拒絶する場合はＲ
ＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥと呼ばれるメッセージ
をスイッチに送出する。
スイッチ間で制御メッセージが転送され、必要なＡＴＭ
スイッチの状態更新が行われ、着呼端末を収容するＡＴ
Ｍスイッチに制御メッセージが届くと、このＡＴＭスイ
ッチが着呼端末に対しＳＥＴＵＰメッセージを送出す
る。着呼端末はＳＥＴＵＰメッセージの内容から呼を受
け付けるか否かの判断（呼受付可否判断）を行い、呼を
受け付ける場合は応答としてＣＯＮＮＥＣＴと呼ばれる
メッセージをスイッチに送出し、呼を拒絶する場合はＲ
ＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥと呼ばれるメッセージ
をスイッチに送出する。
【００１２】存在しているＶＣについてのルーチング情
報のみを記憶すればよいので、ルーチングテーブルが保
持すべきエントリ数は少なくてすみ、セル転送処理もハ
ードウエアにより実装できる。これによりＡＴＭは高速
な情報転送が可能であるという長所を持つ。
報のみを記憶すればよいので、ルーチングテーブルが保
持すべきエントリ数は少なくてすみ、セル転送処理もハ
ードウエアにより実装できる。これによりＡＴＭは高速
な情報転送が可能であるという長所を持つ。
【００１３】ＡＴＭによる通信能力を持つ通信端末につ
いても、通信端末が実行するアプリケーションの多くは
ＩＰ通信を用いたものであり、ＡＴＭはその通信端末と
ＩＰルータとの間でＩＰパケットを送受信するために用
いられることが多い。これは、多くの通信アプリケーシ
ョンにとっては相互接続可能な端末の数が多いことが重
要であり、ＡＴＭはＩＰよりも遅れて実現された技術で
あるため、通信アプリケーションはＩＰ通信を用いるこ
ととした方が既に存在するＩＰ通信端末との相互接続を
確保できる分だけ有利だからである。
いても、通信端末が実行するアプリケーションの多くは
ＩＰ通信を用いたものであり、ＡＴＭはその通信端末と
ＩＰルータとの間でＩＰパケットを送受信するために用
いられることが多い。これは、多くの通信アプリケーシ
ョンにとっては相互接続可能な端末の数が多いことが重
要であり、ＡＴＭはＩＰよりも遅れて実現された技術で
あるため、通信アプリケーションはＩＰ通信を用いるこ
ととした方が既に存在するＩＰ通信端末との相互接続を
確保できる分だけ有利だからである。
【００１４】一方、ＩＰルーチング網を用いずにＡＴＭ
通信網により相手側端末と接続して情報を転送する通信
アプリケーションをＮＡＴＭ(Native ＡＴＭ) 通信アプ
リケーションと呼ぶ。ＮＡＴＭ通信アプリケーションは
ＩＰ通信を用いた通信アプリケーションと比較して相互
接続可能な端末数が著しく少なくなってしまうという欠
点を持つ。
通信網により相手側端末と接続して情報を転送する通信
アプリケーションをＮＡＴＭ(Native ＡＴＭ) 通信アプ
リケーションと呼ぶ。ＮＡＴＭ通信アプリケーションは
ＩＰ通信を用いた通信アプリケーションと比較して相互
接続可能な端末数が著しく少なくなってしまうという欠
点を持つ。
【００１５】ここで、ＩＰ通信の例として挙げたインタ
ーネットの問題点に対応する従来技術を説明する。ま
ず、前述の問題１を解決する手段として、通常はＩＰル
ーチング網を介して通信を行うが、大量の情報を転送す
る場合にはカットスルーＶＣと呼ばれるＡＴＭ−ＶＣを
ＩＰ端末間またはＩＰパケットの転送経路上のＩＰルー
タの間に設定し、カットスルーＶＣ上でＩＰパケットを
転送する方式が検討されている。
ーネットの問題点に対応する従来技術を説明する。ま
ず、前述の問題１を解決する手段として、通常はＩＰル
ーチング網を介して通信を行うが、大量の情報を転送す
る場合にはカットスルーＶＣと呼ばれるＡＴＭ−ＶＣを
ＩＰ端末間またはＩＰパケットの転送経路上のＩＰルー
タの間に設定し、カットスルーＶＣ上でＩＰパケットを
転送する方式が検討されている。
【００１６】通信端末間にカットスルーＶＣを生成した
場合にはＩＰルーチング網を経由せずに高速な情報転送
が可能となる。また転送経路上のＩＰルータ間でカット
スルーＶＣを生成した場合でも中間のＩＰルータを回避
する分だけ通信の実行速度を向上させることができる。
場合にはＩＰルーチング網を経由せずに高速な情報転送
が可能となる。また転送経路上のＩＰルータ間でカット
スルーＶＣを生成した場合でも中間のＩＰルータを回避
する分だけ通信の実行速度を向上させることができる。
【００１７】図４４はＮＨＲＰを用いたＡＴＭ−ＳＶＣ
生成を説明するための図である。図４４に示すように、
カットスルーＶＣを生成するにはカットスルーＶＣ生成
時に着呼側となる通信端末のアドレスを発呼側となる通
信端末が取得している必要がある。これを実現する手順
としてＮＨＲＰと呼ばれるプロトコルがある。この方式
では端末はＩＰルータに対しＡＴＭアドレス問い合わせ
メッセージを送出する。ＩＰルータは、問われているＡ
ＴＭアドレスを知っていれば応答メッセージを通信端末
に返し、知らなければ通常のＩＰパケットと同じ転送経
路で問い合わせメッセージをルータに転送する。
生成を説明するための図である。図４４に示すように、
カットスルーＶＣを生成するにはカットスルーＶＣ生成
時に着呼側となる通信端末のアドレスを発呼側となる通
信端末が取得している必要がある。これを実現する手順
としてＮＨＲＰと呼ばれるプロトコルがある。この方式
では端末はＩＰルータに対しＡＴＭアドレス問い合わせ
メッセージを送出する。ＩＰルータは、問われているＡ
ＴＭアドレスを知っていれば応答メッセージを通信端末
に返し、知らなければ通常のＩＰパケットと同じ転送経
路で問い合わせメッセージをルータに転送する。
【００１８】問い合わせメッセージはＡＴＭアドレスを
知っているルータにたどりつくまで転送され、ＡＴＭア
ドレスを知っているルータからは応答メッセージがさか
のぼって返されていく。このようにＮＨＲＰはルータか
らルータへと問い合わせメッセージを転送していく手順
である。この方式により以下の利点が生じる。
知っているルータにたどりつくまで転送され、ＡＴＭア
ドレスを知っているルータからは応答メッセージがさか
のぼって返されていく。このようにＮＨＲＰはルータか
らルータへと問い合わせメッセージを転送していく手順
である。この方式により以下の利点が生じる。
【００１９】１．必ずしも相手通信端末がＡＴＭ通信手
段を持たなくても相手通信端末にできる限り近いＩＰル
ータとの間にカットスルーＶＣを生成できる。
段を持たなくても相手通信端末にできる限り近いＩＰル
ータとの間にカットスルーＶＣを生成できる。
【００２０】２．セキュリティ管理上の境界となるルー
タでアドレス問い合わせメッセージをこれ以上転送しな
いように設定して、セキュリティ上外部ネットワークか
ら保護されている領域にある通信端末に対して不正なカ
ットスルーＶＣが生成されるのを防ぐことができるま
た、問題２の解決手段として、セキュリティの観点から
外部ネットワークから遮蔽すべき領域（以下「プライベ
ートドメイン」）とインターネットなどの外部のネット
ワーク（以下「パブリックドメイン」）との間でＩＰル
ーチングによる情報の転送は行わないこととし、代わり
に両ドメインの境界にＦｉｒｅＷａｌｌと呼ばれる両ド
メインに対してネットワークインターフェースを持つ装
置を設置する方式がある。図４５はＦｉｒｅＷａｌｌの
原理を説明するための図である。
タでアドレス問い合わせメッセージをこれ以上転送しな
いように設定して、セキュリティ上外部ネットワークか
ら保護されている領域にある通信端末に対して不正なカ
ットスルーＶＣが生成されるのを防ぐことができるま
た、問題２の解決手段として、セキュリティの観点から
外部ネットワークから遮蔽すべき領域（以下「プライベ
ートドメイン」）とインターネットなどの外部のネット
ワーク（以下「パブリックドメイン」）との間でＩＰル
ーチングによる情報の転送は行わないこととし、代わり
に両ドメインの境界にＦｉｒｅＷａｌｌと呼ばれる両ド
メインに対してネットワークインターフェースを持つ装
置を設置する方式がある。図４５はＦｉｒｅＷａｌｌの
原理を説明するための図である。
【００２１】ある端末からのアプリケーションメッセー
ジを受信して、そのメッセージを発した端末の代行とし
てアプリケーションメッセージをさらに他の装置へ送出
する機能をプロキシ機能と呼ぶ。図４５に示すＦｉｒｅ
Ｗａｌｌは利便性が高く、セキュリティに対する影響が
小さい一部のアプリケーションに対してプロキシ機能を
提供し、プライベートドメインの端末とパブリックドメ
インの端末とのアプリケーションを実現する。これによ
って、ユーザにとっての利便性をある程度維持しなが
ら、セキュリティを確保することができる。
ジを受信して、そのメッセージを発した端末の代行とし
てアプリケーションメッセージをさらに他の装置へ送出
する機能をプロキシ機能と呼ぶ。図４５に示すＦｉｒｅ
Ｗａｌｌは利便性が高く、セキュリティに対する影響が
小さい一部のアプリケーションに対してプロキシ機能を
提供し、プライベートドメインの端末とパブリックドメ
インの端末とのアプリケーションを実現する。これによ
って、ユーザにとっての利便性をある程度維持しなが
ら、セキュリティを確保することができる。
【００２２】
【発明が解決しようとする課題】ＮＨＲＰを用いてカッ
トスルーＶＣを生成し、前述の問題１を解決する手法は
以下の問題点を有する。
トスルーＶＣを生成し、前述の問題１を解決する手法は
以下の問題点を有する。
【００２３】問題３．現在のコンピュータの通信アプリ
ケーションの多くは情報の検索の過程において異なる複
数の端末との間で情報量の少ない通信を頻繁に繰り返
す。これらの情報量の少ない通信についてカットスルー
ＶＣを生成すると、処理能力を上回るコネクションの設
定、解放要求が網に到着し網が輻輳する、コネクション
の生成に起因する遅延によってアプリケーションの反応
速度が大きく増大してしまう。図４６は問題点（問題
３．）を説明するための図である。
ケーションの多くは情報の検索の過程において異なる複
数の端末との間で情報量の少ない通信を頻繁に繰り返
す。これらの情報量の少ない通信についてカットスルー
ＶＣを生成すると、処理能力を上回るコネクションの設
定、解放要求が網に到着し網が輻輳する、コネクション
の生成に起因する遅延によってアプリケーションの反応
速度が大きく増大してしまう。図４６は問題点（問題
３．）を説明するための図である。
【００２４】問題４．通信を行う双方の端末がＡＴＭ通
信手段を持ち、セキュリティ管理の観点からも外部装置
とカットスルーＶＣを生成することが許される場合で
も、両端末間の通常のＩＰ通信での情報転送経路上のル
ータがＮＨＲＰ機能を持たなければ、ＡＴＭアドレス取
得を達成できず、カットスルーＶＣを生成できない。図
４７はＮＨＲＰの問題点（問題４．）を説明するための
図である。
信手段を持ち、セキュリティ管理の観点からも外部装置
とカットスルーＶＣを生成することが許される場合で
も、両端末間の通常のＩＰ通信での情報転送経路上のル
ータがＮＨＲＰ機能を持たなければ、ＡＴＭアドレス取
得を達成できず、カットスルーＶＣを生成できない。図
４７はＮＨＲＰの問題点（問題４．）を説明するための
図である。
【００２５】問題５．ＮＨＲＰで相手端末のアドレスを
知るだけでは、相手端末の性能、網環境が分からないた
めにどの程度の実効通信速度を達成できるかがわから
ず、このため生成するカットスルーＶＣの帯域をどの程
度の値に設定すれば良いか端末が知る手段がない。図４
８は問題点（問題５．）を説明するための図である。
知るだけでは、相手端末の性能、網環境が分からないた
めにどの程度の実効通信速度を達成できるかがわから
ず、このため生成するカットスルーＶＣの帯域をどの程
度の値に設定すれば良いか端末が知る手段がない。図４
８は問題点（問題５．）を説明するための図である。
【００２６】また、問題１、２を同時に解決するためカ
ットスルーＶＣの生成とＦｉｒｅＷａｌｌの設置を同時
に行おうとすると、以下の問題が発生する。
ットスルーＶＣの生成とＦｉｒｅＷａｌｌの設置を同時
に行おうとすると、以下の問題が発生する。
【００２７】問題６．ＦｉｒｅＷａｌｌにおいてアプリ
ケーションプロトコルを介して通信アプリケーションを
実行している端末があり両端末ともＡＴＭ通信手段を持
っていたとしても、ＦｉｒｅＷａｌｌでアプリケーショ
ンプロトコルを終端させる必要があるために、Ｆｉｒｅ
ＷａｌｌをまたがるカットスルーＶＣは生成できない。
図４９は問題点（問題６．）を示す図である。
ケーションプロトコルを介して通信アプリケーションを
実行している端末があり両端末ともＡＴＭ通信手段を持
っていたとしても、ＦｉｒｅＷａｌｌでアプリケーショ
ンプロトコルを終端させる必要があるために、Ｆｉｒｅ
ＷａｌｌをまたがるカットスルーＶＣは生成できない。
図４９は問題点（問題６．）を示す図である。
【００２８】可能なカットスルーＶＣの設定形態は一方
の端末とＦｉｒｅＷａｌｌとの間及びもう一方の端末と
ＦｉｒｅＷａｌｌの間で別々のカットスルーＶＣを設定
する形態となる。ＦｉｒｅＷａｌｌe では一方のＶＣか
らの情報についてアプリケーションレイヤでの処理を行
ってもう一方のＶＣへ送出する。この形態ではＦｉｒｅ
Ｗａｌｌへの負荷の集中が発生し、通信の速度向上の障
害となる。図５０は問題点（負荷集中）を示す図であ
る。
の端末とＦｉｒｅＷａｌｌとの間及びもう一方の端末と
ＦｉｒｅＷａｌｌの間で別々のカットスルーＶＣを設定
する形態となる。ＦｉｒｅＷａｌｌe では一方のＶＣか
らの情報についてアプリケーションレイヤでの処理を行
ってもう一方のＶＣへ送出する。この形態ではＦｉｒｅ
Ｗａｌｌへの負荷の集中が発生し、通信の速度向上の障
害となる。図５０は問題点（負荷集中）を示す図であ
る。
【００２９】また端末がＩＰ通信を用いないこととし
て、ＮＡＴＭ通信アプリケーションにより通信を行えば
上記の問題は発生しないが、前述の通りＩＰ通信を用い
ないこととすると相互接続可能な通信端末数が著しく少
なくなってしまう。
て、ＮＡＴＭ通信アプリケーションにより通信を行えば
上記の問題は発生しないが、前述の通りＩＰ通信を用い
ないこととすると相互接続可能な通信端末数が著しく少
なくなってしまう。
【００３０】本発明は、このような背景に行われたもの
であって、問題３、４、５、６が発生することなく問題
１、２を解決し、既存のＡＴＭ通信手段を持たない従来
のＩＰ端末との相互接続性を確保しながら、ＡＴＭによ
る高速な情報転送を利用した通信方式を提供することを
目的とする。
であって、問題３、４、５、６が発生することなく問題
１、２を解決し、既存のＡＴＭ通信手段を持たない従来
のＩＰ端末との相互接続性を確保しながら、ＡＴＭによ
る高速な情報転送を利用した通信方式を提供することを
目的とする。
【００３１】すなわち、本発明は、トラヒックの増加に
よるスループットの低下を回避することができるＩＰ−
ＡＴＭハイブリッド通信装置および通信網を提供するこ
とを目的とする。本発明は、不正なユーザによるシステ
ム侵入の発生を回避することができるＩＰ−ＡＴＭハイ
ブリッド通信装置および通信網を提供することを目的と
する。
よるスループットの低下を回避することができるＩＰ−
ＡＴＭハイブリッド通信装置および通信網を提供するこ
とを目的とする。本発明は、不正なユーザによるシステ
ム侵入の発生を回避することができるＩＰ−ＡＴＭハイ
ブリッド通信装置および通信網を提供することを目的と
する。
【００３２】
【課題を解決するための手段】（手段１）まず、本発明
による通信では、通信を行う通信端末どうしが、通信端
末間でＩＰ通信を用いたアプリケーションを実行し、そ
の通信アプリケーションにおいて双方がＡＴＭ−ＳＶＣ
通信能力を有するか否かを確認するステップ（「カット
スルー能力確認ステップ」）を実行し、いずれかまたは
双方の通信端末がＡＴＭ−ＳＶＣ通信能力を有しない場
合にはＡＴＭ−ＳＶＣ通信を用いずに通信アプリケーシ
ョンを継続して実行し、双方がＡＴＭ−ＳＶＣ通信能力
を有することが確認された場合にはカットスルーＶＣを
生成することが望ましい時（例えば大量の情報を転送す
る時など）に以下の手順によりカットスルーＶＣを生成
してカットスルーＶＣを用いた情報転送を実行すること
を特徴とする： （手順１：ＶＣ生成申し合わせステップ）カットスルー
ＶＣを生成することをＩＰ通信により申し合わせる。
による通信では、通信を行う通信端末どうしが、通信端
末間でＩＰ通信を用いたアプリケーションを実行し、そ
の通信アプリケーションにおいて双方がＡＴＭ−ＳＶＣ
通信能力を有するか否かを確認するステップ（「カット
スルー能力確認ステップ」）を実行し、いずれかまたは
双方の通信端末がＡＴＭ−ＳＶＣ通信能力を有しない場
合にはＡＴＭ−ＳＶＣ通信を用いずに通信アプリケーシ
ョンを継続して実行し、双方がＡＴＭ−ＳＶＣ通信能力
を有することが確認された場合にはカットスルーＶＣを
生成することが望ましい時（例えば大量の情報を転送す
る時など）に以下の手順によりカットスルーＶＣを生成
してカットスルーＶＣを用いた情報転送を実行すること
を特徴とする： （手順１：ＶＣ生成申し合わせステップ）カットスルー
ＶＣを生成することをＩＰ通信により申し合わせる。
【００３３】（手順2 ：ＶＣ−ＴＡＧ決定ステップ）ど
ちらかの通信端末（以下「マスター側」とする）が申し
合わせたＶＣに対するＶＣ−ＴＡＧを決定する。
ちらかの通信端末（以下「マスター側」とする）が申し
合わせたＶＣに対するＶＣ−ＴＡＧを決定する。
【００３４】（手順3 ：ＶＣ−ＴＡＧ通知ステップ）マ
スター側通信端末が相手通信端末（以下「スレーブ側」
とする）に対し決定されたＶＣ−ＴＡＧをＩＰ通信によ
り通知する。
スター側通信端末が相手通信端末（以下「スレーブ側」
とする）に対し決定されたＶＣ−ＴＡＧをＩＰ通信によ
り通知する。
【００３５】（手順4 ：カットスルーＶＣ発呼ステッ
プ）スレーブ側通信端末が通知されたＶＣ−ＴＡＧをＳ
ＥＴＵＰメッセージ中に記入しながら発呼要求をＡＴＭ
通信網に対して行う。
プ）スレーブ側通信端末が通知されたＶＣ−ＴＡＧをＳ
ＥＴＵＰメッセージ中に記入しながら発呼要求をＡＴＭ
通信網に対して行う。
【００３６】（手順５：ＶＣ−ＴＡＧ照合ステップ）マ
スター側通信端末にＡＴＭ通信網からＳＥＴＵＰメッセ
ージが到着した際にマスター側通信端末がＳＥＴＵＰメ
ッセージ中のＶＣ−ＴＡＧと前記ＶＣ−ＴＡＧ通知ステ
ップにおいて通知したＶＣ−ＴＡＧを照合して（以下、
「ＶＣ−ＴＡＧ照合ステップ」）、ＶＣ−ＴＡＧが一致
しなければ呼受付を拒絶し、ＶＣ−ＴＡＧが一致すれば
呼を受け付けカットスルーＶＣを生成する。
スター側通信端末にＡＴＭ通信網からＳＥＴＵＰメッセ
ージが到着した際にマスター側通信端末がＳＥＴＵＰメ
ッセージ中のＶＣ−ＴＡＧと前記ＶＣ−ＴＡＧ通知ステ
ップにおいて通知したＶＣ−ＴＡＧを照合して（以下、
「ＶＣ−ＴＡＧ照合ステップ」）、ＶＣ−ＴＡＧが一致
しなければ呼受付を拒絶し、ＶＣ−ＴＡＧが一致すれば
呼を受け付けカットスルーＶＣを生成する。
【００３７】前記手段1を実現する本発明による通信端
末の一形態の特徴として、ＩＰルーチング網を利用した
通信（以下「ＩＰ通信」とする）を行う手段と、ＡＴＭ
シグナリング手順で端末間に生成したＡＴＭ−ＶＣ（以
下「カットスルーＶＣ」）上で通信（以下「ＡＴＭ−Ｓ
ＶＣ通信」とする）を行う手段（以下「ＡＴＭ−ＳＶＣ
通信手段」）とを備え、さらにＡＴＭ−ＳＶＣ通信手段
を持っているか否かを相手通信端末に対し確認するステ
ップ（「カットスルー能力確認ステップ」）を含むＩＰ
通信を用いたアプリケーションを実行する手段と、カッ
トスルーＶＣを端末間に生成することをＩＰ通信により
申し合わせる手段（「ＶＣ生成申し合わせ手段」）と、
生成を申し合わせたカットスルーＶＣに対して両端末で
共通に認識可能な識別子（以下「ＶＣ−ＴＡＧ」）を割
り当てる手段（以下「ＶＣ−ＴＡＧ割り当て手段」）
と、現在保持しているＶＣ（以下「保持中ＶＣ」）と生
成することが申し合わされたＶＣ（以下「生成予定Ｖ
Ｃ」）に対するＶＣ−ＴＡＧを記憶、管理する手段（以
下「ＶＣ−ＴＡＧ管理テーブル））とを備え、さらに前
記ＡＴＭ−ＳＶＣ通信手段は発呼時にＳＥＴＵＰメッセ
ージ中にＶＣ−ＴＡＧを記入する機能と着呼時にＳＥＴ
ＵＰメッセージ中のＶＣ−ＴＡＧを前記「ＶＣ−ＴＡＧ
管理テーブル」と照合し、ＳＥＴＵＰメッセージと一致
したＶＣ−ＴＡＧの生成予定ＶＣがなければ呼受け付け
を拒否する機能（以下「非生成予定呼拒絶機能」）を持
つことが挙げられる。
末の一形態の特徴として、ＩＰルーチング網を利用した
通信（以下「ＩＰ通信」とする）を行う手段と、ＡＴＭ
シグナリング手順で端末間に生成したＡＴＭ−ＶＣ（以
下「カットスルーＶＣ」）上で通信（以下「ＡＴＭ−Ｓ
ＶＣ通信」とする）を行う手段（以下「ＡＴＭ−ＳＶＣ
通信手段」）とを備え、さらにＡＴＭ−ＳＶＣ通信手段
を持っているか否かを相手通信端末に対し確認するステ
ップ（「カットスルー能力確認ステップ」）を含むＩＰ
通信を用いたアプリケーションを実行する手段と、カッ
トスルーＶＣを端末間に生成することをＩＰ通信により
申し合わせる手段（「ＶＣ生成申し合わせ手段」）と、
生成を申し合わせたカットスルーＶＣに対して両端末で
共通に認識可能な識別子（以下「ＶＣ−ＴＡＧ」）を割
り当てる手段（以下「ＶＣ−ＴＡＧ割り当て手段」）
と、現在保持しているＶＣ（以下「保持中ＶＣ」）と生
成することが申し合わされたＶＣ（以下「生成予定Ｖ
Ｃ」）に対するＶＣ−ＴＡＧを記憶、管理する手段（以
下「ＶＣ−ＴＡＧ管理テーブル））とを備え、さらに前
記ＡＴＭ−ＳＶＣ通信手段は発呼時にＳＥＴＵＰメッセ
ージ中にＶＣ−ＴＡＧを記入する機能と着呼時にＳＥＴ
ＵＰメッセージ中のＶＣ−ＴＡＧを前記「ＶＣ−ＴＡＧ
管理テーブル」と照合し、ＳＥＴＵＰメッセージと一致
したＶＣ−ＴＡＧの生成予定ＶＣがなければ呼受け付け
を拒否する機能（以下「非生成予定呼拒絶機能」）を持
つことが挙げられる。
【００３８】従来の技術と異なる点は以下の通りであ
る。
る。
【００３９】１．ＮＨＲＰを用いてカットスルーＶＣを
生成する方式と比較すると、本発明による通信方式では
カットスルーＶＣを生成する装置間で直接、カットスル
ーＶＣを生成することを事前に申し合わせているが、Ｎ
ＨＲＰを用いてカットスルーＶＣを生成する方式ではカ
ットスルーＶＣを生成することを装置間で事前に申し合
わせることはしない点が異なる。
生成する方式と比較すると、本発明による通信方式では
カットスルーＶＣを生成する装置間で直接、カットスル
ーＶＣを生成することを事前に申し合わせているが、Ｎ
ＨＲＰを用いてカットスルーＶＣを生成する方式ではカ
ットスルーＶＣを生成することを装置間で事前に申し合
わせることはしない点が異なる。
【００４０】２．ＮＡＴＭ通信アプリケーションと比較
すると、本発明による通信方式ではＩＰ通信を用いた通
信アプリケーションにおいて互いのＡＴＭ通信能力を確
認し、双方またはいずれかがＡＴＭ通信能力を有しない
場合にはＩＰ通信のみを用いて通信アプリケーションを
継続して実行するが、ＮＡＴＭ通信アプリケーションで
はＡＴＭ通信網により相手側装置に接続するため、相手
側装置がＡＴＭ通信能力を持っていることが前提となる
点が異なる。
すると、本発明による通信方式ではＩＰ通信を用いた通
信アプリケーションにおいて互いのＡＴＭ通信能力を確
認し、双方またはいずれかがＡＴＭ通信能力を有しない
場合にはＩＰ通信のみを用いて通信アプリケーションを
継続して実行するが、ＮＡＴＭ通信アプリケーションで
はＡＴＭ通信網により相手側装置に接続するため、相手
側装置がＡＴＭ通信能力を持っていることが前提となる
点が異なる。
【００４１】（手段２）さらに本発明による通信は前記
カットスルーＶＣ発呼ステップより以前にマスター側端
末が自端末のＡＴＭアドレスをスレーブ側端末にＩＰ通
信により通知することを特徴とする。従来のＮＨＲＰを
用いてカットスルーＶＣを生成する方式と比較すると本
発明による通信方式ではカットスルーＶＣを生成する端
末間の直接のＩＰ通信によりＡＴＭアドレスが通知され
る点が異なる。
カットスルーＶＣ発呼ステップより以前にマスター側端
末が自端末のＡＴＭアドレスをスレーブ側端末にＩＰ通
信により通知することを特徴とする。従来のＮＨＲＰを
用いてカットスルーＶＣを生成する方式と比較すると本
発明による通信方式ではカットスルーＶＣを生成する端
末間の直接のＩＰ通信によりＡＴＭアドレスが通知され
る点が異なる。
【００４２】（手段３）さらに本発明による通信は、マ
スター側通信端末が自通信端末の処理能力、網環境を考
慮して達成可能な実効通信速度を予測して、前記カット
スルーＶＣ生成ステップの実行以前にＩＰ通信によりこ
の値をスレーブ側通信端末に通知することを特徴とす
る。従来のＮＨＲＰを用いてカットスルーＶＣを生成す
る方式ではこのようにカットスルーＶＣを発呼する通信
端末が相手側通信端末が達成可能な実効通信速度を取得
することはできない。またＮＡＴＭ通信アプリケーショ
ンでも相手側通信端末と接続する以前に発呼側通信端末
が相手側通信端末が達成可能な実効通信速度を取得する
ことはできない。
スター側通信端末が自通信端末の処理能力、網環境を考
慮して達成可能な実効通信速度を予測して、前記カット
スルーＶＣ生成ステップの実行以前にＩＰ通信によりこ
の値をスレーブ側通信端末に通知することを特徴とす
る。従来のＮＨＲＰを用いてカットスルーＶＣを生成す
る方式ではこのようにカットスルーＶＣを発呼する通信
端末が相手側通信端末が達成可能な実効通信速度を取得
することはできない。またＮＡＴＭ通信アプリケーショ
ンでも相手側通信端末と接続する以前に発呼側通信端末
が相手側通信端末が達成可能な実効通信速度を取得する
ことはできない。
【００４３】（手段４）さらに本発明による通信は、通
信端末の片方が情報を提供するような「サーバ」であ
り、もう一方が情報を取得するような「クライアント」
である場合に、クライアントをスレーブ側とし、サーバ
をマスター側とすることを特徴とする。
信端末の片方が情報を提供するような「サーバ」であ
り、もう一方が情報を取得するような「クライアント」
である場合に、クライアントをスレーブ側とし、サーバ
をマスター側とすることを特徴とする。
【００４４】（手段５）さらに本発明による通信端末は
カットスルーＶＣ上で実行されるアプリケーションをあ
る特定のアプリケーション（以下「指定アプリケーショ
ン」）に限定する手段を持つ事を特徴とし、本発明によ
る通信は前記カットスルーＶＣ発呼ステップより以前に
指定アプリケーションを決定することを特徴とする。
カットスルーＶＣ上で実行されるアプリケーションをあ
る特定のアプリケーション（以下「指定アプリケーショ
ン」）に限定する手段を持つ事を特徴とし、本発明によ
る通信は前記カットスルーＶＣ発呼ステップより以前に
指定アプリケーションを決定することを特徴とする。
【００４５】一方、従来のＮＨＲＰを用いてカットスル
ーＶＣを生成する方式では、カットスルーＶＣの生成を
事前に申し合わせないために指定アプリケーションを申
し合わせることもできず、いったんカットスルーＶＣが
設定されると、そのカットスルーＶＣ上で実行されるア
プリケーションを制限することはできない。
ーＶＣを生成する方式では、カットスルーＶＣの生成を
事前に申し合わせないために指定アプリケーションを申
し合わせることもできず、いったんカットスルーＶＣが
設定されると、そのカットスルーＶＣ上で実行されるア
プリケーションを制限することはできない。
【００４６】（手段６）手段５のためカットスルーＶＣ
上で指定アプリケーション以外のアプリケーションの実
行を防止する一方式として、本発明による通信の一形態
ではカットスルーＶＣを生成する際、スレーブ側通信端
末からマスター側通信端末への方向の帯域を“０”とす
ることを特徴とする。
上で指定アプリケーション以外のアプリケーションの実
行を防止する一方式として、本発明による通信の一形態
ではカットスルーＶＣを生成する際、スレーブ側通信端
末からマスター側通信端末への方向の帯域を“０”とす
ることを特徴とする。
【００４７】（手段７）手段５のためカットスルーＶＣ
上で指定アプリケーション以外のアプリケーションの実
行を防止する別の方式として、本発明による通信端末の
一形態ではカットスルーＶＣ上で転送されるデータをＩ
Ｐレイヤ処理を通さずに直接指定アプリケーションへ転
送することを特徴とする。
上で指定アプリケーション以外のアプリケーションの実
行を防止する別の方式として、本発明による通信端末の
一形態ではカットスルーＶＣ上で転送されるデータをＩ
Ｐレイヤ処理を通さずに直接指定アプリケーションへ転
送することを特徴とする。
【００４８】（手段８）さらに、本発明においてマスタ
ー側の通信端末は不正な利用者によりカットスルーＶＣ
の生成が試みられたことを検出したらその旨をＡＴＭ通
信網に通知する手段を持つことを特徴とする。
ー側の通信端末は不正な利用者によりカットスルーＶＣ
の生成が試みられたことを検出したらその旨をＡＴＭ通
信網に通知する手段を持つことを特徴とする。
【００４９】（手段９）さらに本発明による通信端末は
カットスルーＶＣのうち通信が終了して一定時間経過し
たＶＣを切断する手段を持つ事を特徴とする。
カットスルーＶＣのうち通信が終了して一定時間経過し
たＶＣを切断する手段を持つ事を特徴とする。
【００５０】（手段１０）さらに本発明による通信端末
は生成予定ＶＣについて、生成することを申し合わせた
時間から一定時間経過しても着呼しないものがある場合
に、ＶＣ−ＴＡＧ管理テーブル中のその生成予定ＶＣに
ついての内容を消去する手段を持つこととを特徴とす
る。
は生成予定ＶＣについて、生成することを申し合わせた
時間から一定時間経過しても着呼しないものがある場合
に、ＶＣ−ＴＡＧ管理テーブル中のその生成予定ＶＣに
ついての内容を消去する手段を持つこととを特徴とす
る。
【００５１】（手段１１）さらに本発明による通信は、
第３者が値を推測したり網羅的に候補値を繰り返し生成
することが困難なバイト列（以下「パスワード」）を用
い、以下のステップを手段１の通信手順に加えることを
特徴とする。
第３者が値を推測したり網羅的に候補値を繰り返し生成
することが困難なバイト列（以下「パスワード」）を用
い、以下のステップを手段１の通信手順に加えることを
特徴とする。
【００５２】１．パスワードの通知ステップ：マスター
側通信端末は各生成予定ＶＣに対してパスワードを生成
することとし、前記カットスルーＶＣ生成ステップの実
行より以前にスレーブ側通信端末に対してパスワードを
ＩＰ通信により通知する。
側通信端末は各生成予定ＶＣに対してパスワードを生成
することとし、前記カットスルーＶＣ生成ステップの実
行より以前にスレーブ側通信端末に対してパスワードを
ＩＰ通信により通知する。
【００５３】２．パスワードの復唱ステップ：前記カッ
トスルーＶＣ生成ステップまたはカットスルーＶＣ生成
直後において、スレーブ側通信端末は通知されたパスワ
ードをマスター側通信端末に対して復唱する。
トスルーＶＣ生成ステップまたはカットスルーＶＣ生成
直後において、スレーブ側通信端末は通知されたパスワ
ードをマスター側通信端末に対して復唱する。
【００５４】３．パスワードの照合ステップ：前記パス
ワードの復唱ステップ以降において、マスター側通信端
末は前記パスワードの通知ステップにおいて通知したパ
スワードと前記パスワードの復唱ステップにおいて復唱
されたパスワードとを照合し、パスワードが一致しなけ
ればカットスルーＶＣの着呼拒絶または切断を行う。
ワードの復唱ステップ以降において、マスター側通信端
末は前記パスワードの通知ステップにおいて通知したパ
スワードと前記パスワードの復唱ステップにおいて復唱
されたパスワードとを照合し、パスワードが一致しなけ
ればカットスルーＶＣの着呼拒絶または切断を行う。
【００５５】手段１１を実現する本発明による通信端末
の一形態の構成上の特徴として、マスター側通信端末が
各生成予定ＶＣについてパスワードを生成する手段を持
つこと、前記ＶＣ−ＴＡＧ管理テーブルは生成予定ＶＣ
に対するパスワードを記憶する機能を持つことが挙げら
れる。
の一形態の構成上の特徴として、マスター側通信端末が
各生成予定ＶＣについてパスワードを生成する手段を持
つこと、前記ＶＣ−ＴＡＧ管理テーブルは生成予定ＶＣ
に対するパスワードを記憶する機能を持つことが挙げら
れる。
【００５６】（手段１２）さらに本発明による通信の一
形態では、各スレーブ側通信端末に固有の暗号鍵が公開
されているとし、マスター側通信端末がこれを取得して
いることを前提とし、前記パスワードの通知ステップに
おいて、マスター側通信端末がパスワードを暗号化し、
パスワードをそのまま通知する代わりに暗号化されたパ
スワードを通知することを特徴とする。
形態では、各スレーブ側通信端末に固有の暗号鍵が公開
されているとし、マスター側通信端末がこれを取得して
いることを前提とし、前記パスワードの通知ステップに
おいて、マスター側通信端末がパスワードを暗号化し、
パスワードをそのまま通知する代わりに暗号化されたパ
スワードを通知することを特徴とする。
【００５７】（手段１３）さらに本発明による通信のう
ち、手段１２に述べたものとは別の形態では、各スレー
ブ側通信端末に固有の復号鍵が公開されているとし、マ
スター側通信端末がこれを取得していることを前提と
し、前記パスワードの復唱ステップにおいて、スレーブ
側通信端末がパスワードを暗号化し、パスワードをその
まま記入する代わりに暗号化されたパスワードをＳＥＴ
ＵＰメッセージに記入することとし、マスター側通信端
末がＳＥＴＵＰ中の暗号化されたパスワードを復号し
て、パスワードを照合することを特徴とする。
ち、手段１２に述べたものとは別の形態では、各スレー
ブ側通信端末に固有の復号鍵が公開されているとし、マ
スター側通信端末がこれを取得していることを前提と
し、前記パスワードの復唱ステップにおいて、スレーブ
側通信端末がパスワードを暗号化し、パスワードをその
まま記入する代わりに暗号化されたパスワードをＳＥＴ
ＵＰメッセージに記入することとし、マスター側通信端
末がＳＥＴＵＰ中の暗号化されたパスワードを復号し
て、パスワードを照合することを特徴とする。
【００５８】本発明による通信端末の構成上の特徴のう
ち手段１２または手段１３の実現に必要なものとして、
通信端末が公開鍵暗号方式によりデータを暗号化および
復号する手段をもつことが挙げられる。
ち手段１２または手段１３の実現に必要なものとして、
通信端末が公開鍵暗号方式によりデータを暗号化および
復号する手段をもつことが挙げられる。
【００５９】次に、本発明の作用を説明する。手段１に
よりあらかじめＩＰ通信上のアプリケーションで生成を
申し合わせたカットスルーＶＣのみを生成することが可
能となる。これにより以下の効果が発生する。
よりあらかじめＩＰ通信上のアプリケーションで生成を
申し合わせたカットスルーＶＣのみを生成することが可
能となる。これにより以下の効果が発生する。
【００６０】問題２の解決：カットスルーＶＣの申し合
わせを行うアプリケーションにおいて、例えば利用者の
認証など、カットスルーＶＣ上の不正な通信を予防する
さまざまな手段を講じることが可能となる。つまり先に
問題２として指摘した不正なユーザによるシステム侵入
の発生を回避できる。
わせを行うアプリケーションにおいて、例えば利用者の
認証など、カットスルーＶＣ上の不正な通信を予防する
さまざまな手段を講じることが可能となる。つまり先に
問題２として指摘した不正なユーザによるシステム侵入
の発生を回避できる。
【００６１】問題３の解決：カットスルーＶＣの申し合
わせを行うアプリケーションにおいて転送すべき情報の
量を判断し、大量の情報を転送する時のみに限定してカ
ットスルーＶＣの生成を行うことが可能となる。つまり
先に問題３として指摘した情報量の少ない通信について
カットスルーＶＣを生成することに起因する網の輻輳の
発生、アプリケーションの反応速度の増大を回避でき
る。
わせを行うアプリケーションにおいて転送すべき情報の
量を判断し、大量の情報を転送する時のみに限定してカ
ットスルーＶＣの生成を行うことが可能となる。つまり
先に問題３として指摘した情報量の少ない通信について
カットスルーＶＣを生成することに起因する網の輻輳の
発生、アプリケーションの反応速度の増大を回避でき
る。
【００６２】また、上記の通りカットスルーＶＣ上で問
題２が発生することを防止できれば、通常のＩＰ通信を
ＦｉｒｅＷａｌｌを経由して行っている装置間について
も、装置間を直結するカットスルーＶＣを生成すること
が可能となり、問題６が解決される。
題２が発生することを防止できれば、通常のＩＰ通信を
ＦｉｒｅＷａｌｌを経由して行っている装置間について
も、装置間を直結するカットスルーＶＣを生成すること
が可能となり、問題６が解決される。
【００６３】以上のとおり、手段１により問題２、３、
６を発生させずにＡＴＭによる高速データ転送を利用し
た通信を行うことが可能となり、問題１が解決される。
また手段１のとおり、通信端末間でＡＴＭ−ＳＶＣ通信
能力の確認を行い、いずれかまたは双方の通信端末がＡ
ＴＭ−ＳＶＣ通信能力を持たない場合にはＩＰ通信のみ
を用いてアプリケーションを継続することにより、ＡＴ
Ｍ−ＳＶＣ通信能力を持たない通信端末とは従来の品質
での通信を行うこととして、相互接続性を確保してい
る。つまり本発明による通信方式では相互接続可能な通
信端末数が少なくなるというＮＡＴＭ通信アプリケーシ
ョンの問題点は発生しない。
６を発生させずにＡＴＭによる高速データ転送を利用し
た通信を行うことが可能となり、問題１が解決される。
また手段１のとおり、通信端末間でＡＴＭ−ＳＶＣ通信
能力の確認を行い、いずれかまたは双方の通信端末がＡ
ＴＭ−ＳＶＣ通信能力を持たない場合にはＩＰ通信のみ
を用いてアプリケーションを継続することにより、ＡＴ
Ｍ−ＳＶＣ通信能力を持たない通信端末とは従来の品質
での通信を行うこととして、相互接続性を確保してい
る。つまり本発明による通信方式では相互接続可能な通
信端末数が少なくなるというＮＡＴＭ通信アプリケーシ
ョンの問題点は発生しない。
【００６４】さらに手段２により発呼側通信端末が着呼
側通信端末から直接、着呼側通信端末のＡＴＭアドレス
を取得することとし問題４を解決する。
側通信端末から直接、着呼側通信端末のＡＴＭアドレス
を取得することとし問題４を解決する。
【００６５】さらに手段３によりスレーブ側通信端末が
通知された通信速度と自身の処理能力、網環境を考慮し
て、達成可能な実効通信速度を予測し、カットスルーＶ
Ｃに対する帯域を決定することが可能となり問題５を解
決する。
通知された通信速度と自身の処理能力、網環境を考慮し
て、達成可能な実効通信速度を予測し、カットスルーＶ
Ｃに対する帯域を決定することが可能となり問題５を解
決する。
【００６６】しかし手段１、２、３によって以下に挙げ
る問題点が新たに発生する。
る問題点が新たに発生する。
【００６７】問題７．悪意を持ったユーザが他人の第３
者のＡＴＭアドレスを通知するようなマスター側装置を
設営しいたずらを行うことが可能となってしまう。
者のＡＴＭアドレスを通知するようなマスター側装置を
設営しいたずらを行うことが可能となってしまう。
【００６８】問題８．前述のとおり、カットスルーＶＣ
の生成を申し合わせるアプリケーションにおいて利用者
の認証などを行えばカットスルーＶＣ上で不正な通信が
発生するのを予防できるが、通信端末の一方がサーバで
あり、すべての人に対して情報の利用を許すようなサー
バである場合、利用者の認証により不正な通信を効果的
に予防することが難しい。この場合、悪意を持ったユー
ザがスレーブ側通信端末を用いて、システムに被害を与
える可能性が少ないアプリケーションでマスター側通信
端末にアクセスし、マスター側通信端末とカットスルー
ＶＣの生成を申し合わせ、カットスルーＶＣを生成した
のち、カットスルーＶＣの生成申し合わせ時に想定され
ていないアプリケーションを実行し、システムに被害を
与える可能性がある。
の生成を申し合わせるアプリケーションにおいて利用者
の認証などを行えばカットスルーＶＣ上で不正な通信が
発生するのを予防できるが、通信端末の一方がサーバで
あり、すべての人に対して情報の利用を許すようなサー
バである場合、利用者の認証により不正な通信を効果的
に予防することが難しい。この場合、悪意を持ったユー
ザがスレーブ側通信端末を用いて、システムに被害を与
える可能性が少ないアプリケーションでマスター側通信
端末にアクセスし、マスター側通信端末とカットスルー
ＶＣの生成を申し合わせ、カットスルーＶＣを生成した
のち、カットスルーＶＣの生成申し合わせ時に想定され
ていないアプリケーションを実行し、システムに被害を
与える可能性がある。
【００６９】問題９．悪意を持ったユーザが網羅的にＶ
Ｃ−ＴＡＧの候補値を生成しながらある通信端末とのカ
ットスルーＶＣの生成を繰り返し試みる可能性がある。
これにより、あるスレーブ側通信端末とあるマスター側
通信端末でカットスルーＶＣの生成申し合わせステップ
が実行されたが、スレーブ側通信端末による前記カット
スルーＶＣ生成ステップ実行より以前に悪意を持ったユ
ーザによる同じＶＣ−ＴＡＧを用いた発呼が発生し、生
成を申し合わせていない通信端末どうしのカットスルー
ＶＣが生成されてしまう危険性がある。
Ｃ−ＴＡＧの候補値を生成しながらある通信端末とのカ
ットスルーＶＣの生成を繰り返し試みる可能性がある。
これにより、あるスレーブ側通信端末とあるマスター側
通信端末でカットスルーＶＣの生成申し合わせステップ
が実行されたが、スレーブ側通信端末による前記カット
スルーＶＣ生成ステップ実行より以前に悪意を持ったユ
ーザによる同じＶＣ−ＴＡＧを用いた発呼が発生し、生
成を申し合わせていない通信端末どうしのカットスルー
ＶＣが生成されてしまう危険性がある。
【００７０】問題１０．不正ユーザがスレーブ側通信端
末を用いて、拒絶されながらもカットスルーＶＣの生成
を繰り返し試みれば、マスター側通信端末、およびＡＴ
Ｍ通信網の呼処理システムの負荷が高くなる。
末を用いて、拒絶されながらもカットスルーＶＣの生成
を繰り返し試みれば、マスター側通信端末、およびＡＴ
Ｍ通信網の呼処理システムの負荷が高くなる。
【００７１】問題１１．カットスルーＶＣ上で通信が終
了しても長時間ＶＣが保持され続けると、同時に保持さ
れるＶＣの数が多くなる。
了しても長時間ＶＣが保持され続けると、同時に保持さ
れるＶＣの数が多くなる。
【００７２】問題１２．通信端末の不意の故障などによ
り、前記ＶＣ−ＴＡＧ通知ステップ実行後に前記カット
スルーＶＣ生成ステップが実行されない事態が発生する
可能性がある。この場合、ＶＣ−ＴＡＧ管理テーブル中
に生成予定ＶＣのエントリが長時間存在することとな
り、問題９の発生率を増加させる。
り、前記ＶＣ−ＴＡＧ通知ステップ実行後に前記カット
スルーＶＣ生成ステップが実行されない事態が発生する
可能性がある。この場合、ＶＣ−ＴＡＧ管理テーブル中
に生成予定ＶＣのエントリが長時間存在することとな
り、問題９の発生率を増加させる。
【００７３】サーバは人の操作によらず動作しているが
クライアントは人の操作によって動作している場合が多
いため、手段４により問題７として指摘したいたずらの
発生が人に認識され、早期にいたずらによる被害の継続
を終わらせることが可能となる。
クライアントは人の操作によって動作している場合が多
いため、手段４により問題７として指摘したいたずらの
発生が人に認識され、早期にいたずらによる被害の継続
を終わらせることが可能となる。
【００７４】手段５により、カットスルーＶＣ生成以前
にカットスルーＶＣ上で実行するアプリケーションを端
末間で申し合わせることとし、カットスルーＶＣ生成以
前に指定されたもの以外のアプリケーションがカットス
ルーＶＣ上で実行されるのを防止する。これにより、カ
ットスルーＶＣ上の通信を特定の目的に限ることができ
る。例えば、カットスルーＶＣ上で公開の情報を転送す
ることが目的であれば、非公開の情報を取得したりでき
ないように利用者の権限を制限することが可能なアプリ
ケーションを指定アプリケーションとして指定し、不正
な通信を防止できる。以上のとおり、手段５により問題
８を解決する。
にカットスルーＶＣ上で実行するアプリケーションを端
末間で申し合わせることとし、カットスルーＶＣ生成以
前に指定されたもの以外のアプリケーションがカットス
ルーＶＣ上で実行されるのを防止する。これにより、カ
ットスルーＶＣ上の通信を特定の目的に限ることができ
る。例えば、カットスルーＶＣ上で公開の情報を転送す
ることが目的であれば、非公開の情報を取得したりでき
ないように利用者の権限を制限することが可能なアプリ
ケーションを指定アプリケーションとして指定し、不正
な通信を防止できる。以上のとおり、手段５により問題
８を解決する。
【００７５】手段６、７は手段５においてカットスルー
ＶＣ上で指定アプリケーション以外のアプリケーション
が実行されるのを防ぐための具体的手段である。
ＶＣ上で指定アプリケーション以外のアプリケーション
が実行されるのを防ぐための具体的手段である。
【００７６】不正に使用されシステムに被害を与える可
能性が高いアプリケーションの多くは双方向の通信を必
要とするため、手段６により問題８を発生させる可能性
が高いアプリケーションがカットスルーＶＣ上で実行さ
れるのを防ぐことが可能となる。
能性が高いアプリケーションの多くは双方向の通信を必
要とするため、手段６により問題８を発生させる可能性
が高いアプリケーションがカットスルーＶＣ上で実行さ
れるのを防ぐことが可能となる。
【００７７】多くのアプリケーションはアプリケーショ
ンに固有の待ち受けポート番号に対してＴＣＰコネクシ
ョンの設定要求パケットを送ることにより起動されるた
め、手段７により不正ユーザが指定アプリケーション以
外のアプリケーションを起動することが不可能となり、
指定アプリケーション以外のアプリケーションがカット
スルーＶＣ上で実行されることが防止される。
ンに固有の待ち受けポート番号に対してＴＣＰコネクシ
ョンの設定要求パケットを送ることにより起動されるた
め、手段７により不正ユーザが指定アプリケーション以
外のアプリケーションを起動することが不可能となり、
指定アプリケーション以外のアプリケーションがカット
スルーＶＣ上で実行されることが防止される。
【００７８】手段８により、ＡＴＭ通信網は不正なＳＥ
ＴＵＰメッセージを発した通信端末からの呼設定要求の
処理をしばらく中断するなどの措置を講じることが可能
となり、問題１０を解決する。
ＴＵＰメッセージを発した通信端末からの呼設定要求の
処理をしばらく中断するなどの措置を講じることが可能
となり、問題１０を解決する。
【００７９】手段９により、すでにアプリケーションが
終了したカットスルーＶＣが一定時間保留後切断され、
問題１１を解決する。
終了したカットスルーＶＣが一定時間保留後切断され、
問題１１を解決する。
【００８０】手段１０により、通信端末の不意の故障な
どが原因で前記ＶＣ−ＴＡＧ通知ステップ実行後に前記
カットスルーＶＣ生成ステップが実行されない生成予定
ＶＣについての情報がＶＣ−ＴＡＧ管理テーブルから一
定時間経過後自動的に消去されることとなり問題１２を
解決する。
どが原因で前記ＶＣ−ＴＡＧ通知ステップ実行後に前記
カットスルーＶＣ生成ステップが実行されない生成予定
ＶＣについての情報がＶＣ−ＴＡＧ管理テーブルから一
定時間経過後自動的に消去されることとなり問題１２を
解決する。
【００８１】手段１１は、着呼時に照合するバイト列と
してＶＣ−ＴＡＧに加えて網羅的に候補値を生成するこ
とが困難なバイト列を用いることにより、カットスルー
ＶＣの申し合わせを行っていない第３者の通信端末がカ
ットスルーＶＣを生成することを困難とし問題９を解決
する。
してＶＣ−ＴＡＧに加えて網羅的に候補値を生成するこ
とが困難なバイト列を用いることにより、カットスルー
ＶＣの申し合わせを行っていない第３者の通信端末がカ
ットスルーＶＣを生成することを困難とし問題９を解決
する。
【００８２】しかし、上記の方式では新たに以下の問題
点が発生する。
点が発生する。
【００８３】問題１３．悪意を持ったユーザがパスワー
ドを通知しているＩＰ通信を傍受し、不正なカットスル
ーＶＣ生成を試みる可能性がある。
ドを通知しているＩＰ通信を傍受し、不正なカットスル
ーＶＣ生成を試みる可能性がある。
【００８４】しかし、手段１２または手段１３により、
正当なスレーブ側通信端末のみが正しくパスワードを復
唱することが可能となり、問題１３が解決される。
正当なスレーブ側通信端末のみが正しくパスワードを復
唱することが可能となり、問題１３が解決される。
【００８５】すなわち、本発明の第一の観点は通信装置
であって、本発明の特徴とするところは、ＩＰ通信を行
う手段およびＡＴＭ通信を行う手段を共に備え、通信を
行う相手装置とＩＰ通信を実行することによりこの相手
装置との間にカットスルーＶＣを設定することおよび回
線の設定条件の申し合わせを行う手段と、この申し合わ
せにしたがって前記相手装置との間にカットスルーＶＣ
を設定する手段とを備え、さらに相手装置との間にカッ
トスルーＶＣを設定して行う通信について当該カットス
ルーＶＣが前記設定条件の申し合わせを事前に行ったも
のか否かを判別する手段と、この判別結果が否であれば
当該通信の実行を拒否する手段とを備えたところにあ
る。
であって、本発明の特徴とするところは、ＩＰ通信を行
う手段およびＡＴＭ通信を行う手段を共に備え、通信を
行う相手装置とＩＰ通信を実行することによりこの相手
装置との間にカットスルーＶＣを設定することおよび回
線の設定条件の申し合わせを行う手段と、この申し合わ
せにしたがって前記相手装置との間にカットスルーＶＣ
を設定する手段とを備え、さらに相手装置との間にカッ
トスルーＶＣを設定して行う通信について当該カットス
ルーＶＣが前記設定条件の申し合わせを事前に行ったも
のか否かを判別する手段と、この判別結果が否であれば
当該通信の実行を拒否する手段とを備えたところにあ
る。
【００８６】これにより、セキュリティ性の高いＡＴＭ
通信によりデータ転送を行うことができる。このとき、
ＡＴＭ通信に先立って申し合わせを行った条件以外のカ
ットスルーＶＣを用いた通信を拒否することにより、さ
らに、セキュリティ性を高めることができる。
通信によりデータ転送を行うことができる。このとき、
ＡＴＭ通信に先立って申し合わせを行った条件以外のカ
ットスルーＶＣを用いた通信を拒否することにより、さ
らに、セキュリティ性を高めることができる。
【００８７】前記カットスルーＶＣの設定の申し合わせ
について、カットスルーＶＣ設定の条件を提示する側の
通信装置を主端末としもう一方の通信装置を従端末とす
るとき、前記申し合わせにもとづくカットスルーＶＣの
設定要求をこの従端末がＡＴＭ通信網に対して行う手段
を備えることが望ましい。
について、カットスルーＶＣ設定の条件を提示する側の
通信装置を主端末としもう一方の通信装置を従端末とす
るとき、前記申し合わせにもとづくカットスルーＶＣの
設定要求をこの従端末がＡＴＭ通信網に対して行う手段
を備えることが望ましい。
【００８８】前記申し合わせを行う手段は、カットスル
ーＶＣを前記端末間に設定して行う通信が可能であるか
否かを確認する手段を含み、その通信が可能でないとき
にはＩＰ通信によりデータ転送を実行する手段を備える
ことが望ましい。これにより、ＩＰ通信を行う手段しか
持っていない相手端末に対しても従来どおりにデータ転
送を行うことができる。
ーＶＣを前記端末間に設定して行う通信が可能であるか
否かを確認する手段を含み、その通信が可能でないとき
にはＩＰ通信によりデータ転送を実行する手段を備える
ことが望ましい。これにより、ＩＰ通信を行う手段しか
持っていない相手端末に対しても従来どおりにデータ転
送を行うことができる。
【００８９】前記設定条件は、カットスルーＶＣ上で実
行可能とするアプリケーション、通信条件、識別子およ
びＡＴＭアドレスを含むことが望ましい。
行可能とするアプリケーション、通信条件、識別子およ
びＡＴＭアドレスを含むことが望ましい。
【００９０】このとき、前記通信条件は、主端末が属す
るＬＡＮの実効通信速度、その負荷状況および可能な最
大通信速度を含むことが望ましい。
るＬＡＮの実効通信速度、その負荷状況および可能な最
大通信速度を含むことが望ましい。
【００９１】前記申し合わせにもとづき設定された相手
端末との間のカットスルーＶＣ上で実行を許可するアプ
リケーションを限定し、許可されていないアプリケーシ
ョンの実行を不可能にする手段を備えることが望まし
い。これにより、不要なアプリケーションの実行を不可
能とし、不正を試みる第三者によるアクセスを回避する
ことができる。
端末との間のカットスルーＶＣ上で実行を許可するアプ
リケーションを限定し、許可されていないアプリケーシ
ョンの実行を不可能にする手段を備えることが望まし
い。これにより、不要なアプリケーションの実行を不可
能とし、不正を試みる第三者によるアクセスを回避する
ことができる。
【００９２】前記カットスルーＶＣが通信を行う相手端
末との間に設定された後に、このカットスルーＶＣを用
いたＩＰ通信を行うことを不可能にする手段を含むこと
が望ましい。
末との間に設定された後に、このカットスルーＶＣを用
いたＩＰ通信を行うことを不可能にする手段を含むこと
が望ましい。
【００９３】前記カットスルーＶＣが事前に申し合わさ
れたものか否かの判別の結果として事前に申し合わされ
ていないカットスルーＶＣを用いた通信の実行要求を検
出したときには、この旨をネットワーク上の監視手段に
通知する手段を含むことが望ましい。このように不正を
試みる第三者の存在をネットワーク上の監視手段に通知
することにより、この監視手段はこれに対処することが
できる。
れたものか否かの判別の結果として事前に申し合わされ
ていないカットスルーＶＣを用いた通信の実行要求を検
出したときには、この旨をネットワーク上の監視手段に
通知する手段を含むことが望ましい。このように不正を
試みる第三者の存在をネットワーク上の監視手段に通知
することにより、この監視手段はこれに対処することが
できる。
【００９４】データ転送の完了から所定時間経過後に当
該データ転送に用いたカットスルーＶＣを自動的に切断
する手段を含むことが望ましい。これにより、不要なカ
ットスルーＶＣを速やかに切断し、不正を試みる第三者
のアクセスを回避することができる。
該データ転送に用いたカットスルーＶＣを自動的に切断
する手段を含むことが望ましい。これにより、不要なカ
ットスルーＶＣを速やかに切断し、不正を試みる第三者
のアクセスを回避することができる。
【００９５】前記申し合わせが行われてから所定時間後
にカットスルーＶＣの設定が行われないときには前記申
し合わせた設定条件を消去する手段を備えることが望ま
しい。これにより、前記申し合わせた条件に基づくカッ
トスルーＶＣの設定が不正を試みる第三者によって行わ
れることを回避することができる。
にカットスルーＶＣの設定が行われないときには前記申
し合わせた設定条件を消去する手段を備えることが望ま
しい。これにより、前記申し合わせた条件に基づくカッ
トスルーＶＣの設定が不正を試みる第三者によって行わ
れることを回避することができる。
【００９６】相手端末の正当性をパスワードにより確認
する手段を備えることが望ましい。このとき、データ転
送の開始毎に、相手端末の正当性をパスワードにより確
認する手段を含むことが望ましい。このように、パスワ
ードを前記識別子と併用することにより、通信のセキュ
リティ性を高めることができる。
する手段を備えることが望ましい。このとき、データ転
送の開始毎に、相手端末の正当性をパスワードにより確
認する手段を含むことが望ましい。このように、パスワ
ードを前記識別子と併用することにより、通信のセキュ
リティ性を高めることができる。
【００９７】パスワードを暗号化する手段と、暗号化さ
れたパスワードを復号化する手段とを備えることが望ま
しい。このとき、前記暗号化する手段は、当該パスワー
ドの送信先の端末に固有な公開鍵を用いて当該パスワー
ドを暗号化する手段を含む構成とすることもできる。
れたパスワードを復号化する手段とを備えることが望ま
しい。このとき、前記暗号化する手段は、当該パスワー
ドの送信先の端末に固有な公開鍵を用いて当該パスワー
ドを暗号化する手段を含む構成とすることもできる。
【００９８】主端末がサーバであり、従端末がクライア
ントである構成とすることもできる。このとき、前記サ
ーバは、ＡＴＭ通信を開始するときにクライアントに対
してクライアントからサーバへの通信帯域を“０”とす
る手段を含むことが望ましい。これにより、サーバに対
する不正を試みる第三者からのアクセスを回避すること
ができる。
ントである構成とすることもできる。このとき、前記サ
ーバは、ＡＴＭ通信を開始するときにクライアントに対
してクライアントからサーバへの通信帯域を“０”とす
る手段を含むことが望ましい。これにより、サーバに対
する不正を試みる第三者からのアクセスを回避すること
ができる。
【００９９】前記申し合わせにより決定された設定条件
のうち一部の当該設定条件の要素をＡＴＭ通信網に対す
るカットスルーＶＣの設定要求メッセージに記入する手
段を備える構成とすることもできる。この一部の当該設
定条件の要素は、例えば、カットスルーＶＣに対する識
別子およびまたはパスワードである。
のうち一部の当該設定条件の要素をＡＴＭ通信網に対す
るカットスルーＶＣの設定要求メッセージに記入する手
段を備える構成とすることもできる。この一部の当該設
定条件の要素は、例えば、カットスルーＶＣに対する識
別子およびまたはパスワードである。
【０１００】本発明の第二の観点は、ＡＴＭシグナリン
グ手順により設定されたコネクション上でセルを送受す
ることにより通信を行うＡＴＭ通信網と、インターネッ
トプロトコルに基づくＩＰパケットを順次中継すること
により通信を行うＩＰルーチング網と、これら二つの通
信網に接続される複数の通信端末とを備えたＩＰ−ＡＴ
Ｍハイブリッド通信網である。
グ手順により設定されたコネクション上でセルを送受す
ることにより通信を行うＡＴＭ通信網と、インターネッ
トプロトコルに基づくＩＰパケットを順次中継すること
により通信を行うＩＰルーチング網と、これら二つの通
信網に接続される複数の通信端末とを備えたＩＰ−ＡＴ
Ｍハイブリッド通信網である。
【０１０１】ここで、本発明の特徴とするところは、前
記通信端末は、前記ＩＰルーチング網を介する通信によ
り前記ＡＴＭ通信網を介してデータ転送を行うことを申
合せる手段と、この申合せにしたがってカットスルーＶ
Ｃによりデータ転送を行うとともに前記ＩＰ通信により
申合わせた条件以外のカットスルーＶＣを用いた通信を
拒否する手段とを備えたところにある。
記通信端末は、前記ＩＰルーチング網を介する通信によ
り前記ＡＴＭ通信網を介してデータ転送を行うことを申
合せる手段と、この申合せにしたがってカットスルーＶ
Ｃによりデータ転送を行うとともに前記ＩＰ通信により
申合わせた条件以外のカットスルーＶＣを用いた通信を
拒否する手段とを備えたところにある。
【０１０２】
【発明の実施の形態】発明の実施の形態を図１を参照し
て説明する。図１は本発明実施例の全体構成および通信
端末の要部ブロック構成を示す図である。
て説明する。図１は本発明実施例の全体構成および通信
端末の要部ブロック構成を示す図である。
【０１０３】本発明は、図１に示すように、ＩＰ通信を
行う手段であるＩＰ通信部２Ｍ、２ＳおよびＡＴＭ通信
を行う手段であるＡＴＭ−ＳＶＣ通信部１Ｍ、１Ｓを共
に備え、通信を行う相手装置とＩＰ通信を実行すること
によりこの相手装置との間にカットスルーＶＣを設定す
ることおよび回線の設定条件の申し合わせを行い、この
申し合わせにしたがって前記相手装置との間にカットス
ルーＶＣを設定し、さらに相手装置との間にカットスル
ーＶＣを設定して行う通信について当該カットスルーＶ
Ｃが前記設定条件の申し合わせを事前に行ったものか否
かを判別し、この判別結果が否であれば当該通信の実行
を拒否する手段である通信制御部７Ｍおよび７Ｓを備え
たところにある。
行う手段であるＩＰ通信部２Ｍ、２ＳおよびＡＴＭ通信
を行う手段であるＡＴＭ−ＳＶＣ通信部１Ｍ、１Ｓを共
に備え、通信を行う相手装置とＩＰ通信を実行すること
によりこの相手装置との間にカットスルーＶＣを設定す
ることおよび回線の設定条件の申し合わせを行い、この
申し合わせにしたがって前記相手装置との間にカットス
ルーＶＣを設定し、さらに相手装置との間にカットスル
ーＶＣを設定して行う通信について当該カットスルーＶ
Ｃが前記設定条件の申し合わせを事前に行ったものか否
かを判別し、この判別結果が否であれば当該通信の実行
を拒否する手段である通信制御部７Ｍおよび７Ｓを備え
たところにある。
【０１０４】ここでは、このカットスルーＶＣの設定の
申し合わせについて、カットスルーＶＣ設定の条件を提
示する側の通信装置をマスター側の通信端末１０としも
う一方の通信装置をスレーブ側の通信端末２０とする。
このとき、前記申し合わせにもとづくカットスルーＶＣ
の設定要求をこのスレーブ側の通信端末２０がＡＴＭ通
信網５０に対して行う。
申し合わせについて、カットスルーＶＣ設定の条件を提
示する側の通信装置をマスター側の通信端末１０としも
う一方の通信装置をスレーブ側の通信端末２０とする。
このとき、前記申し合わせにもとづくカットスルーＶＣ
の設定要求をこのスレーブ側の通信端末２０がＡＴＭ通
信網５０に対して行う。
【０１０５】また、本発明は、ＡＴＭシグナリング手順
により設定されたコネクション上でセルを送受すること
により通信を行うＡＴＭ通信網５０と、インターネット
プロトコルに基づくＩＰパケットを順次中継することに
より通信を行うＩＰルーチング網７０と、これら二つの
通信網に接続される複数の通信端末１０および２０とを
備えたＩＰ−ＡＴＭハイブリッド通信網である。
により設定されたコネクション上でセルを送受すること
により通信を行うＡＴＭ通信網５０と、インターネット
プロトコルに基づくＩＰパケットを順次中継することに
より通信を行うＩＰルーチング網７０と、これら二つの
通信網に接続される複数の通信端末１０および２０とを
備えたＩＰ−ＡＴＭハイブリッド通信網である。
【０１０６】ここで、本発明の特徴とするところは、通
信端末１０および２０は、ＩＰルーチング網７０を介す
る通信によりＡＴＭ通信網５０を介してデータ転送を行
うことを申合せこの申合せにしたがってカットスルーＶ
ＣであるカットスルーＶＣによりデータ転送を行うとと
もに前記ＩＰ通信により申合わせた条件以外のカットス
ルーＶＣを用いた通信を拒否する手段である通信制御部
７Ｍおよび７Ｓを備えたところにある。なお、前述した
識別子は本発明実施例ではＶＣ−ＴＡＧに相当する。
信端末１０および２０は、ＩＰルーチング網７０を介す
る通信によりＡＴＭ通信網５０を介してデータ転送を行
うことを申合せこの申合せにしたがってカットスルーＶ
ＣであるカットスルーＶＣによりデータ転送を行うとと
もに前記ＩＰ通信により申合わせた条件以外のカットス
ルーＶＣを用いた通信を拒否する手段である通信制御部
７Ｍおよび７Ｓを備えたところにある。なお、前述した
識別子は本発明実施例ではＶＣ−ＴＡＧに相当する。
【０１０７】
【実施例】（実施例における端末の構成）本発明の実施
例として本発明によるＩＰ−ＡＴＭハイブリッド通信方
式を拡張機能としたＷＷＷクライアント、ＷＷＷサーバ
を示す。ＷＷＷ（World Wide Web）とはＩＰルータ網上
の散在しているサーバ上の文字、データ、映像、音声な
どのファイル（以下では総称してＷｅｂリソースとす
る）を利用者が取得することを実現するシステムであ
る。
例として本発明によるＩＰ−ＡＴＭハイブリッド通信方
式を拡張機能としたＷＷＷクライアント、ＷＷＷサーバ
を示す。ＷＷＷ（World Wide Web）とはＩＰルータ網上
の散在しているサーバ上の文字、データ、映像、音声な
どのファイル（以下では総称してＷｅｂリソースとす
る）を利用者が取得することを実現するシステムであ
る。
【０１０８】情報を取得する通信端末をＷＷＷクライア
ントと呼び、情報を配信する通信端末をＷＷＷサーバと
呼ぶ。ＷＷＷクライアントは画面上にＷｅｂページと呼
ばれる画像を表示する。ＷｅｂページにはＵＲＬと呼ば
れるＷｅｂリソースの所在を表す情報（サーバのアドレ
ス、ファイル名）が埋め込まれており、ユーザがＷｅｂ
ページ内のある部分をマウスなどで選択するとＷＷＷク
ライアントはその個所に埋め込まれているＵＲＬが示す
ＷＷＷサーバにアクセスし、そのＷＷＷサーバからＵＲ
Ｌが示すファイルを取得する。この際のＷＷＷサーバか
らＷＷＷクライアントへの情報転送に用いられる典型的
なプロトコルとしてＨＴＴＰ（Hyper Text Transfer Pr
otocol）が用いられる。
ントと呼び、情報を配信する通信端末をＷＷＷサーバと
呼ぶ。ＷＷＷクライアントは画面上にＷｅｂページと呼
ばれる画像を表示する。ＷｅｂページにはＵＲＬと呼ば
れるＷｅｂリソースの所在を表す情報（サーバのアドレ
ス、ファイル名）が埋め込まれており、ユーザがＷｅｂ
ページ内のある部分をマウスなどで選択するとＷＷＷク
ライアントはその個所に埋め込まれているＵＲＬが示す
ＷＷＷサーバにアクセスし、そのＷＷＷサーバからＵＲ
Ｌが示すファイルを取得する。この際のＷＷＷサーバか
らＷＷＷクライアントへの情報転送に用いられる典型的
なプロトコルとしてＨＴＴＰ（Hyper Text Transfer Pr
otocol）が用いられる。
【０１０９】図１に示す通信端末１０および２０は、通
信端末１０がＷＷＷサーバであり、通信端末２０がＷＷ
Ｗクライアントであるということができる。このとき、
本実施例によるＷＷＷサーバ（以下、サーバと記す）は
ＡＴＭ−ＳＶＣ通信部１Ｍ、ＩＰ通信部２Ｍ、ＶＣ−Ｔ
ＡＧ管理モジュール８Ｍ、サーバアプリケーションモジ
ュールである通信制御部７Ｍによって構成され、ＷＷＷ
クライアント（以下、クライアントと記す）はＡＴＭ−
ＳＶＣ通信部１Ｓ、ＩＰ通信部２Ｓ、ＶＣ−ＴＡＧ管理
モジュール８Ｓ、クライアントアプリケーションモジュ
ールである通信制御部７Ｓによって構成される。ＶＣ−
ＴＡＧ管理モジュール８ＳはＶＣ−ＴＡＧ管理テーブル
５Ｓを有し、ＶＣ−ＴＡＧ管理モジュール８ＭはＶＣ−
ＴＡＧ割当て部６およびＶＣ−ＴＡＧ管理テーブル５Ｍ
を有する。
信端末１０がＷＷＷサーバであり、通信端末２０がＷＷ
Ｗクライアントであるということができる。このとき、
本実施例によるＷＷＷサーバ（以下、サーバと記す）は
ＡＴＭ−ＳＶＣ通信部１Ｍ、ＩＰ通信部２Ｍ、ＶＣ−Ｔ
ＡＧ管理モジュール８Ｍ、サーバアプリケーションモジ
ュールである通信制御部７Ｍによって構成され、ＷＷＷ
クライアント（以下、クライアントと記す）はＡＴＭ−
ＳＶＣ通信部１Ｓ、ＩＰ通信部２Ｓ、ＶＣ−ＴＡＧ管理
モジュール８Ｓ、クライアントアプリケーションモジュ
ールである通信制御部７Ｓによって構成される。ＶＣ−
ＴＡＧ管理モジュール８ＳはＶＣ−ＴＡＧ管理テーブル
５Ｓを有し、ＶＣ−ＴＡＧ管理モジュール８ＭはＶＣ−
ＴＡＧ割当て部６およびＶＣ−ＴＡＧ管理テーブル５Ｍ
を有する。
【０１１０】ＡＴＭ−ＳＶＣ通信部１Ｍおよび１ＳはＡ
ＴＭシグナリング手順によりカットスルーＶＣを設定ま
たは解放し、この設定されたカットスルーＶＣを用いて
情報を送受する。また、クライアントアプリケーション
である通信制御部７Ｓおよびサーバアプリケーションで
ある通信制御部７Ｍは、カットスルーＶＣ生成申し合わ
せを行い、本発明によって拡張を施されたＨＴＴＰプロ
トコルにより通信を行う。
ＴＭシグナリング手順によりカットスルーＶＣを設定ま
たは解放し、この設定されたカットスルーＶＣを用いて
情報を送受する。また、クライアントアプリケーション
である通信制御部７Ｓおよびサーバアプリケーションで
ある通信制御部７Ｍは、カットスルーＶＣ生成申し合わ
せを行い、本発明によって拡張を施されたＨＴＴＰプロ
トコルにより通信を行う。
【０１１１】サーバは実行を開始した直後はクライアン
トからの要求を待つ状態にあり、クライアントも実行を
開始した直後はユーザからの要求を待つ状態にある。ク
ライアントを持つユーザがＷｅｂページ上のある個所を
選択し、その結果、サーバからクライアントへ情報が転
送され、情報転送が終了し、クライアントおよびサーバ
共に元の状態に戻るまでがシステムの一連の動作であ
り、その間にシステムは以下のフェーズを経る。 (1) ＡＴＭ−ＳＶＣ通信能力（カットスルー拡張機能）
の確認 (2) カットスルーＶＣ生成の必要性の判断 (3) カットスルーＶＣ生成の申し合わせ (4) カットスルーＶＣ生成の開始（クライアント側） (5) カットスルーＶＣ生成の受付 (6) カットスルーＶＣ上でのアプリケーションの実行 (7) カットスルーＶＣの解放 以降では各フェーズにおける本実施例の詳細を説明す
る。
トからの要求を待つ状態にあり、クライアントも実行を
開始した直後はユーザからの要求を待つ状態にある。ク
ライアントを持つユーザがＷｅｂページ上のある個所を
選択し、その結果、サーバからクライアントへ情報が転
送され、情報転送が終了し、クライアントおよびサーバ
共に元の状態に戻るまでがシステムの一連の動作であ
り、その間にシステムは以下のフェーズを経る。 (1) ＡＴＭ−ＳＶＣ通信能力（カットスルー拡張機能）
の確認 (2) カットスルーＶＣ生成の必要性の判断 (3) カットスルーＶＣ生成の申し合わせ (4) カットスルーＶＣ生成の開始（クライアント側） (5) カットスルーＶＣ生成の受付 (6) カットスルーＶＣ上でのアプリケーションの実行 (7) カットスルーＶＣの解放 以降では各フェーズにおける本実施例の詳細を説明す
る。
【０１１２】（ＡＴＭ−ＳＶＣ通信能力（カットスルー
拡張機能）の確認）ユーザがＷｅｂページ中のある個所
を選択すると、通信制御部７Ｓはその部分に埋め込まれ
ているＵＲＬからアクセスすべきサーバを識別して、Ｉ
Ｐ通信部２Ｓによりそのサーバのサーバアプリケーショ
ンとＨＴＴＰ通信を行うためのＴＣＰ／ＩＰコネクショ
ンを設定する。
拡張機能）の確認）ユーザがＷｅｂページ中のある個所
を選択すると、通信制御部７Ｓはその部分に埋め込まれ
ているＵＲＬからアクセスすべきサーバを識別して、Ｉ
Ｐ通信部２Ｓによりそのサーバのサーバアプリケーショ
ンとＨＴＴＰ通信を行うためのＴＣＰ／ＩＰコネクショ
ンを設定する。
【０１１３】図２ないし図５はメッセージフォーマット
を示す図である。図６ないし図２２は各ステップのフロ
ーチャートである。図６（ステップ１）に示すように、
通信制御部７Ｍは通信制御部７Ｓに対してこれからアク
セスするサーバが本発明による拡張（以下ハイブリッド
拡張）に対応しているかどうか問い合わせる。この時ク
ライアントからサーバに送出される問い合わせメッセー
ジを図２(1) に示す。サーバは受けとったメッセージを
解析し、もし自分がハイブリッド拡張に対応しているの
であれば、問い合わせメッセージに対する返事として図
２(2)-a メッセージを返送する。また、自分がハイブリ
ッド拡張に対応していないか、もしくはなんらかの理由
で拡張システムを用いたくない場合には、拡張機能を使
えないことを示す図２(2)-b メッセージを返送する。
を示す図である。図６ないし図２２は各ステップのフロ
ーチャートである。図６（ステップ１）に示すように、
通信制御部７Ｍは通信制御部７Ｓに対してこれからアク
セスするサーバが本発明による拡張（以下ハイブリッド
拡張）に対応しているかどうか問い合わせる。この時ク
ライアントからサーバに送出される問い合わせメッセー
ジを図２(1) に示す。サーバは受けとったメッセージを
解析し、もし自分がハイブリッド拡張に対応しているの
であれば、問い合わせメッセージに対する返事として図
２(2)-a メッセージを返送する。また、自分がハイブリ
ッド拡張に対応していないか、もしくはなんらかの理由
で拡張システムを用いたくない場合には、拡張機能を使
えないことを示す図２(2)-b メッセージを返送する。
【０１１４】図２(2)-a メッセージが返ってきた場合は
サーバおよびクライアント双方ともハイブリッド拡張に
対応していることを表すので、その後、クライアントか
らサーバに送出されるメッセージにはハイブリッド拡張
を前提にしたメッセージが用いられる。また、図２(2)-
b を受信した場合、クライアントはサーバがハイブリッ
ド拡張に対応していないことを理解し、本発明による拡
張を施していない従来のＨＴＴＰメッセージを用いてサ
ーバと通信を行い、Ｗｅｂリソースを取得する。以上の
手順により、通信端末１０および２０間でＡＴＭ−ＳＶ
Ｃ通信能力を持つか否かを確認することが達成されてい
る。
サーバおよびクライアント双方ともハイブリッド拡張に
対応していることを表すので、その後、クライアントか
らサーバに送出されるメッセージにはハイブリッド拡張
を前提にしたメッセージが用いられる。また、図２(2)-
b を受信した場合、クライアントはサーバがハイブリッ
ド拡張に対応していないことを理解し、本発明による拡
張を施していない従来のＨＴＴＰメッセージを用いてサ
ーバと通信を行い、Ｗｅｂリソースを取得する。以上の
手順により、通信端末１０および２０間でＡＴＭ−ＳＶ
Ｃ通信能力を持つか否かを確認することが達成されてい
る。
【０１１５】（カットスルーＶＣ生成の必要性の判断）
次に、通信制御部７Ｓは、通信制御部７Ｍに対してユー
ザの要求するＷｅｂリソースをクライアント側に転送す
ることを要求するメッセージ（ＧＥＴメッセージ）を送
信する。Ｗｅｂリソースの転送に従来のＩＰルーチング
網上にすでに張られているＴＣＰコネクションを用いる
か、それとも新たにカットスルーＶＣを生成してこれを
用いるか判断する必要がある。
次に、通信制御部７Ｓは、通信制御部７Ｍに対してユー
ザの要求するＷｅｂリソースをクライアント側に転送す
ることを要求するメッセージ（ＧＥＴメッセージ）を送
信する。Ｗｅｂリソースの転送に従来のＩＰルーチング
網上にすでに張られているＴＣＰコネクションを用いる
か、それとも新たにカットスルーＶＣを生成してこれを
用いるか判断する必要がある。
【０１１６】本実施例では判断の基準としてクライアン
ト側に転送されるデータのサイズを用いる。すなわち、
図７（ステップ２）および図８（ステップ３）に示すよ
うに、ＧＥＴメッセージに"Cut-Through-Control" と呼
ばれる情報を付加してカットスルーＶＣに切り替える条
件を提示する。ここで示される例では、もしクライアン
トに転送されるデータのサイズがth＿sizeで示される値
よりも大きければ、カットスルーＶＣの生成を行う。サ
ーバはクライアントがCut-Through-Control で示した判
断基準に従いカットスルーＶＣを生成するか否かを判断
し、ＧＥＴに対する応答として図２(4) に示すようなメ
ッセージを返す。
ト側に転送されるデータのサイズを用いる。すなわち、
図７（ステップ２）および図８（ステップ３）に示すよ
うに、ＧＥＴメッセージに"Cut-Through-Control" と呼
ばれる情報を付加してカットスルーＶＣに切り替える条
件を提示する。ここで示される例では、もしクライアン
トに転送されるデータのサイズがth＿sizeで示される値
よりも大きければ、カットスルーＶＣの生成を行う。サ
ーバはクライアントがCut-Through-Control で示した判
断基準に従いカットスルーＶＣを生成するか否かを判断
し、ＧＥＴに対する応答として図２(4) に示すようなメ
ッセージを返す。
【０１１７】またこの段階においてサーバはクライアン
トとの利用者認証手順を起動し、利用者を認証すること
も可能である。図２(4) は、判断の結果として、サーバ
がカットスルーＶＣを生成することを提案している例で
ある。以上までの手順により転送すべき情報の量が多い
時だけカットスルーＶＣを生成することとする判断処理
が達成されている。
トとの利用者認証手順を起動し、利用者を認証すること
も可能である。図２(4) は、判断の結果として、サーバ
がカットスルーＶＣを生成することを提案している例で
ある。以上までの手順により転送すべき情報の量が多い
時だけカットスルーＶＣを生成することとする判断処理
が達成されている。
【０１１８】（カットスルーＶＣ生成の申し合わせ）図
９（ステップ４）に示すように、サーバ−クライアント
間でカットスルーＶＣを生成することにしたとき、次に
カットスルーＶＣの生成に必要な情報のやりとりを行わ
なくてはならない。カットスルーＶＣの生成手順はクラ
イアント側から起動されるが、このためにクライアント
はサーバ側のＡＴＭアドレスなどの情報を得なければな
らない。また生成されるカットスルーＶＣの種類、帯域
などをサーバとの間で交渉する必要がある。以上の情報
の取得はクライアントがサーバに対しカットスルーＶＣ
を生成する旨を示すメッセージ（以下「CUT-THROUGH SE
TUP 」）を送り、これに対しサーバがクライアントに応
答メッセージを送る手順によって達成される。
９（ステップ４）に示すように、サーバ−クライアント
間でカットスルーＶＣを生成することにしたとき、次に
カットスルーＶＣの生成に必要な情報のやりとりを行わ
なくてはならない。カットスルーＶＣの生成手順はクラ
イアント側から起動されるが、このためにクライアント
はサーバ側のＡＴＭアドレスなどの情報を得なければな
らない。また生成されるカットスルーＶＣの種類、帯域
などをサーバとの間で交渉する必要がある。以上の情報
の取得はクライアントがサーバに対しカットスルーＶＣ
を生成する旨を示すメッセージ（以下「CUT-THROUGH SE
TUP 」）を送り、これに対しサーバがクライアントに応
答メッセージを送る手順によって達成される。
【０１１９】CUT-THROUGH SETUPメッセージの例を図２
(5) に示す。このメッセージに含まれる情報の例として
は、" クライアントのＡＴＭアドレス" 、" 生成される
カットスルーＶＣの種類" などがある。クライアントの
ＡＴＭアドレスはサーバ側で現在行われているＨＴＴＰ
メッセージの一連のやり取り（以下セッションと呼ぶ）
を識別するために用いられる。またクライアント側で生
成することの出来るカットスルーＶＣの種類をサーバに
知らせ、サーバがそのカットスルーＶＣを受けいれるこ
とが出来るかどうか問い合わせる。
(5) に示す。このメッセージに含まれる情報の例として
は、" クライアントのＡＴＭアドレス" 、" 生成される
カットスルーＶＣの種類" などがある。クライアントの
ＡＴＭアドレスはサーバ側で現在行われているＨＴＴＰ
メッセージの一連のやり取り（以下セッションと呼ぶ）
を識別するために用いられる。またクライアント側で生
成することの出来るカットスルーＶＣの種類をサーバに
知らせ、サーバがそのカットスルーＶＣを受けいれるこ
とが出来るかどうか問い合わせる。
【０１２０】このメッセージを受けとったサーバは、ま
ずクライアントの提示したカットスルーＶＣを自分が受
けいれることが出来るかどうか判断する。サーバは能力
的に受けいれることが出来ても、回線が混んでいる場合
など、物理的に受けいれることが難しければクライアン
トの提示した条件を拒絶することもあり得る。この場合
は拒絶を表すメッセージをクライアントに返送する。拒
絶メッセージを受けとったクライアントは、可能であれ
ば適当な時間待機したのち、再び図２(5) に準じたメッ
セージを生成し、サーバに対して送信する。このように
図２(5) のメッセージによるカットスルーＶＣの交渉
は、双方で折り合いがつくまで何度でも行うことができ
る。
ずクライアントの提示したカットスルーＶＣを自分が受
けいれることが出来るかどうか判断する。サーバは能力
的に受けいれることが出来ても、回線が混んでいる場合
など、物理的に受けいれることが難しければクライアン
トの提示した条件を拒絶することもあり得る。この場合
は拒絶を表すメッセージをクライアントに返送する。拒
絶メッセージを受けとったクライアントは、可能であれ
ば適当な時間待機したのち、再び図２(5) に準じたメッ
セージを生成し、サーバに対して送信する。このように
図２(5) のメッセージによるカットスルーＶＣの交渉
は、双方で折り合いがつくまで何度でも行うことができ
る。
【０１２１】図１０（ステップ５）に示すように、クラ
イアントから提示されたカットスルーＶＣをサーバが受
けいれる場合には、通信制御部７ＭはＡＴＭ−ＳＶＣ通
信部１Ｍに対して図３(6) に示すメッセージ（以下「セ
ッション登録通知」）を送り、生成される予定となった
カットスルーＶＣの情報（クライアントのＡＴＭアドレ
ス、生成されるカットスルーＶＣの種類、サーバの識別
子など）をＶＣ−ＴＡＧ管理モジュール８に通知する。
イアントから提示されたカットスルーＶＣをサーバが受
けいれる場合には、通信制御部７ＭはＡＴＭ−ＳＶＣ通
信部１Ｍに対して図３(6) に示すメッセージ（以下「セ
ッション登録通知」）を送り、生成される予定となった
カットスルーＶＣの情報（クライアントのＡＴＭアドレ
ス、生成されるカットスルーＶＣの種類、サーバの識別
子など）をＶＣ−ＴＡＧ管理モジュール８に通知する。
【０１２２】図１１（ステップ６）に示すように、通信
制御部７Ｍからのセッション登録通知を受けとったＶＣ
−ＴＡＧ管理モジュール８Ｍは、既に割り当てられてお
り現在有効なＶＣ−ＴＡＧと重複しないように新たなＶ
Ｃ−ＴＡＧを選択し、新規に登録されたセッション用の
カットスルーＶＣに対して割り当てる。さらにＶＣ−Ｔ
ＡＧ管理テーブル５Ｍに新規エントリを作成し、そのエ
ントリに通知されたセッションの情報と割り当てられた
ＶＣ−ＴＡＧを記憶し、そのエントリのカットスルーＶ
Ｃの状態を「生成予定」とする。そしてＶＣ−ＴＡＧ管
理モジュール８Ｍは通信制御部７Ｍに対する応答メッセ
ージ図３(7) を送り、割り当てられたＶＣ−ＴＡＧを通
信制御部７Ｍに通知する。
制御部７Ｍからのセッション登録通知を受けとったＶＣ
−ＴＡＧ管理モジュール８Ｍは、既に割り当てられてお
り現在有効なＶＣ−ＴＡＧと重複しないように新たなＶ
Ｃ−ＴＡＧを選択し、新規に登録されたセッション用の
カットスルーＶＣに対して割り当てる。さらにＶＣ−Ｔ
ＡＧ管理テーブル５Ｍに新規エントリを作成し、そのエ
ントリに通知されたセッションの情報と割り当てられた
ＶＣ−ＴＡＧを記憶し、そのエントリのカットスルーＶ
Ｃの状態を「生成予定」とする。そしてＶＣ−ＴＡＧ管
理モジュール８Ｍは通信制御部７Ｍに対する応答メッセ
ージ図３(7) を送り、割り当てられたＶＣ−ＴＡＧを通
信制御部７Ｍに通知する。
【０１２３】セッションの登録によって、サーバ側でカ
ットスルーＶＣを着呼する準備は整ったことになる。図
１２（ステップ７）に示すように、次にサーバはクライ
アントに対して図２(5) に対する応答メッセージとして
図２(8) に示すメッセージを送り、カットスルーＶＣの
生成に必要な情報をクライアントに知らせる。図２(8)
が示すとおり、このときクライアント側に知らされる情
報は“サーバのＡＴＭアドレス”、“ＶＣ−ＴＡＧ”、
サーバ側の実効通信速度などがある。以上までの通信手
順によりサーバがクライアントに対しカットスルーＶＣ
の生成に必要なＡＴＭアドレス、実行通信速度を通知す
ることが達成されている。
ットスルーＶＣを着呼する準備は整ったことになる。図
１２（ステップ７）に示すように、次にサーバはクライ
アントに対して図２(5) に対する応答メッセージとして
図２(8) に示すメッセージを送り、カットスルーＶＣの
生成に必要な情報をクライアントに知らせる。図２(8)
が示すとおり、このときクライアント側に知らされる情
報は“サーバのＡＴＭアドレス”、“ＶＣ−ＴＡＧ”、
サーバ側の実効通信速度などがある。以上までの通信手
順によりサーバがクライアントに対しカットスルーＶＣ
の生成に必要なＡＴＭアドレス、実行通信速度を通知す
ることが達成されている。
【０１２４】なお、実効通信速度その他の通信条件は、
通信端末１０の通信条件提示部３により生成される。ま
た、この通信条件は、通信端末２０の通信条件確認部４
により確認される。
通信端末１０の通信条件提示部３により生成される。ま
た、この通信条件は、通信端末２０の通信条件確認部４
により確認される。
【０１２５】（カットスルーＶＣの生成の開始）カット
スルーＶＣの生成に必要な情報を得た通信制御部７Ｍ
は、図１３（ステップ８）に示すように、カットスルー
ＶＣを生成するために、ＡＴＭ−ＳＶＣ通信部１Ｍに図
３(9) に示すＳＶＣ設定ＲＥＱ. を伝達し、サーバのＡ
ＴＭアドレス、カットスルーＶＣの帯域、発呼時にＳＥ
ＴＵＰメッセージに記入すべきＶＣ−ＴＡＧを通知す
る。
スルーＶＣの生成に必要な情報を得た通信制御部７Ｍ
は、図１３（ステップ８）に示すように、カットスルー
ＶＣを生成するために、ＡＴＭ−ＳＶＣ通信部１Ｍに図
３(9) に示すＳＶＣ設定ＲＥＱ. を伝達し、サーバのＡ
ＴＭアドレス、カットスルーＶＣの帯域、発呼時にＳＥ
ＴＵＰメッセージに記入すべきＶＣ−ＴＡＧを通知す
る。
【０１２６】図１４（ステップ９）に示すように、ＡＴ
Ｍ−ＳＶＣ通信部１Ｓは、通知されたサーバのＡＴＭア
ドレスをCalled Party Number とし、通知された帯域を
要求帯域として指定し、さらに通知されたＶＣ−ＴＡＧ
を記入して、ＳＥＴＵＰメッセージをＡＴＭ通信網に送
出する。ＳＥＴＵＰメッセージ中にＶＣ−ＴＡＧを記入
する方法としては次の４方式が考えられる。
Ｍ−ＳＶＣ通信部１Ｓは、通知されたサーバのＡＴＭア
ドレスをCalled Party Number とし、通知された帯域を
要求帯域として指定し、さらに通知されたＶＣ−ＴＡＧ
を記入して、ＳＥＴＵＰメッセージをＡＴＭ通信網に送
出する。ＳＥＴＵＰメッセージ中にＶＣ−ＴＡＧを記入
する方法としては次の４方式が考えられる。
【０１２７】１．Broadband High Layer Information情
報要素を用いる。
報要素を用いる。
【０１２８】２．User-User Dataを用いる。
【０１２９】３．ＡＴＭアドレスのＳＥＬ部分に付加す
る。
る。
【０１３０】４．ＧＩＴ(Generic Identifier Transpor
t)情報要素を用いる。
t)情報要素を用いる。
【０１３１】ここでは3.の方式を用いてＳＥＴＵＰにＶ
Ｃ−ＴＡＧを埋め込む。ＶＣ−ＴＡＧを埋め込まれたＳ
ＥＴＵＰは途中１つ以上のＡＴＭスイッチを経由して、
サーバのＡＴＭ−ＳＶＣ通信部１Ｍに送られる。
Ｃ−ＴＡＧを埋め込む。ＶＣ−ＴＡＧを埋め込まれたＳ
ＥＴＵＰは途中１つ以上のＡＴＭスイッチを経由して、
サーバのＡＴＭ−ＳＶＣ通信部１Ｍに送られる。
【０１３２】（カットスルーＶＣの受付）図１５（ステ
ップ１０−１）に示すように、サーバ側のＡＴＭ−ＳＶ
Ｃ通信部１ＭはＳＥＴＵＰを受け取ると、そのＳＥＴＵ
Ｐが通信制御部７Ｓと通信制御部７Ｍとの間で正規の手
続きを経て発行されたものかどうか調べるために、ＶＣ
−ＴＡＧ管理テーブル５Ｍに図２(11)ＶＣ−ＴＡＧ問い
合わせＲＥＱを伝達し、受信したＳＥＴＵＰメッセージ
中に記入されていたＶＣ−ＴＡＧ、Call ReferenceValu
e、ＶＰＩ／ＶＣＩを通知する。
ップ１０−１）に示すように、サーバ側のＡＴＭ−ＳＶ
Ｃ通信部１ＭはＳＥＴＵＰを受け取ると、そのＳＥＴＵ
Ｐが通信制御部７Ｓと通信制御部７Ｍとの間で正規の手
続きを経て発行されたものかどうか調べるために、ＶＣ
−ＴＡＧ管理テーブル５Ｍに図２(11)ＶＣ−ＴＡＧ問い
合わせＲＥＱを伝達し、受信したＳＥＴＵＰメッセージ
中に記入されていたＶＣ−ＴＡＧ、Call ReferenceValu
e、ＶＰＩ／ＶＣＩを通知する。
【０１３３】図１６（ステップ１１）に示すように、も
しＶＣ−ＴＡＧ管理テーブル５Ｍに該当ＶＣ−ＴＡＧが
存在し、かつその状態が生成予定であれば、届いたＳＥ
ＴＵＰメッセージは正当なものである。この場合には、
ＶＣ−ＴＡＧ管理テーブル５ＭはＶＣ−ＴＡＧ管理テー
ブル５Ｍ中の当該ＶＣ−ＴＡＧが示すエントリにCallRe
ference Value、ＶＰＩ／ＶＣＩ値などの情報を書き加
え、状態を“使用中”に変更し、ＡＴＭ−ＳＶＣ通信部
１Ｍに図３(12)ＶＣ−ＴＡＧ問い合わせＲＥＳＰを返
し、呼を受け付ける旨を通知する。図３(12)にはアプリ
ケーションの識別子（ＶＣ−ＴＡＧ管理テーブル５Ｍや
ＡＴＭ−ＳＶＣ通信部１Ｍからのメッセージを受け付け
る論理ポート番号：以下ポート）が入っている。また、
もしＶＣ−ＴＡＧ管理テーブル５Ｍに該当ＶＣ−ＴＡＧ
が存在しない場合には、到着したＳＥＴＵＰが通信制御
部７Ｓと通信制御部７Ｍとの間で正規の手続きを経て発
行されたものではない。このような場合ＶＣ−ＴＡＧ管
理テーブル５Ｍはアプリケーション識別子として“−
１”を指定して図２(12)ＶＣ−ＴＡＧ問い合わせＲＥＳ
Ｐを返し、呼を拒絶する旨をＡＴＭ−ＳＶＣ通信部１Ｍ
に通知する。
しＶＣ−ＴＡＧ管理テーブル５Ｍに該当ＶＣ−ＴＡＧが
存在し、かつその状態が生成予定であれば、届いたＳＥ
ＴＵＰメッセージは正当なものである。この場合には、
ＶＣ−ＴＡＧ管理テーブル５ＭはＶＣ−ＴＡＧ管理テー
ブル５Ｍ中の当該ＶＣ−ＴＡＧが示すエントリにCallRe
ference Value、ＶＰＩ／ＶＣＩ値などの情報を書き加
え、状態を“使用中”に変更し、ＡＴＭ−ＳＶＣ通信部
１Ｍに図３(12)ＶＣ−ＴＡＧ問い合わせＲＥＳＰを返
し、呼を受け付ける旨を通知する。図３(12)にはアプリ
ケーションの識別子（ＶＣ−ＴＡＧ管理テーブル５Ｍや
ＡＴＭ−ＳＶＣ通信部１Ｍからのメッセージを受け付け
る論理ポート番号：以下ポート）が入っている。また、
もしＶＣ−ＴＡＧ管理テーブル５Ｍに該当ＶＣ−ＴＡＧ
が存在しない場合には、到着したＳＥＴＵＰが通信制御
部７Ｓと通信制御部７Ｍとの間で正規の手続きを経て発
行されたものではない。このような場合ＶＣ−ＴＡＧ管
理テーブル５Ｍはアプリケーション識別子として“−
１”を指定して図２(12)ＶＣ−ＴＡＧ問い合わせＲＥＳ
Ｐを返し、呼を拒絶する旨をＡＴＭ−ＳＶＣ通信部１Ｍ
に通知する。
【０１３４】図１７（ステップ１２）に示すように、図
３(12)ＶＣ−ＴＡＧ問い合わせＲＥＳＰを受けとったＡ
ＴＭ−ＳＶＣ通信部１Ｓは、アプリケーション識別子が
“−１”であればＡＴＭ通信網５０に対して図３(10)-c
ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッセージを発行
する。この際、ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッ
セージ中のCause value の値として不正なユーザからの
アクセスを検出したことを示す値（100 0010="Invalid
Access Detected"）を新たに定義し、この値を用いる。
この場合クライアント側のＡＴＭ−ＳＶＣ通信部１Ｍが
発呼した呼は拒絶されたこととなる。また、アプリケー
ション識別子が“−１”以外であった場合、ＡＴＭ−Ｓ
ＶＣ通信部１ＳはＡＴＭ通信網５０に対して ＣＯＮＮ
ＥＣＴを発行する。同時にＡＴＭ−ＳＶＣ通信部１Ｓは
通信制御部７Ｓに対して図３(13)着呼通知を伝達し、着
呼したカットスルーＶＣのＶＰＩ／ＶＣＩを通知する。
３(12)ＶＣ−ＴＡＧ問い合わせＲＥＳＰを受けとったＡ
ＴＭ−ＳＶＣ通信部１Ｓは、アプリケーション識別子が
“−１”であればＡＴＭ通信網５０に対して図３(10)-c
ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッセージを発行
する。この際、ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥメッ
セージ中のCause value の値として不正なユーザからの
アクセスを検出したことを示す値（100 0010="Invalid
Access Detected"）を新たに定義し、この値を用いる。
この場合クライアント側のＡＴＭ−ＳＶＣ通信部１Ｍが
発呼した呼は拒絶されたこととなる。また、アプリケー
ション識別子が“−１”以外であった場合、ＡＴＭ−Ｓ
ＶＣ通信部１ＳはＡＴＭ通信網５０に対して ＣＯＮＮ
ＥＣＴを発行する。同時にＡＴＭ−ＳＶＣ通信部１Ｓは
通信制御部７Ｓに対して図３(13)着呼通知を伝達し、着
呼したカットスルーＶＣのＶＰＩ／ＶＣＩを通知する。
【０１３５】図１８（ステップ１３）に示すように、図
３(13)着呼通知を受けとった通信制御部７Ｓは、情報の
送受を行う論理ポート（以降ソケット）を新たに生成
し、通知されたＶＰＩ／ＶＣＩのカットスルーＶＣで送
られてきた情報はその論理ポートへ伝達されるようにＯ
Ｓに設定（この設定をバインドと呼ぶ）する。
３(13)着呼通知を受けとった通信制御部７Ｓは、情報の
送受を行う論理ポート（以降ソケット）を新たに生成
し、通知されたＶＰＩ／ＶＣＩのカットスルーＶＣで送
られてきた情報はその論理ポートへ伝達されるようにＯ
Ｓに設定（この設定をバインドと呼ぶ）する。
【０１３６】以上の手順によって、サーバがあらかじめ
生成を申し合わせたカットスルーＶＣのみを着呼するこ
と、着呼したカットスルーＶＣについてはそのＶＣ上で
転送される情報があらかじめ指定されたアプリケーショ
ンにのみ転送されるようにすること、受信したＳＥＴＵ
Ｐメッセージが無効であった場合にその旨をＡＴＭ通信
網５０に通知することが達成されている。
生成を申し合わせたカットスルーＶＣのみを着呼するこ
と、着呼したカットスルーＶＣについてはそのＶＣ上で
転送される情報があらかじめ指定されたアプリケーショ
ンにのみ転送されるようにすること、受信したＳＥＴＵ
Ｐメッセージが無効であった場合にその旨をＡＴＭ通信
網５０に通知することが達成されている。
【０１３７】図１９（ステップ１０−２）に示すよう
に、一方、サーバ側のＡＴＭ−ＳＶＣ通信部１Ｍが Ｃ
ＯＮＮＥＣＴを送ったことにより、クライアント側のＡ
ＴＭ−ＳＶＣ通信部１ＳはＡＴＭ通信網５０からＣＯＮ
ＮＥＣＴを受信することとなる。ＣＯＮＮＥＣＴを受け
とったクライアント側のＡＴＭ−ＳＶＣ通信部１Ｓは、
ＣＯＮＮＥＣＴによって得られたCall Reference Valu
e, ＶＰＩ／ＶＣＩ値などの情報と、ＶＣ−ＴＡＧ情
報、アプリケーション識別子、ＶＣの状態、状態遷移時
刻などの情報をＶＣ−ＴＡＧ登録ＲＥＱに記入し、これ
をＶＣ−ＴＡＧ管理テーブル５Ｓに伝達する。
に、一方、サーバ側のＡＴＭ−ＳＶＣ通信部１Ｍが Ｃ
ＯＮＮＥＣＴを送ったことにより、クライアント側のＡ
ＴＭ−ＳＶＣ通信部１ＳはＡＴＭ通信網５０からＣＯＮ
ＮＥＣＴを受信することとなる。ＣＯＮＮＥＣＴを受け
とったクライアント側のＡＴＭ−ＳＶＣ通信部１Ｓは、
ＣＯＮＮＥＣＴによって得られたCall Reference Valu
e, ＶＰＩ／ＶＣＩ値などの情報と、ＶＣ−ＴＡＧ情
報、アプリケーション識別子、ＶＣの状態、状態遷移時
刻などの情報をＶＣ−ＴＡＧ登録ＲＥＱに記入し、これ
をＶＣ−ＴＡＧ管理テーブル５Ｓに伝達する。
【０１３８】図２０（ステップ１４）に示すように、Ｖ
Ｃ−ＴＡＧ登録ＲＥＱを受けとったＶＣ−ＴＡＧ管理テ
ーブル５ＳはＶＣ−ＴＡＧ管理テーブル５Ｓに新規エン
トリを作成して通知されたＶＣ−ＴＡＧ情報を書き込
み、そのエントリのカットスルーＶＣの状態を「使用
中」とする。そしてＶＣ−ＴＡＧ登録ＲＥＳＰを返送す
る。
Ｃ−ＴＡＧ登録ＲＥＱを受けとったＶＣ−ＴＡＧ管理テ
ーブル５ＳはＶＣ−ＴＡＧ管理テーブル５Ｓに新規エン
トリを作成して通知されたＶＣ−ＴＡＧ情報を書き込
み、そのエントリのカットスルーＶＣの状態を「使用
中」とする。そしてＶＣ−ＴＡＧ登録ＲＥＳＰを返送す
る。
【０１３９】図２１（ステップ１５）に示すように、Ｖ
Ｃ−ＴＡＧ登録ＲＥＳＰを受けとったＡＴＭ−ＳＶＣ通
信部１Ｓは、通信制御部７Ｓに対しＳＶＣ設定要求に対
する応答メッセージ（ＳＶＣ設定ＲＥＳＰ）を伝達し、
生成された呼のＶＰＩ／ＶＣＩを通信制御部７Ｓに通知
する。また、バインドするべきＳＶＣに関する情報を通
信制御部７Ｓに通知する。
Ｃ−ＴＡＧ登録ＲＥＳＰを受けとったＡＴＭ−ＳＶＣ通
信部１Ｓは、通信制御部７Ｓに対しＳＶＣ設定要求に対
する応答メッセージ（ＳＶＣ設定ＲＥＳＰ）を伝達し、
生成された呼のＶＰＩ／ＶＣＩを通信制御部７Ｓに通知
する。また、バインドするべきＳＶＣに関する情報を通
信制御部７Ｓに通知する。
【０１４０】図２２（ステップ１６）に示すように、Ａ
ＴＭ−ＳＶＣ通信ＲＥＳＰを受け取った通信制御部７Ｓ
はサーバの場合と同様にソケットを生成し、通知された
ＶＰＩ／ＶＣＩのＶＣで転送されてきた情報が生成され
たソケットに伝達されるようにＯＳに設定（バインド）
する。図２３は、図６〜図２２の手順を示すシーケンス
図である。
ＴＭ−ＳＶＣ通信ＲＥＳＰを受け取った通信制御部７Ｓ
はサーバの場合と同様にソケットを生成し、通知された
ＶＰＩ／ＶＣＩのＶＣで転送されてきた情報が生成され
たソケットに伝達されるようにＯＳに設定（バインド）
する。図２３は、図６〜図２２の手順を示すシーケンス
図である。
【０１４１】（カットスルーＶＣ上でのアプリケーショ
ンの実行）図２４および図２５はカットスルーＶＣを用
いたＨＴＴＰメッセージのやりとりの手順を説明するた
めの図である。通信制御部７Ｍと通信制御部７Ｓの両方
でＳＶＣのバインドが終了した時点で、カットスルーＶ
Ｃを用いたＨＴＴＰメッセージのやりとりが可能にな
る。図２４および図２５に示すように、通信制御部７Ｓ
はユーザが選択したＷｅｂリソースの転送を要求する
(a) ＧＥＴ−ＲＥＱを通信制御部７Ｍに送信する。ＧＥ
Ｔ−ＲＥＱを受けとった通信制御部７Ｍは、ユーザから
要求されたＷｅｂリソースの内容を含む(b) ＧＥＴ−Ｒ
ＥＳＰメッセージをのせて返送する。
ンの実行）図２４および図２５はカットスルーＶＣを用
いたＨＴＴＰメッセージのやりとりの手順を説明するた
めの図である。通信制御部７Ｍと通信制御部７Ｓの両方
でＳＶＣのバインドが終了した時点で、カットスルーＶ
Ｃを用いたＨＴＴＰメッセージのやりとりが可能にな
る。図２４および図２５に示すように、通信制御部７Ｓ
はユーザが選択したＷｅｂリソースの転送を要求する
(a) ＧＥＴ−ＲＥＱを通信制御部７Ｍに送信する。ＧＥ
Ｔ−ＲＥＱを受けとった通信制御部７Ｍは、ユーザから
要求されたＷｅｂリソースの内容を含む(b) ＧＥＴ−Ｒ
ＥＳＰメッセージをのせて返送する。
【０１４２】（カットスルーＶＣの解放）図２６（ステ
ップ１７）に示すように、通信制御部７Ｍおよび通信制
御部７Ｓ間で一定時間メッセージのやり取りが無かった
とき、また通信制御部７Ｓ側で明示的にカットスルーＶ
Ｃの終了を宣言した場合にカットスルーＶＣ解放のため
の手順が起動される。カットスルーＶＣの解放時に行わ
なくてはならない処理は次の二つである。
ップ１７）に示すように、通信制御部７Ｍおよび通信制
御部７Ｓ間で一定時間メッセージのやり取りが無かった
とき、また通信制御部７Ｓ側で明示的にカットスルーＶ
Ｃの終了を宣言した場合にカットスルーＶＣ解放のため
の手順が起動される。カットスルーＶＣの解放時に行わ
なくてはならない処理は次の二つである。
【０１４３】１．カットスルーＶＣに関する情報をＶＣ
−ＴＡＧ管理モジュールから消去する。
−ＴＡＧ管理モジュールから消去する。
【０１４４】２．カットスルーＶＣの解放。
【０１４５】このうち後者はクライアントからＲＥＬＥ
ＡＳＥメッセージを発行することによって行う。前者に
ついては通信制御部７Ｍと通信制御部７Ｓの両方で行う
必要があり、通信制御部７ＭでカットスルーＶＣに関す
る情報を消去するためには通信制御部７Ｓから通信制御
部７Ｍに登録の削除を要求しなくてはならない。以下に
上記の二つの処理を実行する手順の詳細を述べる。
ＡＳＥメッセージを発行することによって行う。前者に
ついては通信制御部７Ｍと通信制御部７Ｓの両方で行う
必要があり、通信制御部７ＭでカットスルーＶＣに関す
る情報を消去するためには通信制御部７Ｓから通信制御
部７Ｍに登録の削除を要求しなくてはならない。以下に
上記の二つの処理を実行する手順の詳細を述べる。
【０１４６】カットスルーＶＣを解放することに決定し
たとき、図２７（ステップ１８）に示すように、まず通
信制御部７Ｓは解放すべきカットスルーＶＣのＶＣ−Ｔ
ＡＧを記入した図４(17) CUT-THROUGH TEAR-DOWN-REQを
通信制御部７Ｍに対し送る。
たとき、図２７（ステップ１８）に示すように、まず通
信制御部７Ｓは解放すべきカットスルーＶＣのＶＣ−Ｔ
ＡＧを記入した図４(17) CUT-THROUGH TEAR-DOWN-REQを
通信制御部７Ｍに対し送る。
【０１４７】通信制御部７ＭはＶＣ−ＴＡＧ管理テーブ
ル５Ｓの該当セッションに関する情報の消去を２段階で
行う。第１段階、すなわち図４(17)メッセージを受けと
った段階では解放するカットスルーＶＣの状態を“使用
中”から“解放中”に変更することしか行わない。実際
に消去を行うのはカットスルーＶＣが解放された後であ
る。
ル５Ｓの該当セッションに関する情報の消去を２段階で
行う。第１段階、すなわち図４(17)メッセージを受けと
った段階では解放するカットスルーＶＣの状態を“使用
中”から“解放中”に変更することしか行わない。実際
に消去を行うのはカットスルーＶＣが解放された後であ
る。
【０１４８】図２８（ステップ１９）に示すように、図
４(17)CUT-THROUGH TEAR-DOWN-REQを受けとった通信制
御部７Ｍは、図４(17)で通知されたＶＣ−ＴＡＧを含む
図５(18)ＶＣ−ＴＡＧ消去開始ＲＥＱをＶＣ−ＴＡＧ管
理テーブル５Ｍに伝達する。図５ (18) を受けとったＶ
Ｃ−ＴＡＧ管理モジュール８Ｍは、ＶＣ−ＴＡＧ管理テ
ーブル５Ｍ中の該当カットスルーＶＣの状態を“解放
中”に変更し、(19)ＶＣ−ＴＡＧ消去開始ＲＥＳＰを通
信制御部７Ｍに返送する。
４(17)CUT-THROUGH TEAR-DOWN-REQを受けとった通信制
御部７Ｍは、図４(17)で通知されたＶＣ−ＴＡＧを含む
図５(18)ＶＣ−ＴＡＧ消去開始ＲＥＱをＶＣ−ＴＡＧ管
理テーブル５Ｍに伝達する。図５ (18) を受けとったＶ
Ｃ−ＴＡＧ管理モジュール８Ｍは、ＶＣ−ＴＡＧ管理テ
ーブル５Ｍ中の該当カットスルーＶＣの状態を“解放
中”に変更し、(19)ＶＣ−ＴＡＧ消去開始ＲＥＳＰを通
信制御部７Ｍに返送する。
【０１４９】以上の動作によってサーバ側のカットスル
ーＶＣの解放準備が整ったことになる。図２９（ステッ
プ２０）に示すように、図５ (19) のメッセージを受け
取った通信制御部７Ｍは図４(17) CUT-THROUGH TEAR-DO
WN-REQに対する応答として図４(20)CUT-THROUGH TEAR-D
OWN-RESPを通信制御部７Ｓに返送する。
ーＶＣの解放準備が整ったことになる。図２９（ステッ
プ２０）に示すように、図５ (19) のメッセージを受け
取った通信制御部７Ｍは図４(17) CUT-THROUGH TEAR-DO
WN-REQに対する応答として図４(20)CUT-THROUGH TEAR-D
OWN-RESPを通信制御部７Ｓに返送する。
【０１５０】図３０（ステップ２１）に示すように、図
４(20) CUT-THROUGH TEAR-DOWN-RESP を受けとった通信
制御部７ＳはカットスルーＶＣを実際に解放するために
解放すべきカットスルーＶＣのＶＣ−ＴＡＧを含んだ図
５(21)ＳＶＣ解放ＲＥＱをＡＴＭ−ＳＶＣ通信部１Ｓに
伝達する。
４(20) CUT-THROUGH TEAR-DOWN-RESP を受けとった通信
制御部７ＳはカットスルーＶＣを実際に解放するために
解放すべきカットスルーＶＣのＶＣ−ＴＡＧを含んだ図
５(21)ＳＶＣ解放ＲＥＱをＡＴＭ−ＳＶＣ通信部１Ｓに
伝達する。
【０１５１】図３１（ステップ２２）に示すように、図
５(21)ＳＶＣ解放ＲＥＱを受けとったＡＴＭ−ＳＶＣ通
信部１Ｓはサーバ側の手順と同様に、まず解放すべきカ
ットスルーＶＣのＶＣ−ＴＡＧを含んだ図５(22)ＶＣ−
ＴＡＧ消去開始ＲＥＱをＶＣ−ＴＡＧ管理モジュール８
Ｓに伝達する。
５(21)ＳＶＣ解放ＲＥＱを受けとったＡＴＭ−ＳＶＣ通
信部１Ｓはサーバ側の手順と同様に、まず解放すべきカ
ットスルーＶＣのＶＣ−ＴＡＧを含んだ図５(22)ＶＣ−
ＴＡＧ消去開始ＲＥＱをＶＣ−ＴＡＧ管理モジュール８
Ｓに伝達する。
【０１５２】図３２（ステップ２３）に示すように、図
５(22)ＶＣ−ＴＡＧ削除開始ＲＥＱを受け取ったＶＣ−
ＴＡＧ管理モジュール８Ｓは該当ＶＣ−ＴＡＧの状態を
“使用中”から“解放中”に変更して、解放すべきカッ
トスルーＶＣのCall Reference Valueを含んだ図５(23)
ＶＣ−ＴＡＧ消去開始ＲＥＳＰをＡＴＭ−ＳＶＣ通信部
１Ｓに返送する。
５(22)ＶＣ−ＴＡＧ削除開始ＲＥＱを受け取ったＶＣ−
ＴＡＧ管理モジュール８Ｓは該当ＶＣ−ＴＡＧの状態を
“使用中”から“解放中”に変更して、解放すべきカッ
トスルーＶＣのCall Reference Valueを含んだ図５(23)
ＶＣ−ＴＡＧ消去開始ＲＥＳＰをＡＴＭ−ＳＶＣ通信部
１Ｓに返送する。
【０１５３】図３３（ステップ２４−１）に示すよう
に、ＡＴＭ−ＳＶＣ通信部１Ｓは、図５(23)メッセージ
によって渡されたCall Reference Valueを用いてカット
スルーＶＣ解放のためのＲＥＬＥＡＳＥメッセージを生
成し、ＡＴＭ通信網５０に送出する。
に、ＡＴＭ−ＳＶＣ通信部１Ｓは、図５(23)メッセージ
によって渡されたCall Reference Valueを用いてカット
スルーＶＣ解放のためのＲＥＬＥＡＳＥメッセージを生
成し、ＡＴＭ通信網５０に送出する。
【０１５４】クライアントがＲＥＬＥＡＳＥメッセージ
をＡＴＭ通信網５０に送出したことにより、サーバにＡ
ＴＭ通信網５０からＲＥＬＥＡＳＥメッセージが到着す
ることになる。
をＡＴＭ通信網５０に送出したことにより、サーバにＡ
ＴＭ通信網５０からＲＥＬＥＡＳＥメッセージが到着す
ることになる。
【０１５５】図３４（ステップ２５）に示すように、サ
ーバ側のＡＴＭ−ＳＶＣ通信部１Ｍは、ＡＴＭ通信網５
０からＲＥＬＥＡＳＥメッセージを受信すると、受信し
たＲＥＬＥＡＳＥメッセージ中のCall Reference Value
を図５(25)ＶＣ−ＴＡＧ消去指示ＲＥＱに書き込んで、
図５(25)ＶＣ−ＴＡＧ消去指示ＲＥＱをＶＣ−ＴＡＧ管
理モジュール８Ｍに伝達する。
ーバ側のＡＴＭ−ＳＶＣ通信部１Ｍは、ＡＴＭ通信網５
０からＲＥＬＥＡＳＥメッセージを受信すると、受信し
たＲＥＬＥＡＳＥメッセージ中のCall Reference Value
を図５(25)ＶＣ−ＴＡＧ消去指示ＲＥＱに書き込んで、
図５(25)ＶＣ−ＴＡＧ消去指示ＲＥＱをＶＣ−ＴＡＧ管
理モジュール８Ｍに伝達する。
【０１５６】図３５（ステップ２６）に示すように、Ｖ
Ｃ−ＴＡＧ管理モジュール８Ｍは与えられたCall Refer
ence Valueから該当ＶＣ−ＴＡＧを検索し、該当ＶＣ−
ＴＡＧの情報を削除し、(26)ＶＣ−ＴＡＧ削除指示ＲＥ
ＳＰに“削除完了”と記して返送する。
Ｃ−ＴＡＧ管理モジュール８Ｍは与えられたCall Refer
ence Valueから該当ＶＣ−ＴＡＧを検索し、該当ＶＣ−
ＴＡＧの情報を削除し、(26)ＶＣ−ＴＡＧ削除指示ＲＥ
ＳＰに“削除完了”と記して返送する。
【０１５７】図３６（ステップ２７）に示すように、図
５(26)メッセージを受けとったＡＴＭ−ＳＶＣ通信部１
Ｍは、図５ (24)-2 ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥ
メッセージを作成してクライアント側のＡＴＭ−ＳＶＣ
通信部１Ｓに向かって送信する。
５(26)メッセージを受けとったＡＴＭ−ＳＶＣ通信部１
Ｍは、図５ (24)-2 ＲＥＬＥＡＳＥ ＣＯＭＰＬＥＴＥ
メッセージを作成してクライアント側のＡＴＭ−ＳＶＣ
通信部１Ｓに向かって送信する。
【０１５８】図３７〜図４０（ステップ２４−２、ステ
ップ２８、ステップ２９、ステップ３０）に示すよう
に、図５(24)のメッセージがクライアント側のＡＴＭ−
ＳＶＣ通信部１Ｓに到着した時点でＳＶＣの消去は完了
する。
ップ２８、ステップ２９、ステップ３０）に示すよう
に、図５(24)のメッセージがクライアント側のＡＴＭ−
ＳＶＣ通信部１Ｓに到着した時点でＳＶＣの消去は完了
する。
【０１５９】また、図３(7) 新規ＶＣ−ＴＡＧ割り当て
ＲＥＳＰを通知してから一定時間経過しても、そのカッ
トスルーＶＣについてのＶＣ−ＴＡＧ問い合わせＲＥＱ
を受信しないとき、ＶＣ−ＴＡＧ管理モジュール８Ｍは
ＶＣ−ＴＡＧ管理テーブル５Ｍ中のそのカットスルーＶ
Ｃに関するエントリを消去する。図４１は、図２６〜図
４０の手順を示すシーケンス図である。
ＲＥＳＰを通知してから一定時間経過しても、そのカッ
トスルーＶＣについてのＶＣ−ＴＡＧ問い合わせＲＥＱ
を受信しないとき、ＶＣ−ＴＡＧ管理モジュール８Ｍは
ＶＣ−ＴＡＧ管理テーブル５Ｍ中のそのカットスルーＶ
Ｃに関するエントリを消去する。図４１は、図２６〜図
４０の手順を示すシーケンス図である。
【０１６０】以上に述べた本発明により拡張したクライ
アントおよびサーバは以下の利点を持つ。
アントおよびサーバは以下の利点を持つ。
【０１６１】１．本発明による拡張に対応していない装
置とは従来の手順により情報の転送を行うこととし、従
来のクライアント、サーバとの相互接続性を完全に確保
している。
置とは従来の手順により情報の転送を行うこととし、従
来のクライアント、サーバとの相互接続性を完全に確保
している。
【０１６２】２．双方の通信端末１０および２０が本拡
張に対応してさえいれば、カットスルーＶＣを生成する
ことができる。これにより、ＮＨＲＰを用いてカットス
ルーＶＣを生成する方式で発生する「ＩＰ通信経路上の
ルータがＮＨＲＰ機能を持たないとカットスルーＶＣが
生成できない」という問題は発生しない。
張に対応してさえいれば、カットスルーＶＣを生成する
ことができる。これにより、ＮＨＲＰを用いてカットス
ルーＶＣを生成する方式で発生する「ＩＰ通信経路上の
ルータがＮＨＲＰ機能を持たないとカットスルーＶＣが
生成できない」という問題は発生しない。
【０１６３】３．大量の情報を配信する必要がある時の
みカットスルーＶＣを生成する事ができる。
みカットスルーＶＣを生成する事ができる。
【０１６４】４．事前のＩＰ通信でカットスルーＶＣ生
成の申し合わせを行い、申し合わされたカットスルーＶ
Ｃのみを着呼することが可能であり、カットスルーＶＣ
生成の申し合わせを行う際に利用者の認証を行うことと
して、あらかじめ認証が行われた利用者とのみカットス
ルーＶＣを生成することを可能にしている。ＮＨＲＰで
カットスルーＶＣを生成する方式では事前にカットスル
ーＶＣの生成を申し合わせることができない。このため
カットスルーＶＣを着呼する際に、カットスルーＶＣに
より接続される相手を認識して呼の受付判断を行うこと
ができない。
成の申し合わせを行い、申し合わされたカットスルーＶ
Ｃのみを着呼することが可能であり、カットスルーＶＣ
生成の申し合わせを行う際に利用者の認証を行うことと
して、あらかじめ認証が行われた利用者とのみカットス
ルーＶＣを生成することを可能にしている。ＮＨＲＰで
カットスルーＶＣを生成する方式では事前にカットスル
ーＶＣの生成を申し合わせることができない。このため
カットスルーＶＣを着呼する際に、カットスルーＶＣに
より接続される相手を認識して呼の受付判断を行うこと
ができない。
【０１６５】５．上記の通りカットスルーＶＣにより接
続される相手を認識した上でカットスルーＶＣの受付判
断を行うことが可能になるので、ＦｉｒｅＷａｌｌをま
たがってカットスルーＶＣを生成することが可能とな
り、ＦｉｒｅＷａｌｌに対する負荷集中を回避できる。
続される相手を認識した上でカットスルーＶＣの受付判
断を行うことが可能になるので、ＦｉｒｅＷａｌｌをま
たがってカットスルーＶＣを生成することが可能とな
り、ＦｉｒｅＷａｌｌに対する負荷集中を回避できる。
【０１６６】（本発明により拡張したクライアント機能
をＨＴＴＰプロキシに実装する実施例）図４２は上記の
クライアント機能をＨＴＴＰプロキシに実装した実施例
である。ＨＴＴＰプロキシとサーバとの通信手順は上記
と同じである。この形態ではＨＴＴＰプロキシと本発明
により拡張したサーバとの間で本発明によるＩＰ−ＡＴ
Ｍハイブリッド通信網による情報転送が行われる。この
形態ではＦＷに負荷が集中するという点は従来どおりで
あるが、従来のＮＨＲＰを用いてカットスルーＶＣを生
成する方式と比較すると、途中経路上のルータがＮＨＲ
Ｐ機能を提供しないと装置間のＡＴＭアドレスの交換が
行えないという問題点が解決される。またＡＴＭ通信機
能を持たない通信端末もプロキシサーバを経由してＡＴ
Ｍによる高速情報転送を利用することを実現している。
をＨＴＴＰプロキシに実装する実施例）図４２は上記の
クライアント機能をＨＴＴＰプロキシに実装した実施例
である。ＨＴＴＰプロキシとサーバとの通信手順は上記
と同じである。この形態ではＨＴＴＰプロキシと本発明
により拡張したサーバとの間で本発明によるＩＰ−ＡＴ
Ｍハイブリッド通信網による情報転送が行われる。この
形態ではＦＷに負荷が集中するという点は従来どおりで
あるが、従来のＮＨＲＰを用いてカットスルーＶＣを生
成する方式と比較すると、途中経路上のルータがＮＨＲ
Ｐ機能を提供しないと装置間のＡＴＭアドレスの交換が
行えないという問題点が解決される。またＡＴＭ通信機
能を持たない通信端末もプロキシサーバを経由してＡＴ
Ｍによる高速情報転送を利用することを実現している。
【０１６７】またパスワードを用いた実施例において
は、サーバ側のＶＣ−ＴＡＧ管理テーブル５Ｍが新規セ
ッションID割り当てＲＥＱ受信後、ステップ６において
ＶＣ−ＴＡＧの選択と同時にパスワードを生成し、生成
されたパスワードをＶＣ−ＴＡＧ管理テーブル５Ｍに記
憶し、通信制御部７Ｍが通信制御部７Ｓに送る図２(8)
ＳＥＴＵＰ−ＲＥＳＰに生成されたパスワードを含め
る。そして通信制御部７Ｓは、図３(10)ＳＥＴＵＰメッ
セージを送出する際にＳＥＴＵＰ−ＲＥＳＰで通知され
たパスワードをUser-to-User IE とよばれる情報要素に
記入する。そしてＳＥＴＵＰ−ＲＥＳＰを受信したサー
バはＳＥＴＵＰ−ＲＥＳＰ中のパスワードをＶＣ−ＴＡ
Ｇ管理テーブル５Ｍ中のパスワードと照合する。
は、サーバ側のＶＣ−ＴＡＧ管理テーブル５Ｍが新規セ
ッションID割り当てＲＥＱ受信後、ステップ６において
ＶＣ−ＴＡＧの選択と同時にパスワードを生成し、生成
されたパスワードをＶＣ−ＴＡＧ管理テーブル５Ｍに記
憶し、通信制御部７Ｍが通信制御部７Ｓに送る図２(8)
ＳＥＴＵＰ−ＲＥＳＰに生成されたパスワードを含め
る。そして通信制御部７Ｓは、図３(10)ＳＥＴＵＰメッ
セージを送出する際にＳＥＴＵＰ−ＲＥＳＰで通知され
たパスワードをUser-to-User IE とよばれる情報要素に
記入する。そしてＳＥＴＵＰ−ＲＥＳＰを受信したサー
バはＳＥＴＵＰ−ＲＥＳＰ中のパスワードをＶＣ−ＴＡ
Ｇ管理テーブル５Ｍ中のパスワードと照合する。
【０１６８】また、公開暗号方式を用いた別の実施例で
は、パスワードを図２(8) ＳＥＴＵＰ−ＲＥＳＰで通知
する際にクライアントの公開暗号鍵によりパスワードを
暗号化する。また、公開暗号方式を用いた別の実施例で
は、パスワードを図３(10)ＳＥＴＵＰメッセージに含め
る際にパスワードを暗号化し、サーバが受信したパスワ
ードをクライアントの公開復号鍵により復号する。
は、パスワードを図２(8) ＳＥＴＵＰ−ＲＥＳＰで通知
する際にクライアントの公開暗号鍵によりパスワードを
暗号化する。また、公開暗号方式を用いた別の実施例で
は、パスワードを図３(10)ＳＥＴＵＰメッセージに含め
る際にパスワードを暗号化し、サーバが受信したパスワ
ードをクライアントの公開復号鍵により復号する。
【０１６９】また、本発明による別の実施例ではクライ
アントが図３(10)のＳＥＴＵＰメッセージを送る際ＳＥ
ＴＵＰメッセージ中のＡＴＭ Traffic Descriptor 情報
要素のForward方向（発呼側から着呼側の方向）のCellR
ateを０と指定する。
アントが図３(10)のＳＥＴＵＰメッセージを送る際ＳＥ
ＴＵＰメッセージ中のＡＴＭ Traffic Descriptor 情報
要素のForward方向（発呼側から着呼側の方向）のCellR
ateを０と指定する。
【０１７０】
【発明の効果】以上説明したように、本発明によれば、
従来のＡＴＭ通信能力を持たないＩＰ通信端末とも相互
接続性を確保しながら、可能な場合に限りカットスルー
ＶＣを生成し、ＡＴＭによる高速情報転送を行う通信ア
プリケーションを実現できる。またあらかじめ生成を申
し合わせたカットスルーＶＣのみを着呼でき、カットス
ルーＶＣ生成後も不正なアプリケーションが実行される
ことを防止でき、システムの安全性を確保できる。
従来のＡＴＭ通信能力を持たないＩＰ通信端末とも相互
接続性を確保しながら、可能な場合に限りカットスルー
ＶＣを生成し、ＡＴＭによる高速情報転送を行う通信ア
プリケーションを実現できる。またあらかじめ生成を申
し合わせたカットスルーＶＣのみを着呼でき、カットス
ルーＶＣ生成後も不正なアプリケーションが実行される
ことを防止でき、システムの安全性を確保できる。
【０１７１】またＦｉｒｅＷａｌｌをまたがったカット
スルーＶＣの生成が可能になり、ＦｉｒｅＷａｌｌに対
する負荷集中を回避できる。また、大量の情報を転送す
る場合など必要な場合のみカットスルーＶＣを生成し、
転送情報量の少ない通信のためにカットスルーＶＣが生
成され、通信の効率が低下するのを防ぐことができる。
また、通信端末の能力、網環境に応じて達成可能な実効
通信速度を推測してカットスルーＶＣの帯域を設定する
ことが可能になる。また経路上のルータがＮＨＲＰ機能
を提供しない場合においてもカットスルーＶＣによる通
信が可能になる。
スルーＶＣの生成が可能になり、ＦｉｒｅＷａｌｌに対
する負荷集中を回避できる。また、大量の情報を転送す
る場合など必要な場合のみカットスルーＶＣを生成し、
転送情報量の少ない通信のためにカットスルーＶＣが生
成され、通信の効率が低下するのを防ぐことができる。
また、通信端末の能力、網環境に応じて達成可能な実効
通信速度を推測してカットスルーＶＣの帯域を設定する
ことが可能になる。また経路上のルータがＮＨＲＰ機能
を提供しない場合においてもカットスルーＶＣによる通
信が可能になる。
【図１】本発明実施例の全体構成および通信端末の要部
ブロック構成を示す図。
ブロック構成を示す図。
【図２】メッセージフォーマットを示す図。
【図３】メッセージフォーマットを示す図。
【図４】メッセージフォーマットを示す図。
【図５】メッセージフォーマットを示す図。
【図６】ステップ１のフローチャート。
【図７】ステップ２のフローチャート。
【図８】ステップ３のフローチャート。
【図９】ステップ４のフローチャート。
【図１０】ステップ５のフローチャート。
【図１１】ステップ６のフローチャート。
【図１２】ステップ７のフローチャート。
【図１３】ステップ８のフローチャート。
【図１４】ステップ９のフローチャート。
【図１５】ステップ１０−１のフローチャート。
【図１６】ステップ１１のフローチャート。
【図１７】ステップ１２のフローチャート。
【図１８】ステップ１３のフローチャート。
【図１９】ステップ１０−２のフローチャート。
【図２０】ステップ１４のフローチャート。
【図２１】ステップ１５のフローチャート。
【図２２】ステップ１６のフローチャート。
【図２３】図６〜図２２の手順を示すシーケンス図。
【図２４】カットスルーＶＣを用いたＨＴＴＰメッセー
ジのやりとりの手順を説明するための図。
ジのやりとりの手順を説明するための図。
【図２５】カットスルーＶＣを用いたＨＴＴＰメッセー
ジのやりとりの手順を説明するための図。
ジのやりとりの手順を説明するための図。
【図２６】ステップ１７のフローチャート。
【図２７】ステップ１８のフローチャート。
【図２８】ステップ１９のフローチャート。
【図２９】ステップ２０のフローチャート。
【図３０】ステップ２１のフローチャート。
【図３１】ステップ２２のフローチャート。
【図３２】ステップ２３のフローチャート。
【図３３】ステップ２４−１のフローチャート。
【図３４】ステップ２５のフローチャート。
【図３５】ステップ２６のフローチャート。
【図３６】ステップ２７のフローチャート。
【図３７】ステップ２４−２のフローチャート。
【図３８】ステップ２８のフローチャート。
【図３９】ステップ２９のフローチャート。
【図４０】ステップ３０のフローチャート。
【図４１】図２６〜図４０の手順を示すシーケンス図。
【図４２】クライアント機能をＨＴＴＰプロキシに実装
した実施例を示す図。
した実施例を示す図。
【図４３】ＩＰインタフェースを説明するための図。
【図４４】ＮＨＲＰを用いたＡＴＭ−ＳＶＣ生成を説明
するための図。
するための図。
【図４５】ＦｉｒｅＷａｌｌの原理を説明するための
図。
図。
【図４６】問題点（問題３．）を説明するための図。
【図４７】ＮＨＲＰの問題点（問題４．）を説明するた
めの図。
めの図。
【図４８】問題点（問題５．）を説明するための図。
【図４９】問題点（問題６．）を示す図。
【図５０】問題点（負荷集中）を示す図。
１Ｍ、１Ｓ ＡＴＭ−ＳＶＣ通信部 ２Ｍ、２Ｓ ＩＰ通信部 ３ 通信条件提示部 ４ 通信条件確認部 ５Ｍ、５Ｓ ＶＣ−ＴＡＧ管理テーブル ６ ＶＣ−ＴＡＧ割当て部 ７Ｍ、７Ｓ 通信制御部 ８Ｍ、８Ｓ ＶＣ−ＴＡＧ管理モジュール １０、２０ 通信端末 ５０ ＡＴＭ通信網 ７０ ＩＰルーチング網
Claims (19)
- 【請求項１】 ＩＰ通信を行う手段およびＡＴＭ通信を
行う手段を共に備え、 通信を行う相手装置とＩＰ通信を実行することによりこ
の相手装置との間にＡＴＭ論理回線を設定することおよ
び回線の設定条件の申し合わせを行う手段と、この申し
合わせにしたがって前記相手装置との間にＡＴＭ論理回
線を設定する手段とを備え、 さらに相手装置との間にＡＴＭ論理回線を設定して行う
通信について当該ＡＴＭ論理回線が前記設定条件の申し
合わせを事前に行ったものか否かを判別する手段と、こ
の判別結果が否であれば当該通信の実行を拒否する手段
とを備えたことを特徴とする通信装置。 - 【請求項２】 前記ＡＴＭ論理回線の設定の申し合わせ
について、ＡＴＭ論理回線設定の条件を提示する側の通
信装置を主端末としもう一方の通信装置を従端末とする
とき、前記申し合わせにもとづくＡＴＭ論理回線の設定
要求をこの従端末がＡＴＭ通信網に対して行う手段を備
えた請求項１記載の通信装置。 - 【請求項３】 前記申し合わせを行う手段は、ＡＴＭ論
理回線を前記端末間に設定して行う通信が可能であるか
否かを確認する手段を含み、 その通信が可能でないときにはＩＰ通信によりデータ転
送を実行する手段を備えた請求項１記載の通信装置。 - 【請求項４】 前記設定条件は、ＡＴＭ論理回線上で実
行可能とするアプリケーション、通信条件、識別子およ
びＡＴＭアドレスを含む請求項１記載の通信装置。 - 【請求項５】 前記通信条件は、主端末が達成可能な最
大通信速度を含む請求項２記載の通信装置。 - 【請求項６】 前記申し合わせにもとづき設定された相
手端末との間のＡＴＭ論理回線上で実行を許可するアプ
リケーションを限定し、許可されていないアプリケーシ
ョンの実行を不可能にする手段を備えた請求項４記載の
通信装置。 - 【請求項７】 前記ＡＴＭ論理回線が通信を行う相手端
末との間に設定された後に、このＡＴＭ論理回線を用い
たＩＰ通信を行うことを不可能にする手段を含む請求項
６記載の通信装置。 - 【請求項８】 前記ＡＴＭ論理回線が事前に申し合わさ
れたものか否かの判別の結果として事前に申し合わされ
ていないＡＴＭ論理回線を用いた通信の実行要求を検出
したときには、この旨をネットワーク上の監視手段に通
知する手段を含む請求項１記載の通信装置。 - 【請求項９】 データ転送の完了から所定時間経過後に
当該データ転送に用いたＡＴＭ論理回線を自動的に切断
する手段を含む請求項１記載の通信装置。 - 【請求項１０】 前記申し合わせが行われてから所定時
間後にＡＴＭ論理回線の設定が行われないときには前記
申し合わせた設定条件を消去する手段を備えた請求項１
記載の通信装置。 - 【請求項１１】 相手端末の正当性をパスワードにより
確認する手段を備えた請求項２記載の通信装置。 - 【請求項１２】 データ転送の開始毎に、相手端末の正
当性をパスワードにより確認する手段を含む請求項１１
記載の通信装置。 - 【請求項１３】 パスワードを暗号化する手段と、暗号
化されたパスワードを復号化する手段とを備えた請求項
１１記載の通信装置。 - 【請求項１４】 前記暗号化する手段は、当該パスワー
ドの送信先の端末に固有な公開鍵を用いて当該パスワー
ドを暗号化する手段を含む請求項１３記載の通信装置。 - 【請求項１５】 主端末が情報を配信するサーバであ
り、従端末が情報を取得するクライアントである請求項
２ないし１４のいずれかに記載の通信装置。 - 【請求項１６】 前記サーバは、ＡＴＭ通信を開始する
ときにクライアントに対してクライアントからサーバへ
の通信帯域を“０”とする手段を含む請求項１５記載の
通信装置。 - 【請求項１７】 前記申し合わせにより決定された設定
条件のうち一部の当該設定条件の要素をＡＴＭ通信網に
対するＡＴＭ論理回線の設定要求メッセージに記入する
手段を備えた請求項４記載の通信装置。 - 【請求項１８】 前記一部の当該設定条件の要素は、Ａ
ＴＭ論理回線に対する識別子およびまたはパスワードで
ある請求項１７記載の通信装置。 - 【請求項１９】 ＡＴＭシグナリング手順により設定さ
れたコネクション上でセルを送受することにより通信を
行うＡＴＭ通信網と、インターネットプロトコルに基づ
くＩＰパケットを順次中継することにより通信を行うＩ
Ｐルーチング網と、これら二つの通信網に接続される複
数の通信端末とを備えたＩＰ−ＡＴＭハイブリッド通信
網において、 前記通信端末は、前記ＩＰルーチング網を介する通信に
より前記ＡＴＭ通信網を介してデータ転送を行うことを
申合せる手段と、この申合せにしたがってＡＴＭ論理回
線によりデータ転送を行うとともに前記ＩＰ通信により
申合わせた条件以外のＡＴＭ論理回線の通信を拒否する
手段とを備えたことを特徴とするＩＰ−ＡＴＭハイブリ
ッド通信網。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP4387198A JPH11243394A (ja) | 1998-02-25 | 1998-02-25 | Ｉｐ−ａｔｍハイブリッド通信装置および通信網 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP4387198A JPH11243394A (ja) | 1998-02-25 | 1998-02-25 | Ｉｐ−ａｔｍハイブリッド通信装置および通信網 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH11243394A true JPH11243394A (ja) | 1999-09-07 |
Family
ID=12675773
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP4387198A Pending JPH11243394A (ja) | 1998-02-25 | 1998-02-25 | Ｉｐ−ａｔｍハイブリッド通信装置および通信網 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH11243394A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6847488B1 (ja) * | 2020-05-14 | 2021-03-24 | 甲賀電子株式会社 | Ｉｐ通信における認証方法 |
-
1998
- 1998-02-25 JP JP4387198A patent/JPH11243394A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6847488B1 (ja) * | 2020-05-14 | 2021-03-24 | 甲賀電子株式会社 | Ｉｐ通信における認証方法 |
| WO2021229749A1 (ja) * | 2020-05-14 | 2021-11-18 | 甲賀電子株式会社 | Ｉｐ通信における認証方法および認証システム |
| US11882114B2 (en) | 2020-05-14 | 2024-01-23 | Koga Electronics Co., Ltd. | Authentication method and authentication system in IP communication |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11165604B2 (en) | Method and system used by terminal to connect to virtual private network, and related device | |
| US8190899B1 (en) | System and method for establishing a remote connection over a network with a personal security device connected to a local client without using a local APDU interface or local cryptography | |
| US6101543A (en) | Pseudo network adapter for frame capture, encapsulation and encryption | |
| US8364772B1 (en) | System, device and method for dynamically securing instant messages | |
| US6996716B1 (en) | Dual-tier security architecture for inter-domain environments | |
| EP1316177B1 (en) | Multiservice use of network connection capability under user-to-network interface signaling | |
| EP1413094B1 (en) | Distributed server functionality for emulated lan | |
| US20180270660A1 (en) | Method and system for peer-to-peer enforcement | |
| EP0776112A2 (en) | Secure network protocol system and method | |
| EP1374533B1 (en) | Facilitating legal interception of ip connections | |
| CN1647451B (zh) | 用于在网络环境中监视信息的装置、方法和系统 | |
| JP3591753B2 (ja) | ファイアウォール方式およびその方法 | |
| US8386783B2 (en) | Communication apparatus and communication method | |
| US7694015B2 (en) | Connection control system, connection control equipment and connection management equipment | |
| US7363486B2 (en) | Method and system for authentication through a communications pipe | |
| WO2023174143A1 (zh) | 数据传输方法、设备、介质及产品 | |
| Deng et al. | Securing data transfer in asynchronous transfer mode networks | |
| JP2001036561A (ja) | Ｔｃｐ／ｉｐネットワークシステム | |
| US7895648B1 (en) | Reliably continuing a secure connection when the address of a machine at one end of the connection changes | |
| JPH1141280A (ja) | 通信システム、ｖｐｎ中継装置、記録媒体 | |
| US20030154408A1 (en) | Method and apparatus for secured unified public communication network based on IP and common channel signaling | |
| JPH11243394A (ja) | Ｉｐ−ａｔｍハイブリッド通信装置および通信網 | |
| JP2001237824A (ja) | 情報通信中継装置 | |
| JP2004240819A (ja) | 認証機能付きパケット通信装置、ネットワーク認証アクセス制御サーバ、アプリケーション認証アクセス制御サーバ、および分散型認証アクセス制御システム | |
| JPH1132088A (ja) | ネットワークシステム |