Протокол резервирования ресурсов (RSVP) недавно преодолел очередное препятствие на пути превращения в стандарт IETF (Internet Engineering Task Force - целевая группа инженерной поддержки Internet), но самые большие трудности еще впереди.
Рабочая группа RSVP на декабрьской сессии IETF в Сан-Хосе (шт. Калифорния) передала в отдел управления IETF спецификацию протокола резервирования полосы пропускания в Internet. Этот отдел, как ожидается, придаст предложенной спецификации статус стандарта, но и после этого перед сетевыми администраторами останутся не менее сложные проблемы определения правил использования ресурсов и механизмов выполнения этих правил.
Хотя RSVP обеспечивает механизм резервирования заданной части канала для таких чувствительных к временным задержкам приложений, как передача голоса и видео по Internet, этот протокол не предоставляет средств контроля за теми, кто распределяет столь ценную пропускную способность.
“RSVP не создает пропускную способность из воздуха. Что, если вся ваша сеть поддерживает RSVP и все пользователи, имеющие на своем ПК стек RSVP, запрашивают себе львиную долю канала?” - задается вопросом Билл Каррико, президент фирмы Precept Software (Пало-Альто, шт. Калифорния), использующей RSVP в выпускаемых ею видеоприложениях.
Технология резервирования полосы пропускания сама по себе также не свободна от недостатков. “RSVP предоставляет зарезервированную часть канала в первую очередь тому, кто установил этот протокол в сети. Но некоторым приложениям равноправие необходимо больше, чем другим. Сейчас это не обеспечивается. Нам совершенно необходимы правила”, - сказал Фрэд Бейкер, член Совета директоров IETF и старший инженер по программированию фирмы Cisco Systems (Сан-Хосе).
Чтобы решить проблему, IETF работает над созданием набора базовых правил.
На этом уровне, по словам Бейкера, простые правила будут звучать так: “Этот поток более важен, чем тот; этот поток может существовать только в определенные периоды времени” и т. д. В наиболее сложных случаях правила могут быть такими: “Предоставить этот поток некоторому третьему лицу”.
Первые документы, как ожидается, будут закончены в ближайшие несколько месяцев. Их появление позволит приступить к реализации правил.
Разработкой более сложных правил будет заниматься целевая исследовательская группа, созданная, как сказал Бейкер, специально для анализа картины в целом. В задачи группы входит определение того, какие типы механизмов позволят реализовать правила, необходимые Internet-провайдерам, телекоммуникационным операторам и
пользователям частных сетей предприятий. Собственно правила она определять не будет.
Эрик Кроули, менеджер по ПО в фирме Bay Networks (Биллерика, шт. Массачусетс) считает, что помимо выработки основных механизмов IETF “позволит рынку и экономистам выяснить правильный способ использования RSVP”. Кроули является также председателем рабочей группы IETF по вопросам системных служб.
Директор по технологиям фирмы UUNet Technologies Рик Адамс полагает, что перед вновь созданными группами IETF поставлены неразрешимые задачи. “Нельзя вводить контроль за использованием RSVP, это волюнтаризм, - сказал он. - Не существует экономических стимулов для подчинения использования Internet неким правилам. Именно из-за этого RSVP потерпит неудачу при решении тех проблем, с которыми, как думают люди, он в состоянии справиться”.
И все же лучше, по-видимому, иметь RSVP, чем вообще ничего. Поскольку пользователи требуют видео- и аудиоуслуг по Internet, сетевые администраторы очень скоро почувствуют насущную потребность в соответствующих инструментальных средствах.
“Надо же с чего-то начинать, - сказал Кроули. - RSVP, может быть, несовершенен, но существует ощутимый спрос на надежные приложения, работающие в реальном масштабе времени, поэтому что-нибудь подобное RSVP необходимо”.
Паула Мусич
