Архитектура «Дифференцированные Услуги» (Differentiated Services, далее - DiffServ) [RFC2475 является логическим продолжением работ 1ETF над архитектурой IntServ. Целью создания обеих архитектур является обеспечение качества обслуживания в сети Интернет, а причиной перехода от архитектуры IntServ к DiffServ, в первую очередь, является низкая масштабируемость первой. Высокие масштабируемость и гибкость архитектуры DifTServ достигаются за счет объединения всех типов трафика в несколько классов на входе в домен DiffServ - в пограничных входящих узлах (ingress Nodes).

В свою очередь, внутренние сетевые узлы (Interior Nodes) за счет ограниченного числа классов трафика и, соответственно, методов их обработки, избегают того лавинообразного роста служебной информации, как это происходит при использовании архитектуры IntServ, что, в свою очередь, не приводит к снижению производительности. Таким образом, функции маркировки и формирования профиля трафика осуществляются пограничными входящими узлами, в то время как внутренние узлы осуществляют лишь перенаправление пакетов по выбранной методике (Per-Нор Behavior, см. ниже), базируясь на классификации каждого пакета, которая осуществляется на основании информации третьего уровня моделей OSI и TCP/IP по значению поля «тип услуги» ToS (Type of Service) заголовка.

Заметим, что в терминах архитектуры DiffServ поле ToS носит имя DS [RFC2474. Два последних бита ноля DS (рис. 4.11) определены как неиспользуемые (Currently Unused, далее - CU), в связи с тем, что прежде (до внедрения архитектуры DiffServ) поле DS использовалось как поле ToS, которое определяло каким образом обрабатывать пакет. Емкость поля DS позволяет определить до 64 различных значений. Для более полной информации автор рекомендует обратиться к первоисточнику [RFC2474],

Рис. 4.11. Структура поля DS

Таким образом, просто определением значения байта DS для некоторого пакета можно задавать желаемое качество обслуживания. Отметим, что в архитектуре DiffServ, как предстаатено на рис. 4.13, определено три типа сетевых узлов. Два из них уже определены выше, а третьим является тип пограничных исходящих узлов (англоязычный термин - Egress Nodes), основными функциями которых является взаимодействие с пограничными входящими узлами соседних доменов DiffServ, как правило, через так называемый контракт о параметрах услуги SLA (Service layer Agreement). Заметим, что разделение пограничных узлов на входящие и исходящие является логическим, физически эти типы сетевых узлов ре&чизуются в рамках единого маршрутизатора с функциями DiffServ. Достаточно часто в литературе узел, выполняющий роль входящего/исходящего пограничного узла, называется просто пограничным (англоязычный термин - Boundary Node).

Одним из самых важных достоинств DiffServ можно считать тот факт, что при внедрении этой архитектуры на сети учитывается сегментный принцип построения Интернет. Для определения параметров трафика, передаваемого между потребителем услуг (пользователем) и провайдером услуг (1SP) или двумя ISP, должен быть заключен контракт о параметрах услуги SLA [RFC2475], который достаточно подробно был рассмотрен в главе 2. Напомним, что контракт SLA определяет какие услуги и с каким качеством будут предоставляться данным 1SP пользователю. Заметим, что в процессе работы над спе~

цификациями DiffServ была выработана иерархическая модель SLA. Было принято решение, что «соглашение» (agreement) не может определять значения параметров, т.е. SLA был отведен наивысший уровень абстракции в специфицировании услуги, параметризация трафика была выделена в самостоятельное подмножество SLS (Service Level Specification), а ТСА (Traffic Conditioning Agreement) было вовсе переименовано в TCS (Traffic Conditioning Specification). На рис. 4.12 представлена иерархия SLA, в которую входят (в порядке уменьшения степени абстракции) SLS, PDB (Per-Domain Behavior, см. п. 4.5.2), РНВ (р_еr-Hop Behavior, см. п. 4.5.1) и планировщик.

Рис. 4.12. Иерархия SLA

SLS может быть как статическим (постоянным), так и динамическим. При статическом SLS пользователь имеет возможность передавать данные (с соответствующими параметрами) в любое время. При динамическом SLS пользователь должен использовать какой-либо сигнализационный протокол для запроса необходимых ресурсов сети и обработки запросов SLS. Отметим, что поддержка динамического SLS существенно повышает сложность функционирования архитектуры и может, как в случае IntServ, привести к снижению производительности. Сетевые брокеры (Bandwidth Brokers, далее - ВВ), представляющие собой набор функций, реализованных как аппаратно, так и программно, обрабатывают динамические запросы от пользователей на предоставление ресурсов, продекларированных в SLS, и принимают решение на основе данных о текущей загрузке сети. Поле DS передаваемых пакетов устанавливается (маркируется) в соответствии с запрошенным пользователем типом услуги. Входящие узлы на сети рассматриваемого 1SP (предполагается, что сеть 1SP представляет собой домен DiffServ) конфигурируются в соответствии с выполняемыми ими функциями классификации, управления трафиком и маркировки пакетов.

Исходящие узлы, соответственно, конфигурируются с целью выполнения основной функции - формирования необходимого профиля трафика. Конфигурации могут производиться как в ручном режиме, так и автоматически (динамически) с использованием, например, протокола RSVP. Отметим важную деталь, что при переходе пакета из одного домена в другой, значение поля DS может быть изменено в соответствии с информацией, представленной в SLS. Основные блоки, определенные [ETF, из которых возможно выстраивать услуги DiffServ, будут рассмотрены ниже.

Для корректного обслуживания трафика внутри домена DiffServ необходимым условием является соответствие поступающего трафика заявленным параметрам, для чего на входящем пограничном узле реализуется набор функций, известных под общим названием «функции контроля соответствия нагрузки заданным параметрам» (Traffic Conditioning, далее - ТС). Напомним, что ТС включает функции мониторинга, маркировки, сглаживания и сброса. Каждая из функций будет подробно рассмотрена ниже в разделе 4.5.4.

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

⇐Качество обслуживания для услуги cls | Управление трафиком и качество обслужевания в сети | Концепция пошаговой маршрутизации рнв⇒