IP Multicast Simulation in OPNET

Transcription

1 IP Multicast Simulation in OPNET Xin Wang, Chien-Ming Yu, Henning Schulzinne Paul A. Stipe Columbia Univesity Reutes Depatment of Compute Science 88 Pakway Dive South New Yok, New Yok Hauppuage, New Yok ABSTRACT IP multicast is an emeging wide aea netwok technology that povides the capability fo efficient infomation dissemination fom sendes to potentially lage sets of eceives. IP multicast distibution tees o pathways ae enabled via a combination of the LANbased Intenet Goup Management Potocol (IGMP) woking in concet with multicast outing potocols. The financial industy is beginning to utilize IP multicast as a delivey mechanism fo nea eal-time infomation dissemination. Howeve, financial sevices typically have stingent availability equiements. Theefoe, the failue ecovey chaacteistics of IP multicast ae of inteest to investigate. In this pape, we epot on the simulation design of the Potocol Independent Multicast Dense Mode (PIM DM) multicast outing model, the IGMP goup management model, and othe models fo OPNET. Futhemoe, the modifications equied to seveal OPNET IP models to suppot multicast ae detailed. The simulation was used to investigate the failue ecovey chaacteistics of IP multicast. INTRODUCTION Thee has been much discussion about the use of IP multicast technology fo efficient infomation dissemination. IP Multicast enables a netwok to send messages to a goup of anonymous eceives, as compaed to unicast o boadcast that tagets one o all ecipients espectively. It has the potential to utilize less netwok and host esouces in poviding this sevice. Applications, such as Intenet adio, ealtime financial infomation dissemination, softwae distibution all can potentially benefit fom the use of IP multicast. Multicast goup membeship management, unicast outing potocols, and multicast outing potocols ae all equied to enable end-to-end multicast communications. Goup membeship management is needed between eceive hosts and multicast-enabled fist hop outes on the LAN. Intenet Goup Management Potocol (IGMP) [2] is the pimay goup management potocol used in the Intenet community. IGMP is used between hosts and thei immediate multicast-enabled outes to quey, epot, and efesh the multicast goup infomation on LAN. Thee ae seveal types of unicast outing potocols cuently in use, including dynamic and static. RIP is a distance vecto type potocol wheeas Open Shotest Path Fist (OSPF) is link state based [1]. A supeio chaacteistic of link state potocols is that they can eact moe apidly to topologic changes as compaed to distance vecto o static topologies. A thid component potocol equied to enable multicast communications ove the WAN is multicast outing potocols. Multicast outing potocols often use the metics and topology infomation that is maintained by the undelying unicast outing potocol to build and maintain multicast packet delivey tees, and fowad multicast packets. Multicast outing potocols may be integated with a unicast outing potocols o may be independent of the undelying unicast outing potocol. Distance Vecto Multicast Routing Potocol (DVMRP) [5] is tightly coupled with RIP, and Multicast Open Shotest Path Fist (MOSPF) [3] to OSPF, wheeas Potocol Independent Multicast (PIM) [6] is independent of the undelying unicast outing potocol and may un ove any unicast outing potocol. The potocol models developed heein include IGMP fo multicast goup membeship management, OSPF as the unicast outing potocol, and PIM DM [4] as the multicast outing potocol. Simulation models fo an IP multicast system ae developed fo the investigation of end-to-end multicast failue ecovey behavio and pefomance. When a link o oute failue occus in a netwok, the multicast data delivey sevice can be inteupted fo a peiod of time. 1

2 In financial systems, fo example, sevices that ae caied using multicast must be able to apidly ecove fom netwok failues. This pape outlines the simulation models that whee developed within OPNET fo IP multicast. Seveal models wee developed to povide multicast netwok capabilities. The models include IGMP, PIM DM, modifications to the IP fowading engine, a andom topology geneato, an multicast sende and eceive application model, and a link fault injecto, as well as seveal pobes to acquie simulation statistics. In the next section, an intoduction to the potocols is povided, followed by a desciption of the simulation models. MODELS OVERVIEW The establishment of end-to-end multicast communication channels equies seveal potocols to wok in concet. To establish a multicast channel ove a native multicast enabled WAN, a sende application need only to send UDP packets onto the LAN using a class D IP addess (goup addess) in the destination field of the IP heade. The multicast enabled outes in the netwok ae esponsible fo constucting the multicast channel, and extending it to the inteested eceives. At the eceive side, howeve, the goup management potocol IGMP must execute between eceive hosts and thei default outes to allow hosts to expess inteest in paticula multicast goups. The eceiving application must explicitly expess inteest to its tanspot stack, in attaching to a specified goup and UDP pot. The IGMP component executing on the eceive host then fowads the goup inteest, specified by the class D IP addess, to the outes on the eceive s LAN. A selected oute (designated oute) subsequently attaches to and fowads all multicast channels fo the specified goup onto the LAN netwok. The host s tanspot stack filtes data eceived fom diffeent souces fo the same goup de-multiplexing via the UDP pot numbe specified by the eceiving application. If multiple souces send using the same goup and destination UDP pot numbe, application level filteing would be equied at the eceiving application to distinguish amongst the infomation steams. Peiodically, IGMP executing in the oute queies the hosts on the LAN to maintain the accuacy of its goup knowledge. This allows the designated oute (DR) to only pull-down those multicast channels fo goups that ae of inteest to eceives on the LAN. PIM DM is a boadcast and pune potocol and is best suited fo netwoks whee most eceives ae densely populated and bandwidth is plentiful. When a souce commences sending UDP taffic with an IP destination goup addess the fist hop oute(s) floods the data out its intefaces except the inteface on which the data aive. Subsequent outes do the same duing this boadcast phase of the potocol. When the multicast channel eaches a leaf oute (one that is LAN connected to potential eceives), the goup infomation maintained by the oute is examined and eithe the multicast data is fowaded onto the LAN o the oute punes back the channel. This allows only those eceives that have expessed inteest in the goup to have the channel extended to them. The boadcast and pune pocess epeats evey thee minutes. Thee is also the ability fo a new eceive to asynchonously attach to the multicast channel via a gafting mechanism. OSPF is a link state unicast outing potocol that povides obust fail-ove chaacteistics, compaed to othe unicast outing potocols. It can dynamically detect topological changes and calculate new loop-fee outes afte a peiod of convegence. Each oute in the netwok maintains a eplicated database. Routes execute Dijksta's algoithm on thei database to calculate a shotest-path oute to a given destination subnet. Routes exchange database infomation peiodically, o when netwok element failues occu, via a standad flooding algoithm. OSPF was fist intoduced into OPNET in vesion 3.5A by Mil3 and is the vesion on which this wok was completed. In the next section, an oveview is given fo the IGMP, PIM DM models, as well as the othe equied modifications and capabilities developed fo the multicast simulation. THE SIMULATION MODELS A netwok consists of numbes of outes and hosts. Routes connect diectly to othe outes o to local aea netwoks (LAN), whee hosts o othe outes ae connected. To suppot IP multicast, we modify the oiginal OPNET IP models (IP_RTE and IP_ENCAP) to pocess multicast packets and thus cay-out multicast fowading. The PIM_DM model is added into the netwok node models and povides outing contol fo multicast packets. In addition, the IGMP oute and host 2

3 models ae added, to wok with the PIM model. In ode to inject taffic into a netwok, an application model which geneates eithe unicast o multicast UDP datagams is developed. Thee ae two communication mechanisms and one model-wide egisty used to get, give, o exchange infomation fom one model instance to anothe. They ae: IGMP PIM OSPF,w,w,w,w,w Mlocal Moute Unicast oute Figue 1: Basic oute simulation model stuctue 1. Model-wide Registy: This can be effectively used in conjunction with the existing communication mechanisms fo vaious modeling equiements. The pocess egisty defines a goup of pocedues that allow OPNET defined pocesses to ecod, access, and shae infomation in a model-wide (o global) egisty. Usually, we use this type of communication mechanism to shae infomation needed by othe modules, such as dynamic unicast outing table, the dynamic multicast outing table o inteface table infomation. 2. Packet-Based Communications: This is used when thee ae packets needed to be elayed o exchanged inside the simulation netwok. 3. Inteface Contol Infomation: This type of communication mechanism is geneally associated with Packet-Based communications, that is, steam events. This happens because the infomation not caied by packets themselves needs to be sent to the eceiving pocess. Sometimes, an ICI is associated with emote a inteupt so that the inteupted module can etieve infomation even when the model instances ae not physically connected inside a node o outside a node. Netwok IP Encap IP Fowading Inside each of the following models, we will mention the uses of the above methods to inteact with othe modules. IP MULTICAST FORWARDING: THE IP_RTE MODEL The main function of IP_RTE is to act as the IP fowading engine and pocess IP packets that go though this module eithe fom highe layes o fom netwok. Thee ae seveal modifications equied to the standad IP_RTE model in ode to suppot IP Multicast as illustated in Figue 1. Those modifications ae outlined below. IP_RTE: PROCESSING PACKETS ARRIVING FROM HIGHER LAYERS Packets aiving fom uppe laye models like OSPF, PIM DM, UDP, etc., need to be fowaded out towads thei destination. In this case, IP_RTE will eithe get one o moe inteface addesses specified by the uppe laye model as an outgoing inteface, o needs to pefom a lookup in the outing tables to get a list of one o moe outgoing intefaces. Thee ae a few cicumstances in which packets will each IP_RTE fom the uppe laye. Unicast data packets: IP_RTE needs to find the outgoing inteface fom the dynamic unicast outing table. Multicast data packets: 1. Inside a host, this situation happens when the host is the souce of data packets. So fa ou hosts only have exactly one inteface connected to the boadcast media; we use this inteface addess as an outgoing inteface. 2. Inside a oute, this situation happens when the dynamic multicast outing (moute) table did not contain an enty of the souce-destination that matched this incoming packet when this packet aived at the oute. This packet was fowaded up to PIM. PIM ceates an enty fo this soucedestination and sends it down to IP_RTE again. Fo this case, outgoing intefaces ae obtained fom the moute table. Multicast contol packets: when IP_RTE eceives packets destined to a eseved multicast addess (multicast contol packets), IP_RTE will pocess them in a diffeent way compaed to a pue datagam data packet. Multicast contol packets ae fowaded out though the inteface specified by the highe laye. 3

4 IP_RTE: PACKET PROCESSING ARRIVING FROM THE NETWORK Packets fom the netwok will eithe be fowaded to the highe laye, fowaded out, o destoyed. When a packet fom netwok aives and eaches it's destination, this packet will be fowaded up to IP_ENCAP. IP_ENCAP then dispatches this packet to the coesponding module. Some packets need to be fowaded out again. Contol packets ae fowaded up to IP_ENCAP if thei eseved contol addess is egisteed. Incoming data packets that have eached thei destination ae fowaded to IP_ENCAP. All othe incoming packets ae destoyed. Unicast data packets: IP_RTE will eithe fowad them to uppe layes if they each thei destination o out again onto the netwok towads thei destination. Multicast data packets: When a oute eceives this type of packet, it will lookup in the moute table to find an enty that matches this packet. If the enty is found in the moute table, IP_RTE fowads the packet out onto the one o moe intefaces specified in the moute table enty. If an enty that matches this packet is not found, the packet is sent to the PIM model that will ceate an moute enty fo this packet and in tun send it down to IP_RTE again. At this time, IP_RTE knows how to fowad this packet, using the just established moute table enty. Fo a host node model, IP_RTE checks the incoming multicast data packet against the mlocal, maintained by IGMP. Multicast contol packets: If the IP addess of the incoming packets is a eseved addess, IP_RTE will fowad it to the highe laye via IP_ENCAP. IP_ENCAP in tun will fowad it to the coesponding module. IP_ENCAP MODEL This model pocesses all packets fom uppe modules that want to use the IP sevice povided by IP_RTE, and by all packets aiving fom the IP_RTE. When a packet aives fom the highe laye, an IP packet needs to be ceated to encapsulate this packet. In tun, the attibutes of this IP packet need to be set fom the ICI coesponding to this steam event and a new ICI will be installed. Thee ae two ICI fomats used fo this pupose. One is fo geneal datagams fom highe layes. When a packet aives fom the IP_RTE laye, the evese pocedue of the above situation needs to be pefomed. That is, attibutes fom the incoming packet ae conveted into an ICI that is associated with the datagam sent to the highe laye. PIM DM MODEL The main function of PIM_DM is to ceate and maintain outing infomation fo multicast packets inside the oute nodes. The inteaction between the PIM_DM model and the IGMP model is also impotant to popely maintain the moute table, as will be discussed shotly. The moute table needs to be egisteed so that IP_RTE can efeence it and know how to fowad multicast data and contol packets. Futhemoe, dynamic unicast outing infomation is eceived fom the OSPF pocess egisty. Afte the moute table is constucted, IP_RTE can use both dynamic unicast and multicast outing infomation duing its packet fowading pocess. At this point, the PIM hello message is scheduled to be fowaded to all PIM neighboing outes. The PIM DM model is now eady to pocess the incoming packets. Thee ae two types of packets that can aive at the PIM DM model; IGMP and all PIM messages. The IGMP messages ae used to update the mlocal table and the PIM messages ae used to update the moute table. All the PIM messages ae pocessed as is specified in the PIM_DM potocol specification. IGMP MODELS IGMP is a goup management potocol that has two components; one that executes in hosts and one that executes in outes. IGMP ROUTER MODEL The IGMP oute model initializes and then peiodically sends IGMP geneal queies on all its LAN intefaces to collect goup infomation. The IGMP oute model may eceive an IGMP leave goup message fom a host and subsequently emove that goup specific infomation fom the mlocal table (afte executing a goup specific quey, as pe the IGMP specification). PIM_DM is notified when the fist membe of the goup joins the goup, and when the last membe of the goup has left the goup. When a oute eceives an IGMP message, if the message is a quey fom anothe oute, it detemines whethe it emains in the Queie ole. If the message is 4

5 a epot fom a host, the IGMP model efeshes the epot time fo that goup on the inteface eceived, o inset the goup fo the inteface into the IGMP mlocal table if it is not yet in the table, and notifies PIM of the state change. If the message is an IGMP leave message fom a host, IGMP schedules a goup specific quey fo that goup on the inteface fom which the message was eceived. IGMP HOST MODEL The IGMP host model is esponsible fo two activities. It can eceive join o leave equests fom the application model (APP). It also esponds to membeship queies. When the module eceives a join o leave fom an application (highe laye), it needs to update the IGMP table inside the host to indicate the goup addess and numbe of applications on this host joining this specific goup. When a host eceives a membeship quey, it will schedule an inteupt so that a esponse state will send a membeship epot to the outes on the LAN. THE APPLICATION MODULE (APP) The application model is used fo injecting multicast data packets into netwoks and issuing join o leave message equests to the IGMP host model. Data packets fom this application module ae sent to the UDP laye, which in tun encapsulates them with a UDP heade, such as pot numbe, and sends them down to IP_ENCAP. The App model has to specify the destination addess and emote pot numbe in ode to send packets. On the multicast eceive side, the App model needs to egiste the pot numbe on which it is going to eceive the multicast packets. When eaching thei destination, data packets will be fowaded to IP_ENCAP fom IP_RTE. IP_ENCAP dispatches packets by potocol identifie. In this case, the identifie is UDP and packets ae fowaded up to UDP module. Afte the UDP laye eceives the multicast packet, it dispatches the packet to the appopiate App model, based on its destination pot numbe. Besides sending and eceiving data packets, the App model also communicates with the IGMP host model. The inteaction between these two models consists of join and leave goup messages. Join and leave goup messages ae specified by the use eithe in the initial state o dynamically duing the simulation un time. If join and leave ae specified in the initial state, uses need to input a time agument, which coesponds to the simulation time at which the join o leave will take place. If the time value is zeo, then the join o leave will be called immediately. Howeve in some cicumstance uses might want to schedule a join and leave based on peviously defined values instead of scheduling an immediately join o leave. The APP model also povides an API to allow dynamic join o leaves to occu. Fo dynamically called joins and leaves, a new state is defined that can eceive inteupts fom pospective models. CONCLUSIONS A desciption of an IP multicast OPNET simulation is povided. The simulation models consist of seveal new node models, including PIM DM and IGMP. Additionally, many changes wee equied of OPNET within the IP fowading function to suppot multicast. The detailed enhancements to the OPNET IP_RTE and IP_ENCAP models wee outlined. Since space is limited, seveal suppoting models ae mentioned but not discussed, including a andom topology geneato, link failue injection model and seveal multicast pobes. The simulation is being used to investigate the failue ecovey chaacteistics of IP multicast fo highly available systems, such as those in the financial sevices industy. REFERENCES [1] Moy, J., OSPF Vesion 2. Daft Standad RFC 1583, Mach, [2] Fenne, W. Intenet Goup Management Potocol, Vesion 2, RFC2236, Novembe [3] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Poteon, Inc., Mach [4] Stephen Deeing, Deboah Estin, Dino Fainacci, Van Jacobson, Ahmed Helmy, David Meye, Liming Wei. PIM Dense Mode Specification. daft-ietf-pimv2-dm-02.txt [5] Waitzman, D., Patidge, C., Deeing, S., Distance Vecto Multicast Routing Potocol. RFC 1075, Nov [6] Deeing, S., Estin, D., Fainacci, D., Jacobson, V., Liu, C., and Wei, L., The PIM Achitectue fo WAN Multicast Routing. ACM Tansactions on Netwoks, Apil