AODV - SD ΕΠΕΚΤΑΣΗ ΤΟΥ ΠΡΩΤΟΚΟΛΛΟΥ ΔΡΟΜΟΛΟΓΗΣΗΣ AODV ΓΙΑ ΑΝΑΚΑΛΥΨΗ ΥΠΗΡΕΣΙΩΝ ΣΕ ΚΙΝΗΤΑ AD HOC ΔΙΚΤΥΑ SIMULATION WITH J-SIM

MANETS MANETS = Mobile Ad Hoc Networks Δεν υπάρχει fixed network infrastructure Multi hop επικοινωνία Απαιτούνται πρωτόκολλα δρομολόγησης που να ανταπεξέρχονται στις συνεχόμενες αλλαγές στην τοπολογία του δικτύου

Routing (AODV) AODV = Ad hoc On Demand Distance Vector routing protocol Source initiated, on demand routing protocol RFC3561 C. E. Perkins, E. M. Belding-Royer, and S. R. Das, Ad hoc On-Demand Distance Vector (AODV) Routing,

AODV Concepts (1/2) On-demand routing protocol: Οι κόμβοι δεν διενεργούν route discovery ή maintenance προτού χρειαστούν κάποια διαδρομή προς κάποιον άλλο κόμβο Χρησιμοποιεί hop-by-hop routing Οι διαδρομές αποθηκεύονται στους πίνακες δρομολόγησης που βρίσκονται σε κάθε ενδιάμεσο κόμβο

AODV Concepts (2/2) Χρησιμοποιούνται HELLO μηνύματα ανά τακτά χρονικά διαστήματα, ώστε να βρίσκονται οι γειτονικοί κόμβοι Σε κάθε διαδρομή και σε κάθε routing table entry αντιστοιχούν κάποιοι αριθμοί Ώστε να αντιμετωπιστεί το ενδεχόμενο κάποιας μπαγιάτικης διαδρομής Κάθε κόμβος διατηρεί δυο αριθμούς που λειτουργούν ως counters Node sequence number Broadcast ID

Τύποι μηνυμάτων AODV HELLO RREQ RREP RRER

RREQ(1/3) Στέλνονται όταν κάποιος κόμβος θέλει να επικοινωνήσει με κάποιον άλλο κόμβο αλλά δεν ξέρει κάποια διαδρομή προς αυτόν Η πηγή κάνει broadcast το μήνυμα (RREQ) στους γείτονές της type flags resvd hopcnt broadcast_id dest_addr dest_sequence_# source_addr source_sequence_#

RREQ(2/3) Sequence numbers Οι Source sequence δείχνουν την freshness του αντίστροφου μονοπατιού (προς την πηγή) Οι Destination sequence δείχνουν την freshness του μονοπατιού προς τον προορισμό Κάθε κόμβος που λαμβάνει ένα RREQ είτε Επιστρέφει κάποιο route reply (RREP) packet, ή Προωθεί το RREQ στους γείτονές του (source_addr, broadcast_id) καθορίζει μοναδικά το RREQ broadcast_id αυξάνεται για κάθε RREQ που στέλνεται Οι δέκτες μπορούν έτσι να αναγνωρίσουν και να πετάξουν τα διπλά RREQ πακέτα

RREQ(3/3) Εάν ο κόμβος δεν μπορεί να απαντήσει σε ένα RREQ Ο κόμβος αυξάνει το hop count Ο κόμβος αποθηκεύει τις ακόλουθες πληροφορίες για να εγκαθιδρύσει το reverse path Το γειτονικό κόμβο που έστειλε αυτό το RREQ packet Destination IP address Source IP address Broadcast ID Source node s sequence number Expiration time για το reverse path entry (για garbage collection)

RREP(1/2) Εάν κάποιος κόμβος λάβει ένα RREQ packet και έχει μια διαδρομή προς τον τελικό κόμβο, τότε στέλνει ένα route reply packet (RREP) στον γειτονικό κόμβο που έστειλε το RREQ packet type flags rsvd prefx hopcnt dest_addr dest_sequence_# source_addr lifetime

RREP(2/2) Οι ενδιάμεσοι κόμβοι στέλνουν το πρώτο RREP που λαμβάνουν (και που απευθύνεται στην πηγή) προς την πηγή, χρησιμοποιώντας cached reverse route entries Τα υπόλοιπα RREP packets πετάγονται εκτός και αν dest_sequence_# number είναι μεγαλύτερο από το προηγούμενο, ή destination_sequence_# είναι το ίδιο, αλλά το hop_count είναι μικρότερο (που σημαίνει ότι υπάρχει συντομότερο μονοπάτι) RREP τελικά φτάνει στην πηγή, η οποία χρησιμοποιεί το γειτονικό κόμβο που έστειλε το RREP ως το επόμενο hop για να στείλει προς τον τελικό κόμβο Cached reverse routes θα γίνουν timeout στους κόμβους που δεν έλαβαν κάποιο RREP packet

RRER & Route Maintenance Αλλαγές στις διαδρομές μπορούν να ανιχνευθούν με Failure των περιοδικών HELLO packets Failure or disconnect indication από το link level Ο κόμβος που ανιχνεύει κάποιο failure στέλνει ένα route error (RERR) packet στην πηγή με ένα νέο destination sequence number και hop count άπειρο (δηλώνει unreachable) Η πηγή μπορεί να δημιουργήσει καινούριο μονοπάτι χρησιμοποιώντας RREQ packet

AODV & Service Discovery IETF Draft, Rajeev Koodli, Charles Perkins, Service Discovery in On-Demand Ad Hoc Networks

AODV - SD Extensions στα AODV messages SREQ SREP Στα ήδη υπάρχοντα μηνύματα του AODV προσθέτουμε ως extension την υπηρεσία στην οποία επιθυμούμε να έχουμε πρόσβαση Σε κάθε Routing table entry αποθηκεύουμε επιπλέον τις εξής πληροφορίες Service ID Lifetime Attribute list

SREQ Τύπος του μηνύματος ώστε να ξέρουν οι κόμβοι ότι πρόκειται για SREQ μηνύματα (τιμή 20) Μέγεθος του extension Μέγεθος του Service ID Το Service ID ((port ή url)), δηλαδή ποια υπηρεσία ζητάμε Προαιρετική λίστα χαρακτηριστικών, η οποία συνήθως περιλαμβάνει περιορισμούς της υπηρεσίας

SREP Τύπος του μηνύματος ώστε να ξέρουν οι κόμβοι ότι πρόκειται για SREP μηνύματα (τιμή 21) Μέγεθος του extension H διάρκεια ζωής της υπηρεσίας Το μέγεθος του Service URL Το Service URL, που είναι της μορφής: service:lpr://igore.wco.ftp.com:515/draft, service:fsp://192.9.9.204:150/foo.txt - (σύμφωνα με το Service Location Protocol- RFC2156)

AODV SD Concepts

Η Δική μας προσέγγιση Σε κάθε SREP μήνυμα τοποθετούμε ένα έξτρα πεδίο, που δείχνει την εναπομένουσα ενέργειας του παρόχου 'Οταν στο Service Table υπάρχουν περισσότεροι από ένας πάροχοι της ίδιας υπηρεσίας επιλέγουμε αυτόν με την μεγαλύτερη ενέργεια Σύγκριση επιλογής με βάση τον κοντινότερο και με βάση τον ενεργειακά ισχυρότερο με προσομοιώσεις

J - Sim To simulation γίνεται με χρήση του J-sim Το J-sim αποτελεί ένα simulator γραμμένο σε Java και χρησιμοποιεί την Jacl (scripting language) για την περιγραφή των σεναρίων πάνω στα οποία θα γίνει η εξομοίωση Για τους σκοπούς της εργασίας χρησιμοποιήθηκε και το wireless package που προσφέρεται μαζί με το J-sim Το J-sim χρησιμοποιεί component - based αρχιτεκτονική (κάθε component επικοινωνεί με κάποιο άλλο component μέσω συγκεκριμένων ports)

Μετρικές Το διάστημα ζωής των παρόχων Αριθμός ανακάλυψης υπηρεσίας Αριθμός επιτυχημένης κλήσης υπηρεσίας

Μεταβλητές Δικτύου Σταθερές: ταχύτητα (max 1,5 m/s), κινητικότητα RWP, ενέργεια κόμβων 50J, σύνολο κόμβων 25, χρόνος προσομοίωσης 1200 sec, μέγεθος αρχείου 34 Kb, κάρτα δικτύου range 250m, rcvcons395mw, transmcons 660mW Mεταβλητές:μέγεθος περιοχής (400x400-600x600), RequestRatio (per20sec-per40sec), expanding ring search, client-serverratio (10/15, 15/10, 20/5), Extra, Various

Αποτελέσματα- Αναλογία πελατών/παρόχων Μέγεθος Περιοχής Σταθερό 400x400

Αποτελέσματα- Μέγεθος Περιοχής- Αναλογία Cli-Ser 10/15 Σταθερή

Αποτελέσματα από Service Selection Σε πυκνά δίκτυα η επιλογή με βάση τον ενεργειακά ισχυρότερο αποδεικνύεται καλύτερη από την επιλογή με βάση τον κοντινότερο (έως +6% FP και έως +7% SSI)

Future Work Εύρεση κάποιας υβριδικής λύσης για επιλογή που να λαμβάνει υπόψη της αρκετούς παράγοντες, π.χ. να συνδυάζει με κάποιον αλγόριθμο και την απόσταση σε άλματα και την εναπομένουσα ενέργεια του παρόχου Δημιουργία κάποιου μοντέλου κατανάλωσης ενέργειας σε υψηλότερο επίπεδο (πάνω από την κάρτα δικτύου)