From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1052.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc1052.txt (limited to 'doc/rfc/rfc1052.txt') diff --git a/doc/rfc/rfc1052.txt b/doc/rfc/rfc1052.txt new file mode 100644 index 0000000..35de17f --- /dev/null +++ b/doc/rfc/rfc1052.txt @@ -0,0 +1,787 @@ + + + + + + +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 + braden@isi.edu + + Jeff Case + University of Tennessee + 200 Stokely Management Center + Knoxville, TN 37996 + case@utkcs2.cs.utk.edu + + 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 + jrd@monk.proteon.com + + Stephen Dunford + UNISYS Corp. + System Development Corporation + 5151 Camino Road + Camarillo, CA 93010 + dunford@cam.unisys.com + + Mark Fedor + NYSERNET + 125 Jordan Road + Troy, NY 12180 + fedor@nisc.nyser.net + + + + + + +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 + cel@mitre-bedford.arpa + + 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 + craig@bbn.com + + 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 + satz@cisco.com + + Martin Lee Schoffstall + NYSERNET + 125 Jordan Road + Troy, NY 12180 + schoff@nisc.nyser.net + + + +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] + -- cgit v1.2.3