CC BY
191
Сравнительный анализ архитектур для обеспечения качества услуг связи в сетях следующего поколения
Шалагинов ВА, ЦНИИС
Постановка проблемы
Вопросы обеспечения качества услуг связи являются актуальными, и в настоящее время этим вопросом занимается порядка 12 крупных международных организаций [1 ], включая: МСЭ-Т, ETSI, 3GPF, DSL Forum, CableLab и др. Решить проблему обеспечения качества в сетях следующего поколения можно, применяя решения по управлению качеством обслуживания. Такие системы представляют собой специализированные программно-аппаратные комплексы для управления доступом и с гарантированным предоставлением сетевых ресурсов.
Выделим основные проблемы, связанные с обеспечением качества услуг связи, с которыми сталкиваются операторы в сетях следующего поколения.
1. Совместное использование ресурсов сетей, использующих принципы коммутации каналов (КК) и коммутации пакетов (КП) КК и КП, а также ресурсов сетей фиксированной и мобильной связи за один сеанс связи при предоставлении новых услуг. Например, при передаче речи по протоколу IP через сеть Интернет (услуга Skype), пользователь Интернет может инициировать речевой вызов с ПК на телефонный аппарат абонента, находящегося в сети оператора фиксированной или мобильной связи. Однако в условиях отсутствия гарантий по обеспечению качества услуг в пакетных сетях связи, услуги по передаче голосовой и видеоинформации могут быть предоставлены с плохим качеством и без дополнительной оплаты [2], которая могла быть провайдером услуг Интернет.
2. Снижение общего коэффициента надежности сети при предоставлении инфокоммуникационных услуг из-за использования большого количества разнотипных программных и аппаратных средств (маршрутизаторы, шлюзы, контролеры шлюзов, серверы и т.д.) разных производителей. Пример схемы сети при предоставлении инфокоммуникационных услуг показан в [3].
3. Рост полосы пропускания, доступной каждому абоненту, происходит по закону Нильсена (Jakob Nielsen), согласно которому средняя полоса пропускания, доступная абоненту при развитии технологий доступа, увеличивается на 50 % ежегодно [4]. Такой рост приводит к увеличению потребляемого трафика и, как следствие, неспособности транспортной сети обеспечить требуемое качество услуг связи без использования механизмов управления ресурсами транспортной сети.
Избавиться от этих недостатков и обеспечить гарантированное качество обслуживания позволит внедрение системы управления сетевыми ресурсами, которая будет способна гарантировать заданное качество обслуживание для услуг в сетях, построенных на разнотипном оборудовании, использующих разные технологии и принципы передачи информации.
Недостатки и ограничения существующих методов управления качеством обслуживания
В следующем разделе кратко описаны существующие модели, методы и технологии, применяемые для управления сетевыми ресурсами и обеспечения качества обслуживания. Данные технологии подробно описаны во множестве публикаций, например, [5], поэтому отметим только их основные недостатки.
Best Effort Service.
Данный метод используется в настоящее время в сети Интернет и в других сетях с коммутацией пакетов. Методу Best Effort присущи такие качества, как негарантированная доставка данных и отсутствие механизмов обеспечения качества обслуживания. Для доставки данных используются все доступные ресурсы сети без какого-либо выделения отдельных классов трафика и регулирования. При использовании данного метода лучшим механизмом обеспечения качества обслуживания является увеличение пропускной способности и обеспечение достаточной избыточности. Однако модель Best Effort, даже при наличии больших резервов, допускает возникновение перегрузок в случае резких всплесков трафика.
Differentiated Services (DiffServ)
Differentiated Services (DiffServ) [6,7] — это архитектура, предназначенная для организации дифференцированного обслуживания нескольких агрегированных информационных потоков — макропотоков. Разный уровень обслуживания может задаваться как с использованием количественных параметров (например, пропускная способность, величина задержки и уровень потери пакетов), так и с помощью относительных приоритетов одних протоколов по отношению над другими.
DiffServ имеет следующие недостатки:
• регулирование качества обслуживания только для макропотоков;
• относительно небольшое число классов обслуживания;
• отсутствие гарантированного выполнения установленных требований для макропотоков.
При использовании DiffServ, вместо резервирования сетевых ресурсов для каждого потока, фактически предпринимается попытка обеспечить относительное упорядочивание агрегированных потоков. В результате одни агрегированные потоки получают преимущество над другими, в зависимости от правил обслуживания, определенных для каждого агрегированного потока. Качество обслуживания по-прежнему не гарантируется.
Integrated Services (IntSev)
Архитектура Integrated Services (IntServ) [8] и реализующая эту архитектуру интегрированная служба включает в себя ряд механизмов, которые обеспечивают требуемый уровень качества обслуживания при передаче пакетов "из конца в конец" в режимах одноадресной и многоадресной передачи информации. Для обеспечения
гарантированных параметров передачи пакетов в IntServ используется механизм предварительного резервирования ресурсов в маршрутизаторах. Такой подход требует хранения в маршрутизаторах информации об активных потоках.
К недостаткам данной архитектуры относят:
• избыточное резервирование емкости каналов для некоторых потоков, что отрицательно сказывается на качестве обслуживания остальных потоков даже в периоды, когда зарезервированная емкость временно не используется;
• отсутствие средств обеспечения качества обслуживания для макропотоков, что существенно ограничивает область применения IntServ;
• рост нагрузки на маршрутизаторы для работы службы IntServ (особенно в высокоскоростных магистральных сетях);
• необходимость значительных изменений в ПО маршрутизаторов для распознавания сетевых приложений.
Технология MPLS
Технология MPLS [9] не является технологией, непосредственно предназначенной для решения задачи управления качеством обслуживания, однако ее основной задачей является убыстрение продвижения пакетов по сети с пакетной передачей данных. Поэтому для управления сетевыми ресурсами и обеспечения качества обслуживания, MPLS должна применяться совместно с уже описанными выше технологиями IntServ и DiffServ.
Нужно иметь в виду, что проблемы, описанные при рассмотрении IntServ и DiffServ, сохраняются и в том случае, когда в качестве транспортной технологии используется MPLS, поэтому было бы неправильным считать, что MPLS расширяет область применимости этих технологий, она лишь повышает качество их реализации.
В качестве вывода отметим, что необходимость ввода систем управления сетевыми ресурсами для обеспечения качества обслуживания особенно остро стоит при переходе к сетям следующего поколения и реализации, так называемой концепции "All IP". Поэтому многие производители оборудования активно разрабатывают и продвигают такие системы.
Подходы к стандартизации систем управления качеством обслуживания
Архитектура, предложенная организацией CableLab
Организация CableLab предложила архитектуру [10] для динамического управления качеством обслуживания (DQoS — Dynamic Quality of Service) в сетях связи, построенных на базе технологии оптоволоконно-коаксиальных кабелей (HFC — Hybrid Fiber and ^axial). В такой сети несколько кабельных модемов, расположенных у пользователей, делят один общий восходящий канал от пользователя к системе терминирования кабельных модемов (CMTS — Cable Modem Termination System). Разделение полосы пропускания осуществляется при помощи адресов второго уровня модели ВОС на основе спецификации интерфейса кабельной системы передачи данных (DOCSIS — Data Over Cable Service Interface Specification). На втором уровне механизмы обеспечения качества обслуживания определены спецификацией DOCSIS версии 2. Целью DQoS является реализация процедур передачи сигнальной информации и динамического управления ресурсами всей сети с интерфейсами DOCSIS.
Архитектура, предложенная организацией DSL Forum
Организация DSL Forum предложила архитектуру [11] для обеспечения качества обсуживания в сети доступа, построенной на базе технологии цифровой абонентской линии (DSL — Digital Subscriber
Line). В отличие от сетей, построенных на базе технологии оптоволоконно-коаксиальных кабелей, DSL-модем подключается к оборудованию пользователя через выделенную медную линию. Поэтому на втором уровне между DSL-модемом и мультиплексором доступа цифровой абонентской линии (DSLAM — Digital Subscriber Line Access Multiplexer) не требуется динамического управления качеством обслуживания.
Основное внимание организация DSL Forum уделила вопросам обеспечения качества в сети, находящейся в помещении абонента, в частности, проблеме управления ресурсами и их распределению между несколькими терминалами, расположенными за домашним шлюзом абонента. Под домашним шлюзом обычно понимают устройство с функциями маршрутизатора для проводного и беспроводного подключения различных устройств. В сети доступа, построенной на базе технологии DSL, домашний шлюз и сервер удаленного широкополосного доступа (BRAS — Broadband Remote Access Server), расположенный на стороне оператора связи, являются важными сетевыми элементами, которые оказывают влияние на качество обслуживания. Управление трафиком в сети DSL основано на разделении услуг в направлении от пользователя. Домашний шлюз классифицирует трафик на поток данных с гарантией качества (DiffServ) и на поток данных без гарантии качества (Best Effort), а также разделяет типы трафика, отправляемого во внешнюю сеть от абонента.
Основная функция сервера BRAS — агрегация пользовательского трафика и отправка его во внешнюю сеть. BRAS осуществляет соединение устройств внутренней сети абонента с внешней сетью, а также и контроль над этим соединением. Разделение трафика домашним шлюзом производится на основе классов обслуживания (CoS — Class of Service). Правила разделения трафика устанавливаются во время настройки домашнего шлюза. Оператор имеет возможность удаленно управлять домашним шлюзом абонента и менять правила разделения трафика.
Архитектура, предложенная организацией ETSI
В архитектуре подсистемы управления ресурсами и установлением соединений RACS (Resource and Admission Control Sub-system) управление ресурсами осуществляется на сети доступа, а также на граничном участке уровня ядра [12]. Под уровнем ядра понимается участок сети, где производится маршрутизация по протоколу IP При этом под сетью доступа понимается участок сети, на котором агрегируется или распространяется трафик без динамической маршрутизации. Управление ресурсами в сети доступа осуществляется на втором уровне модели взаимодействия открыггых систем (ВОС). Управление ресурсами на уровне ядра сети не рассматривается в концепции RACS.
На рис. 1 приведена архитектура RACS.
Элемент сети, терминирующий трафик на втором уровне, и сетевой элемент, расположенный на границе транспортной сети, непосредственно осуществляют управление ресурсами. Компонент A-RACF (Access Resource And Admission Control Function) выполняет функции по управлению доступом к сетевым ресурсам и непосредственно самими сетевыми ресурсами. Компонент SPDF (Service-Based Policy Decision Function) осуществляет управление на основе политик доступа к услугам на границе уровня ядра сети. Архитектура RACS не получает никакой информации о топологии сети уровня ядра. Управление качеством обслуживания осуществляется в режиме "push", где управляющий компонент (A-RACF или SPDF) отправляет команды транспортному оборудованию.
Архитектура, предложенная организацией МСЭ-Т
РИс. 1. Архитектура RACS: AF — Application Function; A-RACF — Access-Resource and Admission Control Function; C-BGF — Core Border Gateway Function; NASS — Network Attachment Sub-System; SPDF — Service-based Policy Decision Function; RCEF — Resource Control Enforcement Function; e4, Gq, Rq, Ra, Re, la, Di, Ds — точки взаимодействия (reference points)
Архитектура RACS, предложенная ETSI, и функция управления ресурсами и установлением соединений RACF (Resource and Admission Control Function), предложенная МСЭ-Т, не обнаруживают при сравнении серьезных противоречий. Это объясняется тем, что организации МСЭ-Т и ETSI тесно взаимодействовали между собой в процессе разработки этих архитектур. Однако существуют некоторые различия между указанными архитектурами.
Одно из таких различий — участок сети, на котором осуществляется управление. В отличие от RACS, в архитектуре RACF рассматривается процесс управления сетевыми ресурсами для обеспечения качества обслуживания на всех участках сети. Кроме того, в архитектуре RACF предусматривается большее количество сценариев управления сетевыми ресурсами, чем в RACS. Поэтому архитектуру RACS следует рассматривать как составную часть архитектуры RACF
МСЭ-Т определило архитектуру управления качеством обслуживания в документе [13]. Основной идеей архитектуры управления качеством обслуживания в сетях следующих поколений является независимость транспортного уровня от уровня услуг. Например, при передаче речи по протоколу IP через сеть Интернет, голосовой трафик передается после процедуры обмена сигнальной информацией для установления соединения между рабочей станцией и сервером сигнализации. Кроме того, голосовой трафик может передаваться далее через сеть оператора фиксированной или мобильной связи. Однако оператор не сможет передать трафик данного типа с наивысшим приоритетом и получить дополнительную прибыль. Это происходит потому, что в настоящее время не используется механизм запроса и гарантированного предоставления требуемого качества услуг на уровне сети.
Для решения этой проблемы МСЭ-Т предложил выделить уровни транспорта и уровень услуг и сделать их независимыми друг от друга. В соответствии с концепцией о независимости этих уровней, требуемые сетевые ресурсы предоставляются сетью по запросу от уровня услуг. Уровень услуг в этой концепции отвечает за обмен сообщениями сигнализации между приложениями. Уровень транспорта в свою очередь отвечает за надежную передачу пакетов и управление трафиком. Уровень услуг может быть представлен сервером приложений или целой системой (например, IMS).
Функция управления транспортным уровнем служит для взаимодействия между уровнем услуг и уровнем транспорта. Эта функция дает разрешение на предоставление услуг в зависимости от состояния сетевых ресурсов и политики доступа к слугам, установленной оператором для пользователей. Также эта функция управляет сетевым оборудованием с целью выделения требуемых сетевых ресурсов. Функция RACF определяет доступность сетевых ресурсов и осуществляет управление сетевыми элементами. На рис. 2 приведена архитектура RACF
Функция управления услугами SCF отвечает за передачу сигнальной информации во время установления сессии пользования услугой. Эта функция запрашивает требуемый уровень качества обслуживания в элементе RACF
Элемент RACF определяет доступность сетевых ресурсов для обеспечения требуемого качества обслуживания и затем осуществляет управление оборудованием сети.
Функция управления присоединением сетей (NACF) поддерживает авторизацию профиля, в котором указан уровень качества обслуживания пользователя в сети доступа. Во время процедуры установления вызова эта функция проверяет доступность ресурсов сети доступа. Функциональная архитектура была разработана с учетом принципа независимости от местоположения расположения пользователя. Поэтому архитектура RACF может быть реализована в сети доступа и в сети уровня ядра.
Элемент RACF имеет два функциональных блока:
— функциональный блок обеспечения выполнения установленных правил (политик) (PD-FE);
— функциональный блок управления ресурсами транспортного протокола (TRC-FE).
Блок PD-FE определяет возможность предоставления услуги на основе:
— профиля пользователя в сети доступа;
— соглашения об уровне обслуживания (SLA);
— политики;
— приоритета;
— доступности сетевых ресурсов.
После того как запрос принят элементом PD-FE, он отправляет информацию по управлению передачей трафика сетевому обору-
Рис. 2. Архитектура RACF: SCF (Service control functions) — Функция управления услугами; PD-FE (Policy decision functional entity) — Функциональный блок принятия решений о правилах доступа к услугам (политик); TRC-FE (Transport resource control functional entity) — Функциональный блок управления ресурсами транспортного протокола; TRE-FE (Transport resource enforcement functional entity) — Функциональный блок выполнения решений об использовании ресурсов транспортного протокола; PE-FE (Policy enforcement functional entity) — Функциональный блок обеспечения выполнения установленных правил доступа к услугам (политик); NACF (Network attachment control functions) — Функция управления присоединением сетей; Rs, Rp, Rw, Rc и Rt — точки взаимодействия (reference points).
дованию для выделения сетевых ресурсов. В этой информации указываются:
— команды управления шлюзом, с указанием о разрешении или запрете передаче потока пакетов;
— маркировка пакетов потока данных;
— данные о привязке IP адресов и портов для осуществления функций NAT:
— управление значениями скоростей передачи;
— режим работы Firewall для осуществления фильтрация трафика;
— порядок передачи данных (выбор маршрута и сети для предоставления услуги с гарантированным качеством).
Функциональный блок принятия решений PD-FE управляет оборудованием сети доступа с помощью функционального элемента обеспечения выполнения установленных правил PE-FE. Элемент PE-FE расположен на границе региональной сети. В реальной сети связи функции элемента PE-FE может выполнять следующее оборудование:
— пограничный шлюз управления сессиями (SBC);
— головной кабельный модем (CMTS — Cable Modem Termination System);
— граничный маршрутизатор (PE).
Таким образом, функциональный элемент принятия решений PD-FE управляет качеством обслуживания сети с помощью блока PE-FE, расположенного на границе сети. Функциональный элемент управления ресурсами транспортного протокола TRC-FE отслеживает состояние сетевых ресурсов в региональной сети. Он выполняет принятие решений о предоставлении услуг на основе информации о доступности сетевых ресурсов.
Функциональный элемент управления ресурсами транспортного протокола TRC-FE предназначен для управления ресурсами сети
доступа в зависимости от используемого транспортного протокола.
Функциональный элемент принятия решений PD-FE управляет ресурсами транспортной сети независимо от используемого транспортного протокола.
Следует отметить, что в текущей версии стандартов МСЭ-Т не определены конкретные механизмы управления, осуществляемого элементом TRC-FE.
Сравнение рассмотренньх архитектур
В таблице представлено сравнение архитектур управления качеством обслуживания [14].
Архитектуры управления ресурсами, разработанные организациями PacketCable и DSL Forum, сосредоточены на определенной технологии передачи данных — оптоволоконно-коаксиальных кабелей и DSL соответственно. В отличие от указанных подходов, использование функции RACF, предложенной МСЭ-Т, и подсистемы RACS, предложенной ETSI, является более общим подходом к проблеме обеспечения качества.
Архитектуры управления сетевыми ресурсами RACF и RACS тесно взаимосвязаны с архитектурой, предлагаемой организацией 3GPR Организация 3GPP изначально создавалась для разработки новой архитектуры предоставления услуг в сетях подвижной связи, в частности, для сетей GSM. В контексте этой работы 3GPP разработала подсистему IMS для управления услугами мультимедиа, предоставляемых по протоколу IP в части управления сессиями, управления услугами и базой данных, содержащей информацию об абонентах. Даже несмотря на то, что IMS была изначально разработана для развития сетей СПС, построенных на основе стандарта GSM, подход, предложенный в этой концепции, может быть применен к транспортной технологии любого типа.
Сравнение архитектур управления качеством обслуживания
Архитек тура Участок сети, на котором осуществляется управление Транспортная технология Режим работы Особенности
МСЭ-Т RACF Сеть доступа, сеть агрегации*, сеть уровня ядра Любая Динамический Управление трафиком на любом участке сети; независимость от транспортной технологии
ETSI RACS Сеть доступа, сеть агрегации*, включая узел, граничащий с уровнем ядра Любая Динамический Управление трафиком на сети доступа и агрегации; независимость от транспортной технологии
3GPP Сеть доступа GSM Динамический Управление сессиями и услугами на основе концепции 1М5
Packet Cable Сеть доступа Оптоволоконно -коаксиальный кабель Динамический и статический Управление сетевыми ресурсами во время установления соединения и в процессе соединения
DSL Forum Сеть доступа DSL Статический Возможность управления качеством обслуживания на основе технологии 011Т$егу
*- при передаче данных в режиме multicast
Архитектура управления сетевыми ресурсами, предложенная в концепции IMS, разрабатывалась в согласовании с архитектурами 3GPP2 MMD (Multimedia Domain), ETSI TISPAN и МСЭ-Т NGN. Поэтому обе архитектуры RACS и RACF совместимы с концепцией IMS.
Наиболее общей архитектурой, осуществляющей управление сетевыми ресурсами из конца в конец без привязки к транспортной технологии, является архитектура, предложенная МСЭ-Т. Эта архитектура может применяться для обеспечения гарантированного качества обслуживания в сетях следующих поколений с использованием подсистемы IMS или без нее.
Литература
1. Ефимушкин ВА, Ледовских Т.В. Качество услуг связи: задачи национальной стандартизации // T-comm. Телекоммуникации и транспорт. — 2008. — № 5.
2. Шалагинов ВА Задачи исследования качества услуг на базе открытых интерфейсов в сетях следующего поколения//Труды Московского технического университета связи и информатики. — М.: ИД Медиа Паблишер, 2008. — Т. 1. — С. 78-81.
3. Шалагинов ВА, Ярлыкова СМ. Особенности разработки инфоком-муникационных услуг на языке VoiceXML//Сети и системы связи. — 2008.
4. http://www.useit.com/alerlbox/980405.html
5. Букатов АА, Шаройко О.В. Методы распределения емкости телекоммуникационных каналов и обеспечения качества сетевого обслуживания // ЮГИНФО Южного федерального университета, 2008.
6. Nichols K, Blake S., Baker F., Black D. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers // RFC2474, 1998.
7. Blake S, Black D., Carlson M, Davies E, Wang Z, Weiss W. An Architecture for Differentiated Services // RFC2475, 1998.
8. Braden R., Clark D., Shenker S. Integrated Services in the Internet Architecture: an Overview // RFC1633, 1994.
9. Rosen E, Viswanathan A, Callon R. Multiprotocol Label Switching Architecture // RFC3031, 2001.
10. PacketCable Dynamic Quality-of-Service Specification // PKT-SP-DQ0S-I12-050812, CableLabs, 2005.
11. DSL Evolution — Architecture Requirements for the Support of QoS-Enabled IP Services // Technical Report DSL Forum TR-059, 2003.
12. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): Functional Architecture// ETSI ES 282 003 2008.
13. Next Generation Networks — Quality of Service and performance // Рекомендация МСЭ-Т Y.2111, 2006.
14. Jongtae S., M‘ Y.C, SoonSeok L, Jinoo J., Overview of NGN QoS Control // IEEE Communication Vol. 45, №9, 2007.
