wasc@cgch.UUCP (Armin Schweizer) (09/01/89)
From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT.
I did not hear the same for SNMP. Is this valid for SNMP too?
What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)
Who knows of or runs a CMOT implementation? I would like
to have a direct contact.
kind regards
armin
Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
4002 Basel / Switzerland
phone: -41-61-697'79'46dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (09/02/89)
(Sorry. I intended to send this to the entire list. DHC) From dcrocker Fri Sep 1 21:28:53 1989 From: Dave Crocker <dcrocker> Subject: Re: DoD --> CMOT and SNMP To: mcsun!cernvax!cgch!wasc@uunet.uu.net The Internet Activities Board has declared SNMP and CMOT to be co-equal standards. If effect, this means that they both have a stamp of approval from a significant "standards" body. (For the TCP/IP technology, the IAB fills the kind of role that ISO and CCITT and ECMA do in various parts of international communities. So much for the stamp of approval. Your question is more to the point and asks about actual support by vendors. (A nicely practical point to have concern for.) A number of companies are currently shipping products that use SNMP. Further, the NSFNet is managed using it. It is my impression that virtually all TCP/IP vendors have announced intent to support SNMP, if they are not already doing so. SNMP is unique to the TCP/IP community, although it uses the OSI ASN.1 encoding standard, for specifying the format of objects. CMOT is derived from the OSI CMOT standards effort, although I am told there are some differences. It is not clear to me that these differences are in the management protocol, itself, it does run over a modified stack of support protocols. Most significantly, is uses TCP or, perhaps, UDP, instead of an OSI transport. Hence, CMOT gets you closer to the future of OSI network management protocol details. However, there does not appear to be any vendor that currently ships CMOT and, therefore, there is no field (production network) experience using it. While a number of vendors have announced plans to support CMOT, I am not aware of any official, announced, delivery dates from these vendors. A further point about the recent decision to make SNMP and CMOT co-equal standards is that their use of the Management Information Base (MIB) was entirely de-coupled. While one should expect them to continue to use the original 100 variable, there having additional variable in common is problematic. At the least, such sharing should be expected to organic or accidental, rather than formally enforced. (That should be "expected to be organic..." I am on a thin wire with a poor editor.) As always, I trust that others will elaborate on, as well as correct, the above. Dive in! Dave Crocker Digital Equipment Corp. P.S. On review, I note that I did not respond to your query about federal requirements for CMOT support: There is strong governmental pressure for moving to OSI. This is embodied in the GOSIP document. In general, however, the requirements are careful to allow use of alternatives. Perhaps the most extreme way of viewing this is that a vendor certainly cannot consider ignoring the OSI CMOT. I am less clear about their ability to dodge CMOT (but am sure that someone out there in tcp-land will chime in to clarify, please?) Enough vendors have stated intent to support CMOT and enough are working on it, that I would expect it to start showing up in the future. P.P.S. I should use this opportunity to suggest a personal bias. It is NOT about which protocol I prefer. In fact, the brouhaha has, in my opinion, distracted us from worrying about how to manage multi-administration inter-networks. The chosen protocol is not irrelevant to this, but my suspicion is that we could start with a hopelessly incomplete one and still not know how to use it to its fullest. That is, our general understanding and pursuit of specifying and developing management (application) SERVICES has been quite limited and that we would do well to focus on MIB enhancement and specification of standard applications for management. (I.e., focus on the bottom and top of the management architecture.) D/
schoff@SOLBOURNE.NYSER.NET ("Marty Schoffstall") (09/07/89)
>From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT.
I did not hear the same for SNMP. Is this valid for SNMP too?
On paper according to the RFC's they are both to be implemented by
vnedors/suppliers. SNMP exists and this for the most part all TCP/IP
vendors either ship SNMP in their product or are committed to in
their next release. Marketing research orgnizations are responsible
for exact numbers and analysis but I'm aware of 20-25 implementations
that you can buy today.
What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)
CMOT's advantage is that it is theoretically aligned with the International
Standard Organizations (ISO) program.
Who knows of or runs a CMOT implementation? I would like
to have a direct contact.
To my knowledge no one runs this in an operational network and I haven't
heard of the availablility of interoperable CMOT implementations.
Martyrobert@TRWIND.IND.TRW.COM (Robert W. Snyder) (09/08/89)
>>From one of our network devices suppliers I got the information, >that the DoD will request from all suppliers, that their >respective products support CMOT. >I did not hear the same for SNMP. Is this valid for SNMP too? > A major Air Force contract (ULANA) is considering requiring either SNMP or CMOT implementations. There are two major contractors on this contract that are competing against one another. One contractor (TRW - us) is supporting SNMP, the other contractor (EDS teamed with 3com/bridge) is supporting CMOT. Since the government is considering requiring the code after the contract award, they were sort of forced into excepting both or getting into a hassle with one of the two vendors by giving the other an unfair advantage. Since this contract will be a buying vehicle DoD wide, it could by that this is what your vendor is talking about. I could give you a good breakdown of vendor support for both, but I dont think that would be fair since I do not represent a disinterested third party. For anyone interested in gathering this information. I suggest that they attend Interop in San Jose where all the vendors will be available to ask. If anyone is aware of anything else that might be influencing SNMP vs CMOT in the DOD world I would appreciate a reply Hope this helps Robert Snyder Disclaimer -- nobody claims dis, but me TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505 USENET: trwind!robert INTERNET: robert@trwind.TRW.COM Phone 213-373-9161
karl@asylum.SF.CA.US (Karl Auerbach) (09/08/89)
In article <8909021142.AA08148@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes: > SNMP is unique to the TCP/IP community, Not quite true -- one could use SNMP to manage an OSI network. --karl--
pprindev@wellfleet.com (Philip Prindeville) (09/10/89)
>> SNMP is unique to the TCP/IP community, > Not quite true -- one could use SNMP to manage an OSI network. Or DECnet, or XNS, or NetWare, or even a bridge (via SNMP over Ethernet). (We don't have bridge control yet). -Philip
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (09/11/89)
>>> SNMP is unique to the TCP/IP community, >> Not quite true -- one could use SNMP to manage an OSI network. Excuse me, I'm confused. I thought that OSI was a model which described the procedures (steps) to establish a connection and transfer data between two nodes on a network regardless of the protocol suite employed. The ISO IP/TPn and Internet TCP/IP protocol suites can be described by the model as can networks based on Digital's DCA protocol suite, IBM's BSC protocol, and the ISO 1745 protocol. Merton
little@SAIC.COM (Mike Little) (09/11/89)
>> Not quite true -- one could use SNMP to manage an OSI network. >Excuse me, I'm confused. I thought that OSI was a model which described >the procedures (steps) to establish a connection and transfer data between >two nodes on a network regardless of the protocol suite employed. The ISO >IP/TPn and Internet TCP/IP protocol suites can be described by the model >as can networks based on Digital's DCA protocol suite, IBM's BSC protocol, >and the ISO 1745 protocol. OSI is an architectural model (one of many and the one with the most name recognition). I believe the confusion arises here from what I find to be common misspeak - refering to OSI when one actually should refer to ISO. Particularly, the phrase "an OSI network" where the intention is "a network based upon the ISO protocol suite". This may not be exactly what Phillip intended (Phillip please interject if this is nowhere close), but looks like where the confusion is arising from. -Mike
Dave_Katz@UM.CC.UMICH.EDU (09/12/89)
>name recognition). I believe the confusion arises here from what I >find to be common misspeak - refering to OSI when one actually should >refer to ISO. Particularly, the phrase "an OSI network" where the >intention is "a network based upon the ISO protocol suite". This may not I don't believe that the term "OSI network" is incorrect. There are numerous protocols with ISO standards numbers, but only a subset of those are protocols intended to support the OSI service definitions of particular layers. For example, the official title of ISO 8473, commonly known as "ISO IP", is "Protocol for providing the connectionless mode network service" (where said service is defined by the OSI network service definition). For what it's worth, in my experience folks around the standards community commonly refer to these things as "OSI protocols" and "OSI networks." [cue the sound of a hair splitting]
pprindev@wellfleet.com (Philip Prindeville) (09/12/89)
I don't think I'm the one who originally mentioned ISO, though Mike is correct about the loose general use of ISO vs OSI. Since ISO seems to be the only stack that is strictly compliant (complacent?) with the 7 layer model, most people mix the two. I believe I only mentioned XNS and DECnet. Karl Auerbach originally threw out OSI [sic]. I assumed that Karl was referring to ISO 8473 (CLNS), etc. Did I misunderstand? -Philip P.S. Merton: Did you switch employers recently?
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (09/12/89)
Over the past year, I've noticed the more frequent use of OSI in briefings
and publications to refer to the ISO suite of protocols. I was beginning to
wonder if while mucking about with AUTODIN, IDHS, and a host of other lesser
known networks I had missed something.
Merton
P.S. Phil: I'm still at the same stand. Since Bunker Ramo was formed by
Martin and Ramo Woolridge, we've been Allied, Eaton, and Contel.
The last change occurred a year ago but the domain name change
didn't occur until June.LYNCH@A.ISI.EDU (Dan Lynch) (09/15/89)
Robert, I've been away, so sorry for a late reply, but I have also had a chance to see other replies and must add my two cents worth. OSI stands for Open Systems Interconnection. ISO stands for International Organization for Standardization. (Yes, I know that the English/American abbreviation for that should be IOS, but it ain't that way this time...) OSi describes a model of communication among consenting systems. It was described in an ISO document many years ago. Then ISO committees began to fill out thier interpretations of how to accomplish the lofty goals of the OSI model. All of those "interpretations" have come aout as ISO documents. It is easy to mix the two acronyms up because of their use of the same alphabet symbols. I used to find it useful to make the distinction batween OSI and OSI. I thought (and still do think) that the TCP/IP suite of protocols are quite in line withthe OSI "model". So is DECNET, so is SNA, etc. (I mean, hey, an application has just got to shove the bits out the "right" interface/wire to an equally receptive application at the target system; how many ways can you describe to do that? In 1976 it was an accomplishment to even make that description. By this tim ein history it is a freshman problem, right?) So, today, we should quit splitting haris, and let the meaning of "OSI" be those protocols that are promulgated by ISO with regard to communications between consenting computers. (ISO also sets standards for cement ingredients, numbers of threads per inch/millimeter for screws, etc...) In other words, it is a waste of energy for someone to say they are OSI complinat unless they use the actual ISO protocols. We technologists may be able to sort his all out, but our customers should not have to sort out our internal debates. Let us let them see one label. That label is OSI. Dan -------
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/16/89)
Dan--
Speaking of "OSI complinat" [or even compliant], I noted with great
interest in the latest issue of _conneXions_ that "some applications
(for example, X.400, version 1984) access Session services directly",
according to the lead article, "Components of OSI: The Session Service"
(p. 2).
So even if we stipulate that it's undignified lawyering to distinguish
between "OSI" and "osi" (which is what I assume you meant to type), there's
still the fascinating question of whether we get to distinguish between
OSI, The Heralded "Reference Model" and OSI, The Not-Necessarily-Compliant
ISO-Blessed Protocols. (Note that the question-begging phrase "Protocol
Suite" was intentionally avoided.) For the RM, as we know, requires that all
"n-entities" communicate with their peer n-entities via "n-1 entities"
[give or take a hyphen]; the I-BP, however--perhaps in conformance to, if not
with, the by-now-ancient Padlipsky's Law which holds that "It's Layer [sic]
5-7"?--have no such compunction, as we've learned before and have just
been reminded again.
(Aside to purists: no, "reminded again" isn't redundant--though "reminded
of again" might be a tad more idiomatic.)
Or are the tales that X.400 is/are I-BP unfounded?
Or maybe there's a new RM?
I mean, I'd actually kinda like to take the Mother Knows Best approach
myself: the Fuller Context, after all, is that "a prophet is not without
honor save in his own country _and in his own house_", and that gets rather
old after the first dozen years. But what's a dutiful child to do when
Mother keeps contradicting herself?
perplexed cheers,
map
P.S. Feel free to try to influence the editor of _conneXions_ to run
your msg (with referenced typoes preserved, please) and the above as
Letters to the Editor, if you like--but remember: no copyediting of
my stuff, and I get to reply to your response if you make one....
-------robert@trwind.ind.TRW.COM (Robert W. Snyder) (09/19/89)
Dan, How does your response relate to the traffic I sent? I just sent some traffic commenting on whether the DoD is requiring CMOT and SNMP in future TCP/IP implemenations delivered to the government. Robert Snyder Disclaimer -- nobody claims dis, but me TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505 USENET: trwind!robert INTERNET: robert@trwind.TRW.COM Phone 213-373-9161
LYNCH@A.ISI.EDU (Dan Lynch) (09/19/89)
Robert, excuse me, but my resposne was dead on with respect to your inquiry. I said that to my knowledge DoD had not made a blanket requirement with regard to network management protocols. The IAB (which is a technical group, not a purchasing authority) has passed on the technical merits of the two approaches. The SNMP approach has a widespread implementation base as of this date in history. The CMOT approach does not. A good number of CMOT implementations are in progress, with some of them likely to be shown publically in the next month. But, by no means are their actual product announcements pending. Thus, I would infer that anyone telling a potential buyer that he should buy from vendor X because vendor X has CMOT and CMOT is the "LAW" is speaking an untruth; i.e., a damn lie. If you have information to the contrary I would appreciate hearing it. Dan -------
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (09/19/89)
The answer to your question will be in the amendments to the Government Open System Interconnection Profile (GOSIP) which have been or will be published in the Federal Register. The NIC will probably have electronic copies of any amendments that have been published under PROTOCOLS: along with the original GOSIP and FIPS documents. If the question is related to a DoD procurement, you should check directives issued by the Office of the Secretary of Defense (OSD) which will define any deviations from the GOSIP requirements. Based on my aged copy of the GOSIP document, neither SNMP nor CMOT is required. Neither is likely to be required based on directions established in the GOSIP document; however, it would be reasonable to expect an agency to specify CMOT in specific procurements for interoperability with existing systems/networks. Merton
sra@ULANA.MITRE.ORG (09/21/89)
Dan
I did not think it was possible but your response together with
the large amount of traffic has stirred me enough to respond.
I can not speak for all of DOD nor can I speak for all of the Air
Force. I can, however, respond in terms of my knowlege of the
ULANA program and its requirements for SNMP and CMOT.
The ULANA program is currently delivering LAN products to Air
Force costomers. These products are basically a wide variety of
products that implement the extended suite of protocols based
upon TCP/IP for 802.3 networks and in some cases FDDI networks.
These products range from transceiver cables to full hardware/
software attachments for mainframes.
Managing networks of this type would be difficult if all products
were from a single supplier. We do not have that luxury. Ulana
products come from a wide variety of LAN vendors. With a single
integration contractor we might have been able to define network
management in the ULANA context. Instead of one major
integration contractor the ULANA program has two. Still with
only two we might have been able to define an interoperable
network management subset between these vendors except for the
fact that ULANA components are not the only components on the
network. We also expect AT&T machines from the SMSCRC contract,
PCs from the Desk Top III contract, gateways from the Host
concentrator contract and that vast array of user procured
products that claim to be "ULANA compatable."
Being unable to define a government unique management protocol
{thank goodness} we strove to develop a single suite of
network management products form the internet community.
Unfortunately, rather than a single solution with an evolution
from today till the future we have two SNMP and CMOT. Had we
chosen either it would have cost the government many dollars
since vendors have decided to implement one or the other (or in
some cases both). We chose instead to allow the vendor community
to implement either. The management station therefore is
REQUIRED to implement both.
So as a longwinded answer to the variety of questions:
1) To my knowlege there is no requirement to implement CMOT
except in the network management station.
2) The only current requirement for the users regarding SNMP or
CMOT is a policy statement requiring them to use the ULANA
contract.
3) If users procure their own equipment outside ULANA, and
wish to manage this equipment with future management stations
then they MUST have either a CMOT agent or an SNMP agent.
Should the Army and the Navy join the ULANA program the above
will apply to them as well.
A second set of questions asked for the availability of network
management agents. Although many vendors are shipping SNMP or
are about to anounce either SNMP or in some cases CMOT, some
vendors are doing neither. This makes the network management
solution even more complex. For example, EXCELAN, a very good
network vendor who has been active in network management events
has declined to provide us cost or schedule information on an
agent for their VMS attachment. Because of this I find it hard
to understand why anyone would buy EXCELAN VMS products. Other
vendors have indicated that they will need several hundred
thousand dollars to provide agents. Since we desire commercial
products and do not have the desire or funds to develop a wide
variety of agents we are not able to come to the aid of the
community this time.
So to answer the questions as to availabilty of agents:
1) Ensure that your vendor of choice has announced or has
available network management agents for the product you desire.
2) Be very cautious of vendors that provide dates more than three
months in the future.
3) Vendors that do not provide management agents for their
products (for example EXCELAN) are not providing the full suite
of necessary protocols and should, at all costs, be avoided.
A list of with agents available through the ULANA program will be
available in early October.
A last thought, if there are any vendors with network management
stations that implement both SNMP and CMOT NOW! please give us a
call. We would like to hear about it.
Stan Amesschoff@SOLBOURNE.NYSER.NET ("Martin Lee Schoffstall") (09/22/89)
Stan,
I too am stirred to respond, to what appears to be a statesman like message
of yours.
Being unable to define a government unique management protocol
{thank goodness} we strove to develop a single suite of
network management products form the internet community.
You're clearly unable but you and your staff certainly seem to have tried.
Aren't their names on CMOT documents? Hasn't MITRE participated
heavily in pushing CMOT as a major agenda item. At interop88 I
heard what you had to say after the network management panel, you
were pushing then.
Should the Army and the Navy join the ULANA program the above
will apply to them as well.
This would be unfortunate since clearly things have changed in a very
major way in the area of network management in just the last 12 months.
One doesn't want to be saddled with out of date concepts and technology
from past recommendations, and 2nd opinions can also be important to
test the validity and quality of past recommendations.
3) Vendors that do not provide management agents for their
products (for example EXCELAN) are not providing the full suite
of necessary protocols and should, at all costs, be avoided.
Since you've left the arena of "facts" and entered into the arena
of recommendations here are a few to consider:
(1) Consultive recommendations should be considered from sources that have both
deep and current experience with Internet technology (for instance knowing
what is in an ARP table). My personal favorite is Epilogue which has
implemented both CMOT and SNMP, they'll do anything for a buck :-)
but more importantly they do it VERY VERY well.
(2) Independant assement is very important, having a vested interested
in a recommendation needs to be stated and known. I am of course an
co-author of SNMP.
(3) User input and reality input is very useful to make a good recommendation.
Because its on paper doesn't mean its real, because its an "International
Standard" doesn't mean it will work well.
(4) Recommending moving targets is painful for vendors and does nothing
for users.
Lastly, your message discusses the "facts" of NetworkManagement in ULANA,
whether they are good facts or not is another issue.
Martin Schoffstallstev@VAX.FTP.COM (09/22/89)
*We chose instead to allow the vendor community *to implement either. The management station therefore is *REQUIRED to implement both. *Stan Ames as someone looking into developing management stations, where can i get two independantly constructed CMOTs to test my code against? there are several SNMP "stacks" around (CASE's, Proteon's, NYSERNet's, cisco's, MIT's, CMU's). is anyone ready to give me the IP address of an agent to test against? is anyone working on a public domain "stack" like the MIT and CMU SNMP code? good luck getting a management station to understand both at this point in time. i dont necessarily think SNMP is god's gift to network management. but, it is out there, it does work, it seems to be widely supported. why go over to something like CMOT unless it offers much greater functionality, which it does not seem to. it's big draw seems to be a connection to ISO (or is it OSI?) standards. i wouldnt be suprised to find the SNMP people porting SNMP to run on TP4/CLNP. stev knowles stev@ftp.com ftp software 617-246-0900