In this thesis OPNET Modeler 16.0 is chosen for imitating the webs. The simulation consequences are obtained and they are analyzed for decision. The simulation is carried out in six stairss.
Measure 1: In the first measure a web topology is designed for both ATM and MPLS webs.
Measure 2: The voice traffic is sent from beginning ( Caller ) to finish ( Callee ) nodes.
Measure 3: The remainder background traffic are transmitted from other nodes to the waiter.
Measure 4: Once the topology is set, the simulation is ran for 2 hours.
Measure 5: The public presentation prosodies such as Voice End-to-End hold, Voice Jitter, Voice package sent and received are obtained diagrammatically after 2 hours of simulation.
Measure 6: On analysing the consequences provinces which web is more efficient for implementing VoIP application. The consequences of other background traffic are shown in the appendix.
5.3 NETWORK DESIGN
Harmonizing to step 1 a web topology is designed for both ATM and MPLS webs. The simulations are carried out in two different fortunes.
Implementing VoIP application in ATM web including some background traffic and ATM web constituents.
Implementing VoIP application in MPLS web including the same background traffic used in ATM web and besides including MPLS web constituent.
Both the web has a similar topology, architecture, design, background traffic and lines linking each single constituent. But both the webs differ in their constituent used for planing the topology.
5.3.1 ATM SIMULATION DESIGN
The design below shows the topology of ATM web and all the other constituents in the web, which is designed in OPNET Modeler 16.0.
Degree centigrades: UsersKumarDesktopATM_VoIP.png
Figure: ATM web design with its constituents and all the background traffic each carries different traffic severally.
Figure 9 shows the ATM web topology consisting of the undermentioned listed constituents.
There are seven nodes directing FTP, HTTP, TCP, UDP, Video and download petitions to the waiter severally.
A VoIP Caller directing voice traffic to the Callee.
Two switches ( Switch_1 and Switch_2 ) severally.
Two Ethernet routers ( Ingress and Egress ) severally.
Two ATM routers ( ATM_1 and ATM2 ) severally.
Server reacting to the petition sent by all nodes.
In the above topology 10baseT Ethernet links are given that is 10Mbps velocity linking all the elements in the web. An IP_Traffic_flow is set between the nodes and the waiter, each nodes transporting assorted types of traffic flows consequently. The routing protocol used in this web is OSPF. The chief end for puting this background traffic is to look into the public presentation of the web. Voice traffic is set between the Caller and the Callee whose public presentation is traveling to be analyzed.
5.3.2 MPLS SIMULATION DESIGN
Degree centigrades: UsersKumarDesktopMPLS_VoIP.png
Figure: MPLS Network design and its constituents and all the background traffic that carry the same traffic like in the ATM web.
Figure 10 shows the MPLS web topology and its elements. The topology is similar to ATM topology but alternatively of ATM web a MPLS web is designed. The MPLS web consists of the undermentioned constituents.
Two LER ( LER_Ingress and LER_Egress ) severally, and
Two MPLS routers ( MPLS_1 and MPLS_2 ) severally.
The links are all the same except inside the MPLS web, PPP_DS3 line is used in the MPLS web. The MPLS web has LER and MPLS routers which uses a CR-LDP routing technique that helps the packages to travel through the web expeditiously. The TE is implemented in the MPLS utilizing CR-LDP protocol. This type of routing technique makes real-time applications to be implemented in the webs without any perturbation. The voice traffic is set between the Caller and Callee as mentioned in the ATM web. The public presentation of this web is besides analyzed.
5.4 IMPLEMENTING VoIP TRAFFIC IN THE NETWORK
In order to implement VoIP traffic in both the webs, a Demand Model is selected in OPNET Modeler. In the demand theoretical account there is an option for choosing peculiar traffic that need to flux in the web. The Voice traffic between Caller and Callee and other background traffic are set utilizing the Demand Model.
Degree centigrades: UsersKumarDesktop1.png
Figure: Demand Model used in OPNET Modeler for choosing the peculiar traffic to flux in a line.
Figure 11 shows the Demand Model of the OPNET simulator. There are several theoretical accounts but in this thesis Voice and other IP traffic are used. Here the IP_G711_Voice traffic is used for stand foring VoIP traffic flow specified between the Caller and the Callee. This voice traffic uses DSCP to configure the QoS. The several other traffic are used by the other nodes such FTP, HTTP, TCP and other background traffic.
5.4.1 EDITTING TRAFFIC ATTRIBUTES
The figure below shows the traffic attributes of voice traffic and it is edited utilizing the OPNET Modeler. The nexus between Caller and Callee in which the voice traffic flows is edited.
Degree centigrades: UsersKumarDesktop r.png
Figure: VoIP Traffic Attributes used in OPNET Modeler used to redact the traffic velocity and packages to flux in a peculiar line.
Figure 12 shows the properties of VoIP traffic used in the simulation theoretical account. The G711Voice_bps is the velocity of the traffic sent to the Callee and G711Voice_pps is an property that sends 250 packages per second to the Callee. The G711 encoder strategy is a type of service used by VoIP application for implementing voice calls. The properties for other background traffic are applied in the same manner but the same encoder strategy is non used for other traffic.
After implementing voice traffic and redacting their properties the simulation is run for 2 hours i.e. both the scenarios for 2 hours clip. If running clip of the simulation is set high than the consequences are more efficient.
6. RESULTS AND ANALYSIS
6.1 COMPARISON OF VoIP TRAFFIC
The public presentation of VoIP service is compared so by utilizing the consequences obtained by the simulation, the consequences are obtained diagrammatically by OPNET Modeler 16.0. The undermentioned figures 13, 14, 15 and 16 shows the graphs of public presentation prosodies such as voice end-to-end hold, voice jitter, and voice package sent and received. As mentioned above the continuance clip is 2 hours, the simulation starts after several proceedingss, this is due to that the packages foremost look into the nexus and other set up before get downing and terminals after 2 hours.
Degree centigrades: UsersKumarDesktopsent.png
Figure: voice packages sent from Caller and Callee of both ATM and MPLS webs.
Figure 13 shows the mean figure of packages sent to the VoIP_Callee node in both ATM and MPLS webs. The simulation of both ATM and MPLS webs that ran for 2 hours heroic poems that the packages sent are about same in both ATM and MPLS webs, including all background traffic every bit good. So there is no package loss while directing the packages, the packages losingss is non the large drawback in the VoIP application, there should be minimal hold and jitter in the webs. The public presentation of the web can be analyzed with the aid of these public presentation prosodies.
When a Caller makes a call to the Callee, if there is a immense hold of packages so there will non be good communicating between them. The information what Caller wants to convey to the Callee will non be heard by the other terminal. If the jitter that is the interruption in the packages arrival clip is high so there is perturbation in the communicating. This jitter is chiefly caused due to web congestion and the congestion is due to high background traffic.
Degree centigrades: UsersKumarDesktop
Figure: voice traffic received at the Callee in both ATM and MPLS webs.
Figure 14 shows the mean figure of packages received at VoIP_Callee node in both ATM and MPLS webs. The graph heroic poems that the voice traffic received are all most same in both the webs.
Degree centigrades: UsersKumarDesktopete delay.png
Figure: Comparison of voice end-to-end hold or latency of the voice traffic in both ATM and MPLS webs.
Figure 15 shows the voice packages end-to-end hold of both ATM and MPLS webs. For a good web that uses VoIP application the package end-to-end hold must be less than 50 msecs as explained in chapter 2.1.4. If the web goes over the bounds so that peculiar web is non suited for implementing VoIP application. Here in this graph the ATM web possess more end-to-end hold when compared to MPLS web. This proves that ATM web is non much suitable for implementing VoIP application when compared to MPLS.
Degree centigrades: UsersKumarDesktopjitter.png
Figure: Comparison of voice jitter in both ATM and MPLS webs.
The figure 16 shows the voice package jitter for both ATM and MPLS webs. As discussed in the chapter 2.1.4, the jitter for implementing VoIP application in the web should n’t be more than 2 msecs. But the graph obtained from the simulation heroic poems that ATM web posses more jitter that the MPLS web, therefore impacting the QoS of the web. This is because of the TE in the MPLS routers which is implemented by CR-LDP and RSVP protocols and moreover MPLS uses CR-LSP for puting the way to the packages to flux efficaciously within the web. Therefore this proves that ATM web does n’t supply good QoS in VoIP application when compared to that of MPLS web.
7 CONCLUSIONS AND FUTURE WORK
The mail end of this thesis to compare the public presentation of VoIP services in both ATM and MPLS webs and to turn out that MPLS web performs better than the ATM web. The public presentation is compared by the consequences obtained from the OPNET simulator. It is analyzes by the graphs of public presentation prosodies such as voice hold, voice jitter and voice package sent and received.
There are assorted stairss followed to finish the thesis, to get down with for finishing this thesis a literature reappraisal is made on VoIP, ATM and MPLS and how to implement the VoIP application in both webs. From the background study it tells that real-time applications are non efficient in web possessing high hold and jitter. So the MPLS web dwelling of TE implemented by CR-LDP and RSVP routing protocols posses less hold and jitter when compared to ATM web, this has been proved diagrammatically by OPNET simulator. Then the web topology is designed in OPNET Modeler 16.0 and the simulation consequences made us to accomplish the end i.e. MPLS web performs much better than the ATM web.
7.2 FUTURE WORK
In this thesis we chiefly concentrated on the public presentation of VoIP traffic in both MPLS and ATM webs including the background traffic. For future work this can be checked with video application. Here in this thesis MPLS is merely implemented including TE which is implemented by signalling protocols such as CR-LDP and RSVP and so mensurating the public presentation of VoIP and for future picture applications like picture conferencing can be measured utilizing these protocols. Here in this thesis high velocity links are used for connexion within the web for future the information rate of the links can be reduced and so public presentation can be measured.
8. BIBLIOGRAPHY AND APPENDIX
BOOKS and ARTICLES
1. Performance Comparison of IP, MPLS and ATM Based Network Cores utilizing OPNET. Asif, H.M. and Kasor, M.G. 2006, Institute of Electrical and Electronics Engineers. , pp. 1-5.
2. Jannu, K.P. and Deekonda, R. OPNET Simulation of voice over MPLS with sing Traffic Engineering. 2010.
3. Chung, Jong-Moon, Marroun, E. , Sandhu, H. and Kim, Sang-Chul. VoIP over MPLS Networking Requirements. 2001.
4. Rudinsky, J. VoIP-PSTN Interoperability by Asterisk and SS7 Signaling. VoIP-PSTN Interoperability by Asterisk and SS7 Signaling. 2007.
5. Hallock, J. A Brief History of VoIP. A Brief History of VoIP. November 26, 2004.
9. Voice over Internet Protocol ( VoIP ) . Goode. , Bur. September, 2002.
10. Performance analysis and the survey of the behavior of MPLS protocols. Rahman, M.A. , Kabir, A.H. , Hassan, M.Z. and Amir, M.R. s.l.A : ICCCE. , 13-15 May, 2008.
12. Jain. R and Sui, Kai-Yeung. A Brief overview of ATM: Protocol Layers, LAN Emulation and Traffic Management.
14. Development of Multiprotocol Label Switching. Viswanathan, A. , Feldman, N. , Wang, Z. and Callon, R. s.l.A : IEEE Coomunication Magazine. , 1998.
15. Pure MPLS Technology. Liewen, He. and Paul, B. s.l.A : The Third Internation Conference on Availability, Reliability and Security, IEEE.
16. Xiao, X. , Hannan, A. and Bailey, B. Traffic Engineering with MPLS in the Internet.
17. Younis, O. and Fahmy, S. Constraint-Based Routing in the Internet. s.l.A : Basic Principles and Recent Research.
19. Traffic Engineering Standards in IP Network utilizing MPLS. Ghanwani, A. , Jamoussi, B. and Fedyk, D. s.l.A : IEEE, 1999.
20. Javier Diaz-Estebaranz, J. Antonio Portilla-Figueras, Sancho Salcedo-Sanz, Miguel Faro-Rivas, Guillermo Estere-Asensio. Using OMNET++ web based simulator as test-bed for web design algorithms. 2008.
21. Clarification of the ‘OPNET NS2 Comparison ‘ paper with respects to OPNET Modeler. M. Fluery, G. Flores Lucio and M.J. Reed. s.l.A : International Conference on Simulation, Modeling and Optimization. , 2003.
22. Gilberto Flores Lucio, Marcos Paredes-Farrera, Emmanuel Jammeh, Martin Fluery and M.J. Reed. OPNET Modeler and NS-2: Comparing the Accuracy of Network Simulators. 2003.
6. Ezine Article. wwwezinearticles.com. [ Online ] [ Cited: July 15, 2010. ] hypertext transfer protocol: //ezinearticles.com/ ? A-Brief-History-of-VOIP & A ; id=2141357.
7. Which VOIP. www.whichvoip.com. [ Online ] [ Cited: June 22, 2010. ] hypertext transfer protocol: //www.whichvoip.com/voip/articles/voip_history.htm.
8. Radcom Academy. www.protocols.com. [ Online ] [ Cited: July 22, 2010. ] hypertext transfer protocol: //www.protocols.com/papers/voe.htm.
11. Juniper Network. www.juniper.net. [ Online ] May 2007. [ Cited: June 18, 2010. ] hypertext transfer protocol: //www.juniper.net/solutions/literature/white_papers/200087.pdf.
13. Javvin Network Management and Security. www.javvin.com. [ Online ] Javvin. [ Cited: July 16, 2010. ] hypertext transfer protocol: //www.javvin.com/protocolATM.html.
18. Fengnet. www.fengnet.com. [ Online ] [ Cited: August 3, 2010. ] hypertext transfer protocol: //fengnet.com/book/QoS % 20for % 20IP % 20MPLS % 20Networks/ch04lev1sec1.html.