Построение коммутируемого маршрута по протоколу LDP

Построение коммутируемого маршрута по протоколу LDP

 

Рассмотрим, как система MPLS автоматически создает путь LSP в простейшем случае с помощью протокола LDP. Архитектура MPLS не требует обязательного применения LDP, однако, в отличие от других возможных вариантов, он наиболее близок к окончательной стандартизации.

Сначала посредством многоадресной рассылки сообщений UDP коммутирующие маршрутизаторы определяют свое «соседство» (adjacency) в рамках протокола LDP. Кроме близости на канальном уровне, LDP может устанавливать связь между «логически соседними» LSR, не принадлежащими к одному каналу. Это необходимо для реализации туннельной передачи. После того как соседство установлено, LDP открывает транспортное соединение между участниками сеанса поверх ТСР. По этому соединению передаются запросы на установку привязки и сама информация о привязке. Кроме того, участники сеанса периодически проверяют работоспособность друг друга, отправляя тестовые сообщения (keepalive message).

Рассмотрим на примере, как происходит заполнение таблиц меток по протоколу LDP (рис. 2.29). Предположим, что выбран упорядоченный режим распределения меток LSP со спонтанным распространением сведений о привязке.

 

Рис. 2.29. Заполнение таблиц меток по протоколу LDP

 

На стадии A каждое из устройств сети MPLS строит базу топологической информации, задействуя любой из современных протоколов маршрутизации (на схеме — OSPF). На стадии B маршрутизаторы LSR применяют процедуру нахождения соседних устройств и устанавливают с ними сеансы LDP.

Далее (стадия С) LSR 2 на основе анализа собственных таблиц маршрутизации обнаруживает, что он является выходным LSR для пути, ведущего к IP-сети 193.233.48.0. Тогда LSR 2 ассоциирует класс FEC с пакетами, адрес получателя которых соответствует префиксу данной сети, и присваивает этому классу случайное значение метки — в нашем случае 18. Получив привязку, протокол LDP уведомляет верхний маршрутизатор LSR (LSR 1) о том, что потоку, адресованному сети с префиксом 193.233.48, присвоена метка 18. LSR 1 помещает это значение в поле выходной метки своей таблицы.

На стадии D устройство LSR 1, которому известно значение метки для потока, адресованного на префикс 193.233.48, присваивает собственное значение метки данному FEC и уведомляет верхнего соседа (LSR 0) об этой привязке. Теперь LSR 0 записывает полученную информацию в свою таблицу. После завершения данного процесса все готово для передачи пакетов из сети «клиента» в сеть с адресом 193.233.48.0, т.е. по выбранному пути LSP.

Спецификация класса FEC может содержать несколько компонентов, каждый из которых определяет набор пакетов, соответствующих данному классу. На сегодняшний день определены два компонента FEC: адрес узла (host address) и адресный префикс (address prefix). Пакет классифицируется как принадлежащий к данному классу FEC, если адрес получателя точно совпадает с компонентом адреса узла либо имеет максимальное совпадение с адресным префиксом. В нашем примере узел LSR 0 выполняет в процессе передачи классификацию пакетов, поступающих к нему из сети клиента, и (если адрес получателя в них совпадает с префиксом 193.233.48), присвоив пакету метку 33, отправляет его через интерфейс 2.

 

Краткий глоссарий

BGP (Border Gateway Protocol) — граничный шлюзовой протокол. Разновидность протокола маршрутизации между автономными системами.

CBWFQ (Class Based WFQ) — технология WFQ, действие которой распространяется на несколько классов трафика с совместным доступом к ресурсам.

FEC (Forwarding Equivalence Class) — класс эквивалентности при передаче. Класс пакетов сетевого уровня, которые получают от сети MPLS одинаковое обслуживание как при выборе LSP, так и с точки зрения доступа к ресурсам.

IETF (Internet Engineering Task Force) — рабочая группа инженеров по Internet. Организация, отвечающая за разработку протоколов сети Internet.

IS-IS (Intermediate System-to-Intermediate System) — «промежуточная система—промежуточная система». Разновидность протокола маршрутизации внутри автономной системы.

LDP (Label Distribution Protocol) — протокол распределения информации о привязке меток к FEC.

LSP (Label Switching Path) — путь коммутации по меткам.

LSR (Label Switching Router) — узел сети MPLS, участвующий в реализации алгоритма маршрутизации и выполняющий коммутацию по меткам.

MPLS (MultiProtocol Label Switching) — многопротокольная коммутация по меткам.

OSPF (Open Shortest Path First) — «первым выбирается кратчайший путь». Разновидность протокола маршрутизации внутри автономной системы.

QoS (Quality of Service) — качество сервиса. Набор параметров, описывающих свойства потока и гарантированный уровень сетевого обслуживания.

RSVP (Resource Reservation Protocol) — протокол резервирования ресурсов в IP-сетях.

VCI (Virtual Circuit Identifier) — идентификатор виртуального канала. Пара VPI/VCI в заголовке АТМ-ячейки определяет соединение (маршрут) в сети АТМ.

VPI (Virtual Path Identifier) — идентификатор виртуального пути. Совместно с VCI определяет соединение в сети АТМ.

WFQ (Weighted Fair Queing) — взвешенное недискриминационное распределение по очереди. Технология управления буферизацией и обслуживанием потоков, способствующая предотвращению перегрузок.

WRED (Weighted Random Early Detection) — взвешенное случайное раннее обнаружение. Вероятностный алгоритм управления очередью, который сохраняет среднюю длину очереди малой за счет раннего уведомления адаптивного транспортного протокола о приближении перегрузки.

 

 

Общие сведения

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

Поскольку IP-телефония претендует на роль конкурента традиционной телефонной связи, она должна гарантировать пользователю некий уровень качества обслуживания (QoS), сравнимый с ТфОП.

Основными составляющими качества IP -телефонии являются (рис. 4.1):

1.. Качество речи, включающее:

• диалог - возможность пользователя связываться и разговаривать с другим пользователем в реальном времени и полнодуплексном режиме;

• разборчивость и узнаваемость - чистота и тональность речи;

• наличие эхосигнала - слышимость собственной речи с задержкой;

• громкость - громкость речи.

2. Качество сигнализации, включающее:

• время установление соединения - скорость успешного доступа и

времяустановления соединения;

• время завершение соединения - время отбоя и скорость разъединения.
Факторы, которые влияют на качество IP-телефонии, могут быть разделены на две категории:

1. Факторы качества IP-сети:

■ максимальная пропускная способность - максимальное количество полезных и избыточных данных, которая она передает;

■ задержка на передачу - промежуток времени, требуемый для передачи пакета через сеть;

■ вариация задержки - задержка между двумя последовательными пакетами;

■ потеря пакета - пакеты или данные, потерянные при передаче через сеть.

2. Факторы качества шлюза:

■ требуемая полоса пропускания - различные вокодеры требуют

различную полосу.

Например, вокодер G.723 требует полосы 16,3 кбит/с для каждого

речевого канала;
задержка на обработку - время, необходимое цифровому сигнальному
процессору DSP или другим устройствам обработки для кодирования и

декодирования речевого сигнала;

буфер для устранения вариации задержки - сохранение пакетов даны

до тех пор, пока все пакеты не будут получены и можно будет передавать

их в требуемой последовательности для минимизации джиггера;

потеря пакетов - потеря пакетов при сжатии и/или передаче

в оборудовании 1Р-телефонии;

степень подавления эха - механизм для подавления эха, возникающего при

передаче по сети;

управление уровнем - возможность регулировать громкость речи.

 

Задержка

 

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

Можно выделить следующие составляющие задержки при пакетной передачи речи из конца в конец:

1. Задержка накопления (иногда называется алгоритмической задержкой). Эта

задержка обусловлена необходимостью сбора кадра речевых отсчетов,

выполняемая в речевом кодере. Величина задержки определяется типом

речевого кодера и изменяется от небольших величин (0,125 мкс) до

нескольких миллисекунд. Например, стандартные речевые кодеры имеют

следующие длительности кадров:

G.729 CS-ACELP (8 кбит/с) - 10 мс

G.723.1 - Multi Rate Coder (5.3, 6.3 кбит/с) - 30 мс.

2. Задержка обработки. Процесс кодирования и сбора закодированных отсчетов в пакеты для передачи через пакетную сеть создает определенные

задержки. Задержка кодирования или обработки зависит от времени работы

процессора и используемого типа алгоритма обработки.

 

Качество передачи речи

• Диалог

• Разборчивость и узнаваемость

• Наличие эхосигнала

• Громкость

Качество передачи сигнализации

• Время установления соединения

• Время завершения соединения

 

Качество шлюза

Качество сети

 

Задержка на обработку Буфер для устранения вариации задержки Степень подавления эха Управление уровнем

Максимальное пропускная способность

Задержка на передачу Вариация задержки Потеря пакетов

 

Рис. 4.1. Факторы, влияющие на качество IP-телефонии

 

Для уменьшения загрузки пакетной сети обычно несколько кадров речевого кодера объединяются в один пакет. Например, три кадра кодовых слов G.729, соответствующих 30 мс речи, могут быть объединены для уменьшения размера одного пакета.

3. Сетевая задержка. Задержка обусловлена физической средой и протоколами, используемыми для передачи речевых данных, а также буферами, используемыми для удаления джиттера пакетов на приемном конце.

Сетевая задержка зависит от емкости сети и процессов передачи пакетов в сети.

Время задержки при передаче речевого сигнала можно отнести к одному из

трех уровней:

• до 200 мс (первый уровень) - отличное качество связи. Для сравнения, в телефонной сети общего пользования допустимы задержки до 150-200 мс;

• до 400 мс (второй уровень) - считается хорошим качеством связи, но если сравнивать с качеством связи по сетям ТфОП, то разница будет видна. Если задержка постоянно удерживается на верхней границе этого уровня (на 400 мс), то не рекомендуется использовать эту связь для деловых переговоров:

• до 700 мс (третий уровень) - считается приемлемым качеством связи для ведения неделовых переговоров. Такое качество связи возможно также при передаче пакетов по спутниковой связи.

 

Джиттер

В случае разбивки речи или данных на пакеты для передачи через IP-сеть, пакеты часто прибывают в пункт назначения в различное время и в разной последовательности. Это создает разброс времени доставки пакетов (джиттер ). Джиттер приводит к специфическим нарушениям передачи речи, слышимым как трески и щелчки.

Возникает необходимость организации буфера для превращения пакетной речи, отягощенной нестационарными задержками в канале, возможными переста­новками пакетов, в непрерывный естественный речевой сигнал реального времени. Параметры буфера определяются компромиссом между величиной запаздывания телефонного сигнала в режиме дуплексной связи и процентом потерянных пакетов.

 

Потеря пакетов

 

Потерянные пакеты в IP-телефонии нарушают речь и создают искажения тембра. В существующих IP-сетях все голосовые кадры обрабатываются как данные. При пиковых нагрузках и перегрузках голосовые кадры будут отбрасываться, как и кадры данных. Однако ю очередь, не может быть восполнена таким способом и в результате пкадры данных не связаны со временем, и отброшенные пакеты могут быть успешно переданы путем повторения. Потеря голосовых пакетов в свороизойдет неполная передача информации. Предполагается, что потеря до 5% пакетов незаметна, а свыше 10-15% недопустима. Причем данные величины существенно зависят от алгоритмов компрессии/декомпрессии.

Наиболее вероятны потери одного, двух и трех пакетов подряд. Потери больших пачек пакетов редки. Существенно, что потеря большой группы пакетов приводит к необратимым локальным искажениям речи, тогда как потери одного, двух, трех пакетов можно пытаться компенсировать.

 

RSVP

 

Для обеспечения должного качества обслуживания трафика речевых и

видеоприложений, необходим механизм, позволяющий приложениям информировать сеть о своих требованиях. На основе этой информации сеть может резервировать ресурсы для того, чтобы гарантировать выполнение требований к качеству или отказать приложению, вынуждая его либо пересмотреть требования, либо отложить сеанс связи. В роли такого механизма выступает протокол резервирования ресурсов (Resource Reservation Protocol, RSVP), рекомендованный комитетом IETF. С помощью RSVP мультимедиа-программы могут потребовать специального качества обслуживания (specific quality of service, QoS) посредством любого из существующих сетевых протоколов, чтобы обеспечить качественную передачу видео- и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

Используя RSVP, отправитель посылает получателю сообщение RSVP Path, в котором указывает желательные характеристики качества обслуживания трафика - верхнюю и нижнюю границы полосы пропускания, величину задержки и вариации задержки (рис. 2.3). Каждый транзитный маршрутизатор, получив сообщение RSVP Path, фиксирует адрес предыдущего маршрутизатора. Таким образом, в сети образуется фиксированный маршрут.

Приняв сообщение RSVP Path, его получатель передаёт к маршрутизатору, от которого пришло это сообщение, запрос резервирования ресурсов - сообщение RSVP Resv. При чтении этого сообщения каждый транзитный маршрутизатор определяет, приемлем ли этот запрос. Если запрос не может быть удовлетворён, то маршрутизатор отвечает на него сообщением об ошибке. Если же ресурсов достаточно, то отправитель начинает передачу.

RSVP Path

Получатель

Отправитель

RSVP Resv

 

 

 

Рис. 4.3. Применение протокола RSVP

 

 

Когда RSVP-программы закончат сеанс связи, они должны вызвать функцию отмены, предусмотренную этим протоколом. Отмена аннулирует все запросы на ресурсы, сделанные программой, и позволяет другим прикладным программам использовать коммуникационные возможности Internet. Если программе не удается выполнить отмену, то предусмотренные протоколом средства по истечении некоторого промежутка времени обнаружат это и автома­тически отменят запрос на ресурсы.

Недостатком протокола RSVP является то, что полоса пропускания, выделяемая источнику информации, при снижении активности источника не может быть использована для передачи другой информации. Поскольку для реализации QoS протокол RSVP требует резервирования ресурсов, некоторые пользователи могут захватить ресурсы сети, инициируя несколько сеансов QoS подряд. Как только канал зарезервирован, он становится недоступным для других пользователей, даже если тот, кто его затребовал, ничего не передает. К сожалению, в RSVP отсутствует четкий механизм предотвращения подобных ошибок, и решение этой проблемы возлагается на сетевых администраторов. Очевидно, что необходимо предусмотреть более жесткий контроль, чтобы RSVP имел успех. Ввиду зависимости RSVP от совместимости промежуточных узлов (в большинстве случаев маршрутизаторов), то это влечет за собой неизбежные проблемы, в частности, в глобальных сетях. Если какой-либо маршрутизатор достиг предела своих возможностей, когда он не может гарантировать запрошенный уровень QoS, все последующие запросы будут игнорироваться и удаляться. При отказе только одного узла обслуживать запрос вся стройная система RSVP распадается на части. RSVP имеет весьма хорошие перспективы на корпоративном уровне, где адмннистратор имеет возможность определить, какие параметры маршрутизатор будет использовать для обслуживания запросов о предоставлении QoS. В глобальных сетях маршрутизаторы вовсе не обязательно находятся под той же юрисдикцией, что и хосты и приложения, производящие запросы, что осложняет

гарантирование QoS.

 

RTP и RTCP

 

Для уменьшения значений джиттера и задержек на сетевом уровне применяются гарантирующие пользователю заданный уровень качества механизмы RSVP, MPLS, DiffServ и др. Они улучшают качество услуг, управляемых сетью, но не могут полностью устранить образование очередей в сетевых устройствах, а, следовательно, и совсем убрать джиттер. Компенсировать его негативное влияние позволяет разработанный IETF протокол прикладного уровня RTP (Real-time Transport Protocol).

Протокол RTP (RFC 1889) предназначен для доставки чувствительной к задержкам информации с использованием сетевых служб одноадресной или групповой рассылки. Он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг. Это осуществляют нижележащие протоколы. Он даже не обеспечивает все те функции, которые обычно предоставляют транспортные протоколы, в частности, функции по исправлению ошибок или управлению потоком. Обычно RTP работает поверх UDP и использует его службы, но может функционировать и поверх других транспортных протоколов. Служба RTP предусматривает указание типа полезной нагрузки и последовательного номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, а получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке пакетов позволяет определить джиттер и смягчить его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой.

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

Возможности RTP можно расширить, объединив его с еще одним
протоколом IETF, а именно с протоколом управления передачей в реальном
времени (Real-time Transport Control Protocol, RTCP). С помощью RTCP
контролируется доставка RTP-пакетов и обеспечивается обратная связь с
передающей стороной и другими участниками сеанса. RTCP периодически
рассылает свои управляющие пакеты, используя тот же механизм распределения, какой применяется и для RTP-пакетов с пользовательской информацией.
Основной функцией RTCP является организация обратной связи с приложением для отчета о качестве получаемой информации. RTCP передает сведения (как от приемника, так и от отправителя) о числе переданных и потерянных пакетов, значении джиттера, задержке и т.д. Эта информация может быть использована отправителем для изменения параметров передачи, например, для уменьшения коэффициента сжатия информации с идентификацию пользователей-участников сеанса.

При всех своих достоинствах протокол RTP далеко не совершенен. Например, протокол никак не способен повлиять на задержку в сети, но он помогает сократить дрожание звука при воспроизведении при наличии задержек. Кроме того, хотя пакеты UDP и получают порядковые номера, но при установлении принимающей станцией факта потери пакета RTP не предпринимает никаких мер для его восстановления.

Один из способов расширения возможностей RTP состоит в использовании его совместно с протоколом RSVP.

 

Построение коммутируемого маршрута по протоколу LDP

 

Рассмотрим, как система MPLS автоматически создает путь LSP в простейшем случае с помощью протокола LDP. Архитектура MPLS не требует обязательного применения LDP, однако, в отличие от других возможных вариантов, он наиболее близок к окончательной стандартизации.

Сначала посредством многоадресной рассылки сообщений UDP коммутирующие маршрутизаторы определяют свое «соседство» (adjacency) в рамках протокола LDP. Кроме близости на канальном уровне, LDP может устанавливать связь между «логически соседними» LSR, не принадлежащими к одному каналу. Это необходимо для реализации туннельной передачи. После того как соседство установлено, LDP открывает транспортное соединение между участниками сеанса поверх ТСР. По этому соединению передаются запросы на установку привязки и сама информация о привязке. Кроме того, участники сеанса периодически проверяют работоспособность друг друга, отправляя тестовые сообщения (keepalive message).

Рассмотрим на примере, как происходит заполнение таблиц меток по протоколу LDP (рис. 2.29). Предположим, что выбран упорядоченный режим распределения меток LSP со спонтанным распространением сведений о привязке.

 

Рис. 2.29. Заполнение таблиц меток по протоколу LDP

 

На стадии A каждое из устройств сети MPLS строит базу топологической информации, задействуя любой из современных протоколов маршрутизации (на схеме — OSPF). На стадии B маршрутизаторы LSR применяют процедуру нахождения соседних устройств и устанавливают с ними сеансы LDP.

Далее (стадия С) LSR 2 на основе анализа собственных таблиц маршрутизации обнаруживает, что он является выходным LSR для пути, ведущего к IP-сети 193.233.48.0. Тогда LSR 2 ассоциирует класс FEC с пакетами, адрес получателя которых соответствует префиксу данной сети, и присваивает этому классу случайное значение метки — в нашем случае 18. Получив привязку, протокол LDP уведомляет верхний маршрутизатор LSR (LSR 1) о том, что потоку, адресованному сети с префиксом 193.233.48, присвоена метка 18. LSR 1 помещает это значение в поле выходной метки своей таблицы.

На стадии D устройство LSR 1, которому известно значение метки для потока, адресованного на префикс 193.233.48, присваивает собственное значение метки данному FEC и уведомляет верхнего соседа (LSR 0) об этой привязке. Теперь LSR 0 записывает полученную информацию в свою таблицу. После завершения данного процесса все готово для передачи пакетов из сети «клиента» в сеть с адресом 193.233.48.0, т.е. по выбранному пути LSP.

Спецификация класса FEC может содержать несколько компонентов, каждый из которых определяет набор пакетов, соответствующих данному классу. На сегодняшний день определены два компонента FEC: адрес узла (host address) и адресный префикс (address prefix). Пакет классифицируется как принадлежащий к данному классу FEC, если адрес получателя точно совпадает с компонентом адреса узла либо имеет максимальное совпадение с адресным префиксом. В нашем примере узел LSR 0 выполняет в процессе передачи классификацию пакетов, поступающих к нему из сети клиента, и (если адрес получателя в них совпадает с префиксом 193.233.48), присвоив пакету метку 33, отправляет его через интерфейс 2.

 

Краткий глоссарий

BGP (Border Gateway Protocol) — граничный шлюзовой протокол. Разновидность протокола маршрутизации между автономными системами.

CBWFQ (Class Based WFQ) — технология WFQ, действие которой распространяется на несколько классов трафика с совместным доступом к ресурсам.

FEC (Forwarding Equivalence Class) — класс эквивалентности при передаче. Класс пакетов сетевого уровня, которые получают от сети MPLS одинаковое обслуживание как при выборе LSP, так и с точки зрения доступа к ресурсам.

IETF (Internet Engineering Task Force) — рабочая группа инженеров по Internet. Организация, отвечающая за разработку протоколов сети Internet.

IS-IS (Intermediate System-to-Intermediate System) — «промежуточная система—промежуточная система». Разновидность протокола маршрутизации внутри автономной системы.

LDP (Label Distribution Protocol) — протокол распределения информации о привязке меток к FEC.

LSP (Label Switching Path) — путь коммутации по меткам.

LSR (Label Switching Router) — узел сети MPLS, участвующий в реализации алгоритма маршрутизации и выполняющий коммутацию по меткам.

MPLS (MultiProtocol Label Switching) — многопротокольная коммутация по меткам.

OSPF (Open Shortest Path First) — «первым выбирается кратчайший путь». Разновидность протокола маршрутизации внутри автономной системы.

QoS (Quality of Service) — качество сервиса. Набор параметров, описывающих свойства потока и гарантированный уровень сетевого обслуживания.

RSVP (Resource Reservation Protocol) — протокол резервирования ресурсов в IP-сетях.

VCI (Virtual Circuit Identifier) — идентификатор виртуального канала. Пара VPI/VCI в заголовке АТМ-ячейки определяет соединение (маршрут) в сети АТМ.

VPI (Virtual Path Identifier) — идентификатор виртуального пути. Совместно с VCI определяет соединение в сети АТМ.

WFQ (Weighted Fair Queing) — взвешенное недискриминационное распределение по очереди. Технология управления буферизацией и обслуживанием потоков, способствующая предотвращению перегрузок.

WRED (Weighted Random Early Detection) — взвешенное случайное раннее обнаружение. Вероятностный алгоритм управления очередью, который сохраняет среднюю длину очереди малой за счет раннего уведомления адаптивного транспортного протокола о приближении перегрузки.