idnits 2.17.1 draft-ietf-policy-req-02.txt: 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: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 122 lines 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 363 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 15 has weird spacing: '...This document...' == Line 17 has weird spacing: '...are working ...' == Line 18 has weird spacing: '...as, and its ...' == Line 19 has weird spacing: '...groups may al...' == Line 22 has weird spacing: '...months and m...' == (358 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 9, 2000) is 8568 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) == Unused Reference: 'TERMS' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'TERMINOLOGY' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'COPS' is defined on line 832, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Normative reference to a draft: ref. 'TERMINOLOGY' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: A later version (-08) exists of draft-ietf-policy-core-info-model-03 -- Possible downref: Normative reference to a draft: ref. 'POLFRAME' Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Hugh Mahon 2 Expiration: May 2001 Hewlett-Packard 3 File: draft-ietf-policy-req-02.txt Yoram Bernet 4 Microsoft 5 Shai Herzog 6 IP Highway 7 John Schnizlein 8 Cisco Systems 9 November 9, 2000 11 Requirements for a Policy Management System 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. Internet-Drafts 17 are working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as ``work 25 in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Abstract 39 This document describes why policy based management is interest- 40 ing to people managing IT environments and what is needed to make 41 policy management address those interests. Work to date is 42 described, as well as usage cases demonstrating how policy-based 43 management would actually work. 45 The goal for this document is to provide a set of requirements 46 for further development of standards for policy management sys- 47 tems. There has already been work in the area of policy manage- 48 ment and the work to date is described as well as additional 49 areas to be defined. 51 This document is the result of discussions, e-mail, and other 52 communications within the Policy Framework Working Group and 53 among individuals. 55 Table of Contents 57 1. Introduction ......................................... 2 58 2. QoS Policy usage ..................................... 5 59 2.1 Voice ............................................... 5 60 2.2 Protected classes of traffic ........................ 6 61 2.3 Guaranteed Transfer Time ............................ 7 62 2.4 Policy and Services ................................. 7 63 3. Usage Cases .......................................... 8 64 3.1 Simple Usage Case ................................... 8 65 3.1.1 Simple Usage Case in an ISP Environment ........... 8 66 3.1.2 Simple Usage Case in an Enterprise Environment .... 9 67 3.1.3 Simple Usage Case - Steps to Implement ............ 10 68 3.1.3 Simple Usage Case Requirements .................... 11 69 3.1 Complex Usage Case .................................. 12 70 3.1 Complex Usage Case - Requirements ................... 13 71 4. Security Considerations .............................. 13 72 5. Summary .............................................. 14 73 6. Intellectual Property ................................ 15 74 7. References ........................................... 16 75 8 Acknowledgements ...................................... 17 76 9. Author Information ................................... 17 77 10. Full Copyright Statement ............................ 18 79 1. Introduction 81 Policy based management has generated a lot of buzz in the 82 industry lately. Unfortunately hype can create unrealistic 83 expectations. While Policy Based Management won't solve all 84 problems, or make IT administration a trivial task, there is a 85 real need for Policy Based Management. So why are people 86 interested in Policy Based Management? 87 Policy is essentially a matter of allocating resources in 88 terms of business decisions. It is the translation between 89 business terms and the configuration details necessary to pro- 90 duce those resource allocations that distinguishes policy man- 91 agement from configuration management. 93 Internet technology based networks are being used for more 94 functions and by more businesses. Their ability to do busi- 95 ness is affected by the health and abilities of their net- 96 works. 98 As networks grow the amount of things that need to be managed 99 grows. Not only are there more devices to be managed, but 100 also the number of kinds of things (e.g., capabilities, ser- 101 vices, types of interfaces, etc.) is growing. As more kinds 102 of things are introduced, so are more management interfaces 103 the IT administrators must learn and use to manage the envi- 104 ronment. In addition, many of those management tools work 105 with individual devices, so that an administrator must dupli- 106 cate the actions used to manage (configure) one device for 107 each other device, even if they are the same type of device 108 from the same vendor. The problem is exacerbated if the 109 devices are from different vendors, since they must perform 110 different tasks to manage similar capabilities. The same 111 problem exists not just for networking, but for just about 112 anything an IT administrator may need to manage. 114 In response to this situation, customers (IT administrators) 115 have for many years been asking vendors for tools which better 116 address their needs in managing such large and dynamic envi- 117 ronments. Their list of desired features includes: 119 - centralized management 120 - abstracted (or simplified) management data 121 - commonality across devices 122 - automation of management tasks 123 - fewer interfaces 124 - consistency across interfaces 126 Centralized management requires the ability to perform manage- 127 ment tasks via the network. Scalability factors into the 128 requirements since a centralized system is not practical if it 129 doesn't scale well to fit the management needs in the environ- 130 ment. 132 Abstracted (or simplified) management data fits with the fewer 133 interfaces objective by abstracting the functions and decision 134 criteria across multiple devices, lending itself to the next 135 desired feature, commonality across devices. 137 There are two aspects to commonality: the ability to learn how 138 to do something once and apply that across multiple things of 139 the same kind, and the ability to use the same data, not just 140 similar data, across multiple things. By using the same con- 141 figuration across multiple devices, the administrator can 142 achieve consistent behavior in the managed environment and 143 reduce, or better yet eliminate, duplication of efforts. It 144 is this desire to use the same data across multiple devices 145 that is behind the desire to have fewer interfaces. 147 Automation of management tasks is the feature that causes a 148 change from most implementations of management tools with 149 existing technologies (e.g., SNMP). One aspect of automation 150 is the desire of customers to be able to re-use management 151 data where that re-use makes sense, and for the tools to sup- 152 port such re-use. In other words, wherever possible, the 153 tools support management information re-use, and do not 154 require the administrator to duplicate information already in 155 the management system, and can automatically get the informa- 156 tion where it needs to go and when it is needed rather than 157 require additional intervention by the human administrator. 158 Automation is also key in allowing the network to operate with 159 a minimum of human intervention (once the human administrators 160 have specified, through management data, how the environment 161 is to behave under given circumstances). 163 The key to providing a solution for these requirements is the 164 data used to manage the environment; what that data repre- 165 sents, how it gets from the administrator to what the data 166 affects, and the functionality that supports reuse and automa- 167 tion. 169 That data has been called 'policy'. Policy Based Management 170 is the term used to describe the technologies that address the 171 customer requirements described above. 173 In support of the above features, the efforts for defining 174 Policy Based Management have focused on the data representa- 175 tion and properties of a repository for that information. 177 The use of a repository is important to support reusability of 178 data across managed things, as well as allowing an administra- 179 tor to edit existing management data (both are forms of 180 reuse). In addition to being stored in a repository, the data 181 must get to where it will be used (this supports the require- 182 ments of centralized management and automation). (Information 183 distributed from a centralized repository also aids in consis- 184 tency of information throughout the managed environment.) 186 With common policy information the administrator can use the 187 same information to configure devices which are supposed to do 188 the same thing (addressing centralized management, commonality 189 across devices, and reducing the number of interfaces required 190 for multiple devices from different vendors). This policy 191 information can also be abstracted to a higher level, since it 192 will need to be device independent. 194 Common information does not require a common format (i.e., 195 schema). In other words, it is possible to have common infor- 196 mation for QoS management, and common information for security 197 uses, but have completely different formats for the different 198 uses of data. This would cause a duplication of information 199 that could be common (e.g., user information use for access 200 control), and so would be a bad thing because it would lead to 201 greater differences between disciplines than necessary. 202 Therefore, a common format is another requirement to support 203 the desire for automation and fewer interfaces. 205 To summarize the above: centralized management leads to the 206 need for a repository; scalability requires a means to commu- 207 nicate the data beyond the repository; abstraction requires a 208 common information model; automation requires the abstraction 209 and components to perform actions based on management data and 210 real-time inputs. 212 The rest of this document describes what is necessary to make 213 a policy-based management system work. 215 2. QoS Policy usage 217 The focus of this draft is on the requirements of policy, with 218 an emphasis on network Quality of Service. 220 Policy control of data (packet) networks coincides with the 221 convergence of voice (and video) calling and business-critical 222 communications with interconnected local area networks (LANs). 223 A strong motivation for users is to protect these forms of 224 communication that are less tolerant of potential delays and 225 congestion than applications usually using in packet networks. 226 Because the application of policy implies unequal treatment, 227 adequate authorization for allocations is essential. 229 2.1. Voice 231 Voice over IP requires special network allocations to 232 ensure reasonable quality. Whether using int-serv [RFC 233 1633] or diff-serv [RFC 2475], priority queuing and traffic 234 shaping are required for real-time traffic. Policy speci- 235 fies how much of the network is allocated to this real-time 236 traffic and which calls are authorized to use this alloca- 237 tion. This policy, in conjunction with traffic engineer- 238 ing, determines the configuration of queue schedulers and 239 traffic policers across a variety of network devices. 241 Because calling parties might connect at different places 242 in the network (unlike plain-old telephone service (POTS) 243 but not roam like cellular mobility), binding personal 244 authorization to which devices to be configured depends on 245 the process resolving personal locations within the network 246 topology. This binding between user identity and location 247 is outside the policy system, but might depend on policy to 248 determine what locations are authorized. Configuration 249 depends on the interaction between calling authorization, 250 location, and the details of network capacity at that loca- 251 tion. Since this interaction is more dynamic than policy, 252 separate processes in the configuration environment are 253 suggested. 255 If the capacity for real-time calls is less than the poten- 256 tial level authorized, some scheduling process, at least 257 call admission control (CAC), is also required. Since CAC 258 is likely to be even more dynamic than station mobility, a 259 process separate from the configuration process above is 260 suggested. RSVP [RFC 2205] anticipates that policy, in 261 addition to local network capacity, will determine CAC for 262 int-serv. Capacity allocation for CAC must be local 263 because availability or congestion is only meaningful for 264 individual links (or queues). 266 To summarize: Configuration for real-time (voice) calls 267 requires the interaction of policy, traffic engineering, 268 user identity, and location. Call admission control 269 requires all of this plus accounting for local resources 270 along the path of the call. 272 2.2. Protected classes of traffic 274 Fear that traffic for critical applications might be dis- 275 placed by less important traffic when both share the same 276 network motivates interest in policy networking. As a mat- 277 ter of implementation, the only way to protect one class of 278 traffic from the load applied from another class is to 279 queue them separately. Each class must then be allocated a 280 share of the output link capacity. This also has the advan- 281 tage that each class is protected from the others, which is 282 impossible with priority or precedence approaches; even a 283 class allocated a small share will not be affected by loads 284 in other classes. Priority appears to reflect business 285 interests, "But priority is an implementation mechanism, 286 not a service model." [RFC 1633] Resolving ordering effects 287 among multiple levels of priority also complicates an 288 already difficult problem of resolving potential conflicts 289 within a set of policy constraints. 291 Because queues can be scarce resources in network devices, 292 policy should control their allocation and which traffic 293 sources use which queues. Traffic engineering influences 294 the allocation of traffic classes to queues because queues 295 are necessary only where bottlenecks cause congestion. This 296 interaction between traffic engineering and policy is 297 slightly different than their interaction for real-time 298 traffic; policy creation should be constrained by the abil- 299 ity of the network to protect different traffic classes. 300 Where call admission is analogous to program-language run- 301 time, and configuration is analogous to compile-time, the 302 availability of class separation is analogous to semanti- 303 cally-constrained editing of policy entry. 305 In many cases, traffic rates from server to client are so 306 much larger than from client to server that classification 307 of protected traffic can be made on the basis of server 308 addresses, which are authenticated and authorized over long 309 time periods. Sometimes, it may be necessary to include 310 client authorization beyond what the application performs. 311 Client authorization could interact with policy to imply 312 configuration changes on a time-scale (comparable to user 313 mobility above), or individual sessions on a multi-user 314 (host) client (comparable to admission control above). 316 2.3. Guaranteed Transfer Time 318 The business-level specification of quality is often in 319 terms much larger than suitable for configuration, even 320 through consistency resolution and translation from policy. 321 An application that demands transfer of a known (approxi- 322 mately) volume of data within a specified time is attrac- 323 tive for archival storage and content distribution. The 324 value of this application justifies scheduling classes of 325 traffic with capacity configurations across the path of the 326 transfer. This application requires (time of day) schedul- 327 ing along with the same requirements as for protected 328 classes. 330 2.4. Policy and Services 332 Policy management is often discussed in terms of the ser- 333 vices that are supported via policy. There are different 334 kinds and levels of information required when managing a 335 networked environment. Service management is a relatively 336 high level view of a system. Many drafts discuss an 337 "Olympic" service, in which there are multiple levels of 338 service, for example: Bronze, Silver, and Gold. In such 339 discussions Gold is better than Silver, and Silver is bet- 340 ter than Bronze. When actually describing the meaning of 341 the service, though, things become more complex. 343 Policy is used to implement services in an environment. 344 But policy information may not be the only representation 345 of the service characteristics. Services may be described 346 in a manner that is higher-level than policy itself; that 347 is, services may be described in a form that describes 348 characteristics from which policy information is then 349 derived. Such a higher level representation may be 350 required to perform some functions in a managed environ- 351 ment. For example, different policies which describe dif- 352 ferent behaviors may be deployed to two entities traversed 353 by a customer's traffic. It may be impossible to tell if a 354 conflict exists simply by looking at the policies them- 355 selves, but it may be possible to determine if a conflict 356 exists with the service(s) to which the customer has sub- 357 scribed. 359 Service descriptions are beyond the scope of this draft, 360 but the distinction between services and policies is an 361 important one when discussing what information is used in a 362 management system, and what the administrator needs to know 363 in order to create and deploy policies. 365 3. Usage Cases 367 Building on the discussion in section 2, two usage cases will 368 be described. 370 3.1. Simple Usage Case 372 A customer, Joe, has subscribed for Gold service. For this 373 example Gold service will simply mean that Joe has higher 374 priority than customers who subscribed for Silver or Bronze 375 service levels. What needs to happen in order for Joe to 376 receive the service to which he is subscribed? 378 This example will be shown in two contexts: an ISP environ- 379 ment and an enterprise environment. 381 3.1.1. Simple Usage Case in an ISP Environment 383 The ISP management personnel must configure the environ- 384 ment to support the Gold, Silver, and Bronze services. 385 Within the core of the network this can be accomplished 386 by putting in place policies which cause the devices to 387 examine the DiffServ mark on the packet and then treat 388 the traffic appropriately. These policies do not change 389 frequently because they are not associated with specific 390 customers. The more difficult part is to have the traf- 391 fic appropriately marked. 393 Since Joe is signed up for the service, the RADIUS 394 server could be configured to have the POP at which Joe 395 usually logs in assign Joe a known address when he logs 396 in. With a known IP address the administrator can 397 author a policy which references Joe's IP address and 398 marks traffic coming from that address as Gold service 399 traffic. This policy would then be deployed to Joe's 400 POP. 402 In order for any traffic going to Joe's system to 403 receive Gold treatment, that traffic must also be marked 404 appropriately. This means that policy must be deployed 405 to the edge devices so that they will mark traffic going 406 to Joe's system to receive Gold service. This is accom- 407 plished by deploying policies to edge devices. These 408 edge policies cause packets going to Joe's address to be 409 marked so that they receive Gold service treatment. 410 This would also be done on internal routers or switches 411 to which the ISP's servers (e.g., mail or news servers) 412 are attached so that traffic internal to the ISP is also 413 appropriately marked. 415 Customers like Joe want to be able to see if they are 416 getting the service they have paid the service provider 417 for. Service providers should provide the tools which 418 allow their customers to see information relevant to 419 each customer's service. Such tools are beyond the 420 scope of this document. 422 3.1.2. Simple Usage Case in an Enterprise Environment 424 As in the ISP example above, the corporate IT adminis- 425 trators will need to configure the core to handle the 426 different services offered to users of the corporate 427 network. The difference is in how the user's traffic is 428 marked to receive the desired service. 430 One way for the traffic to be marked is for Joe to have 431 a fixed IP address. The policies would then be written 432 to recognize Joe's address and treat the traffic coming 433 to and from that address appropriately. 435 A second way for the traffic to be marked correctly is 436 that when Joe's computer is connected to the network the 437 DHCP system recognizes that it is Joe's computer, or 438 that it is a computer to which Gold service is to be 439 provided, and thus notifies another management component 440 of the event. This causes a policy to be deployed (or 441 more likely causes an existing policy to be modified) 442 that will mark the traffic to and from Joe's computer as 443 receiving Gold service. 445 A third way for the traffic to be marked correctly is to 446 have a sequence of events be started when Joe logs into 447 the system. This would notify a central authority which 448 would cause the traffic to be marked to receive Gold 449 service. 451 Yet a fourth way would be to have policy deployed to the 452 end systems themselves. When Joe uses an application 453 that generates traffic the networking stack on that sys- 454 tem would mark Joe's traffic appropriately. 456 For all of these approaches, the network devices would 457 also need to be configured to appropriately mark traffic 458 going to Joe's system so that it gets the desired treat- 459 ment. As can be seen, an environment with totally 460 dynamic address assignment would require dynamic config- 461 uration changes in order to support QoS. Signaling 462 addresses some of these issues, but introduces other 463 issues as well. 465 Each of these approaches has advantages and disadvan- 466 tages. Approaches two and three are the most complex 467 and would require more elaborate management systems than 468 approaches one and four. The fourth approach is the 469 only method described which addresses policy associated 470 with an individual user that would work with a multi- 471 user system. However, the problem of solving marking 472 traffic going to Joe on system X, and treating the traf- 473 fic going to other users on system X, is not solved 474 here. 476 As in the ISP example above, knowledgeable users of the 477 network in the enterprise like to be able to review the 478 services they are receiving. 480 3.1.3. Simple Usage Case - Steps to Implement 482 In order to implement the policy discussed above, the 483 administrator must enter new policy (or edit old pol- 484 icy). Some interface, whose specification is beyond the 485 scope of this document, is used to accomplish this task. 486 This interface then delivers the policy information to a 487 repository. At this step other functions may be per- 488 formed, such as validation, verification, conflict 489 detection, etc. The Policy Consumers (see [POLFRAME]) 490 associated with the interfaces to which the policy 491 applies will be notified that the policy has changed (or 492 is newly available). The Policy Consumers will receive 493 the policy information and transform it into a form 494 suitable for the device. During this step the Policy 495 Consumer will use information about the Policy Target to 496 perform the information transformation. Note that noth- 497 ing is being stated about the architecture of the Policy 498 Consumer or Policy Target. They may be integral, dis- 499 tributed, or in whatever form will accomplish receiving 500 policy information and implementing the behaviors 501 described by the policy information. 503 3.1.4. Simple Usage Case Requirements 505 Now let's look at what happened in the above example and 506 see what is necessary to support it. 508 At least two policies would be written in this case. 509 One is to configure the core devices. In this example a 510 single policy could be written which specifies priority 511 treatment based on DSCP values. The other policy would 512 be to configure the RADIUS server to assign an IP 513 address for Joe. A third policy may be required so that 514 the devices at the POP recognize Joe's IP address and 515 give his traffic the appropriate DSCP mark. The third 516 policy (which could be an action on the RADIUS policy) 517 would require dynamic reconfiguration in real-time in 518 order to provide appropriate service to the user in a 519 timely manner. 521 In order to perform these tasks the administrator will 522 need to enter or edit policy and have it stored in a 523 central repository. The policy would then be sent to 524 the appropriate devices which must carry out the opera- 525 tions specified by the policies. The administrator 526 would need to be able to associate the policies with the 527 devices in some way. The interface the administrator 528 uses for policy administration is beyond the scope of 529 this document, but there must be a standardized inter- 530 face for inserting into and retrieving policy informa- 531 tion from the repository. 533 The next step is the repository. The actual repository 534 must be able to support the structured nature of policy 535 information, and support insert, search, and retrieval. 536 The key aspect of the repository is its network accessi- 537 bility. So far LDAP is the stand out example meeting 538 this requirement. However, the environment described 539 above is dynamic. Policy can be, and should be, rela- 540 tively static. But when the administrator makes changes 541 in policy, especially to address an existing problem in 542 the network or to correct an incorrect policy, those 543 changes may need to be propagated quickly. This is best 544 done via notification rather than polling. LDAP cur- 545 rently does not provide a notification to LDAP clients 546 of changes. 548 There may be other functionality which is logically 549 associated with the repository. This functionality may 550 address the notification requirements, and may also con- 551 tribute to the desire to have validation, verification, 552 and conflict detection performed on new or modified pol- 553 icy information. 555 The next requirement is the transformation of policy 556 information into device information, followed by the 557 features in the device to enforce policy. 559 In addition is the need to address policy which is 560 referring to a moving or changing set of needs, primar- 561 ily users moving around in the network. This issue will 562 only grow in importance. The issue arises not just 563 because the origin of the traffic is moving, but the 564 destination, meaning that more points in the network 565 must be made aware that traffic going to that destina- 566 tion should receive a particular treatment. 568 3.2. Complex Usage Case 570 A more complex usage case would involve managing a particu- 571 lar kind of traffic across the network. For example, say 572 that a corporate IT group decides that no more than 40% of 573 all network traffic can be video. This will further be 574 defined that over any link the traffic can only take up to 575 40% of the bandwidth of that link. 577 This presents many different problems to be solved. Traf- 578 fic identification is a necessary component in order to 579 enforce policy of this type, but such identification is 580 beyond the scope of this draft. The ability to specify 581 conditions which are used to identify traffic is a require- 582 ment for policy itself. 584 One way is to use signaling via RSVP to identify traffic. 585 But this may not always be feasible, especially in this 586 example where the intent is not to guarantee a QoS for the 587 video traffic, but to limit its use of the corporate net- 588 work bandwidth. Those who are generating video traffic may 589 not always want to have their traffic identified as video, 590 and so using a signal may be avoided. 592 The traffic must be identifiable and must be able to be 593 specified in conditions used within the policy rule. 595 Policies would be deployed in the core and at the edges of 596 the network to enforce the utilization limits. The need in 597 the core is that multiple flows from different sources with 598 different destinations may end up traversing the same link. 599 Per the definition above, their aggregate bandwidth usage 600 can be no more than 40% on any link, so the policing must 601 occur everywhere. 603 For this example consider a simple policing action type 604 which limits bandwidth usage. This action may use shaping 605 or dropping to police the traffic to ensure it doesn't take 606 more than the permitted bandwidth. Because of this 607 restriction, traffic would end up with no more bandwidth 608 than 40% of the slowest link it traverses. Issues of jit- 609 ter and latency should be addressed in some form, possibly 610 by other action types deployed to the same interfaces. 612 This leads to another topic that must be resolved for a 613 usable policy system: the interaction and relationships 614 between multiple policy rules, particularly of different 615 types, on a single managed entity. For example, how to 616 express policy rules in a way that is obvious to the admin- 617 istrator and device/policy translator that multiple actions 618 are to be taken and are to work together? Later revisions 619 of this draft will include examples in this area. 621 Either the policy management system must have information 622 about the bandwidth abilities of each link, or the Policy 623 Consumers (which convert policy into device information) 624 must be able to translate percentage into device specific 625 values. 627 3.3. Complex Usage Case - Requirements 629 As with the simple usage case, there must be: 631 - A standard interface to the policy repository. 632 - Network access to the policy repository. 633 - A way to notify components which use policy that 634 there is new or modified policy. 635 - A way to transform the policy information to a 636 form usable by devices. 637 - Mechanisms to enforce policy on network traffic. 639 In addition, this example points out the need for well 640 defined semantic relationships between multiple policies 641 and/or rules within the same policy, especially if they are 642 of different action types. 644 4. Security Considerations 646 For QoS related Policy, the security needs of a Policy Manage- 647 ment System require authentication at a minimum. 649 The Policy Management System contains components which send 650 messages and read and write data. 652 The interactions which involve writing of data MUST ensure 653 authentication of both parties. In other words, when a Policy 654 Consumer connects to a Policy Management Repository, in which 655 the Policy Consumer writes status and configuration informa- 656 tion to the Policy Management Repository, the Policy Consumer 657 must authenticate itself to the Policy Management Repository, 658 and vice-versa. The reason for this is that either end of the 659 communication could be false. If a true Policy Consumer wrote 660 data to a false Policy Management Repository, the Administra- 661 tor will not see the true data. If a false Policy Consumer 662 wrote data to a true Policy Management Repository, the Admin- 663 istrator will see false data. Either situation means that the 664 Administrator does not know the true state of Policy configu- 665 ration in the networked environment. Similar requirements 666 exist for the connection of the Policy UI to the Policy Repos- 667 itory and Policy Management Repository. 669 Authentication also allows ensuring the party is authorized to 670 perform the actions taken (reading and/or writing policy and 671 status information). 673 There is need to limit access (either read or write) to por- 674 tions of the policy information (and status information). The 675 policy management system (or data repository if it is to be 676 accessed directly rather than through the policy management 677 system) must allow establishing multiple users (or identities) 678 in order to allow authorization of which subsets of the infor- 679 mation the user (or component) is allowed to access. 681 Policy information should also be shipped with information 682 verifying its integrity, that is, demonstrating that it has 683 not been tampered with during transit from a trusted server or 684 client. 686 When Policy is used for security purposes, it MUST be 687 encrypted when being transported over the network. 689 Repositories must be as secure as reasonably possible. If a 690 Repository resides on a general purpose host, access to the 691 Repository data should be controlled and monitored. If the 692 data cannot be so secured, other means, such as encryption of 693 data in the repository, or other methods ensuring integrity 694 should be employed. 696 5. Summary 698 Policy Based Management is not just a buzz word, or a solution 699 looking for a problem. There is a genuine need for allowing 700 network Administrators to be more effective by managing the 701 network as a collective, not as a collection of individual 702 devices each requiring a separate set of knowledge. 704 Today's tools allow Administrators to configure the devices 705 which enable traffic, but the view they present to Administra- 706 tors is limited, and the management of a device is the focus 707 of the activities with those tools. 709 Policy information, as described in [INFOMODEL] allows that 710 abstraction, but additional information is needed to make Pol- 711 icy useful. Information such as the targets of Policy, 712 attributes about those targets, and the association between 713 Policy and the targets must be further defined. 715 Additionally, the actual architecture of a Policy Management 716 System must be further defined in order to allow multiple ven- 717 dors to have interoperable implementations. The details of 718 such an architecture include making the Policy information 719 available in a timely manner, and providing the Administrator 720 (and, in the future, tools) with information about the charac- 721 teristics of Policy Targets in order to allow validation of 722 Policy and conflict detection. Additionally, Administrators 723 need to know if Policy deployment was successful in order to 724 know if the network will work as expected so they don't have 725 to wait for users of the network to tell them there's a prob- 726 lem. 728 New requirements not already documented elsewhere are also 729 documented here, such as security, and timely delivery of Pol- 730 icy Data. 732 Another requirement which is probably best addressed through a 733 combination of data organization, techniques, and architec- 734 ture, is that of dealing with a mobile (dynamic) set of 735 clients. 737 To finish the summation of this document, below are bullet 738 lists of the requirements of a Policy Management System. The 739 items marked with an asterisk are yet to be fully defined. 741 Policy Data 743 - A way to state actions to be taken by the policy managed 744 entity 745 - A way to specify under what conditions the above actions 746 are to take place 747 - A way to specify to what the policy (combination of action 748 and prerequisite conditions) pertains or is to control * 749 - Status information about the policy managed entity * 750 - Properties of policy managed entity describing capabilities * 751 - Semantic relationship of policy actions, both of same 752 action type and dissimilar action types. * 753 - Security information (integrity, authentication, etc.) * 754 - A way to limit access to policy contents based on security 755 information. 757 The following are tentative derivations from the requirements 758 to be considered further. 760 - Policy repository communication (e.g., LDAP) 761 - Policy repository (may be settled by above 762 question, e.g., if communication is LDAP) 763 - Notification to Policy Consumer of new/changed 764 policy * 765 - Versioning of Policy Data * 766 - Status reporting mechanism * 768 6. Intellectual Property 770 The IETF takes no position regarding the validity or scope of 771 any intellectual property or other rights that might be 772 claimed to pertain to the implementation or use of the tech- 773 nology described in this document or the extent to which any 774 license under such rights might or might not be available; 775 neither does it represent that it has made any effort to iden- 776 tify any such rights. Information on the IETF's procedures 777 with respect to rights in standards-track and standards- 778 related documentation can be found in BCP-11. 780 Copies of claims of rights made available for publication and 781 any assurances of licenses to be made available, or the result 782 of an attempt made to obtain a general license or permission 783 for the use of such proprietary rights by implementors or 784 users of this specification can be obtained from the IETF Sec- 785 retariat. 787 The IETF invites any interested party to bring to its atten- 788 tion any copyrights, patents or patent applications, or other 789 proprietary rights which may cover technology that may be 790 required to practice this standard. Please address the infor- 791 mation to the IETF Executive Director. 793 7. References 795 [TERMS] S. Bradner, "Key words for use in RFCs to 796 Indicate Requirement Levels", Internet RFC 797 2119, March 1997. 799 [RFC 1633] R. Braden, D. Clark, S. Shenker, "Integrated 800 Services in the Internet Architecture: an 801 Overview", June 1994. 803 [RFC 2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. 804 Jamin, "Resource ReSerVation Protocol (RSVP) 805 -- Version 1 Functional Specification", 806 September 1997. 808 [RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. 809 Wang, W. Weiss, "An Architecture for Differen- 810 tiated Services", December 1998. 812 [TERMINOLOGY] J. Strassner, E. Ellesson, "Terminology for 813 describing network policy and services", 814 Internet Draft draft-strassner-policy- 815 terms-01.txt, February 1999. 817 [IANA] Internet Assigned Numbers Authority, 818 http://www.isi.edu/in-notes/iana/assign- 819 ments/port-numbers . 821 [INFOMODEL] B. Moore, E. Ellesson, J. Strassner, "Policy 822 Framework Core Information Model", Internet 823 Draft draft-ietf-policy-core-info- 824 model-03.txt, January 2000. 826 [POLFRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. 827 Strassner, G. Waters, A. Westerinen, J. 828 Wheeler, "Policy Framework", Internet Draft 829 draft-ietf-policy-framework-00.txt, September 830 1999. 832 [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. 833 Rajan, A. Sastry, "The COPS (Common Open Pol- 834 icy Service) Protocol", RFC 2748, January 835 2000. 837 8. Acknowledgements 839 Special thanks to Mark Stevens, Bob Moore, Andrea Westerinen, 840 Avri Doria, Cheh Goh, Ken Owens, Rick Roeling, and Brian 841 O'Keefe for input and feedback during the development of this 842 draft. Thanks also go to Ed Ellesson and Bert Wijnan for 843 their guidance on what should be discussed in this document. 845 9. Author Information 846 Hugh Mahon 847 Hewlett-Packard Co. 848 3404 East Harmony Road, MS A2 849 Fort Collins, CO 80528-9599 850 USA 851 Phone: +1 970 898 2487 852 EMail: hugh_mahon@hp.com 854 Yoram Bernet 855 Microsoft 856 1 Microsoft Way 857 Redmond, WA 98052 858 USA 859 Phone: +1 206 936 9568 860 EMail: yoramb@microsoft.com 862 Shai Herzog 863 IPHighway 864 Parker Plaza, 16th Floor 865 400 Kelby St. Fort-Lee NJ 07024 866 USA 867 Phone: +1 201.585.0800 868 EMail: herzog@iphighway.com 870 John Schnizlein 871 Cisco Systems 872 9123 Loughran Road 873 Fort Washington, MD 20744 874 USA 875 Phone: +1 301 567 7126 876 EMail: john.schnizlein@cisco.com 878 10. Full Copyright Statement 880 Copyright (C) The Internet Society (2000). All Rights 881 Reserved. 883 This document and translations of it may be copied and fur- 884 nished to others, and derivative works that comment on or oth- 885 erwise explain it or assist in its implementation may be pre- 886 pared, copied, published and distributed, in whole or in part, 887 without restriction of any kind, provided that the above copy- 888 right notice and this paragraph are included on all such 889 copies and derivative works. However, this document itself 890 may not be modified in any way, such as by removing the copy- 891 right notice or references to the Internet Society or other 892 Internet organizations, except as needed for the purpose of 893 developing Internet standards in which case the procedures for 894 copyrights defined in the Internet Standards process must be 895 followed, or as required to translate it into languages other 896 than English. 898 The limited permissions granted above are perpetual and will 899 not be revoked by the Internet Society or its successors or 900 assigns. 902 This document and the information contained herein is provided 903 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 904 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 905 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 906 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 907 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 908 PARTICULAR PURPOSE." 909 1. Introduction ......................................... 2 910 2. QoS Policy usage ..................................... 5 911 2.1 Voice ............................................... 5 912 2.2 Protected classes of traffic ........................ 6 913 2.3 Guaranteed Transfer Time ............................ 7 914 2.4 Policy and Services ................................. 7 915 3. Usage Cases .......................................... 8 916 3.1 Simple Usage Case ................................... 8 917 3.1.1 Simple Usage Case in an ISP Environment ........... 8 918 3.1.2 Simple Usage Case in an Enterprise Environment .... 9 919 3.1.3 Simple Usage Case - Steps to Implement ............ 10 920 3.1.3 Simple Usage Case Requirements .................... 11 921 3.1 Complex Usage Case .................................. 12 922 3.1 Complex Usage Case - Requirements ................... 13 923 4. Security Considerations .............................. 13 924 5. Summary .............................................. 14 925 6. Intellectual Property ................................ 16 926 7. References ........................................... 16 927 8 Acknowledgements ...................................... 17 928 9. Author Information ................................... 17 929 10. Full Copyright Statement ............................ 18