Современные аспекты IP-сетей

Требования к IP-сетям
Протокол IP является фактическим стандартом при построении корпоративных сетей передачи данных. На повестке дня — создание единых, "конвергированных" сетей, обеспечивающих передачу данных, голоса и видео.
К конвергенции подталкивают следующие обстоятельства:
• желание упростить и удешевить создание и эксплуатацию сетей, в которых нуждаются организации;
• стремление использовать для аудиопотоков более широкий набор типов среды передачи;
• стремление снизить стоимость телефонных переговоров, особенно международных (услуги современных сетей передачи данных обходятся дешевле, чем традиционный телефонный сервис);
• наличие в ряде организаций подключения к IP-сетям при отсутствии подключения к телефонной сети общего пользования.
Для достижения поставленных целей необходимо решить ряд проблем.
При транспортировке IP-пакетов их порядок, вообще говоря, может нарушаться, что недопустимо в случае передачи голосового потока данных. Помимо сохранения порядка, требуется также минимизировать задержки пакетов и колебания длительности задержек.
Для обеспечения приемлемого голосового потока время задержки должно составлять менее 300-600 мс.
Задержки могут возникать на следующих этапах:
• подготовка (кодирование и/или сжатие) и отправка голосового потока;
• передача по сети;
• декодирование на принимающей стороне.
Перечисленные этапы показаны на рисунке 1. При передаче аудиопотока необходимо контролировать величину задержки на каждом из них.

Пути изменения структуры и свойств IP-сетей
Ключевыми характеристиками сети при передаче аудио- и видеопотоков являются пропускная способность и качество сервиса.
Наращивание полосы пропускания может происходить за счет перехода на более высокоскоростные интерфейсы и/или технологии. Обычно такое решение является дорогостоящим, так как требует закупки нового сетевого оборудования. Кроме того, оно (решение), как правило, оказывается краткосрочным, поскольку расширенная полоса пропускания быстро "съедается" новыми сетевыми приложениями.
Поддержка механизмов QoS позволяет предоставлять ресурсы сети тем приложениям, которым они нужны в наибольшей степени. 
Например, можно резервировать определенную полосу пропускания под голосовые пакеты, а данным, менее критичным к задержкам (передача файлов по сети), назначать меньший приоритет.
Избежать заторов в IP-сетях, вызванных разнородным трафиком, можно лишь за счет дифференциации качества обслуживания.
Для реализации механизмов QoS в заголовке IP-пакета предусмотрено поле типа сервиса размером 8 бит (Type of Service, ToS, которое задает характер обработки пакета в процессе транспортировки последнего.
Можно управлять следующими параметрами:
• приоритет;
• величина задержек;
• уровень надежности;
• пропускная способность;
• надежность.
В большинстве случаев улучшение одного из перечисленных параметров связано с ухудшением других. На практике приходится делать выбор между малыми задержками, высокой пропускной способностью и высокой надежностью.
Распределение разрядов в поле типа сервиса представлено в табл. Таб. 1, а назначение различных комбинаций — в табл. Таб. 2.

Таблица 1. Распределение разрядов в поле типа сервиса IP-пакета.

Разряды	Назначение
0-2	Приоритет (Precedence)
3	Задержка (Delay)
4	Пропускная способность (Throughput)
5	Надежность (Reliability)
6-7	Зарезервировано

Таблица 2. Назначение различных комбинаций в поле типа сервиса IP-пакета.

Разряды	Значение	Описание
0-2	111	Управление сетью (Network Control)
	110	Межсетевое управление (Internetwork Control)
	101	CRITIC/ECP
	100	Быстрее, чем мгновенно (Flash Override)
	011	Мгновенно (Flash)
	010	Немедленно (Immediate)
	001	Приоритетно (Priority)
	000	Обычно (Routine)
3	1	Малая задержка
	0	Нормальная задержка
4	1	Высокая пропускная способность
	0	Нормальная пропускная способность
5	1	Высокая надежность
	0	Обычная надежность

Механизмы обеспечения качества сервиса
Качество сервиса в IP-сетях определяется следующими параметрами:
• готовность (service availability): надежность соединения пользователя с информационным сервисом;
• задержка (delay): интервал времени между отправлением и получением пакета;
• вариация задержки (delay variation): допустимый интервал между пакетами в потоке;
• пропускная способность (throughput): допустимая пиковая загруженность сети;
• коэффициент потери пакетов (packet loss rate).
Существуют следующие механизмы, используемые для обеспечения заданного качества сервиса в IP-сетях:
• механизмы классификации трафика в очереди обрабатываемых пакетов (выделения трафика, нуждающегося в определенном качестве сервиса, и его маркировка);
• механизмы управления очередями;
• механизмы фильтрации (продвижение приоритетного трафика в случае накопления его в очереди).
Существует две архитектуры IP-QoS, утвержденные комитетом IETF:
• архитектура с интеграцией сервисов (Integrated Service Architec-ture, Int-Serv);
• архитектура с дифференциацией сервисов (Differentiated Services Framework, Diff-Serv).

Архитектура QoS Int-Serv
В основе архитектуры Int-Serv лежит протокол резервирования ресурсов — RSVP (Resource ReSer-Vation Protocol). Данный протокол позволяет зарезервировать определенную долю сетевых ресурсов, необходимую информационному потоку, на протяжении всего маршрута от станции отправителя до станции получателя. Более подробное описание RSVP дается в следующем разделе. Здесь же мы ограничимся аналогией с коммутируемыми виртуальными соединениями ATM (ATM SVC).

Архитектура QoS Diff-Serv
Идея архитектуры с дифференциацией сервисов состоит в минимизации служебного трафика, чтобы исключить задержки, возникающие в Int-Serv на начальном этапе взаимодействия.
Архитектура с дифференциацией сервисов является прозрачной для приложений, здесь основная тяжесть реализации приходится на маршрутизаторы и коммутаторы поставщиков сетевых услуг.
Идея состоит в том, чтобы сформировать "облако", поддерживающее качество сервиса. Граничные маршрутизаторы по предопределенным правилам классифицируют входной трафик, маркируют его и передают транзитным устройствам для дальнейшего продвижения (см. рисунок 2). В результате однотипным приложениям соответствует одинаковый приоритет и обрабатываются соответствующие пакеты сходным образом.
Для маркировки пакетов используется поле типа сервиса (ToS), которое в данной архитектуре называется DS (Differentiated Services). Базируясь на значении поля DS, транзитный маршрутизатор помещает IP-пакет в очередь, соответствующую заданному приоритету. 
Движение внутри каждой очереди обеспечивается механизмом управления, ключевыми функциями которого являются распределение пропускной способности канала связи и правила обработки в случае накопления пакетов.
Архитектура с дифференциацией сервисов предлагает базовый уровень, обеспечивающий поддержку качества обслуживания, предоставляет гибкий механизм для разработчиков активного сетевого оборудования. Однако при использовании данной архитектуры возникают определенные сложности.
Каждый поставщик сетевых услуг обеспечивает качество сервиса в своей "зоне ответственности", однако нет гарантии, что поддержка окажется сквозной, как это имеет место в архитектуре с интеграцией сервисов.
Дифференциация сервисов — это относительно новый подход и далеко не все удалось стандартизовать. Основные проблемы состоят в отсутствии:
• стандарта на поле DS;
• утвержденного количества классов обслуживания и их описания;
• механизма эффективной агрегации потоков (на уровне транзитных маршрутизаторов);
• решений по интерпретации с технологией ATM;
• механизма управления.
Первые две позиции, может быть, не особенно критичны, но, конечно же, существует проблема согласования оборудования различных производителей.
Пункт три более критичен. Хотя на сегодня, исходя из статистики, количество IP-трафика, требующего определенного качества сервиса, составляет всего 5% от общего объема, легко прогнозировать значительное увеличение данной пропорции в связи с появлением новых интегрированных технологий и приложений.
По поводу пункта 4 отметим, что хотя вопросы обеспечения качества сервиса в ATM стандартизированы, вопрос трансляции IP QoS в ATM QoS остается открытым.
Отсутствие стандартных средств управления, несомненно, является критически важной проблемой.
Чтобы стать полноценной, общепризнанной архитектурой, дифференциации сервисов необходимо пройти достаточно долгий путь. Возможно, ей изначально уготована роль временного, частичного решения.

Протокол RSVP
Протокол резервирования ресурсов (RSVP — Resource ReSerVation Protocol) — это протокол "точка-точка". Подобно ICMP и IGMP, он является протоколом управления и функционирует в совокупности с протоколами маршрутизации.
Основными компонентами RSVP являются:
• отправитель;
• получатель;
• маршрутизаторы и хосты, находящиеся на пути от получателя к отправителю;
• потоки (совокупность IP-пакетов, посылаемых отправителем одному или более получателям, с соответствующим потоку идентификатором — FlowLabel).
В соответствии с протоколом RSVP, перед началом посылки потока IP-пакетов, требующего определенного качества сервиса, отправитель сообщает получателю о желании начать передачу и о необходимых параметрах качества (это сообщение называется PathMessage и содержит IP-адреса отправителя и получателя, а также информацию, характеризующую качество сервиса для потока и называемую FlowSpec).
В ответ получатель рассылает заявки на резервирование ресурсов всем узлам, находящимся на выбранном маршруте. Данная заявка содержит в себе, помимо IP-адреса отправителя и получателя, поля FlowSpec, AdmissionControl и PolicyControl. Поле Admission-Control содержит информацию о возможности отправителя предоставить требуемое качество сервиса, а поле PolicyControl характеризует права получателя на проведение операции резервирования QoS. Если оба поля (Admission Control и PolicyControl) установлены верно, узел, получающий данную заявку, резервирует требуемые ресурсы.
Если все узлы смогли зарезервировать ресурсы и заявка на резервирование дошла до отправителя, он начинает передачу потока.
В случае невозможности зарезервировать запрашиваемые ресурсы отправитель получает соответствующее уведомление. Если передачи потока не происходит, узел с зарезервированным качеством сервиса ждет фиксированное время, после чего освобождает ресурсы.
Таким образом, механизм RSVP выглядит следующим образом:
• отправитель посылает Path Message-сообщение получателю;
• получатель получает Path Message;
• получатель посылает заявку на резервирование QoS на маршрутизаторы между отправителем и получателем;
• каждый маршрутизатор, получив заявку, проверяет поля Admission Control и PolicyControl и в случае их достоверности резервирует требуемый QoS;
• отправитель получает уведомление о резервировании QoS;
• отправитель начинает передачу потока пакетов.
Рассмотрим пример (см. рисунок). Пусть станция-отправитель подключена по технологии Fast Ethernet (100 Мбит/с), получатель A — по технологии ATM (155 Мбит/с), получатель B — по технологии Token Ring (16 Мбит/с).
Допустим, требуемая полоса пропускания составляет 30 Мбит/с. В этом случае получатель A может запрашивать полную пропускную способность — 30 Мбит/с, а получатель B вынужден использовать сжатие данных, в результате чего экономится часть полосы пропускания. 
Передача между отправителем и получателями осуществляется до тех пор, пока выполняются характеристики QoS, заданные в поле FlowSpec.
Действия, выполняемые в рамках RSVP отправителем, получателем и промежуточными маршрутизаторами, показаны на рис. Рис. 4.
При использовании протокола RSVP особое внимание следует уделить следующим аспектам:

• Масштабируемость.Одновременная активность большого количества потоков с высокой пропускной способностью может вызвать перегрузку маршрутизаторов, что влечет блокировку или задержку передачи других критичных данных. Пока IETF не предлагает стандартных механизмов разрешения этой проблемы. Рекомендуется не использовать RSVP на магистральных маршрутизаторах (ограничиваясь периферией сети).

• Безопасность.Следующая сложность, связанная с использованием RSVP, — несанкционированный захват или сокрытие сетевых ресурсов. 
Такая ситуация возможна в случае, если злоумышленник прослушивает сеть с целью перехвата сообщений PathMessage. В IETF разрабатывается документ RSVP Cryptographic Authentication для обеспечения криптозащиты передаваемых служебных данных; в будущем он, вероятно, обеспечит кардинальное решение. 
Пока рекомендуется контролировать и протоколировать изменения в служебной информации, особое внимание уделяя полю FlowSpec.

Рис. 1. Основные этапы обработки потоков аудиоданных.

Рис. 2. Продвижение IP-трафика внутри зоны, поддерживающей качество сервиса.

Рис. 3. Конфигурация, на примере которой иллюстрируется работа протокола RSVP.

Рис. 4. Действия, выполняемые отправителем, получателем и промежуточными маршрутизаторами.

• Политика управления.Протокол RSVP предусматривает и описывает транспортную политику. В то же время в RSVP не описана политика управления. Не определены механизмы того, кто может (должен) осуществлять резервирование, а также средства проверки подлинности. 
Для решения данной проблемы в рамках комитета по RSVP создана специальная рабочая группа. Решение по поддержке политики безопасности подразумевает использование сервера авторизации, к которому осуществляются запросы при резервировании ресурсов на маршрутизаторе.