Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
Network Working Group                                            V. CerfRequest for Comments: 1052                                           NRI                                                              April 1988IAB Recommendations for the Development ofInternet Network Management StandardsStatus 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 1988Specific 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 1988EXECUTIVE 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 aCerf                                                            [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 itsRFC-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 managementCerf                                                            [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 1988MEMBERS 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.netCerf                                                           [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.netCerf                                                           [Page 11]

RFC 1052                  Internet Management                 April 1988   Glenn Trewitt   Center for Integrated Systems, Room 216   Stanford University   Stanford, CA 94305        Trewitt@amadeus.stanford.eduMEETING LOCATION:  San Diego Supercomputer Center, UC San DiegoLOCAL ARRANGEMENTS:  Paul Love, SDSCMEETING DATE:  29 February 1988AGENDA 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 AdjournCerf                                                           [Page 12]

RFC 1052                  Internet Management                 April 1988REFERENCES   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,      obsoletesRFC-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]

[8]ページ先頭

©2009-2025 Movatter.jp