[ih] inter-network communication history
jeanjour at comcast.net
Fri Nov 8 07:00:22 PST 2019
And from what I understand, the HEMS implementation turned out to be simpler and smaller than the SNMP implementation.
> On Nov 8, 2019, at 09:56, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
> Hi Jack:
> You're crossing network management streams.
> SNMP had nothing to do with NMP except, perhaps, some influences on Marty
> Schoffstall. You are probably thinking of HMP (Host Management Protocol).
> Around 1983, network management work at BBN started going down two paths.
> One was the stuff that Hinden's team was doing for the NOC. The other was
> Jil Wescott's distributed network management system (I think called NOMS?)
> with Charlie Lynn and I think Ross Callon and Karen Seo and, briefly me,
> working on it. Then DCA funded a large project (name I've forgotten)
> trying to build a better suite of tools (but not protocols as I recall) for
> the MILNET NOC. That work never made it out of BBN.
> In 1987, NSF realized the cupboard for multi-vendor network management
> protocols was bare. Steve Wolff asked me to come up with a solution, which
> become HEMS and was based on my experience with NOMS and discussions at
> IETF and some great ideas from Glenn Trewitt (who had been dealing with
> Stanford's substantial internet). Jeff Case and Marty Schoffstall (and
> others) felt HEMS was too complex to deploy ASAP (and ASAP was the need --
> NSFNET was growing like topsy) and devised SGMP (Simple Gateway Management
> Protocol) which the IETF then evolved into SNMP.
> On Thu, Nov 7, 2019 at 4:33 PM Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
>> On 11/7/19 1:35 PM, Vint Cerf wrote:
>>> Don't forget CMIP, HEMS AND SNMP
>> Hmmm. Well, what I remember is:
>> SNMP was instantiated as a first step toward a comprehensive NMP
>> (Network Management Protocol). As I recall, NMP was more of a concept
>> than a protocol. It was an umbrella covering a lot of pieces.
>> As we were struggling to make the Internet 24x7, we did a lot of
>> cogitating about what it meant to manage a network, which went well
>> beyond basic real-time monitoring and control. In addition to the
>> Internet "core gateways", at BBN we were managing and/or operating a
>> variety of networks, so we had a fairly broad view of the issues that
>> crop as you operate and evolve networks over 5 or 10 years.
>> One dimension of that exploration was into life-cycle management. That
>> involved things like how to measure traffic statistics and patterns,
>> identify and predict trends, plan for topology alterations to handle
>> future traffic, plan for changes needed to add new users or
>> applications, etc.
>> It also included operational disturbances. How do you deploy a new
>> major software release without disrupting users' activities? How do you
>> add a large number of new users with a new application without
>> disrupting current activity? How do you debug problems, without
>> disrupting other users?
>> In the DDN context, a memorable one of those was the release of a major
>> new IMP version. To make that run smoothly, we had to create a lot of
>> mechanisms and processes even beyond those needed within the IMPs
>> themselves to smoothly convert to the new release. E.G., we created a
>> service product called "TestNet" which allowed systems integrators to
>> test and debug their software in the new environment via a dial-up link
>> and get it all running smoothly before going live in the users'
>> I recall one motivation for that was some Army system -- the one that
>> provided payroll services and issued the soldiers' checks. If it didn't
>> work the week after the software transition.... well, those guys have
>> some serious capability to protest such disrespect.
>> At one point an ARPANET clone was involved in the systems that are used
>> by the officers at points of entry into the US. When something was
>> wrong... well, it seemed like having a BBN identifier on your paperwork
>> made you much more likely to be randomly selected for extra scrutiny at
>> the airport.
>> Another dimension of network management was into management of resources
>> - i.e., respecting the "boundaries" Dave mentioned. This came up in the
>> context of SATNET and the VAN Gateway (ARPANET connected to the public
>> X.25 world). Whoever owned something, and paid for its operation,
>> wanted it used for their purposes only. So ARPA research traffic could
>> use SATNET, but other stuff should use the X.25 service (and getting the
>> bill to go to the right place depended on quirky details like which side
>> "dialed the phone" to establish the X.25 connection between gateways.)
>> In the technical environment, this requirement appeared as "policy
>> routing" and related technologies, protocols, etc.
>> Resource management extended into the security world as well, i.e.,
>> making sure that only authorized "people" (humans, computers, software,
>> whatever) were able to access only the appropriate resources. It also
>> impacted functionality like TOS - how do you make traffic go down the
>> most appropriate path for the kind of service it required.
>> All of that kind of "management" was folded under "Network Management".
>> It was, and is, a huge area. It went far beyond the basic
>> monitoring/control of SNMP. But to get something quickly for the
>> network we were trying to operate, SNMP was created.
>> SNMP was Simple Network Management Protocol. I remember we had
>> discussions about exactly which noun the adjective "Simple" was
>> modifying. My thought was that it really should have been Simple
>> Protocol for Simple Management of Simple Networks - i.e., SPSMSN or
>> something like that.
>> Anyway, SNMP was an "interim" solution while the larger issues were
>> sorted out. I recall that Bob Kahn and I circa 1983 initiated a new
>> project area called "Automated Network Management" where we would
>> explore the more esoteric resource management ideas aligned with ARPA's
>> charter. We also put together (got funded) projects from several of the
>> various "operational" clients we had, who were pretty desperate for
>> near-term pragmatic tools to help them manage their own stuff (those
>> research guys never write the Users' Manual!). All of that combined
>> would make a foundation project for further NMP development.
>> Sometime in late 1983, I lost track of the "NMP" work. BBN reorganized
>> and those various projects and contracts ended up scattered around to
>> different divisions after the upheavals settled. I think that
>> separation of the "research" and "operational" worlds might have had a
>> noticeable effect on the history of the Internet, by breaking the
>> "pipeline" from research to operations that Vint started when he moved
>> the gateways to become 24x7 services.
>> I don't know anything about HEMS. It may be what later came out of the
>> Automated Network Management project as a protocol part of NMP, but I'm
>> not sure if it ever got deployed or transitioned and used in any of the
>> operational network environments.
>> I know even less about CMIP. I could never get my teeth into ISO
>> technology. There wasn't any code to play with, and every time I tried
>> to read those stacks of documents I'd fall asleep.
>> Fun times though,
>> /Jack Haverty
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
> Craig Partridge's email account for professional society activities and
> mailing lists.
> Internet-history mailing list
> Internet-history at elists.isoc.org
More information about the Internet-history