idnits 2.17.1 draft-ietf-rap-framework-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 393 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], RFC, [RFC2211,, 2212], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 51 has weird spacing: '...include an im...' == Line 142 has weird spacing: '...ructure and m...' == Line 169 has weird spacing: '... of any speci...' == Line 365 has weird spacing: '...P which rende...' == Line 487 has weird spacing: '...rwarded as us...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2205' on line 45 -- Looks like a reference, but probably isn't: 'RFC 2211' on line 45 -- Looks like a reference, but probably isn't: 'RFC 2212' on line 45 == Unused Reference: '5' is defined on line 844, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-05 == Outdated reference: A later version (-05) exists of draft-ietf-rsvp-policy-ext-03 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1825 (ref. '4') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2138 (ref. '5') (Obsoleted by RFC 2865) == Outdated reference: A later version (-01) exists of draft-rajan-policy-qosschema-00 -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-ietf-rap-priority - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' -- No information found for draft-ietf-rap- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Raj Yavatkar, Intel 2 INTERNET-DRAFT Dimitrios Pendarakis, IBM 3 draft-ietf-rap-framework-02.txt Roch Guerin, U. Of Pennsylvania 5 April 1999 6 Expires: December 1999 8 A Framework for Policy-based Admission Control 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 A Framework for Policy-based Admission Control March 1999 33 1. Abstract 35 The IETF working groups such as Integrated Services (called "int-serv") 36 and RSVP [1] have developed extensions to the IP architecture and the 37 best-effort service model so that applications or end users can request 38 specific quality (or levels) of service from an internetwork in addition 39 to the current IP best-effort service. Recent efforts in the Differen- 40 tiated Services Working Group are also directed at definition of mechan- 41 isms that support aggregate QoS services. The int-serv model for these new 42 services requires explicit signaling of the QoS (Quality of Service) 43 requirements from the end points and provision of admission and traffic 44 control at Integrated Services routers. The proposed standards for RSVP 45 [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a 46 new reservation setup protocol and new service definitions respectively. 47 Under the int-serv model, certain data flows receive preferential treat- 48 ment over other flows; the admission control component only takes into 49 account the requester's resource reservation request and available capa- 50 city to determine whether or not to accept a QoS request. However, the 51 int-serv mechanisms do not include an important aspect of admission con- 52 trol: network managers and service providers must be able to monitor, con- 53 trol, and enforce use of network resources and services based on policies 54 derived from criteria such as the identity of users and applications, 55 traffic/bandwidth requirements, security considerations, and time-of- 56 day/week. Similarly, diff-serv mechanisms also need to take into account 57 policies that take into account various criteria such as customer iden- 58 tity, ingress points, and so on. 60 This document is concerned with specifying a framework for providing 61 policy-based control over admission control decisions. In particular, it 62 focuses on policy-based control over admission control using RSVP as an 63 example of the QoS signaling mechanism. Even though the focus of the work 64 is on RSVP-based admission control, the document outlines a framework that 65 can provide policy-based admission control in other QoS contexts. We argue 66 that policy-based control must be applicable to different kinds and quali- 67 ties of services offered in the same network and our goal is to consider 68 such extensions whenever possible. 70 We begin with a list of definitions in Section 2. Section 3 lists the 71 requirements and goals of the mechanisms capable of controlling and 72 enforcing access to better QoS. We then outline the architectural ele- 73 ments of the framework in Section 4 and describe the functionality assumed 74 for each component. Section 5 discusses example policies, possible 75 scenarios, and policy support needed for those scenarios. Section 6 speci- 76 fies the requirements for a client-server protocol for communication 77 between a policy server (PDP) and its client (PEP) and evaluates suitabil- 78 ity of some of the existing protocols for this purpose. 80 A Framework for Policy-based Admission Control March 1999 82 2. Terminology 84 The following is a list of terms used in this document. 86 - Administrative Domain: A collection of networks under the same 87 administrative control and grouped together for administrative pur- 88 poses. 90 - Network Element or Node: Routers, switches, hubs are examples of 91 network nodes. They are the entities where resource allocation 92 decisions have to be made and the decisions have to be enforced. A 93 RSVP router which allocates part of a link capacity (or buffers) to 94 a particular flow and ensures that only the admitted flows have 95 access to their reserved resources is an example of a network ele- 96 ment of interest in our context. 98 In this document, sometimes we use the terms router, network ele- 99 ment, and network node interchangeably, but should be interpreted 100 as reference to a network element. 102 - QoS Signaling Protocol: A signaling protocol that carries an admis- 103 sion control request for a bandwidth resource, e.g., RSVP. 105 - Policy: The combination of rules and services where rules define 106 the criteria for resource access and usage. 108 - Policy control: The application of rules to determine whether or 109 not access to a particular resource should be granted. 111 - Policy Object: Contains policy-related info such as policy ele- 112 ments and is carried in a request or response related to resource 113 allocation decision. 115 - Policy Element: Subdivision of policy objects; contains single 116 units of information necessary for the evaluation of policy rules. 117 A single policy element carries an user or application identifica- 118 tion whereas another policy element may carry user credentials or 119 credit card information. Examples of policy elements include iden- 120 tity of the requesting user or application, user/app credentials, 121 etc. The policy elements themselves are expected to be independent 123 A Framework for Policy-based Admission Control March 1999 125 of which QoS signaling protocol is used. 127 - Policy Decision Point (PDP): The point where policy decisions are 128 made. 130 - Policy Enforcement Point (PEP): The point where the policy deci- 131 sions are actually enforced. 133 - Policy Ignorant Node (PIN): A network element that does not expli- 134 citly support policy control using the mechanisms defined in this 135 document. 137 - Resource: Something of value in a network infrastructure to which 138 rules or policy criteria are first applied before access is 139 granted. Examples of resources include the buffers in a router and 140 bandwidth on an interface. 142 - Service Provider: Controls the network infrastructure and may be 143 responsible for the charging and accounting of services. 145 - Soft State Model - Soft state is a form of the stateful model that 146 times out installed state at a PEP or PDP. It is an automatic way 147 to erase state in the presence of communication or network element 148 failures. For example, RSVP uses the soft state model for instal- 149 ling reservation state at network elements along the path of a data 150 flow. 152 - Installed State: A new and unique request made from a PEP to a PDP 153 that must be explicitly deleted. 155 - Trusted Node: A node that is within the boundaries of an adminis- 156 trative domain (AD) and is trusted in the sense that the admission 157 control requests from such a node do not necessarily need a PDP 158 decision. 160 3. Policy-based Admission Control: Goals and Requirements 162 A Framework for Policy-based Admission Control March 1999 164 In this section, we describe the goals and requirements of mechanisms and 165 protocols designed to provide policy-based control over admission control 166 decisions. 168 - Policies vs Mechanisms: An important point to note is that the 169 framework does not include any discussion of any specific policy 170 behavior or does not require use of specific policies. Instead, the 171 framework only outlines the architectural elements and mechanisms 172 needed to allow a wide variety of possible policies to be carried 173 out. 175 - RSVP-specific: The mechanisms must be designed to meet the policy- 176 based control requirements specific to the problem of bandwidth 177 reservation using RSVP as the signaling protocol. However, our goal 178 is to allow for the application of this framework for admission 179 control involving other types of resources and QoS services (e.g., 180 Diff-Serv) as long as we do not diverge from our central goal. 182 - Support for preemption: The mechanisms designed must include sup- 183 port for preemption. By preemption, we mean an ability to remove a 184 previously installed state in favor of accepting a new admission 185 control request. For example, in the case of RSVP, preemption 186 involves the ability to remove one or more currently installed 187 reservations to make room for a new resource reservation request. 189 - Support for many styles of policies: The mechanisms designed must 190 include support for many policies and policy configurations includ- 191 ing bi-lateral and multi-lateral service agreements and policies 192 based on the notion of relative priority. In general, the determi- 193 nation and configuration of viable policies are the responsibility 194 of the service provider. 196 - Provision for Monitoring and Accounting Information: The mechan- 197 isms must include support for monitoring policy state, resource 198 usage, and provide access information. In particular, mechanisms 199 must be included to provide usage and access information that may 200 be used for accounting and billing purposes. 202 - Fault tolerance and recovery: The mechanisms designed on the basis 203 of this framework must include provisions for fault tolerance and 204 recovery from failure cases such as failure of PDPs, disruption in 206 A Framework for Policy-based Admission Control March 1999 208 communication including network partitions (and subsequent merging) 209 that separate a PDP from its peer PEPs. 211 - Support for Policy-Ignorant Nodes (PINs): Support for the mechan- 212 isms described in this document should not be mandatory for every 213 node in a network. Policy based admission control could be enforced 214 at a subset of nodes, for example the boundary nodes within an 215 administrative domain. These policy capable nodes would function as 216 trusted nodes from the point of view of the policy-ignorant nodes 217 in that administrative domain. 219 - Scalability: One of the important requirements for the mechanisms 220 designed for policy control is scalability. The mechanisms must 221 scale at least to the same extent that RSVP scales in terms of 222 accommodating multiple flows and network nodes in the path of a 223 flow. In particular, scalability must be considered when specifying 224 default behavior for merging policy data objects and merging should 225 not result in duplicate policy elements or objects. There are 226 several sensitive areas in terms of scalability for policy control 227 over RSVP. First, not every policy aware node in an infrastructure 228 should be expected to contact a remote PDP. This would cause poten- 229 tially long delays in verifying requests that must travel up hop by 230 hop. Secondly, RSVP is capable of setting up resource reservations 231 for multicast flows. This implies that the policy control model 232 must be capable of servicing the special requirements of large mul- 233 ticast flows. Thus, the policy control architecture must scale at 234 least as well as RSVP based on factors such as the size of RSVP 235 messages, the time required for the network to service an RSVP 236 request, local processing time required per node, and local memory 237 consumed per node. 239 - Security and denial of service considerations: The policy control 240 architecture must be secure as far as the following aspects are 241 concerned. First, the mechanisms proposed under the framework must 242 minimize theft and denial of service threats. Second, it must be 243 ensured that the entities (such as PEPs and PDPs) involved in pol- 244 icy control can verify each other's identity and establish neces- 245 sary trust before communicating. 247 4. Architectural Elements 249 The two main architectural elements for policy control are the PEP (Policy 251 A Framework for Policy-based Admission Control March 1999 253 Enforcement Point) and the PDP (Policy Decision Point). Figure 1 shows a 254 simple configuration involving these two elements; PEP is a component at a 255 network node and PDP is a remote entity that may reside at a policy 256 server. The PEP represents the component that always runs on the policy 257 aware node. It is the point at which policy decisions are actually 258 enforced. Policy decisions are made primarily at the PDP. The PDP itself 259 may make use of additional mechanisms and protocols to achieve additional 260 functionality such as user authentication, accounting, policy information 261 storage, etc. For example, the PDP is likely to use an LDAP-based direc- 262 tory service for storage and retrieval of policy information[6]. This 263 document does not include discussion of these additional mechanisms and 264 protocols and how they are used. 266 The basic interaction between the components begins with the PEP. The PEP 267 will receive a notification or a message that requires a policy decision. 268 Given such an event, the PEP then formulates a request for a policy deci- 269 sion and sends it to the PDP. The request for policy control from a PEP 270 to the PDP may contain one or more policy elements (encapsulated into one 271 or more policy objects) in addition to the admission control information 272 (such as a flowspec or amount of bandwidth requested) in the original mes- 273 sage or event that triggered the policy decision request. The PDP returns 274 the policy decision and the PEP then enforces the policy decision by 275 appropriately accepting or denying the request. The PDP may also return 276 additional information to the PEP which includes one or more policy ele- 277 ments. This information need not be associated with an admission control 278 decision. Rather, it can be used to formulate an error message or 279 outgoing/forwarded message. 281 ________________ Policy server 282 | | ______ 283 | Network Node | | |-------------> 284 | _____ | | | May use LDAP,SNMP,.. for accessing 285 | | | | | | policy database, authentication,etc. 286 | | PEP |<-----|------->| PDP |-------------> 287 | |_____| | |_____| 288 | | 289 |________________| 291 Figure 1: A simple configuration with the primary policy control 292 architecture components. PDP may use additional mechanisms and protocols 293 for the purpose of accounting, authentication, policy storage, etc. 295 The PDP might optionally contact other external servers, e.g., for access- 296 ing configuration, user authentication, accounting and billing databases. 297 Protocols defined for network management (SNMP) or directory access (LDAP) 298 might be used for this communication. While the specific type of access 299 and the protocols used may vary among different implementations, some of 301 A Framework for Policy-based Admission Control March 1999 303 these interactions will have network-wide implications and could impact 304 the interoperability of different devices. 306 Of particular importance is the "language" used to specify the policies 307 implemented by the PDP. The number of policies applicable at a network 308 node might potentially be quite large. At the same time, these policies 309 will exhibit high complexity, in terms of number of fields used to arrive 310 at a decision, and the wide range of decisions. Furthermore, it is likely 311 that several policies could be applicable to the same request profile. For 312 example, a policy may prescribe the treatment of requests from a general 313 user group (e.g., employees of a company) as well as the treatment of 314 requests from specific members of that group (e.g., managers of the com- 315 pany). In this example, the user profile "managers" falls within the 316 specification of two policies, one general and one more specific. 318 In order to handle the complexity of policy decisions and to ensure a 319 coherent and consistent application of policies network-wide, the policy 320 specification language should ensure unambiguous mapping of a request pro- 321 file to a policy action. It should also permit the specification of the 322 sequence in which different policy rules should be applied and/or the 323 priority associated with each one. Some of these issues are addressed in 324 [6]. 326 In some cases, the simple configuration shown in Figure 1 may not be suf- 327 ficient as it might be necessary to apply local policies (e.g., policies 328 specified in access control lists) in addition to the policies applied at 329 the remote PDP. In addition, it is possible for the PDP to be co-located 330 with the PEP at the same network node. Figure 2 shows the possible confi- 331 gurations. 333 The configurations shown in Figures 1 and 2 illustrate the flexibility in 334 division of labor. On one hand, a centralized policy server, which could 335 be responsible for policy decisions on behalf of multiple network nodes in 336 an administrative domain, might be implementing policies of a wide scope, 337 common across the AD. On the other hand, policies which depend on informa- 338 tion and conditions local to a particular router and which are more 339 dynamic, might be better implemented locally, at the router. 341 A Framework for Policy-based Admission Control March 1999 343 ________________ ____________________ 344 | | | | 345 | Network Node | Policy Server | Network Node | 346 | _____ | _____ | _____ _____ | 347 | | | | | | | | | | | | 348 | | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | | 349 | |_____| | |_____| | |_____| |_____| | 350 | ^ | | | 351 | | _____ | |____________________| 352 | \-->| | | 353 | | LPDP| | 354 | |_____| | 355 | | 356 |________________| 358 Figure 2: Two other possible configurations of policy control 359 architecture components. The configuration on left shows a local decision 360 point at a network node and the configuration on the left shows PEP and 361 PDP co-located at the same node. 363 If it is available, the PEP will first use the LPDP to reach a local deci- 364 sion. This partial decision and the original policy request are next sent 365 to the PDP which renders a final decision (possibly, overriding the 366 LPDP). It must be noted that the PDP acts as the final authority for the 367 decision returned to the PEP and the PEP must enforce the decision ren- 368 dered by the PDP. Finally, if a shared state has been established for the 369 request and response between the PEP and PDP, it is the responsibility of 370 the PEP to notify the PDP that the original request is no longer in use. 372 Unless otherwise specified, we will assume the configuration shown on the 373 left in Figure 2 in the rest of this document. 375 Under this policy control model, the PEP module at a network node must use 376 the following steps to reach a policy decision: 378 1. When a local event or message invokes PEP for a policy decision, 379 the PEP creates a request that includes information from the mes- 380 sage (or local state) that describes the admission control request. 381 In addition, the request includes appropriate policy elements as 382 described below. 384 2. The PEP may consult a local configuration database to identify a 385 set of policy elements (called set A) that are to be evaluated 386 locally. The local configuration specifies the types of policy ele- 387 ments that are evaluated locally. The PEP passes the request with 389 A Framework for Policy-based Admission Control March 1999 391 the set A to the Local Decision point (LPDP) and collects the 392 result of the LPDP (called "partial result" and referred to as D(A) 393 ). 395 3. The PEP then passes the request with ALL the policy elements and 396 D(A) to the PDP. The PDP applies policies based on all the policy 397 elements and the request and reaches a decision (let us call it 398 D(Q)). It then combines its result with the partial result D(A) 399 using a combination operation to reach a final decision. 401 4. The PDP returns the final policy decision (one after the combina- 402 tion operation) to the PEP. 404 Note that in the above model, the PEP *must* contact the PDP even if no 405 (or NULL) policy objects are received in the admission control request. 406 This requirement would help ensure that a request cannot bypass policy 407 control by omitting policy elements in a reservation request. However, 408 ``short circuit'' processing is permitted, i.e., if the result of D(A), 409 above, is ``no'', then there is no need to proceed with further policy 410 processing at the policy server. Still, the PDP must be informed of the 411 failure of local policy processing. The same applies to the case when pol- 412 icy processing is successful but admission control (at the resource 413 management level due to unavailable capacity) fails; again the policy 414 server has to be informed of the failure. 416 It must also be noted that the PDP may, at any time, send an asynchronous 417 notification to the PEP to change its earlier decision or to generate a 418 policy error/warning message. 420 4.1. Example of a RSVP Router 422 In the case of a RSVP router, Figure 3 shows the interaction between a PEP 423 and other int-serv components within the router. For the purpose of this 424 discussion, we represent all the components of RSVP-related processing by 425 a single RSVP module, but more detailed discussion of the exact interac- 426 tion and interfaces between RSVP and PEP will be described in a separate 427 document [3]. 429 A Framework for Policy-based Admission Control March 1999 431 ______________________________ 432 | | 433 | Router | 434 | ________ _____ | _____ 435 | | | | | | | | 436 | | RSVP |<------->| PEP |<--|---------->| PDP | 437 | |________| |_____| | |_____| 438 | ^ | 439 | | Traffic control | 440 | | _____________ | 441 | \---->| _________ | | 442 | | |capacity | | | 443 | | | ADM CTL | | | 444 | | |_________| | | 445 --|----------->| ____ ____ | | 446 | Data | | PC | PS | | | 447 | | |____|____| | | 448 | |_____________| | 449 | | 450 |______________________________| 452 Figure 3: Relationship between PEP and other int-serv components 453 within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler 455 When a RSVP message arrives at the router (or an RSVP related event 456 requires a policy decision), the RSVP module is expected to hand off the 457 request (corresponding to the event or message) to its PEP module. The PEP 458 will use the PDP (and LPDP) to obtain the policy decision and communicate 459 it back to the RSVP module. 461 4.2. Additional functionality at the PDP 463 Typically, PDP returns the final policy decision based on an admission 464 control request and the associated policy elements. However, it should be 465 possible for the PDP to sometimes ask the PEP (or the admission control 466 module at the network element where PEP resides) to generate policy- 467 related error messages. For example, in the case of RSVP, the PDP may 468 accept a request and allow installation and forwarding of a reservation to 469 a previous hop, but, at the same time, may wish to generate a 470 warning/error message to a downstream node (NHOP) to warn about conditions 471 such as "your request may have to be torn down in 10 mins, etc." Basi- 472 cally, an ability to create policy-related errors and/or warnings and to 473 propagate them using the native QoS signaling protocol (such as RSVP) is 474 needed. Such a policy error returned by the PDP must be able to also 475 specify whether the reservation request should still be accepted, 476 installed, and forwarded to allow continued normal RSVP processing. In 477 particular, when a PDP sends back an error, it specifies that: 479 A Framework for Policy-based Admission Control March 1999 481 1. the message that generated the admission control request should be 482 processed further as usual, but an error message (or warning) be sent in 483 the other direction and include the policy objects supplied in that 484 error message 486 2. or, specifies that an error be returned, but the RSVP message should 487 not be forwarded as usual. 489 4.3. Interactions between PEP, LPDP, and PDP at a RSVP router 491 All the details of RSVP message processing and associated interactions 492 between different elements at an RSVP router (PEP, LPDP) and PDP are 493 included in separate documents [3,8]. In the following, a few, salient 494 points related to the framework are listed: 496 * LPDP is optional and may be used for making decisions based on pol- 497 icy elements handled locally. The LPDP, in turn, may have to go to 498 external entities (such as a directory server or an authentication 499 server, etc.) for making its decisions. 501 * PDP is stateful and may make decisions even if no policy objects 502 are received (e.g., make decisions based on information such as 503 flowspecs and session object in the RSVP messages). The PDP may 504 consult other PDPs, but discussion of inter-PDP communication and 505 coordination is outside the scope of this document. 507 * PDP sends asynchronous notifications to PEP whenever necessary to 508 change earlier decisions, generate errors etc. 510 * PDP exports the information useful for usage monitoring and 511 accounting purposes. An example of a useful mechanism for this pur- 512 pose is a MIB or a relational database. However, this document does 513 not specify any particular mechanism for this purpose and discus- 514 sion of such mechanisms is out of the scope of this document. 516 4.4. Placement of Policy Elements in a Network 518 A Framework for Policy-based Admission Control March 1999 520 By allowing division of labor between an LPDP and a PDP, the policy con- 521 trol architecture allows staged deployment by enabling routers of varying 522 degrees of sophistication, as far as policy control is concerned, to com- 523 municate with policy servers. Figure 4 depicts an example set of nodes 524 belonging to three different administrative domains (AD) (Each AD could 525 correspond to a different service provider in this case). Nodes A, B and 526 C belong to administrative domain AD-1, advised by PDP PS-1, while D and E 527 belong to AD-2 and AD-3, respectively. E communicates with PDP PS-3. In 528 general, it is expected that there will be at least one PDP per adminis- 529 trative domain. 531 Policy capable network nodes could range from very unsophisticated, such 532 as E, which have no LPDP, and thus have to rely on an external PDP for 533 every policy processing operation, to self-sufficient, such as D, which 534 essentially encompasses both an LPDP and a PDP locally, at the router. 536 AD-1 AD-2 AD-3 537 ________________/\_______________ __/\___ __/\___ 538 { } { } { } 539 A B C D E 540 +-------+ +-----+ +-------+ +-------+ +-------+ 541 | RSVP | | RSVP| | RSVP | | RSVP | | RSVP | 542 +----+ |-------| |-----| |-------| |-------| |-------| 543 | S1 |--| P | L |---| |----| P | L |----| P | P |----| P | +----+ 544 +----+ | E | D | +-----+ | E | D | | E | D | | E |----| R1 | 545 | P | P | | P | P | | P | P | | P | +----+ 546 +-------+ +-------+ +------+ +-------+ 547 ^ ^ ^ 548 | | | 549 | | | 550 | | +-------+ 551 | | | PDP | 552 | +------+ | |-------| 553 +-------->| PDP |<-------+ | | 554 |------| +-------+ 555 | | PS-2 556 +------+ 557 PS-1 559 Figure 4: Placement of Policy Elements in an internet 561 5. Example Policies, Scenarios, and Policy Support 563 In the following, we present examples of desired policies and scenarios 564 requiring policy control that should possibly be addressed by the policy 566 A Framework for Policy-based Admission Control March 1999 568 control framework. In some cases, possible approach(es) for achieving the 569 desired goals are also outlined with a list of open issues to be resolved. 571 5.1. Admission control policies based on factors such as Time-of-Day, User 572 Identity, or credentials 574 Policy control must be able to express and enforce rules with temporal 575 dependencies. For example, a group of users might be allowed to make 576 reservations at certain levels only during off-peak hours. In addition, 577 the policy control must also support policies that take into account iden- 578 tity or credentials of users requesting a particular service or resource. 579 For example, an RSVP reservation request may be denied or accepted based 580 on the credentials or identity supplied in the request. 582 5.2. Bilateral agreements between service providers 584 Until recently, usage agreements between service providers for traffic 585 crossing their boundaries have been quite simple. For example, two ISPs 586 might agree to accept all traffic from each other, often without perform- 587 ing any accounting or billing for the ``foreign'' traffic carried. How- 588 ever, with the availability of QoS mechanisms based on Integrated and Dif- 589 ferentiated Services, traffic differentiation and quality of service 590 guarantees are being phased into the Internet. As ISPs start to sell their 591 customers different grades of service and can differentiate among dif- 592 ferent sources of traffic, they will also seek mechanisms for charging 593 each other for traffic (and reservations) transiting their networks. One 594 additional incentive in establishing such mechanisms is the potential 595 asymmetry in terms of the customer base that different providers will 596 exhibit: ISPs focused on servicing corporate traffic are likely to experi- 597 ence much higher demand for reserved services than those that service the 598 consumer market. Lack of sophisticated accounting schemes for inter-ISP 599 traffic could lead to inefficient allocation of costs among different ser- 600 vice providers. 602 Bilateral agreements could fall into two broad categories; local or glo- 603 bal. Due to the complexity of the problem, it is expected that initially 604 only the former will be deployed. In these, providers which manage a net- 605 work cloud or administrative domain contract with their closest point of 606 contact (neighbor) to establish ground rules and arrangements for access 607 control and accounting. These contracts are mostly local and do not rely 608 on global agreements; consequently, a policy node maintains information 609 about its neighboring nodes only. Referring to Figure 4, this model 610 implies that provider AD-1 has established arrangements with AD-2, but not 611 with AD-3, for usage of each other's network. Provider AD-2, in turn, has 612 in place agreements with AD-3 and so on. Thus, when forwarding a reserva- 613 tion request to AD-2, provider AD-2 will charge AD-1 for use of all 614 resources beyond AD-1's network. This information is obtained by 616 A Framework for Policy-based Admission Control March 1999 618 recursively applying the bilateral agreements at every boundary between 619 (neighboring) providers, until the recipient of the reservation request is 620 reached. To implement this scheme under the policy control architecture, 621 boundary nodes have to add an appropriate policy object to the RSVP mes- 622 sage before forwarding it to a neighboring provider's network. This policy 623 object will contain information such as the identity of the provider that 624 generated them and the equivalent of an account number where charges can 625 be accumulated. Since agreements only hold among neighboring nodes, policy 626 objects have to be rewritten as RSVP messages cross the boundaries of 627 administrative domains or provider's networks. 629 5.3. Priority based admission control policies 631 In many settings, it is useful to distinguish between reservations on the 632 basis of some level of "importance". For example, this can be useful to 633 avoid that the first reservation being granted the use of some resources, 634 be able to hog those resources for some indefinite period of time. Simi- 635 larly, this may be useful to allow emergency calls to go through even dur- 636 ing periods of congestion. Such functionality can be supported by associ- 637 ating priorities with reservation requests, and conveying this priority 638 information together with other policy information. 640 In its basic form, the priority associated with a reservation directly 641 determines a reservation's rights to the resources it requests. For exam- 642 ple, assuming that priorities are expressed through integers in the range 643 0 to 32 with 32 being the highest priority, a reservation of priority, 644 say, 10, will always be accepted, if the amount of resources held by lower 645 priority reservations is sufficient to satisfy its requirements. In other 646 words, in case there are not enough free resources (bandwidth, buffers, 647 etc.) at a node to accommodate the priority 10 request, the node will 648 attempt to free up the necessary resources by preempting existing lower 649 priority reservations. 651 There are a number of requirements associated with the support of priority 652 and their proper operation. First, traffic control in the router needs to 653 be aware of priorities, i.e., classify existing reservations according to 654 their priority, so that it is capable of determining how many and which 655 ones to preempt, when required to accommodate a higher priority reserva- 656 tion request. Second, it is important that preemption be made con- 657 sistently at different nodes, in order to avoid transient instabilities. 658 Third and possibly most important, merging of priorities needs to be care- 659 fully architected and its impact clearly understood as part of the associ- 660 ated policy definition. 662 Of the three above requirements, merging of priority information is the 663 more complex and deserves additional discussions. The complexity of merg- 664 ing priority information arises from the fact that this merging is to be 665 performed in addition to the merging of reservation information. When 667 A Framework for Policy-based Admission Control March 1999 669 reservation (FLOWSPEC) information is identical, i.e., homogeneous reser- 670 vations, merging only needs to consider priority information, and the sim- 671 ple rule of keeping the highest priority provides an adequate answer. 672 However, in the case of heterogeneous reservations, the * two-dimensional 673 nature} of the (FLOWSPEC, priority) pair makes their ordering, and there- 674 fore merging, difficult. A description of the handling of different cases 675 of RSVP priority objects is presented in [7]. 677 5.4. Pre-paid calling card or Tokens 679 A model of increasing popularity in the telephone network is that of the 680 pre-paid calling card. This concept could also be applied to the Internet; 681 users purchase ``tokens'' which can be redeemed at a later time for access 682 to network services. When a user makes a reservation request through, say, 683 an RSVP RESV message, the user supplies a unique identification number of 684 the ``token'', embedded in a policy object. Processing of this object at 685 policy capable routers results in decrementing the value, or number of 686 remaining units of service, of this token. 688 Referring to Figure 4, suppose receiver R1 in the administrative domain 689 AD3 wants to request a reservation for a service originating in AD1. R1 690 generates a policy data object of type PD(prc, CID), where ``prc'' denotes 691 pre-paid card and CID is the card identification number. Along with other 692 policy objects carried in the RESV message, this object is received by 693 node E, which forwards it to its PEP, PEP_E, which, in turn, contacts PDP 694 PS-3. PS-3 either maintains locally, or has remote access to, a database 695 of pre-paid card numbers. If the amount of remaining credit in CID is suf- 696 ficient, the PDP accepts the reservation and the policy object is returned 697 to PEP_E. Two issues have to be resolved here: 699 * What is the scope of these charges? 701 * When are charges (in the form of decrementing the remaining credit) 702 first applied? 704 The answer to the first question is related to the bilateral agreement 705 model in place. If, on the one hand, provider AD-3 has established agree- 706 ments with both AD-2 and AD-1, it could charge for the cost of the com- 707 plete reservation up to sender S1. In this case PS-2 removes the 708 PD(prc,CID) object from the outgoing RESV message. 710 On the other hand, if AD-3 has no bilateral agreements in place, it will 711 simply charge CID for the cost of the reservation within AD-3 and then 712 forward PD(prc,CID) in the outgoing RESV message. Subsequent PDPs in other 713 administrative domains will charge CID for their respective reservations. 715 A Framework for Policy-based Admission Control March 1999 717 Since multiple entities are both reading (remaining credit) and writing 718 (decrementing credit) to the same database, some coordination and con- 719 currency control might be needed. The issues related to location, manage- 720 ment, coordination of credit card (or similar) databases is outside the 721 scope of this document. 723 Another problem in this scenario is determining when the credit is 724 exhausted. The PDPs should contact the database periodically to submit a 725 charge against the CID; if the remaining credit reaches zero, there must 726 be a mechanism to detect that and to cause revocation or termination of 727 privileges granted based on the credit. 729 Regarding the issue of when to initiate charging, ideally that should hap- 730 pen only after the reservation request has succeeded. In the case of local 731 charges, that could be communicated by the router to the PDP. 733 5.5. Sender Specified Restrictions on Receiver Reservations 735 The ability of senders to specify restrictions on reservations, based on 736 receiver identity, number of receivers or reservation cost might be useful 737 in future network applications. An example could be any application in 738 which the sender pays for service delivered to receivers. In such a case, 739 the sender might be willing to assume the cost of a reservation, as long 740 as it satisfies certain criteria, for example, it originates from a 741 receiver who belongs to an access control list (ACL) and satisfies a limit 742 on cost. (Notice that this could allow formation of "closed" multicast 743 groups). 745 In the policy based admission control framework such a scheme could be 746 achieved by having the sender generate appropriate policy objects, carried 747 in a PATH message, which install state in routers on the path to 748 receivers. In accepting reservations, the routers would have to compare 749 the RESV requests to the installed state. 751 A number of different solutions can be built to address this scenario; 752 precise description of a solution is beyond the scope of this document. 754 6. Interaction Between the Policy Enforcement Point (PEP) and the Policy 755 Decision Point (PDP) 757 In the case of an external PDP, the need for a communication protocol 758 between the PEP and PDP arises. In order to allow for interoperability 759 between different vendors networking elements and (external) policy 760 servers, this protocol should be standardized. 762 6.1. PEP to PDP Protocol Requirements 764 A Framework for Policy-based Admission Control March 1999 766 This section describes a set of general requirements for the communication 767 protocol between the PEP and an external PDP. 769 * Reliability: The sensitivity of policy control information necessi- 770 tates reliable operation. Undetected loss of policy queries or 771 responses may lead to inconsistent network control operation and are 772 clearly unacceptable for actions such as billing and accounting. One 773 option for providing reliability is the re-use of the TCP as the 774 transport protocol. 776 * Small delays: The timing requirements of policy decisions related to 777 QoS signaling protocols are expected to be quite strict. The PEP to 778 PDP protocol should add small amount of delay to the response delay 779 experienced by queries placed by the PEP to the PDP. 781 * Ability to carry opaque objects: The protocol should allow for 782 delivery of self-identifying, opaque objects, of variable length, 783 such as RSVP messages, RSVP policy objects and other objects that 784 might be defined as new policies are introduced. The protocol should 785 not have to be changed every time a new object has to be exchanged. 787 * Support for PEP-initiated, two-way Transactions: The protocol must 788 allow for two-way transactions (request-response exchanges) between a 789 PEP and a PDP. In particular, PEPs must be able to initiate requests 790 for policy decision, re-negotiation of previously made policy deci- 791 sion, and exchange of policy information. To some extent, this 792 requirement is closely tied to the goal of meeting the requirements 793 of RSVP-specific, policy-based admission control. RSVP signaling 794 events such as arrival of RESV refresh messages, state timeout, and 795 merging of reservations require that a PEP (such as an RSVP router) 796 request a policy decision from PDP at any time. Similarly, PEP must 797 be able to report monitoring information and policy state changes to 798 PDP at any time. 800 * Support for asynchronous notification: This is required in order to 801 allow both the policy server and client to notify each other in the 802 case of an asynchronous change in state, i.e., a change that is not 803 triggered by a signaling message. For example, the server would need 804 to notify the client if a particular reservation has to be terminated 805 due to expiration of a user's credentials or account balance. Like- 806 wise, the client has to inform the server of a reservation rejection 807 which is due to admission control failure. 809 A Framework for Policy-based Admission Control March 1999 811 * Handling of multicast groups: The protocol should provision for han- 812 dling of policy decisions related to multicast groups. 814 * QoS Specification: The protocol should allow for precise specifica- 815 tion of level of service requirements in the PEP requests forwarded 816 to the PDP. 818 7. Security Considerations 820 The communication tunnel between policy clients and policy servers should 821 be secured by the use of an IPSEC [4] channel. It is advisable that this 822 tunnel makes use of both the AH (Authentication Header) and ESP (Encapsu- 823 lating Security Payload) protocols, in order to provide confidentiality, 824 data origin authentication, integrity and replay prevention. 826 In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authen- 827 tication can be used to secure communications between network elements. 829 8. References 831 [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSer- 832 Vation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205, 833 September 1997. 835 [2] F. Baker., "RSVP Cryptographic Authentication", draft-ietf-rsvp-md5- 836 05.txt, August 1997. 838 [3] S. Herzog., "RSVP Extensions for Policy Control", Internet Draft}, 839 draft-ietf-rsvp-policy-ext-03.[ps,txt], August 1998. 841 [4] R. Atkinson. Security Architecture for the Internet Protocol. RFC1825, 842 Aug. 1995. 844 [5] C. Rigney, A Rubens, W. Simpson and S. Willens. Remote Authentication 845 Dial In User Service (RADIUS). RFC 2138. 847 [6] R. Rajan et al. Schema for Differentiated Services and Integrated Ser- 848 vices in Networks, draft-rajan-policy-qosschema-00.txt, October 1998. 850 [7] S. Herzog, "RSVP Preemption Priority Policy", Internet Draft, draft- 851 ietf-rap-priority-00.txt, Nov. 1998. 853 [8] S. Herzog, "COPS Usage for RSVP", Internet Draft, draft-ietf-rap- 855 A Framework for Policy-based Admission Control March 1999 857 cops-rsvp-00.txt, August 1998. 859 8. Acknowledgements 861 This is a result of an ongoing discussion among many members of the RAP 862 group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai 863 Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry. 865 9. Authors` Addresses 867 Raj Yavatkar 868 Intel Corporation 869 2111 N.E. 25th Avenue, 870 Hillsboro, OR 97124 871 USA 872 phone: +1 503-264-9077 873 email: raj.yavatkar@intel.com 875 Dimitrios Pendarakis 876 IBM T.J. Watson Research Center 877 P.O. Box 704 878 Yorktown Heights 879 NY 10598 880 phone: +1 914-784-7536 881 email: dimitris@watson.ibm.com 883 Roch Guerin 884 University of Pennsylvania 885 Dept. of Electrical Engineering 886 200 South 33rd Street 887 Philadelphia, PA 19104 889 phone: +1 215 898-9351 890 email: guerin@ee.upenn.edu