Bridging Model for Frame Relay

Remote bridges with LAN ports receive and transmit MAC frames to and from the LANs to which they are attached. They may also receive and  transmit MAC frames through virtual ports to and from other remote   bridges.  A virtual port may represent an abstraction of a remote bridge's point of access to one, two or more other remote bridges.

The frame relay VCs that interconnect the bridges of a remote bridge group may be combined or used individually to form one or more virtual bridge ports.  This gives flexibility to treat the Frame Relay interface either as a single virtual bridge port, with all VCs in a group, or as a collection of bridge ports (individual or grouped VCs).
 

LAN View

The simplest bridge configuration for a Frame Relay network is the LAN view where all VCs are combined into a single virtual port. Frames, such as BPDUs,  which would be broadcast on a LAN, must be flooded to each VC (or multicast if the service is developed for Frame Relay services).

Flooding is performed by sending the packet to each relevant DLC associated with the Frame Relay interface. The VCs in this environment are generally invisible to the bridge.  That is, the bridge sends a flooded frame to the frame relay interface and does not "see" that the frame is being forwarded to each VC individually.  If all participating bridges are fully connected (full mesh) the standard Spanning Tree Algorithm will suffice in this configuration.

Typically LAN bridges learn which interface a particular end station may be reached on by associating a MAC address with a bridge port. In a Frame Relay network configured for the LAN-like single bridge port (or any set of VCs grouped together to form a single bridge port), however, the bridge must not only associated a MAC address with a bridge port, but it must also associate it with a connection identifier.

For Frame Relay networks, this connection identifier is a DLCI.  It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a DLC.  Therefore, Frame Relay LAN-modeled bridges must provide a mechanism to allow the Frame Relay bridge port to dynamically learn the associations.  To accomplish this dynamic learning, the receiving Frame Relay interface will know to look into the bridged packet to gather the appropriate information.

Point-to-Point View

A second Frame Relay bridging approach, the point-to-point view, treats each Frame Relay VC as a separate bridge port.  Flooding and forwarding packets are significantly less complicated using the point-to-point approach because each bridge port has only one destination.  There is no need to perform artificial flooding or to associate DLCIs with destination MAC addresses.  Depending upon the interconnection of the VCs, an extended Spanning Tree algorithm may be required to permit all virtual ports to remain active as long as there are no true loops in the topology external to the remote bridge group.

It is also possible to combine the LAN view and the point-to-point view on a single Frame Relay interface.  To do this, certain VCs are combined to form a single virtual bridge port while other VCs are independent bridge ports.

The following drawing illustrates the different possible bridging configurations:
The purple arrows between bridges represent virtual circuits.

Since there is less than a full mesh of VCs between the bridges in this example, the network must be divided into more than one remote bridge group.  A reasonable configuration is to have bridges A, B, and C in one group, and have bridges A and D in a second.

Configuration of the first bridge group combines the VCs interconnection the three bridges (A, B, and C) into a single virtual port.  This is an example of the LAN view configuration.  The second group would also be a single virtual port which simply connects bridges A and D.  In this configuration the standard Spanning Tree Algorithm is sufficient to detect loops.

An alternative configuration has three individual virtual ports in the first group corresponding to the VCs interconnecting bridges A, B and C.  Since the application of the standard Spanning Tree Algorithm to this configuration would detect a loop in the topology, an extended Spanning Tree Algorithm would have to be used in order for all virtual ports to be kept active.  Note that the second group would still consist of a single virtual port and the standard Spanning Tree Algorithm could be used in this group.

Using the same drawing, one could construct a remote bridge scenario with three bridge groups.  This would be an example of the point-to-point case.  Here, the VC connecting A and B, the VC connecting A and C, and the VC connecting A and D are all bridge groups with a single virtual port.