Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Приоритизация трафика в сетях IP

Эрик Холл

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

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

Изначально стандарт 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 не смогут реализовать в своих приложениях механизмы управления приоритетами.

Из клиентских ОС фирмы Microsoft поддержка функции SetSockpt реализована только в Windows98. Что же касается серверных ОС, то данную поддержку Microsoft собирается ввести только в Windows NT 5.0.

Помогает инфраструктура

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

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

Мы также считаем, что следует обратить внимание на программный продукт DynamicAccess фирмы 3Com, работающий с системами Windows 95 и Windows NT. С его помощью нам удалось организовать службы приоритизации непосредственно на узле-отправителе и узле-получателе, предоставив всей оставшейся части сети обрабатывать пакеты в соответствии с критериями, определенными в конечных узлах. При этом DynamicAccess не "страдает" от ограничений, накладываемых WINSOCK.DLL, поскольку является некой прослойкой между сетевыми протоколами и драйверами сетевых адаптеров NDIS 3.1. По существу, он контролирует пакеты, поступающие после обработки протоколами третьего уровня (IP или IPX), и перед отправкой их на драйверы сетевых адаптеров модифицирует биты приоритета и типа обслуживания. Это позволяет устанавливать уровни приоритета трафика IP в конечных точках сети.

Что день грядущий нам готовит?

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

А теперь держитесь! В этой области грядут существенные изменения. В подтверждение своих усилий, направленных на усовершенствование служб управления уровнями приоритетов в сетях поставщиков услуг Интернет, одна из рабочих групп IETF провела встречу, на которой обсуждались вопросы, связанные с изменениями фундаментальных основ байта ToS.

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

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

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





  
11 '1998
СОДЕРЖАНИЕ

колонка редактора

• Наперегонки со светом

локальные сети

• Внедрение приоритизации трафика в сети Ethernet

• Удаленная загрузка Windows 95

• В эпоху интеллектуальных зданий

• Консолидация информационно-вычислительных ресурсов

• Коммутаторы для рабочих групп: мал золотник, да дорог

• Цифровые мультиметры на страже безопасности

• Место коаксиальных кабелей вне локальных сетей

• Один дюйм или два?

бизнес

• О российском канале дистрибуции

• Профессор сетевых технологий

• Oracle побеждает в SQL-гонке

интернет и интрасети

• Приоритизация трафика в сетях IP

• Отладка работы PPP-соединений

• ISP все еще решают проблему пиринга

корпоративные сети

• Тестируем связующее ПО МОМ

• Платформам сетевого управления недостает лидера

услуги сетей связи

• IP-телефония: проблем хватает

• Предоставление услуг IN на сети МГТС

• Спутники облегчают доступ ко Всемирной паутине

• Мониторинг трафика Frame Relay: выгода налицо

• DSL: скорость и средства для ее контроля

• DSL: трудная дорога к стандартам

защита данных

• ИБП для централизованной системы бесперебойного гарантированного электроснабжения

системы учрежденческой связи

• Отечественные УАТС: с оптимизмом — в будущее

новые продукты

• PairView "найдет" потерянные пары; Простота и эффективность Novell Replication Services 1.21;



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх