RFC 1109

Report of the second Ad Hoc Network Management Review Group

πŸ“… published August 1989, from ietf

RFC 1109 πŸ“œ Report of the Second Ad Hoc Network Management Review Group

okay bestie, this is the title block πŸŽ€ (part 1 of 2)

  • Network Working Group: the working group this RFC belongs to 🌸
  • Request for Comments: 1109
  • Author: V. Cerf, NRI πŸ’–
  • Date: August 1989 πŸ“…
  • Category: the header doesn't list one, but the Status section says it's an official Internet Activities Board (IAB) policy position πŸ”₯
  • Obsoletes / Updates: the header doesn't say it obsoletes or updates anything πŸ™ˆ

Status of this Memo ✨

ngl this section is the official stamp 🫢 This RFC reports an official Internet Activities Board (IAB) policy position on how Network Management gets treated in the Internet. It shares the results and recommendations from the second Ad Hoc Network Management Review, which happened on June 12, 1989. The first meeting's results were reported in RFC 1052 [1]. The IAB, assembled July 11-13, 1989, approved the report and adopted its recommendations. Distribution of this memo is unlimited πŸ¦‹


INTRODUCTION 🧚

so the backstory is that on February 29, 1988, an Ad Hoc Network Management Review Group got together to look at where network management tech stood for the Internet and to make recommendations to the Internet Activities Board about network management policy πŸ’… That meeting's outcome was summarized in RFC 1052, and it basically set up a framework. Two network management protocols got picked for more work: the Simple Network Management Protocol (SNMP) and the Common Management Information Protocol on TCP (CMOT) 🌈

Then both SNMP [6] and CMOT [5] got advanced to Draft-Standard/Recommended status for use in the Internet [SNMP: RFC 1098, CMOT: RFC 1095] ⭐

At the same time, everyone agreed to set up a working group to coordinate the definition and specification of managed objects that either protocol could use πŸ“ They also agreed to use the ISO Structure of Management Information (SMI) spec from that time as a reference standard. It guides the naming and abstraction conventions for 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 fifteen months after that, a lot of progress happened πŸš€ The common Management Information Base got better, and network management tools got implemented, deployed, and used all over the Internet 🌸

Right now, the public subtree of the Internet MIB has roughly 100 variables (managed objects). The SNMP and CMOT working groups agreed these are mandatory for Internet network management πŸ’œ The June 12, 1989 meeting got convened to review progress, figure out whether actions were needed to help network management tools keep evolving, and recommend specific actions to the IAB πŸ‘‘


SNMP STATUS πŸ’…

so right after the meeting in RFC 1052, a group got together to make extensions and changes to SNMP's predecessor, the Simple Gateway Monitoring Protocol πŸŽ€ There was a "connectathon" at NYSERNet, an RFC got published, and in the Fall, demos of network management tools using SNMP were offered at Interop 88 [a conference and show presented by Advanced Computing Environments (ACE)] πŸ¦‹

SNMP is in use across a bunch of networks in the Internet, plus private packet networks around the world 🌍 A number of vendors have implementations out in the field, including cisco Systems, Proteon, and The Wollongong Group. There are also vendor-independent reference implementations from NYSERNet and Case and Key in Tennessee, along with some freely available versions from MIT and CMU 🫢

Here's the thing, though: the common Internet MIB has roughly 100 variables, but a typical SNMP monitoring system might support anywhere from 100 to 200 ADDITIONAL objects defined in private or experimental MIB space 😭 Lots of these are device or protocol dependent variables 🧩

Scaling to bigger numbers of monitored objects and subsystems is still a challenge πŸ’€ The group noticed that fault monitoring is easier to scale than performance and configuration monitoring. That makes sense, because fault monitoring can work on an exception basis, while performance and configuration monitoring are more likely to need periodic reporting πŸ“ˆ


CMOT STATUS πŸ¦‹

RFC 1095 (CMOT) got published not too long ago 🌈 It built on experience from prototype implementations demoed at Interop 88 that Fall ✨ The current CMOT spec is based on the ISO Draft International Standard version of the Common Management Information Protocol (CMIP). CMIP is moving toward International Standard status, but the exact timing is kinda fuzzy. It'll happen late in 1989 or maybe in the first quarter of 1990 πŸ™ˆ Some changes will fix known errors, and the CMIP document itself will probably get restructured πŸ› οΈ

During the discussion, people pointed out that there's a LOT of network management that neither CMOT nor SNMP covers. Examples include downloading software, configuration management, and user access control πŸ” Authenticating the source of network management commands and responses is another area that matters a lot to providers and users of these tools πŸ’œ

The National Institute for Standards and Technology (NIST) is sponsoring the development of implementors' agreements on how network management tools behave functionally. That includes, inter alia, logging, event reporting, error reporting, structured object management, and alarm reporting πŸŽ€

At the meeting, nobody reported any publicly available CMOT implementations yet. Still, a number of vendors are planning developments in both agents and network management tools πŸ“ The University of Wisconsin plans to demo CMOT using the ISODE software at Interop 89 [(tm) ACE] in September 1989 🫢

NIST ACTIVITIES 🌸

Okay so the Ad Hoc Review had the benefit of reps from NIST who are active in the network management area πŸ’…. They spilled that the major focus right now is at layers 3 and 4, where objects are being defined in accordance with "templates" provided by ISO's SC21 🧚. IEEE 802 is also going after MIB objects, just not with the same templates the NIST NMSIG is using now. The layers above transport are only just starting to get 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 vibe of this part 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 πŸ”₯. That's especially true as the time approaches when coexistence of the OSI protocol suite with the existing Internet protocols is the norm πŸ‘‘.

CONCLUSIONS AND RECOMMENDATIONS πŸ’–

Okay, so 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 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 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
πŸ“¦ where this page comes from