-
Notifications
You must be signed in to change notification settings - Fork 141
ARP_Path Switch
- Status :
- Version :
- Last code update :
- Authors :
- NetFPGA base source :
The standard Rapid Spanning Tree Protocol RSTP is used in switched networks with redundant links to permit broadcast and address learning without frame loops, but it blocks redundant links. The standard Multiple Spanning Tree Protocol (MSTP) IEEE 802.1Q allows usage of redundant links configuring multiple spanning trees associated to different sets of VLANs, but is complex to configure.
To solve the above limitations, protocols were proposed at IEEE 802.1 and IETF TRILL Working Group for self-configuring shortest path bridges to be used at campus and enterprise networks. Routing Bridges (TRILL RBridges) at the IETF, and Shortest Path Bridges at IEEE 802.1 are the two standard protocols aimed to overcome the severe limitations that the spanning tree protocol imposes to switched networks. Both standard protocols and other alternative propietary protocols use a link state routing protocol (IS-IS protocol extended for layer two) two to compute proactively shortest paths between all bridges. The paths are shared by multiple hosts. Balancing the load at links requires equal cost multipath (ECMP) computations.
Conversely, ARP-Path protocol finds a path (reactively) between every pair of hosts just-in-time, flooding the standard ARP Request frame through all links, snooping it at bridges with a modified address learning mechanism that associates the source address of frame to the first-arrival port and locks this association for some time, discarding duplicated packets received via other ports just by matching its source address.
ARP-Path is the first protocol of the new family of transparent bridges identified as All-Path bridges. The basic idea is to explore with a broadcast packet flooded simultaneously through all network paths from the source host to destination host, learning only at every bridge the path with the lowest latency. ARP-Path reuses the standard ARP Request and ARP Reply packets to find an on-demand low latency path from source host to source to destination host.
The discovery of paths is performed with two messages: Path Request and Path Reply. The standard ARP Request packet is reused for path request and the ARP Reply for path reply.
The path discovery process is described as follows. When a source host S sends a standard ARP Request on an Ethernet broadcast frame B to resolve the IP address of a given destination host D, all traversed ARP-Path switches snoop that frame and associate the incoming port and the source MAC address, only of the first received copy of the ARP Request, thus creating an entry in a forwarding table. Later (slower) copies, which will arrive at different input ports, are discarded. Therefore, the ARP Request creates a tree rooted at the edge switch of the source host S, avoiding loops and, at the same time, creating paths for all possible destination to reach host S. Host D will reply with a unicast ARP Reply which will follow the recently created path to S and, at the same time, it will create a path to D by associating the incoming port and the MAC address of D in the forwarding table.
For more detail, watch: http://youtu.be/IhwCYAu_E7E
Established paths may get broken at some point either by the expiration of an address timer or by failure or initialization of a link or bridge. ARP-Path switches do not replicate unknown unicast frames over all bridge ports when there is no path learnt at bridge to destination address. When a link connecting two bridges fails, all MAC addresses learnt at both ports ending the link are flushed. The same happens at all ports of a node, when the node reinitializes. Then, whenever a bridge receives a frame with an unknown unicast destination address (i.e. the address is not associated to any port of bridge), the path may be rebuilt from the source bridge or from the current bridge. Many variants of these two approaches can be designed; we explain here the repair method implemented in our NetFPGA project.
In this case, when a unicast frame reaches a switch with no forwarding entry for its destination MAC address, a Path_Fail special message that encapsulates the frame's source and destination MAC addresses is created and broadcast in the network. Eventually the Path_Fail will reach the edge switch of the host that has that destination MAC address and the edge switch will reply with a Path_Request message on behalf of its host, which could also be replaces by an ARP Request message, since the actions carried out to learn the path again are the same for both messages.
- Zero configuration routing protocol.
- Low latency paths (shortest paths)
- Load balancing
Sources for the project can be downloaded from
https://docs.google.com/file/d/0B-pAPCvBuxmQOVZNc3hlb0hYOGc
NOTE: You should also first install from NetFPGA Yum repository:
- Install the NetFPGA Base Package
First of all, read the "README" file, which explains in detail the usage of this project.However it does not include the link failure detection, which is the third step of the three needed to start the project:
- 1) Download the ARP-Path Switch project:
$ nf_download <path_to_arppath.bit>In 'netfpga/projects/arppath/lib/C' directory:
- 2) Start ARP-Path Switch:
$ ./cli -s<switch_mac> -m1 -F -l<lt_timeout> -b<bt_timeout> \
-r<rt_timeout> -e<hello_timeout> -p<hello_period_shift>
For help:
$ ./cli -h
- 3) Activate link failure detection routine (if not active, the project will work and forward frames, but repair will not work):
$ ./cliloop
For more info about our switching projects, ARP-Path and the All-Path family, visit our video channel at: https://www.youtube.com/gistnetserv/videos