Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Урок03

.pdf
Скачиваний:
4
Добавлен:
21.02.2016
Размер:
668.81 Кб
Скачать

бит уведомления (сигнализации) источника о явной перегрузке (Backward Explicit Congestion Notification — BECN) устанавливается в “1” для уведомления источника сообщения о том, что произошла перегрузка в направлении, обратном направлению передачи содержащего этот бит кадра. Бит BECN устанавливается АКД (а не ООД) и может не использоваться терминалами абонентов;

бит разрешения сброса (Discard Eligibility —DE) устанавливается в “1” в случае явной перегрузки и указывает на то, что данный кадр может быть уничтожен в первую очередь. Бит DE устанавливает либо АКД, либо ООД (т. е. пользователю предоставлено право выбирать, какими кадрами он может “пожертвовать”). Однако при перегрузках узлы коммутации сети FR уничтожают не только кадры с битом DE.

3.Информационное поле - содержит данные пользователя и состоит из целого числа октетов. Его максимальный размер определен стандартом FRF и составляет 1600 октетов (минимальный размер —1 октет), но возможны и другие максимальные размеры (вплоть до 4096 октетов). Содержание информационного поля пользователя передается неизменным.

4.Проверочная последовательность кадра (Erame Check Sequence — FCS). FCS используется для обнаружения возможных ошибок при его передаче и состоит из 2 октетов. Данная последовательность формируется аналогично циклическому коду HDLC.

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

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

Узлам сети FR разрешено уничтожать искаженные кадры, не уведомляя об этом пользователя. Искаженным считается кадр, которому присущ какой-либо из следующих признаков:

нет корректного ограничения флагами;

имеется менее пяти октетов между флагами;

нет целого числа октетов после удаления бит обеспечения прозрачности;

ошибка в FCS;

искажено поле адреса (для случая, когда проверка не выявила ошибки в

FCS);

содержится несуществующий DLCI;

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

Для FR характерно:

заполнение канала связи комбинацией “флаг“ при отсутствии данных для передачи;

резервирование одного DLCI для интерфейса локального управления и сигнализации;

содержание поля данных пользователя в любом кадре не должно подвергаться какой-либо обработке со стороны АКД (могут обрабатываться лишь данные в локальном канале управления).

Управление доступом к сети FR возлагается на интерфейс локального управления (Local Management Interface — LMI). Именно LMI (он будет рассмотрен ниже) реализует интерфейс UNI. Доступ в сеть FR обеспечивают интерфейсы FR (“порты FR”) и FR-адаптеры — сборщики/разборщики кадров FR (FR assembler/disassembler, FRAD). Добиться высокой эффективности использования пропускной способности физических линий и каналов связи, а также исключения перегрузок узлов связи и всей сети FR позволяет метод статистического мультиплексирования кадров, который подразумевает:

постоянное “наблюдение” АКД за потоком заявок от пользователей на передачу сообщений и за текущей загрузкой сети (линий, каналов и узлов связи);

перераспределение свободного (и высвобождающегося) ресурса пропускной способности в соответствии с реальными потребностями абонентов;

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

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

максимальный размер поля информации в кадре FR (в октетах);

пропускная способность порта, посредством которого абонент подключается к сети FR;

гарантированная скорость передачи данных (Committed Information Rate, CIR), при этом обеспечивается требуемое качество доставки;

гарантированный объем передачи информации (Committed Burst Size) при обеспечении требуемого качества доставки; дополнительный объем передачи информации (Excess Burst Size) — качество передачи данных может снижаться.

Предварительные соглашения реализуются следующим образом.

1.Абонент выбирает (и оплачивает) пропускную способность порта и гарантированную скорость передачи данных для PVC.

2.Узел доступа к сети FR измеряет “реальную потребность абонента” в ресурсе пропускной способности канала связи.

3.Если этот ресурс (выраженный реальной скоростью передачи информации) не превышает CIR, то кадры передаются без изменений. Если требуемая скорость превышает CIR, но соответствует пропускной способности порта, то бит DE устанавливается в “1”, что дает возможность удалять эти кадры при возникновении перегрузок (абонент также имеет право решать, какие кадры для него менее важны).

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

Абонент может воспользоваться предварительным соглашением и для того, чтобы уменьшить свои затраты следующим оригинальным способом. Некоторые операторы сетей (поставщики услуг) предлагают значительные скидки при передаче кадров с битом DE, установленным в “1”. При наличии в сети значительного запаса пропускной способности абонент может определить CIR равной “0”. В этом случае во всех передаваемых кадрах бит DE будет установлен в “1”.

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

Стандарты FR (ANSI, ITU-T) распределяют двухоктетные адреса DLCI между пользователями и сетью следующим образом:

0 - используется для канала локального управления (LMI);

1... 15 — зарезервированы для дальнейшего применения;

16...991 — используются абонентами для нумерации PVC и SVC;

992...1007 — используется сетевой транспортной службой для внутрисетевых соединений;

1008...1022 — зарезервированы для дальнейшего применения;

1023 — используются для управления канальным уровнем (в кадрах, которые “переносят” сквозные сообщения управления интерфейсом,

связывающим протоколы более высоких уровней).

Таким образом, в любом интерфейсе FR для оконечных устройств пользователя отводится только 976 адресов DLCI.

Протокол FR обеспечивает высокоскоростную транспортировку данных и, соответственно, предоставляет абоненту требуемый ресурс пропускной способности сети (линий и каналов связи). Поскольку этот протокол стандартизирован только для РVС, то пока отсутствуют стандарты для процедур установления и разъединения соединений. Кроме того, не рассматриваются процедуры управления потоком и исправления ошибок. Таким образом, протокол FR определяет лишь базовый механизм передачи данных и не предполагает никакого механизма локального управления и контроля за состоянием связи.

Интерфейс локального управления (LMI) был разработан, в первую очередь, с целью предоставления пользователю информации о состоянии и конфигурации PVC. LMI применяется только в оконечном аппаратно-программном обеспечении пользователя и выполняет следующие функции:

уведомление абонента о включении, наличии и отключении PVC;

уведомление абонента о готовности заранее сконфигурированного PVC;

последовательный опрос АКД для подтверждения целостности соединения.

При разработке новых стандартов FR интерфейс LMI входит в них неотъемлемой частью, поэтому международные организации, занимающиеся стандартизацией FR, и фирмы-производители проводят активную работу по скорейшему принятию единого стандарта LMI. Такой стандарт окажется особенно актуальным при переходе сетей FR на SVC.

Интерфейс LMI соответствует логической и процедурной характеристикам базового стандарта FR. Различие состоит в расширении заголовка кадра FR с целью размещения дополнительных полей стандарта LMI, поэтому в дальнейшем расширенный кадр FR мы будем называть кадром LMI. Его базовый формат включает в себя (кроме флагов и проверочной последовательности) следующие элементы. Базовый формат кадра LMI:

Октеты

 

 

 

Номера бит

 

 

 

Назначение

 

 

 

 

 

 

 

 

 

1

2

3

4

5

 

6

7

8

 

 

 

 

 

 

 

 

 

 

 

1

0

1

1

1

1

 

1

1

0

Флаг

2

0

0

0

0

0

 

0

0

0

Заголовок: DLCI=0; CR=0 ;

 

 

 

 

 

 

 

 

 

 

 

3

0

0

0

0

0

 

0

0

1

DE=0 ; FECN=0; BECN=0;

 

 

 

 

 

 

 

 

 

 

 

4

1

1

0

0

0

 

0

0

0

Индикатор ненумерованного кадра

5

0

0

0

0

1

 

0

0

0

Определитель протокола

 

 

 

 

 

 

 

 

 

 

 

6

0

0

0

0

0

 

0

0

0

Вызываемый номер (только для SVC)

 

 

 

 

 

 

 

 

 

 

 

7

 

 

 

 

 

 

 

 

 

Тип сообщения

8

 

 

 

 

 

 

 

 

 

Первый информационный элемент

 

 

 

 

 

 

 

 

 

 

 

9

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

N-й информационный элемент

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Проверочная последовательность

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0

1

1

1

1

 

1

1

0

Флаг

1.Заголовок. Им служит стандартный заголовок FR, в котором ад-рес DLCI всегда имеет значение “О”, показывающее, что это — кадр LMI.

2.Индикатор ненумерованного кадра. Данное поле всегда кодируют как “00000011”, чтобы обеспечить процедурную и логическую совместимость с

ISDN.

3.Определитель протокола. Этот октет всегда устанавливается в “00001000”, чем обеспечивается процедурная и логическая совместимость с ISDN.

4.Вызываемый номер. Октет зарезервирован для организации SVC. При создании PVC он кодируется “00000000”.

5.Тип сообщения. Данный октет предназначен для идентификации типа управляющего сообщения, передаваемого через интерфейс LMI. В настоящее время стандартизированы три типа управляющих сообщений — “Запрос установления соединения”, “Запрос разъединения” и “Смешанное сообщение”. Первые два типа относятся к SVC, а последний — к PVC. В этом октете восьмой бит всегда устанавливается в “0”, а биты 7...5 — “1 1 1”, что указывает на смешанное сообщение.

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

Процедурная характеристика LMI .

LMI предусматривает три стратегии локального управления:

синхронное симплексное управление (ССУ);

синхронное дуплексное управление (СДУ);

асинхронное управление (АУ).

Синхронное симплексное управление.

Для осуществления ССУ используются два типа сообщений: “Запрос состояния” (STATUS ENQUIRY) и “Состояние” (STATUS). С помощью этих сообщений LMI проверяет целостность соединения, уведомляет о включении или выключении, а также о готовности PVC.

Процедура ССУ заключается в следующем. ООД периодически запрашивает через интерфейс LMI (процедура “биения”) состояние сети. Через определенный временной интервал ООД посылает в сеть сообщение “Запрос состояния” (международное обозначение интервала опроса — Т391) с целью подтверждения целостности соединения, на что сеть отвечает сообщением “Состояние”, содержащим требуемый элемент информации о целостности соединения.

Интерфейс LMI ведет подсчет числа опросов. По достижении какого-то числа переданных сообщений “Запрос состояния” (т. е. через некоторый временной интервал, который имеет международное обозначение N391) ООД запрашивает у сети информацию о так называемом полном состоянии, также используя сообщение “Запрос состояния”. АКД отвечает на него сообщением “Состояние”, в котором присутствуют информационные элементы для каждого PVC (если ООД имеет несколько портов). Отсутствие в этом ответе информационного элемента для какого-либо PVC воспринимается терминалом пользователя как отсутствие PVC в интерфейсе “пользователь—сеть”. В формате сообщения “Запрос состояния” всегда содержатся два элемента:

информация о типе сообщения;

информация о результатах проверки целостности соединения.

Формат кадра LMI Запрос состояния

Октеты

 

 

 

 

 

 

Номера бит

 

 

 

 

 

 

 

Назначение

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

 

2

 

3

 

4

 

5

 

 

6

 

7

 

8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

0

 

1

 

1

 

1

 

1

 

 

1

 

1

 

0

 

 

Флаг

2

0

 

0

 

0

 

0

 

0

 

 

0

 

0

 

0

 

 

Заголовок: DLCI=0; CR=0 ;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3

0

 

0

 

0

 

0

 

0

 

 

0

 

0

 

1

 

DE=0 ; FECN=0; BECN=0;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4

1

 

1

 

0

 

0

 

0

 

 

0

 

0

 

0

 

 

Индикатор ненумерованного кадра

5

0

 

0

 

0

 

0

 

1

 

 

0

 

0

 

0

 

 

Определитель протокола

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6

0

 

0

 

0

 

0

 

0

 

 

0

 

0

 

0

 

 

Вызываемый номер (только для SVC)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7

0

 

1

 

1

 

1

 

0

 

 

1

 

0

 

1

 

 

Сообщение Запрос состояния

8

0

 

1

 

0

 

1

 

0

 

 

0

 

0

 

1

 

 

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

9

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

10

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Тип сообщения

11

0

 

1

 

0

 

1

 

0

 

 

0

 

1

 

1

 

 

Информационный элемент о

12

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

целостности связи

13

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Номер передаваемого кадра

14

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Номер принятого кадра

15

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Проверочная последовательность

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

17

0

 

1

 

1

 

1

 

1

 

 

1

 

1

 

0

 

 

Флаг

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Первый из информационных элементов указывает, какой тип сообщения запрашивается у сети (всего их может быть три). “Запрос о полном состоянии” посылается для получения информации о всех PVC, сконфигурированных с помощью интерфейса. “Запрос о целостности соединения” предназначен для промежуточного определения порядка следования кадров, “проходящих” через интерфейс, с целью контроля за возможными потерями кадров. “Запрос о состоянии отдельного асинхронного PVC” служит для получения информации об отдельном PVC.

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

“О”).

В ответ на полученное сообщение “Запрос состояния” АКД передает ООД сообщение “Состояние”, в котором указываются:

порядковый номер передаваемого кадра (увеличивается на единицу при каждой передаче);

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

Порядковые номера кадров могут принимать значения от 1 до 255 (в двоичной форме). 0 используется только для обозначения начального порядкового номера принятого кадра в начальном сообщении Запрос состояния.

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

Оповещение пользователя о состоянии PVC осуществляется не в масштабе реального времени, т.е. ООД не мгновенно узнает об изменениях в сети. Поэтому некорректный выбор временного интервала, через который посылаются запросы на информацию о полном состоянии PVC, может привести к возникновению проблем. Во-первых, уведомление о том, что PVC стал доступным, может получить только один из участников информационного обмена. Тогда ООД начинает передавать другому участнику кадры данных прежде, чем на место назначения поступит сообщение Состояние, в котором бит активный PVC установлен АКД в 1. Во-вторых, не зная о том, что PVC стал недоступным, ООД будет по-прежнему передавать через него данные в сеть.

Синхронное дуплексное управление.

При использовании ССУ ответственность за генерацию сообщения Запрос состояния лежит полностью на ООД, а за генерацию сообщения Состояние — на АКД. Такая процедура приемлема для многих приложений, однако предпочтительнее, чтобы каждая из сторон интерфейса LMI могла обеспечивать требуемые для противоположной стороны параметры и коэффициент готовности. СДУ — необязательная часть стандарта FR, которая может использоваться только при заключении соглашения между сторонами (абонент—сеть). СДУ отличается от ССУ только одним: сообщения Запрос состояния и Состояние имеют право передавать обе стороны интерфейса. При СДУ обе стороны интерфейса FR передают сообщение Запрос состояния через определенный временной интервал (Т391), ожидают ответа — сообщения Состояние (Т392), а также запрашивают информацию о полном состоянии (N391). При использовании этих процедур любая из сторон может запрашивать различные параметры и вести учет номеров принимаемых и передаваемых кадров для каждого направления .

Асинхронное управление.

Главным недостатком ССУ и СДУ является потенциальная задержка информирования ООД (или АКД) об изменениях сетевых PVC. Например, при задержке, равной 60 с, и CIR 64 кбит/с пользователь направит в сеть приблизительно 3,5 Мбит данных, прежде чем получит информацию о состоянии PVC. Стратегия АУ позволяет при изменении состояния PVC сети FR сразу передавать стандартные сообщения «Запрос состояния» и «Состояние». Эти сообщения содержат информацию только об отдельных PVC, которые изменили свое состояние. Проверка целостности соединения также основана на генерации последовательности специальных пронумерованных кадров и проверке корректности ее передачи. АУ может осуществляться совместно с ССУ и СДУ, однако если в сети FR применяются одновременно SVC и PVC, то рекомендуется использовать только АУ.

Процедуры управления LMI при возникновении ошибок.

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

прием кадра LMI, информирующего о целостности связи, с неправильным порядковым номером (не соответствующим порядковому номеру последнего переданного кадра);

сообщение “Запрос состояния” не принято по истечении тайм-аута (этот интервал имеет международное обозначение Т392 и должен быть больше,

чем Т391);

прием кадра LMI с ошибкой в FCS.

Вэтих случаях АКД устанавливает в сообщении “Состояние” бит “активный PVC” в “О”, указывая на временную неготовность канала. Когда ошибка устранена, АКД устанавливает бит “активный PVC” в “1”. Однако данные действия осуществляются не сразу при возникновении ошибок, а только при превышении установленного “порога” (максимально допустимое число ошибок имеет международное обозначение N392), который определяется используемым протоколом FR. АКД подсчитывает ошибки, возникающие в пределах установленного периода (его международное обозначение — N393). Если в течение интервала N393 порог N392 будет превышен, сеть переведет PVC в неактивное состояние. Выход из него осуществляется при получении сетью безошибочного сообщения “Запрос состояния”.

ООД может обнаруживать следующие ошибки:

прием кадра LMI, информирующего о целостности соединения, с неправильным порядковым номером (не соответствующим порядковому номеру последнего переданного кадра);

сообщение “Состояние” не принято по истечении временного интервала Т391 — после передачи сообщения “Запрос состояния”;

прием кадра LMI с ошибкой в FCS.

Действия ООД пользователя аналогичны предпринимаемым АКД; их основой является тот же самый пороговый принцип: ООД прекращает передачу, когда в течение интервала N393 превышен порог N392. Выход из неактивного состояния PVC осуществляется при передаче от ООД сообщения “Запрос состояния”. Однако стандарт FR не устанавливает процедуры, позволяющие однозначно определить, что ошибка устранена и ООД может передать сообщения “Запрос состояния”. Об устранении ошибки свидетельствует лишь то, что N392 событий прошли без ошибки. Необходимо также отметить, что невозможно обнаружить ошибки в пределах отдельного PVC интерфейса FR, т.е. ошибки затронут все сконфигурированные PVC.

Возникновение ошибок может быть связано с тем, что сообщения о состоянии LMI были потеряны на линии связи или инициализация PVC осуществлялась некорректно. В этих случаях ООД должно отмечать в кадрах LMI, что PVC “активен” или “недоступен” соответственно.

Параметры для синхронизации процедур управления LMI.

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

Международное

 

Диапазон

Значение «по

 

обозначение

Содержание

возможных

Назначение

счетчика

 

значений

умолчанию»

 

 

Счетчик

 

 

 

 

кадров для

 

 

Определяет начало

 

определения

 

 

 

 

 

последовательности

N 391

момента

1…255

6

пронумерованных

 

сообщения о

 

 

 

 

 

кадров LMI

 

полном

 

 

 

 

 

 

 

статусе

 

 

 

 

Порог –

 

 

 

 

максимально

 

 

 

N 392

допустимое

1…10

3

Подсчет ошибочных

число

событий

 

 

 

 

ошибочных

 

 

 

 

событий

 

 

 

 

Интервал

 

 

 

N 393

контроля

1…10

4

Подсчет ошибочных

ошибочных

событий

 

 

 

 

событий

 

 

 

При ССУ счетчик кадров (N391 ) ведет подсчет переданных ООД кадров LMI (“Запросов состояния”) с информацией о целостности соединения. После того, как переданы N391 сообщений “Запрос состояния”, ООД с помощью кадра LMI (“Запрос состояния”) запрашивает информацию о полном состоянии PVC. При СДУ АКД также может использовать счетчик кадров (N391) для запроса информации о полном состоянии.

Максимально допустимое число (порог) ошибок (N392) используется при подсчете числа ошибок в интерфейсе и должно быть меньше (или равняться) интервала N393. В пределах этого интервала анализу подвергаются следующие события:

получение корректного кадра LMI;

получение недействительного кадра LMI;

отсутствие кадра LMI в период тайм-аута (Т392).

Если за интервал N393 число ошибок превысило порог N392, это интерпретируется как состояние ошибки. В практических реализациях интервал N393 устанавливается ненамного меньшим, чем N391, поскольку иначе при изменении состояния PVC не произойдет своевременное уведомление ООД. При осуществлении ССУ счетчик времени (Т391) используется для определения начала передачи сообщения “Запрос состояния” (запрос о целостности связи) со

стороны ООД, а при СДУ — со стороны АКД. Величины Т391, устанавливаемые ООД и АКД, могут быть различными.

При ССУ величиной тайм-аута (Т392) пользуется лишь АКД. Если сообщение “Запрос состояния”, которое передается ООД, не поступает в сеть до истечения срока Т392, то АКД повторно передает ООД сообщение “Состояние” (с номером последнего корректно принятого кадра LMI); при этом число ошибочных событий (N392) увеличивается на единицу. Т392 всегда должен быть больше, чем Т391. При СДУ таймер Т392 применяется также ООД. Величины Т392, устанавливаемые ООД и АКД, могут быть различными. Существует необходимость не только в синхронизации специальных счетчиков событий и времени, но и в установлении максимального размера поля информации кадра FR при взаимодействии ООД—АКД.

Использование сети Frame Relay в качестве транспортной среды.

Важным преимуществом использования сети FR в качестве транспортной среды (применения кадра FR в качестве базового информационного элемента, в который “вкладывается” пакет сетевого протокола) является то, что сетевые протоколы позволяют достаточно просто строить (конфигурировать) распределенные сети передачи данных (СПД) на основе “физических” FRсоединений. Чтобы добиться этой простоты, необходимо иметь в рамках FRпротокола некоторый уникальный механизм (дополнение к процедурной и логической характеристикам FR-протокола) для идентификации сетевого протокола при передаче пакета, “вкладываемого” в FR-кадр. Главная цель такого механизма — обеспечение корректной доставки адресату сообщения отправителя. Рассмотрим основные положения проекта международного стандарта, разработанного ANSI .

Сущность метода идентификации сетевого протокола при передаче пакета, “вкладываемого” в FR-кадр, заключается в использовании стандартного формата FR-кадра; в поле данных этого кадра имеется специальное поле идентификатора протокола 3-го уровня. В дальнейшем такой FR-кадр будем именовать многопротокольным кадром, включающим в себя следующие поля:

адресное поле. Имеет стандартный размер 2 октета, но при необходимости может быть увеличено до 3 или 4 октетов;

идентификатор ненумерованного информационного кадра (ИНИК). Поле кодируется в соответствии с Рекомендацией ITU-T Q.922 (используется так же, как в кадре LMI);

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

идентификатор протокола сетевого уровня (ИПСУ). Поле содержит код сетевого протокола, в соответствии с процедурной характеристикой которого осуществляется передача пакета. Кодирование данного поля соответствует стандартам ANSI и ITU-T — при условии, что все производители примут единую систему идентификации. Если какой-либо сетевой протокол не имеет ИПСУ, определенного стандартами ANSI/ITU-T, то может быть использован специальный код (шестнадцатеричное “08”), который определен в Рекомендации ITU-T Q.933. Для кодирования ИПСУ могут применять 2 дополнительных двухоктетных поля, которые служат