report aodv word2000
TRANSCRIPT
An OPNET model implementation forAd-hoc On demand Distance Vector
Routing Protocol
by
Lyes GuemariInstitut National des Telecommunications
Paris – France
Master’s thesis at the
Information Technology LaboratoryOf the
National Institute of Standards & Technology (NIST)Gaithersburg, MD – USA
August 20, 2001
Tutor:Dr. Djamel Zeglache (INT)
Supervisor:Dr. Leonard E. Miller (NIST)
2
FICHE DE PRÉSENTATION
Nom Lyes GuemariOption Communications MobilesEntreprise National Institute of Standards and Technology (NIST, USA)Dates Du 1 Décembre 2000 au 31 Août 2000Sujet1 Implémentation d’un .modèle OPNET pour le protocole de routage Ad-hoc
On-demand Distance Vector (AODV). AODV est un protocole de routage dédié aux réseaux mobiles dits Ad-hoc (improvisés).
Nombres de personnes participant au projet
1
RÉSUMÉ
Un réseau mobile ad-hoc (MANET) est un ensemble de terminaux mobiles sans-fils formant un réseau temporaire sans l’aide d’aucune infrastructure préalable. A cause de la nature improvisée de tels réseaux, un protocole de routage est nécessaire pour établir des routes entre les noeuds communicants.
La Internet Engineering Task Force (IETF) a formé un groupe de travail autour des réseaux mobiles ad-hoc dont la mission est d’encadrer le développement des protocoles de routages ad-hoc destinés à fonctionner au-dessus du protocole IP. Au jour d’aujourd’hui, de nombreux protocoles sont à l’étude mais aucun standard n’a été adopté. Le protocole Ad-hoc On-demand Distance Vector est l’un des protocoles les plus prometteur actuellement à l’étude.
Afin de contribuer au développement des MANETs, le Wireless Communication Technologies Group du National Institute of standards and Technology a entrepris le développement d’un modèle de simulation pour le protocole AODV. Ce modèle a été ensuite mis à la dispostion des chercheurs désirant conduire des simulations dans le domaine des MANETs.
Le présent rapport contient une description et une évaluation du dit modèle.
ABSTRACT
A mobile ad-hoc network (MANET) is a collection of wireless mobile hosts forming a temporary network without the use of any pre-existing structure. Because of the improvised nature of such networks, a routing protocol is used to discover routes between nodes.
The Internet Engineering Task Force (IETF) has formed a new working group for Mobile Ad-hoc Networking in order to provide a framework for developing IP-based routing protocols in ad-hoc networks. At this time, no standard protocol has been adopted yet but many of them are currently under study. The Ad-hoc On-demand Distance Vector algorithm is one of the promising protocols under study.
As a contribution of the Wireless Communication Technologies Group of the National Institute of standards and Technology, a simulation model for AODV was developed and made available in order to provide a tool for researchers who need to conduct studies in MANETs.
This paper presents a description and an evaluation of the said model.
1Ce rapport présente le travail que j’ai effectué au sein du groupe Wireless Communication Technologies du NIST. Une description technique est présentée dans les sections 4, 5 et 6.
3
4
ACKNOWLEDGMENT
First of all, I would like to express my gratitude to Dr. Nader Moayeri, the group manager, for giving me the opportunity to work at NIST. Then, I would like to thank Dr. Leonard E. Miller, my supervisor for his driving support during this period and his great help for writing this paper. Finally, I want to thank all my teammates for providing such an enjoyable environment.
5
6
TABLE OF CONTENTS
0 The National Institute of Standards & Technology.....................................................4
The Information Technology Laboratory.........................................................................4The Advanced Network Technologies Division..............................................................4
1 Introduction.....................................................................................................................4
2 General Concepts............................................................................................................4
2.1 Ad-hoc Networking.......................................................................................................42.2 Routing protocols for Ad-hoc Networks.......................................................................4
2.2.1 Actual Needs...................................................................................................................................42.2.2 Classic Protocols.............................................................................................................................4
2.2.2.1 Link State Protocols.................................................................................................................42.2.2.2 Distance Vector Protocols........................................................................................................42.2.2.3 Critic.........................................................................................................................................4
2.2.3 Enhanced Protocols for MANETs...................................................................................................42.2.3.1 Destination Sequenced Distance Vector Protocol....................................................................42.2.3.2 Ad-hoc On-demand Distance Vector Protocol.........................................................................4
3 AODV Specifications......................................................................................................4
3.1 Route Discovery.........................................................................................................43.1.1 Generating route requests................................................................................................................43.1.2 Forwarding route requests...............................................................................................................43.1.3 Generating route replies..................................................................................................................43.1.4 Forwarding route replies..................................................................................................................4
3.2 Local Connectivity Management...............................................................................43.3 Route Maintenance.....................................................................................................43.4 Route expiry and deletion...........................................................................................4
4 Our addition to AODV...................................................................................................4
4.1 Problem......................................................................................................................44.2 Solution......................................................................................................................4
5 NIST/AODV OPNET Model Implementation.............................................................4
5.1 Objective....................................................................................................................45.2 Model description.......................................................................................................4
5.2.3 NIST/AODV Node Model..............................................................................................................45.2.4 NIST/AODV Application Manager (app_manger) Process Model................................................45.2.5 NIST/AODV Routing (aodv_routing) Process Model....................................................................45.2.6 NIST/AODV Mobility Process Model............................................................................................4
5.3 NIST/AODV Model Validation.................................................................................4
1
6 NIST/AODV Model Study.............................................................................................4
6.1 The simulation model.................................................................................................46.2 Performance Results...................................................................................................4
6.3 Metrics................................................................................................................................................46.4 Results................................................................................................................................................4
6.4.1 Varying Mobility and Repair.......................................................................................................46.4.2 Varying Offered Load.................................................................................................................46.4.3 Varying Connectivity Support.....................................................................................................4
7 Summary.........................................................................................................................4
References...........................................................................................................................4
APPENDIX A – SEQUENCE NUMBERS AND LOOP FORMATIONS........................................4
APPENDIX B – 3-NODE SAMPLE SCENARIO LOG FILE...........................................................4
2
0 The National Institute of Standards & Technology
The National Institute of Standards and Technology (NIST), formerly the National Bureau of Standards (NBS), was established by Congress in 1901 to support industry, commerce, scientific institutions, and all branches of Government. For nearly 100 years the NIST/NBS laboratories have worked with industry and government to advance measurement science and develop standards.
NBS was created at a time of enormous industrial development in the United States to help support the steel manufacturing, railroads, telephone, and electric power, all industries that were technically sophisticated for their time but lacked adequate standards. In creating NBS, Congress sought to redress a long-standing need to provide standards of measurement for commerce and industry and support the "technology infrastructure" of the 20th Century.
In its first two decades, NBS won international recognition for its outstanding achievements in physical measurements, development of standards, and test methods – a tradition that has continued ever since. This early work laid the foundation for advances and improvements in many scientific and technical fields of the time, such as standards for lighting and electric power usage; temperature measurement of molten metals; and materials corrosion studies, testing, and metallurgy.
Both World Wars found NBS deeply involved in mobilizing science to solve pressing weapons and war materials problems. After WWII, basic programs in nuclear and atomic physics, electronics, mathematics, computer research, and polymers as well as instrumentation, standards, and measurement research were instituted.
In the 1950s and 1960s, NBS research helped usher in the computer age and was employed in the space race after the stunning launch of Sputnik. The Bureau's technical expertise led to assignments in the social concerns of the Sixties: the environment, health and safety, among others. By the Seventies, energy conservation and fire research had also taken their place at NBS. The mid-to-late 1970s and 1980s found NBS returning with renewed vigor to its original mission focus in support of industry. In particular, increased emphasis was placed on addressing measurement problems in the emerging technologies. Many believe that the Stevenson-Wydler Act implemented, throughout the federal laboratories, the practices that had been developed at NBS over the years: cooperative research and technology transfer activities.
The Omnibus Trade and Competitiveness Act of 1988 – in conjunction with 1987 legislation – augmented the Institute's uniquely orchestrated customer-driven, laboratory-based research program aimed at enhancing the competitiveness of American industry by creating new program elements designed to help industry speed the commercialization of new technology. To reflect the agency's broader mission, the name was changed to the National Institute of Standards and Technology (NIST).
3
These efforts, and the organizational changes brought by the NIST Authorization Act for 1989 which created the Department of Commerce's Technology Administration to which NIST was transferred, served as a critical examination of the role of NIST in economic growth. These mission and organizational changes, initiated under the Bush Administration were reaffirmed and strengthened by the Clinton Administration.
In addition to the reviews by Congress, the Administration, and the Department of Commerce, the Visiting Committee on Advanced Technology (VCAT) of NIST reviews and makes recommendations regarding the general policy, organization, budget, and programs of NIST. The VCAT holds four business meetings each year with NIST management, and summarizes its findings each year in an annual report that is submitted to the Secretary of Commerce and transmitted by the Secretary to Congress.
As an agency of the U.S. Department of Commerce's Technology Administration, NIST's primary mission is to promote U.S. economic growth by working with industry to develop and apply technology, measurements, and standards. It carries out this mission through a portfolio of four major programs:
Measurement and Standards Laboratories that provide technical leadership for vital components of the nation's technology infrastructure needed by U.S. industry to continually improve its products and services;
a rigorously competitive Advanced Technology Program providing cost-shared awards to industry for development of high-risk, enabling technologies with broad economic potential;
a Manufacturing Extension Partnership with a network of local centers offering technical and business assistance to smaller manufacturers; and
a highly visible quality outreach program associated with the Malcolm Baldrige National Quality Award that recognizes business performance excellence and quality achievement by U.S. manufacturers, service companies, educational organizations, and health care providers.
With a budget of $790 millions, NIST employs approximately 3,300 scientists, engineers, technicians, and about 1,250 visiting researchers each year. NIST provides industry, university, and government agency with a wide range of technology services. These include Standard Reference Materials and data, information on national and international standards, laboratory accreditation, and equipment calibration. NIST laboratories are specialized in electronics and electrical engineering, manufacturing engineering, chemical science and technology, physics, materials science and engineering, building and fire research, and information technology. NIST organization includes the following laboratories:
4
Electronics and Electrical Engineering Laboratory (EEEL), Manufacturing Engineering Laboratory (MEL), Chemical Science and Technology Laboratory (CSTL), Physics Laboratory (PL), Materials Science and Technology Laboratory (MSTL), Buildings and Fire Research Laboratory (BFRL), and Information Technology Laboratory (ITL).
The Information Technology Laboratory
The Information Technology Laboratory (ITL) at NIST represents the US measurement and standards laboratory focused on the needs and competitiveness of the US information technology sector and the needs of the sector’s products and services.
To answer to industries and users needs, ITL is providing unbiased measurement methods, tests and standards. ITL’s activities support the development and use of information technology-based systems and services that are usable, scalable, interoperable and secure. ITL also provides tools that help companies to produce, integrate, test and use next generation products and services.
ITL’s programs and activities include research, technical collaboration, development of tests, quality assurance techniques, tools, models, and reference data for emerging network technologies. By collaborating with different organizations such as industry, research, education, government and standards organizations, ITL tries to improve measurement methods and techniques for efficient access, and exchange of complex information. ITL’s fields of competence are also security techniques and methods for protecting the integrity, confidentiality, reliability, and availability of information resources. Tests and measurements are the main activities of the laboratory and ITL provides to industry evaluation of measurement methods for high performance computing and communications systems, as well as software testing tools and methods to improve quality of software, information technology resources, and supporting infrastructure.
ITL’s activities cover a broad range of technologies (Figure 1) in mathematical and computational sciences, advanced networks, statistical engineering, computer security, information access and user interfaces, high performance systems and services, distributed computing and information services, software diagnostic and conformance testing. All these fields of research find their application within NIST activities, by providing high quality services to NIST staff and collaborators, but also help and support the US industry in conducting scientific, engineering, consulting and administrative applications.
In 1998, the laboratory involved 384 full-time employees, 75 percent of them were professional and technical staff and 25 percent were administrative support personnel. In
5
addition, 92 research associates, guest scientists and faculty appointments contributed the ITL research program.
The budget for ITL programs consisted of $44.5 million given by the NIST Congressional appropriation, including $12.3 million for the Consolidated Scientific Computing System, $0.6 million for Technical Competence, $2.2 million from the Advanced Technology Program, and $11.9 million in reimbursable funds.
Figure 1 ITL Organization Chart
The Advanced Network Technologies Division
The Advanced Networking Technologies Division (ANTD), one of the eight divisions within NIST’s Information Technology Laboratory, consists of approximately 35 technical professionals holding undergraduate and advanced degrees in computer science, electrical engineering, and mathematics. The division operates with an annual budget of approximately $5 million.
Its mission is to study and accomplish the development of next generation networking technologies and study the transmission of multimedia data streams to enable heterogeneous collaborative computing.
6
The ANTD works as a partner with suppliers and users of information technology to improve the quality, manageability, reliability, security and interoperability of networked systems. As part of the ITL’s metrology laboratory, the division provides test, measurement, and quality assurance techniques, tools, models and reference data for emerging network technologies. It develops, demonstrates and promotes these technologies through reference implementations, testbeds, guidelines and standards. All the technical programs focus on infrastructure and enabling technologies for advanced networks, but also on interoperability among heterogeneous networks and communication protocols.
The ANTD is divided into four groups as shown in :
Figure 2 ANTD Organization Chart
The Multimedia and Digital Video Technologies Group works with industry to promote the development of cost-effective, interoperable, distributed multimedia applications and to enable the development of digital video technologies for broadcast, interactive television, video on demand and video conferencing.
The Internetworking Technologies Group works with industry and commercial suppliers to remove barriers to the next generation of secure and reliable internetworking technologies and integrated network services.
The High Speed Network Technologies (HSNT) Group where I worked. The group works with the communications industry to expedite the development of technologies for high-speed networks, and to promote the deployment and use of such technologies. The main emphases of the group include testing methods and prototype development for high speed network technologies, interoperability among high speed
7
network products and analysis, simulations and measurements of the performance characteristics of high speed network technologies.
And finally the Wireless Communications Technologies Group (WCTG) investigates performance optimization and enhancements for information technology applications that are carried over wireless communications especially such digital signal processing techniques as compression and error control encoding. The current researches deal with Local Multipoint Distribution Service (LMDS), the third mobile generation (3G) and Mobile Ad Hoc Network (MANET).
8
1 Introduction
The term MANET[1] stands for Mobile Ad-hoc Network. This new networking concept defines simple mechanisms which enable mobile devices to form a temporary community without any planned installation, or human intervention. The idea is to form a totally improvised network that does not require any pre-established infrastructure. But, how can we make this possible? The answer is very simple. Each node acts as a host and a router at the same time. This means that each node participating in a MANET commits itself to forward data packets from a neighboring node to another until a final destination is reached. In other words, the survival of a MANET relies on the cooperation between its participating members—if a source node wants to communicate with another node which is out of its transmission range, the former will send its packets to a neighboring node, which will send them, in its turn, to one of its neighboring nodes, and so on, until the destination node is reached.
Because such networks are deployed “on the fly”, they find a direct application in the military field. They are also very useful in other applications such as emergency rescues and disaster recovery situations, where cellular infrastructures are non-existent. However, as wireless networking devices are becoming more and more sophisticated and hence more and more affordable, some new commercial applications have been introduced for MANETs, such as pervasive computing, document sharing in conferences, and smart sensors.
Although, this new approach of networking brings a great flexibility to the world of wireless communications, it raises some new challenges among the research community as far as routing, QoS, and security issues are concerned.
In this report, we will limit our interest to the routing area. In fact, ad-hoc networks have certain characteristics (high degree of mobility, absence of centralized administration, limited resources) that impose some strong requirements with regard to the routing functionality. An adequate routing protocol for MANETs should not only react quiet rapidly to the dynamically changing topology of the network but it should also maintain a decent quantity of control traffic in order to preserve the available resources (bandwidth, battery power, etc). Classic protocols such as link-state or distance-vector[2] would be too drastic for such a purpose. Both rely on flooding mechanisms, which would cost a lot in terms of resources and would take a long time to converge in case of higher mobility.
Therefore, the Internet Engineering Task Force has formed a new working group for Mobile Ad-hoc Networking[1], whose mission consists of providing a framework for developing IP-based routing protocols in ad-hoc networks. At this time, no standard protocol has been adopted yet but many of them are currently under study. One of the rising protocols is known as AODV, which stands for Ad-hoc On-demand Distance Vector[3].
9
In keeping with the general pattern of its policy, the Wireless Communication Technologies Group (WCTG) of the National Institute of Standards and Technology (NIST) intends to play an active role in the development of MANETs by investigating the performance of routing protocols for MANETs that have been submitted for possible standardization by the IETF.
This report is the result of a master’s thesis which has been carried out in the WCTG laboratory. The objective of this study is the implementation, documentation and evaluation of a simulation model for the AODV routing protocol. The commercially available simulation software OPNET[4] was used for this purpose.
The remainder of this report is organized as follows. In section 2, some general concepts are quickly introduced with a particular focus on the routing area. In section 3, a short introduction to AODV is presented. Section 4 introduces our additions to the actual specifications of AODV. Section 5 describes the simulation platform that was adopted and Section 6 presents some performance results. A summary is presented in Section 7.
2 General Concepts
2.1 Ad-hoc Networking
There are two approaches that allow two wireless stations to communicate with each other. The first one is to introduce a third fixed party (a base station) that will hand over the offered traffic from a station to another, as illustrated in Figure 3. This same entity will regulate the attribution of radio resources, for instance. When a node S wishes to communicate with a node D, the former notifies the base station, which eventually establishes the communication with the destination node. At this point, the communicating nodes do not need to know of a route for one to each other. All that matters is that both nodes source and destination are within the transmission range of the base station. If one of them fails to fulfill this condition, the communication will abort.
Question: what happens if the base station is unavailable? Or what happens if we are in situation where such an infrastructure does not exist at the first place?Answer: we simply do not communicate! Actually, we can thanks to the second approach that is introduced bellow.
Note however that this form of centralized administration is very popular among wide cellular networks such as GSM, UMTS, etc.
10
Figure 3 Infrastuctured network
The second approach, called ad-hoc, does not rely on any stationary infrastructure. The concept behind these infrastructureless networks is the collaboration between its participating members, i.e., instead of making data transit through a fixed base station, nodes consequentially forward data packets from one to another until a destination node is finally reached. Typically, a packet may travel through a number of network points before arriving at its destination.
Figure 4 illustrates a simple 3-node ad-hoc network. In this figure, a source node S wants to communicate with a destination node D. S and D are not within transmission range of each other. Therefore, they both use the relay node R to forward packets from one to another. So, even though R is primarily a host, R is acting as a router at the same time.
Figure 4 Infrastructureless networks
By definition, a router is an entity that determines the path to be used in order to forward a packet toward its final destination. The router chooses the next node to which a packet should be forwarded according to its current understanding of the state of the network.
S DR
11
Because of the improvised nature of ad-hoc networks, routes are built dynamically as and when nodes are regrouping (Discovery). Hence, ad-hoc networks are more responsive to topology changing than any wired networks. Consequently, routing protocols for ad-hoc networks should be able to cope with link breakages and make sure that the network wont collapse as nodes are moving or shutting down (Maintenance).
The following section is dedicated to ad-hoc routing protocols.
2.2 Routing protocols for Ad-hoc Networks
2.2.1 Actual Needs
As we previously mentioned, ad-hoc networks have certain characteristics that put a lot of stress on the routing layer. Some of these characteristics are listed bellow:
Nodes in a MANET are connected by wireless links with a constrained bandwidth. Thus, an appropriate routing protocol for MANETs should imply a reasonable over-head in order to preserve the limited bandwidth. Message complexity must be kept very low.
Nodes in a MANET are likely to be hand-held devices and laptops with relatively constrained resources. These resources include namely storage capacity and battery power and should be used in a smart way. Therefore, a suitable routing protocol for MANETs should not make an excessive use of flooding or periodic update messages.
Nodes in a MANET are likely to be mobile. In order to cope with such a rapidly changing topology, a routing protocol for ad-hoc networks should be able to find alternate routes very quickly. Rapid convergence is the ultimate goal for an ad-hoc routing protocol.
In the next sections, we will see how classic protocols do not fulfill the new demands that were established by ad-hoc networks. Also, we will see how this has led to the appearance of a new generation of protocols wholly dedicated to MANETs.
2.2.2 Classic Protocols
Two routing algorithms, link-state and distance-vector, have been traditionally used in packet-switched networks. They both allow a node to determine the next hop along the “shortest path” toward a given destination. The shortest path is computed according to a specific cost, which is usually the distance in number of hops. 2.2.2.1 Link State Protocols
In the link-state[2] approach, each node collects the state (cost) of its outgoing links (links toward neighboring nodes) and diffuses it to every other node in the network in the
12
form of link state packets (LSPs). This is done periodically or whenever a change is detected in one of the outgoing links. Also, LSPs are tagged with a sequence number in order to indicate their freshness (most recent LSPs have greater sequence numbers).
On the other hand, as a node receives the LSPs, it updates its global view of the network topology in terms of link states. Given this map, the node runs a shortest path algorithm (usually, Dijkstra’s shortest path algorithm[5]) and determines the optimal next hop for each destination in the network. Only the next hop and route cost for each destination are stored in the routing table.
Note however that nodes do not update their tables at the same time (due to the propagation time of LSPs). This can lead to the formation of some short-lived loops, which will disappear by the time the LSPs have reached every other node in the network.
2.2.2.2 Distance Vector Protocols
The distance vector algorithm, also called the Bellman-Ford[6] algorithm, is based on a different approach. Each node advertises its entire routing table to its immediate neighbors only. As a node receives the routing information of its neighboring nodes, it updates its own routing table by looking at its neighbors’ routing table. Basically, for each destination, a node looks at each of its neighbor’s distance for that destination (distance from neighbor to destination) and increments it by the link cost to reach this same neighbor. The node, then, picks up the neighbor via which the distance is the smallest. Each node keeps track of its neighbor’s distances and modifies its local vector if any changes occur.
The Bellman-Ford algorithm suffers from both short-lived and long-lived loops. Also, it is known for its “counting-to-infinity” problem[7], which occurs in case of link failure.
2.2.2.3 Critique
Both algorithms link-state and distance-vector have proven their efficiency in case of networks with very low mobility. However, they both collapse when it comes to frequently changing topology networks. They not only take a long time to converge, but they also consume a big part of the available resources in finding routes that would probably never be used. Plus, some sort of mechanism should be added in order to avoid the formation of neither short nor long-lived loops.
2.2.3 Enhanced Protocols for MANETs
With the growing interest for mobile ad-hoc networks, a large set of IP-based routing protocols was proposed to the MANET working group. No standard has been adopted yet, but some promising protocols are enthusiastically under study. One of the rising protocols is the subject of this report. It is called Ad-hoc On Demand Distance Vector
13
(AODV) and finds some of its inspiration in the Destination Sequenced Distance Vector (DSDV) protocol.
2.2.3.1 Destination Sequenced Distance Vector Protocol
As the name indicates, DSDV[8] is originally based on the distance-vector algorithm.
Two major modifications were added in order to make the protocol suitable more for mobile ad-hoc networks. The first modification was added to cope with the “counting to infinity” and “loop formation” issues. The idea is very simple and consists of tagging each route with a sequence number in order to indicate its freshness. Basically, a route with a greater sequence number is a route that was issued later in the time and has therefore more chances to be accurate with regard to the current topology of the network. The destination sequence number is originally issued by the destination node. This number is maintained within each node by incrementing it whenever a change occurs along this same route. The sequence number and the cost route are included in the update messages. Thus, when a node receives an update message for a given route, it first checks the sequence number that is included in it and compares it with the one that is stored in the routing table. Only update messages with greater sequence number are taken into account. In case of equality, the route with smaller metric is to be considered.
The second improvement that was added to the original algorithm aims at reducing the over-head generated by the protocol. It consists of the introduction of two types of update messages: full dump and incremental. A full dump packet is used to advertise all available routing information whereas an incremental packet has smaller size and is used to advertise only the changes between two full dumps.
Indeed, DSDV is much more stable than the basic Bellman-Ford algorithm. However, DSDV still relies on periodic messages to maintain its routing information. Therefore, a final adjustment was needed to minimize the amount of over-head traffic generated.
2.2.3.2 Ad-hoc On-demand Distance Vector Protocol
AODV[3] brings another brick to the edifice. As an improvement on DSDV, AODV reduces the amount of control traffic by simply minimizing the number of enquired routes. Instead of building a route for all possible destinations in the network, a node only creates and maintains routes that it really needs. When a route is needed, a node initiates a request in order to locate its interlocutor node. On the other hand, when a route is no longer used, it is simply expunged from the routing table. This approach is known as source-initiated on-demand routing as opposed to table-driven routing. It is also known as reactive as opposed to proactive. For reasons of scalability, proactive protocols may not find the same response within the MANET community as reactive protocols, such as AODV, DSR, or OLSR[9] would probably have.
Another adjustment was added as far as route maintenance is concerned. In fact, in case of link failure, the node upstream immediately broadcast an update message to the set of
14
nodes that are truly affected. Periodic updates such as full dump packets in DSDV were completely eradicated.
Of course, AODV uses the same set of sequence numbers as in DSDV, which guaranties loop-freedom in its routes.
A more thorough description of AODV mechanisms is presented in the next chapter.
3 AODV Specifications
As we previously mentioned in section 2.2.3.2, the Ad-hoc On demand Distance Vector protocol uses a whole different approach to build its routing information. As a matter of fact, route enquiries are initiated on an on-demand basis.
When a node wishes to send a packet to a destination node, it initiates a discovery process in order to locate it. If no route is found within a specific period of time, the initiator node assumes that the destination node is unreachable. The discovery process is aborted and the corresponding data packets are dropped. On the other hand, if the initiator node receives a route as a response to its enquiry, it updates its routing table by creating an entry for the destination node.
Once an entry is created, a maintenance process is triggered in order to monitor the status of the just created route— if a route is no longer used, a node deletes from its routing table. If a failure occurs along an active route, the node upstream immediately notifies the earlier hops of such a breakage using a specific type of control packets. In the presence of packets still in need of a route, affected nodes may re-initiate new discovery activities in order to find a replacement route.
AODV defines the routing information in a distributed table-driven manner. This means that each node along a particular path has to maintain a routing table entry for the destination node down that same path. This is opposed to the source routing approach where only the source node is aware of the complete path (hop-by-hop) toward the destination. AODV also allows each node to maintain one and only route per destination. It is good to know then that some other routing protocols allow multiple route discoveries. In this case, if a primary route collapses, an alternative one is used.
Routing table entries are defined in AODV in the form of tuples <destination address, next hop address, sequence number, distance, precursor list, expiration date>. Sequence numbers are used to guarantee loop-freedom and indicate the freshness of a route. Distances are expressed in number of hops. Whenever a route is invalidated, the destination sequence number is incremented by one and the distance is set to infinity. The precursor list designates the set of neighboring nodes that are effectively using that entry to forward data packets. Finally, the expiration date indicates the time upon which the
15
entry must be deleted. Of course, the expiration date is extended every time the entry is used.
3.1 Route Discovery
The discovery process is a mechanism that allows each source node participating in a MANET to locate (given its IP address) a destination node for which it has a packet to send. Of course, nodes initiate discovery requests only for nodes that have not been previously located (those for which node has not an entry in its routing table). If an entry already exists, then data packets are immediately sent to their destination and the discovery step is skipped.
In order to initiate a discovery process, a node has to broadcast a route request packet (RREQ) to its neighboring nodes. The packet is propagated by every other node in the network until a route is found (see Figure 5).
3.1.1 Generating route requests
Basically, if a node source A is looking for a destination node B in a MANET, A would let every other node in the network know that it is looking for B by broadcasting a RREQ packet to its neighbors. The RREQ includes the IP address and sequence numbers of both source and destination. The destination sequence number refers to the sequence number associated to the last route to the destination node B that the source node A has been aware of. If no trace of the sequence number is found, a default value of 0 is used.
Figure 5 RREQ propagation
Each intermediate host which receives the broadcast RREQ has to re-broadcast it at a certain extent until the RREQ reaches either the destination node B or an intermediate node which is aware of a fresh enough route (according to the included destination sequence number) to the destination node B.
16
Two other fields of a RREQ are the time to live (TTL) and the broadcast ID.
The TTL field allows a discovery initiator to control the degree of dissemination of its RREQ within the network. For instance, a RREQ packet whose TTL field is set to 2 will travel through 2 hops at most from the source node. When a RREQ is broadcast, the source node sets its TTL field to an initial value in terms of hops and waits for a corresponding period of time (RREP_WAIT_TIMEOUT) before taking any action. If by any chance, a route is received before the waiting period is finished, then the discovery process is successfully terminated. On the other hand, if the waiting period arrives to its term without having received any response, the source node re-broadcasts the “same” RREQ packet and again waits for another period of time. This time, however, the RREQ has a bigger TTL value and the waiting period is consequently longer. Having a bigger TTL value, the new RREQ will reach a larger set of nodes and will hopefully lead to a route reply generation. If still no reply is received, the source keeps on re-broadcasting the RREQ with an incremented TTL up to a maximum number of retries. Upon threshold, the discovery period is aborted. These mechanisms of broadcast control is also known as the expanding ring search technique.
Also, each RREQ packets is tagged with a sequence number, called Broadcast ID. This tag provides a mean for nodes to distinguish the different RREQs emanating from the same node and is incremented after each broadcast. A couplet <source IP address, Broadcast ID> uniquely identifies a RREQ and a RREQ with a greater Broadcast ID is fresher. As an intermediate node processes a RREQ issued from a particular node, it records the corresponding Broadcast ID. Later, the intermediate node will only process RREQs from a same source node with a greater Broadcast ID. Other RREQs with smaller Broadcast ID are simply discarded.
Finally, a RREQ carries a hop count field that records the number of hops that the RREQ has traveled through.
3.1.2 Forwarding route requests
An intermediate node I receives a RREQ emanating from a source node S which is requesting a route for a destination node D.
First of all, I checks the Broadcast ID and the source node of the just received RREQ. If the RREQ is obsolete (smaller or equal Broadcast ID), then R does not process it. The RREQ is destroyed.
In case I has to process the RREQ, it first creates or updates a reverse route to the source node S (Figure 6 illustrates all the reverse routes that were created as the RREQ propagated in Figure 5). This route will eventually be used to carry the route reply back
17
to the source node S. The next hop along this path is the node from which the RREQ was received and the corresponding sequence number is the source sequence number that is included in the RREQ.
Once the reverse route is created, I checks if it has a fresh enough route to D. If this is the case, R generates a route reply packet (see paragraph bellow) and unicasts back along the reverse route. At this point, the RREQ does no longer need to be re-broadcast. If R does not have a fresh enough route, it will re-broadcast the RREQ after having consumed one hop of its time to live (TTL decremented by one). A RREQ that has expired (TTL = 0) is not re-broadcast. In case of re-broadcast, the hop count field is also incremented by one.
Figure 6 Reverse route creation
3.1.3 Generating route replies
When a node wants to make a route available (either a destination node or an intermediate node with a fresh enough route), it unicasts a route reply packet (RREP) back to the source node that initiated the discovery process.
The RREP contains IP addresses of both source and destinations nodes and the sequence number of the advertised route. It also includes a hop count field (similar to the one in RREQ packets) and a lifetime field whose value indicates the validity period of the advertised route.
18
3.1.4 Forwarding route replies
As it is illustrated in Figure 7, the forward path (from source to destination) is built as the route reply packet travels down along the reverse path. Each node receiving the RREP creates an entry for the destination node D. The destination sequence number and hop count are copied from the RREP itself and the next hop along this path is the last node that forwarded the RREP.
Figure 7 Forward route creation
If the RREP has not reached its destination (S) yet, then it has to be forwarded to the next hop along the reverse path. Of course, the hop count field is incremented first.
When the RREP finally reaches the source node, it does no longer need to be forwarded. After S has created a forward entry toward D, it automatically destroys the RREP packet. The discovery period is terminated and the newly established route can now be used to send the data packets waiting on the buffer.
So far, two limitations of AODV were pointed out. First, AODV discovers a single route between a pair source/destination. Second, AODV discovery procedure assumes that RREP packets will travel down the same path that RREQ packets went through, but in the other way. This assumption of bi-directionality makes AODV not suitable for situations where uni-directional links may exist. Yet, in a wireless environment, links are unlikely to be symmetric.
3.2 Local Connectivity Management
When a route toward a particular destination is created, a node may use a set of mechanisms in order to monitor its status. In other words, each node along a particular path tries to make sure that the next hop toward that destination remains available and
19
viable as long as needed. If the next hop is active, the route is still valid. If not, the current node has to notify earlier nodes that the route is no longer valid, as described in Section 3.3.
Monitoring can be done in two different fashions: proactive or reactive. In the first approach, some kind of anticipation is introduced. Each node constantly monitors the actual state of activity of its neighbors by updating its local connectivity map whenever a broadcast packet is received. Said differently, whenever a broadcast packet is received the current node updates or creates its routing table entry for the originator node. This entry would have a short lifetime period which would correspond to the maximum period of time that a neighboring node is allowed to remain silent before the current node assumes that it is unavailable. Thus, as long as the neighboring node is available, the corresponding entry remains valid. On the other, if a routing table of a neighboring node happens to expire, the current node assumes that the downstream link has broken and a link failure notification procedure is immediately called.
Sometimes however, a node’s silence is not an accurate indicator of its availability. Therefore, AODV makes use of periodic hello message broadcasts. Basically, if no broadcast packet has been emitted within the last hello interval period of time, a node advertises its presence by broadcasting a specific RREP packet containing its identity and sequence number. Hello messages were also introduced in order to make AODV independent from lower layer platforms—local connectivity management can rely entirely on hello message exchanges. Lower layer messages can be ignored.
The second approach is called proactive. This means that a link breakage is only detected upon a data transmission failure. In this case, a failure may be detected a bit later. However, a reactive approach induces a quite heavy overhead which might not be adequate for mobile ad-hoc networking purposes.
3.3 Route Maintenance
When a link failure is detected along a route, the node upstream propagates a route error (RERR) packet in order to notify earlier nodes down the path of such a breakage. The RERR contains the list of all lost destinations along with their sequence numbers incremented by one.
As the RERR travels down the forward path (Figure 8), each affected node updates its routing table by invalidating the corresponding routes. For each destination included in the RERR packet, the current node sets the distance value to infinity and updates the corresponding sequence number by copying it from the RERR packet. Plus, if the precursor list is not empty, the current unreachable destination remains within the RERR packet which will be broadcast to predecessor nodes. Of course, the RERR will be re-broadcast only if at least one unreachable destination is remaining.
20
Also, note that each node invalidates its entry for a given destination only if the RERR was received from its own next hop toward that same destination. For instance, even though 1’ receives the RERR, 1’ will not invalidate its route for D because As a matter of fact, 1’ receives the RERR from 2 which is not, according to its routing table, the next hop toward D. Therefore, the RERR is simply destroyed.
Figure 8 RERR propagation
3.4 Route expiry and deletion
In keeping with the purely on-demand nature of AODV, each node gets rid of all the routes which are no longer used. Thus, if an active route is not used within the last ACTIVE_ROUTE_TIMEOUT period of time, the current node first invalidates it by incrementing its sequence number and setting the hop count to infinity. The entry is said to be expired. At this point, the entry has not been removed from the routing table. In fact, the entry will stay in the expiry state for a DELETE_PERIOD of time, before being completely expunged from the routing table.
The reason behind the expiry/deletion mechanism is for a node to keep record of the sequence number of the expired route as long as possible. As a matter of fact, if a node deletes a route upon expiry (without transiting through a deletion period), it would lose track of its sequence number and the default value 0 will be used. This situation can lead to the formation of loops, as reported in [10].
But why delete the entry at the first place? In fact, if a node needs to keep track of the sequence number, it should never delete an expired entry. This would certainly be safer. However, such a solution may not be practical in a dynamic network where a node is likely to see lots of nodes for short periods of time. Also, rebooted nodes would have no recollection of any sequence number whatsoever. Therefore, a proper deletion mechanism has to be introduced.
21
ANNEXE II presents the contribution of the University of Pennsylvania to the earlier draft of AODV. The idea is for each node to keep the expired entry in the routing table until no predecessor is pointing at it. In other words, a routing table entry should be deleted from the routing table of each node along the path around the same time. To do so, the DELETE_PERIOD value is chosen as the maximum lifetime that an entry could have within the network. Also, each time a node receives a packet for which it has an expired route, it not only generates a RERR but also delays the deletion time for another DELETE_PERIOD seconds. Thus, the entry will not be deleted until earlier nodes have their entries for that same destination deleted too.
Other features of AODV such as local repair or gratuitous replying were not listed in the above description. For more details, you can refer to [3].
4 Our addition to AODV
In this section, we present some useful additions to AODV in order to cope with a major issue that can occur during the discovery process.
4.1 Problem
In the section '8.3.1. Processing Route Requests' of the 'draft-ietf-manet-aodv-08.txt' it says:
[...] The node always creates or updates a to the Source IP Address in its routing table. If a route to the Source IP Address already "exists", it is updated only if either
(i) the Source Sequence Number in the RREQ is higher than the destination sequence number of the Source IP Address in the route table, or
(ii) the sequence numbers are equal, but the hop count as specified by the RREQ is now smaller than the existing hop count in the routing table.[...]
Assuming that the current node does not have a fresh enough active route to be able to reply, what happens if a route to the Source IP Address already exists but is invalid (waiting for deletion) with a destination sequence number greater than the Source Sequence Number that is included in the RREQ?
The question is: Should the node update its reverse route anyway or should it rather destroy the RREQ?
22
One thing is for sure: The node should definitely not update its route table entry if the sequence number in the RREQ is less than that in the route table entry. It is too risky and may lead to the appearance of loops.
On the other hand, if the node does not update its reverse route, the node should not forward the RREQ either. Because if the node receives an eventual RREP back to the node which originated the RREQ, it would not have a route to forward it anyway.
Here is a simple 3-node scenario to better illustrate such a situation.
A --- B --- C
1) A broadcasts a request looking for C.
2) B receives the RREQ. Let's suppose, B had already a route for A, which has expired very recently and is currently waiting for deletion. B would then have an entry to A with a sequence number incremented by one. In this case, the source sequence number that A had specified in its RREQ is likely to be smaller than the sequence number that B has in its routing table entry for A. So when B receives the RREQ, there is a great probability that B does not update its route to A. However, B still re-broadcasts the RREQ.
3) C receives the RREQ from B. C updates its reverse route to A, considering B as the next hop toward this destination.
At this point, C "thinks" it has a route to A, but this is not the case because B does not have a route to A. The worst part is that C will spread this route whenever it intercepts a RREQ asking for A. This will cost at least a data packet to be dropped and a RERR message to be broadcast.
On the other hand, A may never have a route to C. In fact, when a RREP reaches B, it will be destroyed because, B does not have a route to A. Moreover, when A re-broadcasts its RREQ, the same situation is likely to occur. As a matter of fact, unless a change is sensed, A would keep the same sequence number for itself. Thus, the reverse route B-A will not be created and the same problem shows up.
4.2 Solution
One solution would be for each node to update its own sequence number each time it broadcasts a RREQ packet. Hence, a node should never re-broadcast a RREQ if the reverse route has not been previously updated.
23
In this case, the following sentence "If the node does not have an active route, it rebroadcasts the RREQ from its interface(s)" from the draft should be extended to:
"A node forwards a RREQ only if:(i) It has no route for the requested destination;(ii) It has previously updated or created a reverse route to the source node of the RREQ (the node must have an active route back to the source node of the request if it decides to rebroadcast it)."
5 NIST/AODV OPNET Model Implementation
5.1 Objective
This chapter provides information about the NIST/AODV OPNET Model. This model for the Ad-hoc On-demand Distance Vector routing protocol was developed at the National Institute of Standards and Technology by Lyes Guemari during its stay at the Wireless Communication Technologies Group (WCTG).
As a contribution of NIST, this model was made available to provide a tool for researchers and designers who need to conduct OPNET simulations of Mobile Ad hoc Networks.
5.2 Model description
Along with the AODV routing implementation, the NIST/AODV OPNET Model provides a general framework to simulate a MANET environment. This platform includes a hierarchical structure of models consisting of a network model, a node model, and a set of process models.
As the name states, NIST/AODV OPNET Model was built using the commercially available network simulation tool OPNET by MIL3.
5.2.3 NIST/AODV Node Model
As it is shown in Figure 9, NIST/AODV node model tries to reproduce the so-called OSI stack. The focus being, however, drawn by the AODV routing implementation, some layers have been legitimately omitted. In fact, the primary idea behind the development of the NIST/AODV node model is to provide a test bed around the AODV routing implementation.
24
Each node within the network is uniquely identified with its IP address. In our platform, the IP address is assimilated to the MAC address which must be indicated before the simulation compilation.
Bellow is the list of the different modules that compose the NIST/AODV node model:
- src module: This is the packet source module— It generates packets according to specific packet size and inter-arrival distributions. Once generated, packets are sent to the immediate lower layer (app_manager).
- app_manager module: The application manager module sets a random destination address to the incoming packet and generates a service request primitive to the routing layer in the form of an Internal Communication Interface2 (ICI). Along with the ICI, the just received packet is sent the aodv_routing module.
- aodv_routing module: This module receives the PDU from the application layer and executes the AODV routing algorithm as described in the previous section.
- wlan_mac_intf module (provided by OPNET): This module interface the lower layer module. It receives the packet from the aodv_routing module and hands it over to wlan_mac module and vice-versa.
- wlan_mac module (provided by OPNET): This module is an implementation of the IEEE 802.11[11][13] standard medium access control (MAC) protocol. Some modifications were added to the original model to enable some sort of interaction with the upper layers (especially with the aodv_routing process). For instance, upon transmission failure, the current module hands over an ICI to the upper layers indicating the IP address of the unreachable node.
As the IEEE 802.11 standard is widely used in test beds and simulation platforms, we had practically no choice to not to integrate it within the current model. However, such a supremacy of 802.11 in MANETs is far from being completely justified [14].
- wlan_rx + wlan_tx modules: These modules are implementations of the IEEE 802.11 standard physical layer specifications.
- mobility module: This mobile performs the movement of the current node by changing its position periodically according to the actual movement scheme.
2 An ICI is an interface which allows two processes to exchange a user-defined information.
25
Figure 9 AODV Node Model
5.2.4 NIST/AODV Application Manager (app_manger) Process Model
As we previously mentioned, the primary function of the application manager process is to attribute a destination IP address for each incoming packet. The other function of the app_manger is to “reply” to each received packet by emitting a data packet to the attention of the source node of the received packet. This mechanism was introduced in order to fake a two-way conversation between the members of each pair source/destination.
Inputs
Number of available flows within the network (integer): This value is defined at the simulation level and indicates the maximum authorized number of active source/destination pairs.
Node’s interlocutor (enumerated values: either None, Random, or a specific Node’s address): this value is defined at the process level and indicates the state of activity of the current node. If the interlocutor attribute is set to None, the node is not allowed to initiate a conversation with another node. If the interlocutor attribute is set to a
26
specific node’s address, then node is only authorized to converse with that same node. Finally, if interlocutor is set to Random, the current node may (under the condition of flow availability) pick a random destination IP address and initiate a conversation with the corresponding station.
Figure 10 Application Manager Process Model
Description
The principle is very basic and can be divided into 3 steps.
First step:
On the one hand, the attribution of the flows obeys to a FIFO (first in-first served) policy: the first node transiting to the init state has greater chances to occupy a free spot. On the other hand, each node, at the pre-init state, randomly picks a waiting period before transiting to the init state. The idea is to introduce some sort of discrimination between the existing nodes. Thus, as nodes consecutively transit in the init state, remaining flows are progressively granted to arriving nodes until no more flows are available. Of course, nodes with an interlocutor attribute set to a specific node’s IP address automatically transit to the init state (waiting period at the pre-init state equals 0) and are consequently guaranteed to occupy a free flow.
27
Second step:
Once in the init state, each node checks its interlocutor attribute:
1. If it is set to none, the current node does automatically transit to the idle state and no actions are undertaken;
2. If it is set to a specific node’s IP address, the current node consumes a flow buy decrementing the number of available flows;
3. If it is set to Random, node checks the number of remaining flows, first. Two scenarios are possible. First: At least one flow is unoccupied. In this case, the current node reserves it as in 2 and picks up a random destination node which it will converse with during the simulation time. The interlocutor attribute is then switched from Random to that specific IP address and the node transits to the idle state. Second and last: All flows are reserved. In this case, the current node did not get lucky enough. It switches its interlocutor value to None and proceeds as in 1.
Final step:
The current node is in the idle state and can transit either to the rx (upon packet arrival from the lower layer) or tx (upon packet arrival from the lower layer) state.
When a packet is received from the src module, the current node checks its interlocutor attribute. At this stage, only two values are possible for the interlocutor attribute: None or a specific destination IP address. If the value is None, the current nodes silently discards the data packet and returns to an idle state. On the other case, the current node generates a service request primitive to the aodv_routing module and passes the received packet and the destination IP address (which is stored in the interlocutor attribute) as arguments. In practical, the current process installs an ICI including the destination IP address and sends it along with the data packet to the aodv_routing process. After that, node returns to the idle state.
In the rx state, the current node has just received a packet from the lower layer. As the packet has reached its destination, the current node simply destroys it. Also, if the received packet requires a response, the current node creates a new data packet and generates a service request primitive as described above. This time however, the newly created A-PDU will be destined for the originator of the just received packet.
28
5.2.5 NIST/AODV Routing (aodv_routing) Process Model
The aodv_routing process (Figure 11) implements the AODV routing protocol as specified in the IETF AODV draft version 08. The modifications described in section 4 were also added.
In our effort to accomplish the implementation of the present model, we have tried to make the aodv_routing process model as independent as possible from the rest of the platform (at the node model level). Thus, it would be relatively easy to integrate the same process into another platform.
The remainder of this section presents a general description of the aodv_routing process model. For further details, the reader may refer to the technical documentation [12].
Inputs
AODV routing constants (see AODV Draft [])
Current node’s IP address (integer)
Repair Parameter (enumerated values: enabled, or disabled): If the Repair attribute is set to Enabled, a node may perform a local repair following a link failure. Otherwise, the same node must generate a RERR packet and broadcast it to the neighboring nodes.
Connectivity Parameters (a set of attributes): Indicates the type of requested connectivity support (either None, MAC, HELLO messages, or HELLO+MAC) as described in Section 3.2. If the HELLO mode is selected, the user may choose the type of HELLO messages to be used (either RREQ or RREP). The draft only recommends the use of RREPs, but performance studies show that results are somewhat better with RREQ packets as Hello messages.
Data buffer size (integer): This variable indicates the maximum number of data packets waiting for routes that can be stored in the internal queue. If an extra packet is received while the buffer is full, the just received packet is ignored (destroyed).
Max node traversal time (double): Indicates the maximum time that a data packet is allowed to spend in the data buffer of a given node. Upon this time, the data packet is destroyed.
Max buffer size (integer): Indicates the maximum capacity (in terms of number of packets) of the send buffer that is maintained by each node.
29
Figure 11 AODV Routing Process Model
Description
- Init state: This state consists of the initialization of the process model. User defined attributes are loaded and different variable are initialized (routing table, pending request list, etc). In case Hello messages are selected, a self-interrupt is scheduled to initiate the first Hello Interval. Once the initialization step is accomplished, the process transits in the idle state.
- Rcv_Appl state: The aodv_routine process transits to this state when a service request is received from the upper layer to transmit a data packet to a given destination. The current state first extracts the ICI which is associated to the just received packet and reads the destination IP address of that same packet. The current state then encapsulates the received data packet into an AODV-PDU and fills its header fields with the correct values. After that, the aodv_pk_receive_from_appl() routine is called in order to route the packet to its final destination. For more details, please refer to the technical documentation.
- Rcv_Mac state: This state receives the incoming packet stream from the lower layer. It first checks the type of the received packet then, calls the appropriate function to proceed.
If a packet has reached its final destination, the current state decapsulates its payload and sends it to the app_manager module.
30
- Handle_RREQ_Rebroadcast state: Occurs when a RREP_WAIT_TIMEOUT (see section 3.1.1) timer expires for a given destination (the destination IP address is deducted from the interrupt code). This means that the current node still did not receive a route reply to its request. In this case, the current state checks whether a re-broadcast is possible or not (with regard to the number of retries threshold). If the maximum authorized number of retries is reached, the discovery process for that destination is aborted. Consequently, any data packet awaiting for this route is dropped from the buffer. In the other case, a RREQ packet is rebroadcast.
- Update_Route_Table state: This state occurs when the timer of an entry expires. Three cases are possible.
1.The expired entry is active. Node then invalidates it and schedules a new interruption for its deletion. Besides, if entry is flagged as broken, node resets the breakage flag before it schedules the deletion interrupt. Also, if the expired entry points toward a neighboring node, the current state either generates a RERR and broadcast it to its neighboring nodes or attempt to perform a local repair (according to the Repair attribute value).
2. The expired entry is under repair. In this case, the current state delay the expiration time and wait till the end of the discovery process.
3. The expired entry is invalid. In this case, node simply deletes it from its routing table except if it is under repair.
- Handle_Breakage state: This state is called when a failure to transmit occurs at the MAC Layer. In this case, the MAC Layer notifies the upper layer by sending a NACK message containing both final and next hop destinations of the lost data packet. At this point, two scenario are possible:
1. Repair is allowed. In this case, node performs a local repair by calling the aodv_initiate_maintenance() routine.
2. Repair is not allowed. In this case, node generates a RERR packet by calling the aodv_rerr_pk_generate() routine.
- Rcv_Ack state: Upon Ack reception from a given destination, the current state slides its transmission window and transmits the next waiting packet for that same destination.
- Handle_Pk_Retransmission state: The process transits to this state when a node downstream did not acknowledge a data packet within the appropriate timing frame. The current stat enqueues a copy of the non-acknowledged data packet in the buffer and retransmits calls the appropriate function to retransmit the packet.
31
- Say_Hello state: It has been hello_interval seconds since the last broadcast. Node must broadcast a hello message in order to advertise its presence in the neighborhood.
- Maintain_Local_Conn state: When a packet is received at the physical layer, the latter notifies the routing layer indicating the IP address of the originator node. If the MAC connectivity support is selected, the current state updates its local connectivity map by updating its routing table entry for that same node.
- Stat state: The current process periodically transits to this state in order to collect different global statistics. These statistics are written into a Comma Separated Values (CSV) file which is created at the beginning of each simulation run. Other vector and scalar statistics are also collected through OPNET kernel procedures.
Once again, the reader is invited to consult the technical documentation for further information.
5.2.6 NIST/AODV Mobility Process Model
The mobility process model, shown in Figure 12, implements a random waypoint mobility scheme which is described bellow.
The general motion of a particular node is simulated through a set of discretized small step intervals. A node in motion updates its position every time step period of time. In our simulations, the duration of each step was set to a value of 0.2 seconds.
Figure 12 Mobility Process Model
32
Inputs
Mobility attribute (enumerated values: Enable, or Disabled): Indicates whether the current node is fixed or mobile.
Grid dimensions: Each mobile node moves around the specified area.
Speed limit: Maximum speed that a node in motion may reach.
Pause time: After reaching a target position, a moving node must pause during this period of time before reaching for a new target position.
Description
In the init state, each node picks a random position within the specified grid. After that, each node checks the mobility attribute in order to determine whether it should move or not: If the mobility attribute is set to Disabled, the current node transits immediately to the idle state and remains at the same position during the whole simulation time. In the other case, if the mobility attribute is set to Enabled, the current node transits to the init_mvt state in order to initialize its next movement parameters.
Basically, a moving node chooses a random target position within the grid and a random speed between 0 and the speed limit value. Given these two parameters, the moving node periodically (every step time period) transits from the idle state to the move state until it reaches the target position. While in the move state, a moving node progressively travels by a step time * speed amount of distance toward the target position. After each step movement, the node checks if the target has been reached or not. If so, the current node transits to the idle state and enters a pause time phase. When the pause period arrives to its term, the END_PAUSE condition becomes true and the current node transit to the init_mvt state in order to plan the next trip. On the other hand, if the target position has still not been reached yet, the current returns to idle state and waits for the next step time before returning to the move state.
During nodes movements, the aodv_mob_collect_stat() routine is periodically (after each step time) called to monitor the actual topology of the network. This provides an instant view of link changes along the simulation time. These statistics are also reported into the CSV file generated at the end of each simulation run.
5.3 NIST/AODV Model Validation
The following section describes the methodology that was followed in order to ensure that NIST/AODV OPNET Model operates properly and in conformity with the IETF draft version 8.
33
The idea behind the validation process consisted on using the NIST/AODV OPNET Model in as many scenarios as possible and track the different events ongoing during the simulation time.
Two outputs were used to follow the evolution of each simulation sequence: numerical statistics and on-screen tracings.
The first one gives a global opinion as far as the model correctness is concerned. For instance, a 0 efficiency with a two fixed node networks may indicate a certain dysfunction of the model.
The second output consists on tracing the simulation execution by printing short messages on the screen (see Appendix B). For each node, messages can be printed out along the simulation time in order to track its evolution within the network. As a matter of fact, these messages provide information about its position, its current state on the process, and its response to the current events. This feature is controlled by the DEBUG attribute (node level) whose value indicates the quantity of information to be displayed on the screen (DEBUG = "Second Level" is recommended). If DEBUG is set to "None", no messages will be printed.
This second approach however is not easily scalable. Upon few nodes in the network, printed messages become impossible to follow. The first approach is then more suitable.
6 NIST/AODV Model Study
During the process of validation, we have run different simulations using the node model described in section 5.2.3. Some of these simulations are presented farther in this section.
6.1 The simulation model
In all our runs, we used the same network model that is shown in Figure 13. This network contains 40 mobile nodes which can move around a 1200x800 meters square wide area. Nodes communicate over wireless links with a transmission range of 250 meters. The AODV layer maintains a send buffer of 64 packets, and the node traversal time is set to 30 seconds (a packet may remain within a send buffer for a period of 30 seconds at most).
As far as the traffic model is concerned, we used Continuous Bit Rate (CBR) sources with a rate of 4 packets per second. Packet size is constant and equals to 512 bytes. Each run is a simulation of 900 seconds.
The implementation of 802.11 provided by OPNET showed a lot of dysfunctions during our simulations. For instance, the activation of the virtual carrier sensing (RTS/CTS handshake) always leads to a segmentation fault causing the simulation to stop. The source of such a problem is not quite clear. However, it seems that nodes happen to emit
34
packets of a size null while deferring. These packets, when received at the interface of a given node, are put in a re-segmentation buffer. The packet being of a size null, the re-segmentation routine returns a null packet pointer. The next time that the current node will attempt to manipulate this null packet pointer, the simulation will stop following a segmentation fault.
The RTS/CTS handshake scheme, which is supposed to reduce the effect of the hidden node problem, was therefore deactivated. The results shown later are consequently biased. As a matter of fact, each transmission failure at the MAC layer is reported to the AODV layer as a link breakage. In such a situation, the latter undertakes the maintenance procedure (as described in Section 3.3) which leads to new route discoveries.
The RTS/CTS exchange being deactivated, the chances for link failures because of the hidden node problem are greater and the situation described above is likely to happen more often.
Figure 13 NIST/AODV 40-node Network Model
In our simulations, we have studied the effect of four different parameters:
The Mobility Parameter: we vary this parameter by varying the speed limit attribute described in 5.2.6. The mobility is quantified in the form of a mobility factor which expresses the average relative speed of a node during the simulation time.
The Offered Load Parameter: the offered traffic is controlled through the number of flows in the network. For instance, it is increased by increasing the number of flows.
35
The Repair Parameter: as described in Section 5.2.5, this parameter can be set to either Enabled or Disabled. This study allows us to evaluate the effect of local repair on a MANET.
The Connectivity Parameter: we vary the connectivity support (see Section 5.2.5) and observe the reaction of the network.
6.2 Performance Results
6.3 Metrics
Different metrics were collected in order to evaluate the network performance. The most important metrics are listed bellow:
Efficiency – The ratio of delivered data packets to those offered to the network.
Normalized Overhead Load — The amount of control traffic generated (in bits) per data traffic delivered (in bits).
Average end-to-end delay for data packets — This includes all possible delays from the moment the packet is generated to the moment it is received by the destination node. This metric is expressed in seconds.
Average hop count — Average number of hops traveled by data packets.
Average Discovery Period — Average duration of a discovery period in seconds.
6.4 Results
6.4.1 Varying Mobility and Repair
We vary the Speed Limit parameter between 0 and 20 m/s and measure the corresponding mobility factor (average relative speed). All other parameters are set to their default value (16 flows and no connectivity support). The results are shown in Figures 13 and 14.
Two major observations can be made. First, a quick look to the graphs in Figure 13 shows that the efficiency is relatively mediocre (0.65% at most). This is principally due to the bad performance of the 802.11 implementation used in our model. Second, the affect of mobility is different in each case.
36
Figure 14 Efficiency vs. Mobility
Figure 15 Average end-to-end delay vs. Mobility
37
In case of low mobility (mobility factor < 1), the AODV version with Repair gives better result than the one with no Repair. The reason was implicitly exposed in the beginning of this chapter.
As a matter of fact, nodes being relatively static, link failures are essentially due to transmission failures at the MAC layer level. In other words, these link failures are due to network congestion and not to node movement. In such a case, the version of AODV without Repair features is largely affected. In fact, in this version, each node in this scenario immediately undertakes the maintenance procedure by broadcasting a RERR. This RERR will travel down the path causing packets to be dropped and finally the route to be re-discovered. Considering that the link has not truly broken, these actions cost a lot in term of efficiency.
The Repair version, however, reacts differently to link breakages. As a matter of fact, upon link failure, each node queues a copy of the lost packet and immediately attempts to repair the broken path by initiating a route discovery for the lost destination. As there was no breakage at the first place, the route is quickly restored and packets are delivered to their destinations. Therefore, the version with Repair provides better efficiency.
Figure 14, however, shows smaller delays for the other version (the one without Repair). This observation is biased. In case of no Repair, packets are immediately dropped upon link failure. The average delay is then measured with much less packets. On the other hand, packets waiting for repair are queued in the send buffer. Therefore, delays increase in case of repair because of extra queuing times.
Another interesting observation is noticed in case of high mobility. It seems that efficiency does not collapse when node are frequently moving (Mob. Fact. = 3, for example). Delays however are increasingly larger. The idea is if we do not impose a minimum of QoS and in case of mobility, a data packet is infinitely relayed from a node to another until it finally reaches its destination. Thus, applications with flexible QoS requirements can be easily supported by MANETs.
Finally, both graphs show that the Repair feature is definitely not suitable for networks with frequently changing possibility. Repair attempts usually end-up with a failure and cumulated packets (during repair period) are yet dropped at the end.
6.4.2 Varying Offered Load
In this study, we vary the number of flows in the network. The maximum speed is set to 0.5 m/s in all runs which corresponds to a mobility factor around 0.24 with an interval of 0.01.
All connectivity supports are disabled and local repair is not allowed.
38
Figure 16 Efficiency vs. Offered Load
Figure 17 Average Delay vs. Offered Load
39
Figure 18 Normalized Overhead vs. Offered Load
There is practically nothing to say about Figures 16, 17 and 19 except may be that AODV seems to react quiet well along the increase of the traffic load. The current scenario does certainly not provide a rough situation for the routing protocol, but we can note however that the network start to collapse upon 35 flows. The overhead is multiplied by a factor of 4.5 and delays are very high. The stability of the efficiency between 15 and 30 flows is probably due to a lucky balancing of the traffic within the network (position of source nodes).
Again, the decrease in delays for 40 flows is not due to a better performance of the routing protocols. It is only caused by the fewer number of delivered packets compared to the results obtained for other number of flows.
6.4.3 Varying Connectivity Support
In this set of simulations, we study the affect of the connectivity support in case of average mobility. The Speed limit was set to 5m/s which corresponds to a mobility factor of 0.95 with an interval of 0.05. The number of flows is set to 16. The HELLO_INTERVAL is set to 1 second, and the ALLOWED_HELLO_LOSS is set to 2 (two Hello messages can be lost before assuming a link breakage).
Simulations were run for five different types of connectivity support:
40
None — The routing protocol does not perform any form of connectivity management.
MAC — The routing layer builds its local connectivity map by eavesdropping in the neighborhood (802.11 in the promiscuous mode).
Hello using RREPs — A node advertises its presence by broadcasting a specific RREP packet containing its identity and sequence number.
Hello using RREQs — A node advertises its presence by broadcasting a specific RREQ packet containing its identity and sequence number. Each node receiving such a RREQ replies as for a regular RREQ.
MAC + Hello using RREQs — Combines both supports.
Figure 19 Performance vs. Connectivity Support
First of all, the use of connectivity management provides better results as far as efficiency and delays are concerned (up to 33% more efficiency in case of Hello RREQs). The generated overhead is however multiplied by a factor between 2 and 3.
These observations translate the ambivalence of Hello Messages. On the one hand, Hello messages somewhat increase the performance of the network by allowing broken links to be detected before a packet is sent. We remind you that in case of no connectivity
41
management, link breakages are only detected upon transmission failures (too late). On the other hand, the use of periodic messages considerably increases the routing load of the network. The choice of the Hello parameters (interval + allowed loss) is then crucial. The interval should be small enough to allow link failure detection in time, but big enough to relatively reduce the amount of generated overhead.
The version with MAC support (eavesdropping) provides results somewhere between the version with no support at all and the versions with Hello messages. First, the eavesdropping allows link failure anticipation as for Hello messages, which leads to better performance. However, with the MAC support, if a node remains silent for too long (2 seconds in our simulation), its neighbors assume that it is down and therefore initiate a maintenance procedure. These spurious link failures lead to useless route maintenances which reduce the performance of the network.
Finally, the type of Hello messages has curiously some effects on the protocol behavior. The better performance of RREQs compared to RREPs is probably due to a certain synchronization in building the connectivity map. As a matter of fact, a node using RREPs as Hello messages only advertises its presence to the neighbors. The same node cannot learn of its neighbors unless they, too, advertise their presence through a Hello message broadcast. Thus, each node will progressively learn of its neighbors as they respectively declare themselves in the “locality” by broadcasting a Hello message.
The approach is slightly different in case of RREQS. As a matter of fact, a node using RREQs not only advertises its presence by broadcasting a Hello messages, but it simultaneously asks its neighbors to declare themselves by replying to its RREQs. Thus, nodes from the same “locality” will share a same complete connectivity map in a synchronous manner. On other words, each group of neighbors will have the same understanding of the “local” topology.
The use of Hello messages has certainly proven its efficacy by anticipating link failures. However, periodic broadcasts of such messages have negative affects on network congestion and battery lifetime. Therefore, the use of Hello messages should be adjusted dynamically according to the given state of the network.
42
7 Summary
In this report, we have presented an OPNET simulation model for the Ad-hoc On demand Distance Vector routing protocol that was developed at the National Institute of Standards and Technology. This implementation of AODV includes all the features listed bellow:
Expanding ring search technique while controlling route request broadcasts; Local connectivity management (Hello messages + Link Layer Notifications +
Passive acknowledgements); Local repair in case of link breakage; Early quenching of requests + Gratuitous replies; Distributed route storage; Route expiry and deletion.
In order to provide a reference simulation platform, this implementation of the AODV protocol is supplied with a hierarchical structure of models consisting of a simulation model, a network model, a node model, and finally a set of process models.
In addition to the AODV routing process model, users can find an implementation of the random waypoint mobility scheme and an implementation of the 802.11 protocol. The latter was provided by OPNET as an extension to its radio package.
While our node model is admittedly simple, it allowed us to evaluate the performance of our implementation. In fact, although great care has been taken while developing NIST/AODV OPNET Model, some simulations were run in order to ensure that the model operates properly and in conformity with the IETF draft version 8.
These simulations will reveal, later, a dysfunction of the 802.11 implementation which was reported to OPNET. However, we believe our model provides a reference basis for researchers and designers who need to conduct OPNET simulations of Mobile Ad hoc Networks (MANETs). Plus, in our effort to accomplish the implementation of the present model, we have tried to make the AODV routing process model as portable as possible. Thus, users can easily integrate it in their existing platform.
Finally, two different versions of the NIST/AODV OPNET model were made available for download (March 01 for version I, and August 01 for version II). The most current information on NIST/AODV OPNET Model, including updates, can be found on the NIST Wireless Communications Technologies Group website - http://w3.antd.nist.gov/wctg.
43
References
[1] J. Macker and S. CorsonMobile Ad-hoc NETwork (MANET). URL:http://www.ietf.org/html.charters/manet-charter.html, 1997. IETF Working Group Charter.
[2] L. Peterson and B. Davie“Computer Network – A system approach”. SF, Prentice Hall.
[3] C. Perkins, E. Royer, and S. Das“Ad-hoc On-demand Distance Vector (AODV) routing”http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-08.txt, 2001. IETF Internet Draft.
[4] OPNET Technologies, Inc. / 7255 Woodmont Av. Suite 250/ Bethesda, MD, USA.http://www.opnet.com/
[5] E.W. Dijkstra“A note on two problems in connection with graphs”. Numerical Mathematics, 1959.
[6] D. Bertsekas and R. Gallager.“Data Networks”. SF, Prentice Hall - 1987.
[7] S. Keshav“An engineering Approach to Computer Networking: ATM Networks, the Internet and the Telephone Network”. Addison – Wesley, 1997.
[8] C. Perkins and P. Bhagwat.“Highly dynamic destination sequenced distance-vector routing”. ACM SIGCOMM conference, 1994.
[9] E. Royer and C. Toh“A review of current routing protocols for Ad hoc mobile wireless networks”. IEEE Personal Communications, 1999.
[10] K. Bhargavan, D. Obradovic, and C. Gunter“Analyzing the Occurrence of Loops in AODV”, 1999.
[11] IEEE standards Department. Wireless Lan medium access control (MAC) and physical layer (PHY) specifications, IEEE standards 802.11 – 1997.
[12] L. Guemari“NIST AODV Technical Documentation”, 2001.
[13] IEEE 802.11 Tutorial. URL: http://www.breezecom.com[14] S. Xu and T. Saadawi
“Does the IEEE 802.11 MAC Protocol work well in Multihop Wireless Ad Hoc Networks?”. IEEE Communications Magazine, 2001.
44
45
Appendix A – Sequence numbers and loop formations
AODV uses a set of “sequence numbers’ in order to prevent the formation of loops in its routing tables. In this annex, we will introduce a sample scenario that shows the possibility of loop formation and how AODV manages to avoid such a disastrous issue.
First, let’s consider a 3-node network in the ad-hoc mode.
Node ‘A’ knows of a route to the node C that goes through node ‘B’. The sequence number along this route is 0, for instance.Now, if the route toward C breaks, the routing protocol reacts differently whether sequence numbers are used or not.
First scenario (No use of sequence numbers):
Following the loss of ‘C’, ‘B’ would eventually perform a local repair on its routing table. So, ‘B’ would broadcast a RREQ asking for ‘C’.‘A’ hears the RREQ. It checks its routing table, and finds out it has a route for ‘C’. ‘A’ replies immediately.When ‘B’ receives the RREP from ‘A’, it creates an entry for ‘C’ with ‘A’ as the next hop node for this destination. The problem is that ‘A’ has an entry for ‘C’ that indicates ‘B’ as the next hop node for that same destination.So, when a packet destined for ‘C’ arrives at the routing interface of the node ‘B’, ‘B’ will forward it to ‘A’. In its turn, the node ‘A’ will forward any packet destined for ‘C’ to the node ‘B’. A loop is formed.
Second scenario (With use of sequence numbers):
Node ‘B’ would still broadcast a RREQ asking for ‘C’. But this time, ‘B’ has previously incremented the destination sequence number for ‘C’ (it is set to 1). So, when ‘A’ receives the RREQ, it wouldn’t have a fresh enough route to answer the RREQ (its sequence number for this route is 0, whereas B is asking for a route whose sequence number is at least equal to 1). ‘A’ forwards the RREQ in its turn and the loop is avoided.
Attributing a sequence number to routes allows the network to have an idea of how fresh a route is. Each time a route changes, its sequence number is incremented. Also, a route with a greater sequence number is always preferred when building routing table entries.
A B C
A B C
46
Appendix B – 3-node sample scenario log file
This log file was obtained after running a simulation with the 3-node network shown bellow:Node 0 --- Node 1 --- Node 2Node 0 initiates a discovery looking for Node 2. Node 0 and Node 2 are not within transmission range. Details follow.
|-----------------------------------------------------------------------------|| |||| ||||| || || ||||| |||||||| Network Simulation of: || || || || ||| ||| || || || NIST_AODV-3n_1src_secenar || || || ||||| |||| || ||||| || || || || || || |||| || || Simulation and Model Library Copyright || || || || || ||| || || 1987-2000 by OPNET Technologies, Inc. || |||| || || || ||||| || as a part of OPNET Release 7.0.B ||-----------------------------------------------------------------------------|| O P T I M U M N E T W O R K P E R F O R M A N C E ||-----------------------------------------------------------------------------|| OPNET Technologies, Inc. / 7255 Woodmont Av. Suite 250/ Bethesda, MD, USA || TEL: +1.240.497.3000 / FAX: +1.240.497.3001 ||-----------------------------------------------------------------------------||-----------------------------------------------------------------------------|| Reading network model (NIST_AODV-3n_1src_secenar) ||-----------------------------------------------------------------------------||-----------------------------------------------------------------------------|| Initializing results. ||-----------------------------------------------------------------------------||-----------------------------------------------------------------------------|| Progress: Time (0 sec.), Events (0) || Speed: Average (0 events/sec.), Current (0 events/sec.) || Time: Elapsed (0 sec.) ||-----------------------------------------------------------------------------|
<node 0 @ app manager> INIT :: - Current time = 0.000000 - Flows avail = 1 - Dest is = 2 (None = -2, Rand = -1)
<node 1 @ app manager> INIT :: - Current time = 0.000000 - Flows avail = 0 - No more spots left (0 flows avail)
<node 2 @ app manager> INIT :: - Current time = 0.000000 - Flows avail = 0 - No more spots left (0 flows avail)
|------------------------------------------------------------------------------||====] Node 0 [====| @ Rcv_Appl Time: 0.660296 ||------------------------------------------------------------------------------|
- A DATA pk has been received from application layer> Destination is 2> Printing packet:****************************************** DATA Packet ****************************************** From = 0 ** To = 0 ********************************** Hop Count = 0 *********************************
47
* Source = 0 ** Destination = 2 *********************************> Buffer empty: Packet processed.> No active route was found: Packet queued> No request pending: continue processing> Route either invalid or non-existent: Initiate discovery> Initiating discovery for destination 2> Generating RREQ> Sending packet to lower layer: size = 192> Printing packet:***************************************** REQUEST Packet **************************************** TTL = 2 ********************************** From = 0 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 0 ** HopCount = 0 ** BroadcastID = 0 ** SrcSeqNb = 0 *********************************
|------------------------------------------------------------------------------||====] Node 1 [====| @ Rcv_Mac Time: 0.660713 ||------------------------------------------------------------------------------|
- A REQUEST pk has been received from mac layer> Printing packet:***************************************** REQUEST Packet **************************************** TTL = 2 ********************************** From = 0 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 0 ** HopCount = 0 ** BroadcastID = 0 ** SrcSeqNb = 0 *********************************> Request is fresh enough: RREQ processed> Create or update reverse entry> Entry does not exist: create it> Reverse route was created: Source node is 0> Printing entry:|=======================================|| Route [1] x [0] ||=======================================|| Next Hop = 0 || DestSeqNb = 0 || Hop Count = 1 || Last Hop Count = infinity || ExpirationTime = 3.360713 ||---------------------------------------|| Breakage = 0 || Repair = 0 ||---------------------------------------|
48
| Precursor List: ||---------------------------------------||* -1 *||=======================================|> Serve destination 0: checking buffer> Buffer is empty> Request has reached an intermediate node: Checking for entry> No active route was found: Forwarding RREQ to neighbors> TTL still valid + reverse route exists: RREQ forwarded> Sending packet to lower layer: size = 192> Printing packet:***************************************** REQUEST Packet **************************************** TTL = 1 ********************************** From = 1 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 0 ** HopCount = 1 ** BroadcastID = 0 ** SrcSeqNb = 0 *********************************
|------------------------------------------------------------------------------||====] Node 0 [====| @ Rcv_Mac Time: 0.662032 ||------------------------------------------------------------------------------|
- A REQUEST pk has been received from mac layer> Printing packet:***************************************** REQUEST Packet **************************************** TTL = 1 ********************************** From = 1 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 0 ** HopCount = 1 ** BroadcastID = 0 ** SrcSeqNb = 0 *********************************> Maintain local conn: entry was created|=======================================|| Route [0] x [1] ||=======================================|| Next Hop = 1 || DestSeqNb = 0 || Hop Count = 1 || Last Hop Count = infinity || Current Time = 0.662032 || ExpirationTime = 2.662032 ||---------------------------------------|| Breakage = 0 || Repair = 0 ||=======================================|> Current node is the source of the present request: RREQ
discarded
49
|------------------------------------------------------------------------------||====] Node 2 [====| @ Rcv_Mac Time: 0.662032 ||------------------------------------------------------------------------------|
- A REQUEST pk has been received from mac layer> Printing packet:***************************************** REQUEST Packet **************************************** TTL = 1 ********************************** From = 1 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 0 ** HopCount = 1 ** BroadcastID = 0 ** SrcSeqNb = 0 *********************************> Maintain local conn: entry was created|=======================================|| Route [2] x [1] ||=======================================|| Next Hop = 1 || DestSeqNb = 0 || Hop Count = 1 || Last Hop Count = infinity || Current Time = 0.662032 || ExpirationTime = 2.662032 ||---------------------------------------|| Breakage = 0 || Repair = 0 ||=======================================|> Request is fresh enough: RREQ processed> Create or update reverse entry> Entry does not exist: create it> Reverse route was created: Source node is 0> Printing entry:|=======================================|| Route [2] x [0] ||=======================================|| Next Hop = 1 || DestSeqNb = 0 || Hop Count = 2 || Last Hop Count = infinity || ExpirationTime = 3.362032 ||---------------------------------------|| Breakage = 0 || Repair = 0 ||---------------------------------------|| Precursor List: ||---------------------------------------||* -1 *||=======================================|> Serve destination 0: checking buffer> Buffer is empty> Request has reached its destination: Node replies> RREP has been generated: sending to MAC> Add next Hop Toward Source (1) to the precursor list of (2)> Sending packet to lower layer: size = 160> Printing packet:********************************
50
********** REPLY Packet ***************************************** By = 2 ********************************** From = 2 ** To = 1 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 1 ** HopCount = 0 ** Lifetime = 10 *********************************
|------------------------------------------------------------------------------||====] Node 1 [====| @ Rcv_Mac Time: 0.663220 ||------------------------------------------------------------------------------|
- A REPLY pk has been received from mac layer> Printing packet:****************************************** REPLY Packet ***************************************** By = 2 ********************************** From = 2 ** To = 1 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 1 ** HopCount = 0 ** Lifetime = 10 *********************************> Forward route was created: destination node is 2> Forwarding RREP to the next hop along the path> Packet sent to MAC> Add next Hop Toward Source (0) to the precursor list of (2)> Printing entry:|=======================================|| Route [1] x [2] ||=======================================|| Next Hop = 2 || DestSeqNb = 1 || Hop Count = 1 || Last Hop Count = infinity || ExpirationTime = 10.663220 ||---------------------------------------|| Breakage = 0 || Repair = 0 ||---------------------------------------|| Precursor List: ||---------------------------------------||* 0 *||=======================================|> Sending packet to lower layer: size = 160> Printing packet:****************************************** REPLY Packet ***************************************** By = 2 ********************************** From = 1 *
51
* To = 0 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 1 ** HopCount = 1 ** Lifetime = 10 *********************************> Serve destination 2: checking buffer> Buffer is empty
|------------------------------------------------------------------------------||====] Node 0 [====| @ Rcv_Mac Time: 0.664358 ||------------------------------------------------------------------------------|
- A REPLY pk has been received from mac layer> Printing packet:****************************************** REPLY Packet ***************************************** By = 2 ********************************** From = 1 ** To = 0 ********************************** Source = 0 ** Destination = 2 ** DestSeqNb = 1 ** HopCount = 1 ** Lifetime = 10 *********************************> RREP has reached its final destination> Forward route was created: destination node is 2> Printing entry:|=======================================|| Route [0] x [2] ||=======================================|| Next Hop = 1 || DestSeqNb = 1 || Hop Count = 2 || Last Hop Count = infinity || Current Time = 0.664358 || ExpirationTime = 10.664358 ||---------------------------------------|| Breakage = 0 || Repair = 0 ||=======================================|> No more forward: RREP destroyed> A request was pending: cancel it, and serve buffer> Serve destination 2: checking buffer> 1 packets waiting|=======================================|| Route [0] x [2] ||=======================================|| Next Hop = 1 || DestSeqNb = 1 || Hop Count = 2 || Last Hop Count = infinity || Current Time = 0.664358 || ExpirationTime = 10.664358 ||---------------------------------------|| Breakage = 0 || Repair = 0 |
52
|=======================================|> Buffer not empty: 1 packets queued> A route is available: checking transmission window> Window is free: sending packet> Printing path from 0 to 2: [0] -----> [1]> Sending packet to lower layer: size = 4096> Printing packet:****************************************** DATA Packet ****************************************** From = 0 ** To = 1 ********************************** Hop Count = 0 ********************************** Source = 0 ** Destination = 2 *********************************
|------------------------------------------------------------------------------||====] Node 1 [====| @ Rcv_Mac Time: 0.669681 ||------------------------------------------------------------------------------|
- A DATA pk has been received from mac layer> Printing packet:****************************************** DATA Packet ****************************************** From = 0 ** To = 1 ********************************** Hop Count = 0 ********************************** Source = 0 ** Destination = 2 *********************************> Destination is 2> Buffer empty: Packet processed.> A route is available: checking transmission window> Window is free: sending packet> Printing path from 1 to 2: [1] -----> [2]> Sending packet to lower layer: size = 4096> Printing packet:****************************************** DATA Packet ****************************************** From = 1 ** To = 2 ********************************** Hop Count = 1 ********************************** Source = 0 ** Destination = 2 *********************************
|------------------------------------------------------------------------------||====] Node 0 [====| @ Rcv_Ack Time: 0.669806 ||------------------------------------------------------------------------------|
- Destination 2 aknowledged [Ack rcvd from node 1]> Sliding transmission window
53
> Serving left packets (if any)> Serve destination 2: checking buffer> Buffer is empty
|------------------------------------------------------------------------------||====] Node 2 [====| @ Rcv_Mac Time: 0.674905 ||------------------------------------------------------------------------------|
- A DATA pk has been received from mac layer> Printing packet:****************************************** DATA Packet ****************************************** From = 1 ** To = 2 ********************************** Hop Count = 1 ********************************** Source = 0 ** Destination = 2 *********************************> Data packet has reached its final destination> Pk rcvd: nb hop = 2> Sending pdu to upper layer
|------------------------------------------------------------------------------||====] Node 2 [====| @ Rcv_Appl Time: 0.674905 ||------------------------------------------------------------------------------|
- A DATA pk has been received from application layer> Destination is 0> Printing packet:****************************************** DATA Packet ****************************************** From = 0 ** To = 0 ********************************** Hop Count = 0 ********************************** Source = 2 ** Destination = 0 *********************************> Buffer empty: Packet processed.> A route is available: checking transmission window> Window is free: sending packet> Printing path from 2 to 0: [2] -----> [1]> Sending packet to lower layer: size = 4096> Printing packet:****************************************** DATA Packet ****************************************** From = 2 ** To = 1 ********************************** Hop Count = 0 ********************************** Source = 2 ** Destination = 0 *********************************
54