Slide 1 2/22/2016 Policy-Based Management With SNMP SNMPCONF Working Group - Interim Meeting May 2000 Jon Saperia

Slide 2 2/22/2016 Presentation Goals u Provide a common starting point for our discussions by: –Defining common terms - terms in common with Policy Framework Working Group –Presenting an architectural overview of current work –Describing how the proposed process of policy-based management works with SNMP u Identify areas that need further refinement

Slide 3 2/22/2016 Presentation Outline u Definition of Terms –Policy and Levels of Abstraction –Examples u SNMP Architecture –The basic elements –The Policy MIB Module –Mechanism and Device Specific MIB Modules –Support for access in managed devices at multiple levels of abstraction

Slide 4 2/22/2016 Presentation Outline - Continued u Process of Configuration Management with a policy- enabled framework based on SNMP –User definition of policy –Initialization of policy components in managed devices –Configuration of the mechanism specific sub system –Manager interaction with managed devices to learn capabilities –Definition of roles –Policy transfer to managed devices –Device evaluation of policy –Mechanism/Device specific policy module interactions –Device feedback to policy management applications

Slide 5 2/22/2016 Policy Definition u Policy means many things to different people - different levels of abstraction –The high-level -the business level - few technical details All authorized IP phone calls have to get enough bandwidth for TDM equivalent telephone service –Increasing technical detail down to the most ‘refined’ level - individual parameters for specific instances in specific devices.

Slide 6 2/22/2016 Policy Abstraction - Domains u A general area of technology such as service quality or security. u Example domains –IPSec –Differentiated Services u More than 1 domain may be needed to fully represent business level goals.

Slide 7 2/22/2016 Policy Abstraction - Mechanism dependence/independence u Mechanisms are technologies used within a particular domain such as: –RED –WFQ u Policies expressed at a higher levels of abstraction are mechanism independent.

Slide 8 2/22/2016 Policy Abstraction Implementation dependence/independence u Possible to express policy in mechanism dependent and device independent way. u Expect that it will be common to combine mechanism and device dependent layers together. –This is analogous to standard MIB Modules and vendor extensions. Even when the standard is sufficient, many vendors require additional parameters for monitoring and control. –A policy that is defined using RED could have start and stop probabilities defined that have either different queue parameters for different vendors, or other objects that are vendor specific.

Slide 9 2/22/2016 Policy Abstraction - Instance dependence/independence u A policy can be distributed to a managed device in an instance independent or dependent way. u The policy MIB Module is configured with the rules that the managed device use to identify which instances should have the device and mechanism specific policy applied.

Slide 10 2/22/2016 Policy Information at Different Levels of Abstraction

Slide 11 2/22/2016 SNMP Architecture - Basic Elements Managed Elements SNMP Agent The MIB i.e., MIB Modules The SNMP Protocol SNMP Managers with one or more applications

Slide 12 2/22/2016 The Policy MIB Module - Overview u Filters to apply for selection of instances u Role information used in instance selection Ethernet interface Serves the executive offices u Pointers for schedule information u Pointers to mechanism/device dependent MIB Modules

Slide 13 2/22/2016 Policy MIB Module - Overview Continued u Policy state information u Optionally usage information u Device capabilities: –Domains such as quality of service or IPSec –Mechanism appropriate to specific technologies WFQ WRED u Information about which instances are associated with specific roles.

Slide 14 2/22/2016 The Policy Module and other MIB Modules SNMP Agent The MIB Other ‘traditional’ Policy MIB Module Policy Module communicates with other modules as needed or with local instrumentation. device and instance specific MIB Modules

Slide 15 2/22/2016 Mechanism, Implementation and Instance Specific MIB Modules SNMP Agent Policy MIB Module Diff. Serv. Policy MIB Module - converts mechanism and implementation specific information to instance specific level Instance Specific MIB Module(s). Can contain vendor extensions Dotted lines indicate that indicated level of policy information is available to management applications, e.g., all levels are available Solid lines represent possible interactions between components containing different levels of information.

Slide 16 2/22/2016 Table and Information Relationships Role Definitions and filters for each policy Schedule Information Implementation and Mechanism dependent information for each policy Policy Management Application(s) Calendar/Schedule Objects Policy Table (an entry for every policy on the managed element. Role Table - roles are added to instance specific objects (e.g., interfaces) Capabilities Table Mechanism and device specific MIB Modules or tables

Slide 17 2/22/2016 The Entire System - Overview Administratively defined policy Device, Instance and Mechanism Independent ‘default’ information Policy System allows users to create expressions of policy for each domain. Management Application Distributes Policy Information Configuration commands to device, mechanism, and instance specific MIB Module(s) or ‘raw’ device instrumentation Device Dependent, Instance Independent,Mechanism Dependent information Mechanism specific Modules expand, defaults to instances for policy from info from Policy Module Policy MIB Module

Slide 18 2/22/2016 Sequence of Operations u Users provide information to management applications: –Filters/rules that managed elements used to determine which instances to apply specific policies - to pmPolicyFilter. –Schedule information - Policy and Schedule Modules –Device and Mechanism specific information (when needed). –Assignment of roles to instances u Mechanism specific subsystem(s) register with Policy Module. u Managers learn devices capabilities from the Policy Module.

Slide 19 2/22/2016 Sequence of Operations - Continued u Management software sets roleStrings in each device u Management software sends policies to devices –Mechanism and device information sent to devices and appropriate MIB Modules as necessary. u Managed devices evaluate policyFilter and policyAction objects to determine instance targets for policy. u Device/Mechanism dependent modules set necessary values - via communication with other MIB Modules.

Slide 20 2/22/2016 Operations - An Ongoing Activity u Monitor policy status u Monitor resource utilization u Monitor fault status