Network interface with data protection

Abstract

Technologies for optimizing area and latency for network interfaces with data protection are described. One system includes a Media Access Control (MAC)unit coupled to a physical coding sublayer (PCS) through a media-independent interface (MII bus) and a MACsec engine located between the MAC unit and the PCS. The MAC unit provides MII signals with packet data on the MII bus, provides extra MII signals on the MII bus to eliminate MII bus decoding by the MACsec engine, and provides early packet signals to the MACsec engine. The early packet signals allow the MACsec engine to perform classification and transformation ahead of receiving the MII signals with the packet data on the MII bus. The MACsec engine modifies the packet data with substantially zero egress latency.

Description

Attorney Docket No.: 27170.1109 (L1057PCT)NETWORK INTERFACE WITH DATA PROTECTIONBACKGROUND

[0001] Network interfaces serve as the bridge between computing systems and communication networks, enabling the transmission and reception of data packets over various network topologies. These interfaces typically comprise multiple functional layers, including media access control (MAC) units that manage data frame processing and physical coding sublayers (PCS) that handle the conversion of digital data for transmission over physical media.

[0002] In modern networking applications, particularly in automotive and industrial environments, there is an increasing demand for secure data transmission to protect against unauthorized access and data tampering. MAC layer security protocols, such as those defined by IEEE 802.1AE (MACsec), provide encryption, authentication, and integrity protection for data frames at the data link layer. These security mechanisms typically involve classification of incoming data frames to determine appropriate security policies, followed by cryptographic operations to encrypt payloads and generate Integrity Check Values (ICVs).

[0003] Traditional network interface architectures place security processing components at various points in the data path, often requiring complex coordination between different functional blocks. The placement and timing of security operations can significantly impact overall system performance, particularly in terms of processing latency and resource utilization. In applications where timing constraints are stringent, such as real-time automotive networks or industrial control systems, even small delays in data processing can affect system functionality.

[0004] Low-speed network implementations, such as 10 Mbps and 100 Mbps Ethernet variants commonly used in cost-sensitive applications, present particular challenges for security processing. The relatively narrow data buses and lower clock frequencies associated with these implementations can result in extended processing times for security operations. Additionally, half-duplex network configurations, which are sometimes employed in automotive applications to reduce wiring complexity, introduce collision detection and avoidance mechanisms that can be sensitive to processing delays in the data path.

[0005] The integration of security processing with existing network interface components often involves trade-offs between security functionality, processingAttorney Docket No.: 27170.1109 (L1057PCT)efficiency, and system complexity. Conventional approaches may require substantial buffering, complex timing coordination, or modifications to standard interface protocols, which can increase implementation costs and reduce compatibility with existing network infrastructure components.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

[0007] FIG. 1 is a block diagram of a transmitting path of a network interface with a MACsec engine configured for area- and latency-optimized data protection according to at least one embodiment.

[0008] FIG. 2 is a block diagram of a transmitting path of a network interface configured for optimized data protection with enhanced MAC signaling capabilities according to at least one embodiment.

[0009] FIG. 3 illustrates a bus timing diagram that demonstrates the temporal relationships and signaling coordination between the components shown in FIG. 2 according to at least one embodiment.

[0010] FIG. 4 illustrates a flowchart of a method for operating a transmitting path of a MACsec engine with optimized area and latency characteristics according to at least one embodiment.DETAILED DESCRIPTION

[0011] Technologies for optimizing area and latency for network interfaces with data protection are described. The following description sets forth numerous specific details, such as examples of specific systems, components, methods, and the like, in order to provide a clear understanding of various embodiments of the present disclosure.However, it will be apparent to one skilled in the art that at least some embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known components or methods are not described in detail or presented in a simplified block diagram format to avoid unnecessarily obscuring the present disclosure. Thus, the specific details set forth are merely exemplary examples. Particular implementations may vary from these exemplary details and still be contemplated within the scope of the present disclosure.Attorney Docket No.: 27170.1109 (L1057PCT)

[0012] As described above, there is an increasing demand for secure data transmission to protect against unauthorized access and data tampering, such as in the automotive and industrial environments. Automotive and industrial Ethernet networks increasingly rely on the Media Access Control Security (MACsec) protocol to ensure secure data transmission. MACsec provides encryption, integrity checking, and packet classification to safeguard communication between nodes. These security functions, however, must be performed without introducing excessive delay or consuming excessive silicon area, particularly in cost- and latency-sensitive environments such as automotive Ethernet operating at 10 Mbps, 100 Mbps, and 1 Gbps data rates.

[0013] Conventional approaches to integrating MACsec into Ethernet systems typically involve combining an off-the-shelf Ethernet Media Access Controller (MAC) with a separate MACsec product operating across a Media Independent Interface (Mil). In these architectures, the MACsec engine must decode the Mil bus to detect frame boundaries, including the start-of-frame, end-of-frame, and frame check sequence (FCS). This process requires deep pipelines, data collection, and buffering to align processing with packet boundaries. As a result, such systems exhibit significant egress latency, and consume additional silicon area. These drawbacks are particularly problematic for applications requiring half -duplex operation, such as lOBase-TlS Ethernet (10Mbit single-pair Ethernet with shared medium), where large latency values preclude reliable performance.

[0014] Accordingly, there is a need for an improved MACsec architecture that can operate with predictable, minimal latency while reducing silicon area and remaining compatible with standard Ethernet MAC and physical coding sublayer (PCS) implementations.

[0015] Aspects and embodiments of the present disclosure can address these challenges and others by providing a network interface architecture that provides area and latency optimized data protection for various networks, including automotive and industrial Ethernet networks. Aspects and embodiments of the present disclosure can be applicable to various port rates: from 10Mbit to Gigabits per second, including lOBase-TlS due to its half-duplex nature.

[0016] Aspects and embodiments of the present disclosure provide a MACsec architecture located between an Ethernet MAC and a physical coding sublayer (e.g., PCS or physical-level collision avoidance (PLCA) component). In contrast to conventional approaches, the Ethernet MAC is extended to deliver additional signaling to the MACsecAttorney Docket No.: 27170.1109 (L1057PCT)engine. The additional signaling can include early packet signals and supplemental Mil bus signals. In particular, the MAC can provide early packet signals to allow the MACsec engine to perform classification and transformation ahead of packet data appearing on the Mil bus, allowing the MACsec engine to modify the data with basically zero egress latency. In particular, the MAC can provide supplemental signals, in addition to the standard Mil bus signals, to eliminate time-consuming Mil bus decoding. The base functions of the MAC and PCS / PLCA are otherwise unchanged. Such signaling includes indications of packet start, end, and packet data, as well as supplemental Mil signals (e.g., start-of-frame and end-of-frame markers) that explicitly define packet boundaries.

[0017] By receiving this early information, the MACsec engine can perform classification, header inspection, and cryptographic preparation "just-in-time," prior to the arrival of the packet data that must be modified. This eliminates the need for decoding the Mil bus to detect frame boundaries, thereby removing long pipelines, data collection buffers, and latency fixing mechanisms.

[0018] The system leverages the natural timing characteristics of the Mil interface, where the reconciliation layer (the component that adds preambles and manages the physical interface timing) adds preambles that inherently delay packet transmission, creating an opportunity window for parallel processing. For example, in a 10 Mbit Mil implementation with 4 bits per clock, the 8-byte preamble with SFD (start of frame delimiter) provides approximately 16 clock cycles of advance processing time. The MACsec engine utilizes this timing advantage to complete header inspection, packet classification, and security tag preparation before the actual packet data requires modification.

[0019] Aspects and embodiments of the present disclosure eliminate the conventional decoder function that typically consumes 8 or more clock cycles to identify packet boundaries from the Mil bus. Instead of sequential processing stages, the system enables parallel execution of classification and transformation operations in a different timing domain. The MACsec engine receives first information comprising early packet signals for start, stop, and data, enabling header inspection and classification before data arrival. Additionally, the MACsec engine receives second information indicating the start and end of Layer 2 (L2) packet data, including Ethernet padding when present. This approach reduces MACsec processing latency to nearly zero or one clock cycle, compared to conventional systems with greater egress latency.Attorney Docket No.: 27170.1109 (L1057PCT)

[0020] Aspects and embodiments of the present disclosure provide significant silicon area reduction by eliminating deep pipelines, data collection buffers, and latency compensation mechanisms required in traditional implementations.

[0021] The system maintains compatibility with existing MAC and PCS functionality, including Time-Sensitive Networking (TSN) operations, while requiring only minimal updates to standard Ethernet MAC implementations. For half -duplex automotive applications, the near-zero latency enables proper collision detection and carrier sense functionality that would otherwise be compromised by processing delays. The TSN functionality can be implemented in the MAC core, relying on fixed-latency path afterwards. The MAC core can reserve extra space for MACsec expansion as a normal way of using MACsec after the MAC unit. Aspects and embodiments of the present disclosure can support IEEE 802.3br pre-emption, but would need more signals.

[0022] The MACsec engine performs standard security operations including packet encryption, integrity checking, and authentication tag generation, but with optimized timing coordination. The system supports various MACsec modes including bypass, integrity -only protection, and combined confidentiality and integrity protection.

[0023] Aspects and embodiments of the present disclosure may be implemented across different Mil interface speeds, from 10 / 100 Mbit Mil with 4-bit data paths to higher-speed implementations like GMII with 8-bit paths. The early packet data interface may utilize bus widths as Mil or higher depending on the specific MAC core implementation. The system includes additional control signals for data valid and last word (EOP) byte alignment when wider data buses are employed.

[0024] The MACsec engine incorporates classification logic that determines security policies based on packet headers received through the early signaling interface.Transform logic applies the appropriate security operations including encryption, security tag insertion, and Integrity Check Value generation. Aspects and embodiments of the present disclosure enable constant latency operation by design, ensuring predictable timing behavior regardless of packet content or classification results.

[0025] Frame check sequence operations are optimized through early knowledge of packet boundaries, eliminating the need to detect FCS locations through bus monitoring. The system supports automotive Ethernet requirements including multi-drop bus configurations and collision avoidance protocols. Aspects and embodiments of the present disclosure provide a scalable solution that can be adapted to various throughput requirements while maintaining the core latency optimization benefits. ImplementationAttorney Docket No.: 27170.1109 (L1057PCT)flexibility allows the system to operate with or without enhanced MAC signaling, providing backward compatibility with existing infrastructure.

[0026] FIG. 1 is a block diagram of a transmitting path of a network interface 100 with a MACsec engine 102 configured for area- and latency-optimized data protection according to at least one embodiment. The network interface 100 includes a TX packet buffer 104, a MAC unit 106, the MACsec engine 102, and a PCS or PLCA component 108.

[0027] The TX packet buffer 104 serves as a temporary storage component that receives and holds Layer 2 (L2) packets awaiting transmission processing within the network interface. The TX packet buffer 104 is positioned at the input stage of the transmission pipeline and is configured to interface with upstream packet sources such as host processors, network controllers, or other data generation components. The functionality of the TX packet buffer 104 can vary based on the specific implementation.

[0028] The TX packet buffer 104 is implemented as a memory structure capable of storing complete Ethernet frames, including MAC headers and payload data. The TX packet buffer 104 may be configured with sufficient capacity to hold multiple packets simultaneously, enabling efficient packet queuing and flow management. In some embodiments, the TX packet buffer 104 may support variable packet sizes ranging from minimum Ethernet frame lengths up to jumbo frame sizes exceeding 1500 bytes.

[0029] The TX packet buffer 104 includes interface logic for receiving packet data from upstream sources and providing packet data to the downstream MAC unit 106. The TX packet buffer 104 may implement First-In-First-Out (FIFO) queuing mechanisms to ensure proper packet ordering during transmission. In alternative embodiments, the TX packet buffer 104 may support priority -based queuing with multiple internal queues for different traffic classes or Quality of Service (QoS) levels.

[0030] The TX packet buffer 104 is configured to coordinate with the MAC unit 106 through flow control signaling to prevent buffer overflow or underflow conditions. The TX packet buffer 104 may provide status indicators such as buffer fill levels, empty / full flags, and ready signals to enable proper timing coordination with the MAC processing pipeline. This coordination ensures that packet data is available when required by the MAC unit 106 while preventing data loss due to timing mismatches.

[0031] In some embodiments, typically used in safety critical systems, the TX packet buffer 104 may include packet validation functionality to verify frame integrity before forwarding to the MAC unit 106. The TX packet buffer 104 may perform basic checksAttorney Docket No.: 27170.1109 (L1057PCT)such as minimum / maximum frame length validation, header format verification, or protocol-specific checksum validation to identify potentially corrupted packets early in the transmission process.

[0032] The TX packet buffer 104 may be implemented using various memory technologies including static RAM (SRAM), embedded memory blocks, or external memory interfaces depending on the specific system requirements. For automotive and industrial applications requiring deterministic timing behavior, the TX packet buffer 104 may utilize dedicated on-chip memory to minimize access latency and ensure predictable performance characteristics.

[0033] In alternative configurations, the TX packet buffer 104 may support advanced features such as packet timestamping for Time-Sensitive Networking (TSN) applications, packet modification capabilities for header insertion or VLAN tagging, or diagnostic functions for network monitoring and troubleshooting purposes.

[0034] The TX packet buffer 104 may alternatively be implemented as a Direct Memory Access (DMA) component or DMA buffer that provides efficient data transfer capabilities between system memory and the network transmission pipeline. In this configuration, the TX packet buffer 104 includes DMA controller functionality that can autonomously fetch packet data from host system memory without requiring continuous processor intervention.

[0035] When implemented as a DMA buffer, the TX packet buffer 104 may include address generation logic, burst transfer capabilities, and memory interface controllers that enable high-throughput data movement from external memory sources. The DMA functionality allows the TX packet buffer 104 to pre-fetch multiple packets from system memory and maintain them in local storage for immediate availability to the MAC unit 106.

[0036] The TX packet buffer 104 is operatively connected to a MAC unit 106, which performs media access control functions and is configured to provide early signaling information 120 to the MACsec engine 102 before payload data transmission on the Mil bus. The MAC unit 106 represents an enhanced Ethernet Media Access Controller that has been specifically extended to support optimized MACsec processing through additional signaling capabilities, referred to herein as early signaling information 120. Unlike conventional MAC implementations, the MAC unit 106 is configured to provide early packet information to downstream security processing components before the packet data appears on the standard MU bus. In at least one embodiment, the MAC unitAttorney Docket No.: 27170.1109 (L1057PCT)106 can implement TSN functionality in the MAC core that relies on a subsequent fixed-latency path. The MAC core reserves extra space for MACsec expansion as a normal way of using the MACsec engine 102 after the MAC unit 106. It should be noted that the embodiments described herein may support IEEE 802.3br pre-emption, while it would need more signals.

[0037] In at least one embodiment, the MAC unit 106 has been augmented with additional output signaling that provides packet-level information including start-of-packet (pkt tx sop), end-of-packet (pkt tx eop), and packet data (pkt tx data) signals in advance of Mil bus transmission. The MAC unit 106 is further configured to generate supplemental Mil signals comprising start-of-frame (mii tx sof) and end-of-frame (mii tx eof) indicators that explicitly define Layer 2 packet boundaries. These additional signals eliminate the need for downstream components to decode the Mil bus to detect frame boundaries, thereby reducing processing complexity and latency.

[0038] The enhanced signaling capabilities of the MAC unit 106 enable the connected MACsec engine 102 to perform classification and cryptographic preparation operations during the natural timing delays introduced by preamble insertion, creating an opportunity window for parallel security processing. This coordination between the MAC unit 106 and MACsec engine 102 allows the overall system to achieve near-zero security processing latency while maintaining compatibility with standard Ethernet protocols and physical layer components.

[0039] The MACsec engine 102 (also referred to as MACsec unit) is located between the MAC unit 106 and a PCS orPLCA component 108. The MACsec engine 102 represents a Media Access Control Security processing component that provides encryption, authentication, and integrity protection for data frames (e.g., Ethernet data frames). The MACsec engine 102 is strategically positioned in the transmission pipeline to receive Layer 2 packets and apply security transformations according to IEEE 802.1 AE (MACsec) protocol specifications.

[0040] The MACsec engine 102 includes classification logic 114 that analyzes incoming packet headers to determine appropriate security policies, such as whether packets should be encrypted, authenticated with integrity checking only, or allowed to bypass security processing entirely. As described herein, the MAC unit 106 can send early packet signals, including start-of-packet (pkt tx sop), end-of-packet (pkt tx eop), and packet data (pkt tx data) signals. The early packet signals from the MAC unit 106 allow classification and transformation ahead of the Mil data on the Mil bus. TheAttorney Docket No.: 27170.1109 (L1057PCT)classification logic 114 determines an action on the packet based on the early packet signals (i.e., bypass, drop through different methods like zeroization, add header and encrypt). The MACsec transform logic 116 determines which bytes on the Mil bus should be modified and how they should be modified. It should be noted that the implementation and the target throughput of the port (e.g., 10M, 100M, 1G, etc.) determines how far ahead the data shall be provided to the classification logic 114 and MACsec transform logic 116.

[0041] The MACsec engine 102 incorporates MACsec transform logic 116 that performs the actual cryptographic operations including AES-GCM encryption, security tag generation, and Integrity Check Value (ICV) calculation. In at least one embodiment, the MACsec transform logic 116 uses AES-GCM cipher. In other embodiments, the MACsec transform logic 116 can use other types of streaming ciphers if the throughput matches a line rate of the port. In at least one embodiment, the MACsec engine 102 includes a Mil encoder. The Mil encoder can apply modifications to the stream according to the MACsec action (drop, bypass, encrypt) determined by the classification logic 114. The Mil encoder can be implemented in various ways, but depending on the implementation can have zero latency. In at least one embodiment, the Mil encoder can perform an output FCS recalculation when necessary. The output FCS recalculation must be done for the packets which are modified. This is done on-the-fly and does not need extra latency. The output FCS recalculation is not required for packets that are classified to be bypassed. The output FCS can be intentionally corrupted for dropped packets as an indicator to the target device.

[0042] The MACsec engine 102 is configured to receive early signaling information 120 that enables just-in-time security processing without the latency penalties associated with conventional MACsec implementations. This optimized approach allows the MACsec engine 102 to complete classification and cryptographic preparation operations in parallel with packet transmission timing, achieving near-zero processing latency.

[0043] The MACsec engine 102 supports various operational modes including confidentiality and integrity protection, integrity-only protection, and transparent bypass mode. The MACsec engine 102 maintains constant latency behavior regardless of the selected security mode, ensuring predictable timing characteristics suitable for automotive Ethernet applications requiring half -duplex operation and collision detection functionality.Attorney Docket No.: 27170.1109 (L1057PCT)

[0044] As described above, the PCS or PLCA component 108 handles physical coding sublayer operations or physical-level collision avoidance functions for network transmission. The PCS or PLCA component 108 represents the physical layer processing unit that handles the final stage of packet transmission before data is transmitted on the network medium. This component may be implemented as either a PCS component or a PLCA component depending on the type and bitrate of the physical medium supported by a port. In the half-duplex case, the PCS or PLCA component 108 can send collision management signals back to the MAC unit 106, such as illustrated in FIG. 2. Using the embodiments described herein that have near zero egress latency the half-duplex operation used in PCS or PLCA component 108 can be supported because the presence of the MACsec engine 102 in the egress path is basically transparent.

[0045] When implemented as a PCS component, the unit performs physical coding sublayer functions according to IEEE 802.3 Ethernet standards. The PCS component handles encoding of data frames received from the MACsec engine into appropriate physical layer formats, such as 4B / 5B encoding for lOOBase-TX implementations or 8B / 10B encoding for Gigabit Ethernet variants. The PCS component manages line coding, scrambling, and physical medium attachment functions to ensure reliable data transmission over copper or fiber optic links. The PCS implementation supports full-duplex operation and includes clock recovery, symbol alignment, and error detection capabilities for maintaining signal integrity.

[0046] When implemented as a PLCA component, the unit provides Physical-Level Collision Avoidance functionality specifically designed for automotive Ethernet applications such as lOBase-TlS according to IEEE 802.3 Ethernet standards. The PLCA component implements deterministic medium access control that eliminates collisions in multi-drop network configurations by coordinating transmission opportunities among multiple network nodes. The PLCA component manages transmission scheduling, beacon generation, and collision avoidance protocols that enable reliable half-duplex communication over single twisted-pair automotive wiring. This implementation is particularly suited for cost-sensitive automotive applications where reduced wiring complexity and deterministic timing behavior are essential requirements.

[0047] Both implementations of the PCS or PLCA component 108 receive processed packets from the MACsec engine 102 and provide the final physical layer processing before network transmission, while maintaining compatibility with the optimized timing characteristics of the upstream security processing pipeline.Attorney Docket No.: 27170.1109 (L1057PCT)

[0048] In at least one embodiment, the MACsec engine 102 includes an input Mil port 110 configured to receive an L2 packet from the MAC unit 106. The MACsec engine 102 can receive Mil signals 124 on the first input Mil port 110. The Mil signals 124 can include the supplemental Mil signals described herein. The MACsec engine 102 further includes an output Mil port 112 configured to couple to the PCS or PLCA component 108 for outputting processed data frames. The MACsec engine 102 also includes an input port 122 configured to receive the additional packet signaling from the MAC unit 106, such as the early packet signals, including start-of-packet (pkt tx sop), end-of-packet (pkt tx eop), and packet data (pkt tx data) signals. As described above, the input Mil port 110 receives the supplemental Mil bus signals, including the start-of-frame(mii tx sof) and end-of-frame (mii tx eof) signals that precisely indicate when Layer 2 packet data begins and ends on the Mil bus, eliminating any ambiguity about frame boundaries.

[0049] The MACsec engine 102 is configured to receive the early signaling information 120 from the MAC unit 106 via the input port 122. The early signaling information 120 can include first information, such as a start-of-packet indication (SOP indication), packet data, and an end-of-packet indication (EOP indication), from the MAC unit 106 before receiving the payload data of the L2 packet. The MACsec engine 102 is configured to receive second information indicating a start and end of the L2 packet. Within the MACsec engine 102, classification logic 114 is configured to receive the first information (e.g., SOP indication) from the MAC unit 106 and perform a classification operation using the first information before the first Mil port 110 receives payload data of the L2 packet. In at least one embodiment, the L2 packet includes classification scope data and the payload data, enabling the classification logic 114 to perform the classification operation using the classification scope data prior to receiving the payload data.

[0050] The MACsec engine 102 also incorporates MACsec transform logic 116 configured to perform a MACsec transform operation on the L2 packet after the classification operation. The MACsec transform operation comprises encrypting the payload data to obtain encrypted payload data and inserting the encrypted payload data into the L2 packet. The MACsec transform operation further comprises generating a MACsec security tag using the classification scope data and inserting the MACsec security tag into a header of the L2 packet before the encrypted payload data, andAttorney Docket No.: 27170.1109 (L1057PCT)generating an Integrity Check Value (ICV) and appending the ICV to the L2 packet after the encrypted payload data.

[0051] An Mil encoder 118 is configured to receive the second information and the L2 packet from the MAC unit 106 via the input Mil port 110 and encode the L2 packet for transmission to the PCS or PLCA component 108 via the output Mil port 112. The second information indicates the start and end of the L2 packet, comprising a start-of-frame indication (SOF indication) and an end-of-frame indication (EOF indication). The first information comprises a start-of-packet indication, packet data, and an end-of-packet indication provided before the payload data appears on the media independent interface bus.

[0052] The MACsec engine 102 eliminates the need for a conventional Mil decoder through its enhanced interface with the upstream MAC unit. Traditional MACsec implementations require Mil decoders to monitor the Mil bus and identify frame boundaries by detecting specific bit patterns, preamble sequences, and frame check sequences within the continuous data stream. This decoding process typically requires pattern matching logic to distinguish between actual frame delimiters and similar bit patterns that may appear within packet payload data. It should be noted that detecting the SOF indication from the Mil bus conventionally required decoding a preamble / SFD (Start of Frame Delimiter). This is just a natural consequence of how the Mil bus is formed. This decoding can be done on-the-fly so there is no latency impact, but it requires decoding logic (i.e., an Mil decoder) to do it. Receiving the SOF indication (e.g., MII TX SOF) as one of the enhanced signals from the MAC unit 106, as described herein, permits the MACsec engine 102 to avoid having decoding logic (i.e., an Mil decoder) to decode the SOF indication. Also, detecting the EOF indication from the Mil bus conventionally required multiple clock cycles as indicated above. This is just a natural consequence of how the Mil bus is formed, but requires a Mil decoder to see the end of FCS to determine the last payload byte. Receiving the EOF indication (e.g., MII TX EOF) as one of the enhanced signals from the MAC unit 106, as described herein, permits the MACsec engine 102 to avoid having decoding logic (i.e., an Mil decoder) and the latency to decode it. It should be noted that an input FCS check is one of the methods to verify data integrity of an incoming packet. In other embodiments other methods can be used, such as a parity check, which may need an extra parity input from the MAC unit 106 (e.g., MAC reconciliation layer or RS layer).Attorney Docket No.: 27170.1109 (L1057PCT)

[0053] The MACsec engine 102 avoids this decoding overhead by receiving explicit frame boundary information directly from the MAC unit through dedicated signaling (also referred to herein as supplemental Mil signals). The MAC unit provides start-of-frame (mii tx sof) and end-of-frame (mii tx eof) signals that precisely indicate when Layer 2 packet data begins and ends on the Mil bus, eliminating any ambiguity about frame boundaries. Additionally, the MACsec engine 102 receives early packet signaling comprising start-of-packet, end-of-packet, and packet data information before the data appears on the Mil bus.

[0054] This direct signaling approach allows the MACsec engine 102 to immediately identify packet boundaries without the time-consuming process of analyzing the Mil data stream for delimiter patterns. The elimination of Mil decoding logic reduces silicon area requirements, removes processing latency associated with pattern detection, and enables the MACsec engine 102 to begin security operations with precise timing coordination. This optimization is particularly beneficial for half-duplex automotive applications where processing delays can interfere with collision detection and carrier sense mechanisms that require predictable, minimal latency through the transmission pipeline.

[0055] In at least one embodiment, the MACsec engine 102 further includes checking logic (not separately numbered) configured to check an FCS of a frame comprising a preamble, the L2 packet, and the FCS. In at least one embodiment, the Mil encoder 118 is configured to recalculate the FCS for transmission of the frame to the PCS or PLCA component 108. The checking logic, while not specifically illustrated as a separate component in FIG. 1, represents frame validation functionality that is integrated within the MACsec engine 102 to verify frame integrity and recalculate FCS after security processing operations. This checking logic operates in coordination with the Mil encoder 118 to ensure that processed packets maintain proper Ethernet frame formatting and checksums before transmission to the PCS or PLCA component 108. The checking logic benefits from the explicit frame boundary information provided by the MAC unit 106, eliminating the need to detect FCS locations through conventional Mil bus monitoring techniques. By receiving precise start-of-frame and end-of-frame indicators through the second information signaling, the checking logic can immediately identify where frame check sequences are located within the data stream and perform validation or recalculation operations with optimal timing efficiency. This integration enables the MACsec engine 102 to maintain frame integrity while preserving the overall low-latency characteristics of the optimized security processing architecture, as will be described inAttorney Docket No.: 27170.1109 (L1057PCT)more detail with respect to FIG. 2. In this embodiment, FCS check is used to verify data integrity of the packet. In other embodiments, other checks, such as a parity check, could be done to verify data integrity.

[0056] The network interface 100 may be implemented as part of an Automotive Ethernet device, enabling optimized security processing with minimal latency for automotive and industrial network applications. The network interface 100 can be part of an Automotive Ethernet Node (e.g., an endpoint, a gateway, a physical layer (PHY) device, a switch, Ethernet ECU (Electronic control unit), or the like.

[0057] In alternative embodiments, the network interface 100 may be implemented with different Mil interface configurations to support various data rates and bus widths. For example, the input Mil port 110 and output Mil port 112 may operate with 4-bit data paths for 10 Mbps implementations, 8-bit data paths for 100 Mbps implementations, or wider data paths such as 16-bit or 32-bit configurations for higher throughput applications. The Mil encoder 118 may include additional control signals for data alignment and byte counting when wider data buses are employed.

[0058] In some embodiments, the MAC unit 106 may be configured to operate without providing the enhanced early signaling, allowing the MACsec engine 102 to function in a backward compatibility mode. In such configurations, the classification logic 114 may revert to conventional Mil bus decoding operations while still maintaining the integrated positioning between the MAC unit 106 and PCS or PLCA component 108.

[0059] Alternative embodiments may implement the PCS or PLCA component 108 as different physical layer components depending on the specific network application. For automotive Ethernet applications, the PCS or PLCA component 108 may comprise a lOBase-TlS physical layer with collision avoidance capabilities. For industrial applications, the PCS or PLCA component 108 may comprise a standard lOOBase-TX or lOOOBase-T physical coding sublayer.

[0060] In certain embodiments, the classification logic 114 may be implemented with configurable classification rules stored in memory or programmable logic. The classification logic 114 may support multiple security policies simultaneously, enabling different treatment for various packet types or traffic classes.

[0061] Alternative configurations of the MACsec transform logic 116 may support different encryption algorithms beyond the standard AES-GCM, including Ascon or other authenticated encryption modes. In some embodiments, the MACsec transform logic 116 may include dedicated hardware for key management and cryptographic keyAttorney Docket No.: 27170.1109 (L1057PCT)derivation functions. The MACsec transform logic 116 may also support multiple concurrent security associations for handling different traffic flows.

[0062] In some embodiments, the TX packet buffer 104 may be implemented as a multi-level buffer system with separate queues for different priority levels or traffic classes. The TX packet buffer 104 may include flow control mechanisms to coordinate with the MAC unit 106 and prevent buffer overflow conditions. Alternative implementations may integrate the TX packet buffer 104 directly within the MAC unit 106 or distribute buffering across multiple components.

[0063] Certain embodiments may implement the MACsec engine 102 as a half-duplex optimized solution. In such configurations, the MACsec engine 102 may include bidirectional classification logic 114 and MACsec transform logic 116 to handle both transmission and reception security operations.

[0064] Alternative embodiments may include diagnostic and monitoring capabilities within the MACsec engine 102, such as performance counters, error detection logic, and debug interfaces. Some implementations may provide software-configurable parameters for adjusting latency optimization settings or enabling different operational modes based on network conditions.

[0065] In certain configurations, the network interface 100 may be implemented as part of a larger system-on-chip (SoC) design, with the various components 102, 104, 106, and 108 integrated on a single semiconductor device. Alternative implementations may distribute these components across multiple integrated circuits with standardized interfaces for modular system design.

[0066] FIG. 2 is a block diagram of a transmitting path of a network interface 200 configured for optimized data protection with enhanced MAC signaling capabilities according to at least one embodiment. The network interface 200 includes the TX packet buffer 104, the MAC unit 106, the MACsec engine 102, and the PCS or PLCA component 108. The network interface 200 is similar to the network interface 100 as noted by similar reference numbers, except the MAC unit 106 specifically includes a MAC core 202 and a MAC reconciliation layer 204, and the MACsec engine 102 includes classification logic 114, MACsec transform logic 116, Mil encoder 118, and checking logic 206 as described in detail below. The PCS or PLCA component 108 can provide collision management signals to the MAC unit 106.

[0067] The network interface 200 includes the TX packet buffer 104 (or DMA component) that receives and stores L2 packets for transmission processing. The TXAttorney Docket No.: 27170.1109 (L1057PCT)packet buffer 104 is operatively connected to the MAC unit 106, which has been updated to output additional output signals 208 for enabling early packet processing (also referred to as early signaling information 120 or first packet signaling information). The new signals can include start-of-packet (pkt tx sop), end-of-packet (pkt tx eop), and packet data (pkt tx data) signals. These signals can be sent as additional output signals 208 before the L2 packets are transmitted on a media independent interface (Mil) bus. As noted above, the MAC unit 106 includes the MAC core 202 and the MAC reconciliation layer 204. The MAC core 202 represents the central processing unit within the MAC unit 106 that handles the fundamental media access control operations for Ethernet frame processing. The MAC core 202 is configured to receive Layer 2 packets from the TX packet buffer 104 and perform essential MAC layer functions including frame encapsulation, address filtering, and protocol processing.

[0068] In the disclosed embodiment, the MAC core 202 has been enhanced to generate early signaling information that enables optimized MACsec processing. The MAC core 202 is configured to extract packet header information during the initial stages of frame processing, before the data is formatted for transmission on the Mil bus. This early extraction capability allows the MAC core 202 to provide packet data signals, start-of-packet indications, and end-of-packet indications to the MACsec engine 102 in advance of the actual payload data transmission.

[0069] The MAC core 202 operates in coordination with the MAC reconciliation layer 204 to manage the timing of packet transmission. While the MAC reconciliation layer 204 handles the physical interface timing and preamble insertion, the MAC core 202 focuses on the logical aspects of frame processing including header analysis, frame validation, and protocol-specific operations. The MAC core 202 may include dedicated logic for parsing Ethernet headers, extracting destination and source MAC addresses, and identifying frame types or VLAN tags.

[0070] In some embodiments, the MAC core 202 may incorporate buffer management functionality to coordinate with the TX packet buffer 104 and ensure proper data flow timing. The MAC core 202 may include flow control mechanisms to prevent data underrun or overflow conditions during packet processing. The MAC core 202 may also implement priority queuing capabilities to support Quality of Service (QoS) requirements in automotive or industrial networking applications.

[0071] The MAC core 202 may be implemented with configurable parameters to support different Ethernet variants and data rates. For 10 Mbps implementations, theAttorney Docket No.: 27170.1109 (L1057PCT)MAC core 202 may operate with reduced clock frequencies and simplified processing pipelines. For higher-speed implementations such as 100 Mbps or 1 Gbps, the MAC core 202 may include parallel processing capabilities and wider internal data paths to maintain throughput requirements.

[0072] In alternative embodiments, the MAC core 202 may include additional functionality such as statistics collection, error detection and correction, and diagnostic capabilities. The MAC core 202 may provide software-accessible registers for configuration and monitoring purposes, enabling system-level control of MAC operations and integration with network management protocols.

[0073] The MAC reconciliation layer 204 represents a key functional component within the MAC unit 106 that manages the interface between the MAC core processing logic and the physical layer transmission medium. The MAC reconciliation layer 204 is responsible for adding preambles to outgoing data frames, managing inter-frame gap timing, and coordinating the physical interface protocols required for proper Ethernet transmission.

[0074] The MAC reconciliation layer 204 performs the critical function of preamble insertion, adding the standard 8-byte preamble sequence (7 bytes of alternating 1010... pattern followed by a start-of-frame delimiter) to each transmitted frame. This preamble insertion process creates a natural timing delay that the disclosed system leverages for parallel security processing operations. For example, in a 10 Mbit Mil implementation with 4 bits per clock, the 8-byte preamble provides approximately 16 clock cycles of processing time that can be utilized by the downstream MACsec engine for classification and cryptographic preparation.

[0075] In the enhanced implementation shown, the MAC reconciliation layer 204 has been updated to generate additional signaling information (also referred to herein as second packet signaling information) that supports optimized MACsec processing. The MAC reconciliation layer 204 is configured to output supplemental Mil signals 210 including start-of-frame (mii tx sof) and end-of-frame (mii tx eof) indicators that explicitly define packet boundaries on the Mil bus. These supplemental Mil signals 210 eliminate the need for downstream components to decode the Mil bus to detect frame boundaries, thereby reducing processing complexity and latency.

[0076] The MAC reconciliation layer 204 also manages inter-packet gap timing to ensure proper spacing between consecutive frames according to Ethernet protocol requirements. The MAC reconciliation layer 204 coordinates with the MAC core 202 toAttorney Docket No.: 27170.1109 (L1057PCT)ensure that frame transmission timing meets the specifications for the particular Ethernet variant being implemented, whether 10 Mbps, 100 Mbps, or higher-speed implementations. When used with MACsec engine 102, the inter-packet gap is enlarged to include space for adding a MACsec header and trailer in the MACsec engine 102. This timing coordination is essential for maintaining network compatibility while enabling the enhanced signaling capabilities that support low-latency security processing.

[0077] While the MAC reconciliation layer 204 is configured to output supplemental Mil signals 210 including start-of-frame (mii tx sof) and end-of-frame (mii tx eof) indicators that explicitly define packet boundaries, the MAC core 202 is configured to provide early packet signaling as the additional output signals 208 (e.g., pkt tx sop, pkt tx eop), and packet data (pkt tx data) signals before the L2 packets are transmitted on a media independent interface (Mil) bus.

[0078] In at least one embodiment, the MAC unit 106 is coupled to a MACsec engine 102 that is strategically positioned between the MAC unit 106 and a PCS or PLCA component 108. The MACsec engine 102 is configured to receive first information (e.g., additional output signals 208) from the MAC unit 106 before payload data of the L2 packet arrives, and to receive second information (e.g., supplemental Mil signals 210) indicating a start and end of the L2 packet data.

[0079] In at least one embodiment, the MACsec engine 102 includes a input Mil port configured to receive the L2 packet from the MAC unit 106. Within the MACsec engine 102, classification logic 114 is configured to receive the first information from the MAC core 202 and perform a classification operation using the first information before the input Mil port receives payload data of the L2 packet from the MAC reconciliation layer 204. The early availability of packet information enables the classification logic 114 to analyze packet headers and determine appropriate security policies in parallel with data transmission on the Mil bus.

[0080] The MACsec engine 102 incorporates MACsec transform logic 116 configured to perform a MACsec transform operation on the L2 packet based on the classification results. The MACsec transform operation comprises encrypting the payload data to obtain encrypted payload data, generating a MACsec security tag using classification scope data, inserting the security tag into a header of the L2 packet, and generating an ICV to append to the L2 packet.

[0081] As illustrated in FIG. 2, the MACsec engine 102 further includes checking logic 206 configured to check a frame checksum (FCS) of a frame comprising a preamble, theAttorney Docket No.: 27170.1109 (L1057PCT)L2 packet, and the FCS. The checking logic 206 receives frame boundary information from the supplemental Mil signals 210 (i.e., second information) provided by the MAC reconciliation layer 204, eliminating the need to decode the Mil bus to detect the FCS location.

[0082] An Mil encoder 118 is configured to receive the second information and the L2 packet from the MAC reconciliation layer 204 via the input Mil port and encode the L2 packet for transmission to the PCS or PLCA component 108 via an output Mil port. The Mil encoder 118 is further configured to recalculate the FCS for transmission of the frame to the PCS or PLCA component 108 via the output Mil port.

[0083] The architecture shown in FIG. 2 demonstrates how the MAC unit 106 provides early packet signals and explicit frame boundary indicators to the MACsec engine 102, enabling the classification logic 114 and MACsec transform logic 116 to perform security operations with minimal latency. The natural timing delay introduced by the MAC reconciliation layer 204 during preamble insertion creates an opportunity window for the MACsec engine 102 to complete classification and cryptographic preparation before the actual packet data requires modification, thereby achieving near-zero processing latency.

[0084] As described above, the MACsec engine 102 eliminates the need for a conventional Mil decoder through its enhanced interface with the upstream MAC unit. Traditional MACsec implementations require Mil decoders to monitor the Mil bus and identify frame boundaries by detecting specific bit patterns, preamble sequences, and frame check sequences within the continuous data stream. This decoding process typically consumes 8 or more clock cycles and requires pattern matching logic to distinguish between actual frame delimiters and similar bit patterns that may appear within packet payload data.

[0085] In alternative embodiments, the network interface 200 may be implemented with different configurations of the MAC reconciliation layer 204 to support various Ethernet standards and timing requirements. For example, the MAC reconciliation layer 204 may be configured for Gigabit Media Independent Interface (GMII) operation with 8-bit data paths and higher clock frequencies, or for 10-Gigabit implementations requiring wider data buses and more complex timing coordination. The MAC reconciliation layer 204 may include configurable preamble lengths or custom frame formatting for specialized automotive or industrial protocols.Attorney Docket No.: 27170.1109 (L1057PCT)

[0086] Alternative implementations of the checking logic 206 may include enhanced frame validation capabilities beyond basic FCS verification. In some embodiments, the checking logic 206 may perform comprehensive frame integrity checks including header field validation, length verification, and protocol-specific error detection. The checking logic 206 may also support multiple checksum algorithms or custom integrity verification methods required for specific automotive or industrial networking standards.

[0087] In certain embodiments, the MAC unit 106 may be configured to provide additional early signaling information beyond the basic start-of-packet, end-of-packet, and packet data signals. Alternative signaling may include VLAN tag indicators, priority level information, timestamp data for Time-Sensitive Networking (TSN) applications, or custom header fields specific to automotive protocols. The MAC unit 106 may also support multiple concurrent packet streams with separate signaling channels for each stream.

[0088] Alternative configurations of the MACsec engine 102 may implement distributed processing architectures where the classification logic 114 and MACsec transform logic 116 operate on separate clock domains or processing cores. In some embodiments, the classification logic 114 may include machine learning capabilities for adaptive security policy determination, or the MACsec transform logic 116 may support multiple encryption algorithms simultaneously for different traffic classes.

[0089] The network interface 200 may be implemented with alternative buffer architectures where the TX packet buffer 104 includes multiple priority queues, separate buffers for different security domains, or distributed buffering across multiple components. Some embodiments may integrate the buffer functionality directly within the MAC unit 106 or implement shared buffer pools accessible by multiple network interfaces.

[0090] In certain embodiments, the PCS or PLCA component 108 may include additional functionality such as forward error correction (FEC), adaptive equalization for challenging channel conditions, or multi-rate support for dynamic speed negotiation. Alternative implementations may support multiple physical interfaces simultaneously, enabling redundant transmission paths or load balancing across multiple network links.

[0091] Some embodiments may implement the network interface 200 with additional diagnostic and monitoring capabilities, including performance counters, error logging, security event detection, and real-time network analysis functions. The network interfaceAttorney Docket No.: 27170.1109 (L1057PCT)100 may include software-configurable parameters for adjusting processing priorities, enabling different operational modes, or adapting to varying network conditions.

[0092] Alternative embodiments may integrate the network interface 200 components within different system architectures, such as system-on-chip (SoC) implementations, multi-chip modules, or distributed processing systems with standardized interconnects between functional blocks.

[0093] In an alternative embodiment, the MACsec engine 102 may be implemented with a distributed information delivery architecture that provides enhanced coordination between the MAC and the MACsec processing components. In this configuration, the first information is delivered to the MACsec engine 102 through a dedicated high-speed interface that operates independently of the standard Mil bus timing. The first information may include comprehensive packet metadata such as complete header fields, classification hints, security policy indicators, and cryptographic parameters that enable the MACsec engine 102 to perform advanced preparation operations well in advance of the actual L2 packet data arrival.

[0094] The delivery of first information may occur through a parallel processing channel that operates at a higher clock frequency than the Mil bus, enabling the MACsec engine 102 to receive and process packet information during multiple clock cycles before the corresponding data appears on the standard interface. This extended advance notice allows the classification logic to perform complex policy lookups, key derivation operations, and cryptographic initialization procedures that would otherwise contribute to processing latency.

[0095] In this embodiment, the second information delivery mechanism provides duallayer frame boundary detection through both explicit signaling and implicit timing coordination. The second information indicating the start and end of the L2 packet data may include precise byte-level positioning information, frame length indicators, and padding detection signals that enable the MACsec engine 102 to optimize memory allocation and processing resource utilization. The redundant delivery of second information through multiple signaling paths provides enhanced reliability and enables error detection in the frame boundary detection process.

[0096] The MACsec engine 102 in this alternative embodiment may include buffer management logic that coordinates the timing between the first information delivery and the second information delivery to ensure optimal resource utilization. The MACsec engine 102 may pre-allocate processing resources, initialize cryptographic engines, andAttorney Docket No.: 27170.1109 (L1057PCT)prepare output buffers based on the first information, then utilize the second information to coordinate the precise timing of data processing operations.

[0097] This alternative architecture enables the MACsec engine 102 to achieve even lower latency than the basic embodiment by extending the advance processing window and providing more comprehensive packet information for optimization decisions. The dual information delivery approach also provides enhanced flexibility for supporting different MAC implementations and varying network timing requirements while maintaining the core benefits of reduced silicon area and constant latency operation.

[0098] In an alternative embodiment, the MACsec engine 102 operates with a two-phase processing approach that separates classification and transform preparation from the actual payload transformation operations. The L2 packet is structured to include classification scope data, which comprises packet headers, addressing information, protocol identifiers, and security policy indicators, along with the payload data that contains the actual information content requiring protection.

[0099] The MACsec engine 102 utilizes the early delivery of first information to access the classification scope data and perform comprehensive classification and transform preparation operations before the payload data becomes available for processing. During this preparation phase, the classification logic analyzes the packet headers to determine security policies, selects appropriate cryptographic algorithms, derives necessary encryption keys, and initializes security parameters. The transform logic simultaneously prepares cryptographic engines, allocates processing resources, and configures security tag generation parameters based on the classification results.

[0100] This separation of classification scope processing from payload processing enables the MACsec engine 102 to complete all preparatory operations during the natural timing delays inherent in the MAC reconciliation layer's preamble insertion process. When the payload data subsequently arrives at the MACsec engine 102, the transform operation can proceed immediately with pre-configured parameters and initialized cryptographic engines, eliminating the sequential processing delays associated with conventional MACsec implementations.

[0101] The two-phase approach ensures that the actual MACsec transform operation on the payload data occurs with minimal latency, as all classification decisions and cryptographic preparations have been completed in advance. This optimization is particularly beneficial for applications requiring predictable timing behavior, such asAttorney Docket No.: 27170.1109 (L1057PCT)automotive Ethernet systems where processing delays can interfere with collision detection and real-time communication requirements.

[0102] In an alternative system embodiment, the network interface is implemented as an integrated system comprising an Ethernet Media Access Controller (MAC) that is directly coupled to a physical coding sublayer (PCS) through a standard media independent interface (Mil), with a MACsec engine strategically disposed between these components to provide transparent security processing. This system architecture enables the MACsec engine to intercept and process packets without disrupting the standard MAC-to-PCS communication protocols.

[0103] The Ethernet MAC in this embodiment is enhanced to generate early packet signaling that provides advance notification to the MACsec engine before packet transmission occurs on the Mil bus. This early signaling includes start-of-packet indications that alert the MACsec engine when a new frame is beginning processing, end-of-packet indications that signal frame completion, and packet data that provides header information and classification scope data in advance of the actual payload transmission. The early delivery of this information enables the MACsec engine to perform classification operations and security processing preparation during the natural timing delays inherent in MAC processing.

[0104] The system further incorporates supplemental Mil signaling where the Ethernet MAC provides explicit frame boundary indicators including start-of-frame (mii tx sof) and end-of-frame (mii tx eof) signals. These supplemental signals precisely identify the beginning and end of layer-2 packet data, including any Ethernet padding that may be present to meet minimum frame length requirements. The availability of explicit frame boundary information eliminates the need for the MACsec engine to perform Mil bus decoding operations to detect frame check sequence (FCS) boundaries.

[0105] The MACsec engine in this system configuration achieves ultra-low latency processing by utilizing the early packet signaling and supplemental Mil signals to complete security header insertion and packet data encryption with a processing latency of no more than one clock cycle. This performance is achieved through the parallel execution of classification and cryptographic preparation operations during MAC processing delays, enabling the security transformation to occur immediately when the packet data becomes available for modification. The system maintains full compatibility with standard Ethernet protocols while providing enhanced security processingAttorney Docket No.: 27170.1109 (L1057PCT)capabilities suitable for automotive and industrial applications requiring deterministic timing behavior.

[0106] FIG. 3 illustrates a bus timing diagram 300 that demonstrates the temporal relationships and signaling coordination between the components shown in FIG. 2, particularly highlighting how the enhanced MAC signaling enables optimized MACsec processing with reduced latency, according to at least one embodiment. The bus timing diagram 300 includes an initial time reference (TO or first time) and a subsequent time reference (T1 or second time) that establish temporal reference points for comparing conventional and optimized processing approaches.

[0107] The bus timing diagram 300 begins at TO with a first stage 302 (labeled 1) that represents the L2 packet transmission from the TX packet buffer 104 to the MAC unit 106. The first stage 302 establishes the baseline timing for packet processing within the network interface 200. This first stage 302 shows the original packet structure including header fields and a payload field. The header fields include a MAC destination address field, a MAC source address field, and other specific fields, such as a VLAN field, and a type field (labeled ET), which represent specific header components within Ethernet frame structures. The VLAN field represents VLAN tagging information as defined by the IEEE 802. IQ standard. This field contains a 4-byte VLAN tag that includes a Tag Protocol Identifier (TPID), a Priority Code Point (PCP) for traffic prioritization, a Drop Eligible Indicator (DEI) for congestion management, and a 12-bit VLAN Identifier (VID) that specifies which virtual network the frame belongs to. VLAN tagging enables network segmentation and traffic isolation within a single physical network infrastructure, which is particularly important in automotive and industrial applications where different types of traffic may require separation for security or performance reasons. The ET field represents the EtherType field within the Ethernet frame header, which is a 2-byte field that indicates the protocol type of the payload data contained within the frame. Common EtherType values include 0x0800 for IPv4, 0x86DD for IPv6, 0x0806 for ARP, and 0x88E5 for MACsec-protected frames. In the context of MACsec processing, the EtherType field is particularly significant because it may be modified during security transformation operations when security tags are inserted, and the classification logic 114 uses this field to determine appropriate security policies for different protocol types. Both fields are part of the classification scope that the classification logic 114 analyzes when determining security policies, and they may beAttorney Docket No.: 27170.1109 (L1057PCT)modified or preserved during MACsec transform operations depending on the specific security requirements and frame processing modes.

[0108] The second stage 304 (labeled 2) depicts the Mil bus transmission as processed by the MAC reconciliation layer 204 within the MAC unit 106, beginning at a second time (Tl). This second stage 304 shows how the MAC reconciliation layer 204 formats the packet for transmission on the Mil bus, including a header field (preamble / SFD), a MAC destination address field, a MAC source address field, a VLAN field, and an ET field, before the L2 payload field. After the L2 payload, the MAC reconciliation layer 204 inserts padding fields (labeled PAD) and a frame check sequence field (labeled FCS).

[0109] The preamble / SFD (Start of Frame Delimiter) in the second stage 304 represents the synchronization and frame delineation sequence that is inserted by the MAC reconciliation layer 204 during the transition from MAC processing to Mil bus transmission. This 8-byte sequence consists of 7 bytes of alternating bit pattern (10101010) followed by a 1-byte Start of Frame Delimiter (10101011) that signals the beginning of the actual Ethernet frame data. The MAC reconciliation layer 204 inserts the preamble / SFD sequence to serve several critical functions in Ethernet communication. First, the alternating bit pattern of the preamble allows receiving devices to synchronize their clock recovery circuits and establish proper timing alignment with the incoming data stream. This synchronization is essential for reliable data reception, particularly in systems where transmitter and receiver clocks may have slight frequency differences or phase variations. Second, the Start of Frame Delimiter provides an unambiguous marker that indicates the precise boundary between the synchronization preamble and the actual frame content. This delimiter enables receiving devices to identify exactly when the destination MAC address and subsequent frame data begins, ensuring proper frame parsing and processing. At the end of the preamble / SFD, the MAC reconciliation layer 204 can output the supplemental Mil signals 210, including the SOF signal to the MACsec engine 102 at a fifth stage 310. At the end of the padding field, the MAC reconciliation layer 204 can output the supplemental Mil signals 210, including the EOF signal at a sixth stage 312.

[0110] It should be noted that the preamble insertion process creates a natural timing delay that the system leverages for optimized MACsec processing. During the time required for the MAC reconciliation layer 204 to transmit the 8-byte preamble / SFD sequence on the Mil bus, the MACsec engine 102 utilizes this delay period to performAttorney Docket No.: 27170.1109 (L1057PCT)classification operations and cryptographic preparation in parallel. For example, in a 10 Mbit Mil implementation with 4 bits per clock, the preamble transmission requires 16 clock cycles, providing sufficient time for the classification logic 114 to analyze packet headers and for the MACsec transform logic 116 to prepare security parameters before the actual packet pay load data arrives and requires modification.[OHl] This timing coordination eliminates the need for the MACsec engine 102 to buffer packet data or implement additional pipeline stages, enabling the near-zero latency processing that is essential for half-duplex automotive Ethernet applications where timing delays can interfere with collision detection mechanisms.

[0112] The third stage 306 (labeled 2b) represents the Mil-optimized MACsec processing performed by the MACsec engine 102, specifically showing how the classification logic 114 and MACsec transform logic 116 operate with the enhanced signaling from the MAC unit 106. This third stage 306 demonstrates the reduced processing latency achieved through the elimination of Mil bus decoding requirements, as the MACsec engine 102 receives explicit frame boundary information rather than having to detect boundaries through pattern matching. That is, at Tl, the classification logic 114 receives a SOP signal 318 from the MAC core 202. The classification logic 114 subsequently receives the packet data (pkt tx data) and then an EOP signal 320 at the end of the L2 payload field. As illustrated in FIG. 3 at the second stage 304 and third stage 306, the classification logic 114 receives classification scope data of the L2 packet before the classification scope data is provided by the MAC reconciliation layer 204 on the Mil bus. This allows classification and transform preparation to be ready in time to be applied at a security header offset of the packet, as illustrated in the fourth stage 308.

[0113] The fourth stage 308 (labeled 3.3) illustrates the output transmission by the MACsec engine 102 to the PCS or PLCA component 108 via the xMII interface, showing how the processed packets maintain proper timing relationships for downstream physical layer processing. This fourth stage 308 demonstrates that the optimized MACsec processing maintains compatibility with standard physical layer components while achieving significant latency improvements. The packet begins with the preamble / SFD sequence that maintains the standard 8-byte synchronization pattern required for proper physical layer reception. The MAC DA (destination address) and MAC SA (source address) fields retain their original 6-byte values as these addresses are not encrypted during MACsec processing, allowing network switching and routing functions to operate normally on the protected frames. The MACsec transform logic 116Attorney Docket No.: 27170.1109 (L1057PCT)can generate a security tag for a security flag field (labeled SecTag) to represent a newly inserted 8-byte or 16-byte header that contains MACsec-specific information including the Security Channel Identifier (SCI), Packet Number (PN), and security policy indicators. This tag is generated by the MACsec transform logic 116 based on the classification results and enables receiving devices to identify the security association and parameters required for decryption and authentication verification. The L2 Payload field contains the original Layer 2 payload data that has been encrypted by the MACsec transform logic 116 using AES-GCM or other configured encryption algorithms. The PAD (padding) field may be present to ensure proper frame length alignment as required by Ethernet standards, particularly when the original payload length does not meet minimum frame size requirements. The MACsec transform logic 116 can generate an ICV value for the ICV field (labeled ICV) to represent an authentication tag generated during the MACsec transformation process, typically 8 or 16 bytes in length depending on the cipher used. This field enables receiving devices to verify both the authenticity and integrity of the transmitted data. Finally, the FCS (Frame Check Sequence) field contains the recalculated 4-byte CRC-32 checksum that covers the entire modified frame structure, as computed by the Mil encoder 118 to ensure proper Ethernet frame validation at the receiving end. The new FCS can be calculated during the Mil encoding by Mil encoder 118 for the packets that are modified. For the packets that are not modified, the original FCS can be used.

[0114] As described above, the fifth stage 310 (labeled 2a - new mii_sof signal) specifically highlights the start-of-frame signaling generated by the MAC reconciliation layer 204 and provided to the MACsec engine 102. This new signaling includes the SOF signal 314 that explicitly indicates when Layer 2 packet data begins, eliminating the need for the MACsec engine 102 to decode the Mil bus to detect frame boundaries. The timing shows how this signal enables the classification logic 114 to begin processing operations with precise timing coordination.

[0115] As described above, the sixth stage 312 (labeled 2a - new mii_eof signal) demonstrates the end-of-frame signaling that complements the start-of-frame indication. This sixth stage 312 shows the EOF signal 316 that precisely indicates when Layer 2 packet data concludes, enabling the checking logic 206 to perform frame check sequence operations and the Mil encoder 118 to complete packet reconstruction with optimal timing. The coordination between these signals allows the MACsec engine 102 toAttorney Docket No.: 27170.1109 (L1057PCT)process packets with constant latency regardless of packet content or classification results.

[0116] The bus timing diagram 300 illustrates how the enhanced signaling from the MAC unit 106 creates an opportunity window during preamble insertion that the MACsec engine 102 utilizes for parallel security processing. The natural timing delay introduced by the MAC reconciliation layer 204 during preamble insertion provides approximately 16 clock cycles in a 10 Mbit implementation, which the classification logic 114 and MACsec transform logic 116 use to complete header inspection, packet classification, and cryptographic preparation before the actual packet data requires modification. This timing coordination enables the network interface 200 to achieve near-zero MACsec processing latency while maintaining full compatibility with standard Ethernet protocols and the PCS or PLCA component 108. The timing relationships demonstrate that the optimized system can complete security operations before the actual packet data requires modification, enabling constant latency operation suitable for halfduplex automotive Ethernet applications.

[0117] FIG. 4 illustrates a flowchart of a method 400 for operating a transmitting path of a MACsec engine with optimized area and latency characteristics according to at least one embodiment. The method 400 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device to perform hardware simulation), or a combination thereof. In one embodiment, the method 400 is performed by any of the hardware described above with respect to FIG. 1 or FIG. 2. In one embodiment, the method 400 is performed by the network interface 100 or network interface 200 described with respect to FIG. 1 or FIG. 2. In one embodiment, some or all operations of the method 400 are performed by the MACsec engine 102, the classification logic 114, or the MACsec transform logic 116 of FIG. 1 or FIG. 2. In one embodiment, some or all operations of the method 400 are performed by the MAC unit 106, the MAC reconciliation layer 204, or the checking logic 206 of FIG. 2. In one embodiment, some or all operations of the method 400 are performed by the Mil encoder 118 of FIG. 1 or FIG. 2, or the MACsec engine 102 of FIG. 1 or FIG. 2. In one embodiment, some or all operations of the method 400 are performed by the TX packet buffer 104 or PCS or PLCA component 108 of FIG. 1 or FIG. 2, an integrated circuit having the MACsec engine or classification logic, as described herein.Attorney Docket No.: 27170.1109 (L1057PCT)

[0118] Referring to FIG. 4, the method 400 begins with the processing logic receiving a Layer 2 (L2) packet from an Ethernet Media Access Controller (MAC) at a first media independent interface (Mil) port of the MACsec engine (block 402). This initial operation can establish the data flow from the MAC unit to the MACsec engine, where the L2 packet contains the standard Ethernet frame structure including headers, payload data, and frame check sequence information. The input Mil port serves as the input interface that couples the MACsec engine to the upstream MAC processing components.

[0119] At block 404, processing logic receives first information from the Ethernet MAC and performs a classification operation using the first information before receiving payload data of the L2 packet at the input Mil port. This operation can represent the optimization that enables early packet processing, where the first information comprises packet data, start-of-packet indication, and end-of-packet indication provided in advance of the actual payload data transmission on the Mil bus. The classification operation analyzes packet headers to determine appropriate security policies such as encryption, integrity -only protection, or bypass mode, utilizing the timing advantage created by the MAC'S preamble insertion process.

[0120] At block 406, processing logic performs a MACsec transform operation on the L2 packet based on the results of the classification operation. This operation can encompass the cryptographic processing including payload encryption using algorithms such as AES-GCM, security tag generation and insertion, and ICV calculation and appending. The transform operation can modify the packet structure to include the necessary security enhancements while maintaining proper Ethernet frame formatting.

[0121] At block 408, processing logic receives second information from the Ethernet MAC, where the second information indicates a start and end of the L2 packet. This information can include explicit frame boundary signals including start-of-frame and end-of-frame indicators that eliminate the need for Mil bus decoding to detect packet boundaries. The second information enables precise timing coordination for frame check sequence operations and packet reconstruction activities.

[0122] At block 410, processing logic encodes the L2 packet for transmission to a physical coding sublayer (PCS) or a physical-level collision avoidance (PLCA) component via an output Mil port of the MACsec engine. This operation can involve reconstructing the processed packet with all security modifications applied, recalculating the frame check sequence to account for the inserted security tags and encrypted payload, and formatting the data for proper transmission to the downstream physicalAttorney Docket No.: 27170.1109 (L1057PCT)layer components. The encoding process maintains compatibility with standard Ethernet protocols while preserving the timing optimizations achieved through the enhanced MAC signaling approach.

[0123] The method illustrated in FIG. 4 demonstrates the sequential processing operations that enable near-zero latency security processing through enhanced coordination between MAC and MACsec components.

[0124] The method illustrated in FIG. 4 demonstrates how the coordinated processing operations enable the MACsec engine to achieve constant latency operation with minimal silicon area requirements, making it particularly suitable for automotive and industrial Ethernet applications requiring predictable timing behavior and cost-effective implementation.

[0125] In alternative embodiments, the method 400 may include additional operations that leverage the enhanced signaling capabilities described with respect to FIG. 1 to FIG.3. For example, at block 404, the classification operation may include analyzing VLAN tags, EtherType fields, and priority indicators within the first information to determine traffic-specific security policies. The classification logic 114 may support multiple concurrent classification rules for different automotive or industrial protocol requirements, enabling differentiated security treatment based on packet characteristics.

[0126] Alternative embodiments may include additional operations between blocks 404 and 406 for performing header validation and integrity pre-checks using the early packet information. The processing logic may verify frame length consistency, validate MAC address formats, or perform protocol-specific header field verification before initiating cryptographic operations. These validation steps can be performed in parallel with the natural timing delays created by preamble insertion in the MAC reconciliation layer 204.

[0127] In some embodiments, the MACsec transform operation at block 406 may include alternative cryptographic algorithms beyond AES-GCM, such as Ascon for different security or performance requirements. The transform operation may also include key derivation functions, security association management, and replay protection mechanisms. Alternative implementations may support multiple concurrent security associations for handling different traffic flows or security domains simultaneously.

[0128] Additional embodiments may include operations for timestamp insertion during the transform operation at block 406, particularly for Time-Sensitive Networking (TSN) applications. The processing logic may insert precision timestamps into the L2 payloadAttorney Docket No.: 27170.1109 (L1057PCT)field or security tag field to support real-time communication requirements in automotive and industrial networks.

[0129] Alternative embodiments may expand block 408 to include reception of additional signaling information beyond basic start and end indicators. The second information may include frame quality indicators, error detection flags, or physical layer status information that enables adaptive processing based on network conditions. The processing logic may also receive buffer status information or flow control signals that coordinate with the TX packet buffer 104.

[0130] In certain embodiments, the encoding operation at block 410 may include additional formatting steps for different physical layer requirements. For automotive Ethernet applications using PLCA components, the encoding may include collision avoidance signaling, beacon generation, or multi-drop bus coordination. For industrial applications, the encoding may include forward error correction, adaptive equalization parameters, or redundancy information for harsh electromagnetic environments.

[0131] Alternative embodiments may include additional operations for diagnostic and monitoring functions throughout the method 400. The processing logic may collect performance statistics, security event logs, or timing measurements that enable system optimization and troubleshooting. These monitoring operations can be performed in parallel with the main processing flow without affecting the optimized latency characteristics.

[0132] Some embodiments may include conditional branching operations that enable different processing paths based on packet classification results or system configuration. For example, the method may include bypass paths that skip cryptographic operations for certain packet types, or express paths that provide even lower latency for time-critical traffic.

[0133] Alternative implementations may include operations for coordinating with multiple MACsec engines operating in parallel, enabling load balancing or redundancy for high-availability applications. The method may include synchronization operations, shared resource management, or failover mechanisms that maintain security processing continuity.

[0134] Certain embodiments may expand the method to include bidirectional processing capabilities, with additional operations for handling received packets and performing decryption, authentication verification, and integrity checking. TheseAttorney Docket No.: 27170.1109 (L1057PCT)receive-side operations would complement the transmit-side processing shown in FIG. 4 to provide complete MACsec functionality.

[0135] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0136] In the above description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that the aspects of the present disclosure may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present disclosure.

[0137] Some portions of the detailed descriptions above are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0138] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “receiving,” “determining,” “selecting,” “storing,” “setting,” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.Attorney Docket No.: 27170.1109 (L1057PCT)

[0139] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), RAMs, erasable programmable ROMs (EPROMs), EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0140] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear as set forth in the description. In addition, aspects of the present disclosure are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein.

[0141] Aspects of the present disclosure may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any procedure for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium (e.g., read-only memory (“ROM’), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.).

[0142] Typically, such “fragile” data is delivered sequentially from the data source to each of its destinations. The transfer can include transmitting or delivering the data from the source to a single destination and waiting for an acknowledgment. Once the acknowledgment has been received, the source then commences the delivery of data to the next destination. The time required to complete all the transfers can potentially exceed the lifespan of the delivered data if there are many destinations or there is a delay in reception for one or more transfer acknowledgments. This has traditionally beenAttorney Docket No.: 27170.1109 (L1057PCT)addressed by introducing multiple timeout / retry timers and complicated scheduling logic to ensure timely completion of all the transfers and identify anomalous behavior.

[0143] In at least one embodiment, the situation can be improved by either broadcasting the data to all the destinations at once, like a multi-cast transmission in Ethernet. This can decouple the data delivery and acknowledgment without delaying the delivery of data by a previous destination’s delivery acknowledgment. These approaches can provide some following benefits, as well as others. Broadcasting the data to all destinations at once can remove any limit to the number of destinations that can be supported. The control logic can be simplified. For example, there can be a single time to track the lifespan of data and a single register to track delivery acknowledgment reception. In one embodiment, an incomplete delivery is simply indicated by the register not being fully populated by l’s (or 0’s if the convention is reversed) at the end of the data timeout period.

[0144] It is to be understood that the above description is intended to be illustrative and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. Therefore, the disclosure scope should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

Attorney Docket No.: 27170.1109 (L1057PCT)CLAIMSWhat is claimed is:

1. A system comprising:a Media Access Controller (MAC) unit coupled to a physical coding sublayer (PCS) through a media independent interface (Mil) bus; anda Media Access Control Security (MACsec) engine located between the MAC unit and the PCS, wherein the MAC unit is to:provide Mil signals with packet data on the Mil bus;provide extra Mil signals on the Mil bus to eliminate Mil bus decoding by the MACsec engine; andprovide early packet signals to the MACsec engine to allow the MACsec engine to perform classification and transformation ahead of receiving the Mil signals with the packet data on the Mil bus, and wherein the MACsec engine is to modify the packet data with substantially zero egress latency.

2. The system of claim 1, wherein the Mil signals with the packet data comprise a Layer 2 (L2) packet that comprises classification scope data and payload data, wherein the early packet signals comprise the classification scope data of the L2 packet, and wherein the MACsec engine is to perform a classification operation using the classification scope data prior to the MACsec engine receiving the L2 packet on the Mil bus, and wherein the MACsec engine is to perform a MACsec transform operation after the classification operation.

3. The system of claim 2, wherein the MACsec engine comprises:classification logic to perform the classification operation;MACsec transform logic to perform the MACsec transform operation; checking logic to check a frame checksum (FCS) of a frame, the frame comprising a preamble, the L2 packet, and the FCS; anda media independent interface (Mil) encoder to encode the frame and recalculate the FCS for transmission to the PCS.Attorney Docket No.: 27170.1109 (L1057PCT)4. The system of claim 2, wherein the MACsec transform operation comprises encrypting the payload data to obtain encrypted payload data and inserting the encrypted payload data into the L2 packet.

5. The system of claim 4, wherein the MACsec transform operation further comprises generating a MACsec security tag using the classification scope data and inserting the MACsec security tag into a header of the L2 packet before the encrypted payload data.

6. The system of claim 4, wherein the MACsec transform operation further comprises generating an Integrity Check Value (ICV) and appending the ICV to the L2 packet after the encrypted payload data.

7. The system of claim 1, wherein the early packet signals comprises a start-of-packet indication, packet data, and an end-of-packet indication.

8. The system of claim 1, wherein the extra Mil signals comprise a start-of-frame indication and an end-of-frame indication.

9. The system of claim 1, wherein the MACsec engine is part of an Automotive Ethernet device.

10. A Media Access Control Security (MACsec) engine comprising:an input media independent interface (Mil) port to receive a Layer 2 (L2) packet from an Ethernet Media Access Controller (MAC);an output Mil port to couple to a physical coding sublayer (PCS) component; a third port to receive early packet signals of the L2 packet from the Ethernet MAC;classification logic to receive the early packet signals from the Ethernet MAC and perform a classification operation using the early packet signals before the input Mil port receives the L2 packet from the Ethernet MAC;MACsec transform logic to perform a MACsec transform operation on the L2 packet; andAttorney Docket No.: 27170.1109 (L1057PCT)a Mil encoder to receive the L2 packet and extra signals from the Ethernet MAC via the input Mil port and encode the L2 packet for transmission to the PCS via the output Mil port, the extra signals indicating a start and end of the L2 packet.

11. The MACsec engine of claim 10, further comprising checking logic to check a frame checksum (FCS) of a frame, the frame comprising a preamble, the L2 packet, and the FCS, and wherein the Mil encoder is to recalculate the FCS for transmission of the frame to the PCS.

12. The MACsec engine of claim 10, wherein the L2 packet comprises classification scope data and payload data, wherein the early packet signals comprises the classification scope data of the L2 packet, and wherein the classification logic is to perform the classification operation using the classification scope data prior to the MACsec engine receiving the L2 packet on the input Mil port, and wherein the MACsec transform logic is to perform the MACsec transform operation after the classification operation.

13. The MACsec engine of claim 10, wherein the MACsec transform operation comprises encrypting the payload data to obtain encrypted payload data and inserting the encrypted payload data into the L2 packet.

14. The MACsec engine of claim 13, wherein the MACsec transform operation further comprises generating a MACsec security tag using the classification scope data and inserting the MACsec security tag into a header of the L2 packet before the encrypted payload data.

15. The MACsec engine of claim 13, wherein the MACsec transform operation further comprises generating an Integrity Check Value (ICV) and appending the ICV to the L2 packet after the encrypted payload data.

16. A method of operating a Media Access Control Security (MACsec) engine, the method comprising:receiving a Layer 2 (L2) packet from an Ethernet Media Access Controller (MAC) at an input media independent interface (Mil) port of the MACsec engine;Attorney Docket No.: 27170.1109 (L1057PCT)receiving early packet signals of the L2 packet from the Ethernet MAC; performing a classification operation using the early packet signals before receiving the L2 packet at the input Mil port;performing a MACsec transform operation on the L2 packet; andreceiving extra Mil signals at the input Mil port from the Ethernet MAC, the extra Mil signals indicating a start and end of the L2 packet; andencoding the L2 packet for transmission to a physical coding sublayer (PCS) via an output Mil port of the MACsec engine.

17. The method of claim 16, further comprising:checking a frame checksum (FCS) of a frame, the frame comprising a preamble, the L2 packet, and the FCS; andrecalculating the FCS for transmission of the frame to the PCS.

18. The method of claim 16, wherein performing the MACsec transform operation comprises encrypting the payload data to obtain encrypted payload data and inserting the encrypted payload data into the L2 packet.

19. The method of claim 18, wherein performing the MACsec transform operation further comprises generating a MACsec security tag using the classification scope data and inserting the MACsec security tag into a header of the L2 packet before the encrypted payload data.

20. The method of claim 18, wherein performing the MACsec transform operation further comprises generating an Integrity Check Value (ICV) and appending the ICV to the L2 packet after the encrypted payload data.

Images