---

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

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

<скорость данных (Мбит/с) > <тип физичесюой среды> <>максималыная длина сегмента (ХЮО м)>.

Например, настоящий стандарт содержит спецификацию сис­темы «ТИП 10BASE5» основной полосы частот на 10 Мбит/с с физической средой максимальной длины сегмента 500 м. Каждая последующая спецификация физического уровня будет подобным образом устанавливать свой собственный уникальный идентифи­катор ТИП.

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

ГОСТ 24402 «Системы обработки информации. Телеобработка данных и вычислительные сети. Термины и определения».

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

ИСО 2382/25¹ «Системы обработки информации. Локальные вычислительные сети. Термины и определения».

ИСО 7498—2* «Системы обработки информации. Соединение открытых систем. Эталонная (справочная) модель. Часть 2. Ар­хитектура защиты».

Публикация МЭК 96—1 (1971)* (3-я редакция) «Радиочастот­ные кабели. Часть 1. Общие требования к методам измерений».

Публикация МЭК 96—1 (1976)*, 1-е дополнение «Радиочас­тотные кабели. Часть 1. Приложение к разд. 5.4. Завершающий трехосевой метод проверки переходного импеданса частотой до 100 МГц».

Публикация МЭК 169—8* и 169—16* «Соединители радио­частотного коаксиального кабеля с винтовым соединением, 50 Ом (тип BNC и тип N)».

Публикация МЭК 380 (1985)* (3-я редакция) «Безопасность электроэнергетических учрежденческих установок».

Публикация МЭК 435 (1983)* (2-я редакция) «Безопасность оборудования обработки данных».

Публикация МЭК 807—2 (1985)* (1-я редакция) «Подробная спецификация набора соединителей с контактами кругового сече­ния фиксирующей спайки».

Публикация МЭК 950 (1986)* «Безопасность оборудования информационной технологии, включая электрическое промышлен­ное оборудование».

Используемые в настоящем стандарте определения соответст­вуют ГОСТ 24402 и ГОСТ 28907 (ИСО 8802—2). Более специ- -фичный для терминологии ЛВС проект государственного стан- .дар.та на основе международного стандарта ИСО 2382/25 нахо­дится в стадии разработки.

2. СПЕЦИФИКАЦИЯ УСЛУГ ПОДУРОВНЯ УДС

   1. Назначение и область применения

В данном разделе определяются услуги, предоставляемые подуровнем УДС подуровню УЛЗ (см. черт. 2.1). Эти услуги опи­сываются абстрактным образом и не предполагают никакой кон­кретной реализации или каких-либо конкретных интерфейсов. Между примитивами, формализованными процедурами и интер­фейсами, описываемыми в пп. 4.2 и 4.3, нс обязательно должно существовать однозначное соответствие.

ОТНОШЕНИЕ СПЕЦИФИКАЦИИ УСЛУГ К МОДЕЛИ ЛВС

Уровни эталонной модели ВОС

Уровни ЛВС КДОН/ОК

ИМС — интерфейс с модулем сопряжения; МСС — модуль сопряжения со средой; ИЗС — ин­терфейс, зависимый от среды; МДС — модуль дос­тупа к среде; ООД — оконечное оборудование дан­ных; УЛЗ — управление логическим звеном; УДС — управление доступам к среде; ПФС — передача фи­зических сигналов

Черт. 2.1

Услуги, обеспечиваемые подуровнем УДС, позволяют логи­ческому объекту подуровня УЛЗ обмениваться блоками данных с равноправными логическими объектами подуровня УЛЗ. Могут быть предусмотрены факультативные средства для установления логического объекта подуровня УДС в известное состояние.

Модель, используемая в этой спецификации услуг, аналогич­на модели, описанной в п. 1.2.

УД-ДАННЫЕ. запрос

УД-ДАННЫЕ. индикация

Рассматриваемые в данном разделе сервисные примитивы УД-ДАННЫЕ. запрос и УД-ДАННЫЕ. индикация являются обя­зательными.

Этот примитив определяет передачу данных из локального логического объекта подуровня УЛЗ одному .(или нескольким в случае групповой адресации) равноуровневому(ым) логическо­му (ким) объекту(ам) УЛЗ.

адрес-получателя, уд-ебд, класс-обслуживания )

Параметр «адрес-получателя» может определять либо индиви­дуальный, либо групповой адрес логического объекта УДС. Он должен содержать информацию, достаточную для формирования поля АП, которое присоединяется к кадру локальным логическим объектом подуровня УДС, и любую другую информацию физи­ческого уровня. Параметр «уд-ебд» определяет сервисный блок данных УДС, подлежащий передаче логическим объектом под­уровня УДС. В параметре «уд-ебд» содержится достаточно ин­формации для того, чтобы логический объект подуровня УДС мог определить длину блока данных. Параметр «класс-обслужи- ванпя» указывает качество услуг, запрошенное подуровнем УЛЗ пли более высоким уровнем (см. п. 2.3.1.5).

Этот примитив генерируется логическим объектом подуровня УЛЗ всякий раз, когда данные должны быть переданы равно­правному логическому объекту (пли объектам) УЛЗ. Он может выдаваться в ответ на запрос протоколов вышерасположенных уровней, либо вырабатываться на основе данных, генерируемых внутри подуровня УЛЗ, подобных тем, которые требуются услу­гами типа 2.

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

мГОСТ 34.913.3—91 С. И сформированный кадр протоколам нижераслоложенных уровней для его передачи равноправному логическому объекту (или объектам) подуровня УДС.

Протокол УДС КДОН/ОК обеспечивает простое качество услуг независимо от запрошенного класса услуг.

Этот примитив определяет передачу данных из логического объекта подуровня УДС одному (или нескольким в случае груп­повой адресации) логическому(им) объекту(ам) подуровня УЛЗ.

Семантика данного примитива имеет следующий вид:

УД-ДАННЫЕ. индикация (

адрес-получателя, адрес-отправителя, уд-ебд, состоявие-приема )

Параметр «адрес-получателя» может быть либо индивидуаль­ным, либо групповым адресом, как определено полем АП посту­пившего кадра. Параметр «адрес-отправителя» является индиви­дуальным адресом, как это определено полем АО поступившего кадра. Параметр «уд-ебд» определяет сервисный блок данных УДС в том виде, в котором он принят локальным логическим объектом УДС. Параметр «состояние-приема» используется для передачи информации о состоянии равноправному логическо­му объекту подуровня УЛЗ.

Примитив УД-ДАННЫЕ. индикация передается из логического объекта подуровня УДС логическому объекту (или объектам) подуровня УЛЗ для информирования о поступлении кадра в ло­кальный логический объект подуровня УДС. О таких кадрах сооб­щается только в том случае, если они правильно оформлены, приняты без ошибок, а их адрес получателя определяет данный локальный логический объект УДС.

Результат приема примитива подуровнем УЛЗ нс определен.

Если локальный логический объект подуровня УДС определен параметром «адрес-получателя» примитива УД_ДАННЫЕ. запрос, то примитив индикации будет также привлекаться этим логическим объектом УДС для локального логического объекта УЛЗ. Это дуплексное свойство подуровня УДС может быть обусловлено уникальными функциональными возможностями подуровня УДС или дуплексными свойствами нижераслоложенных уровней (нап­ример все кадры, переданные по глобальному адресу, будут привлекать примитив УД-ДАННЫЕ. индикация па всех станциях сети, включая станцию, которая сгенерировала запрос).

2. СТРУКТУРА КАДРА УПРАВЛЕНИЯ ДОСТУПОМ К СРЕДЕ

   1. Краткое описание

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

Формат кадра УДС

? ок 1Є1О8

? ИЛИ б ОКАТОВ

Адрес логучггелл

7 или G о* теток

Адрес отправителя

Черт. 3.1

Контрольная последовательность кадра

Длина

Данные УЛЗ

Заполнитель

НОК — начальный ограни­читель кадра; £>МЗ — бит младшей значимости; БСЗ — бит старшей значимости

На черт. 3.1 показано восемь полей кадра: преамбула; на­чальный ограничитель кадра (НОК); адреса отправителя и полу­чателя кадра; поле длины, указывающее длину следующего за ним поля, которое содержит данные УЛЗ, подлежащие переда

­

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

Минимальный и максимальный пределы длины кадра в и. 4.4 относятся к той части кадра, которая начинается с поля «адрес получателя» и кончается полем «контрольная последовательность кадра» включительно.

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

Поле «преамбула» содержит 7 октетов и используется для то­го, чтобы дать возможность схемам ПФС прийти в устойчивый синхронизм с принимаемыми тактовыми сигналами кадра (см. .п. 4.2.5).

Поле НОД имеет битовую комбинацию 10101011. Оно следует непосредственно за комбинацией преамбулы и указывает начало кадра.

Формат поля адреса

4

16-битоиый формат адреса

4&бию8ый адрес

8-битовыи Фог-мат адреса

И/Г = 0 — индивидуальный адрес; И!Г= — групповой адрес: Г/Л = 0 — глобально администрируемый адрес; Г!Л=—локально адми­нистрируемый адрес

Черт. 3.2

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