ГОСТ Р ИСО/МЭК МФС 10609-10-98

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ФУНКЦИОНАЛЬНЫЙ СТАНДАРТ

ПРОФИЛИ ТВ, ТС, TD И ТЕ. УСЛУГИ ТРАНСПОРТНОГО УРОВНЯ В РЕЖИМЕ С УСТАНОВЛЕНИЕМ СОЕДИНЕНИЯ С ИСПОЛЬЗОВАНИЕМ УСЛУГ СЕТЕВОГО УРОВНЯ В РЕЖИМЕ С УСТАНОВЛЕНИЕМ

СОЕДИНЕНИЯ

Часть 10. ТРЕБОВАНИЯ, ЗАВИСИМЫЕ ОТ ПОДСЕТИ «ЛОКАЛЬНАЯ ВЫЧИСЛИТЕЛЬНАЯ СЕТЬ» И НЕЗАВИСИМЫЕ

ОТ ФИЗИЧЕСКОЙ СРЕДЫ

Издание официальное

ГОССТАНДАРТ РОССИИ Москва

ГОСТ Р ИСО/МЭК МФС 10609-10-98

Предисловие

1    РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного комитета Российской Федерации по связи и информатизации

ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 14 июля 1998 г. № 293

3    Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК МФС 10609-10—94 «Информационная технология. Международный функциональный стандарт. Профили ТВ, ТС, TD и ТЕ. Услуги транспортного уровня в режиме с установлением соединения с использованием услуг сетевого уровня в режиме с установлением соединения. Часть 10. Требования, зависимые от подсети «локальная вычислительная сеть» и независимые от физической среды»

4    ВВЕДЕН ВПЕРВЫЕ

© ИПК Издательство стандартов, 1998

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

II

ГОСТ Р ИСО/МЭК МФС 10609-10-98

Таким образом, например, статус «оо» должен означать обязательное обеспечение возможности, указанной в форме ЗСРП, и обязательность ее использования в применимых случаях.

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

А.2.4 Идентификация позиций формы ЗСРП

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

А.З СТЗФС для ГОСТ Р 34.950

Соответствующая форма ЗСРП базового стандарта приведена в приложении В к ИСО 8208/Изм.З. Настоящий стандарт налагает на нее следующие ограничения:

С.5 Общие характеристики ООД
Позиция базового	Описание	Ограничение
стандарта
Вс	Служба виртуальных соединений	о
ХХД/8	Операции ООД/АКД (1988)	3
ХХД/4	Операции ООД/АКД (1984)	3
ХХД/0	Операции ООД/АКД (1980)	3

С.6.4.1 Установление соединения
Позиция базового	Описание	Ограничение
стандарта
В1с	Запрос небыстрой выборки	н/р
В 2а	Приемлемость быстрой выборки	о
В 2с	Приемлемость небыстрой выборки	н/р

С.6.4.2 Освобождение соединения
Позиция базового	Описание	Ограничение
стандарта
02а	Освобождение соединения для прерывания ВС	о
02Ь	Освобождение соединения для отклонения ВС	о
02с	Инициируемое освобождение установленного ВС	о

С.6.5 Сброс логических каналов
Позиция базового	Описание	Ограничение
стандарта
СБо	Сброс со стороны ответчика	о

С.6.8.1 Передача данных
Позиция базового	Описание	Ограничение
стандарта
ПдД	Передача пакетов ДАННЫЕ	о
ПОПд	Поворот окна на передаче	о
ПдОД	Передача бита О = 0 в пакете ДАННЫЕ	о

7

ПРИЛОЖЕНИЕ В (обязательное)

ПРЕДПОЛАГАЕМАЯ ФОРМА ЗСРП БАЗОВЫХ СТАНДАРТОВ ДЛЯ УПРАВЛЕНИЯ ЛОГИЧЕСКИМ ЗВЕНОМ ПО ГОСТ 28907

В Л Введение

Поставщик реализации протокола, заявляющий о ее соответствии ГОСТ 28907 и изменениям 1—4 к ИСО 8802-2, должен заполнить приведенную ниже форму заявки о соответствии реализации протоколу (ЗСРП).

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

-    разработчиком протокола в качестве проверочного списка с целью уменьшить риск ошибиться в оценке соответствия стандарту из-за возможного недосмотра;

-    поставщиком и покупателем или потенциальным покупателем реализации в виде подробного описания ее возможностей, которое изложено на общевоспринимаемой основе, предусмотренной стандартной формой ЗСРП;

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

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

В.2 Сокращения и специальные символы

В.2.1 Символы    состояний:

О    —    обязательный;

Ф    —    факультативный;

Ф, <п>    —    факультативный,    но с обязательным обеспечением, по меньшей мере, одной из

групп факультативных возможностей, имеющих один и тот же номер п;

3    —    запрещенный;

<пред>:    —    условный символ, включающий в себя идентификацию предиката (см. В.3.3) и относя

щийся к конкретной позиции;

<пред>::    —    условный символ, включающий в себя идентификацию предиката (см. В.3.3) и относя

щийся к таблице или группе таблиц;

<позиция>: — условный символ, статус зависит от обеспечения, указанного для данной позиции (см. В.3.4).

В.2.2 Общие сокращения Н/И    — не используется;

ЗСРП    — заявка о соответствии реализации протоколу.

В.2.3 Указатели позиции

Ниже приведен перечень указателей позиций, используемых в форме ЗСРП: Основные возможности:

КЛС    Класс обеспечиваемого протокола УЛЗ

ЛОМ    Логический объект определения маршрута

УЛЗ, тип 1

НИ    ПБД НИ

ИДС    ПБД ИДС

ТСТ    ПБД ТЕСТ

НИПд    Параметры    в передаваемых ПБД

ИДПд    Параметры    в передаваемых ПБД

ТСПд    Параметры    в передаваемых ПБД

НИПр    Параметры    в принимаемых ПБД

ИДПр    Параметры    в принимаемых ПБД

ТСПр    Параметры    в принимаемых ПБД

ГОСТ Р ИСО/МЭК МФС 10609-10-98

УРС ПБД УРРАС РЗД ПБД РЗД нп ПБД НП ФРЗ ПБД ФРЗД НРК ПБД НПРК ППд Параметры в передаваемых ПБД ППм Параметры в принимаемых ПБД опп Процедуры протокола ПАП Параметры протокола ПРЧ Прочие возможности протокола УЛЗ, тип 3 ПпК Командные ПБД ПДп ПОК ПБД ПДО КМД ПОО ПБД ПДО ОТВ П1К ПБД ПД1 КМД пю ПБД ПД1_ОТВ ПОПд Параметры в передаваемых ПБД ШПд Параметры в передаваемых ПБД ПОПм Параметры в принимаемых ПБД ШПм Параметры в принимаемых ПБД ОПП Процедуры протокола ППР Параметры протокола ПРЧ Прочие возможности протокола

пдо ПД1 пдо ПД1

В.З Инструкции по заполнению формы ЗСРП

В.3.1 Общая структура формы ЗСРП

Первая часть формы ЗСРП «Идентификация реализации и сводные сведения о протоколе» должна быть заполнена, как указано, информацией, необходимой для полной идентификации как поставщика, так и реализации.

Основная часть формы ЗСРП представляет собой вопросник фиксированного формата, имеющий шесть основных подразделов; последние могут быть разделены на более мелкие подразделы, каждый из которых содержит множество отдельных позиций. Ответы на вопросы каждой позиции, которые записывают в правой колонке, представляют собой либо простую пометку для указания ограниченного выбора (обычно «Да» или «Нет»), либо указание конкретного значения либо набора, либо диапазона значений.

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

Каждая позиция идентифицируется ее обозначением в первой колонке; во второй колонке содержится вопрос, на который требуется ответить; в третьей колонке содержится ссылка (или ссылки) на материал, который определяет позицию в ГОСТ 28907 и в изменениях 1—5 ИСО 8802-2. В остальных колонках зарегистрирован статус позиции: является ли обеспечение обязательным, факультативным или условным, — и предусмотрено место для записи ответов; см. также В.3.4.

Поставщик может также записать или потребовать записи другой информации, классифицируемой как «дополнительная информация» или «особая информация». Каждый из этих видов информации при ее наличии должен быть представлен в последующих подразделах позиций, отмеченных как Д <i> или О <i> соответственно для ссылок на нее, где <i> — любая недвусмысленная идентификация позиции (например, обычный номер); никаких других ограничений на ее формат и представление не налагается.

Заполненная форма ЗСРП, включая любую дополнительную информацию и особую информацию, представляет собой «Заявку о соответствии реализации протоколу» для соответствующей реализации.

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

В.3.2 Дополнительная информация

Позиции раздела ЗСРП «Дополнительная информация» позволяют поставщику представить дополнительную информацию, которая поможет в интерпретации ЗСРП. Не ставится целью и не предполагается обеспечить большой объем такой информации, и вся ЗСРП может рассматриваться без любой такой информации. Примерами дополнительной информации могут служить описания способов установки реализации (одной) для работы в различных условиях и в разных конфигурациях либо краткое обоснование, возможно, специфических требований применения, причин исключения тех возможностей, которые, хотя и являются факультативными, но, тем не менее, повсеместно представлены в реализациях протокола ГОСТ 28907.

Ссылки на позиции раздела «Дополнительная информация» могут быть даны вслед за любым ответом в вопроснике и могут быть включены в позиции раздела «Особая информация».

В.3.3 Особая информация

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

11

Электронная версия

колонке «Обеспечение» он не найдет никакого заготовленного ответа на этот случай; вместо этого поставщик должен записать в эту колонку отсутствующий ответ вместе со ссылкой О <i> на позицию особой информации и должен дать соответствующее обоснование позиции особой информации.

Реализация, для которой необходима такая особая позиция, не соответствует ГОСТ 28907 и изменениям 1-5 ИСО 8802-2.

Примечание — Причиной описанной выше ситуации может оказаться извещение об ошибке в ГОСТ 28907 или в изменениях 1—5 ИСО 8802-2; ожидаемое исправление должно изменить требование, которому реализация не соответствует.

В.3.4 Условные состояния

В.3.4.1 Условные позиции

Форма ЗСРП содержит большое число условных позиций. Это такие позиции, в которых применимый статус — обязательный, факультативный или запрещенный — зависит от обеспечения некоторых других позиций.

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

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

Условный символ имеет форму «<пред><х>», где «<пред>» означает предикат согласно В.3.4.2, а «<х>» — один из символов статуса О, Ф, Ф.<п> или И.

Если предикат в любой строке условной позиции имеет значение «истинно» (см. В.3.4.2), то условная позиция применима и ее статус соответствует символу статуса, следующему за предикатом; колонка ответов должна быть заполнена необычным образом. Если предикат имеет значение «ложно», то в соответствующей строке должен быть указан ответ «не используется» (Н/И). (Каждая строка в многострочной условной позиции должна быть заполнена: максимум одна строка потребует ответа, отличного от Н/И.)

Условный символ вида «<пред><х>», где «<пред>» означает предикат согласно В.3.4.2, может предшествовать таблице или группе таблиц в разделе или подразделе. Если значение предиката — «истинно», в таблице или группе таблиц должен быть указан ответ. В противном случае таблица или группа таблиц должны быть опущены.

В.3.4.2 Предикаты

Предикатом считается одно из следующих:

a)    ссылка в позиции на какую-либо позицию в форме ЗСРП: предикат имеет значение «истинно», если позиция указана как обеспечиваемая, и «ложно» в противном случае;

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

c)    символ логического отрицания «—», предшествующий ссылке в позиции или имени предиката: предикат имеет значение «истинно», если предикат, сформированный в отсутствие символа «—», имеет значение «ложно», и наоборот.

Определение имени предиката представляет собой одно из следующих:

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

й) соотношение, содержащее оператор сравнения (=, < и т.п.), где по меньшей мере один из операндов является ссылкой в позиции, имеющей в качестве ответа числовое значение; такой предикат имеет значение «истинно», если соотношение выполняется, когда каждая ссылка в позиции заменяется значением в колонке «Обеспечение» в качестве ответа на указанную позицию или

Ш) булево выражение, составленное из простых предикатов, как в подпунктах i) и й), с обычным использованием булевых операторов И, ИЛИ и НЕ и скобок; значение такого предиката оценивается как «истинно», если булево выражение оценивается как истинное при интерпретации ссылки на позицию, как указано выше.

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

В.3.5 Идентификация требований

Информация в форме ЗСРП не заменяет и не добавляет никаких требований к соответствию, изложенных в основной части ГОСТ 28907 и в изменениях 1, 2, 4 и 5 ИСО 8802-2.

12

Электронная версия

В.4 Форма ЗСРП. Идентификация

В.4.1 Идентификация реализации

Поставщик
Пункт контактов для вопросов о ЗСРП
Имя (имена) и версия (и) реализации
Прочая информация, необходимая для полной идентификации, например имя (имена) и версия (и) машин и операционных систем, имена систем
Примечания 1    Для всех реализаций требуются только три первые позиции; «прочая информация» может быть указана соответствующим образом при выполнении требований к полной идентификации. 2    Термины «имя» и «версия» следует интерпретировать в соответствии с терминологией поставщика (например, тип, серия, модель).

В.4.2 Сводные сведения о протоколе

Идентификация спецификации протокола ГОСТ 28907 ИСО 8802-2/Изм.1 ИСО 8802-2/Изм.2 ИСО 8802-2/Изм.4 ИСО 8802-2/Изм.5 Идентификация изменений и поправок к данной форме ЗСРП, ГОСТ 28907 которая заполнена как часть дан- Изм. : Попр. : ной ЗСРП Изм. : Попр. : Изм. : Попр. : Требуются ли какие-либо особые позиции (В.3.3)? (см. Нет [ ] Да [ ]) (Ответ «Да» означает, что данная реализация не соответствует ГОСТ 28907 и изменениям 1, 2, 4 и 5 ИСО 8802-2)

Дата заявки

В.5 Основные возможности

Позиция Возможности протокола Ссылки Статус Обеспечение *КЛС1а Обеспечивается ли класс I УЛЗ? 4.2 Ф.1 Да ] Нет [ ] КЛС1Ь Обеспечиваются ли процедуры УЛЗ типа 1? 4.2 КЛС1а:0 Н/И ] Да [ *КЛС2а Обеспечивается ли класс II УЛЗ? 4.2 Ф.1 Да ] Нет [ ] КЛС2Ь Обеспечиваются ли процедуры УЛЗ типов 1 и 2? 4.2 КЛС2а:0 н/и ] Да [ *КЛСЗа Обеспечивается ли класс III УЛЗ? 4.2 Ф.1 Да ] Нет [ ] КЛСЗЬ Обеспечиваются ли процедуры УЛЗ типов 1 и 3? 4.2 КЛСЗа:0 Н/И ] Да [ *КЛС4а Обеспечивается ли класс IV УЛЗ? 4.2 Ф.1 Да ] Нет [ ] КЛС4Ь Обеспечиваются ли процедуры УЛЗ типов 1, 2 и 3? 4.2 КЛС4а:0 н/и ] Да [ *ОМР Обеспечивается ли определение маршрута? 10 Ф Да ] Нет [ ]

В.6 Операции УЛЗ типа 1. Режим без установления соединения и без подтверждений

KJICla ИЛИ КЛС2а ИЛИ КЛСЗа ИЛИ КЛС4а::

Все таблицы в разделе В.6 должны быть заполнены, если перечисленные выше предикаты оценены как

«истинные».

В.6.1 УЛЗ, тип 1. Обеспечиваемые типы ПБД

Позиция	Возможности протокола. Обеспечиваемые типы ПБД	Ссылки	Статус	Обеспечение
НИ/1 НИ/2 *идс/з ИДС/4 ИДС/5 ИДС/6 *ТЕС/7 ТЕС/8 ТЕС/9 ТЕС/10	НИ_КМД, обеспечивается при передаче НИ_КМД, обеспечивается при приеме ИДС_КМД, обеспечивается при передаче ИДС_КМД, обеспечивается при приеме ИДС_ОТВ, обеспечивается при передаче ИДС_ОТВ, обеспечивается при приеме ТЕСТ_КМД, обеспечивается при передаче ТЕСТ_КМД, обеспечивается при приеме ТЕСТ_ОТВ, обеспечивается при передаче ТЕСТ_ОТВ, обеспечивается при приеме	6.1,    6.5.1 6.1,    6.5.1 6.6 6.6 6.6 6.6 6.7 6.7 6.7 6.7	О О ф О О идс/зю ф О О ТЕСТ/7:0	Да [ ] Да [ ] Да [ ] Нет [ ] Да [ ] Да [ ] Н/И[] Да [ ] Да [ ] Нет [ ] Да [ ] Да [ ] Н/И[] Да [ ]

В.6.2 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при передаче

Позиция Возможности протокола. Обеспечиваемые параметры при передаче Ссылки Статус Обеспечение НИПд/11 НИ КМД - адрес ПДУП 6.2 О Да ] НИПд/12 НИ КМД-ПДУО 6.2 О Да ] НИПд/13 НИ КМД - бит 3 = 0 6.3 О Да ] НИПд/14 НИ_КМД — информация 3.3 ф Да ] Нет [ ] ИДПд/15 ИДС КМД - адрес ПДУП 6.2, 6.6 ИДС/3:0 Н/И ] Да [ Нет [ ] ИДПд/16 ИДС КМД - адрес ПДУО 6.2, 6.6 ИДС/3:0 Н/И ] Да [ Нет [ ] ИДПд/17 ИДС КМД - бит 3 = 1 6.3 ИДС/3:Ф.2 Н/И ] Да [ Нет [ ] ИДПд/18 ИДС КМД - бит 3 = 0 6.3 ИДС/3:Ф.2 Н/И ] Да [ Нет [ ] ИДПд/19 ИДС_КМД — информация 5.4.1.1.2, 6.6 ИДС/3:0 Н/И ] Да [ Нет [ ] ИДПд/20 ИДС ОТВ - адрес ПДУП 6.2, 6.6 О Да ] ИДПд/21 ИДС ОТВ - адрес ПДУО 6.2, 6.6 О Да ] ИДПд/22 ИДС ОТВ — бит И = бит 3 6.3 О Да ] ИДПд/23 ИДС_ОТВ — информация 5.4.1.2.1, 6.6 О Да ] ТСПд/24 ТЕСТ КМД - адрес ПДУП 6.2 ТСПд/7:0 Н/И ] Да [ Нет [ ] ТСПд/25 ТЕСТ КМД - адрес ПДУО 6.2 ТСПд/7:0 Н/И ] Да [ Нет [ ] ТСПд/26 ТЕСТ КМД - бит 3 = 1 6.3 ТСПд/7:Ф.З Н/И ] Да [ Нет [ ] ТСПд/27 ТЕСТ КМД - бит 3 = 0 6.3 ТСПд/7:Ф.З Н/И ] Да [ Нет [ ] ТСПд/28 ТЕСТ_КМД — информация 5.4.1.1.3, 6.7 ТСПд/7:0 Н/И ] Да [ Нет [ ] ТСПд/29 ТЕСТ ОТВ - адрес ПДУП 6.2 О Да ] ТСПд/30 ТЕСТ ОТВ - адрес ПДУО 6.2 О Да ] ТСПд/31 ТЕСТ ОТВ — бит П = бит 3 6.3 О Да ] ТСПд/32 ТЕСТ_ОТВ — информация 5.4.1.2.2, 6.7 О Да ]

В.6.3 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при приеме

Позиция Возможности протокола. Обеспечиваемые параметры при приеме Ссылки Статус Обеспечение НИПм/33 НИ КМД - адрес ПДУП 6.2 О Да [ ] НИПм/34 НИ КМД-ПДУО 6.2 О Да [ ] НИПм/35 НИ КМД - бит 3 = 0 6.3 О Да [ ] НИПм/36 НИ_КМД — информация 6.3 ф Да [ ] Нет [ ]

Окончание В. 6.3

Позиция Возможности протокола. Обеспечиваемые параметры при приеме Ссылки Статус Обеспечение ИДПм/37 ИДС КМД - адрес ПДУП 6.2, 6.6 О Да [ ] ИДПм/38 ИДС КМД - адрес ПДУО 6.2, 6.6 О Да [ ] ИДПм/39 ИДС КМД - бит 3 = 1 6.3 О Да [ ] ИДПм/40 ИДС КМД - бит 3 = 0 6.3 О Да [ ] ИДПм/41 ИДС_КМД — информация 5.4.1.1.2, 6.6 О Да [ ] ИДПм/42 ИДС ОТВ - адрес ПДУП 6.2, 6.6 О Да [ ] ИДПм/43 ИДС ОТВ - адрес ПДУО 6.2, 6.6 О Да [ ] ИДПм/44 ИДС ОТВ — бит И = бит 3 6.3 О Да [ ] ИДПм/45 ИДС_ОТВ — информация 5.4.1.2.1, 6.6 О Да [ ] ТСПм/46 ТЕСТ КМД - адрес ПДУП 6.2 О Да [ ] ТСПм/47 ТЕСТ КМД - адрес ПДУО 6.2 О Да [ ] ТСПм/48 ТЕСТ КМД - бит 3 = 1 6.3 О Да [ ] ТСПм/49 ТЕСТ КМД - бит 3 = 0 6.3 О Да [ ] ТСПм/50 ТЕСТ_КМД — информация 5.4.1.1.3, 6.7 О Да [ ] ТСПм/51 ТЕСТ ОТВ - адрес ПДУП 6.2 О Да [ ] ТСПм/52 ТЕСТ ОТВ - адрес ПДУО 6.2 О Да [ ] ТСПм/53 ТЕСТ ОТВ — бит П = бит 3 6.3 О Да [ ] ТСПм/54 ТЕСТ_ОТВ — информация 5.4.1.2.2, 6.7 ТСПд/28:0 Н/И[] Да [ ]

В.6.4 УЛЗ, тип 1. Прочие возможности протокола

Позиция Прочие функциональные возможности протокола Ссылки Статус Обеспечение ПРЧ/55 Все ли передаваемые ПБД содержат целое число октетов? 3.3 О Да [ ] Если следующие ПБД получены из подуровня УДС, они рассматриваются как недействительные и игнорируются? ПРЧ/56 - не содержат целого числа октетов 3.3.4 О Да [ ] ПРЧ/57 - их длина меньше трех октетов 3.3.4 О Да [ ] Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУП» ПБД НИ? ПРЧ/58 - индивидуальный адрес 5.4.1.1.1 Ф.4 Да [ ] Нет [ ] ПРЧ/59 - групповой адрес 5.4.1.1.1 Ф.4 Да [ ] Нет [ ] ПРЧ/60 - глобальный адрес 5.4.1.1.1 Ф.4 Да [ ] Нет [ ] ПРЧ/61 - нулевой адрес 5.4.1.1.1 Ф.4 Да [ ] Нет [ ] ПРЧ/62 Является ли адрес в поле «адрес ПДУО» ПБД НИ индивидуальным адресом отправителя? 5.4.1.1.1 О Да [ ] ПРЧ/63 Все ли ПБД НИ передаются в виде ПБД НИ КМД? 6.5.1 О Да [ ] ПРЧ/64 Все ли ПБД НИ КМД передаются с 6.5.1 О Да [ ] битом 3=1? ПРЧ/65 Если получен ПБД НИ_ОТВ, аннулируется ли кадр? 6.5.2 О Да [ ] Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУП» ПБД ИДС КМД? ПРЧ/66 - индивидуальный адрес 5.4.1.1.2 ИДС/3:Ф.6 Н/И[] Да [ Нет [ ] ПРЧ/67 - групповой адрес 5.4.1.1.2 ИДС/3:Ф.6 Н/И[] Да [ Нет [ ]

15

Окончание В. 6.4

Позиция Прочие функциональные возможности протокола Ссылки Статус Обеспечение ПРЧ/68 - глобальный адрес 5.4.1.1.2 ИДС/3:Ф.6 Н/И [ ] Да [ ] Нет [ ] ПРЧ/69 - нулевой адрес 5.4.1.1.2 ИДС/3:Ф.6 Н/И [ ] Да [ ] Нет [ ] ПРЧ/70 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУО» ПБД ИДС_КМД? - индивидуальный адрес 5.4.1.1.2 ИДС/3:Ф.6 Н/И [ ] Да [ ] Нет [ ] ПРЧ/71 - нулевой адрес 5.4.1.1.2 ИДС/3:Ф.6 Н/И [ ] Да [ ] Нет [ ] ПРЧ/72 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУП» ПБД ИДС_ОТВ? - индивидуальный адрес 5.4.1.2.1 О Да [ ] ПРЧ/73 - нулевой адрес 5.4.1.2.1 О Да [ ] ПРЧ/74 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУО» ПБД ИДС_ОТВ? - индивидуальный адрес 5.4.1.2.1 О Да [ ] ПРЧ/75 - нулевой адрес 5.4.1.2.1 О Да [ ] ПРЧ/76 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУП» ПБД ТЕСТ_КМД? - индивидуальный адрес 5.4.1.1.3 ТСПд/7:Ф.7 Н/И [ ] Да [ ] Нет [ ] ПРЧ/77 - групповой адрес 5.4.1.1.3 ТСПд/7:Ф.7 Н/И [ ] Да [ ] Нет [ ] ПРЧ/78 - глобальный адрес 5.4.1.1.3 ТСПд/7:Ф.7 Н/И [ ] Да [ ] Нет [ ] ПРЧ/79 - нулевой адрес 5.4.1.1.3 ТСПд/7:Ф.7 Н/И [ ] Да [ ] Нет [ ] ПРЧ/80 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУО» ПБД ТЕСТ_КМД? - индивидуальный адрес 5.4.1.1.3 ТСПд/7:Ф.8 Н/И [ ] Да [ ] Нет [ ] ПРЧ/81 - нулевой адрес 5.4.1.1.3 ТСПд/7:Ф.8 Н/И [ ] Да [ ] Нет [ ] ПРЧ/82 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУП» ПБД ТЕСТ_ОТВ? - индивидуальный адрес 5.4.1.2.2 О Да [ ] ПРЧ/83 - нулевой адрес 5.4.1.2.2 О Да [ ] ПРЧ/84 Какие из перечисленных ниже адресов обеспечиваются в поле «адрес ПДУО» ПБД ТЕСТ_ОТВ? - индивидуальный адрес 5.4.1.2.2 О Да [ ] ПРЧ/85 - нулевой адрес 5.4.1.2.2 О Да [ ] *ПРЧ/86 Обеспечивается ли проверка дублиро- 6.9.2 Ф Да [ ] Нет [ ] ПРЧ/87 вания адреса? - Обеспечивается ли функция ТАЙМ- 6.9.2 ПРЧ/86:0 Н/И[] Да [ ] ПРЧ/88 ПРЧ/89 АУТ_ПДТ? -    Диапазон ТАЙМ-АУТ_ПДТ (с) -    Обеспечивается ли функция СЧЕТ 6.9.2 ПРЧ/88:0 Минимальное значение = Максимальное значение = Н/И[] Да [ ] ПРЧ/90 ПРЧ/91 ПОВТОРЕНИЙ? -    Диапазон СЧЕТ_ПОВТОРЕНИЙ (с) -    Обеспечивается ли функция СЧЕТ 6.9.2 ПРЧ/88:0 Минимальное значение = Максимальное значение = Да [ ] ИДС_ОТВ?

ГОСТ Р ИСО/МЭК МФС 10609-10-98

Содержание

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

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

3    Определения............................................................. 2

4    Сокращения............................................................. 2

5    Требования.............................................................. 2

5.1    Введение............................................................. 2

5.2    Требования статического соответствия...................................... 2

5.3    Требования динамического соответствия.................................... 3

Приложение А Список требований к заявке о соответствии реализации функциональному

стандарту.................................................... 6

А.1 Введение............................................................ 6

А. 2 Нотация и соглашения.................................................. 6

А.З СТЗФС для ГОСТ Р 34.950 .............................................. 7

A. 4 СТЗФС для ГОСТ 28907 ................................................ 9

Приложение В Предполагаемая форма ЗСРП базовых стандартов для управления логическим

звеном по ГОСТ 28907 .......................................... 10

B. 1 Введение............................................................ 10

В.2 Сокращения и специальные символы....................................... 10

В.З Инструкции по заполнению формы ЗСРП................................... 11

В.4 Форма ЗСРП. Идентификация............................................ 13

В.5 Основные возможности................................................. 13

В.6 Операции УЛЗ типа 1. Режим без установления соединения и без подтверждений.....14

В.7 Операции УЛЗ типа 2. Режим с установлением соединения...................... 17

В.8 Операции УЛЗ типа 3. Режим без установления соединения с подтверждениями......20

B. 9 Логический объект определения маршрута...................................24

Приложение С Рекомендации.................................................25

C. 1 Введение............................................................25

С.2 Рекомендации ГОСТ Р 34.950 ............................................ 25

С.З Рекомендации ГОСТ 28907 .............................................. 25

Приложение D Библиография.................................................27

III

В.7 Операции УЛЗ типа 2. Режим с установлением соединения

КЛС2а ИЛИ КЛС4а::

Все таблицы в разделе В.7 должны быть заполнены, если перечисленные выше предикаты оценены как «истинные».

В.7.1 УЛЗ, тип 2. Обеспечиваемые типы ПБД

Позиция	Возможности протокола. Обеспечиваемые типы ПБД	Ссылки	Статус	Обеспечение
*ИП/92а	ПБД И, обеспечивается при передаче	7.4.2	Ф	Да [ ] Нет [ ]
*ИК/92Ь	И КМД, обеспечивается при передаче	Таблица 7-1	ИП/92а:Ф	Н/И [ ] Да [ ] Нет [ ]
ИК/93	И_КМД, обеспечивается при приеме	То же	О	Да [ ]
ИК/94	И ОТВ, обеспечивается при передаче	»	ИП/92а:0	Н/И[] Да [ ]
ИК/95	И_ОТВ, обеспечивается при приеме	»	О	Да [ ]
ГПК/96	ГПР КМД, обеспечивается при передаче	»	О	Да [ ]
ГПК/97	ГПР_КМД, обеспечивается при приеме	»	О	Да [ ]
ГПО/98	ГПР ОТВ, обеспечивается при передаче	»	О	Да [ ]
ГПО/99	ГПР_ОТВ, обеспечивается при приеме	»	О	Да [ ]
НГК/100	НГПР КМД, обеспечивается при передаче	»	О	Да [ ]
НГК/101	НГПР_КМД, обеспечивается при приеме	»	О	Да [ ]
НГО/102	НГПР ОТВ, обеспечивается при передаче	»	О	Да [ ]
НГО/ЮЗ	НГПР_ОТВ, обеспечивается при приеме	»	О	Да [ ]
*НПК/104	НПР КМД, обеспечивается при передаче	»	ф	Да [ ] Нет [ ]
НПК/105	НПР_КМД, обеспечивается при приеме	»	О	Да [ ]
НПО/Ю6	НПР ОТВ, обеспечивается при передаче	»	О	Да [ ]
НПО/107	НПР_ОТВ, обеспечивается при приеме	»	О	Да [ ]
УРК/108	УРРАС КМД, обеспечивается при передаче	»	О	Да [ ]
УРК/109	УРРАС_КМД, обеспечивается при приеме	»	О	Да [ ]
РЗК/110	РЗД КМД, обеспечивается при передаче	»	О	Да [ ]
РЗК/111	РЗД_КМД, обеспечивается при приеме	»	О	Да [ ]
НПО/112	НП ОТВ, обеспечивается при передаче	»	О	Да [ ]
НПО/113	НП_ОТВ, обеспечивается при приеме	»	О	Да [ ]
ФРО/114	ФРЗД ОТВ, обеспечивается при передаче	»	О	Да [ ]
ФРО/115	ФРЗД_ОТВ, обеспечивается при приеме	»	О	Да [ ]
НКО/116	НПРК ОТВ, обеспечивается при передаче	»	О	Да [ ]
НКО/117	НПРК_ОТВ, обеспечивается при приеме	»	О	Да [ ]

В.7.2 УЛЗ, тип 2. Обеспечиваемые параметры в ПБД

Позиция Возможности протокола. Обеспечиваемые параметры при передаче Ссылки Статус Обеспечение ППд/118а ППд/118Ь ППд/119 Содержат ли следующие ПБД адрес ПДУП, адрес ПДУО и поле управления, как определено в указанных в «Ссылках» разделах? -    И КМД -    И ОТВ -    НПР КМД 3.2,    3.3, 5.4 3.2,    3.3, 5.4 3.2,    3.3, 5.4 ИК/92Ь:0 ИП/92Ь:0 НПР/Ю4:0 Н/И[] Да [ ] Н/И [ ] Да [ ] Н/И[] Да [ ]

Электронная версия

Введение

Настоящий стандарт определен в контексте функциональной стандартизации в соответствии с принципами, определенными в ГОСТ Р ИСО/МЭК ТО 10000-1 и ГОСТ Р ИСО/МЭК ТО 10000-2.

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

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

ГОСТ Р ИСО/МЭК МФС 10609 состоит из нескольких частей, из которых настоящий стандарт является частью 10. Части 1—4 определяют независимые от особенностей подсети требования к каждой группе транспортных профилей ТВ, ТС, TD и ТЕ соответственно. В других частях определены зависимые от подсети и физической среды требования к профилям. Кроме того, для каждого отдельного профиля предусмотрена отдельная часть ФС, в которой установлены конкретные требования к данному профилю со ссылками на соответствующий материал из других частей, определяющих зависимые и независимые от подсети требования.

Настоящий стандарт содержит четыре приложения. Приложения А и В являются обязательными, приложения С и D — информационными.

IV

ГОСТ Р ИСО/МЭК МФС 10609-10-98

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

Функциональный стандарт

ПРОФИЛИ ТВ, ТС, TD И ТЕ. УСЛУГИ ТРАНСПОРТНОГО УРОВНЯ В РЕЖИМЕ С УСТАНОВЛЕНИЕМ СОВДИНЕНИЯ С ИСПОЛЬЗОВАНИЕМ УСЛУГ СЕТЕВОГО УРОВНЯ В РЕЖИМЕ С УСТАНОВЛЕНИЕМ СОВДИНЕНИЯ

Часть 10. Требования, зависимые от подсети «Локальная вычислительная сеть»

и независимые от физической среды

Information technology. International standardized profiles ТВ, TC, TD and ТЕ. Connection-mode transport service

over connection-mode network service Part 10. LAN subnetwork-dependent, media-independent requirements

Дата введения 1999—01—01

1    ОБЛАСТЬ ПРИМЕНЕНИЯ

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

Настоящий стандарт определяет зависимые от типа подсети требования к оконечным системам, которые подсоединены к подсети «локальная вычислительная сеть» (ЛВС), работающей по протоколу управления логическим звеном (УЛЗ) типа 2 по ГОСТ 28907, безотносительно к типу физической среды.

2    НОРМАТИВНЫЕ ССЫЛКИ

Настоящий стандарт содержит ссылки на следующие стандарты:

ГОСТ 34.954-91 (ИСО 8878—87) Информационная технология. Взаимосвязь открытых систем. Использование протокола пакетного уровня Х.25 для обеспечения услуг сетевого уровня взаимосвязи открытых систем в режиме с установлением соединения

ГОСТ 28907-91 (ИСО 8802-2—89) Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных

ГОСТ Р 34.950-92 (ИСО 8208—87) Информационная технология. Взаимосвязь открытых систем. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных

ГОСТ Р ИСО/МЭК 8881—98 Информационная технология. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях

ГОСТ Р ИСО/МЭК ТО 10000-1—93 Информационная технология. Основы и таксономия функциональных стандартов. Часть 1. Основы

ГОСТ Р ИСО/МЭК ТО 10000-2—93 Информационная технология. Основы и таксономия функциональных стандартов. Часть 2. Таксономия профилей

ИСО/МЭК 8208—87/Изм.З—910 Информационная технология. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных. Дополнение 3. Аттестованные требования

ИСО/МЭК 8348—930 Системы обработки информации. Передача данных. Определение услуг сетевого уровня

ИСО 8802-2—89/Изм. 10 Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 1. Методы управления потоком для мостовых ЛВС

О Оригиналы стандартов и проектов ИСО/МЭК — во ВНИИКИ Госстандарта России.

Издание официальное

Электронная версия

ИСО 8802-2—89/Изм.2^|) Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 2. Услуги и протокол в режиме без установления соединений с подтверждением. Операции типа 3

ИСО 8802-2—89/Изм.ЗО Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 3. Требования к соответствию

ИСО 8802-2—89/Изм.40 Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 4. Редакционные изменения и технические поправки

ИСО 8802-2—89/Изм.50 Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 5. Маршрутизация со стороны отправителя в мостовых ЛВС, выполняемая оконечными системами

3    ОПРЕДЕЛЕНИЯ

Все термины, использованные в настоящем стандарте, определены в базовых стандартах, на которые даны ссылки (см. раздел 2).

4    СОКРАЩЕНИЯ

Сокращения, использованные в настоящем стандарте, определены в базовых стандартах, на которые даны ссылки (см. раздел 2).

5    ТРЕБОВАНИЯ

5.1    Введение

В данном разделе установлены зависимые от типа подсети и независимые от физической среды требования к операциям оконечной системы в случае подключения оконечной системы к ЛВС.

5.2    Требования статического соответствия

5.2.1    Общие требования

Реализация, претендующая на соответствие настоящей части настоящего ФС, должна:

a)    удовлетворять требованиям ГОСТ 34.954, приведенным в 5.2.2;

b)    удовлетворять требованиям ГОСТ Р 34.950, модифицированным в ГОСТ Р ИСО/МЭК 8881 в части операции типа 2 УЛЗ и приведенным в 5.2.3;

c)    удовлетворять требованиям ГОСТ 28907, приведенным в 5.2.4;

d)    реализовать все функциональные возможности, идентифицированные как требования в списке требований к заявке о соответствии реализации функциональному стандарту (ЗСРФС), приведенному в приложении А.

5.2.2    Требования ГОСТ 34.954

Реализация должна:

a)    удовлетворять требованиям к обеспечению услуг сетевого уровня ВОС, определенных в ГОСТ 34.954, за исключением услуг «подтверждение приема» (раздел 9), «передача срочных данных» (раздел 10) и приложения А;

b)    быть способной использовать адреса отправителя и получателя на сетевом уровне ВОС любого формата и с любыми значениями, определенными в ИСО/МЭК 8348.

5.2.3    Требования ГОСТ Р 34.950

5.2.3.1 Общие требования

Реализация должна:

a)    удовлетворять требованиям статического соответствия, установленным в разделе 17 ИСО 8208/Изм.З;

b)    реализовать службу виртуальных соединений;

c)    реализовать следующие возможности, определенные в таблице 37 ИСО 8208/Изм.З:

- устанавливать виртуальное соединение (ВС); инициировать исходящее ВС с последующим принятием или отклонением либо принимать входящее ВС и отвечать принятием, либо принимать входящее ВС и отвечать отклонением.

П римечание — Реализация может выполнять любую из перечисленных возможностей либо все эти возможности;

б Оригиналы стандартов и проектов ИСО/МЭК — во ВНИИКИ Госстандарта России.

ГОСТ Р ИСО/МЭК МФС 10609-10-98

-    прерывать попытки установления исходящего ВС путем освобождения соединения,

-    освобождать установленное ВС в роли как инициатора, так и ответчика,

-    сбрасывать логический канал в роли ответчика;

d)    реализовать следующие факультативные возможности, определенные в 21.1.2 ИСО 8208/Изм.З:

-    обеспечивать передачу данных пользователя в пакетах «установление соединения» при их приеме и передаче,

-    обеспечивать передачу пакетов ДАННЫЕ,

-    обеспечивать пакеты ДАННЫЕ с битом М, установленным в 1 при приеме,

-    передавать обновленную информацию поворота окна,

-    передавать пакеты ГПР;

e)    принимать входящие ВС как вызовы с быстрой выборкой;

f)    обеспечивать следующие факультативные возможности:

-    согласование класса пропускной способности,

-    быстрая выборка,

-    приемлемость быстрой выборки,

-    выбор и индикация транзитной задержки,

-    расширение адреса вызывающего,

-    расширение адреса вызываемого,

-    согласование класса минимальной пропускной способности,

-    согласование межконцевой транзитной задержки,

-    согласование срочных данных;

g)    удовлетворять требованиям к адресации на сетевом уровне, изложенным в 5.2.3.2.

5.2.3.2 Адреса на сетевом уровне

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

Адреса вызывающего, вызываемого и отвечающего ПДУСУ должны передаваться полностью с использованием предпочтительного двоичного кодирования в поле «параметр услуги» услуги «расширение адресов вызывающего и вызываемого».

Примечание — Если аттестуемая реализация получает пакет ВХОДЯЩИЙ ВЫЗОВ, который не соответствует настоящему стандарту, рекомендуется передать пакет ЗАПРОС ОСВОБОЖДЕНИЯ с кодом причины «по инициативе ООД» и кодом диагностики либо 235, либо 232.

5.2.4 Требования ГОСТ 28907

Реализация должна:

a)    реализовать функции, требуемые ГОСТ 28907 для обеспечения протокола «управление логическим звеном, тип 2»;

b)    для обеспечения взаимосвязи согласовывать значения N1 и тайм-аута подтверждения, общие для всей ЛВС;

c)    обеспечивать для тайм-аута подтверждения значение (5+1) с, при этом рекомендуется предусмотреть возможность изменения этого значения во время эксплуатации.

5.3 Требования динамического соответствия

5.3.1    Общие требования

Реализация, претендующая на соответствие настоящему стандарту, должна:

a)    удовлетворять требованиям ГОСТ Р 34.950, приведенным в 5.3.2;

b)    удовлетворять требованиям ГОСТ 28907, приведенным в 5.3.3;

c)    функционировать в соответствии с требованиями списка требований к ЗСРФС приложения А.

5.3.2    Требования ГОСТ Р 34.950

5.3.2.1 Общие требования

Реализация должна:

a)    выполнять обеспечиваемые в ГОСТ Р 34.950 функции в соответствии с процедурами протокола пакетного уровня Х.25 по ГОСТ Р 34.950, модифицированными в разделах 1 и 2 ГОСТ Р ИСО/МЭК 8881 для работы в функциональной среде ЛВС с использованием процедур УЛЗ типа 2;

b)    не использовать процедуры для работы протокола ГОСТ Р 34.950 с УЛЗ типа 1, приведенными в разделе 3 ГОСТ Р ИСО/МЭК 8881, поскольку они запрещены настоящим стандартом.

3

Электронная версия

Примечание — Это не относится к использованию протокола маршрутизации по ГОСТ Р ИСО/МЭК 10030, который может использовать процедуры УЛЗ типа 1 в функциональной среде ЛВС;

c)    удовлетворять требованиям к передаче срочных данных, определенным в 5.3.2.2;

d)    удовлетворять требованиям к подтверждению приема, определенным в 5.3.2.3;

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

а) игнорировать адреса вызываемого ООД и вызывающего ООД ППУ Х.25, поскольку настоящий стандарт не требует их использования.

5.3.2.2    Срочные данные

Услуга «срочные данные» не обеспечивается.

Функция «согласование срочных данных» (ССД) ППУ по ГОСТ Р 34.950 используется для согласования неиспользования услуги срочных данных.

i) Если логический объект сетевого уровня получает от удаленного пользователя УСУ примитив С-СОЕДИНЕНИЕ запрос, передаваемый пакет ЗАПРОС ВЫЗОВА может содержать функцию ССД, установленную в значение «неиспользование срочных данных» или как вариант функция ССД может быть опущена, что предполагает неиспользование этой возможности.

и) Если логический объект сетевого уровня получает от удаленного пользователя УСУ примитив С-СОЕДИНЕНИЕ ответ, передаваемый пакет ВЫЗОВ ПРИНЯТ может содержать функцию ССД, установленную в значение «неиспользование срочных данных» или как вариант функция ССД может быть опущена, что предполагает неиспользование этой возможности.

Примечания

1    Если реализация, действующая в соответствии с настоящим стандартом, в фазе передачи данных получает пакет ПРЕРЫВАНИЕ, рекомендуется, чтобы освобождение виртуального соединения проходило с использованием пакета ЗАПРОС ОСВОБОЖДЕНИЯ (и соответствующих процедур, определенных в ГОСТ Р 34.950), кода причины «по инициативе ООД» и кода диагностики 44.

2    При работе по некоторым другим профилям, например обеспечивающим терминальный доступ к Х.29, может потребоваться обеспечение однооктетных пакетов ПРЕРЫВАНИЕ.

5.3.2.3    Подтверждение приема

Услуга «подтверждение приема» не обеспечивается.

Бит 7 октета 1 (бит Д) в поле ИОФ пакета установления соединения ППУ Х.25—1984 используется для согласования неиспользования услуги подтверждения приема.

i) В пакетах ЗАПРОС ВЫЗОВА, передаваемых ООД, бит Д должен быть установлен в значение 0. и) Если логический объект сетевого уровня получает примитив С-СОЕДИНЕНИЕ ответ, параметр «выбор подтверждения приема» должен быть установлен в значение «неиспользование подтверждения приема» и, следовательно, бит 7 поля ИОФ пакета ВЫЗОВ ПРИНЯТ устанавливается в 0.

П р и м е ч а н и е — Если аттестуемая реализация получает пакет ДАННЫЕ с битом Д в значении 1, рекомендуется, чтобы освобождение виртуального соединения проходило с использованием пакета ЗАПРОС ОСВОБОЖДЕНИЯ (и соответствующих процедур, определенных в ГОСТ Р 34.950), кода причины «по инициативе ООД» и кода диагностики 255 или 166.

5.3.2.4    Метод определения диапазона логических каналов

Диапазон подлежащих использованию логических каналов (НВК, ВВК, НДК, ВДК, НИК и ВИК) определяется на основании локальных сведений. Если локальных сведений нет, то по умолчанию может быть использован только один двунаправленный логический канал (т.е. НДК и ВДК будут установлены в 1, а НВК, ВВК, НИК и ВИК — в 0). При наличии более одного канала старшее значение ВДК может быть согласовано с использованием услуги «динамическая регистрация услуги».

Если ООД способно инициировать пакет ЗАПРОС РЕГИСТРАЦИИ, то поле параметра регистрации должно устанавливаться следующим образом:

i) Параметры НВК, ВВК, НИК и ВИК должны устанавливаться в нуль, а НДК должен устанавливаться в значение 1. Значение поля параметра «общее число логических каналов» должно устанавливаться равным значению поля параметра ВДК.

и) Никакие другие факультативные возможности пользователя не должны идентифицироваться в пакете ЗАПРОС РЕГИСТРАЦИИ, и при их наличии они должны игнорироваться принимающей стороной.

Если ООД способно выдавать в ответ пакет ЗАПРОС РЕГИСТРАЦИИ, то в поле параметра ВДК должно указываться максимально допустимое число двунаправленных логических каналов между двумя ООД. Значение поля параметра ВДК должно быть меньше или равно значению, запрошенному в поле параметра ВДК пакета ЗАПРОС РЕГИСТРАЦИИ.

ГОСТ Р ИСО/МЭК МФС 10609-10-98

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

Примечание — Ответчик может проигнорировать пакет ЗАПРОС РЕГИСТРАЦИИ. Рекомендуется, однако, чтобы ООД было способно выдавать в ответ пакет ЗАПРОС РЕГИСТРАЦИИ, даже если оно обеспечивает только один двунаправленный логический канал. Это предотвратит ненужные задержки у инициатора при передаче пакета ЗАПРОС ВЫЗОВА. Такие задержки определяются инициатором по значениям тайм-аута Т28 и счетчика повторных передач R28.

5.3.3 Требования ГОСТ 28907

5.3.3.1 Общие требования

Реализация должна:

a)    выполнять обеспечиваемые ГОСТ 28907 функции в соответствии с процедурами, определенными в ГОСТ 28907;

b)    использовать фактическое значение адреса '111 1110'. В таблице 1 показано кодирование полей адресов ПДУП и ПДУО;

Таблица 1— Значения адреса УЛЗ

Поле адреса ПДУП Поле адреса ПДУО Формат поля И/Г И И И И И И И К/О 0 0 0 0 0 0 0 Значение 0 111111 0 К/О 111111 0 Примечание — И/Г — бит, определяющий тип адреса (индивидуальный/групповой); К/О — бит-идентификатор команды/ответа.

с) если должно использоваться значение к, не равное 7, согласовать значение, подлежащее использованию в кадрах ИДС в соответствии с излагаемыми в 5.3.3.2 процедурами.

5.3.3.2 Использование ИДС

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

Примечание — ГОСТ 28907 требует, чтобы на получение командного кадра ИДС выдавался ответный кадр ИДС.

Реализация, получающая командный кадр ИДС, адресованный по отдельному значению фактического адреса, определенному в 5.3.3.1 Ь), должна выдавать ответный кадр ИДС с использованием отдельного фактического адреса. Реализация должна действовать следующим образом:

i) Воспринимать размер окна приема инициатора, если его используемое значение по умолчанию равно 7. Однако если это значение иное, реализация не должна использовать размер окна передачи больший, чем указано в полученной команде ИДС. Если используемый размер окна передачи больше размера окна приема, это может привести к сбросу соединения УЛЗ. Требования к фактическому использованию полного размера окна, указанного в получаемой команде ИДС, отсутствуют.

и) Поле информации в ответе ИДС должно содержать размер окна приема ответчика. Размер окна по умолчанию (определенный в ГОСТ Р ИСО/МЭК 8881) равен 7.

ш) Инициатор, получивший ответ ИДС, должен зафиксировать его и действовать с размером окна приема, как указано в i).

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

i) Значение полученного размера окна должно игнорироваться.

и) Рекомендуется, чтобы поле информации в ответе ИДС содержало тип/класс УЛЗ, установленный в значение «класс II», и размер окна приема, установленный в значение '000 0000'.

Примечания

1    Значение класса II определено в ГОСТ 28907 и равно Т1000'.

2    Размер окна приема в кадре ИДС, относящегося к нулевому адресу, не имеет значения. Следовательно, его значение должно игнорироваться. Если никакое другое значение не может быть использовано для этого поля, предлагается значение '000 0000'.

5

Электронная версия

ПРИЛОЖЕНИЕ А (обязательное)

СПИСОК ТРЕБОВАНИИ К ЗАЯВКЕ О СООТВЕТСТВИИ РЕАЛИЗАЦИИ ФУНКЦИОНАЛЬНОМУ СТАНДАРТУ

АЛ Введение

ГОСТ Р ИСО/МЭК ТО 10000-1 определяет три позиции для включения в список требований к ЗСРФС. К ним относятся:

-    общие факультативные возможности профиля;

-    список стандартов, выбранных в профиле;

-    ограничения на допустимые ответы в форме ЗСРП каждого такого стандарта.

Две первые позиции относятся к профилю в целом и поэтому входят только в те части ГОСТ Р ИСО/МЭК МФС 10609, которые специфичны для отдельных профилей. Однако в каждой части указанного стандарта содержится идентификация тех ограничений профиля, которые входят в предмет ее рассмотрения.

ГОСТ Р ИСО/МЭК ТО 10000-1 указывает, что форма ЗСРФС может содержать либо простой список ограничений, либо измененные копии форм ЗСРП базовых стандартов. В настоящем стандарте используется первая из указанных возможностей.

А.2 Нотация и соглашения

А.2.1 Введение

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

А.2.2 Нотация для статического соответствия

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

а) Статус, определяющий непосредственно символы

Символ	Значение
О	Обязательный
ф	Факультативный
3	Запрещенный
—	Не используется
н/р	Не входит в предмет рассмотрения в настоящем стандарте.

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

Ь) Прочая необходимая нотация

Символ    Значение

у <п>    Условный    (см.    ниже)

<позиция> :    <статус>    Условный    (см.    ниже)

Символы в виде у<п> используются в тех случаях, когда статус данной позиции зависит от обеспечения других позиций. В этом случае <п> — это номер, который ссылается на определение окончания раздела, в котором он используется. Это определение устанавливает специальный статус, который может быть выражен, например, в форме типа «если АВС, то о, иначе з», что должно означать статус «обязательно», если позиция в форме ЗСРП с указателем АВС обеспечивается, и статус «запрещено» в противном случае.

Символы в форме <позиция>:<статус> используются как сокращенный способ выражения условий, при которых статус определен, если заданная позиция обеспечивается, в противном случае статус будет иметь значение «не используется». Таким образом, например, «АВС:о» будет эквивалентом условному статусу «если АВС, то о, иначе —».

А.2.3 Нотация при описании динамического соответствия

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

Символ    Значение

о    Обязательный — реализация должна использовать возможность в применимых случаях

ф    Факультативный — использование возможности «факультативное»

з    Запрещенный — использование возможности не разрешается

—    Не используется

н/р    Не входит в предмет рассмотрения в настоящем стандарте