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

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

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

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

СПРАВОЧНИК

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

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

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

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

ShadowConsumerContract    CONTRACT    :    :    =    {

CONNECTION    dispConnectionPackage

INITIATOR CONSUMER OF    {shadowConsumerPackage}

ID    id-contract-shadowConsumer    }

shadowSupplierContract    CONTRACT    :    :    =    {

CONNECTION    dispConnectionPackage

RESPONDER CONSUMER OF    {shadowSupplierPackage}

ID    id-contract-shadowSupplier    }

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

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

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

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

dispConnectionPackage    CONNECTION-PACKAGE : : = {

BIND    dSAShadowBind

UNBIND    dSAShadowUnbind

ID    id-package-dispConnection }

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

shadowConsumerPackage    OPERATION-PACKAGE : : = {

SUPPLIER INVOKES    {coordinateShadowUpdate

| updateShadow}

ID    id-package-shadowSupplier }

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

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

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

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

CONNECTION    dopConnectionPackage

OPERATIONS OF    {dopPackage}

ID    id-contract-dop    }

7

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

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

dopConnectionPackage    CONNECTION-PACKAGE : : = {

BIND    dSAOperationalBindingManagementBind

UNBIND    dSAOperationalBindingManagementUnbind

ID    id-package-dopConnection }

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

dopPackage OPERATION-PACKAGE : : = {

CONSUMER INVOKES {establishOperationalBinding

| modifyOperationalBinding | terminateOperationalBinding}

ID    id-package-operationalBindingManagement}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

него.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9

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

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

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

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

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

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

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

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

directoryAccessAbstractSyntax ABSTRACT-SYNTAX : : = {

DAP-PD Us

id-as-directoryAccessAS }

CHOICE {

ROS {{DAP-InvokelDSet}, {DAP-InvokablE},

{DAP- Returnable}},

Bind {directoryBind},

Unbind {directoryUnbind}}

: : = InvokelD (ALL EXCEPT absent:NULL)

: = { read | compare | abandon | list | search | addEntry | removeEntry | modifyEntry | modifyDN }

: = { read | compare | abandon | list | search | addEntry | removeEntry | modifyEntry | modify DN }

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

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

directorySystembstractSyntax ABSTRACT-SYNTAX : : = {

DSP-PDUs

id-as-directorySystemAS }

CHOICE {

ROS {{DSP-InvokelDSet}, {DSP-Invokable},

{DSP-Returnable}},

Bind {dSABind},

Unbind {dSAUnbind}}

: : = InvokelD (ALL EXCEPT absent:NULL)

chainedRead | chainedCompare chainedAbandon | chainedList | chainedSearch | chainedAddEntry chainedRemoveEntry | chainedModifyEntry chainedModifyDN }

10

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

DSP-Returnable OPERATION : : = { chainedRead | chainedCompare

| chainedAbandon | chainedList 1 chainedSearch 1 chainedAddEntry | chainedRemoveEntry 1 chainedModifyEntry | chainedModifyDN }

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

СЭП справочника реализуют указанные в 6.5 пакеты управления операциями, которые определяются в абстрактном синтаксисе «directoryShadowAbstractSyntax» или «directoryReliableShadow-AbstractSyntax» в зависимости от использования СЭНП в прикладном контексте. Эти два абстрактных синтаксиса определяются в виде информационных объектов класса ABSTRACT-SYNTAX. directoryShadowAbstractSyntax ABSTRACT-SYNTAX : : = {

DISP-PDUs    : : = CHOICE {

basicRos    ROS {{DISP-InvokelDSet}, {DISP-Invokable},

{DISP-Returnable}},

Bind {dSAShadowBind},

Unbind {dSAShadowUnbind}}

: : = ROS {{DISP-InvokelDSet},

{DISP-Invokable},

{DISP-Returnable}},

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

bind    Bind {dSAShadowBind},

unbind    Unbind {dSAShadowUnbind}}

DISP-InvokelDSet    : : = InvokelD (ALL EXCEPT absent:NULL)

DISP-Invokable OPERATION    :    : = { requestShadowUpdate

| updateShadow | coordinateShadowUpdate }

DISP-Returnable OPERATION    :    : = { requestShadowUpdate

| UpdateShadow | coordinateShadowUpdate }

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

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

id-as-directoryOperationalBindingManagementAS } CHOICE {

ROS {{DOP-InvokelDSet}, {DOP-Invokable}, {DOP-Returnable}},

Bind {directoryBind},

Unbind {directoryUnbind}}

11

InvokelD (ALL EXCEPT absent:NULL) establishOperationalBinding | modifyOperationalBinding | terminateOperationalBinding }

{ establishOperationalBinding 1 modifyOperationalBinding | terminateOperationalBinding}

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

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

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

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

directoryAccessAC    APPLICATION-CONTEXT    : : = {

CONTRACT    dapContract

ESTABLISHED BY    acse

INFORMATION TRANSFER BY    pData

ABSTRACT SYNTAXES    (acse-abstract-syntax

1 directory AccessAbstractSyntax}

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

1 directoryAccessAbstractSyntax}

APPLICATION CONTEXT NAME    id-ac-directorySystemAC }

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

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

7.2.3.1 Начальные контексты теневого поставщика

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

APPLICATION-CONTEXT : : = { ShadowSupplierContract acse pData

{acse-abstract-syntax 1 directoryShadowSyntax} 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

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

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

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

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

APPLICATION-CONTEXT : : = { shadowConsumerContract acse pData

{acse-syntax I directoryShadowSyntax

id-ac-shadowConsumerlnitiatedAC }

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

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

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

reliableShadowConsumerlnitiatedAC CONTRACT ESTABLISHED BY INFORMATION TRANSFER BY ABSTi-tACT SYNTAXES

APPLICATION CONTEXT NAME

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

APPLICATION-CONTEXT : : = { dopContract acse pData

{acse-abctract-syntax | directoryOperationalBindingManagementAbstractSyntax} APPLICATION CONTEXT NAME    id-ac-directoryOperationalBindingManagementAC    }

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

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

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

id^opcode-compare    Code

id-opcode-abandon    Code

id-opcode-list    Code

id-opcode-search    Code

id-opcode-addEntry    Code

id-opcode-removeEntry    Code

id-opcode-modifyEntry    Code

id-opcode-modifyDN    Code

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

Следующие коды операций используются пакетами управления операциями ПТИС:

id-opcode-requestShadowUpdate    Code

id-opcode-updateShadow    Code

id-opcode-coordinateShadowUpdate    Code

13

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

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

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

id-op-terminateOperationalBinding    Code    :    : =    local :    101

7.4    Коды ошибок

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

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

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

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

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

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

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

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

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

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

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

7.5.1    АПС к АСС

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

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 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-na-REJECT или прерывать прикладную ассоциацию) и

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

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

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

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

7.5.2 АС С к АС С

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

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

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

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

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

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

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

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

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

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

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

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

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

15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1.1.1.1    Режим

16

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

Содержание

Введение ................................................ IV

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

III

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

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

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

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

a)    для ПДС — directoryAccessAC;

b)    для ПСС — directorySystemAC;

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

d)    для ГТТИС — shadowSupplierlnitiatedAC или shadowConsumerlnitiatedAC.

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

Преобразование услуги DirectoryBind или DSABind в параметры «информация пользователя» примитива П-АССОЦИАЦИЯ запрос определено ГОСТ Р ИСО/МЭК 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    К а ч е с т в о у с л у г

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

8.1.1.1.6    Требования сеансового уровня

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

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

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

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

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

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

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

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

8.1.1.2.1    Результат

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

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

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

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

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

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

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

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

17

Введение

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

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

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

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

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

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

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

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

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

IV

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

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

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

Ч а с т ь 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 Информационная технология. Взаимосвязь открытых систем (ВОС). Базовая эталонная модель. Часть 1. Базовая модель

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

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

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

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

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

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

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

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

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

ИСО/МЭК ПМС 9072-3* Системы обработки информации. Передача текста. Удаленные операции. Часть 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)    управляющая информация протокола прикладного уровня;

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

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

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

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

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

c)    ошибка;

d)    операция;

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

f)    объект-УУО.

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

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

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

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

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

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

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

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

4    СОКРАЩЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5    СОГЛАШЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

3

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

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

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

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

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

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

dua    ROS-OBJECT-CLASS    : : = {

INITIATES    (dapContract)

ID    id-rosObject-dua)

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

RESPONDS    (dapContract)

ID    id-rosObject-directory)

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

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

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

RESPONDS    (dapContract)

ID    id-rosObject-dapDSA)

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

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

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

BOTH    {dspContract}

ID    id-rosObject-dspDSA }

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

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

initiating-consumer-dsa ROS-OBJECT-CLASS : : = {

RESPONDS    {shadowConsumerContract}

ID    id-rosObject-respondingSupplierDSA}

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

initiating-supplierMsa    ROS-OBJECT-CLASS    :    :    =    {

responding-consumerMsa ROS-OBJECT-CLASS : : = {

RESPONDS    {ShadowSupplierContract}

ID    id-rosObject-respondingConsumerDSA }

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

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

BOTH    {dopContract}

ID    id-rosObjectMopDSA}

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

6.3 Контракт и пакеты ПДС

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

CONNECTION    dapConnectionPackage

INITIATOR CONSUMER OF {readPackage | searchPackage

| modifyPackage}

ID    id-contract-dap }

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

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

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

dapConnectionPackage    CONNECTION-PACKAGE : : = {

BIND    directoryBind

UNBIND    directoryUnBind

ID    id-package-dapConnection    }

5

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

readPackage    OPERATION-PACKAGE : : = {

CONSUMER INVOKES    {read | compare | abandon}

ID    id-package-read }

searchPackage    OPERATION-PACKAGE : : = {

CONSUMER INVOKES    {list | search}

ID    id-package-search }

modifyPackage    OPERATION-PACKAGE : : = {

CONSUMER INVOKES    {addEntry | removeEntry

| modifyEntry | modifyDN}

ID    id-package-modify}

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

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

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

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

CONNECTION    dspConnectionPackage

OPERATIONS OF    {chainedReadPackage | chainedSearchPackage

| chained ModifyPackage}

ID    id-contractMsp }

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

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

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

dspConnectionPackage    CONNECTION-PACKAGE    : : = {

BIND    dSABind

UNBIND    dSAUnbind

ID    id-package-dspConnection    }

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

OPERATION-PACKAGE : : = {

{chainedAdd Entry | chainedRemoveEntry | chainedModifyEntry | chainedModifyDN} id-package-chainedModify}

6