[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf System Capabilities

As some of you know, how an agent reports its capabilities to the policy
management system has been discussed a bit on the list and was an issue that
was discussed at the Interim meeting in San Francisco. I have been
exchanging ideas about this with a number of people - this was partly
sparked by a post Andrew made the other week.

The following are some additional ideas about how SNMP-based systems that
support policy can make available to policy managers, details of the
(dis)abilities of their mechanism and implementation specific MIB Modules. I
note a couple of different approaches but flesh out only one that involves
the modification of the policy table in our current policy module. I believe
there is some promise in this approach but it would benefit from additional
comments. Counter proposals for other approaches that I did not flesh out or
new ideas are welcome. I would like to get something specific into the next
draft Steve Waldbusser is working on in advance of publication for our next

This discussion began on the DIFFSERV email list in the context the the MIB
Module they are developing. In that exchange I said that I would write a
proposal of how we could accomplish advertisement of capabilities in the
SNMPCONF work. I was not sure this was relevant enough to send to the
DIFFSERV list so I have just sent it to the SNMPCONF list. Andrew, since
this is a response to questions you posed, if you feel this is useful on the
DIFFSERV list, feel free to forward it. If not, we can continue to discuss
it here since we have to resolve this issue for SNMPCONF anyway. I hope that
we can use the same approach across the two working groups.

Part of the problem as Andrew pointed out is that there are several
granularities of capability that are required for an effective system. From
my perspective, they are equivalent to the levels of abstraction that we
have been dealing with:

    Domain - Do I offer quality of service or secure communication

    Mechanism - Mechanisms are technologies used within a particular domain.
For example, in the differentiated services domain, RED or WRED (Weighted
Random Early Detection) might be used as one of the mechanisms that devices
employ to support differentiated services. It is helpful for a policy
management application to learn what mechanisms are supported on a
particular device. Not all possible mechanisms may be supported or enabled
in all implementations.

    Implementation specific details - These fall into two dimensions. The
first are restrictions on what the standards require. These restrictions
should be 'advertised' via the mechanism specific level. The second
dimension are extensions for mechanism that are not part of a standard.
These facilities would be 'advertised' via the implementation specific MIB
Module if present.

Note that I exclude from the expression of capability, restrictions of the
following type:

    - Does the device have the capacity to perform the work? This is
important but should be reported via a mechanism that is for that purpose in
our SNMP-based policy management system.

    - Anything related to conflict detection or resolution, including the
time dimension.

With this said, I think the problem has two parts. First: there is no
standardized way of learning this information from SNMP-based
instrumentation at this time. Agent capabilities is generally not available
as a set of run time objects.

The second part is that, unlike a lot of current network layer
auto-discovery code that uses the presence or absence of a particular base
OID to determine if something is supported, that level of granularity is not
sufficient for our task - see above. In any event that approach will not
work since some of the tables will not exist yet and thus there will be no
row entries - this is a problem for network layer discovery systems as well
but is not as problematic..

Additionally, there is a problem in that the capabilities might be limited
within an object. Take for example an enumerated integer that is supposed to
support 5 values, but in the particular agent implementation supports only

We have discussed a variety of techniques, none of them are completely
satisfactory yet. They include:

- Use of a default row in tables to learn the existence of the specific
object. Good but suffers from limitation of the sub object support described
above. For example, if the Differentiated Services Policy MIB Module were
running on a particular system, it would always have a reserved 1st row that
might even contain default values but not be associated with and instances.
This also has a nice side effect of having the mechanism specific desired
defaults and implementation specific defaults (e.g., for xyz vendor)

- Use of bit strings for listing restrictions. Interesting but probably not
likely to be well supported.

- Having managers read the agent capabilities and compliance and conformance
macros - after all that is what they are for. This is appealing but suffers
from the fact that most vendors are not always forthcoming in creating
accurate macros of this kind. The other defect in this approach in my view
is that is assumes the vendor has told the truth. Of course the agent could
always give a correct error message if a value were set to an object that
did not exist or was invalid for that object.

- The use of an extended capabilities table in the Policy MIB Module. This
table is quite simple in the current draft with just two objects:

PmCapabilitiesEntry ::= SEQUENCE {
    pmCapabilitiesIndex          Integer32,
    pmCapabilitiesType           OBJECT IDENTIFIER

I had always imagined that there would be a pmCapabilitiesSubType as well so
that is just a minor omission from the current table. I would re-do the
table as follows:

-- capabilities table
-- Note that with this table it is not necessary to list all OIDs that
-- a mechanism specific MIB Module supports, just the base OID if
-- the implementation is a fully compliant one. If the implementation
-- is not, then additional rows will exist in the table that list
-- the limitations or enhancements.

pmCapabilitiesTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF PmCapabilitiesEntry
    MAX-ACCESS  not-accessible
    STATUS      current
         "The pmCapabilitiesTable contains a description of
         the capabilities of the system. It also enumerates
    ::= { policyMgt 4 }

pmCapabilitiesEntry OBJECT-TYPE
    SYNTAX      PmCapabilitiesEntry
    MAX-ACCESS  not-accessible
    STATUS      current
         "The description of a capability or limitation of a
         capability of the system. An entry will exist for each
         domain and mechanism specific ability the system has. In
         the case of a domain specific capability with no mechanism
         specific parameters, the pmCapabilitiesSubType and all other
         columns may be null. Entries will exist that contain
         values for the pmCapabilitiesRestrictOID,
         pmCapabilitiesRestrictType, pmCapabilitiesRestrictValue
         and pmCapabilitiesRestrictString objects only when
         an implementation is reporting a mechanism specific
         restriction. Multiple entries are possible when more
         than one restriction for a type or subtype are needed."
    INDEX       { pmCapabilitiesIndex, pmCapabilitiesType }
    ::= { pmCapabilitiesTable 1 }

PmCapabilitiesEntry ::= SEQUENCE {
    pmCapabilitiesIndex          Integer32,
    pmCapabilitiesType           OBJECT IDENTIFIER,
    pmCapabilitiesSubType        OBJECT IDENTIFIER,
    pmCapabilitiesRestrictOID    OBJECT IDENTIFIER,
    pmCapabilitiesRestrictType   INTEGER,
    pmCapabilitiesRestrictValue  INTEGER,
    pmCapabilitiesRestrictString OCTET STRING

pmCapabilitiesIndex OBJECT-TYPE
    SYNTAX      Integer32 (1..65535)
    MAX-ACCESS  not-accessible
    STATUS      current
         "A unique index for this entry."
    ::= { pmCapabilitiesEntry 1 }

pmCapabilitiesType OBJECT-TYPE
    MAX-ACCESS  not-accessible
    STATUS      current
         "The type of the capability represented by this entry.
         The IANA will publish the list of identifiers that are valid
         values for this object."
    ::= { pmCapabilitiesEntry 2 }

pmCapabilitiesSubType OBJECT-TYPE
    MAX-ACCESS  read-only
    STATUS      current
         "The sub type of capability is a pointer to a mechanism specific
          set of capabilities supporting a base technology. In the case of
          DIFFSERV, the OID value here would be the base OID of the
          Differentiated Services Policy MIB Module."
    ::= { pmCapabilitiesEntry 3 }

pmCapabilitiesModificationOID OBJECT-TYPE
    MAX-ACCESS  read-only
    STATUS      current
         "The OID of the object that is either not supported, supported
         with one or more limitations, or expanded by an implementation
         specific module. If this columnar object is other than null then
         there must be at least an entry in pmCapabilitiesModificationType.
         Note that this need not be a leaf node or scalar object. If
         an entire table is not supported, this value can be the base OID
         for the table."
    ::= { pmCapabilitiesEntry 4 }

pmCapabilitiesModificationType OBJECT-TYPE
    MAX-ACCESS  read-only
    STATUS      current
         "An unsupported value indicates that the OID in
          pmCapabilitiesModificationOID is not supported on
          this system. A value of 1 indicates that the OID
          is supported but with restricted values
          These constraints are described in the
          pmCapabilitiesModificationValue and
          pmCapabilitiesModificationString objects. A value of
          2 indicates a vendor specific extension to a standard.
          The OID of the new object is pmCapabilitiesModificationOID.
          For some implementations, additional functions may be
          provided. addvalue indicates that this row of the table
          describes an additional value that the object can take.
          The specific value is in the pmCapabilitiesModificationValue.
          The values of 4 and 5 indicate restrictions or the removal
          of restrictions for the object identified."
    ::= { pmCapabilitiesEntry 5 }

pmCapabilitiesModificationValue OBJECT-TYPE
    MAX-ACCESS  read-only
    STATUS      current
         "If the value of pmCapabilitiesModificationType is 0, this
          object will be null since 0 indicates no support for the
          object at all. A value of 1 in the
          pmCapabilitiesModificationType will be further modified by a
          single integer value in this object that corresponds to
          enumerated integer values that are not supported by the
          system for the object that is identified in this row. This
          value can also represent the limit values in the
          pmCapabilitiesModificationType object."
    ::= { pmCapabilitiesEntry 6 }

pmCapabilitiesModificationString OBJECT-TYPE
    MAX-ACCESS  read-only
    STATUS      current
         "Any additional details or description or parameters needed.."
    ::= { pmCapabilitiesEntry 7 }

This table is not perfect but does give quite a lot of flexibility and does
not require very many objects. Implementations that are reasonably
conformant will also have tables with a fairly small number of rows. Even
when this is not the case, this will be read only very infrequently and is
indexed such that it is possible to retrieve reasonable sub portions of the
table. Not that I still think a 'default'/initial row for mechanism and
implementation specific modules may have some value.

on 06/13/2000 6:09 PM, Andrew Smith at andrew@extremenetworks.com wrote:

> Jon,
> There are several levels of granularity on which this could work:
> 1. Lowest as in "I support the diffServMeterTable", "I do not support the
> diffServAlgDropperTable".

I think the mods above support this.
> 2. Slightly higher as in "I support head droppers but not tail droppers"

Depends on the layout, but I think this would be handled.
> 3. Higher as in "I support head droppers that feed into strict-priority
> schedulers but not into WRR schedulers"

I doubt very much that this would be correctly dealt with in the objects I
wrote. At some point, humans will have to be involved. I would be happy to
say we can not deal with this type of condition and that the person writing
the 'rule' would have to take this into consideration. Of course this is not
an excuse for the agent not doing good error checking :-)
> There's also a "number of instances" dimension to it: "I support 3 strict
> priority scheduled queues per interface", "I support 3 strict priority OR 2
> WRR scheduled queues per interface but not both at the same time".

This in my view is a 'capacity' question. A valid one but dealt with
elsewhere. We have yet to have a full discussion on this topic, though I
look forward to it.
> There could also be an even more abstract notion of "I support AF but not
> EF" but that's somewhat different (since we don't have an AF or EF MIB -
> just one that hacks on the individual components that work together to
> provide AF or EF).

Since this is not a capability at this level. I am not sure how to deal with
this. Of course we could create mechanism specific objects for things like
this and they could be modified by this table.
> This could get quite fun ... but the more information like this that an
> agent can export, the easier will be the job of the manager and the more
> multi-vendor this whole config thing can become.

Agreed. Of course we have to also make it implementable - some people may
feel this table with the 7 objects is already to hard.  Others may feel it
does not go far enough.