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

В основу протокола резервирования ресурсов RSVP (Resource Reservation Protocol) заложены три понятия: сеанс, спецификация потока и спецификация фильтра. Сеанс — это период обработки потока данных. Сеанс начинается с выделения ресурсов, необходимых для пропуска потока, и заканчивается после прохождения потока. Запрос на резервирование ресурсов от получателя на­зывается описанием протокола и состоит из спецификации потока и фильтра. Спецификацию потока определяют параметры услуг, которые необходимо заре­зервировать, чтобы поток мог пройти через данный узел без потери качества. Спецификация фильтра определяет набор пакетов, под которые запрашивают­ся ресурсы. Любые другие пакеты обрабатываются по остаточному принципу с предоставлением минимальных услуг, которые сеть может обеспечить в это время. Спецификация фильтра описывает произвольное подмножество пакетов одного сеанса. Фильтр может быть настроен на различные параметры: конкрет­ных отправителей, конкретные протоколы, поля заголовков и т. д.

Основная сложность протокола RSVP связана с групповой рассылкой. Это связано с тем, что запросы на выделение ресурсов распространяются в обратном направлении по дереву маршрутизации. Протокол RSVP использует два основ­ных типа сообщений: RESV и PATH.

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

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

Можно упрощенно описать данный алгоритм на следующем примере. Пред­положим, что отправитель, зная всех получателей, хочет показать им видеоклип. Так как адреса известны, он посылает им сообщение PATH. Это сообщение несет информацию о том, что отправитель собирается показать видеоклип чле­нам своей группы. По пути следования к адресатам, сообщение выставляет на маршрутизаторах необходимые для передачи потока параметры. Если какой-либо маршрутизатор не может обеспечить данные параметры, он отвергает сооб­щение. Это означает, что получатель на таком маршруте не сможет посмотреть видеоклип. После достижения сообщением PATH всех получателей, они анали­зируют полученную с этим сообщением информацию и отвечают сообщением RESV. Сообщение RESV проходит по маршруту сообщения PATH, но в обрат­ном направлении. Получатели закладывают в сообщения RESV информацию о том, хотят ли они посмотреть клип. Они могут попросить показать другой клип. Некоторые попросят «загрубить картинку», так как имеют плохие каналы связи и т. д. После того как отправитель получил все сообщения RESV, он начинает сеанс с учетом пожеланий каждого получателя.

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

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

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

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

Несмотря на эти недостатки и тот факт, что протокол RSVP все еще нахо­дится в стадии рассмотрения в группе IETF и не проверен в больших распре­деленных сетях, все ведущие производители сетевого оборудования (Cisco Systems, 3Com, Bay Networks и т. д.) вводят его поддержку в свои маршрутиза­торы.