Alexander Keller
MNM
TEAM
Munich Network Management Team
Faculty of Computer Science, Munich University of Technology
E-Mail: keller@informatik.uni-muenchen.de
AbstractandStructureofthePresentation
Duringtherecentyears,integratedmanagementhasbecomemorecomplicatedduetothestandardizationofseveralcompetingmanagementarchitectures:Thisaddsadditionalheterogeneitytothealreadyexistingamountofheterogeneityoftoday’sdistributedsystems.ThemostwidespreadmanagementarchitecturesaretheOSI/TMNandInternet(SNMP-based)managementframeworks.Withthelackofinteroperabilitybetweenthesedifferentmanagementarchitectures,thereisastrongdemandforsolutionsthatprovidesmoothtransitionpathsbetweenthem.
ThispresentationdescribestheresultsofaresearchprojectdealingwiththedesignandimplementationofaQAdapterFunction(QAF),oftencalledManagementGatewayfortheintegrationofSNMP-managedresourcesinaTMNenvironment[16].QAFsareamechanismforbringingmanagementinformationfromthepre-TMNinstalledbaseofsystemsintoaTMNenvironment[3].ThereasonforchoosingaTMN-compliantmanagementplatformasthecoreofourdistributedmanagementsystemisthefactthattheOSI/TMNmanagementarchitectureyieldsthelargestsetofmanagementfunctionalitybyfar.Ontheotherhand,sinceSNMPagentsareinwidespreaduse,anintegratedmanagementsolutionneedstotakeintoaccounttheInternetmanagementframework.Furthermore,iftheInternetmanagedobjectsappearfromthemanagingsystem’sperspectivesimilartotheotherOSI/TMNmanagedobjects,thecompletesetofOSI/TMNmanagementfunctionalitycanbeappliedtothem.
Thispaperisorganizedasfollows:Section1comparesthreepossiblewaysforbridgingthegapsbetweendifferentmanagementarchitecturesandgivesthereasonswhywedecidedtousetheQAFapproach.Section2describestheunderlyingconceptsandtheprincipalstepsfordesigningaQAFforSNMP;italsopresentsalreadyexistingalgorithmsandmethodswhichhavebeenusedforthedesignofourprototype.Obviously,thedevelopmenttoolshaveanimpactonthestructureoftheacquiredsolution;section3thereforedescribestheIBMTMNProducts,aTMNdevelopmenttoolsetthatweusedfortheQAFimplementation,andexplainsthearchitectureoftheprototype.Section4discussesseveralimplementationissuesandfeaturesoftheQAF,namelyhowthescopingandfilteringcapabilitiesarerealizedandhowthecapabilitiesoftheQAFcanbeincreasedbyintroducingSNMPMIBsdescribingnewresources.Finally,section5concludesthepaperandpresentsissuesforfurtherresearch.
1IntroductionandMotivation
1.1Approachesforinteroperabilitybetweenmanagementarchitectures
Interoperability between Management ArchitecturesMultiarchitectural OSFMultiarchitectural AgentQ-Adapter FunctionCMIPSNMPCMIPSNMPCMIPQ3CMIP AgentQ3SNMPCMIPQ3SNMP ManagermCMIPSNMPSNMPResources1. IntroductionResourcesAlexander KellerResourcesMNMTEAMTherearebasicallythreedifferentstrategiesforachievingaseamlessinteractionofcomponentslocatedindifferentarchitecturaldomains(seealso[15]):
Thefirstapproachconsistsinplacingtheburdenofintegratingthedifferentarchitecturesonthemanagingsystem.SuchamultiarchitecturalOperationsSystemFunction(OSF)supportsasetofmanagementprotocolswhichareimplementedontotheOSF’scommunicationstack.Aconversionbetweendifferentmanagementprotocolsisthereforenotnecessary.ThetransformationofthemanagementinformationdescriptionsisoftenlefttothemanagementapplicationsandnothandledbytheOSFinfrastructure.TheexperienceswithXOM/XMPshowthatthiskindofintegrationisunsatisfactory:MultiarchitecturalOSFsdistinguishatthetopofthetopologyhierarchybetweenthedifferentsupportedarchitectures.Theapplicationofonearchitecture’sspecificfeatures(suchastheOSIscopingandfilteringfacilities)tomanagedobjectsinanotherarchitectureisimpossible.
Analternativeistheintegrationattheresourcelevel,i.e.themanagedsystemssupportmorethanonemanagementprotocol;theyareequippedwithmultiarchitecturalagents.Thisisusuallyunfeasibleforthefollowingreasons:SNMPagents,forexample,areoftenusedtoperformmonitoringofsimplenetworkdevices.Theyshouldnotconsumealargeamountofresourcesandareusuallybuiltintothefirmwareofthedevice;theimplicationsarethattheseagentscanneitherbeenhancedtosupportanothermanagementprotocolnorshouldtheyintroduceadditionalcomplexity.Foranin-depthdiscussionofthissubject,thereaderisreferredto([18],[6]).
ThethirdsolutionistheQ-adapterfunction.Itisthenpossibletomanageservices,systemsandnetworksindifferentmanagementarchitecturesfromasinglepointofcontrol.ItisevenpossibletoapplythepoweroftheOSImanagementarchitecturetoanyresourceinthedifferentarchitecturaldomains,asshallbedescribedinsection4.1.InmanagementarchitectureshavingnonotionofamanagementfunctionalmodelsuchastheInternetframework,theapplicationofmanagementfunctionality“borrowed”fromotherarchitecturesisparticularlyuseful.Forthesereasons,wedecidedtofollowthisapproachforthedesignandimplementationofourinteroperabilitysolution.
2AchievingInteroperability
2.1TransformationStep1:MappingtheInformationModels
Information Model Mapping: The IIMC AlgorithmTransformation of Internet-SMI Elements into new GDMO Class Definitions:1. Internet-SMI GroupsMOCs2. Internet-SMI Table RowsMOCs3. Other Internet SMI-ElementsMOC Attributesmib-2topsystem interface at ip imcp tcp udp ...sysDescrsysObjectIDsysUpTime......tcpRetransSegstcpConnTable...tcpConnEntrytcpConnState...mib-2systemsysDescrsysObjectIDsysUpTime...tcp...tcpConnEntrytcpConnState......tcpRetransSegs2. InteroperabilityAlexander KellerMTEAMNMFromthethreeapproachesforachievinginteroperabilitybetweenmanagementarchitectures,theQ-adapterfunctionapproachseems
todeliverthemostworkablesolutionasthemappingbetweenthedifferentarchitecturesisdoneatalimitednumberofpoints,namelym-referencepointsattheboundariesofthearchitecturaldomains.Furthermore,neithermanagingsystemsnormanagedsystemsneedtobemodified.ThepriceofthisflexibilityisthecomplexityoftheQAFasshallbedescribedbelow.
ThespecificationofalgorithmsusedfortheimplementationofQAFsisthegoalofaninitiativefromX/OpenandtheNetworkManagementForumcalledISO-InternetManagementCoexistence(IIMC).Itdevidesthetransformationprocessintwophases:ThefirststeppermitstherepresentationofmanagedobjectsdefinedinInternetSMI(StructureofManagementInformation)intheOSI/TMNinformationmodel[12].Thealgorithmisdescribedin[22];animplementationofthistransformationalgorithmhasbeendonebytheTelecommunicationsLaboratoryoftheTechnicalResearchCentreofFinlandandisavailablefromtheNetworkManagementForumFTPserver.Theimplementationisdocumentedin[26].
ThemappingoftheInternet-SMIconstructstoTMNmanagedobjectsisstraightforward:AttributegroupsandtablerowsbecomeMOCs,scalarvariablesaretranslatedintoattributesoftheappropriateMOC.
TheIIMCalgorithmhandlesnotonlythenamingandregistrationofmanagedobjectclassesbutalsotheregistrationoftheirnamebindingsthathelptobuildthecontainmenthierarchy.ThedistinguishednamesforMOCs,namebindingsandnamingattributesarebuiltbyappendingtheSNMP-OIDstoapredefinedprefix.Ontheotherhand,theuniquenessofthenamescannotbeguaranteed:TheMIB-II[20]containsagroupnamed\"system\"whiletheISO10165-2\"system\"classisdefinedastherootoftheOSIcontainmenthierarchy.WhiletranslatingMIB-II,\"system\"hastoberenamedtoe.g.\"internetSystem\"(seealsosection4.2).
Asaresultoftheinformationmodelmappingprocess,theformerSNMPMIBhasbeentransformedintoGDMO[13]andASN.1managedobjectdescriptions.
2.2TransformationStep2:MappingtheCommunicationModels
Mapping the Communication ModelsOSFq3 InterfaceCMIP-PDUsq3 InterfaceName mapping :MOC Instances OIDs of SNMP-MIBQ-AdapterService EmulationService mapping :M-GETM-SETM-CREATEM-DELETEM-CANCEL-GETSNMP-TRAPSNMP-GETSNMP-GET,SNMP-SETSNMP-SETSNMP-SET--M-EVENT-REPORTName mappingService mappingSNMP InterfaceSNMP-PDUsSNMP-StackSNMP AgentScoping, Filtering and Synchronisation2. InteroperabilityAlexander KellerMTEAMNMThesecondstepprovidesamechanismfortheexchangeofmanagementdatabetweenmanagedobjectsinthedifferentdomainsi.e.
themappingofCMISrequeststoSNMPPDUs.Theconceptsbehindthismechanismaredescribedindetailin[23]andwilljustbesketchedoutforthesakeofbrevity.ThemainaspectsofthecommunicationmodeltransformationaretheNameMappingandtheServiceMapping.
NamemappingdescribesthetaskofcomputingthecorrespondingSNMPObjectIdentifier(OID)fromagivennamespecifiedinaCMISrequestanddependingonthecontainmenthierarchy.ThisisnecessarybecausetheOSFhasobviouslynonotionofSNMPOIDs.
ServicemappingimpliesthetransformationofCMISservicesintoadequateSNMPPDUs.First,themanagedobjectstowhichanoperationapplieshavetobeidentified,i.e.thesetofinstanceslyinginthescopeoftherequesthavetobedetermined.Theseinstancesarethencheckedwhethertheirattributesmeetthefiltercriteria.TheobtainedsetofMOinstancesisthensubjecttotheoperationsaccordingtothefigureabove.
IncomingSNMPtrapsarereceivedbytheQAFandtransformedintoCMIPnotificationsissuedbythecorrespondingobjectinstance.CMISserviceslikeM-CREATEandM-DELETEcanbemappedinthecaseoftablestoSNMP-GETrequests:ThisisdonebymodifyingthecorrespondingRowStatusvariablesaccordingtotheconventionsoftheSNMPframework.TheM-CANCEL-getserviceistheonlyCMIS-operationthatcannotbemappedtoanappropriateSNMPcommand.
Bynow,itshouldhavebecomeclearthataQAFdoesnotonlyactasaconverterofprotocoldataunits;itisparticularlynecessarytoperformamappingbetweentheheterogeneousmanagementinformationmodels.Thismustbedoneforachievingcoexistenceandcooperationbetweenmanagementarchitectureswhiletheagentsremainsimple.Q-adapterfunctionsaredual-roleentities:Fromtheperspectiveofamanagingsystem,theyactasmanagedsystems;fromanagent’spointofview,theyappearasmanagingsystems.
2.3Puttingitalltogether:PropertiesofQ-AdapterFunctions;IIMCProxyManagementModel
Tasks of a Q-Adapter Function for SNMPg reference pointTMN Managing SystemQ-Adapter FunctionGDMOMIBInternetMIBSNMP Managed SystemManagedResourcesWSFf reference pointOSFGDMOMIBService Emulation(Scoping) (Filtering)(Operations)InternetMIBInternetAgentCMIS ServicesCMIPCMIPSNMPSNMP \"Services\"SNMPQ3 Interfacem reference pointMTEAMNM2. InteroperabilityAlexander KellerQ-adapterfunctionsallowingthemanagementofSNMPagentsfromaTMN-compliantmanagingsystemmustfulfillthefollowing
requirements:
1.Theagent’sSNMP-MIBshavetoberepresentedinthemanager’sinformationmodel(OSISMI).
2.Nomodificationsaretobeappliedtomanagingortomanagedsystems,i.e.acompletelytransparenttransitionbetweenthearchitecturesforallentitiesmustbeachieved.TheQ-adapterfunctionthereforehasthedutyofprovidingTMN-compliantproxyobjectsforanySNMPagentinthedomainsurveyedbytheQAF.3.OperationsissuedbytheOSF(Create,Delete,Get,Set)havetobeinterpretedbytheQAFandforwardedtothecorrespondingagent.Ontheotherhand,SNMPtrapsissuedbytheagentshavetobetransformedintoCMIPnotificationsandthenforwardedtotheOSF.Onemaywonderwhythemappingofonlytwomodels(namelytheinformationandcommunicationmodels)issufficientforourpurposesandwhyitisnotnecessarytoprovideatransitionbetweentheorganizationalandfunctionalmodelsalsodefinedin[14].Thereasonisthattheformermodelisroughlyidenticalforbotharchitectures;thelatter,incontrast,definesabroadrangeofmanagementfunctionalityfortheOSI/TMNdomainandhasnocounterpartinSNMPmanagement.
ThegoalistodeliverthestrengthsoftheOSI/TMNarchitecturetotheInternetmanagementarchitectureinordertoobtainacomprehensiveintegratedmanagementsolution.ThisimpliesthattheInternetarchitecture(havingnonotionofmanagementfunctionality)canbeusedwithmanagementservicesalreadydefinedintheOSI/TMNmanagementframework.AtypicalexampleforthisistheenhancementoftheInternetmanagementarchitecturewithmanagementfunctionalitylikethresholdmonitoringoreventprocessingdefinedbytheOSISystemsManagementFunctions.
3ToolsandArchitecture
3.1ToolEnvironment
Tool Environment: The IBM TMN ProductsNetView TMN Support Facility for AIX:TMN Management Platform (OSF + WSF) APIs for Management Application Development & Runtime EnvironmentGeneric Application Support for M.3100 and OMNIPoint 1 ModelsTMN WorkBench for AIX:Information Modeling Tools: MO Compiler, MO Browser and EditorAutomated Creation of Agent executableTool-based Generation of C++ Callbacks from GDMO descriptionsDeveloper completely shielded from CMIP invocations (CMIS/C++ API)3. ArchitectureAlexander KellerMTEAMNMForimplementingtheQAFaccordingtotheprinciplesoutlinedinsection2,wedecidedtousetheIBMTMNProducts([8],[4])as
thedevelopmentenvironment.Theyconsistoftwomaincomponents:
TheNetViewTMNSupportFacility[7]encompassesaTMNmanagementplatform(OSFandWSF)andAPIsfordevelopingTMNapplications.TheproductsupportsbothM.3100[1]andOMNIPoint[5]objectmodelsandprovidesallthenecessaryfeaturesformanagingOSI/TMNcompliantmanagementagents.
TheTMNWorkBenchforAIX[9]providesthewholedevelopmentenvironment.ItconsistsofinformationmodelingtoolslikeMOCbrowsersandeditorsbywhichnewMOCscanbederivedfromexistingonesbydrag-and-dropoperations.Forthispurpose,alargenumberofstandardizedMOCcataloguesisshippedinmachine-readableform.TMNcompliantagentsarebuiltbycompilingtheGDMOandASN.1definitionsoftherequiredMOCsintoC++classheaders.Thedeveloperthenonlyhasthedutyofimplementingthebehaviourofthemanagedobjectsbyfillingtheprovidedcallbackswithprogramcode.
ThemainadvantageoftheIBMTMNdevelopmentenvironmentliesinanewC++/CMIP-API([21],[2])whichisbeingstandardizedbytheNMForum:ThedeveloperiscompletelyshieldedfromthecomplexitiesofthemanagementprotocolandisabletoautomaticallygenerateC++interfacesfromGDMOmanagedobjectdescriptions.ItisevenpossibletoautomaticallygenerateanagentexecutabledirectlyfromGDMOandASN.1documentswhichalreadycontainsthestandardizedgenericbehaviourdescriptions.Thedeveloperhasthereforeonlytocopewiththeimplementationofthespecificbehaviour.In[19]asimilarapproachtoaQAFforSNMPbasedontheOSIMISmanagementplatform[24]isdescribed.
ThefollowingsectionswillexplaintheinfluenceoftheIBMTMNdevelopmentenvironmentonthedesignandimplementationofoursolution.OurexperienceswiththeIBMTMNproductsandoff-the-shelfCORBAtoolkitshaveshownthatthedevelopmentprocessofTMNagentsisverysimilartothewayCORBAmanagementagentsareimplemented.
3.2TheArchitectureoftheQ-AdapterFunction
Architecture of an SNMP Q-Adapter using the IBM TMN ProductsOSF/WSFManagement ApplicationMIBQ3Communication component (Postmaster)Q-Adapter FunctionORS-DatabaseInfrastructureInfratopNaming and ReplicationSNMP Managed DevicesDiscrLogrAgentMOIsmEventHandlerLogHandlerCore AgentResource AccessSNMP APIm3. ArchitectureAlexander KellerMTEAMNMByintroducingaQAFintothemanagementenvironment,anadditionalhierarchicallevelisinsertedbetweenthemanagingsystem
andthemanagedsystem.Recallfromsection1.1thatfromtheperspectiveofanOSF,aQAFisconsideredasanagent.Infact,thisisthereasonwhywewereabletouseaTMNagentdevelopmenttoolkit(seesection3.1)fortheimplementationoftheQ-adapter.TheOSFinteractswiththeQAFbymeansoftheQ3-interface;theQAFitselfisperceivedasmanagingsystembytheSNMPmanageddevicesandcommunicateswiththemthroughthem-interface(here:SNMP).AsobviouslynoSNMP-APIisshippedwiththeTMNdevelopmentenvironment,wehadtoencapsulateanalreadyexistingC-APIforSNMP(theucd-snmpAPI)inordertotriggerSNMP-PDUsintheC++callbacks.
Duringruntimetheagentexecutableconsistsoffourdistinctprocesses(shadedareasintheabovefigure):
TheInfratopprocessconsistsofthecomponentsInfrastructureandNamingandReplication.TheprocessiscrucialforthefunctionoftheQAFsinceitimplementsCMISEandACSE,maintainsthecontainmenthierarchyandchecksthenamebindingrestrictionsincaseofM-CREATEandM-DELETErequests.Furthermore,itprovidesthescopingandfilteringfunctionalitybyreplicatingtherequeststotheconcernedMOIs.
DiscristheeventhandlingcomponentwhichiscomplianttotheEventReportManagementFunction[10].LogrmaintainsthelogrecordsaccordingtotheLogControlFunction[11].
TheAgent,finally,containsthemanagedobjectinstances(MOI),thecoreagentandfacilitiesforresourceaccess.Itmaybeeithersingle-ormultithreaded.
4ImplementationIssues
4.1PerformingscopedandfilteredM-GEToperations
Capabilities: Scoping and FilteringTMN Managing SystemM-GET.response(MOC,MOI,Attr)(9)(9)(9)InfrastructureInfratopNamingandReplicationCMIP OperationsM-GET.response(Error)(3)(4)(2)M-GET.request(BMOC,Scope,Filter)(1)(5)LogrDiscr(5)(8)Core Agent(5)(6)SNMP Managed System(7)(7)(7)Q-Adapter Function4. Implementation IssuesAlexander KellerSNMP OperationsMTEAMNMInordertoclarifythecooperationofthedistributedmanagementenvironment,wewilldescribenowhowascopedandfiltered
M-GET.requestishandledbytheQAF.
1.TheOSFissuesthroughitsCMIS/ACSEstackascopedandfilteredM-GET.requestonaBaseManagedObjectClass(BMOC)oftheQAF.2.TheInfrastructurereceivesanM-GET.indicationandpassestheparameterstotheNamingandReplicationcomponent.3.Theinstancescontainedinthescopearedetermined.
4.IfthebaseMOIoftherequestisnotpresentinthecontainmenthierarchy,anM-GET.responsecontainingthenoSuchInstancemessageisreturnedtotheOSF.5.Ifthescopecanbedetermined,everyconcernedMOIinthecoreagentreceivesareplicaoftherequest.6.ThecoreagentlocatestheMOIandexecutestherequestontheMOI.
7.Thistriggersthecallbackmethodoftheaddressedattribute.ThecallbackmethoddeterminestheOIDandinvokesanSNMPGETrequestonthemanagedresourcethroughtheSNMPinterface.TheSNMPGETresponsereturnsthevalueoftheaddressedSNMPMIBvariable.8.TheCoreAgentreceivestheresultandforwardsittotheInfrastructure.
9.TheInfrastructuregeneratesanM-GET.responsemessagewithlinkedreplies.TheOSFreceivesthesereplies(M-GET.confirm)throughitsCMIS/ACSEprotocolstack.
4.2ContainmentHierarchy
MIB-II: The Containment Hierarchy4. Implementation IssuesAlexander KellerMTEAMNMWewillnowdescribehowauserinteractswiththeQAFandthecharacteristicsofourimplementation.
Atthecurrentstage,ourQAFprototypeisabletohandletwokindsofSNMPMIBs:Obviously,aQAFforSNMPmustsupport
MIB-II[20],thecommonMIBofallSNMP-capableresources.ThesecondMIB(\"lrz-unix\")hasbeendevelopedbyourresearchgroupandcoversthetypicaladministrationandmaintenancetasksofUNIXworkstations:Itallowsthedefinitionofusersandusergroupsandtheassignmentofquotasfordiskspaceandprintingfacilities.Furthermore,differentkindsofdevices(diskpartitions,filesystems,disks,tapesetc.)canbemanaged;itisalsopossibletocreateanddeleteprocesses.Theemphasisliesinhavingnotonlymonitoringcapabilities,butalsofacilitiesforissuingadministrativecommandsviaSNMP.
TherepresentationofthesetwoMIBsintheQAFsumsuptoroughly60MOCs;theseMOCscontaintogetherabout600attributes.Forthesakeofbrevity,thescreendumpshownabovedepictsonlytheMIB-IIpartofamanagedsystem(here:RelativeDistinguishedNameibmhegering1;inthecenterofthefigure)asitisperceivedbytheuserontheWSFconsole.OperationsontheseMOIsareissuedbydraggingtheiconofthedesiredMOIonaniconrepresentingthedesiredoperation(M-GET,M-SET,etc.)andbyenteringtheappropriateparametersintoapop-upmenu(definingthescopeandfiltersandthetypeofsynchronization).ThisisequivalenttothemechanismhowTMNobjectsaremanagedandrepresentedontheWSF,thereforeprovidingseamlessintegrationofSNMPmanagedobjectsintotheTMNenvironment.
Thesecondpartofinterestistheareawhichcontains3MOIs(\"CMIP/SNMP\"andbelow;ontherightsideofthefigure)thatallowtheconfigurationoftheQAFitselfduringruntimethroughthesamemechanismasdescribedabove.ManagementoftheQAFisnecessarybecauseourQAFimplementationperformsseveraltasksitselfsuchascachingoffrequentlyrequestedMIBattributes.ThroughtheseMOCs,auserhas,amongothers,thepossibilityofconfiguringthecachinglifetimeofattributesandtheirpollingintervals.Furthermore,itisalsopossibletoretrievethevaluesofseveralcountersgivinginformationonprotocolerrors.
4.3ExtendingtheQ-AdapterFunction
Integrating MIBs for new SNMP ResourcesSNMP Management AgentnewMIBIIMC AlgorithmUser-defined BehaviourASN.1GDMOCode ModulesSNMP Interfacem reference pointManaged Object Browser & EditorSNMP InterfaceExisting MOCsIBM TMN Workbench for AIXMetadataDatabaseCompilerLinkerNew MOCsCallbacksEnhanced Q-Adapterq3 reference pointManaged Object / Agent Composer4. Implementation IssuesAlexander KellerMTEAMNMGiventhelargenumberofdifferentSNMPMIBsthatarebeingdefined(e.g.HostresourcesMIB,HTTPMIB,Manager-to-Manager
MIBetc.)andtheamountofvendor-anddevice-specificMIBs,thesupportofonlytwoMIBsofcourseisnotsufficient:ItisthereforenecessarytohavetheopportunityofextendingtheQAFeasilybynewmanagedobjectdescriptions.
Thisisdoneasfollows:ThenewMIBhastobetranslatedbymeansofthecompileraccordingtotheIIMCalgorithmintoGDMOtemplatesandASN.1descriptions;eventually,thecreatednamebindingsandOIDshavetobeadaptedmanually:Afterthetranslation,allthegeneratednamebindingsbeingnecessaryforthecreationofthecontainmenthierarchyhavetheirsuperiorobjectclasssetto“system”.ForMOCshavingadifferentsuperiorMOC(thevastmajorityinourcase),thismustbechangedmanuallytotheappropriatevaluesinordersatisfythenamebindingconstraintsforinstatiatingtheMOCs.Thisrequiresknowledgeoftheunderlyinginformationmodels.Ifneeded,user-definedbehaviourcanbeadded.ThesefilesarethenenteredintotheIBMTMNWorkbenchbyprocessingthemwiththeManagedObjectBrowserandEditorwhichentersthenewdescriptionsintotheMetadataDatabase,acommonandarchitectureindependentrepositoryforMOCdescriptions.
Afterthishasbeendone,thenewMOCsareaddedtothealreadyexistingensemblebymeansoftheManagedObject/AgentComposer.Thistoolgeneratesthentheheadersofthecallbackmethodswhichhavetobefilledwiththeimplementationcode.InthecaseoftheQAF,thecallstotheSNMPAPIareentered.Finally,thegeneratedcodehastobecompiledandlinkedwiththealreadyexistingQAFcode.TheQAFisthenextendedtohandlealsothenewMIB.
TheflexibilityforintegratingdifferentkindsofSNMPcapableresourcesandtheachievedeaseofuseforapplyingcomplexandpowerfuloperationshaveacertainpriceintermsofmanpowerandsystemresourcesneeded:Ittookaboutoneman-yeartodesignandimplementtheprototype.TheexecutablecodesizeisroughlyfiveMegabytesifUNIXsharedlibrariesareused;thestand-aloneversionoftheQAFhasasizeof40Megabytes.ThecompiletimefortheQAFisabout60minutesonanIBMRS/6000workstationmodel3BT(7030)equippedwith128MBofRAM.Thedevelopmentenvironmentrequires250MBofdiskspace.
5ConclusionandFutureWork
Conclusion and Outlook\"Single Architecture Image\": SNMP-Resources perceived as TMN Managed ObjectsComplete OSI/TMN Functionality (Scoping, Filtering etc.) for SNMP-ResourcesFirst set of capabilities for managing the Q-Adapter available (Polling Intervals etc.)Further research:Dynamic Integration of new SNMP-MIBsDefinition of a MIB for managing the Q-Adapter5. ConclusionAlexander KellerMTEAMNMThispresentationhasdescribedaresearchprojectdealingwiththedesignandimplementationofaQ-adapterfunctionforthe
integrationofexistingSNMPresourcesintoaTMNenvironment.Fromtheperspectiveofthemanagingsystem,theseresourcesappearasOSI/TMNmanagedobjects;therefore,thewholerangeofOSI/TMNfunctionalityandfeaturesmaybeappliedtothem.Thisincludesscoping,filteringandsynchronization;itisalsopossibletodelegateeventhandlingandloggingtaskstotheQAFbydefiningEventForwardingDiscriminatorsandLogRecords.Furthermore,weimplementedafirstsetofmanagedobjectsallowingtomanagetheQAFitselffromtheOSF:Thisincludes,amongother,thesettingofresource-specificpollingprofiles.Althoughwewereabletobaseourdevelopmentonasoundfundament(namelytheIIMCconceptsandthepowerfulIBMTMNdevelopmentenvironmentthatshieldscompletelythecomplexityofCMIP),weexperiencedthatthedesignandimplementationofaQ-adapterfunctionforSNMParefarfrombeingtrivial:
ThecompilerbasedontheIIMCalgorithm(describedinsection2.1)doesaverygoodtranslationjobbutcan,atitscurrentstage,onlyhandleSNMPv1managedobjectdescriptions.Theincorrectgenerationofnamebindingsandobjectidentifiers(sketchedoutinsection4.3)requiressomeadditionalwork.
OurexperienceswiththeIBMTMNdevelopmenttoolsethavebeendescribedinsection4andcanbesummarizedasfollows:ApartfromthelargecompiletimesandtheconsiderablecodesizeoftheQAF,theexperienceswiththisdevelopmentenvironmentweregoodalthoughsomedeepunderstandingofOSISMIisrequired.
StepsforfurtherresearchincludetheenhancementoftheQAFinawaythatitssetofMOCscanbeextendedduringruntime;currently,theQAFneedstoberecompiledifanewSNMPMIBistobeadded.AnotherissueisthemanageabilityoftheQAFitself;weareworkingonthedefinitionandimplementationofaQ-adapterMIBallowingtolookupandmodifythepropertiesoftheQAF.Theexperiencesobtainedinthisprojectarebeingsuccessfullyreusedinafollow-onresearchprojectdealingwiththeintegrationofSNMPresourcesinCORBA.Thisprototypeiscurrentlyunderdevelopment.
Acknowledgements
TheauthorwishestothankthemembersoftheMunichNetworkManagement(MNM)Teamforhelpfuldiscussionsandvaluablecommentsonpreviousversionsofthepaper.TheMNMTeamdirectedbyProf.Dr.Heinz-GerdHegeringisagroupofresearchersoftheUniversityofMunich,theMunichUniversityofTechnology,andtheLeibnizSupercomputingCenteroftheBavarianAcademyofSciences.
References
[1]GenericNetworkInformationModel.RecommendationM.3100,CCITT,June1992.
[2]TomR.Chatt,MichaelA.Curry,JuhaSepp¨a,andUlfHollberg.TMN/C++:Anobject-orientedAPIforGDMO,CMIS,andASN.1.InLazaretal.[17],pages
177–191.[3]RobertaCohen.TheTelecommunicationsManagementNetwork(TMN),chapter9,pages217–242.InSloman[27],June1994.
[4]M.Feridun,L.Heusler,andR.Nielsen.ImplementingOSIAgentsforTMN.IBMResearchReportRZ2759,IBMResearchDivision,ZurichResearch
Laboratory,1995.[5]NetworkManagementForum,editor.DiscoveringOMNIPoint-ACommonApproachtotheIntegratedManagementofNetworkedInformationSystems.Prentice
Hall,1993.[6]S.Heilbronner,A.Keller,andB.Neumair.IntegriertesNetz-undSystemmanagementmitmodularenAgenten.InC.Cap,editor,ProceedingsofSIWORK’96:
WorkstationsundihreAnwendungen,pages275–286,Zurich,Switzerland,May1996.vdfHochschulverlagAGanderETHZ¨urich.ISBN3-7281-2342-0.[7]IBMCorporation,ResearchTrianglePark,NC27709-2195.IBMNetViewTMNSupportFacilityforAIXRelease2:User’sGuide,March1996.OrderNumber:SC31-8017-01.[8]IBMCorporation,ResearchTrianglePark,NC27709-2195.IBMTMNProductsforAIXRelease2:GeneralInformation,release2edition,March1996.Order
Number:GC31-8016-01.[9]IBMCorporation,ResearchTrianglePark,NC27709-2195.IBMTMNWorkBenchforAIXRelease2:ManagedObject/AgentComposerUser’sand
Programmer’sGuide,March1996.OrderNumber:SC31-8006-01.[10]InformationTechnology–OpenSystemsInterconnection–SystemsManagement–Part5:EventReportManagementFunction.IS10164-5,ISO/IEC,June
1993.[11]InformationTechnology–OpenSystemsInterconnection–SystemsManagement–Part6:LogControlFunction.IS10164-6,ISO/IEC,June1991.
[12]InformationTechnology–OpenSystemsInterconnection–StructureofManagementInformation–Part2:DefinitionofManagementInformation.IS10165-2,
ISO/IEC,September1991.[13]InformationTechnology–OpenSystemsInterconnection–StructureofManagementInformation–Part4:GuidelinesfortheDefinitionofManagedObjects.
IS10165-4,ISO/IEC,August1991.[14]InformationProcessingSystems–OpenSystemsInterconnection–BasicReferenceModel–Part4:ManagementFramework.IS7498-4,ISO/IEC,November
1989.[15]PramodKalyanasundaramandAdarshpalSethi.InteroperabilityIssuesinHeterogeneousNetworkManagement.InManuMalek,editor,JournalofNetwork
andSystemsManagement,volume2,pages169–193.PlenumPublishingCorporation,June1994.[16]M.Langer.EntwurfundImplementierungeinesCMIP/SNMPGateways.Master’sthesis,TechnischeUniversit¨atM¨unchen,November1996.
[17]AurelA.Lazar,RobertoSaracco,andRolfStadler,editors.Proceedingsofthe5thIFIP/IEEEInternationalSymposiumonIntegratedNetworkManagement,
SanDiego.IFIP,ChapmanandHall,May1997.[18]S.Mazumdar,S.Brady,andD.Levine.DesignofProtocolIndependentManagementAgenttoSupportSNMPandCMIPQueries.InProceedingsofthe3rd
IFIP/IEEEInternationalSymposiumonIntegratedNetworkManagement.North-Holland,April1993.[19]KevinMcCarthy,GeorgePavlou,SaleemN.Bhatti,andJoseNeumandeSouza.ExploitingthepowerofOSIManagementforthecontrolofSNMP-capable
resourcesusinggenericapplicationlevelgateways.InRaynaudetal.[25],pages440–453.[20]KeithMcCloghrieandMarshallT.Rose.ManagementInformationBaseforNetworkManagementofTCP/IP-basedInternets:MIB-II.RFC1213,IAB,March
1991.[21]TMNC++ApplicationProgrammingInterface.Issue1.0,draft5-forpubliccomment,NetworkManagementForum,January1996.[22]TranslationofInternetMIBstoOSI/CCITTGDMOMIBs.NMF026,NetworkManagementForum,1993.[23]ISO/CCITTtoInternetManagementProxy.NMF028,NetworkManagementForum,1993.
[24]GeorgePavlou,KevinMcCarthy,SaleemN.Bhatti,andGrahamKnight.TheOSIMISPlatform:MakingOSIManagementSimple.InRaynaudetal.[25].[25]YvesRaynaud,AdarshpalSethi,andFabienneFaure-Vincent,editors.Proceedingsofthe4thInternationalSymposiumonIntegratedNetworkManagement,
SantaBarbara.IFIP,ChapmanandHall,May1995.[26]J.Reilly.VTTIIMCNotes-ModificationtoSMICSNMPMIBCompilertoproduceGDMOMIBDefinitons.Technicalreport,TechnicalResearchCentreof
Finland,TelecommunicationsLaboratory(VTT/TEL),May1993.[27]MorrisSloman,editor.NetworkandDistributedSystemsManagement.Addison-Wesley,June1994.
因篇幅问题不能全部显示，请点此查看更多更全内容