— Все документы — ГОСТы — ГОСТ Р 54018-2010/ISO/IEC TR 10730:1993 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ. РУКОВОДСТВО ПО ПРИСВОЕНИЮ ИМЕН И АДРЕСАЦИИ

ГОСТ Р 54018-2010/ISO/IEC TR 10730:1993 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ. РУКОВОДСТВО ПО ПРИСВОЕНИЮ ИМЕН И АДРЕСАЦИИ

ГОСТ Р 54018-2010/ISO/IEC TR 10730:1993 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ. РУКОВОДСТВО ПО ПРИСВОЕНИЮ ИМЕН И АДРЕСАЦИИ

Утв. Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2010 г. N 629-ст
Национальный стандарт РФ ГОСТ Р 54018-2010/ISO/IEC TR 10730:1993
"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ. РУКОВОДСТВО ПО ПРИСВОЕНИЮ ИМЕН И АДРЕСАЦИИ"

Information technology. Open Systems Interconnection. Tutorial on naming and addressing

Дата введения - 1 июня 2012 г.
Введен впервые

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0.-2004 "Стандартизация в Российской Федерации. Основные положения"

1 Область применения

Настоящий технический отчет представляет основные понятия и механизмы, определенные в ИСО 7498-3 для удовлетворения потребностей присвоения имен и адресации объектов в среде взаимосвязи открытых систем (СрВОС). Он также содержит логическое обоснование некоторых важных решений, принятых в архитектуре присвоения имен и адресации.

Несмотря на то, что ИСО 7498-3 не дает определения каких-либо конкретных форм присвоения имен и адресации, в конце настоящего технического отчета приведены примеры форм конкретных имен, которые определены в других стандартах взаимосвязи открытых систем (ВОС), показывающих, как понятия и механизмы, определенные в ИСО 7498-3, применяются при присвоении имен определенным объектам.

2 Нормативные ссылки

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

ИСО 3166:1988 Коды для представления названий стран (ISO 3166:1988 Codes for the representation of namens of countries)

ИСО 6523:1984 Обмен информацией. Структура идентификаторов организации (ISO 6523:1984 Data interchange; Structures for the identification of organizations)

ИСО 7498:1984 Системы обработки информации. Взаимодействие открытых систем. Базовая эталонная модель (ISO 7498:1984 Information processing systems; Open Systems Interconnection; Basic Reference Model)

ИСО 7498-3:1989 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация (ISO 7498-3:1989 Information processing systems; Open Systems Interconnection; Basic reference model; Part 3: Naming and addressing)

ИСО 8348/Доп. 2:1988 Информационная технология. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне (ISO 8348:1987/Add. 2:1988 Information processing systems; data communications; network service definition; addendum 2: network layer addressing)

ИСО/МЭК 8824:1990 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактной синтаксической нотации версии один (АСН.1) (ISO/IEC 8824:1990 Information technology; open systems interconnection; specification of abstract syntax notation one (ASN.1)

ИСО/МЭК TO 9577:1990 Информационная технология. Передача данных и обмен информацией между системами. Идентификация протоколов сетевого уровня ВОС (ISO/IEC TR 9577:1990 Information technology; telecommunications and information exchange between systems; protocol identification in the network layer)

ИСО/МЭК 9594:1990 Информационная технология. Взаимосвязь открытых систем. Справочник (ISO/IEC 9594:1990 Information technology; open systems interconnection; the directory)

ИСО/МЭК 9834-I:1993 Информационная технология. Взаимосвязь открытых систем. Процедуры работы полномочных органов регистрации ВОС. Часть 1. Общие процедуры (ISO/IEC 9834-1:1993 Information technology; Open Systems Interconnection; Procedures for the operation of OSI Registration Authorities: General procedures)

ИСО/МЭК 9834-6:1993 Информационная технология. Взаимосвязь открытых систем. Процедуры работы полномочных органов регистрации ВОС. Часть 6. Прикладные процессы и прикладные объекты (ISO/IEC 9834-6:1993 Information technology; Open Systems Interconnection; procedures for the operation of OSI registration authorities: application processes and application entities)

ИСО/МЭК 10021-1:1990 Системы обработки информации. Передача текста. Системы передачи текста, ориентированные на сообщения (MOTIS) (ISO/IEC 10021-1:1990 Information technology; text communication; message-oriented text interchange systems (MOTIS); part 1: system and service overview)

3 Сокращения

В настоящем техническом отчете применены следующие сокращения:

БУС - (режим) без установления соединения;

ВОС - взаимосвязь открытых систем;

ДИО - дерево идентификаторов объектов;

ЗПО - заголовок прикладного объекта;

ИСО (ISO) - Международная организация по стандартизации;

ИДС - информационное дерево справочника;

КДС (DCC) - код данных страны (Data Country Code);

КПО - квалификатор прикладного объекта;

МККТТ (CCITT-) - Международный консультативный комитет по телеграфии и телефонии (Comite Consultatif International Telegraphique et Telephonique);

ООИ - относительное отличающее имя;

ОТ - обработка транзакций;

ПАИ - протокольная адресная информация;

ПБД - протокольный блок данных;

ПДУ - пункт доступа к услугам;

ПДСУ - пункт доступа к сетевым услугам;

ПДУФ (FTAM) - передача файлов, доступ к файлам и управление файлами (File Transfer, Access and Management);

ПО - прикладной объект;

ПОЗ - передача и обработка заданий;

ПП - прикладной процесс;

ППП - пункт подключения подсети;

ПУИ - протокольная управляющая информация;

СОС - система обработки сообщений;

ССПЗ - средства справочника прикладных заголовков;

СССА - средства справочника сетевых адресов;

СрВОС - среда взаимосвязи открытых систем;

СТК1 - совместный технический комитет 1;

ТО - технический отчет;

УМК - указатель международного кода;

УС - режим с установлением соединения (ранее указывался как режим, ориентированный на установление соединения);

УР - уполномоченный по регистрации;

ФАИ - функция адресации инициатора;

ФАП - функция адресации получателя;

ФПИ - функция ПАИ инициатора;

AFI - Authority and Format Identifier (идентификатор уполномоченного и формата);

AFNOR - Французская ассоциация стандартизации;

ANSI - Американский национальный институт стандартов;

BSI - Британский институт стандартов;

ЕСМА - Европейская ассоциация производителей вычислительной техники;

IATA - Международная ассоциация транспортных авиалиний.

4 Стандарт ИСО 7498-3 и его связь с настоящим техническим отчетом

ИСО 7498-3 устанавливает принципы, которым должен следовать любой стандарт, когда возникает необходимость идентификации и/или локализации соответствующих объектов в СрВОС. Для цели локализации объектов используется конкретная форма имени (адреса).

Правила наименования и адресации существенны для успешного применения ВОС. В частности, основным требованием является, чтобы реальная открытая система, хотя ее внутренняя структура может быть сложной, демонстрировала простую структуру наименования и адресации в СрВОС так, чтобы она могла быть легко доступна для любой другой реальной открытой системы. В ИСО 7498-3 развиты понятия, позволяющие проектировать открытые системы, которые могут иметь очень сложную внутреннюю структуру, но эта сложность не видна в пределах СрВОС, и схема адресации представляется очень простой сточки зрения других открытых систем. Эта концепция сохраняет принцип независимости реализации (который является одним из основных правил ВОС), а именно, реальной открытой системе не требуется что-либо знать о структуре реализации любой другой реальной открытой системы, и она не предполагает таких знаний в качестве условия для связи с использованием стандартов ВОС.

Настоящий технический отчет предназначен для разъяснения того, каким образом ИСО 7498-3 решает эту задачу. Технический отчет не предназначен для замены базового стандарта. Там, где возникает любое противоречие между утверждениями настоящего технического отчета и цитируемых стандартов, базовые стандарты являются определяющим источником. Примеры, приведенные в настоящем техническом отчете, не являются предписаниями, а служат только для целей разъяснения.

5 Основные понятия

5.1 Общие вопросы наименования

Имена являются лингвистическими конструкциями, выраженными на некотором языке, то есть имена составлены из заданного набора символов. Имя связано с одним или несколькими объектами. В контексте ВОС имена идентифицируют конкретные объекты связи в СрВОС.

Наименование объектов, рассматриваемых в СрВОС, может иметь глобальный или локальный смысл. Объекты, для которых наименование имеет глобальный смысл, включают в себя реальные открытые системы и элементы уровней ВОС (например, (N)-объект, прикладной-процесс). Адреса этих объектов также имеют глобальный смысл.

Объекты, для которых наименование имеет локальный смысл (то есть смысл в пределах заданной области действия в открытой системе) включают в себя селекторы, вызовы-прикладных-процессов и вызовы-(N)-объектов.

5.1.1 Типы и свойства имен

5.1.1.1 Примитивные, описательные и групповые имена

Имя недвусмысленно в пределах данной области действия, когда оно идентифицирует один и только один объект в пределах этой области. Недвусмысленность имени не препятствует существованию синонимов для объекта, то есть недвусмысленно идентифицировать объект может несколько имен. Понятие недвусмысленности может быть расширено на случай имени набора объектов.

Примеры:

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

- номера рейсов IATA (Международная Ассоциация Транспортных Авиалиний) обычно являются примерами недвусмысленных имен;

- в контексте ВОС сетевые адреса являются по определению недвусмысленными, так как они предназначены для идентификации набора ПДСУ в оконечной системе и в результате локализуют оконечную систему среди всех возможных оконечных систем, подключенных к любой подсети.

Имена могут быть разделены на примитивные и описательные.

Примитивное имя - это имя, которое идентифицирует объект (который сам может быть набором объектов) и которое присваивается назначенным уполномоченным. Не требуется, чтобы внутренняя структура имени была понятна или имела смысл для пользователей.

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

Описательное имя может быть неполным, когда всем утверждениям соответствует множество объектов, или может быть полным, когда оно служит для идентификации единственного объекта (например, описательное имя может идентифицировать несколько прикладных процессов ПДУФ и, таким образом, быть неполным описательным именем. Полным описательное имя было бы в том случае, если бы оно идентифицировало единственный прикладной процесс ПДУФ).

Групповое имя - это примитивное имя или неполное описательное имя, которое идентифицирует набор, содержащий более одного объекта. Когда принадлежность набору не известна пользователю имени, не подразумевается, что пользователь должен знать, является имя групповым или нет (например, вызываемый-(N)-адрес (см. 6.2), когда он используется запрашивающей системой, рассматривается как примитивное имя (независимо от того, является оно групповым или нет), тогда как тот же самый вызываемый-(N)-адрес, когда он обрабатывается внутри отвечающей системы, может рассматриваться как групповое имя). Групповое имя может также идентифицировать элементы (или подмножество элементов) класса объектов, определенного типом объектов.

Примечание 1 - ИСО 7498-3 дает определение примитивного имени как имени, которое идентифицирует объект, хотя неявно подразумевается, что этот объект сам может быть набором объектов. Это вытекает из определения группового имени, как "примитивного имени, которое идентифицирует набор объектов" (ИСО 7498-3, 5.6). Групповое имя является частным случаем примитивного имени, когда известен тот факт, что объект является набором.

Примечание 2 - В общем случае подразумевается, что использование группового имени для конкретной операции приводит к выбору ровно одного элемента набора в качестве цели этой операции (ИСО 7498-3, 5.6). В этом случае запрашивающий операцию обычно не знает, каким образом сделан выбор. Другая возможная интерпретация использования групповых имен осуществляется при обращении к средствам справочника. В этом случае использование группового имени в качестве входных данных для средств справочника приводит к возвращению списка элементов соответствующего набора (ИСО 7498-3, 14.2.3).

Примеры:

- в общем случае фамилия является примитивным именем, не содержащим информацию о свойствах членов семьи;

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

ххуууу, где: хх - двухбуквенный код, идентифицирующий авиакомпанию;

уууу - код (до 4 цифр), идентифицирующий номер рейса компании хх.

Двухбуквенный код (хх) - пример группового примитивного имени: он идентифицирует набор рейсов, обслуживаемых этой компанией (для того, чтобы гарантировать недвусмысленность номеров рейсов IATA, иногда необходимо предоставить дополнительную информацию такую, как "участок маршрута");

- номера лотерейных билетов - пример недвусмысленных примитивных (неописательных) имен;

- подмножество элементов тип-прикладного-процесса (с прикладными-процессами, возможно размещенными в различных концах системы), может быть названо групповым именем "MHS-ORGX". Элементами прикладных-процессов "MHS-ORGX" могут быть, например, все прикладные-процессы СОС в пределах одной организации ("ORGX"). Каждому прикладному-процессу может быть присвоено (примитивное) имя, например "MHS-ORGX-1", "MHS-ORGX-2", ..., "MHS-ORGX-n". Использование группового имени "ORGX" в качестве входных данных для средств справочника прикладных заголовков приведет к списку соответствующих заголовков-прикладных-процессов ("MHS-ORGX-1", "MHS-ORGX-2", ..., "MHS-ORGX-n") (см. 7.3).

5.1.1.2 Заголовки и идентификаторы

Заголовок - это имя, присвоенное объекту для его распознавания среди различных объектов (или наборов объектов). Примерами являются заголовок-прикладного-процесса, заголовок-прикладного-объекта и т.п. Заголовком может быть имя, присвоенное типу объекта для того, чтобы распознавать его среди различных типов объектов. Примерами являются заголовок-типа-прикладного-процесса, заголовок-типа-прикладного-объекта и т.п.

Идентификатор - это имя, присвоенное объекту для его распознавания среди экземпляров этого объекта. Примерами использования идентификаторов являются идентификаторы (N)-ассоциации, (N)-оконечной-точки-соединения, вызова-прикладного-объекта и т.п.

5.1.2 Уполномоченные по наименованию и области наименований

Недвусмысленность присваиваемых имен достигается путем использования уполномоченных по наименованию. Уполномоченным по наименованию является уполномоченный по регистрации имен (см. 7.1.3). Он либо непосредственно распределяет и регистрирует имена (например, сетевые адреса), либо только регистрирует представленные ему имена после проверки того, что они еще не зарегистрированы. Имена, зарегистрированные уполномоченным по наименованию, должны быть выражены на установленном языке согласно конкретным правилам, но уполномоченный по наименованию не осуществляет связывания имени с объектом (или с набором объектов), им поименованным.

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

Объект может быть включен в две или более области наименований (или адресации). Объекту также может быть выделено более чем одно имя из одной области. Таким образом, может быть несколько имен (или адресов), которые идентифицируют (или локализуют) один и тот же объект. Эти имена (или адреса) являются синонимами. В первом случае синонимы неудобны, но на практике являются неизбежными. В другом случае синонимы обычно полезны и используются преднамеренно (например, альтернативные имена или сокращения).

Примеры:

- сейчас синонимом "столица Франции" является имя "Париж - Франция": оба этих имени идентифицируют один и тот же объект;

- названия стран также могут иметь синонимы подобного типа (например, Соединенные Штаты Америки, США, Штаты...);

- термин "ВОС" часто используется вместо "взаимосвязь открытых систем". Оба термина являются синонимами.

5.2 Имена в СрВОС

5.2.1 Открытые системы

Основным компонентом СрВОС является реальная открытая система-система, которая соответствует требованиям стандартов ВОС при взаимодействии с другими реальными системами.

Заголовок-системы используется для идентификации реальной открытой системы. Заголовок-системы является независящим от уровня примитивным именем, то есть он используется для идентификации реальной открытой системы как целого. Одна реальная открытая система именуется одним и только одним заголовком-системы. Заголовок-системы может быть использован вместе с другими квалификаторами и для идентификации конкретных ресурсов ВОС в реальной открытой системе, то есть он может быть использован как основа для построения структурированных имен объектов в данной реальной открытой системе. Например, заголовок-прикладного-процесса может быть основан на заголовке-системы (с добавлением соответствующих квалификаторов).

5.2.2 (N)-подсистемы и (N)-объекты

Открытая система состоит из набора уровней. Каждый уровень в данной открытой системе определяет одну подсистему - (N)-подсистему (для уровня N). Следовательно, (N)-подсистема является элементом иерархического разбиения открытой системы (а именно на (N)-уровне). (N)-подсистема взаимодействует непосредственно только с элементами в (N+1)- и (N-1)-подсистемах этой открытой системы.

(N)-объект является активным элементом в пределах (N)-подсистемы, включающим в себя набор возможностей, определенных для (N)-уровня, который соответствует конкретному типу-(N)-объекта. Тип-(N)-объекта может быть идентифицирован, но необязательно должен или может быть локализован. Напротив, каждый из (N)-объектов (этого типа-(N)-объектов) может быть идентифицирован и локализован; это необходимо, так как (N)-объекты являются активными элементами, которые участвуют в связи. (N)-объект именуется заголовком-(N)-объекта.

Так как (N)-объект представляет коммуникационные возможности (N)-уровня, то различные коммуникационные возможности (N)-уровня могут быть предоставлены различными (N)-объектами, то есть внутри (N)-подсистемы может быть несколько (N)-объектов (например, два различных (N)-протокола, представляемых двумя различными (N)-объектами).

Если (N)-объект вызывается для участия во взаимосвязи, то осуществляется конкретное использование его функций (или части этих функций). Такое использование называется вызовом-(N)-объекта. Вызов-(N)-объекта недвусмысленно именуется идентификатором вызова-(N)-объекта, который должен быть уникален в пределах области действия этого (N)-объекта.

Вместе с (N)-объектами используются следующие имена:

- тип-(N)-объекта именуется заголовком-типа-(N)-объекта;

- (N)-объект именуется заголовком-(N)-объекта;

- вызов-(N)-объекта именуется идентификатором-вызова-(N)-объекта.

5.2.3 Пункты доступа к (N)-услуге; (N)-ПДУ

Для обеспечения (N)-услуги (N+1)-уровню (N)-объект соединяется с одним или несколькими (N)-ПДУ. Для того, чтобы это выполнить, (N)-объект может использовать услугу (N-1)-уровня, предоставляемую одним или несколькими (N-1)-ПДУ.

(N-1)-ПДУ присоединяется к одному (и только к одному) (N)-объекту, и, таким образом, (N)-объект локализуется своим соединением с одним или несколькими (N-1)-ПДУ. Хотя (N-1)-адрес-ПДУ точно идентифицирует (N-1)-ПДУ, в любой данный момент времени этот (N-1)-ПДУ недвусмысленно адресует (N)-объект.

На рисунках 1а и 1b показана взаимосвязь (N)-объекта с (N)-ПДУ и с (N+1)-объектами. Показанная на рисунке 1b связь не допускается, так как (N)-ПДУ может присоединяться только к одному (N+1)-объекту и одному (N)-объекту.

image001.jpg

"Рисунок 1а - Допустимые взаимосвязи (N)-объектов с (N)-ПДУ и (N+1)-объектами"

image002.jpg

"Рисунок 1b - Недопустимые взаимосвязи (N)-объектов с (N)-ПДУ и (N+1)-объектами"

5.2.4 (N)- адрес и (N)-адреса-ПДУ

(N)-адрес идентифицирует набор (N)-ПДУ, все из которых расположены на границе между (N)- и (N+1)-подсистемами. Это определение, например, на сетевом уровне, приводит к следующему: сетевой-адрес идентифицирует набор ПДСУ (ПДУ-сетевого уровня). (N)-адрес используется для локализации (N+1)-объекта или нескольких (N+1)-объектов, которые обеспечивают одни и те же функциональные возможности.

(N)-адрес-ПДУ является (N)-адресом, который идентифицирует единственный (N)-ПДУ. Таким образом, имеется существенное различие между (N)-адресом и (N)-адресом-ПДУ. Могут существовать функции уровня, которые требуют (N)-адрес для идентификации единственного (N)-ПДУ, фактически используемого для обеспечения соединения. Следовательно, определение направления выполняемой операции не является свойством самих адресов, а окончательное решение о том, что идентифицирует конкретный (N)-адрес - единственный (N)-ПДУ или набор из нескольких (N)-ПДУ - основывается на отношениях уровень-уровень и протокол-протокол. На это решение могут также повлиять локальные свойства, связанные с конфигурацией реальной открытой системы.

Из сказанного выше следует, что возможно существование различных организаций системы, например:

a) несколько (N)-объектов, связанных с единственным (N+1)-объектом;

b) несколько (N+1)-объектов, обеспечивающих одни и те же функциональные возможности, которые используют услуги единственного (N)-объекта и т.п.

5.2.5 Использование (N)-адресов

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

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

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

ИСО 7498-3 устанавливает, что (N+1)-подсистема делится на (N+1)-объекты последующим причинам:

- для обеспечения различных (N+1)-протоколов или наборов (N+1)-протоколов;

- для согласования требований защиты и/или административного управления;

- в случае прикладной подсистемы для распознавания различных прикладных процессов и прикладных объектов одного и того же прикладного процесса.

ИСО 7498-3 устанавливает, что (N)-адреса не используются:

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

- для получения информации маршрутизации выше сетевого уровня;

- для различения компонентов аппаратных средств.

Примечание 1 - В некоторых конфигурациях обычное использование (N)-адреса может привести к (N+1)-объекту, полностью содержащемуся в одном компоненте аппаратных средств. Тем не менее, в СрВОС (N)-адрес идентифицирует (N+1)-объект, а не компоненты аппаратных средств.

Примечание 2 - Когда различные протоколы ВОС совместно используют, по крайней мере, минимальный механизм идентификации, который позволяет вычленить каждый тип протокола (например, см. ИСО/МЭК ТО 9577), они могут рассматриваться как подтипы общего типа и должны управляться одним объектом. Таким образом, для распознавания этих различных протоколов не требуется разных адресов.

Эти правила являются очень важными, так как они ограничивают степень сложности реальной открытой системы, которая может быть видна вне этой системы (то есть в пределах СрВОС). Как отмечено выше, внешний вид реальной открытой системы должен быть прост настолько, чтобы она могла быть легко доступна другим реальным открытым системам, даже самым простым. Для представления внешнего вида рекомендуется, чтобы реальная открытая система моделировалась как имеющая по одному объекту каждого уровня ВОС на доступный тип протокола так, чтобы схема адресации была прямой (см. рисунок 2а).

Примечание - Хотя примеры, показанные на рисунках 2а - 2d, иллюстрируют (N)-протоколы в режимах УС и БУС в отдельных (N)-объектах, возможно, что они могут быть в одном и том же (N)-объекте, при условии, что не существует двусмысленности для (N)-ПДУ в режимах УС и БУС.

image003.jpg

"Рисунок 2а - Пример реальной открытой системы с несложной схемой адресации"

Представим реальную открытую систему с довольно сложной внутренней структурой [одной из причин такой сложной и избыточной конфигурации (как в элементах аппаратных, так и программных средств) может быть потребность в высокой надежности]. Для простоты ограничимся сетевым, транспортным и сеансовым уровнями (см. рисунок 2b).

image004.jpg

"Рисунок 2b - Пример сложной реальной внутренней структуры"

Структура этой реальной открытой системы не должна быть видимой извне и ее схема адресации должна оставаться простой. Лучший способ для достижения этого - принять, что на различных уровнях имеется только один УС-объект и один БУС-объект (см. рисунок 2с).

image005.jpg

"Рисунок 2с - Конфигурация ВОС N 1"

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

В этом случае конфигурация реальной открытой системы ВОС могла бы выглядеть так, как показано на рисунке 2d.

image006.jpg

"Рисунок 2d - Конфигурация ВОС N 2"

Кроме целей возобновления связи нет никакого основания различать два объекта в режиме УС (или БУС) в одной и той же (N)-подсистеме и нет никаких критериев для этого. Таким образом, важно иметь возможность доступа к этим объектам в режиме УС (или БУС), как если бы они были одним объектом. Это может быть достигнуто путем использования (N)-адреса, охватывающего все различные (N)-ПДУ, ведущие к этим объектам. Тогда при использовании этих (N)-адресов конфигурация ВОС N 2 (рисунок 2d) выглядит эквивалентной конфигурации ВОС N 1 (рисунок 2с).

Понятие отвечающего-(N)-адреса (см. 6.2) позволит получающей системе указывать, какой конкретный (N)-ПДУ используется для каждого отдельного экземпляра связи. Фактически используемый (N)-ПДУ, идентифицированный (N)-адресом-ПДУ, представляется в отвечающем-(N)-адресе. Таким образом, инициатор уведомляется, какой конкретный (N)-ПДУ из возможного набора (N)-ПДУ, идентифицированных (N)-адресом, представленным инициатором, используется для этого конкретного случая связи. Знание отвечающего-(N)-адреса позволяет инициатору устанавливать последующее соединение с тем же самым (N)-объектом (в большинстве случаев инициатор не заботится о том, какой объект был выбран, тем не менее, этот механизм обязателен, когда есть необходимость в возобновлении связи).

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

ИСО 7498-3 устанавливает, что каждый уровневый стандарт может, в случае необходимости, налагать ограничения на понятия (N)-адресов и отвечающих-(N)-адресов (например, потребовать, чтобы (N)-адрес всегда был простым (N)-адресом-ПДУ). Такие ограничения должны налагаться только тогда, когда доказана их необходимость, так как они будут ограничивать гибкость понятий адресации.

Некоторые существующие стандарты ИСО не делают различия между (N)-адресами и (N)-адресами-ПДУ и, таким образом, обычно устанавливают свои свойства адресации в терминах (N)-адресов-ПДУ. Это происходит из-за того, что они разрабатывались до ИСО 7498-3, и при этом не подразумевалось, что они накладывают ограничение, что (N)-адреса должны относиться к единственному (N)-ПДУ. Свойства, установленные этими стандартами в терминах (N)-адресов-ПДУ, обычно естественным образом расширяются на (N)-адреса, поэтому пересмотр этих документов с учетом понятий, определенных в ИСО 7498-3, был бы как необходимым, так и легко осуществимым.

6 Архитектура и присвоение имен

6.1 Декомпозиция имен

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

В пределах СрВОС может быть очень большое число объектов данного типа, и будет непрактично одному уполномоченному поддерживать требуемый регистр на всемирной основе. В таком случае уполномоченный по регистрации делегирует свои полномочия подуполномоченным при условии, что явно будет установлен метод, который позволяет различать имена, зарегистрированные подуполномоченными. Это, обычно, достигается по правилу префикса, когда имя объекта, зарегистрированного подуполномоченным, всегда содержит в себе префикс, который некоторым образом идентифицирует самого подуполномоченного.

Делегирование полномочий, в случае необходимости, может повторяться до достижения такого уровня подуполномоченного, когда управление регистром становится приемлемым как относительно размера самого регистра, так и относительно легкости доступа к уполномоченному для поиска регистрации некоторого объекта.

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

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

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

6.2 Адресная информация в услугах ВОС

В услугах ВОС адресная информация требуется для того, чтобы позволить (N+1)-объекту указывать поставщика (N)-услуги, у которого может быть найден равноправный (N+1)-объект, являющийся целью сервисного обмена. Из общего характера услуг ВОС следует, что эта адресная информация определена только в терминах присвоенной ей семантики, а не в терминах используемого синтаксического кодирования. Фактически используемое кодирование будет обеспечиваться в пределах элементов протокола, используемых для сообщения значения адресной информации партнеру по соединению.

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

Когда N больше 3 (то есть выше сетевого уровня), (N)-адрес не только включает адресную информацию, относящуюся к (N)-уровню, но также содержит адресную информацию, относящуюся (N-1)-уровню. (N)-адрес передается через (N)-ПДУ как параметр примитивов (N)-услуги. (N-1)-объект может определить через функции-(N-1)-справочника (см. 6.5) (N-1)-адрес из переданного (N)-адреса.

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

Существуют три типа (N)-адреса: вызывающий-(N)-адрес, вызываемый-(N)-адрес и отвечающий-(N)-адрес.

Примечание - В определении услуг конкретного уровня вызывающий-(N)-адрес может указываться как "(N)-адрес-источника", а вызываемый-(N)-адрес - как "(N)-адрес-назначения". Однако в ИСО 7498-3 используются исключительно термины: вызывающий-(N)-адрес и вызываемый (N)-адрес.

Всякий раз, когда (N+1)-объект пытается установить (N)-соединение или передать блок данных в режиме без установления соединения, он должен указать адрес(а) предполагаемого(ых) партнера(ов) и может указать собственный адрес. Адрес партнера указывается как параметр вызываемый-(N)-адрес. Этот адрес указывает (N)-адрес (N)-ПДУ или набора (N)-ПДУ, который дает доступ к желаемому партнеру. Для получения этой информации вызывающий-(N+1)-объект локально использует функции справочника (см. 6.5). Эти функции, в свою очередь, при необходимости могут требовать доступа к внутренним или внешним средствам справочника (см. 7.3).

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

Адрес (N)-ПДУ, закрепленный за инициировавшим (N+1)-объектом (то есть объектом, который инициирует соединение или передает примитив в режиме без установления соединения), передается в примитиве запроса как параметр вызывающий-(N)-адрес. Эта информация предоставляется как параметр примитива услуги с вызывающей стороны, хотя обычно в ней нет необходимости, так как она неявно известна из вызывающей системы. Информация передается к системе получателя в (N)-протоколе, она становится доступной вызываемому (N+1)-объекту как параметр примитива индикации (N)-услуги для ее предоставления вместе с информацией, необходимой для идентификации вызывающего партнера и, возможно, для будущего повторного вызова.

Когда вызываемый-(N)-адрес относится к набору нескольких (N)-ПДУ, то может быть полезно, чтобы получающая система указывала адрес конкретного (N)-ПДУ, который выбирается локально. Это достигается использованием параметра примитива услуг отвечающий-(N)-адрес. Этот конкретный адрес (N)-ПДУ передается обратно вызывающему партнеру и предоставляется ему в примитиве подтверждения (N)-услуги, таким образом появляется возможность будущего повторного вызова того же самого (N)-ПДУ, через который получатель установил первоначальное соединение. Как следствие, отвечающий-(N)-адрес, найденный в примитиве подтверждения, не обязательно идентичен вызываемому-N-адресу, первоначально представленному в примитиве запроса (N)-услуги.

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

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

6.3 Адресная информация в протоколах ВОС

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

Примечание - При передаче данных в режиме с установлением соединения для различения разных соединений к (N)-объекту используются локальные ссылки. Такие локальные ссылки (идентификаторы-оконечной-точки-соединения) назначаются при установлении соединения. Они позволяют указывать тот же самый вызываемый объект, который в каждой участвующей открытой системе использует установленное соединение. Эти локальные ссылки остаются действительными до тех пор, пока сохраняется соединение. Они не обязаны иметь одинаковые значения в оконечных точках соединения.

Адресная информация, предоставленная в примитивах услуг установления (и, возможно, разрыва) соединения в режиме с установлением соединения и во всех примитивах в режиме без установления соединения, передается между открытыми системами как часть протокольной-управляющей-информации (ПУИ) протокольных блоков данных (ПБД). Для этого используется конкретное поле в (N)-ПУИ: поле (N)-протокольной-адресной-информации (N)-ПАИ. Кодирование этого поля является частью спецификации протокола.

Вид адресной информации, передаваемой в (N)-ПАИ, в зависимости от места соответствующего протокола в иерархии протоколов ВОС, относится к двум категориям: полные адреса и/или селекторы.

На 1 - 3 уровнях в подсетях, где область действия адресации ограничивается конкретной средой в пределах подсети, понятие селектора неприменимо и, как следствие, протокол передает полную семантику адресной информации.

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

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

В результате информация, необходимая для доступа к прикладному-объекту, является кортежем:

сетевой-адрес, Т-селектор, С-селектор, П-селектор,

где сетевой-адрес передается через сетевые протоколы, а Т-, С- и П-селекторы передаются через транспортный, сеансовый протоколы и протокол уровня представления.

Таким образом, выше сетевого уровня (N)-адрес эквивалентен паре [(N-1)-адрес, (N)-селектор]. Значение (N)-селектора недвусмысленно идентифицирует набор (N)-ПДУ, находящихся в одной и той же (N)-подсистеме, а значение (N-1)-селектора не может быть получено из значения (N)-селектора.

Значения (N)-селекторов определяются каждой открытой системой локально для транспортного, сеансового протоколов и протокола уровня представления для идентификации сеансовых-объектов, объектов-представления и прикладных-объектов соответственно. Так как (N)-селекторы должны быть недвусмысленны в пределах только своих подсистем, то нет необходимости в уполномоченных по регистрации. Однако их значения должны быть доступны для потенциальных партнеров путем использования некоторого подходящего механизма, такого как двустороннее соглашение или использование внешних средств справочника.

Абстрактный синтаксис (N)-селекторов невидим для какой-либо другой открытой системы, следовательно, выбор представления является исключительно локальным решением. Значения (N-селекторов, область действия которых - пределы соответствующей открытой системы, выбираются локальным администратором открытой системы; локальный администратор должен выбирать абстрактный синтаксис и метод кодирования, который должен использоваться для представления этих значений. Механизм для представления абстрактного синтаксиса и метода кодирования, которые связаны со значением (N)-селектора, не рассматривается в ИСО/МЭК 7498-3.

Современные стандарты, специфицирующие (N)-селекторы, не определяют ни абстрактный синтаксис (например, символы ИСО 646), ни метод кодирования значений (N)-селекторов. Стандарты только устанавливают, что значение (N)-селектора является строкой октетов. Поэтому другим открытым системам должны быть доступны только закодированные значения. Это может быть достигнуто путем записи закодированных значений в средствах удаленного справочника при гарантии того, что администраторы обеспечат эти закодированные значения, откуда бы не использовались средства удаленного справочника.

6.4 Связь между адресной информацией, услугами ВОС и протоколами ВОС

Данная тема иллюстрируется примером, который показывает связь между адресной информацией в услугах ВОС (см. 6.2) и адресной информацией в протоколах ВОС (см. 6.3) для адреса-уровня-представления и связанных с ним кортежей.

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

Адресная информация уровня представления

Сеансовая адресная информация

Транспортная адресная информация

Сетевая адресная информация

Рисунок 3 - Возможное представление адреса-уровня-представления

Это представление описывает одну возможную форму абстрактной семантики адреса-уровня-представления. Абстрактный синтаксис каждой из составляющих (например, сеансовая адресная информация) является локальным вопросом системы, но каждая составляющая идентифицирует набор (N)-ПДУ на границе (N)-подсистема/(N+1)-подсистема.

Другим возможным представлением адреса-уровня-представления является такое, которое не делает видимыми границы между (N)-уровнями в пределах адресного пространства. В этом случае (N-1)-адрес может быть получен из (N)-адреса с использованием метода табличного поиска в каждой подсистеме, где используется это представление.

Абстрактная семантика адреса-уровня-представления передается в равноправную открытую систему посредством П-селектора, С-селектора, Т-селектора и сетевого-адреса, которые, в свою очередь, передаются с использованием некоторого метода кодирования через ПАИ-представления, ПАИ-сеансовую, ПАИ-транспортную и ПАИ-сетевую соответственно.

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

6.5 (N)-функции-справочника

В ИСО 7498-3 определены концептуальные (N)-функции-справочника. Это название (N)-функции-справочника) может ввести в заблуждение, так как эти функции не имеют отношения к какому-либо доступу к средствам справочника (см. 7.3). Они являются абстрактными понятиями, которые разрабатывались для описания того, как (N)-подсистема устанавливает связь между (N)-адресами, (N-1)-адресами, (N)-селекторами, и т.д.

Важно отметить, что, будучи абстрактным понятием, (N)-функции-справочника не должны реализовываться как таковые.

В ИСО 7498-3 определены семь (N)-функций-справочника инициатора и четыре (N)-функции-справочника получателя.

Среди них в примере 8.2 используются следующие:

- Функция Адресации Инициатора 2 - ФАИ2

Для этой функции:

1) входными параметрами являются: ВЫЗЫВАЕМЫЙ-(N)-АДРЕС и ЛОКАЛЬНАЯ информация;

2) выходом является: ВЫЗЫВАЕМЫЙ-(N-1)-АДРЕС.

- Функция Адресации Инициатора 3 - ФАИ3

Для этой функции:

1) входными параметрами являются: ВЫЗЫВАЕМЫЙ-(N-1)-АДРЕС, ВЫЗЫВАЮЩИЙ-(N)-АДРЕС и ЛОКАЛЬНАЯ информация;

2) выходом является: ВЫЗЫВАЮЩИЙ-(N-1)-АДРЕС.

- Функция ПАИ Инициатора 1 - ФПИ1

Для этой функции:

1) входным параметром является: ВЫЗЫВАЕМЫЙ-(N)-АДРЕС;

2) выходом является: ВЫЗЫВАЕМЫЙ-(N)-ПАИ.

- Функция ПАИ Инициатора 2 - ФПИ2

Для этой функции:

1) входным параметром является: ВЫЗЫВАЮЩИЙ-(N)-АДРЕС;

2) выходом является: ВЫЗЫВАЮЩИЙ-(N)-ПАИ.

- Функция Адресации Получателя 1 - ФАП1

Для этой функции:

1) входными параметрами являются: ВЫЗЫВАЕМЫЙ-(N)-ПАИ, ВЫЗЫВАЕМЫЙ-(N-1)-АДРЕС и ЛОКАЛЬНАЯ информация;

2) выходом является: ВЫЗЫВАЕМЫЙ-(N)-АДРЕС.

- Функция Адресации Получателя 2 - ФАП2

Для этой функции:

1) входными параметрами являются: ВЫЗЫВАЮЩИЙ-(N)-ПАИ и ВЫЗЫВАЮЩИЙ-(N-1)-АДРЕС;

2) выходом является: ВЫЗЫВАЮЩИЙ-(N)-АДРЕС.

- Функция Адресации Получателя 3 - ФАП3

Для этой функции:

1) входными параметрами являются: ВЫЗЫВАЕМЫЙ-(N-1)-АДРЕС и ЛОКАЛЬНАЯ информация;

2) выходом является: ОТВЕЧАЮЩИЙ-(N-1)-АДРЕС.

6.6 Специфические аспекты уровней

На конкретном уровне применяются не все (N)-функции-справочника. Общее использование этих функций описано в примерах 8.2. Тем не менее, необходимо подробнее специфицировать наименование на прикладном и сетевом уровнях из-за сложности их внутренней структуры.

6.6.1 Прикладной уровень

6.6.1.1 Прикладные процессы и прикладные объекты

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

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

6.6.1.2 Типы и вызовы

Для прикладного-процесса (прикладного-объекта) иногда желательно указывать "тип", к которому он принадлежит. Это достигается с помощью заголовков-типов-прикладных-процессов (заголовков-типов-прикладных-объектов), которые должны быть недвусмысленными в пределах СрВОС и, следовательно, должны быть зарегистрированы.

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

6.6.1.3 Соединения

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

Необходимо, чтобы эти идентификаторы были недвусмысленными только в пределах области взаимодействия вызовов-прикладных-объектов (то есть вызовов в конечных точках соединения) и, следовательно, не должны регистрироваться.

6.6.1.4 Структура наименований прикладного уровня

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

a) заголовок-прикладного-процесса является базовым элементом структурной схемы. Он может быть построен с использованием заголовка-системы в качестве основы для формирования его имени;

b) заголовок-прикладного-объекта составляется из заголовка-прикладного-процесса и квалификатора-прикладного-объекта;

c) при необходимости идентификации вызов-прикладного-процесса идентифицируется парой:

1) заголовок-прикладного-процесса, к которому он относится;

2) идентификатор-вызова-прикладного-процесса, который является недвусмысленным в пределах области действия прикладного-процесса;

d) при необходимости идентификации вызов-прикладного-объекта идентифицируется набором:

1) заголовок-прикладного-объекта, к которому он относится;

2) идентификатор-вызова-прикладного-процесса, который является недвусмысленным в пределах области действия прикладного-процесса;

3) идентификатор-вызова-прикладного-объекта, который является недвусмысленным в пределах области действия как вызова-прикладного-процесса, так и прикладного-объекта.

Примечание - Способ использования заголовков-прикладных-объектов и заголовков-прикладных-процессов для получения адресной информации описывается с помощью средств справочника (см. 7.3).

Пример возможной структуры наименования для "банковской прикладной задачи":

- банковская прикладная задача обеспечивает две возможности, а именно: возможность передачи файла (используя ПДУФ) и возможность обработки транзакций (используя ОТ);

- банковской прикладной задаче может быть дан заголовок-прикладного-процесса "SEOUL-ABC";

- возможности ПДУФ может быть дан заголовок-типа-прикладного-объекта"РТАМ". Возможности ОТ может быть дан заголовок-типа-прикладного-объекта "ТР";

- прикладной-процесс "SEOUL-ABC" может иметь два прикладных-объекта: один типа "FTAM", а другой - типа "ТР";

- заголовку-прикладного-объекта типа "FTAM" может быть присвоено имя "SEOUL-ABC.F"; заголовку-прикладного-объекта типа "ТР" может быть присвоено имя "SEOUL-ABC.T";

- использование объекта "SEOUL-ABC.F" в ассоциации с удаленным ПДУФ-объектом "SYDNEY-ABC.F" является вызовом-прикладного-объекта. При необходимости этот вызов-объекта можно идентифицировать идентификатором "24" в прикладном-объекте "SEOUL-ABC.F", в то время как парный ему вызов-объекта может быть идентифицирован идентификатором "цр".

На рисунке 4 показан другой пример заголовков прикладных процессов/объектов и идентификаторов вызова.

Примечание 1 - Эти идентификаторы-вызовов-прикладных-объектов должны быть различными, если они связаны с вызовами-прикладных-объектов, которые относятся к одному и тому же вызову-прикладного-процесса.

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

image007.jpg

"Рисунок 4 - Примеры заголовков и идентификаторов прикладных процессов и объектов"

6.6.2 Сетевой уровень

На транспортном, сеансовом уровнях и уровне представления ПАИ требуется только для передачи селекторов. На сетевом уровне ПАИ должна передавать полный сетевой-адрес.

Сетевой-адрес является недвусмысленным в пределах СрВОС и идентифицирует набор ПДСУ, предоставляющих доступ к данному транспортному-объекту в одной открытой системе. Пользователи сетевых-услуг не могут ни получать маршрутную информацию из сетевого-адреса, ни влиять на выбор маршрута посредством сетевого-адреса.

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

Функцией сетевого уровня является использование сетевого-адреса для маршрутизации - то есть получение адреса ППП из вызываемого-сетевого-адреса. Этот адрес ППП будет или адресом ППП целевой оконечной системы (идентифицированной вызываемым-сетевым-адресом), или адресом ППП промежуточной системы, которая является первым (или единственным) транзитным участком на пути к целевой оконечной системе (тогда промежуточная система получает задачу определения ближайшего подходящего адреса ППП; эта функция повторяется до тех пор, пока не будет достигнута целевая оконечная система).

В общем случае открытой системе потребуется использование средств справочника сетевых адресов (СССА) для получения информации о сетевых-адресах - отображений ППП-адреса. Связи между сетевыми-адресами и ППП-адресами могут быть один-к-одному, один-ко-многим, или многие-ко-многим. Возможности, предоставляемые СССА, вероятно, будут распределенными в системах в пределах СрВОС. Когда открытая система запрашивает использование этих (пространственно разнесенных) возможностей, то для доступа к ним она будет использовать методы взаимосвязи ВОС.

Сетевая-ПАИ должна переносить и сетевой-адрес, и ППП-адрес. Обычно, в сетевой-ПАИ имеется одно поле для переноса сетевого-адреса и отдельное поле для переноса ППП-адреса.

Сетевой-адрес в сетевой-ПАИ переносится явно между взаимодействующими оконечными системами. Поле сетевой-ПАИ, переносящее ППП-адрес, может содержать различные ППП-адреса, так как оно пересекает промежуточные системы на маршруте между двумя связанными оконечными системами. Фактически, в каждой промежуточной системе для определения следующего транзитного участка на пути к целевой оконечной системе сетевой уровень рассматривает сетевой-адрес и помещает ППП-адрес следующей промежуточной системы в поле ППП-адреса в сетевой-ПАИ.

На рисунках 5 и 6 показаны примеры использования сетевых-адресов и ППП-адресов (для взаимодействия, инициированного оконечной системой А, когда оконечная система В является получателем).

image008.jpg

"Рисунок 5 - Вызов между оконечными системами, относящимися к одному и тому же пространству ППП-адресов"

image009.jpg

"Рисунок 6 - Вызов между оконечными системами, относящимися к разным пространствам ППП-адресов"

Примечание - В примерах, представленных на рисунках 5 и 6, А и В принадлежат одному и тому же адресному пространству, когда система В имеет адрес ППП, непосредственно достижимый инициатором (системой А) для любого конкретного случая соединения. Пространство ППП-адресов может охватывать одну или несколько подсетей.

7 Среда ВОС и имена

К настоящему времени детализированы общие вопросы наименований и адресации. Для правильной работы в СрВОС реальных систем и реализаций имена и адреса информационных объектов должны быть определены и сделаны доступными некоторым или всем объектам взаимосвязи.

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

Для присвоения имен и адресов используются уполномоченные по регистрации, для хранения имен и адресов используют средства справочника.

7.1 Стандарты, имеющие отношение к присвоению имен

Как указывалось в разделе 1 настоящего стандарта, ИСО 7498-3 определяет понятия имен, адресов и идентифицирует, какие объекты должны именоваться в СрВОС.

ИСО 7498-3 моделирует (N)-функции-справочника (см. 6.5) и средства справочника (см. 7.3). Целью средств справочника является предоставление адресной информации, заданной именем. (N)-функции-справочника концептуально существуют на каждом уровне эталонной модели для обеспечения локального отображения адресной информации.

ИСО 7498-3 определяет также понятие уполномоченного по регистрации. Однако он не определяет ни структуру имен или адресов, ни процедуры регистрации этих имен или адресов.

Для обеспечения более специфических потребностей разработаны другие стандарты. В настоящем подразделе дается обзор текущего состояния дел, относящихся к работе ИСО/МЭК СТК 1 в этой области. Описание работы уполномоченных по регистрации (см. 7.1.3) может изменяться по мере развития стандартов.

7.1.1 Справочник

В ИСО/МЭК 9594 определены общие задачи справочника относительно доступа прикладных задач и соответствующие услуги справочника. Этот стандарт применяется, когда информация должна храниться и удаленно разыскиваться в записи справочника, относящейся к прикладному процессу и/или прикладному объекту.

Справочник является развитием понятия услуги справочника, первоначально определенной в СОС для своих потребностей. Имена информационных объектов ВОС могут храниться и разыскиваться приложениями в справочнике вместе с набором атрибутов, описывающих объекты (отметим, что версия СОС МККТТ1984 определяет свой собственный справочник, а версия МККТТ1988 использует справочник, определенный в ГОСТ ИСО/МЭК 9594).

В ИСО/МЭК 9594 определено понятие иерархического дерева, известного как информационное дерево справочника (ИДС). Структура ИДС вместе с соответствующими процедурами регистрации может быть использована для гарантии того, что объектам присваиваются недвусмысленные имена.

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

Примечание - ИСО/МЭК 9594 не обеспечивает средство справочника сетевых адресов (см. 7.3.2). Это средство частично обеспечивается использованием протоколов маршрутизации. Используя свои собственные методы, они позволяют оконечным и промежуточным системам обмениваться информацией о сетевых-адресах, ППП-адресах и соответствующей информацией, такой как параметры качества услуги и доступность маршрутов.

7.1.2 Идентификаторы объектов

В ИСО/МЭК 8824 определено дерево идентификаторов объектов (ДИО). Кроме того, в приложениях В, С и D ИСО/МЭК8824 вводятся дуги из корневого узла ДИО. Понятие ДИО вместе с соответствующими процедурами регистрации используется как основа для создания недвусмысленных имен информационных объектов.

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

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

7.1.3 Уполномоченные по регистрации

В ИСО/МЭК 9834-1 специфицированы различные этапы присвоения имен.

Регистрация заключается в присвоении недвусмысленного имени экземпляру типа информационного объекта.

Регистрация осуществляется агентом по регистрации. Уполномоченным по регистрации является организация, действующая как агент по регистрации. Агентом по регистрации может быть стандарт: например, как ИСО 8571 в отношении типов документов ВОС, которые в нем определены.

Для большей гибкости полномочия могут быть делегированы агентом по регистрации, ответственным за область наименований, подчиненным ему агентам по регистрации.

Для обеспечения недвусмысленности выбирается древовидная структура имени: имя создается иерархическим методом. Таким образом, имя информационного объекта включает в себя компонент имени, присвоенный ему агентом по регистрации, сцепленный в качестве суффикса с именем самого агента по регистрации.

В ИСО/МЭК 9834-1 идентифицированы две формы имени для регистрации: форма, основанная на атрибутах, и форма идентификатора объекта. Подробнее см. 8.3.

7.2 Регистрация имен

Для обеспечения удобного управления процессом регистрации процедура регистрации допускает иерархию подуполномоченных.

Например, некоторые международно-признанные организации (такие как ЕСМА, EWOS) запросили выделить им код ICD (согласно ИСО 6523) в качестве первого шага для признания их уполномоченными по регистрации для того, чтобы присваивать имена в соответствии с собственными потребностями (идентификация документов, членов и т.п.).

Страны, идентифицируемые кодом страны DCC (по ИСО 3166), могут идентифицировать свои национальные организации в качестве уполномоченных по регистрации для присвоения имен в соответствии с потребностями организаций. Примерами таких уполномоченных по регистрации для присвоения имен организациям являются ANSI в США, BSI в Великобритании, AFNOR во Франции.

Подуполномоченые по наименованию под узлами ICD и DCC могут назначать имена различным объектам. Кроме того, эти подуполномоченные далее могут делить свое пространство имен и передавать полномочия по наименованию в подпространствах своим подуполномоченным.

Примерами типов имен, для которых уполномоченные по регистрации распределяют имена, являются:

- заголовки ВОС:

- заголовки-систем,

- заголовки-прикладных-процессов,

- заголовки-типов-прикладных-процессов,

- заголовки-типов-прикладных-объектов и др.;

- адреса СОС (ИСО/МЭК10021-1 А);

- сетевые-адреса (ИСО 8348/Доп. 2).

Примечание - В ИСО 8348/Доп. 2 определено понятие иерархического дерева для сетевых адресов. Дерево имен для сетевых адресов вместе с соответствующими процедурами регистрации используется для гарантии того, что присвоены недвусмысленные имена (см. 8.3.5).

ИСО/МЭК 8824, ИСО/МЭК 9594 и ИСО/МЭК 9834 обеспечивают механизмы, гарантирующие недвусмысленность и глобальный смысл имен. Подчиненные уполномоченные в своей области наименований могут определять свои собственные правила для структуры имен при условии соответствия этим международным стандартам.

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

7.3 Средства справочника

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

Если средства справочника предназначены для удаленного доступа, то они должны быть доступны через услуги и протоколы ВОС.

Определены два основных средства:

a) ССПЗ (средство справочника прикладных заголовков) обрабатывает заголовки-прикладных-процессов и/или заголовки-прикладных-объектов и выдает относящуюся к ним адресную информацию;

b) CCCA (средство справочника сетевых адресов) обрабатывает сетевые-адреса и выдает относящуюся к ним маршрутную информацию.

7.3.1 ССПЗ

ССПЗ (функции которого показаны на рисунке 7) состоит из двух компонентов для выдачи соответствующей информации, связанной с полученными им входными данными - то есть с именем:

- "разрешитель имени", который способен преобразовывать групповое или неполное описательное имя в соответствующие примитивные (негрупповые) или полные описательные имена;

- "справочник", который возвращает адресную информацию, связанную с примитивным или полным описательным именем.

Входными данными для компонента ССПЗ "разрешитель имени" является заголовок-прикладного-процесса или заголовок-прикладного-объекта. Заголовок-прикладного-процесса или заголовок-прикладного-объекта может быть групповым (например, они могут быть заголовками-типа-ПП или - ПО).

Если входными данными является:

а) групповой заголовок-прикладного-процесса, то компонент ССПЗ "разрешитель имени" возвращает список соответствующих негрупповых заголовков-прикладных-процессов. Эти негрупповые заголовки-прикладных-процессов могут затем стать входными данными для компонента ССПЗ "разрешитель имени" (см. перечисление b);

b) негрупповой заголовок-прикладного-процесса, то компонент ССПЗ "разрешитель имени" возвращает список негрупповых заголовков-прикладных-объектов, идентифицирующих прикладные-объекты, относящиеся к рассматриваемому процессу;

c) групповой заголовок-прикладного-объекта, то компонент ССПЗ "разрешитель имени" возвращает список связанных негрупповых заголовков-прикладных-объектов.

Любой негрупповой заголовок-прикладного-объекта (который может являться выходными данными компонента ССПЗ "разрешитель имени") может быть использован в качестве входных данных для компонента ССПЗ "справочник". Компонент ССПЗ "справочник" используется для получения соответствующей адресной информации, которая необходима для локализации равноправного объекта. Эта информация определяется кортежем вида:

(П-селектор,

С-селектор,

Т-селектор,

сетевые-адреса) (или список сетевых-адресов).

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

Ниже приводится пример использования ССПЗ.

Прикладная задача с заголовком ALPHA в оконечной системе с заголовком 627 требует (как часть своих функций) выполнить некоторые вычисления. Оказалось, что эти вычисления требуют использования некоторого высокопроизводительного параллельного процессора помимо возможностей процессоров, доступных в пределах системы 627.

Тогда на первом шаге задача ALPHA, используя, например, ПОЗ, может потребовать передачи этой части работы некоторой другой оконечной системе, в которой существует такая производительная обработка. Для этого задача ALPHA должна знать заголовок прикладного-объекта нужного прикладного-процесса. Он может быть конкретно идентифицирован прикладной задачей, или задача ALPHA может не иметь предпочтительного партнера и может обращаться к любой одной из ряда таких прикладных задач. В первом случае задача ALPHA должна содержать в себе примитивное имя для заголовка удаленного партнера, скажем - "PARPROC84". Во втором случае задача ALPHA должна быть обеспечена групповым заголовком-прикладного-объекта для группы партнеров, скажем - "PARPROC". Этот случай рассматривается ниже в настоящем примере.

На втором шаге задаче ALPHA должен быть предоставлен адрес-уровня-представления выбранного прикладного-объекта. Обе функции достигаются через ССПЗ по запросу задачи ALPHA.

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

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

Когда локальная часть ССПЗ не может обеспечить информацию о группе PARPROC, она взаимодействует, используя протоколы справочника, с остальной частью распределенного ССПЗ, получает информацию о группе PARPROC и передает ее задаче ALPHA локальным способом. В зависимости от реализации локальный ССПЗ может принять решение воспользоваться информацией о группе PARPROC, полученной таким образом, и сохранить ее для будущих запросов тех же партнеров, которые могут возникнуть в системе 627.

На рисунке 7 показаны возможные различные входные данные и точки входа в ССПЗ.

image010.jpg

"Рисунок 7 - Функционирование ССПЗ"

7.3.2 СССА

Вызывающий-сетевой-адрес и вызываемый-сетевой-адрес передаются (как параметры примитива сетевой услуги) инициирующим транспортным объектом связанному инициирующему сетевому объекту. Вызываемый-сетевой-адрес (который является частью адресного кортежа, предоставленного ССПЗ) неявно идентифицирует транспортный объект, который должен быть достигнут в удаленной оконечной системе. Таким образом, существует необходимость в доступе к этой удаленной оконечной системе. Функцией СССА является обеспечение информации, необходимой для достижения этой цели.

СССА требует в качестве входных данных вызывающий- и вызываемый-сетевые-адреса и возвращает, используя соответствующие процедуры, вызывающий- и вызываемый-адреса-каналов-передачи-данных, вызываемую-сетевую-ПАИ, вызываемую-подсетевую-адресную-информацию, вызывающую-сетевую-ПАИ и вызывающую-подсетевую-ПАИ.

СССА отличается от ССПЗ тем, что информация, предоставляемая СССА, зависит от относительного расположения реальных открытых систем, которые предполагается связать, тогда как информация, предоставляемая ССПЗ, не зависит от этого расположения. Таким образом, когда заголовок-прикладного-объекта является входными данными для ССПЗ, то результатом всегда является одна и та же адресная информация (по крайней мере, пока эта информация не обновится в ССПЗ). Однако когда инициирующая оконечная система вводит сетевой-адрес в СССА, информация, которая возвращается, включает в себя маршрутную информацию в форме первого (или единственного) транзитного участка на пути к целевой оконечной системе. Как было описано выше (6.6.2), ППП-адрес первого транзитного участка может быть ППП-адресом целевой оконечной системы, если эта система достижима непосредственно, или ППП-адресом промежуточной системы, если целевая оконечная система непосредственно не достижима. Таким образом, из СССА могут быть получены различные результаты в зависимости от относительного расположения двух оконечных систем.

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

8 Примеры

8.1 Объекты и адреса

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

Следующие два примера (рисунки 8а и 8b) преследуют цель прояснить это требование. На рисунке 8а: А, В, ... G являются (N-1)-адресами; v, w, ... z являются (N)-селекторами.

Возможными допустимыми (N)-адресами являются следующие:

Av, Aw, Ax, Bv, Bw, Bx, Ey, Ez, Gy, Gz.

Возможными недопустимыми (N)-адресами являются следующие:

Ay, Bz, Fw, Gx.

image011.jpg

"Рисунок 8а - Взаимосвязи между селекторами, относящимися к (N)-ПДУ и (N-1)-ПДУ"

Примечание - Может показаться, что формат (N)-адресов, используемых в этом примере, подразумевает иерархическое построение (N)-адреса из (N-1)-адреса и (N)-селектора. Этот формат используется только для упрощения. (N)-адреса являются вполне понятийными, а их действительное представление в реальной открытой системе является локальным вопросом.

На рисунке 8b lu, It, Ht являются возможными допустимыми адресами, так как любой выбранный (N-1)-ПДУ всегда доступен (N)-ПДУ. Ни является недопустимым адресом, так как, если для конкретного соединения используется (N-1)-ПДУ D, то он недоступен (N)-ПДУ.

image012.jpg

"Рисунок 8b - Взаимосвязи между селекторами, относящимися к наборам (N)-ПДУ и (N-1)-ПДУ"

В примере на рисунке 9 показаны со 2 по 5 уровни системы "S", где сеансовый уровень включает в себя два сеансовых-объекта в режиме-с-установлением-соединения, названные объект А и объект В (возможные причины такого внутреннего устройства обсуждались в 5.2.5). Однако для любой другой открытой системы (и, таким образом, для СрВОС) различий между А и В быть не должно, так как они оба обеспечивают одну и ту же услугу. Следовательно, А и В являются доступными в целом благодаря использованию единственного транспортного-адреса Т1, и внешний вид подсистемы очень прост.

Если, по каким-то причинам, удаленной системе необходимо в последующем транспортном соединении возвратиться к тому же самому сеансовому объекту (то есть к тому сеансовому объекту, который использовался в предыдущем транспортном соединении), то должна быть возможность различать ТПДУ, открывающая ей доступ к А и В. Это возможно благодаря использованию "отвечающего-транспортного-адреса", который должен предоставляться системой "S".

Следовательно, в общем случае соединения удаленные открытые системы не делают различия между объектами А и В, а единственным транспортным-адресом, известным им для сеансового-объекта в режиме-с-установлением-соединения, будет Т1. Когда соединение установлено, система "S" возвращает в качестве отвечающего-транспортного-адреса адрес конкретного ТПДУ, который использовался в этом конкретном соединении (например, Т4). Инициализирующая подсистема может затем, если ей это необходимо, сохранить этот транспортный-адрес (Т4) для использования в последующем соединении. Тогда использование Т4 вместо Т1 будет означать, что удаленная оконечная система желает вернуться к тому же самому сеансовому-объекту, с которым она имела предыдущее соединение.

image013.jpg

"Рисунок 9 - Пример структуры адресации для уровней 2-5 системы "S"

Примечание 1 - Для простоты на несколько адресов ТПДУ был разбит только транспортный-адрес Т1. Естественно, эта декомпозиция может применяться к любому (N)-адресу по усмотрению администратора системы "S".

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

8.2 Установление прикладной-ассоциации

8.2.1 Получение имен

Предположим, что прикладной-объект, названный NAMEA, хочет начать соединение с другим удаленным прикладным-объектом. NAMEA для общения с удаленным объектом должен знать его имя, заголовок-прикладного-объекта, например - NAMEB.

Инициирующий прикладной-объект посылает NAMEB в ССПЗ; средства ССПЗ возвратят кортеж для локализации NAMEB, например:

aofNAMEB=рр ss tt XYZ,

где

aofNAMEB является недвусмысленным в пределах СрВОС и локализует NAMEB;

рр ss tt являются именами положения удаленной системы;

рр является селектором уровня представления;

ss является селектором сеансового уровня;

tt является селектором транспортного уровня;

XYZ является недвусмысленным в пределах СрВОС сетевым-адресом реальной системы, в которой размещен NAMEB.

Селекторы используются на уровнях с 6 по 4 и передаются взаимодействующим равноправным объектам в ПАИ.

На 3 уровне сетевой объект получает имя XYZ. Затем сетевой-объект вызывает средства СССА; эти функции возвращают ППП-адрес, указывающий следующий транзитный участок пути, куда надо следовать для достижения транспортного-объекта, соответствующего адресу XYZ.

Примечание

- В случае, когда реальная открытая система обеспечивает как ССПЗ, так и СССА, возвращение информации от обоих средств справочника может быть сделано единственным запросом.

8.2.2 Уровневые механизмы в вызывающей системе

На рисунке 10 показаны основные действия инициатора с (N)-функциями-справочника (см. 6.5) в вызывающей открытой системе, когда вызываемый- и вызывающий-адрес-уровня-представления передаются объекту уровня представления как параметры сервисного примитива уровня представления.

8.2.3 Уровневые механизмы в вызываемой системе

На рисунке 11 показаны основные действия получателя с (N)-функциями-справочника (см. 6.5) в вызываемой открытой системе, когда сетевой ПБД, посланный инициирующей системой и несущий вызываемый- и вызывающий-сетевой-адрес, достиг систему получателя.

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

Примечание 2 - Структура, показанная на рисунках 10 и 11 для (N)-адресов, является только примером возможной внутренней структуры. Она была использована потому, что делает видимой связь между (N^селекторами и (N)-адресами. Для существующих реализаций могут быть использованы другие внутренние структуры.

Прикладной уровень

image014.jpg

"Рисунок 10 - Влияние способов инициализации в вызывающей оконечной системе"

image015.jpg

"Рисунок 11 - Влияние методов получения в вызываемой оконечной системе"

8.3 Примеры конкретных форм имен, опубликованных в стандартах ВОС

8.3.1 Формы имени, основанного на атрибутах

Основанное на атрибутах имя состоит из нескольких относительных отличающих имен (ООИ). Компонент ООИ состоит из нескольких утверждений-значений-атрибута, где каждое утверждение-значение-атрибута строится из двух элементов: тип атрибута и значение атрибута. Тип атрибута является идентификатором объекта, а значение атрибута может быть построено из конкретного типа набора символов (например, набор печатаемых символов).

Примером основанного на атрибутах имени может быть имя справочника, имеющее следующую структуру:

Country

=

Франция

Organization

=

ABC

Organizational Unit

=

Отдел маркетинга

В этом примере имя справочника образуется из трех ООИ, каждое из которых построено из единственного утверждения значения атрибута. "Country", "Organization" и "Organizational Unit" являются типами атрибутов. "Франция", "ABC" и "Отдел маркетинга" являются их значениями атрибутов в соответствующих утверждениях значений атрибутов.

8.3.2 Форма имени, основанного на идентификаторе объекта

Имя идентификатора объекта является последовательностью целочисленных значений. На рисунке 12 показана верхняя часть ДИО с тремя дугами из корневого узла и дугами, непосредственно подчиненными узлам, идентифицированным "ccitt" и "iso".

image016.jpg

"Рисунок 12 - Дерево идентификаторов объектов"

Примером основанного на идентификаторе объекта имени является:

{iso (1) member-body (2) france (250) type-org (1) abc (6325) marketing department (316)},

где "type-org" - компонент идентификатора объекта, показывающий, что последующие компоненты относятся к организации.

8.3.3 Заголовки, относящиеся к прикладному уровню

8.3.3.1 Заголовок-прикладного-процесса

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

Заголовку-прикладного-процесса может быть присвоено имя в форме, основанной на атрибутах или на идентификаторе объекта. Квалификатору-прикладного-объекта может быть присвоено имя в форме, основанной на атрибутах или на идентификаторе объекта.

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

На рисунке 13 показан пример построения ПП-заголовка в форме, основанной на атрибутах.

image017.jpg

8.3.3.2 Заголовки-прикладных-объектов

Имя заголовка-прикладного-объекта (ЗПО) формируется путем добавления квалификатора-прикладного-объекта (КПО) к заголовку-прикладного-процесса.

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

{SALES (3)} (для имени в форме идентификатора объекта)

8.3.3.3 Заголовки-типов-прикладных-процессов/объектов

Заголовок-типа-прикладного-процесса (или заголовок-типа-прикладного-объекта) может идентифицировать всех членов конкретного типа-прикладного-процесса (или типа-прикладного-объекта) в СрВОС. Альтернативно этому заголовок-типа-прикладного-процесса (или заголовок-типа-прикладного-объекта) может идентифицировать определенное подмножество членов конкретного типа-прикладного-процесса (или типа-прикладного-объекта).

Для заголовка-типа-прикладного-процесса/объекта, который идентифицирует все члены конкретного типа в СрВОС, требуется недвусмысленность имени. Недвусмысленность имени достигается благодаря уполномоченному по регистрации. Для заголовка-типа-прикладного-процесса/объекта, который идентифицирует определенное подмножество членов конкретного типа-прикладного-процесса/объекта, также может потребоваться недвусмысленность имени.

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

organization

=

ABC

common name

=

SALES

8.3.4 Система обработки сообщением - COC (MHS, Х400/ИСО 10021 (MOTIS)

В COC пользователи идентифицируются с помощью имен отправителя/получателя (О/П имен).

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

В СОС определен набор стандартных атрибутов, таких как:

общие: имя-области-управления, название-страны, сетевой-адрес,

название-организации, название-организационной-единицы, имя-сотрудника и т.п.;

почтовой адресации: адрес-почтового-ящика-офиса, адрес-улицы, уникальное-почтовое-имя и т.п.

Можно рассмотреть тот же самый пример, что и для Справочника (8.3.1), используя часть этих атрибутов и соответствующие утверждения значений атрибутов.

8.3.5 Сетевые адреса

Согласно ИСО 7498-3 сетевой адрес является недвусмысленным в СрВОС именем, которое используется для идентификации группы пунктов доступа к услугам сетевого уровня (ПДСУ), расположенных на границе между подсистемами сетевого и транспортного уровней в одной и той же открытой системе. Адрес ПДСУ является сетевым адресом, который используется для идентификации одного ПДСУ.

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

Уполномоченный по адресации А, ответственный за адресацию в области D, может делегировать далее ответственность за D, разделив D на подобласти D1 - Dk и назначив уполномоченных А1 - Ak для распределения адресного пространства в пределах подобластей адресации D1 - Dk. В свою очередь, любой из этих уполномоченных таким же образом может делегировать свою ответственность.

В ИСО 8348/Доп.2 из корневого узла для сетевых адресов определены семь дуг и, следовательно, семь верхних уровней уполномоченных по адресации. Это следующие дуги:

- Х.121;

- ISODCC;

- F.69;

- Е.163;

- Е.164;

- ISOICD;

- Локальный (см. примечание).

Примечание - Формат локального сетевого адреса не требует "глобального" уполномоченного по регистрации, но может требовать "локального" уполномоченного по регистрации для гарантии недвусмысленности адресов в пределах области действия его локальной среды.

Уполномоченный по регистрации требуется для каждого формата сетевого-адреса МККТТ (то есть Х.121, F.69, Е.163 и Е.164) и для каждого формата сетевого-адреса ИСО (то есть ISO DCC и ISO ICD). Уполномоченные по регистрации для присвоения этих номеров для других целей уже существуют (например, номер по X. 121 используют в глобальной открытой сети Х.25, номер по Е.163 используют для международной телефонной сети). Можно полагать, что объектам, которым были выделены номера одним из этих уполномоченных по регистрации для их первоначальных целей, выделены эти же номера для использования в сетевых адресах систем в пределах их полномочий.

Структура сетевого адреса, определенная в ИСО 8348/Доп.2, представлена на рисунке 14.

image018.jpg

"Рисунок 14 - Структура сетевого адреса"

Компонент "идентификатор уполномоченного и формата" (AFI) в сетевом-адресе указывает формат (то есть Х.121, КДС ИСО и т. д.) идентификатора начальной области (IDI) сетевого адреса. Компонент IDI содержит номер, присвоенный соответствующим уполномоченным по регистрации для каждого конкретного формата сетевого-адреса. Владелец номера в компоненте IDI является уполномоченным по регистрации для специфической части области (DSP) сетевого-адреса. Уполномоченный по регистрации для компонента DSP может далее делить адресное пространство, разделив компонент DSP и передав ответственность за регистрацию (в каждой части DSP) подуполномоченным по регистрации. Как было сказано ранее, любой из этих уполномоченных, в свою очередь, может разделить адресное пространство, за которое он отвечает, используя аналогичный метод.

На рисунке 15 показан пример формата сетевого-адреса КДС ИСО с компонентом DSP, разделенным на четыре компонента.

image019.jpg

"Рисунок 15 - Формат сетевого адреса КДС ИСО (ISO DCC)"

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

Уникальный номер для компонента "идентификатор организации" должен быть получен от национального уполномоченного по регистрации, который является ответственным за распределение этих номеров в конкретной стране (или географической области). Владелец "идентификатора организации" может далее подразделять адресное пространство, как показано на рисунке 15. Примером сетевого-адреса, основанного на этой структуре, тогда может быть:

39

-

двоичный адрес ISO DCC;

438

-

код страны Лихтенштейн (ИСО 3168);

12 34 56

-

идентификатор организации;

00 03

-

идентификатор подсети;

00 00 00 00 00 05

-

адрес подсети;

01

-

селектор ПДСУ.

На рисунке 16 показан пример формата сетевого-адреса Х.121 без DSP. Нет необходимости в DSP, когда IDP достаточен для идентификации требуемого (ых) ПДСУ. Может быть, что этот сетевой-адрес идентифицировал ПДСУ в системе, присоединенной непосредственно к подсети, которая использует номер Х.121.

image020.jpg

"Рисунок 16 - Пример формата сетевого-адреса X. 121"

Одним из примеров сетевого-адреса, основанного на структуре, показанной на рисунке 16, может быть:

36 идентифицирует IDI X.121 (с десятичным DSP, если присутствует);

23420123456789 является адресом Х.121.

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Таблица ДА. 1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

ИСО 3166:1988

MOD

ГОСТ 7.67-2003 (ИСО 3166-1:1997) Система стандартов по информации, библиотечному и издательскому делу. "Коды названий стран"

ИСО 6523:1984

-

*

ИСО 7498:1984

IDT

ГОСТ Р ИСО/МЭК 7498-1-99 "Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель"

ИСО 7498.3:1989

IDT

ГОСТ Р ИСО 7498-3-97 "Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация"

ИСО 8348/Доп. 2:1988

IDT

ГОСТ Р ИСО 8348/Доп.2-93 "Информационная технология. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне"

ИСО/МЭК 8824:1990

IDT

ГОСТ Р ИСО/МЭК 8824-1-2001 "Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации"

ИСО/МЭК ТО 9577:1990

IDT

*

ИСО/МЭК 9594:1990

-

*

ИСО/МЭК 9834-1:1993

IDT

ГОСТ Р ИСО/МЭК 9834-1-2009 "Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных регистрации ВОС. Часть 1. Общие процедуры и верхние дуги дерева идентификатора объекта АСН.1"

ИСО/МЭК 9834-6:1993

IDT

ГОСТ Р ИСО/МЭК 9834-6-2009 "Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных регистрации ВОС. Часть 6. Регистрация прикладных процессов и прикладных категорий"

ИСО/МЭК 10021-1:1990

IDT

ГОСТ Р ИСО/МЭК 10021-1-98 "Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 1. Общее описание системы и службы"

* Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов.

Примечание - В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов:

- IDT - идентичные стандарты;

- MOD - модифицированные стандарты.

Возврат к списку
(Нет голосов)

Комментарии (0)


Чтобы оставить комментарий вам необходимо авторизоваться
Самые популярные документы
Новости
Все новости