What Exactly Is The Control Plane?
Tassos opened an interesting can of worms in a comment to my Management, Control and Data Planes post: Is ICMP response to a forwarded packet (TTL exceeded, fragmentation needed or destination unreachable) a control- or data-plane activity?
Other control plane protocols (BGP, OSPF, LDP, LACP, BFD ...) are more clear-cut – they run between individual network devices (usually adjacent, but there’s also targeted LDP and multihop BGP) and could be (at least in theory) made to run across a separate control plane network (or VRF).
Control plane protocols usually run over data plane interfaces to ensure shared fate – if the packet forwarding fails, the control plane protocol fails as well – but there are scenarios (example: optical gear) where the data plane interfaces cannot process packets, forcing you to run control plane protocols across a separate set of interfaces.
Typical control plane protocols aren’t data-driven: BGP, LACP or BFD packet is never sent as a direct response to a data plane packet.
ICMP is different: some ICMP packets are sent as replies to other ICMP packets, others are triggered by data plane packets (ICMP unreachables and ICMPv6 neighbor discovery).
Trying to classify protocols based on where they’re run is also misleading. It’s true that the networking device CPU almost always generates ICMP requests and responses (it doesn’t make sense to spend silicon real estate to generate ICMP responses). In some cases, ICMP packets might be generated in the slow path, but that’s just how a particular network operating system works. Let’s ignore those dirty details for the moment; just because a device’s CPU touches a packet doesn’t make that packet a control plane packet.
Vendor terminology doesn’t help us either. Most vendors talk about Control Plane Policing or Protection, equating control plane with the device CPU – these mechanisms usually apply to control plane protocols as well as data plane packets punted from ASICs to the CPU.
Even IETF terminology isn’t exactly helpful – while C in ICMP does stand for Control, it doesn’t necessarily imply control plane involvement. ICMP is simply a protocol that passes control messages (as opposed to user data) between IP devices.
Honestly, I’m stuck. Is ICMP a control plane protocol that’s triggered by data plane activity or is it a data plane protocol? Can you point me to an authoritative source explaining what ICMP is? Share your thoughts in the comments!
But FWIW, wouldn't Openflow have many of the same issues with classification, since a lot of Openflow traffic is going to be generated in response to unknown packets?
- Nik Weidenbacher
Control plane is a process by which certain states are derviated to aid data plane. Most of the protocols (BGP, OSPF...) derive states independent of data plane. Certain protocols like Multicast, ICMP use data plane itself to arrive at states to aid data plane.
Strictly speaking, Control plane policing (CoPP) could probably be renamed to CPU Policing, as policies both control and data plane.
1. From the definition point of view ICMP is the control plane protocol.
2. From the hardware point of view some protocols (like ICMP, BFD) can be offloaded to line cards so they do not affect the HW control plane which is represented by a control module. It is hard to say about PING represented by an ICMP Echo Request that this is a control-plane packet on distributed devices. An LC can respond. Thus no operations really needed on the RP CPU.
3. Does it mean that the control plane can be just attributed to the HW module? Of course not. The control plane is more like an abstraction - as someone mentioned earlier. So from the functionality/abstraction point of view some protocols can be the control/data/mgmt (match any) plane protocols at the same time.
So, i can see a clear role for ICMP as a two-way control plane protocol handling the status/info communication between devices and as an one-way control plane protocol handling the error reporting of a device towards another.
I think that the answer should be: depends on implementation. It could be a process running on router CPU (control plane process) or hardware ASIC (data plane).
Same is for ICMP replies. Some hardware may implement it in ASIC, but usually this is a kernel process (control plane).
The pass through devices - data plane is initiated.