JP3591753B2 - ファイアウォール方式およびその方法 - Google Patents
ファイアウォール方式およびその方法 Download PDFInfo
- Publication number
- JP3591753B2 JP3591753B2 JP01702797A JP1702797A JP3591753B2 JP 3591753 B2 JP3591753 B2 JP 3591753B2 JP 01702797 A JP01702797 A JP 01702797A JP 1702797 A JP1702797 A JP 1702797A JP 3591753 B2 JP3591753 B2 JP 3591753B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- access
- connection
- protocol
- firewall
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/166—IP fragmentation; TCP segmentation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
- H04L2012/5667—IP over ATM
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5687—Security aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ファイアウォールに係わり、特に、ＩＰ ｏｖｅｒ ＡＴＭ プロトコルを使用する通信におけるファイアウォールに関する。
【０００２】
【従来の技術】
近年、急速に普及してきているインターネットは、その標準プロトコルとしてＴＣＰ／ＩＰを採用しているが、ＴＣＰ／ＩＰプロトコルに従った通信をＡＴＭ ネットワーク上で実現するシステムが検討されている。このようなシステムは、ＩＰ ｏｖｅｒ ＡＴＭ と呼ばれている。この技術が確立されれば、たとえば、ＡＴＭ ネットワークを利用したインターネットを実現できる。
【０００３】
ところで、インターネットの普及に伴い、コンピュータ等の端末を公衆網に接続する機会が増えてきているが、このような状況では、公衆網側からの不正なアクセスから端末（端末が格納する情報）を守る技術が重要である。この場合、特定種類のトラフィックを遮断する機能が必要になる。特定種類のトラフィックを遮断することによってコンピュータ等のセキュリティを向上させる機能、またはその機能を実現する装置はファイアウォールと呼ばれている。
【０００４】
図３３は、上述したＩＰ ｏｖｅｒ ＡＴＭ においてファイアウォールを設ける例を示す図である。図３３に示す例では、端末（ＤＴＥ： Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）１０２、１０７は、ＴＣＰ／ＩＰプロトコルに従った通信を行うことができ、ＡＴＭ ネットワーク１０１に収容されている。ＬＡＮ１０３は、ＴＣＰ／ＩＰプロトコルを利用したイーサネットであり、ルータ１０５を介してＡＴＭ ネットワーク１０１に接続される。ルータ１０５は、ファイアウォール機能を有し、ＡＴＭ ネットワーク１０１からＬＡＮ１０３へのアクセスを選択的に許可する。
【０００５】
上記システムにおいて、端末１０２から端末１０７へＴＣＰ／ＩＰプロトコルでアクセスする場合には、まず、端末１０２から端末１０７間にＡＴＭ コネクションを確立し、そのＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションを確立して通信を行う。
【０００６】
端末１０２からＴＣＰ／ＩＰプロトコルによる通信でＬＡＮ１０４内に設けられた端末１０４へアクセスする場合は、まず、端末１０２とルータ１０５との間にＡＴＭ コネクションを確立する。そして、端末１０２は、そのＡＴＭ コネクションを介して端末１０４へのアクセス要求をルータ１０５へ転送する。ルータ１０５は、アクセス要求を受け取ると、ＩＰアドレスやＴＣＰ のポート番号などに従ってそのアクセス要求を許容するか否かを判断する。アクセス要求を許容する場合には、ルータ１０５は、端末１０２とルータ１０５との間に確立したＡＴＭ コネクションを利用して端末１０２と端末１０４との間にＴＣＰ／ＩＰコネクションを確立し、ＴＣＰ／ＩＰプロトコルによる通信が開始される。一方、アクセス要求を許容しない場合には、ルータ１０５は、端末１０２とルータ１０５との間に確立したＡＴＭ コネクションパケットを切断する。
【０００７】
このように、従来のシステムでは、ルータ１０５にファイアウォール機能を設け、ＡＴＭ ネットワーク１０１からＬＡＮ１０３へのアクセスを選択的に許可することによって、ＬＡＮ１０３内の資源への不正アクセスを防いでいた。
【０００８】
【発明が解決しようとする課題】
上述のように、ＩＰ ｏｖｅｒ ＡＴＭ システムにおいてＴＣＰ／ＩＰプロトコルレベルでアクセス要求を許容するか否かを判断するためには、許容されるであろうアクセス要求（許容アクセス）であっても、拒絶されるであろうアクセス要求（非許容アクセス）であっても、必ずいったんＡＴＭ コネクションが確立される。図３３に示す例では、端末１０２とルータ１０５との間にＡＴＭ コネクションが確立される。
【０００９】
ＡＴＭ ネットワーク１０１は、通常、ＡＴＭ コネクションが確立されるとその呼に対して課金する。したがって、たとえば、端末１０２から端末１０４へのアクセス要求がルータ１０５によって規制される（拒絶される）場合であっても、端末１０２とルータ１０５との間にいったんＡＴＭ コネクションが確立されるので、端末１０２は、サービスを受けられないにも係わらず課金されてしまう。
【００１０】
また、上述のように、非許容アクセスであっても、いったんＡＴＭ コネクションが確立されるので、網リソースが無駄使いされてしまう。たとえば、端末１０２から端末１０４へのアクセス要求が非許容アクセスであった場合でも、端末１０２とルータ１０５との間にはＡＴＭ コネクションが確立され、ＡＴＭ ネットワーク１０１とルータ１０５との間を接続する回線１０６の帯域がそのＡＴＭ コネクションに割り当てられてしまう。この場合、非許容アクセスによって回線１０６の使用可能帯域が小さくなってしまう。回線１０６の使用可能帯域が不足すると、回線１０６上にＡＴＭ コネクションを確立できなくなるので、許容アクセスであってもＬＡＮ１０３内へのアクセスができなくなってしまう。このように、非許容アクセスによって許容アクセスが妨害されてしまう恐れがある。
【００１１】
なお、上記問題は、ＩＰ ｏｖｅｒ ＡＴＭ のみに起因するものではなく、イーサネットやトークンリング等のＬＡＮ 上で転送されるデータをＡＴＭ ネットワークを介して転送するシステム（ＬＡＮ エミュレーションと呼ばれることがある）においても発生する。
【００１２】
本発明の課題は、網リソースを有効に利用できるファイアウォールを構築することである。
【００１３】
【課題を解決するための手段】
図１は、本発明の原理図である。本発明のファイアウォール方式は、第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワーク３を介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制する。
【００１４】
交換ノード１は、例えば、ネットワーク３の交換機であり、固定長パケットを交換するとともに、受信した固定長パケットのなかから上記第２のプロトコルによる第１の端末から第２の端末へのアクセス要求を含んだ固定長パケットを抽出する。
【００１５】
エージェントユニット２は、ネットワーク３内に設けられ、交換ノード１によって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断し、アクセスを許容する場合にのみ、上記第１の端末またはその第１の端末を収容する端末と上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立する。第１または第２の端末を収容する端末とは、たとえば、ルータ装置である。
【００１６】
上記構成によれば、交換ノードと第２の端末（またはその第２の端末を収容する端末装置）との間にコネクションを確立することなく第２の端末へのアクセスを許容するか否かを判断できる。すなわち、この判断のためにネットワーク３と第２の端末（またはその第２の端末を収容する端末装置）とを接続する回線の資源（帯域）を使うことはない。
【００１７】
本発明の他の態様のファイアウォール方式は、第１の端末と第２の端末との間に上記第１のプロトコルによるコネクションが確立されている状況において、そのコネクションを介して他のサービスを要求する場合を前提とする。
【００１８】
交換ノード１は、第２のプロトコルによる第１の端末から第２の端末へのアクセスのために上記コネクションの帯域変更を要求する情報を含んだ固定長パケットを抽出する。
【００１９】
エージェントユニット２は、ネットワーク３内に設けられ、交換ノード１によって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断し、その要求を許容する場合にのみ上記コネクションの帯域を変更する。
【００２０】
上記構成によれば、第２のプロトコルによるアクセスが許容されない場合には上記コネクションの帯域が変更されないので、ネットワーク資源（帯域）の無駄使いをを防ぐことができる。
【００２１】
【発明の実施の形態】
以下、本発明の実施形態について図面を参照しながら説明する。
図２は、本実施形態の全体システム構成図である。以下では、ＩＰ ｏｖｅｒ ＡＴＭ システムを前提に説明する。ＩＰ ｏｖｅｒ ＡＴＭ システムでは、各端末はＩＰプロトコルに従った通信を行うが、ここでは、一例として、ＴＣＰ／ＩＰプロトコルに従った通信を行い、ＡＴＭ ネットワーク内では、ＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションが確立されるものとする。本実施形態では、ＡＴＭ ネットワーク内にファイアウォールを設け、そのファイアウォールにおいてＴＣＰ／ＩＰコネクションを確立することを許可するか否かを判断する。そして、ＴＣＰ／ＩＰコネクションの確立を許容する通信に対してのみ、着信端末との間にＡＴＭ コネクションを確立する。
【００２２】
ＡＴＭ ネットワーク１１は、交換ノード（Ａ） １２および交換ノード（Ｂ） １３を有する。交換ノード（Ａ） １２および交換ノード（Ｂ） １３は、それぞれＡＴＭ 交換機であり、ＡＴＭ セルをそのヘッダに設定されているルーティング情報（ＶＰＩ／ＶＣＩ ）に基づいてルーティングする。また、交換ノード（Ａ） １２および交換ノード（Ｂ） １３は、それぞれエージェント（Ａ） １４およびエージェント（Ｂ） １５を有する。エージェント（Ａ） １４およびエージェント（Ｂ） １５は、仮想端末であり、それぞれＡＴＭ アドレスとして”ＤＴＥｘａ” および”ＤＴＥｘｂ” が割り当てられている。エージェント（Ａ） １４およびエージェント（Ｂ） １５は、ファイアウォール機能を有し、従来のシステムではルータ装置が行っていたＴＣＰ コネクションまたはＩＰコネクションによるアクセス規制をルータ装置に代わって行う。
【００２３】
交換ノード（Ａ） １２は端末（Ａ） １６を収容し、交換ノード（Ｂ） １３は端末（Ｂ） １７を収容する。端末（Ａ） １６および端末（Ｂ） １７は、それぞれＴＣＰ／ＩＰ端末であり、ＴＣＰ／ＩＰプロトコルに従って通信を行う。また、端末（Ａ） １６および端末（Ｂ） １７は、それぞれ、たとえば、ＤＴＥ（Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ ）である。端末（Ａ） １６および端末（Ｂ） １７は、ＡＴＭ 対応端末であり、データをＡＴＭ ネットワークに出力する際にそのデータをＡＴＭ セルに格納する機能、およびＡＴＭ ネットワークから受信したＡＴＭ セルから必用な情報を取り出す機能を有している。なお、非ＡＴＭ 対応端末１８をＡＴＭ ネットワーク１１に接続する場合は、セル分解組立機能を有したＴＡ（Ｔｅｒｍｉｎａｌ Ａｄａｐｔｏｒ）１９およびＤＳＵ（Ｄａｔａ Ｓｅｒｖｉｃｅ Ｕｎｉｔ ）２０を用いる。端末（Ａ） １６に対しては、ＡＴＭ アドレスとして”ＤＴＥａ”が割り当てられ、ＩＰアドレスとして”１３３．１６２．９６．ａ”が割り当てられている。また、端末（Ｂ） １７に対しては、ＡＴＭ アドレスとして”ＤＴＥｂ”が割り当てられ、ＩＰアドレスとして”１３３．１６２．９６．ｂ”が割り当てられている。
【００２４】
上記システムにおいて、端末（Ａ） １６と端末（Ｂ） １７との間でＴＣＰ／ＩＰプロトコルに従った通信を行う場合には、図３に示すように、送信側において、ＴＣＰ／ＩＰパケットを複数の固定長データに分解してそれらの固定長データをそれぞれＡＴＭ セルの情報フィールドに格納し、ＡＴＭ ネットワーク１１を介して転送する。受信側では、ＡＴＭ セルの情報フィールドから取り出したデータからＴＣＰ／ＩＰパケットを再生する。
【００２５】
図４は、ＡＴＭ セルの構成図であり、（ａ） は、ＵＮＩ （Ｕｓｅｒ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）におけるフォーマット、（ｂ） は、ＮＮＩ （Ｎｅｔｗｏｒｋ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ） におけるフォーマットである。ＡＴＭ セルは、５３バイトの固定長パケットであり、５バイトのヘッダと４８バイトの情報フィールドとから構成される。
【００２６】
ＵＮＩ におけるＡＴＭ セルは、図４（ａ） に示すように、８ビットのＶＰＩ （仮想パス識別子）と１６ビットのＶＣＩ （仮想チャネル識別子）を有する。ＶＰＩ／ＶＣＩ は、ルーティング情報である。ＧＦＣ （一般フロー制御）は、セル同士の衝突を防ぐために使用される情報である。ＰＴ（ペイロードタイプ）は、情報フィールドに格納される情報の種類（ユーザ情報、制御情報．．．）を示す。ＣＬＰ （セル損失優先表示）は、セルの優先度を表示する。ＨＥＣ （ヘッダ誤り制御）は、ヘッダ部分の誤り検出とセル同期に使われる。
【００２７】
ＮＮＩ におけるＡＴＭ セルは、図４（ｂ） に示すように、１２ビットのＶＰＩ および１６ビットのＶＣＩ を有する。ＰＴ、ＣＬＰ 、ＨＥＣ は、ＵＮＩ におけるＡＴＭ セルについて説明したものと同じである。
【００２８】
図５は、本実施形態のファイアウォールシステムの構成図である。図５において、交換ノード３０は、図２の交換ノード（Ａ） １２または交換ノード（Ｂ） １３であり、エージェント３４は、エージェント（Ａ） １４またはエージェント（Ｂ） １５である。
【００２９】
ＡＴＭ スイッチ３１は、複数の入力線および複数の出力線を収容し、ＡＴＭ セルを自律的に交換する。
呼管理制御部３２は、ＡＴＭ コネクションを管理・制御する。呼管理制御部３２は、呼の設定時に発呼要求メッセージを取り込んで解析し、呼管理テーブル３３を設定する。また、呼管理制御部３２は、ＡＴＭ コネクションの切断や、ＡＴＭ コネクションの使用帯域の変更など、呼管理処理を行う。
【００３０】
呼管理テーブル３３は、ＡＴＭ コネクション毎に、発呼端末のアドレス、着呼端末のアドレス、当該ＡＴＭ コネクションを介して転送されるデータセル（アイドルセルを含まない）のＶＰＩ／ＶＣＩ 、およびＡＴＭ スイッチ３１のセル転送ポート番号などの通信経路情報を格納する。交換ノード３０は、呼管理テーブル３３に格納されている情報に従ってＡＴＭ セルを交換する。
【００３１】
たとえば、呼管理テーブル３３の１行目に設定されているＡＴＭ コネクションにおいて、端末（Ａ） １６からＶＰＩ／ＶＣＩ として”ａａｂｂ”が設定されているＡＴＭ セルを受信すると、交換ノード３０は、そのＡＴＭ セルの転送先が端末（Ｂ） １７であることを認識し、また、ＡＴＭ スイッチ３１は、呼管理テーブル３３の設定に従って、そのセルをポート４から出力する。この結果、ＡＴＭ セルは端末（Ｂ） １７へ送出される。一方、端末（Ｂ） １７からＶＰＩ／ＶＣＩ として”ｃｃｄｄ”が設定されているＡＴＭ セルを受信すると、交換ノード３０は、そのＡＴＭ セルの転送先が端末（Ａ） １６であることを認識し、また、ＡＴＭ スイッチ３１は、呼管理テーブル３３の設定に従って、そのＡＴＭ セルをポート３から出力する。この結果、ＡＴＭ セルは端末（Ａ） １６へ送出される。
【００３２】
エージェント３４は、ＡＴＭ セルの情報フィールドに格納されているデータを取り出して解析する。また、エージェント３４は、ＴＣＰ／ＩＰプロトコルのＩＰヘッダおよびＴＣＰ ヘッダを解釈する機能を有する。エージェント３４は、仮想的なＡＴＭ 端末であり、通常のＡＴＭ 端末と同様に、接続要求（発呼要求）を発行してＡＴＭ コネクションを確立したり、受信した接続要求に従ってその接続要求を発行した端末とＡＴＭ コネクションを介して通信を行うことができる。なお、エージェント３４は、ＡＴＭ スイッチ３１に収容されている。
【００３３】
ファイアウォールテーブル３５は、交換ノード３０に収容される端末毎にＴＣＰ／ＩＰコネクションを確立する際の規制条件を設定する。同図に示す例では、送り元ＩＰアドレス（発ＩＰアドレス）、宛先ＩＰアドレス（着ＩＰアドレス）、およびＴＣＰ の宛先ポート番号を設定している。ＴＣＰ のポート番号は、サービスまたはアプリケーションの種別を表す。
【００３４】
エージェント３４は、受信したＡＴＭ セルからＴＣＰ／ＩＰパケットを組み立てる。このＴＣＰ／ＩＰパケットのＩＰアドレスおよびポート番号がファイアウォールテーブル３５に既に設定されていた場合、エージェント３４は、ＴＣＰ／ＩＰコネクションを確立することを許容し、そのＴＣＰ／ＩＰコネクションを確立するためのＡＴＭ コネクションをアクセス先端末との間に確立する。ＡＴＭ コネクションを確立する際、エージェント３４は、呼管理テーブル３３を書き換える。
【００３５】
図３３に示す従来のシステムでは、着信端末を収容するルータ装置（または着信端末）がＴＣＰ／ＩＰコネクションの確立を許容するか否かを判断していたが、本実施形態のシステムでは、交換ノード３０内に設けたエージェント３４がその判断をする。すなわち、エージェント３４は、ファイアウォール機能の実行に際して着信端末を収容するルータ装置（または着信端末）の代理として働く仮想端末である。
【００３６】
端末（Ａ） １６から端末（Ｂ） １７にＴＣＰ／ＩＰプロトコルに従ってアクセスする場合の概略動作を説明する。まず、端末（Ａ） １６は、端末（Ｂ） １７への接続要求を発行する。この接続要求は、通信プロトコルとしてＴＣＰ／ＩＰを使用することを示す情報を含んでおり、ＡＴＭ セルに格納されて送出される。
【００３７】
交換ノード３０は、この接続要求がＴＣＰ／ＩＰ接続を要求していると認識すると、その接続要求をエージェント３４に渡す。このことにより、端末（Ａ） １６とエージェント３４との間にＡＴＭ コネクションが確立される。ただし、端末（Ａ） １６は端末（Ｂ） １７との間でＡＴＭ コネクションが確立されたものとの認識している。端末（Ａ） １６は、端末（Ｂ） １７に対してＴＣＰ／ＩＰパケットを送出すると、ＡＴＭ コネクションはエージェント３４に接続されているので、そのＴＣＰ／ＩＰパケットはエージェント３４によって受信される。
【００３８】
エージェント３４は、受信したＴＣＰ／ＩＰパケットに格納されている端末（Ｂ） １７のＩＰアドレス、およびサービス種別（ポート番号）がファイアウォールテーブル３５に設定されているかどうかを調べる。設定されていなければ、エージェント３４は、上記接続要求を許容せず、端末（Ｂ） １７の代理として端末（Ａ） １６に対してＴＣＰ／ＩＰコネクションを確立できないことを示すメッセージを送出し、さらに端末（Ａ） １６とエージェント３４との間のＡＴＭ コネクションを切断する。一方、ファイアウォールテーブル３５にＩＰアドレスおよびポート番号が設定されていた場合には、エージェント３４は、上記接続要求を許容し、端末（Ａ） １６の代理として端末（Ｂ） １７との間にＡＴＭ コネクションを確立する。その後、エージェント３４は、呼管理テーブル３３を書き換えることにより、端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションを確立する。このとき、端末（Ａ） １６と端末（Ｂ） １７との間には、すでにＴＣＰ／ＩＰコネクションが確立されている。
【００３９】
次に、ファイアウォールテーブル３５の登録手順を説明する。以下では、図６および図７を参照しながら、端末（Ｂ） １７からその端末（Ｂ） １７を収容する交換ノード（Ｂ） １３内のファイアウォールテーブル３５に端末（Ｂ） １７へのアクセス規制条件を登録する例を説明する。
【００４０】
手順１： 端末（Ｂ） １７は、発呼要求により、エージェント（Ｂ） １５との間にＡＴＭ コネクションを確立する。この場合、端末（Ｂ） １７は、宛先アドレスとしてエージェント（Ｂ） １５に割り当てられているＡＴＭ アドレス（ＤＴＥｘｂ ）を指定し、交換ノード１３の呼管理制御部３２は、呼制御テーブル３３において着アドレスとしてそのＡＴＭ アドレスを設定する。呼制御テーブル３３において着アドレスとしてエージェント１５のＡＴＭ アドレス（ＤＴＥｘｂ ）が設定されると、エージェント（Ｂ） １５は、ファイアウォールテーブ３５の設定（登録、変更、削除）プログラムを起動し、そのためのインタフェイスを提供する。
【００４１】
手順２〜４： エージェント（Ｂ） １５は、端末（Ｂ） １７に対してパスワード入力要求を送出する。これに対して、端末（Ｂ） １７が正しいパスワード（ＸＸＸＸ）を入力すると、エージェント（Ｂ） １５は、端末（Ｂ） １７に対して、アクセス規制条件登録受付メッセージを送出する。
【００４２】
手順５〜８： 端末（Ｂ） １７は、アクセス規制条件を送出する。この場合、たとえば、ＦＴＰ （ファイル転送プロトコル）でデータを転送する。ここでは、アクセスを許容するサービスとして、ＮＮＴＰ（ニュース転送プロトコル：ポート番号＝１１９）、ＳＭＴＰ（簡易メール転送プロトコル：ポート番号＝２５）、およびＨＴＴＰ（ハイパーテキスト転送プロトコル：ポート番号＝８０）を登録することを要求する。エージェント（Ｂ） １５は、端末（Ｂ） １７から受信した要求に従い、アクセス規制条件として端末（Ｂ） １７のＩＰアドレスと共にサービス種別（ポート番号）をファイアウォールテーブル３５に登録する。尚、アクセス規制条件として送り元アドレス（発アドレス）を登録することもできる。そして、エージェント（Ｂ） １５は、端末（Ｂ） １７にアクセス規制条件登録完了メッセージを送出した後、端末（Ｂ） １７との間に確立されていたＡＴＭ コネクションを切断する。
【００４３】
なお、上記の例では、端末（Ｂ） １７へのアクセス規制条件を端末（Ｂ） １７から登録したが、他の端末から登録することもできる。たとえば、ＬＡＮ 管理者が、そのＬＡＮ に収容される各端末へのアクセス規制条件をある所定の端末から一括して登録してもよい。あるいは、通信事業者が、その通信事業者と契約した端末のアクセス規制条件をＡＴＭ コネクションを介することなく直接エージェントに登録してもよい。
【００４４】
次に、交換ノードでＴＣＰ／ＩＰプロトコルによるアクセスを許容するか否かを判断する場合の手順を説明する。システム構成としては、宛先端末を収容する交換ノードにてその判断をする構成と、任意の交換ノードでその判断をする構成とが考えられるが、まず、宛先端末を収容する交換ノードにおいてその判断をする構成を説明する。
【００４５】
以下の説明では、図２において、端末（Ａ） １６から端末（Ｂ） １７へＴＣＰ／ＩＰプロトコルによるアクセス要求が発行されたときに、端末（Ｂ） １７を収容する交換ノード（Ｂ） １３においてそのアクセスを許容するか否かを判断する例を示す。ここで、エージェント（Ｂ） １５内のファイアウォールテーブル３５には、図６および図７を参照しながら説明した手順でアクセス規制条件が登録され、図８（ａ） に示す状態になっているものとする。
【００４６】
ＴＣＰ／ＩＰプロトコルによるアクセスが許容されるときの手順を図９を参照しながら説明する。
手順１： 端末（Ａ） １６は、端末（Ｂ） １７にアクセスする際、ＡＴＭ ネットワーク１１上に設けられた不図示のネームサーバを利用し、端末（Ｂ） １７のＩＰアドレス（１３３．１６２．９６．ｂ）から端末（Ｂ） １７のＡＴＭ アドレス（ＤＴＥｂ）を得る。この手順は、ＩＰ ｏｖｅｒ ＡＴＭ プロトコルに従う。
【００４７】
手順２： 端末（Ａ） １６は、端末（Ｂ） １７への発呼要求メッセージ（接続要求メッセージ）を、図１０に示すようにＡＴＭ セルに格納して送出する。すなわち、端末（Ａ） １６は、ＡＴＭ アドレスＤＴＥｂを宛先アドレスとして発呼する。この発呼要求メッセージは、たとえば、ＩＴＵ 勧告のＱ．９３１（または、Ｑ．９３１を同等の規定）に準拠しており、情報伝送能力（要求帯域）などを申告する。この発呼要求メッセージの付加情報フィールドには、ＴＣＰ／ＩＰコネクションによる通信を行うこと示す情報が設定されている。なお、発呼要求はシグナリング手順であり、発呼要求メッセージ格納したＡＴＭ セルに割り当てられるＶＰＩ／ＶＣＩ は、制御セルであることを示す値である。
【００４８】
手順３： 各交換ノードは、このＡＴＭ セルを受信すると、そのＶＰＩ／ＶＣＩ 値が制御セルを示しているので、情報フィールドを参照し、発呼要求メッセージに従って端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションを確立しようとする。このとき、アクセス先の端末である端末（Ｂ） １７を収容する交換ノード（Ｂ） １３は、受信した発呼メッセージの付加情報フィールドを参照し、ＴＣＰ／ＩＰコネクションによる通信を行うこと示す情報が設定されていると、その発呼メッセージを格納したＡＴＭ セルをエージェント（Ｂ） １５に渡す。すなわち、交換ノード（Ｂ） １３の呼管理制御部３２は、この時点で使用されていないＶＰＩ／ＶＣＩ （ＶＰＩ／ＶＣＩ ＝ｘａｘｂとする）を取り出し、そのＶＰＩ／ＶＣＩ をエージェント（Ｂ） １５へのルートを指定する情報として交換ノード（Ｂ） １３内の呼管理テーブル３３に設定する。このときの呼管理テーブル３３の状態を図１１（ａ） に示す。この設定により、交換ノード（Ｂ） １３は、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されているＡＴＭ セルを受信すると、そのＡＴＭ セルをエージェント（Ｂ） １５に転送するようになる。
【００４９】
手順４： エージェント（Ｂ） １５は、端末（Ｂ） １７への発呼要求メッセージを受け取ったので、端末（Ｂ） １７の代わりに呼受付メッセージを端末（Ａ） １６に送出する。この呼受付メッセージには、ＡＴＭ コネクションが確立されたときに使用するＶＰＩ／ＶＣＩ として”ｘａｘｂ”が設定されている。このことにより、端末（Ａ） １６とエージェント（Ｂ） １５との間にＡＴＭ コネクションが確立される。なお、エージェント（Ｂ） １５は、”ａａｂｂ”と端末（Ｂ） １７とを対応づけて記憶する。すなわち、エージェント（Ｂ） １５は、ＶＰＩ／ＶＣＩ として”ａａｂｂ”が設定されているＡＴＭ セルは本来は端末（Ｂ） １７へ転送されるべきであったことを記憶しておく。
【００５０】
手順５： 端末（Ａ） １６は、呼受付メッセージを受信すると、実際にはエージェント（Ｂ） １５との間にＡＴＭ コネクションが確立されているが、端末（Ｂ） １７との間にＡＴＭ コネクションが確立したと認識する。すなわち、端末（Ａ） １６は、以降、ＶＰＩ／ＶＣＩ ＝ａａｂｂを設定したＡＴＭ セルを送出すれば、そのＡＴＭ セルは端末（Ｂ） １７に転送されるものと認識する。
【００５１】
手順６： 端末（Ａ） １６は、端末（Ｂ） １７にＴＣＰ／ＩＰパケットを送出する。すなわち、端末（Ａ） １６は、端末（Ｂ） １７に対してＴＣＰ／ＩＰコネクション確立要求（アクセス要求）を送出する。ここでは、ポート番号８０で指定されるサービスを要求するものとする。なお、ＴＣＰ／ＩＰパケットは、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されたＡＴＭ セルに格納されて転送される。
【００５２】
手順７： 交換ノード（Ｂ） １３は、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されているＡＴＭ セルを受信すると、図１１（ａ） に示す状態の呼管理テーブル３３を参照し、そのＡＴＭ セルをエージェント（Ｂ） １５に転送する
手順８： エージェント（Ｂ） １５は、受信したＡＴＭ セルからＴＣＰ／ＩＰパケットを読み出す。このＴＣＰ／ＩＰパケットは、図８（ｂ） に示す情報を含んでいる。また、受信したＡＴＭ セルのＶＰＩ／ＶＣＩ が”ａａｂｂ”であるので、エージェント（Ｂ） １５は、そのＡＴＭ セルは端末（Ｂ） １７に転送されるべきセルであることを認識する。したがって、エージェント（Ｂ） １５は、端末（Ｂ） １７について登録されたファイアウォールテーブル３５を参照し、ＴＣＰ／ＩＰパケットに設定されている情報と同じ情報が登録されているかどうか調べる。なお、アクセス要求が許容された場合には、上記ＴＣＰ／ＩＰパケットを端末（ｂ） １７に転送するので、エージェント（Ｂ） １５は、そのＴＣＰ／ＩＰパケットを保持しておく。
【００５３】
手順９： エージェント（Ｂ） １５は、ＴＣＰ／ＩＰパケットに設定されている情報がファイアウォールテーブル３５に登録されていることを認識すると、端末（ｂ） １７へのアクセス要求を許容する。このとき、交換ノード（ｂ） １３と端末（ｂ） １７との間にはＡＴＭ コネクションは確立されていない。すなわち、交換ノード（ｂ） １３と端末（ｂ） １７との間にＡＴＭ コネクションを確立する前に、端末（Ａ） １６と端末（ｂ） １７との間のＡＴＭ コネクション上でのＴＣＰ／ＩＰコネクションによるアクセスを許容するか否かの判断ができたことになる。
【００５４】
エージェント（Ｂ） １５は、端末（ｂ） １７へのアクセスが許容されたと認識すると、端末（Ａ） １６と端末（ｂ） １７とをＡＴＭ コネクションで接続する。すなわち、端末（Ａ） １６とエージェント（ｂ） １５との間には既にＡＴＭ コネクションが確立されているので、エージェント（ｂ） １５は、エージェント（ｂ） １５と端末（ｂ） １７との間にＡＴＭ コネクションを確立する。したがって、エージェント（ｂ） １５は、端末（Ａ） １６の代わりに端末（ｂ） １７に対して発呼要求メッセージ（接続要求メッセージ）を送出する。この場合、送り元アドレス（発アドレス）は、端末（Ａ） １６のＡＴＭ アドレスＤＴＥａである。また、ＡＴＭ コネクションが確立した後に使用するＶＰＩ／ＶＣＩ として、その時点で使用されていない値（ＶＰＩ／ＶＣＩ ＝ｘａｘｃ）を呼管理テーブル３３に設定する。
【００５５】
手順１０： 交換ノード（Ｂ） １３は、エージェント（Ｂ） １５から端末（Ｂ） １７への発呼要求メッセージを受け取ると、現在使用されていなＶＰＩ／ＶＣＩ （ＶＰＩ／ＶＣＩ ＝ｃｃｄｄ）を取り出し、端末（Ｂ） １７へのルートを指定する識別子として呼管理テーブル３３に設定する。この結果、呼管理テーブル３３は、図１１（ｂ） に示す状態になる。交換ノード（Ｂ） １３は、発呼要求メッセージを格納したＡＴＭ セルにＶＰＩ／ＶＣＩ ＝ｃｃｄｄを割り当てて送出する。
【００５６】
手順１１〜１３： 端末（Ｂ） １７は、交換ノード（Ｂ） １３から発呼要求メッセージを受け取ると、そのメッセージを端末（Ａ） １６による発呼要求であると認識し、端末（Ａ） １６に対して呼受付メッセージを送出する。この呼受付メッセージは、ＶＰＩ／ＶＣＩ ＝ｃｃｄｄが割り当てられたＡＴＭ セルに格納して送出される。交換ノード（Ｂ） １３は、呼受付メッセージを受信すると、図１１（ｂ） の状態にある呼管理テーブル３３を参照し、その呼受付メッセージを端末（Ａ） １６に送出することなくエージェント（Ｂ） １５に渡す。このことにより、エージェント（Ｂ） １５と端末（ｂ） １７との間にＡＴＭ コネクションが確立されたことになる。この後、エージェント（Ｂ） １５は、手順８で保持しておいたＴＣＰ／ＩＰパケットをＡＴＭ セルに格納し、そのＡＴＭ セルにＶＰＩ／ＶＣＩ ＝ｘａｘｃを割り当てて送出する。
【００５７】
手順１４〜１６： 交換ノード（Ｂ） １３は、手順１３で送出されたＡＴＭ セルを受信すると、図１１（ｂ） の状態にある呼管理テーブル３３を参照し、そのセルを端末（Ｂ） １７へ転送する。エージェント（Ｂ） １５は、端末（Ａ） １６と端末（Ｂ） １７とをエージェント（Ｂ） １５を介することなく接続するように、交換ノード（Ｂ） １３内の呼管理テーブル３３を書き換える。この結果、呼管理テーブル３３は、図１１（ｃ） に示す状態に移る。
【００５８】
上記手順１〜１６により、端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションが確立されるが、このとき既にＴＣＰ／ＩＰプロトコルによるアクセス要求はエージェント（Ｂ） １５によって許容されている。以降、端末（Ａ） １６と端末（Ｂ） １７との間でＴＣＰ／ＩＰコネクションを介した通信が行われる。
【００５９】
ＴＣＰ／ＩＰプロトコルによるアクセスが許可されないときの手順を図１２を参照しながら説明する。以下の例では、端末（Ｂ） １７に関するファイアウォールテーブル３５が図８（ａ） に示す状態であり、端末（Ａ） １６から端末（Ｂ） １７に対してテルネットサービス（ＴＣＰ ポート番号＝２３）を要求するものとする。
【００６０】
手順１〜５： 手順１〜５は、図９を参照しながら説明した手順１〜５と同じである。
手順６〜７： 端末（Ａ） １６は、端末（Ｂ） １７にＴＣＰ／ＩＰパケットを送出する。すなわち、端末（Ａ） １６は、端末（Ｂ） １７に対してＴＣＰ／ＩＰコネクション確立要求（アクセス要求）を送出する。ここでは、ポート番号２３で指定されるサービスを要求するものとする。なお、ＴＣＰ／ＩＰパケットは、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されたＡＴＭ セルに格納されて転送される。交換ノード（Ｂ） １３は、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されているＡＴＭ セルを受信すると、図１３（ａ） に示す状態の呼管理テーブル３３を参照し、そのＡＴＭ セルをエージェント（Ｂ） １５に転送する
手順８〜９： エージェント（Ｂ） １５は、受信したＡＴＭ セルからＴＣＰ／ＩＰパケットを読み出す。このＴＣＰ／ＩＰパケットは、図８（ｃ） に示す情報を含んでいる。エージェント（Ｂ） １５は、図８（ａ） の状態のファイアウォールテーブル３５を参照してＴＣＰ／ＩＰパケットに設定されている情報と同じ情報が登録されているかどうか調べる。エージェント（Ｂ） １５は、ＴＣＰ／ＩＰパケットに設定されている情報がファイアウォールテーブル３５に登録されていないことを認識すると、端末（ｂ） １７へのアクセス要求を非許容と判断する。このとき、交換ノード（ｂ） １３と端末（ｂ） １７との間にはＡＴＭ コネクションは確立されていない。即ち、交換ノード（ｂ） １３と端末（ｂ） １７との間にＡＴＭ コネクションを確立する前に、端末（Ａ） １６と端末（ｂ） １７との間のＡＴＭ コネクション上でのＴＣＰ／ＩＰコネクションによるアクセスを許容するか否かの判断ができたことになる。
【００６１】
エージェント（Ｂ） １５は、端末（ｂ） １７へのアクセスが非許容であることを認識すると、端末（Ａ） １６に対してＴＣＰ／ＩＰコネクション確立不可メッセージを送出する。このメッセージは、ＡＴＭ セルに格納され、ＶＰＩ／ＶＣＩ ＝ｘａｘｂが割り当てられて送出される。
【００６２】
手順１０： 交換ノード（Ｂ） １３は、ＴＣＰ／ＩＰコネクション確立不可メッセージを格納したＡＴＭ セルを受信すると、図１３（ａ） の状態にある呼管理テーブル３３に従って、そのセルを端末（Ａ） １６へ転送する。
【００６３】
手順１１： 端末（Ａ） １６は、ＴＣＰ／ＩＰコネクション確立不可メッセージを受信する。端末（Ａ） １６は、このメッセージを端末（Ｂ） １７から転送されてきたものであるとみなす。このメッセージは、端末（Ａ） １６内のＴＣＰ／ＩＰアプリケーションプログラムに渡され、ＴＣＰ／ＩＰアプリケーションプログラムは、このことにより、ＴＣＰ／ＩＰパケットの送出を停止する。なお、ＴＣＰ／ＩＰアプリケーションプログラムがＴＣＰ／ＩＰコネクションのために確立したＡＴＭ コネクションの切断を要求することもある。
【００６４】
手順１２〜１３： エージェント（Ｂ） １５は、端末（Ａ） １６との間のＡＴＭ コネクションの切断要求を交換ノード（Ｂ） １３内の呼管理制御部３２に送出する。このことにより、交換ノード（Ｂ） １３内の呼管理テーブル３３が書き換えられ、呼管理テーブル３３の状態は図１３（ｂ） に示すようになる。また、交換ノード（Ｂ） １３は、端末（Ａ） １６に対して、ＡＴＭ コネクション切断指示メッセージを送出する。
手順１４〜１５： 端末（Ａ） １６は、ＡＴＭ コネクション切断指示メッセージを受信すると、交換ノード（Ｂ） １３に対してＡＴＭ コネクション切断完了メッセージを送出する。このことにより、交換ノード（Ｂ） １３内の呼管理テーブル３３が書き換えられ、呼管理テーブル３３の状態は図１３（ｃ） に示すようになる。
上述した図８〜図１３の例では、宛先端末（アクセス先端末）を収容する交換ノードにおいてＴＣＰ／ＩＰコネクションによるアクセスを許容するか否かを判断する構成を説明したが、以下では、送信端末（アクセス元端末）を収容する交換ノードにおいてその判断を行う構成を説明する。
【００６５】
以下の説明では、図２において、端末（Ａ） １６から端末（Ｂ） １７へＴＣＰ／ＩＰプロトコルによるアクセス要求が発行されたときに、端末（Ａ） １６を収容する交換ノード（Ａ） １２においてそのアクセスを許容するか否かを判断する例を示す。尚、端末（Ｂ） １７に関するアクセス規制条件は、交換ノード（Ｂ） １３のファイアウォールテーブルに格納されており、現在、交換ノード（Ａ） １２のファイアウォールテーブルには格納されていないものとする。また、アクセス規制条件をファイアウォールテーブル登録する手順は、図６および図７を参照しながら説明した手順に従う。
【００６６】
ＴＣＰ／ＩＰプロトコルによるアクセスが許可されるときの手順を図１４を参照しながら説明する。
図１４に示すシーケンスは、後述する手順ａ〜ｆを除けば、基本的に図９に示したシーケンスと同じである。ただし、図１４に示すシーケンスでは、図９に示したシーケンスにおいて交換ノード（Ｂ） １３およびエージェント（Ｂ） １５が行っていた処理と同等の処理を、交換ノード（Ａ） １２およびエージェント（Ａ） １４が行う。
【００６７】
すなわち、図１４に示すシーケンスでは、端末（Ａ） １６が端末（Ｂ） １７に対してＴＣＰ／ＩＰプロトコルによりアクセス要求を発行すると、端末（Ａ） １６とエージェント（Ａ） １４との間にＡＴＭ コネクションが確立され、エージェント（Ａ） １４に発呼要求メッセージが転送される。そして、エージェント（Ａ） １４においてＴＣＰ／ＩＰプロトコルによるアクセスを許容するか否かを判断し、許容する場合にのみ、エージェント（Ａ） １４が端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションを確立する。以下、手順ａ〜ｆについて説明する。
【００６８】
手順ａ： エージェント（Ａ） １４は、端末（Ｂ） １７への発呼要求（接続要求）メッセージを受け取ると、エージェント（Ａ） １４内のファイアウォールテーブル３５を検索して端末（Ｂ） １７に関するアクセス規制条件を探す。端末（Ｂ） １７に関するアクセス規制条件が格納されてない場合には、エージェント（Ａ） １４は、端末（Ｂ） １７に関するアクセス規制条件を要求するメッセージを送出する。
【００６９】
手順ｂ： 交換ノード（Ａ） １２は、手順ａにおいて送出されたメッセージを受け取ると、端末（Ｂ） １７のＡＴＭ アドレスより端末（Ｂ） １７を収容する交換ノード（交換ノード（Ｂ） １３）を認識し、交換ノード（Ｂ） １３に対して、端末（Ｂ） １７に関するアクセス規制条件を要求するメッセージを送出する。宛先ＡＴＭ アドレスからその宛先端末を収容する交換ノードを認識する手法は、通常の発呼手順と同じである。
【００７０】
手順ｃ〜ｄ： 交換ノード（Ｂ） １３は、上記メッセージを受け取ると、そのメッセージをエージェント（Ｂ） １５に渡す。エージェント（Ｂ） １５は、このメッセージに従い、端末（Ｂ） １７に関するアクセス規制条件を交換ノード（Ａ） １２に転送する。
【００７１】
手順ｅ〜ｆ： 交換ノード（Ａ） １２は、エージェント（Ｂ） １５から転送されてきた端末（Ｂ） １７に関するアクセス規制条件をエージェント（Ａ） １４に渡し、エージェント（Ａ） １４は、そのアクセス規制条件をエージェント（Ａ） １４内のファイアウォールテーブルに格納する。
【００７２】
上記手順ａ〜ｆにより、アクセス要求の送り元端末（端末（Ａ） １６）を収容する交換ノード（交換ノード（Ａ） １２）に、アクセス要求の着信先端末（端末（Ｂ） １７）に関するアクセス規制条件を登録できる。このように、アクセス要求の着信先端末に関するアクセス規制条件をいったんアクセス要求の送り元端末を収容する交換ノードに格納すれば、以降、その交換ノードにおいてアクセス要求を許容するか否かを判断できる。
【００７３】
図１５は、ＴＣＰ／ＩＰプロトコルによるアクセスが許可されない場合の手順を示す図である。手順ａ〜ｆは、図１４を参照しながら説明したシーケンスと同じであり、他の手順は、図１２を参照しながら説明したシーケンスと同じなので、図１５に関する詳細な説明は省略する。
【００７４】
なお、アクセス要求の送り元端末を収容する交換ノードにおいてアクセス要求を許容するか否かを判断した後には、他の交換ノードで同様の判断を行う必要はない。
【００７５】
上記図１４または図１５においては、アクセス要求の着信先端末に関するアクセス規制条件をアクセス要求の送り元端末を収容する交換ノードに格納する構成を説明したが、この場合、アクセス規制条件を次々をファイアウォールテーブル３５に書き込むことになる。ところが、ファイアウォールテーブル３５の規模を大きくするには実用的には限界がある。したがって、他の交換ノードから転送されてきたアクセス規制条件は、使用頻度の低いものをファイアウォールテーブルから削除する必用がある。
【００７６】
どのアクセス規制条件をファイアウォールテーブルから削除するのかは、参照回数および参照日時に従って決める。すなわち、ファイアウォールテーブル３５は、図１６に示すように、アクセス要求の着信先端末ごとに参照回数および参照日時を記録する領域を有し、参照されるごとにこれらのデータを更新する。そして、ファイアウォールテーブル３５が満杯の状態でさらに他の交換ノードからアクセス規制条件が転送されてきた場合には、たとえば、以下の条件を満たすアクセス規制条件を削除する。削除条件１：参照回数が１０回以下の端末に関するデータ。削除条件２：最後の参照した日時が１ヶ月以上前である端末に関するデータ。
【００７７】
このような構成とすることにより、ファイアウォールテーブルから使用頻度の低いアクセス規制条件が削除されるので、ファイアウォールテーブルの使用効率が向上する。
【００７８】
次に、本発明の他の実施形態について説明する。他の実施形態では、あるＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションが確立されている状況において、そのＡＴＭ コネクション上にさらに別のＴＣＰ／ＩＰコネクションを確立する場合を想定する。
【００７９】
以下では、端末（Ａ） １６と端末（Ｂ） １７との間に１２８ｋｂｐｓの帯域が割り当てられたＡＴＭ コネクションｋｋが確立されており、このＡＴＭ コネクションｋｋ上にＴＣＰ／ＩＰコネクションｍｍが確立されているものとする。ＴＣＰ／ＩＰコネクションｍｍは、簡易メール転送プロトコル（ポート番号＝２５）を提供する。このような状況において、端末（Ａ） １６が端末（Ｂ） １７にＴＣＰ／ＩＰプロトコルによる他のサービスを要求し、それに伴ってＡＴＭ コネクションｋｋ上にさらにＴＣＰ／ＩＰコネクションｎｎを確立する。この場合、ＡＴＭ コネクションｋｋの帯域を増加させる必用が生じる。
【００８０】
ＴＣＰ／ＩＰコネクションの追加が許可されるときの手順を図１７を参照しながら説明する。ここでは、端末（Ａ） １６が端末（Ｂ） １７に対して、ＨＴＴＰ（ポート番号＝８０）によるサービスを要求するものとする。この場合、追加されるＴＣＰ／ＩＰコネクションｎｎは、帯域として３８４ｋｂｐｓを要求し、それに伴ってＡＴＭ コネクションｋｋの帯域を１２８ｋｂｐｓから５１２ｋｂｐｓに増加させる必用があるものとする。
【００８１】
手順１： 端末（Ａ） １６は、端末（Ｂ） １７との間にＴＣＰ／ＩＰコネクションｎｎを確立するために、端末（Ｂ） １７に対して帯域予約要求メッセージを送出する。このメッセージは、発ＩＰアドレス「１３３．１６２．９６．ａ」、着ＩＰアドレス「１３３．１６２．９６．ｂ」およびポート番号「８０」を含んでいる。また、このメッセージは、制御セルであることを示すＶＰＩ／ＶＣＩ が割り当てられたＡＴＭ セルに格納されてＡＴＭ ネットワーク１１に送出される。
【００８２】
交換ノード（Ｂ） １３は、このＡＴＭ セルを受信すると、そのＶＰＩ／ＶＣＩ 値が制御セルを示しているので、情報フィールドを参照する。ここでは、情報フィールドに帯域予約要求メッセージが格納されており、このメッセージ内にＴＣＰ／ＩＰプロトコルに関する情報が設定されているので、交換ノード（Ｂ） １３の呼管理制御部３２は、このメッセージを端末（Ｂ） １７には転送せずに、エージェント（Ｂ） １５に渡す。
【００８３】
手順２〜３： エージェント１５は、端末（Ａ） １６と端末（Ｂ） １７との間の通信に対して設定されているファイアウォールテーブル３５を参照し、帯域予約要求メッセージに設定されていたＩＰアドレスおよびＴＣＰ ポート番号がアクセス可能であることを認識する。そして、エージェント１５は、端末（Ａ） １６から転送されてきた帯域予約要求メッセージを端末（Ｂ） １７へ転送する。
【００８４】
手順４〜５： 端末（Ｂ） １７は、帯域予約要求メッセージで指定されている帯域を確保できると判断すると、帯域確保通知を端末（Ａ） １６に対して送出する。このことにより、端末（Ｂ） １７と交換ノード（Ｂ） １３との間、交換ノード（Ｂ） １３と交換ノード（Ａ） １２との間、および交換ノード（Ａ） １２と端末（Ａ） １６との間において帯域が確保され、ＡＴＭ コネクションｋｋに５１２ｋｂｐｓの帯域が割り当てられる。そして、端末（Ａ） １６と端末（Ｂ） １７との間にＴＣＰ／ＩＰコネクションが確立され、このＴＣＰ／ＩＰコネクションを介してＨＴＴＰが提供される。
【００８５】
ＴＣＰ／ＩＰコネクションの追加が許可されないときの手順を図１８を参照しながら説明する。ここでは、端末（Ａ） １６が端末（Ｂ） １７に対して、ＴＥＬＮＥＴ（ポート番号＝２３）によるサービスを要求するものとする。
【００８６】
手順１： 手順１は、図１７に示したシーケンスの手順１と同じである。
手順２〜３： エージェント１５は、端末（Ａ） １６と端末（Ｂ） １７との間の通信に対して設定されているファイアウォールテーブル３５を参照し、帯域予約要求メッセージに設定されていたＩＰアドレスおよびＴＣＰ ポート番号がアクセス非許容能であると判断する。この場合、エージェント１５は、端末（Ａ） １６に対して帯域変更不可メッセージを送出する。
【００８７】
このように、図１７または図１８に示すシステムでは、同一ＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションを追加してもよいかどうかをＡＴＭ ネットワーク１１内で判断するので、その判断をするためにＡＴＭ ネットワーク１１とアクセス要求先端末との間のパスを使用する必用がない。
【００８８】
従来のシステムでは、ＴＣＰ／ＩＰコネクションの追加が許可されない場合であっても、アクセス要求先端末とその端末を収容する交換ノードとの間でトラヒックが発生していたが、本実施形態では、そのトラヒックが発生しない。
【００８９】
次に、各交換ノードにおける処理フローチャートを示す。図１９は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その１）である。ここでは、着呼端末（着信先端末）を収容する交換ノードにファイアウォールを設ける場合を示す。
【００９０】
ステップＳ１では、発呼要求（接続要求）メッセージを受信する。ステップＳ２では、受信した発呼要求メッセージがＴＣＰ／ＩＰコネクション用なのかどうかを調べる。ＴＣＰ／ＩＰコネクション用であれば、ステップＳ３へ進み、ＴＣＰ／ＩＰコネクション用でなければステップＳ７へ進む。
【００９１】
ステップＳ３では、発呼要求メッセージがどこから転送されてきたのかを調べる。中継回線（ＮＮＩ によって規定される回線）から転送されてきた場合には、ステップＳ４へ進み、エージェントから転送されてきた場合には、ステップＳ６へ進み、端末回線（ＵＮＩ によって規定される回線）から転送されてきた場合には、ステップＳ７へ進む。
【００９２】
発呼要求メッセージが中継回線から転送されてくる場合とは、たとえば、図９の手順２、３に相当する。ステップＳ４では、発呼端末とエージェントとの間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ５では、発呼要求メッセージをエージェントに渡す。なお、ステップＳ４およびＳ５は、当該交換ノードが着呼端末を収容している場合に実行され、収容していない場合には、ステップＳ４およびＳ５の代わりにステップＳ７を実行する。
【００９３】
発呼要求メッセージがエージェントから転送されてくる場合とは、たとえば、図９の手順９、１０に相当する。ステップＳ６では、エージェントと着呼端末との間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ７では、発呼要求メッセージを着呼端末に転送する。
【００９４】
図２０は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その２）である。ここでも、着呼端末（着信先端末）を収容する交換ノードにファイアウォールを設ける場合を示す。
【００９５】
ステップＳ１１〜Ｓ１３は、発呼受付メッセージ（接続要求受付メッセージまたは呼受付メッセージ）を扱うが、基本的には、図１９で説明したステップＳ１〜Ｓ３と同じである。ステップＳ１３の判断において、発呼受付メッセージが端末回線から転送されてきた場合には、ステップＳ１４へ進み、中継回線から転送されてきた場合には、ステップＳ１５へ進む。
【００９６】
発呼受付メッセージが端末回線から転送されてくる場合とは、たとえば、図９の手順１１、１２に相当する。ステップＳ１４では、呼管理テーブルにおいて着呼端末とエージェントとの間にＡＴＭ コネクションが設定されているので、発呼受付メッセージをエージェントに転送する。
【００９７】
発呼受付メッセージが中継回線から転送されてくる場合とは、たとえば、図１４の手順１１、１２における交換ノード（Ｂ） １３の動作に相当する。ステップＳ１５では、受信した発呼受付メッセージを発呼端末に転送する。
【００９８】
図２１は、発呼端末とエージェントとの間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
ステップＳ２１では、発呼要求メッセージを受信する。ステップＳ２２では、受信した発呼受付メッセージを発呼端末に転送する。上記ステップの動作は、たとえば、図９の手順４に相当する。
【００９９】
図２２は、ＩＰパケット受信時の交換ノードの動作を説明するフローチャートである。
ステップＳ３１では、ＩＰパケット（ＴＣＰ／ＩＰパケット）を受信する。このＩＰパケットは、ＡＴＭ セルに格納されている。ステップＳ３２では、受信したＩＰパケットを呼管理テーブルに設定されている転送先ポートへ転送する。これらのステップの動作は、たとえば、図９の手順７に相当する。
【０１００】
図２３は、エージェントと着呼端末との間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
ステップＳ４１では、ＩＰパケット（ＴＣＰ／ＩＰパケット）を受信する。ステップＳ４２では、受信したＩＰパケットがＩＰコネクション（ＴＣＰ／ＩＰコネクション）の確立を要求するメッセージか否かを調べる。ＩＰコネクション確立要求メッセージであれば、ステップＳ４３へ進み、それ以外の場合は、受信したＩＰパケットをステップＳ５３において廃棄する。
【０１０１】
ステップＳ４３では、着呼端末に関するファイアウォールテーブルを持っているかどうかを調べる。持っている場合には、ステップＳ４５へ進み、持っていない場合には、ステップＳ４４において、着呼端末を収容する交換ノードから着呼端末に関するファイアウォールテーブルを転送してもらう。なお、ステップＳ４４は、たとえば、図１４の手順ａ〜ｆに相当する。
【０１０２】
ステップＳ４５では、受信したＩＰコネクション確立要求メッセージを許容するか否かを判断する。許容する場合（規制対象でない場合）には、ステップＳ４６へ進み、許容しない場合（規制対象の場合）には、ステップＳ５１へ進む。
【０１０３】
ステップＳ４６では、発呼要求メッセージを着呼端末へ転送する。ステップＳ４７では、着呼端末から発呼受付メッセージを受信する。ステップＳ４８では、ステップＳ４１で受信したＩＰコネクション確立要求メッセージを着呼端末へ転送する。ステップＳ４９では、エージェントを介することなく発呼端末と着呼端末との間を接続するＡＴＭ コネクションを確立するように当該交換ノード内の呼管理制御部に要求する。上記ステップＳ４６〜Ｓ４８は、たとえば、図９の手順９〜１４に相当し、ステップＳ４９は、図９の手順１５に相当する。
【０１０４】
ステップＳ５０では、ステップＳ４９の要求により、呼管理テーブルを書き換える。
ステップＳ５１では、発呼端末に対して、ＡＴＭ コネクション切断要求メッセージを転送する。ステップＳ５２では、発呼端末からＡＴＭ コネクション切断完了メッセージを受信する。これらのステップは、たとえば、図１２の手順１３、１４に相当する。
【０１０５】
図２４は、帯域予約要求メッセージを受信した際の交換ノード内の呼管理制御部の動作を説明するフローチャートである。ここでは、着呼端末（着信先端末）を収容する交換ノードにファイアウォールを設ける場合を示す。
【０１０６】
ステップＳ６１では、帯域予約要求メッセージを受信する。ステップＳ６２では、受信した上記帯域予約要求メッセージがＴＣＰ／ＩＰコネクション用なのかどうかを調べる。ＴＣＰ／ＩＰコネクション用であれば、ステップＳ６３へ進み、ＴＣＰ／ＩＰコネクション用でなければステップＳ６５へ進む。
【０１０７】
ステップＳ６３では、帯域予約要求メッセージがどこから転送されてきたのかを調べる。中継回線から転送されてきた場合は、ステップＳ４４へ進み、エージェントまたは端末回線から転送されてきた場合には、ステップＳ６５へ進む。
【０１０８】
帯域予約要求メッセージが中継回線から転送されてくる場合とは、たとえば、図１７の手順１に相当する。ステップＳ６４では、帯域予約要求メッセージをエージェントに渡す。なお、ステップＳ６４は、当該交換ノードが着呼端末を収容している場合に実行され、収容していない場合には、ステップＳ６４の代わりにステップＳ６６を実行する。
【０１０９】
帯域予約要求メッセージがエージェントから転送されてくる場合とは、たとえば、図１７の手順３に相当し、端末回線から転送されてくる場合とは、例えば、図１７の手順１における交換ノード（Ａ） １２の動作に相当する。ステップＳ６５では、帯域予約要求メッセージに従って帯域を確保する。ステップＳ６６では、帯域予約要求メッセージを着呼端末へ転送する。
【０１１０】
図２５は、帯域予約完了メッセージを受信した際の交換ノードの動作を説明するフローチャートである。
ステップＳ７１では、帯域予約完了メッセージを受信する。ステップＳ７２では、受信した帯域予約完了メッセージを発呼端末に転送する。これらのステップは、たとえば、図１７の手順４に相当する。
【０１１１】
図２６は、帯域予約要求メッセージを受信した際のエージェントの動作を説明するフローチャートである。
ステップＳ８１では、帯域予約要求メッセージを受信する。ステップＳ８２では、受信した帯域予約要求を許容するか否かを判断する。許容する場合（規制対象でない場合）は、ステップＳ８３へ進み、許容しない場合（規制対象の場合）には、ステップＳ８４へ進む。
【０１１２】
ステップＳ８３では、帯域予約要求メッセージを着呼端末へ転送する。ステップＳ８４では、帯域予約不可メッセージを発呼端末へ転送する。なお、ステップＳ８３は、たとえば、図１７の手順３に相当し、ステップＳ８４は、図１８の手順３に相当する。
【０１１３】
図２７は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その３）である。ここでは、発呼端末を収容する交換ノードにファイアウォールを設ける場合を示す。
【０１１４】
ステップＳ９１では、発呼要求（接続要求）メッセージを受信する。ステップＳ９２では、受信した発呼要求メッセージがＴＣＰ／ＩＰコネクション用なのかどうかを調べる。ＴＣＰ／ＩＰコネクション用であれば、ステップＳ９３へ進み、ＴＣＰ／ＩＰコネクション用でなければステップＳ９７へ進む。
【０１１５】
ステップＳ９３では、発呼要求メッセージがどこから転送されてきたのかを調べる。端末回線から転送されてきた場合には、ステップＳ９４へ進み、エージェントから転送されてきた場合には、ステップＳ９６へ進み、中継回線から転送されてきた場合には、ステップＳ９７へ進む。
【０１１６】
発呼要求メッセージが端末回線から転送されてくる場合とは、たとえば、図１４の手順２、３に相当する。ステップＳ９４では、発呼端末とエージェントとの間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ９５では、発呼要求メッセージをエージェントに渡す。
【０１１７】
発呼要求メッセージがエージェントから転送されてくる場合とは、たとえば、図１４の手順９、１０に相当する。ステップＳ９６では、エージェントと着呼端末との間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ９７では発呼要求メッセージを着呼端末に転送する。
【０１１８】
図２８は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その４）である。ここでも、発呼端末を収容する交換ノードにファイアウォールを設ける場合を示す。
【０１１９】
ステップＳ１０１〜Ｓ１０３は、発呼受付メッセージ（接続要求受付メッセージまたは呼受付メッセージ）を扱うが、基本的には、図２７で説明したステップＳ９１〜Ｓ９３と同じである。ステップＳ１０３の判断において、発呼受付メッセージが中継回線から転送されてきた場合には、ステップＳ１０４へ進み、端末回線から転送されてきた場合には、ステップＳ１０５へ進む。
【０１２０】
発呼受付メッセージが中継回線から転送されてくる場合とは、たとえば、図１４の手順１１、１２に相当する。ステップＳ１０４では、呼管理テーブルにおいて着呼端末とエージェントとの間にＡＴＭ コネクションが設定されているので、発呼受付メッセージをエージェントに転送する。
【０１２１】
発呼受付メッセージが端末回線から転送されてくる場合とは、たとえば、図１４の手順１１、１２における交換ノード（Ｂ） １３の動作に相当する。ステップＳ１０５では、受信した発呼受付メッセージを発呼端末に転送する。
【０１２２】
なお、上述の実施形態では、ファイアウォールテーブルに着ＩＰアドレスおよびＴＣＰ のポート番号を設定してそれらによってアクセス規制条件を決めていたが、図２９（ａ） に示すように、発ＩＰアドレスを登録してもよい。同図に示す例では、ＦＴＰ （ファイル転送プロトコル）に対して、発ＩＰアドレスが設定されている。この場合、このファイアウォールテーブルに登録されているＩＰアドレスを持った端末のみがＦＴＰ サービスを受けることができる。
【０１２３】
また、図２９（ｂ） に示すように、ファイアウォールテーブルにパスワードを設定してもよい。この場合、パスワードを知っているユーザのみがサービスを受けることができる。すなわち、ＡＴＭ ネットワークにおいてＴＣＰ／ＩＰアクセスに関するユーザ認証を行うことができる。
【０１２４】
また、上述の実施形態では、エージェントを交換ノード内に設けた仮想端末として説明したが、図３０（ａ） に示すように、エージェントを交換ノードと独立に設ける構成としてもよい。この場合、エージェント３４は、交換ノード３０に接続されたサーバコンピュータである。エージェント３４と交換ノード３０との間は、ＰＶＣ （パーマネント仮想チャネル）またはＳＶＣ （スイッチド仮想チャネル）で接続する。
【０１２５】
さらに、上述の実施形態では、各交換ノードごとにエージェントを設けていたが、図３０（ｂ） に示すように、複数の交換ノード３０−１〜３０−３に対して１つのエージェント４１を設けるようにしてもよい。
【０１２６】
上述の実施例では、ＩＰ ｏｖｅｒ ＡＴＭ システムの一実施形態として、ＴＣＰ／ＩＰプロトコルのトラヒックをＡＴＭ ネットワークを介して転送する構成を示したが、本発明は、ＴＣＰ プロトコル以外の通信プロトコルにも適用可能である。たとえば、本発明をＵＤＰ （Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｃｏｌ ）に適用可能である。この場合、ファイアウォールテーブルには、ＩＰアドレスおよびＵＤＰ のポート番号を登録し、それらの情報に従ってアクセスを規制する。
【０１２７】
ところで、コンピュータネットワークの世界では、イーサネット、トークンリング、ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）などのＬＡＮ が広く普及している。ＬＡＮ エミュレーションは、これらのＬＡＮ データをＡＴＭ ネットワークを介して転送する技術である。本発明は、ＩＰ ｏｖｅｒ ＡＴＭ システムだけでなく、ＬＡＮ エミュレーションシステムにも適用可能である。
【０１２８】
図３１は、本発明をＬＡＮ エミュレーションシステムに適用した場合の構成図である。同図に示す例では、ＡＴＭ ネットワーク１１を介してＬＡＮ５１とＬＡＮ５２とを接続する構成である。
【０１２９】
ＬＡＮ の代表的な通信プロトコルとしては、ＴＣＰ／ＩＰの他に、例えば、ノベル社のＮｅｔ Ｗａｒｅ（登録商標）で採用されているＩＰＸ／ＳＰＸ 、マイクロソフト社のＷｉｎｄｏｗｓ ９５、Ｗｉｎｄｏｗｓ ＮＴ（共に商標）で採用されているＮｅｔ ＢＥＵＩ、アップルコンピュータ社のＭａｃｉｎｔｏｓｈ （商標）で使用されているＡｐｐｌｅＴａｌｋ 等が知られている。
【０１３０】
ＬＡＮ は、基本的に、ＭＡＣ （Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを用いてデータを転送するが、上記の通信プロトコルでは、各プロトコル毎に独自のアドレス体系を有している。たとえば、ＩＰＸ／ＳＰＸ では、ＩＰＸ アドレスを有し、データを転送するときには、図３２（ａ） に示すように、ＩＰＸ アドレス（発アドレスおよび着アドレス）が設定されたＩＰＸ フレームをＭＡＣ フレームの中に格納する。そして、ＡＴＭ ネットワークを介して通信を行う場合には、このフレームをＡＴＭ セルに格納してネットワークに送出する。
【０１３１】
ＡＴＭ ネットワーク１１内の交換ノードには、図３２（ｂ） に示すようなファイアウォールテーブルを設ける。このように、ＩＰＸ アドレス毎にアクセス規制条件を設定すれば、発端末（アクセス要求元端末）と着端末（アクセス要求先端末）との間にＡＴＭ コネクションを確立することなく、着端末にデータを転送するか否かすなわちアクセスを許容するか否かを判断できる。
【０１３２】
上述した実施例の説明において、図２に示すように、ＡＴＭ ネットワークに直接接続される端末１６、１７間の通信では、アクセス要求が許容されれば、端末１６と端末１７との間にＡＴＭ コネクションが確立される。ところが、図３１に示すように、ＬＡＮ５１、５２間の通信では、ルータ５３とルータ５４との間にＡＴＭ コネクションが確立される。たとえば、ＬＡＮ５１に収容される端末５５からＬＡＮ５２に収容される端末５６にアクセスする際には、ＡＴＭ ネットワーク１１内に設けられたファイアウォール機能によりそのアクセスを許容するか否かを判断し、許容する場合には、ルータ５３とルータ５４との間にＡＴＭ コネクションを確立する。このことは、ＬＡＮ エミュレーションだけでなく、ＩＰ ｏｖｅｒ ＡＴＭ においても同様である。
【０１３３】
ＬＡＮ は、基本的に、通信相手との間にコネクションを確立することなくデータを送信するコネクションレス型通信である。一方、ＡＴＭ は、送受信間でコネクションを確立した後にそのコネクションを介してデータを転送するコネクション型通信である。従って、ＬＡＮ エミュレーションや、ＵＤＰ プロトコルによるトラヒックをＡＴＭ ネットワークを介して転送する技術は、コネクションレス型通信のトラヒックをコネクション型通信のネットワークを介して転送する方式と言える。換言すれば、ＡＴＭ ネットワークは、コネクション型通信のネットワークの一形態である。
【０１３４】
【発明の効果】
ＩＰ ｏｖｅｒ ＡＴＭ またはＬＡＮ エミュレーションにおいて、ＡＴＭ ネットワーク内にファイアウォールを設け、そのファイアウォールでアクセス要求を許容するか否かを判断するので、その判断のために着信先端末とその着信先端末を収容する交換ノードとの間にＡＴＭ コネクションを確立する必要がないので、ネットワーク資源の無駄遣いを防げる。また、着信先端末との間にコネクションを確立することなくアクセスが許容されるか否かの判断がされるので、その判断のために課金が発生しない。
【図面の簡単な説明】
【図１】本発明の原理を説明する図である。
【図２】本実施形態の全体システム構成図である。
【図３】ＴＣＰ／ＩＰパケットとＡＴＭ セルとの分解・組立を示す図である。
【図４】ＡＴＭ セルの構成図であり、（ａ） は、ＵＮＩ におけるフォーマット、（ｂ） は、ＮＮＩ におけるフォーマットである。
【図５】本実施形態のファイアウォールシステムの構成図である。
【図６】交換ノードへアクセス規制条件を登録する方法を説明する図である。
【図７】交換ノードへアクセス規制条件を登録するシーケンスを示す図である。
【図８】（ａ） は、ファイアウォールテーブルの例であり、（ｂ） および（ｃ） は、受信したＴＣＰ／ＩＰパケットの例である。
【図９】アクセスが許容される場合のシーケンスを示す図である。
【図１０】発呼要求メッセージをＡＴＭ セルに格納して転送することを模式的に示す図である。
【図１１】（ａ） 〜（ｃ） は、図９に対応する呼管理テーブルの例である。
【図１２】アクセスが許容されない場合のシーケンスを示す図である。
【図１３】（ａ） 〜（ｃ） は、図１２に対応する呼管理テーブルの例である。
【図１４】アクセス要求元端末を収容する交換ノードにおいてそのアクセスを許容するか否かを判断する場合のシーケンスを示す図（その１）である。
【図１５】アクセス要求元端末を収容する交換ノードにおいてそのアクセスを許容するか否かを判断する場合のシーケンスを示す図（その２）である。
【図１６】ファイアウォールテーブルから使用頻度の低い情報を削除する構成を説明する図である。
【図１７】ＴＣＰ／ＩＰコネクションの追加が許可されるときのシーケンスを示す図である。
【図１８】ＴＣＰ／ＩＰコネクションの追加が許可されない時のシーケンスを示す図である。
【図１９】発呼端末とエージェントとの間またはエージェントと着信先端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その１）である。
【図２０】発呼端末とエージェントとの間またはエージェントと着信先端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その２）である。
【図２１】発呼端末とエージェントとの間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
【図２２】ＩＰパケット受信時の交換ノードの動作を説明するフローチャートである。
【図２３】エージェントと着呼端末との間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
【図２４】帯域予約要求メッセージを受信したときの交換ノード内の呼管理制御部の動作を説明するフローチャートである。
【図２５】帯域予約完了メッセージを受信した際の交換ノード内の動作を説明するフローチャートである。
【図２６】帯域予約要求メッセージを受信した際のエージェントの動作を説明するフローチャートである。
【図２７】発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その３）である。
【図２８】発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その４）である。
【図２９】（ａ） および（ｂ） は、ファイアウォールテーブルの例である。
【図３０】（ａ） および（ｂ） は、エージェントの構成例を示す例である。
【図３１】本発明をＬＡＮ エミュレーションシステムに適用した場合の構成図である。
【図３２】（ａ） は、ＬＡＮ プロトコルのフレームを説明する図であり、（ｂ） は、ＬＡＮ エミュレーションシステムにおけるファイアウォールテーブルの例を示す図である。
【図３３】ＩＰ ｏｖｅｒ ＡＴＭ システムにおいてファイアウォールを設ける場合の従来の構成例を示す図である。
【符号の説明】
１ 交換ノード
２ エージェントユニット
３ コネクション型通信ネットワーク
１１ ＡＴＭ ネットワーク
１２、１３ 交換ノード
１４、１５ エージェント
１６、１７ 端末（ＤＴＥ： Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）
３０ 交換ノード
３０−１〜３０−３ 交換ノード
３１ ＡＴＭ スイッチ
３２ 呼管理制御部
３３ 呼管理テーブル
３４、４１ エージェント
３５ ファイアウォールテーブル
５１、５２ ＬＡＮ
５３、５４ 端末
５５、５６ ルータ装置
【発明の属する技術分野】
本発明は、ファイアウォールに係わり、特に、ＩＰ ｏｖｅｒ ＡＴＭ プロトコルを使用する通信におけるファイアウォールに関する。
【０００２】
【従来の技術】
近年、急速に普及してきているインターネットは、その標準プロトコルとしてＴＣＰ／ＩＰを採用しているが、ＴＣＰ／ＩＰプロトコルに従った通信をＡＴＭ ネットワーク上で実現するシステムが検討されている。このようなシステムは、ＩＰ ｏｖｅｒ ＡＴＭ と呼ばれている。この技術が確立されれば、たとえば、ＡＴＭ ネットワークを利用したインターネットを実現できる。
【０００３】
ところで、インターネットの普及に伴い、コンピュータ等の端末を公衆網に接続する機会が増えてきているが、このような状況では、公衆網側からの不正なアクセスから端末（端末が格納する情報）を守る技術が重要である。この場合、特定種類のトラフィックを遮断する機能が必要になる。特定種類のトラフィックを遮断することによってコンピュータ等のセキュリティを向上させる機能、またはその機能を実現する装置はファイアウォールと呼ばれている。
【０００４】
図３３は、上述したＩＰ ｏｖｅｒ ＡＴＭ においてファイアウォールを設ける例を示す図である。図３３に示す例では、端末（ＤＴＥ： Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）１０２、１０７は、ＴＣＰ／ＩＰプロトコルに従った通信を行うことができ、ＡＴＭ ネットワーク１０１に収容されている。ＬＡＮ１０３は、ＴＣＰ／ＩＰプロトコルを利用したイーサネットであり、ルータ１０５を介してＡＴＭ ネットワーク１０１に接続される。ルータ１０５は、ファイアウォール機能を有し、ＡＴＭ ネットワーク１０１からＬＡＮ１０３へのアクセスを選択的に許可する。
【０００５】
上記システムにおいて、端末１０２から端末１０７へＴＣＰ／ＩＰプロトコルでアクセスする場合には、まず、端末１０２から端末１０７間にＡＴＭ コネクションを確立し、そのＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションを確立して通信を行う。
【０００６】
端末１０２からＴＣＰ／ＩＰプロトコルによる通信でＬＡＮ１０４内に設けられた端末１０４へアクセスする場合は、まず、端末１０２とルータ１０５との間にＡＴＭ コネクションを確立する。そして、端末１０２は、そのＡＴＭ コネクションを介して端末１０４へのアクセス要求をルータ１０５へ転送する。ルータ１０５は、アクセス要求を受け取ると、ＩＰアドレスやＴＣＰ のポート番号などに従ってそのアクセス要求を許容するか否かを判断する。アクセス要求を許容する場合には、ルータ１０５は、端末１０２とルータ１０５との間に確立したＡＴＭ コネクションを利用して端末１０２と端末１０４との間にＴＣＰ／ＩＰコネクションを確立し、ＴＣＰ／ＩＰプロトコルによる通信が開始される。一方、アクセス要求を許容しない場合には、ルータ１０５は、端末１０２とルータ１０５との間に確立したＡＴＭ コネクションパケットを切断する。
【０００７】
このように、従来のシステムでは、ルータ１０５にファイアウォール機能を設け、ＡＴＭ ネットワーク１０１からＬＡＮ１０３へのアクセスを選択的に許可することによって、ＬＡＮ１０３内の資源への不正アクセスを防いでいた。
【０００８】
【発明が解決しようとする課題】
上述のように、ＩＰ ｏｖｅｒ ＡＴＭ システムにおいてＴＣＰ／ＩＰプロトコルレベルでアクセス要求を許容するか否かを判断するためには、許容されるであろうアクセス要求（許容アクセス）であっても、拒絶されるであろうアクセス要求（非許容アクセス）であっても、必ずいったんＡＴＭ コネクションが確立される。図３３に示す例では、端末１０２とルータ１０５との間にＡＴＭ コネクションが確立される。
【０００９】
ＡＴＭ ネットワーク１０１は、通常、ＡＴＭ コネクションが確立されるとその呼に対して課金する。したがって、たとえば、端末１０２から端末１０４へのアクセス要求がルータ１０５によって規制される（拒絶される）場合であっても、端末１０２とルータ１０５との間にいったんＡＴＭ コネクションが確立されるので、端末１０２は、サービスを受けられないにも係わらず課金されてしまう。
【００１０】
また、上述のように、非許容アクセスであっても、いったんＡＴＭ コネクションが確立されるので、網リソースが無駄使いされてしまう。たとえば、端末１０２から端末１０４へのアクセス要求が非許容アクセスであった場合でも、端末１０２とルータ１０５との間にはＡＴＭ コネクションが確立され、ＡＴＭ ネットワーク１０１とルータ１０５との間を接続する回線１０６の帯域がそのＡＴＭ コネクションに割り当てられてしまう。この場合、非許容アクセスによって回線１０６の使用可能帯域が小さくなってしまう。回線１０６の使用可能帯域が不足すると、回線１０６上にＡＴＭ コネクションを確立できなくなるので、許容アクセスであってもＬＡＮ１０３内へのアクセスができなくなってしまう。このように、非許容アクセスによって許容アクセスが妨害されてしまう恐れがある。
【００１１】
なお、上記問題は、ＩＰ ｏｖｅｒ ＡＴＭ のみに起因するものではなく、イーサネットやトークンリング等のＬＡＮ 上で転送されるデータをＡＴＭ ネットワークを介して転送するシステム（ＬＡＮ エミュレーションと呼ばれることがある）においても発生する。
【００１２】
本発明の課題は、網リソースを有効に利用できるファイアウォールを構築することである。
【００１３】
【課題を解決するための手段】
図１は、本発明の原理図である。本発明のファイアウォール方式は、第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワーク３を介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制する。
【００１４】
交換ノード１は、例えば、ネットワーク３の交換機であり、固定長パケットを交換するとともに、受信した固定長パケットのなかから上記第２のプロトコルによる第１の端末から第２の端末へのアクセス要求を含んだ固定長パケットを抽出する。
【００１５】
エージェントユニット２は、ネットワーク３内に設けられ、交換ノード１によって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断し、アクセスを許容する場合にのみ、上記第１の端末またはその第１の端末を収容する端末と上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立する。第１または第２の端末を収容する端末とは、たとえば、ルータ装置である。
【００１６】
上記構成によれば、交換ノードと第２の端末（またはその第２の端末を収容する端末装置）との間にコネクションを確立することなく第２の端末へのアクセスを許容するか否かを判断できる。すなわち、この判断のためにネットワーク３と第２の端末（またはその第２の端末を収容する端末装置）とを接続する回線の資源（帯域）を使うことはない。
【００１７】
本発明の他の態様のファイアウォール方式は、第１の端末と第２の端末との間に上記第１のプロトコルによるコネクションが確立されている状況において、そのコネクションを介して他のサービスを要求する場合を前提とする。
【００１８】
交換ノード１は、第２のプロトコルによる第１の端末から第２の端末へのアクセスのために上記コネクションの帯域変更を要求する情報を含んだ固定長パケットを抽出する。
【００１９】
エージェントユニット２は、ネットワーク３内に設けられ、交換ノード１によって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断し、その要求を許容する場合にのみ上記コネクションの帯域を変更する。
【００２０】
上記構成によれば、第２のプロトコルによるアクセスが許容されない場合には上記コネクションの帯域が変更されないので、ネットワーク資源（帯域）の無駄使いをを防ぐことができる。
【００２１】
【発明の実施の形態】
以下、本発明の実施形態について図面を参照しながら説明する。
図２は、本実施形態の全体システム構成図である。以下では、ＩＰ ｏｖｅｒ ＡＴＭ システムを前提に説明する。ＩＰ ｏｖｅｒ ＡＴＭ システムでは、各端末はＩＰプロトコルに従った通信を行うが、ここでは、一例として、ＴＣＰ／ＩＰプロトコルに従った通信を行い、ＡＴＭ ネットワーク内では、ＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションが確立されるものとする。本実施形態では、ＡＴＭ ネットワーク内にファイアウォールを設け、そのファイアウォールにおいてＴＣＰ／ＩＰコネクションを確立することを許可するか否かを判断する。そして、ＴＣＰ／ＩＰコネクションの確立を許容する通信に対してのみ、着信端末との間にＡＴＭ コネクションを確立する。
【００２２】
ＡＴＭ ネットワーク１１は、交換ノード（Ａ） １２および交換ノード（Ｂ） １３を有する。交換ノード（Ａ） １２および交換ノード（Ｂ） １３は、それぞれＡＴＭ 交換機であり、ＡＴＭ セルをそのヘッダに設定されているルーティング情報（ＶＰＩ／ＶＣＩ ）に基づいてルーティングする。また、交換ノード（Ａ） １２および交換ノード（Ｂ） １３は、それぞれエージェント（Ａ） １４およびエージェント（Ｂ） １５を有する。エージェント（Ａ） １４およびエージェント（Ｂ） １５は、仮想端末であり、それぞれＡＴＭ アドレスとして”ＤＴＥｘａ” および”ＤＴＥｘｂ” が割り当てられている。エージェント（Ａ） １４およびエージェント（Ｂ） １５は、ファイアウォール機能を有し、従来のシステムではルータ装置が行っていたＴＣＰ コネクションまたはＩＰコネクションによるアクセス規制をルータ装置に代わって行う。
【００２３】
交換ノード（Ａ） １２は端末（Ａ） １６を収容し、交換ノード（Ｂ） １３は端末（Ｂ） １７を収容する。端末（Ａ） １６および端末（Ｂ） １７は、それぞれＴＣＰ／ＩＰ端末であり、ＴＣＰ／ＩＰプロトコルに従って通信を行う。また、端末（Ａ） １６および端末（Ｂ） １７は、それぞれ、たとえば、ＤＴＥ（Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ ）である。端末（Ａ） １６および端末（Ｂ） １７は、ＡＴＭ 対応端末であり、データをＡＴＭ ネットワークに出力する際にそのデータをＡＴＭ セルに格納する機能、およびＡＴＭ ネットワークから受信したＡＴＭ セルから必用な情報を取り出す機能を有している。なお、非ＡＴＭ 対応端末１８をＡＴＭ ネットワーク１１に接続する場合は、セル分解組立機能を有したＴＡ（Ｔｅｒｍｉｎａｌ Ａｄａｐｔｏｒ）１９およびＤＳＵ（Ｄａｔａ Ｓｅｒｖｉｃｅ Ｕｎｉｔ ）２０を用いる。端末（Ａ） １６に対しては、ＡＴＭ アドレスとして”ＤＴＥａ”が割り当てられ、ＩＰアドレスとして”１３３．１６２．９６．ａ”が割り当てられている。また、端末（Ｂ） １７に対しては、ＡＴＭ アドレスとして”ＤＴＥｂ”が割り当てられ、ＩＰアドレスとして”１３３．１６２．９６．ｂ”が割り当てられている。
【００２４】
上記システムにおいて、端末（Ａ） １６と端末（Ｂ） １７との間でＴＣＰ／ＩＰプロトコルに従った通信を行う場合には、図３に示すように、送信側において、ＴＣＰ／ＩＰパケットを複数の固定長データに分解してそれらの固定長データをそれぞれＡＴＭ セルの情報フィールドに格納し、ＡＴＭ ネットワーク１１を介して転送する。受信側では、ＡＴＭ セルの情報フィールドから取り出したデータからＴＣＰ／ＩＰパケットを再生する。
【００２５】
図４は、ＡＴＭ セルの構成図であり、（ａ） は、ＵＮＩ （Ｕｓｅｒ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）におけるフォーマット、（ｂ） は、ＮＮＩ （Ｎｅｔｗｏｒｋ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ） におけるフォーマットである。ＡＴＭ セルは、５３バイトの固定長パケットであり、５バイトのヘッダと４８バイトの情報フィールドとから構成される。
【００２６】
ＵＮＩ におけるＡＴＭ セルは、図４（ａ） に示すように、８ビットのＶＰＩ （仮想パス識別子）と１６ビットのＶＣＩ （仮想チャネル識別子）を有する。ＶＰＩ／ＶＣＩ は、ルーティング情報である。ＧＦＣ （一般フロー制御）は、セル同士の衝突を防ぐために使用される情報である。ＰＴ（ペイロードタイプ）は、情報フィールドに格納される情報の種類（ユーザ情報、制御情報．．．）を示す。ＣＬＰ （セル損失優先表示）は、セルの優先度を表示する。ＨＥＣ （ヘッダ誤り制御）は、ヘッダ部分の誤り検出とセル同期に使われる。
【００２７】
ＮＮＩ におけるＡＴＭ セルは、図４（ｂ） に示すように、１２ビットのＶＰＩ および１６ビットのＶＣＩ を有する。ＰＴ、ＣＬＰ 、ＨＥＣ は、ＵＮＩ におけるＡＴＭ セルについて説明したものと同じである。
【００２８】
図５は、本実施形態のファイアウォールシステムの構成図である。図５において、交換ノード３０は、図２の交換ノード（Ａ） １２または交換ノード（Ｂ） １３であり、エージェント３４は、エージェント（Ａ） １４またはエージェント（Ｂ） １５である。
【００２９】
ＡＴＭ スイッチ３１は、複数の入力線および複数の出力線を収容し、ＡＴＭ セルを自律的に交換する。
呼管理制御部３２は、ＡＴＭ コネクションを管理・制御する。呼管理制御部３２は、呼の設定時に発呼要求メッセージを取り込んで解析し、呼管理テーブル３３を設定する。また、呼管理制御部３２は、ＡＴＭ コネクションの切断や、ＡＴＭ コネクションの使用帯域の変更など、呼管理処理を行う。
【００３０】
呼管理テーブル３３は、ＡＴＭ コネクション毎に、発呼端末のアドレス、着呼端末のアドレス、当該ＡＴＭ コネクションを介して転送されるデータセル（アイドルセルを含まない）のＶＰＩ／ＶＣＩ 、およびＡＴＭ スイッチ３１のセル転送ポート番号などの通信経路情報を格納する。交換ノード３０は、呼管理テーブル３３に格納されている情報に従ってＡＴＭ セルを交換する。
【００３１】
たとえば、呼管理テーブル３３の１行目に設定されているＡＴＭ コネクションにおいて、端末（Ａ） １６からＶＰＩ／ＶＣＩ として”ａａｂｂ”が設定されているＡＴＭ セルを受信すると、交換ノード３０は、そのＡＴＭ セルの転送先が端末（Ｂ） １７であることを認識し、また、ＡＴＭ スイッチ３１は、呼管理テーブル３３の設定に従って、そのセルをポート４から出力する。この結果、ＡＴＭ セルは端末（Ｂ） １７へ送出される。一方、端末（Ｂ） １７からＶＰＩ／ＶＣＩ として”ｃｃｄｄ”が設定されているＡＴＭ セルを受信すると、交換ノード３０は、そのＡＴＭ セルの転送先が端末（Ａ） １６であることを認識し、また、ＡＴＭ スイッチ３１は、呼管理テーブル３３の設定に従って、そのＡＴＭ セルをポート３から出力する。この結果、ＡＴＭ セルは端末（Ａ） １６へ送出される。
【００３２】
エージェント３４は、ＡＴＭ セルの情報フィールドに格納されているデータを取り出して解析する。また、エージェント３４は、ＴＣＰ／ＩＰプロトコルのＩＰヘッダおよびＴＣＰ ヘッダを解釈する機能を有する。エージェント３４は、仮想的なＡＴＭ 端末であり、通常のＡＴＭ 端末と同様に、接続要求（発呼要求）を発行してＡＴＭ コネクションを確立したり、受信した接続要求に従ってその接続要求を発行した端末とＡＴＭ コネクションを介して通信を行うことができる。なお、エージェント３４は、ＡＴＭ スイッチ３１に収容されている。
【００３３】
ファイアウォールテーブル３５は、交換ノード３０に収容される端末毎にＴＣＰ／ＩＰコネクションを確立する際の規制条件を設定する。同図に示す例では、送り元ＩＰアドレス（発ＩＰアドレス）、宛先ＩＰアドレス（着ＩＰアドレス）、およびＴＣＰ の宛先ポート番号を設定している。ＴＣＰ のポート番号は、サービスまたはアプリケーションの種別を表す。
【００３４】
エージェント３４は、受信したＡＴＭ セルからＴＣＰ／ＩＰパケットを組み立てる。このＴＣＰ／ＩＰパケットのＩＰアドレスおよびポート番号がファイアウォールテーブル３５に既に設定されていた場合、エージェント３４は、ＴＣＰ／ＩＰコネクションを確立することを許容し、そのＴＣＰ／ＩＰコネクションを確立するためのＡＴＭ コネクションをアクセス先端末との間に確立する。ＡＴＭ コネクションを確立する際、エージェント３４は、呼管理テーブル３３を書き換える。
【００３５】
図３３に示す従来のシステムでは、着信端末を収容するルータ装置（または着信端末）がＴＣＰ／ＩＰコネクションの確立を許容するか否かを判断していたが、本実施形態のシステムでは、交換ノード３０内に設けたエージェント３４がその判断をする。すなわち、エージェント３４は、ファイアウォール機能の実行に際して着信端末を収容するルータ装置（または着信端末）の代理として働く仮想端末である。
【００３６】
端末（Ａ） １６から端末（Ｂ） １７にＴＣＰ／ＩＰプロトコルに従ってアクセスする場合の概略動作を説明する。まず、端末（Ａ） １６は、端末（Ｂ） １７への接続要求を発行する。この接続要求は、通信プロトコルとしてＴＣＰ／ＩＰを使用することを示す情報を含んでおり、ＡＴＭ セルに格納されて送出される。
【００３７】
交換ノード３０は、この接続要求がＴＣＰ／ＩＰ接続を要求していると認識すると、その接続要求をエージェント３４に渡す。このことにより、端末（Ａ） １６とエージェント３４との間にＡＴＭ コネクションが確立される。ただし、端末（Ａ） １６は端末（Ｂ） １７との間でＡＴＭ コネクションが確立されたものとの認識している。端末（Ａ） １６は、端末（Ｂ） １７に対してＴＣＰ／ＩＰパケットを送出すると、ＡＴＭ コネクションはエージェント３４に接続されているので、そのＴＣＰ／ＩＰパケットはエージェント３４によって受信される。
【００３８】
エージェント３４は、受信したＴＣＰ／ＩＰパケットに格納されている端末（Ｂ） １７のＩＰアドレス、およびサービス種別（ポート番号）がファイアウォールテーブル３５に設定されているかどうかを調べる。設定されていなければ、エージェント３４は、上記接続要求を許容せず、端末（Ｂ） １７の代理として端末（Ａ） １６に対してＴＣＰ／ＩＰコネクションを確立できないことを示すメッセージを送出し、さらに端末（Ａ） １６とエージェント３４との間のＡＴＭ コネクションを切断する。一方、ファイアウォールテーブル３５にＩＰアドレスおよびポート番号が設定されていた場合には、エージェント３４は、上記接続要求を許容し、端末（Ａ） １６の代理として端末（Ｂ） １７との間にＡＴＭ コネクションを確立する。その後、エージェント３４は、呼管理テーブル３３を書き換えることにより、端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションを確立する。このとき、端末（Ａ） １６と端末（Ｂ） １７との間には、すでにＴＣＰ／ＩＰコネクションが確立されている。
【００３９】
次に、ファイアウォールテーブル３５の登録手順を説明する。以下では、図６および図７を参照しながら、端末（Ｂ） １７からその端末（Ｂ） １７を収容する交換ノード（Ｂ） １３内のファイアウォールテーブル３５に端末（Ｂ） １７へのアクセス規制条件を登録する例を説明する。
【００４０】
手順１： 端末（Ｂ） １７は、発呼要求により、エージェント（Ｂ） １５との間にＡＴＭ コネクションを確立する。この場合、端末（Ｂ） １７は、宛先アドレスとしてエージェント（Ｂ） １５に割り当てられているＡＴＭ アドレス（ＤＴＥｘｂ ）を指定し、交換ノード１３の呼管理制御部３２は、呼制御テーブル３３において着アドレスとしてそのＡＴＭ アドレスを設定する。呼制御テーブル３３において着アドレスとしてエージェント１５のＡＴＭ アドレス（ＤＴＥｘｂ ）が設定されると、エージェント（Ｂ） １５は、ファイアウォールテーブ３５の設定（登録、変更、削除）プログラムを起動し、そのためのインタフェイスを提供する。
【００４１】
手順２〜４： エージェント（Ｂ） １５は、端末（Ｂ） １７に対してパスワード入力要求を送出する。これに対して、端末（Ｂ） １７が正しいパスワード（ＸＸＸＸ）を入力すると、エージェント（Ｂ） １５は、端末（Ｂ） １７に対して、アクセス規制条件登録受付メッセージを送出する。
【００４２】
手順５〜８： 端末（Ｂ） １７は、アクセス規制条件を送出する。この場合、たとえば、ＦＴＰ （ファイル転送プロトコル）でデータを転送する。ここでは、アクセスを許容するサービスとして、ＮＮＴＰ（ニュース転送プロトコル：ポート番号＝１１９）、ＳＭＴＰ（簡易メール転送プロトコル：ポート番号＝２５）、およびＨＴＴＰ（ハイパーテキスト転送プロトコル：ポート番号＝８０）を登録することを要求する。エージェント（Ｂ） １５は、端末（Ｂ） １７から受信した要求に従い、アクセス規制条件として端末（Ｂ） １７のＩＰアドレスと共にサービス種別（ポート番号）をファイアウォールテーブル３５に登録する。尚、アクセス規制条件として送り元アドレス（発アドレス）を登録することもできる。そして、エージェント（Ｂ） １５は、端末（Ｂ） １７にアクセス規制条件登録完了メッセージを送出した後、端末（Ｂ） １７との間に確立されていたＡＴＭ コネクションを切断する。
【００４３】
なお、上記の例では、端末（Ｂ） １７へのアクセス規制条件を端末（Ｂ） １７から登録したが、他の端末から登録することもできる。たとえば、ＬＡＮ 管理者が、そのＬＡＮ に収容される各端末へのアクセス規制条件をある所定の端末から一括して登録してもよい。あるいは、通信事業者が、その通信事業者と契約した端末のアクセス規制条件をＡＴＭ コネクションを介することなく直接エージェントに登録してもよい。
【００４４】
次に、交換ノードでＴＣＰ／ＩＰプロトコルによるアクセスを許容するか否かを判断する場合の手順を説明する。システム構成としては、宛先端末を収容する交換ノードにてその判断をする構成と、任意の交換ノードでその判断をする構成とが考えられるが、まず、宛先端末を収容する交換ノードにおいてその判断をする構成を説明する。
【００４５】
以下の説明では、図２において、端末（Ａ） １６から端末（Ｂ） １７へＴＣＰ／ＩＰプロトコルによるアクセス要求が発行されたときに、端末（Ｂ） １７を収容する交換ノード（Ｂ） １３においてそのアクセスを許容するか否かを判断する例を示す。ここで、エージェント（Ｂ） １５内のファイアウォールテーブル３５には、図６および図７を参照しながら説明した手順でアクセス規制条件が登録され、図８（ａ） に示す状態になっているものとする。
【００４６】
ＴＣＰ／ＩＰプロトコルによるアクセスが許容されるときの手順を図９を参照しながら説明する。
手順１： 端末（Ａ） １６は、端末（Ｂ） １７にアクセスする際、ＡＴＭ ネットワーク１１上に設けられた不図示のネームサーバを利用し、端末（Ｂ） １７のＩＰアドレス（１３３．１６２．９６．ｂ）から端末（Ｂ） １７のＡＴＭ アドレス（ＤＴＥｂ）を得る。この手順は、ＩＰ ｏｖｅｒ ＡＴＭ プロトコルに従う。
【００４７】
手順２： 端末（Ａ） １６は、端末（Ｂ） １７への発呼要求メッセージ（接続要求メッセージ）を、図１０に示すようにＡＴＭ セルに格納して送出する。すなわち、端末（Ａ） １６は、ＡＴＭ アドレスＤＴＥｂを宛先アドレスとして発呼する。この発呼要求メッセージは、たとえば、ＩＴＵ 勧告のＱ．９３１（または、Ｑ．９３１を同等の規定）に準拠しており、情報伝送能力（要求帯域）などを申告する。この発呼要求メッセージの付加情報フィールドには、ＴＣＰ／ＩＰコネクションによる通信を行うこと示す情報が設定されている。なお、発呼要求はシグナリング手順であり、発呼要求メッセージ格納したＡＴＭ セルに割り当てられるＶＰＩ／ＶＣＩ は、制御セルであることを示す値である。
【００４８】
手順３： 各交換ノードは、このＡＴＭ セルを受信すると、そのＶＰＩ／ＶＣＩ 値が制御セルを示しているので、情報フィールドを参照し、発呼要求メッセージに従って端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションを確立しようとする。このとき、アクセス先の端末である端末（Ｂ） １７を収容する交換ノード（Ｂ） １３は、受信した発呼メッセージの付加情報フィールドを参照し、ＴＣＰ／ＩＰコネクションによる通信を行うこと示す情報が設定されていると、その発呼メッセージを格納したＡＴＭ セルをエージェント（Ｂ） １５に渡す。すなわち、交換ノード（Ｂ） １３の呼管理制御部３２は、この時点で使用されていないＶＰＩ／ＶＣＩ （ＶＰＩ／ＶＣＩ ＝ｘａｘｂとする）を取り出し、そのＶＰＩ／ＶＣＩ をエージェント（Ｂ） １５へのルートを指定する情報として交換ノード（Ｂ） １３内の呼管理テーブル３３に設定する。このときの呼管理テーブル３３の状態を図１１（ａ） に示す。この設定により、交換ノード（Ｂ） １３は、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されているＡＴＭ セルを受信すると、そのＡＴＭ セルをエージェント（Ｂ） １５に転送するようになる。
【００４９】
手順４： エージェント（Ｂ） １５は、端末（Ｂ） １７への発呼要求メッセージを受け取ったので、端末（Ｂ） １７の代わりに呼受付メッセージを端末（Ａ） １６に送出する。この呼受付メッセージには、ＡＴＭ コネクションが確立されたときに使用するＶＰＩ／ＶＣＩ として”ｘａｘｂ”が設定されている。このことにより、端末（Ａ） １６とエージェント（Ｂ） １５との間にＡＴＭ コネクションが確立される。なお、エージェント（Ｂ） １５は、”ａａｂｂ”と端末（Ｂ） １７とを対応づけて記憶する。すなわち、エージェント（Ｂ） １５は、ＶＰＩ／ＶＣＩ として”ａａｂｂ”が設定されているＡＴＭ セルは本来は端末（Ｂ） １７へ転送されるべきであったことを記憶しておく。
【００５０】
手順５： 端末（Ａ） １６は、呼受付メッセージを受信すると、実際にはエージェント（Ｂ） １５との間にＡＴＭ コネクションが確立されているが、端末（Ｂ） １７との間にＡＴＭ コネクションが確立したと認識する。すなわち、端末（Ａ） １６は、以降、ＶＰＩ／ＶＣＩ ＝ａａｂｂを設定したＡＴＭ セルを送出すれば、そのＡＴＭ セルは端末（Ｂ） １７に転送されるものと認識する。
【００５１】
手順６： 端末（Ａ） １６は、端末（Ｂ） １７にＴＣＰ／ＩＰパケットを送出する。すなわち、端末（Ａ） １６は、端末（Ｂ） １７に対してＴＣＰ／ＩＰコネクション確立要求（アクセス要求）を送出する。ここでは、ポート番号８０で指定されるサービスを要求するものとする。なお、ＴＣＰ／ＩＰパケットは、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されたＡＴＭ セルに格納されて転送される。
【００５２】
手順７： 交換ノード（Ｂ） １３は、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されているＡＴＭ セルを受信すると、図１１（ａ） に示す状態の呼管理テーブル３３を参照し、そのＡＴＭ セルをエージェント（Ｂ） １５に転送する
手順８： エージェント（Ｂ） １５は、受信したＡＴＭ セルからＴＣＰ／ＩＰパケットを読み出す。このＴＣＰ／ＩＰパケットは、図８（ｂ） に示す情報を含んでいる。また、受信したＡＴＭ セルのＶＰＩ／ＶＣＩ が”ａａｂｂ”であるので、エージェント（Ｂ） １５は、そのＡＴＭ セルは端末（Ｂ） １７に転送されるべきセルであることを認識する。したがって、エージェント（Ｂ） １５は、端末（Ｂ） １７について登録されたファイアウォールテーブル３５を参照し、ＴＣＰ／ＩＰパケットに設定されている情報と同じ情報が登録されているかどうか調べる。なお、アクセス要求が許容された場合には、上記ＴＣＰ／ＩＰパケットを端末（ｂ） １７に転送するので、エージェント（Ｂ） １５は、そのＴＣＰ／ＩＰパケットを保持しておく。
【００５３】
手順９： エージェント（Ｂ） １５は、ＴＣＰ／ＩＰパケットに設定されている情報がファイアウォールテーブル３５に登録されていることを認識すると、端末（ｂ） １７へのアクセス要求を許容する。このとき、交換ノード（ｂ） １３と端末（ｂ） １７との間にはＡＴＭ コネクションは確立されていない。すなわち、交換ノード（ｂ） １３と端末（ｂ） １７との間にＡＴＭ コネクションを確立する前に、端末（Ａ） １６と端末（ｂ） １７との間のＡＴＭ コネクション上でのＴＣＰ／ＩＰコネクションによるアクセスを許容するか否かの判断ができたことになる。
【００５４】
エージェント（Ｂ） １５は、端末（ｂ） １７へのアクセスが許容されたと認識すると、端末（Ａ） １６と端末（ｂ） １７とをＡＴＭ コネクションで接続する。すなわち、端末（Ａ） １６とエージェント（ｂ） １５との間には既にＡＴＭ コネクションが確立されているので、エージェント（ｂ） １５は、エージェント（ｂ） １５と端末（ｂ） １７との間にＡＴＭ コネクションを確立する。したがって、エージェント（ｂ） １５は、端末（Ａ） １６の代わりに端末（ｂ） １７に対して発呼要求メッセージ（接続要求メッセージ）を送出する。この場合、送り元アドレス（発アドレス）は、端末（Ａ） １６のＡＴＭ アドレスＤＴＥａである。また、ＡＴＭ コネクションが確立した後に使用するＶＰＩ／ＶＣＩ として、その時点で使用されていない値（ＶＰＩ／ＶＣＩ ＝ｘａｘｃ）を呼管理テーブル３３に設定する。
【００５５】
手順１０： 交換ノード（Ｂ） １３は、エージェント（Ｂ） １５から端末（Ｂ） １７への発呼要求メッセージを受け取ると、現在使用されていなＶＰＩ／ＶＣＩ （ＶＰＩ／ＶＣＩ ＝ｃｃｄｄ）を取り出し、端末（Ｂ） １７へのルートを指定する識別子として呼管理テーブル３３に設定する。この結果、呼管理テーブル３３は、図１１（ｂ） に示す状態になる。交換ノード（Ｂ） １３は、発呼要求メッセージを格納したＡＴＭ セルにＶＰＩ／ＶＣＩ ＝ｃｃｄｄを割り当てて送出する。
【００５６】
手順１１〜１３： 端末（Ｂ） １７は、交換ノード（Ｂ） １３から発呼要求メッセージを受け取ると、そのメッセージを端末（Ａ） １６による発呼要求であると認識し、端末（Ａ） １６に対して呼受付メッセージを送出する。この呼受付メッセージは、ＶＰＩ／ＶＣＩ ＝ｃｃｄｄが割り当てられたＡＴＭ セルに格納して送出される。交換ノード（Ｂ） １３は、呼受付メッセージを受信すると、図１１（ｂ） の状態にある呼管理テーブル３３を参照し、その呼受付メッセージを端末（Ａ） １６に送出することなくエージェント（Ｂ） １５に渡す。このことにより、エージェント（Ｂ） １５と端末（ｂ） １７との間にＡＴＭ コネクションが確立されたことになる。この後、エージェント（Ｂ） １５は、手順８で保持しておいたＴＣＰ／ＩＰパケットをＡＴＭ セルに格納し、そのＡＴＭ セルにＶＰＩ／ＶＣＩ ＝ｘａｘｃを割り当てて送出する。
【００５７】
手順１４〜１６： 交換ノード（Ｂ） １３は、手順１３で送出されたＡＴＭ セルを受信すると、図１１（ｂ） の状態にある呼管理テーブル３３を参照し、そのセルを端末（Ｂ） １７へ転送する。エージェント（Ｂ） １５は、端末（Ａ） １６と端末（Ｂ） １７とをエージェント（Ｂ） １５を介することなく接続するように、交換ノード（Ｂ） １３内の呼管理テーブル３３を書き換える。この結果、呼管理テーブル３３は、図１１（ｃ） に示す状態に移る。
【００５８】
上記手順１〜１６により、端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションが確立されるが、このとき既にＴＣＰ／ＩＰプロトコルによるアクセス要求はエージェント（Ｂ） １５によって許容されている。以降、端末（Ａ） １６と端末（Ｂ） １７との間でＴＣＰ／ＩＰコネクションを介した通信が行われる。
【００５９】
ＴＣＰ／ＩＰプロトコルによるアクセスが許可されないときの手順を図１２を参照しながら説明する。以下の例では、端末（Ｂ） １７に関するファイアウォールテーブル３５が図８（ａ） に示す状態であり、端末（Ａ） １６から端末（Ｂ） １７に対してテルネットサービス（ＴＣＰ ポート番号＝２３）を要求するものとする。
【００６０】
手順１〜５： 手順１〜５は、図９を参照しながら説明した手順１〜５と同じである。
手順６〜７： 端末（Ａ） １６は、端末（Ｂ） １７にＴＣＰ／ＩＰパケットを送出する。すなわち、端末（Ａ） １６は、端末（Ｂ） １７に対してＴＣＰ／ＩＰコネクション確立要求（アクセス要求）を送出する。ここでは、ポート番号２３で指定されるサービスを要求するものとする。なお、ＴＣＰ／ＩＰパケットは、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されたＡＴＭ セルに格納されて転送される。交換ノード（Ｂ） １３は、ＶＰＩ／ＶＣＩ ＝ａａｂｂが設定されているＡＴＭ セルを受信すると、図１３（ａ） に示す状態の呼管理テーブル３３を参照し、そのＡＴＭ セルをエージェント（Ｂ） １５に転送する
手順８〜９： エージェント（Ｂ） １５は、受信したＡＴＭ セルからＴＣＰ／ＩＰパケットを読み出す。このＴＣＰ／ＩＰパケットは、図８（ｃ） に示す情報を含んでいる。エージェント（Ｂ） １５は、図８（ａ） の状態のファイアウォールテーブル３５を参照してＴＣＰ／ＩＰパケットに設定されている情報と同じ情報が登録されているかどうか調べる。エージェント（Ｂ） １５は、ＴＣＰ／ＩＰパケットに設定されている情報がファイアウォールテーブル３５に登録されていないことを認識すると、端末（ｂ） １７へのアクセス要求を非許容と判断する。このとき、交換ノード（ｂ） １３と端末（ｂ） １７との間にはＡＴＭ コネクションは確立されていない。即ち、交換ノード（ｂ） １３と端末（ｂ） １７との間にＡＴＭ コネクションを確立する前に、端末（Ａ） １６と端末（ｂ） １７との間のＡＴＭ コネクション上でのＴＣＰ／ＩＰコネクションによるアクセスを許容するか否かの判断ができたことになる。
【００６１】
エージェント（Ｂ） １５は、端末（ｂ） １７へのアクセスが非許容であることを認識すると、端末（Ａ） １６に対してＴＣＰ／ＩＰコネクション確立不可メッセージを送出する。このメッセージは、ＡＴＭ セルに格納され、ＶＰＩ／ＶＣＩ ＝ｘａｘｂが割り当てられて送出される。
【００６２】
手順１０： 交換ノード（Ｂ） １３は、ＴＣＰ／ＩＰコネクション確立不可メッセージを格納したＡＴＭ セルを受信すると、図１３（ａ） の状態にある呼管理テーブル３３に従って、そのセルを端末（Ａ） １６へ転送する。
【００６３】
手順１１： 端末（Ａ） １６は、ＴＣＰ／ＩＰコネクション確立不可メッセージを受信する。端末（Ａ） １６は、このメッセージを端末（Ｂ） １７から転送されてきたものであるとみなす。このメッセージは、端末（Ａ） １６内のＴＣＰ／ＩＰアプリケーションプログラムに渡され、ＴＣＰ／ＩＰアプリケーションプログラムは、このことにより、ＴＣＰ／ＩＰパケットの送出を停止する。なお、ＴＣＰ／ＩＰアプリケーションプログラムがＴＣＰ／ＩＰコネクションのために確立したＡＴＭ コネクションの切断を要求することもある。
【００６４】
手順１２〜１３： エージェント（Ｂ） １５は、端末（Ａ） １６との間のＡＴＭ コネクションの切断要求を交換ノード（Ｂ） １３内の呼管理制御部３２に送出する。このことにより、交換ノード（Ｂ） １３内の呼管理テーブル３３が書き換えられ、呼管理テーブル３３の状態は図１３（ｂ） に示すようになる。また、交換ノード（Ｂ） １３は、端末（Ａ） １６に対して、ＡＴＭ コネクション切断指示メッセージを送出する。
手順１４〜１５： 端末（Ａ） １６は、ＡＴＭ コネクション切断指示メッセージを受信すると、交換ノード（Ｂ） １３に対してＡＴＭ コネクション切断完了メッセージを送出する。このことにより、交換ノード（Ｂ） １３内の呼管理テーブル３３が書き換えられ、呼管理テーブル３３の状態は図１３（ｃ） に示すようになる。
上述した図８〜図１３の例では、宛先端末（アクセス先端末）を収容する交換ノードにおいてＴＣＰ／ＩＰコネクションによるアクセスを許容するか否かを判断する構成を説明したが、以下では、送信端末（アクセス元端末）を収容する交換ノードにおいてその判断を行う構成を説明する。
【００６５】
以下の説明では、図２において、端末（Ａ） １６から端末（Ｂ） １７へＴＣＰ／ＩＰプロトコルによるアクセス要求が発行されたときに、端末（Ａ） １６を収容する交換ノード（Ａ） １２においてそのアクセスを許容するか否かを判断する例を示す。尚、端末（Ｂ） １７に関するアクセス規制条件は、交換ノード（Ｂ） １３のファイアウォールテーブルに格納されており、現在、交換ノード（Ａ） １２のファイアウォールテーブルには格納されていないものとする。また、アクセス規制条件をファイアウォールテーブル登録する手順は、図６および図７を参照しながら説明した手順に従う。
【００６６】
ＴＣＰ／ＩＰプロトコルによるアクセスが許可されるときの手順を図１４を参照しながら説明する。
図１４に示すシーケンスは、後述する手順ａ〜ｆを除けば、基本的に図９に示したシーケンスと同じである。ただし、図１４に示すシーケンスでは、図９に示したシーケンスにおいて交換ノード（Ｂ） １３およびエージェント（Ｂ） １５が行っていた処理と同等の処理を、交換ノード（Ａ） １２およびエージェント（Ａ） １４が行う。
【００６７】
すなわち、図１４に示すシーケンスでは、端末（Ａ） １６が端末（Ｂ） １７に対してＴＣＰ／ＩＰプロトコルによりアクセス要求を発行すると、端末（Ａ） １６とエージェント（Ａ） １４との間にＡＴＭ コネクションが確立され、エージェント（Ａ） １４に発呼要求メッセージが転送される。そして、エージェント（Ａ） １４においてＴＣＰ／ＩＰプロトコルによるアクセスを許容するか否かを判断し、許容する場合にのみ、エージェント（Ａ） １４が端末（Ａ） １６と端末（Ｂ） １７との間にＡＴＭ コネクションを確立する。以下、手順ａ〜ｆについて説明する。
【００６８】
手順ａ： エージェント（Ａ） １４は、端末（Ｂ） １７への発呼要求（接続要求）メッセージを受け取ると、エージェント（Ａ） １４内のファイアウォールテーブル３５を検索して端末（Ｂ） １７に関するアクセス規制条件を探す。端末（Ｂ） １７に関するアクセス規制条件が格納されてない場合には、エージェント（Ａ） １４は、端末（Ｂ） １７に関するアクセス規制条件を要求するメッセージを送出する。
【００６９】
手順ｂ： 交換ノード（Ａ） １２は、手順ａにおいて送出されたメッセージを受け取ると、端末（Ｂ） １７のＡＴＭ アドレスより端末（Ｂ） １７を収容する交換ノード（交換ノード（Ｂ） １３）を認識し、交換ノード（Ｂ） １３に対して、端末（Ｂ） １７に関するアクセス規制条件を要求するメッセージを送出する。宛先ＡＴＭ アドレスからその宛先端末を収容する交換ノードを認識する手法は、通常の発呼手順と同じである。
【００７０】
手順ｃ〜ｄ： 交換ノード（Ｂ） １３は、上記メッセージを受け取ると、そのメッセージをエージェント（Ｂ） １５に渡す。エージェント（Ｂ） １５は、このメッセージに従い、端末（Ｂ） １７に関するアクセス規制条件を交換ノード（Ａ） １２に転送する。
【００７１】
手順ｅ〜ｆ： 交換ノード（Ａ） １２は、エージェント（Ｂ） １５から転送されてきた端末（Ｂ） １７に関するアクセス規制条件をエージェント（Ａ） １４に渡し、エージェント（Ａ） １４は、そのアクセス規制条件をエージェント（Ａ） １４内のファイアウォールテーブルに格納する。
【００７２】
上記手順ａ〜ｆにより、アクセス要求の送り元端末（端末（Ａ） １６）を収容する交換ノード（交換ノード（Ａ） １２）に、アクセス要求の着信先端末（端末（Ｂ） １７）に関するアクセス規制条件を登録できる。このように、アクセス要求の着信先端末に関するアクセス規制条件をいったんアクセス要求の送り元端末を収容する交換ノードに格納すれば、以降、その交換ノードにおいてアクセス要求を許容するか否かを判断できる。
【００７３】
図１５は、ＴＣＰ／ＩＰプロトコルによるアクセスが許可されない場合の手順を示す図である。手順ａ〜ｆは、図１４を参照しながら説明したシーケンスと同じであり、他の手順は、図１２を参照しながら説明したシーケンスと同じなので、図１５に関する詳細な説明は省略する。
【００７４】
なお、アクセス要求の送り元端末を収容する交換ノードにおいてアクセス要求を許容するか否かを判断した後には、他の交換ノードで同様の判断を行う必要はない。
【００７５】
上記図１４または図１５においては、アクセス要求の着信先端末に関するアクセス規制条件をアクセス要求の送り元端末を収容する交換ノードに格納する構成を説明したが、この場合、アクセス規制条件を次々をファイアウォールテーブル３５に書き込むことになる。ところが、ファイアウォールテーブル３５の規模を大きくするには実用的には限界がある。したがって、他の交換ノードから転送されてきたアクセス規制条件は、使用頻度の低いものをファイアウォールテーブルから削除する必用がある。
【００７６】
どのアクセス規制条件をファイアウォールテーブルから削除するのかは、参照回数および参照日時に従って決める。すなわち、ファイアウォールテーブル３５は、図１６に示すように、アクセス要求の着信先端末ごとに参照回数および参照日時を記録する領域を有し、参照されるごとにこれらのデータを更新する。そして、ファイアウォールテーブル３５が満杯の状態でさらに他の交換ノードからアクセス規制条件が転送されてきた場合には、たとえば、以下の条件を満たすアクセス規制条件を削除する。削除条件１：参照回数が１０回以下の端末に関するデータ。削除条件２：最後の参照した日時が１ヶ月以上前である端末に関するデータ。
【００７７】
このような構成とすることにより、ファイアウォールテーブルから使用頻度の低いアクセス規制条件が削除されるので、ファイアウォールテーブルの使用効率が向上する。
【００７８】
次に、本発明の他の実施形態について説明する。他の実施形態では、あるＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションが確立されている状況において、そのＡＴＭ コネクション上にさらに別のＴＣＰ／ＩＰコネクションを確立する場合を想定する。
【００７９】
以下では、端末（Ａ） １６と端末（Ｂ） １７との間に１２８ｋｂｐｓの帯域が割り当てられたＡＴＭ コネクションｋｋが確立されており、このＡＴＭ コネクションｋｋ上にＴＣＰ／ＩＰコネクションｍｍが確立されているものとする。ＴＣＰ／ＩＰコネクションｍｍは、簡易メール転送プロトコル（ポート番号＝２５）を提供する。このような状況において、端末（Ａ） １６が端末（Ｂ） １７にＴＣＰ／ＩＰプロトコルによる他のサービスを要求し、それに伴ってＡＴＭ コネクションｋｋ上にさらにＴＣＰ／ＩＰコネクションｎｎを確立する。この場合、ＡＴＭ コネクションｋｋの帯域を増加させる必用が生じる。
【００８０】
ＴＣＰ／ＩＰコネクションの追加が許可されるときの手順を図１７を参照しながら説明する。ここでは、端末（Ａ） １６が端末（Ｂ） １７に対して、ＨＴＴＰ（ポート番号＝８０）によるサービスを要求するものとする。この場合、追加されるＴＣＰ／ＩＰコネクションｎｎは、帯域として３８４ｋｂｐｓを要求し、それに伴ってＡＴＭ コネクションｋｋの帯域を１２８ｋｂｐｓから５１２ｋｂｐｓに増加させる必用があるものとする。
【００８１】
手順１： 端末（Ａ） １６は、端末（Ｂ） １７との間にＴＣＰ／ＩＰコネクションｎｎを確立するために、端末（Ｂ） １７に対して帯域予約要求メッセージを送出する。このメッセージは、発ＩＰアドレス「１３３．１６２．９６．ａ」、着ＩＰアドレス「１３３．１６２．９６．ｂ」およびポート番号「８０」を含んでいる。また、このメッセージは、制御セルであることを示すＶＰＩ／ＶＣＩ が割り当てられたＡＴＭ セルに格納されてＡＴＭ ネットワーク１１に送出される。
【００８２】
交換ノード（Ｂ） １３は、このＡＴＭ セルを受信すると、そのＶＰＩ／ＶＣＩ 値が制御セルを示しているので、情報フィールドを参照する。ここでは、情報フィールドに帯域予約要求メッセージが格納されており、このメッセージ内にＴＣＰ／ＩＰプロトコルに関する情報が設定されているので、交換ノード（Ｂ） １３の呼管理制御部３２は、このメッセージを端末（Ｂ） １７には転送せずに、エージェント（Ｂ） １５に渡す。
【００８３】
手順２〜３： エージェント１５は、端末（Ａ） １６と端末（Ｂ） １７との間の通信に対して設定されているファイアウォールテーブル３５を参照し、帯域予約要求メッセージに設定されていたＩＰアドレスおよびＴＣＰ ポート番号がアクセス可能であることを認識する。そして、エージェント１５は、端末（Ａ） １６から転送されてきた帯域予約要求メッセージを端末（Ｂ） １７へ転送する。
【００８４】
手順４〜５： 端末（Ｂ） １７は、帯域予約要求メッセージで指定されている帯域を確保できると判断すると、帯域確保通知を端末（Ａ） １６に対して送出する。このことにより、端末（Ｂ） １７と交換ノード（Ｂ） １３との間、交換ノード（Ｂ） １３と交換ノード（Ａ） １２との間、および交換ノード（Ａ） １２と端末（Ａ） １６との間において帯域が確保され、ＡＴＭ コネクションｋｋに５１２ｋｂｐｓの帯域が割り当てられる。そして、端末（Ａ） １６と端末（Ｂ） １７との間にＴＣＰ／ＩＰコネクションが確立され、このＴＣＰ／ＩＰコネクションを介してＨＴＴＰが提供される。
【００８５】
ＴＣＰ／ＩＰコネクションの追加が許可されないときの手順を図１８を参照しながら説明する。ここでは、端末（Ａ） １６が端末（Ｂ） １７に対して、ＴＥＬＮＥＴ（ポート番号＝２３）によるサービスを要求するものとする。
【００８６】
手順１： 手順１は、図１７に示したシーケンスの手順１と同じである。
手順２〜３： エージェント１５は、端末（Ａ） １６と端末（Ｂ） １７との間の通信に対して設定されているファイアウォールテーブル３５を参照し、帯域予約要求メッセージに設定されていたＩＰアドレスおよびＴＣＰ ポート番号がアクセス非許容能であると判断する。この場合、エージェント１５は、端末（Ａ） １６に対して帯域変更不可メッセージを送出する。
【００８７】
このように、図１７または図１８に示すシステムでは、同一ＡＴＭ コネクション上にＴＣＰ／ＩＰコネクションを追加してもよいかどうかをＡＴＭ ネットワーク１１内で判断するので、その判断をするためにＡＴＭ ネットワーク１１とアクセス要求先端末との間のパスを使用する必用がない。
【００８８】
従来のシステムでは、ＴＣＰ／ＩＰコネクションの追加が許可されない場合であっても、アクセス要求先端末とその端末を収容する交換ノードとの間でトラヒックが発生していたが、本実施形態では、そのトラヒックが発生しない。
【００８９】
次に、各交換ノードにおける処理フローチャートを示す。図１９は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その１）である。ここでは、着呼端末（着信先端末）を収容する交換ノードにファイアウォールを設ける場合を示す。
【００９０】
ステップＳ１では、発呼要求（接続要求）メッセージを受信する。ステップＳ２では、受信した発呼要求メッセージがＴＣＰ／ＩＰコネクション用なのかどうかを調べる。ＴＣＰ／ＩＰコネクション用であれば、ステップＳ３へ進み、ＴＣＰ／ＩＰコネクション用でなければステップＳ７へ進む。
【００９１】
ステップＳ３では、発呼要求メッセージがどこから転送されてきたのかを調べる。中継回線（ＮＮＩ によって規定される回線）から転送されてきた場合には、ステップＳ４へ進み、エージェントから転送されてきた場合には、ステップＳ６へ進み、端末回線（ＵＮＩ によって規定される回線）から転送されてきた場合には、ステップＳ７へ進む。
【００９２】
発呼要求メッセージが中継回線から転送されてくる場合とは、たとえば、図９の手順２、３に相当する。ステップＳ４では、発呼端末とエージェントとの間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ５では、発呼要求メッセージをエージェントに渡す。なお、ステップＳ４およびＳ５は、当該交換ノードが着呼端末を収容している場合に実行され、収容していない場合には、ステップＳ４およびＳ５の代わりにステップＳ７を実行する。
【００９３】
発呼要求メッセージがエージェントから転送されてくる場合とは、たとえば、図９の手順９、１０に相当する。ステップＳ６では、エージェントと着呼端末との間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ７では、発呼要求メッセージを着呼端末に転送する。
【００９４】
図２０は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その２）である。ここでも、着呼端末（着信先端末）を収容する交換ノードにファイアウォールを設ける場合を示す。
【００９５】
ステップＳ１１〜Ｓ１３は、発呼受付メッセージ（接続要求受付メッセージまたは呼受付メッセージ）を扱うが、基本的には、図１９で説明したステップＳ１〜Ｓ３と同じである。ステップＳ１３の判断において、発呼受付メッセージが端末回線から転送されてきた場合には、ステップＳ１４へ進み、中継回線から転送されてきた場合には、ステップＳ１５へ進む。
【００９６】
発呼受付メッセージが端末回線から転送されてくる場合とは、たとえば、図９の手順１１、１２に相当する。ステップＳ１４では、呼管理テーブルにおいて着呼端末とエージェントとの間にＡＴＭ コネクションが設定されているので、発呼受付メッセージをエージェントに転送する。
【００９７】
発呼受付メッセージが中継回線から転送されてくる場合とは、たとえば、図１４の手順１１、１２における交換ノード（Ｂ） １３の動作に相当する。ステップＳ１５では、受信した発呼受付メッセージを発呼端末に転送する。
【００９８】
図２１は、発呼端末とエージェントとの間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
ステップＳ２１では、発呼要求メッセージを受信する。ステップＳ２２では、受信した発呼受付メッセージを発呼端末に転送する。上記ステップの動作は、たとえば、図９の手順４に相当する。
【００９９】
図２２は、ＩＰパケット受信時の交換ノードの動作を説明するフローチャートである。
ステップＳ３１では、ＩＰパケット（ＴＣＰ／ＩＰパケット）を受信する。このＩＰパケットは、ＡＴＭ セルに格納されている。ステップＳ３２では、受信したＩＰパケットを呼管理テーブルに設定されている転送先ポートへ転送する。これらのステップの動作は、たとえば、図９の手順７に相当する。
【０１００】
図２３は、エージェントと着呼端末との間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
ステップＳ４１では、ＩＰパケット（ＴＣＰ／ＩＰパケット）を受信する。ステップＳ４２では、受信したＩＰパケットがＩＰコネクション（ＴＣＰ／ＩＰコネクション）の確立を要求するメッセージか否かを調べる。ＩＰコネクション確立要求メッセージであれば、ステップＳ４３へ進み、それ以外の場合は、受信したＩＰパケットをステップＳ５３において廃棄する。
【０１０１】
ステップＳ４３では、着呼端末に関するファイアウォールテーブルを持っているかどうかを調べる。持っている場合には、ステップＳ４５へ進み、持っていない場合には、ステップＳ４４において、着呼端末を収容する交換ノードから着呼端末に関するファイアウォールテーブルを転送してもらう。なお、ステップＳ４４は、たとえば、図１４の手順ａ〜ｆに相当する。
【０１０２】
ステップＳ４５では、受信したＩＰコネクション確立要求メッセージを許容するか否かを判断する。許容する場合（規制対象でない場合）には、ステップＳ４６へ進み、許容しない場合（規制対象の場合）には、ステップＳ５１へ進む。
【０１０３】
ステップＳ４６では、発呼要求メッセージを着呼端末へ転送する。ステップＳ４７では、着呼端末から発呼受付メッセージを受信する。ステップＳ４８では、ステップＳ４１で受信したＩＰコネクション確立要求メッセージを着呼端末へ転送する。ステップＳ４９では、エージェントを介することなく発呼端末と着呼端末との間を接続するＡＴＭ コネクションを確立するように当該交換ノード内の呼管理制御部に要求する。上記ステップＳ４６〜Ｓ４８は、たとえば、図９の手順９〜１４に相当し、ステップＳ４９は、図９の手順１５に相当する。
【０１０４】
ステップＳ５０では、ステップＳ４９の要求により、呼管理テーブルを書き換える。
ステップＳ５１では、発呼端末に対して、ＡＴＭ コネクション切断要求メッセージを転送する。ステップＳ５２では、発呼端末からＡＴＭ コネクション切断完了メッセージを受信する。これらのステップは、たとえば、図１２の手順１３、１４に相当する。
【０１０５】
図２４は、帯域予約要求メッセージを受信した際の交換ノード内の呼管理制御部の動作を説明するフローチャートである。ここでは、着呼端末（着信先端末）を収容する交換ノードにファイアウォールを設ける場合を示す。
【０１０６】
ステップＳ６１では、帯域予約要求メッセージを受信する。ステップＳ６２では、受信した上記帯域予約要求メッセージがＴＣＰ／ＩＰコネクション用なのかどうかを調べる。ＴＣＰ／ＩＰコネクション用であれば、ステップＳ６３へ進み、ＴＣＰ／ＩＰコネクション用でなければステップＳ６５へ進む。
【０１０７】
ステップＳ６３では、帯域予約要求メッセージがどこから転送されてきたのかを調べる。中継回線から転送されてきた場合は、ステップＳ４４へ進み、エージェントまたは端末回線から転送されてきた場合には、ステップＳ６５へ進む。
【０１０８】
帯域予約要求メッセージが中継回線から転送されてくる場合とは、たとえば、図１７の手順１に相当する。ステップＳ６４では、帯域予約要求メッセージをエージェントに渡す。なお、ステップＳ６４は、当該交換ノードが着呼端末を収容している場合に実行され、収容していない場合には、ステップＳ６４の代わりにステップＳ６６を実行する。
【０１０９】
帯域予約要求メッセージがエージェントから転送されてくる場合とは、たとえば、図１７の手順３に相当し、端末回線から転送されてくる場合とは、例えば、図１７の手順１における交換ノード（Ａ） １２の動作に相当する。ステップＳ６５では、帯域予約要求メッセージに従って帯域を確保する。ステップＳ６６では、帯域予約要求メッセージを着呼端末へ転送する。
【０１１０】
図２５は、帯域予約完了メッセージを受信した際の交換ノードの動作を説明するフローチャートである。
ステップＳ７１では、帯域予約完了メッセージを受信する。ステップＳ７２では、受信した帯域予約完了メッセージを発呼端末に転送する。これらのステップは、たとえば、図１７の手順４に相当する。
【０１１１】
図２６は、帯域予約要求メッセージを受信した際のエージェントの動作を説明するフローチャートである。
ステップＳ８１では、帯域予約要求メッセージを受信する。ステップＳ８２では、受信した帯域予約要求を許容するか否かを判断する。許容する場合（規制対象でない場合）は、ステップＳ８３へ進み、許容しない場合（規制対象の場合）には、ステップＳ８４へ進む。
【０１１２】
ステップＳ８３では、帯域予約要求メッセージを着呼端末へ転送する。ステップＳ８４では、帯域予約不可メッセージを発呼端末へ転送する。なお、ステップＳ８３は、たとえば、図１７の手順３に相当し、ステップＳ８４は、図１８の手順３に相当する。
【０１１３】
図２７は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その３）である。ここでは、発呼端末を収容する交換ノードにファイアウォールを設ける場合を示す。
【０１１４】
ステップＳ９１では、発呼要求（接続要求）メッセージを受信する。ステップＳ９２では、受信した発呼要求メッセージがＴＣＰ／ＩＰコネクション用なのかどうかを調べる。ＴＣＰ／ＩＰコネクション用であれば、ステップＳ９３へ進み、ＴＣＰ／ＩＰコネクション用でなければステップＳ９７へ進む。
【０１１５】
ステップＳ９３では、発呼要求メッセージがどこから転送されてきたのかを調べる。端末回線から転送されてきた場合には、ステップＳ９４へ進み、エージェントから転送されてきた場合には、ステップＳ９６へ進み、中継回線から転送されてきた場合には、ステップＳ９７へ進む。
【０１１６】
発呼要求メッセージが端末回線から転送されてくる場合とは、たとえば、図１４の手順２、３に相当する。ステップＳ９４では、発呼端末とエージェントとの間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ９５では、発呼要求メッセージをエージェントに渡す。
【０１１７】
発呼要求メッセージがエージェントから転送されてくる場合とは、たとえば、図１４の手順９、１０に相当する。ステップＳ９６では、エージェントと着呼端末との間のＡＴＭ コネクションを呼管理テーブルに登録する。ステップＳ９７では発呼要求メッセージを着呼端末に転送する。
【０１１８】
図２８は、発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その４）である。ここでも、発呼端末を収容する交換ノードにファイアウォールを設ける場合を示す。
【０１１９】
ステップＳ１０１〜Ｓ１０３は、発呼受付メッセージ（接続要求受付メッセージまたは呼受付メッセージ）を扱うが、基本的には、図２７で説明したステップＳ９１〜Ｓ９３と同じである。ステップＳ１０３の判断において、発呼受付メッセージが中継回線から転送されてきた場合には、ステップＳ１０４へ進み、端末回線から転送されてきた場合には、ステップＳ１０５へ進む。
【０１２０】
発呼受付メッセージが中継回線から転送されてくる場合とは、たとえば、図１４の手順１１、１２に相当する。ステップＳ１０４では、呼管理テーブルにおいて着呼端末とエージェントとの間にＡＴＭ コネクションが設定されているので、発呼受付メッセージをエージェントに転送する。
【０１２１】
発呼受付メッセージが端末回線から転送されてくる場合とは、たとえば、図１４の手順１１、１２における交換ノード（Ｂ） １３の動作に相当する。ステップＳ１０５では、受信した発呼受付メッセージを発呼端末に転送する。
【０１２２】
なお、上述の実施形態では、ファイアウォールテーブルに着ＩＰアドレスおよびＴＣＰ のポート番号を設定してそれらによってアクセス規制条件を決めていたが、図２９（ａ） に示すように、発ＩＰアドレスを登録してもよい。同図に示す例では、ＦＴＰ （ファイル転送プロトコル）に対して、発ＩＰアドレスが設定されている。この場合、このファイアウォールテーブルに登録されているＩＰアドレスを持った端末のみがＦＴＰ サービスを受けることができる。
【０１２３】
また、図２９（ｂ） に示すように、ファイアウォールテーブルにパスワードを設定してもよい。この場合、パスワードを知っているユーザのみがサービスを受けることができる。すなわち、ＡＴＭ ネットワークにおいてＴＣＰ／ＩＰアクセスに関するユーザ認証を行うことができる。
【０１２４】
また、上述の実施形態では、エージェントを交換ノード内に設けた仮想端末として説明したが、図３０（ａ） に示すように、エージェントを交換ノードと独立に設ける構成としてもよい。この場合、エージェント３４は、交換ノード３０に接続されたサーバコンピュータである。エージェント３４と交換ノード３０との間は、ＰＶＣ （パーマネント仮想チャネル）またはＳＶＣ （スイッチド仮想チャネル）で接続する。
【０１２５】
さらに、上述の実施形態では、各交換ノードごとにエージェントを設けていたが、図３０（ｂ） に示すように、複数の交換ノード３０−１〜３０−３に対して１つのエージェント４１を設けるようにしてもよい。
【０１２６】
上述の実施例では、ＩＰ ｏｖｅｒ ＡＴＭ システムの一実施形態として、ＴＣＰ／ＩＰプロトコルのトラヒックをＡＴＭ ネットワークを介して転送する構成を示したが、本発明は、ＴＣＰ プロトコル以外の通信プロトコルにも適用可能である。たとえば、本発明をＵＤＰ （Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｃｏｌ ）に適用可能である。この場合、ファイアウォールテーブルには、ＩＰアドレスおよびＵＤＰ のポート番号を登録し、それらの情報に従ってアクセスを規制する。
【０１２７】
ところで、コンピュータネットワークの世界では、イーサネット、トークンリング、ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）などのＬＡＮ が広く普及している。ＬＡＮ エミュレーションは、これらのＬＡＮ データをＡＴＭ ネットワークを介して転送する技術である。本発明は、ＩＰ ｏｖｅｒ ＡＴＭ システムだけでなく、ＬＡＮ エミュレーションシステムにも適用可能である。
【０１２８】
図３１は、本発明をＬＡＮ エミュレーションシステムに適用した場合の構成図である。同図に示す例では、ＡＴＭ ネットワーク１１を介してＬＡＮ５１とＬＡＮ５２とを接続する構成である。
【０１２９】
ＬＡＮ の代表的な通信プロトコルとしては、ＴＣＰ／ＩＰの他に、例えば、ノベル社のＮｅｔ Ｗａｒｅ（登録商標）で採用されているＩＰＸ／ＳＰＸ 、マイクロソフト社のＷｉｎｄｏｗｓ ９５、Ｗｉｎｄｏｗｓ ＮＴ（共に商標）で採用されているＮｅｔ ＢＥＵＩ、アップルコンピュータ社のＭａｃｉｎｔｏｓｈ （商標）で使用されているＡｐｐｌｅＴａｌｋ 等が知られている。
【０１３０】
ＬＡＮ は、基本的に、ＭＡＣ （Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを用いてデータを転送するが、上記の通信プロトコルでは、各プロトコル毎に独自のアドレス体系を有している。たとえば、ＩＰＸ／ＳＰＸ では、ＩＰＸ アドレスを有し、データを転送するときには、図３２（ａ） に示すように、ＩＰＸ アドレス（発アドレスおよび着アドレス）が設定されたＩＰＸ フレームをＭＡＣ フレームの中に格納する。そして、ＡＴＭ ネットワークを介して通信を行う場合には、このフレームをＡＴＭ セルに格納してネットワークに送出する。
【０１３１】
ＡＴＭ ネットワーク１１内の交換ノードには、図３２（ｂ） に示すようなファイアウォールテーブルを設ける。このように、ＩＰＸ アドレス毎にアクセス規制条件を設定すれば、発端末（アクセス要求元端末）と着端末（アクセス要求先端末）との間にＡＴＭ コネクションを確立することなく、着端末にデータを転送するか否かすなわちアクセスを許容するか否かを判断できる。
【０１３２】
上述した実施例の説明において、図２に示すように、ＡＴＭ ネットワークに直接接続される端末１６、１７間の通信では、アクセス要求が許容されれば、端末１６と端末１７との間にＡＴＭ コネクションが確立される。ところが、図３１に示すように、ＬＡＮ５１、５２間の通信では、ルータ５３とルータ５４との間にＡＴＭ コネクションが確立される。たとえば、ＬＡＮ５１に収容される端末５５からＬＡＮ５２に収容される端末５６にアクセスする際には、ＡＴＭ ネットワーク１１内に設けられたファイアウォール機能によりそのアクセスを許容するか否かを判断し、許容する場合には、ルータ５３とルータ５４との間にＡＴＭ コネクションを確立する。このことは、ＬＡＮ エミュレーションだけでなく、ＩＰ ｏｖｅｒ ＡＴＭ においても同様である。
【０１３３】
ＬＡＮ は、基本的に、通信相手との間にコネクションを確立することなくデータを送信するコネクションレス型通信である。一方、ＡＴＭ は、送受信間でコネクションを確立した後にそのコネクションを介してデータを転送するコネクション型通信である。従って、ＬＡＮ エミュレーションや、ＵＤＰ プロトコルによるトラヒックをＡＴＭ ネットワークを介して転送する技術は、コネクションレス型通信のトラヒックをコネクション型通信のネットワークを介して転送する方式と言える。換言すれば、ＡＴＭ ネットワークは、コネクション型通信のネットワークの一形態である。
【０１３４】
【発明の効果】
ＩＰ ｏｖｅｒ ＡＴＭ またはＬＡＮ エミュレーションにおいて、ＡＴＭ ネットワーク内にファイアウォールを設け、そのファイアウォールでアクセス要求を許容するか否かを判断するので、その判断のために着信先端末とその着信先端末を収容する交換ノードとの間にＡＴＭ コネクションを確立する必要がないので、ネットワーク資源の無駄遣いを防げる。また、着信先端末との間にコネクションを確立することなくアクセスが許容されるか否かの判断がされるので、その判断のために課金が発生しない。
【図面の簡単な説明】
【図１】本発明の原理を説明する図である。
【図２】本実施形態の全体システム構成図である。
【図３】ＴＣＰ／ＩＰパケットとＡＴＭ セルとの分解・組立を示す図である。
【図４】ＡＴＭ セルの構成図であり、（ａ） は、ＵＮＩ におけるフォーマット、（ｂ） は、ＮＮＩ におけるフォーマットである。
【図５】本実施形態のファイアウォールシステムの構成図である。
【図６】交換ノードへアクセス規制条件を登録する方法を説明する図である。
【図７】交換ノードへアクセス規制条件を登録するシーケンスを示す図である。
【図８】（ａ） は、ファイアウォールテーブルの例であり、（ｂ） および（ｃ） は、受信したＴＣＰ／ＩＰパケットの例である。
【図９】アクセスが許容される場合のシーケンスを示す図である。
【図１０】発呼要求メッセージをＡＴＭ セルに格納して転送することを模式的に示す図である。
【図１１】（ａ） 〜（ｃ） は、図９に対応する呼管理テーブルの例である。
【図１２】アクセスが許容されない場合のシーケンスを示す図である。
【図１３】（ａ） 〜（ｃ） は、図１２に対応する呼管理テーブルの例である。
【図１４】アクセス要求元端末を収容する交換ノードにおいてそのアクセスを許容するか否かを判断する場合のシーケンスを示す図（その１）である。
【図１５】アクセス要求元端末を収容する交換ノードにおいてそのアクセスを許容するか否かを判断する場合のシーケンスを示す図（その２）である。
【図１６】ファイアウォールテーブルから使用頻度の低い情報を削除する構成を説明する図である。
【図１７】ＴＣＰ／ＩＰコネクションの追加が許可されるときのシーケンスを示す図である。
【図１８】ＴＣＰ／ＩＰコネクションの追加が許可されない時のシーケンスを示す図である。
【図１９】発呼端末とエージェントとの間またはエージェントと着信先端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その１）である。
【図２０】発呼端末とエージェントとの間またはエージェントと着信先端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その２）である。
【図２１】発呼端末とエージェントとの間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
【図２２】ＩＰパケット受信時の交換ノードの動作を説明するフローチャートである。
【図２３】エージェントと着呼端末との間のＡＴＭ コネクションを確立する際のエージェントの動作を説明するフローチャートである。
【図２４】帯域予約要求メッセージを受信したときの交換ノード内の呼管理制御部の動作を説明するフローチャートである。
【図２５】帯域予約完了メッセージを受信した際の交換ノード内の動作を説明するフローチャートである。
【図２６】帯域予約要求メッセージを受信した際のエージェントの動作を説明するフローチャートである。
【図２７】発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その３）である。
【図２８】発呼端末とエージェントとの間、またはエージェントと着呼端末との間のＡＴＭ コネクションを確立する際の交換ノード内の呼管理制御部の動作を説明するフローチャート（その４）である。
【図２９】（ａ） および（ｂ） は、ファイアウォールテーブルの例である。
【図３０】（ａ） および（ｂ） は、エージェントの構成例を示す例である。
【図３１】本発明をＬＡＮ エミュレーションシステムに適用した場合の構成図である。
【図３２】（ａ） は、ＬＡＮ プロトコルのフレームを説明する図であり、（ｂ） は、ＬＡＮ エミュレーションシステムにおけるファイアウォールテーブルの例を示す図である。
【図３３】ＩＰ ｏｖｅｒ ＡＴＭ システムにおいてファイアウォールを設ける場合の従来の構成例を示す図である。
【符号の説明】
１ 交換ノード
２ エージェントユニット
３ コネクション型通信ネットワーク
１１ ＡＴＭ ネットワーク
１２、１３ 交換ノード
１４、１５ エージェント
１６、１７ 端末（ＤＴＥ： Ｄａｔａ Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）
３０ 交換ノード
３０−１〜３０−３ 交換ノード
３１ ＡＴＭ スイッチ
３２ 呼管理制御部
３３ 呼管理テーブル
３４、４１ エージェント
３５ ファイアウォールテーブル
５１、５２ ＬＡＮ
５３、５４ 端末
５５、５６ ルータ装置
Claims (25)
- 第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワークを介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制するファイアウォール方式であって、
固定長パケットを交換するとともに、受信した固定長パケットのなかから上記第２のプロトコルによる第１の端末から第２の端末へのアクセス要求を含んだ固定長パケットを抽出する交換ノードと、
上記ネットワーク内に設けられ、上記交換ノードによって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断するエージェントユニットと、を有し、
上記エージェントユニットは、アクセスを許容する場合は、上記第１の端末またはその第１の端末を収容する端末と上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立し、アクセスを許容しない場合には、上記交換ノードと上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立することなく上記アクセス要求を拒絶する
ことを特徴とするファイアウォール方式。 - 上記エージェントユニットは、上記第１の端末から上記第２の端末へのアクセス要求が発行されると、上記第２の端末の代わりに上記第１の端末に対して応答する請求項１に記載のファイアウォール方式。
- 上記エージェントユニットは、上記第２の端末に関する上記第２のプロトコルによるアクセス規制条件を格納したファイアウォールテーブルを有する請求項１に記載のファイアウォール方式。
- 上記エージェントユニットは、上記第１のプロトコルによるコネクションを介して転送されてくる指示に従って上記ファイアウォールテーブルの内容を変更する請求項３に記載のファイアウォール方式。
- 上記交換ノードは、上記第２の端末を収容する交換機である請求項１に記載のファイアウォール方式。
- 上記交換ノードは、上記第１の端末を収容する交換機である請求項１に記載のファイアウォール方式。
- 上記交換ノードは、上記第２のプロトコルによるアクセス要求を含んだ固定長パケットを受信すると、その固定長パケットを上記エージェントユニットへ転送する請求項１に記載のファイアウォール方式。
- 上記エージェントユニットは、上記第２のプロトコルによるアクセス要求を含んだ固定長パケットを受信すると、上記第１の端末またはその第１の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立する請求項７に記載のファイアウォール方式。
- 上記エージェントユニットは、上記アクセス要求を許容しない場合には、上記第１の端末に対して上記アクセス要求が認められないことを通知する請求項８に記載のファイアウォール方式。
- 上記エージェントユニットは、上記アクセス要求を許容する場合には、上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立する請求項８に記載のファイアウォール方式。
- 上記エージェントユニットは、上記第１の端末またはその第１の端末を収容する端末と当該エージェントユニットの間に確立したコネクションおよび上記第２の端末またはその第２の端末を収容する端末と当該エージェントユニットの間に確立したコネクションを、上記第１の端末またはその第１の端末を収容する端末と上記第２の端末またはその第２の端末を収容する端末との間に確立される上記第１のプロトコルによるコネクションに変更するように、上記交換ノードの設定を変更する請求項１０に記載のファイアウォール方式。
- 第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワークを介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制するファイアウォール方式であって、
固定長パケットを交換するとともに、受信した固定長パケットのなかから上記第２のプロトコルによる第１の端末から第２の端末へのアクセス要求を含んだ固定長パケットを抽出する複数の交換ノードと、
上記複数の交換ノードの各々に対して設けられ、対応する交換ノードに収容される端末に関する上記第２のプロトコルによるアクセス規制条件を格納し、対応する交換ノードによって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断する複数のエージェントユニットと、を有し、
上記第２の端末を収容する交換ノードに対応するエージェントユニットから上記第１の端末を収容する交換ノードに対応するエージェントユニットへ上記第２の端末に関するアクセス規制条件を転送し、上記第１の端末を収容する交換ノードに対応するエージェントユニットにおいて上記アクセスを許容するか否かを判断するファイアウォール方式。 - 上記第１の端末を収容する交換ノードに対応するエージェントユニットにおいて、参照時刻が最も古いアクセス規制条件を廃棄する請求項１２に記載のファイアウォール方式。
- 上記第１の端末を収容する交換ノードに対応するエージェントユニットにおいて、参照回数が所定数よりも少ないアクセス規制条件を廃棄する請求項１２に記載のファイアウォール方式。
- 上記交換ノードは、第１の端末と第２の端末との間に上記第１のプロトコルによるコネクションを確立した後、受信した固定長パケットのなかから上記第２のプロトコルによる第１の端末から第２の端末へのアクセスのために上記コネクションの帯域変更を要求する情報を含んだ固定長パケットを抽出し、
上記エージェントユニットは、上記交換ノードによって抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断する、
ことを特徴とする請求項１に記載のファイアウォール方式。 - 上記エージェントユニットは、上記アクセス要求を許容しない場合には、上記第１の端末に対して上記帯域変更要求が認められないことを通知する請求項１５に記載のファイアウォール方式。
- 上記エージェントユニットは、上記アクセス要求を許容する場合には、上記第２の端末に対して上記帯域変更要求を含んだ固定長パケットを転送する請求項１５に記載のファイアウォール方式。
- IP over ATM プロトコルを用いた通信システムにおけるファイアウォール方式であって、
少なくともアクセス先のIPアドレスに従ってそのアクセスを許容するか否かを判断する機能をATM ネットワーク内の所定の装置に持たせ、
ATM ネットワークと上記アクセス先との間にATM コネクションを確立することなく上記アクセスを許容するか否かを判断し、
アクセスを許容する場合は、上記アクセスを要求した第１の端末またはその第１の端末を収容する端末と上記アクセスの要求先である第２の端末またはその第２の端末を収容する端末との間に ATM コネクションを確立し、アクセスを許容しない場合には、上記 ATM ネットワーク内の交換ノードと上記第２の端末またはその第２の端末を収容する端末との間に ATM コネクションを確立することなく上記アクセス要求を拒絶する
ことを特徴とするファイアウォール方式。 - アクセス先のIPアドレスおよびアクセス先のTCP ポート番号を用いて上記アクセスを許容するか否かを判断する請求項１８に記載のファイアウォール方式。
- コネクションレス型通信のトラヒックをコネクション型通信ネットワークを介して転送するシステムにおいて上記コネクションレス型通信のトラヒックを規制するファイアウォール方式であって、
少なくとも上記コネクションレス型通信の通信プロトコルによって規定されるアドレス体系のアクセス先アドレスに従ってそのアクセスを許容するか否かを判断する機能を上記コネクション型通信ネットワーク内の所定の装置に持たせ、
該ネットワークと上記アクセス先との間にコネクションを確立することなく上記アクセスを許容するか否かを判断し、
アクセスを許容する場合は、上記アクセスを要求した第１の端末またはその第１の端末を収容する端末と上記アクセスの要求先である第２の端末またはその第２の端末を収容する端末との間に上記コネクション型通信の通信プロトコルによるコネクションを確立し、アクセスを許容しない場合には、上記コネクション型通信ネットワーク内の交換ノードと上記第２の端末またはその第２の端末を収容する端末との間に上記コネクション型通信の通信プロトコルによるコネクションを確立することなく上記アクセス要求を拒絶する
ことを特徴とするファイアウォール方式。 - 第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワークを介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制するファイアウォールとして機能するエージェントユニットであって、
交換ノードから上記第２のプロトコルによる第１の端末から第２の端末へのアクセス要求を含んだ固定長パケットを受信する受信手段と、
該受信手段が受信した固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断する判断手段と、
アクセスを許容する場合にのみ上記ネットワークと上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立するコネクション設定手段と、を有し、
上記コネクション設定手段は、アクセスを許容する場合は、上記第１の端末またはその第１の端末を収容する端末と上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立し、アクセスを許容しない場合には、上記交換ノードと上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立することなく上記アクセス要求を拒絶する
ことを特徴とするエージェントユニット。 - 請求項１に記載のファイアウォール方式において第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワークに収容される端末装置であって、
上記ネットワーク内に設けられる第２のプロトコルによるアクセスに対する規制条件を格納したファイアウォールテーブルを格納する装置との間に上記第１のプロトコルによるコネクションを確立する手段と、
該コネクションを介して上記ファイアウォールテーブルの内容を変更する指示を送出する手段と、
を有する端末装置。 - 第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワークを介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制するファイアウォール方法であって、
交換ノードにおいて受信した固定長パケットから上記第２のプロトコルによる第１の端末から第２の端末へのアクセス要求を含んだ固定長パケットを抽出するステップと、
上記抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断するステップと、
アクセスを許容する場合は、上記第１の端末またはその第１の端末を収容する端末と上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクションを確立し、アクセスを許容しない場合には、上記交換ノードと上記第２の端末またはその第２の端末を収容する端末との間に上記第１のプロトコルによるコネクショ ンを確立することなく上記アクセス要求を拒絶するステップ、
を有するファイアウォール方法。 - 第１のプロトコルに従って固定長パケットを交換するコネクション型のネットワークを介して第２のプロトコルに従った通信のトラヒックを転送するシステムにおいて上記第２のプロトコルに従った通信を規制するファイアウォール方法であって、
第１の端末から第２の端末への上記第２のプロトコルによるアクセス要求が発行された際に、上記第１の端末を収容する交換ノードにおいて上記アクセス要求を含んだ固定長パケットを抽出するステップと、
上記第１の端末を収容する交換ノードに上記第２の端末に関するアクセス規制条件が登録されているか否かを判断するステップと、
登録されていた場合には、その登録されているアクセス規制条件に従って上記アクセス要求を許容するか否かを判断するステップと、
登録されていない場合には、他の交換ノードに上記第２の端末に関するアクセス規制条件を転送してくれるよう要求し、その転送されてきたアクセス規制条件に従って上記アクセス要求を許容するか否かを判断するステップと、
を有するファイアウォール方法。 - 上記第１の端末と第２の端末との間に上記第１のプロトコルによるコネクションが確立された後、上記第２のプロトコルによる第１の端末から第２の端末へのアクセスのために上記コネクションの帯域変更を要求する情報を含んだ固定長パケットを抽出するステップと、
上記抽出された固定長パケットに格納されている情報に基づいて上記第２の端末へのアクセスを許容するか否かを判断するステップと、
アクセスを許容する場合にのみ、上記帯域変更要求を上記第２の端末に転送するステップと、
をさらに有する請求項２３に記載のファイアウォール方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP01702797A JP3591753B2 (ja) | 1997-01-30 | 1997-01-30 | ファイアウォール方式およびその方法 |
| US09/015,826 US6353856B1 (en) | 1997-01-30 | 1998-01-29 | Firewall system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP01702797A JP3591753B2 (ja) | 1997-01-30 | 1997-01-30 | ファイアウォール方式およびその方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10215248A JPH10215248A (ja) | 1998-08-11 |
| JP3591753B2 true JP3591753B2 (ja) | 2004-11-24 |
Family
ID=11932524
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP01702797A Expired - Fee Related JP3591753B2 (ja) | 1997-01-30 | 1997-01-30 | ファイアウォール方式およびその方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6353856B1 (ja) |
| JP (1) | JP3591753B2 (ja) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6961748B2 (en) * | 1998-10-27 | 2005-11-01 | Murrell Stephen J | Uniform network access |
| US7136387B2 (en) * | 1999-08-09 | 2006-11-14 | Mci, Llc | Method of and system for providing quality of service in IP telephony |
| US6832321B1 (en) | 1999-11-02 | 2004-12-14 | America Online, Inc. | Public network access server having a user-configurable firewall |
| CA2300066A1 (en) * | 2000-03-03 | 2001-09-03 | Paul A. Ventura | High speed, high security remote access system |
| FR2812491B1 (fr) * | 2000-07-25 | 2003-01-10 | France Telecom | Dispositif de controle d'acces entre des reseaux atm |
| DE10046240A1 (de) * | 2000-09-19 | 2002-03-28 | Deutsche Telekom Ag | Verfahren zur Messung der unidirektionalen Übertragungseigenschaften, wie Paketlaufzeit, Laufzeitschwankungen und der hieraus ableitbaren Ergebnisse, in einem Telekommunikationsnetz |
| KR20030011080A (ko) * | 2001-03-16 | 2003-02-06 | 마쯔시다덴기산교 가부시키가이샤 | 방화벽 설정 방법 및 장치 |
| KR20030016733A (ko) * | 2001-08-21 | 2003-03-03 | 아르파(주) | 통신 시스템에서의 동적 서비스 보호 방법 |
| FI20012339A0 (fi) * | 2001-11-29 | 2001-11-29 | Stonesoft Corp | Palomuurien välillä siirtyvien yhteyksien käsittely |
| JP3988475B2 (ja) * | 2002-02-05 | 2007-10-10 | ソニー株式会社 | 送信装置、受信装置およびそれらの方法 |
| CN100452715C (zh) * | 2002-10-01 | 2009-01-14 | 华为技术有限公司 | 一种智能终端管理方法 |
| WO2005029337A1 (ja) * | 2003-09-22 | 2005-03-31 | Japan Media Systems Corp. | データ通信システム、プログラム及び記録媒体 |
| US7447211B1 (en) * | 2004-03-23 | 2008-11-04 | Avaya Inc. | Method and apparatus of establishing a communication channel using protected network resources |
| EP1840748A4 (en) | 2004-12-20 | 2012-08-22 | Fujitsu Ltd | RELAY PROGRAM, COMMUNICATION PROGRAM AND FIREWALL SYSTEM |
| JP4584809B2 (ja) * | 2005-10-04 | 2010-11-24 | パナソニック株式会社 | 制御装置及び被制御装置 |
| US20070171825A1 (en) * | 2006-01-20 | 2007-07-26 | Anagran, Inc. | System, method, and computer program product for IP flow routing |
| US8547843B2 (en) * | 2006-01-20 | 2013-10-01 | Saisei Networks Pte Ltd | System, method, and computer program product for controlling output port utilization |
| EP2807796B1 (en) | 2012-01-27 | 2021-10-20 | Nokia Solutions and Networks Oy | Session termination in a mobile packet core network |
| JP2016154389A (ja) * | 2016-05-18 | 2016-08-25 | ノキア ソリューションズ アンド ネットワークス オサケユキチュア | 移動パケットコアネットワークにおけるセッション終了 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5138659A (en) * | 1991-05-02 | 1992-08-11 | General Instrument Corporation | Conversion of television signal formats with retention of common control data stream |
| US5379297A (en) * | 1992-04-09 | 1995-01-03 | Network Equipment Technologies, Inc. | Concurrent multi-channel segmentation and reassembly processors for asynchronous transfer mode |
| JPH07107990B2 (ja) * | 1992-11-12 | 1995-11-15 | 日本電気株式会社 | Ａｔｍ方式による送信装置及び通信システム |
| US5452297A (en) * | 1993-12-20 | 1995-09-19 | At&T Corp. | Access switches for large ATM networks |
| US5528592A (en) * | 1994-01-27 | 1996-06-18 | Dsc Communications Corporation | Method and apparatus for route processing asynchronous transfer mode cells |
| JPH07264207A (ja) | 1994-03-24 | 1995-10-13 | Hitachi Ltd | Ａｔｍ交換網へのデータ端末接続方法 |
| US5796829A (en) * | 1994-09-09 | 1998-08-18 | The Titan Corporation | Conditional access system |
| US5483527A (en) * | 1994-12-21 | 1996-01-09 | At&T Corp. | Terminal adapter for interfacing an ATM network with a STM network |
| US5600644A (en) * | 1995-03-10 | 1997-02-04 | At&T | Method and apparatus for interconnecting LANs |
| US5581552A (en) * | 1995-05-23 | 1996-12-03 | At&T | Multimedia server |
| US5774670A (en) * | 1995-10-06 | 1998-06-30 | Netscape Communications Corporation | Persistent client state in a hypertext transfer protocol based client-server system |
| US5732078A (en) * | 1996-01-16 | 1998-03-24 | Bell Communications Research, Inc. | On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network |
| US5892924A (en) * | 1996-01-31 | 1999-04-06 | Ipsilon Networks, Inc. | Method and apparatus for dynamically shifting between routing and switching packets in a transmission network |
| US5898830A (en) * | 1996-10-17 | 1999-04-27 | Network Engineering Software | Firewall providing enhanced network security and user transparency |
| JP3131137B2 (ja) * | 1996-02-28 | 2001-01-31 | 株式会社日立製作所 | バーチャルネットワークシステム |
| US5878043A (en) * | 1996-05-09 | 1999-03-02 | Northern Telecom Limited | ATM LAN emulation |
| US5950195A (en) * | 1996-09-18 | 1999-09-07 | Secure Computing Corporation | Generalized security policy management system and method |
| US5828844A (en) * | 1996-10-08 | 1998-10-27 | At&T Corp. | Internet NCP over ATM |
| US5896382A (en) * | 1996-11-19 | 1999-04-20 | Scientific-Atlanta, Inc. | Method and apparatus for communicating information between a headend and subscriber over a wide area network |
| US5903559A (en) * | 1996-12-20 | 1999-05-11 | Nec Usa, Inc. | Method for internet protocol switching over fast ATM cell transport |
| US5909430A (en) * | 1996-12-31 | 1999-06-01 | Northern Telecom Limited | Address assignment in an ATM switched network |
| JP3457493B2 (ja) * | 1997-03-18 | 2003-10-20 | 富士通株式会社 | Ａｒｐサーバ |
| JP3394430B2 (ja) * | 1997-09-09 | 2003-04-07 | 富士通株式会社 | ネットワークシステム及び交換機 |
-
1997
- 1997-01-30 JP JP01702797A patent/JP3591753B2/ja not_active Expired - Fee Related
-
1998
- 1998-01-29 US US09/015,826 patent/US6353856B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6353856B1 (en) | 2002-03-05 |
| JPH10215248A (ja) | 1998-08-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3591753B2 (ja) | ファイアウォール方式およびその方法 | |
| JP3478218B2 (ja) | エッジノード交換機と交換機 | |
| US5835710A (en) | Network interconnection apparatus, network node apparatus, and packet transfer method for high speed, large capacity inter-network communication | |
| US6021263A (en) | Management of ATM virtual circuits with resources reservation protocol | |
| JP3338365B2 (ja) | パケット交換トラヒックを転送するための改良型システム | |
| EP1110349B1 (en) | Atm virtual private networks | |
| EP1215857B1 (en) | System and method for operating a communication network on an ATM platform | |
| US6205148B1 (en) | Apparatus and a method for selecting an access router's protocol of a plurality of the protocols for transferring a packet in a communication system | |
| US8018939B2 (en) | MPLS implementation of an ATM platform | |
| JP2000124920A (ja) | コネクション型ネットワ―クの接続を管理するための方法、およびコネクション型ネットワ―クを介してコネクションレス型通信プロトコルを支持するための方法 | |
| US20060114889A1 (en) | Multiservice use of network connection capability | |
| CA2341939C (en) | Label request packet transmission method, packet transfer network and method thereof, and packet transfer device | |
| US20040153556A1 (en) | Connections on demand between subscribers and service providers | |
| JP3261057B2 (ja) | Ａｔｍスイッチおよび呼受付優先制御方法 | |
| JP3394430B2 (ja) | ネットワークシステム及び交換機 | |
| JP2000022710A (ja) | パス設定方法、通信装置及び記憶媒体 | |
| KR20010075867A (ko) | 프레임릴레이 연동장치의 영구가상연결 제어 방법 | |
| KR19990087607A (ko) | Atm 네트워크를 통한 atm 셀의 전송 방법 | |
| JP3621475B2 (ja) | Ａｔｍ通信システム及びａｔｍ交換機およびノード装置 | |
| JPH1168782A (ja) | シグナリング処理装置およびその方法 | |
| KR100613964B1 (ko) | 비동기전송모드(ａｔｍ)망에서 인터넷 아이.피(ｉｐ)패킷전송 방법 | |
| JP3471136B2 (ja) | 制御情報転送方法及びノード装置 | |
| JP2001045058A (ja) | セッション接続型パケット転送システムおよびその構成装置 | |
| JP3548701B2 (ja) | ユーザ認証と経路制御機能を備えたセッション接続型パケット転送システム | |
| JP3538018B2 (ja) | 通信網 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040212 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040323 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040517 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040817 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040820 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090903 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |