🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.snmp
Article #13

Re: MIBs for SS7

#13
From: Douglas R Donahue
Date: Mon, 03 Aug 1992 15:56
71 lines
4891 bytes
In article <3145@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>
>	nath@mpd.tandem.com (Narendra M. Nath (Pi-Net)) writes:
>>> 
>>> Does anyone out there know about any existing MIB for SS7.
>>> If so please send me a copy
>
>	<mschenk@research.ptt.nl> Mike Schenk writes:
>
>%  You mean managing SS7 with SNMP? That does not seem very appropriate
>% and I have not heard about anyone doing it. However, managing SS7 with
>% CMIS/CMIP is something completely different.
>
>  Why the hell not use SNMP ?  It is more secure than CMIP and it
>WORKS properly and interoperably and it is deployed in 100 times more
>sites than CMIP/CMOT is.  The only thing "completely different" is
>that using CMIP make NO SENSE technically, while using SNMP makes a
>hell of a lot of sense.  
Well for one thing, many implementations of SNMP are not transport level
indepent. The result is that they are tied to UDP/IP based internets. Not a
joyfull situation when dealing with huge multiprotocol based networks. The
utilization of proxy agents facilitates a solution but has limitations on
efficiency. Unless the implementor of NM functionality is doing so on behalf of
an organization which has a MIB registered with with the Internet Assigned
Number Authority (IANA) (As this is the only way in which asyncronous capability
can be associated with user defined functionality) then the only net management
mechanism available (other than that for the standard MIB associated TRAPs) is
polling. The control functionality associated with standard MIBs is generally
limited, as a result.  Polling is not the most effient utilization of network
bandwidth. Such an arrangement many not be feasible with such an arrangement,
as a result.  A related aspect is that end-end managment is only possible on
IP based networks, to boot. Management of multi-protocol based networks then
becomes, shall we say, "creative".

As far as SNMP being more secure than CMIS, such statements are plain irres-
ponsible. Network management via CMIS has not even been standardized yet (as
far I know, and it wasn't the last time I checked) and neither have the SNMP
based security features, for that matter. Kerbose and DES are being implemented
in various vendors SNMP based net mgmt packages, but as far as stardization via
the IAB is concerned, SNMP based security has not taken been acheived as of
Aug 92 (again, as of the last time I checked). For that matter, SNMP and CMIS
address two different areas of network management. Their implementation and
utilization is not mutually exclusive and may even turn out to requisite for
the managment of large multiprotocol based internetworks.

>  No doubt this is why BELLCORE has published a number of MIBs for use
>with SNMP.  
The use and choice of SMI/MIBs by BELCORE was more for interoperability and 
platform independence than because of the incidental association between
SMI/MIBs with SNMP. The beauty of the utilization of SMI/MIBs is that it 
provides platform, imlementation, and network independence with respect to data
representation and management. ASN.1/BER are presentation level services which
facilitate representation and management independence of any layer which reside
in the application layer and make use of the service. A result of such is that
any application level protocol is able to represent and manage objects via the
definition and utilization of ASN.1/BER. SNMP being an application level
protocol falls into such a category. However, so does CMIS/CMIP/ROSE. Besides,
ANS.1/BER are ISO standards so don't go thinking that SNMP has defined the
definitive answers to net mgmt all by itself.

"ASN.1 is destined, for better or worse, to become the network programming
language of the 90s, just as the C programming language is largely seen as
having been the systems programming language of the 90s. So, the choice of
ANS.1 is a good one."   The Simple Book by Marshall T. Rose

Ergo BELLCOREs choice.
-- 
||--  Douglas R. Donahue           --  GE Aerospace                         --||
||--  ddonahue@atl.ge.com          ||  Advanced Technology Laboratory       --||
--||  609 866 6614                 ||  Route 38 : Bldg 145-2                ||--
--||  8 * 777 6614                 --  Moorestown, NJ 08057                 ||--
Technical Details
Message-ID: <1992Aug3.155642.21219@puma.ATL.GE.COM>
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!ge-dab!puma.ATL.GE.COM!ddonahue
References: <2115@devnull.mpd.tandem.com> <1992Jul26.233303.1@research.ptt.nl> <3145@ra.nrl.navy.mil>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!ge-dab!puma.ATL.GE.COM!ddonahue
From: ddonahue@fergie.atl.ge.com (Douglas R Donahue)
Newsgroups: comp.protocols.snmp
Subject: Re: MIBs for SS7
Message-ID: <1992Aug3.155642.21219@puma.ATL.GE.COM>
Date: 3 Aug 92 15:56:42 GMT
References: <2115@devnull.mpd.tandem.com> <1992Jul26.233303.1@research.ptt.nl> <3145@ra.nrl.navy.mil>
Sender: news@puma.ATL.GE.COM (USENET News System)
Organization: GE Aerospace, Advanced Technology Labs
Lines: 71