図 1-1 サービスブロック図
キーワード： ポリシー,PBNM,組織間QoS提供,組織間課金,BGP4,COPS江端智一、滝広眞利、三宅滋、小泉稔
（株）日立製作所システム開発研究所
〒244-0817 横浜市戸塚区吉田町292番地
TEL:045-860-3079 FAX:045-860-1675E-mail: ebata@sdl.hitachi.co.jp
近年、QoS制御を可能とするルーター等の通信機器の出現により、これら機器を連携させてQoSを保証する通信サービスの提供することが可能となり、さらにこのサービスを、「ポリシー」という枠組みで統合管理するポリシーベースネットワーク管理(PBNM)が着目されつつある。しかし、現在PBNMは単一組織内の管理を対象としており、複数の企業ネットワーク、キャリア、サービスプロバイダー等、異なるポリシーにて管理されるネットワークをまたがるQoS保証型サービスには対応していない。本論文では、ポリシーの異なる組織間でQoS保証サービスと、そのサービスに対して発生する組織間課金サービスを行なう為に必要となる、ポリシーフレームワークとアーキテクチャについて考察した。また、前記サービスを実現する「組織間ポリシー配布プロトコル」「組織間ポリシー交渉・通知プロトコル」[INTD]を提案し、実証実験により、これらのプロトコルの有効性を確認した。
最近このようなQoS保証型サービスを提供するインターネットサービスプロバイダ(ISP)と、そのサービスを利用するユーザとの間で、サービスに関する契約を記載するSLA(Service Level Agreement) [SLA]の利用が注目されるようになってきている。SLAは、ISPとユーザの間で取り交わされる契約内容であり、ユーザが利用するサービスと、そのサービスに対してユーザがISPに支払う課金の契約内容を含んでいる。QoSと課金は、SLAという契約体系の元で、今後のインターネットサービスにおいて不可欠なものとなりつつある。
このような状況の元、上記のQoS、課金、およびSLAを、ポリシーという枠組みで統合管理するポリシーサーバ[Term]の存在がクロースアップされるようになってきている。このようなポリシーサーバを用いてポリシーベースでネットワーク管理形態を、ポリシーベースネットワーク管理(PBNM)と呼ぶ。
一方、企業間のコラボレーションや企業活動のグローバル化により、異なる企業組織ネットワーク、キャリア、又はISPにまたがるQoS保証型サービスの提供およびそれに対する課金が、今後益々重要となってくることが予想される。この場合、それぞれの組織のポリシーは、ネットワーク管理者の意図を反映して作成されるため、ポリシーの内容は組織毎に異なるものになり、ある組織に適用されているポリシーを、他の組織で適用することは一般的に不可能である。従って、単一組織を前提としたPBNMでは、上記の組織間をまたがるQoS,課金制御に対応することができない。
IETFのPolicy WGでは、ポリシーサーバで用いるポリシーのコア部分となるポリシーコアスキーマおよびQoSスキーマの制定が進められているが、現在のところ、単一組織のネットワークでの制御・運用を前提としているのが実状である。
本論文の目的は、組織間でのQoS保証型のサービスの提供と課金を実現することである。
これらを実現とするためには、ISPなどのネットワークサービスプロバイダによって、それぞれ組織間QoS提供サービス、組織間課金サービスが、基本的なサービスとして提供される必要があり、本論文では、それらの制御方式について述べる。
図 1-1 サービスブロック図
本論文の構成は以下の通りである。
第2章では、組織間で用いられるポリシーフレームワークと、そのフレームワークを組織間QoS提供と組織間課金に適用した事例について説明する。また、このフレームワークから、前記２つのポリシーフレームワークで用いられる１０の種類のポリシーを抽出し、その中から組織間で交換が必要となる６つのポリシーを選ぶ。さらに、その６つのポリシーが必要とする交換の方法を明らかにする。
第3章では、ポリシーを交換するアーキテクチャに関して、(a)各組織のポリシーサーバを統合する上位ポリシーサーバが存在する体系と、(b)存在しない体系での比較を行ない、アーキテクチャの課題を明らかにする。また、ポリシー交換を実施するシステムが前提とする環境について説明する。
第4章では、ポリシー交換の一手段として提案する、組織間ポリシー配布プロトコルについて、また第5章では、組織間ポリシー交渉・通知プロトコルについて説明する。
さらに、第6章では、前述の２つのプロトコルを実装したポリシーサーバを含むネットワーク環境にて、実証実験を実施し、その結果得られた評価に関して述べる。
コンディション ポリシー アクション +-------------+ リクエスト--> |・属性１〜n |---> レスポンス or レスポンス |・ルール１〜m| or リクエスト +-------------+
図 2-1 ポリシーの定義
この定義では、機能を管理するルールは、単一のポリシーとしてグループ化される。例えば、顧客要求に含まれる特定のパラメータのように、与えられたコンディションは、ポリシーのルールによって評価され、アクションの形で出力される。出力されたアクションは、他のポリシーをアクティブにするきっかけになり、特定の処理やデバイスの制御を行なう事になる。
図 2-1 組織間ポリシーフレームワーク
サービスに関するポリシーとは、組織内外で利用可能なサービスに関するポリシーを扱うものである。具体的には、サービスの属性情報（サービスの性質（要リアルタイム等）、使用プロトコル、期待されるQoS品質、利用可能時間、利用料金等）と、これらの属性情報を組み合わせて構成されるルール（もし、サービスAが使われているなら、1分あたり10円課金する）からなる。
資源に関するポリシーとは、組織内外で利用可能なネットワーク資源に関するポリシーを扱うものである。具体的には、ネットワーク資源の属性情報（ネットワーク媒体、ルーティングプロトコル、QoSパラメータ(帯域幅、遅延、揺らぎ、最大スループット等）、QoSサービス種類（IntServ,DiffServ)等、あるいは、および利用情報（どのパスを使って、どれくらいの時間、どんなサービスを実施されたか）と、これらの属性情報を組み合わせて構成されるルールから成る。
ポリシーの決定とその結果に関するポリシーとは、ネットワーク機器に対する最終的な要求を作る、または、ネットワーク機器からの応答をまとめるものである。このポリシーは上記の要求の属性と、それに対する応答の属性と、それらの属性から構成されるルール（例えば、「もし、A氏のサービスに対して十分な帯域が取れないのであれば、他のユーザの帯域を減らせ」）から成る。
ポリシーの実施とその結果に関するポリシーとは、上位のポリシーに従って機器の設定を行なう属性情報と、設定によって得られた結果の情報を持つものである。上記レイヤーのポリシーを内容を受け、組織内で制御可能なネットワーク制御装置（例えばルータ）の設定や制御を行う。具体的には制御装置の属性値（設定パラメータの値）、及びその属性情報を組み合わせて構成されるルールと、ネットワークで観測されたパケットの実測情報から成る。
図 2-2は、図 2-1 組織間ポリシーフレームワークを、組織間QoS提供のポリシーフレームワークに適用したものである。
組織間QoS提供のプロセスは、前記フレームワークの上位のポリシーから水平あるいはトップダウン的に実行される。このプロセスは、QoS保証型サービスが、(1)誰が、(2)どのサービスを、(3)どのように、利用するかを、それぞれ(a)カスタマポリシー、(b)サービスポリシー、(c)リソースポリシーに入力することによって開始されることになる。あるカスタマがサービス利用を要求しても、そのカスタマに権限がない場合、あるいは、権限があってもそのサービスを実行するだけのリソースが残っていない場合などは、ポリシー間で要求を発行することで、サービスの利用を停止させることができる。
前記の３つのポリシーの出力となるディシジョン要求は、ディシジョンポリシーに入力され、各ネットワーク機器に対する具体的な命令となるエンフォースメント要求を発行する。このエンフォースメント要求によって、適当なエンフォースメントポリシーが起動し、ネットワーク制御装置が制御されることになる。
図 2-2 組織間QoS提供フレームワーク
組織間課金のプロセスは、前記フレームワークの下位のポリシーから水平、あるいはボトムアップ的に実行される。このプロセスは、ネットワークの状態を観測することのできる１つ以上の機器のメータリングポリシーが、ネットワーク上に流れる、パケットを検知することによって処理が開始される。このメータリングポリシーの出力は、リーディングポリシーに集められ、パケットをフローとして整理した後、リーディング結果として出力される。この出力は、アカウンティングポリシーの他、チャージングポリシー、ビリングポリシーに入力されてもよい。前記の３つのポリシーは、それぞれ組織間QoS保証サービスに関わるリソースの利用状況、サービスの実行状況、カスタマの負担コストとして、組織間QoS保証サービスに返されることになる。
図 2-3 組織間課金フレームワーク
(1)組織間でサービスを行なうにあたっては、相手側組織に、(a)サービスを提供しているかどうか、(b)サービスを要求する顧客が存在するかどうか、(c)サービスを行なうだけのリソースが存在すかどうか、がわからなければ、サービスを開始することが出来ない。
(2)組織間で課金を行なうにあたっては、相手側組織のサービスあるいはリソース利用料金体系がわからなければ、コストを算出することが出来ない。 (3)組織間で実際に利用したサービス、リソースとそれに対するコストを通知しなければ、課金を請求することができない
このように、各組織が、それぞれの組織のポリシーを相互に知っておかなければ、如何なる形でも組織間でのサービスや課金を実施できないことは明らかである。
以下に、組織間で交換する必要があると想定されるポリシーとそのポリシーの内容を示す。
(1)組織間QoS提供フレームワーク
組織内のカスタマの中で、組織間サービスの利用が可能なカスタマと、その属性と、そのカスタマに関するルールから成る。カスタマの属性としては、そのカスタマのプライオリティ、利用可能なサービス、そのサービスを利用できる時間等がある。
組織が提供し、かつ他組織のユーザも利用することのできるサービスの属性と、そのサービスに関するルールから成る。サービスの属性としては、組織の提供するサービス名、サービスの利用時間等がある。
組織が提供し、かつ他組織のユーザも利用することのできるリソースの属性と、そのリソースに関するルールから成る。リソースの属性としては、経路、その経路の有効帯域幅、最小遅延時間、最大転送単位、揺らぎ等がある。
(2)組織間課金フレームワーク
組織内で実施されたQoS保証型サービスで利用されたサービスに対して、組織外のカスタマに請求する課金情報とその属性から成る。
組織内で実施されたQoS保証型サービスの利用料金表、および利用されたサービスとその属性から成る。サービスの属性としては、実際に利用された組織の提供するサービス名、サービスの利用時間等がある。
組織内で実施されたQoS保証型サービスで利用されたリソースとその属性から成る。リソースの属性としては、実際に使用された経路、その経路の有効帯域幅、最小遅延時間、最大転送単位、揺らぎ等がある。
(1)サービス提供フレームワーク
(2)課金フレームワーク
図 2-4 配布を用いるポリシー
(1)サービス提供フレームワーク
(1)課金フレームワーク
図 2-5 要求応答・通知を用いるポリシー
このアーキテクチャに関しては、図 3-1に示すように２つの方式が考えられる。
(1)は上位のポリシーサーバを経由して、ポリシー交換するアーキテクチャである。このアーキテクチャでは、組織間で直接ポリシーの交換を行なう必要がなくなるため、ポリシーサーバの負荷が軽減できるというメリットがある一方で、組織間ポリシー交換を実施する全ての組織が、上位のポリシーサーバと連携している必要があるため、拡張性や柔軟性に乏しくなる。また上位ポリシーサーバの管理者が必要になるという問題もある。
一方(2)の方式は、各組織のポリシーサーバの処理負荷が高くなるという問題があるが、拡張性や柔軟性に高く、従来のインターネットの枠組みで実現することが可能である。またネットワーク管理者は自分の組織だけを管理していればよいという利点がある。
本報告書では、既存のインターネットのアーキテクチャと親和性の高い(2)の方式に関して検討を行なう。
図 3-1 ２つのポリシー交換アーキテクチャ
前章で説明したように、必要とされるポリシーの交換方法には、「配布」「要求応答」および「通知」の３種類が必要となり、このようなポリシー交換手段を具備しなければならない。
６種類のポリシーを組織間で交換することから、ポリシーサーバの通信負荷が大きくなることが予想される。案件が発生した時点において、全てのポリシーの交換を行なうと、ポリシーサーバの処理能力が劣化する恐れがある。このため、処理が一時に集中しないようにポリシーの交換を行なう必要がある。
(Step1)ポリシー配布フェーズ
ポリシー交換手段の「配布」を行なうものである。 組織のポリシーを他の組織に送信、あるいは受信する処理を行なう。
(Step.2)ポリシー要求応答・通知フェーズ
ポリシー交換手段の「要求応答」と「通知」を行なうものである。前記の公示されたポリシーを参照して、他の組織に対して要求内容が記載されたポリシーを送信、あるいは受信し、その応答内容が記載されたポリシーを送信、あるいは受信する処理を行なう。また、その要求応答によって実施された結果として、通知内容が記載されたポリシーを送信、あるいは受信する処理を行なう。
上記のポリシー交換を実現するために、「組織間ポリシー配布プロトコル」と「組織間ポリシー交渉・通知プロトコル」２つのプロトコルを用いる。 組織間ポリシー配布プロトコルは、2.6.1で述べたポリシーを組織に配布するプロトコルである。これについては、IPネットワーク上の組織間で情報を交換・共有するプロトコルとしてBGP4(Boarder Gateway Protocol 4)[RFC1364] [BGP4]が利用可能である。このBGP4は経路情報を交換するためのプロトコルであるが、その他の情報も設定できる付加できる機能があり、これを活用して組織間構成情報交換を実現する。
また、組織間ポリシー交渉・通知プロトコルは、2.6.2および2.6.3のポリシーを組織間で交換するプロトコルであり、必要な情報を運びつつ、制御のきっかけとなるシグナリングを発行する機能が必要となる。これについては、IETＦで標準化が進められているCOPS(Common Open Policy Service) [COPS]が利用可能である。現在COPSは、ポリシーを決定するポイント（例えばポリシーサーバ）と、そのポリシーを実行するポイント（例えばルータ装置）間で通信を行なうことが想定されているが、これを組織間に拡張して用いることで、組織間でのシグナリングを実現する。ただし、現状COPSは、組織内のポリシー決定ポイント(Policy Decision Point(PDP))と、ポリシー実施ポイント(Policy Enforcement Point(PEP))の間での使用しか想定されていない。
図 3-1は、組織間ポリシー制御を実施するシステムの構成例を示す図である。
各組織のポリシーは、各組織のポリシーサーバ(PS)が所有しているものとする。さらに、ポリシーサーバは、組織内のポリシーを実行する、あるいは組織間でポリシーの交換を行なう唯一の装置とする。
各組織(組織A,B,C,D)は、ルータ(R)および他の通信機器、ホストによってネットワークが構成されている。組織間は境界ルータ(BR)で接続されている。
これらの装置は、ポリシーサーバ(PSa,PSb,PSc,PSd)によって管理されている。ポリシーサーバは、自分の組織内の機器のみを制御することが可能である。
図 3-2 システム構成例
(1)近接組織ID(AS-ID)
(2)近接組織PSのIPアドレス
(3)近接組織BR-IPアドレス
(4)(3)のBRと組織のBRを接続する回線（以下、「組織間リンク」と呼ぶ）の属性(利用可能帯域、最小遅延時間、最大転送単位、ジッタ、および単位フロー最大レート等）
これらの情報の取得方法に関しては、特に限定せず本論文では言及しない。次に、上記情報を用いて、以下の情報を作成し、ポリシーサーバ内部に格納する。(1) 組織間通信を許可するホストまたはネットワークIPアドレス
(2) (1)が通信可能とする組織ID(AS-ID)
(3) (1)が(2)に至る為に経由する組織間リンクIDとそのポリシー情報
次項以降では、ポリシーサーバが上記の情報を保持していることを前提に説明する。ホストa1(Ha1)は組織Aの内部にあり、このHa1に至るには、組織間リンクLa1,La2,La3を介して、BRa1とBRa2を経由して到達することが可能であることと、およびそれぞれの経路において利用可能なQoS（例えば帯域幅）の値、Ha1のカスタマの属性情報などが、他の組織に配送される。
これらの情報は、組織内部のネットワーク構成状態を知っているポリシーサーバにて作成される。例えば、La1を経由してHa1に到達することが可能な帯域幅は、La1の帯域幅、および組織A内部のネットワークの帯域幅を加味して、適切な経路とその帯域幅情報を決定することになる。
このように、組織内部のネットワークの構成情報を反映したホストの情報が、組織間ポリシー配布プロトコルで配送されることになる。
図 4-1 PAPの概要
例えば、先ず、PSaがPScに対して、BRc1から、BRa2を介して、Ha1に到達する経路を使った場合、帯域情報が3.5Mbit/sであることを配布するとする。すると、PSｃは、自組織内部の帯域情報を調べ、利用可能帯域が2.7Mbit/sであり、さらに、BRc2とBRd1の組織間リンクの帯域が4.0Mbit/sであることが解っているので、組織内部の帯域幅である2.7Mbit/sで帯域幅が制約されると解釈する。結果として、組織Dでは、BRd1を介してHa1との間でQoS保証サービスを使うときには、2.7Mbit/sが有効な帯域幅であることがPSdに伝えられることになる。
上記の例は、QoSポリシーの一つとして、帯域幅の情報を扱ったものであるが、この様に組織間ポリシー配布プロトコルでは、配布ポリシーをポリシーサーバが変更すること許容することを特徴としている。
なお、上記の例では、組織A内部の一つのホストを例にして説明を行なったが、組織A内部のネットワークのアドレスを用いて、そのネットワークのポリシーを配布してもよい。さらに、組織Aそれ自体を一つのアドレスと見なしてポリシーの配布を行なっても構わない。
図 4-2 PAPのメッセージフォーマット
組織間ポリシー交渉・通知プロトコルは、組織間ポリシー配布プロトコルによって得られた各組織のポリシー情報を用いて、実際に交渉制御を行う為の通信プロトコルである。本プロトコルは、組織間をまたがった制御を行うことを前提としている。
図 5-1は、組織Aのあるユーザが、組織Dのあるユーザとの間でQoS保証型サービスを行うために、組織AのPSが組織CのPSを介して組織DのPSと交渉を行っている状況を示している。
図 5-1 PNPの概要
交渉案件が発生した場合、要求側組織のPSは、応答側組織のPSに対して、交渉内容を搭載したDecision(DEC(Install))メッセージを送出し、応答側組織のPSは、組織内でQoS保証パスが確立できるか否かを確認し、このDECメッセージに対して、交渉成立の可否結果を搭載したReport State(RPT(Installed))メッセージを返すことで、組織間で交渉案件の処理を行う。
ただし、上図に示すように、要求側組織のPSが、応答側組織のPSと物理的な接続関係を持たない場合、要求側と応答側の組織を結ぶ第３の組織を経由して（以後、経由組織と称す）QoS保証パスを確立する必要があるため、経由組織と応答側組織を含めた交渉制御を行うことになる。このような場合、要求側組織のPSは、組織間ポリシー配布プロトコルを使って配布されたポリシーを使って、応答側組織のPSに至るために経由しなければならない経由組織を決定し、その組織のPSに対して、交渉内容を搭載したDEC(Install)メッセージを送出する。
経由組織のPSは、この交渉内容を調べ、先ず自組織内でQoS保証パスが確立できることを確認したら、応答側組織に対して同じように交渉内容を搭載したDEC(Install)メッセージを送出する。応答側組織のPSは、組織内でQoS保証パスが確立できるか否かを確認し、このDEC(Install)メッセージに対して、交渉成立の可否結果を搭載したRPT(Installed/NotInstall)メッセージを、経由組織のPSに返し、さらに、この経由組織のPSは、要求側組織のPSに対して、交渉成立の可否結果を搭載したRPT(Installed/NotInstall)メッセージを返す。
このような処理を行うことで、要求側組織と応答側組織の間に、経由組織がいくつあっても対処可能となる。
図 6-1 実証実験環境
(1) PAP及びPNPによって配送されたポリシーの量は、それぞれ1.1kbit,1.4kbitであり、BGP4などのルーティング情報と比較しても十分小さな値であった。なお、PAPによるポリシー配布時間は平均300ms程度であった。
(2) ユーザインターフェースの処理を含むPNPの処理は平均１５秒程度であり、ネットワーク管理者へのインタビューの結果からも『ストレスを感じることはない』との回答を得た。
この他、ポリシーサーバのGUIが使い難く操作に手間取る等の意見もあったが、被験者からは概ね、実運用に耐えうるという回答を得る事ができた。(1)組織間ポリシーフレームワーク
ポリシーサーバが持つべき１０の種類のポリシーを抽出し、複数組織間ポリシー制御を行なうにあたり、組織間で交換が必要となる６つのポリシーを選んだ。さらに、これらのポリシーが「配布」「要求応答」「通知」の手段で交換すること明らかにした。
(2) 組織間ポリシー交換アーキテクチャ
既存のインターネットと親和性の高いアーキテクチャで用いる、前記のポリシーの交換を実現する通信プロトコル「組織間ポリシー配布プロトコル」と、「組織間ポリシー交換・通知プロトコル」の２つのプロトコルを提案した。
(3) 組織間ポリシー配布プロトコル
ルーティングプロトコルであるBGP4を拡張して、組織間でポリシーを配布する具体的な手段を詳細に説明した。
(4) 組織間ポリシー交渉・通知プロトコル
ポリシー配送とシグナリングのプロトコルであるCOPSを拡張して、組織間でポリシーを交換・配布する具体的な手段を詳細に説明した。
今後の課題は以下の通りである。
(1) 組織間で交換するポリシーの選択と圧縮の検討
ポリシー内容の検討の過程で、組織間で交換する必要があるポリシーのボリュームが問題になることが判ってきた。現状の仕様では、相当量のポリシーが組織間を流れ、組織間の帯域を圧迫する恐れがある。今後はポリシーの選別、およびポリシーの圧縮方式に関しても検討を行なう予定である。
なお本論文の内容は，情報処理振興事業協会平成10年度事業「次世代デジタル応用基盤技術開発事業」による請負研究として実施中の「QoS保証対応アクティブネットワーク技術」に関するものである。ここに本開発プロジェクトの関係者一同に謝意を表する。
[INTD] T.Ebata, M.Takihiro, S.Miyake, M.Koizumi, F.Hartanto, G.Carle," Inter-Domain QoS Provisioning and Accounting", Internet-Draft, draft-ebata-inter-domain-qos-acct-00.
[QOS]S. Gai, J. Strassner, D. Durham, S. Herzog, H. Mahon,F. Reichmeyer, "QoS Policy Framework Architecture",Internet-Draft, draft-sgai-policy-framework-00.txt, February 1999.
[SLA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP Core Schema",Internet-Draft, draft-ietf-policy-core-schema-04.txt, June 1999
[Term]J.Strassner,E.Ellesson,"Terminology for describing network policy and services",Internet draft,draft-strassner-policy-terms-01.txt, February 1999
[RFC1364] K. Varadhan, "BGP OSPF Interaction", RFC1364, September 1992
[BGP4]Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", Internet-Draft, draft-ietf-idr-bgp4-09.txt, September 1999.
[COPS]J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A.Sastry,"The COPS (Common Open Policy Service) Protocol"Internet-Draft, draft-ietf-rap-cops-06.txt, February 1999.