Internet Engineering Task Force David C Blight INTERNET DRAFT Charley Liu 17 February 1999 Fujitsu Labs of America Generalized Policy Framework Architecture 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 dis- tribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inap- propriate 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 Out goal is describe a simple policy framework (or architecture) which is both practical to implement, and easy to extend. Our framework is driven by the in- formation which needs to be exchanged, and the communication system required to implement it. We view policies as a specification for network management systems, and have constructed our framework based on that assumption. We forces us to consider a more general architecture, than one based on QoS assumptions alone. 1. Introduction Policy Based Networking has received a lot of attention recently (most of it has been hype). The basic idea is simple, specify a set of rules which govern the operation of network. What a policy is, has never been consistently defined, mostly because everyone has preconceived ideas about what the policies are. This framework is general enough to handle almost all kinds of policies, independent of their schema. Almost every company that makes (or announces it is making) an internet device, appliance, network management system has at some point publicly announced their Policy strategy, and promised that it will solve all the Internet's problems. Despite the promises, policies are a very powerful tools, if used in a consistent manner. The Internet (and Internet Protocol based networks) have lots of problems. Se- curity, reliability, performance, and Quality of service are just of few of them. We envision a policy based framework which will serve as a consistent framework for developing solutions to all these problems. This internet draft is intended to show one possible solution to the implementing Policy based management. 2. Assumptions The internet (and IP based networks) are complex, and everyone wants something different from them. Lets assume that a policy is the specification for some aspect of a network. Multiple policies will be specified covering many of the goals for the network. These policies will potentially come from different sourc- es (network managers, other management systems, synthesized from other poli- cies). The policies may also be applied to the network in different manners (simultaneously, sequentially, to specific devices, or at specific times). Our framework must be robust enough to meet these different requirements. Our basic assumption is that policies are specifications for network management systems. Policies within a network can take two forms, those that are specific for one or more devices, and directly implementable (A policy that specifies router configuration), or they may be network centric (web applications should receive a specified QoS guarantee). In either case, the policies are specifica- tions, and are interpreted by network management system, service management sys- tems, or device management systems. In order for policies to be more useful the current techniques for network or device configuration, we must standardize pol- icy specifications to that they are vendor independent. This implies that they must assume a generalized view of common network devices, services, or compo- nents. No single network management system can manage all aspects of a typical IP based networks, including layers lower than IP (ATM, Ethernet, SONET, POTS, etc.), and layers above IP (TCP, applications, services, business). It would be too complex to construct a general purpose network manager that knows about all applications, protocols, networking technologies. A more reasonable approach is to allow spe- cialized network management systems to control appropriate portions of the net- work, and allow communications between network management systems to achieve consistent management for all aspects of a network. In order to allow network management system to communicate, we must do the fol- lowing: 1) Common information model. 2) Simple communication system. 2.1 Common Information Model If everyone models information consistently, life becomes easier. Fortunately we have the Common Information Model (from the DMTF), which has standardized a good, flexible, information model. As a bonus, most commercial network manage- ment systems are supporting this model. With this in mind we should view our policy framework supporting a CIM based schema.An LDAP based schema is strictly a mapping into data structures consistent with LDAP. This is consistent with the schema currently being developed by Policy Working Group. 2.2 Simple communication system The required communication system must do the following 1) Reliably send messages from one component to another 2) Support component interaction models (e.g. client/server, publish sub- scribe) Most often we implement such a communication system by developing a layered set of protocols, usually like applications protocol/TCP/IP. The most important fea- ture is that the protocols should not be more constrictive than the data model being communicated. LDAP sucks. or maybe a better way to phrase it is, LDAP was designed for one specific purpose, and is not suited for all purposes. Its weak in security, data modelling, and many other things. While there are many attempts to make it bet- ter, this will likely take a long time, and the result will likely be very kludgy. Reality is that LDAP is standardized, and implementations exist. Lets view it as the lowest common denominator in a system. We use it for interoperability, when its suitable, but lets not go overboard with it. Everything must be kept simple. Simple is implementable, extendable, reusable, and consistent. Simple if good. 3. Architecture Our architecture consists of four entities: Management Consoles(MS): this is where policies are entered into the system. Policy Management System(PMS): this is the part of the system which does all the work. The PMS is responsible for interpreting the policies that are entered, and issuing instructions for network components.This unit will receive policies (in standardized encoding/schemas) and interpret the semantics of the policies, and issue commands for network components (these commands are also policies, just more specific) Policy Interpreter: The average internet device today does not know about policies (since we have not standardized them yet). The policy interpreter (sim- ilar to the one in PMS) interprets the policies, and issues machine specific instructions (via COPS, SNMP, or any other protocol). Policy Enabled Device: Any internet device, application, service, or appliance which has a built in Policy Interpreter. Policy Enabled Virtual Component: Not all components in a network are real, some are actually multiple components acting a single component. For example: a leased line between two routers is actually a large network belonging to a car- rier/ISP. By allowing details of network to be abstracted by a single component, we allow ourselves to construct networks which can be managed by multiple man- agement systems. When we send a policy to a Virtual component, we are actually sending a policy to the PMS of a network.Normally the internals of a virtual components would be beyond the management capabilities of the external PMS. +---------------+ +---------------+ +-----------------+ | | | | | | | Mgmt Console | | Mgmt Console | | Policy Mgmt Sys | | | | | | | +---------------+ +---------------+ +-----------------+ \ | / \ | / +-----------------+ | | | Policy Mgmt Sys | | | +-----------------+ / | \ / | \ / | \ +------------------+ +----------------+ +----------------+ \ +------------------+ | +---------------+ | +---------------+ | +-----------------+ | | | | | | | | | | | | | Policy | | |Policy Enabled | | | Policy Enabled | | | | Interpretor(s)| | | Device(s) | | | Virtual Devices | |-+ | |--+ | |-+ | |--+ +---------------+ +---------------+ +-----------------+ | | | | | | | | | \/ \/ \/ Legacy Devices Figure 1 : PBN Architecture A Policy Enabled Device, is simply a Device which can communicate with the Policy management System, and contains an interpreter +-----------------------+ | +---------------+ | | | | | | | Policy | | | | Interpreter | | | | | | | +---------------+ | | | | | | | | | | | \/ | | Device | +-----------------------+ Figure 2 - policy enabled device A Virtual Policy Enabled Component (or Device), is an abstract component which represents part of a network under the control of a different management system. To the policy management system, this portion of the network looks like a single device. +-----------------------+ | +---------------+ | | | | | | | Policy | | | | mgmt sys | | | | | | | +---------------+ | | | | | | | | | | | \/ | | Devices | +-----------------------+ Figure 3 : Virtual policy Enabled Device A multi-layer managed network could look something like +---------------+ +---------------+ +-----------------+ | | | | | | | Mgmt Console | | Mgmt Console | | Mgmt Console | | | | | | | +---------------+ +---------------+ +-----------------+ \ | / \ | / +-----------------+ | | | Policy Mgmt Sys | / | | \ / +-----------------+ \ / / | | \ \ / / | | \ \ +---------------+ +---------------+ +-----------------+ +---------------+ | +---------------+ | +-----------------+| | | | | | | | || | Policy Enabled| | |Policy Mgmt | | | Policy Enabled || | Devices |-+ | Sys |-+ | Devices |+ | | | | | | +---------------+ +---------------+ +-----------------+ / | \ / | \ +---------------+ +---------------+ +-----------------+ +---------------+ | +---------------+ | +-----------------+| | | | | | | | || | Policy Enabled| | |Policy Mgmt | | | Policy Enabled || | Devices |-+ | Sys |-+ | Devices |+ | | | | | | +---------------+ +---------------+ +-----------------+ Figure 4 : MultiLayer Architecture 4. Policy Management System Lets examine what is needed of the policy management system. 4.1 Multiple console support Each management system is logically centralized, but supports multiple manage- ment consoles to accommodate multiple managers on a network and/or to present different views of the network. Each user should have an associated set of access permissions to different information. WBEM is the likely protocol to be used for access.Inputs from users managers) should be specified in terms of policies (al- though through a graphics front end). An important part of this framework is that management systems may be tied to- gether through the same interface. Any other management system should appear to the management system as a management console. Instructions from other manage- ment systems should be in the form of policies, and information can be retrieved by WBEM. 4.2 Multiple network Views An important extension to supporting multiple consoles is to support multiple network views. There is always more than one way to look at a network. We may be interested in topology, physical assets, network traffic, or network state. Each console can potential show a different view of the network. Each network view will also be subjected to access control. Not all users/management systems will have the same permission to view all levels of details. One important network view is the virtual device view, in which the network (or subset of) is make to look like a single device to the management console (or other management system). This is critical in making the management systems scal- able and interoperable. For example, consider an ATM based carrier network which is providing a VPN for an enterprise. The external view of this network that the carrier network man- agement system will export to the enterprise is one of a single link, with as- sociated properties corresponding to its SLA or measured characteristics. Policies from the enterprise network PMS to the carrier PMS may include Security policies QoS Policies Reliability Policies Likewise the enterprise could request network information from the carrier. The carrier does not want to inform the enterprise of any other VPNs than its own, and of the internals of the carrier network. For this purpose, the carrier will create a special CIM model of the single link view of the VPN, and make it avail- able to the enterprise PMS (through the communication system). 5. Communication requirements We desire a simple communication system. Before describing some basic messages which may be sent, we will first discuss the basic needs. Messages will be grouped into three categories: 1) Identification 2) Request/Response 3) Notifications Identification is used to authenticate all parties in a communications. Request/Response messages are used to query information or submit policies. A Management console (or Management system), needs to be able request available views of the network, and to submit policies. This communication follows the client/server model. We could conceivably get by with two commands, get overall view and set policy, but additional messages are included for efficiency (to get more specific information, and reduce receiver filtering/processing). Notifications are asynchronous messages used to notify a management console or PMS of a policy violation. Submission of a policy is viewed as a subscription to events associated with the policy. 5.1 Register The register message is used to identify a network component to the policy man- agement system. A Register message is returned to the requester, with an at- tribute indicating error conditions. This message should also contain or initiate a sequence of messages to authenticate both parties. The register com- mand leaves an open connection through which further commands may be sent. 5.2 Get View Capability The message requests a list of network views which the originator is allowed to request. 5.3 View List This message is generated in response to a Get_View_Capability message. This message will contain a list of views that the PMS supports, and is authorized to reveal to the requester. 5.4 Get Policy Capability This message will request a list of policies types that the policy management system supports. This information will be used by network management consoles and other network management system to identify what types of policies are ap- propriate for the PMS. 5.5 Policy List This message is generated in response to a Get_Policy_Capability message. This message will contain a list of policy schemas that the PMS supports. 5.6 Get View This message requests a network information model view be made available to the requester. It most specify one of the available view types. 5.7 Return View This message is generated in response to a get_View message. It will contain a information model/schema view of the network. 5.6 Apply policy This message contains a policy, which should be administered by the PMS.it will contain a policy ID, which may be used to identify this policy in future trans- actions. 5.7 Modify Policy This message is used to change the parameters of a policy. It must contain an ID of a valid policy. This command can be used to rescind policies. 5.8 Policy Status This message is generated in response to a Apply_policy or Modify_policy message. It will contain sufficient information to identify whether the policy (or mod- ification) was accepted by the PMS. 5.9 Events This message is used to single network components of policy violations. 5.10 Multicast Communication Multicast technology could be used to improve the efficiency of the this frame- work, although it is not strictly required. The multicast model is none the less useful for showing the conceptual communication model. if multicast is not avail- able, the same functionality may be provided by the PMS (with multiple point to point connections). Our communication architecture adopts IP multicast and the concept of self-organization. IP multicast is used to improve the efficiency of one-to-many communication; and the self-organization concept is used to improve system robustness in the presence of network dynamics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +---------+ . . | Console | Bootstrap Group . . +---------+ . . x x x x x x x x x|x x x x x x x x x x x x x x x x x x x x x x x x x . . x | x . . x | All-PMS Group x . . x | x . . x # # # # # # # | # # # # # # # x . . x # V # # # # # # # # # # # # # # # # x . . x # +-------------+ # # +-------------+ # x . . x # | MPS A | < ----------- > | PMS B | # x . . x # | Directory | # # | Directory | # x . . x # +-------------+ # # +-------------+ # x . . x # ^ # # ^ # x . . x x#x x x x x x x|x x x x x x x#x x#x x x x x x x|x x x x x x x#x x . . # V # # V # . . # +-----------------+ # # +-----------------+ # . . # +-----------------+ | # # +-----------------+ | # . . # +-----------------+ |-+ # # +-----------------+ |--+ # . . # +-----------------+ |-+ # # | Network Devices |--+ # . . # | Network Devices |-+ # # +-----------------+ # . . # +-----------------+ # # # . . # # # Designated Group B # . . # Designated Group A # # # . . # # # # # # # # # # # # # # # # # . . # # # # # # # # # # # # # # # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5-2: Multicast Group Model As shown in Figure 2, there are 3 types of multicast groups: the bootstrap group, the all-directory group and the designated groups. The bootstrap group is used for the policy-aware devices to discover available policy directories; the all-directory group is used to exchange characteristics and request for missing policies among directories; and the designated group is associated with individual directories, which is used to disseminate policies to a set of network devices. 5.10.1 Bootstrap Group Initially, the membership of the bootstrap group consists of all policy directories. Each policy directory periodically multicasts solicitation messages. These messages contain information for policy-aware network devices to determine their designated directories. When a new network device is brought on- line, it joins the bootstrap group and receives solicitation messages from directories. It then selects a directory as it designated directory and joins the corresponding designated group. The device can leave the bootstrap group or optionally stays in the group to discover better suitable directory. There are several ways to select a designated group. A device can choose a directory based on the distance. On the other hand, if directories store different policies based on device types, a device should select the directory of its type. The selection criteria should be carried in the solicitation messages. 5.10.2 All-Directory Group All policy directories join the all-directory group. A period session messages are sent by individual directories to exchange directory characteristics, such as database synchronization, distance measurement, etc. The information in the session messages can be used to synthesize solicitation messages for the bootstrap group. This group is also used to distribute new policies and to request missing policies among directories. When a new policies is installed in a directory, this directory multicasts the policies to other directories. When a directory discovers a missing policy, it multicasts a request to the group to recover the missing policy. 5.10.3 Designated Group Each policy directory is associated with a multicast group. This group is used to distribute policies to policy-aware network devices. When a policy-aware network device selects a policy directory as its designated directory, it also joins the corresponding designated-directory group as a member. This device receives new policies from its designated group. When the device discovers a missing policy, it also requests its designated directory for recovery. Therefore, once a designated directory is selected, a device only deals with its designated directory and designated group. 5.10.4 Mechanism Description This section describes the operational mechanism of our communication architecture. We discuss the bootstrap mechanism, policy dissemination and policy retrieval. 5.10.5 Bootstrap Mechanism When a policy directory is brought on-line, it joins 2 well-known multicast groups, the bootstrap group and all-directory group. It starts exchanging session messages with other directories in the all-directory group, and sending solicitation messages to the bootstrap group. Directory synchronization and fault-tolerance can be achieved within the all-directory group. Since there are available mechanisms in the area of distributed database, we do not discuss those mechanisms here. When a policy-aware network device is brought on-line or it does not select a designated directory, it joins the bootstrap group. The devices include management consoles, policy servers and other policy-manageable devices. After receiving solicitation messages from some directories, a device selects its designated directory based on some criteria, for example, distance, device type, etc. The device also joins the corresponding designated group. From then on, the device can leave the bootstrap group. However, it can stay in the group if it wishes to adapt to a better suitable directory. 5.10.6 Policy Dissemination Policy dissemination is a 3-step process. The management console first installs the policy to a directory, the directory distributes it to all other directories, and then directories multicast the policy to their designated groups. Each management console has one designated policy directory. When a management console is brought on-line, the console learns of other existing directories by joining the bootstrap group. When the console installs a policy, it either multicasts to its designated group or unicasts to its designated directory. The communication between the console and its designated directory should be reliable, that is, an ACK should be received from the designated directory to ensure the reception of the new policy. When the designated directory receives a new policy, it informs other directories by multicasting a copy of the policy to the all-directory group. A reliable multicast mechanism, for example, SRM, is used to ensure the correct reception of the new policy. When a directory receives the new policies from the all-directory group or receives a unicast policy from a device (i.e., management console), it multicasts a copy to its designated group. However, if the designated group is created based on device type, only devices affected by the policy should be informed. The communication should be reliable among a directory and devices. 5.10.7 Policy Retrieval In some cases, a device may request for missing policies. For example, when a device is brought on-line, it should request for the past policies from it designated directory. Policy retrieval is a 2-step process. A policy-aware network device requests its designated group to retrieve a missing policy. If the designated directory has the policy, it replies to the device. Otherwise, it requests the all-directory group for the missing policy. The mechanism used in each step is exactly the same as the reliable multicast mechanism in the policy dissemination. 6. LDAP compliance This policy framework is more sophisticated than that allowed by a strictly LDAP only protocols. One requirement is that this system should be interoperable with devices that are LDAP only capable. If an LDAP based device, or network management system needs to interact with the PMS, if may retrieve and set values using LDAP access to directories, which may store all information required. Essentially each management view can be stored in a virtual directory (or real directory). When an LDAP message is received, the appropriate information is sent (via LDAP), or action performed. Security, registration, and event notification are beyond LDAP's current capa- bilities, but future extensions to LDAP may address these weaknesses. 7. Security Considerations We all know security is important, and most of us know how to implement it. This architecture is modular based on databases, protocols, devices, and users. We obviously need to encrypt everything, and authenticate all users. Ideally a se- curity policy should be used to set ACL for permissions on access to management system functionality. 8. Conflict Detection and Resolution The other internet draft (qos-poli-rev-3.3.txt) does a good job of discussing conflict issues. Only two issues need to be addresses further. 1) An alternative to identifying and resolving conflicts is to avoid them. Ide- ally we should start with a small number of policies, and synthesize a large number policies from them using proven techniques which will not produce con- flicts in lower layers. As long as the original policies are conflict free, and conflict safe algorithms are used by the management systems, conflicts need not be detected, except at highest level.We are not saying that conflicts will not occur, just that not all system will require conflict detection/resolution. 2) The policy management system must have sufficient knowledge of lower layers to ensure it is not creating unimplementable policies. It would be very slow to have a top level management system create policies which are unimplementable at the lowest level. Without knowledge of the underlying network, it is pointless to try to synthesis policies. Simply having a management system or device reject a policy (with reasons) is not sufficient, since the system may next try to syn- thesis policies with the new knowledge, but they may or may not work (since the management system does not have all available information). The solution is to retrieve required information first, and then synthesis policies. This is not fundamentally different than internet draft (qos-poli-rev-3.3.txt), as it also requires information to propagate up (in form of error signals). 9. Example Examples are the best way to show how this system works. 9.1 Example Configuration Policies Policies: 30 % bandwidth reserved for Web traffic 10 % bandwidth reserved for control traffic (Router protocols, etc) 20 % bandwidth reserved for email Step 1: Devices on network register themselves with PMS. Bootstrapping or SLP is used to identify appropriate PMS. Step 2: PMS queries devices (real or virtual) to determine their capabilities. Information should include number of queues, buffer sizes, etc (for routers on- ly..obliviously) Step 3: Network Administrator opens Network management console, authenticates userid/password. Step 4: Management console queries PMS (with Network administrators credentials) for available network views, and allowed policies to be specified. PMS responds with list of network views, and policy schemas (QoS only in this example). Step 5: The above policies are specified on management console, using a GUI. The GUI interface produces a set of policies (compliant with Policy Schema, QoS Sche- ma). The management console would not allow security policies to be entered, as they were not reported in step 2). The policies are sent to the PMS. Step 6: The PMS sends policies to routers (or any other appropriate devices). Step 7: The PMS configures (via policies again), network monitoring equipment to verify policy enforcement. If the measured performance does not match spec- ified performance, an event is sent to the management console. If an event re- lated to these policies is received from a network device (real or virtual), it is also sent to the management console. 9.2 Example: Network Centric Policies Policies: Web Sessions should receive 100 Kbps and 50ms delay Email sessions should receive 30 Kbps Voice over IP should receive 32 Kbps Step 1: Network Administrator opens Network management console, authenticates userid/password. Step 2: Management console queries PMS (with Network administrators credentials) for available network views, and allowed policies to be specified. PMS responds with list of network views, and policy schemas (QoS only in this example). Step 3: The above policies are specified on management console, using a GUI. The GUI interface produces a set of policies (compliant with Policy Schema, QoS Sche- ma). The management console would not allow security policies to be entered, as they were not reported in step 2). The policies are sent to the PMS. Step 4: The Policy Management System receives the set of policies from the man- agement console. It verifies permission to set these policies. Step 5: PMS needs to configure the network so that the policies specified are being met. Since the policies specified do not directly translate into device configurations, the PMS uses its knowledge of the current network state, and configuration, and allowable configurations, to determine a set of configura- tions that will achieve these policies (as well as other specified by other man- agers). IMPORTANT NOTE: How this is done is not part of the standard, this is where network management vendors will make products that differentiate them- selves by how well they accomplish this. To realistically implement these pol- icies however, the PMS would need to know about network traffic profiles. This could be entered by user, or measured from network. The former method would re- quire the management console to supply traffic profiles. This could be accom- plished in this framework by having the management console appear as both as console and a device (network measurement device with traffic profile views). Step 6: PMS converts new configuration into policies for each device (real or virtual in network), and sends them to the devices. Step 7: The PMS configures (via policies again), network monitoring equipment to verify policy enforcement. If the measured performance does not match spec- ified performance, an event is sent to the management console. If an event re- lated to these policies is received from a network device (real or virtual), it is also sent to the management console. 9.3 Example: Multi Layer Networks Policies: SLA's between ISP Customers and ISP Step 1: Policies received from ISP's customers. These policies reflect service requirements and QoS. Step 2: ATM network is queried for its connectivity view. View shows possible connectivity that ATM network may be configured for. Step 3: Policies are used to configure network (IP Layer) through synthesized policies. MPLS LSP are established. Step 4: Policies are sent to ATM PMS, which configures PVCs in ATM network. Step 5: A single link network view is return from ATM network. Step 6: Single link views are produced for each VPN provided by ISP, and made available to ISP Customers. Step 7: General connectivity views are made for internet customers. Step 8: Failure in ATM network event received. ATM PVC reconfigured to new path.Cell loss occurred. The information in event states that data was lost (technology independent). Details include bytes lost and duration. No details of ATM network sent or required. Step 9: If SLA performance not met, an event sent to customer. 9.4 LDAP Example A LDAP only device, uses SLP (or appropriate directory location service) to find PMS (which acts as a directory). It can use LDAP to query appropriate policies. The PMS will restrict information supplied to LDAP device so that only relevant information is sent. The PMS acts as a smart LDAP directory. If device asked for all router policies, the PMS would return DN of policies appropriate for that device, assuming the PMS recognises the device. (A different device would get different list of policies back). An unrecognized device would receive the entire list of policies. The PMS must remember the DNs given out, so that it can be consistent in responding to future queries. Note that the PMS could actually use a real directory (LDAP based) if it wished, but it is not restricted to that. 10. 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 technology described in this document or the extent to which any license under such rights might or might not be available; neither does it rep- resent that it has made any effort to identify 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 imple- menters or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover tech- nology that may be required to practice this standard. Please address the in- formation to the IETF Executive Director. 9. Acknowledgments We would thank everyone who has or will criticize this document. 10. References [COPS] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju Rajan, Arun Sastry, "The COPS (Common Open Policy Service) Protocol," draft-ietf-rap-cops-02.txt, March 12, 1998. [DSFIELD] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Dif- ferentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", Internet Draft, , August 1998. [LDAP] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Proto- col," RFC 1777, Performance Systems International, University of Michigan, ISODE Consortium, March 1995. [SCHEMA] J. Strassner, E. Ellesson, _Policy Framework Core Information Model_, draft [TERMS] J. Strassner and E. Ellesson, _Terminology for describing network policy and services_, draft 11. Author's Addresses: David C Blight Fujitsu Labs of America 595 Lawrence Expressway Sunnyvale, California 94086-3922 dblight@fla.fujitsu.com 408-530-4567 Charley Liu Fujitsu Labs of America 595 Lawrence Expressway Sunnyvale, California 94086-3922 charley@fla.fujitsu.com 12.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its im- plementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright 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 copyright notice or references to the Internet Society or other Internet organ- izations, 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 IM- PLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.