Материал: Лекция 1 (Определения и терминология, форматы сообщений)

ТСАР, особенности протокола, механизм, определяющий взаимодействие на 6, 5, 4-м уровнях модели OSI и всех видов обмена ПОВ

Общая схема организации взаимодействия логических блоков подсистемы транзакционных возможностей ОКС 7 представлен на нижеследующей диаграмме «Подсистема транзакционных возможностей ОКС 7 и ее взаимодействие с верхними и нижними уровнями модели взаимодействия открытых систем (ВОС)».

Подсистема транзакционных возможностей ОКС 7 и ее взаимодействие с верхними и нижними уровнями модели взаимодействия открытых систем (ВОС)

Адресация обеспечивается SCCP

Примитивы управления SCCP используются для передачи информации пользователей SCCP о доступности (недоступности SCCP-местный или удаленный), которые прозрачно передаются к ТС пользователей.

Компонентный подуровень

Компонента является средством проведения подсистемой транзакций ОКС 7 (ТС-Transaction Capability) запроса на выполнение операции или отклик.

Операция – действие, которое должно выполняться на удаленном окончании, идентифицируемое примитивом INVOKE-Id. Это позволяет произвести несколько вызовов аналогичной или различных операций. На операцию может передаваться только один отклик (указание об успехе или ошибке).

Диалог (структурированный и неструктурированный)

Услуги управления диалогом

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

1. Компоненты аналогичного потока соотносятся;

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

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

Если для завершения распределенного прикладного процесса требуется одиночное сообщение, то может быть использовано однонаправленное сообщение неструктурированного диалога. Инициатор операции TCAP не ожидает сообщения о результате операции (такая операция является операцией класса 4), но может принять сообщение об ошибке протокола, если она случается.

Неструктурированный диалог – ассоциация между компонентами. Неструктурированный диалог обеспечивается в протоколе посредством однонаправленного сообщения (unidirectional). В случае, если происходит ошибка, то возвращается также однонаправленное сообщение.

Структурированный диалог

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

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

1. Начало диалога;

2. Подтверждение диалога;

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

4. Диалог завершается: на передающей стороне более не передается компонент;

Параметр идентификатора диалога используется, как в примитивах управления операциями (компонентами), так и в примитивах управления передачей (диалогом) и необходимы для определения, какие компоненты относятся к какому диалогу. Параметр идентификатора диалога отражается (по соглашению) первым параметром в этих примитивах, начиная с буквы «D». Каждый пользователь TC имеет для данного диалога собственную ссылку. Местные ссылочные номера (используемые на интерфейсе с SCCP) представлены в данных рекомендациях. Сопоставление этих местных ссылочных номеров с ссылочными номерами протокола осуществляется подсистемой транзакционных возможностей ОКС 7.

Для управления диалогом при нормальных обстоятельствах были определены три примитива – они указывают на начало диалога (TC-BEGIN), продолжение (TC-CONTINUE) и завершение (TC-END). Каждый из этих примитивов может быть использован для запроса передачи 0, 1, или нескольких компонент, которые могут содержать информацию, относящуюся к одной или нескольким операциям.

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

Пример инициирования диалога, его последующего продолжения и завершения по инициативе пользователя B

Если «отклик» на вызов операции является вызовом другой операции с приемной стороны, первоначальный идентификатор вызова («Invoke Id») возвращается как идентификатор связанной операции («Linked Id»), указывая, что этот вызов операции с приемной стороны «связан» с первоначальной операцией. Пример организации связанной операции приведен на нижеследующей диаграмме.

Пример вызова связанной операции

Связанные операции.

Услуга структурированного диалога позволяет ТС пользователю начать диалог, произвести в рамках его обмен компонентами, закончить или прервать диалог.

Это обеспечивается посредством идентификатора транзакций среди соответствующих транзакционных сообщений.

Начало диалога

ТС пользователь начинает новый диалог посредством ввода примитива запроса «TC-Begin». Назначение этого примитива является следующим:

- указать компонентному подуровню на начало диалога, идентифицированного параметром идентификатора диалога, присутствующим в этом примитиве;

- запросить передачу какой-либо компоненты (компонент), переданных к подуровню компонент посредством примитивов управления компонентами типа “запрос” и имеющие аналогичный идентификатор диалога.

Примитив запроса «TC-Begin» может быть введен перед передачей каких-либо компонент к подуровню компонент. На приемной стороне ТС пользователь пункта назначения информируется о том, что новый диалог инициирован посредством примитива индикации «TC-Begin». На присутствие компонент указывается в поле “компоненты присутствуют”.

Продолжение диалога

Пользователь ТС указывает на продолжение диалога посредством ввода примитива запроса «ТC-Continue». Эти запросы, инициируемые соответствующим примитивом, необходимы для передачи какой-либо компоненты (компонент), переданных к компонентному подуровню для этого диалога, с момента приема сообщения «TC-Begin» или передачи примитива запроса «ТC-Continue».

На приемной стороне указанный примитив «ТC-Continue ind.» информирует пользователя о следующем:

- что диалог может быть продолжен;

- что компоненты доставлены (если параметр “компоненты присутствуют” не указывают “пусто”)

Завершение диалога

Для ТС пользователя обеспечивается три сценария, позволяющие ему завершить диалог:

- специально организованное завершение диалога;

- основное завершение диалога;

- прерывание диалога ТС пользователем.

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

а) Предварительно организованное завершение диалога.

В этом сценарии ТС пользователь, по предварительному соглашению решил, когда завершить диалог: влияние примитива TC-END является исключительно локальным. К ТС пользователю на приемной стороне пункта назначения никакая индикация TC-END не предусматривается.

Никаких компонент не может быть передано или принято для диалога, как только пользователем был передан примитив управления диалогом TC-END. Пример предварительно организованного завершения диалога представлен на нижеследующей диаграмме.

Пример предварительно организованного завершения диалога

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

Предварительно организованное завершение диалога обеспечивает отсутствие сообщений от других пунктов назначения, условно информирующих пользователя: «Я не имею этой информации». Только пользователь, владеющий соответствующей информацией, может продолжить диалог, в то время как все остальные SP назначения будут завершать диалог локально. Инициатор запросов будет также завершать диалог с неподтвержденными пунктами назначения местно. В приведенном выше примере рассматривается ситуация, где имеются два пункта назначения – B1 и B2 и инициированы два диалога (D1, D2) и (D3, D4). B1 владеет запрашиваемой информацией и решает продолжить диалог (передается транзакция управления диалогом «TC-Continue req. (D2)».

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

в) основной сценарий

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

Базовый сценарий использует примитивы TC-END со следующей целью:

- доставка какой-либо компоненты (компонент), которые были переданы к подуровню транзакций и для которых передача была задержана (на подуровне транзакций допускается образование очереди)

- индикация к ТС пользователю, что обмен компонентами в любом направлении будет для инициированного диалога прекращен.

Пример основного завершения диалога

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

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

с) прекращение диалога ТС пользователем

ТС пользователь имеет возможность запросить немедленное прекращение диалога, не принимая во внимание какие-либо задержанные вызовы операций. При этом, пользователь ТС может обеспечить “сквозную” (End-to-End) передачу информации, указывающую на причину прерывания диалога, а так же определенную диагностическую информацию. Эта информация ТСАР не анализируется.

Запрос TC-U-Abort и соответствующая индикация примитива предназначены для выполнения соответствующих функций.

Управление компонентами.

Определение параметров.

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

“класс”, “идентификатор диалога” – соотносит компоненты с определенным диалогом;

“идентификатор вызова” – идентифицирует вызов операции;

“идентификатор связанной операции” – связывает текущий вызов операции;

“ошибка” – содержит информацию, обеспечиваемую пользователем ТС, при ошибке возврата операции. Эта информация ТСАР не анализируется.

“последний компонент” – используется только в примитивах типа “индикация”, для обозначения последней компоненты сообщения. Заметим, что индикация последней части результата операции реализуется посредством названия примитива.

“операция” – идентифицирует действие, выполняемое пользователем ТС по запросу другого пользователя ТС.

“параметры”- содержат какие-либо параметры, сопровождающие операцию или предусмотренные в отклике на операцию.

“код проблемы” – идентифицирует причину неприема компоненты.

“таймаут” – указывает на максимальное время действия (существование) идентификатора компоненты. Данный параметр используется для обработки ситуаций неприема ожидаемого результата выполнения операций.

“вызов операции” – запрашивается компонентным подуровнем посредством примитива запроса TC-Invoke. Если этот вызов связан с предыдущей операцией, то используется параметр идентификатора связанной операции. Соответствующий примитив индикации TC-Invoke используется для индикации активации операции к пользователям ТС пункта назначения.

Доклад об успехе операции

Доклад об успешном выполнении операции (класс 1 или 3) является подтверждением выполнения операций удаленным ТС пользователем.

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

• ТС-Result-L указывает на последний сегмент результата (//* может присутствовать только один сегмент)

• ТС-Result-NL – указывает на сегмент результата (имеются еще сегменты)

На количество сегментов ограничений не имеется.

Примитив типа “запрос” используется для передачи результата от ТС пользователя к компонентному подуровню. Примитив типа “индикация” используется для доставки результата к ТС пользователю.

Доклад об ошибке

ТС пользователь, принимающий операцию (класс 1 или 2), которую он не может выполнить, “понимает” это и вводит примитив запроса ТС-U-Error, указывающий на причину ошибки (параметр ошибки). Соответствующая операция идентифицируется параметром идентификатора вызова. ТС пользователь, вызвавший операцию, информируется указательным примитивом TC-U-Error.

Неприем сообщения пользователем ТС

ТС пользователь может не принять какую-либо компоненту (за исключением самой компоненты reject), генерируемую подсистемой взаимодействия, которая предполагается некорректной. Причина неприема указывается в параметре кода проблемы, раздельные параметры доступны для неприема индивидуальных типов компонент.

Любой неприем вызова или результата завершает операцию. Если связанная операция не принята, то на операцию, с которой она связана, влияния не оказывается.

ТС пользователь не принимает компоненту посредством примитива запроса TC-U-Reject. Удаленный пользователь информируется о неприеме компоненты, посредством примитива указательного типа TC-U-Reject.

Отмена операции

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

Соответствующими компонентами являются указательные компоненты.

TC-L-Cancel – таймер, установленный подуровнем компонент, истекает и соответствующий примитив выдается к ТС пользователю от уровня компонент.

TC-U-Cancel – решение о прекращении диалога исходит от ТС пользователя к подуровню компонент.

Никаких компонент не передается

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

Последовательность компонент получается посредством передачи одной или нескольких компонент с данным идентификатором диалога к компонентному подуровню, что реализуется между двумя успешными запросами на передачу. (TC-Begin, TC-Continue или примитива запроса TC-End). Последовательность компонент также образуется (на исх. стороне) перед первым примитивом управления диалогом TC-Begin, использующим аналогичный идентификатор диалога (//* имеется в виду аналогичный идентификатору примитива управления компонентами *//), или только при запросе на передачу (TC-UNI)

На исходящей стороне список компонент ограничен примитивами запроса TC-UNI, TC-Begin, TC-Continue или TC-End.

На стороне пункта назначения последовательность компонент начинается с примитива, указывающего на передачу; на завершение передачи указывается посредством параметра “последняя компонента” примитивов, которые доставляют компоненты к ТС пользователю. Параметр “компоненты присутствуют” в примитиве передачи указывают на то, является последовательность сообщений пустой или нет.

Прерывание диалога