Благодаря отсутствию необходимости изменять приложения и другим преимуществам дифференцированное обслуживание пользуется все большим вниманием.
Разработкой методов предоставления дифференцированных услуг (Differentiated Services, DS) в настоящее время занимается рабочая группа IETF DS. Однако технические требования для DS в сети Internet пока еще не приняты и не опубликованы в виде RFC. Поэтому сегодня мы можем дать только обзор базовых идей и принципов дифференцированного обслуживания в Internet. При этом читателю следует иметь в виду, что некоторые из рассмотренных технических требований могут быть изменены на конечной стадии стандартизации дифференцированных услуг.
Цель введения DS состоит в предоставлении дифференцированного обслуживания для различных типов приложений в сети Internet. DS обеспечивают передачу трафика с предсказуемыми параметрами (задержкой, пропускной способностью, показателем числа потерь пакетов и т. д.). Различие между интегрированными и дифференцированными услугами состоит в том, что в случае DS трафик Internet разбивается на различные классы со своими требованиями к параметрам QoS, при этом резервирование ресурсов на каждом транзитном узле для каждого отдельного потока в целях обеспечения качества обслуживания не производится.
Центральный компонент DS — соглашение об уровне сервиса (Service Level Agreement, SLA). SLA — это сервисный контракт между клиентом и провайдером услуг с подробным перечнем предоставляемых услуг. Клиентом может быть отдельный пользователь, организация или любой другой объект DS. Провайдер услуг должен гарантировать, что трафик клиента, с которым у него заключено SLA, будет обслуживаться в соответствии с оговоренными параметрами QoS. Поэтому администрация сети провайдера для выполнения своих контрактных обязательств должна определить соответствующую сервисную политику и осуществлять контроль за качеством предоставляемых услуг.
Чтобы отличить принадлежащие разным клиентам пакеты данных, поддерживающие DS устройства изменяют содержимое определенного поля в IP-пакете. Обработка пакета сетевым узлом производится в соответствии со значением этого поля. Байт DS расположен в октете TOS в заголовке протокола IPv4 и в поле класса трафика в заголовке протокола IPv6. Весь сетевой трафик внутри домена получает обслуживание в зависимости от указанного в байте DS класса трафика.
Для гарантированного предоставления предусмотренных в SLA услуг в сети должны быть реализованы следующие механизмы:
- задание битов в байте DS (поле TOS) для определения административных границ сети;
- использование этих битов для сообщения маршрутизаторам внутри сети о способе обработки этих пакетов;
- создание условий для прохождения отмеченных пакетов в заданных границах сети в соответствии с параметрами QoS для каждого класса обслуживания.
В настоящее время IETF определена асимметричная архитектура системы с предоставлением DS, в соответствии с которой дифференцированное обслуживание производится только в одном направлении передачи. Симметричная архитектура находится пока на стадии разработки.
АРХИТЕКТУРА СИСТЕМЫ
В отличие от интегрированной, сеть с дифференцированными услугами обеспечивает соблюдение параметров QoS за счет долгосрочных настроек маршрутизаторов. Это означает, что приложениям DS не требуется производить резервирование ресурсов для индивидуальных потоков данных. Весь передаваемый через сети с поддержкой DS трафик будет обслуживаться в соответствии с определенными параметрами QoS. При этом все пакеты данных должны иметь непустой байт DS для их интерпретации маршрутизаторами.
Как было отмечено, рабочая группа IETF DS предложила переопределить назначение поля TOS в IPv4 и поля класса трафика в IPv6. Определение поля TOS заменяется на определение байта DS в протоколе IPv4, как это описано в документе RFC 1349.
Шесть битов поля DS используются в качестве кодов для определения вида предоставляемых дифференцированных услуг (Differentiated Services CodePoint, DSCP). Они служат для выбора необходимого класса обработки трафика на каждом транзитном узле.
Любое сетевое устройство с поддержкой DS знает о том, как пакеты должны быть обработаны в зависимости от значения байта DS. В технических требованиях на DS эта информация называется "Режим на переходе" (Per-Hop Behavior, PHB) и предназначена для индикации способа обработки пакета на сетевых узлах. Для предсказуемого предоставления услуг все маршрутизаторы в сети должны поддерживать все режимы обслуживания PHB. Режим PHB можно рассматривать как совокупность параметров, в соответствии со значением которых маршрутизатор устанавливает порядок направления пакетов на интерфейс вывода. Это могут быть отдельные очереди с заданными приоритетами, определенные параметры для установления длины очереди или алгоритмы удаления пакетов из обращения в зависимости от их приоритета и веса.
Для поддержки DS маршрутизаторы должны обеспечивать планирование очередей, упорядочение выходных пакетов по приоритетам и контроль за размером очереди для минимизации перегрузки в сети. Традиционная организация очереди по принципу FIFO в обычных маршрутизаторах Internet не гарантирует дифференцированного обслуживания и может привести к возникновению проблем в сети. Способы обработки пакета внутри маршрутизатора зависят от возможностей самого маршрутизатора, его конфигурации и содержимого байт DS в пакете IP. Например, если пакет IP поступает на маршрутизатор с поддержкой восьми различных очередей, каждая со своим приоритетом, то байт DS может использоваться для выбора соответствующей очереди.
Вместе с тем маршрутизатор может иметь единственную очередь со множественными приоритетами для различных пакетов данных. В этом случае байт DS используется для выбора приоритета пакетов в очереди. Ноль в байте DS означает "наибольшую вероятность прохождения этого пакета", а семь — "наименьшую вероятность прохождения этого пакета". Другая возможная реализация — это организация четырех очередей с двумя уровнями приоритетов в каждой.
Чтобы маршрутизаторы обрабатывали один и тот же пакет одинаково, разрабатываемыми техническими требованиями должен быть определен некий стандартизованный режим PHB при предоставлении DS. Это означает, что техническими требованиями к DS должны быть заданы некоторые уникальные значения режима PHB для предоставления определенных классов обслуживания. Все маршрутизаторы в одном домене DS должны уметь обрабатывать пакеты с определенным режимом(-ами) PHB.
Режим PHB будет также определен и для групп. Группа режимов PHB — это набор одинаковых или различных режимов PHB, каждый из которых может быть реализован одновременно с другими при обслуживании очереди или управлении очередями. Режим РНВ по умолчанию должен соблюдаться всеми узлами с поддержкой DS. При отсутствии каких-либо соглашений все пакеты считаются принадлежащими к этому сервисному уровню. Рабочая группа IETF рекомендует использовать для задания режима PHB по умолчанию значение DSCP в байте DS, равное "000000".
Другой предложенный для стандартизации режим PHB — это срочное отправление (Expedited Forwarding, EF). Этот режим обеспечивает высокоприоритетную обработку трафика управления сетью, например для сообщений об изменении маршрутов. Рекомендованное значение для EF PHB в поле DSCP байта DS — "101100".
ДОМЕНЫ ДИФФЕРЕНЦИРОВАННОГО ОБСЛУЖИВАНИЯ
Рабочая группа IETF определяет домен с предоставлением дифференцированных услуг (домен DS) как смежную часть сети Internet, в которой дифференцированные услуги предоставляются согласованным образом. Это могут быть различные административные домены или автономные системы, различные трастовые (доверительные) области, области с различными сетевыми технологиями и т. д. Домен DS имеет в своем составе граничные устройства для организации взаимодействия между различными доменами DS. Эти граничные устройства связаны с внутренними (см. Рисунок 1).
Домен DS обычно состоит из одной или нескольких сетей с единым административным управлением. Это может быть, например, корпоративная сеть Intranet или сеть провайдера услуг. Администрация домена DS отвечает за подготовку к работе и резервирование необходимых ресурсов для обеспечения выполнения SLA. Сетевые администраторы должны располагать соответствующими методами контроля за наличием требуемого объема ресурсов в домене DS для удовлетворения всех законных запросов на параметры QoS.
ГРАНИЦЫ ДОМЕНОВ DS
При передаче из одного домена DS в другой все пакеты данных должны проходить через граничное устройство, каковым может быть маршрутизатор, рабочая станция или сетевое устройство защиты. Обрабатывающее исходящий трафик граничное устройство домена DS называется выходным, а обрабатывающее входящий DS-трафик граничное устройство — входным. Обычно граничные устройства доменов DS действуют и как входные, и как выходные, в зависимости от направления трафика. Входное граничное устройство должно обеспечить входящим в домен пакетам то же качество обслуживания, какое они имели в домене, из которого поступили. Выходное граничное устройство домена DS выполняет согласование условий поступления выходного трафика в соседний домен. Определение необходимых условий для этого трафика осуществляется внутри граничного устройства формирователем трафика (traffic conditioner). Формирователь трафика состоит из следующих компонентов.
- Классификатор (Classifier). Классификатор выбирает пакеты в зависимости от заголовка и передает их на дальнейшую обработку в соответствии с заданными правилами. Модель DS определяет два типа классификаторов пакетов:
- универсальные (Multi-field, MF) могут классифицировать пакеты как по байту DS, так и по любому другому полю заголовка пакета IP, например по адресу IP и номеру порта, подобно классификатору протокола RSVP;
- агрегатные (Behavior Aggregate, BA) классифицируют пакеты только по битам байта DS.
- Измеритель (Meter). Измеритель трафика оценивает скорость поступления трафика каждого класса. Эта скорость сравнивается затем с оговоренными в SLA параметрами трафика. В зависимости от результатов измеритель помечает пакеты как отвечающие или не отвечающие параметрам трафика для их последующей обработки в соответствии с заданными правилами.
- Маркер (Marker). Маркеры DS задают специфическую комбинацию двоичных разрядов байта DS приходящих пакетов IP. Режим PHB определяется первыми шестью битами байта DS таким образом, чтобы отмеченные пакеты соответствовали заключенному между провайдером услуг и клиентом SLA.
- Формирователь/отбрасыватель (Shaper/Dropper). Формирователь и отбрасыватель используют некоторые конфигурационные описатели трафика, например маркерный фильтр области памяти. Они различными методами согласуют поток с конфигурацией трафика. Формирователь может задерживать как отдельные пакеты, так и все пакеты трафика сразу. Он имеет буфер ограниченного размера, поэтому некоторые пакеты могут быть отброшены при отсутствии достаточного для хранения отсроченных пакетов буферного пространства. Отбрасыватель может изымать из обращения как некоторые, так и все пакеты. Он может быть реализован в виде формирователя, у которого размер буфера равен нулю. Формирователь трафика главным образом используется на граничных устройствах домена DS, но может также быть реализован на внутреннем устройстве.
Формирователь трафика в граничном устройстве должен проверить правильность выбора для транзитных пакетов режима PHB в одной из групп режимов PHB, поддерживаемых в пределах этого домена. Это действие необходимо, так как различные домены DS могут поддерживать различные группы режимов PHB. Иными словами, одна и та же кодовая комбинация в байте DS может в различных доменах интерпретироваться по-разному.
Например: в первом транзитном для пакета домене DS все маршрутизаторы имеют две очереди с различными приоритетами (от нулевого до третьего). Пакеты со значением режима PHB, равным трем, передаются с самым высоким приоритетом. Но в следующем транзитном для пакета домене DS все маршрутизаторы имеют восемь различных очередей, и уже все пакеты со значением режима PHB, равным семи, направляются с самым высоким приоритетом. Теперь пакет с наивысшим приоритетом в первом домене будет иметь только средний приоритет во втором домене. Такое изменение приоритетов может привести к нарушению контракта SLA между клиентом и провайдером услуг. Поэтому при передаче из первого домена во второй формирователь трафика на граничном маршрутизаторе между двумя доменами DS должен изменить значение режима PHB с трех на семь.
Если при передаче пакет данных проходит через множество доменов, то байт DS может быть изменен на каждом граничном устройстве таким образом, чтобы пакет получал обслуживание в соответствии с заключенным SLA. SLA содержит подробное соглашение по трафику (Traffic Conditioning Agreement, TCA), где определены правила работы классификатора пакетов и временные характеристики потока трафика. TCA содержит подробную информацию о том, как должны производиться измерение, маркировка, отбраковка и пропуск пакетов в формирователе трафика для выполнения условий SLA. Информация TCA должна быть доступна для всех граничных устройств сети DS, чтобы при прохождении различных доменов DS пакеты получали одинаковое обслуживание.
ВНУТРЕННИЕ УСТРОЙСТВА ДОМЕНА DS
Внутренние устройства домена DS выбирают форму обслуживания для пакетов, основываясь на содержании байта DS. Под внутренним устройством понимается маршрутизатор с поддержкой алгоритма назначения приоритетов трафика. Обычно значение байта DS остается неизменным при нахождении пакета внутри домена DS, а все внутренние маршрутизаторы поддерживают единую политику обработки трафика в целях соблюдения соглашения относительно параметров QoS. Пакеты данных с различными значениями режима PHB в байте DS получают различное обслуживание. Все внутренние маршрутизаторы в домене используют одни и те же правила обработки, поэтому циркулирующий между внутренними устройствами трафик обрабатывается только классификатором пакета. Он выбирает пакеты, основываясь на их значении PHB или других полях заголовка IP, и передает пакеты механизмам управления очередями и планирования.
Классификация трафика и приоритетная маршрутизация используется в каждом внутреннем устройстве домена DS. После пересечения границы домена пакет данных поступает на граничный маршрутизатор следующего домена и должен получить от него своего рода пропуск в этот домен с требуемыми параметрами QoS.
ВЫХОДНЫЕ ДОМЕНЫ
Рабочая группа IETF DS определяет выходной домен DS как домен, где имеется одно или более порождающих трафик устройств, на которых этот трафик получает специфическое обслуживание. Источники трафика и промежуточные устройства в пределах выходного домена могут выполнять классификацию трафика и другие необходимые функции. Выходящий из такого домена трафик может быть классифицирован непосредственно источниками трафика или промежуточными устройствами перед выходом из этого домена.
Можно отметить, что первоначальная маркировка режима PHB для пакетов данных непосредственно отправляющим эти пакеты приложением не производится. Сами приложения ничего не знают о способности сети оказывать дифференцированные услуги. Поэтому приложения не требуется каким-либо образом модернизировать для их использования в сети с предоставлением DS. Это их самое важное преимущество над сетями с предоставлением интегрированных услуг, где большинство приложений требуется подвергнуть некоторым изменениям для реализации поддержки протокола RSVP.
Первоначальная маркировка режима PHB для пакетов приложения производится на этой же рабочей станции или на первом маршрутизаторе вдоль маршрута пакета. Пакеты идентифицируются по их IP-адресу и выходному порту. Например, клиент имеет SLA с провайдером услуг, условиями которого оговаривается более высокий приоритет для пакетов с аудиоинформацией. Звуковое приложение посылает пакеты данных через определенный порт и может быть идентифицировано универсальными классификаторами. Классификаторы этого типа определяют IP-адреса и номер порта пакета и могут отличать пакеты различных приложений. Если рабочая станция содержит формирователь трафика с таким классификатором, то пакету IP будет назначен соответствующий режим PHB. Если рабочая станция не содержит формирователь трафика, то начальная маркировка пакетов будет произведена первым маршрутизатором в данном домене DS.
В нашем примере сеть DS поддерживает политику, в соответствии с которой пакеты звукового приложения имеют более высокий приоритет по сравнению с другими пакетами. Рабочая станция клиента может указать в поле DS отправляемого пакета код DS с таким уровнем приоритета, который в сервисном соглашении не предусматривается. Первый транзитный маршрутизатор может в этом случае повторно классифицировать трафик от клиента и выставить в пакетах правильную кодировку DS. Домен DS является ответственным за обеспечение соответствия этого трафика заключенному SLA. Граничное устройство выходного домена также должно контролировать соблюдение заданных условий и может при необходимости принимать соответствующие меры.
ИСПОЛЬЗОВАНИЕ ПРОТОКОЛА RSVP
Протокол RSVP позволяет приложениям сообщать о требованиях потока к сети, но он имеет некоторые ограничения, препятствующие его широкомасштабному развертыванию в сети Internet:
- в настоящее время только небольшое число устройств поддерживает протокол RSVP. Это количество, как ожидается, будет расти, однако большинство существующих приложений скорее всего не сможет поддерживать этот протокол без существенных доработок;
- многие приложения хотя и требуют предоставления QoS, но не способны точно сформулировать эти требования при использовании модели IS.
Рисунок 2 показывает пример, в котором два клиента распределенной сети с поддержкой протокола RSVP связаны с магистралью DS сети Internet. Граничные маршрутизаторы R2 и R3 осуществляют взаимодействие между сетями с предоставлением интегрированных и дифференцированных услуг. Поддержка ими RSVP не требуется. Они выполняют функции входного контроля домена DS. Набор услуг сети DS должен обеспечивать замену резервирования RSVP соответствующим классом дифференцированного обслуживания.
Маршрутизаторы R1 и R4 — краевые маршрутизаторы со стороны области сети с поддержкой RSVP/IS. Эти маршрутизаторы как бы разделены на две половины. Одна половина поддерживает протокол RSVP и связана с пользовательской сетью, а другая поддерживает сети с предоставлением DS и связана с сетью Internet. Маршрутизатор должен быть способен обрабатывать сообщения PATH и RESV, но хранения полного состояния RSVP или универсальной классификации пакета от него не требуется. Вторая половина маршрутизатора обеспечивает интерфейс с функцией управления доступом для сети с предоставлением DS. Если сервисное соглашение между пользовательской сетью и Internet является статичным, то функция управления доступом может быть реализована в виде простой таблицы, с указанием параметров QoS для каждого сервисного уровня. Если сервисное соглашение имеет динамическую форму, то функция управления доступом связывается с аналогичными функциями в пределах данной сети с предоставлением DS для принятия решения о доступе на основании имеющейся пропускной способности сети.
В рассмотренном примере обмен сообщениями протокола RSVP используется для обеспечения контроля за доступом к специфическим сервисным уровням сети с предоставлением DS из сети с предоставлением IS. Сообщения протокола RSVP содержат параметры QoS для области сети с IS. На границе между сетью с IS и сетью с DS краевые маршрутизаторы преобразуют параметры QoS для сетей IS в соответствующие уровни обслуживания сетей с DS. Затем краевой маршрутизатор осуществляет контроль за доступом в сеть DS, принимая или отклоняя запрос в зависимости от возможности обеспечения требуемого уровня обслуживания в сетях с DS. При достижении сообщением резервирования протокола RSVP краевого маршрутизатора описатель потока RSVP будет преобразован в PHB для получения соответствующего уровня обслуживания в сети с DS. Краевой маршрутизатор добавляет в конец сообщения о резервировании протокола RSVP значение режима PHB и отправляет его пославшей запрос рабочей станции. Получив ответ, рабочая станция указывает во всех отправляемых пакетах это значение режима PHB. Такой подход позволяет обеспечить качество обслуживания из конца в конец в сети, где одни области поддерживают интегрированное, а другие — дифференцированное обслуживание.
С Максимом Кульгиным можно связаться по адресу: mk@mail.admiral.ru.Ресурсы Internet
Более подробную информацию по вопросам обеспечения качества обслуживания можно найти в следующих источниках:
- RFC 1349 Type of Service in the Internet Protocol Suite;
- RFC 1633 Integrated Services in the Internet Architecture: an Overview;
- RFC 2205 Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification;
- RFC 2206 RSVP Management Information Base using SMIv2;
- RFC 2207 RSVP Extensions for IPSEC Data Flows;
- RFC 2208 Resource ReSerVation Protocol (RSVP) — Version 1 Applicability Statement;
- RFC 2209 Resource ReSerVation Protocol (RSVP) — Version 1 Message Processing Rules;
- RFC 2210 The Use of RSVP with IETF Integrated Services;
- http://www.ietf.org/internet-drafts/draft-ietf-diffserv-arch-01.txt;
- http://www.ietf.org/internet-drafts/draft-nichols-dsopdef-00.txt;
- http://www.ietf.org/internet-drafts/draft-ietf-diffserv-header-02.txt;
- http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework-00.txt;
- http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rsvp-00.txt;
- http://www.ietf.org/internet-drafts/draft-ietf-diffserv-phb-ef-00.txt.