|
|
1.1 ! root 1: ! 2: ! 3: ! 4: ! 5: draft SMUX May 1990 ! 6: ! 7: ! 8: SNMP MUX Protocol and MIB ! 9: ! 10: Sun May 13 14:53:58 1990 ! 11: ! 12: ! 13: Marshall T. Rose ! 14: ! 15: Performance Systems International, Inc. ! 16: 11800 Sunrise Valley Drive ! 17: Suite 1100 ! 18: Reston, VA 22091 ! 19: ! 20: [email protected] ! 21: ! 22: ! 23: ! 24: ! 25: ! 26: ! 27: 1. Status of this Memo ! 28: ! 29: This document defines a mechanism by which multiple UNIX ! 30: daemons may communicate with the local SNMP agent on a host. ! 31: This is a local mechanism. ! 32: ! 33: ! 34: ! 35: ! 36: ! 37: ! 38: ! 39: ! 40: ! 41: ! 42: ! 43: ! 44: ! 45: ! 46: ! 47: ! 48: ! 49: ! 50: ! 51: ! 52: ! 53: ! 54: ! 55: ! 56: ! 57: ! 58: M.T. Rose [Page 1] ! 59: ! 60: ! 61: ! 62: ! 63: ! 64: draft SMUX May 1990 ! 65: ! 66: ! 67: 2. Introduction ! 68: ! 69: On kernel/user systems such as BSD UNIX, an agent speaking the ! 70: SNMP [1] is often implemented as a user-process, which reads ! 71: kernel variables in order to realize the Internet-standard MIB ! 72: [2]. This approach works fine as long as all of the ! 73: information needed by the SNMP agent resides in either the ! 74: kernel or in stable storage (i.e., files). However, when ! 75: other user-processes are employed to implement other network ! 76: services, such as routing protocols, communication between the ! 77: SNMP agent the and other processes is problematic. ! 78: ! 79: In order to solve this problem, a new protocol, the SNMP ! 80: multiplexing (SMUX) protocol is introduced. When a user- ! 81: process, termed a SMUX peer, wishes to export a MIB module, it ! 82: initiates a SMUX association to the local SNMP agent, ! 83: registers itself, and (later) fields management operations for ! 84: objects in the MIB module. ! 85: ! 86: Carrying this approach to its fullest, it is possible to ! 87: generalize the SNMP agent so that it knows about only the SNMP ! 88: group of the Internet-standard MIB. All other portions of the ! 89: Internet-standard MIB can be implemented by another process. ! 90: This is quite useful, for example, when a computer ! 91: manufacturer wishes to provide SNMP access for its operating ! 92: system in binary form. ! 93: ! 94: In addition to defining the SMUX protocol, this document ! 95: defines a MIB for the SMUX. Obviously, this MIB module must ! 96: also be implemented in the local SNMP agent. ! 97: ! 98: ! 99: ! 100: ! 101: ! 102: ! 103: ! 104: ! 105: ! 106: ! 107: ! 108: ! 109: ! 110: ! 111: ! 112: ! 113: ! 114: ! 115: ! 116: ! 117: M.T. Rose [Page 2] ! 118: ! 119: ! 120: ! 121: ! 122: ! 123: draft SMUX May 1990 ! 124: ! 125: ! 126: 3. Architecture ! 127: ! 128: There are two approaches that can be taken when trying to ! 129: integrate arbitrary MIB modules with the SNMP agent: request- ! 130: response and cache-ahead. ! 131: ! 132: The request-response model simply propagates the SNMP requests ! 133: received by the SNMP agent to the user process which exported ! 134: the MIB module. The SMUX peer then performs the operation and ! 135: returns a response. In turn, the SNMP agent propagates this ! 136: response back to the network management station. The ! 137: request-response model is said to be agent-driven since, after ! 138: registration, the SNMP agent initiates all transactions. ! 139: ! 140: The cache-ahead model requires that the SMUX peer, after ! 141: registration, periodically updates the SNMP agent with the ! 142: subtree for the MIB module which has been registered. The ! 143: SNMP agent, upon receiving an SNMP request, locally performs ! 144: the operation, and returns a response to the network ! 145: management station. The cache-ahead model is said to be ! 146: peer-driven since, after registration, the SMUX peer initiates ! 147: all transactions. ! 148: ! 149: There are advantages and disadvantages to both approaches. As ! 150: such, the architecture envisioned supports both models in the ! 151: following fashion: the protocol between the SNMP agent and the ! 152: SMUX peer is based on the request-response model. However, ! 153: the SMUX peer, may itself be a user-process which employs the ! 154: cache-ahead model with other user-processes. ! 155: ! 156: Obviously, the SMUX peer which employs the cache-ahead model ! 157: acts as a "firewall" for those user-processes which actually ! 158: implement the managed objects in the given MIB module. ! 159: ! 160: Note that this document describes only the SMUX protocol, for ! 161: the request-response model. Each SMUX peer is free to define ! 162: a cache-ahead protocol specific for the application at hand. ! 163: ! 164: ! 165: ! 166: ! 167: ! 168: ! 169: ! 170: ! 171: ! 172: ! 173: ! 174: ! 175: ! 176: M.T. Rose [Page 3] ! 177: ! 178: ! 179: ! 180: ! 181: ! 182: draft SMUX May 1990 ! 183: ! 184: ! 185: 4. Protocol ! 186: ! 187: The SMUX protocol is simple: the SNMP agent listens for ! 188: incoming connections. Upon establishing a connection, the ! 189: SMUX peer issues an OpenPDU to initialize the SMUX ! 190: association. If the SNMP agent declines the association, it ! 191: issues a closePDU and closes the connection. If the SNMP ! 192: agent accepts the association, no response is issued by the ! 193: SNMP agent. ! 194: ! 195: For each subtree defined in a MIB module that the SMUX peer ! 196: wishes to register (or unregister), the SMUX peer issues a ! 197: RReqPDU. When the SNMP agent receives such a PDU, it issues a ! 198: corresponding RRspPDU. The SNMP agent returns RRspPDUs in the ! 199: same order as the RReqPDUs were received. ! 200: ! 201: When the SMUX peer wishes to issue a trap, it issues an SNMP ! 202: Trap-PDU. When the SNMP agent receives such a PDU, it ! 203: propagates this to the network management stations that it is ! 204: configured to send traps to. ! 205: ! 206: When the SNMP agent receives an SNMP GetRequest-PDU, ! 207: GetNextRequest-PDU, or SetRequest-PDU which includes one or ! 208: more variable-bindings within a subtree registered by a SMUX ! 209: peer, the SNMP agent sends an equivalent SNMP PDU containing ! 210: only those variables within the subtree registered by that ! 211: SMUX peer. When the SMUX peer receives such a PDU, it applies ! 212: the indicated operation and issues a corresponding SNMP ! 213: GetResponse-PDU. The SNMP agent then correlates this result ! 214: and propagates the resulting GetResponse-PDU to the network ! 215: management station. ! 216: ! 217: When either the SNMP agent or the SMUX peer wishes to release ! 218: the SMUX association, the ClosePDU is issued and the ! 219: connection is closed. ! 220: ! 221: ! 222: 4.1. Tricky Things ! 223: ! 224: Although straight-forward, there are a few nuances. ! 225: ! 226: ! 227: ! 228: ! 229: ! 230: ! 231: ! 232: ! 233: ! 234: ! 235: M.T. Rose [Page 4] ! 236: ! 237: ! 238: ! 239: ! 240: ! 241: draft SMUX May 1990 ! 242: ! 243: ! 244: 4.1.1. Registration ! 245: ! 246: Associated with each registration is an integer priority, from ! 247: 0 to (2^31)-1. The lower the value, the higher the priority. ! 248: ! 249: Multiple SMUX peers may register the same subtree. However, ! 250: they must do so at different priorities (i.e., a subtree and a ! 251: priority uniquely identifies a SMUX peer). As such, if a SMUX ! 252: peer wishes to register a subtree at a priority which is ! 253: already taken, the SNMP agent repeatedly increments the ! 254: integer value until an unused priority is found. ! 255: ! 256: When registering a subtree, the special priority -1 may be ! 257: used, which selects the highest available priority. ! 258: ! 259: Of course, the SNMP agent may select an arbitrarily worse ! 260: priority for a SMUX peer, based on local (configuration) ! 261: information. ! 262: ! 263: Note that when a subtree is registered, the SMUX peer with the ! 264: highest registration priority is exclusively consulted for all ! 265: operations on that subtree. Further note that SNMP agents ! 266: must enforce the "subtree mounting effect", which hides the ! 267: registrations by other SMUX peers of objects within the ! 268: subtree. For example, if a SMUX peer registered "sysDescr", ! 269: and later another SMUX peer registered "system" (which scopes ! 270: "sysDescr"), then all requests for "sysDescr" would be given ! 271: to the latter SMUX peer. ! 272: ! 273: An SNMP agent should disallow any attempt to register at or ! 274: within the SNMP and SMUX subtrees of the MIB. Other subtrees ! 275: may be disallowed as an implementation-specific option. ! 276: ! 277: ! 278: 4.1.2. Removing Registration ! 279: ! 280: A SMUX peer may remove registrations for only those subtrees ! 281: which it has registered. If the priority given in the RReq- ! 282: PDU is -1, then the registration of highest priority is ! 283: selected for deletion. Otherwise, only that registration with ! 284: the precise registration is selected. ! 285: ! 286: ! 287: ! 288: ! 289: ! 290: ! 291: ! 292: ! 293: ! 294: M.T. Rose [Page 5] ! 295: ! 296: ! 297: ! 298: ! 299: ! 300: draft SMUX May 1990 ! 301: ! 302: ! 303: 4.1.3. Variables in Requests ! 304: ! 305: When constructing an SNMP GetRequest-PDU, GetNextRequest-PDU, ! 306: or SetRequest-PDU, for a SMUX peer, the SNMP agent may send ! 307: one, or more than one variable in a single request. In all ! 308: cases, the SNMP agent should process each variable ! 309: sequentially, and block accordingly when a SMUX peer is ! 310: contacted. ! 311: ! 312: ! 313: 4.1.4. Request-ID ! 314: ! 315: When the SNMP agent constructs an SNMP GetRequest-PDU, ! 316: GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer, the ! 317: request_id field of the SNMP takes a special meaning. ! 318: Basically, this field should take a different value for each ! 319: SNMP PDU received by the SNMP agent. As such, if an SNMP ! 320: agent generates multiple PDUs for a SMUX peer, upon receipt of ! 321: a single PDU from the network management station, then the ! 322: request_id field of the PDUs sent to the SMUX peer takes the ! 323: same value (which need bear no relationship to the value of ! 324: the request_id field of the PDU originally received by the ! 325: SNMP agent.) ! 326: ! 327: ! 328: 4.1.5. The powerful get-next operator ! 329: ! 330: Each SMUX peer acts as though it contains the entire MIB when ! 331: processing the powerful get-next operator. This means that ! 332: the SNMP agent must check each variable named returned in the ! 333: SNMP GetResponse-PDU generated by a SMUX peer and see if it is ! 334: in the subtree of the managed object corresponding to original ! 335: SNMP GetNextRequest-PDU. If not, the SNMP agent will apply ! 336: the get-next operator to the next managed object. This may ! 337: result in contacting a different SMUX peer, depending on the ! 338: registration topology. ! 339: ! 340: ! 341: 4.2. Protocol Data Units ! 342: ! 343: The SMUX protocol data units are defined using Abstract Syntax ! 344: Notation One (ASN.1) [3]: ! 345: ! 346: SMUX DEFINITIONS ::= BEGIN ! 347: ! 348: ! 349: ! 350: ! 351: ! 352: ! 353: M.T. Rose [Page 6] ! 354: ! 355: ! 356: ! 357: ! 358: ! 359: draft SMUX May 1990 ! 360: ! 361: ! 362: IMPORTS ! 363: DisplayString, ObjectName ! 364: FROM RFC1155-SMI ! 365: ! 366: PDUs ! 367: FROM RFC1157-SNMP; ! 368: ! 369: ! 370: -- tags for SMUX-specific PDUs are application-wide to ! 371: -- avoid conflict with tags for current (and future) ! 372: -- SNMP-generic PDUs ! 373: ! 374: SMUX-PDUs ::= ! 375: CHOICE { ! 376: open -- SMUX peer uses ! 377: OpenPDU, -- immediately after TCP open ! 378: ! 379: close -- either uses immediately before TCP close ! 380: ClosePDU, ! 381: ! 382: registerRequest -- SMUX peer uses ! 383: RReqPDU, ! 384: ! 385: registerResponse -- SNMP agent uses ! 386: RRspPDU, ! 387: ! 388: PDUs -- note that roles are reversed: ! 389: -- SNMP agent does get/get-next/set ! 390: -- SMUX peer does get-response/trap ! 391: } ! 392: ! 393: ! 394: -- open PDU ! 395: -- currently only simple authentication ! 396: ! 397: OpenPDU ::= ! 398: CHOICE { ! 399: simple ! 400: SimpleOpen ! 401: } ! 402: ! 403: SimpleOpen ::= ! 404: [APPLICATION 0] IMPLICIT ! 405: SEQUENCE { ! 406: version -- of SMUX protocol ! 407: ! 408: ! 409: ! 410: ! 411: ! 412: M.T. Rose [Page 7] ! 413: ! 414: ! 415: ! 416: ! 417: ! 418: draft SMUX May 1990 ! 419: ! 420: ! 421: INTEGER { ! 422: version-1(0) ! 423: }, ! 424: ! 425: identity -- of SMUX peer, authoritative ! 426: OBJECT IDENTIFIER, ! 427: ! 428: description -- of SMUX peer, implementation-specific ! 429: DisplayString, ! 430: ! 431: password -- zero length indicates no authentication ! 432: OCTET STRING ! 433: } ! 434: ! 435: ! 436: -- close PDU ! 437: ! 438: ClosePDU ::= ! 439: [APPLICATION 1] IMPLICIT ! 440: INTEGER { ! 441: goingDown(0), ! 442: unsupportedVersion(1), ! 443: packetFormat(2), ! 444: protocolError(3), ! 445: internalError(4), ! 446: authenticationFailure(5) ! 447: } ! 448: ! 449: ! 450: -- insert PDU ! 451: ! 452: RReqPDU ::= ! 453: [APPLICATION 2] IMPLICIT ! 454: SEQUENCE { ! 455: subtree ! 456: ObjectName, ! 457: ! 458: priority -- the lower the better, "-1" means default ! 459: INTEGER (-1..2147483647), ! 460: ! 461: operation ! 462: INTEGER { ! 463: delete(0), ! 464: readOnly(1), ! 465: readWrite(2) ! 466: ! 467: ! 468: ! 469: ! 470: ! 471: M.T. Rose [Page 8] ! 472: ! 473: ! 474: ! 475: ! 476: ! 477: draft SMUX May 1990 ! 478: ! 479: ! 480: } ! 481: } ! 482: ! 483: RRspPDU ::= ! 484: [APPLICATION 3] IMPLICIT ! 485: INTEGER { ! 486: failure(-1) ! 487: ! 488: -- on success the non-negative priority is returned ! 489: } ! 490: ! 491: END ! 492: ! 493: ! 494: ! 495: 4.3. Mappings on Transport Service ! 496: ! 497: The SMUX protocol may be mapped onto any CO-mode transport ! 498: service. At present, only one such mapping is defined. ! 499: ! 500: ! 501: 4.3.1. Mapping onto the TCP ! 502: ! 503: When using the TCP to provide the transport-backing for the ! 504: SMUX protocol, the SNMP agent listens on TCP port 199. ! 505: ! 506: Each SMUX PDU is serialized using the Basic Encoding Rules [4] ! 507: and sent on the TCP. As ASN.1 objects are self-delimiting ! 508: when encoding using the BER, so no packetization protocol is ! 509: required. ! 510: ! 511: ! 512: ! 513: ! 514: ! 515: ! 516: ! 517: ! 518: ! 519: ! 520: ! 521: ! 522: ! 523: ! 524: ! 525: ! 526: ! 527: ! 528: ! 529: ! 530: M.T. Rose [Page 9] ! 531: ! 532: ! 533: ! 534: ! 535: ! 536: draft SMUX May 1990 ! 537: ! 538: ! 539: 5. MIB for the SMUX ! 540: ! 541: The MIB objects for the SMUX are implemented by the local SNMP ! 542: agent: ! 543: ! 544: SMUX-MIB DEFINITIONS ::= BEGIN ! 545: ! 546: IMPORTS ! 547: enterprises, OBJECT-TYPE, ObjectName ! 548: FROM RFC1155-SMI; ! 549: ! 550: ! 551: unix OBJECT IDENTIFIER ::= { enterprises 4 } ! 552: ! 553: ! 554: smux OBJECT IDENTIFIER ::= { unix 4 } ! 555: ! 556: smuxPeerTable OBJECT-TYPE ! 557: SYNTAX SEQUENCE OF SmuxPeerEntry ! 558: ACCESS not-accessible ! 559: STATUS mandatory ! 560: ::= { smux 1 } ! 561: ! 562: smuxPeerEntry OBJECT-TYPE ! 563: SYNTAX SmuxPeerEntry ! 564: ACCESS not-accessible ! 565: STATUS mandatory ! 566: -- INDEX { smuxPindex } ! 567: ::= { smuxPeerTable 1} ! 568: ! 569: SmuxPeerEntry ::= SEQUENCE { ! 570: smuxPindex ! 571: INTEGER, ! 572: smuxPidentity ! 573: OBJECT IDENTIFIER, ! 574: smuxPdescription ! 575: DisplayString, ! 576: smuxPstatus ! 577: INTEGER ! 578: } ! 579: ! 580: smuxPindex OBJECT-TYPE ! 581: SYNTAX INTEGER ! 582: ACCESS read-write ! 583: STATUS mandatory ! 584: ! 585: ! 586: ! 587: ! 588: ! 589: M.T. Rose [Page 10] ! 590: ! 591: ! 592: ! 593: ! 594: ! 595: draft SMUX May 1990 ! 596: ! 597: ! 598: ::= { smuxPeerEntry 1 } ! 599: ! 600: smuxPidentity OBJECT-TYPE ! 601: SYNTAX OBJECT IDENTIFIER ! 602: ACCESS read-write ! 603: STATUS mandatory ! 604: ::= { smuxPeerEntry 2 } ! 605: ! 606: smuxPdescription OBJECT-TYPE ! 607: SYNTAX DisplayString (SIZE (0..255)) ! 608: ACCESS read-write ! 609: STATUS mandatory ! 610: ::= { smuxPeerEntry 3 } ! 611: ! 612: smuxPstatus OBJECT-TYPE ! 613: SYNTAX INTEGER { valid(1), invalid(2), connecting(3) } ! 614: ACCESS read-write ! 615: STATUS mandatory ! 616: ::= { smuxPeerEntry 4 } ! 617: ! 618: smuxTreeTable OBJECT-TYPE ! 619: SYNTAX SEQUENCE OF SmuxTreeEntry ! 620: ACCESS not-accessible ! 621: STATUS mandatory ! 622: ::= { smux 2 } ! 623: ! 624: smuxTreeEntry OBJECT-TYPE ! 625: SYNTAX SmuxTreeEntry ! 626: ACCESS not-accessible ! 627: STATUS mandatory ! 628: ::= { smuxTreeTable 1} ! 629: ! 630: SmuxTreeEntry ::= SEQUENCE { ! 631: smuxTsubtree ! 632: ObjectName ! 633: smuxTpriority ! 634: INTEGER, ! 635: smuxTindex ! 636: INTEGER, ! 637: smuxTstatus ! 638: INTEGER ! 639: } ! 640: ! 641: smuxTsubtree OBJECT-TYPE ! 642: SYNTAX ObjectName ! 643: ! 644: ! 645: ! 646: ! 647: ! 648: M.T. Rose [Page 11] ! 649: ! 650: ! 651: ! 652: ! 653: ! 654: draft SMUX May 1990 ! 655: ! 656: ! 657: ACCESS read-write ! 658: STATUS mandatory ! 659: -- INDEX { smuxTsubtree, smuxTpriority } ! 660: ::= { smuxTreeEntry 1 } ! 661: ! 662: smuxTpriority OBJECT-TYPE ! 663: SYNTAX INTEGER (0..2147483647) ! 664: ACCESS read-write ! 665: STATUS mandatory ! 666: ::= { smuxTreeEntry 2 } ! 667: ! 668: smuxTindex OBJECT-TYPE ! 669: SYNTAX INTEGER (0..2147483647) ! 670: ACCESS read-write ! 671: STATUS mandatory ! 672: ::= { smuxTreeEntry 3 } ! 673: ! 674: smuxTstatus OBJECT-TYPE ! 675: SYNTAX INTEGER { valid(1), invalid(2) } ! 676: ACCESS read-write ! 677: STATUS mandatory ! 678: ::= { smuxTreeEntry 4 } ! 679: ! 680: END ! 681: ! 682: ! 683: ! 684: 5.1. Identification of OBJECT instances for use with the ! 685: SNMP ! 686: ! 687: The names for all object types in the MIB are defined ! 688: explicitly either in the Internet-standard MIB or in other ! 689: documents which conform to the naming conventions of the ! 690: SMI[5]. The SMI requires that conformant management protocols ! 691: define mechanisms for identifying individual instances of ! 692: those object types for a particular network element. ! 693: ! 694: Each instance of any object type defined in the MIB is ! 695: identified in SNMP operations by a unique name called its ! 696: "variable name." In general, the name of an SNMP variable is ! 697: an OBJECT IDENTIFIER of the form x.y, where x is the name of a ! 698: non-aggregate object type defined in the MIB and y is an ! 699: OBJECT IDENTIFIER fragment that, in a way specific to the ! 700: named object type, identifies the desired instance. ! 701: ! 702: ! 703: ! 704: ! 705: ! 706: ! 707: M.T. Rose [Page 12] ! 708: ! 709: ! 710: ! 711: ! 712: ! 713: draft SMUX May 1990 ! 714: ! 715: ! 716: This naming strategy admits the fullest exploitation of the ! 717: semantics of the powerful SNMP get-next operator, because it ! 718: assigns names for related variables so as to be contiguous in ! 719: the lexicographical ordering of all variable names known in ! 720: the MIB. ! 721: ! 722: The type-specific naming of object instances is defined below ! 723: for a number of classes of object types. Instances of an ! 724: object type to which none of the following naming conventions ! 725: are applicable are named by OBJECT IDENTIFIERs of the form ! 726: x.0, where x is the name of said object type in the MIB ! 727: definition. ! 728: ! 729: For example, suppose one wanted to identify an instance of the ! 730: variable sysDescr. The object class for sysDescr is: ! 731: ! 732: iso org dod internet mgmt mib system sysDescr ! 733: 1 3 6 1 2 1 1 1 ! 734: ! 735: Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which ! 736: is appended an instance sub-identifier of 0. That is, ! 737: 1.3.6.1.2.1.1.1.0 identifies the one and only instance of ! 738: sysDescr. ! 739: ! 740: ! 741: 5.1.1. smuxPeerTable Object Type Names ! 742: ! 743: The name of a SMUX peer relationship, s, is the OBJECT ! 744: IDENTIFIER value of the form i, where i has the value of that ! 745: instance of the smuxPindex object type associated with s. ! 746: ! 747: For each object type, t, for which the defined name, n, has a ! 748: prefix of smuxPeerEntry, an instance, i, of t is named by an ! 749: OBJECT IDENTIFIER of the form n.s, where s is the name of the ! 750: SMUX peer relationship about which i represents information. ! 751: ! 752: For example, suppose one wanted to identify the instance of ! 753: the variable smuxPidentity associated with peer relationship ! 754: number 2. Accordingly, smuxPidentity.2 would identify the ! 755: desired instance. ! 756: ! 757: ! 758: ! 759: ! 760: ! 761: ! 762: ! 763: ! 764: ! 765: ! 766: M.T. Rose [Page 13] ! 767: ! 768: ! 769: ! 770: ! 771: ! 772: draft SMUX May 1990 ! 773: ! 774: ! 775: 5.1.2. smuxTreeTable Object Type Names ! 776: ! 777: The name of a SMUX subtree relationship, s, is the OBJECT ! 778: IDENTIFIER value of the form i.j, where i has the value of ! 779: that instance of the smuxTsubtree object type, and j has the ! 780: value of that instance of the smuxTpriority object type, ! 781: associated with s. ! 782: ! 783: For each object type, t, for which the defined name, n, has a ! 784: prefix of smuxTreeEntry, an instance, i, of t is named by an ! 785: OBJECT IDENTIFIER of the form n.s.t.u, where s is the number ! 786: of sub-identifiers in the corresponding instance of ! 787: smuxTsubtree, t is the value of the instance of smuxTsubtree ! 788: corresponding to this entry, and u is the value of the ! 789: instance of smuxTpriority corresponding to this entry. ! 790: ! 791: For example, suppose one wanted to identify the instance of ! 792: the variable smuxTindex associated with the subtree 1.3.6.1.5 ! 793: for priority 3. Accordingly, smuxTindex.5.1.3.6.1.5.3 would ! 794: identify the desired instance. ! 795: ! 796: ! 797: ! 798: ! 799: ! 800: ! 801: ! 802: ! 803: ! 804: ! 805: ! 806: ! 807: ! 808: ! 809: ! 810: ! 811: ! 812: ! 813: ! 814: ! 815: ! 816: ! 817: ! 818: ! 819: ! 820: ! 821: ! 822: ! 823: ! 824: ! 825: M.T. Rose [Page 14] ! 826: ! 827: ! 828: ! 829: ! 830: ! 831: draft SMUX May 1990 ! 832: ! 833: ! 834: 6. Acknowledgements ! 835: ! 836: SMUX was designed one afternoon by these people: ! 837: ! 838: Jeffrey S. Case, UTK-CS ! 839: James R. Davin, MIT-LCS ! 840: Mark S. Fedor, PSI ! 841: Jeffrey C. Honig, Cornell ! 842: Louie A. Mamakos, UMD ! 843: Michael G. Petry, UMD ! 844: Yakov Rekhter, IBM ! 845: Marshall T. Rose, PSI ! 846: ! 847: ! 848: ! 849: ! 850: ! 851: ! 852: ! 853: ! 854: ! 855: ! 856: ! 857: ! 858: ! 859: ! 860: ! 861: ! 862: ! 863: ! 864: ! 865: ! 866: ! 867: ! 868: ! 869: ! 870: ! 871: ! 872: ! 873: ! 874: ! 875: ! 876: ! 877: ! 878: ! 879: ! 880: ! 881: ! 882: ! 883: ! 884: M.T. Rose [Page 15] ! 885: ! 886: ! 887: ! 888: ! 889: ! 890: draft SMUX May 1990 ! 891: ! 892: ! 893: 7. References ! 894: ! 895: [1] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, ! 896: Simple Network Management Protocol, Internet Working ! 897: Group Request for Comments 1157. Network Information ! 898: Center, SRI International, Menlo Park, California, (May, ! 899: 1990). ! 900: ! 901: [2] K. McCloghrie and M.T. Rose, Management Information Base ! 902: for Network Management of TCP/IP-based internets, ! 903: Internet Working Group Request for Comments 1156. ! 904: Network Information Center, SRI International, Menlo ! 905: Park, California, (May, 1990). ! 906: ! 907: [3] Information processing systems - Open Systems ! 908: Interconnection - Specification of Abstract Syntax ! 909: Notation One (ASN.1), International Organization for ! 910: Standardization. International Standard 8824, (December, ! 911: 1987). ! 912: ! 913: [4] Information processing systems - Open Systems ! 914: Interconnection - Specification of Basic Encoding Rules ! 915: for Abstract Notation One (ASN.1), International ! 916: Organization for Standardization. International Standard ! 917: 8825, (December, 1987). ! 918: ! 919: [5] M.T. Rose and K. McCloghrie, Structure and Identification ! 920: of Management Information for TCP/IP-based internets, ! 921: Internet Working Group Request for Comments 1155. ! 922: Network Information Center, SRI International, Menlo ! 923: Park, California, (May, 1990). ! 924: ! 925: ! 926: ! 927: ! 928: ! 929: ! 930: ! 931: ! 932: ! 933: ! 934: ! 935: ! 936: ! 937: ! 938: ! 939: ! 940: ! 941: ! 942: ! 943: M.T. Rose [Page 16] ! 944: ! 945: ! 946: ! 947: ! 948: ! 949: draft SMUX May 1990 ! 950: ! 951: ! 952: Table of Contents ! 953: ! 954: ! 955: 1 Status of this Memo ................................... 1 ! 956: 2 Introduction .......................................... 2 ! 957: 3 Architecture .......................................... 3 ! 958: 4 Protocol .............................................. 4 ! 959: 4.1 Tricky Things ....................................... 4 ! 960: 4.1.1 Registration ...................................... 5 ! 961: 4.1.2 Removing Registration ............................. 5 ! 962: 4.1.3 Variables in Requests ............................. 6 ! 963: 4.1.4 Request-ID ........................................ 6 ! 964: 4.1.5 The powerful get-next operator .................... 6 ! 965: 4.2 Protocol Data Units ................................. 6 ! 966: 4.3 Mappings on Transport Service ....................... 9 ! 967: 4.3.1 Mapping onto the TCP .............................. 9 ! 968: 5 MIB for the SMUX ...................................... 10 ! 969: 5.1 Identification of OBJECT instances for use with ! 970: the SNMP ........................................... 12 ! 971: 5.1.1 smuxPeerTable Object Type Names ................... 13 ! 972: 5.1.2 smuxTreeTable Object Type Names ................... 14 ! 973: 6 Acknowledgements ...................................... 15 ! 974: 7 References ............................................ 16 ! 975: ! 976: ! 977: ! 978: ! 979: ! 980: ! 981: ! 982: ! 983: ! 984: ! 985: ! 986: ! 987: ! 988: ! 989: ! 990: ! 991: ! 992: ! 993: ! 994: ! 995: ! 996: ! 997: ! 998: ! 999: ! 1000: ! 1001: ! 1002: M.T. Rose [Page 17] ! 1003:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.