Итак, обе архитектуры, и IntServ, и DiffServ, изначально создавались с целью обеспечения качества обслуживания на основе существующей структуры и топологии сети Интернет. IntServ обладает целым рядом достоинств, которые были приведены выше, однако сложность реализации и низкая масштабируемость являются достаточно серьезными недостатками. В свою очередь, DiffServ обладает свойствами, которые позволяют преодолеть недостатки IntServ, однако статичность архитектуры, т.е. необходимость предварительного определения SLA/ SLS, является отрицательной стороной архитектуры DiffServ.

В [RFC2998] предложено изящное решение, позволяющее обеспечивать качество обслуживания «из-конца-в-конец» на основе совместного функционирования обеих архитектур, базируясь на их преимуществах. Архитектура DiffServ, очевидно, должна эффективно функционировать в рамках высокоскоростных транзитных сетей, т.к. сетевые узлы обеспечивают быструю маршрутизацию по причине достаточно простых выполняемых ими функций. Отсутствие полноценной реализации динамической функции САС (в DiffServ она фактически заменена на SLS) может привести к неприятным последствиям в случае, если в агрегированный поток поступит еще один поток, в то время как ресурсы для данного агрегированного потока уже исчерпаны.

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

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

Таким образом, архитектуру сети Интернет, обеспечивающую качество обслуживания с использованием IntServ/RSVP и DiffServ, можно представить следующим образом: сегменты IntServ находятся на сети доступа, а сегменты DiffServ - на магистральной сети. Если IntServ/ RSVP используется как САС для сегмента DiffServ, то в данном случае необходимо обратить внимание на «пограничный узел» (access router, далее - AR), находящийся между сегментами IntServ и DiffServ. Со стороны IntServ, узел должен поддерживать протокол RSVP, и, соответственно, обрабатывать сообщения PATH и RESV.

На базе информации об используемой и доступной полосе пропускания, а также информации, полученной из сообщения RESV, функция САС, реализованная в рассматриваемом узле, принимает решение о возможности установления нового соединения. В случае поддержки нового соединения, ему назначается соответствующий тип РНВ и в заголовках всех принадлежащих ему пакетов устанавливается соответствующее значение поля DS.

Таким образом, на границе между архитектурами и DiffServ запросы из сегмента IntServ должны быть корректно переданы к сегменту DiffServ для следующих целей:

• установки правильного типа «пошаговой маршрутизации» РНВ для запрошенной услуги;

• корректного выполнения функций «управления политикой» на пограничном узле DiffServ;

• передачи параметров соединения или потока от IntServ к DiffServ.

Рис. 4.19. Комбинация IntServ/RSVP и DiffServ

Рассмотрим функционирование схемы, представленной на рис. 4.19. Как было показано ранее, процесс начинается с посылки источником сообщения PATH, которое передается по направлению к приемнику, в сегменте IntServ оно обрабатывается стандартно. При получении PATH пограничным узлом на нем инсталлируется соответствующее состояние и это сообщение маршрутизируется в сегмент DiffServ, в котором его содержимое игнорируется. Далее сообщение PATH просто перенаправляется к приемнику, где обрабатывается в соответствии со стандартными процедурами пограничным узлом.

На получение PATH приемник отвечает сообщением RESV, которое проходит обратно к источнику через сегменты IntServ и DiffServ. Рассмотренный выше запрос на предоставление ресурсов может быть, естественно, не поддержан любым узлом IntServ, вследствие функпионирования САС, инициируемой поступлением сообщения RESV на пограничный узел. Также на пограничном узле проводится сравнение ресурсов, запрашиваемых в RESV, и уровня качества обслуживания, предлагаемого сегментом DiffServ.

В случае если ресурсов достаточно и параметры трафика соответствуют SLS, то соединение поддерживается, а сообщение RESV направляется далее в сторону источника, иначе выполняются соответствующие процедуры, рассмотренные при описании протокола RSVP. Однако, рассмотренный пример обладает одним существенным недостатком, заключающимся в том, что сообщения PATH и RESV передаются через сегмент DiffServ прозрачно и базой для определения существования ресурсов в сегменте DiffServ является статический SLA/SLS, установленный между двумя сегментами. В этом случае, учитывая, что функция САС пограничного узла, реализованная со стороны IntServ, не располагает данными о доступных ресурсах внутри сегмента DiffServ, будет достаточно сложно использовать ресурсы сегмента DiffServ оптимальным образом.

Для решения этой проблемы уже предложены несколько методов, среди которых необходимо отметить мониторинг сообщений протокола RSVP в сегменте DiffServ [RFC3175J, который позволяет динамически оптимизировать использование ресурсов в сегменте DiffServ посредством реализации самоконфигурирования узлов. Другое достаточно распространенное решение базируется на применении «сервера управления политикой».

⇐Общие принципы обеспечения qos в diffserv | Управление трафиком и качество обслужевания в сети | Многопротокольная маршрутизация по метке mpls⇒