Работаем по всей России
Часы работы: Пн-Пт, 10:00-22:00
+7 ()
Обратный звонок

ГОСТ Р ИСО/МЭК МФС 10608-1-95 Информационная технология. Функциональный стандарт профиля ТАnnnn. Услуги транспортного уровня в режиме-с-установлением-соединения при использовании услуг сетевого уровня в режиме-без-установления-соединения. Часть 1. Общее описание и требования, независимые от подсети

Получить консультацию специалиста

Ошибка: Контактная форма не найдена.

Оставляя заявку, вы соглашаетесь с пользовательским соглашением

ГОСТ Р ИСО/МЭК МФС 10608-1-95

Группа П85

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

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

ФУНКЦИОНАЛЬНЫЙ СТАНДАРТ ПРОФИЛЯ TAnnnn. УСЛУГИ
ТРАНСПОРТНОГО УРОВНЯ В РЕЖИМЕ-С-УСТАНОВЛЕНИЕМ-СОЕДИНЕНИЯ
ПРИ ИСПОЛЬЗОВАНИИ УСЛУГ СЕТЕВОГО УРОВНЯ
В РЕЖИМЕ-БЕЗ-УСТАНОВЛЕНИЯ-СОЕДИНЕНИЯ

Часть 1. Общее описание и требования, независимые от подсети

Information technology. International Standadized Profile TAnnnn Connection-mode
Transport Service over connectionless-mode Network Service. Part 1. General overview and subnetwork-type independent requirements

ОКС 35.100.40*
ОКСТУ 4002
________________
* В Указателе “Государственные стандарты” 2003 год указан ОКС 35.100.05. – Примечание “КОДЕКС”.

Дата введения 1996-07-01

Предисловие

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

ВНЕСЕН Комитетом при Президенте Российской Федерации по политике информатизации

ПОДГОТОВЛЕН Техническим комитетом по стандартизации (TК 22) “Информационная технология”

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 22.08.95 N 446

3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК МФС 10608-1-92 “Информационная технология. Международный функциональный стандарт профиля TAnnnn. Услуги транспортного уровня в режиме-с-установлением-соединения при использовании услуг сетевого уровня в режиме-без-установления-соединения. Часть 1. Общее описание и требования, независимые от подсети”

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

Введение

Введение

Настоящий функциональный стандарт (ФС) определен в контексте функциональной стандартизации в соответствии с принципами, определенными в ГОСТ Р ИСО/МЭК ТО 10000 “Информационная технология. Основы и таксономия функциональных стандартов” (части 1 и 2). Контекст функциональной стандартизации является одним из направлений общей области деятельности по стандартизации информационной технологии (ИТ), охватывающей базовые стандарты, профили и механизмы регистрации. Профиль определяет комбинации базовых стандартов, которые совместно выполняют конкретную четко определенную функцию ИТ. Профили стандартизуют использование факультативных возможностей и других вариантов в базовых стандартах и обеспечивают основу для разработки унифицированных международно признанных системных тестов.

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

Настоящий ФС определяет независимые от типа подсети требования для профилей группы ТА.

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

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

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

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

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

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

ГОСТ 34.960-91 (ГОСТ 8072-86) Информационная технология. Взаимосвязь открытых систем. Определение услуг транспортного уровня

Примечание – См. также рекомендацию МККТТ Х.214- 88.

ГОСТ 34.961-91 (ИСО/МЭК 8073-88) Информационная технология. Взаимосвязь открытых систем. Спецификация протокола уровня в режиме с установлением соединения

Примечание – См. также рекомендацию МККТТ Х.224- 88.

ИСО/МЭК 8073-88/Доп.2-89* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола транспортного уровня в режиме с установлением соединения. Дополнение 2. Операции класса 4 с использованием услуг сетевого уровня в режиме без установления соединения
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта

ИСО/МЭК 8073-88/Доп.3-92* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола транспортного уровня в режиме с установлением соединения. Дополнение 3. Форма заявки о соответствии реализации протоколу
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта

ИСО/МЭК 8073-88/Изм.1-90* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола транспортного уровня в режиме с установлением соединения. Изменение 1.
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта

ИСО/МЭК 8073-88/Изм.2-90* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола уровня в режиме с установлением соединения. Изменение 2.
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта

ИСО/МЭК 8073-88/Изм.4-91* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола транспортного уровня в режиме с установлением соединения. Изменение 4.
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта

ИСО/МЭК 8073-88/Изм.5-91* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола транспортного уровня в режиме с установлением соединения. Изменение 5.
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта России.

ГОСТ Р 34.951-92 (ИСО 8348-87, ИСО 8348-87/Доп.1-87) Информационная технология. Передача данных. Определение услуг сетевого уровня

Примечание – См. также рекомендацию МККТТ X.213-88;

ИСО 8348-87/Доп.2-88* Системы обработки информации. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта России.

ГОСТ Р 34.1952-92 (ИСО 8473-88) Информационная технология. Передача данных. Протокол для обеспечения услуг сетевого уровня в режиме без установления соединения

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

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

4 СОКРАЩЕНИЯ

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

5 ТРЕБОВАНИЯ, НЕЗАВИСИМЫЕ ОТ ТИПА ПОДСЕТИ

5.1 Общие положения

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

5.2 Требования транспортного уровня

Настоящий стандарт устанавливает обеспечение услуг транспортного уровня в режиме-с-установлением-соединения, определенных в ГОСТ 34.960, с использованием класса 4 протокола транспортного уровня в режиме-с-установлением-соединения, определенного в ГОСТ 34.961, а также в ИСО/МЭК 8073/Доп.2, где описаны операции класса 4 при использовании услуг сетевого уровня в режиме-без-установления соединения.

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

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

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

a) удовлетворять требованиям соответствия согласно разделу 14 ГОСТ 34.961;

b) обеспечивать обязательные функциональные возможности для класса 4 через УСУ-БУС согласно ГОСТ 34.961 и ИСО/МЭК 8073/Доп.2;

c) если реализация претендует на возможность инициации соединения транспортного уровня, она должна быть способна демонстрировать передачу ПБДТ ЗС с:

1) классом 4 как предопределенным;

d) если реализация претендует на способность отвечать на попытку установления соединения транспортного уровня, она должна быть способна демонстрировать прием ПБДТ ЗС с классом 4 как предопределенным;

e) если реализация претендует на возможность инициации соединения транспортного уровня, она должна быть способна:

1) передавать поле ИД-ПДУТУ вызываемого в ПБДТ ЗС,

2) при необходимости, передавать поле ИД-ПДУТУ вызывающего в ПБДТ ЗС, который может переносить любой из селекторов транспортного уровня, реализуемых системой;

f) если реализация претендует на способность отвечать на попытку установления соединения транспортного уровня, она должна быть способна:

1) передавать поле ИД-ПДУТУ вызывающего в ПБДТ ПС,

2) при необходимости, передавать поле ИД-ПДУТУ вызываемого в ПБДТ ПС, который может переносить любой из селекторов транспортного уровня, реализуемых системой;

g) быть способна образовывать начальные значения следующих параметров:

Т1 – Время локальной повторной передачи,

N – Максимальное число повторных передач,

I – Время неактивности,

W – Время окна;

h) если реализация соблюдает любую стратегию, задерживающую передачу ПБДТ ПД, то максимальное время, на которое может быть задержан один ПБДТ ПД, должно быть указано поставщику услуг транспортного уровня с использованием параметра “время подтверждения”.

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

а) ИД-ПДУТУ

Реализация должна поддерживать параметры удаленного ИД-ПДУТУ переменного размера вплоть до 32 октетов, использующих любые коды и значения.

Длина локальных Т-селекторов не должна превышать 32 октета.

При получении ПБДТ ЗС отсутствие параметра “ИД-ПДУТУ вызывающего” или “ИД-ПДУТУ вызываемого” следует рассматривать как эквивалент такого же параметра нулевой длины.

Отсутствие параметра “ИД-ПДУТУ вызывающего” в полученном ПБДТ ПС, означает, что значение параметра “ИД-ПДУТУ вызывающего” в ПС эквивалентно значению параметра “ИД-ПДУТУ вызывающего” в ЗС.

Отсутствие параметра “ИД-ПДУТУ вызываемого” в полученном ПБДТ ПС, означает, что значение параметра “ИД-ПДУТУ вызываемого” в ПС эквивалентно значению параметра “ИД-ПДУТУ вызываемого” в ЗС.

На рисунке 1 приводятся сводные сведения о трактовке параметров ИД-ПДУТУ вызывающей и вызываемой стороны ПБДТ ЗС и ПС.

Примечания

1 ПС вызываемого эквивалентно ЗС вызываемого.

2 ПС вызываемого по длине и значению должен соответствовать ЗС вызываемого.

3 ПС вызывающего по длине и значению должен соответствовать ЗС вызывающего.

4 ПС вызывающего эквивалентен ЗС вызывающего.

Рисунок 1 – Трактовка параметров ИД-ПДУТУ вызываемого и вызывающего

b) Факультативный выбор при установлении соединения

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

c) Недействительные значения в известных параметрах

Известные параметры с недействительными длинами в ПБДТ ЗС или ПС должны рассматриваться как протокольная ошибка.

Известные параметры с действительными длинами, но недействительными значениями в ПБДТ ЗС, должны обрабатываться следующим образом:

Параметр

Действие

Вызываемый ИД-ПДУТУ

передача ПБДТ ЗР

Контрольная сумма

сброс ПБДТ ЗС

5.3 Требования сетевого уровня

Настоящий стандарт определяет обеспечение услуг сетевого уровня в режим-без-установления-соединения, определенных в ГОСТ Р 34.951, с использованием услуг сетевого уровня в режиме-без-установления-соединения, определенных в ГОСТ Р 34.1952.

Стандарт определяет использование адресов сетевого уровня ВОС в соответствии с ИСО 8348/Доп.2. Любые адреса ПДУСУ в любых форматах, определенных ИСО 8348/Доп.2, могут быть использованы в ГОСТ Р 34.1952.

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

Дополнительные требования, которые определяют СТФС для протокола сетевого уровня, приведены в приложении С.

5.3.1 Требования ПСБУС

5.3.1.1 Неактивное подмножество

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

5.3.1.2 Несегментированное подмножество

Реализация не должна генерировать ПБД “данные” без части “сегментирование”. Однако она должна принимать и правильно обрабатывать те ПБД, которые не содержат сегментируемой части, необходимой для обеспечения взаимодействия с теми системами, которые предпочитают передавать ПБД без сегментированной части, т.е. когда флаг “сегментирование разрешено” установлен в ноль.

5.3.2 Требования ОС-ПС

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

6 РАСПОЛОЖЕНИЕ ТРЕБОВАНИЙ, СПЕЦИФИЧНЫХ ДЛЯ ТИПА ПОДСЕТИ

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

Перечисленные ниже номера частей настоящего стандарта присвоены в предположении, что эти части будут разработаны в обозримом будущем.

Часть 2 ТА51 – ЛВС КДОН/ОК;

Часть 3 ТА52 – ЛВС “Шина с маркерным доступом”;

Часть 4 ТА53 – ЛВС “Кольцо с маркерным доступом”;

Часть 5 ТА1111/ТА1121 – Подсеть Х.25.

ПРИЛОЖЕНИЕ А (обязательное). Список требований ЗСРПФС (СТФС)

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

A.1 Введение

СТФС в данном приложении определяет дополнительные требования к ИСО/МЭК 8073/Доп.3. Требования, установленные в ИСО/МЭК 8073/Доп.3, относятся к каждой позиции, для которой отсутствует запись в данном СТФС.

СТФС данного приложения составлен по форме, определенной в ИСО/МЭК 8073/Доп.3. Поскольку группа профилей ТА использует только класс 4 протокола транспортного уровня, то колонка “статус” ЗСРП для классов с 0 по 3 и класса 4 через УСУ-УС не нуждается в повторном описании в СТФС для профилей ТА. Все ссылки на классы транспортного уровня с 1 по 3 и класс 4 через УСУ-УС не входят в предмет рассмотрения настоящего ФС.

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

А.2 Нотация

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

а) Нотация статуса базовых стандартов.

1) тип или диапазон базового стандарта.

О

– обязательно

Ф

– факультативно

Ф.<n>

– факультативно, но требуется обеспечение по меньшей мере одной из групп факультативных возможностей, помеченных одним и тем же номером <n>

<позиции>:

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

<позиции>: :

– когда этот групповой предикат имеет значение “истина”, соответствующий раздел должен быть завершен

b) Нотация статуса СТФС.

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

1) Статическое

о – обязательно (реализация обязательна)

н/р – не входит в предмет рассмотрения (не относится к настоящему профилю)

2) Динамическое

о – обязательно (использование обязательно).

А.3 СТФС транспортного уровня

А.3.1 Функции ППУ-ССУ

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Функциональная возможность

Раздел базового стандарта

Статус

Раздел ФС

Статус

С2

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

6.3.1

Ф

н/р

С3

Диагностика

7.6.2, 7.7

Ф

н/р

С4

Активное восстановление соединения сетевого уровня

7.4.2

Ф

н/р

А.3.2 Функции, обеспечиваемые в классе 4 (С4 или C4L::)

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Функциональная возможность

Раздел базового стандарта

Статус

Раздел ФС

Статус

Т4Ф29

Неиспользование контрольной суммы

6.17

Ф

5.2.2 b

о

А.3.3 Обеспечиваемые параметры выдаваемых ПБДТ

А.3.3.1 Обеспечиваемые параметры для ППУ-ССУ (А1::)

А.3.3.2 ПБДТ ИС (SN1::)

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Обеспечиваемые параметры

Раздел базового стандарта

Допустимые значения

Раздел ФС

Статус

ВИ1

Идентификатор протокола

8.3.3б

ГОСТ 34.961, ГОСТ Р 34.964, частное

ГОСТ 34.961

А.3.3.3 Обеспечиваемые параметры для класса 4

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Обеспечиваемые параметры

Раздел базового стандарта

Статус

Раздел ФС

Статус

В4ЗС7

Вызываемый ИД ПДУТУ

13.3.4а

Ф

о

В4ЗС11

Параметры защиты

13.3.4г

Ф

н/р

В4ЗC12

Выбор дополнительной факультативной функции

13.3.4е

Ф

о

В4ЗС13

Пропускная способность

13.3.4и

Ф

н/р

В4ЗC14

Коэффициент необнаруженных ошибок

13.3.4к

Ф

н/р

В4ЗС15

Приоритет

13.3.4л

Ф

н/р

В4ЗC16

Транзитная задержка

13.3.4н

Ф

н/р

В4ПС7

Вызывающий ИД ПДУТУ

13.4.4

Ф

о

В4ПС9

Параметры защиты

13.4.4

Ф

н/р

В4ПС10

Выбор дополнительной факультативной функции

13.4.4

Ф

о

В4ПС12

Пропускная способность

13.4.4

Ф

н/р

В4ПС13

Коэффициент необнаруженных ошибок

13.4.4

Ф

н/р

В4ПС14

Приоритет

13.4.4

Ф

н/р

В4ПС15

Транзитная задержка

13.4.4

Ф

н/р

В4ЗР4

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

13.5.4а

Ф

н/р

А.3.4 Реализация протокола

А.3.4.1 Реализуемые классы

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Функциональная возможность

Раздел базового стандарта

Статус

Раздел ФС

Статус

С4L

Реализация класса 4 через УСУ-БУС

14

ИСО:С2:Ф

о

А.3.4.2 Согласование класса со стороны ответчика

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Функциональная возможность

Раздел базового стандарта

Допустимые ответы

Раздел ФС

Статус

RC4

Этими классами вы можете отвечать, если ЗС предлагает только класс 4

6.5.4з
табл.3

2, 4 или отказ от соединения в зависимости от обеспечи- ваемых классов

4

ПРИЛОЖЕНИЕ В (обязательное). Перечень поправок

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

В.1 Введение

Перечень поправок, приведенный в данном приложении, отражает содержимое ИСО/МЭК 8073 (ГОСТ 34.961), дополнений и изменений к нему (см. раздел 2). Данный перечень поправок разработан и одобрен ИСО/МЭК СТК 1/ПК 6, но к моменту публикации настоящего стандарта не был опубликован в качестве изменения ИСО/МЭК 8073. Перечень поправок включен в данное приложение потому, что он содержит соответствующую информацию о требованиях и смысловом содержании базового стандарта. Реализации должны соответствовать базовому стандарту с учетом данных поправок.

1 Номер поправки: 8073/53.

8. Классификатор: Техническая.

9. Ссылка в документе: подраздел 12.2.4.2.

10. Содержание поправки:

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

11. Решение, предлагаемое первоисточником:

Дополнить 12.2.4.2 следующим абзацем:

“Примечание – Хотя процедура повторной передачи также применяется для ПБДТ ЗР в фазе разъединения, она по возможности учитывает, что соединение транспортного уровня освобождается, если необходимо открыть новое соединение сетевого уровня для повторной передачи ПБДТ ЗР”.

12. Редакционная правка:

Дополнить 12.2.4.2 следующим абзацем:

“Хотя процедура повторной передачи также применяется для ПБДТ ЗР в фазе разъединения, логический объект транспортного уровня может учитывать, что соединение транспортного уровня освобождается, если необходимо открыть новое соединение сетевого уровня, чтобы повторно передать ПБДТ ЗР”.

1. Номер поправки: 8073/64.

8. Классификатор: Техническая.

9. Ссылка в документе: подпункт 6.1.3, абзацы 3 и 5.

10. Содержание поправки: Пояснение, связанное с поправкой 8073/63.

11. Решение, предлагаемое первоисточником: см. пункт 12.

Подпункт 6.1.3, абзац 3:

Заменить термин “логический объект транспортного уровня” на термин “инициатор”.

Подпункт 6.1.3, абзац 5. Дополнить перечисление с) предложением: “B этом случае как инициатор, так и ответчик информируют о прикреплении СТУ”.

12. Редакционная правка:

В подпункте 6.1.3, абзац 3:

Заменить термин “логический объект транспортного уровня” на термин “инициатор”.

ПРИЛОЖЕНИЕ С (обязательное). Список требований ЗСРПФС (СТФС)

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

С.1 Введение

СТФС в данном приложении определяет дополнительные требования к ГОСТ 34.1952. Требования, установленные в ГОСТ Р 34.1952, относятся к каждой позиции, для которой отсутствует запись в настоящем СТФС.

СТФС данного приложения основывается на рабочем проекте формы, которая еще не была пересмотрена компетентным техническим комитетом ИСО.

Данный СТФС определяет полную реализацию протокола сетевого уровня в режиме-без-установления-соединения для оконечных систем. Ни одно из двух определенных в ГОСТ Р 34.1952 подмножеств не используется. Операции промежуточных систем не определены.

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

С.2 Нотация

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

а) Нотация статуса базовых стандартов.

1) тип или диапазон базового стандарта.

О

– обязательно

Ф

– факультативно

Ф.<n>

– факультативно, но требуется обеспечение по меньшей мере с одной из групп факультативных возможностей, помеченных одним и тем же номером <n>

– не используется

<позиции>:

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

<позиции>: :

– когда этот групповой предикат имеет значение “истина”, соответствующий раздел должен быть завершен

b) Нотация статуса СТФС.

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

1) Статическое

о – обязательно (реализация обязательна)

ф – факультативно (реализуется факультативно)

н/р – не входит в предмет рассмотрения (не относится к настоящему профилю)

2) Динамическое

о – обязательно (использование обязательно)

и – исключено (использование в контексте настоящего профиля запрещено).

С.3 СТФС в режиме без-установления-соединения

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

С.3.1 Обеспечиваемые ПБДС

Используются только перечисленные ниже ПБДС

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

ПБДС

Раздел базового стандарта

Статус

Раздел ФС

Статус

Передача ДН

7.7

О

&

Прием ДН

7.7

О

&

Передача ОШ

7.9

О

&

Прием ОШ

7.9

О

&

С.3.2 Обеспечиваемые подмножества

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

Функциональные возможности базового стандарта

Функциональные возможности профиля

Индекс

Протокольные подмножества

Раздел базового стандарта

Статус

Раздел ФС

Статус

ДН

ОШ

ДН

ОШ

Передача неактивной подмножества

7.8

Ф

5.3.1

фи

&

Прием неактивной подмножества

7.8

Ф

5.3.1

н/р

&

Передача не- сегментируемого подмножества

7.4

Ф

5.3.1

фи

&

Прием не- сегментируемого подмножества

7.4

Ф

5.3.1

оо

&

& – так же, как в базовом стандарте.

С.3.3 Обеспечиваемые функции

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

Функциональные возможности базового стандарта – передача

Функциональные возможности профиля

Индекс

Передаваемые функции протокола

Раздел базового стандарта

Статус

Раздел ФС

Статус

ДН

ОШ

ДН

ОШ

Формирование ПБД

6.1

О

О

&

&

Маршрутизация ПБД

6.5

О

О

&

&

Продвижение ПБД

6.6

О

О

&

&

Сегментирование

6.7

О

&

&

Отчет об ошибке

6.10

Ф

&

&

Обнаружение ошибки в заголовке ПБД

6.11

Ф

Ф

&

&

Уведомление о перегрузке

6.18

Ф

Ф

&

&

Функциональные возможности базового стандарта – прием

Функциональные возможности профиля

Индекс

Передаваемые функции протокола

Раздел базового стандарта

Статус

Раздел ФС

Статус

ДН

ОШ

ДН

ОШ

Расформирова- ние ПБД

6.2

О

О

&

&

Анализ формата заголовка

6.3

О

О

&

&

Контроль времени существования ПБД

6.4

Ф

Ф

&

&

Сборка

6.8

О

&

&

Аннулирование ПБД

6.9

О

&

&

Отчет об ошибке

6.10

О

&

&

Обнаружение ошибки в заголовке ПБД

6.11

О

Ф

&

&

Уведомление о перегрузке

6.18

Ф

Ф

&

&

& – так же, как в базовом стандарте.

С.3.4 Обеспечиваемые параметры

Поставщик должен указать в форме ЗСРП обеспечение следующих параметров

Функциональные возможности базового стандарта – передача

Функциональные возможности профиля

Индекс

Передаваемые
парамеиры протокола

Раздел базового стандарта

Статус

Раздел ФС

Статус

ДН

ОШ

ДН

ОШ

Заполнение

7.5.2

Ф

Ф

&

&

Защита

7.5.3

Ф

Ф

н/р

н/р

Причина аннулирования

7.9.1.4

О

&

&

Частичная маршрутизация со стороны отправителя

7.5.4

Ф

Ф

фи

фи

Полная маршрутизация со стороны отправителя

7.5.4

Ф

Ф

фи

фи

Частичная регистрация маршрута

7.5.5

Ф

Ф

&

&

Полная регистрация маршрута

7.5.5

Ф

Ф

фи

фи

Обеспечение КУ

7.5.6

Ф

Ф

н/р

н/р

Приоритетность

7.5.7

Ф

Ф

н/р

н/р

Функциональные возможности базового стандарта – прием

Функциональные возможности профиля

Индекс

Передаваемые функции протокола

Раздел базового стандарта

Статус

Раздел ФС

Статус

ДН

ОШ

ДН

ОШ

Заполнение

7.5.2

Ф

Ф

&

&

Защита

7.5.3

Ф

Ф

н/р

н/р

Причина аннулирования

7.9.1.4

О

&

&

Частичная маршрутизация со стороны отправителя

7.5.4

Ф

Ф

н/р

н/р

Полная маршрутизация со стороны отправителя

7.5.4

Ф

Ф

н/р

н/р

Частичная регистрация маршрута

7.5.5

Ф

Ф

н/р

н/р

Полная регистрация маршрута

7.5.5

Ф

Ф

н/р

н/р

Обеспечение КУ

7.5.6

Ф

Ф

н/р

н/р

Приоритетность

7.5.7

Ф

Ф

н/р

н/р

Примечание – Обеспечение КУ обязательно (оо), если система обеспечивает функцию уведомления о перегрузке.

& – так же, как в базовом стандарте.

ПРИЛОЖЕНИЕ D (рекомендуемое). Рекомендации по взаимодействию на транспортном уровне

ПРИЛОЖЕНИЕ D
(рекомендуемое)

D.1 Рекомендации по транспортному уровню

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

D.1.1 Тайм-аут повторных передач

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

,

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

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

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

,

где – новый результат проверки: – параметр, который может принимать значение от 0 до 1. Подбираемое для значение определяет относительную весомость текущего оценочного значения и нового значения проверки. Большое значение увеличивает весомость старого оценочного значения, что приводит только к замедленной реакции на вариации задержки кругового обхода.

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

Если представить в виде 1-2 для некоторого значения , то процедура корректировки может быть сведена к вычитанию и примет следующий вид:

.

Если при проверках принят ПБДТ ПД, который подтверждает несколько ПБДТ ДН, должен рассматриваться только один результат проверки относительно задержки кругового обхода самого последнего переданного ПБДТ ДН. Это попытки уменьшить любую задержку, обусловленную удаленным поставщиком услуги транспортного уровня, задерживающего ПБДТ ПД.

D.1.2 Функция сохранения активности

Протокол класса 4 определяет неработоспособность соединения транспортного уровня с помощью тайм-аута неактивности. Этот тайм-аут сбрасывается при каждом получении ПБДТ по данному соединению. При истечении тайм-аута соединение завершается.

Протокол класса 4 поддерживает соединение в холостом состоянии, периодически передавая ПБДТ ПД при истечении тайм-аута окна. Таким образом, в простой реализации величина одного интервала тайм-аута окна логического объекта транспортного уровня должна быть меньше величины интервала тайм-аута неактивности равноправного логического объекта, и наоборот. Описанный ниже механизм может быть использован, если известно, что удаленная реализация всегда отвечает на прием продублированного ПБДТ ПД, не содержащего подтверждения управления потоком, передаваемого ПБДТ ПД, содержащим параметр подтверждения управления потоком. Тем самым устраняется потребность в знании значений тайм-аутов удаленных реализаций.

– Реализация должна всегда передавать дублирующие ПБДТ ПД без подтверждения управления потоком по истечении локального тайм-аута окна (ГОСТ 34.961, 12.2.3.8.1). Получение этого ПБДТ удаленным логическим объектом транспортного уровня приведет к выдаче им в ответ ПБДТ ПД, содержащего параметр подтверждения управления потоком. Когда этот ПБДТ будет принят локальным логическим объектом транспортного уровня, последний сбросит тайм-аут неактивности – см. рисунок D.1.

– Установка значений тайм-аутов реализации, в частности, в подходящие относительные значения носит локальный для реализации характер:

– значение тайм-аута окна должно превышать задержку кругового обхода;

– тайм-аут неактивности должен быть в два раза больше, а обычно может быть в несколько раз больше тайм-аута окна, если соединение транспортного уровня должно быть устойчиво к потере ПБДТ ПД. Дублирующий ПБДТ ПД (см. рисунок D.1) содержит в себе те же значения НР-ОТВ, кредита и порядкового номера, что и ранее переданный ПБДТ ПД. Дублирующий ПБДТ ПД не подтверждает никаких новых данных и не изменяет кредитного окна.

Рисунок D.1 – Обмен ПБДТ ПД по холостому соединению

D.1.3 Номер версии

Параметр “номер версии” никогда не должен передаваться в ПБДТ ЗС, а в случае получения должен игнорироваться. Если по каким-либо причинам номер версии был передан в ПБДТ ЗС, то его значение должно быть установлено в единицу.

D.1.4 Расширенная нумерация

Для всех профилей ТА5n настоятельно рекомендуется обеспечивать в реализации факультативную возможность расширенной нумерации ПБДТ ЗС.

В высокоскоростных сетях, таких как ЛВС КДОН/ОК на 10 Мбит/с (профиль ТА51), большое число результатов тестирования и реализаций показали необходимость использования факультативной возможности расширенной нумерации для получения адекватной производительности.

D.1.5 Механизм устранения перегрузок

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

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

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

Правила принимающих логических объектов транспортного уровня (ПмЛОТ).

Правило1

Инициализация окна.

Начальное значение ОПм (известное как ОПмО) должно иметь локально формируемую верхнюю границу. Это окно передается передающему логическому объекту транспортного уровня (ПдЛОТ) в следующем передаваемом поле КРД.

Правило 2

Требуемый период проверки.

Все ПмЛОТ должны сохранять фиксированное значение ОПм до тех пор, пока не поступят следующие 2 ПБДТ ДН ОПм, считая с момента, когда ПмЛОТ передал последнее поле КРД.

Правило 3

Требуемый подсчет принятых ПБДТ в период проверки.

Все ПмЛОТ должны сохранять число N, определяющее суммарное количество принятых ПБДТ, и число NC, определяющее суммарной число принятых ПБДТ, в которых установлен флаг “ощущается перегрузка” (ОП). В подсчет N и NC включаются все типы ПБДТ, за исключением ПБДТ ДП.

Правило 4

Необходимые действия о конце периода проверки.

Все ПмЛОТ в конце каждого периода проверки должны выполнять следующие действия:

– если число NC составляет менее 50% N, то ПмЛОТ должен увеличивать ОПм, добавляя единицу максимум до ОПм1, что основывается на стратегии управления локальным буфером. В противном случае, ПмЛОТ должен уменьшать ОПм, умножая его на 0,875 (минимум до 1):

– сбросить N и NC в ноль;

– передать в следующем ноле КРД новое окно ОПм передающему логическому объекту транспортного уровня.

Правила передающих логических объектов транспортного уровня (ПрЛОТ).

Правило 1

Инициализация окна.

Все ПдЛОТ должны обеспечивать размер окна передачи (ОПд). В начальный момент, а также до тех пор, пока не происходит потерь, ОПд устанавливается в значение окна приема ОПм. полученного от удаленного ПмЛОТ в последнем поле КРД.

Правило 2

Необходимые действия при истечении тайм-аута.

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

Правило 3

Требуемый подсчет подтвержденных ПБДТ.

Все ПрЛОТ должны обеспечивать счет ДАПм, определяющего число ПБДТ ДН, подтвержденных ПмЛОТ с момента последней подстройки ОПд. Следовательно, при каждой подстройке ОПд счет ДАПм должен сбрасываться в ноль.

Правило 4

Стратегия уменьшения окна.

Все ПрЛОТ должны уменьшать ОПд на единицу каждый раз, когда счет ДАПм становится равным или большим текущего значения ОПд, если только ОПд не превышает окна, допускаемого удаленным ПмЛОТ.

D.2 Рекомендации по сетевому уровню

D.2.1 ПСУ-БУС

В реализации протокола ГОСТ Р 34.1952 параметр “время существования ПБД” должен представляться начальным значением, по меньшей мере трехкратной протяженности сети или трехкратным значением максимальной транзитной задержки (в единицах 500 мс) в зависимости от того, что больше.

Неактивное подмножество ПСУ-БУС было определено вне рамок рассмотрения данного профиля, однако настоятельно рекомендуется, чтобы во всех случаях использовался полный профиль ПСУ-БУС. Рекомендуется также, чтобы неактивное подмножество никогда не использовалось и не реализовывалось.

D.2.2 ОС-ПС

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

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

ПРИЛОЖЕНИЕ Е (справочное). Библиография

ПРИЛОЖЕНИЕ Е
(справочное)

В данном приложении приведен перечень стандартов, которые содержат информацию дополнительно к перечисленной в разделе 2.

ИСО 8648-87* Системы обработки информации. Передача данных. Внутренняя организация сетевого уровня
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта России.

ГОСТ Р 34.90-93 Информационная технология. Передача данных и обмен информацией между системами. Протокольные комбинации для обеспечения и поддержки услуг сетевого уровня ВОС. (ИСО/МЭК 8880-1-90, ИСО/МЭК 8880-2-92, ИСО/МЭК 8880-3-90)

ИСО/МЭК ТО 9575-90* Информационная технология. Телекоммуникации и информационный обмен между системами. Основы маршрутизации в ВОС

ИСО/МЭК ТО 9577-90* Информационная технология. Телекоммуникации и информационный обмен между системами. Идентификация протоколов сетевого уровня
_____________________
* До прямого применения данного документа в качестве государственного стандарта Российской Федерации он может быть получен во ВНИИКИ Госстандарта России.

ГОСТ Р ИСО/МЭК 9646-1-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 1. Общие положения

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

Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 1995

Выполненные работы

Натуральные чаи «Чайные технологии»
Натуральные чаи «Чайные технологии»
О проекте

Производитель пищевой продукции «Чайные технологии» заключил контракт с федеральной розничной сетью «АЗБУКА ВКУСА» на поставку натуральных чаев.

Под требования заказчика был оформлен следующий комплект документов: технические условия с последующей регистрацией в ФБУ ЦСМ; технологическая инструкция; сертификат соответствия ГОСТ Р сроком на 3 года; декларация соответствия ТР ТС ЕАС сроком на 3 года с внесение в госреестр (Росаккредитация) с протоколами испытаний; Сертификат соответствия ISO 22 000; Разработан и внедрен на производство план ХАССП.

Выдали полный комплект документов, производитель успешно прошел приемку в «АЗБУКЕ ВКУСА». Срок реализации проекта составил 35 дней.

Что сертифицировали

Азбука Вкуса

Кто вёл проект
Дарья Луценко - Специалист по сертификации

Дарья Луценко

Специалист по сертификации

Оборудования для пожаротушения IFEX
Оборудования для пожаротушения IFEX
О проекте

Производитель оборудования для пожаротушения IFEX открыл представительство в России. Заключив договор на сертификацию продукции, организовали выезд экспертов на производство в Германию для выполнения АКТа анализа производства, часть оборудования провели испытания на месте в испытательной лаборатории на производстве, часть продукции доставили в Россию и совместно с МЧС РОССИИ провели полигонные испытания на соответствия требованиям заявленным производителем.

По требованию заказчика был оформлен сертификат соответствия пожарной безопасности сроком на 5 лет с внесением в госреестр (Росаккредитация) и протоколами испытаний, а также переведена и разработана нормативное документация в соответствии с ГОСТ 53291.

Выдали полный комплект документации, а производитель успешно реализовал Госконтракт на поставку оборудования. Срок реализации проекта составил 45 дней.

Что сертифицировали

Международный производитель оборудования
для пожаротушения IFEX

Кто вёл проект
Василий Орлов - Генеральный директор

Василий Орлов

Генеральный директор

Рассчитать стоимость оформления документации

Специалист свяжется с Вами в ближайшее время

Получить консультацию специалиста

Ошибка: Контактная форма не найдена.

Оставляя заявку, вы соглашаетесь с пользовательским соглашением