Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

38 страниц

487.00 ₽

Купить официальный бумажный документ с голограммой и синими печатями. подробнее

Официально распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль".

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

Показать даты введения Admin

Страница 1

ГОСТ Р ИСО/МЭК 9594-5-98 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ СПРАВОЧНИК

ЧАСТЬ 5 СПЕЦИФИКАЦИИ ПРОТОКОЛА

Издание официальное

БЗ 3-98/493


ГОССТАНДАРТ РОССИИ Москва

Страница 2

ГОСТ Р ИСО/МЭК 9594-5-98

Предисловие

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

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

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 19 мая 1998 г. № 215

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 9594-5—95 «Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола*

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

© И ПК Издательство стандартов. 1998

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

II

Страница 3

ГОСТ Р ИСО/МЭК 9594-5-98

Содержание

............................. IV

Введение

1    Область применения.......................................... I

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

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

4    Сокращения..........................................................................................2

5    Соглашения.........................................................................3

6    Общее описание протокола..........................................................................3

7    Абстрактный сингаксис протокола справочника....................................................10

8    Преобразование в используемые услуга..............................................................16

9    Соответствие..........................................................................................18

Приложение Л.    Протокол доступа к справочнику в АСН. I ......................................23

Приложение В.    Протокол системы справочника в АСН. 1 .................... 25

Приложение С.    Протокол теневой информации справочника в АСН. I ..........................27

Приложение D. Прогокол административного управления эксплуатационными связями справочника в АСН. I ......................................................................30

Приложение Е. Эталонное определение идентификаторов объектов протокача.........32

Приложение F. Типы эксплуатационных свяэгй справочника......................................33

III

Страница 4

ГОСТ I» ИСО/МЭК 9594-5-98

Введение

Настоящий стандарт разработан с целью обеспечения взаимосвязи систем обработки информации, предназначенных для предоставления услуг справочника. Совокупность подобных систем вместе с содержащейся в них информацией справочника может рассматриваться как единое целое, называемое справочником. Информация, хранимая справочником и называемая в целом «информационной базой справочника» (ИБС), используется обычно для обеспечения обмена данными между такими объектами, как логические объекты прикладного уровня, персонал, терминалы и дистрибутивные списки.

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

-    поставляемых от различных изготовителей;

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

-    имеющих различные уровни сложности;

-    использующих рахаичные технологии.

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

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

В приложении Л приведен модуль ЛСН. 1 для протокола доступа к справочнику, в приложении В — модуль ЛСН.1 для протокола системы справочника, в приложении С — модуль ACH.I для протокола теневой информации справочника, в приложении D — модуль ЛСН.1 для протокола управления эксплуатационными связями справочника, в приложении Е — модуль ЛСН.1, который содержит все идентификаторы объектов ЛСН.1, используемые в настоящем стандарте, и в приложении F — модуль ЛСН.1, который содержит все идентификаторы объектов ЛСН.1, предназначенные для определения типов эксплуатационных связей, используемых в такого типа стандартах.

IV

Страница 5

ГОСТ Р ИСО/МЭК 9594-5-98 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ СПРАВОЧНИК

Ч а е т ь 5 Спецификации протокола

Information technology. Open Systems Interconnection. The directory. Part 5. Protocol specifications

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

1    ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящий стандарт определяет протокол доступа к справочнику, протокол системы справочника. протокол теневой информации справочника и протокол управления эксплуатационными связями справочника, используемые при выполнении абстрактных услуг, определенных в ИСО/МЭК 9594-3. ИСО/МЭК 9594-4 и ИСО/МЭК 9594-9.

2    НОРМАТИВНЫЕ ССЫЛКИ

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

ГОСТ 34.971-91 (ИСО 8822—88) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг уровня представления для режима с установлением соединения

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

ГОСТ Р ИСО/МЭК 7498-1—95 Информационная технология. Взаимосвязь открытых систем (ВОС). Базовая эталонная модель. Часть I. Базовая модель

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

ГОСТ Р ИСО 8326-95 Информационная технология. Взаимосвязь открытых систем. Определение базовых услуг сеансового уровня в режиме с установлением соединения

ЮСТ Р ИСО/МЭК 8348—96 Информационная технология. Взаимосвязь открытых систем. Определение услуг сетевого уровня

['ОСТ Р ИСО/МЭК 8824—93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (ACH.I)

ГОСТ Р ИСО/МЭК 9066-1—93 Системы обработки информации. Передача текста. Надежная передача. Часть 1. Модель и определение услуг

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

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

ГОСТ Р ИСО/МЭК 9594-7—98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 7. Выбранные классы объектов

Издание официальное

I

2-11211

Страница 6

ГОСТ Р ИСО/МЭК 9594-5-98

ИСО/МЭК I1MC 9072-31 Системы обработки информации. Передача текста. Удаленные операции. Часть 3. Реализации ВОС

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

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

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

ГОСТ Р ИСО/МЭК 9594-6—98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 6. Выбранные типы атрибутов

ИСО/МЭК 9594-9—93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 9. Дублирование

3    ОПРЕДЕЛЕНИЯ

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

a)    абстрактный синтаксис;

b)    прикладной контекст;

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

d)    прикладной процесс;

e)    управляющая информации протокола прикладного уровня;

0 протокольный блок данных прикладного уровня;

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

3.2    В настоящем стандарте используются следующие термины, определенные в ГОСТ Р ИСО/МЭК 9072-1:

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

b)    контракт, контракт ассоциации;

c)    ошибка;

d)    операция;

e)    пакет управления операциями;

0 объект-УУО.

3.3    В настоящем стандарте используются следующие термины, определенные в ИСО/МЭК 9594-2:

a)    справочник;

b)    пользователь (справочника);

c)    агент системы справочника;

d)    агент пользователя справочника.

3.4    В настоящем стандарте используются следующие термины, определенные в ИСО/МЭК 9594-4:

a)    сцепление;

b)    обращение.

4    СОКРАЩЕНИЯ

АСС    — агент системы справочника;

АПС    — агент пользователя справочника;

ЛОП    — логический объект прикладного уровня:

11БДП — протокольный блок данных прикладного уровня;

ПДС    — протокол доступа к справочнику:

ПК    — прикладной контекст;

ПСС    — протокол системы справочника;

ГГГИС    — протокол теневой информации справочника;

2

1

Оригиналы стандартов и проектов ИСО/МЭК — во ВНИИКИ Госстандарта России.

Страница 7

ГОСТ Р ИСО/МЭК 9594-5-98

11У ИII — протокольная управляющая информация прикладного уровня;

ПУЭС    — протокол управления эксплуатационными    связями справочника;

СЭП    — сервисный    элемент прикладного уровня;

СЭУА    — сервисный    элемент управления ассоциацией;

СЭУО    — сервисный    элемент удаленных операций;

УУО — услуги удаленных операций.

5    СОГЛАШЕНИЯ

В настоящем стандарте под понятием «спецификация справочник;»* следует понимать ГОСТ I* ИСО/МЭК 9594-5. а под понятием «спецификации справочника» — части 1—9 ГОСТ Р ИСО/МЭК 9594.

Если элементы списков пронумерованы (в отличие от использования знаков дефиса «—♦ или букв), то такие элементы должны рассматриваться как шаги процедуры.

Настоящий стандарт определяет операции справочника, используя нотацию удаленных операций. определенных в ГОСТ Р ИСО/МЭК 9072-Г

6    ОБЩЕЕ ОПИСАНИЕ ПРОТОКОЛА

6.1 Удаленные операции — спецификация и реализация в ВОС

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

Класс ROS-OBJECT-CLASS используется для определения ряда общих возможностей набора объектов-УУО в понятиях контрактов (ассоциации), которые они обеспечивают, выполняя роль отправителей и/или ответчиков. Если объект-УУО реализован с использованием услуг обмена данными в ВОС, то он преобразуется в прикладной процесс, а контракт - в прикладной контекст. В таких спецификациях справочника понятие «абстрактная услуга* используется для обращения к контракту ассоциации УУО, а протокол прикладного уровня ВОС — для обращения к реализации контракта между двумя открытыми системами, использующими услуги обмена данными в ВОС.

Класс OPERATION-РАСKAGE используется для определения набора операций, которые могут быть привлечены объектом-УУО, выполняющим роль «потребителя», либо набора операций, которые могут быть привлечены объектом-УУО. выполняющим роль «поставщика», либо набора операций, которые могут быть привлечены обоими указанными объектами-УУО. При использовании услуг обмена данными ВОС пакет управления операциями реализуется в виде сервисного элемента прикладного уровня (СЭП).

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

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

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

Класс ABSTRACT-SYNTAX, построенный на основе АСН.1, используется для определения и присвоения идентификатора объекта типу АСН.1, значения которого включают абстрактный синтаксис.

3

2*

Страница 8

ГОСТ Р ИСО/МЭК 9594-5-98

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

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

Для надежной передачи протокольных блоков данных прикладного уровня (Г1БДП) в ПТИС факультативно может быть использован сервисный элемент надежной передачи (СЭНГ1).

6.2 Объекты-УУО и контракты справочника

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

Класс *dua* объекта-УУО описывает АПС, который является экземпляром этого класса, в виде инициатора контракта «dapContract*. В таких спецификациях справочника на этот контракт ссылаются как на абстрактную услугу справочника. Класс «dua* определен (см. 6.3) в виде информационного обьекта УУО.

dua    KOS-OBJ ECT-CLASS    ::= (

INITIATES    (dapContract}

ID    id-rosObject-dua}

Класс «directory» объекта-УУО описывает поставщика абстрактных услуг справочника. Этот поставщик является ответчиком «darContract*. directory ROS-OBJECT-CLASS :: = {

RESPONDS    {dapContract}

ID    id-rosObject-directory}

Далее справочник моделируется, как показано на рисунке I, где АПС представлен агентом АСС, который обеспечивает конкретный пункт доступа. ИСО/МЭК 9594-4 определяет взаимодействия между двумя АСС в пределах справочника, чтобы поддерживать сцепленные запросы пользователя.

Объект «directory» представлен в виде набора взаимодействующих АСС. Каждый АСС. включающий «directory*, является элементом класса «dap-dsa*. Объект *dap-dsa» выполняет роль ответчика

в «dapContract».

dap-dsa    ROS-OBJECT-CLASS    ::=    (

RESPONDS    (dapContract}

ID    id-rosObject-dapDSA)

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

П)ок1 доступа

Рисунок 1 — Взаимодействия справочника

В общем случае взаимодействия между АСС, необходимые для обеспечения абстрактных услуг справочника при наличии распределенной ИБС, определены как «dspContract*. АСС. который участвует в этом контракте, определен как объект-УУО класса odsp-dsa».Контракт, на который ссылают-

4

Страница 9

ГОСТ Р ИСО/МЭК 9594-5-98

ся в этих спецификациях справочника, определен как абстрактная услуга ACC. АСС определен в виде информационного объекта УУО (см. 6.4).

dsp-dsa    ROS - OBJ ЕСТ-С LASS    : : = {

BOTH    {dspContracl}

ID    id-rosObject-dspDSA }

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

Объект «ShadowConsumerContract* выражает вид услуги, в который теневой потребитель объект -УУО класса «initiating-consumer-dsa* является инициатором контракта. Объект-УУО класса «responding-supplier-dsa* яатяется ответчиком в этом контакте.

initiating-consumer-dsa    ROS-OBJ ЕСТ-С LASS    :: =    {

INITIATES    {shadowConsuinerContraci}

ID    id-rosObject-initiating ConsumerDSA )

responding-supplier-dsa    ROS-OBJ ECT-C LASS    ::=    {

RES PON DS    {shadowConsumerContract}

ID    id-rosObject-rcspondingSupplierDSA}

Объект «ShadowSuppl ieiContract» выражает форму услуги, в которой теневой поставщик объекта-УУО класса «initiating-supplierdsa* является инициатором контракта. Объект- ROS класса « responding-consumer-dsa* является отвечиком в этом контракте.

initiating-suppIierMsa    ROS-OBJ ЕСТ-С L\SS    :: =    {

INITIATES    {shadowSuppIierContract >

ID    id-rosObject-initiatingSuppIierDSA [

responding-consumerMsa    ROS-OBJ ECT-C LASS    :: = {

RESPONDS    {shadowSuppIierContract}

ID    id-rosObject-respondingConsuinerDSA }

Взаимодействия между двумя ACC для упраатения набором эксплуатационных связей определены как «dopContract*.

dop-dsa    ROS-OBJ ЕСТ-С LASS    ::= {

BOTH    {dopContract}

ID    id-rosObjectMopDSA}

ACC, который участвует в этом контракте, определен как объект-УУО класса «dop-dsa». Этот контракт определен в виде информационного объекта УУО (см. 6.6).

6.3 Кшгтракт и пакеты НДС

«DapContract* определен в виде информационного объекта класса «CONTRACT*. dapContract    CONTRACT :: = {

CONNECTION    dapConnectionPackage

INITIATOR CONSUMER OF {readPackage | search Package

| modify Package}

ID    id-contract-dap }

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

о DapContract* составлен из пакета соединений «dapConnectionPackage* и трех пакетов управления операциями «readPackage*, «searchPackage* и «modifyРасkage*.

Пакет упраатения соединением «dapConnectionPackage* определен как информационный объект класса CONNECTION-PACKAGE. Операции соединения и разъединения этого пакета соединений «directoryBind» и «directoryUnbind* определены в ИСО/МЭК 9594-3.

dapConnectionPackage    CONNECTION-PACKAGE    ::= |

BIND    directory Bind

UNBIND    directoryUnBind

ID    id-package-dapConnection    }

5

Э— 112(1

Страница 10

ГОСТ Р ИСО/МЭК 9594-5-98

Пакеты управления операциями «readPackage*, «searchPackage» и «modifyPackage* определены как информационные объекты класса OPERATION-PACKAGE. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-3.

readPackage    OPERATION-PACKAGE    ::=    {

CONSUMER INVOKES    {read | compare | abandon)

ID    id-package-read }

searchPackage    OPERATION - РАСKAG E    :: =    {

CONSUMER INVOKES    {list |search)

ID    id-package-search    )

modifvPackage    OPERATION-PACKAGE    :: =    «

CONSUMER INVOKES    (addEntry | removeEntry

| modifyEntiy | modifyDN)

ID    id-package-modify)

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

Поскольку АПС является инициатором «dapContract*. он принимает роль потребителя пакетов управления операциями контракта. Это означает, что только ЛИС может привлечь операции и этом контракте и его реализацию ВОС.

6.4 Контракт и пакеты НСС

«dsp Contract* определен как информационный объект класса CONTRACT. dspContract    CONTRACT :: = {

CONNECTION    dspConnectionPackage

OPERATIONS OF    {chainedReadPackage j chainedSearchPackage

| chainedModifyPackage)

ID    id-contractMsp )

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

«DspContract* состоит из пакета управления соединением «dspConnecti-on Package* и трех пакетов управления операциями «chainedReadPackage», «chainesearchPackage* и «chainedModifyPackage».

Пакет управления соединением «dspConnectionPackage» определен как информационный объект класса CONNECTION-PACKAGE. Он    идентичен    пакету' управления соединением

«dapConnectionPackage*.

dspConnectionPackage    CONNECTION-PACKAGE    :: =    \

BIND    dSABind

UNBIND    dSAUnbind

ID    id-package-dspConnection    )

Пакеты управления операциями «chainedReadPackage». «chainedSearchPackage» и «chainedModifyPackage* определены как информационные объекты класса OPERATION-PACKAGE. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-4. chained Read Package    OPERATION-PACKAGE    ::=    {

OPERATIONS    {chained Read | chainedCompare

| chainedAbandon)

ID    id-package-chained Read |

chainedSearchPackage    OPERATION-PACKAGE    :: =    {

OPERATIONS    {chainedList | chainedSearch)

ID    id-package-chainedSearch )

chainedModifyPackage    OPERATION-PACKAGE    ::=    {

OPERATIONS    {chainedAdd Entry | chained Remove Entry

J chainedModifyEntry | chainedModifyDN)

ID    id-package-chainedModify}

6

Страница 11

ГОСТ Р ИСО/МЭК 9594-5-98

Примечание — Если эти пакеты реализованы в виде СЭГ1. они используются для создания прикладных контекстов, определенных в настоящем стандарте. Они не ставят своей задачей служить основой для заявки о соответствии отдельному СЭП или любой комбинации СЭП.

В «dapContract* ACC может пришшать роль иниииатора. к либо инициирующий, либо отвечающий ЛСС могут вызвать операции такого контракта.

6.5    Контракты и пакеты П'ГИС

«SliadowConsumerContract» и *shadowSupplierContract* определены как информационные объекты класса CONTRACT.

shadowConsumerContract    CONTRACT :: = {

CONNECTION    dispConnectionPackage

INITIATOR CONSUMER OF    (shadowConsumerPackage)

ID    id-contract-sluidowConsun>eг    }

shadowSupplicrContract    CONTRACT :: = {

CONNECTION    dispConnectionPackage

RESPONDER CONSUMER OF    {shadowSupplierPackage)

ID    id-coniract-shadowSupplier    }

Примечание — Понятия «потребитель» и «поставщик», используемые в нотации для классов CONTRACT и OPERATION-PACKAGE, используются для обозначения двух ролей. В ИСО/МЭК 9594-9 зги роли соответствуют двум понятиям — теневой потребитель и теневой поставщик.

Реализации в ВОС двух видов абстрактных теневых услуг, называемых в совокупности ГГГИС, определены в терминах некоторых прикладных контекстов и представлены в 7.2 настоящего стандарта.

Объекты «ShadowConsumerContract* и «shadowSupplierContract» составлены из общего пакета управления соединением «dispConnectionPackage» и либо пакета управления операциями «shadowConsumerPackage» в первом случае, либо пакета «shadowSupplierPackage* во втором.

Пакет управления соединением ‘dispConnectionPackage* определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением «dapConnection Package*.

dispConnectionPackage    CONNECTION-PACKAGE    ::    = {

BIND    dSAShadowBind

UNBIND    dSAShadow Unbind

ID    id-package-dispConnection    }

Пакеты управления операциями «shadowConsumerPackage*    и «shadowSupplierPackage* опреде

лены как информационные объекты класса «OPERATION-PACKAGE*. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-9.

shadowConsumerPackage    OPERATION-PACKAGE    ::=    {

CONSUMER INVOKES    {request Shadow Update)

SUPPLIER INVOKES    {updateShadow}

ID    id-package-shadowConsumer    }

shadowSupplierPackage    OPERATION-PACKAGE    ::=    {

SUPPLIER INVOKES    (coordinateShadowUpdate

| updateSliadow)

ID    id-package-shadowSupplier    }

Поскольку теневой потребитель является инициатором объекта «shadowConsumerContract». то он принимает роль потребителя «shadowConsumerPackage*. Это означает, что теневой потребитель вызывает операцию «requestShadowUpdate*, а теневой поставщик — операцию «updateShadow».

Поскольку теневой поставщик является инициатором «shadowSuppli-erConsumerContract», то он принимает роль поставщика «shadowSupp-lierPackage*. Это означает, что теневой поставщик привлекает операции контракта.

6.6    Контракт и пакеты НУЭС

«DopContract* определен как информационный объект класса CONTRACT. dopCoiuract    CONTRACT :: = (

CONNECTION    dopConnectionPackage

OPERATIONS OF    JdopPackage)

ID    id-contract-dop }

7

j*

Страница 12

ГОСТ Р ИСО/МЭК 9594-5-98

Если две ЛСС из различных открытых систем взаимодействуют между собой, то такой контракт ассоциации реализуется как протокол прикладного уровня ВОС, на который в таких спецификациях ссылаются как на протокол управления эксплуатационными связями (Г1У— ЭС). Определение этого протокола в понятиях прикладного контекста ВОС приведено в 7.2 настоящего стандарта.

Пакет управления соединением «dopConnectionPackage* определен как информационный объект класса CONNECTION-PACKAGE. Он идентичен пакету управления соединением «dapConnection Package».

dopConnectionPackage    CONNECTION-PACKAGE :: = {

BIND    dSAOperationalBindingManagementBind

UNBIND    dSAOperational Binding Management Unbind

ID    id-package-dopConneciion >

Пакет упраазения операциями «dopPackage» определен как информационный объект класса OPERATION-PACKAGE. Операции таких пакетов управления операциями определены в ИСО/МЭК 9594-2.

dopPackage OPERATION-PACKAGE :: = {

CONSUMER INVOKES lestablishOpenuional Binding

| modifyOperationalBinding | terminateOperationalBinding}

ID    id-package-operationalBindingManagement}

ACC, который может принимать роль инициатора объекта «dopContract», зависит от ролей, которые ЛСС может выполнять при административном управлении эксплуатационной(ыми) связью<ямн), использующем операции этого контракта. Привлекать операции «dopContract» может только инициатор. С этим контрактом возможно несколько административно управляемых типов эксплуатационных связей, если только рати АСС для различных типов совместимы (например. АСС принимает роль А при любом типе связи).

6.7 Использование нижерасположенных услуг

Протоколы НДС. ПСС, ПУЭС и ПТИС могут использовать нижерасположенные услуги, как описано ниже.

6.7.1    Использование услуг СЭУО

Сервисный элемент удаленных операций определен в ГОСТ Р ИСО/МЭК 9072-2.

СЭУО поддерживает парадигму запрос—ответ удаленных операций.

СЭГ1 справочника яачяются пользователями услуг СЭУО УО-ПРИ ВЛЕЧЕНИЕ. УО-РЕЗУЛЬТАТ. УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ

Удаленные операции НДС и ПСС выполняются в асинхронном режиме. Поскольку АГ1С яазя-ется потребителем ПДС, то выбор операций может осуществляться синхронным способом.

Удаленные операции П ГИС должны обеспечиваться синхронными операциями и факультативно могут обеспечиваться асинхронными операциями.

Удаленные операции ПУЭС выполняются в асинхронном режиме.

6.7.2    Использование услуг СЭНП

Сервисный элемент надежной передачи (СЭНП) определен в ИСО/МЭК 9066-1.

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

Для обеспечения ПТИС определены альтернативные прикладные контексты с СЭНП и без

него.

СЭНП используется в нормальном режиме. Использование нормального режима СЭНП подразумевает использование нормального режима СЭУА и нормального режима услуг уровня представления.

Если СЭНП включен в прикладной контекст, услуга УО-СВЯЗКА преобразуется в услугу СЭНП НП-ОТКРЫТИЕ, а услуга УО-РАЗВЯЗКА - в услугу СЭНП НГ1-ЗАКРЫТИЕ. Базовые услуги СЭУО являются единственным пользователем услуг СЭНП НП-Г1ЕРЕДАЧА. НП-ЗАП РОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ. НП-Пс-ПРЕРЫВАНИЕ н НП-Пл-ПРЕРЫВАНИЕ.

Страница 13

ГОСТ Р ИСО/МЭК 9594-5-98

6.7.3    Использование услуг СЭУА

Сервисный элемент управления ассоциацией (СЭУА) определен в ГОСТ 34.981.

СЭУА обеспечивает управление (установление, освобождение, аварийное прекращение работы) прикладных ассоциаций между ЛОП.

Если СЭНП включен в прикладной контекст, то он является единственным пользователем услуг СЭУА П-АССОЦИАЦИЯ. П-РАЗЪЕДИНЕНИЕ, П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.

Если СЭНП не включен в прикладной контекст, услуги УО-СВЯЗКА и УО-РАЗВЯЗКА являются единственными пользователями услуг СЭУА П-АССОЦИАЦИЯ и II-РАЗЪЕДИНЕНИЕ. Прикладной процесс использует услуги СЭУА П-ПРЕРЫВЛНИЕ и П-Пс-ПРЕРЫВАНИЕ.

Получение П-Г1РЕРЫВЛНИЕ или П-Пс-ПРЕРЫВЛНИЕ по ассоциации, поддерживающей ПДС, завершает всю обработку запроса. Кроме определенных условий, описанных в ИСО/МЭК 9594-4. это также справедливо для Г1СС. Пользователь справочника яазяется ответственным за подтверждение выполнения требуемых модификаций в ИБС,

Получение П-ИРЕРЫВЛНИЕ или П-Пс-ПРЕРЫВЛНИЕ по ассоциации, поддерживающей ПТИС, описано в ИСО/МЭК 9594-9.

Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВЛНИЕ по ассоциации, поддерживающей Г1УЭС. описано в ИСО/МЭК 9594-4.

6.7.4    Использование услуг уровня представления

Услуги уровня представления определены в ГОСТ 34.971.

Уровень представления координирует представление (синтаксис) семантики прикладного уровня. которая должна быть заменена.

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

СЭУА является единственным пользователем услуг Пр-СОЕДИНЕНИЕ. Пр-РАЗЪЕДИНЕНИЕ, Пр-Пл-ПРЕРЫВАНИЕ и Лр-Пс-ПРЕРЫВАНИЕ уровня представления.

Если СЭНП вктючен в прикладной контекст, то он яазяется единственным пользователем следующих услуг уровня представления: Пр-НАЧАЛО-АКТИВНОСТИ. Пр-КОНЕЦ-АКТИВНОС-ГИ. Пр-ПРЕРЫВЛНИЕ-АКТИВНОСТИ. Пр-ЛННУЛ ИРОВАНИЕ-АКТИВНОСТИ, Пр-ВОЗОБ-НОВЛЕНИЕ-АКТИВНОСТИ, Пр-ДАННЫЕ, Пр-МЛАДШЛЯ-СИНХРОНИЗЛЦИЯ. Пр-Пл-ОСО-БОЕ-СООБШЕНИЕ. Пр-Пс-ОСОБОЕ-СООБЩЕНИЕ. Пр-ЗЛПРОС-ПОЛНОМОЧИЙ и Пр-ПРЕ-ДОСТАВЛ ЕН И Е- ПОЛ НОМОЧ И Й.

Если СЭНП не включен в прикладной контекст, СЭУА является единственным пользователем услуги уровня представления Пр-ДАННЫЕ.

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

6.7.5    Использование услуг и ижераспо ложе иного уровня

Услуги сеансового уровня определены в ГОСТ Р ИСО N326.

Сеансовый уровень структурирует диалог потока информации между оконечными системами.

Если СЭНП включен в прикладной контекст, то уровень представления использует следующие фуикиионазьные блоки сеансового уровня: «ядро», «полудуплексе, «особые сообщения*, «младшая синхронизация* и «упраазение активностью».

Если СЭНП не включен в прикладной контекст, уровнем предстаазения используются функциональные блоки сеансового уровня: «ядро* и «полудуплекс*.

Услуги транспортного уровня определены в ГОСТ Р ИСО/МЭК 8072. Транспортный уровень обеспечивает межконцевую прозрачную передачу данных по соединению ннжерасположенного сетевого уровня.

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

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

Ннжерасположенный сетевой уровень, поддерживающий услуги сетевого уровня ВОС. определен в ГОСТ Р ИСО/МЭК 8348.

9

4 - >120

Страница 14

ГОСТ Р ИСО/МЭК 9594-5-98

Адресация на сетевом уровне определена также в ГОСТ Г ИСО/МЭК Х348 (адресация пунктов доступа к услугам сетевого уровня).

7 АБСТРАКТНЫЙ СИНТАКСИС ПРОТОКОЛА СПРАВОЧНИКА

7.1    Абстрактные синтаксисы

Два абстрактных синтаксиса, используемые в протоколах справочника, определены в других стандартах. Абстрактный синтаксис СЭУА *acse-abstract-syntax* необходим для установления ассоциации. Абстрактный синтаксис СЭНП «rtse-abstract-syntax* используется для ПТИС факультативно.

Тип АСН.1. из которого получены значения абстрактных синтаксисов, определяется путем использования типов параметризации ROS { }. Bind { }, Unbind { J, которые определены в ГОСТ Р ИСО/МЭК 9072-1.

Эти абстрактные синтаксисы, как и определенные ниже, должны (как минимум) колироваться в соответствии с базовыми правилами кодирования ACH.I.

7.1.1    Абстрактный синтаксис Г1ДС

СЭП справочника, реализующие указанные в 6.3 пакеты управления операциями, используют единственный абстрактный синтаксис «directoryAccessAbstractSyntax*. Он определяется в виде информационного объекта класса ABSTRACT-SYNTAX.

direct о ryAccessAbst гас t Syntax ABSTRACT-SYNTAX :: = {

DAP-PDUs

IDENTIFIED    BY    id-as-directoryAccessAS }

DAP-PDUs    ::=    CHOICE 1

basicRos    ROS {{DAP-InvokelDSet}, (DAP-lnvokablE),

{DAP-Returnable», bind    Bind (directoryBind),

unbind    Unbind {directorvUnbind)}

DAP>lnvokelDSet    :: - InvokelD (ALL EXCEPT absent:NULL)

DAP-lnvokable OPERATION    : : = | read | compare | abandon

| list | search | addEntry | reinoveEntry | modifyEntry | modifyDN }

DAP-Returnable OPERATION :: = {read | compare | abandon

| list | search | addEntry | remove Entry | modifyEntry | modify DN }

7.1.2    Абстрактный синтаксис ПСС

СЭП справочника, реализующие указанные в 6.4 пакеты управления операциями, используют единственный абстрактный синтаксис «directorySystembstractSyntax». Он определяется в виде информационного объекта класса ABSTRACT-SYNTAX.

directorySystembstractSyntax ABSTRACT-SYNTAX :: = {

DSP-PDUs

IDENTIFIED BY    id-as-directorySystemAS J

DSP-PDUs ::=    CHOICE {

basicRos    ROS {{DSP-Invoke!DSet},    {DSP-lnvokable},

{DSP-Returnable», bind    Bind {dSABind),

unbind    Unbind {dSAUnbind»

DSP-lnvokelDSet    :: = InvokelD (ALL EXCEPT absent:NULL)

DSP-lnvokable OPERATION : : = { chainedRead | chainedCompare

| chainedAbandon | chainedList | chainedSearch | chainedAddEntry | chainedRemoveEntry | chainedModityEntry | chainedModifyDN )

10

Страница 15

ГОСТ Р ИСО/МЭК 9594-5-98

DSP-Returnable OPERATION : : = { chainedRead | chainedCompare

| chainedAbandon | chained List | chainedSearch | chainedAddEntry | chainedRemoveEntry | chainedModifyEntry | chainedModifyDN )

7.1.3    Абстрактный синтаксис ПТИС

СЭГ1 справочника реализуют указанные в 6.5 пакеты управления операциями, которые определяются в абстрактном синтаксисе «directoiyShadowAbstractSyntax* или «directory ReliableShadow-Abstract Syntax» в зависимости от использования СЭН11 в прикладном контексте. Эти два абстрактных синтаксиса определяются в виде информационных объектов класса ABSTRACT-SYNTAX. directoryShadowAbstractSvntax ABSTRACT-SYNTAX :: = {

DISP-PDUs

IDENTIFIED BY id-as-directoryShadowAS ) directoryReliableShadowAbstractSyntax ABSTRACT-SYNTAX :: = {

Reliable-DISP-PDUs

IDENTIFIED BY id-as-direcioryRe!iableShadowAS }

Кроме того, в контекстах применения СЭНГ1 используется следующий абстрактный синтаксис. Он включает абстрактный синтаксис самого СЭНГ1 и абстрактный синтаксис Bind (dSAShadowBind}, a Unbind {dSAShadowUnbind}.

rtseAndShadowBindingAbstractSyniax ABSTRACT-SYNTAX :: = I Reliable Shadow Binding- P D Us

IDENTIFIED BY id-as-reliableShadowBindingAbstractSyntax}

Типы ACH.l, из которых получены значения абстрактных синтаксисов, определяются путем использования типов параметризации ROS {}, Bind {), Unbind {}.

DISP-PDUs    :    :    =    CHOICE    {

basicRos    ROS {{DISP-lnvokelDSet}, {DISP-lnvokable}.

{DISP- Returnable}}, bind    Bind (dSAShadowBind},

unbind    Unbind IdSAShadowUnbind}}

Reliable-DISP-PDUs    ::= ROS {{DISP-Invoke I DSet},

{DISP-lnvokable}.

{DISP-Returnable}},

ReliableShadowBinding-PDUs ::= CHOICE { rTS    RTSE-apdus,

bind    Bind {dSAShadowBind},

unbind    Unbind {dSAShadowUnbind}}

D ISP-Invoke I DSet    :: = InvokelD (ALL EXCEPT absent:NULL)

DISP-lnvokable OPERATION    :: = {requestShadowUpdate

| updateShadow | coordinateShadowUpdate }

DISP-Retumable OPERATION    :: = {requestShadowUpdate

| UpdateShadow | coordinateShadowUpdate }

7.1.4    Абстрактный синтаксис ПУЭС

СЭП справочника, который реализует указанный в 6.5 пакет управления операциями, использует абстрактный синтаксис «directoryOperationalBindingManagementAbstractSyntax*. Абстрактный синтаксис определяется в виде информационного объекта класса ABSTRACT-SYNTAX. directorvOperationalBindingManagementAbstractSvntax ABSTRACT-SYNTAX :: = {

DOP-PDUs

IDENTIFIED BY id-as-directorvOperaiionalBindingManagementAS }

DOP-PDUs ::= CHOICE { basicRos    ROS {{DO P- Invoke I DSet}.    {DOP-lnvokable},

{DOP- Returnable}}, bind    Bind {directoryBind},

unbind    Unbind {directorylJnbind}}

Страница 16

ГОСТ Р ИСО/МЭК 9594-5-98

DOP-liwokelDSet    ::= InvokelD (ALL EXCEPT absent: NULL)

DOP-Invokable OPERATION :: = { establishOperationalBinding

| modifyOperationalBinding | tcrminateOpcrationalBinding}

DOP-Reiumable OPERATION :: = { establishOperationalBinding

| modifyOperationalBinding | terminateOperationalBinding}

7.2 Прикладные контексты справочника

7.2.1    Прикладной контекст доступа к справочнику «DapContract* реализован как «directoryAccessAC». Этот прикладной контекстопределен в виде

информационного объекта класса APPLICATION-CONTEXT.

directoryAccessAC    APPLICATION-CONTEXT :: = |

CONTRACT    dapCon tract

ESTABLISHED BY    acse

INFORMATION TRANSFER BY    pData

ABSTRACT SYNTAXES    {acse-abstract-syntax

| directoryAccessAbstractSyntax)

APPLICATION CONTEXT NAME    id-ac-directoryAccessAC }

7.2.2    Прикладной контекст системы справочника

« DspContract* реализован как «directorySystemAC». Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.

directorySystemAC    APPLICATION-CONTEXT :: = {

CONTRACT    dspContract

ESTABLISHED BY    acse

INFORMATION TRANSFER BY    pData

ABSTRACT SYNTAXES    {acse-abstract-syntax

| directoryAccessAbstractSyntax)

APPLICATION CONTEXT NAME    id-ac-directorySystemAC )

7.2.3    Прикладной контекст теневого справочника

Если ACC поддерживает 11ТИС. он должен поддерживать по крайней мере одну теневую роль: поставщика либо потребителя и, кроме того, один из объектов «shadowSupplierlnitiatedAC» или «shadowConsumerlnitiatedAC». Если АСС поддерживает «shadowSupplierlnitiatedAC* для конкретной роли, то он может факультативно поддерживать для той же роли и «reliableShadowSupplierlnitiatedAG*. Если АСС поддерживает «shadowConsumerlnitiatedAC* для конкретной роли, то он может факультативно поддерживать для той же рати и reliableShadowCon-sumerlnitiatedAC*.

7.2.3.1 Начеиыте контексты теневою поставщика

«ShadowSupplierContract* может быть реализован как «shadowSupplierlnitiatedAC*. Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT. shadowSupplierlnitiatedAC    APPLICATION-CONTEXT    ::=    {

CONTRACT    shadowSupplierContract

ESTABLISHED BY    acse

INFORMATION TRANSFER BY    pData

ABSTRACT SYNTAXES    (acse-abstract-syntax

| directoryShadowSyntax}

APPLICATION CONTEXT NAME    id-ac-shadowSupplierlnitiatedAC )

Этот прикладной контекст требует применения только синхронных операций.

Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как •id-ac-shadowSupplierlnitiatedAsynchronosAC*.

«ShadowSupplierContract* может быть факультативно реализован как «reliableShadowSupplier-InitiatedAC*. Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.

reliableShadowSupplierlnitiatedAC    APPLICATION-CONTEXT :: = {

CONTRACT    shadowSupplierContract

ESTABLISHED BY    association-by-RTSE

INFORMATION TRANSFER BY    transfer-by-RTSE

ABSTRACT SYNTAXES    (reliableShadowBindingAbstractSyntax

12

Страница 17

ГОСТ Р ИСО/МЭК 9594-5-98

| use-abstract-syntax I rtseAndShadowBindingAbstractSyntax} APPLICATION CONTEXT NAME    id-ac-reliableShadowSupplierlnitiatedAC    }

7.2.3.2 Начальные контексты теневого потребителя

Объект «shadowConsumerContract* может быть реализован как «shadowConsumerlnitiatedAC*. Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.

APPLICATION-CONTEXT :: = | shadowConsumerContract acse pData

shadowConsumerlnitiatedAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTRACT SYNTAXES APPLICATION CONTEXT NAME

{acse-syntax 1 directoryShadowSyntax J id-ac-shadowConsumerlnitiatedAC }

Этот прикладной контекст требует применения только синхронных операций.

Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как «id-ac-shadowConsumerlnitiatedAsynchronosAC*.

Объект «shadowConsumerContract» может быть факультативно реализован как «reliable-ShadovvConsumerlnitiatedACV Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.

reliables hadowConsumerlnitiatedAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTRACT SYNTAXES

APPLICATION-CONTEXT :: = { shadowConsumerContract association-by-RTSE transfer-by-RTSE

I re liable Shadow Bindi ngAbst ract Sy nt ax | rtse-abstract-syntax | rtseAndShadow Bindi ngAbst ractSyntax | id-ac-reliableShadowConsumerlnitiatedAC } управления эксплуатационными

APPLICATION CONTEXT NAME 7.2.4 Прикладной контекст связями справочника «DopContract реализован как «directoryOperationalBindingManagementAC*. Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.



APPLICATION-CONTEXT dopContract acse pData

directoryOpe rational Binding.ManagementAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTRACT SYNTAXES

) acse-abctract-syntax | directoryOperationalBindingManagementAbst ractSyntax} APPLICATION CONTEXT NAME    id-ac-directoryOperationalBindingManagemeiuAC

7.3 Коды операций

7.3.1 Коды операций для пакетов НДС и ПСС

Следующие коды операций используются пакетами управления операциями Г1ДС и ПСС.

idmpcode-read

Code

Code

Code

Code

Code

Code

Code

Code

local

local

local

local

local

local

local

local

local

id - opcode -com pa re

id-opcode-abandon

id-opcode-list

id-opcode-search

id-opcode-addEntry

id - opcode - remove Entry

id-opcode-modify Entry

id-opcode-modifyDN

Code :: =

7.3.2 Коды операций для пакетов 11ТИС

Следующие коды операций используются пакетами управления операциями ГГГИС: id-opcode-requestShadowUpdate    Code    :: =    local:    I

id-opcode-updateShadow    Code    :: =    local:    2

id-opcode-coordinateShadowUpdate    Code    :: =    local:    3

5 - 1120

13

Страница 18

ГОСТ Р ИСО/МЭК 9594-5-98

7.3.3 Коды операций для пакетов ПУЭС

Следующие коды операций используются пакетами управления операциями ПУЭС: id-op-establishOperationalBinding    Code    :: =    local:    100

id-op-modifyOperaiionalBinding    Code    :: =    local:    102

id-op-terminateOperationalBinding    Code    = local: 101

7.4    Коды ошибок

7.4.1    Коды ошибок для пакетов ПДС и ПСС

Пакеты управления операциями ПДС и ПСС используют следующие колы ошибок: *id-errcode-referral* — только в ПДС; «id-opcode-dsaRereferral* — только в ПСС.

7.4.2    Коды ошибок для пакетов Г1ТИС

Пакеты упраачения операциями ПТИС используют следующие коды ошибок: id-errcode-shadowError    Code    ::    =    local:    1

7.4.3    Коды ошибок для пакетов ПУЭС

Пакеты управления операциями ПУЭС используют следующие коды ошибок: id-err-operationalBindingError    Code    ::=    local:    100

7.5    Версии и правила расширяемости

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

Примечание—В настоящее прем и существует только одна версия каждого протокола справочника. И (дания 198S и 1993 гг. имеют одинаковую версию. Упомянутая выше процедура определена для более позднего издания спецификации справочника как новая версия.

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

11 р и мечен и е — Промежуточный АСС. который только сцепляет запрос, может выбрать для рассмотрения определенные элементы Г1БДП справочника, необходимые для выполнения своей функции, например, присвоение имени.

7.5.1    А П С КАСС

7.5.1.1    Согласование версии

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

И р и м с ч а н и с — Других каких-либо двухпунктовых аспектов ПДС. которые в настоящее время указывались бы различными версиями протокола, не Существует.

7.5.1.2    Обработка запроса и ответа

АПС может инициировать запросы, используя самое последнее издание спецификации, запрос которого она поддерживает. Если один или несколько элементов запроса критичны, то АПС должен указывать номер(а) расширения в параметре critical Extensions.

Примечание— Если информация расширения заменена в тине CHOICE. ENUMERATED или INTEGER (использованный как ENUMERATED), то тип будет существен для соответствующей операции в АСС, реализованном согласно более раннему изданию спецификации. Рекомендуется, чтобы расширение было отмечено как критическое.

При обработке запроса от АПС АСС должен выполнять правила, определенные в 7.5.2.2.

При обработке ответа АПС должен:

а) игнорировать все неизвестные присвоения имен битов в строке битов;

14

Страница 19

ГОСТ Р ИСО/МЭК 9594-5-98

b)    игнорировать все неизвестные поименованные номера в типе ENUMERATED или INTEGER, который используется в перечисленном стиле при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;

c)    игнорировать все неизвестные элементы в SET, в копие SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.

Примем а и и с — Реализации хюгут в качестве локального решения игнорировать определенные дополнительные элементы в П БД справочника. В частности, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификации таких элементов является предметом дальнейшего изучения;

d)    не рассматривать получение неизвестных типов атрибутов и их значений как нарушение протокола;

e)    факультативно сообщать пользователю неизвестные типы атрибутов и их значения.

7.5.1.3 Правша расширяемости при обработке ошибок

При обработке известного типа ошибки с неизвестными обозначенными проблемами и параметрами АПС должен;

a)    не рассматривать получение неизвестных обозначенных проблем и параметров как нарушение протокола (то есть он не должен выдавать RO-Ra-REJECT или прерывать прикладную ассоциацию) и

b)    факультативно сообщать пользователю дополнительную информацию об ошибке.

При обработке неизвестного типа ошибки АПС должен;

a)    не рассматривать получение неизвестного типа ошибки как нарушение протокола (то есть он не должен выдавать RO-Пл-REJECT или прерывать прикладную ассоциацию) и

b)    факультативно сообщать пользователю об ошибке.

7.5.2 АС С к АС С

7.5.2.1    Согласование версии

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

И р и м с ч а н и с — Не существует двухпунктовых аспектов ПСС, которые в настоящее время обозначены различными версиями протокола.

При установлении или принятии ассоциации, то есть связки с использованием П'ГИС. согласование версии должно определять все аспекты протокола, имеющие отношение к обмену между АСС.

Примечание — В настоящее время существует только одна версия протокола ПТИС.

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

Примечание — В настоящее время существует только одна версия протокола ПУЭС.

7.5.2.2    Правила расширяемости при обработке операции

Если какой-либо АСС, выполняющий операцию (после завершения присвоения имен) определяет элемент criticalExtensioiis. семантика которого неизвестна, он должен передать обратно признак unavailableCriticalExtension в виде serviceError или в PartialOutcomeQualifier.

Примечание— При получении строки criticalExtensioiis с одним или несколькими нулевыми значениями это указывает на то, что расширения, соответствующие значениям, не представлены в операции или некритичны. Наличие нулевых значений в строке criticalExlensions не должно быть выведено как наличие или отсутствие соответствующего расширения в Г1БД11.

В противном случае при обработке Г1БД справочника АСС должен:

a)    игнорировать все неизвестные присвоения имен битов в строке битов;

b)    игнорировать все неизвестные поименованные номера в типе ENUMERATED или типе INTEGER, который используется в перечисленном стиле, при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;

15

j*

Страница 20

ГОСТ Р ИСО/МЭК 9594-5-98

с) игнорировать псе неизвестные элементы в SET, в конце SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.

II р и м с ч а я и с — Реализации могу г в качестве локального решения игнорировать определенные дополнительные элементы н ПБД справочника. В частност и, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификация таких элементов является предметом дальнейшего изучения.

7.5.2.3    Правила расширяемости при формировании цепочки

Если ПБД является запросом, ЛСС должен передавать запрос, содержащий неизвестные типы и значения, любому дополнительному ЛСС. определенному в результате присвоения имени.

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

7.5.2.4    !lpauu.ui расширяемости при об/юботке ошибок

При обработке известного типа ошибок с неизвестными обозначенными проблемами и параметрами ЛСС:

a)    не должен рассматривать получение неизвестных обозначенных проблем и параметров как нарушением протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию) и

b)    может попытаться восстановить соответствующий своему пониманию именно этот тип ошибки или передать эту ошибку (и неизвестные для себя обозначенные проблемы и параметры) следующему соответствующему ЛСС или АПС.

При обработке неизвестного типа ошибки ЛСС, который только участвует в формировании цепочки запросов, должен:

a)    не рассматривать неизвестный тип ошибки как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию);

b)    не пытаться корректировать или восстанавливать ошибки и своих обозначенных проблем и параметров;

c)    передавать неизвестный тип ошибки следующему соответствующему ЛСС или АПС.

При обработке неизвестной ошибки ЛСС, который коррелирует групповые ответы, должен:

a)    не рассматривать неизвестный тип ошибки как нарушение протокола (то есть он не должен выдавать УО-Пл-ОТКЛОНЕНИЕ или прерывать прикладную ассоциацию);

b)    не пытаться корректировать или восстанавливать ошибки и своих обозначенных проблем и параметров;

c)    занести неизвестную ошибку в PartialOutcomeQualifier и

d)    продолжить корреляцию результатов в обычном режиме.

8 ПРЕОБРАЗОВАНИЕ В ИСПОЛЬЗУЕМЫЕ УСЛУГИ

Этот раздел определяет преобразование ПДС. ПСС. ПУЭС и ПТИС в используемые услуги. Преобразование ПДС. ПСС и ПУЭС, а также тех прикладных контекстов ПТИС, которые не содержат СЭНП. определено в 8.1. Преобразование прикладных контекстов ПТИС, использующих СЭНП, определено в 8.2.

8.1    Прикладные контексты, не использующие СЭШ1

В этом подразделе определяется преобразование прикладных контекстов ПДС, а также тех прикладных контекстов ПТИС, которые не содержат СЭНП, в используемые услуги.

8.1.1    Преобразование в СЭУА

Ниже определяется преобразование услуг (DirectoryBind, DSABind. DSAShadowBind или DSADOPBind) и (DirectoryUnbind. DSAUnbind. DSAShadowUnbind или DSADOPUnbind) в услуги СЭУА. СЭУА определен в ГОСТ 34.981.

8.1.1.1    Преобразование Bind в 11-А ССОЦИЛ ЦИЯ

Услуги DirectoryBind. DSABind. DSAShadowBind или DSADOPBind преобразуются в услугу СЭУА П-АССОЦИЛЦИЯ. Использование параметров услуги П-ЛССОЦИАЦИЯ уточняется в следующих подпунктах.

8.1.1.1.1    Режим

16

Страница 21

ГОСТ Р ИСО/МЭК 9594-5-98

Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИА-ЦИЯ запрос и иметь значение «нормальный режим*.

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

Инициатор ассоциации должен предоставлять один из следующих прикладных контекстов:

a)    для Г1ДС - direcioryAccessAC:

b)    для ПСС - directoiySystemAC;

c)    для ПУЭС — directoryOpeiationalBindingManagementAC;

d)    для ПТИС — shadowSupplieiinitiatedAC или shadowConsumerlnitiatedAC.

8.1.1.1.3    Информация пользователя

Преобразование услуги DirectoryBind или DSABind в параметры «информация пользователя* примитива П-АССОЦИАЦИЯ запрос определено ГОСТ I» ИСО/МЭК 9072-1.

8.1.1.1.4    Список определений копте к с т а уровня п р е д с т а в л е и и я

Инициатор ассоциации должен установить список определений контекста уровня представления в примитиве П-АССОЦИАЦИЯ запрос, который должен содержать абстрактный синтаксис СЭУА (id-as-acse) и один из следующих абстрактных синтаксисов: НДС (id-as-directoryAccessAS), ПСС (id-as-directorySystemAS), ПУЭС (idws-directoryOperationalBindingManagemetAS) или ПТИС (id-asMirec-toryShadowAS).

8.1.1.1.5    Качество услуг

Этот параметр должен устанавливаться инициатором ассоциации в примитиве 11-АССОЦИАЦИЯ запрос и ответчиком ассоциации в примитиве П-АССОЦИАЦИЯ ответ. Параметры «управление расширением» и «оптимизированная диалоговая передача* должны быть установлены в значение «возможность не требуется*. Остальные параметры должны быть установлены таким образом, чтобы использовались значения по умолчанию.

X. 1.1.1.6 Требования сеансового уровня

Этот параметр должен устанавливаться инициатором ассоциации в примитиве 11 -АССОЦИАЦИЯ запрос и ответчиком ассоциации в примитиве П-АССОЦИАЦИЯ ответ. Этот параметр устанавливается для определения функциональных блоков «ядро* и «полудуплекс*.

8.1.1.1.7 Наименование ЛОП и адрес на уровне представления

Эти параметры должны устанавливаться инициатором и ответчиком ассоциации (наименование ЛОП устанавливается факультативно).

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

Для АПС (или АСС), устанавливающего ассоциацию с АСС. к которому он обращается, эти параметры могут быть получены из значения атрибута AccessPoint в Continuation Reference.

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

8.1.1.2    Unbind в //-РАЗЪЕДИИЕНИЕ

Услуги DirectoryUnbind. DSAUnbind, DSAShadowUnbind или DSADOPUnbind преобразуются в услугу СЭУА П-РАЗЪЕДИНЕНИЕ. Использование параметров услуги 11 -РАЗЪЕДИНЕНИЕ описано в следующем подпункте.

8.1.1.2.1    Результат

Этот параметр должен иметь значение «подтверждение».

8.1.1.3    Использование услуг П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ

Прикладной процесс является пользователем услуг СЭУА П-ПРЕРЫВАНИЕ и ГЬПс-ПРЕ-РЫВАНИЕ.

8.1.2    Преобразование в СЭУО

Услуги СЭП справочника преобразуются в услуги СЭУО УО-ПРИ ВЛЕЧЕНИЕ. УО-РЕЗУЛЬ-ТАТ. УО-ОШИБКА. УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ. Преобразование нотации абстрактного синтаксиса сервисных элементов прикладного уровня справочника в услуги СЭУО осуществляется в соответствии с ГОСТ Р ИСО/МЭК 9072-1.

8.2    Прикладные контексты, содержащие СЭНН

В этом подразделе определено преобразование прикладных контекстов ПТИС, содержащих СЭНП, в используемые услуги. Обеспечение этого преобразования определяется заявкой о соответствии этим прикладным контекстам. СЭНП определен в ГОСТ Р ИСО/МЭК 9066-1.

8.2.1    Преобразование в у с л у г и HI1-OTK Р Ы Т И Е и Н П-3 А КРЫТИЕ

17

Страница 22

ГОСТ Р ИСО/МЭК 9594-5-98

Ниже определяется преобразование услуг DSAShadowBind и DSAShadowUnbind в услуги СЭНГ1 НП-ОТКРЫТИЕ и НГ1-ЗАКРЫТИЕ.

8.2.1.1    Преобразование DSAShadow ВЫ в НП-ОТКРЫТИЕ

Услуга DSAShadowBind преобразуется в услугу СЭНП НП-ОТКРЫТИЕ. Использование параметров услуги НП-ОТКРЫТИЕ описывается ниже.

8.2.1.1.1    Режим

Этот параметр должен устанавливаться инициатором ассоциации в примитиве НГ1-ОТКРЫТИЕ запрос и иметь значение «нормальный режим*.

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

Инициатор ассоциации должен предлагать в примитиве НП-ОТКРЫТИЕ запрос либо прикладной контекст reliableShadowSupplierlnitiatedAC. либо прикладной контекст reliable-ShadowConsumerlnitiatedAC.

5.2.1.1.3    Данные пользователя

Преобразование операции связки в параметре «данные пользователя* примитива НП-ОТКРЫ-'ГИЕ запрос определено в ГОСТ Р ИСО/МЭК 9072-1.

8.2.1.1.4    Список определений кон т е к с т а уровня п р е д с т а в л е н и я

Инициатор ассоциации должен установить список определений контекста уровня представления в примитиве НП-ОТКРЫТИЕ запрос, который должен содержать абстрактный синтаксис СЭУА (id-as-acse) и абстрактный синтаксис ПТИС, включающий СЭНП (id-as-direcioryReliableShadowAS).

8.2.1.1.5    Н а ч а л ь н ы й ц и к л

Этот параметр должен быть установлен инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и должен быть равен значению «association-initiator*.

5.2.1.1.6    Наименование Л О II и адрес на уровне представления

Эти параметры должны устанавливаться инициатором и ответчиком ассоциации НП-ОТКРЫТИЕ (наименование ЛОП устанавливается факультативно).

8.2.1.2    Преобразование DSAShadow Unbind в НП-ЗЛКРЫГИЕ

Услуга DSAShadowUnbind преобразуется в услугу СЭНП Н 11-ЗАКРЫТИЕ.

8.2.2    Преобразование в СЭУО

Услуги ShadowSuppIierASE и shadowConsumerASE преобразуются в услуги СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА. УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ. Преобразование нотации абстрактного синтаксиса таких СЭП ПТИС в услуги СЭУО осуществляется в соответствии с ГОСТ Р ИСО/МЭК 9072-1.

СЭУО является пол ьэователем услуг СЭНП Н11-ПЕРЕДАЧА, НП-ЗАП РОС-ПОЛНОМОЧИЙ. НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ. Использование услуг СЭНП СЭУО определено в ГОСТ Р ИСО/МЭК 9072-2.

8.2.2.1    Управление полномочиями

ГОСТ Р ИСО/МЭК 9072-2 определяет использование сервисным элементом удаленных операций услуг СЭНП НИ-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ для управления полномочиями.

Параметр «приоритет» услуги НП-ЗАПРОС-ПОЛНОМОЧИЙ, используемой сервисным элементом удаленных операций для запроса полномочий, имеет значение:

ноль — наивысший приоритет, зарезервированный для освобождения ассоциации инициатором;

единица — используется СЭУО для обеспечения своих услуг УО-Пл-ОТКЛОНЕНИЕ и УО-ОШИБКА;

два — используется СЭУО для обеспечения своей услуги УО-РЕЗУЛЬТАТ;

три — используется СЭУО для обеспечения своей услуги УО-ПРИВЛЕЧЕНИЕ.

9 СООТВЕТСТВИЕ

В этом разделе устанавливаются требования к соответствию настоящему стандарту.

9.1    Требования к соответствию, предъявляемые AIIC

Реализация АПС, претендующая на соответствие настоящему стандарту, должна удовлетворять требованиям 9.1.1 —9.1.3.

9.1.1    Требования к заявке

IS

Страница 23

ГОСТ Р ИСО/МЭК 9594-5-98

Должно был, указано следующее:

a)    операции прикладного контекста directoryAccessAC, которые способен привлечь АПС и соответствие которым заявлено;

b)    уровень(и) зашиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая):

c)    расширения, перечисленные в таблице 7.3.1 ИСО/МЭК 9594—3, которые АПС способен инициировать и соответствие которым заявлено.

9.1.2    Статические требования

АПС должен:

a)    обладать способностью обеспечивать прикладной контекст directoryAccessAC, определенный его абстрактным синтаксисом в разделе 7;

b)    выполнять расширения, соответствие которым заяатено в 9.1.1 с).

9.1.3    Динамические требования

АПС должен:

a)    соответствовать преобразованию в используемые услуги, определенные в разделе S;

b)    соблюдать правила процедур расширения, определенные в 7.5.1.

9.2 Требования к соответствию, предъявляемые АСС

Реализация АСС, претендующая на соответствие настоящему стандарту, должна удовлетворять требованиям 9.2.! —9.2.3.

9.2.1 Требования к заявке

Должно быть указано следующее.

a)    Прикладные контексты, соответствие которым заявлено: directoryAccessAC, directory-SystemAC, directoryOperationalBindingManagemeniAC или их комбинации. АСС, претендующий на соответствие атрибуту directoiyOperationalBindingManagementAC в обеспечение иерархических эксплуатационных связей, должен обеспечивать также directorySystemAC. Если сведения об АСС рассредоточены. что вызывает необходимость обращаться к АСС, расположенных в других АСС вне своего собственного административного региона справочника (АРС), должно быть заявлено соответствие атрибуту directory SystemAC.

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

b)    Эксплуатационные типы связей, соответствие которым заявлено — shadow-OperationalBindinglD. specificHierarchicalBindinglD, non-specificHierarchicalBindingID или их комбинации. АСС, претендующий на соответствие атрибуту' shadowOperationalBindingID, должен поддерживать один или несколько прикладных контекстов теневых поставщиков и/или теневых потребителей, указанных в 9.3 и 9.4.

c)    Способность АСС функционировать в качестве АСС первого уровня, как определено в ИСО/МЭК 9594-4.

d)    Обеспечение режима сцепления операций согласно ИСО/МЭК 9594-4. если заявлено соответствие прикладному контексту directorySystemAC.

e)    Уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая).

О Выбранные типы атрибута, определенные в ИСО/МЭК 9594-6, и любые другие типы атрибутов. соответствие которым заявлено, а также соответствие атрибутов, основанных на синтаксисе directoryString. выбору UNIVERSAL STRING.

g)    Выбранные классы объектов, определенные в Г ОСТ Р ИСО/МЭК 9594-7. и любые другие классы объектов, соответствие которым заяапено.

h)    Расширения, перечисленные в таблице 7.3.1 ИСО/МЭК 9594-3, при которых АСС способен быть отвечающим, соответствие которому заявлено.

i)    Соответствие общим атрибутам согласно Х.8 ИСО/МЭК 9594-2 и 7.6, 7.8.2,    9.2.2

ИСО/МЭК 9594-3.

j) Соответствие иерархическим атрибутам согласно 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3.

к) Типы эксплуатационных атрибутов, определенные в ИСО/МЭК 9594—2. и любые другие типы эксплуатационных атрибутов, соответствие которым заявлено.

1) Соответствие для передачи псевдонимов согласно 7.7.1 ИСО/МЭК 9594-3.

т) Соответствие выдаче указания о том, что передача информации записи завершена согласно 7.7.6 ИСО/МЭК 9594-3.

19

Страница 24

ГОСТ Р ИСО/МЭК 9594-5-98

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

0)    Соответствие базовому управлению доступом.

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

q) Способность АСС осуществить административное управление подсхемой своей части ДИС согласно ИСО/МЭК 9594-2.

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

г) Выбранные поименованные связи, определенные в ГОСТ Р ИСО/МЭК 9594-7. и любые другие поименованные связи, соответствие которым заявлено.

s) Способность АСС к административному управлению общими атрибутами согласно ИСО/МЭК 9594-2.

9.2.2    Статические требования

АСС должен:

a)    поддерживать прикладные контексты, соответствие которым заявлено, согласно определению их абстрактного синтаксиса в разделе 7;

b)    поддерживать информационную структуру, определенную абстрактным синтаксисом ИСО/МЭК 9594-2;

c)    соответствовать требованиям минимальных сведений, определенным в ИСО/МЭК 9594-4;

d)    обеспечивать требования корневого контекста согласно ИСО/МЭК 9594-4. если заявлено соответствие АСС первого уровня;

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

О обеспечивать классы объектов, соответствие которым заявлено согласно их абстрактному синтаксису;

g)    обеспечивать расширения, соответствие которым заявлено в 9.2.lh;

h)    осуществлять административное управление подсхемой, если заявлено соответствие такой способности согласно ИСО/МЭК 9594-2;

1)    выполнять соответствующие процедуры, определенные в 7.6. 7.8.2 и 9.2.2 ИСО/МЭК 9594-3, если заявлено соответствие общим атрибутам;

j) выполнять соответствующие процедуры, определенные в 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3, если заявлено соответствие иерархическим атрибутам;

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

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

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

9.2.3    Динамические требования

АСС должен;

a)    соответствовать преобразованию в используемые услуги, определенные в разделе S настоящего стандарта;

b)    соответствовать процедурам распределенных операций справочника при обращении к нему согласно ИСО/МЭК 9594-4;

c)    соответствовать процедурам ИСО/МЭК 9594-4, относящимся к режиму обращения ИДС, если заявлено соответствие прикладному контексту directoiyAccessAC;

d)    соответствовать режиму обращения при взаимодействии согласно ИСО/МЭК 9594-4. если заявтено соответствие прикладному контексту directorySystemAC;

e)    соответствовать режиму сцепления при взаимодействии согласно ИСО/МЭК 9594-4, если заявлено соответствие режиму сцепления при взаимодействии.

Примечание — В этом случае необходимо только, чтобы АС'С был способен привлекать операции directorySystemAC;

О соблюдать правила процедур расширяемости, определенные в 7.5.2;

20

Страница 25

ГОСТ Р ИСО/МЭК 9594-5-98

g)    обладать возможностью зашиты информации в пределах ЛСС в соответствии с процедурами базового управления доступом, если заявлено соответствие базовому управлению доступом;

h)    обладать возможностью зашиты информации в пределах ЛСС в соответствии с процедурами упрощенного управления доступом, если заяатено соответствие упрощенному управлению доступом;

i)    соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно ПЭУС. если заявлено соответствие атрибуту shadowOperationalBindinglD;

j) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно конкретных иерархических эксплуатационных связей, если заявлено соответствие атрибуту specificHierarchicalBindinglD;

к) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно неопределенных иерархических эксплуатационных связей, если заявлено соответствие атрибуту non-specificHierarchicalBindinglD.

9.3 Требования соответствия, предъявляемые теневым поставщиком

Реализация ЛСС. претендующая на соответствие настоящему стандарту и выступающая в роли теневого поставщика, должна удовлетворять требованиям 9.3.1—9.3.3.

9.3.1    Требования к заявке

Должно быть указано следующее:

a)    прикладн(ой)ые контекст<ы), соответствие которому(ым) заяатено как для теневого поставщика: shadowSupplierlnitiatedAC, shadowConsumerlnitiatedAC, reliableShadowSupplierlnitiatedAC и reliableShadowConsu-merlnitiatedAC.

Реализация ЛСС должна как минимум обеспечивать либо shadowSupplierlnitiatedAC, либо shadowConsumerlnitiatedAC. Если ЛСС поддерживает shadowSupplierlnitiatedAC, он может факультативно поддерживать reliableShadowSupplierlnitiatedAC. Если ЛСС поддерживает shadowConsumerlnitiatedAC. он может факультативно поддерживать reliableShadowConsumerlnitiatedAC;

b)    уровепь(и) зашиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);

c)    в какой степени обеспечивается UnitOfReplication, в частности, какая (при наличии) из следующих факультативных особенностей обеспечивается:

-    фильтрование записи на Object Class;

-    выбор/исключение атрибутов с помощью AttributeSelection;

-    включение сведений подчиненного в область для копирования;

-    включение расширенных сведений дополнительно к сведениям подчиненного.

9.3.2    Статические требования

ЛСС должен:

a)    обеспечивать прнкладной(ые) контекст(ы), соответствие которому(ым) заявлено согласно определениям в их абстрактном синтаксисе в разделе 7;

b)    обеспечивать эксплуатационные атрибуты modi-fyTimestamp и createTimestamp.

9.3.3    Динамические требования

ЛСС должен:

a)    соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта:

b)    соответствовать процедурам, определенным ИСО/МЭК 9594-9 относительно ГГГИС.

9.4 Требования к соответствию, предъявляемые теневым потребителем

Реализация ЛСС. претендующая на соответствие настоящему стандарту и являющаяся теневым потребителем, должна удовлетворять требованиям, перечисленным в 9.4.1-9.4.3.

9.4.1 Требования к заявке

Должно быть указано следующее:

a)    прикладн(ой)ые контекст(ы). соответствие которому(ым) заяачено как для теневого поставщика: shadowSupplierlnitiatedAC, shadowConsumerlnitiatedAC, reliableShadowSupplierlnitiatedAC и reliableShadowConsumerlnitiatedAC.

Реализация ЛСС как минимум должна обеспечивать либо shadowSupplierlnitiatedAC. либо shadowConsumerlnitiatedAC. Если ЛСС обеспечивает shadowSupplierlnitiatedAC, он может факультативно обеспечивать reliableShadowSuppIierlnitiatedAC. Если ЛСС обеспечивает shadowConsumerlnitiatedAC, он может факультативно обеспечивать reliableShadowConsumerlnitiatedAC;

b)    уровень(и) защиты, соответствие которому(ым) заяатено (отсутствует, простая, строгая):

21

Страница 26

ГОСТ I* ИСО/МЭК 9594-5-98

c)    способность ЛСС действовать в качестве вторичного теневого поставщика (то есть участвовать во вторичном затенении в качестве промежуточного ЛСС);

d)    способность ЛСС обеспечивать затенение перекрывающихся блоков, подлежащих копированию.

9.4.2    Статические требования

ЛСС должен:

a)    обеспечивать прикладной(ые) контекст(ы). соответствие которому(ым) заявлено, как определено их абстрактным синтаксисом в разделе 7;

b)    обеспечивать эксплуатационные атрибуты modifyTimestamp и createTimestamp. если обеспечиваются перекрывающиеся блоки, подлежащие копированию;

c)    обеспечивать сервисное управление copyShallDo.

9.4.3    Динамические требования

АСС должен:

a)    соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта;

b)    соответствовать процедурам, определенным ИСО/МЭК 9594-9. относительно ИТИС.

22

Страница 27

ГОСТ Р ИСО/МЭК 9594-5-98

ПРИЛОЖЕН НЕ А

(обязательное/

ПРОТОКОЛ ДОСТУПА К СПРАВОЧНИКУ В АСН.1

В данном приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 *DircctoryAcccssProtocol».

DircctoryAccessProtocol Ijoint-iso-ccitt ds(5} module! I} dap! 11} 2}

DEFINITIONS :: -BEGIN

-    EXPORTS All -

-    - Определенные в этом модуле типы и Значения эксиоргируются для использования в других модулях АСН.1,

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

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

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

-    -необходимым при обслуживании или усовершенствовании услуг справочника.

IMPORTS

directoryAbstractServtoe. protocolObjcct Identifiers FROM UscfulDefinitions (joint-iso-ccitt ds(5) module(l) usefulDefinitions(0) 2)

ROS-OBJECT-CLASS. CONTRACT. OPERATION-PACKAGE, CONNECTION-PACKAGE, Code, OPERATION

FROM Remotc-Opcrations-lnfomiation-Objccls

{joint-iso-ccitt rcmote-opcrations(4) i и Го rrna t ю n Object s( 5) version(O)}

ROS{}, Bind{}. Unbindgj). InvokeII)

FROM Remote-Operations-Generic-ROS-PDUs

{joint-iso-ccitt rcmotc-operations<4) generic-ROS-PDUs (6) vcrsionl(O)}

APPL1CATION-CONTEXT

FROM Remote-Operations-lnformation-Objects-extension

{joint-iso-ccitt rcmote-operations(4) informationObjects-extension{8) version WO)} acse, pData

FROM Remote-Operations-Realisations

{joint-isowcitt remotc-operations(4) realisations^) version 1(0)) acse-abstract-syntax

FROM Remotc-Opcrations-Abstract-Syntaxes

{joint-iso-ccitt remote-opcrations(4) rcmoteOpcrationsAbstractSyntaxcs( 12) version 1(0)} id-acDircctoryAccessAC. id-rosObject4ua, id-rosObject-dircctory, id-rosObject-dapDSA. ideontract4ap. id-package-dapConnection. id-package-read, id-package-search. kl-package-modify. id-as-dircctoryAccessAS FROM ProtocolObjectldentifiere protocolObjcct Identifiers dircctoryBind. directorylinbind, read, compare, abandon, list, search. addEntry, removeEntry, modifyEntry. modil'yDN

FROM Direc ton,'Abstract Service directoryAbstractService

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

directoryAcccssAC    APPLIC’ATION-CONTEXT    {

CONTRACT    dapContract

ESTABLISHED BY    acse

INFORMATION TRANSFER BY    pData

ABSTRACT SYNTAXES    {acse-abstract-syntax I

d ircctoryAcccssAbst ract Syntax}

APPLICATION-CONTEXT NAME    id-ac-directoryAcccssAC |

-    - обьскты-УУО - -

dua    ROS-OBJECT-CLASS    ::-    {

INITIATES    {dapContract)

ID    id-rosObject-dua}

directory    ROS-OBJECT-CLASS    -    <

RESPONDS    (dapContract}

ID    id-rosObjcct-dircctory }

dap-dsa    ROS-OBJECT-CLASS    ::    =    {

RESPONDS    (dapContract}

ID    id-rosObject-dapDSA }

23

Страница 28

ГОСТ I* ИСО/МЭК 9594-5-98

-    - Контракты - -

dapContract    CONTRACT

CONNECTION INITIATOR CONSUMER OF

dapConneclion Рас kage {readPackage | scarchPackage | modifyPackage} id-conimct-dap J

ID

-    - Пакет управления соединением -dapC'onnectionPackagc

CONNECTION-PACKAGE { directoryBind directory Unbind id-packagc-dapC'onneclion J

OPE RATI ON-PACKAGE    |

{read I compare | abandon) id-package-read)

OPERATION-PACKAGE - { (list | search} id-packagc-search }

BIND

UNBIND

ID

-    - Пакет чтения - -read Package

CONSUMER INVOKES

ID

-    - Пакет поиска - -scarchPackage

CONSUMER INVOKES

ID

-    - Пакет модификации - -modify Package

CONSUMER INVOKES

operation-Package - {

(addEntry | rcmovcEntry | modifyEntry | modifyDN } id-package-modify }

ID

- - Абстрактный синтаксис directoryAccessAbstractSynlax

DAP-PDUs IDENTIFIED BY DAP-PDUs

basic Ros

ABSTRACT-SYNTAX

{

id-as-MireclorvAccessAS J CHOICE (

ROS {(DAP-lnvokelDSet}. (DAP-lnvokablE), {DAP-Returnable}},

Bind {directory Bind}.

bind

unbind

DAP-lnvokelDSet

DAP-lnvokable

Unbind {directorvUnbind}}

(Invokeid (ALL EXCEPT absent:NULL)

OPERATION

(read | compare | abandon | list I search j addEntry | remove Entry | modifyEntry | mtxlifvDN }

DAP-Returnable

OPERATION

(read j compare | abandon | list | search j iiddEntry | rcmovcEntry j modifyEntry | modify DN |

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code

Code


local: 1 local: 2 local: 3 local: 4 local: 5 local: 6 local: 7 local : S local: 9

local: I local: 2 local: 3 local: 4 local: 5 local: 6 local : 7 local: S

local: 9


Code :: =


-    - Колы удаленных операций - -id-opcodc-read id-opcodc-compare id-opcodc-abandon id-opcode-lisl id-opcodc-search id-opcode-addEntry

id -opcodc - removcEnt ry id-opcode-modifyEntrv id-opcode-modifyDN

-    - Коды ошибок удаленных операций id-errcodc-attributeError

id -encode-name E rror id -encode -sc rvice Error id -errcode-re ferral id -crrcode-abandoncd id-errcode-securilyError id-errcode-abandonFailed id-encode-updateEnor

-    - Коды удаленных ошибок для ПСС id-errcodc-dsaRcferral

END


24

Страница 29

ГОСТ Р ИСО/МЭК 9594-5-98

ПРИЛОЖЕНИЕ В

(обязательное/

ПРОТОКОЛ СИСТЕМЫ СПРАВОЧНИКА В ACII.1

В данном приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля ACH.l «DircctorySystemProtocol».

DirectorySystem Protocol {joint-iso-ccitt ds{5( module! П dsp(12} 2|

DEFINITIONS :: -BEGIN

- - EXPORTS All - -

-    - Определенные в атом модуле типы и значения экспортируются для использования в других модулях АСИ. I,

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

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

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

-    -необходимым при обслуживании или усовершенствовании услуг справочника.

IMPORTS

distributedOpcrations. protocolObjcct Identifiers FROM Useful Definitions {joint-iso-ccitt ds(5) module(l) usefulDefinitions(O) 2}

ROS-OBJECT-CLASS. CONTRACT. OPERATION-PACKAGE, CONNECTION-PACKAGE. Code, OPERATION

FROM Rcmote-Opcrations-lnformation-Objects {joint-iso-ccitt rcmote-opcrations(4) informalionObjects(5) version 1<0)}

ROS{}, Bind{}. Unbind!), InvokcID

FROM Rcmote-Operations-Gencnc-ROS-PDUs {joint-iso-ccitt remote-operations(4) generic-ROS-PDUs (6) version 1(0)}

APPLICATION-CONTEXT

FROM Remote-Operations-Information-Objccts-exlension {joint-iso-ccitt rcmote-operations(4) informationObjects-extension(8) version 1(0» acse, pData

FROM Remote-Operations-Realisations {joint-iso-ccitt rcmote-operations<4) realisations(S) version 1(0)1 acse-abst ract -syntax

F RO M Re mote - Ope rat ions-Abst ract - Syntaxes {joint-iso-ccitt remote-operations(4) remoteOpcrationsAbstractSyntaxcs<12) version 1<0)> id-ac-directorySystemAC. id - rosObkxt -dsp DSA. id-contract-dsp. id-package-dspConnection. id-package-chaincdRcad. id-packagc-chaincdSeaich, id-package-chainedModify, id-as-directorySystemAS FROM ProtocolObjectldcntifiers protocolObjcct Identifiers dSABind, dSAUnbind, chaincdRcad. chainedComparc, chainedAbandon, chainedList, chainedScarch, chainedAdd Entry, chained RemoveEntry. chainedModifyEntry. chained Modify DN FROM DistributedOperations dLstributedOperations

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

directorySystemAC    APPLICATION-CONTEXT    :: = |

CONTRACT    dspContract

ESTABLISHED BY    acse

INFORMATION TRANSFER BY pDua ABSTRACT SYNTAXES    jacse-abstract-syntax

| directoryAccessAbstractSyntax!

APPLICATION-CONTEXT NAME    id-ас-directorySystemAC    1

-    - Объекты-УУО - -

dsp-dsa    ROS-OBJECT-CLASS    ::-    {

BOTH    {dspContract}

ID    id-rosObject-dspDSA }

-    - Кон факзы - -

dspContract    CONTRACT    {

CONNECTION    dspConnection Package

OPERATIONS OF    (chained Read Package

| chainedSearchPackage j chainedModifyPackage }

ID    id-contract-dsp J

25

Страница 30

ГОСТ I* ИСО/МЭК 9594-5-98

- - Пакет упраа'1С1Ш51 соединением - -

dspConnectionPackagc BIND UNBIND ID

- - Сцепленный пакет чтения chained ReadPackagc OPERATIONS

ID

- - Сцепленный пакет поиска - -chainedScarchPackage OPERATIONS ID

CONN ЕСТ I ON-PACKAGE :: -dSABind dS A Unbind

id-package-dspConnection }

OPERATION-PACKAGE :: - { (chained Read ] chainedCompare | chaincdAbandon} id-packagc-chaincdRead \

OPERATION-PACKAGE :: = ( (chainedList | chainedScarch) id-packagc-chaincdSearch J


- - Сцепленный пакет модификации - -

chained.VlodifyPackage

OPERATIONS

ID

- - Абстрактный синтаксис directorySysteinAbstraciSvntax

DSP-PDUs IDENTIFIED BY DSP-PDUs basic Ros


bind

unbind

DSP-lnvokclDSet

DSP-lnvokable


DSP-Returnable OPERATION


END


id-as-directorvSvxtcmAS )

CHOICE (

ROS «DSP-lnvokclDSetI, {DSP-lnvokable}, {DSP-Returnable}},

Bind {dSABind},

Unbind {dSAL'nbind))

:: - {InvokeID (ALL EXCEPT absent:NLLL)


{ chained Read | chainedCompare | chaincdAbandon | chainedList j chained Search | chainedAddEntry j chainedRemoveEntry | chainedModifyEntry j chainedModifyDN }

{chainedRead | chainedCompare | chaincdAbandon | chainedList | chainedSearch j chainedAddEntry j chainedRemoveEntry | с ha ined M odi fy Entry JchainedModify DN 1


OPERATION-PACKAGE {chainedAddEntry | chainedRemoveEntry | chaincd.ModifyEntry | chained Modify DN ) id-package-chaincdModifv }

ABSTRACT-SYNTAX :: - {


OPERATION


(


26

Страница 31

ГОСТ Р ИСО/МЭК 9594-5-98

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

ПРОТОКОЛ ТЕНЕВОЙ ИНФОРМАЦИИ СПРАВОЧНИКА В ACII.1

В данном приложении приведены определения всех соответствующих типов и значений АСН.1. содержа-шихся в настоящем стандарте, в виде модуля ACH.l «DirectorylnformatJonShadowProtocol». DircctorvlnformationShadowPmtocol {joint-iso-ccitt ds(5) module(l) dLsp(!6) 2)

DEFINITIONS :: -BEGIN

- EXPORTS All ~

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

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

-    - программы могуг использовать их для своих собственных целей, но это не препятствует расширениях!

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

directoryShadowAbstractService, protocolObjcct Identifiers

FROM Useful Definitions {joint-iso-ccitt ds<5) module(l) useful Definitions(O) 2}

ROS - О В J ECT-C LASS. CONTRACT. OPER\TION-PACKAGE, CONNECTION-PACKAGE. Code, OPERATION

FROM Rcmotc-Opcrations-1nformation-Objects {joint-iso-ccitt remotc-operations(4> informal ionObjects(5) version 1(0)}

ROS{}, Iiind{>. L!nbind{). InvokelD

FROM Rcmotc-Operations-Genenc-ROS-PDUs {joint-iso-ccitt remote-operations(4) generic-ROS-PDUs (6) versionl(O)}

APPLICATION-CONTEXT

FROM Remote-Operations-1 nformat ion-Objects-extension {joint-iso-ccitt remotc-opcrations(4) informationOb jects-extcnsion(8> version 1 (0)} acse, pData. association-by-RTSE, transfcr-by-RTSE FROM Remote-Operations-Realisations {joint-iso-ccitt remote-operations(4) rcalisalions(8) version 1(0)} acscc-abstract-syntax, rtse-abstract-syntax

FROM Remote-Operations-Abstract-Syntaxes {joint-iso-ccitt remote-operations(4) remotcOperationsAabstractSyntaxcs( 12) version 1(0» id-ac-shadowSupplierlnitiatedAC, id-ac-shadowConsumcrlnitiatedAC, id-ac-reliableShadowSupplicrlnitiatedAC, id-ac - rel iableShadowConsu merl n it iat edAC

id-rosObject-imtiatingConsumerDSA. id-rosObject-responding-SupplierDSA, id-rosObject-initiatingSupplierDSA. id-rosObject-rcspondingConsumerDSA. id-contract-shadowConsumer. id-contract-shadowSupplier, id-package-dispConnection

id-package-shadowConsumer. id-package-shadowSupplier,    id-as-directory Shadow AS,    id-as-

directoryReliablcShadowAS. id-as-reliableShadowBindingAbstractSyntax FROM ProtocolObjectldenlificrs protocolObjcctIdentifiers dSAShadowBind, dSAShadowUnbind, requestShadowCpdate.updateShadow. coordinatcShadowUpdate FROM DirectoryShadowAbstractService directoryShadowAbstractService RTSE-apdus FROM Rcliable-Transfer-APDL's (joint-iso-ccitt rcliable-t ransfer(3) apdus(O) ) ;

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

APPLICATION-CONTEXT :: - {

shadowSupplierC'ontract

acse

pData

{rtse-abstract-syntax |

dinxtoryShadowSyntax)

id-ac-shadowSupplierlnitiatcdAC )

APPLICATION-CONTEXT - {

shadowConsumerContract

acse

pData

CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTRACT SYNTAXES

APPLICATION-CONTEXT NAME shadowConsumerlniliatedAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY

27

Страница 32

ГОСТ I* ИСО/МЭК 9594-5-98

{acsc-syntax | dircctoryShadowSyntax J id-ac-shadowC'onsumerlnitiatedAC ) APPLICATION-CONTEXT :: = { shadowSupplicrContract association-by- RTSE transfer-by-RTSE

ABSTRACT SYNTAXES APPLICATION-CONTEXT NAME rehablcShadowSupplicrlnitiatedAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTRACT SYNTAXES

{rcliableShadowBindingAbMractSyntax | rtse-abstract-syntax j rtscAndShadowBindingAbstractSyntax} id-ac-rcliableShadowSupplicrlniliatcdAC У APPLICATION-CONTEXT :: = { shadowConsumcrContract association-by-RTSE transfer-by-RTSE

APPLICATION-CONTEXT NAME rcliablcShadowConsumcrlnitiatedAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTRACT SYNTAXES

{rcliablcShadowBindingAbstractSynlax | rtsc-abstract-syntax | rtscAndShadowBmdingAbstractSyntax ) id-ac-rcliablcShadowConsumcrlnitiatedAC }

APPLICATION-CONTEXT NAME

-    - Объекты-УУО - -iniliating-consumcr-dsa

INITIATES ID

responding-supplier-dsa RESPONDS ID

initiating-supplier-cka INITIATES ID

respond i ng-consu me r-dsa RESPONDS ID

-    - Контракты - -shadowConsumcrContract

CONNECTION INITIATOR CONSUMER OF ID

shadowSupplicrContract CONNECTION

RESPONDER CONSUMER OF ID

-    - Пакет управлении соединением - -dispC'onnection Package

BIND

UNBIND

ID

-    - Пакеты - -shadowConsuincrPackage

CONSUMER INVOKES SUPPLIER INVOKES ID

shadowSupplierPackage SUPPLIER INVOKES

ID

-    - Абстрактный синтаксис - -dircctoryShadowAbstractSyntax

ROS-OBJECT-CLASS ::= { {shadowConsumcrContract} id-rosObjcc!-initiatingConsumcrDSA ) ROS-OBJECT-CLASS    {

{shadowConsumcrContract) id-rosOhject-rcspondingSupplicrDSA } ROS-OBJECT-CLASS    {

{shadowSu ppl ic rCont гас 11 id-rosObject-mitiatingSupplierDSA } ROS-OBJECT-CLASS ::= { {shadowSupplicrContract) id-rosObjcct-respondingC'onsumerDSA }

CONTRACT    :: - (

dispConnection Package {shadowConsumcrPackagc [ id-contract-shadowConsumcr ) CONTRACT    :: “ (

d ispCon ncction Рас kagc {shadowSupplierPackage} id-contracl-shadow Supplier }

CONNECTION-PACKAGE : : - ( dSAShadowBind dSAShadow Unbind id-package-dispConncction f

OPE RATION - РАС KAG E :: = {

{request ShadowU pdatc}

{updatcShadow} id-packagc-shadowConsumcr ) OPERATION - PACKAGE {

{coord inatcShadowUpdate | updatcShadow} id-pacLagc-shadowSupplier }

ABSTRACT-SYNTAX :: - { DISP-PDUs

IDENTIFIED BY    id-as-directoryShadowAS J

directorvRcliablcShadowAbstractSvntax    ABSTRACT-SYNTAX :: = {

Rcliablc-DISP-PDUs

IDENTIFIED BY    id-as-dircctoryRcliableShadowAS J

28

Страница 33

ГОСТ Р ИСО/МЭК 9594-5-98

ABSTRACT-SYNTAX

rtseAnd ShadowBindingAbstractSyntax ReliableShadowBinding- PDUs IDENTIFIED BY DlSP-PDlls basic Ros

•{

id-as- rcl iablcShadow Bi ndi ngAbst ractSyntax } :: - CHOICE (

ROS {{DISP-lnvokelDSet}, <DISP-lnvokable|,

{DISP-Returnable}).

Bind {dSAShadowBind},

bind

unbind

Reliable-DISP-PDUs

Unbind {dSAShadowUnbind}}

:: =■ ROS |(DISP-InvokelDSet}, {DISP-lnvokabk}. {DISP-Retumable}},

:: - CHOICE {

ReliableShadowBinding-PDUs rTS bind unbind DISP-lnvokelDSet : DlSP-lnvokable

RTSE-apdus.

Bind {dSAShadowBind}.

Unbind (dSAShadowUnbind}J Invokcld <ALL EXCEPT abseni:NULL)

OPERATION :: ■=( rcquestShadowUpdatc | UpdateShadow | coordinateShadowUpdate } OPERATION : :    request Shadow Update

DISP-Retumable

| updateShadow | coordinateShadowUpdate }

- - Колы удаленных операций - -

Code

Code

Code


local

local

local


Code :: ”


local: I


id-opcodc-rcquestShadowUpdate id-opcode-updateShadow id-pcode-coordinateShadowUpdate

- - Коды ошибок удаленных операций - -id-errcode-ShadowError


29

Страница 34

ГОСТ I* ИСО/МЭК 9594-5-98

ПРИЛОЖЕНИЕ О

(обязательное)

ПРОТОКОЛ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ ЭКСПЛУАТАЦИОННЫМИ СВЯЗЯМИ СПРАВОЧНИКА В АСНЛ

В данном приложении приведены определения всех соответствующих типов и значений ACH.I, содержащихся в настоящем стандарте, в виде модуля АСНЛ «DircctoryOperationalBinding Management Protocol». DircctoryOpcrationalBindingManagemcntProtocol {jomt-iso-ccitt ds(5) module) 1) dop(l7) 2)

DEFINITIONS : : -BEGIN

- - EXPORTS AH - -

-    - Определенные в этом модуле типы и значения экс порт руются для использования в других модулях АСНЛ.

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

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

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

-    -необходимым при обслуживании или усовершенствовании услуг справочника.

IMPORTS

protocolObject Identifiers, directory AbstractService, opBindingManagement FROM Useful Definitions {joint-iso-ccitt ds(5> module(l) useful Definitions^)) 2} directoryBind. directoryUnBmd FROM DirectorvAbst ract Service dircctorvAbstractServicc ROS-OBJECT-CLASS. CONTRACT, OPE RATION-PACKAGE, CONNECTION-PACKAGE, Code.

FROM Remote-Operations-Informal ion-Objects {joint-iso-ccitt remote-opcrations(4> inforination0bjects(5) version 1(0)}

ROS{}, Iiind{}. UnbindJ). InvokelD

FROM Remote-Opemtions-gcncric-ROS-PDUs {joint-iso-ccitt remote-operalions(4) generic-ROS-PDUs (6) version 1(0)}

APPLICATION-CONTEXT

FROM Rcmote-Operations-lnformation-Objects-exlension {joint-iso-ccitt rcmote-operations(4) informationObjcct-exlcnsion(8) version 1(0)} acsc. pData

FROM Re mote-Operations-Realisations {joint-iso-ccitt rcmote-operations(4) realisations^) version 1(0)} acse-abstract-syntax

F RO M Remote -Ope rat ions-Abst ract - Syntaxes {joint-iso-ccitt renn>tc-opcrdtions{4) remotcOpcrationsAbstractSyntaxcs(12) version 1(0)} id-ac-dircctoryOpcrationalBindingManagcmenlAC. id-rosObject-dopDSA. id-contract-dop, id-package-dopConnection, id-packagc-operationalBindingManagement, id-as-dircctoryOpcrationalBindingManagemcntAS

FROM ProtocoIObjectldcntificrs protocolObject Identifiers establishOperationalBinding, modifyOperationalBinding, terminateOperationalBinding, dSAOperational-BindingManagementBmd. dSAOpcrationalBinding.ManagementUnbind FROM OpcrationalBindingManagement opBindingManagement:

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

directoryOpcrationalBindingManagcmentAC    APPLICATION-CONTEXT    :: *» {

CONTRACT    dopContract

ESTABLISHED BY    acsc

INFORMATION TRANSFER BY    pData

ABSTRACT SYNTAXES    (acse-abstract-syntax |

directoryOpcrationalBindingManagcmenlAbslractSyntax| APPLICATION-CONTEXT NAME    id-ас-director) OperationalBindingManagementAC }

-    - Обьекты УУО - -

dop-dsa    ROS-OBJECT-CLASS    :: =• {

BOTH    {dopContract}

ID    id-rosObject-dopDSA }

-    - Контракты - -

dopContract    CONTRACT    :: =■ {

CONNECTION    dopC'onncctionPackage

30

Страница 35

ГОСТ Р ИСО/МЭК 9594-5-98

INITIATOR CONSUMER OF (dopPackage) ID    id-contract-dop

- - Пакет управления соединением - -

dopCon nect ion Рас kage BIND UNBIND ID

- - Пакеты - -dopPackage

CONSUMER INVOKES

ID

CONNECTION-PACKAGE :: - { dS AOpcrat ional Bi ndi ng Manage me nt Bind dSAOperationalBindingManagemcntUnbind id-package-dopConnection }

OPERATION-PACKAGE : : - { [cstablishOperational Binding | modifyOperationalBinding I lerminateOperationalBinding } id-package-OpcrationalBindingManagement


ABSTRACT-SYNTAX

- - Абстрактный синтаксис - -directorvOpcrationalBindingManagcmentAbstractSyntax DOP-PDUs IDENTIFIED BY DOP-PDUs :: - CHOICE basic Ros

id-as-directoryOperationalBindingManagementAS } {

ROS {{DOP-lnvokclDSetf, {DOP-lnvokable}.

{DOP-Retumable}}. bind    Bind {diirctoryBind},

unbind    Unbind (directorvUnbind))

DOP- Invoke I DSel    :: - InvokcID (ALL EXCEPT absent:NULL)

DOP-lnvokable OPERATION :: * {cstablishOpcrationalBinding

| modifyOperationalBinding | terminateOperationalBinding } DOP-Retumable OPERATION :: « { cstablishOperationalBinding

| modifyOperational Binding | lerminateOperationalBinding }

- - Коды удаленных операций - -

id-op-cstablishOperational Binding

Code :

: " local:

100

id-op-modifyOpcrational Binding

Code :

:» local:

102

id-op-terminateOperationalBinding

Code :

: local:

101

- - Коды ошибок удаленных операций - -

id-e rr-ope rational BindingError

Code :

: =• local:

100

END

31

Страница 36

ГОСТ Р ИСО/МЭК 9594-5-98

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

ЭТАЛОННОЕ ОПРЕДЕЛЕНИЕ ИДЕНТИФИКАТОРОВ ОБЪЕКТОВ ПРОТОКОЛА

В данном приложении приведены все идентификаторы объектов АС‘Н.1, присвоенные в настоящем стандарте, в виде модуля АС'Н.1 «ProtocolObjectldentifiers*.

ProtocolObjectIdentifiers {joint-Lvo-ccitl ds(5) module(l) protocolObject Identifiers^) 2j DEFINITIONS : : =■

BEGIN

- - EXPORTS All - -

-    - Определенные в этом модуле типы и значения экспортируются для использования в других модулях ACH. I.

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

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

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

-    -необходимым при обслуживании или усовершенствовании услуг справочника.

IMPORTS

id-rosObject. id-contract, id-package, id-ас, id-as FROM Uscfuldefinitions (joint-iso-ccitt ds<5) module(l) usefulDefinitions{0) 2}

- - Объекты УУО - -

id-rosObject-dua

id-rosObject-dircclory

id-rosObject-dapDS A

id-rosObjecl-dspDSA

id- rosObject -dopDSA

id-rosObject-initiatingConsumerDSA

id-rosObject-rcspondingSupplicrDSA

id-rosObject-initiatingSupplierDSA

id-rosObject-respondingConsumerDSA

-    - Контракты - -id-contract-dap id-contract-dsp id-contract-shadowConsumer id-contract-shadowSupplier id-contract-dop

-    - Пакеты - -id-package-read id-package-search id-package-modify id-package-chained Read id - package -cha i ned Searc h id-package-chained Modify id-packagc-shadowConsumer id-package -shadowSupplier

id-package-operational BindingManagement id - package-dapCon nect ion id-package -dspConneclion id-package -dispConnection id-package-dopConnect ion

-    - Прикладной контекст - -id-ac-directoryAccessAC id-ac-directorySystemAC

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

id-ac-directoryOperationalBindingManagemenlAC

id-ac-shadowConsumcrlnhiatcdAC

id-ac-sliadowSupplierlnitiatedAC

id-ac-reliableShadowSupplierlnitiatedAC

id-ac-reliableShadowConsumerlnitiatedAC

id-ac-shadowSupplierlnitiatedAsynchronousAC

id-ac-shadowCoimimerlnitiatedAsynchronousAC

OBJECT IDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER OBJECTIDENTIFIER

id-rosObject 1) id-rosObject 2) id-rosObject 3) id-rosObject 4) id-rosObject 7) id-rosObject S) id-rosObject ‘)| id-rosObject 10} id-rosObject 11}

id-contract I) id-contract 2} id-contract 3} id-contract 4} id-contract 5}

id-package 1} id-package 2} id-package 3} id-package 4} id-package 5} id-package 6} id-package 7} id-package 8} id-package 9} id-package 10} id-package 11) id-package 12} id-package 13}

(id-ac 1}

(id-ac 2}

|id-ac 3}

{id-ac 4}

(id-ac 5}

(id-ac 6}

(id-ac 7}

(id-ac 8}

(id-ac 9}

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

OBJECTIDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER


32

Страница 37

ГОСТ Р ИСО/МЭК 9594-5-98

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT

OBJECT


IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER

IDENTIFIER


{id-asc П {id-asc 2) {id-asc 3} {id-asc 4} {id-asc 5} {id-asc 6} {id-asc 1) {id-asc 8) {id-asc 9}

{id-as 1} {jd-as 2} {id-as 3} |jd-as 4} {id-as 5} {jd-as 6}


-    ASts (obsolete} -

-    id-ase-readASE

-    id-asc-searchASE

-    id-ase-modify AS E

-    id-asc-chaincdReadASE

-    id-ase-chainedSearchASE

-    id-asc-chainedModifyASE

-    id-ase-opcrationalBmdingManagcmcntASE

-    id-ase-shadowCoasumerASE

-    id-ase-shadowSupplierASE

- - Абстрактный синтаксис - -id-as-directoryAccessAS id-as-dircctorySystcmAS id-as-directory$hadowAS

id-avdircctoryOperational Binding Management AS id-as-d i rcctory Rel iable Shadow.-4S id-as-reliablcShadowBindingAbstraclSvntax END


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

ТИПЫ ЭКСПЛУАТАЦИОННЫХ СВЯЗЕЙ СПРАВОЧНИКА

В данном приложении приведены в виде модуля ACH.l «DircctoryOpcrationalBmdingTypes® все присвоенные идентификаторы объектов ACH.I, предназначенные для определения типов эксплуатационных связей, реализуемых в настоящем стандарте.

DircctoryOpcrationalBinding Types

{joint-iso-ccitt ds<5) modulc(l) directoryOperationalBindingTypes(25) 2|

DEFINITIONS :: -BEGIN

- - EXPORTS All - -

-    - Определенные в этом модуле типы и значения экспортируются для использования в других модулях ACH.I,

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

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

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

-    -необходимым при обслуживании или усовершенствовании услуг справочника.

IMPORTS

id-ob

FROM Uscfuklefinitions (joint-iso-ccitt ds(5) module) 1) nsclulDclinitions(O) 2}; id-op-binding-siiadow    OBJECT    IDENTIFIER    :: **    {id-ob 1)

id-op-binding-hierarchical    OBJECT    IDENTIFIER    (id-ob 2}

id-op-binding-non-spccific-hicrarchical    OBJECT    IDENTIFIER    {id-ob 3}

END

33

Страница 38

ГОСТ Р ИСО/МЭК 9594-5-98

УДК 681.324:006.354    ОКС    35.100.70    П85    ОКСТУ4(И)2

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

Редакюр В. II. О.-урцоа Технический реликтор Л. Л. Кузнецова Корректор М. И. Першиыа Компьютерная верстка 3. II Мартлтолои

Изд. лиц. № 021007 OI 10.08.95. Сиама и набор 26 05.98. Подписано п печать I0.0S.98: Уел. леч. л. 4.18. Уч.-и м. л. 4.10.

Тира* 228 эхл. С/Д 5344. Зак. 423.

ИНК Издательство спшлпртов,107076. Мое кии. Колоне ш и й пер.. 14.

Нибраио и Калужской тишнрифи» стандартов на ПЭВМ.

Калужская типография стандартов. ул. Московская. 256.

ПЛР № 040138