Часть 2 (начало см.: Сети 1997 #10)


Коммутируемые виртуальные каналы
Фаза установления соединения
Фаза разъединения
Информационные элементы сообщения

Современный стандарт frame relay (FR) описывает протокол и интерфейс "пользователь-сеть" (ИПС) только для постоянных виртуальных каналов (ПВК), поэтому в основном используется в сетях со статическими методами и способами маршрутизации информационных потоков. Вместе с тем при создании глобальной широкополосной FR-сети, в которой будут применяться коммутируемые виртуальные каналы (КВК) и динамическое управление потоками информации, возникает необходимость объединения существующих корпоративных и локальных FR-сетей. Такая интеграция требует единого подхода к "философии" функционирования КВК и разработке стандарта интерфейса "сеть-сеть" (ИСС). В настоящее время разработкой и исследованием этого стандарта активно занимаются консорциум Frame Relay Forum (FRF), Американский национальный институт стандартизации (ANSI) и Международный союз электросвязи (МСЭ). Первый проект стандарта на ИСС был выработан FRF в конце 1992 г.

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

Picture 1. (1x1)

Рисунок 1.
Области применения ИСС

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

Picture 2.

Рисунок 2.
Многосетевой ПВК состоит из "отрезков"

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

Picture 3. (1x1)

Рисунок 3.
Процедуры в ИСС

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

Для нормального функционирования процедур управления в ИСС используются те же параметры синхронизации, что и для LMI (ряд специальных счетчиков событий и времени, назначение которых - синхронизация последовательностей управляющей информации через интерфейсы N391, N392, N393, T391 и T392). Очевидно, что текущие значения отдельных таймеров и счетчиков с каждой стороны ИСС будут различны. Однако проект стандарта FRF на ИСС строго оговаривает, что предельные (пороговые) значения таймеров и счетчиков на обеих сторонах ИСС должны быть одинаковыми.

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

МПВК считается активным при условии, что все отрезки ПВК между двумя ИПС активны. Для этого необходимо, чтобы:

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

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

Picture 4. (1x1)

Рисунок 4.
Процедуры установления МПВК через один ИСС

ООД пользователя А (ООД А) подключено к АКД сети Х (АКД Х) через ИПС, в котором номер ПВК - DLCI 20. Далее СУС соединяет этот отрезок ПВК (сеть Х, для достижения ООД абонента В) с ИСС, в котором номер ПВК - DLCI 99. Заметим, что сеть Х не обладает точной информацией о нахождении пользователя В (ООД В), за исключением DLCI 99 в ИСС. Спустя некоторое время СУС соединяет ООД абонента В и АКД сети Y через ИПС (локальный DLCI 40) и организует отрезок ПВК (сеть Y) между ИПС и ИСС (DLCI 99).

Очевидно, что во время установления соединения между ООД пользователей А и В внутри ИПС и ИСС происходит постоянный обмен сообщениями "Запрос состояния". Рассмотрим более подробно эти процедуры (см. рис. 4).

ПВК между ООД В и АКД Yп не сконфигурирован.

ИПСх. В ответ на первый "Запрос состояния" ООД А получает от АКД Хп (АКД сети Х со стороны ООД А) ответ "Полное состояние", в котором ПВК имеет DLCI 20, является "новым" и неактивным. На второй запрос также будет получен ответ, что ПВК неактивен. Однако в этом случае АКД Хп не покажет, что ПВК "новый" (DLCI 20), так как ООД А подтвердило в своем втором запросе наличие "нового" ПВК (путем установки бита "новый ПВК" в "1").

ИСС. АКД Yс (АКД сети Y со стороны АКД Х) на свой первый "Запрос состояния" получает от АКД Хс (АКД сети Х со стороны АКД Y) ответ "Полное состояние", в котором указывается, что cконфигурирован новый ПВК (отрезок ПВК), имеющий DLCI 99 и являющийся активным "внутри" сети Х. Ввиду того, что в ИСС используются асинхронные двунаправленные процедуры управления, АКД Хс также посылает АКД Yс "Запрос состояния", в ответе на который ("Полное состояние") не указываются никакие новые ПВК (за исключением ранее установленных). Причем это продолжится до тех пор, пока отрезок ПВК (сеть Y) не будет сконфигурирован. АКД Хс на последующие запросы АКД Yс будет по-прежнему отвечать сообщениями "Полное состояние", в которых указывается, что внутри сети Х имеет место "активный" ПВК (DLCI 99). Однако данный ПВК не будет идентифицироваться как новый.

ПВК между ООД В и АКД Yп сконфигурирован.

ИПСy. АКД Yп (АКД сети Y со стороны ООД В), получив первый "Запрос состояния", отвечает сообщением "Полное состояние". В нем указывается, что имеет место "новый" активный ПВК (DLCI 40), являющийся последним отрезком МПВК. Следовательно, МПВК сконфигурирован.

ИСС. АКД Yс на следующий "Запрос состояния" от АКД Хс посылает ответ "Полное состояние", в котором указывается, что имеет место "новый" активный ПВК (DLCI 99).

ИПСх. АКД Хп на последний "Запрос состояния" от ООД А отвечает сообщением "Полное состояние", в котором ПВК (DLCI 20) активен.

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

Существует несколько причин сбоя МПВК: сбой в ИПС, сбой в ИСС и сбой в отрезке ПВК. В каждом случае ответственным за передачу сообщений "Полное состояние", в которых указывается неактивное состояние ПВК, является ИСС. Это позволяет временно прекращать передачу данных через ИПС до тех пор, пока ПВК не будет реконфигурирован. Если имеет место сбой в ИСС, то это вызывает сбой механизма синхронизации, что незамедлительно обнаруживает ООД пользователей.

Коммутируемые виртуальные каналы

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

Для цифровых сетей с интеграцией услуг был принят только один стандарт (рекомендация МСЭ Q.933), который описывает системы сигнализации для служб ретрансляции кадров. FRF согласился лишь с тем, что указанная рекомендация будет служить основой для будущего стандарта на использование КВК. Однако она посвящена лишь логической и процедурной характеристикам протокола FR для КВК в любых FR-сетях (не обязательно в цифровых сетях с интеграцией услуг).

Все управляющие сообщения, используемые при установлении и разъединении КВК и передаче сообщения, передаются по общему каналу сигнализации, для которого в ИПС выделен канал с DLCI=0. (Это вполне согласуется с концепцией FR, согласно которой процедуры сигнализации осуществляются по выделенному каналу.) Данные сообщения аналогичны кадру LMI. На рис. 5 представлен основной формат кадра, применяемый при конфигурации КВК (далее - кадр КВК).

  8 7 6 5 4 3 2 1 Назначение
1 0 1 1 1 1 1 1 0 Флаг
2 0 0 0 0 0 0 0 0 Заголовок: DLCI=0, CR=0, DE=0, FECN=0, BECN=0
3 0 0 0 0 0 0 0 1
4 0 0 0 0 0 0 1 1 Индикатор ненумерованного кадра
5 0 0 0 0 1 0 0 1 Определитель протокола
6 0 0 0 0   Вызываемый номер
7    
8   Тип сообщения
9   Первый информационный элемент
10  
11  
12  
13  
14  
15   Второй информационный элемент
16  
17  
18  
19  
20  
. . . . . . . . .
    N-й информационный элемент
    Проверочная последовательность
  0 1 1 1 1 1 1 0 Флаг

Рисунок 5.
Базовый формат кадра КВК

Поля, используемые в кадре КВК, идентичны полям кадра LMI-процедур - за исключением полей "Вызываемый номер", "Тип сообщения" и "Информационные элементы".

"Вызываемый номер". Это поле является локальным идентификатором, который предназначен для распознавания различных вызовов в локальном интерфейсе. Оно не имеет смысла при установлении межтерминального соединения. Длина поля может составлять 2 или 3 октета и зависит от требуемого количества индивидуальных каналов.

Формат 2-октетного поля, наиболее приемлемого в сетях FR, показан на рис. 6. Первый октет указывает на длину вызываемого номера (1 или 2 октета), а второй содержит значение вызываемого номера и "флаг". Главное назначение "флага" - определение стороны интерфейса: инициатор установления соединения получает флаг "0", вызываемая сторона "1". Таким образом, исключена одинаковая установка этого бита обеими сторонами интерфейса. Поле "Вызываемый номер" может иметь длину 3 октета - как правило, в том случае, когда требуется 7...15 битов для идентификации большого числа (>64) КВК в высокоскоростных ИСС (более 8 Мбит/с). Уникальное значение вызываемого номера определяется инициатором вызова, когда передается сообщение на установление соединения.

ОктетеыБиты 8 7 6 5 4 3 2 1
1 0 0 0 0 0 0 0 1
    Длина вызываемого номера
2 Флаг Значение вызываемого номера

Рисунок 6.
Кодирование поля "Вызываемый номер"

"Тип сообщения". При создании, разъединении КВК и в фазе передачи данных используются 7 типов сообщений (Q.933), которые представлены на рис.7.

Тип сообщения 8 7 6 5 4 3 2 1
Сообщения для установления соединения (КВК) 0 0 0 - - - - -
Подтверждение вызова соединения (КВК)   0 0 0 1 0
  0 0 1 1 1
Установка параметров   0 0 1 0 1
Сообщения для разъединения (КВК) 0 1 0 - - - - -
Запрос разъединения   0 0 1 0 1
Согласие на разъединение   0 1 1 0 1
Подтверждение разъединения   0 1 0 1 0
Смешанные сообщения 0 1 1 - - - - -
Состояние   1 1 1 0 1
Запрос состояния   1 0 1 0 1

Рисунок 7.
Кодирование поля "Тип сообщения"

"Информационные элементы". Информационные элементы для создания и разъединения КВК изменяются в соответствии с фазой информационного обмена. Рассмотрим эти фазы.

Фаза установления соединения

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

Picture 8.

Рисунок 8.
Последовательность передачи сообщений при установлении соединения (конфигурации КВК)

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

Информационный элемент Режим передачи Тип элемента Максимальный размер (октеты)
Тип сообщения "Установка параметров" Дуплексный Обязательный 1
Пропускная способность Дуплексный Обязательный 5
Идентификатор канала передачи данных (DLCI) Дуплексный Необязательный 4
Параметры канального уровня (ЭМВОС) Дуплексный Необязательный 14
Подадрес вызывающей стороны Дуплексный Необязательный 23
Адрес вызываемой стороны Дуплексный Обязательный -
Подадрес вызываемой стороны Дуплексный Необязательный 23
Совместимость нижнего уровня Дуплексный Необязательный 16

Рисунок 9.
Информационные элементы, входящие в сообщение "Установка параметров"

Подтверждение вызова и соединения. В ответ на сообщение "Установка параметров" АКД ответит сообщением "Подтверждение вызова", в котором подтвердит наличие соединения и укажет на то, что требуемые параметры при установлении соединения обеспечены. На рис. 10 представлены информационные элементы, входящие в сообщение "Подтверждение вызова". Последнее включает в себя DLCI, который указывает номер КВК, входящий в информационный элемент сообщения "Установка параметров" (см. рис. 2 во врезке). Однако значение DLCI может не соответствовать значению DLCI, указанному в информационном элементе сообщения "Установка параметров".

Информационный элемент Режим передачи Тип элемента Максимальный размер (октеты)
Тип сообщения "Подтверждение вызова" Дуплексный Обязательный 1
DLCI Дуплексный Необязательный 4

Рисунок 10.
Информационные элементы, входящие в сообщение "Подтверждение вызова"

Финальным сообщением фазы установления соединения является "Подтверждение соединения". Это сообщение передается как от ООД вызываемого абонента в направлении АКД, так и от АКД в направлении ООД вызывающего пользователя. На рис. 11 представлены информационные элементы, входящие в сообщение "Подтверждение соединения". Последнее включает в себя DLCI, который указывает номер КВК входящий в информационные элементы сообщений "Установка параметров", "Подтверждение вызова" (см. рис. 2 во врезке).

Информационный элемент Режим передачи Тип элемента Максимальный размер (октеты)
Тип сообщения "Подтверждение соединения" Дуплексный Обязательный 1
DLCI Дуплексный Необязательный 4

Рисунок 11.
Информационные элементы, входящие в сообщение "Подтверждение соединения"

Рассмотренная фаза установления соединения является "удачной процедурой вызова". Рекомендация МСЭ Q.933 содержит также описание ошибочных ситуаций и действия при их возникновении.

Фаза разъединения

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

Picture 12.

Рисунок 12.
Последовательность передачи сообщений при разъединении

В фазе разъединения используются три сообщения: "Запрос разъединения", "Согласие на разъединение" и "Подтверждение разъединения".

Информационный элемент Режим передачи Тип элемента Максимальный размер (октеты)
Тип сообщения "Запрос разъединения" Дуплексный Обязательный 1
Причина разъединения Дуплексный Обязательный 4...32

Рисунок 13.
Информационные элементы, входящие в сообщение "Запрос разъединения

Сообщение "Запрос разъединения" может быть передано либо ООД в направлении АКД с требованием разъединения КВК, либо от АКД для индикации начала процедуры разъединения. Это сообщение содержит только один информационный элемент "Причина разъединения", формат заголовка которого показан на рис. 13. Данный элемент предназначен лишь для указания причины разъединения. Кодирование полей информационного элемента "Причина разъединения" представлено на рис. 14.

8 7 6 5 4 3 2 1 Октеты
0 0 0 1 1 0 0 1
1
  Идентификатор информационного элемента "Причина разъединения"
Размер информационного элемента "Причина разъединения" 2
0/1
Бит расшир.
0 0 0 Местонахождение непосредственного инициатора разъединения 3
Стандарт кодирования Резерв
1
Расш.
Код причины разъединения 4

Рисунок 14.
Информационный элемент "Причина разъединения""

Параметры, содержащиеся в информационном элементе:

  • стандарт кодирования;
  • местонахождение непосредственного инициатора разъединения. Это поле имеет следующую кодировку: "0001" - местный пользователь, обслуживаемый частной FR-сетью, "0010" - местный пользователь, обслуживаемый FR-сетью общего пользования, "0011" - транзитная FR-сеть, "0101" - удаленный пользователь, обслуживаемый частной FR-сетью, "0100" - удаленный пользователь, обслуживаемый FR-сетью общего пользования, "0001" - международная сеть;
  • код причины разъединения. Возможные причины разъединения стандартизированы в рекомендациях МСЭ Q.933 и Q.931 и имеют свое уникальное кодирование. Кодовая комбинация "16" означает нормальное разъединение. Необходимо заметить, что для указания причины разъединения не рекомендуется использовать кодовую комбинацию "00000000", чтобы исключить возможные конфликтные ситуации.

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

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

Информационный элемент Режим передачи Тип элемента Максимальный размер (октеты)
Типы сообщения "Согласие на разъединение" и "Подтверждение разъединения" Дуплексный Обязательный 1
Причина разъединения Дуплексный Обязательный 4...32

Рисунок 15.
Информационные элементы, входящие в сообщения "Согласие на разъединение" и "Подтверждение разъединения"

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


Информационные элементы сообщения

Обязательные элементы

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

8 7 6 5 4 3 2 1 Октеты
0 0 0 0 0 1 0 0 1
Идентификатор информационного элемента "Пропускная способность"
Размер информационного элемента "Пропускная способность" 2
1
Бит
расшир.
0 0 0 1 0 0 0 3
Стандарт кодирования (МСЭ) Потенциальные возможности доставки сообщений
1
Бит расшир.
0 1 0 0 0 0 0 4
Режим доставки Зарезервировано
1
Бит расшир.
1 0 0 1 1 1 1 5
Идентификатор канального уровня (ЭМВОС) Характеристика информации пользователя

Рисунок 1.
Формат информационного элемента "Пропускная способность"

На рис. 1 представлен формат информационного элемента "Пропускная способность". Поля внутри формата фиксированны и означают:

  • вид кодирования;
  • любая информация в цифровой форме (потенциальные возможности доставки сообщений);
  • режим доставки;
  • характеристика информации пользователя.

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

Идентификатор канала передачи данных (DLCI). Этот информационный элемент является обязательным в направлении сеть-пользователь и необязательным в обратном направлении. Он определяет DLCI КВК, который будет использоваться в локальном интерфейсе. Если инициатором соединения является АКД (т. е. последняя посылает сообщение "Установка параметров"), этот элемент всегда содержит DLCI, выбранный при установлении соединения. И наоборот, если инициатор соединения - ООД (т. е. последнее посылает сообщение "Установка параметров"), то этот элемент необязателен до тех пор, пока ООД не затребует значение DLCI, используемого при информационном обмене.

Формат этого элемента представлен на рис. 2 (для 2-октетного адресного поля). Необходимо отметить, что DLCI, размещаемый в стандартном поле данного элемента, является локальным и имеет смысл только для конкретной FR-сети. Бит "уникальный флаг" всегда устанавливается в "0". Если АКД не способна по каким-либо причинам указать конкретное значение DLCI для требуемого канала, то она будет указывать другое (приемлемое для нее) значение DLCI. Бит "расширения" также применяется для индикации окончания адресного поля и будет использоваться таким же образом (т. е. как маркер расширения адреса) в заголовке кадра.

8 7 6 5 4 3 2 1 Октеты
0 0 0 1 1 0 0 1 1
Идентификатор информационного элемента "DLCI"
Размер информационного элемента "DLCI " 2
0
Бит
расшир.
0
Уник.
флаг
DLCI (первые 6 битов) 3
1
Бит
расшир.
DLCI (последние 4 бита) Зарезервировано 4

Рисунок 2.
Формат информационного элемента "DLCI"

Необязательные элементы

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

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

  • максимальный размер поля информации в кадре FR (в октетах);
  • пропускная способность. Единица измерения данного параметра - бит/с. Пропускная способность является составной величиной и включает в себя "размерность" (100...106) и целочисленный "множитель". Например, 64 кбит/с будут иметь вид 3/64 ("размерность"/"множитель"), что означает 64х103;
  • гарантированный объем информации, подлежащей передаче/приему. Этот параметр определяет максимальный объем данных (в октетах), который согласовывают между собой ООД и АКД (при нормальном функционировании канала) для доставки в каждом направлении за определенный временной интервал;
  • дополнительный объем информации, подлежащей передаче/приему. Этот параметр определяет максимальный дополнительный объем данных (в октетах), который сеть будет "пытаться" доставить в каждом направлении за определенный интервал времени. Во всех кадрах, превышающих гарантированный объем, но меньших дополнительного объема, бит DE может быть установлен АКД в "1".

8 7 6 5 4 3 2 1 Октеты
0 1 0 0 1 0 0 0 1
Идентификатор информационного элемента "Параметры канального уровня"
Размер информационного элемента "Параметры канального уровня" 2
0 0 0 0 1 0 0 1 3
Расшир. Поле идентификатора "Максимальный размер поля информации в кадре FR"
0
Расшир.
Максимальный размер поля информации в передаваемом кадре FR (направление АКД-ООД) 4
0/1
Расшир.
Продолжение максимального размера поля информации в передаваемом кадре FR (направление АКД-ООД) 5
0
Расшир.
Максимальный размер поля информации в принимаемом кадре FR (направление АКД-ООД) 6
1
Расшир.
Продолжение максимального размера поля информации в принимаемом кадре FR (направление АКД-ООД) 7
0 0 0 0 1 0 1 0 8
Расшир. Поле идентификатора "Пропускная способность"
0
Расшир.
Размерность величины пропускной способности (ВПС) при передаче информации Значение множителя ВПС при передаче информации 9
0/1
Расшир.
Продолжение значения множителя ВПС при передаче информации 10
0
Расшир.
Размерность ВПС при приеме информации Значение множителя ВПС при приеме информации 11
1
Расшир.
Продолжение значения множителя ВПС при приеме информации 12
0 0 0 0 1 1 0 1 13
Расшир. Поле идентификатора "Гарантированный объем информации, подлежащей передаче/приему"
0
Расшир.
Величина гарантированного объема информации, подлежащей передаче 14
0/1
Расшир.
Продолжение величины гарантированного объема информации, подлежащей передаче 15
0
Расшир.
Величина гарантированного объема информации, подлежащей приему 16
1
Расшир.
Продолжение величины гарантированного объема информации,
подлежащей приему
17
0 0 0 0 1 1 1 0 18
Расшир. Поле идентификатора "Дополнительный объем информации, подлежащей передаче/приему"
0
Расшир.
Величина дополнительного объема информации, подлежащей передаче 19
0/1
Расшир.
Продолжение величины дополнительного объема информации, подлежащей передаче 20
0
Расшир.
Величина дополнительного объема информации, подлежащей приему 21
1
Расшир.
Продолжение величины дополнительного объема информации, подлежащей приему 22

Рисунок 3.
Формат информационного элемента "Параметры канального уровня"

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

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

На рис. 4 представлен формат информационного элемента "Подадрес вызывающей стороны". Параметры, входящие в этот информационный элемент:

  • тип подадреса, который определяет либо тип используемой адресации "000", либо специфический адрес пользователя "010";
  • вид кодирования адреса, который устанавливает вид представления (двоичное или четверичное) адреса, имеющего десятичную форму;
  • значение подадреса (максимум 20 октетов).

8 7 6 5 4 3 2 1 Октеты
0 1 1 0 1 1 0 1  
Идентификатор информационного элемента "Подадрес вызывающей стороны" 1

Поделитесь материалом с коллегами и друзьями





Похожие статьи


Президент Violin: компания возвращается

Глава компании — о ее финансовом оздоровлении, текущей ситуации, ближайших шагах на российском рынке и конкуренции