Часть XII

12.6. Итоговый пример функционирования модели OSI RM

    В качестве примера функционирования модели OSI RM рассмотрим процесс реализации сервиса прикладного уровня, связанного с установлением прикладной ассоциации. При этом будем предполагать, что сетевое соединение уже установлено и что при установлении транспортного соединения ему будет назначаться уже установленное сетевое соединение.

    Данный процесс представлен в виде последовательности событий, происходящих в архитектуре OSI RM и пронумерованных в порядке их проявления. Этот процесс иллюстрируется на Рис. 12.3-12.5. Прокомментируем этот процесс в порядке наступления событий:

    1: Некоторая компонента некоторого ASO, например, элемент ASE такой, как FTAM, формирует запрос сервисному элементу ACSE, входящему в тот же ASO, на установление прикладной ассоциации с удаленным ASO. Т.е. формируется сервисный примитив A-ASSOCIATE request. Заметим, что сервис A-ASSOCIATE имеет сложную семантику. При его исполнении задействуется ряд важных механизмов, для реализации которых в примитивах данного сервиса используется обширный набор параметров. Не углубляясь в семантику самих параметров, приведем их состав, анализ которого позволяет убедиться в сложности процедуры установления прикладной ассоциации:

    Mode (normal or X.410-1984)

    ASO-Content-Name

    ASO-Content-Name List

    Calling AP Title

    Calling ASO-Name

    Calling AP Invocation-identifier

    Calling ASO Invocation Tag

    Called AP Title

    Called ASO-Name

    Called AP Invocation-identifier

    Called ASO Invocation Tag

    Responding AP Title

    Responding ASO-Name

    Responding AP Invocation-identifier

    Responding ASO Invocation Tag

    ACSE Requirements

    Authentication-mechanism Name

    Authentication-value

    User Data

    Result

    Result Source

    Diagnostic

    Calling Presentation Address

    Called Presentation Address

    Responding Presentation Address

    Presentation Context Definition List

    Presentation Context Definition Result List

    Default Presentation Context Name

    Default Presentation Context Result

    Quality of Service

    Session Requirements

    Presentation Requirements

    Initial Synchronization Point Serial Number

    Initial Assignment of Tokens

    Session Connection Identifier

    User Summary

    2: Данный сервисный элемент ACSE формирует соответствующий сервисному примитиву A-ASSOCIATE request протокольный блок данных (AARQ APDU) и передает его в качестве параметра (как сервисный блок данных) в примитиве запроса соединения представительного уровня P- CONNECT request в некоторую точку PSAP.

    3: Сущность представительного уровня, приняв примитив P- CONNECT request и вместе с ним сервисный блок данных SPDU с данными пользователя, построит протокольный блок данных CP PPDU, соответствующий семантике процедуры установления представительного соединения. Так как такого соединения еще не установлено, то блок данных CP PPDU в виде соответствующего сервисного блока в качестве параметра передается сеансовому уровню посредством примитивы S- CONNECT request, запрашивающей установление сеансового соединения. Как мы видим, в этом примере передача данных пользователя может осуществляться и при выполнении фазы установления соединения.

    4: Сущность сеансового уровня, получив запрос на установление сеансового соединения и выделив из него данные пользователя, содержащие CP PPDU и AARQ APDU, выполнит следующие действия:

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

    - инициирует установление необходимого для этого транспортного соединения с помощью примитивы Т- CONNECT request.

    5: Транспортная сущность формирует протокольный блок данных CR TPDU, назначает устанавливаемому транспортному соединению существующее уже (по условию задачи) сетевое соединение и передает этот TPDU (опять же через механизм параметров и соответствующий NSDU) посредством примитива N-DATA request принимающей транспортной сущности по выбранному сетевому соединению.

    6: Поставщик сетевого сервиса выдает принимающей транспортной сущности примитив N-DATA indication, в параметрах которого доставляется сервисный блок NSDU, содержащий TPDU.

    7: Принимающая транспортная сущность интерпретирует полученный блок TPDU, и, найдя возможным (например, по ресурсам и/или требованиям к качеству обслуживания) установить предлагаемое транспортное соединение (отображаемое на конкретное сетевое соединение), выдает своему пользователю транспортного уровня примитив Т- CONNECT indication.

    8: Положим, что сущность сеансового уровня, получившая индикацию, обладает необходимыми ресурсами для управления установленным транспортным соединением. В этом случае принимающей стороной выдается нижележащей транспортной сущности примитив Т- CONNECT response.

    9: Транспортная сущность оформляет подтверждение о том, что она принимает подтверждение об установлении транспортного соединения. Она формирует протокольный блок данных CC (Connection Confirm) TPDU и передает его через механизм параметров с помощью примитивы N-DATA request.

    10: Поставщик сетевого сервиса выдает инициирующей транспортной сущности примитив N-DATA indication, в параметрах которого доставляется сервисный блок NSDU, содержащий CC TPDU. Этот блок интерпретируется и, если транспортная сущность принимает условия установления транспортного соединения, она подтверждает это примитивом Т-CONNECT confirm, в противном случае она могла бы послать своему партнеру протокольный блок данных DR (Disconnect Request) TPDU и выдать примитив T-DISCONNECT indication своему сеансовому пользователю.

    11: Организовав транспортное соединение сущность-инициатор сеансового уровня, теперь может надстроить над ним сеансовое соединение. Поэтому она формирует протокольный блок данных CN (Connect) SPDU, связанный с процедурой установления сеансового соединения, включая в него запомненные пользовательские данные (т.е. CP PPDU и AARQ APDU), и передает его в качестве параметра TSDU посредством примитива T-DATA request по только что построенному транспортному соединению.

    12: Блок TSDU передается как нормальные данные посредством протокольного блока данных DT TPDU. Передача DT TPDU осуществляется опосредованно через поставщика сетевого сервиса с помощью примитива N-DATA request, осуществляющего передачу DT TPDU в своем параметре (как блок NSDU).

    13: Поставщик сетевого сервиса выдает принимающей транспортной сущности примитив N-DATA indication, в параметре которого доставляется сервисный блок NSDU, содержащий DT TPDU.

    14: Управляющая информация блока DT TPDU интерпретируется, а данные пользователя, включающие CN SPDU (точнее TSDU), передаются принимающей сеансовой сущности посредством примитива T-DATA indication.

    15: Протокольный блок данных CN SPDU интерпретируется и если сеансовое соединение может быть установлено, то осуществляется выбор опций и параметров для данного соединения. Далее выдается индикация на запрос об установлении между представительными сущностями сеансового соединения, с которым передается через механизм параметров и блок CP PPDU.

    16: Блок данных CP PPDU интерпретируется, в частности, выполняются действия процедуры переговоров по согласованному выбору представительного контекста и других параметров взаимосвязи на представительном уровне. Уведомление о попытке установления представительного соединения выдается прикладному процессу (точнее его компоненте ACSE) в виде примитива P-CONNECT indication. В параметрах этого примитива передается информация пользователя-инициатора установления прикладной ассоциации блок AARQ APDU, извлеченный из блока CP PPDU.

    17: Блок данных AARQ APDU интерпретируется принимающим элементом ACSE. После выполнения своей части процедуры переговоров и выбора прикладного контекста и других параметров взаимосвязи на уровне прикладной ассоциации, элемент ACSE уведомляет о попытке установления прикладной ассоциации своего пользователя (некоторую компоненту некоторого ASO) посредством примитива A-ASSOCIATE indication.

    18-27: Иллюстрируют дальнейшее развитие процесса установления прикладной ассоциации, когда получая положительные ответы от пользователей сервиса, сущности уровня обмениваются положительными подтверждениями, использую установленное сеансовое соединение.

Рис. 12.4. Процесс установления прикладной ассоциации (продолжение)

Рис. 12.5. Процесс установления прикладной ассоциации (продолжение)