How Distributed is Distributed Management or Can Too Many Cooks Spoil the Broth? by John Day | Pouzin society
The need for network management has always been recognized. At the same time, it recognized as overhead to selling equipment as well as a facility to smooth over the shortcomings of the equipment. Most datacomm networks in the 1970s and before were fairly small, often using equipment from a single vendor. While the network management stations, then called network control, was sold as a loss leader: Sell the razor cheap, they buy more blades. As the 70s progressed, networks were not only getting larger but more and more diverse. The likelihood of a multi-vendor network was not only more likely but becoming more common. A broader view of network management was needed.All of this was coming together as the 70s neared the end and the US computing industry initiated the OSI effort in 1978. Since the industry had always sold network control, they recognized at the beginning its importance. And they adopted a new more sophisticated sounding term, network management. Not realizing that in these new packet networks, it was qualitatively different. In OSI, it was given its own working group.[1] At the same time, there were strong forces working against network management. Causing the work to be slow to getting off the ground, partly because it was a rather amorphous topic. BBN had done such a good job providing network management for the ARPANET, that many didn’t realize how necessary it was. Consequently, the first rudimentary foray towards network management was with ICMP around 1980, and the first real network management wasn’t until 1988 with SNMP, which is considered below.Up to this point, there had not been much of a consistent structure to network management, just lots of lists of parameters. Althoug there was agreement on five broad ‘management applications,’ the so-called FCAPS: Fault, Configuration, Accounting, Performance, Security. But there was really no operational model of they worked together. At least now, it was 5 lists. It didn’t take long for vendors to realize that network management standards were a major threat to their barriers to competitors. With management standards, network equipment could be more easily swapped out for a competitor’s. The response was predictable.The contributions (many from IBM) continually added more and more issues to the discussions as to what these applications might be about. In this sort of environment, it was very hard to develop concrete proposals for standards and IBM favored postponing getting too concrete until it was clearer where it was going. Of course, this was for all sorts of good reasons. In the early 1980s, IBM ran full-page ads in places like Scientific American showing how the original 5-layer SNA model really had seven layers and followed the OSI Reference Model. The ads went on to point out that while OSI did data transfer, it didn’t handle network management. Was IBM stonewalling? Some said so. It was quite obvious that whoever defined (and sold) network management said a lot about how the equipment in the network had to behave and thus controlled the account.In 1984, GM and Boeing with NIST had joined forces in an effort, called MAP/TOP, to develop factory and office automation based on the emerging LAN and OSI standards. In the fall of 1984, they visited the subsidiary of Motorola, where I worked looking for ideas on network management. Earlier that year, we had begun work on network management for our LAN products and in late Spring I had developed a network management model, which we presented to them. They were enthusiastic about it, thought we were far ahead of everyone else. Our staff began attending IEEE 802.1 meetings to help them pull together the specifications.[2] The reaction by the other companies was typical, “O, now I understand.” Well, only superficially but it got things moving. Within 18 months, IEEE 802.1 had an architecture and protocol completed, which were submitted fully formed into ISO as working drafts ready to be voted on. IBM never saw it coming. They tried to stop it or delay it, but the proposals had too much support. (All of the companies that had participated in its development in 802.) That broke the logjam and began in earnest the development of CMIP and its associated standards.In some sense, that effort was relatively traditional in that it consisted of a Network Management System, modeled on the classic operations center concept, collecting information from Agents in the devices in the network and producing commands to the Agents to modify their configuration, etc. The state of hardware at the time made it important to minimize the resources the Agents required. This flipped the traditional client/server concept to putting most of the work at the client, rather than server. In addition, it had been recognized quite early in the development of packet networks that some functions like routing and congestion control had to be automatic feedback mechanisms recognizing that events in the network were happen