IAB recommendations for the development of Internet network management standards
Author(s): V.G. Cerf
This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT,...
Network Working Group V. Cerf Request for Comments: 1052 NRI April 1988 IAB Recommendations for the Development of Internet Network Management Standards Status of this Memo This memo is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. The memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and the long term. Distribution of this memo is unlimited. Background At the IAB meeting on 21 March 88 in videoconference, the report of the Ad Hoc Network Management Review Committee was reviewed. The recommendations of the committee were endorsed by the IAB and direction given to the chairman of the Internet Engineering Task Force to take the necessary steps to implement the recommendations. The IAB expressed its gratitude for the efforts of the HEMS, SNMP and CMIP/CMIS working groups and urged that parties with technical interest in the outcome of the network management working groups convey their ideas and issues to the relevant working group chairmen. The IETF chairman was directed to form two new working groups, one of which would be responsible for the further specification and definition of elements to be included in the Management Information Base (MIB). The other would be responsible for defining extensions to the Simple Network Management Protocol to accommodate the short- term needs of the network vendor and operator communities. The longer-term needs of the Internet community are to be met using the ISO CMIS/CMIP framework as a basis. A working group of the IETF exists for this work and would continue its work, coordinating with the two new groups and reporting to the IETF chairman for guidance. The output of the MIB working group is to be provided to both the SNMP working group and the CMIS/CMIP ["Netman"] working group so as to assure compatibility of monitored items for both network management frameworks. Cerf [Page 1] RFC 1052 Internet Management April 1988 Specific Recommendations The IAB recommends that the Simple Network Management Protocol be adopted as the BASIS for network management in the short-term. Extensions may be required to the existing SNMP specification to accommodate additional data types or to deal with functional or performance issues arising as multiple SNMP implementations are deployed and applied, especially in multi-vendor applications. The SNMP working group constituted by the IETF is charged with considering requirements not met by the present SNMP definition, defining extensions, if necessary, to accommodate these needs, and preparing revisions of the SNMP specifications to address any new extensions. The IAB urges the working group to be extremely sensitive to the need to keep SNMP simple, to work quickly to come to concensus on any revisions needed and to promulgate expeditiously the results of its work in one or more RFCs within the next 90 days. The IETF chairman is responsible for resolving disagreements arising if they cannot be resolved within the working group and is instructed to escalate problems quickly to the IAB should resolution not be forthcoming. The IAB further recommends that the MIB working group begin its work equally expeditiously, taking as its starting inputs the MIB definitions found in the existing High-Level Entity Management Systems (HEMS) RFC-1024, the SNMP IDEA-11, and CMIS/CMIP IDEAs. It is the intention of the IAB that the MIB definitions be applied both to the SNMP system in the short term and CMIS/CMIP for TCP/IP in the longer term. The three working groups will have to coordinate their efforts carefully to achieve these objectives: 1. Rapid convergence and definition for SNMP. 2. Rapid convergence and definition for the TCP/IP MIB. 3. Provision for transitioning from SNMP to CMIP/CMIS. 4. Early demonstration of the CMIP/CMIS capability using the TCP/IP MIB. The IAB remains extremely interested in progress towards these goals and intends to have representation, whenever possible, in the various working group and IETF plenary activities. Cerf [Page 2] RFC 1052 Internet Management April 1988 REPORT OF THE AD HOC NETWORK MANAGEMENT REVIEW COMMITTEE Edited by Vinton Cerf, Chairman March 1988 EXECUTIVE SUMMARY On 29 February 88, an ad hoc committee was convened to review the network management options for the Internet in particular and the TCP/IP protocol suite in general. This meeting was called at the request of the Internet Activities Board in the course of exercising its responsibilities to the Federal Research Internet Coordinating Council (FRICC) and by the MITRE Corporation as a consequence of its work for the U.S. Air Force on the ULANA project. At the conclusion of the one day meeting, it was agreed that the following recommendations be forwarded to the Internet Activities Board chairman, Dr. David C. Clark, for consideration at the next IAB meeting scheduled for 21 March: 1. In the short term, the Internet community should adopt and adapt the Simple Network Management Protocol (SNMP) for use as the basis of common network management throughout the system. (Rationale: The software is available and in operation.) 2. In the longer term, the Internet research community and the vendors should develop, deploy and test a network management system based on the International Standards Organization (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP). (Rationale: The Internet community can take the high ground in protocol development by virtue of the experimental environment in which it can operate. Recommendations to the ISO from this community, the IAB and the vendors will carry great weight if they are in the language of the ISO common network management system and if they are rooted in actual experience with implementation and use in the field.) 3. Responsibility for the SNMP effort should be placed in the hands of an IETF task force. (Rationale: Eliminate vendor-specific bias or control over the SNMP and its evolution and harmonize inputs from the Internet community.) Cerf [Page 3] RFC 1052 Internet Management April 1988 4. As a high priority effort, define an extended Management Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into closer conformance with the MIB defined for the experimental HighLevel Entity Management System (HEMS). (Rationale: The HEMS effort produced a very thorough and widely- discussed set of elements to monitor, along with definitions of the semantics of these elements. The current SNMP definitions are more restricted and the CMIP definitions less precise. Implementation of SNMP in a timely and useful fashion through the Internet cannot be satisfactorily completed without such a definition of information elements in hand.) The ad hoc committee therefore recommends immediate action by the IAB on all four of these points. It should be noted that this resolution would not have been possible in such a timely way without the statesman-like efforts of Craig Partridge who, at the end of the day, recommended that the HEMS effort be withdrawn from consideration so as to pave the way for an Internet-wide agreement. In consideration of this unselfish act, the ad hoc committee urges the IAB to approve the recommendations above and to instruct the IETF to move quickly to accept and act on the SNMP items requiring completion. 1. INTRODUCTION During its development history, the community of researchers, developers, implementors and users of the DARPA/DoD TCP/IP protocol suite have experimented with a wide range of protocols in a variety of different networking environments. The Internet has grown, especially in the last few years, as a result of the widespread availability of software and hardware supporting this system. The scaling of the size and scope of the Internet and increased use of its technology in commercial applications has underscored for researchers, developers and vendors the need for a common network management framework within which TCP/IP products can be made to work. In recognition of this need, several efforts were started to develop network management concepts which might be applied to the Internet and to the internet technology in general. Three of these efforts had made sufficient progress by the end of 1987 that it became clear that some choices had to be made or the community would find itself with a set of incompatible network management tools. These efforts included the High-Level Entity Management System (HEMS), the Simple Gateway Monitoring Protocol (SGMP) and the Common Management Information Service/Protocol. Cerf [Page 4] RFC 1052 Internet Management April 1988 The latter is an ISO initiative which was adapted to Internet use in a vendor-initiated effort. The HEMS work was carried out in the context of the Gateway Monitoring group of the Internet Engineering Task Force. The SGMP effort was carried out largely in the practical context of the NYSERNET and SURAnet regional networks which needed network management facilities to operate satisfactorily. Independent of the general Internet situation and requirements, the U.S. Air Force has been pursuing a Universal Local Area Network Architecture (ULANA) for its own use. The principal agent for the development of the ULANA specifications is the MITRE Corporation. Faced with several long and short term network management options, the MITRE ULANA specification team initiated an effort with substantial vendor participation called the NETMAN working group. It was against this fabric of various options that the IAB appointed a chairman to convene a review committee to discuss these various options and to make recommendations on long and short term choices. The MITRE Corporation co-sponsored this work to further its aims in the specification of the ULANA design. Reference material listed at the end of this report was provided in advance of the meeting. 2. DISCUSSION Rather than attempting to produce minutes of the meeting, this section summarizes in very high level terms the substance of the discussion which took place during most of the meeting. Presentation viewgraphs can be made available to IAB/FRICC members interested in their contents. The agenda was followed fairly closely with the technical presentations made in the order suggested: HEMS, SGMP, CMIP/CMIS. The HEMS effort has established a benchmark for other network management work in the sense that it took a comprehensive conceptual view of the problem and went into considerable detail on the design of the underlying management information database, the mechanics of access to and reporting of information, considerations of scaling and performance (e.g., Query Language vs Remote Procedure Call style), definition of information required and so on. HEMS has been implemented in an experimental version from which some encouraging performance measurements were taken. Serious vendor interest in this protocol was expressed by Cisco Systems and implementation efforts were under way as of the meeting. The SGMP effort, though somewhat less documented, was rooted in a Cerf [Page 5] RFC 1052 Internet Management April 1988 practical need for network management tools for the NYSERNET, SURAnet, and, by extension, other components of the Internet. Implementations of it exist, in its RFC-1028 form (probably with some experimental extensions based on experience gained from the initial work), and are in use today. Serious vendor support for this work is found at Proteon and, more recently, in the NSFNET effort by MERIT, IBM and MCI, specifically in the IBM Network Switching System (NSS) nodes. Applications running above SGMP exist and provide useful monitoring information, presented in easily grasped form. The ISO CMIS/CMIP effort, voluminously documented, has had almost no implementation as yet. Reports from Unisys/SDC about an experimental implementation were heard at the meeting. There is substantial momentum in the international community for the adoption of this service and protocol suite for network management. The Draft Proposal is out for its second ballot (it failed to make Draft International Standard on its first ballot). There is vocal vendor support for this work, based on the premise that ultimately the ISO protocol suite will propagate and the vendors must support it. In general, all of the network management proposals make use of the Abstract Syntax Notation 1 (ASN.1) which has emerged from the ISO efforts as a kind of lingua franca for the representation of arbitrary data structures. The data types used in the SGMP Management Information Base (aspects of network components to be monitored) are the most restricted of the three proposals, confined to integers and octet strings only. HEMS has the most extensive Management Information Base and added some rather unique ideas such as self-knowledge about what could be monitored so that a device/unit/component could respond to a query asking "what can you tell me about yourself and your operation and how is it represented?" (!). CMIS/CMIP is probably the broadest in scope, but less precisely defined at this point, with respect to information which should be monitored. The draft RFCs referenced above relating to the CMIS/CMIP concerning items to be monitored are still in the definition stages. A point made strongly by the HEMS team was their concern that a Remote Operations basis for CMIP may not scale well into a very large Internet which needs to be monitored from a few central sites. Remote Operations is a term used by ISO and means, roughly, what the Internet community has long referred to as Remote Procedure Calls. If each atomic action is a Remote Procedure Call, the HEMS team argues that increasing Internet size and potential delays may vastly constrain the amount and timeliness of information which can be collected. The HEMS design uses, instead, a general query language approach which permits more elaborate, multi-variable queries to be formulated at the requesting site and processed at the responding site(s). Cerf [Page 6] RFC 1052 Internet Management April 1988 Although it does substantial injustice to the very lucid and helpful presentations by representatives of each of the network management research groups, I have chosen to leave out much of the detail from this report and move directly to the points of agreement which were reached by the Committee. 3. POINTS OF AGREEMENT (i) Future Internet development is a joint interest of the R&D community, the vendor community and the user community. [Editor's comment: The development of the Internet is now not only dependent on research work, but on the hardware and software of vendors selling to both commercial ("internet") and the research environment ("Internet"). Moreover, the Internet users are not all concerned with network research; many of the components of the Internet are based on vendor-supplied and supported subsystems.] (ii) We still don't have a common understanding of what [Inter]Network Management really is. [Editor's comment: We haven't tried to manage the Internet as a collection of autonomous systems in an effective way, yet.] (iii) We will learn what [Inter]Network Management is by doing it. (a) in as large a scale as is possible (b) with as much diversity of implementation as possible (c) over as wide a range of protocol layers as possible (d) with as much administrative diversity as we can stand. (iv) There are more than HEMS, SGMP and CMIS/CMIP as potential candidates: HEMS, SGMP, CMIS/CMIP [multiple profiles], NETVIEW, LANMANAGER, Network Computing Forum "Fat Document"... [Editor's comment: The multiplicity of options is motivation for coalescing the energy of the Internet environment around single short and long term foci so as to make more substantial progress in really understanding network management per point (iii).] (v) Define the Management Information Base for TCP/IP suite NOW! (vi) Seek a seat for IETF on ANSI, ISO and/or CCITT!!! Cerf [Page 7] RFC 1052 Internet Management April 1988 [Editor's comment: This may actually be feasible.] (vii) Define a CMIS interface to any of the surviving network management schemes so as to provide a migration path to ISO. 4. RESOLUTION AND CONCLUSIONS In a dramatic act of statesmanship, Craig Partridge volunteered that the HEMS proposal be dropped in favor of the other two efforts, SGMP and CMIS/CMIP - IF THIS WOULD LEAD TO INTERNET-WIDE AGREEMENT ON A NETWORK MANAGEMENT PLAN FOR THE SHORT AND LONG TERM. A rationale for the long term was proposed, based on the assumption that the ISO initiatives, and the U.S. Government issuance of the GOSIP guidelines, would ultimately require at least the Government users, and hence their vendor suppliers, to use ISO-based protocols and tools. In this rationale, the Internet research community and its vendors would "take the high ground" in network management by implementing the CMIS/CMIP on top of the TCP/IP protocol suite and deploy it widely for experimental use in the Internet. Neither the ISO nor any other organization, including the Corporation for Open Systems (COS) has anything close to the laboratory in large that the Internet represents. By taking the initiative, the Internet working groups can establish credibility based on experience which will make it far more feasible to affect the evolution of the ISO network management and other related efforts. The Internet community will be able to speak with authority about problems with the design or definition of CMIS/CMIP based on real implementation experience and use, rather than solely analytic means. In the short term, however, the Internet desperately needs tools to apply to the operational management problems associated with its rapid growth. Given the present state of advanced implementation of the SGMP and its relative simplicity, the general agreement was that SGMP (or its re-named successor, SNMP) should be quickly brought to more complete specification for widespread implementation and use. In short, the ad hoc committee recommends: 1. In the short term, the Internet community should adopt and adapt the Simple Network Management Protocol (SNMP) for use as the basis of common network management throughout the system. (Rationale: The software is available and in operation.) 2. In the longer term, the Internet research community and the vendors should develop, deploy and test a network management Cerf [Page 8] RFC 1052 Internet Management April 1988 system based on the International Standards Organization (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP). (Rationale: The Internet community can take the high ground in protocol development by virtue of the experimental environment in which it can operate. Recommendations to the ISO from this community, the IAB and the vendors will carry great weight if they are in the language of the ISO common network management system and if they are rooted in actual experience with implementation and use in the field.) 3. Responsibility for the SNMP effort should be placed in the hands of an IETF task force. (Rationale: Eliminate vendor-specific bias or control over the SNMP and its evolution and harmonize inputs from the Internet community.) 4. As a high priority effort, define an extended Management Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into closer conformance with the MIB defined for the experimental HighLevel Entity Management System (HEMS). (Rationale: The HEMS effort produced a very thorough and widely-discussed set of elements to monitor, along with definitions of the semantics of these elements. The current SNMP definitions are more restricted and the CMIP definitions less precise. Implementation of SNMP in a timely and useful fashion through the Internet cannot be satisfactorily completed without such a definition of information elements in hand.) Cerf [Page 9] RFC 1052 Internet Management April 1988 MEMBERS OF THE AD HOC NET MANAGEMENT REVIEW COMMITTEE Amatzia Ben-Artzi Sytek Corp. 1225 Charleston Rd. Mountain View, CA 94043 Amatzia@amadeus.stanford.edu Bob Braden USC-ISI 4676 Admiralty Way Marina del Rey, CA 90292 firstname.lastname@example.org Jeff Case University of Tennessee 200 Stokely Management Center Knoxville, TN 37996 email@example.com Vint Cerf - Chairman Corp. for National Research Initiatives 1895 Preston White Dr., Suite 100 Reston, VA 22091 (703) 620-8990 Cerf@ISI.EDU Chuck Davin Proteon, Inc. 2 Technology Dr. Westborough, MA 01536 firstname.lastname@example.org Stephen Dunford UNISYS Corp. System Development Corporation 5151 Camino Road Camarillo, CA 93010 email@example.com Mark Fedor NYSERNET 125 Jordan Road Troy, NY 12180 firstname.lastname@example.org Cerf [Page 10] RFC 1052 Internet Management April 1988 Phill Gross - IETF Chairman MITRE Corporation 1820 Dolley Madison Blvd. McLean, VA 22012 Gross@Gateway.MITRE.Org Lee LaBarre MITRE Corporation Burlington Road Bedford, MA 01730 email@example.com Dan Lynch Advanced Computing Environments 480 San Antonio Rd. Mountain View, CA 94040 Lynch@isi.edu Jim Mathis Apple Computer, Inc. MS 27-0 20525 Mariani Ave. Cupertino, CA 95014 Mathis@Apple.com Craig Partridge BBN Labs 10 Moulton St. Cambridge, MA 02238 firstname.lastname@example.org Marshall T. Rose The Wollongong Group, Inc. 1129 San Antonio Road Palo Alto, CA 94043 MRose@twg.com Greg Satz Cisco Systems 1360 Willow Rd., Suite 201 Menlo Park, CA 94301 email@example.com Martin Lee Schoffstall NYSERNET 125 Jordan Road Troy, NY 12180 firstname.lastname@example.org Cerf [Page 11] RFC 1052 Internet Management April 1988 Glenn Trewitt Center for Integrated Systems, Room 216 Stanford University Stanford, CA 94305 Trewitt@amadeus.stanford.edu MEETING LOCATION: San Diego Supercomputer Center, UC San Diego LOCAL ARRANGEMENTS: Paul Love, SDSC MEETING DATE: 29 February 1988 AGENDA ITEMS: 0900 Introductions and Objectives/Cerf 0915 HEMS: Craig Partridge and Glenn Trewitt 1030 Break 1045 SGMP - Jeff Case 1145 CMIP/CMIS - Amatzia Ben-Artzi 1245 Lunch Break 1430 TCP/IP and ISO: Politics, Technology, Penetration/Cerf 1530 Break 1545 Tradeoffs among alternate paths (Discussion) 1700 Resolution of alternatives 1730 Summary of conclusions/actions 1800 Adjourn Cerf [Page 12] RFC 1052 Internet Management April 1988 REFERENCES The following reference material was provided in advance of the meeting. Note that some of the citations include informal descriptors (such as IDEA numbers or DRAFT letter codes), for example, IDEA-13 or DRAFT-AAAA. IDEA notes may be updated from time to time reusing the same number. The IDEA notes are the working notes of the Engineering Task Force. The DRAFT is a temporary notation and may not be meaningful for more than a few months. HEMS (1) Craig Partridge, "A UNIX Implementation of HEMS", USENIX, February 1988. [Available from C. Partridge, BBN Labs] (2) Craig Partridge and Glenn Trewitt, "The High-Level Entity Management System", RFC-1021. (3) Craig Partridge and Glenn Trewitt, "The High-Level Entity Management Protocol", RFC-1022. (4) Glenn Trewitt and Craig Partridge, "The HEMS Monitoring and Control Language", RFC-1023. (5) Craig Partridge and Glenn Trewitt, "HEMS Variable Definitions", RFC-1024. (6) Craig Partridge and Glenn Trewitt, "The High-Level Entity Management System", IEEE Network magazine, March 1988. SGMP/SNMP (1) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A Simple Gateway Monitoring Protocol", RFC-1028, November 1987. (2) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A Simple Network Management Protocol", IDEA-11, February 1988, obsoletes RFC-1028 when issued. (3) Jeffrey R. Case, James R. Davin, Mark S. Fedor, Martin L. Schoffstall, "Introduction to the Simple Gateway Monitoring Protocol", IEEE Network Magazine, March 1988. CMIS/CMIP (1) Amatzia Ben-Artzi, "Network Management for TCP/IP Network: An Overview", IDEA-12, February 1988. Cerf [Page 13] RFC 1052 Internet Management April 1988 (2) Lee LaBarre, " TCP/IP Network Management Implementors Agreements", IDEA-13, January 1988. (3) Lee LaBarre, "Data Link Layer Management Information: MAC802.3", DRAFT-MMMM, February 1988. (4) Lee LaBarre, "Network Layer Management Information: IP", DRAFT-NNNN, February 1988. (5) Marshall Rose, "ISO Presentation Services on Top of TCP/IP- based Internets", DRAFT-PPPP, February 1988. (6) Lee LaBarre, "Structure and Identification of Management Information for the Internet", DRAFT-SMI, February 1988. (7) Lee LaBarre, "Transport Layer Management Information: TCP", DRAFT-TTTT, February 1988. (8) Lee LaBarre, "Transport Layer Management Information: UDP", DRAFT-UUUU, February 1988. (9) ISO/IEC JTC 1/21 N 2058, "2nd DP 9595-1 Information Processing Systems - Open Systems Interconnection - Management Information Service Definition - Part 1: Overview", December 1987. (10) ISO/IEC JTC 1/21 N 2059, "2nd DP 9595-2, Information Processing Systems - Open Systems Interconnection - Management Information Service Definition - Part 2: Common Management Information Service Definition", December 1987. (11) ISO/IEC JTC 1/21 N 2060, "2nd DP 9596-2, Information Processing Systems - Open Systems Interconnection - Management Information Protocol Specification - Part 2: Common Management Information Protocol", December 1987. (12) ISO/TC97/SC21/WG4 N 472, "US Comments on the Proposal for Extension of the Common Management Information Services and Protocol: Creation and Deletion Functions", November 1987. (13) JTC1/SC21/WG4 N 482, "Proposal to extend M-Set and M- Confirmed-Set to allow adding and removing values of a multi- valued attribute", November 1987. (14) S. Mark Klerer, "The OSI Management Architecture: An Overview", IEEE Network Magazine, March 1988. Cerf [Page 14]