[P4-dev] [P4-discuss] Can we start a new flow from p4 switch?

Antonin Bas antonin at barefootnetworks.com
Fri Oct 27 16:30:19 EDT 2017

Adding p4-dev mailing list.

Hi Robin,

You seem to be describing OpenFlow packet-in / packet-out feature - or more
precisely here packet-in since you are referring to packets sent by the
switch to the controller.
The way this is usually achieved is by sending appropriate packets to a
special port, called the CPU port, potentially encapsulated in a custom
header. Unlike OpenFlow, P4 doesn't mandate anything in this regard, but
you usually need this custom header to carry relevant metadata information,
such as the incoming port number of the packet.
In the case of bmv2, this CPU port number can be anything you want, but
actual hardware targets often mandate a special value.

The exact meaning of the CPU port can depend on the P4 target. In bmv2, all
packets are sent to an interface of your choice, and you can read / write
from it. See this P4_14 example:

In P4 Runtime however, we define higher-level APIs for packet-in /
packet-out, which are very close to OpenFlow (
This enables the applications to use packet-in / packet-out in a
target-independent way. The closest thing we have to an example is this
but we hope to add more concrete examples very soon.

On Fri, Oct 27, 2017 at 1:11 PM, Andy Fingerhut <andy.fingerhut at gmail.com>

> Regarding your point 1)
> The digest mechanism does not generate a packet that goes out a 'normal'
> port.  It generates a message in some implementation-specific form that
> goes to the control plane software.
> Features like counters, meters, registers, digest, recirculate, resubmit,
> clone, action profiles and selectors, were all part of the P4_14 base
> language, and thus you find them in the P4_14 language specification
> documents and the open source implementations, including the 1.0.3 you
> mention, which is most likely v1.0.3 of the P4_14 language spec.
> Those features were intentionally separated into 'extern's in P4_16, so
> are not part of the base language specification.  There is a PSA (Portable
> Switch Architecture) document being worked on now, the latest draft is here
> [1], which defines those things for switches.  The digest mechanism in PSA
> is something that still isn't quite nailed down yet, and I don't know the
> current state of the open source tools on P4_16 and the digest mechanism.
> Most things in P4 assume a model of "specify what the P4-programmable
> device does when it receives a packet".  There isn't anything in it that
> says "spontaneously wake up and start generating traffic".  Now if you took
> a P4-programmable device and added a mechanism, not specified in P4, that
> caused packets with particular contents to be sent to the P4-programmable
> device, e.g. based upon timer events firing, or from control plane
> software, then that combined system could be made to act as if the
> P4-programmable device was initiating flows to the rest of the world, but
> the P4-programmable part would still only be specifying how it reacts to
> packets when it receives them.  Hopefully I explained that in an
> understandable way.
> I am not familiar enough with how an openflow switch can initiate
> communication to other devices, so could be missing something here.
> Andy
> [1] https://p4lang.github.io/p4-spec/   (look for the links to the PSA
> document -- remember, still in draft form right now)
> On Wed, Oct 25, 2017 at 11:43 AM, Debobroto Das Robin <drobin at kent.edu>
> wrote:
>> Andy, Thanks a lot for the reply.
>> 1) The digest mechanism is obviously a new direction to me. I was reading
>> the P4_16 specs and there was no "digest" keyword. Then i moved to version
>> 1.0.3 and found the digest mechanism. Is the digest mechanism available in
>> P4 16? In case of digest, generate_digest  will not initiate a new flow. It
>> basically generates a reply after processing a packet. (if my understanding
>> are correct)
>> 2) I know about clone based mechanism.
>> Let me explain my question a little bit more detail. Think about an
>> openflow like protocol. Here both the controller and switch can initiate
>> communication toward each other. Now if we want to achieve this kind of
>> switch initiated communication (i.e. new flow), what would be the best
>> technique in P4  ?
>> Robin
>> On Wed, Oct 25, 2017 at 2:27 PM, Andy Fingerhut <andy.fingerhut at gmail.com
>> > wrote:
>>> The digest mechanism is intended to send a 'record' containing a
>>> P4-program-specified collection of field values to the control plane, as
>>> the result of processing a received packet.  The prototypical example is if
>>> the P4 program was implementing Ethernet learning bridge functionality, if
>>> the source MAC address of the received packet was not currently in the MAC
>>> address table, then the P4 program would send a digest containing the
>>> packet's source MAC address and ingress port it arrived on (and perhaps
>>> other field values, too).
>>> In addition to processing the received packet 'normally' (whatever that
>>> means for your application), the clone mechanism can be used to create
>>> another copy of the received packet, and then your P4 program can process
>>> it differently before sending it to a different destination than the
>>> 'normal' copy.  That clone could be sent to the control plane, to a
>>> different port, be tunnel-encapsulated, etc.
>>> The P4 language is probably not the best fit for trying to implement the
>>> behavior of a TCP endpoint, with all of the data buffering and packet
>>> retransmission behavior that requires.  Not sure if you were even thinking
>>> along those lines, but wanted to mention it.
>>> Andy
>>> On Wed, Oct 25, 2017 at 11:12 AM, Debobroto Das Robin <drobin at kent.edu>
>>> wrote:
>>>> Hello All,
>>>> Is there any option to start a new flow from p4 switch? For example
>>>> based on certain event at switch we want to send a notification to control
>>>> plane or some other destination. Is it possible?
>>>> _______________________________________________
>>>> P4-discuss mailing list
>>>> P4-discuss at lists.p4.org
>>>> http://lists.p4.org/mailman/listinfo/p4-discuss_lists.p4.org
> _______________________________________________
> P4-discuss mailing list
> P4-discuss at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-discuss_lists.p4.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20171027/3b0ca8f7/attachment-0002.html>

More information about the P4-dev mailing list