Механизмы профилирования и формирования трафика.

Существует несколько популярных алгоритмов, которые рекомендуется применять для профилирования и формирования трафика, с целью обеспече- ния требуемого QoS.

Алгоритм «дырявого ведра» (Leaky bucket) разработан для профили- рования пульсирующего трафика. Он позволяет проверить соблюдение трафи- ком оговоренных (в соглашении об уровне услуг) значений средней скорости и пульсаций.

У алгоритма имеются следующие настраиваемые значения:

• период усреднения скорости Т;

• средняя скорость, которую трафик не должен превышать на периоде Т

(скорость, согласованная с провайдером);

 

• объем пульсации Вс, соответствующий средней скорости и периоду Т;

• допустимое превышение объема пульсации Ве. Предполагается, что трафик контролируется каждые Т секунд.

Трафик должен иметь среднюю скорость не выше оговоренной скорости средней скорости.

Превышение объемом пульсации оговоренного значения Вс на величину Ве считается мягким нарушением. Пакеты-нарушители помечаются специаль- ным признаком, но не удаляются.

При превышении объемом пульсации величины Вс + Ве пакеты отбрасы- ваются. Но фактически предпринимаемые при этом действия являются настра- иваемым параметром.

Алгоритм использует счетчик поступивших от пользователя байтов. Каждые Т секунд счетчик уменьшается на величину Вс (или сбрасывается в 0, если его значение меньше Вс). Это иллюстрируется обычно ведром, из которо- го дискретно каждые Т секунд вытекает объем накопленного трафика (рис. 7.6).

 

кеты

 

Вс

Рис. 7.6. Алгоритм «Leaky bucket»

Все кадры, которые находятся в объеме, не превышающем Вс, пропус- каются в сеть со значением признака DE=0 (нормальная доставка). Кадры, находящиеся в промежутке (Вс) ÷ (Вс + Ве), тоже передаются в сеть, но с при- знаком DЕ =1 (возможность удаления на следующих маршрутизаторах сети). Те кадры, которые находятся за пределами объема (Вс + Ве), отбрасываются маршрутизатором.

Такой вариант алгоритма используется в сети Framу Rеlау.

Алгоритм «Ведро меток» (Токеn bucket) используется как для профили- рования, так и для формирования, т.е. сглаживания трафика. Цель алгоритма – уменьшение неравномерности продвижения пакетов, когда из-за значительной пульсации они сбиваются в плотные группы.

Под меткой (Токеn) понимается абстрактный объект, носитель «порции» информации. Генератор меток периодически направляет очередную метку в

«ведро» с ограниченным объемом b байт. Все метки имеют одинаковый объем m байт, а генерация меток происходит с такой скоростью, что ведро заполняет- ся со скоростью r байт в секунду. Скорость r является желательной средней скоростью для формируемого трафика (рис. 7.7).

 

r бит/с

Токен             скорость наполнения ведра

 

b бит объем ведра

 

 

Входной поток                       Выходной поток

Рис. 7.7. Алгоритм Токеn bucket

Пакеты поступают в систему и попадают в очередь объемом K байт. Из очереди пакет продвигается сервером только в том случае, когда к этому мо- менту «ведро» наполнено до уровня М байт, где М – объем пакета. Пакет в этом случае продвигается вперед, а из «ведра» удаляется объем в М байт. Таким об- разом, достигается улучшение трафика. Даже если приходит большое число пакетов, из очереди они выходят равномерно и в темпе, задаваемом генерато- ром меток. То есть поток меток – это идеальный трафик, к форме которого ста- раются привести входной трафик.

Расчет длительности выходной пачки:

S – длительность пачки/с;

C – емкость маркерного ведра/байт;

ρ – скорость появления маркеров, байт/с;

M – максимальная выходная скорость, байт/с.

Максимальное количество переданных байтов в пачке будет равно (С+ ρ S).

М S – количество байтов, переданных в пачке с максимальной скоростью.

С+ ρ S= М S, отсюда

S = С/ (М – ρ)

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

Политики QoS. Службы QoS, в которых используют централизованные службы поддержки политики, называются службами, основанными на политике (Policy based QoS).

Правила политики применяются не только для управления QoS, но и для координации выполнения сетевыми устройствами других функций, например, функций защиты трафика. Централизованная служба политики сети обычно базируется на общей справочной службе сети (Directory Service), хранящей все учетные данные о пользователях (имя, пароль,...). В последнее время ее функ- ции расширены – добавлено хранение самых разных данных о сети, в том чис- ле и данных о политике QoS, политике безопасности и т. д.

 

Протокол RSVP. Чтобы сеть могла предоставлять гарантии качества об- служивания, нужен специальный механизм, позволяющий работающим на хо- стах приложениям резервировать ресурсы в Интернете. Таким механизмом яв- ляется протокол RSVP (ReSerVation Protocol) – протокол резервирования. Его задача – резервирование пропускной способности линий и буферов маршрути- заторов. Используя этот протокол, хост от имени приложения запрашивает у сети определенный объем пропускной способности. Маршрутизаторы с помо- щью протокола RSVP пересылают запросы на резервирование ресурсов. Два свойства протокола RSVP:

• он может резервировать пропускную способность в деревьях группо- вой рассылки;

• резервирование инициируется и управляется получателем потока дан-

ных.

Однако протокол RSVP не определяет, каким образом сеть предоставляет

зарезервированную пропускную способность. Этим занимаются маршрутиза- торы (используя механизмы планирования – приоритетное обслуживание, взвешенная справедливая очередь и т. д.). RSVP не определяет также и те ли- нии, на которых должна быть зарезервирована пропускная способность. Это тоже функция маршрутизаторов.

Рассмотрим пример групповой рассылки (рис. 7.8).

R1

 

 

Отправитель

C                20 Кбит/с

R2

100 Кбит/с

 

A        B

R3

D                         3 Мбит/с

 

 

R4

3 Мбит/с

Рис. 7.8. Пример резервирования при групповой рассылке

Имеется источник, передающий в Интернет видео о спортивном сорев- новании. Видеоданные передаются с разными уровнями качества – 20, 100, 3000 Кбит/с. Каждый получатель посылает вверх по дереву групповой рассыл- ки запрос на резервирование ресурсов. В нем указывается требуемая скорость.

Запрос обрабатывается планировщиком узла, а затем пересылается вверх по дереву. Пользователи, подключенные к узлу D, резервируют 3 Мбит/с. Маршрутизатор D по линии D - В посылает запрос на резервирование маршру- тизатору В (то есть здесь объединяются запросы от RЗ и R4 – суммарная про- пускная способность – 3 Мбит/с).

 

Аналогично, на узле С резервируются пропускные способности 20 и 100 Кбит/с от R1 и R2. Узел С обрабатывает запрос и пересылает его в узел D (запрос на 100 Мбит/с). Здесь поток 20 Кбит/с включают в поток 100 Кбит/с.

Узел В обрабатывает запросы и по линии В - А передает на узел А запрос на резервирование 3 Мбит/с (100 Кбит/с включается внутрь этого потока).

Другой пример – проведение видеоконференции (рис. 7.9).

Положим, что в видеоконференции участвуют 4 собеседника, каждый из которых открывает на экране 3 окна.

Каждый из пользователей хочет получать от своих собеседников высоко- качественный поток 3 Мбит/с. Таким образом, надо резервировать пропускную способность: 3 Мбит/с – от пользователя и 9 Мбит/с – к пользователю.

Объединить потоки (как в предыдущем примере) здесь нельзя.

Отправитель/

Отправитель/ Получатель

9 Мби т/с   A            B

3 Мбит/с

 

 

C

Получатель 3 Мбит/с

9 Мбит/с

 

 

Отправитель/ Получатель

 

 

Отправитель/ Получатель

 

Рис. 7.9. Проведение видеоконференции

Реализация резервирования. Резервирование на маршрутизаторах и уз- лах реализуется в форме так называемого неустойчивого состояния.

С каждым запросом на резервирование на маршрутизаторе связывается таймер. Когда указанный интервал времени истекает, резервирование отменя- ется и ресурсы освобождаются.

Если получатель хочет продлить резервирование, он должен периодиче- ски повторять запросы.

Ограничение. Маршрутизатор, получив запрос, проверяет его на допу- стимость – имеются ли требуемые пропускные способности. Если таковых нет – запрос отвергается.

Стандарт на протокол. Протокол RSVP описан в документе RFC 2205. Он работает на уровне выше протоколов IP и UDP (т.е. уже на прикладном уровне).

Возможность подтверждения. Получатель может включать в запрос на резервирование RESV еще запрос на подтверждение этого резервирования. При успешном резервировании он получает подтверждение RESV Conf.