Movatterモバイル変換

Network Working Group                                            V. CerfRequest for Comments:  1109                                          NRI                                                             August 1989Report of the Second Ad Hoc Network Management Review GroupStatus of this Memo   This RFC reports an official Internet Activities Board (IAB) policy   position on the treatment of Network Management in the Internet. This   RFC presents the results and recommendations of the second Ad Hoc   Network Management Review on June 12, 1989.  The results of the first   such meeting were reported inRFC 1052 [1].  This report was approved   and its recommendations adopted by the IAB as assembled on July 11-   13, 1989.  Distribution of this memo is unlimited.INTRODUCTION   On February 29, 1988, an Ad Hoc Network Management Review Group was   convened to consider the state of network management technology for   the Internet and to make recommendations to the Internet Activities   Board as to network management policy.  The outcome of that meeting   was summarized inRFC 1052 and essentially established a framework in   which two network management protocols now known respectively as   Simple Network Management Protocol (SNMP) and Common Management   Information Protocol on TCP (CMOT) were selected for further work.   Subsequently, both SNMP [6] and CMOT [5] were advanced to Draft-   Standard/Recommended status for use in the Internet [SNMP:RFC 1098,   CMOT:RFC 1095].   Simultaneously, it was agreed to establish a working group to   coordinate the definition and specification of managed objects to be   used in common with either protocol.  In addition, it was agreed to   use the then current ISO Structure of Management Information (SMI)   specification as a reference standard to guide the naming and   abstraction conventions that would be followed in constructing the   common Internet Management Information Base (MIB).  The Internet   versions of SMI and MIB were specified inRFC 1065 [2] andRFC 1066   [3] respectively.   In the intervening fifteen months, considerable progress has been   made in the specification of a common Management Information Base and   in the implementation, deployment and use of network management tools   in the Internet.Cerf                                                            [Page 1]

RFC 1109                  Internet Management                August 1989   The current public subtree of the Internet MIB contains roughly 100   variables (i.e., managed objects) agreed by the SNMP and CMOT working   groups as mandatory for Internet network management.  The June 12,   1989 meeting which this document reports was convened to review the   progress to date, to determine whether actions were needed to foster   further evolution of network management tools and to recommend   specific actions in this area to the IAB.SNMP STATUS   Immediately after the meeting reported inRFC 1052, a group was   convened to make extensions and changes to the predecessor to SNMP:   Simple Gateway Monitoring Protocol.  A "connectathon" was held at   NYSERNet, an RFC published, and demonstrations of network management   tools using SNMP were offered in the Fall at Interop 88 [a conference   and show presented by Advanced Computing Environments (ACE)].  The   protocol is in use in a number of networks within the Internet as   well as in private packet networks internationally.  A number of   vendor implementations are in the field (e.g., cisco Systems,   Proteon, The Wollongong Group), vendor independent reference   implementations (e.g., NYSERNet, Case and Key in Tennessee) along   with some freely available versions (e.g., MIT, CMU).   It is important to note that while the common Internet Management   Information Base has roughly 100 variables, a typical SNMP monitoring   system may support anywhere from 100 to 200 ADDITIONAL objects which   have been defined in private or experimental MIB space.  Many of   these are device or protocol dependent variables.   Scaling to include larger numbers of monitored objects and subsystems   remains a challenge.  It was observed that fault monitoring was   easier to scale than performance and configuration monitoring, since   the former may operate on an exception basis while the latter is more   likely to require periodic reporting.CMOT STATUSRFC 1095 (CMOT) was recently published and built upon experience   gained earlier with prototype implementations demonstrated at Interop   88 in the Fall of that year.  The present specification for CMOT is   based on the ISO Draft International Standard version of Common   Management Information Protocol (CMIP).  The CMIP is being moved to   International Standard status, though the precise timing is not   perfectly clear.  It will happen late in 1989 or perhaps in the first   quarter of 1990.  Some changes will be made to correct known errors   and the CMIP document itself will probably be restructured.   During this discussion, it was pointed out that there is much toCerf                                                            [Page 2]

RFC 1109                  Internet Management                August 1989   network management which is not addressed by either the CMOT or the   SNMP specifications: for example, down loading of software,   configuration management and user access control.  Authentication of   the source of network management commands and responses is another   area important to providers and users of network management tools.   The National Institute for Standards and Technology (NIST) is   sponsoring the development of implementors' agreements on the   functional behavior of network management tools including, inter   alia, logging, event reporting, error reporting, structured object   management, and alarm reporting.   Although at the time of the meeting, there were no publicly available   implementations of CMOT reported, developments were reportedly   planned by a number of vendors both in the form of agents and network   management tools.  The University of Wisconsin plans to demonstrate   CMOT using the ISODE software at Interop 89 [(tm) ACE] in September   1989.MIB AND SMI STATUS   In the Fall of 1988, two RFCs were published (1065 and 1066) to   specify the Structure of Management Information (SMI) and the initial   Internet Management Information Base (MIB) respectively.  There were   some challenges in crafting this set of commonly agreed variables; in   the end, roughly 100 were agreed and defined as mandatory for   Internet management.   It was recognized in this process that the definition of the layer   BELOW IP was a difficult task.  IP is sufficiently simple and general   that it has been moved in encapsulated form over many media including   the MAC level of various local nets, X.25 packet level, serial line   protocols, multiplexors, tunnels and, it is rumored, tin cans and   string.   At the Transport level, specifically for TCP, it was observed that   information about the transient status of connections was potentially   inaccessible to the network management tools since the loss of a TCP   connection typically meant loss of its Transmission Control Block   (status block) just when you wanted to look back into the history of   its state.  Countervailing this observation was evidence that looking   at TCBs with network management tools yielded far more insight into   the transient behavior of TCP than looking at aggregated network   statistics.   It was clear from the discussion that there is strong interest in   extending the variables accessible via network management tools.   Adding new devices, new higher level protocols and the ability toCerf                                                            [Page 3]

RFC 1109                  Internet Management                August 1989   manipulate configuration information were high on the list of   desirable extensions, although several participants felt that this   desire needed some moderation.   A vital, but unsettled research area has to do with relationships   among groups of monitored variables.  A particular implementation may   have IP operating atop X.25.  The problem is to be able to make   queries about the condition of monitored variables so that those for   the IP level can be correlated with those for a lower layer, for   instance.  This notion of relationship is especially important as   network devices (including hosts) begin to sport multiple network   connections and multiple protocol suites operating in parallel.  Just   how the dynamics of such relationships are to be specified, defined   and instantiated is the research question.  What sort of SMI is   appropriate? What generic structure is needed for the management   objects?   Another difficult topic has to do with version numbers for SMI.  The   issue is "which version of MIB is instantiated in this monitored   system?"  As consideration of extensions to the currently agreed SMI   were contemplated during the last fifteen months, it became apparent   that the question of versions was central.   Not far behind was the question of functionality of the underlying   support protocols (SNMP and CMOT).  TheRFC 1052 recommendation was   to tightly link the MIB/SMI, keeping only one such definition for   both protocols.  In theory, this plan would make it easier to move   from one protocol base to another.  In practice, it appears to have   stifled exploration of new variable and function definitions in   operating network environments.  This point needs to be underscored:   it is essential for the Internet community to have the freedom to   explore the utility of the OSI offerings while, at the same time,   having the freedom to respond to operational needs through the   definition and use of new MIB variables and SMI features.   Yet another area still needing development has to do with the   archiving of operational data collected by means of a network   management tool.  The ISO Common Management Information Service   (CMIS) specifications do not treat this matter.   Finally, it was pointed out that registration of managed objects and   their definitions was still an open area although the NIST has   apparently made progress through its Network Management Special   Interest Group (NMSIG) in planning for cataloging of defined   management information objects.Cerf                                                            [Page 4]

RFC 1109                  Internet Management                August 1989APPLICATION PROGRAMMING INTERFACE (API)   It was generally agreed that the actual network management tools   available to operators, rather than the specifics of the protocols   supporting the tools, would be the determining factor in the   effectiveness of any Internet network management system.  A brief   report was offered and discussion ensued on the possibility of   creating a common application programming interface that could be   used independent of the specific protocol (CMOT, SNMP, CMIP or   proprietary) used to transport queries and commands.   It was acknowledged that the present service interfaces of both SNMP   and CMIS have limitations (e.g., neither has any sense of time other   than "now"; this makes it impossible to express queries for   historical information, or to issue command requests of the form: Do   X at device Y, beginning in 30 minutes).  These limitations hinder   both SNMP and CMOT from directly offering a comprehensive API for   network management applications.   Although some positive sentiment was expressed for defining a kind of   "super SMI" metalanguage to aid in the the definition of a general   API, it was not clear whether the current crop of supporting   protocols had sufficient semantic commonality to be used in this way.   The matter remains open for investigation.NIST ACTIVITIES   The Ad Hoc Review had the benefit of representatives from NIST who   are active in the network management area.  It was reported that the   major focus at present is at layers 3 and 4 where objects are being   defined in accordance with "templates" provided by ISO's SC21.  IEEE   802 is also pursuing the definition of MIB objects, though not with   the benefit of the same templates now in use by the NIST NMSIG.  The   layers above transport are just beginning to receive attention.   It was observed that the Internet SMI is not quite a subset of the   ISO CMIS SMI.  The Internet variable naming conventions are a little   different and some functionality may vary.  There was some   uncertainty about the treatment of gauges in the Internet SMI and the   corresponding OSI SMI.  [L. Steinberg reported, subsequent to the   meeting, that gauges latch and counters roll over in the OSI SMI, as   they appear to do in the Internet SMI - VGC].   The general sense of this portion of the discussion was that a   considerable amount of activity is underway with the sponsorship of   NIST and that this work is relevant to the Internet community,   particularly as the time approaches in which coexistence of the OSI   protocol suite with the existing Internet protocols is the norm.Cerf                                                            [Page 5]

RFC 1109                  Internet Management                August 1989CONCLUSIONS AND RECOMMENDATIONS   The assembled attendees came to the conclusions enumerated below and   recommends to the IAB that actions be taken which are consistent with   these conclusions:      1. The Internet will exist in a pluralistic protocol stack         environment and the need to coexist will persist.      2. Expansion of the common MIB has been impeded by an inability to         agree on a common, extended SMI.      3. The Internet community must not ignore the work of other groups         in the network management area, while at the same time, coping         with the current operational needs of the Internet (and         internet) communities.      4. Until we can gain operational experience with OSI network         management tools (e.g., with CMIP on TCP or on OSI), we cannot         specify a plan for coexistence with and transition to use of         the OSI-based protocols in the Internet.   Therefore:      (a) We want to foster an environment for real CMOT/CMIP use.      (b) We should take action as needed to extend SNMP for operational          reasons.      (c) We must preserve the utility of the first agreed common MIB          (RFC 1066).      (d) We should develop, separately, experimental and enterprise MIB          variables and seek opportunity for placing these in the common          MIB.      (e) In a coexisting environment, we will need to access the same          set of variables (e.g., in a given gateway or router) by means          of more than one protocol (e.g., SNMP, CMIP/TCP, CMIP/CLNP,          etc.).   It is recommended to the IAB that the network management efforts   using SNMP and CMOT be allowed independently to explore new variables   and potentially non-overlapping SMI definitions for the next 12   months so as to foster operational deployment and experience with   these network management tools.  In essence, it is recommended that   the binding of SNMP and CMOT to a common MIB/SMI be relaxed for this   period of exploration.  Variables which are NOT supportable in commonCerf                                                            [Page 6]

RFC 1109                  Internet Management                August 1989   by both protocols should be defined in the experimental or private   parts of the MIB definition space.  Obviously, care should be taken   to achieve agreement within each respective working group on any   variables added to the distinct SNMP and CMOT experimental spaces.   Specifically, the CMOT working group should extend its MIB and SMI   definitions in the direction of the OSI/NIST specifications so as to   bring CMOT into closer alignment with the OSI CMIS design.   During this period of experimentation, it is strongly recommended   that the IAB seek opportunities to encourage the introduction of   Internet elements which use the OSI protocols into the Internet   environment.  Such OSI-based elements offer an opportunity to obtain   operational experience with monitoring and management support by way   of the CMIP and CMOT protocols.  It is anticipated that network   management systems based on the OSI Common Management Information   Service (CMIS) will be developed which use CMIP or CMOT, as   appropriate, to manage various elements in the Internet.   It is also recommended that the IAB engage in an active liaison   effort with the NIST, focusing especially on the question of   coexistence of the Internet protocols with OSI protocols.  If at all   possible, joint experimental or test-bed efforts should be initiated   to identify means for supporting this coexistence.   As necessary, the Internet Engineering Task Force should be directed   to restructure its network management efforts both to support the   need for MIB/SMI exploration by the SNMP and CMOT groups and to   strengthen links between the IETF efforts and those of NIST.   Finally, it is recommended that the Ad Hoc Review Group be reconvened   at 6 month intervals to review status and to determine whether   opportunities for expanding the common MIB/SMI are available.REFERENCES   1.  Cerf, V., "IAB Recommendations for the Development of Internet       Network Management Standards",RFC 1052, NRI, April 1988.   2.  Rose, M., and K. McCloghrie, "Structure and Identification of       Management Information for TCP/IP-based internets",RFC 1065,       TWG, August 1988.   3.  McCloghrie, K., and M. Rose, "Management Information Base for       Network Management of TCP/IP-based internets",RFC 1066, TWG,       August 1988.   4.  Schoffstall, M., C. Davin, M. Fedor, and J. Case, "SNMP overCerf                                                            [Page 7]

RFC 1109                  Internet Management                August 1989       Ethernet",RFC 1089, Rensselaer Polytechnic Institute, MIT       Laboratory for Computer Science, NYSERNet, Inc., and University       of Tennessee at Knoxville, February 1989.   5.  Warrier, U., and L. Besaw, "Common  Management Information       Services and Protocol over TCP/IP (CMOT)",RFC 1095, Unisys       Corporation, and Hewlett-Packard, April 1989.   6.  Case, J., M. Fedor, M. Schoffstall, and C. Davin, "Simple Network       Management Protocol (SNMP)",RFC 1098, University of Tennessee at       Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, and       MIT Laboratory for Computer Science, April 1989.Appendix A - Ad Hoc Net Management Review Attendance List   Amatzia Ben-Artzi   3Com   Paul Brusil         MITRE   John Burruss        Wellfleet Communications   Jeff Case           University of Tennessee at Knoxville   Vint Cerf           National Research Initiatives   Ralph Droms         Bucknell University (on sabbatical at NRI)   Mark Fedor          NYSERNet   Phill Gross         National Research Initiatives   Lee LaBarre         MITRE   Bruce Laird         Bolt Beranek and Newman   Gary Malkin         Proteon   Keith McCloghrie    Wollongong   Craig Partridge     Bolt Beranek and Newman   Marshall Rose       NYSERNet   Greg Satz           cisco Systems   Marty Schoffstall   NYSERNet   Louis Steinberg     IBM   Dan Stokesberry     NIST   Unni Warrier        NetlabsAuthor's Address   Vinton G. Cerf   Corporation for National Research Initiatives   1895 Preston White Drive, Suite 100   Reston, VA 22091   Phone: (703) 620-8990   EMail: CERF@A.ISI.EDUCerf                                                            [Page 8]