ГОСТ Р ИСО/МЭК МФС 10607-1-94 Информационная технология. Функциональный стандарт профилей АFТnn. Передача файлов, доступ к файлам и управление файлами. Часть 1. Спецификация протоколов СЭУА, уровня представления и сеансового уровня для использования протоколами ПДУФ

ГОСТ Р ИСО/МЭК МФС 10607-1-94

Группа П85

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


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

ФУНКЦИОНАЛЬНЫЙ СТАНДАРТ ПРОФИЛЕЙ AFTnn

ПЕРЕДАЧА ФАЙЛОВ, ДОСТУП К ФАЙЛАМ И УПРАВЛЕНИЕ ФАЙЛАМИ

Часть 1. Спецификация протоколов СЭУА, уровня представления и сеансового
уровня для использования протоколами ПДУФ

Information technology. International standardized profiles AFTnn.
File transfer, access and management. Part 1. Specification of ACSE,
presentation and session protocols for use by FTAM

ОКСТУ 4002

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

Предисловие

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

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

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

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

3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК МФС 10607-1-90 "Информационная технология. Международный функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 1. Спецификация протоколов СЭУА, уровня представления и сеансового уровня для использования протоколами ПДУФ"

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

ВВЕДЕНИЕ

ВВЕДЕНИЕ

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

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

Настоящий ФС эквивалентен ИСО/МЭК МФС 10607-1, который разработан в тесном сотрудничестве с группами экспертов по ПДУФ трех международных рабочих групп по ВОС: Секцией реализаторов ВОС (NIST OIW), Европейской секцией открытых систем (EWOS) и секцией Азии-Океании (AOW). ИСО/МЭК МФС 10607-1 согласован с этими секциями и в конечном счете ратифицирован пленарными ассамблеями этих секций.

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

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

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

1.2 Место в таксономии

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

Он может быть объединен с любыми профилями Т (см. ГОСТ Р ИСО/МЭК ТО 10000), определяющими услуги транспортного уровня в режиме-с-установлением-соединения.

1.3 Сценарий

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

Рисунок 1 - Модель обеспечивающих уровней

Рисунок 1 - Модель обеспечивающих уровней

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

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

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

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

ГОСТ Р 34.980.1-92 (ИСО 8571-1-88) Информационная технология. Взаимосвязь открытых систем. Передача файлов, доступ к файлам и управление файлами. Часть 1. Общее введение

ГОСТ Р 34.980.2-92 (ИСО 8571-2-88) Информационная технология. Взаимосвязь открытых систем. Передача файлов, доступ к файлам и управление файлами. Часть 2. Определение виртуального накопителя файлов

ГОСТ Р 34.1980.3-92 (ИСО 8571-3-88) Информационная технология. Взаимосвязь открытых систем. Передача файлов, доступ к файлам и управление файлами. Часть 3. Определение услуг файлов

ГОСТ Р 34.1980.4-93 (ИСО 8571-4-88) Информационная технология. Взаимосвязь открытых систем. Передача файлов, доступ к файлам и управление файлами. Часть 4. Спецификация протокола файлов

ИСО/МЭК 8571-5-90* Системы обработки информация Взаимосвязь открытых систем. Передача файлов, доступ к файлам и управление файлами. Часть 5. Форма заявки о соответствии реализации протоколу
______________
* До прямого применения данных документов в качестве государственных стандартов Российской Федерации они могут быть получены во ВНИИКИ Госстандарта России.

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

ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактной синтаксической нотации версии один (ACH.1)

ГОСТ 37.974-91* (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Спецификация базовых правил кодирования абстрактно-синтаксической нотации версии один (АСН.1)
______________
* Вероятно ошибка оригинала. Следует читать: "ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Спецификация базовых правил кодирования абстрактно-синтаксической нотации версии один (АСН.1)". - Примечание "КОДЕКС".

ГОСТ Р 34.982-92 (ИСО 8650-88) Информационная технология. Взаимосвязь открытых систем. Спецификация протокола для сервисного элемента управления ассоциацией

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

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

ГОСТ Р ИСО/МЭК МФС 10607-2-94 Информационная технология. Функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 2. Определение типов документов, наборов ограничений и синтаксисов

ИСО/МЭК МФС 10607-2/Изм.1-91* "Информационная технология. Международный функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 2. Определение типов документов, наборов ограничений и синтаксисов. Изменение 1. Дополнительные определения
______________
* До прямого применения данных документов в качестве государственных стандартов Российской Федерации они могут быть получены во ВНИИКИ Госстандарта России.

ГОСТ Р ИСО/МЭК МФС 10607-3-94 Информационная технология. Функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 3. AFT11 - услуги передачи простых файлов (неструктурированных)

ИСО/МЭК МФС 10607-4-91* Информационная технология. Международный функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 4. АFТ12 - услуги передачи позиционных файлов (плоских)
______________
* До прямого применения данных документов в качестве государственных стандартов Российской Федерации они могут быть получены во ВНИИКИ Госстандарта России.

ГОСТ Р ИСО/МЭК МФС 10607-5-94 Информационная технология. Функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 5. AFT22 - услуги доступа к позиционным файлам (плоским)

ГОСТ Р ИСО/МЭК МФС 10607-6-94 Информационная технология. Функциональный стандарт профилей AFTnn. Передача файлов, доступ к файлам и управление файлами. Часть 6. AFT3 - услуги административного управления файлами.

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

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

Кроме того, здесь даны определения следующим терминам.

3.1 Общее понятие

Взаимодействие - способность к совместным действиям для достижения цели инициатора.

3.2 Степень обеспечения

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

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

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

Примечания

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

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

3.2.2 Факультативно обеспечиваемое; ф - любая возможность, обозначаемая "ф", обеспечивается в реализация по усмотрению ее разработчика.

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

3.2.3 Условно обеспечиваемая; у - любая возможность, обозначенная "у", должна обеспечиваться при соблюдении условий, определенных в настоящем стандарте. Если эти условия отсутствуют, то обеспечение данной возможности не входит в предмет рассмотрения настоящего стандарта.

3.2.4 Исключенная; и - любая возможность, обозначенная "и", исключается из настоящего стандарта, т.е. не должна реализовываться.

3.2.5 Не рассматривается; н/р - любая возможность, обозначенная "н/р", не входит в предмет рассмотрения настоящего стандарта, т.е. может быть проигнорирована и, следовательно, она не может быть предметом аттестационного тестирования ФС. Однако синтаксис всех параметров, обеспечиваемых ПБД, должен быть реализован, даже если процедуры не реализованы (т.е. получатель должен быть способен декодировать ПБД).

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

4 СОКРАЩЕНИЯ

Степень обеспечения протокольных возможностей:

О - обеспечивается обязательно;

ф - обеспечивается факультативно;

у - обеспечивается условно;

и - исключено;

н/р - не входит в предмет рассмотрения;

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

5 СООТВЕТСТВИЕ

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

5.1 Констатация соответствия

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

5.2 Взаимоотношения с базовыми стандартами

5.2.1 Соответствие СЭУА

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

5.2.2 Соответствие уровня представления

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

5.2.3. Соответствие синтаксису передачи

Реализация, соответствующая настоящему стандарту, должна обеспечивать "базовое кодирование простого типа АСН.1", определенное в ГОСТ 34.974, наряду с дополнительными правилами, определенными в разделе 8, по генерации протокольных кодов АСН.1.

5.2.4 Соответствие сеансовому уровню

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

6 СЕРВИСНЫЙ ЭЛЕМЕНТ УПРАВЛЕНИЯ АССОЦИАЦИЕЙ (СЭУА)

Обеспечение функций и параметров для СЭУА определено в A.1 приложения А. ЗСРП реализации может налагать ограничения на протокольные аспекты, касающиеся длины или значений, но она не должна налагать более серьезных ограничений, по сравнению с теми, что определены в данном разделе. Реализация, соответствующая настоящему стандарту, может прервать ассоциацию, если нарушены требования, определенные в 6.1-6.3.

6.1 Наименование логического объекта прикладного уровня

Наименования логических объектов физического уровня должны реализовываться в соответствии с технической поправкой 1 к ГОСТ Р 34.982.

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

Примечания

1 "Обеспечено" означает реализованную возможность передачи и приема параметра, но не обязательно используемую в каждом сеансе взаимодействия.

2 Наименование ЛОП должно образовываться путем присоединения определителя ЛОП к соответствующему наименованию Прикладного Протокола.

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

Стандарт ГОСТ Р 34.1980.4 определяет значение простого механизма передачи. Другие значения не определены в настоящем стандарте.

6.3 ПБДП "прерывание"

При использовании ПБДП в фазе установления ассоциации согласование на уровне представления считается полным и компонент ВНЕШНЕЕ "прямая-ссылка" не должен иметь место.

7 УРОВЕНЬ ПРЕДСТАВЛЕНИЯ

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

7.1 Идентификатор контекста уровня представления

В реализации, соответствующей протоколу, идентификаторы контекста уровня представления должны кодироваться от 0 до 32767.

7.2 Имя синтаксиса передачи в списке ЗДП

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

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

7.3 Кодирование данных уровня представления

Полностью закодированные данные, т.е. последовательности ЗДП, в одном и том же контексте уровня представления (например сгруппированные ПБД ПДУФ) должны кодироваться либо в виде простого списка ЗДП (используя вариант пооктетного выравнивания), либо в виде последовательности списка ЗДП, каждое из которых закодировано в виде либо одного ЗДП (используя вариант типа простого АСН.1), либо нескольких ЗДП (используя вариант пооктетного выравнивания).

Принимающие стороны должны воспринимать любой из перечисленных выше кодов.

7.4 Параметр "данные пользователя"

Этот параметр ПБДП должен содержать ответный ПБД "П-АССОЦИАЦИЯ", если отсутствует параметр "причина поставщика".

7.5 Кодирование значения тип-СРС

Реализации не должны использовать в параметре "данные пользователя УСнУ" примитива СН-СОЕДИНЕНИЕзапрос никаких значений типа СРС, если только для одного контекста представления ЗДП не предложено более одного синтаксиса передачи. Каждый тип СРС представляет уникальный синтаксис передачи, так что если предложено более одного синтаксиса передачи, то значения типа СРС могут появляться в параметре "данные пользователя УСнУ".

Для того контекста уровня представления, в котором предложенным синтаксисом передачи являются базовые правила кодирования, все ЗДП в параметре "данные пользователя" ПБДП КП должны быть сначала закодированы с использованием базовых правил кодирования и должны анализироваться принимающим протокольным автоматом, затем могут быть проанализированы значения типа СРС, либо они могут быть проигнорированы по усмотрению принимающей стороны (см. ГОСТ 34.972, 6.2.5.3).

7.6 Список результатов определения контекста представления

Параметр "список-результатов-определения-контекста представления" требуется в том случае, если параметр "причина-поставщика" отсутствует в ПБДП.

Отсутствие этого факультативного параметра ПБДП не предполагает никакой семантики.

7.7 ПБДП "повторная синхронизация"

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

7.8 Недействительное кодирование.

Если полученный ПБДП содержит какие-либо неправильно закодированные значения данных (включая значения, содержащиеся в поле "данные пользователя" ПБДП) и выдано прерывание, то должен быть передан либо ARU, либо ARP.

8 СИНТАКСИС ПЕРЕДАЧИ

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

8.1 Поля "длина" АСН.1

Максимальное значение компонента "октеты длины" АСН.1, которое должно обрабатываться реализацией, соответствующей настоящему стандарту, должно равняться 4 294 967 295. Это максимальное абсолютное значение целого числа, которое может быть представлено в 32 битах. Следовательно, код октетов длины может занимать максимум 5 октетов.

Примечание - Это требование не относится к коду бесконечной длины.

8.2 Значения типа целого

При любом значении типа ЦЕЛОЕ АСН.1, определенном в абстрактных синтаксисах ПДУФ, СЭУА и уровня представления, передатчик не должен кодировать значения, превышающие 2**31-1 или меньшие, чем -2**31. Приемник должен быть способен декодировать значения, которые, по меньшей мере, находятся в диапазоне от -2**31 до 2**31-1.

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

Атрибуты ПДУФ

размерфайла

будущий-размерфайла

ф-ВОССТАНОВЛЕНИЕзапрос

номер-передачи-массивов-данных

Идентификатор БДДФ

номер БДДФ

могут быть закодированы передатчиком в диапазоне от -2**63 до 2**63-1. В подобных случаях сторона может отклонить соответствующий ПБД ПДУФ.

При любом типе ЦЕЛОЕ АСН.1, определенном в других абстрактных синтаксисах (см. ГОСТ Р ИСО/МЭК МФС 10607-2), передатчик не должен кодировать значений, превышающих 2**31-1 или меньших, чем -2**31. Принимающая сторона должна быть способна декодировать значения, которые, по меньшей мере, находятся в диапазоне от -2**31 до 2**31-1 или в некотором другом диапазоне, определенном в ГОСТ Р ИСО/МЭК МФС 10607-2.

Примечание - Чтобы гарантировать взаимодействие, кодируемые значения должны быть ограничены диапазоном от 2**31 до 2**31-1.

8.3 Значения типа "строка бит"

Если в базовом стандарте не оговорено иное, то каждый бит, поименованный в типе СТРОКА БИТ, используемом в определениях абстрактных синтаксисов уровня представления, СЭУА, ПУИ ПДУФ и БДДФ ПДУФ, должен быть явно закодирован в соответствующее значение СТРОКА БИТ даже в том случае, если он является частью строки концевых нулевых бит.

Неиспользуемые биты, не входящие в точное число бит, соответствующих полному списку специфицированных поименованных бит, никогда не должны кодироваться. Это правило применимо ко всем типам СТРОКА БИТ, если только в определении абстрактного синтаксиса не оговорено иное.

8.4 Тип "внешние данные"

8.4.1 Если значение данных, которое должно быть скомпоновано в типе ВНЕШНИЙ, является экземпляром простого типа АСН.1, закодированного в соответствии с базовыми правилами кодирования АСН.1, то в качестве его кода должна быть выбрана факультативная возможность "простой-тип-АСН.1".

8.4.2 Если значение данных, которое должно быть скомпоновано в типе ВНЕШНИЙ, является целым числом октетов, а условия 8.4.1 неприменимы, то в качестве его кода должна быть выбрана факультативная возможность "выравнено-по-октетам".

8.4.3 Всегда остается в силе соглашение по правилам кодирования на уровне представления.

8.5 Структура кода

При кодировании БДДФ, ПБДАс и ПБДПр применимо следующее правило.

Содержимое октетов сформированного кода значения СТРОКА БИТ, СТРОКА ОКТЕТОВ или строка знаков состоит из полного кода одного, нескольких или ни одного значения данных, и код этих значений данных должен быть очень простым.

9 СЕАНСОВЫЙ УРОВЕНЬ

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

9.1 Версия сеансового протокола

Для использования данных пользователя неограниченного размера должна использоваться версия 2 сеансового протокола в соответствии с дополнением 2 к ИСО 8327.

9.2 Расширенное сцепление

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

9.3 Сегментация сеанса

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

9.4 Младшая синхронизация

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

9.5 Повторная синхронизация

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

Примечание - Обеспечение функционального модуля "повторная синхронизация сеанса" требуется только в соответствии с требованиями 9.5. Однако этот функциональный модуль должен всегда реализовываться при необходимости преобразования Ф-АННУЛИРОВАНИЕ ПДУФ в Пр-ПОВТОРНАЯ СИНХРОНИЗАЦИЯ (отказ).

9.6 Повторное использование соединения транспортного уровня

Повторного использования соединение транспортного уровня не требуется. Если оно реализовано, должен быть обеспечен параметр "разъединение" соединения транспортного уровня ПБДСн ОТКЛОНЕНИЕ или ОКОНЧАНИЕ.

9.7. Использование срочных услуг транспортного уровня

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

Примечание - Это средство должно запрашиваться и использоваться.

9.8 Получение недействительных ПБДСн

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

ПРИЛОЖЕНИЕ А (обязательное). СПИСОК ТРЕБОВАНИЙ ЗСФС ДЛЯ ПРОТОКОЛОВ СЭУА УРОВНЯ ПРЕДСТАВЛЕНИЯ И СЕАНСОВОГО УРОВНЯ

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

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

В таблицах A.1-А.3 приведены сводные перечни характеристик протоколов СЭУА уровня представления и сеансового уровня в соответствии с требованиями ПДУФ ГОСТ Р ИСО/МЭК МФС 10607. Степень обеспечения каждой функциональной возможности указанных протоколов определена в таблицах A.1-А.3 с использованием понятий, определенных в 3.2.

В заголовках таблиц A.1-А.3 использованы следующие сокращения:

Д - требования к соответствию, определенные в базовом стандарте.

Р - требования к соответствию, определенные в настоящем стандарте.

Если в таблицах A.1-А.3 степень обеспечения определена двумя значениями, разделенными пробелом, то левое значение относится к роли инициатора в данной реализации, а правое - к роли ответчика в данной реализации.

A.1 Сервисный элемент управления ассоциацией


Таблица A.1 - Протокол сервисного элемента управления ассоциацией

A.2 Уровень представления


Таблица A.2 - Протокол уровня представления

А.3 Сеансовый уровень


Таблица А.3 - Протокол сеансового уровня

ПРИЛОЖЕНИЕ В (обязательное). ИЗМЕНЕНИЯ И ПОПРАВКИ

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

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

СЭУА

ИСО 8650/Поп.1:1990

Примечание - Данные документы могут быть получены в техническом комитете по стандартизации "Информационная технология" (ТК 22).



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