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) в кадре моста.