インターネットドラフト 江端智一 有効期限　2000年4月 滝広眞利 ファイル　draft-ebata-inter-domain-qos-acct-00.txt 三宅滋 小泉稔 日立製作所 F.Hartanto G.Carle GMD FOKUS 組織間QoS提供・課金方式 要約 最近、IETFでは、QoS保証サービス提供の管理・制御を行なう為の一手段とし て、ポリシーを適用する試みが始められている。それぞれの組織は、ポリシー を定義し、ポリシーに応じたサービスを実施することができる。組織ごとに ポリシーが異なってくるのは当然である。 　本文章は、組織間のQoS提供と課金をサポートするために必要となるポリシー の設定に着目し、複数の組織間でポリシーを交換する方式について説明する。 ポリシー交換を実施するにあたって、本文章では、２つのプロトコル「ポリシー 配布プロトコル(Policy Advertisement Protocol (PAP))」と「ポリシー交渉・ 通知プロトコル(Policy Negotiation and Notification Protocol (PNP))」に ついて説明する。PAPは、他の組織に自分の組織が提供しているサービスにつ いて配布を行ない、PNPは、他組織にQoS保証サービスを要求する場合と、その サービスに対する課金の情報を通知する場合に使用される。 　これによって、組織間でQoS保証型のサービスの提供と、その提供されたQoS を基にした課金を動的に実施する事が可能となる。 目次 1.定義と用語 1.1. 定義 1.2. 用語 2.イントロダクション 2.1. 背景 2.2. 目的 2.3. ターゲット 2.4. 前提とするユーティリティ 2.5. 本文章の概要 3. 組織間ポリシー交換 3.1. ポリシーフレームワーク 3.2. QoS提供フレームワーク 3.3. 課金フレームワーク 3.4. 必須交換ポリシー 3.5. 交換するポリシーの性質 3.5.1. 配布 3.5.2. 要求・応答 3.5.3. 通知 4. 組織間ポリシー交換アーキテクチャ 4.1. 提案アーキテクチャ 4.2. 課題 4.3. ポリシー交換プロトコル 4.3.1. ２つのプロトコル 4.4. 前提条件 4.4.1. システム構成 4.4.2. 事前に取得しておく情報 5. ポリシー配布プロトコル 5.1. 概要 5.2. プロトコル 5.3. メッセージフォーマット 5.4. 内容 5.4.1. カスタマポリシー 5.4.2. サービスポリシー 5.4.3. フローポリシー 5.4.4. ビリングポリシー 5.4.5. チャージングポリシー 5.4.6. アカウンティングポリシー 6. ポリシー交渉・通知プロトコル 6.1. 概要 6.2. プロトコル 6.3. メッセージフォーマット 6.4. 内容 6.4.1. Client-Open(OPN)メッセージ 6.4.2. Client-Accept(CAT)メッセージ 6.4.3. Client-Open(OPN)メッセージ 6.4.4. Decision(DEC)メッセージ 6.4.5. Report State(RPT)メッセージ 7. 安全性問題 8. 参考文献 9. 著者住所 1.定義と用語 1.1. 定義 +---------------+--------------------------------------------------+ |ポリシー |A set of rules that prescribes the actions or | | |further policies that need to be taken or used | | |for given events or conditions. | +---------------+--------------------------------------------------+ |組織　 |同一の管理制御下にあるネットワークの範囲　　　　　| +---------------+--------------------------------------------------+ |ポリシーサーバ |あるポリシーに従って組織内部の制御対象を管理する　| | |サーバ | +---------------+--------------------------------------------------+ |サービス |Description of the overall treatment of (a subset | | |of) a customer's traffic across a particular | | |domain, across a set of interconnected domains, | | |or end-to-end. | +---------------+--------------------------------------------------+ |管理者 |組織およびポリシーサーバを管理する人間 | +---------------+--------------------------------------------------+ 1.2. 用語 +---------------+--------------------------------------------------+ |AS |Autonomous System, [RFC1364]を見よ | +---------------+--------------------------------------------------+ |QoS |Quality of Service, [QOS]を見よ | +---------------+--------------------------------------------------+ |COPS |Common Open Policy Service. [COPS]を見よ. | +---------------+--------------------------------------------------+ |PDP |Policy Decision Point, [COPS]を見よ. | +---------------+--------------------------------------------------+ |PEP |Policy Enforcement Point, [COPS]を見よ. | +---------------+--------------------------------------------------+ |BGP4 |Border Gateway Protocol Version4, [RFC1364]を見よ.| +---------------+--------------------------------------------------+ |BR |Border Router, [RFC1364]を見よ. | +---------------+--------------------------------------------------+ |PS |Policy Server, [QOS]を見よ. | +---------------+--------------------------------------------------+ |SLA |Service Level Agreement, [SLA]を見よ. | +---------------+--------------------------------------------------+ |PBNM |Policy Based Network Management | +---------------+--------------------------------------------------+ 　用語に関しては、[Term]を参照の事。ポリシー製造、管理者、管理、配布等 の用語を紹介している。 2.イントロダクション 2.1. 背景 　最近、IETFでは、ネットワークの管理や制御、およびサービス提供の手段と して、ポリシーを適用する試みが始められている。IETFのポリシーワーキング グループは、ポリシーコアスキーマとQoSスキーマによるポリシーアーキテク チャの検討を続けている。これらの方式を基本としたネットワーク管理は、 「ポリシーベースネットワーク管理」(Policy Based Network　 Management(PBNM))と呼ばれる。 　サービスレベル契約(Service Level Agreements (SLAs))は、顧客が受ける べきサービスを明確化するものであり、顧客への請求や課金を含み、顧客が利 用したサービスに対して支払わなければならない内容を特定するものである。 これによって、SLAは、QoSの提供や課金を特定する契約書として扱われる事が できる。 　一方、組織間でQoS保証サービスを行なう事が益々重要となりつつあり、そ れに伴ない、例えば異なるISP、企業ネットワーク、キャリアなどのような、 異なる組織にまで言及する必要が生じつつある。 　それぞれの組織は、その組織固有のポリシーで管理されているので、ある一 つの組織のポリシーが、他の組織のポリシーと異なるのは当然である。従って、 既存のPBNMの枠組みで、シームレスに組織間のQoS保証サービスや組織間課金 を提供するのは困難である。 2.2. 目的 　本文章の目的は、組織間でのポリシー交換やシグナリング制御を伴なう、組 織間QoS提供機能と課金機能をベースとした、組織間QoS保証サービスの手段を 示す事である。 　上記の処理を実現する為に、本文章では、２つのプロトコル「ポリシー配布 プロトコル(Policy Advertisement Protocol (PAP))」と「ポリシー交渉・通 知プロトコル(Policy Negotiation and Notification Protocol (PNP))」に ついて説明する。 　なお本文章においては、ポリシーの設定とポリシー交換のみについて扱い、 ポリシーを利用する処理については言及しないこととする。例えば、アカウン ティングに関するポリシーに関して言えば、アカンティングポリシーが管理す るアカウンティング機能については言及するが、アカウンティング機能それ自 体がおこなう処理に関しては言及しない。 2.3. ターゲット 　本文章で扱うプロトコルは、IP電話やビデオ会議などのQoS保証型のサービ スの提供を目的としている。アプリケーションが提供するサービスを良い状態 に保持する為には、ISPなどのネットワークサービスプロバイダによって提供 されるべき、次の２つの基本サービスがあると考える。 (1)QoS提供サービス (2)課金サービス　 　上記の２つの基本サービスは、ネットワークを監視・管理・制御する事が必 要である。 　図2-1は、課金を伴なうQoS保証サービスのブロックを示す図である。 +-------------------------+ | +---------------------------+ | | 一般 +-----------------------------+ |--+ | サービス | 　 QoS 保証サービス　　 |--+ | +---------|---------^---------+ +-----------------|--+ +--|-----------------+ | |QoS 提供サービス | | | | 課金サービス | | | 　　　　 | | | | 　　　　 | | 基本 +-----------------|--+ +--|-----------------+ | サービス + - - - - - - - - v - - - - | - - - - - - - - + | QoS保証・状態監視可能ネットワーク 　| |ネットワーク + - - - - - - - - - - - - - - - - - - - - - - + 図 2-1 QoS保証サービスブロック図 　QoS提供サービスは、遅延、揺らぎ、パケットロス等の異なるパラメータに よって定義される。複数組織間環境においては、それぞれのドメインは、多く のQoSサービスクラスを提供し、そのサービスクラスは、応答性や関係する保 証に関する事項を含んでいる。一つの例としては、次のテーブルで提供される ようなQoSサービスクラスがある。 +-----------+-----------+------------+-------------+ | クラス　 | 遅延 | 揺らぎ | 　ロス　 | +-----------+-----------+------------+-------------+ | ゴールド | 0.05 s | 0.01 s | 1e-6 - 1e-8 | | シルバー | 0.5 s | 0.2 s | 1e-6 - 1e-8 | | ブロンズ | 1.0 s | 0.5 s | 1e-2 - 1e-3 | +-----------+-----------+------------+-------------+ 　複数組織間環境では、エンドーエンドQoSは、それぞれの組織によって提供 されているQoSに依存している。例えば、３つの組織A,B,及びCの中で、AとBは 最高0.000001%のパケットロスであるのに対し、組織Cでは1%のパケットロスの みを提供する。これが意味するものは、組織Aは、組織Cからのユーザと通信を 行ないたい場合に、ユーザにブロンズクラスのみしか提供できない事を意味す る。これは、組織Aは、組織B,Cによって提供されるQoSと課金のポリシーを知っ ておく必要があることを意味する。これらのポリシーは、ポリシーを配布する 事によって、組織を経由して知らされる事になる。 　課金サービスは、異なるQoSサービスクラスに当てはまる課金の観点から定 義される。複数組織間環境では、チャージングポリシーの交換は、次のような ことを保証する為にも必要となる。それは、ユーザに直接サービスを実施する 組織が、他の組織によって直接課金させることはない。 チャージングポリシーの交換は、直接ユーザーにサービスを実施している組織 が、そのユーザーに適用する料金より高い値段で、他のドメインによって課金 されない事を保証することが要求される。これらのポリシー交換は、組織間で の一時的な契約として扱われ、契約によるトラブルの確認や会費などに役に立 つ事が期待される。 　本文章では。上記２つの基本サービスについて、詳細に説明する。 2.4. 前提とするユーティリティ 　前節で述べたように、組織はQoSと、QoS保証サービスに関する他のポリシー を他のドメインに配布する必要がある。 BGP4 (Boarder Gateway Protocol version4)[BGP4]は、これらの機能をサポートする事が可能である。BGP4は、 単なるルーティングプロトコルでなく、BGP4メッセージに他の情報を付与して 運ぶ事ができる。本文章では、BGP4をポリシー配布の仕組みとして扱う。 　組織間QoS提供と組織間課金を制御する為に、シグナリング機能によて必要 なポリシーを運ぶ必要がある。これらの機能をサポートする為に、COPS (Common Open Policy Service)[COPS] が有効である。COPSは、現在IETFで標 準化が行われており、ポリシーを、例えばポリシーサーバの様な、ポリシー決 定ポイント(policy decision point)と、ルータのような、ポリシー実施ポイ ント(policy enforcement point)で、ポリシーを交換するものである。 　本文章では、ポリシーサーバ間でポリシーを交換する為の拡張COPSを提案す る。 2.5. 本文章の概要 　第３章では、異なる１０種類のポリシーについて紹介する。この１０つのポ リシーの中で、６つのポリシーが、組織間QoS提供制御と組織間課金制御に関 わるものとして扱われ、ポリシー交換を実施する。さらに、これらのポリシー の交換手段について説明する。 　第４章では、ポリシー交換のアーキテクチャについて検討し、２つのアーキ テクチャを提案する。タイプ(1)は、いわば「スーパーポリシーサーバ」と呼 ぶものを使う方式で、タイプ(2)は使わない方式である。これらの２つを比較 する。さらに、これらのポリシー交換を可能とする２つのプロトコルを紹介す る。 　第５章と第６章では、前記の２つのプロトコルのフォーマットと詳細につい て説明する。 3. 組織間ポリシー交換 　本章では、組織間QoS提供と組織間課金のポリシーフレームワークについて 説明する。このフレームワークは、組織間QoS提供と組織間課金の２つで、分 けて扱い、これらの相互のポリシーの関係について説明する。 　組織間QoS提供と組織間課金を行なうにあたり、何故ポリシー交換が必要と なるか、さらに、異なる組織間で、異なる種類のポリシーや、それらのポリシー を交換する手段についても説明する。 3.1. ポリシーフレームワーク 　本文章では。ポリシーは次の様に定義される。 　「ポリシーとは、ルールの集合体である。それは、与えられたイベントやコ ンディションに対して使用されるアクションやポリシーを規定するものである」 　この概念を、図3-1に示す。 　この概念では、厳密に機能を管理するルールは、単一のポリシーとしてグルー プ化される。例えば、顧客要求に含まれる特定のパラメータのように、与えら れたコンディションを基として、ポリシーのルールが評価される。そのレスポ ンスは、アクションの形で表現され、そのアクションは、他のポリシーの評価 のきっかけや、特定の処理やデバイスの制御を行なう事になる。 ポリシー +-----------------+ (コンディション) | | (アクション) 要求　　　　-------->| ルール |--------> 要求 あるいは応答 | | あるいは応答 +-----------------+ 図3-1 ポリシーの概念 　ポリシーフレームワークを、図3-2に示す。 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Q0S保証型サービス | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 顧客 | サービス | リソース v 要求 　 v 要求 v 要求 +-----------------+ +----------------+ +------------------+ |　 顧客特有　　 | | サービス特有 | |　リソース特有　　| | ポリシー | | ポリシー | | 　ポリシー | | |<---->| |<--->| | |-顧客ポリシー　　| |-サービスポリシー| |-フローポリシー | |-請求ポリシー　　| |-料金ポリシー　 | |-Accounting Policy| +-----------------+ +-----------------+ +------------------+ ^ ^ ^ | | | +------------------+ | +-----------------+ | | | v v v +---------------------+ | Network Function | | specific Policy | | | | -Policing & Routing | | Policy | | -Collecting Policy | +---------------------+ ^ | v +---------------------+ | Network Element | | specific Policy | Ebata et al Expires April 2000 [Page 7] Internet Draft October 1999 | | | -Classifying & | | Queuing Policy | | -Metering Policy | +---------------------+ Figure 3-1 Policy framework The top three policy groups of the policy framework represent policies that are to be exchanged with other domains. The inter-domain exchange of these policies are the focus of this document. Details will be explained in Section 3.5. The bottom two policy groups represent policy groups that are used for controlling the network elements (processes or devices) for providing intra-domain QoS guaranteed service and accounting. The customer specific policy controls the customer access to the services available within a provider domain. The policy uses attributes of a customer (e.g. priorities, usable services, valid time, usable resources) and rules composed of the attributes (for example, "If Mr. A has gold priority, then he can use all services from gold to bronze with maximum network bandwidth."). There are two kinds of customer specific policy, "Customer Policy" and "Billing Policy". The service specific policy controls how a service should be provided to a customer. The policy uses the attribute of service (e.g. expected QoS, valid time, cost) and the rules composed of the attributes (for example, "If service A is available, then its cost is one dollar a minute."). There are two kinds of policy, "Service Policy" and "Charging Policy". The resource specific policy controls how actual network resources are utilized as part of a service provision. The policy uses attributes of resources (e.g. network medium, bandwidth, delay, jitter, MTU), status information (kinds of service, path and time), and rules composed of the attributes (for example, "If there is not enough bandwidth for Mr. A's service, reduce other bandwidth of service for other customers"). There are two kinds of resource specific policy, "Flow Policy" and "Accounting Policy". The network function specific policy defines the functions that should be provided to support a service for a specific customer. The policy uses above request attributes of above policies. Its response attributes and rules are composed of the attributes (for example, "If the bandwidth rate of route A is above 90%, use route B"). There are two kinds of network function specific policy, "Policing & Routing Policy" and "Collecting Policy". The network elements policy defines the configuration of network elements for providing a network function associated with a service. The policy uses the communication attributes of a device (e.g. setting parameters and its values) and rules composed of the attributes (for Ebata et al Expires April 2000 [Page 8] Internet Draft October 1999 example, "If bandwidth is assigned, then set bandwidth parameter enable and mark packets as green"). The policy uses packet attributes of a flow (e.g. real time measurement values of bandwidth, delay) and rules composed of the attributes (for example, "If "user" is assigned, relate flow with IP address"). There are two kinds of network elements policy, "Classifying & Queuing Policy" and "Metering Policy". 3.2. QoS provisioning framework Figure 3-3 shows the QoS provisioning framework. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | QoS guaranteed services | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Customer | Service | Resource v request v request v request +----------------+ +----------------+ +------------------+ | | | | | | |Customer Policy |----->| Service Policy |----->| Flow Policy | | | | | | | +----------------+ +----------------+ +------------------+ | | | +------------------+ | +-----------------+ | | | v v v Network Function Request +---------------------+ | | | Policing & Routing | | Policy | +---------------------+ | v Network Element Configuration +---------------------+ | | | Classifying & | | Queuing Policy | +---------------------+ Figure 3-3 QoS provisioning framework The QoS provisioning process starts with the requests from QoS guaranteed services. The requests activate policies, and its policies trigger the execution of further policies. For example, when a QoS guaranteed service put out some requests, customer policy check the attributes of a customer and rules, and output the service request to service policy. After checking service attributes and rules, service policy output the resource requests to flow policy. With the same process, flow policy output the network function requests and network function policy dictates the queuing policy to be used for configuring the communication devices. Ebata et al Expires April 2000 [Page 9] Internet Draft October 1999 Customer policy in the QoS provisioning framework has the attribute of customer (e.g. host IP, priority, available service name, right of the inter-domain service use) and its rule composed of the attributes (for example, "if a customer has no right of inter-domain service, the process is halted"). After this policy accept the requests from QoS guaranteed services, the policy output service request and/or network function request. Service policy in the QoS provisioning framework has the attribute of service (e.g. nature of service, protocol, expected QoS, valid time, cost) and its rule composed of the attributes(for example, "if service is not available at present, the process is halted"). After this policy accept the request from QoS guaranteed services and/or customer policy, the policy output resource requests and/or network function requests. Flow policy in the QoS provisioning framework has the attribute of flow (e.g. network medium, bandwidth, delay, jitter, MTU) and its rule composed of the attributes (for example, "If there is not enough bandwidth for Mr. A's service, reduce other bandwidth of service for other customers"). After this policy accept the requests from QoS guaranteed services and/or service policy, the policy output network function requests. Policing & Routing policy in the QoS provisioning framework has the attribute of policing and routing and its rules composed of the attributes (for example, "If the bandwidth rate of route A is above 90%, use route B"). After this policy accept the requests from customer policy and/or service policy and/or flow policy, the policy output network element configurations. Classifying & Queueing policy in the QoS provisioning framework has the attributes of packet classification and queueing (e.g. setting parameters and its values) and its rules composed of the attributes (for example, "If "bandwidth" is assigned, set bandwidth parameter enable"). After this policy accept the requests from policing & routing policy, the policy sets parameters and enforce to execute the communication devices. 3.3. Accounting framework Accounting framework shows how the policy framework account for QoS guaranteed services in the figure 3-4. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | QoS guaranteed services | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ^ Billing ^ Charging ^ Accounting | response | response | response +----------------+ +----------------+ +------------------+ Ebata et al Expires April 2000 [Page 10] Internet Draft October 1999 | | | | | | | Billing Policy |<-----|Charging Policy |<-----|Accounting Policy | | | | | | | +----------------+ +----------------+ +------------------+ ^ ^ ^ | | | +------------------+ | +-------------------+ | | | Collecting response +---------------------+ | | | Collecting Policy | | | +---------------------+ ^ | Metering response +---------------------+ | | | Metering Policy | | | +---------------------+ Figure 3-4 Accounting framework Accounting process starts with Metering response from Metering policy. The response activates policies, and its policies put out the response to another policy. For example, communication devices keep observing network traffic. Metering policy check the traffic attributes and output the metering response to collecting policy. After checking metering response, collecting policy output the collecting response to accounting policy and/or charging policy and/or billing policy. With the same processes, accounting policy output the accounting response and charging policy output charging response. Finally, billing policy output billing response toward QoS guaranteed services. Metering policy in the accounting framework has the attribute of metering (e.g. in case of an IP packet, the eight header fields used for classification are source and destination address, source and destination port number, type-of-service field, protocol field and transport layer protocol flags) and its rule composed of the attributes (for example, "if source address ="192.168.1.10" and destination address="192.168.23.3" then observe the packet arrival time"). After this policy keep observing the network flows in that point at the regular interval, metering policy execute the above process and output metering responses. Collecting policy in the accounting framework has the attribute of collecting (e.g. measurement point, time, and other summary of the observed metering packet (count, total length of every kinds of packet )) and its rule composed of the attributes (for example, "if the same Ebata et al Expires April 2000 [Page 11] Internet Draft October 1999 packet is observed at the point A and point B, calculate the differential time between two points"). After this policy accept the response from the multiple metering point, collecting policy execute the above process and output collecting responses. Accounting policy in the accounting framework has the attribute of accounting (e.g. collecting policy ID) and its rule composed of the attributes (for example, "if time is between 10:00 and 12:00, adopt collecting policy ID #23,#27) After this policy accept the response from collecting policy, accounting policy execute the above process and output accounting responses. Charging policy in the accounting framework has the attribute of charging (e.g. pricing formula, charging formula, accounting policy ID) and its rule composed of the attribute (for example, "if time is between 10:00 and 12:00, adopt pricing formula No.3") After this policy accept the response from collecting policy and/or accounting policy, charging policy execute the above process and output charging responses. Billing policy in the accounting framework has the attribute of billing (e.g. host IP, priority, available service name, right of the inter-domain service use) and its rule composed of the attribute (for example, "if customer's priority is gold class and his/her total packet count is over 100 million a month, his/her cost is rank S") After this policy accept the response from collecting policy and/or charging policy, billing policy execute the above process and output charging responses. 3.4. Mandatory exchange policy In order to execute inter-domain QoS provisioning and accounting, the policy exchange is needed. Reasons are as follows. (1) In order provide inter-domain QoS, it is necessary for one domain to know (a) which service exist in another domain, (b) which customer that use the service exist in another domain,(c) how much resources to execute the service remain in another domain. (2) In order to provide Inter-domain accounting services, it is necessary to have information on the above(a)(b) and (c), and possibly additional information such as charging tables for services and resources. Thus, if each domain does not know the policy of other domains involved in end-to-end service provisioning, it is impossible to provide interdomain QoS and accounting. Polices and its contents, which are supposed to be exchanged inter-domain, are shown as follows. Ebata et al Expires April 2000 [Page 12] Internet Draft October 1999 (1)QoS provisioning framework (a) Customer policy Some parts of this policy explained in 3.2. are exchanged inter-domain, for example, a customer's priority, available services, and its valid time. (b)Service policy Some parts of this policy explained in 3.2. are exchanged inter-domain, for example, service name(or ID)and its valid time. (c)Flow policy Some parts of this policy explained in 3.2. are exchanged inter-domain for example, path, available bandwidth, packet loss, minimum delay time, jitter, and MTU. (2)Accounting framework (a)Billing policy Some parts of this policy explained in 3.3. are exchanged inter-domain in order to notify required customer type and customer credit to request for a given service. (b)Charging policy Some parts of this policy explained in 3.3. are exchanged inter-domain in order to notify charging tables which are described service, resources, time and its cost for a domain. (c)Accounting policy Some parts of this policy explained in 3.3. are exchanged inter-domain in order to notify accounting information about resources used and its cost for each customers. 3.5. Nature of exchange policy As explained earlier, the nature of policy exchange within the QoS provisioning and accounting framework can be separated into three steps, namely: (1) a domain advertises the policies it supports to other domains. (2) a domain requests a service from another domain. (3) the requested domain notifies the requesting domain with regard to the policies governing the charges for the services. The advertised policies in step (1) will rather be generic in nature to allow another domain to make a request, while the notified policies in step (3) are more specific. For example, the advertised charging policy may say that charges are Volume*Price(QoS1). A specific policy may dictate that charging will be calculated based on max(Volume*Price(QoS2)-Credit,0), where Credit is given because higher QoS request is not met. Based on this policy, the requesting domain can calculate the charges and pass the charges to its users. For these three types of policy exchanges, the following three means of Ebata et al Expires April 2000 [Page 13] Internet Draft October 1999 policy exchange are introduced. 3.5.1. Advertisement This mechanism used for policies that each domain must obtain for the purpose of inter-domain QoS provisioning and accounting. Policies may be delivered by broadcast as indicated in figure 3-5. A domain which advertises policies is called "Source Domain". A domain which receives policies is called "Destination Domain" +-----+ +-----+ / Dest. \ / Dest. \ | Domain |<-+ +->| Domain | \ / \ / \ / +-----+ \ / +-----+ +-----+ +-----+ / Src. \ / Dest. \ | Domain |--->| & Src. | \ / \Domain / +-----+ +-----+ \ +-----+ \ / Dest. \ +->| Domain | Src. : Source \ / Dest.: Destination +-----+ Figure 3-5 Advertisement of policy The types of policy using this mechanism are as follows. (1)QoS provisioning framework (a)Customer policy (b)Service policy (c)Flow policy (2)Accounting framework (a)Billing policy (b)Charging policy (c)Accounting policy These policies are "advertised policy". 3.5.2. Request and response This mechanism is used as a trigger to start inter-domain QoS provisioning. One policy is carried as requests to start QoS provisioning, and another policy is carried as responses for its reply. These policies may be exchanged by request and response communication as shown in figure 3-6. A domain which sends requests is called "Source Domain" and a Domain which sends responses is called "Destination Domain". Ebata et al Expires April 2000 [Page 14] Internet Draft October 1999 +-----+ +-----+ / Src. \ -----> / Dest. \ | Domain | | Domain | \ / <----- \ / +-----+ +-----+ Figure 3-6 Request and response of policy The types of policy using this mechanism are: (1)QoS provisioning framework (a)Customer policy (b)Service policy (c)Flow policy These policies are "signaling policies". The three policy types represent the three granularities of a service request. The customer policy controls the user accesses to the service provider domain. Within this access, the user can set up multiple services, with each service being governed by the service policy. Each service can request for multiple flows which are governed by flow policy. 3.5.3. Notification This mechanism is used as accounting state reports to notify the result of inter-domain QoS guaranteed service. This policy may be notified by unicast in figure 3-7. A domain which sends notifications is called "Source Domain". A domain which receives it is called "Destination Domain". +-----+ +-----+ / Dest. \ / Src. \ | Domain |<-----| Domain | \ / \ / +-----+ +-----+ Figure 3-7 Notification of policy The types of policy using this mechanism are as follows. (1)Accounting framework (a)Billing policy (b)Charging policy (c)Accounting policy These types of policy are "notified policies". Associated with the three granularities of service request, the service provider can provide the user with the information on the charges at three different levels, with each level being governed by different policy. For example, billing policy may be used to reject customer request because the customer is running out credit. Charging policy may be used Ebata et al Expires April 2000 [Page 15] Internet Draft October 1999 to inform the customer of the current service cost in response to a service request. Accounting policy may be used to inform the customers of the current metered number of packets for a given flow.