Архітектура диференційованих послуг
АРХІТЕКТУРА ДИФЕРЕНЦІЙОВАНИХ ПОСЛУГ
Содержание
1. Загальна характеристика DiffServ
2. DCSP і рівні обслуговування DiffServ
3. Порівняльна характеристика базових архітектурних моделей QoS
1. Загальна характеристика DiffServ
Термін "диференційоване обслуговування" (Differentiated Service, DiffServ) застосовується як у широкому значенні для позначення рівня обслуговування, так і у вузькому - для позначення архітектури QoS, що забезпечує однойменний рівень обслуговування. DiffServ у вузькому значенні можна визначити як масштабовану архітектуру IP QoS, що забезпечує якість обслуговування на основі чітко визначених компонентів, які комбінуються з метою надання необхідних послуг, і яка орієнтована для застосування в мережах постачальників мережних послуг і в магістральних мережах.
Базові елементи архітектури DiffServ описані в декількох специфікаціях:
RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) задає спосіб маркування пакетів;
RFC 2598 (An Expedited Forwarding PHB) і 2597 (Assured Forwarding PHB Group) визначають два основних різновиди сервісу;
RFC 2475 (An Architecture for Differentiated Service) описує взаємодію компонентів в архітектурній моделі DiffServ.
Основним моментом у моделі DiffServ є диференціювання трафіка шляхом його розбивки на класи з різними пріоритетами (рівнем QoS), і, як наслідок, головною задачею DiffServ є визначення і стандартизація байта диференційованої послуги (DS, RFC 2474). Байт DS у рамках архітектури DiffServ замінює байт типу обслуговування (Type of Service, ToS) із заголовка пакета IPv4 і байт класу трафіка (Traffic Class) пакета IPv6. Специфікація RFC 2474 визначає байт DS, вводить поле коду диференційованої послуги (Differentiated Services Code Point, DSCP) і його маркування, від чого надалі залежить політика покрокового обслуговування пакета (Per-Hop Behavior, PHB), тобто рішення про просування пакета у кожному проміжному вузлі мережі, і як результат, наданий рівень QoS.
Архітектура DiffServ (рис.1, табл.1) передбачає наявність класифікатора і формувача трафіка на границі DiffServ-домена, а також підтримку функції розподілу ресурсів у ядрі з метою забезпечення необхідної політики покрокового обслуговування PHB.
Рисунок 1 - Типи маршрутизаторів в архітектурі DiffServ
Таблиця 1 - Функціональні блоки DiffServ
Функціональний блок |
Розташування |
Функція |
Дія |
Формувачі трафіка |
Вхідний інтерфейс приграничного маршрутизатора DiffServ-домена |
Класифікація пакетів, вирівнювання й обмеження трафіка |
Обмеження вхідного трафіка й установка значення поля DSCP на основі профілю трафіка |
Пристрої, що реалізують РНВ-політику |
Усі маршрутизатори DiffServ - домена |
Розподіл ресурсів і політика відкидання пакетів |
РНВ-політика обробки пакетів визначається на основі характеристик якості обслуговування, що відповідають заданому значенню поля DSCP |
архітектура диференційована послуга маршрутизатор
Приграничні маршрутизатори DiffServ-домену виконують функцію класифікації і встановлюють значення поля DSCP відповідно до необхідного рівня QoS. Як під час класифікації, так і потім під час формування трафіка важливу роль відіграє SLA - угода про якість обслуговування, яка попередньо укладається між постачальником послуг і замовником. Наявність SLA є необхідною умовою реалізації архітектури DiffServ. Дана угода встановлює критерії політики і визначає профіль трафіка. Очікується, що трафік буде згладжуватися (функція shaping) у вихідних точках домена відповідно до SLA, а у вхідній точці домена профілюватися (обмежуватися) відповідно до правил політики (функція policing). Будь-який трафік "поза профілем" (тобто такий, що виходить за верхні границі смуги пропускання, що зазначені в SLA) не одержує гарантій щодо обслуговування (або ж оплачується за підвищеною ціною у відповідності зі SLA). Критерії політики можуть включати час дня, адреси джерела і призначення, транспортний протокол, номери портів. У загальному випадку будь-який вміст пакета може використовуватися для застосування політики.
Внутрішні вузли DiffServ-домена (рис.1) забезпечують передавання пакета на підставі поля DSCP у його заголовку, тобто реалізують РНВ-політику. РНВ-політика - це політика дій мережного вузла по відношенню до пакетів з певним значенням поля DSCP, яка спостерігається ззовні і яку можна розглядати як своєрідну "чорну шухляду". РНВ-політику можно визначити в термінах пріоритету в наданні ресурсів відносно інших РНВ-політик або ж за допомогою таких вимірюваних характеристик трафіка, як затримка пакетів, рівень втрати пакетів або тремтіння трафіка.
На рис.2 зображена узагальнена операційна модель QoS. Отже архітектурою DiffServ з метою надання необхідної якості обслуговування передбачається така послідовність обробки пакетів:
1. На приграничних маршрутизаторах DiffServ-домена (під час входження в домен) виконуються задачі TCB:
класифікація пакетів відповідно до необхідного рівня QoS;
відповідне маркування поля DSCP у заголовку кожного IP-пакета;
формування трафіка відповідно до параметрів, які оговорено в SLA (функції вирівнювання й обмеження, деякі пакети можуть бути відкинуті);
постановка пакета в чергу для передачі в опорну мережу.
2. В опорній мережі (усередині DiffServ-домену) реалізується PHB-політика:
формування й обслуговування черг (функція розподілу ресурсів);
відкидання пакетів з метою попередження виникнення перевантаження.
Рисунок 2 - Операційна модель DiffServ
Зверніть увагу, що в рамках DiffServ не передбачена явна сигналізація про необхідну якість обслуговування, не здійснюється резервування ресурсів і усі вузли, що реалізують РНВ-політику, працюють незалежно один від одного.
Слід зазначити, що архітектура диференційованих послуг визначає усього лише базові механізми, на основі яких здійснюється обслуговування пакетів. Використовуючи ці механізми як будівельні блоки, можна розробити безліч різних послуг. Нагадаємо, що в даному випадку послуга визначає досить вагомі характеристики передачі пакетів, такі, як пропускна здатність, затримка, джитер, а також рівень втрат пакетів в одному напрямку при передачі уздовж мережного маршруту. До того ж можна охарактеризувати послугу в термінах відносного пріоритету при доступі до ресурсів мережі. Після визначення послуги розробляються відповідні їй рішення про передавання пакета (РНВ-політика) для кожного вузла мережі, що підтримує дану послугу.
Наприклад, компанія Cisco пропонує такий набір механізмів для реалізації архітектури диференційованих послуг:
модульний QoS інтерфейс командного рядка (Cisco Modular QoS command-line interface, MQC), що допомагає спростити задачу одночасного настроювання декількох інструментів QoS на одному мережному пристрої;
механізм узгодження швидкості доступу CAR, що виконує функції класифікації і маркування полів IP-пріоритету і QoS-групи, вимірювання трафіка й обмеження інтенсивності трафіка (policing), забезпечуючи тим самим управління смугою пропускання;
механізм маркування пакетів на основі класу Class-Based Packet Marking, що реалізує однойменну функцію маркування пакетів з метою диференціації трафіка;
механізм обмеження трафіка Traffic Policing, що дозволяє обмежити швидкість на вхідному або вихідному інтерфейсі на основі сформованих користувачем критеріїв, значень IP-пріоритету, QoS-групи або поля DSCP;
формування трафіка на основі класу Class-Based Shaping, що дозволяє настроїти GTS на основі класу, визначити середню і пікову швидкість для кожного класу і конфігурувати CBWFQ у рамках GTS;
механізм обслуговування черг CBWFQ, що дозволяє гарантувати мінімальне значення смуги, яка виділяється трафіку в період перевантаження на даному інтерфейсі;
механізм обслуговування черг LLQ, у рамках якого вводиться пріоритетна черга PQ, що використовується для чутливого до затримок трафіка, наприклад, мовного;
механізм зваженого довільного раннього виявлення перевантажень WRED, що реалізує випадкове відкидання пакетів, де імовірність відкидання розраховується на підставі IP-пріоритету або DSCP. Даний механізм має працювати в парі з CBWFQ;
реалізація розширення MPLS Class of Service (CoS), що дозволяє постачальникам послуг установлювати поле MPLS Experimental замість IP-пріоритету.
2. DCSP і рівні обслуговування DiffServ
Як зазначалося вище, зміст поля DCSP у заголовку пакета відображає необхідний рівень якості обслуговування, у зв'язку з цим розглядати ці питання (DCSP і рівні обслуговування DiffServ) необхідно комплексно.
Усі коди DCSP, які визначені робочою групою IETF щодо створення та впровадження DiffServ, в залежності від рівня обслуговування (застосовуваної політики РНВ) можна розбити на чотири групи (табл.2):
DCSP за замовчуванням або стандартний код DCSP відповідає політиці негарантованої доставки пакетів (best effort), визначений як 000 000 (RFC 2474);
DCSP, сумісні з кодами IP-пріоритету, так звані селектори класу (Classs Selector, CS) забезпечують розділення трафіка на 8 класів (рівнів пріоритету), були уведені для сумісності з існуючими IP-системами, що використовують поле пріоритету; мають формат ххх000, де х - бінарні 0 або 1. Ці коди подані в табл.2.
DCSP політики негайної передачі (Expedited Forwarding, EF) указує на найвищий рівень обслуговування, який надається за додаткову вартість, визначається RFC 2598; рекомендоване значення - 101110.
DCSP політики
гарантованої передачі (Assured Forwarding, AF)
мають 12 припустимих значень формату
AF>ij>,
де
- клас обслуговування (
),
- рівень відкидання пакетів (
);
визначається RFC 2597 (табл.3).
На рис.3 і 4 показане обслуговування трафіка IP-пакетів у випадку використання селекторів класу CS і у випадку використання політики гарантованої передачі.
Отже, у рамках DiffServ можна виділити три різновиди РНВ-політики (рівня обслуговування):
негарантована доставка даних (DCSP за замовчуванням);
РНВ-політика негайної передачі (EF РНВ);
РНВ-політика гарантованої доставки (AF РНВ).
При реалізації архітектури DiffServ найвищу якість обслуговування (Premium Service), яку можна порівняти з якістю виділених каналів, забезпечує політика негайної передачі пакетів EF РНВ.
Таблиця 2 - Порівняльна характеристика різних політик покрокової обробки DiffServ
PHB |
Опис |
DSCP |
Політика негарантованої доставки пакетів (Best effort, BE) |
PHB без надання всіляких гарантій щодо якості обслуговування |
DSCP за замовчуванням (000 000) |
Селектори класу (Class selector, CS) |
Використовується вісім значень DSCP, де завжди останні три біти нульові. Уведені для зворотної сумісності з IP-пріоритетами. Засновані на логіці "більше - краще": чим більше значення DSCP, тим вище якість обслуговування |
CS1, CS2, CS3, CS4, CS5, CS6, CS7 |
Політика гарантованої передачі (Assured forwarding, AF) |
PHB містить два компоненти: планувальник черг забезпечує мінімальну смугу для кожної з чотирьох окремих черг і три рівні порога відкидання для кожної з черг. DSCP не завжди підкоряється правилу "більше - краще". |
AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33, AF41, AF42, AF43 |
Політика негайної передачі (Expedited forwarding, EF) |
PHB містить два компоненти: планувальник черг забезпечує низький рівень затримки, тремтіння і втрат, а також гарантовану частку смуги; для виділення достатньої смуги необхідна функція обмеження (policing). |
EF |
Таблиця 3 - Значення DCSP політики гарантованої передачі
|
Низька імовірність відкидання в межах класу |
Середня імовірність відкидання в межах класу |
Висока імовірність відкидання в межах класу |
Клас 1 |
AF11/10 / 001010 |
AF12/12/001100 |
AF13/14/001110 |
Клас 2 |
AF21/18/010010 |
AF22/20 / 010100 |
AF23/22/010110 |
Клас 3 |
AF31/26/011010 |
AF32/28/011100 |
AF33/30 / 011110 |
Клас 4 |
AF41/34/100010 |
AF42/36/100100 |
AF43/38/100110 |
Рисунок 3 - Обробка IP-трафіка у випадку використання селекторів класу CS
Рисунок 4 - Приклад обробки IP-трафіка у випадку використання політики гарантованої передачі
Група типів локального поводження Expedited Forwarding (EF) була спеціально розроблена з метою організації віртуальної виділеної лінії для передачі трафіка через домен DiffServ. Характерними рисами застосування політики EF є низький рівень втрати пакетів, мала затримка, незначний джитер пакетів трафіка, а також гарантована смуга пропускання. Політика EF РНВ застосовується для обслуговування трафіка таких аплікацій, як передача мовлення мережами IP (VoIP), аплікацій відеоконференцій, а також для забезпечення таких послуг, як передача інформації віртуальними орендованими каналами, оскільки ця послуга є з'єднанням кінцевих вузлів DiffServ-домена типу "точка-точка". Скориставшись сервісом Expedited Forwarding, організація може побудувати власну виділену (з погляду QoS) мережу поверх загальнодоступної мережі провайдера.
З огляду на те, що рівень обслуговування EF має забезпечити припустиму величину затримки, а значну частку в сумарній затримці пакета складає час очікування в черзі, політика EF РНВ не має допускати виникнення черг (допускається черга дуже малого розміру). Виникнення черг на перевантажених ділянках мережі пов'язане з тим, що інтенсивність вхідного потоку трафіка перевищує інтенсивність його вихідного потоку. Звідси вирішення задачі запобігання появи черг - обмеження максимальної інтенсивності вхідного потоку трафіка мінімальною інтенсивністю його вихідного потоку. Задача обмеження вхідного трафіка покладається на формувачі трафіка, які реалізовані в прикордонних маршрутизаторах DiffServ-домена. Інтенсивність вихідного потоку трафіка (смуга пропускання) регулюється РНВ-політикою.
У випадку виникнення перевантаження маршрутизатор може виділити ресурси, яких досить для забезпечення певної інтенсивності вихідного трафіка для заданого інтерфейса. Це здійснюється шляхом використання різних функціональних реалізацій політики EF РНВ. Мова йде про застосування різних механізмів обслуговування черг, таких як зважений механізм рівномірного обслуговування черг на основі класу трафіку (CBWFQ), зважений механізм кругового обслуговування (WRR) і механізм кругового обслуговування з дефіцитом (DRR). У цьому випадку EF-трафіка призначається вага, що відповідає смузі пропускання, яка набагато перевищуює інтенсивність вхідного EF-трафіка. Можна модифікувати ці механізми, додавши пріоритетну чергу, призначену спеціально для обслуговування EF-трафіка.
Рівень обслуговування, що відповідає політиці гарантованої доставки пакетів AF РНВ, поступається за якістю обслуговування рівневі EF РНВ, однак є цілком прийнятним для більшості ТСР-аплікацій. Чотири класи обслуговування усередині AF РНВ орієнтовані на гарантовану доставку, але без мінімізації рівня затримок пакетів. Рівень обслуговування AF PHB відповідає рівню контрольованого навантаження моделі інтегрованого обслуговування.
У рамках політики AF PHB визначається чотири класи обслуговування: AF>1>, AF>2>, AF>3> і AF>4>. Кожному класові виділяється певна кількість ресурсів (буферного простору і смуги пропускання) відповідно до укладеної раніше угоди SLA або прийнятої в мережі політики.
У межах кожного класу вводиться три рівні відкидання пакетів. Якщо при перевантаженні виникне необхідність відкинути пакети якого-небудь класу, наприклад, AF>1>, імовірність їхнього відкидання підкорятиметьсяся такому правилу:
,
де
- імовірність відкидання пакета класу
обслуговування
.
Іншими словами, в
першу чергу буде відкинутий пакет класу
,
потім класу
,
потім
.
Відкидання відбувається при перевищенні
класом (у даному випадку AF>1>)
виділеної для нього смуги. Пакети
потоку-порушника можуть маркуватися з
підвищенням імовірності відкидання.
Рівень обслуговування
AF PHB має виділений йому діапазон
припустимих значень DSCP. Поле DSCP у цьому
випадку має формат xyzab0,
де xyz можуть
бути 001, 010, 011 або 100, а значення ab
відображає значення
.
На практиці класи сервісу AF РНВ добре співпрацюють з одним класом сервісу EF - трафік EF може обслуговуватися за пріоритетною схемою, але з обмеженням інтенсивності вхідного потоку. Пропускна здатність, що залишилася, розподіляється між класами трафіка AF відповідно до алгоритму зваженого обслуговування, що забезпечить необхідну пропускну здатність, але не мінімізацію затримок. Кожному класові AF-трафіка відповідає своя власна черга пакетів, що дозволяє реалізувати ефективне управління смугою пропускання. Кожен клас AF-трафіка характеризується трьома рівнями пріоритету відкидання пакетів (низький, середній і високий), що дозволяє реалізувати механізм управління чергою за типом механізму довільного раннього виявлення (RED).
3. Порівняльна характеристика базових архітектурних моделей QoS
У табл.4 наведена коротка порівняльна характеристика базових архітектурних моделей QoS у мережах IP, включаючи негарантовану доставку.
Таблиця 4 - Порівняльна характеристика базових архітектурних моделей QoS у мережах IP
best effort |
DiffServ |
IntServ |
|
1 |
2 |
3 |
4 |
Наданий рівень якості обслуговування |
Негарантована доставка |
Рівень диференційованих послуг (Soft QoS), не забезпечує гарантій наданих послуг |
Рівень інтегрованих послуг (Hard QoS), дає тверді гарантії щодо забезпечення необхідного обсягу ресурсів |
Область застосування |
Без обмежень |
Магістральні мережі |
Орієнтується на периферію мережі, LAN, MAN |
Функція QoS мережного рівня |
Зв’язність вузлів мережі, рекомендується застосовувати механізми запобігання перевантажень (WRED) |
Механізми СВ-Marking, Class-Based Shaping, CAR, WRED, WFQ, CBWFQ, LLQ. У мережах MPLS - CoS |
Протокол RSVP |
Функція QoS канального рівня |
Обслуговування з невизначеною бітовою швидкістю UBR у мережах ATM, механізм узгодження швидкості передачі інформації (CIR) у мережах Frame Relay |
IEEE 802.1p |
Диспетчер пропускної здатності підмережі SBM, механізм обслуговування з постійною бітовою швидкістю CBR у мережах ATM, механізм узгодження швидкості передачі інформації (CIR) у мережах Frame Relay |
Переваги |
Простота, не вимагає реалізації складних QoS-механізмів |
- Висока масштабованість; можлива організація великої кількості класів обслуговування (при використанні шестибітного поля DSCP - 64 класи) |
- Забезпечення твердих гарантій щодо наданого рівня якості послуг; реалізація управління доступом з метою перевірки доступних ресурсів; інтеграція з інфраструктурою правил COPS; підтримка сигналізації Н.323 |
Недоліки |
Відсутність усіляких гарантій щодо якості доставки і щодо самого факту доставки, відсутність диференціації трафіка на класи (рівні) обслуговування. Мінімальна гарантована смуга пропускання 25% від ширини каналу, залежить від кількості інших класів і їхніх вимог |
- Відсутність твердих гарантій; вимагає реалізації великої кількості механізмів QoS, можливі складності в настроюванні |
Низька масштабованість, що пов'язано з обробкою кожного потоку окремо, необхідністю зберігати інформацію про стан кожного потоку на кожному вузлі, великими обсягами сигнальної інформації |