GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1109

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1109.txt · Last modified: 1989/08/03 21:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki