Архітектура інтегрованих послуг (стр. 2 из 4)
4. Коли кожен маршрутизатор, який підтримує RSVP, уздовж зворотнього шляху одержує повідомлення RESV, то він визначає прийнятність зазначених у запиті параметрів резервування як було описано вище з використанням процесів управління доступом і управління політикою. Якщо запит не може бути задоволений (через недолік ресурсів або помилки авторизації), маршрутизатор повертає повідомлення про помилку джерелу. Якщо запит приймається, то маршрутизатор посилає повідомлення RESV уверх наступному маршрутизаторові (у напрямку джерела). Прийом запиту резервування маршрутизатором означає також передачу параметрів QoS на відпрацьовування у відповідні блоки маршрутизатора. Конкретний спосіб відпрацьовування параметрів QoS маршрутизатором у протоколі RSVP не описується. Якщо технологія канального рівня, що обслуговує вихідний інтерфейс, не підтримує управління якістю обслуговування, то відпрацьовування виконується механізмом управління чергами, таким як WFQ або CQ. Якщо ж ця технологія підтримує QoS, то параметри специфікації RSpec відображаються на параметри QoS даної технології, наприклад, ATM.
5. Коли останній маршрутизатор одержує повідомлення RESV і приймає запит, то він посилає повідомлення-підтвердження назад вузлу-одержувачу (останній маршрутизатор розташований найближче до джерела, а для групових потоків — це точка об’єднання резервування). При виконанні групового резервування враховується той факт, що в точках розгалуження дерева доставки декілька потоків резервування зливаються в один. Якщо для всіх потоків запитується однакова пропускна здатність, то вона потрібна і для загального потоку. Якщо запитуються різні величини пропускної здатності, то для загального потоку обирається максимальна.
Після встановлення резервування джерело починає відправляти дані, що обслуговуються на всьому шляху до приймача (приймачів) із заданою якістю обслуговування.
Механізм RSVP-резервування схематично показаний на рис. 3.
Рисунок 3 – Механізм RSVP-резервування
Отже, RSVP-компоненти виконують такі функції.
• RSVP-джерело (RSVP sender) ініціює відправлення трафіка в RSVP-сеансі. RSVP- джерела передають параметри свого трафіка – специфікацію потоку даних відправника Sender_TSpec – проміжним маршрутизаторам і RSVP-одержувачеві. Специфікація Sender_TSpec є частиною об'єкта RSVP SENDER_TSPEC повідомлення PATH (див. нижче). Під час передавання RSVP-мережею зміст специфікації Sender_TSpec не змінюється;
• RSVP-одержувач (RSVP-receiver) одержує трафік у RSVP-сеансі. У процесі резервування ресурсів у відповідь на повідомлення PATH формує повідомлення, до якого включено об'єкт RSVP FLOWSPEC (див. нижче), що містить інформацію Receiver_TSpec і RSpec. Під час передавання RSVP-мережею зміст даних специфікацій може змінюватися в результаті злиття декількох RSVP-запитів або з інших причин.
Специфікація потоку даних Sender_TSpec або Receiver_TSpec містить у собі таку інформацію про трафік (RFC 2210): середню швидкість передачі даних, розмір «кошика маркерів» (узгоджений розмір сплеску), пікову швидкість (максимальний розмір сплеску), мінімальний і максимальний розміри пакетів. Специфікація RSpec містить вимоги щодо виділених ресурсів у термінах смуги пропускання і затримки.
Підтримка резервування. RSVP є протоколом гнучких станів (soft-state). Це означає, що потрібне періодичне оновлення резервування в мережі шляхом посилання додаткових повідомлень, чим власне протоколи даного типу відрізняються від hard-state протоколів, в яких запит посилається один раз і виконується доти, поки не буде явно скасований.
Для відновлення резервування усі компоненти, що беруть участь у резервуванні (RSVP-джерело, RSVP-одержувач, RSVP-сумісні маршрутизатори), періодично через кожні 30 с відсилають своїм сусідам повідомлення PATH (у прямому напрямку) і RESV (у зворотному напрямку). Якщо маршрутизатор відправляє чотири повідомлення PATH підряд і не одержує протягом цього часу жодного повідомлення RESV, резервування вважається втраченим і одержувачеві відправляється повідомлення про розрив з'єднання.
Скасування резервування. Резервування можна скасувати прямо або непрямо. Пряме скасування виконується з ініціативи RSVP-джерела або RSVP-одержувача за допомогою відповідних повідомлень протоколу RSVP (PATHTEAR уздовж шляху, яким передавалося повідомлення PATH, і RESVTEAR уздовж шляху, яким передавалося повідомлення RESV). Повідомлення RESVTEAR відправляється у відповідь на отримане PATHTEAR, що сигналізує про те, що RSVP-одержувач скасував резервування. Cisco IOS Software очікує від RSVP-джерела відсилання RSVP-одержувачеві підтвердження про одержання RESVTEAR – повідомлення RESVTEARCONF.
Непряме скасування відбувається за тайм-аутом: стан резервування має термін життя, і RSVP-компоненти мають періодично підтверджувати резервування. Якщо ж повідомлення-підтвердження перестають надходити, то резервування скасовується після закінчення його терміну життя.
Сигналізація помилок. Природно, в процесі поширення мережею або в процесі обробки RSVP-повідомлень іноді виникають помилки. Зазвичай це відбувається через порушення цілісності повідомлення. Для повідомлення RSVP-компонентів про виникнення помилок використовуються повідомлення PATHERR і RESVERR.
2.3 Повідомлення і пакети RSVP
У табл. 1 наведено типи повідомлень, які використовуються в RSVP. Документом RFC 2205 визначено сім типів повідомлень: PATH, RESV, PATHERR, RESVERR, PATHTEAR, RESVTEAR, RESVCONF. Повідомлення HELLO введене в RFC 3209 як розширення RSVP і призначене для підтримки встановленого резервування. Повідомлення RESVTEARCONF не описане в документах RFC, а є запатентованою компанією Cisco розробкою.
Таблиця 1 – Типи RSVP повідомлень
| Повідомлення | Функція | Напрямок | Адреса призначення |
| PATH | Використовується для ініціалізації встановлення і підтримки резервування | Униз (до одержувача) | Вузол-одержувач |
| RESV | Інформує про успішне проходження повідомлення PATH; резервує ресурси | Уверх (до джерела) | Наступний вузол |
| PATHERR | Посилається в напрямку джерела у випадку виявлення помилки в PATH (наприклад, коли розірване з'єднання або пакет PATH пошкоджений) | Уверх | Наступний вузол |
| RESVERR | Посилається в напрямку до кінцевого вузла, якщо в процесі обробки повідомлення RESV виявлена помилка | Униз | Наступний вузол |
| PATHTEAR | Посилається до кінцевого вузла для розриву існуючого резервування | Униз | Вузол-одержувач |
| RESVTEAR | Посилається в напрямку до вузла-джерела для розриву існуючого резервування | Уверх | Вузол- джерело |
| RESVCONF | Посилається у відповідь на повідомлення RESV або RESVTEAR для запиту підтвердження одержання повідомлення | Униз | Вузол-одержувач |
| RESVTEARCONF (Cisco) | Посилається в підтвердження на RESVTEAR | Униз | Вузол-одержувач |
| HELLO (RFC 3209) | Посилається сусіднім RSVP- вузлам з якими існує пряме з'єднання з метою підтримки встановленого з'єднання | Уверх / униз | Наступний вузол |
Повідомлення RSVP мають чіткий формат: кожне повідомлення RSVP обов'язково має заголовок (рис. 4) і наступний за ним один або кілька об'єктів. У табл. 2 описані поля заголовка RSVP-повідомлення.
Рисунок 4 – Загальний формат заголовка RSVP
Таблиця 2 – Пояснення полів заголовка RSVP
| Поле | Опис |
| Версія (Version) | Версія протоколу RSVP. Поточна версія 1. |
| Прапорці (Flags) | Прапорці не визначені |
| Тип повідомлення (Message Type) | 1=повідомлення PATH2= повідомлення RESV3= повідомлення PATHERR4= повідомлення RESVERR5= повідомлення PATHTEAR6= повідомлення RESVTEAR7= повідомлення RESVCONF10= повідомлення RESVTEARCONF20= повідомлення HELLO |
| RSVP Checksum | Контрольна сума в RSVP-повідомленні |
| TTL передачі | Вказує на те, з яким значенням позначки часу життя (TTL) відправлений даний IP пакет |
| Зарезервоване (Reserved) | Не використовується |
| Довжина (RSVP Length) | Довжина RSVP повідомлення в байтах, включаючи заголовок. Мінімальна довжина 8 байт |
Що стосується об'єктів, які розміщуються після заголовка, то їхня кількість і типи залежать від призначення повідомлення. Різними документами RFC визначено 23 класи об'єктів RSVP. Всі об'єкти мають однаковий формат (RFC 2205), що складається з заголовка (32 біта) і змісту об'єкта (рис. 5). У відповідності зі стандартним форматом у заголовку кожного об'єкта вказується його загальна довжина в байтах (величина обов'язково кратна чотирьом); номер класу об'єкта (кожен клас об'єктів має як свою назву, так і номер); С-тип (тип об'єкта, унікальний у рамках одного класу). Номер класу і С-тип використовуються разом як 16-бітовий ідентифікатор унікального типу для кожного об'єкта. Об'єкт несе в собі різну інформацію, наприклад, про стиль резервування ресурсів (клас STYLE), специфікацію потоку даних, переданих джерелом (клас Sender_TSpec), специфікацію потоку даних і вимог до ресурсів, запитуваних одержувачем (клас Flowspec, RFC 2210). Об'єкт розміщується в повідомленні з урахуванням його типу, наприклад, об'єкт класу Sender_TSpec розміщається тільки в PATH-повідомленнях, об'єкт класу Flowspec тільки в повідомленнях RESV, RESVERR, RESVTEAR, RESVCONF, RESVTEARCONF.