JP4954947B2 - 経路情報変換機能を有するノード装置 - Google Patents

Description

本発明は、経路情報追加の運用ルールが異なる複数のドメインに分割された大規模ネットワークにおいても、経路情報変換機能を備えることにより、情報の欠落や重複を生じることなく経路情報を適切に収集することの可能な経路トレースを実現するノード装置に関する。

ＧＭＰＬＳ（Generalized Multi−Protocol Label Switching）／ＭＰＬＳは、ラベル情報に従ってデータ転送を行う技術である。ＧＭＰＬＳにおけるラベル情報とは、パケットの先頭に実際に添付される固定長ラベルを意味するだけでなく、時間分割伝送にあってはパケットのデータが収容されるタイムスロットがこれに相当し、光多重伝送にあってはパケットのデータを搬送する光の波長がこれに相当する。特に、パケットの先頭に添付された固定長ラベルを用いて転送するネットワークをＭＰＬＳ網と呼ぶ。なお、ＧＭＰＬＳ網では、ＭＰＬＳ網で使用される固定長ラベルも含めいずれか、もしくはいくつかのラベル情報が用いられる。

例えば、固定長ラベルを用いるパケット転送では、中継ノード（ＬＳＲ：Label Switched Router）は、入力ラベル＆入力ＩＦ（インタフェース）に対する出力ラベル＆出力ＩＦの関係を示すラベルテーブルを保持する。そして、パケット中継時には、受信したパケットの宛先アドレスではなく、パケットに添付されているラベルに従って出力ＩＦを決定し、パケットに添付されているラベルを出力ラベルに書き換え中継する。これを繰り返すことにより、宛先までパケットを高速に送信することができる。なお、ＧＭＰＬＳ／ＭＰＬＳ網の入口の中継ノード（始点ノード）が最初にラベルを添付する。

図１を参照して、パケット中継方法について説明する。ＬＳＲ１を始点としてＬＳＲ２からＬＳＲ４へパケットを転送する。まず、ＬＳＲ１は転送するパケット１０にラベルａを添付する。そして、ＬＳＲ２はラベルａを持つパケットをＩＦ＃１から受信すると、ラベルａとＩＦ＃１の組み合わせでラベルテーブル１２を検索し、出力ＩＦとしてＩＦ＃２及び出力ラベルとしてラベルｂを獲得する。そして、パケットのラベルを出力ラベルであるラベルｂに書き換えた後、パケットを出力ＩＦであるＩＦ＃２に出力する。これを繰り返し、終端のＬＳＲ４（終点ノード）までパケットを転送する。このように固定長のラベルに従い転送することにより、パケット中継の高速化を図ることができる。

さらに中継ノードにおいて帯域制御と各ラベルを関連付けることにより、各パケットフローに対して帯域保証を行うことができる。

時分割伝送では、各ノードが入力タイムスロット＆入力ＩＦに対する出力タイムスロット＆出力ＩＦの関係を示すラベルテーブルを保持する。そして、各ノードは、受信ＩＦと受信タイムスロットから出力ＩＦと出力タイムスロットを決定し、データを出力ＩＦの出力タイムスロットに出力する。これを繰り返すことにより、宛先までデータを送信する。

光多重伝送では、各ノードが入力光波長＆入力ＩＦに対する出力光波長＆出力ＩＦの関係を示すラベルテーブルを保持する。そして、各ノードは、受信ＩＦと受信光波長から出力ＩＦと出力光波長を決定し、受信光波長を出力光波長に変換し、出力ＩＦに出力する。これを繰り返すことにより、宛先までデータを送信する。

ＧＭＰＬＳとは、上記のような、固定長ラベル、タイムスロット、光波長をラベルとして扱うことにより、同一の仕組みで転送を行う技術である。

ＧＭＰＬＳ／ＭＰＬＳでは、各ノードでラベルテーブルを構築する必要がある。そのために、図２に示すようなパス確率シグナリングプロトコル（ＣＲ−ＬＤＰ／ＲＳＶＰ−ＴＥ等）が用いられる。

以下ではＲＳＶＰ−ＴＥを例に取り、ラベルテーブルを構築することによるパス確立の動作を説明する。パス確立を要求する始点ノードＬＳＲ１は、パスの終点ノードＬＳＲ４までパス確立要求メッセージ（Ｐａｔｈメッセージ）１４をＨｏｐ−ｂｙ−Ｈｏｐで送信する。下記の例では、明示的に経路を指定するため、Ｐａｔｈメッセージ１４中に経由する中継ノードの情報１６が挿入されている。Ｐａｔｈメッセージ１４を受信した終点ノードＬＳＲ４は、ラベルの割り当てを行うパス確立応答メッセージ（Ｒｅｓｖメッセージ）１８をＰａｔｈメッセージ１４が送られてきた経路に沿って始点ノードＬＳＲ１へ返信する。このとき、Ｒｅｓｖメッセージ１８に格納されているラベル２０をラベルテーブルに登録することにより、データを転送するためのラベルテーブル２４が構築される。Ｐａｔｈ／ＲｅｓｖメッセージともにパスＩＤ２２が格納されており、ラベルテーブルにはパスＩＤも合わせて登録される。

以下ではＲＳＶＰ−ＴＥを例に取り、経路トレース機能を実現するための従来手法について説明する。ＲＳＶＰにおいて経路トレースを実現する手法としてRecord Route Object（ＲＲＯ）を用いた手法がＩＥＴＦ標準で定義されている（ＲＦＣ３２０９，ＲＦＣ３４７７）。図３を参照してその動作を説明する。図３の（ａ）欄には経路トレースを行うパスとパス上のノードとその識別子（Ａ，Ｂ，Ｃ・・・・Ｉ）および入出力インターフェースの番号（１または２）が示されている。（ｂ）欄はノード間で転送されるパス確立要求メッセージを示し、（ｃ）欄はパス確立応答メッセージを示す。経路トレースを要求する始点ノードＡは、パス確立のためのパス確立要求（Ｐａｔｈ）メッセージに経路トレースを要求するためのオブジェクトＲＲＯを挿入するとともに、ＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとして自身のノード識別子（Ａ）、および出力インタフェースの番号（２）を付与した上で、Ｈｏｐ−ｂｙ−ｈｏｐで送信する。Ｐａｔｈメッセージを受信した中間ノードは、ＲＲＯ ｏｂｊｅｃｔが挿入されていることから、経路トレース機能が有効になっていると判断し、自身のノード識別子（Ａ〜Ｈ）およびパスが通過する出力インタフェースの番号（１または２）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてリストに追加した上でＰａｔｈメッセージを次ｈｏｐへ転送する。中継ノードはこの手順をそれぞれ実施し、最終的にＰａｔｈメッセージが経由したノードおよびインタフェース番号のリストを含んだＲＲＯが、Ｐａｔｈメッセージによって終点ノードまで運ばれる。Ｐａｔｈメッセージを受信した終点ノードＩは、応答（Ｒｅｓｖ）メッセージにＲＲＯ ｏｂｊｅｃｔおよび自身の識別子（Ｉ）および出力インタフェースの番号（１）を含むｓｕｂ−ｏｂｊｅｃｔを挿入し、Ｐａｔｈメッセージが送られてきた経路に沿って始点ノードＡへ返信する。ＲＲＯ ｏｂｊｅｃｔを含むＲｅｓｖメッセージを受信した中間ノードは自身のノード識別子および、パスが通過する出力インタフェースの情報をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてリストに追加した上で次ｈｏｐへＲｅｓｖメッセージを転送する。最終的にはＲｅｓｖメッセージが経由したノードおよびインターフェースの番号のリストを含んだＲＲＯが、Ｒｅｓｖメッセージによって始点ノードＡまで運ばれる。以上の手順を実施することにより、それぞれのノードはＰａｔｈメッセージから自身の上流に位置するノード群のリストを、Ｒｅｓｖメッセージから自身の下流に位置するノード群のリストを取得し、両情報から、確立されたパスが経由しているノードの情報を取得することができる。例えばノードＥにおいては、ノードＤから受け取ったＰａｔｈメッセージ２６からノードＥの上流に位置するノード群のリストが得られ、ノードＦから受け取ったＲｅｓｖメッセージ２８からノードＥの下流に位置するノード群のリストが得られる。なお、このＰａｔｈメッセージとＲｅｓｖメッセージのやり取りはパス確立時に限らず、パス確立後においても経路情報の確認のため行なわれることがある。

ところで、ネットワークが大きくなってくると、ネットワークを複数のドメインに分割して運用する場合がある。この場合に、ドメイン内のノードが連携するためにＩＮＮＩ（Internal Network−Node Interface）シグナリングプロトコル、ドメインの境界ノードが連携するためにＥＮＮＩ（External Network−Node Interface）シグナリングプロトコルが用いられる。

複数のドメインに分割され、ＩＮＮＩシグナリングプロトコルと、ＥＮＮＩシグナリングプロトコルが用いられる場合も上記と同様の手順で、経路トレース機能が提供される。図４に示すように、ドメイン内のノード（ノードＢ，Ｅ，Ｈ）は、ＩＮＮＩシグナリングプロトコルを処理する、図中白丸で示すＩＮＮＩシグナリング処理部を持っている。一方、ドメインの境界に位置する境界ノード（ノードＡ，Ｃ，Ｄ，Ｆ，Ｇ，Ｉ）は、ＩＮＮＩシグナリング処理部と、ＥＮＮＩシグナリングプロトコルを処理する、図中黒丸で示すＥＮＮＩシグナリング処理部を持っている。ＩＮＮＩシグナリング処理部、ＥＮＮＩシグナリング処理部は、前述した経路トレース機能とほぼ同様の動作を行う。ＩＮＮＩシグナリング処理部とＥＮＮＩシグナリング処理部を有する境界ノードは、ＩＮＮＩシグナリング処理部が受信した経路情報リストをＩＮＮＩシグナリング処理部に引き渡すこと、あるいは、ＥＮＮＩシグナリング処理部が受信した経路情報リストをＩＮＮＩシグナリング処理部に引き渡すことが必要になる。そして、境界ノードは引き渡された経路情報リストに自身のノード識別子、および、出力インタフェースの番号を追加し、次のノードに制御メッセージ（Ｐａｔｈ／Ｒｅｓｖメッセージ）を転送する。例えば、ノードＣのＥＮＮＩシグナリング処理部は隣接ドメインのノードＤからＥＮＮＩシグナリングプロトコルの制御メッセージ（Ｒｅｓｖメッセージ）を受信すると、受信制御メッセージ中の経路情報リストをＩＮＮＩシグナリング処理部に引き渡す。そして、ＩＮＮＩシグナリング処理部は、自身のノード識別子および出力インタフェースの番号をリストに追加した上で次ｈｏｐへＲｅｓｖメッセージを転送する。ＥＮＮＩシグナリングプロトコルの詳細については下記非特許文献１に説明されている。ＩＮＮＩシグナリングプロトコルの詳細については、下記に非特許文献２として挙げたＲＦＣ３２０９に記載されている。

複数のドメインに分割されたネットワークにおいて、ＩＮＮＩシグナリングプロトコルとＥＮＮＩシグナリングプロトコルが使用される場合、ＩＮＮＩシグナリングプロトコルはドメイン内の管理ルールに従い、ＥＮＮＩシグナリングプロトコルはドメイン間で取り決められた管理ルールに従い、運用される。図４に示した例では、ＥＮＮＩシグナリングプロトコルおよびＩＮＮＩシグナリングプロトコルのいずれにおいても、ノードとノードを結ぶ各リンクについて、メッセージがリンクへ入力される側（以下、「リンクの入力側」と称する）のノードがその識別子と出力インターフェース（リンクから見れば入力インターフェース）の番号を経路情報に追加する、という運用ルールが適用されている。一方、例えばＩＮＮＩシグナリングプロトコルにおいては、リンクの入力側のノードがそのリンクについての情報（ノード識別子＋インターフェース番号）を追加するという運用ルールが適用され、ＥＮＮＩシグナリングプロトコルにおいては、リンクの出力側のノードがそのリンクについての情報を追加するという運用ルールが適用される、といったように、ＩＮＮＩとＥＮＮＩとで適用される運用ルールが異なる場合がある。この場合、以下に説明するように情報に不整合が生じ、正しく経路を把握できないという問題がある。

たとえば、図５に示すように、ＩＮＮＩシグナリングプロトコルではリンクの入力側のノードが情報を経路情報リストに追加するが、ＥＮＮＩシグナリングプロトコルではリンクの出力側のノードが情報を追加するという運用になる場合がある。この場合ノードＧとノードＨの間のリンクに関してはＩＮＮＩの管理ルールに従いノードＨが自ノードの情報（Ｈ．１）を追加し、ノードＦとノードＧの間のリンクに関してはＥＮＮＩの運用ルールに従いノードＦが自ノードの情報（Ｆ．２）を追加する。そのため、ノードＧに関する情報が追加されないという問題がある。ノードＦについてはそのＥＮＮＩ処理部がリンクＦ−Ｇに関する情報（Ｆ．２）を追加し、さらにＩＮＮＩ処理部がリンクＥ−Ｆに関する情報（Ｆ．１）を追加することになる。それに対してノードＧのＥＮＮＩ処理部およびＩＮＮＩ処理部はいずれも情報を追加することなくメッセージを転送することになる。同様に、ノードＤに関しても情報が追加されない。

また、ＩＮＮＩ／ＥＮＮＩシグナリングプロトコルの運用では、ドメイン内部で使用しているアドレス空間とドメイン間の連携で使用するネットワーク全体で使用するアドレス空間を独立にすることができるという特徴がある。独立したアドレス空間で運用された場合を図６に示す。ＩＮＮＩドメイン毎に独立にアドレスを割り当てることができるため、重複したアドレスが経路情報リストに格納されてしまう問題点が発生する可能性がある。図６に示す例では、経路情報リストにはノードａ、ノードｂ、ノードｃが複数格納されてしまう問題点が発生する。
Intra-Carrier E-NNI Signaling Specification, February 27, 2004（http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdfからダウンロード可能） ＲＦＣ３２０９

したがって本発明の目的は、運用ルールの異なる領域に跨って確立されたパスの経路情報を欠落や重複なく適切に収集することを可能にするノード装置を提供することにある。

前述の課題を解決するノード装置は、自ノードを通るパスに沿って隣接する一方のノードから、該パスに沿って転送されそれまでに通った経路を示す経路情報を含み経路に関する情報を要求する経路情報要求メッセージを受信したとき、適用される運用ルールに従って自ノードの情報を該経路情報要求メッセージに含まれる経路情報に追加する経路情報追加部と、該経路要求メッセージに含まれる経路情報に第１の運用ルールとは異なる第２の運用ルールに従う経路情報が含まれるとき、該第２の運用ルールに従う経路情報を第１の運用ルールに従う経路情報に変換する経路情報変換部とを具備する。

このノード装置は、前記第１の運用ルールに従う経路情報と前記第２の運用ルールに従う経路情報との対応関係を記憶する経路情報変換テーブルをさらに具備し、前記経路情報変換部は、該経路情報変換テーブルを用いて経路情報の変換を行なうことが好適である。

上記の構成のノード装置をドメイン境界ノードに用いることにより、経路情報追加の運用ルールが異なる複数の領域に跨るパスの経路トレースを適切に実施することができる。

図７は本発明の一実施形態に係るノード装置の一例の構成を示すブロック図である。ノード装置３０のＥＮＮＩ処理部３２はドメイン外の領域からのＰａｔｈメッセージ、ＲｅｓｖメッセージなどのＥＮＮＩ制御メッセージを受信するＥＮＮＩ制御メッセージ受信部３４と、受信したＥＮＮＩ制御メッセージに経路トレースを要求するＲＲＯ（Record Route object）が含まれているとき、ＥＮＮＩの運用ルールに従って経路情報を追加するＥＮＮＩ経路情報追加部３６を備えたＥＮＮＩ経路情報処理部３８と、ドメイン外の領域へＥＮＮＩ制御メッセージを送信するＥＮＮＩ制御メッセージ送信部４０を備えている。ＥＮＮＩ制御メッセージ受信部３４で受信されＥＮＮＩ経路情報処理部３８において処理されるメッセージのうち、ドメイン内を宛先とするものに含まれる経路情報は、必要に応じて情報を追加した後、ＩＮＮＩ処理部４２へ引き渡される。

ＩＮＮＩ処理部４２はドメイン内の領域からのＰａｔｈメッセージ、ＲｅｓｖメッセージなどのＩＮＮＩ制御メッセージを受信するＩＮＮＩ制御メッセージ受信部４４と、受信したＩＮＮＩ制御メッセージに経路トレースを要求するＲＲＯが含まれている時、ＩＮＮＩの運用ルールに従って経路情報を追加するＩＮＮＩ経路情報追加部４６を備えたＩＮＮＩ経路情報処理部４８と、ドメイン内の領域へＩＮＮＩ制御メッセージを送信するＩＮＮＩ制御メッセージ送信部５０を備えている。ＩＮＮＩ制御メッセージ受信部４４で受信されＩＮＮＩ経路情報処理部４８において処理されるメッセージのうち、ドメイン外を宛先とするものに含まれる経路情報は、必要に応じて情報を追加した後、ＥＮＮＩ処理部３２へ引き渡される。

ＥＮＮＩ経路情報処理部３８に含まれるＥＮＮＩ経路情報変換テーブル５２は、ドメイン外の領域からドメイン内の領域へ向かうメッセージに含まれる経路情報の中で変換が必要なものについて変換前の経路情報と変換後の経路情報の組み合わせを記憶する一種のデータベースである。ＥＮＮＩ経路情報変換部５４はメッセージに含まれる経路情報をＥＮＮＩ経路情報変換テーブル５２を参照して変換する。

ＩＮＮＩ経路情報処理部４８に含まれるＩＮＮＩ経路情報変換テーブル５６は、ドメイン内の領域からドメイン外の領域へ向かうメッセージに含まれる経路情報の中で変換が必要なものについて変換前の経路情報と変換後の経路情報の組み合わせを記憶するデータベースである。ＩＮＮＩ経路情報変換部５８はメッセージに含まれる経路情報をＩＮＮＩ経路情報変換テーブル５６を参照して変換する。

図８は図７に示した構成のノード装置における処理の一例を示すフローチャートである。図８において、まず、ＥＮＮＩ制御メッセージ受信部３４がＲＲＯを有するＥＮＮＩ制御メッセージを受信すると（ステップ１０００）、ＥＮＮＩ経路情報処理部３８のＥＮＮＩ経路情報追加部３６に引き渡される。ＥＮＮＩ経路情報追加部３６では、ＥＮＮＩシグナリングプロトコルにおいて適用される運用ルールが、メッセージがリンクから出力される側（以下「リンクの出力側」と称する）のノードに関する情報を追加するルールであれば（ステップ１００２）自ノードの情報（ノードの識別子＋インターフェースの番号）を経路情報に追加する（ステップ１００４）。次に、メッセージを転送すべき宛先が自ノードが属するドメイン内のノードであるかが判定され（ステップ１００６）、宛先がドメイン外であるとき、ステップ１００８に進む。そして、ＥＮＮＩの運用ルールがリンクの入力側のノードの情報を追加するルールであれば（ステップ１００８）、ＥＮＮＩ経路情報追加部３６において、自ノードの情報を経路情報に追加する（ステップ１０１０）、そして、ＥＮＮＩ制御メッセージ送信部４０においてメッセージが送信される（ステップ１０１２）。

ＩＮＮＩ制御メッセージ受信部４４がＰＲＯを有するＩＮＮＩ制御メッセージを受信すると（ステップ１０１４）、ＩＮＮＩ経路情報処理部４８のＩＮＮＩ経路情報追加部４６に引き渡される。ＩＮＮＩ経路情報追加部４６では、ＩＮＮＩシグナリングプロトコルにおいて適用される運用ルールが、リンクの出力側のノードに関する情報を追加するルールであれば（ステップ１０１６）自ノードの情報を経路情報に追加する（ステップ１０１８）。次に、メッセージを転送すべき宛先が自ノードが属するドメイン外のノードであるかが判定され（ステップ１０２０）、宛先がドメイン内であるとき、ステップ１０２２へ進む。そして、ＩＮＮＩの運用ルールがリンクの入力側のノードの情報を追加するルールであれば（ステップ１０２２）、ＩＮＮＩ経路情報追加部４６において、自ノードの情報を経路情報に追加する（ステップ１０２４）。そして、ＩＮＮＩ制御メッセージ送信部５０においてメッセージが送信される（ステップ１０２６）。

ステップ１００６において、ドメイン外の領域から受信したメッセージの転送先が自ノードが属するドメイン内のノードであると判定されるとき、ＥＮＮＩ経路情報変換部５４では、まず、転送されるメッセージについて直前に適用されていた運用ルールとこれから適用されるべき運用ルールが異なっていて経路情報の変換が必要かどうかを判定し、（ステップ１０２８）、変換が必要であるときはメッセージに含まれる経路情報と同じエントリがＥＮＮＩ経路情報変換テーブル５２に登録されているかを確認し、マッチしたものを変換が必要な経路情報として抽出し（ステップ１０３０）、ＥＮＮＩ経路情報変換テーブル５２を用いて変換する（ステップ１０３２）。その後、ＩＮＮＩ処理部のステップ１０２２の処理に変換する。

ステップ１０２０において、ドメイン内の領域から受信したメッセージの転送先がドメイン外であると判定されるとき、ＩＮＮＩ経路情報変換部５８では、まず、転送されるメッセージについて直前に適用されていた運用ルールとこれから適用されるべき運用ルールが異なっていて経路情報の変換が必要かどうかを判定し、（ステップ１０３４）、変換が必要であるときはメッセージに含まれる経路情報と同じエントリがＩＮＮＩ経路情報変換テーブル５６に登録されているかを確認し、マッチしたものを変換が必要な経路情報として抽出し（ステップ１０３６）、ＩＮＮＩ経路情報変換テーブル５２を用いて変換する（ステップ１０３８）。その後、ＥＮＮＩ処理部のステップ１００８の処理に変換する。

図９を参照し、パス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ）を用いて、ノードＡ→ノードＢ→ノードＣ→ノードＸ→ノードＤ→ノードＥ→ノードＦ→ノードＹ→ノードＧ→ノードＨ→ノードＩの経路のパスを確立する場合において、パス確立応答メッセージ（Ｒｅｓｖメッセージ）による経路トレース機能の動作の第１の例を説明する。

図９に示すネットワークは、複数のドメインに分割され、ドメイン間で使用されるＥＮＮＩシグナリングプロトコルと各ドメイン間で使用されるＩＮＮＩシグナリングプロトコルとで独立した運用ルールが適用されている。ＥＮＮＩシグナリングプロトコルでは各リンクの出力側のノードの情報（以下、出力インタフェース情報と称す）が収集され、ドメイン内で使用されるＩＮＮＩシグナリングプロトコルでは各リンクの入力側のノードの情報（以下、入力インタフェース情報と称す）が収集される。通常、ドメイン毎に独立な運用ルールで運用されているため、全てのドメイン内で同じように入力インタフェース情報を収集するとは限らないが、説明を簡単にするため、同じルールで運用しているとする。また、Ｒｅｓｖメッセージによる経路トレース機能の動作を例に取って説明するが、パス確立要求メッセージ（Ｐａｔｈメッセージ）による経路トレースでも同様の動作で実現可能である。

始点ノードＡは、パスを確立する経路に沿ってパス確立要求メッセージ（Ｐａｔｈメッセージ）をＨｏｐ−ｂｙ−Ｈｏｐで転送する。そして、以下の動作によりＲｅｓｖメッセージによる経路トレース機能が実現される。

Ｐａｔｈメッセージを受信した終点ノードＩはパス確立応答時にＲＲＯをパス確立応答メッセージ（Ｒｅｓｖメッセージ）に含めることにより、経路トレースを要求する。終点ノードＩは、ドメイン内のノードＨとはＩＮＮＩシグナリングプロトコルを使って連携するため、ノードＨとのリンクについての入力インタフェース情報、すなわち自ノード識別子＋インタフェース番号（Ｉ．１）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに格納し、そのＲＲＯを格納したＩＮＮＩシグナリングプロトコルのＲｅｓｖメッセージ（以下、ＩＮＮＩ Ｒｅｓｖメッセージと称す）６０をノードＨへ送信する。

ＩＮＮＩ Ｒｅｓｖメッセージ６０を受信したノードＨは、ドメイン内のノードＧとはＩＮＮＩシグナリングプロトコルを使って連携するため、ノードＧとのリンクの入力インタフェース情報、すなわち自ノード識別子＋インタフェース番号（Ｈ．１）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加し、そのＲＲＯを格納したＩＮＮＩ Ｒｅｓｖメッセージ６２を前段ノードＧへ送信する。

ＩＮＮＩ Ｒｅｓｖメッセージ６２を受信したドメイン境界ノードＧは、隣接ドメインのノードＹとはＥＮＮＩシグナリングプロトコルを使って連携する。ノードＨとノードＧ間のＩＮＮＩ側のリンクについての情報はすでにリンクの入力側のノードＨがＲＲＯに追加しており、かつ、ノードＧとノードＹ間のＥＮＮＩ側のリンクについての情報はリンクの出力側のノードＹが出力インタフェース情報を追加するため、ノードＧは経路情報を追加しない。言い換えると、この例のようなＩＮＮＩ／ＥＮＮＩシグナリングプロトコルのＲＲＯ運用ルールの場合は、ドメイン外ヘＥＮＮＩシグナリングプロトコルのＲｅｓｖメッセージ（以下、ＥＮＮＩ Ｒｅｓｖメッセージと称す）を送信するノードは経路情報をＲＲＯに追加しない。しかしながら、ドメイン間で受け渡される経路情報は出力インタフェース情報であり、これに合わせるため、ドメイン６４内で収集した経路情報を経路情報変換テーブルを用いて入力インタフェース情報から出力インタフェース情報に変換する。経路情報変換テーブルはリンクの両端のノードの情報を対応付けた以下のような表である。ＲＲＯに格納されている全てのＲＲＯ ｓｕｂ−ｏｂｊｅｃｔを検索し、矢印６６で示すように、経路情報変換テーブルにマッチした全てのＲＲＯ ｓｕｂ−ｏｂｊｅｃｔ（Ｈ．１およびＩ．１）を（Ｇ．２およびＨ．２へ）変換する。変換を行ったＲＲＯを格納したＥＮＮＩ Ｒｅｓｖメッセージ６８をノードＹへ転送する。

ＥＮＮＩ Ｒｅｓｖメッセージ６８を受信したノードＹは、ノードＧとのリンクの出力インタフェース情報（Ｙ．２）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加し、そのＲＲＯを格納したＥＮＮＩ Ｒｅｓｖメッセージ７０をノードＦへ送信する。

ＥＮＮＩ Ｒｅｓｖメッセージを受信したドメイン境界ノードＦは、ＥＮＮＩシグナリングの運用ルールに従い、つまり、出力インタフェース情報を収集しているため、ノードＹとのリンクの出力インタフェース情報、すなわち自ノード識別子＋インタフェース番号（Ｆ．２）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加する。そして、ドメイン内のノードＥとはＩＮＮＩシグナリングプロトコルを使って連携するため、さらに、ノードＥとのリンクの入力インタフェース情報、すなわち自ノード識別子＋インタフェース番号（Ｆ．１）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加し、そのＲＲＯを格納したＩＮＮＩ Ｒｅｓｖメッセージ７２をノードＥへ送信する。

同様の処理を繰り返し、Ｒｅｓｖメッセージを始点ノードＡまで転送する。

ＩＮＮＩ Ｒｅｓｖメッセージ７４を受信したドメイン境界ノード（始点ノード）Ａは、ドメイン間で受け渡される経路情報は出力インタフェース情報であるため、ドメイン７６内で収集した経路情報を経路情報変換テーブルを用いて矢印７８で示すように入力インタフェース情報（Ｂ．１，Ｃ．１）から出力インタフェース情報（Ａ．２，Ｂ．２）に変換する。変換を行ったＲＲＯに格納されている情報７９によりパスが通過する経路全体を把握することができる。

なお、経路情報変換テーブルは、管理者により手動で構築してもよいし、ルーティングプロトコルで交換されているドメイン内のリンク情報等を流用してもよい。

上記の動作において、境界ノードＧと境界ノードＦが内部でどのような動作を行ったか、既に説明済の図７のブロック図および図８のフローチャートを参照して説明する。

まずは、ＩＮＮＩ Ｒｅｓｖメッセージを受信するドメイン境界ノードＧの動作について説明する。

ステップ１０１４） 経路情報リスト（ＲＲＯ）を持ったＩＮＮＩ Ｒｅｓｖメッセージを受信する（ＩＮＮＩ制御メッセージ受信部４４）。

ステップ１０１６） ＩＮＮＩシグナリングプロトコルでは経路情報としてリンクの入力インターフェース情報を追加する運用ルールが適用されているため、ここでは経路情報は追加されない。

ステップ１０２０） Ｒｅｓｖメッセージを転送するノードはドメイン内かドメイン外かを確かめる。この例では、ノードＹはドメイン外に存在する。（ＩＮＮＩ経路情報処理部４８）
ステップ１０３４） 経路情報の変換が必要であるか否かを確かめる。この例では、ＩＮＮＩシグナリングプロトコルとＥＮＮＩシグナリングプロトコルにおける経路トレース機能の運用ルールが異なり、かつ、ドメイン外の連携であるＥＮＮＩシグナリングの運用ルールに合わせる必要があるため、経路情報の変換が必要である。（ＩＮＮＩ経路情報変換部５８）
ステップ１０３６） ＲＲＯに格納されている経路情報と同じエントリが経路情報変換テーブル５６に登録されているかを確認し、マッチしたものを変換が必要な経路情報として抽出する。（ＩＮＮＩ経路情報変換部５８）
ステップ１０３８） 経路情報変換テーブル５６を用いて、入力インタフェース情報を出力インタフェース情報に変換する。経路情報変換テーブル５６に格納されているリンク情報によって変換することで、リンクの一方の端点の情報を他方の端点の情報に変換することができる。（ＩＮＮＩ経路情報変換部５８）
ステップ１００８） ＥＮＮＩシグナリングプロトコルではリンクの出力インターフェース情報を追加する運用ルールが適用されるので、ここでは経路情報の追加はない。

ステップ１０１２） 変換を行ったＲＲＯを格納したＥＮＮＩ Ｒｅｓｖメッセージを前段ノードＦへ転送する。（ＥＮＮＩ制御メッセージ送信部４０）
次に、ＥＮＮＩ Ｒｅｓｖメッセージを受信するドメイン境界ノードＦの動作について説明する。

ステップ１０００） 経路情報リスト（ＲＲＯ）を持ったＥＮＮＩ Ｒｅｓｖメッセージを受信する（ＥＮＮＩ制御メッセージ受信部３４）。

ステップ１００２） ＥＮＮＩシグナリングプロトコルでは、リンクの出力インターフェース情報が追加されるので、出力インタフェース情報（自ノード識別子＋インタフェース番号）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加する。

ステップ１００６） Ｒｅｓｖメッセージを転送するノードはドメイン内かドメインが以下を確かめる。この例では、前段ノードＥはドメイン内に存在する。（ＥＮＮＩ経路情報処理部３８）
ステップ１０２８） 経路情報の変換が必要であるか否かを確かめる。この例では、ＩＮＮＩシグナリングプロトコルとＥＮＮＩシグナリングプロトコルにおける経路トレース機能の運用ルールが異なるが、ドメイン外の連携であるＥＮＮＩシグナリングの運用ルールに合わせるため、ＥＮＮＩで収集した経路情報を変換する必要はない。（ＥＮＮＩ経路情報変換部５４）
ステップ１０２２） ＩＮＮＩシグナリングプロトコルではリンクの入力インターフェース情報を追加する運用ルールが適用されるので、入力インタフェース情報（自ノード識別子＋インタフェース番号）をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加する。

ステップ１０２６） 経路情報を追加したＲＲＯを格納したＥＮＮＩ ＲｅｓｖメッセージをノードＦへ転送する。（ＩＮＮＩ制御メッセージ送信部５０）
以上の機能を実装することにより、ＩＮＮＩシグナリングプロトコルと、ＥＮＮＩシグナリングプロトコルの経路トレース機能において、異なる位置を経路として記録するような運用が行われた場合においても、一貫性のある経路情報を収集（トレース）することが可能になる。

前述の第１の例では、ＥＮＮＩシグナリングプロトコルではリンクの出力インタフェース情報が収集され、ドメイン内で使用されるＩＮＮＩシグナリングプロトコルではリンクの入力インタフェース情報が収集されていた。図１０に示す第２の例では、この運用ルールとは異なり、ＥＮＮＩシグナリングプロトコルでは入力インタフェース情報が収集され、ドメイン内で使用されるＩＮＮＩシグナリングプロトコルでは出力インタフェース情報が収集されるとして、経路トレース機能の動作を説明する。

まず、第１の例と同様にパス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ）を用いて、ノードＡ→ノードＢ→ノードＣ→ノードＸ→ノードＤ→ノードＥ→ノードＦ→ノードＹ→ノードＧ→ノードＨ→ノードＩの経路のパスを確立する。この場合におけるパス確立応答メッセージ（Ｒｅｓｖメッセージ）による経路トレース機能の動作が図１０に示されている。ほぼ第１の例と同様の動作を行うが、以下の点が異なる。

・ＩＮＮＩ Ｒｅｓｖメッセージ８０を受信したドメイン境界ノードＧは、第１の例と異なり、ドメイン８２間での経路情報は出力インタフェース情報であるため、ドメイン８２内で収集した経路情報を経路情報変換テーブルを用いて、矢印８４で示すように、出力インタフェース情報（Ｇ．２，Ｈ．２）から入力インタフェース情報（Ｈ．１，Ｉ．１）に変換する。

・ＥＮＮＩ Ｒｅｓｖメッセージ８６を受信したドメイン境界ノードＦは、ノードＦとノードＹ間のＥＮＮＩ側のリンク情報はすでにノードＹがＲＲＯに追加しているため、経路情報として追加する必要はなく、また、ノードＦとノードＥ間のＩＮＮＩ側のリンク情報もノードＥが出力インタフェース情報を追加するため、経路情報を追加する必要がない。言い換えると、この例のようなＩＮＮＩ／ＥＮＮＩシグナリングプロトコルのＲＲＯ運用ルールの場合は、ドメイン内へＩＮＮＩ Ｒｅｓｖメッセージを送信するノードは経路情報をＲＲＯに追加する必要はない。ノードＦは受信したＲＲＯを変更せずＩＮＮＩ Ｒｅｓｖメッセージ８８を前段ノードＥへ転送する。

・ＩＮＮＩ Ｒｅｓｖメッセージ９０を受信したドメイン境界ノード（始点ノード）Ａは、ノードＢとのリンクの出力インターフェース情報（Ａ．２）を追加する。そしてドメイン間での経路情報は入力インタフェース情報であるため、ドメイン８９内で収集した経路情報を経路情報変換テーブルを用いて出力インタフェース情報（Ａ．２，Ｂ．２）から入力インタフェース情報（Ｂ．１，Ｃ．１）に変換する。変換を行ったＲＲＯに格納している経路情報９５によりパスが通過する経路全体を把握することができる。

前述の第１の例では、ＥＮＮＩシグナリングプロトコルでは出力インタフェース情報が追加され、ドメイン内で使用されるＩＮＮＩシグナリングプロトコルでは入力インタフェース情報が追加される。第２の例では、ＥＮＮＩシグナリングプロトコルでは入力インタフェース情報が追加され、ドメイン内で使用されるＩＮＮＩシグナリングプロトコルでは出力インタフェースの情報が追加される。そしていずれも、最終的にＥＮＮＩシグナリングの運用ルールに従う情報を収集する、第３の例では、最終的にＩＮＮＩシグナリングの運用ルールに従う情報収集を行う場合の経路トレース機能の動作を説明する。なお、第３の例におけるＥＮＮＩおよびＩＮＮＩの運用ルールは、第２の例と同じ運用ルールとする。

まず、これまでの例と同様にパス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ）を用いて、ノードＡ→ノードＢ→ノードＣ→ノードＸ→ノードＤ→ノードＥ→ノードＦ→ノードＹ→ノードＧ→ノードＨ→ノードＩの経路のパスを確立するとする。この場合におけるパス確立応答メッセージ（Ｒｅｓｖ メッセージ）による経路トレース機能の動作を図１１に示す。ほぼこれまでに示した例と同様の動作を行うが、以下の点が異なる。

・ＩＮＮＩ Ｒｅｓｖメッセージ９６を受信したドメイン境界ノードＧは、ＩＮＮＩシグナリングの運用ルールに従い、つまり、出力インタフェース情報を追加しているため、自ノードの出力インタフェース情報Ｇ．２をＰＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加する。そして、ドメイン外のノードＹへ通信するときのＥＮＮＩシグナリングプロトコルの運用ルールに従い、自ノードの入力インタフェース情報Ｇ．１をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加する。そのＲＲＯを格納したＥＮＮＩ Ｒｅｓｖメッセージ９８をノードＹへ送信する。

・ＥＮＮＩ Ｒｅｓｖメッセージ１００を受信したドメイン境界ノードＦは、ノードＦとノードＹ間のＥＮＮＩ側のリンク情報はすでにノードＹがＲＲＯに追加しているため、経路情報として追加する必要はなく、また、ノードＦとノードＥ間のＩＮＮＩ側のリンク情報もノードＥが出力インタフェース情報を追加するため、経路情報を追加する必要がない。言い換えると、この例のようなＩＮＮＩ／ＥＮＮＩシグナリングプロトコルのＲＲＯ運用ルールの場合は、ドメイン内へＩＮＮＩ Ｒｅｓｖメッセージを送信するノードは経路情報をＲＲＯに追加しない。しかし、最終的に収集するのはドメイン内の運用ルールに追加した出力インタフェース情報であるため、ＥＮＮＩ区間で収集した経路情報を経路情報変換テーブルを用いて入力インタフェース情報（Ｇ．１，Ｙ．１）から出力インタフェース情報（Ｆ．２，Ｙ．２）に変換する。そのＲＲＯを格納したＩＮＮＩ Ｒｅｓｖメッセージ１０２をノードＥへ送信する。

第４の例では、第３の例と同様に、最終的にＩＮＮＩシグナリングの運用ルールに従って情報を収集する場合の経路トレース機能の動作を説明する。しかし、第３の例とは異なり、第４の例におけるＥＮＮＩおよびＩＮＮＩの運用ルールは、第１の例と同じ運用ルールとする。

まず、これまでの例と同様にパス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ）を用いて、ノードＡ→ノードＢ→ノードＣ→ノードＸ→ノードＤ→ノードＥ→ノードＦ→ノードＹ→ノードＧ→ノードＨ→ノードＩの経路のパスを確立するとする。この場合におけるパス確立応答メッセージ（Ｒｅｓｖメッセージ）による経路トレース機能の動作が図１２に示されている。ほぼこれまでの例と同様の動作を行うが、以下の点が異なる。

・ＩＮＮＩ Ｒｅｓｖメッセージ１０４を受信したドメイン境界ノードＧは、ノードＧとノードＨ間のＩＮＮＩ側のリンク情報はすでにノードＨがＲＲＯに追加しているため、経路情報として追加する必要はなく、また、ノードＧとノードＹ間のＥＮＮＩ側のリンク情報もノードＹが出力インタフェース情報を追加するため、経路情報を追加する必要がない。言い換えると、この例のようなＩＮＮＩ／ＥＮＮＩシグナリングプロトコルのＲＲＯ運用ルールの場合は、ドメイン内へＥＮＮＩ Ｒｅｓｖメッセージを送信するノードは経路情報をＲＲＯに追加しない。そのＲＲＯを格納したＥＮＮＩ ＲｅｓｖメッセージをノードＹへ送信する。

・ＥＮＮＩ Ｒｅｓｖメッセージ１０６を受信したドメイン境界ノードＦは、ＥＮＮＩシグナリングの運用ルールに従い、つまり、出力インタフェース情報を追加しているため、ノードＹとのリンクの出力インタフェース情報Ｆ．２をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加する。そして、最終的に収集されるのは入力インタフェース情報であるため、ＥＮＮＩ区間で収集した経路情報を経路情報変換テーブルを用いて出力インタフェース情報（Ｆ．２，Ｙ．２）から入力インタフェース情報（Ｇ．１，Ｙ．１）に変換する。そしてさらにノードＥとのリンクの入力インターフェース情報（Ｆ．１）を追加する。そのＲＲＯを格納したＩＮＮＩ Ｒｅｓｖメッセージ１０８をノードＦへ送信する。

これまでに説明した例ではドメイン間がノードを介して複数のリンクで接続されているが、ドメイン間が単一のリンクで直接的に接続されている場合も同様の動作となる。図１１および図１２に示された運用ルールおよび収集ルールが適用されるシステムにおいてドメイン間が単一のリンクで接続されている場合をそれぞれ図１３および図１４に示す。

ネットワークを複数のドメインに分割した場合、それぞれのドメインは独立した運用ルールで運用される可能性があることは前述し、これまでＩＮＮＩ／ＥＮＮＩシグナリングプロトコルの経路トレース機能で収集される場所が異なる例（リンクの入力インターフェース情報を追加するかリンクの出力インターフェース情報を追加するかで異なる例）を説明してきた。しかし、収集される場所だけでなく、ドメインの内外およびドメイン間で異なるアドレス空間を用いて運用される場合がある。そのような場合に対応するための動作を図１５を参照して説明する。下記では、説明を簡単にするため、ＩＮＮＩ／ＥＮＮＩシグナリングプロトコルで収集される情報は全て出力インタフェース情報とし、アドレス空間の変換だけを説明する。しかし、収集される場所が異なる場合であっても、アドレス空間の変換も同時に実施可能である。

これまでの例と同様にパス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ）を用いて、ノードＡ→ノードＢ→ノードＣ→ノードＸ→ノードＤ→ノードＥ→ノードＦ→ノードＹ→ノードＧ→ノードＨ→ノードＩの経路のパスを確立するとする。この場合におけるパス確立応答メッセージ（Ｒｅｓｖメッセージ）による経路トレース機能の動作が図１５に示されている。ほぼこれまでと同様の動作を行うが、以下の点が異なる。

・ＩＮＮＩ Ｒｅｓｖメッセージ１１０を受信したドメイン境界ノードＧは、ＩＮＮＩシグナリングの運用ルールに従い、つまり、リンクの出力インタフェース情報を収集しているため、自ノードの出力インタフェース情報ａ．２をＲＲＯ ｓｕｂ−ｏｂｊｅｃｔとしてＲＲＯに追加してメッセージ１１２とする。そして、ドメイン内外で使用しているアドレス空間が異なるため、ドメイン１１２内で収集した経路情報ａ．２，ｂ．２を経路情報変換テーブルを用いてＧ．２，Ｈ．２に変換してメッセージ１１４とする。下記の経路変換テーブルには、インタフェース番号を含んでいるが、ノード識別子だけでもよい。

・ＩＮＮＩ Ｒｅｓｖメッセージ１１６を受信したドメイン境界ノード（始点ノード）Ａは、ドメイン内外で使用しているアドレス空間が異なるため、ドメイン１１８内で収集した駅路情報ａ．２，ｂ．２を経路情報変換テーブルを用いてＡ．２，Ｂ．２に変換する。変換を行ったＲＲＯには各ドメインで独自に付与されるノード識別子ａ，ｂ，ｃ・・・ではなく、グローバルノードを識別する識別子Ａ，Ｂ，Ｃ・・・が使用されているので、これによりパスが通過する経路全体を把握することができる。

上記の例では、経路トレース情報として、ノード識別子＋インターフェース番号を収集している。経路情報としてノード識別子のみによるノード情報を収集情報として利用する経路トレース機能においても同様の動作が可能である。

以上説明したように、ドメイン毎に独立した管理ルールでＩＮＮＩ／ＥＮＮＩシグナリングプロトコルを運用した場合においても、始点ノードから終点ノードまでの一貫した経路トレース情報を収集することができる。具体的には、ＩＮＮＩ／ＥＮＮＩシグナリングプロトコルの経路トレース機能で収集される場所が、入力インタフェース、出力インタフェースの違いがある場合においても、入力インタフェース情報だけの収集、あるいは、出力インタフェース情報だけの収集が可能である。あるいは、ドメインの内外およびドメイン間で異なるアドレス空間を用いて運用される場合もドメイン外のアドレス空間での経路トレース情報の収集が可能である。

図７および図８を参照して説明した例では、経路情報変換テーブル５２，５６と経路情報変換部５４，５８は、ＥＮＮＩ処理部３２とＩＮＮＩ処理部４２とでそれぞれ別個に設けられている。しかしながら、その代わりとして、ＥＮＮＩ処理部３２とＩＮＮＩ処理部４２に共通のものとしてそれぞれ１つだけ設けることもできる。

また、これまでに説明した例ではいずれも、経路情報変換の処理量および変換テーブルの大きさを最小限にとどめるため、ＥＮＮＩおよびＩＮＮＩの間で共通に定められた１つの運用ルールに従う経路情報への変換が行なわれて、共通に定められた運用ルールに従う経路情報が収集される。しかしながら、それぞれのドメインにおいて独自に定められた運用ルールに従う経路情報を、それぞれのドメイン内の各ノードにおいて収集することも可能である。そのためには、メッセージがドメインの境界を跨って転送されるごとに、境界ノードにおいて、メッセージに含まれるすべての経路情報を、自ノードが属するドメインの運用ルールに従う経路情報に変換するように構成すれば良い。その場合には、境界ノードが備える経路情報変換テーブルには、少なくともパスの上流のすべてのノードに関する変換情報が格納される。

固定長ラベルを用いたパケット転送を説明する図である。 パス確立シグナリングプロトコルを説明する図である。 ＲＲＯを用いた経路トレースを説明する図である。 複数ドメインに分割された場合の経路トレースを説明する図である。 複数ドメインに分割された場合の問題を説明する図である。 複数ドメインに分割された場合の問題を説明する図である。 本発明の一実施形態に係るノード装置の構成の一例を示すブロック図である。 図７の構成のノード装置における処理の一例を示すフローチャートである。 経路トレース機能の動作の第１の例を示す図である。 経路トレース機能の動作の第２の例を示す図である。 経路トレース機能の動作の第３の例を示す図である。 経路トレース機能の動作の第４の例を示す図である。 図１１の例においてドメイン間が単一のリンクで接続されている場合の図である。 図１２の例においてドメイン間が単一のリンクで接続されている場合の図である。 経路トレース機能の動作の第５の例を示す図である。

Claims (6)

1. 経路情報の追加の際の運用ルールが異なる複数の領域に跨って確立されたパスの経路情報の適切な収集を可能とするノード装置であって、
   自ノードを通るパスに沿って隣接する一方のノードから、該パスに沿って転送されそれまでに通った経路を示す経路情報を含み経路に関する情報を要求する経路情報要求メッセージを受信したとき、適用される運用ルールに従って自ノードの情報を該経路情報要求メッセージに含まれる経路情報に追加する経路情報追加部と、
   該経路要求メッセージに含まれる経路情報に第１の運用ルールとは異なる第２の運用ルールに従う経路情報が含まれるとき、該第２の運用ルールに従う経路情報を第１の運用ルールに従う経路情報に変換する経路情報変換部とを具備するノード装置。
2. 前記第１の運用ルールに従う経路情報と前記第２の運用ルールに従う経路情報との対応関係を記憶する経路情報変換テーブルをさらに具備し、
   前記経路情報変換部は、該経路情報変換テーブルを用いて経路情報の変換を行う請求項１記載のノード装置。
3. 前記経路情報はリンクの入力側の情報またはリンクの出力側の情報を含み、
   前記第２の運用ルールは、経路情報としてリンクの入力側の情報を追加するかリンクの出力側の情報を追加するかにおいて前記第１の運用ルールと異なる請求項１または２記載のノード装置。
4. 前記経路情報はノードの識別子を含み、前記第１の運用ルールと第２の運用ルールとでは、追加される経路情報に含まれるノードの識別子のアドレス空間が異なる請求項１〜３のいずれか１項記載のノード装置。
5. 前記第１の運用ルールは、異なる領域間で共通に定められた運用ルールである請求項１〜４のいずれか１項記載のノード装置。
6. 前記第１の運用ルールは、自ノードが属する領域において適用される運用ルールである請求項１〜４のいずれか１項記載のノード装置。

Images