Рассмотренный протокол RSVP и архитектура IntServ могут поддерживаться не во всех без исключения подсетях, входящих в состав глобальной сети Интернет. В этом случае, для того, чтобы существовала возможность функционирования RSVP через те участки, где данная функция не предусмотрена, применяется туннелирование, т.е. сообщения PATH и RESV инкапсулируются в IP-пакеты и маршрутизируются (не обязательно за один шаг) на узел, поддерживающий протокол RSVP.

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

Кроме того, отметим, что при использовании IntServ, и узлы, и приложения должны поддерживать протокол RSVP. На данный момент применение протокола RSVP в коммерческих продуктах достаточно ограничено, однако в большинстве операционных систем (в том числе Linux, Mac OS, Windows 2000) он реализован.

Отметим, что протокол RSVP является ориентированным на приемник, т.е., как было показано выше, именно приемник инициализирует резервирование ресурсов посредством сообщения RESV. Данный факт можно отнести к недостаткам протокола, т.к. зачастую источник является объектом, ответственным за обеспечение качества обслуживания Xiao99.

Как показала практика, IntServ/RSVP лучше применять для поддержки долговременных соединений [HarjuOO], в то время как для вэб-серфинга эта комбинация вряд ли найдет применение. Скорее всего, использование IntServ/RSVP может быть подходящим решением для случаев, когда количество потоков ограничено и канал постоянно перегружен.

Кроме использования совместно с IntServ, протокол RSVP также может быть задействован как в MPLS для установления «маршрутов скоммутированных по метке» (LSP - см. п. 4.7 данной главы) fRFC3209J, так и в DiffServ для конфигурирования параметров в оконечных узлах [RFC2996J.

⇐Временное состояние «soft state» | Управление трафиком и качество обслужевания в сети | Особенности реализации qos для архитектуры intserv⇒