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

Протокол INAP является пользователем протокола ROSE (Remote operations service element - сервисньм элементудаленных операци!?!), определенного в рекомендациях ITU-T Х.219 иХ229, в том смысле, что INAP использует для переноса CBoei?i информации блоки данных протокола ROSE. Протокол ROSE содержится внутри подуровня компонентов ТСАР системы сигнализации ОКС-7 (ITU-T, 0.771-775) и DSS1 (ITU-T, 0.932). Сам по себе, ROSE является стандартизованным прикладным сервисным элементом. Поскольку ROSE предоставляет услуги вызова удаленных процедур, он используется во многих приложениях с распределенно!?! обработко!?!. Для него определены четыре типа блоков данных протокола (PDU - Protocol data unit):

• Invoke - обращение;

• Return Result - возврат результата;

• Return Error - возврат ошибки;

• Reject - отказ.

Чтобы понять модель протокола ROSE, рассмотрим два прикладных объекта, взаимоде1?1ствующих друг с другом. Один из них является клиентом, а друго1?1 - сервером. Клиент подготавливает запрос выполнения сервером некоторо!?! операции (семантика операции является прозрачно!?! для ROSE) посредством процедуры вызова блока данных протокола ROSE - Invoke PDU. Данная процедура в своих параметрах содержит информацию о требуемо:?! операции. Запрошенная клиентом операция упаковывается в блок данных Invoke PDU и передается к серверу, которьм пытается ее выполнить. В зависимости от результата сервер может ответить одним из следующих способов:

• в случае успешного выполнения операции результат передается клиенту в виде блока данных Return Result PDU;

• в случае неуспеха клиенту передается сообщение об ошибке в блоке данных Return Error PDU;

• в случае, когда сервер не распознал запроса, он может послать блок данных с отказом Reject PDU.

Каждьм запрос выполнения операции в точности определяет, ожидается ли ответ, и, если ожидается, то в каком виде он должен быть отправлен. Предусмотрены операции четырех классов:

• операции класса 1 требуют отчета как об успешном, так и о неуспешном результате выполнения операции;

• операции класса 2 требуют отчета только об успешном результате выполнения операции;

• операции класса 3 требуют отчета только о неуспешном результате выполнения операции;

• операции класса 4 не требуют никакого отчета.

Заметим, что OSI ROSE имеет пять классов операций, но подсистема ТСАР ОКС-7 использует только четыре из них, а именно со 2-го по 5-ый. Первые три класса операций подразумевают ожидание пользователем ответа, поэтому необходимо наличие таймеров на обеих сторонах, чтобы быть уверенным, что процесс не «повис».

Нам осталось ввести последнее понятие, относящееся к определению прикладного протокола, в частности, протокола INAP. Этим понятием является прикладной контекст (АС - Application context). Как и ранее, обратимся к примеру, где абонент - прикладной процесс (АР) - сидит перед телефонным аппаратом - прикладным объектом (АЕ), намереваясь начать разговор. Будем рассматривать слова, и даже целые предложения, как операции, которые объединяются в смысловые (контекстные) прикладные сервисные элементы (ASE), например, «АЗЕ-пища», «АЗЕ - музыка» и т.д. В начале разговора оба собеседника согласовывают предмет обсуждения. Пусть таким предметом у них будет обед из пяти блюд, т.е. базой разговора будет «АЗЕ-пища», а обсуждение должно вестись согласно правилам SACF, заключающимся ВТОМ, что порядок обсуждения должен соответствовать порядку употребления блюд, а именно: закуска, суп, мясо или рыба, сыры и десерт. Все, что подлежало согласованию в данном примере, и является прикладным контекстом.

Формально прикладной контекст может быть определен как набор ASE и правил, которые должны соблюдаться при взаимодействии прикладных процессов друг с другом. Прикладной процесс, который инициировал взаимодействие, предлагает один или более контекстов в блоке данных (PDU) и получает ответ, в котором возможность использования контекста либо подтверждается, либо отвергается, либо предлагается другой контекст. В последнем случае текущая ассоциация должна быть закрыта, и открыта новая для представления нового набора прикладных контекстов.

1.3.9.2 Особенности протокола INAP

Услуги, предоставляемые протоколом INAP. Семантика услуг, предоставляемых протоколом INAP, определена на распределенной функциональной плоскости концептуальной модели IN. Основной задачей протокола INAP является перенос информации, которой обмениваются функциональные объекты (FE) и которая определена в информационных потоках (IF) и в соответствующих информационных элементах (IE). В этом месте возникает законный вопрос: почему протокол отвечает за обмен информацией между функциональными объектами (FE), а не физическими объектами - узлами сети IN

(РЕ)? Ответ содержится в разделе 3 рекомендации ITU-T 0.1208, где излагается ключевой принцип архитектурной концепции IN, а именно то, что «протоколы должны быть определены таким образом, чтобы функциональные объекты можно было размещать по физическим элементам любым способом по желанию операторов и производителей оборудования».

Словарь INAP. Словарь протокола INAP состоит из операций, поддерживаемых ROSE, и их параметров, которые, в свою очередь, соответствуют представленным на распределенной функциональной плоскости информационным потокам и информационным элементам.

Теперь читателем достигнута достаточная степень понимания того, как, в принципе, информационные потоки и информационные элементы распределенной функциональной плоскости могут быть использованы в окружении, описанном выше. Рассмотрение детальных проекций информационных потоков и информационных элементов в соответствующие операции и параметры отнесено в часть 3 данной книги, посвященную подробному описанию интерфейсов IN для набора CS-1.

Кодирование INAP. Рекомендация ITU-T 0.1208 предписывает использовать для кодирования протокола INAP язык абстрактных описаний -ASN.1. ЯзыкASN.1 подобен языку Pascal и предназначен для независимого от кодирования определения блоков данных PDU прикладного уровня, которые, сами по себе, являются структурами данных. Язык ASN.1 содержит набор элементарных типов данных и способов создания структурированных типов данных из элементарных типов данных.

Примерами элементарных типов данных могут служить типы: INTEGER (ЦЕЛЫЙ), REAL (ДЕЙСТВИТЕЛЬНЫЙ), BOOLEAN (БУЛЕВСКИЙ), ENUMERATED (ПЕРЕЧИСЛЕННЫЙ), BIT STRING (БИТОВАЯ СТРОКА), OCTET STRING (СТРОКА ОКТЕТОВ).

Примерами структурированных типов данных, используемых в INAP, являются:

• конструкция SET - означает структуру и соответствует конструкции RECORD в языке Pascal;

• конструкция SEOUENCE - это структура (SET) с упорядоченными компонентами, так что они должны посылаться строго в том порядке, какой определен в спецификации;

• для определения массивов данных любых типов могут быть ис-пользоваы конструкции SIZE и OF. Например, SEOUENCE SIZE [1...10]ОР<тип>;

• Конструкция CHOICE соответствует конструкции CASE в языке Pascal и используется для объявления альтернатив;