В. Столлингс - Современные компьютерные сети (2-е издание, 2003) (1114681), страница 133
Текст из файла (страница 133)
Поскольку резервирование ресурсов и протокол КЗУР не зависят от протоколов маршрутиаации, в смешанном окружении, в котором некоторые маршрутизаторы могут не использовать протокол К5'у'Р, конфликта не возникает. Такие маршрупшаторы просто передают данные по остаточному принципу. + Поддержка протоколов 1ро4 и 1Рггб. Протокол КВЪ'Р может использовать поле типа службы в заголовке! Ру4 и поле метки потока в заголовке 1Руб. Такие две характеристики протокола, как резервирование, инициированное получателем, и гибкое состояние, стоит обсудить особо. Резервирование, инициированноеполучателем Рассматривавшиеся ранее методы резервирования ресурсов, а также подход, применяемый в сетях АТМ и сетях ретрансляции кадров, поаволяют источнику потока данных запросить определенный набор ресурсов. Приложение получает возможность передавать данные с определенной скоростью и получать обслуживание определенного уровня качества, причем эти характеристики встраиваются в схему передачи данных.
Однако такой подход не годится для групповой рассылки. Как уже упоминалось, у различных членов одной н той же группы рассылки могут быть разные потребности в Ресурсах. Если передаваемый источником поток данных может быть разделен на составляющие подпотоки, тогда отдельные члены группы рассылки могут удовлетвориться приемом только одного из подпотоков. Если трансляцию для группы получателей ведут одновременно несколько источников, то, возможно, некоторые члены группы захотят принимать передачу толь- ко от одного источника или от подмножества источников.
Наконец, требования к качеству обслуживания у разных получателей также могут различаться в зависимости от оконечного оборудования, обрабатывающих мошностей и пропускной способности канала получателя, Таким образом РезеРвировать ресурсы имеет смысл скорее для получателей чем для отправителей. Отправитель обязан предоставить маршрутизаторам характеристики графика (скорость передачи данных, ее неравномерность), но желаемый уровень качества обслуживания должны указывать получатели. Затем маршрутизаторы могут проанализировать совокупные заявки на предоставление ресурсов, чтобы учесть общие участки маршрута в дереве распределения.
Гибкое состояние В протоколе КЗЧР используется концепция гибкого состояния. Это понятие, предложенное в [501, его стоит процитировать'. Хотя дейтаграмма очень хорошо служила для решения самых важных задач Интернета, оказалось, что решить такие задачи, как управление ресурсами и учет, весьма непросто.
Большинство дейтаграмм на прикладном уровне представляют собой часть некоторой последовательности пакетов от источника до получателя, а не изолированные блоки данных. Однако шлюз не может сам определить факт наличия данной последовательности, так как работает с каждым пакетом отдельно. Поэтому и решение об управлении ресурсами или учете принимается для каждого пакета отдельно. Таким образом, можно предположить, что для архитектуры следующего поколения должен использоваться более подходящий гстроительный блок», нежели дейтаграмма. Обшая характеристика этого строителыюго блока заключается в том, что он будет идентифицировать последовательность пакетов, направляюшук1ся от источника к получателю. Для данного строительного блока я использовал термин впоток» (йоту).
На шлюзах должна храниться информация о состоянии текуших череа них потоков, но эта информация не должна быть критичной для поддержания типа обслуживания, ассоциированного с потоком. Напротив, тип обслуживания должны заказывать оконечные точки путем периодической отправки сообшений, гарантирующих, что с данным потоком будет ассоциирован соответствующий тип обслуживания, Таким образом, ассоциированная с потоком информация о состоянии этого потока может быть потеряна в случае сбоя, не выавав окончательной недоступности выбранного типа обслуживания. Я называю эту концепцию гибким состоянием. По сушеству, в ориентированных на соединение схемах применяется подход жесткого состояния, в котором природа соединения вдоль фиксированного маршРута определяется информацией о состоянии, хранящейся на промежуточных коммутируюших узлах, В протоколе К5Ъ'Р используется метод гибкого состояния, то есть метод, не требующий соединения, в котором состояние зарезервированных ' Термин шлю» вспельзуется вместо термина магга»уыиватоп в большинстве ранних документов дГС и в литературе, пвевяшеааай прет»колам ТСР/! Р; иногла этот термин используется в»том»изчезав ло сиз пор (к»пример, птетоквл ВГР— Вогдег Смея»у Ргососо!, дословно е югран ичный шлкеввм~~ протокол»).
5УЗ Глава 18. Протоколы поддержания качества обслуживания 18,1. Протокол ПВНР 579 ресурсов представляет собой информацию, кэшируемую на маршрутизато :аторе, но записываемую и периодически обновляемую оконечными системами. Если -ели сосуд яние не обновляется в течение определенного интервала времени, маршрути Р прутизатор удаляет эту информацию. Если для данного потока выбирается новый марш маршрут оконечные системы посылают заявки на предоставление ресурсов новым, м маршрутизаторам, находящимся на пути следования данных.
Потоки данных Три концепции, относящиеся к потокам данных, являются базовыми для раб яра оты протокола КЗНР. Это сеанс, спецификация потока и спецификация фильтра. Сеансом называют поток данных, идентифицируемый по его месту назн назначения (то есть адресату, или получателю). Причина использования термина сел а сеанс (эюэ1оп) вместо термина место назначения (оеэтша11оп) заключается в том, что данный термин отражает основанную на гибком состоянии природу функционирования протокола КВН Р. Когда на маршрутизаторе в определенном направлении реаервируются ресурсы, маршрутизатор рассматривает эти действия как сеанс и выделяет ресурсы только на время сеанса. В частности, сеанс определяется следующими характеристиками: + 1Р-адресом получателя; + идентификатором 1Р-протокола; + портом назначения, 1Р-адрес получателя может быть одиночным или групповым.
Идентификатор протокола указывает на пользователя протокола 1Р (то есть на протокол ТСР или 1Л)Р), а порт назначения представляет собой порт пользователя протокола ТСР или 131>Р. Если адрес групповой, порт назначения является необязательным. так как у различных приложений групповые адреса, как правило, различаются. Запрос на резервирование ресурсов, посылаемый получающей оконечной системой, называется олисателем потока (Йо>у деэспр1ог) и состоит иа спецификации потока (йоту эрос(Всат(оп) и спецификации фильпуа (Игег эрос>йсагюп). Спецификация потока содержит информацию о запрашиваемом уровне качества обслуживания н используется для установки параметров планировщика пакетов узла.
Таким образом, маршрутизатор будет передавать пакеты с заданным набором прел- почтений, основываясь на текущей спецификации потока. Спецификация фильтра определяет множество пакетов, для которых запрашивается резервирование ресурсов. Таким образом, спецификация фильтра вместе с сеансом определяют множество пакетов (то есть поток), которые должны приниматься с указанным уровнем качества обслуживания.
Любые другие пакеты, адресуемые тому же получателю, обслуживаются по остаточному принципу. Содержимое спецификации потока не относится к протоколу КБНР, который представляет собой всего лишь транспортное средство для передачи защюсов. В общем случае спецификация потока содержит следующие элементы: Ф класс службы; + спецификацшо резервирования; + спецификацию графика. Класс службы представляет собой идентификатор типа запрашиваемой службы. Он включает информацию, используемую маршрутизатором для объединения запросов. Остальные два параметра представляют собой численные значения.
Спецификация резервирования определяет желаемый уровень качества обслуживания, а спецификация графика описывает поток данных. Содержимое этих параметров является непрозрачным для протокола КБЪ'Р. В принципе, спецификация фильтра позволяет идентифицировать произвольное подмножество пакетов одного сеанса (то есть пакетов, прибывающих адресату данного сеанса). Например, спецификация фильтра может указывать только особые источники или конкретные протоколы источника либо только пакеты, в загооля Вт ейве сии Ъ'Р ней тью, ото- слу- Пакет (эдре Рно.
18.1. Обработка пакетов одного сеанса на одном маршрутизаторе Работа протокола ЙВЧР Протокол КБНР, в основном, предназначен для управления групповой рассылкой. Целевая рассылка обрабатывается как специальный случай. В дальнейшем мы будем рассматривать работу протокола КБНР в условиях резервирования ресурсов для групповой рассылки. В обсуждении используется конфигурация объединенной сети, показанная на рис.
18.2, а. Эта конфигурапия состоит из четырех соединенных друг с другом маршрутизаторов (К1, К2, КЗ и К4). Каналы ловках которых совпадают определенные п . екугп р протокола КЗ используется спецификация фильтра, состоящая из следующих элементов: + адреса отправителя; + порта Б))Р или ТСР отправителя. Рисунок 18.1 иллюстрирует взаимоотношения между сеансом, спецификац потока и спецификацией фильтра. Каждый прибывающий пакет является час самое болыпее, одного сеанса и обрабатывается в соответствии с логическим п ком для этого сеанса.
Если пакет не принадлежит ни одному из сеансов, он об живается по остаточному принципу. ! Пакеты, Планировщик пакетов 18.1. Протокол Взур 581 Рис. 18.2. Работа протокола ПВНР 580 Глава 18. Протоколы поддержания качества обслуживания связи между маршрутизаторами, изображенные в виде линий, могут быть двух. чечными соединениями или подсетямн. Три хоста (С1, С2 и СЗ) являются членам1 группы рассылки и могут получать дейтаграммы с соответствующим групповы, адресом получателя.
Два хоста (81 н 52) передают данные по этому групповому адресу. Жирные черные линии обозначают лерево марнзрутов для источника 81 и этой группы получателей, а жирные серые линии указывают дерево маршрутов для источника 82 и этой групп~ ~ Лигпн1 со стрелками обозначают переда гу пак тов от источника 81 (черные) и от источника 52 (серые). Как видно, все четыре маршрутизатора должны знать о том, какие ресурсы зарезервированы для каждой группы получателей. Таким образом, запросы на предоставление ресурсов должны распространяться вверх по дереву маршрутов к каждому потенциальному хосту. Фильтрация На рис. 18.2, б показан случай, при котором хост СЗ резервирует ресурсы, указывая в спецификации фильтра оба источника, 51 и 52, тогда как хосты С1 н С2 запрашивают передачу только от источника 51.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
