Соблюдение профиля трафика в соответствии с ТСА строится на основе функций мониторинга и маркировки/сброса пакетов в архитектуре DiffServ, которые, в свою очередь, реализуются при помощи алгоритма Token Bucket. Учитывая специфику DiffServ, заключающуюся в определении множества классов качества обслуживания, очевидно, что поступающая нагрузка должна быть обработана не одним Token Bucket, каждый из которых должен быть параметризирован в соответствии с классом качества обслуживания им обрабатываемым. Например, для каждого класса услуги AF (пошаговая маршрутизация «гарантированное перенаправление» - Assured Forwarding Per-Нор Behavior, см. п. 4.5.1.2, глава 4) должно быть определено три Token Bucket для обработки трех уровней приоритета.

Для работы с нагрузкой услуги AF в [RFC2698] был предложен новый алгоритм «двухскоростной трехуровневый маркировщик» (two-rare three-color marker, далее - trTCM), являющийся модификацией Token Bucket, точнее - двойного Token Bucket (Dual Token Bucket). Алгоритм trTCM измеряет нагрузку и маркирует пакеты тремя цветами: зеленый (green), желтый (yellow) и красный (red), и определяется четырьмя контролируемыми параметрами: «пиковая скорость» (Peak Information Rate, далее - PIR) и соотвествующий ей «пиковый размер пачки» (Peak Burst Size, далее - PBS), а также «выполнимая скорость» (Committed Information Rate, далее - CIR) и соответствующий ей «выполнимый размер пачки» (Committed Burst Size, далее - CBS).

Отметим, что под «выполнимой скоростью» CIR подразумевается скорость, поддерживаемая сетью при нормальном функционировании. В общем случае предполагается, что значения параметров CIR и CBS, как минимум, не превышают (равны) значения параметров PIR и PBS, соответственно. Поступающий в trTCM пакет маркируется красным цветом, если скорость потока в момент, когда он поступает, превышает значение параметра «пиковой скорости» PIR, иначе пакет маркируется как желтый или зеленый в зависимости от того, превышает ли скорость потока в момент, когда он поступает, значение параметра CIR.

В [RFC2697] был предложен алгоритм «односкоростной трехуровневый маркировщик» (single-race three-color marker,далее - srTCM), являющийся частным случаем trTCM и используемый для контроля трех параметров потока - CIR, CBS и «избыточного размера пачки» (Excess Burst Size, далее - EBS). Ниже srTCM не рассматривается, а заинтересованный читатель в первоисточнике [RFC2697} сможет почерпнуть более глубокие знания.

Процедура измерения нагрузки в trTCM может функционировать в двух режимах: «слепом» (color blind), когда предполагается что пакеты немаркированы и «цветном» (color-aware). В последнем режиме предполагается, что пакеты могли быть уже ранее «предварительно маркированы некоторым цветом» (precolored, далее - премаркированы), например, в пользовательском оборудовании или в предыдущем транзитном узле. Цвет премаркирован-ного пакета может быть изменен только в «худшую» сторону, т.е. премаркированный желтым цветом пакет не может быть маркирован как зеленый, а только как красный.

Ниже рассмотрим подробнее принцип функционирования алгоритма trTCM. Определим, как показано на рис. 2.20, два последовательных Token Bucket и назовем их Р и С, по первым буквам типа параметров контролируемых каждым из Token Bucket - Peak и Committed, соответственно. Таким образом, в первом из Token Bucket контролируются параметры «пиковая скорость» PIR и «пиковый размер пачки» PBS, а во втором - параметры «усредненная скорость» CIR и соответствующий ей «усредненный размер пачки» CBS. Каждый поступающий пакет должен пройти через оба Token Bucket, поэтому

окончательный цвет на выходе trTCM будет результатом функционирования обеих составляющих:

• зеленым цвет пакета будет в случае, если он конформен обоим Token Bucket, Р и С;

• желтым цвет пакета будет в случае, если он конформен для Р, но не конформен для С;

• красным цвет пакета будет в случае, если он не конформен обоим Token Bucket, Р и С.

Алгоритм trTCM состоит из двух функций: подсчет параметров Token Bucket и маркировка. На рис. 2.21 представлен мегакол первой из функций, результатом которой являются значения количества жетонов для обоих Token Bucket, и которая выполняется каждый раз при поступлении пакета. Функция маркировки, метакодьг которой представлены на рис. 2.22 и 2.23 для «слепого» и «цветного» случаев, соответственно, выполняется после подсчета жетонов для Р и С.

Переменные алгоритма:

Рис. 2.21. Метакод функции подсчета количества жетонов

Рис. 2.23. Метакод функции маркировки в «цветном» режиме В представленном алгоритме предполагается, что не премаркиро-ванные пакеты и пакеты, имеющие какой-либо отличный от определенных цвет, обрабатываются также как пакеты, премаркированные как зеленые. Можно заметить, что при определенном раскладе премаркированные зеленые пакеты в Token Bucket Р могут быть маркированы как красные, даже в случае наличия достаточного количества жетонов в Token Bucket Р. Отметим, что пакет, премаркированный как желтый, может быть маркирован только как желтый или красный, но не как зеленый.

Учитывая этот факт, рассмотрим пример. Пусть в некоторый момент времени в Р и С находятся 10 и 8 жетонов, соответственно, причем для простоты положим, что пакеты имеют фиксированную длину и обслуживаются, забирая всего один жетон из очереди. Далее пусть в trTCM поступает пачка из 10 пакетов премаркированных желтым цветом. Все доступные 10 жетонов из Р будут потрачены на обслуживание этих пакетов, а из С на обслуживание этих пакетов не будет потрачено ни одного жетона (см. алгоритм на рис. 2.24), т.к. пакеты желтые, для Р являются конформными и не могут быть маркированы как зеленые.

Желтые пакеты израсходовали все жетоны из Р, а из С - ни одного. Предположим, что через некоторый промежуток времени, за который в Р и С количество жетонов увеличилось на 2 и 1, соответственно, в trTCM поступает 10 пакетов, премаркированных как зеленые. Первые два поступивших зеленых пакета конформны для обоих Token Bucket, поэтому из системы выйдут как зеленые. К этому моменту в Р не останется жетонов, а С будет содержать еще 8 жетонов. Таким образом, в сложившейся ситуации оставшиеся 8 зеленых пакетов в Р будут маркированы как красные. Принимая во внимание факт, что целью алгоритма trTCM является защита именно зеленых пакетов, очевидно, что при наличии жетонов в С маркировка этих пакетов красным в Р является нелогичной и ухудшает качество функционирования алгоритма.

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

Рис. 2.24. Метакод части функции маркировки в «цветном» режиме

⇐Алгоритм token bucket | Управление трафиком и качество обслужевания в сети | Сглаживание профиля трафика⇒