Skip to main content

Posts

Showing posts with the label protocol

Link State Routing Protocol

Link state routing is a method in which each router shares its neighborhood’s knowledge with every other router on the internetwork. In this algorithm, each router in the network understands the network topology and then makes a routing table depending on this topology. Each router will share data about its connection to its neighbor, who will, consecutively, reproduce the data to its neighbors, etc. This appears just before all routers have constructed a topology of the network. In LSP, each node transmits its IP address and the MAC to its neighbor with its signature. Neighbors determine the signature and maintain a record of the combining IP address and the MAC. The Neighbor Lookup Protocol (NLP) of LSP derives and maintains the MAC and IP address of every network frame accepted by a node. The extracted data can support the mapping of MACs and IP addresses. The link-state flooding algorithm prevents the general issues of broadcast in the existence of loops by having every node mainta...

SRM Implementation in NS

This section gives an overview of the implementation of SRM in NS. Running an SRM simulation requires creating and configuring the agent, attaching an application level data source (a traffic generator), and starting the agent and the traffic generator. The key steps in configuring a virgin SRM agent are to assign its multicast group and attach it to a node. Other useful configuration parameters are to assign a separate flow id to traffic originating from this agent, to open log file for statistics, and a trace file for trace data. The agent does not generate any application data on its own; instead the simulation user can connect any traffic generation module to any SRM agent to generate data. The user can attach any traffic generator to n SRM agent. The SRM agent will add the SRM headers, set the destination address to the multicast group and deliver the packet to its target. SRM header contains the type of message, identity of the sender, the sequence number of the message, the roun...

Position-based routing protocols for Flying Object Ad-hoc Networks

Flying Ad-Hoc Networks are ad-hoc networks composed of flying objects (e.g., drones). In this context, we have 3D topologies in which it is interesting to study routing algorithms exploiting geographic information. These algorithms refer to nodes by their location, not address, and use those coordinates to route greedily, when possible, towards a destination. We are focused on the state-of-the-art, stateless geographic packet routing protocols conceived or adapted for three-dimensional network scenarios. Each protocol is based on a specific forwarding algorithm, which tries to send a packet to a neighbor node according to the rule specified by the algorithm. Compared Routing Algorithms We have implemented in NS-2 the following routing algorithms and performed a comparison over a common simulation scenario.  Greedy  is a simple progress-based forwarding strategy. A node forwards the packet to the neighbor node that minimizes the distance to the destination node. In general, if ...

FISHEYE ROUTING PROTOCOL IN NS2

  Hi guys in this post, we present a novel routing protocol for wireless ad hoc networks –   Fisheye State Routing (FSR)   in NS2. FSR introduces the notion of multi-level fisheye scope to reduce routing update overhead in large networks. Nodes exchange link state entries with their neighbors with a frequency which depends on distance to destination. From link state entries, nodes construct the topology map of the entire network and compute optimal routes. MANET  nodes are laptop, personal computer, personal digital assistants, mobile phones MP3 Players and these can be located in airplanes, trains, ships, cars offices and homes. A simple MANET can be designed at home to connect wirelessly the mobile nodes or it can be used in disaster hit area when a communication infrastructure collapses and there is insufficient time to install new infrastructure, MANETs are the best solution to build a fast infrastructure in disaster situation because they allow plug and play net...

BYZANTINE ATTACK SIMULATION IN NS 2

In order to simulate most of the Byzantine attacks, we developed a protocol-independent Byzantine attack simulation module for ns2. This module provides the capability to simulate the black hole, Byzantine wormhole, and Byzantine overlay network wormhole attacks without modifying the routing protocol. It was not possible to simulate the flood rushing attack using this technique because it requires timing changes in the routing protocol code. Because this attack simulation module is potentially useful to the secure routing community, we make it publicly available below. The module is implemented as part of the ns2 Link Layer (LL) object which lies directly below the Routing Agent and directly above the MAC layer. The modified LL has several commands that allow it to be configured from the simulation TCL setup script. The first command enables the black hole attack, which is executed by checking the packet type of any packet sent down by the routing agent, and silently dropping any packe...

SIMULATION OF ALOHA PROTOCOL USING NS2

  ALOHA is a protocol for satellite and terrestrial radio transmissions. In pure Aloha, a user can transmit at any time but risks collisions with other users' messages. "Slotted Aloha" reduces the chance of collisions by dividing the channel into time slots and requiring that the user send only at the beginning of a time slot. Aloha was the basis for Ethernet, a local area network protocol. Pure ALOHA Graph of frames being sent from 4 different stations according to the pure ALOHA protocol with respect to time, with overlapping frames shaded to denote collision. The first version of the protocol (now called "Pure ALOHA", and the one implemented in ALOHAnet) was quite simple: If you have data to send, send the data If, while you are transmitting data, you receive any data from another station, there has been a message collision. All transmitting stations will need to try re sending "later". Boxes indicate frames. Shaded boxes indicate frames which have ...

MODIFYING AODV PROTOCOL

 Many people doing project on AODV modification, but most of them have trouble in doing the same. The best way to modify aodv is to study aodv.cc and aodv.h well before starting your work. So here we are going to provide some help to modify AODV protocol. First of all you have to study the function of each timer in aodv.cc; for that put a printf message inside each function of aodv.cc separately and then you can see how many times each function calls while executing a simple aodv program. Step 1: open /ns-allinone-2.35/ns-2.35/aodv directory Step 2: open aodv.cc file and add the commands which is shown in yellow outline. void HelloTimer::handle(Event*) {   // Begin ns2blogger.blogspot.in printf("DEBUG TEST TEST \n"); // End ns2blogger.blogspot.in    agent->sendHello();    double interval = MinHelloInterval +                  ((MaxHelloInterval - MinHelloInterval) * Random::un...

FLOODING PROTOCOL FOR NETWORKS

  Flooding is a simple routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on. Flooding is used in bridging and in systems such as Usenet and peer-to-peer file sharing and as part of some routing protocols, including OSPF, DVMRP, and those used in ad-hoc wireless networks. There are generally two types of flooding available, Uncontrolled Flooding and Controlled Flooding. Uncontrolled Flooding  is the fatal law of flooding. All nodes have neighbours and route packets indefinitely. More than two neighbours creates a broadcast storm. Controlled Flooding  has its own two algorithms to make it reliable, SNCF (Sequence Number Controlled Flooding) and RPF (Reverse Path Flooding). In SNCF, the node attaches its own address and sequence number to the packet, since every node has a memory of addresses and sequence numbers. If it receives a packet in memory, it drops it immediately while in RPF, the node will only send the p...

REAL TIME PROTOCOLS [RTP/RTCP] FOR VIDEO STREAMING IMPLEMENTATION

  Here, we describe the necessary steps to include the new developed RTP/RTCP module with the other built-in NS-2 modules, without needing to replace the native implementation for these protocols. We assume the reader has successfully installed a current NS-2.XX version. This code has been developed and tested with NS-2.33 and NS-2.34.  In the legacy code, RTP and RTCP protocols are implemented as the RTP Agent and the RTCP Agent classes, respectively. These two classes are implemented in the rtp.cc (located in ~ns-2.XX/apps/rtp.cc) and rtcp.cc (located in ~ns-2.XX/tcp/rtcp.cc) files, as can be appreciated in Figure 1.  The RTP Agent holds all the functionalities for sending and receiving data packets, whereas the RTCP Agent is responsible for the control reports transmission and reception. The RTP Session class (implemented in ~ns-2.XX/common/session-rtp.cc) mainly deals with feedback report building and participant’s information tables maintenance, through the received ...

IMPLEMENTING A NEW PROTOCOL

  Tutorial to implement protoname in ns2.35 This is an Implementation tutorial of new manet( M obile  A d-hoc  NET works) unicast protocol name protoname. List of files to be modified ~/ns-allinone-2.35/ns-2.35/common/packet.h ~/ns-allinone-2.35/ns-2.35/trace/cmu-trace.h ~/ns-allinone-2.35/ns-2.35/trace/cmu-trace.cc ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-packet.tcl ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-default.tcl  ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-lib.tcl ~/ns-allinone-2.35/ns-2.35/queue/priqueue.cc   ** Note: Text in  red  is the part that is to be added or modified in given file and location and  purple  colour denotes the terminal commands. ** Note: mod stands for modification. ** Note: Line number is approx and is provided for your convenience. Please check the methods below and above before inserting. Step 1: download protoname.rar http://www.cs.nccu.edu.tw/~g10031/protoname.rar Extract the files and place them in ~/ns-allinone-2.35/...