JP2011170422A

JP2011170422A - Ｐ２ｐ型通信用ポリシー管理システム

Info

Publication number: JP2011170422A
Application number: JP2010031187A
Authority: JP
Inventors: Tomohiko Ogishi; 智彦大岸; Emi Shibuya; 惠美渋谷; Yuichiro Hei; 雄一郎屏
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2010-02-16
Filing date: 2010-02-16
Publication date: 2011-09-01

Abstract

【課題】運用者が設定する細やかなポリシーに従ってピアリストの候補ピアを選択できるP2P型通信用ポリシー管理システムを提供する。
【解決手段】要求ピアの条件と前記候補ピアの条件との組み合わせに対して所定の優先度を定めたポリシーテーブルを入力され保存するポリシー管理部２と、ポリシーテーブルを読み込んで優先度マップを作成・保存する優先度マップ算出部３と、要求ピアからのピアリスト要求を受信し、優先度マップを参照して要求ピアとの優先度に基づいてピアリスト要求中の候補ピアを選出して前記ピアリスト情報を作成し、要求ピアに返信するサーバ部４とを備えてポリシー管理システム１を構成する。
【選択図】図２

Description

本発明は、P2P型の通信を対象とし、ピアが通信相手のピアを選択する際にネットワーク運用者が定義したポリシーにより、選択するピアの優先度を決定するP2P型通信用ポリシー管理システムに関するものである。

近年，P2P(Peer to Peer、ピアツーピア)技術を用いたコンテンツ配信により、AS(Autonomous System、自律システム)間やISP (Internet Services Provider)内部などにおけるトラフィックが増加し、バックボーンを非常に圧迫している。この技術課題に対して、複数のASがネットワーク情報公開してP2P配信サービス側でこの情報を利用し，ASと配信サービスが互いに協力することで双方にとって効率良い配信を行うP4P（Provider Portal for P2P）と呼ばれる取組が行われている。P4Pは非特許文献１に開示されている。

P4Pでは、AS内部に設置されるiTracker（ネットワーク情報サーバ）が、appTracker（配信制御サーバ）に対して、自身のネットワークにとって配信効率が良いピアの情報を提供する。ピア(要求ピア)がコンテンツを要求すると、appTrackerは自身が持つピア(候補ピア)の情報を、要求コンテンツのピース片を保有しておりP2P通信対象として接続可能なピア情報としてiTrackerへ通知する。iTrackerは自身が持つネットワーク情報を元に、要求ピアと候補ピアのネットワーク的な距離を計算し、その距離が短いものを優先的に選択し、ピアリストとしてappTrackerに返答する。ここで、ネットワーク情報としては、予め運用者が定めたアドレス空間の集合を示すPIDや、AS番号が用いられる。要求ピアと候補ピアが、同じPID内になる割合を70%、同じAS内になる割合を80%という形で、ある程度局所的に同一ネットワーク上で通信が発生するように制御し、効率的な配信を実現している。

P4P: Provider Portal for Applications http://www.cs.washington.edu/homes/arvind/papers/p4p.pdf

上記の従来技術においては、ピアリストに加える候補ピアを選定する条件として、同じPIDを持つピアを優先するなど、単純なポリシーしか適用できなかった。このため、特定の回線をできる限り使用する、特定の回線をできる限り使用しないといった細やかな設定ができない問題があった。

本発明の目的は上記した従来技術の課題を解決し、運用者が設定する細やかなポリシーに従ってピアリストの候補ピアを選択できるP2P型通信用ポリシー管理システムを提供することにある。

上記課題を解決するため、本発明は、P2P通信を利用して所定データを求める要求ピアから、該要求ピアの情報および該所定データを保有し通信対象となる複数の候補ピアの情報を記載したピアリスト要求を受信し、前記ピアリスト要求中の候補ピアを選別してピアリスト情報として前記要求ピアに返信するP2P型通信用ポリシー管理システムにおいて、以下のような手段を講じた点に特徴がある。

前記要求ピアの条件と前記候補ピアの条件との組み合わせに対して所定の優先度を定めたポリシーテーブルを入力され保存するポリシー管理部と、前記ポリシーテーブルを読み込んで優先度マップを作成・保存する優先度マップ算出部と、前記ピアリスト要求を受信し、前記優先度マップを参照して前記要求ピアとの優先度に基づいて前記ピアリスト要求中の候補ピアを選出して前記ピアリスト情報を作成し、前記要求ピアに返信するサーバ部とを含む点に第１の特徴がある。

また、前記要求ピアの条件および前記候補ピアの条件が、各ピアの所属するネットワークセグメントのＩＤによって識別される条件である点に第２の特徴がある。

また、前記P2P型通信用ポリシー管理システムが既存の第一の優先度マップを用いて稼働中に、前記ポリシー管理部に対して前記ポリシーテーブルが更新入力された場合、前記優先度マップ算出部は前記第一の優先度マップを保持しつつ該更新入力されたポリシーテーブルを読み込んで第二の優先度マップを作成し、該第二の優先度マップ作成中に前記サーバ部が前記ピアリスト要求を受信した場合、前記サーバ部は前記第一の優先度マップを参照して前記ピアリスト情報を作成し、前記第二の優先度マップ作成後に前記サーバ部が前記ピアリスト要求を受信した場合、前記サーバ部は前記第二の優先度マップを参照して前記ピアリスト情報を作成する点に第３の特徴がある。

また、前記ポリシーテーブルは前記要求ピア条件と、前記候補ピア条件と、該要求ピア条件と該候補ピア条件の組み合わせに対する優先度と、を列挙して対応づけた形式の行を構成単位として複数行からなり、前記優先度マップ算出部は前記ポリシーテーブルを読み込んで前記優先度マップを行列の形式で作成し、該行列は前記要求ピア条件に対応する行と前記候補ピア条件に対応する列とを有し、該行および該列に対応する前記優先度を行列要素として有する点に第４の特徴がある。

また、前記優先度マップ算出部は、前記ポリシーテーブルに入力の優先度に追加して、前記ポリシーテーブルに未入力の前記要求ピアの条件と前記候補ピアの条件との組み合わせに対して第一の優先度を定めて前記優先度マップを作成・保存し、前記ポリシーテーブルに入力される前記優先度は、前記第一の優先度よりも高い第二の優先度または前記第一の優先度よりも低い第三の優先度を含み、前記サーバ部は前記候補ピアを該候補ピアの優先度が高い順に選出して前記ピアリスト情報を作成する点に第５の特徴がある。

また、前記ポリシーテーブルに入力される前記優先度は、前記第一、第二および第三の優先度を含む他の全ての優先度よりも低い第四の優先度を含み、前記サーバ部は、前記ピアリスト情報を作成するにあたり、前記第四の優先度に該当する候補ピアは選出しない点に第６の特徴がある。

また、前記ポリシーテーブルにおける前記要求ピアの条件および前記候補ピアの条件を、前記P2P通信が行われるネットワークで稼働するルータが発する経路情報を用いて更新する経路解析部をさらに含む点に第７の特徴がある。

前記第１の特徴によれば、運用者の記述したポリシーに従い、特定のピア条件間のP2P通信を多くしたり少なくしたりする等のトラフィック制御を行うことができる。

前記第２の特徴によれば、特定のネットワークセグメント間のピア同士のP2P通信を多くしたり少なくしたりする等のトラフィック制御を行うことができる。

前記第３の特徴によれば、運用者がポリシーを変更する場合においても、更新したポリシーテーブルを反映させて新規の優先度マップを作成する際に、サーバ部は旧優先度マップを参照することでピアリスト情報提供サービスが継続されるので、無停止でP2P型通信用ポリシー管理システムを運用することができる。

前記第４の特徴によれば、要求ピア条件と候補ピア条件に対する優先度を多数の行に渡って全て記載したポリシーテーブルを行列形式で整理した優先度マップをサーバ部が参照するので、サーバ部はピアリスト情報を作成するに際してポリシーテーブルのポリシー行から一致行を探して逐次参照するよりも高速に優先度づけを行うことができる。

前記第５の特徴によれば、要求ピア条件と候補ピア条件の全てに対して優先度を入力する必要なくデフォルトの第一の優先度が設定でき、デフォルトより高い第二の優先度、またはデフォルトより低い第三の優先度のみのポリシーテーブル入力でそれぞれ通常の優先度よりも高い、または低い優先順位づけが可能となる。

具体的には、前記第５の特徴によってデフォルトよりも大きい優先度を持つポリシーを記述可能とすることにより、帯域が大きく処理能力が高い、回線費用がかからないなどの理由で積極的に活用したい回線や、業務提携を行っているなどの理由により通信性能を向上させたい相手のASなどに関して優先順位づけを行うことができる。

また前記第５の特徴によってデフォルトよりも小さい優先度を持つポリシーを用意することにより、例えば従量課金による回線費用がかかるなどの理由で出来る限り使用したくない回線に関する制御を行うことができる。

前記第６の特徴によれば、前記第５の特徴による制御を行ったが実際のユーザの分布状況によりトラフィック制御の効果がないような場合であっても、最も低い優先度を設定することで、いかなる場合においてもその優先度に該当するピアを選択しないよう制御することが可能である。

前記第７の特徴によれば、ピアへの経路情報が動的に変化する場合であっても、該変化に追従して各ピアのネットワーク的な状態を把握できるので、動的に変化するネットワーク情報に応じたピアリスト情報を作成できる。

ポリシー管理システムを利用したP2P通信が実施されるネットワーク構成の概略図である。本発明の一実施形態のポリシー管理システムの構成を示す図である。優先度マップの例を示す図である。優先度マップを作成する処理のフローを表す図である。ピアリスト情報を作成する処理のフローを表す図である。ポリシー管理システムの稼働中にポリシーを変更する場合の処理のフローを表す図である。本発明の他の実施形態の、経路情報が動的に変化する場合のポリシー管理システムの構成を示す図である。

以下に、図面を参照して本発明の実施形態について詳細に説明する。図１に本発明を利用したP2P通信が実施されるネットワーク構成の概略を示す。ネットワーク内には、P2P通信を行う各ユーザ１、ユーザ２、ユーザ３等の複数のユーザが存在する。各ユーザはP2P通信を行う要求ピアであり同時に所望コンテンツ等をピース片等の形で提供するために保持している候補ピアでもある。

例えばユーザ１が要求ピアでコンテンツ等を要求する場合、まず(a)に示すようにネットワーク内の配信制御サーバにコンテンツIDと要求ピア自身（ユーザ１）の情報を送信する。配信制御サーバは(b)に示すように要求ピアと通信可能でありかつ要求されたコンテンツの各ピース片を保有している候補ピアのリストをピース片毎に要求ピアに返信する。このリストの中から、実際に要求ピアがP2P通信によりコンテンツをダウンロードする際に運用者側で設定したポリシーに従ったネットワーク利用がなされるようにするため、続いて(c),(d)にて示される要求ピアと本発明のポリシー管理システム１とのやりとりがなされる。

(c)では要求ピアはポリシー管理システム１に対して、要求ピア自身の情報と配信制御サーバより受信した候補ピアの情報と（各情報それぞれ、IPアドレスなどとして）をピアリスト要求として送信する。ポリシー管理システム１はピアリスト要求の中から、要求ピアがコンテンツダウンロードで通信するにあたって管理者の定めるポリシーに沿う候補ピアを選出してピアリスト情報とし、(d)に示すようにユーザ１（要求ピア）に返信する。

ユーザ１（要求ピア）は受信したピアリスト情報を用いて所望コンテンツを各ピース片としてダウンロードし、ピース片を結合して所望コンテンツを得る。この際のネットワーク利用においてはポリシー管理システム１から受信したピアリスト情報を利用するので運用者の設定したポリシーを反映した利用がなされる。

なお、配信制御システムは所望コンテンツがネットワーク（要求ピア近辺に限定したネットワークを含む）に分散配置されていない場合、最初にコンテンツを分散配置してP2P通信が可能なようにする役割なども担う。またユーザ自体（要求ピア・候補ピア）が部分的に配信制御システムの役割を担うことも可能である。

次にポリシー管理システム１の本発明の一実施形態における構成を、図２を参照して説明する。ポリシー管理システム１は図２に示すように、ポリシー管理部２、優先度マップ算出部３およびサーバ部４を含む。ポリシー管理部２は運用者が入力する所定のポリシーをポリシーテーブルとして管理・保存する。優先度マップ算出部３はポリシーテーブルを読み込んで優先度マップを作成する。サーバ部４は、ユーザ（要求ピア）からのピアリスト要求を受信し、優先度マップ算出部の優先度マップを参照してピアリスト要求中の各候補ピアに優先度づけを行い、候補ピアを選定してユーザにピアリスト情報として返信する。次に、各部の詳細について説明する。

ポリシー管理部２では、運用者の入力するポリシーをポリシーテーブルとして管理・保存する。ポリシーテーブルは行単位で構成され、各行にはポリシーすなわち要求ピアの条件、候補ピアの条件およびそれらペアに対する優先度が記載されている。例えばポリシーテーブルの１つの行（ポリシー行）は次の[ポリシー例１]のようになる。
[ポリシー例１]
SID1:SID2:100

この場合、要求ピアがSID1に属し、候補ピアがSID2に属するならばその優先度を数値100に設定することを意味する。SID1およびSID2は運用者が定めるプレフィクス分類用のID(SID、セグメントＩＤ)の例である。各SIDに含まれるアドレス空間の集合は、次に具体的に示すようにプレフィクス集合として予め与えられていて、その情報はポリシーテーブル内に含まれる。
[SIDの定義例]
SID1: 20.0.0.0/24, 20.0.1.0/24
SID2: 21.0.0.0/24, 21.0.1.0/24
この定義により、ピアの属するSIDは、ピアのIPアドレスが含まれるプレフィクスの属するSIDとして決定できる。（なおまた、SIDに含まれるアドレス空間の集合が動的に変化する場合については後述する。）運用者は、ポリシーテーブルにおけるSID条件のペアに対する所定の優先度づけによって所望のポリシーを反映したネットワーク利用がなされるようにするため、上記のように各々のSID自体も所定の条件のプレフィクスを定義する。

各SIDに属するプレフィクスの選定は運用者が行うが、SIDの選定・分類の基準としてはネットワークセグメント（ネットワークの範囲、部分）の情報すなわち経路情報やネットワークトポロジ（同一データリンクにあるものを一つのSIDとするなど）を考慮した情報を利用してもよい。例えば各ASをネットワークセグメントの単位として、SIDにネットワークセグメントのIDを用いてもよい。

またこのような情報に追加して、もしくはこのような情報とは無関係に、ネットワーク帯域の情報や、プレフィクス内のピアの通信量の情報や、ネットワーク運用事業者の情報などをSID選定・分類基準としてもよい。SIDペアに対して定義する優先度も、これらの組み合わせに基づいて運用者は所望の値を設定することができる。

[ポリシー例１]のような形式のポリシー行を構成単位とすることでポリシーテーブルは次の[ポリシー例２]のような複数行の記述により構成される。
[ポリシー例２]
SID1:SID1:100
SID2:SID2:50
SID1:SID2:30

このような形式のポリシーテーブルを参照して要求ピアと候補ピアのペアに対する優先度を決定する場合、全ポリシー行を順に評価する。途中で条件一致する行にたどり着くと、その行に記載された優先度を要求ピア・候補ピアの条件に対する優先度として決定する。また最後の行まで全て条件が一致しなかった場合には、デフォルトの所定の優先度(例えば0)がその候補ピアの優先度となる。このようにして、ポリシーテーブルの記載は(記載がない場合はデフォルトを用いて)、要求ピアに対する全ての候補ピアにつき優先度が定まるような形式となっている。

優先度マップ算出部３では、ポリシー管理部２におけるポリシーテーブルをそのままの形式で（逐次行を評価して条件一致行を探すことにより）利用して優先度を求めるのは効率が悪いため、頻繁に実施することとなる優先度計算を高速に実施できる優先度マップを予め作成しておく。なお、優先度マップは作成元のポリシーテーブルに記載のSID自体の定義も後述する行列形式部分とは別に保有しているものとする。

優先度マップは、要求ピア条件の種類数分の行数と、候補ピア条件の種類数分の列数をもち、その交差する部分（対応する行列要素）に優先度を記述した行列形式のマップである。例えば[ポリシー例２]のポリシーテーブルから作成される優先度マップは図３のようになる。図３に示すように[ポリシー例２]のポリシーテーブルではポリシー行による記載指定のない要求ピア条件SID2、候補ピア条件SID1に対しては優先度のデフォルト値として0が与えられている。

以上のように、ポリシー管理部２および優先度マップ算出部３においてポリシーテーブルが設定され優先度マップを算出され、ポリシー管理システム１がユーザからのピアリスト要求を受信可能になるまでの処理の流れを図４に示す。

ステップS1では管理者が初期ポリシーをポリシーテーブルの形式で設定し、ポリシー管理システム１を起動してポリシー管理部２にポリシーテーブルを入力する。ステップS2では優先度マップ算出部３がポリシーテーブルを読み込み、ポリシー行に含まれる要求ピア条件の種類、候補ピア条件の種類を抽出して、それらを行数、列数としてかつ行番号、列番号がそれぞれ要求ピア条件、候補ピア条件に対応する優先度マップの行列領域を確保する。ステップS2で確保された行列領域はその各行列要素にポリシーテーブルの優先度を入力する前の状態である。

ステップS3では優先度マップ算出部３がさらにポリシーテーブルのポリシー行を順に読み込み、各ポリシー行の要求ピア条件、候補ピア条件に該当する行番号、列番号の行列要素に、該当ポリシー行の優先度を入力する。ただし、既に数値が入力済みの場合は更新は行わない。すなわちポリシーテーブルのポリシー行に、要求ピア条件と候補ピア条件のペアが同一になるような複数の行が存在した場合には、行数が最も小さいポリシー行に記載の優先度が優先度マップに記載され、サーバ部４でのピアリスト情報作成に用いられることとなる。ポリシーテーブルの全ポリシー行の読み込み、優先度マップの該当箇所への入力を終えると、優先度マップにおいて優先度が入力されていない残りの箇所全てにデフォルト値を入力して、ステップS3を終える。

ステップS4では、ステップS3にて全行列要素に入力を終えた優先度マップをサーバ部４から参照可能になり、ユーザからのピアリスト要求に応答する準備が整ったので、サーバ部４を稼働させ、ユーザからの要求を受け付け可能な状態とする。

次に、図４のような手順にてユーザからのピアリスト要求を受信可能になったサーバ部４がピアリスト情報を作成する処理の流れを図５を用いて示す。この手順により、ピアリスト要求中に記載された複数(N個)の候補ピアから優先度の高い所定のn個(n≦N)の候補ピアを選択してユーザに返信するピアリスト情報が作成される。

ステップS11ではユーザから受信したピアリスト要求に記載の要求ピアのIPアドレスから、要求ピアのSIDを調査する。この調査は前述のとおり優先度マップに行列部分とは別に保存されているSIDの定義を参照し、SIDに含まれるプレフィクスをサーバ部４が参照し、要求ピアのIPアドレスが所属するプレフィクスを探索し、該当プレフィクスのSIDを要求ピア自体のSIDとすることにより行う。

ステップS12ではピアリスト要求中の全N個の候補ピアに対して処理を行うためのカウンタi（1≦i≦N）を１に設定する。ステップS13ではピアリスト要求中のi番目の候補ピアのSIDを(要求ピアでの調査と同様にして)、候補ピアのIPアドレスから調査する。ステップS14では要求ピアのSIDとi番目の候補ピアのSIDとを参照して、優先度マップにおける要求ピアSIDに対応する行とi番目候補ピアのSIDに対応する列に記載の優先度を該候補ピアの優先度として決定する。

ステップS15ではカウンタiがN未満か調査し、肯定の判断の場合はピアリスト要求中の全N個に対する優先度決定の処理がまだ終了していないのでステップＳ１８へ移りiを1増やして次の候補ピアに対して再びステップS13,S14の処理を行う。i=Nとなって全候補ピアに対して優先度が決定され、ステップS15の判断が否定となるとステップS16に進む。

ステップS16では候補ピアを優先度の高い方から順にソートし、ステップS17ではソートの結果から上位n個の候補ピアをユーザ（要求ピア）に返答するピアリスト情報として選定する。

次に、ポリシー管理システム１が既存の優先度マップを参照して動作中に、運用者がポリシーテーブルの全体または一部を変更した場合の処理の流れを図６を用いて示す。この処理により、ポリシー管理システム１はポリシー変更があった場合も無停止でユーザからのピアリスト要求に応答することが可能となる。なお、ポリシーテーブルにおける優先度設定対象のSIDはプレフィクス等の情報から構成されるが、運用者が管理しているASが大規模な場合プレフィクスは例えば数千〜数万程度存在することもあるため、ポリシーテーブルも巨大となりうる。図６の処理によりこうした巨大なポリシーテーブルに変更を加える場合でもポリシー管理システム１は無停止でユーザにサービスを提供できる。

まず、図６の処理の開始時点においては図５のような処理によって運用者設定の初期ポリシーが優先度マップに読み込まれ（およびポリシー変更があった場合はこれより説明する図６の手順を経て優先度マップ変更が反映され）、ポリシー管理システム１はサーバ部４にてユーザからのピアリスト要求を処理できる状態で稼働しているものとする。

まず、ステップS21にて部分的にもしくは全体を変更したポリシーをネットワーク運用者が記述し、ポリシーテーブルの形式で用意してポリシー管理部２に新規ポリシーテーブルとして入力する。ポリシー管理部２では変更を反映された新規ポリシーテーブルが保存される。

ステップS22では優先度マップ算出部３が現在の優先度マップ（新規の優先度マップとの区別で旧優先度マップと呼ぶこととする）をサーバ部４が参照できるように維持したまま、新規に優先度マップ用の行列領域を確保する。すなわち、初期ポリシーテーブルから初期優先度マップの行列領域を確保した図４のステップS2と同様の処理が、新規優先度マップ領域に対して行われる。新規ポリシーテーブルからポリシー行に含まれる要求ピア条件の種類、候補ピア条件の種類を抽出して、対応するサイズの行列領域を優先度入力用に確保する。またステップS22にて新規優先度マップに対して、新規ポリシーテーブルに記載のSID定義も行列領域とは別に保存される。

ステップS23では、新規確保された領域に対して図４のステップS3に相当する処理を行う。すなわち、新規ポリシーテーブルを順次読み込み、要求ピア条件・候補ピア条件のペアに対応する優先度を対応する行列要素に入力する。全ポリシー行を読み込み終えると、優先度が入力されていない箇所にデフォルト優先度を入力する。こうして新規優先度マップが作成される。このステップS23の処理の間もステップS22の場合と同様に、ユーザからのピアリスト要求に対しては維持してある旧優先度マップを参照してピアリスト情報を作成する。

ステップS24では、作成完了した新規優先度マップをサーバ部４の参照用に利用できるようにし、維持しておいた旧優先度マップを削除する。以上のようにしてユーザからのピアリスト要求に対する応答処理を続けたまま、無停止にて新規優先度マップへの更新が可能である。

次に、ポリシーテーブルで設定し、優先度マップにおいてピアリスト情報作成のため参照される優先度の詳細設定につき説明する。優先度は例えば数値で表し、デフォルトを０とする。デフォルトとは、前述のようにポリシーテーブルで要求ピア条件と候補ピア条件との条件ペアに対して優先度を入力していない場合に優先度テーブル作成時に自動入力される値であるが、ポリシーテーブルにおいて所定条件ペアに対して明示的にデフォルト値を入力しておいても構わない。

デフォルトよりも高い優先度を設定する場合は、０よりも大きな値を用いる。前述のようにピアリスト情報は優先度が高い方から順にソートして作成するので、デフォルト値０よりも高い値の優先度を用いることによって候補ピアのうち、要求ピアに対して特に選択したいピア（の条件ペア）に対して優先順位づけが可能となる。また、デフォルトよりも小さい優先度として例えば以下の２つを用意する。

優先度−１：選択しない方が望ましいことを示す優先度。図５において説明したように、ピアリスト要求中の全候補ピアN個のうちピアリスト情報としてn個を選ぶ場合に、優先度が０以上のものが全て選ばれてもまだn個に達しない場合に、残りを優先度−１の候補ピアから選ぶようにする。

優先度−９９：選択してはならないことを示す優先度。この場合上述と同様にN個中n個を選ぶとして、優先度−１までのものでn個に満たない場合であっても、優先度−９９のピアは選択しない。よって優先度−９９の設定がある場合は、図５のステップS16、S17を経ても所定数n個未満のピアリスト情報となる場合がありうる。

以上の説明では、経路情報（要求ピアおよび候補ピアのIPアドレスへの経路情報であり、各ピアをSIDに対応付けるのに利用できる情報）がプレフィクスとして予め静的に与えられ、ポリシー管理システム１において静的な経路情報を管理し、サーバ部４がSID調査で参照する構成を示していた。

図７にその拡張的な実施形態として、SIDに対応する経路情報が動的に変化する場合のポリシー管理システム１の構成を示す。本構成は静的な場合を想定した図２の構成と比べて、動的な経路情報を収集・解析するために経路解析部５が追加構成として存在する。図７の場合においてもポリシー管理部２、優先度マップ算出部３およびサーバ部４は図２の場合と同様の処理を（対応するプレフィクスが経路情報の収集によって動的に変化するSIDに対して）行う。

経路解析部５はSIDと、SIDに対応する経路条件とで構成された経路グループテーブルを有する。経路グループテーブルは運用者がポリシー管理部２において入力するポリシーテーブルからSIDの定義部分をコピーしたものである。経路解析部５によって動的な経路情報にも追従できる本実施形態では、上述の静的な場合の実施形態で説明した[SIDの定義例]におけるような静的なプレフィクスリストによるSID定義に加えて、経路条件の記載によるSIDの定義が可能となる。すなわち経路条件はSID定義に用いる条件として、運用者によりポリシーテーブル内に記載され、経路グループテーブルに反映される。経路解析部５は後述のように動的に変化する経路情報（プレフィクスへの経路情報）を収集することで、経路グループテーブルにおいて収集した経路情報に対応する経路条件のSIDに属するプレフィクスを動的に更新する。

こうして本実施形態におけるピアリスト情報提供の流れは、
(1)運用者が経路情報による定義を含めたSID定義と共にポリシーテーブルを作成しポリシー管理部２に入力
(2)ポリシーテーブルのSID定義を経路解析部５が経路グループテーブルとしてコピー
(3)経路解析部５が収集した経路情報によって経路グループテーブルに記載のSIDに対応するプレフィクスを更新し、ポリシー管理部２のポリシーテーブルにおける各SIDに属するプレフィクスの情報を更新
(4)各SIDに属するプレフィクス情報を更新されたポリシーテーブルから優先度マップ算出部が優先度マップを算出
となり、サーバ部４は(4)の優先度マップを用いて、静的な場合の実施形態として説明した図５と同様の処理でピアリスト情報を作成する。

経路情報の収集は例えば、経路解析部５がルータと接続し、ルータがBGP(Border Gateway Protocol)ルータであればBGP UPDATEのメッセージを、OSPF(Open Shortest Path First)ルータであればOSPF LSA(リンクステート広告、LSAのうち特にNetwork Summary LSA)のメッセージを収集することによってなされる。また、このようなメッセージをルータから直接受信するのではなく、ルータが収集した経路情報をMRT等のファイル形式に蓄積したものを参照することによって経路情報を収集してもよい。

以下に、経路グループテーブルの例と、経路解析部５がルータ等から経路情報を収集して経路グループテーブルを更新する例を示す。まず、経路グループテーブルは次に例[A]を示すとおり、各SIDに対応する静的なプレフィクスリストや、プレフィクスの属する経路属性指定（例えばAS経由の経路指定）などの経路情報から構成される。（静的なプレフィクスリストも経路情報の一種とみなしてよい。）経路グループテーブルの情報は前述のように運用者がポリシーテーブルの優先度の記載にあたり、各SIDにプレフィクスが属する条件として定義してポリシーテーブル内に記載しておく。
[経路グループテーブルの例Ａ]
SID1:prefix_list1
SID2:prefix_list2
SID3:Origin_AS=200&AS_path_len<3&next_hop=10.1.1.1
SID4:Origin_AS=200&AS_path_len<3
SID5:Neighbor_AS=100
SID6:others
ここで経路グループテーブルの１,2行目(SID1,SID2)において静的なプレフィクスリストとして以下を用いることとする。
prefix_list1: 10.0.0.0/24, 10.0.1.0/24
prefix_list2: 11.0.0.0/24, 11.0.1.0/24

すなわち、経路グループテーブルの例Ａでは、１，２行目はSID1、SID2に属するのは上記のprefix_list1、prefix_list2のリスト内のプレフィクスであることを示している。また、３，４行目ではSID3,SID4はAS経由の経路情報を、経路情報生成元である経路の末端AS(Origin_AS)の番号指定と、経由するASの数を示すASパス長(AS_path_len)の指定と、末端ASから宛先(経路情報を収集しているルータ)へ経路情報が到達する際の末端ASのボーダルータ（ネクストホップ、next_hop）のIPアドレスによる指定(SID3のみ)とによって示している。5行目のSID5では経路情報を交換する隣接AS(Neighbor_AS)の番号指定によって経路情報を示している。SID3,SID4,SID5ではそれぞれ該当する経路情報に一致するプレフィクスが該当SIDに属することとなる。また6行目のSID6は以上のSID1〜SID5に該当しなかったプレフィクスが所属するSIDである。

次に、[経路グループテーブルの例Ａ]を更新する、ルータ等から受信する経路情報の例[B]を示す。
[経路情報の受信例Ｂ]
(1) ANNOUNCE,10.0.0.0/24, 300 200, next_hop=10.2.2.2
(2) ANNOUNCE,11.0.0.0/24, 300 200, next_hop=10.1.1.1
(3) ANNOUNCE,12.0.0.0/24, 100 200, next_hop=10.1.1.1
(4) ANNOUNCE,13.0.0.0/24, 100 200, next_hop=10.2.2.2
(5) ANNOUNCE,14.0.0.0/24, 100 400, next_hop=10.2.2.2
(6) ANNOUNCE,15.0.0.0/24, 200 400, next_hop=10.2.2.2
(7) WITHDRAW,14.0.0.0/24
(8) ANNOUNCE,16.0.0.0/24, 100 200, next_hop=10.3.3.3

以上(1)~(8)の受信例はその行数の示す順に経路情報を受信したものであり、受信順で逐次経路グループテーブルにおけるSIDに対応するプレフィクスを更新する。このように受信した経路情報に対して以下で具体的に述べるように経路グループテーブルを順に解析・参照することで、経路条件のみで定義したSID3〜SID6のようなSIDに対しても具体的に所属するプレフィクスが決まり、プレフィクスリストを含むSIDが定義・作成される。

またこの受信例[B]はBGP経路受信の例であり、BGPメッセージ識別(ANNOUNCE=経路受信、またはWITHDRAW=経路取消)、対象プレフィクス、ASパス(ANNOUNCEの場合に経由ASをそのAS番号の経由順に列挙して表示。Origin_ASにおけるnext_hop指定がある場合は加えて表示)の順に並べられたデータ形式となっている。また[A]に例示したような経路グループテーブルの更新にあたっては、受信した経路情報を経路グループテーブルに記載のSID行に対して順次一致するか確認し、一致した行のSIDを更新する（その行以降に一致する行があったとしても更新されない）。

受信例[B]において(1)では対象プレフィクス10.0.0.0/24が経路グループテーブル[A]１行目のSID1のprefix_list1に一致する。すなわちprefix_list1の10.0.0.0/24への経路が[B](1)受信時点で存在していることが確認されたのでprefix_list1をそのまま残す。また[B](1)は[A]SID1に一致したので、2行目のSID2以降の一致確認は行わない。

次の経路受信[B](2)では対象プレフィクス11.0.0.0/24は[A]SID1には一致しないのでSID2を確認するとprefix_list2内にプレフィクスが存在する。よって[B](2)受信時点でSID2のprefix_list2内の11.0.0.0/24への経路の存在が確認されたのでprefix_list2をそのまま残す。そしてSID2以降の行の確認評価は行わない。

次の経路受信[B](3)では対象プレフィクス12.0.0.0/2は[A]SID1,SID2の順に確認しても存在しないので次のSID3との一致を確認すると、Origin_AS=200、AS_path_len=2<3、next_hop=10.1.1.1であり、SID3に記載の全条件に一致する。よって[B](3)の受信経路のプレフィクス12.0.0.0/2をSID3に加える。SID4以降の評価は行わない。

次の受信経路[B](4)では対象プレフィクス13.0.0.0/24は[A]SID1,SID2に一致せず、次のSID3を確認してもnext_hop=10.2.2.2が一致しない。そして次のSID4にOrigin_AS=200、AS_path_len=2<3として一致するのでSID4に当該プレフィクス13.0.0.0/24を加える。SID5以降の評価は行わない。

同様に次の経路受信[B](5)では対象プレフィクス14.0.0.0/24はSID1,SID2に一致せず、またその経路条件はSID3,SID4にも一致しない。そしてSID5のNeighbor_AS=100に一致するため、SID5に当該プレフィクス14.0.0.0/24を加える。SID6の評価は行わない。

次の経路受信[B](6)では対象プレフィクス15.0.0.0/24はSID1,SID2に一致せず、SID3,SID4,SID5の経路情報にも一致しない。よってSID6(SID1〜SID5に該当しない残り)に当該プレフィクス15.0.0.0/24を加える。

次の経路受信[B](7)はプレフィクス14.0.0.0/24の取り消しであり、これは[B](5)を受信した時点からSID5に所属しているプレフィクスである。よってSID5から当該プレフィクス14.0.0.0/24を取り除く。

次の経路受信[B](8)では対象プレフィクス16.0.0.0/24はSID1~SID3には一致せず、SID4にOrigin_AS=200、AS_path_len=2<3として一致する。よってSID4に当該プレフィクス16.0.0.0/24を加える。SID5以降の評価は行わない。

以上、経路受信[B](1)~(8)の適用によって[経路グループテーブルの例A]の各SIDに所属するプレフィクスのリストは以下のとおりとなる（なおSID3~SID6に関しては[B]によって追加されたプレフィクスである）。
SID1: 10.0.0.0/24, 10.0.1.0/24
SID2: 11.0.0.0/24, 11.0.1.0/24
SID3: 12.0.0.0/24
SID4: 13.0.0.0/24, 16.0.0.0/24
SID5: null (該当プレフィクスなし)
SID6: 15.0.0.0/24

なお、本実施形態のように動的に更新される経路情報を経路解析部５で受信して利用する場合においても、SIDに対応するプレフィクス集合が更新されたポリシーテーブルに対して図６で説明したポリシー変更と同様の処理を行うことで、更新された経路情報を適用しつつ無停止の運用が可能である。また図６の説明は静的なプレフィクス情報でSIDを定義する実施形態における説明であったが、経路情報が動的に更新される実施形態でSIDを経路条件で定義する場合にポリシーを変更する場合も適用可能である。

１…ポリシー管理システム、２…ポリシー管理部、３…優先度マップ算出部、４…サーバ部、５…経路解析部

Claims

P2P通信を利用して所定データを求める要求ピアから、該要求ピアの情報および該所定データを保有し通信対象となる複数の候補ピアの情報を記載したピアリスト要求を受信し、前記ピアリスト要求中の候補ピアを選別してピアリスト情報として前記要求ピアに返信するP2P型通信用ポリシー管理システムであって、
前記要求ピアの条件と前記候補ピアの条件との組み合わせに対して所定の優先度を定めたポリシーテーブルを入力され保存するポリシー管理部と、
前記ポリシーテーブルを読み込んで優先度マップを作成・保存する優先度マップ算出部と、
前記ピアリスト要求を受信し、前記優先度マップを参照して前記要求ピアとの優先度に基づいて前記ピアリスト要求中の候補ピアを選出して前記ピアリスト情報を作成し、前記要求ピアに返信するサーバ部とを含むことを特徴とするP2P型通信用ポリシー管理システム。
前記要求ピアの条件および前記候補ピアの条件が、各ピアの所属するネットワークセグメントのＩＤによって識別される条件であることを特徴とする請求項１に記載のP2P型通信用ポリシー管理システム。
前記P2P型通信用ポリシー管理システムが既存の第一の優先度マップを用いて稼働中に、前記ポリシー管理部に対して前記ポリシーテーブルが更新入力された場合、
前記優先度マップ算出部は前記第一の優先度マップを保持しつつ該更新入力されたポリシーテーブルを読み込んで第二の優先度マップを作成し、
該第二の優先度マップ作成中に前記サーバ部が前記ピアリスト要求を受信した場合、前記サーバ部は前記第一の優先度マップを参照して前記ピアリスト情報を作成し、
前記第二の優先度マップ作成後に前記サーバ部が前記ピアリスト要求を受信した場合、前記サーバ部は前記第二の優先度マップを参照して前記ピアリスト情報を作成することを特徴とする請求項１または２に記載のP2P型通信用ポリシー管理システム。
前記ポリシーテーブルは前記要求ピア条件と、前記候補ピア条件と、該要求ピア条件と該候補ピア条件の組み合わせに対する優先度と、を列挙して対応づけた形式の行を構成単位として複数行からなり、
前記優先度マップ算出部は前記ポリシーテーブルを読み込んで前記優先度マップを行列の形式で作成し、
該行列は前記要求ピア条件に対応する行と前記候補ピア条件に対応する列とを有し、該行および該列に対応する前記優先度を行列要素として有することを特徴とする請求項１または２に記載のP2P型通信用ポリシー管理システム。
前記優先度マップ算出部は、前記ポリシーテーブルに入力の優先度に追加して、前記ポリシーテーブルに未入力の前記要求ピアの条件と前記候補ピアの条件との組み合わせに対して第一の優先度を定めて前記優先度マップを作成・保存し、
前記ポリシーテーブルに入力される前記優先度は、前記第一の優先度よりも高い第二の優先度または前記第一の優先度よりも低い第三の優先度を含み、
前記サーバ部は前記候補ピアを該候補ピアの優先度が高い順に選出して前記ピアリスト情報を作成することを特徴とする請求項１または２に記載のP2P型通信用ポリシー管理システム。
前記ポリシーテーブルに入力される前記優先度は、前記第一、第二および第三の優先度を含む他の全ての優先度よりも低い第四の優先度を含み、
前記サーバ部は、前記ピアリスト情報を作成するにあたり、前記第四の優先度に該当する候補ピアは選出しないことを特徴とする請求項５に記載のP2P型通信用ポリシー管理システム。
さらに、前記ポリシーテーブルにおける前記要求ピアの条件および前記候補ピアの条件を、前記P2P通信が行われるネットワークで稼働するルータが発する経路情報を用いて更新する経路解析部を含むことを特徴とする請求項１または２に記載のP2P型通信用ポリシー管理システム。