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 > >
