юридическая фирма 'Интернет и Право'
Основные ссылки




На правах рекламы:



Яндекс цитирования





Произвольная ссылка:
Описание
Источник публикации
М.: ИПК Издательство стандартов, 1998
Примечание к документу
С 1 июля 2003 года до вступления в силу технических регламентов акты федеральных органов исполнительной власти в сфере технического регулирования носят рекомендательный характер и подлежат обязательному исполнению только в части, соответствующей целям, указанным в пункте 1 статьи 46 Федерального закона от 27.12.2002 N 184-ФЗ.
Документ введен в действие с 1 января 1999 года.
Название документа
"ГОСТ Р ИСО/МЭК 9594-5-98. Государственный стандарт Российской Федерации. Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола"
(принят и введен в действие Постановлением Госстандарта России от 19.05.1998 N 215)

"ГОСТ Р ИСО/МЭК 9594-5-98. Государственный стандарт Российской Федерации. Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола"
(принят и введен в действие Постановлением Госстандарта России от 19.05.1998 N 215)


Оглавление

ГОСТ Р ИСО/МЭК 9594-5-98. Государственный стандарт Российской Федерации. Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола
Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Определения
4. Сокращения
5. Соглашения
6. Общее описание протокола
7. Абстрактный синтаксис протокола справочника
8. Преобразование в используемые услуги
9. Соответствие
Приложение A. Протокол доступа к справочнику в АСН.1
Приложение B. Протокол системы справочника в АСН.1
Приложение C. Протокол теневой информации справочника в АСН.1
Приложение D. Протокол административного управления эксплуатационными связями справочника в АСН.1
Приложение E. Эталонное определение идентификаторов объектов протокола
Приложение F. Типы эксплуатационных связей справочника
Принят и введен в действие
Постановлением Госстандарта
России
от 19 мая 1998 г. N 215
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ
ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ
СПРАВОЧНИК
ЧАСТЬ 5
СПЕЦИФИКАЦИИ ПРОТОКОЛА
Information technology. Open Systems Interconnection.
The directory. Part 5. Protocol specifications
ГОСТ Р ИСО/МЭК 9594-5-98
Группа П85
ОКС 35.100.70
ОКСТУ 4002
Дата введения
1 января 1999 года
Предисловие
1. Разработан Московским научно-исследовательским центром (МНИЦ) Государственного комитета Российской Федерации по связи и информатизации.
Внесен Техническим комитетом по стандартизации ТК 22 "Информационные технологии".
2. Принят и введен в действие Постановлением Госстандарта России от 19 мая 1998 г. N 215.
Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 9594-5-95 "Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола".
3. Введен впервые.
Введение
Настоящий стандарт разработан с целью обеспечения взаимосвязи систем обработки информации, предназначенных для предоставления услуг справочника. Совокупность подобных систем вместе с содержащейся в них информацией справочника может рассматриваться как единое целое, называемое справочником. Информация, хранимая справочником и называемая в целом "информационной базой справочника" (ИБС), используется обычно для обеспечения обмена данными между такими объектами, как логические объекты прикладного уровня, персонал, терминалы и дистрибутивные списки.
Справочник играет существенную роль во взаимосвязи открытых систем (ВОС), цель которой состоит в том, чтобы при минимуме технических согласований вне стандартов по ВОС обеспечить взаимосвязь систем обработки информации:
- поставляемых от различных изготовителей;
- использующих различные методы административного управления;
- имеющих различные уровни сложности;
- использующих различные технологии.
Настоящий стандарт определяет сервисные элементы прикладного уровня и прикладной контекст для двух протоколов - протокола доступа к справочнику (ПДС) и протокола системы справочника (ПСС). ПДС обеспечивает доступ к справочнику для осуществления поиска и модификации информации справочника. ПСС обеспечивает сцепление запросов при осуществлении поиска и модификации информации справочника во всех частях распределенной системы справочника, где может храниться информация.
Кроме того, настоящий стандарт определяет сервисные элементы прикладного уровня и прикладные контексты протокола теневой информации справочника (ПТИС) и протокола управления эксплуатационными связями справочника (ПУЭС). ПТИС обеспечивает теневую информацию, хранимую в одном АСС для другого АСС. ПУЭС обеспечивает установление, модификацию и завершение связей между парами АСС при административных взаимоотношениях между АСС (типа теневых или иерархических отношений).
В Приложении A приведен модуль АСН.1 для протокола доступа к справочнику, в Приложении B - модуль АСН.1 для протокола системы справочника, в Приложении C - модуль АСН.1 для протокола теневой информации справочника, в Приложении D - модуль АСН.1 для протокола управления эксплуатационными связями справочника, в Приложении E - модуль АСН.1, который содержит все идентификаторы объектов АСН.1, используемые в настоящем стандарте, и в Приложении F - модуль АСН.1, который содержит все идентификаторы объектов АСН.1, предназначенные для определения типов эксплуатационных связей, используемых в такого типа стандартах.
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. СОКРАЩЕНИЯ
АСС - агент системы справочника;
АПС - агент пользователя справочника;
ЛОП - логический объект прикладного уровня;
ПБДП - протокольный блок данных прикладного уровня;
ПДС - протокол доступа к справочнику;
ПК - прикладной контекст;
ПСС - протокол системы справочника;
ПТИС - протокол теневой информации справочника;
ПУИП - протокольная управляющая информация прикладного уровня;
ПУЭС - протокол управления эксплуатационными связями справочника;
СЭП - сервисный элемент прикладного уровня;
СЭУА - сервисный элемент управления ассоциацией;
СЭУО - сервисный элемент удаленных операций;
УУО - услуги удаленных операций.
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, значения которого включают абстрактный синтаксис.
Протоколы прикладного уровня ВОС, определенные в настоящем стандарте как ПДС, ПСС, ПТИС и ПУЭС, - это протоколы, обеспечивающие взаимосвязь между двумя прикладными процессами. В среде ВОС эта взаимосвязь представляется в виде обмена данными между двумя логическими объектами прикладного уровня (ЛОП), использующими услуги уровня представления. Функция ЛОП обеспечивается набором сервисных элементов прикладного уровня. Взаимодействие между ЛОП описано в понятиях использования ими услуг, предоставляемых сервисными элементами прикладного уровня. Все услуги, обеспечиваемые сервисными элементами прикладного уровня справочника, содержатся в одном ЛОП.
Сервисный элемент удаленных операций (СЭУО) поддерживает парадигму запрос - ответ операции. СЭП справочника обеспечивают функцию преобразования абстрактно-синтаксической нотации пакетов управления операциями в услуги, предоставляемые УУО. Сервисный элемент управления ассоциацией (СЭУА) поддерживает установление и освобождение ассоциации прикладного уровня между двумя ЛОП. Ассоциации между АПС и АСС могут быть установлены только АПС. Освободить ассоциацию может только ее инициатор.
Для надежной передачи протокольных блоков данных прикладного уровня (ПБДП) в ПТИС факультативно может быть использован сервисный элемент надежной передачи (СЭНП).
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 определяет взаимодействия между двумя АСС в пределах справочника, чтобы поддерживать сцепленные запросы пользователя.
Рисунок 1. Взаимодействия справочника
Объект "directory" представлен в виде набора взаимодействующих АСС. Каждый АСС, включающий "directory", является элементом класса "dap-dsa". Объект "dap-dsa" выполняет роль ответчика в "dapContract".
dap-dsa ROS-OBJECT-CLASS ::= {
RESPONDS {dapContract}
ID id-rosObject-dapDSA}
Кроме взаимодействия с АПС, агенты системы справочника могут взаимодействовать с любым другим объектом для решения различных задач. При таких взаимодействиях должно быть определено число контрактов и объектов-УУО, отражающих способ участия АСС в этих контрактах. Любой реальный АСС может служить примером одного или нескольких таких объектов-УУО АСС.
В общем случае взаимодействия между АСС, необходимые для обеспечения абстрактных услуг справочника при наличии распределенной ИБС, определены как "dspContract". АСС, который участвует в этом контракте, определен как объект-УУО класса "dsp-dsa". Контракт, на который ссылаются в этих спецификациях справочника, определен как абстрактная услуга АСС. АСС определен в виде информационного объекта УУО (см. 6.4).
dsp-dsa ROS-OBJECT-CLASS ::= {
BOTH {dspContract}
ID id-rosObject-dspDSA}
Теневые абстрактные услуги определяют теневую информацию между теневым поставщиком АСС и теневым потребителем АСС. Эти услуги проявляются в двух формах и поэтому определяются как два различных контракта. Они определяются в виде информационных объектов УУО (см. 6.5).
Объект "ShadowConsumerContract" выражает вид услуги, в который теневой потребитель объект-УУО класса "initiating-consumer-dsa" является инициатором контракта. Объект-УУО класса "responding-supplier-dsa" является ответчиком в этом контракте.
initiating-consumer-dsa ROS-OBJECT-CLASS ::= {
INITIATES {shadowConsumerContract}
ID id-rosObject-initiating ConsumerDSA}
responding-supplier-dsa ROS-OBJECT-CLASS ::= {
RESPONDS {shadowConsumerContract}
ID id-rosObject-respondingSupplierDSA}
Объект "ShadowSupplierContract" выражает форму услуги, в которой теневой поставщик объекта-УУО класса "initiating-supplierdsa" является инициатором контракта. Объект-ROS класса "responding-consumer-dsa" является ответчиком в этом контракте.
initiating-supplierMsa ROS-OBJECT-CLASS ::= {
INITIATES {ShadowSupplierContract}
ID id-rosObject-initiatingSupplierDSA}
responding-consumerMsa ROS-OBJECT-CLASS ::= {
RESPONDS {ShadowSupplierContract}
ID id-rosObject-respondingConsumerDSA}
Взаимодействия между двумя АСС для управления набором эксплуатационных связей определены как "dopContract".
dop-dsa ROS-OBJECT-CLASS ::= {
BOTH {dopContract}
ID id-rosObjectMopDSA}
АСС, который участвует в этом контракте, определен как объект-УУО класса "dop-dsa". Этот контракт определен в виде информационного объекта УУО (см. 6.6).
6.3. Контракт и пакеты ПДС
"DapContract" определен в виде информационного объекта класса "CONTRACT".
dapContract CONTRACT ::= {
CONNECTION dapConnectionPackage
INITIATOR CONSUMER OF {readPackage|searchPackage
|modify Package}
ID id-contract-dap}
Если АПС и АСС из различных открытых систем взаимодействуют между собой, то такой контракт ассоциации может быть реализован в виде протокола прикладного уровня ВОС, на который в таких спецификациях справочника ссылаются как на протокол доступа к справочнику (ПДС). Определение этого протокола в понятиях прикладного контекста ВОС представлено в 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}
Пакеты управления операциями "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
|chainedModifyPackage}
ID id-contractMsp}
Если две АСС из различных открытых систем взаимодействуют между собой, то такой контракт ассоциации реализуется как протокол прикладного уровня ВОС, на который в таких спецификациях ссылаются как на протокол системы справочника (ПСС). Определение этого протокола в терминах прикладного контекста ВОС представлено в 7.2 настоящего стандарта.
"DspContract" состоит из пакета управления соединением "dspConnecti-onPackage" и трех пакетов управления операциями "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.
chainedReadPackage OPERATION-PACKAGE ::= {
OPERATIONS {chainedRead|chainedCompare
|chainedAbandon}
ID id-package-chainedRead}
chainedSearchPackage OPERATION-PACKAGE ::= {
OPERATIONS {chainedList|chainedSearch}
ID id-package-chainedSearch}
chainedModifyPackage OPERATION-PACKAGE ::= {
OPERATIONS {chainedAdd Entry|chainedRemoveEntry
|chainedModifyEntry|chainedModifyDN}
ID id-package-chainedModify}
Примечание. Если эти пакеты реализованы в виде СЭП, они используются для создания прикладных контекстов, определенных в настоящем стандарте. Они не ставят своей задачей служить основой для заявки о соответствии отдельному СЭП или любой комбинации СЭП.
В "dapContract" АСС может принимать роль инициатора, и либо инициирующий, либо отвечающий АСС могут вызвать операции такого контракта.
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 ::= {
CONSUMER INVOKES {requestShadowUpdate}
SUPPLIER INVOKES {updateShadow}
ID id-package-shadowConsumer}
shadowSupplierPackage 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.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}
АСС, который может принимать роль инициатора объекта "dopContract", зависит от ролей, которые АСС может выполнять при административном управлении эксплуатационной(ыми) связью(ями), использующем операции этого контракта. Привлекать операции "dopContract" может только инициатор. С этим контрактом возможно несколько административно управляемых типов эксплуатационных связей, если только роли АСС для различных типов совместимы (например, АСС принимает роль А при любом типе связи).
6.7. Использование нижерасположенных услуг
Протоколы ПДС, ПСС, ПУЭС и ПТИС могут использовать нижерасположенные услуги, как описано ниже.
6.7.1. Использование услуг СЭУО
Сервисный элемент удаленных операций определен в ГОСТ Р ИСО/МЭК 9072-2.
СЭУО поддерживает парадигму запрос - ответ удаленных операций.
СЭП справочника являются пользователями услуг СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ.
Удаленные операции ПДС и ПСС выполняются в асинхронном режиме. Поскольку АПС является потребителем ПДС, то выбор операций может осуществляться синхронным способом.
Удаленные операции ПТИС должны обеспечиваться синхронными операциями и факультативно могут обеспечиваться асинхронными операциями.
Удаленные операции ПУЭС выполняются в асинхронном режиме.
6.7.2. Использование услуг СЭНП
Сервисный элемент надежной передачи (СЭНП) определен в ИСО/МЭК 9066-1.
СЭНП обеспечивает надежную передачу ПБДП. СЭНП гарантирует, что каждый ПБДП полностью передается только один раз, а об особых случаях отправитель предупреждается. При нарушениях обмена данными и отказе оконечной системы СЭНП восстанавливает и минимизирует количество повторных передач, необходимых для восстановления.
Для обеспечения ПТИС определены альтернативные прикладные контексты с СЭНП и без него.
СЭНП используется в нормальном режиме. Использование нормального режима СЭНП подразумевает использование нормального режима СЭУА и нормального режима услуг уровня представления.
Если СЭНП включен в прикладной контекст, услуга УО-СВЯЗКА преобразуется в услугу СЭНП НП-ОТКРЫТИЕ, а услуга УО-РАЗВЯЗКА - в услугу СЭНП НП-ЗАКРЫТИЕ. Базовые услуги СЭУО являются единственным пользователем услуг СЭНП НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ.
6.7.3. Использование услуг СЭУА
Сервисный элемент управления ассоциацией (СЭУА) определен в ГОСТ 34.981.
СЭУА обеспечивает управление (установление, освобождение, аварийное прекращение работы) прикладных ассоциаций между ЛОП.
Если СЭНП включен в прикладной контекст, то он является единственным пользователем услуг СЭУА П-АССОЦИАЦИЯ, П-РАЗЪЕДИНЕНИЕ, П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.
Если СЭНП не включен в прикладной контекст, услуги УО-СВЯЗКА и УО-РАЗВЯЗКА являются единственными пользователями услуг СЭУА П-АССОЦИАЦИЯ и П-РАЗЪЕДИНЕНИЕ. Прикладной процесс использует услуги СЭУА П-ПРЕРЫВАНИЕ и П-Пс-ПРЕРЫВАНИЕ.
Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВАНИЕ по ассоциации, поддерживающей ПДС, завершает всю обработку запроса. Кроме определенных условий, описанных в ИСО/МЭК 9594-4, это также справедливо для ПСС. Пользователь справочника является ответственным за подтверждение выполнения требуемых модификаций в ИБС.
Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВАНИЕ по ассоциации, поддерживающей ПТИС, описано в ИСО/МЭК 9594-9.
Получение П-ПРЕРЫВАНИЕ или П-Пс-ПРЕРЫВАНИЕ по ассоциации, поддерживающей ПУЭС, описано в ИСО/МЭК 9594-4.
6.7.4. Использование услуг уровня представления
Услуги уровня представления определены в ГОСТ 34.971.
Уровень представления координирует представление (синтаксис) семантики прикладного уровня, которая должна быть заменена.
В нормальном режиме для каждого абстрактного синтаксиса, включенного в прикладной контекст, используется различный контекст уровня представления.
СЭУА является единственным пользователем услуг Пр-СОЕДИНЕНИЕ, Пр-РАЗЪЕДИНЕНИЕ, Пр-Пл-ПРЕРЫВАНИЕ и Пр-Пс-ПРЕРЫВАНИЕ уровня представления.
Если СЭНП включен в прикладной контекст, то он является единственным пользователем следующих услуг уровня представления: Пр-НАЧАЛО-АКТИВНОСТИ, Пр-КОНЕЦ-АКТИВНОСТИ, Пр-ПРЕРЫВАНИЕ-АКТИВНОСТИ, Пр-АННУЛИРОВАНИЕ-АКТИВНОСТИ, Пр-ВОЗОБНОВЛЕНИЕ-АКТИВНОСТИ, Пр-ДАННЫЕ, Пр-МЛАДШАЯ-СИНХРОНИЗАЦИЯ, Пр-Пл-ОСОБОЕ-СООБЩЕНИЕ, Пр-Пс-ОСОБОЕ-СООБЩЕНИЕ, Пр-ЗАПРОС-ПОЛНОМОЧИЙ и Пр-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ.
Если СЭНП не включен в прикладной контекст, СЭУА является единственным пользователем услуги уровня представления Пр-ДАННЫЕ.
Контекст уровня представления, устанавливаемый по умолчанию, восстановление контекста и административное управление контекстом не используются.
6.7.5. Использование услуг нижерасположенного уровня
Услуги сеансового уровня определены в ГОСТ Р ИСО 8326.
Сеансовый уровень структурирует диалог потока информации между оконечными системами.
Если СЭНП включен в прикладной контекст, то уровень представления использует следующие функциональные блоки сеансового уровня: "ядро", "полудуплекс", "особые сообщения", "младшая синхронизация" и "управление активностью".
Если СЭНП не включен в прикладной контекст, уровнем представления используются функциональные блоки сеансового уровня: "ядро" и "полудуплекс".
Услуги транспортного уровня определены в ГОСТ Р ИСО/МЭК 8072. Транспортный уровень обеспечивает межконцевую прозрачную передачу данных по соединению нижерасположенного сетевого уровня.
Выбор класса услуг транспортного уровня, используемых сеансовым уровнем, зависит от требований, предъявляемых к мультиплексированию и восстановлению от ошибок. Обеспечение класса 0 протокола транспортного уровня (отсутствие мультиплексирования) обязательна. Услуга срочной передачи данных транспортного уровня не используется.
Обеспечение других классов протокола факультативно. Класс с мультиплексированием может быть использован при мультиплексировании ПДС или ПСС и других протоколов по одному и тому же соединению сетевого уровня. Класс с восстановлением при ошибках может быть выбран по соединению сетевого уровня с недопустимым коэффициентом необнаруженных ошибок.
Нижерасположенный сетевой уровень, поддерживающий услуги сетевого уровня ВОС, определен в ГОСТ Р ИСО/МЭК 8348.
Адресация на сетевом уровне определена также в ГОСТ Р ИСО/МЭК 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-PDUs
IDENTIFIED BY id-as-directoryAccessAS}
DAP-PDUs ::= CHOICE {
basicRos ROS {{DAP-InvokeIDSet}, {DAP-Invokable},
{DAP-Returnable}},
bind Bind {directoryBind},
unbind Unbind {directoryUnbind}}
DAP-InvokeIDSet ::= InvokeID (ALL EXCEPT absent: NULL)
DAP-Invokable OPERATION ::= {read|compare|abandon
|list|search
|addEntry|removeEntry
|modifyEntry|modifyDN}
DAP-Returnable OPERATION ::= {read|compare|abandon
|list|search
|addEntry|removeEntry
|modifyEntry|modifyDN}
7.1.2. Абстрактный синтаксис ПСС
СЭП справочника, реализующие указанные в 6.4 пакеты управления операциями, используют единственный абстрактный синтаксис "directorySystemabstractSyntax". Он определяется в виде информационного объекта класса ABSTRACT-SYNTAX.
directorySystemabstractSyntax ABSTRACT-SYNTAX ::= {
DSP-PDUs
IDENTIFIED BY id-as-directorySystemAS}
DSP-PDUs ::= CHOICE {
basicRos ROS {{DSP-InvokeIDSet}, {DSP-Invokable},
{DSP-Returnable}},
bind Bind {dSABind},
unbind Unbind {dSAUnbind}}
DSP-InvokeIDSet ::= InvokeID (ALL EXCEPT absent: NULL)
DSP-Invokable OPERATION ::= {chainedRead|chainedCompare
|chainedAbandon|chainedList
|chainedSearch|chainedAddEntry
|chainedRemoveEntry
|chainedModifyEntry
|chainedModifyDN}
DSP-Returnable OPERATION ::= {chainedRead|chainedCompare
|chainedAbandon|chainedList
|chainedSearch|chainedAddEntry
|chainedRemoveEntry
|chainedModifyEntry
|chainedModifyDN}
7.1.3. Абстрактный синтаксис ПТИС
СЭП справочника реализуют указанные в 6.5 пакеты управления операциями, которые определяются в абстрактном синтаксисе "directoryShadowAbstractSyntax" или "directoryReliableShadow-AbstractSyntax" в зависимости от использования СЭНП в прикладном контексте. Эти два абстрактных синтаксиса определяются в виде информационных объектов класса ABSTRACT-SYNTAX.
directoryShadowAbstractSyntax ABSTRACT-SYNTAX ::= {
DISP-PDUs
IDENTIFIED BY id-as-directoryShadowAS}
directoryReliableShadowAbstractSyntax ABSTRACT-SYNTAX ::= {
Reliable-DISP-PDUs
IDENTIFIED BY id-as-directoryReliableShadowAS}
Кроме того, в контекстах применения СЭНП используется следующий абстрактный синтаксис. Он включает абстрактный синтаксис самого СЭНП и абстрактный синтаксис Bind {dSAShadowBind}, а Unbind {dSAShadowUnbind}.
rtseAndShadowBindingAbstractSyntax ABSTRACT-SYNTAX ::= {
ReliableShadowBinding-PDUs
IDENTIFIED BY id-as-reliableShadowBindingAbstractSyntax}
Типы АСН.1, из которых получены значения абстрактных синтаксисов, определяются путем использования типов параметризации ROS {}, Bind {}, Unbind {}.
DISP-PDUs ::= CHOICE {
basicRos ROS {{DISP-InvokeIDSet}, {DISP-Invokable},
{DISP-Returnable}},
bind Bind {dSAShadowBind},
unbind Unbind {dSAShadowUnbind}}
Reliable-DISP-PDUs ::= ROS {{DISP-InvokeIDSet},
{DISP-Invokable},
{DISP-Returnable}},
ReliableShadowBinding-PDUs ::= CHOICE {
rTS RTSE-apdus,
bind Bind {dSAShadowBind},
unbind Unbind {dSAShadowUnbind}}
DISP-InvokeIDSet ::= InvokeID (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 ::=
{
DOP-PDUs
IDENTIFIED BY id-as-directoryOperationalBindingManagementAS}
DOP-PDUs ::= CHOICE {
basicRos ROS {{DOP-InvokeIDSet}, {DOP-Invokable},
{DOP-Returnable}},
bind Bind {directoryBind},
unbind Unbind {directoryUnbind}}
DOP-InvokeIDSet ::= InvokeID (ALL EXCEPT absent: NULL)
DOP-Invokable OPERATION ::= {establishOperationalBinding
|modifyOperationalBinding
|terminateOperationalBinding}
DOP-Returnable OPERATION ::= {establishOperationalBinding
|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
|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. Прикладной контекст теневого справочника
Если АСС поддерживает ПТИС, он должен поддерживать по крайней мере одну теневую роль: поставщика либо потребителя и, кроме того, один из объектов "shadowSupplierInitiatedAC" или "shadowConsumerInitiatedAC". Если АСС поддерживает "shadowSupplierInitiatedAC" для конкретной роли, то он может факультативно поддерживать для той же роли и "reliableShadowSupplierInitiatedAC". Если АСС поддерживает "shadowConsumerInitiatedAC" для конкретной роли, то он может факультативно поддерживать для той же роли и reliableShadowCon-sumerInitiatedAC".
7.2.3.1. Начальные контексты теневого поставщика
"ShadowSupplierContract" может быть реализован как "shadowSupplierInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
shadowSupplierInitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT ShadowSupplierContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-abstract-syntax
|directoryShadowSyntax}
APPLICATION CONTEXT NAME id-ac-shadowSupplierInitiatedAC}
Этот прикладной контекст требует применения только синхронных операций.
Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как "id-ac-shadowSupplierInitiatedAsynchronosAC".
"ShadowSupplierContract" может быть факультативно реализован как "reliableShadowSupplier-InitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
reliableShadowSupplierInitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT ShadowSupplierContract
ESTABLISHED BY association-by-RTSE
INFORMATION TRANSFER BY transfer-by-RTSE
ABSTRACT SYNTAXES {reliableShadowBindingAbstractSyntax
|rtse-abstract-syntax
|rtseAndShadowBindingAbstractSyntax}
APPLICATION CONTEXT NAME id-ac-reliableShadowSupplierInitiatedAC}
7.2.3.2. Начальные контексты теневого потребителя
Объект "shadowConsumerContract" может быть реализован как "shadowConsumerInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION-CONTEXT.
shadowConsumerInitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT shadowConsumerContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-syntax I directoryShadowSyntax}
APPLICATION CONTEXT NAME id-ac-shadowConsumerInitiatedAC}
Этот прикладной контекст требует применения только синхронных операций.
Вариант такого прикладного контекста, который разрешает использование асинхронных операций, идентифицирован как "id-ac-shadowConsumerInitiatedAsynchronosAC".
Объект "shadowConsumerContract" может быть факультативно реализован как "reliable-ShadowConsumerInitiatedAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.
reliableShadowConsumerInitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT shadowConsumerContract
ESTABLISHED BY association-by-RTSE
INFORMATION TRANSFER BY transfer-by-RTSE
ABSTRACT SYNTAXES {reliableShadowBindingAbstractSyntax
|rtse-abstract-syntax
|rtseAndShadowBindingAbstractSyntax}
APPLICATION CONTEXT NAME id-ac-reliableShadowConsumerInitiatedAC}
7.2.4. Прикладной контекст управления эксплуатационными связями справочника
"DopContract реализован как "directoryOperationalBindingManagementAC". Этот прикладной контекст определен в виде информационного объекта класса APPLICATION CONTEXT.
directoryOperationalBindingManagementAC APPLICATION-CONTEXT ::= {
CONTRACT dopContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-abctract-syntax|
directoryOperationalBindingManagementAbstractSyntax}
APPLICATION CONTEXT NAME id-ac-directoryOperationalBindingManagemen
tAC}
7.3. Коды операций
7.3.1. Коды операций для пакетов ПДС и ПСС
Следующие коды операций используются пакетами управления операциями ПДС и ПСС.
idmpcode-read
Code ::=
local: 1
id-opcode-compare
Code ::=
local: 2
id-opcode-abandon
Code ::=
local: 3
id-opcode-list
Code ::=
local: 4
id-opcode-search
Code ::=
local: 5
id-opcode-addEntry
Code ::=
local: 6
id-opcode-removeEntry
Code ::=
local: 7
id-opcode-modifyEntry
Code ::=
local: 8
id-opcode-modifyDN
Code ::=
local: 9
7.3.2. Коды операций для пакетов ПТИС
Следующие коды операций используются пакетами управления операциями ПТИС:
id-opcode-requestShadowUpdate
Code ::=
local: 1
id-opcode-updateShadow
Code ::=
local: 2
id-opcode-coordinateShadowUpdate
Code ::=
local: 3
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.
При обработке ответа АПС должен:
a) игнорировать все неизвестные присвоения имен битов в строке битов;
b) игнорировать все неизвестные поименованные номера в типе ENUMERATED или INTEGER, который используется в перечисленном стиле при условии, что номер представлен в виде факультативного элемента SET или SEQUENCE;
c) игнорировать все неизвестные элементы в SET, в конце SEQUENCE или в CHOICE, где CHOICE сам является факультативным элементом SET или SEQUENCE.
Примечание. Реализации могут в качестве локального решения игнорировать определенные дополнительные элементы в ПБД справочника. В частности, некоторые неизвестные поименованные номера и неизвестные CHOICE в обязательных элементах SET и SEQUENCE могут быть проигнорированы, не делая операцию недействительной. Идентификация таких элементов является предметом дальнейшего изучения;
d) не рассматривать получение неизвестных типов атрибутов и их значений как нарушение протокола;
e) факультативно сообщать пользователю неизвестные типы атрибутов и их значения.
7.5.1.3. Правила расширяемости при обработке ошибок
При обработке известного типа ошибки с неизвестными обозначенными проблемами и параметрами АПС должен:
a) не рассматривать получение неизвестных обозначенных проблем и параметров как нарушение протокола (то есть он не должен выдавать RO-Пл-REJECT или прерывать прикладную ассоциацию) и
b) факультативно сообщать пользователю дополнительную информацию об ошибке.
При обработке неизвестного типа ошибки АПС должен:
a) не рассматривать получение неизвестного типа ошибки как нарушение протокола (то есть он не должен выдавать RO-Пл-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;
c) игнорировать все неизвестные элементы в 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. Режим
Этот параметр должен устанавливаться инициатором ассоциации в примитиве П-АССОЦИАЦИЯ запрос и иметь значение "нормальный режим".
8.1.1.1.2. Имя прикладного контекста
Инициатор ассоциации должен предоставлять один из следующих прикладных контекстов:
a) для ПДС - directoryAccessAC;
b) для ПСС - directorySystemAC;
c) для ПУЭС - directoryOperationalBindingManagementAC;
d) для ПТИС - shadowSupplierInitiatedAC или shadowConsumerInitiatedAC.
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. Преобразование в услуги НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ
Ниже определяется преобразование услуг DSAShadowBind и DSAShadowUnbind в услуги СЭНП НП-ОТКРЫТИЕ и НП-ЗАКРЫТИЕ.
8.2.1.1. Преобразование DSAShadowBind в НП-ОТКРЫТИЕ
Услуга DSAShadowBind преобразуется в услугу СЭНП НП-ОТКРЫТИЕ. Использование параметров услуги НП-ОТКРЫТИЕ описывается ниже.
8.2.1.1.1. Режим
Этот параметр должен устанавливаться инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и иметь значение "нормальный режим".
8.2.1.1.2. Имя прикладного контекста
Инициатор ассоциации должен предлагать в примитиве НП-ОТКРЫТИЕ запрос либо прикладной контекст reliableShadowSupplierInitiatedAC, либо прикладной контекст reliable-ShadowConsumerInitiatedAC.
8.2.1.1.3. Данные пользователя
Преобразование операции связки в параметре "данные пользователя" примитива НП-ОТКРЫТИЕ запрос определено в ГОСТ Р ИСО/МЭК 9072-1.
8.2.1.1.4. Список определений контекста уровня представления
Инициатор ассоциации должен установить список определений контекста уровня представления в примитиве НП-ОТКРЫТИЕ запрос, который должен содержать абстрактный синтаксис СЭУА (id-as-acse) и абстрактный синтаксис ПТИС, включающий СЭНП (id-as-directoryReliableShadowAS).
8.2.1.1.5. Начальный цикл
Этот параметр должен быть установлен инициатором ассоциации в примитиве НП-ОТКРЫТИЕ запрос и должен быть равен значению "association-initiator".
8.2.1.1.6. Наименование ЛОП и адрес на уровне представления
Эти параметры должны устанавливаться инициатором и ответчиком ассоциации НП-ОТКРЫТИЕ (наименование ЛОП устанавливается факультативно).
8.2.1.2. Преобразование DSAShadowUnbind в НП-ЗАКРЫТИЕ
Услуга DSAShadowUnbind преобразуется в услугу СЭНП НП-ЗАКРЫТИЕ.
8.2.2. Преобразование в СЭУО
Услуги ShadowSupplierASE и shadowConsumerASE преобразуются в услуги СЭУО УО-ПРИВЛЕЧЕНИЕ, УО-РЕЗУЛЬТАТ, УО-ОШИБКА, УО-Пл-ОТКЛОНЕНИЕ и УО-Пс-ОТКЛОНЕНИЕ. Преобразование нотации абстрактного синтаксиса таких СЭП ПТИС в услуги СЭУО осуществляется в соответствии с ГОСТ Р ИСО/МЭК 9072-1.
СЭУО является пользователем услуг СЭНП НП-ПЕРЕДАЧА, НП-ЗАПРОС-ПОЛНОМОЧИЙ, НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ, НП-Пс-ПРЕРЫВАНИЕ и НП-Пл-ПРЕРЫВАНИЕ. Использование услуг СЭНП СЭУО определено в ГОСТ Р ИСО/МЭК 9072-2.
8.2.2.1. Управление полномочиями
ГОСТ Р ИСО/МЭК 9072-2 определяет использование сервисным элементом удаленных операций услуг СЭНП НП-ЗАПРОС-ПОЛНОМОЧИЙ и НП-ПРЕДОСТАВЛЕНИЕ-ПОЛНОМОЧИЙ для управления полномочиями.
Параметр "приоритет" услуги НП-ЗАПРОС-ПОЛНОМОЧИЙ, используемой сервисным элементом удаленных операций для запроса полномочий, имеет значение:
ноль - наивысший приоритет, зарезервированный для освобождения ассоциации инициатором;
единица - используется СЭУО для обеспечения своих услуг УО-Пл-ОТКЛОНЕНИЕ и УО-ОШИБКА;
два - используется СЭУО для обеспечения своей услуги УО-РЕЗУЛЬТАТ;
три - используется СЭУО для обеспечения своей услуги УО-ПРИВЛЕЧЕНИЕ.
9. СООТВЕТСТВИЕ
В этом разделе устанавливаются требования к соответствию настоящему стандарту.
9.1. Требования к соответствию, предъявляемые АПС
Реализация АПС, претендующая на соответствие настоящему стандарту, должна удовлетворять требованиям 9.1.1 - 9.1.3.
9.1.1. Требования к заявке
Должно быть указано следующее:
a) операции прикладного контекста directoryAccessAC, которые способен привлечь АПС и соответствие которым заявлено;
b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);
c) расширения, перечисленные в таблице 7.3.1 ИСО/МЭК 9594-3, которые АПС способен инициировать и соответствие которым заявлено.
9.1.2. Статические требования
АПС должен:
a) обладать способностью обеспечивать прикладной контекст directoryAccessAC, определенный его абстрактным синтаксисом в разделе 7;
b) выполнять расширения, соответствие которым заявлено в 9.1.1 c).
9.1.3. Динамические требования
АПС должен:
a) соответствовать преобразованию в используемые услуги, определенные в разделе 8;
b) соблюдать правила процедур расширения, определенные в 7.5.1.
9.2. Требования к соответствию, предъявляемые АСС
Реализация АСС, претендующая на соответствие настоящему стандарту, должна удовлетворять требованиям 9.2.1 - 9.2.3.
9.2.1. Требования к заявке
Должно быть указано следующее.
a) Прикладные контексты, соответствие которым заявлено: directoryAccessAC, directorySystemAC, directoryOperationalBindingManagementAC или их комбинации. АСС, претендующий на соответствие атрибуту directoryOperationalBindingManagementAC в обеспечение иерархических эксплуатационных связей, должен обеспечивать также directorySystemAC. Если сведения об АСС рассредоточены, что вызывает необходимость обращаться к АСС, расположенных в других АСС вне своего собственного административного региона справочника (АРС), должно быть заявлено соответствие атрибуту directorySystemAC.
Примечание. Прикладной контекст не должен разделяться, за исключением указанного здесь разделения; в частности, не должно заявляться соответствие конкретным операциям.
b) Эксплуатационные типы связей, соответствие которым заявлено - shadowOperationalBindingID, specificHierarchicalBindingID, non-specificHierarchicalBindingID или их комбинации. АСС, претендующий на соответствие атрибуту shadowOperationalBindingID, должен поддерживать один или несколько прикладных контекстов теневых поставщиков и/или теневых потребителей, указанных в 9.3 и 9.4.
c) Способность АСС функционировать в качестве АСС первого уровня, как определено в ИСО/МЭК 9594-4.
d) Обеспечение режима сцепления операций согласно ИСО/МЭК 9594-4, если заявлено соответствие прикладному контексту directorySystemAC.
e) Уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая).
f) Выбранные типы атрибута, определенные в ИСО/МЭК 9594-6, и любые другие типы атрибутов, соответствие которым заявлено, а также соответствие атрибутов, основанных на синтаксисе directoryString, выбору UNIVERSAL STRING.
g) Выбранные классы объектов, определенные в ГОСТ Р ИСО/МЭК 9594-7, и любые другие классы объектов, соответствие которым заявлено.
h) Расширения, перечисленные в таблице 7.3.1 ИСО/МЭК 9594-3, при которых АСС способен быть отвечающим, соответствие которому заявлено.
i) Соответствие общим атрибутам согласно 8.8 ИСО/МЭК 9594-2 и 7.6, 7.8.2, 9.2.2 ИСО/МЭК 9594-3.
j) Соответствие иерархическим атрибутам согласно 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3.
k) Типы эксплуатационных атрибутов, определенные в ИСО/МЭК 9594-2, и любые другие типы эксплуатационных атрибутов, соответствие которым заявлено.
l) Соответствие для передачи псевдонимов согласно 7.7.1 ИСО/МЭК 9594-3.
m) Соответствие выдаче указания о том, что передача информации записи завершена согласно 7.7.6 ИСО/МЭК 9594-3.
ИС NORMPROD: примечание.
В официальном тексте документа, видимо, допущена опечатка: пункт 11.3.2 в тексте документа отсутствует.
n) Соответствие модификации атрибута класса объекта с точки зрения добавлений и/или перемещений значений, идентифицирующих вспомогательные классы объектов согласно 11.3.2.
o) Соответствие базовому управлению доступом.
p) Соответствие упрощенному управлению доступом.
q) Способность АСС осуществлять административное управление подсхемой своей части ДИС согласно ИСО/МЭК 9594-2.
Примечание. Способности административного управления подсхемой не должны разделяться; в частности, не должна заявляться способность административного управления конкретными определениями подсхемами.
r) Выбранные поименованные связи, определенные в ГОСТ Р ИСО/МЭК 9594-7, и любые другие поименованные связи, соответствие которым заявлено.
s) Способность АСС к административному управлению общими атрибутами согласно ИСО/МЭК 9594-2.
9.2.2. Статические требования
АСС должен:
a) поддерживать прикладные контексты, соответствие которым заявлено, согласно определению их абстрактного синтаксиса в разделе 7;
b) поддерживать информационную структуру, определенную абстрактным синтаксисом ИСО/МЭК 9594-2;
c) соответствовать требованиям минимальных сведений, определенным в ИСО/МЭК 9594-4;
d) обеспечивать требования корневого контекста согласно ИСО/МЭК 9594-4, если заявлено соответствие АСС первого уровня;
e) обеспечивать типы атрибутов, соответствие которым заявлено, согласно их абстрактному синтаксису;
f) обеспечивать классы объектов, соответствие которым заявлено согласно их абстрактному синтаксису;
g) обеспечивать расширения, соответствие которым заявлено в 9.2.1h;
h) осуществлять административное управление подсхемой, если заявлено соответствие такой способности согласно ИСО/МЭК 9594-2;
i) выполнять соответствующие процедуры, определенные в 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3, если заявлено соответствие общим атрибутам;
j) выполнять соответствующие процедуры, определенные в 7.6, 7.8.2 и 9.2.2 ИСО/МЭК 9594-3, если заявлено соответствие иерархическим атрибутам;
k) поддерживать типы эксплуатационных атрибутов, соответствие которым заявлено;
l) сохранять элементы информации управления доступом, отвечающие определениям базового управления доступом, если заявлено соответствие базовому управлению доступом;
m) сохранять элементы информации управления доступом, отвечающие определениям упрощенного управления доступом, если заявлено соответствие упрощенному управлению доступом;
9.2.3. Динамические требования
АСС должен:
a) соответствовать преобразованию в используемые услуги, определенные в разделе 8 настоящего стандарта;
b) соответствовать процедурам распределенных операций справочника при обращении к нему согласно ИСО/МЭК 9594-4;
c) соответствовать процедурам ИСО/МЭК 9594-4, относящимся к режиму обращения ПДС, если заявлено соответствие прикладному контексту directoryAccessAC;
d) соответствовать режиму обращения при взаимодействии согласно ИСО/МЭК 9594-4, если заявлено соответствие прикладному контексту directorySystemAC;
e) соответствовать режиму сцепления при взаимодействии согласно ИСО/МЭК 9594-4, если заявлено соответствие режиму сцепления при взаимодействии.
Примечание. В этом случае необходимо только, чтобы АСС был способен привлекать операции directorySystemAC;
f) соблюдать правила процедур расширяемости, определенные в 7.5.2;
g) обладать возможностью защиты информации в пределах АСС в соответствии с процедурами базового управления доступом, если заявлено соответствие базовому управлению доступом;
h) обладать возможностью защиты информации в пределах АСС в соответствии с процедурами упрощенного управления доступом, если заявлено соответствие упрощенному управлению доступом;
i) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно ПЭУС, если заявлено соответствие атрибуту shadowOperationalBindingID;
j) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно конкретных иерархических эксплуатационных связей, если заявлено соответствие атрибуту specificHierarchicalBindingID;
k) соответствовать процедурам, определенным в ИСО/МЭК 9594-9 и ИСО/МЭК 9594-2 относительно неопределенных иерархических эксплуатационных связей, если заявлено соответствие атрибуту non-specificHierarchicalBindingID.
9.3. Требования соответствия, предъявляемые теневым поставщиком
Реализация АСС, претендующая на соответствие настоящему стандарту и выступающая в роли теневого поставщика, должна удовлетворять требованиям 9.3.1 - 9.3.3.
9.3.1. Требования к заявке
Должно быть указано следующее:
a) прикладн(ой)ые контекст(ы), соответствие которому(ым) заявлено как для теневого поставщика: shadowSupplierInitiatedAC, shadowConsumerInitiatedAC, reliableShadowSupplierInitiatedAC и reliableShadowConsumerInitiatedAC.
Реализация АСС должна как минимум обеспечивать либо shadowSupplierInitiatedAC, либо shadowConsumerInitiatedAC. Если АСС поддерживает shadowSupplierInitiatedAC, он может факультативно поддерживать reliableShadowSupplierInitiatedAC. Если АСС поддерживает shadowConsumerInitiatedAC, он может факультативно поддерживать reliableShadowConsumerInitiatedAC;
b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);
c) в какой степени обеспечивается UnitOfReplication, в частности, какая (при наличии) из следующих факультативных особенностей обеспечивается:
- фильтрование записи на ObjectClass;
- выбор/исключение атрибутов с помощью AttributeSelection;
- включение сведений подчиненного в область для копирования;
- включение расширенных сведений дополнительно к сведениям подчиненного.
9.3.2. Статические требования
АСС должен:
a) обеспечивать прикладной(ые) контекст(ы), соответствие которому(ым) заявлено согласно определениям в их абстрактном синтаксисе в разделе 7;
b) обеспечивать эксплуатационные атрибуты modifyTimestamp и createTimestamp.
9.3.3. Динамические требования
АСС должен:
a) соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта;
b) соответствовать процедурам, определенным ИСО/МЭК 9594-9 относительно ПТИС.
9.4. Требования к соответствию, предъявляемые теневым потребителем
Реализация АСС, претендующая на соответствие настоящему стандарту и являющаяся теневым потребителем, должна удовлетворять требованиям, перечисленным в 9.4.1 - 9.4.3.
9.4.1. Требования к заявке
Должно быть указано следующее:
a) прикладн(ой)ые контекст(ы), соответствие которому(ым) заявлено как для теневого поставщика: shadowSupplierInitiatedAC, shadowConsumerInitiatedAC, reliableShadowSupplierInitiatedAC и reliableShadowConsumerInitiatedAC.
Реализация АСС как минимум должна обеспечивать либо shadowSupplierInitiatedAC, либо shadowConsumerInitiatedAC. Если АСС обеспечивает shadowSupplierInitiatedAC, он может факультативно обеспечивать reliableShadowSupplierInitiatedAC. Если АСС обеспечивает shadowConsumerInitiatedAC, он может факультативно обеспечивать reliableShadowConsumerInitiatedAC;
b) уровень(и) защиты, соответствие которому(ым) заявлено (отсутствует, простая, строгая);
c) способность АСС действовать в качестве вторичного теневого поставщика (то есть участвовать во вторичном затенении в качестве промежуточного АСС);
d) способность АСС обеспечивать затенение перекрывающихся блоков, подлежащих копированию.
9.4.2. Статические требования
АСС должен:
a) обеспечивать прикладной(ые) контекст(ы), соответствие которому(ым) заявлено, как определено их абстрактным синтаксисом в разделе 7;
b) обеспечивать эксплуатационные атрибуты modifyTimestamp и createTimestamp, если обеспечиваются перекрывающиеся блоки, подлежащие копированию;
c) обеспечивать сервисное управление copyShallDo.
9.4.3. Динамические требования
АСС должен:
a) соответствовать преобразованиям в используемые услуги, определенные в разделе 8 настоящего стандарта;
b) соответствовать процедурам, определенным ИСО/МЭК 9594-9, относительно ПТИС.
Приложение A
(обязательное)
ПРОТОКОЛ ДОСТУПА К СПРАВОЧНИКУ В АСН.1
В данном Приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectoryAccessProtocol".
DirectoryAccessProtocol {joint-iso-ccitt ds{5} module{1} dap{11} 2}
DEFINITIONS ::=
BEGIN
- EXPORTS AII -
-- Определенные в этом модуле типы и значения экспортируются для
-- использования в других модулях АСН.1, содержащихся в спецификациях
-- справочника, и другими прикладными программами, которые будут,
-- в свою очередь, использовать их для доступа к услугам справочника.
-- Другие прикладные программы могут использовать их для своих
-- собственных целей, но это не препятствует расширениям
-- и модификациям, необходимым при обслуживании или усовершенствовании
-- услуг справочника.
IMPORTS
directoryAbstractService, protocolObjectIdentifiers
FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
usefulDefinitions(0) 2}
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE,
Code, OPERATION
FROM Remote-Operations-Information-Objects
{joint-iso-ccitt remote-operations(4) informationObjects(5)
version(0)}
ROS{}, Bind{}, Unbindg{}, InvokeID
FROM Remote-Operations-Generic-ROS-PDUs
{joint-iso-ccitt remote-operations(4) generic-ROS-PDUs(6)
version1(0)}
APPLICATION-CONTEXT
FROM Remote-Operations-Information-Objects-extension
{joint-iso-ccitt remote-operations(4) informationObjects-
extension(8) version1(0)}
acse, pData
FROM Remote-Operations-Realisations
{joint-isowcitt remote-operations(4) realisations(8)
version1(0)}
acse-abstract-syntax
FROM Remote-Operations-Abstract-Syntaxes
{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract-
Syntaxes(12) version1(0)}
id-acDirectoryAccessAC, id-rosObject4ua, id-rosObject-directory, id-
rosObject-dapDSA, ideontract4ap, id-package-dapConnection, id-package-read,
id-package-search, id-package-modify, id-as-directoryAccessAS
FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
directoryBind, directoryUnbind, read, compare, abandon, list, search,
addEntry, removeEntry, modifyEntry, modifyDN
FROM DirectoryAbstractService directoryAbstractService
-- Прикладной контекст --
directoryAccessAC APPLICATION-CONTEXT ::= {
CONTRACT dapContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-abstract-syntax I
directoryAccessAbstractSyntax}
APPLICATION-CONTEXT NAME id-ac-directoryAccessAC}
-- Объекты-УУО --
dua ROS-OBJECT-CLASS ::= {
INITIATES {dapContract}
ID id-rosObject-dua}
directory ROS-OBJECT-CLASS ::= {
RESPONDS {dapContract}
ID id-rosObject-directory}
dap-dsa ROS-OBJECT-CLASS ::= {
RESPONDS {dapContract}
ID id-rosObject-dapDSA}
-- Контракты --
dapContract CONTRACT ::= {
CONNECTION dapConnectionPackage
INITIATOR CONSUMER OF {readPackage|searchPackage
|modifyPackage}
ID id-contract-dap}
-- Пакет управления соединением --
dapConnectionPackage CONNECTION-PACKAGE ::= {
BIND directoryBind
UNBIND directoryUnbind
ID id-package-dapConnection}
-- Пакет чтения --
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|modifyD
N}
ID id-package-modify}
-- Абстрактный синтаксис --
directoryAccessAbstractSyntax ABSTRACT-SYNTAX ::= {
DAP-PDUs
IDENTIFIED BY id-as-MirectoryAccessAS
DAP-PDUs CHOICE ::= {
basicRos ROS {{DAP-InvokeIDSet} {DAP-Invokable},
{DAP-Returnable}},
bind Bind {directoryBind},
unbind Unbind {directoryUnbind}}
DAP-InvokeIDSet ::= {Invokeid (ALL EXCEPT absent: NULL)
DAP-Invokable OPERATION ::= {read|compare|abandon
|list|search
|addEntry|removeEntry
|modifyEntry|modifyDN}
DAP-Returnable OPERATION ::= {read|compare|abandon
|list|search
|addEntry|removeEntry
|modifyEntry|modifyDN}
-- Коды удаленных операций --
id-opcode-read Code ::= local: 1
id-opcode-compare Code ::= local: 2
id-opcode-abandon Code ::= local: 3
id-opcode-list Code ::= local: 4
id-opcode-search Code ::= local: 5
id-opcode-addEntry Code ::= local: 6
id-opcode-removeEntry Code ::= local: 7
id-opcode-modifyEntry Code ::= local: 8
id-opcode-modifyDN Code ::= local: 9
-- Коды ошибок удаленных операций --
id-errcode-attribute Error Code ::= local: 1
id-errcode-nameError Code ::= local: 2
id-errcode-serviceError Code ::= local: 3
id-errcode-referral Code ::= local: 4
id-errcode-abandoned Code ::= local: 5
id-errcode-security Error Code ::= local: 6
id-errcode-abandonFailed Code ::= local: 7
id-errcode-updateError Code ::= local: 8
-- Коды удаленных ошибок для ПСС --
id-errcode-dsaReferral Code ::= local: 9
END
Приложение B
(обязательное)
ПРОТОКОЛ СИСТЕМЫ СПРАВОЧНИКА В АСН.1
В данном Приложении приведены определения всех типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectorySystemProtocol".
DirectorySystemProtocol {joint-iso-ccitt ds{5} module{1} dsp{12} 2}
DEFINITIONS ::=
BEGIN
-- EXPORTS AII --
-- Определенные в этом модуле типы и значения экспортируются для
-- использования в других модулях АСН.1, содержащихся в спецификациях
-- справочника, и другими прикладными программами, которые будут,
-- в свою очередь, использовать их для доступа к услугам справочника.
-- Другие прикладные программы могут использовать их для своих
-- собственных целей, но это не препятствует расширениям
-- и модификациям, необходимым при обслуживании или усовершенствовании
-- услуг справочника.
IMPORTS
distributedOperations, protocolObjectIdentifiers
FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
usefulDefinitions(0) 2}
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE,
Code, OPERATION
FROM Remote-Operations-Information-Objects
{joint-iso-ccitt remote-operations(4) informationObjects(5)
version1(0)}
ROS{}, Bind{}, Unbind{}, InvokeID
FROM Remote-Operations-Generic-ROS-PDUs
{joint-iso-ccitt remote-operations(4) generic-ROS-PDUs(6)
version1(0)}
APPLICATION-CONTEXT
FROM Remote-Operations-Information-Objects-extension
{joint-iso-ccitt remote-operations(4) informationObjects-
extension(8) version1(0)}
acse, pData
FROM Remote-Operations-Realisations
{joint-iso-ccitt remote-operations(4) realisations(8)
version1(0)}
acse-abstract-syntax
FROM Remote-Operations-Abstract-Syntaxes
{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract-
Syntaxes(12) version1(0)}
id-ac-directorySystemAC, id-rosObject-dspDSA, id-contract-dsp, id-
package-dspConnection, id-package-chainedRead, id-package-chainedSearch,
id-package-chainedModify, id-as-directorySystemAS
FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
dSABind, dSAUnbind, chainedRead, chainedCompare, chainedAbandon,
chainedList, chainedSearch, chainedAddEntry, chainedRemoveEntry,
chainedModifyEntry, chainedModifyDN
FROM DistributedOperations distributedOperations
-- Прикладной контекст --
directorySystemAC APPLICATION-CONTEXT ::= {
CONTRACT dspContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-abstract-syntax
|directoryAccessAbstractSyntax}
APPLICATION-CONTEXT NAME id-ac-directorySystemAC}
-- Объекты-УУО --
dsp-dsa ROS-OBJECT-CLASS ::= {
BOTH {dspContract}
ID id-rosObject-dspDSA}
-- Контракты --
dspContract CONTRACT ::= {
CONNECTION dspConnectionPackage
OPERATIONS OF {chainedReadPackage
|chainedSearchPackage
|chainedModifyPackage}
ID id-contract-dsp}
-- Пакет управления соединением --
dspConnectionPackage CONNECTION-PACKAGE ::= {
BIND dSABind
UNBIND dSAUnbind
ID id-package-dspConnection}
-- Сцепленный пакет чтения --
chainedReadPackage OPERATION-PACKAGE ::= {
OPERATIONS {chainedRead|chainedCompare
|chainedAbandon}
ID id-package-chainedRead}
-- Сцепленный пакет поиска --
chainedSearchPackage OPERATION-PACKAGE ::= {
OPERATIONS {chainedList|chainedSearch}
ID id-package-chainedSearch}
-- Сцепленный пакет модификации --
chainedModify Package OPERATION-PACKAGE :: = {
OPERATIONS {chainedAddEntry|chainedRemoveEntry
|chainedModifyEntry|chainedModifyDN}
ID id-package-chainedModify}
-- Абстрактный синтаксис --
directorySystemAbstractSyntax ABSTRACT-SYNTAX ::= {
DSP-PDUs
IDENTIFIED BY id-as-directorySystemAS}
DSP-PDUs ::= CHOICE {
basicRos ROS {{DSP-InvokeIDSet}, {DSP-Invokable},
{DSP-Returnable}},
bind Bind {dSABind},
unbind Unbind {dSAUnbind}}
DSP-InvokeIDSet ::= {InvokeID (ALL EXCEPT absent: NULL)
DSP-Invokable OPERATION ::= {chainedRead|chainedCompare
|chainedAbandon|chainedList
|chained Search|chainedAddEntry
|chainedRemoveEntry
|chainedModifyEntry|
|chainedModifyDN}
DSP-Returnable OPERATION ::= {chainedRead|chainedCompare
|chainedAbandon
|chainedList|chainedSearch
|chainedAddEntry
|chainedRemoveEntry|
chainedModifyEntry
|chainedModifyDN}
END
Приложение C
(обязательное)
ПРОТОКОЛ ТЕНЕВОЙ ИНФОРМАЦИИ СПРАВОЧНИКА В АСН.1
В данном Приложении приведены определения всех соответствующих типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectoryInformationShadowProtocol".
DirectoryInformationShadowProtocol {joint-iso-ccitt ds(5) module(1)
disp(16) 2}
DEFINITIONS ::=
BEGIN
= EXPORTS AII =
-- Определенные в этом модуле типы и значения экспортируются для
-- использования в других модулях АСН.1, содержащихся в спецификациях
-- справочника, и другими прикладными программами, которые будут,
-- в свою очередь, использовать их для доступа к услугам справочника.
-- Другие прикладные программы могут использовать их для своих
-- собственных целей, но это не препятствует расширениям
-- и модификациям, необходимым при обслуживании или усовершенствовании
-- услуг справочника.
IMPORTS
directoryShadowAbstractService, protocolObjectIdentifiers
FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
usefulDefinitions(0) 2}
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE,
Code, OPERATION
FROM Remote-Operations-Information-Objects
{joint-iso-ccitt remote-operations(4) informationObjects(5) version
1(0)}
ROS{}, Bind{}, Unbind{}, InvokeID
FROM Remote-Operations-Generic-ROS-PDUs
{joint-iso-ccitt remote-operations(4) generic-ROS-PDUs(6) version
1(0)}
APPLICATION-CONTEXT
FROM Remote-Operations-Information-Objects-extension
{joint-iso-ccitt remote-operations(4) informationObjects-extension
(8) version1(0)}
acse, pData, association-by-RTSE, transfer-by-RTSE
FROM Remote-Operations-Realisations
{joint-iso-ccitt remote-operations(4) realisations(8) version1(0)}
acsee-abstract-syntax, rtse-abstract-syntax
FROM Remote-Operations-Abstract-Syntaxes
{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract
Syntaxes(12) version1(0)}
id-ac-shadowSupplierInitiatedAC, id-ac-shadowConsumerInitiatedAC, id-
ac-reliableShadowSupplierInitiatedAC, id-ac-reliableShadowConsumerInitiated
AC
id-rosObject-initiatingConsumerDSA, id-rosObject-responding-Supplier
DSA, id-rosObject-initiatingSupplierDSA, id-rosObject-respondingConsumer
DSA, id-contract-shadowConsumer, id-contract-shadowSupplier, id-package-
dispConnection
id-package-shadowConsumer, id-package-shadowSupplier, id-as-directory
ShadowAS, id-as-directoryReliableShadowAS, id-as-reliableShadowBinding
AbstractSyntax
FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
dSAShadowBind, dSAShadowUnbind, requestShadowUpdate, updateShadow,
coordinateShadowUpdate
FROM DirectoryShadowAbstractService directoryShadowAbstractService
RTSE-apdus
FROM Reliable-Transfer-APDUs {joint-iso-ccitt reliable-transfer(3)
apdus(0)} ;
-- Прикладной контекст --
shadowSupplierInitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT ShadowSupplierContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {rtse-abstract-syntax|
directoryShadowSyntax}
APPLICATION-CONTEXT NAME id-ac-shadowSupplierInitiatedAC}
shadowConsumerInitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT shadowConsumerContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-syntax|directoryShadowSyntax}
APPLICATION-CONTEXT NAME id-ac-shadowConsumerInitiatedAC}
reliableShadowSupplierInitiated ACAPPLICATION-CONTEXT ::= {
CONTRACT ShadowSupplierContract
ESTABLISHED BY association-by-RTSE
INFORMATION TRANSFER BY transfer-by-RTSE
ABSTRACT SYNTAXES {reliableShadowBindingAbstractSyntax
|rtse-abstract-syntax
|rtseAndShadowBindingAbstractSyntax}
APPLICATION-CONTEXT NAME id-ac-reliableShadowSupplierInitiated
AC}
reliableShadowConsumerlnitiatedAC APPLICATION-CONTEXT ::= {
CONTRACT shadowConsumerContract
ESTABLISHED BY association-by-RTSE
INFORMATION TRANSFER BY transfer-by-RTSE
ABSTRACT SYNTAXES {reliableShadowBindingAbstractSyntax
|rtse-abstract-syntax
|rtseAndShadowBindingAbstractSyntax
APPLICATION-CONTEXT NAME id-ac-reliableShadowConsumerInitiated
AC}
-- Объекты-УУО --
initiating-consumer-dsa ROS-OBJECT-CLASS ::= {
INITIATES {shadowConsumerContract}
ID id-rosObject-initiatingConsumerDSA}
responding-supplier-dsa ROS-OBJECT-CLASS ::= {
RESPONDS {shadowConsumerContract}
ID id-rosObject-respondingSupplierDSA}
initiating-supplier-dsa ROS-OBJECT-CLASS ::= {
INITIATES {ShadowSupplierContract}
ID id-rosObject-initiatingSupplierDSA}
responding-consumcr-dsa ROS-OBJECT-CLASS ::= {
RESPONDS {shadowSupplierContract}
ID id-rosObject-respondingConsumerDSA}
-- Контракты --
shadowConsumerContract CONTRACT ::= {
CONNECTION dispConnectionPackage
INITIATOR CONSUMER OF {shadowConsumerPackage}
ID id-contract-shadowConsumer}
shadowSupplierContract CONTRACT ::= {
CONNECTION dispConnectionPackage
RESPONDER CONSUMER OF {shadowSupplierPackage}
ID id-contract-shadowSupplier}
-- Пакет управления соединением --
dispConnectionPackage CONNECTION-PACKAGE ::= {
BIND dSAShadowBind
UNBIND dSAShadowUnbind
ID id-package-dispConnection}
-- Пакеты --
shadowConsumerPackage OPERATION-PACKAGE ::= {
CONSUMER INVOKES {requestShadowUpdate}
SUPPLIER INVOKES {updateShadow}
ID id-package-shadowConsumer}
shadowSupplierPackage OPERATION-PACKAGE ::= {
SUPPLIER INVOKES {coordinateShadowUpdate
|updateShadow}
ID id-package-shadowSupplier}
-- Абстрактный синтаксис --
directoryShadowAbstractSyntax ABSTRACT-SYNTAX ::= {
DISP-PDUs
IDENTIFIED BY id-as--directoryShadowAS}
directoryReliableShadowAbstractSyntax ABSTRACT-SYNTAX ::= {
Reliable-DISP-PDUs
IDENTIFIED BY id-as-directoryReliableShadowAS }
rtseAnd ShadowBindingAbstractSyntax ABSTRACT-SYNTAX ::= {
ReliableShadowBinding-PDUs
IDENTIFIED BY id-as-reliableShadowBindingAbstractSy
ntax}
DISP-PDUs ::= CHOICE {
basicRos ROS {{DISP-InvokeIDSet},
{DISP-Invokable},
{DISP-Returnable}},
bind Bind {dSAShadowBind},
unbind Unbind {dSAShadowUnbind}}
Reliable-DISP-PDUs ::= ROS {{DISP-InvokeIDSet},
{DISP-Invokable},
{DISP-Returnable}},
ReliableShadowBinding-PDUs :: = CHOICE {
rTS RTSE-apdus,
bind Bind {dSAShadowBind},
unbind Unbind {dSAShadowUnbind}}
DISP-InvokeIDSet Invokeid (ALL EXCEPT absent: NULL)
DISP-Invokable OPERATION ::= {requestShadowUpdate
|UpdateShadow
|coordinateShadowUpdate}
DISP-Returnable OPERATION ::= {requestShadowUpdate
|updateShadow
|coordinateShadowUpdate
-- Коды удаленных операций --
id-opcode-requestShadowUpdate Code ::= local: 1
id-opcode-updateShadow Code ::= local: 2
id-pcode-coordinateShadowUpdate Code ::= local: 3
-- Коды ошибок удаленных операций --
id-errcode-ShadowError Code ::= local: 1
Приложение D
(обязательное)
ПРОТОКОЛ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ ЭКСПЛУАТАЦИОННЫМИ
СВЯЗЯМИ СПРАВОЧНИКА В АСН.1
В данном Приложении приведены определения всех соответствующих типов и значений АСН.1, содержащихся в настоящем стандарте, в виде модуля АСН.1 "DirectoryOperationalBindingManagementProtocol".
DirectoryOperationalBindingManagementProtocol {joint-iso-ccitt ds(5)
module(1) dop(17) 2}
DEFINITIONS ::=
BEGIN
-- EXPORTS AII --
-- Определенные в этом модуле типы и значения экспортируются для
-- использования в других модулях АСН.1, содержащихся в спецификациях
-- справочника, и другими прикладными программами, которые будут,
-- в свою очередь, использовать их для доступа к услугам справочника.
-- Другие прикладные программы могут использовать их для своих
-- собственных целей, но это не препятствует расширениям
-- и модификациям, необходимым при обслуживании или усовершенствовании
-- услуг справочника.
IMPORTS
protocolObjectIdentifiers, directoryAbstractService, opBinding
Management
FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1) useful
Definitions(0) 2}
directoryBind, directoryUnBind
FROM DirectoryAbstractService directoryAbstractService
ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE,
Code,
FROM Remote-Operations-Information-Objects
{joint-iso-ccitt remote-operations(4) informationObjects(5) version
1(0)}
ROS{}, Bind{}, Unbind{}, InvokeID
FROM Remote-Operations-generic-ROS-PDUs
{joint-iso-ccitt remote-operations(4) generic-ROS-PDUs (6) version
1(0)}
APPLICATION-CONTEXT
FROM Remote-Operations-Information-Objects-extension
{joint-iso-ccitt remote-operations(4) informationObject-extension(8)
version1(0)}
acse, pData
FROM Remote-Operations-Realisations
{joint-iso-ccitt remote-operations(4) realisations(8) version1(0)}
acse-abstract-syntax
FROM Remote-Operations-Abstract-Syntaxes
{joint-iso-ccitt remote-operations(4) remoteOperationsAbstract
Syntaxes(12) version1(0)}
id-ac-directoryOperationalBindingManagementAC, id-rosObject-dopDSA,
id-contract-dop, id-package-dopConnection,
id-package-operationalBindingManagement,
id-as-directoryOperationalBindingManagementAS
FROM ProtocolObjectIdentifiers protocolObjectIdentifiers
establishOperationalBinding, modifyOperationalBinding, terminate
OperationalBinding, dSAOperationalBindingManagementBind, dSAOperational
BindingManagementUnbind
FROM OperationalBindingManagement opBindingManagement;
-- Прикладной контекст --
directoryOperationalBindingManagementAC APPLICATION-CONTEXT ::= {
CONTRACT dopContract
ESTABLISHED BY acse
INFORMATION TRANSFER BY pData
ABSTRACT SYNTAXES {acse-abstract-syntax|
directoryOperationalBindingManagement
AbstractSyntax}
APPLICATION-CONTEXT NAME id-ac-directoryOperationalBindingMana
gementAC}
-- Объекты УУО --
dop-dsa ROS-OBJECT-CLASS ::= {
BOTH {dopContract}
ID id-rosObject-dopDSA }
-- Контракты --
dopContract CONTRACT ::= {
CONNECTION dopConnectionPackage
INITIATOR CONSUMER OF {dopPackage}
ID id-contract-dop
-- Пакет управления соединением --
dopConnectionPackage CONNECTION-PACKAGE ::= {
BIND dSAOperationalBindingManagementBind
UNBIND dSAOperationalBindingManagementUnbind
ID id-package-dopConnection}
-- Пакеты --
dopPackage OPERATION-PACKAGE ::= {
CONSUMER INVOKES {establishOperationalBinding
|modifyOperationalBinding
|terminateOperationalBinding}
ID id-package-OperationalBindingManageme
nt
-- Абстрактный синтаксис --
directoryOperationalBindingManagementAbstractSyntax ABSTRACT-SYNTAX ::=
{
DOP-PDUs
IDENTIFIED BY id-as-directoryOperationalBindingMana
gementAS}
DOP-PDUs :: = CHOICE {
basicRos ROS {{DOP-InvokeIDSet}, {DOP-
Invokable}, {DOP-Returnable}},
bind Bind {directoryBind},
unbind Unbind {directoryUnbind}}
DOP-InvokeIDSet ::= InvokeID (ALL EXCEPT absent: NULL)
DOP-Invokable OPERATION ::= {establishOperationalBinding
|modifyOperationalBinding
|terminateOperationalBinding}
DOP-Returnable OPERATION ::= {establishOperationalBinding
|modifyOperationalBinding
|terminateOperationalBinding}
-- Коды удаленных операций --
id-op-establishOperationalBinding Code ::= local: 100
id-op-modifyOperationalBinding Code ::= local: 102
id-op-terminateOperationalBinding Code ::= local: 101
-- Коды ошибок удаленных операций --
id-err-operationalBindingError Code ::= local: 100
END
Приложение E
(обязательное)
ЭТАЛОННОЕ ОПРЕДЕЛЕНИЕ ИДЕНТИФИКАТОРОВ ОБЪЕКТОВ ПРОТОКОЛА
В данном Приложении приведены все идентификаторы объектов АСН.1, присвоенные в настоящем стандарте, в виде модуля АСН.1 "ProtocolObjectIdentifiers".
ProtocolObjectIdentifiers {joint-iso-ccitt ds(5) module(1) protocol
ObjectIdentifiers(4) 2}
DEFINITIONS ::=
BEGIN
-- EXPORTS AII --
-- Определенные в этом модуле типы и значения экспортируются для
-- использования в других модулях АСН.1, содержащихся в спецификациях
-- справочника, и другими прикладными программами, которые будут,
-- в свою очередь, использовать их для доступа к услугам справочника.
-- Другие прикладные программы могут использовать их для своих
-- собственных целей, но это не препятствует расширениям
-- и модификациям, необходимым при обслуживании или усовершенствовании
-- услуг справочника.
IMPORTS
id-rosObject, id-contract, id-package, id-ac, id-as
FROM Usefuldefinitions {joint-iso-ccitt ds(5) module(1) usefulDefini
tions(0) 2}
-- Объекты УУО --
id-rosObject-dua OBJECTIDENTIFIER ::= {id-rosObject 1}
id-rosObject-directory OBJECTIDENTIFIER ::= {id-rosObject 2}
id-rosObject-dapDSA OBJECTIDENTIFIER ::= {id-rosObject 3}
id-rosObject-dspDSA OBJECTIDENTIFIER ::= {id-rosObject 4}
id-rosObject-dopDSA OBJECTIDENTIFIER ::= {id-rosObject 7}
id-rosObject-initiatingConsumerDSA OBJECTIDENTIFIER ::= {id-rosObject 8}
id-rosObject-respondingSupplierDSA OBJECTIDENTIFIER ::= {id-rosObject 9}
id-rosObject-initiatingSupplierDSA OBJECTIDENTIFIER ::= {id-rosObject 10}
id-rosObject-respondingConsumerDSA OBJECTIDENTIFIER ::= {id-rosObject 11}
-- Контракты --
id-contract-dap OBJECTIDENTIFIER ::= {id-contract 1}
id-contract-dsp OBJECTIDENTIFIER ::= {id-contract 2}
id-contract-shadowConsumer OBJECTIDENTIFIER ::= {id-contract 3}
id-contract-shadowSupplier OBJECTIDENTIFIER ::= {id-contract 4}
id-contract-dop OBJECTIDENTIFIER ::= {id-contract 5}
-- Пакеты --
id-package-read OBJECTIDENTIFIER ::= {id-package 1}
id-package-search OBJECTIDENTIFIER ::= {id-package 2}
id-package-modify OBJECTIDENTIFIER ::= {id-package 3}
id-package-chainedRead OBJECTIDENTIFIER ::= {id-package 4}
id-package-chainedSearch OBJECTIDENTIFIER ::= {id-package 5}
id-package-chainedModify OBJECTIDENTIFIER ::= {id-package 6}
id-package-shadowConsumer OBJECTIDENTIFIER ::= {id-package 7}
id-package-shadowSupplier OBJECTIDENTIFIER ::= {id-package 8}
id-package-operationalBinding
Management OBJECTIDENTIFIER ::= {id-package 9}
id-package-dapConnection OBJECTIDENTIFIER ::= {id-package 10}
id-package-dspConnection OBJECTIDENTIFIER ::= {id-package 11}
id-package-dispConnection OBJECTIDENTIFIER ::= {id-package 12}
id-package-dopConnection OBJECTIDENTIFIER ::= {id-package 13}
-- Прикладной контекст --
id-ac-directoryAccessAC OBJECT IDENTIFIER ::= {id-ac 1}
id-ac-directorySystemAC OBJECT IDENTIFIER ::= {id-ac 2}
id-ac-directoryOperationalBinding
ManagementAC OBJECT IDENTIFIER ::= {id-ac 3}
id-ac-shadowConsumerInitiatedAC OBJECT IDENTIFIER ::= {id-ac 4}
id-ac-shadowSupplierInitiatedAC OBJECT IDENTIFIER ::= {id-ac 5}
id-ac-reliableShadowSupplier
InitiatedAC OBJECT IDENTIFIER ::= {id-ac 6}
id-ac-reliableShadowConsumer
InitiatedAC OBJECT IDENTIFIER ::= {id-ac 7}
id-ac-shadowSupplierInitiated
AsynchronousAC OBJECT IDENTIFIER ::= {id-ac 8}
id-ac-shadowConsumerInitiated
AsynchronousAC OBJECT IDENTIFIER ::= {id-ac 9}
- ASEs {obsolete} -
- id-ase-readASE OBJECT IDENTIFIER ::= {id-ase 1}
- id-ase-searchASE OBJECT IDENTIFIER ::= {id-ase 2}
- id-ase-modifyASE OBJECT IDENTIFIER ::= {id-ase 3}
- id-ase-chainedReadASE OBJECT IDENTIFIER ::= {id-ase 4}
- id-ase-chainedSearchASE OBJECT IDENTIFIER ::= {id-ase 5}
- id-ase-chainedModifyASE OBJECT IDENTIFIER ::= {id-ase 6}
- id-ase-operationalBinding
ManagementASE OBJECT IDENTIFIER ::= {id-ase 7}
- id-ase-shadowConsumerASE OBJECT IDENTIFIER ::= {id-ase 8}
- id-ase-shadowSupplierASE OBJECT IDENTIFIER ::= {id-ase 9}
-- Абстрактный синтаксис --
id-as-directoryAccessAS OBJECT IDENTIFIER ::= {id-as 1}
id-as-directorySystemAS OBJECT IDENTIFIER ::= {id-as 2}
id-as-directoryShadowAS OBJECT IDENTIFIER ::= {id-as 3}
id-as-directoryOperationalBinding
ManagementAS OBJECT IDENTIFIER ::= {id-as 4}
id-as-directoryReliableShadowAS OBJECT IDENTIFIER ::= {id-as 5}
id-as-reliableShadowBinding
AbstractSyntax OBJECT IDENTIFIER ::= {id-as 6}
END
Приложение F
(справочное)
ТИПЫ ЭКСПЛУАТАЦИОННЫХ СВЯЗЕЙ СПРАВОЧНИКА
В данном Приложении приведены в виде модуля АСН.1 "DirectoryOperationalBindingTypes" все присвоенные идентификаторы объектов АСН.1, предназначенные для определения типов эксплуатационных связей, реализуемых в настоящем стандарте.
DirectoryOperationalBinding Types
{joint-iso-ccitt ds(5) module(1) directoryOperationalBindingTypes
(25) 2}
DEFINITIONS ::=
BEGIN
-- EXPORTS AII --
-- Определенные в этом модуле типы и значения экспортируются для
-- использования в других модулях АСН.1, содержащихся в спецификациях
-- справочника, и другими прикладными программами, которые будут,
-- в свою очередь, использовать их для доступа к услугам справочника.
-- Другие прикладные программы могут использовать их для своих
-- собственных целей, но это не препятствует расширениям
-- и модификациям, необходимым при обслуживании или усовершенствовании
-- услуг справочника.
IMPORTS
id-ob
FROM Usefuldefinitions {joint-iso-ccitt ds(5) module(1) useful
Definitions(0) 2};
id-op-binding-shadow OBJECT IDENTIFIER ::= {id-ob 1}
id-op-binding-hierarchical OBJECT IDENTIFIER ::= {id-ob 2}
id-op-binding-non-specific-hierarchical OBJECT IDENTIFIER ::= {id-ob 3}
END


Вернуться в "Каталог нормативных документов"



 

Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/47/gost_60104.html

 

На эту страницу сайта можно сделать ссылку:

 

 

На правах рекламы:

© Антон Серго, 1998-2026.
Правовая информация, 18+

Разработка сайта
ArtStyle Group