Frame relay что это

Frame Relay – это технология пакетной коммутации канального уровня, разработанная для построения глобальных сетей передачи данных между территориально распределёнными узлами. Протокол был стандартизирован ITU-T и ANSI и широко применялся в корпоративных WAN-сетях в период, когда аренда выделенных линий имела высокую стоимость, а IP/MPLS ещё не получил массового распространения.

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

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

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

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

Frame Relay: что это и как работает протокол

Frame Relay – протокол канального уровня модели OSI, ориентированный на быструю передачу кадров между узлами глобальной сети через инфраструктуру оператора связи. Он использует принцип виртуальных соединений, при котором физический канал разделяется на несколько логических путей. Каждый путь определяется числовым идентификатором DLCI, который имеет локальное значение и назначается провайдером.

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

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

Для реакции на перегрузку используются специальные биты управления. FECN уведомляет получателя о заторе на прямом направлении, BECN – отправителя о необходимости снизить скорость передачи, DE помечает кадры, которые могут быть отброшены при превышении согласованной скорости. При проектировании канала важно учитывать параметры CIR и BC, так как их некорректный расчёт приводит к потере данных.

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

Назначение Frame Relay в корпоративных WAN-сетях

Frame Relay применялся в корпоративных WAN-сетях для организации постоянных логических соединений между центральным офисом и удалёнными подразделениями через инфраструктуру оператора связи. Технология позволяла заменить набор выделенных линий одной физической точкой доступа, на которой создавались десятки виртуальных каналов с индивидуальными параметрами пропускной способности.

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

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

Отсутствие встроенного контроля доставки делало Frame Relay подходящим для приложений, устойчивых к потерям пакетов или использующих собственные механизмы восстановления. При планировании корпоративной WAN-сети рекомендовалось ограничивать объём burst-трафика и настраивать приоритеты на маршрутизаторах, чтобы избежать пометки кадров битом DE в периоды пиковых нагрузок.

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

Типы виртуальных каналов: PVC и SVC на практике

В Frame Relay используются два типа виртуальных каналов: PVC (Permanent Virtual Circuit) и SVC (Switched Virtual Circuit). Оба варианта работают поверх одной физической линии, но различаются способом создания, управлением и областью применения в корпоративных WAN-сетях.

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

На практике PVC использовались для постоянных потоков данных: репликации баз данных, терминального доступа, передачи транзакций. Рекомендовалось жёстко привязывать критичные приложения к отдельным PVC и не смешивать их с фоновым трафиком, чтобы избежать перегрузки и пометки кадров битом DE.

SVC создавались динамически по запросу и разрывались после завершения передачи данных. Такой подход предполагал использование сигнализации и временное выделение ресурсов сети. В реальных корпоративных внедрениях SVC встречались редко из-за сложности поддержки, задержек при установке соединения и ограниченной поддержки со стороны оборудования операторов.

При выборе между PVC и SVC в сетях Frame Relay предпочтение практически всегда отдавалось PVC. Они проще в администрировании, легче поддаются мониторингу и позволяют заранее рассчитать нагрузку на WAN-каналы. SVC рассматривались как вспомогательный механизм для нерегулярных соединений, но в большинстве проектов от них отказывались на этапе проектирования.

Роль идентификаторов DLCI при передаче кадров

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

На практике DLCI выполняет несколько прикладных задач:

• определяет принадлежность кадра конкретному PVC или SVC;
• позволяет разделять трафик разных филиалов на одном физическом интерфейсе;
• используется для привязки параметров пропускной способности и приоритетов;
• участвует в механизмах сигнализации перегрузки сети.

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

При внедрении Frame Relay рекомендуется придерживаться упорядоченной схемы назначения DLCI:

1. выделять отдельные диапазоны для разных регионов или групп филиалов;
2. не использовать одинаковые значения DLCI для разных каналов на одном интерфейсе;
3. документировать соответствие DLCI и удалённых узлов для упрощения диагностики.

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

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

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

Основной элемент заголовка – поле DLCI, занимающее 10 бит и определяющее виртуальный канал, по которому будет передан кадр. Вместе с ним в заголовке присутствуют управляющие биты FECN, BECN и DE, которые используются для сигнализации состояния сети. Эти значения не изменяют маршрут кадра, но влияют на обработку трафика на стороне отправителя и получателя.

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

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

Обработка заголовка выполняется каждым коммутатором сети: устройство считывает DLCI, проверяет управляющие биты и передаёт кадр на следующий сегмент виртуального канала. Пользовательское оборудование не участвует в этом процессе, поэтому корректная интерпретация заголовка полностью зависит от согласованности конфигураций между клиентом и оператором связи.

Механизм управления перегрузкой: FECN, BECN, DE

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

Бит FECN (Forward Explicit Congestion Notification) устанавливается коммутаторами при обнаружении затора на пути следования кадра. Получатель, увидев установленный флаг, фиксирует факт перегрузки и может передать эту информацию прикладным системам или использовать её для статистического анализа качества канала.

Бит BECN (Backward Explicit Congestion Notification) служит для уведомления отправителя. Он помечает кадры, идущие в обратном направлении, сигнализируя о необходимости снизить интенсивность передачи. На маршрутизаторах корпоративных сетей рекомендуется настраивать реакции на BECN, например ограничение скорости или перераспределение трафика между виртуальными каналами.

Флаг DE (Discard Eligibility) используется для обозначения кадров с пониженным приоритетом. При превышении согласованной скорости CIR оборудование оператора может помечать или сразу отбрасывать такие кадры в условиях перегрузки. Для критичных приложений следует исключать попадание их трафика под действие DE, выделяя отдельные виртуальные каналы или применяя политику приоритизации.

При эксплуатации Frame Relay важно не игнорировать сигналы перегрузки. Регулярное появление FECN и BECN указывает на несоответствие профиля трафика согласованным параметрам канала. В таких случаях рекомендуется пересматривать значения CIR, ограничивать burst-нагрузку и анализировать распределение трафика между PVC.

Как работает передача данных без подтверждений

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

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

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

При проектировании сети без подтверждений рекомендуется:

ограничивать burst-трафик для предотвращения переполнения буферов коммутаторов;

согласовывать CIR с реальным профилем нагрузки, а не с пиковыми значениями;

использовать приоритизацию на маршрутизаторах для защиты критичных потоков.

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

Требования к оборудованию и настройка интерфейсов

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

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

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

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

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

Причины вытеснения Frame Relay современными технологиями

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

Ключевые технические ограничения, повлиявшие на отказ от Frame Relay:

• отсутствие встроенных механизмов гарантии доставки и управления качеством обслуживания;
• жёсткая привязка к инфраструктуре операторов связи и их схемам коммутации;
• сложность масштабирования при росте числа филиалов и виртуальных каналов;
• ограниченные возможности мониторинга и диагностики на уровне канала.

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

Дополнительным фактором стало распространение Ethernet-технологий в WAN-сегменте. Провайдеры начали предлагать услуги на базе Metro Ethernet, которые обеспечивают прозрачную передачу кадров, высокие скорости и простую интеграцию с локальными сетями без необходимости настройки виртуальных каналов на уровне провайдера.

При эксплуатации унаследованных сетей с Frame Relay рекомендуется планировать поэтапную миграцию:

1. аудит текущих PVC и профилей трафика;
2. сопоставление сервисов с требованиями новых транспортных технологий;
3. перенос критичных приложений на MPLS или IP VPN;

Такой подход снижает риски потери данных и позволяет адаптировать корпоративную WAN-сеть к современным требованиям без резких изменений архитектуры.

Вопрос-ответ:

Почему Frame Relay не использует подтверждение доставки кадров?

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

Чем DLCI отличается от MAC- или IP-адреса?

DLCI — это локальный идентификатор виртуального канала, который имеет значение только между клиентским оборудованием и ближайшим коммутатором провайдера. Он не используется для глобальной адресации узлов и не передаётся сквозь всю сеть. В отличие от IP-адреса, DLCI не отражает расположение устройства и не участвует в маршрутизации на сетевом уровне.

Можно ли было передавать голос и видео по Frame Relay?

Технически передача голосового и видеотрафика была возможна, но на практике возникали сложности. Протокол не обеспечивал контроль задержек и потерь, а при перегрузке кадры с флагом DE отбрасывались первыми. Для таких типов трафика требовались жёсткие ограничения нагрузки и отдельные виртуальные каналы, что увеличивало сложность эксплуатации.

Какую роль играл LMI в работе Frame Relay?

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

Почему Frame Relay чаще применялся в топологии hub-and-spoke?

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

Почему при превышении CIR трафик Frame Relay начинает теряться, хотя канал физически не перегружен?

Скорость физического доступа не определяет правила обработки кадров внутри сети оператора. При превышении согласованного CIR кадры помечаются флагом DE и попадают в очередь с пониженным приоритетом. При появлении перегрузки на любом участке сети такие кадры отбрасываются первыми, даже если локальный интерфейс маршрутизатора продолжает передавать данные без ошибок.

Есть ли практический смысл сохранять Frame Relay в работающей корпоративной сети?

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