Simulating inet's Protocol Stack with OPNET Modeler

Transcription

1 Simulating inet's Protocol Stack with OPNET Modeler Item Type text; Proceedings Authors Jaber, Nur; Moazzemi, Paria Publisher International Foundation for Telemetering Journal International Telemetering Conference Proceedings Rights Copyright held by the author; distribution rights International Foundation for Telemetering Download date 21/07/ :40:53 Link to Item

2 SIMULATING INET S PROTOCOL STACK WITH OPNET MODELER Author: Nur Jaber and Paria Moazzemi Advisor: Dr. Richard Dean Morgan State University ABSTRACT This paper discussessimulating inet sprotocol stack using OPNET Modeler. It shows an example of a custom protocol simulated in OPNET Modeler, and how to model thetest article, and ground station as reusable components for future simulation. simulation is a critical tool for inetas it enables design decisions that cannot be made analytically due to the complexity of the problem. This work addresses the incorporation of inet s protocol stack into the OPNET Modeler tool set as this piece of inet is unique and is not available in OPNET Modeler. KEYWORDS Simulation,OPNET Modeler, Protocol Stack, TFTP, inet. INTRODUCTION The integrated Enhanced Telemetry (inet) is a program launched by the director of the Central Test and Evaluation Investment Program (CTEIP) at the U.S. Department of Defense (DoD) to take advantage of advances in networking and telemetry technology to satisfy the emerging needs, such as higher transmission bandwidth, of the Major Range and Test Facility Bases (MRTFB)[1]. The inet study is aiming at adapting cutting-edge network technologies to replace the current inefficient point-to-point telemetry system. The new Telemetry System (TmNS) will have test articles (TAs), ground stations (GSs) working together with interconnected packet network [1]. Currently network designs are being developed by the inet community. However, verification of these designs is vital especially before on-the-field deployment. This could be done by building the proposed designs and testing them physically or by using computer software simulation tools. Although physical testing is the ultimate measure for any network design, it is a very costly and time-consuming process. Further, these tools are much more flexible than physical testing when dealing with a network as large and complex as inet. Therefore, 1

3 simulating inet is key because it is faster, more reliable and more cost-effective than physical testing. OPNET Modeler is a highly sophisticated and efficient network simulator. It enables engineers to simulate complex networks with highly customizable structures while maintaining the ability to produce comprehendible data to management. OPNET Modeler provides these capabilities through its layered design [2]. By enabling engineers to build top-down models that are graphically oriented, management can better understand the overall design without the need to understand the intricate technical details. This helps in closing the communication gap between management and their technical staff. Consequently, managerial decision making is greatly simplified and improved. OPNET Modeler is our choice as the simulator for the inet simulation task by the team at MorganStateUniversity based on its advantages of graphical user interface and strong community support. The objective of the research team is to provide the inet community with a toolbox in OPNET Modeler that will allow engineers and researchers run and customize inet simulations [3]. In this paper, we focus on simulating the TA s protocol stack and provide an example of a custom built protocol in OPNET Modeler as a means to future studies. Incorporating the stack into simulators such as OPNET Modeler to support the development of new protocols and to plan operational testing has significant potential impact to the inet program. BACKGROUND In the inet environment, there are three major components: the TA, the GS, and the radio link connecting the two. Data exchangeon this network is similar to a laptop accessing a home server on the same wireless local area network (WLAN). However, if the radio link is the main focus of the study,a laptop using a WLAN cannot be compared to a TA. This is mainly because the TAcould bemovingat Mach 2 speed which creates a significant channel distortion. This effect among others makes studying this analogy not useful. Since the purpose of this work is to simulate the protocols governing data exchange, studying WLAN scenarios will be of great importance. This is because the protocol stacks of both scenarios are almost identical. To simulatethe TA s protocol stack, a functional network must be built. This includes all three components: the TA,GS, and the radio link. OPNET Modeler is a discrete event packet simulator. It provides a user friendly graphical user interface (GUI) as well as a number of editors. These features simplify network modelingwhich makes the tool suitable for simulating almost any packet network.therefore, OPNET Modeler is widely used in industry and academia. OPNET Modeler provides a toolbox for standard components such as WLAN. Components unique to inet however, are yet to be created. This paper describeshow to accurately model inet and provides an example of a custom protocol in OPNET Modeler to enable engineers in

4 the inet community to customize their simulations to meet specifications. TAand GS nodes can then be used as a prototype for future development. Packet simulators like OPNET Modeler are designed to reduce the computational complexity of networks. Instead of manipulating the signal directly, it simulates networks based on its packets behavior [3]. Computations associated with physical properties and characteristics of the network components and their generated, transmitted, and received data packets are associated with each packet and eventually determine if the packet is going to be receivedor droppedby the destination. Computations include possible receivers, path loss, received power, signal to noise ratio at the receiver, bit error rate, packet error rate, and more. Every packet sent by the transmitter goes through its protocol stack and eventually to the receiver where it is determined if the packet is lost due to packet error. If the packet passes this stage, it is passed to the protocol stack of the receiver. METHODOLOGY AND DESIGN Accurately modeling network traffic in inet requires network models which represent the various stages and processes that information packets go through in their lifecycle. This includes the mechanisms and rules which govern them. Thus, previous prototypes which focused on modeling the radio link only are insufficient to accurately simulate inet. This is mainly because those prototypes failed to account for the internal complexity of the TA-GS nodes. According to the inet specifications, connectivity between the TA and GS follows the internet and OSI protocol reference models. Information packets are generated at the highest level of the protocol stack at one end and consumed at the same level of the other end as shown in Figure 1. Onboard Archive Recall Station Link/Phy L1 L2 /P1 /P2 L1 L2 /P1 /P2 L1 L2 /P1 /P2 Link/Phy Link/Phy Archive System 1 2 Data Acquisition System Comm. RF Interface 3 4 RF Comm. Processing RF Net System Interface Test Article Ground Station Figure 1: End to End lication Level Connectivity [1.] Previous prototypes were mainly developed to validate OPNET Modeler sability to meet inet needs [3]. However, when those prototypesare compared to inet s architecture shown in Figure

5 1, it is apparent that this prototype is insufficient to mimic inet's architecture. For example, the DAUs are connected to the recorder using logical connections, while in a real TA, this connection will be using Ethernet standard. This means that each component within the TA will have an Ethernet MAC and Physical layers as a bare minimum to meet inet needs. Modeling inet could be done in two ways: building inet s protocol stack from scratch or modifying existing OPNET Modeler s available models to meet inet requirements. The second method was chosen because it could save considerable amount of time and it would provide developers with multiple worked examples in the OPNET Help Files. Following this method, available models could be used to compile a protocol stack similar to inet s then adding the new protocols, which are unique to inet, and the other protocols which are not provided by OPNET Modeler s application standard package. In addition, a genericmodel basis was used to simplify protocol customization instead of an Original Manufacturer Equipment (OEM) specific model, like Cisco or Nortel. This later choice eliminates the need to deal with proprietary protocol implementations. Figure 2 is a model of the inet protocol stack. Most of these protocols are available on some generic-models in OPNET Modeler with the exception of some protocols which are circled in red in Figure 2: TFTP, PTP, SNMP, RTSP, LTC and RC Delivery Protocols. These six protocols are not a part of the standard application package available in OPNET Modeler. RC Delivery Protocol SNMP LTC Delivery Protocol RTSP HTTP FTP TFTP DHCP PTP TCP UDP DiffServ ARP IP v4 IGMP ICMP Ethernet LLC RSTP/Transparent Bridging IGMP Ethernet (Data Link) Ethernet Flow Control 10 Mbps Ethernet Ethernet (Physical) 100 Mbps Ethernet Auto-Negotiation 1Gbps Ethernet Figure 2: TA s Protocol Stack

6 Thus one of the six protocols was chosen to simulate as a part of a custom-compiled protocol stack. TFTP is the simplest among the six, thus it is easier to build, simulate and troubleshoot. Hence it was chosen. To simulate the new protocol the entire protocol stack must be simulated. To do this, a network must be built. Sothe network shown in Figure2has a TA and GS nodes running the new lication Layer protocol. Also, it has four new icons on the top, which are needed to simulate any application/protocol in OPNET Modeler. These icons have a multi-layer structured code written in Proto-C, the programming language in OPNET. The user can use the GUI to configure the network quickly. Figure 3: Sample (Top Level View.) The _Def and Prof_Def icons define the applications supported in the network and the profile of application supported on the nodes, while the Tasks icon defines the custom applications which are not a part of the standard packagee in OPNET Modeler. A generic server was used as the base node model. It was chosen becausee its node-model resembled Figure 2 the most, andalso because it is likely that the future architectures of the TA and GS will include real servers. Figure 4 shows the proposed DAU prototype in the red rimmed figure. This DAU not only generates packets but can be connected using an Ethernet cable to other DAUs or a switch. This is a result of having a real Ethernet MAC and physical layers. Also, the black rimmed figure is a node model of a server with a real and functional protocol stack. This serverr is replacing the queue in the first prototype mainly because it is a more realistic representation of a TA component than a simple queue. In addition, the dotted black rimmed figure shows that this server is currently running the TFTP application, which was built using the Tasks icon shown in Figure 3. Notably, for the purpose of testing the operation of the new protocol, TFTP, a modified g connection was used instead of an aeronautical channel. This later choice avoids the need to modify the MAC layer which is beyond the scope of this paper, but will be addressed in the near future.

7 Figure 4: TA Node Model. RESULTS, ANALYSIS AND DISCUSSION To verify the operation of the developed protocol, TFTP, the developed prototype shown in Figure 4 was simulated with TFTP as the only supported application layer protocol running at the server. Figure 5 shows the average throughput of the TA and GS. Figure 5: TFTP Throughput at TA and GS Transceivers.

8 This simulation and the proceeding one used Quite Room Scenario WLAN at 1.0 Watts, and to ensure that all packets generated at the TA will be received by the GS, both nodes were placed strategically and a trajectory was defined based on a trial bases until an optimum configuration was decided. Thus, Figure 6 shows that all packets created by TFTP at the application layer were encapsulated by the UDP layer and the other layers above and below shown in Figure 2. The same Figure also shows that those packets were received by the GS and destroyed at the application layer by TFTP. Figure 6: TFTP Packets Generationn and Disposal. After verifying the protocol s operation independently, it was joined by another two application layer protocols: FTP and HTTP. These protocols are TCP protocols and were chosen to ensure that both transport protocols, and the corresponding application layer protocols, work properly together. Consequently, Figure 7 was generated to show the throughput of both nodes.

9 Figure 7: TFTP+FTP+HTTP Throughput at TAA and GS Transceivers. Then, by observing Figure 8, it is clear that both transport protocols are functioning properly.

10 Figure 8: TFTP+FTP+HTTPP Packets Generation and Disposal. CONCLUSIONN ModelingiNET during this development stage is of great importance. This can be done with network simulators which provide easy, fast, and costt effective solutions.however accurately modeling network traffic in inet requires network models which represent the various stages and processes that information packets go through in their lifecycle.. Thus, this work presented a way of simulating an inet prototype with a functional protocol stack similar to the TA s providedd in the inet standards. We implemented acustom protocol, TFTP, as an addition to the available protocols in the OPNET Modeler s standard suit. Simulations have been performed to show that both the standard protocol suit and the new protocol function well simultaneously. ACKNOWLEDGEMENTS The authors appreciate the support of the inet project, SRC, and the DoD TRMC center which funded this effort.

11 REFERENCES 1. inet Telemetry System Architecture CTEIP; Version 1.0, OPNET Modeler Documentation OPNET Corporation; Zhang, Tianyin; Jaber, Nur, Aeronautical Channel Simulation in Simulators for incorporation into OPNET, , 46 th Annual International TelemeteringConference (ITC/USA), SanDiego, CA, October, 2010.