Основні параметри якості зв'язку

Основные параметры, которые непосредственно влияют на методы оценки качества следующие:

- параметры каналов связи.

Существует три параметра канала связи, которые считаются основными, они влияют на качество IP-телефонии:

· уровень искажения голоса;

· частота пропадания голосовых пакетов;

· время задержки (между произнесением фразы первого абонента и моментом, когда она будет услышана вторым абонентом).

- используемый кодек.

- отсутствие либо наличие эха.

Все кодеки, которые на сегодняшний день используются в IP-телефонии, дают сжатие с потерями. На слух эти потери могут быть различимы по разному, все зависит от алгоритмов, которые используются, именно в этом ключе анализируется, насколько кодеки влияют на качество речи.

Проблеми з якістю зв'язку

Качество связи напрямую зависит от загруженности интернет канала, что в свою очередь может отразиться на воспроизведении звукового сигнала. В случае если линия сильно перегружена, то некоторые пакеты могут приходить с опозданием, а это может привести к задержке звука или вовсе к потере некоторых данных.

Пока еще достаточно слабо развита система защиты данных и конфиденциальной информации (разговоров) при использовании ip-телефонии. Интернет-сети переживают dos-атаки, нападения спамеров, заражения вирусами. Это приводит иногда к многочасовым перерывам в поддержке пользователей и создает неудобства.

Принцип функціонування QoS

- Для приймання і відправлення пакетів на маршрутизаторах у найпростішому випадку застосовують метод FIFO: перший прийшов — перший пішов (First In — First Out)

- Коли спостерігається перевантаження мережі – на маршрутизаторах утворюються затори, які розв’язують найпростішим чином

o Усі пакети, що не ввійшли до буферу черги FIFO (як на вході, так і на виході), ігноруються маршрутизатором, тобто просто втрачаються

- Більш досконалий метод — застосовувати «розумну» чергу, в якій пріоритет пакетів залежить від типу сервісу — ToS

o Для створення «розумної» черги пакети повинні заздалегідь отримати мітки типу сервісу

Протоколи, що надають послугу QoS

- Поле ToS у заголовку IPv4

- IP Differentiated services (DiffServ)

- IP Integrated services (IntServ)

- Resource reSerVation Protocol (RSVP)

- Multiprotocol Label Switching (MPLS)

- RSVP-TE (Traffic Engineering)

- Frame relay

- X.25

- Asynchronous Transfer Mode (ATM)

- IEEE 802.1p/Q

- IEEE 802.11e

- IEEE 802.11p

Моделі QoS. Негарантована доставка – Best Effort Service

Існує 3 моделі QoS:

1 Негарантована доставка — Best Effort Service

2 Інтегрований сервіс — Integrated Service (IntServ)

3 Диференційоване обслуговування — Differentiated Service (DiffServ)

Негарантована доставка — Best Effort Service

Наявність ToS Best Effort Service не є механізмом тонкого регулювання і є ознакою простого збільшення перепускної спроможності без виділення окремих класів трафіку

Інтегрований сервіс — Integrated Service (IntServ)

- Згідно RFC 1633, модель інтегрованого обслуговування забезпечує наскрізну (End-to-End) якість обслуговування, гарантуючи необхідну перепускну спроможність

- IntServ використовує протокол резервування мережних ресурсів RSVP, що забезпечує виконання вимог до всіх транзитних вузлів

- Стосовно IntServ часто застосовують термін «резервування ресурсів» (Resource reservation)

 

Протокол RSVP

RSVP - протокол резервування мережевих ресурсів (Resource ReSerVation Protocol) (RFC 2205).

З метою повідомлення маршрутизаторам мережі потреб кінцевих вузлів за якістю обслуговування потоків використовується додатковий протокол - RSVP.

Працює він таким чином: вузол-джерело до передачі даних, що вимагають певного нестандартного якості обслуговування (наприклад, постійної смуги пропускання для передачі відеоінформації), посилає по мережі спеціальне повідомлення у форматі протоколу RSVP. Це повідомлення про шляху (path message) містить дані про тип переданої інформації і необхідної пропускної спроможності. Воно передається між маршрутизаторами по всьому шляху від вузла-відправника до адреси призначення, при цьому визначається послідовність маршрутизаторів, в яких необхідно зарезервувати певну смугу пропускання.

Маршрутизатор, одержавши таке повідомлення, перевіряє свої ресурси з метою визначення можливості виділення необхідної пропускної спроможності. При її відсутності маршрутизатор запит відкидає. Якщо необхідна пропускна здатність досяжна, то маршрутизатор налаштовує алгоритм обробки пакетів таким чином, щоб вказаною потоку завжди надавалася необхідна пропускна здатність, а потім передає повідомлення наступному маршрутизатору вздовж шляху. В результаті, по всьому шляху від вузла-відправника до адреси призначення резервується необхідна пропускна здатність з метою забезпечення запитуваної якості обслуговування.

Протокол RSVP, крім використання для сигналізації вимог до якості обслуговування (архітектура QoS IntServ), використовується також для сигналізації MPLS TE LSP (MultiProtocol Label Switching Traffic Engineering Label-Switched Path). Для сигналізації MPLS TE LSP використовується модифікована версія протоколу - RSVP-TE (RFC 3209, RFC 5420).

Протокол RSVP три види трафіку

- Best-effort

o Традиційний IP трафік

- Rate-sensitive

o Вимагає гарантованої швидкості передавання

- Delay-sensitive

o Трафік, чутливий до затримки

 

Диференційоване обслуговування — Differentiated Service (DiffServ)

- Описане в RFC 2474 и RFC 2475

- Забезпечує QoS на основі розподілу ресурсів всередині мережі і певних класифікаторів і обмежень на межі мережі

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

- DiffServ складається з:

o керування формуванням трафіку (класифікація пакетів, маркування, керування інтенсивністю

o керування політикою (розподіл ресурсів, політика відкидання пакетів)

 

Механізми керування трафіком (Leaky bucket, Token bucket, TCP rate control

- Формування трафіку (traffic shaping, rate limiting):

o Leaky bucket (відро, що протікає)

o Token bucket (іноді помилково ототожнюють з алгоритмом leaky bucket)

o TCP rate control (керування швидкістю ТСР) — штучне регулювання розміру вікна TCP разом з керуванням темпу повернення квитанцій ACK відправнику

v нижче наведені ще 2 механізми (вони непотрібні, але може хтось захоче «блєснути умом» xD)

- Алгоритми планування (Scheduling algorithms):

- Запобігання перевантаженню (Congestion avoidance):

Алгоритм Leaky Bucket

- Відро, що протікає, в якості вимірювача (meter)

Алгоритм:

o З кожним користувачем, що передає пакети, асоціюють лічильник.

o Лічильник збільшують, коли користувач надсилає пакет, і зменшують періодично (через рівні проміжки часу)

o Якщо лічильник перебільшує встановлену межу, пакет вважають таким, що не відповідає вимогам (non-conformant)

o Користувач встановлює темп зменшення лічильника (що задає середню перепускну спроможність) і межу (міру сплесків)

Пакети фактично через “відро” не проходять, його застосовують лише для визначення, чи є трафік дозволеним

- Відро, що протікає, в якості черги (queue)

Алгоритм:

o Існує черга заданої довжини

o Коли надходить пакет, якщо у черзі є достатнє місце для нього, його додають у чергу, якщо ж немає – його відкидають

o Через рівні проміжки часу один пакет відправляють у мережу (якщо черга не порожня)

Таким чином, “відро” формує рівномірний трафік

 

Алгоритм Token bucket

Алгоритм:

o Через рівні проміжки часу у відро кладуть один маркер

o Відро може утримувати певну кількість маркерів. Якщо маркер надходить коли відро повне, його ігнорують

o Коли надходить пакет розміром в n байт, n маркерів забирають з відра, а пакет надсилають у мережу

o Якщо у відрі менше, ніж n маркерів, з відра нічого не забирають, а пакет вважають таким, що не відповідає вимогам (non-conformant)

Легко бачити, що алгоритм Token Bucket еквівалентний алгоритму Leaky Bucket as a meter

Точніше, ці два алгоритми є дзеркальним відображенням один одного, але вони дають тотожні результати щодо визначення відповідності трафіку