[ih] inter-network communication history

[John Day]

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.
> 
> Thanks!
> 
> Craig
> 
> 
> 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'
>> environment.
>> 
>> 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
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> 
> 
> -- 
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history