SNMP-Based Multicast Reachability Monitoring Framework, CTI.

cation Review,18(4):314–329,August1988.[19]D.Levi and J.Schoenwaelder.Definitions of Managed Objects forScheduling Management Operations,RFC2591.Technical report, IETF,May1999.[20]D.Makofske and K.Almeroth.MHealth:A real-time graphical multicastmonitoring tool for the MBone.In Workshop on Network and Oper-ating System Support for Digita Audio and Video.NOSSDA V,June 1999.[21]Perl 5.005SNMP Package.Technical report,SwissAcademic and Research Network(SWITCH), http://www.switch.ch/misc/leinen/snmp/perl/.[22]M.Rose and K.McCloghrie.Structure and Identification of ManagementInformation for TCP/IP-based Int ernets,RFC1155.Technical report, IETF,May1990.[23]M.Rose and K.McCloghrie.Concise MIB Definitions,RFC1212.Tech-nical report,IETF,March1991.[24]J.Schnwlder and J.Quittek.Script MIB Extensibility Protocol Version1.0.,RFC2593.Technical report,IETF,May1999.[25]H.Schulzrinne,S.Casner,R.Frederick,and V.Jacobson.RTP:A Trans-port Protocol for Real-Time Applications.Technical report,IETF, July2001.[26]J.Walz and B.N.Levine.A Hierarchical Multicast Monitoring Scheme.In2nd InternationalWorkshop on Networked Group Communication, November2000.REFERENCES[1]SNMPv3IETF WG Mailing List,snmpv3@,June2001.[2]AdventNet API for SNMP Development.Technical report,AdventNet,/products/snmp/index.html.[3]Ehab Al-Shaer.Active Management Framework for Distributed Mul-timedia Systems.Journalof Network and Systems Management (JNSM),8(1),March2000.[4]Ehab Al-Shaer.A Dynamic Group Management for Scalable DistributedEvent Correlation.In IEEE/IFIP Integrated Management(IM’2001), May2001.[5]Ehab Al-Shaer,Hussein Abdel-Wahab,and Kurt Maly.HiFi:A NewMonitoring Architecture for Distributed System Management.In Pro-ceedings of InternationalConference on Distributed Computing Sys-tems(ICDCS’99),pages171–178,Austin,TX,May1999.[6]Ehab Al-Shaer and Yongning Tang.Toward Integrating IP Multicastingin Internet Nework Management Protocols.Journalof Computer and Communications Review,24(5):473–485,December2000.[7]Ehab Al-Shaer and Yongning Tang.Design and Implementation ofSNMP-Based Multicast Reachability Monitoring Framework,CTI.Technical report,School of Computer Science,Telecommunicaitons and Information Systems,DePaul University,August2001.[8]K.Almeroth.Managing IP multicast traffic:Afirst look at the issues,tools and challenges.Technical report,IP Multicast InitiativeSummit, September1998.[9]K.Almeroth.The Evolution of Multicast:From the MBone to Inter-domain Multicast to Internet2Deployment.IEEE Network,Jan2000.[10]K.Almeroth and L.Wei.Justification for and use of themulticast rout-ing monitor(MRM)protocol.Technical report,IETF InternetDraft, February1999.[11]K.Almeroth,L.Wei,and D.Farinacci.Multicast Reachability Monitor(MRM),Internet Engineering Task Force Internet Draft.Technical report,IETF,October1999.[12]D.Bacher,A.Swan,and L.Rowe.rtpmon:A third-party RTCP mon-itor.ACM Multimedia’96,pages437–438,November1996.[13]J.Case,M.Fedor,M.Schoffstall,and J.Davin.Simple Network Man-agement Protocol,RFC1157.Technical report,IETF,May1990. [14]S.E.Deering and D.Cheriton.Multicast routing in internetworks andextended lans.ACM Transactions on Computer Systems,8(2):85–110, May1990.[15]C.Diot,B.Levine,B.Lyles,H.Kassem,and D.Balensiefen.DeploymentIssues for the IP Multicast Service and Architecture.IEEE Networks SpecialIssue on Mul ticast,January2000.[16]W.Fenner and S.Casner.A”traceroute”facility for ip multicast,ietfinternet draft.Technical report,March2000.[17]M.Handley.Sdr:Session Directory Tool,Technique Report.Technicalreport,University College London,March1995.[18]V Jacobson.Congestion Avoidance and puter Communi-approach is its requirement of deploying new HPMM agents in routers and local domains,limits the deployment of this approach significantly.HPMM uses only passive monitoring for fault isolation.Although passive monitoring has the minimum intrusiveness,active monitoring is important for detecting and isolating network problems.As HPMM is strictly a fault management tool,monitoring other network parameters such as delay and jitter is not currently supported in HPMM.Andfinally the use of unicast in the agent communication increases the maintenance cost associated with the hierarchy which makes it less practical[4].Unlike previous work,SMRM utilizes the existing management infrastruc-ture of SNMP agents and requires no changes in network.The SNMP agent software is widely acceptable as a mature ers/vendors are always reluctant todeplo y new daemo ns that might intro duce reliability and security problems.In addition,SMRM provides a broader monitoring scope that includes observing delay and jitter which are important for QoS man-agement of multicast networks.6.CONCLUSIONMulticast is a network service for providing scalable group communication in the Internet.With the constant evolution of multicast routing,fromflat MBone to hierarchical routing multicast in Internet2[9],multicasting be-comes more widely deployed and more complex as well.Multicast monitoring is necessary not only for debugging and fault detection,but also for measur-ing the quality of multicast reachability to the group members.This paper presents an easy-to-use easy-to-deploy framework for multicast reachability monitoring called SMRM.SMRM is an active monitoring tool that injects a specified multicast stream between sender(s)and receiver(s)and reports at real-time the QoS parameters such as loss,delay and jitter of the network paths.Unlike previous work,SMRM is thefirst active monitoring framework that utilizes the existing SNMP infrastructure and requires nochanges in the network.For SMRM deployment,simple extensions to SNMP agents and MIB are required.Among the most important features for SMRM is the scalability to large number of groups and agents,extensibility via dynamic MIB scripts which allow developers to deploy their own multicast management scripts, providing on-line and postmortem monitoring analysis,allowing for the se-lection of traffic characteristics,and incurring minimal operational overhead. Our experiments with the prototype implementation of SMRM shows that the overhead of SMRM ping-pong technique is very comparable with tracer-oute and the impact of the message payload is negligible[7].Nevertheless, we consider SMRM is a basic component toward supporting a comprehensive multicast management solution,which includes fault detection and isolation, event correlation for performance and security management,QoS monitoring, and SLA(Service Level Agreement)management in enterprise networks.Our research agenda alsoincludes integrating IP multicast in SNMPv3,develo p-ing IP routing topology discovery,monitoring pre-existing multicast sessions, enhancing the delay monitoring scheme,and providing self-synchronization scheme.from multicast receivers.Mrinfo is another tool used to give the status of a multicast router such as active multicast tunnels and interfaces.A very useful comprehensive survey of similar tools is presented in[8].Many of these tools suffer the following limitations:(1)they are too re-stricted in their functionality to support an extensible framework that can monitor other aspects of multicast networks such as reachability and perfor-mance problem,(2)they require special support in the network,like mtrace, or they are restricted on RTP or SDR applications,like Mhealth and sdr-monitor,and(3)they don’t not scale with large multicast groups due to the reply implosion problem.Multicast Monitoring Frameworks.These systems tend to offer a broader solution for multicast monitoring.The Mmon application in HP Openview is thefirst attempt to provide a complete framework for multicast management. It provides an automatic discovery of tree topology and multicast-capable routers,a query service to investigate the status of multicast routers,paths and traffic information through a GUI.This allows operators to identify and isolate faults as they occur in the network.Mmon uses SNMP to gather the information from various MIBs such as IGMP MIB,PIM MIB,CBT MIB, IPMROUTE MIB.The main limitations of mmon approach are:(1)it suffers a scalability problem due to SNMP unicast communication[6],(2)the lack of active monitoring to enable injecting and monitoring multicast traffic at any selected points in the network for fault diagnoses and isolation,(3)lack of supporting inter-domain multicast management.Other approaches use proprietary protocols(instead of SNMP)to address the previous limitations.The Multicast Reachability Monitor or MRM[10,11] is thefirst framework that introduces a new protocol for multicast reachabil-ity monitoring.MRM uses active monitoring in which a multicast traffic is originated by a delegated sender(called TS)to multicast receivers(called TR) which continuously collect statistics and send status reports to the manager. Although MRM is a step forward toward efficient multicast monitoring,its deployment will be limited because of using a proprietary protocol and special agents.It is also not clear from[11]how the delay and jitter are calculated when no clock synchronization is supported between sender and receivers. In addition,MRM framework lacks many of theflexibility and extensibility features of SMRM such as providing on-line and postmortem analysis,differ-ent traffic distributions and the ability to download dynamically new man-agement scripts in the monitoring agents.A Hierarchical Passive Multicast Monitor(HPMM)is another recent proposal[26]that uses a proprietary pro-tocol for faults detection and isolation in multicast networks.Unlike MRM, HPMM use passive monitoring agents that communicate with each other us-ing unicast.The HPMM agents are organized in a hierarchy according to their locations from the multicast sender.Monitoring reports are collected and cor-related in a hierarchy fashion to provide a large-scale monitoring architecture. The idea of hierarchical monitoring andfiltering was well investigated in many other monitoring systems such as HiFi system[3,5].Nevertheless,the HPMM presents an interesting hierarchy setup protocol that overlays the actual mul-ticast tree to build an efficient hierarchy of agents.The main drawback of thisTesters.This function is useful for debugging,and verification purposes.This Figure alsosho ws the delay and jitter o f the same receivers at real-time.4.2.SMRM Agent andManager ImplementationWefirst extended the MIB II module to include mcastInfo and smrmMIB group under enterprises group[23].We use(1)the implementation of net-snmp agent package4.2(previously known as UCD-snmp)from University of California at Davis()as case study for developing this framework,(2)the implementation of schedMIB,schedule-mib-0.5[19], and(3)Perl5SNMP module supported by Swiss Academic and Research Net-work[21].We use the Perl5SNMP package to create the script(smrmScript) launched by the schedule MIB.This package is completely stand-alone and portable to many platforms.Other implementations of SNMP agent can be used similarly.Three steps are required toimplement SMRM agents and manager:1.Incorporating the multicast functionality and mcastInfoMIB in SNMP agentand manager as described in Section2.2.2.Integrating the SMRM-specific MIBs:schedMIB,and smrmMIB,which aredescribed in 2.3..3.Integrating the SMRM management GUI described in Section4.1.The SMRM manager is a JA V A-based program developed using AdventNet SNMP API Release3.2package[2].It also incorporates the multicast func-tionality and the SMRM-specific MIBs.The SMRM manager is developed based on SNMPv1and the usability of SNMPv3is work-in-progress.5.RELATED WORKWith the deployment of multicast services in global networks,many research proposals,experiments and tools were developed for monitoring multicast net-works and operations.However,only few of them consider multicast monitor-ing solutions that are scalable,easy-to-use and easy-to-deploy.In this survey, we classified the related work into two categories:Multicast Monitoring Tools.Most of this work was inspired by the de-ployment effort of multicasting,which requires tools for debug and diagnose the network problems.One of the most useful tools in this category is mtrace which discovers the routers in the reverse multicast path from a given re-ceiver to the source of a multicast group[16].It also gives simple statistics of the discovered path such as packet loss and delay.Mtrace requires a special support in routers in order to collect this information.Other tools,like sdr-monitor[17],MHealth[20]and RTPmon[12],observe the global reachability of sdr and RTP multicast messages to group members by collecting feedbackFigure3SMRM View Interfacethe session ID is selected,the interface shows the associated senders and re-ceivers.Notice that the sender IP is needed because multiple senders may exist in the one session.The Polling Interval parameter is todetermine ho w frequently the manager should do the polling This parameter is particularly important to control the information freshness and the monitoring intrusive-ness trade-off.The loss ratio,delay and jitter charts show the total percentage of packet loss,average delay and average jitter,respectively,after each polling ers can switch charts of different sessions back-and-forth dynami-cally without re-activating sessions.Figure3shows that the receiver of ID11 suffers lost of reachability problems compared with other receivers in the this session,mboneSdrTest.In fact,this receiver was unreachable between80and 120minutes after the beginning of the sessionSMRM MIB Browser:The SMRM user interface provides a standard MIB browser which enables managers to view the MIB objects values of the SMRMconfigurations of a previous SMRM session can be used in creating a newsession.A manager can initiate multiple SMRM monitoring sessions simulta-neously on the same network.For each SMRM session,users must configure the Session,Traffic and Agents parameters shown in Figure2as follows:•Session Parameters–Users have todefine the multicast gro up tobe mo ni-tored using Group Address and Group Port in the create session interface.The Session Period defines the length of the testing session in seconds (Time Interval)o r in number o f bytes(TotalBytes)as shown in Figure2.In other words,the user might choose to run an smrm session for3hours, for example,or for the time it takes to send a bulk traffic of100MBytes.The SMRM testers provide information about three monitoring objects: packet loss,latency and jitter which are major attributes for determin-ing the Quality of Service(QoS)for multicast networks.An SMRM session must be assigned a unique name in the(Session ID)parameter.The SMRM receivers use<smrmSessID,smrmSourceIP,smrmPktSeq>tuple included in the Set requests touniquely identify multicast traffic generated by dif-ferent senders in SMRM sessions.•Traffic Parameters Configuration–This configuration section is to shape the outgoing multicast traffic according to specific parameters such as the sending rate,packet length,traffic distribution(e.g.,uniform,Passion, Pareto),and when to start sending this traffic(Starting Time and StartingDate).•Agents Configuration–We assume that NOC perso nnel whointend touse SMRM know the topology or at least the end-point nodes of the network under testing.This is important to determine the network segments under test/ers can specify this by listing the IP addresses of the sender(s)and the receivers in the SMRM session.The SMRM receivers can be configured to use on-line monitoring or postmortem analysis in smrm sessions.This feature is important to accommodate a wide range of moni-toring requirements and network environments as described in Section2.1..The user can enable implosion control to prevent reply explosion in the manager when large number of agents exist in the session.The user can also select the NTP(Network Time Protocol)option to enable delay cal-culation based on the sending/receiving timestamp.Otherwise,ping-pong techniques is used tomeasure the delay as described befo re.When the SMRM session configuration is completed,the manager can ini-tiate a session by activating it(Activate Session in Figure2).This causes the manager to contact and configure the SNMP/SMRM agents of the IP addresses in this session.SMRM View Session:The view interface(Figure3)allows managers to retrieve and present the monitoring results of various SMRM sessions from different agents.The interface contains of four graphs that show real-time charts of the monitoring targets over time.Each graph area is to plot one of the monitoring targets(packet loss,delay or jitter)for a specific tree path defined by the Session ID,Sender IP and a group of Selected Receivers.OnceFigure2SMRM Create Interface4.SMRM FRAMEWORK IMPLEMENTATIONThis sections describes the implementation of the SMRM components:user interface,manager,and agents(testers).It also explains the various options and parameters of SMRM sessions.4.1.SMRM User InterfaceThe SMRM user interface is part of the manager functionality.The SMRM interface has two main functions:(1)enabling users to create one or more SMRM monitoring sessions and configuring remote SMRM agents,and(2) allowing users to collect and view the reachability monitoring results in real-time or postmortem basis.that includes four main operations and an exist button.The SMRM user interface is Java-based and is integrated in the SNMP manager developed using AdventNet[2].In the following sections,we describe the steps and the interfaces used for launching SMRM sessions.Creating or Loading SMRM Session:When a reachability monitoring test is to be conducted,the NOC manager creates a new SMRM session us-ing the interface in Figure2to define the SMRM agents configurations.Theusing the sending and receiving time stamps.This is an accurate and simple technique but it requires synchronizing the sender and receiver clocks using NTP or other protocols.However,this solution is not feasible if network nodes do not support NTP.Therefore,we propose the“ping-pong”technique that uses schedMIB and MIB scripts tomake the sender and the receivers sending ping-pong SNMP Set requests to each other.Simply,the schedMIB of an SMRM sender initiates a Set request that includes the sender timestamp as an OID toset smrmCurrentSendTS vari-able in the receiver MIB.As a result,this triggers a script in the receiver that sends back a Set request that includes the original sender timestamp, smrmCurrentSendTS,and sequence number,smrmCurrentSeq.The last one is used to identify out of order messages.Thus,when the SMRM sender receives the Set request from the receiver,it calculates M(Round Trip Time or RTT), as follows:M=CurrentT ime−smrmSenderTS.Then,M is used toco ntin-uously calculate the smoothed RTT average(L)according to this formula[18]:L=α∗L+(1−α)∗Mwhere M is the measured RTT andαis a smoothing factor with recom-mended value of0.9.Since the returning Set request from the receiver to the sender may not traverse the same outgoing multicast path,the calculated de-lay may not be as accurate as in thefirst technique.However,the user has the option to use thefirst technique if NTP is supported in the network.Oth-erwise the“ping-pong”technique is used for monitoring the delay.Jitter Calculation.The inter-arrival jitter(J)is defined tobe the mean deviation(smoothed absolute value)of the difference D in packet spacing at the receiver compared to the sender for a pair of packets.The traffic that the sender sends tomeasure the delay is alsoused by agents tomeasure the jitter. We use the RTP jitter calculation described in[25].Therefore,assuming S i is the sender timestamp from set request(or packet)i,and R i is the time of arrival in timestamp units for Set request i,then for the two requests i and j,D may be expressed asD(i,j)=(R j−R i)−(S j−S i)=(R j−S j)−(R i−S i)SMRM receivers calculate the inter-arrival jitter continuously as each set request i is received from source using the difference D for that packet and the previous packet i−1in order of arrival(not necessarily in sequence)and according to the following formula:J i=J i−1+(|D(i−1,i)|−J i−1)/16This algorithm is the optimalfirst-order estimator and the gain parameter 1/16gives a good noise reduction ratio while maintaining a reasonable rate of convergence[25].A sample implementation is also shown in[25].2.4.Schedule MIB Application in SMRMThe Schedule-MIB[19]allows to schedule simple SNMP Set operations onthe local SNMP agent in a regular basis or at specific future points in time.In conjunction with the Script-MIB this allows to launch short-time scriptsat regular intervals or to start and terminate scripts on scheduled points in ing the schedule MIB,the manager can schedule SMRM test sessionin three different ways:(1)periodic,in which case the SMRM senders will pe-riodically trigger the SMRM script that sends Set requests to a specified mul-ticast group,(2)one-shot,in which case the SMRM sender triggers the SMRM script one time;(3)calendar-based,in which case the SMRM script will be scheduled according to specified time and date.The smrmSessLaunchButtonin smrmMIB is the script-trigger object that the schedMIB sets in order to launch smrmScript.The schedMIB functionality can be integrated in SMRM managers or the senders.However,we choose to integrate schedMIB in SMRM senders for scalability purpose as the session manager might get involved into too many SMRM sessions.3.SMRM MONITORING TARGETS CALCULATIONSThis section describes the calculation process of packet loss,delay and jitteras performed by the agents during on-line monitoring mode.Packet Loss Calculation.When an SMRM agent receives a multicast Set request,it increments smrmRecvNumOfPkts value and updates the smrmCurrentSeq with the new sequence number if the new one is larger thanthe the current sequence number.Then,the value of smrmLostPktsNum is setto smrmCurrentSeq−smrmRecvNumOfPkts.And the loss ratio,smrmPktLossRatio, is calculated as smrmLostPktsNum/smrmCurrentSeq.The manager retrieves and plots the accumulative loss ratio in a graph interface frequently and basedon a polling interval(see Section4.1.).However,the manager updates the loss ratiograph o nly if the smrmRecvNumOfPkts or smrmCurrentRecvTS has been incremented in the TR since the last retrieval.Otherwise,if nopackets is received during this polling period,a specialflag is marked in the graph to indicate that this receiver-path is currently unreachable.An example o f an ac-cumulative graph is shown in Figure3.Notice that the minimum polling timeof the manager is1second which is significantly larger than the minimum packet inter-arrival time.In order to calculate the loss ratio for each individual polling interval separately(dispersed graph),the manager must set smrmLostPktsNum and smrmRecvNumOfPkts in the agents’MIB tozeroevery time the lo ss ratioin-formation is retrieved.Similar to the cumulative calculation,if the smrmRecvNumOfPkts remains unchanged(zero),the graph will indicate the network path unreachability.Delay Calculation.There are twometho ds tomeasure the delay fro m a sender toreceivers in the multicast delivery tree.Thefirst technique is byfor a session ID,smrmSourceIP for the sender IP address,smrmPktSeq forthe packet sequence number,smrmPktSenderTS the sender timestamp andsmrmPktLen for the packet length(see Figure1).In order to make the Set re-quest packet size matching the smrmPktLen,a dummy OID smrmDummyTrafficof Octet syntax is included in the variable binding along with the OIDslisted above.The SMRM sender increments the value of smrmPktSeq and smrmPktSenderTS objects each time a new set request is sent out.This class of objects is used exclusively by SMRM receivers to store the OID values of the set requests in multicast traffic.Notice that Set requests are sent as a multicast messages to the agents’groups as described in Section2.2..When the agent inserts smrmPktSenderTS object in smrmMIB,it automatically set the current time in the smrmPktRecvTS object.This information is recorded in such objects only if the postmortem moni-toring mode is selected by the manager,which retrieves these objects from theagents,after the session ends,to calculate the packet loss,delay and jitter. The calculation of the monitoring targets is described in the following sec-tion.Notice that the smrmSessID,smrmSourceIP and smrmPktSeq represent the indices for this table.The objects in this class have a read-only access type.SMRM Receive Report Objects.This class is also used by SMRM re-ceivers to store the target monitoring information,the number of packet loss (smrmLostPktsNum),and the traffic jitter(smrmJitter).This class is used by agents if the on-line monitoring is selected.In this case.the agent uses the traffic information OID values in the multicast Set requests generated by the sender to continuously calculate the monitoring targets.Therefore, managers can retrieve the monitoring targets information(using SNMP get requests)at real-time if on-line monitoring mode is used.This class contains also other objects that reports the total number of bytes and packets received so far and the ratio of number of lost packets over number of received packets (smrmPktLossRatio).The smrmCurrentSeq smrmCurrentSendTS, smrmCurrentRecvTS,and smrmCurrentJitter are objects used locally by agents to calculate the monitoring targets as described in the Section3.. Both smrmSessID and smrmSourceIP objects are the index for entries of this smrmRecvReportTable.The objects in this class have read-only access ex-cept smrmRecvNumOfPkt and smrmLostPktsNum which have read-write access as they can be set by managers to adjust the monitoring analysis/calculation as described in Section3..SMRM Sender Report Objects.This class is alsoused by SMRM senders to store the delay monitoring information,the maximum transmission de-lay(smrmMaxDelay),and the average transmission delay(smrmAvgDelay)fo r on-line monitoring.The variable smrmCurrentDelay is used tosto re the in-termediate delay values for calculating the smooth average as described in Section3..Both objects smrmSessID and smrmRecvIP which is the IP of re-ceiver agents are used as the indices for entries in the smrmSendReportTable. The objects in this class have read-only access.Figure1smrmMIB Group in Extended MIB II.by receivers only.Thefirst one indicates,if it is set to TRUE,that SMRM receivers must use a randomized timer before sending the SNMP reply to the manager.This technique is used to avoid reply implosion in the man-ager and provide scalable monitoring.The second object defines the report-ing/monitoring mode,on-line or postmortem,as described in Section2.1..The third object indicates which of the reachability the attributes(packet loss,de-lay and jitter)are to be monitored by this agent.Managers may task agents in an SMRM session with different monitoring targets as multicast paths may encounter different kinds of problems.The value of smrmMonTargets ranges from0to7which indicate all targets combinations as0means no requested target(postmortem analysis)and7means all targets(packet loss delay and jitter).This object is important to limit the monitoring processing overhead in the agent.Notice that the smrmSessID and smrmSourceIP are both the in-dices for entries of this table.This means a sender might participate in more than one SMRM session with different parameters.The objects in this class have read-write access type.SMRM Traffic Information Objects.The multicast traffic originated by the SMRM senders is actually a sequence of Set-request packets where each one contains the following OIDs to be set in the agent smrmMIB:smrmSessID。