ТЕХНИЧЕСКИЙ ОБЗОР
Сможет ли управление качеством обслуживания справиться с хаосом в пакетных сетях? Вердикт по этому вопросу пока не вынесен, но протокол RSVP (Resource ReSerVation Protocol - протокол резервирования ресурсов) открывает заманчивые перспективы регулирования IP-трафика.
Возможно, на осознание потенциальных возможностей этого протокола потребуются годы, но проведенная в Тестовом центре PC Week Labs экспертиза ясно показала, что заложенная в его основу технология может принести плоды уже сегодня. Для этого потребуется лишь минимальная поддержка со стороны приложений независимых разработчиков и клиентских операционных систем.
Чтобы выяснить, какие уровни приоритета присваиваются различным типам IP-трафика, мы проверили RSVP в операционной среде Internetwork Operating System (IOS) 11.2 фирмы Cisco Systems.
Некоторые функции управления качеством обслуживания были заложены еще в предыдущий вариант этой ОС. Версия 11.0 позволяла устанавливать правила определения очередности различных типов передаваемых сообщений. Объединив эти возможности с новой технологией RSVP, мы смогли выделить заданную долю пропускной способности канала Т-1 для пересылки пакетов с различных хост-компьютеров.
Подобный способ управления пропускной способностью позволяет администраторам лучше распределять ее между приложениями и гарантировать требуемую скорость передачи приоритетных данных даже при общей перегрузке сети.
Действительно, что может быть естественнее, чем предоставить право определения приоритетности трафика самим операторам магистрали? Разве какой-нибудь разработчик согласится признать трафик своего приложения второразрядным?
Конфигурация многих сетей даже предусматривает игнорирование RSVP-меток качества обслуживания, присваиваемых клиентом, и распределение пропускной способности в соответствии с заданными правилами. Так, например, сетевые операторы могут решить, что общий технический трафик не должен занимать больше 50% общей пропускной способности магистрали.
Таким образом, служебная информация RSVP, определяемая на конечной станции, может стать второразрядной, а то и вообще не учитываться. Магистральные же RSVP-функции определения качества обслуживания позволят администраторам лучше распределять ресурсы, выделяя их тем, кому они действительно нужны, или тем, кто платит за них.
Возможность регулировать пропускную способность окажется особенно полезной сервис-провайдерам Internet, которые смогут гарантировать своим клиентам передачу данных с заданной скоростью. Более того, большинству из них, чтобы воспользоваться всеми преимуществами RSVP, даже не придется вкладывать дополнительные средства в модернизацию маршрутизаторов. Избранный Cisco подход позволяет добиться этого простой загрузкой из сети свежей версии системного ПО.
Поступательное развитие
На разработку RSVP, как и многих других спецификаций, понадобилось много времени, и мы столкнулись с дилеммой развития, сильно напоминающей пресловутую “Уловку 22”.
Качество обслуживания невозможно гарантировать, пока все сетевые аппаратные средства, клиентские ОС и приложения конечных пользователей не будут приспособлены для новой технологии. Однако никто не хочет проявлять инициативу и переходить на модернизированные средства, пока этого не сделают все остальные.
Зачем разработчикам ПО создавать сетевые приложения, обеспечивающие заданное качество обслуживания, если те не смогут работать с устаревшими IP-стеками? Зачем производителям операционных систем встраивать модернизированные подсистемы гарантированного качества обслуживания, если нет ПО, способного использовать эти функции? И наконец, зачем создателям аппаратных средств выпускать маршрутизаторы и коммутаторы, поддерживающие качество обслуживания, если нет соответствующего ПО?
Конечно, когда-нибудь все эти вопросы организации инфраструктуры отпадут, потому что почти все производители аппаратных средств и программного обеспечения заявляют о своей приверженности RSVP.
По мере естественного обновления систем будет обеспечена полная поддержка протокола, которая станет стандартной для всех сетей, и на рынке появится множество совместимых с RSVP продуктов.
Как уже указывалось, Cisco начала выпуск RSVP в качестве составной части своей ОС IOS 11.2, а Microsoft включила интерфейсы прикладного программирования с управлением качеством обслуживания (которые, однако, еще не полностью совместимы с протоколом RSVP) в Winsock 2.0, входящий в комплект Windows NT 4.0.
Фирма Sun Microsystems, как ожидается, вскоре представит RSVP-расширение к операционной системе Solaris, а фирма Bay Networks планирует обеспечить поддержку протокола в своей линии маршрутизаторов.
Похоже, что инфраструктура для RSVP будет создана уже в этом году, и остается лишь теряться в догадках, когда же преимуществами новой технологии решатся воспользоваться разработчики приложений. 4
Майкл Суркан
RSVP управляет трафиком сетевых клиентов
Технические ПК
150.40.64.151-
150.40.64.200
Технология RSVP позволяет выделять заданную часть пропускной способности магистрали даже в тех случаях, когда сетевые клиенты не поддерживают протокол RSVP
Концентратор
Бухгалтерские ПК
150.40.64.100-
150.40.64.150
Маршрутизатор с поддержкой RSVP
Канал Т-1 глобальной сети
RSVP выделяет 60% пропускной способности канала Т-1 для трафика технических ПК (150.40.64.151 - 150.40.64.200)
RSVP выделяет 40% пропускной способности канала Т-1 для трафика бухгалтерских ПК (150.40.64.100 - 150.40.64.150)
