Article View: comp.protocols.snmp
Article #13Re: MIBs for SS7
From: Douglas R Donahue
Date: Mon, 03 Aug 1992 15:56
Date: Mon, 03 Aug 1992 15:56
71 lines
4891 bytes
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!ddonahueReferences:
<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