Internet Draft Policy Configuration with SNMP July 6, 2000 J. Saperia JDS Consulting, Inc Policy Configuration with SNMP draft-saperia-policysnmp-00.txt July 6, 2000 saperia@jdscons.com 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 obsoleted 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 (2000). All Rights Reserved. Saperia Expires January 6th 2001 [Page 1] Internet Draft Policy Configuration with SNMP July 6, 2000 1. Abstract This paper is an introduction to terms and principles of policy-based network configuration management that is based on work in the IETF. A generic model for the realization of policy-based network configuration management is presented based on these terms. The last portion, and focus of the paper, examines the current work of the SNMP Configuration Working Group in the IETF and maps that work to the previously defined terms and model. 2. Introduction Configuration management of network elements based on a set of rules or business objectives is not new. Payroll, order processing systems, and many other business critical applications have been configured to receive priority processing in preference to other computer tasks for decades. For years, routers have been configured to send traffic over certain links in preference to others based on the lowest dollar cost link versus what the routing protocols have selected - policy-based routing. What is driving much of the recent public discussion of policy is the demand for improved and predictable service level qualities - Qualities of Service (Qos). Related to this demand is the associated explosion in the size and complexity of networks and the scarcity of human resources with the requisite skills manage to them. An example of a technology that can be used to help deliver different qualities of service is Differentiated Services [DIFFSERV]. Since some traffic in this and other Qos approaches is treated preferentially over other traffic, there is also an increased need for authentication of the monitoring and control functions in the network. This is necessary to avoid unauthorized use of network resources and the subsequent reduction in service quality by those who had paid for improved Quality of Service. This authentication needs to be flexible since some network operators need control and monitoring, while others need only monitoring functions. In fact some operators may be permitted to control some functions on a device only when accessing them from a 'secure' location. The concern over security extends to the need in many Saperia Expires January 6th 2001 [Page 2] Internet Draft Policy Configuration with SNMP July 6, 2000 environments to provide protection against the unauthorized disclosure of management information as well as protections against modification of authorized commands. In order to effectively make configuration decisions, policy- based configuration tools need information about the operational state and available resources in the network. This information includes: - The operational state of network elements that are to be configured. - The capabilities of the devices in the network. A capability can be almost any unit of work a network element can perform. These include, routing protocols supported, Web Server and OS versions, queuing mechanisms supported on each interface that can be used to support different qualities of service, and many others. - The capacity of the devices to perform the desired work. Capability is an ability to perform the desired work while a capacity is a measure of how much of that capability the system has. - Utilization refers to how much capacity for a particular capability has been consumed. To understand policy-based configuration with SNMP and the work of the SNMP Configuration Working group, the primary focus of this paper, a review of some background and history is helpful. This paper is divided into 3 Parts: [1] Background and recent history related to policy and policy based management. [2] Definition of terms. The meaning of policy and policy related terminology has been problematic. In this section a few terms are defined that help provide a context for the discussion on the approach that the SNMP Configuration working group is taking in this area. An Saperia Expires January 6th 2001 [Page 3] Internet Draft Policy Configuration with SNMP July 6, 2000 effort has been made to harmonize these terms with the activities of those in the Policy Working Group. [3] Current work of the SNMP Configuration Working Group 3. History and Background An examination of the archives of the Policy Framework Working Group in the IETF [POLICY] will reveal that they have been discussing the issue of policy-based management since the middle of 1998. The archive is located at: http://www.raleigh.ibm.com/maillists/policy The first few sentences of the charter read: "There is a need to represent, manage, share, and reuse policies and policy information in a vendor-independent, interoperable, and scalable manner. This working group has three main goals. First, to provide a framework that will meet these needs. Second, to define an extensible information model and specific schemata compliant with that framework that can be used for general policy representation (called the core information model and schema). Third, to extend the core information model and schema to address the needs of QoS traffic management (called the QoS information model and schemata)." For additional details of the charter and the current working group activities please reference the charter page for the working group at: http://ietf.org/html.charters/policy-charter.html During this same period of time, SNMPv3 [SNMP] moved from PROPOSED to DRAFT STANDARD status. This important evolution is relevant to the operational considerations associated with policy-based management since security is an important issue when a single high-level command can be issued that has network wide impact. The Resource Allocation Protocol Working Group [RAP] has been Saperia Expires January 6th 2001 [Page 4] Internet Draft Policy Configuration with SNMP July 6, 2000 working on policy based management for some time using protocols other than SNMP. For additional details on these protocols, see the reference section at the end of this document. The fact that there were multiple approaches caused some concern and generated a number of papers that were reviewed and discussed. These discussions culminated in a BOF on configuration management at the 46th IETF held in Washington, DC in November, 1999. One of the outcomes of that BOF was to explore the creation of a working group that would later be called the SNMP Configuration Working Group (snmpconf). Additional details about the working group charter and activities can be found at: http://ietf.org/html.charters/snmpconf-charter.html This paper outlines the current state of the activities in the SNMP Configuration Working Group and illustrates how an effective, efficient, and integrated management system can be built using the Internet Standard Management Framework, SNMP. The terms used in this paper have been aligned as much as possible with the work in the Policy Framework Working Group as an example of an implementation of the three goals described in the working group charter previously cited. Using the Internet Standard Management Framework (SNMP) as the foundation for policy-based configuration management as well as for more traditional instance based configuration (e.g, such as setting an IP address on an interface) provides a powerful solution to the problem of configuration management since it [SNMPv3] also has the extensive security infrastructure that is also needed to ensure that resources in the network are only used by those authorized. Policy-based configuration management functions can be accomplished using the existing SNMP architecture as it is today without any changes to the framework. The SNMP architecture provides for the definition of new MIB modules as needs arise. In the case of both policy-based and instance-based configuration, all that is needed is the definition of configuration objects. The important distinction to be made here is that some of the new objects will be aggregate (Policy) configuration commands that can concisely convey to the managed element a series of configuration Saperia Expires January 6th 2001 [Page 5] Internet Draft Policy Configuration with SNMP July 6, 2000 commands that should be executed. The new objects represent information at a higher layer of abstraction than has been common in previous MIB Modules. Another advantage of using SNMP as the foundation for configuration management is that it makes it easier to perform other related functions of fault or performance management. Consider how much easier it will be to understand the effect of an interface failure or an abnormally terminated server process if the mechanism that configured them to deliver some policy supporting uses the same name space (MIB Object Identifiers) as is used for fault information. For example, if an interface fails that is supporting a customer with a particular service level guarantee, knowing that that instance is associated with the delivery of a policy can greatly improve the ability to rapidly understand how service levels are affected by failure or oversubscription. Other approaches do not have this direct connection. This does not mean that each instance of configuration object in each interface must be sent to the managed device. Rules for the expansion of the configuration commands can be efficiently transmitted to the managed element with just a few MIB Objects. Later sections of this document outline how these new objects relate to each other and the thousands of MIB objects that have already been defined in RFCs and a large number of vendor specific MIB Modules. 4. Definition of Terms 4.1. Defining the Term Policy One difficulty for the advancement of policy-based configuration and control of networks is the definition of terms. The single most problematic term is policy. To begin, policy-based management is simply a particular type of configuration management. The distinction here is that often the policy is expressed in terms that are neither instance or technology specific. The configuration management that we are most familiar with, where we might set the IP address for an interface, tends to be technology and instance-specific. What Saperia Expires January 6th 2001 [Page 6] Internet Draft Policy Configuration with SNMP July 6, 2000 this means is that the configuration software knows about the format of an IP address and how to send it to the managed device so that it gets applied to exactly the interface desired. 4.1.1. What is a Policy and how does it relate to Configuration? Part of the difficulty with policy discussions has been that policy is often used to describe several different concepts. This overloading impairs our ability to communicate. What is often unclear is the level of detail or abstraction that the speaker intends. For many people, policy means business level or service level agreement expressions. For others, policy means configuration of one or more elements in a network to behave a certain way. For many that have thought about the issue, policy is on a continuum that ranges from very high level business abstractions to very low level device configuration parameters. The distinction between all these different levels of abstraction is the detail associated with the expression of the policy. 4.1.2. Terms and Relationship to Policy Framework Working Group Much of the information in this section is an adaptation and expansion of a presentations given at the 47th IETF in during the Policy Framework Working Group session. By adopting terms used by the Policy Framework Working Group wherever feasible; the SNMP Configuration Working Group hopes to reduce the terminology confusion that has existed in this area. Work is ongoing in the SNMP Configuration and Policy Framework groups as well as others; so some change is inevitable. Here are terms that are used to describe policy information at different levels of abstraction moving from the most general to the most specific. [1] Domain-Specific. A domain is a general area of technology such as service quality or security. Services, or service level agreements, may span several domains, each of them potentially including many policies. As a general rule, Saperia Expires January 6th 2001 [Page 7] Internet Draft Policy Configuration with SNMP July 6, 2000 people will not discuss these domains in the abstract. They will most often be discussed with technology or application-specific examples. Examples of technical domains include, IPSec and Differentiated Services. When expressed in terms specific to a particular domain, a policy is said to be at the Domain Specific level of detail. There is little in common between how one would configure differentiated services with how one would configure IPSec [IPSEC]. They may both be required for a particular service agreement however. For example, people who want to use a voice over IP application might also want to ensure a certain level of security for these communications. [2] Mechanism-Specific. Mechanisms are technologies used within a particular domain. For example, in the differentiated services domain, RED (Random Early Detection) or WRED (Weighted Random Early Detection) might be used as one of the mechanisms that devices employ to support differentiated services and the applications on which they rely. Policy descriptions that include the details associated with a particular mechanism, are said to be mechanism-specific. [3] Implementation-Specific. implementation-specific details are those parameters that a particular vendor might use in an implementation that augment a standard set of mechanism-specific parameters. Vendors often add special capabilities to basic mechanisms as a way of meeting special customer requirements or differentiating themselves from their competitors. These special capabilities are often a result of the implementation approach that a vendor has used for the product, thus the term, implementation-specific. For example, if a router vendor implemented a particular routing protocol, they would have the mechanism-specific parameters that control the behavior of that software. The vendor might have chosen to run several instances of that routing protocol, perhaps on different processors, for performance reasons. The parameters that are used to control the distribution Saperia Expires January 6th 2001 [Page 8] Internet Draft Policy Configuration with SNMP July 6, 2000 of work on the different processors for that protocol would be implementation-specific. [4] Instance-Specific. Network operators are most familiar and comfortable with information of this type. Instance- specific information refers to parameter values that have been associated with a specific instance in a managed element. For example, The Border Gateway Protocol is a routing protocol that has a number of parameters that describe information about a particular router's view of other routers that it is sharing information with, peer routers. One such parameter defined in the BGP MIB Module [BGP MIB] is the desired connection retry interval for a peer, bgpPeerConnectRetryInterval. An example value would be 120 (seconds). When expressed with this level of specificity, one would say that this is mechanism- specific data. If we were to see a value of bgpPeerConnectRetryInterval.10.0.0.1 = 120 we would be looking at the retry interval of the peer router found at IP address 10.0.0.1. The value for this instance is 120 seconds, instance-specific data. One of the goals of policy-based (configuration) management is to improve the efficiency of configuration operations. This is accomplished in part by eliminating the necessity of sending to the managed device a configuration object for every instance of that object in a system. For example, if we wanted to change one of the BGP parameters referenced above on a large system for each interface that is supporting the BGP, there may be many individual commands needed to accomplish this task. If a command line interface were used as the primary configuration tool in this example, many configuration commands would be needed as well. When we say that a a policy is at the instance independent level of abstraction, we mean that the value for a particular parameter is independent of the instances to which it will be applied. To make things more concrete, consider a voice over IP application. In order to 'make the sale', the service Saperia Expires January 6th 2001 [Page 9] Internet Draft Policy Configuration with SNMP July 6, 2000 provider must guarantee certain characteristics of the traffic to the customer. At a business or non-technical level, what the customer may want is that the voice over IP application traffic carried by the service prover has the same general characteristics as regular telephone service. More specifically, his might be expressed as 'Authorized IP phone calls get enough bandwidth and latency and jitter control for TDM (time-division multiplexing) equivalent telephone service'. While this is important from a business perspective, it does not say much about how the network would be configured to deliver this type of service. This is where the additional levels of detail are required. The increasing levels of detail that are needed to fully specify this service all the way down to specific values for specific instances are illustrated in the following table using the terms we have defined: TABLE 1. Increasing Detail for Each Level of Abstraction See .ps version of this paper for table with graphics. Domain-Specific (DiffServ is used for our examples): if sourceIPAddress == 172.3.128.0/15, && DSCP == 101110 THEN mark voice traffic with Expedited Forwarding. Mechanism-Specific: For DSCP value == 101110 then set Random Drop Parameters (e.g., RED) to be QMin (minimum queue size) = 0 and PMin (lowest drop probability) = 0 and QMax (maximum Queue Size) = 5, and PMax (maximum discard probability = 100). There is no MIB Module for RED currently defined, but to carry our example further we could create MIB Objects that would contain these default values: QMin = 0 PMin = 0, QMax = 5, PMax = 100 Implementation-Specific: In this example we are not adding any implementation-specific parameters. Were they needed, they would appear at this level. One might see them as augmentations to the table shown in the mechanism-specific level. Saperia Expires January 6th 2001 [Page 10] Internet Draft Policy Configuration with SNMP July 6, 2000 Instance-Specific: At this level of abstraction, the specific values for each instance of each queue that has been selected to enforce the policy would be visible. If there were just 10 queues that would be 40 objects with just the 4 objects that were speci- fied in the previous level. In our fictional RED MIB Module we would have a table that looked in part like: Index QMin PMin QMax PMax 1 0 0 5 100 2 0 0 5 100 3 0 0 5 100 4 0 0 5 100 ........... 4.1.3. Levels of Abstraction A policy management system must be able to work with information at all these levels of abstraction from the domain to instance-specific since they are so closely interrelated. A policy system must also make it easy to move and map from one level of abstraction to another. As one moves from the least specific to the most specific level of detail, the instance-specific, the lower layer depends on the layers above. In the BGP example we used earlier it would make little sense to talk about a data value of 120 without knowing what the value was describing. We use the terms dependent and independent to describe this relationship. Here is an examples from the previous table: 1. Domain Dependent, mechanism, implementation and instance independent. If sourceIPAddress == 172.3.128.0/15, && DSCP == 101110 THEN mark voice traffic with Expedited Forwarding. At this level of abstraction, notice that this policy has not been applied to any specific device, nor has the specific mechanism through which the Expedited Forwarding is to be realized been defined. We have simply moved to a more specific level of abstraction. In this case we have Saperia Expires January 6th 2001 [Page 11] Internet Draft Policy Configuration with SNMP July 6, 2000 selected a specific technology area, Differentiated Services since we are using Expedited Forwarding, a term defined within that technology area 2. Mechanism Dependent and Implementation and Instance Independent. If DSCP value == 101110 then set Random Drop Parameters (e.g., RED) to be QMin (minimum queue size) = 0 and PMin (lowest drop probability) = 0 and QMax (maximum Queue Size) = 5, etc. Notice that this information is dependent on mechanism-specifics but not on any implementation or instance information. A policy can be expressed, at least in theory, in a mechanism-specific and implementation-independent fashion. Refer back to the RED mechanism in the table, there are several parameters that will require configuration to achieve a particular result. People would like to express policy configuration in such a mechanism independent way to make work simpler. The details of the implementation from one device to another, even when the devices come from the same vendor, make it unlikely that mechanism-specific, implementation independent configuration information will be deployed on systems. Accordingly, the implementation-specific information in Table 1 would generally be filled-in in a realization of differentiated services by a particular vendor. The reason for this is that while mechanism-specifics such as routing protocols, etc. are published as standards, most vendors add to these standards in their product implementations. What will be deployed more often, will be mechanism and implementation dependent defaults that a policy system can send to managed devices that match a particular implementation and mechanism pair as was the case in the routing software example in the implementation-specific definition section. The vendor added the capability to support features that were not part of the standard which defines mechanism-specific details. To properly configure that vendor's system, both the mechanism-specific as well as vendor extensions, implementation-specific, information must be supplied. Some vendors make these additions as a result of customer requests or the perception that they will improve their market differentiation. Another reason for this is that standards are not perfect. They can be incomplete for any number of reasons including the fact that vendors are often able to respond more rapidly to changes in customer requirements than the standards bodies. Saperia Expires January 6th 2001 [Page 12] Internet Draft Policy Configuration with SNMP July 6, 2000 5. The SNMP Configuration Working Group This section, and the ones that follow, describe how SNMP can be applied to the area of policy-based configuration while at the same time performing simple configuration tasks and all of the other tasks to which it has been successfully applied. An important benefit of using SNMP for simple as well as policy- based configuration is that with all configuration data associated with instance level details, e.g., specific interfaces and their status and counter values, it is much easier to understand the relationship of faults and utilization of resources with specific policies. This association still allows for the efficient transfer of configuration commands to the managed devices in terms of the policy levels described above. SNMP-based policy configuration offers considerable flexibility by allowing the selection of the level of abstraction needed for the task. It is still possible to set individual instance level parameters as has always been the case. This approach also provides for higher level configuration abstractions to be sent to the managed devices in a network which can provide a significant reduction in the amount of information to be exchanged between the management application and managed devices. 5.1. Charter and Goals The working group is examining configuration management with SNMP in a fairly broad context. It is not limited to policy- based configuration nor is it limited to traditional instance-specific configuration issues. There are three deliverables that have been chartered: 1. A Best Current Practices document to provide guidelines on how to best use the existing Internet Standard Management Framework to perform configuration management. 2. A MIB module which describes a network entities capabilities such as support for a particular type of security or a particular queuing method on certain interfaces. The module will also convey the capacity of the device to perform certain work. 3. A MIB module which can be used to concisely convey information about desired network wide DiffServ Based QoS Saperia Expires January 6th 2001 [Page 13] Internet Draft Policy Configuration with SNMP July 6, 2000 behavior. 5.2. The SNMP Architecture and Configuration Model An understanding of Policy and the different levels of abstraction that are used when discussing policy, enables mapping of the Internet Standard Management Framework to the Policy Framework. RFC 2571, An Architecture for Describing SNMP Management Frameworks, restates some of the basic architectural principles that have guided SNMP-based management for over a decade. From section 1.2 An SNMP management system contains: - several (potentially many) nodes, each with an SNMP entity containing command responder and notification originator applications, which have access to management instrumentation (traditionally called agents); - at least one SNMP entity containing command generator and/or notification receiver applications (traditionally called a manager) and, - a management protocol, used to convey management information between the SNMP entities. The architecture assumes AT LEAST one management system which implies in many cases that there is a need for more than one. The SNMP architecture has been designed to support multiple managers since its inception. As networks become more complex, the redundancy possible with this architecture will become increasingly important. For the purpose of this document, a policy management application is a generic term. It can be any combination of the five applications that are described in RFC 2571: Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. A common combination will be Command Generators combined with Notification Receivers. FIGURE 1. The Internet Standard Management Framework Saperia Expires January 6th 2001 [Page 14] Internet Draft Policy Configuration with SNMP July 6, 2000 5.2.1. The Policy MIB Module Given this architecture, it is a simple and low-cost matter to add policy-enabled management within the SNMP architecture. In fact all that is required is the addition of one MIB Module. The SNMPCONF Working Group has named this the Policy-Based Management MIB Module, or Policy Module for short. FIGURE 2. The Policy MIB Module - See the .ps version. The Policy Module helps translate from one level of abstraction to another. It helps move from the mechanism independent to the mechanism dependent and helps move from the instance independent to the instance dependent level of abstraction. Here are some terms used in the Policy-Based Management MIB Module. Note that Policy, Policy Filter, Policy Action and Role definitions are from the Policy-Based Management MIB Module draft: http://ietf.org/internet-drafts/draft-ietf-snmpconf-pm- 01.txt: Policy - in the context of the Policy MIB Module, a policy is expressed as: if (policyFilter) then (policyAction). Policy Filter - The policy filter is an SNMP object that contains an expression that results in a boolean that is used to determine if an element is to be a member of a set of objects on which an action is to be performed. Policy Action - The policy action object contains what parameters are to be modified on instances in the system that match the policy filter expression. These actions could be to turn an interface on or off, or cause the configuration of a complex set of objects as might be the case in Differentiated Services. In that case, the action would be expanded by the information for the policy found in the mechanism, and if necessary, implementation- specific tables. An action could also be as simple as Saperia Expires January 6th 2001 [Page 15] Internet Draft Policy Configuration with SNMP July 6, 2000 causing a particular device to download a new version of operational code. Role - A role is an abstract characteristic assigned to the element. These abstract roles can express a geographical, political, financial, legal or architectural attribute. Most often these attributes are not algorithmically determinable. The Policy MIB Module contains standard MIB tables managers can populate that: 1. Tell the managed system what policy filters to apply in order to select the instances to which a specific policy (action) should be applied. 2. Tell the managed system what roles apply to which instances. We can define roles such as; serves customer A, or is a backup interface in tables in this MIB Module. For our Voice over IP customer, these could be interfaces that have had the role assigned to them of serving this specific customer and are also currently up to date on their premium service payments. When the managed system must determine to which instances to apply the policy, it evaluates these roles and their associations with instances (interfaces in our example). It accomplishes this function based on the filter object that is supplied with each policy. This filter is applied to the roles assigned to instances in the device, and a result list is created to which the configuration operations appropriate to the policy are applied. Part of the filter specification can be information that the managed system can use to restrict the scope of the role search for efficiency purposes. 3. Tell the managed system when and how long the policy should remain in effect, for example every Monday to Friday from 9 am to 5 pm. Saperia Expires January 6th 2001 [Page 16] Internet Draft Policy Configuration with SNMP July 6, 2000 4. Tell the managed system if and how to apply mechanism-specific such as DiffServ and instance and implementation independent parameters as needed to the instances that are appropriate to the local system. The mechanism-specific parameters are found in the mechanism-specific MIB Modules such as the Differentiated Services Policy MIB Module that is described in the next section. The policy MIB Module also provides important information to the management system. This information includes: 1. The current state of the Policy. 2. Global utilization information about the resources used by a particular policy. 3. The mechanisms that the implementation supports. The Policy Module contains objects that identify the capabilities that the system supports. It is planned that standard capabilities will be published by IANA. 4. The specific instances that are associated with one or more of the roles identified earlier. The first part of a policy in the Policy Table is a policy filter. This contains the roles that a specific instance must match before the policy action part is to be applied. The second part is a policy action that contains the operations the system is to perform on instances to which the policy applies. The policy table also contains pointer information for the scheduling of a policy as well as information that can be of value when debugging and information about the status of each policy. The Role Table in the Policy Module is configured with roles strings that are to be associated with elements of a system under policy control. The role table is really two tables; first is the pmRoleESTable where role strings are assigned to specific elements. The pmRoleSETable is a read-only table indexed by role string and could be very helpful in debugging situations. Scheduling information is contained in tables external to the Policy MIB Module. That information is in [SCHED]. In the case of differentiated services and other complex technologies Saperia Expires January 6th 2001 [Page 17] Internet Draft Policy Configuration with SNMP July 6, 2000 there can be many objects that need to be configured to realize a particular policy. Having these objects separately visible makes inspection and modification of parameters for such complex policies an easier matter and makes it possible to download policy in a mechanism and implementation independent fashion to the Policy Module since the mechanism and implementation-specific details are potentially in mechanism and technology specific modules. In the cases where mechanism-specific and instance-specific MIB modules have been defined, both MIB Modules should be supported. A object will be defined so that if a change is made to the instance-specific MIB Module that affects an instance under the control of a policy, the Policy MIB Module will be able to reflect that an object under its control has been changed. If present, a mechanism/implementation-specific MIB Module will also be able to convey that a change or changes have been made at the instance-specific level. This information can be conveyed via MIB objects that reflect the state of the policy. The Policy Module allows for the expansion of the Mechanism Independent to the Mechanism and Implementation Dependent, when needed, through the connection to the Mechanism/Implementation Dependent MIB Modules. These specific modules take the instances that have been selected as a result of the expansion of the policy filter and then expand the 'default' mechanism, and where appropriate, implementation-specific parameters to each of the selected instances. In some simple domains, there may be no value in both mechanism dependent and independent levels. An example would be policy which states that all devices must run the latest approved version of the operating system. In these cases there are not a number of different mechanisms and related parameters so this additional component may not be needed. In this case, the Policy MIB Module may interact directly with the instance-specific, the lowest level of abstraction, instrumentation in the device.The SNMP Configuration Working Group has developed an example of a MIB Module that converts from the mechanism and implementation independent methods to mechanism, implementation, and instance-specific levels. This MIB Module is the Differentiated Services Policy MIB Module. 5.2.2. Mechanism and Implementation-Specific MIB Modules Sometimes mechanism-specific attributes are needed to fully specify a policy. In some cases, both mechanism and implementation-specific attributes must be specified for an Saperia Expires January 6th 2001 [Page 18] Internet Draft Policy Configuration with SNMP July 6, 2000 effective policy to be configured if the vendor has added extensions to a standard mechanism or has created a mechanism inside a particular domain. The architecture allows for the policy action to contain mechanism and implementation-specific references. However, there are cases where there is value in having this policy action include this mechanism and/or implementation-specific information by reference rather than by value.The value of having these separate tables pointed to by the higher layer Policy MIB module is for facilitating good management applications that can operate on these different levels of abstraction as needed by the various users. This separation also avoids unnecessarily complex configuration of policy actions in the Policy Module and potentially makes debugging a bit easier since the policy action is an expression that an application would have to know how to parse in order to reasonably present the information whereas the mechanism and implementation-specific MIB Modules contain the information in a form that most SNMP-based management applications are well able to 'understand' and display. This helps leverage the considerable investment in our SNMP-based infrastructure. FIGURE 3. Mechanism and Implementation-Specific MIB Modules - See .ps version The part of our policy enabled system that can move from the mechanism independent to the mechanism dependent is a Mechanism-Specific MIB Module. Implementation-specific attributes can be defined in a vendor specific extensions to mechanism-specific MIB Modules since the IETF does not specify implementation-specific mechanisms. If a vendor were to require implementation-specific extensions to a mechanism that has been defined, they would add them to this MIB Module, probably through the use of an AGUMENTS clause. This approach is identical to the approach vendors have used for the extension of standard instance-based attributes with their own. The SNMP Architecture was designed with this extensibility in mind. Many vendors realize both standard and vendor specific MIB Objects in the same software module, and it is expected that this will also be the case when a vendor extends IETF standard MIB modules that have been defined at the mechanism-specific level of abstraction. The information in the mechanism-specific MIB Module does not always have to be located apart from the instance-specific MIB Saperia Expires January 6th 2001 [Page 19] Internet Draft Policy Configuration with SNMP July 6, 2000 Module. Some working groups in the future may choose to create policy tables in their instance-specific MIB Modules. Having the extra MIB objects, whether in a separate MIB Module as we have for the differentiated services domain, or as extra tables in future domain specific MIB Modules is of less importance than having the information separately available. 5.2.3. Instance-Specific MIB Modules The last element to add to our architecture is the traditional MIB module. This module is at the instance-specific level of abstraction. It, too, can be based on an ITEF standard and have augmentations for implementation-specific instance values as has been common for some time. If a vendor has implementation-specific MIB objects, they should also provide MIB objects for these implementation-specific details at the instance independent level (mechanism and implementation dependent). An implementation-specific MIB module without a corresponding instance based version of those objects would make it impossible for an SNMP based management system to see the instance-specific values on which the implementation- specific MIB module is presumed to operate on. The information sent by the management station to the mechanism and implementation-specific MIB Modules is expressed in Implementation and Mechanism dependent and instance independent terms. When the policy management application wants to have the policy activated in the managed device, a command is issued that causes the managed element to take the information in the Policy MIB Module and the mechanism and implementation-specific MIB Modules and combine them to create the implementation, mechanism and instance-specific information used by the device. The instances are created using the native facilities in the instance-specific MIB modules and the values of the instances are visible in the instance-specific MIB modules as has traditionally been the case with SNMP-based information. FIGURE 4. Mechanism, Implementation and Instance-Specific MIB Modules - See .ps version. Saperia Expires January 6th 2001 [Page 20] Internet Draft Policy Configuration with SNMP July 6, 2000 5.3. The process of Configuration Management In this section we will walk through the steps an integrated SNMP-based policy management system would take to configure a system that is 1. Users provide policy information to the management applications. In order for the policy management applications to correctly control policy in all of the managed elements, users must provide information of several types to the policy management applications. It is possible that 'users' in this case could also mean software that extracts information from other sources. The types of information needed by a policy management application are: - The filter/rules that are to be sent to each managed device. This is the information that is used to determine to what instances a policy is to be applied. This information will be sent to the Policy Filter object in the Policy Table of the Policy MIB Module. A policy could require several conditions to be met before an instance in a device is to be included. For example, the filter could require that the policy be applied only to interfaces that are Ethernet and are also connected to certain departments such as the accounting department. A different rule for another policy might require that an interface be an OC-12 and be connected to a particular carrier before the policy is applied. - Schedule information. Some policies are intended to run continuously, while others 'fire' once, and still others run only at specific time periods. The information that is to be sent to each managed device in the network that is to carry out this policy must be provided to the management application. - Implementation and mechanism-specific information. These are the details of how the policy is realized in a device. This is how the administratively defined policy and policies expressed at the implementation, mechanism, Saperia Expires January 6th 2001 [Page 21] Internet Draft Policy Configuration with SNMP July 6, 2000 and instance independent levels of abstraction get translated to something that is meaningful to a network device. To use our telephony example, the parameters would be specific to a particular vendor and perhaps even model. This is the instance independent information that is sent to the mechanism and technology specific MIB Modules. In the case of differentiated services, this information could include the values that all queues associated with a specific policy should use for their Weighted Fair Queuing parameters. - Many of the 'Roles' that are expressed in the policy filter object are not algorithmicly determinable by a computer system and must be assigned on each network device. It may not be possible for the network element to know that some interfaces are connected to the accounting department or that other interfaces are connected to a specific carrier. For this reason, the management application will have to configure the 'Role Table' in the Policy MIB Module. This is how the managed element will know that a particular interface matches or does not match a particular policy filter. One of the advantages of using SNMP for policy based management is that many of the 'filters' that people would want to use are already defined in terms of MIB objects and thus can be used directly. For example, the type of interface used in the example above would be very easy to specify to a managed element by giving the specific value of the object that contains the interface type as one of the parts of the policy filter. FIGURE 5. An SNMP-Based Policy Management System - Inputs - See .ps version Figure 5 represents inputs that are required for a policy enabled SNMP management system. Note that the architecture does not specify or assume the origin of the role, schedule, filter or mechanism and implementation- specific information. This is consistent with current practice in the SNMP community. Management software today takes inputs from humans, database systems and other repositories as well as a wide variety of standard and proprietary APIs. Also note that the architecture does not assume that the management applications run in a Saperia Expires January 6th 2001 [Page 22] Internet Draft Policy Configuration with SNMP July 6, 2000 particular location. It is likely that manager stations dedicated to policy or other management activities will be used to manage numbers of network elements at one time. SNMP will be the protocol used to communicate that management information. There is nothing inherent in the policy work that would prohibit a vendor from putting these applications on any system, mid-level manager or managed element. Configuration in an SNMP-based policy management system continues after the first step is completed as just described, see item 1 that began this section. The next steps are: 2. Mechanism-specific subsystem in the managed device registers with policy module. The policy module has a capabilities table that is populated by the various mechanism-specific subsystems in a machine. In our case, the Differentiated Services Policy MIB Module would register with the Policy MIB Module that it is present and can perform Differentiated Services Functions. This registration mechanism would really be no different that the registration mechanism that many implementations of master and subagent technology use today. Many such technologies provide a way for a subagent to tell the master agent what MIB objects it supports when the subagent is started. 3. Manager then 'knows' system capabilities (e.g., Web Server, VPN Support, Differentiated Services, MPLS). Managers will need to know the mechanism-specific details supported by each subsystem. In some cases it may not be easy to disambiguate what they are without interrogating the mechanism-specific subsystem (e.g., what WFQ parameters are supported on this system that is running a particular software release). There are two mechanisms through which a manager can 'learn' the capabilities of a device as represented in the capabilities table. The first, and preferred method, is by the managed device sending an INFORM to the manager whenever there is a change in the capabilities table. Some management applications may want to check the entire contents of these tables periodically. Note that in the case of an Saperia Expires January 6th 2001 [Page 23] Internet Draft Policy Configuration with SNMP July 6, 2000 SNMP INFORM, these messages are acknowledged by the manager so that the managed device knows the message has been received. An important advantage of this approach is that multiple management systems can be kept in sync with the managed devices in a network without polling and without having to maintain a TCP connection to every managed device in the network. 4. Managers/management software send previously defined roles to each device and associate them with specific instances in the device. This is accomplished by the manager via sending SNMP SET operations to the Role Table in the Policy Module in each managed device. Roles can be just about anything from an indication that an interface marked with this role serves an Executive office, to the interface is a backup, to the person connected to the interface has not paid for premium services. Roles can be associated with any instance specific element, from a particular instance of an Ethernet interface to a specific instance of a Web server. 5. Managers send policies to managed devices. This can take one of two forms as mentioned previously. In a simple case, the policyAction MIB Object contains a simple expression (we used the load Operating System version earlier). In the case where there is a great deal of mechanism-specific information to be conveyed as in the case of Differentiated Services or Routing Policy, then a mechanism-specific module is recommended. The mechanism and implementation independent policy is loaded into the Policy Module by the management application and the implementation and mechanism-specific defaults (where necessary) are loaded into the mechanism and implementation-specific MIB Modules in the device by the manager. The policyFilter object in the Policy table contains the expression sent by the management system to the device that the device is to use to determine which instances to apply the policyAction to. 6. Managed devices evaluate the Policy Filter and Policy Action Objects to determine where and when the policy is applied. Note that an important part of the Policy Module Saperia Expires January 6th 2001 [Page 24] Internet Draft Policy Configuration with SNMP July 6, 2000 is a pointer to [SCHED] that tells the system when and for how long to execute a policy. The expression contained in the policy filter contains the information that the managed device requires to look through the Role table to determine which instances of objects to apply the action contained in the policyAction object. 7. Implementation and Mechanism-specific module sets necessary values via instance-specific subsystem. If the policy action indicated a mechanism and implementation- specific module, then the various mechanism and implementation-specific parameters associated with the policy would be applied to the instances that were the result of the policy filter evaluation of the Role Table. An important characteristic of this approach is that implementation-specific additions are easily accomplished with this approach via augmenting the mechanism-specific MIB Modules. This is exactly the same approach that vendors have used for some time to add extensions to standard MIB Modules for configuration and monitoring operations. 8. Management software monitors usage and status to refine policy and verify policy changes. Since this approach does make it possible for a management system to know the instances that are being used to support policies, they can better monitor and control overall network behavior. For example, if there is an interface failure that is associated with a policy, a manager can be informed and perhaps display the policies that are likely to be impacted by such a failure. Additionally, this approach would allow more effective data collection of performance statistics so that vendors can better plan what resources they need to upgrade in order to support their customers before the resources reach exhaustion. Part of the power of an SNMP-based policy system is the integration of fault and other types of information in the same infrastructure, they use the same administrative framework, and share common access methods. Without the feedback provided by fault, utilization, performance and other data, it is like driving a car with your eyes shut. You have all the control offered by the steering wheel, Saperia Expires January 6th 2001 [Page 25] Internet Draft Policy Configuration with SNMP July 6, 2000 brake and accelerator but your feedback is limited to what you can hear and feel when you touch something. It is possible to have someone tell you where you are on the road, or if a car is approaching, but this is far less effective than using your own sight that is directly linked to your control system, your feet for brake and accelerator and your hands for the steering wheel input. This level of indirection is even more severe if the person watching the road speaks a language that you cannot understand and must be first translated to your language by another unfortunate rider in your car. The same is true of systems that attempt configuration operations without the important data noted above. It is possible to have another system inform the configuration system about faults, over-utilization, and remaining capacity. The additional levels of translation and indirection can be expensive and are not necessary if all the data is in a common language. We have that language, the SMIv2, and the MIB Objects that are defined with it. This is not to say languages cannot evolve - the v2 indicates this. As new features are required for the future they can be added, just as new features have been added to routing protocols and other essential elements of the Internet infrastructure. Not included in this discussion is the important work of the application development that must take place. These applications will take information from policy servers, the network and humans to do the right things. The diagram that follows illustrates parts of an SNMP policy-enabled management system involved in the various steps described above. This example is for Differentiated Services, though many others are possible and expected over time. Users provide information to the management applications that the applications will use to configure the various network elements. This information is used by the network elements to evaluate the information that fully describes the policy and then configures the required parts of itself to achieve the desired behavior. FIGURE 6. A Complete SNMP-Based Policy Management System - See .ps version. Saperia Expires January 6th 2001 [Page 26] Internet Draft Policy Configuration with SNMP July 6, 2000 5.3.1. But Can I do Simple Configuration? The MIB Modules described do not in any way interfere with basic, simple configuration operations that people may want to perform. Traditional instance based configuration operations can continue to be used in combination with the more powerful policy-based configuration operations. 6. Conclusion This document provides a framework for policy-based configuration with SNMP and an introduction to common terms used in that framework. The SNMP Configuration Working Group has not yet completed its initial work though substantial progress has been made on all of the documents it is working on. It is now clear that with just a few MIB Objects, it is possible to create a powerful, efficient and integrated policy management system using the Internet Standard Management Framework. It is also clear that this approach to policy based management maps well to the work undertaken in the Policy Framework Working Group. 7. Acknowledgments Many ideas in this paper have been informed by conversations with and comments by my colleges. I would like to acknowledge their contribution to my understanding of the problem. A few individuals that have made special contributions I would like to acknowledge: Andy Bierman, Jeff Case, Joel Halpern, Bob Quinn, John Schnizlein, John Strassner, Steve Waldbusser, Walter Weiss, and the other members of the editing team that have contributed to the SNMP Configuration documents, Harrie Hazewinkel, Thippanna Hongal, Mike MacFaden, and David Partain. Some individuals have also provided feedback on numerous revisions of this document. I would also like to thank the SNMPCONF co-chair, David Harrington, for his detailed editorial review of several drafts of this document. 8. General References to Web Pages Here is a list of URLs to the various documents or working groups that may be of interest referenced in this paper. The Saperia Expires January 6th 2001 [Page 27] Internet Draft Policy Configuration with SNMP July 6, 2000 working group pages contain some of the summary information used in this document as well as pointers to relevant IDs as well as many of the RFCs that are of interest. [SNMPCONF] Configuration Management with SNMP (snmpconf): http://www.ietf.org/html.charters/snmpconf-charter.html [POLICY] Policy Framework (policy): http://www.ietf.org/html.charters/policy-charter.html [RAP] Resource Allocation Protocol (rap): http://www.ietf.org/html.charters/rap-charter.html [SNMP] SNMP Version 3 (snmpv3) http://www.ietf.org/html.charters/snmpv3-charter.html [DIFFSERV] Differentiated Services (diffserv) http://www.ietf.org/html.charters/diffserv-charter.html [IPSEC] IP Security Protocol (ipsec) http://www.ietf.org/html.charters/ipsec-charter.html [INTSERV] Integrated Services (intserv) http://www.ietf.org/html.charters/intserv-charter.html Saperia Expires January 6th 2001 [Page 28] Internet Draft Policy Configuration with SNMP July 6, 2000 [BGP MIB] ftp://ftp.isi.edu/in-notes/rfc1657.txt [SCHED] Definitions of Managed Objects for Scheduling Management Operations ftp://ftp.isi.edu/in-notes/rfc2591.txt Saperia Expires January 6th 2001 [Page 29] Internet Draft Policy Configuration with SNMP July 6, 2000 9. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [3] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [6] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [7] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [18] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [9] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [10] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [11] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Saperia Expires January 6th 2001 [Page 30] Internet Draft Policy Configuration with SNMP July 6, 2000 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 represent 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 implementors 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 technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Authors' Addresses Jon Saperia JDS Consulting 174 Chapman Street Watertown, MA 02472 email - saperia@jdscons.com 12. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above Saperia Expires January 6th 2001 [Page 31] Internet Draft Policy Configuration with SNMP July 6, 2000 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 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. Saperia Expires January 6th 2001 [Page 32] Internet Draft Policy Configuration with SNMP July 6, 2000 Table of Contents ^ 1 Abstract .............................................. 2 2 Introduction .......................................... 2 3 History and Background ................................ 4 4 Definition of Terms ................................... 6 4.1 Defining the Term Policy ............................ 6 4.1.1 What is a Policy and how does it relate to Configuration? .................................... 7 4.1.2 Terms and Relationship to Policy Framework Working Group ...................................... 7 4.1.3 Levels of Abstraction ............................. 11 5 The SNMP Configuration Working Group .................. 13 5.1 Charter and Goals ................................... 13 5.2 The SNMP Architecture and Configuration Model ....... 14 5.2.1 The Policy MIB Module ............................. 15 5.2.2 Mechanism and Implementation-Specific MIB Modules ............................................ 18 5.2.3 Instance-Specific MIB Modules ..................... 20 5.3 The process of Configuration Management ............. 21 5.3.1 But Can I do Simple Configuration? ............... 27 6 Conclusion ............................................ 27 7 Acknowledgments ....................................... 27 8 General References to Web Pages ....................... 27 9 References ............................................ 30 10 Intellectual Property ................................ 31 11 Authors' Addresses ................................... 31 12 Full Copyright Statement ............................. 31 Saperia Expires January 6th 2001 [Page 33]