idnits 2.17.1 draft-ietf-agentx-ext-pro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 1996) is 10178 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4-7' on line 405 -- Looks like a reference, but probably isn't: 'TBD' on line 1241 -- Looks like a reference, but probably isn't: '1-22' on line 649 -- Looks like a reference, but probably isn't: '4-6' on line 687 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1902 (ref. '2') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '3') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1907 (ref. '5') (Obsoleted by RFC 3418) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '6') ** Downref: Normative reference to an Experimental RFC: RFC 1592 (ref. '7') Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 3 Expire in six months 5 Agent Extensibility (AgentX) Protocol 6 Version 1 8 June 12, 1996 10 Mike Daniele 11 Digital Equipment Corporation 12 daniele@zk3.dec.com 14 Dale Francisco (editor) 15 StrataCom 16 dfrancisco@strata.com 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as ``work in 29 progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 33 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 35 Rim). 37 Daniele/Francisco Expires December 1996 [Page 1] 38 Table of Contents 40 1. Introduction 41 2. The SNMP framework 42 2.1 A Note on Terminology 43 3. Extending the MIB 44 3.1 Motivation For AgentX 45 4. The AgentX Framework 46 4.1 AgentX Roles 47 5. AgentX Encodings 48 5.1 Character Set Selection 49 5.2 Value Representation 50 6. Protocol Definitions 51 6.1 Common Constructs 52 6.1.1 RegionSpecifier 53 6.1.2 NamingScope 54 6.1.3 SearchRange 55 6.1.4 AgentX PDU Header 56 6.2 AgentX PDUs 57 7. Elements of Procedure 58 7.1 AgentX Administrative PDUs 59 7.1.1 The Open-PDU 60 7.1.2 The Register-PDU 61 7.1.2.1 Register-PDU Fields 62 7.1.2.2 Processing the Register-PDU 63 7.1.2.2.1 The AddRegion Procedure 64 7.1.2.2.2 Handling Duplicate Regions 65 7.1.3 The Unregister-PDU 66 7.1.3.1 Unregister-PDU Fields 67 7.1.3.2 Processing the Unregister-PDU 68 7.1.4 The Close-PDU 69 7.2 Processing Received SNMP Protocol Messages 70 7.2.1 Dispatching AgentX PDUs 71 7.2.1.1 GetRequest-PDU 72 7.2.1.2 GetNextRequest-PDU 73 7.2.1.3 GetBulkRequest-PDU 74 7.2.2 Subagent Processing of AgentX PDUs 75 7.2.2.1 Subagent Processing of the AgentX Get-PDU 76 7.2.2.2 Subagent Processing of the AgentX GetNext-PDU 77 7.2.2.3 Subagent Processing of the AgentX GetBulk-PDU 78 7.2.3 Master Agent Processing AgentX Responses 79 7.2.4 Sending the SNMP Response PDU 80 8. Master Agent Transport Mappings 81 9. Security Considerations 82 10. Acknowledgements 83 11. References 85 Daniele/Francisco Expires December 1996 [Page 2] 86 1. Introduction 88 This memo defines a framework for extensible SNMP agents. It defines 89 processing entities called master agents and subagents, a protocol 90 (AgentX) used to communicate between them, and the elements of 91 procedure by which the extensible agent processes SNMP protocol 92 messages. 94 2. The SNMP Framework 96 A management system contains: several (potentially many) nodes, 97 each with a processing entity, termed an agent, which has access to 98 management instrumentation; at least one management station; and, a 99 management protocol, used to convey management information between 100 the agents and management stations. Operations of the protocol are 101 carried out under an administrative framework which defines 102 authentication, authorization, access control, and privacy 103 policies. 105 Management stations execute management applications which monitor 106 and control managed elements. Managed elements are devices such as 107 hosts, routers, terminal servers, etc., which are monitored and 108 controlled via access to their management information. 110 Management information is viewed as a collection of managed objects, 111 residing in a virtual information store, termed the Management 112 Information Base (MIB). Collections of related objects are defined 113 in MIB modules. These modules are written using a subset of OSI's 114 Abstract Syntax Notation One (ASN.1) [1], termed the Structure of 115 Management Information (SMI) [2]. 117 2.1. A Note on Terminology 119 The term "variable" refers to an instance of a non-aggregate object 120 type defined according to the conventions set forth in the SMI [2] 121 or the textual conventions based on the SMI [3]. The term "variable 122 binding" normally refers to the pairing of the name of a variable 123 and its associated value. However, if certain kinds of exceptional 124 conditions occur during processing of a retrieval request, a 125 variable binding will pair a name and an indication of that 126 exception. 128 A variable-binding list is a simple list of variable bindings. 130 The name of a variable is an OBJECT IDENTIFIER, which is the 131 concatenation of the OBJECT IDENTIFIER of the corresponding object 132 type together with an OBJECT IDENTIFIER fragment identifying the 133 instance. The OBJECT IDENTIFIER of the corresponding object-type is 134 called the OBJECT IDENTIFIER prefix of the variable. 136 Daniele/Francisco Expires December 1996 [Page 3] 137 For the purpose of exposition, the original Internet-standard 138 Network Management Framework, as described in RFCs 1155 (STD 16), 139 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1 140 framework (SNMPv1). The current framework, as described in RFCs 141 1902-1908, is termed the SNMP version 2 framework (SNMPv2). 143 3. Extending the MIB 145 New MIB modules that extend the Internet-standard MIB are 146 continuously being defined as the output of various IETF working 147 groups. It is also common for enterprises or individuals to 148 create or extend enterprise-specific or experimental MIBs. 150 As a result, managed devices are frequently complex collections of 151 manageable components that have been independently installed on a 152 managed node. Each component provides instrumentation for the 153 managed objects defined in the MIB module(s) it implements. 155 Neither the SNMP version 1 or version 2 framework address how 156 managed objects may be dynamically added to or removed from the 157 agent view within a particular managed node. 159 3.1. Motivation for AgentX 161 This very real need to dynamically extend the management objects 162 within a node has given rise to a variety of "extensible agents", 163 which typically comprise 165 - a "master" agent that is available on the standard transport 166 address and that accepts SNMP protocol messages 168 - a set of "subagents" that each contain management 169 instrumentation 171 - a protocol that operates between the master agent and subagents, 172 permitting subagents to "connect" to the master agent, and the 173 master agent to multiplex received SNMP protocol messages 174 amongst the subagents. 176 - a set of tools to aid subagent development, and a runtime (API) 177 environment that hides much of the protocol operation between a 178 subagent and the master agent. 180 The wide deployment of extensible SNMP agents, coupled with the 181 lack of Internet standards in this area, makes it difficult to field 182 SNMP-manageable applications. A vendor may have to support several 183 different subagent environments (APIs) in order to support different 184 target platforms. 186 It can also become quite cumbersome to configure subagents and 188 Daniele/Francisco Expires December 1996 [Page 4] 189 (possibly multiple) master agents on a particular managed node. 191 Specifying a standard protocol for agent extensibility (AgentX) 192 provides the technical foundation required to solve both of 193 these problems. Independently developed AgentX-capable master 194 agents and subagents will be able to interoperate at the protocol 195 level. Vendors can continue to differentiate their products 196 in all other respects. 198 4. AgentX Framework 200 A managed node contains a processing entity, called an agent, which 201 has access to management information. 203 Within the AgentX framework, an agent consists of both 205 - a single processing entity called the master agent, which sends 206 and receives SNMP protocol messages in an agent role (as 207 specified by the SNMP version 1 and version 2 framework 208 documents) but typically has little or no access to management 209 information. 211 - 0 or more processing entities called subagents, which do not 212 send or receive SNMP protocol messages, but which have access 213 to management information. 215 The master and subagent entities communicate via AgentX protocol 216 messages, as specified in this memo. While some of these 217 protocol messages appear similar in syntax and semantics to the 218 SNMP, it is important to remember that AgentX subagents are not 219 themselves SNMP protocol entities. 221 The internal operations of AgentX are invisible to an SNMP entity 222 operating in a manager role. To the manager, the agent behaves 223 exactly as would a non-extensible (monolithic) agent that had access 224 to the same management instrumentation. 226 This transparency to managers is a fundamental requirement of 227 AgentX, and is what differentiates AgentX subagents from SNMP proxy 228 agents. 230 4.1. AgentX Roles 232 An entity acting in a master agent role performs the following 233 functions: 235 - Accepts logical connection requests from subagents. 237 - Accepts registration of MIB regions by subagents. 239 Daniele/Francisco Expires December 1996 [Page 5] 240 - Sends and accepts SNMP protocol messages on the agent's 241 specified transport addresses. 243 - Implements the agent role Elements of Procedure specified for 244 the administrative framework applicable to the SNMP protocol 245 message, except where they specify performing management 246 operations. (The application of MIB views, and the access 247 control policy for the managed node, are implemented by the 248 master agent.) 250 - Provides instrumentation for the MIB objects defined in [5], 251 and for any MIB objects relevant to any administrative 252 framework it supports. 254 - Sends and receives AgentX protocol messages to access 255 management information, based on the current registry of MIB 256 regions. 258 An entity acting in a subagent role performs the following functions: 260 - Registers MIB regions with the master agent. 262 - Instantiates managed objects. 264 - Binds MIB region OIDs (contained in AgentX protocol messages) 265 to actual variable names. 267 - Performs management operations on variables. 269 - Initiates traps. 271 5. AgentX Encodings 273 AgentX PDUs consist of a common, fixed-format header; an optional 274 PDU-specific subheader; and optional, possibly variable-length data. 275 The PDUs are not encoded using the BER [1], but are represented as 276 a simple byte stream. 278 Within the header and subheaders, numeric data is always encoded 279 most significant byte (MSB) first. The length of this data is 280 not transmitted explicitly since it is known by the packet format. 281 Variable-length data within the subheaders is transmitted as 282 null-terminated strings. The length of this data is not transmitted 283 explicitly since it may be determined by the string's length. 285 Object identifiers are represented within the subheaders as 286 null-terminated, ASN.1 dotted notation strings. 288 5.1. Character Set Selection 290 Daniele/Francisco Expires December 1996 [Page 6] 291 Strings are represented in the native character set of the system on 292 which the subagent resides. If this is not ASCII, the master agent 293 must perform any required conversions. 295 5.2. Value Representation 297 Variable bindings may be transmitted within the variable-length 298 portion of some PDUs. This representation (called a VarBind) is 299 as follows: 301 VarBind 303 +--------+------+--------------------------------------------+ 304 | OFFSET | SIZE | FIELD | 305 +--------+------+--------------------------------------------+ 306 | X | var | v.name (OID, null-terminated, length L) | 307 +--------+------+--------------------------------------------+ 308 | X+L+1 | 1 | v.type | 309 +--------+------+--------------------------------------------+ 310 | X+L+2 | 2 | v.length (MSB first) | 311 +--------+------+--------------------------------------------+ 312 | X+L+4 | var | v.data (format depends on data type) | 313 +--------+------+--------------------------------------------+ 315 v.type indicates the variable binding's syntax, and must be one of 316 the following values: 318 Daniele/Francisco Expires December 1996 [Page 7] 319 +-----------------------------------------------------------------+ 320 | Table 17. Valid values for the Value Type field | 321 +-------+---------------------------------------------------------+ 322 | VALUE | VALUE TYPE | 323 +-------+---------------------------------------------------------+ 324 | 129 | SNMP_TYPE_Integer32 | 325 +-------+---------------------------------------------------------+ 326 | 2 | SNMP_TYPE_OCTET_STRING | 327 +-------+---------------------------------------------------------+ 328 | 3 | SNMP_TYPE_OBJECT_IDENTIFIER | 329 +-------+---------------------------------------------------------+ 330 | 4 | SNMP_TYPE_NULL (empty, no value) | 331 +-------+---------------------------------------------------------+ 332 | 5 | SNMP_TYPE_IpAddress | 333 +-------+---------------------------------------------------------+ 334 | 134 | SNMP_TYPE_Counter32 | 335 +-------+---------------------------------------------------------+ 336 | 135 | SNMP_TYPE_Gauge32 | 337 +-------+---------------------------------------------------------+ 338 | 136 | SNMP_TYPE_TimeTicks (1/100ths seconds) | 339 +-------+---------------------------------------------------------+ 340 | 9 | SNMP_TYPE_DisplayString | 341 +-------+---------------------------------------------------------+ 342 | 13 | SNMP_TYPE_Counter64 | 343 +-------+---------------------------------------------------------+ 344 | 14 | SNMP_TYPE_Opaque | 345 +-------+---------------------------------------------------------+ 346 | 15 | SNMP_TYPE_noSuchObject | 347 +-------+---------------------------------------------------------+ 348 | 16 | SNMP_TYPE_noSuchInstance | 349 +-------+---------------------------------------------------------+ 350 | 17 | SNMP_TYPE_endOfMibView | 351 +-------+---------------------------------------------------------+ 353 v.length is a 2-byte integer, MSB first, which indicates the number 354 of octets of v.data. 356 v.data is the actual value, and is encoded as follows: 358 - 32-bit integers are 4-byte elements, MSB first. Example: 359 '00000001'h represents 1. 361 - 64-bit integers are 8-byte elements, MSB first. Example: 362 '0000000100000001'h represents 4,294,967,297. 364 - Object Identifiers are NULL terminated strings in the selected 365 character set, representing the OID in ASN.1 dotted notation. 366 The length includes the terminating NULL. Example ASCII: 367 '312e332e362e312e322e312e312e312e3000'h represents 368 "1.3.6.1.2.1.1.1.0" which is sysDescr.0. Example EBCDIC: 369 'f14bf34bf64bf14bf24bf14bf14bf14bf000'h represents 371 Daniele/Francisco Expires December 1996 [Page 8] 372 "1.3.6.1.2.1.1.1.0" which is sysDescr.0. 374 - DisplayStrings are in the selected character set. The length 375 specifies the length of the string. Example ASCII: 376 '6162630d0a'h represents "abc\r\n", no NULL. Example EBCDIC: 377 '8182830d25'h represents "abc\r\n", no NULL. 379 - IpAddress, NsapAddress and Opaque are implicit OCTET_STRING, 380 so they are octets (e.g. IpAddress in network byte order). 382 - NULL has a zero length for the value, and no value data. 384 - noSuchObject, noSuchInstance and endOfMibView are implicit 385 NULL and represented as such. 387 - BIT_STRING is an OCTET_STRING of the form uubbbb...bb, where 388 the first octet (uu) is 0x00-0x07 and indicates the number of 389 unused bits in the last octet (bb). The bb octets represent 390 the bit string itself, where bit zero (0) comes first and so 391 on. 393 VarBindList is a contiguous list of VarBinds. 395 6. Protocol Definitions 397 6.1. Common Constructs 399 6.1.1. RegionSpecifier 401 A RegionSpecifier is an object identifier that may optionally contain 402 a range in place of exactly one of its sub-identifiers. The range 403 is represented as "[" lower-bound "-" upper-bound "]". 405 For example, "1.2.3.[4-7].8" is a valid RegionSpecifier. 407 6.1.2. NamingScope 409 [TBD] 411 Daniele/Francisco Expires December 1996 [Page 9] 412 6.1.3. SearchRange 414 SearchRange 416 +--------+------+----------------------------------------+ 417 | OFFSET | SIZE | FIELD | 418 +--------+------+----------------------------------------+ 419 ... 420 +--------+------+--------------------------------------------+ 421 | X | var | g.requested (null-terminated OID, len L) | 422 +--------+------+--------------------------------------------+ 423 | X+L+1 | var | g.limit (null-terminated OID) | 424 +--------+------+--------------------------------------------+ 426 g.requested is the name of a requested variable binding. 428 g.limit is an optional object identifier derived by the master 429 agent to limit the search done by a subagent. 431 SearchRangeList is a contiguous list of SearchRanges. 433 6.1.4. AgentX PDU Header 435 Header 437 +--------+------+----------------------------------------+ 438 | OFFSET | SIZE | FIELD | 439 +--------+------+----------------------------------------+ 440 | 0 | 4 | h.length (MSB first) | 441 +--------+------+----------------------------------------+ 442 | 2 | 4 | h.ID (MSB first) | 443 +--------+------+----------------------------------------+ 444 | 8 | 1 | h.major | 445 +--------+------+----------------------------------------+ 446 | 9 | 1 | h.minor | 447 +--------+------+----------------------------------------+ 448 | 10 | 1 | h.flags | 449 +--------+------+----------------------------------------+ 450 | 11 | 1 | h.type | 451 +========+======+========================================+ 453 h.length is the size in octets of the entire PDU, including the 454 header. (HL is the length of the header itself.) 456 h.ID is a monotonically increasing packet id that should be kept 457 unique by the sending entity. 459 h.major is the protocol major version. This memo specifies a value 460 of 0. 462 h.minor is the protocol minor version number. This memo specifies 463 a value of 0. 465 h.flags is a one-octet bitmask, bit 0 first, etc. 466 Bit definitions are 468 Bits Contain 469 ---- ------- 470 0-3 SNMP version 471 4 Alone 472 5-7 reserved 474 h.type is the PDU type, and must be one of the following values: 476 +-----------------------------------------------------------------+ 477 | Table 16. Valid values for the packet type field | 478 +-------+---------------------------------------------------------+ 479 | VALUE | PACKET TYPE | 480 +-------+---------------------------------------------------------+ 481 | 1 | AGENTX_GET | 482 +-------+---------------------------------------------------------+ 483 | 2 | AGENTX_GETNEXT | 484 +-------+---------------------------------------------------------+ 485 | 3 | AGENTX_SET | 486 +-------+---------------------------------------------------------+ 487 | 4 | AGENTX_TRAP | 488 +-------+---------------------------------------------------------+ 489 | 5 | AGENTX_RESPONSE | 490 +-------+---------------------------------------------------------+ 491 | 6 | AGENTX_REGISTER | 492 +-------+---------------------------------------------------------+ 493 | 7 | AGENTX_UNREGISTER | 494 +-------+---------------------------------------------------------+ 495 | 8 | AGENTX_OPEN | 496 +-------+---------------------------------------------------------+ 497 | 9 | AGENTX_CLOSE | 498 +-------+---------------------------------------------------------+ 499 | 10 | AGENTX_COMMIT | 500 +-------+---------------------------------------------------------+ 501 | 11 | AGENTX_UNDO | 502 +-------+---------------------------------------------------------+ 503 | 12 | AGENTX_GETBULK | 504 +-------+---------------------------------------------------------+ 505 | 13 | AGENTX_TRAPV2 (not yet used) | 506 +-------+---------------------------------------------------------+ 507 | 14 | AGENTX_INFORM (not yet used) | 508 +-------+---------------------------------------------------------+ 509 | 15 | AGENTX_ARE_YOU_THERE | 510 +-------+---------------------------------------------------------+ 512 6.2. AgentX PDUs 514 Register-PDU 516 +--------+------+----------------------------------------------+ 517 | OFFSET | SIZE | FIELD | 518 +--------+------+----------------------------------------------+ 519 | 0 | | Header | 520 +--------+------+----------------------------------------------+ 521 | HL | 2 | r.priority (MSB first) | 522 +--------+------+----------------------------------------------+ 523 | HL+2 | 2 | r.timeout (MSB first) | 524 +--------+------+----------------------------------------------+ 525 | HL+4 | var | r.region (RegionSpecifier, length L) | 526 +--------+------+----------------------------------------------+ 527 |HL+4+L+1| var | r.context (NamingScope) | 528 +--------+------+----------------------------------------------+ 530 Unregister-PDU 532 +--------+------+----------------------------------------------+ 533 | OFFSET | SIZE | FIELD | 534 +--------+------+----------------------------------------------+ 535 | 0 | | Header | 536 +--------+------+----------------------------------------------+ 537 | HL | 1 | u.reason code | 538 +--------+------+----------------------------------------------+ 539 | HL+1 | var | u.region (RegionSpecifier, length L) | 540 +--------+------+----------------------------------------------+ 541 |HL+1+L+1| var | u.context (NamingScope) | 542 +--------+------+----------------------------------------------+ 544 Get-PDU 546 +--------+------+----------------------------------------------+ 547 | OFFSET | SIZE | FIELD | 548 +--------+------+----------------------------------------------+ 549 | 0 | | Header | 550 +--------+------+----------------------------------------------+ 551 | HL | var | g.context (NamingScope, length L) | 552 +--------+------+----------------------------------------------+ 553 | HL+L+1 | var | SearchRangeList | 554 +--------+------+----------------------------------------------+ 556 GetNext-PDU 558 +--------+------+----------------------------------------------+ 559 | OFFSET | SIZE | FIELD | 560 +--------+------+----------------------------------------------+ 561 | 0 | | Header | 562 +--------+------+----------------------------------------------+ 563 | HL | var | g.context (NamingScope, length L) | 564 +--------+------+----------------------------------------------+ 565 | HL+L+1 | var | SearchRangeList | 566 +--------+------+----------------------------------------------+ 568 GetBulk-PDU 570 +--------+------+----------------------------------------------+ 571 | OFFSET | SIZE | FIELD | 572 +--------+------+----------------------------------------------+ 573 | 0 | | Header | 574 +--------+------+----------------------------------------------+ 575 | HL | 4 | g.non_repeaters (MSB first) | 576 +--------+------+----------------------------------------------+ 577 | HL+4 | 4 | g.max_repetitions (MSB first) | 578 +--------+------+----------------------------------------------+ 579 | HL+8 | var | g.context (NamingScope, length L) | 580 +--------+------+----------------------------------------------+ 581 |HL+8+L+1| var | SearchRangeList | 582 +--------+------+----------------------------------------------+ 584 Response-PDU 586 +--------+------+----------------------------------------------+ 587 | OFFSET | SIZE | FIELD | 588 +--------+------+----------------------------------------------+ 589 | 0 | | Header | 590 +--------+------+----------------------------------------------+ 591 | HL | 4 | res.error_code (MSB first) | 592 +--------+------+----------------------------------------------+ 593 | HL+4 | 4 | res.error_index (MSB first) | 594 +--------+------+----------------------------------------------+ 595 | HL+8 | var | VarBindList | 596 +--------+------+----------------------------------------------+ 598 7. Elements of Procedure 600 This section describes the actions of protocol entities (master 601 agents and subagents) implementing the AgentX protocol. Note, 602 however, that it is not intended to constrain the internal 603 architecture of any conformant implementation. 605 The actions of AgentX protocol entities can be broadly categorized 606 under two headings: processing AgentX administrative messages (e.g, 607 connection requests from a subagent to a master agent); and 608 processing SNMP messages (e.g., the coordinated actions of a master 609 agent and one or more subagents in processing a received SNMP 610 GetRequest-PDU). 612 7.1. Processing AgentX Administrative Messages 614 This subsection describes the actions of AgentX protocol entities in 615 processing AgentX administrative messages. Such messages include 616 those involved in establishing and terminating a connection between 617 a subagent and a master agent, and those by which a subagent 618 communicates to a master agent which MIB subtrees it supports. 620 7.1.1. The Open-PDU 622 [TBD] 624 7.1.2. The Register-PDU 626 A Register-PDU is generated by a subagent for each region of the 627 MIB variable naming tree (within a specific context) that it wishes 628 to support. 630 7.1.2.1. Register-PDU Fields 632 A Register-PDU contains the following fields: 634 - r.region indicates a region of the MIB that a subagent 635 wishes to support. It may be a fully-qualified instance name, 636 a partial instance name, a MIB table or group, or ranges of 637 any of these. 639 The choice of what to register is implementation-specific; this 640 memo does not specify permissible values. Standard practice 641 however is for a subagent to register at the highest level of 642 the naming tree that makes sense. Registration of 643 fully-qualified instances is typically done only when a 644 subagent can perform management operations only on particular 645 rows of a conceptual table. 647 Note that the RegionSpecifier syntax (see 6.1.1) permits 648 registering a conceptual row in a single operation. For 649 instance, "1.3.6.1.2.1.2.2.1.[1-22].7" would register row 7 of 650 the RFC 1573 ifTable. 652 - r.context is used by the subagent when identically named 653 objects require a context to differentiate them. A null 654 string indicates the default context. 656 - r.priority is used by cooperating subagents to achieve a 657 desired configuration when registering identical regions. 658 The default value is 0 (no priority indicated). Higher 659 numbers indicate higher priority. 661 - r.timeout is the length of time, in centiseconds, that a master 662 agent should allow to elapse after dispatching a message to a 663 subagent before it regards the subagent as not responding. 664 r.timeout applies only to messages that concern MIB objects 665 within r.region. It overrides both the subagent-wide value (if 666 any) indicated when the logical connection with the master 667 agent was established, and the master agent's default timeout. 668 The default value for r.timeout is 0 (no override). 670 7.1.2.2. Processing the Register-PDU 672 When the master agent receives a Register-PDU, it processes it 673 as follows: 675 If an Open-PDU has not been received and successfully processed for 676 this subagent, ignore the message [or send back error?]. 678 Otherwise, the master agent adds this region to its registered OID 679 space for that context, to be considered during the dispatching 680 phase for subsequently received SNMP protocol messages. 682 7.1.2.2.1. The AddRegion Procedure 684 In this region addition phase, RegionSpecifiers that contain subid 685 ranges are processed as if the master agent had received multiple 686 registrations, each containing no subid ranges. (For instance, 687 "1.2.3.[4-6].7" is processed as if the master had received 688 registrations whose RegionSpecifiers where "1.2.3.4.7", "1.2.3.5.7", 689 and "1.2.3.6.7".) 691 If r.region (R1) is a subtree of a currently registered region (R2), 692 split R2 into 3 new regions (R2a, R2b, and R2c) such that R2b is an 693 exact duplicate of R1. Now remove R2 and add R1, R2a, R2b, and R2c 694 to the master agent's lexicographically ordered set of regions (the 695 registered OID space). Note: Though newly-added regions R1 and 696 R2b are identical in terms of the MIB objects they contain, they are 697 registered by different subagents, possibly at different priorities. 699 For instance, if subagent S2 registered `ip' (R2 is 1.3.6.1.2.1.4) 700 and subagent S1 subsequently registered `ipNetToMediaTable' (R1 is 701 1.3.6.1.2.1.4.22), the resulting set of registered regions would be: 703 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 704 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 705 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 706 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) 708 If r.region (R1) overlaps one or more currently registered 709 regions, then for each overlapped region (R2) split R1 into 3 new 710 regions (R1a, R1b, R1c) such that R1b is an exact duplicate of 711 R2. Add R1b and R2 into the lexicographically ordered set of 712 regions. Apply the AddRegion operation to R1a and R1c (since 713 they may overlap, or be subtrees of, other regions). 715 For instance, given the currently registered regions in the example 716 above, if subagent S3 now registers mib-2 (R1 is 1.3.6.1.2.1) the 717 resulting set of regions would be: 719 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 720 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S2) 721 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 722 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S2) 723 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 724 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 725 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S2) 726 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 727 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3) 729 Note that at registration time a region may be split into multiple 730 regions due to pre-existing registrations, or as a result of any 731 subsequent registration. This region splitting is transparent to 732 subagents. Hence the master agent must always be able to associate 733 any registered region with the information contained in its original 734 Register-PDU. 736 7.1.2.2.2. Handling Duplicate Regions 738 As a result of this registration algorithm there are likely to be 739 duplicate regions (regions of identical MIB objects registered to 740 different subagents) in the master agent's registered OID space. 741 Whenever the master agent's dispatching algorithm (see 7.2.1, 742 Dispatching AgentX PDUs) selects a duplicate region, the 743 determination of which one to use proceeds as follows: 745 1) Choose the one whose original Register-PDU r.region contained 746 the most subids, i.e., the most specific r.region. Note: A 747 range subid is no "longer" (more specific) than a single 748 subid. 750 2) If still ambiguous, choose the one whose original Register-PDU 751 specified the highest priority. 753 3) If still ambiguous, choose the one whose original Register-PDU 754 was received most recently. 756 7.1.3. The Unregister-PDU 758 The Unregister-PDU is sent by a subagent to remove a previously 759 registered RegionSpecifier from the master agent's OID space. 761 7.1.3.1. Unregister-PDU Fields 763 An Unregister-PDU contains the following fields: 765 - u.reason 767 - u.region indicates a previously-registered region of the MIB 768 that a subagent no longer wishes to support. It may be a 769 fully-qualified instance name, a partial instance name, a MIB 770 table or group, or ranges of any of these. 772 - u.context is used by the subagent when identically named 773 objects require a context to differentiate them. A null 774 string indicates the default context. 776 7.1.3.2. Processing the Unregister-PDU 778 If u.region and u.context do not exactly match the values of 779 r.region and r.context of a previously processed Register-PDU which 780 was sent from this subagent, the request is rejected with an 781 appropriate error response. 783 Otherwise the master agent removes u.region from its registered OID 784 space for u.context. If the original region had been split, all 785 such related regions are removed. If this removal results in any 786 contiguous regions that share a common original Register-PDU, they 787 are agglomerated into a single region. 789 For instance, given the example registry above, if subagent S2 790 unregisters `ip', the resulting registry would be: 792 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4 (by S3) 793 1.3.6.1.2.1.4 up to but not including 1.3.6.1.2.1.4.22 (by S3) 794 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 795 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 796 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.1.5 (by S3) 797 1.3.6.1.2.1.5 up to but not including 1.3.6.1.2.2 (by S3) 799 and after agglomeration; 801 1.3.6.1.2.1 up to but not including 1.3.6.1.2.1.4.22 (by S3) 802 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S1) 803 1.3.6.1.2.1.4.22 up to but not including 1.3.6.1.2.1.4.23 (by S3) 804 1.3.6.1.2.1.4.23 up to but not including 1.3.6.1.2.2 (by S3) 806 7.2. Processing Received SNMP Protocol Messages 808 When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or 809 SetRequest protocol message is received by the master agent, the 810 master agent implements the access control policy in effect at the 811 managed node. 813 In particular, the master agent implements the Elements of Procedure 814 defined in section 4.1 of [6] that apply to receiving entities. 816 [We can't refer to 1901, or v2u/v2* ?] 818 If this processing results in a valid SNMP request PDU, then an SNMP 819 response PDU is constructed from information gathered in the 820 exchange of AgentX PDUs between the master agent and 1 or more 821 subagents. Upon receipt and initial validation of an SNMP request 822 PDU, a master agent uses the procedures described below to dispatch 823 AgentX PDUs to the proper subagents, marshal the subagent responses, 824 and construct an SNMP response PDU. 826 7.2.1 Dispatching AgentX PDUs 828 Upon receipt and initial validation of an SNMP request PDU, a master 829 agent uses the procedures described below to dispatch AgentX PDUs to 830 the proper subagents. 832 7.2.1.1 GetRequest-PDU 834 An SNMP Response-PDU is constructed whose fields all contain the 835 same values as in the SNMP Request-PDU, except that the value of 836 each variable binding is set to 'noSuchObject'. 838 Each variable binding in the Request-PDU is processed in order, as 839 follows: 841 (1) Identify the target region. 843 (2) Within a list of regions registered within the context indicated 844 in the request PDU, and lexicographically ordered by 845 RegionSpecifier, locate the RegionSpecifier that is identical to 846 or is the closest lexicographical predecessor to the variable 847 binding's name. 849 (3) If no such region exists the variable binding is not processed 850 further. 852 (4) Identify the target subagent, which is the one that registered 853 the target region. 855 (5) If this is the first variable binding to be dispatched to the 856 target subagent, create an AgentX Get-PDU for the subagent, with 857 the header fields initialized as described in section 6.1.3, and 858 the context in the Request-PDU encoded into g.context. 860 (6) Add a SearchRange to the end of the target subagent's Get-PDU 861 for this variable binding. 863 (7) The variable binding's name is copied to g.requested. 865 (8) g.limit is set to null. 867 7.2.1.2. GetNextRequest-PDU 869 An SNMP Response-PDU is constructed whose fields all contain the same 870 values as in the SNMP Request-PDU, except that the value of each 871 variable binding is set to 'endOfMibView'. 873 Each variable binding in the Request-PDU is processed in order, as 874 follows: 876 (1) Identify the target region. 878 (2) Within a list of regions registered within the context indicated 879 in the request PDU, and lexicographically ordered by 880 RegionSpecifier, locate the longest RegionSpecifier of which the 881 variable binding's name is a subtree. If no such region exists, 882 locate the RegionSpecifier which is the first lexicographical 883 successor to the variable binding's name. 885 (3) If no such region exists the variable binding is not processed 886 further. 888 (4) Identify the target subagent, which is the one that registered 889 the target region. 891 (5) If this is the first variable binding to be dispatched to the 892 target subagent, create an AgentX GetNext-PDU for the subagent, 893 with the header fields initialized as described in section 6.1.3 894 and the context in the Request-PDU encoded into g.context. 896 (6) Add a SearchRange to the end of the target subagent's GetNext-PDU 897 for this variable binding. 899 (7) The variable binding's name is copied to g.requested. 901 (8) g.limit is set to the RegionSpecifier that is the first 902 lexicographical successor to the target Regionspecifier, and that 903 was not registered by the target subagent. If no such 904 RegionSpecifier exists, g.limit is set to null. 906 7.2.1.3. GetBulkRequest-PDU 908 (Note: The outline of the following procedure is based closely on 909 section 4.2.3, "The GetBulkRequest-PDU" of [4]. Please refer to it 910 for details on the format of the SNMP GetBulkRequest-PDU itself.) 912 An SNMP Response-PDU is constructed whose fields all contain the same 913 values as in the SNMP Request-PDU. The SNMP Response-PDU contains 914 N + (M * R) variable bindings whose values are set to `EndOfMibView', 915 where 917 N ("non-repeaters") is the minimum of: 918 a) the value of the non-repeaters field in the request, and 919 b) the number of variable bindings in the request 921 M ("max-repetitions") is the value of the max-repetitions field 922 in the request 924 R ("repeaters") is the maximum of: 925 a) number of variable bindings in the request - N, and 926 b) zero 928 Each variable binding in the Request-PDU is processed in order, as 929 follows: 931 (1) Identify the target region and target subagent, exactly as 932 described for the GetNextRequest-PDU (7.2.1.2). 934 (2) If this is the first variable binding to be dispatched to the 935 target subagent during the processing of this Request-PDU, create 936 an AgentX GetBulk-PDU for the subagent, with the header fields 937 initialized as described in section 6.1.3 and the context and 938 max_repetitions value in the request PDU encoded into g.context 939 and g.max_repetitions. Set g.non_repeaters to 0. 941 (3) Add a SearchRange to the end of the target subagent's GetBulk-PDU 942 for this variable binding, as described for the GetNext-PDU. If 943 the variable binding was within the non_repeaters range in the 944 original Request-PDU, increment the value of g.non_repeaters. 946 When all variable bindings have been processed, send any AgentX PDUs 947 to their respective target subagents (at the transport endpoint used 948 to initiate the subagent's logical connection). 950 Calculate a timeout value for each target subagent that is the 951 maximum of: 953 - The master agent's default. 955 - The subagent's default, as indicated by the subagent at 956 connection establishment. 958 - Any region-specific timeout values, as indicated by the 959 subagent at registration. 961 7.2.2. Subagent Processing of AgentX Request PDUs 963 When a subagent receives an AgentX Get-, GetNext-, or GetBulk-PDU, it 964 performs the indicated management operations and returns a response 965 PDU. 967 The response PDU header fields are identical to the received 968 request PDU except that, at the start of processing, the subagent 969 initializes h.type to RESPONSE, res.error_code to `noError', 970 res.error_index to 0, and the VarbindList to null. 972 Each SearchRange in the request PDU is then processed in order, and 973 a corresponding VarBind added to the response PDU as described 974 below. If processing should fail for any reason not described 975 below, res.error_code is set to `genError', res.error_index to the 976 index of the failed SearchRange, the VarBindList is reset to null, 977 and this response PDU is returned to the master agent. 979 7.2.2.1. Subagent Processing of the AgentX Get-PDU 981 Upon the subagent's receipt of an AgentX Get-PDU, each variable 982 binding in the request is processed in order as follows: 984 1) g.requested is copied to v.name. 986 2) If the value of g.requested exactly matches the name of a 987 variable instantiated by this subagent within the indicated 988 context, v.type, v.length, and v.data are encoded to represent 989 the variable's syntax and value, as described in section 5.2. 991 If the resulting VarBind's type is not part of the SNMPv1 SMI, 992 and h.flags indicate this is an SNMPv1-style request, v.type is 993 set to `noSuchObject', and v.length to 0. 995 3) Otherwise, if the value of g.requested does not match the OBJECT 996 IDENTIFIER PREFIX of any variable instantiated within the 997 indicated context, v.type is set to `noSuchObject' and v.length 998 to 0. 1000 4) Otherwise, v.type is set to `noSuchInstance' and v.length to 0. 1002 7.2.2.2. Subagent Processing of the AgentX GetNext-PDU 1004 Upon the subagent's receipt of an AgentX GetNext-PDU, each variable 1005 binding in the request is processed in order as follows: 1007 1) The subagent searches for a variable within the 1008 lexicographically ordered list of variable names for all 1009 variables it instantiates (without regard to registration of 1010 regions) within the indicated context, for which the following 1011 are all true: 1013 - The variable's name is the closest lexicographical successor 1014 to g.requested. 1016 - If g.limit is not null, the variable's name lexicographically 1017 precedes g.limit. 1019 - If h.flags indicates this is an SNMPv1 request, the 1020 variable's syntax is part of the SNMPv1 SMI. 1022 If all of these conditions are met, v.name is set to the 1023 located variable's name. v.type, v.length, and v.data are 1024 encoded to represent the variable's syntax and value, as 1025 described in section 5.2. 1027 2) If no such variable exists, v.name is set to g.requested, 1028 v.type is set to `endOfMibView', and v.length to 0. 1030 7.2.2.3. Subagent Processing of the AgentX GetBulk-PDU 1032 A maximum of N + (M * R) VarBinds are returned, where 1034 N equals g.non_repeaters, 1036 M equals g.max_repetitions, and 1038 R is (number of SearchRanges in the GETBULK request) - N. 1040 The first N SearchRanges are processed exactly as for the GetNext 1041 PDU. 1043 If M and R are both non-zero, the remaining R SearchRanges are 1044 processed iteratively to produce potentially many VarBinds. For 1045 each iteration i, such that i is greater than zero and less than or 1046 equal to M, and for each repeated SearchRange s, such that s is 1047 greater than zero and less than or equal to R, the 1048 (N+((i-1)*R)+s)-th VarBind is added to the response PDU as follows: 1050 1) The subagent searches for a variable within the 1051 lexicographically ordered list of variable names for all 1052 variables it instantiates (without regard to registration of 1053 regions) within the indicated context, for which the following 1054 are all true: 1056 - The variable's name is the (i)-th lexicographical successor 1057 to the (N+s)-th requested OID. 1059 - If g.limit is not null, the variable's name 1060 lexicographically precedes g.limit. 1062 - If h.flags indicates this is an SNMPv1 request, the 1063 variable's syntax is part of the SNMPv1 SMI. 1065 If all of these conditions are met, v.name is set to the 1066 located variable's name. v.type, v.length, and v.data are 1067 encoded to represent the variable's syntax and value, as 1068 described in section 5.2. 1070 2) If no such variable exists, v.type is set to `endOfMibView' 1071 and v.length to 0. v.name is set to v.name of the 1072 (N+((i-2)*R)+s)-th VarBind unless i is currently one, in which 1073 case it is set the value of g.requested in the (N+s)-th 1074 SearchRange. 1076 Note that further iterative processing should stop if for any 1077 iteration i, all s values of v.type are `EndofMibView'. 1079 When the AgentX response PDU has been generated, it is sent back to 1080 the master agent's transport endpoint from which the request was 1081 sent. 1083 7.2.3. Master Agent Processing of AgentX Responses 1085 The master agent now marshals all subagent response PDUs and builds 1086 an SNMP response PDU. To do so, the master agent must be able to 1087 determine the corresponding variable binding (or error_index value) 1088 in the SNMP Response-PDU for each received AgentX VarBind (or 1089 res.error_index value). 1091 (Note in particular that a response PDU may contain more VarBinds 1092 than are required to complete the SNMP Response-PDU.) 1094 1) If any subagent did not respond within its allotted time period, 1095 the SNMP Response PDU's error code is set to `genError' and 1096 its error index to the index of the variable binding 1097 corresponding to the first VarBind in the request PDU that was 1098 sent to this subagent. 1100 All other subagent response PDUs received due to processing this 1101 SNMP request are ignored. Processing is complete; the SNMP 1102 response PDU is sent. 1104 2) Otherwise, if the h.ID field of the AgentX response PDU does not 1105 match that of the request PDU sent to this subagent, the PDU is 1106 ignored. 1108 3) Otherwise, if res.error code is not `noError', the SNMP response 1109 PDU's error code is set to this value, and its error index to the 1110 index of the variable binding corresponding to the failed VarBind 1111 in the subagent's response PDU. 1113 All other response PDUs received due to processing this SNMP 1114 Request are ignored. Processing is complete; the SNMP Response 1115 PDU is sent. 1117 4) Otherwise, the VarBinds in the RESPONSE PDU are processed as 1118 follows: 1120 Get 1122 If v.name is not within the relevant MIB view, the VarBind is 1123 ignored. (This determination is implementation-specific.) 1125 Otherwise, the name and value of the corresponding variable 1126 binding in the SNMP Response-PDU are updated with the contents 1127 of the VarBind. 1129 GetNext 1131 If v.name is not within the relevant MIB view, the VarBind is 1132 ignored. (This determination is implementation-specific.) 1134 Otherwise, the name and value of the corresponding variable 1135 binding in the SNMP Response-PDU are updated with the contents 1136 of the VarBind. 1138 5) After all expected response PDUs have been processed, if any 1139 variable bindings still contain the value `endOfMibView', 1140 processing must continue: 1142 - For each such variable binding, a target region is 1143 identified which is the lexicographical successor to the 1144 target region for this variable binding on the last 1145 iteration. The target subagent is the one that registered 1146 the target region. 1148 - If this is the first variable binding to be dispatched to 1149 the target subagent (during this iteration), create an 1150 AgentX GetNext-PDU for the subagent, with the header 1151 fields initialized as described in section 6.1.3 and the 1152 context in the Request-PDU encoded into g.context. 1154 - Add a SearchRange to the end of the target subagent's 1155 GetNext-PDU for this variable binding. The variable 1156 binding's name is copied to g.requested. g.limit is set to 1157 the RegionSpecifier that is the first lexicographical 1158 successor to the target Regionspecifier, and that was not 1159 registered by the target subagent. If no such 1160 RegionSpecifier exists, g.limit is set to null. 1162 - The AgentX PDUs are sent, received, and processed 1163 according to section 7.2.3. 1165 - This process continues iteratively until a complete SNMP 1166 Response-PDU has been built, or until there remain no 1167 target region lexicographical successors. 1169 GetBulk 1171 If v.name is not within the relevant MIB view, the VarBind is 1172 ignored. (This determination is implementation-specific.) 1174 Otherwise, the name and value of the corresponding variable 1175 binding in the SNMP Response-PDU are updated with the contents 1176 of the VarBind. 1178 5) If after all expected RESPONSE PDUs have been processed, any 1179 variable bindings still contain the value `endOfMibView', 1180 processing must continue: 1182 - For each such variable binding, a target region is 1183 identified which is the lexicographical successor to the 1184 target region for this variable binding on the last 1185 iteration. The target subagent is the one that registered 1186 the target region. 1188 - If this is the first variable binding to be dispatched to 1189 the target subagent (during this iteration), create an 1190 AgentX GetBulk-PDU for the subagent, with the header fields 1191 initialized as described in section 6.1.3 and the context 1192 from the Request-PDU encoded into g.context. 1194 - Set the value of g.non_repeaters and g.max_repetitions 1195 to 0. 1197 - Add a SearchRange to the end of the target subagent's 1198 GetBulk-PDU for this variable binding. 1200 - g.requested is set to v.name of the (last repeating) 1201 VarBind that was returned for this variable binding on the 1202 previous iteration. 1204 g.limit is set to the RegionSpecifier that is the first 1205 lexicographical successor to the target Regionspecifier, 1206 and that was not registered by the target subagent. If no 1207 such RegionSpecifier exists, g.limit is set to null. 1209 If the variable binding was within the non_repeaters range 1210 in the original Request-PDU, increment the value of 1211 g.non_repeaters. 1213 Otherwise, set the value of g.max_repetitions to the 1214 maximum of its current value, or the number of response 1215 variable bindings still required for this requested 1216 variable binding. 1218 - The AgentX PDUs are sent, received, and processed 1219 according to the procedures in section 7.2.3. 1221 - This process continues iteratively until a complete SNMP 1222 response PDU has been built, or until there are no target 1223 region lexicographical successors. 1225 7.2.4. Sending the SNMP Response PDU 1227 Once the processing described in sections 7.2.1 - 7.2.3 is 1228 complete, there is an SNMP response PDU available. The master agent 1229 now implements the Elements of Procedure for the applicable version 1230 of the SNMP protocol in order to encapsulate the PDU into a message, 1231 and transmit it to the originator of the SNMP management request. 1233 Note that this may also involve altering the PDU contents for agents 1234 that support the SNMP version 1 framework. 1236 [Do we need to mention explicit mappings? For instance, for v2 1237 Set error codes?] 1239 8. Master Agent Transport Mappings 1241 [TBD] 1243 9. Security Considerations 1245 Security issues are not discussed in this memo. 1247 10. Acknowledgements 1249 The initial draft of this memo was heavily influenced by the DPI 1250 2.0 specification [7]. 1252 This document was produced by the IETF Agent Extensibility 1253 (AgentX) Working Group. 1255 11. References 1257 [1] Information processing systems - Open Systems Interconnection - 1258 Specification of Abstract Syntax Notation One (ASN.1), 1259 International Organization for Standardization. International 1260 Standard 8824, (December, 1987). 1262 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1263 S. Waldbusser, "Structure of Management Information for Version 2 1264 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1265 January 1996. 1267 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1268 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 1269 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1271 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1272 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 1273 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1275 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1276 S. Waldbusser, "Management Information Base for Version 2 of the 1277 Simple Network Management Protocol (SNMPv2)", RFC 1907, 1278 January 1996. 1280 [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1281 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 1282 Systems International, MIT Laboratory for Computer Science, May 1283 1990. 1285 [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters, 1286 "Simple Network Management Protocol: Distributed Protocol 1287 Interface, Version 2.0", RFC 1592, T.J. Watson Research Center, 1288 IBM Corp., Bell Northern Research, Ltd., March 1994.