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

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

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

Очевидное решение состоит в увеличении пропускной способности сети. Если у вас имеется магистраль Fast Ethernet, то модернизация ее до Gigabit Ethernet должна устранить все вопросы, не так ли? Иногда да, но широкий канал все же не гарантирует, что потоки реального времени будут прибывать в правильном порядке с минимальной задержкой.

Другое решение состоит во введении управления распределением пропускной способности в вашей сети, наиболее вероятно в виде аппаратных или программных продуктов, для контроля за сетевым трафиком и управления ресурсами глобальной сети более эффективным образом. Однако управление пропускной способностью вовсе не обязательно решает проблемы приложений реального времени. (Более подробное рассмотрение технологии и продуктов для управления пропускной способностью можно найти в статье "Оптимизация распределения пропускной способности" в LAN №2 за 1999 г.)

Чтобы справиться с потенциальным кошмаром передачи телефонного разговора по пакетной сети, вам не обойтись без обеспечения качества услуг (Quality of Service, QoS).

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

Некоторые из сетевых технологий типа ATM предусматривают меры обеспечения QoS изначально, поэтому стандарты и методы в области QoS нацелены на IP, Ethernet и другие пакетные сети без встроенной поддержки качества услуг.

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

Если обеспечение QoS в корпоративной сети можно поручить сотрудникам отдела ИС компании, то его гарантирование в пределах глобальной сети потребует тесного сотрудничества с провайдером услуг. Такие гарантии оговариваются обычно в соглашении об уровне сервиса (Service Level Agreement, SLA), представляющем собой контракт между провайдером и заказчиком (см. врезку "Уровни QoS, предлагаемые сервис-провайдерами").

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

ПРЕДВАРИТЕЛЬНОЕ РЕЗЕРВИРОВАНИЕ

Один из передовых стандартов в мире коммуникаций реального времени - это несомненно протокол H.323. Он состоит из множества спецификаций, определяющих, как мультимедийные приложения взаимодействуют друг с другом по сети, не гарантирующей QoS (включая Ethernet, Token Ring, IP и IPX). Эта группа стандартов под общим именем H.323 описывает аудио- и видеокодеки, сигнализацию вызовов и управление пропускной способностью.

Специально разработанный для сетей, не гарантирующих QoS, H.323 предоставляет специальную поддержку, необходимую приложениям реального времени. Одним из таких протоколов является протокол передачи в реальном масштабе времени (Real-Time Transfer Protocol, RTP) для доставки потокового аудио и видео по Internet.

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

RTP обходит ограничения TCP за счет использования UDP в качестве транспортного уровня для видеоконференций и других сервисов реального времени.

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

RTP может быть дополнен протоколом управления трафиком реального времени (Real-Time Control Protocol, RTCP) для мониторинга уровня QoS и передачи сеансовой информации между участниками сеанса.

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

При всей полезности RTP - далеко не панацея. Один из способов расширения возможностей RTP состоит в использовании его совместно с протоколом RSVP. Не входя официально в комплект протоколов H.323, RSVP поддерживается многими приложениями реального времени.

При использовании RSVP хост может от имени приложения запросить у сети определенный уровень QoS. Этот запрос может оговаривать такие параметры, как максимальная скорость пакетов, максимальная вариация задержки пакетов и максимальная задержка из конца в конец.

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

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

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

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

ДИФФЕРЕНЦИРОВАННОЕ ОБСЛУЖИВАНИЕ

Заведомо менее зрелая, но тем не менее многообещающая технология обеспечения QoS разрабатывается в настоящее время рабочей группой IETF по дифференцированному обслуживанию (Differentiated Services, DiffServ). Эта группа выделилась из рабочей группы по интегрированному обслуживанию (Integrated Services, IntServ), задача которой состоит в разработке стандартов для поддержки трафика Internet реального времени.

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

IntServ определяет три класса обслуживания для IP: по мере возможности - то, что сейчас предлагает Internet; с контролируемой загруженностью - приложение получает тот уровень обслуживания, какой оно имело бы в слабо загруженной сети, и с гарантированным обслуживанием - необходимая пропускная способность в течение всего сеанса предоставляется с гарантией на параметры качества обслуживания.

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

Дифференцированное обслуживание предлагает более простой и масштабируемый метод QoS для приложений реального времени.

Одним из ключевых моментов в работе над DiffServ является переопределение 8-битного поля "Тип сервиса" в заголовке Ipv4. Названное "Дифференцированным обслуживанием" (DS), это поле может содержать информацию, на основании которой узлы вдоль маршрута определяют, как им следует обрабатывать пакеты и передавать их следующему маршрутизатору.

В настоящее время только 6 из 8 бит в поле DS были определены, и только одно назначение было стандартизовано. Это назначение известно как принятое по умолчанию - Default (DE), - и оно определяет класс обслуживания по мере возможности. Другое предполагаемое назначение, срочная отправка (Expedited Forwarding, EF), должно обеспечить сокращение задержек и потерь пакетов.

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

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

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

МЕТКА НА MPLS

Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект IETF под названием "Многопротокольная коммутация меток" (Multiprotocol Label Switching, MPLS).

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

При IP-коммутации узел анализирует первые несколько пакетов поступающего трафика и, в случае короткой посылки, например запроса DNS или SNMP, обрабатывает их как обычный маршрутизатор. Но если узел идентифицирует длительный поток - от трафика telnet или ftp до загрузки файлов через Web и мультимедийных приложений, то IP-коммутатор переключается на нижележащую структуру ATM и применяет сквозную коммутацию для быстрой доставки данных адресату.

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

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

Одним из результатов возникшего конфликта явилось создание в рамках IETF группы MPLS, вносимые которой изменения в сети IP даже более существенны, чем в случае DiffServ.

Например, если DiffServ задействует заголовок DS, уже имеющийся в пакетах Ipv4, то MPLS использует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта метка, добавляемая при входе в сеть с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информацию о требуемом для данного пакета уровне QoS.

В отличие от поля DS, метка MPLS изначально не является частью пакета IP. Скорее, она добавляется при поступлении пакета в сеть и удаляется при выходе пакета из сети MPLS.

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

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

По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM, в мир пакетных сетей, связанных с IP. На практике MPLS можно использовать для доставки IP-трафика по сетям IP.

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

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

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

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

ВКЛАД IEEE

Хотя может показаться, что IETF узурпировала все сколько-нибудь интересные проекты в области стандартов для QoS, IEEE не стоит сбрасывать со счетов. Контролирующая разработку Ethernet, Token Ring и других сетевых стандартов группа изобрела изящный способ обработки традиционными коммутаторами второго уровня трафика приложений реального времени, в том числе передачи голоса, видео и информации.

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

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

На основании этого заголовка маршрутизаторы и коммутаторы (как на втором, так и на третьем уровне) могут принимать решения о приоритете трафика с учетом предопределенных правил, заданных администратором сети.

Стандарт 802.1p призван обеспечить QoS при коммутации в локальных сетях, поэтому он может быть не столь привлекательным, как рассмотренные выше технологии для глобальных сетей. Однако помните, что при передаче локального трафика многие компании опирались и продолжают опираться на Ethernet. И, кроме того, в наши дни даже от протоколов локальных сетей требуется поддержка аудио- и видеопотоков реального времени.

ЛУЧШЕ, ЧЕМ ПО МЕРЕ ВОЗМОЖНОСТИ

Internet доставляет информацию из одного места в другое по мере возможности имеющихся ресурсов. Даже если компания создала частную сеть Intranet на базе IP, то ей приходится мириться с отсутствием поддержки QoS в пакетных сетях. То же самое справедливо в отношении Ethernet, гигабитная разновидность которой используется многими компаниями на уровне территориальной магистрали.

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

Анита Карве - помощник редактора Network Magazine. С ней можно связаться по адресу: akarve@mfi.com.

Уровни QoS, предлагаемые сервис-провайдерами

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

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

Один из способов сделать это - заключение соглашений об уровне сервиса (Service Level Agreement, SLA), т. е. контрактов, где четко указано, какого уровня доступность, сервисы и цены ожидает получить заказчик. В таком соглашении сервис-провайдеры должны гарантировать срок бессбойной работы и длительность задержки в конкретное время суток для конкретных видов приложений. Оно также может содержать информацию о доступности пользовательского соединения.

SLA должно также определять, какие сервисы и, что более важно, гарантии обслуживания предлагаются для каждого класса трафика. Кроме того, оно должно указывать пропускную способность (скорость, с которой пакеты передаются по сети), задержку (время между отправкой и приемом пакетов на конечных станциях), процент потерянных пакетов (максимально возможное число удаленных при передаче пакетов) и вариацию задержки (разницу во времени доставки пакетов из одного потока).

Как в случае SLA, для VPN заказчик должен поинтересоваться у провайдера о том, какого рода обслуживание он может ожидать получить.

Сервис-провайдер может определить два или более уровней QoS и взимать за них соответствующую плату. Наинизший уровень QoS может использоваться для доставки данных по мере возможности по типу Internet. Более высокий уровень обслуживания - для критически важных данных, таких, как приложения ERP, с низким процентом потерянных пакетов и контролируемой задержкой. Самый высокий уровень обслуживания - для приложений реального времени типа видеоконференции и видеосвязи; этот уровень должен характеризоваться очень малой задержкой и вариацией задержки, а также очень низким процентом потерянных пакетов.

Заказчики должны иметь способ мониторинга реального уровня QoS. Это может делаться посредством аудита журналов сетевых ресурсов. Сервис-провайдеры также должны вести учет, чтобы быть уверенными, что они выполняют условия контракта.

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

Ресурсы Internet

Дополнительную информацию о протоколе RSVP, включая общий обзор, а также перечень версий программного обеспечения, поддерживающего RSVP, смотри на http://www.isi.edu/div7/rsvp/.

Подробное рассмотрение протокола RTP, включая его реализации, имеется на http://www.cs.columbia.edu/~hgs/rtp/.

Дальнейшая информация о MPLS, включая ссылку на IETF, может быть найдена на http://www.employees.org/~mpls/.

Познакомиться с инициативами IEEE 802.1p и 802.1Q можно на http://grouper.ieee.org/groups/802/1/index.html.