How to parse packet trailer

Getting Started with P4
1

I need to parse and handle PRP RCT header which is a four octets header appended to packet trailer. My program needs to parse the Ethernet header and then make forwarding decision based on IP destination address. Then I will need to parse the PRP RCT header which is possible at the end of four bytes of the receiving packet.

I have the follow two options, but not sure of whether they are feasible:

  1. define a payload header with a varbit typed field, exact all packet data into the varbit typed field after parsing IPv4 header. But I don’t find a method to get the actual length of varbit and method to get the last four bytes from varbit for further parsing.

  2. Based on the packet length and also the parsed length of Ethernet and IPv4 headers, calculate the remaining length of packet not parsed. Then advance to the offset of the last four bytes. However, in this approach, I am not sure how to emit the skipped packet data when forwarding the packet out of output port.

2

Hello and welcome to the forum!

P4 does not have any built-in facilities to process packet trailers.

From the pure language perspective, you can, indeed, extract the payload as a varbit header and then proceed to the trailer. To do that, you have to know the payload length prior to the extraction. As you correctly pointed out, this is something you can do in case of IPv4.

Theoretically you can do something like this:

const int MAX_PAYLOAD_LEN_IN_BYTES=9216;

header payload_h {
    varbit<(MAX_PAYLOAD_LEN_IN_BYTES*8)> payload;
}
. . . 
struct headers_t {
    ethernet_h ethernet;
    ...
    ipv4_h     ipv4;
    payload_h  payload;
    prp_rct_h    prp_rct;
}
....
parser IngressParser(. . .)
{
   . . . 
    state parse_payload {
        pkt.extract(hdr.payload, (hdr.ipv4.total_length - hdr.ipv4.ihl * 4) * 8);
        pkt.extract(hdr.prp_rct);
        transition accept;
    }
}

Deparsing is as easy as emitting hdr.payload

Some targets might accept this code, but many won’t for a variety of reasons, such as specific limits that targets impose on the field or header size, the specific limits many targets impose on the parsing depth, etc.

Just as data point, the most popular “trailer” by far (also known as Ethernet FCS :slight_smile: ) is not usually processed in P4 programs and is left to the fixed-function components (MACs) to deal with.

1 Like
3

This information is very helpful. Thank you. For PRP protocol, it appends the RCT header at the end of payload before sending the packet out.

image
image1654Ă—466 49.5 KB