JP3529541B2 - ルータ装置及びパケット転送方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、仮想コネクション
ネットワーク同士を接続することのできるルータ装置、
ルータ装置を介し異なる論理ネットワークをまたがって
パケットを転送する方法、及び、ルータ装置を介しマル
チキャストのパケット転送を行うための仮想的転送路を
形成する方法に関する。

【０００２】

【従来の技術】ルータ装置は、LAN(Local Area Networ
k) 間を接続する際に用いられるもので、一方のLAN か
ら他方のLAN にパケットを転送する役割を果たす。パケ
ットには、転送すべき通信情報データに加えて、その送
信元および最終宛先のネットワーク層アドレスが記載さ
れており、ルータ装置では、そのアドレス情報を用い
て、パケットの出力インターフェイスおよび次の転送ノ
ードを決定している。

【０００３】このルータ装置は、１つの発信元から１つ
の最終宛先にパケットを転送するユニキャスト通信のみ
でなく、１つの発信元から多数の最終宛先にパケットを
送信するマルチキャスト通信も行うことができる。

【０００４】さて、近年、音声や画像をパケットを用い
て転送する試みが行われている。現状では、音声画像の
データと他のデータがルータで同様に送られるため、音
声がとぎれとぎれになったら、映像が乱れたりしてい
る。そこで、ルータで資源予約を行うことで、音声画像
の転送を優先的に行うことで聞きやすい音声と見易い画
像になる。ここでは、音声画像を例に取ったが、優先的
に流したいデータの場合は、資源予約することにより、
メリットがある。

【０００５】このようにルータ装置で資源予約をするた
めには、ルータ装置間で資源予約の情報をやり取りする
必要があり、そのプロトコルとして、RSVP(Resource Re
SerVation Protocol) が開発されている。このプロトコ
ルは、ユニキャストとマルチキャストの両方に対応して
いる。

【０００６】RSVPでは、データを受信している下流側の
ノードから情報の発信元である上流ノードへ資源予約を
行う。具体的には、情報の発信元からデータの宛先と同
じ宛先に向かってPATHメッセージを送出し、情報がどの
経路を通っているかを経路上のルータに記憶させる。PA
THメッセージには、資源予約すべきデータを特定する識
別子と、PATHメッセージを送出するノードのIPアドレス
が書かれている。

【０００７】データの受信ノードは、PATHメッセージを
受信すると、PATHメッセージを送信した上流ノードにRE
SVメッセージを送出することで、資源予約の意思を表示
する。RESVメッセージには、資源予約すべきデータを特
定する識別子と、受信ノードが要求するQOS （サービス
品質）が書かれている。

【０００８】このRESVメッセージを受信したルータは、
資源予約するだけの能力がネットワークレイヤ（IP）処
理部にある場合は、ネットワークレイヤのスケジューリ
ングを行って、RESVを上流に転送する。資源予約が出来
ない場合は、RESV Errorを下流のノードに送信する。こ
れを繰り返すことにより、上流ノードまで資源予約が出
来る。

【０００９】

【発明が解決しようとする課題】本発明の一つは、ネッ
トワークレイヤ処理部の能力が比較的低いルータが、ネ
ットワークレイヤのスケジューリングのみによっては、
資源予約のためのメッセージに示される要求サービス品
質を満たすことができない場合にも、要求された資源の
予約を可能とし、かつ、自ノードで資源予約が行えたか
否かを正しく他のノードに伝える機構を提供することを
目的とする。

【００１０】本発明は、また、ルータがネットワークレ
イヤより下位のレイヤでの仮想コネクションのスイッチ
ング機能を利用してマルチキャスト通信を行う際に、こ
の通信のためのコネクション及びルータ内の設定を効率
よく行う手法を提供することを目的とする。

【００１１】本発明は、また、ルータ間にスイッチの存
在するシステムでマルチキャスト通信を行う際に、この
通信のためのコネクションを両端のルータで一意に識別
し、必要なコネクション及びルータ内の設定を効率よく
行う手法を提供することを目的とする。

【００１２】

【課題を解決するための手段】本発明の第一の発明は、
仮想コネクション型ネットワークとの物理インタフェー
スを有し、少なくとも２つの論理ネットワークを接続す
るルータ装置において、一方の前記論理ネットワークか
らの受信に使用される仮想的転送路と他方の前記論理ネ
ットワークへの送信に使用される仮想的転送路との対応
関係を記憶する記憶手段と、この記憶された対応関係に
従って、パケットの転送を行う転送手段と、資源予約の
ためのメッセージを受信者側の論理ネットワークから受
信する受信手段と、この受信した資源予約のためのメッ
セージに基づき、前記受信者側の論理ネットワークへの
前記転送手段を介することが可能なパケット送信用の仮
想的転送路の存在、及び、送信者側の論理ネットワーク
からの前記転送手段を介することが可能なパケット受信
用の仮想的転送路の存在の有無に応じて、資源予約のた
めのメッセージを前記送信者側の論理ネットワークへ送
信する送信手段とを具備したことを特徴とする。

【００１３】本発明の第二の発明は、仮想コネクション
型ネットワークとの物理インタフェースを有し、少なく
とも２つの論理ネットワークを接続するルータ装置にお
いて、一方の前記論理ネットワークからの受信に使用さ
れる仮想的転送路と他方の前記論理ネットワークへの送
信に使用される仮想的転送路との対応関係を記憶する記
憶手段と、この記憶された対応関係に従って、パケット
の転送を行う転送手段と、資源予約のためのメッセージ
を受信者側の論理ネットワークから受信する受信手段
と、この受信した資源予約のためのメッセージに基づ
き、資源予約のためのメッセージを送信者側の論理ネッ
トワークへ送信する送信手段と、前記受信者側の論理ネ
ットワークへの前記転送手段を介することが可能なパケ
ット送信用の仮想的転送路の存在、及び、前記送信者側
の論理ネットワークからの前記転送手段を介することが
可能なパケット受信用の仮想的転送路の存在の有無に応
じて、前記送信手段により送信した資源予約のためのメ
ッセージの取り消しを通知する通知手段とを具備したこ
とを特徴とする。

【００１４】本発明の第三の発明は、例えば第一の発明
に係るルータ装置を用いて実現されるものであり、第１
のノードから送信されるパケットを、前記第１のノード
とは異なる論理ネットワークに属する第２のノードへ転
送するパケット転送方法において、資源予約のためのメ
ッセージを前記第２のノードから受信し、前記第１のノ
ードから前記第２のノードへネットワークレイヤレベル
の転送処理の一部又は全部を行わずにパケット転送を行
うことを可能とするように設定された、前記第１のノー
ドからのパケットを受信可能な仮想的転送路と、前記第
２のノードへのパケットを送信可能な仮想的転送路とが
存在する（ことを確認した）場合に、これら仮想的転送
路の対応関係を記憶すると共に、資源予約のためのメッ
セージを前記第１のノードへ送信し、パケットを受信し
た場合に、この受信に用いられた仮想的転送路について
の前記対応関係が記憶されているならば、この対応関係
に従って前記パケットを転送することを特徴とする。

【００１５】本発明の第四の発明は、例えば第二の発明
に係るルータ装置を用いて実現されるものであり、第１
のノードから送信されるパケットを、前記第１のノード
とは異なる論理ネットワークに属する第２のノードへ転
送するパケット転送方法において、資源予約のためのメ
ッセージを前記第２のノードから受信し、この受信を受
けて、資源予約のためのメッセージを前記第１のノード
へ送信し、前記第１のノードから前記第２のノードへネ
ットワークレイヤレベルの転送処理の一部又は全部を行
わずにパケット転送を行うことを可能とするように設定
された、前記第１のノードからのパケットを受信可能な
仮想的転送路と、前記第２のノードへのパケットを送信
可能な仮想的転送路との少なくとも一方が存在しない
（ことを確認した）場合に、送信した前記資源予約のた
めのメッセージの取り消しを前記第１のノードに通知
し、前記両仮想的転送路が存在する場合に、これら仮想
的転送路の対応関係を記憶し、パケットを受信した場合
に、この受信に用いられた仮想的転送路についての前記
対応関係が記憶されているならば、この対応関係に従っ
て前記パケットを転送することを特徴とする。

【００１６】ここで、記憶された対応関係に従ってパケ
ットを転送することは、ネットワークレイヤレベルの転
送処理の一部又は全部を省略してパケットを転送するこ
とを意味する。少なくとも省略される処理は、パケット
の宛先アドレスから、次に転送すべき先のノードを決定
し、この決定されたノードへのパケット送信に用いる仮
想的転送路を特定する処理（ネットワークレイヤレベル
の解析）である。

【００１７】また、ネットワークレイヤレベルの転送処
理の一部又は全部を行わずにパケット転送を行うことを
可能とするように設定された仮想的転送路は、異なる論
理ネットワークに属するノード間でネットワークレイヤ
レベルの転送処理を行ってパケットを転送するように既
に設定されている仮想的転送路とは別の仮想的転送路で
あることが望ましい。

【００１８】このように、上記第一乃至第四の発明で
は、ルータ装置がネットワークレイヤより下位のレイヤ
での仮想的転送路のスイッチング機能を一部利用して
（これら仮想的転送路の対応関係を記憶してこの対応関
係に従って）パケット転送を行うことにより、従来のル
ータ装置よりも多くの場合に資源の予約を行うことがで
きる。

【００１９】さらに、上記第一又は第三の発明によれ
ば、下流から資源予約のためのメッセージ（例えばRSVP
のResvメッセージ）を受けたとき、これを受けたノード
（ルータ装置）の上流及び下流に、ネットワークレイヤ
レベルの転送処理の一部又は全部を省略してパケットを
転送するように使用することのできる仮想的転送路（例
えば専用VC）が存在し、これらの仮想的転送路の対応関
係を記憶してこれに従ってパケット転送を行う（例えば
直結する）ことによりはじめて資源予約のためのメッセ
ージに示される要求サービス品質を満たすことができる
場合に、両仮想的転送路の存在を確認してから上流へ資
源予約のためのメッセージを送信するため、これを受け
た上流のノードは、次ノードから下流については確実に
資源予約が行えたと解釈して動作することができる。

【００２０】さらに、上述の場合に、少なくともいずれ
かの仮想的転送路の不存在を確認したならば、下流に資
源予約に失敗した旨のメッセージ（例えばRESV Error）
を送信することにより、これを受けた下流のノードは、
自ノードの要求した資源予約が拒否されたことを知って
動作することができる。

【００２１】この発明を、例えば、資源予約のためのメ
ッセージを受信したノードが、自ノードの上流に専用VC
を設定するよう要求する場合に適用すると、専用VCを直
結することによりはじめて受信側から要求された資源予
約が行える場合には、まず、自ノードの下流に専用VCが
存在しないならば、上流へ資源予約のためのメッセージ
を送信することはせず（下流に資源予約の失敗を伝
え）、自ノードの下流に専用VCが存在するならば、要求
して上流に専用VCが設定されてから、上流へ資源予約の
ためのメッセージを送信することになる。

【００２２】なお、自ノードの下流に専用VCが存在しな
いという場合を減らすため、専用VCを直結せずに要求さ
れた資源予約が行える場合でも、上流に専用VCを設定す
るよう要求しても良い。そして、両側に専用VCが存在す
るならば、ネットワークレイヤの資源を他の用途に利用
できるように、専用VCを直結せずに要求された資源予約
が行える場合でも、直結しても良い。

【００２３】一方、上記第二又は第四の発明によれば、
下流から資源予約のためのメッセージを受けたとき、こ
れを受けたノード（ルータ装置）の上流及び下流の仮想
的転送路（例えば専用VC）の対応関係を記憶してこれに
従ってパケット転送を行う（例えば直結する）ことをし
なければ資源予約のためのメッセージに示される要求サ
ービス品質を満たすことができない場合であっても、上
流に資源予約のためのメッセージを送信しておき、少な
くともいずれかの仮想的転送路の不存在を確認したなら
ば、これの取り消しを通知する（例えばRESV Tear を送
る）ため、上流のノードは、次ノードから下流について
資源予約が行えたか否かを確実に知って動作することが
できる。

【００２４】さらに、上述の場合に、少なくともいずれ
かの仮想的転送路の不存在を確認したならば、下流に資
源予約に失敗した旨のメッセージ（例えばRESV Error）
を送信することにより、これを受けた下流のノードは、
自ノードの要求した資源予約が拒否されたことを知って
動作することができる。

【００２５】この発明を、例えば、資源予約のためのメ
ッセージを受信したノードが、自ノードの下流に専用VC
を設定する場合に適用すると、専用VCを直結することに
よりはじめて受信側から要求された資源予約が行える場
合には、まず、自ノードの下流に専用VCを設定し、上流
のノードが自ノードの送信した資源予約のためのメッセ
ージをきっかけとして専用VCを設定するのを待つ。そし
て、上流に専用VCが設定されなければ、上流へ資源予約
を取り消すメッセージを送信し（下流に資源予約の失敗
を伝え）ることになる。

【００２６】ここで、上流に資源予約のためのメッセー
ジを送信するタイミングは、下流に専用VCを設定する前
でも後でも良いが、前とする場合は、下流に専用VCが設
定できなかったときも、上流へ資源予約を取り消すメッ
セージを送信する。

【００２７】なお、自ノードの上流に専用VCが設定され
ないという場合を減らすため、専用VCを直結せずに要求
された資源予約が行える場合でも、下流に専用VCを設定
するようにしても良い。そして、両側に専用VCが存在す
るならば、ネットワークレイヤの資源を他の用途に利用
できるように、専用VCを直結せずに要求された資源予約
が行える場合でも、直結しても良い。

【００２８】本発明の第五の発明は、第１のノードから
送信されるパケットを、前記第１のノードとは異なる論
理ネットワークに属する複数の第２のノードへ、ルータ
装置を介して転送するための仮想的転送路を形成する方
法において、前記第１のノードから前記ルータ装置へ
の、及び、前記ルータ装置から前記第２のノードへの、
ポイント−マルチポイントとなり得る通常コネクション
（例えばデフォルトVC）を設定し、前記ルータ装置は、
前記第１のノードとの間に設定された前記通常コネクシ
ョン上に送信されたパケットを、ネットワークレイヤレ
ベルの解析を行って、前記第２のノードとの間に設定さ
れた前記通常コネクション上に転送し、前記第１のノー
ドから前記ルータ装置への、及び、前記ルータ装置から
前記複数の第２のノードのうち所定の条件を満たすもの
への、ポイント−マルチポイントとなり得る専用コネク
ション（例えば専用VC）を設定し、前記ルータ装置は、
前記第１のノードとの間に設定された前記専用コネクシ
ョン上に送信されたパケットを、ネットワークレイヤレ
ベルの解析を行わずに、前記第２のノードとの間に設定
された前記専用コネクション上に転送し、前記専用コネ
クションの設定される前記第１のノードと前記ルータ装
置間、及び、前記専用コネクションの設定される前記ル
ータ装置と前記第２のノード間に、ポイント−ポイント
の通常コネクションを設定し、この通常コネクションを
用いて、前記専用コネクションの保持を行うことを特徴
とする。

【００２９】ここで、ネットワークレイヤレベルの解析
を行わないということは、ネットワークレイヤレベルの
転送処理の一部又は全部を省略してパケットを転送する
ことを意味する。少なくとも省略される処理は、パケッ
トの宛先アドレスから、次に転送すべき先のノードを決
定し、この決定されたノードへのパケット送信に用いる
仮想的転送路を特定する処理であり、これに代わってネ
ットワークレイヤより下位のレイヤで記憶された対応関
係に従ってパケットが転送される。

【００３０】この発明によれば、マルチキャスト用の通
常の品質で転送が行われる通常コネクションと、マルチ
キャスト用の高品質で転送が行われる専用コネクション
と、ポイント−ポイントの通常コネクションが設定さ
れ、専用コネクションの保持がポイント−ポイントの通
常コネクションを用いて行われる（例えば、保持のため
のメッセージが下流ノードから定期的に送られる）た
め、マルチキャスト通信において、ルータ装置がネット
ワークレイヤより下位のレイヤでの仮想的転送路のスイ
ッチング機能を一部利用してパケット転送を行うこと
を、効率よく実現することができる。

【００３１】例えば、専用コネクションを設定するきっ
かけとして、資源予約のためのメッセージを下流から受
信したときや、データパケットを上流から受信したとき
が想定されるが、前者の場合は、資源予約のためのメッ
セージ受信に、ポイント−ポイントの通常コネクション
を用いれば良く、後者の場合は、データパケットの受信
に、マルチキャスト用の通常コネクションを用いれば良
い。

【００３２】また、例えば、専用コネクションの設定
を、自ノードの上流に要求して設定する場合や、自ノー
ドの下流に設定する場合が想定されるが、前者の場合
は、設定を要求するメッセージの送信に、後者の場合
は、設定したことを通知するメッセージの送信に、ポイ
ント−ポイントの通常コネクションを用いれば良い。

【００３３】なお、専用コネクションはマルチキャスト
用であるから、同じマルチキャストグループに対応する
ノードへの専用コネクションの設定は、既に存在する専
用コネクションにリーフをを追加することにより行われ
る。そして、ポイント−ポイントの通常コネクションを
用いて保持されるのは、専用コネクションの対応するリ
ーフであることになる。

【００３４】本発明の第六の発明は、第１のノードから
送信されるパケットを、前記第１のノードとは異なる論
理ネットワークに属する複数の第２のノードへ、ルータ
装置を介して転送するための仮想的転送路を形成する方
法において、前記ルータ装置から前記複数の第２のノー
ドへの、ポイント−マルチポイントとなり得る専用コネ
クションを設定し、前記ルータ装置と前記第２のノード
それぞれとの間に、ポイント−ポイントの通常コネクシ
ョンを設定し、前記専用コネクションを表す前記論理ネ
ットワーク内でユニークな識別情報を、前記ルータ装置
から前記専用コネクションを用いて送信し、前記第２の
ノードから前記通常コネクションを用いて、前記識別情
報を確認するメッセージを送信することを特徴とする。

【００３５】この発明によれば、マルチキャスト用の専
用コネクションと、ポイント−ポイントの通常コネクシ
ョンが設定され、専用コネクションを両端のノードで一
意に識別するための情報が、上流ノードから専用コネク
ションで提案され、下流ノードから通常コネクションで
確認されるため、マルチキャストグループに受信者が参
加してくる毎に、対応する各ノードにおいて、専用コネ
クションを一意に識別することを、効率よく実現するこ
とができる。

【００３６】

【発明の実施の形態】

（実施形態１）本実施形態では、CSR(Cell Switch Rout
er) の技術を用いて、ATM(Asynchronous Transfer Mod
e) 上で資源予約プロトコルであるRSVP(resource ReSeV
ation Protocol) を実現するための方法を述べる。

【００３７】RSVPは、送信元アドレス／ポートと宛先ア
ドレス／ポートの組（宛先アドレス／ポートだけでもよ
い）等で識別するフローに属するパケット転送のQOS
（サービス品質）をルータで保証するものである。この
フローを識別する識別子をここでは、Flow ID と呼ぶこ
とにする。このQOS 保証は、ルータ内部でパケット転送
のスケジューリングを行うことにより、資源を予約して
いるパケットについては、早めに転送を行うようにする
ことにより、実現される。

【００３８】CSR は、通常のルータと同じIPパケット単
位で転送する動作を行う他に、ルータ内部にATM スイッ
チ機能を持つことにより、より高速なATM セル単位の転
送を行うことができるルータである。

【００３９】図1 を使って、CSR の簡単な動作を説明す
る。X.1 からCSR を通してY.1 にパケットを転送する場
合を考える。通常と同じIPパケット転送の動作を行うた
めには、X.1 からCSR に色々な宛先のパケットを転送す
るために設定されているATMコネクションでパケットを
送信する。ここでは、このATM コネクションをデフォル
トVC(Virtual Connection)と呼ぶ。CSR では、IPパケッ
トの宛先を見て次に配送するノードを決定する。ここで
は、次のノードは、Y.1 になるので、デフォルトVCにパ
ケットを送出することによりY.1 へとパケットが転送さ
れる。

【００４０】次に、ATM セル転送の動作を説明する。Y.
1 へのパケット転送専用のX.1 からCSR へのATM コネク
ションとCSR からY.1 へのATM コネクションとが設定さ
れているとする。ここでは、このATM コネクションを専
用VCと呼ぶ。さらに、これら２つの専用VCをCSR 内のAT
M スイッチ機能でATM セル単位で転送できるように設定
しておく。すなわち、X.1 からCSR への専用VCのCSR の
受信ポートでのVPI/VCI と、CSR からY.1 への専用VCの
CSR の送信ポートでのVPI/VCI との対応関係を、ATM レ
ベルのルーティングテーブルとして記憶しておく。この
ような設定を行うことで、二つの論理ネットワーク（IP
Subnet ）に属する専用VCを直結するバイパスパイプが
形成されたことになる。

【００４１】X.1 からY.1 へのパケット転送を行うに
は、X.1 からY.1 用の専用VCにパケットを送信すること
により、X.1 からCSR に送られ、CSR でATM レベルのル
ーティングテーブルを参照することによりATM セルのま
まCSR からY.1 への専用VCに転送されて、その専用VCで
Y.1 へ送られる。

【００４２】なお、ここでは、専用VCにて送信されるパ
ケットをATM セル単位で転送することを、専用VCの直結
として説明したが、専用VCにて送信されるパケットをAA
L(ATM Adaptation Layer) フレーム単位で転送すること
で、専用VCの直結としても良い。この場合も、上記のAT
M レベルのルーティングテーブルを参照することによ
り、AAL フレーム転送が行える。以上の場合はいずれ
も、ネットワークレイヤ（例えばIP）レベルの解析処理
を行わずに、パケットが転送されることになる。

【００４３】また、専用VCにて送信されるパケットに対
し、パケットの最終宛先アドレスから出力先とすべきVC
を決定するネットワークレイヤレベルのルーティングテ
ーブル参照処理は行わず、その他のネットワークレイヤ
レベルの処理（IPの場合はTTL(Time To Live) を減らす
処理やチェックサム計算等）は行って、次段ノードへの
専用VCに転送することを、上記専用VCの直結としても良
い。この場合も、上記のATM レベルのルーティングテー
ブルを参照することにより、出力先とすべきVCが決定で
き、パケット転送が行える。この場合は、ネットワーク
レイヤレベルの処理を一部だけ行って、パケットが転送
されることになる。

【００４４】本発明は、CSR の動作が以上に説明したい
ずれのものであっても、適用可能である。さて、RSVPで
資源予約を行う場合は、ルータ内でIP転送のスケジュー
リングを行う必要があるが、ルータにCSR を用いると、
パケット転送をATM セル単位でATM スイッチ機能で転送
できるので、パケット転送のスケジューリングをATM ス
イッチ機能で行うことができる。すなわち、資源を予約
しているパケットについては、ATM スイッチ機能（ATM
セル転送、AAL フレーム転送、IP処理の一部を省略した
パケット転送のいずれでも良い）を用いることにより高
速に転送を行うことができる。以下では、RSVPを用いた
時の専用VCの設定手順を述べる。

【００４５】（具体例１）本例では、ATM コネクション
がSVC(Switched Virtual Connection)であり、ユニキャ
ストを想定した場合について説明する。

【００４６】図2 の様なネットワークトポロジーを例に
とり専用VCの設定の手順を述べる。H1,H2 はホストを示
し、R1,R2,R3はルータを示している。これらの全てのノ
ード間にはデフォルトVCがあらかじめ設定されていると
仮定する。

【００４７】以下の手順では、R1,R2,R3を取り出して、
その間で行われる手順を説明する。H1とR1間やR3とH2間
のようなホストとルータ間（ホストもルータもいずれも
ノードである）の手順も、仮想コネクション型ネットワ
ークで接続されているならば、ルータ同士の手順と同じ
なので、ここでは、省略する。

【００４８】（具体例１−１）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
図3 のようにルータ１,2,3(R1,R2,R3)が存在している場
合に、ルータ2 での資源予約の方法を述べる。初期状態
として、ルータ1 からルータ2 へ、ルータ2 からルータ
3 へのデフォルトVCとルータ2 からルータ3 への専用VC
が設定されている状況を考える。以下では、メッセージ
交換の様子を示す図（図3 ）と、下流側のルータ（図3
ではR2）内部の動作図（図4 、図5 ）と、上流側のルー
タ（図3ではR1）内部の動作図（図6 ）を用いて説明す
る。

【００４９】はじめに、図3 のようにルータ3 からRSVP
の予約（RESV）メッセージがルータ2 に到着したとす
る。RESVメッセージには、どのパケットに対して予約す
べきか示すためのFlow ID と予約したいQOS が書かれて
いる。Flow ID には、発信元IPアドレス／ポート、宛先
IPアドレス／ポートの組、あるいは、IPv6 のFlow ID
が書かれている。QOS には、帯域の情報や遅延の情報が
書かれている。

【００５０】RESVメッセージを受信したルータ２は、図
4 及び図5 のフローチャートに従い、RSVPメッセージ中
のFlow ID 用の下流側の専用VCがあるかチェックする
（Ｓ１）。この例では、専用VCが存在するので専用VC依
頼メッセージを上流側のノード（R1）に送出する（Ｓ
２）。このメッセージには、RESVメッセージの内容と同
じFlow ID とQOS の情報を持つ。もしくは、RESVのQOS
からATM レベルの品質を求めてこれをQOS の情報として
専用VC依頼メッセージに書き込んでも良い。

【００５１】もし、下流側に専用VCが無い場合は、IP処
理部で要求された資源を確保できるか判断し（Ｓ３）、
資源予約できる場合には、IP転送のスケジューリングを
行うことにより資源予約して上流にRESVメッセージを送
出する（Ｓ５）と共に、専用VC依頼メッセージを上流に
送出し（Ｓ２）、資源予約できない場合には、RESV ERR
ORを下流ノードに送出する（Ｓ４）。

【００５２】なお、自ルータでは下流に専用VCがなくて
も資源予約できる場合であっても、専用VC依頼メッセー
ジを上流に送出するのは、自ルータより上流のノード群
の中に、専用VCの直結を行わないと要求された資源が確
保できないノードが存在する可能性があることに対処す
るためである。特に、宛先ノード（ホストH2）、もしく
は、宛先ノードが非仮想コネクション型ネットワークに
接続されている場合の、非仮想コネクション型ネットワ
ークと仮想コネクション型ネットワークとの境界に位置
するルータは、専用VCの直結は行わないが、専用VC依頼
メッセージは上流に送出するようにする。

【００５３】専用VC依頼メッセージを受信したルータ1
は、図6 のフローチャートに従い、ATM シグナリングを
用いて、専用VC依頼メッセージを送信したノード（ルー
タ2）への、要求QOS を満たせるATM コネクション（専
用VC）を設定する（Ｓ２１）。

【００５４】ATM コネクションの設定が終わるとこのコ
ネクションを両端で一意に識別できるようにVCIDという
識別子を付ける。これは、ルータ1 及び2 の属する論理
ネットワーク内でユニークな識別子である。このVCIDの
付け方は、例えば、グローバルユニークなホストのIDと
そのホストで発行したVCIDのシーケンス番号を付けるこ
とで、一意なVCIDを付けることができる。このように作
ったVCIDを、VCID提案メッセージを新しくつくったATM
コネクション（専用VC）に流すことで、下流ノードに運
ぶ（Ｓ２２）。

【００５５】このメッセージには、送信者側（ルータ1
）が提案するVCIDと、ターゲットIPアドレス（ルータ2
のIPアドレス）とが入っている。ターゲットIPアドレ
スは、後述するように専用VCをポイント−マルチポイン
ト化することに対処するために、書き込まれる。

【００５６】このVCID提案メッセージを受信したノード
（ルータ2 ）は、このメッセージに含まれるターゲット
IPアドレスが自ノードのIPアドレスであるか否かを調べ
（Ｓ１１）、そうである場合は、このVCIDを許容するな
らば、VCID ACKをデフォルトVCで上流ノード（ルータ1
）に送信する（Ｓ１２）。VCID ACKは、少なくとも送
信者側が提案し自ノードが許容したVCIDが入っている。
この手続きにより、VCIDの交換が終了する。

【００５７】VCID交換が終了し、専用VCが使用可能であ
ることを下流側のノード（ルータ2）に知らせるため
に、ルータ1 からルータ2 へ専用VC通知メッセージを送
信する（Ｓ２３）。このメッセージは、デフォルトVC
（すなわちパケット送信に用いられる専用VCとは異なる
VC）にて、送信する。このメッセージには、Flow ID と
VCIDが含まれる。

【００５８】この専用VC通知メッセージを受信したノー
ド（ルータ2 ）は、そのVCIDで特定される専用VCは、そ
のFlow ID で特定されるフロー専用に使えることが分か
るので、同じFlow ID を持つ下流側の専用VCがある（Ｓ
１３ある）ならば、上流側の専用VCと下流側の専用VCと
を直結する（Ｓ１４）。すなわち、ATM レベルのルーテ
ィングテーブルに専用VC同士の対応関係を記憶する。こ
うして専用VCが使用可能になると、上流側にリダイレク
トメッセージを送出する（Ｓ１５）。リダイレクトメッ
セージは、Flow ID とVCIDを含み、デフォルトVCにより
送信される。

【００５９】上流側のノード（ルータ1 ）は、リダイレ
クトメッセージを受信すると、そのFlow ID を今までデ
フォルトVCで送出していて（Ｓ２４Yes ）、同じFlow I
D を持つ上流側の専用VCがない（Ｓ２６ない）ならば、
IP処理部がそのFlow ID に関わるパケットを専用VCに流
すようにする（Ｓ２５）。すなわち、さらに上流側のノ
ード（H1）からデフォルトVCにて送信されてくるパケッ
トをルータ2 への専用VCに転送するよう、IP処理部で用
いるルーティング情報を書き替える。

【００６０】なお、ルータ1 の上流に同じFlow ID を持
つ専用VCが存在する（Ｓ２６ある）場合は、その上流側
の専用VCとルータ2 への専用VCを直結する（Ｓ２７）。
専用VC通知メッセージを受信したノード（ルータ2 ）
は、下流側にFlow ID 用の専用VCがない（Ｓ１３ない）
場合には、上流側の専用VCから受信したパケットをIP処
理部に渡すように設定する（Ｓ１６）。このステップ
は、直結せずに資源予約できるが、上流に専用VC依頼メ
ッセージを送出し、それにより上流側に専用VCが設定さ
れた場合に対応する。

【００６１】最後に、ルータ2 でRSVPのQOS 要求を満足
することができるので、ルータ2 からルータ1 へ、デフ
ォルトVCでRESVの送出を行う（Ｓ１７）。なお、Ｓ１５
のリダイレクト及びＳ１７のRESVの送信順序は逆でも構
わない。

【００６２】以上により、ルータ2 の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ2 か
らルータ1 へ適当なタイミングで定期的に送出すること
により、対応する専用VCを保持する。この保持のための
メッセージは、上記RESVメッセージによって代用しても
構わない。リダイレクトメッセージ（代用する場合はRE
SVメッセージ）が送信されてこなくなったルータへの専
用VCは解放する。

【００６３】（具体例１−２）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。具
体例１−１で説明した手順では、専用VC依頼メッセージ
を送信し、ATM シグナリングを行った後、VCID提案、VC
ID ACK、専用VC通知と３つのメッセージを送信していた
が、専用VC通知メッセージを新たに作ったATM コネクシ
ョン（専用VC）に流すことで、VCID提案メッセージとVC
ID ACKを省略することが可能である。

【００６４】具体的なシーケンス図を図7 で示し、下流
側のノードのフローチャートを図4、図8 に、上流側の
ノードのフローチャートを図9 に示す。具体例１−１か
ら変更した点を説明すると、図7 では、VCID提案メッセ
ージとVCID ACKメッセージが無くなったことと、専用VC
通知メッセージを新たに作ったATM コネクション（専用
VC）で転送することが異なる。また、本例での専用VC通
知メッセージには、Flow ID とVCIDの他に、具体例１−
１ではVCID提案メッセージに含ませていたターゲットIP
アドレスを含ませる。

【００６５】メッセージが２つ不要となったことに伴っ
て、上流側のノード（図9 ）は、VCID ACKメッセージを
受信したときの動作（Ｓ２３）が無くなり、新たに作っ
たATM コネクションに、VCID提案ではなく、上述した専
用VC通知を送信することになる（Ｓ３１）。下流側のノ
ードは、RESVを受信したときの動作は図4 の通りであ
り、VCID ACK提案を受信したときの動作（Ｓ１２）が無
くなり、専用VC通知メッセージを受信したときは、図8
に示すように、このメッセージに含まれるターゲットIP
アドレスが自分のアドレスであるか否かチェックした
後、図5(b)と同様の動作を行う。

【００６６】（具体例２）本例では、ATM コネクション
がVP(Virtual Path)のコネクションであり、ユニキャス
トを想定した場合について説明する。図10のようにルー
タ１,2,3(R1,R2,R3)が存在している場合に、ルータ2 で
の資源予約の方法を述べる。初期状態として、ルータ1
からルータ2 へ、ルータ2 からルータ3 へのデフォルト
VCとルータ2 からルータ3 への専用VCが設定されている
状況を考える。以下では、メッセージ交換の様子を示す
図（図10）と下流側のルータ内部の動作図（図11、図1
2）と上流側のルータ内部の動作（図13）を用いて説明
する。

【００６７】はじめに、図10のようにルータ3 からRSVP
の予約（RESV）メッセージがルータ2 に到着したとす
る。RESVメッセージには、どのパケットに対して予約す
べきか示すためのFlow ID と予約したいQOS が書かれて
いる。

【００６８】RESVメッセージを受信したルータ２は、図
11のフローチャートに従い、RSVPメッセージ中のFlow I
D 用の下流側の専用VCがあるかチェックする（Ｓ４
１）。この例では、専用VCが存在するので、上流側のル
ータからの（R1からR2への）未使用VCのうち適当なもの
を選んでこれを専用VCとして使用することを決定し（Ｓ
４２）、この決定した上流の専用VCと下流に存在する専
用VCとを直結（ATM レベルのルーティングテーブルに対
応関係を記憶）し（Ｓ４３）、リダイレクトメッセージ
をデフォルトVCで上流側のノード（R1）に送出する（Ｓ
４４）。

【００６９】このメッセージには、RESVメッセージの内
容と同じFlow ID と、VCIDの情報を持つ。VCIDは、VP中
の使用していないVCI （上記のように選んだ専用VCのVC
I ）を使用し、VPI/VCI の組をVCIDの値とする。もし、
下流側に専用VCが無い場合は、IP処理部で要求された資
源を確保できるか判断し（Ｓ４５）、資源予約できる場
合には、IP転送のスケジューリングを行うことにより資
源予約して上流にRESVメッセージを送出する（Ｓ４６）
と共に、上流側のルータとの間の未使用VCのうち適当な
ものを選んでこれを専用VCとして使用することを決定し
（Ｓ４７）、この専用VCで受信したパケットをIP処理部
に渡すように設定し（Ｓ４８）、リダイレクトメッセー
ジを上流に送出する（Ｓ４４）。資源予約できない場合
には、RESV ERRORを下流ノード(R3)に送出する（Ｓ４
９）。

【００７０】リダイレクトメッセージを受信したルータ
１は、図13のフローチャートに従い、図6(c)と同様にFl
ow ID に関するパケット転送をデフォルトVCを使う転送
から専用VCによる転送に切り替え、下流側のノードにデ
フォルトVC（もしくは専用VC）で専用VC通知メッセージ
を送出する（Ｓ５１）。このメッセージには、 FlowID
（とVCID）の情報が含まれる。

【００７１】下流側のノード（ルータ２）が専用VC通知
メッセージを受信すると、図12のフローチャートに従い
動作する。すなわち、 VCID で特定される専用VCは、Fl
ow ID 専用に使えることが分かり、ルータ2 でRSVPのQO
S 要求を満足することができるので、ルータ2 からルー
タ1 へ、デフォルトVCでRESVの送出を行う（Ｓ５２）。

【００７２】以上により、ルータ2 の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ2 か
らルータ1 へ適当なタイミングで定期的に送出すること
により、対応する専用VCを保持する。この保持のための
メッセージは、上記RESVメッセージによって代用しても
構わない。リダイレクトメッセージ（代用する場合はRE
SVメッセージ）が送信されてこなくなったルータへ専用
VCは解放する。

【００７３】（具体例３）本例では、ATM コネクション
がSVC であり、マルチキャストを想定した場合について
説明する。図14のようにルータ１,2,3,4(R1,R2,R3,R4)
が存在している場合に、ルータ4での資源予約の方法を
述べる。ホストH2,H3 がマルチキャストグループG に参
加しているため、ルータ2 からルータ3 とルータ４へ、
ポイント−マルチポイント( 以下p-mpと言う) のデフォ
ルトVCが設定されている。また、上流のルータから下流
のルータへデータパケット等を流すために設定されてい
るデフォルトVCはマルチキャスト用（p-mpとなり得るも
の）であり、このマルチキャスト用デフォルトVCとは別
に、下流から上流に制御パケット等を流すためにポイン
ト−ポイント( 以下p-p と言う) のデフォルトVCが、必
要に応じて設定される。

【００７４】（具体例３−１）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
初期状態として、図15のように、ルータ2 からルータ3
とルータ４へ、マルチキャスト用のデフォルトVC（p-mp
となり得る( ここでは既になっている)VC ）が設定さ
れ、ルータ2 からルータ3 へのp-mpとなり得る（ここで
はまだなっていない）専用VCが設定され、ホスト3 とル
ータ4 間に（p-p の）デフォルトVCが設定されている状
況を考える。ルータ2 からルータ3 への専用VCは、マル
チキャストグループG の専用VCとする。

【００７５】ここで、ルータ1 からルータ2 への専用VC
や、ルータ2 からルータ3 への専用VCは、具体例１−１
で説明した手順により設定されたものである。但し、具
体例１−１で説明したRESV、VCID ACK、専用VC通知、リ
ダイレクトの各メッセージは、p-p のデフォルトVCを用
いて送信される。

【００７６】以下では、メッセージ交換の様子を示す図
（図15）と、下流側のルータ（図15ではR4）内部の動作
図（図4 、図5 ）と、上流側のルータ（図15ではR2）内
部の動作図（図6 ）を用いて、ルータ4 がマルチキャス
トグループG のパケットのための資源予約を行う手順を
述べる。

【００７７】はじめに、図15のようにホスト3 からデフ
ォルトVCで、RSVPの予約（RESV）メッセージがルータ４
に到着したとする。なお、これはマルチキャスト用のデ
フォルトVCを用いて上流から下流へ転送されたRSVPのPa
thメッセージに応答してホスト3 が送信したものであ
る。

【００７８】RESVメッセージには、どのパケットに対し
て予約すべきか示すためのFlow IDと予約したいQOS が
書かれている。Flow ID には、発信元IPアドレス／ポー
ト、宛先IPアドレス／ポートの組、あるいは、IPv6 の
Flow ID が書かれている。QOS には、帯域の情報や遅延
の情報が書かれている。

【００７９】RESVメッセージを受信したルータ４は、図
4 及び図5 のフローチャートに従い、RSVPメッセージ中
のFlow ID 用の下流側の専用VCがあるかチェックする
（Ｓ１）。この例では、下流側に専用VCが無いので、IP
処理部で要求された資源を確保できるか判断し（Ｓ
３）、資源予約できる場合には専用VC依頼メッセージを
上流に送出し（Ｓ２）、資源予約できない場合には、RE
SV ERRORを下流ノードに送出する（Ｓ４）。ここでは、
資源予約が出来たとして話を進める。

【００８０】専用VC依頼メッセージを受信したルータ２
は、図6 のフローチャートに従い、ATM シグナリングを
用いて、専用VC依頼メッセージを送信したノード（ルー
タ2）への、要求QOS を満たせるATM コネクション（専
用VC）を設定する（Ｓ２１）。この場合のシグナリング
は、ADD PARTY であり、ルータ２からルータ３への専用
VCが経由するスイッチのいずれかから分岐してルータ４
に達する新たなリンクを既に存在する専用VCに追加する
ことになる。

【００８１】ATM コネクションの設定が終わると、この
コネクションを両端で一意に識別できるように、ルータ
２からルータ３への専用VCを設定したときに定めたVCID
を、VCID提案メッセージを新しくリーフを追加したATM
コネクション（専用VC）に流すことで、下流ノードに運
ぶ（Ｓ２２）。このメッセージには、送信者側（ルータ
２）が提案するVCIDと、ターゲットIPアドレス（ルータ
４のIPアドレス）とが入っている。

【００８２】このVCID提案メッセージを受信したノード
（ルータ３、ルータ4 ）は、このメッセージに含まれる
ターゲットIPアドレスが自ノードのIPアドレスであるか
否かを調べ（Ｓ１１）、そうである場合は、このVCIDを
許容するならば、VCID ACKをp-p のデフォルトVCで上流
ノード（ルータ２）に送信する（Ｓ１２）。VCID ACK
は、少なくとも送信者側が提案し自ノードが許容したVC
IDが入っている。この手続きにより、VCIDの交換が終了
する。ここでは、ルータ４がターゲットであるので、ル
ータ4 のみVCID ACKを上流ノードに送信する。

【００８３】VCID交換が終了し、専用VCが使用可能であ
ることを下流側のノード（ルータ４）に知らせるため
に、ルータ２ からルータ４ へ専用VC通知メッセージ
を送信する（Ｓ２３）。このメッセージは、p-p のデフ
ォルトVC（すなわちパケット送信に用いられる専用VCと
は異なるVC）にて、送信する。このメッセージには、Fl
ow ID とVCIDが含まれる。

【００８４】この専用VC通知メッセージを受信したノー
ド（ルータ４）は、そのVCIDで特定される専用VCは、そ
のFlow ID で特定されるフロー専用に使えることが分か
る。下流側のFlow ID 用の専用VCがあることをチェック
して、専用VCが無いことが分かるので（Ｓ１３ない）、
上流側の専用VCで受信したパケットをIP処理部に渡すよ
うに設定する（Ｓ１６）。なお、専用VCがある場合は、
直結する。

【００８５】なお、ルータ４には、ADD PARTY によって
専用VCに自分へのリーフが追加された時点から、パケッ
トが送信されてくるが、専用VC通知メッセージを受信す
るまでは、このパケットの扱いが分からないため無視
し、専用VC通知を受けて必要な設定がされるまでは、マ
ルチキャスト用デフォルトVCにて送信されてくるパケッ
トをIP処理部に渡してホスト３への転送を行っている。

【００８６】こうして専用VCが使用可能になると、上流
側にリダイレクトメッセージを送出する（Ｓ１５）。リ
ダイレクトメッセージは、Flow ID とVCIDを含み、p-p
のデフォルトVCにより送信される。

【００８７】上流側のノード（ルータ２）は、リダイレ
クトメッセージを受信すると、そのFlow ID は今まで専
用VCで送出していたので（Ｓ２４No）、何もしない。な
お、マルチキャストの場合の上流側のノードの動作のう
ち、図6(c)のＳ２５は、今までマルチキャスト用デフォ
ルトVCに流していたそのFlow ID に関わるパケットを専
用VCに流すようにしたとき、マルチキャストデフォルト
VCにも同じパケットを流し続けるようにする。これは、
マルチキャストの場合は受信者毎に異なるQOS を要求す
る可能性があり、専用VCを設定せずマルチキャスト用デ
フォルトVCにてパケットを受け取っているノードが存在
するかもしれないことに対処するためである。

【００８８】最後に、ルータ４でRSVPのQOS 要求を満足
することができるので、ルータ４からルータ２へ、p-p
のデフォルトVCでRESVの送出を行う（Ｓ１７）。なお、
Ｓ１５及びＳ１７の順序は逆でも構わない。

【００８９】以上により、ルータ４の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ４か
らルータ２へ適当なタイミングで定期的に送出すること
により、対応する専用VCのリーフを保持する。この保持
のためのメッセージは、上記RESVメッセージによって代
用しても構わない。リダイレクトメッセージ（代用する
場合はRESVメッセージ）が送信されてこなくなったルー
タへのリーフは削除する。

【００９０】（具体例３−２）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。初
期状態として、図15と同様な状況を考える。ここで、ル
ータ1 からルータ2への専用VCや、ルータ2 からルータ3
への専用VCは、具体例１−２で説明した手順により設
定されたものである。但し、具体例１−２で説明したRE
SV、リダイレクトの各メッセージは、p-p のデフォルト
VCを用いて送信される。

【００９１】メッセージ交換の様子を示す図（図16）
と、下流側のルータ（図16ではR4）内部の動作図（図4
、図8 ）と、上流側のルータ（図16ではR2）内部の動
作図（図9 ）を用いて、ルータ4 がマルチキャストグル
ープG のパケットのための資源予約を行う手順を述べ
る。

【００９２】具体例３−１から変更した点を説明する
と、図16では、VCID提案メッセージとVCID ACKメッセー
ジが無くなったことと、専用VC通知メッセージを新たに
リーフを追加したATM コネクション（専用VC）で転送す
ることが異なる。また、本例での専用VC通知メッセージ
には、Flow ID とVCIDの他に、具体例３−１ではVCID提
案メッセージに含ませていたターゲットIPアドレスを含
ませる。これにより、ルータ4 への専用VC通知を受け取
ってしまうルータ3 は、これを無視することができる。

【００９３】メッセージが２つ不要となったことに伴っ
て、上流側のノード（図9 ）は、VCID ACKメッセージを
受信したときの動作（Ｓ２３）が無くなり、新たにリー
フを追加したATM コネクションに、VCID提案ではなく、
上述した専用VC通知を送信することになる（Ｓ３１）。
下流側のノードは、RESVを受信したときの動作は図4の
通りであり、、VCID ACK提案を受信したときの動作（Ｓ
１２）が無くなり、専用VC通知メッセージを受信したと
きは、図8 に示すように、このメッセージに含まれるタ
ーゲットIPアドレスが自分のアドレスであるか否かチェ
ックした後、図5(b)と同様の動作を行う。

【００９４】以上の説明では、RSVPをきっかけとしてCS
R の技術を生かした資源予約を行う方法を述べたが、上
述したようにRSVPのRESVメッセージをトリガとして専用
VCを設定するのではなく、データパケットをトリガとし
て専用VCを設定することも、同様にして実現できる。

【００９５】上述したRSVPをきっかけとする場合と異な
る点は、以下の２つである。一つは、RSVP有りの場合
は、RESVメッセージを受信すると専用VC依頼メッセージ
を送出したが、RSVPが無い場合は、データパケットが来
たときに、専用VC依頼メッセージを送出する点である。
その後、専用VCを設定し、これをデータパケット転送の
ために使用可能とする（直結するかもしくはIP処理をし
て転送するようにする）動作を行うことは同様である。
もう一つの違いは、専用VC通知メッセージを受信したと
きに、RESVメッセージを上流に送信しないことである。

【００９６】具体的には、例えば図２のルータ２が、デ
フォルトVCにてデータパケットを受信すると、そのデー
タパケットをデフォルトVC（もしくは専用VC）にて次段
のノード（ルータ３）に転送した後、パケットに関係あ
るFlow ID を持つ専用VCを上流側に設定するよう、専用
VC依頼メッセージを上流（ルータ１）へ送出する。この
とき、上記データパケットに書かれた送信元アドレス／
ポートと宛先アドレス／ポートの組（宛先アドレス／ポ
ートだけでもよい）等をFlow ID とし、このFlow ID を
専用VC依頼メッセージに含ませる。

【００９７】そして、ルータ１との間に専用VCが設定さ
れたことを専用VC通知メッセージにより知ると、そのパ
ケットに関係あるFlow ID を持つ下流側の（ルータ３へ
の）専用VCがあるならば、直結し、なければ、ルータ１
から専用VCで転送されてきたパケットをルータ３へのデ
フォルトVCで転送するようにする。また、ルータ１は、
ルータ２が専用VCを使用可能となったことをリダイレク
トメッセージにより知ると、今までデフォルトVCで転送
していたデータパケットを、専用VCで転送するようにす
る。

【００９８】また、例えば図１４のルータ４が、マルチ
キャスト用のデフォルトVCにてデータパケットを受信す
る（ルータ１はこの時点でルータ３のための専用VCによ
る転送とルータ４のためのデフォルトVCによる転送とを
行っている）と、そのデータパケットをデフォルトVC
（もしくは専用VC）にて次段のノード（ホスト３）に転
送した後、そのデータパケットから求めたFlow ID （こ
の場合のアドレスはマルチキャストアドレス）を持つ専
用VCを上流側に設定するよう、専用VC依頼メッセージを
p-p のデフォルトVCにて上流（ルータ２）へ送出する。

【００９９】そして、ルータ２からルータ３への専用VC
にルータ４へのリーフが追加されたことを専用VC通知メ
ッセージにより知ると、そのパケットに関係あるFlow I
D を持つ下流側の専用VCがあるならば、直結し、なけれ
ば、ルータ１から専用VCで転送されてきたパケットをホ
スト３へのデフォルトVCで転送するようにする。なお、
ルータ１は、ルータ３、４からそれぞれのp-p デフォル
トVCにてリダイレクトメッセージが定期的に送信されて
くる間は、p-mp専用VCのそれぞれに対応するリーフを維
持する（リダイレクトメッセージが送信されてこなくな
ったルータへのリーフは削除する）。

【０１００】なお、このようにデータパケットをきっか
けとする場合、データパケットに含まれる情報に基づい
て、上記手順を起動するデータパケット（が属するフロ
ー）を選択するようにしても良い。

【０１０１】（実施形態２）本実施形態では、CSR の技
術を用いて、ATM 上で資源予約プロトコルであるRSVPを
実現するための、別の方法を述べる。実施形態１では、
RSVPのRESVメッセージが到着したノードから上流側に専
用VCを設定する手順を説明したが、ここでは、RESVメッ
セージが到着したときに下流側に専用VCを設定する手順
を説明する。

【０１０２】（具体例１）本例では、ATM コネクション
がSVC(Switched Virtual Connection)であり、ユニキャ
ストを想定した場合について説明する。

【０１０３】（具体例１−１）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。

【０１０４】図17のようにルータ１,2,3(R1,R2,R3)が存
在している場合に、ルータ2 での資源予約の方法を述べ
る。初期状態として、ルータ1 からルータ2 へ、ルータ
2 からルータ3 へのデフォルトVCが設定されている状況
を考える。以下では、メッセージ交換の様子を示す図
（図17）と、下流側のルータ（図17ではR2）内部の動作
図（図22、図23）と、上流側のルータ（図17ではR1）内
部の動作図（図18、図19、図20、図21）を用いて説明す
る。

【０１０５】はじめに、図17のようにルータ３からRSVP
のRESVメッセージがルータ２に到着したとする。RESVメ
ッセージには、Flow ID と予約したいQOS が書かれてい
る。ルータ2 は、RESVメッセージに書かれた予約したい
QOS を実現する資源予約がIPスケジューラで行えるか否
かを判断し（Ｓ６１）、できる場合には、IPスケジュー
ラで資源予約する（Ｓ６２）と共に、RESVメッセージを
デフォルトVCで上流側に（ルータ1 へ）転送する（Ｓ６
３）。できない場合にも、ルータ2 では今は資源予約が
できていないが、後で上流側と下流側の両方に専用VCが
設定されて直結を行うことにより資源予約ができること
を見越して、RESVメッセージを上流側に送出する（Ｓ６
３）。

【０１０６】RESVを送出すると、下流側に（ルータ3
へ）専用VCを設定するための動作を行う。なお、RESVメ
ッセージは、下流側の専用VCが設定された（ルータ3 か
らリダイレクトメッセージが返ってきた）後に、上流側
に送出することとしても構わない。

【０１０７】ここで、IPスケジューラで資源予約できる
場合にも、下流側に専用VCを設定するための動作を行う
のは、後で上流側と下流側の両方に専用VCが設定されて
直結を行うことができた場合に、このフローのための資
源予約をIPスケジューラではなくATM スイッチ機能にて
行うことで、IPスケジューラの資源になるべく余裕を持
たせ、他のフローがIPスケジューラの資源を使えるよう
にしておくためである。

【０１０８】RESVメッセージを受信したルータ２の動作
手順は、図18に示すように、RESVメッセージを上流に送
信した（Ｓ６３）後、ATM シグナリングでATM コネクシ
ョン（専用VC）を次段ノード（ルータ3 ）へ設定した
後、VCID提案メッセージをこの専用VCにて送信する（Ｓ
６５）。

【０１０９】VCID提案メッセージを受信した下流ノード
（ルータ３）は、図22にしたがって、ターゲットIPが自
分のアドレスかチェックして（Ｓ７１）、自分のアドレ
スの場合は、VCID ACKをデフォルトVCにて送信する（Ｓ
７２）。

【０１１０】VCID ACKを受信した上流ノード（ルータ
２）は、図19にしたがって、下流側に専用VC通知をデフ
ォルトVCにて送信する（Ｓ６６）。専用VC通知を受信し
た下流ノード（ルータ３）は、図23にしたがって、同じ
Flow ID を持つ下流側の（ホスト2 への）専用VCがある
かチェックして（Ｓ７３）、無い場合は、上流側の（ル
ータ2 からの）専用VCで受信したパケットをIP処理部に
渡すように設定する（Ｓ７４）。ある場合は、上流側の
専用VCと下流側の専用VCを直結する（Ｓ７５）。最後
に、自ノードが専用VCを使用可能になったことを上流に
知らせるため、リダイレクトメッセージをデフォルトVC
で上流ノードに送信する（Ｓ７６）。

【０１１１】リダイレクトメッセージを受信した上流ノ
ード（ルータ２）は、図20及び21にしたがって、デフォ
ルト転送を行っていない（後述するマルチキャストのよ
うに既にその専用VC上へパケット転送を行っている）場
合は（Ｓ８１No）、終了する。

【０１１２】デフォルト転送を行っている場合は、同じ
Flow ID を持つ上流側の（ルータ1からの）専用VCがあ
るかチェックして（Ｓ８２）、専用VCがある場合は、上
流側の専用VCと下流側の（ルータ3 への）専用VCを直結
する（Ｓ８３）。専用VCが無い場合は、IP処理部で今ま
でデフォルトVCにて転送していたパケットを専用VCにて
転送するようにする（Ｓ８４）。

【０１１３】このFlow ID に関して、自ノードが受信し
たパケットを転送するのではなく、自ノードが送信ノー
ドである場合は（Ｓ８５Yes ）、ここで終了する。それ
以外の場合は、一定時間待ち（Ｓ８６）、上流側に下流
側と同じFlow IDを持つ専用VCが設定されず、上流側の
専用VCと下流側の専用VCが直結しなかったら（Ｓ８７N
o）、IPスケジューラでの資源予約（Ｓ６２）を行って
いたかを調べ（Ｓ８８）、行っていればそのままとし、
行っていなければ、上流側（ルータ1）に、Ｓ６３にて
送信したRESVメッセージを取り消すための、RESV Tear
メッセージを送信し、下流側（ルータ3 ）に、資源予約
に失敗したことを示すRESV Errメッセージを送信する。
なお、Ｓ８８で改めてIPスケジューラの資源予約ができ
るかを調べ直しても構わない。

【０１１４】また、一定時間内に、上流側に下流側と同
じFlow ID を持つ専用VCが設定され、上流側の専用VCと
下流側の専用VCが直結されれば（Ｓ８７Yes ）、IPスケ
ジューラでの資源予約（Ｓ６２）を行っていたかを調べ
（Ｓ９０）、行っていなければそのままとし、行ってい
れば、この資源予約は専用VCの直結により不要となって
いるから、取り消す（Ｓ９１）。

【０１１５】なお、上記の説明では、先にIPスケジュー
ラの資源予約を行ってから、専用ＶＣが直結できたらこ
れを取り消すこととしたが、専用ＶＣの直結ができる可
能性が高い場合には、IPスケジューラの資源予約は行わ
ずに下流側に専用VCを設定し、上流側に専用VCができる
のを待ってできたら直結し、直結ができないことを確認
した時点（Ｓ８７No）でIPスケジューラの資源予約を試
み、資源予約できればそのままとし、できなければ上流
にRESV Tear を、下流にRESV Errを返すこととしても構
わない。

【０１１６】以上により、ルータ2 の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ３か
らルータ２へ適当なタイミングで定期的に送出すること
により、対応する専用VCを保持する。この保持のための
メッセージは、RESVメッセージによって代用しても構わ
ない。リダイレクトメッセージ（代用する場合はRESVメ
ッセージ）が送信されてこなくなったルータへの専用VC
は解放する。

【０１１７】（具体例１−２）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。具
体例１−１で説明した手順では、ATM シグナリングを行
った後、VCID提案、VCID ACK、専用VC通知と３つのメッ
セージを送信していたが、専用VC通知メッセージを新た
に作ったATM コネクション（専用VC）に流すことで、VC
ID提案メッセージとVCID ACKを省略することが可能であ
る。

【０１１８】具体的なシーケンス図を図２４で示し、下
流側のノードのフローチャートを図２０、２１、２５
に、上流側のノードのフローチャートを図２６に示す。
具体例１−１から変更した点を説明すると、図２４で
は、VCID提案メッセージとVCID ACKメッセージが無くな
ったことと、専用VC通知メッセージを新たに作ったATM
コネクション（専用VC）で転送することが異なる。ま
た、本例での専用VC通知メッセージには、Flow ID とVC
IDの他に、具体例１−１ではVCID提案メッセージに含ま
せていたターゲットIPアドレスを含ませる。

【０１１９】メッセージが２つ不要となったことに伴っ
て、上流側のノードは、VCID ACKメッセージを受信した
ときの動作（図１９）が無くなり、新たに作ったATM コ
ネクションに、VCID提案ではなく、上述した専用VC通知
を送信することになる（図２５のＳ１０５）。

【０１２０】下流側のノードは、VCID ACK提案を受信し
たときの動作（図２２）が無くなり、専用VC通知メッセ
ージを受信したときは、図２６に示すように、このメッ
セージに含まれるターゲットIPアドレスが自分のアドレ
スであるか否かチェック（Ｓ１１１）した後、図２３と
同様の動作を行う。

【０１２１】（具体例２）本例では、ATM コネクション
がVP(Virtual Path)のコネクションであり、ユニキャス
トを想定した場合について説明する。図２７のようにル
ータ１,2,3(R1,R2,R3)が存在している場合に、ルータ2
での資源予約の方法を述べる。初期状態として、ルータ
1 からルータ2 へ、ルータ2からルータ3 へのデフォル
トVCが設定されている状況を考える。以下では、メッセ
ージ交換の様子を示す図（図２７）と下流側のルータ内
部の動作図（図２３）と上流側のルータ内部の動作（図
２０、２１、２８）を用い、具体例１から変更した点を
説明する。

【０１２２】図１７では、予約（RESV）メッセージを受
信すると、ATM シグナリング、VCID提案、VCID ACKを行
っていたが、VPの場合は、予めATM コネクションがあ
り、VCIDとしてVPI/VCI を利用することが出来るので、
これらのメッセージが図２７では無い。

【０１２３】この３つのメッセージ転送が無いために、
上流側ノードでは、図１８のＳ６５のVCID提案メッセー
ジ送信の代わりに、図２８のＳ１２５の専用VC通知メッ
セージを送信する。また、図１９のVCID ACK受信に対す
る動作が無い。下流側ノードでは、図２２のVCID提案受
信した場合の動作が無い。

【０１２４】（具体例３）本例では、ATM コネクション
がSVC であり、マルチキャストを想定した場合について
説明する。

【０１２５】（具体例３−１）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
初期状態として、図２９のように、ルータ2 からルータ
3 とルータ４へ、マルチキャスト用のデフォルトVC（p-
mpとなり得る( ここでは既になっている)VC ）が設定さ
れ、ルータ２からルータ３へのp-mpとなり得る（ここで
はまだなっていない）専用VCが設定され、ルータ１とル
ータ２間に（p-p の）デフォルトVCが設定されている状
況を考える。ルータ2 からルータ3 への専用VCは、マル
チキャストグループG の専用VCとする。

【０１２６】ここで、ルータ１から２への専用VCや、ル
ータ２から３への専用VCは、具体例１−１で説明した手
順により設定されたものである。但し、具体例１−１で
説明したRESV、VCID ACK、専用VC通知、リダイレクトの
各メッセージは、p-p のデフォルトVCを用いて送信され
る。

【０１２７】以下では、メッセージ交換の様子を示す図
（図２９）と、下流側のルータ（図２９ではR4）内部の
動作図（図２２、図２３）と、上流側のルータ（図２９
ではR2）内部の動作図（図１８、１９、２０、２１）を
用いて、ルータ２がマルチキャストグループG のパケッ
トのための資源予約を行う手順を述べる。

【０１２８】はじめに、図２９のようにルータ４からデ
フォルトVCで、RSVPの予約（RESV）メッセージがルータ
２に到着したとする。なお、これはマルチキャスト用の
デフォルトVCを用いて上流から下流へ転送されたRSVPの
Pathメッセージに応答してルータ４が送信したものであ
る。

【０１２９】RESVメッセージには、どのパケットに対し
て予約すべきか示すためのFlow IDと予約したいQOS が
書かれている。RESVメッセージを受信したルータ２は、
図１８のフローチャートに従い、IPスケジューラで資源
予約出来るかチェックする（S ６１）。資源予約出来る
場合は、資源予約した後（S ６２）、予約（RESV）メッ
セージを上流に送信する（S ６３）。資源予約出来なか
った場合は、資源予約をせずに、予約メッセージを上流
に送信する（S ６３）。

【０１３０】次にATM シグナリングでATM コネクション
を下流ノードに設定した後（Ｓ６４）、VCID提案メッセ
ージを設定したATM コネクションで送信する（S ６
５）。このVCID提案メッセージには、ターゲットIPアド
レスと VCID が書かれている。ここで、ターゲットIPア
ドレスは、ルータ4 のアドレスが入っている。

【０１３１】VCID提案メッセージは、ルータ３とルータ
４が受信する。これを受信したノードは、図２２のフロ
ーチャートに従い、ターゲットIPアドレスが自分のアド
レスかチェックする。VCID提案メッセージのターゲット
IPアドレスは、ルータ4 になっており、ルータ3 では、
自分のIPアドレスと異なる（S ７１No）ので、何もせず
に終了する。ルータ４では、自分のIPアドレスを同じな
ので（S ７１yes)、VCID ACKを上流に送信する（S ７
２）。

【０１３２】VCID交換が終了し、専用VCが使用可能であ
ることを下流側のノード（ルータ４）に知らせるため
に、ルータ２からルータ４へ専用VC通知メッセージを送
信する（図１９のS ６６）。このメッセージは、p-p の
デフォルトVCにて、送信する。このメッセージには、Fl
ow ID とVCIDが含まれる。

【０１３３】この専用VC通知メッセージを受信したノー
ド（ルータ４）は、そのVCIDで特定される専用VCは、そ
のFlow ID で特定されるフロー専用に使えることが分か
る。図２３に従い、下流側のFlow ID 用の専用VCがある
ことをチェックして、専用ＶＣが無いことが分かるので
（Ｓ７３なし）、上流側の専用ＶＣで受信したパケット
をIP処理部に渡すように設定する（Ｓ７４）。なお、専
用VCがある場合は、直結する。

【０１３４】なお、ルータ４には、ADD PARTY によって
専用VCに自分へのリーフが追加された時点から、パケッ
トが送信されてくるが、専用VC通知メッセージを受信す
るまでは、このパケットの扱いが分からないため無視
し、専用VC通知を受けて必要な設定がされるまでは、マ
ルチキャスト用デフォルトVCにて送信されてくるパケッ
トをIP処理部に渡して転送を行っている。

【０１３５】こうして専用VCが使用可能になると、上流
側にリダイレクトメッセージを送出する（Ｓ７６）。リ
ダイレクトメッセージは、Flow ID とVCIDを含み、p-p
のデフォルトVCにより送信される。

【０１３６】上流側のノード（ルータ２）は、リダイレ
クトメッセージを受信すると、そのFlow ID は今まで専
用VCで送出していたので（Ｓ８１No）、何もしない。な
お、マルチキャストの場合の上流側のノードの動作のう
ち、図２０のＳ８４は、今までマルチキャスト用デフォ
ルトVCに流していたそのFlow ID に関わるパケットを専
用VCに流すようにしたとき、マルチキャストデフォルト
VCにも同じパケットを流し続けるようにする。これは、
マルチキャストの場合は受信者毎に異なるQOS を要求す
る可能性があり、専用VCを設定せずマルチキャスト用デ
フォルトVCにてパケットを受け取っているノードが存在
するかもしれないことに対処するためである。

【０１３７】S ８４を終了したあとの処理は、具体例１
ー１と同様である。以上により、ルータ２のルータ４に
関する資源予約が終了する。なお、上記リダイレクトメ
ッセージを、ルータ４からルータ２へ適当なタイミング
で定期的に送出することにより、対応する専用VCのリー
フを保持する。この保持のためのメッセージは、RESVメ
ッセージによって代用しても構わない。リダイレクトメ
ッセージ（代用する場合はRESVメッセージ）が送信され
てこなくなったルータへのリーフは削除する。

【０１３８】（具体例３−２）本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。初
期状態として、図３０のように、ルータ2 からルータ3
とルータ４へ、マルチキャスト用のデフォルトVC（p-mp
となり得る( ここでは既になっている)VC ）が設定さ
れ、ルータ２からルータ３へのp-mpとなり得る（ここで
はまだなっていない）専用VCが設定され、ルータ１とル
ータ２間に（p-p の）デフォルトVCが設定されている状
況を考える。ルータ2 からルータ3 への専用VCは、マル
チキャストグループG の専用VCとする。

【０１３９】具体例３−１で説明した手順では、ATM シ
グナリングを行った後、VCID提案、VCID ACK、専用VC通
知と３つのメッセージを送信していたが、専用VC通知メ
ッセージを新たに作ったATM コネクション（専用VC）に
流すことで、VCID提案メッセージとVCID ACKを省略する
ことが可能である。

【０１４０】具体的なシーケンス図を図３０で示し、下
流側のノード（図３０ではR4）のフローチャートを図２
０、２１、２５に、上流側のノード( 図３０ではR2) の
フローチャートを図２６に示す。

【０１４１】具体例３ー１から変更した点を説明する
と、VCID提案メッセージを送出する代わりに、専用VC通
知メッセージを新たに作ったATM コネクション（専用V
C）で転送することが異なる。また、本例での専用VC通
知メッセージには、Flow ID とVCIDの他に、具体例１−
１ではVCID提案メッセージに含ませていたターゲットIP
アドレスを含ませる。

【０１４２】メッセージが２つ不要となったことに伴っ
て、上流側のノードは、VCID ACKメッセージを受信した
ときの動作（図１９）が無くなり、新たに作ったATM コ
ネクションに、VCID提案ではなく、上述した専用VC通知
を送信することになる（図２５のＳ１０５）。

【０１４３】下流側のノードは、VCID ACK提案を受信し
たときの動作（図２２）が無くなり、専用VC通知メッセ
ージを受信したときは、図２６に示すように、このメッ
セージに含まれるターゲットIPアドレスが自分のアドレ
スであるか否かチェック（Ｓ１１１）した後、図２３と
同様の動作を行う。

【０１４４】以上の説明では、RSVPをきっかけとしてCS
R の技術を生かした資源予約を行う方法を述べたが、上
述したようにRSVPのRESVメッセージをトリガとして専用
VCを設定するのではなく、データパケットをトリガとし
て専用VCを設定することも、同様にして実現できる。

【０１４５】上述したRSVPをきっかけとする場合と異な
る点は、以下の２つである。一つは、RSVP有りの場合
は、RESVメッセージを受信するとATM シグナリングを行
い下流に専用VCを設定したが、RSVPが無い場合は、デー
タパケットが来たときに、これを行う点である。その
後、設定した専用VCをデータパケット転送のために使用
可能とする（直結するかもしくはIP処理をして転送する
ようにする）動作を行うことは同様である。もう一つの
違いは、RESVメッセージ、RESV Tear を上流に送信しな
いことである。

【０１４６】具体的には、例えば図２のルータ２が、デ
フォルトVCもしくは専用VCにてデータパケットを受信す
ると、そのデータパケットをデフォルトVCにて次段のノ
ード（ルータ３）に転送した後、パケットに関係あるFl
ow ID を持つ次段のノードへの専用VCを設定するよう、
ATM シグナリングを行う。そして、上記データパケット
に書かれた送信元アドレス／ポートと宛先アドレス／ポ
ートの組（宛先アドレス／ポートだけでもよい）等をFl
ow ID とし、このFlow ID を書き込んだ専用VC通知メッ
セージを下流に送出する。

【０１４７】そして、ルータ2 は、ルータ3 がこの専用
VCを使用可能になったことをリダイレクトメッセージに
より知ると、そのパケットに関係あるFlow ID を持つ上
流側の（ルータ1 からの）専用VCがあるならば、直結
し、なければ、ルータ１からデフォルトVCで転送されて
きたパケットをルータ３への専用VCで転送するようにす
る。

【０１４８】また、例えば図１４のルータ２が、IPマル
チキャスト用のプロトコル（例えばIGMP(Internet Grou
p Management Protocol)）により、ルータ4 がマルチキ
ャストグループG に参加したことを認識すると、それに
関係するFlow ID （この場合のアドレスはマルチキャス
トアドレス）を持つ専用VCを下流側に設定するよう、AD
D PARTY を行う。そして、ルータ２からルータ３への専
用VCにルータ４へのリーフが追加される。なお、ルータ
2 は、ルータ３、４からそれぞれのp-p デフォルトVCに
てリダイレクトメッセージが定期的に送信されてくる間
は、p-mp専用VCのそれぞれに対応するリーフを維持する
（リダイレクトメッセージが送信されてこなくなったル
ータへのリーフは削除する）。

【０１４９】なお、このようにデータパケットをきっか
けとする場合、データパケットに含まれる情報に基づい
て、上記手順を起動するデータパケット（が属するフロ
ー）を選択するようにしても良い。

【０１５０】

【発明の効果】以上詳述したように、本発明の第一乃至
第四の発明によれば、ネットワークレイヤのスケジュー
リングのみによっては、資源予約のためのメッセージに
示される要求サービス品質を満たすことができない場合
にも、ネットワークレイヤより下位のレイヤでの仮想コ
ネクションのスイッチング機能の利用により要求された
資源の予約を可能とし、かつ、自ノードで資源予約が行
えたか否かを正しく他のノードに伝えることができる。

【０１５１】また、本発明の第五の発明によれば、ルー
タがネットワークレイヤより下位のレイヤでの仮想コネ
クションのスイッチング機能を利用しつつマルチキャス
ト通信を行う際に、この通信のためのコネクション及び
ルータ内の設定を効率よく行うことができる。

【０１５２】また、本発明の第六の発明によれば、ルー
タ間にスイッチの存在するシステムでマルチキャスト通
信を行う際に、この通信のためのコネクションを両端の
ルータで一意に識別し、必要なコネクション及びルータ
内の設定を効率よく行うことができる。

【図面の簡単な説明】

【図１】 CSR の動作を説明するための図。

【図２】 ユニキャストの場合のネットワークトポロジ
ーの例を示す図。

【図３】 実施形態１の具体例１−１のメッセージ交換
の様子を示す図。

【図４】 実施形態１の下流側のノードの動作例を示す
図。

【図５】 実施形態１の下流側のノードの動作例を示す
図。

【図６】 実施形態１の上流側のノードの動作例を示す
図。

【図７】 実施形態１の具体例１−２のメッセージ交換
の様子を示す図。

【図８】 実施形態１の下流側のノードの別の動作例を
示す図。

【図９】 実施形態１の上流側のノードの別の動作例を
示す図。

【図１０】 実施形態１の具体例２のメッセージ交換の
様子を示す図。

【図１１】 実施形態１の下流側のノードの更に別の動
作例を示す図。

【図１２】 実施形態１の下流側のノードの更に別の動
作例を示す図。

【図１３】 実施形態１の上流側のノードの更に別の動
作例を示す図。

【図１４】 マルチキャストの場合のネットワークトポ
ロジーの例を示す図。

【図１５】 実施形態１の具体例３−１のメッセージ交
換の様子を示す図。

【図１６】 実施形態１の具体例３−２のメッセージ交
換の様子を示す図。

【図１７】 実施形態２の具体例１−１のメッセージ交
換の様子を示す図。

【図１８】 実施形態２の上流側のノードの動作例を示
す図。

【図１９】 実施形態２の上流側のノードの動作例を示
す図。

【図２０】 実施形態２の上流側のノードの動作例を示
す図。

【図２１】 実施形態２の上流側のノードの動作例を示
す図。

【図２２】 実施形態２の下流側のノードの動作例を示
す図。

【図２３】 実施形態２の下流側のノードの動作例を示
す図。

【図２４】 実施形態２の具体例１−２のメッセージ交
換の様子を示す図。

【図２５】 実施形態２の上流側のノードの別の動作例
を示す図。

【図２６】 実施形態２の下流側のノードの別の動作例
を示す図。

【図２７】 実施形態２の具体例２のメッセージ交換の
様子を示す図。

【図２８】 実施形態２の上流側のノードの更に別の動
作例を示す図。

【図２９】 実施形態２の具体例３−１のメッセージ交
換の様子を示す図。

【図３０】 実施形態２の具体例３−２のメッセージ交
換の様子を示す図。

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/00 - 12/66

Claims (9)

(57)【特許請求の範囲】
1. 【請求項１】仮想コネクション型ネットワークとの物理
   インタフェースを有し、少なくとも２つの論理ネットワ
   ークを接続するルータ装置において、 一方の前記論理ネットワークからの受信に使用される仮
   想的転送路と他方の前記論理ネットワークへの送信に使
   用される仮想的転送路との対応関係を記憶する記憶手段
   と、 この記憶された対応関係に従って、パケットの転送を行
   う転送手段と、 資源予約のためのメッセージを受信者側の論理ネットワ
   ークから受信する受信手段と、 この受信した資源予約のためのメッセージに基づき、前
   記受信者側の論理ネットワークへの前記転送手段を介す
   ることが可能なパケット送信用の仮想的転送路の存在、
   及び、送信者側の論理ネットワークからの前記転送手段
   を介することが可能なパケット受信用の仮想的転送路の
   存在の有無に応じて、資源予約のためのメッセージを前
   記送信者側の論理ネットワークへ送信する送信手段とを
   具備したことを特徴とするルータ装置。
2. 【請求項２】前記送信手段は、送信用の前記仮想的転送
   路の設定要求に対する応答を受信した場合に、前記受信
   手段により受信したメッセージに基づく資源予約のため
   のメッセージを、前記両仮想的転送路の存在の有無によ
   らず送信者側の論理ネットワークへ送信する手段をさら
   に備えるものである請求項１に記載のルータ装置。
3. 【請求項３】前記受信手段により受信したメッセージに
   応じて、送信者側の論理ネットワークからの前記転送手
   段を介することが可能なパケット受信用の仮想的転送路
   を設定するよう前記送信者側の論理ネットワークへ要求
   する要求手段を更に具備する請求項１又は２に記載のル
   ータ装置。
4. 【請求項４】仮想コネクション型ネットワークとの物理
   インタフェースを有し、少なくとも２つの論理ネットワ
   ークを接続するルータ装置において、 一方の前記論理ネットワークからの受信に使用される仮
   想的転送路と他方の前記論理ネットワークへの送信に使
   用される仮想的転送路との対応関係を記憶する記憶手段
   と、 この記憶された対応関係に従って、パケットの転送を行
   う転送手段と、 資源予約のためのメッセージを受信者側の論理ネットワ
   ークから受信する受信手段と、 この受信した資源予約のためのメッセージに基づき、資
   源予約のためのメッセージを送信者側の論理ネットワー
   クへ送信する送信手段と、 前記受信者側の論理ネットワークへの前記転送手段を介
   することが可能なパケット送信用の仮想的転送路の存
   在、及び、前記送信者側の論理ネットワークからの前記
   転送手段を介することが可能なパケット受信用の仮想的
   転送路の存在の有無に応じて、前記送信手段により送信
   した資源予約のためのメッセージの取り消しを通知する
   通知手段とを具備したことを特徴とするルータ装置。
5. 【請求項５】前記通知手段は、前記転送手段による転送
   を行わないと前記受信手段により受信したメッセージに
   示される要求サービス品質を満たすことができないと判
   断した場合に、前記両仮想的転送路の存在の有無に応じ
   た通知を行うものである請求項４に記載のルータ装置。
6. 【請求項６】前記受信手段により受信したメッセージに
   応じて、前記受信者側の論理ネットワークへの前記転送
   手段を介することが可能なパケット送信用の仮想的転送
   路を設定する設定手段を更に具備する請求項４又は５に
   記載のルータ装置。
7. 【請求項７】前記転送手段による転送を行わないと前記
   受信手段により受信したメッセージに示される要求サー
   ビス品質を満たすことができないと判断し、かつ、前記
   両仮想的転送路の少なくとも一方の不存在を確認した場
   合に、資源予約に失敗した旨のメッセージを前記受信者
   側の論理ネットワークへ送信する手段を更に具備する請
   求項５乃至６に記載のルータ装置。
8. 【請求項８】第１のノードから送信されるパケットを、
   前記第１のノードとは異なる論理ネットワークに属する
   第２のノードへ転送するパケット転送方法において、 資源予約のためのメッセージを前記第２のノードから受
   信し、 前記第１のノードから前記第２のノードへネットワーク
   レイヤレベルの転送処理の一部又は全部を行わずにパケ
   ット転送を行うことを可能とするように設定された、前
   記第１のノードからのパケットを受信可能な仮想的転送
   路と、前記第２のノードへのパケットを送信可能な仮想
   的転送路とが設定可能な場合に、これら仮想的転送路の
   対応関係を記憶すると共に、前記両仮想的転送路の有無
   に応じて資源予約のためのメッセージを前記第１のノー
   ドへ送信し、 パケットを受信した場合に、この受信に用いられた仮想
   的転送路についての前記対応関係が記憶されているなら
   ば、この対応関係に従って前記パケットを転送すること
   を特徴とするパケット転送方法。
9. 【請求項９】第１のノードから送信されるパケットを、
   前記第１のノードとは異なる論理ネットワークに属する
   第２のノードへ転送するパケット転送方法において、 資源予約のためのメッセージを前記第２のノードから受
   信し、 この受信を受けて、資源予約のためのメッセージを前記
   第１のノードへ送信し、 前記第１のノードから前記第２のノードへネットワーク
   レイヤレベルの転送処理の一部又は全部を行わずにパケ
   ット転送を行うことを可能とするように設定された、前
   記第１のノードからのパケットを受信可能な仮想的転送
   路と、前記第２のノードへのパケットを送信可能な仮想
   的転送路との少なくとも一方が存在しない場合に、送信
   した前記資源予約のためのメッセージの取り消しを前記
   第１のノードに通知し、 前記両仮想的転送路が存在する場合に、これら仮想的転
   送路の対応関係を記憶し、 パケットを受信した場合に、この受信に用いられた仮想
   的転送路についての前記対応関係が記憶されているなら
   ば、この対応関係に従って前記パケットを転送すること
   を特徴とするパケット転送方法。