Архiтектура iнтегрованих послуг

АРХРЖТЕКТУРА РЖНТЕГРОВАНИХ ПОСЛУГ

1. Модель IntServ

Архiтектура iнтегрованих послуг IntServ з'явилася у 1994 роцi, ранiше за DiffServ, у вiдповiдь на необхiднiсть у модифiкацii iнфрастуктури Internet. Метою цiii архiтектури i пiдтримка QoS, у першу чергу для аплiкацiй реального часу, яка б забезпечувала управлiння мiжкiнцевою затримкою пакета, а також управлiння розподiлом смуги мiж потоками трафiка. Термiн Влiнтегрованi послугиВ» вiдповiдно до специфiкацii RFC 1633 мiстить у собi iснуючу ранiше доставку best effort, а також додаi доставку потокiв трафiка реального часу з гарантованою затримкою i доставку пакетiв з гарантованою швидкiстю.

Головна iдея (постулат) моделi IntServ полягаi в тому, що ресурсами, у тому числi смугою, можна явно управляти з метою задоволення вимог потокiв трафiка. Другий момент (постулат) тАУ забезпечення твердих гарантiй щодо якостi обслуговування неможливе без резервування ресурсiв, де пiд резервуванням ресурсiв розумiiться вiдображення QoS-вимог потокiв на стан (конфiгурацiю) маршрутизаторiв.

Основними функцiональними блоками моделi IntServ i резервування ресурсiв (resource reservation) i управлiння доступом (admission control). У рамках архiтектури IntServ зроблено акцент на процесi сигналiзацii, за допомогою якого iндивiдуальнi потоки повiдомляють про своi вимоги щодо обсягу смуги, який потрiбно зарезервувати, i припустимоi величини затримки. Як протокол сигналiзацii в моделi IntServ передбачаiться використання протоколу резервування ресурсiв RSVP (RFC 2205 тАУ 2215).

Процесовi резервування передуi процес управлiння доступом, що на пiдставi аналiзу доступних мережних ресурсiв приймаi рiшення про прийняття потоку до обслуговування (якщо ресурсiв досить) або вiдхилення запиту (за нестачi ресурсiв). Обов'язковою умовою прийняття запиту до обслуговування i непогiршення якостi обслуговування ранiше прийнятих запитiв. Функцiя управлiння доступом покладаiться на COPS-сервер.

Отже, ключовим поняттям у IntServ i резервування ресурсiв. Коли мова йде про резервування смуги для потоку трафiка, то це означаi таку конфiгурацiю механiзму обслуговування черг, що при обслуговуваннi черги з даним потоком йому надаiться така смуга, яка запитуiться. Коли мова йде про забезпечення припустимоi величини затримки, то тут все трохи складнiше. Наприклад, IOS Cisco забезпечуi низьку затримку шляхом резервування мiсця в черзi. Взагалi в концепцii IntServ з (RFC 1633) не обумовлюiться спосiб забезпечення резервування ресурсiв, залишаючи це питання розробникам обладнання.

Реалiзацiя моделi IntServ згiдно з RFC 1633 вимагаi наявностi в маршрутизаторi таких функцiональних блокiв (рис. 1 ):

- класифiкацiя (iдентифiкацiя) потокiв даних з метою визначення iхньоi належностi певному класу обслуговування;

- механiзм обслуговування черги, а також механiзми визначення перевантаження i вiдкидання пакетiв з низьким рiвнем прiоритетного обслуговування;

- управлiння доступом до ресурсiв мережi з метою визначення можливостi обслуговування запиту з заданим рiвнем QoS на пiдставi аналiзу наявностi необхiдного обсягу ресурсiв;

- механiзм резервування ресурсiв.

Рисунок 1 тАУ Компоненти моделi IntServ, реалiзованi в маршрутизаторi

Функцii управлiння доступом, класифiкацii i планувальника можуть бути об'iднанi в блок управлiння трафiком (traffic control), головна задача якого полягаi в створеннi рiзницi щодо якостi обслуговування.

Модель IntServ маi своi переваги та недолiки. Головною перевагою даноi моделi i забезпечення твердих гарантiй щодо якостi обслуговування: аплiкацiя отримуi той обсяг ресурсiв, який iй необхiдний, не менше i не бiльше. Крiм того, це сприяi ефективному використанню ресурсiв мережi. Однак моделi IntServ властивi серйознi недолiки, завдяки яким вона не одержала широкого поширення на практицi. Перший i найголовнiший недолiк полягаi в низькiй масштабованостi, що пов'язано iз обслуговуванням кожного потоку окремо. Нагадаiмо, що для кожного окремого потоку необхiдно не тiльки зарезервувати ресурси, а також пiдтримувати це резервування, крiм того, на кожному маршрутизаторi уздовж шляху доставки необхiдно зберiгати iнформацiю про стан потоку.

Другий недолiк пов'язаний iз утратою якостi обслуговування при проходженнi через дiлянку мережi, у якiй не пiдтримуiться IntServ. Тут вiдбуваiться або передача з якiстю best effort, або вiдображення запиту на класи DiffServ (DSCP) при проходженнi через DiffServ-домен.

iнтегрований intserv протокол

2. Протокол сигналiзацii RSVP

2.1 Призначення протоколу RSVP

ReSerVation Protocol (RSVP) тАУ стандартизований протокол, призначений для динамiчного настроювання наскрiзного QoS у рамках гетерогенноi мережi. RSVP дозволяi аплiкацiям посилати в мережу сигнали про своi QoS-вимоги для кожного потоку i динамiчно резервувати необхiдну для них смугу пропускання. Можна дати таке визначення RSVP тАУ це протокол сигналiзацii, що забезпечуi резервування ресурсiв i управлiння ними з метою надання iнтегрованих сервiсiв, призначених для емуляцii видiлених каналiв у IP-мережах.

RSVP працюi на рiвнi протоколу IP i маi свiй власний тип протоколу тАУ 46, хоча можлива iнкапсуляцiя повiдомлень RSVP у датаграми UDP. Для такоi iнкапсуляцii використовуються UDP-порти 1698 i 1699.

Спочатку протокол RSVP розроблявся для мультимедiйного трафiка (аудiо- та вiдео-), орiiнтуючись на групове мовлення. Однак RSVP успiшно застосовуiться для резервування ресурсiв для односпрямованого трафiка, наприклад, трафiка мережноi файловоi системи (Network File System, NFS) i управляючого трафiка вiртуальних приватних мереж (Virtual Private Network, VPN).

Протокол RSVP сигналiзуi про запити резервування ресурсiв доступним шляхом в мережi, який маршрутизуiться. При цьому RSVP не виконуi власну маршрутизацiю, а використовуi для цього iншi протоколи маршрутизацii. Подiбна модульнiсть допомагаi протоколу RSVP ефективно функцiонувати разом з будь-якою службою надання iнформацii про маршрути. RSVP забезпечуi явну передачу повiдомлень для управлiння трафiком, полiтиками i легко працюi в непiдтримуваних оточеннях.

2.2 Принципи функцiонування протоколу RSVP

Функцiонування RSVP пов'язане з виконанням таких задач:

- резервування ресурсiв i пiдтримка резервування;

- звiльнення зарезервованих ресурсiв;

- сигналiзацiя про помилки.

Резервування ресурсiв здiйснюiться шляхом посилання в мережу RSVP-запитiв вiд iменi потоку даних, в яких закладено iнформацiю про необхiдний рiвень QoS. RSVP-запити передаються уздовж заздалегiдь розрахованого маршруту i на кожному iз пройдених вузлiв (маршрутизаторiв) здiйснюiться спроба зарезервувати необхiднi ресурси. Для цього в кожному з маршрутизаторiв мережi необхiдна реалiзацiя RSVP-агентiв, взаiмодiя яких з iншими функцiональними блоками вiдображена на рис. 2 (RFC 2205).

Рисунок 2 тАУ Агенти RSVP на маршрутизаторах мережi

Перед тим як зарезервувати ресурси, RSVP-демон (RSVPD) маршрутизатора з'iднуiться з двома локальними модулями прийняття рiшення тАУ модулем управлiння доступом (admission control) i модулем управлiння полiтикою (policy control). Модуль управлiння доступом визначаi, чи маi вузол досить вiльних ресурсiв для забезпечення вiдповiдного рiвня QoS. Модуль управлiння полiтикою визначаi, чи i в користувача адмiнiстраторськi права, для того, щоб зробити резервування. Якщо яка-небудь з перевiрок не пройшла, RSVP-демон вiдправляi повiдомлення про помилку процесовi аплiкацii, який надiслав запит. Якщо обидвi перевiрки пройшли нормально, RSVP-демон установлюi параметри класифiкатора пакетiв (packet classifier) i планувальника пакетiв (packet scheduler) для надання потрiбного рiвня QoS. Класифiкатор пакетiв визначаi клас QoS для кожного пакета, а планувальник пакетiв управляi передачею пакетiв, базуючись на iхньому класi QoS. На рiвнi планувальника передбачаiться використання алгоритмiв WFQ або СQ i алгоритму WRED.

Пiд час процесу прийняття рiшення модулем управлiння доступом резервування необхiдноi смуги пропускання виконуiться тiльки в тому випадку, якщо для запитуваного класу трафiка маються вiльнi ресурси в достатнiй кiлькостi. У протилежному випадку запит на доступ вiдхиляiться, але трафiк передаiться з якiстю обслуговування, визначеною за замовчуванням для даного класу трафiка. У багатьох випадках, навiть якщо запит на доступ вiдхилений на одному або декiлькох маршрутизаторах, модуль усе ще може реалiзувати прийнятну якiсть обслуговування, встановивши резервування на перевантажених маршрутизаторах. Це можливо через те, що iншi потоки даних можуть не цiлком використовувати замовлену ними смугу пропускання.

Резервування завжди маi здiйснюватися тим самим одноадресним шляхом (маршрутом) або багатоадресним деревом. У випадку виходу з ладу лiнii зв'язку маршрутизатор маi сповiстити про це RSVP-демона, щоб його RSVP-повiдомлення передавалися новим шляхом.

Процес встановлення резервування складаiться з п'яти окремих крокiв.

1. Джерело даних посилаi за унiкальною або груповою адресою одержувача спецiальне повiдомлення PATH, у якому воно вказуi параметри свого трафiка тАУ специфiкацiю потоку даних вiдправника (Sender_TSpec). Повiдомлення PATH передаiться маршрутизаторами мережi у напрямку вiд джерела (або джерел) з використанням таблиць маршрутизацii, якi отриманi за допомогою будь-якого протоколу маршрутизацii.

2. Кожен RSVP-маршрутизатор перехоплюi РАТН-повiдомлення, зберiгаi IP-адресу попередньоi точки призначення, записуi замiсть нього свою власну адресу i вiдправляi оновлене повiдомлення далi тим же шляхом, яким передаються данi. Тим самим у мережi утвориться фiксований маршрут передачi повiдомлень у рамках сесii RSVP.

3. Пiсля одержання повiдомлення РАТН приймач вiдправляi маршрутизаторовi, вiд якого вiн одержав це повiдомлення, запит резервування ресурсiв тАФ повiдомлення RESV (reservation request). До повiдомлення RESV крiм iнформацii Receiver_TSpec (специфiкацiя потоку даних) включаiться специфiкацiя запиту (RSpec), в якiй указуються необхiднi приймачевi параметри якостi обслуговування, i специфiкацiя фiльтра (FilterSpec), що визначаi, до яких пакетiв сесii застосовуiться дане резервування (наприклад, за типом транспортного протоколу i номером порту). Разом RSpec i FilterSpec складають дескриптор потоку, який маршрутизатор використовуi для iдентифiкацii кожного резервування ресурсiв (RFC 2205). Фiльтр може визначити потiк пакетiв з будь-яким ступенем деталiзацii i на пiдставi будь-якоi iнформацii, у тому числi i прикладному рiвнi. Запитуванi параметри QoS у специфiкацii RSpec можуть вiдрiзнятися вiд зазначених у специфiкацii TSpec.

4. Коли кожен маршрутизатор, який пiдтримуi RSVP, уздовж зворотнього шляху одержуi повiдомлення RESV, то вiн визначаi прийнятнiсть зазначених у запитi параметрiв резервування як було описано вище з використанням процесiв управлiння доступом i управлiння полiтикою. Якщо запит не може бути задоволений (через недолiк ресурсiв або помилки авторизацii), маршрутизатор повертаi повiдомлення про помилку джерелу. Якщо запит приймаiться, то маршрутизатор посилаi повiдомлення RESV уверх наступному маршрутизаторовi (у напрямку джерела). Прийом запиту резервування маршрутизатором означаi також передачу параметрiв QoS на вiдпрацьовування у вiдповiднi блоки маршрутизатора. Конкретний спосiб вiдпрацьовування параметрiв QoS маршрутизатором у протоколi RSVP не описуiться. Якщо технологiя канального рiвня, що обслуговуi вихiдний iнтерфейс, не пiдтримуi управлiння якiстю обслуговування, то вiдпрацьовування виконуiться механiзмом управлiння чергами, таким як WFQ або CQ. Якщо ж ця технологiя пiдтримуi QoS, то параметри специфiкацii RSpec вiдображаються на параметри QoS даноi технологii, наприклад, ATM.

5. Коли останнiй маршрутизатор одержуi повiдомлення RESV i приймаi запит, то вiн посилаi повiдомлення-пiдтвердження назад вузлу-одержувачу (останнiй маршрутизатор розташований найближче до джерела, а для групових потокiв тАФ це точка обтАЩiднання резервування). При виконаннi групового резервування враховуiться той факт, що в точках розгалуження дерева доставки декiлька потокiв резервування зливаються в один. Якщо для всiх потокiв запитуiться однакова пропускна здатнiсть, то вона потрiбна i для загального потоку. Якщо запитуються рiзнi величини пропускноi здатностi, то для загального потоку обираiться максимальна.

Пiсля встановлення резервування джерело починаi вiдправляти данi, що обслуговуються на всьому шляху до приймача (приймачiв) iз заданою якiстю обслуговування.

Механiзм RSVP-резервування схематично показаний на рис. 3.

Рисунок 3 тАУ Механiзм RSVP-резервування

Отже, RSVP-компоненти виконують такi функцii.

тАв RSVP-джерело (RSVP sender) iнiцiюi вiдправлення трафiка в RSVP-сеансi. RSVP- джерела передають параметри свого трафiка тАУ специфiкацiю потоку даних вiдправника Sender_TSpec тАУ промiжним маршрутизаторам i RSVP-одержувачевi. Специфiкацiя Sender_TSpec i частиною об'iкта RSVP SENDER_TSPEC повiдомлення PATH (див. нижче). Пiд час передавання RSVP-мережею змiст специфiкацii Sender_TSpec не змiнюiться;

тАв RSVP-одержувач (RSVP-receiver) одержуi трафiк у RSVP-сеансi. У процесi резервування ресурсiв у вiдповiдь на повiдомлення PATH формуi повiдомлення, до якого включено об'iкт RSVP FLOWSPEC (див. нижче), що мiстить iнформацiю Receiver_TSpec i RSpec. Пiд час передавання RSVP-мережею змiст даних специфiкацiй може змiнюватися в результатi злиття декiлькох RSVP-запитiв або з iнших причин.

Специфiкацiя потоку даних Sender_TSpec або Receiver_TSpec мiстить у собi таку iнформацiю про трафiк (RFC 2210): середню швидкiсть передачi даних, розмiр Влкошика маркерiвВ» (узгоджений розмiр сплеску), пiкову швидкiсть (максимальний розмiр сплеску), мiнiмальний i максимальний розмiри пакетiв. Специфiкацiя RSpec мiстить вимоги щодо видiлених ресурсiв у термiнах смуги пропускання i затримки.

Пiдтримка резервування. RSVP i протоколом гнучких станiв (soft-state). Це означаi, що потрiбне перiодичне оновлення резервування в мережi шляхом посилання додаткових повiдомлень, чим власне протоколи даного типу вiдрiзняються вiд hard-state протоколiв, в яких запит посилаiться один раз i виконуiться доти, поки не буде явно скасований.

Для вiдновлення резервування усi компоненти, що беруть участь у резервуваннi (RSVP-джерело, RSVP-одержувач, RSVP-сумiснi маршрутизатори), перiодично через кожнi 30 с вiдсилають своiм сусiдам повiдомлення PATH (у прямому напрямку) i RESV (у зворотному напрямку). Якщо маршрутизатор вiдправляi чотири повiдомлення PATH пiдряд i не одержуi протягом цього часу жодного повiдомлення RESV, резервування вважаiться втраченим i одержувачевi вiдправляiться повiдомлення про розрив з'iднання.

Скасування резервування.
Резервування можна скасувати прямо або непрямо. Пряме скасування виконуiться з iнiцiативи RSVP-джерела або RSVP-одержувача за допомогою вiдповiдних повiдомлень протоколу RSVP (PATHTEAR уздовж шляху, яким передавалося повiдомлення PATH, i RESVTEAR уздовж шляху, яким передавалося повiдомлення RESV). Повiдомлення RESVTEAR вiдправляiться у вiдповiдь на отримане PATHTEAR, що сигналiзуi про те, що RSVP-одержувач скасував резервування. Cisco IOS Software очiкуi вiд RSVP-джерела вiдсилання RSVP-одержувачевi пiдтвердження про одержання RESVTEAR тАУ повiдомлення RESVTEARCONF.

Непряме скасування вiдбуваiться за тайм-аутом: стан резервування маi термiн життя, i RSVP-компоненти мають перiодично пiдтверджувати резервування. Якщо ж повiдомлення-пiдтвердження перестають надходити, то резервування скасовуiться пiсля закiнчення його термiну життя.

Сигналiзацiя помилок. Природно, в процесi поширення мережею або в процесi обробки RSVP-повiдомлень iнодi виникають помилки. Зазвичай це вiдбуваiться через порушення цiлiсностi повiдомлення. Для повiдомлення RSVP-компонентiв про виникнення помилок використовуються повiдомлення PATHERR i RESVERR.

2.3 Повiдомлення i пакети RSVP

У табл. 1 наведено типи повiдомлень, якi використовуються в RSVP. Документом RFC 2205 визначено сiм типiв повiдомлень: PATH, RESV, PATHERR, RESVERR, PATHTEAR, RESVTEAR, RESVCONF. Повiдомлення HELLO введене в RFC 3209 як розширення RSVP i призначене для пiдтримки встановленого резервування. Повiдомлення RESVTEARCONF не описане в документах RFC, а i запатентованою компанiiю Cisco розробкою.

Таблиця 1 тАУ Типи RSVP повiдомлень

Повiдомлення	Функцiя	Напрямок	Адреса призначення
PATH	Використовуiться для iнiцiалiзацii встановлення i пiдтримки резервування	Униз (до одержувача)	Вузол-одержувач
RESV	РЖнформуi про успiшне проходження повiдомлення PATH; резервуi ресурси	Уверх (до джерела)	Наступний вузол
PATHERR	Посилаiться в напрямку джерела у випадку виявлення помилки в PATH (наприклад, коли розiрване з'iднання або пакет PATH пошкоджений)	Уверх	Наступний вузол
RESVERR	Посилаiться в напрямку до кiнцевого вузла, якщо в процесi обробки повiдомлення RESV виявлена помилка	Униз	Наступний вузол
PATHTEAR	Посилаiться до кiнцевого вузла для розриву iснуючого резервування	Униз	Вузол-одержувач
RESVTEAR	Посилаiться в напрямку до вузла-джерела для розриву iснуючого резервування	Уверх	Вузол- джерело
RESVCONF	Посилаiться у вiдповiдь на повiдомлення RESV або RESVTEAR для запиту пiдтвердження одержання повiдомлення	Униз	Вузол-одержувач
RESVTEARCONF (Cisco)	Посилаiться в пiдтвердження на RESVTEAR	Униз	Вузол-одержувач
HELLO (RFC 3209)	Посилаiться сусiднiм RSVP- вузлам з якими iснуi пряме з'iднання з метою пiдтримки встановленого з'iднання	Уверх / униз	Наступний вузол

Вместе с этим смотрят:

GPS-навигация

IP-телефония. Особенности цифровой офисной связи

РЖсторiя диктофону

РЖсторiя звтАЩязку та його розвиток

Автоматика, телемеханика и связь