In this new networking era, characterized by the dissemination of concepts such as SDN, automation, X-ops (e.g. DevOps, NetOps, SecOps, etc), it is always good, in fact, critical I would argue, to take time and ponder what some of these commonly used concepts really mean.
Once you start peeling these concepts, you may find that some of those are either old concepts “with new wrapping paper” or incremental variations from old concepts and only occasionally, you are lucky to really find a totally new definition. Those of you who are not new in networking must be nodding your heads in agreement.
However, there are other concepts or definitions which can easily trigger “silent” confusions – those confusions when speakers both believe understand the concept – when in reality, their understandings are different or too general. One of these concepts on top of my list is the definition of flow in networking.
Do you know what a flow is ? — Ohh…that question can make many network engineers, security engineers, system administrators, software engineers, and SDN engineers nod their heads affirmatively and quickly say yes – probably all at once.
Well, a flow is exactly one of those concepts that is ideal for causing undetected confusions. In this blog, I’ll review a few of the different meanings and their applicable context as well as some of the potential “silent” confusions which can derive from these.
Let’s start by checking what “Mr. Google” find for us as answers to the: what is a flow? question:
In Network security, often a flow is defined as the set of packets which satisfies a 5-tuple matching of the packet header fields: Source IP address, Destination IP address, Protocol (these in the IP header), Source Port, and Destination Port (these last two at the TCP or UDP header).
In Ethernet, Network engineers often leverage the IEEE 802.3ad (now IEEE 802.1ax) standard to bundle multiple physical ethernet links and load balance traffic across them. In this context, a flow could mean a set of frames whose following 5-tuple header fields match: SA, DA, protocol, TCP/UDP SA and TCP/UDP DA.
In the RSVP RFC (RFC 2205), a flow is defined as part of an “RSVP session” which; subsequently, is defined by a set of packets with the following matching triple header fields: IP Destination Address, IP header Protocol ID, and a “generalized” Destination Port. The generalized destination port can be either a UDP/TCP destination port field or another “application-specific” information.
Also in RSVP, there is this concept of “Flowspec” which, along with a filter spec, define a “flow descriptor”. It is this flow descriptor which, along with a session specification, defines a common set of data packets — yes… it defines “the flow” in RSVP.
When using netflow, there definition of flow data can be rather specific. Cisco, as the creator of net flow, originally defined a flow as a unidirectional set of packets matching a set of 7-tuple header fields: Ingress Interface (SNMP ifIndex), Source-IP address, Destination IP address, IP protocol, Source UDP/TCP port, Destination UDP/TCP port, and IP Type of service. As netflow had additional releases and other versions (e.g. IPFIX) came to the market place, the original concept of a 7-tuple flow definition was abandoned and it gave users freedom to assign the matching fields defining a flow.
When dealing with IPv6 packets, it is entirely possible to define a flow in a unique way given that the IPv6 header field includes a field called: “flow label”. This label technically provides the flexibility to define any set of IPv6 packets to be part of the same “flow” by simply assigning a common value in their IPv6 flow label.
In an SDN Openflow, the matching field of a given flow can technically be any combination from 1-15 fields. An interesting remark is that the ONF’s Openflow standard uses the word “flow” frequently even though it does not explicitly provide its definition.
So, in a nutshell, keep in mind that the concept of flow can be a chameleon in the networking lexicon ecosystem.