Recall last Wednesday, we began looking at the class of switches used to forwards packets between shared media LANs such as Ethernets.
Our starting example was a pair of Ethernets that we wanted to connect.
If we used a repeater, we might exceed the physical limitations of the Ethernet.
So the approach we took is to put a node between the two Ethernets and have the node forward frames transmitted on either side of the Ethernet.
This node operates in promiscuous mode, accepting all frames transmitted on either side.
This kind of node is called a bridge.
The LANs connected by one or more bridges are together called an extended LAN.
We now look at how to build networks out of bridges.
Learning Bridges
If A wants to send to B, there is no point for the bridge to forward the message it sees on port 1 to port 2. How does the
bridge know when to forward and when not to?
A human could create a bridge table with two columns, one for host, one for which port to use. If the frame comes in on the same port
that it should also go out on, then the bridge wouldn't need to forward it.
This would be using the datagram model of forwarding we talked about last day.
One way to automate the process of building the bridge table is the following:
When a bridge first turns on, it starts with an empty table.
When the bridge gets a frame on a given interface, it checks its table to see if there is an entry which has the same source address. If not, it adds the entry (source address, interface) to its table and sets a timer. If yes, and the entry would be the same, the timer is reset.
The bridge then checks: Does the destination MAC address have an entry in the table? If yes, and it is different from the incoming interface, forward the frame according to the entry. If there is no entry, then forward on all outgoing lines other than the one the frame came in on.
If a timer goes to 0, then delete that entry. This guards against machines going down or changing the topology.
Quiz
In MACA how long should a third party not transmit? Assume the first two parties are a
sender and a receiver.
For x seconds, if it hears an RTS with length field x seconds.
Not until it hears an ACK from the receiver.
For x seconds, if it hears an CTS with length field x seconds.
Spanning Tree Algorithm
The algorithm two slides back works provided there are no loops in the network graph. If there is a loop, and no one has an entry
for a given frame destination, then a frame might cycle indefinitely.
This is a problem because, loops occur reasonably naturally in bridged networks: They might arise because no one person building the network controls all the bridges; they also might arise because the builder wanted to ensure the reliability of the network against failures.
In order to solve this problem, the bridges might run a distributed spanning tree algorithm. This algorithm was developed at DEC by Radia Perlman and is part of the 802.1. spec.
Once a spanning tree is computed, a bridge can use the algorithm of two slides back with the change that it only forwards on ports which are part of the spanning tree.
The spanning tree algorithm works as follows:
Each bridge has its own unique ID (MAC address of lowest port + bridge priority, 8 bytes) which we denote B1, B2, B3 ...
The bridges first elect a root bridge. This will be the bridge with the least ID.
Each bridge then computes the shortest path to the root, and determines which of its ports is on this route. It also determines a designated forwarding bridge which will be responsible for forwarding messages to the route.
More on the Spanning Tree Algorithm
In order to do each of these steps, bridges exchange configuration messages containing: (1) the ID of the bridge sending the message, (2) the ID for what the sending bridge thinks is the root bridge, (3) the distance in hops of the sending bridge from the root.
If a bridge receives a configuration message, it checks if its own configuration message is better or worse than the one received.
The new message is better if:
It identifies a root with a smaller ID.
It identifies a root with an equal ID, but shorter distance.
The root ID and distance are equal but the sending bridge has a smaller ID.
If the new message is better than the currently recorded information, a bridge discards the old information and saves the new information. However, it adds 1 to the distance from the root to the bridge.
When a bridge receives a message which tells it that it is not the root, it stops generating its own configuration messages, and instead only forwards messages from other bridges, adding 1 to the hop distance.
When a bridge receives a message which tells it that it is not the designated bridge for the port of its neighbor, the bridge stops sending configuration messages over that port.
The system stabilizes when only the root bridge is still generating messages. The root continues to do this periodically.
If any node including the root goes down, downstream nodes will stop receiving configuration messages and then after a timeout period will once again claim to be root and run the above algorithm. This also happens if new nodes are added to the system.
Broadcast and Multicast
To broadcast in a bridge network, a given bridge only needs to send out the frames it receives on each of its active ports other than the port on which it received the frame.
On today's extended LANs, multicast is implemented in the same way as broadcast and it is up to each host to decide whether or not to accept a given frame.
It might be the case that not all LANs in a given extended LAN have a host that needs to be multicast to. Another proposed way to implement multicast is for each host to periodically send a frame with the address for the multicast group in its source field and have the multicast
address in its destination field. Bridges could then use the table algorithm to learn only those LANs that have hosts for that multicast address.
Limitations of Bridges
The set-up of the previous few slides can be used to create networks of tens of bridges.
The set-up does not scale to larger networks for a variety of reasons.
One problem is that if a destination is unknown it has to be broadcast. As the network gets bigger there are more unknown hosts, and this becomes more and more of an issue.
Another reason is that the spanning tree algorithm scales linearly in the number of nodes, so will take longer and longer to settle. It would
be useful to have a hierarchy of bridges to solve this.
Virtual LANs
One way to try to make extended LANs more scalable is to use virtual LANs (VLANs).
Each VLAN is assigned an identifier (a color).
Packets can only be sent from one segment to another if they have the same color.
This makes it possible to do things like have a VLAN for the CS department as part of the extended LAN of the Science college. CS traffic on this VLAN wouldn't go to the Math department's VLAN (also on Science's LAN)and so they wouldn't see our private messages.
The implementation of VLANs is specified in the 802.1Q spec. This spec changes the way Ethernet frames look to VLAN enabled bridges. It is backward compatible for non-such enabled bridges and hosts. Basically, before the length field in the frame 0x8100 is added, followed by a priority field, followed by a canonical format indicator, followed by the VLAN identifier.
Heterogeneity
As bridges make use of the frame header, they are limited to connect networks which have the same format for addresses.
So bridges could be used to interconnect Ethernets and Token rings. But they could not be used to connect to ATM networks.
So there are limitations on the heterogeneity of the networks you can use with bridges.