Протокол RSVP осуществляет резервирование ресурсов посредством так называемых стилей резервирования (reservation styles). Стиль резервирования определяет каким образом множество запросов на резервирование объединяются и как запрос отправляется к следующему узлу. В спецификации RSVP определены следующие классы стилей резервирования ресурсов:

• индивидуальное резервирование (distinct reservation);

• долевое резервирование (shared reservation): отметим, что этот класс стилей резервирования разработан для приложений, использующих мультикастинг.

Ниже функционирование стилей резервирования будет объяснено на примере сетевого узла. Пусть существует некоторый сетевой узел с двумя входяшими // и 1₂и двумя исходящими О/ и 0₂интерфейсами (см. рис. 4.4). Далее предположим, что существует три источника Sj, S₂и 5?, причем нагрузка от S, поступает через интерфейс //, а нагрузка от S₂и 5? - через 1₂. Учитывая количество источников, определим количество приемников равное трем: R,, R₂и R₃.

Пусть приемник R, маршрутизируется через исходящий интерфейс ОI, а приемники R₂и R₃маршрутизируется через исходящий интерфейс 0₂. Как было показано ранее, протокол RSVP подразумевает, что запросы на резервирование поступают от приемника по направлению к источнику (сообщение RESV). Далее, для простоты, через переменную В обозначим единицу резервируемых ресурсов.

Для первого класса стилей резервирования, индивидуального, определен только лишь один стиль - Fixed Filter («постоянный фильтр», далее - FF):

• подразумевает индивидуальное резервирование с возможностью выбора источника (стратегия прямо противоположна WF-резер-вированию, рассмотренному ниже). При FF резервирование определяется для каждого отдельного источника. FF-резервирование может быть представлено как FF (SI (Ql), S2 (Q2Sn (Qn)), где S,, S₂, S„ - источники, a Q,, Q₂, Q„ - параметризации соответствующих этим источникам устанавливаемых соединений. Обратимся к примеру, приведенному на рис. 4.5. На исходящих интерфейсах отдельное резервирование выполняется для каждого из приемников, пославших запрос на резервирование. В случае поступления нескольких запросов на резервирование от разных приемников к одному и тому же источнику осуществляется резервирование с максимальным из поступивших значением.

Для второго класса стилей резервирования, долевого, определено два стиля - Wildcard Filter («фильтр без ограничений», далее- WF) и Shared Explicit («явное резервирование,», далее - SE):

• WF: гтодразуменает долевое резервирование без выбора конкретного источника. Размер WF-резервирования для всех источников равен максимальному значению количества запрашиваемых ресурсов одной из RSVP сессий, причем любой из источников может использовать это резервирование. WF-резервирование может быть представлено как WF (*, {Q}), где звезда определяет возможность выбора любого источника, а параметр Q - параметризацию устанавливаемого соединения (в нашем случае Q определяется через переменную В). Обратимся к примеру, приведенному на рис. 4.6. На исходящих интерфейсах О/ и 0₂поступают запросы на резервирование, причем через О, поступает запрос с наибольшим значением размера запрашиваемых ресурсов 4В, именно поэтому на все входящие интерфейсы /, передается запрос с наибольшим значением размера запрашиваемых ресурсов 4В.

• SE: подразумевает долевое резервирование с явным выбором конкретного источника. В SE-резервировании осуществляется выполнение одного объединенного резервирования и использования его несколькими определенными источниками. Оно может быть представлено следующим образом: SE( (SI, S2,…Sn) {Q_n}), где S_hS₂, S„ - источники, a Q - параметризация соответствующего устанавливаемого соединения. При объединении в результирующее резервирование включаются как исходные значения, так и результирующее, равное максимальному значению размера запрашиваемых ресурсов среди объединяемых резервирований. Пример SE-резервирования приведен на рис. 4.7.

Рис. 4.4. Конфигурация сетевого узла, поддерживающего протокол RESV

Рис. 4.6. Функционирование стиля резервирования WF

Рис. 4.7. Функционирование стиля резервирования SE

Важным фактом, определяющим корректное функционирование протокола RSVP, является то, что различные стили резервирования не могут объединяться, в связи с тем, что изначально они строятся с использованием различных моделей.

⇐Протокол резервирования ресурсов rsvp | Управление трафиком и качество обслужевания в сети | Временное состояние «soft state»⇒