Internet Draft T.Ebata
Expiration Date: April 2000 M.Takihiro
File: draft-ebata-inter-domain-qos-acct-00.txt S.Miyake
M.Koizumi
Hitachi, Ltd.
F.Hartanto
G.Carle
GMD FOKUS
Inter-Domain QoS Provisioning and Accounting
<draft-ebata-inter-domain-qos-acct-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to produce
derivative works is not granted.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
Recently, IETF has started to examine policy as a tool for managing
and controlling the provision of QoS guaranteed services. In a
multi-domain environment, each domain will define its own policies and
manage the services according to its own policies. So it is natural
that the policy in one domain is different from the policy in another
domain.
Therefore, this document focuses on the policy setup required for
supporting inter-domain QoS provisioning and accounting and describes
the policy exchange required between the domains. For supporting the
policy exchanges, this document describes two protocols, namely "Policy
Advertisement Protocol (PAP)" and "Policy Negotiation and Notification
Protocol (PNP)". PAP is used by a domain to advertise its service
policies to other domains. PNP is used by a domain to request another
domain to provide a QoS guaranteed service and for the requested domain
to notify the requesting domain of the policies governing the charges
for the services. This allows dynamic negotiation for the service
charges based on the offered QoS.
Ebata et al Expires April 2000 [Page 1]
Internet Draft October 1999
Table of Contents
1.Definition and Terminology ........................................3
1.1. Definition .....................................................3
1.2. Terminology ....................................................3
2.Introduction ......................................................4
2.1. Background......................................................4
2.2. Purpose and Scope ..............................................4
2.3. Target .........................................................4
2.4. Utilities ......................................................6
2.5. Outline of this document .......................................6
3. Inter-domain policy exchange .....................................6
3.1. Policy framework ...............................................6
3.2. QoS provisioning framework .....................................9
3.3. Accounting framework ..........................................10
3.4. Mandatory exchange policy .....................................12
3.5. Nature of exchange policy .....................................13
3.5.1. Advertisement ...............................................14
3.5.2. Request and response ........................................14
3.5.3. Notification ................................................15
4. Inter-domain policy exchange architecture .......................16
4.1. Proposed architecture .........................................16
4.2. Subjects ......................................................17
4.3. Communication protocols for policy exchange ...................17
4.3.1. Two protocols ...............................................17
4.4. Premise condition .............................................18
4.4.1. System structure ............................................18
4.4.2. Acquisition information before operation ....................19
5. Policy advertisement protocol ...................................19
5.1. Outline .......................................................19
5.2. Protocol ......................................................21
5.3. Message format ................................................21
5.4. Contents ......................................................24
5.4.1. Customer policy .............................................24
5.4.2. Service policy ..............................................26
5.4.3. Flow policy .................................................26
5.4.4. Billing policy ..............................................27
5.4.5. Charging policy .............................................27
5.4.6. Accounting policy ...........................................28
6. Policy negotiation and notification protocol ....................28
6.1. Outline .......................................................29
6.2. Protocol ......................................................30
6.3. Message format ................................................30
6.4. Contents ......................................................30
6.4.1. Client-Open(OPN) message ...................................30
6.4.2. Client-Accept(CAT) message .................................31
6.4.3. Client-Open(OPN) message ...................................32
6.4.4. Decision(DEC) message ......................................33
6.4.5. Report State(RPT) message ..................................34
7. Security Considerations .........................................36
8. References ......................................................36
9. Author's addresses ..............................................36
Ebata et al Expires April 2000 [Page 2]
Internet Draft October 1999
1.Definition and Terminology
1.1. Definition
+---------------+--------------------------------------------------+
|Policy |A set of rules that prescribes the actions or |
| |further policies that need to be taken or used |
| |for given events or conditions. |
+---------------+--------------------------------------------------+
|Domain |Range of a network under the same administrative |
| |control. |
+---------------+--------------------------------------------------+
|Policy server |Server that controls objects inside a domain in |
| |accordance with a certain policy |
+---------------+--------------------------------------------------+
|Service |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. |
+---------------+--------------------------------------------------+
|Administrator |Person who controls a domain / operates a policy |
| |server. |
+---------------+--------------------------------------------------+
1.2. Terminology
+---------------+--------------------------------------------------+
|AS |Autonomous System, see [RFC1364]. |
+---------------+--------------------------------------------------+
|QoS |Quality of Service, see [QOS]. |
+---------------+--------------------------------------------------+
|COPS |Common Open Policy Service. See[COPS]. |
+---------------+--------------------------------------------------+
|PDP |Policy Decision Point, see [COPS]. |
+---------------+--------------------------------------------------+
|PEP |Policy Enforcement Point, see [COPS]. |
+---------------+--------------------------------------------------+
|BGP4 |Border Gateway Protocol Version4, see [RFC1364]. |
+---------------+--------------------------------------------------+
|BR |Border Router, see [RFC1364]. |
+---------------+--------------------------------------------------+
|PS |Policy Server, see [QOS]. |
+---------------+--------------------------------------------------+
|SLA |Service Level Agreement, see [SLA]. |
+---------------+--------------------------------------------------+
|PBNM |Policy Based Network Management |
+---------------+--------------------------------------------------+
For terminology see also [Term] that introduces a set of terms for
policy creation, administration, management and distribution.
Ebata et al Expires April 2000 [Page 3]
Internet Draft October 1999
2.Introduction
2.1. Background
Recently, IETF started to examine policy as a means how to manage and
control network devices and how to provide services.
The Policy working group in IETF continues to work on the policy
architectures with its core and QoS schema. Network management
based on these principles is called "Policy Based Network Management
(PBNM)".
Service Level Agreements (SLAs) have been introduced to specify the
service a customer's traffic should receive. An SLA may contain rules
for usage-based charging and accounting, specifying what a customer
must pay for using the service. This allows to use an SLA as a single
contract for specifying QoS provisioning and accounting.
On the other hand, inter-domain QoS guaranteed services become
important, leading to the need of contracts that refer to different
domains, e.g. different ISPs networks, enterprise networks, and carrier
networks.
As each domain is managed in accordance with a specific policy, it is
natural that the policy in one domain is different from the policy in
another domain. Therefore, it is impossible to seamlessly provide
inter-domain services and accounting within the current PBNM framework.
2.2. Purpose and Scope
This document describes how to provide inter-domain QoS guaranteed
services based on inter-domain QoS provisioning and accounting
with policy exchange and signaling control between domains. In order to
realize the above processes, this document describes two protocols
"Policy Advertisement Protocol" and "Policy Negotiation and
Notification Protocol".
In this document we only deal with policy setup and policy exchange,
and not with the processes that use the policies. For example, we deal
with accounting policies, which manage the accounting functionality,
and not with the process that performs the accounting functionality
itself.
2.3. Target
The protocols detailed in this document are targeted to provide QoS
guaranteed services, such as IP telephony services or video conference
services. In order to achieve good application-level performance, two
elemental services should be provided by network service providers:
(1) a QoS provisioning service, and (2) an accounting service. These
two elemental services require to observe, manage and control the
network.
Figure 2-1 shows the building blocks of QoS guaranteed services with
Ebata et al Expires April 2000 [Page 4]
Internet Draft October 1999
accounting.
+-------------------------+ |
+---------------------------+ | | General
+-----------------------------+ |--+ | services
| QoS guaranteed service |--+ |
+---------|---------^---------+
+-----------------|--+ +--|-----------------+ |
|QoS provisioning | | | | Accounting | |
| service | | | | service | | Elemental
+-----------------|--+ +--|-----------------+ | services
+ - - - - - - - - v - - - - | - - - - - - - - +
| QoS guaranteed and flow observable network | | Infrastructure
+ - - - - - - - - - - - - - - - - - - - - - - +
Figure 2-1 Building blocks of QoS guaranteed services
The QoS provisioning service is defined in terms of different
parameters, such as delay, delay jitter, and loss.
In a multi-domain environment, each domain may offer a number of QoS
service classes, which contain a set of ranges of performance values
and related guarantees. An example of QoS service classes is given in
the following table.
+-----------+-----------+------------+-------------+
| Classes | Delay | Jitter | Loss |
+-----------+-----------+------------+-------------+
| Gold | 0.05 s | 0.01 s | 1e-6 - 1e-8 |
| Silver | 0.5 s | 0.2 s | 1e-6 - 1e-8 |
| Bronze | 1.0 s | 0.5 s | 1e-2 - 1e-3 |
+-----------+-----------+------------+-------------+
In a multi-domain environment, the end-to-end QoS depends on the QoS
provided by each domain. For example, in three domains A, B, and C,
domain A and B provide loss up to 1e-8, while C only provides loss up
to 1e-2. This means that domain A can only provide Bronze class to its
users who want to communicate with a user from domain C. Domain A
informs the users on its policies in charging for the service. This
implies that domain A needs to know the QoS and accounting policies
supported by domain B and C. These policies can be made known through
the domains by advertising their policies.
The accounting service may be defined in terms of charges applicable
for different QoS service classes. In a multi-domain environment,
exchanges of charging policies are required to ensure that the domain
directly serving the users is not charged by other domains higher than
the charges it applies to its users. These policy exchanges can be
treated as a temporary contract between the domains and can be helpful
in identifying and resolving conflicts.
In this document, the above two elemental services are explained in
detail.
Ebata et al Expires April 2000 [Page 5]
Internet Draft October 1999
2.4. Utilities
As mentioned in the previous section, a domain needs to advertise QoS
as well as other policies associated with a QoS guaranteed service
provision to other domains. BGP4 (Boarder Gateway Protocol
version4)[BGP4] is able to support this functionality. BGP4 is not only
a routing protocol but also is able to carry additional information in
a BGP4 message. In this document, BGP4 is utilized as the policy
advertisement mechanism.
In order to control inter-domain QoS provisioning and accounting,
signaling functions are needed to carry necessary policies. To support
this functionality, COPS (Common Open Policy Service)[COPS] is
available. COPS is currently being standardized by IETF. It exchanges
policies between a policy decision point (e.g. policy server]) and the
policy enforcement point (e.g. router). In this document, enhancements
for COPS are proposed in order exchange policies between policy
servers.
2.5. Outline of this document
In chapter 3, a Policy Framework is introduced that distinguishes 10
different kinds of policy. Of these, 6 are identified as relevant for
inter-domain QoS provisioning and accounting control, and are therefore
subject to policy exchange. Finally, it is explained how to exchange
these policies.
In chapter 4, architectures for policy exchange are investigated, and
two architecture types are proposed. The architecture type(1) with a
so-called super policy server, and the architecture type(2) without a
super policy server are compared. Two protocols are introduced that
allow to perform policy exchange.
In chapters 5 and 6, the message formats and and further details of the
two protocols are explained.
3. Inter-domain policy exchange
In this chapter, the policy framework for QoS provisioning and
accounting is explained. The framework is divided into a QoS
provisioning framework and an accounting framework. Mutual relations of
the policies are explained.
It is explained why policy exchange is needed to realize inter-domain
QoS provisioning and accounting.
Furthermore, different kinds of policies and means to exchange them
among different domains are explained.
3.1. Policy framework
In this document, policy is defined as:
"A set of rules which prescribes the actions or further policies that
Ebata et al Expires April 2000 [Page 6]
Internet Draft October 1999
need to be taken or used for given events or conditions".
This concept is shown in figure 3-1.
With this concept, rules which manage a distinct functionality is
grouped as a single policy. Based on a given condition, for example
specific parameters contained in a customer request, the rules of the
policy are evaluated. The response can be in the form of an action
which may trigger the evaluation of other policies or control specific
processes or devices.
Policy
+-----------------+
(Condition) | | (Action)
From Request-------->| Rules |--------> Request
or Response | | or Response
+-----------------+
Figure 3-1 Concept of Policy
The policy framework is shown in the figure 3-1.
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Q0S guaranteed services |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Customer | Service | Resource
v request v request v request
+-----------------+ +----------------+ +------------------+
|Customer specific| |Service specific| |Resource specific |
| Policy | | Policy | | Policy |
| |<---->| |<--->| |
|-Customer Policy | |-Service Policy | |-Flow Policy |
|-Billing Policy | |-Charging Policy| |-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
billing 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.
4. Inter-domain policy exchange architecture
In this chapter, the architectures about Inter-domain policy exchange
is explained.
In this document with one major premise, the architecture has one
policy server(PS), which controls objects (e.g. router) in
intra-domain only in accordance with intra-domain policy.
4.1. Proposed architecture
There seem to be two types of architecture in figure 4-1.
+-----+
+-->| SPS |<--+
| +-----+ |
| |
V V
+----+ +----+ +----+ +----+
| PS | | PS | | PS |<-------->| PS |
+----+ +----+ +----+ +----+
| | | |
+-----+ +-----+ +-----+ +-----+
/ \ / \ / \ / \
/ \ / \ / \ / \
| | | | | | | |
| Domain | | Domain | | Domain | | Domain |
\ / \ / \ / \ /
\ / \ / \ / \ /
+----+ +----+ +----+ +----+
(a)with SPS (b)without SPS
SPS:Super Policy Server
Figure 4-1 Two types of architecture
In the type(a), policies are exchanged through SPS. In this
architecture, direct policy exchange process is unnecessary and the
load of PS becomes low. Because all PSs which execute QoS provisioning
and accounting must make a joint relationship with SPS, it is the case
that scalability and flexibility become sacrificed. And nobody knows
who manage SPS.
On the other side in the type(b),the load of PS becomes high, but
scalability and flexibility problems is less than type(a).PS
administrators manage their intra-domain only. And it is possible to
realize it with the current internet architecture.
Ebata et al Expires April 2000 [Page 16]
Internet Draft October 1999
In this document, type(b) is explained as follows.
4.2. Subjects
The subjects of architecture of type(b) are showed in this clause.
(a)Different exchange means for different natures of policy
In the chapter 3, it became clear that the three communication types
such as "advertisement", "request and response", and "notification"
are needed. So PSs are necessary to be furnished such the communication
means.
(b)Low-load policy exchange process
For the reason of the six kinds of policy are needed to exchange
through inter-domain, the load of PSs is afraid to be high. If the
exchange process are executed at the same time when inter-domain QoS
provisioning or accounting start, the processing power of PS may become
down. So PS should not exchange the policies simultaneously.
4.3. Communication protocols for policy exchange
In order for the purpose of above subject, PSs should realize two
phases policy exchange processes.
(Step.1) Policy advertisement phase
In this phase, "advertisement" is executed in order to advertise
policies through inter-domain.
(Step.2) Policy request-response and notification phase
In this phase, "request and response" and "notification" are
executed. After PSs refer to the above advertised policies, PSs send
and/or receive the policies which contain request and/or response
contents toward another domain. And as the results of the QoS
guaranteed type services, PSs send and/or receive the policies which
contain notification about the services.
4.3.1. Two protocols
In order to realize the policy exchange processes, two protocols,
"policy advertisement protocol" and "policy negotiation and
notification protocol" are proposed as one implementation form.
"Policy advertisement protocol" is to advertise the above 6 kinds of
policy (customer, service, flow, billing, charging and accounting
policy). This protocol is enhanced BGP4 which is able to route network
packets with routing policy.
"Policy negotiation and notification protocol" is to negotiate the
customer, service and flow policy and/or notify the billing, charging
and accounting policy. This protocol is enhanced COPS which is able to
convey some policies and signal to execute some actions corresponded
Ebata et al Expires April 2000 [Page 17]
Internet Draft October 1999
with its policies between PDPs(Policy Decision Points) and PEPs(Policy
Enforcement Points).
4.4. Premise condition
In this clause, it is explained about the premise system structure and
the process before process of starting the system.
4.4.1. System structure
The figure 4-2 shows a sample system structure.
Each PS(PSa, PSb, PSc, PSd) owns policies of each domain. There are
some routers and other devices in each domain. Border routers(BRs)
in the domain are connected with other BRs in another domain.
The PSs manage some devices in the domain and control them (for
example, intra-domain routing) corresponded with the policies. And PSs
exchange the policies through inter-domain and execute QoS
provisioning and accounting.
+-----+ +-----+
| PSa | | PSb |
+-----+ +-----+
| |
+-----+---+ +------+------+
/ \ / \
/ \ / \
/ +---+ +----+ +----+ \
| | R |---| BR |-------------------| BR |\ |
| +---+ /+----+ +----+ \+---+ +---+ |
| | / | | | R |-| R | |
| +---+/ +----+ +----+ /+---+ +---+ |
| | R |---| BR |-------------------| BR |/ |
\ +---+ +----+\ /+----+ /
\ Domain A / \ / \ Domain B /
\----------+ \ +-----+ / +-------------+
AS-ID:64512 \ | PSc | / AS-ID:64514
\ +-----+ /
+----+ | +----+ +-----+
/| BR |----| BR |\ | PSd |
/ +----+ +----+ \ +-----+
| \ / \ \ |
| +---+ \ \ +-------+
| | R | | \ / \
| +---+ | \ +----+ \
\ Domain C / \| BR |\ +---+ |
+-------------+ +----+ \| R | |
AS-ID:64513 \ +---+ |
\ Domain D/
+-------+
AS-ID:64515
Figure 4-2 Sample of premise system structure
Ebata et al Expires April 2000 [Page 18]
Internet Draft October 1999
4.4.2. Acquisition information before processes
PS administrators must get the following information from neighboring
domains connected with physical communication lines, before PSs start
the policy exchange process and inter-domain QoS provisioning and
accounting.
(1)Domain ID(in short AS-ID) and IP address for PS(in short PS-IP)
(2)IP address of BRs(in short BR-IP) of intra-domain side and
inter-domain side
(3)Resource information about the inter-domain physical communication
lines (which is called Inter-domain link, in short I-D link)
(e.g. network medium, maximum bandwidth, range of packet loss, minimum
delay, minimum jitter, MTU)
It is not referred how to get the above information in this document.
Next, PS administrators make the following information and store them
in the PS's storage device. Part of information is treated as policies.
(1)Customers information(for example, host IP, priority, available
service name, right of the inter-domain service use)
(2)AS-IDs that the above customer are allowed for inter-domain
communication.
(3)Inter-domain link ID that the above customer's host can arrive at
the domain of the above AS-ID
(4)Potential resource information from the above I-D link to the above
customer's host
5. Policy advertisement protocol
In this chapter, for the purpose of inter-domain policy
advertisement, it is explained about the policy advertisement
protocol(in short PAP) which is enhanced BGP4 protocol [BGP4].
5.1. Outline
In this clause, the outline of the PAP and the sample policies and the
functions are explained.
An example of domain structure is showed in figure 5-1.
+-----+
| PSa |
+-----+
|
+-----+---+
/ 0 Ha1 \
/ | \
/ +---+ +------+ La1
| | R |---| BRa1 |----------
Ebata et al Expires April 2000 [Page 19]
Internet Draft October 1999
| +---+ /+------+ PS:Policy Server
| | / | H:Host
| +---+/ +------+ La2 R:Router
| | R |---| BRa2 |---------- BR:Border Router
\ +---+ +------+\ L:Inter-Domain Link
\ Domain A / \ La3
\----------+ \
Figure 5-1 Example of domain structure
In this example, the PS in this domain has some policies which should
be advertised toward another PS. For example, there is Host a1(Ha1) in
domain A. And in order to communicate with the Ha1 from another
customer in another AS domain, three I-D links (La1,La2, La3) and two
BRs (BRa1, BRa2) are available. These information are made up
automatically by the PS which always get the network structure and
state. And parts of information are treated as policies in this
domain.
In table 5-1, a simple advertised policies table is showed.
Table 5-1
+-------+-----------------------+-------+-------+
|(a) |(b) |(c) |(d) |
+-------+-----------------------+-------+-------+
|Ha1 |123.456.789.100/24 |La1 |5.3 |
| | |La2 |5.3 |
| | |La3 |3.5 |
+-------+-----------------------+-------+-------+
(a)Customer and/or Host name
(b)Host IP address that is permitted to communicate with another
domain
(c)I-D link ID the customer can use
(d)Bandwidth(Mbit/sec) that is permitted to communicate with another
domain
The outline process of policy advertisement is showed in figure 5-2.
(Source PS) (Destination (Destination PS)
& Source PS )
+-----+ +-----+ +-----+
| PSa | - - - - - - - >| PSc |- - - - - - - >| PSd |
+-----+ +-----+ +-----+
| | |
+----+---+ +---+---+ +---+---+
/ Domain A \ /Domain C \ /Domain D \
| Ha1 +------+ +------+ +------+ +------+ |
| 0-----| BRa2 |---| BRc1 |---| BRc2 |---| BRd1 | |
| +------+ +------+ +------+ +------+ |
\ (10.0M) / (3.5M) \ (2.7M) / (4.0M) \ /
+---------+ +-------+ +-------+
(available bandwidth)
Ebata et al Expires April 2000 [Page 20]
Internet Draft October 1999
Figure 5-2 Example of policy advertisement
This figure shows a sample case that one policy in domain A is being
advertised from PSa (Source PS) to PSc (Destination and source PS) and
PSd (Destination PS).
This policy is advertised with routing information on BGP4. A different
process is that the advertised policies, for example, flow policy
may be transformed by each PS in accordance with the network structure
and/or state.
Firstly, PSa advertises it policies toward PSc. The policies contain
follows information that if a customer in domain C would like to
communicate with Ha1's customer in domain A, the customer can use the
3.5Mbit/sec bandwidth through BRc1 in domain C. Because the available
bandwidth is limited by minimum bandwidth among (3.5M) between BRc1
and BRa2 and (10.0M) between BRa2 and Ha1.
Secondly, PSc forwards its policies toward PSd. The policies contain
follows information that if a customer in domain D would like to
communicate with Ha1's customer in domain A, the customer can use the
2.7Mbit/sec bandwidth through BRd1 in domain D. Because the available
bandwidth is limited by minimum bandwidth among (4.0M) between BRd1
and BRc2 and (2.7M) between BRc2 and BRc1 and the above 3.5M through
inter-domain C and A.
In this case, it is explained about the bandwidth which is included
in flow policy. But there are another attributes in flow policy, which
are transformed or forwarded by each PS as follows.
bandwidth minimum value
packet loss range value
latency total sum value
MTU minimum value
jitter total sum value
Thus, PS is allowed to transform policies in this process, but it is
not referred in this document in detail.
5.2. Protocol
PAP is all based on BGP4 [BGP4], except for the policy transformation
process.
5.3. Message format
Policies (customer, service, flow, billing, charging and accounting
policy) are advertised using UPDATE message of BGP4. BGP4 advertises
not only routing information but also other information in BGP4
message.
The format of BGP4 message is showed in figure 5-3.
Ebata et al Expires April 2000 [Page 21]
Internet Draft October 1999
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Unfeasible routes information =
| |
+-------------------------------+
| Total path attribute length |
+-------------------------------+ |
| | | Path attribute
= Path attribute = | information
| | |
+-------------------------------+
| Network layer reachability |
= information =
| |
+-------------------------------+
Figure 5-3 UPDATE message format
Advertised policy is loaded in "path attribute information"
The format of path attribute message is showed in figure 5-4.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Attribute flag |Attr. type code|
+-------------------------------+
| Attribute length |
+-------------------------------+
| |
// Attribute value //
| | Attr.:Attribute
+-------------------------------+
Figure 5-4 Path attribute message format
Contents about the attribute flag of this path attribute are as
follows.
Table 5-2
+-----+---------------------+--------------+
| bit | name | value |
+-----+---------------------+--------------+
| 0 | Option bit | optional(1) |
| 1 | Transitive bit | Transitive(1)|
| 2 | Partial bit | partial(1) |
| 3 | Extended length bit | two octets(1)|
+-----+---------------------+--------------+
The attribute type code is "21" and this attribute is called
Ebata et al Expires April 2000 [Page 22]
Internet Draft October 1999
"advertised policy attribute". Maximum Attribute length is the value
which expressed by 2 bytes.
Advertised policy attributes are loaded in following format.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
// Common header // |
| | |
+-------------------------------+ | advertise policy #1
| | |
// Advertised policy // |
| | |
+-------------------------------+
| | |
// Common header // |
| | |
+-------------------------------+ | advertise policy #2
| | |
// Advertised policy // |
| | |
+-------------------------------+
Figure 5-5 Advertised policy attribute message format
The above advertised policies are added through each PS. Each PS
recompose the original policies.
In the above common header, BR address and total message length
included this header are described.
IP-Type = 1, IPv4 Address
0 1 2 3
+--------------+--------------+--------------+--------------+
| IP Version | //////// | Message Length |
+--------------+--------------+--------------+--------------+
| BR IPv4 Address format |
+--------------+--------------+--------------+--------------+
Figure 5-6 IPv4 type
IP-Type = 2, IPv6 Address
+--------------+--------------+--------------+--------------+
| IP Version | //////// | Message Length |
+--------------+--------------+--------------+--------------+
| |
+ +
| |
Ebata et al Expires April 2000 [Page 23]
Internet Draft October 1999
+ BR IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
Figure 5-7 IPv4 type
The advertised policy is prefixed by a policy index header as shown in
Figure 5-8. The header includes policy type and its length.
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | P-Num | P-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
Figure 5-8 Policy index header
P-num is policy number which means a kind of policy, and P-type is its
type.
P-num: 8 bits Policy number
1 = customer policy
2 = service policy
3 = flow policy
4 = billing policy
5 = charging policy
6 = accounting policy
P-Type: 8 bits Policy type
Its value depends on each policy.
The policy contents are discussed in Section 5.4.
5.4. Contents
5.4.1. Customer policy
(1)P-num = 1, P-type = 1 Priority
Priority means customer priority.
-Number of Priority :
Regulated rank number which a source PS determine,
-Priority level :
Customer's priority level
Ebata et al Expires April 2000 [Page 24]
Internet Draft October 1999
0 1 2 3
+-------------+-------------+-------------+-------------+
| Number of Priority | Priority level |
+-------------+-------------+-------------+-------------+
Figure 5-9 Priority
(2)P-num = 1, P-type = 2 Usable service
Usable service means the service provided in the source domain and the
customer can use.
-Number of Usable service
Number of service which the customer can use
-Usable service ID
ID of service which the customer can use
0 1 2 3
+-------------+-------------+-------------+-------------+
| Number of Usable service |
+-------------+-------------+-------------+-------------+
| Usable service ID |
+-------------+-------------+-------------+-------------+
| |
// //
| |
+-------------+-------------+-------------+-------------+
| Usable service ID |
+-------------+-------------+-------------+-------------+
Figure 5-10 Usable service
(3)P-num = 1, P-type = 3 Valid date and time
This is the valid date and time when the customer can be provided
services.
-Invalid date and time(0)
ID which indicate the head of Invalid date and time
information
-Valid date and time(1)
ID which indicate the head of Valid date and time
information
0 1 2 3
+-------------+-------------+-------------+-------------+
| Invalid date and time(0) | Length |
+-------------+-------------+-------------+-------------+
| |
// Date Time information //
| |
Ebata et al Expires April 2000 [Page 25]
Internet Draft October 1999
+-------------+-------------+-------------+-------------+
| Valid date and time(0) | Length |
+-------------+-------------+-------------+-------------+
| |
// Date Time information //
| |
+-------------+-------------+-------------+-------------+
Figure 5-11 Valid date and time
5.4.2. Service policy
(1)P-num = 2, P-type = 1 Provided service
Provided service means services which are provided by the source
domain.
-Number of provided service
Number of service that the source domain provides.
-Provided service ID
ID of service (it should be managed in all domains)
-Available date and time
date and time when the service is provided.
-Request QoS
Request QoS which the service needs
0 1 2 3
+-------------+-------------+-------------+-------------+
| Number of provided service |
+-------------+-------------+-------------+-------------+
| Provided service ID |
+-------------+-------------+-------------+-------------+
| |
// Available date and time //
| |
+-------------+-------------+-------------+-------------+
| |
// Request QoS //
| |
+-------------+-------------+-------------+-------------+
Figure 5-12 Provided service
5.4.3. Flow policy
(1)P-num = 3, P-type = 1 General QoS
This is general QoS which are provided by the source domain
- Jitter, measured in miliseconds.
Param. ID = 1, Param. Flag = 2 (max.)
- Packet Loss, measured in loss ratio.
Param. ID = 2, Param. Flag = 1 (min.), Param. Flag = 2 (max.)
Ebata et al Expires April 2000 [Page 26]
Internet Draft October 1999
- Available path bandwidth, measured in Mbps.
Param. ID = 3, Param. Flag = 1 (min.), Param. Flag = 2 (max.)
- Path latency, measured in miliseconds.
Param. ID = 4, Param. Flag = 1 (min.), Param. Flag = 2 (max.)
- Maximum transmission unit, measured in bytes.
Param. ID = 5, Param. Flag = 0 (not defined)
0 1 2 3
+-------------+-------------+-------------+-------------+
|Param. ID(4) | Param. Flag | Length |
+-------------+-------------+-------------+-------------+
| |
// Param. Value //
| |
+-------------+-------------+-------------+-------------+
Figure 5-13 General QoS
PS is allowed to transform these policies in this process, but it is
not referred in this document in detail.
5.4.4. Billing policy
(1)P-num = 4, P-type = 1 Customer Credit
-Priority level
Customer's priority level
-Minimum credit
Required minimum credit for the customer to start a
service
0 1 2 3
+-------------+-------------+-------------+-------------+
| Priority level | Length |
+-------------+-------------+-------------+-------------+
| Minimum credit |
+-------------+-------------+-------------+-------------+
Figure 5-14 Customer Credit
5.4.5. Charging policy
(1)P-num = 5, P-type = 1 Charging Scheme
-Usable Service ID
ID of service which the customer can use
-CF Type
Charging formula used
CF Type = 1: duration based, e.g. Charge = B.P
CF Type = 2: volume based, e.g. Charge = V.P
-Param. ID
Charging parameters
Ebata et al Expires April 2000 [Page 27]
Internet Draft October 1999
- Price: Param. ID = 1
- Fixed cost: Param. ID = 2
- Credit: Param. ID = 3
0 1 2 3
+-------------+-------------+-------------+-------------+
| Usable service ID |
+-------------+-------------+-------------+-------------+
| CF Type | Number of Parameters |
+-------------+-------------+-------------+-------------+
|Param. ID(4) | Param. Flag | Length |
+-------------+-------------+-------------+-------------+
| |
// Param. Value //
| |
+-------------+-------------+-------------+-------------+
Figure 5-15 Charging Scheme
5.4.6. Accounting policy
(1)P-num = 6, P-type = 1 Accounting report
- Measured Volume, measured in bytes.
Param. ID = 1, Param. Flag = 0 (not defined)
- Measured Bandwidth, measured in Mbps.
Param. ID = 2, Param. Flag = 0 (not defined)
- Jitter, measured in miliseconds.
Param. ID = 3, Param. Flag = 0 (not defined)
- Packet Loss, measured in loss ratio.
Param. ID = 4, Param. Flag = 0 (avg.)
- Packet delay, measured in miliseconds.
Param. ID = 5, Param. Flag = 0 (avg.)
0 1 2 3
+-------------+-------------+-------------+-------------+
|Param. ID(4) | Param. Flag | Length |
+-------------+-------------+-------------+-------------+
| |
// Param. Value //
| |
+-------------+-------------+-------------+-------------+
Figure 5-16 Accounting Report
6. Policy negotiation and notification protocol
In this chapter, for the purpose of inter-domain policy
negotiation and notification, it is explained about the policy
negotiation and notification protocol(in short PNP) which is enhanced
COPS protocol.
Ebata et al Expires April 2000 [Page 28]
Internet Draft October 1999
6.1. Outline
In this clause, the outline of the PNP and the sample policies and
functions are explained.
The PNP is to convey some policies and to execute some actions
corresponded with its policies between PDPs(Policy Decision Points)
and PEPs(Policy Enforcement Points).
In order to control these services through inter-domain, the signaling
function which trigger the control is needed with carrying necessary
policy. As far as this process, COPS (Common Open Policy Service) is
available. But COPS is assumed to utilize between the policy decision
point like PSs and the policy enforcement point like routers only at
present. Because the PNP must be enhanced in order to adapt to use
between multi PSs, PSs must have both functions as PDP and PEP.
The outline process of the PNP is showed in figure 6-1.
+-----+ +-----+ +-----+
| PSa | | PSc | | PSd |
+-----+ +-----+ +-----+
| | |
+----+---+ +---+---+ +---+---+
/ \ / \ / \
| +------+ +------+ +------+ +------ |
| | BRa2 |---| BRc1 |---| BRc1 |---| BRd1 | |
| +------+ +------+ +------+ +------+ |
\ Domain A / \Domain B / \Domain D /
+---------+ +-------+ +-------+
| Client-Open(CO) | |
|<----------------------| | |
| Client-Accept(CA) | | Initial management |
|---------------------->| | |
| | |
|Decision(DEC(Install)) | |
|---------------------->| |
| |Decision(DEC(Install)) |
| |---------------------->|
| | |
| | Report State(RPT |
| |(Installed/NotInstall))|
| Report State(RPT |<----------------------|
|(Installed/NotInstall))| |
|<----------------------| |
| | |
Figure 6-1 Example of policy negotiation and notification
This figure shows that in order to execute inter-domain QoS
provisioning and accounting between one customer in domain A and
Ebata et al Expires April 2000 [Page 29]
Internet Draft October 1999
another customer in domain D, PSa negotiates with PSc and PSc does with
PSd.
Firstly, each PS makes a session for the PNP. The process is that a PS
sends Client-Open(CO) message toward another PS and the PS receives
Client-Accept(CA) message from above another PS.
When a request for above service which is called "negotiation items"
occurs in the source domain (Domain A), the source PS(PSa)
investigates several things, for example, whether QoS provisioning is
available or not in the domain. After that, the source PS(PSa) sends
Decision(DEC(Install)) message that includes decision policies toward
the destination PS(PSc).
Next, the destination PS(PSc) investigate the above same things, and
sends Report State(RPT(Installed/NotInstall)) message that includes
its reply (negotiation accept or not) of decision policies toward the
source PS(PSa).
But as figure 6-1 shows, there is no physical direct connection
between the Domain A and Domain D. In this case, both PSa and PSd need
to make a logical connection through Domain C.
In this case, after PSc receives Decision(DEC(Install)) message from
PSa, PSc search paths in order to connect Domain A with Domain D and
investigates several items about the path. After that, PSc sends
another Decision(DEC(Install)) message that includes the decision
policies toward PSd.
PSd investigates the above same things, and sends Report
State(RPT(Installed/NotInstall)) message that includes its reply
(negotiation accept or not) of decision policies toward PSc.
After PSc receive its reply, PSc sends State
(RPT(Installed/NotInstall)) message to PSa.
Thus, this process is guaranteed to execute without numbers of domain.
6.2. Protocol
PNP is all based on COPS, except for communicating between PSs (PDPs).
6.3. Message format
All is based on COPS.
6.4. Contents
6.4.1. Client-Open(OPN) message
This message is sent from a source PS as PDP to a destination PS as
PEP, in order to trigger PNP session.
-Domain ID as PEP(AS-ID)
AS-ID that specifies a source PS
-Waiting time for negotiation response (Timeout)
Ebata et al Expires April 2000 [Page 30]
Internet Draft October 1999
Time that PS should wait for RPT(Installed) from other
domain where this PS sent to DEC(Install).
<Client-Open> ::= <Common Header>
<PEPID>
<ClientSI>
<Common Header>
+-------------+-------------+-------------+-------------+
|Version|Flag | OpCode | Client-Type |
+-------------+-------------+-------------+-------------+
| Message Length |
+-------------+-------------+-------------+-------------+
Version :4bit fixed on 1
Flag :4bit fixed on 0
OpCode :8bit Client-Open(6)
Client-Type :16bit InterDomain(3)
Message Length :32bit octet length that includes Common Header
<PEPID>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| AS-ID as PEP |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit PEP Identification(11)
C-Type :8bit fixed on 1
C-Type :8bit 1
<ClientSI>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Waiting time for negotiation response (Timeout) |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit Client Specific Info(9)
C-Type :8bit Named ClientSI(2)
6.4.2. Client-Accept(CAT) message
This message is sent as from a destination PS as PEP to a source PS as
PDP, in order to establish PNP session.
- Keep Alive(KA) time
Regular interval time that PS confirm the alive of
COPS session.
<Client-Accept> ::= <Common Header>
<KA Timer>
<Common Header>
+-------------+-------------+-------------+-------------+
Ebata et al Expires April 2000 [Page 31]
Internet Draft October 1999
|Version|Flag | OpCode | Client-Type |
+-------------+-------------+-------------+-------------+
| Message Length |
+-------------+-------------+-------------+-------------+
Version :4bit fixed on 1
Flag :4bit fixed on 0
OpCode :8bit Client Accept(7)
Client-Type :16bit InterDomain(3)
Message Length :32bit octet length that includes Common Header
<KA Timer>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| ////////////// | KA Timer Value |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit Keep-Alive Timer(10)
C-Type :8bit fixed on 1
KA Timer Value:16bit Keep Alive time (1 - 65535)[sec]
Infinity time (0)
6.4.3. Client-Open(OPN) message
This message closes PNP session, and it is available for both a
destination PS as PEP to a source PS as PDP.
-Error Code
Code that indicates the reason to terminate COPS
session.
-Error Sub-Code
It is depended on each Error Code.
<Client-Close> ::= <Common Header>
<Error>
<Common Header>
+-------------+-------------+-------------+-------------+
|Version|Flag | OpCode | Client-Type |
+-------------+-------------+-------------+-------------+
| Message Length |
+-------------+-------------+-------------+-------------+
Version :4bit fixed on 1
Flag :4bit fixed on 0
OpCode :8bit Client-Close(8)
Client-Type :16bit InterDomain(3)
Message Length : Octet length that includes Common Header
<Error>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Error-Code | Error-Sub Code |
Ebata et al Expires April 2000 [Page 32]
Internet Draft October 1999
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit Error(8)
C-Type :8bit fixed on 1
Error-Code : 16bit
Normal end (0)
(TBD)
Error-Sub Code : 16bit
(TBD)
6.4.4. Decision(DEC) message
This message is sent from a source PS as PDP to a destination PS as
PEP, in order for a trigger to carry decision policies.
-Negotiation ID
ID that is issued by a source PS
-Source domain ID and Source host IP
AS-ID and host that requests QoS provisioning and
accounting through inter-domain
-Request Policy
Policies which are send toward the destination Domain
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision>
<Context>
<Common Header>
+-------------+-------------+-------------+-------------+
|Version|Flag | OpCode | Client-Typ |
+-------------+-------------+-------------+-------------+
| Message Length |
+-------------+-------------+-------------+-------------+
Version :4bit fixed on 1
Flag :4bit fixed on 0
OpCode :8bit Decision(2)
Client-Type :16bit InterDomain(3)
Message Length :32bit octet length that includes Common Header
<Client Handle>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Source domain ID(AS-ID) | |
+-------------+-------------+ Date and time +
| |
+-------------+-------------+-------------+-------------+
| Negotiation ID |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 12
C-Num :8bit Handle(1)
Ebata et al Expires April 2000 [Page 33]
Internet Draft October 1999
C-Type :8bit 1
<Decision>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Command-Code | Flags |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit Decision(6)
C-Type :8bit 1
Command-Code: 16bit
NULL Decision (No configuration data available)(0)
Install (Admit request/Install configuration)(1)
Remove (Remove request/Remove configuration)(2)
Flags :fixed on 16(Un-used)
<Context>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| destination AS-ID | IP Version |
+-------------+-------------+-------------+-------------+
| |
// Source host IP address(a) //
| |
+-------------+-------------+-------------+-------------+
| |
// Request QoS(b) //
| |
+-------------+-------------+-------------+-------------+
(a) Data format is depended on Common header in 5.3.
(b) Data format is (T.B.D.)
When <Decision>Command-Code is "Remove" status, <Context> is
not needed.
Length :16bit fixed on 28
C-Num :8bit Context(2)
C-Type :8bit 1
Date of request start/end Year(7bit) + Month(4bit) +
Day(5bit)
Time of request start/end Hour(5bit) + Minute(6bit) +
Second(6mit) + Millisecond
(10bit)
6.4.5. Report State(RPT) message
This message is sent from a destination PS as PEP to a source PS as
PDP in order to reply the result of the DEC message.
Ebata et al Expires April 2000 [Page 34]
Internet Draft October 1999
-Negotiation ID
This is same ID that are used in DEC message
-Negotiation result
included "negotiation success", "negotiation fail",
"success of cancel negotiation matter", "fail of
cancel negotiation matter" and others(T.B.D.).
-Reason of negotiation fail
included "resource reservation fail", "timeout",
"Policy violation" and others(T.B.D.).
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
<ClientSI>
<Common Header>
+-------------+-------------+-------------+-------------+
|Version|Flag | OpCode | Client-Type |
+-------------+-------------+-------------+-------------+
| Message Length |
+-------------+-------------+-------------+-------------+
Version :4bit fixed on 1
Flag :4bit fixed on 0
OpCode :8bit Report State(3)
Client-Type :16bit InterDomain(3)
Message Length :32bit octet length that includes Common Header
<Client Handle>
same as DEC message
<Report-Type>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Report-Type | ///////////// |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit Report Type(12)
C-Type :8bit 1
Report-Type : 16bit
Installed(4)
Removed(5)
NotInstall(6)
NotRemoved(7)
<ClientSI>
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| AS-ID | Error-Code |
+-------------+-------------+-------------+-------------+
Length :16bit fixed on 8
C-Num :8bit Client Specific Info(9)
Ebata et al Expires April 2000 [Page 35]
Internet Draft October 1999
C-Type :8bit
C-Type :8bit Named ClientSI(2)
AS-ID :16bit
that indicate an domain of PS that detects error
first.
Error-Code :16bit
Resource Reservation fail(1)
Timeout(2)
Policy violation(3)
When <Report-Type> NotInstall(6),NotRemoved(7)
exists,<ClientSI> is added.
7. Security Considerations
PAP and PNP are the enhanced each BGP4 and COPS. Both protocol have
already implemented or considered security functions[BGP4][COPS].
In this document, no security issue is described.
8. References
[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.
[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
9. Author's addresses
Tomoichi Ebata
Hitachi, Ltd.
System Development Laboratory
292 Yoshida-cho, Totsuka-ku,
Ebata et al Expires April 2000 [Page 36]
Internet Draft October 1999
Yokohama, Kanagawa 244-0817 JAPAN
Phone: +81 45 860 3079
Email: ebata@sdl.hitachi.co.jp
TAKIHIRO, Masatoshi
Hitachi, Ltd.
System Development Laboratory
292 Yoshida-cho, Totsuka-ku,
Yokohama, Kanagawa 244-0817 JAPAN
Phone: +81 45 860 3077
Email: takihiro@sdl.hitachi.co.jp
Shigeru Miyake
Hitachi, Ltd.
System Development Laboratory
292 Yoshida-cho, Totsuka-ku,
Yokohama, Kanagawa 244-0817 JAPAN
Phone: +81 45 860 3080
Email: yake@sdl.hitachi.co.jp
Minoru Koizumi
Hitachi, Ltd.
System Development Laboratory
292 Yoshida-cho, Totsuka-ku,
Yokohama, Kanagawa 244-0817 JAPAN
Phone: +81 45 860 3079
Email: m-koizu@sdl.hitachi.co.jp
Felix Hartanto
GMD FOKUS
Kaiserin-Augusta-Allee 31
D-10589 Berlin GERMANY
Phone: +49 30 3463 7136
Email: hartanto@fokus.gmd.de
Georg Carle
GMD FOKUS
Kaiserin-Augusta-Allee 31
D-10589 Berlin GERMANY
Phone: +49 30 3463 7149
Email: carle@fokus.gmd.de
Ebata et al Expires April 2000 [Page 37]