As bandwidth requirements have increased over time, new network standards and topologies have been implemented in automobiles. This has led to multiple technologies and standards for communication between ECUs, including CAN, CAN-FD, FlexRay, LIN, MOST, and even others such as USB and LVDS. Sensor data exchange has been achieved through different bus network methods in an ad-hoc manner. Popular methods, such as CAN and LIN, operate as a shared bus without any switching (forwarding) at the device level. In the last five years, the shift to more sophisticated in-car functions, driven by Advanced Driver Assistance Systems (ADAS), has stipulated higher levels of connectivity. The significantly higher throughput of data communication, with the goal of reducing latency across the network, has led to a review of the network approach that should be employed. This has
Coinciding with the growth of in-car infotainment systems, the capacity of Wi-Fi networks, and the provision of future support for V2X systems, it's perhaps no surprise that Ethernet has become the de facto vehicle networking protocol for new automotive platforms. Legacy networking protocols are likely to remain in use for some time, so it's important to incorporate support for these legacy networking protocols within the Ethernet ecosystem. IEEE 1722 has specified a method for taking legacy communications, such as CAN and LIN, and integrating them into Ethernet packets, with the goal of making Ethernet the primary networking method for automotive applications. With a long and proven track record outside the automotive environment, Ethernet has impressive credentials and will help simplify the complexities of automotive networking.
Wiring harnesses are among the five most expensive and heaviest components in a car, so using a single, well-tested network will help reduce both of these factors. Automotive Ethernet standards of 100 Mbps and 1 Gbps have been defined for use with a single pair of unshielded copper wires.
Increased internet connectivity in cars opens up potential attack surfaces and entry points, making vigilance paramount, but it also opens up the possibility of providing more networking functionality within the Ethernet switch by analyzing data flow. For the embedded developer, the need to perform real-time wire-speed analysis of all incoming data without introducing any latency, while using a finite amount of computing resources, can be challenging. Achieving the necessary protection or additional functionality requires packet inspection using a set of predefined rules. This is executed based on certain data values or conditions encountered. Examples include a wide range of new audio/visual applications and time-sensitive or critical network requirements.
Within a legacy Ethernet switch, decisions about which port to forward a packet to are made at Layer 2 (L2) of the OSI network model. See Figure 1.
In Figure 1, if the source address (SA) of the incoming frame has not been previously encountered, it is added to the address database along with the frame's incoming port number. If the destination address (DA) is already in the bridge's lookup table, then the packet is forwarded accordingly; otherwise, the frame is flooded. Over the years, IEEE standards governing protocols used at Layer 2, such as 802.1 MAC bridging, VLANs, and port-based network access control standards, have focused on the first 16 bytes of an Ethernet frame. They have steadily evolved, with recent additions including time-sensitive audio/video transmission (AVB) networking standards such as 802.1AS. In particular, the need for a deterministic network within the automotive environment is becoming increasingly necessary to ensure timely and guaranteed delivery across the network. Locking all ECUs to a single Grand Master clock source and maintaining AV content quality are just two examples. Enhanced capabilities have also been introduced that facilitate the inspection of OSI Layer 3 information, such as IPv4/IPv6 packet prioritization and IPv4/IPv6 eavesdropping.
While the above techniques were initially sufficient for Ethernet-based automotive applications, greater flexibility is needed to inspect packets in a real-time, "wire-speed" approach so that advanced packet classification, debugging/diagnostics, and security features can be implemented. However, the possibility of achieving deep packet inspection (DPI) must be balanced against the space-constrained and budget-sensitive nature of automotive applications. Historically, achieving such wire-speed packet classification has not been possible without using a number of compute-intensive devices that have taken up additional board space and impacted the bill of materials (BoM). However, newer devices can now offer this capability in a compact package using a DPI engine, an approach borrowed from the enterprise networking world.
The DPI engine in Marvell's 88Q5050 IC switch employs a technique called TCAM (Ternary Content-Addressable Memory). TCAM takes the packet data and matches its contents to a predefined filter to find matches. Based on the match or non-match result, the DPI engine can determine the action to be taken. This approach provides three possibilities (hence the term ternary) for matching binary data, where the state of each bit can be determined to be 0, 1, or "X" (doesn't matter). The "doesn't matter" rule can be extremely useful for configuring masks that allow for easy verification of data ranges. Implemented with a large number of parallel ports located within the bridge conduit, TCAM supports wire-speed classification and data modification across multiple ports. Depending on the implementation, TCAM can operate on a specific number of bytes within the packet header and payload area. DPI can perform actions such as changing the packet's destination port, discarding a frame, duplicating a frame to another port, or changing the frame priority or queue.
Let's look at three automotive use cases for DPI, the first being for debugging/diagnostics. On-board Ethernet diagnostics (OBD) are typically designed with a 100BASE-TX port that has a speed of 100 Mbps. While this seems adequate for most applications, the practical reality is that contention ratios in fully utilized switch configurations forward data at speeds exceeding 100 Mbps, making it impossible to duplicate all frames on the switch without impacting the actual data flow. This leads to packets being dropped, resulting in incomplete duplication. The alternative is to use DPI to identify and classify only the frames of interest. Refer to Figure 2. In this example, to address a problem with Precision Time Protocol (PTP) frames, a DPI rule can be configured to reflect all ports carrying PTP messages to the OBD port. This can be achieved using either the EtherType (0x88F7) or the MSG ID, for example. All PTP-related frames would then be reflected to the OBD port, even if the switch were operating at full capacity.
Another application of DPI is for security. Identifying valid Ethernet packets can consume a significant amount of computing resources for a CPU located in the data path, meaning that achieving real-time low-latency classification would require processing capabilities beyond the size, Bill of Materials (BoM), and capabilities of most automotive environments. However, TCAM provides a means of verifying that each packet entering an Ethernet switch is in the correct format for the network.
In the example illustrated in Figure 3, the TCAM masks are configured to allow only incoming packets within a range of MAC DAs, SAs and VLAN IDs, these being destinations of 00:01:02:XX:XX:XX (matching all MAC DA addresses in the range 00:01:02:00:00:00 to 00:01:02:FF:FF:FF), source addresses of 00:11:22:XX:XX:XX (matching all MAC SA addresses in the range 00:11:22:00:00:00 to 00:11:22:FF:FF:FF) and VLAN ID: 0x0XX (matching all VLAN IDs in the range 0x000 to 0x0FF).
This example uses only Layer 2 information from the packet; however, depending on the TCAM implementation, Layer 3, Layer 4, or higher-layer information can be used as part of the TCAM match.
TCAM presents the only cost-effective, low-latency, and low-resource method for verifying every packet entering a switch. Packets that fail the above tests can be dropped or subjected to further action.
In the final use case example, DPI is used to make routing decisions for encapsulated Ethernet packets. As mentioned earlier, the goal is to incorporate many different legacy automotive networking protocols, such as LIN and CAN, into Ethernet, with the long-term objective of reducing automotive network complexity and costs. While gateways exist to perform such encapsulation, forwarding decisions must be made after encapsulation. However, using DPI provides a method for making forwarding decisions based on the encapsulated data. The packet format is already defined according to IEEE 1722-2016, so TCAM can be used to classify the packet type (CAN, for example) and use CAN_BUS_ID and CAN_IDENTIFIER to create routing actions accordingly.
Implementing TCAM-based DPI techniques within an automotive network environment opens support for a host of new applications, standards, and features that were previously not commercially viable. As the connected car becomes a reality, manufacturers face the challenge of incorporating many more safety features while simultaneously trying to simplify the complexities of the network environment. DPI presents an opportunity to achieve both.
Author: Christopher Mash, Senior Director of Automotive Applications and Architecture
