JUL	Oct	DEC
	17
2006	2007	2008

9 captures

1 May 05 - 23 Dec 07

Close Help

полная версия

Замок Дракона

Б Е З Б А Ш Н И

На главную / Архивы Замка Дракона / Лекции ВМиК / Сети / Frame relay

Frame relay.

Проблемы стандартизации

Ретрансляция кадров (frame relay, FR) - это метод доставки сообщений в сетях передачи данных (СПД) с коммутацией пакетов (в отличие от СПД с коммутацией каналов и сообщений). Первоначально разработка стандарта FR ориентировалась на цифровые сети интегрированного обслуживания (ISDN - Integrated Services Digital Networks), однако позже стало ясно, что FR применим и в других СПД (здесь под данными понимается любое сообщение, представленное в цифровой форме). К числу достоинств метода прежде всего необходимо отнести малое время задержки, простой формат кадров, содержащих минимум управляющей информации, и независимость от протоколов верхних уровней ЭМВОС.
В настоящее время разработкой и исследованием стандартов FR занимаются три организации:
Frame Relay Forum (FRF) - международный консорциум, включающий в себя свыше 300 поставщиков оборудования и услуг, среди которых 3Com, Northern Telecom, Digital, Cisco, Netrix, Ascom Timeplex, Newbridge Networks, Zilog и др.; American National Standards Institute (ANSI, Американский национальный институт по стандартизации); Международный союз электросвязи (ITU-T).
Любой международный стандарт имеет (и всегда будет иметь) множество прикладных реализаций, что зачастую приводит к несовместимости аппаратно-программных средств разных производителей. Международные организации неоднократно пытались решить данную проблему. Результатом одной из таких попыток (предпринятой FRF) стал проект стандарта, включающего в себя спецификации ANSI, которые обязательны для выполнения членами FRF. В январе 1992 г. этот проект был доработан Техническим комитетом FRF и утвержден собранием членов FRF.
Принятый FRF проект рассматривает только спецификации для постоянных виртуальных каналов (PVC) и интерфейса "пользователь-сеть" (UNI). В него не вошли стандарты для коммутируемых виртуальных каналов (SVC) и интерфейса межсетевого взаимодействия. Однако работа по этим направлениям продолжается и ее результаты найдут свое отражение в новых стандартах FR. Проект FRF не рассматривает и стандарты физических интерфейсов, поэтому при создании сетей FR допускаются различные физические интерфейсы, среди которых V.35, G.703, X.21 и др.

Логическая характеристика протокола FR

FR является бит-ориентированным синхронным протоколом и использует "кадр" в качестве основного информационного элемента - в этом смысле он очень похож на протокол HDLC (High Level Data Link Control). Однако FR обеспечивает не все функции протокола HDLC; многие из элементов кадра HDLC исключены из основного формата кадра FR (в последнем адресное поле и поле управления HDLC совмещены в единое адресное поле). Структура кадра FR (рис.1) включает в себя следующие элементы.

Рисунок 1.Структура и формат кадра frame relay.

Флаг. Все кадры начинаются и заканчиваются комбинацией "флаг": "01111110". С целью предотвращения имитации комбинации "флаг" при передаче кадра проверяется все его содержание между двумя флагами и вставляется бит "0" после каждой последовательности, состоящей из пяти идущих подряд бит "1". Данная процедура (bit stuffing) обязательна при формировании любого кадра FR. На приемном конце биты "0" отбрасываются.

Заголовок:

адрес в пределах кадра FR (стандарт FRF), состоит из шести бит первого октета и четырех бит второго октета заголовка кадра (стандарты ANSI и ITU-T допускают размер заголовка до 4 октетов). Эти 10 бит представляют собой идентификатор канала передачи данных (Data Link Connection Identifier, DLCI) и определяют абонентский адрес в сети FR;
бит "опрос/финал" (Command/ Response - CR) зарезервирован для возможного применения в различных протоколах более высоких уровней управления ЭМВОС. Этот бит не используется протоколом FR и "прозрачно пропускается" аппаратно-программными средствами сети FR;
бит расширения адреса (Extended Address - EA). DLCI содержится в 10 битах, входящих в два октета заголовка. Однако возможно расширение заголовка на целое число дополнительных октетов с целью указания адреса, состоящего более чем из 10 бит. EA устанавливается в конце каждого октета заголовка; если он имеет значение "1", то это означает, что данный октет в заголовке последний. Стандарт FRF рекомендует использовать заголовки, состоящие из 2 октетов. В этом случае значение бита EA первого октета будет соответствовать "0", а второго - "1";
бит уведомления (сигнализации) приемника о явной перегрузке (Forward Explicit Сongestion Notification - FECN) устанавливается в "1" для уведомления получателя сообщения о том, что произошла перегрузка в направлении передачи данного кадра. Бит FECN устанавливается аппаратурой канала данных (АКД), а не передающим оконечным оборудованием данных (ООД) и может не использоваться терминалами абонентов (рис. 2);
бит уведомления (сигнализации) источника о явной перегрузке (Backward Explicit Сongestion Notification - BECN) устанавливается в "1" для уведомления источника сообщения о том, что произошла перегрузка в направлении, обратном направлению передачи содержащего этот бит кадра. Бит BECN устанавливается АКД (а не ООД) и может не использоваться терминалами абонентов (см. рис. 2); бит разрешения сброса (Discard Eligibility - DE) устанавливается в "1" в случае явной перегрузки и указывает на то, что данный кадр может быть уничтожен в первую очередь. Бит DE устанавливает либо АКД, либо ООД (т. е. пользователю предоставлено право выбирать, какими кадрами он может "пожертвовать"). Однако при перегрузках узлы коммутации сети FR уничтожают не только кадры с битом DE.

Рисунок 2. Установка бит перегрузки.

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

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

Процедурная характеристика протокола 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, Bc) - при обеспечении требуемого качества доставки;
дополнительный объем передачи информации (Excess Burst Size, Be) - качество передачи данных может снижаться.

Предварительные соглашения реализуются следующим образом.
1. Абонент выбирает (и оплачивает) пропускную способность порта и гарантированную скорость передачи данных для PVC.
2. Узел доступа к сети FR измеряет "реальную потребность абонента" в ресурсе пропускной способности канала связи.
3. Если этот ресурс (выраженный реальной скоростью передачи информации) не превышает CIR, то кадры передаются без изменений. Если требуемая скорость превышает CIR, но соответствует пропускной способности порта, то бит DE устанавливается в "1", что дает возможность удалять эти кадры при возникновении перегрузок (абонент также имеет право решать, какие кадры для него менее важны). Наконец, если превышена пропускная способность порта, кадры уничтожаются вне зависимости от каких-либо условий.
Абонент способен воспользоваться предварительным соглашением и для того, чтобы уменьшить свои затраты следующим оригинальным способом. Некоторые операторы сетей (поставщики услуг) предлагают значительные скидки при передаче кадров с битом DE, установленным в "1". При наличии в сети значительного запаса пропускной способности абонент может определить CIR равной "0". В этом случае во всех передаваемых кадрах бит DE будет установлен в "1".

Адресация в сетях FR

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

Рисунок 3. Применение DLCI.

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

0 - используется для канала локального управления (LMI);
13/415 - зарезервированы для дальнейшего применения;
163/4991 - используются абонентами для нумерации PVC и SVC;
9923/41007 - используется сетевой транспортной службой для внутрисетевых соединений;
10083/41022 - зарезервированы для дальнейшего применения;
1023 - используются для управления канальным уровнем (в кадрах, которые "переносят" сквозные сообщения управления интерфейсом, связывающим протоколы более высоких уровней).

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

Интерфейс локального управления

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

Логическая характеристика LMI

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

	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	Заголовок: DCLCI=0, CR=0
3	0	0	0	0	0	0	0	1	DE=0, FECN=0, DECN=0
4	0	0	0	0	0	0	1	1	Индикатор ненумерованного кадра
5	0	0	0	0	1	0	0	0	Определитель протокола
6	0	0	0	0	0	0	0	0	Вызываемый номер (только для SVC)
7									Тип сообщения
8									Первый информационный элемент
9
10
11
12
13
	...								...
									N-й информационный элемент
									Проверочная последовательность
	0	1	1	1	1	1	1	0	Флаг

Рисунок 4.
Базовый формат кадра LMI.

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

Индикатор ненумерованного кадра. Данное поле всегда кодируют как "00000011", чтобы обеспечить процедурную и логическую совместимость с ISDN.
Определитель протокола. Этот октет всегда устанавливается в "00001000", чем обеспечивается процедурная и логическая совместимость с ISDN.
Вызываемый номер. Октет зарезервирован для организации SVC. При создании PVC он кодируется "00000000".
Тип сообщения. Данный октет предназначен для идентификации типа управляющего сообщения, передаваемого через интерфейс LMI. В настоящее время стандартизированы три типа управляющих сообщений - "Запрос установления соединения", "Запрос разъединения" и "Смешанное сообщение". Первые два типа относятся к SVC, а последний - к PVC. В этом октете восьмой бит всегда устанавливается в "0", а биты 7...5 - "111", что указывает на смешанное сообщение. Как кодируются остальные биты, показано на рис. 5.

Тип сообщения	8	7	6	5	4	3	2	1
Смешанные сообщения	0	1	1	1	-	-	-	-
Состояние	0	1	1	1	1	1	0	1
Запрос состояния	0	1	1	1	0	1	0	1

Рисунок 5.
Кодирование поля "Тип сообщения" кадра LMI для смешанных сообщений.

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

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

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

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

Синхронное симплексное управление. Для осуществления ССУ используются два типа сообщений: "Запрос состояния" (STATUS ENQUIRY) и "Состояние" (STATUS). С помощью этих сообщений LMI проверяет целостность соединения, уведомляет о включении или выключении, а также о готовности PVC.
Процедура ССУ (рис. 6) заключается в следующем. ООД периодически запрашивает через интерфейс LMI (процедура "биения") состояние сети. Через определенный временной интервал ООД посылает в сеть сообщение "Запрос состояния" (международное обозначение интервала опроса - T391) с целью подтверждения целостности соединения, на что сеть отвечает сообщением "Состояние", содержащим требуемый элемент информации о целостности соединения.

Рисунок 6.Процедура периодического опроса (ССУ).

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

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

	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	Заголовок: DCLCI=0, CR=0
3	0	0	0	0	0	0	0	1	DE=0, FECN=0, DECN=0
4	0	0	0	0	0	0	1	1	Индикатор ненумерованного кадра
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	Cообщение "Запрос состояния"
8	0	1	0	1	0	0	0	1	Информационный элемент о типе сообщения
9	1
10	Тип сообщения
11	0	1	0	1	0	0	1	1	Информационный элемент о целостности связи
12	2
13	Номер передаваемого кадра
14	Номер принятого кадра
15									Проверочная последовательность
16									Проверочная последовательность
17	0	1	1	1	1	1	1	0	Флаг

Рисунок 7.
Формат кадра LMI "Запрос состояния".

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

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

	8	7	6	5	4	3	2	1	Назначение
1	0	1	0	1	0	0	1	1	Информационный элемент о целостности связи
2									Длина информационного элемента в октетах (2)
3									Номер передаваемого кадра
4									Номер принятого кадра

Рисунок 8.
Формат информационного элемента о целостности связи.

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

Порядковые номера кадров могут принимать значения от 1 до 255 (в двоичной форме). "0" используется только для обозначения начального порядкового номера принятого кадра в начальном сообщении "Запрос состояния".
Признак нового PVC еще не дает ООД разрешения начать передачу сообщения в данном PVC. "Сигналом" начала передачи является бит "активный PVC", определенный сетью как "1". Он устанавливается АКД только тогда, когда последняя "непосредственно убедилась" в том, что найден путь для доставки сообщения к месту назначения (другими словами, когда PVC полностью проключен). Время включения PVC зависит от конкретной сети и реализации протокола.
Оповещение пользователя о состоянии PVC осуществляется не в масштабе реального времени, т.е. ООД не мгновенно "узнает" об изменениях в сети. Поэтому некорректный выбор временного интервала, через который посылаются запросы на информацию о полном состоянии PVC, может привести к возникновению проблем. Во-первых, уведомление о том, что PVC стал доступным, может получить только один из участников информационного обмена. Тогда ООД начинает передавать другому участнику кадры данных прежде, чем на место назначения поступит сообщение "Состояние", в котором бит "активный PVC" установлен АКД в "1". Во-вторых, не зная о том, что PVC стал недоступным, ООД будет по-прежнему передавать через него данные в сеть.
Синхронное дуплексное управление. При использовании ССУ ответственность за генерацию сообщения "Запрос состояния" лежит полностью на ООД, а за генерацию сообщения "Состояние" - на АКД. Такая процедура приемлема для многих приложений, однако предпочтительнее, чтобы каждая из сторон интерфейса LMI могла обеспечивать требуемые для противоположной стороны параметры и коэффициент готовности.
СДУ - необязательная часть стандарта FR, которая может использоваться только при заключении соглашения между сторонами (абонент-сеть). СДУ отличается от ССУ только одним: сообщения "Запрос состояния" и "Состояние" имеют право передавать обе стороны интерфейса (рис. 9). При СДУ обе стороны интерфейса FR передают сообщение "Запрос состояния" через определенный временной интервал (T391), "требуют" ответа - сообщения "Состояние" (T392), а также запрашивают информацию о полном состоянии (N391). При использовании этих процедур любая из сторон может запрашивать различные параметры и вести учет номеров принимаемых и передаваемых кадров для каждого направления (рис. 10).

Рисунок 9. Процедура синхронного дуплексного управления.
Рисунок 10. Распределение нумерации кадра при СДУ.

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

Стратегия АУ позволяет при изменении состояния PVC сети FR сразу передавать стандартные сообщения "Запрос состояния" и "Состояние". Эти сообщения содержат информацию только об отдельных PVC, которые изменили свое состояние. Проверка целостности соединения также основана на генерации последовательности специальных пронумерованных кадров и проверке корректности ее передачи. АУ может осуществляться совместно с ССУ и СДУ, однако если в сети FR применяются одновременно SVC и PVC, то рекомендуется использовать только АУ.
Процедуры управления LMI при возникновении ошибок. LMI предназначен для передачи минимального количества управляющей информации, позволяющей гарантировать нормальное функционирование интерфейса FR. Но существуют и специальные процедуры управления, которые реализуются при возникновении следующих возможных ошибок в интерфейсе FR, обнаруживаемых АКД:
В этих случаях АКД устанавливает в сообщении "Состояние" бит "активный PVC" в "0", указывая на временную неготовность канала. Когда ошибка устранена, АКД устанавливает бит "активный PVC" в "1". Однако данные действия осуществляются не сразу при возникновении ошибок, а только при превышении установленного "порога" (максимально допустимое число ошибок имеет международное обозначение N392), который определяется используемым протоколом FR. АКД подсчитывает ошибки, возникающие в пределах установленного периода (его международное обозначение - N393). Если в течение интервала N393 порог N392 будет превышен, сеть переведет PVC в неактивное состояние. Выход из него осуществляется при получении сетью безошибочного сообщения "Запрос состояния".
ООД может обнаруживать следующие ошибки:

прием кадра LMI, информирующего о целостности соединения, с неправильным порядковым номером (не соответствующим порядковому номеру последнего переданного кадра);
сообщение "Состояние" не принято по истечении временного интервала T391 - после передачи сообщения "Запрос состояния";
прием кадра LMI с ошибкой в FCS.

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

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

Возникновение ошибок может быть связано с тем, что сообщения о состоянии LMI были потеряны на линии связи или инициализация PVC осуществлялась некорректно. В этих случаях ООД должно отмечать в кадрах LMI, что PVC "активен" или "недоступен" соответственно.
Параметры для синхронизации процедур управления LMI. Для нормального осуществления процедур управления LMI используется ряд специальных счетчиков событий и времени, назначение которых - синхронизация последовательностей кадров управляющей информации, проходящих через интерфейс (рис. 11 и 12).

#	Международное обозначение счетчика	Содержание	Диапазон возможных значений	Значение "по умолчанию"	Назначение
1	#391	Счетчик кадров для определения момента передачи сообщения о полном статусе	1...255	6	Определяет начало последовательности пронумерованных кадров LMI
2	#392	Порог - максимально допустимое число ошибочных событий	1...10	3	Подсчет ошибочных событий
3	#393	Интервал для контроля ошибочных событий	1...10	4	Посчет ошибочных событий

Рисунок 11.
Счетчики событий, используемые для синхронизации процессов управления LMI.

#	Международное обозначение таймера	Назначение	Диапазон возможных значений, с	Значение "по умолчанию", с
1	Т391	Таймер для определения начала передачи сообщения о целостности связи	5...30	10
2	Т392	Временной интервал тайм-аута	5...30	15

Рисунок 12.
Счетчики времени, используемые для синхронизации процессов управления LMI.

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

Максимально допустимое число (порог) ошибок (N392) используется при подсчете числа ошибок в интерфейсе и должно быть меньше (или равняться) интервала N393. В пределах этого интервала анализу подвергаются следующие события:
Если за интервал N393 число ошибок превысило порог N392, это интерпретируется как состояние ошибки. В практических реализациях интервал N393 устанавливается ненамного меньшим, чем N391, поскольку иначе при изменении состояния PVC не произойдет своевременное уведомление ООД.
При осуществлении ССУ счетчик времени (T391) используется для определения начала передачи сообщения "Запрос состояния" (запрос о целостности связи) со стороны ООД, а при СДУ - со стороны АКД. Величины T391, устанавливаемые ООД и АКД, могут быть различными.
При ССУ величиной тайм-аута (T392) пользуется лишь АКД. Если сообщение "Запрос состояния", которое передается ООД, не поступает в сеть до истечения срока T392, то АКД повторно передает ООД сообщение "Состояние" (с номером последнего корректно принятого кадра LMI); при этом число ошибочных событий (N392) увеличивается на единицу. T392 всегда должен быть больше, чем T391. При СДУ таймер T392 применяется также ООД. Величины T392, устанавливаемые ООД и АКД, могут быть различными.
Существует необходимость не только в синхронизации специальных счетчиков событий и времени, но и в установлении максимального размера поля информации кадра FR при взаимодействии ООД-АКД.

[Наверх: в начало раздела ≡ Назад: некуда ≡ Вперед: некуда ≡ Здесь: Frame relay]