Сети с предоставлением интегрированных услуг

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

Все больше людей используют сеть Internet для своих частных и служебных нужд. Соответственно, пропорциональным образом возрастает объем передаваемых через сеть Internet данных. Новые приложения типа аудио- и видео в реальном времени, IP-телефонии и видеоконференций нуждаются в более высокой пропускной способности, нежели приложения Internet первого поколения. И, что очень важно, приложения реального времени не могут работать при значительном проценте потерь пакетов или при длительных задержках прохождения пакетов, в то время как эти характеристики не являются критическими для традиционных приложений Internet, типа FTP или telnet.

В свою очередь, при отсутствии контроля за распределением пропускной способности качество этих потоков реального времени зависит только от доступной пропускной способности. При малой или, что еще хуже, непостоянной пропускной способности приложения реального времени будут работать неудовлетворительно. Даже при использовании протокола реального времени (Real-Time Protocol, RTP) функционирование приложений будет зависеть от возможностей сети IP по предоставлению соответствующего качества обслуживания.

Таким образом, неотъемлемым условием при разработке любой новой концепции обслуживания стало гарантированное предоставление определенного качества обслуживания QoS для приложений Internet реального времени. При этом качество обслуживания характеризуется набором параметров для определенного потока данных (например, пропускная способность, объем буфера, назначенный приоритет, степень загруженности центрального процессора и т. д.).

Обеспечение качества обслуживания

Стандартные протоколы стека TCP/IP обеспечивают только обслуживание по мере возможности. Пакеты передаются без предоставления какой-либо гарантии на выделение требуемой пропускной способности или обеспечение минимальной задержки. Все запросы имеют одинаковый приоритет и обрабатываются последовательно один за другим. Возможность зарезервировать пропускную способность или изменить приоритет для определенных приложений не предусматривается.

Все эти вопросы были учтены при разработке новой стратегии предоставления предсказуемых услуг в сети Internet. В настоящее время качество обслуживания может быть интегрировано в сеть Internet двумя путями:

• предоставлением интегрированных услуг (Integrated Services, IS);
• предоставлением дифференцированных услуг (Differentiated Services, DS).

Введение интегрированных услуг приводит к расширению модели сети IP, чтобы она могла поддерживать передачу информации в реальном времени и предоставлять гарантируемую пропускную способность для определенных потоков. В этом случае потоки требуется идентифицировать как различные, например поток видеоинформации между конкретной парой абонентов. Инициируя такой поток данных, каждое приложение может определить необходимые ему параметры качества обслуживания. Например, приложение видеоконференции может запросить у сети пропускную способность в 128 Кбит/с с задержкой пакетов не более 100 мс.

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

Интегрированные услуги

Модель сети Internet с предоставлением интегрированных услуг (IS) была определена рабочей группой IETF. Эта модель дополняет обслуживание по мере возможности услугами в реальном времени и резервированием пропускной способности в сети Internet.

Модель сети с предоставлением IS была разработана в целях оптимизации использования ресурсов сети новыми приложениями типа передачи мультимедийной информации в реальном времени. Для предоставления интегрированных услуг маршрутизатор Internet должен уметь обеспечить требуемое QoS для каждого потока в соответствии с запрошенными параметрами. Основной функцией маршрутизатора становится, таким образом, функция контроля и управления поступающим потоком информации. Эту функцию реализуют следующие основные подсистемы.

• Планировщик пакетов (Packet scheduler). Планировщик пакетов с помощью подсистемы управления очередями и других алгоритмов планирования регулирует отправку различных потоков пакетов на рабочие станции и маршрутизаторы в соответствии с назначенными им сервисными классами. Он следит за тем, чтобы пакеты доставлялись получателю в соответствии с заданными параметрами QoS для каждого потока. Планировщик пакетов может выполнять функции формирования трафика для того, чтобы тот соответствовал некоторому заданному уровню обслуживания. Планировщик пакетов должен функционировать в точке, где пакеты ставятся в очередь. Этой точкой обычно является протокол канального уровня в операционной системе маршрутизатора.
• Классификатор пакетов (Packet classifier). Классификатор пакетов идентифицирует пакеты потока IP на рабочих станциях и маршрутизаторах. Каждый входящий пакет относится им к определенному классу. Все пакеты определенного класса получают одинаковую обработку от планировщика пакетов. Выбор конкретного класса осуществляется исходя из приоритетов отправителя и получателя, IP-адреса и номера порта в заголовке пакета или дополнительного номера классификации, добавляемого к каждому пакету. Однотипные потоки принадлежат обычно - но не обязательно - к одному классу. Например, все потоки видеоинформации при проведении видеоконференции с несколькими участниками могут принадлежать к одному сервисному классу. Вместе с тем, при определенных условиях, один поток видеоконференции может быть отнесен к более высокому сервисному классу, чем остальные.
• Контроль доступа (Admission control). Контроль доступа основан на алгоритме выбора, который маршрутизатор использует для определения достаточности имеющихся у него ресурсов для обслуживания нового потока с требуемым QoS. Если для обслуживания нового потока у маршрутизатора нет достаточных свободных ресурсов, то такой поток должен быть отклонен, тем более, если новый поток будет негативно воздействовать на уже проходящий через маршрутизатор трафик с выданной гарантией на QoS. Если же требования нового потока могут быть удовлетворены, то маршрутизатор поручает классификатору и планировщику пакетов зарезервировать часть своих ресурсов под обеспечение требуемого для этого потока QoS. Контроль доступа реализуется в каждом маршрутизаторе с поддержкой резервирования ресурсов и служит для принятия решения о предоставлении ресурсов или об отклонении запроса на обслуживание в реальном времени. Алгоритм контроля за доступом должен быть совместим с предложенной моделью обслуживания.

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

Интегрированные услуги предоставляются с использованием протокола резервирования ресурсов (Resource ReSerVation Protocol, RSVP) для передачи запросов о резервировании. Как показано на Рисунке 1, если приложение хочет зарезервировать для потока пакетов с данными определенные ресурсы сети, то оно обращается к услугам протокола резервирования RSVP. Протокол RSVP начинает процедуру резервирования ресурсов для обеспечения требуемого QoS. Запрос на выделение ресурсов будет удовлетворен, если, во-первых, само приложение соответствует выдвинутым ограничениям и, во-вторых, если маршрутизаторы способны обеспечить требуемое QoS. Протокол RSVP уведомляет классификатор и планировщик пакетов каждого маршрутизатора о необходимости проведения соответствующей обработки этого потока. Если приложение теперь передаст пакеты с данными классификатору первого маршрутизатора, то до того, как трафик будет отправлен следующему узлу на пути следования, поток передается планировщику пакетов в соответствии с классом, присвоенным ему маршрутизатором. Планировщик пакетов определяет очередность отправки пакетов этого приложения на следующий маршрутизатор или конечную станцию о соответствии с их сервисным классом.

Поскольку протокол RSVP работает как бы в симплексном режиме, то резервирование QoS производится только в одном направлении, а именно от отправителя к получателю. Если приложение хочет отменить резервирование для своего потока данных, то оно посылает уведомление в отвечающую за резервирование инстанцию для освобождения зарезервированных ресурсов на всех маршрутизаторах по пути следования потока. Эти ресурсы теперь могут использоваться для других потоков. Технические требования на IS определены в документе RFC 1633.

Сервисные классы

Интегрированная модель предоставления услуг описывает различные классы обслуживания в соответствии с определениями интегрированных услуг рабочей группы IETF. В зависимости от типа приложения, эти сервисные классы предусматривают более жесткие или более свободные требования к процедуре обеспечения качества обслуживания. Текущая модель IS включает два сервисных класса: гарантируемое обслуживание (guaranteed service), которое определено в документе RFC 2212, и контролируемую нагрузку (controlled load service), которая описана в документе RFC 2211. Для понимания различия этих сервисных классов необходимо пояснить значение некоторых терминов.

Каждому потоку назначается описатель потока (flow descriptor). Он определяет характеристики трафика для конкретного потока пакетов данных. Описатель потока состоит из спецификации фильтра (filterspec) и спецификации потока (flowspec). Рисунок 2 показывает связь между сеансом, спецификацией фильтра и спецификацией потока.

Спецификация фильтра используется для идентификации пакетов одного и того же потока с определенным IP-адресом отправителя и выходным портом. Содержащаяся в спецификации фильтра информация используется классификатором пакетов. Спецификация потока содержит набор параметров, обобщенно называемых информацией вызова (invocation information). Эту информацию можно разделить на две группы:

• спецификацию трафика (Traffic Specification, Tspec);
• спецификацию сервисного запроса (Serviсe Request Specification, Rspec).

Tspec описывает характеристики трафика с требуемым обслуживанием. В модели с предоставлением IS требования Tspec реализуются маркерным фильтром области памяти (token bucket filter). Используемый принцип предусматривает потоковый механизм контроля и управления, в соответствии с которым маркеры добавляются в буферную область памяти через определенные интервалы времени. Отправитель получает разрешение передавать пакеты данных только в том случае, если содержащееся в области памяти количество маркеров соответствует (больше или равно) длине этого пакета данных. Подобная стратегия позволяет осуществлять строгий контроль за поступлением пакетов данных в сеть. Маркерная система организации области памяти характеризуется двумя параметрами - маркерной скоростью r, с которой маркеры помещаются в область памяти, и объемом области памяти b. Обе величины, r и b, должны быть положительными.

Параметр r определяет среднюю скорость передачи данных и измеряется количеством байт в секунду. Значение этого параметра может меняться в диапазоне от одного байта в секунду до 40 терабайт в секунду. Параметр b измеряется в байтах, исходя из максимальной скорости, с которой система может передавать данные. Значение этого параметра может варьироваться в пределах от одного байта до 250 гигабайт. Диапазон значений для этих параметров выбран намеренно завышенным для того, чтобы его не пришлось менять впоследствии с развитием сетевых технологий. При применении маркерных фильтров области памяти трафик должен подчиняться следующему правилу: для всех периодов времени T количество посланных данных не должно превышать значения (rT+b), где r и b - маркерные параметры области памяти.

Спецификация Tspec включает также два других маркерных параметра области памяти: минимальный размер пакета m и максимальный размер пакета M. Короткие пакеты могут быть отброшены маркерным фильтром области памяти как не соответствующие размеру m. Параметр M определяет максимальный размер пакета в байтах в соответствии со спецификацией трафика Tspec. Запрос на обслуживание будет отклонен сетью, если требуемый максимальный размер пакета больше, чем принятое в данной сети значение MTU.

Спецификация сервисного запроса (Rspec) определяет качество обслуживания, которое приложение хотело бы получить для конкретного потока. Она зависит от типа обслуживания и требований приложения к QoS. Это может быть определенная пропускная способность, максимальная задержка пакета или максимальное количество потерянных пакетов. В модели сети с IS информация Tspec и Rspec используется планировщиком пакетов.

Сервисное управление нагрузкой

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

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

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

Сервисное управление нагрузкой не принимает во внимание и не использует в своей работе такие параметры, как пропускная способность, задержки или потери пакетов. Поэтому при применении управления нагрузкой приложения должны иметь собственные механизмы обнаружения и реагирования на случай, вообще говоря, редких потерь пакетов и небольших задержек пакетов.

Механизм резервирования QoS с использованием управления нагрузкой должен предоставить спецификацию трафика Tspec с указанием маркерной скорости r и объема области памяти b, а также минимального m и максимального M размера пакетов. Предоставление спецификации сервисного запроса Rspec не обязательно, так как управление нагрузкой не предусматривает резервирование заданной пропускной способности или гарантии минимальной задержки пакетов. Управление нагрузкой обеспечивает качество обслуживания, только если трафик соответствует требуемому уровню Tspec. Это означает, что пакеты получают гарантию обслуживания, только если они не нарушают правило маркерного распределения области памяти, в соответствии с которым для всех периодов времени T объем посланных данных не может превышать величину, равную rT+b.

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

Гарантируемое обслуживание

Моделью с гарантируемым обслуживанием предусматривается, что пакеты поступят к получателю в пределах оговоренного периода времени. Это означает, что каждый пакет потока, - если он соответствует техническим требованиям трафика, - прибудет к получателю в пределах допустимой задержки по времени. Гарантируемое обслуживание предоставляется приложениям, для нормальной работы которых дейтаграммы должны дойти до получателя не позже, чем через определенное время после того, как они были переданы в сеть отправителем.

Гарантируемое обслуживание не минимизирует вариацию (разницу во времени между минимальными и максимальными задержками при передачи дейтаграмм), но оно учитывает максимальную задержку при организации очередей. Сервисная модель с гарантируемым обслуживанием предоставляет достаточно мощный механизм управления задержками в сетях. Другие сервисные модели имеют намного более слабые возможности по управлению задержками. Следует сказать, что гарантируемое обслуживание достигает цели только в тех случаях, когда оно поддерживается каждым маршрутизатором на пути резервирования.

Гарантируемое обслуживание открывает перед приложениями значительные возможности по контролю за задержками. При рассмотрении этого вопроса необходимо помнить, что задержка в IP-сети имеет две составляющие: фиксированную задержку при передаче пакетов и переменную задержку вследствие организации очередей. Фиксированная задержка зависит от выбранного маршрута передачи пакетов, причем он выбирается без участия механизма качества обеспечения обслуживания. Задержка вследствие организации очередей зависит от эффективности гарантируемого обслуживания и определяется двумя параметрами: маркерной областью памяти (в частности, размером области памяти b) и пропускной способностью R. Эти параметры используются для описания потоковой модели (fluid model) с учетом непрерывных изменений в характеристиках потока.

Потоковая модель определяет обслуживание, аналогичное тому, которое приложение могло бы получить при организации выделенного канала связи между отправителем и получателем, с заданной пропускной способностью R. В потоковой модели обслуживание определенного потока полностью независимо от обслуживания других потоков. Если такой переменный поток поддерживает параметры маркерной области памяти (r, b) и проходит по каналу с пропускной способностью R > r, то в этом случае характеристики предоставляемого гарантированного обслуживания потока с изменяемой задержкой ограничены величиной отношения R/r. Гарантируемое обслуживание обеспечивает работу с сервисной скоростью R, где R теперь - доля пропускной способности при следовании через маршрутизаторы, а не пропускной способности выделенной линии.

В сервисной модели с гарантированным обслуживанием резервирование ресурсов производится с учетом требований Tspec и Rspec. Tspec представлена маркерными параметрами области памяти. Rspec содержит параметр резервируемой пропускной способности. Сервисная модель с гарантируемым обслуживанием определена в документе RFC 2212.

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

Интегрированной моделью предоставления услуг предусматривается использование протокола резервирования ресурсов RSVP в целях обеспечения качества обслуживания методами резервирования. Протокол RSVP определен в документе RFC 2205 и имеет статус предложения по стандарту. RSVP - это протокол управления сетью Internet, а не протокол маршрутизации; необходимым условием его применения является совместное с ним использование одного из существующих протоколов маршрутизации. Протокол RSVP работает на более высоком уровне, нежели протоколы IP и UDP, и должен поддерживаться всеми маршрутизаторами по пути следования пакетов. Ключевые понятия протокола RSVP - это потоки и резервирование ресурсов.

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

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

Процедура резервирования ресурсов по протоколу RSVP инициализируется получателем. Отправитель сообщает получателю о характеристиках организуемого потока. В ответ получатель посылает сообщения протокола RSVP о резервировании ресурсов назад отправителю с указанием желательных параметров QoS. Такая схема гарантирует удовлетворение требований к QoS различных получателей в гетерогенных сетях с многоадресной рассылкой. При этом отправителю не нужно знать возможности всех потенциальных получателей и самому заботиться о резервировании для них соответствующих ресурсов.

Для резервирования ресурсов с помощью протокола RSVP получатели посылают запросы на резервирование ресурсов к отправителям с учетом своих возможностей. Например, пользователь высокопроизводительной рабочей станции и пользователь устаревшего компьютера хотели бы получать высококачественный видеопоток с частотой 30 кадров в секунду при скорости передачи данных в 1,5 Мбит/с. Рабочая станция имеет достаточно мощный центральный процессор для декодирования потока видео в полном объеме, но вот устаревший компьютер способен декодировать только 10 кадров в секунду. Если в такой ситуации видеосервер посылает двум своим получателям сообщения о том, что он готов предоставить поток видео со скоростью в 1,5 Мбит/с, то рабочая станция может в ответ выслать просьбу о резервировании пропускной способности в 1,5 Мбит/с. В то же время персональный компьютер не нуждается в такой пропускной способности для своего потока, потому что он не в состоянии декодировать все кадры. Поэтому он может послать просьбу о резервировании ресурсов для потока с частотой 10 кадров в секунду со скоростью в 500 Кбит/с.

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

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

После получения сообщения пути маршрутизаторы готовы к резервированию ресурсов для потока. Состояние всей системы после прохождения сообщения пути следующее: все получатели знают предполагаемые характеристики потока от отправителя, а все маршрутизаторы - предполагаемые требования к качеству для этих потоков.

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

На каждом маршрутизаторе запрос на резервирование ресурсов инициирует два действия.

1. Резервирование параметров QoS на этом пути. Процесс резервирования протокола RSVP передает запрос механизмам контроля доступа (access control) и контроля политики (policy control) на маршрутизаторе. Контроль доступа проверяет наличие у приложения прав на резервирование параметров QoS, а контроль политики - наличие у маршрутизатора необходимых ресурсов для установления нового соединения с заданными параметрами QoS. Если одна из этих проверок дает отрицательный ответ, то резервирование отклоняется, и процесс резервирования протокола RSVP возвращает сообщение RESVErr об ошибке соответствующему получателю. Если обе проверки прошли успешно, то маршрутизатор использует информацию спецификации фильтра в сообщении RESV для задания параметров классификатора пакетов, а информацию спецификации потока - для определения параметров планировщика пакетов. После того как классификатор пакетов выявит наличие в трафике пакетов из данного потока, планировщик пакетов получит желательные параметры QoS, определенные в технических требованиях к потоку. Рисунок 3 показывает процесс резервирования ресурсов протоколом RSVP.
2. Отправление запроса резервирования. После успешного принятия и проверки политики запрос резервирования возвращается обратно к отправителю. При групповой адресации получатель может принимать данные от множества отправителей. Совокупность конечных станций, на которые данный запрос резервирования был разослан, называется областью этого запроса. Запрос, отправляемый следующему узлу после успешного резервирования, может отличаться от запроса, полученного устройством от предыдущего узла. Одна из возможных причин этого может состоять в изменении механизмом управления потоком сообщений технических требований к потоку между транзитными узлами. Другой, более важной, причиной является то, что при групповой адресации сообщения резервирования от различных ветвей рассылки многоадресного трафика для одного и того же отправителя объединяются вместе. Такое объединение необходимо для выделения суммарных ресурсов на этом маршрутизаторе.

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

Такой способ резервирования ресурсов возможен только при условии, если все маршрутизаторы на пути поддерживают протокол RSVP. Если хотя бы один маршрутизатор не поддерживает резервирование ресурсов, то обслуживание с резервированием ресурсов нельзя будет гарантировать на всем пути из-за того, что обычные маршрутизаторы будут осуществлять передачу по мере возможности. При отсутствии поддержки RSVP транзитный маршрутизатор может как выполнить, так и не выполнить требования к качеству обслуживания потока в зависимости от своей загруженности. Послав запрос на резервирование, получатель может также запросить сообщение о подтверждении успешности выполнения запроса. Включив запрос о подтверждении в сообщение RESV, получатель получит сообщение ResvConf, если резервирование было произведено успешно.

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

Путь и состояние резервирования также могут быть удалены при помощи отменяющих (teardown) сообщений RSVP. Отменяющие сообщения бывают двух типов:

• сообщение PathTear. Сообщения PathTear рассылаются вниз по сети из точки инициирования всем получателям, отменяя состояние резервирования на всех устройствах, поддерживающих протокол RSVP;
• сообщение ResvTear. Сообщения ResvTear рассылаются вверх по сети из точки инициирования всем отправителям, отменяя состояние резервирования на всех маршрутизаторах и рабочих станциях.

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

Стили резервирования протоколом RSVP

Групповым приложениям мультимедиа приходится принимать потоки от различных отправителей. В процессе резервирования, описанном ранее, получатель должен инициировать отдельные запросы о резервировании для каждого потока, который он собирается получать. Но протокол RSVP обеспечивает и более гибкий способ резервирования ресурсов для потоков от различных отправителей. Запрос на резервирование включает набор опций для так называемых стилей резервирования (reservation style). Одна из этих опций касается обработки резервирования для различных отправителей в пределах одного сеанса связи. Получатель может задать разные параметры резервирования для каждого отправителя или произвести общее резервирование для пакетов от всех отправителей в рамках одного сеанса связи.

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

1. Фильтр указателей (Wildcard-Filter, WF). Метод фильтра указателей использует опции общего резервирования и выбор отправителя по указателям. Этот стиль устанавливает общее для всех отправителей резервирование в рамках данного сеанса связи. Запросы на резервирование от различных получателей объединяются вместе по пути таким образом, что отправителю передается только запрос на резервирование наибольших ресурсов. Запрос на резервирование по указателям передается вверх по сети всем отправителям. При появлении новых отправителей в рамках текущего сеанса, например при присоединении новых участников к видеоконференции, резервирование расширяется и на этих новых отправителей.
2. Устанавливаемый фильтр (Fixed-Filter, FF). Метод устанавливаемого фильтра использует опции, отличные от резервирования с явным выбором отправителя. Это означает, что резервирование зависит от отправителя. В рамках одного и того же сеанса связи пакеты от различных отправителей обслуживаются раздельно в соответствии с зарезервированными для них ресурсами.
3. Общедоступно-явный (Shared-Explicit, SE). Общедоступно-явный метод использует опции общего резервирования и явного выбора отправителя. Это означает, что общее резервирование охватывает потоки от указанного подмножества отправителей. Поэтому список отправителей должен быть включен в запрос от получателя на резервирование.

Резервирование по методам WF и SE используется главным образом групповыми приложениями. Для этого типа приложений маловероятно, что несколько источников информации будут передавать данные одновременно, поэтому резервировать параметры QoS для каждого отправителя обычно не требуется.

Например, при проведении аудиоконференции каждый из 5 участников порождает потоки данных со скоростью 64 Кбит/с. При использовании резервирования по методу FF все участники конференции должны отправить 4 запроса на резервирование полосы в 64 Кбит/с для потоков от других участников. Но во время аудиоконференции большую часть времени одновременно говорят только один или два человека. Поэтому пропускной способности в 128 Кбит/с было бы достаточно для всех участников. Иначе эффективность использования программного обеспечения аудиоконференции резко понижается, так как значительные ресурсы пришлось бы расходовать на подавление пауз.

Будущее интегрированных услуг

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

Поддержка маршрутизаторами протокола RSVP может отрицательно сказаться на процессе маршрутизации. Чем больше потоков данных проходит через маршрутизатор, тем больше сеансов связи протокола RSVP приходится ему обслуживать. Изготовители маршрутизаторов должны гарантировать, что при интенсивном трафике маршрутизатор не будет блокирован вследствие обслуживания сообщений протокола RSVP. Понятие блокировки можно понимать и в более широком смысле. Резервирование пропускной способности для потоков по протоколу RSVP может привести к ситуации, когда остальным потокам просто не останется пропускной способности.

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

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

Таблица 1. Стили резервирования