Механизмы повышения эффективности канала

В настоящее время программное обеспечение Cisco IOS предусматривает два механизма повышения эффективности канала: фрагментацию и чередование в канале (Link Fragmentation and Interleaving — LFI) и сжатие заголовков протокола реального времени (Real-Time Protocol Header Compression — RTP-HC), которые в сочетании с организацией очередей и формированием потоков повышают эффективность и предсказуемость служб уровня приложений.

LFI: фрагментация и чередование данных протокола IP

Интерактивные потоки данных (Telnet, Voice over IP и т.п.) чувствительны к повышению латентности и дребезжанию, которые возникают, когда сеть обрабатывает большие пакеты (например, при передаче данных по глобальному каналу между локальными сетями по протоколу FTP), особенно если они поставлены в очередь на медленном канале. Функция LFI операционной системы IOS Cisco сокращает задержку и уменьшает уровень дребезжания на медленных каналах путем разбиения (фрагментации) крупных дейтаграмм и чередования получившихся пакетов меньшего размера с пакетами с малой задержкой (рис. 59.11).

Рис. 59.11. Сокращение задержки на медленном канале путем разбиения крупных дейтаграмм посредством LFI

LFI был разработан специально для низкоскоростных каналов, где задержки фрагментации достаточно велики. На интерфейсе, в котором используется режим чередования, функционирование LFI требует установки многоканального протокола РРР. Проект IETF, называемый многоклассовым расширением многоканального РРР, (MultiClass extensions to MultiLink РРР — MCML) реализует практически те же самые функции как и LFI.

Следует обратить внимание на то, что для фрагментации в сети Frame Relay необходимо использовать функцию FRF.12, которая обеспечивает тот же результат.

Сжатие заголовков RTP: повышение эффективности при передаче данных реального времени

Транспортный протокол реального времени представляет собой протокол для передачи между узлами по IP-сетям данных современных мультимедийных приложений, в том числе пакетированных аудио- и видеоданных. Транспортный протокол реального времени обеспечивает сквозную передачу информации для приложений, требующих обмена данными в реальном времени, такой как аудио, видео и данные моделирования по одиночному адресу или по группе адресов. Благодаря сжатию заголовка протокола RTP повышается эффективность работы многих современных мультимедийных приложений и приложений VoIP, в особенности на медленных каналах. Схема сжатия заголовка протокола RTP показана на рис. 59.12.

Рис. 59.12 Сжатие заголовка транспортного протокола реального времени

RTP-пакет со сжатыми данными аудиоприложений имеет 40-байтовый заголовок и, как правило, от 20 до 150 байтов полезной нагрузки. Учитывая размер комбинированного заголовка 1P/UDP/RTP, неэффективно передавать несжатый заголовок. Сжатие заголовка RTP/UDP/IP с 40 до 2—5 байт обеспечивает более эффективную работу этого протокола, особенно на низкоскоростных каналах. Это особенно выгодно для небольших пакетов (таких, как данные VoIP) на медленных каналах (385 Кбит/с и ниже), в которых сжатие RTP-заголовка может значительно снизить объем управляющих сигналов и задержку при передаче. Сжатие заголовка протокола RTP также позволяет снизить удельный вес управляющих сигналов для мультимедийных данных протокола RTP и, соответственно, уменьшить задержку, особенно для пакетов небольшой (относительно заголовка) длины.

Сжатие RTP-заголовка поддерживается на последовательных каналах с помощью Frame Relay, протокола HDLC или инкапсуляции РРР. Его поддерживают также интерфейсы ISDN. Те же функции выполняет разработка IETF, называемая сжатым RTP (Compressed RTP — CRTP).

Протокол RSVP: гарантии QoS

RSVP представляет собой протокол Internet-стандарта IETF (RFC 2205), позволяющий приложению динамически резервировать полосу пропускания сети. Этот протокол дает приложениям возможность запросить качество обслуживания QoS для потока данных (рис. 59.13). В реализации Cisco протокол RSVP также может быть использован в сети с настроенным прокси-сервером RSVP. Таким образом, сетевые менеджеры имеют возможность использовать преимущества RSVP даже для тех приложений и узлов, которые не поддерживают протокол RSVP.

На узлах и маршрутизаторах RSVP применяется для доставки запросов QoS маршрутизаторам по маршруту передачи потока данных и для поддержания маршрутизатора и узла в состоянии, позволяющем обеспечивать требуемый уровень обслуживания — обычно полосу пропускания и задержку. Для определения резервируемой полосы пропускания RSVP использует информацию о средней скорости передачи данных, наибольшем количестве данных, которые маршрутизатор может держать в очереди, и минимальный уровень QoS.

Очередности WFQ или WRED выступают в качестве рабочего инструмента для RSVP, осуществляя классификацию и устанавливая расписание передачи пакетов для зарезервированных потоков. Используя очередность WFQ, протокол RSVP может предоставлять гарантированный набор интегрированных служб, в том числе службу управляемой нагрузки. Очередность WFQ по-прежнему управляет потоками данных, для которых резервирование не производится, ускоряя прохождение интерактивных данных и равномерно распределяя оставшуюся полосу пропускания между интенсивными потоками. Очередность WRED, соответственно, обслуживает потоки, не относящихся к RSVP. Протокол RSVP можно реализовать в существующих сетях путем обновления программного обеспечения.

Рис. 59.13. Работа протокола RSVP в сети с маршрутизаторами Cisco

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100