Высокоскоростные сети

Страница 14

Рисунок 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.

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

СДУ - необязательная часть стандарта FR, которая может использоваться только при заключении соглашения между сторонами (абонент-сеть). СДУ отличается от ССУ только одним: сообщения "Запрос состояния" и "Состояние" имеют право передавать обе стороны интерфейса (рис. 9). При СДУ обе стороны интерфейса FR передают сообщение "Запрос состояния" через определенный временной интервал (T391), "требуют" ответа - сообщения "Состояние" (T392), а также запрашивают информацию о полном состоянии (N391).

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

Стратегия АУ позволяет при изменении состояния PVC сети FR сразу передавать стандартные сообщения "Запрос состояния" и "Состояние". Эти сообщения содержат информацию только об отдельных PVC, которые изменили свое состояние. Проверка целостности соединения также основана на генерации последовательности специальных пронумерованных кадров и проверке корректности ее передачи. АУ может осуществляться совместно с ССУ и СДУ, однако если в сети FR применяются одновременно SVC и PVC, то рекомендуется использовать только АУ.

Некоторые дополнения

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

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

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

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

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

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