Слепов Н.Н. Современные технологии Цифровых оптоволоконных сетей связи (ATM, PDH, SDH, SONET и WDM)

Подождите немного. Документ загружается.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

195

Блок QAF - подключает к TMN логи-

ческие объекты класса NEF или QSF,

не являющиеся частью TMN, осущест-

вляя связь между эталонными точка-

ми внутри и вне TMN,а также реали-

зует функцию управляющего при-

ложения QAF-MAF;

Блок WSF - позволяет интерпретиро-

вать информацию TMN в терминаx

понятных пользователю управляющей

информации.

К дополнительным функцио-

нальным компонентам, не играющим

самостоятельной роли в качестве бло-

ков TMN, но включенных в состав

функциональных блоков, относятся:

DAF - функция доступа к (системному) каталогу - функциональный компонент, ассоциируемый со

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

DCF - функция передачи данных - используется для передачи информации между блоками, наделен-

ными управляющими функциями;

DSF - функция системного каталога - функциональный компонент, представляющий (как локально,

так и глобально) распределенный каталог системы;

НМА - человеко-машинная адаптация - компонент, преобразующий информацию MAF к удобному

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

ICF - функция преобразования информации - используется в промежуточных системах для трансля-

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

MF, OSF, QAF;

MAF - функция управляющего приложения - фактически осуществляет управляющий (адми-

нистративный) сервис TMN, может играть роль либо Менеджера, либо Агента [65,67], использу-

ется в функциональных блоках MF, NF, OSF и QSF;

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

жащейся в сообщении, используется во всех функциональных блоках;

MIB - база управляющей информации - играет роль репозитария (информационного архива)

управляющих объектов, не является объектом стандартизации TMN, используется в схеме дис-

танционного мониторинга RMON, а также в схеме простого протокола сетевого управления

SNMP [70]; MIB применяется во всех, кроме WSF, функциональных блоках;

PF - функция презентации - преобразует информацию к удобному для отображения виду,

используется в функциональном блоке WSF;

SF - функция обеспечения безопасности - функциональный компонент, обеспечивающий безопасность

работы функциональных блоков в соответствии с требованиями пользователя (тип сервиса по обеспечению

безопасности конкретных блоков различают использованием двойных обозначений, например: MF-SF,

NEF-SF, OSF-SF, QAF-SF, WSF-SF);

UISF - функция поддержки интерфейса пользователя - транслирует информацию, содержащуюся в

информационной модели TMN, в формат, удобный для отображения в рамках человеко-

машинного интерфейса, и, наоборот, транслирует информацию, вводимую пользователем, в фор-

мат, требуемый для информационной модели TMN;

WSSF - функция поддержки рабочей станции - осуществляет поддержку функций рабочей станции

WSF.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

196

В табл. 6-1 показано, какие дополнительные функциональные компоненты включаются в

функциональные блоки как обязательные (О), необязательные (опциональные - НО) или их вклю-

чение недопустимо (ндп).

Эталонные (интерфейсные) точки сети TMN

В сети TMN вводятся эталонные (интерфейсные) точки, определяющие границы сервиса.

Эти точки делятся на две группы. Первая группа включает точки внутри TMN, вторая - вне ее.

Точки первой группы делятся на три класса:

• q - точки между блоками OSF, QAF, MF и NEF, обеспечивают информационный обмен между

блоками в рамках информационной модели, описанной в стандарте ITU-T M.3100 [62]; эти

точки делятся на два типа:

- q

- точки между двумя блоками MF или блоком MF и остальными блоками;

- q

- точки между двумя блоками OSF или блоком OSF и остальными блоками;

• f - точки для подключения блоков WSF к OSF и/или к MF, подробнее описаны в рекомендации

ITU-T Rec. M.3300 [66];

• х - точки между OSF, принадлежащих двум TMN.

Точки второй группы делятся на два класса:

• g - точки между WSF и пользователем (см. определение человеко-машинного интерфейса* в

стандарте ITU-T Rec. Z.341 [347], его спецификацию в стандарте Z.331 [348], а использова-

ние этого интерфейса в сетях связи в стандарте Z.361 [349]);

• m - точки между QAF и управляемым объектом, не принадлежащим TMN.

Ниже приведена сводная табл. 6-2 положения указанных эталонных точек.

Положение указанных эталонных точек определяет положение соответствующих им ин-

терфейсов TMN, обозначаемых заглавными буквами. Оно показано на рис. 6-2 и рис. 6-4 [60].

Пунктиром на рис. 6-2 отмечены границы TMN. В соответствии с ними интерфейсы Q и F являют-

ся внутренними для TMN, интерфейс X - пограничным, а интерфейсы М и G - внешними.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

197

Функция передачи дан-

ных DCF

Основная цель DCF - соз-

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

передачи информации между блока-

ми, наделенными управляющими

функциями (рис. 6-3). В нашем слу-

чае он осуществляется между функ-

циональными блоками TMN А и В.

Характер взаимодействия между ни-

ми равноправный (одноранговый).

Этот механизм взаимодей-

ствия осуществляется на первых

трех уровнях модели OSI (физиче-

ском, канальном и сетевом).

DCF может быть поддержана на уровне различных типов подсетей, например, на уровне

Х.25, WAN, MAN, LAN, SS#7 или ЕСС SDH.

Внешний доступ к TMN

Доступ к TMN должен

быть как со стороны другой та-

кой же TMN, так и со стороны

пользователя сети. Схема такого

доступа и взаимодействия двух

сетей TMN приведена на рис. 6-

4. При организации доступа

пользователя (как правило, с це-

лью получения лимитированной

информации о сети) должны

быть предусмотрены стандарт-

ные в таких случаях процедуры,

включая меры защиты, преобра-

зование протоколов, трансляцию

функций и сервисное обслужи-

вание. Один из вариантов такого

доступа: сетевой менеджмент

пользователя CNM, описан в

ITU-T Rec. X.160 [359]

6.2.2.2. Информационный аспект архитектуры

При создании информационной модели обмена данными (сообщениями) в TMN используется объ-

ектно-ориентированный подход ООП и концепция Менеджер/Агент.

В рамках ООП управление обменом информацией в TMN рассматривается в терминах Ме-

неджер - Агент - Объекты. Менеджер (см. рис. 6-5), представляя управляющую открытую сис-

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

от объекта управления уведомления об их исполнении. Директивы, направленные от менеджера к

объекту, доводятся до объекта управления агентом. Уведомления, направленные от объекта к

менеджеру, доводятся до менеджера тем же агентом.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

198

Один Менеджер может быть вовлечен в информационный обмен с несколькими Агентами

и, наоборот, один Агент может взаимодействовать с несколькими Менеджерами. Агент может иг-

норировать директивы Менеджера по соображениям нарушения секретности доступа к объекту

или другим причинам. Все взаимодействие между Менеджером и Агентом осуществляется на ос-

нове использования протокола общей управляющей информации CMIP и сервиса общей управ-

ляющей информации CMIS, описанных в рекомендациях ITU-T Rec. X.710 и Х.711 [72, 71].

Указанная схема взаимодействия может быть использована при организации связи и взаи-

модействия между несколькими системами на основе TMN. На рис. 6-6 показана схема взаимо-

действия трехкаскадно связанных сетями TMN систем А, В и С, в которой система А управляет

системой В, которая, в свою очередь, управляет системой С. Здесь Менеджер М системы А управля-

ет системой В, ориентируясь на информационную модель системы В, которую он "видит" благода-

ря тому, что она хранится в базе МПЗ системы В и доступна для М через Агента А этой системы.

На основе этой информации М, используя сервис CMIS и протокол CMIP организует дви-

жение вниз по стеку протоколов OSI системы А от прикладного уровня до физического, на кото-

ром происходит связь со стеком протоколов OSI системы В, а затем движение по нему вверх с вы-

ходом через CMIS/CMIP на Агента системы А. Он реализует директиву от М по управлению объ-

ектами (ресурсами) системы В, отображаемыми в MIB. По цепи обратной связи М системы А по-

лучает уведомление от этого объекта через Агента системы В. По цепи прямой связи информация

об изменении статуса/состояния объекта (ресурса) отображается в MIB системы В и поступает

Менеджеру М системы В, управляющему системой С. Алгоритм действий менеджера М системы

В аналогичен описанному для системы А. Ясно, что уведомление, получаемое Менеджером М

системы В, передается далее в систему А и производит изменение в MIB систем С и В.

Организация указанного выше взаимодействия между системами подразумевает, что все

они используют общую базу знаний менеджмента SMK и одинаково ее интерпретируют. SMK

описана в ITU-T Rec. X.701 [70] и Х.750 [360]. Другим важным моментом является использование

службы каталога, описанной в ITU-T Rec. X.500 [361], для поддержки требований отсутствия

пересечений по именам и адресации в системе TMN.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

199

6.2.2.3. Общий аспект архитектуры TMN

Функциональный и информационный аспекты взаимодействия систем на основе TMN, кратко опи-

санные выше, являются хорошей основой для рассмотрения общего аспекта или собственно архи-

тектуры TMN.

На рис. 6-7 показан простой пример такой архитектуры управления сетями, где функцио-

нальные блоки представлены выполняющими только свои обязательные (О) функции (NEF, MF,

QAF, OSF, WSF). Эти блоки могут выполнять и другие (необязательные - НО) функции, как пока-

зано в табл. 6-3.

В схеме на рис. 6-7 управляющая сис-

тема OS взаимодействует с телекоммуникаци-

онными сетями через три типа интерфейсов,

соответствующие эталонным точкам: X, F, Q3.

Взаимодействие осуществляется через сеть пе-

редачи данных DCN, реализующую протоколы

уровней OSI 1-3 и поддерживающую функцию

DCF. DCN может состоять из нескольких свя-

занных между собой подсетей различного типа.

Например, это могут быть подсети, образован-

ные каналами связи данных типа DCC в сетях

SDH.

Через интерфейс F сеть DCN связана с рабочей станцией WS, играющей роль монитора

управляющей системы. Интерфейс X связывает DCN с "внешним миром", через интерфейс Q

)CN

может быть напрямую связана с сетевым элементом NE или с Q-адаптером QA, позволяющим

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

фейсы Q

и F сеть DCN подключается к устройствам сопряжения MD. Устройства MD, в свою

очередь, через интерфейс Q

подключаются к другим DCN или к подсетям той же DCN, которые

через интерфейсы Q

связаны напрямую cNE и QA.

TMN протоколы

Кроме указанных выше протоколов CMIP, CMIS, существуют группы протоколов, под-

держивающих каждый из указанных выше интерфейсов: Q

, Q

, X и F. Выбор протокола зависит

от требований по реализации данной физической конфигурации. Прикладной уровень (верхний

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

200

уровень семиуровневой модели взаимодействия открытых систем OSMSO) является общим

для всех групп протоколов, причем он не всегда требуется.

Для интерфейса Qj на верхних уровнях (с 4 по 7) модели OSI используются протоколы в

соответствии с рекомендацией ITU-T Rec. Q.812 [74], на нижних уровнях (с 1 по 3) - в соответст-

вии с рекомендацией ITU-T Rec. Q.811 [73]. При этом первые три уровня требуются практически

всегда, так как транспорт сообщений TMN осуществляется протоколами сетевого уровня.

Для оборудования, не имеющего такого интероперабельного интерфейса, как Q интер-

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

щего интероперабельного интерфейса. Такая конвертация осуществляется функцией MCF, а также

QAF, которые могут быть реализованы в QA, NE, MD или OS.

6.2.2.4. Логическая многоуровневая архитектура TMN

Учитывая сложность управления в TMN, ее архитектуру можно представить как логическую мно-

гоуровневую архитекутру (LLA), разбитую на логические уровни, соответствующие функцио-

нальным уровням TMN (см. разд. 6.1).

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

управления/менеджмента, построенными (как на фундаменте) на уровне сетевых элементов. В ре-

зультате архитектуру LLA можно представить в виде 5-уровневой модели вида [60]:

B-OSF -уровень бизнес-менедэ1смента - 5-й уровень;

S-OSF -уровень сервис-менеджмента - 4-й уровень;

N-OSF -уровень сетевого менеджмента - 3-й уровень;

E-OSF -уровень элемент-менеджмента - 2-й уровень;

NEF - уровень сетевых элементов -1-й уровень.

Все уровни модели связаны между собой интерфейсами Q

, а с "внешним миром" - интер-

фейсами X. Каждый из 4 уровней менеджмента выполняет свои специфические задачи.

Уровень элемент-менеджмента:

- управляет и координирует подмножество сетевых элементов на основе индивидуального набо-

ра функций NEF;

- управляет и координирует подмножество сетевых элементов на основе набора функций NEF для кол-

лективного взаимодействия, когда группа элементов NE рассматривается OSF как единый логиче-

ский элемент, или OSF управляет взаимодействием (например, связями) между NEF;

- управляет сбором статистики, ведением журнала событий (Log) и т. д. на уровне NE.

Уровень сетевого менеджмента:

- управляет и «координирует поведение всех сетевых элементов в рамках своих задач и своего

домена;

- конфигурирует, модифицирует и обеспечивает сетевые возможности, требуемые для поддерж-

ки клиентского сервиса;

- осуществляет обслуживание сети;

- управляет сбором статистики, ведением журнала событий (Log) и т. д. на уровне сети и взаимо-

действует с уровнем сервис менеджмента для мониторинга производительности и др.

Уровень сервис-менеджмента:

- обеспечивает контакты (facing) и взаимодействие (interfacing) клиента/пользователя с различ-

ными администрациями;

- обеспечивает взаимодействие с операторами сети - сервис-провайдерами;

- управляет сбором статистики (нужной, например, для поддержки требуемого качества обслу-

живания);

- обеспечивает взаимодействие между различными типами сервиса.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

201

Уровень бизнес-менеджмента:

- несет ответственность за бизнес телекоммуникационной компании в целом и адекватное моде-

ли бизнеса функционирование всех лежащих ниже слоев:

- поддерживает процесс принятия решений по оптимальному вложению инвестиций;

- поддерживает бюджет административного управления и обслуживания сети.

Следует отметить, что в указанной многоуровневой архитектуре взаимодействие "агент-

менеджер" осуществляется как по вертикали (между уровнями, где осуществляются операции

управления агентом и уведомления со стороны агента, см. рис 6-5), так и по горизонтали (в преде-

лах одного уровня, реализуя механизм локальной передачи управления).

6.2.2.5. Примеры реализации DCN в сетях SDH

Сеть DCN для TMN должна, там, где это возможно, следовать модели OSI (МВОС), описанной в

ITU-T Rec. X.200 [362]. Сеть соединяет элементы NE, QA и MD с OS с помощью интерфейса Q3, a

также MD с NE и QA с помощью интерфейса Q

. Использование интерфейсов Q обеспечивает сис-

теме максимально возможную гибкость.

В сетях SDH, использующих концепцию Менеджер-Агент, взаимодействие DCN (также

как и в TMN) реализуется с использованием MCF. На рис. 6-8,а, б приведены два примера реализа-

ции таких сетей, обеспечивающих функцию DCF в среде SDH. Объединяющий овал на линиях

связи на рис. 6-8 указывает, что оба интерфейса имеют объединенный транспорт.

В первом примере (рис. 6-8,а) Менеджер управляющей системы OS, реализует функцию

управляющего приложения OSF-MAF и управляет, используя интерфейс Q

и встроенные каналы

управления ЕСС, устройством сопряжения MD и элементами сети NE1 и NE2 через MCF. Кроме

этого, через интерфейсы Q

и Q

реализуется и стандартная для концепции Менеджер-Агент схема

управления устройствами MD, NE1 и управляемым объектом МО.

Во втором примере (рис. 6-8,6) используется только эта стандартная схема управления всеми

устройствами, поддержанная функцией MF-MAF и осуществляемая через интерфейсы Q

и Q

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

202

6.3. Общая схема управления сетью SDH

В свете вышесказанного, рассмотрим более подробно схему управления сетью SDH. Схема орга-

низационного управления сетью, см. рис. 6-9, является многоуровневой [23]. Нижний уровень этой

схемы включает SDHNE, которые обеспечивают транспортный сервис. Функции MAF внутри них

осуществляют связь с одноранговыми NE и поддержку управления ими, а также устройствами MD

и управляющей системой OS.

Примечание: На схеме используются следующие обозначения:

MCF - функция передачи сообщения А - агент

MAF - функция управляющего приложения М - менеджер

NEF - функция сетевого элемента МО - управляемый объект

ЕСС - встроенный канал управления F, Q - интерфейсы

Нижний уровень состоит из трех сетевых элементов и в целом напоминает рис. 6-8,6 (два нижних

блока). В каждом элементе логически выделены три функции: MCF, MAF и NEF, причем MAF каждого эле-

мента может включать Агент или Менеджер, или их оба. Управляющее сообщение, поступающее по ЕСС,

через интерфейсы F и Q, или от элемента другой (не SDH) сети, передается с помощью MCF, затем интерпре-

тируется с помощью MAF и через агента, интерпретирующего NEF, передается на управляемый объект МО.

Реакция объекта передается обратно через агента и менеджера в канал ЕСС, или через интерфейсы F и Q, на

средний уровень - MD, взаимодействующий непосредственно с OS, которая управляется от ЕМ или NMS.

Формат сообщений в такой многоуровневой структуре поддерживается одинаковым, как при движении по

горизонтали, NE-NE, так и по вертикали: NE-MD, MD-OS.

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

203

6.3.1 Подсеть SMS сети управления SMN

Сеть управления SDH (SMN), будучи сама частью TMN, состоит из нескольких подсетей SMS.

Архитектура подсетей SMS и их взаимодействие с TMN приведены на рис. 6-10 [23].

Отметим ряд особенностей этой архитектуры:

- несколько адресуемых NE могут располагаться в одном (отведенном для оборудования) месте,

доступ к которому осуществляется через шлюзовые элементы сети GNE, например GNE

GNE

;

- функция MCF имеет возможность завершать, маршрутизировать или обрабатывать сообщения,

передаваемые по ЕСС или через внешний Q-интерфейс;

- на основе ЕСС можно сформировать звено связи между офисами или местами установки обо-

рудования;

- в пределах одного места установки оборудования можно организовать связь, используя либо

встроенные каналы управления ЕСС, либо локальную сеть связи LCN.

Топология SMS и ЕСС

Каждая подсеть SMS должна иметь хотя бы один элемент, соединенный с MD или OS, он

называется шлюзовым элементом сети GNE, так как служит шлюзом в подсеть SMS.

На топологию сети ЕСС не накладывается ограничений - это может быть звезда, шина,

кольцо или ячеистая сеть.

6.3.2. Функции Управления

6.3.2.1. Общие функции управления

Управление каналами ЕСС Так как ЕСС используются для связи NE, то каналы ЕСС должны

иметь следующие функции:

Глава 6

Управление сетью: функционирование, администрирование и обслуживание

204

- запрос/получение сетевых параметров, таких как размер пакета, временные промежутки, каче-

ство сервиса и т.д.;

- формирование маршрута сообщения между узлами DCC;

- менеджмент сетевых адресов;

- запрос/получение сетевого статуса DCC для данного узла;

- возможность разрешать/запрещать доступ к DCC.

Фиксация временных событий. На все события, требующие фиксации во времени ставится

временная метка с разрешением в одну секунду. Время фиксируется по показанию локального таймера

NE.

Другие функции. Другие общие функции, например, защита на различных уровнях или

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

обеспечения, обеспечиваются в настоящее время производителями SDH оборудования.

6.3.2.2. Управление сообщениями об аварийных ситуациях

Наблюдение за сообщениями об аварийных ситуациях.

Оно включает обнаружение и сохранение таких сообщений о событиях и условиях, кото-

рые сопутствовали их появлению, причем не только в том оборудовании, в котором они были об-

наружены. Система OS SMN должна поддерживать следующие функции:

- автономное сообщение о всех сигналах об аварийной ситуации;

- запрос на сообщение о всех зарегистрированных сигналах об аварийной ситуации;

- сообщение о всех таких сигналах;

- разрешение/запрет на автономное сообщение о всех сигналах об аварийной ситуации;

- сообщение о статусе функции "разрешение/запрет на автономное сообщение о всех подобных сигналах".

Отслеживание истории сигналов/сообщений о возникновении аварийной ситуации.

Оно включает: запись моментов возникновения таких сигналов и их хранение в регистро-

вом файле, регистры которого содержат все параметры сообщения об аварийной ситуации. Реги-

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

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

запись с циклическим возвратом от конца к началу с перезаписью старых событий.

Другие функции.

Из них можно отметить, например, тестирование и регистрацию SDH оборудования.

Основные типы сообщений о возникновении аварийной ситуации.

Для того, чтобы получить более полное представление о типах аварийных ситуаций, кото-

рые отслеживаются в сети SDH, они представлены в виде таб. 6-4 [23], где в левом столбце поме-

щены типы аварийных ситуаций, а в верхней строке - места их возможного возникновения. В

ячейках таблицы помещен символ R, если требуется регистрация данного типа аварийной ситуа-

ции, или О, если такая регистрация не обязательна.