The barrier sort of serves as a confirmation message. When you send a switch a flow-mod, you ordinarily have no way of knowing when or if it has taken effect since there's no positive acknowledgement. We don't even know if it's valid. The switch might send an error, but we have no idea *when* it will send an error. However, according to the specification, when a switch sends a barrier reply, everything before the barrier should have been processed -- the table entry should actually be active, and if there was an error, the error messages should have been sent *before* we get the barrier reply.
The reason for clearing the flow tables when a link has changed is that the link event signifies that the topology has changed. This may mean that a path which was previously valid (which we are using!) is no longer valid. It may also mean that a path which was previously the shortest is no longer the shortest. If l2_multi kept track of all the paths it had installed and which were active, etc., it could figure this out and just fix the particular paths that need adjusting. But it doesn't, since this would considerably complicate what is supposed to be a relatively straightforward example. So it just clears everything and lets everything get rebuilt from scratch. -- Murphy On Dec 18, 2013, at 8:45 AM, Amer <amer7...@hotmail.com> wrote: > Hello, > > Very helpful explanation, > I would like to ask you about the barrier command and its replay. What is the > benefit from using it in l2_multi. Also, what is the benefit from clearing > flow-table contents, while receiving a LinkEvent. > > Best regards, > Amer > > On ١٦/١٢/٢٠١٣, at ٩:٢٦ ص, Murphy McCauley <murphy.mccau...@gmail.com> wrote: > >> There isn't. In short, it's like this: >> >> The discovery component raises LinkEvents when links change. >> >> l2_multi keeps an "adjacency" map. The value of adjacency[sw1][sw2] is the >> port which connects sw1 to sw2. This is updated by the l2_multi class, >> which watches LinkEvents. LinkEvents also cause all switches to have their >> tables cleared. >> >> The Switch class watches PacketIn events. When one occurs, it "learns" the >> source MAC (stored in mac_map). In the usual case, this should only be from >> a port which *doesn't* connect two switches (and therefore won't be in the >> the adjacency map). If we know the destination, we install a path from the >> current switch all the way to its final destination (if we don't, as usual, >> we flood). >> >> To install a path, we find the shortest path using the Floyd-Warshall >> algorithm, and then fill in the port numbers from the adjacency map. We >> send the flow-mods to all the switches on the path, followed by a barrier. >> When we have gotten the barrier reply from each switch, the entire path >> should be ready, so we send the waiting packet (that is, the packet which >> caused us to want to install the flow in the first place). >> >> >> Most of the rest of the code is to handle "exceptional" cases like >> multicasts, partitions, etc. >> >> Don't look to l2_multi as an example of a "good" way to write network-wide >> forwarding code, though. It's just a 500 line example which is meant to be >> relatively easy to understand. >> >> -- Murphy >> >> On Dec 15, 2013, at 8:24 PM, Amer <amer7...@hotmail.com> wrote: >> >>> Hello, >>> >>> I would like to ask you if there is a document that help me to understand >>> l2_multi code. >>> >>> Best regards, >>> Amer >> >>
