home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-romanov-00.txt < prev    next >
Text File  |  1997-09-03  |  9KB  |  236 lines
  1.  
  2. INTERNET-DRAFT          EXPIRES: SEPTEMBER 1997       INTERNET-DRAFT
  3.  
  4. Network Working Group                                      A.Romanov
  5. Internet Draft                                   Quality Quorum, Inc
  6. Category: Informational                                   March 1997
  7. Expire in six months
  8.  
  9.  
  10. Practical Approach to Improving Scalability  and 
  11. Interoperability of SNMP Applications
  12. <draft-rfced-info-romanov-00.txt>
  13.  
  14. Status of this Memo
  15.  
  16. This document is an Internet-Draft.  Internet-Drafts are working
  17. documents of the Internet Engineering task Force (IETF), its areas,
  18. and its working groups.  Note that other groups may also distribute
  19. working documents as Internet-Drafts.
  20.  
  21. Internet-Drafts are draft documents valid for a maximum of six
  22. months and may be updated, replaced, or obsoleted by other
  23. documents at any time.  It is inappropriate to use Internet-Drafts
  24. as reference material or to cite them other than as "work in
  25. progress".
  26.  
  27. To learn the current status of any Internet-Draft, please check the
  28. "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  29. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31. ftp.isi.edu (US West Coast).
  32.  
  33. Abstract
  34.  
  35. The goal of this memo is to provide a simple solution for apparent practical
  36. problem of scalability and interoperability of network management
  37. applications.
  38.  
  39.  
  40. Table of Contents
  41.  
  42. 1. Introduction
  43. 2. Proposed Solution
  44. 3. MIB Definitions
  45. 4. Acknowledgments
  46. 5. References
  47.  
  48. 1.  Introduction
  49.  
  50. Both the SNMPv1 protocol (RFC1157 [1]) and the SNMPv2 protocol (RFC1905 [2])
  51. were developed with the goal of providing scalable  network management
  52. environment. However, both these protocols did not specify limits on the
  53. complexity of the SET requests.  At the same time both these protocols
  54. required 100% atomicity  (also known "as if simultaneous" principle) of SET 
  55. requests.  These two requirements combined can be satisfied only by 
  56. impractically complex SNMP agents.  So, these requirements were ignored to
  57. one or another degree by practically all existing SNMP agent implementations
  58. accepting SET requests. 
  59.  
  60. In this environment network management applications (NMA) have no other way
  61. than to accept worse case and use less common denominator approach by 
  62. utilizing only simplest forms SET requests in all cases. So, NMA with
  63. additional information is not able to utilize capabilities of high end
  64. SNMP agent implementations, so SNMP is not so good scaling up, it also
  65. has negative impact on interoprability between NMAs and network devices
  66. provided by diffrenet vendors. 
  67.  
  68.  
  69. 2.  Proposed Solution
  70.  
  71. It seems imperative to find practical solution  allowing  (1)really simple
  72. SNMP agent implementations, (2) NMAs able to adapt itself to both exploiting
  73. full capabilities of high end SNMP agents and utilizing modest capabilites
  74. of low end implementations. Proposed solution consists of two parts:
  75. (a) an implementation agreement to use error-status 'inconsistenValue'  by 
  76. SNMPv2 agents and 'badValue' by SNMPv1 agents to reject SET requests whose
  77. complexity exceeds agent abilities to process it, (b) MIB variables allowing
  78. NMAs to get information about acceptable level of SET request complexity for
  79. given SNMP agent before sending any requests.
  80.  
  81. This solution is (1)simple, (2)compliant with both SNMPv1 and SNMPv2, 
  82. (3)backward compatible with existing implementations.
  83.  
  84.  
  85. 3.  MIB Definitions
  86.  
  87. QQI-MIB DEFINITIONS ::= BEGIN
  88.  
  89. IMPORTS
  90.     enterprises  FROM SNMPv2-SMI;
  91.  
  92. qqiMIB MODULE-IDENTITY
  93.     LAST-UPDATED "9703010000Z"
  94.     ORGANIZATION "Quality Quorum, Inc."
  95.     CONTACT-INFO
  96.             "        Aleksey Romanov
  97.            Email:  qqi@world.std.com"
  98.     DESCRIPTION
  99.             "QQI private MIB tree."
  100.     REVISION      "9703010000Z"
  101.     DESCRIPTION
  102.             "The initial revision of this MIB module."
  103.     ::= { enterprises  3023 }
  104.  
  105. END
  106.  
  107.  
  108.  
  109.  
  110. QQI-PUBLIC-MIB DEFINITIONS ::= BEGIN
  111.  
  112. IMPORTS
  113.     qqiMIB  FROM QQI-MIB;
  114.  
  115. qqiPublicMIB MODULE-IDENTITY
  116.     LAST-UPDATED "9703010000Z"
  117.     ORGANIZATION "Quality Quorum, Inc."
  118.     CONTACT-INFO
  119.             "        Aleksey Romanov
  120.            Email:  qqi@world.std.com"
  121.     DESCRIPTION
  122.             "Part of QQI private MIB tree intended for public use."
  123.     REVISION      "9703010000Z"
  124.     DESCRIPTION
  125.             "The initial revision of this MIB module."
  126.     ::= { qqiMIB   25 }
  127.  
  128. -- Group providing information about acceptable complexity of
  129. -- of  SET requests for given SNMP agent
  130.  
  131. qqiPublicGroups OBJECT IDENTIFIER ::= { qqiPublicMIB  1}
  132. qqiSetRequest   OBJECT IDENTIFIER ::= { qqiPublicGroups 1 }
  133.  
  134. qqiSetLevel OBJECT-TYPE
  135.     SYNTAX      INTEGER(0..7)
  136.     MAX-ACCESS  read-only
  137.     STATUS      current
  138.     DESCRIPTION
  139.         "The relative measure of SET request complexity acceptable for 
  140.          given SNMP agent. Its values has to be interpreted as follows:
  141.              0  - the most primitive form of SNMP agent, it can reliably
  142.                   process  SET request which limited to single instance or 
  143.                   single row in the conceptual table. Also it is not able
  144.                   to identify and reject too complex request,
  145.              1  - Same as '0' plus it is able to process 'snmpSetSerialNo',
  146.              2  - Same as '1' plus it is able to reliably identify and reject
  147.                   too complex SET request (this is lowest level of really 
  148.                   compliant SNMP implementation),
  149.              3  - Same as '2' plus it is able to process simplest case of
  150.                   multiple rows/scalars in one PDU, e.g. it is able to add
  151.                   several new PVCs to ATM switch configuration, however,
  152.                   it will be unable  to properly process resource reallocation
  153.                   within a request, e.g. to reuse VCI freed by PVC being
  154.                   deleted in PVC being created by the same request,
  155.              4  - Same as '2'  plus it is able to process complex updates
  156.                   of multiple rows within a single table,
  157.              5  - Same as '3' plus it is able to process simple updates in
  158.                   several tables simultaneously,
  159.              6  - Same as '4' plus it is able to process complex updates in
  160.                   several rows simultaneously,
  161.              7  - No limits.
  162.          For all practical purposes all agents which do not implement this
  163.          variable should be considered of level 0."
  164.     ::= { qqiSetRequest 1 }
  165.  
  166. qqiSetLimit OBJECT-TYPE
  167.     SYNTAX      INTEGER(1..65535)
  168.     MAX-ACCESS  read-only
  169.     STATUS      current
  170.     DESCRIPTION
  171.         "Limit on the number of rows/scalars to be processed by SNMP agent
  172.         having value of qqiSetLevel in the range of (3..6). This value is
  173.         not applicable to SNMP agent with qqiSetLevels 0, 1, 2, and 7."
  174.    ::= { qqiSetRequest 2 }
  175.  
  176. -- Conformance statements
  177. qqiPublicMIBConformance OBJECT IDENTIFIER ::= { qqiPublicMIB 2 }
  178.  
  179. qqiPublicMIBCompliance  OBJECT IDENTIFIER ::= { qqiPublicMIBConformance 1 }
  180. qqiPublicMIBGroups      OBJECT IDENTIFIER ::= { qqiPublicMIBConformance 2 }
  181.  
  182. -- compliance statements
  183.  
  184.  
  185. qqiPublicMIBCompliance MODULE-COMPLIANCE
  186.     STATUS  current
  187.     DESCRIPTION
  188.         "The compliance statement for SNMP entities which
  189.         implement objects of qqiPublic MIB"
  190.     MODULE  
  191.     MANDATORY-GROUPS { qqiSetGroup }
  192.     ::= { qqiPublicMIBCompliance 1 }
  193.  
  194. -- units of conformance
  195.  
  196. qqiSetRequestGroup OBJECT-GROUP
  197.     OBJECTS   { qqiSetLevel, qqiSetLimit}
  198.     STATUS    current
  199.     DESCRIPTION
  200.         "The qqiSetRequest  group of objects providing information about
  201.         acceptable complexity of set request."
  202.     ::= { qqiPublicMIBGroups 1 }
  203.  
  204. END
  205.  
  206.  
  207. 4. Acknowledgments
  208.  
  209. This memo was inspired by author's discussion with Bob Natale (ACE*COMM).
  210.  
  211. 5. References
  212.  
  213. [1]  Jeffrey  D. Case, Mark Fedor, Martin Lee Schoffstall and James
  214.      R. Davin, Simple  Network  Management  Protocol  (SNMP),  SNMP
  215.      Research,  Performance  Systems  International, MIT Laboratory
  216.      for Computer Science, RFC 1157, May 1990.
  217.  
  218. [2]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
  219.      Waldbusser, Protocol Operations for Version 2  of  the  Simple
  220.      Network Management Protocol (SNMPv2), SNMP Research Inc, Cisco
  221.      Systems Inc, Dover Beach Consulting Inc, International Network
  222.      Services, RFC1905, January 1996.
  223.  
  224.  
  225. INTERNET-DRAFT          EXPIRES: SEPTEMBER 1997        INTERNET-DRAFT
  226.  
  227.  
  228. Author's Address:
  229.  
  230. Mr. Aleksey Y. Romanov    
  231. Quality Quorum, Inc.
  232. 60 Lincoln Road
  233. Sutton, MA  01590
  234. USA
  235. E-mail:        qqi@world.std.com
  236.