Теперь, когда мы познакомились с основными компонентами QoS, самое время объединить их, чтобы реально его обеспечить. Гарантии QoS предоставляются через управление допуском. Мы рассматривали его как средство борьбы с перегрузкой, что является гарантией производительности, пусть даже не очень эффективной. Здесь мы предъявляем к гарантиям более серьезные требования, но модель остается той же. Пользователь передает в сеть поток, предъявляя определенные требования QoS. Сеть принимает или отвергает этот поток в зависимости от своих возможностей и обязательств перед другими клиентами. Если поток принимается, сеть должна заранее зарезервировать ресурсы, чтобы при передаче по нему трафика клиент получил необходимый уровень QoS.
Необходимо зарезервировать ресурсы на всех маршрутизаторах, расположенных в узлах пути, по которому следуют пакеты. Иначе может возникнуть коллапс, и гарантии QoS не будут выполнены. Многие алгоритмы маршрутизации выбирают наилучший путь от отправителя до получателя и направляют по нему весь трафик. Однако некоторые потоки могут быть отвергнуты из-за недостатка ресурсов в узлах наилучшего маршрута. Тогда, чтобы выполнить свои обязательства, сеть выберет другой путь для отправки крупного потока. Этот подход называется QoS-маршрутизацией (QoS routing); см. работу Чэня и Нарштедт (Chen and Nahrstedt, 1998). Также можно разделить трафик для одного адресата по нескольким маршрутам, чтобы было проще найти дополнительные ресурсы. Маршрутизаторы могут выбирать пути с одинаковой стоимостью и использовать маршрутизацию, пропорциональную или эквивалентную емкостям исходящих связей. Однако существуют и более сложные алгоритмы (Нелакудити и Чжан; Nelakuditi и Zhang, 2002).
С учетом выбранного пути решение о принятии или отклонении потока не сводится к сравнению запрашиваемых ресурсов (пропускной способности, буферной памяти, времени CPU) с возможностями маршрутизатора. Во-первых, несмотря на то что многие приложения знают свои требования по пропускной способности, два других параметра им неизвестны. Следовательно, как минимум необходим иной способ описания потоков и определения ресурсов, выделяемых маршрутизатором. Вскоре мы это обсудим.
Также отметим, что приложения значительно различаются по толерантности в отношении пропущенного предельного срока обработки. Поэтому приложение должно выбрать один из типов гарантий, предлагаемых сетью: от строгих до максимально лояльных. При прочих равных условиях наиболее популярными были бы строгие гарантии. Но проблема в том, что они затратные, так как ограничивают поведение сети в наихудшем случае. Для приложения обычно достаточно тех же гарантий, что и для большинства пакетов; кроме того, они позволяют добавить дополнительный поток при фиксированной емкости.
Наконец, некоторые приложения могут поторговаться за параметры пакетов, а некоторые нет. Скажем, проигрыватель видео, обычно предоставляющий 30 фреймов/с, может работать на 25 фреймах/с, если для 30 не хватает пропускной способности. Аналогично можно настраивать количество пикселей на фрейм, полосу пропускания для аудиоданных и другие свойства потоков различных приложений.
Поскольку в споре о том, что делать с потоком, участвует много сторон (отправитель, получатель и все маршрутизаторы на пути между ними), поток необходимо описывать крайне аккуратно с помощью параметров, о которых можно договориться. Набор таких параметров называется спецификацией потока (flow specification). Как правило, отправитель (например, сервер видеоданных) создает спецификацию, указывая нужные ему параметры. По мере движения спецификации по пути потока маршрутизаторы анализируют ее и меняют параметры, если нужно. Эти изменения могут быть направлены только на уменьшение потока (например, скорость передачи данных может быть понижена, но не повышена). Когда спецификация доходит до получателя, устанавливаются окончательные параметры.
В качестве содержимого спецификации потока рассмотрим пример на илл. 5.30. Он основан на RFC 2210 и RFC 2211 для комплексного обслуживания — технологии QoS, о которой мы поговорим в следующем разделе. В спецификации содержится пять параметров. Первые два, скорость маркерного ведра и размер маркерного ведра, позволяют вычислить максимальную скорость, которую источник может поддерживать в течение долгого времени, усредненную по большому временному отрезку, а также максимальный объем пачки, передаваемой за короткий промежуток времени.
Параметр
Единицы измерения
Скорость маркерного ведра
байт/с
Размер маркерного ведра
байт
Пиковая скорость передачи данных
байт/с
Минимальный размер пакета
байт
Максимальный размер пакета
байт
Илл. 5.30. Пример спецификации потока
Третий параметр, пиковая скорость передачи данных, — это максимальная допустимая скорость (даже для коротких временных интервалов). Отправитель ни в коем случае не должен превышать это значение.