Курс лекций по сетевым технологиям

Часть IV

Стандарты IEEE 802.1Q и IEEE 802.1р

Приоритеты и классы обслуживания

Протоколы RTP и RSVP

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

Задача рабочих групп, трудящихся над стандартами p и Q, — дать сетевой отрасли единый метод передачи по сети информации о приоритете кадра и его принадлежности к ВЛВС. Были разработаны две спецификации маркировки пакетов:

• первая, одноуровневая, определяет взаимодействие виртуальных сетей по магистрали Fast Ethernet;

• вторая, двухуровневая, касается маркировки пакетов в смешанных магистралях, включая Token Ring и FDDI.

Первая спецификация с самого начала нуждалась лишь в минимальной доработке, так как она, по сути, представляет собой технологию тэговой коммутации, продвигаемую на рынок усилиями Cisco. Задержки с принятием стандарта 802.1Q объясняются необходимостью детальной проработки куда более сложной «двухуровневой» спецификации.

Стандарт должен был удовлетворять следующим достаточно высоким требованиям:

• масштабируемости на уровне обмена пакетами между коммутаторами;

• преемственности на уровне существующих конечных приложений;

• адаптации на уровне существующих протоколов и таблиц маршрутизации;

• экономичности в плане утилизации высокоскоростных магистралей;

• совместимости с ATM, особенно с эмуляцией ЛВС;

• управляемости процесса маркировки пакетов.

В соответствии со стандартом 802.1Q к кадру Ethernet добавлены четыре байта. Эти 32 бита содержат информацию по принадлежности кадра Ethernet к ВЛВС и о его приоритете. Говоря точнее, тремя битами кодируется до восьми уровней приоритета, 12 бит позволяют различать трафик до 4096 ВЛВС, один бит зарезервирован для обозначения кадров сетей других типов (Token Ring, FDDI), передаваемых по магистрали Ethernet, и т. д.

Поле идентификатора уровня приоритета дает возможность использовать восемь таких уровней, соответствующих системе приоритетов стандарта 802.1p.

В заголовке кадра Ethernet поля 802.1Q размещаются между адресом отправителя и полем с информацией о длине кадра полезной нагрузки 802.3 (кадр Ethernet) или о типе протокола более высокого уровня (кадр Ethernet II).

В настоящее время практически все сетевые фирмы уже создали коммерческие версии продуктов, поддерживающие стандарты 802.1p и 802.1Q. Кроме того, многие производители коммутаторов Ethernet уже реализовали службы приоритезации собственной разработки.

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

В самом деле, из-за того что данные 802.1Q размещаются перед полем с информацией о длине полезной нагрузки (или типе протокола), традиционный сетевой продукт не обнаружит эту информацию на привычном месте и вместо нее «прочитает» число x8100 — значение по умолчанию нового поля «Тэг протокольного идентификатора» (Tag Protocol Identifier) в кадрах 802.1Q.

Источником проблем является не только изменение в размещении полей заголовка кадра Ethernet, но и увеличение максимальной длины данного кадра. Многие сетевые устройства не способны обрабатывать кадры длиннее 1518 байт. Между специалистами возникли споры по поводу того, нужно ли максимальный размер кадра Ethernet удлинять на четыре байта или следует укоротить на четыре байта максимальный размер полезной нагрузки и таким образом компенсировать увеличение заголовка. Спецификация 802.1Q предусматривает оба подхода, поэтому производителям самим предстоит обеспечивать взаимную совместимость своих продуктов.

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

Спецификация IEEE 802.1p, создаваемая в рамках процесса стандартизации 802.1Q, определяет метод передачи информации о приоритете сетевого трафика. Хотя в большинстве ЛВС редко случаются длительные перегрузки, отдельные всплески трафика представляют собой обычное явление и могут привести к задержкам передач пакетов. Это абсолютно неприемлемо для работы сетей, предназначенных для передачи голоса и видео. Стандарт 802.1p специфицирует алгоритм изменения порядка расположения пакетов в очередях, с помощью которого обеспечивается своевременная доставка трафика, чувствительного к временным задержкам.

Рабочая группа по стандартизации интегрированного обслуживания в сетях с разными канальными уровнями (ISSLL) определила ряд классов обслуживания в зависимости от того, какое время задержки допустимо для передачи пакета того или иного типа трафика. Представьте себе сеть с разными видами трафика: чувствительного к задержкам порядка 10 мс, не допускающего задержек более 100 мс и почти не чувствительного к задержкам. Для успешной работы такой сети каждый из этих типов трафика должен иметь свой уровень приоритета, обеспечивающий выполнение требований, предъявляемых к величине задержки. Используя концепцию протокола резервирования ресурсов (Resource Reservation Protocol — RSVP) и систему классов обслуживания, можно определить схему управления приоритетами. Протокол RSVP, который будет рассмотрен ниже, поддерживается большинством коммутирующих маршрутизаторов и, в частности, моделями SSR 8000/8600 производства Cabletron.

В дополнение к определению приоритетов стандарт 802.1p вводит важный протокол GARP (Generic Attributes Registration Protocol) с двумя специальными реализациями. Первая из них — протокол GMRP (GARP Multicast Registration Protocol), позволяющий рабочим станциям делать запрос на подключение к домену групповой рассылки сообщений. Поддерживаемую этим протоколом концепцию назвали подсоединением, инициируемым «листьями». Протокол GMRP обеспечивает передачу трафика только в те порты, из которых пришел запрос на групповой трафик, и хорошо согласуется со стандартом 802.1Q.

Второй реализацией GARP является протокол GVRP (GARP VLAN Registration Protocol), похожий на GMRP. Однако, работая по нему, рабочая станция вместо запроса на подключение к домену групповой рассылки сообщений посылает запрос на доступ к определенной ВЛВС. Данный протокол связывает стандарты p и Q.

С принятием предварительных вариантов стандартов 802.1Q и 802.1p появились все возможности для широкого использования средств приоритезации трафика в сетях Ethernet. Задействуя продукты, поддерживающие механизмы приоритезации, сетевые администраторы смогут распоряжаться коммутирующей инфраструктурой своей сети таким образом, чтобы, например, высший уровень приоритета получил трафик офисного пакета Lotus Notes и электронной почты, а аудиопотоки RealAudio — низший уровень. Механизмы приоритезации трафика, основанные на спецификациях 802.1Q и 802.1p, бесспорно, стали еще одним козырем технологии Ethernet.

Но хотя упомянутые спецификации и обеспечивают приоритезацию трафика для наиболее популярных топологий второго уровня, они не гарантируют того, что вся инфраструктура сети (от одной ее конечной точки до другой) будет поддерживать обработку приоритетного трафика. В частности, спецификации 802.1Q и 802.1p бесполезны при управлении приоритетом IP-трафика (трафика третьего уровня), передаваемого через низкоскоростную распределенную сеть или каналы доступа в Интернет, то есть через наиболее вероятные «узкие места» сетевой инфраструктуры.

Чтобы в полной мере управлять трафиком во всей сети, необходимо прежде всего реализовать эффективную приоритезацию IP-трафика. В связи с этим возникает ряд вопросов. Поддерживает ли локальная сеть механизмы такой приоритезации? А оборудование распределенной сети? Поддерживает ли эти механизмы ваш поставщик услуг Интернета? Что в связи с этим можно сказать об инфраструктуре на другом конце соединения? Если хотя бы одно устройство, находящееся между двумя системами, не поддерживает механизмы приоритезации, будет невозможно реализовать передачу приоритетного трафика от одного конечного узла сети до другого.

В отличие от технологии Ethernet, протокол IP уже довольно давно обладает средствами приоритезации сетевого трафика — впервые они были предложены в версии, опубликованной в 1981 году. Каждый IP-пакет имеет восьмибитовое поле «Тип сервиса» (Type of Service, ToS), состоящее из двух подполей (см. структуру заголовка пакета IP):

• трехбитового — для установления уровня приоритета пакета;

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

Три первых бита поля ToS позволяют устанавливать для IP-трафика те же восемь уровней приоритета (от 0 до 7), что и спецификации 802.1Q и 802.1p, а также большинство других технологий ЛВС. Поэтому можно взаимно однозначно отображать информацию о приоритетах кадров Ethernet и пакетов IP, а значит, реализовать сквозную обработку приоритетного трафика, передаваемого из одной сети Ethernet в другую через распределенную сеть IP или инфраструктуру поставщика услуг Интернета.

Четыре других используемых бита поля ToS позволяют администратору сети осуществлять индивидуальную маршрутизацию каждого пакета в соответствии с особенностями содержащихся в нем данных. Так, например, пакетам протокола NNTP (Network News Transfer Protocol), транспортирующим новости UseNet, можно установить класс обслуживания с низкой стоимостью («low cost», а пакетам Telnet — класс обслуживания с низкой задержкой «(low latency»).

Изначально стандарт RFC 791 (первоначальный вариант протокола IP) определял только три класса обслуживания, каждому из которых ставился в соответствие отдельный бит, устанавливаемый в «1» или «0» в зависимости от потребностей в том или ином типе обслуживания. С принятием стандарта RFC 1349 был добавлен еще один класс, и теперь ранее разобщенные четыре бита стали рассматриваться как единое целое. Поэтому сегодня с их помощью можно задавать максимум 16 значений (от 0 до 15).

Сетевые администраторы, управляющие сложными сетями с множеством маршрутов, могут использовать биты определения типа обслуживания в сочетании с такими протоколами маршрутизации, как OSPF, для создания специальных служб маршрутизации. Например, пакеты с «отметкой» low latency (низкая задержка) можно посылать не по спутниковому соединению, а по высокоскоростной оптической линии, тогда как «неприхотливый» трафик (класс обслуживания «low cost») направить через Интернет, а не через корпоративную распределенную сеть.

Комбинируя биты установки типа обслуживания с битами приоритета, можно очень точно задавать режимы обработки пакетов с конкретными типами данных, например: определить правила, в соответствии с которыми сетевые фильтры будут присваивать всем пакетам приложения Lotus Notes средний уровень приоритета и назначать класс обслуживания с низкой задержкой. При этом пользователи Notes получат льготное обслуживание по сравнению с пользователями других, менее важных приложений. Можно определить иной набор фильтров, который пометит весь трафик аудиоприложения RealAudio как низкоприоритетный и установит для него класс обслуживания с высокой пропускной способностью (high throughput).

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

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

Но удивительно, что лишь некоторые операционные системы используют в своих IP-стеках механизмы записи в пакет информации об уровне его приоритета и требуемом для него классе обслуживания. В прикладном программном интерфейсе WINSOCK.DLL, поставляемом вместе с Windows 95 и Windows NT, такие возможности вообще отсутствуют, так что попытки вызвать функцию «setsockopt (IP_TOS)» приводят к выдаче диагностического сообщения «invalid operation» («Недопустимая операция»). В других операционных системах, например в Irix, HP-UX и Solaris, реализована лишь частичная поддержка данных функций.

Среди всех операционных систем мощная поддержка функций ToS реализована только в Linux и Digital UNIX. Причем она имеется как непосредственно в самих системах, так и в наборах их стандартных приложений. Например, обе системы предоставляют клиенты и серверы Telnet, способные устанавливать бит low latency поля ToS — ни одна другая из протестированных нами операционных систем такими важными возможностями не обладает. Клиент и сервер FTP, работающие в среде Linux и Digital UNIX, способны устанавливать бит low latency в пакетах, передаваемых по каналу управления, а бит high throughput — в пакетах, передаваемых по информационному каналу. В итоге такая команда FTP, как abort operation (прервать команду), будет передана на сервер по самому скоростному маршруту и соответственно за минимальное время (оперативно отменив при этом загрузку файла с сервера).

Почему же лишь немногие приложения поддерживают функции байта ToS? Да потому, что большая часть операционных систем, в среде которых они работают, не обеспечивает надлежащую поддержку этих функций. И до тех пор, пока Microsoft не модифицирует программный интерфейс WINSOCK.DLL системы Windows NT, поставщики приложений вроде Lotus Development, Netscape Communications и Oracle не смогут реализовать в своих приложениях механизмы управления приоритетами.

Тем не менее существуют способы, позволяющие обходить те проблемы, которые не спешат решать поставщики операционных систем и приложений. Самый верный из них — реализовать службы приоритезации трафика IP не в приложениях и операционных системах, а в устройствах сетевой инфраструктуры. Администраторы многих крупных и сильно загруженных сетей уже несколько лет осуществляют приоритезацию с помощью фильтров, устанавливаемых в маршрутизаторах отдельно для каждого приложения.

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

Существует немало средств для реализации в IP-сетях различных механизмов управления приоритетами, ориентированных на конкретные приложения. Эти механизмы можно связать со схемой приоритезации, определенной в спецификациях 802.1Q и 802.1p.