Frame Preemption (FPE)

IEEE802.1Qbu (frame preemption) breaks the interfering frame into smaller fragments. Therefore, the guard band needs to be only as large as the largest possible interfering fragment instead of the largest possible interfering frame. So how are the interfering frames broken down into smaller fragments, and how does the peer MAC process these received fragments? Let's continue on.

Before going into the details of FPE, let's watch a few simple demos to have an overview of the preemption mechanism.

As shown in Figure 1, the higher priority queue (E-Queue) wants to send frame at time $T_2$, while the lower priority queue (P-Queue) is sending frame.

When FPE is disabled, the sending process is shown in Figure 2. The E-Queue needs to wait for the P-Queue to finish sending frame before it starts sending. This causes a delay in sending the frame with a delay of $T_3 - T_2$.

When FPE is enable, the sending process is shown in Figure 3. The P-frame is cut off at time $T_2$ and the cut off portion is retransmitted at time $T_4$. As a result, the E-Frame can be sent on time.

As shown in Figure 3, the P-frame is split into two fragments for transmission. This results in each fragment not having enough information for the peer MAC's L2 protocol layer to process. For example, because the second fragment does not have an Ethernet type field, L2 cannot forward the fragment to the correct protocol handler. Therefore, 802.3-2022 Clause 99 - MAC Merge Sublayer defines MAC merge packet (mPacket) for encapsulating frames when FPE is enabled. In this way, fragments can be reassembled before forwarding to L2.

An mPacket contains one of the following^[a]:

• a complete express packet,
• a complete preemptable packet
• an initial fragment of a preemptable packet, or
• a continuation fragment of a preemptable packet

SMD values are used to distinguish different mPacket types. See Table 1 for the mapping of SMD values to mPacket types.

The SMD in an mPacket carrying a complete (non-fragmented) preemptable packet or any of the fragments of a preemptable packet also indicates the frame count. Information about the frame count prevents reassembling an invalid packet if the final mPacket of one preemptable packet and the initial fragment of the next preemptable packet are lost.

With the introduction of mPacket, we can outline the encapsulation process (Figure 4) of mPakcet in the Tx of the local MAC and the decapsulation process (Figure 5) in the Rx of the peer MAC.

Now we know that the fragments are encapsulated in an mPacket and sent to the peer MAC. But if the peer MAC doesn't support mPacket, all the sent fragments are discarded by the peer MAC. In other words, the one you love doesn't love what you give it.

Therefore, the verification process shown in Figure 6 should be performed between the local and peer MACs before FPE is enabled. The verification process uses Verify (SMD-V) and Respond (SMD-R) mPackets for interaction. After mutually confirming that the peer MAC has enabled FPE, the two MACs can send valid data fragments to each other.

Finally, the completed FPE system process process is given.