JP4684349B2 - 中継ノード - Google Patents

Description

本発明は、ＧＭＰＬＳ（Generalized Multi-Protocol Label Switching）／ＭＰＬＳ（Multi-Protocol Label Switching）網における経路トレース情報を取得する技術に関する。

最初に、ＧＭＰＬＳ／ＭＰＬＳ網、ＧＭＰＬＳ／ＭＰＬＳで用いられるパス確立シグナリングプロトコルについて簡単に説明する。そして、その後に従来の経路トレース方式について説明する。

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

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

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

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

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

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

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

（パス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ：Resource reSerVation Protocol - Traffic Extension））
図２２は、パス確立シグナリングプロトコルの動作を示す図である。

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

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

（従来の経路トレース情報取得方式 ＲＲＯ）
図２３は、ＲＲＯ（Record Route Object）を用いた経路トレース機能の動作を示す図である。

以下では、ＲＳＶＰ−ＴＥを例に取り、経路トレース機能を実現するための従来手法について説明する。ＲＳＶＰにおいて経路トレースを実現する手法としてＲＲＯを用いた手法がＩＥＴＦ標準で定義されている（非特許文献１、非特許文献４）。

以下にその動作を説明する（図２３）。経路トレースを要求する始点ノードは、パス確立のためのパス確立要求（Ｐａｔｈ）／応答（Ｒｅｓｖ）メッセージに経路トレースを要求するためのオブジェクトＲＲＯを挿入するとともに、RRO sub-objectとして自身のノード識別子を付与した上で、パス確立要求メッセージ（Ｐａｔｈメッセージ）をＨｏｐ−ｂｙ−Ｈｏｐで送信する。Ｐａｔｈメッセージを受信した中間ノードは、RRO objectが挿入されていることから、経路トレース機能が有効になっていると判断し、自身のノード識別子をRRO sub-objectとしてリストに追加した上でＰａｔｈメッセージを次のｈｏｐへ転送する。各中間ノードは本手順をそれぞれ実施し、最終的にＰａｔｈメッセージが経由したノードのリストを含んだＲＲＯが、Ｐａｔｈメッセージによって終点ノードまで運ばれる。Ｐａｔｈメッセージを受信した終点ノードは、応答（Ｒｅｓｖ）メッセージにRRO objectおよび自身の識別子を含むsub-objectを挿入し、Ｐａｔｈメッセージが送られてきた経路に沿って始点ノードへ返信する。RRO sub-objectを含むＲｅｓｖメッセージを受信した中間ノードは自身のノード識別子をRRO sub-objectとしてリストに追加した上で次のｈｏｐへＲｅｓｖメッセージを転送する。最終的にはＲｅｓｖメッセージが経由したノードのリストを含んだＲＲＯが、Ｒｅｓｖメッセージによって始点ノードまで運ばれる。以上の手順を実施することにより、それぞれのノードはＰａｔｈメッセージから自身の上流に位置するノード群のリストを、Ｒｅｓｖメッセージから自身の下流に位置するノード群のリストを取得し、両情報から確立されたパスが経由しているノードの情報を取得することができる。

図２４は、上記の標準仕様処理フローを示す図である。各中継ノードは、パス確立要求（または、応答）を受信すると、そのメッセージに経路記録要求（ＲＲＯ）が有るか否かを確認する。経路記録要求が有るときは、自ノードの識別子を経路情報リストに追加して、次のノードへパス確立要求（または、応答）を送信する。経路記憶要求がない時は、そのまま、次のノードへパス確立要求（または、応答）を送信する。
特開２０００−２４４５６３号公報 D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels." Network Working Group Request for Comments (RFC) 3209, December 2001. P. Ashwood-Smith, Ed., L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions." Network Working Group Request for Comments (RFC) 3471, January 2003. L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions." Network Working Group Request for Comments (RFC) 3473, January 2003. K. Kompella, Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)." Network Working Group Request for Comments (RFC) 3477, January 2003. J. Moy, "OSPF Version 2." Network Working Group Request for Comments (RFC) 2328, April 1998. D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2." Network Working Group Request for Comments (RFC) 3630 September 2003. K. Kompella, Ed., Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)." Network Working Group Request for Comments (RFC) 4302, October 2005. K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)." Network Working Group Request for Comments (RFC) 4303, October 2005.

図２５は、既存の経路トレースの課題を示す図である。

複数のネットワークドメインが接続されたネットワークにおいて、各ドメインがキャリア毎などであった場合には、ドメイン内情報の秘匿が必要となる。インターネットにおいてもＤＯＳ攻撃（Denial of Service attack）などを避けるために、キャリアネットワーク内の情報はなるべく外へ開示しないような仕組みが採られている。

一方、ＧＭＰＬＳ／ＭＰＬＳネットワークにおいて、経路トレース情報の取得にＲＲＯを用いた場合、各ノードは自ノードのＩＤをRRO sub-objectに載せて隣接のノードへ転送することがルールとして定められている。この仕組みは、あるネットワーク範囲内（ドメイン）の情報をその外へ開示したくない場合には以下のような問題があり、結果としてドメイン内の情報を容易に外部ドメインから抽出することが可能になってしまう(図２５)。

（１）情報を開示してはいけないネットワークとの境界を知ることができない。

（２）経路トレース情報に記載される経路情報のうち、情報を隠蔽する対象となる情報を特定することができない。

（３）経路トレース情報に記載される経路情報を削除することができない。

図２６は、ＲＲＯ機能無効時の動作を示す図である。ノードＡからＲＲＯを含むパスメッセージを送信すると、ＲＲＯ非実装ノードであるノードＤからＲＲＯ非対応である旨のエラーがノードＡに対して返される。ノードＡは、ＲＲＯを含まないパスメッセージを送信して、パスを確立する。

このように、情報を開示したくない場合には、ドメイン内のノードをＲＲＯに非対応なものにすればドメイン外への情報の流出は防ぐことができる(図２６)。しかし、経路トレース情報の取得という機能自体が無効となるため、ドメイン内の経路情報を取得したい場合には、既存の仕組みとは異なる手法を講じる必要がある。

そこで、本願発明は、経路トレース情報の取得機能を維持しつつ、特定のノードの情報を開示しない中継ノードを提供することを課題とする。

本発明は、上記課題を解決するために、以下の手段を採用する。

即ち、本発明は、
始点ノードから終点ノードまでのデータ転送に用いられるパスに係る経路情報を含む経路トレース用制御メッセージを前記パス上の前段のノードから受信する受信部と、
自ノードが前記パス上の経路情報遮蔽区間の境界に位置する境界ノードである場合に、前記受信部で受信された経路トレース用制御メッセージに含まれる経路情報の前記経路情報遮蔽区間に関する部分が識別できない状態に編集する編集部と、
前記編集後の経路トレース用制御メッセージを、前記パス上に位置する次段のノードへ送出する送信部と、
を備える中継ノード
である。

本発明によると、経路情報の経路情報遮蔽区間外のノードからは、経路情報の経路情報遮蔽区間内に関する情報を認識することができない。

好ましくは、上記本発明であって、
前記編集部は、削除された経路情報遮蔽区間に関する部分の代わりに前記経路情報遮蔽区間に関する擬似情報を前記経路情報に付加する中継ノード
とする。

本発明によると、経路トレース情報の取得機能を維持しつつ、経路情報遮蔽区間に関する情報を隠蔽することができる。

本発明によれば、擬似情報を付加することで、既存の経路情報取得機能と相互接続性が保証される。

好ましくは、上記発明であって、
前記経路情報は、前記パスが通過するノードの識別子と、ノードが前記経路情報遮蔽区間に属するか否かを示すフラグとを有するリストを含み、
前記編集部は、前記フラグに基づいて、前記リスト中の前記経路情報遮蔽区間に属するノードを特定し、特定されたノードの識別子を前記リストから削除する中継ノード
とする。

本発明によると、経路情報遮蔽区間外に送出される経路情報に、経路情報遮蔽区間に属するノードの情報が含まれない。

本発明によれば、経路情報遮蔽区間外への経路情報の流出を防ぐことができる。

好ましくは、上記発明であって、
自ノードが所属するドメインと、自装置に接続する他の中継ノードが所属するドメインとを記憶するリンク管理情報データベース、
をさらに備え、
前記編集部は、
前記リンク管理情報データベースを参照して、前記自装置が所属するドメインと、前記制御メッセージの送信先である第２の中継ノードが所属するドメインと、が一致するか否かを判断し、
前記自ノードが所属するドメインと、前記制御メッセージの送信先である次段の中継ノード装置が所属するドメインと、が一致しない場合に、自ノードが前記境界ノードであると判断する中継ノード
とする。

本発明によると、リンク管理情報データベースにより、自ノードが境界ノードであるか否かを適切に判断することができる。

好ましくは、上記発明であって、
前記編集部は、自ノードが前記境界ノードではなく且つ前記経路情報遮蔽区間に属する場合に、前記受信部で受信された経路トレース用制御メッセージに、自ノードの識別子と、自ノードが前記経路情報遮蔽区間に属することを示すフラグとを付加する中継ノード
とする。

本発明によると、フラグを付加することによって、境界ノードにおいて、経路情報に含まれる中継ノードが経路情報遮蔽区間に属するノードか否かを適切に判断することができる。

ここで、本発明における「編集部」には、ＲＲＯ処理部が含まれる。また、本発明における「記憶部」には、遮蔽対象ノードデータベースが含まれる。

本願発明によれば、経路トレース情報の取得機能を維持しつつ、特定のノードの情報を開示しない中継ノードを提供することが可能となる。

図１は、実施形態１のドメインに基づく遮蔽領域指定を示す図である。 図２は、実施形態１のノードの構成を示す図である。 図３は、ノード１０Ｆ（ドメイン２、遮蔽領域内）リンク管理情報データベースを示す図である。 図４は、実施形態１の処理フローを示す図である。 図５は、遮蔽対象フラグの付与を示す図である。 図６は、境界ノードによるsub-object削除処理を示す図である。 図７は、RRO IPv4 address sub-object(Type 0x01)を示す図である。 図８は、RRO Unnumbered Interface ID sub-object (Type 0x04)を示す図である。 図９は、Ｒｅｓｖメッセージによる処理を示す図である。 図１０は、任意の遮蔽範囲指定を示す図である。 図１１は、ノード２０Ｃ（ドメイン１、遮蔽領域内）リンク管理情報データベースを示す図である。 図１２は、経路情報の部分的遮蔽を示す図である。 図１３は、実施形態３のネットワーク構成の例を示す図である。 図１４は、実施形態３の処理フローを示す図である。 図１５は、擬似的ノードの追加処理を示す図である。 図１６は、実施形態４のノードの構成の例を示す図である。 図１７は、実施形態４の処理フローを示す図である。 図１８は、データマッチングによる遮蔽対象ノードの特定の例を示す図である。 図１９は、実施形態５の処理フローを示す図である。 図２０は、データマッチングによる遮蔽対象ノードの特定の例を示す図である。 図２１は、固定長ラベルを用いたパケット転送を示す図である。 図２２は、パス確立シグナリングプロトコル（ＲＳＶＰ−ＴＥ）の動作を示す図である。 図２３は、ＲＲＯを用いた経路トレース機能の動作を示す図である。 図２４は、標準仕様処理フローを示す図である。 図２５は、既存の経路トレースの課題を示す図である。 図２６は、ＲＲＯ機能無効時の動作を示す図である。

符号の説明

１０、１０Ａ−１０Ｉ ノード
２０、２０Ａ−２０Ｍ ノード
３０、３０Ｄ−２０Ｉ ノード
１００ ネットワーク
２００ ネットワーク
１０１２ データ受信部
１０１４ データ中継部
１０１６ データ送信部
１０２２ 制御パケット受信部
１０２４ パス制御部
１０２６ 制御パケット送信部
１０３０ ＲＲＯ処理部
１０５２ リンク管理情報データベース
１０５４ 遮蔽対象ノードデータベース
１０５６ ラベルテーブル

以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。また、各実施形態を適宜組み合わせて、構成することが可能である。

〔実施形態１〕
〈構成〉
図１は、本実施形態におけるネットワーク構成例を示す図である。図１は、経路情報の遮蔽対象領域をドメイン単位で設定した場合の例である。

ドメインとは関係なく任意の範囲を経路情報の遮蔽対象領域として、遮蔽対象領域に合わせてドメインを区切り直すこともできる。

図１のネットワーク１００には、９個のノード（ノード１０Ａ乃至ノード１０Ｉ）が存在する。ノード１０Ａ、ノード１０Ｂ及びノード１０Ｃはドメイン１に、ノード１０Ｄ、ノード１０Ｅ及びノード１０Ｆはドメイン２に、ノード１０Ｇ、ノード１０Ｈ及びノード１０Ｉはドメイン３に含まれる。ここで、ドメイン２を経路情報の遮蔽対象領域とする。この場合に、遮蔽対象領域の境界に位置するノードは、リンクのドメイン属性情報（リンク管理情報データベース）を使用して、自ノードが遮蔽境界ノードであることを認識する。ここで、ドメイン内のリンクをドメイン内リンク、ドメイン間を接続するリンクをドメイン間リンクと定義する。各ノードが、自ノードに直に接続されているリンク（リンク属性）をそれぞれ管理する。

図２は、本実施形態の経路情報の遮蔽対象のノードの構成の例を示す図である。本実施形態における経路情報の遮蔽対象領域内のノードは、データ受信部１０１２、データ中継部１０１４、データ送信部１０１６、制御パケット受信部１０２２、パス制御部１０２４、制御パケット送信部１０２６、ＲＲＯ処理部１０３０、リンク管理情報データベース１０５２、ラベルテーブル１０５６を備える。

データ受信部１０１２は、隣接ノードからデータを受信し、そのデータを宛先を決定するためにデータ中継部１０１４へ送信する。

データ中継部１０１４は、データ受信部１０１２からデータを受信する。データ中継部１０１４は、ラベルテーブル１０５６を参照し、データ受信部１０１２から受信したデータの宛先を決定する。データ中継部１０１４は、ラベルテーブル１０５６に記されたラベルをデータに付与し、データ送信部１０１６へ当該データを送信する。

データ送信部１０１６は、データ中継部１０１４からデータを受信する。データ送信部１０１６は、ラベルを付与された当該データを、隣接ノードへ送信する。

制御パケット受信部１０２２は、パスの確立、削除などを行うための制御パケットを隣接ノードから受信する。制御パケット受信部１０２２は、制御パケットを、パス制御部１０２４へ送信する。

パス制御部１０２４は、制御パケット受信部１０２２から制御パケットを受信する。パス制御部１０２４は、当該制御パケットの要求に応じたパス確立のためにラベル割り当てを行う。パス制御部１０２４は、割り当てたラベル情報をラベルテーブル１０５６に登録する。パス制御部１０２４は、必要に応じて制御パケットの中身を次の隣接ノードに送信するためのものに書き換える。パス制御部１０２４は、制御パケットを制御パケット送信部１０２６へ送信する。また、パス制御部１０２４は、制御パケットにＲＲＯ要求が含まれる場合には、ＲＲＯ処理部１０３０に制御パケットを送信する。ＲＲＯ処理部１０３０で、制御パケット処理を行うためである。

ＲＲＯ処理部１０３０は、パス制御部１０２４から、ＲＲＯ要求が含まれる制御パケットを受信する。ＲＲＯ処理部１０３０は、Record Route Object（ＲＲＯ）エントリ追加処理をする。つまり、ＲＲＯ処理部１０３０は、自ノードの識別子を含むRRO sub-objectをＲＲＯに追加する。また、ＲＲＯ処理部１０３０は、RRO sub-objectが遮蔽対象ノードであることを示す遮蔽対象フラグをＲＲＯに付与する。さらに、ＲＲＯ処理部１０３０は、遮蔽境界ノード判定処理、遮蔽対象経路情報の特定処理、遮蔽対象経路情報の削除処理、の各処理を行う。ＲＲＯ処理部１０３０は、その処理結果を制御パケットに含めて制御パケット送信部１０２６へ送信する。

制御パケット送信部１０２６は、パス制御部１０２４又はＲＲＯ処理部１０３０から制御パケットを受信し、隣接ノードへ制御パケットを送信する。

リンク管理情報データベース１０５２は、自ノードのインタフェース毎に、対応する宛先ドメインの情報を格納する。また、リンク管理情報データベース１０５２は、自ノードの属するドメイン（自ドメイン）の情報を格納する。特定のインタフェースの宛先ドメインと自ノードの属するドメインとを比較することで、その特定のインタフェースのリンクの接続先ノードがドメイン内かドメイン外かを判断することが出来る。

図３は、ノード１０Ｆのリンク管理情報データベースの例を示す図である。各ノードは、それぞれリンク管理情報データベース１０５２を有する。リンク管理情報データベース１０５２は、自ノードの属するドメイン（自ドメイン）の情報と、インタフェース毎の宛先ドメインの情報とを有する。ノード１０Ｆでは、ノード１０Ｆ自身はドメイン２に属し、インタフェース＃１にはドメイン２が、インタフェース＃２にはドメイン３が、接続されている。このことから、ノード１０Ｆのインタフェース＃１はドメイン内リンク、ノード１０Ｆのインタフェース＃２はドメイン間リンクであると判断することができる。

〈動作例〉
図４は、本実施形態における遮蔽対象領域内のノードの処理フローの例を示す図である。ここでは、主にノード１０Ｆを例にとり、説明する。ノード１０Ｄ及びノード１０Ｅにおいても、同じ処理フローによって処理される。

ここで、パス確立シグナリングプロトコル(ＲＳＶＰ−ＴＥ)を用いて、ノード１０Ａから、ノード１０Ｂ、ノード１０Ｃ、ノード１０Ｄ、ノード１０Ｅ、ノード１０Ｆ、ノード１０Ｇ及びノード１０Ｈを順に経由して、ノードＩまでの経路のパスを確立する。始点のノード１０Ａは、パス確立要求にＲＲＯをＰａｔｈメッセージに含めることにより、経路トレースを要求する。

ノード１０Ｆは、隣接ノードからパス確立要求を受信する（図４：Ｓ１００２）。ノード１０Ｆは、パス確立要求がＲＲＯを含むＰａｔｈメッセージであるか否か確認する（Ｓ１００４）。パス確立要求がＲＲＯを含まないＰａｔｈメッセージである場合（Ｓ１００４；ＮＯ）は、所定の処理の後、次のノードへそのパス確立要求を送信する（Ｓ１０１８）。パス確立要求がＲＲＯを含むＰａｔｈメッセージである場合（Ｓ１００４；ＹＥＳ）、通常のパス確立プロセスを実行するとともに、経路情報リストに自ノードの識別子を含むRRO sub-objectを追加する（Ｓ１００６、ＲＲＯ処理）。ノード１０Ｆは、当該RRO sub-objectが遮蔽対象であることを示すフラグを付与する（Ｓ１００８）。

図５は、遮蔽対象フラグの付与の例を示す図である。ノード１０Ｄ、ノード１０Ｅ、ノード１０Ｆでは、自ノードの識別子（Ｄ、Ｅ、または、Ｆ）を含むRRO sub-objectとともに、当該RRO sub-objectが遮蔽対象であることを示す遮蔽対象フラグ（１）が付与される。

次に、ノード１０Ｆは、Ｐａｔｈメッセージを送出すべきインタフェースを特定する。このインタフェースを特定するための情報は、パスの終点に関する情報を用いて自ら経路計算を実施して求めることができる。また、Ｐａｔｈメッセージ内に経路を指定するExplicit Route Objectが含まれる場合には、その記載に従って求める。

ノード１０Ｆは、自ノードが遮蔽境界に位置するノードか否かを判断する（図４：Ｓ１０１０、遮蔽境界ノード判定処理）。ノード１０Ｆは、リンク管理情報データベース１０５２の自ドメインの情報と、Ｐａｔｈメッセージを送出するインタフェースの宛先ドメインの情報とを比較して、自ノードが遮蔽境界に位置するか否かを判断する。

ここで、例えば、ノード１０Ｄ（またはノード１０Ｅ）の場合は、自ドメインの情報と宛先ドメインの情報とが一致する（図４：Ｓ１０１０；ＮＯ）。このとき、ノード１０Ｄ（またはノード１０Ｅ）は、自ノードが遮蔽境界に位置しないと判断して、所定の処理の後、次のノードへパス確立要求を送信する（Ｓ１０１８）。

ノード１０Ｆの場合は、自ドメインの情報と宛先ドメインの情報とが一致しない（図４：Ｓ１０１０；ＹＥＳ）。このとき、ノード１０Ｆは、自ノードが遮蔽境界に位置すると判断して次の処理を行う。ノード１０Ｆは、RRO sub-objectが遮蔽対象であることを示すフラグを参照して、遮蔽対象経路情報（遮蔽対象であるノードの情報）を特定する（Ｓ１０１２、遮蔽対象経路情報の特定処理）。遮蔽対象であることを示すフラグが付与されているRRO sub-objectが、遮蔽対象経路情報であると判断される。ノード１０Ｆは、遮蔽経路情報であると判断されたRRO sub-objectをリストから削除する（Ｓ１０１４、遮蔽対象経路情報の削除処理）。ノード１０Ｆは、所定の処理の後、次のノードへパス確立要求を送信する（Ｓ１０１８）。

ノード１０Ｆは、遮蔽対象フラグの付与の前に、自ノードが遮蔽境界ノードか否かを判断し、遮蔽境界ノードであると判断した場合は、自ノードの識別子を含むRRO sub-objectの追加及び遮蔽対象フラグの付与を行わない構成にしてもよい。

図６は、境界ノードによるRRO sub-objectの削除処理の例を示す図である。ノード１０Ｆは、自ノードが遮蔽境界ノードであると判断すると、遮蔽対象であることを示すフラグが付与されているRRO sub-object（Ｄ、Ｅ、Ｆ）及び当該フラグを削除する。

図７及び図８は、標準で定義されたsub-objectの例を示す図である。図７は、Type 0x01 IPv4 address sub-objectを示し、図８は、Type 0x04 Unnumbered Interface ID sub-objectを示す。

図７のType 0x01 IPv4 address sub-objectを用いた場合、IPv4 addressにノードの識別子を付与する。図８のType 0x04 Unnumbered Interface ID sub-objectを用いた場合、Router IDにノードの識別子を付与し、Interface IDにＲＲＯを含むＰａｔｈメッセージを受信したインタフェース番号、または、ＲＲＯを含むＰａｔｈメッセージを送出するインタフェース番号を付与する。遮蔽対象フラグは、Flagsに新たに値を定義することにより実現することが出来る。既に定義されているFlagsは次の通りである。

0x01 Local protection available
0x02 Local protection in use
図８のType 0x04 Unnumbered Interface ID sub-objectを用いる場合には、Reservedの領域に新たなフラグを定義して遮蔽対象フラグとしても良い。

図９は、パス確立応答のＲｅｓｖメッセージを用いた場合の例を示す図である。ノード１０Ｄ、ノード１０Ｅ及びノード１０Ｆを含むドメイン２が、遮蔽対象領域であるとする。

パス確立応答がＲＲＯを含むＲｅｓｖメッセージをノード１０Ｇから受信したノード１０Ｆは、通常のパス確立プロセスを実行するとともに、ＲＲＯの処理を行う。ノード１０Ｆは、ＲＲＯに自ノードの識別子を含むRRO sub-objectを追加するとともに、RRO sub-objectが遮蔽対象であることを示す遮蔽対象フラグを付与する。次に、ノード１０Ｆは、Ｒｅｓｖメッセージを送出するべきインタフェースを特定する。この情報は、Ｐａｔｈメッセージを受信、送信した際にノード内に生成するPath Stateを参照することによって求める。送出すべきインタフェース（ここでは＃１）が求められた後に、自ノードで管理するリンク属性情報（リンク管理情報データベース１０５２）と照合し、そのインタフェースがドメイン内リンクであるのかドメイン間リンクであるのかを判断する。ノード１０Ｆの場合、次にＲｅｓｖメッセージを送出すべきインタフェース＃１はドメイン内リンクであるので、自ノードを遮蔽境界ノードではないと判断する。遮蔽境界ノード以外のノードであるノード１０Ｆでは、Ｒｅｓｖメッセージの送出処理を行う。同様の処理は、ノード１０Ｅにおいても実施される。

一方、パス確立応答がＲＲＯを含むＲｅｓｖメッセージをノード１０Ｅから受信したノード１０Ｄは、通常のパス確立プロセスを実行するとともに、ＲＲＯの処理を行う。ノード１０Ｄは、ＲＲＯに自ノードの識別子を含むRRO sub-objectを追加するとともに、RRO sub-objectが遮蔽対象であることを示す遮蔽対象フラグを付与する。ノード１０Ｄは、自ノードが遮蔽境界ノードであるか否かの判断を行う。ノード１０Ｄが、次にＲｅｓｖメッセージを送出するべきインタフェース＃１はドメイン間リンクであるので、自ノードを遮蔽境界ノードであると判断する。遮蔽境界ノードであるノード１０Ｄは、RRO sub-objectのリストを参照し、遮蔽対象フラグの付与されているRRO sub-objectをリストから削除する。その後にＲＲＯをＲｅｓｖメッセージに格納し、インタフェース＃１へ送出する。

〈実施形態１の作用効果〉
以上説明した本実施形態によると、遮蔽対象領域外の各ノードには遮蔽対象領域の経路情報を開示することなく、遮蔽対象領域内では通常の経路情報を取得することが可能となる。例えば、遮蔽対象領域外のノード１０ＧではＰａｔｈメッセージから上流の経路情報{Ａ，Ｂ，Ｃ}を、Ｒｅｓｖメッセージからは下流の経路情報{Ｈ，Ｉ}を取得する。これらの情報と自ノードの情報との組み合せからパスの経路情報{Ａ，Ｂ，Ｃ，Ｇ，Ｈ，Ｉ}が得られる。これは遮蔽対象領域内の経路情報｛Ｄ，Ｅ，Ｆ｝が隠蔽された形式である。一方、遮蔽対象領域内のノード１０Ｅにおいては、Ｐａｔｈメッセージからは上流の経路情報{Ａ，Ｂ，Ｃ，Ｄ}を、Ｒｅｓｖメッセージからは下流の経路情報{Ｆ，Ｇ，Ｈ，Ｉ}を取得する。これらの情報と自ノードの情報との組み合わせからパスの経路情報{Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈ，Ｉ}が得られる。これは、パス上のすべてのノードが含まれた経路情報となる。

（変形例）
図１０は、本実施形態の変形例におけるネットワークの構成例を示す図である。図１０は、経路情報の遮蔽対象領域をドメインとは関係なく任意に設定した場合の例である。

図１０のネットワーク２００には、１３個のノード（ノード２０Ａ乃至ノード２０Ｍ）が存在する。ノード２０Ａ、ノード２０Ｂ、ノード２０Ｃ及びノード２０Ｎはドメイン１に、ノード２０Ｄ、ノード２０Ｅ、ノード２０Ｆ及びノード２０Ｊはドメイン２に、ノード２０Ｇ、ノード２０Ｈ及びノード２０Ｉはドメイン３に、ノード２０Ｋ、ノード２０Ｌ及びノード２０Ｍはドメイン４に含まれる。

ここで、図１０において点線で囲まれた領域を経路情報の遮蔽対象領域とする。つまり、ノード２０Ａ、ノード２０Ｂ、ノード２０Ｃ、ノード２０Ｄ、ノード２０Ｅ、ノード２０Ｆ、ノード２０Ｊ、ノード２０Ｋ及びノード２０Ｍが、遮蔽対象領域内のノードであるとする。経路情報の遮蔽対象領域が、ドメイン１及びドメイン４の一部と、ドメイン２と、を含んでいる。遮蔽対象領域内の各ノードは、遮蔽対象領域特定のためのリンク属性情報（リンク管理情報データベース）を保持する。

このとき、ノード２０Ｃとノード２０Ｎとを接続するリンクは、ドメイン１のドメイン内リンクであり、経路情報の遮蔽対象領域外へ接続されるリンクである。

本実施形態の変形例の各ノードは、図２に示されるノードの構成と同様の構成を有する。

図１１は、ノード２０Ｃが保持するリンク情報管理データベースの例を示す図である。各ノードは、それぞれリンク管理情報データベース１０５２を有する。リンク管理情報データベース１０５２は、自ノードの属するドメイン（自ドメイン）の情報と、インタフェース毎の宛先ドメインの情報と、宛先ノードが遮蔽対象領域内か領域外かを示す情報を有する。この場合、経路情報遮蔽ポリシーとして、遮蔽対象領域外への情報開示の禁止を設定する。リンク管理情報データベース１０５２において、自ノードの属するドメイン（自ドメイン）の情報は必ずしも必要ではない。

経路情報の遮蔽対象領域内の各ノードは、リンク管理情報データベースに基づき、自ノードが遮蔽境界ノードに位置するか否かを認識し、適切な処理を実施することができる。

本変形例の遮蔽対象領域内の各ノードは、図４に示す処理フローと同様の処理を行う。ただし、自ノードが遮蔽境界に位置するノードか否かの判断は、リンク管理情報データベース１０５２の宛先ノードが遮蔽対象領域内か領域外かによって行う。宛先ノードが遮蔽対象領域外であれば、遮蔽境界に位置するノードであると判断される。

〔実施形態２〕
次に、本発明の実施形態２を説明する。実施形態２は、実施形態１と共通点を有する。従って、主として、相違点について説明し、共通点については説明を省略する。

本実施形態では、経路情報の遮蔽対象領域内の一部のノードのみの経路情報を遮蔽する方法を説明する。

〈構成〉
本実施形態のネットワーク構成は、実施形態１における図１のネットワーク構成例と同様である。本実施形態の経路情報の遮蔽対象領域内の各ノードの構成は、実施形態１における図２のノードの構成と同様である。

また、変形例として、実施形態１の変形例における図１０と同様のネットワーク構成とすることもできる。

〈動作例〉
経路情報の遮蔽対象領域内の各ノードの処理フローは、実施形態１の図４の処理フローと同様である。実施形態１では、遮蔽対象領域内の各ノードでは、一律に、RRO sub-objectが遮蔽対象であることを示す遮蔽対象フラグを付与していた。本実施形態では、ノード毎に遮蔽ポリシーを設定できるようにする。あるノードに、遮蔽非対称ポリシーが設定された場合には、RRO sub-objectを追加する際に、遮蔽対象フラグを付与しない。この構成により、遮蔽非対称ポリシーが設定されたノードは、遮蔽境界ノードで、RRO sub-objectを削除されない。

図１２は、本実施形態における遮蔽境界ノードによるRRO sub-object削除処理の例を示す図である。図１２では、ドメイン２が経路情報の遮蔽対象領域として指定されている。また、ノード１０Ｄ及びノード１０Ｆは、遮蔽非対称ノードであり、ノード１０Ｅは、遮蔽対象ノードである。ノード１０Ｆは、自ノードが遮蔽境界ノードであると判断すると、遮蔽対象であることを示すフラグが付与されているRRO sub-object（Ｅ）及び当該フラグを削除する。

〈実施形態２の作用効果〉
以上説明した実施形態によると、経路情報の遮蔽対象領域内では、各ノードは、実施形態１の場合と同様に、通常の経路情報を取得することが可能となる。また、遮蔽対象ノードと遮蔽非対象ノードとを設定することにより、経路情報の遮蔽対象領域外では、各ノードは、遮蔽対象領域内の遮蔽対象ノードを除く経路情報を取得することができる。

〔実施形態３〕
次に、本発明の実施形態３を説明する。実施形態３は、実施形態１と共通点を有する。従って、主として、相違点について説明し、共通点については説明を省略する。

実施形態１において、経路情報の遮蔽対象範囲内のノードが始点ノードとなった場合、その遮蔽対象範囲内の遮蔽境界ノードでは、すべての経路情報が削除されるため、空のＲＲＯを送出することになる。空のＲＲＯを送ることは標準違反となるため、問題である。本実施形態では、この問題を解決する。

〈構成〉
図１３は、本実施形態におけるネットワーク構成例を示す図である。図１５は、経路情報の遮蔽対象領域をドメイン単位で設定した場合の例である。

図１３のネットワーク３００には、６個のノード（ノード３０Ｄ乃至ノード３０Ｉ）が存在する。ノード３０Ｄ、ノード３０Ｅ及びノード３０Ｆはドメイン２に、ノード３０Ｇ、ノード３０Ｈ及びノード３０Ｉはドメイン３に含まれる。ノード３０Ｄは、始点ノードである。ここで、ドメイン２を経路情報の遮蔽対象領域とする。この場合に、遮蔽対象領域の境界に位置するノードは、リンクのドメイン属性情報（リンク管理情報データベース）を使用して、自ノードが遮蔽境界ノードであることを認識する。ここで、ドメイン内のリンクをドメイン内リンク、ドメイン間を接続するリンクをドメイン間リンクと定義する。各ノードが、自ノードに直に接続されているリンク（リンク属性）をそれぞれ管理する。

本実施形態の経路情報の遮蔽対象のノードの構成は、実施形態１の図２のノードの構成と同様である。

〈動作例〉
図１４は、本実施形態における遮蔽対象領域内のノードの処理フローの例を示す図である。ここでは、主にノード１０Ｆを例にとり、説明する。ノード１０Ｄ及びノード１０Ｅにおいても、同じ処理フローによって処理される。

図１４において、パス確立要求を受信（Ｓ３００２）してから、遮蔽対象経路情報を削除（Ｓ３０１４）するまでは、実施形態１の処理フロー（図４）と同様である。しかしながら、始点ノードが経路情報の遮蔽対象領域内に存在する場合、遮蔽対象経路情報を削除した際、経路情報がなくなってしまう。そこで、遮蔽境界のノードであるノード３０Ｆは、遮蔽対象としているドメインを代表する擬似的なノード（domain2）をRRO sub-objectとして追加する（Ｓ３０１６）。

図１５は、境界ノードによるRRO sub-objectの削除処理の例を示す図である。ノード３０Ｆは、自ノードが遮蔽境界ノードであると判断すると、遮蔽対象であることを示すフラグが付与されているRRO sub-object（Ｄ、Ｅ、Ｆ）及び当該フラグを削除する。さらに、ノード３０Ｆは、遮蔽対象のドメインを代表する擬似的なノード（domain2）をRRO sub-objectに追加する。これにより、空のＲＲＯが創出されることを回避することができる。

ノード３０Ｆは、所定の処理の後、次のノードへパス確立要求を送信する（Ｓ３０１８）。

〈実施形態３の作用効果〉
本実施形態によれば、図１５に示すように、始点ノードが遮蔽対象ドメイン内に存在し、ドメイン内の全ノードに削除対象設定が施されているような場合においては、本機能を実装しない場合、空のＲＲＯを送出することになる。空のＲＲＯを送ることは標準違反となるが、本機能を用いることで、この違反を回避することができる。

また、本実施形態の擬似的ノードをRRO sub-objectに追加する構成は、経路情報の遮蔽対象領域内に始点ノードが存在しない場合も適用することが可能である。

〔実施形態４〕
次に、本発明の実施形態４を説明する。実施形態４は、実施形態１と共通点を有する。従って、主として、相違点について説明し、共通点については説明を省略する。

本実施形態では、RRO sub-objectに変更を加えることなく、経路情報の柔軟な遮蔽を実現する方法を説明する。

〈構成〉
本実施形態のネットワーク構成は、実施形態１における図１のネットワーク構成例と同様である。

また、変形例として、実施形態１の変形例における図１０と同様のネットワーク構成とすることもできる。

図１６は、本実施形態の経路情報の遮蔽対象領域内のノードの構成を示す図である。本実施形態の経路情報の遮蔽対象領域内のノードは、実施形態１における図２のノードの構成とほぼ同様である。本実施形態の当該ノードは、さらに、遮蔽対象ノードデータベース１０５４を有する。遮蔽対象ノードデータベース１０５４は、少なくとも遮蔽境界に位置するすべてのノードが、有していればよい。即ち、遮蔽境界のノードにならないことが確実なノードは、遮蔽対象ノードデータベース１０５４を有さなくてもよい。

遮蔽対象ノードデータベース１０５４は、遮蔽対象となるノードの一覧を記述したデータベースである。

ＲＲＯ処理部１０３０は、実施形態１と異なり、遮蔽対象であることを示す遮蔽対象フラグの付与を行わない。

また、ＲＲＯ処理部１０３０は、自ノードが遮蔽境界ノードであると判断すると、RRO sub-objectリストと、遮蔽対象ノードデータベースとを比較する。ＲＲＯ処理部１０３０は、比較した結果、遮蔽対象ノードデータベースに記載されたノードと一致するノードをRRO sub-objectリストから削除する。

〈動作例〉
図１７は、本実施形態における遮蔽対象領域内のノードの処理フローの例を示す図である。ここでは、主にノード１０Ｆを例にとり、説明する。ノード１０Ｄ及びノード１０Ｅにおいても、同じ処理フローによって処理される。

図１７において、パス確立要求を受信（Ｓ４００２）してから、次のノードへパス確立要求（Ｓ４０１８）するまで、実施形態１の処理フロー（図４）と同様である。しかしながら、本実施形態では、遮蔽対象ノードであることを示すフラグを設定する必要はない。また、本実施形態では、遮蔽対象経路情報を特定（Ｓ４０１２）する際、遮蔽対象ノードであることを示すフラグを使用する代わりに、遮蔽対象ノードデータベース１０５４を使用する。

図１８は、境界ノードによるｓｕｂ−ｏｂｊｅｃｔの削除処理の例を示す図である。遮蔽対象範囲内のノード１０Ｆは、自ノードが遮蔽境界ノードであると判断すると、遮蔽対象ノードデータベース１０５４を参照して、RRO sub-object（Ｄ、Ｅ、Ｆ）を削除する。

〈実施形態４の作用効果〉
本実施形態によれば、RRO sub-objectに変更を加えることなく、遮蔽対象ノードデータベース１０５４を随時更新することで、経路情報の遮蔽の範囲を柔軟に変更しながら、経路情報の遮蔽を実現することができる。

〈変形例〉
遮蔽対象ノードデータベース１０５４を準備する代わりに、ドメイン内トポロジデータベースの利用することができる。

ＧＭＰＬＳ／ＭＰＬＳでは、ネットワーク内のノードの接続情報を収集するためのルーティングプロトコル(非特許文献５、非特許文献６、非特許文献７、非特許文献８など)が標準として定義されている。各ノードは、本プロトコルを用いることによってネットワーク内に位置するノードに関する情報を取得することが出来る。トポロジデータベースにはエリアに関する情報も付与できるため、ドメイン毎に異なるエリア値を設定すれば、一つのドメインのみを遮蔽対象とする処理が実現できる。

〔実施形態５〕
次に、本発明の実施形態５を説明する。実施形態５は、実施形態４と共通点を有する。従って、主として、相違点について説明し、共通点については説明を省略する。

本実施形態では、実施形態４の構成に、実施形態３の擬似的ノードを付加する構成を追加する方法を説明する。

〈構成〉
本実施形態のネットワーク、各ノードは、実施形態４と同様の構成を有する。

〈動作例〉
図１９は、本実施形態における遮蔽対象領域内のノードの処理フローの例を示す図である。ここでは、主にノード１０Ｆを例にとり、説明する。ノード１０Ｄ及びノード１０Ｅにおいても、同じ処理フローによって処理される。

図１９において、パス確立要求を受信（Ｓ５００２）してから、遮蔽対象経路情報を削除（Ｓ５０１４）するまで、実施形態４の処理フロー（図１７）と同様である。本実施形態では、遮蔽対象経路情報を削除した後、実施形態３と同様に、遮蔽対象のドメインを代表する擬似的ノード（domain2）をRRO sub-objectリストに追加する。

図２０は、境界ノードによるｓｕｂ−ｏｂｊｅｃｔの削除処理の例を示す図である。遮蔽対象範囲内のノード１０Ｆは、自ノードが遮蔽境界ノードであると判断すると、遮蔽対象ノードデータベース１０５４を参照して、RRO sub-object（Ｄ、Ｅ、Ｆ）を削除する。さらに、ノード１０Ｆは、RRO sub-objectに擬似的ノード（domain2）を付加する。

Claims (6)

1. 始点ノードから終点ノードまでのデータ転送に用いられるパスに係る経路情報を含む経路トレース用制御メッセージを前記パス上の前段のノードから受信する受信部と、
   自ノードが前記パス上の経路情報遮蔽区間の境界に位置する境界ノードである場合に、前記受信部で受信された経路トレース用制御メッセージに含まれる経路情報の前記経路情報遮蔽区間に関する部分が識別できない状態に編集する編集部と、
   前記編集後の経路トレース用制御メッセージを、前記パス上に位置する次段のノードへ送出する送信部とを備え、
   前記経路情報は、前記パスが通過するノードの識別子と、ノードが前記経路情報遮蔽区間に属するか否かを示すフラグとを有するリストを含み、
   前記編集部は、前記経路情報から経路情報遮蔽区間に関する部分を削除し、前記フラグに基づいて、前記リスト中の前記経路情報遮蔽区間に属するノードを特定し、特定されたノードの識別子を前記リストから削除する
   中継ノード。
2. 始点ノードから終点ノードまでのデータ転送に用いられるパスに係る経路情報を含む経路トレース用制御メッセージを前記パス上の前段のノードから受信する受信部と、
   自ノードが前記パス上の経路情報遮蔽区間の境界に位置する境界ノードである場合に、前記受信部で受信された経路トレース用制御メッセージに含まれる経路情報の前記経路情報遮蔽区間に関する部分が識別できない状態に編集する編集部と、
   前記編集後の経路トレース用制御メッセージを、前記パス上に位置する次段のノードへ送出する送信部とを備え、
   前記経路情報は、前記パスが通過するノードの識別子と、ノードが前記経路情報遮蔽区間に属するか否かを示すフラグとを有するリストを含み、
   前記編集部は、前記経路情報から経路情報遮蔽区間に関する部分を削除し、削除された経路情報遮蔽区間に関する部分の代わりに前記経路情報遮蔽区間に関する擬似情報を前記経路情報に付加し、前記フラグに基づいて、前記リスト中の前記経路情報遮蔽区間に属するノードを特定し、特定されたノードの識別子を前記リストから削除する
   中継ノード。
3. 前記経路情報遮蔽区間に属するノードの特定情報を記憶した記憶部をさらに含み、
   前記編集部は、前記記憶部の特定情報に基づいて、前記経路情報から前記経路情報遮蔽区間に関する部分を削除する
   請求項１または２に記載の中継ノード。
4. 自ノードが所属するドメインと、自装置に接続する他の中継ノードが所属するドメインとを記憶するリンク管理情報データベース、
   をさらに備え、
   前記編集部は、
   前記リンク管理情報データベースを参照して、前記自装置が所属するドメインと、前記制御メッセージの送信先である第２の中継ノードが所属するドメインと、が一致するか否かを判断し、
   前記自ノードが所属するドメインと、前記制御メッセージの送信先である次段の中継ノード装置が所属するドメインと、が一致しない場合に、自ノードが前記境界ノードであると判断する、
   請求項１または２に記載の中継ノード。
5. 自ノードの所属するドメインと、自ノードに接続する他の中継ノードが経路情報の遮蔽対象領域内か遮蔽対象領域外かを示す情報と、を記憶するリンク管理情報データベースと、をさらに備え、
   前記編集部は、
   前記リンク管理情報データベースを参照して、前記制御メッセージの送信先である次段の中継ノード装置が経路情報の遮蔽対象領域外であるか否かを判断し、
   前記制御メッセージの送信先である次段の中継ノード装置が経路情報の遮蔽対象領域外である場合に、自ノードが前記境界ノードであると判断する、
   請求項１または２に記載の中継ノード。
6. 前記編集部は、自ノードが前記境界ノードではなく且つ前記経路情報遮蔽区間に属する場合に、前記受信部で受信された経路トレース用制御メッセージに、自ノードの識別子と、自ノードが前記経路情報遮蔽区間に属することを示すフラグとを付加する、
   請求項１または２に記載の中継ノード。

Images