Delivery-Date: Fri, 02 Aug 1996 07:39:10 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA26339 for X-agentx-local; Fri, 2 Aug 1996 07:39:09 -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 HAA26335 for ; Fri, 2 Aug 1996 07:39:08 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id JAA24259; Fri, 2 Aug 1996 09:57:03 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05804; Fri, 2 Aug 1996 09:57:02 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA02758; Fri, 2 Aug 1996 09:58:36 -0400 Message-Id: <9608021358.AA02758@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: "Unionized" registration In-Reply-To: Your message of "Wed, 17 Jul 96 18:34:05 PDT." <199607180134.AA048823645@dorothy.peer.com> Date: Fri, 02 Aug 96 09:58:35 -0400 From: Mike Daniele X-Mts: smtp Hi Randy, Thanks for an excellent write-up. You write very well... :-) It's been over 2 weeks since you posted, with nary a peep in reply (at least on the list). > 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 And in agentx this can be accomplished in a single registration request. Yes, the real question is do we need unionized registration? We'd need it to support 1) tables whose indexing structure permit no other way of sharing except by registering complete instances, and whose size/dynamism make this unreasonable 2) "poorly" behaved subagents. for instance, in the 64 processor example, each subagent registers tcpConnTable instead of a more qualified region. We might need it so support 3) Roll-up (at least that's what i call it). things like, who maintains those untidy objects that count table rows, when the table is being shared? (is that what you call aggregration?) 4) Row creation. I know in a previous discussion you had mentioned a configuration in which one "overseer" subagent registers (for example) ifTable, and spawns other subagents when interfaces are created (which in turn register their own specific interface). In cases like this 3) and 4) could be easily handled without unionized registration. Is 2) valid? for example, given suagents that share ifTable, is it reasonable to assume they'll register the proper regions under ipNetToMedia, ifStack, etc? Or will they just register those tables and expect the master to sort things out? As far as 1), there certainly are such MIBs (host mib process table), but they typically are implemented in a single subagent. Are there others? Maybe something indexed by a string? A term I've seen used elsewhere that might be applicable is "implementable, but not deployable". I think that with agentx as currently specified (without unionized registration), one could implement a total solution that works for ~all configurations. However, once you throw in separate implementations having to coexist, I'm not sure it would work out so well. For instance, two different vendors might each implement the "overseer" subagent for a particular table. I hate the idea, but it seems like agentx will need to support unionized registration. I sure would feel better after hearing about existing configurations that absolutely require it. Regards, Mike   Delivery-Date: Tue, 06 Aug 1996 05:15:33 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id FAA14004 for X-agentx-local; Tue, 6 Aug 1996 05:15:33 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id FAA14001 for ; Tue, 6 Aug 1996 05:15:32 -0700 (PDT) Message-Id: <199608061215.FAA14001@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4188; Tue, 06 Aug 96 08:15:27 EDT Date: Tue, 6 Aug 96 14:14:18 DST From: "Bert Wijnen" To: agentx@fv.com Subject: AGENT-CAPABILITIES for subagents We didn't finish this discussion yet (I think). Yet, I want to experiment with it within my DPI implementation, so I get a feel for what this means. Here is some old conversation: > I asked: > At the L.A. agentX meetings I suggested that I was thinking about > mapping the subAgent OID (as passed with the DPI_OPEN request) into > the sysORTable. The idea here is that the OID by which you identify > you subagent is the OID that represents the AGENT-CAPABILITIES > statement for that subagent. > > Some of the people present did not agree to that. Can they pls explain > (again) why they do not agree and how they see that we will dynamically > update the sysORTable when a new sub-agent registers any subtrees? > > to which Maria responded with: > In the Entity MIB working group we concluded that each Logical Entity > should implement the system group (and therefore the sysORTable) in > its naming scope. By sweeping the entLogicalTable with the "default" > context/community, you can determine what the Logical Entities are and > their corresponding context/community. Then, by sweeping the > sysORTable with the appropriate context/community string, you can > (indirectly through AGENT-CAPABILITIES) determine the set of managed > objects each entity supports. > > More than one subagent can register the same OIDs and the same > instances, in which case the context/community string is needed in > order to dispatch the request to the correct subagent. So, my real > question is how does a subagent get associated with a Logical Entity > (naming scope, context, community string...)? Maybe that's part of the > open request, too? My current understanding is that agentX will indeed allow for subagents to specify the context within which they want to operate. So then, I think this means that within one context we should only see one instance of any MIB. And so a subagent could use its subagent ID (an OID in DPI) to represent its AGENT-CAPABILITIES. If multiple subagents then register multiple instances of the same MIB (each in its own context), then they better all implement that MIB in exactly the same way. If not, then they better use a different subagent ID. We have not yet documented the OPEN PDU. Maybe instead of using an agentID (as we do in DPI) we should use an agentCapabilities in the open request. In SMUX and DPI their agentID could then be mapped onto the agentCapabilities if needed. Any comments? Bert.   Delivery-Date: Tue, 06 Aug 1996 07:00:06 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA03090 for X-agentx-local; Tue, 6 Aug 1996 07:00:05 -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 HAA03080 for ; Tue, 6 Aug 1996 07:00:04 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id JAA22442; Tue, 6 Aug 1996 09:49:11 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05604; Tue, 6 Aug 1996 09:49:10 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04136; Tue, 6 Aug 1996 09:50:37 -0400 Message-Id: <9608061350.AA04136@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: AGENT-CAPABILITIES for subagents In-Reply-To: Your message of "Tue, 06 Aug 96 14:14:18 +0700." <199608061215.FAA14001@fv.com> Date: Tue, 06 Aug 96 09:50:36 -0400 From: Mike Daniele X-Mts: smtp Hi Bert, >My current understanding is that agentX will indeed allow for subagents >to specify the context within which they want to operate. Yes, registrations may specify context. >We have not yet documented the OPEN PDU. Maybe instead of using an >agentID (as we do in DPI) we should use an agentCapabilities in the >open request. >So then, I think this means that within one context we should only >see one instance of any MIB. I think so. >And so a subagent could use its subagent ID (an OID in DPI) to represent its >AGENT-CAPABILITIES. >We have not yet documented the OPEN PDU. Maybe instead of using an >agentID (as we do in DPI) we should use an agentCapabilities in the >open request. In SMUX and DPI their agentID could then be mapped This would be nice and simple, but may not map well to our registration model. A subagent may participate in multiple contexts. It may even register different MIB regions in the different contexts. A single agent-caps (associated with a single context) wouldn't represent the subagent accurately. The 2 alternatives are 1. Put agent caps in the REGISTER PDU. Subagents would then be able to (optionally) associate specific agent caps with specific contexts. 2. Create a new PDU. My vote (based on 0 experience with non-default contexts) is for simple. Let's provide for a single agent capabilities in the OPEN pdu. If that proves unworkable for some situations we'll modify it later. The PDU should contain an object identifier and a string, to be used as sysORID and sysORDescr. The implications are that this agent capabilities "entry" is present in sysORTable for each context in which this subagent subsequently registers any MIB region. How's that sound? Mike   Delivery-Date: Tue, 06 Aug 1996 07:34:42 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA10083 for X-agentx-local; Tue, 6 Aug 1996 07:34: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 HAA10074 for ; Tue, 6 Aug 1996 07:34:39 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA26420; Tue, 6 Aug 1996 10:24:29 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA13763; Tue, 6 Aug 1996 10:24:25 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04149; Tue, 6 Aug 1996 10:26:03 -0400 Message-Id: <9608061426.AA04149@bernie.zk3.dec.com> To: agentx@fv.com Subject: 05: sysUpTime Date: Tue, 06 Aug 96 10:26:02 -0400 From: Mike Daniele X-Mts: smtp On this list we had arrived at some conclusions. Subagent registration of MIB regions will cause sysORTable entries to be created, and unregistration will cause their removal. Loss of connection with a subagent should be handled in the master agent by unregistering all the subagents registered regions. This provided a mechanism for subagents to reset the timestamps in sysORTable. Further, subagents whose MIB regions have "typical" counters (that are not explicitly defined to reference a particular timestamp) could use the sysORTable timestamps as this reference (as opposed to referencing sysUpTime). By unregistering and reregistering, they could reset this reference time when they perceived a counter discontinuity. The master agent would emit a warmStart trap when the sysORTable changes. It would reset sysUpTime when the master agent reboots. It would also return sysUpTime in response to an OPEN PDU, so subagents would have a common time base. Sounded pretty good... At the first Montreal interfaces mib wg though, there was some discussion that counters inherently reference sysUpTime, and that it's a semantic change to associate a counter with a different timebase object. (someone correct me please if i mis-interpreted) So, any comments on AgentX and sysORTable vis a vis sysUpTime? Mike   Delivery-Date: Tue, 06 Aug 1996 08:31:01 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA21633 for X-agentx-local; Tue, 6 Aug 1996 08:31:01 -0700 (PDT) Received: from ta.antec.com ([205.187.171.11]) by fv.com (8.7.4/8.7.3) with SMTP id IAA21610 for ; Tue, 6 Aug 1996 08:30:59 -0700 (PDT) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) for id LAA16109; Tue, 6 Aug 1996 11:22:55 -0400 Date: Tue, 6 Aug 1996 11:22:55 -0400 Message-Id: <199608061522.LAA16109@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: AGENT-CAPABILITIES for subagents At 02:14 PM 8/6/96 DST, Bert Wijnen wrote: [deleted...] >My current understanding is that agentX will indeed allow for subagents >to specify the context within which they want to operate. >So then, I think this means that within one context we should only >see one instance of any MIB. And so a subagent could use its subagent >ID (an OID in DPI) to represent its AGENT-CAPABILITIES. If multiple >subagents then register multiple instances of the same MIB (each in its >own context), then they better all implement that MIB in exactly the >same way. If not, then they better use a different subagent ID. > [deleted...] >Any comments? How does this relate to cases where subagents access different rows of a table, as in the network services MIB? If the SubAgent ID is used like the OID is in DPI, is that then a unique tag that maps to a set of OIDs that the subagent accesses or what? Thanks, Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: george.best@antec.com Digital Video voice: (770)734-0400 ext. 8534 A Division of Arris Interactive Norcross GA, USA   Delivery-Date: Tue, 06 Aug 1996 10:14:56 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA13898 for X-agentx-local; Tue, 6 Aug 1996 10:14:56 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.4/8.7.3) with SMTP id KAA13890 for ; Tue, 6 Aug 1996 10:14:53 -0700 (PDT) Message-Id: <199608061714.KAA13890@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7559; Tue, 06 Aug 96 13:14:46 EDT Date: Tue, 6 Aug 96 19:12:25 DST From: "Bert Wijnen" To: george.best@antec.com, agentx@fv.com Subject: AGENT-CAPABILITIES for subagents Ref: Your note of Tue, 6 Aug 1996 11:22:55 -0400 Subject: AGENT-CAPABILITIES for subagents George writes: > How does this relate to cases where subagents access different rows of a > table, as in the network services MIB? If the SubAgent ID is used like the > OID is in DPI, is that then a unique tag that maps to a set of OIDs that the > subagent accesses or what? The way I suggested it is that the subAgent ID would go directly into the sysORtable as an entry. Such an OID then represents an AGENT-CAPABILITIES< and that AGENT-CAPABILITIES statement should list exactly what (group of) objects in which MIB its supports and how. Bert   Delivery-Date: Wed, 07 Aug 1996 14:54:14 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA04544 for X-agentx-local; Wed, 7 Aug 1996 14:54:14 -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 OAA04540 for ; Wed, 7 Aug 1996 14:54:13 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id RAA00152; Wed, 7 Aug 1996 17:54:14 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA18968; Wed, 7 Aug 1996 17:51:23 -0400 Date: Wed, 7 Aug 1996 17:53:37 EDT From: Bob Natale Subject: Re: "Unionized" registration To: daniele@zk3.dec.com, rpresuhn@peer.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Fri, 02 Aug 96 09:58:35 -0400 Hi Mike, Randy and everyone, [Speaking as wg chair:] We need to pick up the pace here. A new draft of the protocol spec is in the works and should hit the list shortly--thanks entirely to the efforts of Mike, Dale, and the cadre that has been consulting with Mike from time to time. And many thanks to Randy for another helpful analysis of another difficult topic (more on this after this administrative intro). We need to plan some implementation testing/reporting in the near future...I am going to check whether we can get some BOF time at Interop (Atlanta, mid-September)...let me know what you think about that. [Speaking (mostly) as a technical contributor:] Here's my take on the "unionized registration" issue >> Date: Wed, 17 Jul 1996 18:34:05 -0700 >> From: Randy Presuhn >>... >> 2.1 Requirements >> >> We need to be sure that these requirements are real. Right. And not just "real", but of significant magnitude in terms of probable affected user base and the availability (or not) of less costly alternatives. More on this later. >> Are there are important configurations not handled by the >> existing agentx registration mechanisms? There can be some of these, even when AgentX is complete. The (mandatory) goal of AgentX is to provide a protocol by which an independently developed sub-agent can interoperate with an independently developed master agent, at the protocol level. It will be permissable for master agents and extensible agent development toolkits to provide a super-set of extensible agent functionality relative to that provided by the AgentX protocol. The goal, of course, is to accommodate the 80-90% of "simple" sub-agent configurations in a straightforward manner. The remaining 10-20% might have to find some other solution--perhaps in a super-set environment--if accommodating them within AgentX makes life too difficult for the 80-90% crowd. >> 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 > > And in agentx this can be accomplished in a single registration > request. Excellent improvement. > Yes, the real question is do we need unionized registration? > We'd need it to support > > 1) tables whose indexing structure permit no other way of sharing > except by registering complete instances, and whose size/dynamism > make this unreasonable > > 2) "poorly" behaved subagents. for instance, in the 64 processor > example, each subagent registers tcpConnTable instead of a more > qualified region. > > We might need it so support > > 3) Roll-up (at least that's what i call it). things like, > who maintains those untidy objects that count table rows, when > the table is being shared? (is that what you call aggregration?) > > 4) Row creation. > > I know in a previous discussion you had mentioned a configuration > in which one "overseer" subagent registers (for example) ifTable, > and spawns other subagents when interfaces are created (which in turn > register their own specific interface). In cases like this 3) and 4) > could be easily handled without unionized registration. Two down, two to go. > Is 2) valid? for example, given suagents that share ifTable, is > it reasonable to assume they'll register the proper regions under > ipNetToMedia, ifStack, etc? Or will they just register those tables > and expect the master to sort things out? Perhaps the "index reservation" approach can be used here...? I believe that Maria has some relevant info on this from Jeff that she will eventually post to the list. Two and one-half down; one and a half to go. > > As far as 1), there certainly are such MIBs (host mib process table), > but they typically are implemented in a single subagent. ^^^^^^^^^ Right (90+%). Three and a half down; a half to go. > Are there others? Maybe something indexed by a string? I was not sure whether these questions were an integral part of 1) or a new category...? > A term I've seen used elsewhere that might be applicable is > "implementable, but not deployable". I think that with agentx > as currently specified (without unionized registration), one > could implement a total solution that works for ~all configurations. That sounds like a win. > However, once you throw in separate implementations having to > coexist, I'm not sure it would work out so well. All that has to "coexist" is this: - A compliant independently developed AgentX sub-agent must be able to plug into a compliant independently developed AgentX master agent, at the protocol level (i.e., independently of APIs, toolkits, etc.). It is not a requirement that every conceivable agent be implementable (solely) as an AgentX sub-agent. Nor is it a requirement that a given master agent cannot provide a super-set of AgentX capabilities. It is also permissable for people to build and market comprehensive extensible agent development and runtime enironments that provide enhanced capabilities. And so forth. > For instance, two different vendors might each implement the > "overseer" subagent for a particular table. This sounds like a strictly local configuration problem to me. As long as the master agent can return an error status in response to an invalid registration request, that's ok. > I hate the idea, but it seems like agentx will need to support > unionized registration. I don't hate the idea, but I feel it has proven itself too "costly" both in terms of actually getting a "workable" AgentX protocol designed and agreed upon and in terms of probable impact on the 80-90% of "simple" sub-agents that would benefit greatly from a standard protocol for working with master agents. Randy's point puts the lid on it, as far as I am concerned: "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." That's a loser, IMHO. > I sure would feel better after hearing about existing > configurations that absolutely require it. And any alternative (super-set) means for them to use instead. 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, 16 Aug 1996 01:56:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id BAA13078 for X-agentx-local; Fri, 16 Aug 1996 01:56:03 -0700 (PDT) Received: from netra.soft.net (netra.soft.net [164.164.128.17]) by fv.com (8.7.4/8.7.3) with SMTP id BAA13010 for ; Fri, 16 Aug 1996 01:55:56 -0700 (PDT) Received: from plutonium.bflsl.soft.net. by netra.soft.net (5.x/SMI-SVR4) id AA08067; Fri, 16 Aug 1996 14:23:27 +0500 Received: by plutonium.bflsl.soft.net. (SMI-8.6/SMI-SVR4) id OAA04570; Fri, 16 Aug 1996 14:25:53 -0600 From: bflcim@plutonium.bflsl.soft.net (CIM Agents Group) Message-Id: <199608162025.OAA04570@plutonium.bflsl.soft.net.> Subject: DPI Interface problem on Warp server advanced.... To: agentx@fv.com Date: Fri, 16 Aug 1996 14:25:52 -0600 (GMT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text   Delivery-Date: Fri, 16 Aug 1996 05:13:52 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id FAA10793 for X-agentx-local; Fri, 16 Aug 1996 05:13:51 -0700 (PDT) Received: from netra.soft.net (netra.soft.net [164.164.128.17]) by fv.com (8.7.4/8.7.3) with SMTP id FAA10760 for ; Fri, 16 Aug 1996 05:13:40 -0700 (PDT) Received: from plutonium.bflsl.soft.net. by netra.soft.net (5.x/SMI-SVR4) id AA09706; Fri, 16 Aug 1996 17:40:30 +0500 Received: from nt-os2 by plutonium.bflsl.soft.net. (SMI-8.6/SMI-SVR4) id RAA00509; Fri, 16 Aug 1996 17:42:55 -0600 Date: Fri, 16 Aug 1996 17:42:55 -0600 Message-Id: <1.5.4.32.19960816172727.0032150c@164.164.58.2> X-Sender: bflbvs@164.164.58.2 X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: teamos2-l@teamos2.org, agentx@fv.com, wijnen@vnet.ibm.com From: Sunil B V Subject: OS/2 DPI initialization is FAILING!!!!!!!! Cc: bflssn@plutonium.bflsl.soft.net, bflcim@plutonium.bflsl.soft.net, atmakuri@bangate.compaq.com, asunder@bangate.compaq.com Hi All, This mail is intended to get an explaination on a very TRIVIAL problem as explained below... We are developing an SNMP sub-agent application on OS/2. We are calling a DPI call "query_dpi_port" to get a VALID dpi_port descriptor, to enable us to succesfully establish link between our sub-agent and the OS/2 MASTER AGENT program. We are able to get a VALID DPI descriptor on OS/2 2.11 , OS/2 WARP, OS/2 WARP Connect flavours of OS/2. But this call is failing on WARP Server version of OS/2 with a retrun value of "-1". We ran the TCPSTART.CMD file again after this DPI_PORT call failed and found to our great surprise that the same call worked fine and we were able to get a VALID dpi_port descriptor. We are registering our sub-agent after "mib_2.exe" is registered. Is this the default behaviour of TCPIP/SNMP implementation on WARP Server version of OS/2? Thanks in advance.. Sunil (e-mail : bflbvs@plutonium.bflsl.soft.net)   Delivery-Date: Fri, 23 Aug 1996 09:36:45 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id JAA02426 for X-agentx; Fri, 23 Aug 1996 09:36:44 -0700 (PDT) Received: from mtldns.esc.lmco.com (mtldns.esc.lmco.com [128.126.52.200]) by fv.com (8.7.4/8.7.3) with SMTP id JAA02421 for ; Fri, 23 Aug 1996 09:36:42 -0700 (PDT) Received: from monsmtp.esc.lmco.com by mtldns.esc.lmco.com (4.1/SMI-4.1) id AA27564; Fri, 23 Aug 96 12:10:17 EDT Received: by monsmtp.esc.lmco.com with Microsoft Mail id <321DDE43@monsmtp.esc.lmco.com>; Fri, 23 Aug 96 12:37:23 EDT From: "Hamilton, Ed @ OTT" To: "''Agentx Mail'" Subject: SNMP DPI Date: Fri, 23 Aug 96 12:36:00 EDT Message-Id: <321DDE43@monsmtp.esc.lmco.com> Encoding: 8 TEXT X-Mailer: Microsoft Mail V3.0 Hi, Can anyone provide an overview of the current status of RFC 1592, SNMP-DPI. Are people using it? Is there a newer version? What do people have to say, good and bad about it? --- Ed.Hamilton@lmco.com   Delivery-Date: Sun, 25 Aug 1996 13:54:05 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA22193 for X-agentx; Sun, 25 Aug 1996 13:53:53 -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 NAA22189 for ; Sun, 25 Aug 1996 13:53:52 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id QAA03414; Sun, 25 Aug 1996 16:53:38 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA23555; Sun, 25 Aug 1996 16:52:25 -0400 Date: Sun, 25 Aug 1996 16:52:52 EDT From: Bob Natale Subject: Re: relationships to other MIBs To: Harald.T.Alvestrand@uninett.no Cc: applmib@emi-summit.com, agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Harald.T.Alvestrand@uninett.no > Date: Sun, 25 Aug 1996 22:09:07 +0200 <...> > I'm concerned about the scenario: > > Manager trying to find linkages > | | > | | > | | > HR MIB implementation | > [PID 1248] SysApp MIB implementation > | [PID 2986] > | | > | | > OS that does NOT use small integers for process ID > [process CX_12345_ALPHA] > > One may be doing a folded MD5 hash of the process name, the other may > be using the process ID as an index into an internal PID->name cache. > > The AgentX WG seems to be trying to make it easy to create such > scenarios. But do we think they will actually become common? I'd like to take this opportunity to let everyone know that Mike Daniele and Dale Francisco have been working on a revision of the AgentX protocol draft and that will be posted on the AgentX list in the immediate future (early this week, I expect). Once posted, we will try to channel the ensuing discussion toward issues of implementation and deployment, and away from protocol architecutre and marginal cases. It is time to add AgentX to the "solution space". Whether AgentX itself will make it easy to craete scenarios such as that outline above remains to be seen. We are still anticipating a contribution from SNMP Research wrt "index reservation" that may play a helpful role in that. In any case, once this latest version of the spec hits the street, this is definitely one of those implementation issues that we will try to resolve quickly. 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: Mon, 26 Aug 1996 06:21:42 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id GAA04486 for X-agentx; Mon, 26 Aug 1996 06:21:42 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id GAA04469 for ; Mon, 26 Aug 1996 06:21:39 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id JAA00517 for ; Mon, 26 Aug 1996 09:21:32 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id JAA24303 for ; Mon, 26 Aug 1996 09:17:53 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id JAA05567; Mon, 26 Aug 1996 09:23:21 -0400 (EDT) Date: Mon, 26 Aug 1996 09:23:21 -0400 (EDT) From: Maria Greene Message-Id: <199608261323.JAA05567@avalon.nexen.com> To: agentx@fv.com Subject: AgentX MIB Draft Happy Monday, everyone. Attached you'll find the first draft of the AgentX MIB. This MIB is based on Bert Wijnen's Subagent MIB which, itself, was based on Marshall Rose's SMUX MIB. This is a working draft and hasn't been placed in the official repository yet. I'd like to make it match the latest AgentX protocol I-D before it gets published more widely. Please send any and all comments to the agentx@fv.com list. (Typos/nits you can send directly to me.) Maria - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INTERNET-DRAFT AgentX MIB August 1996 Definitions of Managed Objects for Extensible SNMP Agents August 24, 1996 Maria Greene Ascom Nexion greene@nexen.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires February 1997 [Page 1] INTERNET-DRAFT AgentX MIB August 1996 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. Expires February 1997 [Page 2] INTERNET-DRAFT AgentX MIB August 1996 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "master agent" and multiple "subagents". This is necessary because there is only one well-known UDP port for SNMP (161) which can only have one listener, but there are many vendors that may contribute software which contains management instrumentation for a variety of MIBs. Furthermore, these subagents may come and go over time as hardware is installed and removed or as software is started and stopped. The AgentX protocol is described in detail in [6]. Support for the MIB module described in this memo is optional for AgentX master agents. The optional designation is somewhat unusual for an SNMP MIB module. However, one of the goals of AgentX is to support identical SNMP protocol operations as the equivalent monolithic SNMP agent. In other words, an SNMP manager should not need to be modified to be able to communicate with an AgentX agent. However, this transparency could hinder trouble-shooting and would not allow tuning of the behavior of the AgentX protocol. Therefore, this MIB module defines a standard set of MIB objects that must be supported by a manageable AgentX entity. The goals of the AgentX MIB are: o List the set of subagents currently registered with the master agent and their status. Allow the manager to stop a subagent. o Identify the subagent's type, vendor, transport address, AgentX protocol version and other characteristics. o Identify the set of MIB objects each subagent implements, the context in which the objects are registered and the priority of the registration. Specifying priority allows overlapping registrations. o Provide statistics about the protocol operation such as the number of packets to and from each subagent. o Allow control of protocol operation parameters such as the timeout interval for responses from a subagent. Expires February 1997 [Page 3] INTERNET-DRAFT AgentX MIB August 1996 3. Definitions AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, experimental, Counter32, BITS FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF DisplayString, TruthValue, TimeStamp, TDomain, TAddress FROM SNMPv2-TC ; agentxMIB MODULE-IDENTITY LAST-UPDATED "9608241200Z" -- August 24, 1996 ORGANIZATION "IETF AgentX Working Group" CONTACT-INFO "Maria Greene Postal: Ascom Nexion 289 Great Road Acton, MA 01720 USA Tel: +1 508 266 4570 E-mail: greene@nexen.com Bert Wijnen Postal: IBM International Operations Watsonweg 2 1423 ND Uithoorn The Netherlands Tel: +31 348 412 498 E-mail: wijnen@vnet.ibm.com" DESCRIPTION "The MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent." ::= { experimental 2001 } -- ::= { experimental XX } axObjectIdentities OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxTcpDomain OBJECT-IDENTITY STATUS current DESCRIPTION "A TAddress associated with this TDomain will be length 6: octets contents encoding Expires February 1997 [Page 4] INTERNET-DRAFT AgentX MIB August 1996 1-4 IP-address network-byte order 5-6 TCP-port network-byte order " ::= { axObjectIdentities 1 } axObjects OBJECT IDENTIFIER ::= { agentxMIB 2 } axGeneral OBJECT IDENTIFIER ::= { axObjects 1 } axMaxTimeout OBJECT-TYPE SYNTAX INTEGER (1..3600) -- 3600 seconds = 1 hour UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum amount of time (in seconds) that this agent allows for timeout values for subagents. This is the upper bound for axDefaultTimeout, axSATimeout and axRegTimeout. The agent may implement this object as read-only if it does not support user-specified timeouts. The agent may also support a more restricted upper bound for this object." DEFVAL { 60 } ::= { axGeneral 1 } axDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (1..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value that will be used for axSATimeout when a new subagent registers. This value must be less than axMaxTimeout. The agent may implement this object as read-only if it does not support user-specified timeouts." DEFVAL { 5 } ::= { axGeneral 2 } axDuplicateSAsAllowed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls whether multiple instances of the same type of subagent (as identified by axSAObjectID) are allowed. Setting this value to 'false(2)' will prevent new duplicate Expires February 1997 [Page 5] INTERNET-DRAFT AgentX MIB August 1996 subagent registrations. However, if any duplicates exist when the object is set, the agent will not remove them. (The manager may remove them by setting axSAOperStatus to 'down(2)'.)" DEFVAL { true } ::= { axGeneral 3 } axTotalPacketsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of AgentX packets received by the master agent from all subagents since the master agent was initialized. Note that this is not the sum of all current instances of axSAPacketsOut since some subagents may have unregistered." ::= { axGeneral 4 } axTotalPacketsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of AgentX packets sent from the master agent to all subagents since the master agent was initialized. Note that this is not the sum of all current instances of axSAPacketsIn since some subagents may have unregistered." ::= { axGeneral 5 } axMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. Current version is 1. Note that the master agent must allow registration of earlier version subagents." DEFVAL { 1 } ::= { axGeneral 6 } axMasterSnmpVer OBJECT-TYPE SYNTAX BITS { snmpv1(0), snmpv2c(1), snmpv2star(2), snmpv2u(3) } MAX-ACCESS read-only Expires February 1997 [Page 6] INTERNET-DRAFT AgentX MIB August 1996 STATUS current DESCRIPTION "The SNMP protocol versions that this master agent supports." ::= { axGeneral 7 } axMasterTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport domain of the axMasterTAddress." DEFVAL { agentxTcpDomain } ::= { axGeneral 8 } axMasterTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address on which the master agent listens for register/unregister protocol messages from subagents." -- DEFVAL { '??'h } -- 127.0.0.1:?? ::= { axGeneral 9 } axSubagentLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the axSubagentTable." ::= { axGeneral 10 } -- -- The AgentX Subagent Table -- axSubagentTable OBJECT-TYPE SYNTAX SEQUENCE OF AxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagents that are currently registered or were recently registered with this master agent." ::= { axObjects 2 } axSubagentEntry OBJECT-TYPE Expires February 1997 [Page 7] INTERNET-DRAFT AgentX MIB August 1996 SYNTAX AxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single subagent that is currently registered or was recently registered with the AgentX master agent." INDEX { axSAIndex } ::= { axSubagentTable 1 } AxSubagentEntry ::= SEQUENCE { axSAIndex INTEGER, axSAObjectID OBJECT IDENTIFIER, axSADescr DisplayString, axSAAdminStatus INTEGER, axSAOperStatus INTEGER, axSALastChange TimeStamp, axSAAgentXVer INTEGER, axSATDomain TDomain, axSATAddress TAddress, axSATimeout INTEGER, axSAPacketsIn Counter32, axSAPacketsOut Counter32 } axSAIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique, small-integer index for the subagent. Note that if a re-registers it will get a new index, therefore values of axSAIndex are not necessarily contiguous." ::= { axSubagentEntry 1 } axSAObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The type identification for the subagent. This is analogous to sysObjectID." ::= { axSubagentEntry 2 } axSADescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only Expires February 1997 [Page 8] INTERNET-DRAFT AgentX MIB August 1996 STATUS current DESCRIPTION "A textual description of the subagent. This should include a descriptive name and version identification." ::= { axSubagentEntry 3 } axSAAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. The only value that can be set by the manager is 'down(2)', which should cause the axSAOperStatus to transition to 'closedByManager(4)'. The value 'up(1)' cannot be set because, once the subagent is disconnected, it cannot be reconnected with the same axSAIndex." DEFVAL { up } ::= { axSubagentEntry 4 } axSAOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), connecting(2), disconnecting(3), closedByManager(4), closedByMasterAgent(5), closedBySubagent(6), closedBySubagentTimeout(7), closedBySubagentError(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the subagent. It is an implementation specific matter how long an entry that is in one of the closed states remains in the table, if it remains at all. However, since it is useful for troubleshooting to know the cause of a subagent disconnect, the agent implementor is encouraged to allow at least the last few entries that entered a closed state to remain in the table." ::= { axSubagentEntry 5 } Expires February 1997 [Page 9] INTERNET-DRAFT AgentX MIB August 1996 axSALastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time the value of axSAOperStatus changed." ::= { axSubagentEntry 6 } axSAAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This will be equal to or less than the value of axMasterAgentXVer." DEFVAL { 1 } ::= { axSubagentEntry 7 } axSATDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport domain for the subagent's AgentX transport address." ::= { axSubagentEntry 8 } axSATAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address on which this subagent listens for AgentX protocol messages." ::= { axSubagentEntry 9 } axSATimeout OBJECT-TYPE SYNTAX INTEGER (1..3600) MAX-ACCESS read-write STATUS current DESCRIPTION "The timeout (in seconds) for a subagent response. The initial value may have been specified by the subagent when it registered or it may have been the value of axDefaultTimeout at the time of registration. The manager can set this object to override the Expires February 1997 [Page 10] INTERNET-DRAFT AgentX MIB August 1996 value. However, note that a conformant agent is allowed to implement this object as read-only. This value must be less than axMaxTimeout." ::= { axSubagentEntry 10 } axSAPacketsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AgentX protocol messages received by this subagent from the master agent." ::= { axSubagentEntry 11 } axSAPacketsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AgentX protocol messages sent by this subagent to the master agent." ::= { axSubagentEntry 12 } -- -- The AgentX Registration Table -- axRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered OBJECT IDENTIFIER regions. Note that a subagent registration may be broken up into multiple entries in this table." ::= { axObjects 3 } axRegistrationEntry OBJECT-TYPE SYNTAX AxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single registered region. Regions are added by the master agent when subagents register and are removed from the table when subagents are removed from the axSubagentTable." INDEX { axRegIndex } ::= { axRegistrationTable 1 } Expires February 1997 [Page 11] INTERNET-DRAFT AgentX MIB August 1996 AxRegistrationEntry ::= SEQUENCE { axRegIndex INTEGER, axRegStart OBJECT IDENTIFIER, axRegEnd OBJECT IDENTIFIER, axRegPriority INTEGER, axRegContext OCTET STRING, axRegSAIndex INTEGER, axRegActive TruthValue, axRegTimeout INTEGER } axRegIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A small integer that uniquely identifies a registration entry." ::= { axRegistrationEntry 1 } axRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by axRegSAIndex implements objects starting at this value. Note that this value could identify an object type, an object instance, or a partial object instance identifier." ::= { axRegistrationEntry 2 } axRegEnd OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The ending OBJECT IDENTIFIER of this registration entry. The subagent identified by axRegSAIndex implements objects up to but not including this value Note that this value could identify an object type, an object instance, or a partial object instance identifier." ::= { axRegistrationEntry 3 } axRegPriority OBJECT-TYPE SYNTAX INTEGER (0..256) MAX-ACCESS read-write STATUS current Expires February 1997 [Page 12] INTERNET-DRAFT AgentX MIB August 1996 DESCRIPTION "The subagent's priority when exporting this MIB region. Lower values have higher priority. Note that conformant agents may not allow the manager to change the priority." DEFVAL { 10 } ::= { axRegistrationEntry 4 } axRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region." ::= { axRegistrationEntry 5 } axRegSAIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of axSAIndex for the subagent that registered this region." ::= { axRegistrationEntry 6 } axRegActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this region is active. The value 'true(1)' indicates that it is active. The value 'false(2)' indicates it is not active which could be because the subagent is in a closed state (but remains in the axSubagentTable) or that an identical region with a higher priority has been registered." ::= { axRegistrationEntry 7 } axRegTimeout OBJECT-TYPE SYNTAX INTEGER (1..3600) MAX-ACCESS read-write STATUS current DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this region. Initially, this will be the same value as axSATimeout. The upper bound is specified by axMaxTimeout. Note that a conformant agent is allowed to Expires February 1997 [Page 13] INTERNET-DRAFT AgentX MIB August 1996 implement this object as read-only. " DEFVAL { 5 } ::= { axRegistrationEntry 8 } -- -- Conformance Statements for the AgentX MIB -- axConformance OBJECT IDENTIFIER ::= { agentxMIB 3 } axMIBGroups OBJECT IDENTIFIER ::= { axConformance 1 } axMIBCompliances OBJECT IDENTIFIER ::= { axConformance 2 } axMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only." MODULE -- this module MANDATORY-GROUPS { axMIBGroup } OBJECT axMaxTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT axDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT axDuplicateSAsAllowed MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT axSAAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT axSATimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." Expires February 1997 [Page 14] INTERNET-DRAFT AgentX MIB August 1996 OBJECT axRegPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT axRegTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { axMIBCompliances 1 } axMIBGroup OBJECT-GROUP OBJECTS { axMaxTimeout, axDefaultTimeout, axDuplicateSAsAllowed, axTotalPacketsIn, axTotalPacketsOut, axMasterAgentXVer, axMasterSnmpVer, axMasterTDomain, axMasterTAddress, axSubagentLastChange, axSAObjectID, axSADescr, axSAAdminStatus, axSAOperStatus, axSALastChange, axSAAgentXVer, axSATDomain, axSATAddress, axSATimeout, axSAPacketsIn, axSAPacketsOut, axRegStart, axRegEnd, axRegPriority, axRegContext, axRegSAIndex, axRegActive, axRegTimeout } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB." ::= { axMIBGroups 1 } Expires February 1997 [Page 15] INTERNET-DRAFT AgentX MIB August 1996 END 4. Acknowledgments This document is a product of the IETF's AgentX Working Group. This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [7]. Expires February 1997 [Page 16] INTERNET-DRAFT AgentX MIB August 1996 5. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC, Cisco Systems, January 1996. [6] Kastenholz, F., "Definitions of Managed Objects for the Ethernet- like Interface Types using SMIv2", RFC1650, FTP Software, Inc, August 1994. [6] Daniele, M., Francisco, D., "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-00.txt, Digital Equipment Corporation, StrataCom, June, 1996. [7] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, Inc., May 1991. Expires February 1997 [Page 17] INTERNET-DRAFT AgentX MIB August 1996 6. Security Considerations Security issues are not discussed in this memo. 7. Author's Address Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720-4739 Phone: (508) 266-4570 EMail: greene@nexen.com 8. Issues Note: this section will be removed when this Internet-Draft becomes a Draft Standard RFC. 1. Is axDuplicateIDsAllowed needed? 2. Should the manager be allowed to disable a subagent? (Do we need axSAAdminStatus?) 3. Do we need to be able to override timeout for a particular registration? Is the timeout specification too complex? We could have just a single timeout value with a fixed upper bound. 4. Should the manager be allowed to unregister a region or change the priority? Expires February 1997 [Page 18] INTERNET-DRAFT AgentX MIB August 1996 Table of Contents 1 The SNMP Network Management Framework ........................ 2 1.1 Object Definitions ......................................... 2 2 Introduction ................................................. 3 3 Definitions .................................................. 4 4 Acknowledgments .............................................. 16 5 References ................................................... 17 6 Security Considerations ...................................... 18 7 Author's Address ............................................. 18 8 Issues ....................................................... 18 Expires February 1997 [Page 19]   Delivery-Date: Tue, 27 Aug 1996 10:54:32 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA25628 for X-agentx; Tue, 27 Aug 1996 10:54:32 -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 KAA25605 for ; Tue, 27 Aug 1996 10:54:23 -0700 (PDT) From: dfrancisco@stratacom.com Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA21561; Tue, 27 Aug 96 10:53:08 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA05014; Tue, 27 Aug 96 10:53:04 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA06614; Tue, 27 Aug 96 10:53:06 PDT Date: Tue, 27 Aug 96 10:53:06 PDT Message-Id: <9608271753.AA06614@santa.strata.com> To: greene@nexen.com Subject: Re: AgentX MIB Draft Cc: agentx@fv.com Maria, A question about the "optional" nature of your proposed AgentX MIB. You start by saying that "Support for the MIB module described in this memo is optional for AgentX master agents", and later say that the reason for this is that, in order to support the transparency requirement, "an SNMP manager should not need to be modified to be able to communicate with an AgentX agent". That sounds like a reason for not requiring that SNMP managers be cognizant of the AgentX MIB in order to interact successfully with an AgentX agent. If the information in the AgentX MIB is generally useful, and if there are, as yet, no AgentX master agents, shouldn't we make it a requirement that any AgentX master agent support this MIB? Dale   Delivery-Date: Tue, 27 Aug 1996 14:11:49 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA05697 for X-agentx; Tue, 27 Aug 1996 14:11:49 -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 OAA05684 for ; Tue, 27 Aug 1996 14:11:47 -0700 (PDT) From: dfrancisco@stratacom.com Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26581; Tue, 27 Aug 96 14:11:51 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA18860; Tue, 27 Aug 96 14:11:48 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA08343; Tue, 27 Aug 96 14:11:51 PDT Date: Tue, 27 Aug 96 14:11:51 PDT Message-Id: <9608272111.AA08343@santa.strata.com> To: agentx@fv.com Subject: Revised AgentX protocol draft to be posted I'm sending in a single following post a revision of the proposed AgentX Protocol internet draft. This revision contains changes proposed during the Montreal wg meeting, as well as changes by Mike Daniele as a result of his continuing work and discussion with other wg members. Please direct questions, comments, and suggested changes to the list (agentx@fv.com). Thanks, Dale Francisco Editor, AgentX WG dfrancisco@strata.com voice: (805) 961-3642 fax: (805) 961-3600 PS: Note on Document Format I've changed the running head that appears at the top of each page of the i-d into a non-IETF-standard form that I think will be more useful to us during the review and discussion process, and which can easily be changed before submitting to the i-d repository. The new running head format is: agentx protocol where "ver" is the version number, in the form "xx.yy", where xx is the number on the current draft in the i-d repository (major rev), and yy represents the level of incremental drafts since then (minor rev). Thus, right now, the version at InterNIC is "00" (the major rev number); and I'm calling this minor revision "03" ("01" was the last available update before Montreal; "02" was an interim version with rough draft changes after Montreal). So, the version number for this draft revision is "00.03". "date" is the date and time of last modification. Having a version and date at the top of every page should make it easier to tell if we're talking about the same document.   Delivery-Date: Tue, 27 Aug 1996 14:15:14 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA06460 for X-agentx; Tue, 27 Aug 1996 14:15:14 -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 OAA06290 for ; Tue, 27 Aug 1996 14:14:34 -0700 (PDT) From: dfrancisco@stratacom.com Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26628; Tue, 27 Aug 96 14:14:35 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA19115; Tue, 27 Aug 96 14:14:23 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA08355; Tue, 27 Aug 96 14:14:23 PDT Date: Tue, 27 Aug 96 14:14:23 PDT Message-Id: <9608272114.AA08355@santa.strata.com> To: agentx@fv.com Subject: AgentX protocol draft, ver 00.03 Agent Extensibility (AgentX) Protocol Version 1 Mike Daniele Digital Equipment Corporation daniele@zk3.dec.com Dale Francisco (editor) StrataCom dfrancisco@strata.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Daniele/Francisco Expires December 1996 [Page 1] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 Table of Contents 1 Introduction......................................................5 2 The SNMP Framework................................................5 2.1 A Note on Terminology.........................................5 3 Extending the MIB.................................................6 3.1 Motivation for AgentX.........................................6 3.2 Design Goals for AgentX.......................................7 4 AgentX Framework..................................................8 4.1 AgentX Roles..................................................8 5 AgentX Encodings..................................................9 5.1 ObjectIdentifiers............................................10 5.2 SearchRange..................................................11 5.3 Naming Scope.................................................12 5.4 Value Representation.........................................13 6 Protocol Definitions.............................................14 6.1 AgentX PDU Header............................................14 6.2 AgentX PDUs..................................................16 6.2.1 The agentx-Open-PDU......................................16 6.2.1.1 agentx-Open-PDU Fields...............................16 6.2.2 The agentx-Close-PDU.....................................17 6.2.2.1 agentx-Close-PDU Fields..............................17 6.2.3 The agentx-Register-PDU..................................18 6.2.3.1 agentx-Register-PDU Fields...........................19 6.2.4 The agentx-Unregister-PDU................................21 6.2.4.1 agentx-Unregister-PDU Fields.........................21 6.2.5 The agentx-Get-PDU.......................................22 6.2.6 The agentx-GetNext-PDU...................................23 6.2.7 The agentx-GetBulk-PDU...................................23 6.2.8 The agentx-Test-PDU......................................24 6.2.9 The agentx-Commit, -Undo, -Cleanup, and -Ping PDUs.....................................................25 6.2.10 The agentx-Notify-PDU...................................25 6.2.10.1 agentx-Notify-PDU Fields............................25 6.2.11 The agentx-Response-PDU.................................26 6.2.11.1 agentx-Response-PDU Fields..........................26 7 Elements of Procedure............................................26 7.1 Processing AgentX Administrative Messages....................26 7.1.1 Processing the agentx-Open-PDU...........................27 7.1.2 Processing the agentx-Register-PDU.......................27 7.1.2.1 Handling Duplicate OID Ranges........................29 7.1.3 Processing the agentx-Unregister-PDU.....................30 7.1.4 Processing the agentx-Close-PDU..........................31 7.1.5 Detecting Connection Loss................................31 7.1.6 Processing the agentx-Notify-PDU.........................31 Daniele/Francisco Expires December 1996 [Page 2] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 7.1.7 Processing the agentx-Ping-PDU...........................32 7.2 Processing Received SNMP Protocol Messages...................32 7.2.1 Dispatching AgentX PDUs..................................32 7.2.1.1 agentx-Get-PDU.......................................33 7.2.1.2 agentx-GetNext-PDU...................................34 7.2.1.3 agentx-GetBulk-PDU...................................35 7.2.1.4 agentx-Test-PDU......................................36 7.2.1.5 Dispatch.............................................36 7.2.2 Subagent Processing of agentx-GET, GetNext, GetBulk-PDUs.............................................37 7.2.2.1 Subagent Processing of the agentx-Get-PDU............37 7.2.2.2 Subagent Processing of the agentx-GetNext-PDU...................................38 7.2.2.3 Subagent Processing of the agentx-GetBulk-PDU...................................38 7.2.3 Subagent Processing of agentx-Test, -Commit, -Undo,...................................................39 7.2.3.1 Subagent Processing of the agentx-Test-PDU...........40 7.2.3.2 Subagent Processing of the agentx-Commit-PDU....................................40 7.2.3.3 Subagent Processing of the agentx-Undo-PDU...........40 7.2.3.4 Subagent Processing of the agentx-Cleanup-PDU...................................41 7.2.4 Master Agent Processing of AgentX Responses..............41 7.2.4.1 Common Processing of All AgentX Response PDUs.................................................41 7.2.4.2 Processing of Responses to agentx-Get-PDUs...........42 7.2.4.3 Processing of Responses to agentx-GetNext- and..................................42 7.2.4.4 Processing of Responses to agentx-Test-PDUs.....................................44 7.2.4.5 Processing of Responses to agentx-Commit-PDUs...................................45 7.2.4.6 Processing of Responses to agentx-Undo-PDUs.....................................45 7.2.5 Sending the SNMP Response-PDU............................45 7.2.6 MIB Views................................................46 8 Transport Mappings...............................................46 8.1 AgentX over TCP..............................................46 8.1.1 Well-known Values........................................46 8.1.2 Operation................................................46 8.2 AgentX over UNIX-domain Sockets..............................46 8.2.1 Well-known Values........................................47 8.2.2 Operation................................................47 9 Security Considerations..........................................47 10 Acknowledgements................................................48 Daniele/Francisco Expires December 1996 [Page 3] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 11 Questions and Issues............................................48 11.1 Design......................................................48 11.2 Miscellaneous Issues........................................50 12 References......................................................51 Daniele/Francisco Expires December 1996 [Page 4] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 1. Introduction This memo defines a framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. 2. The SNMP Framework A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. 2.1. A Note on Terminology The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [2] or the textual conventions based on the SMI [3]. The term "variable binding" normally refers to the pairing of the name of a variable and its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception. A variable-binding list is a simple list of variable bindings. The name of a variable is an OBJECT IDENTIFIER, which is the concatenation of the OBJECT IDENTIFIER of the corresponding object type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable. For the purpose of exposition, the original Internet-standard Daniele/Francisco Expires December 1996 [Page 5] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 Network Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1 framework (SNMPv1). The current framework, as described in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2). 3. Extending the MIB New MIB modules that extend the Internet-standard MIB are continuously being defined as the output of various IETF working groups. It is also common for enterprises or individuals to create or extend enterprise-specific or experimental MIBs. As a result, managed devices are frequently complex collections of manageable components that have been independently installed on a managed node. Each component provides instrumentation for the managed objects defined in the MIB module(s) it implements. Neither the SNMP version 1 or version 2 framework address how managed objects may be dynamically added to or removed from the agent view within a particular managed node. 3.1. Motivation for AgentX This very real need to dynamically extend the management objects within a node has given rise to a variety of "extensible agents", which typically comprise - a "master" agent that is available on the standard transport address and that accepts SNMP protocol messages - a set of "subagents" that each contain management instrumentation - a protocol that operates between the master agent and subagents, permitting subagents to "connect" to the master agent, and the master agent to multiplex received SNMP protocol messages amongst the subagents. - a set of tools to aid subagent development, and a runtime (API) environment that hides much of the protocol operation between a subagent and the master agent. The wide deployment of extensible SNMP agents, coupled with the lack of Internet standards in this area, makes it difficult to field SNMP-manageable applications. A vendor may have to support several different subagent environments (APIs) in order to support different target platforms. It can also become quite cumbersome to configure subagents and (possibly multiple) master agents on a particular managed node. Daniele/Francisco Expires December 1996 [Page 6] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 Specifying a standard protocol for agent extensibility (AgentX) provides the technical foundation required to solve both of these problems. Independently developed AgentX-capable master agents and subagents will be able to interoperate at the protocol level. Vendors can continue to differentiate their products in all other respects. 3.2. Design Goals for AgentX The primary goal of the design described in this memo is to minimize the latency associated with AgentX protocol operations above and beyond that already incurred for monolithic agents responding to similar management requests. In other words, minimize the response time and maximize the throughput of the extensible agent as perceived by SNMP manager entities. This goal is achieved primarily by minimizing the number of AgentX PDUs required to service an SNMP request. The elements of procedure are defined so that: - Except in rare cases, each requested variable binding is dispatched to only 1 subagent - All variable bindings targeted for a subagent are included in a single AgentX PDU sent to that subagent - Subagents return a single response PDU, which contains as much data as possible; its limits (for Next/Bulk) are its own size constraints, or the boundary of the lexicographically-next MIB region for which a different subagent is responsible - The master agent's bounding of acceptable returned variable binding names, and the SMI-consistency checking (for v2->v1 mapping) in the subagent, assure that the master will not have to resend PDUs For questions and open issues, see section 11 at the end of this memo. Daniele/Francisco Expires December 1996 [Page 7] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 4. AgentX Framework Within the SNMP framework, a managed node contains a processing entity, called an agent, which has access to management information. Within the AgentX framework, an agent is further defined to consist of - a single processing entity called the master agent, which sends and receives SNMP protocol messages in an agent role (as specified by the SNMP version 1 and version 2 framework documents) but typically has little or no direct access to management information. - 0 or more processing entities called subagents, which are "shielded" from the SNMP protocol messages processed by the master agent, but which have access to management information. The master and subagent entities communicate via AgentX protocol messages, as specified in this memo. Other interfaces (if any) on these entities, and their associated protocols, are outside the scope of this document. While some of the AgentX protocol messages appear similar in syntax and semantics to the SNMP, bear in mind that AgentX is not SNMP. The internal operations of AgentX are invisible to an SNMP entity operating in a manager role. To the manager, the agent behaves exactly as would a non-extensible (monolithic) agent that had access to the same management instrumentation. This transparency to managers is a fundamental requirement of AgentX, and is what differentiates AgentX subagents from SNMP proxy agents. 4.1. AgentX Roles An entity acting in a master agent role performs the following functions: - Accepts logical connection requests from subagents. - Accepts registration of MIB regions by subagents. - Sends and accepts SNMP protocol messages on the agent's specified transport addresses. - Implements the agent role Elements of Procedure specified for the administrative framework applicable to the SNMP protocol message, except where they specify performing management operations. (The application of MIB views, and the access Daniele/Francisco Expires December 1996 [Page 8] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 control policy for the managed node, are implemented by the master agent.) - Provides instrumentation for the MIB objects defined in [5], and for any MIB objects relevant to any administrative framework it supports. - Sends and receives AgentX protocol messages to access management information, based on the current registry of MIB regions. - Forwards notifications on behalf of subagents. An entity acting in a subagent role performs the following functions: - Initiates a logical connection with the master agent. - Registers MIB regions with the master agent. - Instantiates managed objects. - Binds MIB region OIDs (contained in AgentX protocol messages) to actual variable names. - Performs management operations on variables. - Initiates notifications. 5. AgentX Encodings AgentX PDUs consist of a common header, followed by PDU-specific data of variable length. The PDUs are not encoded using the BER [1], but are transmitted as a contiguous byte stream. The data within this stream is organized to provide natural alignment with respect to the start of the PDU, permitting direct (integer) access by the processing entities. Numeric data is encoded in network byte order (most significant byte first). PDUs are depicted in this memo using the following convention (where byte 1 is the first transmitted byte): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 1 | byte 2 | byte 3 | byte 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 5 | byte 6 | byte 7 | byte 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Daniele/Francisco Expires December 1996 [Page 9] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 5.1. ObjectIdentifiers Object identifiers are encoded with a 4-byte header, followed by a variable number of contiguous 4-byte sub-identifiers. This representation (termed ObjectIdentifier) is as follows: ObjectIdentifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ObjectIdentifier header fields: n_subid - The number (0-128) of sub-ids in the object identifier. An ordered list of `n_subid' 4-byte sub-ids follows the 4-byte header. A value of 0 indicates a null object identifier. prefix - An unsigned value used to reduce the length of object identifier encodings. A non-zero value x is interpreted as the first sub-id after `internet' (1.3.6.1), and indicates an implicit prefix 'internet.x' to the actual sub-ids encoded in the ObjectIdentifier. For example, a prefix field value '2' indicates an implicit prefix '1.3.6.1.2'. A value of 0 in the prefix field indicates there is no prefix to the sub-ids. include - Used only when the object identifier is part of a SearchRange. Daniele/Francisco Expires December 1996 [Page 10] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 Examples: sysDescr.0 (1.3.6.1.2.1.1.1.0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.9.9.9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. SearchRange A SearchRange consists of two ObjectIdentifiers. In its communication with a subagent, the master agent uses a SearchRange to identify a requested variable binding, and, in GetNext and GetBulk operations, to set an upper bound on the names of managed object instances the subagent may send in reply. The first object identifier (called the starting OID) indicates the beginning of the range. It is frequently (but not necessarily) the name of a requested variable binding. The `include' field in this OID's header is a boolean value indicating whether or not the starting OID is included in the range. The second object identifier indicates the non-inclusive end of the range. Daniele/Francisco Expires December 1996 [Page 11] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 Example: To indicate a search range from 1.3.6.1.2.1.25.2 (inclusive) to 1.3.6.1.2.1.25.2.1 (exclusive), the SearchRange would be (start) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 2 | 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (end) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SearchRangeList is a contiguous list of SearchRanges. 5.3. Naming Scope Naming scopes (contexts) are transferred as variable-length ASCII strings. When present, a naming scope string is always transmitted as the last item in a PDU, hence its size may be determined from the PDU size. Daniele/Francisco Expires December 1996 [Page 12] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 5.4. Value Representation Variable bindings may be transmitted within the variable-length portion of some PDUs. The representation of a variable binding (called a VarBind) consists of a 4-byte header, an ObjectIdentifier, the value data, and optional padding bytes as needed to achieve alignment on 4-byte boundaries: VarBind +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | v.size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (v.name) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (v.data) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v.type - Indicates the variable binding's syntax, and must be one of the following (SNMPv2 SMI) values: INTEGER (2), OCTET_STRING (4), OBJECT_IDENTIFIER (6), IpAddress (64), Counter32 (65), Gauge32 (66), TimeTicks (67), Opaque (68), Counter64 (70), noSuchObject (128), noSuchInstance (129), endOfMibView (130) Daniele/Francisco Expires December 1996 [Page 13] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 v.size - The number of bytes of data following the ObjectIdentifier. If this value is not zero or a multiple of 4, then 1 to 3 padding bytes are appended to the data to achieve 4-byte alignment. v.name - The ObjectIdentifier which names the variable. v.data - The actual value, encoded as follows: o 32-bit integers are 4-byte elements, MSB first. Example: '00000001'h represents 1. o 64-bit integers are 8-byte elements, MSB first. Example: '0000000100000001'h represents 4,294,967,297. o OBJECTIDENTIFIER data are represented as described in section 5.1. Note that v.size includes the size of the entire ObjectIdentifier (including the header). o IpAddress and Opaque are implicit OCTET_STRING, so they are octets (e.g. IpAddress in network byte order). o noSuchObject, noSuchInstance, are endOfMibView are implicit NULL and represented by v.size equal 0, and no data. A VarBindList is a contiguous list of VarBinds. 6. Protocol Definitions 6.1. AgentX PDU Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | h.type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h.length - The size in octets of the entire PDU, including the header. h.version - The version of the AgentX protocol (0 for this draft). Daniele/Francisco Expires December 1996 [Page 14] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 h.type - The PDU type; one of the following values: agentx-Open-PDU (1), agentx-Close-PDU (2), agentx-Register-PDU (3), agentx-Unregister-PDU (4), agentx-Get-PDU (5), agentx-GetNext-PDU (6), agentx-GetBulk-PDU (7), agentx-Test-PDU (8), agentx-Commit-PDU (9), agentx-Undo-PDU (10), agentx-Cleanup-PDU (11), agentx-Notify-PDU (12), agentx-Ping-PDU (13), agentx-Response-PDU (14) h.ID - A monotonically increasing packet id that should be kept unique by the sending entity, and that wraps if the maximum value is reached. h.flags - A bitmask, with bit 0 the leftmost bit. The bit definitions are as follows: Bit Definition --- ---------- 0 REG_INSTANCE 1 REG_UNION 2 REG_CLUSTER 3-4 reserved 5 CTX_ONE 6 CTX_ALL 7-8 reserved 9 IS_AGENT_CAP 10-12 reserved 13-15 unused h.snmp_version - The value of the version component of the received SNMP message. The subagent uses this value to interpret the contents of the Naming Scope field, and to bind SearchRanges to variables whose syntax is suitable to the SMI of that version. Daniele/Francisco Expires December 1996 [Page 15] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2. AgentX PDUs 6.2.1. The agentx-Open-PDU An agentx-Open-PDU is generated by a subagent to establish a logical connection with the master agent. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.timeout | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (o.id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subidentifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subidentifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.descr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.1.1. agentx-Open-PDU Fields o.timeout - The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a subagent-wide default value that may be overridden by values associated with specific registered MIB regions. The default value of 0 indicates no subagent-wide value is requested. o.id - An Object Identifier which identifies the subagent. If the IS_AGENT_CAP bit in h.flags is set, this value identifies an agent capabilities statement with respect to the MIB modules supported by the subagent. Otherwise it represents a unique (enterprise-specific) sysObjectID. Daniele/Francisco Expires December 1996 [Page 16] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 o.descr - An ASCII-encoded DisplayString describing o.id. 6.2.2. The agentx-Close-PDU an agentx-Close-PDU terminates a logical connection. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c.reason | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.2.1. agentx-Close-PDU Fields c.reason - An implementation-specific reason code. No values are specified by this memo. Daniele/Francisco Expires December 1996 [Page 17] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.3. The agentx-Register-PDU An agentx-Register-PDU is generated by a subagent for each region of the MIB variable naming tree (within one or more contexts) that it wishes to support. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.timeout | r.priority | r.range_subid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional upper-bound sub-identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional Naming Scope | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 18] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.3.1. agentx-Register-PDU Fields An agentx-Register-PDU contains the following fields: r.timeout - The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. r.timeout applies only to messages that concern MIB objects within r.region. It overrides both the subagent-wide value (if any) indicated when the logical connection with the master agent was established, and the master agent's default timeout. The default value for r.timeout is 0 (no override). r.priority - Used by cooperating subagents to achieve a desired configuration when registering identical or overlapping regions. The default value is 0 (no priority indicated). Higher numbers indicate higher priority. r.region - An ObjectIdentifier that, in conjunction with r.range_subid, indicates a region of the MIB that a subagent wishes to support. It may be a fully-qualified instance name, a partial instance name, a MIB table or group, or ranges of any of these. The choice of what to register is implementation-specific; this memo does not specify permissible values. Standard practice however is for a subagent to register at the highest level of the naming tree that makes sense. Registration of fully-qualified instances is typically done only when a subagent can perform management operations only on particular rows of a conceptual table. If r.region is in fact a fully qualified instance name, the REG_INSTANCE bit in h.flags must be set, otherwise it must be cleared. The master agent may save this information to optimize subsequent operational dispatching. r.range_subid - Permits specifying a range in place of one of r.region's sub-ids. If this value is 0, no range is specified. Otherwise the `r.range_subid'-th sub-identifier in r.region is a range lower bound, and the range upper bound sub-identifier (r.upper_bound) immediately follows r.region. Daniele/Francisco Expires December 1996 [Page 19] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 This permits registering a conceptual row with a single PDU. For example, the following PDU would register row 7 of the RFC 1573 ifTable (1.3.6.1.2.1.2.2.1.1-22.7): (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.priority | r.timeout | 5 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 2 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r.context - An optional NamingScope which may be specified by the subagent. This is present only when the CTX_ONE bit is set, and indicates r.region is to be registered only within r.context. Daniele/Francisco Expires December 1996 [Page 20] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.4. The agentx-Unregister-PDU The agentx-Unregister-PDU is sent by a subagent to remove a previously registered MIB region from the master agent's OID space. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u.reason | u.range_subid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (u.region) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (u.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional upper-bound sub-identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (u.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional Naming Scope | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.4.1. agentx-Unregister-PDU Fields An agentx-Unregister-PDU contains the following fields: - u.reason is a placeholder for implementation-specific data; no values are specified by this memo. - u.region indicates a previously-registered region of the MIB that a subagent no longer wishes to support. It may be a fully-qualified instance name, a partial instance name, a MIB Daniele/Francisco Expires December 1996 [Page 21] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 table or group, or ranges of any of these. - u.context is an optional NamingScope which may be specified by the subagent. This is present only when the CTX_ONE bit is set, and indicates r.region is to be unregistered only within r.context. 6.2.5. The agentx-Get-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (g.SearchRangeList) (start 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (end 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (g.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Daniele/Francisco Expires December 1996 [Page 22] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.6. The agentx-GetNext-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (g.SearchRangeList) ... (g.Context) ... 6.2.7. The agentx-GetBulk-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g.non_repeaters | g.max_repetitions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (g.SearchRangeList) ... (g.Context) ... Daniele/Francisco Expires December 1996 [Page 23] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.8. The agentx-Test-PDU (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (t.SearchRangeList) (VarBind 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | v.size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (VarBind n) (t.context) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Daniele/Francisco Expires December 1996 [Page 24] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.9. The agentx-Commit, -Undo, -Cleanup, and -Ping PDUs A agentx-Ping-PDU is sent by a subagent to test that the master agent is running and responding promptly. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | h.type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.10. The agentx-Notify-PDU An agentx-Notify-PDU is sent by a subagent to cause the master agent to forward a notification. (agentx header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (n.vblist) ... (n.context) ... 6.2.10.1. agentx-Notify-PDU Fields An agentx-Notify-PDU contains the following fields: n.vblist - A VarBindList whose contents define the actual PDU to be sent. This memo places the following restrictions on its contents: - snmpTrapOID.0 must be present - If sysUpTime.0 is not present, the master agent should supply a current value. n.context - An optional field which is used by the subagent to indicate a non-default context associated with the notification. Daniele/Francisco Expires December 1996 [Page 25] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 6.2.11. The agentx-Response-PDU +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.length | h.version | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.flags | h.snmp_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.error | res.index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (optional fields) 6.2.11.1. agentx-Response-PDU Fields res.error - Indicates error status (including 'noError'). Values are limited to those defined for errors and exceptions in the SNMPv2 SMI [4]. res.index - In error cases, this is the index of the failed variable binding within a received request PDU. Other data may follow these two fields, depending on which AgentX PDU is being responded to. These contents are specified in the subsequent elements of procedure. 7. Elements of Procedure This section describes the actions of protocol entities (master agents and subagents) implementing the AgentX protocol. Note, however, that it is not intended to constrain the internal architecture of any conformant implementation. The actions of AgentX protocol entities can be broadly categorized under two headings: (1) processing AgentX administrative messages (e.g, connection requests from a subagent to a master agent); and (2) processing SNMP messages (e.g., the coordinated actions of a master agent and one or more subagents in processing a received SNMP Get-PDU). 7.1. Processing AgentX Administrative Messages This subsection describes the actions of AgentX protocol entities in Daniele/Francisco Expires December 1996 [Page 26] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 processing AgentX administrative messages. Such messages include those involved in establishing and terminating a connection between a subagent and a master agent, and those by which a subagent communicates to a master agent which MIB regions it supports. 7.1.1. Processing the agentx-Open-PDU When the master agent receives an agentx-Open-PDU, it processes it as follows: 1) If a logical connection for this subagent has already been established (via an agentx-Open-PDU from the same transport endpoint), the PDU is ignored. 2) Otherwise, an agentx-Response-PDU is sent with the res.error field set to noError(0), and the 4-byte TimeTicks value of sysUpTime.0 within the default context, following the header. This indicates the establishment of a logical connection. If the IS_AGENT_CAP bit in h.flags is set, the data in o.id and o.descr must be represented as an entry in sysORTable from [5]. A warmStart trap is issued. 7.1.2. Processing the agentx-Register-PDU When the master agent receives an agentx-Register-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Characterize the request. If r.region (or any of its set of ObjectIdentifiers if r.range is non-zero) is exactly the same as any currently registered value of r.region (or any of its set of ObjectIdentifiers), this registration is termed a duplicate region. If r.region (or any of its set of ObjectIdentifiers if r.range is non-zero) is a subtree of, or contains, any currently registered value of r.region (or any of its set of ObjectIdentifiers), this registration is termed an overlapping region. If the CTX_ALL bit is set, this region is to be logically registered within all contexts known to the master agent. If the CTX_ONE bit is set, this region is to be logically registered within the single context r.context. Daniele/Francisco Expires December 1996 [Page 27] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 If neither bit is set this region is to be logically registered within the default context. A registration that would result in a duplicate region with the same priority and within an identical context (including the default) as a current registration, is termed a duplicate registration. 3) If either CTX bit is set, and the master agent supports only a default context, an agentx-Response-PDU is returned with res.error set to `genError'. 4) If this is a duplicate registration, and either of the following is true, an agentx-Response-PDU is returned with res.error set to `inconsistentValue': - This PDU's REG_UNION bit is not set. - The REG_UNION bit is not set for any current registration of which this registration is a duplicate. 5) Otherwise, an agentx-Response-PDU is returned with res.error set to `noError', and a 4-byte TimeTicks value following the header. The latter is the current value of sysUpTime.0 for either a specified non-default context (if the registration message so indicated), or for the default context. The master agent adds this region to its registered OID space for the indicated context(s), to be considered during the dispatching phase for subsequently received SNMP protocol messages. NOTE: The following algorithm describes maintaining a set of OID ranges derived from "splitting" registered regions. The algorithm for operational dispatching is also stated in terms of these OID ranges. These OID ranges are a useful explanatory device, but are not required for a correct implementation. - If r.region (R1) is a subtree of a currently registered region (R2), split R2 into 3 new regions (R2a, R2b, and R2c) such that R2b is an exact duplicate of R1. Now remove R2 and add R1, R2a, R2b, and R2c to the master agent's lexicographically ordered set of ranges (the registered OID space). Note: Though newly-added ranges R1 and R2b are identical in terms of the MIB objects they contain, they are registered by different subagents, possibly at different priorities. For instance, if subagent S2 registered `ip' (R2 is 1.3.6.1.2.1.4) and subagent S1 subsequently registered `ipNetToMediaTable' (R1 is 1.3.6.1.2.1.4.22), the resulting set of registered regions would be: Daniele/Francisco Expires December 1996 [Page 28] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) - If r.region (R1) overlaps one or more currently registered regions, then for each overlapped region (R2) split R1 into 3 new ranges (R1a, R1b, R1c) such that R1b is an exact duplicate of R2. Add R1b and R2 into the lexicographically ordered set of regions. Apply (5) above iteratively to R1a and R1c (since they may overlap, or be subtrees of, other regions). For instance, given the currently registered regions in the example above, if subagent S3 now registers mib-2 (R1 is 1.3.6.1.2.1) the resulting set of regions would be: 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3) Note that at registration time a region may be split into multiple OID ranges due to pre-existing registrations, or as a result of any subsequent registration. This region splitting is transparent to subagents. Hence the master agent must always be able to associate any OID range with the information contained in its original agentx-Register-PDU. 7.1.2.1. Handling Duplicate OID Ranges As a result of this registration algorithm there are likely to be duplicate OID ranges (regions of identical MIB objects registered to different subagents) in the master agent's registered OID space. Whenever the master agent's dispatching algorithm (see 7.2.1, Dispatching AgentX PDUs) selects a duplicate OID range, the determination of which one to use proceeds as follows: 1) Choose the one whose original agentx-Register-PDU r.region contained the most subids, i.e., the most specific r.region. Note: The presence or absence of a range subid has no bearing on how "specific" one ObjectIdentifier is compared to another. 2) If still ambiguous, there were duplicate regions. Choose the one whose original agentx-Register-PDU specified the highest Daniele/Francisco Expires December 1996 [Page 29] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 priority. 3) If still ambiguous, there were duplicate registrations. In this case, requests for objects within this OID range must be dispatched (at least initially) to all subagents who have registered the duplicate region. NOTE: This case may cause serious performance penalties during operational dispatching. The REG_UNION bit should be clear for all but the most unwieldy subagent configurations. It is almost always possible to use the indexing structure of conceptual tables to provide unique registrations among subagents sharing the implementation of such tables, and that is the preferred configuration. For example, a subagent "responsible" for a particular interface whose ifIndex is n, should register a specific conceptual row of ifTable (`ifEntry'.1-22.n), not `ifTable'. If this subagent also implements ipNetToMediaTable, it should register `ipNetToMediaEntry'.n.1-4, not `ipNetToMediaTable'. If it implements tcpConnTable, it should register `tcpConnEntry.a.b.c.d.1-5, where a.b.c.d is an IP address for the interface, not `tcpConnTable', etc. 7.1.3. Processing the agentx-Unregister-PDU 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) If the combination of u.region, the CTX bits, and the optional u.context do not match an existing registration, an agentx-Response-PDU is returned with res.error set to 'inconsistentValue'. 3) Otherwise, an agentx-Response-PDU is sent in reply with res.error set to `noError'. The master agent removes u.region from its registered OID space within the indicated context(s). If the original region had been split, all such related regions are removed. If this removal results in any contiguous OID ranges that share a common original agentx-Register-PDU, they are agglomerated into a single OID range. For instance, given the example registry above, if subagent S2 unregisters `ip', the resulting registry would be: Daniele/Francisco Expires December 1996 [Page 30] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3) and after agglomeration; 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4.22 (by S3) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.2 (by S3) sysORTable is updated to reflect the change in configuration, and a warmStart trap is issued. 7.1.4. Processing the agentx-Close-PDU When the master agent receives an agentx-Close-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Otherwise, the master agent dissolves the logical connection as described below. No agentx-Response-PDU is sent. - All MIB regions that have been registered by this subagent are unregistered, as described in 7.1.3. (Note: In this case a single warmStart trap is issued, not one per registered region.) When a subagent receives an agentx-Close-PDU, it must reestablish a logical connection and reregister its MIB regions. 7.1.5. Detecting Connection Loss If a master agent is able to detect (from the underlying transport) that a subagent cannot receive AgentX PDUs, it should dissolve the logical connection as described in 7.1.4, step (2). 7.1.6. Processing the agentx-Notify-PDU A subagent sending SNMPv1 trap information must map this into (minimally) a value of snmpTrapOID.0, as described in 3.1.2 of [8]. When the master agent receives an agentx-Notify-PDU, it processes it as follows: Daniele/Francisco Expires December 1996 [Page 31] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) The VarBindList is parsed. 3) Notifications are sent according to the implementation-specific configuration of the master agent. If SNMPv1 Trap PDUs are generated, the recommended mapping is as described in [9]. No agentx-Response-PDU is sent. 7.1.7. Processing the agentx-Ping-PDU When the master agent receives an agentx-Ping-PDU, it processes it as follows: 1) If a logical connection for this subagent has not been established (via an agentx-Open-PDU), the PDU is ignored. 2) Otherwise, an agentx-Response-PDU is sent, whose res.error field is noError(0), and containing no other data. 7.2. Processing Received SNMP Protocol Messages When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or SetRequest protocol message is received by the master agent, the master agent implements the access control policy. In particular, the master agent implements the Elements of Procedure defined in section 4.1 of [6] that apply to receiving entities. In the SNMPv1 or v2c frameworks, the master agent uses the community string as an index into a local repository of configuration information that may include community profiles or more complex context information. If application of the access control policy results in a valid SNMP request PDU, then an SNMP Response-PDU is constructed from information gathered in the exchange of AgentX PDUs between the master agent and one or more subagents. Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents, marshal the subagent responses, and construct an SNMP response PDU. 7.2.1. Dispatching AgentX PDUs Daniele/Francisco Expires December 1996 [Page 32] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents. Note: In the following procedures, an object identifier is said to be "contained" within an OID range when both of the following are true: - the object identifier does not lexicographically precede the range - the object identifier lexicographically precedes the end of the range 7.2.1.1. agentx-Get-PDU An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'noSuchObject'. Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range. Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate the region that contains the binding's name. (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`noSuchObject'). (3) Identify the subagent(s) responsible for this OID range, termed the target subagent(s). For each target subagent: (4) If this is the first variable binding to be dispatched to the target subagent, create an agentx-Get-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). (5) Add a SearchRange to the end of the target subagent's PDU for this variable binding. - The variable binding's name is encoded into the starting OID. - The ending OID is encoded as null. If the master agent has determined that a specific non-default Daniele/Francisco Expires December 1996 [Page 33] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 context is associated with the Request-PDU, that context is encoded into g.context. 7.2.1.2. agentx-GetNext-PDU An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'endOfMibView'. Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range. Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate a) the OID range that contains the variable binding's name and is not a fully qualified instance, or b) the OID range that is the first lexicographical successor to the variable binding's name. (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`endOfMibView'). (3) Identify the subagent(s) responsible for this OID range, termed the target subagent(s). For each target subagent: (4) If this is the first variable binding to be dispatched to the target subagent, create an agentx-GetNext-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). (5) Add a SearchRange to the end of the target subagent's agentx-GetNext-PDU for this variable binding. - if (1a) applies, the variable binding's name is encoded into the starting OID, and the OID's `include' field is set to 0. - if (1b) applies, the target OID is encoded into the starting OID, and its `include' field is set to 1. - the ending OID is encoded with the OID range that is the first lexicographical successor to the target OID range, and that was not registered by the target subagent. If no such OID range exists, it is encoded as a null OID. Daniele/Francisco Expires December 1996 [Page 34] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into g.context. 7.2.1.3. agentx-GetBulk-PDU (Note: The outline of the following procedure is based closely on section 4.2.3, "The GetBulkRequest-PDU" of [4]. Please refer to it for details on the format of the SNMP GetBulkRequest-PDU itself.) An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU. The SNMP Response-PDU contains N + (M * R) variable bindings whose values are set to `EndOfMibView', where N ("non-repeaters") is the minimum of: a) the value of the non-repeaters field in the request, and b) the number of variable bindings in the request M ("max-repetitions") is the value of the max-repetitions field in the request R ("repeaters") is the maximum of: a) (number of variable bindings in the request) - N, and b) zero Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range and target subagent(s), exactly as described for the agentx-GetNext-PDU (see 7.2.1.2). (2) If this is the first variable binding to be dispatched to the target subagent during the processing of this Request-PDU, create an agentx-GetBulk-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). Set g.non_repeaters to 0. g.max_repetitions is generally set to the max_repetitions value in the Request-PDU. However, the master agent may elect a smaller value based on the maximum possible size of a potential Response-PDU, known constraints of the AgentX transport, or any other implementation-specific constraint. (3) Add a SearchRange to the end of the target subagent's agentx-GetBulk-PDU for this variable binding, as described for the agentx-GetNext-PDU. If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. Daniele/Francisco Expires December 1996 [Page 35] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into g.context. 7.2.1.4. agentx-Test-PDU AgentX employs the well-known test-commit-undo-cleanup phases to achieve "as if simultaneous" semantics of the SNMP SetRequest-PDU within the extensible agent. The initial phase involves the agentx-Test-PDU. An SNMP Response-PDU is constructed whose fields all contain the same values as in the SNMP Request-PDU, except that the value of each variable binding is set to 'noSuchObject'. Each variable binding in the Request-PDU is processed in order, as follows: (1) Identify the target OID range. Within a lexicographically ordered set of OID ranges, valid for the indicated context, locate the range that contains the variable binding's name. (2) If no such OID range exists the variable binding is not processed further, and retains its initialized value (`noSuchObject'). (3) Identify the subagent(s) responsible for this OID range, termed the target subagent(s). For each target subagent: (4) If this is the first variable binding to be dispatched to the target subagent, create an agentx-Test-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). (5) Add a VarBind to the end of the target subagent's PDU for this variable binding, as described in section 5.4. If the master agent has determined that a specific non-default context is associated with the Request-PDU, that context is encoded into t.context. 7.2.1.5. Dispatch When all variable bindings have been processed, send any AgentX PDUs to their respective target subagents. Calculate a timeout value for each target subagent that is the maximum of: Daniele/Francisco Expires December 1996 [Page 36] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 - The master agent's default. - The subagent's default, as indicated by the subagent at connection establishment. - Any region-specific timeout values, as indicated by the subagent at registration. 7.2.2. Subagent Processing of agentx-GET, GetNext, GetBulk-PDUs When a subagent receives an agentx-Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns an agentx-Response-PDU. The agentx-Response-PDU header fields are identical to the received request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', res.error_index to 0, and the VarBindList to null. Each SearchRange in the request PDU is then processed in order, and a corresponding VarBind is added to the agentx-Response-PDU as described below. If processing should fail for any reason not described below, res.error is set to `genError', res.error_index to the index of the failed SearchRange, the VarBindList is reset to null, and this agentx-Response-PDU is returned to the master agent. 7.2.2.1. Subagent Processing of the agentx-Get-PDU Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in the request is processed in order as follows: 1) The starting OID is copied to v.name. 2) If the starting OID exactly matches the name of a variable instantiated by this subagent within the indicated context, v.type, v.length, and v.data are encoded to represent the variable's syntax and value, as described above (see 5.4, Value Representation). If the resulting VarBind's type is not compatible with the SMI for the SNMP framework of the version specified in h.snmp_version, v.type is set to `noSuchObject', and v.length to 0. 3) Otherwise, if the starting OID does not match the OBJECT IDENTIFIER PREFIX of any variable instantiated within the indicated context, v.type is set to `noSuchObject' and v.length to 0. 4) Otherwise, v.type is set to `noSuchInstance' and v.length to 0. Daniele/Francisco Expires December 1996 [Page 37] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 7.2.2.2. Subagent Processing of the agentx-GetNext-PDU Upon the subagent's receipt of an agentx-GetNext-PDU, each SearchRange in the request is processed in order as follows: 1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context, for which the following are all true: - if the `include' field of the starting OID is 0, the variable's name is the closest lexicographical successor to the starting OID. - if the `include' field of the starting OID is 1, the variable's name is either equal to, or the closest lexicographical successor to, the starting OID. - If the ending OID is not null, the variable's name lexicographically precedes the ending OID. - The variable's syntax is compatible with the SMI for the SNMP framework of the version specified in h.snmp_version. If all of these conditions are met, v.name is set to the located variable's name. v.type, v.length, and v.data are encoded to represent the variable's syntax and value, as described above (see 5.4, Value Representation). 2) If no such variable exists, v.name is set to the starting OID, v.type is set to `endOfMibView', and v.length to 0. 7.2.2.3. Subagent Processing of the agentx-GetBulk-PDU A maximum of N + (M * R) VarBinds are returned, where N equals g.non_repeaters, M equals g.max_repetitions, and R is (number of SearchRanges in the GETBULK request) - N. The first N SearchRanges are processed exactly as for the agentx-GetNext-PDU. If M and R are both non-zero, the remaining R SearchRanges are processed iteratively to produce potentially many VarBinds. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated SearchRange s, such that s is Daniele/Francisco Expires December 1996 [Page 38] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 greater than zero and less than or equal to R, the (N+((i-1)*R)+s)-th VarBind is added to the agentx-Response-PDU as follows: 1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context, for which the following are all true: - The variable's name is the (i)-th lexicographical successor to the (N+s)-th requested OID. (Note that if i is 0 and the `include' field is 1, the variable's name may be equivalent to, or the first lexicographical successor to, the (N+s)-th requested OID.) - If the ending OID is not null, the variable's name lexicographically precedes the ending OID. - The variable's syntax is compatible with the SMI for the SNMP framework of the version specified in h.snmp_version. If all of these conditions are met, v.name is set to the located variable's name. v.type, v.length, and v.data are encoded to represent the variable's syntax and value, as described above (see 5.4 Value Representation). 2) If no such variable exists, v.type is set to `endOfMibView' and v.length to 0. v.name is set to v.name of the (N+((i-2)*R)+s)-th VarBind unless i is currently 1, in which case it is set to the value of the starting OID in the (N+s)-th SearchRange. Note that further iterative processing should stop if - For any iteration i, all s values of v.type are `EndofMibView'. - An AgentX transport constraint or other implementation-specific constraint is reached. 7.2.3. Subagent Processing of agentx-Test, -Commit, -Undo, -Cleanup-PDUs These four PDUs are used to collectively perform the indicated management operation. An agentx-Response-PDU is sent in reply to each of the PDUs, to inform the master agent of the state of the operation. The agentx-Response-PDU header fields are identical to the received Daniele/Francisco Expires December 1996 [Page 39] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 request PDU except that, at the start of processing, the subagent initializes h.type to Response, res.error to `noError', res.error_index to 0, and the VarBindList to null. 7.2.3.1. Subagent Processing of the agentx-Test-PDU Upon the subagent's receipt of an agentx-Test-PDU, each VarBind in the PDU is validated until they are all successful, or until one fails, as described in section 4.2.5 of [4]. As a result of this validation step, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following (SNMPv2 SMI) values: noError (0), genErr (5), noAccess (6), wrongType (7), wrongLength (8), wrongEncoding (9), wrongValue (10), noCreation (11), inconsistentValue (12), resourceUnavailable (13), notWritable (17), inconsistentName (18) If this value is not noError(0), the res.index field must be set to the index of the VarBind for which validation failed. Full context for this operation must be maintained by the subagent. 7.2.3.2. Subagent Processing of the agentx-Commit-PDU The agentx-Commit-PDU indicates the subagent should actually perform the management operation indicated by the previous Test-PDU, as described in section 4.2.5 of [4]. As a result of this, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following (SNMPv2 SMI) values: noError (0), commitFailed (14) If this value is commitFailed(14), the res.index field must be set to the index of the VarBind for which the operation failed. Otherwise res.index is set to 0. Full context for this operation must be maintained by the subagent. 7.2.3.3. Subagent Processing of the agentx-Undo-PDU Daniele/Francisco Expires December 1996 [Page 40] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 The agentx-Undo-PDU indicates the subagent should undo the management operation indicated in the previous Commit-PDU, as described in section 4.2.5 of [4]. As a result of this, an agentx-Response-PDU is returned whose res.index field is set to 0, and whose res.error field is set to one of the following (SNMPv2 SMI) values: noError (0), undoFailed (15) This ends subagent processing of the management request. 7.2.3.4. Subagent Processing of the agentx-Cleanup-PDU The agentx-Cleanup-PDU indicates the end of processing of the management operation indicated in the previous Commit-PDU. No response is sent by the subagent. 7.2.4. Master Agent Processing of AgentX Responses The master agent now marshals all subagent agentx-Response-PDUs and builds an SNMP Response-PDU. In the next several sub-sections, the initial processing of all subagent agentx-Response-PDUs is described, followed by descriptions of subsequent processing for each Response type. 7.2.4.1. Common Processing of All AgentX Response PDUs If any SearchRange was sent to more than one subagent, the "best" response must be chosen. (Note: This could only have occurred if a requested variable binding fell within a duplicate OID range that was established via duplicate registrations, i.e., the REG_UNION bit was set.) During such processing, if the master agent discovers that multiple subagents instantiate the same MIB variable, a duplicateInstance notification should be generated as described in section [TBD]. Only a single such notification should be generated per duplicated OID range (not per duplicated instance) between reboots of the master agent. 1) If any subagent did not respond within its allotted time period, this is treated as if the subagent had returned `genError' and processed as described below. 2) Otherwise, if the h.ID field of an agentx-Response-PDU does not match that of the request PDU sent to this subagent, the PDU is Daniele/Francisco Expires December 1996 [Page 41] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 ignored. 3) Otherwise, the responses are processed jointly to form the SNMP Response-PDU. 7.2.4.2. Processing of Responses to agentx-Get-PDUs After common processing of the subagent's response to an agentx-Get-PDU (see 7.2.4.1 above), processing continues with the following steps: If any SearchRange was dispatched to multiple subagents: 1a) Any response whose corresponding VarBind contains data supersedes responses containing an error or whose corresponding VarBind contains an exception value. If multiple such "good" responses are received, the choice of which VarBind to use is implementation-specific. If all responses contain an error or exception value, the choice of which to use is implementation-specific. Alternately, if no SearchRange was dispatched to multiple subagents: 1b) For any received agentx-Response-PDU, if res.error is not `noError', the SNMP response PDU's error code is set to this value, and its error index to the index of the variable binding corresponding to the failed VarBind in the subagent's agentx-Response-PDU. All other agentx-Response-PDUs received due to processing this SNMP Request are ignored. Processing is complete; the SNMP Response-PDU is sent. 2) Otherwise, the content of each VarBind in the agentx-Response-PDU is used to update the corresponding variable binding in the SNMP Response-PDU. 7.2.4.3. Processing of Responses to agentx-GetNext- and agentx-GetBulk-PDUs After common processing of the subagent's response to an agentx-GetNext-PDU or agentx-GetBulk-PDU (see 7.2.4.1 above), Daniele/Francisco Expires December 1996 [Page 42] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 processing continues with the following steps: If any SearchRange was dispatched to multiple subagents: 1a) Any response whose corresponding VarBind contains data supersedes responses containing an error or whose corresponding VarBind contains an exception value. If multiple such "good" responses are received, the VarBind containing the lexicographically first value in v.name is chosen. If still ambiguous, the choice of which VarBind to use is implementation-specific. If all responses contain an error or exception value, the choice of which to use is implementation-specific. Alternately, if no SearchRange was dispatched to multiple subagents: 1b) For any received agentx-Response-PDU, if res.error is not `noError', the SNMP response PDU's error code is set to this value, and its error index to the index of the variable binding corresponding to the failed VarBind in the subagent's agentx-Response-PDU. All other agentx-Response-PDUs received due to processing this SNMP Request are ignored. Processing is complete; the SNMP Response PDU is sent. 2) Otherwise, the content of each VarBind in the agentx-Response-PDU is used to update the corresponding variable binding in the SNMP Response-PDU. After all expected agentx-Response-PDUs have been processed, if any variable bindings still contain the value `endOfMibView', processing must continue: 3) For each such variable binding, a target OID range is identified which is the lexicographical successor to the target OID range for this variable binding on the last iteration. The target subagent is the one that registered the target OID range. 4) If this is the first variable binding to be dispatched to the target subagent (during this iteration), create an agentx-GetNext or GetBulk-PDU for the subagent, with the header fields initialized as described above (see 6.1 AgentX PDU Header). 5a) For responses to agentx-GetNext-PDUs: Daniele/Francisco Expires December 1996 [Page 43] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 i) Add a SearchRange to the end of the target subagent's PDU for this variable binding. The starting OID is set to the target OID range, and its `include' field is set to 1. The ending OID is set to the OID range that is the first lexicographical successor to the target OID range, and that was not registered by the target subagent. If no such OID range exists, the ending OID is set to null. 5b) For responses to agentx-GetBulk-PDUs: i) Set the value of g.non_repeaters and g.max_repetitions to 0. ii) Add a SearchRange to the end of the target subagent's PDU for this variable binding. The starting OID is set to the target OID range, and its `include' field is set to 1. The ending OID is set to the OID range that is the first lexicographical successor to the target OID range, and that was not registered by the target subagent. If no such OID range exists, the ending OID is set to null. iii) If the variable binding was within the non_repeaters range in the original Request-PDU, increment the value of g.non_repeaters. Otherwise, set the value of g.max_repetitions to the maximum of its current value, or the number of response variable bindings still required for this requested variable binding. 6) The AgentX PDUs are sent to the subagent(s), and the responses are received and processed according to the steps described in section 7.2.4. 7) This process continues iteratively until a complete SNMP Response-PDU has been built, or until there remain no target OID range lexicographical successors. [Include examples, TBD] 7.2.4.4. Processing of Responses to agentx-Test-PDUs After common processing of the subagent's response to an agentx-Test-PDU (see 7.2.4.1 above), processing continues with the following steps: 1) If any VarBind was dispatched to multiple subagents, a subagent returning `noError' becomes the target subagent and continues to participate in subsequent processing. If multiple such "good" responses are received, the choice Daniele/Francisco Expires December 1996 [Page 44] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 of which subagent to use is implementation-specific. If all responses contain indicate an error, the choice of which to use is implementation-specific. 2) Otherwise, if any response is not `noError', all other agentx-Response-PDUs received due to processing this SNMP Request are ignored. An agentx-Cleanup-PDU is sent to each target subagent. Processing is complete; the SNMP Response-PDU is constructed as described below in 7.2.4.6, step (2). 3) Otherwise an agentx-Commit-PDU is sent to each target subagent. 7.2.4.5. Processing of Responses to agentx-Commit-PDUs After common processing of the subagent's response to an agentx-Commit-PDU (see 7.2.4.1 above), processing continues with the following steps: 1) If any response is not `noError', all other agentx-Response-PDUs received due to processing this SNMP Request are ignored. An agentx-Undo-PDU is sent to each target subagent. 2) Otherwise an agentx-Cleanup-PDU is sent to each target subagent. Processing is complete; the SNMP Response-PDU is constructed as described below in 7.2.4.6, step (2). 7.2.4.6. Processing of Responses to agentx-Undo-PDUs After common processing of the subagent's response to an agentx-Undo-PDU (see 7.2.4.1 above), processing continues with the following steps: 1) An agentx-Cleanup-PDU is sent to each target subagent. 2) If any response is not `noError' the SNMP response PDU's error code is set to this value, and its error index to the index of the variable binding corresponding to the failed VarBind in the agentx-Test-PDU. Otherwise the SNMP Response-PDU's error code is set to `noError' and its error index to 0. 7.2.5. Sending the SNMP Response-PDU Once the processing described in sections 7.2.1 - 7.2.3 is Daniele/Francisco Expires December 1996 [Page 45] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 complete, there is an SNMP Response-PDU available. The master agent now implements the Elements of Procedure for the applicable version of the SNMP protocol in order to encapsulate the PDU into a message, and transmit it to the originator of the SNMP management request. Note that this may involve altering the PDU contents for agents that support the SNMP version 1 framework. In such cases the recommended mapping is that defined in [9]. 7.2.6. MIB Views AgentX subagents are not aware of MIB views, since view information is not contained in AgentX PDUs. As stated above, the descriptions of procedures in section 7 of this memo are not intended to constrain the internal architecture of any procedures described in sections 7.2.1 and 7.2.3 may be altered so as to optimize AgentX exchanges when implementing MIB views. Such optimizations are beyond the scope of this memo. But note that section 7.2.3 defines subagent behavior in such a way that alteration of SearchRanges may be used in such optimizations. 8. Transport Mappings The same AgentX PDU formats, encodings, and elements of procedure are used regardless of the underlying transport. 8.1. AgentX over TCP 8.1.1. Well-known Values The master agent accepts TCP connection requests for the well-known port [TBD]. Subagents connect to the master agent using this port number. 8.1.2. Operation Once a TCP connection has been established, the AgentX peers use this connection to carry all AgentX PDUs. Only a single logical connection may be established per transport connection. All AgentX PDUs are presented individually to the TCP, to be sent as the data portion of a TCP PDU. 8.2. AgentX over UNIX-domain Sockets Many (BSD-derived) implementations of the UNIX operating system support the UNIX pathname address family (AF_UNIX) for socket communications. This provides a convenient method of sending and Daniele/Francisco Expires December 1996 [Page 46] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 receiving datagrams (SOCK_DGRAM type) between processes on the same host. Mapping AgentX to this transport is useful for environments that - wish to guarantee subagents are running on the same managed node as the master agent - typically provide better performance than TCP or UDP, especially in the presence of heavy network I/O 8.2.1. Well-known Values A subagent creates a UNIX-domain socket endpoint called "/var/agentx/subagent", where is the textual representation of a unique identifier. The recommended value is (or is based on) the subagent's process identifier (e.g, "/var/agentx/subagent2133"). This is the subagent endpoint for all AgentX communication. The master agent creates a well-known UNIX-domain socket endpoint called "var/agentx/master". (It may create other, implementation-specific endpoints.) These endpoint names use the character set encoding native to the managed node, and represent UNIX-domain datagram sockets. 8.2.2. Operation All AgentX PDUs are sent as individual datagrams. The maximum length of AgentX PDUs when using this transport is 2048 octets. All PDUs originated by the subagent (Open, Close, Register, Unregister, Ping, Notify) are sent to the master agent's well-known endpoint. Only a single logical connection may be established (via sending the Open PDU) from a single subagent endpoint. All PDUs originated by the master agent (Close, Get, GetNext, GetBulk, Test, Commit, Undo, Cleanup, Response) are sent to the subagent endpoint used to initiate the logical connection. All PDUs sent by the subagent in response to a received PDU (Response) are sent to the endpoint that originated the received PDU. 9. Security Considerations This memo defines a protocol between two processing entities, one of which (the master agent) is also assumed to perform authentication of received SNMP requests and to control access to management Daniele/Francisco Expires December 1996 [Page 47] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 information. The master agent performs these security operations independently of the other processing entity (the subagent). Thus, security issues are outside the scope of this protocol definition. 10. Acknowledgements The initial draft of this memo was heavily influenced by the DPI 2.0 specification [7]. This document was produced by the IETF Agent Extensibility (AgentX) Working Group, and benefited especially from the contributions of the following working group members: Jeff Case, Maria Greene, Bob Natale, Randy Presuhn, Aleksey Romanov, and Bert Wijnen. 11. Questions and Issues 11.1. Design Here are some of the questions and issues (and some attempts at addressing them) that have arisen with regard to the concept of maximizing the number of varbinds in AgentX PDUs, as opposed to limiting each AgentX PDU to contain a single varbind: 1) Isn't this design harder to document and implement than, for example, one which limits each PDU to containing a single variable binding? It is somewhat more complex. But not greatly so, given that the master agent must distribute varbinds to multiple subagents anyway. An important note here is the assumption that these details of AgentX will not be made visible to subagent (end user) developers. Vendors typically ship API libraries which hide the protocol implementation and present a method routine interface. So for example, the fact that a particular AgentX request PDU is - a GetBulk with max repetitions == 10, - containing 7 variable bindings - all bounded by a different subagent's registration of (...), and Daniele/Francisco Expires December 1996 [Page 48] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 - made via SNMPv1, so object types (...) must be skipped would not be visible to the MIB implementor; they would be handled within the subagent library implementation of AgentX. 2) The multiple-varbind design requires more memory (stack, heap) in both the master agent and the subagent. It's not clear that the master agent will have a bigger memory load under the multiple-varbind design, since it needs to keep all varbinds around anyway. Yes, the subagent has potentially many varbinds concurrently instead of one. But this seems like the correct design trade-off. Note that for GetBulk (where this effect will be most dramatic), the subagent is permitted to return less than the requested number of varbinds. 3) As a result of its more complex design, the multiple-varbind design will require more code space. In at least one sample implementation, it works out to about 20 more lines of code in the subagent, which seems a tiny cost for a large performance win. It's probably more in the master (haven't checked the implementation carefully; it's somewhat harder to separate things out in the master agent). But given the inherent complexity of an extensible master agent, this additional code space seems like a small price to pay for the added functionality. 4) Maybe this is the wrong goal. Some "transports" are very fast; who cares how many transactions are required to service a request? This touches on the nature of AgentX. It had to be designed in part as interprocess communications, not simply a network protocol. This is why care is taken to achieve alignment of most structures on 4-byte offsets within the PDU, for instance. But it doesn't seem wise to assume the availability of particular mechanisms to carry AgentX (e.g., shared memory). Nor can we assume that the required transport mappings will be standardized, and that therefore the AgentX specification need not be concerned with performance. In other words, we need to try to make it work reasonably well even over TCP. Daniele/Francisco Expires December 1996 [Page 49] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 11.2. Miscellaneous Issues Below are several comments from Mike Daniele on various issues that remain to be resolved by the working group. For some of these he has proposed solutions. 1) How to transfer binary OIDs? A suggested shorthand is included in this version of this memo (specifying a prefix, etc.) There wasn't much feedback on the list; it's not something I view as critical. Just seems like an easy way to save some space. Additionally, the "RangeSpecifier" encoding was removed. Since OIDs with subid ranges are only permitted in Register and Unregister PDUs, the OID range stuff is defined there. 2) Unionized registrations We never got a real example of where this is absolutely necessary. But it seems to be something that will help integrate random subagents. So I've included it in the spec, while simultaneously trying hard to discourage its use... 3) Contexts Last version would not support v2*. This version includes bits in the h.flags field to differentiate "all", "default", or "specific". 4) sysUpTime Is returned with the response to an Open or Register PDU. 5) sysORTable An OID and display string are passed in the Open PDU, and a h.flags bit defines if these represent an agent capabilities. This means the level of granularity is the subagent (Open/close), not registration. May be too high, but at least it's simple. This mechanism is also the implied way to handle counter discontinuities... 6) SNMP version in the AgentX header I know may of you feel this reeks. But there were at least three implementors in Montreal who said it needs to be there. I'm hoping folks will think about it a bit more, possibly in Daniele/Francisco Expires December 1996 [Page 50] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 conjunction with the background design discussion, and also in light of recent postings to the SNMPv2 list... 7) Options The only optional behavior permitted (or at least intended) is that a master agent may not support non-default context. 8) Index reservation Hopefully will be forthcoming after this version of the i-d settles out. It should NOT effect anything in this spec. 9) States Do we need to specify protocol states? Some are implied by elements of procedure (can't register before open, etc.). Perhaps specifying that Test/Commit/Undo/cleanup must finish before other requests are forwarded to a subagent? 12. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. Daniele/Francisco Expires December 1996 [Page 51] agentx protocol 00.03 Tue Aug 27 13:27:59 PDT 1996 [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters, "Simple Network Management Protocol: Distributed Protocol Interface, Version 2.0", RFC 1592, T.J. Watson Research Center, IBM Corp., Bell Northern Research, Ltd., March 1994. [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [9] Wijnen, B., and Levi, D., "V2ToV1: Mapping SNMPv2 onto SNMPv1 Within a Bilingual SNMP Agent", FYI ???, T.J. Watson Research Center, IBM Corp., SNMP Research, Inc., August 1996. Daniele/Francisco Expires December 1996 [Page 52]   Delivery-Date: Tue, 27 Aug 1996 15:19:48 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA19647 for X-agentx; Tue, 27 Aug 1996 15:19:48 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id PAA19640 for ; Tue, 27 Aug 1996 15:19:46 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id SAA12319 for ; Tue, 27 Aug 1996 18:19:49 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id SAA18190 for ; Tue, 27 Aug 1996 18:16:02 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id SAA07081; Tue, 27 Aug 1996 18:21:44 -0400 (EDT) Date: Tue, 27 Aug 1996 18:21:44 -0400 (EDT) From: Maria Greene Message-Id: <199608272221.SAA07081@avalon.nexen.com> To: agentx@fv.com Subject: Re: AgentX MIB Draft >>>>> On Tue, 27 Aug 96 10:53:06 PDT, dfrancisco@stratacom.com said: > Maria, Hi, Dale. > A question about the "optional" nature of your > proposed AgentX MIB. You start by saying that > "Support for the MIB module described in this memo > is optional for AgentX master agents", and later > say that the reason for this is that, in order to > support the transparency requirement, "an SNMP manager > should not need to be modified to be able to communicate > with an AgentX agent". > That sounds like a reason for not requiring that > SNMP managers be cognizant of the AgentX MIB in order > to interact successfully with an AgentX agent. Right. That is what I was trying to say. For example, a MIB browser application written years ago should be able to browse an agent implemented using the AgentX protocol. > If > the information in the AgentX MIB is generally useful, > and if there are, as yet, no AgentX master agents, > shouldn't we make it a requirement that any AgentX master > agent support this MIB? I would have no objection to this. However, I believe an AgentX implementation is useful without support for this MIB. Many of us have been using AgentX-like systems for years without the benefit of MIB visibility into the "plumbing". The argument could be made that this MIB is most useful for agent developers and not for end users. Since it takes memory and cycles (development and CPU) to implement, some developers, especially those for embedded devices, might choose not to support it even if the "instrumentation" is there in the master agent. However, that said, I believe that since it is useful in some cases, all AgentX master agent vendors should have a standard MIB available to implement and not invent many proprietary versions of the same thing. > Dale Maria ________________________________________________________________________ Maria N. Greene greene@nexen.com Ascom Nexion 289 Great Rd., Acton MA 01720 USA +1 508 266-4570   Delivery-Date: Wed, 28 Aug 1996 12:39:41 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id MAA07792 for X-agentx; Wed, 28 Aug 1996 12:39:40 -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 MAA07781 for ; Wed, 28 Aug 1996 12:39:35 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA26766; Wed, 28 Aug 1996 15:30:33 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA00213; Wed, 28 Aug 1996 15:30:32 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA13253; Wed, 28 Aug 1996 15:32:15 -0400 Message-Id: <9608281932.AA13253@bernie.zk3.dec.com> To: agentx@fv.com Subject: Comments on AgentX MIB draft Date: Wed, 28 Aug 96 15:32:14 -0400 From: Mike Daniele X-Mts: smtp Hi Maria, Thanks for producing the draft. >2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "master agent" and multiple "subagents". This is necessary because > there is only one well-known UDP port for SNMP (161) which can only > have one listener, but there are many vendors that may contribute > software which contains management instrumentation for a variety of > MIBs. Furthermore, these subagents may come and go over time as > hardware is installed and removed or as software is started and > stopped. I'd remove the explanatory text, hopefully we've got plenty of it in [6]. > The goals of the AgentX MIB are: ... > o Identify the set of MIB objects each subagent implements, the > context in which the objects are registered and the priority of > the registration. Specifying priority allows overlapping > registrations. I'd remove the last sentence, overlapping registration can occur without priority. > o Allow control of protocol operation parameters such as the > timeout interval for responses from a subagent. Hmmm... I don't understand the value of this. More below. > agentxTcpDomain OBJECT-IDENTITY Currently we also map to unix-domain sockets. > axMaxTimeout OBJECT-TYPE > axDefaultTimeout OBJECT-TYPE I suppose it's mildy interesting to view this information, but i don't see why it would be useful to make it writeable. If a subagent wishes to get around axDefault, it simply uses a different value during registration. > axDuplicateSAsAllowed OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object controls whether multiple instances of the same > type of subagent (as identified by axSAObjectID) are allowed. > Setting this value to 'false(2)' will prevent new duplicate > subagent registrations. However, if any duplicates exist when > the object is set, the agent will not remove them. (The manager > may remove them by setting axSAOperStatus to 'down(2)'.)" > DEFVAL { true } > ::= { axGeneral 3 } The i-d does not discuss duplicate values of the oids passed in OPEN and REGISTER pdus. I don't understand what the issue would be with duplicate oid values in general, but it doesn't make sense to have this knob when it's defined action isn't accounted for in the protocol spec. My vote would be to remove this object. > axMasterTDomain OBJECT-TYPE > axMasterTAddress OBJECT-TYPE Seems like it would be simpler to get well-known values assigned and list these in the protocol i-d. If we end up with > 1 transport mapping, and a master agent supports > 1, we could use a single BITS object in this mib to show which mappings are supported. > axMasterAgentXVer is currently 0 in the protocol i-d. > axSubagentEntry OBJECT-TYPE > SYNTAX AxSubagentEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single subagent that is currently > registered or was recently registered with the AgentX master > agent." > INDEX { axSAIndex } > ::= { axSubagentTable 1 } In the protocol i-d we reserve the term "register" for registering MIB regions. To be consistent this section should say seomthing like "a single subagent that has a current logical connection with the master ...". > axSAOperStatus OBJECT-TYPE > SYNTAX INTEGER { > up(1), > connecting(2), > disconnecting(3), > closedByManager(4), > closedByMasterAgent(5), > closedBySubagent(6), > closedBySubagentTimeout(7), > closedBySubagentError(8) > } The subagent's oid and descr are passed in the OPEN PDU, which if received and processed successfully, constitutes an established logical connection. While a TCP connection is being established, the OPEN couldn't have been sent. So I don't see why we need the connecting or disconnecting states. Also, the protocol i-d discusses the master detecting hard (transport) errors and closing a logical connection. But it doesn't prescribe doing that on timeouts. Even if it did, i don't think we need to differentiate the 2 conditions in this MIB, so suggest closedBySubagentError(7). > axSATDomain OBJECT-TYPE > axSATAddress OBJECT-TYPE The subagent could conceivably have > 1 Taddress per TDomain, and could also have > 1 TDomain. > axSATimeout OBJECT-TYPE > SYNTAX INTEGER (1..3600) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The timeout (in seconds) for a subagent response. The initial > value may have been specified by the subagent when it registered > or it may have been the value of axDefaultTimeout at the time of > registration. The manager can set this object to override the This object seems pointless given the existence of axRegTimeout, suggest removing it. > axRegistrationTable OBJECT-TYPE > SYNTAX SEQUENCE OF AxRegistrationEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of registered OBJECT IDENTIFIER regions. Note that a > subagent registration may be broken up into multiple entries in > this table." > ::= { axObjects 3 } Might wish to add something like "may be split into multiple entries in this table, as described in [6]". Also, it would be nice if this table sorted in lex order for atRegStart. Could we add text to the description mentining that a master should try to do so? (Can't really accomplish it by the INDEX clause i don't think.) Finally, what about registrations that specified a range subid (1.2.3.4-7.5)? We should probably add in the description that in such cases each individual oid derived from such a registration is represented by an entry in this table. > axRegPriority OBJECT-TYPE > SYNTAX INTEGER (0..256) > MAX-ACCESS read-write > STATUS current Is it really useful for this to be writeable? I don't see how. > axRegContext OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The context in which the subagent supports the objects in this > region." > ::= { axRegistrationEntry 5 } No can do. a region may have been registered in multiple (or all) contexts. Why is this different than any other context-specific data? Why not just let the axRegistrationTable be accessed in conjunction w/ a context, and only return those entries relevent to that context? The protocol i-d supports the notion of a virtual registry within a context. > axRegActive OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An indication of whether this region is active. The value > 'true(1)' indicates that it is active. The value 'false(2)' > indicates it is not active which could be because the subagent > is in a closed state (but remains in the axSubagentTable) or > that an identical region with a higher priority has been > registered." > ::= { axRegistrationEntry 7 } The description should simply define active (being dispatched to) and reference the selection algorithm in the protocol i-d. > axRegTimeout OBJECT-TYPE > SYNTAX INTEGER (1..3600) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The timeout value, in seconds, for subagent responses to > requests associated with this region. Initially, this will be > the same value as axSATimeout. The upper bound is specified by > axMaxTimeout. Note that a conformant agent is allowed to this description also should either reference or duplicate the discussion of timeout in the protocol i-d (region-specific beats subagent-specific beats master's default). Also, again I don't see the value in making this writeable. Cheers, Mike   Delivery-Date: Wed, 28 Aug 1996 14:02:38 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id OAA23663 for X-agentx; Wed, 28 Aug 1996 14:02:38 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id OAA23659 for ; Wed, 28 Aug 1996 14:02:37 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id RAA17666 for ; Wed, 28 Aug 1996 17:02:39 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id QAA08423 for ; Wed, 28 Aug 1996 16:58:45 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id RAA07902; Wed, 28 Aug 1996 17:04:38 -0400 (EDT) Date: Wed, 28 Aug 1996 17:04:38 -0400 (EDT) From: Maria Greene Message-Id: <199608282104.RAA07902@avalon.nexen.com> To: agentx@fv.com Subject: Re: Comments on AgentX MIB draft References: <9608281932.AA13253@bernie.zk3.dec.com> Hi, Mike. Good comments, thanks! I'll update the draft, posting questions back to the mailing list if I need clarifications. Maria >>>>> On Wed, 28 Aug 96 15:32:14 -0400, Mike Daniele said: Mike> Hi Maria, Mike> Thanks for producing the draft. >2. Introduction Mike> The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to Mike> distribute the implementation of an SNMP agent amongst a single Mike> "master agent" and multiple "subagents". This is necessary because > there is only one well-known UDP port for SNMP (161) which can only > have one listener, but there are many vendors that may contribute > software which contains management instrumentation for a variety of > MIBs. Furthermore, these subagents may come and go over time as > hardware is installed and removed or as software is started and > stopped.   Delivery-Date: Thu, 29 Aug 1996 15:40:55 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA10938 for X-agentx; Thu, 29 Aug 1996 15:40:55 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id PAA10915 for ; Thu, 29 Aug 1996 15:40:49 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id SAA26193 for ; Thu, 29 Aug 1996 18:40:51 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id SAA24368 for ; Thu, 29 Aug 1996 18:36:49 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id SAA09248; Thu, 29 Aug 1996 18:42:49 -0400 (EDT) Date: Thu, 29 Aug 1996 18:42:49 -0400 (EDT) From: Maria Greene Message-Id: <199608292242.SAA09248@avalon.nexen.com> to: agentx@fv.com Subject: Re: Comments on AgentX MIB draft References: <9608281932.AA13253@bernie.zk3.dec.com> >>>>> On Wed, 28 Aug 96 15:32:14 -0400, Mike Daniele said: > Hi Maria, Hi, Mike. > Thanks for producing the draft. You're welcome. I've done an update incorporating the feedback I've received so far. I'm doing one more pass comparing it to the 00.03 protocol i-d. I'll forward it to Dale for a "once over" soon. >2. Introduction > The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to > distribute the implementation of an SNMP agent amongst a single > "master agent" and multiple "subagents". This is necessary because > there is only one well-known UDP port for SNMP (161) which can only > have one listener, but there are many vendors that may contribute > software which contains management instrumentation for a variety of > MIBs. Furthermore, these subagents may come and go over time as > hardware is installed and removed or as software is started and > stopped. > I'd remove the explanatory text, hopefully we've got plenty of > it in [6]. Agreed. Removed. I also reworded the following paragraph (about why MIB is opitional) based on Dale's comments. What do you think of this wording? Support for the MIB module described in this memo is optional for AgentX master agents. The optional designation is somewhat unusual for SNMP MIB modules. The rationale is that AgentX SNMP agents are useful without support for this MIB since the manager need not be and generally is not aware that it is communicating with an AgentX SNMP agent. However, lack of visibility into the run-time configuration could hinder trouble shooting. Therefore, if an AgentX master agent implementation chooses to export management information, this memo defines a standard MIB for the protocol. Or, perhaps: Support for the MIB module described in this memo is mandatory for all AgentX master agents. I added this as Issue #5. Opinions? > The goals of the AgentX MIB are: > ... > o Identify the set of MIB objects each subagent implements, the > context in which the objects are registered and the priority of > the registration. Specifying priority allows overlapping > registrations. > I'd remove the last sentence, overlapping registration can occur without > priority. Done. > o Allow control of protocol operation parameters such as the > timeout interval for responses from a subagent. > Hmmm... I don't understand the value of this. More below. Agreed. Changed it to: Determine protocol operational parameters such as the timeout interval for responses from a subagent. > agentxTcpDomain OBJECT-IDENTITY > Currently we also map to unix-domain sockets. OK. This OBJECT-IDENTITY was removed, however, based on the suggestion to change the supported transport info. to a bit mask. See below. > axMaxTimeout OBJECT-TYPE > axDefaultTimeout OBJECT-TYPE > I suppose it's mildy interesting to view this information, > but i don't see why it would be useful to make it writeable. > If a subagent wishes to get around axDefault, it simply uses a > different value during registration. Agreed. Some of this stuff is hold-over from the original Subagent MIB. Hey, Bert, have any users of that MIB found it useful/necessary? I removed axMaxTimeout and made axDefaultTimeout read-only. What is the recommended default value for axDefaultTimeout (if any)? The protocol i-d doesn't say. It seems to me that if the subagent is allowed to override it (subagent-wide or per registration) it should know what the value would be if it didn't. > axDuplicateSAsAllowed OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object controls whether multiple instances of the same > type of subagent (as identified by axSAObjectID) are allowed. > Setting this value to 'false(2)' will prevent new duplicate > subagent registrations. However, if any duplicates exist when > the object is set, the agent will not remove them. (The manager > may remove them by setting axSAOperStatus to 'down(2)'.)" > DEFVAL { true } > ::= { axGeneral 3 } > The i-d does not discuss duplicate values of the oids passed in > OPEN and REGISTER pdus. I don't understand what the issue would > be with duplicate oid values in general, but it doesn't make > sense to have this knob when it's defined action isn't accounted > for in the protocol spec. > My vote would be to remove this object. It's gone! > axMasterTDomain OBJECT-TYPE > axMasterTAddress OBJECT-TYPE > Seems like it would be simpler to get well-known values assigned > and list these in the protocol i-d. If we end up with > 1 > transport mapping, and a master agent supports > 1, we could use > a single BITS object in this mib to show which mappings are > supported. Good idea. It's now a BITS construct. > axMasterAgentXVer > is currently 0 in the protocol i-d. OK, changed. > axSubagentEntry OBJECT-TYPE > SYNTAX AxSubagentEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single subagent that is currently > registered or was recently registered with the AgentX master > agent." > INDEX { axSAIndex } > ::= { axSubagentTable 1 } > In the protocol i-d we reserve the term "register" for > registering MIB regions. To be consistent this section should > say seomthing like "a single subagent that has a current logical > connection with the master ...". Oops, I knew that. I think I've cleaned up all of these. > axSAOperStatus OBJECT-TYPE > SYNTAX INTEGER { > up(1), > connecting(2), > disconnecting(3), > closedByManager(4), > closedByMasterAgent(5), > closedBySubagent(6), > closedBySubagentTimeout(7), > closedBySubagentError(8) > } > The subagent's oid and descr are passed in the OPEN PDU, > which if received and processed successfully, constitutes > an established logical connection. > While a TCP connection is being established, the OPEN couldn't > have been sent. So I don't see why we need the connecting or > disconnecting states. > Also, the protocol i-d discusses the master detecting hard > (transport) errors and closing a logical connection. But it > doesn't prescribe doing that on timeouts. Even if it did, i > don't think we need to differentiate the 2 conditions in this > MIB, so suggest closedBySubagentError(7). OK. I've changed up(1) to open(1) and removed connecting, disconnecting, and closedBySubagentTimeout. > axSATDomain OBJECT-TYPE > axSATAddress OBJECT-TYPE > The subagent could conceivably have > 1 Taddress per TDomain, and > could also have > 1 TDomain. True. I removed these objects because I think their value is not high enough to make a (doubly-indexed) table of them. Any objections? > axSATimeout OBJECT-TYPE > SYNTAX INTEGER (1..3600) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The timeout (in seconds) for a subagent response. The initial > value may have been specified by the subagent when it registered > or it may have been the value of axDefaultTimeout at the time of > registration. The manager can set this object to override the > This object seems pointless given the existence of axRegTimeout, > suggest removing it. Hmm. It's in the open PDU. Do you want to remove it altogether or just make it read-only? > axRegistrationTable OBJECT-TYPE > SYNTAX SEQUENCE OF AxRegistrationEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of registered OBJECT IDENTIFIER regions. Note that a > subagent registration may be broken up into multiple entries in > this table." > ::= { axObjects 3 } > Might wish to add something like "may be split into multiple entries > in this table, as described in [6]". Done. > Also, it would be nice if this table sorted in lex order for > atRegStart. Could we add text to the description mentining that > a master should try to do so? (Can't really accomplish it by > the INDEX clause i don't think.) We can recommend it. Indexing the table by the columns that make it unique would have meant an index clause with OID, OID, INTEGER, OCTET STRING, so I'm glad to see you agree it can't really be accomplished with the INDEX clause! The manager doesn't need to easily determine which subagent implements a particular OID (thank goodness, this is the job of the master agent), so I don't think this is a problem. > Finally, what about registrations that specified a range subid > (1.2.3.4-7.5)? We should probably add in the description that > in such cases each individual oid derived from such a > registration is represented by an entry in this table. Isn't this "described in [6]"? > axRegPriority OBJECT-TYPE > SYNTAX INTEGER (0..256) > MAX-ACCESS read-write > STATUS current > Is it really useful for this to be writeable? I don't see how. In Montreal I remember someone asking for this so that the administrator can override the subagent since it does not have the "big picture". Thoughts? > axRegContext OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The context in which the subagent supports the objects in this > region." > ::= { axRegistrationEntry 5 } > No can do. a region may have been registered in multiple (or > all) contexts. Empty string means all? > Why is this different than any other context-specific data? Why > not just let the axRegistrationTable be accessed in conjunction > w/ a context, and only return those entries relevent to that > context? > The protocol i-d supports the notion of a virtual registry > within a context. OK, if that's the way we want to handle it. I think context is a hack that confuses a lot of people, but I guess we're stuck with it. > axRegActive OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An indication of whether this region is active. The value > 'true(1)' indicates that it is active. The value 'false(2)' > indicates it is not active which could be because the subagent > is in a closed state (but remains in the axSubagentTable) or > that an identical region with a higher priority has been > registered." > ::= { axRegistrationEntry 7 } > The description should simply define active (being dispatched to) > and reference the selection algorithm in the protocol i-d. Maybe we should remove this object? I thought it might be useful for determining why a request isn't being dispatched to a particular subagent, but it may be too onerous to implement in the MA. > axRegTimeout OBJECT-TYPE > SYNTAX INTEGER (1..3600) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The timeout value, in seconds, for subagent responses to > requests associated with this region. Initially, this will be > the same value as axSATimeout. The upper bound is specified by > axMaxTimeout. Note that a conformant agent is allowed to > this description also should either reference or duplicate the > discussion of timeout in the protocol i-d (region-specific beats > subagent-specific beats master's default). > Also, again I don't see the value in making this writeable. OK, it's read-only. > Cheers, > Mike > We've taken care of my issues 1, 3, and 4. What about 2? Issues 2. Should the manager be allowed to disable a subagent? (Do we need axSAAdminStatus?) Maria   Delivery-Date: Fri, 30 Aug 1996 02:02:13 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id CAA00662 for X-agentx; Fri, 30 Aug 1996 02:02:12 -0700 (PDT) Received: from card.com (card.com [206.97.242.10]) by fv.com (8.7.4/8.7.3) with ESMTP id CAA00658 for ; Fri, 30 Aug 1996 02:02:11 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by card.com (8.7.4/8.7.3) with SMTP id EAA00958 for ; Fri, 30 Aug 1996 04:02:11 -0500 (CDT) Message-Id: <199608300902.EAA00958@card.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4646; Fri, 30 Aug 96 04:59:48 EDT Date: Fri, 30 Aug 96 10:59:57 DST From: "Bert Wijnen" To: greene@nexen.com, agentx@fv.com Subject: Comments on AgentX MIB draft Ref: Your note of Thu, 29 Aug 1996 18:42:49 -0400 (EDT) Subject: Comments on agentX MIB draft Maria discusses other comments: > I also reworded the following paragraph (about why MIB is > opitional) based on Dale's comments. What do you think of this > wording? > > Support for the MIB module described in this memo is optional for > AgentX master agents. The optional designation is somewhat unusual > for SNMP MIB modules. The rationale is that AgentX SNMP agents are > useful without support for this MIB since the manager need not be > and generally is not aware that it is communicating with an AgentX > SNMP agent. However, lack of visibility into the run-time > configuration could hinder trouble shooting. Therefore, if an > AgentX master agent implementation chooses to export management > information, this memo defines a standard MIB for the protocol. > > Or, perhaps: > > Support for the MIB module described in this memo is mandatory for > all AgentX master agents. > > I added this as Issue #5. > > Opinions? > I like the first wordin above describing that it is optional, explains why, and then states that if you want to give control over the internals of an agentX master agent then this is the way to do it. > > axMaxTimeout OBJECT-TYPE > > axDefaultTimeout OBJECT-TYPE > > > I suppose it's mildy interesting to view this information, > > but i don't see why it would be useful to make it writeable. > > > If a subagent wishes to get around axDefault, it simply uses a > > different value during registration. > > Agreed. Some of this stuff is hold-over from the original Subagent > MIB. Hey, Bert, have any users of that MIB found it useful/necessary? > > I removed axMaxTimeout and made axDefaultTimeout read-only. What is > the recommended default value for axDefaultTimeout (if any)? The > protocol i-d doesn't say. It seems to me that if the subagent is > allowed to override it (subagent-wide or per registration) it should > know what the value would be if it didn't. > I think we should do the axMax/DefaultTimeout as Maria initially described. In fact of all the saMIB items on which you based this MIB, these 2 timeout values seemed the most usefull in our experience. The axMaxTimeout is something that gives the master agent control over the ABSOLUTE max timeout anyone can use. A management station can change that value if it wants. The axDefaultTimeout is what the master agent uses if a subagent does not specifically specify a timeout value. I would suggest that subagents do ineed not specify a timeout value but leave it up to the master agent to use this default. Again in certain conditions, the master agents default might not be good enough, and by making it read-write a management station can change it if needed. I would also keep the timeout in the registration tree, so that timeout values can be used/minotored/changed per registration. Sometimes a subagent is very happy with the default timeout except for may be one variable which takes a long time t compute or figure out. I know that one of our FDDI subagent developers needed a 30 second timeout for one of the objects in the FDDI MIB (I don't recall right away which one) for which he had to go out on the ring and collect data which could take up to 30 seconds (he claimed). I claimed that the MIB was broken in this case.... but then it was a MIB that came from the IETF I beleieve... so such things exist. > OK. I've changed up(1) to open(1) and removed connecting, > disconnecting, and closedBySubagentTimeout. > I have found that closedBySubagentTimeout is the most possible reason why connections get closed (especially during testing when the subagent loops or something). So again I would keep this specific reason code. > Issues > > 2. Should the manager be allowed to disable a subagent? (Do we need > axSAAdminStatus?) > I would say YES. It is possible that some subagent misbehaves badly. So you would want the management station to be able to bump it. I have not checked all of the MIB yet, but in the last posting Maria was explicitly pooling me for comments. So I have addressed a few ones that were obvious to me right off the bat. Bert   Delivery-Date: Fri, 30 Aug 1996 03:13:02 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id DAA10832 for X-agentx; Fri, 30 Aug 1996 03:13:02 -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 DAA10782 for ; Fri, 30 Aug 1996 03:12:59 -0700 (PDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id MAA10527; Fri, 30 Aug 1996 12:12:24 +0200 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id MAA29278; Fri, 30 Aug 1996 12:12:23 +0200 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id MAA19724; Fri, 30 Aug 1996 12:12:22 +0200 Date: Fri, 30 Aug 1996 12:12:22 +0200 Message-Id: <199608301012.MAA19724@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: greene@nexen.com CC: agentx@fv.com In-reply-to: <199608292242.SAA09248@avalon.nexen.com> (message from Maria Greene on Thu, 29 Aug 1996 18:42:49 -0400 (EDT)) Subject: Re: Comments on AgentX MIB draft > I also reworded the following paragraph (about why MIB is > opitional) based on Dale's comments. What do you think of this > wording? > > Support for the MIB module described in this memo is optional for > AgentX master agents. The optional designation is somewhat unusual > for SNMP MIB modules. The rationale is that AgentX SNMP agents are > useful without support for this MIB since the manager need not be > and generally is not aware that it is communicating with an AgentX > SNMP agent. However, lack of visibility into the run-time > configuration could hinder trouble shooting. Therefore, if an > AgentX master agent implementation chooses to export management > information, this memo defines a standard MIB for the protocol. > > Or, perhaps: > > Support for the MIB module described in this memo is mandatory for > all AgentX master agents. I don't quite understand the problem. If I am going to implement a protocol (say OSPF), than there is no requirement to implement the corresponding MIB (OSPF MIB in this example). So why should there be a requirement to implement AgentX MIB when I implement the AgentX protocol? My understanding is that the implementation of a MIB for a protocol is always optional - we should not confuse this with optional parts in a MIB module. IMHO, a statement that the AgentX MIB is defined to manage an AgentX environment and that it is in no way required to use AgentX should be sufficient. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Delivery-Date: Fri, 30 Aug 1996 07:09:59 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA22032 for X-agentx; Fri, 30 Aug 1996 07:09:59 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA22029 for ; Fri, 30 Aug 1996 07:09:57 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA29781 for ; Fri, 30 Aug 1996 10:09:58 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA09497 for ; Fri, 30 Aug 1996 10:05:52 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id KAA09878; Fri, 30 Aug 1996 10:12:03 -0400 (EDT) Date: Fri, 30 Aug 1996 10:12:03 -0400 (EDT) From: Maria Greene Message-Id: <199608301412.KAA09878@avalon.nexen.com> To: agentx@fv.com Subject: Re: AgentX protocol draft, ver 00.03 References: <9608272114.AA08355@santa.strata.com> Dale and Mike, here are some comments on the draft. Most are real nits. Maria >>>>> On Tue, 27 Aug 96 14:14:23 PDT, dfrancisco@stratacom.com said: > 3.2. Design Goals for AgentX ... > - The master agent's bounding of acceptable returned > variable binding names, and the SMI-consistency checking (for > v2->v1 mapping) in the subagent, assure that the master > will not have to resend PDUs You might want to explicitly say "master will not have to resend AgentX PDUs" to distinguish them from SNMP PDUs. > 4. AgentX Framework ... > The internal operations of AgentX are invisible to an SNMP entity > operating in a manager role. To the manager, the agent behaves > exactly as would a non-extensible (monolithic) agent that had access > to the same management instrumentation. Nit: "agent behaves exactly as...agent that has access..." ^^^ > 4.1. AgentX Roles ... > - Sends and accepts SNMP protocol messages on the agent's > specified transport addresses. Specified where how? I'd suggest removing "specified". > 5.3. Naming Scope > Naming scopes (contexts) are transferred as variable-length ASCII > strings. When present, a naming scope string is always transmitted > as the last item in a PDU, hence its size may be determined from the > PDU size. I think you'd be better off just using context here (and not saying it's the same as a naming scope). What's the relationship between the context string that the subagent registers and the community string in an SNMPv1 or SNMPv2c PDU? > 5.4. Value Representation ... > o OBJECTIDENTIFIER data are represented as described in > section 5.1. Note that v.size includes the size of > the entire ObjectIdentifier (including the > header). Nit: OBJECT_IDENTIFIER > 6.2.1.1. agentx-Open-PDU Fields ... > o.id - An Object Identifier which identifies the subagent. If > the IS_AGENT_CAP bit in h.flags is set, this value > identifies an agent capabilities statement with respect > to the MIB modules supported by the subagent. Otherwise > it represents a unique (enterprise-specific) > sysObjectID. Huh?? Bert suggested taking the OID and Descr the subagent provides in the Open PDU and using them to populate the sysORTable. Is that what this is trying to say? But this IS_AGENT_CAP flag lets you override that? I would suggest renaming the bit SYS_OR_ENTRY. What does the "otherwise" statement mean? Does it mean that this is the value that the MA should use for sysObjectID? Since the MA implements the system group, that would make sense. > o.descr - An ASCII-encoded DisplayString describing o.id. Same comment applies here as with o.id. Is this the value used to populate sysORTable.sysORDescr or sysDescr, depending on the value of the flag? > 6.2.3.1. agentx-Register-PDU Fields ... > r.region - An ObjectIdentifier that, in conjunction with > r.range_subid, indicates a region of the MIB that a > subagent wishes to support. It may be a fully-qualified > instance name, a partial instance name, a MIB table or > group, or ranges of any of these. I think "group" here is confusing. You don't mean the OID of an OBJECT-GROUP macro. You mean an OBJECT IDENTIFIER that a node in the naming tree that's not an OBJECT-TYPE. > (r.region) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 6 | 2 | 0 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Unless I'm confused, the first byte in r.region should be 4. > 8.2.1. Well-known Values ... > A subagent creates a UNIX-domain socket endpoint called > "/var/agentx/subagent", where is the textual representation > of a unique identifier. The recommended value is (or is based on) > the subagent's process identifier (e.g, > "/var/agentx/subagent2133"). Isn't there a length limit on these (16 characters?) You might want to keep the important part () closer to the beginning. > 11. Questions and Issues ... You should have an Authors' Addresses section about here. > 11.1. Design ... > 1) Isn't this design harder to document and implement than, for > example, one which limits each PDU to containing a single > variable binding? Isn't this discussion moot since a subagent can't do correct "as if simultaneous" Set processing with only one variable at a time since the test phase may require comparing the values of multiple variables? > 6) SNMP version in the AgentX header > I know may of you feel this reeks. But there were at least three > implementors in Montreal who said it needs to be there. I'm > hoping folks will think about it a bit more, possibly in Yup, it reeks. Maybe take it out of protocol header and only put it in PDUs that "need" it, like Get/Test/etc.? > 8) Index reservation > Hopefully will be forthcoming after this version of the i-d > settles out. It should NOT effect anything in this spec. I'm going to comment on this in another message so it doesn't get burried. > > 9) States > Do we need to specify protocol states? Some are implied by > elements of procedure (can't register before open, etc.). > Perhaps specifying that Test/Commit/Undo/cleanup must finish > before other requests are forwarded to a subagent? Yes, I think we do. We especially need to explain how to avoid deadlock situations since a lot of "mid-level manager" applications are going to be defined that will run as subagents.   Delivery-Date: Fri, 30 Aug 1996 07:22:47 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA24768 for X-agentx; Fri, 30 Aug 1996 07:22:47 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA24762 for ; Fri, 30 Aug 1996 07:22:46 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA00152 for ; Fri, 30 Aug 1996 10:22:47 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA09729 for ; Fri, 30 Aug 1996 10:18:41 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id KAA09898; Fri, 30 Aug 1996 10:24:52 -0400 (EDT) Date: Fri, 30 Aug 1996 10:24:52 -0400 (EDT) From: Maria Greene Message-Id: <199608301424.KAA09898@avalon.nexen.com> To: agentx@fv.com Subject: Index reservation Regarding the index reservation capability, I've got these thoughts: > 8) Index reservation > Hopefully will be forthcoming after this version of the i-d > settles out. It should NOT effect anything in this spec. Well... I see two ways to do this: 1) a MIB 2) protocol operations If you choose 1, you've got a problem. Reserving an index implies doing a "set" operation on a MIB variable. Unfortunately, you often want to reserve an index in the course of handling a set request. I'm assuming the master agent is only going to allow one outstanding set at a time. If so, you've got deadlock. To get around this problem, you could define implied set behavior as a side effect of get or get-next, as Dave, Jeff and Ulrich have in their reservation MIB. This gives me the willies, though. It's complicated and there's a lot of opportunity for unintended reservations. If there was a PDU defined in the protocol to reserve an index, we'd avoid the whole mess. This would effect the spec. I was thinking of something along the lines of: agentx-IndexRes-PDU Subagent sends this PDU which contains a varbind list with the OID(s) of the index object(s) to be reserved and either the value to be reserved or no value which indicates the master agent sould return the next available index. agentx-IndexResResp-PDU Master agent responds with an error (e.g., the index is already reserved by another subagent) or the value. Let me re-iterate my feeling that this is extremely important for multi-vendor AgentX implementations if we're going to support SNMP operations that are equivalent to a monolithic agent. Otherwise, we'd be forced to implement tables like ifTable in multiple contexts. Maria   Delivery-Date: Fri, 30 Aug 1996 11:27:01 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA18340 for X-agentx; Fri, 30 Aug 1996 11:27:01 -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 LAA18326 for ; Fri, 30 Aug 1996 11:26:59 -0700 (PDT) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA28041; Fri, 30 Aug 1996 14:27:30 -0400 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id OAA27729; Fri, 30 Aug 1996 14:26:54 -0400 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA36559; Fri, 30 Aug 1996 14:26:51 -0400 From: Uri Blumenthal Message-Id: <9608301826.AA36559@hawpub.watson.ibm.com> Subject: Re: Comments on AgentX MIB draft To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Fri, 30 Aug 1996 14:26:51 -0400 (EDT) Cc: greene@nexen.com, agentx@fv.com In-Reply-To: <199608300902.EAA00958@card.com> from "Bert Wijnen" at Aug 30, 96 10:59:57 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Bert Wijnen says: > I like the first wordin above describing that it is optional, explains > why, and then states that if you want to give control over the internals > of an agentX master agent then this is the way to do it. Agreed. > I think we should do the axMax/DefaultTimeout as Maria initially > described. In fact of all the saMIB items on which you based this MIB, > these 2 timeout values seemed the most usefull in our experience. > The axMaxTimeout is something that gives the master agent control over > the ABSOLUTE max timeout anyone can use. A management station can change > that value if it wants. Enough functionality, reasonable overhead. Let's do it. > I would also keep the timeout in the registration tree, so that > timeout values can be used/minotored/changed per registration. Naturally. > > 2. Should the manager be allowed to disable a subagent? (Do we need > > axSAAdminStatus?) > > > I would say YES. It is possible that some subagent misbehaves badly. > So you would want the management station to be able to bump it. The assumption is - if the NMS decides to actively mess with the "composition" of the Agent, most likely NMS knows what it's doing. Therefore it needs this capability, and it's cheap enough to give. Let's have it. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 30 Aug 1996 11:54:44 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA23735 for X-agentx; Fri, 30 Aug 1996 11:54:44 -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 LAA23731 for ; Fri, 30 Aug 1996 11:54:43 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA01215; Fri, 30 Aug 1996 14:49:34 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05389; Fri, 30 Aug 1996 14:49:33 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA01524; Fri, 30 Aug 1996 14:52:47 -0400 Message-Id: <9608301852.AA01524@bernie.zk3.dec.com> To: agentx@fv.com Subject: re: Index reservation Date: Fri, 30 Aug 96 14:52:47 -0400 From: Mike Daniele X-Mts: smtp >If there was a PDU defined in the protocol to reserve an index, we'd >avoid the whole mess. This would effect the spec. Agreed, and I had always assumed the protocol spec should define index reservation. >agentx-IndexRes-PDU > Subagent sends this PDU which contains a varbind list with the > OID(s) of the index object(s) to be reserved and either the value > to be reserved or no value which indicates the master agent sould > return the next available index. I assume we'd need to define a convention for what to reserve (the object type containing the INDEX clause?) so subagents know what to do. Also, is there a constraint on indx value syntax? Just integers? >agentx-IndexResResp-PDU > Master agent responds with an error (e.g., the index is already > reserved by another subagent) or the value. Nit: There aren't any pdu-specific response pdus currently, so this should probably just be a agentx-Response-PDU containg a VarBindList. But how to denote an index is already reserved within the individual VarBinds? Perhaps a null value means already reserved? Or maybe simpler is the master always returns a value of areserved index. If the subagent didn't request one, the ret value is the next available. If the subagent did request one, the ret value is o the requested value, if it's available o the next available value I guess we'd need agentx-IndexUnRes-PDU too? And when a subagent's logical connection is closed, all of its reserved indexes are freed? Mike   Delivery-Date: Fri, 30 Aug 1996 15:23:08 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA05287 for X-agentx; Fri, 30 Aug 1996 15:23:07 -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 PAA05282 for ; Fri, 30 Aug 1996 15:23:06 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id SAA10887; Fri, 30 Aug 1996 18:23:09 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04374; Fri, 30 Aug 1996 18:21:55 -0400 Date: Fri, 30 Aug 1996 18:22:24 EDT From: Bob Natale Subject: Re: Comments on AgentX MIB draft To: Maria Greene Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Maria Greene > Date: Thu, 29 Aug 1996 18:42:49 -0400 (EDT) Hi Maria, <...> Thanks for your continued work on this MIB...and for already forwarding the revision to Dale for inclusion in the nascent AgentX document set. Let me shorten this response by saying that I generally agree with Juergen's statement wrt the optionality of the MIB for AgentX master agent implementators and I generally agree with the comments by Bert and Uri wrt what objects to retain from your original draft. <...> > OK. I've changed up(1) to open(1) and removed connecting, > disconnecting, and closedBySubagentTimeout. Per Bert's note, I would favor retaining that last state. > > axSATDomain OBJECT-TYPE > > axSATAddress OBJECT-TYPE > > > The subagent could conceivably have > 1 Taddress per TDomain, > > and could also have > 1 TDomain. > > True. I removed these objects because I think their value is not > high enough to make a (doubly-indexed) table of them. Any objections? I agree with your assessment of their value *if* a doubly-indexed table were required. However, I am not sure that Mike's comment (while true) need apply here...my view is that these objects should reflect the transport info wrt the connection of this instance of the subagent to the master agent. Assuming that there might be multiple means of connecting subagents to a master agent, then this information about a particular instance of a subagent would be helpful for some trouble-shooting scenarios. <...> > > The protocol i-d supports the notion of a virtual registry > > within a context. > > OK, if that's the way we want to handle it. I think context is a > hack that confuses a lot of people, Here's one! > but I guess we're stuck with it. Looks that way. :-( <...> > We've taken care of my issues 1, 3, and 4. What about 2? > > Issues > > 2. Should the manager be allowed to disable a subagent? > (Do we need axSAAdminStatus?) Yes, IMHO. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- 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 ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------