summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1109.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1109.txt')
-rw-r--r--doc/rfc/rfc1109.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1109.txt b/doc/rfc/rfc1109.txt
new file mode 100644
index 0000000..4e9804d
--- /dev/null
+++ b/doc/rfc/rfc1109.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group V. Cerf
+Request for Comments: 1109 NRI
+ August 1989
+
+
+ Report of the Second Ad Hoc Network Management Review Group
+
+
+
+Status 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 in RFC 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 in RFC 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 in RFC 1065 [2] and RFC 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 in RFC 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 STATUS
+
+ RFC 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 to
+
+
+
+Cerf [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 to
+
+
+
+Cerf [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). The RFC 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 1989
+
+
+APPLICATION 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 1989
+
+
+CONCLUSIONS 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 common
+
+
+
+Cerf [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 over
+
+
+
+Cerf [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 Netlabs
+
+Author'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.EDU
+
+
+
+
+
+
+Cerf [Page 8]
+ \ No newline at end of file