Delivery-Date: Mon, 08 Jul 1996 05:37:02 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id FAA04790 for X-agentx-local; Mon, 8 Jul 1996 05:37:02 -0700 (PDT) Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by fv.com (8.7.4/8.7.3) with SMTP id FAA04753 for ; Mon, 8 Jul 1996 05:37:01 -0700 (PDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ad13390; 8 Jul 96 13:37 +0100 Received: from farpoint.demon.co.uk ([158.152.19.97]) by relay-3.mail.demon.net id aa06404; 8 Jul 96 13:36 +0100 Received: from farpoint (193.115.8.5) by farpoint.demon.co.uk (EMWAC SMTPRS 0.60) with SMTP id ; Mon, 08 Jul 1996 13:25:07 +0100 Message-Id: <1.5.4.32.19960708122507.002c3310@farpoint.demon.co.uk> X-Sender: pete@farpoint.demon.co.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 08 Jul 1996 13:25:07 +0100 To: agentx@fv.com MMDF-Warning: Parse error in original version of preceding line at relay-3.mail.demon.net From: Pete Lynch Subject: subscribe   Delivery-Date: Mon, 08 Jul 1996 23:34:39 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id XAA26522 for X-agentx-local; Mon, 8 Jul 1996 23:34:38 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by fv.com (8.7.4/8.7.3) with SMTP id XAA26500 for ; Mon, 8 Jul 1996 23:34:33 -0700 (PDT) Received: from citrus.citr.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP); Tue, 9 Jul 1996 16:34:10 +1000 Received: from citron.citr.uq.oz.au by citrus.citr.uq.oz.au (8.7.3/CiTR-External-Gateway) ; id ; Tue, 9 Jul 1996 16:33:19 +1000 (EST) Received: from mango by citron.citr.uq.oz.au (8.7.3/CiTR-Main) ; id ; Tue, 9 Jul 1996 16:34:05 +1000 (EST) Received: from localhost by mango (5.65/CiTR-Client) ; id ; Tue, 9 Jul 1996 16:34:05 +1000 Message-Id: <6456.9607090634@mango> To: agentx@fv.com Subject: re: draft-ietf-agentx-ext-pro-01.txt (unpaginated version) Date: Tue, 09 Jul 96 16:33:58 +1000 From: David Horton X-Mts: smtp (1) in 5.2 Value Representations Should there be a type for IPv6 addresses? Do we want NsapAddress as a type, or a more generalised Network address e.g. to support the needs of the NHRP-MIB which has to potentially deal with a generalised network address? (2) section 7.2.1 SETS I presume that some form of set command is dispatched 'in-parallel' to all the sub-agents registered for the OID range corresponding to the SNMP attribute set. I would hope to see some sequence of additional messages between the subagent and master e.g. MA->all SAs SET-register-interest SA->MA SET-Vote MA->one SA SET-Selected SA->MA SET-result Further I presume this has to go on in 'parallel' for the potentially multiple attributes in the particular SNMP packet from the management station. In making the voting/selection, there needs to be some form of weighting given to a subagent if it can handle some of the request, rather than load spread. e.g. if multiple subagents are supporting multiple interfaces, and they could all individually perform the task, then you wouldn't want one attribute to be set on I/F=1 and another on I/F=2 relating back to the one set request. (3) Customer Network Management capability I can envisage a system that is providing a CNM front end in addition to local management. In this case the smarts for selection of instances is most logically done in the CNM specific subagent, rather than trying to force all the capability into the master agent. I would like to have the ability for the subagent to have access to various information in the original SNMP request, e.g. IP address, community name. Perhaps these don't need to be passed on every request, but a message and reply from the SA to MA based on a particular request handle to acquire the information from the master. (4) Are there any MIB groups defined to be supported by the master agent e.g. system, snmp, party-mib etc (5) Interactions between sub-agents I have a couple of cases where it is desirable for sub-agents to interact and was hoping some thought could be given making this easier. Case (a) Multiple layers of software dependent on each other Case (b) Multiple subagents supporting different physical devices and a 'coordinating' or 'cross-device' MIB Case (a) Multiple layers of software dependent on each other Specifically NHRP or something like it IP Route <-------> NHRP ++ IfStack ++ \ | NhrpI/F AAL mgmt | AAL5 I/F \ ATM mgmt ATM I/F | OC3 I/F Physical layer (e.g. OC3) Here there may be data that comes from one subagent that is needed by a subagent that is layered upon it. The simplest case is the ifStack table. Case (b) Multiple subagents supporting different physical devices and a 'coordinating' or 'cross-device' MIB Specifically an AToMMIB cross connection and/or physical topology manager +++++++++++ Master +++++++++++ / / \ \ Topology manager ATM Cross Connect \ / \ / Switch-1-SA Switch-2-SA Here the topology and crossconnect subagents need to coordinate and correlate information from multiple switches under their domain. The topology manager may have to match up neighbour information from the physical switches to determine the ATM physical connectivity. The cross connect manager may have to match up virtual channel identifiers leading out of interfaces on the switches, and in conjunction with the physical topology manager determine which of these form a permanent virtual circuit across the managed ATM network domain. It may also have to configure tables in these physical switch agents, e.g. a SET request on the cross connect object may require a cascade of sets on the individual physical switch agents to acomplish the cross connection creation. (6) Rejection of registration request I like the idea of being able to try to register a OID instance, and have the master reject the registration because it is already in use. This way I can write sub-agents as part of some server (say multiple ftamd) which don't have to have a separate protocol to determine whether there is another one running, just in order to get a 'unique' slot in a table. i.e. this uses the master agent as an allocator of IDs. regards, David David Horton Centre for Information Technology Research Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064 Email: d.horton@citr.uq.oz.au Phone +61 7 32592222 Fax +61 7 32592259   Delivery-Date: Tue, 09 Jul 1996 07:52:26 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA22952 for X-agentx-local; Tue, 9 Jul 1996 07:52:26 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA22946 for ; Tue, 9 Jul 1996 07:52:24 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA07248; Tue, 9 Jul 1996 10:31:45 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA14967; Tue, 9 Jul 1996 10:31:44 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA29593; Tue, 9 Jul 1996 10:33:09 -0400 Message-Id: <9607091433.AA29593@bernie.zk3.dec.com> To: agentx@fv.com Subject: re: draft-ietf-agentx-ext-pro-01.txt (unpaginated version) Date: Tue, 09 Jul 96 10:33:08 -0400 From: Mike Daniele X-Mts: smtp >To: agentx@fv.com >Subject: re: draft-ietf-agentx-ext-pro-01.txt (unpaginated version) >Date: Tue, 09 Jul 96 16:33:58 +1000 >From: David Horton >X-Suppressed-X-Mts: smtp Hi David, >(1) in 5.2 Value Representations >Should there be a type for IPv6 addresses? >Do we want NsapAddress as a type, or a more generalised Network address >e.g. to support the needs of the NHRP-MIB which has to potentially >deal with a generalised network address? Agentx is limited to the SNMP SMI, which defines only a 4-octet IP address type. I'm not familiar with NHRP, but would assume IPv6 addresses or generalized network addresses would be defined as textual convention whose syntax is OCTET STRING SIZE (0..(2) section 7.2.1 SETS >I presume that some form of set command is dispatched 'in-parallel' to >all the sub-agents registered for the OID range corresponding to the >SNMP attribute set. I would hope to see some sequence of additional >messages between the subagent and master e.g. > MA->all SAs SET-register-interest > SA->MA SET-Vote > MA->one SA SET-Selected > SA->MA SET-result >Further I presume this has to go on in 'parallel' for the potentially >multiple attributes in the particular SNMP packet from the management >station. In making the voting/selection, there needs to be some form >of weighting given to a subagent if it can handle some of the >request, rather than load spread. e.g. if multiple subagents are >supporting multiple interfaces, and they could all individually >perform the task, then you wouldn't want one attribute to be set >on I/F=1 and another on I/F=2 relating back to the one set request. This touches on many points missing from the current draft. We have planned on providing "index reservation", whereby a subagent can reserve unused indexes for specific "tables", and then register specific rows in those tables. This handles the case of tables with instances that aren't very dynamic, and it makes sense for subagents to register individual rows. Other MIB tables might not lend themselves to this mechanism. At the Montreal IETF this was raised as an issue. In general, the aim is for a variable binding to be dispatched (initially) to only 1 subagent. On Next/Bulk if that subagent returns endofmibview other subagents need to be queried. Permitting variable bindings to be initially dispatched to multiple subagents is generally thought to be required only in (fairly uncommon) cases where multiple subagents share a table where it is not practical for them to register distinct rows or blocks of rows within that table. In this case the master agent chooses the "best" response. Randy Presuhn will be posting some ideas on this specific topic to this list. Soon :-) All of this will be documented in the next version of the (admittedly very incomplete) draft. >(3) Customer Network Management capability >I can envisage a system that is providing a CNM front end in addition >to local management. In this case the smarts for selection of instances >is most logically done in the CNM specific subagent, rather than >trying to force all the capability into the master agent. The agentx master agent knows nothing (well, very little) of instances. (Or were you referring to your CNM master agent?) >I would like to have the ability for the subagent to have access to >various information in the original SNMP request, e.g. IP address, >community name. >Perhaps these don't need to be passed on every request, but a message >and reply from the SA to MA based on a particular request handle to >acquire the information from the master. Up to now we've considered that beyond our scope. If handled that way (separate PDUs to send that information) it would be easy to extend compliant Agentx peers to handle this. >(4) Are there any MIB groups defined to be supported by the master agent >e.g. system, snmp, party-mib etc Yes, the draft states the master agent must - Provides instrumentation for the MIB objects defined in [5], and for any MIB objects relevant to any administrative framework it supports. where [5] is RFC 1907. How that's done is implementation-specific since it's beyond what we're trying to define as the master agent "processing entity". >(5) Interactions between sub-agents >I have a couple of cases where it is desirable for sub-agents to interact >and was hoping some thought could be given making this easier. >Case (a) Multiple layers of software dependent on each other >Case (b) Multiple subagents supporting different physical devices > and a 'coordinating' or 'cross-device' MIB AgentX will provide o index reservation, o a general-purpose mechanism for registering MIB regions (which can be entire MIBs or individual fully qualified instances or anywhere in between). o a documented procedure for handling registrations and dispatching to subagents so for instance, a 'coordinating' subagent might register a table's oid, do index reservation, and start other subagents "on" specific rows of a table. If you can't design a solution based on these mechanisms then you'll have to go beyond AgentX. One way might be to use SNMP itself to query the master agent and find out What's On This System. I think it's more likely that for very low-level synchronization subagents will look to underlying primitive data (routing tables, etc). >(6) Rejection of registration request >I like the idea of being able to try to register a OID instance, and have >the master reject the registration because it is already in use. >This way I can write sub-agents as part of some server (say multiple ftamd) >which don't have to have a separate protocol to determine whether there is >another one running, just in order to get a 'unique' slot in a table. >i.e. this uses the master agent as an allocator of IDs. I think Randy's posting will address this. The daemons could also use index reservation to obtain unique slots. Thank you for your suggestions/comments. Regards, Mike   Delivery-Date: Tue, 09 Jul 1996 12:09:02 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA18649 for X-agentx-local; Tue, 9 Jul 1996 12:09:01 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id MAA18600 for ; Tue, 9 Jul 1996 12:08:53 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA32002; Tue, 9 Jul 1996 14:55:06 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA24019; Tue, 9 Jul 1996 14:55:05 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA29734; Tue, 9 Jul 1996 14:56:33 -0400 Message-Id: <9607091856.AA29734@bernie.zk3.dec.com> To: agentx@fv.com Subject: binary oid syntax Date: Tue, 09 Jul 96 14:56:30 -0400 From: Mike Daniele X-Mts: smtp At Montreal we decided on a binary syntax for object identifiers. We also currently define a RangeSpecifier as an object identifier which may define 1 sub-identifier as a range (1.2.3.[20-30].5.6). Given that restriction, we could define a single construct, something like this... RangeSpecifier: byte 1 byte 2 byte 3 byte 4 +---------+---------+--------+--------+ | n_subid | r_subid | 0 | prefix | +---------+---------+--------+--------+ | sub-id #1 (32 bits, net byte order) | +-------------------------------------+ ... +-------------------------------------+ | sub-id #n_subid | +-------------------------------------+ | range upper bound (optional) | +-------------------------------------+ n_subid - the number (1-128) of sub-ids in the RangeSpecifier. an ordered list of `n_subid' 32 bit sub-ids follows the 32-bit "header". r_subid - the index (0-128) of the single sub-id which is actually a range. A value of 0 indicates there is no range sub-id. A non-zero value indicates that `r_subid'-th sub-id is the lower bound of a range, and that an extra sub-id defining its upper bound follows the ordered list of `n_subid' sub-ids. prefix - a value (0-4) used for optimizing the transfer of object identifiers. a value of 1-4 indicates a branch below `internet' (1.3.6.1), and that this branch is a prefix to the actual sub-id's contained in the RangeSpecifier. A value of 0 indicates there is no prefix to the sub-ids. Note that n_subid and r_subid are always defined with respect to the sub-ids contained in the RangeSpecifier, regardless of the value of this field. ObjectIdentifier: A RangeSpecifier with r_subid == 0. Examples: sysDescr.0 (1.3.6.1.2.1.1.1.0) +--------+---------+--------+--------+ | 4 | 0 | 0 | 2 | +--------+---------+--------+--------+ | 1 | +------------------------------------+ | 1 | +------------------------------------+ | 1 | +------------------------------------+ | 0 | +------------------------------------+ row 7 of RFC 1573 ifTable (1.3.6.1.2.1.2.2.1.[1-22].7) +--------+---------+--------+--------+ | 6 | 5 | 0 | 2 | +--------+---------+--------+--------+ | 1 | +------------------------------------+ | 2 | +------------------------------------+ | 2 | +------------------------------------+ | 1 | +------------------------------------+ | 1 | +------------------------------------+ | 7 | +------------------------------------+ | 22 | +------------------------------------+ A martian (9.9.9.9.9.9.9) +--------+---------+--------+--------+ | 7 | 0 | 0 | 0 | +--------+---------+--------+--------+ | 9 | +------------------------------------+ | 9 | +------------------------------------+ | 9 | +------------------------------------+ | 9 | +------------------------------------+ | 9 | +------------------------------------+ | 9 | +------------------------------------+ | 9 | +------------------------------------+ Usage: Recall that RangeSpecifiers are used in all request PDUs (g.start, g.end) and response PDUs (v.name), as well as the (UN)REGISTER PDUs. I believe we should specify that r_subid must be 0 in all PDUs except (UN)REGISTER. that is, ranges are only permissable during registration processing. Or rather, we define those fields as ObjectIdentifiers not RangeSpecifiers. Comments: Since oids are so common it seems reasonable to me to try to optimize their binary representation (via the prefix field or something like it). This represents a savings of 5 integers per oid. For GetNext and GetBulk, each SearchRange contains 2 oids, so we'd save 10 integers or 40 bytes per requested oid. A response to a GetBulk might contain 20 varbinds, and this would save 400 bytes. You get the picture ... Perhaps a better use of this field might be 0 - means there is no prefix 1 - means the prefix is `mib-2' 2 - means the prefix is `enterprise' 3 - means the prefix is `experimental' since mib-2 and enterprise are probably the prefix for the vast majority of objects, and this would save 6 integers per oid. Comments please. Mike   Delivery-Date: Tue, 09 Jul 1996 14:40:34 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA23146 for X-agentx-local; Tue, 9 Jul 1996 14:40:33 -0700 (PDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by fv.com (8.7.4/8.7.3) with SMTP id OAA23133 for ; Tue, 9 Jul 1996 14:40:31 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id XAA08549; Tue, 9 Jul 1996 23:33:43 +0200 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id XAA08759; Tue, 9 Jul 1996 23:33:41 +0200 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id XAA06514; Tue, 9 Jul 1996 23:33:40 +0200 Date: Tue, 9 Jul 1996 23:33:40 +0200 Message-Id: <199607092133.XAA06514@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: agentx@fv.com In-reply-to: <9607091856.AA29734@bernie.zk3.dec.com> (message from Mike Daniele on Tue, 09 Jul 96 14:56:30 -0400) Subject: Re: binary oid syntax Mike Daniele wrote: > At Montreal we decided on a binary syntax for object identifiers. > > We also currently define a RangeSpecifier as an object identifier > which may define 1 sub-identifier as a range (1.2.3.[20-30].5.6). > > Given that restriction, we could define a single construct, > something like this... [... RangeSpecifier description removed ...] Here are the hex values of your examples in your proposed encoding (labeled MD) and in normal BER encoding. I have encoded a range by simply encoding two object identifier in BER. (Please correct me if I got something wrong.): sysDescr.0: 0x0400000200000001000000010000000100000000 (Mike) 0x2b06010201010100 (BER) 9.9.9.9.9.9.9: 0x0700000000000009000000090000000900000009000000090000000900000009 (Mike) 0x710909090909 (BER) 1.3.6.1.2.1.2.2.1.[1-22].7: 0x0605000200000001000000020000000200000001000000010000000700000026 (Mike) 0x2b060102010202010107 1.3.6.1.2.1.2.2.1.1.7 (BER) 0x2b060102010202011607 1.3.6.1.2.1.2.2.1.22.7 (BER) Note that you do not save a single byte in these examples because most sub-identifier can be packed into a single BER byte. Your scheme always uses 4 bytes for a sub-identifier which is easy and fast to process but very expensive in the number of bytes. Your scheme becomes a bit more efficient if you have large sub-identifier which I think is not the common case. (Correct me if I am wrong.) > I believe we should specify that r_subid must be 0 in all PDUs except > (UN)REGISTER. that is, ranges are only permissable during registration > processing. Or rather, we define those fields as ObjectIdentifiers not > RangeSpecifiers. Allowing range specifiers only in (UN)REGISTER PDUs makes the need for an efficient encoding less important. Even two object identifier in BER encoding might be efficient here. > Since oids are so common it seems reasonable to me to try to optimize > their binary representation (via the prefix field or something like it). > This represents a savings of 5 integers per oid. > For GetNext and GetBulk, each SearchRange contains 2 oids, so we'd save 10 > integers or 40 bytes per requested oid. > A response to a GetBulk might contain 20 varbinds, and this would > save 400 bytes. You get the picture ... While I agree that optimizing oid representation makes some sense, I am not yet convinced that your proposed scheme does a good job in the general case. The trade-off here is the code needed to create and parse a compact representation versus the number of bytes exchanged. Do we care about the number of bytes on the wire (which wire?) or do we care about the processing overhead of encoding/decoding BER values? Juergen   Delivery-Date: Tue, 09 Jul 1996 15:42:57 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA07010 for X-agentx-local; Tue, 9 Jul 1996 15:42:56 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by fv.com (8.7.4/8.7.3) with ESMTP id PAA07006 for ; Tue, 9 Jul 1996 15:42:55 -0700 (PDT) Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id SAA11046; Tue, 9 Jul 1996 18:43:22 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA25867; Tue, 9 Jul 1996 18:42:56 -0400 From: Uri Blumenthal Message-Id: <9607092242.AA25867@hawpub.watson.ibm.com> Subject: Re: binary oid syntax To: schoenw@cs.utwente.nl (Juergen Schoenwaelder) Date: Tue, 9 Jul 1996 18:42:55 -0400 (EDT) Cc: agentx@fv.com In-Reply-To: <199607092133.XAA06514@atlas.cs.utwente.nl> from "Juergen Schoenwaelder" at Jul 9, 96 11:33:40 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Juergen Schoenwaelder says: > Here are the hex values of your examples in your proposed encoding > (labeled MD) and in normal BER encoding. I have encoded a range by > simply encoding two object identifier in BER. (Please correct me if I > got something wrong.): > sysDescr.0: > > 0x0400000200000001000000010000000100000000 (Mike) > 0x2b06010201010100 (BER) Yes, BER in this case is more compact. However, I suggest that in the most likely case, the bandwidth between the master agent and the sub isn't a constrain, while CPU cycles are. In short, you can't beat the performance of addressing 4-byte integers directly, also you've relieved from the need to figure out whether one byte is enough to store *this* particular OID or not. When binary representation for OIDs was proposed at Montreal, we all knew well enough, that for many OIDs this will mean more space. I think it's obvious, that performance gain is sufficient to justify the space loss. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Wed, 10 Jul 1996 08:38:41 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA21875 for X-agentx-local; Wed, 10 Jul 1996 08:38:41 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id IAA21868 for ; Wed, 10 Jul 1996 08:38:39 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA26227; Wed, 10 Jul 1996 11:31:40 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA02021; Wed, 10 Jul 1996 11:31:29 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA30077; Wed, 10 Jul 1996 11:32:49 -0400 Message-Id: <9607101532.AA30077@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: binary oid syntax In-Reply-To: Your message of "Tue, 09 Jul 96 23:33:40 +0200." <199607092133.XAA06514@atlas.cs.utwente.nl> Date: Wed, 10 Jul 96 11:32:48 -0400 From: Mike Daniele X-Mts: smtp Hi Juergen, >Note that you do not save a single byte in these examples because most >sub-identifier can be packed into a single BER byte. BER is certainly more space-efficient, but a decision was made some time ago not to use BER for AgentX. >Do we care about the number of bytes on the wire (which wire?) or do >we care about the processing overhead of encoding/decoding BER values? The existing solutions typically don't use BER, so in effect trade off space for a more simple encoding/decoding scheme. This space consumption when not using BER is most pronounced with oids, so it seems like a good candidate for some sort of simple optimization. Regards, Mike   Delivery-Date: Thu, 11 Jul 1996 07:51:25 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA29278 for X-agentx-local; Thu, 11 Jul 1996 07:51:24 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA29272 for ; Thu, 11 Jul 1996 07:51:19 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA06653; Thu, 11 Jul 1996 10:36:57 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA25898; Thu, 11 Jul 1996 10:36:55 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA30526; Thu, 11 Jul 1996 10:38:21 -0400 Message-Id: <9607111438.AA30526@bernie.zk3.dec.com> To: agentx@fv.com Subject: Alignment, and PDU diagrams Date: Thu, 11 Jul 96 10:38:20 -0400 From: Mike Daniele X-Mts: smtp Uri wrote: > ... In short, you can't beat the performance of addressing 4-byte >integers directly, ... In order to assure all platforms can do that, 4-byte integers need to be naturally aligned in memory. To ensure that can happen, we need to specify the PDUs and various encoding methods so that 4-byte ints are at multiple-of-4 offsets. I've started to reorganize the PDU layouts to do so (using a binary representation for oids). Seems pretty striaghtforward, varbinds in the response may need padding... Anyway, one of the things I'm finding is the current format for describing PDUs is hard to read (at least for me). I know we were supposed to "start with DPI", but what do folks think about adopting a more typical format? Instead of Object Identifier: +--------+------+--------------------------------------------+ | OFFSET | SIZE | FIELD | +--------+------+--------------------------------------------+ | X | 1 | n_subid | +--------+------+--------------------------------------------+ | X+1 | 1 | r_subid | +--------+------+--------------------------------------------+ | X+2 | 1 | include | +--------+------+--------------------------------------------+ | X+3 | 1 | prefix | +--------+------+--------------------------------------------+ | X+4 | 4 | sub-identifier #1 | +--------+------+--------------------------------------------+ ... +--------------+------+--------------------------------------+ | X+(4*n_subid)| 4 | sub-identifier #n_subid | +--------------+------+--------------------------------------+ something like byte 1 byte 2 byte 3 byte 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | r_subid | include | prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mike   Delivery-Date: Thu, 11 Jul 1996 22:02:14 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id WAA24418 for X-agentx-local; Thu, 11 Jul 1996 22:02:13 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id WAA24414 for ; Thu, 11 Jul 1996 22:02:12 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id AAA08581; Fri, 12 Jul 1996 00:55:31 -0400 Date: Fri, 12 Jul 1996 00:55:23 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA25770; Fri, 12 Jul 1996 00:55:23 -0400 Message-Id: <9607120455.AA25770@nips.acec.com> To: daniele@zk3.dec.com Subject: Re: Alignment, and PDU diagrams Cc: agentx@fv.com > Date: Thu, 11 Jul 96 10:38:20 -0400 > From: Mike Daniele Hi Mike, <..> > I've started to reorganize the PDU layouts to do so (using a binary > representation for oids). Seems pretty striaghtforward, varbinds in the > response may need padding... Excellent, Mike...you are doing an outstanding job as the technical lead on this effort. > Anyway, one of the things I'm finding is the current format for describing > PDUs is hard to read (at least for me). I know we were supposed to > "start with DPI", but what do folks think about adopting a more typical > format? I think that from a reader's perspective, the two forms are equivalent. So, do whatever works best for you, in consultation with Dale just in case there's any impact on the overall editing/ production effort. Thanks, again, for your exemplary effort. I am very hopeful that in a week or two (not before 7/19), I will be able to play a more useful role in this process. Thanks to various folks--Randy and Uri and Bert all come to mind...I am sure there are others--who have been helping with the AgentX PR via responses to agent-related queries on the SNMP list. And thanks to Dale for getting the Montreal minutes in to the IETF and cc'd to the list sometime later today! :-) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 12 Jul 1996 05:43:03 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id FAA12022 for X-agentx-local; Fri, 12 Jul 1996 05:43:01 -0700 (PDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by fv.com (8.7.4/8.7.3) with SMTP id FAA12014 for ; Fri, 12 Jul 1996 05:42:59 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id OAA29150; Fri, 12 Jul 1996 14:36:11 +0200 Received: from dijkstra.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id OAA17372; Fri, 12 Jul 1996 14:36:08 +0200 Received: by dijkstra.cs.utwente.nl (SMI-8.6/SMI-SVR4) id OAA12836; Fri, 12 Jul 1996 14:36:07 +0200 Date: Fri, 12 Jul 1996 14:36:07 +0200 Message-Id: <199607121236.OAA12836@dijkstra.cs.utwente.nl> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: agentx@fv.com In-reply-to: <9607101532.AA30077@bernie.zk3.dec.com> (message from Mike Daniele on Wed, 10 Jul 96 11:32:48 -0400) Subject: Re: binary oid syntax Mike Daniele wrote: > BER is certainly more space-efficient, but a decision was made some > time ago not to use BER for AgentX. I am not going to promote BER. I just want to understand the reasons behind the proposed encoding scheme. > The existing solutions typically don't use BER, so in effect trade > off space for a more simple encoding/decoding scheme. > This space consumption when not using BER is most pronounced with > oids, so it seems like a good candidate for some sort of simple > optimization. Note, the value of this optimization (or the encoding scheme in general) really depends on the transport mappings which define the costs to move bytes around. Some things to consider: - A size constraint transport mapping like UDP might create problems if the encoding of an object identifier gets too large. This is where using 32 bits for a single sub-identifier is problematic. - A transport mapping which allows to move bytes from the master to the subagent directly in memory (e.g. by using some form of shared memory) makes the need for your proposed optimization questionable. (It is probably easier/faster just to memcpy() things around and to accept a couple of more bytes in memory.) - A transport mapping based on e.g. TCP streams might benefit from the proposed scheme. Perhaps this is what you have in mind? I just want to understand the criteria and trade-offs for selecting an encoding scheme and the reasons for an optimizations like this. Note, there are other ways to reduce the number of bytes e.g. by having a field which defines if each subidentifier is encoded in one, two or four bytes. This again introduces some small overhead but it creates a reasonably compact encoding for the frequently used cases. Juergen   Delivery-Date: Fri, 12 Jul 1996 11:30:30 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA01163 for X-agentx-local; Fri, 12 Jul 1996 11:30:27 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA01107 for ; Fri, 12 Jul 1996 11:30:22 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA32413; Fri, 12 Jul 1996 14:20:30 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA06197; Fri, 12 Jul 1996 14:20:22 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA31047; Fri, 12 Jul 1996 14:21:55 -0400 Message-Id: <9607121821.AA31047@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Alignment, and PDU diagrams Date: Fri, 12 Jul 96 14:21:54 -0400 From: Mike Daniele X-Mts: smtp Hi Bob, >Excellent, Mike...you are doing an outstanding job as the technical >lead on this effort. Thanks for those encouraging words. I think now is a good time to post some things that I want folks to be aware of. I wrote the I-D because o we were thrashing, you can't really make progress without something written down, and everyone @ LA said "we need an I-D to shoot down" o there was no other spec available that contained a meaningful elements of procedure describing exactly how registration and dispatching should work The current I-D is obviously incomplete. It was an attempt to describe reg & dispatch, defining only enough other things to do so. (And even that much is very broken in spots...) While the incompleteness caused some confusion, after Montreal we now have concrete issues that we can work. I'm very aware that others have far more (and wider) experience with deployed extensible agents than I do. I'm trying hard to lean on those folks, and have them shape agentx to work well in their environments (embedded systems, hubs, etc). In particular, this means Jeff, Randy, and Maria :-) I know at least one person out there disagrees :-), but I don't think we're *that* far away from an implementable draft. I expect progress to be much swifter from here on. (Hope that statement doesn't bite me later...) >I am very hopeful that in a week or two (not before 7/19), >I will be able to play a more useful role in this process. I hope that will include posting some milestones for the wg :-) Regards, Mike   Delivery-Date: Sat, 13 Jul 1996 16:27:02 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id QAA02411 for X-agentx-local; Sat, 13 Jul 1996 16:27:00 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by fv.com (8.7.4/8.7.3) with SMTP id QAA02400 for ; Sat, 13 Jul 1996 16:26:58 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA08937; Sat, 13 Jul 96 16:26:59 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA04237; Sat, 13 Jul 96 16:26:58 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA04310; Sat, 13 Jul 96 16:26:58 PDT Date: Sat, 13 Jul 96 16:26:58 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9607132326.AA04310@santa.strata.com> To: agentx@fv.com Subject: Agentx WG at 36th IETF, reported by Dale Francisco Agentx WG at 36th IETF, June 24-28, 1996 ---------------------------------------- At the 36th IETF in Montreal, June 24-28, 1996, the SNMP Agent Extensibility Working Group (agentx) had two meetings, one on Tuesday, June 25, 09:00-11:30, and the other on Wednesday, June 26, 13:00-15:00. The most active participants in the discussions (a few names were missed due to inattentiveness on the part of the note- taker) were: Uri Blumenthal, Jeff Case, Mike Daniele, Maria Greene, Bob Natale, Bill Norton, David Partain, Dave Perkins, Randy Presuhn, Juergen Schoenwaelder, Bob Stewart, Randy Turner, Glenn Waters, Bert Wijnen, and Steve Zilles. About 80 people were present at the meetings. Meeting notes were taken by Dale Francisco, wg editor. Meeting 1 (Tue, June 25, 09:00-11:30) ------------------------------------- WG chair Bob Natale opened the meeting with a brief summary of the meeting agenda, a charter review, and a summary of progress to date. He praised the work of Mike Daniele in coming up with an initial protocol draft, of David Keeney in creating and maintaining an agentx web page, and of Bert Wijnen and others who provided extensive review comments on the draft both on and off the list. The chair stated that the primary goals of this wg meeting were to do a detailed review and discussion of the agentx protocol draft, and to come up with a schedule and commitments on actions needed to meet the goals set forth in the charter. He then began a review and discussion of the agentx protocol draft. Two points concerning SNMP and the agentx framework were raised: o The draft should be consistent in using SNMPv2 as the SNMP base protocol. o Though for the purposes of the draft document, master agent and subagents are restricted to the agentx protocol (not SNMP) for all communication between them, this is not meant to constrain other interfaces that these processing entities might have. There was a long discussion on the issue of OID representation in agentx and support for non-ASCII character sets. Bert Wijnen described the translation burdens that the proposed ASCII representation of OIDs would impose on master and subagent entities in non-ASCII environments. Randy Presuhn pointed out that even in ASCII environments, ASCII representation of OIDs would be space inefficient, expensive to translate to and from BER, and would not collate correctly. A consensus was reached to use a binary encoding for OIDs (probably integer vector), and to remove any text in the draft that referred to character set selection. The second half of the meeting began with introductory remarks from Mike Daniele, author of the protocol draft, on what he considered some important topics for discussion: procedures for registration and dispatch; whether or not to include information about the originating management request's SNMP version in messages from the master agent to subagents; how to resolve ties among subagents in the case of exactly duplicate registrations; and whether it was worth having a subagent flag registrations of fully-qualified instances, in order to allow the master agent to optimize getnext processing. A discussion followed concerning subagent registration and the issues of priority, naming scope, and duplicate registration. Randy Presuhn argued that allowing a master agent to return a different (lower) priority than the one a subagent attempted to register at was sufficient to cover most cases of conflicting registration among subagents; Bert Wijnen and others felt that this was overloading priority, and that some of the bits in the flags field (h.flags) might be used to indicate, for instance, that a subagent wanted a non- overlapping registration of some MIB region (that is, a registration that would neither displace a subagent already registered for some or all of that region, nor be subject to being itself displaced subsequent to registration). On the question of whether or not to include information about the originating management request's SNMP version in messages from the master agent to subagents, almost everyone agreed that it was esthetically offensive to pass this information to the subagent; at the same time, some felt that the potential for burning CPU cycles with futile getnexts to a v2-syntax columnar object made it worth the wart. Further discussion on mailing list was thought necessary before this could be resolved. Meeting 2 (Wed, June 26, 13:00-15:00) ------------------------------------- The review of the protocol draft continued with consideration of section 6, "Protocol Definitions", beginning with the Register PDU. Many felt that exact duplicate or overlapping registrations should be disallowed, either by rejecting registration requests or by reassigning priorities so as to remove the duplication. Jeff Case felt that overlapping registrations at the same priority could be accommodated either by allowing the master agent to decide which subagents to call, or by calling all overlapping agents and choosing the "best" answer. Randy Presuhn suggested subagents might use in registration requests a flag bit that would indicate overlapping registration was acceptable, in order to catch common cases in which overlap was a mistake (e.g., someone left an old, buggy subagent running). He also felt that the logic needed in the master agent to handle overlapping registration at equivalent priority was probably little more than was already required to do getnext and getbulk processing. This was a large topic; further discussion was deferred to the mail list. A question was raised as to whether the reason code (u.reason) was needed in the Unregister PDU. Several people felt that a reason code might be useful in reducing finger-pointing in a multivendor subagent situation. It was decided to reserve judgement until implementation experience showed if the reason code was actually useful. It was agreed that there needed to be a more detailed specification of how a master agent implements an access control policy. It was pointed out that the draft lacks a section on Set processing. There was a brief discussion of the "alone" bit in h.flags; this would be used to tell a subagent during a Set operation that, because it was the only subagent affected, it didn't need to wait for "commit" and "end" PDUs. Most felt that this was an unnecessary optimization. The meeting ended with the agreement that many of the architectural questions that had been raised during the Montreal wg meetings would have to be resolved on the mailing list. Bob Natale appealed for help in filling in unfinished portions of the draft, and expressed the hope that with sufficient progress on the protocol specification, we might be able to do interoperability testing at the Atlanta Interop (September 16-20, 1996).   Delivery-Date: Mon, 15 Jul 1996 14:20:32 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA23805 for X-agentx-local; Mon, 15 Jul 1996 14:20:32 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by fv.com (8.7.4/8.7.3) with ESMTP id OAA23796 for ; Mon, 15 Jul 1996 14:20:30 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA25515; Mon, 15 Jul 1996 17:11:27 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA30396; Mon, 15 Jul 1996 17:10:13 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA32082; Mon, 15 Jul 1996 17:11:45 -0400 Message-Id: <9607152111.AA32082@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: binary oid syntax Date: Mon, 15 Jul 96 17:11:44 -0400 From: Mike Daniele X-Mts: smtp Juergen, > - A transport mapping based on e.g. TCP streams might benefit from > the proposed scheme. Perhaps this is what you have in mind? Yes, I assume the only transport mapping we'll be able to specify is onto TCP. > - A transport mapping which allows to move bytes from the master to > the subagent directly in memory (e.g. by using some form of shared > memory) makes the need for your proposed optimization questionable. > (It is probably easier/faster just to memcpy() things around and > to accept a couple of more bytes in memory.) I think it would be great to have such a mapping (say for standard unix). I just doubt that the wg can produce one. Mike   Delivery-Date: Tue, 16 Jul 1996 17:39:17 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id RAA27307 for X-agentx-local; Tue, 16 Jul 1996 17:39:17 -0700 (PDT) Received: from mail.sharplabs.com ([204.75.175.200]) by fv.com (8.7.4/8.7.3) with SMTP id RAA27197 for ; Tue, 16 Jul 1996 17:38:54 -0700 (PDT) Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id RAA24261; Tue, 16 Jul 1996 17:34:47 -0700 Received: by sla5c (SMI-8.6) id RAA02153; Tue, 16 Jul 1996 17:34:40 -0700 From: "Randy Turner" Message-Id: <9607161734.ZM2151@sla5c.sharplabs.com> Date: Tue, 16 Jul 1996 17:34:38 -0700 In-Reply-To: Mike Daniele "Re: binary oid syntax" (Jul 15, 5:11pm) References: <9607152111.AA32082@bernie.zk3.dec.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: agentx@fv.com Subject: Re: binary oid syntax Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 15, 5:11pm, Mike Daniele wrote: > Subject: Re: binary oid syntax > Juergen, > > > - A transport mapping based on e.g. TCP streams might benefit from > > the proposed scheme. Perhaps this is what you have in mind? > > Yes, I assume the only transport mapping we'll be able to > specify is onto TCP. I hope this is not the case....at least in the RFCs for SNMP V2 it was fairly easy to be transport-independent, and include specs for Novell IPX and AppleTalk DDP. I think transport-independence will just fall out of this work, and while we can specify TCP as an example transport, I hope our design doesn't preclude other transports as well...... Randy   Delivery-Date: Wed, 17 Jul 1996 18:33:38 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id SAA24655 for X-agentx-local; Wed, 17 Jul 1996 18:33:37 -0700 (PDT) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by fv.com (8.7.4/8.7.3) with ESMTP id SAA24618 for ; Wed, 17 Jul 1996 18:33:26 -0700 (PDT) Message-Id: <199607180134.AA048823645@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA048823645; Wed, 17 Jul 1996 18:34:05 -0700 Date: Wed, 17 Jul 1996 18:34:05 -0700 From: Randy Presuhn To: agentx@fv.com Subject: "Unionized" registration Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - As promised at the Montreal meeting, I've written up my understanding of the proposal for handling "unionized" registration and operations that grew out of Jeff Case's description of a specific configuration. This too-lengthy post has three sections: 1) the "unionized" registration proposal from Montreal 2) an analysis of this proposal 3) a list of other issues uncovered in this discussion Goals: - to find out whether there was indeed a requirement - to find out whether there was an acceptable solution I'm not convinced that we should do this, but I've tried to keep the presentation reasonably objective, and am eager to see what I've missed. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA ----------------------------------------------------------------------------- =========================================================================== 1. Description of "unionized" registration 1.1 Example The example given by Jeff Case was of a 64-processor system, in which each processor had its own set of IP addresses, and for which a single, unified tcpConnTable was to be made visible to management. Jeff suggested that a way to handle this configuration was to allow each of the 64 subagents to claim responsibility for the entire tcpConnTable. To process an SNMP operation potentially involving tcpConnTable would then require dispatching that operation to the subagents claiming responsibility for that table, and then use some resolution algorithm / heuristic to determine which response(s) should be used in formulating the SNMP response. The goal was to be able to minimize the registration traffic and master agent memory required to support a highly dynamic set of object instances scattered across multiple subagents, where the indexing structure does not reflect the division of labor among the subagents. 1.2 Requirements Statement Most of the time, identical registrations (same region, same non-default priority) are a symptom of a configuration error. It would be good to be able to treat them as an error. Consequently, there is a requirement that a subagent making such a registration request must explicitly identify this request as being potentially identical to that claimed by some other subagent. If there is a need to support complete overlap in the registration of two or more subagents (because there is some MIB in which the index assignment algorithm in no way follows the partitioning into subagents and the rows are very dynamic) then it would be good to, at registration time, be able to explicitly identify these registrations, and to distinguish them from the common configuration error described above. A subagent would be able to claim responsibility for a MIB region identical to a MIB region claimed by another subagent. (Identical means: same naming scope, same priority, same set of subtrees.) In processing an SNMP operation, the master agent must consider the union of the sets of objects actually supported by the subagents claiming the relevant MIB regions. In cases where multiple subagents are capable of responding for a specific object instance, the issue of determinism was not addressed, and represents a potentially serious problem. These requirements are independent of the requirements to support row and instance level registration, as well as the ability to support arbitrary subtree registration. 1.3 Protocol Description The syntax for registration requests needs an additional bit of information that identifies a registration request as being a "unionized" registration. The semantics of a unionized registration request differ from a conventional registration request in the handling of a "duplicate" registration. Instead of identifying the duplicate as an error, the unionized registration will be accepted if the existing registration was also flagged as a unionized registration. The procedures for processing requests involving unionized mib regions can be thought of as a generalization of the procedures for handling non-unionized requests, adding an additional loop to the algorithms. For GET operations, for all relevant subagents, the request is propagated and a response accepted. The master agent uses these responses in formulating its response to the SNMP operation. For each SNMP varbind, the first non-(error/missing data) response is the one used in the reply to the SNMP operation. Note that if more than one subagent is able to provide a value for a specific varbind, the results of this algorithm are not deterministic. For SET operations, for all variable bindings, for all relevant subagents, the request is propagated and a response accepted to determine which subagents are able to support set requests for the specific varbind. Once this set has been determined, normal set processing can proceed. If more than one subagent is able to handle a specific varbind, the results of this algorithm are not deterministic. Note also that this processing would be simplified if subagent SET processing were modified to support "trickled" requests, although at the cost of a substantially more complex state space. For GET-NEXT/BULK, for all relevant subagents, the request is propagated and a response accepted. All responses must be considered by the master agent to determine which is lexicographically "next." Behavior when ties occur is not deterministic. =========================================================================== 2. Analysis of "unionized" registration 2.1 Requirements We need to be sure that these requirements are real. Are there are important configurations not handled by the existing agentx registration mechanisms? For the example of the tcpConnTable, SMUX handles the registration nicely with a sequence of five registration requests per ip address a.b.c.d: tcpConnTable.[1-5].a.b.c.d This avoids the unworkable churn of registering fully-qualified instances for every connection. For addresses like 0.0.0.0 and 127.0.0.1, there would need to be information sharing among the TCP stacks in any case in order to get reasonable TCP/IP behavior. The lack of specified determinism worries me, although if identical instances are supported by multiple subagents in this kind of configuration, there are probably more serious system level problems, unless we're doing some kind of aggregation. An issue that arose in the discussion in Montreal was the question of whether the selection algorithm in the case where multiple subagents were able to handle a query for a region should include aggregation. Before we start over-engineering the agentx protocol, we need to be sure that the requirements are real. 2.2 Implementation Complexity Registration complexity is slightly increased, though the burden is not onerous, in my opinion. For simple GET, it's clear the implementation complexity is fairly low. GET-NEXT and GET-BULK require more memory than GET, but are not significantly more complex than is necessary to handle overlapped registrations. SET gets complicated, because the discovery of the set of subagents willing to perform a proposed SET operation interacts with the commit protocol used between subagent and master agent. Minimizing the number of transactions would require modifying the SET protocol to allow "trickled" requests (master agent allowed to send multiple phase 1 requests to a single subagent before proceeding to the next phase, requiring the subagent to hang on to these bits and pieces so it can later do cross-checking.) 2.3 Performance Characteristics The performance characteristics of unionized registration concern me. Two complementary implementation approaches come to mind, depending on that choice of underlying transport and the level of true concurrency achievable in the target system. An important factor throughout this analysis is the probability that a given subagent will be able to give the definitive answer for a given query. If we do support this kind of registration, the processing of operations for those mib regions becomes a bit more interesting. For GET and SET operations, on average, N/2 exchanges over N/2 time will be needed to process the operation if processing is iterative, or N exchanges over some smaller period of time if processing is parallelized. In either case, the processing load is O(N), where N is the number of unionized regions targeted by the operation. If the cost of delivering the same request concurrently to a large number of subagents is low for the transport in use, or if the average time required for a subagent to generate a reply times the number of subagents approaches the acceptable time limit for the formulation of SNMP responses, then it makes sense to emulate a multicast to the relevant subagents, and process their responses as they come back. This results in N transactions for all operation types. Otherwise, it makes sense to iteratively try each relevant subagent until an acceptable response is received. This results on average in N/2 requests for GET and SET operations, but still requires N transactions for GET-BULK/NEXT. For GET-NEXT and GET-BULK, due to the nature of the operations, it will always be necessary to dispatch the operation to all the subagents claiming the unionized region. (GET and SET can be satisfied by the first subagent willing to process the varbind. With GET-NEXT and GET-BULK you don't know whether you've gotten the "best" response until you've asked them all.) To put this in perspective, unionized registration would typically require agentx to perform, for the tcpConnTable example, between 32 and 64 times more agent/subagent transactions than SMUX to retrieve the same information. 2.4 Memory requirements For most interesting configurations, this proposal could produce memory savings in the master agent by reducing the amount of registration information that would need to be stored. The magnitude of these savings would be directly related to how poorly the object indexing structure mapped onto the subagent division of labor. =========================================================================== 3. Other issues uncovered 3.1 There may be value in generating a trap when a registration attempt fails for certain reasons. 3.1.1 Detection of a non-unionized duplicate registration, usually a symptom of a configuration error. 3.1.2 Run-time detection of duplicate instances within unionized regions. 3.2 Should the master agent be able to "adjust" registration priority at any time other than when the registration is requested? (This arose in conjunction with discussion of run-time detection of duplicate instances within unionized regions.) ===========================================================================   Delivery-Date: Sun, 21 Jul 1996 17:03:10 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id RAA16398 for X-agentx-local; Sun, 21 Jul 1996 17:03:10 -0700 (PDT) Received: from relay.conware.de ([153.92.1.3]) by fv.com (8.7.4/8.7.3) with SMTP id RAA16381 for ; Sun, 21 Jul 1996 17:03:07 -0700 (PDT) Received: from voyager.conware.de by relay.conware.de with smtp (Smail3.1.28.1 #2) id m0ugss0-000E5HC; Thu, 18 Jul 96 15:11 MET DST Received: by voyager.conware.de (/\==/\ Smail3.1.25.1 #25.8) id ; Thu, 18 Jul 96 15:21 MET DST Message-Id: From: finken@conware.de (Michael Finken) Subject: subscribe agentx@conware.de To: agentx@fv.com Date: Thu, 18 Jul 1996 15:21:33 +0200 (MET DST) Organization: Conware Computer Consulting GmbH, Karlsruhe, Germany X-SecretAgent-For: Serious Cybernetics Corporation for Robotics and Metaphysics X-Tribbles-Info: Help!! They are everywhere!!! X-Public-Service-Announcement: Prevent Tribble Abuse. Just say No. X-Mailer: ELM [version 2.4ME+ PL14 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit quit ------------------------------------------------------------------------------- Michael Finken Conware Computer Consulting GmbH E-Mail: finken@conware.de Killisfeldstr. 64 76227 Karlsruhe/Germany Tel.: +49 721 9495-0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Huehneraugen bekaempft man am besten mit ihrem natuerlichen Feind, mit dem Fuchsschwanz. -------------------------------------------------------------------------------