Обычно мосты ЛВС определяют достижимость интерфейса конкретной конечной станции, связывая MAC-адрес с портом моста. В сети Frame Relay, настроенной на работу с одним bridge-портом типа моста ЛВС (или любым набором VC, объединенных для формирования одного bridge-порта), мост должен ассоциироваться не только с MAC-адресом bridge-порта, но и с идентификатором соединения. Для сетей Frame Relay в качестве идентификаторов соединений используются значения DLCI. Неразумно, а возможно и нереально, требовать статической настройки мостов для создания ассоциаций между всеми возможными MAC-адресами получателей и DLC. Следовательно, мосты в сетях Frame Relay, действующие по типу мостов ЛВС, должны обеспечивать механизм, позволяющий bridge-портам Frame Relay динамически создавать такие ассоциации. Для реализации автоматического обучения передаваемый с использованием мостов пакет должен соответствовать требованиям к инкапсуляции, описанным в разделе 4.2. В этом случае приемный интерфейс Frame Relay будет знать, как работать с пакетом, полученным через мост, для сбора требуемой информации.
Другое приближение для мостов Frame Relay (point-to-point view) трактует каждое виртуальное соединение Frame Relay VC как отдельный порт моста. В этом варианте лавинная маршрутизация и пересылка пакетов существенно упрощаются, поскольку каждый порт моста связан с единственным адресатом (destination). Нет необходимости организовывать искусственную лавинную маршрутизацию (flooding) или связывать DLCI с MAC-адресами получателей. В зависимости от топологии соединений (VC) может потребоваться использование расширенного алгоритма Spanning Tree для того, чтобы сохранялась активность всех портов, пока не возникает петель во внешней по отношению к группе удаленного моста.
Возможно также использовать комбинированную (LAN и point-to-point) модель для одного интерфейса Frame Relay. Для реализации такого подхода некоторые VC объединяются для формирования одного виртуального bridge-порта, а остальные VC образуют независимые порты мостов.
На рисунке показаны различные варианты конфигурации мостов (пунктирные линии задают виртуальные соединения).
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+
Поскольку в приведенном примере отсутствует полная связность (VC между каждой парой мостов), сеть должна быть разделена на несколько групп remote bridge. Разумно объединить мосты A, B и C в одну группу, а мосты A и D — в другую.
Конфигурация первой группы объединяет VC, соединяющие три моста (A, B, C) в один виртуальный порт. Это является примером LAN-конфигурации. Вторая группа также содержит один виртуальный порт, который просто соединяет мосты A и D. В этой конфигурации стандартного алгоритма Spanning Tree достаточно для обнаружения петель.
Альтернативный вариант конфигурации будет иметь 3 отдельных виртуальных порта, соответствующих VC, которые связывают мосты A, B и C. Поскольку применение стандартного алгоритма Spanning Tree в этой конфигурации будет приводить к обнаружению петли, для сохранения активности всех виртуальных портов требуется использовать расширенный алгоритм Spanning Tree. Отметим, что вторая группа по-прежнему содержит один виртуальный порт и может использовать стандартный алгоритм Spanning Tree.
Используя тот же пример (см. рисунок), мы можем создать конфигурацию удаленных мостов с тремя группами. Это будет примером конфигурации point-to-point. В этом случае виртуальные соединения VC, связывающие A и B, VC между A и C, а также VC между A и D являются bridge-группами с одним виртуальным портом.