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 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). ::= +-------------+-------------+-------------+-------------+ |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 +-------------+-------------+-------------+-------------+ | 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 +-------------+-------------+-------------+-------------+ | 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. ::= +-------------+-------------+-------------+-------------+ 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 +-------------+-------------+-------------+-------------+ | 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. ::= +-------------+-------------+-------------+-------------+ |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 +-------------+-------------+-------------+-------------+ | 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 ::= +-------------+-------------+-------------+-------------+ |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 +-------------+-------------+-------------+-------------+ | 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 +-------------+-------------+-------------+-------------+ | 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) +-------------+-------------+-------------+-------------+ | 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 Command-Code is "Remove" status, 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.). ::== +-------------+-------------+-------------+-------------+ |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 same as DEC message +-------------+-------------+-------------+-------------+ | 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) +-------------+-------------+-------------+-------------+ | 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 NotInstall(6),NotRemoved(7) exists, 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]