Internet Draft Hugh Mahon Expiration: April 2000 Hewlett-Packard File: draft-ietf-policy-req-01.txt Yoram Bernet Microsoft Shai Herzog IP Highway October, 22 1999 Requirements 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 (1999). All Rights Reserved. Abstract This document describes why policy based management is interest- ing to people managing IT environments and what is needed to make policy management address those interests. Work to date is described, as well as usage cases demonstrating how policy-based Internet Draft Policy Requirements October 1999 management would actually work. The goal for this document is to provide a set of requirements for further development of standards for policy management sys- tems. There has already been work in the area of policy manage- ment and the work to date is described as well as additional areas to be defined. For readers in a hurry the Introduction (section 1) and Usage Cases (section 5) will provide a great deal of information. Readers interested in more detail about various aspects of Policy Management should read from the beginning of the document to the end. 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 ......................................... 3 2. A Simple Policy Management System .................... 6 2.1 The Policy Consumer and Policy Target ............... 7 3. Policy Management in Action .......................... 9 3.1 Information Visible to the Administrator ............ 10 3.2 Policy Deployment Actions ........................... 11 3.2.1 Policy Configuration Usage ........................ 11 3.2.2 Results of Policy Configuration ................... 13 3.3 Alternate Architectures ............................. 13 3.3.1 Policy Status and Configuration Information ....... 13 3.3.2 Policy Notification ............................... 15 4. General Policy Management Issues ..................... 17 4.1 Provisioned vs. Signaled QoS Mechanisms ............. 17 4.2 Policy assignment ................................... 19 4.2.1 Policy applicability .............................. 21 4.3 Policy Operation .................................... 21 4.3.1 Policy Size ....................................... 22 4.3.2 Policy Capability ................................. 23 4.4 Policy Conflicts .................................... 24 4.4.1 Conflict (Inconsistency) Between Policies ......... 24 4.4.2 Rule Conflict Within a Policy ..................... 26 4.5 Time aspects of policy .............................. 26 4.6 Scalability ......................................... 27 4.6.1 Scalability and Policy Targets .................... 28 4.6.2 Scalability and Policy Consumers .................. 28 4.6.3 Scalability and the Repositories .................. 28 4.6.4 Scalability and the Policy Management Applica- tion ............................................... 29 4.7 Administration of the Policy Management System ...... 30 4.7.1 Policy UI ......................................... 31 4.7.2 Policy Conflict Detection ......................... 31 4.7.3 Policy Repository ................................. 32 4.7.4 Policy Management Repository ...................... 32 Mahon,Bernet,Herzog Expires March 2000 [Page 2]
Internet Draft Policy Requirements October 1999 4.7.5 Policy Consumers .................................. 32 4.7.6 Policy Targets .................................... 32 4.8 Policy Conditions ................................... 33 4.8.1 Time/Date Conditions .............................. 33 4.8.2 Packet Conditions ................................. 33 4.9 Implementation examples ............................. 34 4.9.1 LDAP .............................................. 34 4.9.2 SNMP .............................................. 37 4.9.3 COPS .............................................. 39 4.9.4 HTTP .............................................. 41 4.10 Policy Interpretation .............................. 42 4.11 Policy information ................................. 42 5. Usage Cases .......................................... 42 5.1 An Accounting Department Example .................... 43 5.1.1 Policy Consumer For an Existing (Legacy) Device .................................................... 48 5.1.2 Policy Consumer for a Policy Aware Device ......... 51 5.1.3 Other Policy Consumer Uses ........................ 52 5.2 New Traffic in the Net .............................. 52 5.3 Traffic Classification With Packet Conditions ....... 53 5.4 Other Uses of Policy ................................ 57 5.5 Network Failure ..................................... 58 5.6 The Role of Signaling in Policy Management .......... 61 5.6.1 Classification Assumptions Implicit in Top-Down Provisioning ....................................... 61 5.6.2 Snooping Signaling Messages to Glean Classifica- tion Information ................................... 62 5.6.3 Offering High Quality Guarantees .................. 63 5.6.4 Signaled QoS Usage Case I - IP Telephony .......... 64 5.6.5 Signaled QoS Usage Case II - SAP .................. 68 6. Security Considerations .............................. 70 7. Summary .............................................. 71 8. Intellectual Property ................................ 72 9. References ........................................... 73 10 Acknowledgements ..................................... 74 11. Author Information .................................. 74 12. Full Copyright Statement ............................ 74 1. Introduction Policy based management has generated a lot of buzz in the industry lately. Unfortunately hype can create unrealistic expectations. While Policy Based Management won't solve all problems, or make IT administration a trivial task, there is a real need for Policy Based Management. So why are people interested in Policy Based Management? Mahon,Bernet,Herzog Expires March 2000 [Page 3]
Internet Draft Policy Requirements October 1999 Internet technology based networks are being used for more functions and by more businesses. Their ability to do busi- ness is affected by the health and abilities of their net- works. As networks grow the amount of things that need to be managed grows. Not only are there more devices to be managed, but also the number of kinds of things (e.g., capabilities, ser- vices, types of interfaces, etc.) is growing. As more kinds of things are introduced, so are more management interfaces the IT administrators must learn and use to manage the envi- ronment. In addition, many of those management tools work with individual devices, so that an administrator must dupli- cate the actions used to manage (configure) one device for each other device, even if they are the same type of device from the same vendor. The problem is exacerbated if the devices are from different vendors, since they must perform different tasks to manage similar capabilities. The same problem exists not just for networking, but for just about anything an IT administrator may need to manage. In response to this situation, customers (IT administrators) have for many years been asking vendors for tools which better address their needs in managing such large and dynamic envi- ronments. Their list of desired features includes: - centralized management - abstracted (or simplified) management data - commonality across devices - automation of management tasks - fewer interfaces - consistency across interfaces Centralized management requires the ability to perform manage- ment tasks via the network. Scalability factors into the requirements since a centralized system is not practical if it doesn't scale well to fit the management needs in the environ- ment. Abstracted (or simplified) management data fits with the fewer interfaces objective by abstracting the functions and decision criteria across multiple devices, lending itself to the next desired feature, commonality across devices. There are two aspects to commonality: the ability to learn how to do something once and apply that across multiple things of the same kind, and the ability to use the same data, not just similar data, across multiple things. By using the same con- figuration across multiple devices, the administrator can achieve consistent behavior in the managed environment and Mahon,Bernet,Herzog Expires March 2000 [Page 4]
Internet Draft Policy Requirements October 1999 reduce, or better yet eliminate, duplication of efforts. It is this desire to use the same data across multiple devices that is behind the desire to have fewer interfaces. Automation of management tasks is the feature that causes a change from most implementations of management tools with existing technologies (e.g., SNMP). One aspect of automation is the desire of customers to be able to re-use management data where that re-use makes sense, and for the tools to sup- port such re-use. In other words, wherever possible, the tools support management information re-use, and do not require the administrator to duplicate information already in the management system, and can automatically get the informa- tion where it needs to go and when it is needed rather than require additional intervention by the human administrator. Automation is also key in allowing the network to operate with a minimum of human intervention (once the human administrators have specified, through management data, how the environment is to behave under given circumstances). The key to providing a solution for these requirements is the data used to manage the environment; what that data repre- sents, how it gets from the administrator to what the data affects, and the functionality that supports reuse and automa- tion. That data has been called 'policy'. Policy Based Management is the term used to describe the technologies that address the customer requirements described above. In support of the above features, the efforts for defining Policy Based Management have focused on the data representa- tion and properties of a repository for that information. The use of a repository is important to support reusability of data across managed things, as well as allowing an administra- tor to edit existing management data (both are forms of reuse). In addition to being stored in a repository, the data must get to where it will be used (this supports the require- ments of centralized management and automation). (Information distributed from a centralized repository also aids in consis- tency of information throughout the managed environment.) With common policy information the administrator can use the same information to configure devices which are supposed to do the same thing (addressing centralized management, commonality across devices, and reducing the number of interfaces required for multiple devices from different vendors). This policy information can also be abstracted to a higher level, since it will need to be device independent. Common information does not require a common format (i.e., schema). In other words, it is possible to have common Mahon,Bernet,Herzog Expires March 2000 [Page 5]
Internet Draft Policy Requirements October 1999 information for QoS management, and common information for security uses, but have completely different formats for the different uses of data. This would cause a duplication of information that could be common (e.g., user information use for access control), and so would be a bad thing because it would lead to greater differences between disciplines than necessary. Therefore, a common format is another requirement to support the desire for automation and fewer interfaces. To summarize the above: centralized management leads to the need for a repository; scalability requires a means to commu- nicate the data beyond the repository; abstraction requires a common information model; automation requires the abstraction and components to perform actions based on management data and real-time inputs. The rest of this document describes what is necessary to make a policy-based management system work, and how such a system would work in a real environment. 2. A Simple Policy Management System To start the discussion of how things would operate in a Pol- icy Management system a simple system must be described. Fig- ure 1 provides a schematic view of a very basic Policy Manage- ment System. Mahon,Bernet,Herzog Expires March 2000 [Page 6]
Internet Draft Policy Requirements October 1999 +-------+ |Policy | |UI | | | +-------+ ^ | V +------------------------+ |Policy Repository | | | | | +------------------------+ ^ ^ / | / | V V +---------+ +---------------+ |Policy | Policy | Policy | |Decision | Consumers | Consumer 1 | |Point | | | +---------+ +---------------+ ^ ^ ^ ^ ^ COPS RSVP| | | |COPS, \ Client type | | +------------+ | |SNMP, TelnetCLI, etc. V +>| +--------+<-----------+ V V +------------+ | |Policy | | +-----------+ +-----------+ |RSVP enabled| | |Target C| | Policy | Policy | | Policy | |device | | +--------+ | Targets | Target A | | Target B | | | |RSVP enabled| | | | | +------------+ |device | +-----------+ +-----------+ +------------+ Figure 1. A schematic of a Policy Based Network Management System. In this illustration, the designation of one policy target as using COPS/RSVP (signaled policy model) and another as using SNMP (provisioned policy model), is not intended to imply that the two are mutually exclusive. In fact, it is likely that many devices will support both models simultaneously. The Policy UI is a place where the administrator can author or edit policies and the components of policies. The Policy Repository is a place where the policy information is stored for use by the rest of the policy architecture. Later figures present elaborations on the functions required for a more complete Policy Management System. Mahon,Bernet,Herzog Expires March 2000 [Page 7]
Internet Draft Policy Requirements October 1999 2.1. The Policy Consumer and Policy Target There are two essential functions when viewing the managed environment: 1. dealing with the management information 2. implementing the functionality/behavior specified by the management information The Policy Consumer is a logical component which can parse Policy information. The Policy Target is a logical compo- nent which implements the functionality or behavior speci- fied by the Policy. The Policy Consumer and Policy Target may be logically or physically the same, or may be separate. The choice is left to the implementor because different implementations have valid reasons for implementing either way. There is at least one other logical component, and that is the piece which takes information and compares it with the Policy (or information derived from it) to make a decision. This component may reside with either the Policy Consumer or the Policy Target. Again, there are valid reasons for either. The discussion of Policy Management Systems in this document will not make any assumptions about this implementation dependent component. To provide further examples, the Policy Consumer receives policy intended for a Policy Target and processes the pol- icy to allow the Policy Target to enforce the policy. The Policy Consumer may use the policy interactively, that is, directly use the policy information to make a decision each time an event occurs which requires an enforcement decision (such as the arrival of an RSVP reservation message). In this real-time policy usage scenario the Policy Consumer is acting in the role of the PDP (Policy Decision Point) as described in the COPS architecture (see [COPSFRAME]). The Policy Consumer could instead process the policy infor- mation and convert it into configuration information for the Policy Target to use without further operation of the Policy Consumer. (Note that the Policy Consumer may inter- act with the Policy Target even if Policy does not change. This may be because of time or other reasons discussed later in this document.) If the Policy Consumer is resident on the device with the Policy Target, then the details of the Policy Consumer and Policy Target interaction are implementation dependent (if indeed the logical distinction between Consumer and Target exist, which is not a requirement of an implementation). Mahon,Bernet,Herzog Expires March 2000 [Page 8]
Internet Draft Policy Requirements October 1999 If the Policy consumer is not resident on the device, pro- cessing by the Policy Consumer may take one of a spectrum of forms: 1. The Policy Consumer may be an outsourcing PDP, in which case it responds to queries from the Policy Tar- get (which is acting as a Policy Enforcement Point). Such a scenario, in which the PEP issues requests to the PDP about RSVP reservations, is what COPS was originally developed for. See [COPSFRAME] for more information about the functions of an of an outsourc- ing PDP. 2. The Policy Consumer may receive policy information and convert this into configuration information for a man- aged element (e.g., a router) and then configure the device to act in accordance with the policy informa- tion. It should be noted that where policy is con- verted (or the decision is made) is an implementation decision, and there is no single best answer for all desired optimizations. 3. Anywhere between 1 and 2, in which some processing or decision making occurs in the Policy Consumer, and the Policy Target takes configuration information or caches decisions. It is important to note that the Policy interface is at the Policy Consumer, whether it resides on the managed element or elsewhere. The interface between the Policy Consumer and Policy Target (if it exists in a particular implementa- tion) is beyond the scope of this document and the Policy Framework WG. A Policy Consumer may work with multiple Policy Targets. A single device may use multiple Policy Consumers, and may even have co-located Policy Consumers for some policy types and remote Policy Consumers for other policy types. It is not required that a single Policy Consumer encompass the functionality to support all of the policy features of a single device. A Policy Target is a specific functional aspect of a device or logical component. For example, a router has multiple interfaces, and each interface has multiple capabilities, such as priority queueing, Committed Access Rate, etc. Each of these capabilities on an interface becomes a 'tar- get' for Policy. By focusing on the most basic features that can be configured, Policy enables the administrator to deal with abstractions of the device. By allowing this abstraction Policies can be applied across multiple kinds Mahon,Bernet,Herzog Expires March 2000 [Page 9]
Internet Draft Policy Requirements October 1999 of devices which provide similar functionality at that abstract level. So if a router has 4 interfaces, and each interface has 4 manageable features, the router has 16 Pol- icy Targets. The scoping of the Policy Target is the same as the func- tionality being managed. In other words, if a managed function (or capability) is specific to a router interface, the Policy Target is that function, and is considered local to that interface and function. If a manageable function is global to a device, the Policy Target related to that function is global to the device. Each Policy Target has one Policy Consumer. To have more than one Policy Consumer responsible for configuring the Policy Target would invite contention between the Policy Consumers. There may be one or more Policy Consumers to enable continued operation in a failure mode, but only one at a time is to be the 'active' Policy Consumer. A Policy Consumer, though, can work with multiple Policy Targets at the same time. Note that the figure contains an RSVP enabled device which also contains a Policy Target. It is expected that a sin- gle device may have multiple policy manageable capabili- ties. Such a device may use outsourcing (the PDP/PEP rela- tionship) for one feature, and one or even multiple Policy Consumers to address other features that can be provi- sioned. Although the diagram illustrates the requirement for verti- cal communication, under certain circumstances horizontal communication between components will be necessary, and this will be discussed in later sections. One such hori- zontal communication is RSVP. 3. Policy Management in Action The following list describes the expected sequence of actions in a policy based management system. Each aspect will be dis- cussed further in this section and following sections of this document. In addition, later sections will discuss aspects of policy not necessarily apparent in a simple description of policy operation. A. Administrator authors new policy (or edits existing pol- icy) B. Administrator associates policy with Policy Targets. C. Policy and association with Policy Targets is stored in repository. Mahon,Bernet,Herzog Expires March 2000 [Page 10]
Internet Draft Policy Requirements October 1999 D. For each of the Policy Targets, a Policy Consumer is notified that new policy is available for the Policy Tar- get. E. The Policy Consumer obtains the policy. See below for a detailed description of the actions of the Policy Con- sumer. F. For each Policy Target which received policy information, the Policy Consumer provides status information back to the Administrator about policy deployment; success, or failure and information about the failure. 3.1. Information Visible to the Administrator A network Administrator must be able to author policy (see [TERMINOLOGY] and [INFOMODEL]), and this could be done using a text file or a special purpose user interface which can provide assistance in authoring policy. Because it is expected that policy information will be complex this docu- ment will expect that a special purpose user interface will be used. The actual function of such a user interface is beyond the scope of this document and the work of the Pol- icy Framework Working Group. There are, however, functions of the user interface that can be determined and thus the requirements for that UI can be documented. An Administrator should not be forced to write policy new each time a change is desired or policy is to be deployed to a newly installed device on the network. For this rea- son a repository is needed. The communication between the UI and repository must be two-way, that is, the UI can store policy in the repository, and the UI may extract pol- icy from the repository for viewing and editing. Because an Administrator will edit Policy Data, it would be desirable to have versioning of Policy Data to allow the Administrator to easily view (or use) earlier versions of the data. In addition to policies, there is a need for information about what is to be managed with the policies. The infor- mation about the Policy Targets would contain a name recog- nizable by the administrator, some attributes of the Policy Target relative to the policy types which can be assigned to the Policy Target (more details described later), and status attributes relative to policy deployment (so the administrator can determine the usage of policy). It should be noted that this status is not intended to reflect the effectiveness of the policy, only the status of policy deployment at each of the Policy Targets. Mahon,Bernet,Herzog Expires March 2000 [Page 11]
Internet Draft Policy Requirements October 1999 3.2. Policy Deployment Actions Once policy information is stored in the repository it must be delivered to where it is to be used. Here is one aspect of a policy based management system which may be non-obvious: Each managed element, called a Policy Target, will have associated with them a Policy Con- sumer. The Administrator need not be conscious of the association between Policy Targets and Policy Consumers (if there is a difference) except during configuration of the Policy Targets into the policy management system. In other words, when the Administrator associates policy to managed elements the mapping between the Policy Consumer and Policy Target (managed element) can be, and probably should be, hidden from the Administrator. How policy is deployed from the repository to the Policy Consumer is discussed in section 3.3.2. As described in section 2.1, a Policy Consumer can be used to configure a managed element based on the policy informa- tion. The following is a simple example of such an opera- tion. 3.2.1. Policy Configuration Usage For this example a simple policy type assigning priority to traffic will be used. This contains a single attribute with a value ranging from zero to seven, 7 being highest priority. Also for this example, the following conditions may be used to identify traffic: - Destination IPaddress - Destination IPport - Destination IPsubnet - policyTimePeriodCondition - Source IPaddress - Source IPport - Source IPsubnet - IP precedence A Policy Consumer working with an existing router (which is not policy aware) would translate the policy informa- tion into the router's configuration commands to enable the router to act in accordance with the policy. For example, a policy may be expressed in the form of an 'if-then-else' statement, such as: Mahon,Bernet,Herzog Expires March 2000 [Page 12]
Internet Draft Policy Requirements October 1999 if (srcIPaddr == 192.168.34.2) then Priority=5 else if (destIPaddr == 192.168.72.12) then Priority=6 else if (destIPsubnet == 192.168.72.0/255.255.248.0) then Priority=7 endif In the above example is a policy containing three rules, each rule containing a single condition which is to cause the traffic matching the expression to receive a designated priority. The Policy Target in this case is priority queuing on an interface on the router. Also, since this router is not policy aware (it was designed before policy standards were developed) it is only configurable via a Command Line Interface (CLI) accessible via Telnet. The Policy Consumer for the router will translate the policy into the appropriate configuration commands for the router/interface combination. Prior to sending the information to the router, the Policy Consumer will check for other configuration related to the specific router interface. If there is already configuration on the interface which is for the function specified by the policy, that previous configuration is removed (using the appropriate CLI commands). Other configuration of the device, even for the specific interface, which does not affect the properties of operation relevant to the policy description is not affected. The ordering of steps will vary from implementation to implementation in order to handle the particular requirements for each device, but the key is that the Policy Consumer concerns itself only with the configura- tion of the device relative to behaviors described by policy. As more policy types are defined this may encompass all aspects of device configuration, but this will not be the case for initial policy management tools and system deployments. Such configuration (communication between the Policy Consumer and Policy Target) may be done using technolo- gies other than Telnet CLI. Other such tools include, but are not limited to, SNMP, COPS, and HTTP. Mahon,Bernet,Herzog Expires March 2000 [Page 13]
Internet Draft Policy Requirements October 1999 3.2.2. Results of Policy Configuration Once the device has been configured according to policy, the Policy Consumer determines whether the deployment was successful. In the case of the above example with a policy unaware device, the Policy Consumer could query the configuration of the device to determine that what was sent was instantiated on the target. The Policy Consumer would then provide for the Administrator feed- back of the success or failure of the policy deployment to the Policy Target. It is not required that the same repository which stores policy information also store the policy status attribute information of the Policy Targets, but there must be an information model that allows for the associ- ation in order to allow an administrator to understand the state of a Policy Target relative to the policy deployed to it. Where this information is stored is dis- cussed below. Once feedback from the Policy Consumer is sent to a repository, it should be presented for the Administrator to see. Many networks are managed and monitored using SNMP today. In environments using SNMP, there are often con- soles which are used to display the status of network elements. Notification of events relative to policy actions may be sent to such an SNMP management system, but Administrators performing Policy management func- tions may use a separate UI. The status of deployment of policy to a Policy Target is therefore desirable as an attribute of that Policy Target. 3.3. Alternate Architectures In order to address notification and status reporting, there need to be more functional elements than appear in Figure 1. The following sections describe various ways to address these needs. 3.3.1. Policy Status and Configuration Information As described above, there is more information required to manage Policy Targets than Policies. Network Admin- istrators need feedback about policy deployment. In addition, information about the capabilities of the Pol- icy Targets would be useful to the Administrator (or management application) in order to ensure that the pol- icy can be implemented on the Policy Target(s) before actual deployment. Mahon,Bernet,Herzog Expires March 2000 [Page 14]
Internet Draft Policy Requirements October 1999 +-------+ |Policy | |UI | | | +-------+ ^ ^ / \ / \ / \ v v +-------------+ +------------+ |Management | |Policy rep | |Repository | |(e.g., LDAP)| |(e.g., rdb) | | | +-------------+ +------------+ ^ / status \ /Policy data and config\ / info \ v +---------------+ | Policy | | Consumer | | | +---------------+ ^ ^ | \ | \ V V +-----------+ +-----------+ | Policy | | Policy | | Target A | | Target B | | | | | +-----------+ +-----------+ Figure 2. Adds a repository for status information about the Policy Targets. Figure 2 shows the components which enable storage of such information for display by the Policy User Inter- face. In addition to the Policy Repository represented in Fig- ure 1, Figure 2 adds a Management Repository to store information about the Policy Targets, their relationship to Policy Consumers, and status of policy deployment to the Policy Targets. In addition other attributes of the Policy Targets may be stored for use of the administra- tor or other policy application(s). Such information would include attributes related to Policy Actions (e.g., for Committed Rate Policy the maximum bandwidth for a target) and Policy Conditions (what conditions are supported, and what are valid values for the Mahon,Bernet,Herzog Expires March 2000 [Page 15]
Internet Draft Policy Requirements October 1999 conditions). In addition, status information regarding the opera- tional status ('up' or 'down') of the Policy Targets, and Policy Consumers should be sent to the Policy Man- agement Repository in order to provide the Administrator with the operational status of these components. An LDAP enabled directory is suited to relatively static information, that is, an LDAP enabled directory is best suited to providing access to information that does not change often (on time scales of hours or days). Information such as status is volatile, meaning that it can change frequently (seconds or minutes) (see section 4.5 Time Aspects of Policy). Based on current stan- dards, then, LDAP enabled directories are not well suited to storing status information. The other attribute information about Policy Targets could be stored in either the Directory or Management Repository. 3.3.2. Policy Notification Also described above is the need to have policy deliv- ered to Policy Consumers in a timely manner. Mahon,Bernet,Herzog Expires March 2000 [Page 16]
Internet Draft Policy Requirements October 1999 +-------------------+ |Policy Mmgt App. | | - Policy UI | | - Conflict detect | | - Notification | | - Mgmt repository | | | | | +-------------------+ ^ | ^ | | | | | | | | | | | V | | +------------+ | | |Policy rep | | | |(e.g., LDAP)| | | | | | | +------------+ | |notif. / status | | /Policy data and config| | / info | v v +---------------+ | Policy | | Consumer | | | +---------------+ ^ ^ | \ | \ V V +-----------+ +-----------+ | Policy | | Policy | | Target A | | Target B | | | | | +-----------+ +-----------+ Figure 3. Provides for status and other information related to policy, as well as notification to Policy Consumers of new policy. Network Administrators currently configure devices in real time. Even though policy management provides addi- tional features, Administrators will still want the man- agement process to occur in human terms (for feedback this means within a few seconds). In order for policy to be received by the Policy Consumer and provide feed- back to the Administrator in such a time frame the Pol- icy Consumer must either poll the Policy Repository at short intervals or be notified that there is information to retrieve from the repository. Mahon,Bernet,Herzog Expires March 2000 [Page 17]
Internet Draft Policy Requirements October 1999 Polling would place a burden on the Policy Consumer (and the system it is implemented on), the Policy Repository (and its host), and the network. Polling is an effec- tive, if inefficient, way to determine if there is new policy. To reduce the cost of polling, the polling interval can be increased, so that queries are performed less often, but this reduces the ability to receive pol- icy in a timely manner. Notification would be more efficient than polling, and could be done to support timely delivery. There are discussions of extending LDAP to provide a notification capability, but this is still undefined, so LDAP does not appear to be able to provide a more effi- cient means than polling for policy distribution to Pol- icy Consumers in the near future (2 to 3 years). Because it writes the information to the Policy Reposi- tory, the Policy UI is aware of when policy changes in the repository. Functionality could be added so that the Policy UI is more than just a UI and notifies the Policy Consumer related to the Policy Target for which there is new Policy. This notification could also inform the Policy Consumer where to find the Policy Data, for example, the Distinguished Name of the first element (or top of DIT containment) of the Policy Data in an LDAP enabled Directory Server. 4. General Policy Management Issues Policy Management is a complex topic. This section of the document will provide a discussion of the major areas of Pol- icy Management. 4.1. Provisioned vs. Signaled QoS Mechanisms There are two mechanisms by which resources may be allo- cated: provisioned (or pre-defined, or pro-active) and sig- naled (or on-demand, or reactive). Each has their strengths and weaknesses. With provisioned mechanisms, traffic treatment (such as CAR, priority, shaping, etc.) can be specified as well as the characteristics of the traffic to receive that treat- ment (i.e., packet header information such as source and destination IP address, IP port numbers, etc.). An admin- istrator would observe traffic patterns on the network, compare that with the desired state (based on business or operational needs), and then craft policies which allocate resources accordingly. Such mechanisms may work quite well for traffic such as HTTP, telnet, or FTP, which are Mahon,Bernet,Herzog Expires March 2000 [Page 18]
Internet Draft Policy Requirements October 1999 tolerant of variance in flow quality (jitter, packet re- ordering, etc.), but still can benefit from having greater throughput provided by the above mentioned QoS mechanisms. The stength of signaling, simply put, is that it enables parts of the network to offer high quality guarantees, and to simultaneously be used efficiently. Without signaling, it is necessary either to compromise the quality of the guarantees, or to over-provision parts of the network. In certain parts of the network, over-provisioning may be a viable option. However, in other parts it may not. If the network administrator is to have the flexibility to not over-provision those parts of the network which would be prohibitively expensive to over-provision *and* to support high quality guarantees through them, then end to end sig- naling must be availble to be used for policy based admis- sion control decisions. Signaling mechanisms can provide information beyond the QoS needs of the traffic for which it is signaling. User information (not available in packet headers), and applica- tion identification (which would be hidden by IPSec, or unavailable if well-known or registered ports aren't used) can be provided, thus allowing higher quality information about the traffic than may be available otherwise. Since network administrators manage in temrs of users and applications, and network devices classify in terms of IP addresses and ports, any mechanism which improves the bind- ing of users/applications to IP addresses and ports (or laternate classification criteria in the case of IPSec), improve the manageability of the network. But the greatest value of the signal is that by traversing the same path in the network as the traffic for which it is signaling, it can communicate the specific QoS needs for the connection. If the needs cannot be met anywhere along the path, an explicit notification is provided, effectively a 'busy signal', notifying the application that it will not get the desired QoS. The signal, then, acts as a horizontal communication mecha- nism (relative to figures 1 and 3) assuring resource allo- cation along the path of a connection, coordinating the QoS mechanisms to ensure expected treatement for the traffic. In contrast, provisioned mechanisms will act as individual points to provide pre-specified levels of QoS, unaware of what other devices are doing. Why, then, wouldn't signaling be used for all traffic for which better than best effort QoS is desired? The signal- ing does incur a cost in additional network traffic, set up time, and processing on the devices and end systems Mahon,Bernet,Herzog Expires March 2000 [Page 19]
Internet Draft Policy Requirements October 1999 involved. Such overhead makes sense for connections that will last for a minute or more, or where variance in QoS can produce dramatically undesirable results. VoIP fits both criteria. Traffic whose connections are short-lived (e.g., HTTP), or can tolerate variable QoS within limits (e.g., telnet, FTP), may not warrant such overhead. A common need for both signaled and provisioned QoS mecha- nisms, though, is policy. It is with policies that the administrator would specify how much resource is to be allocated to any particular use, whether it is to allow a certain amount of bandwidth to be used for all VoIP traf- fic, or limit how much bandwidth a single connection can use (for example to prevent a single user from allocating the entire VoIP bandwidth to send high quality audio to a friend). Related to the provisioned vs. signaled models is the use of outsourcing vs. pre-configuration. Signaling lends itself to outsourcing of policy based decisions better than provisioned because of the granularity provided by the sig- nal (one or a few signals for a connection that lasts a long time versus classifying each packet). This, however, doesn't mean that to use RSVP a device must use an external PDP. It could use a local PDP (in the device) if it has sufficient processing capability. Conversely, a device that uses provisioned QoS mechanisms may outsource a deci- sion when it recognizes a new flow, and then cache the packet header information to provide policy specified QoS for the rest of the flow. 4.2. Policy Assignment Policies must be associated with a manageable entity, which in this document are called Policy Targets. For example, a router has multiple interfaces on it, and each interface is an ingress point to a network (LAN, WAN, backbone, etc.). Many such devices have the ability to affect the Quality of Service of traffic going out through these interfaces (as opposed to coming in through an interface). It is these interfaces, which are the control points, which are the targets of QoS policies. Mahon,Bernet,Herzog Expires March 2000 [Page 20]
Internet Draft Policy Requirements October 1999 +---+ +----+ | |Client A | |Server 1 | |\ /| | +---+ \ +---------+ / +----+ \ |Network | / Dept +----|element |-----+ Corporate WAN / Int1| |Int2 \ / +---------+ \ +---+/ \+----+ | | | | | |Server 2 | |Client B +---+ +----+ Figure 4. Policy assignment example. Figure 4 represents a simple schematic of two networks con- nected by a network element (e.g., a router). In this example, the network element does not have the ability to control traffic entering on an interface, but can control (via queues, marking, etc.) the traffic going out through an interface. One network is a Departmental LAN, and the other is a Cor- porate WAN. The network element connecting these two net- works has two interfaces, Int1 and Int2. The traffic going in to the Dept. LAN will be regulated at Int1, while the traffic going to the Corporate WAN will be regulated at Int2. To control traffic going from the Dept. LAN to the Corp. WAN, a policy would be deployed to Int2, whether it is traffic which is returning to Client B from Server 2 or is traffic from Client A to Server 1. Conversely, traffic entering the Dept. LAN is controlled by Int1, whether the traffic is a request to Server 2 or a response to Client A. The distinction between the interfaces, and the policies targeted to each is important for many reasons. For exam- ple, if the manager of the Dept. LAN wanted to set higher priority for Web usage of users of the Dept. LAN than Web usage from outside of the Dept. LAN (i.e., to the Web servers on the Dept. LAN from the rest of the company), then the policies affecting the traffic must be structured in one of two ways: 1. The policies deployed to Int1 are different than poli- cies deployed to Int2 and the conditions can refer to traffic type only (e.g., source and destination IP Port numbers). Mahon,Bernet,Herzog Expires March 2000 [Page 21]
Internet Draft Policy Requirements October 1999 2. The policies deployed to Int1 and Int2 are the same, and the conditions refer not only to the traffic types, but to the source or destination addresses or subnets. Either approach is valid. The advantage to #1 is that the policy will be smaller, and should require less memory and processing on the network element to implement (the number of 'ifs' that must be processed to implement the policy would be smaller). Of course, the same policy can be deployed anywhere else in the network if the same kinds of behaviors are desired at one or more specific points in the network. And because specific addresses or subnets are not used, the policy is easily reused (if only traffic type is the characteristic). The disadvantage of #2 is that it would be larger, since it is specifying the behavior for flowing out both interfaces, and thus would cause policy which would be used only on Int2 (in this example) to be installed on Int1, and vice- versa. The advantage of this approach is that the adminis- trator may install this same policy anywhere in the network and it will yield the same behavior, reducing the number of policies the administrator would need to author and track. 4.2.1. Policy applicability It is important to point out that while this document often refers to policy applying to a 'device', policy is applicable to other logical entities as well. A network stack within a general computer system (i.e., host com- puter), an application running on a host computer, a firewall application running on a host computer, etc. Thus, in the QoS example of policies, policy may be applied to any physical or logical entity which gener- ates, handles, or otherwise impacts the flow of network traffic. 4.3. Policy Operation There are many considerations regarding policy when it is used to configure a device (as opposed to the decision out- sourcing mode described by the COPS RSVP PDP/PEP interac- tion). How large are policies, what are the implications of expan- sion, and even how well could policy map to a specific device can enter into the usage of policy when specific devices (instead of 'typical') are considered. This dis- cussion is not intended to prescribe a 'least common denom- inator' model for policy, but to describe how policy may be Mahon,Bernet,Herzog Expires March 2000 [Page 22]
Internet Draft Policy Requirements October 1999 used with devices with limited capabilities. 4.3.1. Policy Size Policy to express a certain set of behaviors may take different sizes. The number of Policy Rules contained within a given Policy, the number of conditions, etc., all depend on the requirements placed on the Administra- tor. While the intent of policy is to reduce device specific considerations visible to the administrator it will be difficult to eliminate all device considerations. This is not unlike the fact that a PC user today must be cog- nizant of whether or not a given application will work on a PC equipped with a given amount of RAM. Discussions with Network Administrators have revealed that many do not wish to use more than a handful (4 or 5) of classes of network traffic. This may result in only 4 or 5 rules within a policy. Of course, how those classes are defined may vary. Below are some examples of how classes of traffic may be identified: 1. destIPsubnet == 192.168.32.0/255.255.248.0 && destIPport == 80 2. srcIPport = 25 3. srcIPsubnet == 192.168.32.0/255.255.248.0 && dayOfWeek == _MTWRF_ The list of conditions enumerated in section 3.2.1 is a subset of conditions expected to be defined for policy management. With this set of conditions an administra- tor can specify the type of traffic going between two machines: if ((srcIPaddr == 192.168.2.4) && (destIPaddr == 192.168.72.12) && (destIPport == 80)) then priority=6 else if ((destIPaddr == 192.168.2.4) && (srcIPaddr == 192.168.72.12) && (srcIPport == 80)) then priority=6 endif Mahon,Bernet,Herzog Expires March 2000 [Page 23]
Internet Draft Policy Requirements October 1999 The translation of the above rules would be fairly sim- ple. Some devices can handle many rules such as those above, while other devices can only handle relatively few (e.g., 16 or less). Sizing of policy can also affect performance. For exam- ple, a router could experience greater latency in for- warding a packet if too many rules (or rules containing many condition lists) were configured on the device. On the other hand, a firewall configured with security pol- icy may have no problem handling a hundred or more rules describing what traffic is to be allowed through the firewall. The size of policy on the Policy Target, therefore, is a combination of the complexity of the number of Policy Rules and the actions and conditions expressed in the policy as well as the capabilities of the device itself relative to the ability of the policy to be expressed in the configuration commands of the device. The same pol- icy may consume less memory on one device than on another because of differences in the configuration capabilities of the two devices. 4.3.2. Policy Capability If a device has the ability to control traffic and can exert that control by basing the behavior on things such as information in the packet header, it is a candidate for use with QoS policies. (The criteria for whether or not something can be used with policy is dependent on what capability, functionality, or behavior the policy types involved are abstracting.) Not all devices have the same capabilities. While a policy type may be able to be mapped to a function on a device, that device may not offer all of the conditions (means for classification) that other devices with simi- lar functions offer. For example, a policy for specify- ing Committed Rate may use the value of the IP Prece- dence field to classify traffic. A particular router may not be able to handle this feature. If a policy with IP Precedence in a rule condition is targeted for a device which cannot use IP Precedence, the UI should notify the user and prevent deployment. At a minimum, if the UI is not equipped for this, the Policy Consumer should return a status message that the policy was not implementable on the Policy Target (if there was no work-around by using some other feature of the target). In another variation on the capabilities of a device, not all devices can handle multiple conditions which together identify traffic. (This may not apply to time Mahon,Bernet,Herzog Expires March 2000 [Page 24]
Internet Draft Policy Requirements October 1999 conditions. See sections 4.5 and 5.6.1.) If a Rule within a Policy contains multiple conditions, and the Target is on a device which cannot handle such a Rule, the Administrator should receive a message indicating an error in the Policy. Some devices are simply limited in the number of rules, or the total number of conditions within rules, that can be evaluated. In such a case the Policy Consumer (or some element higher in the system) should provide feed- back of this limitation. 4.4. Policy Conflicts There are two types of policy conflicts that could exist: 1. conflicts between two rules within a policy 2. conflicts between actions within a rule 4.4.1. Conflict Between Two Rules Within a Policy Within a Policy Group are one or more Policy Rules. As defined in [INFOMODEL] these Policy Rules contain Policy Actions and Policy Conditions. Within a single Policy, it is possible to have more than one Policy Rule which will evaluate 'true' for one cir- cumstance. The oft cited example is as follows: Rule 1 if (srcIPaddr == 192.168.2.3) Priority=5 Rule 2 if (srcIPsubnet == 192.168.1.0/255.255.248.0) Priority=3 ... In the above example, both Rule 1 and Rule 2 would eval- uate true if the source IP address were 192.168.2.3. If a configuration were to be entered into an existing device (e.g., a router) to implement this behavior there would be a forced ordering of evaluation, so that the first match would be the action implemented. The Policy Framework WG currently defines in the Core Information Model a priority value associated with the Policy Rule. This priority is used by the administrator to set which Policy Rule is to have a higher priority, so that if more than one Policy Rule can evaluate as true, which Policy Rule has precedence. Unfortunately Mahon,Bernet,Herzog Expires March 2000 [Page 25]
Internet Draft Policy Requirements October 1999 there is no uniqueness to the priority value, so that it is still possible to have multiple rules which could evaluate true and there is no way for the system to determine which has higher priority. The problem with the priority approach is that since priority values need not be unique for a given set of rules, different systems may choose different rules to apply given the same input, which would lead to incon- sistent QoS for traffic matching the multiple Policy Rules. Rule evaluation must be deterministic, such that the same policy, encountering the same input conditions, renders the same results wherever the policy is installed. Rule evaluation must be clearly determinable in order for the administrator to properly specify and understand how the policy (containing multiple rules) will operate in the managed environment. Without such determinism, policy will not meet the needs of those interested in using it. 4.4.2. Conflicts Between Actions Within a Rule If a rule contains multiple actions, it is possible that the actions (or the results of the actions) will con- flict with each other. An example of this is that one action sets one type of queueing on a device, and the other action sets another type of queueing, which for that particular device are incompatible. For each type of device such conflict may be detectable, but in a gen- eral case may not be. 4.5. Time Aspects of Policy With the policyTimePeriodCondition (and the PolicyRuleVa- lidityPeriod condition as part of the Policy Rule) it is possible to have behaviors related to time (see section 4.10.1). This leads to interesting possibilities for policy. With time-based policies Administrators may establish poli- cies to limit certain kinds of traffic to provide enough bandwidth for the nightly backup. Some customers may only want to pay for better QoS during business hours. Policy can be put in place to allow an Accounting Department to have better QoS for accessing corporate financial informa- tion during the last three days of the month. All of these would be possible without the manual intervention of the Administrator at the time the policies are to go into or out of effect. To take advantage of time-based policies, most existing devices (which do not have time- or date-based Mahon,Bernet,Herzog Expires March 2000 [Page 26]
Internet Draft Policy Requirements October 1999 configuration capabilities) would need a Policy Consumer implemented separately from the device. New managed ele- ments may be developed with time and date keeping functions on them, or Policy Targets may reside on a host system which has those functions. It is also possible that the Policy Management Application would change policy stored in the Policy Repository based on time. This would have the advantage of removing the need for time keeping on the Policy Target (or Policy Con- sumer), but it would mean that Policy data is not as static as currently expected. It also would cause a lag in deployment of Policy to the Target since more components are involved (the Policy Management Application, the Repos- itory if indirect delivery is involved, and the Policy Con- sumer). This could be solved, but a solution would make the entire system more expensive. Another affect of time-based policy is on the status of the policy deployment. Depending on the implementation of the Policy Consumer and the conflict detection mechanisms in the system (if any exist) there may be a problem with the policy information that is not visible until portions of the policy with time conditions become 'active'. In other words, portions of the policy (rules, or condition lists in a rule) with time conditions become 'active' when the time or date match values in the policyTimePeriodCondition. These rules or condition lists may contain information which brings the rule into conflict with one or more other rules. Or even worse, the time based rule may contain con- ditions which are not supported by the Policy Target (see section 4.3.2). 4.6. Scalability Policy systems must be able to handle many Policy Targets. Methods for handling such scalability depend on the size of the environment to be managed and other issues related to the managed environment. 4.6.1. Scalability and Policy Targets Looking at the system (as described in Figure 3) from the bottom up, the first components which are affected are the Policy Targets. In terms of what they manage, Policy Targets are fixed since they are by definition a single manageable entity. Scalability is a factor, though, in terms of the amount of data, or configura- tion, the Policy Target can actually handle. Every device (or 'thing') has a finite set of resources. For example, it would be possible to write a set of Policy Rules that when translated to device configuration could be more than the Policy Target could handle. In such a Mahon,Bernet,Herzog Expires March 2000 [Page 27]
Internet Draft Policy Requirements October 1999 case the Policy Consumer would provide notification of the problem to the Policy Management Repository. (The problem could be detected by the Policy Consumer, or some component of the Policy Management Application in order to provide feedback before the Policy actually is sent to the Policy Target.) 4.6.2. Scalability and Policy Consumers To enable more outsourcing PEPs, more PDPs could be deployed in the environment. A limiting factor would be if information relevant to one PEP were to affect deci- sions made for another PEP. In this case, the manage- ment relationship would maintain PEPs which are logi- cally related to the same PDPs, or the PDPs could commu- nicate state information to support relationships between PEPs. Either solution is beyond the scope of the Policy Framework WG. For other Policy Consumers, more Consumers may be placed in the environment to address the increased number of Policy Targets. Any coordination necessary between mul- tiple Policy Consumers (beyond information in the Policy Data) is beyond the scope of the Policy Framework WG. 4.6.3. Scalability and the Repositories There are at least two issues for scalability for repos- itories: - number of clients accessing them - amount of data stored in the repositories The Policy Repository (e.g., an LDAP enabled directory server) would be used to provide the policy data for a management domain (i.e., a logical collection of managed entities under the control of a single IT group). If the number of Policy Consumers (including PDPs) is such that it puts a strain on the resources of the Policy Repository it would be necessary to have duplicate repositories to provide better response to the Policy Consumers. Since Policy Data is expected to be rela- tively static, the Policy Repository should not be over- loaded by policy management over an extended period of time, but may become overloaded if policy for many Pol- icy Targets were to change, which would cause many Pol- icy Consumers to query the repository in a short period of time. To minimize the affect of such a loading of the Policy Repository, it would be desirable to allow for replication of the repository, leading to the usual issues relating to data coherence across repositories. Using LDAP further adds management issues because the Mahon,Bernet,Herzog Expires March 2000 [Page 28]
Internet Draft Policy Requirements October 1999 LDAP enabled server must be configured to replicate data to the correct LDAP servers for Policy Data in a timely fashion. If the Policy Administrator and Directory Administrator are not the same, the Policy Administrator places requirements on, and uses the services provided by, the Directory Administrator. Because it would directly communicate with Policy Con- sumers and PDPs the Policy Management Repository resides logically at the same level as the Policy Repository. The information that the Policy Management Repository works with is more volatile than the information in the Policy Repository, therefore it is more susceptible to being overloaded than is the Policy Repository. The reason that information in the Policy Management Repository is more volatile is that it stores status information (see section 3.3.1). This information is subject to change at any time even if restricted to Pol- icy Deployment status (see section 4.5). The mechanisms for replication among multiple Policy Management Repositories is beyond the scope of the Pol- icy Framework WG, but in the interest of interoperabil- ity should be defined. 4.6.4. Scalability and the Policy Management Application The Policy Management Application can contain multiple functional components. The scalability of one of those components, the Policy Management Repository is dis- cussed above. The other logical components include, but are not lim- ited to: - Policy UI - Policy Conflict Detection - Policy Consumer notification Scalability issues related to the Policy UI mainly con- cern the size of data. (?) Similarly, the number of policies (and the number of Policy Targets) impacts how fast Policy Conflict Detec- tion can be accomplished. 4.7. Administration of the Policy Management System Any Policy Management System will require some management of the system itself, but in order to provide value it must Mahon,Bernet,Herzog Expires March 2000 [Page 29]
Internet Draft Policy Requirements October 1999 be simpler than managing the individual entities under its control separately. That is, using the Policy Management System must cost less (in terms of human administration time) than managing the environment without it. This is not to say that initially it will be easy to use a Policy Management System, for as noted in the Introduction to this draft, it will require new ways of thinking about the managed environment. Indeed, it is the requirement to think in terms of what value the networked computing envi- ronment is providing that is one of the driving forces behind the development of Policy Based Management. As net- working has become a central tool for business, the net- worked computing infrastructure (and the IT staff support- ing it) is being measured on value rendered to the business organization. The value is measured in terms of access to information and the applications which manipulate that information and make it available (and valuable) to others. As has been mentioned earlier, the Policy Data has already received a great deal of attention. It is the components which will use the data which will require most of the administration. Each component, and the aspects which must be administered will be discussed in the following sec- tions. As noted in the Introduction, the Policy Management System is a distributed system. As such, the components may be physically together or separate. Also, depending on the implementation, there may be no externally visible inter- faces between some of the components. The following dis- cussion will try to describe the administration needs with- out assuming any particular implementation. Installation of anything requires some effort. Installa- tion of the components of the Policy Management System will require some extra overhead relative to existing environ- ments. The key value will be that it is easier for the administrator to alter the behavior of the network using the components of the Policy Management System rather than using other tools. Since most of the tools available to the administrator today require touching each network ele- ment individually, and require specific knowledge of each element, the Policy Management System can significantly reduce administration costs if it 1) abstracts functions without requiring detailed knowledge of each element in the networked environment, and 2) allows sharing, reuse, and centralized control of the network elements allowing the administrator to perform tasks without manually contacting each network element. This section is not intended to be an exhaustive listing or specification of the features of a Policy Management Mahon,Bernet,Herzog Expires March 2000 [Page 30]
Internet Draft Policy Requirements October 1999 System, but rather to provide a realistic description of the administrative tasks required of such a system. 4.7.1. Policy UI The Policy UI may be part of other components of a Pol- icy Management Application, such as the Policy Manage- ment Repository. If it is instead a stand-alone compo- nent it will require more administration. Much of this depends on the implementation, and may be beyond the scope of the Policy Framework WG. The UI must be installed, requiring some amount of disk space. It may be configured as to which Policy Reposi- tory and Policy Management Repository are to be used. If a Public Key mechanism is to be used for authentica- tion or encryption between the UI and other components of the Policy Management Application, then those keys must be generated and put in place. Any logging that the UI performs, either independently or as part of the Policy Management Application, may also require administration. Information to be config- ured would include such items as log file location, max log file size, other logging information destinations, type of information to be placed in the log, etc. 4.7.2. Policy Conflict Detection Since this is one of the least discussed logical compo- nents, it is hard to assess the characteristics of this component. Assuming Policy Conflict Detection to be a separate component, it would need to be installed, con- figured for communication (keys, Policy and Management Repository location(s), etc.), logging, and any configu- ration for the component itself, such as the Policy Tar- gets for which it may be responsible, valid Policy Types and Policy Conditions, etc. 4.7.3. Policy Repository The Policy Repository will also require administration. The amount of administration required will depend on the technology chosen for the repository. A general purpose mechanism may require more administration effort than a purpose specific repository technology. If an LDAP enabled directory is used, and the directory is being used for other purposes within an IT environ- ment, the tasks of installation and configuration will mainly already be covered. In addition any security configuration and optional replication configuration specific to Policy Management would be required. Mahon,Bernet,Herzog Expires March 2000 [Page 31]
Internet Draft Policy Requirements October 1999 Additional administration may be required to provide access control for who or what is allowed to modify data in the portions of the repository used for Policy. 4.7.4. Policy Management Repository The Policy Management Repository would need to be installed, configured with any security information, and possibly configured for which repositories from which it can receive information. If additional Policy Manage- ment Repositories are installed to address scalability for receiving information from Policy Consumers, it must also be configured with information about the upstream Policy Management Repository to which it reports status and configuration information from Policy Consumers. Logging would also need to be configured. 4.7.5. Policy Consumers The function and implementation of Policy Consumers could vary (see section 2.1), so issues of administra- tion may not apply to all Policy Consumers. At a minimum security information would need to be con- figured during or after installation. So would informa- tion about how to contact the Policy Repository and (if separate from the Policy Repository) the Policy Manage- ment Repository. Optionally, the Policy Consumer may be configured for the Policy Targets for which it is responsible. This configuration may be done at the Pol- icy Consumer, at the Policy UI, or be automated as part of a discovery process. Logging may also need to be configured. 4.7.6. Policy Targets Policy Targets (or the device which contains multiple Targets) may need to be configured in order to work in the Policy Management System. Such configuration items could include security configuration (keys, passwords, ACLs, etc.), logging, Policy Consumers (if implemented off of the device containing the Policy Target), etc. 4.8. Policy Conditions There are multiple types of Policy Conditions that could be used. The following sections describe two types of Policy Conditions and how they are used. 4.8.1. Time/Date Conditions The policyTimePeriodCondition described in [INFOMODEL] provides the ability to specify when a Policy Action may Mahon,Bernet,Herzog Expires March 2000 [Page 32]
Internet Draft Policy Requirements October 1999 take place. This allows great flexibility in allowing (or disallowing) particular usages of the network. Often used examples of how time-based policies would be used are to allow a set of users to have improved QoS during business hours, an Accounting department to have better QoS on the 15 and the last three days of the month, and to give nightly backups priority during spec- ified hours during the night. Time is intended to be used as a period during which the Action portion of the Policy Rule could be enacted (depending on any other conditions which may be present in the Condition portion of the Policy Rule). Time is not intended to provide an event, or single point in time which causes a specified action to occur (as in a UNIX 'cron' job), but provide a time specification on other conditions which may be observed when an event which causes policy interpretation to occur. The attributes of the policyTimePeriodCondition are: ptpConditionTime ptpConditionMonthOfYearMask ptpConditionDayOfMonthMask ptpConditionDayOfWeekMask ptpConditionTimeOfDayMask ptpConditionTimeZone 4.8.2. Packet Conditions Packet Conditions are based on characteristics that may be observed in the packet itself. For layer 3 devices dealing with IP such characteristics which may be directly observed include: - Destination IPaddress - Destination IPport - Destination IPsubnet - IPaddress (matches either source or destination) - IPport (matches either source or destination) - IPsubnet (matches either source or subnet) - Source IPaddress - Source IPport - Source IPsubnet - Type of Service - IP precedence bits Source and destination subnet may be inferred from the IP address information (the condition would contain the subnet mask to allow determination of affinity). Mahon,Bernet,Herzog Expires March 2000 [Page 33]
Internet Draft Policy Requirements October 1999 Devices with sufficient capability may be able to look at other portions of the packet, below layer 3 and above layer 3. Such other information that may be observed include: - Application Traffic (if not clear from the Port number used, or more detailed than the Port number reveals) - Protocol Type (IP, IPX, ARP, DECNet, Appletalk, SNA over Ether) - URL - VLAN ID These conditions may allow an Administrator to infer who (i.e., users associated with IP addresses) or what (i.e., what applications) are using the network, or both, and specify what type of QoS is to be provided to those uses of the shared network resources. See section 5 for examples. Such bindings are made more reliable when binding information received in signaling messages is leveraged. 4.9. Implementation examples Quite a bit has been described above about how Policy data and other information related to Policy would be shipped from one component to another. In discussions of Policy Management Systems the subject of 'What would be the best protocol?' always seems to come up. The short answer is that there is no 'perfect' protocol because each has strengths and shortcomings. The following sections will describe the most common candidates for transporting infor- mation within a Policy Management System 4.9.1. LDAP While LDAP is often associated with a Directory Service, it is simply the protocol for transporting information stored within the Directory and accessing the informa- tion in the Directory. LDAP does not specify the Direc- tory itself. LDAP is designed to provide access to information for clients dispersed across a network. LDAP is not well suited to providing this access for information that changes often (on the order of minutes), nor is it well suited for passing messages between clients. LDAP cur- rently does not provide mechanisms for notifying clients when information they care about changes in the server. Mahon,Bernet,Herzog Expires March 2000 [Page 34]
Internet Draft Policy Requirements October 1999 LDAP is optimized to have data written to the directory once, and then read thousands of times. +-------------------+ |Policy Mmgt App. | | - Policy UI | | - Conflict detect | | - Notification | | - Mgmt repos. | | | | | +-------------------+ ^ | ^ | | |LDAP | | | | | |Policy Data | | V | | +------------+ | | |Policy rep | | | | | | | | | | | +------------+ | |notif. / status | | /Policy data and config| | /LDAP info | v v +---------------+ | Policy | | Consumer | | | +---------------+ ^ ^ | \ | \ V V +-----------+ +-----------+ | Policy | | Policy | | Target A | | Target B | | | | | +-----------+ +-----------+ Figure 6. Diagram of a Policy Management System using LDAP. Figure 6 is a modification of Figure 3 showing where LDAP would be used for providing data within a Policy Management System. The Policy Management Application would retrieve Policy Data from the Directory Service via LDAP in order to allow the Administrator to view or modify existing pol- icy. The Policy Management Application would also use LDAP to write new or modified Policy Data to the Mahon,Bernet,Herzog Expires March 2000 [Page 35]
Internet Draft Policy Requirements October 1999 Directory Server acting as the Policy Repository. The Policy Consumer would either poll the Policy Reposi- tory via LDAP or be notified by the Policy Management Application via other means that new Policy is available for the Policy Consumer to read. Where the Policy would be stored in an LDAP enabled Directory is also an open issue. For many reasons it does not make sense to define a canonical location to be used in all Directories. There also needs to be an association between the Policy Data and the Policy Targets the Policy Data affects. This information about the association may be stored in the Directory or elsewhere. If the association were stored in the Directory, and the schema for the associa- tion were standardized, the Policy Consumer could then search the directory for the appropriate attribute which stores the reference for the Policy Targets for which it is responsible. The association object would then pro- vide a pointer to the Policy for the Policy Targets. If the association between Policy Data and the Policy Targets were not stored in the Directory, then the mech- anism that notifies the Policy Consumer of new policy should also provide information about where to find the Policy Data in the Directory. This may be a more eco- nomical method for the Policy Consumer to find the Pol- icy Data in the Directory since it would require less of the Directory's resources (i.e., no search would be required). For the notification, the same, or yet another protocol could be used to allow status to be sent to the Policy Management Repository. Taking the list of deployment steps from section 3 and putting in the detail of using LDAP, we would have: A. Administrator authors new policy (or edits existing policy) Aa. Administrator retrieves existing policy from Direc- tory Service using LDAP and views or edits policy B. Administrator associates policy with Policy Tar- gets. C. Policy and association with Policy Targets is stored in Policy Repository via LDAP. Mahon,Bernet,Herzog Expires March 2000 [Page 36]
Internet Draft Policy Requirements October 1999 D. For each of the Policy Targets, the associated Pol- icy Consumers are notified that new policy is available for the Policy Targets using Protocol X. E. The Policy Consumer obtains the Policy from the Policy Repository via LDAP. (The Policy Consumer may issue a query to determine where to find the Policy Data.) F. The Policy Consumer processes the Policy Data and configures the Policy Target(s) using the appropri- ate mechanism(s) for the Target(s). (A standard- ized interface between between the Policy Consumers and Policy Targets would would support the require- ment of commonality across devices, with all of the attendant benefits.) G. For each Policy Target which received Policy Data, the Policy Consumer provides status information back to the Policy Management Application via Pro- tocol Y. An added benefit of using LDAP is that any LDAP client may obtain Policy Data (as long as the client is autho- rized to access that information). LDAP supports authentication of clients and privacy for data transported across the network. LDAP also has mechanisms for replication between multi- ple LDAP servers which enables scaling. As a primary means for storing Policy information, LDAP does not support versioning of the data, nor, for that matter, does the Policy Core Information provide for versioning of the Policy data. 4.9.2. SNMP SNMP provides asynchronous communications in both direc- tions, although not symmetrical in nature. Using Figure 6, SNMP could be the transport to provide the notification using a 'Set' operation on a MIB, with information about what Policy is to be used for each Policy Target for which the Policy Consumer is responsi- ble. The Policy Consumer in return could send status back to the Policy Management Application at any time using SNMP traps. One drawback is that most SNMP implementations use UDP. If UDP were used the Policy Management Application and Policy Consumers would need to provide feedback to each Mahon,Bernet,Herzog Expires March 2000 [Page 37]
Internet Draft Policy Requirements October 1999 other to ensure messages were actually received. SNMP over TCP would allow communications between the Policy Consumers and Policy Management Application to be robust. Implementations of SNMP over TCP already exist. SNMP could be used on all of the data paths in Figure 6, not only notifying the Policy Consumers of new Policy Data, but delivering Policy Data as well, eliminating the need for the Policy Consumer to query the Policy Repository. For a TCP-based SNMP implementation a connection would be established and maintained in order to allow messages to be sent quickly between the client and server. Taking the list of deployment steps, using an all SNMP solution would yield: A. Administrator authors new policy (or edits existing policy) Aa. Policy UI retrieves existing policy from Policy Repository using SNMP Get and Administrator views or edits policy B. Administrator associates policy with Policy Tar- gets. C. Policy and association with Policy Targets is stored in Policy Repository via SNMP Set. D. For each of the Policy Targets, the associated Pol- icy Consumers are provided with new policy for the Policy Targets using SNMP Set commands. E. The Policy Consumer processes the Policy Data and configures the Policy Target(s) using the appropri- ate mechanism(s) for the Target(s). F. For each Policy Target which received Policy Data, the Policy Consumer provides status information back to the Policy Management Application via SNMP Traps. A mechanism for replicating data among Policy Management Applications using only SNMP would need to be defined to enable scaling of the solution for many thousands of Policy Targets. Figure 7 shows how an all SNMP solution would look while still using an LDAP enabled Directory as an export mech- anism to other Policy Management Applications. Undeter- mined is any mechanism (or requirement) for notification Mahon,Bernet,Herzog Expires March 2000 [Page 38]
Internet Draft Policy Requirements October 1999 to other Management Applications of new policy. +-------------------+ |Policy Mmgt App. | | - Policy UI | | - Conflict detect | +-----------+ | - Notification | |Policy | | - Mgmt repos. | LDAP |Repository | | |<------->|(Directory | | | | Server) | +-------------------+ +-----------+ ^ | SNMP| |SNMP | | | |Policy status | |Data and config| | info | v +---------------+ | Policy | | Consumer | | | +---------------+ ^ ^ | \ | \ V V +-----------+ +-----------+ | Policy | | Policy | | Target A | | Target B | | | | | +-----------+ +-----------+ Figure 7. SNMP is used for all communication between Policy Management Application and Policy Consumer. With SNMPv3, features are introduced which provide secure communications (privacy and integrity) between the components of the Policy Management System. 4.9.3. COPS Like SNMP, COPS provides asynchronous yet asymmetrical communications between a client and server, and is based on TCP. An appropriate COPS client type could provide objects for notification to a Policy Consumer, as well as allow the Policy Consumer to send status information to the Policy Management Application asynchronously. In addi- tion, the COPS client type could define objects to enable delivery of Policy Data for Policy Targets using COPS decision messages. Mahon,Bernet,Herzog Expires March 2000 [Page 39]
Internet Draft Policy Requirements October 1999 For COPS communications between the Policy Management Application and the Policy Consumers a connection would be established and maintained in order to allow messages to be send quickly. Taking the list of deployment steps, an all COPS solu- tion could look like: A. Administrator authors new policy (or edits existing policy) Aa. Policy UI retrieves existing policy from Policy Repository using a COPS request message and Admin- istrator views or edits policy. B. Administrator associates policy with Policy Tar- gets. C. Policy and association with Policy Targets is stored in Policy Repository via COPS request. D. For each of the Policy Targets, the associated Pol- icy Consumers are provided with new policy for the Policy Targets using COPS decision messages. E. The Policy Consumer processes the Policy Data and configures the Policy Target(s) using the appropri- ate mechanism(s) for the Target(s). F. For each Policy Target which received Policy Data, the Policy Consumer provides status information back to the Policy Management Application via COPS status response messages. A mechanism for replicating data among Policy Management Applications using only COPS would need to be defined to enable scaling of the solution for many thousands of Policy Targets. For a COPS solution, Figure 7 could be altered to use 'COPS' instead of 'SNMP'. COPS currently has no built-in mechanisms to provide private communications between components, but [COPS] now defines an integrity object to enable a client to verify it received a valid message. 4.9.4. HTTP HTTP is a protocol that is available on many devices and host systems today. It does provide asynchronous capa- bilities between client and server. Typical HTTP con- nections are short-lived but that is not a requirement. Mahon,Bernet,Herzog Expires March 2000 [Page 40]
Internet Draft Policy Requirements October 1999 The Policy Consumer or the Policy Management Application could act as the server. Because the Policy Management Application should be more stable than the Policy Con- sumers, the Policy Management Application is more the candidate for being an HTTP server. Regardless, all that is necessary is for a connection to be established before either end needs to send a message to the other. Again using the list of deployment steps, an all HTTP solution would look like: A. Administrator authors new policy (or edits existing policy) Aa. Policy UI retrieves existing policy from Policy Repository using an HTTP Get message and Adminis- trator views or edits policy. B. Administrator associates policy with Policy Tar- gets. C. Policy and association with Policy Targets is stored in Policy Repository via Post request. D. For each of the Policy Targets, the associated Pol- icy Consumers are provided with new policy for the Policy Targets via responses to Get messages from Policy Consumer. E. The Policy Consumer processes the Policy Data and configures the Policy Target(s) using the appropri- ate mechanism(s) for the Target(s). F. For each Policy Target which received Policy Data, the Policy Consumer provides status information back to the Policy Management Application via HTTP Post messages. A mechanism for replicating data among Policy Management Applications using only HTTP would need to be defined to enable scaling of the solution for many thousands of Policy Targets. For an HTTP solution, Figure 7 could be altered to use 'HTTP' instead of 'SNMP'. HTTP supports use of SSL to secure communications allow- ing authentication and privacy during data transfer. 4.10. Policy Interpretation One of the important ideas behind Policy Management is that a Policy may be used across multiple devices (Policy Mahon,Bernet,Herzog Expires March 2000 [Page 41]
Internet Draft Policy Requirements October 1999 Targets) which collectively provide a service. This use of Policy would allow those devices to provide a consistent level of service. This means that each of these Policy Targets must interpret the Policy (and the Policy Rules that make up the Policy) in the same way. As noted in section 4.4.2 the current Policy Core Informa- tion Model does not ensure that any two Policy Consumers (or their Policy Targets) will interpret Policy because it does not specify an unambiguous method for resolving con- flict between multiple Policy Rules which may simultane- ously evaluate true. 4.11. Policy Information Policy used by a Policy Consumer MUST come from a single source (i.e. a single Policy Repository). That Policy MUST be in the form of a single grouping of Policy Rules. Without this grouping, the administrator is not assured of seeing all of the Policy Rules which may be associated with a Policy Target. Without this ability to see all of the Policy Rules associated with a Policy Target there is no way for the Administrator to be assured that under a given set of conditions (as specified by Policy Conditions) that a Policy Target will act in accordance with the wishes of the Administrator. 5. 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 Mahon,Bernet,Herzog Expires March 2000 [Page 42]
Internet Draft Policy Requirements October 1999 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. 5.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 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, Mahon,Bernet,Herzog Expires March 2000 [Page 43]
Internet Draft Policy Requirements October 1999 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: 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. Mahon,Bernet,Herzog Expires March 2000 [Page 44]
Internet Draft Policy Requirements October 1999 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 (as described in section 2.1). First is the representation in Policy Schema terms of what the above Policy Rule would translate into: 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 March 2000 [Page 45]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 46]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 47]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 48]
Internet Draft Policy Requirements October 1999 '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 March 2000 [Page 49]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 50]
Internet Draft Policy Requirements October 1999 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.) 5.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. 5.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 March 2000 [Page 51]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 52]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 53]
Internet Draft Policy Requirements October 1999 IPport conditions as described earlier allow an Administra- tor to classify traffic by type. (Other ways are described in section 4.8.2.) 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 Mahon,Bernet,Herzog Expires March 2000 [Page 54]
Internet Draft Policy Requirements October 1999 limited to the NFS server could be done with the following: 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 (as described in section 4.2). +-------+--------+ | Int3 | | | +----------+ |Router | |NFS Server| R&D subnet | TargetB| | | +----------+Int1 Int2+-----------+ | | |TargetA | | | +--+-----+ | | | | |User PC | | | +----------+ | | | Int4 | +--------+ +-------+--------+ Figure 8. 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 Mahon,Bernet,Herzog Expires March 2000 [Page 55]
Internet Draft Policy Requirements October 1999 going to the subnet with the NFS server is controlled. The other Rule: 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 5.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 Mahon,Bernet,Herzog Expires March 2000 [Page 56]
Internet Draft Policy Requirements October 1999 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 crit- ical 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. 5.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 March 2000 [Page 57]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 58]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 59]
Internet Draft Policy Requirements October 1999 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). 5.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. 5.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 March 2000 [Page 60]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 61]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 62]
Internet Draft Policy Requirements October 1999 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. 5.6.4. Signaled QoS Usage Case I - IP Telephony Consider the following network topology: Mahon,Bernet,Herzog Expires March 2000 [Page 63]
Internet Draft Policy Requirements October 1999 +-------+ +-------+ +-------+ | | | | | | |host 1 | |host 2 | |host 3 | | | | | | | +-------+ +-------+ +-------+ | | | | | | +-----------+-----------+ | | | +-----+------+ | | | PEP 1 +---------+ | | | | | | +---------+ +-----+------+ | | | | | | | | +----+ PDP | | 1544kbps link | | | | | | | | | +---------+ +-----+------+ | | | | | PEP 2 | | | +---------+ | | +------------+ | | 64kbps linl | +-----------+-----------+ | | | | | | +--+----+ +--+----+ +--+----+ | | | | | | |host 4 | |host 5 | |host 6 | | | | | | | +-------+ +-------+ +-------+ Figure 9. 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 March 2000 [Page 64]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 65]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 66]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 67]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 68]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 69]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 70]
Internet Draft Policy Requirements October 1999 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. 5.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 March 2000 [Page 71]
Internet Draft Policy Requirements October 1999 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 March 2000 [Page 72]
Internet Draft Policy Requirements October 1999 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) 6. Security Considerations For QoS related Policy, the security needs of a Policy Manage- ment System require authentication at a minimum. The Policy Management System contains components which send messages and read and write data. The interactions which involve writing of data MUST ensure authentication of both parties. In other words, when a Policy Consumer connects to a Policy Management Repository, in which the Policy Consumer writes status and configuration informa- tion to the Policy Management Repository, the Policy Consumer must authenticate itself to the Policy Management Repository, and vice-versa. The reason for this is that either end of the communication could be false. If a true Policy Consumer wrote data to a false Policy Management Repository, the Administra- tor will not see the true data. If a false Policy Consumer wrote data to a true Policy Management Repository, the Admin- istrator will see false data. Either situation means that the Administrator does not know the true state of Policy configu- ration in the networked environment. Similar requirements exist for the connection of the Policy UI to the Policy Repos- itory and Policy Management Repository. Mahon,Bernet,Herzog Expires March 2000 [Page 73]
Internet Draft Policy Requirements October 1999 When Policy is used for security purposes, it MUST be encrypted when being transported over the network. Repositories must be as secure as reasonably possible. If a Repository resides on a general purpose host, access to the Repository data should be controlled and monitored. If the data cannot be so secured, other means, such as encryption of data in the repository, or other methods ensuring integrity should be employed. 7. Summary Policy Based Management is not just a buzz word, or a solution looking for a problem. There is a genuine need for allowing network Administrators to be more effective by managing the network as a collective, not as a collection of individual devices each requiring a separate set of knowledge. Today's tools allow Administrators to configure the devices which enable traffic, but the view they present to Administra- tors is limited, and the management of a device is the focus of the activities with those tools. Policy information, as described in [INFOMODEL] allows that abstraction, but additional information is needed to make Pol- icy useful. Information such as the targets of Policy, attributes about those targets, and the association between Policy and the targets must be further defined. Additionally, the actual architecture of a Policy Management System must be further defined in order to allow multiple ven- dors to have interoperable implementations. The details of such an architecture include making the Policy information available in a timely manner, and providing the Administrator (and, in the future, tools) with information about the charac- teristics of Policy Targets in order to allow validation of Policy and conflict detection. Additionally, Administrators need to know if Policy deployment was successful in order to know if the network will work as expected so they don't have to wait for users of the network to tell them there's a prob- lem. Key questions have now been discussed in a document. Such questions as "What protocols should be used?" and the role of the Policy Consumer and Policy Consumer are covered in detail in this document. New requirements not already documented elsewhere are also documented here, such as security, versioning of Policy Data, and timely delivery of Policy Data. To finish the summation of this document, below are bullet lists of the requirements of a Policy Management System. The Mahon,Bernet,Herzog Expires March 2000 [Page 74]
Internet Draft Policy Requirements October 1999 items marked with an asterisk are yet to be fully defined. Policy Data - Policy, contains one or more Rules - Rule, contains one or more Actions and one or more condi- tion lists - Action, schema definition exists, but few proposals for types * - Condition list, contains one or more conditions - Condition, schema definition exists, but few proposals for types * - Policy Target *, contains attributes: - name - properties relative to policies supported - status - Policy Consumer * - Association between Policy and Policy Target * (currently called 'Jurisdiction' or 'Role', but not well defined) Policy Architecture Features - Policy repository communication (e.g., LDAP) - Policy repository (may be settled by above question, e.g., if communication is LDAP) - Notification to Policy Consumer of new/changed policy * - Versioning of Policy Data * - Status reporting mechanism from Policy Consumer * 8. 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 Mahon,Bernet,Herzog Expires March 2000 [Page 75]
Internet Draft Policy Requirements October 1999 with respect to rights in standards-track and standards- 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. 9. 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- framework-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", Internet Draft draft- Mahon,Bernet,Herzog Expires March 2000 [Page 76]
Internet Draft Policy Requirements October 1999 ietf-rap-cops-07.txt, August 16, 1999. [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. 10. Acknowledgements Special thanks to Mark Stevens, Bob Moore, Andrea Westerinen, Avri Doria, Cheh Goh, 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 guid- ance on what should be discussed in this document. 11. 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 IPHighwayw Parker Plaza, 16th Floor 400 Kelby St. Fort-Lee NJ 07024 201.585.0800 herzog@iphighway.com Mahon,Bernet,Herzog Expires March 2000 [Page 77]
Internet Draft Policy Requirements October 1999 12. Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. 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 March 2000 [Page 78]
Internet Draft Policy Requirements October 1999 1. Introduction ......................................... 3 2. A Simple Policy Management System .................... 6 2.1 The Policy Consumer and Policy Target ............... 8 3. Policy Management in Action .......................... 10 3.1 Information Visible to the Administrator ............ 11 3.2 Policy Deployment Actions ........................... 12 3.2.1 Policy Configuration Usage ........................ 12 3.2.2 Results of Policy Configuration ................... 14 3.3 Alternate Architectures ............................. 14 3.3.1 Policy Status and Configuration Information ....... 14 3.3.2 Policy Notification ............................... 16 4. General Policy Management Issues ..................... 18 4.1 Provisioned vs. Signaled QoS Mechanisms ............. 18 4.2 Policy assignment ................................... 20 4.2.1 Policy applicability .............................. 22 4.3 Policy Operation .................................... 22 4.3.1 Policy Size ....................................... 23 4.3.2 Policy Capability ................................. 24 4.4 Policy Conflicts .................................... 25 4.4.1 Conflict Between Two Rules Within a Policy ........ 25 4.4.2 Conflicts Between Actions Within a Rule ........... 26 4.5 Time aspects of policy .............................. 26 4.6 Scalability ......................................... 27 4.6.1 Scalability and Policy Targets .................... 27 4.6.2 Scalability and Policy Consumers .................. 28 4.6.3 Scalability and the Repositories .................. 28 4.6.4 Scalability and the Policy Management Applica- tion ............................................... 29 4.7 Administration of the Policy Management System ...... 29 4.7.1 Policy UI ......................................... 31 4.7.2 Policy Conflict Detection ......................... 31 4.7.3 Policy Repository ................................. 31 4.7.4 Policy Management Repository ...................... 32 4.7.5 Policy Consumers .................................. 32 4.7.6 Policy Targets .................................... 32 4.8 Policy Conditions ................................... 32 4.8.1 Time/Date Conditions .............................. 32 4.8.2 Packet Conditions ................................. 33 4.9 Implementation examples ............................. 34 4.9.1 LDAP .............................................. 34 4.9.2 SNMP .............................................. 37 4.9.3 COPS .............................................. 39 4.9.4 HTTP .............................................. 40 4.10 Policy Interpretation .............................. 41 4.11 Policy information ................................. 42 5. Usage Cases .......................................... 42 5.1 An Accounting Department Example .................... 43 5.1.1 Policy Consumer For an Existing (Legacy) Device .................................................... 48 5.1.2 Policy Consumer for a Policy Aware Device ......... 51 5.1.3 Other Policy Consumer Uses ........................ 51 5.2 New Traffic in the Net .............................. 52 Mahon,Bernet,Herzog Expires March 2000 [Page 79]
Internet Draft Policy Requirements October 1999 5.3 Traffic Classification With Packet Conditions ....... 53 5.4 Other Uses of Policy ................................ 56 5.5 Network Failure ..................................... 57 5.6 The Role of Signaling in Policy Management .......... 60 5.6.1 Classification Assumptions Implicit in Top-Down Provisioning ....................................... 60 5.6.2 Snooping Signaling Messages to Glean Classifica- tion Information ................................... 61 5.6.3 Offering High Quality Guarantees .................. 62 5.6.4 Signaled QoS Usage Case I - IP Telephony .......... 63 5.6.5 Signaled QoS Usage Case II - SAP .................. 67 5.7 Policy in an Engineered Network ..................... 69 5.8 Combination of Policies ............................. 71 6. Security Considerations .............................. 73 7. Summary .............................................. 74 8. Intellectual Property ................................ 75 9. References ........................................... 76 10 Acknowledgements ..................................... 77 11. Author Information .................................. 77 12. Full Copyright Statement ............................ 78 Mahon,Bernet,Herzog Expires March 2000 [Page 80]
