Improving the Quality of Multicast Networks by Using
the OPNET Modeler
Krishna Kumaran Vienjipuram
Asmeer Babu Abdul
This thesis is presented as part of the Degree of Master of Science in Electrical
Engineering with Emphasis in Telecommunication
Blekinge Institute of Technology
June 2010
Master of Science Program in Electrical Engineering
School of Computing
Abstract
This thesis presents different Internet Protocol (IP) multicasting design models and together with their implementation methods in OPNET Modeler 14.5. The models presented in this report are designed for handling various types of advanced multimedia applications and services when using the multicast communication paradigm. The architectural models presented in this thesis are independent of the routing protocols used as well as of the underlying networking environment.
Several exiting challenges related to high bandwidth requirements, low network delay, and jitter are discussed together with these design models, and are simulated using the OPNET Modeler. The emerging demands for new multicast capable applications, for both real-time and non real-time traffic are considered together in this report in order to better evaluate multicast traffic requirements.
Efficient routing methods, group management policies, and shortest path algorithms are also discussed in the proposed models. The pros and cons of IP multicasting are described using the Protocol Independent Multicast Sparse Mode (PIM-SM) method, in the highlight of the proposed design models.
Several results related to link utilization, end-to-end delay, packet loss, PIM control traffic, Internet Group Management Protocol (IGMP), and network convergence are obtained by using already available statistical methods and modules from OPNET Modeler. Our major contribution with this thesis work relates to components associated with network convergence, routing delay, and processing delay. These components are illustrated in this thesis using various OPNET metrics. Moreover, several issues related to protocol scalability, supportability, performance optimization and efficiency are also presented by using OPNET’s build in reports, i.e., executive flow and survivability analysis reports.
Preface and Acknowledgements
This project is a work required for the fulfillment of our Master’s Degree in Electrical Engineering with emphasis on Telecommunication in June 2010. The thesis was carried out with OPNET Modeler 14.5, at Blekinge Institute of Technology (BTH), Karlskrona, Sweden.
We are grateful to our honorable thesis supervisor Dr. Doru Constantinescu at School of Computing, Blekinge Institute of Technology, who had guided our thesis work with his scholarly advice. Without his guidance and encouragement this task would have been unachievable. We express our heartfelt gratitude to him.
We would like to thank our friends and parents who supported us during our master thesis. We would also like to thank, the program managers Mikael Åsman, Anders Nelsson as well as other BTH staff, too numerous to mention here.
Krishna Kumaran Vienjipuram, Asmeer Babu Abdul,
Goals
Table of Contents
ABSTRACT ... III GOALS ... VII LIST OF FIGURES ... XIII LIST OF TABLES ... XV ACRONYMS ... XVII CHAPTER I ... 1 1INTRODUCTION ... 1 1.1 INTRODUCTION ... 1 1.2 PROBLEM DESCRIPTION ... 1 1.3 INTENDED AUDIENCE ... 1 1.4 SCOPE ... 2 1.5 MOTIVATION ... 2 1.6 LIMITATIONS ... 2
1.7 STRUCTURE OF THE REPORT ... 2
1.8 MULTICAST HISTORY ... 3
CHAPTER II ... 5
2 BACKGROUND & RELATED WORK ... 5
2.1 BACKGROUND ... 5
2.2 RELATED WORK ... 5
2.3 COMPARISON TO THIS WORK ... 6
CHAPTER III ... 7
3.1 INTERIOR GATEWAY ROUTING PROTOCOLS ... 8
3.1.1 DISTANCE VECTOR ROUTING ... 8
3.1.2 LINK STATE ROUTING ... 8
3.1.3 HYBRID ROUTING ... 9
3.2 EXTERIOR GATEWAY ROUTING PROTOCOLS ... 9
3.3 CLASSLESS ROUTING ... 9
3.3.1 OPEN SHORTEST PATH FIRST ... 10
3.3.2 BORDER GATEWAY PROTOCOL ... 10
3.4 CLASSFULL ROUTING ... 10
3.5 STATIC AND DYNAMIC ROUTING ... 10
3.5.1 STATIC ROUTING ... 10
3.5.2 DYNAMIC ROUTING ... 11
3.6 ROUTING ALGORITHMS ... 11
3.6.1 GLOBAL ROUTING ALGORITHM ... 11
3.7 HIERARCHICAL ROUTING... 11
3.8 IP COMPONENTS ... 12
3.9 ERROR IDENTIFICATION ... 12
3.9.1 ICMP MESSAGE TYPES ... 12
CHAPTER IV ... 13
4 MULTICAST ADDRESSING ... 13
4.1.1 DYNAMIC ALLOCATION ... 14
4.1.2 STATIC ALLOCATION ... 14
4.2 MULTICAST ADDRESS MAPPING ... 14
4.3 MULTICAST ROUTING PROTOCOLS ... 15
4.3.1 MULTICAST ROUTING PROTOCOLS ... 15
4.3.2 PROTOCOL INDEPENDENT MULTICAST VERSIONS ... 15
4.3.3 PROTOCOL INDEPENDENT MULTICAST ... 15
4.3.4 MSDP ... 15
4.3.5 DENSE MODE PROTOCOLS ... 16
4.3.6 DISTANCE VECTOR MULTICAST ROUTING PROTOCOL ... 16
4.3.7 SPARSE MODE PROTOCOLS ... 16
4.3.8 PIM SPARSE-DENSE MODE ... 18
4.4 ROUTING MULTICAST TRAFFIC ... 19
4.4.1 TRASNPORT PROCOCOLS AND MULTICASTING ... 19
4.5 MULTICAST FORWARDING ... 20
4.6 MULTICAST TRAFFIC ENGINEERING ... 20
4.6.1 RP POSITION ... 20
4.6.2 MULTICAST ROUTING CONFIGURATION ... 20
4.6.3 DEPENDENCY ON UNICAST ... 20 4.7 IGMP ... 21 4.7.1 IGMP v1 ... 21 4.7.2 IGMP v2 ... 21 4.7.3 IGMP v3 ... 21 4.7.4 IGMP MESSAGES ... 21
4.7.5 IGMP PROTOCOL OPERATION ... 22
4.8 CGMP ... 22
4.9 IP MULTICAST MODEL ARCHITECTURE & MULTICAST OPERATIONS ... 23
4.9.1 JOINING A GROUP ... 23
4.9.2 SENDING TRAFFIC TO A GROUP ... 24
4.9.3 MULTICAST TUNNELING ... 25
4.9.4 DVMRP TUNNELS ... 25
4.9.5 GRE TUNNEL ... 25
4.9.6 MULTICAST APPLICATIONS ... 25
4.9.7 PERFORMANCE METRICE IN MULTICASTING ... 25
CHAPTER V ... 27
5. MODEL DESIGN I ... 27
5.1 MODEL DESIGN EXPERIMENT 1 ... 27
CHAPTER VI ... 31
6 MODEL DESIGN II ... 31
6.1 DESIGN MODEL EXPERIMENT II ... 31
CHAPTER VII ... 33
7. SIMULATION RESULTS AND ANALYSIS ... 33
7.1 EXPERIMENT I ... 33
7.1.1 INTRODUCTION TO NEW DESIGN AND SCENARIO EXPERIMENT I ... 33
7.2 EXPERIMENT II ... 64
7.2.1 INTRODUCTION TO NEW DESIGN AND EXPERIMENT II ... 64
7.3 INTERNET STANDARDS USED IN THIS REPORT ... 82
LIST OF FIGURES
FIGURE 1: MULTICAST DEPLOYMENT FROM 1992 TO 2006 ... 3
FIGURE 2 ROUTING PROTOCOLS ... 7
FIGURE 3 CLASS D RANGE IP MULTICAST ... 13
FIGURE 4 IEEE 802.3 MAC ADDRESS STRUCTURE ... 14
FIGURE 5 PIM SPARSE-DENSE MODE ... 18
FIGURE 6 CGMP OPERATION WITH ROUTERS AND SWITCHES ... 23
FIGURE 7 IGMP GROUP JOINING PROCEDURE ... 24
FIGURE 8 MULTICAST TRAFFIC FORWARDING TO GROUPS ... 24
FIGURE 9 NEW MODEL DESIGN EXPERIMENT I ... 27
FIGURE 10 RONNEBY SUBNET ... 28
FIGURE 11 KARLSHAM SUBNET ... 29
FIGURE 12 KARLSKRONA SUBNET WITH R1 AS RP ... 30
FIGURE 13 NEW MODEL DESIGN EXPERIMENT II ... 31
FIGURE 15 ROUTING BETWEEN DEVICES IN RONNEBY ... 35
FIGURE 16 BGP ROUTING BETWEEN DEVICES IN RONNEBY ... 35
FIGURE 17 KARLSKRONA JUNCTION ROUTING INFORMATION ... 36
FIGURE 18 CONNECTIVITY BETWEEN DEVICES FROM KARLSKRONA JUNCTION ... 37
FIGURE 19 KARLSHAM JUNCTION ROUTING INFORMATION ... 38
FIGURE 20 GLOBAL IP STATISTICS SUMMARY IN EXP I ... 39
FIGURE 21 GLOBAL STATISTICS PIM-SM SUMMARY ... 40
FIGURE 22 GLOBAL STATISTICS SUMMARY BGP ... 40
FIGURE 23 GLOBAL STATISTICS EIGRP SUMMARY ... 41
FIGURE 24 POINT-TO-POINT QUEUING DELAY BETWEEN MAJOR DEVICES ... 41
FIGURE 25 TRAFFIC SENT /RECEIVED IN PACKETS/SEC ... 42
FIGURE 26 FLOW ANALYSIS EXP 1 ... 43
FIGURE 27 NET DOCTOR FINAL REPORT EXP I ... 45
FIGURE 28 NET DOCTOR SURVIVABILITY SCORE ... 46
FIGURE 29 CASE VIOLATION HISTORY PIE CHART ... 47
FIGURE 30 FAILURE IMPACT SUMMARIES ... 47
FIGURE 31 ELEMENT SURVIVABILITY REPORT ... 48
FIGURE 32 NETWORK PERFORMANCE REPORT ... 48
FIGURE 33 NETWORK PERFORMANCE (AVERAGE LINK UTILIZATION) ... 49
FIGURE 34 NET REPORTS OVER-UTILIZATION OF LINKS ... 50
FIGURE 35 OVER-UTILIZATION AND LINK FAILURES ... 51
FIGURE 36 CAPACITY PLANNING FLOW ANALYSIS REPORT ... 55
FIGURE 37 END–TO-END DELAY DISTRIBUTION CAPACITY PLANNING REPORT... 56
FIGURE 38 IP BACKGROUND TRAFFIC ... 57
FIGURE 39 PIM-SM CONTROL TRAFFIC SENT/RECEIVED ... 58
FIGURE 40 BGP AND EIGRP TRAFFIC EXP 1 ... 59
FIGURE 41 UDP TRAFFIC EXP 1 ... 60
FIGURE 42 CLIENT FTP TRAFFIC RECEIVED/SENT ... 61
FIGURE 43 FTP TRAFFIC EXP 1 ... 62
FIGURE 44 MULTICAST TRAFFIC, LAN INBOUND/OUTBOUND ... 63
FIGURE 45 NEW DESIGN SCENARIO MAIN TOPOLOGY EXP II ... 64
FIGURE 46 CONFERENCING APPLICATION ROUTING WITH GROUP ADDRESS 224.0.6.1 ... 65
FIGURE 47 FTP APPLICATION ROUTING WITH GROUP ADDRESS 224.0.6.11... 66
FIGURE 48 DATABASE APPLICATION ROUTING WITH GROUP ADDRESS 224.0.6.12 ... 66
FIGURE 49 DISCRETE EVENT SIMULATION EXP 2 ... 68
FIGURE 50 GLOBAL STATISTICS PIM-SM EXP 2 ... 69
FIGURE 51 FLOW ANALYSIS EXP 2 ... 70
FIGURE 52 EXECUTIVE SUMMARY IP MULTICAST GROUP ... 71
FIGURE 53 NET DOCTOR REPORT EXECUTIVE SUMMARY EXP 2 ... 72
FIGURE 54 OSPF AREAS TOPOLOGY II PIE CHART EXP 2 ... 72
FIGURE 56 SURVIVABILITY ANALYSIS EXECUTIVE REPORT EXP 2 ... 74
FIGURE 57 POINT-TO-POINT QUEUING DELAY (SEC) ... 74
FIGURE 58 PIM-SM DETAILS EXP 2 ... 76
FIGURE 59 VIDEO CONFERENCING AND OSPF NETWORK CONVERGENCE ... 77
FIGURE 60 AVERAGE IP TRAFFIC, VLAN, MANAGEMENT TRAFFIC, FTP TRAFFIC ... 78
FIGURE 61 FTP DOWNLOAD/UPLOAD RESPONSE TIMES, VIDEO CONFERENCING TRAFFIC ... 79
FIGURE 62 IP END-TO-END DELAY TRAFFIC, IP MULTICAST TRAFFIC SENT/RECEIVED/DROPPED ... 80
List of tables
TABLE 1 ACRONYMS ... XVII
TABLE 2 ROUTING PROTOCOL COMPARISON ... 8
TABLE 3 ICMP MESSAGE TYPES ... 12
TABLE 4 MULTICAST RANGE AND DESCRIPTION ... 13
TABLE 5 RESERVED MULTICAST ADDRESSES ... 13
TABLE 6 PIM OPERATION... 15
TABLE 7 IP MULTICAST MODEL ARCHITECTURE ... 23
TABLE 8 SIMULATION LOG DESCRIPTION EXP 2 ... 68
TABLE 9 OSPF AREAS TABULAR FORMAT EXP 2 ... 73
ACRONYMS
Table 1 ACRONYMS BGP Border Gateway Protocol
BSR Boot Strap Router
CGMP Cisco Group Management Protocol
DVMRP Distance Vector Multicast Routing Protocol EIGRP Exterior Gateway Routing Protocol
Hop Count Estimated number of hops
ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IS-IS Intermediate System to Intermediate System
LAN Local Area Network
MAC Medium Access Control
MBGP Multicast extension to Border Gateway Protocol MBone Multicast Backbone
MOSPF Multicast Open Shortest Path First MRIB Multicast Routing Information Base
MTU Maximum Transfer Unit
Multicast One-to-many Communication OSPF Open Shortest Path First
Overhead The average number of control bits generated
Packet delay The average time required to deliver the data packets to destination PIM Protocol Independent Multicast
PIM-DM PIM Dense Mode PIM-SM PIM Sparse Mode
Reliability Refers in this report to reliable delivery of data
RFC Request For Comments
RP Rendezvous Point
RPF Reverse Path Forwarding SLA Service Level Agreement SPT Shortest Path Tree
TCP Transport Control Protocol
Throughput Average number of data bits received by multicast group members UDP User Datagram Protocol
Unicast One-to-one Communication VLSM Variable Length Subnet Masking
CHAPTER I
1INTRODUCTION
1.1 INTRODUCTION
IP multicast is an efficient way to distribute information from a single source to multiple destinations. Network resources of the existing Internet are limited and the numbers of applications that utilize the IP multicast services are rising every day. The majority of applications require reliable Quality of Service (QoS) at the cost of limited available network resources. The continuous rise of applications requiring a one-to-many communication paradigm, demands for further research of new designs and implementations of IP multicasting. Such research work can be achieved by using various simulators for easier future estimations of network growth and control over its limited resources. Among such limited resources we mention a limited IP address span, limited network bandwidth, and limited number of multicast capable routers in a network segment [56, 57, 24].
In this thesis we suggest several designs methods, and provide their implementation methods along with achieving reliable IP multicast services using the popular industrial research tool OPNET Modeler 14.5 [27, 52]. A vast majority of real-time multicast applications are based on the User Datagram Protocol (UDP). Consequently, most of the simulations presented in this report are performed using UDP as transport protocol in our design models [25, 52, 58, 64].
1.2 PROBLEM DESCRIPTION
The purpose of this work is to find out problem areas of application level multicast traffic using different routing protocols, and to find an efficient multicast path (i.e., shortest path from a multicast source to a destination) for delivering multicast related traffic [59, 60]. Problems related to path failures, survivability, group management, performance tuning, along with multicast protocol complexity are presented in this thesis through various types of build in reports from OPNET Modeler 14.5.
1.3 INTENDED AUDIENCE
Nevertheless, several chapters in this thesis are dedicated to provide some basic background information to commonly used routing protocols, configuration issues, with main focus on multicast routing protocols.
1.4 SCOPE
The scope of this thesis focuses on currently available multicast methods available in OPNET Modeler 14.5 for achieving reliable group communication, Shortest Path Tree (SPT), and reliable data delivery in Local Area Network (LAN)/ Wide Area Network (WAN) environments [55, 63, 43]. This thesis also focuses on network design, configuration issues, failure potential, and alternate route diversion for optimal path selection in case of critical network failures.
1.5 MOTIVATION
The motivation behind the design models presented in this report is to discuss issues related to aggressive traffic behavior, network congestion, heavy bandwidth utilization in relation to an ever growing IP multicast enabled and resource demanding network.
1.6 LIMITATIONS
The limitations in this project are as follows [44, 51]:
1. The multicast addressing is restricted to IPv4 only, i.e., no IPv6 is implemented in the current design.
2. Security issues are not taken into consideration in our case studies due to existing restrictions in OPNET.
3. No wireless clients or wireless technology is implemented.
4. Pure PIM-DM is not implemented due to existing restriction in OPNET. 5. IP tunneling between different zones is not implemented
1.7 STRUCTURE OF THE REPORT
This report is organized as follows:
Chapter 1 briefly explains the problem formulation, intended audience for this report, the scope of the project and its limitations, thesis structure as well as a brief history of IP multicast.
Chapter 3 presents some basic information about routing protocols, routing types, and the importance of routing algorithms. Several components of various routing protocols, ICMP message types, and error identification methods are presented here.
Chapter 4 describes multicast addressing. It describes the multicast address allocation methods, multicast address mapping methods, multicast routing protocols (PIM-SM, PIM-DM, Multicast Source Discovery Protocol (MSDP), Distance Vector Multicast Routing Protocol (DVMRP), multicast tree construction, interoperability issues, Rendezvous Point (RP) mapping, and usage of Boot Strap Routers (BSRs). This chapter also describes implementation details, transport methods, group management protocols, model architecture of IP multicast, multicast tunneling issues, and performance metrics used in our multicast simulation models.
Chapter 5 and 6 describe the proposed model designs. The simulation design models are explained with various evaluation methods available with OPNET Modeler. Several types of network traffic such as FTP, voice, video conferencing, and database traffic are generated in the designed models. Several statistics over traffic utilization are collected after simulating these models.
Chapter 7 covers the description of the implementation work with reports, and contains the analysis of different graphs, the comparison between the different routing protocols used in our models and their statistics.
Chapter 8 concludes this report and presents the work done and goals achieved. Future enhancements to this project are also explained in this chapter.
1.8 MULTICAST HISTORY
The IP multicast background history is given in Figure 1. The figure illustrates the multicast technologies ranging from approximately 1992 to 2006. The figure clearly indicates the PIM development and implementation during the period 1996 to 1998 [11].
1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
Figure 1: Multicast deployment from 1992 to 2006
MBone Overlay Multicast deployme nt
Native PIM Multicast on Production network
Native PIM Multicast Deployment in ISPs
The ever growing demand of IP multicasting capability takes a crucial role in everyday real-time streaming applications. Multicast uses UDP, so reliability must be handled by the application [20, 54]. The multicast group addressing allows different hosts to join or leave a multicast group regardless of their current place in a network topology.
In this project the multicast source is providing a variety of services such as video conferencing, FTP, VoIP, database, etc. The hosts can register with any of the services available in the network. The IP multicast solution was originally provided by using IGMP in most of the proposed designs [41].
CHAPTER II
2 BACKGROUND & RELATED WORK
2.1 BACKGROUND
Fault recovery, performance tuning of Protocol Independent Multicast (PIM) enabled native IP multicast networks is extremely complex to attain in both LAN as well as in WAN environments [14]. Network performance can be improved by switching a Rendezvous Point (RP) tree to Shortest Path Tree (SPT) in multicast enabled networks [6].
Distributed decision making regarding receiver access control have influence over SPT, and provides better scalability [35].
A multicast routing protocol is more complex, as multicast traffic takes an increasing role in network traffic. Improper design models give poor network performance for real–time, multicast transmissions [15].
2.2 RELATED WORK
Fault recovery behavior depends on many factors, such as the protocols used, compatibility issues between different network devices with the environment they operate in, and in particular the multicast group management employed.
For instance, an IP video conference simulated in OPNET demonstrates the complexity behind multicast traffic forwarding, traffic engineering issues through detailed analysis, and evaluation. Simulation results show details of PIM control traffic, and provide a comparison of the end-to-end delay for video traffic. However, this report will only present one type of traffic for analyzing the multicast behavior in a LAN/WAN environment.
A distributed decision making approach allows a router other than an RP in tree decision making. A practical solution is provided for receiver access control within PIM-SM multicast routing protocol. Distributing the tree is a key management task for all RPs in a network and this approach provides predictable results.
important task of assigning multiple RPs in a network. These PIM routers assist in distributing the multicast traffic to the entire network according to the requests obtained from a particular receiver.
2.3 COMPARISON TO THIS WORK
The proposed design models in this thesis are using different routing protocols, group management, path failure recovery, performance, survivability analysis, etc. The qualitative and quantitative analysis is made using OPNET for our design models. The PIM-SM control traffic, OSPF, EIGRP, RIP end-to-end delay, network delay, throughput are presented in CHAPTER VII Results section.
The failure scenarios consider a single or multiple device failures in simultaneous attempts. The auto web page facility was utilized to make easier the understanding of a failure, and the survivability validation analysis. This thesis considers different types of real- and non real-time traffic along with video conferencing traffic. In particular the flow of multicast traffic through SPT is clearly shown in our second experiment.
CHAPTER III
3. ROUTING PROTOCOLS
Figure 1 illustrates a possible hierarchy of different routing protocols.
Routing protocols are used to route data packets with best, loop free paths. Responsibilities include adding new routes, or replacing lost ones. Routing is the process of forwarding packets from a source to a destination in systematic way. There are many routing protocols commonly used today, and most routing protocols are based on the following algorithms: Bellman-Ford algorithm, Dijkstra’s algorithm also called as shortest path algorithms.
Leas-cost-path algorithm computes the shortest path from source to all other nodes in a network, also called link state algorithm. The name link state called due to its capability of showing link status using update messages in routers. One such algorithm is Dijkstra’s algorithm, which uses an iterative procedure to find least cost paths to all destination nodes. The link state routing sends information to all directly connected links using link state packets. This algorithm provides complete cost information about each link in a network, since the least cost among the all possible paths is available. The pros behind this issue are quick response to topology changes and node failures, but suffer with computation overhead, over space requirements [69].
Bell-man ford algorithm uses two approaches in finding the shortest path, such approaches are centralized and distance vector approach. In centralized approach least cost is calculated from each node to destination nodes, and uses the same approach once per destination with multiple nodes. The repetition of iterations going to happen asynchronously or all at once. In distance vector approach each node maintains a table of information relating to distance, destination, node information. In this approach the periodically triggered updates are sent to all neighboring nodes when vector changes. This method is used in, ARPNET, RIP, DECnet and Novel IPX. The distance vector approach suffers
Routing Protocols Exterior Interior EGP BGP Hybrid Link-Vect Dist- Vect EIRGP OSPF IGRP RIP
with infinite loop, propagation delay problems which can be avoided by selecting loop-free paths, split-horizon techniques [65, 69].
A routing algorithm specifies the best path for data packets to take from a source to destination by maintaining a so-called routing table. The forwarding method of data packets is different for a connection-oriented or a connection-less service. The selection of a routing algorithm is based upon networking requirements such as accuracy, simplicity, optimality, stability, convergence, load balancing, etc. [1, 13, 55, 64].
Table 2 Routing protocol comparison
PROPERTY EIGRP OSPF IS-IS BGP
Method Advanced
Distance Vector
Link state Link state Path Vector
Summary Auto / Arbitrary Arbitrary Arbitrary Arbitrary
VLSM Yes Yes Yes Yes
Converge Seconds Seconds Seconds Seconds
Timers Update/Hello/dead
Triggered LSA refreshes every 30 min
Triggered(10/30) Triggered(60/80)
A brief comparison of several routing protocols is given in Table 2 [1, 9].
3.1 INTERIOR GATEWAY ROUTING PROTOCOLS
In Interior Gateway Routing, the routing information is exchanged within the same routing domain. IGP can be classified into three different classes. Distance Vector, Link state, hybrid routing protocol algorithms. Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP) and Open shortest Path First (OSPF) are examples of interior gateway routing protocols. Such protocols can also be divided based on their addressing paradigm, i.e., classfull or classless addressing [39, 55
3.1.1 DISTANCE VECTOR ROUTING
In Distance Vector Routing Algorithm (DVRA) the routes are selected based on the agreed distance metric between networks. The distance metric can be number of hops, or routers between them. The distance to all known networks is regularly calculated using distance vector routing algorithm. DVRA is also known as the Bellman-Ford algorithm. RIP, IGRP are examples of distance vector routing protocols [2]. In experiment I, II the RIP protocol was configured at High end servers.
3.1.2 LINK STATE ROUTING
router keeps immediate neighbor information to all other networks, as well as the best path to each destination. OSPF, IS-IS are some examples of Link state routing algorithms [2]. In experiment II all routers are configured with OSPF as routing protocol, and using OSPF’s area concept. Some of the end devices are configured with RIP as routing protocol. The reason behind the selection of RIP is because of its simplicity in configuration, widespread usage, the supportability, and low computational overhead. As the network size grows it is advisable to go for OSPF, but the complexity also increases proportionally.
3.1.3 HYBRID ROUTING
Hybrid routing protocols are balanced routing protocols which make use of both distance-vector, as well as link-state routing mechanisms for their routing and neighbor relationship to other routers in a network environment. Hybrid routing protocols allow rapid convergence and less processing power in routers.
For instance, EIGRP is a balanced routing protocol which uses a distance vector technique for a more accurate routing metric, and a link state technique for better neighbor information exchange [64]. In experiment I EIGRP is configured between the devices in each and every subnet, but BGP is configured between the three subnets.
3.2 EXTERIOR GATEWAY ROUTING PROTOCOLS
Exterior Gateway Routing Protocols (EGRP) is used to exchange routing information between different domains, e.g., Border Gateway Protocol (BGP). BGP uses a path vector algorithm [50, 54]. Path vector algorithm changes the operational behavior of the protocol by including path information to improve its convergence time. In a path vector algorithm a node receives the full-fledged path information as well as the distance from their neighbor.
BGP advertises the complete path information as a list of Autonomous Systems (AS) in its routing mechanism. Paths with loops are detected locally by creating a policies using BGP as path vector protocol. The best path computation is possible with a path vector algorithm [68]. The BGP is configured in our experiment I, between the Ronneby subnet and (Karlskrona, Karlshamn) subnets.
3.3 CLASSLESS ROUTING
Also called Classless Inter domain Routing (CIDR), allows each router interface to be configured with different networks based on arbitrary bit boundaries. Aggregation, summarization are some great features of CIDR.
3.3.1 OPEN SHORTEST PATH FIRST
OSPF is a classless open standard IETF link state routing protocol. OSPF uses flooding for updating its link state, and Dijkstra algorithm for finding the shortest least-cost path between nodes. OSPF is mostly used for intra-AS routing. OSPF uses a shortest path first (SPF) algorithm against its own topology to calculate best routes to each network. OSPF has an added advantage of fast convergence in case of configuration changes. Neighbor database can be maintained with Hello packets [9, 19].
3.3.2 BORDER GATEWAY PROTOCOL
BGP is a complex internet routing protocol of the internet. Internet service providers (ISP) use BGP to share and establish routing information among different autonomous systems. BGP is path vector protocol, in which the routing information stored as a combination of a destination and path attributes to a network destination.
BGPv1 was a classfull routing protocol, without support of route aggregation. BGP-4 supports CIDR. BGP messages are sent over reliable transport connections having a maximum BGP message size of 1024 bytes. The mode of operation in BGP is External BGP (eBGP) and Internal BGP (iBGP). eBGP is used between different ASs, whereas iBGP is used between similar ASs for exchanging BGP updates. BGP speakers establish peer relationship with each of their neighboring routers using the concept of eBGP, and iBGP [20].
eBGP, iBGP concept is implemented in experiment I, and presented in CHAPTER V SECTION 5.1.
3.4 CLASSFULL ROUTING
Used for routing packets based on the default network address boundary. The major drawback of this addressing technique is an enormous waste of IP addresses [39, 52].
3.5 STATIC AND DYNAMIC ROUTING
3.5.1 STATIC ROUTING
Static routing is secure because of well known or defined routes can only have access to particular network. [52, 55, 54]. For the sake of argument the concept of static routing also implemented in experiment I along with eBGP between neighboring routers.
3.5.2 DYNAMIC ROUTING
In dynamic routing the state of the network is dynamically propagated after each and every route update. In this method, each router has a chance to calculate the best path to a destination after receiving the new neighbor information. Dynamic routing protocols are classified into Interior Gateway routing protocols (IGP), and exterior Routing Gateway routing protocols (EGP) [7, 52, 55, 54].
3.6 ROUTING ALGORITHMS
3.6.1 GLOBAL ROUTING ALGORITHM
In global routing, the least cost path is determined from source to destination by using a shortest path routing algorithm. This type of routing algorithm has complete information about link costs, connection type, and is also known as link state routing algorithm. Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS) are some examples of link-state routing protocols. Link state has several advantages over distance vector algorithm, such as: more stable, faster convergence, faster network topology discovery, better source routing, better routing services.
Distance vector suffers from count to infinity, slower network convergence, routing loop problems [13, 21, 31]. The shortest path from source to destination is presented in experiment II, for four different types of traffic, using OSPF as main routing protocol.
The periodical exchange of routing information between neighboring routers, causes the network routing information to pass very slowly, and contributes to slower network convergence. Network convergence is indicated as change in either router status or link status. Routing loops are generated in any network due to wrong routing information that is spreading throughout the network. Routing loops are generated due to passing same information recursively or never being able to reach a destination (phenomenon also known as count to infinity) [5].
3.7 HIERARCHICAL ROUTING
The growth of routing tables and number of nodes in network creates scalability problems. The number of flooded packets will cause improper communication between routers and large protocol overhead. This is already prohibitive in today’s Internet. Several routing problems can be solved by using hierarchical routing techniques.
3.8 IP COMPONENTS
Internet addressing and forwarding are the most important components of the internet protocol. IP addressing is of two types: IPv4 [RFC 791] and IPv6 [RFC 2460, RFC 3513]. All the experiments performed in this thesis work are restricted to IPv4 addressing.
3.9 ERROR IDENTIFICATION
Internet Control Message Protocol (ICMP) is an error and information reporting protocol. It can be used by Packet Internet Gopher (PING) command to send ICMP echo request, echo response messages, and to check connectivity between hosts and routers and is used by communicating parties to retrieve network related information.
Foremost, ICMP is used for error reporting. Several examples of more general types of network related information possible through ICMP are: “Destination host unreachable”, “Unable to find path to host”, “Destination host unknown”, and “Time to Live (TTL) expired”. The connectivity between different network devices was tested in this thesis using the PING command [3, 66].
3.9.1 ICMP MESSAGE TYPES
ICMP message types are classified as either error messages or queries and responses and are presented in Table 3 [66].
Table 3 ICMP Message Types
ICMP Type Code Description
0 0 Echo reply to ping
3 0 Destination N/W unreachable
3 1 Destination host unreachable
3 2 Destination protocol unreachable
3 3 Destination port unreachable
30 6 Destination network unknown
3 7 Destination host unknown
4 0 Congestion control
8 0 Echo request
9 0 Route advertisement
CHAPTER IV
4 MULTICAST ADDRESSING
According to Internet Assigned Numbers Authority (IANA) the assignment of IP multicast addressing is given in Table 4 and Table 5. A class D address space is indicated by the high order 4 bits set to binary 1110 as illustrated in Figure 2.
Class D address range for IP Multicast is from 224.0.0.0 – 239.255.255.255. All multicast addresses have to be within the limits defined for Class D. This address range is only for the group address or destination address of IP multicast traffic [23, 20, 47].
28 Bits
1 1 1 0 Multicast Group ID
Figure 2 class D range IP Multicast
Table 4 Multicast Range and description
Starting Range Ending Range Description
224.0.0.0 224.0.0.255 Locally Scoped
224.0.1.0 238.255.255.255 Globally Scoped
239.0.0.0 239.255.255.255 Limited Scoped
Locally scoped addresses are only for network protocol use, and routers will not forward data related to locally scoped addresses. These are also used for stateless auto configuration of hosts. Multicasts in locally scoped addresses are never forwarded off the local network.
Table 5 Reserved Multicast addresses
S No Reserved Multicast Address Description
1 224.0.0.1 All Multicast enabled systems in a network
2 224.0.0.2 All Multicast enabled routers in a network
3 224.0.0.4 All DVMRP (Distance vector Multicast ) routers
4 224.0.0.5 All OSPF routers
5 224.0.0.6 All OSPF Designated Routers
6 224.0.0.9 All RIPv2 routers
7 224.0.0.10 All EIGRP routers
Table 5 illustrates the IANA recommended reserved link local addresses for network protocols on a local network segment. Packets with these addresses should never be forwarded by a router but instead should remain local to a particular network segment.
Globally scoped addresses are assigned dynamically over the internet. The 224.2.X.X address range is used by Multicast Backbone (MBone) applications. The MBone concept was introduced by IETF in 1992 for the purpose of supporting applications using a large number of users using audio and video meetings through a virtual multicast channel. The routers enabled with multicast features are called MBone routers.
Encapsulation of multicast packets inside IP packets, and transferring the multicast data over the existing physical media through tunneling within the islands of MBone subnets is a never-ending demanding feature for ubiquitous multicast applications. Normal IP routers that are disabled with multicast capability for the sake of bandwidth tracking, and billing can make use of MBone concept to provide multicast services over Internet [34].
4.1 MULTICAST ADDRESS ALLOCATION
4.1.1 DYNAMIC ALLOCATION
Used for group addresses on demand allocation to multicast applications. It provides addressing for a specified life time according to need and demand. Applications are allowed to get this type of addressing depending on their needs [52].
4.1.2 STATIC ALLOCATION
Well known addressing scheme for specific protocols. It is specifically assigned by IANA, for global inter-working. Addressing schemes are used for specific protocols [52, 47].
4.2 MULTICAST ADDRESS MAPPING
IEEE 802.3 MAC Address structure is illustrated in Figure 301-00-5E 0
Figure 3 IEEE 802.3 MAC Address structure
OUI 23bits
These fields are defined as follows:
OUI: Organizational Unique Identifier is always 01-00-5E.
Multicast MAC address is derived from the IP multicast address. The destination IP address of IP multicast packets maps to a multicast MAC address [52].
4.3 MULTICAST ROUTING PROTOCOLS
4.3.1 MULTICAST ROUTING PROTOCOLS
The multicast routing protocols have a major role in constructing a distribution tree in order to forward multicast packets. The basic approaches in most multicast protocols for building distribution trees are Sparse Mode (SM) and Dense Mode (DM) [24, 26, 34, 67].
4.3.2 PROTOCOL INDEPENDENT MULTICAST VERSIONS
PIMv1 · Provides automatic RP discovery with Auto-RP (Cisco proprietary)
PIMv2 · Automatic RP discovery is accomplished by the bootstrap router method (standards based)
4.3.3
PROTOCOL INDEPENDENT MULTICAST
The Protocol Independent Multicast (PIM) is independent of the unicast routing protocols that are already running in a network. In addition PIM is also the most widely used internet multicast routing protocol. The PIM in conjunction with MBGP (Multicast extension to BGP) provide scalable multicast solutions to enterprise wide multicast-enabled networks.
The PIM router does not participate in updating the routing information. MBGP uses BGP to keep additional Routing Information Base (RIB) for protocols other than IPv4 unicast. Multicast RIB (MRIB) allows unicast and multicast routing to exist at same place when performing RPF check [20, 26, 51, 53, 54].
4.3.4 MSDP
Multicast Source Discovery Protocol (MSDP) can be used to connect RPs between different SM domains. Each PIM SM domain uses its own RP and need not depend on other RPs in different domains [5].
Tree construction protocol: PIM-SM, PIM-DM, SPARSE-DENSE MODE
Table 6 PIM operation
Mode of Operation Description
PIM-DM Tree initializations with all MC enabled routers and prune back the branches if IGMP is absent.
PIM-SM Tree with a shared point called RP (Rendezvous point) between source and destination
Table 6 [51] illustrates the PIM mode of operation and their description.
4.3.5 DENSE MODE PROTOCOLS
PIM Dense Mode (PIM-DM) is mainly designed for multicast LAN applications based on source trees. Uses a technique called flood and prune in order to stop sending multicast packets to stations no longer interested in receiving multicast traffic. Best suited in an environment where there are a number of hosts waiting to receive multicast data and with a need to cope with the flooding in that network segment.
PIM-DM initially floods traffic out of all non-RPF interfaces where there is another PIM-DM neighbor or a directly connected member of the multicast group. As each router receives multicast traffic via its RPF interface (the interface in the direction of the source), it forwards the multicast traffic to all of its PIM-DM neighbors. This approach results in some traffic arriving via a non-RPF interface. When this happens, the packets arriving via the non-RPF interface are discarded.
Prune messages are also sent on non-RPF interfaces to shut off the flow of multicast traffic. Prune messages are sent on an RPF interface only when the router does not have any downstream receivers for multicast traffic. In PIM-DM, all prune messages expire in 3 minutes. After that, the multicast traffic is flooded again to all of the participating routers. This periodic flood-and-prune behavior is normal and must be taken into consideration when the network is designed to use PIM-DM. PIM-DM can use unicast routing tables populated through OSPF, IS-IS, BGP, or they could use a special multicast RPF table populated by MBGP or M-ISIS when performing RPF checks [54, 61, 62, 64].
4.3.6 DISTANCE VECTOR MULTICAST ROUTING PROTOCOL
DVMRP is the oldest and most widely used reverse path flooding multicast protocol of internet. DVMRP functions within an autonomous system (AS) and routes multicast datagram’s within an AS only, but not between Autonomous Systems. Uses reverse path flooding to forward multicast data, and pruning to reduce the amount of traffic sent [5].
4.3.7 SPARSE MODE PROTOCOLS
PIM Sparse Mode (PIM-SM) is defined in RFC 2362. PIM-SM uses shared multicast distribution trees, but it can also switch to the SPT. In PIM-SM traffic is forwarded only to those parts of the network that need it. PIM-SM uses an RP to coordinate forwarding of multicast traffic from a source to receivers. Senders register with the RP and send a single copy of multicast data through it to the registered receivers.
Currently this is the most scalable IP multicast routing protocol. In this case, group members are spread sparsely throughout the network. Flooding may still cause unnecessary bandwidth and performance problems. The empty distribution tree starts with adding its branches depending upon the request from hosts. Information is passed from a sender to a receiver by using a common point called RP. Receivers always need to register with the RP in order to request data from the multicast source. The optimized path from sender to receiver is always calculated in SM environment.
PIM bidirectional mode is designed for many-to-many applications. Source Specific Multicast (SSM) is a variant of PIM-SM that builds only source-specific SPTs and does not need an active RP [20, 34, 51, 52].
Interoperability: PIM-SM, PIM-DM, and DVMRP can operate at same time by using these protocols on same interface either by using IPv4 or IPv6 addressing. In DM the multicast source broadcasts the data throughout the network and prunes back the unwanted branches, where as in SM the requested receiver is only eligible to receive multicast data.
Rendezvous Point (RP): RP is a central place where all senders and receivers start sending their multicast information. Receivers always have to send a join messages to RP and senders start sending according to the request from respective hosts. RP is always placed at an optimal point in a network. SPT switch occurs automatically after the first transmission attempt [51, 52].
Characteristics of an RP:
1. Defined on all multicast enabled routers 2. Reachable to all sources and destinations 3. Optimal location in a network.
Groups to RP mapping
There are several possible ways for mapping between multicast groups and RPs, as follows:
Static RP: It must be configured on all routers. The configuration information is local to the router and there is no protocol that propagates this information to the network. At least one static RP must be configured for a multicast group operating in SM [51, 52].
Auto RP: A Cisco proprietary protocol must be configured with candidate RPs called mapping agents. Cisco’s reserved address space assigned by IANA for this purpose is: 224.0.1.39 for announcements, and 224.0.1.40 for discovery. It simplifies the process of automatic distribution of RP to group mapping for different multicast groups. Auto RP avoids miss-configuration issues between similar RPs, or between mapping agents. A Cisco router automatically listens for RP related information. Mostly used with PIM DM or with PIM sparse-dense mode only [51, 52].
Redundancy through RP configuration methods: static RP cannot provide any redundancy. Auto RP and BSR may provide some redundancy in a different way. Similar to auto-RP, candidates RPs are configured and the information is propagated to the network. This approach supports PIMv2 and above [24, 36, 39].
4.3.8 PIM SPARSE-DENSE MODE
Maximum efficiency can be achieved by keeping multiple RPs at optimal locations. This approach with multiple RPs is complex to configure and to trouble shoot. PIM Sparse-Dense-Mode comes up with a feature of auto selection RPs for each multicast scenario. PIM Sparse-Dense-Mode solves several problems such as scalability, heavy router resource consumption of PIM-DM, and the limited configuration issues of PIM-SM.
PIM-Sparse-Dense-Mode mostly takes the DM features, so automatic RP discovery is implemented. This method also permits auto RP, BSR, along with statically defined RPs.
Figure 4 PIM Sparse-Dense Mode
The above figure 4 [20 (module 7.3.7, Figure 1), 53] illustrates two multicast sources each with RPs in an optimal location. The PIM sparse-dense mode is difficult to configure, manage, and troubleshoot through manual configurations of RPs. PIM sparse-dense mode supports automatic selection of RPs for each multicast. Router A in the figure could be the RP for source 1, and router F could be the RP for source 2.
Designated Router:
Controls the multicast routes on a directly connected network. The router with highest IP address becomes the DR when more PIM routers are present in a network [5, 52].
4.4 ROUTING MULTICAST TRAFFIC
Identifying multicast traffic is more complex than unicast or broadcast because the multicast enabled routers has to translate multicast addresses to host addresses. The routers must interact with each other in order to exchange their status to neighboring routers and to establish shortest path among them. Before forwarding multicast traffic, the establishment of distribution trees among designated routers and multicast enabled devices is mandatory. The tree process may be performed in several ways, but the most common approaches are: source specific tree and shared tree.
Source Specific Tree: Multiple delivery trees are built from a source to the receivers. Most of the trees build a shortest path from source to receiver.
Shared tree: The path is shared by different receivers and senders originating in one common point also called RP.
Pruning: The heavily flooded multicast traffic or unwanted traffic can be removed by using a technique called pruning.
PIM-DM: uses the technique called flood and prune reverse path forwarding [51, 54, 57].
4.4.1 TRASNPORT PROCOCOLS AND MULTICASTING
In TCP/IP architecture, the two transport layer protocols have a major role in information transmission. The TCP guarantees data transmission whereas UDP does not guarantee data transfers but it is faster. UDP is a connectionless, unreliable mechanism which does not provide the ordered delivery of packet contents. A vast majority of multicast applications use UDP as transport layer protocol which also implies that multimedia applications are error prone. Meantime, little delay is also observed with these applications.
conferencing, software upgrades to large group of receivers, gains an added advantage over UDP related multicast transmission. FTP transmissions by using multicast transmission have an advantage of lower network bandwidth usage.
Multicast transmission is used for better bandwidth utilization, less host/router processing, simultaneous delivery of data streams [4, 64].
4.5 MULTICAST FORWARDING
Multicast sources send traffic to arbitrary group of hosts specified in the destination address field of an IP packet. All multicast capable routers must create a distribution tree in order to control the IP multicast flow before sending multicast traffic in a network. All multicast routing protocols make use of Reverse Path Forwarding (RPF) check so as to decide whether to forward or drop IP multicast packets.
Switches forward frames based multicast MAC addresses at layer L2. A multicast router always forwards data from a source (upstream direction) source to participating receivers (downstream direction) after performing the RPF process [51].
4.6 MULTICAST TRAFFIC ENGINEERING
The traffic flow in multicast enabled networks depends on various factors. The most common issues are as follows [51]
a) RP Position in a network
b) The multicast routing configuration c) IP Unicast routing table
4.6.1 RP POSITION
Optimal placement of a RP in a network is necessary in ordert to get best performance in a network. RP placement takes a crucial role when the router default behavior is changing. In our scenarios, experiment I have three RPs defined while experiment II has one RP defined.
4.6.2 MULTICAST ROUTING CONFIGURATION
Depending upon the demands and performance analysis on throughput the interface configuration has to be changed. Most of the newest network devices come with extensive support to multicast configuration capability.
4.6.3 DEPENDENCY ON UNICAST
4.7 IGMP
The multicast data flow between two IP sub-networks can be controlled by Internet Group Management Protocol (IGMP) for allowing receivers subscribing to a particular multicast group. IGMP is an integral part of IP. Hosts that want to receive multicast data have to inform their immediate neighboring routers their interest in a multicast transmission through IGMP messages. A multicast enabled router periodically checks for new group members on each configured network. Hosts use IGMP to register with the router such as to join and leave a specific multicast group. By using IGMP multicast routers keep track of multicast memberships. There are three versions of this protocol [24, 27, 49, 51].
4.7.1 IGMP v1
The multicast enabled routers query periodically with 224.0.0.1 multicast address in order to check hosts that are in queue for multicast traffic. Here, the router cannot identify itself the host that left from a particular multicast group. In this version IGMP messages are of fixed size and encapsulated in IP datagrams. Widely deployed version on internet [49, 53, 64].
4.7.2 IGMP v2
This version comes with special message called IGMP leave message from hosts no longer interested in multicast traffic. Added support for low leave latency, routers can find the hosts that are not really interested in group membership. Here, queries are sent to specific multicast group instead of sending to all host address [41, 46, 49]. Most of the experiments in our thesis are using IGMP v2 as group management protocol.
4.7.3 IGMP v3
The matured version of IGMP, come up with a special feature of intimating the nearby router by saying which source a particular host can accept a multicast message along with the available feature of intimating their membership report. Source filtering, expressing the interest in receiving data from a particular source, support for SSM. Version 3 is interoperable with versions 1 and 2 [49, 53, 64].
4.7.4 IGMP MESSAGES
There are three types of IGMP messages. They are query, member ship report, and leave report. The group multicast address is treated as membership report.
Host membership query: all systems in a particular network are addressed with 224.0.0.1 as standard address.
These membership messages are further divided into 2 subtypes
a) General query: Groups that have membership on a bounded network can learn about group membership with the help of general queries.
b) Group specific query: Group membership can be learned with the help of group specific queries, i.e., whether a specified group has members on a bounded network [52].
4.7.5 IGMP PROTOCOL OPERATION
A host sends an IGMP report message when it joins a multicast group. No report is sent when a host leaves a group, after sending the first message. A multicast router can multicast at regular intervals with an IGMP query to all hosts. The interested host can send an IGMP report message as response.
4.8 CGMP
Cisco Group Management Protocol (CGMP) is a protocol developed by Cisco which allows the Catalyst switches to learn from Cisco routers and layer 3 switches about the existence of multicast clients from other Cisco routers and layer 3 switches. Cisco Catalyst switches make use of CGMP to forward layer 2 information based on IGMP operations. With CGMP running, any router receiving a multicast join message via a switch will reply back to the switch with CGMP join message [20].
CGMP is a legacy multicast switching protocol. CGMP is not compatible with IGMPv3. Denials of Service (DoS) attacks are possible on the CGMP enabled switches. The latest switches support IGMP instead of CGMP because of lack of security, flood control, etc [68].
CGMP imitates the client/server paradigm, where the router is considered a CGMP server and the Switch is considered a client. CGMP packets contain information about join and leave messages, MAC address of IGMP clients, and multicast MAC address of the multicast group [1].
Figure 5 CGMP Operation with Routers and switches
Figure 5 [20 (module 7.2.7, Figure1)] illustrates the CGMP operation on routers and switches.
4.9 IP MULTICAST MODEL ARCHITECTURE & MULTICAST
OPERATIONS
The IP Multicast model suite contains the following processing models defined inside its layer technology. The IP Multicasting is implemented by using the process models presented in Table 7 [49, 51].
Table 7 IP Multicast Model Architecture
Process Model Description
Ip_igmp_host To implement IGMP in hosts
Ip_igmp_rte_intf To implement IGMP in routers
Ip_igmp_rte_grp IGMP implementation routers for every multicast group in a defined network
Ip_pim_sm To implement PIM-SM in router nodes
Figure 6 IGMP Group joining Procedure Figure 6 [51 (Figure 14.37)] illustrates the group joining procedure.
Applications join a multicast group, by sending a join request to the ip_igmp_host_process. The ip_igmp_host process sends an IGMP membership report to neighboring routers. The ip_pim_sm process sets up a distribution tree, and starts sending packets to the designated group.
4.9.2 SENDING TRAFFIC TO A GROUP
Error!
Figure 7 [51 (Figure 14-38)] describes the multicast traffic forwarding by using a broadcasting method between sender and broadcast interface.
Applications start sending packets to a multicast group. Router forwards the multicast packets to the ip_pim_sm process. The ip_pim_sm process on the router creates and sends one packet of the multicast packet for each out interface as specified in the routing table.
4.9.3 MULTICAST TUNNELING
Multicast Tunneling:
Tunneling is very useful in case of a lack of contiguous connectivity between multicast routers. The idle link for multicast traffic also provides security. Multicast traffic can also be encapsulated by using two techniques. Tunneling provides added advantage of load splitting: DVMRP tunnels and GRE tunnels [64].
4.9.4 DVMRP TUNNELS
Cannot be used between two Cisco routers. Between a Cisco router and another DVNRP router this is possible.
4.9.5 GRE TUNNEL
Can be used between two Cisco routers, and resembles a point to point connection.
4.9.6 MULTICAST APPLICATIONS
The following multicast applications are simulated in this report: Video conferencing, FTP, Database, Voice.
4.9.7 PERFORMANCE METRICE IN MULTICASTING
The following performance metrics are evaluated in this thesis: Throughput
The average number of data bits received by multicast group members (per second). Overhead (Bits/sec)
The average number of control bits generated (per second) by all nodes in a network. Hop count
The total number of hops necessary to reach the multicast destination.
CHAPTER V
5. MODEL DESIGN I
5.1 MODEL DESIGN EXPERIMENT 1
Figure 8 New model design experiment I
Figure 8 illustrates the topology used for experiment 1 with 3 subnets located at different places: Ronneby, Karlskrona, and Karlshamn.
Figure 9 Ronneby subnet
Figure 9 shows the ISP connected interface for Ronneby having the following configuration: eBGP running between ISP and Ronneby.Karlskrona.junction, ISP and Ronneby.Karlsham.junction router. iBGP Running between junction routers, i.e., ISP-SANJOSE1, ISP-SANJOSE2.
Figure 10 Karlsham Subnet
Figure 11 Karlskrona subnet with R1 as RP
Figure 11 illustrates the Karlskrona subnet with end devices each connected to their respective switches.
CHAPTER VI
6 MODEL DESIGN II
6.1 DESIGN MODEL EXPERIMENT II
Figure 12 New Model Design Experiment II
Figure 12 illustrates the new model design for Experiment 2. The topology describes the type of routing used between the interconnected devices, and the services involved, along with group management concepts.
CHAPTER VII
7. SIMULATION RESULTS AND ANALYSIS
7.1 EXPERIMENT I
Figure 13 New design model topology I
7.1.1
INTRODUCTION TO NEW DESIGN AND SCENARIO EXPERIMENT I
The whole network is designed by using CISCO AS5100 series routers: 3 in Ronneby, 6 routers in Karlskrona, 6 routers in Karlsham along with 2 CISCO Catalyst 3524-PWR XL switches. A total of 5 RP routers are selected for the whole network.
Routing between the different subnets is static routing. EIGRP is configured for running inside the Karlskrona and Karlsham subnets. Some of the servers are enabled with RIP according to scenario requirements. The application configuration is configured with default applications which supports near 16 applications, and the profile configuration is configured for Database and FTP traffic only. FTP Heavy, FTP Low, Database (Heavy), Database (Low) is simulated in the designed network, and the given interfaces are designed with PIM-SM at each interface.
The applications operation mode is assigned as Simultaneous, and start time is set to Constant (100). The simulation duration is set to End of Simulation.
The application start time offset is set to uniform (0, 300), and duration is set to End of Simulation. The end hosts are changed according to scenario definition. Every simulation scenario is taken in different styles for a clearer analysis.
There are 4 types of analysis available for this design, as follows:
1. Discrete Event Simulation 2. Flow Analysis
3. Net Doctor Report 4. Survivability Analysis
The performance of PIM-SM enabled network can be estimated after collecting different statistics. The PIM-SM statistics such as control traffic sent, received, network convergence duration, EIGRP, BGP, etc. are collected along with other performance statistics.
Ronneby subnet routing information in detail
Figure 14 Routing between devices in Ronneby
Figure 14 illustrates the routing information through e.g., using the show ip route command from different routers of the Ronneby subnet. This figure also describes the routing between these devices, including interface information in details.
Figure 16 Karlskrona Junction routing information
The ISP router information is shown in Figure 16. This figure illustrates the neighbor relations with the loopback interface details of interconnected interfaces. Also shown in this figure is the BGP information.
Figure 17 Connectivity between devices from Karlskrona Junction
The Karlsham junction configuration in detail
Figure 18 Karlsham junction routing information
The statistics were collected by varying traffic information between the links. The variation of these parameters is shown in different graphs for clearer analysis. The DES (Discrete Event Simulation) is designed in such a way to collect Flow analysis, Net doctor Reports, and Survivability Reports.
Discrete Event Simulation
Figure 19 Global IP statistics summary in Exp I
Figure 20 Global statistics PIM-SM summary
Figure 20 illustrates the PIM_SM control traffic sent and received (packets/sec). A little loss of less than 1.5% control traffic observed. This loss in control traffic causes the controlling task to fail between the devices, and it will be resumed in the next attempt.
Figure 21 Global statistics summary BGP
Figure 22 Global statistics EIGRP summary Point to Point Queuing Delay between the devices in Karlsham subnet
Top Objects Report: Point-to-Point Queuing *Delay (sec)
Rank Object Name Minimum Average Maximum Std Dev ---- --- --- --- --- --- 1 Karlskrona_LAN <-> SWITCH [0] --> 0.0072349 0.78418 1.1555 0.52571 2 Karlskrona.R5 <-> R4 [0] --> 0.0025000 0.10804 1.1064 0.25693 3 Karlskrona.R1 <-> R2 [0] --> 0.0025000 0.08469 1.1053 0.23286 4 Karlsham.R9 <-> R10 [0] --> 0.0025000 0.08437 1.0421 0.22275 5 Karlskrona.R5 <-> R6 [0] --> 0.0025000 0.08245 0.9812 0.21376 6 Karlskrona.R5 <-> R4 [0] <-- 0.0025000 0.08064 1.1020 0.23312 7 Karlsham.R10 <-> R11 [0] --> 0.0025000 0.07976 1.0924 0.21908 8 Karlsham.R11 <-> R13 [0] <-- 0.0025000 0.07746 1.0201 0.21120 9 Karlsham.R10 <-> R11 [0] <-- 0.0025000 0.07406 0.9875 0.20135 10 Karlskrona.R4 <-> R2 [0] <-- 0.0025000 0.07147 1.0506 0.20909
Figure 23 Point-to-point queuing delay between major devices
The Average Traffic sent and received in Packets/sec in experiment I
Top Objects Report: Traffic Sent (packets/sec)
Rank Object Name Min Average Maximum Std Dev ---- --- --- --- --- --- 1 R10 --> R2 0 11.210 108.09 31.765 2 R11 --> R5 0 11.057 105.67 31.494 3 R1 --> Sanjose1 0 10.965 105.10 31.188 4 R6 --> R13 0 10.956 104.44 31.131 5 Sanjose2 --> R5 0 10.940 108.12 31.141 6 Sanjose1 --> R1 0 10.930 105.99 31.123 7 R12 --> R13 0 10.887 105.63 31.040 8 R11 --> R6 0 10.866 104.21 30.934 9 R1 --> R2 0 10.850 105.79 30.903 10 R13 --> R4 0 10.804 105.01 30.844
Top Objects Report: Traffic Received (packets/sec)
Rank Object Name Min Average Maximum Std Dev ---- --- --- --- --- --- 1 R12 --> R13 0 5.9170 56.120 16.857 2 R1 --> R2 0 5.9098 59.344 16.861 3 R2 --> R6 0 5.7426 56.150 16.399 4 R6 --> R5 0 5.6695 56.548 16.193 5 R9 --> R10 0 5.4788 56.578 15.902 6 R5 --> R2 0 5.4443 55.099 16.026 7 R3 --> R2 0 5.0859 55.536 15.407 8 R13 --> R10 0 5.0316 55.678 15.239 9 R10 --> R11 0 4.8782 57.109 15.215 10 R14 --> R13 0 4.7890 56.153 15.243
Figure 24 Traffic Sent /Received in packets/sec
Figure 24 illustrates the maximum traffic sent (108.12 packets/sec) between the network objects
Sanjose2 --> R5. The maximum traffic received was 59.344 (packets/sec) between R1 --> R2. The
figure also shows the maximum standard deviation (Std Dev) of 31.765 for the traffic sent, and 16.857 for the traffic received.
I.
Flow Analysis
Figure 25 Flow analysis Exp 1
Figure 25 illustrates the flow analysis executive summary. The number of successful demands, failed routes can be found with the help of flow analysis. The figure also illustrates the link maximum utilization (67%), and the average utilization (22.8%).
Node configuration shows the routing information configured on particular devices. The figure also describes that there are 47 interfaces configured with the IPv4 addressing scheme, out of which 34 interfaces are configured with EIGRP routing, and 3 with BGP on the main links.
II. Net Doctor
The given topology was checked for the given rules and summaries. The following rules are checked and success rate show up with a green ticking on left side. The services not used in this work are showed with N|A symbol (i.e., not available).
