Сайт ДонНТУ | Українська | Русский | English | Портал Магістрів ДонНТУ |
|
|
Фазульянов Сергій ВалерійовичФакультет:
комп'ютерних інформационних технологій і
автоматики (КИТА)
|
Тема магістерської
роботи:
|
Автореферат
|
, | (1-4) |
де Ai1 - відносний узагальнюючий коефіцієнт втрат пакетів, Ai2 - відносний узагальнюючий коефіцієнт затримки, Ai3 - Відносний узагальнюючий коефіцієнт джитеру, Ai4 - відносний узагальнюючий коефіцієнт смуги пропускання. Відносні узагальнюючі коефіцієнти розраховуються для приведення існуючих даних до загальної форми, яка піддається подальшій математичній обробці.
Матриця В заповнюється числами 1, 2 і 3, які відображають, відповідно, низьку, середню і високу значимість вимог до показників QoS. Ці параметри можуть бути взяті відповідно до класичних вимог або можуть визначатися оператором. Коефіцієнти Bij використовуються для обліку важливості кожної вимоги QoS відповідного класу трафіку при розрахунку пріоритету.
Значення пріорітетов для класів трафіку розраховується за формулою (5):
(5) |
Ця формула може бути адаптована для будь-якого кількості класів трафіку і різних вимог QoS. Результатом розрахунку є десяткове число 0<Pri<1, яке для вищого пріоритету буде більше, ніж для меншого. Значення пріоритету може бути замінено відповідним маркером для застосування на практиці. Наприклад, пакети можуть бути промарковані шляхом визначення поля IP-пріоритету або поля коду диференційованої послуги, які розташовані в заголовках IP-пакетів.
Результати розрахунків відображені в останньому стовпчику табл. 1. У дужках вказано номер пріоритету обробки пакета даних.
Таблиця 1 - Вимоги до QoS різних класів трафіку і їх відносний пріоритет
Клас трафіку |
і |
Показники QoS |
Пріоритет Pri |
|||
Втрати P, % |
Затримка T, ms |
Джиттер dt, ms |
Смуга C, kbps |
|||
j=1 |
j=2 |
j=3 |
j=4 |
|||
Голос |
1 |
< 0,25 |
150 |
< 10 |
21-106 |
0,2430 (2) |
IPTV |
2 |
< 2 |
1000 |
< 30 |
10240 |
0,1527 (4) |
Відео-конференції |
3 |
< 1 |
150 |
< 30 |
12288 |
0,2314 (3) |
Інтерактивні дані |
4 |
< 0,1 |
400 |
Немає значних вимог |
128 |
0,0950 (5) |
Аудіо |
5 |
< 1 |
1000 |
<15 |
256 |
0,0157 (6) |
Трафік сигнализації |
6 |
< 0,1 |
100 |
Немає значних вимог |
64 |
0,2514 (1) |
Клас Best Effort |
7 |
< 2 |
1000 |
Немає значних вимог |
64 |
0,0109 (7) |
Запропонований критерій дозволяє створити уніфікований і формалізований підхід до визначення пріоритетів обслуговування будь-яких класів трафіку мультисервісних мереж, що є необхідним при вирішенні завдань ефективного керування ресурсами мережі.
Методика пропонує маркувати пакети кодової комбінацією, отриманою в результаті попереднього розрахунку значень критерію для кожного з класів трафіку. Для цього на початковому етапі функціонування системи визначаються із вхідними даними, які формуються на основі як вимог QoS, так і політики оператора. Наступним кроком, після отримання значень пріоритетів для кожного класу трафіку, є присвоєння кожному з класів своєї кодової комбінації, яка відповідає значенню критерію саме для цього класу трафіку. Після чого отримані комбінації фіксуються у відповідних полях мережевих протоколів, які були відзначені вище.
Методика може бути використана для розмежування черговості обробки класів трафіку мультисервісних мереж з використанням різних мережевих протоколів, які пристосовані для вказівки рівня пріоритету в заголовках пакетів.
Процес визначення пріоритету може бути автоматизований за допомогою створення програмного продукту, який виконував би розрахунок значення відносного пріоритету після визначення нових значень вхідних змінних.
Порядок роботи методики наведено на малюнку.
Рисунок 1. Порядок роботи методики пріоритезації трафіку в мультисервісних телекомунікаційних мережах
Однією з особливостей застосування методики є різний формат подання коду пріоритету в різних спеціалізованих полях підзаголовків пакетів різних мережевих протоколів.
У стандарті 802.1p розглянуті принципи організації пріоритетного трафіку на рівні L2, засновані на використанні полів певних стандартом 802.1Q. Стандарт 802.1p є частиною стандарту 802.1D (Мостові з'єднання). У протоколі 802.1Q визначено 4 байти мітки, яка передає інформацію про приналежність пакету до того чи іншого VLAN'у. Вона складається з двох частин - поля EtherType та групи полів, що утворюють TCI (Tagged Control Information). Поле EtherType використовується в мітці як TPID (Tagged Protocol Identifier), що містить інформацію про необхідність обробки кадру згідно IEEE 802.1Q.
Рисунок 2. Формат міток VLAN на рівні L2 (стандарт 802.1р).
Частина мітки, що складається з полів пріоритету класу трафіку (CoS, Class of Service), CFI (Canonical Format Identifier) і 12-бітового поля VID (Ідентифікатор віртуальної мережі) називається TCI (Tagged Control Information). Коди пріоритету CoS присвоюються користувачем. Після додавання мітки в кадр необхідно перерахувати контрольну суму FCS. При цьому канальний рівень повинен підтримувати множинні черги. При додаванні мітки може бути перевищена гранично допустима довжина кадру (1518 байт). У зв'язку з цим IEEE веде розробку специфікації 802.3ас, в якій максимальна довжина кадру збільшена на 4 октети.
Отримана в результаті розрахунку 3-бітова комбінація, кодує відносний пріоритет класу трафіку, розміщується в полі пріоритету без проблем і жодні додаткові операції з перетворення кодового слова не потрібні.
Керування трафіком на рівні L3 в рамках стека протоколів TCP/IP грунтується на можливостях цих транспортних протоколів (IP, UDP, TCP). Протокол IP передбачає завдання значення ToS, що визначається відповідним полем заголовка.
Поле тип сервісу (TOS - type of service) характеризує те, як повинна оброблятися дейтаграма. Формат поля TOS визначено в документі RFC-1349. Це поле ділиться на 6 субполей. Біти C, D, T і R характеризують побажання щодо способу доставки дейтаграми. D=1 вимагає мінімальної затримки, T=1 - високу пропускну здатність, R=1 - високу надійність, а C=1 - низьку вартість. Одночасно в комбінації цих чотирьох полів може містити лише один біт рівний 1. Значення всіх чотирьох біт за замовчуванням дорівнюють нулю.
Рисунок 3.Формат
поля
ToS (Type of
Service)
(Анімація: кадрів - 10, циклів - 7, тривалість - 42 секунди)
3-бітове субполе пріоритет (IPP - IP Precedence) надає можливість присвоїти код пріоритету кожної дейтаграми. Для розміщення комбінації, визначальною значення відносного пріоритету класу трафіку, в полі IP Precedence не потрібно додаткових перетворень коду, отриманого в результаті розрахунку. Однак для встановлення значень біт D, T, R, C необхідне введення в алгоритм роботи методики додаткових операнд, які будуть формувати код типу трафіку, спираючись на максимальну чутливість конкретного класу трафіку до того чи іншого показника якості обслуговування. В даний час полі ToS не використовується.
У рекомендаціях RFC-2474 поле TOS замінено на поле DSCP (Differentiated Services Code Point), де молодші 6 біт визначають код DS (Differentiated Services), а старші два біти поки що не визначені і підлягають обнуленню.
Після початку інтенсивних розробок з забезпечення показників QoS зросла увага до можливості використання поля ToS, яке в більшості реалізацій до цього ігнорувалося. У 1998 році в RFC-2474 з'явилася пропозиція щодо заміни поля ToS на поле DSCP, яке також має довжину 8 біт, але, на відміну від поля ToS, тільки 6 біт задіяні під визначення коду послуги. 2 біти , що залишилися, в даний час не визначені. Іноді поле DSCP називають байтом DS (Differenttiated Services).
Рисунок 4.Формат поля DSCP.
Біти DS0-DS5 визначають селектор класу. Значення цього коду представлені в таблиці нижче. Стандартним значенням DSCP за замовчуванням є 000000.
Таблиця 2. Селектор класу DSCP
Селектор класу |
DSCP |
Пріоритет 1 |
001000 |
Пріоритет 2 |
010000 |
Пріоритет 3 |
011000 |
Пріоритет 4 |
100000 |
Пріоритет 5 |
101000 |
Пріоритет 6 |
110000 |
Пріоритет 7 |
111000 |
Крім того, на базі DSCP заснована технологія покрокової поведінки PHB (Per Hop Behavior). У рамках цієї політики визначаються коди DSCP всередині класів, що істотно розширює можливості з керування ресурсами мережі та забезпечення необхідного рівня QoS.
Для адаптації методики до використання з полем DSCP потрібно додатково ввести в алгоритм операнди, які будуть додавати в кодову комбінацію, що визначає пріоритет класу трафіку, комбінацію з трьох біт, щоб перетворити отримані результати у формат поля DSCP. Ці біти можуть бути сформовані з урахуванням політик PHB, шляхом введення в методику відповідних операнд, або ж взяті рівними 0 для отримання шестибітної комбінації селектора класів.
Рисунок 5. Додавання до коду пріоритету класу трафіку додаткових біт для поміщення його в полі DSCP
Згідно з документом RFC-1883 в протоколі IPv6 полі пріоритету мало 4 біта. Для цього поля значення пріоритетів діляться на два піддіапазону. Коди від 0 до 7 використовуються для завдання пріоритету трафіку, для якого здійснюється контроль перевантаження, з 8 до 15 застосовуються для визначення пріоритету трафіку, для якого спостереження і обробка перевантаження не проводиться, наприклад, у випадку пакетів «Реального часу».
В даний час, відповідно до документа RFC-2460, полі «Пріоритет» замінено полем «Клас трафіку», довжиною 8 біт. За рахунок цього розмір поля «Мітка потоку» скорочений до 20 біт. Таким чином формат заголовка пакету IPv6 був приведений до вимог документа RFC-2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", орієнтованого на вирішення завдань керування QoS.
Моделювання процесу функціонування мультисервісних
телекомунікаційних мереж із застосуванням розробленої методики
пріоритезації планується виконувати в пакеті Opnet. Даний
програмний продукт дозволяє сформувати різнорідний потік даних,
що дозволить змоделювати ділянку мультисервісної мережі, що потребує
керування розподілом ресурсів між різними класами послуг.
Моделювання буде складатися з декількох дослідів:
- Моделювання процесу функціонування ділянки мультисервісної мережі
без застосування пріоритезації
- Моделювання процесу функціонування ділянки мультисервісної мережі
із застосуванням пріоритезації, заснованої на одному з умов (смуга
пропускання, затримка та ін)
- Моделювання процесу функціонування ділянки мультисервісної мережі
із застосуванням розробленої методики приоритезації
На основі отриманих результатів буде зроблено висновок про ефективність прийнятих рішень.
Надалі планується провести дослідження можливості адаптації методики розрахунку відносного значення пріоритету для застосування в пристроях ущільнення трафіку, визначення особливостей реалізації методики в складі систем керування трафіком мереж, побудованих за різним мережних технологій.
Також одним з напрямків дослідження може бути обрано дослідження можливості внесення до методику більш явного визначення пакетів, чутливих до певного вимогу QoS. У рамках цього напрямку дослідження планується розглянути можливість формування кодів DSCP з урахуванням політик per Hop Behavior для більш тонкого керування розподілом ресурсів мережі.
При виконанні роботи були розглянуті принципи пріоритезації трафіку мультисервісних телекомунікаційних мереж, проведено огляд основних принципів організації пріоритетного трафіку в сучасних телекомунікаційних мережах. Зроблено обґрунтування мети роботи як створення формалізованої методики пріоритезації послуг мультисервісних телекомунікаційних мереж на основі критерію визначення відносного пріоритету класів трафіку, що базується на вимогах, що висуваються класами трафіку та операторами до якості обслуговування.
Запропоновано формалізований критерій визначення відносного пріоритету класів трафіку мультисервісних мереж, заснований на вимогах QoS, що висуваються класами трафіку та операторами зв'язку. Розроблено базовий алгоритм функціонування методики, заснований на запропонованому критерії.
Розглянуто особливості організації пріоритетного трафіку, описувані різними стандартами і рекомендаціями. Визначено напрямки подальших досліджень, спрямованих на адаптацію розробляємої методики до практичного застосування в умовах реально існуючих мультисервісних телекомунікаційних мереж.
1. Крылов
В.В. Теория
телетрафика и ее
приложения./ В.В. Крылов, С.С. Самохвалова. – СПб.:
БХВ-Петербург. –2005.
– 288 c
2. Vegesna S. IP Quality of Service./ Srinivas Vegesna.
– Cisco Press.
– 2001. – 368 p
3. Фазульянов С.В. Критерій визначення відносного пріоритету класів
трафіку мультисервісних мереж. - Сучасні проблеми радіотехніки та
телекомунікацій «РТ - 2010»: Матеріали 6-ої міжнар.
молодіжної наук.-техн. конф., 19 – 24 квітня 2010 р.
—
Севастополь: Вид-во СевНТУ, 2010. – стор. 162.
4. Норенков И.П. Основы автоматизированного проектирования: Учеб. для
вузов./ И.П.Норенков – М.: Изд-во МГТУ им. Н.Э. Баумана,
2000.
–360 с.
5. ITU-T Recommendation Y.1540/Y.1541. Network perfomance objectives
for IP-based services. Geneva: International Telecommunication
Union.[Електронний ресурс]
– 2006./ - Режим доступу до статті: http://www.itu.int/rec/dologin~type=items
6. Дегтяренко І.В., Фазульянов С.В. Методика визначення відносного
пріоритету класів трафіку мультисервісних мереж. –
Науково-технічна конференція «Проблеми
телекомунікацій»: Збірник тез. К.: НТУУ
«КПІ», 2010. – стор. 188
7. Олифер Н., Олифер В. Базовые технологии локальных сетей./Н.Олифер,
В.Олифер –
Центр Информационных Технологий, 1999
8. Семенов Ю.А. Telecommunication technologies - телекоммуникационные
технологии (v3.3, 10 мая 2010 года) [Електронний
ресурс]/Ю.А. Семенов./ - Режим доступу до статті: http://book.itep.ru
9. Type of Service in the Internet Protocol Suite; RFC-1349,
July 1992 [Електронний ресурс]/P.
Almquist./ - Режим доступу к статті: http://www.ietf.org/rfc/rfc1349.txt
10. Definition of the Differentiated Services Field (DS Field)in the
IPv4 and IPv6 Headers; RFC-2474, December 1998 [Электронный ресурс]/K.
Nichols./ - Режим доступу до статті: http://www.ietf.org/rfc/rfc2474.txt
11. Internet Protocol, Version 6 (IPv6); RFC-1883, December
1995 [Електронний ресурс]/S. Deering, R.
Hinden./ - Режим доступу до статті:
http://www.ietf.org/rfc/rfc1883.txt
12. Internet Protocol, Version 6 (IPv6); RFC-2460, December 1998
[Електронний ресурс]/S. Deering, R.
Hinden./ - Режим доступу до статті: http://www.ietf.org/rfc/rfc2460.txt
Під час написання даного автореферату кваліфікаційна робота магістра ще не завершена. Дата остаточного завершення роботи: 1 грудня 2010 року. Повний текст роботи та матеріали по темі роботи можуть бути отримані у автора або його наукового керівника після зазначеної дати.
Автобіографія |