Packet- and Flow-Based Forwarding
I don’t like to correct my friends in public, but if someone says “I still believe that flow-based technologies will exceed the capabilities of packet-based technologies” (see Network Break 53), it’s time to revisit the networking fundamentals.
What is a flow?
According to Wikipedia (but what do they know…):
In packet switching networks, traffic flow, packet flow or network flow is a sequence of packets from a source computer to a destination, which may be another host, a multicast group, or a broadcast domain.
But maybe there’s something beyond packet-switching networks? Sure, you have three fundamental options:
- Frequency-division multiplexing (which includes radio and xWDM)
- Time-division multiplexing (SONET, SDH, T1, E1…)
- Statistical multiplexing (cells, frames, packets, datagrams…).
There are no flows (apart from bit streams) in frequency- or time-division multiplexing, so we’re left with statistical multiplexing, and if we call whatever we’re switching “packet” every non-(F|T)DM system is a packet-switching system.
It’s all packet-based
Every single device operating at layers 2-4 (TDM and FDM work on layer 1) that I’ve seen in my life does the same thing:
- Receive a packet;
- Inspect the packet header and extract the relevant fields;
- Perform forwarding table (or TCAM) lookup to find the output port(s);
- Send the packet to output queue(s).
I still haven’t seen an OpenFlow-based or any other flow-based system that would do anything fundamentally different.
Flow-based technologies that are envisioned today thus cannot exceed the packet-based technologies because every flow-based system switches packets, and I sincerely hope the claim I quoted above wasn't meant to be along the lines of “virtual circuit switching will exceed the capabilities of connectionless switching”, because we’ve seen too many times how well that worked.
It sounds a little to me like there's a confusion about the definition of a flow. Is your definition of a flow(sequence of similar packets from a to b) the same as your friend?
Keep up the awesome work simplifying all these sometimes complicated topics. (should be posted in your Thank you-post)
Regardless of what definition one takes, flow-based forwarding is always packet-based. Writing a follow-up blog post as we speak...
I have not heard this podcast...
A router is flow agnostic and doesn't need to respect the flow when deciding which next-hop to assign to a packet to adjust to, for example, changes in the lookup table that happen between packets, whereas a load-balancer does need to arrive at the same next-hop decision over and over again for each packet in the flow or it risks breaking the flow.
And this is more than PBR because it creates a unique entry for each flow, all of which are a match for the same PBR rule, allowing flow A to go to next-hop 1 and flow B to go to next-hop 2.
This is all still packet switching, but it is much more granular matches, which allows for much more granular actions and those actions can, because of the awareness of the flow context, do things that require the maintenance of state, particularly the state between a request and a response. When you do that at L4 you have a stateful firewall. When you do that at L7 or with the payload of L7, you have a load-balancer. When you do it because you really wish your packet switched network was a voice circuit or a virtual wire or a video channel you have a problem.
That doesn't absolve the original quote of it's shame, and in fact, this kind of network state is both very complicated to manage well and applicable to a shrinking number of must-use scenarios if sane technological decisions about things like ipv6 and network identity are made; we shouldn't be artificially increasing them, because they should be naturally decreasing over time.
(Of course, that quotes like that are not the consequence of sane technological decisions.)
However, there's an additional detail: while a flow-based forwarder treats all packets of the same flow in the same way (which might include always sending them toward the next hop), it still has to respond to changes in the forwarding table (for example, when the next hop becomes unreachable or is no longer a valid next-hop for the destination).
Pointer to a more complex implementation is highly appreciated.
Regardless, these fancy-pants devices are still shuffling packets to output queues.
And to Ian's point that routers/switches are flow-agnostic: try turning on per-packet ECMP, or send fragmented traffic over a L4-hashed LAG, and see how that agnosticism plays out ... :)
I am just a technical hands-on guy who doesnt undertand marketing so I would like to raise few basic points regarding openflow/sdn topic, which at this moment I dont have clarity on. Would you be able to comment on them:
At the moment, local CP (RIB) gets downloaded to FIB and we get packet forwarding on a router. If we start evaluating too many fields (PBR) and (assume) are able to push these policies to the FIB - what would become of the FIB table size ?? Wouldnt an open-flow based switch go through the same scaling issue on its forwarding level if each flow was to be treated differently on the device ??
If every device talking to a centralized control plane uses an out-of-band channel to talk to the openflow controller, isnt this a scaling concern?
And if devices dont use out-of-band channel to talk to the openflow controller, what will happen if a core link goes down affecting device <> controller communication? is it expected that the FIB of the device would already have a pre-programmed "alternate" or "backup" path computed and downloaded into it to be able to reroute packets?
Are we then talking about IP-FRR (which has topology restrictions) or LFA/RLFA ?..
what do OF/SDN standards propose to mitigate this issue
Also, the response time from centralized controller for network events would not be the same as a local CP on the device