SNMP Agent Extensibility (agentx)
Working Group of the 34th IETF
December 6 and 8, 1995
Session 1:
Wednesday, December 6, 1995, 1300-1500
- Introduction and Review of the Charter
The chair will present the working group's charter and provide a
history of IETF discussion and publication in this area.
- Presentations by Interested Parties
All participants are invited to make prepared, or impromptu,
presentations to the working group.
(singing afterwards, optional)
- Group Discussion of Presentations
Questions of a clarifying nature may be asked during each individual
presentation;
however,
all other questions should be held until all presentations are heard.
At that time,
questions and discussions on all presentations and topics will be held.
Session 2:
Friday, December 8, 1995, 0900-1130
- Group Discussion of Presentations (continued)
- Review of Problems and Approaches
In real-time,
the group will attempt to derive a taxonomy of the problems,
approaches,
and experiences presented and discussed.
- Group Discussion on How to Proceed in a timely fashion
Introduction
Review of the Charter
The goal of this working group is to define standards-track technology
for SNMP Agent extensibility. The resulting technology specification
will allow independently developed sub-agents to communicate with a
master-agent running on an Internet device.
The technology specification will consist of:
- (mandatory) a platform-independent protocol which supports
intra-agent communication within a device or local area network;
- (optional) a MIB module, which, when implemented by a master-agent,
allows an SNMP-based management application to monitor and control
the intra-agent communication service; and,
- (optional) a programmatic interface to the services offered by
that protocol.
Review of the Charter (cont.)
The working group is explicitly directed to develop a solution which is
adequate to achieve transparency with respect to whether a SNMP request
is processed by a master-agent and/or one or more sub-agents;
simultaneously, the working group is further directed to use good
engineering judgement is developing an approach with the smallest
reasonable "footprint" to achieve intra-agent communication. As a
consequence, the working group may choose to avoid complete
transparency, if, at its discretion, this proves too costly. In this
case, the working group should document its decision for this
engineering trade-off.
Although the working group will solicit existing specifications and
experience in this area, it will produce a vendor-neutral technology
specification.
Review of the Charter (cont.)
- Goals and Milestones:
- 12/95: First meeting
- 12/95: First pass at I-Ds
- 01/96: Second pass at I-Ds
- 03/96: Second meeting
- 04/96: Final pass at I-Ds
- 05/96: Submit I-Ds to IESG
The Multiple Component Problem
- The traditional agent has several functions, including:
- receive requests;
- apply administrative policies;
- access instrumentation;
- generate responses; and,
- generate notifications
- Sometimes the object resources are implemented in
multiple components
- There are two deployment strategies for such environments
[gif image]
The Packet-Multiplexing Approach
- Require that each component have its own agent,
- Decide whether the manager should talk:
- directly to the proxy-target; or,
- indirectly to the proxy-target, via a proxy-agent
- Choice depends on addressing capabilities of manager,
- directly: use different port, selector irrelevant
- indirectly: use port 161, but use a different selector
- With the "direct" choice,
- each component is its own managed system; and,
- there is no relationship between components
so, there is no multiple component problem
- Hence, only the "indirect" choice is interesting
[gif image]
Strategy for Proxy-Multiplexing
- The proxy-agent and each proxy-target contains their own separate
- The proxy-agent contains:
- information on managers and proxy-targets; and,
- (usually) minimal object resources
- Each proxy-target contains:
- information on its own proxy-agent; and,
- extensive object resources in a single MIB view
Agreements for Proxy-Multiplexing
- Platform-Independent Configuration:
- identity of a proxy-target;
- textual description of a proxy-target
- mapping a selector to a proxy-target; and,
- how the proxy-agent communicates with a proxy-target
- The proxy-agent may have local objects to support discovery
- How configuration information is shared between
- the proxy-agent and its proxy-targets
is in the realm of platform-dependent agreements
Example Agreements
- An example Platform-Independent Agreement:
- SNMPv2 contexts identify proxy-targets;
- SNMPv1 used to communicate with proxy-targets; and,
- community strings are unpredictable
- An example Platform-Dependent Agreement (for UNIX):
- use /etc/inet/proxy.conf to read configuration; and,
- exchange SNMPv1 messages via shared-memory
- (maybe) C API for proxy-target developers
The Variable-Multiplexing Approach
- The master agent must have some knowledge about object resources
- in a sub-agent, at some level of granularity
- Manager talks to the master-agent,
- which accesses instrumentation in various components
- A single SNMP operation might involve multiple components
[gif image]
Strategy for Variable-Multiplexing
- The master-agent and all components share the system objects,
- but the master-agent contains the snmp objects
- The master-agent contains:
- information on managers and components; and,
- (usually) minimal object resources
- Each component contains:
- information on its own master-agent; and,
- object resources in a (partial) MIB view
Agreements for Variable-Multiplexing
- Platform-Independent Configuration:
- how components register their object resources;
- how the master-agent communicates which a component; and,
- how component instrumentation interacts
- The master-agent has local objects to support discovery
- e.g., sysORTable or the Entity MIB, etc.
(the granularity and distribution of this knowledge is an issue)
- Configuration is essentially dynamic
Example Agreements
- An example Platform-Independent Agreement
- special-purpose protocol for intra-agent communications
- An example Platform-Dependent Agreement (for UNIX):
- exchange PDUs messages via shared-memory; and,
- (maybe) C API for component developers
Observations
- Considerable similarity between the two approaches,
- e.g., one could design an single API for both approaches,
- and, at start-up, the API library decides which to use
- Issues seem to focus on component transparency to manager
- If so, master-agent must emulate MIB view semantics, e.g.,
- counters and sysUpTime,
- "as if simultaneous" sets, and so on
- If not, manager must relate
- multiple views of the same managed system
IETF Publications
Presentations By Interested Parties
All participants are invited to make prepared, or impromptu,
presentations to the working group, answering these three questions:
- what are the issues which are driving agent extensibility?
- what technologies exist which address these issues?
- what are the real-world experiences with these technologies?
By convention, participants with prepared presentations will present
first.
Questions of a clarifying nature may be asked during each individual
presentation;
however,
all other questions should be held until all presentations are heard.
At that time,
questions and discussions on all presentations and topics will be held.
Group Discussion of Presentations
Review of Problems and Approaches
In real-time,
the group will attempt to derive a taxonomy of the problems,
approaches,
and experiences presented and discussed.
Group Discussion on
How to Proceed in a Timely Fashion