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 ............... 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 Mahon,Bernet,Herzog Expires March 2000 [Page 2] Internet Draft Policy Requirements October 1999 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 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 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 t