This is only a rough draft - Megan 04/08/92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Multiplexing SNMP Agents BOF These are the minutes of the Multiplexing SNMP agent BOF held at the Spring 1992 IETF meeting in San Diego, California. The meeting was chaired by Karl Auerbach and minutes were taken by Ed Alcoff. The meeting began with a quick pair of slides restating the purpose of the BOF and a straw man proposal: ====================================================================== SLIDE 1 The purpose of this BOF is to determine: a) Whether SMUX or DPI are adequate. b) Whether the proxy capabilities in secure SNMP are adequate. c) If neither a) nor b) are adequate, why not? In other words, what sorts of functions do users think they need from a multiplexing SNMP agent? d) What sort of solutions might exist i) If the solutions are limited to the Unix operating system? ii) If the solutions are generalized to cover Unix and other environments? Goal: The goal of this BOF is to make an inquiry regarding the scope of the issue and the range of potential solutions. ====================================================================== ====================================================================== SLIDE 2 Straw man: To begin the discussion, here are some criteria I think might be appropriate for a multiplexing agent: 1. New MIB sub-trees may be attached *and* detached at any time. 2. Sub-trees may not be nested. In other words, an attached sub-tree may not have dynamically attached lower level sub-trees. 3. The master agent must not be required to have a priori knowledge of what is in the subtrees. (In other words, that agent ought to be able to accept any arbitrary subtree.) 4. Get-next must work across subtree boundaries. 6. Get-requests and Get-next requests must be allowed to have varBind entries which refer to elements in multiple subtrees. In other words, a single get/getnext ought to be able to fetch stuff in multiple sub-trees. 7. A set-request ought to be able to contain varBind entries which refer to elements in multiple subtrees. And the "as if simultaneous" requirement must be preserved across subtrees. This one we might want to debate. 8. The multiplexing scheme must be robust despite sub-agent failures. (I.e. a request ought not hang forever if a sub-agent is non-responsive.) 9. The multiplexing scheme need only support sub-agents on the same machine as the primary agent. 10. Multi-agent/multi-protocol capability: The multiplexing protocol ought to be designed so that a given subordinate agent could support multiple superior agents. In addition, the protocol ought to be rich enough that those superior agents aren't just SNMP agents. ====================================================================== DISCUSSION: The BOF started with discussion of the "10" points listed on slide #2. 1. No one strongly disputed the need for dynamic growth or contraction of the MIB tree. 2. It was pointed out that one may want to have different instances of a variable or group "owned" by a different sub-agents. For example, each row of a table may be provided by a separate sub-agent rather than having the entire table provided by a single sub-agent. This appears to be a useful point of view. It is, however, significantly at odds with previous thinking in which all instances of any given variable would be "owned" by a single sub-agent. 3. A model was proposed in which there would be multiple, independent sub-agents rather than a single master multiplexing SNMP agent. In this new model, each agent would emit a start-up trap announcing its service address. A management station would then address independent SNMP queries to the appropriate agent. 4. Problem with both SMUX & DPI was noted: Because of the uncoordinated activities of the various sub-agents, the correlation of sysUpTime with sub-agent derived information may be weak and may vary unpredictably. It may be difficult, if not impossible, to provide a useful correlation between time stamps (such as sysUpTime) and readings of management variables. 5. A concern was raised whether effective network management requires that a management station be able to issue an SNMP varBindList which has items spanning MIB subtrees owned by separate sub-agents. One participant asked whether this was a non-issue. In particular, does it really matter whether a query is split among agents (or sub-agents) by the SNMP manager station itself or by a master agent? In further discussion, it was suggested that since the agent is "closer" to the sub-agents it is in a better position to know how to best partition queries. Partitioning by the agent also has the advantage that get-next semantics can be preserved even where the next lexiographic item lies across a sub-agent boundary. Another participant commented that whenever a MIB is partitioned among sub-agents, it is necessary to replicate at least the System group in each partition. Thus it would be possible to retrieve timestamps which are correlated with the data values. A question was raised whether the sysUpTime value of the various partitions need to be synchronized. A well known pragmatist answered that on most hosts, it is quite easy to keep the various instances of sysUpTime fairly well synchronized. This left unanswered the question whether such synchronization is needed when the sub-agents reside on separate processors. 6. Looking to practice, do people actually issue queries which deal with logically separate information bases (each of which presumably would be handled by a separate sub-agent)? On one hand would one ever realistically want to ask about routing tables and sendmail in the same SNMP query? Probably not. On the other hand, one could conceive of a query which tried to correlate network traffic load with changes in routing topology. And it is not unreasonable to believe that load measurement and routing topology would be maintained in separate sub-agents. It was pointed out that many SNMP managers do not recognize the notion that a single managed device may contain multiple SNMP entities. Consequently, many managers today present such devices on the user interface as if they were multiple, separate devices. 7. It was asked to what extent existing multiplexed SNMP agents enforce the "as if simultaneous" atomic requirements of SNMP Set-Requests. It appears that a significant number of existing multiplexed agents do not make this guarantee. This has not, to date, appeared to have caused any operational difficulties. However, this may be the result of simplistic user interfaces which limit set-requests to one value, proprietary MIBs which are designed so as to avoid the need for atomic "sets", or to adolescent tools which do not yet push Set-Requests very hard. 8. There was discussion regarding the implementation burden on sub-agent writers. At a minimum, there was a desire to avoid encoding and decoding ASN.1/BER. Alternatives suggested were XDR or simplified BER. If the agent-sub-agent interface did not cross machine boundaries then one could even use internal, host specific data formats. Some people wanted to go further and isolate sub-agents from the issues of object naming, object instancing, and lexiographic ordering. It was hoped that the agent-to-sub-agent interface could be hidden behind a clean programming API. There was no consensus, however, whether this is feasible unless done in the context of a specific operating system. 9. DEC, HP, IBM, and Peer Networks quickly described their own methods of dealing with some or all of the issues. 10. Marshall Rose described a means using the Secure SNMP protocols and MIB to partition the management variable space among multiple sub-agents. Each "party" would be mapped to a separate sub-agent. It was pointed out that this is really a variation of the "completely disjoint agent" method #3, above. SUMMARY: There is strong interest in multiplexing SNMP agents. A number of multiplexing agents or extensible agents have been constructed. And various attendees have built multi-protocol agents and managers. The requirements are not yet well understood. In particular, a significant number of attendees were of the opinion that it is not necessary to preserve full SNMP query semantics across sub-agent boundaries or that it is acceptable for an agent to fail to honor the "as it simultaneous" and atomic properties of SET requests. Using the proxy facility of the forthcoming secure SNMP would easily and directly provide a means to divide MIBs among separate sub-agents. But it would require that a management station be aware of the MIB partions.