ГОСТ Р ИСО/МЭК 10040-99 Информационная технология. Взаимосвязь открытых систем. Общее описание административного управления систем

ГОСТ Р ИСО/МЭК 10040-99

Группа П85

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

Взаимосвязь открытых систем

ОБЩЕЕ ОПИСАНИЕ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ СИСТЕМ

Information technology. Open Systems Interconnection.
Systems management overview

ОКС 35.100.70
ОКСТУ 4002

Дата введения 2000-01-01

Предисловие

1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного Комитета Российской Федерации по связи и информатизации

ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 "Информационные технологии"

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 марта 1999 г. N 92

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10040-92 "Информационная технология. Взаимосвязь открытых систем. Общее описание административного управления систем"

3 ВВЕДЕН ВПЕРВЫЕ

1 Назначение

1 Назначение

Настоящий стандарт:

- содержит общее описание семейства стандартов по административному управлению (АУ) систем;

- устанавливает основу для группирования отдельных стандартов по АУ систем, определяя назначение каждой группы и идентифицируя основные компоненты каждой группы;

- содержит руководящие материалы по разработке стандартов по АУ систем, идентифицируя их взаимоотношения друг с другом;

- определяет термины для их использования другими стандартами АУ систем;

- применим ко всем определениям всех стандартов по АУ систем и ко всем аспектам АУ систем любого масштаба;

- применим к ситуациям, в которых ответственность за АУ систем централизована, и к ситуациям, в которых она децентрализована;

- определяет модель АУ систем, идентифицируя многие аспекты АУ систем (например, информационные, функциональные, связные и организационные) и уточняя затем модель для пояснения этих аспектов;

- идентифицирует принципы, определяющие требования к соответствию, и к заявкам на соответствие стандартам по АУ.

В основной части настоящего стандарта не содержится самих требований к соответствию, однако в нем содержатся требования к стандартам, претендующим на соответствие АУ систем.

В приложении А определен прикладной контекст для АУ систем и установлены правила согласования функциональных блоков (ФБ) АУ систем.

Для каждого из этих правил приведены требования к соответствию.

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

В настоящем стандарте содержатся ссылки на следующие стандарты:

ГОСТ 34.981-91 (ИСО 8649-88) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг для сервисного элемента управления ассоциацией (СЭУА)

ГОСТ 28906-91 (ИСО 7498-84, Доп.1-84 ИСО 7498-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель

ГОСТ Р 34.982-92 (ИСО 8650-88) Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола для сервисного элемента управления ассоциацией (СЭУА)

ГОСТ Р ИСО/МЭК 7498-4-99 Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 4. Основы административного управления

ГОСТ Р ИСО/МЭК 8825-93 Системы обработки информации. Взаимосвязь открытых систем. Спецификация базовых правил кодирования для нотации абстрактного синтаксиса версии один (АСН.1)

ГОСТ Р ИСО/МЭК 9072-1-93 Передача текста. Удаленные операции. Часть 1. Модель, нотация и определение услуг

ГОСТ Р ИСО/МЭК 9595-99 Информационная технология. Взаимосвязь открытых систем. Определение общих услуг административного управления

ГОСТ Р ИСО/МЭК 9646-1-93 Информационная технология. Взаимосвязь открытых систем. Основы и методология аттестационного тестирования для ВОС. Часть 1. Общие принципы

ИСО/МЭК 9596-1-91* Информационная технология. Взаимосвязь открытых систем. Протокол информации административного управления. Часть 1. Спецификация протокола

ИСО/МЭК 10026-1-92* Информационная технология. Взаимосвязь открытых систем. Распределенная обработка транзакций

ИСО/МЭК 10164-1-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 1. Функции административного управления объектами

ИСО/МЭК 10164-2-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 2. Функции административного управления состоянием

ИСО/МЭК 10164-3-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 3. Атрибуты для представления взаимоотношений

ИСО/МЭК 10164-4-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 4. Функции уведомления о нештатных ситуациях

ИСО/МЭК 10164-5-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 5. Функции административного управления отчетностью о событиях

ИСО/МЭК 10164-6-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 6. Функции управления журналом регистрации

ИСО/МЭК 10164-7-92* Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 7. Функции отчетности о нарушениях защиты

ИСО/МЭК 10165-1-92* Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 1. Модель информации административного управления

ИСО/МЭК 10165-2-92* Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 2. Определения информации административного управления

ИСО/МЭК 10165-4-92* Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 4. Руководство по определению администрируемых объектов
___________________
* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

3 Определения

3.1 Определения базовой эталонной модели

Настоящий стандарт использует следующие термины в области эталонной модели, определенные в ГОСТ 28906:

a) сервисный элемент прикладного уровня;

b) административное управление систем.

3.2 Определения основы АУ

Настоящий стандарт использует следующие понятия, определенные в ГОСТ Р ИСО/МЭК 7498-4:

a) администрируемый объект;

b) основа информации АУ;

c) логический объект прикладного уровня АУ систем.

3.3 Определения СЭОИА

Настоящий стандарт использует следующие понятия, определенные в ГОСТ Р ИСО/МЭК 9595:

a) атрибут (администрируемый объект);

b) общий сервисный элемент информации АУ;

c) общий сервис информации АУ.

3.4 Определения модели информации АУ

Настоящий стандарт использует следующие понятия, определенные в ИСО/МЗК 10165-1:

a) тип атрибута;

b) обозначение дерева;

c) границы объекта АУ.

3.5 Определения основ и методологии аттестационного тестирования ВОС

a) заявка о соответствии реализации протоколу (ЗСРП);

b) форма ЗСРП;

c) заявка о соответствии системе.

3.6 Определения для общего описания АУ систем

3.6.1 Агент - пользователь услуг информации административного управления (УИА), который в конкретном сеансе взаимодействия АУ систем выполняет роль агента.

3.6.2 Роль агента - роль пользователя УИА, в которой он способен выполнять операции АУ над администрируемым объектом (АО) и выдавать уведомления по поручению АО.

3.6.3. Зависимое соответствие - соответствие элементам протокола, относящимся к набору услуг, согласно заявке о соответствии системы.

3.6.4 Общее соответствие - соответствие элементам протокола, относящихся к корневому набору услуг и к любым дополнительным ФБ согласно настоящему стандарту.

3.6.5 Родовые определения - определения классов АО, типов атрибутов, типов уведомлений или типов операций АУ, доступных для общего пользования.

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

3.6.7 Класс АО - поименованный набор объектов совместно использующий те же наборы (поименованные) атрибутов, уведомлений, операций (пакетов) АУ, которые совместно создают одни и те же условия для наличия таких пакетов.

Примечание - Следующие два определения согласованы с соответствующими определениями по ГОСТ Р ИСО/МЭК 9646-1 относительно ЗСРП и формы ЗСРП.

3.6.8 Заявка о соответствии АО (ЗСАО) - заявка, составляемая поставщиком реализации АО, констатирующая реализованные функциональные и факультативные возможности, а также все опущенные возможности.

3.6.9 Форма ЗСАО - документ в форме анкеты, составленный разработчиком АО или тестового комплекта, который, будучи заполнен относительно реализации АО, становится ЗСАУ.

3.6.10 Администрируемая (открытая) система - реальная открытая система, содержащая пользователя УИА, который может играть роль агента.

3.6.11 Регион АУ - набор АО, к которым применима общая стратегия АО систем.

3.6.12 Информация АУ - информация в открытой системе, которая может быть передана протоколами АУ ВОС.

3.6.13 Объект, поддерживающий АУ - АО систем, определенный специально для поддержки функций АУ систем (например, журнал регистрации, администратор).

3.6.14 Администратор - пользователь УИА, который в конкретном взаимодействии АО систем выполняет роль администратора.

3.6.15 Роль администратора - роль, выполняемая пользователем УИА, в которой он способен выдавать операции АУ или принимать уведомления.

3.6.16 Администрирующая (открытая) система - реальная открытая система, содержащая пользователя УИА, который может выполнять роль администратора.

3.6.17 Пользователь УИА - прикладная программа или прикладной процесс, использующий услуги АУ систем.

3.6.18 Уведомление - информация, выдаваемая АО, относительно события, которое произошло в АО.

3.6.19 Тип уведомления - поименованный тип данных, определяющий конкретный вид уведомления.

3.6.20 АО (N)-уровня - АО, специфичный для (N)-уровня.

3.6.21 Протокол АУ (N)-уровня - протокол (N)-уровня, предназначенный для обмена информацией АУ (N)-уровня и обеспечиваемый только уровнями (N-1) и ниже.

Примечание - Настоящий стандарт не определяет и не требует использования протоколов АУ (N)-уровня. Это определение включено сюда в целях полноты.

3.6.22 Операция (АУ систем) - операция над АО для активизации АУ систем.

3.6.23 Администрируемый объект систем - АО, относящийся к нескольким уровням, к системе в целом или к конкретным функциям АУ.

3.6.24 Прикладной процесс АО систем - прикладной процесс, участвующий в АУ систем.

3.6.25 Сервисный элемент прикладного уровня АУ систем - СЭП, предоставляющий услуги АУ систем.

3.6.26 Функция АУ систем - часть действий АУ систем, которая удовлетворяет набору логически связанных требований пользователя.

3.6.27 Функциональная область АУ систем - категория требований пользователя АУ систем.

3.6.28 Функциональный блок АУ систем - поименованный непустой набор услуг АУ систем, определенный для цепей идентифицированных конкретных наборов функциональных возможностей, где существует требование установления или согласования использования таких функциональных возможностей между оконечными системами или для целей ссылок со стороны других стандартов.

3.6.29 Пакет функциональных блоков АУ систем - поименованный непустой набор ФБАУС систем, определенный для согласования функциональных блоков в ассоциации.

3.6.30 Протокол (прикладного уровня) АУ систем - протокол прикладного уровня, обеспечивающий услуги АУ систем.

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

4 Сокращения

5 Административное управление систем

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

В частности, АУ систем применимо к следующим областям, хотя и не ограничивается ими (например, реальным применением АУ систем считается также протокол TMN по рекомендации М.30 МККТТ):

- уровень 1 ВОС (выделенные линии, арендованные линии, спутниковые каналы);

- уровень 2 ВОС (ЛВС, ГВС и др.);

- уровень 3 ВОС (СДОП КК, СДОП КП, ЦСИС, ЦСИС-В, подсети по Х.300 МККТТ и др.);

- уровень 4 ВОС (логические объекты транспортного уровня);

- уровень 5 ВОС (логические объекты сеансового уровня);

- уровень 6 ВОС (логические объекты уровня представления);

- уровень 7 ВОС (COC/MOTIS, ПДУФ, ВТ, ОТ, справочник).

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


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

Существуют три основные группы стандартов по АУ систем:

a) набор стандартов, определяющих функции АУ систем;

b) набор стандартов, относящихся к спецификации АО;

c) набор стандартов по протоколам и услугам прикладного уровня для обмена информацией, относящейся к функциям АУ.

Требования, которым должны удовлетворять действия АУ систем, могут быть сгруппированы в пять областей, каждая из которых требует одного или нескольких стандартов, охватывающих одну или несколько функций. К этим областям, определенным в ГОСТ Р ИСО/МЭК 7498-4, относятся:

- АУ неисправностями;

- АУ конфигурацией;

- АУ учетом;

- АУ производительностью;

- АУ защитой информации.

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

По этим причинам стандарты по АУ систем формируют тесно взаимоувязанный набор стандартов.

6 Модель административного управления систем

6.1 Введение

В этом разделе идентифицируется множество концепций АУ систем и предусматривается модель, поясняющая эти концепции и взаимоотношения между ними.

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

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

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

Рисунок 1 - Взаимодействие АУ систем

Рисунок 1 - Взаимодействие АУ систем

Действия АУ осуществляются через манипулирование АО. Для целей АУ систем прикладные процессы АУ рассматриваются как пользователи УИА. Каждое взаимодействие происходит между пользователями УИА, один из которых выполняет роль администратора, другой - агента.

Пользователь УИА, выполняющий роль агента, - это часть распределенного прикладного процесса, который управляет администрируемым объектом в ФС своей локальной системы. Агент выполняет операции АУ над АО в виде последовательности операций взаимосвязи с администратором. Агент может также продвигать к администратору уведомления, выдаваемые АО.

Пользователь УИА, выполняющий роль администратора, - это часть распределенного прикладного процесса, которая несет ответственность за одно или несколько действий АУ, выдавая операции АУ и принимая уведомления.

Концепция администратора не ограничена прикладными процессами, участвующими только в АУ систем; другие прикладные процессы, нуждающиеся в доступе к информации АУ, могут использовать услуги информации АУ.

Указанные роли присваиваются агентам УИА не на постоянной основе. Функции некоторых пользователей УИА могут быть ограничены только ролью агента, других - только ролью администратора, тогда как третьи могут выполнять роль агента в одном сеансе взаимодействия и роль администратора в другом сеансе взаимодействия.

Примечания

1 Если взаимодействие АУ между открытыми системами касается нескольких АО, то спецификация способа, которым агент распределяет операции АУ среди своих АО, не является предметом стандартизации.

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

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

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

Примечание - На рисунке 2 представлен конкретный способ рассмотрения некоторых аспектов модели АУ систем, и он приведен только в информационных целях. Этот рисунок оказался полезным при разработке настоящей спецификации. В частности, он позволил провести различие между преобразованиями в стандартный обмен данными (согласно правилам подраздела 6.2) и локальными преобразователями и показал, что способ рассмотрения реальной информации АУ в понятиях модели должен быть представлен в рамках прикладного процесса АУ систем. Кроме того, этот способ представлен в локальной ФС, и поэтому он является локальным вопросом и не входит в предмет стандартизации.


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

Рисунок 2 - Взаимоотношение между информационными аспектами и аспектами обмена данными ВОС

Рисунок 2 - Взаимоотношение между информационными аспектами
и аспектами обмена данными ВОС

6.2 Информационные аспекты

Этот подраздел представляет собой введение в информационные аспекты модели АУ систем. Определяющая спецификация информационной модели приведена в ИСО/МЭК 10165-1. В ней уточняются концепции АО, приведенные в ГОСТ Р ИСО/МЭК 7498-4. Рассматриваются их атрибуты, операции АУ над этими атрибутами и уведомления, которые эти операции могут порождать. Набор АО в системе в сочетании с их атрибутами образует базу информации административного управления (БИА) системы.

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

6.2.1 Администрируемые объекты

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

АО могут быть специфичны для отдельного уровня, и в этом случае они называются "АО (N)-уровня". Те АО, которые относятся к нескольким уровням, к конкретной функции АО систем (объект, поддерживающий АУ) или к системе в целом, называются "АО систем".

6.2.2 Атрибуты

Атрибут - это свойство АО. Атрибут имеет значение, которое может иметь простую или сложную структуру.

6.2.3 Операции АУ и уведомления

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

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

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

6.3 Функциональные аспекты

В этом подразделе описываются функциональные аспекты АУ систем.

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

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

Функции АУ могут быть объединены для выполнения конкретных действий АУ.

Поскольку не все услуги необходимы постоянно в данной ассоциации, услуги функций АУ систем могут быть сгруппированы в один или несколько ФБ, которые являются базовыми блоками согласования между пользователями УИА. Кроме того, могут быть определены функциональные блоки, охватывающие услуги нескольких функций.

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

a) только уведомления;

b) только операции АУ;

c) уведомления и операции АУ.

Примечание - Чтобы обеспечить согласование этих возможностей, определены другие ФБ (например, монитор, управление).


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

6.4 Аспекты обмена данными ВОС

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

Общие услуги обмена данными для АУ систем представляют собой "общий сервис информации АУ" (ОСИА). В 6.4.1 описан способ использования ОСИА для поддержки обмена данными, касающегося операций и уведомлений АУ относительно АО администрируемой системы. В 6.4.2-6.4.5 поясняется, каким образом поддержка обмена данными вписывается в структуру прикладного уровня.

Пользователи УИА могут использовать и другие услуги ВОС (например, услуги обработки транзакций (ОТ) или передачи файлов, доступа к файлам и управления файлами (ПДУФ), которые могут обеспечивать или не обеспечивать распознавание ролей администратор/агент, однако сами пользователи УИА должны обеспечивать такое распознавание.

Примечание - Пользователи УИА могут использовать и другие услуги.

6.4.1 Поддержка операций и уведомлений АУ

Существуют два аспекта поддержки операций и уведомлений АУ со стороны обмена данными:

a) поддержка передачи запросов для операций и уведомлений АУ между пользователями УИА;

b) поддержка управления доступом к АО и внешнего распространения информации уведомлений.

Эти основные компоненты представлены на рисунке 3.

Рисунок 3 - Обеспечение обмена данными для уведомлений и операций АУ

Рисунок 3 - Обеспечение обмена данными для уведомлений
и операций АУ

Услуги АУ систем имеют примитивы для передачи запросов на выполнение различных видов операций АУ, определенных в ИСО/МЭК 10165-1, и примитивы для передачи информации уведомлений. Таким способом услуги АУ систем отображают обмен, определенный на границе АО. Услуги АУ систем обеспечивают дополнительную поддержку при выборе соответствующих АО путем создания областей видимости и фильтрации.

Способ преобразования услуг АО систем в услуги ОСИА определяется в ИСО/МЭК 10164-1.

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

Механизмы управления доступом могут отклонять запросы на операции АУ, поступающие от определенных администраторов в выбранные АО.

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

6.4.2 Логический объект прикладного уровня АУ систем

Логический объект прикладного уровня АУ систем (ЛОПАС) состоит из сервисного элемента прикладного уровня АУ систем (СЭПАС) и сервисного элемента управления ассоциацией (СЭУА) (ГОСТ Р 34.981). Другие СЭП, необходимые в ЛОПАС, описаны ниже.

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

Рисунок 4 - Административное управление и прикладной уровень

Рисунок 4 - Административное управление и прикладной уровень

СЭПАС определяет семантику и абстрактный синтаксис передаваемой информации, относящейся к АУ ВОС в ПБД прикладного уровня АУ (ПБДПА). ПБДПА представляет собой протокольную реализацию абстрактного понятия операций и уведомлений АУ, обмениваемых между ЛОПАС (см. 6.1). Для каждого определенного ПБДПА определено также преобразование в поддерживающие услуги.

Услуги, предоставляемые СЭПАС, могут быть подразделены на группы с целью согласования используемых ФБ. СЭПАС определяет информацию АУ, подлежащую обмену между ЛОПАС. Услуги обмена данными, используемые СЭПАС, могут быть обеспечены ОСЭИА или другими СЭП, например, ПДУФ (ГОСТ Р 34.981) или ОТ (ИСО/МЭК 10026-1). Использование ОСЭИА предполагает также наличие сервисного элемента удаленных операций (СЭУО) (ГОСТ Р ИСО/МЭК 9072-1). ОСЭИА определяет услуги и процедуры передачи общих протокольных блоков данных информации АУ. СЭОИА обеспечивает средства обмена информацией в операциях и уведомлениях АУ для целей АУ общими способами. Для обмена информацией АУ могут использоваться и другие СЭП.

6.4.3 Прикладной контекст

Два ЛОПАС устанавливают ассоциацию путем согласования прикладного контекста, который идентифицирует начальные коллективно используемые сведения для данной ассоциации, включая различные используемые СЭП.

Для целей АУ систем в приложении А настоящего стандарта прикладному контексту АУ систем присвоено имя. Этот прикладной контекст предназначен для использования в тех случаях, где используется только АУ систем. В будущем могут быть присвоены другие имена в предположении использования различного набора СЭП.

6.4.4 Коллективно используемые сведения АУ

Примечание - В этом подразделе описываются те аспекты модели, которые носят информационный характер.


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

К сведениям относительно АУ для обмена данными АУ систем относится следующая информация (но не только):

- сведения о протоколе (например, прикладной контекст);

- сведения о функциях (например, функции и функциональные);

- сведения о АО (например, классы, экземпляры и идентификация АО и их атрибутов);

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

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

Рисунок 5 - Представления коллективного использования сведений АУ

Рисунок 5 - Представления коллективного использования сведений АУ

Коллективно используемые сведения АУ относятся к общим сведениям двух систем, т.е. к коллективно используемой схеме АУ.

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

Сведения АУ могут быть введены в любое время, в частности:

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

- в фазе установления ассоциации;

- в последующем в течение времени существования ассоциации.

Априорные сведения по обеспечению обмена данными АУ служат примером получения сведений АУ.

Должна быть предусмотрена возможность во время установления ассоциации устанавливать или модифицировать сведения АУ.

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

(Использование такого механизма администраторами можно рассматривать как факультативное).

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

6.4.5 Использование обеспечиваемых услуг

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

6.5 Организационные аспекты

Организационные аспекты модели описывают распределенный характер АУ ВОС. Многие концепции, относящиеся к организационным аспектам АУ систем (например, роли администратора, агента) были введены ранее (см. 6.1). В этом подразделе определены дальнейшие организационные аспекты.

6.5.1 Регионы административного управления

Примечание - Описываемые в этом подразделе организационные аспекты носят информационный характер.


К организационным требованиям по управлению совокупностью АО относятся:

- разделение функциональной среды АУ ВОС на множество функциональных целей (или "стратегий"), таких как защита информации, учет, АУ неисправностями и др., или ее разделение по другим признакам АУ, например, в соответствии с географической, технологической или организационной структурой;

- временное присвоение и, возможно, модификация ролей администратора и агента для каждой из целей в совокупности АО;

- анализ форм управления (например, стратегия защиты) совместимым образом.

Если АО организованы в наборы, удовлетворяющие указанным требованиям, эти наборы называются регионами административного управления (РАУ). Концепции РАУ показаны на рис.6.

Рисунок 6 - Концепция регионов административного управления

Рисунок 6 - Концепция регионов административного управления

При использовании для целей АУ систем РАУ могут быть представлены администрируемыми объектами. РАУ характеризуется, по меньшей мере, следующими свойствами:

- имя, которое однозначно идентифицирует данный РАУ;

- идентификация совокупности АО, которые являются членами региона;

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

РАУ могут перекрываться друг с другом. Если РАУ, созданные для одной и той же цели, перекрываются, могут быть применимы специальные условия.

6.5.2 Администрирование РАУ

Помимо организационных, существуют административные требования. К ним относятся:

- установление и поддержание соответствующих уполномоченных каждого РАУ по модификации их границ и по организации способа взаимного перекрытия некоторых РАУ;

- управление передачей управляющей информации от одного РАУ к другому.

Для удовлетворения перечисленных требований определен специальный вид РАУ, называемый административным регионом (АР). АР - это такой РАУ, в котором за все АО ответственность несет только один административный уполномоченный.

В качестве административного уполномоченного АР может быть администрация (администрация сети связи общего пользования или другая организация, предоставляющая услуги обмена данными), либо частная организация. Соответствующая организация может выбрать использование или неиспользование АУ систем для управления АО и теми РАУ, которые целиком расположены в пределах своего АР.

Следовательно, концепция РАУ не является предметом стандартизации. Однако взаимодействия, относящиеся к РАУ, могут быть стандартизованы.

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

7 Стандарты по административному управлению систем

Модель, дающая вводное представление о концепции АУ систем, приведена в разделе 6. В данном разделе описываются различные стандарты, а также их взаимоотношения друг с другом и с моделью раздела 6. Эти взаимоотношения показаны на рисунке 7. На нем показаны также другие стандарты, содержащие конкретную информацию АУ, и их отношение к стандартам по АУ систем.

Рисунок 7 - Взаимоотношения между стандартами

Рисунок 7 - Взаимоотношения между стандартами

Стандарты, относящиеся к АУ систем, могут быть подразделены на следующие категории:

- стандарты, определяющие структуру;

- стандарты по обмену информацией АУ;

- стандарты, относящиеся к информации АУ;

- стандарты по функциям АУ систем.

7.1 Архитектура и структура

ГОСТ Р ИСО/МЭК 7498-4 обеспечивает основы для скоординированной разработки стандартов по АУ ВОС, определив терминологию, структуру и действия АУ ВОС.

Как указано в разделе 1, настоящий стандарт содержит общее описание АУ систем ВОС.

Руководство по АУ систем содержит информационное введение в АУ систем, а также дает обоснование и определяет требования, положенные в основу разработки совокупности стандартов по АУ систем.

7.2 Обмен информацией АУ

ГОСТ Р ИСО/МЭК 9595 определяет СЭП (ОСЭИА), который может использоваться прикладным процессом (в централизованной или децентрализованной конфигурации АУ) для обмена информацией в операциях и уведомлениях АУ для целей АУ систем.

ГОСТ Р ИСО/МЭК 9595 определяет набор примитивов услуг (образующих СЭП), соответствующие параметры и необходимую информацию для семантического описания каждого примитива услуг. Примитивы услуг ОСИА переносят запросы на выполнение операций АУ, обусловливают выполнение операций АУ и выдачу отчетов об ошибках между открытыми системами в соответствии с операциями и уведомлениями, определенными в модели информации АУ.

ИСО/МЭК 9596-1 определяет протокол, обеспечивающий ОСИА. Он используется ЛОП для обмена информацией АУ.

ИСО/МЭК 9596-1 определяет процедуры передачи информации АУ между ЛОП, абстрактный синтаксис ОПИА, процедуры правильной интерпретации протокольной управляющей информации и требования соответствия реализации.

В случае специальных потребностей дополнительно к обмену информацией АУ могут использоваться другие СЭП (например, ОТ или ПДУФ).

7.3 Структура информации АУ

Стандарты по информации АУ подразделяются на две группы: определяющие классы АО и обеспечивающие их определения. Большинство определений классов АО могут быть определены в ИСО группами по отдельным уровням или взаимосвязанными организациями; однако некоторые АО требуются для обеспечения самого АУ ВОС. Конкретными примерами служат АО, представляющие события по продвижению дискриминаторов и журналы регистрации АУ. Стандарты по таким АО составляют часть стандартов по АУ систем.

К стандартам, содержащим руководства по способам определения классов АО, относятся:

ИСО/МЭК 10165-1, определяющий модель АО, включая их атрибуты, операции АУ над этими объектами, выдаваемые этими АО уведомления и соответствующие схемы присвоения имен таким образом, что АО и их атрибуты могут быть идентифицированы в протоколе.

ИСО/МЭК 10165-2, определяющий системные АО и шаблоны, которые могут быть введены во множество различных определений классов АО для поддержки совместимости определений атрибутов, уведомлений и операций АУ, включая их параметры;

ИСО/МЭК 10165-4, который содержит руководящие материалы, методы и нотацию, спецификацию классов АО и другую информацию АУ.

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

7.4 Функции АУ систем

Стандарты, относящиеся к функциям АУ систем, содержат один или несколько следующих компонентов.

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

К этим компонентам относятся:

1) требования пользователей;

2) модели, которые устанавливают взаимоотношения услуг АУ систем с требованиями пользователя;

3) определение услуг, которое содержит перечень необходимых услуг АУ систем и их семантики;

4) спецификация протокола, которая определяет преобразование услуг АО систем и их параметров в нижерасположенные услуги;

5) определение взаимоотношений между услугами АУ систем, с одной стороны, и операциями и уведомлениями АУ "структуры информации административного управления" (СИА);

6) взаимоотношения с другими функциями АУ систем;

7) требования к соответствию.

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

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

АО, атрибуты, операции и уведомления АУ систем, требуемые стандартами, которые содержат этот компонент, доступны для использования в услугах прохождения, определенных в ИСО/МЭК 10164-1.

Эти компоненты состоят из:

1) требований пользователя;

2) моделей, которые устанавливают взаимоотношения родовых определений с требованиями пользователя;

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

Примечание - Родовые определения, требуемые этими функциями, задокументированы в соответствии с руководящими правилами по определению АО, а также в документах СИА, которые содержат родовые определения (см. 7.3).

c) Определение ФБАС. Стандарты, содержащие такие компоненты, идентифицируют конкретные наборы услуг АУ систем, где существует требование к наличию сведений об использовании таких функций по ассоциации в виде части сведений об АУ. Отдельный ФБ может содержать услуги, определенные в нескольких стандартах, и описывать использование услуг в сочетании с классами АО.

Этот компонент состоит из:

1) требований пользователя;

2) моделей, устанавливающих взаимоотношения ФБАУС с требованиями пользователя;

3) перечня услуг АУ систем, требуемых функциональным блоком, наряду с любыми ограничениями, налагаемыми на класс АО и связанными с любой из этих услуг, относящихся к ФБ;

4) определений ФБ;

5) абстрактного синтаксиса, необходимого для идентификации ФБ в протоколе;

6) описаний любых взаимоотношений между ФБ;

7) описаний любых взаимоотношений между ФБАС и функциями АУ систем;

8) требований к соответствию.

Каждый из этих компонентов может быть представлен в единственном числе в стандарте по функциям АУ систем. Эти компоненты могут также объединяться любым способом, за исключением того, что компоненты "родовое определение" и "функциональный блок" не могут быть объединены без ссылки на компонент определения услуги или включения в этот компонент.

8 Соответствие и согласованность

В данном разделе устанавливаются:

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

- требования согласованности для систем, заявляющих о своем соответствии АУ систем;

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

8.1 Согласованность с настоящим стандартом

8.1.1 Введение

В разделе 7 определены три категории стандартов по АУ систем:

- стандарты по обмену информацией АУ;

- стандарты, относящиеся к информации АУ;

- стандарты, относящиеся к функциям АУ систем.

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

Стандарты по обмену данными и стандарты, относящиеся к функциям АУ систем, должны идентифицировать два класса заявок о соответствии: общее соответствие и зависимое соответствие.

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

8.1.2 Требования к стандартам по обмену данными

Стандарты, определяющие протоколы по обмену информацией АУ, должны устанавливать требования статического и динамического соответствия протоколу и обеспечивать форму ЗСРП, идентифицирующую всю информацию, которая должна быть предусмотрена в заявке на соответствие. Эти стандарты должны устанавливать, чтобы в качестве минимальных требований к соответствию АУ систем требовалась поддержка базовых правил кодирования АСН.1 (ГОСТ Р ИСО/МЭК 8825) для абстрактного синтаксиса, определенного для АУ систем.

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

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

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

b) поддержка элементов процедуры, соответствие которым заявлено.

8.1.3 Требования к стандартам по информации АУ

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

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

Должно быть установлено определенное соотношение между поведением ресурса, наблюдаемого на границе АО, и поведением ресурса, наблюдаемого на другой границе, определенной стандартами ВОС. Только в том случае, если такое соотношение определено, его характер должен констатироваться как часть определения класса АО. Такое определяемое соотношение является предметом заявки со стороны поставщика, где должно описываться, каким образом это соотношение представлено в конкретной реализации, с констатацией ограничений реализации (например, максимальная задержка между действием АУ и его влияние на другое наблюдаемое поведение или наоборот). Эта заявка должна быть определена в ЗСАО или в документах, на которые ссылается ЗСАО.

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

Наличие в стандарте требований к соответствию не обязательно предполагает тестируемость требований.

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

8.1.4 Требования к стандартам по функциям АУ

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

Стандарты, содержащие родовые определения, должны устанавливать требования согласованности, предъявляемые к стандартам по АО или другим стандартам, использующим содержащиеся в них определения.

Стандарты, определяющие ФБАС, должны устанавливать требования соответствия, относящиеся к поддержке каждого функционального блока, и содержать форму ЗСРП, которая должна быть предусмотрена в заявке на соответствие.

В случаях, когда стандарт по функциям определяет использование объекта АУ, этот стандарт должен установить требования соответствия для данного АО в форме ЗСАО.

Стандарт по функциям АУ систем должен определять преобразования в соответствующие услуги.

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


Для стандартов по функциям АУ систем должны быть определены два класса заявок о соответствии: общее и зависимое соответствия.

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

Заявка о зависимом соответствии должна отражать тот факт, что система удовлетворяет стандарту по функциям для передачи информации АУ, которая

a) определена в АО, обеспечение которых заявлено системой, и

b) идентифицирована как используемая рассматриваемой функцией АУ систем для передачи.

8.1.5 Руководство по составлению заявок о соответствии АУ систем

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

a) набор обеспечиваемых прикладных контекстов АУ систем. В этот набор должен входить как минимум прикладной контекст АУ систем, определенный в приложении А к настоящему стандарту;

b) набор протоколов информации АУ (например, ОПИА), обеспечение которых системой заявлено, в форме ЗСРП для каждого протокола и в формате, требуемом стандартом по протоколу. В обеспечение этого набора протоколов должно входить обеспечение базовых правил кодирования АСН.1 (ГОСТ Р ИСО/МЭК 8825) для абстрактных синтаксисов, определенных для АУ систем. В этот набор протоколов должны входить:

1) все протоколы, необходимые для поддержки всех функциональных блоков АУ систем, обеспечение которых заявлено;

2) все протоколы, необходимые для поддержки прикладного(ых) контекста(ов), обеспечение которых заявлено;

3) все протоколы, необходимые для поддержки операций и уведомлений АУ, определенных набором классов АО, обеспечение которых заявлено;

c) набор функций АУ систем (которые могут быть выражены в понятиях ФБАС), обеспечение которых системой заявлено, в форме ЗСРП для каждой функции и в формате, установленном стандартом по функциям.

d) набор классов АО, обеспечение которых системой заявлено, в форме ЗСАО для каждого класса АО и в формате, установленном стандартом по классу АО. В этот набор классов АО должны входить классы, необходимые для поддержки тех ФБАС, обеспечение которых заявлено.

8.2 Соответствие настоящему стандарту

Единственные требования соответствия, определенные настоящим стандартом, - это требования, относящиеся к прикладному контексту для АУ систем, определенного в приложении А.

ПРИЛОЖЕНИЕ А (обязательное). Прикладной контекст для административного управления систем

ПРИЛОЖЕНИЕ А
(обязательное)

А.1 Обоснования

В данном приложении описывается прикладной контекст, доступный для ассоциаций в функциональной среде АУ систем.

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

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

А.2 Прикладной контекст АУ

А.2.1 СЭП

Данный прикладной контекст состоит из следующих СЭП и установленных взаимоотношений: СЭУА, СЭУО, ОСЭИА и СЭПАС.

СЭПАС предоставляет услуги пользователю ЛОПАС. ЛОПАС использует услуги ОСЭИА, который, в свою очередь, использует услуги СЭУО. ФУОА предоставляет услуги ассоциации АУ для ЛОПАС и использует СЭУА.

СЭПАС, ОСЭИА и СЭУО совместно используют один абстрактный синтаксис. Этот абстрактный синтаксис определен в ИСО/МЭК 9596-1.

А.2.2 Элементы процедуры

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

В данном прикладном контексте может быть предпринята попытка любого взаимодействия, однако такая попытка использования взаимодействия, не поддержанная обеими системами АУ, может привести к ошибке. При попытке неподдержанного взаимодействия должны использоваться следующие значения ошибок согласно ГОСТ Р ИСО/МЭК 9595 для уведомления о безуспешности взаимодействия:

- "нераспознаваемая операция; операция не относится к согласованным между пользователями услуг СЭПАС", если предпринималась попытка выполнения операции;

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

Другие элементы процедуры определены в A.3.

А.2.3 Имя прикладного контекста

Имя данного прикладного контекста должно иметь следующее значение идентифицированного объекта:

{совместная-исо-мкктт-сау(9) аос(О) прикладной контекст (О) АУ систем (2)}

и следующее значение дескриптора объекта:

"Прикладной контекст АУ систем"

А.2.4 Использование СЭУА

Определенный в ГОСТ Р 34.982 параметр "информация-ассоциации" должен представлять собой последовательность данных ВНЕШНИЕ, предоставляемых для ОСЭИА согласно ИСО/МЭК 9596-1, за которыми следуют данные, обеспечиваемые СЭПАС.

Данные ВНЕШНИЕ, обеспечиваемые СЭПАС, представляют собой тип данных АСН.1 "данные пользователя СЭПАС", как определено в А.3.4 настоящего стандарта.

Параметр "режим", определенный в ГОСТ Р 34.981, должен иметь значение "нормальный".

А.3 Правила установления ассоциации

Определенные в приложении А к ИСО/МЗК 9596-1 правила установления ассоциации для ОСЭИА применимы к прикладному контексту, определенному в настоящем стандарте.

А.3.1 Согласование прикладного контекста

Инициатор ассоциации использует имя прикладного контекста АУ систем для того, чтобы предложить установление ассоциации с прикладным контекстом АУ систем.

Если ответчик воспринимает ассоциацию и отвечает тем же именем прикладного контекста, то ассоциация устанавливается с прикладным контекстом АУ систем.

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

Если ответчик отклоняет запрос на ассоциацию, прикладная ассоциация устанавливается в соответствии с правилами, определенными в ГОСТ Р 34.982.

А.3.2 Согласование функциональных блоков

При согласовании функционального блока ОСЭИА должны соблюдаться правила согласования, определенные в ИСО/МЭК 9596-1.

Согласование ФБАУС является факультативным. Согласованный начальный набор ФБАУС может быть определен при установлении ассоциации путем использования параметра "пакеты баус", определенного в А.3.3 и А.3.4. Если набор ФБАУС согласован, то ассоциация будет ограничиваться согласованным набором ФБ до тех пор, пока не будет достигнуто новое соглашение. Допускаются только операции и уведомления в согласованном наборе для использования в ассоциации.

Примечание - Определение механизма модификации согласованного набора ФБАУС во время действия ассоциации является предметом дальнейшего изучения.


Набор ФБАУС идентифицируется путем спецификации параметра "пакетыфбаус", в котором все биты соответствуют элементам набора ФБАУС, установленным в значение 1. Опущенные концевые биты в СТРОКЕ БИТОВ должны рассматриваться как нулевые.

Для согласования набора ФБАУС инициатор ассоциации должен предложить действительный непустой набор ФБАУС. Для согласования ответчик должен выдать в ответ действительный набор ФБАУС, который либо идентичен предложенному набору, либо является его подмножеством. Чтобы отклонить согласование, ответчик должен выдать ответ с отсутствующим параметром "пакетыфбаус".

Если инициатором не предложен ни один из наборов ФБАУС (в запросе отсутствует параметр "пакетыфбаус"), ответчик должен выдать ответ с отсутствующим параметром "пакетыфбаус" или отклонить ассоциацию.

Если согласование ФБАУС принято, то набор ФБАУС, определенный в ответе, будет представлять собой согласованный начальный набор ФБАУС для данной ассоциации. Если ассоциация успешно установлена, но согласование ФБАУС оказалось безуспешным, правила использования ассоциации определяются только согласованным прикладным контекстом, как указано в А.2.2.

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


Подпараметры ФБВРолиАдминистратора и ФБВРолиАгента параметра "пакетыфбаус" используются для того, чтобы определить, в какой роли предусмотрен конкретный ФБАУС - администратора, агента, либо в той и другой. Это позволяет свести согласование ФБ только к роли агента или администратора АУ систем.

Как только набор ФБАУС будет согласован, на АУ систем возлагается ответственность за обеспечение любых требований и/или ограничений, согласованных для данной ассоциации. Если конкретные ФБАУС согласованы, то любые попытки осуществить взаимодействия вне границ согласованных ФБАУС приведут к ошибке.

А.3.3 Руководства по определению пакетов ФБ

Пакет ФБ - это непустой набор ФБ, предназначенный дня целей согласования ФБ в ассоциации.

Определения пакета ФБ требуют присвоения значения идентификатору объекта. Это значение используется для идентификации пакета ФБ во время согласования ассоциации с использованием абстрактного синтаксиса, определенного в А.3.4.

Более того, определение пакета ФБ должно назначать по одной уникальной битовой позиции для каждого ФБ, определенного в пакете ФБ. Эта битовая позиция используется для идентификации битов, установленных в СТРОКЕ БИТОВ ФБВРолиАдминистратора, или в СТРОКЕ БИТОВ ФБВРолиАгента, или в той и другой для указания ФБ, предложенных для согласования.

ПРИМЕР

"Настоящий стандарт присвоил следующее значение объектного идентификатора

{совместная-исо-мкктт аус (9) функция (2) часть X (X) пакет ФБ (1)}

в качестве значения идПакетаФБ типа АСН.1, определенных в настоящем стандарте для использования согласования следующего (их) ФБ:

0 ФБ А

1 ФБ В
.
.
.

n ФБ Z,

где цифры указывают битовую позицию, присвоенную ФБ, а наименование указывает ФБ согласно разделу X настоящего стандарта.

А.3.4 Определение абстрактного синтаксиса для СЭПАС

Настоящий стандарт присвоил значение объектного идентификатора АСН.1

{совместное-исо-мкктт аус (9) аос (О) согласованиеАбстрактногоСинтаксиса(1) версия 1(1)},

в качестве имени абстрактного синтаксиса для набора всех значений данных уровня представления, каждое из которых является значением типа АСН.1.

СЭПАС-Пк-АССОЦИАЦИЯ-Информация.СЭПАСДанныеПользователя

Протокол СЭУА (ГОСТ Р 34.982) описан с использованием АСН.1. "Информация пользователя" определяется с использованием типа данных ВНЕШНИЕ. Информация пользователя СЭПАС, которая должна передаваться в П-АССОЦИАЦИИ в отдельном поле ВНЕШНИЕ параметра "информация пользователя", определяется следующим образом.

СЭПАС-Пк-АССОЦИАЦИЯ-Информация {совместное-исо-мкктт аус(9) аос (О) асн1Модули(2)

определенияСогласований(0)

версия1(1)

ОПРЕДЕЛЕНИЯ :: = BEGIN

данныеПользователяСЭПАС :: = SEQUENCE {"пакетыфбаус" SET OF

Пакет ФБ ФАКУЛЬТАТИВНО

- должен иметь место в примитивах запроса/индикации, если

- предложено согласование ФБАУС, и в примитивах ответа/подт-

- верждения, если согласование ФБАУС принято, в противном

- случае этот параметр должен отсутствовать.

причина Причина ФАКУЛЬТАТИВНО,

- может иметь место только в примитивах П-АССОЦИАЦИЯ от-

- вет/подтверждение. Если согласование ФБАУС безуспешно или

- если согласование ФБАУС приводит к уменьшению предложенного

- набора ФБАУС, или если запрос ассоциации отклонен, в этом

- параметре может указываться конкретная причина такой ситуа-

- ции.

информацияПолъзователяАУСистем СтрокаГрафическихЗнаков

ФАКУЛЬТАТИВНО

- Этот параметр предусмотрен исключительно для реализации при

- различении различных функциональных сред реализации и он не

- должен быть предметом аттестационного тестирования.

}

Причина :: = INTEGER {

фбаусНеОбеспечены (О),

- один или несколько запрошенных ФБАУС не обеспечены

комбинация фбаусНеОбеспечена (1),

- отдельные ФБАУС обеспечены, но не в предложенной комбинации

- по отдельной ассоциации

требуемые фбаусНедоступны (2),

- один или несколько требуемых ФБАУС не были согласованы

согласованные фбаусОтклонены (3)

- ответчик отказывается согласовывать ФБАУС без явного объяснения, почему.

}

Пакет ФБ :: = SEQUENCE {

идПакетаФБ, ФБВРолиАдминистратора [О] НЕЯВНАЯ СТРОКА БИТОВ ПО УМОЛЧАНИЮ {}

- при отсутствии предполагается роль, необеспеченная для

- этого пакета ФБ.

ФБВРолиАгента [1] НЕЯВНАЯ СТРОКА БИТОВ ПО УМОЛЧАНИЮ {}

- при отсутствии предполагается роль, необеспеченная для

- этого пакета ФБ.

}

идПакетаФБ: = OBJECT IDENTIFIERP

END.

А.3.5 Минимальное обеспечение обмена данными

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

- соединение уровня представления, использующее только ФБ "ядро" без каких-либо элементов услуг АУ контекста;

- двунаправленное одновременное сеансовое соединение без элемента услуг срочной передачи или синхронизации.

А.4 Соответствие

Открытая система, претендующая на соответствие прикладного контекста АУ систем, должна отвечать требованиям к статическому и динамическому соответствию, установленным в А.4.1 и А.4.2.

А.4.1 Статическое соответствие

Система должна обеспечивать синтаксис передачи, образованный из правил кодирования, определенных в ГОСТ Р ИСО/МЭК 8825, и поименованный {совместное-исо-мкктт асн1(1) базовое-кодирование(1)} набор правил кодирования для целей генерации и/или интерпретации параметра "информация-пользователя" в ПБДТ СЭУА, как определено абстрактным синтаксисом {совместное-исо-мкктт аус(9) аос(О) согласованиеАбстракт-ногоСинтаксиса(1) версия(1)}, определенным в А.3.4.

А.4.2 Динамическое соответствие

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

ПРИЛОЖЕНИЕ В (справочное). Образец заявки о соответствии функций АУ систем

ПРИЛОЖЕНИЕ В
(справочное)

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

В.1 Правила

Правила, которые применяют при заполнении шаблона:

- {} элементы шаблона, требующие определенной модификации контекста;

- [] факультативные элементы шаблона;

- ***комментарий*** используется для уточнения {} или [], когда необходимо описать характер необязательного или замещаемого текста.

В.2 Шаблон

Ниже приводится шаблон для составления раздела "Назначение" для стандартов по АУ систем.

1 Назначение

Данная часть настоящего стандарта

***ЧАСТЬ-ОПРЕДЕЛЕНИЕ УСЛУГ: ***[

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

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

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

- определяет протокол, необходимый для обеспечения услуг;

- определяет взаимоотношения между услугами, с одной стороны, и операциями и уведомлениями информации АУ системы, с другой стороны;

- определяет взаимоотношениями с функциями АУ систем;

- определяет требования к соответствию.

]***Данная часть приводится только в тех стандартах, которые определяют услуги АУ систем***

***ЧАСТЬ-РОДОВЫЕ ОПРЕДЕЛЕНИЯ:***[

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

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

- определяет родовые [классы АО,] [типы атрибутов,] [типы операций АО] [типы порождений,] ***исключить ненужное***, задокументированные в соответствии с руководством по определению АО;

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

]***Может иметь место ОТДЕЛЬНО в отдельном стандарте, но не должна быть в стандарте, который содержит ***ЧАСТЬ-ФУНКЦИОНАЛЬНЫЙ БЛОК***, если только этот стандарт не содержит

***ЧАСТЬ-ОПРЕДЕЛЕНИЕ УСЛУГ***.

***ЧАСТЪ-ФУНКЦИОНАЛЬНЫЙ БЛОК:***[

- устанавливает требования пользователя к ФБ {наименование(ия) ФБ};

- определяет модель, которая устанавливает взаимоотношения между ФБ и требованиями пользователя;

- определяет ФБ и перечень (перечни) услуг АУ систем, требуемые ФБ;

- определяет абстрактный синтаксис, необходимый для идентификации ФБ в протоколе;

- устанавливает взаимоотношения между ФБ {наименования ФБ};

- устанавливает взаимоотношения между ФБ {наименование(ия) ФБ} и конкретными требованиями к соответствию.

]***Может иметь место ОТДЕЛЬНО в отдельном стандарте, но не должно быть в стандарте, который содержит ***ЧАСТЬ-РОДОВЫЕ ОПРЕДЕЛЕНИЯ***, если только этот стандарт не содержит

***ЧАСТЬ-ОПРЕДЕЛЕНИЕ УСЛУГ***.

Настоящий стандарт распространяется на {область распространения, требования пользователей, например "администрируемые состояния...")}.

Библиография

Рекомендация Х.300 МККТТ (1988) Общие принципы взаимодействия между сетями общего пользования, а также между сетями общего пользования и другими сетями для обеспечения служб передачи данных

Рекомендация М.30 МККТТ (1988) Принципы организации сети управления электросвязью

Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 1999