Data Flow Diagrams can represent any kind of processing, since it show how data moves between systems or processes or storage. DFD allow also to decompose systems/processes into sub-systems/sub-processes to see the details of a system's internal flows, up to the desired level of details.
However, DFD has several limitations, in view of your domain:
- It does not provide elaborate data modeling capabilities. It is based on a data dictionary and assumes a hierarchical decomposition of the data (to decompose the flows). It could be supported by complementary modelling techniques such as ERD, and would be sufficient to model SDN network packets.
- It is not suitable for object oriented technologies that you'd probably need for implementing your system.
- It is not suited for complex real time data flows that require timing constraints, timeout events, and other event-driven processing. That are typical for networking domains.
A better alternative would be UML. It provides:
- activity diagrams that provide similar capabilities than DFD, but with a precise semantic and object-oriented and event-processing capabilities.
- sequence diagram, to model exchanges between network components, that can express network protocols in a very clear manner.
- state diagrams, to model the state of individual network components
- deployment diagram to model a physical network architecture.
