Subject: snmpconf BCP To do items #1

From: Jon Saperia <[email-masked]>
Date: Thu, 19 Apr 2001 10:28:10 -0400

The following is a revised section from the BCP draft.

7.1.  Organization of Data in an SNMP-Based Policy System

The number of configurable parameters and 'instances' such as interfaces
has increased as equipment has become larger and more complex. At the
same time, there is a need to configure many of these systems to operate
in a coordinated fashion. This enables the delivery of new specialized
services that required this coordinated configuration. Examples include:
delivery of virtual private networks and connections that guarantee
specific service levels.

The growth in size and complexity of configuration information has
significant implications for its organization as well as its efficient
transfer to the management agent.  As an example, a Bridge MIB [22]
agent which represents a large VLAN across could have some 65,000
(virtual) port entries. To configure such a VLAN, it would require the
establishment of dot1dStpPortTable and dot1DStaticTable entries for each
such virtual port. Each table entry would contain several parameters. A
more efficient approach is to provide default values for the creation of
new entries that are appropriate to the VLAN environment in our
example. The local management infrastructure should then iterate across
the system setting the default values to the selected ports.

The way that configuration has been accomplished to now is with file
transfer, by setting individual MIB objects, or with many CLI
commands. In each of these approaches the details for each instance are
contained in the file, CLI commands or MIB Objects. That is, they contain
not only the value, and type of object, but the exact instance of the
object that the value is to be applied to. It is this property that
tends to make configuration operations explode as the number of
instances such as interfaces grows.  This [instance-specific approach]
can work for a few machines configured by experts, but there is a desire
for a more scalable solution. Policy based management abstracts the
details above the instance level which means that fewer SET requests are
sent to a managed device.

Realization of such a policy-driven system requires agents that can take
defaults, and apply them to instances based on a rule that says under
what conditions the defaults (policy) is to be applied. In short, we
need to layer the information so that simple commands can be sent to
devices which then are expanded to produce the increased (instance
level) information that devices require for operation.

7.2.  Layering 

In order to present the principals of policy based management with SNMP,
we will create a MIB Module called the Building Heating Ventilation and
Air Conditioning (HVAC) MIB Module. This allows the discussion to focus
on the new principles as opposed to a specific area of technology. Note
that while the focus of this discussion is on configuration, the
abstractions discussed in this section could equally apply to fault,
performance, accounting or security objects.

Instance-Specific

Instance-specific information refers to values associated with a
specific instance in a managed element. One example would be the number
of octets that were received on a particular interface, ifInOctets. In
our example MIB Module, we will have fan and temperature settings for
every control panel in the building. Imagine how many there would be in
a 50-story office building or multi-acre office park. Network operators
have a similar problem, parameters for many routers and the interfaces
they contain.  Each interface will have an ever increasing number of
values that must be configured to deliver specialized services such as
Differentiated Services.

Mechanism-Specific

The first layer of abstraction above the familiar instance-specific level
is known as mechanism-specific. This is the level that contains the
defaults that would be applied to the instance-specific objects.

A mechanism is a specific way that a function is accomplished. For
example, in the area of routing, BGP has a number of mechanisms that are
used to realize the specified behaviors. As a result, there are many
parameters that apply specifically to BGP and its associated mechanisms
that it uses to accomplish it's routing task such as time-out values
etc.

MIB objects that are mechanism-specific are the defaults used for
instance-specific MIB object creation or modification as described in the
previous section. The are the defaults for standard instance-specific
MIB objects when used in an SNMP-based policy system.  Policy
descriptions that include the details associated with a particular
mechanism are said to be mechanism-specific. In our HVAC example, we
have several mechanisms that are used in the standard MIB module to
control how fast a fan is to turn and what position a switch is to be in
for heating or cooling.

Mechanisms have on additional attribute that distinguishes them. They are
technologies defined in standards that are used within a particular area
such as our routing example. Mechanism-specific MIB Objects then, are a
layer of abstraction above standards-based instance-specific MIB
objects.

Implementation-Specific

Vendors often add special capabilities to standards as a way of
meeting special customer requirements or differentiating themselves from
their competitors.  Implementation-Specific MIB objects have the same
properties as mechanism-specific ones except they have been created as
abstractions for vendor created instance-specific MIB Objects.

These special capabilities are often a result of the implementation
approach that a vendor has used for the product, thus the term
"implementation-specific". In our HVAC example, some vendors might
extend the standard to include features that distinguish their products
from their competition. In our example MIB module, the system is a
sophisticated one and allows for the control of the humidity, which is
not part of the HVAC Standard MIB Module and as such there would be no
mechanism-specific MIB objects for humidity.

In summary implementation and mechanism specific MIB Objects occupy the
same level of abstraction in our hierarchy, just above the familiar
instance-specific level. The only difference is that mechanism-specific
MIB Objects are defined in a standards body, while
implementation-specific objects are defined by vendors in the same way
that vendors define their extensions today.

Higher Levels of Abstraction

If the world consisted of only of MIB and protocol experts, the
abstractions described above would be sufficient. They enable the
efficient transfer of information from management systems to managed
devices. The fact is that many people need to interact with systems that
manage SNMP based configuration data that know nothing about the
protocol details. There are vendor and model differences that make the
addition of two layers above the mechanism and implementation-specific
layer helpful. The higher levels of abstraction that are defined next
help achieve some important operational goals and make it possible to
write better management software. Here are some of benefits for
organizing SNMP-based information into higher levels of abstraction:

     1. Abstract the details of the differences in technology away from
     the users. This is a common principle in programming. The user of a
     service should not have to know the details of how the service is
     implemented. OSPF and BGP are both routing protocols but have
     different knobs. If you want to add a new system to the network at
     the present time, you have to have an expert in both if you use
     both technologies. Different implementations of WEB servers have
     different 'knobs'. To change a configuration or add a new service
     to each, you need a person who knows the individual knobs. A
     solution to this is to write software that abstracts above this
     level.

     2. Abstract the differences from one vendor to another. Even when
     standard technologies are implemented, vendors will have
     variations. In a multi-vendor environment this means that not only
     do you require technology experts, but you have to have experts
     that know the differences in the knobs for each technology for each
     vendor. In the case of SNMP, these knobs are MIB Objects.

Domain-Specific

A useful way to abstract information above that which is carried in
implementation or mechanism-specific MIB Objects is at the level of a
Domain. 

A domain is a short-hand way of referring to all of the mechanisms that
it contains. In the routing examples we have been using, BGP would be
one domain that contains many mechanisms. This is also true for
OSPF. The same is true in the area of Quality of Service, there are many
areas of technology (domains) that could be used to deliver quality of
service. Differentiated Services or 802.1p are two examples that have
very different mechanisms. Our HVAC MIB module has several knobs for
mechanisms that can be used to control the climate inside a building. It
is possible to imagine a very different set of technology that instead
of using fans, controlled exposure of solar cells to change the
temperature. The SNMP infrastructure gives us a number of convenient
ways to reference domains though the mapping is not always
perfect. These handles include the base OID of a MIB Module or the
tables in a MIB Module.

Since the OIDs are not necessarily contiguous, several of them may be
used to fully specify a domain. In the future IANA could become a
registry for such identifiers.

The Services Layer

Some management applications may find it helpful to present one layer of
abstraction above the domain level: services. At this layer we no longer
refer to specific technologies such as BGP, or OSPF, or Differentiated
Services. We refer to routing or Quality of Service. This is the layer
that many business operate at. One example is that they sell WEB or Name
services without referencing the specific technology domain that will be
used to realize the service. In most circumstances they will certainly
not reference the mechanisms used to realize the WEB Services for
example. 

Thanks,
/jon

--
Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/