1 / 7

Efficient Subtree Retrieval Mechanism for SNMP Agents

This document proposes an approach for efficient subtree retrieval in SNMP agents to address issues such as latency and bulk retrievals. It introduces a mechanism using a single request message and multiple response messages, making it easier to track dropped ranges. The method involves using traps for responses and allows for halting operations if needed, without altering the SNMP protocol. Limitations and implementation details are discussed.

hilel-mccarty
Download Presentation

Efficient Subtree Retrieval Mechanism for SNMP Agents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Subtree Retrieval MIBdraft-irtf-nmrg-get-subtree-mib-00.txthttp://www.eecs.umich.edu/~thalerd/subtree.txt Dave Thaler dthaler@microsoft.com

  2. Problem: • Bulk subtree(s) retrieval • "Overshoot" by guessing max-repetitions too large • Or issue sequential requests (larger time window of missing changes, more pkts on wire, etc) • Latency • etc

  3. Goals: • Goals in common with new-PDU approach: • single "request" message • multiple "response" messages, as large as possible • make it easy to know what ranges, if any, got dropped (if over udp) • allow halting operation in progress (e.g. oid typo) • Goals in common with FTP approach: • No changes to existing SNMP protocol • No changes to some master agents (see Limitations slide later on)

  4. Mechanism: • "request" is a set (row creations) in a new MIB • "responses" are traps: • response destination must be a legal notification target in SNMP-TARGET-MIB • conceptual row deleted automatically when done • can cancel operation via row deletion SetRequest Response Trap Trap . . . Trap

  5. Limitations: • Application must be allowed to issue SETs to this MIB • Command responder/notification originator tightly coupled • Command generator/notification responder tightly coupled • Subagent implementing MIB must be able to call back into the SNMP agent to walk other MIBs, without causing a deadlock

  6. Trap contains: • Read-only objects in “request” row created: • seqno (to detect losses) • "done" flag • Bunch of varbinds requested • Encoding optimizations possible (same as with other approaches), but not discussed in this document • App stops waiting for traps when gets “done” and has all seqno’s, or after timeout.

  7. TODO • Need to update to get multiple subtrees in parallel • Initial version didn’t include this just to give the general idea • Implementation • Co-author(s)?

More Related