Дифференцированное обслуживание

Дифференцированное обслуживание (DiffServ) опирается на ту же обобщенную модель QoS, что и интегрированное обслуживание, однако в качестве объектов обслуживания рассматриваются не отдельные потоки, а классы трафика.

Вапомним, что классом трафика называется совокупность пос^^идих на o^pabofky щ», кетш, обладающих общими признаками,, например,эре пакфш грЬ^нэых' приложений или .всепакеты с UW а определенных предела^.* _v' г - „' С " - ^w ;' " ;

В отличие от потока класс трафика не различает пакеты в зависимости от их маршрута, и рис. 20.4 иллюстрирует это отличие. Так, маршрутизатор R1 отно­сит все потоки, требующие приоритетного обслуживания и втекающие в его ин­терфейс il, к одному классу, независимо от их дальнейшего маршрута. Маршру­тизатор R2 оперирует уже с другим составом приоритетного класса, так как в него вошли не все потоки интерфейса il маршрутизатора R1.

Обычно в сети DiffServ поддерживается дифференцированное обслуживание небольшого количество классов трафика, например двух (чувствительного к за­держкам и эластичного) или трех (к первым двум прибавляется класс, требую­щий гарантированной доставки пактов с определенным минимумом скорости трафика). Небольшое количество классов определяет масштабируемость этой модели, так как маршрутизаторы не должны запоминать состояния каждого по­тока пользователя. Высокая степень масштабирумости DiffServ обеспечивается также тем, что каждый маршрутизатор самостоятельно принимает решение о том, как он должен обслуживать тот или иной класс трафика, не согласовывая свои действия с другими маршрутизаторами. Такой подход назван независимым пове­дением маршрутизаторов (Per Hop Behavior, РНВ). Так как в модели DiffServ маршруты пакетов не отслеживаются, то здесь не используется сигнальный про­токол резервирования ресурсов, подобный RSVP модели IntServ. Вместо этого маршрутизаторы сети выполняют статическое резервирование ресурсов для ка­ждого из поддерживаемых сетью классов.

Рис. 20.4. В модели DiffServ объектами обслуживания являются классы трафика, а не потоки

 

В качестве признака принадлежности IP-пакета к определенному классу в DiffServ используется метка, переносимая полем приоритета IP-пакета (ToS-байт), кото­рое с появлением стандартов DiffServ было переопределено и названо DS-бай- том. Как показано на рис. 20.5, DS-байт переопределяет значения битов ToS-бай- та, как это было определено ранее в соответствующих спецификациях (RFC 791, RFC 1122, RFC 1349).

В настоящее время используются только старшие 6 бит DS-байта, причем толь­ко старшие 3 из них требуются для определения класса трафика (что дает не бо­лее 8 различных классов). Младший бит (из используемых шести) DS-байта обычно переносит признак IN — индикатор того, что пакет «вышел» из профиля трафика (аналогично признакам DE и технологии Frame Relay и CPL в техноло­гии ATM). Промежуточные два бита обычно описывают различные варианты обслуживания пакетов внутри одного класса трафика.

Рис. 20.5. Соответствие битов DS-байта битам поля типа сервиса

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

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

Модель DiffServ подразумевает существование соглашения об уровне обслужи­вания (SLA) между доменами с общей границей. Соглашение SLA определяет критерии политики предоставления сервиса, профиль трафика, а также гаранти­руемые параметры QoS. Ожидается, что трафик будет формироваться и сглажи­ваться в выходных точках домена в соответствии с SLA, а во входной точке до­мена будет кондиционироваться в соответствии с правилами политики. Любой трафик «вне профиля» (например, выходящий за верхние границы полосы про­пускания, указанной в SLA) не получает гарантий обслуживания (или же опла­чивается по повышенной стоимости в соответствии с SLA). Правила политики предоставления сервиса могут включать время дня, адреса источника и прием­ника, транспортный протокол, номера портов. В том случае, когда соблюдаются правила политики и трафик удовлетворяет оговоренному профилю, домен DiffServ должен обеспечить при обслуживании этого трафика параметры QoS, зафикси­рованные в SLA.

На сегодняшний день IETF разработаны два стандарта пошагового продвижения па­кетов для схемы РНВ, которые представляют два разных варианта обслуживания.

Пока не используется

Код класса дифференцированного обслуживания RFC 2474

Приоритет; oeJJ^		щ
-->■' *
т * Y RFC 1122 RFC 1349	.. T' Этот бит должен быть нулевым

Биты: 0 1 2 3 4 5 6 7

Байт типа сервиса протокола IPv4

Поле типа сервиса (TOS) RFC 791

Биты: 0 1 2 3 4 5 6 7 DS-байт

□ Быстрое продвижение (Expedited Forwarding, EF) характеризуется одним зна­чением кода (10111) и представляет собой высший уровень качества обслужи­
вания, обеспечивая минимум задержек и вариаций задержек. Любой трафик, интенсивность которого превышает указанную в профиле, отбрасывается.

□ Гарантированная доставка (Assured Forwarding, AF). Имеется четыре класса трафика и три уровня отбрасывания пакетов в каждом классе — всего 12 раз­личных типов трафика. Каждому классу трафика выделяется определенный минимум пропускной способности и размер буфера для хранения его оче­реди. Трафик, параметры которого превышают указанные в профиле, достав­ляется с меньшей степенью вероятности, чем трафик, удовлетворяющий условиям профиля. Это означает, что качество его обслуживания может быть понижено, но он не обязательно будет отброшен.

На основе этих пошаговых спецификаций и соответствующих соглашениях SLA могут быть построены сервисы для конечных пользователей «из конца в конец» — это EF-сервис и AF-сервис соответственно.

Основное назначение EF-сервиса — предоставление качества обслуживания, со­поставимого с качеством обслуживания выделенных каналов, поэтому этот сер­вис называется также сервисом виртуальных выделенных каналов.

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

Четыре класса AF-сервиса ориентированы на гарантированную доставку, но без минимизации уровня задержек пакетов, как это оговорено для EF-сервиса. Га­рантированная доставка выполняется в том случае, когда входная скорость тра­фика не превышает отведенной данному классу минимальной пропускной спо­собности. Реализация классов AF-трафика хорошо сочетается с EF-сервисом — EF-трафик может обслуживаться по приоритетной схеме, но с ограничением ин­тенсивности входного потока. Оставшаяся пропускная способность распределя­ется между классами AF-трафика в соответствии с алгоритмом взвешенного об­служивания, который обеспечивает необходимую пропускную способность, но не минимизацию задержек. Реализация AF-сервиса предполагает (но не требует) взвешенного обслуживания для каждого класса с резервированной полосой про­пускания, а также применения обратной связи (в форме RED).

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

Обслуживание классов трафика подразумевает, что пограничные маршрутизато­ры выполняют профилирование трафика без учета адреса назначения пакетов. Обычно для входных интерфейсов пограничных маршрутизаторов задается не­который порог допустимой нагрузки для трафика каждого класса. Например, пусть наша сеть поддерживает трафик двух классов, реализуя особое обслужи­вание и обслуживание с максимальными усилиями, причем порог для трафика с особым обслуживанием установлен в 20 % пропускной способности для каж­дого входного интерфейса каждого пограничного маршрутизатора. Кроме того,

Рис. 20.6* Неопределенность уровня обслуживания в модели DiffServ

 

Несмотря на такое достаточно жесткое ограничение, интерфейсы маршрутизато­ров сети оказываются под воздействием разной нагрузки. На рис. 20.6 для упро­щения ситуации показаны только потоки, требующие особого обслуживания. Так, выходной интерфейс ill маршрутизатора R1 обслуживает два таких потока и на­гружен на 40 %, в то время как выходной интерфейс i21 маршрутизатора R2 — только один из них, так как второй поток уходит через другой выходной интер­фейс. Выходной же интерфейс i31 маршрутизатора R3 перегружен, обслуживая три таких потока, так что его коэффициент использования равен 60 %. Учитывая факторы, влияющие на образование очередей (см. главу 7), мы знаем, что коэф­фициент использования является наиболее существенным фактором и значения в районе 50 % являются критическими. Поэтому в интерфейсе i31 возникают длинные очереди пакетов класса особого обслуживания, которые снижают каче­ство такого обслуживания, так как приводят к длительным задержкам и их ва­риациям, а также потерям пакетов. Кроме того, страдает трафик класса обслужи­вания с максимальными усилиями, проходящий через этот интерфейс, так как ему достается только 40 % пропускной способности интерфейса.

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

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

Однако все эти меры не дают гарантии, что все интерфейсы всех маршрутизато­ров сети будут работать в нужном диапазоне значений коэффициента исполь­зования, а следовательно, обеспечивать заданное качество обслуживания. Для того чтобы дать такие гарантии, необходимо «улучшить» модель DiffServ и при­менять методы инжиниринга трафика, то есть контролировать не классы, а пото­ки трафика, в данном случае агрегированные. Под агрегированным понимается поток, состоящий из пакетов одного класса, имеющих общую часть пути через сеть. Эта общая часть не обязательно включает полный путь, от входного интер­фейса одного из пограничных маршрутизаторов до выходного интерфейса дру­гого пограничного маршрутизатора. Достаточно, чтобы пакеты проходили хотя бы два общих интерфейса, чтобы считать их агрегированным потоком, как, на­пример, в случае потока, проходящего через интерфейсы ill и i22 (см. рис. 20.6).

Затем, зная путь прохождения каждого агрегированного потока через сеть, мож­но проверить, имеются ли достаточные ресурсы вдоль пути для каждого потока, например, не превышают ли коэффициенты использования интерфейсов задан­ного порога. Для этого нужно провести профилирование с учетом адреса назна­чения пакетов. Однако реализация такого подхода в IP-сетях сталкивается с несколькими трудностями. Во-первых, в технологии DiffServ не предусмотрен сигнальный протокол, такой как, например, RSVP в технологии IntServ. Это оз­начает, что все проверки наличия ресурсов у маршрутизаторов для каждого агре­гированного потока нужно выполнять в автономном режиме, вручную или с помощью какого-то специального программного обеспечения. Во-вторых, для проведения таких расчетов нужно знать пути потоков через сеть. Такие пути оп­ределяются таблицами маршрутизации, которые строятся протоколом маршру­тизации, например RIP или OSPF (либо их комбинацией, если в сети использу­ются несколько протоколов маршрутизации IGP-класса), или вручную. Поэтому для ручного или автоматизированного расчетов нужно знать таблицы маршру­тизации всех маршрутизаторов сети и следить за их изменениями, а это непро­сто, учитывая, что отказы линий связи или маршрутизаторов приводят к пере­стройке таблиц. Нужно также учитывать, что маршрутизаторы могут применять методы балансировки нагрузки, разделяя агрегированный поток на несколько подпотоков, что также усложняет расчеты.

«Улучшенная» версия DiffServ, обеспечивающая учет адресов назначения, повы­шает качество услуг оператора связи, но вместе с тем усложняет саму идею мето­да, в основе которого лежит идея независимого обслуживания классов трафика каждым маршрутизатором сети.