~~PAGEIMAGE:network:ethernet:tsn:fpe:media:demo-3.svg~~

====== Frame Preemption (FPE) ======

{{template>:meta:template:pageinfo#tpl |desc=Introduces how <wrap abbr>FPE</wrap> works.}}

<wrap doc>IEEE802.1Qbu</wrap> (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.

===== Preemption Mechanism =====

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

As shown in [[#demo-1|Figure 1]], the higher priority queue (<wrap abbr>E-Queue</wrap>) wants to send frame at time $T_2$, 
while the lower priority queue (<wrap abbr>P-Queue</wrap>) is sending frame.

<wrap #demo-1 />
{{ network:ethernet:tsn:fpe:media:demo-1.svg |}}
<WRAP nof>Figure 1. Multiple queues want to send frame</WRAP>

When <wrap abbr>FPE</wrap> is disabled, the sending process is shown in [[#demo-2|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$.

<wrap #demo-2 />
{{ network:ethernet:tsn:fpe:media:demo-2.svg |}}
<WRAP nof>Figure 2. Send frame in non-preemptive mode</WRAP>

When <wrap abbr>FPE</wrap> is enable, the sending process is shown in [[#demo-3|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.

<wrap #demo-3 />
{{ network:ethernet:tsn:fpe:media:demo-3.svg |}}
<WRAP nof>Figure 3. Send frame in preemptive mode</WRAP>

===== MAC Merge Packet (mPacket) =====

As shown in [[#demo-3|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 [[https://en.wikipedia.org/wiki/EtherType#Values|Ethernet type]] 
field, L2 cannot forward the fragment to the correct protocol handler.
Therefore, <wrap doc>802.3-2022 <wrap clause>Clause 99 - MAC Merge Sublayer</wrap></wrap> defines **MAC merge packet** 
(<wrap abbr>mPacket</wrap>) for encapsulating frames when <wrap abbr>FPE</wrap> is enabled. In this way, fragments can
be reassembled before forwarding to L2.

An **mPacket** contains one of the following((:9844436-p4091)):
  * a complete express packet,
  * a complete preemptable packet
  * an initial fragment of a preemptable packet, or
  * a continuation fragment of a preemptable packet

==== mPacket Format ====

{{ network:ethernet:tsn:fpe:media:20231102-150109.png?direct&600 |}}
<WRAP nof><wrap doc>802.3-2022 <wrap clause>Figure 99–4 mPacket format</wrap></wrap></WRAP>

==== SMD ====

<wrap abbr>SMD</wrap> values are used to distinguish different **mPacket** types. See [[#smd-values|Table 1]]
for the mapping of <wrap abbr>SMD</wrap> values to **mPacket** types.

<wrap #smd-values />
<WRAP not>Table 1. **SMD** values ((:9844436-p4093))</WRAP>
^ mPacket type                             ^ Notation  ^ Frame count  ^ Value  ^
| <wrap #verify-mpacket />verify packet    | SMD-V     | -            | 0x07   |
| <wrap #respond-mpacket />respond packet  | SMD-R     | -            | 0x19   |
| express packet                           | SMD-E     | -            | 0xD5   |
| preemptable packet start                 | SMD-S0    | 0            | 0xE6   |
| :::                                      | SMD-S1    | 1            | 0x4C   |
| :::                                      | SMD-S2    | 2            | 0x7F   |
| :::                                      | SMD-S3    | 3            | 0xB3   |
| continuation fragment                    | SMD-C0    | 0            | 0x61   |
| :::                                      | SMD-C1    | 1            | 0x52   |
| :::                                      | SMD-C2    | 2            | 0x9E   |
| :::                                      | SMD-C3    | 3            | 0x2A   |

The <wrap abbr>SMD</wrap> 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__. 
==== FRAG_COUNT ====

<WRAP not>Table 2. FRAG_COUNT values ((:9844436-p4093))</WRAP>
^ Frag_count  ^ Value  ^
| 0           | 0xE6   |
| 1           | 0x4C   |
| 2           | 0x7F   |
| 3           | 0xB3   |

===== Encapsulation and Decapsulation Process =====

With the introduction of [[#mac_merge_packet_mpacket|mPacket]], we can outline the encapsulation process 
([[#fpe-tx-flow|Figure 4]]) of <wrap abbr>mPakcet</wrap> in the Tx of the local MAC and the 
decapsulation process ([[#fpe-rx-flow|Figure 5]])  in the Rx of the peer MAC.

<wrap #fpe-tx-flow />
{{ network:ethernet:tsn:fpe:media:fpe-tx-flow.svg?600 |}}
<WRAP nof>Figure 4. FPE encapsulation process</WRAP>

<wrap #fpe-rx-flow />
{{ network:ethernet:tsn:fpe:media:fpe-rx-flow.svg?600 |}}
<WRAP nof>Figure 5. FPE decapsulation process</WRAP>

===== Preemption Verification Process =====

Now we know that the fragments are encapsulated in an <wrap abbr>mPacket</wrap> and sent 
to the peer MAC. But if the peer MAC doesn't support <wrap abbr>mPacket</wrap>, __all the 
sent fragments are discarded by the peer MAC__. In other words, the one you love doesn't
love what you give it. <wrap scale>:-O</wrap>

Therefore, the verification process shown in [[#verify-process|Figure 6]] should be performed
between the local and peer MACs before <wrap abbr>FPE</wrap> is enabled. The verification process
uses <wrap element>[[#verify-mpacket|Verify]] </wrap> (<wrap notation>SMD-V</wrap>)
and <wrap element>[[#respond-mpacket|Respond]]</wrap> (<wrap notation>SMD-R</wrap>) 
<wrap abbr>mPackets</wrap> for interaction. 
After mutually confirming that the peer MAC has enabled <wrap abbr>FPE</wrap>, the two MACs can
send valid data fragments to each other.

<wrap #verify-process />
{{ network:ethernet:tsn:fpe:media:preemption-verify-flow.svg |}}
<WRAP nof>Figure 6. Preemption verification process</WRAP>

===== FPE System Process =====

Finally, the completed <wrap abbr>FPE</wrap> system process process is given.

{{ network:ethernet:tsn:fpe:media:fpe-txrx.svg?900 |}}
<WRAP nof>Figure 7. FPE system process</WRAP>

{{template>meta:template:refnote#ref}}