-6-

КОНТРОЛЬ СООТВЕТСТВИЯ

И УПРАВЛЕНИЕ В ТЕЛЕКОММУНИКАЦИЯХ И СВЯЗИ

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

Рассмотрим такой подход на примере контроля в цифровых сетях с интеграцией служб (ISDN) и их последущей широкополосной реализации (B-ISDN).     

6.1. ЦИФРОВЫЕ СЕТИ С ИНТЕГРАЦИЕЙ СЛУЖБ

Цифровые сети с интеграцией служб (Integrated Services Digital Network - ISDN) относятся к сетям, в которых основным режимом коммутации является коммутация каналов, а информация обрабатывается в цифровой форме. Здесь под интеграцией служб понимается предоставление абонентам сети возможности передачи не только оцифрованной речевой информации, но и таких услуг, как факсимильная связь, те-летекс и видеотекс, голосовая почта и др. С этой целью архитектура ISDN предусматривает несколько видов служб [60], включающих некоммутируемые средства (выделенные цифровые каналы), коммутируемую сеть общего пользования, сети передачи данных с коммутацией каналов и пакетов, сеть передачи данных с трансляцией кадров (frame relay), а также средства контроля и управления работой сети (рис. 6.1).

Рис. 6.1. Службы ISDN

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

6.1.1. Архитектура протоколов и пользовательские интерфейсы

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

Как показано в [61], для разделения процессов передачи пользовательской информации и сигнализации лугах. Протоколы, связанные с U-плоскостью, в свою очередь предназначены для передачи информации между приложениями в виде оцифрованной речи и видео или данных. Информация в U-плоскости может прозрачно переноситься сетью между пользователями или может управляться в пределах сети (например, A-law-to-m-law PCM преобразование).

При этом наличие всех семи уровней протоколов в той или иной плоскости для того или иного приложения не обязательно. Например, для передачи речи необходимо только сквозное соглашение на уровне 1 модели ВОС, а для передачи данных необходимо определить два или три нижних уровня протокола, так как сквозные функции уровней от четвертого до седьмого будут поддерживаться соответствующими стандартами и в связи с этим для сети они прозрачны.

Помимо определений С- и U-плоскостей модели ITU-T вводит еще два термина: функцию плоскости управления, выступающую как средство управления трафиком, с тем чтобы гарантироьать передачу всего трафика, используя соответствующий протокол данной плоскости, и понятие транспортной плоскости, отражающей физическую среду, передача по которой выполняется в соответствии с протоколами С- и U-плоскостей.

Так как одним из базовых принципов ISDN является предоставление пользователю разнообразных услуг сети, в концепции интегральных услуг предусматривается использование стандартного интерфейса между двумя типами оборудования, устанавливаемого в помещении пользователя (СРЕ). Этим оборудованием является терминальное оборудование пользователя (ТЕ), например, телефонный аппарат, компьютер или маршрутизатор, и сетевое окончание (NT), представляющее собой оконечное устройство канала связи с ближайшим коммутатором ISDN.

Учитывая, что пользовательский интерфейс предназначен для обеспечения требуемых скоростей передачи, с этой целью в ISDN предусмотрены следующие типы каналов:

В-канал со скоростью передачи 64 Кбит/с;

D-канал со скоростью передачи 16 или 64 Кбит/с;

Н-канал со скоростью передачи 384 Кбит/с (НО), 1536 Кбит/с (HI) или 1920 Кбит/с (Н12).

Каналы типа В обеспечивают передачу посредством временного мультиплексирования подканалов оцифрованной аналоговой информации, данных или их совокупности с последующим разделением подканалов на стороне приема. При этом оперирование с подканалами выполняется на уровне пользовательского оборудования, а соединение пользователей осуществляется коммутацией каналов, причем ISDN всегда коммутирует В-каналы полностью позволяя использовать их и для подключения пользователей к коммутаторам сети Х.25.

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

Каналы типа Н обеспечивают высокоскоростную передачу данных, необходимую, например, для передачи факсов, видео и высококачественной аудио информации.

Создавая такие каналы, ISDN поддерживает два вида пользовательских интерфейсов, известных как интерфейсы базового (BRI) и первичного (PRI) доступа.                                                                                        

6.1.2. Модель взаимодействия пользователь-сеть

Подключение оборудования пользователя с использованием данных интерфейсов к сети ISDN осуществляется в соответствии с моделью взаимодействия пользователь-сеть (рис. 6.3), в которой используются понятия функциональной группы, контрольной точки RP (Reference Point) и точки доступа АР (Access Point). Последние отражают, соответственно:

•     набор средств, необходимых для реализации интерфейса доступа пользователя к сети;

•     точки R, S, Т и U, соответствующие разделению между смежными функциональными группами;

•     точки 1, 2, 3. 4 и 5, определяющие интерфейс доступа к службам ISDN.

Согласно данной модели вначале рассмотрим функциональные группы (набор) средств, необходимых для реализации интерфейса доступа пользователя к сети.

Устройства функциональной группы NT1 образуют цифровое абонентское окончание (DSL), соединенное с сетью в контрольной точке U. Фактически NT1 представляет собой устройство, которое, вместе с аналогичным устройством оператора сети, создает на физическом уровне ISDN дуплексный канал связи. Устройство NT1 всегда устанавливается в помещении пользователя, несмотря на то, что может принадлежать оператору сети.

Устройства функциональной группы NT2 подключаются к NT1 в контрольной точке типа Т и являются устройствами канального или сетевого уровня, выполняющими функции концентрации и мультиплексирования пользовательских интерфейсов, например, посредством офисной АТС, коммутирующей несколько интерфейсов BRI, мультиплексора низкоскоростных каналов, маршрутизатора, работающего в режиме коммутации пакетов и др. В отличие от NT1 использование NT2 в связи с его функциональным назначением не является обязательным.

Устройства функциональной группы ТЕ1 представляют собой абонентские устройства, которые поддерживают интерфейсы BRI и PRI и по отдельности подключаются к NT2 в контрольной точке S. К таким устройствам относятся, например, цифровой телефон или факс. В случаях, когда NT2 может отсутствовать, контрольные точки S и Т объединяются и обозначаются как S/T.

Устройства функциональной группы ТЕ2 представляют собой абонентские устройства, которые не поддерживают интерфейсы BRI и PRI и в связи с этим подключаются к NT2 через терминальный адаптер (ТА). К таким устройствам можно отнести, например, маршрутизатор или компьютер, которые оснащены не относящимися к ISDN интерфейсами RS-232C, Х.21 или V.35. Подключение последних к адаптеру осуществляется в контрольной точке R.                                                     

С учетом ЭМ ВОС точки доступа 1 и 2 являются точками доступа для основного сервиса, обеспечиваемого ISDN, а точки 3 и 5 — для телесервиса (верхних уровней ЭМ ВОС ISDN). Точка 4 включает виды услуг, основанные на использовании согласно рекомендациям X и V CCITT терминальных адаптеров, служащих для преобразования стандартных интерфейсов в интерфейсы ISDN, осуществляя тем самым поддержку соединений данной сети с устройствами, выполняющими функции группы ТЕ2.

6.1.3. Интерфейсы и каналы передачи ISDN

Учитывая, что обеспечение высоких скоростей передачи невозможно без соблюдения определенных требований к физическому уровню пользовательских интерфейсов, включая особенности подключения терминалов пользователя к сетевому окончанию, рассмотрим данные вопросы более подробно.

Так, если пользователь подключей через интерфейс BRI, то DSL подсоединяется к сети в точке U посредством двухпроводной линии длиной не более 5.5 км (как и обычное окончание аналоговой телефонной сети), а для организации дуплексного режима используется технология одновременной передачи потенциального кода 2B1Q с эхоподавлением и вычитанием передаваемого сигнала из сформированного на приемной стороне суммарного сигнала. При подключении пользователя через интерфейс PRI соединение DSL с сетью осуществляется с помощью четырехпроводной линии длиной не более 1.8 км, а кодирование выполняется согласно требованиям интерфейсов Т1 и Е1, используя коды B8ZS и HDB3, соответственно.

Подключение терминального оборудования в контрольной точке S/T регламентируется рекомендацией ITU-T I.430 и может быть выполнено в нескольких вариантах в зависимости от схемы подключения ТЕ к NT1/2 (рис. 6.4).    

Согласно данному рисунку:

NT 1/2 соединен через согласующий резистор с ТЕ, удаленным на расстояние до 1 км;

NT1/2 соединен с группой до восьми ТЕ, подключенных к линии длиной до 200 м с произвольным интервалом;

NT1/2 соединен с группой ТЕ, подключенных к линии длиной до 500 м в интервале до 50 м от ее конца.

Здесь к одному NT1 или NT2 разрешается подключать до восьми ТЕ, объединяя их посредством монтажного ИЛИ.

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

Интерфейс BRI предоставляет пользователю 2В + D (два В и один D) каналы, которые работают в полнодуплексном режиме и обеспечивают пропускную способность 64 Кбит/с и 16 Кбит/с в каждом В-канале и D-канале, соответственно. В этом случае результирующая пропускная способность BRI интерфейса составляет 144 Кбит/с и, с учетом служебной информации, 192 Кбит/с. Так как различные каналы BRI интерфейса используют благодаря мультиплексированию один и тот же канал физического уровня, они являются логическими, а не физическими каналами.

В отличие от BRI интерфейс PRI обеспечивает повышенную пропускную способность сети, поддерживая так называемую «первичную скорость передачи», равную ЗОВ + D для стран Европы и 24В + D для США и Японии и соответствующую скорости цифровых каналов 2.048 Мбит/ с и 1.544 Мбит/с. Естественно, возможно использование меньшего числа каналов, например, 20B+D или объединение в один логический канал ряда В-каналов, обеспечивая результирующую пропускную способность не превышающую 2.048 Мбит/с, при пропускной способности D канала 64 Кбит/с.

Повышенная пропускная способность интерфейса PRI имеет место и при использовании Н-каналов, в частности канала НО со скоростью 384 Кбит/с (6 х 64 Кбит/с), канала НИ со скоростью 1.536 Мбит/с (24 х 64 Кбит/с) или канала Н12 со скоростью 1.920 Мбит/с (30 х 64 Кбит/с). В настоящее время стандартизованы интерфейсы для Н-каналов, структура которых имеет вид: (H0+D), (Hll+D), (H12+D). В этих интерфейсах пропускная способность канала D составляет 64 Кбит/с.

6.1.4. Протокольные уровни и структура В- и D-каналов

Протоколы ISDN в основном классифицируются в соответствии с их использованием для предоставления услуг (С-плоскость) и обмена информацией между пользователями (U-плоскость), учитывая, что для этих функций могут применяться протоколы, относящиеся к разным протокольным контрольным точкам. Основная часть спецификаций протокола ISDN касается интерфейса пользователь-сеть и сигнализации, переносимой по D-каналу и определяемой протоколами С-плоскости. Учитывая особенности такой межуровневой модели, основной

задачей ITU-T являлось описание протоколов С-плоскости применительно к контрольным точкам взаимодействия различного сетевого оконечного оборудования между собой (точка Т) и с терминальным оборудованием — аппаратурой пользователя (точка S), соответственно (рис. 6.5).

Данные протоколы описывают только интерфейс пользователь-сеть, не затрагивая связь пользователь-пользователь, и соответствуют трем нижним протокольным уровням модели ВОС для D-канала.

Здесь LE представляет собой как сетевое устройство, обеспечивающее услуги ISDN, так и сетевую сторону местной линии связи в которых используются протоколы поддерживающие услуги ISDN. Другие функции LE включают техническое обслуживание, эксплуатацию физического интерфейса и предоставление услуг по запросам пользователей. Некоторые производители станций ISDN далее подразделяют функции LE на две подгруппы, называемые линейным окончанием (LT) и коммутирующим окончанием (ЕТ). LT выполняет функции, связанные с окончанием местной линии связи, тогда как ЕТ выполняет функции коммутации. Для упрощения и обобщения далее используется только сокращение LE, избегая специальных ссылок на LT или ЕТ, за исключением случаев крайней необходимости. Тогда:

•    Уровень 1 описывает физическое соединение между ТЕ и NT, включая разъем, схему линейного кодирования, синхронизацию и электрические характеристики. Физическое соединение является синхронным, последовательным и полнодуплексным. Это может быть соединение точка-точка (PRI или BRI) или точка-многоточка (только BRI). D- и В-каналы используют одну и ту же физическую среду за счет применения временного мультиплексирования.

•     Уровень 2 описывает процедуры, выполняемые для того, чтобы гарантировать безошибочную связь по физическому каналу и осуществить логическое соединение между пользователем и сетью. С этой целью используется протокол LAPD, который также обеспечивает правила для мультиплексирования многочисленных ТЕ в один физический канал (многоточка) при BRI.

•     Уровень 3 определяет сигнальные сообщения, которые используются для запроса услуг сети.

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

Перед тем как подробно рассмотреть тот или иной протокол, очень важно точно определить место, к которому он относится. Это вызвано тем, что ITU-T ISDN протоколы, описывая интерфейс пользователь-сеть D-канала в контрольных точках S и Т, рассматривают эти точки по-разному в зависимости от уровня модели.

В частности, протокол ISDN уровня 1 определяет физическое соединение между ISDN терминальным оборудованием (ТЕ1 или ТА) и сетевым оконечным оборудованием (NT2 или NT1), не описывая физического соединения локальной станции оператора сети с сетевым оконечным оборудованием NT1 в точке U. Между тем, протоколы ISDN уровня 2 и 3 определяют логическую связь и сигнальные протоколы между ISDN терминальным оборудованием (ТЕ1 или ТА) или коммутационным оборудованием (NT2) и LE, соответственно. NT1 обеспечивает только услугу уровня 1, поэтому уровни 2 и 3 для него прозрачны. Учитывая данное обстоятельство, точка S на рис. 6.5 отражает ISDN интерфейс.

Важно отметить, что протоколы С-плоскости ITU-T ISDN определены только для точек S и Т и только по D-каналу. Поэтому пользователь может выбрать любые протоколы для услуг, предоставляемых провайдером по В- или Н-каналам, так как они используют один и тот же канал физического уровня за счет мультиплексирования по времени В-, Н- и D-каналов в одной физической линии (рис. 6.6).

6.1.5. Стек протоколов ISDN

Так как все скоростные стандарты и управление коммутацией В-канала определяются каналом сигнализации (каналом D), то модель взаимодействия открытых систем должна быть дополнена моделью протоколов передачи файлов по D-каналу. CCITT разработал рекомендации по организации доступа к D-каналу (рекомендации серий X и Q).

Соответствие протокольных уровней взаимодействия открытых систем с рекомендациями данного комитета по использованию В- и D-каналов показано в табл. 6.1.

Как видно из таблицы, на уровнях с 4-го по 7-й канал D используется для организации протокольных взаимодействий (передачи файлов), а с 1-го по 3-ий — для организации сетевой сигнализации, в то время как В-канал определен только протоколом физического уровня и поэтому может использоваться для создания сети с коммутацией цифровых каналов.  

Учитывая, что протокол Q.931 переносит в своих пакетах адрес ISDN вызываемого абонента, при маршрутизации коммутатора D-канала, происходит одновременная сквозная коммутация и очередной части составного В-канала. При этом работа сети в режиме с установлением и без установления соединения определяется протоколом Q.921, а сеть каналов типа D внутри ISDN служит транспортным уровнем для системы сигнализации SS7. Данная служба относится к прикладному уровню ЭМ ВОС, но ее услуги пользователю недоступны, так как эта сеть используется для обмена сообщениеями между коммутаторами.

В настоящее время ISDN в основном используются как более скоростные сети с коммутацией каналов, применяя интерфесы BRI и PRI в коммуникационном оборудовании для подключения отдельных компьютеров или небольших ЛВС и в маршрутизаторах сетей небольших размеров, соответственно. Что же касается поддержки служб с коммутацией пакетов на каналах типа В, то здесь имеются две возможности — создание постоянного или коммутируемого соединения с коммутатором сети Х.25, что, собственно, сводится к предыдущему использованию ISDN как сети с коммутацией каналов, реализуя услугу, известную как «доступ к сети Х.25 через канал типа D» (рис. 6.7).

Большими возможностями с точки зрения скорости передачи пакетов в настоящее время характеризуется широкополосная сеть, известная как B-ISDN. Однако для такой сети характерен ряд аспектов, влияющих на качество передачи, таких как битовая скорость, дрожание фазы, частота ошибок и т. д. В то же время они не определяют функциональных характеристик услуг однонаправленного канала и поэтому     могут рассматриваться как «нефункциональные реальные эффекты». При такой точке зрения методология соответствия для B-ISDN не может быть определена как минимальное дополнение любой возможной методологии соответствия ISDN. В связи с этим сертификационное тестирование до настоящего времени рассматривается только с позиций тестирования функциональных характеристик, а оценка характеристик качества ШТ, связанных с нефункциональными характеристиками, запрашиваемыми средством тестирования верхнего уровня, по-прежнему остается за пределом области такого тестирования. Считается, что вопрос о том, следует ли рассматривать тестирование таких важных параметров, как качество предоставляемых услуг в структуре сертификационного тестирования требует тщательной оценки. Для этого в первую очередь необходимо решить вопрос о том, могут ли являться объектом расширенного понятия сертификационного тестирования B-ISDN перечисленные выше характеристики.

Аналогичная ситуация имеет место и в плане тестирования физического уровня. Так, в [9] отмечено, что физические уровни охватывают стандарты и требования соответствия разнообразной природы, а понятия тестирования в литературе по физике или электронике имеют различные толкования. Кроме этого считается, что тестирование физического уровня имеет природу, отличную от тестирования верхних уровней, и это вызывает существенные сомнения по поводу того, что сертификационное тестирование профайла для Т/профайлов должно включать . тестирование уровней-1. Эти соображения, естественно, относятся и к физическому уровню B-ISDN. Однако и при таком подходе в ряде работ приходят к выводу, что вопрос, следует ли рассматривать тестирование физического уровня вне общей концепции тестирования, требует тщательной оценки.

6.2. ШИРОКОПОЛОСНЫЕ ЦИФРОВЫЕ СЕТИ С ИНТЕГРАЦИЕЙ СЛУЖБ

Рассмотрим основные отличия в конфигурации и архитектуре протоколов B-ISDN с тем, чтобы выделить особенности тестирования нижних уровней модели OSI.

6.2.1. Эталонная конфигурация B-ISDN

Согласно проекта CCITT Рекомендации 1.413 в качестве базовой эталонной конфигурации B-ISDN принята конфигурация, представленная на рис. 6.8, а приоритетной целью процедур сертификационного тестирования считается та, которая установливается протоколом пользовательского оборудования. Это связано с тем, что сетевые операторы могут установить свои собственные процедуры приемочных испытаний, не

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

Учитывая данное обстоятельство, далее рассматривается только область пользовательского оборудования, считая, что граница между пользовательской и внешней областями расположена в точке Т_в. При этом рассматривается тестирование широкополосного оконечного устройства со стандартным стыком — терминала В-ТЕ1 и широкополосного устройства сетевого окончания — сетевого окончания B-NT2.

Контрольная точка R_B здесь не рассматривается ввиду незначительного интереса к сертификационному тестированию широкополосных терминальных адаптеров В-ТА и устройств с нестандартным стыком В-ТЕ2 на основании следующих соображений:

•     взаимодействие с ТА из точки S_B не добавляет ничего нового к разрабатываемой методологии с позиций сценариев тестирования, так как это аналогично обращению к точке S_B при тестировании В-ТЕ1;

•     взаимодействие с ТА из точки R_B усложнит процесс по той причине, что должно быть рассмотрено большое количество типов узкополосных оконечных устройств с нестандартным стыком В-ТЕ2, в то время как в свете реализации промышленных тестовых систем, но не в методологическом плане, представляет интерес ограниченное число данных устройств.

Возможные способы материализации приведенной эталонной конфигурации являются главным вопросом методологии тестирования, включающим:

•     расположение физических интерфейсов по отношению к контрольным точкам;

•     функциональность B-NT2;                                                           

•     топологию B-NT2.

Для рассмотрения этих вопросов вначале определим архитектуру протоколов и ее пользовательские интерфейсы.

6.2.2. Архитектура протоколов и пользовательские интерфейсы B-ISDN

В соответствии с методикой сертификационного тестирования вначале определим эталонную модель протокола (Protocol Reference Model — PRM) B-ISDN, данную в CCITT Рекомендации 1.321 (Рис. 6.9). Согласно этой модели термин «нижние уровни» означает все уровни от физического до уровня адаптации AAL.

Здесь следует отметить, что терминология, принятая в CCITT Рекомендации, не обязательно соответствует ISO 7498 OSI архитектуре, ПОЭТОМУ, Например, когда согласно OSI нижние уровни определяются как совокупность протоколов от физического до сетевого уровней, в В-ISDN PRM нижнего уровня эту совокупность составляют протоколы физического, ATM и AAL уровней. Очевидно различие и в понимании верхних уровней, исходя из различия двух эталонных моделей протокола.

Фундаментальным положением PRM B-ISDN является принцип разделения услуг на функции преобразования пользовательской и управляющей информации. Применение этого принципа позволяет, с одной стороны, осуществить полную интеграцию процедур С-плоскости (плоскости управления) для всех поддерживаемых сетью услуг, а с другой стороны, дать определение услуг U-плоскости (плоскости пользователя), которые специально разработаны только для потребностей пользователя. Эти отличия между С- и U-плоскостями существенны только для уровней выше AAL.

В рамках рассматриваемой задачи примем, что протокольные объекты С- и U-плоскостей взаимодействуют с объектами управления уровнем (LME), а на уровнях, для которых различие между U- и С-плоскостями существенно, взаимодействие осуществляется через плоскость управления. При таком допущении, методика сертификационного тестирования нижних уровней системы должна быть применима к случаю, когда объекты физического, ATM и AAL уровней характеризуются как объекты C/U-плоскости, взаимодействующие с соседними объектами C/U-плоскости и соответствующими LME. Все эти объекты, фактически, являются предметом протокольной стандартизации и, следовательно, сертификационного тестирования. Структура нижних уровней в этом случае отражает рис. 6.10, где точки доступа услуги (SAP) определены в пределах C/U-плоскости на границе каждого уровня между C/U-плоскостью и плоскостью управления уровнем, а в пределах каждого уровня — между плоскостью управления уровнем и управлением плоскостями.

Сертификационное тестирование B-ISDN включает четыре основных момента:

•     тестирование взаимозависимости между C/U-плоскостью и плоскостью управления;

•     необходимость обработки протоколов многочисленных равноправных объектов;

•     необходимость включения в сертификационное тестирование аспектов, касающихся качества предоставляемых услуг;

•     тестирование физического уровня,

каждый из которых представляет самостоятельный интерес.

6.3. СЕРТИФИКАЦИОННОЕ ТЕСТИРОВАНИЕ НИЖНИХ УРОВНЕЙ B-ISDN

Для рассмотрения вопросов тестирования нижних уровней B-ISDN вначале определим отличие методики тестирования протоколов ISDN от классической методики тестирование протоколов OSI, а затем выделим особенности сертификационного тестирования нижних уровней B-ISDN, что даст ключ к вопросу сквозного тестирования сетей телекоммуникаций с позиций предоставления услуг определенного качества.

Вовлечение C/U-плоскости и плоскости управления в сертификационное тестирование

Необходимость тестирования функционирования объектов в C/U-плоскости и в плоскости управления создает основное отличие прикладных сценариев относительно рекомендуемых ISO/IEC 9646 [60].

Так, в процессе тестирования OSI реализация системы (ШТ) имеет две SAP (Рис. 6.11): одну на границе верхнего уровня (U-SAP), а другую на границе нижнего уровня (L-SAP). Данные точки являются основными при определении возможных контрольных точек управления и наблюдения (РСО) для использования стандартного метода тестирования. Обычно локализация РСО точно на нижней границе ЩТ или в удаленной точке доступа основного провайдера услуг порождает два понятия средства тестирования нижнего уровня (LT), а набор функций, необходимых для наблюдения и управления U-SAP, определяет понятие средства тестирования верхнего уровня (UT). При тестировании B-ISDN возникает более сложная ситуация:

•     В рамках С-плоскости:

■   одноуровневые C/U-IUT, которые имеют три SAP, обычные U-SAP и L-SAP, а также новую точку на границе между C/U-плоскостью и плоскостью управления уровнем (рис. 6.12), обозначенную LM-SAP;

■   многоуровневые C/U-IUT, имеющие U-SAP, L-SAP и LM-SAP по числу уровней;

•     В рамках управления уровнем LM-IUT (очевидно не одноуровневые) имеют одну LM-SAP на границе с C/U-плоскостью и SAP на границе с плоскостью управления, обозначенную M-SAP.

6.3.1. Сертификационное тестирование C/U-IUT

 В принципе для C/U-IUT должны быть определены два UT:   

•     классический UT для управления и наблюдения за примитивами услуг (SP) в U-SAP C/U-IUT;

•     дополнительный UТ_доп для управления и наблюдения за SP в LM-SAP C/U-IUT.

LT может быть расположен либо на нижней границе IUT, либо в любой удаленной точке доступа к основному сервис-провайдеру. Например,

у для того, чтобы протестировать объект протокола ATM, необходимо осуществить управление через ATM-LME, установив связь между U-SAP (U-PCO) и выбранным VPI/VCI, в связи с чем в LM-SAP необходим UТ_доп и, следовательно, дополнительная РСО (А-РСО) (Рис.6.13). Для упрощения здесь U-SAP и LM-SAP предполагаются доступными.

6.3.2. Сертификационное тестирование LM-IUT

В этом случае должны присутствовать как минимум [62]:

•     классический UT для управления и наблюдения SP между LM-IUT и плоскостью управления в M-SAP;

•     классический LT для управления и наблюдения SP между LM-IUT и C/U-плоскостью в LM-SAP.

Классический LT может быть расположен либо в LM-SAP, либо в удаленной точке доступа к основному провайдеру услуг. Однако, если требуется провести тестирование «реального эффекта», т. е. оценить функционирование C/U-плоскости и, как следствие, правильное использование протоколов в плоскости управления, в конфигурацию необходимо ввести:

•     дополнительный UT для управления и наблюдения SP в U-SAP C/U-объекта, соответствующего данной LM-IUT;

•      дополнительный LT для управления и наблюдения SP в L-SAP С/ U-объекта, соответствующего данной LM-IUT.

В этом случае дополнительный LT может быть распложен либо в L-SAP, либо в удаленной точке доступа к основному провайдеру услуг. В последнем случае классический и дополнительный LT могут быть объединены в одно устройство LT. Наример, всестороннее тестирование протокола метасигнализации, касающегося ATM-LME, должно включать подтверждение, что SVC был назначен должным образом. Для этого необходим дополнительный UT в U-SAP протокольного объекта ATM, a это означает, что А-РСО должна быть заранее предопределена в этой U-SAP (Рис.6.14).

Для упрощения здесь предполагается полная доступность M-SAP и U-SAP, а классический LT расположен на удаленной стороне провайдера физического уровня и включает функции дополнительного LT. На практике один и тот же LT выступает как калассический при использовании канала метасигнализации ATM и как дополнительный LT при использовании других каналов.  

6.3.3. Особенности тестирования протоколов многочисленных равноправных объектов

В случаях, когда AAL зависит от вида предлагаемой на высших уровнях услуги, AAL представляет собой многопротокольный уровень, который, в частности, может включать вещательные протоколы. Поэтому в самом общем случае тестирование уровня AAL может потребовать использования многосторонних методов тестирования (ISO/IEC JTC l/SC 21 N 5076), которые представляют собой [62] очень обобщенный абстрактный метод тестирования. Этот метод определяет архитектуру для тестирования IUT, при которой обрабатывается более одной связи/соединения, допуская для каждой из них разный протокол. При этом необходимо учитывать, что для B-ISDN необходимо специальное дополнение из-за того, что объекты U/C-AAL (в отличие от объектов OSI, использующих только две SAP) общаются с тремя SAP. Более глубокое влияние многостороннего метода тестирования на тестирование протоколов нижнего уровня нельзя оценить до тех пор, пока соответствующие сценарии взаимосвязи между объектами нижнего уровня в разных плоскостях не буду описаны в соответствующих рекомендациях CCITT и стандартах ETSI.

6.4. ВОЗМОЖНЫЕ СЦЕНАРИИ SUT

С позиций существующих методов и конфигураций тестирования, рассматриваемые ниже сценарии считаются неуправляемыми, однако, как показано в работе [62], их можно использовать для тестирования В-ISDN в соответствии с будущей методологией тестирования. Для этого необходимо выпонить следующие шаги:

•     принять эталонную конфигурацию B-ISDN и соответствующее функциональное группирование;

•     предусмотреть набор различных возможных реализаций эталонной конфигурации (называемых далее реализуемыми конфигурациями);

•     идентифицировать в последних интерфейсы протоколов, относящихся к данному тестированию;

•     идентифицировать для выбранных функциональных групп сценарии протоколов в различных плоскостях.

После выполнения этих шагов можно рассматривать вопрос разработки подходящих SUT.

6.4.1. Контроль B-ISDN

Отображение контрольных точек в физических интерфейсах

Обычно методики тестирования в значительной степени определяются расположением физических интерфейсов по отношению к контрольным точкам. В CCITT Рекомендации 1.413 [61] приведен ряд примеров применения различных интерфейсов, которые могут иметь место:

•      в контрольных точках S_B и Т_в;

•      только в контрольной точке S_B;                              

•      только в контрольной точке Т_в;

•      в месте, где контрольные точки S_B и Т_в совпадают. Соответственно:

•      в первом случае обеспечивается полная доступность точек S_B и Т_в;

•      во втором случае контрольная точка Т_в физически недоступна, потому что B-NT2 и B-NT1 реализованы в одном комплекте оборудования;                                                                     

•      в третьем случае контрольная точка S_B физически недоступна, потому что B-NT2 и В-ТЕ реализованы в одном комплекте оборудования;

•     в четвертом случае функции, связанные с B-NT2, исчезают вовсе.

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

Функциональность B-NT2

Следующие два случая относятся к:

•     B-NT2, поддерживающей несколько терминалов, которые обращаются к пользовательскому или сетевому интерфейсу и требуют локального обмена B-ISDN как для связи с удаленными терминалами (внешний трафик), так и для связи с другими терминалами в пределах помещения заказчика (внутренний трафик);

•     B-NT2, поддерживающей несколько терминалов и обеспечивающей внутренний трафик без вовлечения B-NT1 в локальный обмен B-ISDN, при этом B-NT2 включает необходимые функции переключения для внутреннего трафика.

Объединение B-NT2 с В-ТЕ1 и терминальным оборудованием других типов известно также под названием внутренней сети заказчика (CPN).

Топология B-NT2

Топология B-NT2 может быть либо централизованной, либо распределенной, причем:

•     централизованная топология B-NT2 собирает трафик с нескольких В-NTIh направляет его в сеть общего пользования (рис. 6.15а);

•     распределенная B-NT2 обеспечивает многоточечный доступ к общей среде на S_B интерфейсе, имеющем распределенную структуру, которая состоит из AN (узла доступа) и нескольких МА (адаптеров среды), обеспечивающих физическую адаптацию с общей средой, использованной для CPN (интерфейс W). AN, кроме этого, обеспечивает доступ средств к сети общего пользования в интерфейсе Т_в (рис. 6.156).

Протокольные интерфейсы

Исходя из вышеизложенного, с позиций функциональности и структуры B-NT2, можно рассматривать четыре типа протокольных интерфейсов, которые изображены на рис. 6.16 и 6.17, причем в целях упрощения рассмотрения методик тестирования различие между плоскостями на этих рисунках не показано. Здесь необходимо отметить, что несмотря на схожесть уровневой .структуры AN и централизованной B-NT2, они имеют отличие, заключающееся в том, что протоколы нижнего уровня на W интерфейсе могут быть нестандартизованными.        

Так как для каждой приведенной функциональной группы не все уровни относятся к С- и U-плоскостям, это приводит к различию сценариев тестирования протоколов. Рассмотрим данные сценарии, вначале определив расположение протокольных уровней С- и U- плоскостей для каждой приведенной функциональной группы [62].

Приложение к В-ТЕ1

В этом случае уровневая структура включает все возможные уровни согласно эталонной модели протокола В- ISDN. Рис. 6.18 иллюстрирует соответствующую полную  уровневую структуру.  

Приложение к B-NT2

Из всех функциональных групп  только B-NT2 может иметь различные

реализации и использовать различные протокольные структуры, причем наиболее общая структура имеет место в случае, когда B-NT2 поддерживает несколько терминалов и обеспечивает функции их переключения, т. е. когда реализуется централизованная конфигурация модели (рис. 6.19).

В случае распределенной конфигурации уровневая структура МА имеет вид, представленный на рис. 6.20, считая, что уровневая структура AN идентична структуре централизованной D-NT2, но с возможными нестандартизованными ATM и физическими уровнями на W интерфейсе.  

Определение подходящих SUT

В соответствии с проведенным анализом функциональные группы В-ТЕ1 и B-NT2 определены как объекты B-ISDN нижних уровней тестирования протокола (РСТ). В соответствии с этим следует принять во внимание четыре SUT:

•     централизованную B-NT2;

•     МА (только в случае распределенной B-NT2);

•     AN (только в случае распределенной B-NT2);

•     В-ТЕ1.

Основным вопросом здесь является то, как реализуется в B-ISDN совокупность нижних уровней: физического, ATM и AAL, исходя из следующих альтернатив:

•     единая, когда вся совокупность реализуется целиком, подразумевая отсутствие доступности для любой внешней границы между уровнями или плоскостями, однако это не обязательно подразумевает доступность для верхней границы AAL в пределах C/U-плоскости;

•     уровневая, когда вся совокупность реализуется в виде двух или трех частей, что подразумевает их доступность для каждого верхнего уровня в пределах C/U-плоскости и, конечно, отсутствие доступности для каких-либо других уровней (внутренние границы между пллоскостями могут быть доступны);

•     частичная, когда совокупность реализуется только как единый подкомплект, включающий физический уровень.

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

Для централизованной B-NT2, для AN (распределенная B-NT2) и для В-ТЕ1 нижние уровни могут быть реализованы либо как монолитный комплект, либо как уровневый комплект. Монолитный комплект нижних уровней может даже быть вложен ниже его верхних уровней; в этом случае не существует доступности к верхней границе AAL в пределах C/U-плоскости.

Для МА (распределенная B-NT2) реализуется единый подкомплект, включающий уровень ATM и физический уровень. Возможно, что в этом случае доступа к верхней границе ATM уровня не будет, однако желательно по крайней мере обеспечить возможность обмена данными (например, ATM ячейками) выше него.

6.4.2. Контроль качества услуг в нерабочем режиме ATM

Так как параметры QoS могут контролироваться пользователями, можно считать, что в данном случае SUT представляет собой ATM сеть или ATM переключатель, а доступ к измерению QoS осуществляется в контрольных точах Т или S в пользовательском интерфейсе UNI.

Для выполнения контроля, SUT должен находиться под нагрузкой одного из трафиков, которые могут представлять собой:

•     тестовый трафик (A_Cells, однонаправленный поток ячеек), генерируемый тестовым оборудованием для VP и/или VC, используемых в целях тестирования.

•     контролируемый трафик (B_Cells, однонаправленный трафик), генерируемый тестовым оборудованием, но для VP/VC, которые не используются для тестирования.

•     реальный трафик (C_Cells, двунаправленный), генерируемы/по-

лученный реальными абонентами, присоединенными к UNI, используемому для тестирования.

Соответственно, трафик на выходе для тестируемых ячеек будет представлять собой:

■    тестовый трафик (A_Cells, однонаправленный), полученный на тестовом оборудовании для VP и/или VC, используемых в целях тестирования.

■    контролируемый трафик (B_Cells, однонаправленный), полученный на тестовом оборудовании, но для VPs/VCs, не используемых для тестирования.

■    реальный трафик (C_Cells, двунаправленный), генерируемый/полученный реальными абонентами, присоединенными к UNI, используемому для тестирования.

■    фоновый трафик (D_Cells и D'Cells, двунаправленный): трафик, генеруемый реальными абонентами, не присоединенными на входе или выходе тестируемых ячеек.                           

Это позволяет рассматривать две базовые конфигурации тестирования, в которых:

1.    SUT находится полностью под контролем средства тестирования в отсутствие реального и фонового трафика, а тестовый и контролируемый трафики генерируются средством тестирования. Эта конфигурация позволяет получить воспроизводимые результаты тестирования, потому что QoS параметры в значительной степени зависят от общего трафика в SUT.

2.    SUT нагружена реальным и фоновым трафиками, которые не контролируются тестовым оборудованием, что не позволяет получить достаточно воспроизводимые результаты тестирования, потому что реальный и фоновый трафик могут привести к условиям некоторой перегрузки в рамках SUT. Поэтому необходимо измерять не только QoS параметры, но и нагрузку:

■    на UNI входах тестируемых ячеек;            

■    на UNI выхода тестируемых ячеек;

■    в рамках SUT.

Здесь входом для тестируемых ячеек служит одна из контрольнных точек (Т или S) в которых могут генерироваться две категории ячеек:

•     A_Cells — формирующие тестовый трафик, в котором каждая ячейка содержит:

■    VPI или VCI VP resp. VC, установленные в целях тестирования;

■    верный заголовок (НЕС);

■    полезную нагрузку ячеек, содержащую идентификацию (например, порядковый номер ячейки, показатель времени);

■    нагрузку, с учетом CRC, форма которого подлежит дальнейшему изучению.                                                                                 

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

•     B_Cells — формирующие контролируемый трафик, в котором каждая ячейка содержит:

■   VPI или VCI, отличные от VP resp и VC, используемые в целях тестирования.

■   верный заголовок (НЕС)

■   полезную нагрузку ячеек.

Выход тестируемых ячеек так же представляет собой контрольнные точки Т или S, так как контроль QoS параметров основан на установлении событий для ячеек. Следовательно, действительные измерения могут быть проведены только выше физического уровня.

Физический уровень, реализованный в средстве тестирования, может рассматриваться как свободный от ошибок и не имеющий задержек обработки сигнала, в противном случае, ошибки и задержки на физическом уровне должны быть приняты во внимание при расчете значений QoS параметров. Кроме этого, при измерениях QoS необходимо учитывать только действительные ячейки, которые поступают с физического уровня, потому что ячейки с ошибочным НЕС на выходе для тестируемых ячеек, будут подвержены процедуре исправления заголовка или же будут отвергнуты. Поэтому анализ неисправных ячеек и ячеек с ошибкой в НЕС на ATM уровне будет исключен.

Таким образом, в контрольной точке измерения QoS следует различать два типа ячеек:

•     A'_Cells — принадлежащие к тестовому трафику, идентифицированному VPI и/или VCI, для которых проводится следующий анализ CRC нагрузки:

■ если CRC верен, ячейка рассматривается как действительная  тестовая ячейка и в этом случае можно провести анализ ячейки, это отражает верную последовательность, присваивая:

-  да, для ячейки, рассматриваемой как правильная тестовая ячейка (называемая a_cell).

-  нет, для ячейки, рассматриваемой как неверная тестовая ячейка (называемая b_cell).

■   если CRC неверен, ячейка (называемая c_cell) рассматривается как ошибочная тестовая ячейка даже если существует возможность ошибочной вставки данной ячейка.

•     B'_Cells не принадлежат тестовому трафику, но должны приниматься во внимание при расчете общего трафика на выходе тестируемых ячеек вместе с реальным трафиком.

При анализе потока тестовых ячеек обычно определяются следующие параметры QoS:

Коэффициент ошибок для ячеек (CER)

При введении на вход тестируемых ячеек постоянного потока A_cells, на выходе A'_cells этот поток анализируется в течение временного интервала tl, определяемого типом услуги, a CER рассчитывается по формуле

CER = с/А',

где А' — количество полученных тестовых ячеек A'_cells, ас — количество A'_cells с ошибками (c_cells нагрузка CRC неисправна).

Этот метод приведет к неправильным результатам, если получены неправильно вставленные ячейки с битовыми ошибками нагрузки (пересчет с и А').

Коэффициент потерь ячеек

Для определения данного показателя, постоянный поток тестовых ячеек, содержащий A_cells, посылается на вход тестируемых ячеек, а на выходе A'_cells полученные ячейки анализируются в течение временного интервала tl, который зависит от услуги. CLR подсчитывается следующим образом:

CLR - (А - А')/А,

где А — количество A'_cells (тестовых ячеек).                                   

В случае, если количество неправильно вставленных ячеек больше количества потерянных ячеек, CLR будет отрицательным, а если получены неправильно вставленные ячейки с битовыми ошибками нагрузки (пересчет А'), этот метод приведет к неправильным результатам.

Коэффициент неправильно вставленных ячеек (CMR)

На вход тестируемых ячеек подается постоянный поток тестовых содержащих только B_cells ячеек, при этом должно быть исключено поступление А'_се11, за исключением тех случаев, если она неправильно вставлена. Поэтому A'_cells подсчитываются в течение зависящего от услуги временного интервала t2, a CMR определяется как:

CMR = A'/t2.

Коэффициент нарушения последовательности ячеек (CSR)

Стандарт 1.356 не определяет коэффициента нарушения последовательности ячеек (CSR), так как AAL контролирует этот процесс, однако это явление представляет собой ошибочное поведение ATM сети, которое пользователь может пронаблюдать. Поэтому рекомендуется использование метода измерения согласно которому постоянный поток тестовых ячеек, содержащий A_cells, посылается на вход тестируемых ячеек, а на выходе A'cells анализируются в течение зависящего от услуги временного интервала tl. В этом случае

CSR = b/А^׳,

где b — количество b_cells, которые обогнали предыдущую ячейку (ошибка последовательности ячеек).

Время передачи ячейки

В этом случае на выходе тестируемых ячеек анализируются только правильные A'_cells, т. е. имеет место отсутствие неисправности нагрузки CRC. Чтобы осуществить измерения времени прохождения ячейки, средство тестирования, которое генерирует тестовый трафик и анализирует полученный трафик, должно иметь возможность синхронизации с точностью до микросекунд. При этом все параметры оцениваются исходя из измерения задержки прохождения ячейки (CTD):

CTD = tr - ts,

где tr и ts — синхронизированные моменты времени приема и передачи тестируемых ячеек.

Очевидно, что CTD представляет собой один из функциональных параметров передачи ячеек, который в значительной степени зависит от трафика ячеек в тестовом, контролируемом, реальном и фоновом трафиках.

Средняя задержка прохождения ячейки (MCTD) Этот параметр представляет собой среднее арифметическое значение CTD, измеренное в течение зависящего от услуги временного периода tl и равен

MCTD(tl) = Scdt/a,

где а — количество полученных и правильных тестовые ячеек A'_cells, a Scdt — сумма CDT (tr - ts) всех правильных A'_cells.

Очевидно, что приведенное тестирование QoS параметров отражает частное решение, но даже такое рассмотрение позволяет представить основные подходы к решению вопроса обеспечения требуемого качества обслуживания.

6.5. КОНТРОЛЬ КАЧЕСТВА УСЛУГ СЛУЖБ И СЕТЕЙ ПЕРЕДАЧИ ДАННЫХ

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

Согласно рекомендациям CCITT (I.112 и Q.9) предоставление услуг передачи данных определяется как «вид обслуживания, полностью реализующего возможность связи между пользователями в соответствии с протоколами, установленными для соответствующего вида соединения» [63]. В ISO услуга ПД определяется как «итог непосредственного взаимодействия поставщика (оператора связи) и потребителя (пользователя)» [64]. Так как услуги предачи данных предоставляют пользователям только службы передачи данных, а операторы предоставляют только услуги переноса сигналов между точками размещения пользователей [65], следует различать и требования к качеству предоставления данных услуг. Такое отличие в первую очередь определяется структурой данных служб (рис. 6.22).

На схеме показано, что сеть передачи данных в общем случае включает как глобальную сеть WAN, так и локальные сети доступа LAN, с помощью которых абоненты соединяются между собой. Собственно сеть передачи данных (СПД) заканчивается аппаратурой окончания канала данных LT, а интерфейс NT/LT является границей между СПД и точкой взаимодействия этой сети с оконечным оборудованием данных NT. Ранее было показано, что средства коммутации пакетов глобальной сети включают три нижних уровня протоколов ЭМ ВОС, а в NT предусмотрены еще и протоколы верхних уровней. Поэтому для обеспечения связи CCITT регламентирует только протоколы нижних уровней, относя согласование протоколов верхних уровней к прерогативе пользователей. В то же время, учитывая необходимость соответствия протоколов взаимодействующих систем, функции верхних уровней должны быть согласованы, в частности, должна быть определена функция контроля качества услуг.

Известно, что доступ NT к СПД может осуществляться как по прямому соединению (с помощью арендованных каналов или выделенных линий доступа), так и по коммутируемому соединению (при помощи ISDN или ТфОП ). При этом независимо от типа оконечного оборудования (асинхронного или синхронного) и типа соединения за качество услуг на всей сети, включая участки доступа, отвечает оператор СПД. В связи с этим с того момента, когда некоторый прикладной процесс пользователя-отправителя создает, например, файл или сообщение, которые должны быть отправлены по адресу прикладного процесса пользователя-получателя, и дает сигнал на их передачу, начинается процесс передачи, подпадающий под ответственность оператора СПД. С этого момента прикладной процесс отправителя начинает взаимодействовать с     протоколами верхних уровней NT-передатчика, а собственно передача по сети файла или сообщения в NT-приемник и прикладной процесс пользователя — получателя осуществляется с помощью протоколов нижних уровней. Процесс передачи данных заканчивается, когда файл или сообщение оказываются в той области оконечного оборудования получателя, которая закреплена за прикладным процессом адресата.

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

К настоящему времени ITU-T наиболее подробно проработал вопросы нормирования параметров качества услуг служб и сетей передачи данных по рекомендациям серии X, которые для СПД выражаются комплексом критериев функционирования, например, каждой фазы сеансовой услуги и делятся на две группы — критерии скорости и критерии достоверности (точности)/надежности. Данные критерии группируются в матрицу, отражающую три этапа сеанса передачи данных: установление соединения, передачу данных и разъединение (табл. 6.2).

По существу рассматриваемые критерии качества относятся к QoS сеансового уровня и представляют собой список параметров, относящихся к одному из перечисленных критериев его функционирования:

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

Возможность невыполнения сеансового соединения, ограничивающая максимальное отношение неисправностей (типа «задержка») при установлении соединения к общему количеству запросов на соединение. Если это отношение больше требуемого значения, объект, выступающий инициатором сеанса, не будет более делать попыток установления соединения.

Возможная пропускная способность, определяющая минимально допустимую скорость передачи между равноправными пользователями в течении сеанса. Этот параметр задается для каждого направления «потока» и относится только к нормальной (типовой) передаче данных. Значение этого параметра обсуждается между пользователями и может быть изменено провайдером во время установления соединения.

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

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

Задержка передачи, пропускная способность и остаточная частота ошибок, находящиеся ниже допустимых уровней, могут привести к нарушению передачи и получению пользователем сообщения «неисправность». Для оценки вероятности получения такого сообщения существует параметр вероятность нарушения передачи, который определяет максимальную вероятность возникновения неисправности по вине провайдера услуг. Если действительная наблюдаемая частота неисправностей при передаче превышает значение этого QoS параметра, запрашиваемое пользователем соединение не будет осуществлено.

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

Отсюда можно заключить, что именно QoS критерии функционирования, относящиеся к фазе передачи данных транспортного потока, диктуют необходимость достижения транспортным уровнем уровня повышения сетевых услуг, например, разделения потоков с целью увеличения результирующей пропускной способности. Очевидно, что существуют и другие QoS критерии, не связанные с функционированием, но ассоциируемые с сеансом и транспортом. Так, приоритетность соединения связана с отношением одного соединения к другому и является мерой важности каждого из них. Поэтому, если при необходимости общий QoS соединения будет снижен, например, вследствие потери сетевого соединения, от этого пострадают в первую очередь низкоприоритетные соединения. Если же соединение должно быть прервано для сохранения общего уровня услуг, тогда именно приоритетность будет определять, какие из них следует прервать. Еще один такой параметр - это защита соединения, требующий от соединения определенного уровня защиты от мониторинга или манипуляции с соединением. Существуют четыре уровня данного параметра отсутствие защиты; защита от пассивного мониторинга; защита от мониторинга, повторного воспроизведения, дополнения или удаления; защита от комбинации последних уровней.                                                                                                      

И наконец, транспортный объект определяет эквивалентные QoS параметры для сетевого провайдера, которые вместе с ограничивающими значениями, налагаемыми на него QoS параметрами запроса транспортного соединения, основаны на его «опыте» и возможностях. Эти QoS параметры сетевого провайдера будут включены вместе с запросом, ориентированным на соединение или с запросом без соединения.               

Таким образом, для контроля качества предоставляемых услуг требуется определять все указанные характеристики, а контроль должен проводиться на интерфейсах «пользователь — служба передачи данных» (прикладной процесс — верхний протокольный уровень NT) и интерфейс «сеть — оконечное оборудование данных» (LT/NT), на которых определяется качество услуг, соответственно, службы и сети передачи данных. Здесь очень важным является учет влияния на качество передачи данных оконечного оборудования как важнейшего компонента любой службы связи, который, собственно, и определяет тип службы (передача данных, телефония, телеграфия и др.).

Согласно приведенной структурной схеме службы передачи данных при нормировании качества услуг необходимо учитывать также и сети доступа (LAN), рассматривая в общем случае согласно рекомендаций ITU службу передачи данных как состоящую из двух типов служб («службы в службе»):

•     службы виртуальных соединений;                                                

•     службы постоянных виртуальных каналов.

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

В рекомендациях ITU имеется подробная методика проведения и обработки результатов измерений параметров качества услуг WAN сети при прямом доступе, учитывающая, в каких точках, как и при каких условиях (скорости передачи и загрузке каналов) следует измерять приведенные в таблице 6.2 параметры качества услуг. При этом регламентируется также продолжительность и число измерений с получением результатов для двух значений параметров — среднего и с вероятностью 95%.

В работе [65] показано, что на сегодняшний день рекомендации серии X определяют лишь нормы на сети данных для прямого доступа, в то время как нормы на службы передачи данных отсутствуют, и поэтому можно говорить об отсутствии норм не только на службы, но и на сети передачи данных. Еще хуже обстоят дела у пользователей сети Internet, которая создавалась заведомо без учета норм качества услуг. Поэтому констатируется, что даже в наиболее изученной области передачи данных с коммутацией пакетов по рекомендациям ITU-T серии X нормы на качество услуг служб передачи данных отсутствуют. Правда, в Internet принимаются эффективные меры по повышению достоверности, уменьшению времени передачи, повышению надежности доставки информации, но никаких норм на эти параметры не существует. Отсутствуют также нормы на качество услуг передачи данных в новых сетях и службах, таких как ISDN, FR, ATM, откуда следует неутешительный вывод: нормы на качество услуг служб и сетей передачи данных для всех видов передачи данных практически отсутствуют. Однако все это относится к нормам для операторов служб и сетей передачи данных.

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

•     время доставки сообщения определенного объема по заданному адресу;

•     достоверность передачи сообщения (количество ошибок в сообщении определенного объема);

•     надежность функционирования службы (как часто случается, что служба не в состоянии выполнить два первых требования и сколько времени уходит на устранение перерывов в работе).

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

6.6. СИСТЕМНАЯ ПОЛИТИКА УПРАВЛЕНИЯ СЕТЬЮ

В настоящее время сетевое управление подошло к такому рубежу, когда производители пытаются заменить в системах управления функции пассивного наблюдения за состоянием сети на функции обеспечения требуемого качества обслуживания [65]. Такое решение базируется на новейшем подходе в области сетевого управления, носящем название системной политики управления (СПУ), и позволяет наиболее полно реализовать возможности сети. Последнее требует применения в системе средств контроля, позволяющих отслеживать множество характеристик сети. В связи с этим при выборе лучшей стратегии развития СПУ основное внимание следует уделять, с одной стороны, спектру и качеству контроля, а с другой стороны — возможности интеграции с традиционными системами управления, поддержки стандартных протоколов и работе с устройствами различных производителей. Учитывая, что СПУ требует реализации активного мониторинга сети, контроля за выполнением соглашений об уровне обслуживания и интеграции с различными сетевыми службами, объединение этих компонентов в единое целое представляет сложную, но вполне разрешимую задачу.

Основные производители сетевого оборудования, такие, как Allot Communications, Cabletron, Cisco Systems, Extreme Networks, Lucent Technologies и Nortel Networks, ведущие разработчики программных продуктов — IPHighway и Orchestream, а также развивающая свою стратегию в сетевом управлении и оборудовании компания Hewlett-Packard и GN Nettest, уже достигли определенных успехов в этом направлении. Сегодня упомянутые фирмы в большинстве своем представляют изделия, имеющие вполне удовлетворительные для первых СПУ возможности, однако их внедрение в реальные сети затруднено рядом факторов, первый из которых можно сформулировать одной фразой: «Данная технология мощна и привлекательна, но она еще недостаточно проверена» [65].

К сожалению, в этой области существуют серьезные проблемы, которые связаны с отсутствием единых стандартов, необходимых для доступа к оборудованию с целью управления его функциями и характеристиками, контроля текущего состояния, а также для получения информации о пользователях и корпоративных ресурсах. Сегодня для полноценного конфигурирования оборудования используется целый набор средств, в частности, передаваемые по telnet команды CLI, что при любом непредвиденном изменении синтаксиса конфигурационных команд нарушит функционирование СПУ. Применение протокола SNMP в настоящее время обеспечивает вполне приемлемые возможности по мониторингу работы сетевого оборудования, но имеет явные ограничения при его конфигурировании. Некоторые фирмы идут по направлению использования агентов LDAP, планируя установить их в оборудование для территориально распределенных сетей и в телефонные коммутаторы, отмечая свойственную такому решению масштабируемость и отказоустойчивость, что делает его оптимальным для сетей, работающих на основе правил системной политики и активно использующих справочники.

Учитывая такое положение, очевидна целесообразность наличия одного стандартного протокола, например, протокола COPS, который многие считают наиболее перспективным. Изначально он создавался для того, чтобы маршрутизаторы и коммутаторы могли получать от серверов правил информацию о возможностии резервирования полосы пропускания для того или иного приложения. Сегодня существует две версии этого протокола: для динамической сигнализации QoS и для конфигурирования сетевого оборудования. Первый вариант (его так и называют — COPS) является стандартом, а второй, иногда обозначаемый как COPS-PR, еще не ратифицирован, поэтому в ближайшее время придется применять его фирменные или предстандартные реализации. Не менее проблематичны и вопросы сбора информации о пользователях и ресурсах сети, так как существующие службы справочника, такие, как Active Directory фирмы Microsoft, NDS фирмы Novell или какая-либо другая, не стандартизированы. Это затрудняет решение вопроса интеграции служб справочника со средствами сетевого управления. Несмотря на это, большинство фирм единодушны во мнении, что будущее СПУ невозможно представить без тесной интеграции со службами справочника, введение которых может служить:

•     для совместного использования информации серверами правил (policy server), обеспечивая масштабируемость и взаимодействие с системами третьих фирм, а также для ввода в действие новых правил без разработки специального интерфейса прикладных программ (API);

•     единым источником информации для управления ресурсами как вычислительной, так и телефонной сети в виде гигантского хранилища информации, где каждый пользователь будет иметь свой раздел с атрибутами почтового ящика речевой почты, номера телефона, привилегий на доступ к сетевым ресурсам, информации DHCP и DNS и т. д. и т. п.

Существуют также расхождения во взглядах на роль СПУ, представляя в большинстве случаев систему управления сетью (СУС) на основе СПУ как средство конфигурирования сетевого оборудования или как систему, поддерживающую протокол COPS до настольных систем конечных пользователей.                                                                                        

Несмотря на все эти различия и различия в других вопросах, включая концепции безопасности, несомненно одно: средства СПУ кардинально изменят способы управления сетями, в связи с чем представляется достаточно важным определение тенденций развития СПУ. Для этого будем использовать материалы работы [65], где приведены краткое описание и результаты тестирования продуктов отмеченных фирм. Учитывая отсутствие разработанных критериев оценки рассматриваемых решений, проведем их сопоставление по максимуму реализованных возможностей, так как каждая из компаний по-разному понимает термин «работа сети на основе правил системной политики».

6.6.1. Особенности СПУ

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

Условия могут быть заданы почти для любого уровня семиуровневой модели взаимодействия открытых систем (табл. 6.3) и устанавливаются исходя из аппаратно-программных возможностей сетевого оборудования, наиболее важным из которых является поддержка механизмов QoS сетевого уровня (DiffServ и ToS). Последнее необходимо для обеспечения сквозного качества обслуживания в IP- и IPX-сетях. Для этого ПО должно предусматривать возможность обработки информации сетевого и вышележащих IP-уровней, а также поддерживать широкий набор условий, ранее поддерживаемых исключительно традиционными маршрутизаторами. В настоящее время для этих целей широко используются маршрутизирующие устройства нового поколения — маршрутизирующие коммутаторы, которые могут оперировать информацией, содержащейся в поле ToS пакета IP.

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

6.6.2. Основные пути реализации СПУ

Все многообразие подходов к СПУ условно можно разделить на три большие группы:

•     стратегия разработчиков аппаратных средств;

•     стратегия разработчиков программного обеспечения;

•     стратегия разработчиков программно-аппаратных средств.

Учитывая ряд общих черт данных стратегий, рассмотрим их основные отличительные признаки и определим наиболее перспективные решения.

6.6.2.1. Концепции построения СПУ разработчиков аппаратных средств

Можно предположить, что наилучшие перспективы в области СПУ имеют фирмы — производители телекоммуникационного оборудования, так как никто не знает этого оборудования лучше специалистов самой фирмы. Особенно это касается компаний, доминирующих на рынке маршрутизаторов для территориально распределенных сетей, где в первую очередь и потребуются новые средства управления. Поэтому вначале рассмотрим основные возможности, которыми должна обладать СУС на основе СПУ с позиций производителя оборудования.                              

Nortel Networks

Продукт Optivity Policy Services (рис. 6.23) фирмы Nortel Networks

позволяет управлять как собственными маршрутизаторами с операциионной

системой BayRS, так и маршрутизаторами Cisco с операционной системой IOS. Продукт снабжен всем необходимым для работы в сети масштаба предприятия и, опираясь на базу данных Oracle, обеспечивает управление правилами и IP-адресами, позволяя определять правила для обработки трафика конкретных пользователей.

Архитектура управления использует модель «условие — действие» с использованием правил и предполагает группировку сетевых устройств _; по доменам, причем каждый конкретный интерфейс может входить в , состав только одного домена. Она поддерживает все типовые условия, использующие параметры сетевого и транспортного уровней, а также ряд дополнительных уникальных возможностей. Система способна выполнять глубокий анализ пакетов, поэтому использующие ее маршрутизаторы могут идентифицировать потоки на основании URL-адресов HTTP и любых заранее заданных смещений (offset). Предусмотрены механизмы определения обработки пакетов на основании содержимого практически любых их частей, выполняя, например, отказ в обслуживании, маркировку потоков в соответствии с требуемым классом обслуживания, регулирование и мониторинг потоков трафика и его профилирование. Однако по конфигурированию механизмов обслуживания очередей возможности весьма ограничены.

Основными направлениями развития данного направления является синхронизация информации о приоритетах 802.1р и DiffServ, поддержка механизма безопасности 802. IX и резервирования полосы пропускания RSVP, введение функции обнаружения сетевых устройств путем интеграции с платформой управления Optivity Network Management и использование в качестве способа установки правил протокола COPS-PR, который заменит используемые механизмы SNMP и CL1.

Cisco Systems

Программные продукты QoS Policy Manager (QPM) и User Registration Tool (URT) данной фирмы, как, впрочем, и практически все, разрабатываемое в ней ПО, характеризуются удобным пользовательским интерфейсом с поддержкой широких функциональных возможностей системы. Так, менеджер СПУ обеспечивает возможность автоматического определения и настройки интерфейсов маршрутизаторов и коммутаторов собственного производства и за счет их программного обеспечения осуществляет импортирование информации о топологии сети, сохраняя правила системной политики в базе данных в виде файла.

Менеджер имеет средство формирования условий, основанных на IP-адресах, масках IP-подсетей или групп IP-хостов, типах протоколов (IP, TCP или UDP), номерах протокольных портов TCP/UDP, значениях битов IP Precedence, а при отслеживании более высокоуровневых параметров использует специальный механизм NEAR (Network-Based Application Recognition), позволяющий отслеживать потоки использующие такие прикладные протоколы, как Н.323, Real Audio, NetShow и Exchange, a также анализировать адреса URL протокола HTTP.

Имеется возможность установления различных способов обработки трафика (роли) через каждый интерфейс или группу интерфейсов, устанавливая для них механизмы обслуживания очередей, а затем указывая необходимые правила, т. е. определяя, какие механизмы должны поддерживаться тем или иным устройством. Это могут быть механизмы организации очереди с абсолютным приоритетом (Priority Queuing — PQ), настраиваемой очереди (Custom Queuing — CQ), взвешенной справедливой очереди (Weighted Fair Queuing — WFQ), очереди со взвешенным произвольным ранним обнаружением (Weighted Random Early Detection — WRED) и т. д. При работе с трафиком предусмотрена возможность так называемого «окрашивания» потока с помощью битов IP Precedence, ограничение выделяемой потоку полосы пропускания, непосредственная приоритизация путем отправки трафика в конкретную очередь, профилирование (shaping) трафика.                                           

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

Для взаимодействия менеджера с продуктами других фирм потребуется интеграция имеющихся средств управления со средствами управления уровнем обслуживания (Service Level Agreement Management — SLAM), средствами сетевого управления других производителей и др. Продвижение в этом направлении приведет к созданию обратной связи, которая позволит сети самой изменять конфигурацию в ответ на изменение условий. Поэтому, создавая базу для таких решений, уже сейчас следует использовать справочники как интерфейсы к внешним источникам информации.

RealNet Rules

Концепция решения задачи СПУ специалистами Lucent Technologies основана на использовании взаимодействия сетевых устройств с сервером справочников посредством протокола LDAP, что, по их мнению, в отличие от COPS и CLI само по себе обеспечивает высокую масштабируемость и отказоустойчивость технического решения, так как в последнем случае для этого требуются значительные дополнительные усилия. В то же время в перспективе компания планирует предложить интегрированный COPS-агент и посредник-транслятор для управления с помощью SNMP и CLI.

Система предназначена в первую очередь для корпоративных ЛВС, отодвинув в отдаленное будущее поддержку оборудования территориально распределенных сетей и концентраторов доступа ATM. В настоящий момент система позволяет использовать ограниченный набор условий и действий, хотя для определения условий может быть задействовано большинство базовых параметров, таких, как IP-адреса и подсети, протокольные порты TCP/UDP, маркировка DiffServ.

Система тесно интегрирована с другими собственными программными продуктами, что позволяет определять правила для конкретного пользователя или хоста, а также указывать в них МАС-адреса. Это позволяет обеспечить определенный уровень безопасности в ЛВС через основанную на Web систему регистрации, заключающуюся в том, что после аутентификации пользователя, он может быть приписан к определенной IP-сети, позволяя применять к нему соответствующие правила. Хотя степень интеграции в данном случае достаточно высока, с ее помощью пока решаются лишь основные задачи СПУ, но перспективы очевидны. Система уже имеет встроенную поддержку протокола COPS, для хранения правил на сервере LDAP используется схема CIM, что обеспечивает доступ к ним внешних приложений, а сетевые справочники рассматриваются как единый источник информации для управления всеми ресурсами вычислительной и телефонной сетей: адресами, пользователями, традиционными и IP-телефонными системами, речевой почтой и пр.

Extreme Networks

ExtremeWare Enterprise Manager (EEM) представляет собой комплексный пакет сетевого управления, который обеспечивает конфигурирование и наблюдение за работой коммутаторов, создание виртуальных ЛВС и определение правил. Он предназначен в первую очередь для сетей, построенных на базе собственного оборудования, но поддерживает и оборудование других производителей, что позволяет осуществлять сквозное (end-to-end) управление как локальными, так и территориально распределенными сетями.

ЕЕМ, как и большинство других решений, позволяет определять условия на основе физических и протокольных (TCP/UDP) портов, виртуальных ЛВС, IP-адресов и подсетей, типов сетевых протоколов и пр. Однако, помимо этого, в нем предусмотрена уникальная технология DLCS (Dynamic Link Context System), которая позволяет устанавливать соответствие между именем пользователя ОС Windows NT, IP- или МАС-адресом рабочей станции и портом коммутатора. В связи с этим коммутаторы, отслеживая процессы регистрации пользователя в первичном контроллере домена Windows NT (просматривая пакеты WINS NetBIOS), сообщают об этом серверу правил, позволяя применять их к пользователю (или группе) независимо от того, с какой рабочей станции он зашел в сеть.

Все это позволяет соблюдать выполнение правил, ограничивающих скорость одних потоков при гарантии определенного качества обслуживания других, обеспечении приоритетной обработки трафика TCP по сравнению с трафиком UDP, идентификации и приоритизации пакетов на основании физических портов и идентификаторов виртуальных ЛВС и, наконец, реализации технологии DLCS. В то же время из-за того, что механизмы обслуживания очередей моделируются таким образом, чтобы они соответствовали архитектуре устройств собственного производства, такой подход позволяет контролировать передачу трафика через границу территориально распределенной сети без использования средств управления других производителей.

Будущее такого подхода представляется в интеграции ЕЕМ со средствами управления третьих фирм, используя платформу HP Open View, обеспечении поддержки технологии DiffServ, а также возможности устанавливать списки доступа и правила непосредственно на каждом интерфейсе, ориентируясь на стандарты COPS и COPS-PR при использовании протокола LDAP только в качестве способа доступа к серверу справочников. Представляется также важным обеспечение в будущем поддержки технологии RSVP и отслеживание трафика протоколов Н.323 и Kerberos.

Allot Communications

В отличие от других систем NetPolicy является приложением на базе Java. Она позволяет использовать сложные правила обработки трафика, предлагает табличный интерфейс для определения условий и соответствующих действий, но не поддерживает механизмы ролей, которые реализованы в других более поздних продуктах других фирм. Как и большинство систем, NetPolicy позволяет определять потоки на основе IP-адресов, масок подсетей, типов сетевых протоколов (IP, IPX, AppleTalk и др.), протокольных портов TCP/UDP, информации IP ToS и т. д.

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

При использовании сетевых устройств собственного производства система NetPolicy обеспечивает поистине всеобъемлющий контроль за сетью, например, она позволяет использовать такие уникальные и, к сожалению, нестандартные функции, как распределение нагрузки и перенаправление в кэш-сервер на основе заданных правил. В то же время возможности работы с сетевыми устройствами других производителей в данной системе весьма ограничены, поэтому работы по поддержке различных версий операционной системы IOS ведутся достаточно интенсивно. Работа с базовыми механизмами обслуживания очередей и списков контроля доступа ничем не отличается от аналогичных решений.

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

В настоящее время для взаимодействия с сетевыми устройствами система NetPolicy использует протокол COPS и команды CLI, предусматривая в будущем расширение числа поддерживаемого системой оборудования, углубление интеграции со службами справочников (она уже поддерживает протокол LDAP) и дальнейшее развитие механизма обратной связи.

Несмотря на столь передовое решение, оно, к сожалению, является нестандартным и применимо только при использовании оборудования собственного производства.

Cabletron

Построенный на основе кода Spectrum VLAN Manager пакет Spectrum Policy Based Network Management (PBNM) Suite обеспечивает обнаружение устройств, управление виртуальными ЛВС и установление правил обработки трафика, полностью используя преимущества технологии SecureFast при работе с коммутаторами собственного производства. Последние благодаря этому способны сообщать очень важную информацию, например IP- и МАС-адреса подключенных к конкретным портам станций, что значительно упрощает задачи «отслеживания» пользователей и управления на основе правил. В свою очередь возможность читать и записывать информацию сетевого и канального уровней пакетов IP и IPX позволяет реализовать мощнейшие возможности по использованию правил на границах сети, поддерживая самый широкий набор условий, которые могут быть составлены с учетом физических портов, информации IP ToS, типа протокола IP (UDP, TCP, ICMP и т. д.), класса сервиса и типа пакета IPX, IP- и IPX-адресов, номеров сетей и сокетов IPX и т. д. Только данное решение обеспечивает мощную поддержку IPX, в частности, определение введения трафика в конкретную виртуальную ЛВС, приоритизацию пакетов с использованием многочисленных очередей, фильтрацию пакетов, их «окрашивание» битами IP ToS, ограничение скорости потока.

Для хранения правил в пакете реализована самая последняя (пока еще предварительная) спецификация CIM, а благодаря поддержке протокола LDAP и формата LDIF (LDAP Directory Interchange Format) служба справочника может самостоятельно информировать менеджера правил об изменении хранящейся в ней информации. Для конфигурирования маршрутизаторов и коммутаторов используются команды SNMP и CLI, что позволяет реализовать много таких функций, поддержка которых другими продуктами возможна только при использовании внешних средств. Например, имеется возможность самостоятельно обнаружить сетевые устройства и составить карту сети, используя ее в дальнейшем для формирования правил соответствующих физических портов.

Отсутствие поддержки RSVP и COPS, а также сетевого оборудования других фирм-производителей является основным минусом данного подхода и требует скорейшего решения этих вопросов.

6.6.2.2. Концепции построения СПУ разработчиков программного обеспечения

Особенностью построения СУС на основе СПУ компаниями, не производящими сетевое оборудование, является ориентация на изделия разных производителей, поддерживая самый широкий набор условий, действий и ролей.

IPHighway

Так же как и в рассмотренной выше системе, рассматриваемые далее программные продукты создавались для управления различными устройствами, не поддерживающими протокол COPS, свободно распространяя разработанный код этого протокола. С целью реализации концепции СПУ создан пакет открытой системной политики Open Policy System (OPS), который совместно с ориентированным на работу с RSVP в корпоративных сетях приложением QoSMaster формирует комплексное решение по сетевому управлению.

Используемый пользовательский интерфейс очень удобен, так как снабжен четкими средствами определения правил и действий, условия выполнения первых из которых составляются с указанием битов IP Precedence, IP-адресов, протокольных портов TCP/UDP, физических портов и других параметров. Сочетание такого формирования правил с предусмотренным созданием особых групп объектов, после классификации трафика позволяет очень гибко определять правила обработки интерфейсами различных потоков трафика. Помимо этого предусмотрены и различные механизмы обслуживания очередей, например, «первым пришел — первым ушел» (FIFO), PQ, CQ, WFQ, основанная на классах распределенная справедливая очередность или собственный механизм (гибрид WRED и CQ).

Сочетание OPS с QoSMaster обеспечивают работу с технологией RSVP (рис. 6.24), отслеживая процессы приложений и от их имени направляя

запросы RSVP, при этом маршрутизаторы обрабатывают эти запросы, а OPS определяет, разрешать или нет выделение запрошенных ресурсов.

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

Отмеченные особенности позволяют развить данную концепцию в плане создания системы операторского класса IPHighway Bandwidth Broker, которая обеспечит сквозное взаимодействие между поставщиками услуг и их клиентами с помощью продукта, а разработка средств обратной связи с сетевыми устройствами сделает возможными интерактивные мониторинг и обеспечение требуемого уровня обслуживания.

Orchestream Enterprise

Отличительной особенностью данной системы является то, что, уделяя большое внимание модели дифференцированных услуг DiffServ, в ней с целью сокращения времени, необходимого для конфигурирования сети, независимо от имеющегося сетевого ПО, используют интегрированные средства обнаружения сетевой топологии, а конфигурирование сетевых устройств выполняют с помощью нескольких протоколов, например, SNMP, HTTP, TACACS+ (Terminal Access Controller Access Control System Plus) и COPS.

Благодаря такому подходу система позволяет определять различные условия на основе кодов DiffServ (code points), IP-адресов, подсетей, протокольных портов TCP/UDP и пр., а администратор может задать выполнение определенных правил при наступлении заданных внешних событий, реализуя эту функцию с помощью интерфейса API. Вместе с тем ПО глубоко не анализирует информацию канального уровня и с его помощью нельзя, например, задать условия с использованием МАС-адресов или меток виртуальных ЛВС. В то же время система имеет мощнейшие возможности в части использования различных механизмов обработки классифицированных потоков. Она позволяет задействовать на платформах компаний производителей почти столько же механизмов, сколько и их собственное ПО. Здесь следует отметить очень важную возможность агрегатирования большого числа формируемых на периферии сети потоков в малое число классов обслуживания на магистрали, используя механизмы ограничения потоков и пометки трафика.

Для данной системы наибольшей проблемой и тем самым наиболее важной задачей является расширение возможности взаимодействия с оборудованием различных производителей и интеграция с различными справочниками сетевых ОС, так как в настоящее время для хранения информации о правилах в системах такого типа используются базы данных Oracle. Поэтому основное внимание разработчиков направлено на поддержку протоколов COPS и RSVP (Resource Reservation Protocol), a также предоставление пользователям ПО, посредством которого становится возможным создание для системы программных модулей, учитывающих специфику конкретной аппаратуры, а значит, позволяющих успешно управлять сетями, построенными на базе оборудования разных производителей.

6.6.2.3. Концепции построения СПУ разработчиков программно-аппаратных средств

Подход к построению СУС на основе СПУ компаниями, производящими как сетевое оборудование, так и программное обеспечение, представляется наиболее интересным, так как они не ограничены своим оборудованием и не стремятся к соответствию всем случаям жизни.

Hewlett-Packard

Как и при создании платформы управления Open View Network Management, компания Hewlett-Packard при разработке СПУ Policy Xpert постаралась обеспечить ее эффективное взаимодействие с оборудованием других производителей, Технология, заложенная в основу системы HP Open View Policy Xpert, базируется на протоколе COPS и тесно связана с технологией RSVP, поддержка которой является далеко не самой приоритетной для большинства других фирм.

Система работает с собственными коммутаторами HP ProCurve, маршрутизаторами Cisco и Intel, с устройствами PacketShaper фирмы Racketeer, а также может управлять хостами, оборудованными QoS-агентом фирмы Deterministic Networks. Она позволяет указывать в условиях самые разные параметры; время, дату, день недели, протокольные порты TCP/UDP, IP-адреса, URL-адреса HTTP, идентификаторы виртуальных ЛВС и пр. При совпадении одного из условий к потоку трафика возможно применение разнообразных моделей обработки, задействовав механизм обслуживания очередей PQ в устройствах Cisco, a на других платформах — задать минимальную и максимальную полосы пропускания для данного потока, ярлыки виртуальных ЛВС 802.1Q, «окрасить» трафик с помощью битов IP ToS и т. д.

Поддержка широкого спектра оборудования других производителей,

мощные возможности по работе с RSVP (сравнимые разве что с решениями IP Highway) и использование протокола COPS для взаимодействия с сетевым оборудованием — вот сильные стороны системы. При невозможности поддержки тем или иным устройством COPS в системе предусмотрена возможность использования агента-посредника (рис. 6.25), который от ее имени конфигурирует это устройство, а для ускорения работ по реализации поддержки COPS предусмотрен комплект средств разработки. Однако в отличие от других продуктов в системе не предусмотрена возможность конфигурирования механизмов обслуживания очередей на маршрутизаторах, а также средств поддержки механизмов фильтрации и безопасности, равно как и интеграции со службами LDAP. В связи с этим в перспективе должны быть решены как эти вопросы, так и выполнена дальнейшая интеграция с архитектурой HP OpenView для управления сетевыми устройствами и их обнаружения, для обеспечения выполнения правил системной политики, позволяя отслеживать параметры уровня обслуживания, и взаимодействия со справочниками в режиме реального времени.

GN Nettest

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

•     широкими функциональными возможностями;

•     простотой использования вследствие ограниченности трудовых ресурсов;

•     возможностью расширения, требуемой в связи с постоянной эволюцией топологии и размеров сети;

•     возможностью интеграции с Интранет вследствие того, что это на сегодняшний день фактически является определением открытой системы.

Наиболее полно указанным характеристикам отвечает система FastNet, которая представляет собой уникальное решение для полностью автоматизированного мониторинга и экспертной оценки трафика WAN и LAN сетей. Основные особенности данной системы будут рассмотрены в следующей главе.

ВЫВОДЫ

На примере цифровых сетей с интеграцией служб проиллюстрирована возможность решения проблемы тестирования нижних уровней в виде дополнений к методике тестирования OSI. Эволюция от OSI к ISDN состоит во введении U- и С-плоскостей и в координации соответствующих протоколов посредством LME в плоскости управления. В результате определены дополнительные типы SAP и РСО, установлены новые типы UT и LT, а в процесс тестирования одного уровня включены несколько протокольных объектов. Эволюция от ISDN к B-ISDN, в свою очередь, подразумевает, что:

1.   должен быть введен многопротокольный уровень (AAL), который использует одинаковую технологию преобразования (ATM) для различных классов услуг;

2.    тестирование нефункциональных характеристик также становится предметом сертификационного тестирования и осуществляется путем измерения параметров, связанных с качеством функционирования.

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

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