Интегрированные услуги ( англ. Integrated services, IntServ ) — в компьютерных сетях архитектура управления ресурсами, обеспечивающая заданное качество обслуживания ( QoS ). Используемый интегрированными услугами метод требует наличия трудно масштабируемой протокольной архитектуры. Проблема масштабируемости связана с принципом работы интегрированных услуг, во время которой выполняется сквозное резервирование ресурсов во всех элементах, составляющих сетевой уровень приложения.

История

Заметный рост сети Интернет привёл к значительному росту трафика. Появление новых типов приложений, таких как веб-приложения, видео в реальном времени, IP-телефония и множества других, заставило специалистов искать новые способы контроля сетевого трафика. Одним из недавно принятых решений стало использование интегрированных услуг, объединяющих в себе все предложенные решения.

Введение

Стандартные протоколы стека TCP/IP обеспечивают обслуживание по мере возможности и выдают одинаковый приоритет всем запросам. При передаче по одной сети трафика потоковых мультимедийных приложений (VoIP, аудио- и видеоконференции и других) или трафика данных с различными требованиями к пропускной способности, необходимо обеспечить возможность обработки и классифицирования различных типов сетевого трафика, либо в зависимости от предъявляемых требований, либо от содержания. Негарантированная доставка не предполагала проведения какой-либо дифференциации трафика и не обеспечивала ни надёжную доставку, ни гарантированную пропускную способность канала, ни малый уровень потери пакетов.

Для решения всех вышеуказанных проблем негарантированной доставки были созданы следующие две модели качества обслуживания :

• Дифференцированные услуги или DiffServ основаны на разбиении трафика по классам, для каждого из которых определяются свои требования по QoS. Данная модель занимает промежуточное положение между негарантированной доставкой и моделью IntServ и сама по себе не предполагает обеспечение гарантий предоставляемых услуг, поэтому дифференцированное обслуживание часто называют мягким QoS.
• Интегрированные услуги или Intserv основаны на предварительном резервировании сетевых ресурсов и обеспечивают сквозное (на всём пути следования трафика) качество обслуживания, гарантируя необходимую пропускную способность. Эту модель также часто называют жёстким QoS в связи с предъявлением строгих требований к ресурсам сети.

Функции

Прежде чем раскрывать данную тему, стоит дать определение понятию потока . Будем понимать под «потоком» непрерывный трафик, генерируемый пользователем или приложением и требующим одинакового качества обслуживания. В версии IPv4 поток определяется на транспортном уровне используемого протокола (либо TCP , либо UDP ) через порты и IP-адреса отправителя и назначения. В версии IPv6 также имеется специально созданное для этой функции поле, которое наряду с адресами его источника и назначения характеризует поток. Это поле называется меткой потока.

В рамках модели интегрированных услуг можно выделить следующие важные подсистемы :

1. Контроль доступа
2. Классификатор пакетов
3. Планировщик пакетов
4. Активное управление очередью

Контроль доступа

Как было сказано ранее, перед отправкой информации через сеть, резервируются ресурсы в соответствии с требуемым качеством обслуживания. При обслуживании нового потока производятся заявление требований качества обслуживания (путём спецификацией сервисного запроса — RSPEC ) и получение характеристик трафика, который должен быть отправлен через сеть (путём спецификацией трафика — TSPEC ). Если для обслуживания нового потока у маршрутизатора не хватает свободных ресурсов, такой поток будет отклонён. Если же требования нового потока могут быть удовлетворены, то маршрутизатор поручает планировщику и классификатору пакетов зарезервировать часть своих ресурсов под обеспечение необходимого для данного потока качества обслуживания.

В RSPEC можно выделить следующие категории обслуживания потока:

• Гарантированное обслуживание. Гарантированы согласованная скорость передачи и отсутствие потерь. Данная услуга отлично подходит приложениям реального времени.
• Контролируемое обслуживание. Согласованная скорость передачи сохраняется при отсутствии перегрузок сети, а уровень потерь остаётся достаточно низким. Может быть адаптировано под приложения реального времени, но лучше всего подходит для просмотра веб-страниц, FTP и подобных приложений.
• Услуги «best-effort». Обслуживание по умолчанию, не предоставляющее никаких гарантий.

RSPEC и TSPEC предоставляются протоколом резервирования сетевых ресурсов RSVP .

Классификатор пакетов

Классификатор пакетов идентифицирует пакеты потока на маршрутизаторах. Каждый входящий пакет относится им к определённому классу. Будучи разделены по классам, пакеты получают одинаковую для своего класса обработку от планировщика пакетов. Выбор конкретного класса зависит от приоритетов отправителя и получателя, IP-адреса и номера порта в заголовке пакета. Как правило, однотипные потоки принадлежат одному классу.

Планировщик пакетов

Планировщик пакетов с помощью системы управления очередями регулирует отправку пакетов на маршрутизаторы в соответствии с проведённой классификацией, упомянутой выше, и заданными для каждого потока параметрами качества обслуживания. Планировщик пакетов должен функционировать в точке, где пакеты ставятся в очередь. Этой точкой обычно являются протоколы канального уровня в операционной системе маршрутизатора.

Активное управление очередью

Во избежание перебоев в сети, предусматривается контроль перегрузки. Существуют три метода реализации контроля перегрузки путём исключения пакетов:

• Tail drop : Исключаются недавно добавленные пакеты.
• QoS: Исключаются пакеты с наихудшим качеством обслуживания.
• RED ( Random early detection ): Вероятность исключения пакета зависит от степени перегрузки буфера. При превышении заполненности очереди, вероятность отбрасывания пакета повышается. Данный способ является наиболее распространённым.

RSVP

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

В рамках протокола RSVP используется понятие « путь » ( англ. PATH ). Путь — это маршрут прохождения пакетов через различные маршрутизаторы от отправителя к получателю. Резервирование ресурсов производится вдоль этого маршрута. Все пакеты одного потока будут следовать по одному пути. Путь определяется в процессе передачи отправителем сообщения протокола RSVP — так называемого сообщения пути. Оно содержит информацию о качестве обслуживания трафика для данного потока. Так как протокол RSVP не является протоколом маршрутизации, он использует информацию из таблиц маршрутизации на каждом маршрутизаторе в целях скорейшей доставки сообщения пути .

Формат сообщения PATH следующий (данные в квадратных скобках необязательны):

Common Header, [Integrity], Session, RSVP_Hop, Time Values,  [Policy_Data], Sender Template, Sender_Tspec, [ADSPEC]

После получения сообщения пути маршрутизаторы готовы к резервированию ресурсов для потока. Для резервирования определённых параметров QoS получатель посылает сообщение RESV . Каждое устройство, поддерживающее протокол RSVP, уже знает адрес предыдущего устройства в пути следования, поэтому сообщение RESV проходит в обратном направлении к отправителю и сообщает транзитным маршрутизаторам требуемые параметры для резервирования ресурсов.

Формат сообщения RESV следующий:

Common Header, [Integrity], Session, RSVP_Hop, Time Values, [Reso_Confirm], [Scope], Style, Flow Descriptor List

Некоторые уточнения:

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

Стоит отметить, что такой способ резервирования ресурсов возможен только, если все маргрутизаторы на пути следования поддерживают протокол RSVP. При отсутствии поддержки RSVP промежуточный маршрутизатор может как выполнить, так и не выполнить требования к качеству обслуживания в зависимости от своей загруженности. Полная спецификация протокола RSVP определена в документе RFC-2205.

Основная проблема

Хотя в середине 90-х годов прошлого века идея IntServ и RSVP вызывала большие надежды, со временем интерес к этой архитектуре угас. Главной причиной стала проблема масштабируемости, вызванная необходимостью хранить и поддерживать информацию о состоянии передачи в каждом маршрутизаторе. Эта проблема, переносимая на такие глобальные сети, как Интернет, отдаляет RSVP от реальности. Тем не менее в последнее время вновь появились разговоры о применении RSVP в MPLS или в транспортной инженерии, так как в этих случаях значение трафика невелико, что делает его более управляемым и снижает стоимость оборудования.

Примечания

Литература

• «Mundo IP» José Antonio Mañas, (Nowtilus 2004, ISBN 84-9763-026-2 )
• «TCP/IP Tutorial and Technical Overview» Lydia Parciale, David T. Britt, (Redbooks 2006)

Ссылки

• Интегрированные услуги в сети Интернет. (англ.)
• Протокол резервирования ресурсов ( RSVP ). (англ.)
• Спецификации гарантированного качества обслуживания. (англ.)
• .