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: [email protected]

Cerf [Page 8]