Многоцелевое расширение почты Интернет

Выгодное предложение: альбом для монет 25 рублей мультипликация в Москве.          

Протокол резервирования ресурсов RSVP


Если сетевые условия позволяют, то, используя протокол RSVP (где QoS задается в спецификации потока (flowspec) - практически на сегодня это единственное реализуемое решение), можно попытаться зарезервировать для заданной виртуальной сети определенное значение полосы пропускания. Следует иметь в виду, что протокол RSVP приспособлен в основном для резервирования определенного значения полосы пропускания, а не произвольного QoS (спецификации QoS см. в RFC-2210, 2211 и 2212) для существующего виртуального соединения. Если виртуальное соединение разорвано, следом ликвидируются и все резервирования. Следует, разумеется, иметь в виду, что >RSVP может работать как c TCP- так и c UDP-сессиями поверх IPv4 и IPv6. Сессия резервирования инициируется получателем данных. Резервирование может осуществляться как для уникаст, так и мультикаст-потоков. Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin «Resource ReSerVation Protocol», RFC-2205; смотри также RFC-2206-10, -2490, -2745-47, -2750-52, -2872, -2961, -2996, -3097, -3175, -3181, -3209-10) определяет режим резервирования (способ объединения нескольких заявок для одного и того же интерфейса: WF, FF, SE), формирования резервирования и его поддержания в условиях отсутствия поддержки данного протокола в одном или нескольких узлах виртуального пути, пересылки QoS-запросов другим маршрутизаторам и т.д., но решения принимаются маршрутизатором локально без знания условий в остальной части пути. По этой причине здесь не может идти речь о минимизации задержки, обеспечении надежности или безопасности, хотя в перспективе это может стать возможным.

Следует учитывать, что инициатором резервирования в RSVP всегда является клиент (именно он посылает первичные запросы). По этой причине могут возникнуть проблемы при попытке централизованного управления QoS посредством RSVP.

RSVP не имеет механизмов управления очередями в конкретных интерфейсах, а механизм резервирования полосы пропускания для одного из направлений обмена является зоной ответственности изготовителя маршрутизатора и не публикуется. Кроме того, при скоростях несколько сот Мбит/с часто обработка процедур буферизации перепоручается аппаратным средствам (например, в случае компании CISCO).

·        RSVP выполняет резервирование для уникастных и мультикастных приложений, динамически адаптируясь к изменениям членства в группе вдоль маршрута.

·        RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных.

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

·        RSVP поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов.

·        RSVP не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов.

·        RSVP транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP.

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

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

·        RSVP может работать с IPv4 и IPv6.

Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме.

Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

1.    "Rspec", который определяет желательное значение QoS, и

2.     "Tspec", который описывает информационный поток.

Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC 2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.

1.          Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC 2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.

2.          IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов. Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.

3.          IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов.

Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации.

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

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

Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

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

·        Стиль WF (Wildcard-Filter)

Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая «труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.

·        Стиль FF (Fixed-Filter)

Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии.

·        Стиль SE (Shared Explicit)

Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей.

Для облегчения работы с RSVP разработан протокол COPS (Common Open Policy Service; RFC-2748, The COPS Protocol, D. Durham, Ed. Смотри также RFC-2749, -2940 и -3084).

Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике. Предполагается, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [27-28]. Смотри также

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

При работе с АТМ ситуация ненамного лучше, программное обеспечение АТМ-коммутаторов также обычно не доступно. Но имеется возможность работы RSVP поверх АТМ [29-31].

Рассматривается внедрение протокола RSVP на уровень L2 [34].

При наличии механизмов реализации других типов QoS (смотри, например, RFC-2430 [21] и Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", где предлагается ввести дополнительные биты в заголовок), можно решить проблему в более общем виде (но эта технология находится лишь на стадии обсуждения и не внедрена ни на одном серийном приборе). В рамках одной автономной системы (AS), где используется внутренний протокол маршрутизации OSPF>, можно обеспечить требуемый уровень QoS, но это будет делаться вручную, во всяком случае, на уровне задания значений метрики. Теоретически можно это сделать и автоматически, например, в случае применения версии протокола IGRP (внутренний протокол компании CISCO), поддерживающего автоматическую оценку значений метрики. К сожалению, компания CISCO отошла от первоначального плана и значения метрики там задается в настоящее время также администратором.

Реализация управления QoS предполагает организацию эффективной системы мониторинга базовых параметров, характеризующих требуемый уровень QoS. Для этого требуется контролировать уровень информационных потоков во всех фрагментах VPN, постоянно измерять значение RTT и его дисперсии, контролировать уровень вероятности потери пакетов во всех фрагментах виртуального пути. Желательно также отслеживать корреляции перечисленных параметров и локального значения загрузки. Схема мониторинга и управления QoS показана на рис. 6.


Рис. 6.

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



Содержание раздела