SECURE DATA TRANSMISSION IN MOBILE AD-HOC NETWORK USING RDSDV PROTOCOL

Copy­right Notice & Dis­claimer

© Atul Patil, 2015. All rights reserved. This arti­cle, titled “Secure Data Trans­mis­sion in Mobile Ad-Hoc Net­work Using RDSDV Pro­to­col”, was authored and pub­lished by Atul Patil. It was orig­i­nal­ly fea­tured in the Inter­na­tion­al Jour­nal of Research in Com­merce, IT & Man­age­ment, ISSN: 2231–1009, Vol­ume 5, Issue 12 (Decem­ber 2015). The orig­i­nal pub­li­ca­tion can be accessed at https://ijrcm.org.in/article_info.php?article_id=6175.

Dis­claimer: This arti­cle is repub­lished here by the orig­i­nal author, Atul Patil, in accor­dance with the copy­right poli­cies of the Inter­na­tion­al Jour­nal of Research in Com­merce, IT & Man­age­ment. The con­tent remains unchanged to pre­serve its orig­i­nal­i­ty. For any inquiries or copy­right-relat­ed mat­ters, please con­tact the author direct­ly.

ABSTRACT

In mobile ad hoc net­work (MANET) is an autonomous sys­tem of mobile nodes. The nodes are free to move arbi­trar­i­ly. Due to lack of a cen­tral­ized secure infra­struc­ture, the com­mu­ni­ca­tion is prone to secu­ri­ty attacks and the nodes can be eas­i­ly com­pro­mised. Secu­ri­ty has become one of the major issues for data com­mu­ni­ca­tion over wired and wire­less net­works so var­i­ous secu­ri­ty-enhanced mea­sures have been pro­posed to improve the secu­ri­ty of data trans­mis­sion over pub­lic networks.The objec­tive of this work is toim­prove rout­ing secu­ri­ty we rep­re­sent a proac­tive mech­a­nism as Ran­dom­ized rout­ing that explores the exis­tence of mul­ti­ple routes and forces pack­ets to take alter­nate paths ran­dom­ly from its neigh­bors that is a Ran­dom­ize deliv­ery path for secure data trans­mis­sion. We main­tain neigh­bor­ing nodes of each node by send­ing hel­lo pack­ets. Then we find out deliv­ery path from neigh­bor­ing nodes by ran­dom oper­a­tion exclud­ing pre­vi­ous hop which is main­tained as his­to­ry node. Pro­to­col RDSDV is imple­ment­ed to ran­dom­ize deliv­ery paths and com­pared the proac­tive rout­ing pro­to­cols DSDV and RDSDV for dif­fer­ent num­ber of nodes. The per­for­mance of these pro­to­cols is mea­sured under a par­tic­u­lar sce­nario on the basis of three met­rics as Pack­et deliv­ery ratio, e2e delay and jit­ter. This work is imple­ment­ed in Net­work Sim­u­la­tor ver­sion 2.35.

KEYWORDS

mobile nodes, pack­ets, rout­ing, secu­ri­ty.

1.  W   INTRODUCTION

ire­less cel­lu­lar sys­tems have been in use since 1980s. Wire­less sys­tems oper­ate with the aid of a cen­tral­ized sup­port­ing struc­ture such as an access point. These access points assist the wire­less users to keep con­nect­ed with the wire­less sys­tem, when they roam from one place to the oth­er. The pres­ence of a fixed sup­port­ing struc­ture lim­its the adapt­abil­i­ty of wire­less sys­tems. In oth­er words, the tech­nol­o­gy can­not work effec­tive­ly in places

where there is no fixed infra­struc­ture. Future gen­er­a­tion wire­less sys­tems will require easy and quick deploy­ment of wire­less net­works. This quick net­work deploy­ment is not pos­si­ble with the exist­ing struc­ture of cur­rent wire­less sys­tems.

Wire­less net­work­ing is an emerg­ing tech­nol­o­gy that allows users to access infor­ma­tion and ser­vices elec­tron­i­cal­ly, regard­less of their geo­graph­ic posi­tion. Wire­less net­works can be clas­si­fied in two types: Cen­tral­ized approach Or Infra­struc­ture Net­works and Decen­tral­ized approach or Infra­struc­ture less (ad-hoc) Networks[1]. Infra­struc­ture net­work con­sists of a net­work with fixed and wired gate­ways. A mobile host com­mu­ni­cates with a bridge in the net­work (called base sta­tion) with­in its com­mu­ni­ca­tion radius. The mobile unit can move geo­graph­i­cal­ly while it is com­mu­ni­cat­ing. When it goes out of range of one base sta­tion, it con­nects with new base sta­tion and starts com­mu­ni­cat­ing through it. This is called hand­off. In this approach the base sta­tions are fixed.

In con­trast to infra­struc­ture based wire­less net­work, in ad-hoc net­works all nodes are mobile and can be con­nect­ed dynam­i­cal­ly in an arbi­trary man­ner. A MANET is a col­lec­tion of wire­less mobile nodes form­ing a tem­po­rary net­work with­out using any exist­ing infra­struc­ture or any admin­is­tra­tive sup­port. The wire­less ad-hoc net­works are self-cre­at­ing, self-orga­niz­ing and self-admin­is­trat­ing. The nodes in an ad-hoc net­work­can be a lap­top, cell phone, PDA or any oth­er device capa­ble of com­mu­ni­cat­ing with those nodes locat­ed with­in its trans­mis­sion range. The nodes can func­tion as routers, which dis­cov­er and main­tain routes to oth­er nodes. The ad-hoc net­work may be used in emer­gency search-and-res­cue oper­a­tions, bat­tle­field oper­a­tions and data acqui­si­tion in inhos­pitable ter­rain.

Nodes in mobile ad-hoc net­work are free to move and orga­nize them­selves in an arbi­trary fash­ion. Each user is free to roam about while com­mu­ni­ca­tion with oth­ers. The path between each pair of the users may have mul­ti­ple links and the radio between them can be het­ero­ge­neous. This allows an asso­ci­a­tion of var­i­ous links to be a part of the same network.In ad-hoc net­works, dynam­ic rout­ing pro­to­col must be need­ed to keep the record of high degree of node mobil­i­ty, which often changes the net­work topol­o­gy dynam­i­cal­ly and unpre­dictably.

The secu­ri­ty of com­mu­ni­ca­tion in ad hoc wire­less net­works is impor­tant, espe­cial­ly in mil­i­tary appli­ca­tions. The absence of any cen­tral coor­di­na­tion mech­a­nism and shared wire­less medi­um makes MANETs more vul­ner­a­ble to dig­i­tal/­cy­ber-attacks than wired net­works. These attacks are gen­er­al­ly clas­si­fied into two types: pas­sive and active attacks. Pas­sive attacks do not influ­ence the func­tion­al­i­ty of a con­nec­tion. An adver­sary aims to inter­fere in a net­work and read the trans­mit­ted infor­ma­tion with­out chang­ing it. If it is also pos­si­ble for the adver­sary to inter­pret the cap­tured data, the require­ment of con­fi­den­tial­i­ty isvi­o­lat­ed. It’s dif­fi­cult to rec­og­nize pas­sive attacks because under such attacks the net­work oper­ates nor­mal­ly.

In gen­er­al, encryption.[2] is used to com­bat such attacks. Active attacks aim to change or destroy the data of a trans­mis­sion or attempt to influ­ence the nor­mal func­tion­ing of the net­work. Active attacks when per­formed from for­eign net­works are referred to as exter­nal attacks. If nodes from with­in the adhoc net­work are involved, the attacks are referred to as inter­nal attacks

2.  LITERATURE REVIEW

C. Vil­lamizar [3] pro­posed the deliv­ery of secret infor­ma­tion across inse­cure net­works. They pro­posed an end-to-end data deliv­ery scheme called secure pro­to­col for Reli­able data deliv­ery (SPREAD).The basic idea of SPREAD is to improve the con­fi­den­tial­i­ty by using mul­ti­path rout­ing.

D. Clark et al [4] pro­posed a sim­ple algo­rithm called Adap­tive Mul­ti-Path rout­ing (AMP) algo­rithm for dynam­ic traf­fic engi­neer­ing with­in autonomous sys­tems. In con­trast to relat­ed mul­ti­path rout­ing pro­pos­als, AMP does not employ a glob­al per­spec­tive of the net­work in each node. Here avail­able infor­ma­tion is restrict­ed to a local scope, through which sig­nal­ing over­head and mem­o­ry con­sump­tion in routers are reduced.

S. Kent, et al. [5] explored a secu­ri­ty enhanced dynam­ic rout­ing algo­rithm which ran­dom­izes the paths in which the data pack­ets are sent. This algo­rithm is effi­cient and com­pat­i­ble with most­ly used rout­ing pro­to­cols like Rout­ing Infor­ma­tion Pro­to­col (RIP) and Des­ti­na­tion-sequenced Dis­tance Vec­tor (DSDV) pro­to­col for wired and wire­less net­works respec­tive­ly. Both the above stat­ed pro­to­cols need to exchange extra con­trol mes­sages. But con­trol mes­sages are avoid­ed in secu­ri­ty enhanced dynam­ic rout­ing. The main objec­tive in it is to min­i­mize the path sim­i­lar­i­ty i.e. the path tak­en by the con­sec­u­tive pack­ets must not be the same.Virtual Pri­vate Net­works [5], or VPNs, have been used as a way to secure­ly inter­con­nect a (typ­i­cal­ly small) num­ber of sites. While pri­vate net­works use ded­i­cat­ed lines, VPNs try to imple­ment pri­vate net­works atop a pub­licly-acces­si­ble com­mu­ni­ca­tion infra­struc­ture like the Inter­net. VPNs typ­i­cal­ly employ some com­bi­na­tion of encryp­tion, authen­ti­ca­tion, and access con­trol tech­niques to allow par­tic­i­pat­ing sites to com­mu­ni­cate secure­ly.

The emer­gence of IPsec [6] as a IETF stan­dard­ized pro­to­col has prompt­ed VPN solu­tions to use IPsec as the under­ly­ing net­work-lay­er pro­to­col. Secure BGP (S‑BGP)

[7] makes use of pub­lic key and autho­riza­tion infra­struc­ture, as well as IPsec to ver­i­fy the authen­tic­i­ty and autho­riza­tion of con­trol traf­fic gen­er­at­ed by the Bor­der Gate­way Pro­to­col (BGP).

Onion rout­ing [7] is anoth­er approach to secu­ri­ty that focus­es on hid­ing the iden­ti­ties of com­mu­ni­ca­tors. It uses sev­er­al lay­ers of encryp­tion, where each lay­er is used to encrypt the trans­mis­sion between routers on each end of a link. Because of the many lay­ers of encryp­tion, routers are unable to decrypt the data or even the source and des­ti­na­tion address­es. All that a router can deci­pher is the next-hop infor­ma­tion. While onion rout­ing is very effec­tive for anonymi­ty, it is not very effi­cient: each con­nec­tion must be built and torn down, routers must encode and decode pack­ets, and mem­o­ry-inten­sive source rout­ing is used. More recent­ly, moti­vat­ed by con­stant dis­trib­uted denial-ofser­vice attacks (DDoS) to the Inter­net, sev­er­al research efforts have focused on address­ing rout­ing-lev­el secu­ri­ty.

Cen­ter track [8] uses an IP over­lay net­work com­posed of Cen­ter track routers to log pack­ets. Using the result­ing logs, it is pos­si­ble to recon­struct the path tra­versed by attacker’s pack­ets.

IP trace back [9] tries to accom­plish the same goal of track­ing DDoS attacks by trac­ing pack­ets back to their source. The IP track­back mech­a­nism uses prob­a­bilis­tic. Pack­et mark­ing at routers which allows a vic­tim to iden­ti­fy the path(s) attack traf­fic tra­versed with­out sup­port from ser­vice providers/administrators.

Anoth­er relat­ed effort is the Resilient Over­lay Net­works (RON) project [11] whose goal is to improve the per­for­mance and robust­ness of net­work-lay­er rout­ing. RON nodes mon­i­tor cur­rent rout­ing paths and decide whether to choose oth­er routes (by select­ing alter­nate appli­ca­tion-lay­er paths through oth­er RON nodes) to meet appli­ca­tion-spe­cif­ic per­for­mance require­ments.

Exist­ing work on secu­ri­ty-enhanced data trans­mis­sion includes the designs of cryp­tog­ra­phy algo­rithms and sys­tem infra­struc­tures and secu­ri­ty-enhanced rout­ing meth­ods. Their com­mon objec­tives are often to defeat var­i­ous threats over the Inter­net, includ­ing eaves­drop­ping, spoof­ing, ses­sion hijack­ing, etc.Among many well-known designs for cryp­tog­ra­phy based sys­tems, the IP Secu­ri­ty (IPSec) and the Secure Sock­et Lay­er are pop­u­lar­ly sup­port­ed and imple­ment­ed in many sys­tems and plat­forms. Although IPSec and SSL do great­ly improve the secu­ri­ty lev­el for data trans­mis­sion, but they intro­duce sub­stan­tial over­heads which is unavoid­able. Espe­cial­ly on gateway/host per­for­mance and effec­tive net­work band­width. For exam­ple, the data trans­mis­sion over­head is 5 cycles/byte over an Intel Pen­tium II with the Lin­ux IP stack alone, and the over­head increas­es to 58cycles/byte when Advanced Encryp­tion Stan­dard (AES) is adopt­ed for encryption/decryption. Dif­fer­ent­from the past work on the designs of cryp­tog­ra­phy algo­rithms and sys­tem infra­struc­tures, weim­ple­ment­e­dRan­dom­ize deliv­ery paths algo­rithm for data trans­mis­sion

3.  RDSDV IMPLEMENTATION

The objec­tive of imple­ment­ed work is to a Ran­dom­ize deliv­ery path for secure data trans­mis­sion. The deliv­ery of a pack­et with the des­ti­na­tion at a node in order to min­i­mize the prob­a­bil­i­ty that pack­ets are eaves­dropped over a spe­cif­ic link, a ran­dom­iza­tion process for pack­et deliv­er­ies. In this process, the pre­vi­ous next- hop for the source node s is iden­ti­fied in the first step of the process. Then, the process ran­dom­ly picks up a neigh­bor­ing node as the next hop for the cur­rent pack­et trans­mis­sion. The exclu­sion for the next hop selec­tion avoids trans­mit­ting two con­sec­u­tive pack­ets in the same link, and the ran­dom­ized pick­up pre­vents attack­ers from eas­i­ly pre­dict­ing rout­ing paths for the com­ing trans­mit­ted packets.The exist­ing sys­tem relies on dis­tance infor­ma­tion exchanged among neigh­bor­ing nodes for the seek­ing of rout­ing paths. in dis­tance-vec­tor-based imple­men­ta­tions, those based on rip, each node ni main­tains a rout­ing table in which each entry is asso­ci­at­ed with a unique des­ti­na­tion node (t), an esti­mat­ed min­i­mal cost to send a pack­et to t , and the next node cost to send a pack­et to t (next hop). we mod­i­fy rout­ing table entry by adding set of node can­di­dates for the next hop and as a set of entries records the his­to­ry for pack­et deliv­er­ies through the node ni to the des­ti­na­tion node t.

4.  RANDOMIZED NEXT HOP SELECTION ALGORITHM

1: Let hs be the used nex­thop for the pre­vi­ous pack­et deliv­ery for the source node s. 2: pre­pare neigh­bor list of node s by send­ing hel­lo pack­ets.

3: if neigh­bor list is > 1 then

4: Ran­dom­ly choose a node x from neigh­bor list

If x equal to hs then repeat from step 3 three times else

send the pack­et pkt to the node x.

5: set hs as node x, and update the rout­ing table of node n. 7: Send the pack­et pkt to hs.

9: else

10: Ran­dom­ly choose a node y from neigh­bor list and send the pack­et pkt to the node y. 11: set hs as y, and update the rout­ing table of Ni.

12: end if

5.  EXPRIMENTAL RESULT

SIMULATION PARAMETERS

Fol­low­ing table shows net­work sim­u­la­tion para­me­ters which are con­fig­ured in tcl script as net­work inter­face, queue type and sim­u­la­tion area and oth­ers.

TABLE 1: NETWORK SIMULATION PARAMETER

Para­me­ters	Val­ues
Net­work interface/channel type	Wire­less
Radio-prop­a­ga­tion mod­el	TwoRay­Ground
Net­work inter­face type	Phy/WirelessPhy
pack­et size	512bytes
Inter­face queue type	Queue/DropTail/PriQueue
Max pack­et in IFQ	50
Num­ber of mobile Nodes	50
Sim­u­la­tion area size	1000*1000
Sim­u­la­tion dura­tion	150 sec­ond
Trans­mis­sion range of each node	250 m
Mobil­i­ty mod­el	Ran­dom
Rout­ing pro­to­cols	RDSDV ‚DSDV

The per­for­mance of the two pro­to­cols under dif­fer­ent sce­nario are Com­pared on the dif­fer­ent per­for­mance met­rics as PDR, aver­age end to end delay and Jit­ter.

TABLE 2: NETWORK PERFORMANCE METRICS

Sr.no	Per­for­mance Met­ric	Descrip­tion
1	PDR (pack­et Deliv­ery Ratio)	PDR =∑ Num­ber of pack­et receive / ∑ Num­ber of pack­et send
2	Aver­age E2E Delay (End to End delay)	End to End Delay = ∑ (arrive time – send time) / ∑ Num­ber of nodes
3	Jit­ter	AVERAGE JITTER= ∑ [((recvtime(j)-sendtime(j))-(recvtime(i)-sendtime(i)))/(j‑i)]/ num­ber of nodes

We find out exper­i­men­tal results on above per­for­mance met­ric in fol­low­ing sce­nario as for Ran­dom posi­tion and ran­dom node move­ment. We con­sid­er dif­fer­ent topol­o­gy size with 30 to 110 nodes. Results of per­for­mance met­ric are com­pared in using Microsoft Excel tool.

SCENARIO 1

Under this sce­nario, we con­sid­er net­work size as 1000 X 1000 m

1. Jit­ter vari­a­tion for net­work size 1000 x 1000

TABLE 3: JITTER VARIATION FOR NETWORK SIZE 1000 X 1000

Num­ber of Nodes	Jit­ter of DSDV Pro­to­col	Jit­ter of Ran­dom­ized DSDV
30	0.001883	0.002108
50	0.002121	0.004522
70	0.002130	0.003985
90	0.001875	0.005734
110	0.002143	0.003625

FIGURE 1: JITTER VALUES VARIATION FOR NETWORK SIZE

Table 3 shows the jit­ter vari­a­tion for net­work size 1000X1000 m for nodes 30 to 110. Fig­ure 1 shows the graph based on table 3.These results shows the jit­ter val­ues of RDSDV pro­to­col are more than the val­ues of DSDV. Hence the path vari­a­tion more than exist­ing DSDV pro­to­col.

1)      PACKET DELIVERY RATIO VARIATION

TABLE 4: PDR VARIATION FOR NETWORK SIZE 1000 X 1000

Num­ber of Nodes	PDR of DSDV Pro­to­col	PDR of Ran­dom­ized DSDV
30	99.79	99.84
50	99.38	99.65
70	99.32	99.70
90	99.51	99.91
110	99.35	99.85

FIGURE 2: PDR VARIATION FOR NETWORK SIZE 1000 X 1000 M

Table 4 shows the PDR vari­a­tion for net­work size 1000 X 1000 m for nodes 30 to 110. Fig­ure 2 shows the graph based on table 4.These results shows the PDR val­ues of RDSDV pro­to­col are more than the val­ues of DSDV. Hence the PDR vari­a­tion more than exist­ing DSDV pro­to­col.

• AVERAGE END TO END DELAY VARIATION

TABLE 5: AVERAGE END TO END DELAY VARIATION FOR NETWORK SIZE 1000 X 1000

Num­ber of Nodes	AVERAGE DELAYOF DSDV Pro­to­col	AVERAGE DELAY of Ran­dom­ized DSDV
30	140.14	112.81
50	123.88	126.11
70	152.92	150.33
90	132.98	116.54
110	143.35	118.68

FIGURE 3

Table 5 Shows the Aver­age end to end delay vari­a­tion for net­work size 1000 X 1000 m for nodes 30 to 110. Fig­ure 3 shows the graph based on table 5. These results shows the aver­age end to end delay val­ues of RDSDV pro­to­col are less than the val­ues of DSDV. Hence the aver­age end to end delay vari­a­tion of RDSDV pro­to­col is less than exist­ing DSDV pro­to­col.

6.  CONCLUSION

To pro­tect infor­ma­tion and resources from attacks and mis­be­hav­ior. We imple­ment­ed ran­dom­ized deliv­ery path pro­to­col. In order to min­i­mize the prob­a­bil­i­ty that pack­ets are eaves­dropped over a spe­cif­ic link, a ran­dom­ize process for pack­et deliv­er­ies, ran­dom­ly picks up a neigh­bor­ing node as the next hop for the cur­rent pack­et trans­mis­sion. The exclu­sion for the next hop selec­tion avoids trans­mit­ting two con­sec­u­tive pack­ets on the same link and the ran­dom­ized pick­up pre­vents attack­ers from eas­i­ly pre­dict­ing rout­ing paths for the com­ing trans­mit­ted pack­ets.

Exper­i­men­tal results are drawn on dif­fer­ent sce­nar­ios with dif­fer­ent num­bers of nodes and net­work size and nodes mobil­i­ty speed shows that jit­ter val­ue is greater and increas­es as num­ber of nodes increas­es hence prove that each pack­et trans­mit­ted at dif­fer­ent path to des­ti­na­tion. As jit­ter val­ues are more means more path vari­a­tions for pack­et deliv­ery to des­ti­na­tion which com­bat secu­ri­ty attacks. The PDR and End to End Delay met­rics of RDSDV pro­to­col is clos­er to the met­rics for DSDV pro­to­col under same topol­o­gy. Hence we con­clude that secu­ri­ty attacks can be avoid­ed by this process with­out reduc­ing per­for­mance.

REFERENCES

1. Y. Zhang, V. Pax­son, and S. Shenker, “The sta­tion­ary of inter­net path prop­er­ties: Rout­ing, loss, and through­put,” tech. rep., ACIRI, May, 2000.
2. D. Thaler and C. Hopps, “Mul­ti­path issues in uni­cast and mul­ti­cast nex­thop selec­tion,” RFC 2991, Nov. 2000.
3. C. Vil­lamizar, “Ospf opti­mized mul­ti­path (ospf-omp),” draft-ietf-osp­fomp- 03, p. 46, June 1999.
4. J. Saltzer, D. Reed, and D. Clark, “End-to-end argu­ments in sys­tem design,” AMC Trans. on Com­put­er Sys­tems, vol. 2, no. 4, pp. 195–206, 1984.
5. S. Kent, C. Lynn, J. Mikkel­son, and K. Seo, “Secure bor­der gate­way pro­to­col (s‑BGP) — real world per­for­mance and deploy­ment issues,” in Pro­ceed­ings of NDSS 2000, 2000.
6. M. K. Reit­er andA. D. Rubin, “Crowds: Anonymi­ty­for­Web trans­ac­tions,” ACM Trans. on Infor­ma­tion and Sys­tem Secu­ri­ty, vol. 1, pp. 66–92, 1998.
7. P. F. Syver­son, M. G. Reed, and D. M. Gold­schlag, “Onion rout­ing access con­fig­u­ra­tions,” in DISCEX 2000: Pro­ceed­ings of the DARPA Infor­ma­tion Sur­viv­abil­i­ty Con­fer­ence and Expo­si­tion, vol. I, pp. 34–40, Jan. 2000.
8. R. Stone, “Cen­ter­Track: An IP over­lay net­work for track­ing DoS floods,” in 9th USENIX Secu­ri­ty Sym­po­sium, 2000.
9. S. Sav­age, D. Wether­all, A. Kar­lin, and T. Ander­son, “Prac­ti­cal net­work sup­port for IP trace­back,” in Pro­ceed­ings of the 2000 ACM SIGCOMM Con­fer­ence, (Stock­holm, Swe­den), pp. 295–306, August, 2000.
10. D. G. Ander­sen, H. Bal­akr­ish­nan, M. F. Kaashoek, and R. Mor­ris, “Resilient over­lay net­works,” in Proc. 18th ACM SOSP, (Banff, Canada),2001.
11. J. P. Hes­pan­ha and S. Bohacek, “Pre­lim­i­nary results in rout­ing games,” in Proc. Of the 2001 Amer­i­can Con­trol Con­fer­ence, June, 2001.
12. S. D. Patek and D. P. Bert­sekas, “Sto­chas­tic short­est path games,” SIAM J Con­tr. Opti­miza­tion, vol. 37, pp. 803–824, 1999.
13. The VINT Project, a col­lab­o­ra­tion between UC Berke­ley, LBL, USC/ISI and Xerox PARC, “The ns man­u­al (for­mer­ly ns Notes and Doc­u­men­ta­tion).” http://www.isi.edu/nsnam/ns/ns-documentation.html, Oct. 2000.