Технология frame relay кратко

Обновлено: 02.07.2024

Технологии Frame Relay — это технологии ретрансляции кадров.

Сущность и предназначение технологии Frame Relay

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

Как раз такой методикой и явился Frame Relay, то есть метод ретрансляции кадров, который определялся набором стандартов ITU-T, ANSI и FR. Эта методика и стала основой сетевых технологий и сетей типа Frame Relay. Технология Frame Relay первоначально проектировалась для применения в сетях ISDN ещё в восьмидесятых годах двадцатого века. Использование этой технологии обладало рядом несомненных достоинств. Чтобы осуществить трансляцию полезных данных Frame Relay способна использовать примерно девяносто процентов полосы пропускания, в то время как X.25 был способен задействовать только около сорока, а иногда и даже меньше. Для каналов связи, имеющих низкую скорость передачи данных, это достоинство оказалось определяющим.

Особенности технологии Frame Relay

Технология Frame Relay осуществляет на уровне канала мультиплексирование информационного потока в кадровый набор. Причём выполняется операция мультиплексирования по одному каналу связи сразу несколько информационных потоков. При трансляции кадров посредством коммутатора, кадры не преобразуются и по этой причине сеть именуется ретранслятором кадров. То есть, сеть выполняет коммутацию не пакетов, а уже кадров. Кадры несут в себе минимум данных по управлению, и это ведёт к повышению эффективности трансляции данных. Предполагается, также, что каналы связи обладают достаточным уровнем надёжности, а процедуры потокового управления осуществляются согласно протоколам верхнего уровня. Это объясняется тем обстоятельством, что технология Frame Relay не имеет встроенных функций по контролю получения и управлению кадровым потоком. Базовым основанием сети Frame Relay являются специализированные коммутаторы FRAD (Frame Relay Access Device, оборудование доступа к сети с ретрансляцией кадров). Устройства коммутации Frame Relay используют технологию сквозной коммутации, при которой все кадры отправляются на очередной узел транзита непосредственно после чтения информации адреса.

Готовые работы на аналогичную тему

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

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

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

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

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

Канал постоянного типа (PVC - Permanent Virtual Circuit).
Канал коммутируемого типа (SVC - Switched Virtual Circuit).

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

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

Frame Relay первоначально замышлялся как протокол для использования в интерфейсах ISDN, и исходные предложения, представленные в CCITT в 1984 г., преследовали эту цель. Была также предпринята работа над Frame Relay в аккредитованном ANSI комитете по стандартам T1S1 в США.

Крупное событие в истории Frame Relay произошло в 1990 г., когда Cisco Systems, StrataCom, Northern Telecom и Digital Equipment Corporation образовали консорциум, чтобы сосредоточить усилия на разработке технологии Frame Relay и ускорить появление изделий Frame Relay, обеспечивающих взаимодействие сетей. Консорциум разработал спецификацию, отвечающую требованиям базового протокола Frame Relay, рассмотренного в T1S1 и CCITT; однако он расширил ее, включив характеристики, обеспечивающие дополнительные возможности для комплексных окружений межсетевого об'единения. Эти дополнения к Frame Relay называют обобщенно local management interface (LMI) (интерфейс управления локальной сетью).

Основы технологии

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

В роли сетевого интерфейса, Frame Relay является таким же типом протокола, что и Х.25 (смотри Главу 13 "Х.25"). Однако Frame Relay значительно отличается от Х.25 по своим функциональным возможностям и по формату. В частности, Frame Relay является протоколом для линии с большим потоком информации, обеспечивая более высокую производительность и эффективность.

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

Другой важной характеристикой Frame Relay является то, что она использует новейшие достижения технологии передачи глобальных сетей. Более ранние протоколы WAN, такие как Х.25, были разработаны в то время, когда преобладали аналоговые системы передачи данных и медные носители. Эти каналы передачи данных значительно менее надежны, чем доступные сегодня каналы с волоконно-оптическим носителем и цифровой передачей данных. В таких каналах передачи данных протоколы канального уровня могут предшествовать требующим значительных временных затрат алгоритмам исправления ошибок, оставляя это для выполнения на более высоких уровнях протокола. Следовательно, возможны большие производительность и эффективность без ущерба для целостности информации. Именно эта цель преследовалась при разработке Frame Relay. Он включает в себя алгоритм проверки при помощи циклического избыточного кода (CRC) для обнаружения испорченных битов (из-за чего данные могут быть отвергнуты), но в нем отсутствуют какие-либо механизмы для корректирования испорченных данных средствами протокола (например, путем повторной их передачи на данном уровне протокола).

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

Дополнения LMI

Форматы блока данных

Формат блока данных изображен на Рис. 14-1. Флаги ( flags ) ограничивают начало и конец блока данных. За открывающими флагами следуют два байта адресной ( address ) информации. 10 битов из этих двух байтов составляют идентификацию (ID) фактической цепи (называемую сокращенно DLCI от "data link connection identifier" ).

Центром заголовка Frame Relay является 10-битовое значение DLCI. Оно идентифицирует ту логическую связь, которая мультиплексируется в физический канал. В базовом режиме адресации (т.е. не расширенном дополнениями LMI), DLCI имеет логическое значение; это означает, что конечные усторойства на двух противоположных концах связи могут использовать различные DLCI для обращения к одной и той же связи. На рис. 14-2 представлен пример использования DLCI при адресации в соответствии с нерасширенным Frame Relay.

Рис. 14-2 предполагает наличие двух цепей PVC: одна между Aтлантой и Лос-Анджелесом, и вторая между Сан Хосе и Питтсбургом. Лос Анджелес может обращаться к своей PVC с Атлантой, используя DLCI=12, в то время как Атланта обращается к этой же самой PVC, используя DLCI=82. Аналогично, Сан Хосе может обращаться к своей PVC с Питтсбургом, используя DLCI=62. Сеть использует внутренние патентованные механизмы поддержания двух логически значимых идентификаторов PVC различными.

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

Бит C/R, следующий за самым значащим байтом DLCI, в настоящее время не используется.

И наконец, три бита в двубайтовом DLCI являются полями, связанными с управлением перегрузкой. Бит "Уведомления о явно выраженной перегрузке в прямом направлении" (FECN) устанавливается сетью Frame Relay в блоке данных для того, чтобы сообщить DTE, принимающему этот блок данных, что на тракте от источника до места назначения имела место перегрузка. Бит "Уведомления о явно выраженной прегрузке в обратном направлении" (BECN) устанавливается сетью Frame Relay в блоках данных, перемещающихся в направлении, противоположном тому, в котором перемещаются блоки данных, встретившие перегруженный тракт. Суть этих битов заключается в том, что показания FECN или BECN могут быть продвинуты в какой-нибудь протокол высшего уровня, который может предпринять соответствующие действия по управлению потоком. (Биты FECN полезны для протоколов высших уровней, которые используют управление потоком, контролируемым пользователем, в то время как биты BECN являются значащими для тех протоколов, которые зависят от управления потоком, контролируемым источником ("emitter-controlled").

Бит "приемлемости отбрасывания" (DE) устанавливается DTE, чтобы сообщить сети Frame Relay о том, что какой-нибудь блок данных имеет более низшее значение, чем другие блоки данных и должен быть отвергнут раньше других блоков данных в том случае, если сеть начинает испытывать недостаток в ресурсах. Т.е. он представляет собой очень простой механизм приоритетов. Этот бит обычно устанавливается только в том случае, когда сеть перегружена.

Первый из мандатных байтов ( unnumbered information indicator -индикатор непронумерованной информации) имеет тот же самый формат, что и индикатор блока непронумерованной информации LAPB (UI) с битом P/F, установленным на нуль. Подробная информация о LAPB дается в разделе "Уровень 2" Главы 13 "Х.25". Следующий байт называют "дискриминатор протокола" ( protocol discriminator ); он установлен на величину, которая указывает на "LMI". Третий мандатный байт ( call reference -ссылка на обращение) всегда заполнен нулями.

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

Дополнение в виде глобальной адресации позволяет использовать идентификаторы узлов. При использовании этого дополнения значения, вставленные в поле DLCI блока данных, являются глобально значимыми адресами индивидуальных устройств конечного пользователя (например, маршрутизаторов). Реализация данного принципа представлена на Рис.14-4.

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

Групповая адресация (multicusting)

Реализация сети

Frame Relay может быть использована в качестве интерфейса к услугам либо общедоступной сети со своей несущей, либо сети с оборудованием, находящимся в частном владении. Обычным способом реализации частной сети является дополнение традиционных мультиплексоров Т1 интерфейсами Frame Relay для информационных устройств, а также интерфейсами (не являющимися специализированными интерфейсами Frame Relay) для других прикладных задач, таких как передача голоса и проведение видео-телеконференций. На Рис. 14-5 "Гибридная сеть Frame Relay" представлена такая конфигурация сети.

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

Для любого типа сети линии, подключающие устройства пользователя к оборудованию сети, могут работать на скорости, выбранной из широкого диапазона скоростей передачи информации. Типичными являются скорости в диапазоне от 56 Kb/сек до 2 Mb/сек, хотя технология Frame Relay может обеспечивать также и более низкие и более высокие скорости. Ожидается, что в скором времени будут доступны реализации, способные оперировать каналами связи с пропускной способностью свыше 45 Mb/сек (DS3).

Технология, которая в последствии получила название Frame Relay (Коммутация кадров), первоначально была разработана в начале 1980-х для использования в сетях ISDN. Технология Frame Relay обеспечивает информационное взаимодействие на физическом и канальном уровне OSI и была предназначена динамического разделения ресурсов физического канала между пользовательскими процессами передачи данных. Использование технологии FR обеспечивало ряд преимуществ по сравнению с технологиями X.25 и ISDN, которые использовались для обеспечения доступа к распределенным вычислительным ресурсам.В таблице приведены результаты сравнения вышеописанных технологий по некоторым параметрам с технологией FR.

Параметр	ISDN	X.25	FR
Выделение фиксированной полосы под вызов	+	−	−
Виртуальные каналы	−	+	+
Высокая степень готовности	+	−	+
Малая величина задержки	+	−	+
Высокая эффективность использования канала	−	−	+
Возможность масштабирования	−	+	+
Низкая стоимость использования канала	−	−	+

Принципы построения и компоненты сетей Frame Relay

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

Компоненты Frame Relay

Устройства DTE (Data Terminal Equipment)
Устройства DCE (Data Circuit-Terminating Equipment)
Устройства FRAD (Frame Relay Access Device)

Также как и в сети X.25, основу Frame Relay составляют виртуальные каналы (virtual circuits). Виртуальный канал в сети Frame Relay представляет собой логическое соединение которое создается между двумя устройствами DTE в сети Frame Relay и используется для передачи данных. В сети Frame Relay используется два типа виртуальных каналов коммутируемые (SVC) и постоянные (PVC).

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

Установление вызова (Call Setup)
На этом этапе создается виртуальное соединение между двумя DTE
Передача данных(Data Transfer)
Фаза непосредственной передачи данных
Ожидание(Idle)
Виртуальное соединение ещё существует, однако передача данных через него уже не производится. В том случае, если период ожидания превысит установленное значение тайм-аута, соединение может быть завершено автоматически.
Завершение вызова(Call Termination)
На этом этапе выполняются операции, которые необходимы для завершения соединения

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

Постоянные каналы

Передача данных
Фаза непосредственной передачи данных
Ожидание
Виртуальное соединение существует, однако передача данных через него не производится. В отличие от SVC, постоянный канал PVC не может быть автоматически разорван в том случае, если он не используется для передачи данных.

Идентификаторы виртуальных каналов

Для обозначения виртуальных каналов в сети Frame Relay используется аппарат DLCI (Data-Link Connection Identifier) . По своему назначению в сетях Frame Relay идентификатор DLCI совпадает со назначением номера логического канала в сетях X.25. DLCI определяет номер виртуального порта для процесса пользователя. Устройство FRAD LAN1 использует виртуальный канал DLCI 101 для организации обмена данными с сетью LAN 2 и виртуальный канал DLCI 102 для организации обмена данными с сетью LAN 3. Для организации обмена данными с сетью LAN 1 устройство FRAD LAN 2 использует виртуальный канал DLCI 200. Обычно идентификатор DLCI имеет только локальное значение и не является уникальным в пределах сети. Конкретные значения DLCI для каждого пользователя определяются провайдером сервиса Frame Relay.

Структура кадра Frame Relay

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

Флаг	Заголовок Кадра	Полезная нагрузка	FCS	Флаг
1 байт	2 байта	2 байта	1 байт

Поле FLAG

Данное поле выполняет функцию обрамления кадра. Принцип формирования поля FLAG в кадре Frame Relay соответствует принципам формирования поля FLAG в кадре LAPB.

Поле HEADER

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

Структура первого байта поля заголовка:

Структура второго байта поля заголовка:

поле DLCI	FECN	BECN	DE	EA
4 бит	1 бит	1 бит	1 бит	1 бит

Поле DLCI

Поле DLCI занимает 10 бит в заголовке кадра. В это поле коммутатор FR помещает идентификатор, используя который получатель кадра может правильно интерпретировать содержимое поля полезной нагрузки.

Биты FECN и BECN

Бит DE

Бит DE (Discard Eligibility) используется для обеспечения функционирования второго механизма управления потоком данных в сетях Frame Relay. Описание этого механизма будет приведено ниже. Битом DE помечаются кадры, которые при возникновении ситуации перегрузки на коммутаторе FR должны быть уничтожены в первую очередь.

Поле полезной нагрузки

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

Поле FCS

Содержит 16-ти разрядную контрольную сумму всех полей кадра Frame Relay за исключением поля "флаг".

Параметры качества обслуживания Frame Relay

согласованное значение информационной скорости (Committed Information Rate - CIR)
гарантируемый объем передаваемых данных (committed burst size Bc)
не гарантируемый объем передаваемых данных (excess burst size Be)

Согласованная информационная скорость

Значение CIR определяется для каждого PVC пользователя. Согласованная информационная скорость это максимальная скорость, с которой пользователь может обеспечивать информационный обмен по отдельному каналу PVC. Сумма значений CIR всех PVC пользователя не должна превышать 75-80 процентов пропускной способности физического канала провайдера.

Гарантированный объем и интервал неравномерности трафика

Данный параметр услуги предназначен для определения временного интервала допустимой неравномерности трафика пользователя Tc в соответствии с формулой:

Таким образом, значение Bc определяет максимальный объем данных пользователя, который может быть передан без потерь за период Тс.

Не гарантированный объем передаваемых данных

Значение Be определяет величину предельного увеличения трафика пользователя для конкретного виртуального канала PVC. Кадрам пользователя, которые образовали добавку Be к согласованному значению Bc, присваивается признак DE, что означает их удаление при возникновении перегрузок в сети.

Сигнализация и управление вызовами в сетях Frame Relay

Использование технологии Frame Relay в качестве универсальной транспортной среды вызвало необходимость разработки дополнительных спецификаций, которые обеспечивали более гибкое управление ресурсами PVC и SVC в сети Frame Relay. Одной из первых таких спецификаций была спецификация LMI.

Cпецификация LMI

Итак, я уже затрагивал тему xDSL и PDH/SDH. Но все никак не успокоится моя душа, пока я не напишу про Frame Relay. В этом посте попробую устранить это моё душевное неспокойствие.

Как обычно, посмотрим, что такое Frame Relay как технология, как работает и какие интересные особенности в себе имеет. Погнали.

Для начала немного лирики. Уж не знаю почему, но к Frame Relay я всегда имел какие-то теплые чувства (если их вообще можно иметь к протоколу передачи данных. коллеги меня поймут, надеюсь). Впервые я узнал о нем давным давно, когда ещё готовился к CCNA. Тогда Frame Relay произвел на меня достаточно большое впечатление, хотя бы потому что это был не Ethernet. Это было что-то новое, что я не знал тогда. С тех пор, я почти не видел его имплементаций в жизни. Зато в цисковских экзаменах его до недавнего времени было просто завались. Давайте попробуем разобраться, что же в нем такого.

Причины возникновения

После лирики самое время перейти к истории. Frame Relay появился в эру ISDN. Возникла надобность как-то организовать передачу данных по сети, для этого изначально была и разработана технология Frame Relay. Довольно редко встречающаяся в наши дни технология, однако не так уж редкая, как многие думают. Основным применением технологии был, так называемый, корпоративный сектор. В то время, для обеспечения канала связи между двумя офисами, применялись point-to-point serial линки. Штука простая и удобная, но не масштабируемая. Если нам нужно соединить 3 устройства через ISDN сеть, от каждого устройства понадобится прокладывать два serial линка. А если устройств 100. Эту проблему был призван решить Frame Relay. Он способен объединить все эти офисы чуть более эффективным методом. Понадобится всего один линк для соединения каждого устройства с Frame Relay облаком. Картина ниже иллюстрирует подход.

Frame Relay - работает на втором уровне OSI, поверх которого можно передавать множество L3 технологий. Конечно же, основная из них - IP. Именно про IP over Frame Relay и пойдет речь дальше.

Frame Relay вводит пару терминов, которые особой сложности не несут, но иногда могут завести в заблуждение.

DTE (data terminal equipment) - оборудование, которое использует сервис Frame Relay. По сути это CPE.

DCE ( data circuit-terminating equipment ) - оборудование, которое предоставляет сервис Frame Relay. Это Frame Relay Switch, который стоит на стороне провайдера.

Базовый принцип

Итак, теперь когда мы более или менее определились что такое Frame Relay, пора глянуть на то как он работает. Если говорить в терминах Frame Relay, то на схеме ниже у нас три устройства, которые подключены к Frame Relay облаку. Это DTE1, DTE2 и DTE3. Каждое их этих устройств подключено к провайдерскому устройству (DCE), которых на схеме тоже три.

SVC (Switched Virtual Circuit) - такой канал сигнализируется DTE каждый раз, когда нужно передать данные.

PVC (Permanent Virtual Circuit) - этот тип секита всегда присутствует в сети и настроен на узлах. DTE к нему всего лишь подключаются, но не сигнализируют.

Роутер DTE1 инкапсулирует IP пакет в Frame Relay кадр, вставляет DLCI=102 в заголовок и отправляет получившийся сверток в сторону DTE2.
В нашем случае, кадр попадает на DCE1. Внутри Frame Relay облака, перво наперво, проверяется заголовок Frame Relay, там находится идентификатор DLCI=102, это это часть секита VC12, DLCI в кадре меняется на 101 и отправляется в сторону DTE2.
DTE2 так же смотрит заголовок Frame Relay, находит там DLCI 101 по которому он понимает, что данные пришли от DTE1. Далее заголовок отбрасывается и начинается работа с IP пакетом.

LMI (Local Management Interface)

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

Таким образом, после настройки линка наш DTE автоматически узнает о том, какие DLCI используются. Проблема только в том, что мы не знаем какой IP какому DLCI соответсвует. "ARP" - воскликнет читатель. "Почти" - отвечу я.

Inverse ARP

После того, как мы подключили устройство к сети Frame Relay, ближайший свитч расскажет нам какие DLCI настроены в канале. Для того, чтобы узнать какие L3 адреса (IP, короче говоря) за ними сидят нам нужно что-то вроде ARP в Ethernet, но наоборот. В Ethernet мы знаем L3, но не знаем какой MAC, т.е. L2 адрес, ему соответствует. Тут же мы знаем L2 адрес (DLCI), а вот IP нет.

Конечно, Inverse ARP можно отключить, отключив LMI, кстати говоря. В таком случае, всю настройку вы берете на себя. Нужно статически настроить DLCI на интерфейсах и записать каким DLCI на удаленных сторонах сети какие адреса соответсвуют.

Топологии

Стоит пару слов сказать про L3. Вы вольны как угодно строить дизайн L3 поверх Frame Relay облака. Можно одну подсеть "размазать" по всей сети, что я и сделал в своем примере (картинка ниже слева). Можно использовать логику точка-точка и на каждый VC выделить свою подсеть (справа).

Тип интерфейса

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

Физическом интерфейсе. Хороший вариант, но не очень масштабируемый. В нашем примере выше, всю топологию можно настроить на физических интерфейсах. Прописываем инкапсуляцию frame-relay и IP адрес, всю остальную работу за нас сделают LMI и InARP. А вот если бы мы выбрали для реализации подход с предыдущего рисунка, когда для каждого VC нам понадобилась бы своя подсеть, настроить Frame Relay на физическом уровне уже не получится. Нужно было бы прописать две подсети на один физический интерфейс.
Сабинтерфейсе. Можно сказать, что это Best Practises. Но в таком случае, нам нужно выбрать тип интерфейса, коих у нас два:
- Point-to-Point. В таком случае, InverseARP нам не нужен, потому как сама логика PtP предполагает, что на другом конце только одно устройство. Роутер просто считает, что вся подсеть, которая прописана на локалном интерфейсе доступна через DLCI соседа. Например, если настроить VC12 как PtP сабинтерфейс на DTE1, то роутер просто решит, что вся подсеть 192.168.0.0/24 доступна через VC12 и слать трафик в неё нужно с DLCI 102. Такой DLCI рассказал нам DTE2 на другом конце средствами LMI. Напомню, InverseARP для маппинга L2 в L3 не используется в таком случае. Для нашего примера, линк на DTE3 тоже можно настроить как PtP.
- Multipoint. А вот на DTE2 такая логика неприменима, ведь через один линк должно ходить несколько VC. В нашем случае, здесь потребуется настроить multipoint сабинтерфейс.
Если прикинуть, как будет ходить трафик в такой топологии, то получится примерно следующее. Допустим, в облаке уже все настроено и вы включили свои настроенные устройства.

FECN, BECN, DE

Следующее о чем стоит поговорить, это то, как Frame Relay сеть реагирует на перегрузку канала (congestion). А реагирует она, стоит сказать, довольно изящно. В заголовке Frame Relay кадра есть следующие интересущие нас биты:
- FECN (Forward Explicit Congestion Notification) - служит для нотификации перегрузки канала в сторону назначения
- BECN (Backward Explicit Congestion Notification) - служит для обратной нотификации о перегрузке канала
- DE (Discard Eligibility) - маркер трафика, который должен быть отброшен в первую очередь при возникновении переполнения на канале
- DTE1 отправляет некий трафик обернутый заголовком Frame Relay, в котором помимо DLCI находятся два бита - FECN и BECN. Роутер DTE1 отправляет их равными нулю, потому что он ни про какие перегрузки в канале не знает (ещё пока).
- DCE1 получает трафик и обрабатывает его, все как обычно. Однако он замечает, что в линке до DCE2 есть заторчик. Он запоминает VC, в котором к нему пришли данные и ставит бит FECN равным 1 в заголовке кадра в сторону соседа DCE2. Что означает, что в канале произошла перегрузка. Делает он это, по сути, в надежде, что кто-то на него-таки взглянет. Спойлер - не в этот раз.
- Кадр приходит на DCE2. Для него это самый обычный трафик, который он отправляет на DTE2.
- DTE2, получив трафик, начинает его как-то обрабатывать и, скорее всего, шлет некий обратный трафик. Он в этом примере про перегрузку канала ничего не знает, поэтому в его обратном кадре FECN и BECN тоже нулевые.
- Когда DCE1 получит такой трафик, он узнает VC и поставит бит BECN равный 1, для того, чтобы сказать источнику трафика (DTE1), что на канале есть проблемы и ему надо немного охладить свой пыл.
В этом случае, DTE2 настроен на реакцию на бит FECN и сам проставит BECN = 1, для того чтобы уведомить DTE1 о перегрузке. DCE1 в этом случае ничего менять не будет. В этот раз, DCE1 не зря ставил FECN = 1, все таки хоть кому-то он пригодился и DTE2 взглянул на него.

FECN бит в нормальном сети меняют только DCE, а вот BECN могут менять как DCE, так и DTE.

Зачем же нужен бит DE? Когда обнаружиться перегрузка, на DCE, рано или поздно, переполнится очередь на отправку и он будет вынужден начать процесс сбрасывания кадров с её конца. Он понятия не имеет какой трафик важный, а какой нет. Но ему можно попытаться рассказать об этом. Есть возможность помечать некий "неважный" трафик при отправке с DTE битом DE. В этом случае, наши свитчи в ядре (DCE) смогут понять какой трафик стоит отбрасывать в первую очередь, инспектируя значение этого бита в заголовке Frame Relay.

Наверное, пока хватит. Наконец-то я описал Frame Relay в своем блоге. Теперь я буду спать спокойно.

Читайте также: