Илл. 5.31. Гарантии пропускной способности и задержки с использованием маркерных ведер и WFQ
Самая большая задержка в очереди для данного потока — это функция максимальной емкости маркерного ведра. Рассмотрим два крайних случая. При равномерном трафике пакеты проходят через маршрутизатор с той же скоростью, с какой прибывают. При этом не происходит никаких задержек (не считая эффектов пакетирования). С другой стороны, если трафик передается пачками, то пачка максимального размера B может прийти на маршрутизатор полностью. Тогда максимальная задержка D будет равна времени прохождения пакета через маршрутизатор при фиксированной пропускной способности, или B/R (опять же, не считая эффектов пакетирования). Если этот показатель слишком высокий, поток может запросить большую пропускную способность.
Это достаточно строгие гарантии: маркерные ведра ограничивают неравномерность трафика, а справедливое обслуживание изолирует пропускную способность, выделяемую для разных потоков. Это значит, что гарантии пропускной способности и задержки для потока будут выполнены, даже если другие потоки будут копить трафик и отправлять его одновременно.
Более того, результат не зависит от количества маршрутизаторов в узлах пути и от топологии сети. Каждому потоку предоставляется минимальная пропускная способность благодаря тому, что она зарезервирована на каждом маршрутизаторе. Причина, по которой каждый поток получает максимальную задержку, менее явная. В наихудшем случае, если крупный объем трафика поступит на первый маршрутизатор и будет соревноваться с трафиком других потоков, максимальная задержка будет равна D. Однако после этого трафик станет более равномерным, и поэтому на следующих маршрутизаторах такой задержки уже не будет. В результате общая задержка в очереди не будет превышать D.
5.4.4. Комплексное обслуживание
В 1995–1997 годах IETF приложила множество усилий по продвижению архитектуры потокового мультимедиа. В результате появилось две дюжины документов RFC: от RFC 2205 до RFC 2212. Общее название этих трудов — комплексное обслуживание (integrated services). Эта технология предназначена как для одноадресных, так и для многоадресных приложений. В первом случае это может быть просмотр потокового видео на новостном сайте одним пользователем; во втором — набор станций цифрового телевидения, транслирующих свои программы в виде потоков IP-пакетов. Данной услугой может пользоваться большое число абонентов в разных географических точках. Далее мы подробнее рассмотрим многоадресную рассылку, поскольку одноадресная передача — это лишь частный случай многоадресной.
Во многих приложениях с многоадресной маршрутизацией группы пользователей могут динамически меняться. Например, люди участвуют в видеоконференции, потом им становится скучно, и они переключаются на мыльную оперу или спортивный канал. В данном случае стратегия предварительного резервирования пропускной способности не совсем подходит, потому что каждому источнику пришлось бы запоминать все изменения в составе аудитории. В системах, предназначенных для передачи телевизионного сигнала миллионам абонентов, этот метод вообще не сработает.
RSVP — протокол резервирования ресурсов
Главный компонент архитектуры комплексного обслуживания, открытый для пользователей сети, — протокол резервирования ресурсов (Resource reSerVation Protocol, RSVP). Он описывается в стандартах RFC 2205–RFC 2210. Как следует из названия, протокол предназначен для резервирования ресурсов; другие протоколы применяются для описания передачи данных. RSVP позволяет нескольким отправителям отправлять данные нескольким группам абонентов, разрешает отдельным получателям переключать каналы и оптимизирует использование пропускной способности, в то же время устраняя перегрузки.
Самый простой вариант этого протокола использует упомянутую ранее многоадресную маршрутизацию с применением связующих деревьев. Каждая группа получает адрес. Чтобы передать ей данные, отправитель помещает этот адрес в заголовки пакетов. Затем стандартный алгоритм многоадресной маршрутизации строит связующее дерево, охватывающее всех членов группы. Этот алгоритм не является частью протокола RSVP. Единственное отличие от обычной многоадресной маршрутизации состоит в том, что группе периодически рассылается дополнительная информация, с помощью которой маршрутизаторы обновляют в памяти определенные структуры данных.
Рассмотрим сеть на илл. 5.32 (а). Хосты 1 и 2 — многоадресные отправители, а хосты 3, 4 и 5 — многоадресные получатели. В данном примере они разделены, однако в большинстве случаев эти два множества могут перекрываться. Деревья многоадресной рассылки для хостов 1 и 2 показаны на илл. 5.32 (б) и (в) соответственно.
Илл. 5.32. Протокол резервирования ресурсов (а) Сеть. (б) Связующее дерево многоадресной рассылки для хоста 1. (в) Связующее дерево многоадресной рассылки для хоста 2
Для улучшения качества приема и устранения перегрузки каждый получатель в группе может отправить источнику (вверх по дереву) запрос на резервирование. Это сообщение продвигается с использованием переадресации в обратном направлении, которую мы обсуждали ранее. На каждом транзитном участке маршрутизатор замечает запрос и резервирует необходимую пропускную способность. В предыдущем разделе мы видели, как это делает планировщик WFQ. Если пропускной способности недостаточно, маршрутизатор информирует об ошибке. К тому моменту, как запрос приходит обратно к источнику, пропускная способность зарезервирована на пути от отправителя к получателю по связующему дереву.
Пример резервирования показан на илл. 5.33 (а). Здесь хост 3 запросил канал к хосту 1. После создания канала поток пакетов от хоста 1 к хосту 3 может идти без перегрузок. Рассмотрим, что произойдет, если теперь хост 3 зарезервирует канал к другому отправителю, хосту 2, чтобы пользователь мог одновременно смотреть две телевизионные программы. Резервирование второго канала показано на илл. 5.33 (б). Обратите внимание: между хостом 3 и маршрутизатором E должно быть два отдельных канала, так как передаются два независимых потока.
Илл. 5.33. Пример резервирования. (а) Хост 3 запрашивает канал к хосту 1. (б) Затем хост 3 запрашивает второй канал к хосту 2. (в) Хост 5 запрашивает канал к хосту 1
Наконец, на илл. 5.33 (в) хост 5 решает посмотреть программу, передаваемую хостом 1, и также резервирует себе канал. Сначала требуемая пропускная способность резервируется до маршрутизатора H. Затем он замечает, что у него уже есть канал от хоста 1, поэтому дополнительное резервирование выше по дереву не требуется. Обратите внимание, что хосты 3 и 5 могут запросить разную пропускную способность (например, у хоста 3 маленький экран, поэтому ему не нужно высокое разрешение). Следовательно, H должен зарезервировать пропускную способность, достаточную для получателя с самым большим запросом.
При подаче запроса получатель может (по желанию) указать один или несколько источников, от которых он хотел бы получать сигнал. Он также может сообщить, является ли выбор источников фиксированным в течение времени резервирования или он оставляет за собой право сменить их. Эти сведения используются маршрутизаторами для оптимизации планирования пропускной способности. К примеру, двум получателям выделяется общий путь, только если они соглашаются не менять впоследствии свой источник.
В основе такой динамической стратегии лежит независимость зарезервированной пропускной способности от выбора источника. Зарезервировав полосу, получатель может переключаться с одного источника на другой, сохраняя часть существующего пути, которая подходит для нового источника. Например, если хост 2 передает несколько видеопотоков в реальном времени (например, при многоканальном телевещании), хост 3 может переключаться между ними по желанию, не меняя своих параметров резервирования: маршрутизаторам все равно, какую программу смотрит получатель.