Δίκτυα Υπολογιστών Κεφάλαιο 28 – Πρωτόκολλα πραγματικού χρόνου: RSVP
Δημοσιεύτηκε από τον/την codebrakes στις
Δίκτυα Υπολογιστών
Κεφάλαιο 28 - Πρωτόκολλα πραγματικού χρόνου: RSVP
IntServ και RSVP
Όπως είδαμε κι από το προηγούμενο κεφάλαιο σε ένα δίκτυο που κάνει χρήση ποιότητας υπηρεσιών – QoS χρησιμοποιούνται δύο μοντέλα:
- Το DiffServ (Differentiated Services).
- Και το IntServ (Integrated Services).
Εν συντομία, όταν χρησιμοποιούμε το μοντέλο DiffServ εφαρμόζουμε ποιότητα υπηρεσιών από hop σε hop όπου γίνεται επίσης και χρήση του πεδίου ποιότητας υπηρεσιών της IP επικεφαλίδας (TOS/DSCP). Το μοντέλο IntServ είναι τελείως διαφορετικό από το DiffServ, σε αυτό οι διάφορες δικτυακές ροές δεδομένων στέλνουν αίτηση για εύρος ζώνης βάσει των δυνατοτήτων τους.
Σημαντική Παρατήρηση |
Μπορεί να φαίνεται αποτελεσματικός ο τρόπος με τον οποίο λειτουργεί το μοντέλο IntServ αλλά υπάρχει αρκετή δυσκολία στην επεκτασιμότητα του. Κάθε δρομολογητής οφείλει να καταγράφει κάθε δέσμευση πόρων για κάθε ροή δεδομένων. Υπάρχει πιθανότητα ένας δρομολογητής να μην υποστηρίζει το μοντέλο IntServ ή χάσει την δική του καταγραφή δέσμευσης πόρων.
Μέχρι τώρα το RSVP χρησιμοποιείται περισσότερο σε MPLS αρχιτεκτονικές. Για δυνατότητες ποιότητας υπηρεσιών - QoS χρησιμοποιείται περισσότερο το μοντέλο DiffServ. |
Δέσμευση πόρων στο RSVP
Ας πάρουμε ένα παράδειγμα όπου ένας host επιθυμεί να κάνει μια δέσμευση πόρων. Θα στείλει ένα μήνυμα αίτησης δέσμευσης πόρου RSVP χρησιμοποιώντας ένα RSVP path μήνυμα. Κατά την διαδρομή αυτού του μηνύματος στο ενδιάμεσο δίκτυο οι διάφοροι δρομολογητές όταν θα λάβουν αυτό το μήνυμα αν είναι σε θέση να εξασφαλίσουν το απαιτούμενο εύρος ζώνης όπως και χρόνο καθυστέρησης για την αντίστοιχη ροή δεδομένων, θα προωθήσουν αυτό το μήνυμα. Σε διαφορετική περίπτωση αυτό το μήνυμα θα απορριφθεί. Στην συνέχεια όταν αυτό φτάσει στον τελικό του προορισμό ο παραλήπτης αυτού του μηνύματος θα απαντήσει στο αποστολέα με ένα RSVP resv μήνυμα. Η ίδια διαδικασία θα συμβεί όταν το πακέτο μεταβεί στο ενδιάμεσο δίκτυο και περάσει από τους αντίστοιχους δρομολογητές. Κάθε δρομολογητής θα ελέγξει αν έχει αρκετό εύρος ζώνης όπως και δυνατότητα αναμονής γι’ αυτήν την ροή δεδομένων, κι αν ναι τότε θα προωθήσει το μήνυμα αυτό στην πηγή αίτησης δέσμευσης πόρων. Όταν ο host λάβει αυτό το μήνυμα δέσμευσης πόρων τότε η διαδικασία έχει ολοκληρωθεί.
Πρωτόκολλο δέσμευσης πόρων (Resource Reservation Protocol – RSVP)
Μια εφαρμογή λοιπόν που χρησιμοποιεί το μοντέλο IntServ (ενσωματωμένες υπηρεσίες) χρειάζεται να δεσμεύσει δικτυακούς πόρους. Στο μοντέλο IntServ η δέσμευση πορων αφορά μια και μόνο ροή δεδομένων. Είναι επίσης πρωτόκολλο σηματοδοσίας καθότι βοηθάει το πρωτόκολλο IP έτσι ώστε να δημιουργήσει μια ροή και συνεπώς να πραγματοποιηθεί η δέσμευση πόρων. Πρώτού όμως αναφερθούμε στο πως λειτουργεί το RSVP, οφείλουμε να αναφέρουμε ότι είναι ένα ανεξάρτητο ξεχωριστό πρωτόκολλο από το μοντέλο IntServ. Μπορεί δηλαδή να χρησιμοποιηθεί και σε άλλα μοντέλα στο μέλλον.
- Δέσμευση πόρων με βάση τον παραλήπτη (Receiver-Based Reservation): Στο RSVP οι παραλήπτες (κι όχι ο αποστολέας) πραγματοποιούν την δέσμευση πόρων. Αυτή η τεχνική είναι συμβατή με άλλα multicast πρωτόκολλα. Για παράδειγμα, σε πρωτόκολλα δρομολόγησης τα οποία χρησιμοποιούν τεχνικές multicast, συμβαίνει ακριβώς το ίδιο, δηλαδή οι παραλήπτες είναι σε θέση να αποφασίσουν για το αν θα συμμετάσχουν ή αποχωρήσουν από ένα multicast group.
- RSVP μηνύματα: Το RSVP έχει αρκετούς τύπους μηνυμάτων. Παρόλα αυτά εμείς θα επικεντρωθούμε σε δύο τύπους βασικών μηνυμάτων. Ο πρώτος τύπος είναι τα Path μηνύματα και ο δεύτερος τα Resv μηνύματα.
Τύποι RSVP μηνυμάτων
- Path Μηνύματα: Υπενθυμίζουν στους παραλήπτες μιας ροής δεδομένων ότι πρέπει να γίνει μια δέσμευση πόρων. Παρόλα αυτά οι παραλήπτες δεν είναι σε θέση να γνωρίζουν την διαδρομή από την οποία πέρασαν τα πακέτα πριν γίνει αυτή η δέσμευση. Η διαδρομή πρέπει να είναι γνωστή (ή να εγκαθιδρυθεί) για να γίνει η δέσμευση πόρων. Για να λυθεί αυτό το πρόβλημα το RSVP χρησιμοποιεί τα Path μηνύματα. Ένα Path μήνυμα δρομολογείται από τον αποστολέα, έπειτα στο ενδιάμεσο δίκτυο και τέλος προς τους παραλήπτες. Το Path μήνυμα κατά την διάρκεια της δρομολόγησης του καταγράφει όλες τις απαραίτητες πληροφορίες σχετικά με τους παραλήπτες. Όταν ένα Path μήνυμα σταλθεί σε ένα multicast δίκτυο τότε δημιουργείται ένα νέο μήνυμα όταν η διαδρομή αλλάξει.
- Resv Μηνύματα: Όταν ένας παραλήπτης έχει λάβει ένα Path μήνυμα τότε αυτός με την σειρά του στέλνει ένα Resv μήνυμα. Αυτό το Resv μήνυμα του παραλήπτη περνάει από το ενδιάμεσο δίκτυο προς τον αποστολέα (upstream) και πραγματοποιεί μια δέσμευση πόρων στους αντίστοιχους δρομολογητές που υποστηρίζουν το RSVP. Αν ένας δρομολογητής δεν υποστηρίζει το RSVP σε αυτήν την αντίστοιχη διαδρομή από την οποία περνάει το Resv μήνυμα του παραλήπτη τότε το προωθεί με την τεχνική βέλτιστης προσπάθειας (best-effort delivery).
Συγχώνευση δεσμεύσεων RSVP
Στο RSVP, οι πόροι δεν είναι δεσμευμένοι εξ αρχής για κάθε ροής δεδομένων. Στην δέσμευση αυτήν συμμετέχουν όλοι οι κόμβοι του δικτύου προσφέροντας ο καθένας κι από ένα κομμάτι. Στην παρακάτω εικόνα ο PC_4 ζητάει εύρος ζώνης 2 Mbps, ενώ ο PC_3 ζητάει εύρος ζώνης 1 Mbps. Ο router C (καθότι κι αυτός ζητάει εύρος ζώνης από το δίκτυο) οφείλει να ενώσει την δική του αίτηση μαζί με αυτήν του PC_3. Επειδή το μεγαλύτερο εύρος ζώνης το ζητάει ο PC_4 (εύρος ζώνης 2 Mbps) η δέσμευση λοιπόν θα γίνει για 2 Mbps. Το ίδιο ισχύει και για τον route
Εδώ δημιουργείται το ερώτημα γιατί o PC_3 και ο PC_4 που ανήκουν στην ίδια ροή απαιτούν διαφορετικό εύρος ζώνης ;;;
Σε ένα δίκτυο που υποστηρίζει πολυμεσικές υπηρεσίες, διαφορετικοί παραλήπτες μπορούν να διαχειριστούν διαφορετικούς τύπους ποιότητας υπηρεσιών. Για παράδειγμα ο PC_3 είναι σε θέση να λάβει ένα video με ταχύτητα εύρους ζώνης έως 1 Mbps (χαμηλή ποιότητα), ενώ ο PC_4 είναι σε θέση να λάβει το ίδιο video με ταχύτητα εύρους ζώνης στα 2 Mbps (υψηλότερη ποιότητα).
Τύποι δέσμευσης πόρων στο RSVP
Όταν υπάρχουν περισσότερες από μια ροές δεδομένων, ο δρομολογητής χρειάζεται να κάνει μια δέσμευση για να τις διευκολύνει. Στο RSVP έχουν οριστεί τρείς τύποι δέσμευσης πόρων όπως δείχνει το παρακάτω σχήμα.
- Wild Card Filter: Σε αυτόν τον τύπο, ο δρομολογητής δημιουργεί μια και μόνο μοναδική δέσμευση πόρων για όλους τους αποστολείς. Η δέσμευση αυτή βασίζεται στην μεγαλύτερη αίτηση. Αυτός ο τύπος χρησιμοποιείται όταν οι διάφορες ροές δεδομένων από διαφορετικούς αποστολείς δεν συμπέσουν την ίδια χρονική στιγμή.
- Fixed Filter: Σε αυτόν τον τύπο, ο δρομολογητής δημιουργεί μια ξεχωρισττή δέσμευση για κάθε ροή δεδομένων. Αυτό σημαίνει ότι αν υπάρχουν n ροές δεδομένων, τότε θα γίνουν n διαφορετικές δεσμεύσεις. Αυτός ο τύπος χρησιμοποιείται όταν υπάρχει μεγάλη πιθανότητα οι διάφορες ροές δεδομένων του κάθε αποστολέα του δικτύου να συμπέσουν την ίδια χρονική στιγμή.
- Shared Explicit: Σε αυτόν τον τύπο, ο δρομολογητής δημιουργεί μια δέσμευση πόρων η οποία μπορεί να διαμοιραστεί από ένα σύνολο ροών δεδομένων.
Σημαντική Παρατήρηση |
Η κατάσταση δέσμευσης που αποθηκεύεται σε κάθε κόμβο του δικτύου για κάθε ροή δεδομένων πρέπει να ανανεώνεται σε τακτά χρονικά διαστήματα. Αυτό αναφέρεται κι ως soft state σε αντίθεση με το hard state που χρησιμοποιείται σε πρωτόκολλα όπως το ATM ή το frame relay, όπου η πληροφορία για μια ροή δεδομένων πρέπει να διατηρείται έως ότου αυτή διαγραφτεί. Η ανανέωση αυτή πραγματοποιείται κάθε 30 δευτερόλεπτα. |
Τελευταία ενημέρωση: 29/04/2018