If a software defined network can implement standard Internet routing protocols, such as ISIS or OSPF, it should be able to work with FabricPath. The SDN needs to understand the new headers FP adds, within the fabric.

The basic innovation here is that at layer 2, instead of using a distance vector algorithm, which STP does, you use a link state algorithm. Each node computes a loop-free path to reach the other nodes. Sort of like, a spanning tree computed by each node, different from the trees computed by other nodes.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/fabricpath/configuration/guide/fp_cli.pdf

Which is why I'm claiming that if SDN can handle link state algorithms for routing at layer 3, presumably it can be made to do the same link state algorithm at layer 2, using the headers as described in the link above.

If you want to get the same functionality of FabricPath in an SDN, the solution is quite straightforward. You can ask the controller for the network topology, usually gathered via ARP and LLDP messages, and then run (say) Dijkstra's algorithm to compute minimum cost paths to every destination. Then tell the controller to install the appropriate flows at every switch.

With the former, you avoid loops and port blocking without requiring additional header overhead.

You may want to look into TRILL, which is a IETF standard that should replace STP. Links are above:

http://tools.ietf.org/html/rfc5556

http://tools.ietf.org/html/rfc6325