Previous: 4.4.16 Протокол SNTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет
    Next: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

1. Базовые предпосылки

Интернет – это система взаимодействия удаленных программ. Совместимость этих программ гарантируется тем, что они следуют определенным регламентациям (протоколам). Управление трафиком представляет собой проблему, ставшую актуальной за последние несколько лет (если не считать составляющую, сопряженную с управлением перегрузкой).

Период экстенсивного развития сети Интернет завершился несколько лет тому назад даже в РФ. Сейчас многие сервис-провайдеры пытаются привлечь клиентов дополнительными информационными услугами IP-телефония, интерактивные игры, доступ к разнообразным базам данных и депозитариям, электронным магазинам, видеоконференции, видео-телефония и т. д. Клиенты же ищут не просто доступа к Интернет, а интересуются полосой пропускания, безопасностью, стабильностью связи. Именно с этим сопряжен бум разработок основополагающих документов (RFC) в последние 5 лет. По этой причине многие компании, в первую очередь производящие сетевое оборудование, уделяют повышенное внимание средствам управления трафиком (ТЕ) и QoS.

Если рассмотреть ситуацию на уровне L2, здесь имеется сильная зависимость от физического уровня (L1). В сетях с маркерным доступом (Token Ring или FDDI, см. book.itep.ru) существуют механизмы управления приоритетом и способы контроля доступа, гарантирующие определенное значение задержек сетевого отклика. В сетях ISDN и в особенности в ATM предусмотрен целый арсенал средств управления, работающих на фазе установления виртуального канала (процедура SETUP). Для Ethernet до последнего времени ситуация была много хуже. Здесь только некоторые переключатели поддерживают VLAN. Технология виртуальных сетей L2 позволяет сформировать в локальной сети соединение точка-точка. В таком соединении можно гарантировать пропускную способность на уровне 10/100Мбит/c. К сожалению VLAN L2 создаются и модифицируются, как правило администратором, но можно эту проблему перепоручить сценарию, например, на PERL, работающему с демоном SNMP сетевого прибора. В такой сети можно также гарантировать низкий уровень разброса времени реакции сети. Если сформировать VLAN с числом узлов (N) больше двух, можно гарантировать полосу лишь не ниже (10/100)/N. Для произвольной сети Ethernet никаких гарантий на уровне L2 предоставить нельзя. Здесь можно рассчитывать только на вышележащие уровни (IP/TCP/UDP).

Принципы организации приоритетного трафика на уровне L2 рассмотрены в стандарте 802.1р. Стандарт 802.1р является частью стандарта 802.1D (мостовые соединения). В протоколе 802.1Q определена 4-байта метки (смотри рис.1). Поле EtherType=TPID (Tagged Protocol Identifier) содержит код 0x8100. Это поле соотвествует полю тип протокола стандартного поля кадра Ethernet и указывает на необходимость обработки кадра согласно требованиям IEEE 802.1Q. Смотри grouper.ieee.org/groups/802/1/pages/802.1v.html.

Рис. 1. Формат меток VLAN на уровне L2 (стандарт 802.1р).

Поле приоритета пользователя - 3 бита, 1-битовое поле CFI (Canonical Format Identifier) и 12-битовое поле VID (идентификатор виртуальной сети) называются TCI (Tagged Control Information). 3-битовое поле IP-приоритета размещается здесь без проблем. После введения метки в кадр нужно персчитать контрольную сумму FCS. Канальный уровень в этом случае должен поддерживать множественные очереди. Добавление метки может привести к превышению предельно допустимой длины кадра (1518 байт). В этой связи IEEE разрабатывает спецификацию 802.3ас, где максимальная длина кадра равна 1522 октета. Группа IETF, разрабатывающая систему обеспечения требуемого уровня услуг на специфических нижних уровнях ISSLL (Integrated Services over Specific Lower Layers), предлагает способы отображения запросов протокола резервирования уровня L3 (RSVP) на 802.1р с помощью системы управления полосой пропускания субсети SBM (Subnet Bandwidth Manager). Смотри http://www.ietf.org/html.charters/issll-charter.html. Протокол SBM предполагает, что одна из станций в субсети выполняет функцию DSBM (Designated SBM), и осуществляет управление доступом для всех запросов на резервирование ресурсов, посылаемых DSBM-клиентами. При работе протокола SBM используются мультикатсинг-адреса 224.0.0.17 (все станции прослушивают этот адрес), а DSBM-кандидаты прослушивают - 224.0.0.16. Данная технология может использоваться, например, в IP-телефонии (TDMoIP - Time Division Multiplexing over IP)). В этом случае UDP-порт отправителя может быть равен 2-497d, а порт получателя = 2142.

Топология связей в локальной сети на уровне L3 определяется протоколами маршрутизации (статическими или динамическими – RIP, OSPF, IGRP). В последнее время поставщики сетевого оборудования стали предлагать устройства уровня L2, способные осуществлять отбор пакетов на уровне L3 и даже L4 (TCP/UDP). В принципе ничто не мешает создать сетевые переключатели уровня L2, способные гарантировать пропускную способность, минимизировать вероятность потери пакета и т.д.

Любые способы управления трафиком на уровне L3 для сетей, работающих в рамках стека протоколов TCP/IP, в настоящее время базируются на возможностях этих транспортных протоколов (IP, UDP, TCP).

Протокол (см. IP) предусматривает задание значение ToS, определяемое соответствующим полем заголовка. Одно-октетное поле тип сервиса (TOS - Type Of характеризует то, как должна обрабатываться дейтограмма.

Субполе приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).

0          Обычный уровень
1          Приоритетный
2          Немедленный
3          Срочный
4          Экстренный
5          CEITIC/ECP
6          Межсетевое управление
7          Сетевое управление

В новейших разработках (RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) поле TOS заменено на поле DSCP (Differentiated Services Code Point), где младшие 6 бит выделены для кода DS (Differentiated Services), а старшие два бита пока не определены и их следует обнулять.

До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 2. Биты CU пока не определены. Иногда это поле называется байтом DS (Differenttiated Services).

Рис. 2. Формат поля DSCP.

Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.

На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

В маршрутизаторах компании CISCO Systems для классификации пакетов и выбора очередей используются два младших бита из трех. По умолчанию классу 0 выделяется 10% полосы, а классам 1, 2 и 3 – 20%, 30% и 40%, соответственно. Для очередей, основанных на классах QoS, пакеты, не принадлежащие ни одной группе, относятся к группе 0 и автоматически получают 1% от общей пропускной способности группы. Общий вес остальных групп не может превышать 99%. При наличии нераспределенной полосы, она относится к группе 0.

В протоколе IPv6 поле приоритет имеет 4 бита (см. IPv6). Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. В таблице 1 приведены стандартизованные значения поля Type of Service (TOS) IP-пакета.

Таблица .1.  Значения TOS для разных протоколов (DTRC)

Помимо перечисленных значений может рассматриваться значение “Максимальная безопасность”. Строго говоря, значения TOS и QOS не эквивалентны, но именно значение ToS является базой для задания QoS. Присваивая при формировании IP-пакета определенное значение поля ToS, прикладная программа может попытаться реализовать определенные ограничения на QoS. Это поле может анализироваться маршрутизаторами, которые поддерживают протокол RSVP. В протоколе UDP нет никаких механизмов управления трафиком. Кое-что предлагает набор протоколов RTP/RTCP, предназначенный для мультимедийных приложений (например, позволяет ликвидировать влияние разброса времени доступа в каналах Ethernet на качество воспроизведения изображения и звука.). Некоторые приложения и сетевые приборы способны сигнализировать о перегрузке (потере пакетов из-за переполнения буферов), посылая ICMP(4).

Протокол (смотри TCP) имеет в заголовке 6-битовое поле флаги (значения представлены в таблице 2). Значения битов флаги предоставляет дополнительные возможности управления.

Таблица 2.  Значения бит поля флаги

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

Существенную проблему составляет необходимость идентифицировать пакеты, принадлежащие определенному процессу. Эта задача легко решается только в рамках протокола IPv6. Там в заголовке предусмотрено поле метка потока. Некоторые возможности предоставляет также протокол MPLS.

2. Управление трафиком

В настоящее время используется несколько методов управления трафиком:

1.      Динамическая маршрутизация (RIP, OSPF, IGRP, BGP) и т.д.). Здесь нет средства резервирования полосы, но имеется механизм изменения маршрута при изменении значений метрики или из-за выхода из строя узла или обрыва канала. Некоторые из таких протоколов (OSPF, IGRP) могут строить отдельные таблицы маршрутизации для каждого уровня TOS/QOS [1], но метрики для каждого уровня задаются сетевым администратором. Здесь имеется возможность запараллеливания потоков с целью увеличения пропускной способности. Эти протоколы работают только в пределах одной автономной системы (AS). Протокол же BGP, используемый для прокладки путей между автономными системами не способен как-либо учитывать уровень TOS/QOS (использует алгоритм вектора расстояния, что связано с трудностью согласования значений метрик состояния канала администраторами разных AS). Новая версия многопротокольного расширения MP-BGP специально создана для совместной работы с MPLS при формировании виртуальных сетей, но и он безразличен к TOS/QOS.

2.      Формирование виртуальных сетей на уровнях L2 и L3. Протоколы VLAN обеспечивают повышенный уровень безопасности, но не способны резервировать полосу. К этому типу относится и протокол MPLS.

3.      Резервирование полосы в имеющемся виртуальном канале (протокол RSVP). RSVP может работать с протоколами IPv4 и IPv6. Протокол достаточно сложен для параметризации, по этой причине для решения этой задачи был разработан протокол COPS, который существенно облегчает параметризацию. Функция COPS сходна с задачей языка RPSL для маршрутизации.

4.      Автоматическое резервирование полосы при формировании виртуального канала процедурой SETUP в сетях ATM, ISDN, DQDB, Frame Relay и т.д. Управления очередями осуществляется аппаратно, но базовые параметры могут задаваться программно. Программы управления трафиком MPLS позволяют расширяют возможности L2 сетей ATM и Frame Relay.

5.      Использование приоритетов в рамках протокола IPv6. Возможность присвоения потокам меток облегчает, например, разделение аудио- и видеоданных.

6.      Управление перегрузкой (окно перегрузки в TCP, ICMP(4) для UDP-потоков (ICMP L2 и т.д.).

3. Качество обслуживания QoS

QoS связана с возможностью сети предоставить клиенту необходимый ему уровень услуг в условиях работы поверх сетей с самыми разнообразными технологиями, включая Frame Relay, ATM, Ethernet, сети 802.1, SONET, и маршрутизуемые IP-сети.

QoS представляет собой собрание технологий, которые позволяют приложениям запрашивать и получать предсказуемый уровень услуг с точки зрения пропускной способности, временного разброса задержки откликa, а также общей задержки доставки данных. В частности, QoS подразумевает улучшение параметров или достижение большей предсказуемости предоставляемых услуг. Это достигается следующими методами:

• Поддержкой определенной полосы пропускания.
• Сокращением вероятности потери кадров.
• Исключением или управляемостью сетевых перегрузок.
• Возможностью конфигурирования сетевого трафика.
• Установкой количественных характеристик трафика по пути через сеть.

IEFT определяет для QoS следующие две архитектуры:

• Интегрированные услуги (IntServ)
• Дифференцированные услуги (DiffServ)

IntServ для явного задания уровня услуги (QoS) использует протокол RSVP. Это делается путем уведомления об этом требовании всех узлов вдоль пути обмена. Если все сетевые устройства вдоль пути могут предоставить запрошенную полосу, резервирование завершается успешно (смотри документ RFC-1633 [2]).

DiffServ, вместо того чтобы уведомлять о требованиях приложения, использует в IP-заголовке DiffServ Code Point (DSCP), чтобы указать требуемые уровни QoS. Cisco IOS^® Software Release 12.1(5)T вводит совместимость маршрутизаторов Cisco c DiffServ (см. [15-16]). DSCP размещается в поле TOS IP-пакета. В таблице 3 представлены различные виды использования QoS.

Таблица 3.

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

L2 QoS предполагает следующее:

1.      Управление входными очередями: когда кадр приходит на вход порта, он может быть отнесен к одной из нескольких очередей, ассоциированных с портом, прежде чем он будет направлен на один из выходных портов. Обычно, несколько очередей используются тогда, когда различные информационные потоки требуют различных уровней услуг или минимизации задержки. Например, IP мультимедиа требует минимизации задержки, в отличие от передачи данных в FTP, WWW, email, Telnet>, и т.д.

2.      Классификация: процесс классификации включает просмотр различных полей в заголовке Ethernet L2, а также полей IP-заголовка (уровень 3 - L3) и заголовков TCP/UDP (уровень 4 - L4), чтобы обеспечить определенный уровень услуг при коммутации пакетов.

3.      Политика: осуществление политики является процессом анализа кадра Ethernet, чтобы определить, не будет ли превышен заданный уровень трафика за определенный интервал времени (обычно, это время является внутренним параметром переключателя). Если кадр создает ситуацию, при которой трафик превысит заданный уровень, он будет отброшен. Или значение CoS (Class of Service) может быть понижено.

4.      Перепись: процесс переписи предоставляет возможность переключателю модифицировать CoS в заголовке или ToS (Type of Service) в IPv4-заголовке. Следует учесть, что заголовок Ethernet 802.3 поля CoS не имеет (именно эта версия стандарта наиболее распространена в РФ).

5.      Управление выходными очередями: после процесса перезаписи переключатель поместит кадр Ethernet, в выходную очередь для последующей коммутации. Переключатель выполнит управление буфером так, чтобы не произошло переполнение. Это обычно осуществляется с помощью алгоритма RED (Random Early Discard), когда некоторые кадры случайным образом удаляются из очереди. Weighted RE (WRED) является директивой RED (используемой некоторыми модулями семейства Catalyst 6000), где значения CoS анализируются с целью определения того, какие кадры следует отбросить. Когда буферы окажутся заполнены до определенного уровня, кадры с низким уровнем приоритета отбрасываются, в очереди сохраняются только высокоприоритетные кадры.

4. Мультипротокольная коммутация меток (протокол MPLS)

Основы протокола MPLS описаны в официальных документах RFC [3-9 и 14]. Существуют публикации и на русском языке [11-13]. Имеются три монографии, посвященных рассматриваемой проблематике [17-19].

Протокол MPLS хорошо приспособлен для формирования виртуальных сетей (VPN) повышенного быстродействия (метки коммутируются быстрее, чем маршрутизируются пакеты). Принципиальной основой MPLS являются IP-туннели. Для его работы нужна поддержка протокола маршрутизации MP-BGP (RFC-2858 [23]). Протокол MPLS может работать практически для любого маршрутизируемого транспортного протокола (не только IP). После того как сеть сконфигурирована (для этого используются специальные, поставляемые производителем скрипты), сеть существует, даже если в данный момент через нее не осуществляется ни одна сессия. При появлении пакета в виртуальной сети ему присваивается метка, которая не позволяет ему покинуть пределы данной виртуальной сети. Никаких других ограничений протокол MPLS не накладывает. Протокол MPLS предоставляет возможность обеспечения значения QoS, гарантирующего более высокую безопасность. Не следует переоценивать уровня безопасности, гарантируемого MPLS, атаки типа “человек посередине” могут быть достаточно разрушительны. При этом для одного и того же набора узлов можно сформировать несколько разных виртуальных сетей (используя разные метки), например, для разных видов QoS. Но можно использовать возможности АТМ (процедура setup), если именно этот протокол применен в опорной сети (возможные перегрузки коммутаторов не в счет).

Для обеспечения структурирования потоков в пакете создается стек меток, каждая из которых имеет свою зону действия. Формат стека меток представлен на рис. 3 (смотри RFC-3032). В норме стек меток размещается между заголовками сетевого и канального уровней (соответственно L2 и L3). Каждая запись в стеке занимает 4 октета.

Рис. 3. Формат стека меток

Место заголовка МАС может занимать заголовок РРР. В случае работы с сетями АТМ метка может занимать поля VPI и VCI. Смотри рис 4. Глубина стека в данном случае не может превышать 1.

Рис. 4. Формат меток в ячейках АТМ

На рисунке полю СoS соответствует субполю приоритет поля ToS. Поле CoS имеет три бита, что достаточно для поля приоритета IP-заголовка. 6-битовое поле кода дифференцированной услуги DSCP сюда записать нельзя. Можно попробовать разместить этот код в поле самой метки. S – флаг-указатель дна стека меток; TTL - время жизни пакета MPLS.

Существующие версии программного обеспечения Cisco IOS (например, Cisco IOS Release 12.0) содержат набор средств управления трафиком. В частности, имеется возможность формировать статические маршруты и управлять динамическими маршрутами путем манипулирования значениями метрики. Иногда этого вполне достаточно, но в большинстве случаев провайдер нуждается в более эффективных средствах.

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

MPLS представляет собой интеграцию технологий уровней L2 и L3. Управление трафиком в MPLS реализуется путем предоставления традиционных средств уровня L2 уровню L3. Таким образом, можно предложить в односвязной сети то, что достижимо только путем наложения уровня L3 на уровень L2.

Управление коммутацией по меткам основывается на базе данных LIB (Label Information Base). Пограничный маршрутизатор MPLS LER (Label Edge Router) удаляет метки из пакетов, когда пакет покидает облако MPLS, у вводит их во входящие пакеты. Схема работы с помеченными и обычными IP-пакетами показана на рис. 5.

Рис. 5. Обработка помеченных и обычных IP-пакетов

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

Информация об имеющихся ресурсах доводится до сведения заинтересованных субъектов с помощью протокола IPG (Interior Protocol Gateway), алгоритм которого базируется на состоянии канала.

Путь туннеля вычисляется, основываясь на сформулированных требованиях и имеющихся ресурсах (constraint-based routing). IGP автоматически маршрутизирует трафик через эти туннели. Обычно, пакет, проходящий через опорную сеть MPLS движется по одному туннелю от его входной точки к выходной.

Управление трафиком MPLS основано на следующих механизмах IOS:

• Туннелях LSP (Label-switched path), которые формируются посредством RSVP, c расширениями системы управления трафиком. Туннели LSP представляют собой туннельные двунаправленные интерфейсы IOS c известным местом назначения.
• Протоколах маршрутизации IGP, базирующиеся на состоянии канала (такие как IS-IS) с расширениями для глобальной рассылки ресурсной информации, и расширениях для автоматической маршрутизации трафика по LSP туннелям.
• Модуле вычисления пути MPLS, который определяет пути для LSP туннелей.
• Модуле управления трафиком MPLS, который обеспечивает доступ к и запись ресурсной информации, подлежащей рассылке.
• Переадресации согласно меткам, которая предоставляет маршрутизаторам возможности, сходные с уровнем L2, перенаправлять трафик через большое число узлов согласно алгоритму маршрутизации отправителя.

Одним из подходов управления опорной сетью является определение сети туннелей между всеми участниками обменов. Протокол IGP, работающий в начале туннеля, определяет то, какой трафик должен проходить через любой оконечный узел. Модули вычисление пути и управления MPLS определяют маршрут LSP туннеля. Для каждого туннеля подсчитывается число пропущенных пакетов и байт.

Иногда, поток настолько велик, что его нельзя пропустить через один канал (туннель). В этом случае может быть создано несколько туннелей между отправителем и получателем.

Для реализации MPLS управления трафиком сеть должна поддерживать следующие возможности Cisco IOS:

• Мультипротокольную переадресацию пакетов с использованием меток (MPLS)
• IP-переадресацию CEF (Cisco Express Forwarding)
• Протокол маршрутизации IS-IS (Intermediate System-to-Intermediate System; см. RFC-1142, -1195, -2763, -2966 и -2973)

Дополнительные данные о MPLS и управлении трафиком можно найти в документации Cisco (поддерживается в реализациях 7620, 7640, 7200, 7500 и 12000):

• Cisco IOS Release 12.0 Switching Services Configuration Guide, глава "Tag Switching"
• Cisco IOS Release 12.0 Switching Services Command Reference, глава "Tag Switching Commands".
• Cisco IOS Release 11.3 Switching Services Command Reference, Часть 1, глава "Configuring RSVP"
• Cisco IOS Release 11.3 Network Protocols Command Reference, Часть 1, глава "RSVP Commands".
• Cisco IOS Release 12.0 Switching Services Configuration Guide, глава "Tag Switching".
• Cisco IOS Release 12.0 Switching Services Command Reference, глава "Tag Switching Commands".

Протоколы состояния канала типа IS-IS для вычисления кратчайшего пути для всех узлов сети используют алгоритм Дикстры SPF. Маршрутные таблицы получаются на основе дерева кратчайших путей. Эти таблицы содержат упорядоченный набор адресов места назначения и информацию о ближайших соседей. Если маршрутизатор осуществляет прокладку путей на основе алгоритма шаг-за-шагом, первым шагом является физический интерфейс, соединенный с маршрутизатором.

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

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

Управление трафиком MPLS:

• Исключается необходимость ручной конфигурации сетевых устройств, чтобы задать определенные маршруты. Вместо этого, можно положиться на возможности управления трафиком, предоставляемые MPLS.
• Производится оценка полосы канала и значения трафика при прокладке маршрута через опорную сеть.
• Имеет механизмы динамической адаптации, которые позволяют сделать опорную сеть устойчивой к отказам даже в условиях, когда несколько путей были рассчитаны в режиме off-line. В случае отказа узлов производится коррекция топологии опорной сети.

В рекомендациях CISCO [15] можно прочесть, что MPLS позволяет провайдеру маршрутизировать потоки данных так, чтобы клиенту гарантировать минимум задержки и максимум пропускной способности.

Сформировав несколько виртуальных сетей для заданного набора узлов, можно попытаться объединять возможности этих сетей в случае возникновения такой необходимости, увеличивая пропускную способность. Можно для каждой из субсетей использовать разный уровень QoS с помощью протокола RSVP.

Рассмотрение описания конфигурации MPLS в аппаратах CISCO [15] показывает отсутствие возможности задания какого-либо значения QoS. Но это не означает, что этого не будет возможно уже в 2003 году.

5. Протокол резервирования ресурсов RSVP

Если сетевые условия позволяют, то, используя протокол RSVP (где QoS задается в спецификации потока (flowspec) – практически на сегодня это единственное реализуемое решение), можно попытаться зарезервировать для заданной виртуальной сети определенное значение полосы пропускания. Следует иметь в виду, что протокол RSVP приспособлен в основном для резервирования определенного значения полосы пропускания, а не произвольного QoS (спецификации QoS см. в RFC-2210, 2211 и 2212) для существующего виртуального соединения. Если виртуальное соединение разорвано, следом ликвидируются и все резервирования. Следует, разумеется, иметь в виду, что >RSVP может работать как c TCP- так и c UDP-сессиями поверх IPv4 и IPv6. Сессия резервирования инициируется получателем данных. Резервирование может осуществляться как для уникаст, так и мультикаст-потоков. Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin «Resource ReSerVation Protocol», RFC-2205; http://book.itep.ru/4/44/Rsv_4496.htm; смотри также RFC-2206-10, -2490, -2745-47, -2750-52, -2872, -2961, -2996, -3097, -3175, -3181, -3209-10) определяет режим резервирования (способ объединения нескольких заявок для одного и того же интерфейса: WF, FF, SE), формирования резервирования и его поддержания в условиях отсутствия поддержки данного протокола в одном или нескольких узлах виртуального пути, пересылки QoS-запросов другим маршрутизаторам и т.д., но решения принимаются маршрутизатором локально без знания условий в остальной части пути. По этой причине здесь не может идти речь о минимизации задержки, обеспечении надежности или безопасности, хотя в перспективе это может стать возможным.

Следует учитывать, что инициатором резервирования в RSVP всегда является клиент (именно он посылает первичные запросы). По этой причине могут возникнуть проблемы при попытке централизованного управления QoS посредством RSVP.

RSVP не имеет механизмов управления очередями в конкретных интерфейсах, а механизм резервирования полосы пропускания для одного из направлений обмена является зоной ответственности изготовителя маршрутизатора и не публикуется. Кроме того, при скоростях несколько сот Мбит/с часто обработка процедур буферизации перепоручается аппаратным средствам (например, в случае компании CISCO).

·        RSVP выполняет резервирование для уникастных и мультикастных приложений, динамически адаптируясь к изменениям членства в группе вдоль маршрута.

·        RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных.

·        RSVP ориентирован на получателя, т.е., получатель данных инициирует и поддерживает резервирование ресурсов для потока.

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

·        RSVP не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов.

·        RSVP транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP.

·        RSVP обеспечивает несколько моделей резервирования или стилей, для того чтобы удовлетворить требованиям различных приложений.

·        RSVP обеспечивает прозрачность операций для маршрутизаторов, которые его не поддерживают.

·        RSVP может работать с IPv4 и IPv6.

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

Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

1.    "Rspec", который определяет желательное значение QoS, и

2.     "Tspec", который описывает информационный поток.

Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC 2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.

1.          Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC 2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.

2.          IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов. Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.

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

Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации.

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

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

Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

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

·        Стиль WF (Wildcard-Filter)

Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая «труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.

·        Стиль FF (Fixed-Filter)

Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии.

·        Стиль SE (Shared Explicit)

Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей.

Для облегчения работы с RSVP разработан протокол COPS (Common Open Policy Service; RFC-2748, The COPS Protocol, D. Durham, Ed. Смотри также RFC-2749, -2940 и -3084).

Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике. Предполагается, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [27-28]. Смотри также http://book.itep.ru/4/4/cops.htm

В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.

При работе с АТМ ситуация ненамного лучше, программное обеспечение АТМ-коммутаторов также обычно не доступно. Но имеется возможность работы RSVP поверх АТМ [29-31].

Рассматривается внедрение протокола RSVP на уровень L2 [34].

При наличии механизмов реализации других типов QoS (смотри, например, RFC-2430 [21] и Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", где предлагается ввести дополнительные биты в заголовок), можно решить проблему в более общем виде (но эта технология находится лишь на стадии обсуждения и не внедрена ни на одном серийном приборе). В рамках одной автономной системы (AS), где используется внутренний протокол маршрутизации OSPF>, можно обеспечить требуемый уровень QoS, но это будет делаться вручную, во всяком случае, на уровне задания значений метрики. Теоретически можно это сделать и автоматически, например, в случае применения версии протокола IGRP (внутренний протокол компании CISCO), поддерживающего автоматическую оценку значений метрики. К сожалению, компания CISCO отошла от первоначального плана и значения метрики там задается в настоящее время также администратором.

Реализация управления QoS предполагает организацию эффективной системы мониторинга базовых параметров, характеризующих требуемый уровень QoS. Для этого требуется контролировать уровень информационных потоков во всех фрагментах VPN, постоянно измерять значение RTT и его дисперсии, контролировать уровень вероятности потери пакетов во всех фрагментах виртуального пути. Желательно также отслеживать корреляции перечисленных параметров и локального значения загрузки. Схема мониторинга и управления QoS показана на рис. 6.

Рис. 6.

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

Выводы

1.      Для сетей TCP/IP основным инструментом управления QoS пока является протокол RSVP (это касается и MPLS).

2.      Протокол MPLS является удобным средством формирования корпоративных сетей (VPN), которые позволяют поднять их безопасность.

3.      Для обеспечения работы MPLS необходима поддержка протоколов IS-IS и MP-BGP всеми маршрутизаторами VPN.

4.      Протокол MPLS предоставляет гибкие средства мониторинга трафика в пределах VPN.

5.      Технология управления трафиком ТЕ предполагает совмещение возможностей протоколов уровней L2 и L3.

6.      Протокольных средств управления очередями в Ethernet или в TCP/IP не существует. Такие средства имеются вATM-коммутаторах, ограниченные возможности имеются в некоторых маршрутизаторах CISCO и в коммутаторах L2 (например, выбор между режимами store-and-forward и cut through и т.д.). В любом случае такие режимы конфигурируются администратором индивидуально для каждого сетевого устройства. Разумеется, что-то можно сделать с помощью протокола SNMP дистанционно, если имеется пароль доступа (community).

7.      Переход на IPv6 существенно расширяет возможности управления трафиком за счет использования меток потоков (пока не ясно насколько эта возможность поддерживается программно). Данное свойство особенно важно для передачи мультимедийных данных, например, программ цифрового телевидения. Последнее предполагает значительное расширение интегральной полосы каналов опорной сети (хотя бы до 155Мбит/c).

8.      Все выше сказанное отражает ситуацию сегодняшнего дня, когда не стандартизовано дополнительных средств управления трафиком и QoS. Положение может измениться, если будут, например, стандартизованы какие-то дополнительные атрибуты потоков (как это было сделано при введении меток для VPN). Такие работы уже ведутся (см. [3])

9.      Возможности, заложенные в протоколе MPLS, предполагают определенный уровень сотрудничества между администраторами узлов, образующих VPN.

Библиография

Previous: 4.4.16 Протокол SNTP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет    Next: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)