200 likes | 354 Vues
Policy-Based Management With SNMP. SNMPCONF Working Group - Interim Meeting May 2000 Jon Saperia. Presentation Goals. Provide a common starting point for our discussions by: Defining common terms - terms in common with Policy Framework Working Group
E N D
Policy-Based Management With SNMP SNMPCONF Working Group - Interim Meeting May 2000 Jon Saperia Slide 1 10/15/2014
Presentation Goals • 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 • Identify areas that need further refinement Slide 2 10/15/2014
Presentation Outline • Definition of Terms • Policy and Levels of Abstraction • Examples • 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 3 10/15/2014
Presentation Outline - Continued • 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 4 10/15/2014
Policy Definition • 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 5 10/15/2014
Policy Abstraction - Domains • A general area of technology such as service quality or security. • Example domains • IPSec • Differentiated Services • More than 1 domain may be needed to fully represent business level goals. Slide 6 10/15/2014
Policy Abstraction - Mechanism dependence/independence • Mechanisms are technologies used within a particular domain such as: • RED • WFQ • Policies expressed at a higher levels of abstraction are mechanism independent. Slide 7 10/15/2014
Policy Abstraction Implementation dependence/independence • Possible to express policy in mechanism dependent and device independent way. • 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 8 10/15/2014
Policy Abstraction - Instance dependence/independence • A policy can be distributed to a managed device in an instance independent or dependent way. • 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 9 10/15/2014
Policy Information at Different Levels of Abstraction Slide 10 10/15/2014
Managed Elements SNMP Architecture - Basic Elements SNMP Managers with one or mor e applications The SNMP Protocol SNMP Agent The MIB i.e., MIB Modules Slide 11 10/15/2014
The Policy MIB Module - Overview • Filters to apply for selection of instances • Role information used in instance selection • Ethernet interface • Serves the executive offices • Pointers for schedule information • Pointers to mechanism/device dependent MIB Modules Slide 12 10/15/2014
Policy MIB Module - Overview Continued • Policy state information • Optionally usage information • Device capabilities: • Domains such as quality of service or IPSec • Mechanism appropriate to specific technologies • WFQ • WRED • Information about which instances are associated with specific roles. Slide 13 10/15/2014
The Policy Module and other MIB Modules SNMP Agent The MIB Other ‘traditional’ P olicy MIB de vice and instance specif ic Module MIB Modules P olicy Module communicates with other modules as needed or with local instrumentation. Slide 14 10/15/2014
Mechanism, Implementation and Instance Specific MIB Modules SNMP Agent Diff. Serv. Policy MIB Module - converts mechanism and implementation specific information to instance specific level Policy MIB Module Instance Specific MIB Module(s). Can contain vendor extensions Solid lines represent possible interactions between components containing different levels of information. Dotted lines indicate that indicated level of policy information is available to management applications, e.g., all levels are available Slide 15 10/15/2014
Role Definitions and filters for each policy Implementation and Mechanism dependent information for each policy Schedule Information Table and Information Relationships Policy Management Application(s) Mechanism and device specific MIB Modules or tables 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 Slide 16 10/15/2014
Administratively defined policy Policy System allows users to create expressions of policy for each domain. Device, Instance and Mechanism Independent ‘default’ information Management Application Distributes Policy Information Policy MIB Module Device Dependent, Instance Independent,Mechanism Dependent information Mechanism specific Modules expand, defaults to instances for policy from info from Policy Module Configuration commands to device, mechanism, and instance specific MIB Module(s) or ‘raw’ device instrumentation The Entire System - Overview Slide 17 10/15/2014
Sequence of Operations • 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 • Mechanism specific subsystem(s) register with Policy Module. • Managers learn devices capabilities from the Policy Module. Slide 18 10/15/2014
Sequence of Operations - Continued • Management software sets roleStrings in each device • Management software sends policies to devices • Mechanism and device information sent to devices and appropriate MIB Modules as necessary. • Managed devices evaluate policyFilter and policyAction objects to determine instance targets for policy. • Device/Mechanism dependent modules set necessary values - via communication with other MIB Modules. Slide 19 10/15/2014
Operations - An Ongoing Activity • Monitor policy status • Monitor resource utilization • Monitor fault status Slide 20 10/15/2014