Реферат: Архітектура диференційованих послуг

Реферат: Архітектура диференційованих послуг

АРХІТЕКТУРА ДИФЕРЕНЦІЙОВАНИХ ПОСЛУГ

Содержание

1. Загальна характеристика DiffServ

2. DCSP і рівні обслуговування DiffServ

3. Порівняльна характеристика базових архітектурних моделей QoS

Термін "диференційоване обслуговування" (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 відповідно до необхідного рівня 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-пріоритету.

Як зазначалося вище, зміст поля 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 припустимих значень формату AFij, де  - клас обслуговування (),  - рівень відкидання пакетів (); визначається RFC 2597 (табл.3).

На рис.3 і 4 показане обслуговування трафіка IP-пакетів у випадку використання селекторів класу CS і у випадку використання політики гарантованої передачі.

Отже, у рамках DiffServ можна виділити три різновиди РНВ-політики (рівня обслуговування):

негарантована доставка даних (DCSP за замовчуванням);

РНВ-політика негайної передачі (EF РНВ);

РНВ-політика гарантованої доставки (AF РНВ).

При реалізації архітектури DiffServ найвищу якість обслуговування (Premium Service), яку можна порівняти з якістю виділених каналів, забезпечує політика негайної передачі пакетів EF РНВ.

Таблиця 2 - Порівняльна характеристика різних політик покрокової обробки DiffServ

Таблиця 3 - Значення DCSP політики гарантованої передачі

Рисунок 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 визначається чотири класи обслуговування: AF1, AF2, AF3 і AF4. Кожному класові виділяється певна кількість ресурсів (буферного простору і смуги пропускання) відповідно до укладеної раніше угоди SLA або прийнятої в мережі політики.

У межах кожного класу вводиться три рівні відкидання пакетів. Якщо при перевантаженні виникне необхідність відкинути пакети якого-небудь класу, наприклад, AF1, імовірність їхнього відкидання підкорятиметьсяся такому правилу:

,

де  - імовірність відкидання пакета класу обслуговування .

Іншими словами, в першу чергу буде відкинутий пакет класу , потім класу , потім . Відкидання відбувається при перевищенні класом (у даному випадку AF1) виділеної для нього смуги. Пакети потоку-порушника можуть маркуватися з підвищенням імовірності відкидання.

Рівень обслуговування AF PHB має виділений йому діапазон припустимих значень DSCP. Поле DSCP у цьому випадку має формат xyzab0, де xyz можуть бути 001, 010, 011 або 100, а значення ab відображає значення .

На практиці класи сервісу AF РНВ добре співпрацюють з одним класом сервісу EF - трафік EF може обслуговуватися за пріоритетною схемою, але з обмеженням інтенсивності вхідного потоку. Пропускна здатність, що залишилася, розподіляється між класами трафіка AF відповідно до алгоритму зваженого обслуговування, що забезпечить необхідну пропускну здатність, але не мінімізацію затримок. Кожному класові AF-трафіка відповідає своя власна черга пакетів, що дозволяє реалізувати ефективне управління смугою пропускання. Кожен клас AF-трафіка характеризується трьома рівнями пріоритету відкидання пакетів (низький, середній і високий), що дозволяє реалізувати механізм управління чергою за типом механізму довільного раннього виявлення (RED).

У табл.4 наведена коротка порівняльна характеристика базових архітектурних моделей QoS у мережах IP, включаючи негарантовану доставку.

Таблиця 4 - Порівняльна характеристика базових архітектурних моделей QoS у мережах IP