JP6303750B2 - 中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステム - Google Patents
中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステム Download PDFInfo
- Publication number
- JP6303750B2 JP6303750B2 JP2014083347A JP2014083347A JP6303750B2 JP 6303750 B2 JP6303750 B2 JP 6303750B2 JP 2014083347 A JP2014083347 A JP 2014083347A JP 2014083347 A JP2014083347 A JP 2014083347A JP 6303750 B2 JP6303750 B2 JP 6303750B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- bandwidth
- message
- path
- route
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
本開示は、中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステムに関する。
エンド-トゥ-エンド（End-to-End）のＱｏＳ（Quality of Service：サービス品質）を保証するために、ＩＥＴＦ（Internet Engineering Task Force）では、ＲＳＶＰ(Resource reSerVation Protocol：リソース予約プロトコル)と呼ばれる帯域予約プロトコルが提案されている。
ＲＳＶＰを用いた送受信間の帯域予約手順は次の通りである。図３４に示すように、送信元（ソース）ノード（ＳＮ）がＰａｔｈメッセージを送信先（宛先）ノード（ＤＮ）へ向けて送信する。Ｐａｔｈメッセージは、送信元ノードと送信先ノードとの間にある中継ノードａ，中継ノードｂ，中継ノードｃ及び中継ノードｄを経由する。最終的にＰａｔｈメッセージは送信先ノードに到達する。
送信先ノードは、Ｐａｔｈメッセージを受信後、送信元ノードに対してＲｅｓｖメッセージを送信する。Ｒｅｓｖメッセージは、Ｐａｔｈメッセージが通った経路（ａ→ｂ→ｃ→ｄ）を逆方向に辿る。Ｒｅｓｖメッセージが１ホップ移動するごとに、各中継ノードで帯域予約が行われる（図３５参照）。Ｒｅｓｖメッセージが送信元ノードに到達すると、最終的に送信元ノード（送信ノード）と送信先ノード（受信ノード）との間でＱｏＳを保障するための帯域（所望の帯域）が予約される（図３６参照）。
各中継ノードａ〜ｄは、Ｒｅｓｖメッセージを受信すると、送信先ノードと送信元ノードとの間の経路（パス）に関して帯域の予約を試行する。このとき、帯域が予約できない場合には、中継ノードは、送信先ノードにエラーメッセージを送信する。この場合、送信元ノードと送信先ノードとの間での帯域予約は失敗となる。
また、Ｒｅｓｖメッセージを受信した中継ノードがパス上の或るリンク（区間）について所望の帯域を予約できないときには、エラーメッセージを送信する代わりに、所望の帯域を確保可能な空き帯域が生じるまでＲｅｓｖメッセージに基づく予約処理（Ｒｅｓｖメッセージ処理）を待機する方法がある。
しかしながら、上述した中継ノードが予約処理を待機する方法では、以下の問題があった。すなわち、上記方法では、図３７に示すように、Ｒｅｓｖメッセージの送信経路において、予約処理を待機する中継ノードの前段にて既に帯域が予約されている場合には、当該帯域は他のトラフィック中継のために使用できない状態となる。
このように、上記方法では、Ｒｅｓｖメッセージ処理が待機される時間、帯域予約が無駄となるおそれがあった。昨今では、通信の更なる高速化、更なる大容量化の需要が急激
に高まっている。このため、上記方法が実施される環境は必ずしも望ましいとは言えなかった。
に高まっている。このため、上記方法が実施される環境は必ずしも望ましいとは言えなかった。
本開示は、送受信間の通信に関する予約要求帯域を或る経路で確保できない場合に複数の経路で予約要求帯域を確保可能とする技術を提供することを課題とする。
本開示は、送信元ノードと送信先ノードとの間で帯域予約要求メッセージが転送される経路上にある中継ノードであって、
前記送信元ノードと前記送信先ノードとの間の通信に関して予約を要求する帯域を示す予約要求帯域を含んだ前記帯域予約要求メッセージを受信する受信部と、
前記経路上にある隣接ノードとの間で前記予約要求帯域を確保可能であるときに前記帯域予約要求メッセージを前記経路上の次ノードに転送する送信部と、
前記予約要求帯域を前記隣接ノードとの間で確保できないときに前記予約要求帯域の一部の帯域を前記経路上で確保するための情報を含めた前記帯域予約要求メッセージを前記送信部から前記次ノードへ転送する処理と前記経路と異なる他の経路で残りの帯域を確保するための処理とを行う制御部と、
を含む中継ノードである。
前記送信元ノードと前記送信先ノードとの間の通信に関して予約を要求する帯域を示す予約要求帯域を含んだ前記帯域予約要求メッセージを受信する受信部と、
前記経路上にある隣接ノードとの間で前記予約要求帯域を確保可能であるときに前記帯域予約要求メッセージを前記経路上の次ノードに転送する送信部と、
前記予約要求帯域を前記隣接ノードとの間で確保できないときに前記予約要求帯域の一部の帯域を前記経路上で確保するための情報を含めた前記帯域予約要求メッセージを前記送信部から前記次ノードへ転送する処理と前記経路と異なる他の経路で残りの帯域を確保するための処理とを行う制御部と、
を含む中継ノードである。
本開示によれば、送受信間の通信に関する予約要求帯域を或る経路で確保できない場合に複数の経路で予約要求帯域を確保可能とすることができる。
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。実施形態では、送信元ノードと送信先ノードとの間の或る経路で所望の帯域が確保できないときに、送信元ノードと送信先ノードとの間にある他の経路を用いて所望の帯域確保を試行するネットワークシステムについて説明する。
当該ネットワークシステムでは、Ｐａｔｈメッセージの転送経路で予約を所望する帯域が確保できないときに、不足している帯域を別経路で補うことができる。これによって、上述したような、所望の空き帯域が生じるまでＲｅｓｖメッセージ処理を待機する方法を採ることを要しなくなる。従って、帯域予約によって予約済みであるのにパケット中継に使用されない無駄な帯域がネットワーク上に長期間発生することを回避することができる。換言すれば、当該ネットワークシステムは、無駄となる帯域予約を回避することを可能とする。
〔実施形態１〕
実施形態１では、送信元ノードと送信先ノードとの間で必要帯域が予約できない経路が発見された場合に、ロードバランシングを行うノードをネットワーク構成を考慮しつつ動的に選定し、複数の経路で不足帯域を確保する。これによって、送信元ノードと送信先ノードとが通信をするために予約を所望する必要帯域が確保される。以下に具体的な手順を示す。
実施形態１では、送信元ノードと送信先ノードとの間で必要帯域が予約できない経路が発見された場合に、ロードバランシングを行うノードをネットワーク構成を考慮しつつ動的に選定し、複数の経路で不足帯域を確保する。これによって、送信元ノードと送信先ノードとが通信をするために予約を所望する必要帯域が確保される。以下に具体的な手順を示す。
＜手順０：Ｐａｔｈメッセージ／Ｒｅｓｖメッセージ＞
実施形態１では、送信元ノードと、送信先（宛先）ノードとの間で、通信のＱｏＳを保証するための帯域を予約するために、ＰａｔｈメッセージとＲｅｓｖメッセージが送受信される。以下の説明において、送信元ノードは、送信ノードと呼ぶこともある。また、送信先ノードは、受信ノードと呼ぶこともある。Ｐａｔｈメッセージは、「帯域予約要求メッセージ」の一例であり、Ｒｅｓｖメッセージは、「帯域予約メッセージ」の一例である
。
実施形態１では、送信元ノードと、送信先（宛先）ノードとの間で、通信のＱｏＳを保証するための帯域を予約するために、ＰａｔｈメッセージとＲｅｓｖメッセージが送受信される。以下の説明において、送信元ノードは、送信ノードと呼ぶこともある。また、送信先ノードは、受信ノードと呼ぶこともある。Ｐａｔｈメッセージは、「帯域予約要求メッセージ」の一例であり、Ｒｅｓｖメッセージは、「帯域予約メッセージ」の一例である
。
図１は、実施形態で適用されるＰａｔｈメッセージ及びＲｅｓｖメッセージのフォーマットの一部を模式的に示す図である。図１において、Ｐａｔｈメッセージは、ＲＳＶＰに従ったＰａｔｈメッセージのフォーマットを拡張して生成されている。Ｐａｔｈメッセージは、新たなパラメータとして「ＰａｔｈＩＤ（パスＩＤ）」と、「必要帯域情報」と「予約帯域情報」とを含む。
ＰａｔｈＩＤは、送信元ノードの識別情報と、識別番号との組み合わせで形成される。送信元ノードの識別情報は、例えば、Ｐａｔｈメッセージを送信する送信元ノードのMedia Access Control（ＭＡＣ）アドレス（物理アドレス）である。但し、送信元ノードが複数のＭＡＣアドレスを有する場合には、Ｐａｔｈメッセージの送信に用いたＭＡＣアドレスが識別情報として設定される。但し、送信元ノードを一意に識別できる情報であれば、ＭＡＣアドレス以外の情報であっても良い。
識別番号は、送信元ノードと送信先ノードとの間で複数の経路（パス）を用いて帯域が予約される場合において、各パスの識別情報として用いられる。識別番号には、例えば自然数が使用される。送信元ノードにて、第ｘ（ｘは２以上の自然数）Ｐａｔｈメッセージ送信指示メッセージを受信していなければ、識別番号には“１”が設定される。
必要帯域情報は、送信元ノードと送信先ノードとの通信のＱｏＳを保証するために必要な帯域（必要帯域）を示す。必要帯域情報の値は、Ｐａｔｈメッセージが送信元ノードから送信されて送信先ノードへ到達するまでの間に更新されることはない。必要帯域情報は、「予約要求帯域」の一例である。
予約帯域情報は、必要帯域のうち、Ｐａｔｈメッセージが転送される経路（パス）上においてＰａｔｈメッセージを受信したノードと、Ｐａｔｈメッセージの前ホップに該当する隣接ノード（以下、「前ノード」と称する）にて仮予約された帯域（「仮予約帯域」と称することもある）を示す。予約帯域情報は、「予約要求帯域の一部の帯域を経路上で確保するための情報」の一例である。
送信元ノードからＰａｔｈメッセージが送信される時点では、予約帯域情報の値は、必要帯域情報の値と同じ値が設定されている。予約帯域情報の値は、Ｐａｔｈメッセージを受信する各ノードにおいて、Ｐａｔｈメッセージの次ホップに該当する隣接ノード（以下、「次ノード」と称する）との間の空き帯域が予約帯域情報の値より小さい場合に、空き帯域の値を用いて自動的に更新される。
図１において、実施形態１に係るＲｅｓｖメッセージもＲＳＶＰに従った既存のＲｅｓｖメッセージが拡張されている。拡張領域には、Ｐａｔｈメッセージに設定されたＰａｔｈＩＤが設定される。
本実施形態では、必要帯域を複数の経路を用いて確保するために、複数のＰａｔｈメッセージが使用される。送信元ノードの識別情報は、複数のＰａｔｈメッセージが或る必要帯域の予約に係るＰａｔｈメッセージ群であることを紐づけるために使用される（ＰａｔｈメッセージのグループＩＤに相当する）。
識別番号は、同一グループ内（同一の送信元ノードの識別情報を有するＰａｔｈメッセージ間）間で、各Ｐａｔｈメッセージを識別するために使用される。各Ｒｅｓｖメッセージには、各Ｐａｔｈメッセージとの関連づけを行うために、対応するＰａｔｈメッセージに含まれていたＰａｔｈＩＤが含められる。これにより、Ｒｅｓｖメッセージも、Ｐａｔ
ｈＩＤを用いてＲｅｓｖメッセージ間での区別が図られる。
ｈＩＤを用いてＲｅｓｖメッセージ間での区別が図られる。
＜手順１＞
図２〜１５は、実施形態１の説明図である。図２〜図１５には、実施形態１におけるネットワークシステムの例が図示されている。例えば、図２において、ネットワークシステムは、送信元ノードＳＮと、送信先ノードＤＮと、送信元ノードＳＮと送信先ノードＤＮとの間に複数の経路を形成する複数の中継ノードＲＮを含んでいる。送信元ノードＳＮ，送信先ノードＤＮ，中継ノードＲＮのそれぞれは、「ノード」の一例である。
図２〜１５は、実施形態１の説明図である。図２〜図１５には、実施形態１におけるネットワークシステムの例が図示されている。例えば、図２において、ネットワークシステムは、送信元ノードＳＮと、送信先ノードＤＮと、送信元ノードＳＮと送信先ノードＤＮとの間に複数の経路を形成する複数の中継ノードＲＮを含んでいる。送信元ノードＳＮ，送信先ノードＤＮ，中継ノードＲＮのそれぞれは、「ノード」の一例である。
図２に示す例では、中継ノードＲＮとして、複数のノードａ〜ｆが例示されている。送信元ノードＳＮと送信先ノードＤＮとの間には、“ノードＡ→ノードＢ→ノードＣ→ノードＤ”を経由する第１の経路（ルート）と、“ノードＡ→ノードＥ→ノードＦ→ノードＤ”を経由する第２の経路（ルート）とが形成されている。第１の経路のコストは、第２の経路のコストより小さく、最短経路とされている。
送信元ノードＳＮと送信先ノードＤＮとの間で、例えば、１００Ｍｂｐｓの帯域を予約して通信を行う場合、送信元ノードＳＮは、図１に示したＰａｔｈメッセージを送信する。以下の説明では、説明を簡単にするため、送信元ノードＳＮはＭＡＣアドレスを１つだけ有しているものと仮定する。
送信元ノードＳＮから送信される時点でのＰａｔｈメッセージにおけるＰａｔｈＩＤの値は、送信元ノードＳＮのＭＡＣアドレス及び識別番号“１”である。また、必要帯域情報及び予約帯域情報の値は、それぞれ“１００Ｍｂｐｓ”である。Ｐａｔｈメッセージは、次ノードに該当するノードａで受信される。
なお、送信元ノードＳＮは、Ｐａｔｈメッセージの送信に先立ち、次ノードに該当するノードａの間（区間）の空き帯域を調査する。調査の結果、ノードａとの間の空き帯域がＰａｔｈメッセージ中の必要帯域以上である（必要帯域を確保可能である）場合には、送信元ノードＳＮとノードａとの間に必要帯域分の帯域を仮予約する。
ここに、「仮予約」とは、帯域の予約状態が一定時間のうちに開放されることを意味する。本実施形態では、仮予約された帯域は、仮予約帯域を生成する契機となったＰａｔｈメッセージのＰａｔｈＩＤと同じ値のＰａｔｈＩＤを有するＲｅｓｖメッセージが受信されたときに、当該Ｒｅｓｖメッセージに基づく処理によって再度予約される。このＲｅｓｖメッセージに基づく予約を「本予約」といい、この「本予約」に対して「仮予約」と呼ぶ。本予約された帯域が、送信元ノードＳＮと送信先ノードＤＮとの間で行われるデータ転送に使用される。
本実施形態では、所定時間内に本予約の完了を送信元ノードＳＮが検知できない場合には、送信元ノードＳＮから仮予約帯域を開放するメッセージが送信され、仮予約状態が解除される。従って、仮予約された帯域は、一定時間の内に開放される。
仮予約は、各ノードにおいて、Ｐａｔｈメッセージを受信した時点では確保可能であった帯域がＲｅｓｖメッセージを用いた本予約までの間における帯域変動によって確保できなくなることを回避するためになされる。このため、Ｐａｔｈメッセージの転送経路上にある各ノードにおいて、Ｐａｔｈメッセージの受信時点からＲｅｓｖメッセージ受信までの間に十分な空き帯域が確保されるような環境下では、仮予約を要しないこともある。
＜手順２＞
図２において、Ｐａｔｈメッセージを受信したノードａは、Ｐａｔｈメッセージの次ノ
ードであるノードｂとの間（区間）の空き帯域をチェック（調査）する。ノードａは、予約帯域情報を参照し、予約帯域情報で示される必要帯域以上の空き帯域がある場合には、ノードａは、ノードｂとの間で必要帯域分の帯域を仮予約する。
図２において、Ｐａｔｈメッセージを受信したノードａは、Ｐａｔｈメッセージの次ノ
ードであるノードｂとの間（区間）の空き帯域をチェック（調査）する。ノードａは、予約帯域情報を参照し、予約帯域情報で示される必要帯域以上の空き帯域がある場合には、ノードａは、ノードｂとの間で必要帯域分の帯域を仮予約する。
仮予約ができた場合、ノードａは、Ｐａｔｈメッセージ中の予約帯域情報の値を変更することなく、Ｐａｔｈメッセージを次ノードへ送信する。ここでは、コストがノードｅより小さいノードｂへＰａｔｈメッセージが転送される。
また、ノードａは、Ｐａｔｈメッセージ中のＰａｔｈＩＤを記憶する。さらに、ノードａは、記憶したＰａｔｈＩＤ中の識別番号とＰａｔｈメッセージに係る経路との関連づけを行う。
すなわち、ノードａは、Ｐａｔｈメッセージを受信した経路（送信元ノードＳＮへ向かう経路）と識別番号との関連づけを行う。また、ノードａは、Ｐａｔｈメッセージを送信した経路（送信先ノードＤＮへ向かう経路）と識別番号との関連づけを行う。関連づけは、例えば、ノードａが備える経路表中の該当経路に識別番号を付与（マーキング）することによって行われる。ＰａｔｈＩＤの記憶及び経路と識別番号との関連づけは、Ｐａｔｈメッセージを受信する各ノードにて実行される。
＜手順３＞
図３において、Ｐａｔｈメッセージを受信したノードｂは、ノードａと同様の処理を行うことを試行する。すなわち、次ノードであるノードｃとの間の空き帯域を調査し、必要帯域（予約帯域情報の値）を確保可能か否かを判定する。図３に示す例では、空き帯域が７０Ｍｂｐｓであり、必要帯域１００Ｍｂｐｓより３０Ｍｂｐｓ不足する場合を仮定する。
図３において、Ｐａｔｈメッセージを受信したノードｂは、ノードａと同様の処理を行うことを試行する。すなわち、次ノードであるノードｃとの間の空き帯域を調査し、必要帯域（予約帯域情報の値）を確保可能か否かを判定する。図３に示す例では、空き帯域が７０Ｍｂｐｓであり、必要帯域１００Ｍｂｐｓより３０Ｍｂｐｓ不足する場合を仮定する。
空き帯域の不足が検知されたノードは、以下の２つの処理を行う。図３の例に倣い、ノードｂを例として説明する。第１の処理として、ノードｂは、Ｐａｔｈメッセージに含まれた予約帯域情報を更新する。具体的には、ノードｂは、Ｐａｔｈメッセージ中の予約帯域情報の値（１００Ｍ）をノードｃとの間の全空き帯域の値（７０Ｍ）に更新する。但し、全空き帯域よりも小さい値が設定されても良い。
ノードｂは、予約帯域情報を更新したＰａｔｈメッセージを次ノードであるノードｃへ転送する。このように、本実施形態では、必要予約帯域が確保可能か否かに関わらず、Ｐａｔｈメッセージは次ノードに転送され、最終的に送信先ノードＤＮに到達する。
第２の処理として、ノードｂは、ノードｂが備える経路表（ルーティングテーブル）を用いて、自ノードから送信先ノードＤＮへ向かう別の経路が存在するか否かを判定する。例えば、ノードｂは、ロードバランシング実施可否判断処理を実行する。
ロードバランシング実施可否判断処理では、ノードｂは、不等コストロードバランシング（unequal-cost load balancing）の倍率（バリアンス）を強制的に上げる。これによ
って、Ｐａｔｈメッセージの宛先（送信先ノードＤＮ）へ向かう別の経路（バリアンス上昇前はマスクされていた経路）が経路表に出現したか否かを判定する。バリアンス上昇前に、経路表に別の経路が存在している場合には、バリアンス上昇処理を行わず、当該別の経路の存在を以て、別の経路が存在すると判断することもできる。
って、Ｐａｔｈメッセージの宛先（送信先ノードＤＮ）へ向かう別の経路（バリアンス上昇前はマスクされていた経路）が経路表に出現したか否かを判定する。バリアンス上昇前に、経路表に別の経路が存在している場合には、バリアンス上昇処理を行わず、当該別の経路の存在を以て、別の経路が存在すると判断することもできる。
ロードバランシング実施可否判断処理によって、別経路が発見された場合には、ノードｂ（自ノード）が、ロードバランシング実行ノード（ロードバランシング開始ノード）になれる（ロードバランシング実行ノードとして動作する）ことを意味する。これに対し、
別経路が発見されないことは、ノードｂ（自ノード）がロードバランシング実行ノードになれないことを意味する。ロードバランシング実施可否判断処理を実行したノードｂは、ロードバランシング実施可否判断を実行したことを履歴として一定時間保存する。
別経路が発見されないことは、ノードｂ（自ノード）がロードバランシング実行ノードになれないことを意味する。ロードバランシング実施可否判断処理を実行したノードｂは、ロードバランシング実施可否判断を実行したことを履歴として一定時間保存する。
＜手順４＞
図４において、ノードｂからのＰａｔｈメッセージを受信したノードｃは、次ノードであるノードｄとの間の空き帯域を調査するとともに、空き帯域が予約帯域情報の値“７０Ｍ”以上か否かを判定する。このとき、空き帯域が“７０Ｍ”以上であれば、ノードｃは仮予約を行い、Ｐａｔｈメッセージをノードｄに転送する。
図４において、ノードｂからのＰａｔｈメッセージを受信したノードｃは、次ノードであるノードｄとの間の空き帯域を調査するとともに、空き帯域が予約帯域情報の値“７０Ｍ”以上か否かを判定する。このとき、空き帯域が“７０Ｍ”以上であれば、ノードｃは仮予約を行い、Ｐａｔｈメッセージをノードｄに転送する。
＜手順５＞
ノードｄも、ノードｃと同様の処理を行う。その結果、ノードｄと送信先ノードＤＮとの間に“７０Ｍ”の帯域が仮予約され、Ｐａｔｈメッセージが送信先ノードＤＮに到達する。
ノードｄも、ノードｃと同様の処理を行う。その結果、ノードｄと送信先ノードＤＮとの間に“７０Ｍ”の帯域が仮予約され、Ｐａｔｈメッセージが送信先ノードＤＮに到達する。
＜手順６＞
ここで、送信先ノードＤＮでの処理について説明する。送信先ノードＤＮは、Ｐａｔｈメッセージを受信すると、ＰａｔｈメッセージからＰａｔｈＩＤ，必要帯域情報，及び予約帯域情報を取得する。このとき、送信先ノードＤＮは、ＰａｔｈＩＤの識別番号が“１”であり、且つ「必要帯域情報＝予約帯域情報」であれば、送信元ノードＳＮ向けにＲｅｓｖメッセージを送信する。このとき、Ｒｅｓｖメッセージには、対応するＰａｔｈメッセージ中のＰａｔｈＩＤがセットされる。
ここで、送信先ノードＤＮでの処理について説明する。送信先ノードＤＮは、Ｐａｔｈメッセージを受信すると、ＰａｔｈメッセージからＰａｔｈＩＤ，必要帯域情報，及び予約帯域情報を取得する。このとき、送信先ノードＤＮは、ＰａｔｈＩＤの識別番号が“１”であり、且つ「必要帯域情報＝予約帯域情報」であれば、送信元ノードＳＮ向けにＲｅｓｖメッセージを送信する。このとき、Ｒｅｓｖメッセージには、対応するＰａｔｈメッセージ中のＰａｔｈＩＤがセットされる。
また、送信先ノードＤＮは、必要帯域情報を元に、送信元ノードＳＮとの通信に要する必要帯域を予約（本予約）する。すなわち、送信先ノードＤＮは、仮予約された前ノードとの間の仮予約された帯域を本予約状態に移行させる。
これに対し、「必要帯域情報＞予約帯域情報」である場合。或いは、識別番号が“２”以上で「必要帯域情報＝予約帯域情報」となっていた場合には、送信先ノードＤＮは、送信元ノードＳＮ向けのＲｅｓｖメッセージの送信を直ちに行わない。これらの場合、送信先ノードＤＮは、ＰａｔｈＩＤのＭＡＣアドレスが同一のＰａｔｈメッセージの受信履歴を記憶しているか否かを確認する。
該当する受信履歴が無かった場合（実施形態では、識別番号が“２”以上で「必要帯域情報＝予約帯域情報」となる場合は存在しない）には、Ｐａｔｈメッセージから取得した必要帯域情報と予約帯域情報とＰａｔｈＩＤを一定時間保持しておく。
該当する受信履歴があった場合には、送信先ノードＤＮは、過去に受信されたＰａｔｈメッセージにおける予約帯域情報の帯域値と今回受信された予約帯域情報の帯域値とを加算した帯域の合計値を求める。合計値が「合計値＝最初に受信した同一ＭＡＣアドレスのＰａｔｈＩＤを持つＰａｔｈメッセージの必要帯域情報」となった場合には、送信先ノードＤＮは、送信元ノードＳＮへＲｅｓｖメッセージを送信する。
この場合、送信先ノードＤＮは、複数のＲｅｓｖメッセージを送信する。Ｒｅｓｖメッセージの数は、受信されたＰａｔｈメッセージ（送信元ノードの識別情報（ＭＡＣアドレス）が同じ）の数と同数となる。換言すれば、Ｒｅｓｖメッセージの数は、予約帯域情報の加算に利用したＰａｔｈメッセージの数と同数である。各Ｒｅｓｖメッセージには、対応するＰａｔｈメッセージ中のＰａｔｈＩＤがセットされる。
一方、合計値算出の結果が、「合計値＜最初に受信した同一ＭＡＣアドレスのＰａｔｈ
ＩＤを持つＰａｔｈメッセージの必要帯域情報」である場合には、当該合計値を保持し、更に同一のＭＡＣアドレス（送信元ノードの識別情報）を含むＰａｔｈＩＤを有するＰａｔｈメッセージの受信を待機する。
ＩＤを持つＰａｔｈメッセージの必要帯域情報」である場合には、当該合計値を保持し、更に同一のＭＡＣアドレス（送信元ノードの識別情報）を含むＰａｔｈＩＤを有するＰａｔｈメッセージの受信を待機する。
図４に示す例では、送信先ノードＤＮは、ＰａｔｈＩＤ＝識別情報“送信元ノードＳＮのＭＡＣアドレス”，ＰａｔｈＩＤの識別番号“１”，必要帯域情報“１００Ｍ”，予約帯域情報“７０Ｍ”を含むＰａｔｈメッセージを受信する。このため、Ｒｅｓｖメッセージの送信を行わず、ＭＡＣアドレスが同一のＰａｔｈメッセージの受信を待機する状態となる。
＜手順７＞
図４において、送信先ノードＤＮまでのＰａｔｈメッセージの転送経路上にある中継ノードＲＮにて予約帯域情報が更新された場合には、予約帯域情報を更新した中継ノードＲＮ（ノードｂ）は、送信元ノードＳＮ向けの仮予約帯域更新メッセージを前ノード（ノードａ）へ送信する。
図４において、送信先ノードＤＮまでのＰａｔｈメッセージの転送経路上にある中継ノードＲＮにて予約帯域情報が更新された場合には、予約帯域情報を更新した中継ノードＲＮ（ノードｂ）は、送信元ノードＳＮ向けの仮予約帯域更新メッセージを前ノード（ノードａ）へ送信する。
仮予約帯域更新メッセージは、更新された予約帯域情報“７０Ｍ”と、ＰａｔｈメッセージのＰａｔｈＩＤとを含む。仮予約帯域更新メッセージを受け取ったノードａは、当該メッセージ中のＰａｔｈＩＤを参照し、ノードａ自身が同一のＰａｔｈＩＤを持つＰａｔｈメッセージに基づき帯域を仮予約しているかを確認する。仮予約された帯域が存在する場合には、仮予約帯域更新メッセージ中の予約帯域情報に従って、仮予約帯域の帯域幅を変更（更新）する。これによって、ノードａとノードｂとの間の仮予約帯域が“１００Ｍ”から“７０”Ｍに変更される。
仮予約帯域更新メッセージを受信したノードは、当該メッセージを前ノードへ転送する。これによって、ノードａから送信元ノードＳＮへ仮予約帯域更新メッセージが転送される。送信元ノードＳＮは、当該メッセージに従ってノードａとの間の仮予約帯域を“７０Ｍ”に更新する（図５参照）。
このように、Ｐａｔｈメッセージの転送経路上の或る中継ノードＲＮで予約帯域情報が更新された場合には、当該中継ノードＲＮから送信先ノードＤＮの間にある各中継ノードＲＮは、Ｐａｔｈメッセージの予約帯域情報を用いて必要帯域の一部を仮予約する。一方、当該中継ノードから送信元ノードＳＮまでの区間は、仮予約帯域更新メッセージによって、必要帯域の一部が仮予約された状態に変更される。このようにして、必要帯域の一部がＰａｔｈメッセージが転送される経路（或る経路）で確保された状態となる。
＜手順８＞
実施形態１に係るネットワークトポロジでは、ノードｂはノードｃへの経路以外に送信先ノードＤＮへ向かう経路を有していない。このため、ノードｂは、手順３で説明したロードバランシング実施可否判断処理（別経路探索処理）の結果、ロードバランシングを実行できない（別の経路が発見されない）ことを検知する。
実施形態１に係るネットワークトポロジでは、ノードｂはノードｃへの経路以外に送信先ノードＤＮへ向かう経路を有していない。このため、ノードｂは、手順３で説明したロードバランシング実施可否判断処理（別経路探索処理）の結果、ロードバランシングを実行できない（別の経路が発見されない）ことを検知する。
この場合、ノードｂは、前ノードに対して、ロードバランシング実施可否判断実行指示メッセージを送信する（図４）。ロードバランシング実施可否判断実行指示メッセージは、Ｐａｔｈメッセージ中のＰａｔｈＩＤ及び不足予約帯域情報を含む。不足予約帯域情報は、仮予約帯域が必要帯域に対して不足している帯域を示す情報であり、必要帯域から仮予約帯域を減じて算出される。
＜手順９＞
ロードバランシング実施可否判断実行指示メッセージを受信したノードは、ロードバラ
ンシング実施可否判断処理を実行する。ロードバランシング実施可否判断の結果、ロードバランシングを実行できないと判断した場合は、更に送信元ノードＳＮに近い隣接ノードにロードバランシング実施可否判断実行指示メッセージを送信する。なお、ロードバランシング実施可否判断を実行するノードが送信元ノードＳＮとなり、送信元ノードＳＮもロードバランシングを実行できない場合には、複数経路を用いた帯域予約を止める。
ロードバランシング実施可否判断実行指示メッセージを受信したノードは、ロードバラ
ンシング実施可否判断処理を実行する。ロードバランシング実施可否判断の結果、ロードバランシングを実行できないと判断した場合は、更に送信元ノードＳＮに近い隣接ノードにロードバランシング実施可否判断実行指示メッセージを送信する。なお、ロードバランシング実施可否判断を実行するノードが送信元ノードＳＮとなり、送信元ノードＳＮもロードバランシングを実行できない場合には、複数経路を用いた帯域予約を止める。
＜手順１０＞
図５において、ロードバランシング実行可否判断実行指示メッセージをノードｂから受け取ったノードａは、ロードバランシング実施可否判断処理を行う。ノードａは、送信先ノードＤＮへ向かう別経路（他の経路）として、ノードｅ，ノードｆ及びノードｄを経由する経路を有している。
図５において、ロードバランシング実行可否判断実行指示メッセージをノードｂから受け取ったノードａは、ロードバランシング実施可否判断処理を行う。ノードａは、送信先ノードＤＮへ向かう別経路（他の経路）として、ノードｅ，ノードｆ及びノードｄを経由する経路を有している。
このため、経路表から上記別経路が発見される。これにより、ノードａは、ロードバランシングを実行できると判断し、経路表から発見された送信先ノードＤＮ宛の別経路向けに、ロードバランシング終端発見メッセージを送信する（図６）。
ロードバランシング終端発見メッセージは、ロードバランシング実施可否判断実行指示メッセージに含まれていたＰａｔｈＩＤが含められる。また、不足予約帯域情報は、ロードバランシング終端発見メッセージを送信した中継ノードＲＮ（ノードａ）で保持される。
＜手順１１＞
ロードバランシング終端発見メッセージを受信した中継ノードＲＮは、以下のような処理を行う。すなわち、中継ノードＲＮは、そのメッセージの持つＰａｔｈＩＤを確認する。このとき、過去に何らかのＰａｔｈメッセージが自ノードを経由したことがある場合には、過去に自身を経由したＰａｔｈメッセージから得られたＰａｔｈＩＤ（自ノードで記憶強いる）と、ロードバランシング終端発見メッセージ中のＰａｔｈＩＤとを比較する。
ロードバランシング終端発見メッセージを受信した中継ノードＲＮは、以下のような処理を行う。すなわち、中継ノードＲＮは、そのメッセージの持つＰａｔｈＩＤを確認する。このとき、過去に何らかのＰａｔｈメッセージが自ノードを経由したことがある場合には、過去に自身を経由したＰａｔｈメッセージから得られたＰａｔｈＩＤ（自ノードで記憶強いる）と、ロードバランシング終端発見メッセージ中のＰａｔｈＩＤとを比較する。
比較の結果、ＭＡＣアドレス（送信元ノードの識別情報）が一致するＰａｔｈＩＤがない場合には、当該中継ノードＲＮは、ロードバランシング終端発見メッセージを次ノードへ送信する。
これに対し、比較の結果、ＭＡＣアドレス（送信元ノードの識別情報）が一致するＰａｔｈＩＤがある場合には、中継ノードＲＮは、過去におけるロードバランシング実施可否判断の実行履歴が記憶されているか否かを調査する。
ロードバランシング実施可否判断の実行履歴がなかった場合には、当該中継ノードＲＮは、ロードバランシング終端発見メッセージの送信元ノード向けに、別経路メンバパス発見成功メッセージを送信する。
別経路メンバパス発見成功メッセージには、当該中継ノードＲＮで受信されたロードバランシング終端発見メッセージ中のＰａｔｈＩＤが設定される。このＰａｔｈＩＤは、ロードバランシング終端発見メッセージを送信したノードが、無事にロードバランシング終端ノードが発見されたことを認識するために使用される。
手順１１を図６の例に倣って説明する。ノードｅは、ノードａからロードバランシング終端発見メッセージを受信する。ノードｅは、上記で説明したＰａｔｈＩＤに係る処理を行う。このとき、同一のＭＡＣアドレスを有するＰａｔｈＩＤがないため、ノードｅは、ロードバランシング終端発見メッセージをノードｆへ転送する。ノードｆも、ノードｅと同様の処理を行い、ロードバランシング終端発見メッセージをノードｄに転送する。
ノードｅは、手順５でＰａｔｈメッセージを受信し、当該ＰａｔｈメッセージのＰａｔｈＩＤを記憶している。一方、ロードバランシング実行可否判断処理の実行履歴は記憶していない。このため、ノードｅは、自ノードがロードバランシング終端ノードとなると判断し、別経路メンバパス発見成功メッセージを、ロードバランシング終端発見メッセージの送信元ノード（ノードａ）向けに送信する。別経路メンバパス発見成功メッセージは、ノードｆ及びノードｅを経由して、ノードａで受信される（図７）。
＜手順１２＞
手順１１において、ＭＡＣアドレス（送信元ノードの識別情報）が一致するＰａｔｈＩＤがあり、且つ過去におけるロードバランシング実施可否判断の実行履歴が記憶されている場合には、中継ノードＲＮは以下の処理を行う。すなわち、当該中継ノードＲＮは、ロードバランシング終端発見メッセージを送信した前ノードに対して別経路メンバパス発見指示メッセージを送信する。
手順１１において、ＭＡＣアドレス（送信元ノードの識別情報）が一致するＰａｔｈＩＤがあり、且つ過去におけるロードバランシング実施可否判断の実行履歴が記憶されている場合には、中継ノードＲＮは以下の処理を行う。すなわち、当該中継ノードＲＮは、ロードバランシング終端発見メッセージを送信した前ノードに対して別経路メンバパス発見指示メッセージを送信する。
別経路メンバパス発見指示メッセージを受信したノードは、ロードバランシング実施可否判断を実行し、送信先ノードＤＮへ向かう別経路を探す。別経路が存在する場合には、送信先ノードＤＮへ向けて別経路の隣接ノードにロードバランシング終端発見メッセージを送信する。但し、当該ロードバランシング終端発見メッセージの送信元ＩＰアドレスは、本来のロードバランシング終端発見メッセージの送信元ノードとする。
別経路が存在しない場合は、別経路メンバパス発見指示メッセージを受信したノードは、更にロードバランシング終端発見メッセージの送信元に１ホップ近い隣接ノードに対して、別経路メンバパス発見指示メッセージを転送する。なお、別経路メンバパス発見指示メッセージがロードバランシング終端発見メッセージを送信したノードで受信され、当該ノードで別経路が発見されない場合には、送信元ノードＳＮに１ホップ近いノードに対してロードバランシング実施可否判断実行指示メッセージが送信される。
手順１２を図８〜図１０を用いて説明する。図８〜図１０は、ネットワークトポロジが図１〜図７と異なり、ノードｂとノードｅとが接続されている。また、ノードｅからノードｂを経由して送信先ノードＤＮへ向かう経路のコストが、ノードｅからノードｆを経由して送信先ノードＤＮへ向かう経路のコストより小さいと仮定する。
図８において、ノードｅは、ロードバランシング終端発見メッセージを受信し、別メンバパス発見成功メッセージを送信しない判断結果を得ると、経路のコストに従ってノードｂへロードバランシング終端発見メッセージを送信する。
図９において、ノードｂでは、過去にＰａｔｈメッセージを転送しており、さらに、ロードバランシング実行可否判断処理の実行履歴を記憶している（手順３）。このため、ノードｂは、ロードバランシング終端発見メッセージの前ノードに該当するノードｅへ別経路メンバパス発見指示メッセージを送信する。
別経路メンバパス発見指示メッセージを受信したノードｅは、ロードバランシング実施可否判断処理を行う。この結果、別経路として、ノードｆを経由する経路が発見される。すると、ノードｅは、ノードｆへロードバランシング終端発見メッセージを送信する（図１０）。このとき、ロードバランシング終端発見メッセージの送信元ＩＰアドレスには、本来のロードバランシング終端発見メッセージを送信したノードａのＩＰアドレスが設定される。
ノードｆは、手順１１と同様に、ロードバランシング終端発見メッセージをノードｄへ
転送する（図１０）。そして、ノードｄが別経路メンバパス発見指示メッセージをノードｆへ送信し、図７に示した状態、すなわち、別経路メンバパス発見指示メッセージをノードａが受信した状態となる。
転送する（図１０）。そして、ノードｄが別経路メンバパス発見指示メッセージをノードｆへ送信し、図７に示した状態、すなわち、別経路メンバパス発見指示メッセージをノードａが受信した状態となる。
＜手順１３＞
手順１２にて別経路メンバパス発見成功メッセージを送信するノード（ノードｄ）は、ノードｄが備える経路表に、ロードバランシング終端発見メッセージを受信した方路へパケット送信を行うための経路を新たに設ける。例えば、ノードｄは、不等コストロードバランシングのバリアンスを強制的に上昇させて、当該経路（ノードｆを経由して送信元ノードＳＮへ向かう経路）を経路表に新規に作成する。結果として、ノードｄの経路表には、送信元ノードＳＮへ向かう複数の経路が存在する状態になる。
手順１２にて別経路メンバパス発見成功メッセージを送信するノード（ノードｄ）は、ノードｄが備える経路表に、ロードバランシング終端発見メッセージを受信した方路へパケット送信を行うための経路を新たに設ける。例えば、ノードｄは、不等コストロードバランシングのバリアンスを強制的に上昇させて、当該経路（ノードｆを経由して送信元ノードＳＮへ向かう経路）を経路表に新規に作成する。結果として、ノードｄの経路表には、送信元ノードＳＮへ向かう複数の経路が存在する状態になる。
＜手順１４＞
図１１に示すように、ロードバランシング終端発見メッセージを送信したノード（ノードａ）は、別経路メンバパス発見成功メッセージを受信した場合には、以下の処理を行う。すなわち、ノードａは、ロードバランシング終端発見メッセージを送信した隣接ノード（ノードｅ）を経由して送信先ノードＤＮへ向かう経路に識別番号を設ける。
図１１に示すように、ロードバランシング終端発見メッセージを送信したノード（ノードａ）は、別経路メンバパス発見成功メッセージを受信した場合には、以下の処理を行う。すなわち、ノードａは、ロードバランシング終端発見メッセージを送信した隣接ノード（ノードｅ）を経由して送信先ノードＤＮへ向かう経路に識別番号を設ける。
このため、ノードａは、送信元ノードＳＮに識別番号問い合わせメッセージを送信する。送信元ノードＳＮは、当該メッセージに対して識別番号を含む応答メッセージをノードａに送信する。問い合わせに応答する識別番号として、例えば、問い合わせに含まれた識別番号に１を加えた値が設定される。
図１１の例では、ノードａからノードｂに向かう経路に識別番号“１”が設定されており、ノードａが問合せの結果、識別番号“２”を得て、経路表中のノードｅへ向かう経路に識別番号“２”を設定した様子が図示されている。
＜手順１５＞
その後、図１２に示すように、ロードバランシング終端発見メッセージを送信したノード（ノードａ）は、送信元ノードＳＮに対して第ｘＰａｔｈメッセージ送信指示メッセージを送信する。ｘの値は、識別番号問い合わせメッセージにより取得した識別番号に１を加算した値である。
その後、図１２に示すように、ロードバランシング終端発見メッセージを送信したノード（ノードａ）は、送信元ノードＳＮに対して第ｘＰａｔｈメッセージ送信指示メッセージを送信する。ｘの値は、識別番号問い合わせメッセージにより取得した識別番号に１を加算した値である。
送信元ノードＳＮは、識別番号問い合わせメッセージを受信した時点で最大の“ｘ”の値を応答としてノードａに返す。図１２の例では、送信元ノードＳＮは、識別番号“１”を含むＰａｔｈメッセージのみを送信している。このため、最大の“ｘ”の値は“１”であり、識別番号“１”を含む応答をノードａに送る。ノードａは、応答中の識別番号１に１を加えて識別番号“２”を得る。従って、図１２の例では、第ｘＰａｔｈメッセージ送信指示メッセージは、第２Ｐａｔｈメッセージ送信指示メッセージとなる。識別番号は、「経路と他の経路とを識別するための識別情報」の一例である。
第ｘＰａｔｈメッセージ送信指示メッセージには、予約帯域情報と、必要帯域情報と、ＰａｔｈＩＤと、送信先ノードＤＮのＩＰアドレスとが含められる。予約帯域情報の値として、手順１０にて保持した不足予約帯域情報“３０Ｍ”と同値が設定される。必要帯域情報は、Ｐａｔｈメッセージ（第１Ｐａｔｈメッセージ）における必要帯域情報の値“１００Ｍ”が設定される。ＰａｔｈＩＤとして、送信元ノードＳＮのＭＡＣアドレスと、問い合わせにより得た識別番号“２”とが設定される。
ノードａは、送信元ノードＳＮから新たに受信する第ｘＰａｔｈメッセージを含めたメッセージやパケット（宛先同一で識別番号が異なるＰａｔｈＩＤを有するメッセージやパ
ケット）を受信した場合には、ＰａｔｈＩＤの識別番号を確認する。ＰａｔｈＩＤの識別番号が“２”以上である場合には、同一の送信先ノードＤＮへ向かう複数経路の中から、同じ識別番号が設定された経路を選択してメッセージやパケットを転送する。第ｘ（ｘ≧２）Ｐａｔｈメッセージは、「残帯域用帯域予約要求メッセージ」の一例である。
ケット）を受信した場合には、ＰａｔｈＩＤの識別番号を確認する。ＰａｔｈＩＤの識別番号が“２”以上である場合には、同一の送信先ノードＤＮへ向かう複数経路の中から、同じ識別番号が設定された経路を選択してメッセージやパケットを転送する。第ｘ（ｘ≧２）Ｐａｔｈメッセージは、「残帯域用帯域予約要求メッセージ」の一例である。
なお、上述した一連の流れにより新たに作成された経路（識別番号“２”以降が割り当てられる経路）を「メンバパス」と呼ぶ。本来の送受信ノード間の経路（識別番号１の経路）は「ファーストパス（ベストパス）」と呼ぶ。
＜手順１６＞
第ｘ Ｐａｔｈメッセージ送信指示メッセージを受信した送信元ノードＳＮは、当該送
信指示メッセージに含まれたＰａｔｈＩＤを有する新規のＰａｔｈメッセージ（第ｘＰａｔｈメッセージ）を作成し、送信先ノードＤＮへ向けて送信する（図１３参照）。図１３に示す例では、第２Ｐａｔｈメッセージに含まれる必要帯域情報及び予約帯域情報の各値として、第２Ｐａｔｈメッセージ送信指示メッセージ中の必要帯域情報の値“１００Ｍ”及び予約帯域情報の値“３０Ｍ”が適用される。
第ｘ Ｐａｔｈメッセージ送信指示メッセージを受信した送信元ノードＳＮは、当該送
信指示メッセージに含まれたＰａｔｈＩＤを有する新規のＰａｔｈメッセージ（第ｘＰａｔｈメッセージ）を作成し、送信先ノードＤＮへ向けて送信する（図１３参照）。図１３に示す例では、第２Ｐａｔｈメッセージに含まれる必要帯域情報及び予約帯域情報の各値として、第２Ｐａｔｈメッセージ送信指示メッセージ中の必要帯域情報の値“１００Ｍ”及び予約帯域情報の値“３０Ｍ”が適用される。
図１３に示す例では、第２Ｐａｔｈメッセージは、ノードａ，ノードｅ，ノードｆ，ノードｄを経由して送信先ノードＤＮへ到達する。このとき、各ノードａ，ｅ，ｆは、次ノードとの間で、予約帯域情報“３０Ｍ”に従い、３０Ｍの帯域を仮予約する。送信元ノードＳＮ及びノードｄは、さらに３０Ｍの帯域を仮予約することで、合計１００Ｍの帯域を仮予約した状態となる。
なお、第ｘＰａｔｈメッセージを受信したノードが次ノードとの間で予約帯域情報の値を下回る帯域しか確保（仮予約）できない場合には、当該ノードにおいて、別経路で不足の帯域を確保する処理（ロードバランシング実施可否判断以降の処理）が実行される。以降の動作はこれまでの手順と同様である。
＜手順１７＞
送信先ノードＤＮは、第２Ｐａｔｈメッセージを受信すると、第２Ｐａｔｈメッセージ中の予約帯域情報“３０Ｍ”と、先のＰａｔｈメッセージ中の予約帯域情報“７０Ｍ”との合計値が必要帯域情報“１００”であることを確認する。すると、送信先ノードＤＮは、ノードｄとの間で仮予約された１００Ｍの帯域を本予約に変更する。
送信先ノードＤＮは、第２Ｐａｔｈメッセージを受信すると、第２Ｐａｔｈメッセージ中の予約帯域情報“３０Ｍ”と、先のＰａｔｈメッセージ中の予約帯域情報“７０Ｍ”との合計値が必要帯域情報“１００”であることを確認する。すると、送信先ノードＤＮは、ノードｄとの間で仮予約された１００Ｍの帯域を本予約に変更する。
さらに、送信先ノードＤＮは、Ｐａｔｈメッセージに対応するＲｅｓｖメッセージと、第２Ｐａｔｈメッセージに対応するＲｅｓｖメッセージ（第２Ｒｅｓｖメッセージと称する）とを送信する（図１４参照）。
Ｒｅｓｖメッセージは、ノードｄ，ノードｃ，ノードｂ及びノードａを経由して送信元ノードＳＮに到達する。また、第２Ｒｅｓｖメッセージは、ノードｄ，ノードｆ，ノードｅ及びノードａを経由して送信元ノードＳＮに到達する。このとき、各ノードで仮予約された帯域の本予約が行われる。
その結果、図１５に示すように、送信元ノードＳＮとノードａとの間、及びノードｄと送信先ノードＤＮとの間でそれぞれ“１００Ｍ”の帯域が予約（確保）された状態となる。また、ノードａとノードｂとの間，ノードｂとノードｃとの間，及びノードｃとノードｄとの間でそれぞれ“７０Ｍ”の帯域が確保された状態となる。さらに、ノードａとノードｅとの間，ノードｅとノードｆとの間，及びノードｆとノードｄとの間でそれぞれ“３０Ｍ”の帯域が確保された状態となる。
すなわち、複数の経路を用いて送信元ノードＳＮと送信先ノードＳＮとの間で必要帯域“１００Ｍ”が予約された状態となる。送信元ノードＳＮと送信先ノードＤＮとは、予約された帯域を用いて通信（データの送受信）を行うことができる。これによって、ＱｏＳが保証された通信を送受信間で行うことができる。
＜手順１８＞
本実施形態において、送信元ノードＳＮと送信先ノードＤＮとの間で確立された複数経路を用いてデータ（パケット）の送受信を開始するときには、全てのパケットにＰａｔｈＩＤを含める。ＰａｔｈＩＤとして、複数経路の確立に用いた複数のＰａｔｈメッセージ中のＰａｔｈＩＤの一つが設定される。
本実施形態において、送信元ノードＳＮと送信先ノードＤＮとの間で確立された複数経路を用いてデータ（パケット）の送受信を開始するときには、全てのパケットにＰａｔｈＩＤを含める。ＰａｔｈＩＤとして、複数経路の確立に用いた複数のＰａｔｈメッセージ中のＰａｔｈＩＤの一つが設定される。
各パケットにどのＰａｔｈＩＤを割り当てるかは、各予約帯域情報の割合に従う。例えば、実施形態１のように、Ｐａｔｈメッセージと第２Ｐａｔｈメッセージとで２つの経路（“７０Ｍ”，“３０Ｍ”）が確立された場合では、以下のようになる。すなわち、送信元ノードＳＮから１０個のパケットを送信するときに、１０個のうちの７個には、識別番号“１”を含むＰａｔｈＩＤが設定され、残りの３個には識別番号“２”が設定される。ノードａは、パケット中のＰａｔｈＩＤを参照してパケットの転送先をノードｂとノードｅとに振り分ける。送信先ノードＤＮから送信先ノードＳＮに対して送信されるパケットに関しても同様の処理が行われる。
＜手順１９＞
上記の手順において、送信先ノードＤＮは、Ｐａｔｈメッセージに係るｘの値が所定値（例えば６）に達した場合には、複数経路での必要帯域確保を中止して、第１〜第５Ｐａｔｈメッセージにより仮予約された各帯域を開放するためのメッセージを各経路に送信する。
上記の手順において、送信先ノードＤＮは、Ｐａｔｈメッセージに係るｘの値が所定値（例えば６）に達した場合には、複数経路での必要帯域確保を中止して、第１〜第５Ｐａｔｈメッセージにより仮予約された各帯域を開放するためのメッセージを各経路に送信する。
＜実施形態１の効果＞
実施形態１によれば、或る経路で必要帯域を確保できない場合には、複数経路で必要帯域が確保される。すなわち、送受信ノード間にある複数の経路の空き帯域を用いて必要帯域を確保する。このため、１つの経路で必要帯域を予約する場合よりも、必要帯域を確保し易い。これによって、送受信間の通信におけるＱｏＳを保証することができる。
実施形態１によれば、或る経路で必要帯域を確保できない場合には、複数経路で必要帯域が確保される。すなわち、送受信ノード間にある複数の経路の空き帯域を用いて必要帯域を確保する。このため、１つの経路で必要帯域を予約する場合よりも、必要帯域を確保し易い。これによって、送受信間の通信におけるＱｏＳを保証することができる。
また、実施形態１に係る帯域予約方法では、Ｐａｔｈメッセージで必要帯域を仮予約してからＲｅｓｖメッセージを送信する。このため、関連技術として説明した「待時式帯域予約通信方式」において、Ｒｅｓｖメッセージに基づく処理が待機される現象は発生しない。これによって、帯域予約により使用されない帯域が長時間存在し、他の通信に影響を及ぼす可能性を低減することが可能となる。
実施形態１では、仮予約された帯域についてパケットが流れていないのに他の通信がリソースを使用できない現象が発生する。しかし、実施形態１では、手順がリソアルタイム性を有している。すなわち、複数経路を用いた帯域予約の手順の中で、システム全体の動作が止まることはなく、或る一定時間の内に必要帯域の予約完了又は予約処理の終了（予約を行わない）となる。このため、関連技術のように、いつまでも他の通信がリソースを使用できない状況を回避し得る。
［〔実施形態２〕］
次に、実施形態２として、実施形態１で説明したネットワークシステム及び帯域予約方法の詳細について説明する。
次に、実施形態２として、実施形態１で説明したネットワークシステム及び帯域予約方法の詳細について説明する。
〔ネットワークシステムの構成例〕
図１６は、実施形態２に係るネットワークシステムの構成例を示す。図１６に示すネットワークには、複数のノードが図示されている。複数のノードは、通信のＱｏＳを保証するための帯域を予約するＲＳＶＰにおける送信元ノードＳＮと、送信先（宛先）ノードＤＮとを含む、さらに、複数のノードは、送信元ノードＳＮと送信先ノードＤＮとの間にある少なくとも１つの中継ノードＲＮとを含む。
図１６は、実施形態２に係るネットワークシステムの構成例を示す。図１６に示すネットワークには、複数のノードが図示されている。複数のノードは、通信のＱｏＳを保証するための帯域を予約するＲＳＶＰにおける送信元ノードＳＮと、送信先（宛先）ノードＤＮとを含む、さらに、複数のノードは、送信元ノードＳＮと送信先ノードＤＮとの間にある少なくとも１つの中継ノードＲＮとを含む。
図１６に示す例では、中継ノードＲＮとして、複数のノードＡ〜Ｅが例示されている。送信元ノードＳＮは、ノードＡとリンクを介して接続されている。ノードＡは、リンクを介してノードＢ，ノードＣ，及びノードＤのそれぞれと接続されている。ノードＢは、リンクを介してノードＣと接続されている。ノードＣは、リンクを介してノードＥと接続されている。ノードＤは、リンクを介してノードＥと接続されている。ノードＥは、リンクを介して送信先ノードＤＮと接続されている。
図１６に示すネットワークシステムにおいて、送信元ノードＳＮと送信先ノードＤＮとの間で最もコストの小さい経路（パス）は、“ＳＮ→Ａ→Ｂ→Ｃ→Ｅ→ＤＮ”であると仮定する。送信元ノードＳＮと送信先ノードＤＮとの間（送受信ノード間）で予約を所望する帯域幅（必要帯域）は１００Ｍｂｐｓであると仮定する。
また、ノードＣとノードＥとの間の空き帯域は７０Ｍｂｐｓであり、他の区間では、１００Ｍｂｐｓ以上の十分な空き帯域があると仮定する。また、送受信ノード間で複数の経路を用いた１００Ｍｂｐｓの帯域予約が完了するまでの間、各経路の空き帯域の大きさは変化しないものとする。
さらに、ノードＡの経路表には、送信先ノードＤＮへ向かう複数の経路が登録されている。複数の経路をコストが小さい順で並べると、次ホップがノードＢの経路、次ホップがノードＣの経路、次ホップがノードＤの経路の順となる。
＜ノードの構成例＞
図１７は、実施形態１及び２における各ノード（送信元ノードＳＮ，送信先ノードＤＮ，及び中継ノードＲＮ）として使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。本実施形態におけるノードのハードウェア構成としては、既存のルータやレイヤ３スイッチのような通信装置が有するハードウェアアーキテクチャを適用可能である。情報処理装置１０は、例えばルータである。
図１７は、実施形態１及び２における各ノード（送信元ノードＳＮ，送信先ノードＤＮ，及び中継ノードＲＮ）として使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。本実施形態におけるノードのハードウェア構成としては、既存のルータやレイヤ３スイッチのような通信装置が有するハードウェアアーキテクチャを適用可能である。情報処理装置１０は、例えばルータである。
図１７において、情報処理装置１０は、バスＢ（内部通信路）を介して接続された１以上の通信インタフェース（通信Ｉ／Ｆ）１１と、Central Processing Unit（ＣＰＵ）１
２と、Digital Signal Processor（ＤＳＰ）１３と、メモリ１４とを含む。メモリ１４は、Random Access Memory（ＲＡＭ）１５と、Read Only Memory（ＲＯＭ）１６とを含む。通信Ｉ／Ｆ１１は、他のノードと接続される物理回線（物理リンク）を収容する。
２と、Digital Signal Processor（ＤＳＰ）１３と、メモリ１４とを含む。メモリ１４は、Random Access Memory（ＲＡＭ）１５と、Read Only Memory（ＲＯＭ）１６とを含む。通信Ｉ／Ｆ１１は、他のノードと接続される物理回線（物理リンク）を収容する。
通信Ｉ／Ｆ１１は、ＬＡＮ（例えば、イーサネット（登録商標））をサポートする通信機器である。通信Ｉ／Ｆ１１として、例えば、ネットワークインタフェースカード（ＮＩＣ）やＬＡＮ（構内交換網）カードを適用することができる。通信Ｉ／Ｆは、「受信部」，「送信部」の一例である。
メモリ１４のＲＯＭ１６は、オペレーティングシステム（ＯＳ）及び様々なアプリケーションプログラムを含む複数のコンピュータプログラムと、各プログラムの実行に際して使用されるデータとを記憶する。ＲＡＭ１５は、ＣＰＵ１２やＤＳＰ１３の作業領域とし使用される。
メモリ１４は、「記憶装置」、「記憶媒体」、「記憶部」の一例であり、ＲＯＭ１５は、不揮発性記憶媒体の一例であり、ＲＡＭ１６は揮発性記憶媒体の一例である。不揮発性記憶媒体としては、ＥＥＰＲＯＭ，フラッシュメモリ，Solid State Drive（ＳＳＤ）な
どの少なくとも１つを用いることもできる。
どの少なくとも１つを用いることもできる。
ＣＰＵ１２及びＤＳＰ１３は、ＲＯＭ１６に記憶されたプログラムをＲＡＭ１５にロードして実行する。これによって、情報処理装置１０は、パケットのルーティング，フォワーディング，ＲＳＶＰに基づく帯域予約処理のような様々な処理を実行する。ＣＰＵ１２は、情報処理装置１０が所望の動作を行うための全体的な制御を行う。ＤＳＰ１３は、例えば、経路探索に係る計算のような、高速処理が求められる処理をＣＰＵ１２の制御下で行う。ＣＰＵ１２及びＤＳＰ１３のそれぞれは、「プロセッサ」、「制御装置」、「制御部」の一例である。
なお、ＣＰＵ１２及びＤＳＰ１３によって実行される処理の一部又は全部は、例えば、集積回路（ＩＣ，ＬＳＩ，ＡＳＩＣ），プログラマブルロジックデバイス（ＰＬＤ，例えばField Programmable Gate Array（ＦＰＧＡ））を用いたハードウェアロジックによっ
て実装されることもできる。
て実装されることもできる。
＜ノードにおける処理＞
図１８は、ＣＰＵ１２がプログラムを実行することによってノードで行われる処理を模式的に示す図である。ＣＰＵ１２がプログラム実行によって行う処理は、ＣＰＵ１２の制御下でＤＳＰ１３が実行する処理も含む。以下の説明では、ＣＰＵ１２が実行する処理とＤＳＰ１３が実行する処理とを区別せず、ＣＰＵ１２が行う処理として説明する。以下に説明する複数の処理のうち、ＤＳＰ１３に実行させる処理は、適宜選択可能である。
図１８は、ＣＰＵ１２がプログラムを実行することによってノードで行われる処理を模式的に示す図である。ＣＰＵ１２がプログラム実行によって行う処理は、ＣＰＵ１２の制御下でＤＳＰ１３が実行する処理も含む。以下の説明では、ＣＰＵ１２が実行する処理とＤＳＰ１３が実行する処理とを区別せず、ＣＰＵ１２が行う処理として説明する。以下に説明する複数の処理のうち、ＤＳＰ１３に実行させる処理は、適宜選択可能である。
図１８において、ＣＰＵ１２は、受信メッセージ分析処理２０と、Ｐａｔｈメッセージ処理２１と、仮予約帯域更新メッセージ処理２２と、ロードバランシング実行可否判断実行指示メッセージ処理２３とを行う。さらに、ＣＰＵ１２は、ロードバランシング終端発見メッセージ処理２４と、別経路メンバパス発見成功メッセージ処理２５と、第ｘＰａｔｈメッセージ送信指示メッセージ処理２６とを行う。さらに、ＣＰＵ１２は、別経路メンバパス発見指示メッセージ処理２７と、第ｘＰａｔｈメッセージ処理２８と、仮帯域予約全開放メッセージ処理２９と、Ｒｅｓｖメッセージ処理３０とを行う。
＜＜受信メッセージ分析処理＞＞
受信メッセージ分析処理２０は、通信Ｉ／Ｆ１１にて隣接ノードから受信されるメッセージの種別を分析し、メッセージの種別に応じた処理にメッセージを渡す。
受信メッセージ分析処理２０は、通信Ｉ／Ｆ１１にて隣接ノードから受信されるメッセージの種別を分析し、メッセージの種別に応じた処理にメッセージを渡す。
＜＜Ｐａｔｈメッセージ処理＞＞
図１９は、Ｐａｔｈメッセージ処理２１の詳細を模式的に示す図である。Ｐａｔｈメッセージ処理２１は、カーネル（Kernel）空間とアプリケーション（ＡＰＬ）空間とを用いて処理を行う。すなわち、Ｐａｔｈメッセージ処理２１は、カーネル及びアプリケーションで形成される。カーネルは、複数の通信Ｉ／Ｆ１１（ｅｔｈ）が接続された状態となっており、各種のメッセージを含んだＩＰパケットが各通信Ｉ／Ｆ１１（ｅｔｈ）から受信（入力）される状態となっている。
図１９は、Ｐａｔｈメッセージ処理２１の詳細を模式的に示す図である。Ｐａｔｈメッセージ処理２１は、カーネル（Kernel）空間とアプリケーション（ＡＰＬ）空間とを用いて処理を行う。すなわち、Ｐａｔｈメッセージ処理２１は、カーネル及びアプリケーションで形成される。カーネルは、複数の通信Ｉ／Ｆ１１（ｅｔｈ）が接続された状態となっており、各種のメッセージを含んだＩＰパケットが各通信Ｉ／Ｆ１１（ｅｔｈ）から受信（入力）される状態となっている。
また、カーネルは、ＡＰＬ空間でなされた処理に基づく命令に従ったメッセージを含むＩＰパケットを生成する。さらに、カーネルは、経路表ＲＴを有し、経路表ＲＴを用いてＩＰパケット（メッセージ）をその宛先に対応する通信Ｉ／Ｆ１１（ｅｔｈ）から送出する。これによって、隣接ノードへのＩＰパケット（メッセージ）の送信や転送がなされる。
アプリケーションでは、Ｐａｔｈメッセージ分析制御処理３２と、帯域仮予約処理３３と、ＯＳＰＦ−ＴＥ３４と、予約帯域情報更新処理３５と、ロードバランシング実施可否判断処理３６とが実行される。さらに、Ｐａｔｈメッセージ処理２１では、ＡＰＬ空間において、転送元ＩＰカプセル化処理３７と、ロードバランシング実施可否判断指示処理３８と、仮予約帯域幅更新処理３９と、ロードバランシング処理４０と、終端制御４１とが実行される。さらに、Ｐａｔｈメッセージ処理２１では、ＡＰＬ空間において、Ｒｅｓｖ制御４２と、仮予約帯域全開放処理４３とが実行される。
なお、以下に説明する図１９〜図２８中における実線矢印は制御メッセージを示し、破線矢印は、アプリケーションからカーネルへの命令を示し、一点鎖線矢印は、条件付き制御メッセージ（条件によっては発生しない場合がある）を示す。
[Ｐａｔｈメッセージ及びＲｅｓｖメッセージ]
実施形態２におけるＰａｔｈメッセージ及びＲｅｓｖメッセージのそれぞれのデータ構造は、図１に例示した各メッセージと同様のデータ構造を有する。このため、詳細な説明は省略する。
実施形態２におけるＰａｔｈメッセージ及びＲｅｓｖメッセージのそれぞれのデータ構造は、図１に例示した各メッセージと同様のデータ構造を有する。このため、詳細な説明は省略する。
[Ｐａｔｈメッセージ分析制御処理]
図１９に戻って、Ｐａｔｈメッセージ分析制御処理３２では、カーネルに含まれる受信メッセージ分析処理２０からＰａｔｈメッセージを得る。Ｐａｔｈメッセージ分析制御処理３２は、Ｐａｔｈメッセージ中のＰａｔｈＩＤ，予約帯域情報，必要帯域情報，送信元ノードＳＮのＩＰアドレス，送信先ノードＤＮのＩＰアドレスを取得する。
図１９に戻って、Ｐａｔｈメッセージ分析制御処理３２では、カーネルに含まれる受信メッセージ分析処理２０からＰａｔｈメッセージを得る。Ｐａｔｈメッセージ分析制御処理３２は、Ｐａｔｈメッセージ中のＰａｔｈＩＤ，予約帯域情報，必要帯域情報，送信元ノードＳＮのＩＰアドレス，送信先ノードＤＮのＩＰアドレスを取得する。
Ｐａｔｈメッセージは、当該Ｐａｔｈメッセージを送信（転送）した１つ前のホップ（前ノード（previous node））中の通信機器（通信Ｉ／Ｆ１１）のＩＰアドレス（「前ホ
ップＩＰアドレス」と称する）を含んでいる。
ップＩＰアドレス」と称する）を含んでいる。
Ｐａｔｈメッセージ分析制御処理３２は、当該前ホップＩＰアドレスも取得する。Ｐａｔｈメッセージ分析制御処理３２は、取得したＰａｔｈＩＤをＲＡＭ１６に記憶する（図１９＜１＞）。また、Ｐａｔｈメッセージ分析制御処理３２は、不足予約帯域情報をＲＡＭ１６に記憶する。以下の説明において、「保持する」「保存する」との表現は、例えば、対象の情報をＲＡＭ１６などの所定の記憶領域に記憶しておくことを意味する。
Ｐａｔｈメッセージ分析制御処理３２は、ＰａｔｈＩＤ中の識別番号を、経路表ＲＴ内にある送信元ノードＳＮへ向かう経路と、送信先ノードＤＮに向かう経路のそれぞれに設定（マーキング）する（図１９＜２＞）。このとき、送信元ノードへ向かう複数の経路が経路表にある場合には、Pathメッセージが進入してきた（受信された）通信Ｉ／Ｆ１１の先にある隣接ノード（中継ノードＲＮ）経由で送信元ノードＳＮへ向かう経路に識別番号が付与される。
但し、Ｐａｔｈメッセージを受信したノードがロードバランシング実行ノードに該当する場合には、既に経路表ＲＴに識別番号が設定（付与）されている可能性がある。典型的には、Ｐａｔｈメッセージが第ｘ（ｘは自然数、但しここでは２以上の）であるときには、ネットワーク上に既にロードバランシング開始ノードが存在している。そして、ロードバランシング実行ノードの経路表ＲＴには識別番号が付与されている。この場合には、Ｐａｔｈメッセージ分析制御処理３２は、送信先ノードＤＮへ向かう経路に対する識別番号のマーキングを実施しない。
経路表ＲＴには、例えば等コストロードバランシングによって複数の送信先ノードＤＮ
へ向かう経路が存在する場合がある。この場合、Ｐａｔｈメッセージ分析制御処理３２は、ＯＳＰＦ−ＴＥ３４との連携によって、複数の経路の中から１つの経路をＰａｔｈメッセージの転送先として決定する。
へ向かう経路が存在する場合がある。この場合、Ｐａｔｈメッセージ分析制御処理３２は、ＯＳＰＦ−ＴＥ３４との連携によって、複数の経路の中から１つの経路をＰａｔｈメッセージの転送先として決定する。
このとき、Ｐａｔｈメッセージ分析制御処理３２は、複数の経路のうち空き帯域に余裕のある（例えば、空き帯域が大きい）経路をＰａｔｈメッセージの転送先として決定する。複数の経路間で空き帯域が同じである場合には、Ｐａｔｈメッセージ分析制御処理３２は、複数の経路からランダムにＰａｔｈメッセージを転送する経路を決定する。
また、Ｐａｔｈメッセージ分析制御処理３２は、Ｐａｔｈメッセージから得られた予約帯域情報を帯域仮予約処理３３に与える（図１９＜３＞）。Ｐａｔｈメッセージ分析制御処理３２は、帯域仮予約処理３３で実行される次ノードとの間での帯域の仮予約処理の結果を示す通知を受け取る（図１９＜４＞）。仮予約がなされた場合、Ｐａｔｈメッセージ分析制御処理３２は仮予約がなされた旨の通知を受け取る。
また、Ｐａｔｈメッセージ分析制御処理３２は、Ｐａｔｈメッセージに含まれた予約帯域情報を予約帯域情報更新処理３５に送る（図１９＜５＞）。また、Ｐａｔｈメッセージ分析制御処理３２は、予約帯域情報更新処理３５から、更新予約帯域情報を受け取る（図１９＜６＞）。当該処理は、Ｐａｔｈメッセージを送信先ノードＤＮへ向けて送信するにあたり、次ノードとの間でＰａｔｈメッセージに含まれた予約帯域情報中の帯域値をカバーできる空き帯域があるかどうかをチェックするために実行される。このため、自ノードが送信先ノードＤＮである場合には、当該処理は実行されない。
Ｐａｔｈメッセージ分析制御処理３２は、予約帯域情報更新処理３５から更新予約帯域情報を受信すると、Ｐａｔｈメッセージに含まれていた予約帯域情報で示される帯域の値と更新予約帯域情報で示される帯域の値との差分を計算する。計算の結果、差分が０の場合には、Ｐａｔｈメッセージ分析制御処理３２は、Ｐａｔｈメッセージ中の予約帯域情報中の帯域の値を更新しない。これに対し、差分がある場合には、Ｐａｔｈメッセージ分析制御処理３２は、Ｐａｔｈメッセージ中の予約帯域情報中の帯域の値を更新予約帯域情報で示される帯域の値に更新する。
その後、Ｐａｔｈメッセージ分析制御処理３２は、次ノードへＰａｔｈメッセージを送信する前に、転送元ＩＰカプセル化処理３７へカプセル化依頼を実行する（図１９＜７＞）。カプセル化依頼は、Ｐａｔｈメッセージを送信する通信Ｉ／Ｆ１１（ｅｔｈ）のＩＰアドレスをカプセル化するために行われる。但し、Ｐａｔｈメッセージの宛先が自身のノードでない場合には、カプセル化依頼は実行されない。
Ｐａｔｈメッセージ分析制御処理３２は、転送元ＩＰカプセル化処理３７から応答メッセージ（カプセル化の結果）を受け取る（図１９＜８＞）。また、差分が算出された場合には、差分値の帯域を不足予約帯域情報としてＲＡＭ１６に記憶する（図１９＜９＞）。
また、Ｐａｔｈメッセージ分析制御処理３２は、自ノードがロードバランシング実行ノードとなる場合には、Ｐａｔｈメッセージに含まれたＰａｔｈＩＤの識別番号を用いて、Ｐａｔｈメッセージを送信先ノードＤＮへ送るための次ノードを決定する。次ノードの決定は、経路表ＲＴの参照によって行われる。自ノードがロードバランシング実行ノードである場合には、経路表ＲＴに送信先ノードＤＮへ向かう複数の経路が登録されている。複数の経路から１つの経路を選択するために、識別番号が使用される。
また、Ｐａｔｈメッセージ分析制御処理３２は、自ノードがＰａｔｈメッセージの終端ノード（送信先ノードＤＮ）である場合には、Ｐａｔｈメッセージ中の必要帯域情報及び
予約帯域情報を終端制御処理４１へ送る（図１９＜１０＞）。
予約帯域情報を終端制御処理４１へ送る（図１９＜１０＞）。
また、Ｐａｔｈメッセージ分析制御処理３２は、ロードバランシング実施可否判断指示処理３８から、Ｐａｔｈメッセージを送信した前ノードの通信Ｉ／Ｆ１１のＩＰアドレスの問合せを受け取る（図１９＜１１＞）。この場合、Ｐａｔｈメッセージ分析制御処理３２は、該当するＩＰアドレスを含んだ応答をロードバランシング実施可否判断指示処理３８へ返す（図１９＜１２＞）。但し、帯域仮予約処理３３によって次ノードとの間で仮予約帯域が生成されていない場合には、Ｐａｔｈメッセージ分析制御処理３２は、仮予約帯域が生成されるまで応答を控える。
また、Ｐａｔｈメッセージ分析制御処理３２は、仮予約帯域幅更新処理３９から送信元ノードＳＮのＩＰアドレスの問合せを受け取る（図１９＜１３＞）。問合せは、仮予約帯域更新メッセージを送信元ノードＳＮへ送信するために行われる。問合せを受けたＰａｔｈメッセージ分析制御処理３２は、該当するＩＰアドレスを含んだ応答を仮予約帯域幅更新処理３９に返す（図１９＜１４＞）。
また、Ｐａｔｈメッセージ分析制御処理３２は、仮予約帯域全開放処理４３に対し、仮予約帯域全開放指示を与える（図１９＜１５＞）。
[帯域仮予約処理]
帯域仮予約処理３３は、Ｐａｔｈメッセージから受け取る予約帯域情報（図１９＜３＞）を元に、次ノードとの間で帯域の仮予約（仮予約帯域の生成）を実行する。このとき、仮予約のためのメッセージのやりとりがカーネルを介して行われる（図１９＜３ａ＞）。帯域仮予約処理３３は、次ノードとの間で帯域の仮予約がなされた場合、仮予約がなされた旨の応答をＰａｔｈメッセージ分析制御処理３２に通知する（図１９＜４＞）。
帯域仮予約処理３３は、Ｐａｔｈメッセージから受け取る予約帯域情報（図１９＜３＞）を元に、次ノードとの間で帯域の仮予約（仮予約帯域の生成）を実行する。このとき、仮予約のためのメッセージのやりとりがカーネルを介して行われる（図１９＜３ａ＞）。帯域仮予約処理３３は、次ノードとの間で帯域の仮予約がなされた場合、仮予約がなされた旨の応答をＰａｔｈメッセージ分析制御処理３２に通知する（図１９＜４＞）。
[ＯＳＰＦ-ＴＥ]
ＯＳＰＦ-ＴＥ３４は、自ノードと次ノードまでの間の空き帯域の計算を行う。
ＯＳＰＦ-ＴＥ３４は、自ノードと次ノードまでの間の空き帯域の計算を行う。
[予約帯域情報更新処理]
予約帯域情報更新処理３５は、Ｐａｔｈメッセージ分析制御処理３２からＰａｔｈメッセージ中の予約帯域情報を受け取る（図１９＜５＞）。また、予約帯域情報更新処理３５は、ＯＳＰＦ−ＴＥ３４で計算された次ノードまでの空き帯域情報を受け取る（図１９＜１６＞）。予約帯域情報更新処理３５は、予約帯域情報中の帯域値と空き帯域値との差分を計算する。
予約帯域情報更新処理３５は、Ｐａｔｈメッセージ分析制御処理３２からＰａｔｈメッセージ中の予約帯域情報を受け取る（図１９＜５＞）。また、予約帯域情報更新処理３５は、ＯＳＰＦ−ＴＥ３４で計算された次ノードまでの空き帯域情報を受け取る（図１９＜１６＞）。予約帯域情報更新処理３５は、予約帯域情報中の帯域値と空き帯域値との差分を計算する。
上記計算の結果、差分が０の場合には、予約帯域情報更新処理３５は、予約帯域情報中の帯域値の更新は行わず、予約帯域情報の帯域値と同じ値を格納した更新予約帯域情報をＰａｔｈメッセージ分析制御処理３２に送信する（図１９＜６＞）。差分がある場合には、予約帯域情報更新処理３５は、ＯＳＰＦ−ＴＥ３４から受け取った空き帯域の値を更新予約帯域情報の帯域値にセットしてＰａｔｈメッセージ分析制御処理３２に送信する（図１９＜６＞）。また、予約帯域情報更新処理３５は、更新予約帯域情報をロードバランシング実施可否判断処理３６へ送る（図１９＜６ａ＞）
[ＲＡＭ]
ＲＡＭ１６は、ＰａｔｈＩＤと不足予約帯域情報を記憶する。但し、自ノードが送信先ノードＤＮである場合には、必要帯域情報及び予約帯域情報も記憶する。もっとも、Ｐａｔｈメッセージの識別番号が“２”以上である場合（第ｘＰａｔｈメッセージである場合）には、当該Ｐａｔｈメッセージ中の必要帯域情報は保持しない。
[ＲＡＭ]
ＲＡＭ１６は、ＰａｔｈＩＤと不足予約帯域情報を記憶する。但し、自ノードが送信先ノードＤＮである場合には、必要帯域情報及び予約帯域情報も記憶する。もっとも、Ｐａｔｈメッセージの識別番号が“２”以上である場合（第ｘＰａｔｈメッセージである場合）には、当該Ｐａｔｈメッセージ中の必要帯域情報は保持しない。
[ロードバランシング実施可否判断処理]
ロードバランシング実施可否判断処理３６は、ロードバランシング実施可否判断を実行する。自ノードがロードバランシング実行ノードとして動作できない場合には、ロードバランシング実施可否判断処理３６は、ロードバランシング実施可否判断指示処理３８に対してロードバランシング実施可否判断実行指示を送る（図１９＜１７＞）。また、ロードバランシング実施可否判断処理３６は、仮予約帯域幅更新処理３９に対して仮予約更新指示を送る（図１９＜１８＞）。自ノードがロードバランシング実行ノードとして動作可能である場合には、ロードバランシング実施可否判断処理３６は、ロードバランシング処理４０に対して、ロードバランシング指示を与える（図１９＜１９＞）。
ロードバランシング実施可否判断処理３６は、ロードバランシング実施可否判断を実行する。自ノードがロードバランシング実行ノードとして動作できない場合には、ロードバランシング実施可否判断処理３６は、ロードバランシング実施可否判断指示処理３８に対してロードバランシング実施可否判断実行指示を送る（図１９＜１７＞）。また、ロードバランシング実施可否判断処理３６は、仮予約帯域幅更新処理３９に対して仮予約更新指示を送る（図１９＜１８＞）。自ノードがロードバランシング実行ノードとして動作可能である場合には、ロードバランシング実施可否判断処理３６は、ロードバランシング処理４０に対して、ロードバランシング指示を与える（図１９＜１９＞）。
[転送元ＩＰカプセル化処理]
転送先ＩＰカプセル化処理３７は、Ｐａｔｈメッセージ分析制御処理３２からカプセル化依頼を受け取る（図１９＜７＞）。すると、転送先ＩＰカプセル化処理３７は、Ｐａｔｈメッセージを次ノードに転送するときに、転送元となる通信Ｉ／Ｆ１１のＩＰアドレスをカプセル化する。転送先ＩＰカプセル化処理３７は、既に別のノードによってＩＰアドレスが１回以上カプセル化されている場合は、当該ＩＰアドレスの値を更新する。
転送先ＩＰカプセル化処理３７は、Ｐａｔｈメッセージ分析制御処理３２からカプセル化依頼を受け取る（図１９＜７＞）。すると、転送先ＩＰカプセル化処理３７は、Ｐａｔｈメッセージを次ノードに転送するときに、転送元となる通信Ｉ／Ｆ１１のＩＰアドレスをカプセル化する。転送先ＩＰカプセル化処理３７は、既に別のノードによってＩＰアドレスが１回以上カプセル化されている場合は、当該ＩＰアドレスの値を更新する。
[ロードバランシング実施可否判断指示処理]
ロードバランシング実施可否判断指示処理３８は、Ｐａｔｈメッセージ分析制御処理３２に対し、前ノードにおいてＰａｔｈメッセージを送信した通信Ｉ／Ｆ１１のＩＰアドレスを問い合わせる（図１９＜１１＞）。問い合わせに応じたＩＰアドレスがＰａｔｈメッセージ分析制御処理３２から得られると（図１９＜１２＞）、ロードバランシング実施可否判断指示処理３８は、得られたＩＰアドレスを宛先として、カーネルに対して、ロードバランシング実施可否判断指示メッセージの送信を指示する（図１９＜２０＞）。カーネルは、ロードバランシング実施可否判断指示メッセージを生成して送信する。
ロードバランシング実施可否判断指示処理３８は、Ｐａｔｈメッセージ分析制御処理３２に対し、前ノードにおいてＰａｔｈメッセージを送信した通信Ｉ／Ｆ１１のＩＰアドレスを問い合わせる（図１９＜１１＞）。問い合わせに応じたＩＰアドレスがＰａｔｈメッセージ分析制御処理３２から得られると（図１９＜１２＞）、ロードバランシング実施可否判断指示処理３８は、得られたＩＰアドレスを宛先として、カーネルに対して、ロードバランシング実施可否判断指示メッセージの送信を指示する（図１９＜２０＞）。カーネルは、ロードバランシング実施可否判断指示メッセージを生成して送信する。
ロードバランシング実施可否判断指示メッセージには、Ｐａｔｈメッセージが有する送信先ノードＤＮのＩＰアドレス情報、ＰａｔｈＩＤ、不足予約帯域情報が付与される。不足予約帯域情報は、ロードバランシング実施可否判断実行指示メッセージの送信元となったＰａｔｈメッセージの中継ノードＲＮが必要帯域に対して不足する帯域の大きさを示す情報である。
[仮予約帯域幅更新処理]
仮予約帯域幅更新処理３９は、ロードバランシング実施可否判断処理３６からの仮予約帯域幅更新指示の受信（図１９＜１８＞）を契機として、Ｐａｔｈメッセージ分析制御処理３２からＰａｔｈメッセージの送信元ＩＰアドレスを取得する（図１９＜１３＞，＜１４＞）。仮予約帯域幅更新処理３９は、カーネルに対して取得したＩＰアドレスを宛先とする仮予約帯域更新メッセージの送信を指示する（図１９＜２１＞）。カーネルは、仮予約帯域更新メッセージを生成して送信する。
仮予約帯域幅更新処理３９は、ロードバランシング実施可否判断処理３６からの仮予約帯域幅更新指示の受信（図１９＜１８＞）を契機として、Ｐａｔｈメッセージ分析制御処理３２からＰａｔｈメッセージの送信元ＩＰアドレスを取得する（図１９＜１３＞，＜１４＞）。仮予約帯域幅更新処理３９は、カーネルに対して取得したＩＰアドレスを宛先とする仮予約帯域更新メッセージの送信を指示する（図１９＜２１＞）。カーネルは、仮予約帯域更新メッセージを生成して送信する。
[ロードバランシング処理]
ロードバランシング処理４０は、ロードバランシング指示を受けて（図１９＜１９＞）、不等コストロードバランシングのバリアンス値を上げる。これによって、既存の送信先ノードＤＮへ向かう経路の次に小さいコスト値を持つ送信先ノードＤＮ行きの経路が経路表ＲＴに出現する。その後、ロードバランシング処理４０は、新しく経路表ＲＴに出現した経路を利用して、ロードバランシング終端発見メッセージの送信指示をカーネルに与える（図１９＜２２＞）。カーネルはロードバランシング終端発見メッセージを生成して送信する。
ロードバランシング処理４０は、ロードバランシング指示を受けて（図１９＜１９＞）、不等コストロードバランシングのバリアンス値を上げる。これによって、既存の送信先ノードＤＮへ向かう経路の次に小さいコスト値を持つ送信先ノードＤＮ行きの経路が経路表ＲＴに出現する。その後、ロードバランシング処理４０は、新しく経路表ＲＴに出現した経路を利用して、ロードバランシング終端発見メッセージの送信指示をカーネルに与える（図１９＜２２＞）。カーネルはロードバランシング終端発見メッセージを生成して送信する。
[終端制御処理]
終端制御処理４１は、Ｐａｔｈメッセージの受信ノードがＰａｔｈメッセージの終端ノ
ードである場合、すなわち、自ノードが送信先ノードＤＮである場合に起動する。終端制御処理４１は、Ｐａｔｈメッセージ分析制御処理３２からＰａｔｈメッセージ中の予約帯域情報及び必要帯域情報を受けて起動する（図１９＜１０＞）。
終端制御処理４１は、Ｐａｔｈメッセージの受信ノードがＰａｔｈメッセージの終端ノ
ードである場合、すなわち、自ノードが送信先ノードＤＮである場合に起動する。終端制御処理４１は、Ｐａｔｈメッセージ分析制御処理３２からＰａｔｈメッセージ中の予約帯域情報及び必要帯域情報を受けて起動する（図１９＜１０＞）。
終端制御処理４１は、必要帯域情報で示される帯域値（必要帯域）と予約帯域情報で示される帯域値（仮予約帯域）とが同じ値であり、且つＰａｔｈＩＤの識別番号が“１”である場合には、Ｒｅｓｖ制御処理４２へＲｅｓｖメッセージ送信指示を送る（図１９＜２３＞）。これに対し、必要帯域が仮予約帯域より大きい場合、或いは、識別番号が“２”以上で必要帯域と仮予約帯域とが同値である場合は、終端制御処理４１は、以下の処理を行う。
すなわち、終端制御処理４１は、過去に自ノードを経由したＰａｔｈメッセージのうち、同一のＭＡＣアドレスを有し且つ識別番号が異なるＰａｔｈＩＤを有していた複数のＰａｔｈメッセージの情報をＲＡＭ１６から得る（図１９＜２４＞）。続いて、終端制御部４１は、各Ｐａｔｈメッセージが有していた各予約帯域情報の帯域値（仮予約帯域）を加算し、加算結果（合計値）と必要帯域情報の帯域値（必要帯域）とを比較する。
比較結果において、仮予約帯域の合計値と必要帯域とが同値である場合には、終端制御処理４１は、Ｒｅｓｖ制御処理４２へＲｅｓｖメッセージ送信指示を与える（図１９＜２３＞）。これに対し、上記の比較結果において、仮予約帯域の合計値より必要帯域が大きい場合には、仮予約帯域の合計値及びＰａｔｈＩＤをＲＡＭ１６に記憶する（図１９＜２５＞）。このとき、必要帯域もＲＡＭ１６に記憶されるようにしても良い。そして、終端制御処理４１は、同一のＭＡＣアドレスを有し且つ識別番号が異なる他のＰａｔｈメッセージが受信されるのを待機し、該当のＰａｔｈメッセージが受信されると上記処理を行う。
[Ｒｅｓｖ制御処理]
Ｒｅｓｖ制御処理４２は、カーネルに対し、送信元ノードＳＮ向けのＲｅｓｖメッセージの送信指示を与える（図１９＜２６＞）。
Ｒｅｓｖ制御処理４２は、カーネルに対し、送信元ノードＳＮ向けのＲｅｓｖメッセージの送信指示を与える（図１９＜２６＞）。
なお、本実施形態では、既存のＲｅｓｖメッセージにＰａｔｈＩＤ情報が付加される（図５参照）。Ｒｅｓｖメッセージがロードバランシングを実施している中継ノードＲＮで受信された場合には、以下の処理が行われる。すなわち、当該中継ノードＲＮの経路表ＲＴに送信元ノードＳＮへ向かう経路が２以上登録されている場合には、Ｒｅｓｖメッセージに含まれたＰａｔｈＩＤの識別番号がチェックされ、Ｒｅｓｖメッセージの転送に利用する経路が選定される。
[仮予約帯域全開放処理]
仮予約帯域全開放処理４３は、自ノードがＰａｔｈメッセージの終端ノード（送信先ノードＤＮ）であり、且つＰａｔｈメッセージのＰａｔｈＩＤの識別番号が所定値（例えば５）を超過する場合に実行される。なお、自ノードが終端ノードで、且つＰａｔｈＩＤの識別番号が所定値以上のＰａｔｈメッセージが受信された場合には、Ｐａｔｈメッセージ分析制御処理３２は、仮予約帯域全開放指示を仮予約帯域全開放処理４３に与えるだけで、他の処理を行わない。所定値は適宜設定可能である。
仮予約帯域全開放処理４３は、自ノードがＰａｔｈメッセージの終端ノード（送信先ノードＤＮ）であり、且つＰａｔｈメッセージのＰａｔｈＩＤの識別番号が所定値（例えば５）を超過する場合に実行される。なお、自ノードが終端ノードで、且つＰａｔｈＩＤの識別番号が所定値以上のＰａｔｈメッセージが受信された場合には、Ｐａｔｈメッセージ分析制御処理３２は、仮予約帯域全開放指示を仮予約帯域全開放処理４３に与えるだけで、他の処理を行わない。所定値は適宜設定可能である。
仮予約帯域全開放処理４３は、これまでに終端ノードで受信された所定値の各Ｐａｔｈメッセージの通過経路を辿る形式で、送信元ノードＳＮへ所定値と同数の仮予約帯域全開放メッセージの送信指示をカーネルに与える（図１９＜２７＞）。
仮予約帯域全開放メッセージには、これまで受信してきた所定値のＰａｔｈメッセージ
に含まれていたＰａｔｈＩＤを含める。仮予約帯域全開放メッセージを受信した各中継ノードＲＮは、仮予約帯域全開放メッセージから対応するＰａｔｈＩＤを取得して、取得したＰａｔｈＩＤ用に仮予約した帯域を全開放する。
に含まれていたＰａｔｈＩＤを含める。仮予約帯域全開放メッセージを受信した各中継ノードＲＮは、仮予約帯域全開放メッセージから対応するＰａｔｈＩＤを取得して、取得したＰａｔｈＩＤ用に仮予約した帯域を全開放する。
仮予約帯域全開放メッセージを受信した中継ノードＲＮがロードバランシング実行ノードである場合には、当該中継ノードＲＮは、仮予約帯域の開放に加えて不等コストロードバランシングの停止も行う。
なお、送信元ノードＳＮは、仮予約帯域全開放メッセージを受信した場合には、所定の処理を行う。例えば、上述した“待時式帯域予約通信方式”を採用する、或いはベストエフォート型の通信に移行することが考えられる。
＜＜仮予約帯域更新メッセージ処理＞＞
図２０は、仮予約帯域更新メッセージ処理２２の詳細を模式的に示す図である。仮予約帯域更新メッセージ処理２２では、ＡＰＬ空間において、仮予約帯域更新メッセージ分析制御処理４５と、仮予約帯域更新処理３９と、帯域仮予約機能３３とが実行される。
図２０は、仮予約帯域更新メッセージ処理２２の詳細を模式的に示す図である。仮予約帯域更新メッセージ処理２２では、ＡＰＬ空間において、仮予約帯域更新メッセージ分析制御処理４５と、仮予約帯域更新処理３９と、帯域仮予約機能３３とが実行される。
[仮予約帯域更新メッセージ分析制御処理]
仮予約帯域更新メッセージ分析制御処理４５は、カーネル中の受信メッセージ分析処理２０から仮予約帯域更新メッセージを得る。仮予約帯域更新メッセージ分析制御処理４５は、仮予約帯域更新メッセージから仮予約帯域更新情報、ＰａｔｈＩＤを取り出し、仮予約帯域更新処理３９に送る（図２０＜１＞）。当該処理は、仮予約帯域更新メッセージの宛先が自ノードであるか否かと無関係に実行される。
仮予約帯域更新メッセージ分析制御処理４５は、カーネル中の受信メッセージ分析処理２０から仮予約帯域更新メッセージを得る。仮予約帯域更新メッセージ分析制御処理４５は、仮予約帯域更新メッセージから仮予約帯域更新情報、ＰａｔｈＩＤを取り出し、仮予約帯域更新処理３９に送る（図２０＜１＞）。当該処理は、仮予約帯域更新メッセージの宛先が自ノードであるか否かと無関係に実行される。
[仮予約帯域更新処理]
仮予約帯域更新処理３９は、ＯＳＰＦ−ＴＥ３４に対して空き帯域更新指示を送る（図２０＜２＞）。空き帯域更新指示は、仮予約帯域幅を更新する経路と、仮予約帯域の減少分とを含む。減少分は空き帯域となる。このため、空き帯域更新指示を受け取ったＯＳＰＦ−ＴＥ３４は、該当する経路に関して減少分だけ空き帯域を増加させる。
仮予約帯域更新処理３９は、ＯＳＰＦ−ＴＥ３４に対して空き帯域更新指示を送る（図２０＜２＞）。空き帯域更新指示は、仮予約帯域幅を更新する経路と、仮予約帯域の減少分とを含む。減少分は空き帯域となる。このため、空き帯域更新指示を受け取ったＯＳＰＦ−ＴＥ３４は、該当する経路に関して減少分だけ空き帯域を増加させる。
また、仮予約帯域更新処理３９は、帯域仮予約処理３３に対して、仮予約帯域更新指示を送る（図２０＜３＞）。仮予約帯域の識別はＰａｔｈＩＤで行う。このため、仮予約帯域更新指示には、仮予約帯域情報と更新対象のＰａｔｈＩＤとが含まれる。
[帯域仮予約処理]
帯域仮予約処理３３は、仮予約帯域更新指示を受けると、ＰａｔｈＩＤを用いて、仮予約帯域を変更するやりとりを次ノードとの間で行う。すなわち、帯域仮予約処理３３は、カーネルを介して、次ノードとの間で仮予約帯域を変更するためのメッセージのやりとりを行う（図２０＜４＞）。
帯域仮予約処理３３は、仮予約帯域更新指示を受けると、ＰａｔｈＩＤを用いて、仮予約帯域を変更するやりとりを次ノードとの間で行う。すなわち、帯域仮予約処理３３は、カーネルを介して、次ノードとの間で仮予約帯域を変更するためのメッセージのやりとりを行う（図２０＜４＞）。
＜＜ロードバランシング実施可否判断実行指示メッセージ処理＞＞
図２１は、ロードバランシング実施可否判断実行指示メッセージ処理２３（以下、「メッセージ処理２３」と表記）の詳細を模式的に示す図である。メッセージ処理２３では、ロードバランシング実施可否判断実行指示メッセージ分析制御処理４６（以下、「分析制御処理４６」と表記）と、ロードバランシング実施可否判断処理３６とが実行される。
図２１は、ロードバランシング実施可否判断実行指示メッセージ処理２３（以下、「メッセージ処理２３」と表記）の詳細を模式的に示す図である。メッセージ処理２３では、ロードバランシング実施可否判断実行指示メッセージ分析制御処理４６（以下、「分析制御処理４６」と表記）と、ロードバランシング実施可否判断処理３６とが実行される。
また、メッセージ処理２３では、ロードバランシング実施可否判断指示処理３８と、ロードバランシング処理４０と、ロードバランシング終端発見メッセージ送信処理４７と、バリアンス値強制変更処理４８と、経路表チェック処理４９とが実行される。
[ロードバランシング実施可否判断実行指示メッセージ分析制御処理]
分析制御処理４６は、ロードバランシング実施可否判断実行指示メッセージからＰａｔｈメッセージに含まれていた送信先ノードＤＮのＩＰアドレス及び不足予約帯域情報を取得する。分析制御処理４６は、送信先ノードＤＮのＩＰアドレスをロードバランシング実施可否判断処理３６に送る（図２１＜１＞）。また、分析制御処理４６は、不足予約帯域情報をＲＡＭ１６に記憶する（図２１＜２＞）。
分析制御処理４６は、ロードバランシング実施可否判断実行指示メッセージからＰａｔｈメッセージに含まれていた送信先ノードＤＮのＩＰアドレス及び不足予約帯域情報を取得する。分析制御処理４６は、送信先ノードＤＮのＩＰアドレスをロードバランシング実施可否判断処理３６に送る（図２１＜１＞）。また、分析制御処理４６は、不足予約帯域情報をＲＡＭ１６に記憶する（図２１＜２＞）。
[ロードバランシング実施可否判断処理]
ロードバランシング実施可否判断処理３８は、分析制御処理４６から送信先ノードＤＮのＩＰアドレスを取得すると、バリアンス値強制変更処理４８にロードバランシング指示を与える（図２１＜３＞）。ロードバランシング実施可否判断処理３８は、バリアンス値を強制的に大きくする不等コストロードバランシングを実施する。
ロードバランシング実施可否判断処理３８は、分析制御処理４６から送信先ノードＤＮのＩＰアドレスを取得すると、バリアンス値強制変更処理４８にロードバランシング指示を与える（図２１＜３＞）。ロードバランシング実施可否判断処理３８は、バリアンス値を強制的に大きくする不等コストロードバランシングを実施する。
これによって、経路表ＲＴに送信先ノードＤＮへ向かう経路が新規に出現した場合には、バリアンス値強制変更処理４８からの応答を受けて（図２１＜４＞）、ロードバランシング機能に対して、ロードバランシング指示を出す（図２１＜５＞）。
経路表ＲＴにおいて、送信先ノードＤＮへ向かう経路が新しく１つ出現した時点でバリアンス値の上昇は停止する。バリアンス値が上限まで上昇しても経路表ＲＴに送信先ノードＤＮへ向かう経路が出現しない場合には、ロードバランシング実施可否判断処理３６は、以下の処理を行う。
すなわち、ロードバランシング実施可否判断処理３６は、ロードバランシング実施可否判断指示処理３８に対して、ロードバランシング実施可否判断実行指示メッセージ送信指示を送る（図２１＜６＞）。これにより、Ｐａｔｈメッセージの経路上の前ノードにロードバランシング実施可否判断実行指示メッセージが送信される。
なお、バリアンス値強制変更処理４８によってバリアンス値が上昇する前に、送信先ノードＤＮへ向かう経路が既に経路表ＲＴに存在することがある。例えば、等コストロードバランシングが実施されていた場合に、複数の経路が存在することが考えられる。このような場合、ロードバランシング実施可否判断処理３６は、バリアンス値の変更は行わず、既に経路表ＲＴにある別経路を利用することを決定する。
[ロードバランシング実施可否判断指示処理]
ロードバランシング実施可否判断指示処理３８は、分析制御処理４６から前ノードのＩＰアドレスを問い合わせ（図２１＜７＞）、該当ＩＰアドレスを取得する（図２１＜８＞）。すると、ロードバランシング実施可否判断指示処理３８は、カーネルに対して、該当ＩＰアドレス（前ノード）へロードバランシング実施可否判断指示メッセージを送信するように指示する（図２１＜９＞）。
ロードバランシング実施可否判断指示処理３８は、分析制御処理４６から前ノードのＩＰアドレスを問い合わせ（図２１＜７＞）、該当ＩＰアドレスを取得する（図２１＜８＞）。すると、ロードバランシング実施可否判断指示処理３８は、カーネルに対して、該当ＩＰアドレス（前ノード）へロードバランシング実施可否判断指示メッセージを送信するように指示する（図２１＜９＞）。
[ロードバランシング処理]
ロードバランシング処理４０は、ロードバランシング実施可否判断処理３６からのロードバランシング指示を受けて、ロードバランシング終端発見メッセージ送信処理４７にロードバランシング終端発見メッセージの送信指示を送る（図２１＜１０＞）。
ロードバランシング処理４０は、ロードバランシング実施可否判断処理３６からのロードバランシング指示を受けて、ロードバランシング終端発見メッセージ送信処理４７にロードバランシング終端発見メッセージの送信指示を送る（図２１＜１０＞）。
[ロードバランシング終端発見メッセージ送信処理]
ロードバランシング終端発見メッセージ送信処理４７は、ロードバランシング処理４０から、ロードバランシング終端発見メッセージの送信指示を受け取る（図２１＜１０＞）。すると、ロードバランシング終端発見メッセージ送信処理４７は、別経路を利用して送信先ノードＤＮへロードバランシング終端発見メッセージの送信する指示をカーネルに与
える（図２１＜１１＞）。
ロードバランシング終端発見メッセージ送信処理４７は、ロードバランシング処理４０から、ロードバランシング終端発見メッセージの送信指示を受け取る（図２１＜１０＞）。すると、ロードバランシング終端発見メッセージ送信処理４７は、別経路を利用して送信先ノードＤＮへロードバランシング終端発見メッセージの送信する指示をカーネルに与
える（図２１＜１１＞）。
別経路は、バリアンス値の上昇によって経路表ＲＴに出現した別経路、或いはバリアンス値変更前に経路表ＲＴに存在していた別経路である。なお、ロードバランシング終端発見メッセージには、ロードバランシング実施可否判断実行指示メッセージに含まれていたＰａｔｈＩＤが含められる。
＜＜ロードバランシング終端発見メッセージ処理＞＞
図２２は、ロードバランシング終端発見メッセージ処理２４（以下、「メッセージ処理２４」と表記）の詳細を模式的に示す図である。メッセージ処理２４では、ロードバランシング終端発見メッセージ分析制御処理５０（以下、「分析制御処理５０」と表記）と、ＰａｔｈＩＤ問い合わせ処理５１とが実行される。
図２２は、ロードバランシング終端発見メッセージ処理２４（以下、「メッセージ処理２４」と表記）の詳細を模式的に示す図である。メッセージ処理２４では、ロードバランシング終端発見メッセージ分析制御処理５０（以下、「分析制御処理５０」と表記）と、ＰａｔｈＩＤ問い合わせ処理５１とが実行される。
また、メッセージ処理２４では、ロードバランシング実行履歴チェック処理５２と、経路表チェック処理５３と、強制バリアンス変更処理４８と、別経路メンババス発見成功メッセージ送信指示処理５４とが実行される。さらに、メッセージ処理では、ロードバランシング終端発見メッセージ転送処理５５と、別経路メンバパス発見指示メッセージ送信処理５６とが実行される。
[ロードバランシング終端発見メッセージ分析制御処理]
分析制御処理５０は、受信メッセージ分析部２０からロードバランシング終端発見メッセージ（以下、「終端発見メッセージ」ともいう）を得る。分析制御処理５０は、終端発見メッセージ中のＰａｔｈＩＤを取得し、ＰａｔｈＩＤ問い合わせ処理５１（以下「問い合わせ処理５１」とも表記）に送る（図２２＜１＞）。分析制御処理５０は、問い合わせ処理５１、又はロードバランシング実行履歴チェック処理５２（以下、「チェック処理５２」とも表記）から問合せの応答を受け取る（図２２＜２＞，図２２＜３＞）。
分析制御処理５０は、受信メッセージ分析部２０からロードバランシング終端発見メッセージ（以下、「終端発見メッセージ」ともいう）を得る。分析制御処理５０は、終端発見メッセージ中のＰａｔｈＩＤを取得し、ＰａｔｈＩＤ問い合わせ処理５１（以下「問い合わせ処理５１」とも表記）に送る（図２２＜１＞）。分析制御処理５０は、問い合わせ処理５１、又はロードバランシング実行履歴チェック処理５２（以下、「チェック処理５２」とも表記）から問合せの応答を受け取る（図２２＜２＞，図２２＜３＞）。
分析制御処理５０は、応答の内容に従って、バリアンス値強制変更処理４８，ロードバランシング終端発見メッセージ転送処理５５，及び別経路メンバパス発見指示メッセージ送信処理５６へ指示を送信する。
すなわち、分析制御処理５０は、バリアンス値強制変更処理４８（以下、「変更処理４８」とも表記）に対しては、終端発見メッセージの送信元ＩＰアドレスを含む指示を与える（図２２＜４＞）。また、分析制御処理５０は、ロードバランシング終端発見メッセージ転送処理５５（以下、「転送処理５５」とも表記）に対しては、終端発見メッセージの転送指示を与える（図２２＜５＞）。そして、分析制御処理５０は、別経路メンバパス発見指示メッセージ送信処理５６（以下、「送信処理５６」とも表記）に対しては、ロードバランシング終端発見メッセージの送信元ＩＰアドレスを含む指示を与える（図２２＜６＞）。
[ＰａｔｈＩＤ問い合わせ処理]
問い合わせ処理５１は、分析制御処理５０から受けたＰａｔｈＩＤ、すなわち、終端発見メッセージ中のＰａｔｈＩＤと同値のＰａｔｈＩＤがＲＡＭ１６に記憶されているか否かを確認する（図２２＜７＞，＜８＞）。
問い合わせ処理５１は、分析制御処理５０から受けたＰａｔｈＩＤ、すなわち、終端発見メッセージ中のＰａｔｈＩＤと同値のＰａｔｈＩＤがＲＡＭ１６に記憶されているか否かを確認する（図２２＜７＞，＜８＞）。
同値のＰａｔｈＩＤが記憶されていた場合には、問い合わせ処理５１は、チェック処理５２（以下、「チェック処理５２」とも表記）に対して、実行履歴の有無のチェックを要求する（図２２＜７ａ＞）。対象の実行履歴は、同一のＰａｔｈＩＤを有するＰａｔｈメッセージに基づき過去に実行されたロードバランシング実施可否判断処理（以下、「実施可否判断」とも表記）の実行履歴である。
問い合わせ処理５１は、同値のＰａｔｈＩＤが記憶されていなかったときには、分析制御処理５０に対して、転送処理５５へ終端発見メッセージの転送を要求する旨の指示を送る（図２２＜２＞）。
[ロードバランシング実行履歴チェック処理]
チェック処理５２は、対象の実行履歴の有無をチェックする。実行履歴がない場合には、変更処理４８へ終端発見メッセージの送信元ノードのＩＰアドレスを送信する旨の指示を分析制御処理５０に送る（図２２＜３＞）。自ノードをロードバランシングの終端とするためである。
チェック処理５２は、対象の実行履歴の有無をチェックする。実行履歴がない場合には、変更処理４８へ終端発見メッセージの送信元ノードのＩＰアドレスを送信する旨の指示を分析制御処理５０に送る（図２２＜３＞）。自ノードをロードバランシングの終端とするためである。
実行履歴があった場合には、チェック処理５２は、別経路メンバパス発見指示メッセージ送信処理５６（以下、「送信処理５６」とも表記）へ終端発見メッセージの送信元ノードのＩＰアドレスを送信する旨の指示を分析制御処理５０に送る（図２２＜３＞）。
[ロードバランシング終端発見メッセージ転送処理]
転送処理５５は、経路表ＲＴを参照して、終端発見メッセージを次ノードへ転送する命令をカーネルに与える（図２２＜５ａ＞）。転送の際には、転送処理５５は、当該終端発見メッセージの転送の履歴を当該終端発見メッセージ中のＰａｔｈＩＤとセットで保持する。
転送処理５５は、経路表ＲＴを参照して、終端発見メッセージを次ノードへ転送する命令をカーネルに与える（図２２＜５ａ＞）。転送の際には、転送処理５５は、当該終端発見メッセージの転送の履歴を当該終端発見メッセージ中のＰａｔｈＩＤとセットで保持する。
[バリアンス値強制変更処理]
変更処理４８は、不等コストロードバランシングのバリアンス値を強制的に上昇させる（図２２＜９ａ＞）。ただし、変更処理４８は、バリアンス値の上昇前に経路表ＲＴに登録されていた送信元ノードＤＮへ向かう経路を記憶しておく。バリアンス値の上昇は、所望の別経路が経路表ＲＴに出現するまで継続される。変更処理４８は、所望の別経路が経路表ＲＴに出現したか否かは、経路表チェック処理５３の経路表のチェック結果を随時受け取ることを通じて判断する（図２２＜９ｂ＞，＜９ｃ＞）。
変更処理４８は、不等コストロードバランシングのバリアンス値を強制的に上昇させる（図２２＜９ａ＞）。ただし、変更処理４８は、バリアンス値の上昇前に経路表ＲＴに登録されていた送信元ノードＤＮへ向かう経路を記憶しておく。バリアンス値の上昇は、所望の別経路が経路表ＲＴに出現するまで継続される。変更処理４８は、所望の別経路が経路表ＲＴに出現したか否かは、経路表チェック処理５３の経路表のチェック結果を随時受け取ることを通じて判断する（図２２＜９ｂ＞，＜９ｃ＞）。
[経路表チェック処理]
経路表チェック処理５３は、変更処理４８によるバリアンス値の上昇中における経路表ＲＴを監視し、終端発見メッセージの送信元ノード及びＰａｔｈメッセージの送信元ノードＳＮへそれぞれ向かう別経路が経路表ＲＴに出現しているかをチェックする。別経路が経路表ＲＴに出現すると、その旨を変更処理４８に伝える（図２２＜９ｃ＞）。
経路表チェック処理５３は、変更処理４８によるバリアンス値の上昇中における経路表ＲＴを監視し、終端発見メッセージの送信元ノード及びＰａｔｈメッセージの送信元ノードＳＮへそれぞれ向かう別経路が経路表ＲＴに出現しているかをチェックする。別経路が経路表ＲＴに出現すると、その旨を変更処理４８に伝える（図２２＜９ｃ＞）。
変更処理４８は、別経路の出現がチェック処理５３から通知されると、別経路メンバパス発見成功メッセージ送信指示処理５４（以下、「送信指示処理５４」とも表記）へ別経路メンバパス発見成功メッセージの送信指示を与える（図２２＜１０＞）。
[別経路メンバパス発見成功メッセージ送信指示処理]
送信指示処理５４は、送信指示を変更処理４８から受け取ると、別経路メンバパス発見成功メッセージ（以下、「発見成功メッセージ」とも表記）の送信命令をカーネルに与える（図２２＜１１＞）。カーネルは、発見成功メッセージを別経路（終端発見メッセージを送信した中継ノードＲＮ）へ送信する。
送信指示処理５４は、送信指示を変更処理４８から受け取ると、別経路メンバパス発見成功メッセージ（以下、「発見成功メッセージ」とも表記）の送信命令をカーネルに与える（図２２＜１１＞）。カーネルは、発見成功メッセージを別経路（終端発見メッセージを送信した中継ノードＲＮ）へ送信する。
発見成功メッセージは、Ｐａｔｈメッセージの経由してきた経路を通って終端発見メッセージを送信した中継ノードＲＮに到達する可能性がある。もっとも、発見成功メッセージが終端発見メッセージを送信した中継ノードＲＮで受信されれば良いので、経路の相違は問題とならない。発見成功メッセージには、終端発見メッセージ中のＰａｔｈＩＤが含められる。
[別経路メンバパス発見指示メッセージ送信処理]
送信処理５６は、分析制御処理５０からの指示を受けて（図２２＜６＞）、終端発見メッセージの送信元の中継ノードＲＮへ別経路メンバパス発見指示メッセージ（以下、「発見指示メッセージ」とも表記）へ送る命令をカーネルに与える（図２２＜１２＞）。このとき、発見指示メッセージには、終端発見メッセージ中のＰａｔｈＩＤが含められる。
送信処理５６は、分析制御処理５０からの指示を受けて（図２２＜６＞）、終端発見メッセージの送信元の中継ノードＲＮへ別経路メンバパス発見指示メッセージ（以下、「発見指示メッセージ」とも表記）へ送る命令をカーネルに与える（図２２＜１２＞）。このとき、発見指示メッセージには、終端発見メッセージ中のＰａｔｈＩＤが含められる。
＜＜別経路メンバパス発見成功メッセージ処理＞＞
図２３は、別経路メンバパス発見成功メッセージ処理２５（以下、「メッセージ処理２５」と表記）の詳細を模式的に示す図である。メッセージ処理２５では、別経路メンバパス発見成功メッセージ分析制御処理５８（以下、「分析制御処理５８」と表記）と、経路表識別番号付与処理５９（以下、「付与処理５９」とも表記）とが実行される。
図２３は、別経路メンバパス発見成功メッセージ処理２５（以下、「メッセージ処理２５」と表記）の詳細を模式的に示す図である。メッセージ処理２５では、別経路メンバパス発見成功メッセージ分析制御処理５８（以下、「分析制御処理５８」と表記）と、経路表識別番号付与処理５９（以下、「付与処理５９」とも表記）とが実行される。
また、メッセージ処理２５では、識別番号問い合わせ処理６０（以下、「問い合わせ処理６０」とも表記）と、第ｘＰａｔｈメッセージ送信指示処理６１（以下、「送信指示処理６１」とも表記）とが実行される。
[別経路メンバパス発見成功メッセージ分析制御処理]
分析制御処理５８は、自ノード宛ての発見成功メッセージを受信メッセージ分析処理２０から得る。分析制御処理５８は、経路表ＲＴにある送信先ノードＤＮへ向かう経路のうち、終端発見メッセージの送信元のノード経由で送信先ノードＤＮへ向かう経路（別経路）に対して識別番号を割り振る指示を付与処理５９に与える（図２３＜１＞）。
分析制御処理５８は、自ノード宛ての発見成功メッセージを受信メッセージ分析処理２０から得る。分析制御処理５８は、経路表ＲＴにある送信先ノードＤＮへ向かう経路のうち、終端発見メッセージの送信元のノード経由で送信先ノードＤＮへ向かう経路（別経路）に対して識別番号を割り振る指示を付与処理５９に与える（図２３＜１＞）。
また、分析制御処理５８は、発見成功メッセージ中のＰａｔｈＩＤと関連づけられた不足予約帯域情報をＲＡＭ１６から読み出す（図２３＜２＞，＜３＞）。続いて、分析制御処理５８は、発見成功メッセージ中のＰａｔｈＩＤ，送信元ノードＳＮのＩＰアドレス，及び不足予約帯域情報を送信指示処理６１に通知する（図２３＜４＞）。
[経路表識別番号付与処理]
付与処理５９は、分析制御処理５８からの指示を得て、別経路に設定する識別番号を問い合わせ処理６０に問い合わせる（図２３＜５＞）。付与処理５９は、問い合わせに対する応答として、識別番号を得る（図２３＜６＞）。付与処理は、経路表ＲＴ上の別経路に対して識別番号を付与する命令をカーネルに与える（図２３＜７＞）。これによって、別経路に識別番号が付与（設定）される（図１１参照）。なお、経路表ＲＴにおけるＰａｔｈメッセージの転送経路に該当する経路には、既に識別番号が付与されているものとする。
付与処理５９は、分析制御処理５８からの指示を得て、別経路に設定する識別番号を問い合わせ処理６０に問い合わせる（図２３＜５＞）。付与処理５９は、問い合わせに対する応答として、識別番号を得る（図２３＜６＞）。付与処理は、経路表ＲＴ上の別経路に対して識別番号を付与する命令をカーネルに与える（図２３＜７＞）。これによって、別経路に識別番号が付与（設定）される（図１１参照）。なお、経路表ＲＴにおけるＰａｔｈメッセージの転送経路に該当する経路には、既に識別番号が付与されているものとする。
[識別番号問い合わせ処理]
問い合わせ処理６０は、付与処理５９からの問合せを受けて、識別番号問い合わせメッセージの送信命令をカーネルに与える（図２３＜８＞）。カーネルは、識別番号問い合わせメッセージを送信元ノードＳＮに送り、識別番号を含む応答を受信すると、問い合わせ処理６０に与える（図２３＜９＞）。問い合わせ処理６０は、カーネルから得た識別番号の値に１を加算した新たな識別番号を生成し、問い合わせに対する応答として付与処理５９に送る（図２３＜６＞）。
問い合わせ処理６０は、付与処理５９からの問合せを受けて、識別番号問い合わせメッセージの送信命令をカーネルに与える（図２３＜８＞）。カーネルは、識別番号問い合わせメッセージを送信元ノードＳＮに送り、識別番号を含む応答を受信すると、問い合わせ処理６０に与える（図２３＜９＞）。問い合わせ処理６０は、カーネルから得た識別番号の値に１を加算した新たな識別番号を生成し、問い合わせに対する応答として付与処理５９に送る（図２３＜６＞）。
[第ｘＰａｔｈメッセージ送信指示処理]
送信指示処理６１は、ＰａｔｈＩＤ、送信元ノードＳＮのＩＰアドレス，不足予約帯域情報を分析制御処理５８から受け取ったときに、送信元ノードＳＮへ第ｘＰａｔｈメッセージ送信指示メッセージへ送信する命令をカーネルに与える（図２３＜１０＞）。カーネルは、第ｘＰａｔｈメッセージ送信指示メッセージを送信元ノードＳＮへ送信する。第ｘ
Ｐａｔｈメッセージ送信指示メッセージには、ＰａｔｈＩＤ，必要帯域情報と予約帯域情報とが含まれる。必要帯域情報及び予約帯域情報として、不足予約帯域情報の値が設定される。
送信指示処理６１は、ＰａｔｈＩＤ、送信元ノードＳＮのＩＰアドレス，不足予約帯域情報を分析制御処理５８から受け取ったときに、送信元ノードＳＮへ第ｘＰａｔｈメッセージ送信指示メッセージへ送信する命令をカーネルに与える（図２３＜１０＞）。カーネルは、第ｘＰａｔｈメッセージ送信指示メッセージを送信元ノードＳＮへ送信する。第ｘ
Ｐａｔｈメッセージ送信指示メッセージには、ＰａｔｈＩＤ，必要帯域情報と予約帯域情報とが含まれる。必要帯域情報及び予約帯域情報として、不足予約帯域情報の値が設定される。
＜＜第ｘＰａｔｈメッセージ送信指示メッセージ処理＞＞
図２４は、第ｘＰａｔｈメッセージ送信指示メッセージ処理２６の詳細を模式的に示す図である。図２４において、第ｘＰａｔｈメッセージ送信指示メッセージ処理２６（以下、「メッセージ処理２６」とも表記）では、第ｘＰａｔｈメッセージ送信指示メッセージ分析制御処理６３（以下、「分析制御処理６３」とも表記）が実行される。
図２４は、第ｘＰａｔｈメッセージ送信指示メッセージ処理２６の詳細を模式的に示す図である。図２４において、第ｘＰａｔｈメッセージ送信指示メッセージ処理２６（以下、「メッセージ処理２６」とも表記）では、第ｘＰａｔｈメッセージ送信指示メッセージ分析制御処理６３（以下、「分析制御処理６３」とも表記）が実行される。
また、メッセージ処理２６では、Ｐａｔｈメッセージ送信処理６４（以下、「送信処理６４」とも表記）と、第ｘＰａｔｈメッセージ送信指示メッセージ転送処理６５（以下、「転送処理６５」とも表記）とが実行される。
[第ｘＰａｔｈメッセージ送信指示メッセージ分析制御処理]
分析制御処理６３は、受信メッセージ分析処理２０から第ｘＰａｔｈメッセージ送信指示メッセージを得る。分析制御処理は、第ｘＰａｔｈメッセージ送信指示メッセージの宛先をチェックする。当該メッセージの宛先が自ノードである場合には、分析制御処理６３は、当該メッセージからＰａｔｈＩＤを取り出して送信処理６４へ送信する（図２４＜１＞）。当該メッセージの宛先が自ノードでない場合には、分析制御処理６３は、当該メッセージに対して何らの処理を行うことなく、第ｘＰａｔｈメッセージ転送処理６５へ送信する（図２４＜２＞）。
分析制御処理６３は、受信メッセージ分析処理２０から第ｘＰａｔｈメッセージ送信指示メッセージを得る。分析制御処理は、第ｘＰａｔｈメッセージ送信指示メッセージの宛先をチェックする。当該メッセージの宛先が自ノードである場合には、分析制御処理６３は、当該メッセージからＰａｔｈＩＤを取り出して送信処理６４へ送信する（図２４＜１＞）。当該メッセージの宛先が自ノードでない場合には、分析制御処理６３は、当該メッセージに対して何らの処理を行うことなく、第ｘＰａｔｈメッセージ転送処理６５へ送信する（図２４＜２＞）。
[Ｐａｔｈメッセージ送信処理]
Ｐａｔｈメッセージ送信処理６４は、分析制御処理６３から受け取ったＰａｔｈＩＤを含む新規のＰａｔｈメッセージ（第ｘＰａｔｈメッセージ）を作成し、第ｘＰａｔｈメッセージの送信命令をカーネルに与える（図２４＜３＞）。第ｘＰａｔｈメッセージの必要帯域情報及び予約帯域情報の各値として、第ｘＰａｔｈメッセージ送信指示メッセージに含まれていた必要帯域情報及び予約帯域情報の各値が設定される。
Ｐａｔｈメッセージ送信処理６４は、分析制御処理６３から受け取ったＰａｔｈＩＤを含む新規のＰａｔｈメッセージ（第ｘＰａｔｈメッセージ）を作成し、第ｘＰａｔｈメッセージの送信命令をカーネルに与える（図２４＜３＞）。第ｘＰａｔｈメッセージの必要帯域情報及び予約帯域情報の各値として、第ｘＰａｔｈメッセージ送信指示メッセージに含まれていた必要帯域情報及び予約帯域情報の各値が設定される。
[第ｘＰａｔｈメッセージ送信指示メッセージ転送処理]
転送処理６５は、分析制御処理６３から第ｘＰａｔｈメッセージ送信指示メッセージを受信すると、当該メッセージの転送命令をカーネルに与える。これによって、第ｘＰａｔｈメッセージ送信指示メッセージは次ノードへ転送される。
転送処理６５は、分析制御処理６３から第ｘＰａｔｈメッセージ送信指示メッセージを受信すると、当該メッセージの転送命令をカーネルに与える。これによって、第ｘＰａｔｈメッセージ送信指示メッセージは次ノードへ転送される。
＜＜別経路メンバパス発見指示メッセージ処理＞＞
図２５は、別経路メンバパス発見指示メッセージ処理２７の詳細を模式的に示す図である。図２５において、別経路メンバパス発見指示メッセージ処理２７（以下、「メッセージ処理２７」とも表記する）では、別経路メンバパス発見指示メッセージ分析制御処理６７（以下、「分析制御処理６７」とも表記する）が実行される。
図２５は、別経路メンバパス発見指示メッセージ処理２７の詳細を模式的に示す図である。図２５において、別経路メンバパス発見指示メッセージ処理２７（以下、「メッセージ処理２７」とも表記する）では、別経路メンバパス発見指示メッセージ分析制御処理６７（以下、「分析制御処理６７」とも表記する）が実行される。
また、メッセージ処理２７では、ロードバランシング実施可否判断処理３６（以下、「判断処理３６」とも表記）と、参照経路選定処理６９（以下、「選定処理６９」とも表記）と、変更処理４８と、チェック処理５３とが実行される。
さらに、メッセージ処理２７では、ロードバランシング終端発見メッセージ送信処理７０（以下、「送信処理７０」とも表記）と、別経路メンバパス発見指示メッセージ転送処理７１（以下、「転送処理７１」とも表記）と、送信元ＩＰ隠蔽処理７２とが実行される。
[別経路メンバパス発見指示メッセージ分析制御処理]
分析制御処理６７は、別経路メンバパス発見指示メッセージ（発見指示メッセージ）を受信メッセージ分析処理２０から得る。分析処理部６７は、自ノードで保持されている、自ノードが過去に送信したロードバランシング終端発見メッセージ（終端発見メッセージ）の送信履歴を取得する（例えばＲＡＭ１６から読み出す）。
分析制御処理６７は、別経路メンバパス発見指示メッセージ（発見指示メッセージ）を受信メッセージ分析処理２０から得る。分析処理部６７は、自ノードで保持されている、自ノードが過去に送信したロードバランシング終端発見メッセージ（終端発見メッセージ）の送信履歴を取得する（例えばＲＡＭ１６から読み出す）。
分析制御処理６７は、発見指示メッセージ中のＰａｔｈメッセージと送信履歴に残っている終端発見メッセージのＰａｔｈＩＤとを照合し、両者が一致したら、終端発見メッセージの送信に利用した送信先ノードＤＮのＩＰアドレスを得る。分析制御処理６７は、当該ＩＰアドレスを判断処理３６へ送る（図２５＜１＞）。
[ロードバランシング実施可否判断処理]
分析制御処理６７から得られたＩＰアドレスへ向かうセグメント（経路）は、既に経路表ＲＴにある。このため、判断処理３６は、当該経路と別経路をバリアンス値強制変更処理４８によって経路表ＲＴに出現させることを試行する（図２５＜２＞，＜３＞）。変更処理４８及びチェック処理５３の内容は、メッセージ処理２４での処理と同様であるので説明を省略する。
分析制御処理６７から得られたＩＰアドレスへ向かうセグメント（経路）は、既に経路表ＲＴにある。このため、判断処理３６は、当該経路と別経路をバリアンス値強制変更処理４８によって経路表ＲＴに出現させることを試行する（図２５＜２＞，＜３＞）。変更処理４８及びチェック処理５３の内容は、メッセージ処理２４での処理と同様であるので説明を省略する。
経路表ＲＴに別経路が出現した場合には、判断処理３６は、参照経路選定処理６９に参照経路選定指示を送る（図２５＜４＞）。これに対し、別経路が出現しなかった場合には、判断処理３６は、転送処理７１に対し、別経路メンバパス発見指示メッセージ転送要求を送る（図２５＜５＞）。
[別経路メンバパス発見指示メッセージ転送処理]
転送処理７１は、判断処理３６からの別経路メンバパス発見指示メッセージ転送要求を受けると、終端発見メッセージの送信元ノードのＩＰアドレスを分析制御処理６７に問い合わせ（図２５＜６＞）、該当するＩＰアドレスを分析制御処理６７から得る（図２５＜７＞）。転送処理７１は、別経路メンバパス発見指示メッセージの転送指示をカーネルに与える（図２５＜８＞）。転送指示は、終端発見メッセージの送信元ノード、すなわち終端発見メッセージを送信したノードに１ホップ近いノード（終端発見メッセージの転送経路における前ノード）へ送られる。
転送処理７１は、判断処理３６からの別経路メンバパス発見指示メッセージ転送要求を受けると、終端発見メッセージの送信元ノードのＩＰアドレスを分析制御処理６７に問い合わせ（図２５＜６＞）、該当するＩＰアドレスを分析制御処理６７から得る（図２５＜７＞）。転送処理７１は、別経路メンバパス発見指示メッセージの転送指示をカーネルに与える（図２５＜８＞）。転送指示は、終端発見メッセージの送信元ノード、すなわち終端発見メッセージを送信したノードに１ホップ近いノード（終端発見メッセージの転送経路における前ノード）へ送られる。
[参照経路選定処理]
参照経路選定処理６９は、参照経路選定指示を受信したとき、バリアンス値の上昇によって経路表ＲＴに出現した経路へのロードバランシング終端発見メッセージの送信指示を送信処理７０に与える（図２５＜９＞）。
参照経路選定処理６９は、参照経路選定指示を受信したとき、バリアンス値の上昇によって経路表ＲＴに出現した経路へのロードバランシング終端発見メッセージの送信指示を送信処理７０に与える（図２５＜９＞）。
但し、参照経路選定処理６９は、送信指示を送る前に、送信先ＩＰ隠蔽処理７２を利用して、これから送信するロードバランシング終端発見メッセージの送信元ＩＰアドレスを、本来のロードバランシング終端発見メッセージを送信した中継ノードＲＮのＩＰアドレスに設定する（図２５＜１０＞，＜１１＞）。
このような処理を行う理由は以下の通りである。すなわち、送信元ＩＰアドレスの変更を行わない場合には、ロードバランシング終端ノードと本来のロードバランシング終端発見メッセージを送信したノード（ロードバランシング開始ノード）との間でロードバランシングが実行できなくなってしまうからである。
[送信元ＩＰ隠蔽処理]
送信元ＩＰ隠蔽処理７２は、ロードバランシング終端発見メッセージの送信元ＩＰアドレスを、本来の（元々の）ロードバランシング終端発見メッセージを送信したノードのＩ
Ｐアドレスに変更する処理を行う。
送信元ＩＰ隠蔽処理７２は、ロードバランシング終端発見メッセージの送信元ＩＰアドレスを、本来の（元々の）ロードバランシング終端発見メッセージを送信したノードのＩ
Ｐアドレスに変更する処理を行う。
[ロードバランシング終端発見メッセージ送信処理]
送信処理７０は、選定処理６９からの送信指示を受け取ったときに、ロードバランシング終端発見メッセージの送信命令をカーネルに送る（図２５＜１２＞）。これによって、ロードバランシング終端発見メッセージが送信される（図１０参照）。
送信処理７０は、選定処理６９からの送信指示を受け取ったときに、ロードバランシング終端発見メッセージの送信命令をカーネルに送る（図２５＜１２＞）。これによって、ロードバランシング終端発見メッセージが送信される（図１０参照）。
＜＜第ｘＰａｔｈメッセージ処理＞＞
図２６は、第ｘＰａｔｈメッセージ処理２８の詳細を模式的に示す図である。第ｘＰａｔｈメッセージ処理２８は、Ｐａｔｈメッセージ処理２１（図１９）の一部であり、第ｘＰａｔｈメッセージ（ｘ≧２）を受信したロードバランシング開始ノードで実行を要する処理群である。
図２６は、第ｘＰａｔｈメッセージ処理２８の詳細を模式的に示す図である。第ｘＰａｔｈメッセージ処理２８は、Ｐａｔｈメッセージ処理２１（図１９）の一部であり、第ｘＰａｔｈメッセージ（ｘ≧２）を受信したロードバランシング開始ノードで実行を要する処理群である。
第ｘＰａｔｈメッセージ処理２８（以下、「メッセージ処理２８」とも表記する）では、第ｘＰａｔｈメッセージ分析制御処理７４（以下、「分析制御処理７４」とも表記する）が実行される。また、メッセージ処理２８では、経路表送信先セグメント数確認処理７５（以下、「確認処理７５」とも表記）と、ＰａｔｈＩＤ識別番号確認処理７６（以下、「確認処理７６」とも表記）と、参照経路表選定処理７７（以下、「選定処理７７」とも表記）とが実行される。
[第ｘＰａｔｈメッセージ分析制御処理]
分析制御処理７４は、受信メッセージ分析処理２０から第ｘＰａｔｈメッセージを得る。分析制御処理７４は、第ｘＰａｔｈメッセージを得ると、自ノードの経路表ＲＴに存在する、送信先ノードＤＮへ向かうセグメント（経路）数の確認指示を確認処理７５に与える（図２６＜１＞）。
分析制御処理７４は、受信メッセージ分析処理２０から第ｘＰａｔｈメッセージを得る。分析制御処理７４は、第ｘＰａｔｈメッセージを得ると、自ノードの経路表ＲＴに存在する、送信先ノードＤＮへ向かうセグメント（経路）数の確認指示を確認処理７５に与える（図２６＜１＞）。
分析制御処理７４は、確認処理７５からの応答（経路数）を受ける（図２６＜２＞）。経路数が２以上である場合には、第ｘＰａｔｈメッセージ中のＰａｔｈＩＤの識別番号（識別番号≧２）を確認処理７６に送る（図２６＜３＞）。このとき、確認処理７５からの応答内容が“経路数＝１”である場合には、当該経路（セグメント）を用いて送信先ノードＤＮ宛ての第ｘＰａｔｈメッセージを転送するようにカーネルに命令を出す（図２４＜４＞）。経路数が２以上であるノードは、ロードバランシング開始ノードとなっている。
[経路表送信先セグメント数確認処理]
確認処理７５は、分析制御処理７４からの確認指示を受けて、経路表ＲＴ上にある第ｘＰａｔｈメッセージの送信先に対応するセグメント（経路）の数を計数し、計数結果を応答として分析制御処理に返す。
確認処理７５は、分析制御処理７４からの確認指示を受けて、経路表ＲＴ上にある第ｘＰａｔｈメッセージの送信先に対応するセグメント（経路）の数を計数し、計数結果を応答として分析制御処理に返す。
[ＰａｔｈＩＤ識別番号確認処理]
確認処理７６は、分析制御処理７４から識別番号を受信すると、識別番号の値を確認し、当該識別番号がマーキングされている経路を参照して送信先ノードＤＮ宛ての第ｘＰａｔｈメッセージを送信する旨の指示を選定処理７７に与える（図２６＜５＞）。
確認処理７６は、分析制御処理７４から識別番号を受信すると、識別番号の値を確認し、当該識別番号がマーキングされている経路を参照して送信先ノードＤＮ宛ての第ｘＰａｔｈメッセージを送信する旨の指示を選定処理７７に与える（図２６＜５＞）。
[参照経路表選定処理]
選定処理７７は、確認処理７６からの指示を受けて、第ｘＰａｔｈメッセージの転送に用いる経路を選定する。選定処理７７は、選定した経路で第ｘＰａｔｈメッセージを転送する旨の命令をカーネルに与える（図２６＜６＞）。これによって、第ｘＰａｔｈメッセージは、選定された経路を通って送信先ノードＤＮへ転送される。
選定処理７７は、確認処理７６からの指示を受けて、第ｘＰａｔｈメッセージの転送に用いる経路を選定する。選定処理７７は、選定した経路で第ｘＰａｔｈメッセージを転送する旨の命令をカーネルに与える（図２６＜６＞）。これによって、第ｘＰａｔｈメッセージは、選定された経路を通って送信先ノードＤＮへ転送される。
＜＜Ｒｅｓｖメッセージ処理＞＞
図２７は、Ｒｅｓｖメッセージ処理３０の詳細を模式的に示す図である。図２７において、Ｒｅｓｖメッセージ処理３０では、Ｒｅｓｖメッセージ分析制御処理７８（以下、「分析制御処理７８」とも表記が実行される。また、Ｒｅｓｖメッセージ処理３０では、経路表確認処理８０（以下、「確認処理８０」とも表記）と、仮予約帯域→本予約帯域変更処理８１（以下、「予約形式変更処理８１」とも表記）とが実行される。
図２７は、Ｒｅｓｖメッセージ処理３０の詳細を模式的に示す図である。図２７において、Ｒｅｓｖメッセージ処理３０では、Ｒｅｓｖメッセージ分析制御処理７８（以下、「分析制御処理７８」とも表記が実行される。また、Ｒｅｓｖメッセージ処理３０では、経路表確認処理８０（以下、「確認処理８０」とも表記）と、仮予約帯域→本予約帯域変更処理８１（以下、「予約形式変更処理８１」とも表記）とが実行される。
[Ｒｅｓｖメッセージ分析制御処理]
分析制御処理７８は、受信メッセージ分析処理２０からＲｅｓｖメッセージを得る。分析制御処理７８は、Ｒｅｓｖメッセージの送信先ＩＰアドレスを取得し、経路表確認処理８０に送信する（図２７＜１＞）。
分析制御処理７８は、受信メッセージ分析処理２０からＲｅｓｖメッセージを得る。分析制御処理７８は、Ｒｅｓｖメッセージの送信先ＩＰアドレスを取得し、経路表確認処理８０に送信する（図２７＜１＞）。
分析制御処理７８は、経路表確認処理８０から自ノードにおけるＲｅｓｖメッセージの送信先（送信元ノードＳＮ）に向かう経路が１つである旨の応答を得た場合（図２７＜２＞）には、Ｒｅｓｖメッセージ次ノードへ転送する命令をカーネルに与える（図２７＜３＞）。
このとき、分析制御処理７８は、予約形式変更処理８１を利用して仮予約帯域を本予約帯域に変更する（図２７＜４＞，＜５＞）。複数の仮予約帯域がある場合には、分析制御処理７８は、Ｒｅｓｖメッセージ中のＰａｔｈＩＤと同一のＰａｔｈＩＤを有するＲｅｓｖメッセージが過去に自ノードで受信されていないか確認する。当該確認は、ＲＡＭ１６に保持された情報を参照することによって行われる（図２７＜６＞，＜７＞）。
同一のＰａｔｈＩＤを有するＲｅｓｖメッセージが過去に受信されていることを確認した場合には、分析制御処理７８は、選定処理７９に対してＲｅｓｖメッセージ中のＰａｔｈＩＤの識別番号を通知する（図２７＜８＞）。
[経路表確認処理]
確認処理８０は、分析制御処理７８からの確認指示を受けて（図２７＜１＞）、経路表ＲＴを参照し、送信先ＩＰアドレスに対応する経路の数を分析制御処理に応答する（図２７＜２＞）。
確認処理８０は、分析制御処理７８からの確認指示を受けて（図２７＜１＞）、経路表ＲＴを参照し、送信先ＩＰアドレスに対応する経路の数を分析制御処理に応答する（図２７＜２＞）。
[参照経路選定処理]
選定処理７９は、分析制御処理７８から識別番号を受信すると、当該識別番号が付与されている経路を利用してＲｅｓｖメッセージを転送する命令をカーネルに与える（図２７＜９＞）。また、選定処理７９は、仮予約帯域を本予約帯域に変更する指示を予約形式変更処理８１に与える（図２７＜１０＞）。
選定処理７９は、分析制御処理７８から識別番号を受信すると、当該識別番号が付与されている経路を利用してＲｅｓｖメッセージを転送する命令をカーネルに与える（図２７＜９＞）。また、選定処理７９は、仮予約帯域を本予約帯域に変更する指示を予約形式変更処理８１に与える（図２７＜１０＞）。
[仮予約帯域→本予約帯域変更処理]
予約形式変更処理８１は、仮予約されている帯域を本予約に変更することをカーネルに命令する（図２７＜１１＞）。必要に応じて、隣接ノードとの間で、仮予約を本予約にするためのメッセージのやりとりが行われる。
予約形式変更処理８１は、仮予約されている帯域を本予約に変更することをカーネルに命令する（図２７＜１１＞）。必要に応じて、隣接ノードとの間で、仮予約を本予約にするためのメッセージのやりとりが行われる。
＜＜仮予約帯域全開放メッセージ処理＞＞
図２８は、仮予約帯域全開放メッセージ処理２９の詳細を模式的に示す図である。仮予約帯域全開放メッセージ処理２９（以下、「メッセージ処理２９」とも表記）では、仮予約帯域全開放メッセージ分析制御処理８３（以下、「分析制御処理８３」とも表記）が実行される。
図２８は、仮予約帯域全開放メッセージ処理２９の詳細を模式的に示す図である。仮予約帯域全開放メッセージ処理２９（以下、「メッセージ処理２９」とも表記）では、仮予約帯域全開放メッセージ分析制御処理８３（以下、「分析制御処理８３」とも表記）が実行される。
また、メッセージ処理２９では、仮予約帯域全開放処理８４（以下、「開放処理８４」とも表記）と、ベストエフォート型遷移処理８５（以下、「遷移処理８５」とも表記）と
が実行される。
が実行される。
[仮予約帯域全開放メッセージ分析制御処理]
分析制御処理８３は、受信メッセージ分析処理２０から仮予約帯域全開放メッセージ（以下、「開放メッセージ」とも表記）を得る。分析制御処理８３は、開放メッセージ中のＰａｔｈＩＤを得て、当該ＰａｔｈＩＤと同値のＰａｔｈＩＤを有するＰａｔｈメッセージが過去に受信されていないかを、ＲＡＭ１６に記憶されたＰａｔｈＩＤの参照によって確認する（図２８＜１＞，＜２＞）。
分析制御処理８３は、受信メッセージ分析処理２０から仮予約帯域全開放メッセージ（以下、「開放メッセージ」とも表記）を得る。分析制御処理８３は、開放メッセージ中のＰａｔｈＩＤを得て、当該ＰａｔｈＩＤと同値のＰａｔｈＩＤを有するＰａｔｈメッセージが過去に受信されていないかを、ＲＡＭ１６に記憶されたＰａｔｈＩＤの参照によって確認する（図２８＜１＞，＜２＞）。
調査の結果、該当するＰａｔｈＩＤがＲＡＭ１６に記憶されていない場合には、分析制御処理８３は、仮予約帯域全開放メッセージを次ノードへ転送する命令をカーネルに与える（図２８＜２ａ＞）。該当するＰａｔｈＩＤがＲＡＭ１６に記憶されている場合には、分析制御処理８３は、開放処理８４を用いて自ノードが当該ＰａｔｈＩＤを有するＰａｔｈメッセージに従って仮予約した全ての帯域を開放する（図２８＜３＞，＜４＞）。自ノードが開放メッセージの終端ノードである場合には、分析制御処理８３は、遷移処理８５に対して、ロードバランシング経路確立失敗指示を送信する（図２８＜５＞）。
[ベストエフォート型遷移処理]
ベストエフォート型遷移処理８５は、分析制御処理８３からロードバランシング経路確立失敗指示を受信したとき、送受信ノード間でロードバランシングを利用したＱｏＳを保障する複数経路の確立処理を停止し、現在ネットワークで使われているベストエフォート型通信や、待時式帯域予約通信方式などへ移行する。
ベストエフォート型遷移処理８５は、分析制御処理８３からロードバランシング経路確立失敗指示を受信したとき、送受信ノード間でロードバランシングを利用したＱｏＳを保障する複数経路の確立処理を停止し、現在ネットワークで使われているベストエフォート型通信や、待時式帯域予約通信方式などへ移行する。
[仮予約帯域全開放処理]
開放処理８４は、分析制御処理８４から開放指示を受信したとき、開放メッセージ中のＰａｔｈＩＤと同一のＰａｔｈＩＤを有するＰａｔｈメッセージによって仮予約された帯域の全てを開放する処理を行う。開放処理８４は、必要に応じて、仮予約解除のための命令をカーネルに与える（図２８＜７＞）。
開放処理８４は、分析制御処理８４から開放指示を受信したとき、開放メッセージ中のＰａｔｈＩＤと同一のＰａｔｈＩＤを有するＰａｔｈメッセージによって仮予約された帯域の全てを開放する処理を行う。開放処理８４は、必要に応じて、仮予約解除のための命令をカーネルに与える（図２８＜７＞）。
＜動作例＞
図２９〜図３３は、実施形態２におけるネットワークシステム（図１６）の動作例を示すシーケンス図である。図２９において、送信元ノードＳＮは、送信先ノードＤＮとの間で１００Ｍｂｐｓの必要帯域を予約した通信を行う場合、次ノード（ノードＡ）との間の空き帯域が予約帯域（＝必要帯域）以上か否かを判定する（０１）。
図２９〜図３３は、実施形態２におけるネットワークシステム（図１６）の動作例を示すシーケンス図である。図２９において、送信元ノードＳＮは、送信先ノードＤＮとの間で１００Ｍｂｐｓの必要帯域を予約した通信を行う場合、次ノード（ノードＡ）との間の空き帯域が予約帯域（＝必要帯域）以上か否かを判定する（０１）。
空き帯域が予約帯域（＝必要帯域）以上であるので、送信元ノードＳＮは、送信元ノードＳＮとノードＡとの間で“１００Ｍ”の帯域を仮予約する（０２）。次に、送信元ノードＳＮは、送信先ノードＤＮ向けのＰａｔｈメッセージを送信し、ＰａｔｈメッセージはノードＡで受信される（０３）。
Ｐａｔｈメッセージを受信したノードＡは、Ｐａｔｈメッセージ処理２１を実行し、次ノード（ノードＢ）との間の空き帯域が予約帯域以上か否かを調査する（０４）。このとき、空き帯域が予約帯域以上であるので、ノードＡは、ノードＡとノードＢとの間で必要帯域“１００Ｍ”の仮予約を行う（０５）。ノードＡは、ＰａｔｈメッセージをノードＢに転送する（０６）。
Ｐａｔｈメッセージを受信したノードＢは、Ｐａｔｈメッセージ処理２１を実行し、次ノード（ノードＣ）との間の空き帯域が予約帯域以上か否かを調査する（０７）。このとき、空き帯域が予約帯域以上であるので、ノードＢは、ノードＢとノードＣとの間で必要帯域“１００Ｍ”の仮予約を行う（０８）。ノードＢは、ＰａｔｈメッセージをノードＣ
に転送する（０９）。
に転送する（０９）。
Ｐａｔｈメッセージを受信したノードＣは、Ｐａｔｈメッセージ処理２１を実行し、次ノード（ノードＥ）との間の空き帯域が予約帯域以上か否かを調査する（０７）。このとき、空き帯域が予約帯域未満であるので、ノードＣは、予約帯域“１００Ｍ”を、例えば予約帯域“７０[Ｍｂｐｓ]”に更新する（１１）。次に、ノードＣは、ノードＣとノードＥとの間で予約帯域“７０Ｍ”の仮予約を行う（１２）。ノードＣは、ＰａｔｈメッセージをノードＥに転送する（１３）。
また、ノードＣは、仮予約帯域更新メッセージを生成し、前ノード（ノードＢ）へ送信する（１４）。ノードＢは、仮予約帯域更新メッセージ処理２２を実行し、ノードＢとノードＣとの間の仮予約帯域を“１００Ｍ”から“７０Ｍ”に変更する（１５）。
Ｐａｔｈメッセージを受信したノードＥは、Ｐａｔｈメッセージ処理２１を実行し、次ノード（送信先ノードＤＮ）との間の空き帯域が予約帯域“７０Ｍ”以上か否かを調査する（１６）。このとき、空き帯域が予約帯域未満であるので、ノードＥは、予約帯域“７０Ｍ”をノードＥと送信先ノードＤＮとの間で仮予約する（１７）。ノードＥは、Ｐａｔｈメッセージを送信先ノードＳＮに転送する（１８）。
図３０において、Ｐａｔｈメッセージを受信した送信先ノードＤＮは、Ｐａｔｈメッセージ処理２１を実行する。このとき、Ｐａｔｈメッセージの必要帯域情報が予約帯域情報を上回る。このため、送信先ノードＤＮは、Ｐａｔｈメッセージ中のＰａｔｈＩＤにおけるＭＡＣアドレスが同一で識別番号が異なる別のＰａｔｈメッセージ（第２以降のＰａｔｈメッセージ）の到着を持つ状態となる（１９）。
一方、仮予約帯域を変更したノードＢは、仮予約帯域更新メッセージを生成し、前ノード（ノードＡ）へ送信する（２０）。ノードＡは、仮予約帯域更新メッセージ処理２２を実行し、ノードＡとノードＢとの間の仮予約帯域を“１００Ｍ”から“７０Ｍ”に変更する（２１）。
ノードＡは、仮予約帯域更新メッセージを生成し、前ノード（送信元ノードＳＮ）へ送信する（２２）。送信元ノードＳＮは、仮予約帯域更新メッセージ処理２２を実行し、送信元ノードＳＮとノードＡとの間の仮予約帯域を“１００Ｍ”から“７０Ｍ”に変更する（２３）。
予約帯域情報の更新を行ったノードＣは、ロードバランシング実施可否判断を行う（２４）。図１６に示したネットワークトポロジでは、バリアンス値を変更しても別経路が経路表ＲＴに出現しないので、ノードＣはロードバランシングを実施することができない。このため、ノードＣは、ロードバランシング実施可否判断実行指示メッセージを生成し、前ノード（ノードＢ）へ送信する（２５）。
ノードＢは、ロードバランシング実施可否判断実行指示メッセージ処理２３を実行し、ロードバランシング実施可否判断処理を行う（２６）。ノードＢも、別経路を有しないので、ロードバランシングを実施することはできない。このため、ノードＢは、ロードバランシング実施可否判断実行指示メッセージを前ノード（ノードＡ）へ転送する（２７）。
ノードＡは、ロードバランシング実施可否判断実行指示メッセージ処理２３を実行し、ロードバランシング実施可否判断処理を行う（２８）。ノードＡでは、経路表ＲＴから別経路が見つかるので、ロードバランシングを実施可能と判断する。
ノードＡは、ロードバランシング終端発見メッセージを生成し、別経路上の次ノード（送信先ノードＤＮへ向かう別経路上の隣接ノード）であるノードＣへロードバランシング終端発見メッセージを送信する（２９）。
ノードＣは、ロードバランシング終端発見メッセージ処理２４を実行し、ＰａｔｈＩＤの比較を行う。比較の結果、ＰａｔｈＩＤが一致するので、ノードＣは、過去におけるロードバランシング実施可否判断の実行履歴があるか否かを判定する（３０）。ここでは、２４で実行したロードバランシング実施可否判断処理の実行履歴が発見される。このため、ノードＣは、ノードＡに対して、別経路メンバパス発見指示メッセージを送信する（３１）。
ノードＡは、別経路メンバパス発見指示メッセージ処理２７を実行し、ロードバランシング実施可否判断処理を行う（３２）。この結果において、ノードＡはロードバランシングを実施可能と判断する。すると、ノードＡは、ロードバランシング終端発見メッセージを別経路上の次ノードであるノードＤへ送信する（３３）。
ノードＤは、ロードバランシング終端発見メッセージ処理２４を実行し、ＰａｔｈＩＤの比較を行う（３４）。このとき、ＰａｔｈＩＤは不一致（或いは比較するＰａｔｈＩＤが保持されていない）となる。すなわち、同一ＰａｔｈＩＤを有するＰａｔｈメッセージの受信履歴がないことをノードＤは検知する。すると、ノードＤは、ロードバランシング終端発見メッセージを次ノードであるノードＥへ転送する（３５）。
図３１において、ノードＥは、ロードバランシング終端発見メッセージ処理２４を実行し、ＰａｔｈＩＤの比較を行う（３６）。ノードＥは、ロードバランシング終端発見メッセージ中のＰａｔｈＩＤと同一のＰａｔｈＩＤを有するＰａｔｈメッセージを受信している（図２９の１３参照）。しかし、ノードＡは、ロードバランシング実施可否判断処理を実行していないので、当該処理の実行履歴は存在しない。
このため、ノードＥは、自ノードがロードバランシング終端ノードとして動作することを決定する（３７）。さらに、ノードＥは、別経路メンバパス発見成功メッセージを生成し、前ノードであるノードＤへ送信する（３８）。
ノードＤは、別経路メンバパス発見成功メッセージ処理２５を実行し、別経路メンバパス発見成功メッセージを前ノードであるノードＡへ転送する（３９）。ノードＡは、別経路メンバパス発見成功メッセージ処理２５において、自ノードがロードバランシング開始ノードとして動作することを決定する（４０）。
ノードＡは、識別番号問い合わせメッセージを生成し、送信元ノードＳＮへ送信する（４１）。その後、ノードＡは、送信元ノードＳＮから識別番号を受け取ると（４２）、受け取った識別番号に１を加算して識別番号の更新を行う（４３）。続いて、ノードＡは、第２Ｐａｔｈメッセージ送信指示メッセージを送信元ノードＳＮへ送信する（４４）。
送信元ノードＳＮは、第ｘＰａｔｈメッセージ送信指示メッセージ処理２６を実行し、次ノード（ノードＡ）までの空き帯域を調査する（４５）。このとき、空き帯域が第ｘＰａｔｈメッセージ送信指示メッセージ中の必要帯域情報（＝予約帯域情報＝“３０Ｍ”）以上であれば、送信元ノードＳＮは、送信元ノードＳＮとノードＡとの間について“３０Ｍ”の帯域の仮予約を行う（４６）。
その後、送信元ノードＳＮは、第２Ｐａｔｈメッセージを生成し、次ノードであるノードＡへ送信する（４７）。ノードＡは、第２Ｐａｔｈメッセージを受信すると、ノードＡ
とノードＤとの間で予約帯域“３０Ｍ”以上の空き帯域があるかを判定する（４８）。空き帯域がある場合には、ノードＡは、ノードＡとノードＤとの間で“３０Ｍ”の帯域の仮予約を行い（４９）、第２ＰａｔｈメッセージをノードＤへ転送する（５０）。
とノードＤとの間で予約帯域“３０Ｍ”以上の空き帯域があるかを判定する（４８）。空き帯域がある場合には、ノードＡは、ノードＡとノードＤとの間で“３０Ｍ”の帯域の仮予約を行い（４９）、第２ＰａｔｈメッセージをノードＤへ転送する（５０）。
ノードＤは、第２Ｐａｔｈメッセージに対するＰａｔｈメッセージ処理２１を実行し、ノードＤとノードＥ（次ノード）との間の空き帯域が予約帯域“３０Ｍ”以上であるか否かを判定する。予約帯域以上の空き帯域があれば、ノードＤは、図３２に示すように、予約帯域分（不足予約帯域分）の帯域“３０Ｍ”の仮予約を行う（５２）。ノードＤは、第２ＰａｔｈメッセージをノードＥへ転送する（５３）。
ノードＥは、第２Ｐａｔｈメッセージに対するＰａｔｈメッセージ処理２１を実行し、ノードＥと送信先ノードＤＮ（次ノード）との間の空き帯域が予約帯域“３０Ｍ”以上であるか否かを判定する（５４）。予約帯域以上の空き帯域があれば、ノードＥは、予約帯域分（不足予約帯域分）の帯域“３０Ｍ”の仮予約を行う（５５）。ノードＥは、第２Ｐａｔｈメッセージを送信先ノードＤＮへ転送する（５６）。
送信先ノードＤＮは、第２Ｐａｔｈメッセージに対するＰａｔｈメッセージ処理２１を行い、過去に受信したＰａｔｈメッセージ（送信元ノードの識別情報が第２Ｐａｔｈメッセージと同一）の予約帯域情報“７０Ｍ”と第２Ｐａｔｈメッセージの予約帯域情報“３０Ｍ”とを加算する（５７）。加算結果“１００Ｍ”は、Ｐａｔｈメッセージの必要帯域情報“１００Ｍ”と同値であるので、送信先ノードＤＮは、複数経路による必要帯域の確保（仮予約状態）を確認する（５８）。
送信先ノードＤＮは、ＰａｔｈＩＤ（識別番号１）を有するＲｅｓｖメッセージと、ＰａｔｈＩＤ（識別番号２）を有するＲｅｓｖメッセージとを生成し、ノードＥへ送信する（５９）。
ノードＥでは、各Ｒｅｓｖメッセージに対するＲｅｓｖメッセージ処理３０が実行され、識別番号１の経路に対して仮予約された“７０Ｍ”の帯域と識別番号２の経路に対して仮予約された“３０Ｍ”の帯域とが本予約状態に変更される（６０）。これによって、ノードＥと送信先ノードＤＮとの間で１００Ｍの帯域が本予約された状態となる。
識別番号２を有するＲｅｓｖメッセージは、ノードＥによりノードＤへ転送される（６１）。ノードＤは、Ｒｅｓｖメッセージ処理３０の実行を通じてノードＤとノードＥとの間で仮予約された３０Ｍの帯域を本予約状態に変更する（６２）。識別番号２を有するＲｅｓｖメッセージは、ノードＤによりノードＡへ転送される（６３）。ノードＡは、Ｒｅｓｖメッセージ処理３０の実行を通じてノードＡとノードＤとの間で仮予約された３０Ｍの帯域を本予約状態に変更する（６４）。
図３３において、ノードＥは、識別番号１を有するＲｅｓｖメッセージをノードＣへ送る（６５）。ノードＣは、Ｒｅｓｖメッセージ処理３０の実行を通じてノードＣとノードＥとの間で仮予約された７０Ｍの帯域を本予約状態に変更する（６６）。識別番号１を有するＲｅｓｖメッセージは、ノードＣによりノードＢへ転送される（６７）。ノードＢは、Ｒｅｓｖメッセージ処理３０の実行を通じてノードＢとノードＣとの間で仮予約された７０Ｍの帯域を本予約状態に変更する（６８）。
識別番号１を有するＲｅｓｖメッセージは、ノードＢによりノードＡへ転送される（６９）。ノードＡは、Ｒｅｓｖメッセージ処理３０の実行を通じてノードＡとノードＢとの間で仮予約された７０Ｍの帯域を本予約状態に変更する（７０）。
識別番号１を有するＲｅｓｖメッセージと識別番号２を有するＲｅｓｖメッセージとのそれぞれは、最終的に送信元ノードＳＮへ到達する（７１）。図３３では、各Ｒｅｓｖメッセージの到着タイミングが同時であるように図示されている。しかし、タイミングを合わせる必要はなく、各Ｒｅｓｖメッセージは、各経路のコストに応じた相互に無関係なタイミングで送信元ノードＳＮへ到着する。
送信元ノードＳＮは、各Ｒｅｓｖメッセージに基づき、識別番号１のＰａｔｈメッセージに関して仮予約した７０Ｍの帯域と識別番号２のＰａｔｈメッセージに関して仮予約した３０Ｍの帯域とを本予約状態に変更する（７２）。これによって、送信元ノードＳＮとノードＡとの間で必要帯域である１００Ｍの帯域が予約された状態となる。
その後、送信元ノードＳＮと送信先ノードＤＮとの間で、パケット通信が開始される（７３）。パケット通信は、１００Ｍの帯域が予約された状態で行われる。このため、当該パケット通信で要求されるＱｏＳを保証した通信を実行することができる。
実施形態１の作用効果は、実施形態１と同様である。実施形態１の構成と実施形態２の構成とは適宜組み合わせることができる。
＜変形例＞
実施形態１及び２において、Ｐａｔｈメッセージには、予約帯域情報を格納するフィールドが形成されており、送信元ノードＳＮでは、予約帯域情報に必要帯域情報と同値が設定される。そして、Ｐａｔｈメッセージを受信する各ノードは、予約帯域情報に示された帯域の仮予約を行う。
実施形態１及び２において、Ｐａｔｈメッセージには、予約帯域情報を格納するフィールドが形成されており、送信元ノードＳＮでは、予約帯域情報に必要帯域情報と同値が設定される。そして、Ｐａｔｈメッセージを受信する各ノードは、予約帯域情報に示された帯域の仮予約を行う。
上記構成に代えて、以下の構成を採用可能である。送信元ノードＳＮは、予約帯域情報を記憶しない。Ｐａｔｈメッセージを受信する各ノードは、Ｐａｔｈメッセージに予約帯域情報が含まれているか否かを判定し、予約帯域情報があれば、ノードは、予約帯域情報に従って空き帯域調査及び帯域の仮予約を行う。予約帯域情報が無ければ、ノードは、必要帯域情報に従って空き帯域調査及び帯域の仮予約を行う。空き帯域調査で必要帯域が確保できない場合、ノードは、空き帯域調査結果に基づき決定した予約帯域を示す予約帯域情報をＰａｔｈメッセージに新規に含める。
また、実施形態１及び２において、帯域の仮予約は、Ｐａｔｈメッセージを受信したノードが次ノードとの間に帯域について実施する。このような構成に代えて、仮予約が、Ｐａｔｈメッセージを受信したノードが前ノードとの間の帯域について実施するようにしても良い。
また、実施形態１及び２において、送信先ノードＤＮが、所定値（例えば６）の第ｘＰａｔｈメッセージを受信したときに、全開放メッセージが送信されるようにしている。このような構成に代えて以下の構成を採用することができる。送信元ノードＳＮが、識別番号の問い合わせに対して応答を予定する識別番号が適宜設定可能な所定値（６）に達したときには、送信元ノードＳＮが、第１〜第５Ｐａｔｈメッセージを送信した各経路宛てに、仮予約帯域全開放メッセージを送信する。
また、送信元ノードＳＮは、Ｐａｔｈメッセージを送信してから所定期間内に対応するＲｅｓｖメッセージを受信できない場合（待ちタイマがタイムアウトになった場合）には、以下のような動作を行うようにしても良い。
すなわち、所定時間が経過すると、送信元ノードＳＮは、当該時点までにＰａｔｈメッセージ及び第ｘＰａｔｈメッセージを送信した経路に対し、仮予約の帯域開放メッセージ
を送信する。これによって、帯域予約処理（第１Ｐａｔｈメッセージの送信）開始から一定期間内に必要帯域の予約が完了しないときには、仮予約帯域が開放される。これによって、仮予約の影響が他の通信（トラフィック）に及ぶ可能性を低減することができる。
を送信する。これによって、帯域予約処理（第１Ｐａｔｈメッセージの送信）開始から一定期間内に必要帯域の予約が完了しないときには、仮予約帯域が開放される。これによって、仮予約の影響が他の通信（トラフィック）に及ぶ可能性を低減することができる。
上記のようなタイムアウト処理は、送信先ノードＤＮにおいて実行されるようにしても良い。例えば、送信元ノードＤＮは、最初のＰａｔｈメッセージを受信して残りのＰａｔｈメッセージを待機する状態になると、タイマの計時を開始する。タイマが満了すると、送信元ノードＤＮは、各Ｐａｔｈメッセージを受信した経路（将来においてＰａｔｈメッセージを受信する経路を含む）に対して仮予約帯域全開放メッセージを送信する。
以上説明した実施形態の構成は、適宜組み合わせることができる。
ＤＮ・・・送信先ノード
ＳＮ・・・送信元ノード
ＲＮ・・・中継ノード
１０・・・情報処理装置（ルータ）
１１・・・通信インタフェース
１２・・・ＣＰＵ
１４・・・メモリ
ＳＮ・・・送信元ノード
ＲＮ・・・中継ノード
１０・・・情報処理装置（ルータ）
１１・・・通信インタフェース
１２・・・ＣＰＵ
１４・・・メモリ
Claims (11)
- 送信元ノードと送信先ノードとの間で帯域予約要求メッセージが転送される経路上にある中継ノードであって、
前記送信元ノードと前記送信先ノードとの間の通信に関して予約を要求する帯域を示す予約要求帯域を含んだ前記帯域予約要求メッセージを受信する受信部と、
前記経路上にある隣接ノードとの間で前記予約要求帯域を確保可能であるときに前記帯域予約要求メッセージを前記経路上の次ノードに転送する送信部と、
前記予約要求帯域を前記隣接ノードとの間で確保できないときに前記予約要求帯域の一部の帯域を前記経路上で確保するための情報を含めた前記帯域予約要求メッセージを前記送信部から前記次ノードへ転送する処理と前記経路と異なる他の経路で残りの帯域を確保するための処理とを行う制御部と、を含み、
前記制御部は、前記予約要求帯域を確保できない場合において自ノードが前記他の経路を有するときに前記送信元ノードに対して前記他の経路で前記残りの帯域を予約するための残帯域用帯域予約要求メッセージの送信を依頼する
中継ノード。 - 前記制御部は、前記経路上にある隣接ノードとの間で前記予約要求帯域を確保可能であるときには前記予約要求帯域の仮予約を行い、前記予約要求帯域を確保できないときには前記予約要求帯域の一部の仮予約を行う
請求項１に記載の中継ノード。 - 前記制御部は、前記送信先ノードから前記帯域予約要求メッセージに対応する帯域予約メッセージが前記受信部で受信されたときに前記仮予約した帯域を本予約に変更する
請求項２に記載の中継ノード。 - 前記制御部は、前記残帯域用帯域予約要求メッセージが前記送信元ノードから送信される前に前記他の経路と前記経路とを識別するための識別情報を前記送信元ノードから取得し、前記送信元ノードから受信される前記残帯域用帯域予約要求メッセージを前記識別情報を用いて前記他の経路へ転送する
請求項１から３のいずれか１項に記載の中継ノード。 - 前記制御部は、自ノードが前記他の経路を有するときに前記経路上に存在し且つ前記他の経路の終端点となる他の中継ノードに前記経路と前記他の経路とを登録させるための終端点探索メッセージを前記他の経路へ送信する
請求項１から４のいずれか１項に記載の中継ノード。 - 前記制御部は、隣接ノードから受信し転送先に転送した終端点探索メッセージに関して前記転送先からの指示に応じて別経路の探索処理を行い発見した別経路に新たな終端点探索メッセージを送信するときに、前記新たな終端点探索メッセージの送信元アドレスとして元の終端点探索メッセージに含まれた送信元アドレスを設定する
請求項５に記載の中継ノード。 - 前記制御部は、前記別経路の探索処理で別経路が発見できないときに別経路の探索処理を前記隣接ノードに依頼する
請求項６に記載の中継ノード。 - 前記制御部は、自ノードが前記他の経路を有しないときに前記経路上で前記送信元ノード側にある隣接ノードに他の経路を有するか否かの判定処理を依頼する
請求項１から７のいずれか１項に記載の中継ノード。 - 前記制御部は、受信された仮予約の解除指示に応じて仮予約した帯域を開放する
請求項２から８のいずれか１項に記載の中継ノード。 - 送信元ノードと送信先ノードとの間で帯域予約要求メッセージが転送される経路上にある中継ノードの帯域予約支援方法であって、
前記送信元ノードと前記送信先ノードとの間の通信に関して予約を要求する帯域を示す予約要求帯域を含んだ前記帯域予約要求メッセージを受信し、
前記経路上にある隣接ノードとの間で前記予約要求帯域を確保可能であるときに前記帯域予約要求メッセージを前記経路上の次ノードに転送し、
前記予約要求帯域を前記隣接ノードとの間で確保できないときに前記予約要求帯域の一部の帯域を前記経路上で確保するための情報を含めた前記帯域予約要求メッセージを前記次ノードへ転送し、
前記予約要求帯域を前記隣接ノードとの間で確保できない場合において前記中継ノードが前記経路と異なる他の経路を有するときに前記他の経路で残りの帯域を予約するための残帯域用帯域予約要求メッセージの送信を前記送信元ノードに依頼する
ことを含む中継ノードの帯域予約支援方法。 - 帯域予約要求メッセージを送信する送信元ノードと、
前記帯域予約要求メッセージの宛先である送信先ノードと、
前記送信元ノードと前記送信先ノードとの間の複数の経路上にある複数の中継ノードとを含み、
前記各中継ノードは、
前記送信元ノードと前記送信先ノードとの間の通信に関して予約を要求する帯域を示す予約要求帯域を含んだ前記帯域予約要求メッセージを受信する受信部と、
前記帯域予約要求メッセージが転送される経路上にある隣接ノードとの間で前記予約要求帯域を確保可能であるときに前記帯域予約要求メッセージを前記経路上の次ノードに転送する送信部と、
前記予約要求帯域を前記隣接ノードとの間で確保できないときに前記予約要求帯域の一部の帯域を前記経路上で確保するための情報を含めた前記帯域予約要求メッセージを前記送信部から前記次ノードへ転送する処理と前記経路と異なる他の経路で残りの帯域を確保
するための処理とを行う制御部と、
を含み、
前記送信元ノードは、前記経路と異なる他の経路で残りの帯域を確保するための処理によって前記複数の中継ノードの１つから受信される指示に応じて他の経路で前記残りの帯域を確保するための残帯域用帯域予約要求メッセージを送信し、
前記送信先ノードは、自ノードに到達した前記帯域予約要求メッセージの内容から予約要求帯域の全てが確保可能であるときに前記帯域予約要求メッセージの転送経路上にある中継ノードに前記予約要求帯域を予約させるための帯域予約メッセージを送信し、自ノードに到達した前記予約要求メッセージの内容から前記予約要求帯域の一部が確保可能であるときに前記残帯域用帯域予約要求メッセージの受信を待機し、受信された前記残帯域用帯域予約要求メッセージの内容から前記残り帯域が確保可能であるときに前記帯域予約要求メッセージの転送経路上にある中継ノードに前記予約要求帯域の一部を予約させるための帯域予約メッセージを送信するとともに前記残帯域用帯域予約要求メッセージの転送経路上にある中継ノードに前記残り帯域を予約させるための帯域予約メッセージを送信するネットワークシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014083347A JP6303750B2 (ja) | 2014-04-15 | 2014-04-15 | 中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014083347A JP6303750B2 (ja) | 2014-04-15 | 2014-04-15 | 中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015204542A JP2015204542A (ja) | 2015-11-16 |
| JP6303750B2 true JP6303750B2 (ja) | 2018-04-04 |
Family
ID=54597757
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014083347A Expired - Fee Related JP6303750B2 (ja) | 2014-04-15 | 2014-04-15 | 中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6303750B2 (ja) |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09139738A (ja) * | 1995-11-13 | 1997-05-27 | Matsushita Electric Ind Co Ltd | Ａｔｍ通信網 |
| JP4507400B2 (ja) * | 2000-12-13 | 2010-07-21 | 沖電気工業株式会社 | ネットワークリソース予約方法及びノード装置 |
| US8218553B2 (en) * | 2009-02-25 | 2012-07-10 | Juniper Networks, Inc. | Load balancing network traffic on a label switched path using resource reservation protocol with traffic engineering |
-
2014
- 2014-04-15 JP JP2014083347A patent/JP6303750B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2015204542A (ja) | 2015-11-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7039707B2 (ja) | ネットワークにおけるパケット伝送のための方法及びノード | |
| JP4328478B2 (ja) | ラベル転送ネットワークにおける経路変更方法並びにラベルスイッチングノード及び管理ノード | |
| JP2022532729A (ja) | スライスベースルーティング | |
| US7978596B2 (en) | Connection-oriented network node | |
| CN110890994B (zh) | 一种报文转发路径的确定方法、设备和系统 | |
| US10623326B2 (en) | Jitter compensation along multiple-path deterministic network segment | |
| WO2015010518A1 (zh) | 确定业务传输路径的方法、装置及系统 | |
| JP6443864B2 (ja) | パケット紛失検出を実装するための方法、装置、およびシステム | |
| US9736066B2 (en) | Method, apparatus and system for establishing optical bypass | |
| US20090070468A1 (en) | Communication system and communication method | |
| US7133402B2 (en) | Link identifier assignment system in connection-oriented communication network | |
| US20220124023A1 (en) | Path Switching Method, Device, and System | |
| KR20220018065A (ko) | 패킷 포워딩 방법 및 디바이스, 그리고 컴퓨터가 판독 가능한 저장 매체 | |
| US20060036892A1 (en) | Apparatus and method for establishing tunnel routes to protect paths established in a data network | |
| JP5493965B2 (ja) | 帯域制御システム、帯域制御装置、帯域制御方法および帯域制御プログラム | |
| JP4567758B2 (ja) | ＱｏＳリソースを確保し、マルチキャストネットワークリソースを設定する方法および装置 | |
| US20140185607A1 (en) | Communication system, communication path establishing method and management server | |
| EP1418716A1 (en) | Communication control system, communication control method, routing controller and router suitably used for the same | |
| JP2007074055A (ja) | 動的制御用ネットワークリソース制御方法および動的制御用ネットワークリソース制御装置 | |
| JP2006287549A (ja) | 帯域制御方法およびそれを利用したｍｐｌｓルータ | |
| US9288133B2 (en) | Routing device, communications system, and routing method | |
| JP6042838B2 (ja) | 管理システム、管理サーバ、および管理方法 | |
| JP6303750B2 (ja) | 中継ノード，中継ノードの帯域予約支援方法，及びネットワークシステム | |
| US20090016277A1 (en) | Mobile communication system, packet transfer device, and path re-establishing method | |
| US8732335B2 (en) | Device communications over unnumbered interfaces |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170110 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20171025 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20171107 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20171213 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180116 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180125 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180206 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180219 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6303750 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |