[ih] inter-network communication history

[Craig Partridge]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20191108/107e26c0/attachment.htm>