Internet Draft Hugh Mahon Expiration: March 2000 Hewlett-Packard File: draft-ietf-policy-req-00.txt 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 policy based management, what should hap- pen in a policy management system, current definitions, addi- tional areas for definition, and why a new kind of management is required. In addition examples of policies as they are expected to be used are provided in a Usage Cases section. The goal for this document is to provide a set of requirements for further development of standards for policy management systems. There has already been work in the area of policy management and the Internet Draft Policy Requirements September 1999 work to date is described as well as additional areas to be defined. For readers in a hurry the Introduction section on Usage Cases (section 5) will provide a great deal of information. Readers interested in more detail about various aspects of Policy Manage- ment should read from the beginning of the document. 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 .................... 5 2.1 The Policy Consumer and Policy Target ............... 6 3. Policy Management in Action .......................... 9 3.1 Information Visible to the Administrator ............ 9 3.2 Policy Deployment Actions ........................... 10 3.2.1 Policy Configuration Usage ........................ 11 3.2.2 Results of Policy Configuration ................... 12 3.3 Alternate Architectures ............................. 13 3.3.1 Policy Status and Configuration Information ....... 13 3.3.2 Policy Notification ............................... 15 4. General Policy Management Issues ..................... 17 4.1 Policy assignment ................................... 17 4.1.1 Policy applicability .............................. 19 4.2 Policy Operation .................................... 19 4.2.1 Policy Size ....................................... 20 4.2.2 Policy Capability ................................. 21 4.3 Policy Conflicts .................................... 22 4.3.1 Conflict (Inconsistency) Between Policies ......... 22 4.3.2 Rule Conflict Within a Policy ..................... 24 4.4 Time aspects of policy .............................. 24 4.5 Scalability ......................................... 25 4.5.1 Scalability and Policy Targets .................... 26 4.5.2 Scalability and Policy Consumers .................. 26 4.5.3 Scalability and the Repositories .................. 26 4.5.4 Scalability and the Policy Management Applica- tion............................................... 27 4.6 Administration of the Policy Management System ...... 28 4.6.1 Policy UI ......................................... 29 4.6.2 Policy Conflict Detection ......................... 29 4.6.3 Policy Repository ................................. 30 4.6.4 Policy Management Repository ...................... 30 4.6.5 Policy Consumers .................................. 30 4.6.6 Policy Targets .................................... 30 4.7 Policy Conditions ................................... 31 4.7.1 Time/Date Conditions .............................. 31 4.7.2 Packet Conditions ................................. 31 4.8 Implementation examples ............................. 32 4.8.1 LDAP .............................................. 32 4.8.2 SNMP .............................................. 35 Mahon Expires March 2000 [Page 2]
Internet Draft Policy Requirements September 1999 4.8.3 COPS .............................................. 37 4.8.4 HTTP .............................................. 39 4.9 Policy Interpretation ............................... 40 4.10 Policy information ................................. 40 5. Usage Cases .......................................... 40 5.1 An Accounting Department Example .................... 41 5.1.1 Policy Consumer For an Existing (Legacy) Device .................................................... 47 5.1.2 Policy Consumer for a Policy Aware Device ......... 49 5.1.3 Other Policy Consumer Uses ........................ 50 5.2 New Traffic in the Net .............................. 50 5.3 Traffic Classification With Packet Conditions ....... 52 5.4 Other Uses of Policy ................................ 55 5.5 Network Failure ..................................... 56 6. Security Considerations .............................. 59 7. Summary .............................................. 59 8. Intellectual Property ................................ 61 9. References ........................................... 62 10 Acknowledgements ..................................... 62 11. Author Information .................................. 62 12. Full Copyright Statement ............................ 63 1. Introduction Computer networks enable users to share information, whether it is with the person at the next desk, or another point on the globe. The technologies behind this unprecedented access to information are complex, yet they must be managed if net- works are to be relied upon by users. Existing management tools focus on individual components on the network. SNMP, for example, uses management information (MIBs) which are focused on specific devices, or detailed functions. This gives administrators great flexibility in controlling the devices, but because it is focused on the individual elements, limits managers' ability to manage the network as an aggregate of the capabilities represented by the individual pieces. Managing a network, not individual devices, will require abstractions that can apply across not just devices, but logi- cal elements on network elements as well as host systems. In addition, the management information must be easy to assign and deploy to multiple entities from a single location. Mahon Expires March 2000 [Page 3]
Internet Draft Policy Requirements September 1999 While many of these pieces of functionality currently exist in one form or another, no existing single system provides the high-level abstraction and ease of deployment which enable network Administrators to easily map user needs to how the network treats traffic. A standard for such a management sys- tem would enable interoperability of management products among multiple vendors. Even if existing techniques are used to communicate the policy data, few, if any, devices using existing management technolo- gies would be equipped to perform the necessary translation between high-level policy abstractions and low-level device configuration. Policy based management is the technology intended to address this next step in managing the network; managing the network as the sum of its parts. Providing this capability means providing a higher level view of the network. One analogy of policy based management rela- tive to network element management is high-level programming languages relative to assembler language. In both policy based management and high level programming languages, the intent is to focus on the desired result, not the device spe- cific mechanisms which produce the result. Translators spe- cific to the actual devices (e.g., routers or firewalls for policy, CPUs for programming languages) convert from the higher-level information to the operations on the device. Taking the analogy even further, it is evident that policy based management is a distributed processing system, and is not specific to a single system, either in implementation or in terms of what is to be managed. The components of policy based management are necessarily distributed across the net- work, if only because the components being managed are dis- tributed across the network. The logical components of the policy based management system may reside on a single machine, but most likely the UI, repository, and Policy Consumers will be distributed across elements (e.g., routers, firewalls, host systems, probes, other dedicated devices) attached to the net- work. There are already examples of distributed systems today. They each have their own strengths and shortcomings. The purpose of this draft is not to specify technologies, but to describe the set of requirements for a policy management system. The requirements include data and functionality. The essential difference between Policy Based Management and most existing forms of management today is that a Policy Sys- tem: Mahon Expires March 2000 [Page 4]
Internet Draft Policy Requirements September 1999 1. Allows the same management information to be used across different kinds of 'things' (devices, software processes, etc.). One way of doing this is to provide abstractions of functionality or behaviors. 2. Allows administration of multiple things in parallel from a centralized management location, removing from the administrator the burden of manipulation of individual 'things' each time a management change is to be made. This is in contrast to most existing tools which are specific to the thing being managed, and manage one thing at a time. The rest of this document describes multiple usage scenarios. The implications of the usage scenarios are discussed, as well as other aspects of policy based management discussed in vari- ous working groups within the IETF. Finally, these issues are used as the basis for specifying the requirements for a policy based management system. 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 Expires March 2000 [Page 5]
Internet Draft Policy Requirements September 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 +------------+ +-----------+ +-----------+ |RSVP enabled| Policy | Policy | | Policy | |device | Targets | Target A | | Target B | | | | | | | +------------+ +-----------+ +-----------+ Figure 1. A simple schematic of a Policy Based Network Management System. 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. 2.1. The Policy Consumer and Policy Target There are two essential functions when viewing the managed environment: 1. dealing with the management information Mahon Expires March 2000 [Page 6]
Internet Draft Policy Requirements September 1999 2. implementing the functionality/behavior specified by the mangement 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 a packet). In this real-time pol- icy 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). 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). Mahon Expires March 2000 [Page 7]
Internet Draft Policy Requirements September 1999 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. This scenario is more likely to occur with DiffServ related policies (that is, non-signaled QoS mechanisms) than with IntServ related policies. It should be noted that where policy is converted (or the decision is made) is an implementation decision, and there is no single best answer for all desired opti- mizations. 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 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. Mahon Expires March 2000 [Page 8]
Internet Draft Policy Requirements September 1999 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. 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. 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 Mahon Expires March 2000 [Page 9]
Internet Draft Policy Requirements September 1999 document 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 Policy Framework Working Group. There are, however, func- tions 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. 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. Mahon Expires March 2000 [Page 10]
Internet Draft Policy Requirements September 1999 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: 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 Mahon Expires March 2000 [Page 11]
Internet Draft Policy Requirements September 1999 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. 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. Mahon Expires March 2000 [Page 12]
Internet Draft Policy Requirements September 1999 Once feedback from the Policy Consumer is sent to a repository, it should be represented on the UI 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 Expires March 2000 [Page 13]
Internet Draft Policy Requirements September 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 Expires March 2000 [Page 14]
Internet Draft Policy Requirements September 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.4 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 Expires March 2000 [Page 15]
Internet Draft Policy Requirements September 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 Expires March 2000 [Page 16]
Internet Draft Policy Requirements September 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. 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 Expires March 2000 [Page 17]
Internet Draft Policy Requirements September 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 Expires March 2000 [Page 18]
Internet Draft Policy Requirements September 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.1.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.2. 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 Expires March 2000 [Page 19]
Internet Draft Policy Requirements September 1999 used with devices with limited capabilities. 4.2.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 Expires March 2000 [Page 20]
Internet Draft Policy Requirements September 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.2.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 Expires March 2000 [Page 21]
Internet Draft Policy Requirements September 1999 conditions. See sections 4.4 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.3. Policy Conflicts There are two types of policy conflicts that could exist: 1. conflicts between two policies 2. more than one rule within the same policy evaluating 'true' in a given circumstance 4.3.1. Conflict (Inconsistency) Between Policies When multiple policies are deployed throughout the net- work it is possible that the behavior specified in one location will not be the same as behavior specified in another location. +----------+ +----------+ |Net Elem A| |Net Elem B| LAN Alpha | | LAN Beta | | LAN Gamma +----------+Int1 Int2+------------+Int3 Int4+---------- | | | | | +--+-----+ | | | | |User PC | +----------+ +----------+ | | +--------+ Figure 5. In Figure 5 there are two network elements, A and B, which are connected together serially, and traffic may pass from LAN Alpha through LAN Beta to LAN Gamma. If a user on LAN Alpha expects to have the same QoS when com- municating with systems on LAN Beta and LAN Gamma, then the subset of policy (i.e., rules) pertaining to the user's traffic (based on address, traffic type, or other characteristic) deployed on the interfaces of network elements A and B must agree. If all of the LANs are being maintained by one IT department, and the user has contracted for 200 kbps for Mahon Expires March 2000 [Page 22]
Internet Draft Policy Requirements September 1999 traffic to systems on LAN Gamma, then the policies deployed on interfaces 1, 2, 3, and 4 must all support at least that much throughput for the user. For instance, if policy deployed to Int2 and Int4 allow 200kbps for traffic coming from the user's machine, and policy deployed to Int1 and Int3 only allowed 150kbps of traffic to the user's PC, then the policies deployed to Int1 and Int3 could be in conflict with the policies deployed to Int2 and Int4. For policy management such a conflict should be detected before the user complains about lower than expected per- formance. The means for such detection would need to be in policy system at a point where the policies are visible. That is, Int1 cannot determine that its policies are in con- flict with Int2 unless it has visibility into the poli- cies for Int2. Network Element A cannot determine that the policies for it are in conflict with the policies for NE B unless it can see the policies for NE B. There are many reasons that make it undesirable for all policy managed entities to see the policy for all other policy managed entities on the network. It makes sense, then, for the function to determine con- flict between policies to be implemented in the policy system before policies are deployed to their targets (or the Policy Consumers for those targets). Determining conflicts such as those described above may not be simple. For example, the difference in through- put for a given type of traffic may be intended, so how would the system realize there is a conflict? One way to detect conflict in the above example would be if the same endpoints were specified (e.g., source or destination IP address or subnet) and for those rules if the actions specified different behaviors there could be a problem. To ensure that the difference were truly conflict (and not a difference desired by the adminis- trator), the conflict detection would need to understand that traffic going to the User PC is traveling from NE B through NE A, and that the difference in values (smaller on NE A) will cause poorer QoS than specified for NE B. Because inter-policy conflict is such an unknown, it recommended that inter-policy conflict not be a require- ment for (early) policy management systems. A standard for policy management systems should, however, allow for the the use of conflict detection functions, or at a minimum not preclude their use. Mahon Expires March 2000 [Page 23]
Internet Draft Policy Requirements September 1999 4.3.2. Rule Conflict 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 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 potential 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 inconsistent QoS for traffic matching the multiple Pol- icy Rules. 4.4. 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.9.1). Mahon Expires March 2000 [Page 24]
Internet Draft Policy Requirements September 1999 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 configura- tion capabilities) would need a Policy Consumer implemented separately from the device. New managed elements 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.2.2). 4.5. 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 Mahon Expires March 2000 [Page 25]
Internet Draft Policy Requirements September 1999 the managed environment. 4.5.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 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.5.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.5.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 Mahon Expires March 2000 [Page 26]
Internet Draft Policy Requirements September 1999 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 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.4). 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.5.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 Mahon Expires March 2000 [Page 27]
Internet Draft Policy Requirements September 1999 - 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.6. 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 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 Mahon Expires March 2000 [Page 28]
Internet Draft Policy Requirements September 1999 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 Sys- tem, but rather to provide a realistic description of the administrative tasks required of such a system. 4.6.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.6.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. Mahon Expires March 2000 [Page 29]
Internet Draft Policy Requirements September 1999 4.6.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. 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.6.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.6.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.6.6. Policy Targets Policy Targets (or the device which contains multiple Targets) may need to be configured in order to work in Mahon Expires March 2000 [Page 30]
Internet Draft Policy Requirements September 1999 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.7. 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.7.1. Time/Date Conditions The policyTimePeriodCondition described in [INFOMODEL] provides the ability to specify when a Policy Action may 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.7.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: Mahon Expires March 2000 [Page 31]
Internet Draft Policy Requirements September 1999 - 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). 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 allow an Administrator to identify 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. 4.8. 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 answer is that there is no 'perfect' protocol because each has strengths and short- comings. The following sections will describe the most common candidates for transporting information within a Policy Management System 4.8.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 Mahon Expires March 2000 [Page 32]
Internet Draft Policy Requirements September 1999 Directory 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. 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. Mahon Expires March 2000 [Page 33]
Internet Draft Policy Requirements September 1999 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 Direc- tory 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) Mahon Expires March 2000 [Page 34]
Internet Draft Policy Requirements September 1999 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. 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). (An interface between the Policy Consumers and Policy Targets, requiring a protocol or not, is not a requirement.) 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.8.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 Mahon Expires March 2000 [Page 35]
Internet Draft Policy Requirements September 1999 responsible. 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 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 Mahon Expires March 2000 [Page 36]
Internet Draft Policy Requirements September 1999 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 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.8.3. COPS Like SNMP, COPS provides asynchronous yet asymmetrical communications between a client and server, and is based on TCP. Mahon Expires March 2000 [Page 37]
Internet Draft Policy Requirements September 1999 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. 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 Mahon Expires March 2000 [Page 38]
Internet Draft Policy Requirements September 1999 verify it received a valid message. 4.8.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. 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. Mahon Expires March 2000 [Page 39]
Internet Draft Policy Requirements September 1999 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.9. Policy Interpretation One of the important ideas behind Policy Management is that a Policy may be used across multiple devices (Policy Tar- gets) 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.3.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.10. 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 Mahon Expires March 2000 [Page 40]
Internet Draft Policy Requirements September 1999 provide information about the types of traffic, not just the volume, can provide the Administrator with information about the traffic related to critical business functions. In addi- tion, if the collected information indicates sources and des- tinations of the traffic, both inside the firewall and through it, the Administrator can relate that to the type of traffic and better understand particular uses. For example, Web traf- fic can be work-related or recreational. Traffic within the company network, such as to a Personnel server, is work- related. Traffic to www.espn.com, though, is probably not work-related, unless the user is a sports reporter. This kind of information, along with direct input from the users of the network (the Administrator's customers) will be the basis for the Policies managing the network. Note that when using the term 'device' it is reasonable to substitute firewall, host computer, software application, operating system, network stack, Network Interface Card (NIC), or any other 'thing' that can be managed. Somehow 'device' just sounds better than 'thing'. Below are some examples of how Policies can be used to address Network Management needs. 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 Mahon Expires March 2000 [Page 41]
Internet Draft Policy Requirements September 1999 take anything away from the users. For this example we'll use a fictional but realistic sce- nario. The Accounting department must issue reports for each month. The pace of sales orders typically increases just before the close of the month. The company has opera- tions dispersed geographically, including sales offices and warehouses. The information for generating the end-of- month reports must be obtained from these different loca- tions by the Accounting department's systems. In addition, each of these different operations are generating their own reports. Accounting traffic can take a significant portion of the network's bandwidth, but Accounting isn't the only user of the network. The reports are due on the first of the month, so traffic gets heavier during the last 10 days of the month. Quarterly reports are due on the 15th of each month, and work on this begins as soon as the previous monthly report is finished. The company in this example has a fiscal year that matches the calendar year, so quar- ters end at the end of March, June, September, and Decem- ber. That means that work on quarterly reports occur in April, July, October, and January. The Accounting depart- ment's systems are on a separate subnet at the corporate 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. Mahon Expires March 2000 [Page 42]
Internet Draft Policy Requirements September 1999 In the above Policy Rule the traffic is being tested for coming from or going to the subnet for the Accounting department. If the traffic is coming from or going to the AccountingSubnet, and it is the last 10 days of the month, or is the first fifteen days of the month after the end of a quarter, then the traffic is given high priority. Instead of comparing against a subnet, the test could be for a set of machines, or could be for a specific applica- tion. The above Policy Rule would be translated into an actual set of device independent information which conforms with the Policy Schema. Since this Policy Rule is likely not the only Policy infor- mation that would be deployed to a set of devices in the network, this example will add other Policy Rules in the set to be deployed to a target (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 Mahon Expires March 2000 [Page 43]
Internet Draft Policy Requirements September 1999 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.) 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 Mahon Expires March 2000 [Page 44]
Internet Draft Policy Requirements September 1999 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 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. Mahon Expires March 2000 [Page 45]
Internet Draft Policy Requirements September 1999 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 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. Once the Policy Management Application received positive notification from all of the affected Policy Consumers, the Policy Management Application would send a second notifica- tion informing them to deploy the Policy to the designated Policy Targets. 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 Mahon Expires March 2000 [Page 46]
Internet Draft Policy Requirements September 1999 operation. 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 'Pol- icy unaware', while the addition of a Policy Consumer for such a device would allow it to work with a Policy Management System. Some of the Policy Rules in Table 1 contain time and date conditions, which are shorthand for the components of the policyTimePeriodCondition class. The Policy Tar- get in this example is the Priority Queuing feature of an interface on a router. The Policy Consumer would receive the Policy Data in a form conformant with the structure described in [INFO- MODEL], including the time conditions. The Policy Con- sumer would validate the Policy Data, then filter the Policy Data based on the time information. For instance, Rule 2 would be translated and sent to the Policy Target (along with other rules in effect) only Monday through Friday, during the hours of 8 AM to 5 PM. At 5 PM Monday through Friday, for example, the Policy Consumer would understand that a time period within a rule has expired which would cause the Policy Consumer to re-evaluate what information should be configured on the Policy Target. In this example, the Policy Consumer would cause the configuration related to Rule 2 to be removed from the Policy Target (because the Rule con- tains one condition list and that condition list con- tains a time condition). At 8AM on Monday through Fri- day the Policy Consumer would again re-evaluate the Pol- icy Data and would add the configuration information relative to Rule 2 to the configuration of the Policy Targets associated with the Policy. The non-time por- tions of the condition list would be converted into an Access Control List (ACL) on the router with the source subnet, destination subnet, and destination IP Port num- ber when the time condition is true. Mahon Expires March 2000 [Page 47]
Internet Draft Policy Requirements September 1999 To continue the example, configuration relating to Rule 3 would always be on the Policy Target since it does not have a time component. The two condition lists would be converted into ACLs for the router, each ACL specifying a source and destination pair. Rule 4 again is subject to time conditions. When one of the time conditions evaluates true an ACL will be con- figured on the router to match traffic with a source subnet matching a multicast address. Rule 5 also contains a time condition and when the time conditions evaluate true, the Policy Target will be con- figured with two ACLs, one matching the address for the backup server as the source address and the other match- ing the destination address to allow traffic going to and coming from the backup server to have better QoS. Rule 6 contains no time conditions, so would be con- verted into an ACL matching port 26000 (the registered port for Quake, a multi-user game) as the source or des- tination port on a packet, and provide it with the low- est priority. If a device has a feature which provides less than best effort priority, this value may be mapped to such a capability on that device. Since Rule 1 has date based conditions, it would be con- verted to an ACL matching the specified subnet as the source or destination subnet during the last 10 days of the month or the first 15 days of a month after the end of the quarter. The ACL would not be configured for Target (for this Rule) during other time periods. (Note, the schema allows PolicyTimePeriodCondition to be attached to the PolicyRule itself rather than be expressed within the Condition List. For simplicity it was represented in the Condition List.) Prior to deploying the Policy configuration to the device hosting the Policy Target, the Policy Consumer will determine the current configuration. If there is a configuration such that a feature which conflicts with the operation of this Target exists, the Policy Consumer will provide feedback to the Policy Management Reposi- tory about the condition and will not deploy the Policy. If there is configuration for the Policy Target which relates to the Policy configuration to be deployed, the Policy Consumer will issue commands (e.g., SNMP set com- mands, Telnet CLI, etc., as appropriate for the device) to delete the configuration or free resources which will no longer be used. At this point the Policy Consumer will actually send the configuration commands to the device in order to cause Mahon Expires March 2000 [Page 48]
Internet Draft Policy Requirements September 1999 the Policy Target to act in accordance with the Policy (as appropriate based on time and date conditions, etc.). Once the Policy Rules based configuration has been sent to the Policy Target(s) the Policy Consumer will deter- mine the success of the deployment and provide feedback to the Policy Management Application. In order to determine the success, for this example, the Policy Con- sumer will query the device and examine the information relating to the configuration of the Policy Target(s) to determine if the configuration now matches what the Pol- icy Consumer expects based on the Policy Data. If no errors were encountered during the deployment and the configuration is correct, the Policy Consumer will report success. This status information would be stored as an attribute of the Policy Target in the Policy Man- agement Repository. As described above, at the start or end of a time/date period expressed in a condition the Policy Consumer would re-evaluate the Policy Rules for the Policy Target and perform the necessary translations, check existing configuration, perform any necessary clean-up, deploy the corresponding configuration, and report status. (Alternatively the Policy Consumer could generate the appropriate information for any given time period speci- fied in the Policy Rules and simply download them at the appropriate times rather than filter at each time bound- ary.) 5.1.2. Policy Consumer for a Policy Aware Device A Policy Aware device is a device which is has the abil- ity to handle Policy in the form specified by the Policy Schema. In other words, a Policy Aware device is one which has a Policy Consumer capability implemented on the device itself. Without dictating the actual implementation, there are reasonable expectations of the functions that would be implemented on a Policy Aware device. Along with the Policy Consumer, which is the interface for receiving Policy, there needs to be local storage of Policy or derived information, interpretation of the Policy which may include translation to configuration, time-keeping to support time and date conditions, and features to provide feedback to the Policy Management Application of the status of Policy deployment as well as any other attributes of the Policy Target(s) related to Policy management. Mahon Expires March 2000 [Page 49]
Internet Draft Policy Requirements September 1999 If the Policy Consumer is implemented on the same device as the Policy Target, how the behaviors dictated by Pol- icy Rules are put in force is implementation specific. 5.1.3. Other Policy Consumer Uses It is possible that a device may be implemented that can handle Policy Information but does not interact directly with the Policy Management Application or Policy Reposi- tory. In this case a simple Policy Consumer may be used to act as a simple proxy between the device and the Pol- icy Management System. Such a Policy Consumer would simply forward Policy Data to the device. The important thing to note is that the only requirement for a Policy Consumer is to act as an interface for Pol- icy Targets with the Policy Management System. How the functionality that needs to occur between the interface to the Policy Consumer and the Policy Target is depen- dent on the implementation. As long as the Policy Con- sumer can interact with the Policy Management Applica- tion (receiving Policy, notifications, provide status and other feedback, etc.) and the Policy Target can implement the Actions specified in Policy Rules they are compliant with requirements of the Policy Management System. The function of Policy evaluation can reside in the Pol- icy Consumer, the Policy Target, in both, or somewhere in between. The act of Policy evaluation may even occur in stages within the implementation; for example the time conditions may be evaluated separately from other conditions within Policy Rules. 5.2. New Traffic in the Net A few years ago a new application became available. This application allowed users to have their system display news items when their systems were otherwise idle. It became very popular and became widely used in a very short period of time. About the same time users discovered that their network performance was not what they had come to expect, especially connections from their corporate networks to the Internet. After a few months, Network Administrators learned that the firewalls were being overwhelmed by the requests from internal systems to the servers for this new application on the Internet. (The eventual solution was for the companies to set up servers inside the firewall and have internal users connect to these servers instead of going through the firewall.) The initial reaction of the IT staff in these companies was to tell users that use of this application was not allowed until a solution was found, but many users continued to use the application Mahon Expires March 2000 [Page 50]
Internet Draft Policy Requirements September 1999 anyway. With Policy Management the IT staff could have immediately limited or even shut down this kind of traffic by applying some simple Policy Rules. For example: if (traffic == NewsApp) then priority = Lowest endif In the above example 'Lowest' may be even lower than best effort. Even with the internal servers for NewsApp, this may be an appropriate policy since it is not a business critical function. The internal servers still need to get the news articles (and advertising) to provide to internal users, so they need to go through the routers and firewalls connecting with the Internet. For these Policy Targets there may be Policy Rules in place to allow higher priority for internal servers to access the NewsApp servers on the Internet. So an Administrator may author and deploy the following on Targets representing priority queuing on the routers send- ing traffic to connections to the Internet, and on internal interfaces on those routers which can receive traffic from the Internet: if (((traffic == NewsApp) && (trafficFrom InternalNewsAppServers) && (trafficTo !CorporateSubnet)) || ((trafficTo InternalNewsAppServers) && (TrafficFrom !CorporateSubnet))) then priority = Medium endif if (traffic == NewsApp) then priority = Lowest endif In this example the Policy will give NewsApp traffic 'Medium' priority if it is coming from or going to internal servers. If the NewsApp traffic is not coming from the internal NewsApp servers, it will go to the next rule which gives the traffic 'Lowest' priority. Mahon Expires March 2000 [Page 51]
Internet Draft Policy Requirements September 1999 5.3. Traffic Classification With Packet Conditions When determining how traffic should be treated conditions such as what kind of traffic and who is generating (or receiving) it are important factors. As discussed above, some traffic will be more important than others as far as why the network exists. In a company, traffic generated by ERP (Enterprise Resource Planning) tools will be valuable, while traffic generated by games will be less valuable. Also illustrated above is the importance of knowing who is causing the traffic. Combining these pieces of information can enable the Administrator to further refine allocation of shared network resources. The use of IP Port values in the IP packet header allows understanding what kind of traffic the packet represents (as long as one of the Port values is a well-known or reg- istered port). If traffic is going to a well-known port it is going to a server for that type of application. If it is going from a well-known port it is going to a client of that application. Use of the srcIPport, destIPport, and IPport conditions as described earlier allow an Administra- tor to classify traffic by type. (Other ways will are described in section 4.7.2.) Use of addresses (or names) allows designation of individ- ual machines, or groups of individual machines. Use of subnet identifiers allows a shorter designation of groups of people or systems involved in specific types of work (e.g., Accounting, R&D, etc.). To use the example from above of giving some (Medium) pri- ority to Web traffic going to and from a Web server for the Personnel department, we could express it as: if ((IPport == 80) && (IPaddress == PersWebSrv)) then priority = Medium endif Where the condition IPport matches the srcPort or destPort field in the packet header, and IPaddress matches the srcAddress or destAddress field in the packet header. The administrator could author the same rule as follows instead: Mahon Expires March 2000 [Page 52]
Internet Draft Policy Requirements September 1999 if (((destIPport == 80) && (destIPaddress == PersWebSrv)) || (srcIPport == 80) && (srcIPaddress == PersWebSrv))) then priority = Medium endif The difference between the single matching statement and two matching statements ORed together is that some Policy Targets may not have a 'match either source or dest' fea- ture, and could only match one (usually the Policy Consumer would provide a mapping, though). Or an Administrator may know that writing the Rule one way may be more efficient on a particular type of device than the other way. This, again, goes back to the need to understand some character- istics of what is being managed, but not quite to the same level of detail as currently required (e.g., the analogy between high-level programming vs. assembler level pro- gramming). Similarly, traffic for a set of users can be identified, as well as the application they are using. So an R&D group using an NFS server on another LAN could use significant network resources. Allowing them high quality of service limited to the NFS server could be done with the following: if (((destIPport == sunrpc) && (srcIPsubnet == RandDsubnet) && (destIPaddr == NFSserver)) || ((srcIPport == sunrpc) && (srcIPaddr == NFSserver) && (destIPsubnet == RandDsubnet))) then priority = High endif In the first part of the Rule, the conditions are testing for the destination Port for sunrpc (NFS), a source being the R&D subnet, and the destination being the specified NFS server. The second portion of the Rule checks for traffic going the other way. Actually this Rule could be split into two Rules, with each being assigned to different Pol- icy Targets (as described in section 4.1). Mahon Expires March 2000 [Page 53]
Internet Draft Policy Requirements September 1999 +-------+--------+ | Int3 | | | +----------+ |Router | |NFS Server| R&D subnet | TargetB| | | +----------+Int1 Int2+-----------+ | | |TargetA | | | +--+-----+ | | | | |User PC | | | +----------+ | | | Int4 | +--------+ +-------+--------+ Figure 8. A router with Policy Targets. The Rule: if ((destIPport == sunrpc) && (srcIPsubnet == RandDsubnet) && (destIPaddr == NFSserver)) then priority = High endif only needs to be associated with TargetB (representing pri- ority queuing on Interface2) since that is where traffic going to the subnet with the NFS server is controlled. The other Rule: if ((srcIPport == sunrpc) && (srcIPaddr == NFSserver) && (destIPsubnet == RandDsubnet)) then priority = High endif would be associated with TargetA (representing priority queuing on Interface1), which is where traffic entering the R&D subnet is controlled. By carefully authoring Policy Rules to contain the condi- tions specific to the function(s) of a specific Policy Tar- get, the Administrator can reduce the amount of processing for each packet going through the the device. Some devices have fewer resources than others. It can be easy to write a Policy that can tax (or even overflow) a device's capa- bilities. A well implemented Policy Consumer will detect any problems with a Policy before deploying it on a Target Mahon Expires March 2000 [Page 54]
Internet Draft Policy Requirements September 1999 (if the problem wasn't detected in an automated way ear- lier). If a Policy Consumer does detect such a problem it will provide feedback to the Administrator through the Pol- icy Management Repository. The above Rules assume IP traffic. Traffic could also be classified by EtherType, allowing other kinds of traffic sharing the network to share the benefits of Policy. At the edges of a network, it may be desirable to test for the existing value of the IP Precedence bits in the IP TOS byte and re-mark it if the necessary. A Rule performing this check will also look at who the traffic is for (or from) in order to determine what should be the correct mark. For example: if ((IPprecedence == 3) && (trafficTo CustomerX)) then mark = 5 endif 5.4. Other Uses of Policy Policy is not just used to give some traffic higher prior- ity than others. As noted earlier, the network is a shared resource. There will always be some traffic that is more important than other traffic, but even the most critical traffic must still let other users use the network (other- wise their should be a business need to separate that crit- ical traffic onto a separate network). Policy, therefore, can be used not just to assure that a critical use has sufficient bandwidth, but can be used to ensure that the critical traffic doesn't squeeze out the rest of the traffic. There are multiple methods of implementing this, but a com- mon term is Rate Control. The idea is to ensure the important traffic has enough bandwidth to fulfill user needs, and if there is sufficient extra bandwidth the traffic can also use that. But if other traffic exists, the important traffic does have a limit. This concept may also be used to keep the less important traffic from using too much bandwidth on the network. This traffic could be allowed some space, but a limit is set to keep it from interfering with other traffic. Mahon Expires March 2000 [Page 55]
Internet Draft Policy Requirements September 1999 5.5. Network Failure This section discusses methods for dealing with a network element failure which would require a different set of policies to ensure the same (or at least a known) QoS dur- ing the time the unusual situation exists. The case of Policy handling a network failure requires fea- tures for Policy Management not discussed earlier in this draft. To address this scenario additional work on the Policy Framework Core Information Model will be required. An Administrator will establish Policies in the networked environment (on routers, trafficshapers, switches, NICs, in network stacks, on applications, etc.) in order to ensure QoS according to the needs of the users of the networked environment. If a failure of a network element (e.g., router) occurs traffic will need to follow other routes through the network. If there were more than one path through the network which were also provisioned to provide the desired QoS that the failed route were configured to route (i.e., more than one route were identically config- ured relative to QoS and had sufficient bandwidth to take up the slack from another path) there would be no need to change the QoS configuration during the outage. Unfortunately not all networks will be so adequately con- figured, so a way to account for such failures is desir- able. There are at least two ways to address this: 1. Create condition types which deal with state 2. At the level of association between Policy and Policy Target provide the ability to associate multiple Poli- cies, and the association contains conditions which cause deployment of the Policy to the Policy Tar- get(s). Scenario 1 allows for minimal change to the Core Informa- tion Model. It would, however, cause Policies to be clut- tered with Policy Rules (or condition lists within Policy Rules) which only exist to handle contingencies. Such con- ditions which deal with state likely would not be evaluated on the Policy Targets (using existing devices as the model), rather they would be evaluated on the Policy Con- sumer. An example of such a state condition could be: condition type name: deviceDown attributes: device address: 192.168.14.12 considered down if no contact after: 30 Mahon Expires March 2000 [Page 56]
Internet Draft Policy Requirements September 1999 seconds To enable such a condition, either the Policy Consumer would need to poll each of the devices named in each such condition, or would need to be notified by some third party monitoring the condition of each device named in each pol- icy condition. Following Scenario 1 could cause Policies to contain more Policy Rules (or more condition lists within Policy Rules) to handle contingencies. This could also lead to more con- ditions within the non-contingency portions since those descriptions may not be applicable during periods requiring contingency Policy information. Take or example, a Service Provider with agreements with two customers A and B. Cus- tomer A contracted for premium service under all circum- stances. Customer B chose a lower cost service plan, which contained a provision that under certain circumstances may allow outage of service. Customer A's traffic usually flows through one path on the network, while Customer B's traffic flows through a portion with lower capacity. If the path used for Customer A experiences a failure, the contingency would be to route the traffic through the path used for Customer B. Because Customer B's contract allowed for outages, the Pol- icy on that path allowed for only best effort for Customer B during unusual circumstances. To handle this, using Sce- nario 1 as the model, all of the condition lists relating to Policy for QoS for Customer B would contain the state condition(s) for unusual circumstances, but logically NOT'd so that if the unusual circumstances did not exist the rest of the condition list would be evaluated: Mahon Expires March 2000 [Page 57]
Internet Draft Policy Requirements September 1999 Rule 1 if (((srcIPsubnet == CustomerB) || (destIPsubnet == CustomerB)) && ( NOT deviceDown(routerX, 30 sec.) ) && ( NOT deviceDown(routerY, 30 sec.) ) then Priority=5 endif Rule 2 if (((srcIPsubnet == CustomerA) || (destIPsubnet == CustomerA)) && (deviceDown(routerX, 30 sec.) || deviceDown(routerY, 30 sec.))) then Priority=5 endif Such policy would work, but would be cumbersome to manage. It also could reduce the ability to use the same Policy (or individual Policy Rules) across multiple Policy Targets since the 'deviceDown' conditions would be specific to cer- tain portions of the network. This scenario allows minimal change to the existing Core Information Model definition, but changes operational char- acteristics of components of the Policy Management System. Scenario 2 would require a change to the Core Information Model. On the association between a Policy and Policy Tar- get, there would be conditional associations to other Poli- cies. In the association would be conditions similar to those described in Scenario 1, which describe conditions under which the Policies for unusual circumstances would be deployed. If the current indirect model for distribution is followed, all of the policies would be placed in the directory and the Policy Consumer would obtain all of the policies, then change which Policy is deployed to the Pol- icy Target on a status change as described in Scenario 1. If a more direct model for Policy distribution were used, then the Policy Management Application could be enabled to change Policy distribution based on state not related to traffic based conditions. Whether the Policy Management Application or the Policy Consumer is involved, Scenario 2 allows for smaller and more reusable specifying Policies for unusual circum- stances. Mahon Expires March 2000 [Page 58]
Internet Draft Policy Requirements September 1999 If the Policy Consumers were to be made responsible for this contingency management, the Policy Consumers will nec- essarily have greater requirements than have previously been discussed. It would also introduce more policy that would need to be deployed at all times. Having the Policy Management Application handle the contingency deployment centralizes the operations but may be less reliable in the face of a network failure (e.g., if the link between the Policy Management Application and a Policy Consumer were unavailable). 6. Security Considerations For QoS related Policy, the security needs of a Policy Manage- ment System require authentication at a minimum. The Policy Management System contains components which send messages and read and write data. The interactions which involve writing of data MUST ensure authentication of both parties. In other words, when a Policy Consumer connects to a Policy Management Repository, in which the Policy Consumer writes status and configuration informa- tion to the Policy Management Repository, the Policy Consumer must authenticate itself to the Policy Management Repository, and vice-versa. The reason for this is that either end of the communication could be false. If a true Policy Consumer wrote data to a false Policy Management Repository, the Administra- tor will not see the true data. If a false Policy Consumer wrote data to a true Policy Management Repository, the Admin- istrator will see false data. Either situation means that the Administrator does not know the true state of Policy configu- ration in the networked environment. Similar requirements exist for the connection of the Policy UI to the Policy Repos- itory and Policy Management Repository. When Policy is used for security purposes, it MUST be encrypted when being transported over the network. Repositories must be as secure as reasonably possible. If a Repository resides on a general purpose host, access to the Repository data should be controlled and monitored. If the data cannot be so secured, other means, such as encryption of data in the repository, or other methods ensuring integrity should be employed. 7. Summary Policy Based Management is not just a buzz word, or a solution looking for a problem. There is a genuine need for allowing network Administrators to be more effective by managing the network as a collective, not as a collection of individual Mahon Expires March 2000 [Page 59]
Internet Draft Policy Requirements September 1999 devices each requiring a separate set of knowledge. Today's tools allow Administrators to configure the devices which enable traffic, but the view they present to Administra- tors is limited, and the management of a device is the focus of the activities with those tools. Policy information, as described in [INFOMODEL] allows that abstraction, but additional information is needed to make Pol- icy useful. Information such as the targets of Policy, attributes about those targets, and the association between Policy and the targets must be further defined. Additionally, the actual architecture of a Policy Management System must be further defined in order to allow multiple ven- dors to have interoperable implementations. The details of such an architecture include making the Policy information available in a timely manner, and providing the Administrator (and, in the future, tools) with information about the charac- teristics of Policy Targets in order to allow validation of Policy and conflict detection. Additionally, Administrators need to know if Policy deployment was successful in order to know if the network will work as expected so they don't have to wait for users of the network to tell them there's a prob- lem. Key questions have now been discussed in a document. Such questions as "What protocols should be used?" and the role of the Policy Consumer and Policy Consumer are covered in detail in this document. New requirements not already documented elsewhere are also documented here, such as security, versioning of Policy Data, and timely delivery of Policy Data. To finish the summation of this document, below are bullet lists of the requirements of a Policy Management System. The items marked with an asterisk are yet to be fully defined. Policy Data - Policy, contains one or more Rules - Rule, contains one or more Actions and one or more condi- tion lists - Action, schema definition exists, but few proposals for types * - Condition list, contains one or more conditions - Condition, schema definition exists, but few proposals for types * Mahon Expires March 2000 [Page 60]
Internet Draft Policy Requirements September 1999 - Policy Target *, contains attributes: - name - properties relative to policies supported - status - Policy Consumer * - Association between Policy and Policy Target * (currently called 'Jurisdiction' or 'Role', but not well defined) Policy Architecture Features - Policy repository communication (e.g., LDAP) - Policy repository (may be settled by above question, e.g., if communication is LDAP) - Notification to Policy Consumer of new/changed policy * - Versioning of Policy Data * - Status reporting mechanism from Policy Consumer * 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the tech- nology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to iden- tify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Sec- retariat. The IETF invites any interested party to bring to its atten- tion any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the infor- mation to the IETF Executive Director. Mahon Expires March 2000 [Page 61]
Internet Draft Policy Requirements September 1999 9. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [TERMINOLOGY] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", Internet Draft draft-strassner-policy- terms-01.txt, February 1999. [INFOMODEL] B. Moore, E. Ellesson, J. Strassner, "Policy Framework Core Information Model", Internet Draft draft-ietf-policy-core-info- model-00.txt, June 1999. [POLFRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, j. Wheeler, "Policy Framework", Internet Draft draft-ietf-policy-framework-00.txt, August 1999. (???) [COPSFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", Internet Draft draft-ietf-rap- framework-03.txt, April 1999. [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Pol- icy Service) Protocol", Internet Draft draft- ietf-rap-cops-07.txt, August 16, 1999. 10. Acknowledgements Special thanks to Mark Stevens, Bob Moore, Andrea Westerinen, Avri Doria, Cheh Goh, Rick Roeling, and Brian O'Keefe for input and feedback during the development of this draft. Thanks also go to Ed Ellesson and Bert Wijnan for their guid- ance on what should be discussed in this document. 11. Author Information Mahon Expires March 2000 [Page 62]
Internet Draft Policy Requirements September 1999 Hugh Mahon Hewlett-Packard Co. 3404 East Harmony Road, MS A2 Fort Collins, CO 80528-9599 Phone: +1 970 898 2487 EMail: hugh_mahon@hp.com 12. Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and fur- nished to others, and derivative works that comment on or oth- erwise explain it or assist in its implementation may be pre- pared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copy- right notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copy- right notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Mahon Expires March 2000 [Page 63]
