В архитектуре DiffServ используется статический подход декларирования параметров нагрузки. Соглашение, определяющее параметры трафика, называется ТСА (Traffic Cor.ditioning Agreement). На основе данных из ТСА каждому потоку присваивается класс обслуживания. ТСА фактически является подмножеством SLA и содержит правила, которые можно сформулировать следующим образом: что должен делать оконечный пользователь, чтобы получить услугу с желаемым качеством и что, в свою очередь, должен делать провайдер для осуществления контроля за параметрами предоставляемой услуги. ТСА определяет следующие составляющие:

• правила классификации трафика и соответствующие профили (совокупности параметров) для различных классов;

• правила измерения нагрузки;

• правила маркировки пакетов;

• правила принудительного сброса пакетов;

• правила сглаживания нагрузки;

• правила определения параметров нагрузки, специфицированных явным образом в SLA и, возможно, неявным образом определен' ных «политикой управления» услугами в конкретном домене DiffServ;

• параметры для различных профилей трафика;

• параметры оценки функционирования (задержка, пропускная способность, приоритезация, и т.п.);

• так называемые инструкции по обработке трафика, поступающего «вне профиля» (out-profile);

• дополнительные услуги по обработке трафика, реализованные в данном домене.

Набор параметров «профиль трафика» (traffic profile) определяет временные значения параметров некоторого потока, выбранного классификатором, который проводит классификацию пакетов с целью определения принадлежности потокам или классам обслуживания, в результате чего становится возможным мониторинг нагрузки каждого потока и определения соответствия текущих значений параметров заявленным.

В результате должен быть решен вопрос соответствует ли поступивший пакет заявленному в ТСА профилю (in-profile) или нет (out-profile), другими словами, соответствует ли текущая нагрузка заявленной или нет. Например, подобная процедура может быть реализована при помощи механизма Token Bucket, при этом правило классификации будет выглядеть следующим образом:

if DS_codepoint = X then

use Token_3ucket(г,b)

т.е. все пакеты, имеющие значение поля DS, равное X, будут помещены в Token Bucket с параметрами (г, Ь), где г - средняя скорость потока, а b - длина пачки нагрузки, генерируемой источником. В данном примере некоторый пакет определяется как «вне профиля» в том случае, если при поступлении в буфер в Token Bucket для него отсутствует жетон (см. механизм функционирования Token Bucket).

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

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

⇐В архитектуре diffserv контракт по трафику sla | Управление трафиком и качество обслужевания в сети | Классификация нагрузки⇒