Использование протокола резервирования ресурсов (Resource Reservation Protocol - RSVP) по утверждению его сторонников, позволит обеспечить в корпоративных интрасетях работу наиболее ответственных приложений, для которых любые задержки недопустимы, реализовать в Internet передачу голоса и видео, а также объединить ATM с IP, что, возможно, даже не потребует применения сквозного (end-to-end) ATM.
Протокол RSVP действительно позволяет приложениям запрашивать необходимый уровень качества услуг (Quality of Service - QoS), но дело в том, что производители маршрутизаторов до сих пор не пришли к единому мнению по поводу наилучшего способа выполнения запросов. Но даже если эта проблема будет решена, остается нерешенной задача предотвращения заполнения всей, без остатка, полосы пропускания запросами RSVP.
Кроме того, пользователям, скорее всего, придется платить провайдеру за возможность использования RSVP в Internet. Внедрение же RSVP в корпоративных сетях приведет к тому, что некоторые приложения придется оставить на "голодном пайке", чтобы другие могли получать требуемую полосу пропускания, когда им это необходимо. Если вас это не устраивает, то придется расширить полосу пропускания для удовлетворения всех запросов.
Проблема отсутствия соединения
RSVP может работать с самыми разными стеками протоколов, но в первую очередь он предназначен для сетей TCP/IP, в которых данные передаются без установления соединений в виде дейтаграмм. RSVP - смелая попытка решить основную проблему таких сетей. Дело в том, что дейтаграммы, или пакеты данных, не имеют фиксированного пути по сети. Дейтаграмма, отправленная в сеть с какого-либо узла, конкурирует с дейтаграммами от других узлов, "борясь" за полосу пропускания. В результате нельзя гарантировать не только нужной скорости передачи данных между двумя узлами, но и того, что дейтаграммы прибудут к месту назначения.
Для решения этой проблемы Институт информатики при Калифорнийском университете, Массачусетский технологический институт и Пало-Альтский исследовательский центр компании Xerox разработали совместными усилиями проект протокола RSVP. Их целью было обеспечить QoS для избранных потоков данных, при передаче которых недопустимы задержки или необходима определенная полоса пропускания. Разработчики исходили из предположения, что в подавляющем большинстве случаев обмена данными при помощи TCP/IP высокий уровень качества услуг не требуется. Поэтому в протоколе RSVP определено специальное QoS-управляемое информационное взаимодействие, называемое сеансом.
RSVP предназначен в первую очередь для многоадресных рассылок, при которых данные с одного узла рассылаются по множеству других, но он способен поддерживать и одноадресную передачу данных между двумя узлами. Процесс передачи начинается, когда источник данных, например серверное приложение, посылает команду PATH потенциальным получателям. Команда включает в себя идентификатор потока (он может содержать адрес источника и другие поля из заголовка TCP/IP), который позволяет маршрутизатору установить принадлежность дейтаграмм к определенному сеансу RSVP. Команда PATH также позволяет описать ожидаемый информационный поток, например указать его объем. В сущности, источник данных сообщает, что "Чарли собирается послать видеоинформацию. Эту передачу можно идентифицировать такими-то битами в потоке данных, и она имеет такие-то характеристики потока".
Каждый маршрутизатор, обрабатывающий команду PATH, "запоминает" идентификатор потока и канал, по которому пришел этот поток. Это позволяет составить таблицу путей потоков данных и обеспечить готовность всех маршрутизаторов к выделению ресурсов.
Если потенциальный адресат, принявший команду PATH, хочет получить указанные данные, то он посылает команду RESV. Используя тот же самый идентификатор потока, команда RESV следует по пути команды PATH в обратном направлении. При этом она "сообщает" встречающимся на ее пути маршрутизаторам, какой уровень QoS необходимо обеспечить. Маршрутизатор, получивший команды RESV от нескольких получателей, объединяет их в одну команду. Если маршрутизатор способен обеспечить запрашиваемый уровень QoS, он заносит заказ в так называемую таблицу потоков, в противном случае - отказывает в резервировании ресурсов. То, каким образом маршрутизаторы принимают подобные решения, определяют их производители.
Маршрутизаторы используют таблицы потоков, чтобы установить принадлежность поступающих дейтаграмм к тому или иному сеансу RSVP. Этот процесс отнимает заметную часть вычислительных мощностей маршрутизатора. Если каждый пользователь начнет открывать сеансы RSVP, то в конце концов таблицы потоков станут настолько большими, что по сравнению с ними даже таблицы маршрутизации будут гораздо более эффективными, а сама сеть начнет давать сбои.
В рамках проекта RSVP разработан первоначальный вариант процедуры одобрения запросов на QoS, однако работа над ним еще не завершена, поэтому производители разрабатывают собственные подходы к решению этого вопроса. Не вызывает сомнения необходимость контроля (как со стороны пользователей, так и со стороны операторов сети) за числом тех, кто имеет доступ к RSVP, и за соблюдением запрашиваемых приоритетов, поскольку при отсутствии такого контроля сетевых ресурсов никогда не будет достаточно для выполнения всех требований.
RSVP предусматривает регулярный обмен командами PATH/RESV для обнаружения вышедшего из строя узла или канала; если таковой обнаруживается, то сеанс открывается заново. Обмен этими командами служит также подтверждением того, что сеанс не закрыт, а значит, таблица потоков должна поддерживаться, а ресурсы по-прежнему резервироваться.
Протокол RSVP лучше всего работает при разумном числе одновременно поступающих заказов. Таким образом, основная проблема заключается в том, чтобы ограничить число одновременных соединений. Здесь уместна следующая аналогия. Спросите любого человека, который когда-либо ужинал в хорошем нью-йоркском ресторане, насколько просто заказать для этого столик. Он ответит, что это возможно, но далеко не всегда. Так же обстоит дело и с RSVP.
Как выполнить заказ?
Процесс обмена командами PATH/RESV, центральный для RSVP, не позволяет определить, каким образом выполняется заказ. Предварительная спецификация RSVP доверяет выполнение запросов на QoS планировщику пакетов на маршрутизаторе, который определяет порядок пересылки данных с входного на выходной порт маршрутизатора. То, каким образом планировщик будет это делать, предоставлено решать производителю маршрутизатора. Однако можно выделить три основных подхода: создание очереди, сокращение объема вычислений для каждой дейтаграммы в одном сеансе RSVP, управление параметрами коммутируемого виртуального соединения.
Наиболее очевидная стратегия - создание очередей. Этот подход позволяет предоставлять дейтаграммам, относящимся к какому-либо сеансу RSVP, приоритет перед другими дейтаграммами в соответствии с определенной схемой распределения запросов на QoS для каждого сеанса.
Ограничения RSVP
Вне зависимости от используемого подхода к реализации RSVP две проблемы остаются нерешенными.
Во-первых, протокол RSVP позволяет лишь перераспределять сетевые ресурсы. Это, а также существование ограничений на число одновременных сеансов, которые маршрутизаторы способны эффективно обслуживать, обуславливает большую пригодность RSVP для тех случаев, когда число приоритетных потоков невелико и они требуют умеренной полосы пропускания.
Во-вторых, предварительный вариант протокола RSVP не определяет, как в процессе передачи команд PATH/RESV будут кодироваться различные значения QoS и какие параметры (например, максимальная/средняя ширина полосы пропускания, допустимое время задержки и скорость отбраковки дейтаграмм) будут объектами управления RSVP. Это означает, что процесс резервирования должен будет соотноситься со способами интерпретации запросов конкретными моделями маршрутизаторов и коммутаторов. Как показывают три рассмотренных подхода, проект протокола предоставляет свободу выбора способа выполнения запросов на резервирование, а любая свобода, когда речь идет о стандартах, на практике означает отсутствие совместимости.
Если даже оставить в стороне проблемы реализации, то нужно сказать, что недостатки RSVP ими не исчерпываются. Сегодня не существует приложений, которые могут использовать возможности RSVP, а заставить работать с этим протоколом имеющиеся приложения - задача нетривиальная.
Чтобы понять, какие приложения нужны для работы с RSVP, рассмотрим процесс резервирования ресурсов. Как осуществляется запрос на резервирование? Очевидно, процесс инициируется тем приложением, которое посылает команду PATH. Существуют ли такие приложения? Проект описывает базовый интерфейс RSVP API, но использующих его приложений еще никто не разработал. Кроме того, вряд ли такие приложения скоро появятся, поскольку функции RSVP еще не встроены в операционные системы.
Другой способ "научить" приложения работать с RSVP - написать их при помощи такого API, как WinSock 2, который должен получить повсеместное распространение к 1998 г. Реализация этого подхода станет вполне возможной после распространения Windows NT 4.0 и будущей версии Windows 95 с WinSock 2. Однако он хорош только для вновь разрабатываемых или специально переписанных для WinSock 2 приложений.
Еще один подход - использование программы вызова RSVP, выполняющейся независимо от конкретного приложения. Эта программа предназначена только для формирования запроса на резервирование ресурсов и поддержания процесса резервирования в перманентном состоянии. Поскольку работа приложения, отправляющего и принимающего данные, не связана напрямую с применением RSVP, этот подход вполне пригоден для существующих приложений. Подобная программа может быть использована и как планировщик конференций. Ряд производителей разрабатывает такие программы, но еще ни одна из них не была обнародована.
В таких новых областях, как передача голоса и видеоинформации с помощью Internet, отсутствие поддержки протокола RSVP используемыми приложениями легко преодолимо. Приложение может посылать команды PATH и RESV как дейтаграммы IP. Некоторые поставщики разрабатывают продукты, при помощи которых местные компании, обеспечивающие кабельные каналы, или провайдеры доступа смогут использовать Internet для предоставления услуг по передаче голоса. Передача голоса с помощью протокола IP уже поддерживается в некоторых частных сетях, а компании Micom Communications и Northern Telecom пообещали скоро разработать продукт, который позволит передавать голос по IP с использованием RSVP.
Означает ли это, что проблема с приложениями решена? Вряд ли. Существует еще одна, более коварная, проблема, связанная с использованием RSVP. Помните замечание о том, что удовлетворение потребностей одного приложения может привести к тому, что другое будет оставлено без ресурсов? Когда операторы Internet начнут применять RSVP для выделения полосы пропускания при передаче мультимедийной информации, заказчикам придется платить за эти зарезирвированные ресурсы.
Если бы ценовая политика операторов Internet не претерпела изменений, то пользователи заполонили бы мультимедийным трафиком все имеющиеся каналы связи, а без получения дополнительной прибыли операторы Internet не могли бы позволить себе создание дополнительных каналов. Поэтому после установки RSVP в сетях операторов Internet они наверняка станут взимать дополнительную плату за каждый сеанс RSVP. Операторы Internet требуют, чтобы реализация RSVP предусматривала средства регистрации пользователей для последующего выставления счетов.
То же самое справедливо для корпоративных сетей. Использовать наиболее ответственные приложения или передачу голоса в корпоративных интрасетях с RSVP можно лишь постольку, поскольку вы готовы платить за дополнительные ресурсы или оставить другие приложения "на голодном пайке". Представление, что можно бесплатно передавать голос по сетям, является глубоким заблуждением. Действительно, если бы ширина полосы пропускания была достаточной для удовлетворения нужд всех пользователей, то отпала бы необходимость в резервировании и приоритезации. Кроме того, решается скорее вопрос ценовой политики, чем расширения полосы пропускания. Использование RSVP заставит тех, кто нуждается в высоком качестве услуг, платить больше (протокол IP никогда не предоставлял такой возможности).
Некоторые производители рассматривают протокол RSVP в более узком смысле. Новый подход компании Ipsilon Networks к управлению качеством услуг предусматривает анализ заголовка дейтаграмм для приоритезации трафика в соответствии с определенным пользователем набором правил. При этом возникает следующая проблема: этот заголовок вовсе не обязательно будет включать в себя информацию о реальной важности приложения.
Подведем итоги. Сама по себе концепция RSVP, очевидно, ценна, но то, как этот протокол продвигается на рынке, может создать неверное впечатление о его возможностях. Если вы заинтересованы в RSVP и управлении QoS и можете решить свои проблемы за счет перераспределения, а не добавления ресурсов, то RSVP - для вас. Если же вы надеетесь, что этот протокол решит проблему перегрузок, то вас ожидает разочарование. RSVP может с равной вероятностью как дополнить протокол ATM, так и заменить его. Он позволит вам передавать столько мультимедиа, за сколько вы готовы платить. На данный момент протокол RSVP еще не стандартизован, поэтому нельзя опробовать его "в деле", если только вы не работаете в организации с огромными техническими возможностями. Влияние RSVP на Internet будет выражаться в появлении разных уровней услуг и соответствующих ценовых структур. В конце концов, это мир капитала. Вы получаете только то, за что платите.
Томас Нолл - президент компании CIMI, занимающейся оценкой технологий. С ним можно связаться через Internet по адресу tnolle@cimicorp.com.
Согласно принятому в маршрутизаторах компании Cisco алгоритму "взвешенной" очереди (weighted fair-queuing algorithm) потоки с пометкой RSVP получают доступ к ресурсам канала в соответствии с запрошенным качеством услуг. Этот алгоритм также гарантирует, что всем другим потокам будут предоставлены хотя бы минимальные ресурсы. "Взвешенная" очередь - не худшая стратегия для распределения сетевых ресурсов маршрутизатора, но она несовершенна. Всегда остается вероятность того, что из-за предоставления минимального объема ресурсов другим потокам будет отклонен какой-либо запрос RSVP. По правде говоря, алгоритм "взвешенной" очереди вряд ли способен обеспечить требуемое качество услуг в большой сети со множеством сеансов RSVP. Это особенно справедливо при большом количестве промежуточных маршрутизаторов, каждый из которых реализует собственную политику обслуживания очередей. Более того, ближайшие к источнику данных маршрутизаторы не всегда "знают", каковы условия в остальной части сети, поэтому маршрутизаторам трудно выделить дополнительные ресурсы для больших потоков при их прохождении через загруженные участки сети вблизи получателя.
Такая стратегия, как сокращение объема вычислений для каждой дейтаграммы, также помогает улучшить процесс резервирования. Это можно сделать двумя способами: ускорив сам процесс маршрутизации или сократив число маршрутизаторов, обрабатывающих потоки на уровне протокола IP, посредством создания сетки виртуальных каналов.
Этой стратегии придерживается компания Cisco, используя в своих маршрутизаторах технологию коммутации пакетов с тэгами (tag switching). Это позволяет сократить время обработки пакета маршрутизатором, уменьшая, таким образом, время задержки. Действия маршрутизаторов, использующих коммутацию пакетов с тэгами, во многом аналогичны действиям коммутаторов пакетов. Они присваивают определенный индекс (тэг) каждому маршруту и предлагают соседним маршрутизаторам использовать этот тэг для идентификации пакетов, следующих по заданному маршруту. Это исключает необходимость просмотра таблицы маршрутизации.
Создавая сетку виртуальных каналов, определяют, каким виртуальным путям соответствуют различные уровни QoS, а затем направляют сеансы RSVP по соответствующим путям. Это позволяет распределить ресурсы каналов в соответствии с требуемым качеством услуг. Кроме того, при таком подходе только два маршрутизатора - первый и последний - обрабатывают поток данных, а промежуточные маршрутизаторы просто следуют указаниям, по какому виртуальному пути следует направить сеанс. Понятно, что это сокращает время обработки пакета на каждом узле. Этот метод также позволяет использовать RSVP в паре с протоколами frame relay или ATM, в которых широко применяются виртуальные каналы.
Построение сетки виртуальных каналов для маршрутизаторов является ключевой составляющей архитектуры NetFlow компании Cisco и неотъемлемой частью стратегии реализации RSVP других производителей маршрутизаторов. Многие считают, что "RSVP отрицает ATM". На самом же деле ATM может стать основным компонентом в широкомасштабной практической реализации RSVP, так как используемая в ATM технология виртуальных каналов очень хорошо "вписывается" в данный подход.
Некоторые производители коммутаторов применяют еще один подход, при котором сеанс RSVP используется для управления параметрами QoS коммутируемых виртуальных соединений ATM или frame relay. В этом случае RSVP дополняет базовые возможности смешанных архитектур локальных сетей и ATM, таких как эмуляция локальной сети или Multi-Protocol поверх ATM. Производители коммутаторов заявляют, что поскольку современные архитектуры типа LAN-to-ATM не имеют встроенной поддержки качества услуг, то именно RSVP будет способствовать успеху технологии ATM.