JP2004015838A - 仮想的転送路形成方法 - Google Patents

Abstract

【課題】　ＩＰスケジューリングのみによっては要求された資源予約ができない場合にも、資源予約を可能とし、かつ、自ノードで資源予約が行えたか否かを正しく他のノードに伝える。
【解決手段】　下流から資源予約メッセージを受けたとき、これを受けたノードの上流及び下流に、ネットワークレイヤレベルの転送処理の一部又は全部を省略してパケットを転送するように使用できる仮想的転送路が存在し、これらの仮想的転送路の対応関係を記憶してこれに従ってパケット転送を行うことによりはじめて資源予約のためのメッセージに示される要求サービス品質を満たすことができる場合に、両仮想的転送路の存在を確認してから上流へ資源予約メッセージを送信する。
【選択図】　図３

Description

　本発明は、仮想コネクションネットワーク同士を接続することのできるルータ装置を介しマルチキャストのパケット転送を行うための仮想的転送路を形成する方法に関する。

　　ルータ装置は、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）　間を接続する際に用いられるもので、一方のＬＡＮ　から他方のＬＡＮ　にパケットを転送する役割を果たす。パケットには、転送すべき通信情報データに加えて、その送信元および最終宛先のネットワーク層アドレスが記載されており、ルータ装置では、そのアドレス情報を用いて、パケットの出力インタフェースおよび次の転送ノードを決定している。

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

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

　このようにルータ装置で資源予約をするためには、ルータ装置間で資源予約の情報をやり取りする必要があり、そのプロトコルとして、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ　ＲｅＳｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）　が開発されている。このプロトコルは、ユニキャストとマルチキャストの両方に対応している。

　ＲＳＶＰでは、データを受信している下流側のノードから情報の発信元である上流ノードへ資源予約を行う。具体的には、情報の発信元からデータの宛先と同じ宛先に向かってＰＡＴＨメッセージを送出し、情報がどの経路を通っているかを経路上のルータに記憶させる。ＰＡＴＨメッセージには、資源予約すべきデータを特定する識別子と、ＰＡＴＨメッセージを送出するノードのＩＰアドレスが書かれている。　データの受信ノードは、ＰＡＴＨメッセージを受信すると、ＰＡＴＨメッセージを送信した上流ノードにＲＥＳＶメッセージを送出することで、資源予約の意思を表示する。ＲＥＳＶメッセージには、資源予約すべきデータを特定する識別子と、受信ノードが要求するＱＯＳ　（サービス品質）が書かれている。

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

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

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

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

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

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

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

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

　ここで、記憶された対応関係に従ってパケットを転送することは、ネットワークレイヤレベルの転送処理の一部又は全部を省略してパケットを転送することを意味する。少なくとも省略される処理は、パケットの宛先アドレスから、次に転送すべき先のノードを決定し、この決定されたノードへのパケット送信に用いる仮想的転送路を特定する処理（ネットワークレイヤレベルの解析）である。　また、ネットワークレイヤレベルの転送処理の一部又は全部を行わずにパケット転送を行うことを可能とするように設定された仮想的転送路は、異なる論理ネットワークに属するノード間でネットワークレイヤレベルの転送処理を行ってパケットを転送するように既に設定されている仮想的転送路とは別の仮想的転送路であることが望ましい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　（実施形態１）
　本実施形態では、ＣＳＲ（Ｃｅｌｌ　Ｓｗｉｔｃｈ　Ｒｏｕｔｅｒ）　の技術を用いて、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ　Ｔｒａｎｓｆｅｒ　Ｍｏｄｅ）　上で資源予約プロトコルであるＲＳＶＰ（ｒｅｓｏｕｒｃｅ　ＲｅＳｅＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）　　を実現するための方法を述べる。

　ＲＳＶＰは、送信元アドレス／ポートと宛先アドレス／ポートの組（宛先アドレス／ポートだけでもよい）等で識別するフローに属するパケット転送のＱＯＳ　（サービス品質）をルータで保証するものである。このフローを識別する識別子をここでは、Ｆｌｏｗ　ＩＤ　と呼ぶことにする。このＱＯＳ　保証は、ルータ内部でパケット転送のスケジューリングを行うことにより、資源を予約しているパケットについては、早めに転送を行うようにすることにより、実現される。

　ＣＳＲ　は、通常のルータと同じＩＰパケット単位で転送する動作を行う他に、ルータ内部にＡＴＭ　スイッチ機能を持つことにより、より高速なＡＴＭ　セル単位の転送を行うことができるルータである。

　図１　を使って、ＣＳＲ　の簡単な動作を説明する。Ｘ．１　からＣＳＲ　を通してＹ．１　にパケットを転送する場合を考える。通常と同じＩＰパケット転送の動作を行うためには、Ｘ．１　からＣＳＲ　に色々な宛先のパケットを転送するために設定されているＡＴＭ　コネクションでパケットを送信する。ここでは、このＡＴＭ　コネクションをデフォルトＶＣ（Ｖｉｒｔｕａｌ　Ｃｏｎｎｅｃｔｉｏｎ）と呼ぶ。ＣＳＲ　では、ＩＰパケットの宛先を見て次に配送するノードを決定する。ここでは、次のノードは、Ｙ．１　になるので、デフォルトＶＣにパケットを送出することによりＹ．１　へとパケットが転送される。

　次に、ＡＴＭ　セル転送の動作を説明する。Ｙ．１　へのパケット転送専用のＸ．１　からＣＳＲ　へのＡＴＭ　コネクションとＣＳＲ　からＹ．１　へのＡＴＭ　コネクションとが設定されているとする。ここでは、このＡＴＭ　コネクションを専用ＶＣと呼ぶ。さらに、これら２つの専用ＶＣをＣＳＲ　内のＡＴＭ　スイッチ機能でＡＴＭ　セル単位で転送できるように設定しておく。すなわち、Ｘ．１　からＣＳＲ　への専用ＶＣのＣＳ
Ｒ　の受信ポートでのＶＰＩ／ＶＣＩ　と、ＣＳＲ　からＹ．１　への専用ＶＣのＣＳＲ
　の送信ポートでのＶＰＩ／ＶＣＩ　との対応関係を、ＡＴＭ　レベルのルーティングテーブルとして記憶しておく。このような設定を行うことで、二つの論理ネットワーク（ＩＰ　Ｓｕｂｎｅｔ　）に属する専用ＶＣを直結するバイパスパイプが形成されたことになる。

　Ｘ．１　からＹ．１　へのパケット転送を行うには、Ｘ．１　からＹ．１　用の専用ＶＣにパケットを送信することにより、Ｘ．１　からＣＳＲ　に送られ、ＣＳＲ　でＡＴＭ
　レベルのルーティングテーブルを参照することによりＡＴＭ　セルのままＣＳＲ　からＹ．１　への専用ＶＣに転送されて、その専用ＶＣでＹ．１　へ送られる。

　なお、ここでは、専用ＶＣにて送信されるパケットをＡＴＭ　セル単位で転送することを、専用ＶＣの直結として説明したが、専用ＶＣにて送信されるパケットをＡＡＬ（ＡＴＭ　Ａｄａｐｔａｔｉｏｎ　Ｌａｙｅｒ）　フレーム単位で転送することで、専用ＶＣの直結としても良い。この場合も、上記のＡＴＭ　レベルのルーティングテーブルを参照することにより、ＡＡＬ　フレーム転送が行える。以上の場合はいずれも、ネットワークレイヤ（例えばＩＰ）レベルの解析処理を行わずに、パケットが転送されることになる。

　また、専用ＶＣにて送信されるパケットに対し、パケットの最終宛先アドレスから出力先とすべきＶＣを決定するネットワークレイヤレベルのルーティングテーブル参照処理は行わず、その他のネットワークレイヤレベルの処理（ＩＰの場合はＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）　を減らす処理やチェックサム計算等）は行って、次段ノードへの専用ＶＣに転送することを、上記専用ＶＣの直結としても良い。この場合も、上記のＡＴＭ　レベルのルーティングテーブルを参照することにより、出力先とすべきＶＣが決定でき、パケット転送が行える。この場合は、ネットワークレイヤレベルの処理を一部だけ行って、パケットが転送されることになる。

　本発明は、ＣＳＲ　の動作が以上に説明したいずれのものであっても、適用可能である。

　さて、ＲＳＶＰで資源予約を行う場合は、ルータ内でＩＰ転送のスケジューリングを行う必要があるが、ルータにＣＳＲ　を用いると、パケット転送をＡＴＭ　セル単位でＡＴＭ　スイッチ機能で転送できるので、パケット転送のスケジューリングをＡＴＭ　スイッチ機能で行うことができる。すなわち、資源を予約しているパケットについては、ＡＴＭ
　スイッチ機能（ＡＴＭ　セル転送、ＡＡＬ　フレーム転送、ＩＰ処理の一部を省略したパケット転送のいずれでも良い）を用いることにより高速に転送を行うことができる。以下では、ＲＳＶＰを用いた時の専用ＶＣの設定手順を述べる。

　　　（具体例１）
　本例では、ＡＴＭ　コネクションがＳＶＣ（Ｓｗｉｔｃｈｅｄ　Ｖｉｒｔｕａｌ　Ｃｏｎｎｅｃｔｉｏｎ）であり、ユニキャストを想定した場合について説明する。

　図２　の様なネットワークトポロジーを例にとり専用ＶＣの設定の手順を述べる。Ｈ１，Ｈ２　はホストを示し、Ｒ１，Ｒ２，Ｒ３はルータを示している。これらの全てのノード間にはデフォルトＶＣがあらかじめ設定されていると仮定する。

　以下の手順では、Ｒ１，Ｒ２，Ｒ３を取り出して、その間で行われる手順を説明する。Ｈ１とＲ１間やＲ３とＨ２間のようなホストとルータ間（ホストもルータもいずれもノードである）の手順も、仮想コネクション型ネットワークで接続されているならば、ルータ同士の手順と同じなので、ここでは、省略する。

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

　図３　のようにルータ１，２，３（Ｒ１，Ｒ２，Ｒ３）が存在している場合に、ルータ２　での資源予約の方法を述べる。初期状態として、ルータ１　からルータ２　へ、ルータ２　からルータ３　へのデフォルトＶＣとルータ２　からルータ３　への専用ＶＣが設定されている状況を考える。以下では、メッセージ交換の様子を示す図（図３　）と、下流側のルータ（図３　ではＲ２）内部の動作図（図４　、図５　）と、上流側のルータ（図３　ではＲ１）内部の動作図（図６　）を用いて説明する。

　はじめに、図３　のようにルータ３　からＲＳＶＰの予約（ＲＥＳＶ）メッセージがルータ２　に到着したとする。ＲＥＳＶメッセージには、どのパケットに対して予約すべきか示すためのＦｌｏｗ　ＩＤ　と予約したいＱＯＳ　が書かれている。Ｆｌｏｗ　ＩＤ　には、発信元ＩＰアドレス／ポート、宛先ＩＰアドレス／ポートの組、あるいは、ＩＰｖ６　　のＦｌｏｗ　ＩＤ　が書かれている。ＱＯＳ　には、帯域の情報や遅延の情報が書かれている。

　ＲＥＳＶメッセージを受信したルータ２は、図４　及び図５　のフローチャートに従い、ＲＳＶＰメッセージ中のＦｌｏｗ　ＩＤ　用の下流側の専用ＶＣがあるかチェックする（Ｓ１）。この例では、専用ＶＣが存在するので専用ＶＣ依頼メッセージを上流側のノード（Ｒ１）に送出する（Ｓ２）。このメッセージには、ＲＥＳＶメッセージの内容と同じＦｌｏｗ　ＩＤ　とＱＯＳ　の情報を持つ。もしくは、ＲＥＳＶのＱＯＳ　からＡＴＭ　レベルの品質を求めてこれをＱＯＳ　の情報として専用ＶＣ依頼メッセージに書き込んでも良い。

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

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

　専用ＶＣ依頼メッセージを受信したルータ１　は、図６　のフローチャートに従い、ＡＴＭ　シグナリングを用いて、専用ＶＣ依頼メッセージを送信したノード（ルータ２　）への、要求ＱＯＳ　を満たせるＡＴＭ　コネクション（専用ＶＣ）を設定する（Ｓ２１）。

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

　このメッセージには、送信者側（ルータ１　）が提案するＶＣＩＤと、ターゲットＩＰアドレス（ルータ２　のＩＰアドレス）とが入っている。ターゲットＩＰアドレスは、後述するように専用ＶＣをポイント−マルチポイント化することに対処するために、書き込まれる。

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

　ＶＣＩＤ交換が終了し、専用ＶＣが使用可能であることを下流側のノード（ルータ２　）に知らせるために、ルータ１　からルータ２　へ専用ＶＣ通知メッセージを送信する（Ｓ２３）。このメッセージは、デフォルトＶＣ（すなわちパケット送信に用いられる専用ＶＣとは異なるＶＣ）にて、送信する。このメッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤが含まれる。

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

　上流側のノード（ルータ１　）は、リダイレクトメッセージを受信すると、そのＦｌｏｗ　ＩＤ　を今までデフォルトＶＣで送出していて（Ｓ２４Ｙｅｓ　）、同じＦｌｏｗ　ＩＤ　を持つ上流側の専用ＶＣがない（Ｓ２６ない）ならば、ＩＰ処理部がそのＦｌｏｗ
　ＩＤ　に関わるパケットを専用ＶＣに流すようにする（Ｓ２５）。すなわち、さらに上流側のノード（Ｈ１）からデフォルトＶＣにて送信されてくるパケットをルータ２　への専用ＶＣに転送するよう、ＩＰ処理部で用いるルーティング情報を書き替える。

　なお、ルータ１　の上流に同じＦｌｏｗ　ＩＤ　を持つ専用ＶＣが存在する（Ｓ２６ある）場合は、その上流側の専用ＶＣとルータ２　への専用ＶＣを直結する（Ｓ２７）。

　専用ＶＣ通知メッセージを受信したノード（ルータ２　）は、下流側にＦｌｏｗ　ＩＤ
　用の専用ＶＣがない（Ｓ１３ない）場合には、上流側の専用ＶＣから受信したパケットをＩＰ処理部に渡すように設定する（Ｓ１６）。このステップは、直結せずに資源予約できるが、上流に専用ＶＣ依頼メッセージを送出し、それにより上流側に専用ＶＣが設定された場合に対応する。

　最後に、ルータ２　でＲＳＶＰのＱＯＳ　要求を満足することができるので、ルータ２
　からルータ１　へ、デフォルトＶＣでＲＥＳＶの送出を行う（Ｓ１７）。なお、Ｓ１５のリダイレクト及びＳ１７のＲＥＳＶの送信順序は逆でも構わない。

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

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

　具体例１−１で説明した手順では、専用ＶＣ依頼メッセージを送信し、ＡＴＭ　シグナリングを行った後、ＶＣＩＤ提案、ＶＣＩＤ　ＡＣＫ、専用ＶＣ通知と３つのメッセージを送信していたが、専用ＶＣ通知メッセージを新たに作ったＡＴＭ　コネクション（専用ＶＣ）に流すことで、ＶＣＩＤ提案メッセージとＶＣＩＤ　ＡＣＫを省略することが可能である。

　具体的なシーケンス図を図７　で示し、下流側のノードのフローチャートを図４　、図８　に、上流側のノードのフローチャートを図９　に示す。

　具体例１−１から変更した点を説明すると、図７　では、ＶＣＩＤ提案メッセージとＶＣＩＤ　ＡＣＫメッセージが無くなったことと、専用ＶＣ通知メッセージを新たに作ったＡＴＭ　コネクション（専用ＶＣ）で転送することが異なる。また、本例での専用ＶＣ通知メッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤの他に、具体例１−１ではＶＣＩＤ提案メッセージに含ませていたターゲットＩＰアドレスを含ませる。

　メッセージが２つ不要となったことに伴って、上流側のノード（図９　）は、ＶＣＩＤ
　ＡＣＫメッセージを受信したときの動作（Ｓ２３）が無くなり、新たに作ったＡＴＭ　コネクションに、ＶＣＩＤ提案ではなく、上述した専用ＶＣ通知を送信することになる（Ｓ３１）。下流側のノードは、ＲＥＳＶを受信したときの動作は図４　の通りであり、ＶＣＩＤ　ＡＣＫ提案を受信したときの動作（Ｓ１２）が無くなり、専用ＶＣ通知メッセージを受信したときは、図８　に示すように、このメッセージに含まれるターゲットＩＰアドレスが自分のアドレスであるか否かチェックした後、図５（ｂ）と同様の動作を行う。

　　　（具体例２）
　本例では、ＡＴＭ　コネクションがＶＰ（Ｖｉｒｔｕａｌ　Ｐａｔｈ）のコネクションであり、ユニキャストを想定した場合について説明する。

　図１０のようにルータ１，２，３（Ｒ１，Ｒ２，Ｒ３）が存在している場合に、ルータ２　での資源予約の方法を述べる。初期状態として、ルータ１　からルータ２　へ、ルータ２　からルータ３　へのデフォルトＶＣとルータ２　からルータ３　への専用ＶＣが設定されている状況を考える。以下では、メッセージ交換の様子を示す図（図１０）と下流側のルータ内部の動作図（図１１、図１２）と上流側のルータ内部の動作（図１３）を用いて説明する。

　はじめに、図１０のようにルータ３　からＲＳＶＰの予約（ＲＥＳＶ）メッセージがルータ２　に到着したとする。ＲＥＳＶメッセージには、どのパケットに対して予約すべきか示すためのＦｌｏｗ　ＩＤ　と予約したいＱＯＳ　が書かれている。

　ＲＥＳＶメッセージを受信したルータ２は、図１１のフローチャートに従い、ＲＳＶＰメッセージ中のＦｌｏｗ　ＩＤ　用の下流側の専用ＶＣがあるかチェックする（Ｓ４１）
。この例では、専用ＶＣが存在するので、上流側のルータからの（Ｒ１からＲ２への）未使用ＶＣのうち適当なものを選んでこれを専用ＶＣとして使用することを決定し（Ｓ４２）、この決定した上流の専用ＶＣと下流に存在する専用ＶＣとを直結（ＡＴＭ　レベルのルーティングテーブルに対応関係を記憶）し（Ｓ４３）、リダイレクトメッセージをデフォルトＶＣで上流側のノード（Ｒ１）に送出する（Ｓ４４）。

　このメッセージには、ＲＥＳＶメッセージの内容と同じＦｌｏｗ　ＩＤ　と、ＶＣＩＤの情報を持つ。ＶＣＩＤは、ＶＰ中の使用していないＶＣＩ　（上記のように選んだ専用ＶＣのＶＣＩ　）を使用し、ＶＰＩ／ＶＣＩ　の組をＶＣＩＤの値とする。もし、下流側に専用ＶＣが無い場合は、ＩＰ処理部で要求された資源を確保できるか判断し（Ｓ４５）、資源予約できる場合には、ＩＰ転送のスケジューリングを行うことにより資源予約して上流にＲＥＳＶメッセージを送出する（Ｓ４６）と共に、上流側のルータとの間の未使用ＶＣのうち適当なものを選んでこれを専用ＶＣとして使用することを決定し（Ｓ４７）、この専用ＶＣで受信したパケットをＩＰ処理部に渡すように設定し（Ｓ４８）、リダイレクトメッセージを上流に送出する（Ｓ４４）。資源予約できない場合には、ＲＥＳＶ　ＥＲＲＯＲを下流ノード（Ｒ３）に送出する（Ｓ４９）。

　リダイレクトメッセージを受信したルータ１は、図１３のフローチャートに従い、図６（ｃ）と同様にＦｌｏｗ　ＩＤ　に関するパケット転送をデフォルトＶＣを使う転送から専用ＶＣによる転送に切り替え、下流側のノードにデフォルトＶＣ（もしくは専用ＶＣ）で専用ＶＣ通知メッセージを送出する（Ｓ５１）。このメッセージには、　Ｆｌｏｗ　ＩＤ（とＶＣＩＤ）の情報が含まれる。

　下流側のノード（ルータ２）が専用ＶＣ通知メッセージを受信すると、図１２のフローチャートに従い動作する。すなわち、　ＶＣＩＤ　で特定される専用ＶＣは、Ｆｌｏｗ　ＩＤ　専用に使えることが分かり、ルータ２　でＲＳＶＰのＱＯＳ　要求を満足することができるので、ルータ２　からルータ１　へ、デフォルトＶＣでＲＥＳＶの送出を行う（Ｓ５２）。

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

　　　（具体例３）
　本例では、ＡＴＭ　コネクションがＳＶＣ　であり、マルチキャストを想定した場合について説明する。

　図１４のようにルータ１，２，３，４（Ｒ１，Ｒ２，Ｒ３，Ｒ４）　が存在している場合に、ルータ４　での資源予約の方法を述べる。ホストＨ２，Ｈ３　がマルチキャストグループＧ　に参加しているため、ルータ２　からルータ３　とルータ４へ、ポイント−マルチポイント（　以下ｐ−ｍｐと言う）　のデフォルトＶＣが設定されている。また、上流のルータから下流のルータへデータパケット等を流すために設定されているデフォルトＶＣはマルチキャスト用（ｐ−ｍｐとなり得るもの）であり、このマルチキャスト用デフォルトＶＣとは別に、下流から上流に制御パケット等を流すためにポイント−ポイント（
　以下ｐ−ｐ　と言う）　のデフォルトＶＣが、必要に応じて設定される。

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

　初期状態として、図１５のように、ルータ２　からルータ３　とルータ４へ、マルチキャスト用のデフォルトＶＣ（ｐ−ｍｐとなり得る（　ここでは既になっている）ＶＣ　）が設定され、ルータ２　からルータ３　へのｐ−ｍｐとなり得る（ここではまだなっていない）専用ＶＣが設定され、ホスト３　とルータ４　間に（ｐ−ｐ　の）デフォルトＶＣが設定されている状況を考える。ルータ２　からルータ３　への専用ＶＣは、マルチキャストグループＧ　の専用ＶＣとする。

　ここで、ルータ１　からルータ２　への専用ＶＣや、ルータ２　からルータ３　への専用ＶＣは、具体例１−１で説明した手順により設定されたものである。但し、具体例１−１で説明したＲＥＳＶ、ＶＣＩＤ　ＡＣＫ、専用ＶＣ通知、リダイレクトの各メッセージは、ｐ−ｐ　のデフォルトＶＣを用いて送信される。

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

　はじめに、図１５のようにホスト３　からデフォルトＶＣで、ＲＳＶＰの予約（ＲＥＳＶ）メッセージがルータ４に到着したとする。なお、これはマルチキャスト用のデフォルトＶＣを用いて上流から下流へ転送されたＲＳＶＰのＰａｔｈメッセージに応答してホスト３　が送信したものである。

　ＲＥＳＶメッセージには、どのパケットに対して予約すべきか示すためのＦｌｏｗ　ＩＤ　と予約したいＱＯＳ　が書かれている。Ｆｌｏｗ　ＩＤ　には、発信元ＩＰアドレス／ポート、宛先ＩＰアドレス／ポートの組、あるいは、ＩＰｖ６　　のＦｌｏｗ　ＩＤ　が書かれている。ＱＯＳ　には、帯域の情報や遅延の情報が書かれている。

　ＲＥＳＶメッセージを受信したルータ４は、図４　及び図５　のフローチャートに従い、ＲＳＶＰメッセージ中のＦｌｏｗ　ＩＤ　用の下流側の専用ＶＣがあるかチェックする（Ｓ１）。この例では、下流側に専用ＶＣが無いので、ＩＰ処理部で要求された資源を確保できるか判断し（Ｓ３）、資源予約できる場合には専用ＶＣ依頼メッセージを上流に送出し（Ｓ２）、資源予約できない場合には、ＲＥＳＶ　ＥＲＲＯＲを下流ノードに送出する（Ｓ４）。ここでは、資源予約が出来たとして話を進める。

　専用ＶＣ依頼メッセージを受信したルータ２は、図６　のフローチャートに従い、ＡＴＭ　シグナリングを用いて、専用ＶＣ依頼メッセージを送信したノード（ルータ２　）への、要求ＱＯＳ　を満たせるＡＴＭ　コネクション（専用ＶＣ）を設定する（Ｓ２１）。この場合のシグナリングは、ＡＤＤ　ＰＡＲＴＹ　であり、ルータ２からルータ３への専用ＶＣが経由するスイッチのいずれかから分岐してルータ４に達する新たなリンクを既に存在する専用ＶＣに追加することになる。

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

　このＶＣＩＤ提案メッセージを受信したノード（ルータ３、ルータ４　）は、このメッ
セージに含まれるターゲットＩＰアドレスが自ノードのＩＰアドレスであるか否か
を調べ（Ｓ１１）、そうである場合は、このＶＣＩＤを許容するならば、ＶＣＩＤ　ＡＣＫをｐ−ｐ　のデフォルトＶＣで上流ノード（ルータ２）に送信する（Ｓ１２）。ＶＣＩＤ　ＡＣＫは、少なくとも送信者側が提案し自ノードが許容したＶＣＩＤが入っている。この手続きにより、ＶＣＩＤの交換が終了する。ここでは、ルータ４がターゲットであるので、ルータ４　のみＶＣＩＤ　ＡＣＫを上流ノードに送信する。

　ＶＣＩＤ交換が終了し、専用ＶＣが使用可能であることを下流側のノード（ルータ４）に知らせるために、ルータ２　　からルータ４　　へ専用ＶＣ通知メッセージを送信する（Ｓ２３）。このメッセージは、ｐ−ｐ　のデフォルトＶＣ（すなわちパケット送信に用いられる専用ＶＣとは異なるＶＣ）にて、送信する。このメッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤが含まれる。

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

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

　こうして専用ＶＣが使用可能になると、上流側にリダイレクトメッセージを送出する（Ｓ１５）。リダイレクトメッセージは、Ｆｌｏｗ　ＩＤ　とＶＣＩＤを含み、ｐ−ｐ　のデフォルトＶＣにより送信される。

　上流側のノード（ルータ２）は、リダイレクトメッセージを受信すると、そのＦｌｏｗ
　ＩＤ　は今まで専用ＶＣで送出していたので（Ｓ２４Ｎｏ）、何もしない。

　なお、マルチキャストの場合の上流側のノードの動作のうち、図６（ｃ）のＳ２５は、今までマルチキャスト用デフォルトＶＣに流していたそのＦｌｏｗ　ＩＤ　に関わるパケットを専用ＶＣに流すようにしたとき、マルチキャストデフォルトＶＣにも同じパケットを流し続けるようにする。これは、マルチキャストの場合は受信者毎に異なるＱＯＳ　を要求する可能性があり、専用ＶＣを設定せずマルチキャスト用デフォルトＶＣにてパケットを受け取っているノードが存在するかもしれないことに対処するためである。

　最後に、ルータ４でＲＳＶＰのＱＯＳ　要求を満足することができるので、ルータ４からルータ２へ、ｐ−ｐ　のデフォルトＶＣでＲＥＳＶの送出を行う（Ｓ１７）。なお、Ｓ１５及びＳ１７の順序は逆でも構わない。

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

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

　初期状態として、図１５と同様な状況を考える。ここで、ルータ１　からルータ２　への専用ＶＣや、ルータ２　からルータ３　への専用ＶＣは、具体例１−２で説明した手順により設定されたものである。但し、具体例１−２で説明したＲＥＳＶ、リダイレクトの各メッセージは、ｐ−ｐ　のデフォルトＶＣを用いて送信される。

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

　具体例３−１から変更した点を説明すると、図１６では、ＶＣＩＤ提案メッセージとＶＣＩＤ　ＡＣＫメッセージが無くなったことと、専用ＶＣ通知メッセージを新たにリーフを追加したＡＴＭ　コネクション（専用ＶＣ）で転送することが異なる。また、本例での専用ＶＣ通知メッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤの他に、具体例３−１ではＶＣＩＤ提案メッセージに含ませていたターゲットＩＰアドレスを含ませる。これにより、ルータ４　への専用ＶＣ通知を受け取ってしまうルータ３　は、これを無視することができる。

　メッセージが２つ不要となったことに伴って、上流側のノード（図９　）は、ＶＣＩＤ
　ＡＣＫメッセージを受信したときの動作（Ｓ２３）が無くなり、新たにリーフを追加したＡＴＭ　コネクションに、ＶＣＩＤ提案ではなく、上述した専用ＶＣ通知を送信することになる（Ｓ３１）。下流側のノードは、ＲＥＳＶを受信したときの動作は図４　の通りであり、、ＶＣＩＤ　ＡＣＫ提案を受信したときの動作（Ｓ１２）が無くなり、専用ＶＣ通知メッセージを受信したときは、図８　に示すように、このメッセージに含まれるターゲットＩＰアドレスが自分のアドレスであるか否かチェックした後、図５（ｂ）と同様の動作を行う。

　以上の説明では、ＲＳＶＰをきっかけとしてＣＳＲ　の技術を生かした資源予約を行う方法を述べたが、上述したようにＲＳＶＰのＲＥＳＶメッセージをトリガとして専用ＶＣを設定するのではなく、データパケットをトリガとして専用ＶＣを設定することも、同様にして実現できる。

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

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

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

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

　そして、ルータ２からルータ３への専用ＶＣにルータ４へのリーフが追加されたことを専用ＶＣ通知メッセージにより知ると、そのパケットに関係あるＦｌｏｗ　ＩＤ　を持つ下流側の専用ＶＣがあるならば、直結し、なければ、ルータ１から専用ＶＣで転送されてきたパケットをホスト３へのデフォルトＶＣで転送するようにする。なお、ルータ１は、ルータ３、４からそれぞれのｐ−ｐ　デフォルトＶＣにてリダイレクトメッセージが定期的に送信されてくる間は、ｐ−ｍｐ専用ＶＣのそれぞれに対応するリーフを維持する（リダイレクトメッセージが送信されてこなくなったルータへのリーフは削除する）。

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

　　（実施形態２）
　本実施形態では、ＣＳＲ　の技術を用いて、ＡＴＭ　上で資源予約プロトコルであるＲＳＶＰを実現するための、別の方法を述べる。

　実施形態１では、ＲＳＶＰのＲＥＳＶメッセージが到着したノードから上流側に専用ＶＣを設定する手順を説明したが、ここでは、ＲＥＳＶメッセージが到着したときに下流側に専用ＶＣを設定する手順を説明する。

　　　（具体例１）
　本例では、ＡＴＭ　コネクションがＳＶＣ（Ｓｗｉｔｃｈｅｄ　Ｖｉｒｔｕａｌ　Ｃｏｎｎｅｃｔｉｏｎ）であり、ユニキャストを想定した場合について説明する。

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

　図１７のようにルータ１，２，３（Ｒ１，Ｒ２，Ｒ３）が存在している場合に、ルータ２　での資源予約の方法を述べる。初期状態として、ルータ１　からルータ２　へ、ルータ２　からルータ３　へのデフォルトＶＣが設定されている状況を考える。以下では、メッセージ交換の様子を示す図（図１７）と、下流側のルータ（図１７ではＲ２）内部の動作図（図２２、図２３）と、上流側のルータ（図１７ではＲ１）内部の動作図（図１８、図１９、図２０、図２１）を用いて説明する。

　はじめに、図１７のようにルータ３からＲＳＶＰのＲＥＳＶメッセージがルータ２に到着したとする。ＲＥＳＶメッセージには、Ｆｌｏｗ　ＩＤ　と予約したいＱＯＳ　が書かれている。

　ルータ２　は、ＲＥＳＶメッセージに書かれた予約したいＱＯＳ　を実現する資源予約がＩＰスケジューラで行えるか否かを判断し（Ｓ６１）、できる場合には、ＩＰスケジューラで資源予約する（Ｓ６２）と共に、ＲＥＳＶメッセージをデフォルトＶＣで上流側に（ルータ１　へ）転送する（Ｓ６３）。できない場合にも、ルータ２　では今は資源予約ができていないが、後で上流側と下流側の両方に専用ＶＣが設定されて直結を行うことにより資源予約ができることを見越して、ＲＥＳＶメッセージを上流側に送出する（Ｓ６３）。

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

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

　ＲＥＳＶメッセージを受信したルータ２の動作手順は、図１８に示すように、ＲＥＳＶメッセージを上流に送信した（Ｓ６３）後、ＡＴＭ　シグナリングでＡＴＭ　コネクション（専用ＶＣ）を次段ノード（ルータ３　）へ設定した後、ＶＣＩＤ提案メッセージをこの専用ＶＣにて送信する（Ｓ６５）。

　ＶＣＩＤ提案メッセージを受信した下流ノード（ルータ３）は、図２２にしたがって、ターゲットＩＰが自分のアドレスかチェックして（Ｓ７１）、自分のアドレスの場合は、ＶＣＩＤ　ＡＣＫをデフォルトＶＣにて送信する（Ｓ７２）。

　ＶＣＩＤ　ＡＣＫを受信した上流ノード（ルータ２）は、図１９にしたがって、下流側に専用ＶＣ通知をデフォルトＶＣにて送信する（Ｓ６６）。

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

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

　デフォルト転送を行っている場合は、同じＦｌｏｗ　ＩＤ　を持つ上流側の（ルータ１
　からの）専用ＶＣがあるかチェックして（Ｓ８２）、専用ＶＣがある場合は、上流側の
専用ＶＣと下流側の（ルータ３　への）専用ＶＣを直結する（Ｓ８３）。専用ＶＣが無い場合は、ＩＰ処理部で今までデフォルトＶＣにて転送していたパケットを専用ＶＣにて転送するようにする（Ｓ８４）。

　このＦｌｏｗ　ＩＤ　に関して、自ノードが受信したパケットを転送するのではなく、自ノードが送信ノードである場合は（Ｓ８５Ｙｅｓ　）、ここで終了する。

　それ以外の場合は、一定時間待ち（Ｓ８６）、上流側に下流側と同じＦｌｏｗ　ＩＤ　を持つ専用ＶＣが設定されず、上流側の専用ＶＣと下流側の専用ＶＣが直結しなかったら（Ｓ８７Ｎｏ）、ＩＰスケジューラでの資源予約（Ｓ６２）を行っていたかを調べ（Ｓ８８）、行っていればそのままとし、行っていなければ、上流側（ルータ１　）に、Ｓ６３にて送信したＲＥＳＶメッセージを取り消すための、ＲＥＳＶ　Ｔｅａｒ　メッセージを送信し、下流側（ルータ３　）に、資源予約に失敗したことを示すＲＥＳＶ　Ｅｒｒメッセージを送信する。なお、Ｓ８８で改めてＩＰスケジューラの資源予約ができるかを調べ直しても構わない。

　また、一定時間内に、上流側に下流側と同じＦｌｏｗ　ＩＤ　を持つ専用ＶＣが設定され、上流側の専用ＶＣと下流側の専用ＶＣが直結されれば（Ｓ８７Ｙｅｓ　）、ＩＰスケジューラでの資源予約（Ｓ６２）を行っていたかを調べ（Ｓ９０）、行っていなければそのままとし、行っていれば、この資源予約は専用ＶＣの直結により不要となっているから、取り消す（Ｓ９１）。

　なお、上記の説明では、先にＩＰスケジューラの資源予約を行ってから、専用ＶＣが直結できたらこれを取り消すこととしたが、専用ＶＣの直結ができる可能性が高い場合には、ＩＰスケジューラの資源予約は行わずに下流側に専用ＶＣを設定し、上流側に専用ＶＣができるのを待ってできたら直結し、直結ができないことを確認した時点（Ｓ８７Ｎｏ）でＩＰスケジューラの資源予約を試み、資源予約できればそのままとし、できなければ上流にＲＥＳＶ　Ｔｅａｒ　を、下流にＲＥＳＶ　Ｅｒｒを返すこととしても構わない。

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

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

　具体例１−１で説明した手順では、ＡＴＭ　シグナリングを行った後、ＶＣＩＤ提案、ＶＣＩＤ　ＡＣＫ、専用ＶＣ通知と３つのメッセージを送信していたが、専用ＶＣ通知メッセージを新たに作ったＡＴＭ　コネクション（専用ＶＣ）に流すことで、ＶＣＩＤ提案メッセージとＶＣＩＤ　ＡＣＫを省略することが可能である。

　具体的なシーケンス図を図２４で示し、下流側のノードのフローチャートを図２０、２１、２５に、上流側のノードのフローチャートを図２６に示す。

　具体例１−１から変更した点を説明すると、図２４では、ＶＣＩＤ提案メッセージとＶＣＩＤ　ＡＣＫメッセージが無くなったことと、専用ＶＣ通知メッセージを新たに作ったＡＴＭ　コネクション（専用ＶＣ）で転送することが異なる。また、本例での専用ＶＣ通
知メッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤの他に、具体例１−１ではＶＣＩＤ提案メッセージに含ませていたターゲットＩＰアドレスを含ませる。

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

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

　　　（具体例２）
　本例では、ＡＴＭ　コネクションがＶＰ（Ｖｉｒｔｕａｌ　Ｐａｔｈ）のコネクションであり、ユニキャストを想定した場合について説明する。

　図２７のようにルータ１，２，３（Ｒ１，Ｒ２，Ｒ３）が存在している場合に、ルータ２　での資源予約の方法を述べる。初期状態として、ルータ１　からルータ２　へ、ルータ２　からルータ３　へのデフォルトＶＣが設定されている状況を考える。以下では、メッセージ交換の様子を示す図（図２７）と下流側のルータ内部の動作図（図２３）と上流側のルータ内部の動作（図２０、２１、２８）を用い、具体例１から変更した点を説明する。

　図１７では、予約（ＲＥＳＶ）メッセージを受信すると、ＡＴＭ　シグナリング、ＶＣＩＤ提案、ＶＣＩＤ　ＡＣＫを行っていたが、ＶＰの場合は、予めＡＴＭ　コネクションがあり、ＶＣＩＤとしてＶＰＩ／ＶＣＩ　を利用することが出来るので、これらのメッセージが図２７では無い。

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

　　　（具体例３）
　本例では、ＡＴＭ　コネクションがＳＶＣ　であり、マルチキャストを想定した場合について説明する。

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

　初期状態として、図２９のように、ルータ２　からルータ３　とルータ４へ、マルチキャスト用のデフォルトＶＣ（ｐ−ｍｐとなり得る（　ここでは既になっている）ＶＣ　）が設定され、ルータ２からルータ３へのｐ−ｍｐとなり得る（ここではまだなっていない）専用ＶＣが設定され、ルータ１とルータ２間に（ｐ−ｐ　の）デフォルトＶＣが設定されている状況を考える。ルータ２　からルータ３　への専用ＶＣは、マルチキャストグループＧ　の専用ＶＣとする。

　ここで、ルータ１から２への専用ＶＣや、ルータ２から３への専用ＶＣは、具体例１−
１で説明した手順により設定されたものである。但し、具体例１−１で説明したＲＥＳＶ、ＶＣＩＤ　ＡＣＫ、専用ＶＣ通知、リダイレクトの各メッセージは、ｐ−ｐ　のデフォルトＶＣを用いて送信される。

　以下では、メッセージ交換の様子を示す図（図２９）と、下流側のルータ（図２９ではＲ４）内部の動作図（図２２、図２３）と、上流側のルータ（図２９ではＲ２）内部の動作図（図１８、１９、２０、２１）を用いて、ルータ２がマルチキャストグループＧ　のパケットのための資源予約を行う手順を述べる。　はじめに、図２９のようにルータ４からデフォルトＶＣで、ＲＳＶＰの予約（ＲＥＳＶ）メッセージがルータ２に到着したとする。なお、これはマルチキャスト用のデフォルトＶＣを用いて上流から下流へ転送されたＲＳＶＰのＰａｔｈメッセージに応答してルータ４が送信したものである。

　ＲＥＳＶメッセージには、どのパケットに対して予約すべきか示すためのＦｌｏｗ　ＩＤ　と予約したいＱＯＳ　が書かれている。

　ＲＥＳＶメッセージを受信したルータ２は、図１８のフローチャートに従い、ＩＰスケジューラで資源予約出来るかチェックする（Ｓ　６１）。資源予約出来る場合は、資源予約した後（Ｓ　６２）、予約（ＲＥＳＶ）メッセージを上流に送信する（Ｓ　６３）。資源予約出来なかった場合は、資源予約をせずに、予約メッセージを上流に送信する（Ｓ　６３）。

　次にＡＴＭ　シグナリングでＡＴＭ　コネクションを下流ノードに設定した後（Ｓ６４）、ＶＣＩＤ提案メッセージを設定したＡＴＭ　コネクションで送信する（Ｓ　６５）。このＶＣＩＤ提案メッセージには、ターゲットＩＰアドレスと　ＶＣＩＤ　が書かれている。ここで、ターゲットＩＰアドレスは、ルータ４　のアドレスが入っている。

　ＶＣＩＤ提案メッセージは、ルータ３とルータ４が受信する。これを受信したノードは、図２２のフローチャートに従い、ターゲットＩＰアドレスが自分のアドレスかチェックする。ＶＣＩＤ提案メッセージのターゲットＩＰアドレスは、ルータ４　になっており、ルータ３　では、自分のＩＰアドレスと異なる（Ｓ　７１Ｎｏ）ので、何もせずに終了する。ルータ４では、自分のＩＰアドレスを同じなので（Ｓ　７１ｙｅｓ）、ＶＣＩＤ　ＡＣＫを上流に送信する（Ｓ　７２）。

　ＶＣＩＤ交換が終了し、専用ＶＣが使用可能であることを下流側のノード（ルータ４）に知らせるために、ルータ２からルータ４へ専用ＶＣ通知メッセージを送信する（図１９のＳ　６６）。このメッセージは、ｐ−ｐ　のデフォルトＶＣにて、送信する。このメッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤが含まれる。

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

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

　こうして専用ＶＣが使用可能になると、上流側にリダイレクトメッセージを送出する（Ｓ７６）。リダイレクトメッセージは、Ｆｌｏｗ　ＩＤ　とＶＣＩＤを含み、ｐ−ｐ　のデフォルトＶＣにより送信される。

　上流側のノード（ルータ２）は、リダイレクトメッセージを受信すると、そのＦｌｏｗ
　ＩＤ　は今まで専用ＶＣで送出していたので（Ｓ８１Ｎｏ）、何もしない。

　なお、マルチキャストの場合の上流側のノードの動作のうち、図２０のＳ８４は、今までマルチキャスト用デフォルトＶＣに流していたそのＦｌｏｗ　ＩＤ　に関わるパケットを専用ＶＣに流すようにしたとき、マルチキャストデフォルトＶＣにも同じパケットを流し続けるようにする。これは、マルチキャストの場合は受信者毎に異なるＱＯＳ　を要求する可能性があり、専用ＶＣを設定せずマルチキャスト用デフォルトＶＣにてパケットを受け取っているノードが存在するかもしれないことに対処するためである。

　Ｓ　８４を終了したあとの処理は、具体例１ー１と同様である。

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

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

　初期状態として、図３０のように、ルータ２　からルータ３　とルータ４へ、マルチキャスト用のデフォルトＶＣ（ｐ−ｍｐとなり得る（　ここでは既になっている）ＶＣ　）が設定され、ルータ２からルータ３へのｐ−ｍｐとなり得る（ここではまだなっていない）専用ＶＣが設定され、ルータ１とルータ２間に（ｐ−ｐ　の）デフォルトＶＣが設定されている状況を考える。ルータ２　からルータ３　への専用ＶＣは、マルチキャストグループＧ　の専用ＶＣとする。

　具体例３−１で説明した手順では、ＡＴＭ　シグナリングを行った後、ＶＣＩＤ提案、ＶＣＩＤ　ＡＣＫ、専用ＶＣ通知と３つのメッセージを送信していたが、専用ＶＣ通知メッセージを新たに作ったＡＴＭ　コネクション（専用ＶＣ）に流すことで、ＶＣＩＤ提案メッセージとＶＣＩＤ　ＡＣＫを省略することが可能である。

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

　具体例３ー１から変更した点を説明すると、ＶＣＩＤ提案メッセージを送出する代わりに、専用ＶＣ通知メッセージを新たに作ったＡＴＭ　コネクション（専用ＶＣ）で転送することが異なる。また、本例での専用ＶＣ通知メッセージには、Ｆｌｏｗ　ＩＤ　とＶＣＩＤの他に、具体例１−１ではＶＣＩＤ提案メッセージに含ませていたターゲットＩＰアドレスを含ませる。

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

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

　以上の説明では、ＲＳＶＰをきっかけとしてＣＳＲ　の技術を生かした資源予約を行う方法を述べたが、上述したようにＲＳＶＰのＲＥＳＶメッセージをトリガとして専用ＶＣを設定するのではなく、データパケットをトリガとして専用ＶＣを設定することも、同様にして実現できる。

　上述したＲＳＶＰをきっかけとする場合と異なる点は、以下の２つである。一つは、ＲＳＶＰ有りの場合は、ＲＥＳＶメッセージを受信するとＡＴＭ　シグナリングを行い下流に専用ＶＣを設定したが、ＲＳＶＰが無い場合は、データパケットが来たときに、これを行う点である。その後、設定した専用ＶＣをデータパケット転送のために使用可能とする（直結するかもしくはＩＰ処理をして転送するようにする）動作を行うことは同様である。もう一つの違いは、ＲＥＳＶメッセージ、ＲＥＳＶ　Ｔｅａｒ　を上流に送信しないことである。

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

　そして、ルータ２　は、ルータ３　がこの専用ＶＣを使用可能になったことをリダイレクトメッセージにより知ると、そのパケットに関係あるＦｌｏｗ　ＩＤ　を持つ上流側の（ルータ１　からの）専用ＶＣがあるならば、直結し、なければ、ルータ１からデフォルトＶＣで転送されてきたパケットをルータ３への専用ＶＣで転送するようにする。

　また、例えば図１４のルータ２が、ＩＰマルチキャスト用のプロトコル（例えばＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ））により、ルータ４　がマルチキャストグループＧ　に参加したことを認識すると、それに関係するＦｌｏｗ　ＩＤ　（この場合のアドレスはマルチキャストアドレス）を持つ専用ＶＣを下流側に設定するよう、ＡＤＤ　ＰＡＲＴＹ　を行う。そして、ルータ２からルータ３への専用ＶＣにルータ４へのリーフが追加される。なお、ルータ２　は、ルータ３、４からそれぞれのｐ−ｐ　デフォルトＶＣにてリダイレクトメッセージが定期的に送信されてくる間は、ｐ−ｍｐ専用ＶＣのそれぞれに対応するリーフを維持する（リダイレクトメッセージが送信されてこなくなったルータへのリーフは削除する）。

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

　なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示され
ている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

ＣＳＲ　の動作を説明するための図。 ユニキャストの場合のネットワークトポロジーの例を示す図。 実施形態１の具体例１−１のメッセージ交換の様子を示す図。 実施形態１の下流側のノードの動作例を示す図。 実施形態１の下流側のノードの動作例を示す図。 実施形態１の上流側のノードの動作例を示す図。 実施形態１の具体例１−２のメッセージ交換の様子を示す図。 実施形態１の下流側のノードの別の動作例を示す図。 実施形態１の上流側のノードの別の動作例を示す図。 実施形態１の具体例２のメッセージ交換の様子を示す図。 実施形態１の下流側のノードの更に別の動作例を示す図。 実施形態１の下流側のノードの更に別の動作例を示す図。 実施形態１の上流側のノードの更に別の動作例を示す図。 マルチキャストの場合のネットワークトポロジーの例を示す図。 実施形態１の具体例３−１のメッセージ交換の様子を示す図。 実施形態１の具体例３−２のメッセージ交換の様子を示す図。 実施形態２の具体例１−１のメッセージ交換の様子を示す図。 実施形態２の上流側のノードの動作例を示す図。 実施形態２の上流側のノードの動作例を示す図。 実施形態２の上流側のノードの動作例を示す図。 実施形態２の上流側のノードの動作例を示す図。 実施形態２の下流側のノードの動作例を示す図。 実施形態２の下流側のノードの動作例を示す図。 実施形態２の具体例１−２のメッセージ交換の様子を示す図。 実施形態２の上流側のノードの別の動作例を示す図。 実施形態２の下流側のノードの別の動作例を示す図。 実施形態２の具体例２のメッセージ交換の様子を示す図。 実施形態２の上流側のノードの更に別の動作例を示す図。 実施形態２の具体例３−１のメッセージ交換の様子を示す図。 実施形態２の具体例３−２のメッセージ交換の様子を示す図。

Claims (6)

1. 　第１のノードから送信されるパケットを、前記第１のノードとは異なる論理ネットワークに属する複数の第２のノードへ、ルータ装置を介して転送するための仮想的転送路を形成する方法において、
   　前記第１のノードから前記ルータ装置への、及び、前記ルータ装置から前記第２のノードへの、ポイント−マルチポイントとなり得る通常コネクションを設定し、
   　前記ルータ装置は、前記第１のノードとの間に設定された前記通常コネクション上に送信されたパケットを、ネットワークレイヤレベルの解析を行って、前記第２のノードとの間に設定された前記通常コネクション上に転送し、
   　前記第１のノードから前記ルータ装置への、及び、前記ルータ装置から前記複数の第２のノードのうち所定の条件を満たすものへの、ポイント−マルチポイントとなり得る専用コネクションを設定し、
   　前記ルータ装置は、前記第１のノードとの間に設定された前記専用コネクション上に送信されたパケットを、ネットワークレイヤレベルの解析を行わずに、前記第２のノードとの間に設定された前記専用コネクション上に転送し、
   　前記専用コネクションの設定される前記第１のノードと前記ルータ装置間、及び、前記専用コネクションの設定される前記ルータ装置と前記第２のノード間に、ポイント−ポイントの通常コネクションを設定し、
   　この通常コネクションを用いて、前記専用コネクションの保持を行うことを特徴とする仮想的転送路形成方法。
2. 　前記複数の第２のノードのうち所定の条件を満たすものは、資源予約のためのメッセージを前記ルータ装置に送信したもののうち少なくとも前記メッセージに示される要求サービス品質を満たすために前記専用コネクションが必要であると判断されるものであり、
   　前記資源予約のためのメッセージを、前記ポイント−ポイントの通常コネクションを用いて前記第１のノード側のノードへ送信するものである請求項１記載の仮想的転送路形成方法。
3. 　前記専用コネクションの設定を、前記第２のノード側のノードから、前記ポイント−ポイントの通常コネクションを用いて要求するものである請求項１又は２記載の仮想的転送路形成方法。
4. 　前記第１のノード側のノードから前記専用コネクションを設定し、この設定を行った旨を前記ポイント−ポイントの通常コネクションを用いて前記第２のノード側のノードへ通知するものである請求項１又は２記載の仮想的転送路形成方法。
5. 　前記専用コネクションが前記第１のノードとの間に未だ設定されていない新たなノード、もしくは、前記専用コネクションが前記ルータ装置との間に未だ設定されていない前記第２のノードにつき、専用コネクションを設定する動作を、既に設定されている専用コネクションに新たなリンクを付加することにより行うものである請求項１乃至４記載の仮想的転送路形成方法。
6. 　第１のノードから送信されるパケットを、前記第１のノードとは異なる論理ネットワークに属する複数の第２のノードへ、ルータ装置を介して転送するための仮想的転送路を形成する方法において、
   　前記ルータ装置から前記複数の第２のノードへの、ポイント−マルチポイントとなり得る専用コネクションを設定し、
   　前記ルータ装置と前記第２のノードそれぞれとの間に、ポイント−ポイントの通常コネクションを設定し、
   　前記専用コネクションを表す前記論理ネットワーク内でユニークな識別情報を、前記ルータ装置から前記専用コネクションを用いて送信し、
   　前記第２のノードから前記通常コネクションを用いて、前記識別情報を確認するメッセージを送信することを特徴とする仮想的転送路形成方法。

Images