JP2003158543A

JP2003158543A - 中継装置及び中継方法

Info

Publication number: JP2003158543A
Application number: JP2001357848A
Authority: JP
Inventors: Mitsuru Higashiyama; 東山　　満; Takahiro Yamaguchi; 貴宏山口
Original assignee: Anritsu Corp
Current assignee: Anritsu Corp
Priority date: 2001-11-22
Filing date: 2001-11-22
Publication date: 2003-05-30
Also published as: US20030097460A1

Abstract

(57)【要約】【課題】ユーザの設定の負担が増えず、シグナリング
が不要で通信品質を損なわず帯域を確保する。【解決手段】通信ノード間のセッション時に受信した
パケットは、バッファキュー８へのキューイングととも
に解析部６に送信される。解析部６は、データセッショ
ン情報をトレースしてポート番号、必要帯域を認識する
と、帯域割り当てを予約受付制御部７に依頼する。予約
受付制御部７は、内部リソースの状態を判断し、ポート
番号、必要帯域に基づいて帯域保証が可能か否か判別
し、バッファキュー８の帯域割り当てを行う。帯域確保
可能と判断した時は、フローテーブル２にそのフローと
新しいキューＩＤが格納され、トラフィック管理データ
ベース３にそのセッションのフローと帯域が登録され
る。帯域割り当てが不可能な場合は、そのセッションの
パケットがベストエフォートキューにバッファリングさ
れる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のネットワー
ク間を接続してパケットを相互通信するための中継装置
及び中継方法に関し、特にインターネットを介して二つ
の通信ノード間で動画配信と音声、ビデオ通信を行うに
あたって、通信品質（ＱｏＳ）を維持して通信を行うの
に好適な中継装置及び中継方法に関する。

【０００２】

【従来の技術】インターネットは、全世界に広がるＴＣ
Ｐ／ＩＰプロトコルを使ったコンピュータ・ネットワー
クであり、これまで静的なＷｅｂページの表示やテキス
トベースの電子メールを配送するのが主な役割であっ
た。ところが、ここ数年、インターネットはＡＤＳＬ(A
symmetric Digital Subscriber Line)，ＣＡＴＶ(cable
television,community antenna television) などの高
速アクセスサービスを背景にブロードバンド化が加速し
ている。

【０００３】このように、インターネットは、ブロード
バンド化することにより、ｅ−ｃｏｍｍｅｒｃｅやエン
ターテイメント、マルチメディアのコンテンツを運ぶた
めのインフラとして役割を変化させている。特に、アプ
リケーションの中において、動画配信(Video Streamin
g) と音声、ビデオ通信(Voice/Video Conference)がビ
ジネス、エンターテイメントの場で重要視されている。

【０００４】ところで、インターネット上で動画配信、
音声、ビデオ通信などのストリーミングデータを配信す
る場合、パケットのドロップとドロップによる映像、音
声の乱れは重大な問題である。このため、ブロードバン
ド化しマルチメディアを配信する役割を果たすインター
ネットにとっては、通信品質（ＱｏＳ）をいかに保証し
ていくかが鍵となる。

【０００５】古くから利用されてきたデジタル専用線な
どの通信は、デジタルデータを送出する時間を一定時間
（タイム・スロット）毎に変えて複数データを多重する
時分割多重方式が採用されている。この時分割多重方式
では、あるユーザの通信が通信回線上において一定の割
合で保証されていた。

【０００６】例えば１５５Ｍｂｐｓの容量を持つ通信回
線上では、１．５Ｍｂｐｓの通信サービスを１００人ま
でのユーザが利用することができる。この場合、１５５
Ｍｂｐｓの帯域を１００のチャンネルに時間分割し、個
々のチャンネルを利用者に割り当てていた。このよう
に、通信回線上で、通信が決められた帯域で割り当てら
れた状態を「帯域が保証された状態」と呼んでいる。

【０００７】これに対し、インターネットはパケット多
重方式を採用している。すなわち、インターネットの場
合、パケット毎に宛先と送信元のユーザを識別できるよ
うなアドレスを持ったパケットが回線上に流れる。この
ため、インターネットの回線上には物理的なチャンネル
という概念はなく、全てのユーザのパケットが回線や機
器の能力の限界まで混在して回線上を流れている。

【０００８】従って、複数のユーザの通信が混在し、回
線や機器の能力を超えてしまったときには、どのユーザ
のデータも一様に廃棄されることになる。このように、
インターネットは、全体の通信容量が空いているときは
使い放題ではあるが、通信容量がオーバーしたときには
通信内容に関わらず廃棄されてしまう。このような方式
を「ベストエフォート」と呼んでいる。

【０００９】１９５０年に誕生したインターネットは、
もともと実験、研究用のネットワークであったため、
「ベストエフォート」方式も受け入れることができた。
しかし、１９９０年台になり、インターネットがビジネ
スにも利用されるようになるに連れ、通信品質（Ｑｏ
Ｓ）の必要性が叫ばれるようになった。

【００１０】そこで、インターネット上でＱｏＳを実現
するため、研究者や装置メーカが中心となってＩｎｔＳ
ｅｒｖ(Integrated Service)とＤｉｆｆＳｅｒｖ(Diffe
rentiated Service)の二つの方式が考えられた。

【００１１】ＩｎｔＳｅｒｖは、デジタル専用線やＡＴ
Ｍ(asynchronous transfer mode)のように通信回線上の
個々の通信に対し、要求された帯域と品質を割り当てる
方式をとっている。そして、Ｉｎｔｓｅｒｖでは、個々
の通信のことをフロー（Ｆｌｏｗ）と呼んでいる。フロ
ーは、例えばＡさんとＢさんの間で行っているファイル
Ｘの転送が１つの単位になっている。従って、Ａさんと
Ｂさんが別のファイルＹを転送するときには別のフロー
が割り当てられることになる。

【００１２】Ｉｎｔｓｅｖでの帯域の割り当ては、ＲＳ
ＶＰ(ReSource reserVation Protocol) という制御プロ
トコルが使用される。ＲＳＶＰは、インターネットを介
した２点間で、帯域やバッファなどの資源を確保し、Ｑ
ｏＳ制御を実現するためのＲＦＣ２２０５で規定された
ＴＣＰ／ＩＰの上位プロトコルである。このＲＳＶＰは
送信ノードと受信ノード間で交換されるが、交換の途中
経路にあるルータがその内容をみて、ルータが持ってい
る通信用のバッファキューと回線の帯域設定を行ってい
る。

【００１３】図１２及び図１３は送信ノードと受信ノー
ドとの間でＲＳＶＰにより帯域確保を依頼する場合の簡
略説明図である。

【００１４】図１２に示すように、送信ノードは、実際
の送信を始める前に受信ノードのいる方向に向けて帯域
予約のための要求メッセージとして、Ｐａｔｈメッセー
ジを送信する。このＰａｔｈメッセージは、ルータから
ルータへと実際の送信経路に沿って受信ノードに橋渡し
されていく。

【００１５】受信ノードは、次々とルータを介して橋渡
しされるＰａｔｈメッセージを受け取ると、自分が要求
された帯域のデータを受け取る準備を行う。そして、図
１３に示すように、受信ノードは、先程のＰａｔｈメッ
セージと反対の方向にＲｅｓｖメッセージを送信する。
このＲｅｓｖメッセージもルータからルータへと送信ノ
ードに向かって橋渡しされていく。この際、Ｒｅｓｖメ
ッセージを受け取った各ルータは、実際に要求された帯
域の確保を行う。この帯域の確保は、ルータ内部にある
送受信のためのバッファキューを、要求された帯域が処
理できるだけの容量を割り当てる。そして、バッファキ
ューのスケジュールの設定を要求された通信品質に設定
する。

【００１６】なお、ＡＴＭのようなＱｏＳが保証できる
回線につながっている場合は、回線の帯域予約も同時に
行う。

【００１７】このように、ＩｎｔＳｅｒｖは、帯域の確
保をフロー単位で行い、帯域の設定や品質の設定を細か
く制御できる優れた技術である。しかし、ＲＳＶＰをイ
ンターネット上で適用するには「ＲＳＶＰはスケールし
ない」という問題を抱えていた。

【００１８】例えばフローの数が１００から１０００の
位であればＲＳＶＰは十分機能する。しかし、インター
ネットでは、コアと呼ばれる中心部分で考えると、フロ
ーの数が数百万から数千万の桁に上る。こうなると、イ
ンターネットコアにいるルータは、常に膨大な量のＲＳ
ＶＰパケットの予約と開放のパケットを送受信し、その
フローを内部で管理しなければならず、処理性能が耐え
られなくなる。

【００１９】また、ＲＳＶＰは、通信ノードのエンド−
エンドでやり取りするが、その途中経路にいる全てのル
ータがＲＳＶＰをサポートしている必要がある。インタ
ーネットは、何千というインターネットプロバイダが網
の目の様に接続して構成されている。このため、あるプ
ロバイダの使っているたった１つのルータがＲＳＶＰを
サポートしていないだけでも、ＲＳＶＰ自体が機能しな
くなるという問題があった。

【００２０】このように、ＩｎｔＳｅｒｖは、優れた機
能を持ちながらも、プロバイダ毎に運用されるインター
ネットはサポートしていなかった。

【００２１】これに対し、ＤｉｆｆＳｅｒｖは、Ｉｎｔ
Ｓｅｒｖのスケールしないという問題に直面した研究者
がインターネットに適用できるＱｏＳ技術として生み出
された。ＤｉｆｆＳｅｒｖは、ＴＣＰ／ＩＰネットワー
ク上のＱｏＳ制御技術の一つであり、図１４のＩＰデー
タブロックのフォーマットに示すように、ＩＰヘッダ中
の８ビットのＴＯＳ(Type Of Service) という領域をト
ラフィッククラスを識別するコードポイントのマーキン
グのために再定義したものである。

【００２２】ＤｉｆｆＳｅｒｖでは、ＰＨＢ(Per Hop B
ehaivor)トラフィッククラスとそれに対応したバッファ
キューを最大６４個持っている。それぞれのＰＨＢは、
バッファキューの属性により、「帯域が広くて遅延が小
さい」、「帯域が狭くて遅延が大きい」といった特性が
決められている。ＤｉｆｆＳｅｒｖを通過するパケット
はどのトラフィック特性で通信したいのかを決めてお
き、そのＰＨＢに対応したコードポイントをマーキング
する。

【００２３】ＤｉｆｆＳｅｒｖは、「ベストエフォート
よりましな通信品質」を目指して開発された。帯域が保
証されていないため、いくら優先度の高いコードポイン
トを持っていても、そのＰＨＢを用いるトラフィックが
大量に流入すると、結局、輻輳が発生してしまう。ま
た、パケットのドロップ率が小さいＰＨＢでも、ドロッ
プ率は０ではなく、帯域を保証しているわけではない。

【００２４】ところで、動画配信と音声、ビデオ通信
は、他のＷｅｂ（ＨＴＴＰ）やｅｍａｉｌ（ＰＯＰ３／
ＳＭＴＰ）と比べると複雑な動作をしている。動画配信
と音声、ビデオ通信の場合、通信ノード間で最初にコン
トールセッションという接続管理のための通信を行い、
その中で、ビデオや音声データを通すためのパラメータ
の交換と双方の準備が行われるものが多い。そして、準
備が整った段階でビデオや音声を通すデータセッション
が開始される。

【００２５】このビデオや音声などのストリーム配信用
のアプリケーションとしては、ＲＴＳＰというコントロ
ールセッション用のプロトコルとＲＴＰというデータセ
ッション用のプロトコルで通信を行うものが知られてい
る。

【００２６】図１５は上記アプリケーションによりクラ
イアントとサーバとの間でデータ通信を行う際の手順を
示している。この図１５に示すように、上記アプリケー
ションのＲＴＳＰは、データセッションをはじめる前に
データに要求される帯域（ＲＴＳＰ（Ａｔｔｒｉｂｕｔ
ｅ／Ｂａｎｄｗｉｄｔｈ）において文字列の中のビット
レートとして与えられる）を通知し、クライアントから
データセッションに使用するＵＤＰポート番号を通知し
ている。そして、ＲＴＰのセッションを作成する準備が
整った上で、サーバからクライアントに対してクライア
ントから前もって通知されていたポート番号に対してＵ
ＤＰパケットの送信をはじめる。

【００２７】

【発明が解決しようとする課題】ところが、帯域が確保
されていないベストエフォートネットワークでは、輻輳
時にはＲＴＰパケットが途中の経路で失われ、動画や音
声の品質の悪化、あるいはアプリケーション自体のタイ
ムアウトによる終了を引き起こしてしまうという問題が
あった。

【００２８】そこで、本発明は、上記問題点に鑑みてな
されたものであり、ユーザの設定の負担が増えず、か
つ、シグナリングが不要で通信品質を損なうことなく帯
域を自動的に確保することができる中継装置及び中継方
法を提供することを目的としている。

【００２９】

【課題を解決するための手段】上記目的を達成するた
め、本発明の請求項１の発明に係る中継装置は、二つの
通信ノード間の通信を中継する中継装置において、前記
二つの通信ノード間で一方のノードから他方のノードへ
送られる通信の内容を監視することによって、該通信の
内容に含まれる情報であって、前記二つの通信ノードの
一方から他方へ送信するために必要な帯域に関連する前
記情報を検出する検出手段６と、前記必要な帯域が割り
当て可能なバッファ手段８と、前記検出手段によって検
出された前記情報に基づいて前記必要な帯域を前記バッ
ファ手段に割り当てる帯域割当手段７とを備えたことを
特徴とする。

【００３０】請求項２の発明に係る中継方法は、二つの
通信ノード間の通信を中継する中継方法であって、前記
二つの通信ノード間で一方のノードから他方のノードへ
送られる通信の内容を監視することによって、該通信の
内容に含まれる情報であって、前記二つの通信ノードの
一方から他方へ送信するために必要な帯域に関連する前
記情報を検出する段階と、検出された前記情報に基づい
て前記必要な帯域を割り当てる段階とを含むことを特徴
とする。

【００３１】

【発明の実施の形態】図１乃至図１１は本発明の中継装
置及び中継方法に関する図であり、図１は中継装置の機
能ブロック図、図２はフローテーブルの内部構成の一例
を示す図、図３はトラフィック管理データベースの内部
構成の一例を示す図、図４はアプリケーション別固定帯
域情報データベースの内部構成の一例を示す図、図５は
コントロールセッション解析部の動作フローチャート、
図６は予約受付制御部の動作フローチャート、図７乃至
図９はＲＴＳＰセッションに対する動作の一例を説明す
るための図、図１０は新規セッション登録後のフローテ
ーブルの内部構成の一例を示す図、図１１は新規セッシ
ョン登録後のトラフィック管理データベースの内部構成
の一例を示す図である。

【００３２】本発明の中継装置は、二つの通信ノード間
の通信内容を監視し、この監視した通信内容から必要帯
域情報を検出し、この検出した必要帯域情報を含むデー
タセッション情報からそのデータセッションの帯域保証
が可能か否かを判別し、帯域保証が可能と判別したとき
に、内部バッファの帯域の割り当てを行っている。

【００３３】また、予め使用されるアプリケーションに
割り当てる帯域がユーザ設定により決まっている場合に
は、二つの通信ノード間のアプリケーションのコントロ
ールフローの通信内容からデータフローの情報を検出
し、この検出結果に基づいてアプリケーションの設定に
応じた帯域情報を加えたデータセッション情報からその
データセッションの帯域保証が可能か否かを判別し、帯
域保証可能と判別したときに、内部バッファの帯域の割
り当てを行っている。

【００３４】図１に示すように、本例の中継装置１は、
ネットワーク間に接続され、フローテーブル２、トラフ
ィック管理データベース３、アプリケーション別固定帯
域情報データベース４、パケット分類器５、検出手段と
してのコントロールセッション解析部６、帯域割当手段
としての予約受付制御部７、バッファ手段としてのバッ
ファキュー（内部バッファ）８、パケットスケジューラ
９を備えて構成される。

【００３５】フローテーブル２には、帯域確保の対象と
なるフローとバッファキュー８の出力キューとの対応関
係を示すデータが格納されている。具体的には、図２に
示すように、帯域を確保されたフローのデータセッショ
ン情報毎に１つのキューＩＤ（ＱｕｅｕｅＩＤ）がそれ
ぞれ割り当てられて格納されている。図２の例では、デ
ータセッション情報が宛先ＩＰアドレス（例えば１３
３．２３６．２０．５）、送信元ＩＰアドレス（例えば
１２１．４５．１８９．４）、プロトコル（例えばＵＤ
Ｐ）、宛先ポート番号（例えば１１５６）、送信元ポー
ト番号（例えば９８０）の５つの要素で構成され、これ
ら５つの要素を１セットとして各セット毎に１つのキュ
ーＩＤが割り当てられている。なお、キューＩＤは、バ
ッファキュー８の出力キューと対応している。

【００３６】トラフィック管理データベース３には、必
要帯域と遅延を示すデータがフローテーブル２のキュー
ＩＤ毎に格納されている。図３の例では、フローテーブ
ル２の各キューＩＤ毎に設定された最小レート、最大レ
ート、最大遅延を示すデータがテーブル形式で格納され
ている。

【００３７】アプリケーション別固定帯域情報データベ
ース４には、例えば動画、音声、ビデオを再生するため
に使用するアプリケーションとその中に含まれる映像、
音声といった各メディア毎に予め決められた固定の帯域
を示すデータが格納されている。図４の例では、アプリ
ケーション毎に設定された最小レート、最大レート、最
大遅延を示すデータがテーブル形式で格納されている。

【００３８】パケット分類器５は、二つの通信ノード間
で通信が行われる際に受信したパケットが帯域保証の対
象となっているフローか否かをフローテーブル２を参照
して識別し、その識別結果に基づいてそのフロー専用の
バッファキュー８にパケットを格納するとともに、その
パケットをコントロールセッション解析部６に送信して
いる。帯域保証フロー専用のバッファキュー８は、単位
時間当たりのデータ最小出力量が保証されている。この
バッファキュー８にキューイングされたパケットは、ト
ラフィック管理データベース３のデータに基づいてパケ
ットスケジューラ９により出力スケジューリングされ
る。

【００３９】また、パケット分類器５は、コントロール
セッションのパケットを受信した場合、このコントロー
ルセッションのパケットをコピーし、このコピーしたパ
ケットをコントロールセッション解析部６に送信してい
る。

【００４０】コントロールセッション解析部６は、パケ
ット分類器５から送信されるパケットをトレースし、図
５のフローチャートに示す処理手順に従って動作し、デ
ータセッションに必要な帯域に関する情報を検出する。
以下、図５に基づいてコントロールセッション解析部６
の動作について説明する。

【００４１】コントロールセッション解析部６は、通
常、パケット分類器５からのコントロールセッションパ
ケット入力待ち状態（ＳＴ１）となっている。この状態
からパケット分類器５よりパケットが入力されると、そ
のパケットのプロトコル種別（たとえばＲＴＳＰ）を判
定する（ＳＴ２）。このプロトコル種別の判定は、予め
プロトコル別に用意されたプロトコル別解析機能によっ
て行われる。

【００４２】パケットのプロトコル種別が判定される
と、そのパケットが新規セッションか否かを判別する
（ＳＴ３）。新規セッションであれば、セッション情報
（例えばセッション確立用のパケットの宛先ポートまた
は送信元ポートがＲＴＳＰである場合のクライアントの
ＩＰアドレスとポート番号、サーバのＩＰアドレスとポ
ート番号）に基づいて一時エントリを作成し（ＳＴ
４）、パケットからセッション情報を抽出する（ＳＴ
５）。これに対し、新規セッションでなければ、パケッ
トからデータセッション情報を抽出する（ＳＴ５）。抽
出されるデータセッション情報は、例えば宛先ＩＰアド
レス／ポート、送信元ＩＰアドレス／ポート、セッショ
ンに必要な帯域に関する情報などである。

【００４３】データセッション情報が抽出されると、抽
出したデータセッション情報を内部メモリに格納する。
続いて、アプリケーションが事前固定帯域設定のアプリ
ケーションか否かを判別する（ＳＴ６）。アプリケーシ
ョン種別の判別はコントロールセッションの宛先もしく
は送信元ポート番号から求める。そして、アプリケーシ
ョン別固定帯域情報データベース４を参照し、データセ
ッションを交わすアプリケーションが固定帯域設定され
るものであるか否かを判別する。事前固定帯域設定のア
プリケーションであれば、データセッション情報のメデ
ィア（音声、映像）と対応する帯域情報をアプリケーシ
ョン別固定帯域情報データベース４から読み出し、この
読み出した帯域情報を使用して設定を行う（ＳＴ７）。

【００４４】以上の処理によって得られるデータセッシ
ョン情報は、データセッション情報毎にＩＤが割り当て
られてスタティックに内部メモリに格納される。

【００４５】その後、全てのデータセッション情報の取
得が完了したか否かを判別する（ＳＴ８）。全てのデー
タセッション情報の取得が完了すると、内部メモリに格
納された該当エントリ情報を予約受付制御部７に送信す
る（ＳＴ９）。これに対し、全てのデータセッション情
報の取得が完了しなければ、コントロールセッションパ
ケット入力待ち状態に戻る（ＳＴ１）。

【００４６】予約受付制御部７は、コントロールセッシ
ョン解析部６より入力されるデータセッション情報（エ
ントリ情報）に基づいて図６のフローチャートに示す処
理手順に従って動作する。以下、図６に基づいて予約受
付制御部７の動作について説明する。

【００４７】予約受付制御部７は、通常、データセッシ
ョン情報入力待ち状態となっている（ＳＴ１１）。この
データセッション情報入力待ち状態からコントロールセ
ッション解析部６よりデータセッション情報が入力され
ると、このデータセッション情報に含まれる申告帯域が
受入れ可能か否かを判別する（ＳＴ１２）。申告帯域が
受入れ可能か否かの判別は、トラフィック管理データベ
ース３に登録されている使用済みの帯域を参照すること
により行われる。そして、申告帯域が受入れ可能でなけ
れば、データセッション情報入力待ち状態に戻る（ＳＴ
１１）。これに対し、申告帯域が受入れ可能であれば、
フローテーブル２のセッションリストを参照し、既に予
約されたデータセッションか否かを判別する（ＳＴ１
３）。

【００４８】そして、既に予約されたデータセッション
であれば、帯域予約して再設定を行い（ＳＴ１４）、デ
ータセッション情報入力待ち状態に戻る（ＳＴ１１）。
これに対し、既に予約されたセッションでなければ、フ
ローテーブル２にセッションエントリを追加してフロー
テーブル２を更新し（ＳＴ１５）、新たにキューを作成
し（ＳＴ１６）、この作成したキューをパケットスケジ
ューラ９に送る。そして、キューの作成後、帯域予約し
て再設定を行い（ＳＴ１４）、予約帯域をトラフィック
管理データベース３に書き込んで更新し、データセッシ
ョン情報入力状態に戻る（ＳＴ１１）。

【００４９】パケットスケジューラ９は、単位時間当た
りのデータ最小出力量が保証された帯域保証フロー専用
のバッファキュー８を、トラフィック管理データベース
３に格納されたデータに基づいてスケジューリングして
いる。

【００５０】ここで、フローとは、ある特定の送信元端
末のアプリケーションから別のある特定の宛先端末のア
プリケーションへ送信する一連のパケット群のうち、通
過する経路上に存在する本例の中継装置１において一定
の帯域を保証しながら中継する必要があるパケットの単
一方向の流れを意味している。

【００５１】このように、本例の中継装置１では、入出
力処理プロセスにおいて、受信したパケットがパケット
分類器５にかけられる。パケット分類器５では、フロー
テーブル２を参照し、パケットが帯域保証の対象となっ
ているフローをそのフロー専用のバッファキュー８に格
納する。帯域保証フロー専用バッファキュー８は、単位
時間当たりのデータ最小出力量が保証されており、これ
らはパケットスケジューラ９によりトラフィック管理デ
ータベース３に基づいてスケジューリングされる。

【００５２】新しいセッションの場合、コントロールセ
ッションのパケットがバッファキュー８（この場合はベ
ストエフォートキュー）へのキューイングとともにパケ
ット分類器５でコピーされる。このコピーされたパケッ
トは、コントロールセッション解析部６に送信される。
コントロールセッション解析部６では、パケット分類器
５からのパケットを解析し、この後に確立すると仮定さ
れるデータセッションのポート番号、必要帯域を認識し
たときに、新しいバッファキュー８に対する帯域の割り
当てを予約受付制御部７に依頼する。予約受付制御部７
では、内部リソースの状態を判断し、認識されたポート
番号、必要帯域に基づいて出力回線のトラフィックがこ
のデータセッションの帯域を保証可能か否かを判別し、
その判別結果に基づいてバッファキュー８に対する帯域
の割り当てを行い、トラフィック管理データベース３に
基づいてパケットスケジューラ９によりパケットがスケ
ジューリングされる。そして、バッファキュー８への帯
域の割り当てが行え、帯域確保可能と判断したときに
は、フローテーブル２にそのフローと、フロー用に新し
く割り当てたバッファキュー８のキューＩＤを追加して
格納する。同時に、トラフィック管理データベース３に
データセッションのフローと帯域を更新して登録する。
帯域の割り当てができなかった場合は、そのデータセッ
ションのパケットがベストエフォートキューにバッファ
リングされる。

【００５３】次に、上記のように構成された中継装置１
による具体的な帯域割り当て方法の一例について図７乃
至図１１を参照しながら説明する。

【００５４】なお、以下に説明するＲＴＳＰセッション
動作例の項目番号（１）〜（８）は図７乃至図９中の項
目番号（１）〜（８）とそれぞれ対応している。また、
ＲＴＳＰセッション動作例の手順におけるアルファベッ
ト記号（ａ）〜（ｊ）は図１中の制御／データラインを
識別するアルファベット記号（ａ）〜（ｊ）とそれぞれ
対応している。さらに、フローテーブル２とトラフィッ
ク管理データベースの初期状態は、それぞれ図２、図３
の状態であるものとする。

【００５５】（１）ＲＴＳＰ用のセッションの確立をク
ライアント側から開始し、クライアントが本例の中継装
置１を介してサーバのＲＴＳＴポート（５５４）とＴＣ
Ｐ接続する。

【００５６】このとき、本例の中継装置１のパケット分
類器５は、ＴＣＰ接続時に流れたセッション確立用のパ
ケットの宛先ポートまたは送信元ポートがＲＴＳＰ（５
５４）であることを検出する。

【００５７】また、パケット分類器５は、フローテーブ
ル２よりＲＴＳＰ（５５４）ポートが宛先または送信元
になっているパケットはコントロールセッション解析部
６に送信しなければならないことを知る。

【００５８】さらに、パケット分類器５は、これらのパ
ケットをベストエフォートキューに格納すると同時に、
コントロールセッション解析部６にも送信する。

【００５９】コントロールセッション解析部６は、上記
パケットを受け取ると、新規にＲＴＳＰセッションが確
立するものと仮定し、内部にクライアントのＩＰアドレ
ス（１９２．１６８．３７．１１３）とポート番号（１
０６１）、サーバのＩＰアドレス（１７２．１６．２２
３．１０２）とポート番号（５５４）の情報を識別子と
する一時エントリを作成する。

【００６０】（２）クライアントがサーバにオプション
仕様のチェックを依頼する（ＲＴＳＰＯＰＴＩＯＮ
Ｓ）

【００６１】前述した（１）の処理と同様に、パケット
分類器５は、本パケットをベストエフォートキューに格
納すると同時に、コントロールセッション解析部６にも
送信する。

【００６２】コントロールセッション解析部６は、上記
パケットがＲＴＳＰパケットであることを知り、ＲＴＳ
Ｐ専用の解析を行う。

【００６３】また、コントロールセッション解析部６
は、上記ＲＴＳＰパケット内に帯域通知情報が含まれて
いないことを知り、当該パケットに対する処理を終了す
る。以降、上記処理のように、帯域制御に直接結びつか
ない場合の一連動作についての説明を省略する。

【００６４】（３）クライアントがサーバにコンテンツ
の仕様要求を行う（ＲＴＳＰＤＥＳＣＲＩＢＥ）。

【００６５】（４）サーバがクライアントにセッション
情報を送付する（ＲＴＳＰ／ＳＤＰ）。

【００６６】前述した（１）の処理と同様に、パケット
分類器５は、本パケットをベストエフォートキューに格
納すると同時に、コントロールセッション解析部６にも
送信する。

【００６７】コントロールセッション解析部６は、上記
ＲＴＳＰ／ＳＤＰパケット内にコンテンツの帯域情報が
通知されていることを知る。帯域情報の記述（ｂ＝Ａ
Ｓ：１６）より、本セッションにはサーバ→クライアン
トの向きに１６Ｋｂｐｓの帯域が必要であることを知
る。

【００６８】なお、ここで当該ストリーム用のアプリケ
ーションがアプリケーション別固定帯域情報データベー
ス４により事前に帯域が設定されていた場合、その帯域
が使用される。

【００６９】（５）クライアントがサーバにリソースと
ＲＴＳＰセッションの開始を要求し（ＲＴＳＰ）、また
当該要求に対しサーバはクライアントに受領応答を返
す。

【００７０】前述した（１）の処理と同様に、パケット
分類器５は、これらのパケットをベストエフォートキュ
ーに格納すると同時に、コントロールセッション解析部
６にも送信する。

【００７１】コントロールセッション解析部６は、上記
ＲＴＳＰＳＥＴＵＰ要求パケット内を解析し、配信用
のサーバポート番号（１５７９４）と、使用するプロト
コル（ＵＤＰ）を知る。

【００７２】コントロールセッション解析部６は、以上
の処理により、帯域予約に必要な情報であるサーバのＩ
Ｐアドレスとポート番号、クライアントのＩＰアドレス
とポート番号、プロトコル、必要帯域を捕捉したと判断
すると、これらの情報を予約受付制御部７に転送する。

【００７３】予約受付制御部７は、フローテーブル２よ
り既存のコネクションが存在しないことを確認すると、
コントロールセッション解析部６からの情報に基づいて
新規に専用キューを作成（キューＩＤ４）し、必要帯域
（１６Ｋｂｐｓ）の設定を行う。

【００７４】予約受付制御部７は、トラフィック管理デ
ータベース３へキューＩＤと必要帯域情報を送付し、対
応するエントリを登録する。この登録後のトラフィック
管理データベース３は、図３に示すものから図１１のよ
うに変更される。

【００７５】予約受付制御部７は、フローテーブル２に
サーバのＩＰアドレスとポート番号、クライアントのＩ
Ｐアドレスとポート番号、プロトコル、キューＩＤを送
付し、対応するエントリを登録する。この登録後のフロ
ーテーブル２は、図２に示すものから図１０のように変
更される。

【００７６】（６）クライアントがサーバにアプリケー
ションのメディアのパラメータ設定を送付する（ＲＴＳ
ＰＳＥＴ＿ＰＡＲＡＭＥＴＥＲ）。

【００７７】（７）クライアントがサーバにアプリケー
ションのメディアの送信開始を要求する（ＲＴＳＰＰ
ＬＡＹ）

【００７８】（８）サーバがクライアントにストリーム
データの送信を開始する。パケット分類器５は、ストリ
ームデータのパケットのフロー情報を捕捉する。フロー
テーブル２との比較により、上記パケットをキューＩＤ
４のトラフィック管理データベース３に設定された帯域
情報（１６Ｋｂｐｓ）に基づいて出力を行う。以後、Ｔ
ＣＰコネクションの切断が検出されるか、キュー未使用
時間のタイムアウトに達するまで、キューは保持され
る。

【００７９】このように、本発明の中継装置及び中継方
法では、ＲＳＶＰのフロー単位でのきめ細かい帯域保証
という利点を生かしつつ、帯域の自動検出によりＲＳＶ
Ｐの欠点を補っている。そして、動画配信や音声、ビデ
オ通信のための帯域をセッション中のパラメータの交換
から読み取り、自動的に帯域を確保している。そして、
帯域を確保する際に、ＲＳＶＰのような特殊な専用プロ
トコルを使用せず、シグナリングが不要なので、ユーザ
の設定の負担が増えず、全てのネットワーク機器が何か
共通の枠組みで動作していることを前提とせずに動作さ
せることができる。これにより、自分が管理しているバ
ッファキューや、回線を自動検出した帯域要求値で帯域
を自動的に確保することができる。

【００８０】また、ＤｉｆｆＳｅｒｖの様にトラフィッ
クをＰＨＢにアグリゲートするのではなく、フロー単位
で個々の帯域を確保するので、他の通信に邪魔されて必
要なデータがドロップするといった輻輳が起きないとい
う利点がある。

【００８１】ところで、図１に示す中継装置１では、入
出力処理の機能を判り易くするため、パケット分類器
５、コントロールセッション解析部６、予約受付制御部
７を別々の構成として図示したが、これらを一つの処理
部として構成することもできる。

【００８２】また、上述した実施の形態では、ＲＴＳＰ
とＲＴＰを用いて通信を行うストリーム配信用のアプリ
ケーションの場合を例にとって説明したが、本例の中継
装置及び中継方法は、セッション情報として必要帯域と
ポート番号を認識できるものであれば採用することが可
能である。例えばＨ．３２３を用いたネットワーク会議
に採用することができる。

【００８３】ネットワーク会議は、インターネットやＬ
ＡＮを使って音声やカメラ映像をリアルタイムで通信す
ることができ、テレビ電話としても利用できる。ネット
ワーク会議は、リアルタイムＩＰ通信用のＲＴＰや低ビ
ットレート符号化技術（Ｈ．２６３，Ｇ．７２３．１）
を含むＩＴＵ−Ｔ勧告のＨ．３２３という通信プロトコ
ルで呼制御とデータの交換を行っている。

【００８４】Ｈ．３２３は、サービス品質が保証されな
いＬＡＮ上での音声・動画像・データ通信の送受方法の
仕様と発呼時の信号方式を規定しており、ファイル転
送、ホワイト・ボードなどのデータ共有のためのチャネ
ルも規定している。このＨ．３２３は、１９９６年にＩ
ＴＵ−Ｔの勧告により標準化されたインターネットやＬ
ＡＮなどのネットワークでのマルチメディア通信システ
ム及び端末用のプロトコルとして用いられ、図１６に示
す呼の確立とデータの伝送を行っている。すなわち、
Ｈ．３２３は、ＴＣＰ上でＨ．２２５．０やＨ．２４５
を使って発呼を制御したり、コネクションを確立した
後、ＵＤＰ上のＲＴＰとＲＴＣＰによって動画や音声を
リアルタイムに送受信する。そして、Ｈ．３２３では、
ＯｐｅｎＬｏｇｉｃａｌＣｈａｎｎｅｌの中でＲＴＰに
使用するＵＤＰポート番号と、利用する帯域が相手に通
知される。従って、本例の中継装置及び中継方法を採用
することにより、ＵＤＰポート番号と利用帯域を監視
し、この監視結果に基づいて内部バッファの帯域の割り
当てを行うことができる。

【００８５】さらに、上述した実施の形態では、内部バ
ッファの必要帯域がコントールセッションとデータセッ
ションが別フローの場合を例にとって説明したが、本例
の中継装置及び中継方法は、例えばコントロールセッシ
ョンがデータセッションを兼ねた同一フローの場合にも
採用することができる。

【００８６】また、図７乃至図１１に示す例では、デー
タフローをポート番号として説明したが、ＩＰｖ６(int
ernet protcol version6) を採用する場合には、ＩＰア
ドレスのヘッダーに含まれるフロー・ラベルをデータフ
ローとして扱う。ＩＰｖ６は、ＲＦＣ２３７３，２３７
４，２４６０−２４７２などで規定されており、アドレ
ス空間を１２８ビットに広げた他、経路情報を集約化す
ることでルーターの処理負荷を軽減したり、ＩＰｓｅｃ
によるセキュリティ機能、ＤＨＣＰによるアドレス自動
取得機能を標準装備している。

【００８７】

【発明の効果】以上の説明で明らかなように、本発明に
よれば、ＲＳＶＰと同様にフロー単位でのきめ細かい帯
域保証をしつつ、帯域の自動検出によりＲＳＶＰが有す
る欠点を持たず、動画配信や音声、ビデオ通信のための
帯域をセッション中のパラメータの交換から読み取り、
自動的に帯域を確保することができる。しかも、帯域を
確保する際、ＲＳＶＰのような特殊な専用プロトコルを
使用せず、シグナリングが不要なので、ユーザの設定の
負担が増えず、全てのネットワーク機器が何か共通の枠
組みで動作していることを前提とせずに動作させること
ができる。その結果、自己管理しているバッファキュー
や回線を自動検出した帯域要求値で帯域を自動的に確保
することができる。

【００８８】また、ＤｉｆｆＳｅｒｖの様にトラフィッ
クをＰＨＢにアグリゲートするのではなく、フロー単位
で個々の帯域を確保するので、他の通信に邪魔されて必
要なデータがドロップする輻輳が起きないという利点が
ある。

【図面の簡単な説明】

【図１】本発明による中継装置の機能ブロック図

【図２】フローテーブルの内部構成の一例を示す図

【図３】トラフィック管理データベースの内部構成の一
例を示す図

【図４】アプリケーション別固定帯域情報データベース
の内部構成の一例を示す図

【図５】コントロールセッション解析部の動作フローチ
ャート

【図６】予約受付制御部の動作フローチャート

【図７】ＲＴＳＰセッションに対する動作の一例を説明
するための図

【図８】図７に続くＲＴＳＰセッションに対する動作の
一例を説明するための図

【図９】図８に続くＲＴＳＰセッションに対する動作の
一例を説明するための図

【図１０】新規セッション登録後のフローテーブルの内
部構成の一例を示す図

【図１１】新規セッション登録後のトラフィック管理デ
ータベースの内部構成の一例を示す図

【図１２】送信ノードと受信ノードとの間でＲＳＶＰに
より帯域確保を依頼する場合の簡略説明図

【図１３】送信ノードと受信ノードとの間でＲＳＶＰに
より帯域確保を依頼する場合の簡略説明図

【図１４】ＤｉｆｆＳｅｒｖにおけるＩＰデータブロッ
クのフォーマットを示す図

【図１５】ＲＴＳＰとＲＴＰで通信を行うアプリケーシ
ョンによりクライアントとサーバとの間でデータ通信を
行う際の手順の一例を示す図

【図１６】Ｈ．３２３による呼の確立とデータ伝送の手
順の一例を示す図

【符号の説明】

１…中継装置、２…フローテーブル、３…トラフィック
管理データベース、４…アプリケーション別固定帯域情
報データベース、５…パケット分類器、６…コントロー
ルセッション解析部（検出手段）、７…予約受付制御部
（帯域割当手段）、８…バッファキュー（バッファ手
段）、９…パケットスケジューラ。

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5K030 GA13 HA08 JA11 KA03 LA03 LC08 LC11 5K033 AA01 CB06 CB17 DB18 5K051 AA01 BB02 EE01 FF07

Claims

【特許請求の範囲】

【請求項１】二つの通信ノード間の通信を中継する中
継装置において、前記二つの通信ノード間で一方のノードから他方のノー
ドへ送られる通信の内容を監視することによって、該通
信の内容に含まれる情報であって、前記二つの通信ノー
ドの一方から他方へ送信するために必要な帯域に関連す
る前記情報を検出する検出手段（６）と、前記必要な帯域が割り当て可能なバッファ手段（８）
と、前記検出手段によって検出された前記情報に基づいて前
記必要な帯域を前記バッファ手段に割り当てる帯域割当
手段（７）とを備えたことを特徴とする中継装置。
【請求項２】二つの通信ノード間の通信を中継する中
継方法であって、前記二つの通信ノード間で一方のノードから他方のノー
ドへ送られる通信の内容を監視することによって、該通
信の内容に含まれる情報であって、前記二つの通信ノー
ドの一方から他方へ送信するために必要な帯域に関連す
る前記情報を検出する段階と、検出された前記情報に基づいて前記必要な帯域を割り当
てる段階とを含むことを特徴とする中継方法。