Протоколи АТМ
АТМ - єдина мережева технологія, що спочатку розроблялася для підтримки звичайного трафіку TCP і UDP разом з трафіком реального часу. Проте орієнтація на АТМ означає або створення нової мережевої інфраструктури для трафіку реального часу, або заміну наявній конфігурації на базі IP, причому обидві альтернативи обійдуться недешево.
ПРОТОКОЛИ
Потреба в підтримці декількох типів трафіку з різними вимогами до якості послуг в рамках архітектури TCP/IP вельми актуальна. Цю задачу покликані вирішити два ключові інструменти: транспортний протокол реального часу (Real-Time Transport Protocol, RTP) і протокол резервування ресурсів (Resource Reservation Protocol, RSVP).
RTP гарантує доставку даних одному або більш адресатам із затримкою в заданих межах. Це означає, що дані можуть бути відтворені в реальному часі. RSVP дозволяє кінцевим системам резервувати мережеві ресурси для отримання необхідної якості послуг, особливо ресурси для трафіку реального часу по протоколу RTP.
Найбільш широко використовуваний протокол транспортного рівня - це TCP. Не дивлячись на те що TCP дозволяє підтримувати безліч різноманітних розподілених застосувань, він не підходить для додатків реального часу.
У додатках реального часу відправник генерує потік даних з постійною швидкістю, а одержувач(-і) повинен надавати ці дані додатку з тією ж самою швидкістю. Такі застосування включають аудіо- і відеоконференції, розповсюдження живого відео (для негайного відтворення), робочі області, що розділяються, видалену діагностику в медицині, комп'ютерну телефонію, розподілене інтерактивне моделювання, ігри і моніторинг в реальному часі.
Використання TCP як транспортний протокол для цих застосувань неможливе з кількох причин. По-перше, цей протокол дозволяє встановити з'єднання тільки між двома кінцевими крапками, отже, він не підходить для багатоадресної передачі. Він передбачає повторну передачу втрачених сегментів, що прибувають, коли додаток реального часу вже їх не чекає. Крім того, у TCP немає зручного механізму прив'язки інформації про синхронізацію до сегментів - інша вимога додатків реального часу.
Інший широко використовуваний протокол транспортного рівня UDP не має перших двох обмежень (з'єднання точка-точка і передача втрачених сегментів), але і він не надає критичної інформації про синхронізацію. Таким чином, UDP не надає сам по собі яких-небудь інструментів загального призначення для додатків реального часу. Не дивлячись на те що кожен додаток реального часу може мати свої власні механізми для підтримки передачі в реальному часі, вони мають багато загальних рис, а це робить визначення єдиного протоколу вельми бажаним. Стандартний протокол такого роду - RTP, визначений в RFC1889.
У типовому середовищі реального часу відправник генерує пакети з постійною швидкістю. Вони відправляються їм через однакові інтервали часу, проходять через мережу і приймаються одержувачем, відтворюючим дані в реальному часі після їх отримання.
Проте зважаючи на варіацію затримки при передачі пакетів по мережі вони прибувають через нерегулярні інтервали часу. Для компенсації цього ефекту пакети, що поступають, буферизуються, дотримуються на деякий час і потім надаються з постійною швидкістю програмному забезпеченню, що генерує вивід. Щоб така схема працювала, кожен пакет отримує відмітку про час - таким чином одержувач може відтворити дані, що поступають, з тією ж швидкістю, що і відправник.
RTP підтримує передачу даних в реальному часі між декількома учасниками сеансу. (Сеанс - це логічний зв'язок між двома і більш користувачами RTP, підтримувана протягом всього часу передачі даних. Процес відкриття сеансу виходить за рамки RTP.).
Хоча RTP може використовуватися і для одноадресної передачі в реальному часі, його сила в підтримці багатоадресної передачі. Для цього кожен блок даних RTP містить ідентифікатор відправника, що вказує, хто з учасників генерує дані. Блоки даних RTP містять також відмітку про час, щоб дані могли бути відтворені з правильними інтервалами приймаючою стороною.
Крім того, RTP визначає формат корисного навантаження передаваних даних. З цим безпосередньо пов'язана концепція синхронізації, за яку частково відповідає мікшер - механізм трансляції RTP. Приймаючи потоки пакетів RTP від одного або більш за джерела, він комбінує їх і посилає новий потік пакетів RTP одному або більш одержувачам. Мікшер може просто комбінувати дані, а також змінювати їх формат.
Приклад додатку для мікшера - комбінування декількох джерел звуку. Наприклад, припустимо, що частина систем даного аудіосеансу генерує кожна свій власний потік RTP. Велику частину часу тільки один джерело активне, хоча час від часу одночасно "говорять" декілька джерел.
Якщо нова система хоче взяти участь в сеансі, але її канал до мережі не має достатньої ємкості для підтримки всіх потоків RTP, то мікшер отримує всі ці потоки, об'єднує їх в один і передає останній новому членові сеансу. При отриманні декількох потоків мікшер просто складає значення імпульсно-кодової модуляції. Заголовок RTP, що генерується мікшером, включає ідентифікатор(-и) відправника(-ів), чиї дані присутні в пакеті.
Простіший пристрій створює один витікаючий пакет RTP для кожного пакету RTP, що поступає. Цей механізм, званий транслятором, може змінити формат даних в пакеті або використовувати інший комплект низькорівневих протоколів для передачі даних з одного домена в іншій. Наприклад, потенційний одержувач може опинитися не в змозі обробляти високошвидкісний відеосигнал, використовуваний іншими учасниками сеансу. Транслятор конвертує відео у формат нижчої якості, що вимагає не такої високої швидкості передачі даних.
Протокол RTP використовується тільки для передачі призначених для користувача даних - зазвичай багатоадресною - всім учасникам сеансу. Окремий протокол управління передачею в реальному часі працює з декількома адресатами для забезпечення зворотного зв'язку з відправниками даних RTP і іншими учасниками сеансу.
RTCP використовує той же самий базовий транспортний протокол, що і RTP (зазвичай UDP), але інший номер порту. Кожен учасник сеансу періодично посилає RTCP-пакет решті всіх учасників сеансу. RFC 1889 описує три функції, виконувані RTCP: Забезпечення якості послуг і зворотного зв'язку у разі перевантаження. Повідомлення відправника дозволяють одержувачам оцінити швидкість даних і якість передачі. Повідомлення одержувачів містять інформацію про проблеми, з якими вони стикаються, включаючи втрату пакетів і надмірну нерівномірність передачі. Аналізуючи повідомлення всіх учасників сеансу, адміністратор мережі може визначити, торкається дана проблема одного учасника або носить загальний характер. Ідентифікація відправника.
Пакети RTCP надають більше інформації про відправника пакетів даних, ніж випадковим чином вибраний ідентифікатор джерела синхронізації. Крім того, вони допомагають користувачеві ідентифікувати потоки, що відносяться до різних сеансів.оцінка розмірів сеансу і мастшабування.
Для забезпечення якості послуг і зворотного зв'язку з метою управління завантаженістю, а також з метою ідентифікації відправника, всі учасники періодично посилають пакети RTCP. Частота передачі цих пакетів знижується із зростанням числа учасників. RFC 1889 описує алгоритм, згідно якому учасники обмежують частоту RTCP-пакетів залежно від загального числа учасників. Мета полягає в тому, щоб трафік RTCP не перевищував 5% від загального трафіку сеансу. Призначення будь-якої мережі полягає в доставці даних одержувачем з гарантованою якістю послуг, що включають пропускну спроможність, затримку і допустиму межу варіації затримки. Із зростанням числа користувачів і додатків забезпечити якість послуг стає все важчим. Необхідний інструмент, за допомогою якого перевантажень можна було б уникнути взагалі, тобто зробити так, щоб додатки могли резервувати мережеві ресурси відповідно до необхідної якості послуг.
Розв'язання проблеми в даному випадку полягає в резервуванні одноадресними додатками ресурсів для забезпечення необхідного рівня послуг. Тоді маршрутизатори на передбачуваному шляху виділяють ресурси, наприклад місце в черги і частину ємкості витікаючої лінії. Якщо маршрутизатор не має можливості виділити ресурси унаслідок раніше узятих на себе зобов'язань, то він сповіщає про це додаток. В цьому випадку додаток може спробувати ініціювати інший сеанс з меншими вимогами до якості послуг або перенести його на пізніший термін.
Багатоадресна розсилка ставить набагато складніші завдання по резервуванню ресурсів. Вона веде до генерації величезних об'ємів мережевого трафіку у випадку, наприклад, таких застосувань, як відео, або великої і розосередженої групи одержувачів. Проте трафік від джерела багатоадресної розсилки може бути в принципі значно понижений.
Для цього є дві підстави. По-перше, деякі члени групи можуть не потребувати доставки даних від конкретного джерела в певний період часу. Наприклад, члени однієї групи можуть отримувати інформацію одночасно по двох каналах (від двох джерел), але при цьому одержувач може бути зацікавлений в прийомі тільки одного каналу.
Багатоадресний трафік можна понизити і унаслідок того, що деякі члени групи в змозі обробляти тільки частину передаваної відправником інформації. Резервування ресурсів дозволяє маршрутизаторам заздалегідь визначити, чи в змозі вони здійснити доставку багатоадресного трафіку всім одержувачам.
У попередніх спробах реалізації резервування ресурсів і в прийнятих в frame relay і АТМ підходах необхідні ресурси запрошує джерело потоку даних. Цей метод достатній у разі одноадресної передачі, тому що передавальне застосування передає дані в певному темпі, а необхідні рівень якості послуг закладений в схему передачі.
Проте такий підхід не можна використовувати для багатоадресної розсилки. У різних членів групи можуть бути неоднакові вимоги до ресурсів. Якщо початковий потік може бути роздільний на підпотоки, то деякі члени групи, цілком можливо, побажають отримувати тільки один з них. Наприклад, якщо декілька відправників віщають на одну групу, то одержувач може вибрати тільки одного відправника або деяку їх підмножину. Нарешті, вимоги різних одержувачів до якості послуг можуть мінятися залежно від устаткування виводу, потужності процесора і швидкості каналу.
З цієї причини резервування ресурсів одержувачем представляється переважним. Відправники можуть надати маршрутизаторам загальні характеристики трафіку (наприклад, темп передачі даних), але одержувачі винні самі визначити необхідний рівень якості послуг. Маршрутизатори зводять потім воєдино запити на виділення ресурсів на загальних ділянках дерева розповсюдження.
У основі RSVP лежать три концепції, що стосуються потоків даних: сеанс, специфікація потоку і специфікація фільтру. Сеанс - це потік даних, що ідентифікується по адресатові. Відзначимо, що ця концепція відрізняється від концепції сеансу RTP, хоча сеанси RSVP і RTP можуть мати взаємнооднозначну відповідність. Після резервування маршрутизатором ресурсів для конкретного адресата він розглядає це як початок сеансу і виділяє ресурси на час цього сеансу.
Запит на резервування від кінцевої системи-одержувача, названий описувачем потоку, складається із специфікацій потоку і фільтру. Специфікація потоку визначає необхідну якість послуг і використовується вузлом для завдання параметрів планувальника пакетів. Маршрутизатор передає пакети із заданим набором переваг, спираючись на поточну специфікацію потоку.
Специфікація фільтру визначає набір пакетів, під які запрошуються ресурси. Разом з сеансом вона визначає набір пакетів (або потік), для яких необхідна якість послуг повинна бути забезпечене. Будь-які інші пакети, що направляються цьому адресатові, обробляються постільки, поскільки мережа в змозі це зробити.
RSVP не визначає зміст специфікації потоку, він просто передає запит. Специфікація потоку включає зазвичай клас послуг, Rspec (R означає резерв) і Tspec (Т означає трафік). Два інших параметра є набором чисел. Параметр Rspec визначає необхідна якість послуг, а параметр Tspec описує потік даних. В принципі специфікація фільтру описує довільну підмножину пакетів одного сеансу (тобто пакетів, адресат яких визначається даним сеансом). Наприклад, специфікація фільтру може визначати тільки конкретних відправників або протоколи або пакети, поля протокольних заголовків яких співпадають із заданими.
З погляду хоста робота протоколу RSVP складається з наступних етапів (перші два етапи в цій послідовності мають іноді зворотну черговість)
1. Одержувач вступає в групу багатоадресної розсилки за допомогою відправки повідомлення по протоколу IGMP сусідньому маршрутизатору.
2. Потенційний відправник відправляє повідомлення за адресою групи.
3. Одержувач приймає повідомлення Path, що ідентифікує відправника.
4. Тепер, коли одержувач має інформацію про зворотний шлях, він може відправляти повідомлення Resv з дескрипторами потоку.
5. Повідомлення Resv передаються по мережі відправникові.
6. Відправник починає передачу даних.
7. Одержувач починає прийом пакетів даних.
