previous up next index search

Previous: 4.4.16 Протокол SNTP    UP: 4.4 Интернет
    Next: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

4.4.17 Введение в MPLS, TE и QoS
Семенов Ю.А. (ГНЦ ИТЭФ)

Базовые предпосылки
Управление трафиком
Качество обслуживания QoS
Мультипротокольная коммутация меток (протокол MPLS)
Формат меток в ячейках АТМ
Протокол резервирования ресурсов RSVP
Выводы
Библиография

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

В начале 90-х для размещения маршрутной таблицы в маршрутизаторе хватало 4-8Мбайт, но требования быстро росли, и это стимулировало широкое внедрение идеологии автономных систем (AS). На какое-то время AS позволили решить проблему, но к 2005-му году требования к памяти маршрутизатора возросли до 100Мбайт и это не предел.

Давайте сначала прикинем, со сколькими сетевыми узлами вы и сотрудники вашего подразделения устанавливаете связь в течение рабочего дня. Это число нестабильно, зависит от характера работы и сильно варьируется от человека к человеку. Но, очевидно, что это число вряд ли превышает несколько сот и слабо меняется со временем. Таким образом, для обеспечения требуемых маршрутов объем маршрутной таблицы, если бы он содержал только используемые вами IP-адреса, был бы незначительным. При этом поиск в такой таблице занимал бы на порядки меньше времени (RTT сокращается на порядок).


Именно идея сохранения в маршрутной таблице только реально используемых виртуальных путей и легла в основу разработки протокола MPLS и сопряженных с ним протоколов маршрутизации.

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

Период экстенсивного развития сети Интернет завершился несколько лет тому назад даже в РФ. Сейчас многие сервис-провайдеры пытаются привлечь клиентов дополнительными информационными услугами 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-порт порт получателя = 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
Приоритет 1001000
Приоритет 2010000
Приоритет 3011000
Приоритет 4100000
Приоритет 5101000
Приоритет 6110000
Приоритет 7111000

На базе 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 для разных протоколов

Процедура Минимал. задержка Максимал. пропускная способность Максимал. надежность Минимал. стоимость Код TOS
FTP управление
FTP данные
1 0 0 0 0x10
0 1 0 0 0x08
TFTP 1 0 0 0 0x10
DNS

UDP

TCP
1 0 0 0 0x10
0 0 0 0 0x00
0 0 0 0 0x00
Telnet 1 0 0 0 0x10
ICMP 0 0 0 0 0x00
IGP 0 0 1 0 0x04
SMTP управление
SMTP данные
1 0 0 0 0x10
0 1 0 0 0x08
SNMP 0 0 1 0 0x04
NNTP 0 0 0 1 0x02

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


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

Обозначение битов (слева на право) поля флаги Значение бита, если он равен 1
URG Флаг важной информации, поле Указатель важной информации имеет смысл, если URG=1.
ACK Номер октета, который должен был прийти следующим, правилен.
PSH Этот сегмент требует выполнения операции push. Получатель должен передать эти данные прикладной программе как можно быстрее.
RST Прерывание связи.
SYN Флаг для синхронизации номеров сегментов, используется при установлении связи.
FIN Отправитель закончил посылку байтов.

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

Существенную проблему составляет необходимость идентифицировать пакеты, принадлежащие определенному процессу. Эта задача легко решается только в рамках протокола 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 для явного задания уровня услуги (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 Signaling   Protocol_family
QoS Policy and Shaping CAR Rate Limiting
CAR
http://www.cisco.com/en/US/tech/tk543/tk545/tk764/ tech_protocol_home.html
Tech_protocol
QoS Link Efficiency Mechanisms MLPPP http://www.cisco.com/en/US/tech/tk543/tk762/tk763/ tech_protocol_home.html  
QoS Congestion Management WFQ
VIP-Distributed WFQ
PQ
LLQ
IP RTP Priority
FIFO Queueing
Distributed LLQ
CBWFQ
http://www.cisco.com/en/US/tech/tk543/tk544/tk718/ tech_protocol_home.html
  http://www.cisco.com/en/US/tech/tk543/tk544/tk530/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk399/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk366/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk228/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk761/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk544/tk96/ tech_protocol_home.html
QoS Congestion Avoidance WRED
RED
Flow-based WRED
D-WRED
http://www.cisco.com/en/US/tech/tk543/tk760/tk725/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk760/tk549/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk760/tk230/ tech_protocol_home.html http://www.cisco.com/en/US/tech/tk543/tk760/tk185/ tech_protocol_home.html
QoS Configuration and Monitoring   http://www.cisco.com/en/US/tech/tk543/tk759/ tech_protocol_family_home.html
QoS Classification and Marking MPLS EXP bit
Frame Relay DE bit
DCAR
ATM CLP bit
http://www.cisco.com/en/US/tech/tk543/tk757/tk776/ tech_protocol_home.html  http://www.cisco.com/en/US/tech/tk543/tk757/tk758/ tech_protocol_home.html


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

Одной из задач MPLS является предоставление условий передачи мультимедиа данных по виртуалным частным сетям с гарантированным качеством [69].

Рис. 2.a. Site-to-site MPLS VPN

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. Формат стека меток

Рис. 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:

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

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

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

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

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

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

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

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

В рекомендациях 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 исполняется в фоновом режиме.

Спецификация 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 в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

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

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

Для облегчения работы с 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 и cutthrough и т.д.). В любом случае такие режимы конфигурируются администратором индивидуально для каждого сетевого устройства. Разумеется, что-то можно сделать с помощью протокола SNMP дистанционно, если имеется пароль доступа (community).
  7. Переход на IPv6 существенно расширяет возможности управления трафиком за счет использования меток потоков (пока не ясно насколько эта возможность поддерживается программно). Данное свойство особенно важно для передачи мультимедийных данных, например, программ цифрового телевидения. Последнее предполагает значительное расширение интегральной полосы каналов опорной сети (хотя бы до 155Мбит/c).
  8. Все выше сказанное отражает ситуацию сегодняшнего дня, когда не стандартизовано дополнительных средств управления трафиком и QoS. Положение может измениться, если будут, например, стандартизованы какие-то дополнительные атрибуты потоков (как это было сделано при введении меток для VPN). Такие работы уже ведутся (см. [3])
  9. Возможности, заложенные в протоколе MPLS, предполагают определенный уровень сотрудничества между администраторами узлов, образующих VPN.

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

  1. E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. RFC-2386. A Framework for QoS-based Routing in the Internet. August 1998.
  2. R. Braden, RFC-1633. Integrated Services in the Internet Architecture: an Overview. June 1994.
  3. E. Rosen, Y. Rekhter, RFC-2547. BGP/MPLS VPNs. March 1999.
  4. J. Malcolm, RFC-2702, Requirements for Traffic Engineering Over MPLS. September 1999.
  5. A. Malis, RFC-2917, A Core MPLS IP VPN Architecture, September 2000.
  6. E. Rosen. RFC-3031, Multiprotocol Label Switching Architecture, January 2001
  7. D. Tappan, RFC-3032, MPLS Label Stack Encoding, January 2001.
  8. J. Lawrence, RFC-3035, MPLS using LDP and ATM VC Switching, January 2001.
  9. Y. Katsube, RFC-3063, MPLS Loop Prevention Mechanism, February 2001.
  10. B.Олифер, Н. Олифер, Искусство оптимизации трафика. Журнал сетевых решений LAN, декабрь 2001, стр. 38-47.
  11. В.Олифер, Н. Олифер, Виртуальные частные сети на основе MPLS. Журнал сетевых решений LAN, январь 2002, стр. 58-63.
  12. Д.Гринфильд, Глобальная служба MPLS: опережая время. Журнал сетевых решений LAN, март 2002, стр. 32-38.
  13. В.Олифер, Н. Олифер, MPLS на службе VPN. Журнал сетевых решений LAN, март 2002, стр. 40-47.
  14. L. Wu, RFC-3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, May 2002.
  15. http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/xtocid285471
  16. http://www.cisco.com/warp/public/105/qos_index.shtml
  17. Jim Guichard, Ivan Pepelnjak. MPLS and VPN Architectures. A Practical Guide to Understanding, Designing and Deploying MPLS and MPLS-Enabled VPNs. Cisco Press, 2000.
  18. Sean Harnedy. The MPLS Primer. An Introduction to Multiprotocol Label Switching, Prentice Hall, 2001.
  19. Eric W. Gray, MPLS. Implementing the Technology. With CD-ROM, Addison Wesley, 2001.
  20. http://old.ruslan-com.ru/marconi/MPLS/mpls_intro.htm#Arch
  21. Li, T. and Y. Rekhter, RFC-2430, Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). October 1998.
  22. J. Wroclawski. RFC-2210, The Use of RSVP with IETF Integrated Services. September 1997.
  23. L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin «Resource ReSerVation Protocol», RFC-2205. September 1997.
  24. Bates, Y. Rekhter, R., Chandra, D. Katz. Multiprotocol Extensions for BGP-4. RFC-2858. June 2000.
  25. J. Wroclawski. RFC-2211. Specification of the Controlled-Load Network Element Service. September 1997.
  26. S. Shenker. RFC-2212. Specification of Guaranteed Quality of Service. September 1997.
  27. D. Durham, Ed. RFC-2748. The COPS (Common Open Policy Service) Protocol. January 2000.
  28. Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000.
  29. L. Berger. RFC-2379. RSVP over ATM Implementation Guidelines. August 1998.
  30. L. Berger. RFC-2380. RSVP over ATM Implementation Requirements. August 1998.
  31. E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. RFC-2382. A Framework for Integrated Services and RSVP over ATM. August 1998.
  32. S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. RFC-2749 COPS usage for RSVP. January 2000.
  33. S. Herzog. RFC-2750. RSVP Extensions for Policy Control. January 2000.
  34. R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. RFC-2814. SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. May 2000.
  35. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. RFC-3175. Aggregation of RSVP for IPv4 and IPv6 Reservations. September 2001.
  36. D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. RFC-3209. RSVP-TE: Extensions to RSVP for LSP Tunnels. December 2001.
  37. A. Smith, D. Partain, J. Seligson. RFC-2940. Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. October 2000.
  38. K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. RFC-3084. COPS Usage for Policy Provisioning (COPS-PR). March 2001.
  39. Максим Кульгин. Контроль трафика в сетях ATM. LAN/Журнал Сетевых решений #12/98
  40. Алексей Лукацкий. Неизвестная VPN. http://abn.ru/inf/compress/network4.shtml
  41. http://www.cisco.com.ru/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/te120_7t.pdf (управление трафиком - ТЕ)
  42. Мультипротокольная коммутация по меткам (MPLS). http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt3/xcftagc.pdf
  43. http://www.tt.ru/?do=stech2&id=740 (“ТрансТелеКом”, обзоры на русском)
  44. http://www.mplsforum.org (Оффициальная страница группы разработчиков MPLS).
  45. IP-Datentransport ist nur der Anfang. Wilhelm Greiner, LANline 10/2002, стр. 110-115;
    MPLS als Hoffnungstraeger. Gerhard Kafka, LANline 10/2002, стр. 122-125.
    Keine Zeit fuer Auszeigen. Markus Heis, LANline 10/2002, стр. 126-129;
  46. Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment; RFC-3353, D. Ooms, August 2002.
  47. Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks; RFC-3443, P. Agarwal, January 2003.
  48. Framework for Multi-Protocol Label Switching (MPLS)-based Recovery; RFC-3469, V. Sharma, February 2003.
  49. Generalized Multi-Protocol Label Switching (GMPLS)Signaling Functional Description; RFC-3471, L. Berger, January 2003.
  50. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions; RFC-3472, P. Ashwood-Smith, January 2003.
  51. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions; RFC-3473, L. Berger, January 2003.
  52. Graceful Restart Mechanism for Label Distribution Protocol; RFC-3478, M. Leelanivas, February 2003.
  53. Fault Tolerance for the Label Distribution Protocol (LDP); RFC-3479, A. Farrel, February 2003.
  54. Шринивас Вегешна, "Качество обслуживания в сетях IP", Cisco Press, 2003.
  55. Definition of the Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers; RFC-2474, K. Nichols, December 1998.
  56. Assured Forwarding PHB Group; RFC-2597,, J. Heinanen, June 1999.
  57. Multiprotocol Label Switching (MPLS) www.ietf.org/html.charters/mpls-charter.html
  58. Jim Guichard, Ivan Pepelnjak, "MPLS and VPN Architectures", Cisco Press, 2001
  59. Adaptive Bandwidth Control for Efficient Aggregate QoS Provisioning, Peerapon Siripongwutikorny Sujata Banerjeeyz David Tippery
  60. Per-flow Delay Performance in Traffic Aggregates, Peerapon Siripongwutikorn† and Sujata Banerjee†,‡ †Telecommunications Program, University of Pittsburgh
  61. A QoS Engineering Architecture for the Next-Generation-Internet
  62. RFC-3811.   Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management. T. Nadeau, Ed., J. Cucchiara, Ed.. June 2004.
  63. RFC-3812.   Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004.
  64. RFC-3813.   Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004.
  65. RFC-3814.   Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB). T. Nadeau, C. Srinivasan, A. Viswanathan. June 2004.
  66. RFC-3815.   Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP). J. Cucchiara, H. Sjostrand, J. Luciani. June 2004.
  67. RFC-3919.   Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS). E. Stephan, J. Palet. October 2004.
  68. RFC-4023.   Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE). T. Worster, Y. Rekhter, E. Rosen, Ed.. March 2005.
  69. The MPLS Network: A Future-Proof Engine for Voice-Data Convergence. Addressing network traffic trends with new opportunities for business communications. White Paper.

Previous: 4.4.16 Протокол SNTP    UP: 4.4 Интернет
    Next: 4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)