Интегральное обслуживание IntServ

ГЛАВА 14. Интегральное и дифференцированное качество обслуживания. Стандарты QoS в IP-сетях

Качество обслуживания

 

Сеть Интернет, кроме передачи данных, все больше и больше используется для поддержки мультимедийного трафика. В первую очередь это относится к сети нового поколения VoIP (речь поверх IP), которая в качество передачи речи и видео очень чувствительно к задержкам. При описании процедур работы сети ATM было показано, что различные виды информации мультимедийной сети требуют поддержки соответствующих механизмов обеспечения качества обслуживания QoS. Традиционные IP-сети не гарантируют никакого показателя QoS. Взять за основу сеть ATM, обеспечивающую передачу с необходимым QoS любого мультимедийного трафика, практически оказалось не реализовано для сетей связи общего пользования. Это относится к каждому из планируемых ранее вариантов: построение сети ATM для трафика реального времени (речь, видео), требующую малую задержку (с сохранением IP-сети для передачи данных); полная замена IP- сети на сеть ATM. Таким образом, возникла необходимость обеспечить поддержку различного мультимедийного трафика с разнообразными требованиями к уровню QoS в рамках архитектуры IP-сети. Механизмы QoS при рассмотрении их для использования в среде IP можно разделить на три категории: один подход оперирует в режиме сквозной передачи из «конца в конец» (еnd - tо - end), другой функционирует на уровне транзитов (hop – by – hop) и третий совершенно игнорирует IP, используя новую технологию многопротокольной коммутации по меткам MPLS (Multiple Protocol Label Switching). Первая категория определяет архитектуру интегрального обслуживания IntServ, а вторая – дифференцированного обслуживания DiffServ (DS) [30].

Интегральное обслуживание IntServ

 

Главный протокол архитектуры интегрального обслуживания, разработанный IETF, называется протоколом резервирования ресурсов RSVP (Resource reservation Protocol). Как следует из названия, протокол предназначен для резервирования ресурсов. RSVP является протоколом сигнализации, который позволяет приложениям информировать сеть о своих требованиях. На основе этих требований сеть может либо резервировать внутри себя ресурсы, чтобы гарантировать выполнение требований, либо отказать приложению. Протокол RSVP позволяет запрашивать, например, гарантированный показатель трафика, задержку, максимальный уровень потерь блоков данных. Рассмотрим процедуру резервирования по протоколу RSVP (рис. 14.1).

 

Рис. 14.1. Резервирование ресурсов с помощью RSVP

R1, R2, R3 – маршрутизаторы.

Как показано на рисунке 14.1, протокол RSVP передает информацию с использованием двух типов сообщений: PATH и RESV. Сообщения PATH передаются от отправителя к одному или нескольким получателям и включают в себя:

· спецификацию потока данных Tspec, которая определяет тип потока данных приложения, входящего в сеть (Т означает трафик);

· шаблон отправителя (IP-адрес, UDP/TCP порт как опция).

Получив сообщение PATH, получатель передает отправителю сообщение RESV, идентифицируя сеанс, для которого производится резервирование, а также спецификацию Rspec (R означает резервирование, Reserve). Rspec включает уровень QoS, требуемый получателем. После того как резервирование выполнено, маршрутизаторы, находящиеся на маршруте, могут идентифицировать пакеты, принадлежащие к определенному блоку зарезервированных ресурсов, путем анализа следующих полей в заголовке протокола IP и в заголовке транспортного протокола: IP-адрес получателя, порт получателя, IP-адрес отправителя и его порт. Пакеты, идентифицированные таким образом, называются зарезервированным потоком. К пакетам в зарезервированном потоке применяются определенные правила для того чтобы не генерировался больший трафик, чем объявлено в спецификации Тspec. Для пакетов потока также устанавливается соответствующий приоритет обработки с целью обеспечения требуемого уровня обслуживания.

При разработке протокола RSVP предусматривалось резервирование ресурсов для индивидуальных микропотоков приложений. Однако такой подход имеет несколько практических недостатков. При его использовании каждый элемент сети на всем пути следования пакета, включая оконечные системы, должен иметь полную информацию протокола RSVP и участвовать в сигнализации, требуемой механизмом QoS. На каждом сетевом элементе, лежащем на маршруте, должна поддерживаться информация каждого резервирования. Такое требование может привести к потенциальному расширению сети до состояния, когда через базовую IP-сеть будут проходить сотни тысяч потоков. При этом требуется предварительная договоренность при установке канала для каждого потока. Это не позволяет расширить систему в достаточной мере. Поэтому в системах с тысячами потоков интегральное обслуживание применить не удастся. В результате выжило очень мало реализаций RSVP в IP-сетях. Однако этот протокол может выполнить резервирование для объединенных потоков данных. Это позволило использовать протокол RSVP в технологии MPLS.