JP4454072B2 - ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 - Google Patents
ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 Download PDFInfo
- Publication number
- JP4454072B2 JP4454072B2 JP22041999A JP22041999A JP4454072B2 JP 4454072 B2 JP4454072 B2 JP 4454072B2 JP 22041999 A JP22041999 A JP 22041999A JP 22041999 A JP22041999 A JP 22041999A JP 4454072 B2 JP4454072 B2 JP 4454072B2
- Authority
- JP
- Japan
- Prior art keywords
- qos
- qos guarantee
- specific data
- guarantee
- data packet
- 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
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/825—Involving tunnels, e.g. MPLS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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/08—Protocols for interworking; Protocol conversion
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はインターネット網またはイントラネット網（企業内ＩＰ網）などのＩＰパケット交換網を経由した、オーダーエントリ業務などの基幹業務データを含むデータ通信のＱｏＳ（Quality of Service：ネットワークが提供するサービスの品質）保証をＲＳＶＰ(Resource Reservation Protocol)に基づいて可能にするＩＰ通信ネットワークシステムに関する。
【０００２】
【従来の技術】
近年、ローカルエリアネットワーク（ＬＡＮ）の高機能化及びイントラネット網の拡充などをはじめとするネットワーク技術の進歩と、パーソナルコンピュータ（ＰＣ）の多機能化及びＰＣに適用するＣＰＵの高速化などをはじめとするＰＣ技術の進歩とにともない、複数のＬＡＮ（サブネットワーク）上のＰＣ間で各種情報を高速に通信することが実用的に可能になってきた。
【０００３】
また、電子メールやＷＷＷ(World Wide Web)の普及、動画像情報及び音声情報などのマルチメディアデータの利用普及も進みつつある。さらに、データ通信に使用されるプロトコルでは、ＩＰ(Internet Protocol)の占める割合が高まっており、この傾向は今後も進むと推測できる。
【０００４】
ネットワークインフラが整備され、一般のデータ通信(ＩＰデータ通信)がほとんど不都合なく実現されている現在、特定のＩＰデータ通信毎にＱｏＳを保証することが求められるようになってきている。例えば、動画像情報及び音声情報などのマルチメディアデータの連続的なストリームデータについて、送受信エンティティ（ＰＣやワークステーション：ＷＳなど）間の伝送路のトラフィック負荷の状態いかんにかかわらず、スムースな音声情報や動画像情報の再生を可能とするために、ＲＳＶＰに則って伝送帯域幅などのネットワーク資源を予約し、遅延やジッタを一定範囲に抑えることで、要求されるＱｏＳ保証を実現できる。
【０００５】
現在では、ＲＳＶＰを実装したネットワーク機器や、ＰＣのオペレーティングシステム（ＯＳ）自体のＲＳＶＰへの適合やＲＳＶＰに対応したマルチメディアアプリケーションも商品化されている。
【０００６】
また、マルチメディアデータを対象とするデータ通信以外にも低遅延などのＱｏＳ保証が求められているデータ通信がある。例えば、企業の収益に直結するオーダーエントリ業務及び銀行の勘定業務などの基幹業務データに関する通信は、企業にとって重要度が高く、遅延などを抑制した高品質な伝送が求められるデータ通信であり、クライアント端末とサーバ（ホストコンピュータ）との間のネットワークのトラフィック負荷状態とは関係なく、常に低遅延で伝送されるような仕組みが求められている。
【０００７】
さらに、このような基幹業務も、ネットワーク管理コスト低減の観点から、メーカ（ベンダ）各社のネットワーク・アーキテクチャ（ネットワークＯＳ）である従来のＳＮＡ(Systems Network Architecture)やＦＮＡ(Fujitsu Network Architecture)から、他の電子メールやＷＷＷなどの情報通信プロトコルと同じＩＰに移行しつつある。ところが、ネットワーク管理コストは削減の観点から、ＷＷＷや電子メールなどの情報系通信とＩＰ化された基幹業務通信とを１つの回線上に統合するという要求は強いが、仮に統合した場合、特に伝送速度の遅いＷＡＮ、つまりＩＰパケット交換網部分で他の情報系通信のトラフィックに圧迫され、基幹業務データ通信の良好なレスポンスが阻害される、という問題が発生する。
【０００８】
従って、現状では、情報系通信とは別に専用の回線を敷設し、基幹業務データ通信の低遅延などの伝送品質を確保している状態である。
【０００９】
【発明が解決しようとする課題】
上述したように、通信プロトコルのＩＰ統合や回線数削減などによるネットワーク管理コスト削減の要求は強いが、重要度の高い基幹業務データなどの通信については、何らかのＱｏＳ保証の仕組みが必要である。例えば、多数端末がランダムにデータパケットを送信するような基幹業務通信やクライアント・サーバ間通信のＱｏＳ保証についてＲＳＶＰを適用しようと考えた場合、ＲＳＶＰはセッション単位で、言い換えるとＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)コネクション単位、あるいはＵＤＰ／ＩＰ(User Datagram Protocol/Internet Protocol)の送信元及び宛先ポートペア単位でＱｏＳ保証を行う必要がある。
【００１０】
このため、個々のクライアント端末がＲＳＶＰを実装して個々のデータについてＱｏＳ保証しようとした場合、ＲＳＶＰをサポートしているルータなどのネットワーク機器は、端末台数分（数百〜数千台以上）のＲＳＶＰプロセスを処理しなければならない。この結果、処理負荷が増大して、逆にレスポンスは悪くなり、実質上ＲＳＶＰはそのままではこのような通信のＱｏＳ保証に適用不可能である。
【００１１】
さらに、ＲＳＶＰは、ＱｏＳ保証対象のトラフィックが主として動画像情報などのマルチメディアデータであり、ある程度連続した時間継続し、かつほぼ一定レートで送信されるストリームデータを対象としているため、多数端末からランダムに送信される個々のバーストデータに関してＱｏＳ保証のために適用することは難しい。
【００１２】
本発明の課題は、多くのネットワーク機器メーカ各社が実装し、ＱｏＳ保証プロトコルとして標準になっているＲＳＶＰを適用して、多数端末からランダムに送信されるバーストデータの集合について、遅延などのＱｏＳを保証することが可能なＩＰ通信ネットワークシステム及びＱｏＳ保証装置を提供することにある。
【００１３】
【課題を解決するための手段】
上記課題を解決するために、本発明のＩＰ通信ネットワークシステムは、多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を有する第１のＱｏＳ保証装置と；
前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置であって；
カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を有する第２のＱｏＳ保証装置とを備える。
【００１４】
本発明のＱｏＳ保証装置は、多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段とを備える。
【００１５】
この構成を採るＱｏＳ保証装置は、カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段とを備える前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置に対向する。
【００１６】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
〔ＩＰ通信ネットワークシステムの全体構成〕
本発明の一実施の形態におけるＩＰ通信ネットワークシステムの構成を示す図１を参照すると、このシステム１はＩＰパケット交換網としてワイドエリアネットワーク（ＷＡＮ：ルータネットワーク）１０を備える。この実施の形態においては、ＷＡＮ１０はイントラネット網（企業内ＩＰ網）を構成している。ＷＡＮ１０にはＱｏＳ保証装置２０，３０が接続されている。これらのＱｏＳ保証装置２０，３０はルータやネットワークサーバなどのネットワーク機器内に設けることができる。
【００１７】
クライアント側のＱｏＳ保証装置２０はローカルエリアネットワーク（ＬＡＮ）４０に接続され、サーバ側のＱｏＳ保証装置３０はＬＡＮ５０に接続されている。ＬＡＮ４０，５０はシステム１のサブネットワークをそれぞれ構成している。
【００１８】
ＬＡＮ４０は複数のクライアント端末６０及び複数の情報系端末７０を収容している。クライアント端末６０及び情報系端末７０のそれぞれはパーソナルコンピュータ（ＰＣ）であり、音声情報などを含むデータ通信機能を有する。ＬＡＮ５０はサーバ（ホストコンピュータ）８０及び情報系サーバ９０を収容している。
【００１９】
矢印で示す領域２はこのシステム１におけるＱｏＳ保証対象領域である。ここで、情報系端末７０及び情報系サーバ９０はＱｏＳ保証対象外のデータをそれぞれ発生する。
【００２０】
〔ＱｏＳ保証装置の構成〕
図２は図１におけるＱｏＳ保証装置２０，３０の詳細構成、つまり構成要素を示す。なお、ここでは、クライアント側のＱｏＳ保証装置２０の構成を図示しているが、サーバ側のＱｏＳ保証装置３０も同一構成である。
【００２１】
ＱｏＳ保証装置２０は、入力インターフェース部２０１、対象トラフィック判別部２０２、転送機能部２０３、カプセル化機能部２０４、ＲＳＶＰホストプロセス部２０５、条件データベース部２０６、カプセル化解除機能部２０７、トラフィックレート監視部２０８、予約条件設定部２０９、ダミーデータ発生部２１０、タイマ２１１、スケジュールタイマ２１２、及び出力インターフェース部２１３から構成されている。これらのＱｏＳ保証装置２０，３０の動作については後に詳述する。
【００２２】
このＱｏＳ保証装置２０において、入力インターフェース部２０１にはクライアント端末６０から送信されたデータパケットＰＫＴ１及び情報系端末７０から送信されたデータパケットが入力され、出力インターフェース部２１３からはＱｏＳ保証対象のクライアント端末６０からのデータパケットＰＫＴ１をカプセル化したカプセル化データパケットＰＫＴ２及び情報系端末７０からのデータパケットがＷＡＮ１０に向けて出力される。
【００２３】
また、ＱｏＳ保証装置２０においては、入力インターフェース部２０１にはＷＡＮ１０から送信されたカプセル化データパケットＰＫＴ２とＱｏＳ保証対象外のデータパケットとが入力され、出力インターフェース部２１３からはカプセル化解除済みデータパケットＰＫＴ３がクライアント端末６０に向けて出力され、ＱｏＳ保証対象外のデータパケットは情報系端末７０に出力される。
【００２４】
一方、ＱｏＳ保証装置３０において、入力インターフェース部２０１にはＷＡＮ１０から送信されたカプセル化データパケットＰＫＴ２及びＱｏＳ保証対象外のデータパケットが入力され、出力インターフェース部２１３からはカプセル化解除済みデータパケットＰＫＴ３がサーバ８０に向けて出力され、ＱｏＳ保証対象外のデータパケットは情報系サーバ９０に向けて出力される。また、ＱｏＳ保証装置３０においては、入力インターフェース部２０１にはサーバ８０から送信されたデータパケットＰＫＴ１が入力され、出力インターフェース部２１３からはカプセル化データパケットＰＫＴ２がＷＡＮ１０に向けて出力される。ＱｏＳ保証対象外の情報系サーバ９０からのデータパケットはそのまま何も処理されずに送受信（ルーティング）される。
【００２５】
〔ＲＳＶＰのシグナリング及び資源確保システム〕
次に、上記ＩＰ通信ネットワークシステム１におけるデータ通信のＱｏＳ保証のために適用されるＲＳＶＰのシグナリング及び資源確保システムについて、図３及び図４を参照して説明する。
【００２６】
ＲＳＶＰ(Resource Reservation Protocol)は図１に示すＷＡＮ１０などのＩＰパケット交換網上でルータ・ルータ間のネットワーク帯域（伝送帯域幅）などの資源を予約する手順を定めたプロトコルであり、ＲＦＣ２２０５で基本仕様が規定されている。また、ＲＳＶＰはＩＰの上層のトランスポート層のＱｏＳ保証プロトコルである。実際のＱｏＳ保証サービスに関しては、ＩＥＴＦ(Internet Engineering Task Force)のワーキィンクグループ(IntservWG)にて規定されるＱｏＳ保証サービスをその予約対象とすることを前提としている。
【００２７】
現状、このＩｎｔｓｅｒｖＷＧで規定されているサービスは、次のとおりである。つまり、
（１）Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ：ネットワークが過負荷状態でも、通常のＢｅｓｔ−Ｅｆｆｏｒｔ型サービスと同等の性能(遅延、ビット誤り率など)を提供するサービス（ＲＦＣ２２１１規定）。
【００２８】
（２）Ｇｕａｒａｎｔｅｅｄ ＱｏＳ：エンド・エンドのすべてのデータ伝送を指定された遅延時間以内に抑えるサービス（ＲＦＣ２２１２規定）。
ＲＳＶＰはルータＲＴ及びホストＨＴに実装される。言い換えると、あるデータに対してＲＳＶＰメッセージで資源予約を行うＲＳＶＰ対応ホストと、ＲＳＶＰメッセージを受信して実際にネットワーク資源を予約するＲＳＶＰ対応ルータとが存在する。なお、資源予約はデータの受信ホストＨＴ（Ｒ）によって行われる。
【００２９】
データの送信ホストＨＴ（Ｔ）は送信するトラフィックの特性や経路を伝えるためにＲＳＶＰ Ｐａｔｈ（パス状態）メッセージＭＳＧ１を送信する。一方、受信ホストＨＴ（Ｒ）はＰａｔｈメッセージＭＳＧ１を受信し、その送信ホストＨＴ（Ｔ）のデータに対して資源の予約を行う場合、ＲＳＶＰ Ｒｅｓｖ（資源確保要求）メッセージＭＳＧ２を送信する。ＰａｔｈメッセージＭＳＧ１に則って構築された経路をたどって、ＲｅｓｖメッセージＭＳＧ２を途中のＲＳＶＰ対応ルータＲＴ及び送信ホストＨＴ（Ｔ）に伝えることにより、資源の予約が完了する。
【００３０】
なお、経路途上でＲＳＶＰをサポートしていないルータが存在した場合は、そのルータに対して帯域の保証は行われないが、データ伝送は透過的に行われる。また、ＲＳＶＰをサポートしているホストＨＴ及びルータＲＴの場合でも、要求される予約内容が受け入れられない場合、例えば既に別の帯域予約が存在して要求された帯域が確保できないなどの場合は、エラーメッセージを返して通知する。資源予約を解除する場合は、送信ホストＨＴ（Ｔ）がＰａｔｈＴｅａｒメッセージを送信し、受信ホストＨＴ（Ｒ）がＲｅｓｖＴｅａｒメッセージを送信する。
【００３１】
図４において、ＲＳＶＰを実装したシステム、つまりホストＨＴ及びルータＲＴでは、データの送信元であるアプリケーションＡＰＬがＲＳＶＰプロセス（ＲＳＶＰデーモン）ＰＲＣと通信しながらデータパケットをパケットクラスファイアＣＬＦに送る。パケットクラスファイアＣＬＦはＱｏＳ保証対象外のデータパケットを分類する。パケットスケジューラＳＣＤはパケットクラスファイアＣＬＦにより分類されたデータパケットを受け取り、ＲＳＶＰプロセスＰＲＣと通信しながら、ＱｏＳを保証するようにスケジューリングを行ってパケットを送出する。
【００３２】
ＲＳＶＰのＱｏＳ制御要求はデータ受信側からデータ送信経路上のそれぞれの中継システム内のアドミッションコントロールＡＤＭ及びポリシーコントロールＰＲＹの二つの決断モジュールに転送される。アドミッションコントロールＡＤＭは、システムが要求されたＱｏＳを確保できる十分な容量があるかどうかを決定し、ポリシーコントロールＰＲＹは、ＱｏＳを要求しているクライアント（ユーザ）がその確保を許可されているか否かを決定する。パケットクラスファイアＣＬＦにより分類されたパケットについていずれの条件も充足していれば、上記の要求されたＱｏＳを保証するようにパケットスケジューラＳＣＤの処理が行われる。なお、ルータＲＴにおけるルーティングプロセスＲＯＴはルーティングテーブルの処理機能である。
【００３３】
〔ＩＰ通信ネットワークシステムにおけるＱｏＳ保証動作〕
次に、図１に示す本発明の一実施の形態のＩＰ通信ネットワークシステム１の構成、つまり多数のクライアント端末６０と１つのサーバ８０とがＷＡＮ１０を経由してデータ通信を行うネットワーク形態において、ＱｏＳ保証装置が設置されている場合についての動作例を説明する。
【００３４】
図１，図２，図５及び図６を併せ参照すると、ＱｏＳ保証装置２０がデータパケットＰＫＴ１を入力インターフェース部２０１を通して受信した場合、ＱｏＳ保証対象トラフィックであるか否かを対象トラフィック判別部２０２で検査する。例えば、多数の情報系端末７０の送信するＷＷＷや電子メールのデータ及びファイル転送などが対象でない場合、それらは転送機能部２０３に送られ、そのままなにも処理されずに出力インターフェース部２１３を通して転送される。
【００３５】
すべてのＱｏＳ保証対象パケットは、カプセル化機能部２０４にて、登録されているＷＡＮ１０を挟んで対になるＱｏＳ保証装置３０のＩＰアドレスによりカプセル化される。言い換えると、ＱｏＳ保証装置２０，３０間で図５に示すようなトンネルを作り、すべてのＱｏＳ保証対象パケットがトンネリングで転送される。これにより、見かけ上、ＱｏＳ保証装置２０，３０がすべてのＱｏＳ保証対象パケットの送信元、つまりＲＳＶＰを実装した送信ホストとなり、これらのパケットに関してＲＳＶＰホストプロセス部２０５によりＲＳＶＰ ＰａｔｈメッセージＭＳＧ１を送信し、ＱｏＳ保証装置間のネットワーク資源予約を行う。
【００３６】
この結果、多数のクライアント端末６０から送信されるＱｏＳ保証対象パケット群が、見かけ上１つのセッションのデータであるようにして、ＲＳＶＰの１つの資源予約プロセスだけでＱｏＳを保証することができる。
【００３７】
通常、クライアント端末６０で動作している業務通信アプリケーションなどの通信レスポンス全体を保証する場合には、双方向のデータに対してＱｏＳ保証を行う必要があり、サーバ（ホストコンピュータ）８０からの応答データに関しては、そのネットワークに存在するＱｏＳ保証装置が同様の処理を行うことで実現する。
【００３８】
ＱｏＳ保証対象パケットの判別の方法としては、対象トラフィック判別部２０２でデータパケットの宛先アドレスを調べることで区別することができる。どの宛先アドレスがＱｏＳ保証となるかという条件は、条件データベース部２０６に予め登録しておき、これを参照する。これは例えば、クライアント・サーバ間通信において、対象のサーバのアドレスが指定されていた場合に、ＱｏＳ保証対象とする、という場合に適用できる。
【００３９】
つまり、情報系サーバ９０へのデータはＱｏＳ保証対象としない場合は、そのアドレスを条件データベース部２０６には登録しない。サーバ側から多数のクライアント端末（クライアント端末群）６０への応答データにＱｏＳ保証しようとする場合は、各クライアント端末６０のアドレスをサーバ側のＱｏＳ保証装置３０の条件データベース部２０６へ登録し、ＱｏＳ保証対象トラフィックを切り分ける。
【００４０】
また、サーバからの応答データを対象にする場合で、各クライアント端末６０のアドレスを条件とするか、あるいはクライアント端末数が極度に多い場合でかつそこにはＱｏＳ保証対象とするクライアント端末６０しか存在しない場合は、クライアント端末群が属するサブネットワーク、つまりＬＡＮ４０のアドレスのみを登録し、それを調べることでＱｏＳ保証対象トラフィックを切り分ける。これは当然クライアント側のＱｏＳ保証装置２０に適用しても良い。
【００４１】
ＱｏＳ保証対象パケットの判別の他の方法として、条件データベース部２０６に対象となる送信先アドレスを登録しておき、これを使用することもできる。条件データベース部２０６にＱｏＳ保証対象の通信を行うクライアント端末６０のアドレスを登録し、またサーバ側のＱｏＳ保証装置３０には対象とするサーバ８０のアドレスを登録しておくことで実現できる。
【００４２】
あるサブネットワーク（ＬＡＮ）のクライアント端末６０が多数の場合には、登録アドレス数が膨大になる可能性があり、また、あるサブネットワークにはＱｏＳ保証対象の通信しか行わないクライアント端末６０のみが存在する場合は、そのサブネットワークアドレスのみを条件データベース部２０６に登録しておけば良い。
【００４３】
また、例えば基幹業務通信に使われるプロトコルとして、上記ＳＮＡ、ＦＮＡなどがあるが、ＳＮＡｏｎＴＣＰ／ＩＰの場合はポート番号が「１０８」(SNA Gateway Access Server)、「１４３９」(/tcp Eicon X.25/SNA Gateway)、あるいはＦＮＡｏｎＴＣＰ／ＩＰの場合はポート番号が「４９２」または「４９３」(Transport Independent Convergence for FNA)と、ＩＡＮＡ(Internet Assigned Number Authority)のアサインメントより決まっているため、条件データベース部２０６にこれらの宛先ポート番号を登録し、ＱｏＳ保証対象パケットの判別にこれを使用することができる。
【００４４】
ＱｏＳ保証装置に存在するインターフェース部２０１に接続するサブネットワークには基幹業務端末のみが設置され、別のサブネットワークには一般のＰＣなどが接続されているといった形態で、基幹業務データ通信の品質のみ保証したい場合、上記サブネットワークの接続するＱｏＳ保証装置のインターフェース部２０１に入力するパケット群のみに関してＱｏＳを保証することもできる。この場合、ＱｏＳ保証装置の処理負荷は小さくできる。
【００４５】
多数のクライアント端末６０から送信されるデータを１つのＲＳＶＰプロセス、つまりＲＳＶＰホストプロセス部２０５で処理するためには、各パケットが１つのセッションで発生しているように見せ、それに対してＲＳＶＰで資源予約する必要がある。その為には、宛先アドレス、宛先ポート番号、プロトコルＩＤを同一にするようにトンネリングすれば良く、ＩＰヘッダ中のプロトコル番号がＵＤＰを示す「１７」でトランスポート層ヘッダ（ＵＤＰヘッダ）に宛先ポート番号フィールドを持つＩＰヘッダ及びＵＤＰヘッダで、各クライアント端末６０のパケットをカプセル化すれば良い（図６参照）。
【００４６】
具体的には、ＱｏＳ保証装置がトンネルに使用するＵＤＰポートと、トンネルの終端すなわち対になるＱｏＳ保証装置のＩＰアドレスをカプセル化機能部２０４に登録しておき、それらを利用してＱｏＳ保証対象パケットを切り分け後にカプセル化して送信すれば良い。
【００４７】
ＵＤＰ／ＩＰは処理としては軽いが、ロストデータやダメージデータについて再送機能は無い為、トンネリング部分でのデータ伝送の信頼性を高めるために、ＩＰヘッダ中のプロトコル番号が「６」であるＴＣＰ／ＩＰにカプセル化し、それらのパケットに対してＲＳＶＰで予約を行っても良い。
【００４８】
また、ＱｏＳ保証装置間でカプセル化されて伝送され、設定された特定のＵＤＰポートあるいはＴＣＰポートでＱｏＳ保証装置に受信されたデータは、さらに本来の宛先であるサーバ８０、あるいは逆方向では各クライアント端末６０に受信できるように、カプセル化解除機能部２０７にて、付加されていたＵＤＰ／ＩＰヘッダ、あるいはＴＣＰ／ＩＰヘッダを取り除き、本来のデータパケットＰＫＴ１またはＰＫＴ３として転送機能部２０３から送信される。
【００４９】
〔他のＩＰ通信ネットワークシステム構成におけるＱｏＳ保証動作〕
次に、図７に示す本発明の他の実施の形態のＩＰ通信ネットワークシステム３の構成、つまり多数のクライアント端末（クライアント端末群）６０，６１，６２が属するサブネットワーク（ＬＡＮ）４０，４１，４２とサーバ（ホストコンピュータ）８０，８１が属するサブネットワーク（ＬＡＮ）５０，５１とがＷＡＮ１０を挟んでそれぞれ複数存在しているネットワーク形態において、データ通信のＱｏＳ保証を行う場合についての動作例を説明する。
【００５０】
図２，図５，図６，図７，図８及び図９を併せ参照すると、宛先アドレスによりＱｏＳ保証対象パケットを切り分ける場合を考えると、クライアント側ＱｏＳ保証装置２０，２１，２２及びサーバ側ＱｏＳ保証装置３０，３１の条件データベース部２０６（各ＱｏＳ保証装置の構成要素は図２に示すＱｏＳ保証装置２０の構成要素に基づいて説明する）を図８及び図９にそれぞれ示すように、ＱｏＳ保証対象パケット切り分け用のアドレスとそのアドレスを持つパケットの宛先となるべきサーバのアドレス、逆方向ではクライアント端末６０，６１，６２の属するアドレスとそれらネットワークに存在するＱｏＳ保証装置２０，２１，２２のアドレスの対のエントリを条件の数だけ持たせる。
【００５１】
そして、ＱｏＳ保証対象パケット切り分け後に、カプセル化機能部２０４にパラメータとして渡して対応する対のＱｏＳ保証装置のアドレスでカプセル化して、それらのパケットに対して宛先毎にＲＳＶＰにより資源予約することにより、図７に示すように、複数の宛先ネットワークがある場合に対応可能である。
【００５２】
また、例えば図７に示すネットワーク形態において、サブネットワーク５０にサーバ８０が複数存在した場合には、図８に示す「サーバ／ホストコンピュータのアドレス」ではなく「サブネットワーク５０に存在するサーバ８０のアドレス」をすべて登録すれば対応可能である。
【００５３】
また、クライアント端末数が多い場合には、サーバ側ＱｏＳ保証装置の条件データベース部２０６には、すべてのクライアント端末のアドレスの代わりに、サブネットワークのアドレスを登録して、エントリ自体の数を減らしても良い。
【００５４】
また、例えば、特定の宛先ポート番号を基幹業務アプリケーション毎に使用している場合などでは、アドレスやサブネットワークアドレスの代わりに、ポート番号（カプセル化時のポート番号ではなく、オリジナルのデータＰＫＴ１の宛先ポート番号）を登録してこれを使用しても良い。
【００５５】
さらに、これらを組み合せて条件データベース部２０６に登録することによって、同じ宛先だが、使用するポート番号が異なる基幹業務アプリケーションを使用するクライアント端末が混在している場合にも、対応が可能である。
【００５６】
ＲＳＶＰでトラフィックのＱｏＳを保証するには、データの送信元がＲＳＶＰＰａｔｈメッセージＭＳＧ１でトラフィックのデータレートを指定しなければならない。通常、クライアント端末数の多い基幹業務通信やその他のクライアント・サーバ間通信では、各クライアント端末の合計のデータレート、あるいはサーバからの応答データのレートは比較的一定している。しかし、単一のマルチメディアのストリームデータとは違い、若干のデータレートの総計には差が出ることが考えられる。
【００５７】
そこで、ＱｏＳ保証を確実にするため、ＱｏＳ保証対象データの合計データ量をトラフィックレート監視部２０８によって監視し、差分が生じた場合に、差分に相当するダミーのデータパケットをダミーデータ発生部２１０で発生し送信して、データレートを一定にする。この場合のダミーデータパケットは、実際のデータがカプセル化されたものと同じ、すなわち宛先ＩＰアドレスが対のＱｏＳ保証装置のＩＰアドレス、トンネルデータ用のポート番号を持つＵＤＰ／ＩＰあるいはＴＣＰ／ＩＰデータである。
【００５８】
この場合、パケットのペイロードが一定のパケットを必要なだけ送信する、あるいはペイロードの大きさによって差分を補うなどの方法が考えられる。実際の運用では、ＲＳＶＰ ＰａｔｈメッセージＭＳＧ１で指定するデータレートはピーク時のレートより若干多目にし、差分をダミーデータパケットで補うという形態を採ることができる。この手法では、ダミーデータパケット分だけネットワークの帯域を無駄遣いすることになるが、次に述べる手法に比べて、ＱｏＳ保証装置としては軽いＲＳＶＰプロセスで動作することができる。
【００５９】
ＱｏＳ保証対象データの合計データ量をトラフィックレート監視部２０８によって監視し、差分が生じた場合に、そのデータレートに一致するパラメータを予約条件設定部２０９に指定して変更後のＲＳＶＰ ＰａｔｈメッセージＭＳＧ１を送信して、予約条件を実際のレートに合せる方法も採れる。僅かな変動毎に予約条件を変更して予約し直すのは、ＲＳＶＰプロセスとして処理が重くなる可能性があるため、例えば前回予約時から１０Ｋｂｐｓの変動が検出されたとき毎に予約条件を変更するという運用が考えられる。
【００６０】
ＲＳＶＰによりネットワーク資源予約を開始するトリガとしては、資源の有効利用や処理負荷の低減のため、対象トラフィック判別部２０２にてＱｏＳ保証対象のトラフィックを検出した時点で、ＲＳＶＰホストプロセス部２０５に指示してＰａｔｈメッセージＭＳＧ１の送信を開始する。
【００６１】
また、ＱｏＳ保証装置にタイマ２１１を設け、対象トラフィック判別部２０２にてＱｏＳ保証対象のトラフィックが検出されなくなった時点でタイマ２１１を動作し、設定された時間が満了した時点で、タイマ２１１からＲＳＶＰホストプロセス部２０５に指示を出し、ＲＳＶＰ ＰａｔｈＴｅａｒメッセージを送信して資源予約を解除することで、同様に資源の有効利用や処理負荷の低減が可能になる。
【００６２】
また、オーダーエントリ業務など、例えば１０：００〜１８：００といったような、企業の顧客に対する営業時間帯のみに行われる業務のデータ通信に対してＱｏＳ保証を行う場合は、スケジュールタイマ２１２を設けて、ある時間の範囲では常に資源予約を行う、という運用を採ることができる。
【００６３】
マルチメディアデータなどが同時に頻繁に使用されるような環境では、そのマルチメディアデータなどをＲＳＶＰでＱｏＳ保証して伝送することがあるが、基幹業務などの業務系のデータ通信に対してＱｏＳ保証を開始しようとした場合、他のセッションによりネットワーク帯域が使用されていて、業務用に確保したい帯域が確保できない場合もあり得るが、これを避けるため、ＱｏＳ保証装置の起動時にＲＳＶＰのシグナリング、すなわちＰａｔｈメッセージＭＳＧ１やＲｅｓｖメッセージＭＳＧ２の送信を開始し、常に予約しておくとよい。
【００６４】
この場合は、ＲＳＶＰによる他のデータに対する資源予約が、ＱｏＳ保証対象データ用に確保している予約の分だけ利用できないだけで、ＱｏＳ保証対象データが無い場合には、伝送路帯域自体は他のトラフィックによってすべて使用することができるので、大きな問題とはならない。
【００６５】
〔変形例〕
上述したＱｏＳ保証機能は、サブネットワークの入口もしくはＷＡＮへの入口に設置されるルータ、またデータの経路上に存在するワークステーション（ＷＳ）やＰＣサーバなどのネットワークサーバに実装してもよい。この場合、転送機能部に通常のルータが持つルーティング機能を持たせれば良い。
【００６６】
また、企業内ＩＰ網（イントラネット網）としてのルータネットワークの内部のルータすべてが上述したＱｏＳ保証機能を持つ必要は無いため、例えば製品として安価にするために、ＷＳやＰＣに同機能を持たせ、サブネットワーク毎に１つ設置すれば良い。この場合、各クライアント端末やサーバ（ホストコンピュータ）はこの装置宛てにデータを送信することになり、ＱｏＳ保証対象パケットの切り分けには、送信元アドレスや宛先ポート番号を条件データベース部に設定して使用することになる。
［その他］
（付記１）多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を有する第１のＱｏＳ保証装置と；
前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置であって；
カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を有する第２のＱｏＳ保証装置と；
を備えることを特徴とするＩＰ通信ネットワークシステム。
（付記２）多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を備えることを特徴とするＱｏＳ保証装置。
（付記３）カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を備える前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置に対向することを特徴とする付記２記載のＱｏＳ保証装置。
（付記４）前記トランスポート層対応のＱｏＳ保証プロトコルがＲＳＶＰプロトコルであることを特徴とする付記２記載のＱｏＳ保証装置。
（付記５）前記ＩＰパケット交換網がイントラネット網であることを特徴とする付記２記載のＱｏＳ保証装置。
（付記６）前記ＩＰパケット交換網がワイドエリアネットワークから構成されていることを特徴とする付記２記載のＱｏＳ保証装置。
（付記７）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの宛先アドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記８）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの宛先ネットワークアドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記９）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの送信元アドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１０）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの送信元ネットワークアドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１１）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの宛先ポート番号に基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１２）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの受信インターフェースに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１３）前記カプセル構成手段は、前記トラフィックの集合を１つのセッションと見なせるように、前記ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在する対向装置のインターフェースのアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをＵＤＰ／ＩＰでカプセルに構成することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１４）前記カプセル構成手段は、前記トラフィックの集合を１つのセッションと見なせるように、前記ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在する対向装置のインターフェースのアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをＴＣＰ／ＩＰでカプセルに構成することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１５）ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスとＱｏＳ保証対象の前記特定データパケットの宛先アドレスとの組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先アドレスを調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１６）ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスと前記反対側のＱｏＳ保証装置のそれぞれに接続しているサブネットワークのネットワークアドレスとの組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先ネットワークアドレスを調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１７）ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスとＱｏＳ保証対象の前記特定データパケットの宛先ポート番号との組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先ポート番号を調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１８）前記ＱｏＳ保証対象トラフィックの総データ量を監視し、伝送レートに変動があった場合に、前記ＱｏＳ保証対象トラフィックの総伝送レートを一定に保つために送信する、差分レート分のダミーデータパケットを発生する発生手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１９）前記ＱｏＳ保証対象トラフィックの総データ量を監視し、伝送レートに変動があった場合に、前記ＱｏＳ保証プロトコルに則った資源予約条件を動的に変更するための変更手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記２０）前記ＱｏＳ保証対象トラフィックを監視し、前記ＱｏＳ保証対象トラフィックが受信されなかった場合にタイマを起動し、このタイマに設定された時間が満了するまでに、再び前記ＱｏＳ保証対象トラフィックが受信されない場合は、前記ＱｏＳ保証プロトコルに則った資源予約を解除する予約解除手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記２１）スケジュールタイマを参照して、予め定めた時間の範囲で前記ＱｏＳ保証プロトコルに則った資源予約を実行する実行手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記２２）前記第１及び第２のＱｏＳ保証装置の有する機能をネットワーク経路上に存在する他の装置に実装したことを特徴とする付記１記載のＩＰ通信ネットワークシステム。
（付記２３）前記第１及び第２のＱｏＳ保証装置の有する機能をネットワーク経路上に存在しない他の装置に実装したことを特徴とする付記１記載のＩＰ通信ネットワークシステム。
【００６７】
【発明の効果】
以上説明したように、本発明によれば、主としてＲＳＶＰ対応ネットワーク機器が導入されている企業内ＩＰ網などにおいて、本来ＲＳＶＰによるＱｏＳ保証が難しい、重要通信である基幹業務などの多数端末がランダムに送信するデータパケットの集合に対するＱｏＳ保証が実現でき、企業ユースの強い通信プロトコルのＩＰへの統合やネットワークの統合を実現可能とし、ネットワーク管理自体の容易化やそのコストの低減などを図ることができる。
【００６８】
また、本発明によれば、基幹業務データ通信だけではなく、クライアント・サーバ環境における通信応答性の向上やその他の重要通信などにも適用することができ、重要度に応じた通信品質を提供できる。
【図面の簡単な説明】
【図１】 本発明の一実施の形態のＩＰ通信ネットワークシステムの構成を示すブロック図。
【図２】 ＱｏＳ保証装置の詳細構成を示すブロック図。
【図３】 ＲＳＶＰのシグナリングを説明するための図。
【図４】 ＲＳＶＰの資源確保システムを示すブロック図。
【図５】 ＩＰ通信ネットワークシステムにおけるトンネリングの概念を説明するための図。
【図６】 ＵＤＰ／ＩＰによるデータパケットのカプセル化を示す図。
【図７】 本発明の他の実施の形態のＩＰ通信ネットワークシステムの構成を示すブロック図。
【図８】 クライアント側ＱｏＳ保証装置の条件データベースを示す図。
【図９】 サーバ側ＱｏＳ保証装置の条件データベースを示す図。
【符号の説明】
１，３ ＩＰ通信ネットワークシステム
２ ＱｏＳ保証対象領域
１０ ＷＡＮ（ルータネットワーク）
２０，２１，２２，３０，３１ ＱｏＳ保証装置
４０，４１，４２，５０，５１ ＬＡＮ（サブネットワーク）
６０，６１，６２ クライアント端末
７０ 情報系端末
８０，８１ サーバ（ホストコンピュータ）
９０ 情報系サーバ
【発明の属する技術分野】
本発明はインターネット網またはイントラネット網（企業内ＩＰ網）などのＩＰパケット交換網を経由した、オーダーエントリ業務などの基幹業務データを含むデータ通信のＱｏＳ（Quality of Service：ネットワークが提供するサービスの品質）保証をＲＳＶＰ(Resource Reservation Protocol)に基づいて可能にするＩＰ通信ネットワークシステムに関する。
【０００２】
【従来の技術】
近年、ローカルエリアネットワーク（ＬＡＮ）の高機能化及びイントラネット網の拡充などをはじめとするネットワーク技術の進歩と、パーソナルコンピュータ（ＰＣ）の多機能化及びＰＣに適用するＣＰＵの高速化などをはじめとするＰＣ技術の進歩とにともない、複数のＬＡＮ（サブネットワーク）上のＰＣ間で各種情報を高速に通信することが実用的に可能になってきた。
【０００３】
また、電子メールやＷＷＷ(World Wide Web)の普及、動画像情報及び音声情報などのマルチメディアデータの利用普及も進みつつある。さらに、データ通信に使用されるプロトコルでは、ＩＰ(Internet Protocol)の占める割合が高まっており、この傾向は今後も進むと推測できる。
【０００４】
ネットワークインフラが整備され、一般のデータ通信(ＩＰデータ通信)がほとんど不都合なく実現されている現在、特定のＩＰデータ通信毎にＱｏＳを保証することが求められるようになってきている。例えば、動画像情報及び音声情報などのマルチメディアデータの連続的なストリームデータについて、送受信エンティティ（ＰＣやワークステーション：ＷＳなど）間の伝送路のトラフィック負荷の状態いかんにかかわらず、スムースな音声情報や動画像情報の再生を可能とするために、ＲＳＶＰに則って伝送帯域幅などのネットワーク資源を予約し、遅延やジッタを一定範囲に抑えることで、要求されるＱｏＳ保証を実現できる。
【０００５】
現在では、ＲＳＶＰを実装したネットワーク機器や、ＰＣのオペレーティングシステム（ＯＳ）自体のＲＳＶＰへの適合やＲＳＶＰに対応したマルチメディアアプリケーションも商品化されている。
【０００６】
また、マルチメディアデータを対象とするデータ通信以外にも低遅延などのＱｏＳ保証が求められているデータ通信がある。例えば、企業の収益に直結するオーダーエントリ業務及び銀行の勘定業務などの基幹業務データに関する通信は、企業にとって重要度が高く、遅延などを抑制した高品質な伝送が求められるデータ通信であり、クライアント端末とサーバ（ホストコンピュータ）との間のネットワークのトラフィック負荷状態とは関係なく、常に低遅延で伝送されるような仕組みが求められている。
【０００７】
さらに、このような基幹業務も、ネットワーク管理コスト低減の観点から、メーカ（ベンダ）各社のネットワーク・アーキテクチャ（ネットワークＯＳ）である従来のＳＮＡ(Systems Network Architecture)やＦＮＡ(Fujitsu Network Architecture)から、他の電子メールやＷＷＷなどの情報通信プロトコルと同じＩＰに移行しつつある。ところが、ネットワーク管理コストは削減の観点から、ＷＷＷや電子メールなどの情報系通信とＩＰ化された基幹業務通信とを１つの回線上に統合するという要求は強いが、仮に統合した場合、特に伝送速度の遅いＷＡＮ、つまりＩＰパケット交換網部分で他の情報系通信のトラフィックに圧迫され、基幹業務データ通信の良好なレスポンスが阻害される、という問題が発生する。
【０００８】
従って、現状では、情報系通信とは別に専用の回線を敷設し、基幹業務データ通信の低遅延などの伝送品質を確保している状態である。
【０００９】
【発明が解決しようとする課題】
上述したように、通信プロトコルのＩＰ統合や回線数削減などによるネットワーク管理コスト削減の要求は強いが、重要度の高い基幹業務データなどの通信については、何らかのＱｏＳ保証の仕組みが必要である。例えば、多数端末がランダムにデータパケットを送信するような基幹業務通信やクライアント・サーバ間通信のＱｏＳ保証についてＲＳＶＰを適用しようと考えた場合、ＲＳＶＰはセッション単位で、言い換えるとＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)コネクション単位、あるいはＵＤＰ／ＩＰ(User Datagram Protocol/Internet Protocol)の送信元及び宛先ポートペア単位でＱｏＳ保証を行う必要がある。
【００１０】
このため、個々のクライアント端末がＲＳＶＰを実装して個々のデータについてＱｏＳ保証しようとした場合、ＲＳＶＰをサポートしているルータなどのネットワーク機器は、端末台数分（数百〜数千台以上）のＲＳＶＰプロセスを処理しなければならない。この結果、処理負荷が増大して、逆にレスポンスは悪くなり、実質上ＲＳＶＰはそのままではこのような通信のＱｏＳ保証に適用不可能である。
【００１１】
さらに、ＲＳＶＰは、ＱｏＳ保証対象のトラフィックが主として動画像情報などのマルチメディアデータであり、ある程度連続した時間継続し、かつほぼ一定レートで送信されるストリームデータを対象としているため、多数端末からランダムに送信される個々のバーストデータに関してＱｏＳ保証のために適用することは難しい。
【００１２】
本発明の課題は、多くのネットワーク機器メーカ各社が実装し、ＱｏＳ保証プロトコルとして標準になっているＲＳＶＰを適用して、多数端末からランダムに送信されるバーストデータの集合について、遅延などのＱｏＳを保証することが可能なＩＰ通信ネットワークシステム及びＱｏＳ保証装置を提供することにある。
【００１３】
【課題を解決するための手段】
上記課題を解決するために、本発明のＩＰ通信ネットワークシステムは、多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を有する第１のＱｏＳ保証装置と；
前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置であって；
カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を有する第２のＱｏＳ保証装置とを備える。
【００１４】
本発明のＱｏＳ保証装置は、多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段とを備える。
【００１５】
この構成を採るＱｏＳ保証装置は、カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段とを備える前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置に対向する。
【００１６】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
〔ＩＰ通信ネットワークシステムの全体構成〕
本発明の一実施の形態におけるＩＰ通信ネットワークシステムの構成を示す図１を参照すると、このシステム１はＩＰパケット交換網としてワイドエリアネットワーク（ＷＡＮ：ルータネットワーク）１０を備える。この実施の形態においては、ＷＡＮ１０はイントラネット網（企業内ＩＰ網）を構成している。ＷＡＮ１０にはＱｏＳ保証装置２０，３０が接続されている。これらのＱｏＳ保証装置２０，３０はルータやネットワークサーバなどのネットワーク機器内に設けることができる。
【００１７】
クライアント側のＱｏＳ保証装置２０はローカルエリアネットワーク（ＬＡＮ）４０に接続され、サーバ側のＱｏＳ保証装置３０はＬＡＮ５０に接続されている。ＬＡＮ４０，５０はシステム１のサブネットワークをそれぞれ構成している。
【００１８】
ＬＡＮ４０は複数のクライアント端末６０及び複数の情報系端末７０を収容している。クライアント端末６０及び情報系端末７０のそれぞれはパーソナルコンピュータ（ＰＣ）であり、音声情報などを含むデータ通信機能を有する。ＬＡＮ５０はサーバ（ホストコンピュータ）８０及び情報系サーバ９０を収容している。
【００１９】
矢印で示す領域２はこのシステム１におけるＱｏＳ保証対象領域である。ここで、情報系端末７０及び情報系サーバ９０はＱｏＳ保証対象外のデータをそれぞれ発生する。
【００２０】
〔ＱｏＳ保証装置の構成〕
図２は図１におけるＱｏＳ保証装置２０，３０の詳細構成、つまり構成要素を示す。なお、ここでは、クライアント側のＱｏＳ保証装置２０の構成を図示しているが、サーバ側のＱｏＳ保証装置３０も同一構成である。
【００２１】
ＱｏＳ保証装置２０は、入力インターフェース部２０１、対象トラフィック判別部２０２、転送機能部２０３、カプセル化機能部２０４、ＲＳＶＰホストプロセス部２０５、条件データベース部２０６、カプセル化解除機能部２０７、トラフィックレート監視部２０８、予約条件設定部２０９、ダミーデータ発生部２１０、タイマ２１１、スケジュールタイマ２１２、及び出力インターフェース部２１３から構成されている。これらのＱｏＳ保証装置２０，３０の動作については後に詳述する。
【００２２】
このＱｏＳ保証装置２０において、入力インターフェース部２０１にはクライアント端末６０から送信されたデータパケットＰＫＴ１及び情報系端末７０から送信されたデータパケットが入力され、出力インターフェース部２１３からはＱｏＳ保証対象のクライアント端末６０からのデータパケットＰＫＴ１をカプセル化したカプセル化データパケットＰＫＴ２及び情報系端末７０からのデータパケットがＷＡＮ１０に向けて出力される。
【００２３】
また、ＱｏＳ保証装置２０においては、入力インターフェース部２０１にはＷＡＮ１０から送信されたカプセル化データパケットＰＫＴ２とＱｏＳ保証対象外のデータパケットとが入力され、出力インターフェース部２１３からはカプセル化解除済みデータパケットＰＫＴ３がクライアント端末６０に向けて出力され、ＱｏＳ保証対象外のデータパケットは情報系端末７０に出力される。
【００２４】
一方、ＱｏＳ保証装置３０において、入力インターフェース部２０１にはＷＡＮ１０から送信されたカプセル化データパケットＰＫＴ２及びＱｏＳ保証対象外のデータパケットが入力され、出力インターフェース部２１３からはカプセル化解除済みデータパケットＰＫＴ３がサーバ８０に向けて出力され、ＱｏＳ保証対象外のデータパケットは情報系サーバ９０に向けて出力される。また、ＱｏＳ保証装置３０においては、入力インターフェース部２０１にはサーバ８０から送信されたデータパケットＰＫＴ１が入力され、出力インターフェース部２１３からはカプセル化データパケットＰＫＴ２がＷＡＮ１０に向けて出力される。ＱｏＳ保証対象外の情報系サーバ９０からのデータパケットはそのまま何も処理されずに送受信（ルーティング）される。
【００２５】
〔ＲＳＶＰのシグナリング及び資源確保システム〕
次に、上記ＩＰ通信ネットワークシステム１におけるデータ通信のＱｏＳ保証のために適用されるＲＳＶＰのシグナリング及び資源確保システムについて、図３及び図４を参照して説明する。
【００２６】
ＲＳＶＰ(Resource Reservation Protocol)は図１に示すＷＡＮ１０などのＩＰパケット交換網上でルータ・ルータ間のネットワーク帯域（伝送帯域幅）などの資源を予約する手順を定めたプロトコルであり、ＲＦＣ２２０５で基本仕様が規定されている。また、ＲＳＶＰはＩＰの上層のトランスポート層のＱｏＳ保証プロトコルである。実際のＱｏＳ保証サービスに関しては、ＩＥＴＦ(Internet Engineering Task Force)のワーキィンクグループ(IntservWG)にて規定されるＱｏＳ保証サービスをその予約対象とすることを前提としている。
【００２７】
現状、このＩｎｔｓｅｒｖＷＧで規定されているサービスは、次のとおりである。つまり、
（１）Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ：ネットワークが過負荷状態でも、通常のＢｅｓｔ−Ｅｆｆｏｒｔ型サービスと同等の性能(遅延、ビット誤り率など)を提供するサービス（ＲＦＣ２２１１規定）。
【００２８】
（２）Ｇｕａｒａｎｔｅｅｄ ＱｏＳ：エンド・エンドのすべてのデータ伝送を指定された遅延時間以内に抑えるサービス（ＲＦＣ２２１２規定）。
ＲＳＶＰはルータＲＴ及びホストＨＴに実装される。言い換えると、あるデータに対してＲＳＶＰメッセージで資源予約を行うＲＳＶＰ対応ホストと、ＲＳＶＰメッセージを受信して実際にネットワーク資源を予約するＲＳＶＰ対応ルータとが存在する。なお、資源予約はデータの受信ホストＨＴ（Ｒ）によって行われる。
【００２９】
データの送信ホストＨＴ（Ｔ）は送信するトラフィックの特性や経路を伝えるためにＲＳＶＰ Ｐａｔｈ（パス状態）メッセージＭＳＧ１を送信する。一方、受信ホストＨＴ（Ｒ）はＰａｔｈメッセージＭＳＧ１を受信し、その送信ホストＨＴ（Ｔ）のデータに対して資源の予約を行う場合、ＲＳＶＰ Ｒｅｓｖ（資源確保要求）メッセージＭＳＧ２を送信する。ＰａｔｈメッセージＭＳＧ１に則って構築された経路をたどって、ＲｅｓｖメッセージＭＳＧ２を途中のＲＳＶＰ対応ルータＲＴ及び送信ホストＨＴ（Ｔ）に伝えることにより、資源の予約が完了する。
【００３０】
なお、経路途上でＲＳＶＰをサポートしていないルータが存在した場合は、そのルータに対して帯域の保証は行われないが、データ伝送は透過的に行われる。また、ＲＳＶＰをサポートしているホストＨＴ及びルータＲＴの場合でも、要求される予約内容が受け入れられない場合、例えば既に別の帯域予約が存在して要求された帯域が確保できないなどの場合は、エラーメッセージを返して通知する。資源予約を解除する場合は、送信ホストＨＴ（Ｔ）がＰａｔｈＴｅａｒメッセージを送信し、受信ホストＨＴ（Ｒ）がＲｅｓｖＴｅａｒメッセージを送信する。
【００３１】
図４において、ＲＳＶＰを実装したシステム、つまりホストＨＴ及びルータＲＴでは、データの送信元であるアプリケーションＡＰＬがＲＳＶＰプロセス（ＲＳＶＰデーモン）ＰＲＣと通信しながらデータパケットをパケットクラスファイアＣＬＦに送る。パケットクラスファイアＣＬＦはＱｏＳ保証対象外のデータパケットを分類する。パケットスケジューラＳＣＤはパケットクラスファイアＣＬＦにより分類されたデータパケットを受け取り、ＲＳＶＰプロセスＰＲＣと通信しながら、ＱｏＳを保証するようにスケジューリングを行ってパケットを送出する。
【００３２】
ＲＳＶＰのＱｏＳ制御要求はデータ受信側からデータ送信経路上のそれぞれの中継システム内のアドミッションコントロールＡＤＭ及びポリシーコントロールＰＲＹの二つの決断モジュールに転送される。アドミッションコントロールＡＤＭは、システムが要求されたＱｏＳを確保できる十分な容量があるかどうかを決定し、ポリシーコントロールＰＲＹは、ＱｏＳを要求しているクライアント（ユーザ）がその確保を許可されているか否かを決定する。パケットクラスファイアＣＬＦにより分類されたパケットについていずれの条件も充足していれば、上記の要求されたＱｏＳを保証するようにパケットスケジューラＳＣＤの処理が行われる。なお、ルータＲＴにおけるルーティングプロセスＲＯＴはルーティングテーブルの処理機能である。
【００３３】
〔ＩＰ通信ネットワークシステムにおけるＱｏＳ保証動作〕
次に、図１に示す本発明の一実施の形態のＩＰ通信ネットワークシステム１の構成、つまり多数のクライアント端末６０と１つのサーバ８０とがＷＡＮ１０を経由してデータ通信を行うネットワーク形態において、ＱｏＳ保証装置が設置されている場合についての動作例を説明する。
【００３４】
図１，図２，図５及び図６を併せ参照すると、ＱｏＳ保証装置２０がデータパケットＰＫＴ１を入力インターフェース部２０１を通して受信した場合、ＱｏＳ保証対象トラフィックであるか否かを対象トラフィック判別部２０２で検査する。例えば、多数の情報系端末７０の送信するＷＷＷや電子メールのデータ及びファイル転送などが対象でない場合、それらは転送機能部２０３に送られ、そのままなにも処理されずに出力インターフェース部２１３を通して転送される。
【００３５】
すべてのＱｏＳ保証対象パケットは、カプセル化機能部２０４にて、登録されているＷＡＮ１０を挟んで対になるＱｏＳ保証装置３０のＩＰアドレスによりカプセル化される。言い換えると、ＱｏＳ保証装置２０，３０間で図５に示すようなトンネルを作り、すべてのＱｏＳ保証対象パケットがトンネリングで転送される。これにより、見かけ上、ＱｏＳ保証装置２０，３０がすべてのＱｏＳ保証対象パケットの送信元、つまりＲＳＶＰを実装した送信ホストとなり、これらのパケットに関してＲＳＶＰホストプロセス部２０５によりＲＳＶＰ ＰａｔｈメッセージＭＳＧ１を送信し、ＱｏＳ保証装置間のネットワーク資源予約を行う。
【００３６】
この結果、多数のクライアント端末６０から送信されるＱｏＳ保証対象パケット群が、見かけ上１つのセッションのデータであるようにして、ＲＳＶＰの１つの資源予約プロセスだけでＱｏＳを保証することができる。
【００３７】
通常、クライアント端末６０で動作している業務通信アプリケーションなどの通信レスポンス全体を保証する場合には、双方向のデータに対してＱｏＳ保証を行う必要があり、サーバ（ホストコンピュータ）８０からの応答データに関しては、そのネットワークに存在するＱｏＳ保証装置が同様の処理を行うことで実現する。
【００３８】
ＱｏＳ保証対象パケットの判別の方法としては、対象トラフィック判別部２０２でデータパケットの宛先アドレスを調べることで区別することができる。どの宛先アドレスがＱｏＳ保証となるかという条件は、条件データベース部２０６に予め登録しておき、これを参照する。これは例えば、クライアント・サーバ間通信において、対象のサーバのアドレスが指定されていた場合に、ＱｏＳ保証対象とする、という場合に適用できる。
【００３９】
つまり、情報系サーバ９０へのデータはＱｏＳ保証対象としない場合は、そのアドレスを条件データベース部２０６には登録しない。サーバ側から多数のクライアント端末（クライアント端末群）６０への応答データにＱｏＳ保証しようとする場合は、各クライアント端末６０のアドレスをサーバ側のＱｏＳ保証装置３０の条件データベース部２０６へ登録し、ＱｏＳ保証対象トラフィックを切り分ける。
【００４０】
また、サーバからの応答データを対象にする場合で、各クライアント端末６０のアドレスを条件とするか、あるいはクライアント端末数が極度に多い場合でかつそこにはＱｏＳ保証対象とするクライアント端末６０しか存在しない場合は、クライアント端末群が属するサブネットワーク、つまりＬＡＮ４０のアドレスのみを登録し、それを調べることでＱｏＳ保証対象トラフィックを切り分ける。これは当然クライアント側のＱｏＳ保証装置２０に適用しても良い。
【００４１】
ＱｏＳ保証対象パケットの判別の他の方法として、条件データベース部２０６に対象となる送信先アドレスを登録しておき、これを使用することもできる。条件データベース部２０６にＱｏＳ保証対象の通信を行うクライアント端末６０のアドレスを登録し、またサーバ側のＱｏＳ保証装置３０には対象とするサーバ８０のアドレスを登録しておくことで実現できる。
【００４２】
あるサブネットワーク（ＬＡＮ）のクライアント端末６０が多数の場合には、登録アドレス数が膨大になる可能性があり、また、あるサブネットワークにはＱｏＳ保証対象の通信しか行わないクライアント端末６０のみが存在する場合は、そのサブネットワークアドレスのみを条件データベース部２０６に登録しておけば良い。
【００４３】
また、例えば基幹業務通信に使われるプロトコルとして、上記ＳＮＡ、ＦＮＡなどがあるが、ＳＮＡｏｎＴＣＰ／ＩＰの場合はポート番号が「１０８」(SNA Gateway Access Server)、「１４３９」(/tcp Eicon X.25/SNA Gateway)、あるいはＦＮＡｏｎＴＣＰ／ＩＰの場合はポート番号が「４９２」または「４９３」(Transport Independent Convergence for FNA)と、ＩＡＮＡ(Internet Assigned Number Authority)のアサインメントより決まっているため、条件データベース部２０６にこれらの宛先ポート番号を登録し、ＱｏＳ保証対象パケットの判別にこれを使用することができる。
【００４４】
ＱｏＳ保証装置に存在するインターフェース部２０１に接続するサブネットワークには基幹業務端末のみが設置され、別のサブネットワークには一般のＰＣなどが接続されているといった形態で、基幹業務データ通信の品質のみ保証したい場合、上記サブネットワークの接続するＱｏＳ保証装置のインターフェース部２０１に入力するパケット群のみに関してＱｏＳを保証することもできる。この場合、ＱｏＳ保証装置の処理負荷は小さくできる。
【００４５】
多数のクライアント端末６０から送信されるデータを１つのＲＳＶＰプロセス、つまりＲＳＶＰホストプロセス部２０５で処理するためには、各パケットが１つのセッションで発生しているように見せ、それに対してＲＳＶＰで資源予約する必要がある。その為には、宛先アドレス、宛先ポート番号、プロトコルＩＤを同一にするようにトンネリングすれば良く、ＩＰヘッダ中のプロトコル番号がＵＤＰを示す「１７」でトランスポート層ヘッダ（ＵＤＰヘッダ）に宛先ポート番号フィールドを持つＩＰヘッダ及びＵＤＰヘッダで、各クライアント端末６０のパケットをカプセル化すれば良い（図６参照）。
【００４６】
具体的には、ＱｏＳ保証装置がトンネルに使用するＵＤＰポートと、トンネルの終端すなわち対になるＱｏＳ保証装置のＩＰアドレスをカプセル化機能部２０４に登録しておき、それらを利用してＱｏＳ保証対象パケットを切り分け後にカプセル化して送信すれば良い。
【００４７】
ＵＤＰ／ＩＰは処理としては軽いが、ロストデータやダメージデータについて再送機能は無い為、トンネリング部分でのデータ伝送の信頼性を高めるために、ＩＰヘッダ中のプロトコル番号が「６」であるＴＣＰ／ＩＰにカプセル化し、それらのパケットに対してＲＳＶＰで予約を行っても良い。
【００４８】
また、ＱｏＳ保証装置間でカプセル化されて伝送され、設定された特定のＵＤＰポートあるいはＴＣＰポートでＱｏＳ保証装置に受信されたデータは、さらに本来の宛先であるサーバ８０、あるいは逆方向では各クライアント端末６０に受信できるように、カプセル化解除機能部２０７にて、付加されていたＵＤＰ／ＩＰヘッダ、あるいはＴＣＰ／ＩＰヘッダを取り除き、本来のデータパケットＰＫＴ１またはＰＫＴ３として転送機能部２０３から送信される。
【００４９】
〔他のＩＰ通信ネットワークシステム構成におけるＱｏＳ保証動作〕
次に、図７に示す本発明の他の実施の形態のＩＰ通信ネットワークシステム３の構成、つまり多数のクライアント端末（クライアント端末群）６０，６１，６２が属するサブネットワーク（ＬＡＮ）４０，４１，４２とサーバ（ホストコンピュータ）８０，８１が属するサブネットワーク（ＬＡＮ）５０，５１とがＷＡＮ１０を挟んでそれぞれ複数存在しているネットワーク形態において、データ通信のＱｏＳ保証を行う場合についての動作例を説明する。
【００５０】
図２，図５，図６，図７，図８及び図９を併せ参照すると、宛先アドレスによりＱｏＳ保証対象パケットを切り分ける場合を考えると、クライアント側ＱｏＳ保証装置２０，２１，２２及びサーバ側ＱｏＳ保証装置３０，３１の条件データベース部２０６（各ＱｏＳ保証装置の構成要素は図２に示すＱｏＳ保証装置２０の構成要素に基づいて説明する）を図８及び図９にそれぞれ示すように、ＱｏＳ保証対象パケット切り分け用のアドレスとそのアドレスを持つパケットの宛先となるべきサーバのアドレス、逆方向ではクライアント端末６０，６１，６２の属するアドレスとそれらネットワークに存在するＱｏＳ保証装置２０，２１，２２のアドレスの対のエントリを条件の数だけ持たせる。
【００５１】
そして、ＱｏＳ保証対象パケット切り分け後に、カプセル化機能部２０４にパラメータとして渡して対応する対のＱｏＳ保証装置のアドレスでカプセル化して、それらのパケットに対して宛先毎にＲＳＶＰにより資源予約することにより、図７に示すように、複数の宛先ネットワークがある場合に対応可能である。
【００５２】
また、例えば図７に示すネットワーク形態において、サブネットワーク５０にサーバ８０が複数存在した場合には、図８に示す「サーバ／ホストコンピュータのアドレス」ではなく「サブネットワーク５０に存在するサーバ８０のアドレス」をすべて登録すれば対応可能である。
【００５３】
また、クライアント端末数が多い場合には、サーバ側ＱｏＳ保証装置の条件データベース部２０６には、すべてのクライアント端末のアドレスの代わりに、サブネットワークのアドレスを登録して、エントリ自体の数を減らしても良い。
【００５４】
また、例えば、特定の宛先ポート番号を基幹業務アプリケーション毎に使用している場合などでは、アドレスやサブネットワークアドレスの代わりに、ポート番号（カプセル化時のポート番号ではなく、オリジナルのデータＰＫＴ１の宛先ポート番号）を登録してこれを使用しても良い。
【００５５】
さらに、これらを組み合せて条件データベース部２０６に登録することによって、同じ宛先だが、使用するポート番号が異なる基幹業務アプリケーションを使用するクライアント端末が混在している場合にも、対応が可能である。
【００５６】
ＲＳＶＰでトラフィックのＱｏＳを保証するには、データの送信元がＲＳＶＰＰａｔｈメッセージＭＳＧ１でトラフィックのデータレートを指定しなければならない。通常、クライアント端末数の多い基幹業務通信やその他のクライアント・サーバ間通信では、各クライアント端末の合計のデータレート、あるいはサーバからの応答データのレートは比較的一定している。しかし、単一のマルチメディアのストリームデータとは違い、若干のデータレートの総計には差が出ることが考えられる。
【００５７】
そこで、ＱｏＳ保証を確実にするため、ＱｏＳ保証対象データの合計データ量をトラフィックレート監視部２０８によって監視し、差分が生じた場合に、差分に相当するダミーのデータパケットをダミーデータ発生部２１０で発生し送信して、データレートを一定にする。この場合のダミーデータパケットは、実際のデータがカプセル化されたものと同じ、すなわち宛先ＩＰアドレスが対のＱｏＳ保証装置のＩＰアドレス、トンネルデータ用のポート番号を持つＵＤＰ／ＩＰあるいはＴＣＰ／ＩＰデータである。
【００５８】
この場合、パケットのペイロードが一定のパケットを必要なだけ送信する、あるいはペイロードの大きさによって差分を補うなどの方法が考えられる。実際の運用では、ＲＳＶＰ ＰａｔｈメッセージＭＳＧ１で指定するデータレートはピーク時のレートより若干多目にし、差分をダミーデータパケットで補うという形態を採ることができる。この手法では、ダミーデータパケット分だけネットワークの帯域を無駄遣いすることになるが、次に述べる手法に比べて、ＱｏＳ保証装置としては軽いＲＳＶＰプロセスで動作することができる。
【００５９】
ＱｏＳ保証対象データの合計データ量をトラフィックレート監視部２０８によって監視し、差分が生じた場合に、そのデータレートに一致するパラメータを予約条件設定部２０９に指定して変更後のＲＳＶＰ ＰａｔｈメッセージＭＳＧ１を送信して、予約条件を実際のレートに合せる方法も採れる。僅かな変動毎に予約条件を変更して予約し直すのは、ＲＳＶＰプロセスとして処理が重くなる可能性があるため、例えば前回予約時から１０Ｋｂｐｓの変動が検出されたとき毎に予約条件を変更するという運用が考えられる。
【００６０】
ＲＳＶＰによりネットワーク資源予約を開始するトリガとしては、資源の有効利用や処理負荷の低減のため、対象トラフィック判別部２０２にてＱｏＳ保証対象のトラフィックを検出した時点で、ＲＳＶＰホストプロセス部２０５に指示してＰａｔｈメッセージＭＳＧ１の送信を開始する。
【００６１】
また、ＱｏＳ保証装置にタイマ２１１を設け、対象トラフィック判別部２０２にてＱｏＳ保証対象のトラフィックが検出されなくなった時点でタイマ２１１を動作し、設定された時間が満了した時点で、タイマ２１１からＲＳＶＰホストプロセス部２０５に指示を出し、ＲＳＶＰ ＰａｔｈＴｅａｒメッセージを送信して資源予約を解除することで、同様に資源の有効利用や処理負荷の低減が可能になる。
【００６２】
また、オーダーエントリ業務など、例えば１０：００〜１８：００といったような、企業の顧客に対する営業時間帯のみに行われる業務のデータ通信に対してＱｏＳ保証を行う場合は、スケジュールタイマ２１２を設けて、ある時間の範囲では常に資源予約を行う、という運用を採ることができる。
【００６３】
マルチメディアデータなどが同時に頻繁に使用されるような環境では、そのマルチメディアデータなどをＲＳＶＰでＱｏＳ保証して伝送することがあるが、基幹業務などの業務系のデータ通信に対してＱｏＳ保証を開始しようとした場合、他のセッションによりネットワーク帯域が使用されていて、業務用に確保したい帯域が確保できない場合もあり得るが、これを避けるため、ＱｏＳ保証装置の起動時にＲＳＶＰのシグナリング、すなわちＰａｔｈメッセージＭＳＧ１やＲｅｓｖメッセージＭＳＧ２の送信を開始し、常に予約しておくとよい。
【００６４】
この場合は、ＲＳＶＰによる他のデータに対する資源予約が、ＱｏＳ保証対象データ用に確保している予約の分だけ利用できないだけで、ＱｏＳ保証対象データが無い場合には、伝送路帯域自体は他のトラフィックによってすべて使用することができるので、大きな問題とはならない。
【００６５】
〔変形例〕
上述したＱｏＳ保証機能は、サブネットワークの入口もしくはＷＡＮへの入口に設置されるルータ、またデータの経路上に存在するワークステーション（ＷＳ）やＰＣサーバなどのネットワークサーバに実装してもよい。この場合、転送機能部に通常のルータが持つルーティング機能を持たせれば良い。
【００６６】
また、企業内ＩＰ網（イントラネット網）としてのルータネットワークの内部のルータすべてが上述したＱｏＳ保証機能を持つ必要は無いため、例えば製品として安価にするために、ＷＳやＰＣに同機能を持たせ、サブネットワーク毎に１つ設置すれば良い。この場合、各クライアント端末やサーバ（ホストコンピュータ）はこの装置宛てにデータを送信することになり、ＱｏＳ保証対象パケットの切り分けには、送信元アドレスや宛先ポート番号を条件データベース部に設定して使用することになる。
［その他］
（付記１）多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を有する第１のＱｏＳ保証装置と；
前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置であって；
カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を有する第２のＱｏＳ保証装置と；
を備えることを特徴とするＩＰ通信ネットワークシステム。
（付記２）多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を備えることを特徴とするＱｏＳ保証装置。
（付記３）カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を備える前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置に対向することを特徴とする付記２記載のＱｏＳ保証装置。
（付記４）前記トランスポート層対応のＱｏＳ保証プロトコルがＲＳＶＰプロトコルであることを特徴とする付記２記載のＱｏＳ保証装置。
（付記５）前記ＩＰパケット交換網がイントラネット網であることを特徴とする付記２記載のＱｏＳ保証装置。
（付記６）前記ＩＰパケット交換網がワイドエリアネットワークから構成されていることを特徴とする付記２記載のＱｏＳ保証装置。
（付記７）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの宛先アドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記８）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの宛先ネットワークアドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記９）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの送信元アドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１０）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの送信元ネットワークアドレスに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１１）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの宛先ポート番号に基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１２）前記判別手段は、前記多数のデータ通信端末から送信される前記データパケットのそれぞれの受信インターフェースに基づいて、前記特定データパケットを判別し、前記対象トラフィックを分類することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１３）前記カプセル構成手段は、前記トラフィックの集合を１つのセッションと見なせるように、前記ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在する対向装置のインターフェースのアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをＵＤＰ／ＩＰでカプセルに構成することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１４）前記カプセル構成手段は、前記トラフィックの集合を１つのセッションと見なせるように、前記ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在する対向装置のインターフェースのアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットをＴＣＰ／ＩＰでカプセルに構成することを特徴とする付記２記載のＱｏＳ保証装置。
（付記１５）ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスとＱｏＳ保証対象の前記特定データパケットの宛先アドレスとの組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先アドレスを調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１６）ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスと前記反対側のＱｏＳ保証装置のそれぞれに接続しているサブネットワークのネットワークアドレスとの組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先ネットワークアドレスを調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１７）ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスとＱｏＳ保証対象の前記特定データパケットの宛先ポート番号との組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先ポート番号を調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１８）前記ＱｏＳ保証対象トラフィックの総データ量を監視し、伝送レートに変動があった場合に、前記ＱｏＳ保証対象トラフィックの総伝送レートを一定に保つために送信する、差分レート分のダミーデータパケットを発生する発生手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記１９）前記ＱｏＳ保証対象トラフィックの総データ量を監視し、伝送レートに変動があった場合に、前記ＱｏＳ保証プロトコルに則った資源予約条件を動的に変更するための変更手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記２０）前記ＱｏＳ保証対象トラフィックを監視し、前記ＱｏＳ保証対象トラフィックが受信されなかった場合にタイマを起動し、このタイマに設定された時間が満了するまでに、再び前記ＱｏＳ保証対象トラフィックが受信されない場合は、前記ＱｏＳ保証プロトコルに則った資源予約を解除する予約解除手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記２１）スケジュールタイマを参照して、予め定めた時間の範囲で前記ＱｏＳ保証プロトコルに則った資源予約を実行する実行手段を更に備えることを特徴とする付記２記載のＱｏＳ保証装置。
（付記２２）前記第１及び第２のＱｏＳ保証装置の有する機能をネットワーク経路上に存在する他の装置に実装したことを特徴とする付記１記載のＩＰ通信ネットワークシステム。
（付記２３）前記第１及び第２のＱｏＳ保証装置の有する機能をネットワーク経路上に存在しない他の装置に実装したことを特徴とする付記１記載のＩＰ通信ネットワークシステム。
【００６７】
【発明の効果】
以上説明したように、本発明によれば、主としてＲＳＶＰ対応ネットワーク機器が導入されている企業内ＩＰ網などにおいて、本来ＲＳＶＰによるＱｏＳ保証が難しい、重要通信である基幹業務などの多数端末がランダムに送信するデータパケットの集合に対するＱｏＳ保証が実現でき、企業ユースの強い通信プロトコルのＩＰへの統合やネットワークの統合を実現可能とし、ネットワーク管理自体の容易化やそのコストの低減などを図ることができる。
【００６８】
また、本発明によれば、基幹業務データ通信だけではなく、クライアント・サーバ環境における通信応答性の向上やその他の重要通信などにも適用することができ、重要度に応じた通信品質を提供できる。
【図面の簡単な説明】
【図１】 本発明の一実施の形態のＩＰ通信ネットワークシステムの構成を示すブロック図。
【図２】 ＱｏＳ保証装置の詳細構成を示すブロック図。
【図３】 ＲＳＶＰのシグナリングを説明するための図。
【図４】 ＲＳＶＰの資源確保システムを示すブロック図。
【図５】 ＩＰ通信ネットワークシステムにおけるトンネリングの概念を説明するための図。
【図６】 ＵＤＰ／ＩＰによるデータパケットのカプセル化を示す図。
【図７】 本発明の他の実施の形態のＩＰ通信ネットワークシステムの構成を示すブロック図。
【図８】 クライアント側ＱｏＳ保証装置の条件データベースを示す図。
【図９】 サーバ側ＱｏＳ保証装置の条件データベースを示す図。
【符号の説明】
１，３ ＩＰ通信ネットワークシステム
２ ＱｏＳ保証対象領域
１０ ＷＡＮ（ルータネットワーク）
２０，２１，２２，３０，３１ ＱｏＳ保証装置
４０，４１，４２，５０，５１ ＬＡＮ（サブネットワーク）
６０，６１，６２ クライアント端末
７０ 情報系端末
８０，８１ サーバ（ホストコンピュータ）
９０ 情報系サーバ
Claims (12)
- 多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットのみをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を有する第１のＱｏＳ保証装置と；
前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置であって；
カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を有する第２のＱｏＳ保証装置と；
を備えることを特徴とするＩＰ通信ネットワークシステム。 - 多数のデータ通信端末から送信されるデータパケットのうちの特定の条件に合致する特定データパケットの集合をトランスポート層対応のＱｏＳ保証プロトコルに則って品質保証するために、対象トラフィックを分類する判別手段と；
前記トラフィックの集合を１つのセッションと見なせるように、ＩＰパケット交換網のＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のアドレスに基づき、ＱｏＳ保証対象の前記特定データパケットのみをカプセルに構成するカプセル構成手段と；
カプセルに構成された前記特定データパケットの集合に対して前記ＱｏＳ保証プロトコルに則って資源予約を行う資源予約手段と；
を備えることを特徴とするＱｏＳ保証装置。 - カプセルに構成され、かつＱｏＳ保証された前記特定データパケットを前記ＩＰパケット交換網を通して受信する受信手段と；
受信した前記特定データパケットを実際の宛先に送信するために、カプセル構成を解除するカプセル解除手段と；
を備える前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置に対向することを特徴とする請求項２記載のＱｏＳ保証装置。 - ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスとＱｏＳ保証対象の前記特定データパケットの宛先アドレスとの組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先アドレスを調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスと前記反対側のＱｏＳ保証装置のそれぞれに接続しているサブネットワークのネットワークアドレスとの組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先ネットワークアドレスを調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- ＱｏＳ保証対象の前記特定データパケットの集合の宛先が複数である場合、前記ＱｏＳ保証対象領域の反対側に存在するＱｏＳ保証装置のそれぞれのアドレスとＱｏＳ保証対象の前記特定データパケットの宛先ポート番号との組対応を記憶する記憶手段を参照して、前記特定データパケットのそれぞれの宛先ポート番号を調べ、宛先となる前記反対側のＱｏＳ保証装置を決定する決定手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- 前記ＱｏＳ保証対象トラフィックの総データ量を監視し、伝送レートに変動があった場合に、前記ＱｏＳ保証対象トラフィックの総伝送レートを一定に保つために送信する、差分レート分のダミーデータパケットを発生する発生手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- 前記ＱｏＳ保証対象トラフィックの総データ量を監視し、伝送レートに変動があった場合に、前記ＱｏＳ保証プロトコルに則った資源予約条件を動的に変更するための変更手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- 前記ＱｏＳ保証対象トラフィックを監視し、前記ＱｏＳ保証対象トラフィックが受信されなかった場合にタイマを起動し、このタイマに設定された時間が満了するまでに、再び前記ＱｏＳ保証対象トラフィックが受信されない場合は、前記ＱｏＳ保証プロトコルに則った資源予約を解除する予約解除手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- スケジュールタイマを参照して、予め定めた時間の範囲で前記ＱｏＳ保証プロトコルに則った資源予約を実行する実行手段を更に備えることを特徴とする請求項２記載のＱｏＳ保証装置。
- 前記特定の条件に合致する特定データパケットが、前記多数のデータ通信端末からランダムに送信されるバーストデータであることを特徴とする請求項１記載のＩＰ通信ネットワークシステム。
- 前記特定の条件に合致する特定データパケットが、前記多数のデータ通信端末からランダムに送信されるバーストデータであることを特徴とする請求項２記載のＱｏＳ保証装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22041999A JP4454072B2 (ja) | 1999-08-03 | 1999-08-03 | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 |
| US09/587,352 US6977896B1 (en) | 1999-08-03 | 2000-06-05 | IP communications network system and QoS guaranteeing apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22041999A JP4454072B2 (ja) | 1999-08-03 | 1999-08-03 | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001045066A JP2001045066A (ja) | 2001-02-16 |
| JP4454072B2 true JP4454072B2 (ja) | 2010-04-21 |
Family
ID=16750824
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22041999A Expired - Fee Related JP4454072B2 (ja) | 1999-08-03 | 1999-08-03 | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6977896B1 (ja) |
| JP (1) | JP4454072B2 (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3390384B2 (ja) * | 1999-11-04 | 2003-03-24 | 日本電気通信システム株式会社 | Ｔｃｐ／ｉｐにおけるコネクション設定方法および方式 |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| US7886054B1 (en) | 2000-10-11 | 2011-02-08 | Siddhartha Nag | Graphical user interface (GUI) for administering a network implementing media aggregation |
| US7774468B1 (en) | 2000-07-28 | 2010-08-10 | Siddhartha Nag | Network traffic admission control |
| US7788354B2 (en) | 2000-07-28 | 2010-08-31 | Siddhartha Nag | End-to-end service quality in a voice over Internet Protocol (VoIP) Network |
| US7013338B1 (en) * | 2000-07-28 | 2006-03-14 | Prominence Networks, Inc. | Multiplexing several individual application sessions over a pre-allocated reservation protocol session |
| JP2003143212A (ja) * | 2001-11-01 | 2003-05-16 | Fujitsu Ltd | サーバとクラアイントとの接続方法およびルータ装置 |
| JP3792631B2 (ja) * | 2002-09-30 | 2006-07-05 | Ｎｅｃインフロンティア株式会社 | パケット伝送方法及び装置、それを用いた基地局装置、無線ｌａｎ端末装置、無線ｌａｎシステム |
| KR100453324B1 (ko) * | 2002-11-18 | 2004-10-20 | 한국전자통신연구원 | 인터넷 서비스품질 보장을 위한 라우팅 장치 및 그 방법 |
| WO2005008977A1 (ja) * | 2003-07-18 | 2005-01-27 | Fujitsu Limited | パケット転送方法及び装置 |
| US7406533B2 (en) * | 2003-10-08 | 2008-07-29 | Seiko Epson Corporation | Method and apparatus for tunneling data through a single port |
| US7392323B2 (en) * | 2004-11-16 | 2008-06-24 | Seiko Epson Corporation | Method and apparatus for tunneling data using a single simulated stateful TCP connection |
| US7620181B2 (en) * | 2005-04-20 | 2009-11-17 | Harris Corporation | Communications system with minimum error cryptographic resynchronization |
| US8428074B2 (en) | 2005-04-29 | 2013-04-23 | Prom Ks Mgmt Limited Liability Company | Back-to back H.323 proxy gatekeeper |
| JP2007134971A (ja) * | 2005-11-10 | 2007-05-31 | Nippon Hoso Kyokai <Nhk> | 電力線通信多重装置 |
| KR100901206B1 (ko) * | 2007-12-10 | 2009-06-08 | 한국전자통신연구원 | 기지국과 네트워크 개체간의 서비스 품질 보장이 가능한데이터 교환방법 |
| US9313108B2 (en) * | 2007-12-14 | 2016-04-12 | Ericsson Ab | Flexible and scalable method and apparatus for dynamic subscriber services configuration and management |
| JP5051056B2 (ja) * | 2008-08-13 | 2012-10-17 | 富士通株式会社 | 通信システム |
| JP5044519B2 (ja) * | 2008-10-06 | 2012-10-10 | アラクサラネットワークス株式会社 | 受信側装置、伝送装置、伝送方法およびプログラム |
| EP2257003B1 (en) | 2009-05-29 | 2012-09-12 | Alcatel Lucent | A data packet processing device and method generating measurable resource usage |
| US8638778B2 (en) * | 2009-09-11 | 2014-01-28 | Cisco Technology, Inc. | Performance measurement in a network supporting multiprotocol label switching (MPLS) |
| US9007909B2 (en) * | 2011-03-09 | 2015-04-14 | International Business Machines Corporation | Link layer reservation of switch queue capacity |
| US9769116B2 (en) * | 2011-09-16 | 2017-09-19 | Wilmerding Communications Llc | Encapsulating traffic while preserving packet characteristics |
| WO2014000307A1 (zh) * | 2012-06-30 | 2014-01-03 | 华为技术有限公司 | 数据传输方法、网元设备及通信*** |
| US9525639B2 (en) * | 2014-05-28 | 2016-12-20 | Broadcom Corporation | 2.5 GBPS/5GBPS ethernet communications over a full duplex communication channel |
| US9647982B2 (en) | 2015-03-03 | 2017-05-09 | Oracle International Corporation | Peer tunneling for real-time communications |
| US10015287B2 (en) * | 2015-03-04 | 2018-07-03 | Oracle International Corporation | Efficient tunneled streams for real-time communications |
| US10142229B2 (en) * | 2015-03-13 | 2018-11-27 | Oracle International Corporation | Concealed datagram-based tunnel for real-time communications |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6069889A (en) * | 1996-10-02 | 2000-05-30 | International Business Machines Corporation | Aggregation of data flows on switched network paths |
| US6091709A (en) * | 1997-11-25 | 2000-07-18 | International Business Machines Corporation | Quality of service management for packet switched networks |
| US6418139B1 (en) * | 1998-11-25 | 2002-07-09 | Nortel Networks Limited | Mechanism to guarantee quality of service to real-time traffic on IP networks |
| US6519254B1 (en) * | 1999-02-26 | 2003-02-11 | Lucent Technologies Inc. | RSVP-based tunnel protocol providing integrated services |
| US6538416B1 (en) * | 1999-03-09 | 2003-03-25 | Lucent Technologies Inc. | Border gateway reservation protocol for tree-based aggregation of inter-domain reservations |
-
1999
- 1999-08-03 JP JP22041999A patent/JP4454072B2/ja not_active Expired - Fee Related
-
2000
- 2000-06-05 US US09/587,352 patent/US6977896B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6977896B1 (en) | 2005-12-20 |
| JP2001045066A (ja) | 2001-02-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4454072B2 (ja) | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 | |
| US9832169B2 (en) | Method and system for communicating over a segmented virtual private network (VPN) | |
| EP1333642B1 (en) | Method and system for integrating performance enhancing functions in a virtual private network (VPN) | |
| US7643416B2 (en) | Method and system for adaptively applying performance enhancing functions | |
| US9426078B2 (en) | Systems and methods for dynamic quality of service | |
| US7525994B2 (en) | Packet data flow identification for multiplexing | |
| US7835285B2 (en) | Quality of service, policy enhanced hierarchical disruption tolerant networking system and method | |
| EP1443713A2 (en) | Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network | |
| EP1443731A2 (en) | Method and system for providing security in performance enhanced network | |
| JP3985638B2 (ja) | Ｒｓｖｐ代理応答ルータ、ｒｓｖｐ代理応答システム及びそれに用いるｒｓｖｐ代理応答方法 | |
| US20070008884A1 (en) | Immediate ready implementation of virtually congestion free guarantedd service capable network | |
| US20080002663A1 (en) | Virtual network interface card loopback fastpath | |
| CA2353339A1 (en) | Method and system for prioritizing traffic in a network | |
| US8359405B1 (en) | Performance enhancing proxy and method for enhancing performance | |
| Adami et al. | TCP/IP-based multimedia applications and services over satellite links: experience from an ASI/CNIT project | |
| JP3614006B2 (ja) | 非対称経路利用通信システム、および、非対称経路利用通信方法 | |
| JPH11331257A (ja) | 異ネットワーク間接続方法およびルータ装置 | |
| Brown et al. | Phoebus: A session protocol for dynamic and heterogeneous networks | |
| Kodama et al. | TCP Multi-Stream Data Transfer using Multiple Network Interface Cards | |
| JP2004032453A (ja) | パケット通信システムとこのシステムで使用されるパケット転送装置及びパケット転送制御プログラム | |
| Cruickshank et al. | Broadband Satellite Multimedia (BSM) security architecture and interworking with performance enhancing proxies | |
| Seo et al. | Design of sctp-scf | |
| Lee et al. | Reliable multicasting in the Internet: experience with the IRMA architecture | |
| Prudich | Dynamic Routing Using an Overlay Network of Relays | |
| Schmida et al. | QoS based Real Time Audio Streaming on IPv Networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060222 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070918 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070925 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071122 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080226 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100202 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130212 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |