Internet Draft Hugh Mahon Expiration: May 2001 Hewlett-Packard File: draft-mahon-policy-use-00.txt Yoram Bernet Microsoft Shai Herzog IP Highway November 9, 2000 Usage Cases for a Policy Management System Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes some usage cases for policy management, showing how policy may be used in a networked environment. In addition some issues which need to be resolved for defining a policy management system are discussed. Internet Draft Policy Usage Cases November 2000 This document is one of several documents describing multiple aspects of policy management. For more documents relating to policy management see the Web page for the IETF Policy Framework Working Group under the IETF home page (http://www.ietf.org/). This document is the result of discussions, e-mail, and other communications within the Policy Framework Working Group and among individuals. Table of Contents 1. Introduction ......................................... 2 2. Usage Cases .......................................... 3 2.1 An Accounting Department Example .................... 3 2.1.1 Policy Consumer For an Existing (Legacy) Device.... 9 2.1.2 Policy Consumer for a Policy Aware Device ......... 12 2.1.3 Other Policy Consumer Uses ........................ 12 2.2 New Traffic in the Net .............................. 13 2.3 Traffic Classification With Packet Conditions ....... 14 2.4 Other Uses of Policy ................................ 17 2.5 Network Failure ..................................... 18 2.6 The Role of Signaling in Policy Management .......... 21 2.6.1 Classification Assumptions Implicit in Top-Down Provisioning ....................................... 21 2.6.2 Snooping Signaling Messages to Glean Classifica- tion Information ................................... 22 2.6.3 Offering High Quality Guarantees .................. 23 2.6.4 Signaled QoS Usage Case I - IP Telephony .......... 24 2.6.5 Signaled QoS Usage Case II - SAP .................. 28 2.7 Policy in an Engineered Network ..................... 30 2.8 Combination of Policies ............................. 32 3. Security Considerations .............................. 34 4. Intellectual Property ................................ 34 5. References ........................................... 35 6. Acknowledgements ..................................... 36 7. Author Information ................................... 36 8. Full Copyright Statement ............................. 36 1. Introduction The intent behind policy based management is to provide a higher level of control for management functions. Describing how policy management can help administrators and address their needs is not a simple task. Mahon,Bernet,Herzog Expires May 2001 [Page 2]
Internet Draft Policy Usage Cases November 2000 This draft provides some detail of how administrators would go about managing an environment using policy, and describes some of the things they will need to consider when using policy. In addition, some of the requirements for a policy management system are described. 2. Usage Cases A Policy Management System is not a solution unto itself. The fact that it exists in a managed environment does not in and of itself provide a solution. Administrators must understand their networks, and how they are being used. In addition Administrators should understand what their customers need in order to do their jobs, and what their customers want to do with the network (since needs and wants are not necessarily the same). Administrators can begin the process of Policy-based manage- ment by monitoring the traffic on their networks and estab- lishing baseline measures. Traffic and usage patterns vary, but patterns can be determined which provide Administrators with a valuable basis for later actions. Using tools which provide information about the types of traffic, not just the volume, can provide the Administrator with information about the traffic related to critical business functions. In addi- tion, if the collected information indicates sources and des- tinations of the traffic, both inside the firewall and through it, the Administrator can relate that to the type of traffic and better understand particular uses. For example, Web traf- fic can be work-related or recreational. Traffic within the company network, such as to a Personnel server, is work- related. Traffic to www.espn.com, though, is probably not work-related, unless the user is a sports reporter. This kind of information, along with direct input from the users of the network (the Administrator's customers) will be the basis for the Policies managing the network. Note that when using the term 'device' it is reasonable to substitute firewall, host computer, software application, operating system, network stack, Network Interface Card (NIC), or any other 'thing' that can be managed. Somehow 'device' just sounds better than 'thing'. Below are some examples of how Policies can be used to address Network Management needs. 2.1. An Accounting Department Example Accounting departments can be large users of networked resources. Sales orders, product inventory, shipping information, payroll information, and more must be accumu- lated and processed to provide monthly and quarterly reports. Network traffic levels can be expected to (and Mahon,Bernet,Herzog Expires May 2001 [Page 3]
Internet Draft Policy Usage Cases November 2000 does) increase during such periods. This doesn't just involve servers, but the end systems on the desks of the individuals collecting and processing the information as well. Thus the traffic is not isolated to a small portion of the network. It is not uncommon for Network Administrators to ask other users of the network to limit usage of the network during these times to give Accounting priority . This is at best a hit or miss proposition, since it is difficult for a user to understand what impact any given activity will have on the network. A user can easily understand that transfer- ring a large file via FTP can impact other users of the same network, but what is the impact of Web browsing, read- ing News, or e-mail? Asking all of the users of the net- work to manage their traffic is asking everyone to manage the network. Policy Management is a way for the Network Administrator to pro-actively manage the network, not simply react to how users use the network. The intent is to ensure the value of a shared resource, which is what the network is, not to take anything away from the users. For this example we'll use a fictional but realistic sce- nario. The Accounting department must issue reports for each month. The pace of sales orders typically increases just before the close of the month. The company has opera- tions dispersed geographically, including sales offices and warehouses. The information for generating the end-of- month reports must be obtained from these different loca- tions by the Accounting department's systems. In addition, each of these different operations are generating their own reports. Accounting traffic can take a significant portion of the network's bandwidth, but Accounting isn't the only user of the network. The reports are due on the first of the month, so traffic gets heavier during the last 10 days of the month. Quarterly reports are due on the 15th of each month, and work on this begins as soon as the previous monthly report is finished. The company in this example has a fiscal year that matches the calendar year, so quar- ters end at the end of March, June, September, and Decem- ber. That means that work on quarterly reports occur in April, July, October, and January. For the purposes of keeping this example relatively simple, the Accounting department's systems are on a separate subnet at the corpo- rate offices. A simple approach would be to give priority to traffic to or from Accounting during these times. To do this the Administrator could author a policy such as the following: Mahon,Bernet,Herzog Expires May 2001 [Page 4]
Internet Draft Policy Usage Cases November 2000 if (((trafficToOrFrom AccountingSubnet) && (dayOfMonth in last10days)) || ((trafficToOrFrom AccountingSubnet) && (monthIn [April, July, October, January]) && (dayOfMonth in [1-15]))) then priority = high endif Expressions in the condition list such as 'trafficToOrFrom' and AccountingSubnet are abstractions which maybe presented by management implementations to provide understandable yet accurate representations of management goals. Such repre- sentations as 'AccountingSubnet' would be specified else- where in the Policy Management Application or may be taken from other established mappings that already exist in the environment (e.g., directory entries, etc.). Such high level representations may exist in an implementation but are not required. The requirement is the information that goes into the Policy Schema, which is discussed below. In the above Policy Rule the traffic is being tested for coming from or going to the subnet for the Accounting department. If the traffic is coming from or going to the AccountingSubnet, and it is the last 10 days of the month, or is the first fifteen days of the month after the end of a quarter, then the traffic is given high priority. Instead of comparing against a subnet, the test could be for a set of machines, or could be for a specific applica- tion. The above Policy Rule would be translated into an actual set of device independent information which conforms with the Policy Schema. Since this Policy Rule is likely not the only Policy infor- mation that would be deployed to a set of devices in the network, this example will add other Policy Rules in the set to be deployed to a target. First is the representa- tion in Policy Schema terms of what the above Policy Rule would translate into: Mahon,Bernet,Herzog Expires May 2001 [Page 5]
Internet Draft Policy Usage Cases November 2000 Rule 1: provide high QoS for traffic to or from the AccountingSubnet during the last 10 days of the month, or first 15 days after the end of a fiscal quarter if (((IPsubnet 192.168.12.0/255.255.248.0) && (dayOfMonth in last10days)) || ((IPsubnet 192.168.12.0/255.255.248.0) && (monthIn [April, July, October, January]) && (dayOfMonth in [1-15]))) then priority = 6 endif The abstraction 'trafficToOrFrom' has been translated into IPsubnet, which will match traffic going to or from the specified subnet. If, for example, instead of Accounting- Subnet, the specification had been AccountingServers the translation would have been IPaddress, which would have compared the list of machines against the source or desti- nation address on packets. What is stored in the Policy Repository could still be labels (or names) for the condi- tion values rather than fixed information such as IP addresses and subnet values. When the information were sent to the Policy Consumer, though, the information must be resolved. The Policy Condition types would be resolved before being placed in the Policy Repository. The responsibility of representation to the user is left to the Policy Management Application and is outside of the scope of this document. The following includes additional Policy Rules that are to be deployed to multiple targets along with the above Policy Rule. These are represented roughly according to Policy Schema in appropriate boolean form. (Individual components of the PolicyTimePeriodCondition are represented in the interest of readability.) Mahon,Bernet,Herzog Expires May 2001 [Page 6]
Internet Draft Policy Usage Cases November 2000 Rule 1: provide high QoS for traffic to or from the AccountingSubnet during the last 10 days of the month, or first 15 days after the end of a fiscal quarter if (((IPsubnet 192.168.12.0/255.255.248.0) && (dayOfMonth in last10days)) || ((IPsubnet 192.168.12.0/255.255.248.0) && (monthIn [April, July, October, January]) && (dayOfMonth in [1-15]))) then priority = 6 endif Rule 2: provide medium QoS for intra-company Web usage during business hours from the accounting subnet if (((srcIPsubnet == 192.168.12.0/255.255.248.0) && (destIPport == 80) && (destIPsubnet == 192.168.0.0/255.255.0.0) && (timeOfDay == 0800-1700) && (dayOfWeek == _MTWRF_)) || ((destIPsubnet == 192.168.12.0/255.255.248.0) && (srcIPport == 80) && (srcIPsubnet == 192.168.0.0/255.255.0.0) && (timeOfDay == 0800-1700) && (dayOfWeek == _MTWRF_))) then priority = 4 endif Rule 3: provide medium QoS between two servers which share database, directory, and other information if (((srcIPaddress == 192.168.12.17) && (destIPaddress == 192.168.24.8)) || ((srcIPaddress == 192.168.24.8) && (destIPaddress == 192.168.12.17))) then priority = 4 endif Mahon,Bernet,Herzog Expires May 2001 [Page 7]
Internet Draft Policy Usage Cases November 2000 Rule 4: provide high QoS to multicast traffic to the corporate management subnet during business hours and all day Sunday (for important business meetings) if (((srcIPsubnet == 224.0.0.0/240.0.0.0) && (timeOfDay == 0800-1700) && (dayOfWeek == _MTWRF_)) || ((srcIPsubnet == 224.0.0.0/240.0.0.0) && (dayOfWeek == S______))) then priority = 6 endif Rule 5: provide high QoS to nightly backup on server at IP address 192.168.2.15 from 2 to 4 AM on weeknights and Saturdays if (((srcIPaddress == 192.168.2.15) || (destIPaddress == 192.168.2.15)) && (timeOfDay == 0200-0400) && (dayOfWeek == _MTWRFS)) then priority = 6 endif Rule 6: provide lowest priority QoS for Quake traffic if (IPport == 26000) then priority = 0 endif Table 1. A Policy made up of Policy Rules. The Administrator would author the policies as illustrated in Table 1 to meet objectives for the portion of the net- work for which the Administrator is responsible. The Administrator may author other policies to address other needs, and these policies may be of other types. Priority policies are necessary for some needs, while Committed Rate policies address other kinds of needs. RSVP policies address yet another set of needs on the network. And so on. Once the administrator has authored these rules they would be committed to a repository. How the Policy Management Mahon,Bernet,Herzog Expires May 2001 [Page 8]
Internet Draft Policy Usage Cases November 2000 Application chooses to order operations is implementation dependent, but the Policy Rules must be grouped together to form a Policy Group. Once grouped the Policy can option- ally be run through tools to determine if there are con- flicts between Policy Rules within the Policy. The Policy also needs to be associated with Policy Targets. Once this association is created the Policy may be tested for any conflicts with other Policies. The Policy may now (or already have been) stored in the Policy Repository. The Policy can now be deployed to Pol- icy Consumers. The Policy Management Application would send a notification to the Policy Consumers that there is New Policy for them. A good notification message would include references to the Policy Targets affected (individ- ualized for each Policy Consumer) as well as information about where to find the Policy in the directory. If the Policy data is replicated across multiple Policy Repositories, the Policy Management Application should ver- ify replication has occurred before sending out the above notification. The Policy Consumers would now retrieve the Policy and notify the Policy Management Application of receipt. The Policy Consumer may also verify validity of the Policy at this point. The Policy Consumers would perform the appropriate actions for each Policy Target to instantiate the Policy on each Policy Target associated with the Policy and for which that Policy Consumer is responsible. The Policy Consumer would then provide status information to the Policy Management Repository regarding the success of the deployment opera- tion. 2.1.1. Policy Consumer For an Existing (Legacy) Device In order to allow an existing device, which has no con- cept of the Policy Schema, to use Policy a Policy Con- sumer can be implemented which can receive Policy data and provide the appropriated mapping from Policy Data to device configuration actions. This may involve opera- tions not directly mapping to device capabilities, for example handling time and date related conditions, which are not supported by many devices today. Such a Policy Consumer may be appropriate for future devices after Policy Management is well established. Reasons for this could include vendors may decide not to place such functionality on the device itself for cost or other factors. The device itself would then be Mahon,Bernet,Herzog Expires May 2001 [Page 9]
Internet Draft Policy Usage Cases November 2000 'Policy unaware', while the addition of a Policy Con- sumer for such a device would allow it to work with a Policy Management System. Some of the Policy Rules in Table 1 contain time and date conditions, which are shorthand for the components of the policyTimePeriodCondition class. The Policy Tar- get in this example is the Priority Queuing feature of an interface on a router. The Policy Consumer would receive the Policy Data in a form conformant with the structure described in [INFO- MODEL], including the time conditions. The Policy Con- sumer would validate the Policy Data, then filter the Policy Data based on the time information. For instance, Rule 2 would be translated and sent to the Policy Target (along with other rules in effect) only Monday through Friday, during the hours of 8 AM to 5 PM. At 5 PM Monday through Friday, for example, the Policy Consumer would understand that a time period within a rule has expired which would cause the Policy Consumer to re-evaluate what information should be configured on the Policy Target. In this example, the Policy Consumer would cause the configuration related to Rule 2 to be removed from the Policy Target (because the Rule con- tains one condition list and that condition list con- tains a time condition). At 8AM on Monday through Fri- day the Policy Consumer would again re-evaluate the Pol- icy Data and would add the configuration information relative to Rule 2 to the configuration of the Policy Targets associated with the Policy. The non-time por- tions of the condition list would be converted into an Access Control List (ACL) on the router with the source subnet, destination subnet, and destination IP Port num- ber when the time condition is true. To continue the example, configuration relating to Rule 3 would always be on the Policy Target since it does not have a time component. The two condition lists would be converted into ACLs for the router, each ACL specifying a source and destination pair. Rule 4 again is subject to time conditions. When one of the time conditions evaluates true an ACL will be con- figured on the router to match traffic with a source subnet matching a multicast address. Rule 5 also contains a time condition and when the time conditions evaluate true, the Policy Target will be con- figured with two ACLs, one matching the address for the backup server as the source address and the other match- ing the destination address to allow traffic going to and coming from the backup server to have better QoS. Mahon,Bernet,Herzog Expires May 2001 [Page 10]
Internet Draft Policy Usage Cases November 2000 Rule 6 contains no time conditions, so would be con- verted into an ACL matching port 26000 (the registered port for Quake, a multi-user game) as the source or des- tination port on a packet, and provide it with the low- est priority. If a device has a feature which provides less than best effort priority, this value may be mapped to such a capability on that device. Since Rule 1 has date based conditions, it would be con- verted to an ACL matching the specified subnet as the source or destination subnet during the last 10 days of the month or the first 15 days of a month after the end of the quarter. The ACL would not be configured for Target (for this Rule) during other time periods. (Note, the schema allows PolicyTimePeriodCondition to be attached to the PolicyRule itself rather than be expressed within the Condition List. For simplicity it was represented in the Condition List.) Prior to deploying the Policy configuration to the device hosting the Policy Target, the Policy Consumer will determine the current configuration. If there is a configuration such that a feature which conflicts with the operation of this Target exists, the Policy Consumer will provide feedback to the Policy Management Reposi- tory about the condition and will not deploy the Policy. If there is configuration for the Policy Target which relates to the Policy configuration to be deployed, the Policy Consumer will issue commands (e.g., SNMP set com- mands, Telnet CLI, etc., as appropriate for the device) to delete the configuration or free resources which will no longer be used. At this point the Policy Consumer will actually send the configuration commands to the device in order to cause the Policy Target to act in accordance with the Policy (as appropriate based on time and date conditions, etc.). Once the Policy Rules based configuration has been sent to the Policy Target(s) the Policy Consumer will deter- mine the success of the deployment and provide feedback to the Policy Management Application. In order to determine the success, for this example, the Policy Con- sumer will query the device and examine the information relating to the configuration of the Policy Target(s) to determine if the configuration now matches what the Pol- icy Consumer expects based on the Policy Data. If no errors were encountered during the deployment and the configuration is correct, the Policy Consumer will report success. This status information would be stored as an attribute of the Policy Target in the Policy Man- agement Repository. Mahon,Bernet,Herzog Expires May 2001 [Page 11]
Internet Draft Policy Usage Cases November 2000 As described above, at the start or end of a time/date period expressed in a condition the Policy Consumer would re-evaluate the Policy Rules for the Policy Target and perform the necessary translations, check existing configuration, perform any necessary clean-up, deploy the corresponding configuration, and report status. (Alternatively the Policy Consumer could generate the appropriate information for any given time period speci- fied in the Policy Rules and simply download them at the appropriate times rather than filter at each time bound- ary.) 2.1.2. Policy Consumer for a Policy Aware Device A Policy Aware device is a device which is has the abil- ity to handle Policy in the form specified by the Policy Schema. In other words, a Policy Aware device is one which has a Policy Consumer capability implemented on the device itself. Without dictating the actual implementation, there are reasonable expectations of the functions that would be implemented on a Policy Aware device. Along with the Policy Consumer, which is the interface for receiving Policy, there needs to be local storage of Policy or derived information, interpretation of the Policy which may include translation to configuration, time-keeping to support time and date conditions, and features to provide feedback to the Policy Management Application of the status of Policy deployment as well as any other attributes of the Policy Target(s) related to Policy management. If the Policy Consumer is implemented on the same device as the Policy Target, how the behaviors dictated by Pol- icy Rules are put in force is implementation specific. 2.1.3. Other Policy Consumer Uses It is possible that a device may be implemented that can handle Policy Information but does not interact directly with the Policy Management Application or Policy Reposi- tory. In this case a simple Policy Consumer may be used to act as a simple proxy between the device and the Pol- icy Management System. Such a Policy Consumer would simply forward Policy Data to the device. The important thing to note is that the only requirement for a Policy Consumer is to act as an interface for Pol- icy Targets with the Policy Management System. How the functionality that needs to occur between the interface to the Policy Consumer and the Policy Target is depen- dent on the implementation. As long as the Policy Mahon,Bernet,Herzog Expires May 2001 [Page 12]
Internet Draft Policy Usage Cases November 2000 Consumer can interact with the Policy Management Appli- cation (receiving Policy, notifications, provide status and other feedback, etc.) and the Policy Target can implement the Actions specified in Policy Rules they are compliant with requirements of the Policy Management System. The function of Policy evaluation can reside in the Pol- icy Consumer, the Policy Target, in both, or somewhere in between. The act of Policy evaluation may even occur in stages within the implementation; for example the time conditions may be evaluated separately from other conditions within Policy Rules. 2.2. New Traffic in the Net A few years ago a new application became available. This application allowed users to have their system display news items when their systems were otherwise idle. It became very popular and became widely used in a very short period of time. About the same time users discovered that their network performance was not what they had come to expect, especially connections from their corporate networks to the Internet. After a few months, Network Administrators learned that the firewalls were being overwhelmed by the requests from internal systems to the servers for this new application on the Internet. (The eventual solution was for the companies to set up servers inside the firewall and have internal users connect to these servers instead of going through the firewall.) The initial reaction of the IT staff in these companies was to tell users that use of this application was not allowed until a solution was found, but many users continued to use the application any- way. With Policy Management the IT staff could have immediately limited or even shut down this kind of traffic by applying some simple Policy Rules. For example: if (traffic == NewsApp) then priority = Lowest endif In the above example 'Lowest' may be even lower than best effort. Even with the internal servers for NewsApp, this may be an appropriate policy since it is not a business critical function. The internal servers still need to get the news articles (and advertising) to provide to internal users, so they Mahon,Bernet,Herzog Expires May 2001 [Page 13]
Internet Draft Policy Usage Cases November 2000 need to go through the routers and firewalls connecting with the Internet. For these Policy Targets there may be Policy Rules in place to allow higher priority for internal servers to access the NewsApp servers on the Internet. So an Administrator may author and deploy the following on Targets representing priority queuing on the routers send- ing traffic to connections to the Internet, and on internal interfaces on those routers which can receive traffic from the Internet: if (((traffic == NewsApp) && (trafficFrom InternalNewsAppServers) && (trafficTo !CorporateSubnet)) || ((trafficTo InternalNewsAppServers) && (TrafficFrom !CorporateSubnet))) then priority = Medium endif if (traffic == NewsApp) then priority = Lowest endif In this example the Policy will give NewsApp traffic 'Medium' priority if it is coming from or going to internal servers. If the NewsApp traffic is not coming from the internal NewsApp servers, it will go to the next rule which gives the traffic 'Lowest' priority. 2.3. Traffic Classification With Packet Conditions When determining how traffic should be treated conditions such as what kind of traffic and who is generating (or receiving) it are important factors. As discussed above, some traffic will be more important than others as far as why the network exists. In a company, traffic generated by ERP (Enterprise Resource Planning) tools will be valuable, while traffic generated by games will be less valuable. Also illustrated above is the importance of knowing who is causing the traffic. Combining these pieces of information can enable the Administrator to further refine allocation of shared network resources. The use of IP Port values in the IP packet header allows understanding what kind of traffic the packet represents (as long as one of the Port values is a well-known or reg- istered port). If traffic is going to a well-known port it is going to a server for that type of application. If it is going from a well-known port it is going to a client of that application. Use of the srcIPport, destIPport, and Mahon,Bernet,Herzog Expires May 2001 [Page 14]
Internet Draft Policy Usage Cases November 2000 IPport conditions as described earlier allow an Administra- tor to classify traffic by type. Use of addresses (or names) allows designation of individ- ual machines, or groups of individual machines. Use of subnet identifiers allows a shorter designation of groups of people or systems involved in specific types of work (e.g., Accounting, R&D, etc.). To use the example from above of giving some (Medium) pri- ority to Web traffic going to and from a Web server for the Personnel department, we could express it as: if ((IPport == 80) && (IPaddress == PersWebSrv)) then priority = Medium endif Where the condition IPport matches the srcPort or destPort field in the packet header, and IPaddress matches the srcAddress or destAddress field in the packet header. The administrator could author the same rule as follows instead: if (((destIPport == 80) && (destIPaddress == PersWebSrv)) || (srcIPport == 80) && (srcIPaddress == PersWebSrv))) then priority = Medium endif The difference between the single matching statement and two matching statements ORed together is that some Policy Targets may not have a 'match either source or dest' fea- ture, and could only match one (usually the Policy Consumer would provide a mapping, though). Or an Administrator may know that writing the Rule one way may be more efficient on a particular type of device than the other way. This, again, goes back to the need to understand some character- istics of what is being managed, but not quite to the same level of detail as currently required (e.g., the analogy between high-level programming vs. assembler level pro- gramming). Similarly, traffic for a set of users can be identified, as well as the application they are using. So an R&D group using an NFS server on another LAN could use significant network resources. Allowing them high quality of service limited to the NFS server could be done with the following: Mahon,Bernet,Herzog Expires May 2001 [Page 15]
Internet Draft Policy Usage Cases November 2000 if (((destIPport == sunrpc) && (srcIPsubnet == RandDsubnet) && (destIPaddr == NFSserver)) || ((srcIPport == sunrpc) && (srcIPaddr == NFSserver) && (destIPsubnet == RandDsubnet))) then priority = High endif In the first part of the Rule, the conditions are testing for the destination Port for sunrpc (NFS), a source being the R&D subnet, and the destination being the specified NFS server. The second portion of the Rule checks for traffic going the other way. Actually this Rule could be split into two Rules, with each being assigned to different Pol- icy Targets. +-------+--------+ | Int3 | | | +----------+ |Router | |NFS Server| R&D subnet | TargetB| | | +----------+Int1 Int2+-----------+ | | |TargetA | | | +--+-----+ | | | | |User PC | | | +----------+ | | | Int4 | +--------+ +-------+--------+ Figure 1. A router with Policy Targets. The Rule: if ((destIPport == sunrpc) && (srcIPsubnet == RandDsubnet) && (destIPaddr == NFSserver)) then priority = High endif only needs to be associated with TargetB (representing pri- ority queuing on Interface2) since that is where traffic going to the subnet with the NFS server is controlled. The other Rule: Mahon,Bernet,Herzog Expires May 2001 [Page 16]
Internet Draft Policy Usage Cases November 2000 if ((srcIPport == sunrpc) && (srcIPaddr == NFSserver) && (destIPsubnet == RandDsubnet)) then priority = High endif would be associated with TargetA (representing priority queuing on Interface1), which is where traffic entering the R&D subnet is controlled. By carefully authoring Policy Rules to contain the condi- tions specific to the function(s) of a specific Policy Tar- get, the Administrator can reduce the amount of processing for each packet going through the the device. Some devices have fewer resources than others. It can be easy to write a Policy that can tax (or even overflow) a device's capa- bilities. A well implemented Policy Consumer will detect any problems with a Policy before deploying it on a Target (if the problem wasn't detected in an automated way ear- lier). If a Policy Consumer does detect such a problem it will provide feedback to the Administrator through the Pol- icy Management Repository. The above Rules assume IP traffic. Traffic could also be classified by EtherType, allowing other kinds of traffic sharing the network to share the benefits of Policy. At the edges of a network, it may be desirable to test for the existing value of the IP Precedence bits in the IP TOS byte and re-mark it if the necessary. A Rule performing this check will also look at who the traffic is for (or from) in order to determine what should be the correct mark. For example: if ((IPprecedence == 3) && (trafficTo CustomerX)) then mark = 5 endif 2.4. Other Uses of Policy Policy is not just used to give some traffic higher prior- ity than others. As noted earlier, the network is a shared resource. There will always be some traffic that is more important than other traffic, but even the most critical traffic must still let other users use the network (other- wise their should be a business need to separate that Mahon,Bernet,Herzog Expires May 2001 [Page 17]
Internet Draft Policy Usage Cases November 2000 critical traffic onto a separate network). Policy, therefore, can be used not just to assure that a critical use has sufficient bandwidth, but can be used to ensure that the critical traffic doesn't squeeze out the rest of the traffic. There are multiple methods of implementing this, but a com- mon term is Rate Control. The idea is to ensure the important traffic has enough bandwidth to fulfill user needs, and if there is sufficient extra bandwidth the traffic can also use that. But if other traffic exists, the important traffic does have a limit. This concept may also be used to keep the less important traffic from using too much bandwidth on the network. This traffic could be allowed some space, but a limit is set to keep it from interfering with other traffic. 2.5. Network Failure This section discusses methods for dealing with a network element failure which would require a different set of policies to ensure the same (or at least a known) QoS dur- ing the time the unusual situation exists. The case of Policy handling a network failure requires fea- tures for Policy Management not discussed earlier in this draft. To address this scenario additional work on the Policy Framework Core Information Model will be required. An Administrator will establish Policies in the networked environment (on routers, trafficshapers, switches, NICs, in network stacks, on applications, etc.) in order to ensure QoS according to the needs of the users of the networked environment. If a failure of a network element (e.g., router) occurs traffic will need to follow other routes through the network. If there were more than one path through the network which were also provisioned to provide the desired QoS that the failed route were configured to route (i.e., more than one route were identically config- ured relative to QoS and had sufficient bandwidth to take up the slack from another path) there would be no need to change the QoS configuration during the outage. Unfortunately not all networks will be so adequately con- figured, so a way to account for such failures is desir- able. There are at least two ways to address this: Mahon,Bernet,Herzog Expires May 2001 [Page 18]
Internet Draft Policy Usage Cases November 2000 1. Create condition types which deal with state 2. At the level of association between Policy and Policy Target provide the ability to associate multiple Poli- cies, and the association contains conditions which cause deployment of the Policy to the Policy Tar- get(s). Scenario 1 allows for minimal change to the Core Informa- tion Model. It would, however, cause Policies to be clut- tered with Policy Rules (or condition lists within Policy Rules) which only exist to handle contingencies. Such con- ditions which deal with state likely would not be evaluated on the Policy Targets (using existing devices as the model), rather they would be evaluated on the Policy Con- sumer. An example of such a state condition could be: condition type name: deviceDown attributes: device address: 192.168.14.12 considered down if no contact after: 30 seconds To enable such a condition, either the Policy Consumer would need to poll each of the devices named in each such condition, or would need to be notified by some third party monitoring the condition of each device named in each pol- icy condition. Following Scenario 1 could cause Policies to contain more Policy Rules (or more condition lists within Policy Rules) to handle contingencies. This could also lead to more con- ditions within the non-contingency portions since those descriptions may not be applicable during periods requiring contingency Policy information. Take or example, a Service Provider with agreements with two customers A and B. Cus- tomer A contracted for premium service under all circum- stances. Customer B chose a lower cost service plan, which contained a provision that under certain circumstances may allow outage of service. Customer A's traffic usually flows through one path on the network, while Customer B's traffic flows through a portion with lower capacity. If the path used for Customer A experiences a failure, the contingency would be to route the traffic through the path used for Customer B. Because Customer B's contract allowed for outages, the Pol- icy on that path allowed for only best effort for Customer B during unusual circumstances. To handle this, using Sce- nario 1 as the model, all of the condition lists relating to Policy for QoS for Customer B would contain the state condition(s) for unusual circumstances, but logically NOT'd Mahon,Bernet,Herzog Expires May 2001 [Page 19]
Internet Draft Policy Usage Cases November 2000 so that if the unusual circumstances did not exist the rest of the condition list would be evaluated: Rule 1 if (((srcIPsubnet == CustomerB) || (destIPsubnet == CustomerB)) && ( NOT deviceDown(routerX, 30 sec.) ) && ( NOT deviceDown(routerY, 30 sec.) ) then Priority=5 endif Rule 2 if (((srcIPsubnet == CustomerA) || (destIPsubnet == CustomerA)) && (deviceDown(routerX, 30 sec.) || deviceDown(routerY, 30 sec.))) then Priority=5 endif Such policy would work, but would be cumbersome to manage. It also could reduce the ability to use the same Policy (or individual Policy Rules) across multiple Policy Targets since the 'deviceDown' conditions would be specific to cer- tain portions of the network. This scenario allows minimal change to the existing Core Information Model definition, but changes operational char- acteristics of components of the Policy Management System. Scenario 2 would require a change to the Core Information Model. On the association between a Policy and Policy Tar- get, there would be conditional associations to other Poli- cies. In the association would be conditions similar to those described in Scenario 1, which describe conditions under which the Policies for unusual circumstances would be deployed. If the current indirect model for distribution is followed, all of the policies would be placed in the directory and the Policy Consumer would obtain all of the policies, then change which Policy is deployed to the Pol- icy Target on a status change as described in Scenario 1. If a more direct model for Policy distribution were used, then the Policy Management Application could be enabled to change Policy distribution based on state not related to traffic based conditions. Mahon,Bernet,Herzog Expires May 2001 [Page 20]
Internet Draft Policy Usage Cases November 2000 Whether the Policy Management Application or the Policy Consumer is involved, Scenario 2 allows for smaller and more reusable 'non-contingency' Policies, while allowing an easy mechanism for specifying Policies for unusual circum- stances. If the Policy Consumers were to be made responsible for this contingency management, the Policy Consumers will nec- essarily have greater requirements than have previously been discussed. It would also introduce more policy that would need to be deployed at all times. Having the Policy Management Application handle the contingency deployment centralizes the operations but may be less reliable in the face of a network failure (e.g., if the link between the Policy Management Application and a Policy Consumer were unavailable). 2.6. The Role of Signaling in Policy Management The usage cases described thus far are based on a top-down provisioning approach. In this approach, policies are applied by 'pushing' information from a PDP, to PEP. The top-down approach can be combined with a signaling based approach in which hosts signal information from the edges of the network, to components of the policy management sys- tem. This approach offers significant gains in manageabil- ity of certain traffic. In this section, we discuss the signaling approach and its benefits. Note that for the purpose of this discussion, we assume that RSVP signaling is used. However, much of the discus- sion applies to any signaling protocol that carries policy related information from hosts, along the data path to peer hosts and that can be parsed by PEPs (and the asociated PDPs) on the path. For example, IPSec can benefit from a similar approach to policy. 2.6.1. Classification Assumptions Implicit in Top-Down Provisioning Top-down provisioning assumes that the policy management system is endowed with certain knowledge about network traffic. This includes knowledge of the following clas- sification information: 1. Correlation of IP addresses to users - the account- ing department example assumes that the policy man- agement system knows a set of IP addresses (or an IP subnet) that identifies all accounting users. Mahon,Bernet,Herzog Expires May 2001 [Page 21]
Internet Draft Policy Usage Cases November 2000 2. Correlation of IP ports to applications - the Sun- Rpc and NewsApp examples assume that the policy management system knows a set of IP ports that identifies these specific applications. The classification information described may be hard to come by. It is rarely the case that a specific group of users can be identified by a single IP subnet. Account- ing users may be distributed across multiple subnets. Applications often use volatile ports. In the case of IPSec, ports are encrypted and cannot be used at all to identify applications. For these reasons, it is desir- able to enable the policy management system to automati- cally learn classification information that can be used to correlate traffic from certain users and applications with specific classification criteria. 2.6.2. Snooping Signaling Messages to Glean Classification Information Certain sending hosts will generate RSVP signaling mes- sages describing the traffic that they are sending to the network. These messages flow along the data path in the network, carrying information such as: 1. Sending user ID 2. Sending application ID and sub-ID (e.g. print job vs. time-critical transaction [APPID]) 3. Classification criteria (in the form of source and destination IP addresses and ports) 4. Volume of traffic sent (in the case of quantifiable applications only) This information (with the exception of the volume of traffic sent) may be generated both for multimedia applications (such as telephony and video applications) as well as for less quantifiable applications such as ERP applications. In the case of IPSec encrypted traffic, hosts will pro- vide an SPI [RFC2207] in the signaling messages, to be used as classification criteria in lieu of IP ports. Certain PEPs in the data path would be configured to pass the relevant information from RSVP messages to their PDPs. In this manner, policy management systems Mahon,Bernet,Herzog Expires May 2001 [Page 22]
Internet Draft Policy Usage Cases November 2000 may passively snoop RSVP messages to automatically and dynamically populate tables correlating classification information to users and applications. This functional- ity can significantly improve the reliability of classi- fication information while reducing the administrative burden associated with manually maintaining this infor- mation. Of course, for many applications, hosts will not generate signaling messages. For these applications it will still be necessary to maintain classification information using alternate approaches. 2.6.3. Offering High Quality Guarantees The qualities of guarantees that can be made by a strictly top-down provisioned system are limited by the extent to which the system understands network traffic patterns and traffic volumes. For example, assume that an enterprise is interested in enabling IP teleconfer- encing over an enterprise WAN. The top-down provisioned approach to this would push the following rules to a PEP: if (destIPport == IPtelephony) then (mark == 5) endif if (mark == 5) then (priority = high) endif Assume that this rule is implemented on a PEP that drives a T-1 WAN link. Assume further that, on the aver- age, ten telephony sessions are in effect on the link at any time, with an average per-session data rate of 64 Kbps. In this case, roughly 40% of the link's capacity is yielded to telephony. Since the telephony traffic gets high priority, it is assured relatively low latency and a high quality service can be expected. However, assume that on a particular day, there is high demand for the telephony application and one-hundred sessions are in progress. Since all telephony traffic is marked for high priority by the policy management system, the T-1 link will be significantly oversubscribed. In the worse case, all other traffic traversing the link will be starved and the telephony quality guarantees will be worthless. In the best case, other traffic will be Mahon,Bernet,Herzog Expires May 2001 [Page 23]
Internet Draft Policy Usage Cases November 2000 spared starvation, but the telephony guarantees will still be worthless. In this example, it would be preferable to mark traffic associated with ninety of the one-hundred telephony ses- sions as best-effort or low priority traffic, in so at least assuring the quality of guarantees available to the first ten sessions. The strict top-down approach falls short in this regard. It is unable to distinguish one telephony session's traffic from another. Consider now that some of the telephony clients are not directly on the remote end of the T-1 link. Instead, these clients are served by a 64 Kbps link, which is in turn served by the T-1 link. In this case, it would be desirable to mark even fewer than ten sessions worth of traffic for high priority, if those sessions traverse the 64 Kbps link. As such, implementation of the marking rule should depend on the path that potentially marked traffic will take through the network. The same considerations apply to any application requir- ing high quality guarantees, such as most multi-media applications. In short, high quality guarantees require either considerable over-provisioning of the network or the ability to apply some degree of topology aware admission control as part of the policy management sys- tem. Applications that do not require high quality guarantees do not strictly require topology awareness and admission control from the policy management system. Nonetheless, network management systems can use resources more effi- ciently if they are more aware of traffic patterns and are able to apply some form of granular admission con- trol. Consider the following usage cases. The first applies to quantitative applications requiring very high quality guarantees. The second applies to qualitative applications that benefit from some degree of topology aware admission control, but do not require strict guar- antees. 2.6.4. Signaled QoS Usage Case I - IP Telephony Consider the following network topology: Mahon,Bernet,Herzog Expires May 2001 [Page 24]
Internet Draft Policy Usage Cases November 2000 +-------+ +-------+ +-------+ | | | | | | |host 1 | |host 2 | |host 3 | | | | | | | +-------+ +-------+ +-------+ | | | | | | +-----------+-----------+ | | | +-----+------+ | | | PEP 1 +---------+ | | | | | | +---------+ +-----+------+ | | | | | | | | +----+ PDP | | 1544kbps link | | | | | | | | | +---------+ +-----+------+ | | | | | PEP 2 | | | +---------+ | | +------------+ | | 64kbps linl | +-----------+-----------+ | | | | | | +--+----+ +--+----+ +--+----+ | | | | | | |host 4 | |host 5 | |host 6 | | | | | | | +-------+ +-------+ +-------+ Figure 2. This is a simplified depiction of a corporate network. PEP 1 is a router at the main corporate office. It serves some large number of hosts via LAN interfaces (represented on the top side of the router). It con- nects the main corporate office to an overseas hub, rep- resented by PEP 2. In turn, PEP 2 serves a number of smaller remote offices, each of which serve some number of clients. In the diagram, both PEPs are shown as Mahon,Bernet,Herzog Expires May 2001 [Page 25]
Internet Draft Policy Usage Cases November 2000 connected to a single PDP, for simplicity's sake. How- ever, the example could be just as well illustrated with two separate PDPs. There is no direct communication between the process in the PDP that serves PEP 1 and the process that serves PEP 2. Assume that the corporate network manager wishes to use policy to enable the network for IP telephony service using the diffserv EF codepoint. The PDP would then be configured with the following rules: allow .1 * LinkSpeed for signaled EF allow .0 * LinkSpeed for non-signaled EF if signaled ((ServiceType == GuaranteedService) && (LatencyBound <= 100 msec)) then DSCP = EF endif There are two types of rules here. The first rule speci- fies that only ten percent of the traffic traversing a link can be marked for the EF PHB and that only signaled traffic can be marked with the EF codepoint. This rule is required in order to assure the integrity of the ser- vice provided with the EF codepoint. The second rule states that signaled traffic should be marked EF iff it the signaling messages request the Guaranteed Service and a latency bound less or equal to 100 msec. These rules would operate as follows: 1. Hosts would generate signaling messages for IP telephony sessions. These messages would carry the following information: a. Guaranteed Service b. Latency <= 100 msec c. Bandwidth = 6.4 Kbps d. Source IP address/Destination IP address = 1.2.3.4/5.6.7.8 e. Source IP port/Destination IP port = 5000/6000 f. user ID g. application ID/sub application ID Mahon,Bernet,Herzog Expires May 2001 [Page 26]
Internet Draft Policy Usage Cases November 2000 2. These signaling messages would flow from sender towards receiver. Consider initially, a flow transmitted by a host attached to PEP 1. The sig- naling message arrives at PEP 1 and is forwarded to the PDP. 3. The PDP notes that the request is for Guaranteed Service and is for a latency bound less than 100 msec. Based on these parameters, and using the sec- ond rule, it maps the request to the EF PHB. 4. The PDP then compares the requested bandwidth against the maximum allowed EF bandwidth from the first rule. Since the requested bandwidth does not exceed the allowable EF commitment on the link, the PDP can admit the request. 5. The PDP reduces the remaining allowable EF band- width on the link by 6.4 Kbps. 6. The PDP then pushes the following rule to the PEP: if((SrcAddr == 1.2.3.4) && (DestAddr == 5.6.7.8) && (SrcPort == 5000) && (DestPort == 6000)) then mark = EF endif 7. PEP 1 then forwards the signaling message on towards PEP 2. 8. A similar process is repeated at PEP 2. Note the following: 1. An additional request for a similar telephony ses- sion from a host attached to PEP 1 would pass admission control at PEP 1, but would fail at PEP 2 (since the required EF capacity would exceed the ten percent limit on the 64 Kbps link from PEP 2). In this case, the PDP would reject the request via PEP 2. The EF marking rule would not be installed for the second session and a signaling message would be sent back towards PEP 1, indicating that the admission control request failed. This message would be directed to the PDP. The PDP would respond by removing the marking rule for the second Mahon,Bernet,Herzog Expires May 2001 [Page 27]
Internet Draft Policy Usage Cases November 2000 session. 2. The policy described is based purely on the requested service type and the quantitative parame- ters of the request. This policy does not actually restrict the EF service to telephony but rather to any application requiring low latency and Guaran- teed Service. The network administrator could expand the second policy rule to include user ID and application IDs as qualifiers for EF marking. 3. It is implied that the signaling messages are RSVP messages. RSVP policies can be applied to PATH mes- sages (which transit from sender to receiver), RESV messages (which result in the opposite direction) or both. The choice of which messages policy should be applied to is, in itself a policy decision. In this example, policies are applied to PATH mes- sages. 2.6.5. Signaled QoS Usage Case II - SAP Consider the same network topology per the previous example. Now assume that the network administrator wishes to provide preferential service to mission criti- cal SAP traffic traversing the corporate WAN links. The administrator is assured (based on the rules installed for the EF PHB) that at least ninety percent of each link capacity will be available for best-effort traffic. From experience, the administrator knows that 100 SAP accounting sessions can be supported with the remaining link capacity in PEP 1 and that 5 sessions can be sup- ported with the remaining link capacity in PEP 2. With a greater number of sessions, performance for all users tends to degrade rapidly. The PDP would then be config- ured with the following additional rules: if (PEP == 1) if ((APPID == SAP) && (SUB_APPID == ACCOUNTING)) allow 100 sessions for DSCP AF11 else mark DSCP = 0 else if (PEP == 2) if ((APPID == SAP) && (SUB_APPID == ACCOUNTING)) allow 5 sessions for DSCP AF11 else mark DSCP = 0 Mahon,Bernet,Herzog Expires May 2001 [Page 28]
Internet Draft Policy Usage Cases November 2000 endif These rules would operate as follows: 1. Hosts would generate signaling messages for SAP sessions. These messages would carry the following information: a. Null Service (see [NULLSERVICE]) b. Latency <= XXX c. Bandwidth = XXX d. Source IP address/Destination IP address = 2.2.2.2/3.3.3.3 e. Source IP port/Destination IP port = 4000/9000 f. user ID g. application ID/sub application ID 2. These signaling messages would flow from sender towards receiver. Consider initially, a flow transmitted by a host attached to PEP 1. The sig- naling message arrives at PEP 1 and is forwarded to the PDP. 3. The PDP notes that the request is for the Null Ser- vice. Therefore it uses the application ID and sub application ID to identify the appropriate PHB, per the policy rule. 4. The PDP then compares the number of currently admitted SAP sessions against the limit of 100 ses- sions. If 99 or fewer sessions have been admitted so far, the PDP is able to admit the request. 5. The PDP decrements the number of remaining allow- able sessions. 6. The PDP then pushes the following rule to the PEP: if((SrcAddr == 2.2.2.2) && (DestAddr == 3.3.3.3) && (SrcPort == 4000) && (DestPort == 9000)) then mark = AF11 endif Mahon,Bernet,Herzog Expires May 2001 [Page 29]
Internet Draft Policy Usage Cases November 2000 7. The PDP then forwards the signaling message on towards PEP 2. 8. A similar process is repeated at PEP 2. Note the following: 1. Admission control, in this usage case, amounts to deciding whether the signaled traffic is entitled to a DSCP other than for best-effort. PDPs may cause a DCLASS object to be appended to RSVP RESV signaling messages [DCLASS] specifying the DSCP allowed by the PDP. In this manner, it is possible to coordinate the marking function among multiple potential marking PEPs, along a flow's data path. 2. PDPs may also consider user ID in determining which flows are entitled to which DSCP marks. In this manner, a policy could reserve high priority usage of a certain application for specific users of the application. 2.7. Policy in an Engineered Network Using marks on IP packets (using the DS field, IPv4 TOS field, or 802.1p) allows a network element (e.g., router) to quickly classify a packet and give it a particular treatment. Such a usage will require two related but pos- sibly different actions: configuration of the marking mech- anism and provisioning of the network to support the mean- ing of the marks. Both of these actions can be performed via Policy Based Management. An IT administrator would configure (or provision) network elements to support desired behaviors by authoring configu- ration policies. The actions would be the desired behav- iors, and the conditions may only include time and date information (specifying when the behaviors are to be sup- ported, or even what the behaviors mean at a given time). For example, if traffic with DSCP AF11 were only to be sup- ported during the last 10 days of the month, then a config- uration policy rule could be constructed as follows: if (dayOfMonth in last10days) && (DSCP == AF11) then specify queuing behavior 1 endif Mahon,Bernet,Herzog Expires May 2001 [Page 30]
Internet Draft Policy Usage Cases November 2000 and for other times of the month the behavior for DSCP AF11 could be specified differently with the following rule: if (dayOfMonth not in last10days) && (DSCP == AF11) then specify queuing behavior 2 endif It should be noted that each policy rule is self contained, so that when it is combined with other policy rules to form a policy the appropriate actions are taken based on how well the event (e.g., a packet waiting to be queued) matches the conditions of the rule, and the rule's place- ment in the policy. In other words, unless the conditions of a rule are satisfied the rule has no effect, and will not affecte the ability of other rules in the same policy to be acted on. A default behavior for a given action type must be defined such that if the none of the rules within a policy match the event, a known behavior is acted on. In the case of QoS usage policies, the default action will be best effort. These configuration policies will be distributed to the appropriate interfaces to support desired behaviors on the network. Configuring what marks are placed on what traffic is also specified via policy. The IT administrator will author policy rules which identify the type of traffic in the con- ditions and the mark that should be placed on matching packets in the action portion of the policy rule. For example, on an end node that will mark outbound traffic, the following rules may be used to mark traffic to achieve desired behavior in a network that is already appropriately configured to recognize the marks in the packet: if (Application == HTTP) && (destIPaddress in AccountingGroup) DSCP=AF31 endif if (Application == telnet) && (destIPaddress in AccountingGroup) DSCP=AF11 endif if (Application == accountingtool) DSCP=AF12 endif Mahon,Bernet,Herzog Expires May 2001 [Page 31]
Internet Draft Policy Usage Cases November 2000 The default would be not to mark the packet, thus resulting in best effort, unless network elements were provided with policies which identified the traffic through means other than through its mark (e.g., IP address or port informa- tion). A key aspect of such marking is that if end-node marking is to be used, it must be controlled by a centralized manage- ment tool, otherwise a clever (or malicious) user could modify the packet markings to always specify the best behavior, thus bypassing the manager's efforts. 2.8. Combination of Policies Combining policy primitives creates a complete policy set. For example, an enterprise network may include multiple types of applications (VoIP, FTP, HTTP, ERP, Sales and "other"). VoIP and Video are quantitative application that can quantify their traffic as well as the QoS requirements. FTP is a bulk application (cares only about the total start-to-finish transfer time) . and ERP and Sales are qualitative applications (mission critical). This enterprise has three types of employees: executive, sales and administrative. The IT manager of the enterprise has a general goal to pro- vide all these applications and users with their required QoS, except for "other" which get the leftovers, but with a certain minimum: Rule 1: Other is basically best effort If Application=Other Then Priority = 0 Rule 2: Executive get better service for their "other" traffic If Application=Other and User = Executive Then Priority = 1 Rule 3: VoIP If Application = VoIP and (User = executive or User = Sales) Mahon,Bernet,Herzog Expires May 2001 [Page 32]
Internet Draft Policy Usage Cases November 2000 Then One-Way-Delay < 400ms MAX_BW < 64Kbps ; per call MAX_AGGR_BW < 512Kbps ; for all calls Rule 4: If Application = FTP and User=Administrative Then Priority = (0..3) based on the gap of reaching transfer time goal. (Some exponential function ;-) Rule 5: If Application = HTTP and User = Executive Then Up to 256Kbps: Priority = 3 Up to 0.5Mbps: Priority = 2 Else : Priority = 1 Rule 6: If Application = ERP or Application = Sales Then Priority = 3 Rule 7: If Application = ERP or Application = Sales ToD = 9am-12pm Then Priority = 5 Rule 8: Provisioning for classes If Role = CoreRouter+DiffServ+T1 Then Provision Classes using CBQ or Equivalent (Using DiffServ AF?) Priority 5: 15% Priority 4: 20% Priority 3: 20% Priority 2: 35% Priority 1: 5% ;(Anti-Starvation) Priority 0: 5% ;(Anti-Starvation) Rule 9: Marking for classes Mahon,Bernet,Herzog Expires May 2001 [Page 33]
Internet Draft Policy Usage Cases November 2000 If Role = EdgeRouter+EdgeInteface+DiffServ Then Mark DCSP as: Priority 5: AF11 Priority 4: AF12 Priority 3: AF13 Priority 2: AF21 Priority 1: 1 Priority 0: 0 This policy indicates several requirements: Resolution of User and Application into IP/Ports (Abstraction) 2. Ability to handle conflicts: - Rule 6 and 7 conflict 3. Ability to perform admission control (rule 3) on both individual instances as well as their aggregate. 4. Topology awareness. Rules 3 and 8 have per link decisions to make (guaranteeing voice-RSVP style, and guaranteeing classes with at least xx% of any network link). 5. Ability to respond to outsourcing (rule 3) and provisioning (other rules) in a timely manner 6. Interpreting instructions for multiple devices (policy doesn't mention individual devices). 7. Support Roles (rules 8,9) 3. Security Considerations The security requirements for policy management are addressed in more detail in other drafts relating to policy. A short list of the requirements for security related to policy includes: - authentication of server and client - provisions for ensuring integrity of policy information - security of the policy repository - encryption of policy information (especially for policy related to security) 4. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the tech- nology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to iden- tify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- Mahon,Bernet,Herzog Expires May 2001 [Page 34]
Internet Draft Policy Usage Cases November 2000 related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Sec- retariat. The IETF invites any interested party to bring to its atten- tion any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the infor- mation to the IETF Executive Director. 5. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [TERMINOLOGY] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", Internet Draft draft-strassner-policy- terms-01.txt, February 1999. [INFOMODEL] B. Moore, E. Ellesson, J. Strassner, "Policy Framework Core Information Model", Internet Draft draft-ietf-policy-core-info- model-00.txt, June 1999. [POLFRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", Internet Draft draft-ietf-policy-framework-00.txt, September 1999. [COPSFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", Internet Draft draft-ietf-rap-frame- work-03.txt, April 1999. [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Pol- icy Service) Protocol", RFC 2748, January 2000. Mahon,Bernet,Herzog Expires May 2001 [Page 35]
Internet Draft Policy Usage Cases November 2000 [APPID] Y. Bernet, R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", Internet Draft draft-ietf-rap- appid-00.txt, February, 1999. [NULLSERVICE] Y. Bernet, A. Smith, B. Davie, "Specification of the Null Service Type", Internet Draft draft-ietf-issll-nullservice-00.txt, September 1999. 6. Acknowledgements Special thanks to Mark Stevens, Bob Moore, Andrea Westerinen, Avri Doria, Cheh Goh, Ken Owens, Rick Roeling, and Brian O'Keefe for input and feedback during the development of this draft. Thanks also go to Ed Ellesson and Bert Wijnan for their guidance on what should be discussed in this document. 7. Author Information Hugh Mahon Hewlett-Packard Co. 3404 East Harmony Road, MS A2 Fort Collins, CO 80528-9599 Phone: +1 970 898 2487 EMail: hugh_mahon@hp.com Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 USA phone: +1 206 936 9568 email: yoramb@microsoft.com Shai Herzog IPHighway Parker Plaza, 16th Floor 400 Kelby St. Fort-Lee NJ 07024 201.585.0800 herzog@iphighway.com 8. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Mahon,Bernet,Herzog Expires May 2001 [Page 36]
Internet Draft Policy Usage Cases November 2000 This document and translations of it may be copied and fur- nished to others, and derivative works that comment on or oth- erwise explain it or assist in its implementation may be pre- pared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copy- right notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copy- right notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Mahon,Bernet,Herzog Expires May 2001 [Page 37]
Internet Draft Policy Usage Cases November 2000 1. Introduction ......................................... 2 2. Usage Cases .......................................... 3 2.1 An Accounting Department Example .................... 3 2.1.1 Policy Consumer For an Existing (Legacy) Device .................................................... 9 2.1.2 Policy Consumer for a Policy Aware Device ......... 12 2.1.3 Other Policy Consumer Uses ........................ 12 2.2 New Traffic in the Net .............................. 13 2.3 Traffic Classification With Packet Conditions ....... 14 2.4 Other Uses of Policy ................................ 17 2.5 Network Failure ..................................... 18 2.6 The Role of Signaling in Policy Management .......... 21 2.6.1 Classification Assumptions Implicit in Top-Down Provisioning ....................................... 21 2.6.2 Snooping Signaling Messages to Glean Classifica- tion Information ................................... 22 2.6.3 Offering High Quality Guarantees .................. 23 2.6.4 Signaled QoS Usage Case I - IP Telephony .......... 24 2.6.5 Signaled QoS Usage Case II - SAP .................. 28 2.7 Policy in an Engineered Network ..................... 30 2.8 Combination of Policies ............................. 32 3. Security Considerations .............................. 34 4. Intellectual Property ................................ 34 5. References ........................................... 35 6. Acknowledgements ..................................... 36 7. Author Information ................................... 36 8. Full Copyright Statement ............................. 36 Mahon,Bernet,Herzog Expires May 2001 [Page 38]