На каком уровне frame relay обеспечивает обнаружение ошибок

Соседние файлы в папке Сетевые технологии

• #
• #
• #
• #

Frame Relay представляет собой стандартный протокол объединения локальных сетей, который обеспечивает методы быстрой и эффективной передачи информации от пользовательских устройств до мостов и маршрутизаторов ЛВС.

Протокол Frame Relay использует кадры, подобные по структуре кадрам LAPD и отличающиеся от последних тем, что взамен заголовка кадра помещается 2-байтовое поле заголовка Frame Relay. Заголовок Frame Relay содержит заданное пользователем поле DLCI, которое служит адресом получателя данного кадра. Поле заголовка содержит также биты насыщения и состояния, которые передаются пользователю со стороны сети.

Виртуальные устройства (VC)

Кадры Frame Relay передаются получателям с использованием виртуальных устройств (логический путь между отправителем и получателем). Виртуальные устройства могут быть постоянными (PVC) или коммутируемыми (SVC). PVC организуются административными методами администратором сети для создания соединений «точка-точка». Коммутируемые соединения SVC организуются по мере надобности (подобно телефонным звонкам).

Преимущества Frame Relay

Технология Frame Relay является привлекательной альтернативой использованию выделенных линий и сетей X.25 для соединения мостов и маршрутизаторов ЛВС. Успех протокола Frame Relay обусловлен двумя факторами:

• Поскольку виртуальные устройства занимают полосу канала только при реальной передаче данных, в одной линии передачи может сосуществовать множество виртуальных устройств. В дополнение к этому каждое виртуальное устройство может при необходимости использовать более широкую полосу, что обеспечивает повышение скорости передачи данных.
• Повышение надежности каналов связи и расширение возможностей обработки ошибок в оконечных устройствах (пользовательских станциях) позволяет протоколу Frame Relay просто отбрасывать кадры с ошибками, снижая затраты времени на процедуры обработки ошибок на уровне протокола.

Эти два фактора делают технологию Frame Relay удобным решением для организации сетей передачи. Однако в силу перечисленных особенностей Frame Relay требуется проверка корректности работы системы и отсутствие потерь при передаче данных.

Структура Frame Relay

Стандарты для протокола Frame Relay были разработаны одновременно ANSI и CCITT. Отдельная спецификация LMI в основном включена в стандарты ANSI. При дальнейшем рассмотрении протоколов описаны основные аспекты обоих вариантов спецификаций.

Структура кадров Frame Relay базируется на протоколе LAPD. В структуре Frame Relay заголовки кадров несколько изменены и включают идентификатор соединения на канальном уровне DLCI (Data Link Connection Identifier) и биты насыщения взамен полей адреса и управления. Структура специфической части заголовка Frame Relay имеет размер 2 байта и показана на рисунке.

Структура заголовка Frame Relay

DLCI

10-битовое поле DLCI представляет собой адрес получателя и соответствующее соединение PVC.

C/R

Указывает, что содержит кадр – команду или отклик.

EA

Поле расширенной адресации занимает до 2 битов заголовка Frame Relay и позволяет увеличить число адресуемых устройств.

FECN

Прямое уведомление о насыщении – Forward Explicit Congestion Notification (см. ECN ниже).

BECN

Обратное уведомление о насыщении – Backward Explicit Congestion Notification (см. ECN ниже).

DE

Возможность отбрасывания – Discard Eligibility (см. DE ниже).

Информация

Информационное поле может включать кадры других протоколов, таких как X.25, IP или SDLC (SNA).

Биты ECN

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

Для оповещения пользовательских устройств о насыщении в линии используются два бита заголовка кадров Frame Relay – бит прямого уведомления FECN (Forward Explicit Congestion Notification) и бит обратного уведомления BECN (Backward Explicit Congestion Notification). Для поля FECN устанавливается значение 1 в кадрах, передаваемых в направлении получателя (downstream) при возникновении насыщения на пути передачи данных. В этом случае все узлы нисходящего потока и подключенные к ним пользовательские устройства узнают о насыщении в линии. Для бита BECN значение 1 устанавливается в кадрах, передаваемых обратно в направлении отправителя кадров. Эти уведомления говорят отправителю о необходимости снижения скорости передачи данных.

Биты насыщения устанавливаются в соответствии с DLCI

Консолидированное управление на канальном уровне (CLLM)

Может возникнуть такая ситуация, что кадров, передаваемых в направлении отправителя просто не будет. В таких случаях сеть разумно будет передавать по инициативе сети сообщения в направлении узла, вызвавшего проблемы. Однако стандарт не позволяет сети передавать свои кадры с использованием DLCI желаемого виртуального устройства. Для решения этой проблемы в ANSI была разработана спецификация консолидированного управления на канальном уровне (Consolidated Link Layer Management или CLLM). При использовании CLLM для передачи пользовательским устройствам управляющих сообщений канального уровня служит специально зарезервированное значение DLCI (номер 1023). Стандарт ANSI T1.618 определяет формат сообщений CLLM. В таких сообщениях указывается причина насыщения и перечисляются все значения DLCI, для которых требуется снижение скорости передачи данных.

Состояние соединения (LMI)

Каждому значению DLCI соответствует постоянное виртуальное устройство PVC (Permanent Virtual Circuit). Иногда возникает необходимость передачи информации о соединении (например, о состоянии активности интерфейса) по корректным значениям DLCI для интерфейса и состояние каждого PVC. Такая информация передается с использованием DLCI 1023 или DLCI 0 (в зависимости от используемого стандарта.

Вместе с LMI может также передаваться информация о состоянии групповых передач (multicast status). Групповой передачей называются такие случаи, когда маршрутизатор передает кадр по зарезервированному значению DLCI, известному как multicast-группа. В таких случаях сеть копирует групповые кадры и доставляет их по предопределенному списку DLCI (группе пользователей сразу).

Возможность отбрасывания (DE)

При возникновении насыщения в линии сеть должна решить какие кадры могут быть отброшены для освобождения полосы канала. Бит DE предоставляет сети информацию для решения вопроса о возможности отбрасывания кадров. Сеть будет в первую очередь отбрасывать кадры с установленным флагом DE (1).

Бит DE может быть установлен пользователем в кадрах, доставка которых может быть задержана (низкий приоритет). Кроме того, сеть может устанавливать флаг DE для того, чтобы показать другим узлам возможность отбрасывания данного кадра при возникновении насыщения.

Стандарты Frame Relay

ANSI T1.618

Стандарт T1.618 описывает протокол, поддерживающий фазу переноса данных сервиса Frame Relay, определенного в стандарте ANSI T1.606. Стандарт T1.618 основан на подмножестве ANSI T1.602 (LAPD), называемом Core Aspects (основные аспекты) и используемом коммутаторами и постоянными виртуальными каналами.

T1.618 также включает механизм консолидированного управления на канальном уровне CLLM. Генерация и передача CLLM являются необязательным сервисом. При использовании CLLM значение DLCI 1023 резервируется для передачи управляющих сообщений канального уровня.

T1.618 использует явные уведомления о насыщении, передаваемые сетью пользовательским устройствам. Уведомления о насыщении содержат код, показывающий причину насыщения, и список всех DLCI, для которых требуется снижение уровня трафика, чтобы преодолеть насыщение.

ANSI T1.617

Для организации коммутируемых виртуальных устройств SVC (Switched Virtual Circuit) пользователи Frame Relay должны открыть диалог с сетью, используя сигнальные спецификации T1.617. Эта процедура приводит к выделению DLCI для коммутируемого виртуального устройства. После открытия диалога применяются процедуры T1.618.

Для организации постоянного виртуального устройства PVC используется протокол организации соединений (setup protocol), идентичный протоколу D-каналов в ISDN и описанный в спецификации T1.617.

При использовании ISDN пользователи могут применять канал D для организации соединений. Для других типов абонентов (не ISDN) канала D не существует, поэтому диалог между пользователем и сетью должен быть отделен от других процедур передачи данных. В стандарте T1.617 для этого зарезервировано значение DLCI 0.

Стандарт T1.617 также содержит спецификации согласования параметров сервиса Frame Relay.

ANSI LMI

ANSI LMI представляет собой систему управления постоянными виртуальными устройствами PVC, определенную в дополнении Annex D к стандарту T1.617. ANSI LMI практически не отличается от LMI производителей, не используя лишь дополнительных расширений. В ANSI LMI зарезервировано значение DLCI 0.

LMI производителей

Manufacturers’ LMI представляет собой спецификацию Frame Relay с расширением, опубликованную в документе 001-208966 от 18 сентября 1990г.

LMI производителей определяет базовый сервис Frame Relay на основе PVC для соединения устройств DTE с сетевым оборудованием Frame Relay. В дополнение к стандарту ANSI эта спецификация включает расширенные функции и процедуры LMI. В Manufacturers’ LMI зарезервировано значение DLCI 1023.

Frame Relay NNI PVC

Интерпретация NNI (Network-to-Network – сеть-сеть) PVC для Frame Relay описана в FRF.2. Интерфейс NNI рассматривает передачу информации планов U и C (U-plane и C-plane) между двумя сетевыми узлами, находящимися в разных сетях Frame Relay.

FRF.3

FRF.3 обеспечивает многопротокольную инкапсуляцию для сетей Frame Relay в кадрах ANSI T1.618. Структура таких кадров Frame Relay показана на рисунке.

8	7	6	5	4	3	2	1	Октеты
Флаг (7Eh)	1
Адрес T1.618 (включая 10 битов DLCI)	2 3
Управление Q.922 (кадр UI или I)	4
Дополнительный байт заполнения (00h)	5
NLPID	6
Данные . . .	7
Последовательность проверки кадра	n-2 n-1
Флаг (7Eh)	n

Структура кадра FRF.3

Поле NLPID (Network Level Protocol ID идентификатор протокола сетевого уровня) обозначает тип инкапсулируемого протокола. На приведенном ниже рисунке показаны значения NLPID и соответствующие протоколы. Например, значение 0xCC говорит об инкапсуляции кадров IP.

Многопротокольная инкапсуляция Frame Relay

UNI SVC

FRF.4 представляет собой соглашение о коммутируемых виртуальных соединениях Frame Relay для интерфейса «пользователь-сеть» (UNI). Это соглашение позволяет использовать оборудование, подключенное к отличным от ISDN сетям Frame Relay или к сетям ISDN, использующим только case A.

Ниже приведен список корректных типов сообщений SVC:

• ss
• Call proceeding (обработка вызова).
• Connect (соединение).
• Connect Acknowledge (подтверждение соединения).
• Disconnect (разъединение).
• Progress (продолжение процесса).
• Release (освобождение).
• Release complete (освобождение завершено).
• Setup (установка).
• Status (состояние).
• Status enquiry (запрос состояния).

Декодирование UNI SVC

NNI SVC

Анализаторы протоколов RADCOM поддерживают также декодирование кадров NNI (Network-to-Network) SVC в соответствии с соглашением о реализации Frame Relay Forum FRF.10. Это соглашение применяется к коммутируемым виртуальным устройствам SVC для Frame Relay NNI и SPVC. Соглашение применимо также к интерфейсам NNI, в которых обе сети являются частными, одна сеть является частной, а вторая – публичной или обе сети относятся к сетям общего пользования. Такие кадры автоматически распознаются анализатором и корректно декодируются.

FRF.11

Frame Relay в настоящее время является основной компонентой множества крупных сетей. Протокол требует минимального набора функций коммутации для пересылки пакетов переменного размера через сеть. Базовый протокол Frame Relay, описанный в соглашениях о реализации Frame Relay Forum UNI (интерфейс “пользователь-сеть) и NNI (межсетевой интерфейс), был дополнен соглашениями, которые детализируют методы передачи структурированных данных в информационных полях базовых кадров Frame Relay. Эти методы обеспечивают поддержку различных приложений, включая мосты ЛВС, маршрутизацию IP и SNA.

FRF.11 расширяет поддержку приложений Frame Relay, включая сюда возможность передачи голосового (телефонного) трафика. В частности, спецификация FRF.11 предназначена для решения следующих задач:

• Передача сжатых голосовых потоков в кадрах Frame Relay.
• Поддержка широкого набора алгоритмов компрессии голоса.
• Эффективное использование узкополосных соединений Frame Relay.
• Мультиплексирование до 256 субканалов в один Frame Relay DLCI.
• Поддержка множества голосовых потоков одного или различных субканалов в одном кадре.

• Поддержка субканалов передачи данных на мультиплексируемых Frame Relay DLCI.

FRF.12

FRF.12 представляет собой соглашение о реализации фрагментации (Fragmentation Implementation Agreement) в сетях Frame Relay. Фрагментация очередей снижает как абсолютное значение задержки, так и вариации задержки в сетях Frame Relay за счет деления больших пакетов на более мелкие части и последующей сборки исходных пакетов на приемной стороне. Такая возможность особенно существенна при одновременной передаче голоса и другого критичного к задержкам трафика (например, критически важные приложения SNA) с нечувствительными к задержкам данными по одному каналу PVC. Основным достоинством фрагментации является возможность использования общих линий доступа UNI или линий NNI и/или PVC для одновременной передачи больших пакетов и критичного к задержкам трафика.

Фрагментация кадров повышает уровень практичности и однородности сетей Frame Relay, снижая задержки и их вариации при улучшении времени отклика приложений. В результате могут поддерживаться многочисленные типы трафика, включая голос, факсимильные сообщения и данные, с использованием единственного UNI, NNI и/или PVC.

Соглашение о фрагментации обеспечивает для терминального (DTE) и коммуникационного (DCE) оборудования Frame Relay возможность передавать большие пакеты данных в виде кадров меньшего размера с последующей сборкой пакетов устройством DTE или DCE на стороне приемника. Фрагментация кадров требуется для контроля задержки и ее вариаций при передаче чувствительного к задержкам трафика (например, телефонного) через один интерфейс с потоками обычных (нечувствительных к задержкам) данных. Фрагментация позволяет чередовать критичный к задержкам трафик одного PVC с фрагментами больших пакетов другого PVC на одном физическом интерфейсе.

FRF.12 поддерживает три варианта фрагментации:

1. Локальная с использованием интерфейса Frame Relay UNI между устройствами DTE/DCE одного ранга.
2. Локальная с использованием интерфейса Frame Relay NNI между устройствами DCE одного ранга.
3. Сквозная между двумя устройствами Frame Relay DTE, соединенными через одну или несколько сетей Frame Relay.

При использовании сквозного режима процедура фрагментации прозрачна для сетей Frame Relay, расположенных между приемным и передающим устройствами DTE.

FREther

FREther представляет собой вариант Frame Relay, который содержит поле EtherType после заголовка Frame Relay. Этот вариант обеспечивает дополнительный способ инкапсуляции в сетях Frame Relay, используемый некоторыми заказчиками.

Timeplex (BRE2)

Фирменный (proprietary) протокол BRE (Bridge Relay Encapsulation), разработанный компанией Ascom Timeplex, позволяет расширять мосты через WAN-каналы за счет инкапсуляции. BRE2 представляет собой расширенный вариант стандарта, который обеспечивает повышение производительности за счет работы на канальном уровне, требующей меньшей настройки, и поддержки собственного протокола маршрутизации. Протокол BRE2 был реализован в программах маршрутизаторов версии 4.0 и поддерживается программами версий 4.x и 5.x.

Кадры BRE2 имеют следующий формат:

<———– 1 байт ————–>	<———– 1 байт —————->
Тип кадра	F	Приоритет
Номер моста Source BRE (2 байта)
Идентификатор домена Source Bridge = 1
Идентификатор VLAN	SRB #
Оставшаяся часть заголовка BRE
7 байтов в нефрагментированном формате
12 байтов в фрагментированном формате
Данные

Формат кадра BRE

Если F = 0, кадр не фрагментирован и заголовок кадра BRE2 имеет длину 17 байтов. Для фрагментированных кадров F = 1 и заголовок BRE2 имеет размер 22 байта. SRB # задает номер моста Source Route (4 бита).

Cascade

Для обеспечения поддержки сервиса Frame Relay компании RBOC (Regional Bell Operating Companies) установили коммутаторы Cascade во множестве LATA и соединили их между собой для организации сервиса через LATA, а также управления коммутаторами во множестве LATA с одной станции.

Формат транкового заголовка для семейства коммутаторов Cascade STDX соответствует спецификации ANSI T1.618-1991 ISDN Core Aspects для использования с Frame Relay Bearer Service.

Формат транкового заголовка Cascade показан на рисунке.

1	2	3	4	8
R	C/R	Версия	Зарезервированы
ODE	DE	BECN	FECN	Приоритет VC
Идентификатор канала
Данные

Формат заголовка транковых кадров Cascade

R

Резервный бит.

C/R

Флаг команда – отклик.

Версия

Версия заголовка, определяющая версию заголовка транкового формата для коммутаторов Cascade STDX. В настоящее время используется версия 0.

ODE

Значение 1 означает, что скорость проникновения (ingress rate) превышает размер «избыточных пакетов» (excess burst size).

DE

Индикатор возможности отбрасывания, устанавливаемый в соответствии со спецификацией ANSI T1.618.

BECN

Обратное уведомление о насыщении в соответствии с ANSI T1.618.

FECN

Прямое уведомление о насыщении в соответствии с ANSI T1.618.

Приоритет VC

Приоритет виртуального устройства, используемый для того, чтобы различить чувствительный к задержкам трафик (например, телефонный) от трафика, некритичного к задержкам (например, передача файлов). Уровень приоритета может принимать значения 1, 2 или 3 (1 означает высший приоритет).

Для данных управления пятый байт содержит сведения о типе PDU:

0 Call request PDU (запрос соединения)

1 Confirmation PDU (подтверждение)

2 Rejected PDU (отказ)

3 Clear PDU (очистка)

4 Disrupt PDU (разрыв)

5 Hello PDU (приветствие)

6 Hello Acknowledgment PDU (подтверждение приветствия)

7 Defined Path Hello PDU (приветствие для заданного пути)

8 Defined Path Hello Acknowledgment PDU (подтверждение приветствия для заданного пути).

LAPF

Назначением протокола LAPF является передача кадров данных канального уровня между пользователями сервиса DL в плоскости U для кадрированного однонаправленного сервиса через пользовательские интерфейсы ISDN на каналах B, D или H. Кадрированные однонаправленные соединения организуются с использованием протоколов, описанных в спецификации Q.933 [3], или (для постоянных виртуальных устройств) путем подписки. LAPF использует сервис физического уровня и позволяет статистически мультиплексировать несколько однонаправленных соединений через один канал ISDN (B, D или H) с помощью процедур LAPF или совместимых с ними процедур HDLC.

Формат заголовка показан на рисунке.

Принятый по умолчанию формат адреса (2 октета)	DLCI верхнего уровня	C/R	EA 0
DLCI нижнего уровня	FECN	BECN	DE	EA 1

Формат адреса LAPF

Биты поля управления (модуль 128)	8	7	6	5	4	3	2	1
Формат I	N(S)	0	Октет 4
N(R)	P/F	Октет 5
Формат S	X	X	X	X	Su	Su	0	1	Октет 4
N(R)	P/F	Октет 5
Формат U	M	M	M	P/F	M	M	1	1	Октет 4

Формат LAPF

EA

Бит расширенной адресации.

C/R

Флаг команда – отклик.

FECN

Прямое уведомление о насыщении.

BECN

Обратное уведомление о насыщении.

DLCI

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

DE

Флаг возможности отбрасывания.

D/C

Флаг управления DLCI или DL-CORE.

N(S)

Порядковый номер передачи.

N(R)

Порядковый номер приема.

P/F

Бит опроса (Poll) для команд или конечный бит для откликов.

X

Зарезервированное поле (0).

Su

Бит функций наблюдения (Supervisory).

M

Бит модификатора функций.

Multiprotocol over Frame Relay

RFC 1490

RFC 2427

Технология Multiprotocol over Frame Relay обеспечивает методы инкапсуляции различных протоколов ЛВС в сетях Frame Relay. В этом случае для инкапсуляции всех протоколов используются кадры Q.922 Annex A. В дополнение к этому кадры должны содержать информацию, необходимую для идентификации протокола, передаваемого в PDU и позволяющую приемнику соответствующим образом обрабатывать входные пакеты. Формат таких кадров показан на рисунке.

Флаг (7Eh)

Адрес Q.922

Управление

Дополнительное поле заполнения (00h)

NLPID

… данные …

FCS

Флаг (7Eh)

Кадр многопротокольной инкапсуляции Frame Relay

Адрес Q.922

2-октетный адрес, содержащий 10-битовое поле DLCI. В некоторых сетях адрес Q.922 может содержать 3 или 4 октета.

Управление

Поле управления Q.922. Если не согласовано иное значение для этого поля, используется принятое по умолчанию значение UI=0x03. Допускается использование XID (0xAF или 0xBF).

Байт заполнения

Используется для выравнивания оставшейся части кадра по границе слова (2 октета). Для заполнения может использоваться один или два октета, содержащие значение 0.

NLPID

Идентификатор протокола сетевого уровня, выдаваемый ISO или CCITT (ITU-T). Этот идентификатор задает инкапсулированный протокол.

FCS

2-байтовая контрольная сумма.

Существует два типа пакетов, передаваемых по сетям Frame Relay – маршрутизируемые пакеты и пакеты мостов. Эти пакеты отличаются форматами и, следовательно, должны содержать идентификатор, позволяющий получателю корректно интерпретировать содержимое пакетов. Индикатор типа кадра встраивается в заголовки SNAP и поле NLPID.

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

Уникальный идентификатор организации (OUI)	Идентификатор протокола (PID)
3 байта	2 байта

Формат заголовка SNAP

Все станции должны быть способны принимать и корректно интерпретировать инкапсуляцию с помощью NLPID и заголовков SNAP для маршрутизируемых пакетов.

Трехоктетный идентификатор OUI указывает организацию, ответственную за администрирование идентификатора протокола (PID), следующего за полем OUI. Оба поля вместе позволяют идентифицировать протокол. Отметим, что OUI=0x00-00-00 указывает, что следующее за ним поле PID содержит значение EtherType.

Некоторые протоколы имеют выделенные для них значения NLPID, но в силу ограниченного числа значений NLPID эти идентификаторы выделяются не для всех протоколов. Когда пакет с таким протоколом (без NLPID) маршрутизируется через сеть Frame Relay, для поля NLPID используется значение 0x80, за которым следует SNAP. Если протокол связан с EtherType, используется OUI=0x00-00-00 и PID=EtherType для используемого протокола. Для выравнивания по границе слова в этом случае используется однобайтовое поле заполнения.

Другой тип трафика Frame Relay составляют пакеты мостов. Для инкапсуляции таких пакетов используется значение NLPID=80, указывающее на использование SNAP. Как и для других протоколов с инкапсуляцией SNAP используется один октет заполнения для выравнивания на границу слова. Заголовок SNAP, следующий за полем NLPID, идентифицирует формат пакета. Значение OUI, используемое при такой инкапсуляции равно 0x00-80-C2. Поле PID заголовка SNAP (два байта после OUI) определяет форму заголовка MAC, который следует после заголовка SNAP. В дополнение к этому PID показывает сохранение исходной контрольной суммы (FCS) в кадре моста.

---

Основы frame relay

Проблемы стандартизации
Логическая характеристика протокола
FR
Процедурная характеристика протокола
FR
Управление доступом и защита от перегрузок
Адресация в сетях FR

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

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

Некоторые рекомендации

---

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

Стандарт — типовой вид, образец, эталон, модель, принимаемые за исходные для сопоставления с ними других подобных объектов (иными словами, объекты должны соответствовать образцу по своим признакам, свойствам и качествам).

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

Интерфейс — соглашение, на основе которого производится взаимодействие между уровнями управления (семиуровневая эталонная модель взаимодействия открытых систем — ЭМВОС) одной системы. Он определяет структуру данных и способ (алгоритм) обмена ими между соседними уровнями.

Таким образом, стандарт может определять либо протокол (совместно процедурную и логическую характеристики или одну из них), либо интерфейс, либо протокол и интерфейс одновременно.

Основы 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.

Рисунок 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 применяется только в оконечном аппаратно-программном обеспечении пользователя и выполняет следующие функции:

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

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

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

При разработке новых стандартов 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) с целью подтверждения целостности соединения, на что сеть отвечает сообщением «Состояние», содержащим требуемый элемент информации о целостности соединения.

Рисунок 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 применяется только в оконечном аппаратно-программном обеспечении пользователя и выполняет следующие функции:

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

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

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

При разработке новых стандартов 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.
Процедура синхронного дуплексного управления.

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

Рисунок 10.
Распределение нумерации кадра при СДУ.

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

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

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

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

сообщение «Запрос состояния» не принято по истечении тайм-аута
(этот интервал имеет международное обозначение T392 и должен быть больше,
чем T391);

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

В этих случаях АКД устанавливает в сообщении «Состояние» бит «активный 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. В пределах этого интервала анализу подвергаются следующие события:

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

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

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

Если за интервал N393 число ошибок превысило порог N392, это интерпретируется как состояние ошибки. В практических реализациях интервал N393 устанавливается ненамного меньшим, чем N391, поскольку иначе при изменении состояния PVC не произойдет своевременное уведомление ООД.

При осуществлении ССУ счетчик времени (T391) используется для определения начала передачи сообщения «Запрос состояния» (запрос о целостности связи) со стороны ООД, а при СДУ — со стороны АКД. Величины T391, устанавливаемые ООД и АКД, могут быть различными.

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

Существует необходимость не только в синхронизации специальных счетчиков событий и времени, но и в установлении максимального размера поля информации кадра FR при взаимодействии ООД-АКД.

Некоторые рекомендации

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

В данной статье были охвачены только те вопросы, которые нашли свое отражение в рекомендациях ITU-T. Однако за ее рамками осталось множество проблем стандартизации FR, связанных с различными воззрениями на этот метод международных организаций по стандартизации и производителей. К требующим первоочередного разрешения проблемам можно отнести следующие:

окончательная доработка и принятие стандарта протокола FR и интерфейса
LMI для PVC;

выработка и принятие единого стандарта для SVC;

выработка единого подхода и принятие решения о системе международной
(межсетевой) адресации и др.

(В дальнейшем автор намерен посвятить этим проблемам несколько публикаций.)

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

1. Создание и обслуживание сети FR — «удовольствие дорогое», поэтому сначала необходимо соизмерить свои возможности с реальными потребностями.

2. Нужно провести тщательную проверку (в том числе на предмет профессионализма сотрудников) потенциального поставщика услуг, чтобы выяснить: а) не является ли эта фирма «дутой» (она может продать вам ООД или создать сеть FR, а потом «лопнуть»; тогда вы останетесь с «грудой железа», которое невозможно либо очень дорого адаптировать к другим сетям); б) обеспечивается ли информационная безопасность приобретенного ООД или созданной сети, т. е. нет ли возможности «постороннего воздействия» (прямого и/или косвенного) на конфиденциальную информацию, циркулирующую в вашей сети.

3. Заключая договор c оператором на подключение к сети FR (покупая у него ООД) или с сетевым интегратором на создание корпоративной сети FR, необходимо предусмотреть в договоре пункт, в котором будут оговариваться условия эксплуатации и обслуживания вашего ООД или АКД. Они должны предусматривать: во-первых, бесплатную (либо за минимальную цену) замену или модернизацию аппаратно-программных средств при переходе на новые (усовершенствованные) стандарты FR; во-вторых, предоставление пользователям данной сети FR доступа к пользователям других сетей FR, применяющим ООД других стандартов FR, или обеспечение интеграции ведомственной сети (с помощью соответствующих «шлюзов») с другими сетями FR, также функционирующими на основе других стандартов FR.

---

Дмитрий Мельников — сотрудник учебно-методического центра
новых информационных технологий (УМЦ НИТ) ФАПСИ. С ним можно связаться
по факсу (095) 925-85-96.

From Wikipedia, the free encyclopedia

Frame Relay is a standardized wide area network (WAN) technology that specifies the physical and data link layers of digital telecommunications channels using a packet switching methodology. Originally designed for transport across Integrated Services Digital Network (ISDN) infrastructure, it may be used today in the context of many other network interfaces.

Network providers commonly implement Frame Relay for voice (VoFR) and data as an encapsulation technique used between local area networks (LANs) over a WAN. Each end-user gets a private line (or leased line) to a Frame Relay node. The Frame Relay network handles the transmission over a frequently changing path transparent to all end-user extensively used WAN protocols. It is less expensive than leased lines and that is one reason for its popularity. The extreme simplicity of configuring user equipment in a Frame Relay network offers another reason for Frame Relay’s popularity.

With the advent of Ethernet over fiber optics, MPLS, VPN and dedicated broadband services such as cable modem and DSL, Frame Relay has become less popular in recent years.

Technical description[edit]

The designers of Frame Relay aimed to provide a telecommunication service for cost-efficient data transmission for intermittent traffic between local area networks (LANs) and between end-points in a wide area network (WAN). Frame Relay puts data in variable-size units called «frames» and leaves any necessary error-correction (such as retransmission of data) up to the end-points. This speeds up overall data transmission. For most services, the network provides a permanent virtual circuit (PVC), which means that the customer sees a continuous, dedicated connection without having to pay for a full-time leased line, while the service-provider figures out the route each frame travels to its destination and can charge based on usage.

An enterprise can select a level of service quality, prioritizing some frames and making others less important. Frame Relay can run on fractional T-1 or full T-carrier system carriers (outside the Americas, E1 or full E-carrier). Frame Relay complements and provides a mid-range service between basic rate ISDN, which offers bandwidth at 128 kbit/s, and Asynchronous Transfer Mode (ATM), which operates in somewhat similar fashion to Frame Relay but at speeds from 155.520 Mbit/s to 622.080 Mbit/s.^[1]

Frame Relay has its technical base in the older X.25 packet-switching technology, designed for transmitting data on analog voice lines. Unlike X.25, whose designers expected analog signals with a relatively high chance of transmission errors, Frame Relay is a fast packet switching technology operating over links with a low chance of transmission errors (usually practically lossless like PDH), which means that the protocol does not attempt to correct errors. When a Frame Relay network detects an error in a frame, it simply drops that frame. The end points have the responsibility for detecting and retransmitting dropped frames. (However, digital networks offer an incidence of error extraordinarily small relative to that of analog networks.)

Frame Relay often serves to connect local area networks (LANs) with major backbones, as well as on public wide-area networks (WANs) and also in private network environments with leased lines over T-1 lines. It requires a dedicated connection during the transmission period. Frame Relay does not provide an ideal path for voice or video transmission, both of which require a steady flow of transmissions. However, under certain circumstances, voice and video transmission do use Frame Relay.

Frame Relay originated as an extension of integrated services digital network (ISDN). Its designers aimed to enable a packet-switched network to transport over circuit-switched technology. The technology has become a stand-alone and cost-effective means of creating a WAN.

Frame Relay switches create virtual circuits to connect remote LANs to a WAN. The Frame Relay network exists between a LAN border device, usually a router, and the carrier switch. The technology used by the carrier to transport data between the switches is variable and may differ among carriers (i.e., to function, a practical Frame Relay implementation need not rely solely on its own transportation mechanism).

The sophistication of the technology requires a thorough understanding of the terms used to describe how Frame Relay works. Without a firm understanding of Frame Relay, it is difficult to troubleshoot its performance.

Frame-relay frame structure essentially mirrors almost exactly that defined for LAP-D. Traffic analysis can distinguish Frame Relay format from LAP-D by its lack of a control field.^[2]

Protocol data unit[edit]

Each Frame Relay protocol data unit (PDU) consists of the following fields:

1. Flag Field. The flag is used to perform high-level data link synchronization which indicates the beginning and end of the frame with the unique pattern 01111110. To ensure that the 01111110 pattern does not appear somewhere inside the frame, bit stuffing and destuffing procedures are used.
2. Address Field. Each address field may occupy either octet 2 to 3, octet 2 to 4, or octet 2 to 5, depending on the range of the address in use. A two-octet address field comprises the EA=ADDRESS FIELD EXTENSION BITS and the C/R=COMMAND/RESPONSE BIT.

   

   1. DLCI-Data Link Connection Identifier Bits. The DLCI serves to identify the virtual connection so that the receiving end knows which information connection a frame belongs to. Note that this DLCI has only local significance. A single physical channel can multiplex several different virtual connections.
   2. FECN, BECN, DE bits. These bits report congestion:
      • FECN=Forward Explicit Congestion Notification bit
      • BECN=Backward Explicit Congestion Notification bit
      • DE=Discard Eligibility bit
3. Information Field. A system parameter defines the maximum number of data bytes that a host can pack into a frame. Hosts may negotiate the actual maximum frame length at call set-up time. The standard specifies the maximum information field size (supportable by any network) as at least 262 octets. Since end-to-end protocols typically operate on the basis of larger information units, Frame Relay recommends that the network support the maximum value of at least 1600 octets in order to avoid the need for segmentation and reassembling by end-users.
4. Frame Check Sequence (FCS) Field. Since one cannot completely ignore the bit error-rate of the medium, each switching node needs to implement error detection to avoid wasting bandwidth due to the transmission of erred frames. The error detection mechanism used in Frame Relay uses the cyclic redundancy check (CRC) as its basis.

Congestion control[edit]

The Frame Relay network uses a simplified protocol at each switching node. It achieves simplicity by omitting link-by-link flow-control. As a result, the offered load has largely determined the performance of Frame Relay networks. When offered load is high, due to the bursts in some services, temporary overload at some Frame Relay nodes causes a collapse in network throughput. Therefore, Frame Relay networks require some effective mechanisms to control the congestion.

Congestion control in Frame Relay networks includes the following elements:

1. Admission Control. This provides the principal mechanism used in Frame Relay to ensure the guarantee of resource requirement once accepted. It also serves generally to achieve high network performance. The network decides whether to accept a new connection request, based on the relation of the requested traffic descriptor and the network’s residual capacity. The traffic descriptor consists of a set of parameters communicated to the switching nodes at call set-up time or at service-subscription time, and which characterizes the connection’s statistical properties. The traffic descriptor consists of three elements:
2. Committed Information Rate (CIR). The average rate (in bit/s) at which the network guarantees to transfer information units over a measurement interval T. This T interval is defined as: T = Bc/CIR.
3. Committed Burst Size (BC). The maximum number of information units transmittable during the interval T.
4. Excess Burst Size (BE). The maximum number of uncommitted information units (in bits) that the network will attempt to carry during the interval.

Once the network has established a connection, the edge node of the Frame Relay network must monitor the connection’s traffic flow to ensure that the actual usage of network resources does not exceed this specification. Frame Relay defines some restrictions on the user’s information rate. It allows the network to enforce the end user’s information rate and discard information when the subscribed access rate is exceeded.

Explicit congestion notification is proposed as the congestion avoidance policy. It tries to keep the network operating at its desired equilibrium point so that a certain quality of service (QoS) for the network can be met. To do so, special congestion control bits have been incorporated into the address field of the Frame Relay: FECN and BECN. The basic idea is to avoid data accumulation inside the network.

FECN means forward explicit congestion notification. The FECN bit can be set to 1 to indicate that congestion was experienced in the direction of the frame transmission, so it informs the destination that congestion has occurred.
BECN means backwards explicit congestion notification. The BECN bit can be set to 1 to indicate that congestion was experienced in the network in the direction opposite of the frame transmission, so it informs the sender that congestion has occurred.

Origin[edit]

Frame Relay began as a stripped-down version of the X.25 protocol, releasing itself from the error-correcting burden most commonly associated with X.25. When Frame Relay detects an error, it simply drops the offending packet. Frame Relay uses the concept of shared access and relies on a technique referred to as «best-effort», whereby error-correction practically does not exist and practically no guarantee of reliable data delivery occurs. Frame Relay provides an industry-standard encapsulation, utilizing the strengths of high-speed, packet-switched technology able to service multiple virtual circuits and protocols between connected devices, such as two routers.
Although Frame Relay became very popular in North America, it was never very popular in Europe. X.25 remained the primary standard until the wide availability of IP made packet switching almost obsolete.
It was used sometimes as backbone for other services, such as X.25 or IP traffic. Where Frame Relay was used in the USA also as carrier for TCP/IP traffic, in Europe backbones for IP networks often used ATM or PoS, later replaced by Carrier Ethernet^[3]

Relationship to X.25[edit]

X.25 was an important early WAN protocol, and is often considered to be the grandfather of Frame Relay as many of the underlying protocols and functions of X.25 are still in use today (with upgrades) by Frame Relay.^[5]

X.25 provides quality of service and error-free delivery, whereas Frame Relay was designed to relay data as quickly as possible over low error networks. Frame Relay eliminates a number of the higher-level procedures and fields used in X.25. Frame Relay was designed for use on links with error-rates far lower than available when X.25 was designed.

X.25 prepares and sends packets, while Frame Relay prepares and sends frames. X.25 packets contain several fields used for error checking and flow control, most of which are not used by Frame Relay. The frames in Frame Relay contain an expanded link layer address field that enables Frame Relay nodes to direct frames to their destinations with minimal processing. The elimination of functions and fields over X.25 allows Frame Relay to move data more quickly, but leaves more room for errors and larger delays should data need to be retransmitted.

X.25 packet switched networks typically allocated a fixed bandwidth through the network for each X.25 access, regardless of the current load. This resource allocation approach, while apt for applications that require guaranteed quality of service, is inefficient for applications that are highly dynamic in their load characteristics or which would benefit from a more dynamic resource allocation. Frame Relay networks can dynamically allocate bandwidth at both the physical and logical channel level.

Virtual circuits[edit]

As a WAN protocol, Frame Relay is most commonly implemented at Layer 2 (data link layer) of the Open Systems Interconnection (OSI) seven layer model. Two types of circuits exist: permanent virtual circuits (PVCs) which are used to form logical end-to-end links mapped over a physical network, and switched virtual circuits (SVCs). The latter are analogous to the circuit-switching concepts of the public switched telephone network (PSTN), the global phone network.

Local management interface[edit]

Initial proposals for Frame Relay were presented to the Consultative Committee on International Telephone and Telegraph (CCITT) in 1984. Lack of interoperability and standardization prevented any significant Frame Relay deployment until 1990, when Cisco, Digital Equipment Corporation (DEC), Northern Telecom, and StrataCom formed a consortium to focus on its development. They produced a protocol that provided additional capabilities for complex inter-networking environments. These Frame Relay extensions are referred to as the local management interface (LMI).

Datalink connection identifiers (DLCIs) are numbers that refer to paths through the Frame Relay network. They are only locally significant, which means that when device-A sends data to device-B it will most likely use a different DLCI than device-B would use to reply. Multiple virtual circuits can be active on the same physical end-points (performed by using subinterfaces).

The LMI global addressing extension gives Frame Relay data-link connection identifier (DLCI) values global rather than local significance. DLCI values become DTE addresses that are unique in the Frame Relay WAN. The global addressing extension adds functionality and manageability to Frame Relay internetworks. Individual network interfaces and the end nodes attached to them, for example, can be identified by using standard address-resolution and discovery techniques. In addition, the entire Frame Relay network appears to be a typical LAN to routers on its periphery.

LMI virtual circuit status messages provide communication and synchronization between Frame Relay DTE and DCE devices. These messages are used to periodically report on the status of PVCs, which prevents data from being sent into black holes (that is, over PVCs that no longer exist).

The LMI multicasting extension allows multicast groups to be assigned. Multicasting saves bandwidth by allowing routing updates and address-resolution messages to be sent only to specific groups of routers. The extension also transmits reports on the status of multicast groups in update messages.

Committed information rate[edit]

Frame Relay connections are often given a committed information rate (CIR) and an allowance of burstable bandwidth known as the extended information rate (EIR). The provider guarantees that the connection will always support the C rate, and sometimes the PRa rate should there be adequate bandwidth. Frames that are sent in excess of the CIR are marked as discard eligible (DE) which means they can be dropped should congestion occur within the Frame Relay network. Frames sent in excess of the EIR are dropped immediately.

Market reputation[edit]

Frame Relay aimed to make more efficient use of existing physical resources, permitting the over-provisioning of data services by telecommunications companies to their customers, as clients were unlikely to be using a data service 45 percent of the time. In more recent years, Frame Relay has acquired a bad reputation in some markets because of excessive bandwidth overbooking.^{[citation needed]}

Telecommunications companies often sell Frame Relay to businesses looking for a cheaper alternative to dedicated lines; its use in different geographic areas depended greatly on governmental and telecommunication companies’ policies. Some of the early companies to make Frame Relay products included StrataCom (later acquired by Cisco Systems) and Cascade Communications (later acquired by Ascend Communications and then by Lucent Technologies).

As of June 2007, AT&T was the largest Frame Relay service provider in the US, with local networks in 22 states, plus national and international networks.^{[citation needed]}

FRF.12[edit]

When multiplexing packet data from different virtual circuits or flows, quality of service concerns often arise. This is because a frame from one virtual circuit may occupy the line for a long enough period of time to disrupt a service guarantee given to another virtual circuit. IP fragmentation is a method for addressing this. An incoming long packet is broken up into a sequence of shorter packets and enough information is added to reassemble that long frame at the far end. FRF.12 is a specification from the Frame Relay Forum which specifies how to perform fragmentation on frame relay traffic primarily for voice traffic. The FRF.12 specification describes the method of fragmenting Frame Relay frames into smaller frames.^{[6][7][8][9][10]}

See also[edit]

• Multiprotocol Label Switching
• List of interface bit rates

References[edit]

External links[edit]

• RFC 1490 – Multiprotocol Interconnect over Frame Relay
• RFC 1973 – PPP in Frame Relay
• RFC 2427 – Multiprotocol Interconnect over Frame Relay
• Broadband Forum — IP/MPLS Forum, MPLS Forum, ATM, and Frame Relay Forum Specifications
• Cisco Frame Relay Tutorial
• Frame Relay animation
• CCITT I.233 ISDN Frame Mode Bearer Services

Технология глобальной сети Базовая сеть Frame Relay

Frame Relay — это стандартизированная сеть технология локальной сети, которая определяет физический и канальный уровни цифровых телекоммуникационных каналов с использованием методологии коммутации пакетов. Первоначально разработанный для транспортировки через инфраструктуру цифровой сети с интеграцией служб (ISDN), он может использоваться сегодня в контексте многих других сетевых интерфейсов.

Сетевые провайдеры обычно реализуют Frame Relay для голоса (VoFR ) и данных как метод инкапсуляции, используемый между локальными сетями (LAN) по глобальная сеть (WAN). Каждый конечный пользователь получает частную линию (или выделенную линию ) на узел Frame Relay . Сеть Frame Relay обрабатывает передачу по часто изменяющемуся пути, прозрачному для всех широко используемых конечными пользователями протоколов WAN. Он дешевле, чем выделенные линии, и это одна из причин его популярности. Чрезвычайная простота настройки пользовательского оборудования в сети Frame Relay — еще одна причина популярности Frame Relay.

С появлением Ethernet по оптоволокну, MPLS, VPN и выделенных широкополосных услуг, таких как кабельный модем и DSL, конец может вырисовываться для протокола Frame Relay и инкапсуляции.

Содержание

• 1 Техническое описание
  • 1.1 Блок данных протокола
  • 1.2 Контроль перегрузки
• 2 Источник
  • 2.1 Связь с X.25
• 3 Виртуальные каналы
• 4 Локальный интерфейс управления
• 5 Обязательная скорость передачи информации (CIR)
• 6 Репутация на рынке
• 7 FRF.12
• 8 См. Также
• 9 Ссылки
• 10 Внешние ссылки

Техническое описание

Разработчики Frame Relay стремились предоставить телекоммуникационные услуги для экономичной передачи данных для прерывистого трафика между локальные сети (LAN) и между конечными точками в глобальной сети (WAN). Frame Relay помещает данные в блоки переменного размера, называемые «кадрами», и оставляет все необходимые исправления ошибок (такие как повторная передача данных) до конечных точек. Это ускоряет общую передачу данных. Для большинства услуг сеть предоставляет постоянный виртуальный канал (PVC), что означает, что клиент видит непрерывное выделенное соединение без необходимости платить за постоянную выделенную линию, в то время как поставщик услуг определяет маршрут, по которому каждый фрейм идет к месту назначения, и может взимать плату в зависимости от использования.

Предприятие может выбрать уровень качества обслуживания, отдавая приоритет одним кадрам и делая другие менее важными. Frame Relay может работать на частичном T-1 или полном T-carrier системных носителях (за пределами Северной и Южной Америки, E1 или полный E-carrier ). Frame Relay дополняет и предоставляет услуги среднего уровня между базовой скоростью ISDN, которая предлагает полосу пропускания на 128 кбит / с, и асинхронным режимом передачи (ATM), который работает в некоторой степени аналогичным образом. к Frame Relay, но со скоростью от 155,520 Мбит / с до 622,080 Мбит / с.

Frame Relay имеет свою техническую основу в более старой технологии X.25 с коммутацией пакетов, предназначенной для передачи данных на аналоговых голосовых линиях. В отличие от X.25, разработчики которого ожидали аналоговых сигналов с относительно высокой вероятностью ошибок передачи, Frame Relay — это технология быстрой коммутации пакетов, работающая по каналам с низкой вероятностью ошибок передачи ( обычно практически без потерь, например PDH ), что означает, что протокол не пытается исправлять ошибки. Когда сеть Frame Relay обнаруживает ошибку в кадре, она просто отбрасывает этот кадр. Конечные точки несут ответственность за обнаружение и повторную передачу пропущенных кадров. (Однако цифровые сети имеют чрезвычайно низкую вероятность ошибки по сравнению с аналоговыми сетями.)

Frame Relay часто служит для соединения локальных сетей (LAN) с основными магистралями , а также в публичных глобальных сетях (WAN), а также в частных сетевых средах с выделенными линиями по линиям T-1. Для этого требуется выделенное соединение в период передачи. Frame Relay не обеспечивает идеального пути для передачи голоса или видео, и то и другое требует постоянного потока передач. Однако при определенных обстоятельствах для передачи голоса и видео используется Frame Relay.

Frame Relay возникла как расширение цифровой сети с интегрированными услугами (ISDN). Его разработчики стремились сделать так, чтобы сеть с коммутацией пакетов могла передавать по технологии с коммутацией каналов. Технология стала автономным и экономичным средством создания глобальной сети.

Коммутаторы Frame Relay создают виртуальные каналы для подключения удаленных локальных сетей к глобальной сети. Сеть Frame Relay существует между пограничным устройством LAN, обычно маршрутизатором, и коммутатором оператора связи. Технология, используемая оператором для передачи данных между коммутаторами, варьируется и может различаться для разных операторов (то есть для работы практическая реализация Frame Relay не обязательно должна полагаться исключительно на собственный механизм транспортировки).

Сложность технологии требует глубокого понимания терминов, используемых для описания работы Frame Relay. Без четкого понимания работы Frame Relay трудно устранить его производительность.

Структура кадра ретрансляции кадров практически точно отражает структуру, определенную для LAP-D. Анализ трафика позволяет отличить формат Frame Relay от LAP-D по отсутствию поля управления.

Блок данных протокола

Каждый блок данных протокола (PDU) Frame Relay состоит из следующих полей:

1. Поле флага . Флаг используется для выполнения высокоуровневой синхронизации канала данных, которая указывает начало и конец кадра с уникальным шаблоном 01111110. Чтобы гарантировать, что шаблон 01111110 не появляется где-то внутри кадра, вставка битов и удаление используются процедуры.
2. Адресное поле . Каждое поле адреса может занимать октеты со 2 по 3, со 2 по 4 или со 2 по 5, в зависимости от диапазона используемого адреса. Двухоктетное поле адреса состоит из БИТОВ РАСШИРЕНИЯ ПОЛЯ АДРЕСА = EA = и БИТА C / R = КОМАНДА / ОТВЕТ.
   1. DLCI — биты идентификатора соединения канала передачи данных. DLCI служит для идентификации виртуального соединения, чтобы принимающая сторона знала, к какому информационному соединению принадлежит кадр. Обратите внимание, что этот DLCI имеет только локальное значение. Один физический канал может мультиплексировать несколько различных виртуальных соединений.
   2. биты FECN, BECN, DE . Эти биты сообщают о перегрузке:
      • FECN = Бит прямого уведомления о явной перегрузке
      • BECN = Бит обратного явного уведомления о перегрузке
      • DE= Бит отклонения права доступа
3. Информационное поле . Системный параметр определяет максимальное количество байтов данных, которое хост может упаковать в кадр. Хосты могут согласовывать фактическую максимальную длину кадра во время установления соединения. Стандарт определяет максимальный размер информационного поля (поддерживаемый любой сетью) как минимум 262 октета. Поскольку сквозные протоколы обычно работают на основе более крупных информационных единиц, Frame Relay рекомендует, чтобы сеть поддерживала максимальное значение не менее 1600 октетов, чтобы избежать необходимости сегментации и повторной сборки конечными пользователями.
4. Поле последовательности проверки кадра (FCS). Поскольку нельзя полностью игнорировать частоту ошибок по битам среды, каждый коммутационный узел должен реализовать обнаружение ошибок, чтобы избежать потери полосы пропускания из-за передачи ошибочных кадров. Механизм обнаружения ошибок, используемый в Frame Relay, использует в качестве основы циклический контроль избыточности (CRC).

Контроль перегрузки

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

Контроль перегрузки в сетях Frame Relay включает следующие элементы:

1. Контроль допуска. Это обеспечивает основной механизм, используемый в Frame Relay, чтобы гарантировать гарантию потребности в ресурсах после принятия. Это также обычно служит для достижения высокой производительности сети. Сеть решает, принимать ли новый запрос на соединение, на основании соотношения запрошенного дескриптора трафика и остаточной пропускной способности сети. Дескриптор трафика состоит из набора параметров, передаваемых узлам коммутации во время установления вызова или во время подписки на услугу, и который характеризует статистические свойства соединения. Дескриптор трафика состоит из трех элементов:
2. согласованная скорость передачи информации (CIR). Средняя скорость (в бит / с), с которой сеть гарантирует передачу единиц информации в течение интервала измерения T. Этот интервал T определяется как: T = Bc / CIR.
3. (BC). Максимальное количество единиц информации, передаваемых в течение интервала T.
4. Превышение размера пакета (BE). Максимальное количество незафиксированных информационных единиц (в битах), которые сеть будет пытаться передать в течение интервала.

После того, как сеть установила соединение, граничный узел сети Frame Relay должен контролировать поток трафика соединения, чтобы гарантировать, что фактическое использование сетевых ресурсов не превышает этой спецификации. Frame Relay определяет некоторые ограничения на скорость передачи информации пользователя. Это позволяет сети устанавливать скорость передачи информации конечного пользователя и отбрасывать информацию при превышении скорости доступа по подписке.

Явное уведомление о перегрузке предлагается в качестве политики предотвращения перегрузки. Он пытается поддерживать работу сети в желаемой точке равновесия, чтобы можно было обеспечить определенное качество обслуживания (QoS) для сети. Для этого в поле адреса Frame Relay были включены специальные биты управления перегрузкой: FECN и BECN. Основная идея — избежать накопления данных внутри сети.

FECN означает прямое уведомление о перегрузке. Бит FECN может быть установлен в 1, чтобы указать, что возникла перегрузка в направлении передачи кадра, поэтому он информирует пункт назначения о возникновении перегрузки. BECN означает обратное явное уведомление о перегрузке. Бит BECN может быть установлен в 1, чтобы указать, что в сети возникла перегрузка в направлении, противоположном передаче кадра, поэтому он информирует отправителя о возникновении перегрузки.

Origin

Frame Relay начинался как урезанная версия протокола X.25, освобождающая себя от бремени исправления ошибок, обычно связанного с X.25. Когда Frame Relay обнаруживает ошибку, он просто отбрасывает ошибочный пакет. Frame Relay использует концепцию совместного доступа и опирается на метод, называемый «максимальным усилием», при котором исправление ошибок практически не существует и практически не возникает никаких гарантий надежной доставки данных. Frame Relay обеспечивает инкапсуляцию отраслевого стандарта, используя сильные стороны высокоскоростной технологии с коммутацией пакетов, способной обслуживать несколько виртуальных каналов и протоколов между подключенными устройствами, такими как два маршрутизатора.. Хотя Frame Relay стал очень популярным в Северной Америке, он никогда не был очень популярен в Европе. X.25 оставался основным стандартом до тех пор, пока широкая доступность IP не сделала коммутацию пакетов почти устаревшей. Иногда он использовался в качестве магистрали для других сервисов, таких как X.25 или IP-трафик. Если в США Frame Relay использовался также в качестве носителя для трафика TCP / IP, в Европе магистральные сети для IP-сетей часто использовали ATM или PoS, позже замененные на Carrier Ethernet

Отношение к X. 25

X.25 обеспечивает качество обслуживания и безошибочную доставку, тогда как Frame Relay был разработан для максимально быстрой передачи данных по сетям с низким уровнем ошибок. Frame Relay исключает ряд процедур и полей более высокого уровня, используемых в X.25. Frame Relay был разработан для использования на каналах с гораздо меньшей частотой ошибок, чем это было при разработке X.25.

X.25 подготавливает и отправляет пакеты, в то время как Frame Relay готовит и отправляет кадры. Пакеты X.25 содержат несколько полей, используемых для проверки ошибок и управления потоком, большинство из которых не используются Frame Relay. Кадры в Frame Relay содержат расширенное поле адреса канального уровня, которое позволяет узлам Frame Relay направлять кадры по назначению с минимальной обработкой. Исключение функций и полей в X.25 позволяет Frame Relay перемещать данные быстрее, но оставляет больше места для ошибок и больших задержек в случае необходимости повторной передачи данных.

Сети с коммутацией пакетов X.25 обычно выделяют фиксированную полосу пропускания через сеть для каждого доступа X.25, независимо от текущей нагрузки. Этот подход распределения ресурсов, хотя и подходит для приложений, требующих гарантированного качества обслуживания, неэффективен для приложений, которые очень динамичны по своим характеристикам нагрузки или которым было бы полезно более динамическое распределение ресурсов. Сети Frame Relay могут динамически распределять полосу пропускания как на физическом, так и на логическом уровне каналов.

Виртуальные каналы

Как протокол WAN, Frame Relay чаще всего реализуется на уровне 2 (канальный уровень ) взаимодействия открытых систем (OSI) семислойная модель. Существует два типа каналов: постоянные виртуальные каналы (PVC), которые используются для формирования логических сквозных соединений, отображаемых в физической сети, и коммутируемые виртуальные каналы (SVC). Последние аналогичны концепциям коммутации каналов телефонной сети общего пользования (PSTN), глобальной телефонной сети.

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

Первоначальные предложения по Frame Relay были представлены Консультативному комитету по международной телефонной и телеграфной связи (CCITT ) в 1984 году. Отсутствие функциональной совместимости и стандартизации препятствовало любому значительное развертывание Frame Relay до 1990 года, когда Cisco, Digital Equipment Corporation (DEC), Northern Telecom и StrataCom сформировали консорциум для сосредоточиться на его развитии. Они разработали протокол, который предоставил дополнительные возможности для сложных межсетевых сред. Эти расширения Frame Relay называются локальным интерфейсом управления (LMI).

Идентификаторы соединения Datalink (DLCI ) — это числа, которые относятся к путям в сети Frame Relay. Они имеют значение только локально, что означает, что когда устройство-A отправляет данные устройству-B, оно, скорее всего, будет использовать другой DLCI, чем устройство-B для ответа. Несколько виртуальных каналов могут быть активны на одних и тех же физических конечных точках (выполняется с помощью подынтерфейсов ).

Расширение глобальной адресации LMI придает значения идентификатора соединения канала данных Frame Relay (DLCI) глобальное, а не локальное значение. Значения DLCI становятся адресами DTE, которые уникальны в глобальной сети Frame Relay. Расширение глобальной адресации добавляет функциональность и управляемость объединенным сетям Frame Relay. Например, отдельные сетевые интерфейсы и присоединенные к ним конечные узлы могут быть идентифицированы с помощью стандартных методов разрешения адресов и обнаружения. Кроме того, вся сеть Frame Relay выглядит как типичная локальная сеть для маршрутизаторов на ее периферии.

Сообщения о состоянии виртуальных каналов LMI обеспечивают связь и синхронизацию между устройствами Frame Relay DTE и DCE. Эти сообщения используются для периодического отчета о состоянии PVC, что предотвращает отправку данных в черные дыры (то есть через PVC, которые больше не существуют).

Расширение многоадресной рассылки LMI позволяет назначать группы многоадресной рассылки. Многоадресная рассылка экономит полосу пропускания, позволяя отправлять обновления маршрутизации и сообщения разрешения адресов только определенным группам маршрутизаторов. Расширение также передает отчеты о состоянии групп многоадресной рассылки в сообщениях обновления.

Согласованная скорость передачи данных (CIR)

Соединения Frame Relay часто получают подтвержденную скорость передачи данных (CIR) и допускают известную пакетную полосу пропускания как расширенная скорость передачи информации (EIR). Провайдер гарантирует, что соединение всегда будет поддерживать скорость C, а иногда и скорость PRa, если имеется адекватная пропускная способность. Кадры, которые отправляются сверх CIR, помечаются как допустимые для отбрасывания (DE), что означает, что они могут быть отброшены в случае возникновения перегрузки в сети Frame Relay. Фреймы, отправленные сверх EIR, немедленно отбрасываются.

Репутация на рынке

Frame Relay была нацелена на более эффективное использование существующих физических ресурсов, позволяя телекоммуникационным компаниям предоставлять своим клиентам избыточные услуги передачи данных, поскольку клиенты вряд ли будут использовать служба передачи данных в 45% случаев. В последние годы Frame Relay приобрел плохую репутацию на некоторых рынках из-за чрезмерной пропускной способности избыточного бронирования.

Телекоммуникационные компании часто продают Frame Relay предприятиям, которые ищут более дешевую альтернативу выделенным линиям ; его использование в различных географических регионах во многом зависит от политики правительства и телекоммуникационных компаний. Среди первых компаний, производивших продукты Frame Relay, были StrataCom (позже приобретенная Cisco Systems ) и Cascade Communications (позже приобретенная Ascend Communications, а затем Lucent Technologies ).

По состоянию на июнь 2007 года ATT была крупнейшим поставщиком услуг Frame Relay в США с локальными сетями в 22 штатах, а также национальными и международными сетями.

FRF. 12

При мультиплексировании пакетных данных из разных виртуальных каналов или потоков часто возникают вопросы качества обслуживания. Это связано с тем, что кадр из одного виртуального канала может занимать линию в течение достаточно длительного периода времени, чтобы нарушить гарантию обслуживания, предоставленную другому виртуальному каналу. IP-фрагментация — способ решения этой проблемы. Входящий длинный пакет разбивается на последовательность более коротких пакетов, и добавляется достаточно информации для повторной сборки этого длинного кадра на дальнем конце. FRF.12 — это спецификация форума Frame Relay Forum, в котором указывается, как выполнять фрагментацию трафика Frame Relay в первую очередь для голосового трафика. Спецификация FRF.12 описывает метод фрагментации кадров Frame Relay на более мелкие кадры.

См. Также

Ссылки

Внешние links