Policy Standards and IETF Terminology

Transcription

1 Paper White Paper White Paper White Paper White Paper White Paper White Policy Standards and IETF Terminology Volume #2 Part of an ongoing series of monographs published by IPHighway, Inc. on policy-based networking and quality of service. January 2001

2 Page 2 Table of contents 1. OVERVIEW INTRODUCTION OUTSOURCING AND PROVISIONING MODEL Policy Decision Point (PDP) POLICY ENFORCEMENT POINT (PEP) Repository (LDAP Directory) The Common Open Policy Service (COPS) Protocol COPS Base Protocol COPS Client - Type Usage Directives (COPS-PR, COPS-RSVP) Policy Data Representation RSVP Policy Data COPS vs. SNMP SUMMARY REFERENCES...10

3 Page 3 1. Overview This white paper is the second article in a series of monographs published by IPHighway. The goal of the series is to present the elements of Policy-based Network Management (PBNM) and Quality of Service (QoS) in an organized and thorough manner. The series provides complete coverage of the subject from its theoretical underpinnings to product implementations and real-world case studies. To gain the most out of this paper, the reader should be familiar with its preceding companion document, Introduction to Policy-based Networking and Quality of Service, as it provides grounding in a number of areas explored below. In addition to this essay, Policy Standards and IETF Terminology, other papers in this series include: Introduction to Policy-based Networking and Quality of Service IPHighway's Policy-based Networking Products, Design and Architecture IPHighway's Target Markets and Case Studies This article provides a discussion of the emerging policy standards within the Internet Engineering Task Force (IETF) and introduces some of the terms and vocabulary of both Policy-based Networking and Quality of Service (QoS). 2. Introduction IPHighway believes in aligning policy management solutions with the latest advances in IP networking standards. Compared to traditional network management techniques, the QoS and policy management paradigm is new in the industry and generating interest at a rapid pace. IPHighway is leading the way by actively participating in and contributing to the standards-body activities that are shaping policy-based management for the future. An example of such an association is the policy-related working groups within the IETF. Through these efforts, IPHighway and its customers can influence the direction in which policy management moves-thereby ensuring the right solutions for everyone's needs. The IPHighway suite of products is designed around the latest specifications emerging from these standards efforts. This is evident in our policy server products, which utilize the Common Open Policy Service (COPS), Differentiated Services (Diff-Serv), Reservation Resource Protocol (RSVP), and the Lightweight Directory Access Protocol (LDAP) standards, as well as PerformancePro Client-which is based on the COPS and Policy Information Base (PIB) standards. IPHighway's PerformancePro provisioning software is interoperable with routers and switches from virtually any vendor that manufactures standards-compliant equipment. Because it is closely associated with these standards, PerformancePro will continue to evolve to provide interoperability with the latest features and functionality.

4 Page 4 Figure 1: Standard Policy Architecture: Block Diagram Proprietary L DA P Directory Services LDAP COPS LDAP PEP PDP + PEP Working Groups (WGs) at the IETF, including the Policy Framework WG and the Resource Allocation Protocol (RAP) WG, are involved in developing a comprehensive policy architecture. In addition, the RSVP, Diff-Serv, and IPSP WGs are working on QoS and security aspects of policy related to their respective focuses. While many issues are still in development, the following terms are commonly agreed upon. 3. Outsourcing and Provisioning Model PBNM recognizes two main models for policy management: outsourcing and provisioning. The outsourcing model assumes there is a signaled event in the Policy Enforcement Point (PEP) that must be resolved based on policy criteria. These policy criteria are known as Policy Admission Control (PAC). When a PEP is ill equipped to make a decision through this mode, it outsources the decision-making to an external policy decision point (PDP). Signaling events are typically associated with end-to-end signaling protocol (such as RSVP, MPLS-LDP, Multicast Join ICMP, etc.) However, a signaled event at the PEP is decided, in essence, based upon external considerations. Consequently, this outsourcing model is sometimes referred to as "Pull" mode, or "reactive" mode, since the PEP pulls policy decisions from the PDP, while the PDP responds according to the PEP events. The provisioning model is almost the mirror image of the outsourcing model. In this system, the PDP predicts future configuration needs, and proactively provisions resources accordingly. In other words, rather than responding to PEP events, the PDP prepares and "pushes" configuration information to the PEP. This takes place as a result of external events (unrelated to the PEP) such as change of applicable policy, time of day, expiration of account quota, or information from third party (non-pep) signaling. The provisioning mode is most commonly used for controlling network policy for non-signaled protocols, such as Diff-Serv, or configuring devices (such as VPNs and VoIP). Both models employ policy servers as the PDP to control the network devices that enforce the policy (i.e. PEPs). PBNM also offers a policy repository for storing policy information accessed by the PDPs in the system. To communicate policy information between PDPs and PEPs, the COPS policy protocol is

5 Page 5 engaged. Additionally, the LDAP protocol functions to access the policy repository. The following sections provide an overview of COPS, as well as LDAP and other standards and protocols emerging within PBN Policy Decision Point (PDP) The PDP is the PBNM component that directly controls the network devices or policy enforcement points (see next section). Functionally, the PDP handles policy information that has been entered into the PBNM management system. The policy data used by the PDP can either be obtained in real-time upon entry into the management console, or from the policy repository on an as-needed basis. This data is processed, along with network resource information, for the purposes of making policy decisions as well as directing the network devices. In the case of an outsourcing policy model, the PDP receives policy requests from a network device, and determines whether or not to grant these requests. Typically, this activity involves an admission control decision regarding a Reservation Resource Protocol request. Here, the PDP either accepts or rejects the RSVP petition to enter the network based on the business-level policy found in the repository. So, the policy is essentially what grants the originating user/application the privilege to reserve resources, while the PDP provides access to the reservation itself. In the policy-provisioning paragon, new policies are entered at the management console, so the policy rules are distributed to the PDP in real-time. The PDP decides whether or not the policy should be installed. It makes these determinations based on various criteria such as device enforcement capabilities, and applicable time constraints. If a criterion is satisfied, the PDP packages the policy rules as configuration commands. In this way, policy directives arrive at each device in the appropriately deciphered form. At the same time, the PDP handles feedback from the network. All PDP decisions are sent out with either an acknowledgement that assures they were properly installed, or data indicating the detection of installation errors. 4. Policy Enforcement Point (PEP) Network devices that receive and enforce the decisions from the PDP are referred to as PEPs. In both outsourcing and provisioning policy management models, PEPs receive policy decisions and enforce them at the packet level as data passes through the devices. However, in the outsourcing world, enforcement is achieved through the permission or denial of RSVP packet requests to pass through the network. With policy provisioning, enforcement is usually completed by means of classifying data packets as they enter the network, and thereupon processing them according to the policy rules found. An example of this would be the identification of packets that originate from a particular subnet, and the subsequent marking of only those subnet-packets that have high priority precedence. The resulting action is the enforcement of the policy stating that marked traffic from users on that subnet should be treated as mission-critical. The PEP also provides feedback to the PDP regarding the decisions installed at the PEP. This is practical for identifying errors that occur while trying to install the policy, or for detecting failures that could have an effect on a previously installed policy decision.

6 Page Repository (LDAP Directory) The PBNM architecture assumes that multiple policy systems may need to interoperate within a single domain, and share the same policy information. A central repository can be used to store, distribute, and coordinate policy information among such systems. Directories and LDAP (Lightweight Directory Access Protocol) are the industry choice for interoperable standard policy storage [LDAP]. A multi-organizational effort involving the DMTF (Distributed Management Task Force), the IETF, and others, has been defining both an information model and the LDAP schemas to represent standard policy information. The policies in the directory are typically at a level of abstraction that is distinctively business centric. In addition, this information is typically static relative to the policy rules in the PEPs, which need to be installed and changed in order to implement the business policies. To demonstrate this point, we can consider a business policy stating that a certain group of users should receive higher priority in the network at particular time of day. Specifically, engineers should get priority from 6-7 PM. This is a static rule. It is entered into the directory to remain unchanged as long as it is required. However, during the requisite time of implementation, the policy rule itself is "dynamically" installed on the network at 6 PM and then "dynamically" removed at 7 PM. What's more, a "look-up" is required prior to the installation of the policy's packet filters to determine the members of the engineering group. This group may change frequently-especially if it resides in a large organization. So, it is clear that the rules at the network level are quite dynamic The Common Open Policy Service (COPS) Protocol The IETF Resource Allocation Protocol (RAP) WG has developed the Common Open Policy Service (COPS) as a policy protocol for use in PBNM management systems. COPS represents a revolutionary approach to the proactive management of network devices. It was developed as a reaction to traditional network management protocols, such as SNMP, which were found to be incapable of efficiently supporting PBN. The COPS protocol can be conceptually divided into three distinct layers: the base protocol, client-type usage directives, and policy data representation. These three layers, along with other distinct COPS advantages, make COPS especially well suited for the PBNM environment COPS Base Protocol It is intrinsic for PBNM to split policy control tasks between the enforcement device (PEP/router) and the central decision point (PDP/Policy Server). Thus, the IETF RAP WG defined the COPS protocol to be the communication mechanism that efficiently facilitates the exchange of dynamic policy rule information between a PDP and its associated PEPs [COPS]. To accomplish this, individual PEPs are required to initiate communications by opening a TCP connection and "shaking hands" with their controlling PDP-prior to the exchange of any policy data. This is a notable improvement over traditional network management systems, where the server installs configuration data (usually over a UDP connection) by initiating communication with the client. The technique of using a TCP connection increases the reliability and responsiveness of the COPS protocol, while the process of employing the PEP to initiate the connection allows smooth "fail-over" onto a new server if the main PDP crashes. In short, COPS provides a very efficient, scalable method for communicating policy information. For more details about advantages of the COPS protocol, see Section

7 Page 7 The COPS base protocol provides the underlying infrastructure of policy communications, while its builtin concept of client-types leaves room for adding a second layer of client-specific directives (see Section 4.2.2). COPS has been approved by the IETF. Commercially, COPS has been adopted by most major network product manufacturers as their protocol of choice for future releases of their policy-enabled hardware and software COPS Client-Type Usage Directives (COPS-PR, COPS-RSVP) COPS specifies functionality for both outsourcing [COPS-RSVP] and provisioning [COPS-PR] models of policy management. In the outsourcing model, RSVP is assumed as the QoS signaling mechanism. (COPS-RSVP reuses pertinent RSVP objects.) When an edge device (or other PEP) receives an RSVP message requiring a policy decision, the relevant RSVP objects within the message are put into a COPS request message, which is then forwarded to the policy server, or PDP. The PDP determines whether the RSVP message should be accepted, propagated to the next hop, or dropped-in which case an associated RSVP error message would commonly be generated. The PDP then sends a COPS Decision message back to the PEP in response to the request. Subsequent Decisions may be sent for the same request if the PDP determines that the original policy decision needs to be removed or changed. The PEP acknowledges receipt of the Decision messages and sends a report to the PDP, which includes the action taken, so the PDP is aware of the actual policy installed at the PEP at all times. Conversely, in the provisioning policy management model, no QoS signaling mechanism is assumed. Instead, a "push" model is used. In this framework, the PDP processes policy rules as it considers external information to make policy decisions. Then, these decisions are sent asynchronously from the PDP to the PEP for execution. Finally, the PEP confirms the successful installation of the provisioning decisions. COPS-PR may be used for the configuration of several different types of network services such as Diff-Serv Routing, MPLS, Security, VPN, and VoIP Policy Data Representation Data models have been designed for use with policy protocols in PBNM to exchange policy information among the PBNM components. For RSVP, the protocol is extended to include an RSVP POLICY_DATA object. RSVP policy data can also be used with COPS-such as in the case of a policy-outsourcing environment employing RSVP. COPS for policy provisioning requires a new data model called the Policy Information Base (PIB). This is essential because a QoS signaling protocol is not used with policy provisioning, and all policy information gets passed from the PDP down to the PEP in the form of policy rules RSVP Policy Data The RSVP protocol [RSVP] defines the POLICY_DATA object as a "container" for carrying in-band policy information in RSVP messages. The internal format of this object is transparent to RSVP, and can only be processed by policy modules [RSVP-EXT]. When an RSVP message arrives, the PEP communicates the POLICY_DATA object (along with the other RSVP objects) to the PDP. The PDP makes an admission decision, which in part may be based on the contents of the policy data object. The PDP may also modify or replace the policy data for an outgoing RSVP message.

8 Page 8 The internal format of POLICY_DATA objects is defined in [RSVP-EXT]. Its header includes several options related to security and scalability; the rest is sub-divided into a set of policy elements. So far, two standard policy elements have been defined: one for user and applications identification [RSVP-ID] and the other for preemption priority of RSVP flows [PREEMPT] Policy Information Base - PIB The Policy Information Base (PIB) is an information model proposed for use with the COPS-PR protocol, to describe policies and the format of policy information exchanged between the PEP and PDP [PIB]. To manage a wide range of provisioned policy information, the PIB provides both flexibility and extensibility for adding new types of provisioning parameters. The PIB encoding can define general provisioning policy information. That is, it describes network services or QoS packet classification techniques, and provides the level of abstraction necessary to effectively implement PBN. High-level policies, stored in the policy repository, are translated by the PDP to lower-level PIB parameters that can be understood by PEPs. The PIB uses ASN.1 encoding and BER format, and is therefore similar in syntax to Management Information Base (MIB). It provides a semantic name space and a self-descriptive data model, since the unique identifier (Policy Rule Identifier or PRID) that characterizes the data structure of the policy rule is what maintains the identity of each policy rule. Thus, extracting the PRID from COPS-PR messages provides all the information necessary for the PEP to decode and process the entire policy rule contained in the message. This allows new policy rule classes to be implemented simply by extending the PIB. No changes to the COPS policy protocol are necessary, and no modifications to previously defined PIB variables are required either.

9 Page COPS vs. SNMP COPS and SNMP differ in many aspects. Some of the main differences relevant to PBNM can be summed up in the following table: Criteria COPS SNMP Disadvantage/advantage Connection Reliable, TCP Non-reliable, UDP Policy information size limitations, overhead of retransmission of full UDP payload. Session Initiator PEP (router) SNMP Server COPS has automatic fail-over when server fails; SNMP does not. PEP decides level of support needed. Protocol State Stateful, no need for polling Stateless, need constant polling SNMP doesn't scale to PBN for large networks. COPS transmits only differences in state. Multiple Controlling Servers Not possible or permissible Possible and likely Multiple "masters" may confuse the PEP. Resource lock Lock resources actually used None Unlocked resource may change without the server knowing about or acting on it. State Updates Asynchronous, bi-directional, transactional SNMP Sets & Traps No transactional integrity (allows partial update). Traps have scaling problems for real-time usage. Data Model and Representation Policy Info Base (PIB) with "Roles" Management Info Base (MIB) PIB designed for mass (row) operations. Roles allow virtual interface provisioning. Table 1: Comparing SNMP and COPS functionality for PBN 5. Summary This monograph presents the fundamentals of Policy-based Networking for Quality of Service in terms of the IETF framework. As heterogeneous networking becomes the standard for global interconnectivity, organizations like the IETF are necessary to help speed the adoption of open and freely accessible standards for policy-based networking. Since the standards promoted by the IETF are constantly evolving, the reader is encouraged to stay current via regular visits to or

10 Page References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., Sastry, A., "The COPS Common Open Policy Service) Protocol", IETF <draft-ietf-rap-cops-07.txt>, August [COPS-PR] Reichmeyer, F., Herzog, S., Chan, K., Seligson, J., Durham, D., Yavatkar, R., Gai, S., McCloghrie, K., Smith, A., "COPS Usage for Policy Provisioning", IETF <draft-ietf-rap-cops-pr-01.txt>, November [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., Sastry, A., "COPS Usage for RSVP", IETF <draft-ietf-rap-cops-rsvp-05.txt>, June [DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With RSVP Signaling", IETF < draft-ietf-issll-dclass-01.txt>, October, [DS-AF] Heinanen J., Baker, F., Weiss, W., Wroclawski, J., "Assured Forwarding PHB Group", IETF RFC 2597, Proposed Standard, June [DS-ARCH] Blake, S., Black D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", IETF RFC 2475, Proposed Standard, December [DS-EF] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding PHB", IETF RFC 2598, Proposed Standard, June [DS-HDR] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers", IETF RFC 2474, Proposed Standard, December [E2E] Bernet, Y., Yavatkar R., Ford, P., Baker, F., Nichols, K., Speer, M., "A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services", IETF <draft-ietf-diffserv-rsvp-01.txt>, November [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", IETF RFC 2251, Proposed Standard, December [MPLS-ARCH] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", IETF <draft-ietf-mpls-arch-06.txt>, August [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", IETF <draft-ietf-mpls-ldp-06.txt>, October [PIB] M. Fine, K. McCloghrie, S. Hahn, K. Chan, A. Smith, "An Initial

11 Page 11 Quality of Service Policy Information Base for COPS-PR Clients and Servers", draft-mfine-cops-pib-02.txt, October [PREEMPT] Herzog, S., "Signaled Preemption Priority Policy Element", IETF <draft-ietf-rap-signaled-priority-04.txt>, September [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", IETF RFC 2205, Proposed Standard, September [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", IETF <draft-ietf-rap-rsvp-ext-02.txt>, Jan [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., "Identity Representation for RSVP", IETF <draft-ietf-rap-rsvp-identity-05.txt>, September [RSVP-TUN] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G., Srinivasan, V., "Extensions to RSVP for LSP Tunnels", IETF <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt>, September Copyright 2001 IPHighway, Ltd or IPHighway, Inc. All rights reserved. PerformancePro is a trademark of IPHighway Ltd. Other company and brand products and service names are trademarks or registered trademarks of their respective holders. Information in this document is subject to change without notice.

12 To learn more about IP Provisioning or IPHighway products, visit us at: or call