Simulation Study of CBT Multicasting Protocols

Transcription

1 Scholarly Paper Report Simulation Study of CBT Multicasting Protocols Mei Yu George Mason University Fairfax, Virginia 1

2 Contents 1. Background: unicast, broadcast, and multicast 2. Introduction to CBT Protocol 3. Project Description 4. OPNET Simulation Environment 4.1 Network Layer 4.2 Node Layer 4.3 Process Layer 5. Packet Format Definitions 6. Node Level Description of CBT multicast Network 6.1 Queue Module 6.2 IP Module 6.3 CBT Process Module 7. Process Models 7.1 IP Process Model 7.2 CBT Process Model 8. Tests 8.1 Link State maintenance test 8.2 Unicast test 8.3 CBT algorithm test 9. Conclusions 10. Reference 2

3 1. Background: unicast, broadcast, and multicast There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks. Multicasting is not connection oriented. A multicast datagram is delivered to destination group members with the same best-effort reliability as a standard unicast IP datagram. This means that a multicast datagram is not guaranteed to reach all members of the group, or arrive in the same order relative to the transmission of other packets. The only difference between a multicast IP packet and a unicast IP packet is the presence of a group address in the Destination Address field of the IP header. Instead of a Class A, B, or C IP address, multicasting employs a Class D destination address format ( ). Individual hosts are free to join or leave a multicast group at any time. There are no restrictions on the physical location or the number of members in a multicast group. A host may be a member of more than one multicast group at any given time and does not have to belong to a group to send messages to members of a group. Internet group membership protocol (IGMP) is employed by border routers to learn about the presence of group members on their directly attached subnetworks. When a host wants to join a multicast group, it transmit a group membership protocol message for the group(s) that it wishes to receive, and sets its IP process and network interface card to receive frames addressed to this multicast group. This receiver-initiated join process has excellent scaling properties since, as the multicast group increases in size, it becomes even more likely that a new group member will be able to locate a nearby branch of the multicast distribution tree. Multicast routers execute a multicast routing protocol to define delivery paths that enable the forwarding of multicast datagrams across an internetwork. A multicast routing protocol is responsible for the construction of multicast packet delivery trees and performing multicast packet forwarding. The latest addition to the existing set of multicast forwarding algorithms is Core Based Trees (CBT). Unlike existing algorithms, such as MOSPF and PIM, which build a source-rooted, shortest-path tree for each (source, group) pair, CBT constructs a single delivery tree that is shared by all members of a group. The 3

4 CBT algorithm is quite similar to the spanning tree algorithm except that it allows a different core-based tree for each group. Multicast traffic for each group is sent and received over the same delivery tree, regardless of the source. 2. Introduction to CBT Protocol The CBT protocol is designed to build and maintain a shared multicast distribution tree that spans only those networks and links leading to interested receivers. To achieve this, a host first expresses its interest in joining a group by multicasting an IGMP host membership report across its attached link. On receiving this report, a local CBT aware router invokes the tree joining process (unless it has already) by generating a JOIN_REQUEST message, which is sent to the next hop on the path towards the group s core router. This joining message must be explicitly acknowledged (JOIN_ACK), either by the core router itself, or by another router that is on the path between the originating router and the core, which itself has already successfully joined the tree. The join message sets up transient joining state in the routers it traverses, and this state consists of <group, incoming interface, outgoing interface>. Incoming interface and outgoing interface may be previous hop and next hop, respectively, if the corresponding links do not support multicast transmission. Previous hop is taken from the incoming control packet s IP source address, and next hop is gleaned from the routing table-the next hop to the specified core address. This transient state eventually times out unless it is confirmed with a join acknowledgement (JOIN_ACK) from upstream. The JOIN_ACK traverses the reverse path of the corresponding join message, which is possible due to the presence of the transient join state. Once the acknowledgement reaches the router that originated the join message, the new receiver can receive traffic sent to the group. Loops cannot be created in a CBT tree because: a) there is only one active core per group, and b) tree building/maintenance scenarios which may lead to the creation of tree loops are avoided. For example, if a router s upstream neighbor becomes unreachable, the router immediately flushes all of its downstream branches, allowing them to individually rejoin if necessary. Transient unicast loops do not pose a threat because a new join message that loops back on itself will never get acknowledged, and thus eventually times out. The state created in routers by the sending or receiving of a JOIN_ACK is bidirectional. Data can flow either way along a tree branch, and the state is group specific. It consists of the group address and a list of local interfaces 4

5 over which joining messages have previously been acknowledged. There is no concept of incoming or outgoing interfaces, though it is necessary to be able to distinguish the upstream interface from any downstream interfaces. In CBT, these interfaces are known as the parent and child interfaces, respectively. A router is not considered on-tree until it has received a JOIN_ACK for a previously sent JOIN_REQUEST. With regards to the information contained in the multicast forwarding cache, on link types not supporting native multicast transmission an ontree router must store the address of a parent and any children. On links supporting multicast however, parent and any child information is represented with local interface addresses (or similar identifying information, such as an interface index ) over which the parent or child is reachable. Data from non-member senders must be encapsulated (IP-in-IP) by the first hop router, and is unicast to the group's core router. Consequently, no group state is required in the network between the first hop router and the group s core. On arriving at the core router, the data packet s outer encapsulating header is removed and the packet is disseminated over the group-shared tree as described below. When a multicast data packet arrives at a router, the router uses the group address as an index into the multicast forwarding cache. A copy of the incoming multicast data packet is forwarded over each interface (or to each address) listed in the entry except the incoming interface. Each router that comprises a CBT multicast tree, except the core router, is responsible for maintaining its upstream link, provided it has interested downstream receivers, i.e., the child interface list is not NULL. A child interface is one over which a member host is directly attached, or one over which a downstream on-tree router is attached. This "tree maintenance" is achieved by each downstream router periodically sending a CBT "keep-alive" message (ECHO_REQUEST) to its upstream neighbor, i.e., its parent router on the tree. One keep-alive message is sent to represent entries with the same parent, therefore improving scalability on links shared by many groups. On multicast capable links, a keepalive is multicast to the "all-cbt-routers" group (IANA assigned as ); this has a suppressing effect on any other router for which the link is its parent link. If a parent link does not support multicast transmission, keepalive messages are unicast. The receipt of a keepalive message over a valid child interface prompts a response (ECHO_REPLY), which is either unicast or multicast, as appropriate. The ECHO_REPLY message carries a list of groups for which the corresponding interfaces is a child interface. 5

6 It cannot be assumed that all the routers on a multi-access link have a uniform view of unicast routing; this is particularly the case when a multi-access link spans two or more unicast routing domains. This could lead to multiple upstream tree branches being formed (an error condition) unless steps are taken to ensure all routers on the link agree which is the upstream router for a particular group. CBT routers attached to a multi-access link participate an explicit election mechanism that elects a single router, the designed router (DR), as the link's upstream router for all groups. Since the DR might not be the link's best next-hop for a particular core router, this may result in join message being redirected back across a multi-access link. If this happens, the re-directed join message is unicast across the link by the DR to the best nexthop, thereby preventing a looping scenario. This re-direction only ever applies to join messages. Whilst this is suboptimal for join messages, which are generated infrequently, multicast data never traverses a link more than once (either natively, or encapsulated). In all but the exception case described above, all CBT control messages are multicast over multicast supporting links to the "all-cbt-routers" group, with IP TTL 1. The IP source address of CBT control messages is the outgoing interface of the sending router. The IP destination address of CBT control messages is either the "all-cbt-routers" group address, or a unicast address, as appropriate. All the necessary addressing information is obtained by on-tree routers as part of tree set up. If CBT is implemented over a tunneled topology, when sending a CBT control packet over a tunnel interface, the sending router uses as the packet's IP source address the local tunnel end point address, and the remote tunnel end point address as the packet's IP destination address. During the process of CBT tree setup and maintenance, the core router address discovery is the key to the implementation. There are two available options for version 2 CBT core discovery; "bootstrap" mechanism is applicable only to intra-domain core discovery, and allows for a "plug and play" type operation with minimum configuration. However, this mechanism is difficult to affect the shape and therefore the optimality of the resulting distribution tree. Another option is to manually configure the border (or leaf) router with <core, group> mappings. Note that this lies in border routers only. This mechanism imposes a certain degree of administrative burden. Thus, this method does not scale very well. However, it is more likely that "better" trees can result from this method, and it is the only available option for inter-domain core discovery. 6

7 3. Project Description The primary goal is to study the behavior of CBT in a multicast network. The main references used to implement the CBT protocol include: RFC2201 Core Based Trees (CBT) Multicast Routing Architecture RFC2189, Core Based Trees (CBT version 2) Multicast Routing To achieve this goal, I constructed a CBT multicast capable router, a multicast network, and duplex communications link. The actual CBT protocol implemented in the study is based on CBT specification of version 2. However, some simplifications are made to test main features of CBT protocols. Some protocols inside CBT such as HELLO protocol is not simulated, because it is not used at current stage. The manual configuration is used at border router to accomplish core discovery. OPNET was employed to the prototype CBT multicast network. A test network with number of routers 12 is used to test the CBT protocol. This report will explain the details of the simulation, tests done and the work that can be done in the future. 4. Simulation Environment OPNET was used as the simulation tool for this study. OPNET is a layered approach that is top down layer from the network to the process layer. This layered approach is not in any way related to the layered model of the internetwork. The highest layer in the OPNET is Network layer, the next one is node layer and the last one is process layer. 4.1 Network Layer Network layer represents the network that is being simulated. The network was built using the OPNET network editor. The network topology includes 12 routers. Each of these network elements is interconnected using a bidirection link that enables the bi-directional traffic. Figure 1 shows the top layer of network. 7

8 The attributes of the elements of the network layer are Routers 1. IP Address 2. Model: CBT_Router Links 1. Model: CBT_link 2. Data rate: 10,000bps, duplex 4.2 Node Layer This layer was built using Node editor. This layer represents the internal structure of routers and hosts. The basic blocks of the node level structure are Process modules: These modules are used to simulate the behavior of various protocols, which process the incoming packets and route the outgoing packets. Some of the process nodes are CBT process. Transmitter modules: These nodes are used to simulate the transmitting behavior of the packet and the attribute of these nodes is transmission speed which in turn along with the receiver speed effects the transmission delay of the packet. Receiver modules: These nodes simulate the effect of packet reception. The attribute for this node is receiver speed. 8

9 Streams: These are used to interconnect the above nodes and to convey information from one node to other node. Also the packets that are needed to travel between various nodes are sent over these streams. 4.3 Process Module The process module consists of all the states of each process being simulated. They can be viewed conveniently as Finite State Machine (FSM). Each state has arrival and exit executives, which take the form of the code written for simulating the process or protocol. The code is written in C and does have some OPNET related calls that are provided by the OPNET library. Variables and functions are defined in this layer. The following blocks are used Header block used for definitions of the structures and preprocessor commands. State variable block used for defining the variables that are accessible for all the states in the process model. Temporary variable block used to define the variables that are accessible to a particular state Function block used to write the functions that are used by the process. 5. Packet format definitions In this section, all the packet formats are listed in this study for future reference. A variety of packet formats are defined, from CBT packet to IP packet. Only the packet fields that are relative to this study are defined for simplifications. 5.1 IP packet fields: TTL /*Time to Live, integer */ Pro_ID /*protocol ID code: CBT, ICMP, IpoIP, or IP_data */ Total length /*total packet length, including header */ Src_add /*Source host address */ Dest_add /*destination host address*/ Data_Packet /*embedded data packet*/ 5.2 CBT packet formats CBT_Packet /* CBT packet is embedded into IP packet*/ CBT_type /*type of CBT message embedded */ Data_Packet /*data packet, linking to actual CBT message */ 9

10 5.2.2 CBT_echo_rep /*CBT echo reply*/ num_of_group /*number of groups included */ orig_par_router /*originating parent address*/ group_add_1 ~ group_add_19 /*up to 19 groups are acknowledged CBT_join_req /*CBT join request */ group_add /*the group to join */ tar_router /*core router address */ orig_router /*originating border router address */ CBT_join_ack /* CBT join acknowledgement */ group_add /*acknowledged group address */ tar_router /*targeted border router address */ CBT_echo_req /*CBT echo request */ orig_chi_router /*originating child router address */ CBT_quit /*CBT quit notification */ group_add /*the group I want to quit */ orig_chi_router /*originating router address */ CBT_flu /*CBT tree flush, not the same as orginal CBT spec*/ group_add /*the group I want to flush*/ 6. Node Level Description of the CBT Multicast Network Figure 2 shows the node level structure of the CBT capable multicast router. 10

11 The elements of the node structure are Transmitter phy_rx Receiver phy_rx IP Module Queue Module CBT Processor Module 6.1 Queue Module The Queue Module provides service to IP node by generating packets. This traffic was generated in order to generate background for performance analysis of CBT. Queue modules at border routers are activated to simulate the LAN hosts behavior. 11

12 6.2 IP Module The IP Module provides service to the higher layer by utilizing the services provided by the Queue layer. The IP layer receives packets from Queue Node layer and the higher protocol that is on the top of it. If it receives packet from lower layer, it will forwards this packet to different processes depending on the protocol id in the IP header of the packet. 6.3 CBT Process Module This module simulates the CBT protocol, which was proposed in the RFC2189 and RFC2201. CBT protocol involves processing of the following requests and acknowledges: (1) CBT join request (2) CBT join ack (3) CBT echo request (4) CBT echo ack (5) CBT quit notification (6) CBT flush trees The Hello sending and receiving protocol necessary to actual router environment is omitted here for convenience. The descriptions of CBT process and IP process of the CBT aware router are documented as follows. 7. Process Models 7.1 IP Process Model Figure 3 shows the process model diagram of router IP process. This process implements Dijkstra s shortest-path algorithm for unicast and CBT multicasting routing. It also constructs and maintains unicast routing table consisting of link states reflecting global topology. 12

13 Each states function is explained in detail below: Init: Initialize variables, get object ID. Transits to Idle state after completing all the initializations. Idle: This state has transitions to three states, Arr, Link_state, clock. It transits to Arr state upon packet arrival, transit to Link-State state when LS_SEND interrupt was true, it will transit to clock state when REAL_TIME interrupt was true. Arr: This state checks the type of the packet arrived depending on the protocol ID in the IP header and calls the appropriate function depending on the type of message received. Pesudo code for Arr state: switch (protocol) { case datagram: if (destadd==myadd) { discard packet; record statistics; else if (destadd==groupadd) { 13

14 multicast packet; else { discard packet; break; case IPoIP: if(destadd == myadd && sub_destadd == GroupAdd) { multicast packet; else { discard packet; break; case ICMP: if(this packet is new){ update local link state; broadcast this packet; break; case CBT: send this packet to CBT module; break; default: break; Dij: This function used Dijkstra s algorithm to calculate the shortest-path for unicast routing. Pseudo_code: INITIALIZATION: For n=1 to n do Begin D(n)=infinity; Final(n)=false; S(n)=-1; End; D(dest)=0; 14

15 Final(dest)=true; New=dest; ITERATION For n=1 to n=n-1 do Begin For every immediate predecessor I for new if not final(i) do Begin Newdist=D(new)+C(new,j); If newdist<d(i) then do Begin D(i)=newdist; S(i)=new; End; End; Find the node k with smallest temporary label which is not infinity Final(k)=true; New=k End Clock: Generate interrupt according to some condition. If current simulate time minus laststateupdatetime >= LINK_STATE_UPDATE_INTERVAL, it will schedule a interrupt. If not, it will schedule an interrupt every current simulation time+10 seconds. Link_State: In this study, link state representation is used for the network topology. Accordingly, the single source Dijkstra algorithm is employed to find the shortest path from all nodes to a specified destination address. Therefore, knowing a router's address itself, it can get the next hop router address on the shortest path to the destination. Each router periodically maintains it's link state regarding to the global topology and its current neighborhood (local topology). The key technique in link state routing algorithm includes: (1) link state maintenance (2) implementation of Dijkstra's single source shortest path. 15

16 Dijkstra's single source shortest path algorithm has already been described above. The link state maintenance protocol works as follows: Initially, just after power is turned on, each node has no idea of either local or global topology. Its link state table (implemented as link list data structure) and neighborhood table (implemented as linear array) are set to NULL. A real-time clock with interrupt of every 30 seconds is implemented inside the IP process module. Each router broadcast its current neighborhood table using IP datagram every 30 seconds, with TTL (Time_ To_Live) set to 16. On receiving link state broadcasting datagram, it is terminated if TTL=0. Otherwise, if the datagram is from its immediate neighbor (TTL==16), current router's neighborhood table is updated, because it knows there is some router connected on this interface. In the meantime, it also updates the global link state table if the datagram is new. For all other cases it broadcast this datagram to all interfaces except the incoming interface. TTL value is decremented by one. It is important to note that for each link state, I maintain its last refreshing time. That is the latest time it is updated. I use this attribute to distinguish new or old link-state broadcasting packet. Since link state table is broadcast every 30 seconds, I treat a incoming packet new, if the difference between the incoming time and last refreshing time for the link state broadcast from the same node is great than 25 seconds. In this case, I need to update the current link state. Otherwise, the incoming packet is omitted. I also set timeout interval for each link state. The default value is 150 seconds. If some link state is not updated within this interval, I will treat this link as no longer being existed. This link is then deleted. Also note that each topology starts from NULL. Thus if a router get datagram from its immediate neighbor and the contents are NULL, this kind of datagram should not be forwarded. Current router needs only to update its neighborhood table, since at least it can get something from this interface. Pseudo_code for Link_State: link_state_send() { while(current_time - old_time < 30) do nothing; form IP datagram including my current neighbor list; /* TTL is set to 16 */ 16

17 broadcast this datagram on all interfaces; old_time = current_time; link_state_receive() { retrieve neighbor table from the source node; if(it is from my immediate neighnor) update my neighborhood table; if(source node has no neighbors) discard this packet; for(each link state) { if(it is timeout) delete this link state; /*timeout detection */ else if(this link belongs to incoming packet) if(link state is old) update its refreshing time; else omit this link state; end end end Add all newly discovered link states; TTL = TTL - 1; if(ttl>0) forward the link state packet to all interface except the incoming one; 7.2 CBT Process Model Figure 4 shows the process model diagram of the CBT process. This process simulates the behavior of the CBT multicast routing algorithm. 17

18 CBT protocol involves processing of the following requests and acknowledges: (1) CBT join request (2) CBT join ack (3) CBT echo request (4) CBT echo ack (5) CBT quit notification (6) CBT flush trees The CBT protocol implemented in this study complies with CBT version 2, suggested in RFC However some simplification is made to the original specification. For example, the Hello protocol is omitted here because no broadcast links are used here. Following constants are used in the CBT protocol, complying with the CBT specification version 2. (1) MAX_RTX: 18

19 maximum number of retransmission, default value = 3 (2) RTX_INTERVAL: message retransmission interval, default value = 5 seconds (3) JOIN_TIMEOUT: raise exception due to tree join failure, default value = 3.5*RTX_INTERVAL (4) TRANSMISSION_TIMEOUT: delete unconfirmed transient state, default value = 1.5*RTX_INTERVAL (5) GROUP_EXPIRE_TIME time to send QUIT_NOTIFICATION to non responding parent, defaut value=1.5*echo_interval (6) ECHO_INTERVAL interval between sending ECHO_REQUEST to parent routers, default value= 60 seconds (7) EXPECTED_REPLY_TIME: consider parent unreachable, default value = 70 seconds The following processing takes place in the indicated states. Init: This state initializes all the router variables. Default transition to idle state. Idle: This state has several transitions. If a packet arrives it will transit to arr state. It transits to join_req when the join request interrupt was true, transit to join_rep state when the join reply interrupt was true, transit to echo_req when echo request interrupt was true, transit to echo_rep when echo reply interrupt was true, transit to quit_notification when the quit interrupt was true. Join_Request: Pesudo code of this state: join_request(packet* ptr) { /*get the group address of join_request packet*/ Group = get_group_address(ptr); /*other party also needs to activate this group*/ if(this group is already in transient state) 19

20 cache the (group, down_stream, up_stream); /*I need not to forward it*/ put time stamp on this node; else if (this group has already exists) /*I am on the CBT tree */ form JOIN_ACK packet; send JOIN_ACK packet; add this interface to CBT tree information list; add time stamp to this node; else if(destination address = my address) /* I must be the core */ form JOIN_ACK packet; send JOIN_ACK packet; add this interface to CBT tree information list; add time stamp to this node; else get core router address; /* this is new group joining request, forward it */ get the next interface port to send via routing algorithm; forward this packet using unicast; update the transient CBT tree; end end end Join_Ack: Pseudo code for this state: join_ack(packet* ptr) { group = get_group_address(ptr); if(this group already exists on the CBT tree this group does exist on the transient CBT tree) omit this packet else /*confirmation received for the transient group */ for(each node on the transient CBT tree(cache) which matches the group address) { if(timeout) delete this packet; else add this group to CBT tree; update the transient CBT tree; 20

21 set the last refresh time for the group; end if( destination address = my address) destroy this packet; /* I am the border router */ else forward this JOIN_ACK packet to all down streams /* I am in the middle of the tree / associated with the indicated group; end end Echo_Request: Pseudo code for this state: echo_request(packet* ptr) { retrieve the CBT tree to find all groups associated with this downstream; form the ECHO_ACK packet; send ECHO_ACK on the reverse path; Echo_Ack: Pesudo code for this state: echo_ack(packet *ptr) { get all acknowledged group number; for(each group) { if(timeout) delete the ECHO_ACK packet; form the TREE_FLUSH packet; send TREE_FLUSH to all downstreams associated with the group; form QUIT_NOTIFICATION packet; send QUIT_NOTIFICATION to the parent of this group; else update the last refresh time for the group; 21

22 end Quit_Notification: Pseudo Code for this state: quit_notification(packet *ptr) { group = get_group_address(ptr); if( this group exists in CBT tree) delete this downstream of the group; if(no more downstream belongs to the group) delete this group from CBT tree; if(this group has parent) /* I am in the middle of CBT tree */ form QUIT_NOTIFICATION packet; send QUIT_NOTIFICATION to the parent; else do nothing here; /* I am the core */ end end end Tree_Flush: Pseudo code for this state: tree_flush(packet* ptr) { group = get_group_address(ptr); delete this group from CBT tree; if(no downstream exists for this group) /* packet has reached the border router */ do nothing here else form TREE_FLUSH packet; send TREE_FLUSH on all down streams belonging to this group; /* I am in the middle of CBT TREE */ 22

23 end 8. Test 8.1 Link State maintenance test The following result is got after 60 seconds. Router whose IP address is 120 got the network topology. The neighbors of every router are shown below. You may compare this result with figure Unicast algorithm test 23

24 The following result is got when a packet is sent from router 100 to router 110. It is unicast forwarding. From Dijkstra's algorithm, the shortest path is from router 100 to router 20 to router 40 to router 110. You may compare the result shown below. 8.3 CBT algorithm test The following is got when we test CBT algorithm. When a packet from router 80 wants to join a group which address is The join request message is sent from router 80 to router 10 to router 30 to router 70, which is the core router of that group. Then the joining acknowledgement message is sent back according to the reverse path. You may compare it with the result shown below. 24

25 9. Conclusion CBT multicasting (ver.2) is viable, compared to MOSPF, PIM, or other multicasting protocols. CBT is a Shared-Tree algorithm, in contrast to other Source-Driven Tree algorithms. It has been shown via experiment and analysis, that number of routers involved in multicasting much less than other multicasting algorithms. CBT still need unicast to construct the tree, either by Link-state, or Distance-Vector. Benefits In terms of scalability, CBT has several advantages over the Reverse Path Multicasting (RPM) algorithm. CBT makes efficient use of router resources since it only requires a router to maintain state information for each group, not for each (source, group) pair. Also, CBT conserves network bandwidth since 25

26 it does not require that multicast frames be periodically forwarded to all multicast routers in the internetwork. Limitations Despite these benefits, there are still several limitations to the CBT approach. CBT may result in traffic concentration and bottlenecks near core routers since traffic from all sources traverses the same set of links as it approaches the core. In addition, a single shared delivery tree may create suboptimal routes resulting in increased delay-a critical issue for some multimedia applications. Finally, new algorithms still need to be developed to support core management, which encompasses all aspects of core router selection and (potentially) dynamic placement strategies. 10. References (1) A. Ballardie, Core Based Trees (CBT version 2) Multicast Routing RFC2189, September 1997 (2) A.Ballardie, Core Based Trees (CBT) Multicast Routing Architecture RFC2201, September 1997 (3) Chuck Semeria and Tom Maufer Introduction to IP Multicast Routing (4) M.Pullen, A simulation Model for IP Multicast with RSVP, 1997 (5) John D. Spragins, Telecommunications Protocols and Design, 1995 (6) Douglas E. Comer, Internetworking with TCP/IP, 2000 (7) S.Keshav An Engineering Approach to Computer Networking,