Проблема обеспечения качества сервиса (QoS) в глобальных сетях стала весьма актуальной из-за кардинальных изменений в телекоммуникационной отрасли.
Одно из них связано с конвергенцией: некогда различные инфраструктуры, предназначенные для передачи голоса, видео и данных, сменились единой коммуникационной средой. Появление смешанного трафика и постоянный рост его объема стали серьезными угрозами для функционирования сети. А перевод в сетевую среду приложений, предъявляющих различные требования к уровню обслуживания трафика, потребовал от операторов внедрения новых механизмов его обработки.
Второе существенное изменение заключается в том, что по мере удовлетворения спроса на базовые услуги связи выживание телекоммуникационных компаний все больше зависит от способности предлагать потребителям сервисы нового типа. Фундаментом для их внедрения стали технологические достижения последнего десятилетия — усовершенствованные алгоритмы обработки очередей, Web-кэширование, глобальные службы каталогов, шифрование данных. Однако решающую роль в предоставлении услуг приемлемого качества сыграло развитие технологий транспортировки и маршрутизации, учитывающих специфику конкретного вида трафика.
На пути к качеству
Надо отметить, что, несмотря на повсеместную распространенность аббревиатуры QoS, в нее по-прежнему вкладывают разный смысл. Если отвлечься от расширительных толкований, то под качеством сервиса следует понимать обеспечение предсказуемости процесса передачи трафика, то есть способность сетевых компонентов (приложений, компьютеров, маршрутизаторов) гарантировать доставку трафика адресату с требуемыми параметрами. Для достижения этого результата применяются два основных подхода:
- резервирование ресурсов по запросу приложения на основе стратегии управления пропускной способностью (интегрированные сервисы);
- маркировка трафика и выделение необходимых ресурсов разным классам трафика с учетом их приоритета (дифференцированные сервисы).
При этом ресурсы могут выделяться как отдельному потоку данных (он определяется транспортным протоколом, адресом и номером порта источника, адресом и номером порта получателя), так и агрегату из нескольких потоков, часть параметров которых совпадает.
Характеризуя качество сервиса, можно использовать следующие базовые показатели: доступность услуги, задержка передачи, флуктуации задержки, вероятность потерь пакетов и скорость передачи. Поскольку для разных приложений первостепенное значение имеют различные величины, удовлетворить подчас противоречивые запросы «одним махом» не удается.
Скажем, для запуска в сети видеоприложений недостаточно просто увеличить суммарную полосу пропускания, поскольку такая мера не позволяет избежать значительных флуктуаций задержки при всплесках трафика. Более того, и в слабо загруженной сети задержка может сильно изменяться, что отрицательно сказывается на работе приложений реального времени. Чтобы обеспечить предсказуемое поведение различных сервисов, сеть надо наделить интеллектуальными средствами, способными отличать трафик со строгими требованиями к временным параметрам передачи от трафика, для которого конкретные значения этих параметров не столь критичны, и соответствующим образом управлять распределением полосы пропускания.
В первой половине 90-х годов большие надежды в обеспечении QoS возлагались на режим асинхронной передачи (ATM) и основанные на нем технологии (скажем, IP-over-ATM). Однако со временем все явственнее стали ощущаться недостатки такого решения — сложность технологии, высокая доля «накладных расходов», дороговизна оборудования в пересчете на 1 Мбит/с пропускной способности и др. Кроме того, распространение оптических сетей, особенно основанных на спектральном мультиплексировании (WDM, DWDM), означало, что у некогда незаменимой ATM появились достойные альтернативы.
Свою роль сыграл и повсеместный переход на IP. Преобразование IP-пакетов в 53-байтные ячейки ATM и обратно, мягко говоря, не отличается высокой эффективностью. Это обстоятельство также обусловило необходимость разработки новых транспортных технологий.
К сожалению, протокол IP изначально не был рассчитан на дифференцированную обработку потоков разных типов. Поддерживаемая им дисциплина обслуживания best effort обеспечивала хорошую масштабируемость сети и простую функциональность ее ядра, поскольку вся «интеллектуальная» работа возлагалась на оконечные устройства. Даже когда потребности сетевых приложений превышают возможности IP-сети, это не вызывает полного отказа в обслуживании одних видов трафика и сохранения сервиса для других, а приводит к снижению качества сервиса для пакетов всех типов. Такое положение вещей нельзя признать удовлетворительным, тем не менее при создании протоколов, предназначенных для поддержки QoS, ставилась цель сохранения общих архитектурных принципов IP-сетей, прежде всего — упомянутой схемы «разделения труда» между магистральным оборудованием и периферийными устройствами.
В современных глобальных сетях для поддержки качества сервиса применяется несколько протоколов: RSVP, DiffServ, MPLS. Кроме того, для реализации той или иной схемы QoS немаловажное значение имеют такие алгоритмы управления очередями, как Class Based Queuing (CBQ), Random Early Drops (RED), Weighted Fair Queuing (WFQ). Правда, для приложений функционирование этих алгоритмов является прозрачным, а потому они не являются протоколами QoS в строгом смысле слова. Выбор конкретной технологии QoS зависит от типа сетевых приложений, топологии сети и политики администрирования.
Резервирование ресурсов
Протокол сигнализации Resource reSerVation Protocol (RSVP) обеспечивает управление резервированием сетевых ресурсов в IP-сети для реализации интегрированных сервисов (Integrated Services, IntServ). Первоначальная его спецификация, разработанная сотрудниками Университета шт. Южная Каролина и компании Xerox, была опубликована консорциумом IETF в 1997 году (RFC 2205). Около трех лет назад появилась обновленная версия RSVP (RFC 2750). Архитектура IntServ впервые описана в 1994 году в документе RFC 1633.
Протокол RSVP предусматривает два принципиально различных типа сервисов — гарантированный (IntServ Guaranteed) и с контролируемой сетевой нагрузкой (IntServ Controlled). В первом случае речь идет об эмуляции выделенного виртуального канала в IP-сети: потоку гарантируется доступность запрошенной полосы пропускания и одновременно задаются жесткие границы для величины суммарной задержки. Сервис IntServ Guaranteed можно воспринимать как формирование сети коммутации каналов, наложенной на сеть коммутации пакетов. Второй случай аналогичен сервису best effort в условиях незагруженной сети; конкретные диапазоны задержек и других параметров передачи не устанавливаются.
Не вдаваясь в детали, работу протокола RSVP можно представить следующим образом (рис. 1). Источник данных отправляет одному или нескольким получателям сообщение PATH, в котором содержится спецификация трафика (нижняя и верхняя границы полосы пропускания, максимальная задержка и ее неравномерность). Каждый поддерживающий RSVP маршрутизатор, расположенный на пути предполагаемого следования трафика, при получении сообщения PATH запоминает содержащиеся в нем параметры потока и адрес узла, от которого поступило данное сообщение, после чего транслирует его на следующий узел.
Собственно резервирование ресурсов инициируется получателем, который после приема сообщения PATH отправляет в обратном направлении (источнику) запрос RESV. Помимо характеристик трафика, полученных от источника, этот запрос содержит спецификации потока (тип сервиса и ряд вспомогательных параметров) и фильтра (транспортный протокол и номер порта). Две последние спецификации играют роль дескриптора потока.
При получении запроса RESV очередной маршрутизатор производит аутентификацию запроса и выделяет требуемые ресурсы. Если запрос не может быть удовлетворен, источнику отправляется сообщение об ошибке, в противном случае запрос RESV отсылается дальше в восходящем направлении. Наконец, если последний маршрутизатор (то есть расположенный ближе всего к источнику) также в состоянии удовлетворить запрос RESV, он отправляет получателю подтверждающее сообщение.
После этого начинается передача данных. Поддерживающие RSVP маршрутизаторы отправляют поступающие пакеты на классификатор, который отвечает за их приоритизацию. Затем пакеты помещаются в буферные очереди. Распределение пакетов по классам сервиса осуществляет пакетный фильтр, он же определяет маршрут их дальнейшего следования. Управление очередями пакетов и выделение ресурсов для их транспортировки относятся к сфере компетенции диспетчера пакетов.
Ресурсы могут выделяться потокам на индивидуальной либо разделяемой основе. При индивидуальном резервировании в каждом сеансе для каждого отправителя формируется отдельный поток. Разделяемый режим означает, что несколько отправителей могут использовать один и тот же поток, если они не создают друг другу помех.
Выбор режима определяется спецификацией фильтра. Для фиксированного фильтра (Fixed Filter, FF) используется индивидуальное резервирование: каждому отправителю соответствует отдельный запрос RESV, а общая емкость выделенных ресурсов определяется совокупностью запросов к явно заданному набору отправителей. (Если несколько получателей ожидают трафик от одного и того же отправителя, их запросы объединяются, а ресурсы выделяются на разделяемой основе.) Спецификация фильтра с явным указанием отправителей применяется и для разделяемого резервирования (Shared Explicit, SE), только потоки от источников, перечисленных в запросе RESV, используют одни и те же ресурсы. Неявная спецификация (Wildcard Filter, WF) предполагает, что по единому виртуальному каналу будет передаваться трафик от всех отправителей.
Фильтры SE и WF подходят для обработки многоадресного трафика, например при проведении аудиоконференций. Применение FF предпочтительнее для передачи видеосигналов.
Следует отметить несколько принципиальных особенностей механизма резервирования ресурсов в рамках RSVP, отличающих его от других протоколов:
- сам по себе протокол RSVP не отвечает за транспортировку или маршрутизацию данных, а лишь управляет этими процессами, а потому может функционировать параллельно с TCP или UDP;
- RSVP ориентирован только на полудуплексную передачу, и для двустороннего обмена требуется устанавливать два самостоятельных сеанса RSVP;
- каждый маршрутизатор выделяет ресурсы на ограниченный промежуток времени (soft reservation), в течение которого получатель должен успеть обновить свой запрос RESV. Процедура периодического обновления полезна для оперативного реагирования на изменения маршрутов и состава групп многоадресной рассылки;
- при передаче трафика через несколько сетей на его пути могут встретиться устройства, не поддерживающие RSVP. Протокол применим и в этом случае (вариант с туннелированием), хотя вне доменов RSVP можно рассчитывать только сервис best effort;
- ключевая роль получателей в резервировании ресурсов позволяет выделять последние для многоадресного трафика даже в том случае, когда спецификации, поступающие от разных получателей, различны. Для их обработки используется схема «вложения» запросов в узлах тиражирования трафика.
С точки зрения поддержки на уровне приложений и сетевых устройств протокол RSVP является, пожалуй, самым сложным из всех аналогичных технологий. Радикальное отступление от принципа best effort позволяет достичь наивысшего уровня сервиса в плане гарантированности параметров передачи, степени детализации при описании запрашиваемых ресурсов и качества обратной связи с приложениями. Применение архитектуры IntServ и протокола RSVP оказывается идеальным выбором для поддержки приложений реального времени, но в других случаях обеспечиваемый уровень QoS становится ненужным, а «цена» (излишняя сложность конкретных реализаций) — неоправданно высокой. Это обстоятельство обусловило появление не столь изощренных методов поддержки QoS в глобальной сетевой среде, одним из которых является DiffServ.
Дифференцированные услуги
Разработка технологии Differentiated Services (DiffServ) стала попыткой преодолеть недостатки, присущие протоколу RSVP, прежде всего его плохую масштабируемость. В самом деле, в крупной сети число потоков огромно, и для каждого из них сетевые узлы должны хранить спецификации потока, запроса и фильтра, а также ряд дополнительных сведений. Обработка этой информации способна привести к снижению общей производительности маршрутизаторов. Кроме того, использование упомянутого механизма «мягкого» резервирования ресурсов означает, что в сети постоянно циркулирует несметное число сообщений PATH и RESV.
Технология DiffServ предлагает простой и вследствие этого довольно грубый метод приоритизации трафика в соответствии с требованиями различных приложений. Ее основы были изложены в 1998—1999 годах в документах RFC 2474, 2475, 2597 и 2598.
DiffServ подразумевает отнесение пакетов к тому или иному классу обслуживания (так называемому агрегатору поведения, BA) с помощью маркеров — кодовых слов (DiffServ Code Point, DSCP), помещаемых в заголовки каждого IP-пакета. Все операции маркировки пакетов и кондиционирования трафика (то есть его фильтрации и формирования) по-прежнему реализуются на границе между сетями клиента и провайдера (рис. 2), а магистральным устройствам остается лишь дифференцированно обслуживать небольшое число классов трафика.
Приоритет вкупе с методом обслуживания пакета маршрутизатором называется типом локального поведения (Per Hop Behavior, PHB). Собственно, аббревиатурой PHB обозначается набор процедур, которые должны быть использованы для отправки потока пакетов с одним и тем же DSCP на выходной интерфейс маршрутизатора. Очевидно, что различия между типами локального поведения будут существенны, когда потоки, относящиеся к разным классам обслуживания, начнут конкурировать за ограниченные ресурсы (буферное пространство маршрутизатора, пропускную способность выходного канала). Поддержка определенных типов PHB или их групп в узлах сети реализуется путем применения различных алгоритмов управления очередями и буферным пространством.
Двумя основными типами локального поведения являются Expedited Forwarding (EF) и Assured Forwarding (AF).
Первый позволяет сформировать в среде DiffServ виртуальную выделенную линию для высокоскоростной передачи трафика с минимальными значениями задержки, ее вариабельности и вероятности потерь. Чтобы гарантировать пропускную способность не ниже заданного уровня, следует добиться выполнения очевидного условия: суммарная скорость прибытия в сетевой узел потока, относящегося к данному агрегатору поведения, не должна превышать скорости отправки. На помощь приходят специальные процедуры кондиционирования трафика и настройки конфигурации сетевых узлов. Кроме того, необходимо изолировать потоки, относящиеся к разным агрегаторам поведения, предусмотреть выделение минимального объема сетевых ресурсов трафику с наименьшим приоритетом (иначе он может оказаться полностью заблокированным), обеспечить автоматическое отбрасывание пакетов, которые не соответствуют спецификации кондиционирования, дабы не допустить возрастания параметра задержки.
Тип локального поведения Assured Forwarding ориентирован на передачу IP-трафика с определенными количественными показателями качества обслуживания. Он может использоваться для организации VPN на базе сети передачи данных оператора. Если интенсивность трафика не превышает порогового значения, определенного в спецификации кондиционирования, его обработка с высокой вероятностью будет соответствовать заявленному агрегатору поведения. Однако, в отличие от EF, в данном случае трафик, чьи параметры выходят за установленные границы, не будет отброшен, а получит меньший уровень QoS (например, возрастет задержка или доля отброшенных пакетов). Принципиальном моментом является сохранение первоначального порядка следования пакетов в потоке. Очевидно, что приоритет трафика AF должен быть ниже, чем у трафика EF, но выше, чем у трафика, обслуживаемого по принципу best effort.
В рамках AF предусмотрено четыре класса сервиса и для каждого из них — три значения вероятности потерь пакетов. Получающаяся 12-уровневая схема достаточно гибка с точки зрения приоритизации трафика, особенно если учесть, что при возникновении перегрузки для сервисов AF можно задействовать ресурсы, отведенные под другие классы (если отнесенный к ним трафик отсутствует). А поскольку в спецификациях типов поведения AF параметры задержки передачи и ее флуктуаций не фигурируют, метод обслуживания AF допустимо применять к потокам с изменяющейся скоростью (например, в случае предоставления услуг «аудио/видео по запросу»).
Простота схемы приоритизации трафика средствами DiffServ иногда порождает ошибочное мнение об ограниченных возможностях данной технологии. В действительности DiffServ может применяться в сочетании с другими технологиями QoS в глобальной сети, что позволяет классифицировать различные виды трафика по значению постоянной скорости передачи (CBR) и выделять необходимую полосу пропускания для предварительно сформированных агрегированных потоков.
Коммутация по меткам
Технология многопротокольной коммутации по меткам (MultiProtocol Label Switching, MPLS) возникла во второй половине 90-х годов в попытке выработать единый стандарт на базе множества патентованных алгоритмов многоуровневой коммутации. Она чем-то схожа с DiffServ, поскольку здесь также используется маркировка пакетов на входе в сеть MPLS, а их передача напоминает транспортировку трафика по виртуальному каналу в сетях ATM или frame relay. Существенное различие между этими технологиями заключается в том, что в сети MPLS присвоение меток нацелено на определение следующего узла на пути следования пакетов, тогда как в DiffServ во главу угла ставится приоритизация трафика.
Таким образом, поддержка MPLS должна обеспечиваться только на маршрутизаторах; компьютеры пользователей и приложения никакого отношения к ней не имеют. К тому же, как явствует из самого названия, технология MPLS может применяться в сочетании с различными протоколами канального и сетевого уровней.
Технология MPLS в первую очередь ориентирована не на реализацию конкретной схемы QoS, а на формирование трафика и оптимизацию процесса его маршрутизации. Тем не менее, как показала практика последних лет, ее применение позволяет реализовать гибкое управление сетевыми ресурсами, без которого реализация современных схем QoS невозможна.
Подробный анализ технологии MPLS и смежных вопросов содержится в обзоре «MPLS меняет роли», публикуемом в этом же номере «Сетей».
Объединенными усилиями
Рассмотренные протоколы QoS не исключают, а дополняют друг друга, поэтому во многих случаях применяются совместно (особенно когда требуется сквозное качество сервиса в среде, состоящей из сетей нескольких провайдеров). Комбинированный подход позволяет реализовать требуемую схему QoS на всем пути передачи трафика от отправителя к получателю. Он же обеспечивает поддержку QoS «по вертикали» (от канального до прикладного уровня модели OSI), без которой механизм приоритизации будет нарушен. В поддержании сквозной схемы качества обслуживания немаловажную роль играет наличие средств QoS в локальной сети. Распределение ролей между протоколами QoS показано на рис. 3.
Рассмотрим вкратце результаты использования протоколов QoS в различных сочетаниях.
RSVP и DiffServ. Технология DiffServ может рассматриваться в качестве удачного дополения к RSVP, поскольку она обеспечивает маркировку и приоритизацию трафика, для которого RSVP выделяет необходимые ресурсы. Так как протокол RSVP сложнее DiffServ и создает значительную нагрузку на маршрутизаторы, его применение в магистральных сетях стоит ограничить, воспользовавшись вместо этого возможностями DiffServ. Другими словами, RSVP-запросы должны генерировать подключенные к сети компьютеры, определяя необходимый уровень обслуживания, а граничные маршрутизаторы — преобразовывать требования о выделении ресурсов в агрегаторы поведения, которые задаются кодовыми словами DSCP.
MPLS и RSVP. Один из способов реализовать данную комбинацию — использовать в среде RSVP явное указание маршрутов следования пакетов, снабженных MPLS-метками. Фактически составленные из этих пакетов потоки будут передаваться по виртуальным каналам, образованным поддерживающими MPLS маршрутизаторами. Но и при отсутствии явно заданных маршрутов MPLS-метки могут присваиваться в соответствии с RSVP-спецификациями потоков. В любом случае применение меток существенно упрощает задачу поддержки RSVP маршрутизаторами, которым уже не нужно обрабатывать информацию о состояниях RSVP.
MPLS for DiffServ. Схожесть этих технологий заставляет предположить, что транспортировка трафика DiffServ в среде MPLS не вызовет больших затруднений. Тем не менее поддержка DiffServ на уровне отдельных соединений требует резервирования в каждом из маршрутизаторов сети MPLS ресурсов для передачи трафика DiffServ отдельных классов и реализации схемы присвоения меток. Кроме того, с каждым пакетом придется сопоставить один из трех уровней потерь, предусмотренных типом локального поведения AF.
Завершая рассмотрение совместного использования протоколов QoS, нельзя не упомянуть об одной принципиальной проблеме. Как уже говорилось, достижение в сетях с поддержкой DiffServ и MPLS более высокого уровня сервиса, чем простой best effort, возможно лишь в том случае, когда интенсивность входящего трафика не превышает пропускной способности формируемых виртуальных каналов. Между тем технологии DiffServ и MPLS не предусматривают механизмов предварительного вычисления полосы пропускания, которую потребуется зарезервировать. Эту задачу способен решить только RSVP.
Таким образом, без самого сложного из протоколов QoS не обойтись. Причем он нужен для выделения ресурсов не только потокам, генерируемым отдельными приложениями, но и общим классам трафика, в которые объединяются потоки индивидуальных сеансов.
Источники дополнительной информации
Подробное описание протокола RSVP можно найти в журнале Сети (1999, № 10, с. 102) или в Internet по адресу www.cisco.com/univercd/cc/td/doc/cisintwk/ ito_doc/rsvp.htm. Технологии DiffServ посвящен большой обзор в Сетях (2000, № 8, с. 22; № 9, с. 28), а также технические материалы, собранные на Web-странице www.itpapers.com/cgi/SearchIT.pl?scid=45&search=DiffServ.
Количество публикаций о технологии MPLS и смежных вопросах поистине необъятно, часть их собрана на специализированном сайте www.mplsrc.com. Неплохим источником информации могут служить и технические обзоры Data Connection (www.dataconnection.com/network/whitepapers.htm) и Foundry Networks (www.foundrynetworks.com/technologies/ mpls/index.html). Наконец, первичным источником информации являются документы RFC, доступные на сайте www.ietf.org/rfc.html.
Сверху донизу
Для реализации сквозной схемы QoS между приложениями, общающимися друг с другом через глобальную сеть, необходимо организовать поддержку QoS в соответствующих локальных сетях и на различных уровнях эталонной модели OSI. Смысл последнего требования станет очевидным, если учесть, например, что средства DiffServ функционируют на третьем уровне, а RSVP — еще выше.
Механизм маркировки и приоритизации пакетов в коммутируемых сетях Ethernet определен хорошо известными стандартами IEEE 802.1p/Q и 802.1D. Одним из вариантов взаимодействия сетевых технологий второго уровня (разделяемый и коммутируемый варианты Ethernet, Token Ring, FDDI) с вышележащими протоколами и сервисами QoS является сигнальный протокол Subnet Bandwidth Management (SBM), предложенный консорциумом IETF. Он обеспечивает координацию работы коммутаторов и других сетевых узлов, а также кондиционирование трафика с учетом требований протоколов QoS для глобальных сетей.
Основными логическими компонентами архитектуры SBM являются модуль резервирования полосы пропускания (Bandwidth Allocator, BA) и модуль преобразования запросов (Requestor Module, RM). Первый помимо выделения ресурсов отвечает за управление доступом в соответствии с установленными правилами администрирования, а второй выполняет преобразование схемы приоритизации пакетов на канальном уровне в соответствующие параметры QoS на более высоких уровнях (и наоборот). RM устанавливаются на всех конечных станциях, а модули BA могут находиться только на одном коммутаторе (централизованная архитектура) либо на коммутаторах и рабочих станциях (распределенная архитектура).
В сети, поддерживающей SBM, весь трафик должен проходить хотя бы через один SBM-коммутатор. При этом данный протокол обеспечивает обмен служебной информацией между RM и BA, а также между различными BA для инициации процесса выделения полосы пропускания, определения доступных ресурсов, отмены ранее произведенного резервирования и т. д.
Функционирование SBM не зависит от протокола QoS, но само по себе реализуется через генерацию запросов (сначала отправителем, а затем получателем) и тем напоминает работу протокола RSVP. Отличия же связаны со схемой классификации трафика, принятой в ЛС. В частности, при использовании SBM маршрутизаторы глобальной сети, получая сообщения PATH или RESV, должны запоминать один из восьми уровней приоритета, которые задаются соответствующим значением в заголовке 802.1Q. Точные параметры соответствующих им классов обслуживания могут меняться, однако по умолчанию принято, например, что нулевой приоритет соответствует дисциплине best effort, четвертый — обработке трафика, чувствительного к задержкам (без установления порога), а шестой — передаче трафика с задержкой не более 10 мс. Последний, седьмой уровень отведен для пересылки управляющей информации.