ΔΙΑΧΕΙΡΙΣΗ ΚΙΝΗΤΙΚΟΤΗΤΑΣ ΚΑΙ ΥΠΟΣΤΗΡΙΞΗ IP ΥΠΗΡΕΣΙΩΝ ΣΕ ΑΣΥΡΜΑΤΟ ΑΤΜ ΠΕΡΙΒΑΛΛΟΝ

emujabΛογισμικό & κατασκευή λογ/κού

2 Ιουλ 2012 (πριν από 4 χρόνια και 11 μήνες)

471 εμφανίσεις

Πρόλογος

ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟ ΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΝ
ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ
ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΝ ΣΠΟΥ Ν
ΤΟΜΕΑΣ ΣΥΣΤΗΜΑΤΝ ΕΠΙΚΟΙΝΝΙΝ ΚΑΙ ΙΚΤΥΝ

ιπλω ατική Εργασία

ΙΑΧΕΙΡΙΣΗ ΚΙΝΗΤΙΚΟΤΗΤΑΣ ΚΑΙ
ΥΠΟΣΤΗΡΙΞΗ IP ΥΠΗΡΕΣΙΝ ΣΕ
ΑΣΥΡΜΑΤΟ ΑΤΜ ΠΕΡΙΒΑΛΛΟΝ


Σαράντης Πασκαλής

Επιβλέπων Καθηγητής: Λ. Μεράκος

Αθήνα, Απρίλιος 1998

Πρόλογος
i
Πρόλογος
Η εργασία αυτή πραγ ατοποιήθηκε στο Πανεπιστή ιο Αθηνών, ως διπλω ατική
εργασία στα πλαίσια των απαιτήσεων του Προγρά ατος Μεταπτυχιακών Σπουδών του
Τ ή ατος Πληροφορικής του Πανεπιστη ίου Αθηνών.
Οι επικοινωνίες ευρείας ζώνης και οι επικοινωνίες κινητών είναι οι κινητήριοι οχλοί
της έρευνας και της ανάπτυξης τόσο στη βιο ηχανία όσο και στον ακαδη αϊκό χώρο.
Επίσης το Internet γνωρίζει στις έρες ας ια πρωτοφανή ανάπτυξη και αζί ε αυτό
και το IP (Internet Protocol) στο οποίο είναι βασισ ένο. Σκοπός της εταπτυχιακής
εργασίας είναι να αναπτυχθεί ένα πλαίσιο υποστήριξης IP υπηρεσιών σε ασύρ ατο
ΑΤΜ περιβάλλον. Στο περιβάλλον αυτό οι χρήστες θα πορούν να χρησι οποιούν τις
ήδη ανεπτυγ ένες ΙP εφαρ ογές έσα σ’ ένα δίκτυο υψηλών ταχυτήτων. Ένα από τα
θετικά χαρακτηριστικά του περιβάλλοντος είναι η διατήρηση της ποιότητας των
εφαρ ογών, ακό α και όταν οι χρήστες κινούνται έσα στο δίκτυο.
Για το σχεδιασ ό του ολοκληρω ένου περιβάλλοντος, χρησι οποιήθηκαν ανερχό ενα
πρότυπα όπως Ipv6, Mobile IP, RSVP. Το ΑΤΜ σύστη α πάνω στο οποίο βασίστηκε η
ο σχεδιασ ός του περιβάλλοντος, έχει πραγ ατοποιηθεί στα πλαίσια του ευρωπαϊκού
ερευνητικού προγρά ατος The Magic WAND.
Στο ση είο αυτό θα ήθελα να ευχαριστήσω τον υπεύθυνο καθηγητή Λάζαρο Μεράκο
για τις πολύτι ες συ βουλές του και την υποστηρίξη του καθόλη τη διάρκεια της
εκπόνησης της εταπτυχιακής ου εργασίας.
Επίσης θα ήθελα να ευχαριστήσω τον υποψήφιο διδάκτορα Στάθη Χατζηευθυ ιάδη, ο
οποίος ε βοήθησε πάντα πρόθυ α ε τις πολύτι ες συ βουλές και παρε βάσεις του.
Χωρίς την α έριστη συ παράσταση του, δεν θα ήταν δυνατή η ολοκλήρωση αυτής της
εργασίας.
Η ιδιότητα ου ως έλους του προσωπικού στο Εργαστήριο Επικοινωνιών ικτύων του
Τ ή ατος Πληροφορικής του Πανεπιστη ίου Αθηνών ου επέτρεψε την επαφή και
συνεργασία ε ερευνητές που πολλές φορές ε βοήθησαν ε τις παρε βάσεις τους. Το
υψηλό επίπεδο των παρατηρήσεων τους ήταν ση αντικός παράγοντας βοήθειας και
τους ευχαριστώ γι’ αυτό.

Περιεχό ενα
iii
Περιεχό ενα
Πρόλογος.......................................................................................................i
Περιεχό ενα................................................................................................iii
Πίνακας Σχη άτων.....................................................................................vi
Πίνακας Πινάκων......................................................................................vii
Εισαγωγή......................................................................................................1
1.1 Εισαγωγικές έννοιες........................................................................................1
1.2 ιάρθρωση της εργασίας................................................................................2
Internet Protocol (IP).................................................................................3
2.1 Εισαγωγή.........................................................................................................3
2.2 IPv4...................................................................................................................3
2.2.1 Λειτουργία.................................................................................................4
2.2.2 Σχέση ε άλλα πρωτόκολλα......................................................................5
2.2.3 Επικεφαλίδα IPv4......................................................................................5
2.2.4 ιευθυνσιοδότηση.....................................................................................6
2.3 Mobile IPv4......................................................................................................7
2.3.1 Απαιτήσεις................................................................................................7
2.3.2 Ορολογία...................................................................................................8
2.4 IPv6.................................................................................................................12
2.4.1 Επικεφαλίδα IPv6....................................................................................13
2.5 Mobile IPv6....................................................................................................14
2.5.1 Αναλυτική περιγραφή.............................................................................15
2.6 ιαφορές Mobile IPv4 - Mobile IPv6..........................................................16
2.7 Αναφορές........................................................................................................17
RSVP..........................................................................................................19
3.1 Εισαγωγή.......................................................................................................19
3.2 Λειτουργική περιγραφή................................................................................20
3.3 Ροές δεδο ένων..............................................................................................23
3.4 Μοντέλο έσ ευσης......................................................................................23
3.5 Μηχανισ οί του πρωτοκόλλου RSVP.........................................................24
3.5.1 Συγχώνευση Flowspecs...........................................................................26
3.5.2 Μαλακή κατάσταση (Soft state)..............................................................26
3.6 Αναφορές........................................................................................................26
Asynchronous Transfer Mode (ΑΤΜ)....................................................27
4.1 Γενική Επισκόπηση του Κεφαλαίου............................................................27
4.2 Εισαγωγή.......................................................................................................27
4.3 ATM...............................................................................................................27
4.4 Το ATM ίκτυο.............................................................................................28
4.5 Στοίβα Πρωτοκόλλων του ATM.................................................................30
4.5.1 Φυσικό Επίπεδο......................................................................................31
Περιεχό ενα

iv
4.5.2 ATM Επίπεδο..........................................................................................32
4.5.3 Επίπεδο Προσαρ ογής ATM..................................................................33
4.6 Η κυκλοφορία σε ένα ATM ίκτυο.............................................................34
4.6.1 Κυκλοφορία Μεταβλητού Ρυθ ού Μετάδοσης......................................34
4.6.2 Κυκλοφορία Σταθερού Ρυθ ού Μετάδοσης...........................................35
4.6.3 Κυκλοφορία Μη-Πραγ ατικού Χρόνου.................................................35
4.6.4 Οι Κλάσεις Κυκλοφορίας στο ATM και οι Παρά ετροί τους................36
4.6.5 Έλεγχος Κυκλοφορίας και Συ φόρησης................................................38
4.7 Αναφορές........................................................................................................38
IP πάνω από ATM.....................................................................................39
5.1 Εισαγωγή.......................................................................................................39
5.2 LAN Emulation (LANE)..............................................................................39
5.3 CLIP...............................................................................................................41
5.4 NHRP.............................................................................................................41
5.5 MPOA............................................................................................................42
5.6 IP Switching...................................................................................................43
5.6.1 Ταξινό ηση ροών...................................................................................44
5.6.2 GSMP......................................................................................................44
5.6.3 IFMP.......................................................................................................46
5.7 MPLS..............................................................................................................49
5.8

Multicast........................................................................................................50

5.9 RSVP-ATM....................................................................................................51
5.10 Αναφορές........................................................................................................52
Ασύρ ατο ATM.........................................................................................57
6.1 Magic WAND................................................................................................57
6.2 Μοντέλο αναφοράς WATM.........................................................................57
6.3 Μοντέλο Λειτουργίας WATM.....................................................................58
6.4

Εισαγωγή IP στο WAND..............................................................................60

6.4.1 Εναλλακτικές αρχιτεκτονικές.................................................................61
6.4.2 Μηχανισ ός Μεταφοράς εδο ένων.....................................................62
6.5

Αναφορές........................................................................................................62

Κινητικότητα για IP υπηρεσίες πάνω από ασύρ ατο ATM.................63
7.1 Αρχιτεκτονική ασύρ ατου ATM συστή ατος...........................................63
7.1.1 Επιλογή κατεύθυνσης.............................................................................63
7.2 Στοίβα πρωτοκόλλων....................................................................................64
7.3 Ανάλυση λειτουργίας....................................................................................65
7.4 Handovers......................................................................................................66
7.4.1 Intra-switch handovers............................................................................66
7.4.1.1 Προτεινό ενη υλοποίηση....................................................................67
7.4.1.2 Πιθανές βελτιώσεις.............................................................................68
7.4.1.2.1 Βελτίωση handover για εγγενή IP ασύρ ατα συστή ατα.............69
7.4.1.2.2 Προσαρ ογή της multicast εθόδου σε ασύρ ατα ΑΤΜ δίκτυα.70
7.4.2 Inter-switch handovers............................................................................72
7.4.2.1 Προτεινό ενη υλοποίηση....................................................................73
7.4.2.2 Πιθανές βελτιώσεις.............................................................................75
7.4.2.2.1 MRSVP.........................................................................................76
7.4.2.2.2 Προσαρ ογή της τεχνικής MRSVP..............................................78
Περιεχό ενα

v
7.5 ο ή της ονάδας Mobility Management...................................................79
7.6 Αναφορές........................................................................................................80
Σύνοψη-Συ περάσ ατα............................................................................83
Περιεχό ενα

vi
ΠίνακαςΣχη άτων
Σχή α 2-1: Θέση του πρωτοκόλλου Internet (IP).............................................................4
Σχή α 2-2: Περιεχό ενα επικεφαλίδας IPv4....................................................................5
Σχή α 2-3: Κλάσεις IP διευθύνσεων................................................................................6
Σχή α 2-4: Εγκλεισ ός IP σε IP (IP in IP encapsulation)...............................................9
Σχή α 2-5: Τριγωνική δρο ολόγηση..............................................................................11
Σχή α 2-6: Βασικά πεδία επικεφαλίδας IPv6.................................................................13
Σχή α 2-7: Επικεφαλίδες επέκτασης IPv6......................................................................14
Σχή α 3-1: Το RSVP σε κό βους και δρο ολογητές.....................................................21
Σχή α 3-2: ρο ολογητής που χρησι οποιεί RSVP......................................................25
Σχή α 4-1: Σύνδεση εταξύ δύο τερ ατικών σε ένα ATM δίκτυο................................28
Σχή α 4-2: Λειτουργία ενός ATM εταγωγέα...............................................................29
Σχή α 4-3: Στοίβα πρωτοκόλλων του ATM...................................................................31
Σχή α 4-4: Τα πεδία του ATM cell στο User Network Interface (UNI).......................33
Σχή α 5-1: Παράδειγ α λειτουργίας LANE...................................................................40
Σχή α 5-2: Παράδειγ α λειτουργίας CLIP.....................................................................41
Σχή α 5-3: Παράδειγ α λειτουργίας NHRP...................................................................42
Σχή α 5-4: ο ή ενός IP εταγωγέα..............................................................................43
Σχή α 5-5: Εγκαθίδρυση ιας εταγό ενης ροής..........................................................46
Σχή α 5-6: (1) Προώθηση πακέτων πάνω από προκαθορισ ένα ATM VCs. Ο ελεγκτής
του IP εταγωγέα πραγ ατοποιεί αξιολόγηση πακέτων σε κάθε πακέτο...............47
Σχή α 5-7: (2) Ο ελεγκτής του IP εταγωγέα στέλνει το ήνυ α Redirect στον
προηγού ενο κό βο να χρησι οποιήσει ένα νέο VC για την επιλεγ ένη ροή.
(3) Η κυκλοφορία για την επιλεγ ένη ροή αρχίζει να ρέει στο νέο VC. Η
εισερχό ενη ροή παίρνει ετικέτα............................................................................47
Σχή α 5-8: (4) Ο επό ενος κό βος ζητάει επίσης ένα νέο VC για τη ροή.
(5) Ο IP εταγωγέας αρχίζει να στέλνει την κυκλοφορία αυτής της ροής στο νέο
VC. H εξερχό ενη ροή παίρνει ετικέτα..................................................................48
Σχή α 5-9: (6) Η εισερχό ενη ροή ε ετικέτα ετάγεται έσω της εξερχό ενης ροής ε
ετικέτα. Η επιλεγ ένη ροή τώρα ετάγεται απευθείας (cut-through).....................48
Σχή α 5-10: Παράδειγ α λειτουργίας IP switching.......................................................49
Σχή α 5-11: Σύγκριση των τεχνικών παροχής multicast VC-mesh και MCS................50
Σχή α 5-12: Λειτουργία του RSVP πάνω από ATM.....................................................52
Περιεχό ενα

vii
Σχή α 6-1: Ένα γενικό οντέλο αναφοράς δικτύου πρόσβασης στη ραδιοεπικοινωνία
ευρείας ζώνης..........................................................................................................58
Σχή α 6-2: από WAND Functional Overview...............................................................59
Σχή α 6-3: Ασύρ ατο ATM σύστη α ε υπηρεσίες IP................................................61
Σχή α 6-4: Στοίβα πρωτοκόλλων στην παρούσα κατάσταση........................................61
Σχή α 7-1: ίκτυο πρόσβασης ε περισσότερους εταγωγείς............................................63
Σχή α 7-2: Στοίβα πρωτοκόλλων της νέας αρχιτεκτονικής..........................................64
Σχή α 7-3: Intra-switch handover...................................................................................67
Σχή α 7-4: Ση ατοδοσία υλοποιη ένη στο Daedalus....................................................69
Σχή α 7-5: Handover ε τoν multicast ηχανισ ό.........................................................71
Σχή α 7-6: Inter-switch handover...................................................................................72
Σχή α 7-7: Απαραίτητη ανταλλαγή ηνυ άτων για υποστήριξη IP και RSVP ετά από inter-
switch handover........................................................................................................74
Σχή α 7-8: εσ εύσεις για Κλάσεις Υπηρεσιών...........................................................76
Σχή α 7-9: Βελτιω ένο inter-switch handover...............................................................77
Σχή α 7-10: Ο ανταποκριτής κό βος γνωρίζει για τις πιθανές τοποθεσίες του κινητού.78
Σχή α 7-11: Ο proxy agent γνωρίζει για τις πιθανές τοποθεσίες του κινητού...............79
Σχή α 7-12: ιεπaφές της Μονάδας Mobility Management..........................................80
ΠίνακαςΠινάκων
Πίνακας 4-1: Οι κλάσεις κυκλοφορίας του ATM και οι παρά ετροί τους.....................37
Πίνακας 6-1: Πρωτόκολλα και διεπαφές επιπέδων........................................................60
Εισαγωγή

1
Εισαγωγή
1. Γενικήεπισκόπησητουκεφαλαίου
ίνεται ια εισαγωγή στις έννοιες που θα χρησι οποιηθούν στην εργασία καθώς και η
διάρθρωση του κει ένου.
1.1 Εισαγωγικέςέννοιες
Οι επικοινωνίες ευρείας ζώνης και οι επικοινωνίες κινητών είναι οι κινητήριοι οχλοί
της έρευνας και της ανάπτυξης τόσο στη βιο ηχανία όσο και στον ακαδη αϊκό χώρο. Η
τεχνολογία ATM (Asynchronous Transfer Mode) θεωρείται η ιδανικότερη για την
παροχή ολοκληρω ένων υπηρεσιών ευρείας ζώνης. Τα τοπικά ασύρ ατα δίκτυα
προβλέπεται να επεκτείνουν τη δη οτικότητα τους για ετάδοση δεδο ένων σε
εσωτερικό χώρο. Η συνύφανση τους ε την τεχνολογία ΑΤΜ παρουσιάζει την
πρόκληση του συνδυασ ού του αναξιόπιστου έσου ετάδοσης (ραδιοζεύξη) ε τις
υψηλές απαιτήσεις ποιότητας που θέτει το ΑΤΜ.
Το Internet γνωρίζει στις έρες ας ια πρωτοφανή ανάπτυξη και αζί ε αυτό και το
IP (Internet Protocol) στο οποίο είναι βασισ ένο. Είναι επο ένως επιθυ ητή η
υποστήριξη του από όλα τα δίκτυα τα οποία σχεδιάζονται ή χρησι οποιούνται κιόλας.
Η υποστήριξη IP σε ATM δίκτυα παρουσιάζει αρκετό ενδιαφέρον από όνη της, αφού
αντιπροσωπεύουν δύο εντελώς διαφορετικές όψεις της τεχνολογίας εταφοράς
δεδο ένων. Το IP είναι πρωτόκολλο χωρίς σύνδεση (connectionless) που δεν παρέχει
εγγυη ένη ποιότητα υπηρεσίας (Quality of Service, QoS), ενώ το ΑΤΜ είναι
προσανατολισ ένο στη σύνδεση (connection oriented) και πορεί να προσφέρει
εγγυη ένη ποιότητα υπηρεσίας στις συνδέσεις.
Για να καλύψει το κενό της έλλειψης υποστήριξης εγγυήσεων ποιότητας υπηρεσίας στο
IP αναπτύχθηκε το RSVP (Resource ReSerVation Protocol). Το πρωτόκολλο αυτό
λειτουργεί επάνω από το IP (επάνω από το επίπεδο δικτύου) και κάνει δυνατή τη
δέσ ευση των πόρων στο Internet χωρίς εγάλες αλλαγές στην υπάρχουσα υποδο ή.
Στην περίπτωση υποστήριξης IP υπηρεσιών από ΑΤΜ δίκτυα, πρέπει να εξεταστεί και
το στοιχείο της συνεργασίας ανά εσα στις υπηρεσίες δέσ ευσης πόρων του RSVP και
των αντιστοίχων του ΑΤΜ.
Η επιβολή της κινητικότητας (mobility) είναι ένας επιπλέον παράγοντας αύξησης των
βαθ ών ελευθερίας στις επιλογές για σχεδιασ ό ενός συστή ατος αποτελεσ ατικής
υποστήριξης των IP υπηρεσιών.
Ο κατάλληλος και αποτελεσ ατικός συνδυασ ός όλων αυτών των συχνά
αντικρουό ενων τεχνολογικών θε άτων είναι ια ερευνητική διαδικασία που έχει όλις
αρχίσει. Στο υπόλοιπο τ ή α της εργασίας επιχειρείται η καταγραφή των πιθανών
Εισαγωγή

2
τεχνολογικών συζεύξεων και προτείνεται ένας ηχανισ ός ο οποίος υποστηρίζει
αποτελεσ ατικά IP υπηρεσίες σε ασύρ ατα ΑΤΜ δίκτυα.
1.2 ιάρθρωσητηςεργασίας
Στο Κεφάλαιο 2 παρουσιάζεται συνοπτικά το IP πρωτόκολλο και γίνεται αναφορά στην
επέκταση του για υποστήριξη κινητών Mobile IP. Ακό η αναφέρεται η νέα βελτιω ένη
έκδοση του (IPv6) και η υποστήριξη κινητών για τη νέα αυτή έκδοση.
Το πρωτόκολλο δέσ ευσης πόρων RSVP καλύπτεται στο Κεφάλαιο 3, όπου και
αναφέρονται οι λειτουργικές του ονάδερς και επιχειρείται να περιγραφεί ο ηχανισ ός
λειτουργίας του.
Κρίνεται σκόπι ο να γίνει ια αναφορά στην τεχνολογία ΑΤΜ και έτσι το Κεφάλαιο 4
είναι αφιερω ένο στις βασικές έννοιες και λειτουργίες του ΑΤΜ.
Το Κεφάλαιο 5 αποτελεί ια προσπάθεια καταγραφής των σχη άτων που προσπαθούν
να συνδυάσουν το IP ε το ATM. Επιχειρήθηκε να είναι ια σχετικά πλήρης κάλυψη
των προτεινό ενων τεχνικών και αξιολόγησης τους.
Στο Κεφάλαιο 6 παρουσιάζεται το οντέλο λειτουργίας του ασύρ ατου ΑΤΜ δικτύου
και οι τροποποιήσεις που θα απαιτηθούν για την αποτελεσ ατική υποστήριξη του.
Τέλος, στο Κεφάλαιο 7 αναλύεται εκτενέστερα η επιλεγ ένη αρχιτεκτονική και
παρουσιάζεται αναλυτική ο ηχανισ ός που διαχειρίζεται την κινητικότητα (moblity
management). ίνονται αναλυτικές περιγραφές των διαφορετικών περιπτώσεων
handover, αλλά και κατευθύνσεις προς τις οποίες πορεί να κινηθεί ελλοντική
ερευνητική δραστηριότητα.

Internet Protocol

InternetProtocol(IP)
2. Γενικήεπισκόπησητουκεφαλαίου
Στο κεφάλαιο αυτό παρουσιάζεται συνοπτικά το IP πρωτόκολλο. Στην αρχή
παρουσιάζεται η έκδσση που χρησι οποιείται ευρέως σή ερα (IPv4). Στη συνέχεια
αναφέρεται η επέκταση του πρωτοκόλλου για υποστήριξη κινητών Mobile IP. Ακό η
αναφέρεται η νέα βελτιω ένη έκδοση του (IPv6) και η υποστήριξη κινητών για τη νέα
αυτή έκδοση.
2.1 Εισαγωγή
Το πρωτόκολλο διαδικτύου σχεδιάστηκε για χρήση σε διασυνδεδε ένα συστή ατα
υπολογιστών που επικοινωνούν ε δίκτυα εταγωγής πακέτων. Το πρωτόκολλο
διαδικτύου παρέχει υπηρεσίες εταφοράς πακέτων δεδο ένων (datagrams) από τις
πηγές στους προορισ ούς, όπου προορισ οί είναι κό βοι αναγνωρίσι οι από
διευθύνσεις σταθερού ήκους. Το πρωτόκολλο IP, ακό α παρέχει υπηρεσίες για τον
κατακερ ατισ ό (fragmentation) και επανασυναρ ολόγηση (reassembly) εγάλων
πακέτων δεδο ένων, όπου αυτό είναι απαραίτητο για τη εταφορά έσα από δίκτυα
« ικρών πακέτων».
Εξαιτίας της επέκτασης του σε κάθε υπολογιστική λειτουργία στις έρες ας, αρχίζουν
να φαίνονται προβλή ατα που δεν είχαν προβλεφθεί στην αρχική σχεδίαση στη
δεκαετία του ’70. Η τωρινή έκδοση του πρωτοκόλλου IPv4 χρησι οποιείται ουσιαστικά
παντού. Η ο άδα σχεδίασης του Internet, IETF (Internet Engineering Task Force)
σχεδιάζει και υλοποιεί τη νέα έκδοση του πρωτοκόλλου ε αριθ ό 6 (IPv6). Η νέα αυτή
έκδοση βελτιώνει διάφορες αδυνα ίες βασικές στη σχεδίαση της προηγού ενης
έκδοσης.
2.2 IPv4
Το πρωτόκολλο IP είναι περιορισ ένο στις λειτουργίες που είναι απαραίτητες για την
παράδοση ενός πακέτου από bits (ένα Internet datagram) από ία πηγή σε έναν
προορισ ό έσω ενός διασυνδεδε ένου συστή ατος από δίκτυα. εν υπάρχουν
ηχανισ οί που να βοηθούν από άκρη σε άκρη (end to end) την αξιοπιστία των
δεδο ένων, τον έλεγχο ροής (flow control), ή άλλες υπηρεσίες που υπάρχουν σε
πρωτόκολλα προσανατολισ ένα σε επικοινωνίες άλ α-προς-άλ α (hop-by-hop).
Το Internet πρωτόκολλο καλείται από πρωτόκολλο κό βου-προς-κό βο (π.χ. TCP) σε
ένα περιβάλλον διαδικτύου. Αυτό ε τη σειρά του χρησι οποιεί τα τοπικά πρωτόκολλα
δικτύου να εταφέρουν το Internet datagram στον επό ενο κό βο ή στον προορισ ό
του.
Internet Protocol
4
Για παράδειγ α, το πρωτόκολλο TCP θα καλέσει το πρωτόκολλο Internet να πάρει ένα
κο άτι TCP (που περιλα βάνει την επικεφαλίδα TCP και τα δεδο ένα του χρήστη) ως
το κο άτι δεδο ένων ενός Internet datagram. Η ονάδα TCP θα παρέχει τις
διευθύνσεις και άλλες παρα έτρους στην Internet επικεφαλίδα στην ονάδα Internet ως
παρα έτρους της κλήσης. Η ονάδα Internet τότε θα σχη ατίσει ένα Internet datagram
και θα καλέσει τη διασύνδεση ε το τοπικό δίκτυο να εταδώσει το datagram.
2.2.1 Λειτουργία
Το πρωτόκολλο Internet επιτελεί δύο βασικές λειτουργίες: διευθυνσιοδότηση και
κατακερ ατισ ό.
Οι ονάδες Internet χρησι οποιούν τις διευθύνσεις που περιέχονται στην επικεφαλίδα
Internet για να εταδώσουν πακέτα προς τους προορισ ούς τους. Η επιλογή του
βέλτιστου ονοπατιού για την ετάδοση καλείται δρο ολόγηση (routing). Οι ονάδες
Internet χρησι οποιούν πεδία στην επικεφαλίδα του πακέτου για τον κατακερ ατισ ό
και την επανασύνδεση των πακέτων όπου είναι απαραίτητο για την ετάδοση.
Το οντέλο της λειτουργίας έγκειται στο ότι ια ονάδα Internet βρίσκεται σε κάθε
κό βο που ε πλέκεται σε Internet επικοινωνία και σε κάθε πύλη (gateway) που
διασυνδέει δίκτυα. Οι ονάδες αυτές δια οιράζονται κοινούς κανόνες για τη διερ ηνεία
των πεδίων της επικεφαλίδας. Ακό η, οι ονάδες αυτές, (ειδικά οι πύλες-gateways)
έχουν διαδικασίες για να λα βάνουν αποφάσεις δρο ολόγησης και άλλες λειτουργίες.
Κάθε πακέτο αντι ετωπίζεται ως ανεξάρτητη οντότητα ασυσχέτιστη ε κάθε άλλο
πακέτο.
Το πρωτόκολλο δεν παρέχει αξιόπιστη επικοινωνία. εν υπάρχουν επιβεβαιώσεις ούτε
από άκρη σε άκρη ούτε ενδιά εσα στους κό βους. εν υπάρχει έλεγχος λαθών για τα
δεδο ένα, παρά όνο ένα άθροισ α ελέγχου (checksum) στην επικεφαλίδα. εν
υπάρχουν επανα εταδόσεις. εν υπάρχει έλεγχος ροής.
Τα λάθη που ανιχνεύονται πορούν να αναφερθούν έσω του πρωτοκόλλου ελέγχου
του Internet (Internet Control Message Protocol ICMP), το οποίο υλοποιείται στην
ονάδα Internet.


telnet

FTP

TFTP

....

TCP

UDP
....

IP & ICMP

Local Network Protocol
Σχήα 2-1: Θέση του πρωτοκόλλου Internet (IP)
Internet Protocol
5
2.2.2 Σχέση εάλλαπρωτόκολλα
Στο Σχή α 2-1 φαίνεται η θέση του πρωτοκόλλου Internet στην ιεραρχία πρωτοκόλλων.
Παρουσιάζεται ια ενδεικτική στοίβα πρωτοκόλλων.
Το πρωτόκολλο IP επικοινωνεί όπως φαίνεται ε τα πρωτόκολλα του επιπέδου
εταφοράς (TCP και UDP), καθώς και ε το τοπικό πρωτόκολλο δικτύου (Ethernet για
παράδειγ α).
2.2.3 ΕπικεφαλίδαIPv4Η επικεφαλίδα κάθε πακέτου IPv4 περιέχει κατά κανόνα ορισ ένα προκαθορισ ένα
πεδία, αλλά έχει και χώρο για διάφορες επεκτάσεις. Αναλυτικά, η επικεφαλίδα ενός
IPv4 πακέτου παρουσιάζεται στο Σχή α 2-2.

Version IHL Type of Service Total Length
Identification Flags Fragment Offset
Time to Live Protocol Header checksum
Source Address
Destination Address
Options Padding
Σχήα 2-2: Περιεχόενα επικεφαλίδας IPv4
Επεξηγήσεις

Version (Έκδοση): 4 bits. Το πεδίο έκδοσης φανερώνει τη ορφή της επικεφαλίδας.
Στην προκει ένη περίπτωση είναι 4.
• IHL - Internet Header Length (Μήκος επικεφαλίδας διαδικτύου): 4 bits. Το ήκος
της επικεφαλίδας σε 32-bit λέξεις. είχνει στην αρχή των δεδο ένων. Η ελάχιστη
τι ή είναι 5.
• Type of Service (Τύπος Υπηρεσίας): 8 bits. Ένδειξη για την ποιότητα υπηρεσίας
που ζητείται. εν έχει χρησι οποιηθεί.

Total Length (Συνολικό Μήκος): 16 bits. Συνολικό ήκος του πακέτου, ετρη ένο
σε οκτάδες, συ περιλα βανο ένων της επικεφαλίδας και των δεδο ένων. Το
έγιστο ήκος του πακέτου πορεί συνεπώς να είναι 65536 οκτάδες. Το ελάχιστο
ήκος που πρέπει να υποστηρίζουν όλες οι υλοποιήσεις είναι 576 οκτάδες.
• Identification (Ταυτότητα): 16 bits. Ταυτότητα που προστίθεται από τον αποστολέα
σε κάθε πακέτο.
• Flags (Ση αίες): 3 bits. ιάφορες ση αίες ελέγχου.

Fragment Offset (Εκτόπισ α τ ή ατος): 13 bits. Το πεδίο αυτό υποδηλώνει σε
ποιο έρος του datagram ανήκει αυτό το τ ή α.
Internet Protocol
6
• Time to Live (Χρόνος ζωής): 8 bits. Ένδειξη του έγιστου χρόνου ζωής ενός
πακέτου. Ουσιαστικά δείχνει το έγιστο αριθ ό των αλ άτων (hops) έχρι τον
προορισ ό του πακέτου.
• Protocol (Πρωτόκολλο): 8bits. είχνει το πρωτόκολλο του ανώτερου επιπέδου που
περιέχεται στο τ ή α δεδο ένων του πακέτου.

Header checksum (Έλεγχος λαθών επικεφαλίδας): 16 bits. Έλεγχος λάθους όνο
για την επικεφαλίδα.
• Source address (ιεύθυνση πηγής): 32 bits.
• Destination address (ιεύθυνση προορισ ού): 32 bits

Options (Επιλογές): κυ αινό ενο
• Padding (Γέ ισ α): κυ αινό ενο. Το γέ ισ α της επικεφαλίδας ε ηδενικά είναι
απαραίτητο για την εξασφάλιση του ακεραίου ήκους σε 32 bit λέξεις της
επικεφαλίδας.
2.2.4 1ιευθυνσιοδότηση
Όπως προαναφέρθηκε, οι IP διευθύνσεις έχουν σταθερό ήκος 4 οκτάδων (32 bits).
Χρησι οποιούνται τέσσερις διαφορετικές ορφές όπως φαίνεται στο Σχή α 2-3. Κάθε
ία διεύθυνση διακρίνεται από τον αριθ ό του δικτύου και τον αριθ ό του κό βου.

0

ίκτυο Κό βος
Κλάση A

1

0

ίκτυο Κό βος
Κλάση B

1

1

0 ίκτυο Κό βος
Κλάση C

1

1

1 0

Multicast address
Κλάση D
Σχήα 2-3: Κλάσεις IP διευθύνσεων.
Οι διευθύνσεις της κλάσης A έχουν το πρώτο bit ίσο ε το ηδέν. Τα επό ενα 7 bits
καθορίζουν τον αριθ ό του δικτύου ( έχρι 128 δίκτυα) και τα επό ενα 25 τον αριθ ό
του κό βου (περίπου 16 εκατο ύρια κό βοι.
Οι διευθύνσεις της κλάσης B αρχίζουν ε τα bits 10. Τα επό ενα 14 bits σχη ατίζουν
τον αριθ ό του δικτύου (16.384 δίκτυα). Τα τελευταία 16 bits είναι ο αριθ ός του
κό βου (65536 κό βοι).
Internet Protocol
7
Οι διευθύνσεις της κλάσης C αρχίζουν ε τα bits 110. Τα επό ενα 21 bits είναι ο
αριθ ός του δικτύου (περίπου 2 εκατο ύρια δίκτυα) και τα τελευταία 8 bits
καθορίζουν τον αριθ ό του κό βου (255 κό βοι).
Τέλος οι διευθύνσεις της κλάσης D προορίζονται για πολλαπλή αποστολή (multicast).
Ξεκινούν ε τα bits 1110.
2.3 MobileIPv4
Η έκδοση 4 του πρωτοκόλλου διαδικτύου (IP) υποθέτει ότι η IP διεύθυνση ενός κό βου
αντιστοιχεί οναδικά το ση είο προσάρτησης του κό βου στο Internet. Συνεπώς, ένας
κό βος πρέπει να είναι τοποθετη ένος στο δίκτυο που ορίζεται από την IP διεύθυνση
του προκει ένου να λα βάνει πακέτα που προορίζονται προς αυτόν, ειδάλλως τα
πακέτα δεν θα πορούσαν να παραδοθούν. Εάν ένας κό βος επιθυ εί να αλλάξει το
ση είο προσάρτησης του στο δίκτυο, χωρίς να χάσει την ικανότητα επικοινωνίας,
πρέπει να χρησι οποιηθεί ένας από τους παρακάτω ηχανισ ούς:
α) Ο κό βος πρέπει να αλλάζει την IP διεύθυνση του κάθε φορά που αλλάζει το
ση είο προσάρτησης ή
β) Οι δρο ολογήσεις σχετικές ε τον κό βο πρέπει να διαδοθούν αρκετά στο
εσωτερικό του ηχανισ ό δρο ολόγησης του Internet.
Και οι δύο από αυτές τις εναλλακτικές λύσεις δεν είναι βολικές. Η πρώτη καθιστά
αδύνατο για έναν κό βο να διατηρήσει τις συνδέσεις επιπέδου εταφοράς (transport) ή
ανώτερου, όταν ο κό βος αλλάζει τοποθεσία. Η δεύτερη έχει προφανώς σοβαρά
προβλή ατα κλι άκωσης, ειδικά ε την αλ ατώδη αύξηση των υπολογιστικών
συσκευών που υποστηρίζουν κίνηση (mobility).
2.3.1 Απαιτήσεις
Ένας κινητός κό βος πρέπει να πορεί να επικοινωνεί ε άλλους αφού αλλάξει το
ση είο προσάρτησης στο επίπεδο σύνδεσης (link layer), αλλά χωρίς να αλλάξει η IP
διεύθυνση του. Πρέπει να πορεί να επικοινωνεί ε άλλους κό βους οι οποίοι δεν
έχουν υλοποιήσει κατ’ ανάγκη τις λειτουργίες κινητικότητας. εν θα πρέπει να
απαιτούνται βελτιώσεις πρωτοκόλλου σε κό βους ή δρο ολογητές που δεν έχουν
σχέση ε τις λειτουργίες κινητικότητας που προσφέρονται. Επίσης όλα τα ηνύ ατα
που χρησι οποιούνται για την ενη έρωση κάποιου άλλου κό βου για την τοποθεσία
του κινητού κό βου πρέπει να πιστοποιούνται (authentication) για λόγους ασφάλειας.
Η σύνδεση ενός κινητού κό βου ε το Internet θα είναι κατά πάσα πιθανότητα
ασύρ ατη, καθιστώντας την έτσι χα ηλής χωρητικότητας και υψηλότερης πιθανότητας
λάθους από ότι στα παραδοσιακά καλωδιω ένα δίκτυα. Ακό η εξαιτίας της πιθανής
τροφοδοσίας του κινητού κό βου από παταρία, θα πρέπει να αποφεύγεται η άσκοπη
κατανάλωση ενέργειας. Συνεπώς ο αριθ ός και το έγεθος των ηνυ άτων ελέγχου θα
πρέπει να κρατηθεί σε πολύ χα ηλά επίπεδα.
Internet Protocol
8
2.3.2 Ορολογία
Γενική IP ορολογία
Ξενιστής (host): Υπολογιστής που γενικά δεν χρησι οποιείται για την επαναπροώθηση
των πακέτων που φτάνουν σε αυτόν. Η προέλευση του ονό ατος ανάγεται στις αρχικές
έρες σχεδιασ ού του Internet (ARPAnet), όταν η υπολογιστική ισχύς ήταν λιγοστή και
οι υπολογιστές φιλοξενούσαν και εκτελούσαν προγρά ατα από άλλες τοποθεσίες που
δεν είχαν αρκετή υπολογιστική ισχύ.
ρο ολογητής (router): Υπολογιστική συσκευή που ασχολείται ε την δρο ολόγηση,
δηλαδή την επαναπροώθηση των πακέτων που φθάνουν σε αυτόν. Τα πακέτα αυτά δεν
έχουν συνήθως τον δρο ολογητή ως τελικό προορισ ό τους.
Κό βος (node): Ξενιστής (host) ή δρο ολογητής (router).
Mobile IP ορολογία
Για την υποστήριξη κίνησης στο IP επίπεδο εισάγονται οι εξής οντότητες:
Κινητός Κό βος (Mobile node): Κό βος, ο οποίος αλλάζει το ση είο προσάρτησης
του από ένα δίκτυο ή υποδίκτυο σε ένα άλλο χωρίς να αλλάζει η IP διεύθυνση του.
Ένας κινητός κό βος πορεί να συνεχίσει να επικοινωνεί ε άλλους κό βους στο
Internet σε οποιαδήποτε άλλη τοποθεσία χρησι οποιώντας την (σταθερή) IP διεύθυνση
του.
Οικείος πράκτορας (Home agent): Ένας δρο ολογητής στο οικείο δίκτυο ενός
κινητού κό βου που φροντίζει για την παράδοση πακέτων στους απο ακρυσ ένους
κινητούς κό βους. Ακό η διατηρεί πληροφορίες για την τοποθεσία των κινητών
κό βων.
Ξένος πράκτορας (Foreign agent): Ένας δρο ολογητής σε ένα δίκτυο που
επισκέπτεται ο κινητός κό βος, ο οποίος συνεργάζεται ε τον οικείο πράκτορα για την
παράδοση των πακέτων στον απο ακρυσ ένο κινητό κό βο.
Σε έναν κινητό κό βο δίνεται ια ακροπρόθεσ η IP διεύθυνση (home address) στο
οικείο του δίκτυο. Την διεύθυνση αυτή, την διαχειρίζονται ε τον ίδιο τρόπο ε τον
οποίο διαχειρίζονται ια στατική διεύθυνση. Όταν απο ακρύνεται από το οικείο του
δίκτυο, ο κινητός κό βος συσχετίζεται ε ια προσωρινή διεύθυνση (care of address)
που αντανακλά το ση είο προσάρτησης εκείνη τη στιγ ή. Ο κινητός κό βος πορεί να
χρησι οποιεί ως διεύθυνση πηγής (source address) την οικεία του διεύθυνση
ανεξάρτητα ε το ση είο προσάρτησης. Αυτό πορεί να δη ιουργήσει που έχουν σχέση
ε την ασφάλεια του δικτύου και συνήθως τότε χρησι οποιεί την care-of του διεύθυνση
έχοντας την οικεία του διεύθυνση αποθηκευ ένη σε ένα πεδίο επιλογής της IP
επικεφαλίδας.
Οι ακόλουθοι όροι θα χρησι οποιηθούν συχνά για το Mobile IP πρωτόκολλο:
Internet Protocol
9
ιαφή ιση πράκτορα (Agent advertisement): Οι ξένοι πράκτορες διαφη ίζουν την
παρουσία τους χρησι οποιώντας ένα ειδικό ήνυ α, που σχη ατίζεται προσκολλώντας
ια ειδική επέκταση σε ια διαφή ιση δρο ολογητή [RFC1256].
Care-of διεύθυνση (Care of address): Το ση είο τερ ατισ ού ενός τούνελ από τον
οικείο πράκτορα προς ένα κινητό κό βο για πακέτα που προωθούνται προς τον κινητό
κό βο όταν αυτός βρίσκεται σε απο ακρυσ ένη τοποθεσία.
Ανταποκριτής κό βος (Correspondent node): Ένας κό βος στο Internet ε τον οποίο
επικοινωνεί ένας κινητός κό βος. Μπορεί να είναι κινητός ή στατικός.
Ξένο δίκτυο (Foreign network): Κάθε δίκτυο εκτός από το οικείο δίκτυο του κινητού
κό βου.
Οικεία διεύθυνση (Home address): Μια IP διεύθυνση που ανατίθεται σε έναν κινητό
κό βο για ένα εκτετα ένο χρονικό διάστη α. Παρα ένει αναλλοίωτη ανεξάρτητα από
το ση είο προσάρτησης του κό βου στο Internet.
Οικείο δίκτυο (Home network): Ένα δίκτυο, πιθανώς εικονικό (virtual) ε πρόθε α
δικτύου που ταιριάζει στην οικεία διεύθυνση ενός κινητού κό βου. Αξίζει να ση ειωθεί
ότι οι κλασικοί ηχανισ οί IP δρο ολόγησης θα παραδώσουν ένα πακέτο προορισ ένο
προς την οικεία διεύθυνση ενός κινητού κό βου στο οικείο του δίκτυο.
Πράκτορας κινητικότητας (Mobility agent): Ένας οικείος ή ξένος πράκτορας.
Σύνδεσ ος κινητικότητας (Mobility binding): Ο συσχετισ ός ιας οικείας
διεύθυνσης ε ια care-of διεύθυνση και ο εναπο ένων χρόνος ζωής αυτού του
συσχετισ ού.
Τούνελ (Tunnel): Το ονοπάτι που ακολουθείται από ένα Internet datagram ενώ είναι
εγκλεισ ένο σε ένα άλλο Internet datagram. Το οντέλο λειτουργίας είναι ότι όταν είναι
εγκλεισ ένο το πακέτο, προωθείται σε έναν πράκτορα που γνωρίζει ότι πρέπει να το
εξάγει και να το προωθήσει τελικά στον πραγ ατικό του προορισ ό (RFC2003).
Επικεφαλίδα IP
εδο ένα IP
IP payload
Παλιά Επικεφαλίδα IP
εδο ένα IP
IP payload
Νέα Επικεφαλίδα IP

Σχήα 2-4: Εγκλεισός IP σε IP (IP in IP encapsulation)
Επισκεπτό ενο δίκτυο (Visited network): Ένα δίκτυο εκτός του οικείου δικτύου του
κινητού κό βου στο οποίο ο κινητός κό βος είναι προσαρτη ένος.
Λειτουργία
Internet Protocol
10
Το Mobile IP πρωτόκολλο είναι ένας τρόπος να πραγ ατοποιηθούν οι εξής σχετικές
λειτουργίες:
Ανακάλυψη πρακτόρων (Agent Discovery): Οι πράκτορες κινητικότητας διαφη ίζουν
τη διαθεσι ότητα σε κάθε σύνδεση για την οποία παρέχουν υπηρεσίες.
Εγγραφή (Registration): Όταν ο κινητός κό βος είναι απο ακρυσ ένος από το οικείο
του δίκτυο, γνωστοποιεί την care-of του διεύθυνση στον οικείο του πράκτορα.
Τούνελ (Tunneling): Προκει ένου τα πακέτα να παραδίνονται στον κινητό κό βο όταν
αυτός βρίσκεται σε επισκεπτό ενο δίκτυο, ο οικείος πράκτορας πρέπει να τα περάσει
έσα από «τούνελ» προς την care-of διεύθυνση.
• Οι πράκτορες κινητικότητας (οικείος και ξένος) γνωστοποιούν την ύπαρξη τους
στέλνοντας ηνύ ατα διαφή ισης πρακτόρων (agent advertisements). Εναλλακτικά
ένας κινητός κό βος πορεί να προκαλέσει ένα ήνυ α διαφή ισης πρακτόρων
απαιτώντας το.
• Αφού λάβει τη διαφή ιση ενός πράκτορα, ο κινητός κό βος αποφασίζει αν
βρίσκεται στο οικείο του δίκτυο ή σε κάποιο ξένο. Ο κινητός κό βος ουσιαστικά
συ περιφέρεται σαν οποιοσδήποτε άλλος κό βος στο οικείο του δίκτυο όταν δεν
έχει απο ακρυνθεί από αυτό.
• Όταν απο ακρυνθεί ο κινητός κό βος από το οικείο του δίκτυο, του ανατίθεται ια
care-of διεύθυνση (care of address). Αυτό επιτυγχάνεται προκαλώντας ή
περι ένοντας τη διαφή ιση του πράκτορα κινητικότητας (mobility agent) και
επικοινωνώντας αζί του. Εναλλακτικά το κινητό τερ ατικό πορεί να
επικοινωνήσει ε αντίστοιχες οντότητες διευθυνσιοδότησης χρησι οποιώντας άλλα
πρωτόκολλα, όπως για παράδειγ α το Dynamic Host Configuration Protocol
(DHCP) ή το Point-to-Point-Protocol (PPP).

Όταν βρίσκεται έξω από το οικείο του δίκτυο, ο κινητός κό βος ενη ερώνει τον
οικείο του πράκτορα για τη νέα του care-of διεύθυνση. Η ενη έρωση αυτή πορεί να
γίνεται και έσω του ξένου πράκτορα.
• Τα πακέτα (datagrams) που στέλνονται στην οικεία διεύθυνση του κινητού κό βου
αναχαιτίζονται από τον οικείο πράκτορα (home agent). Ο οικείος πράκτορας είναι ο
δρο ολογητής του οικείου δικτύου που υλοποιεί λειτουργίες Proxy ARP για την
αναχαίτιση των πακέτων αυτών. Αυτά, αντί να προωθηθούν προς την hardware
διεύθυνση, εγκλείονται σε άλλα Internet datagrams και προωθούνται από τον οικείο
πράκτορα προς την care-of διεύθυνση. Στην έξοδο του τούνελ (είτε στον ξένο
πράκτορα είτε στον ίδιο τον κινητό κό βο), εξάγονται τα πρωτότυπα datagrams, και
τελικά παραδίδονται στον κινητό κό βο.
• Στην αντίθετη κατεύθυνση, τα πακέτα που στέλνονται από τον κινητό κό βο
παραδίδονται γενικά στον προορισ ό τους χρησι οποιώντας τους κλασικούς
ηχανισ ούς δρο ολόγησης του Internet πρωτοκόλλου, χωρίς να απαιτείται να
περνάνε από τον οικείο πράκτορα.
Internet Protocol
11
Όταν ένας οικείος πράκτορας στέλνει ένα πακέτο ε τη διαδικασία τούνελ στην care-of
διεύθυνση, ο εσωτερικός προορισ ός της IP επικεφαλίδας (δηλαδή η οικεία διεύθυνση
του κινητού κό βου δεν λα βάνεται ουσιαστικά υπόψη από παρε βαλλό ενους
δρο ολογητές εταξύ του οικείου και του επισκεπτό ενου δικτύου. Στην care-of
διεύθυνση, το αρχικό πακέτο βγαίνει από το «τούνελ» και παραδίδεται στον κινητό
κό βο.
Είναι καθήκον κάθε οικείου πράκτορα να προσελκύει και να αναχαιτίζει πακέτα που
προορίζονται για την οικεία διεύθυνση καθενός από τους εγγεγρα ένους του κινητούς
κό βους. Στο Σχή α 2-5 φαίνεται η δρο ολόγηση των πακέτων προς και από έναν
κινητό κό βο απο ακρυσ ένο από το οικείο του δίκτυο. Ο κινητός κό βος
χρησι οποιεί care-of διεύθυνση στο επισκεπτό ενο δίκτυο.
Home Agent
Correspondent
Node
Mobile
Node
encapsulation
(tunneling)

Σχήα 2-5: Τριγωνική δροολόγηση
1. Ένα datagram προς τον κινητό κό βο φθάνει στο οικείο δίκτυο έσω κλασικής IP
δρο ολόγησης.
2. Το datagram αναχαιτίζεται από τον οικείο πράκτορα (Proxy ARP) και διοχετεύεται
έσω τούνελ στην care-of διεύθυνση.
3. Το datagram εξάγεται από το τούνελ και παραδίδεται στον κινητό κό βο.
4. Για datagrams που στέλνονται από τον κινητό κό βο, η κλασική IP δρο ολόγηση τα
παραδίδει στον προορισ ό τους. Στο Σχή α 2-5, ο ξένος πράκτορας είναι ο
προκαθορισ ένος δρο ολογητής (default router) του κινητού κό βου.
Προβλή ατα
Όπως έχει δειχθεί, τα πακέτα που στέλνονται στον κινητό κό βο πρέπει να περάσουν
έσα από τον οικείο πράκτορα όταν ο κινητός κό βος βρίσκεται απο ακρυσ ένος από
το οικείο δίκτυο. Τα πακέτα ό ως από τον κινητό κό βο σε άλλους στατικούς κό βους
του Internet πορούν να δρο ολογηθούν απ’ ευθείας στους προορισ ούς τους όπως
φαίνεται στο Σχή α 2-5. Η ασύ ετρη αυτή δρο ολόγηση ονο άζεται τριγωνική
δρο ολόγηση (triangular routing) και απέχει κατά πολύ από τη βέλτιστη, ειδικά στις
περιπτώσεις, όπου ο ανταποκριτής κό βος είναι πολύ κοντά στον κινητό κό βο.
Internet Protocol
12
Προκει ένου να αντι ετωπιστεί το πρόβλη α της τριγωνικής δρο ολόγησης
προτείνονται αλγόριθ οι βελτιστοποίησης της διαδικασίας της δρο ολόγησης. Τα
πλεονεκτή ατα της βελτιστοποίησης της δρο ολόγησης είναι προφανή, αφού ο
ανταποκριτής κό βος θα επικοινωνεί ε τον κινητό χωρίς τη εσολάβηση του οικείου
πράκτορα. Το εγάλο ειονέκτη α του πρωτοκόλλου που προτείνεται και η ουσιαστική
διαφορά ε το πρωτόκολλο για Mobile IP [RFC2002] είναι ότι απαιτεί αλλαγές στον
ανταποκριτή κό βο.
Η βασική ιδέα που κρύβεται πίσω από τη βελτιστοποίηση δρο ολόγησης είναι ότι τα
ονοπάτια (routes) από τους ανταποκριτές κό βους προς τους κινητούς κό βους
πορούν να βελτιωθούν αν ο ανταποκριτής κό βος έχει έναν ενη ερω ένο σύνδεσ ο
κινητικότητας (mobility binding) για τον κινητό κό βο στον πίνακα δρο ολόγησης του.
Συνεπώς προτείνεται η ανταλλαγή ηνυ άτων εταξύ του κινητού και του ανταποκριτή
κό βου για να επιτευχθεί η ενη έρωση αυτού του συνδέσ ου. Χρησι οποιώντας αυτή
την πληροφορία, ο ανταποκριτής κό βος θα πορεί να στέλνει ( έσω της διαδικασίας
τούνελ) εγκλεισ ένα πακέτα κατευθείαν στην care-of διεύθυνση του κινητού κό βου
χωρίς να εσολαβεί ο οικείος πράκτορας.
2.4 IPv6
Η έκδοση 6 του πρωτοκόλλου διαδικτύου (IP protocol) σχεδιάζεται να αντικαταστήσει
την έκδοση που χρησι οποιείται αυτή τη στιγ ή στο Internet (IPv4). Οι κυριότερες
αλλαγές που περιλα βάνονται στη νέα έκδοση του πρωτοκόλλου είναι οι εξής:
• Εκτετα ένες δυνατότητες διευθυνσιοδότησης. Η έκδοση 6 αυξάνει το έγεθος
της IP διεύθυνσης από 32 bits σε 128 bits, για να υποστηρίξει περισσότερα επίπεδα
ιεραρχίας διευθυνσιοδότησης, ένα πολύ εγαλύτερο αριθ ό κό βων (2
128
αντί για
2
32
) και απλούστερη αυτό ατη ρύθ ιση των διευθύνσεων. Η επεκτασι ότητα της
δρο ολόγησης multicast (προς περισσότερους κό βους) βελτιώνεται ε την
πρόσθεση ενός πεδίο «σκοπού» (scope) στις multicast διευθύνσεις. Καθορίζεται
ακό η ένας νέος τύπος διεύθυνσης ο anycast, που χρησι οποιείται για την αποστολή
πακέτων σε οποιονδήποτε από ία ο άδα κό βων.
• Απλούστευση της ορφής της επικεφαλίδας. Μερικά πεδία της IPv4
επικεφαλίδας καταργήθηκαν ή έγιναν επιλέξι α για να ειωθεί στις περισσότερες
περιπτώσεις το κόστος επεξεργασίας της διαχείρισης των πακέτων και να ειωθεί το
κόστος εύρους ζώνης για την IPv6 επικεφαλίδα.

Βελτιω ένη υποστήριξη για επεκτάσεις και επιλογές. Οι αλλαγές στην
επικεφαλίδα επιτρέπουν πιο αποτελεσ ατική προώθηση, λιγότερο αυστηρά όρια στο
έγεθος των πεδίων και εγαλύτερη ευελιξία για την εισαγωγή νέων επιλογών στο
έλλον.

υνατότητα ση είωσης ροής (Flow Labeling). Προστίθεται ια νέα δυνατότητα
για την υποστήριξη του αρκαρίσ ατος των πακέτων που ανήκουν σε συγκεκρι ένες
ροές κυκλοφορίας, για τις οποίες ο αποστολέας ζητά ειδική εταχείριση, όπως η-
προκαθορισ ένη ποιότητα υπηρεσίας ή υπηρεσία πραγ ατικού χρόνου (real-time).
Internet Protocol
13
• υνατότητες πιστοποίησης (authentication) και προστασίας. Καθορίζονται
επεκτάσεις για την υποστήριξη πιστοποίησης, ακεραιότητα των δεδο ένων και
(επιλεκτικά) το απόρρητο των δεδο ένων για το IPv6.
• Υποστήριξη κινητών κό βων. Υποστηρίζεται η κινητικότητα των κό βων ε τη
χρήση του Mobile IPv6 πρωτοκόλλου, στο οποίο κάθε IPv6 κό βος αθαίνει και
συγκρατεί την care-of διεύθυνση ενός κινητού κό βου και στη συνέχεια στέλνει
πακέτα κατευθείαν στον κινητό κό βο χρησι οποιώντας αυτήν την care-of
διεύθυνση.
2.4.1 ΕπικεφαλίδαIPv6Η επικεφαλίδα των πακέτων IPv6 είναι σαφώς απλούστερη από την αντίστοιχη των
πακέτων IPv4. Έχει πολύ λιγότερα υποχρεωτικά πεδία, γεγονός που κάνει την
επεξεργασία στους δρο ολογητές ευκολότερη. Η αξιοση είωτη αλλαγή ό ως είναι ο
τετραπλασιασ ός των πεδίων διευθύνσεων, που ό ως έχει την παρενέργεια ότι το
ελάχιστο ήκος ενός IP πακέτου αυξάνεται, λόγω των εγάλων πεδίων διευθύνσεων.
Αξίζει να ση ειωθεί ότι κύρια δύνα η πίσω από τη ραγδαία ανάπτυξη της IPv6
τεχνολογίας είναι η έλλειψη διαθεσί ων IPv4 διευθύνσεων. Όταν θα τεθεί σε ευρεία
χρήση το IPv6 πρωτόκολλο, θα εκλείψει αυτό το πρόβλη α και κάποια άλλα τα οποία
δεν είχαν προβλεφθεί στον αρχικό σχεδιασ ό του Internet πρωτοκόλλου πριν από 40
χρόνια.

Version

Priority

Flow Label

Payload Length

Next Header

Hop Limit


Source Address

Destination Address
Σχήα 2-6: Βασικά πεδία επικεφαλίδας IPv6
Επεξηγήσεις:
• Version (Έκδοση): 4 bits. Η έκδοση του πρωτοκόλλου Internet. Έχει την τι ή 6.
• Priority (Προτεραιότητα): 4 bits. Τι ή προτεραιότητας που ανατίθεται από την
πηγή για να υποδείξει την επιθυ ητή προτεραιότητα παράδοσης για τα πακέτα.
• Flow Label (Ετικέτα ροής): 24 bits. Μπορεί να χρησι οποιηθεί για να αρκάρει τα
πακέτα εκείνα για τα οποία ζητείται ειδική εταχείριση από τους δρο ολογητές.

Payload Length (Μήκος δεδο ένων): 16 bits. Μήκος του υπολοίπου του πακέτου
που ακολουθεί την επικεφαλίδα.
Internet Protocol
14
• Next Header (Επό ενη επικεφαλίδα): 8 bits. Αναγνωρίζει τον τύπο της
επικεφαλίδας που ακολουθεί α έσως ετά τη βασική IPv6 επικεφαλίδα.

Hop Limit (Όριο αλ άτων): 8 bits. Μειώνεται κατά ένα σε κάθε κό βο που
διασχίζει. Το πακέτο απορρίπτεται όταν η τι ή αυτή γίνει ηδέν. Παρε φερές πεδίο
ε το Χρόνο Ζωής του IPv4.

Source address (ιεύθυνση πηγής): 128 bits
• Destination address (ιεύθυνση προορισ ού): 128 bits
Στο IPv6, πορεί να ενσω ατωθεί επιλεκτικά και άλλη πληροφορία σε ξεχωριστές
επικεφαλίδες επέκτασης, που τοποθετούνται εταξύ της IPv6 επικεφαλίδας και της
επικεφαλίδας του ανώτερου στρώ ατος σε ένα πακέτο. Όπως φαίνεται από τα
παρακάτω παραδείγ ατα, ένα IPv6 datagram πορεί να περιέχει κα ία ή περισσότερες
επικεφαλίδες επέκτασης, όπου η κάθε ία αναγνωρίζεται από το πεδίο Επό ενης
Επικεφαλίδας στην προηγού ενη επικεφαλίδα.

IPv6 Επικεφαλίδα

Επό ενη
Επικεφαλίδα =
ΤCP

Επικεφαλίδα TCP
+
δεδο ένα
IPv6 Επικεφαλίδα

Επό ενη
Επικεφαλίδα =
ρο ολόγηση
Επικεφαλίδα
ρο ολόγησης
Επό ενη
Επικεφαλίδα =
TCP

Επικεφαλίδα TCP
+
δεδο ένα
IPv6 Επικεφαλίδα

Επό ενη
Επικεφαλίδα =
ρο ολόγηση
Επικεφαλίδα
ρο ολόγησης
Επό ενη
Επικεφαλίδα =
Κατακερ ατισ ός
Επικεφαλίδα
Κατακερ ατισ ού
Επό ενη
Επικεφαλίδα =
TCP

Τ ή α
Επικεφαλίδας TCP
+ δεδο ένα
Σχήα 2-7: Επικεφαλίδες επέκτασης IPv6
Με την εξαίρεση της επικεφαλίδας επέκτασης Hop-by-Hop (άλ α προς άλ α) οι
δρο ολογητές δεν επεξεργάζονται τις επικεφαλίδες επέκτασης.
2.5 MobileIPv6
Το IPv4 δεν προσφέρει υποστήριξη για κινητούς χρήστες, αφού το ση είο
προσάρτησης ενός κό βου θεωρείται σταθερό. Γι’ αυτό, αναπτύχθηκε ένα επιπρόσθετο
σύστη α, το Mobile IPv4. Μέσω αυτού του συστή ατος, ένα κινητό τερ ατικό πορεί
να συνδέεται ε το Internet χωρίς να πρέπει να αλλάζει τα υπάρχοντα χαρακτηριστικά
του δικτύου.
Η επό ενη γενιά του Internet πρωτοκόλλου IPv6 θα έχει υποστήριξη για κινητικότητα
ενσω ατω ένη. εν έχει ακό η αποκρυσταλλωθεί το τελικό κεί ενο και οι τελικές
Internet Protocol
15
προδιαγραφές (specifications), ό ως η βασική φιλοσοφία και οι έθοδοι που θα
χρησι οποιούνται έχουν ήδη εδραιωθεί [ID-Johnson98].
Οι βασικές έννοιες και απαιτήσεις για το σχεδιασ ό του Mobile IPv6 είναι οι ίδιες ε
αυτές για το Mobile IPv4. Υπάρχουν δηλαδή οι έννοιες της οικείας και της care-of
διεύθυνσης, του οικείου πράκτορα, και του συνδέσ ου κινητικότητας που αντιστοιχεί
την οικεία διεύθυνση σε ία care-of διεύθυνση. Το πλεονέκτη α ό ως του σχεδιασ ού
στο Mobile IPv6 είναι ότι δεν έχει υλοποιηθεί ακό η ευρέως η νέα γενιά του Internet
πρωτοκόλλου, επο ένως κάθε IPv6 κό βος θα πορεί να καταλαβαίνει και να εκτελεί
τις λειτουργίες που σχετίζονται ε την κινητικότητα. Το γεγονός αυτό του δίνει ένα
ση αντικό πλεονέκτη α, αφού κάθε IPv6 κό βος θα πορεί να επικοινωνήσει
απρόσκοπτα ε κάθε κινητό IPv6 κό βο.
Η ορολογία δεν διαφέρει από την ορολογία του IPv4.
2.5.1 Αναλυτικήπεριγραφή
Ένας κινητός κό βος είναι πάντα προσβάσι ος έσω της οικείας του διεύθυνσης. Όταν
ο κινητός κό βος βρίσκεται στο οικείο του δίκτυο, τα πακέτα που προορίζονται γι’
αυτόν δρο ολογούνται ε τους κλασικούς ηχανισ ούς δρο ολόγησης.
Όταν ένας κινητός κό βος προσαρτείται σε κάποιο ξένο δίκτυο, είναι επίσης
προσβάσι ος έσω ίας ή περισσοτέρων care-of διευθύνσεων εκτός από την οικεία του
διεύθυνση. Ο κινητός κό βος συνήθως αποκτά την care-of διεύθυνση του έσω
αυτό ατης ανάθεσης διευθύνσεων, η οποία πορεί να χρησι οποιεί κατάσταση
(stateful) όπως το DHCPv6 [ID-Bound98] ή όχι (stateless) [Thomson98] σύ φωνα ε
τις εθόδους της Ανακάλυψης Γειτόνων (Neighbor Discovery) του IPv6 [ID-Narten98].
Τότε δηλώνει ία από τις care-of διευθύνσεις του ε έναν δρο ολογητή στο οικείο του
δίκτυο, τον οικείο του πράκτορα. Αυτή η εγγραφή του συνδέσ ου (binding registration)
πραγ ατοποιείται ε τον κινητό κό βο να στέλνει ένα πακέτο ε ια επιλογή
προορισ ού (Destination Option) ‘Binding Update’ (Ενη έρωση Συνδέσ ου) στον
οικείο πράκτορα. Αυτός απαντά επιστρέφοντας ένα πακέτο ε επιλογή προορισ ού
‘Binding Acknowledgement’ (Επιβεβαίωση Συνδέσ ου) στον κινητό κό βο. Η care-of
διεύθυνση αυτού του συνδέσ ου στον οικείο πράκτορα λέγεται πρωτεύουσα care-of
διεύθυνση (primary care-of address). Στη συνέχεια ο οικείος πράκτορας αναχαιτίζει
όποια πακέτα προορίζονται για την οικεία διεύθυνση του κινητού κό βου και τα
προωθεί έσω «τούνελ» στην πρωταρχική care-of διεύθυνση του κινητού κό βου. Για
να επαναπροωθήσει τα πακέτα, ο οικείος πράκτορας χρησι οποιεί εγκλεισ ό IPv6
(IPv6 encapsulation) [ID-Conta98] για να εγκλείσει τα πακέτα έσα σε άλλα
προορισ ένα για την care-of διεύθυνση του κινητού κό βου.
Οι επιλογές προορισ ού Binding Update και Binding Acknowledgement καθώς και η
επιλογή Binding Request (Αίτηση Σύνδεσης) χρησι οποιούνται επίσης προκει ένου οι
IPv6 κό βοι που επικοινωνούν ε έναν κινητό κό βο να αθαίνουν και να κατακρατούν
(cache) τον σύνδεσ ο (binding) του κινητού κό βου. Όταν στέλνει ένα πακέτο σε
οποιονδήποτε IPv6 προορισ ό, ο IPv6 κό βος ελέγχει τους κατακρατού ενους
συνδέσ ους για την ύπαρξη καταχώρισης για τη διεύθυνση προορισ ού. Αν υπάρχει
κατακρατη ένος σύνδεσ ος για αυτή τη διεύθυνση, ο κό βος χρησι οποιεί ια IPv6
Επικεφαλίδα ρο ολόγησης [ID-Deering97] (αντί για IPv6 εγκλεισ ό) για να
Internet Protocol
16
δρο ολογηθεί το πακέτο στον κινητό κό βο έσω της care-of διεύθυνσης που
υποδεικνύεται στον σύνδεσ ο. Αν ο αποστολέας κό βος δεν έχει κατακρατη ένο
σύνδεσ ο για τη διεύθυνση προορισ ού, στέλνει το πακέτο κανονικά, χωρίς
Επικεφαλίδα ρο ολόγησης, και το πακέτο αναχαιτίζεται και επαναπροωθείται από τον
οικείο πράκτορα του κινητού κό βου, όπως προαναφέρθηκε. Στη συνέχεια ο κό βος
που επικοινωνεί ε έναν κινητό κό βο θα αναφέρεται ως ανταποκριτής κό βος.
Αφού σε ένα πακέτο πορούν να αναπαρασταθούν ως Επιλογές Προορισ ού, οι
Binding Update, Binding Acknowledgement, Binding Request πορούν να
ενσω ατωθούν σε οποιοδήποτε IPv6 πακέτο. Κάθε επιλογή πορεί να αποσταλεί ε ένα
από τους παρακάτω δύο τρόπους
• Ενσω ατω ένη σε κάποιο IPv6 πακέτο που εταφέρει δεδο ένα όπως για
παράδειγ α TCP ή UDP.
• Σε ένα ξεχωριστό IPv6 πακέτο που δεν περιέχει δεδο ένα.
Το Mobile IPv6 ορίζει επίσης ια επιπλέον IPv6 Επιλογή Προορισ ού. Όταν ένας
κινητός κό βος βρίσκεται έξω από το οικείο του δίκτυο και στέλνει ένα πακέτο, θέτει
ως ιεύθυνση Πηγής ία από τις παρούσες care-of διευθύνσεις του και
συ περιλα βάνει ία ‘Home Address’ (Οικεία ιεύθυνση) Επιλογή Προορισ ού στο
πακέτο, θέτοντας της προφανώς την τι ή της οικείας του διεύθυνσης. Πολλοί
δρο ολογητές υλοποιούν πολιτική ασφάλειας όπως ‘ingress filtering’ που δεν
επιτρέπουν προώθηση των πακέτων που φαίνονται να έχουν ιεύθυνση Πηγής η οποία
δεν είναι τοπολογικά σωστή. Χρησι οποιώντας την care-of διεύθυνση ως τη ιεύθυνση
Πηγής, το πακέτο θα πορέσει να περάσει κανονικά από τέτοιους δρο ολογητές, και οι
κανόνες φιλτραρίσ ατος των δρο ολογητών θα πορούν να εντοπίζουν την πραγ ατική
φυσική πηγή του πακέτου ε τον ίδιο τρόπο ε τον οποίο εντοπίζουν πακέτα από
στατικούς κό βους. Συ περιλα βάνοντας ακό η την Επιλογή Προορισ ού Οικείας
ιεύθυνσης, ο αποστολέας κινητός κό βος πορεί να ενη ερώσει για την οικεία του
διεύθυνση τον ανταποκριτή κό βο που θα λάβει αυτό το πακέτο. Συνεπώς η χρήση της
care-of διεύθυνσης είναι διαφανής για τα επίπεδα πάνω από το επίπεδο υποστήριξης
Mobile IPv6 (δηλαδή επίπεδο εταφοράς και πάνω). Η εισαγωγή της επιλογής Οικείας
ιεύθυνσης επηρεάζει όνο την παραλαβή από τον ανταποκριτή κό βο του πακέτου.
εν δη ιουργείται ούτε αλλάζει κα ία κατάσταση στον ανταποκριτή κό βο ως
αποτέλεσ α της παραλαβής πακέτου ε Επιλογή Προορισ ού ‘Οικεία ιεύθυνση’
2.6 ιαφορέςMobileIPv4'MobileIPv6
Από τις προηγού ενες περιγραφές των πρωτοκόλλων Mobile IPv4 και Mobile IPv6 οι
διαφορές εταξύ τους πορούν να εστιαστούν στα εξής ση εία:
Κατάργηση του Ξένου Πράκτορα (Foreign Agent)
Ο Foreign Agent είναι στοιχείο απαραίτητο για το Mobile IPv4, ενώ δεν απαιτείται
για το Mobile IPv6. Ο κύριος λόγος κατάργησης του είναι ο αυτό ατος τρόπος
ανάθεσης care-of διευθύνσεων έσω πρωτοκόλλων που αναπτύχθηκαν.
Βελτιστοποίηση της ρο ολόγησης
Internet Protocol
17
Κάθε IPv6 κό βος που είναι ανταποκριτής κό βος ενός κινητού IPv6 κό βου
κατακρατεί (cache) τον σύνδεσ ο κινητικότητας (mobility binding) των κινητών
κό βων ε τους οποίους επικοινωνεί. Με τον τρόπο αυτό δεν είναι απαραίτητη η
δρο ολόγηση των πακέτων έσω του Οικείου Πράκτορα για να φθάσουν στον
κινητό κό βο. Επίσης δεν είναι απαραίτητος ο εγκλεισ ός (encapsulation), αφού
πορεί να χρησι οποιήσει την Επικεφαλίδα ρο ολόγησης.
Η ουσιαστική βέβαια διαφορά είναι η ενσω ατω ένη υποστήριξη που θα παρέχει σε
κινητούς κό βους το IPv6 και η οποία αντικατοπτρίζεται στις υποχρεωτικές συνθήκες
που πρέπει να υπακούουν όλοι οι IPv6 κό βοι (κινητοί και στατικοί) για την
υποστήριξη της κινητικότητας.
2.7 Αναφορές
[RFC791] J. B. Postel, editor. Internet Protocol, RFC 791, September
1981.
[RFC1256] S. Deering, ICMP router discovery messages, RFC 1256,
September 1991.
[RFC1688] W. Simpson, IPng Mobility Considerations, RFC 1688, August
1994.
[RFC1883] S. Deering, R. Hinden, Internet Protocol, Version6 (IPv6)
Specification, Network Working Group, RFC 1883, December
1995.
[RFC1885] A. Conta, S. Deering, Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification, Standards Track, RFC 1885, December 1995.
[RFC2002] C. Perkins, IP Mobility Support, IETF Standards Track, RFC
2002, October 1996.
[RFC2003] C. Perkins, IP encapsulation within IP, RFC 2003, October
1996.
[ID-Johnson98] D. Johnson, C. Perkins, Mobility Support in IPv6, Mobile IP
Working Group, Internet-draft, Work in Progress, <draft-ietf-
mobileip-ipv6-05.txt>, March ’98.
[ID-Johnson97] D. Johnson, C. Perkins Route Optimization in Mobile IP,
Internet Draft, <draft-ietf-mobileip-optim-07.txt>, December
1997.
[ID-Bound98] J. Bound, C. Perkins Dynamic Host Configuration Protocol for
IPv6 (DHCPv6), Internet Draft, <draft-ietf-dhc-dhcpv6-12.txt>,
March 1998.
Internet Protocol
18
[ID-Thomson98] S. Thomson, T. Narten, IPv6 Stateless Address
Autoconfiguration, Internet Draft, <draft-ietf-ipngwg-addrconf-
v2-02.txt>, February 1998.
[ID-Narten98] T. Narten, W. Simpson, E. Nordmark, Neighbor Discovery for
IP Version 6 (IPv6), Internet Draft, <draft-ietf-ipngwg-
discovery-v2-02.txt>, February 1998.
[ID-Conta98] A. Conta, S. Deering, Generic Packet Tunneling in IPv6
Specification, Internet Draft, <draft-ietf-ipngwg-ipv6-tunnel-
08.txt>, February 1998.
[ID-Deering97] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification, Internet Draft, <draft-ietf-ipngwg-ipv6-spec-v2-
01.txt>, December 1997.
[Perkins96] C. Perkins, D. Johnson, Mobility Support in IPv6, Proceedings
of MobiCom ’96, November 10-12, 1996, Rye, New York,
USA.
[Perkins97] C. Perkins, Mobile IP, IEEE Communications Magazine, May
1997.
[Tannenbaum89] A. Tannenbaum, Computer Networks, Second Edition, Prentice
Hall, 1989.

RSVP

RSVP
3. Γενικήεπισκόπησητουκεφαλαίου
Στο κεφάλαιο αυτό περιγράφεται το πρωτόκολλο δέσ ευσης πόρων RSVP. Αναλύονται
οι λειτουργικές του οντότητες, τα οντέλα δέσ ευσης πόρων που χρησι οποιεί και οι
ηχανισ οί ε τους οποίους λειτουργεί και επικοινωνεί ε άλλα πρωτόκολλα.
3.1 Εισαγωγή
Η παρούσα αρχιτεκτονική του Internet, όπως αυτή καθορίζεται από το Internet
πρωτόκολλο παρέχει ένα πολύ απλό οντέλο υπηρεσιών. Το IP δεν προϋποθέτει τίποτε
για τα πρωτόκολλα που βρίσκονται σε κατώτερο επίπεδο (επίπεδο σύνδεσης link layer)
και προσφέρει ια υπηρεσία στρώ ατος δικτύου χωρίς σύνδεση (connectionless), η
αξιόπιστη, που δεν αποκλείει την απώλεια πακέτων, αναδιάταξη της σειράς τους και
διπλότυπα αντίγραφα τους. Τα προβλή ατα αυτά, αζί ε την καθυστέρηση στους
δρο ολογητές εγαλώνουν ε την αύξηση του φόρτου στο δίκτυο. Εξαιτίας της
έλλειψης σαφών εγγυήσεων, το παραδοσιακό IP οντέλο παράδοσης αναφέρεται ως
«καλύτερης προσπάθειας» (best effort). Απαιτούνται επιπρόσθετα πρωτόκολλα
ανώτερου επιπέδου που να παρέχουν αξιοπιστία από άκρη σε άκρη όπως το TCP
(Transmission Control Protocol). Το TCP παρέχει την απαιτού ενη αξιοπιστία
χρησι οποιώντας ηχανισ ούς επανα ετάδοσης πακέτων, οι οποίοι αυξάνουν επιπλέον
την ολική καθυστέρηση εταφοράς της πληροφορίας.
Τα τελευταία χρόνια, αναπτύχθηκαν πολλές νέες κατηγορίες κατανε η ένων
εφαρ ογών, όπως τηλεδιάσκεψη, εικονική πραγ ατικότητα. Είναι προφανές ότι το
πρωτόγονο οντέλο του Internet είναι ανεπαρκές για αυτές τις νέες εφαρ ογές. Η
ανεπάρκεια αυτή προκύπτει από την αποτυχία του οντέλου ση είου-προς-ση είου,
καλύτερης προσπάθειας να καλύψει δύο βασικές ανάγκες των εφαρ ογών. Κατ’ αρχήν,
πολλές από αυτές τις εφαρ ογές είναι ευαίσθητες στην ποιότητα της υπηρεσίας που
προσφέρεται στα πακέτα τους. Προκει ένου ένα δίκτυο να προσφέρει την κατάλληλη
ποιότητα υπηρεσίας πρέπει να αναβαθ ιστεί από το υπάρχον οντέλο καλύτερης
προσπάθειας και να επιτρέπει ροές. Η ροή (flow) είναι ο γενικός όρος που θα
χρησι οποιείται για διακριτά ρεύ ατα κυκλοφορίας δεδο ένων σε ένα δίκτυο. Στη
συνέχεια, οι νέες αυτές εφαρ ογές δεν ακολουθούν αυστηράτο οντέλο ση είου-προς-
ση είο ε ένα οναδικό αποστολέα και ένα οναδικό δέκτη. Αντίθετα, πολλές φορές οι
εφαρ ογές αυτές έχουν περισσότερους από έναν αποστολείς ή/και δέκτες, όπως στο
παράδειγ α της τηλεδιάσκεψης ή της τηλεκπαίδευσης.
Αυτό δεν είναι ιδιαίτερο πρόβλη α για την παραδοσιακή κυκλοφορία στο Internet, η
οποία δεν είναι πραγ ατικού χρόνου, όπως δεδο ένα FTP. Ό ως, τα τελευταία χρόνια
αναπτύσσονται ραγδαία νέες εφαρ ογές πραγ ατικού χρόνου που απαιτούν
επικοινωνίες πολυ έσων, όπως η τηλεδιάσκεψη. Οι εφαρ ογές αυτές είναι τόσο
ευαίσθητες στις καθυστερήσεις, που το IP πρωτόκολλο είναι ανεπαρκές ακό η και σε
RSVP
20
έτριο φόρτο. Μερικές φορές το πρόβλη α αυτό απαλύνεται εισάγοντας στην
εφαρ ογή πληροφορία για το φόρτο του δικτύου. Παρόλα αυτά, υπάρχει ανάγκη
υποστήριξης πολλών εφαρ ογών ε επαυξη ένες εγγυήσεις παρεχό ενης υπηρεσίας
σχετικά ε το εύρος ζώνης, καθυστέρηση πακέτων και απωλειών.
Η έρευνα τα τελευταία χρόνια στράφηκε προς την ανάπτυξη νέων αρχιτεκτονικών και
οντέλων υπηρεσιών για την καλύτερη εξυπηρέτηση των απαιτήσεων των νέων
εφαρ ογών. Μολονότι προέκυψαν προτάσεις ε βασικές διαφορές, υπάρχει συναίνεση
ότι κάθε νέα αρχιτεκτονική ικανή να εξυπηρετήσει multicast και ποικιλία ποιότητας
υπηρεσιών πορεί να διαιρεθεί σε πέντε διακριτά τ ή ατα:
1. Προδιαγραφή ροής (Flow specification). Το δίκτυο και οι διάφορες ροές
δεδο ένων χρειάζονται ια κοινή γλώσσα επικοινωνίας, ώστε η πηγή να ενη ερώνει
το δίκτυο τα χαρακτηριστικά της ροής και το δίκτυο να καθορίζει την ποιότητα
υπηρεσίας για αυτή τη ροή.
2.
ρο ολόγηση (Routing).
Το δίκτυο πρέπει να αποφασίζει πώς να εταφέρει πακέτα
από την πηγή στον προορισ ό ή σε περίπτωση multicast στους προορισ ούς της
ροής.
3. έσ ευση Πόρων (Resource Reservation). Προκει ένου το δίκτυο να δώσει σε ια
συγκεκρι ένη ροή ια ποσοτικά προσδιορισ ένη ποιότητα υπηρεσίας, όπως ένα όριο
στην καθυστέρηση, είναι συνήθως αναγκαίο για το δίκτυο να φυλάξει ορισ ένους
πόρους (εύρος ζώνης, buffers).
4. Έλεγχος Αποδοχής (Admission Control). Επειδή οι πόροι ενός δικτύου είναι
πεπερασ ένοι, δεν πορεί να ικανοποιεί όλες τις αιτήσεις δέσ ευσης πόρων. Για να
διατηρηθεί ο φόρτος του δικτύου σε ένα επίπεδο, όπου πορούν να ικανοποιηθούν
όλες οι εγγυήσεις ποιότητας υπηρεσίας, η αρχιτεκτονική του δικτύου πρέπει να
περιέχει έναν ηχανισ ό ελέγχου αποδοχής. Ο ηχανισ ός αυτός καθορίζει ποιες
αιτήσεις θα ικανοποιήσει και ποιες θα απορρίψει διατηρώντας έτσι το φόρτο του
δικτύου σε ανεκτό επίπεδο.
5. Χρονοδρο ολόγηση πακέτων (Packet Scheduling). Μετά από κάθε ετάδοση
πακέτου, ένας διακόπτης στο δίκτυο πρέπει να αποφασίσει ποιο πακέτο θα
εταδώσει στη συνέχεια. Την εργασία αυτή την αναλα βάνει ο αλγόριθ ος
χρονοδρο ολόγησης πακέτων, που βρίσκεται στο κέντρο κάθε αρχιτεκτονικής
δικτύου, αφού καθορίζει ποιες ποιότητες υπηρεσίας θα πορεί το δίκτυο να παρέχει.
Το RSVP (resource ReSerVation Protocol) είναι η επικρατέστερη πρόταση αυτή τη
στιγ ή για το τ ή α της αρχιτεκτονικής που διαχειρίζεται την δέσ ευση πόρων.
3.2 Λειτουργικήπεριγραφή
Το RSVP δεσ εύει πόρους για ονοκατευθυντικές (simplex) ροές, δεσ εύει δηλαδή
πόρους όνο προς ία κατεύθυνση. Επο ένως, το RSVP εταχειρίζεται τον αποστολέα
ως λογικά διακριτή οντότητα από τον δέκτη, παρόλο που η ίδια εφαρ ογή πορεί να
συ περιφέρεται τόσο σαν αποστολέας όσο και σαν δέκτης. Το RSVP λειτουργεί πάνω
από το Internet πρωτόκολλο (IPv4 ή IPv6) καταλα βάνοντας τη θέση ενός
RSVP
21
πρωτοκόλλου εταφοράς στη στοίβα των πρωτοκόλλων. Παρόλα αυτά, το RSVP δεν
εταφέρει δεδο ένα εφαρ ογών, αλλά είναι ένα πρωτόκολλο ελέγχου του IP όπως τα
ICMP (Internet Control Message Protocol), IGMP (Internet Group Message Protocol)
και τα διάφορα πρωτόκολλα δρο ολόγησης. Όπως και οι υπόλοιπες υλοποιήσεις των
πρωτοκόλλων δρο ολόγησης και διαχείρισης, η διεργασία RSVP υλοποιείται στο
παρασκήνιο.
Το RSVP δεν είναι πρωτόκολλο δρο ολόγησης. Σχεδιάστηκε να λειτουργεί ε παρόντα
και ελλοντικά unicast και multicast πρωτόκολλα δρο ολόγησης (OSPF). Η διεργασία
RSVP συ βουλεύεται την τοπική βάση δεδο ένων δρο ολόγησης για να αποκτήσει τις
διαδρο ές. Στην περίπτωση multicast για παράδειγ α, ένας κό βος στέλνει ηνύ ατα
IGMP για να εισαχθεί σε ια multicast ο άδα και στη συνέχει στέλνει RSVP ηνύ ατα
για να δεσ εύσει πόρους κατά ήκος του ονοπατιού αυτής της ο άδας. Τα
πρωτόκολλα δρο ολόγησης καθορίζουν που προωθούνται τα πακέτα. Το RSVP
ασχολείται όνο ε την ποιότητα υπηρεσίας που απολα βάνουν τα πακέτα αυτά.
Για την αποτελεσ ατική διαχείριση εγάλων ο άδων, δυνα ική εισαγωγή και διαγραφή
ελών των ο άδων ετερογενείς απαιτήσεις δεκτών, το RSVP καθιστά τους δέκτες
υπεύθυνους για την αίτηση για ια συγκεκρι ένη ποιότητα υπηρεσίας. Μια αίτηση
ποιότητας υπηρεσίας από ια εφαρ ογή σε ένα δέκτη προωθείται στην τοπική
διεργασία RSVP. Το RSVP στη συνέχεια εταφέρει την αίτηση σε όλους τους κό βους
κατά ήκος του αντιστρόφου ονοπατιού των δεδο ένων στην πηγή των δεδο ένων. Η
αίτηση δεν χρειάζεται να εταφερθεί ακρύτερα από τον δρο ολογητή όπου το
ονοπάτι δεδο ένων του δέκτη ενώνεται ε το δένδρο διανο ής multicast. Αυτό έχει ως
αποτέλεσ α το κόστος επεξεργασίας της δέσ ευσης να είναι γενικά λογαριθ ικό αντί
για γρα ικό ως προς τον αριθ ό των δεκτών.
Εφαρ ογή
ιεργασία
RSVP
Έλεγχος
Πολιτικής
Αξιολογητής
Χρονοδρ/τής
πακέτων
Έλεγχος
Εισαγωγής
ιεργασία
RSVP
Έλεγχος
Πολιτικής
Έλεγχος
ρο /σης
Αξιολογητής
Χρονοδρ/τής
πακέτων
Έλεγχος
Εισαγωγής
RSVP
εδο έναεδο ένα
Κό βος ρο ολογητής

Σχήα 3-1: Το RSVP σε κόβους και δροολογητές
Η ποιότητα υπηρεσίας υλοποιείται για ια συγκεκρι ένη ροή δεδο ένων από
ηχανισ ούς που ονο άζονται από κοινού «έλεγχος κυκλοφορίας». Οι ηχανισ οί
αυτοί συ περιλα βάνουν (1) έναν αξιολογητή πακέτων (classifier), (2) έλεγχο
αποδοχής (admission control), και (3) έναν χρονοδρο ολογητή πακέτων (scheduler) ή
κάποιον άλλο ηχανισ ό που εξαρτάται από το επίπεδο σύνδεσης που να καθορίζει
πότε θα προωθούνται συγκεκρι ένα πακέτα. Ο αξιολογητής πακέτων καθορίζει την
RSVP
22
κλάση της ποιότητας υπηρεσίας και πιθανώς τη δρο ολόγηση για κάθε πακέτο. Για
κάθε εξερχό ενη διασύνδεση, ο χρονοδρο ολογητής πακέτων ή κάποιος παρε φερής
ηχανισ ός επιτυγχάνει την επιθυ ητή ποιότητα υπηρεσίας. Ο έλεγχος κυκλοφορίας
υλοποιεί οντέλα ποιότητας υπηρεσιών που καθορίζονται από το Integrated Services
Working Group, το οποίο είναι ο άδα εργασίας στην IETF που αναπτύσσει
πρωτόκολλα για ολοκληρω ένες υπηρεσίες.
Κατά τη διάρκεια της αρχικοποίησης της δέσ ευσης, η RSVP αίτηση ποιότητας
υπηρεσίας προωθείται σε δύο τοπικές ονάδες απόφασης: στον έλεγχο αποδοχής
(admission control) και στον έλεγχο πολιτικής (policy control). Ο έλεγχος αποδοχής
ελέγχει αν ο κό βος έχει επαρκείς διαθέσι ους πόρους να παράσχει τη ζητού ενη
ποιότητα υπηρεσίας. Ο έλεγχος πολιτικής καθορίζει αν ο χρήστης έχει δικαιώ ατα
διοίκησης για να κάνει την δέσ ευση. Αν πετύχουν και οι δύο έλεγχοι, τίθενται οι
παρά ετροι στον αξιολογητή πακέτων και στη διασύνδεση ε το επίπεδο σύνδεσης
(δηλαδή στον χρονοδρο ολογητή πακέτων) για να επιτευχθεί η επιθυ ητή ποιότητα
υπηρεσίας. Αν ένας από τους δύο ελέγχους αποτύχει, η διεργασία RSVP επιστρέφει ια
ειδοποίηση σφάλ ατος στην διεργασία εφαρ ογής που υπέβαλε την αίτηση.
Οι ηχανισ οί του πρωτοκόλλου RSVP παρέχουν έναν εύκολο τρόπο δη ιουργίας και
διατήρησης καταστάσεων δεσ εύσεων πόρων δια έσου ενός πλέγ ατος ονοπατιών
unicast και multicast. Το ίδιο το RSVP εταφέρει και εταχειρίζεται παρα έτρους
ποιότητας υπηρεσίας και ελέγχου πολιτικής σαν αδιαφανή δεδο ένα, εταφέροντας τις
στις κατάλληλες ονάδες ελέγχου κυκλοφορίας και ελέγχου πολιτικής για διερ ηνεία.
Η δο ή και τα περιεχό ενα των παρα έτρων ποιότητας υπηρεσίας καθορίζονται στο
[RFC2210]. Η δο ή και τα περιεχό ενα των παρα έτρων ελέγχου πολιτικής
αναπτύσσονται ακό η [ID-Herzog97].
Αφού τα έλη ιας εγάλης ο άδας multicast και η προκύπτουσα δενδρική τοπολογία
multicast είναι πιθανό να αλλάξουν ε το χρόνο, η σχεδίαση του RSVP υποθέτει ότι η
κατάσταση για το RSVP και τον έλεγχο κυκλοφορίας πρέπει να δη ιουργείται και να
καταργείται σταδιακά σε δρο ολογητές και κό βους. Για το λόγο αυτό, το RSVP
εγκαθιστά « αλακή» κατάσταση (soft state). Το RSVP δηλαδή στέλνει περιοδικά
ηνύ ατα «φρεσκαρίσ ατος» για τη διατήρηση της κατάστασης κατά ήκος των
δεσ ευ ένων ονοπατιών. Αν τα ηνύ ατα αυτά δεν ε φανιστούν, λήγει ο χρόνος της
κατάστασης δέσ ευσης και έτσι καταργείται.
Συνοπτικά το RSVP έχει τις παρακάτω ιδιότητες:
• Το RSVP πραγ ατοποιεί δεσ εύσεις πόρων τόσο για unicast όσο και για multicast
εφαρ ογές, προσαρ οζό ενο δυνα ικά σε εταβαλλό ενες multicast ο άδες όσο και
σε αλλαγές δρο ολόγησης.

Το RSVP είναι ονοκατευθυντικό, πραγ ατοποιεί δηλαδή δεσ εύσεις για
ονοκατευθυντικές ροές δεδο ένων.
• Το RSVP είναι κατευθυνό ενο από το δέκτη. Ο δέκτης ιας ροής δεδο ένων
αρχικοποιεί και διατηρεί την δέσ ευση πόρων που χρησι οποιείται για αυτή τη ροή.
RSVP
23
• Το RSVP διατηρεί « αλακή» κατάσταση σε δρο ολογητές και κό βους παρέχοντας
υποστήριξη για δυνα ικές αλλαγές σε ο άδες και αυτό ατη προσαρ ογή σε αλλαγές
δρο ολόγησης.
• Το RSVP δεν είναι πρωτόκολλο δρο ολόγησης, αλλά εξαρτάται από τα υπάρχοντα
και τα ελλοντικά πρωτόκολλα δρο ολόγησης.

Το RSVP εταφέρει και διατηρεί παρα έτρους ελέγχου κυκλοφορίας και ελέγχου
πολιτικής που είναι αδιαφανείς στο RSVP.
• Το RSVP παρέχει αρκετά οντέλα δέσ ευσης πόρων ή «στυλ» για να υποστηρίζει
ποικιλία εφαρ ογών.

Το RSVP παρέχει διαφανή λειτουργία δια έσου δρο ολογητών που δεν το
υποστηρίζουν.
• To RSVP υποστηρίζει τόσο IPv4 όσο και IPv6.
3.3 Ροέςδεδο/ένων
To RSVP χρησι οποιεί τον όρο συνεδρία (session) για να ορίσει ια ροή δεδο ένων ε
ένα συγκεκρι ένο προορισ ό και πρωτόκολλο επιπέδου εταφοράς. Το RSVP
εταχειρίζεται κάθε συνεδρία ξεχωριστά.
Μια συνεδρία RSVP ορίζεται από την τριάδα (DestAddress, ProtocolID [, DstPort] ).
Εδώ DestAddress είναι η IP διεύθυνση προορισ ού των πακέτων δεδο ένων (unicast ή
multicast). ProtocolID είναι η ταυτότητα του πρωτοκόλλου επιπέδου εταφοράς.
DstPort είναι η παρά ετρος επιλογής που αντιστοιχεί στο γενικευ ένο port προορισ ού,
δηλαδή κάποιο περαιτέρω ση είο αποπολυπλεξίας στο επίπεδο εταφοράς ή
εφαρ ογής. Το DstPort πορεί να οριστεί από ένα πεδίο port προορισ ού UDP/TCP,
από ένα ισοδύνα ο πεδίο σε ένα άλλο επίπεδο εταφοράς ή από κάποια πληροφορία
από την εφαρ ογή.
3.4 Μοντέλοέσ/ευσης
Μια στοιχειώδης αίτηση δέσ ευσης στο RSVP αποτελείται από ένα ‘flowspec’
(προδιαγραφή ροής) αζί ε ένα ‘filter spec’ (προδιαγραφή φίλτρου). Το flowspec
καθορίζει την επιθυ ητή ποιότητα υπηρεσίας. Το filter spec αζί σε ε ια
προδιαγραφή συνεδρίας καθορίζουν το σύνολο των πακέτων δεδο ένων -τη ροή- που
θα λάβει την ποιότητα υπηρεσίας που καθορίστηκε ε το flowspec. Το flowspec
χρησι οποιείται για να τίθενται οι παρά ετροι στο χρονοδρο ολογητή πακέτων του
κό βου ή τους άλλους ηχανισ ούς του στρώ ατος σύνδεσης. Το filter spec
χρησι οποιούνται για να τίθενται οι παρά ετροι στον αξιολογητή πακέτων. Τα πακέτα
δεδο ένων που κατευθύνονται προς κα ία συγκεκρι ένη συνεδρία, αλλά δεν
ταιριάζουν σε κανένα από τα filter specs για τη συνεδρία αυτή υφίστανται εταχείριση
καλύτερης προσπάθειας.
RSVP
24
Το flowspec σε ια αίτηση δέσ ευσης γενικά θα συ περιλα βάνει ια κλάση ποιότητας
υπηρεσίας και δύο σύνολα αριθ ητικών παρα έτρων: (α) ένα ‘Rspec’ (R για reserve,
δηλαδή δέσ ευση) που καθορίζει την επιθυ ητή ποιότητα υπηρεσίας και (β) ένα
‘Tspec’ (T για traffic, κυκλοφορία) που περιγράφει τη ροή δεδο ένων. Η δο ή και τα
περιεχό ενα των Tspec και Rspec καθορίζονται στο [RFC 2210] και είναι γενικά
αδιαφανή στο RSVP.
Σε κάθε ενδιά εσο δρο ολογητή, ια αίτηση δέσ ευσης προκαλεί δύο γενικές ενέργειες
ως εξής:
1. %έσευση σε ένα σύνδεσο
Η διεργασία RSVP εταβιβάζει την αίτηση στον έλεγχο αποδοχής και τον έλεγχο
πολιτικής. Αν ένας από τους δύο ελέγχους αποτύχουν, η αίτηση απορρίπτεται και η
διεργασία RSVP επιστρέφει ένα ήνυ α λάθους στον κατάλληλο αποδέκτη. Αν
επιτύχουν και οι δύο, ο κό βος θέτει τον αξιολογητή πακέτων να επιλέγει τα πακέτα
δεδο ένων που ορίζονται από το filter spec και επικοινωνεί ε το κατάλληλο επίπεδο
σύνδεσης για να επιτευχθεί η επιθυ ητή ποιότητα υπηρεσίας που ορίζεται στο flowspec.
Οι λεπτο ερειακοί κανόνες για την ικανοποίηση ιας αίτησης δέσ ευσης RSVP
εξαρτώνται από την συγκεκρι ένη τεχνολογία επιπέδου σύνδεσης που χρησι οποιείται
σε κάθε διασύνδεση. Οι προδιαγραφές αναπτύσσονται προς το παρόν για τα διάφορα
επίπεδα σύνδεσης. Για παράδειγ α, η επιθυ ητή ποιότητα υπηρεσίας επιτυγχάνεται από
τον χρονοδρο ολογητή πακέτων, ο οποίος είναι υλοποιη ένος στον οδηγό του επιπέδου
σύνδεσης. Αν η τεχνολογία του επιπέδου σύνδεσης υλοποιεί τις δικές της ικανότητες
διαχείρισης ποιότητας υπηρεσίας (ATM για παράδειγ α), το RSVP πρέπει να
διαπραγ ατευθεί ε το επίπεδο σύνδεσης για να επιτύχει την επιθυ ητή ποιότητα
υπηρεσίας.
2. Προώθηση της αίτησης προς τα πάνω (προς τον αποστολέα)
Μια αίτηση δέσ ευσης προωθείται προς τα πάνω προς τους κατάλληλους αποστολείς.
Το σύνολο των αποστολέων-κό βων στο οποίο προωθείται ια δεδο ένη αίτηση
δέσ ευσης λέγεται ο «σκοπός» (scope) της αίτησης.
Η αίτηση δέσ ευσης που ένας κό βος προωθεί προς τα πάνω πορεί να διαφέρει από
την αίτηση που δέχεται από κάτω για δύο λόγους. Ο ηχανισ ός ελέγχου κυκλοφορίας
πορεί να εταβάλει την αίτηση κό βο-προς-κό βο. Ακό η, οι δεσ εύσεις από
διαφορετικά κλαδιά ενός multicast δένδρου από τον ίδιο αποστολέα πρέπει να
συγχωνευθούν καθώς οι αιτήσεις προωθούνται προς τα πάνω.
3.5 Μηχανισ/οίτουπρωτοκόλλουRSVP
Το Σχή α 3-2 παρουσιάζει το οντέλο του RSVP για ένα κό βο δρο ολογητή. Κάθε
ροή δεδο ένων φθάνει από το «προηγού ενο άλ α», δηλαδή από τον προηγού ενο
κό βο έσω ιας ή περισσότερων αντίστοιχων εισερχό ενων διεπαφών και
απο ακρύνεται έσω ιας ή περισσοτέρων εξερχό ενων διεπαφών. Η ίδια διεπαφή
πορεί να είναι εισερχό ενη και εξερχό ενη για διαφορετικές ροές δεδο ένων.
Περισσότερα προηγού ενα άλ ατα ή/και επό ενα άλ ατα πορεί να είναι προσβάσι α
RSVP
25
έσω ιας δεδο ένης φυσικής διεπαφής. Για παράδειγ α στο Σχή α 3-2 φαίνεται ότι τα
(D) και (D’) είναι συνδεδε ένα στο (d) χρησι οποιώντας ένα broadcast LAN.
A
B
B’
C
D
D’
εδο ένα
Path
Resv
εδο ένα
Path
Resv
εδο ένα
Path
Resv
Path
Resv
εδο ένα
ρο ολογητής
a
b
c
d
Προηγού ενο
άλ α
Εισερχό ενη
δι
επαφή
Εξερχό ενη
διεπαφ
ή
Επό ενο
άλ α

Σχήα 3-2: %ροολογητής που χρησιοποιεί RSVP
Υπάρχουν δύο θε ελιώδη τύποι ηνυ άτων στο RSVP: Resv και Path:
Κάθε δέκτης στέλνει ηνύ ατα αιτήσεων δέσ ευσης RSVP (Resv) προς την πηγή. Τα
ηνύ ατα αυτά πρέπει να ακολουθήσουν ακριβώς την αντίστροφη πορεία του
ονοπατιού που θα χρησι οποιήσουν τα πακέτα δεδο ένων προς τους αποστολείς που
περιγράφονται στην επιλογή αποστολέων. η ιουργούν και διατηρούν «κατάσταση
δέσ ευσης» (reservation state) σε κάθε κό βο κατά ήκος του ονοπατιού. Τα
ηνύ ατα Resv πρέπει τελικά να παραδοθούν στους αποστολείς κό βους, ώστε οι
κό βοι να θέσουν τις κατάλληλες παρα έτρους ελέγχου κυκλοφορίας για το πρώτο
άλ α.
Κάθε αποστολέας εταδίδει ηνύ ατα RSVP Path προς τους δέκτες κατά ήκος των
ονοπατιών δρο ολόγησης που παρέχονται από τα πρωτόκολλα δρο ολόγησης. Τα
ηνύ ατα Path αυτά δη ιουργούν «κατάσταση ονοπατιού» (path state) σε κάθε κό βο
κατά ήκος της διαδρο ής. Η κατάσταση ονοπατιού αυτή συ περιλα βάνει
τουλάχιστον την IP διεύθυνση του κό βου του προηγού ενου άλ ατος, η οποία
χρησι οποιείται για τη δρο ολόγηση των Resv ηνυ άτων κό βο-προς-κό βο στην
αντίστροφη κατεύθυνση. Στο έλλον κάποια πρωτόκολλα δρο ολόγησης πορεί να
παρέχουν την πληροφορία αντιστρόφου ονοπατιού απ’ ευθείας, αντικαθιστώντας έτσι
τη λειτουργία αντίστροφης δρο ολόγησης της κατάστασης ονοπατιού. Το ήνυ α
Path περιέχει ακό η τις εξής πληροφορίες εκτός από τη διεύθυνση του προηγού ενου
άλ ατος:
• Sender Template. Υποχρεωτικό. Περιγράφει την ορφή των πακέτων δεδο ένων που
θα στέλνει ο αποστολέας.
• Sender Tspec. Υποχρεωτικό. Καθορίζει τα χαρακτηριστικά κυκλοφορίας της ροής
δεδο ένων που θα ξεκινήσει ο αποστολέας. Χρησι οποιείται από τον έλεγχο
κυκλοφορίας για να αποτρέψει την υπερ-δέσ ευση και ίσως αποτυχία του ελέγχου
αποδοχής.
• Adspec. Προαιρετικό. Περιέχει πληροφορία διαφή ισης OPWA (One Pass With
Advertising). Προωθείται στον τοπικό έλεγχο κυκλοφορίας, από όπου επιστρέφεται
RSVP
26
ένα ανανεω ένο Adspec. Η ενη ερω ένη έκδοση του προωθείται στη συνέχεια έσα
στα ηνύ ατα Path προς τους δέκτες.
Τα Path ηνύ ατα στέλνονται ε τις ίδιες διευθύνσεις πηγής και προορισ ού όπως και
τα δεδο ένα, ώστε να δρο ολογούνται σωστά έσω δικτύων που δεν υποστηρίζουν
RSVP. Από την άλλη εριά τα ηνύ ατα Resv στέλνονται άλ α-προς-άλ α και κάθε
κό βος που υποστηρίζει RSVP προωθεί το ήνυ α RSVP στην unicast διεύθυνση του
προηγού ενου άλ ατος RSVP.
3.5.1 ΣυγχώνευσηFlowspecs
Ένα ήνυ α Resv που προωθείται στο προηγού ενο άλ α εταφέρει ένα flowspec που
είναι το εγαλύτερο από τα flowspecs που ζητήθηκαν από τα επό ενα άλ ατα προς τα
οποία θα σταλθούν τα δεδο ένα. Η διαδικασία αυτή ονο άζεται συγχώνευση των
flowspecs. Μια άλλη περίπτωση συγχώνευσης είναι όταν υπάρχουν πολλαπλές αιτήσεις
από διαφορετικά επό ενα άλ ατα για την ίδια συνεδρία και ε το ίδιο filter spec, αλλά
το RSVP πρέπει να εγκαταστήσει όνο ία δέσ ευση σε αυτή τη διασύνδεση. Εδώ
πάλι, η εγκαταστη ένη δέσ ευση πρέπει να έχει ένα αποτελεσ ατικό flowspec που
είναι το εγαλύτερο από τα flowspecs που ζητήθηκαν από τα επό ενα άλ ατα.
3.5.2 Μαλακήκατάσταση(Softstate)
Το RSVP προσεγγίζει το πρόβλη α της κατάστασης δέσ ευσης σε υπολογιστές και
δρο ολογητές υιοθετώντας τη αλακή κατάσταση. Η αλακή κατάσταση του RSVP
δη ιουργείται και περιοδικά φρεσκαρίζεται από ηνύ ατα Path και Resv. Η κατάσταση
διαγράφεται αν δεν καταφτάσουν ηνύ ατα φρεσκαρίσ ατος πριν τη λήξη ενός
χρονικού διαστή ατος. Η κατάσταση πορεί επίσης να διαγραφεί ε ένα σαφές ήνυ α
διαγραφής. Στη λήξη κάθε διαστή ατος φρεσκαρίσ ατος και ετά από κάθε αλλαγή
κατάστασης, το RSVP ανιχνεύει την κατάσταση του για να στείλει και προωθήσει τα
Path και Resv ηνύ ατα σε επό ενους κό βους.
3.6 Αναφορές
[RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource
ReSerVation Protocol (RSVP) – Version 1 Functional
Specification, RFC 2205, September 1997.
[RFC2210] J. Wroclawski, The Use of RSVP with Integrated Services, RFC
2210, September 1997.
[ID-Herzog97] S. Herzog, RSVP Extensions for Policy Control, Internet Draft,
<draft-ietf-rsvp-policy-ext-02.txt, .ps>, March 1997.
[Zhang93] L. Zhang, S. Deering, D. Estrin, S. Schenker, D. Zappala, RSVP:
A New Resource ReSerVation Protocol, IEEE Network
Magazine, September 1993.
[White97] P. White, RSVP and Integrated Services in the Internet: A
Tutorial ’, IEEE Communications Magazine, May 1997.
ATM

AsynchronousTransferMode(ΑΤΜ)
4. Γενικήεπισκόπησητουκεφαλαίου
Στο κεφάλαιο αυτό επιχειρείται ια ανασκόπηση της τεχνολογίας ΑΤΜ. Εισάγονται
βασικοί όροι και έννοιες καθώς και η γενική αρχιτεκτονική. Στη συνέχεια αναλύονται
τα συστατικά στοιχεία ενός ΑΤΜ δικτύου και ο τρόπος λειτουργίας του.
4.1 ΓενικήΕπισκόπησητουΚεφαλαίου
Στο κεφάλαιο αυτό γίνεται η παρουσίαση του Asynchronous Transfer Mode (ATM).
Περιγράφεται ένα τυπικό ATM δίκτυο, παρουσιάζονται τα επίπεδα ενός ATM δικτύου,
περιγράφονται τα είδη της κυκλοφορίας που ένα ATM δίκτυο πορεί να εξυπηρετήσει
καθώς και οι ηχανισ οί που χρησι οποιούνται για την ο αλή λειτουργία του δικτύου.
4.2 Εισαγωγή
Η πιο ση αντική τεχνολογία που προέκυψε από την ελέτη και ανάπτυξη του B-ISDN
(Broadband Integrated Services Network) είναι το Asynchronous Transfer Mode
(ATM). Το ATM είναι ια τεχνική ετάδοσης πληροφορίας χρησι οποιώντας σταθερού
εγέθους πακέτα, τα ονο αζό ενα κελιά (cells). Ένα ση αντικό χαρακτηριστικό του
ATM είναι το ότι είναι σχεδιασ ένο να λειτουργεί σε υψηλούς ρυθ ούς ετάδοσης.
Ακό η, το ATM ενοποιεί τη ετάδοση όλων των ειδών των δεδο ένων, όπως φωνή,
στατική ή κινού ενη εικόνα, τα περιεχό ενα ενός αρχείου, σε ένα όνο δίκτυο.
Η ανάπτυξη του ATM πραγ ατοποιείται στα πλαίσια δύο διεθνών οργανισ ών. Αυτοί
οι οργανισ οί είναι η ITU-T και το ATM Forum. Η ITU-T (International
Telecommunications Union - Telecommunication Standardisation Sector) είναι ο
παγκόσ ιος οργανισ ός για την δη ιουργία προτύπων στον χώρο των τηλεπικοινωνιών.
Το ATM Forum, από την άλλη εριά, είναι ένας οργανισ ός που δη ιουργήθηκε από
την βιο ηχανία και ασχολείται ε την ανάπτυξη της ATM τεχνολογίας. Η ευρωπαϊκή
επιτροπή που ασχολείται ε την δη ιουργία προτύπων στις τηλεπικοινωνίες (European
Telecommunications Standards Institute - ETSI), έχει αποφασίσει να ακολουθήσει την
ITU-T.
4.3 ATM
Όταν ξεκίνησε η ελέτη και ανάπτυξη του B-ISDN στα έσα της δεκαετίας του 1980,
υπήρξε η ιδέα να χρησι οποιηθεί κάποια σύγχρονη τεχνική πολυπλεξίας ε βάση το
χρόνο (Time Division Multiplexing-TDM). Αν και το σύγχρονο TDM θα αποτελούσε
ια φυσιολογική εξέλιξη του ISDN, δεν ταιριάζει απόλυτα στην φιλοσοφία του B-
ISDN. Κατ’ αρχάς δεν διαθέτει ια ευέλικτη διεπαφή (interface) για να αντι ετωπίσει
Asynchronous Transfer Mode
28
ια ποικιλία αναγκών. Στα πλαίσια του B-ISDN υπάρχουν εφαρ ογές που
χαρακτηρίζονται από ένα εύρος ρυθ ών ετάδοσης. Έτσι η χρήση ενός ή δύο καναλιών
σταθερού ρυθ ού ετάδοσης δεν πορεί να αντι ετωπίσει αυτή την ανάγκη. Επιπλέον
αρκετές εφαρ ογές δεδο ένων (σε αντίθεση ε τις εφαρ ογές φωνής και video)
λειτουργούν από την φύση τους υπό ορφή ριπών και επο ένως είναι πιο εύκολο να τις
διαχειριστού ε ε την χρήση πακέτων. Τέλος η χρήση σύγχρονης τεχνικής δεν οδηγεί
από όνη της στην προσαρ ογή του ρυθ ού ετάδοσης.
Ένα δεύτερο ειονέκτη α της σύγχρονης τεχνικής είναι ότι η χρήση πολλαπλών
υψηλών ρυθ ών ετάδοσης περιπλέκει το σύστη α που διενεργεί τη εταγωγή. Θα
απαιτούσα ε την χρήση switching συστη άτων που θα πορούσαν να χειριστούν
πολλαπλά κανάλια υψηλών ρυθ ών. Κάτι τέτοιο ό ως έρχεται σε αντίθεση ε το ISDN,
το οποίο χειρίζεται όνο κανάλια των 64-kbps.
Για όλους αυτούς του λόγους το σύγχρονο TDM απορρίφθηκε. Ό ως είναι εφικτό να
πολυπλεχθούν διάφορα ATM κανάλια ε την χρήση σύγχρονων TDM εθόδων, ώστε
να πετύχου ε εταδόσεις ε ρυθ ούς που είναι εγαλύτεροι από το ρυθ ό λειτουργίας
των ATM πολυπλεκτών και συστη άτων που διενεργούν το switching.
4.4 ΤοATMίκτυο
Ένα ATM δίκτυο αποτελείται από ATM switches τα οποία συνδέονται εταξύ τους
έσω ιας διεπαφής η οποία ονο άζεται Network-Node Interface (NNI). Τα τερ ατικά
συνδέονται στο δίκτυο έσω ιας άλλης διεπαφής η οποία λέγεται User-Network
Interface (UNI). Αν έσα στο δίκτυο υπάρχουν ιδιωτικοί εταγωγείς, η διεπαφή εταξύ
του ιδιωτικού και του δη όσιου τ ή ατος του δικτύου ονο άζεται Public UNI και η
σύνδεση εταξύ δύο ιδιωτικών εταγωγέων ονο άζεται Private NNI

(P-NNI).
TerminalC
TerminalB
TerminalA
NNI
NNI
NNI
NNI
UNI
UNI
UNI

Σχήα 4-1: Σύνδεση εταξύ δύο τερατικών σε ένα ATM δίκτυο
Μια σύνδεση σε ένα ATM δίκτυο ονο άζεται περνά έσα από ένα εικονικό κανάλι,
virtual channel (VC). Υπάρχουν δύο ειδών εικονικών καναλιών, τα όνι α εικονικά
κανάλια, Permanent Virtual Channels (PVCs) και τα εταγό ενα εικονικά κανάλια,
Asynchronous Transfer Mode
29
Switched Virtual Channels (SVCs). Το Σχή α 4-1 δείχνει ένα παράδειγ α ενός ATM
δικτύου, όπου δύο τερ ατικά, τα Α και Β συνδέονται ε ια εικονική σύνδεση. Σε ένα
εταγωγέα, η δρο ολόγηση γίνεται ε βάση δύο χαρακτηριστικούς αριθ ούς. Οι
αριθ οί αυτοί είναι το Virtual Path Identifier (VPI, προσδιοριστής εικονικού
ονοπατιού) και το Virtual Channel Identifier (VCI), προσδιοριστής εικονικού
καναλιού. Το ζεύγος VPI/VCI δίνεται σε κάθε εικονική σύνδεση από τον εταγωγέα
όταν εγκαθίσταται η σύνδεση και παρα ένει το ίδιο σε όλη την διάρκεια της σύνδεσης.
Θα πρέπει να τονιστεί ότι η τι ή που έχει το ζεύγος VPI/VCI έχει τοπική ση ασία και
γενικά είναι διαφορετική σε κάθε κο άτι της ATM σύνδεσης.
Το ζεύγος VPI/VCI φυλάσσεται στην κεφαλή του κάθε cell και χρησι οποιείται από τον
εταγωγέα για την δρο ολόγηση. Συγκεκρι ένα σε κάθε εταγωγέα, υπάρχει ένας
πίνακας δρο ολόγησης που περιέχει πληροφορίες για την δρο ολόγηση κάθε σύνδεσης.
Οι πληροφορίες αυτές περιέχουν εταξύ άλλων και την νέα τι ή που θα πάρει το ζεύγος
VPI/VCI καθώς και η θύρα (port) εξόδου. Ένα εικονικό ονοπάτι (virtual path)
χαρακτηρίζεται από ένα VPI και περιέχει πολλά εικονικά κανάλια (virtual channels). H
δρο ολόγηση πορεί να γίνει όνο ε βάση το VPI, χωρίς στην περίπτωση αυτή να
αλλάζει το VCI. Το Σχή α 4-2 δείχνει τη σχέση VPI/VCI σε ένα εταγωγέα.
VPI1VPI4
VPI5 VPI4
VPI8VPI1
VCI1
VCI2
VCI4VCI5
VCI4
VCI2
Link1 Link2
ATMSwitch

Σχήα 4-2: Λειτουργία ενός ATM εταγωγέα
Για την εγκαθίδρυση και διαχείριση των συνδέσεων σε ένα ATM δίκτυο είναι
απαραίτητη η χρήση κατάλληλων πρωτοκόλλων ση ατοδοσίας (signalling protocols).
Τα πρωτόκολλα αυτά είναι ακό α στην φάση της ελέτης και ανάπτυξης. Υποψήφια
για να χρησι οποιηθούν για την ση ατοδοσία στο UNI είναι το Q.2931 από την ITU-T
και το UNI Signalling από το ATM Forum. Το πρωτόκολλο ση ατοδοσίας που
πρόκειται να χρησι οποιηθεί στο NNI είναι ακό α σε πρώι ο στάδιο. Τόσο η ITU-T,
όσο και το ATM-Forum έχουν κάποιες πρώτες εκδόσεις των NNI πρωτοκόλλων. Το
ATM Forum προχωρεί στις προδιαγραφές private NNI βασισ ένο στο UNI.
Συγκεκρι ένα χρησι οποιεί τα ίδια ηνύ ατα ελέγχου αλλά περιλα βάνει και
λειτουργίες για την δρο ολόγηση των συνδέσεων.
Asynchronous Transfer Mode
30
Όταν ένα τερ ατικό θελήσει να εγκαταστήσει ια σύνδεση ε ένα άλλο τερ ατικό,
χρησι οποιεί την ση ατοδοσία του UNI (για παράδειγ α το ήνυ α SETUP του Q.2931)
για να γίνει αυτή η εγκατάσταση. Το τερ ατικό που ξεκίνησε την διαδικασία θα πρέπει
να περιγράψει την κυκλοφορία που πρόκειται να περάσει από την συγκεκρι ένη
σύνδεση και την ποιότητα υπηρεσίας (Quality of Service, QoS) που θέλει να λάβει.
Αυτό γίνεται ε την χρήση ειδικών παρα έτρων (QoS parameters). Μόλις ο εταγωγέας
λάβει την αίτηση για εγκαθίδρυση της σύνδεσης, θα ξεκινήσει την διαδικασία
επικοινωνίας ε τους άλλους εταγωγείς έσω NNI ση ατοδοσίας (αν το τερ ατικό
που ξεκινά την διαδικασία και το τερ ατικό προορισ oύ βρίσκονται στον ίδιο
εταγωγέα τότε χρησι οποιείται όνο UNI ση ατοδοσία). Η δρο ολόγηση ιας
σύνδεσης στα δη όσια δίκτυα γίνεται γενικά ε βάση το πρότυπο E.164 το οποίο
προέρχεται από την ITU-T, ενώ τα περισσότερα ιδιωτικά δίκτυα χρησι οποιούν την
NSAP διευθυνσιοδότηση του ATM Forum. Οι ATM διευθύνσεις του ATM Forum
χρησι οποιούν την σύνταξη του OSI NSAP.
Όταν ένας εταγωγέας δέχεται ια αίτηση για την εγκαθίδρυση ια σύνδεσης, εκτελεί
ια λειτουργία για να ελέγξει αν πορεί να δεχτεί την σύνδεση ή όχι. Η λειτουργία αυτή
ονο άζεται Connection Admission Control (CAC), Έλεγχος Αποδοχής Σύνδεσης. Αν
τελικώς η αίτηση γίνει αποδεκτή, τότε αυτή προωθείται στο τερ ατικό. Αν ό ως η
αίτηση δεν πορεί να γίνει αποδεκτή, τότε ο προηγού ενος εταγωγέας πορεί
εναλλακτικά να προωθήσει την αίτηση έσω άλλου δρό ου προς το τερ ατικό-
προορισ ό. Όταν η αίτηση φτάσει τελικά στον εταγωγέα που είναι συνδεδε ένος ε το
τερ ατικό-προορισ ός τότε η αίτηση αυτή προωθείται στο τερ ατικό έσω UNI
ση ατοδοσίας.
Μόλις εγκαθιδρυθεί ια σύνδεση που χαρακτηρίζεται από κάποιες παρα έτρους, το
δίκτυο και ο χρήστης “δη ιουργούν” ένα συ βόλαιο. Το δίκτυο εγγυάται τον τύπο και
την ποιότητα της υπηρεσίας που συ φωνήθηκε, εφόσον η κυκλοφορία ακολουθεί το
πρότυπο που περιγράφεται στο “συ βόλαιο”. Οι τρέχουσες εκδόσεις των πρωτοκόλλων
ση ατοδοσίας επιτρέπουν όνο την αρχική συ φωνία των παρα έτρων που
περιγράφουν την κυκλοφορία σε ια σύνδεση. εν επιτρέπουν δηλαδή, να γίνει κάποια
επαναδιαπραγ άτευση, ούτε και επαναπροσδιορισ ός των παρα έτρων αυτών.
Είναι ση αντικό να ην παρουσιαστεί παραβίαση των “συ βολαίων” που σχετίζονται
ε συνδέσεις άλλων τερ ατικών, λόγω της η τήρησης του “συ βολαίου” από κάποιο
τερ ατικό. Θα πρέπει να διασφαλιστεί ότι ένα τερ ατικό δεν στέλνει περισσότερη
κυκλοφορία από αυτή που του επιτρέπεται. Η λειτουργία που εκτελεί αυτή την
αστυνό ευση λέγεται Usage Parameter Control (UPC). Η συγκεκρι ένη λειτουργία
χρησι οποιεί τον Generic Cell Rate Algorithm (GCRA) ο οποίος πορεί να περιορίσει
την κυκλοφορία ιας σύνδεσης βάσει του “συ βολαίου”.
4.5 ΣτοίβαΠρωτοκόλλωντουATM
Η στοίβα πρωτοκόλλων του ATM φαίνεται στο Σχή α 4-3. Όπως παρατηρού ε από το
Σχή α, η στοίβα αυτή αποτελείται από τρία βασικά οριζόντια επίπεδα που σχετίζονται
ά εσα ε το ATM. Αυτά τα επίπεδα είναι το φυσικό επίπεδο (Physical Layer), το ATM
επίπεδο (ATM Layer), το επίπεδο προσαρ ογής ATM (ATM Adaptation Layer, ALL).
Πάνω από τα τρία αυτά επίπεδα βρίσκονται άλλα πρωτόκολλα, ανάλογα βέβαια και ε
το δίκτυο που θέλου ε να υλοποιήσου ε.
Asynchronous Transfer Mode
31
Κλάση
A
Κλάση
B
Κλάση
C
Κλάση
D
AAL
Ση ατοδοσίας
Ση ατοδοσία
AAL1 AAL2
AAL3/4 ή
AAL5
Επίπεδο ATM
Φυσικό επίπεδο
Επίπεδο
Ελέγχου
Επίπεδο διοίκησης
Επ
ίπεδο
χρήστη

Σχήα 4-3: Στοίβα πρωτοκόλλων του ATM
Πέρα ό ως από τρία αυτά οριζόντια επίπεδα παρατηρού ε ότι υπάρχουν τρία κάθετα
επίπεδα. Αυτά τα επίπεδα είναι το επίπεδο χρήστη (user plane), το επίπεδο ελέγχου
(control plane), το επίπεδο διαχείρισης (management plane). Το επίπεδο χρήστη
χρησι οποιείται για την ετάδοση της πληροφορίας που αφορά στον χρήστη, καθώς και
ε τον σχετιζό ενο ε την πληροφορία αυτή έλεγχο. Το επίπεδο ελέγχου υλοποιεί όλες