Страница 4: ГОСТ 34.972-91. Информационная технология. Взаимосвязь открытых систем. Спецификация протокола уровня представления с установлением соединения (69163)

.6.2.5. Процедура

МОК, определяемое при установлении соединения на уровне представления, согласовывается между равноправными ПАП и УП-пользователями.

Инициирующий ПАП предоставляет для каждого абстрактного синтаксиса, запрашиваемого локальным УП-пользователем, список синтаксисов передачи, которые могут быть использованы в данном соединении на уровне представления. Отвечающий ПАП указыва­ет в сервисном примитиве индикации P-CONNECT, выдаваемый своему УП-пользователю, те абстрактные синтаксисы, которые он не может поддержать с помощью предлагаемых синтаксисов пере­дачи, отмечая их как отвергаемые («отвержение поставщиком»). Отвечающий УП-пользователь указывает в сервисном примитиве ответа P-CONNECT те абстрактные синтаксисы, которые он прини­мает или отвергает. Отвечающий ПАП выбирает для каждого при­нятого контекста представления по одному синтаксису передачи из предложенного списка синтаксисов передачи, которые будут использоваться в данном соединении на уровне представления.

Контекст представления определяется идентификатором контек­ста представления, устанавливаемым инициирующим ПАП.

Если сервисный примитив запроса P-CONNECT не содержит параметра имени контекста по умолчанию, то интерпретацию зна­чений представляемых данных из контекста по умолчанию выпол­няют по правилам, устанавливаемым вне настоящего стандарта.

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

Если отвечающий ПАП поддерживает указанный контекст по умолчанию, но принимает сервисный примитив ответа P-CONNECT, в котором параметр результата контекста по умолчанию имеет значение «отвержение пользователем», он должен передать ПБДП CPR с указанием.в параметре результата контекста по умолчанию значения «отвержение пользователем».

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

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

Если инициирующий ПАП принимает сервисный примитив зап­роса P-U-ABORT после передачи ПБДП СР, но перед выдачей сервисного примитива подтверждения P-CONNECT, он должен передать ПБДП ARU, и соединение на уровне представления при этом не устанавливают.

Если инициирующий ПАП принимает сервисный примитив ин­дикации S-P-ABORT или ПБДП ARP, он должен выдавать сервис­ный примитив индикации Р-Р-ABORT, и соединение на уровне представления при этом не устанавливают.

Если инициирующий ПАП принимает ПБДП ARU, он должен выдать сервисный примитив индикации P-U-ABORT, и соединение на уровне представления при этом не устанавливают.

Отвечающий ПАП после выдачи сервисного примитива инди­кации P-CONNECT должен реагировать на ПБДП ARU, ПБДП ARP и S-P-ABORT таким же образом, как описано выше.

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

Процедура аварийного разрыва соединения на уровне представ­ления может использоваться в любой момент времени для форси­рованного разрыва соединения на уровне представления. Она за­пускается при выполнении услуги P-U-ABORT в ответ на прото­кольную ошибку или при приеме недействительных ПБДП.

При выполнении этой процедуры используют:

1. ПБДП ARU;

2. ПБДП ARP.

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

Этот параметр содержит список, каждый пункт которого состо­ит из двух компонентов: идентификатора контекста представления и относящего к нему имени синтаксиса передачи (или имени специ­фикации, производящей такой синтаксис передачи).

Примечание. Если МОК пустое, этот параметр также должен быть пустым.

Представляют параметр пользовательских данных из сервисно­го примитива запроса P-U-ABORT и должны представляться пара­метром пользовательских данных из сервисного примитива инди­кации P-U-ABORT. Он должен выбираться из контекстов представ­ления, как установлено в п. 6.1.2.

При м е ч а н и е. Параметр пользовательских данных не включают в переда­ваемый ПБДП ARU, если ограничение на длину, действующее со стороны ниже- расположенных СУ, препятствует включению значения представляемых данных параметра пользовательских данных в параметр данных УС-пользователя сеан­сового сервисного примитива запроса S-U-ABORT. Способ, с помощью которого, ПАП извещается об этом, имеет локальный характер.

Указывают одну из следующих причин:

1. причина не указана;

2. нераспознаваемый ПБДП;

3. неожидаемый ПБДП;

4. неожидаемый сеансовый сервисный примитив;

5. нераспознаваемый параметр ПБДП;

6. неожидаемый параметр ПБДП;

7. недействительное значение параметра ПБДП.

В перечислениях в—ж должен также присутствовать параметр идентификатора события.

Должен определять ПБДП или сеансовый сервисный примитив., который привел к процедуре прекращения.

Ниже описаны условия, приводящие к выполнению процедуры прекращения.

Коцца ПАП принимает сервисный примитив запроса P-U- ABORT и выполнено одно из следующих условий:

1. соединение на уровне представления было установлено;

2. был передан ПБДП СР, но не были приняты ни ПБДП СРА, ни ПБДП CPR,

он передает ПБДП ARU, и соединение на уровне представления после этого разрывается.

Когда ПАП принимает нераспознаваемый или неожидаемый ПБДП, или неожидаемый сеансовый сервисный примитив, он дол­жен выдать сервисный примитив индикации Р-Р-ABORT и, если это возможно, передать ПБДП ARP. Соединение на уровне пред­ставления после этого разрывается.

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

Когда ПАП принимает сервисный примитив индикации S-P- ABORT, он должен выдать сервисный примитив индикации Р-Р- ABORT, после чего соединение на уровне представления разрыва­ется.

Когда ПАП принимает ПБДП ARU, он должен выдать сервис­ный примитив индикации P-U-ABORT, после чего соединение на уровне представления разрывается.

Когда ПАП принимает ПБДП ARP, он должен выдать сервис­ный примитив индикации Р-Р-ABORT, после чего соединение на уровне представления разрывается.

Примечание. Когда процедура аварийного разрыва запускается в про­цессе установления соединения на уровне представления, последнее не устанав­ливается.

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

Процедуру изменения контекста используют для модификации МОК. В процессе ее выполнения согласовывается определение од­ного или нескольких новых контекстов представления, добавляе­мых в МОК, а также удаление контекстов представления, которые содержались в МОК. Запрашивающий логический объект исполь­зует эту процедуру, когда принимает сервисный примитив запро­са P-ALTER CONTEXT.