Packet filtering based on vehicle status

Abstract

Novel tools and techniques for packet filtering based on vehicle status. A networked device may feature an access control list (ACL) with filtering rules that each have a field to identify, for example, a possible state of a vehicle. Based on this field, rules that are not applicable to the state may be disregarded when evaluating packets against the rules in the ACL.

Description

Technical Field

[0001] The technical solution generally relates to packet filtering in computer networks, and more specifically to packet filtering in carrier networks, describing the current state or context of the carrier. Background Art

[0002] Ethernet networks (e.g., Internet Protocol ("IP") networks) typically use packet filtering for access control between devices. For example, a networking device (e.g., a router, firewall, switch, etc.) can typically allow or block a given packet flow based on characteristics of the sender and / or receiver of the packet and / or characteristics of the packet itself. In a vehicle, for example, a packet flow can include communications between devices of the vehicle (e.g., sensors, electronic control units (ECUs), etc.) and / or communications from outside the vehicle.

[0003] Networking devices often employ access control lists (ACLs) to provide access control functionality when filtering packets. Generally, an ACL will instruct the networking device how to handle incoming packets (e.g., block packets, allow packets, etc.). Typically, ACLs become cumbersome and impose a nontrivial processing cost to evaluate and determine the appropriate action for each packet (or packet stream), thereby reducing the ability of the networking device to process packets in a timely manner as they arrive and introducing delays in delivery. In some contexts, additional computing resources can alleviate this situation. However, in other examples, such as the case of carrier networks, computing resources are often severely limited.

[0004] One solution might be to modify the ACL (to add, remove, or modify rules) in certain circumstances, but this can be a cumbersome and error-prone process. If done dynamically, it can result in delayed (or dropped) packets as the networked device filters packets that must be buffered in some way while the ACL is updated. This untimely delivery of packets can be unacceptable, or even dangerous; for example, untimely delivery of information to a vehicle ECU can result in unexpected or even dangerous operation of the vehicle, and / or can result in damage to the vehicle.

[0005] Therefore, more efficient techniques are needed to filter packets in a network, especially in resource-constrained networking devices. Summary of the invention

[0006] On the one hand, the present disclosure provides a networking device in a carrier, the networking device comprising: a processor; a ternary content addressable memory (TCAM); a circuit system for receiving an Ethernet packet including an Internet Protocol (IP) packet at a line rate, the Ethernet packet identifying a source of the Ethernet packet and a destination of the Ethernet packet; a circuit system for accessing a configuration register of the carrier to identify a state of the carrier; a circuit system for accessing a static access control list (ACL) including a plurality of filtering rules in the TCAM, wherein each of the plurality of filtering rules: has a priority; and includes a field identifying one or more of a plurality of possible states of the carrier; a circuit system for said state, a circuit system for comparing the identified state of the carrier with the field of each filter rule that identifies one or more of the multiple possible states of the carrier to identify one or more of the multiple filter rules as applicable; a circuit system for evaluating the Ethernet packet against at least one of the one or more applicable filter rules in a priority order of the one or more applicable filter rules; a circuit system for determining one or more management actions to be performed on the packet at the line rate and at least partially based on the evaluation of the Ethernet packet against at least one of the one or more applicable filter rules; and a circuit system for performing the one or more management actions on the packet.

[0007] On the other hand, the present disclosure provides a device comprising: logic for receiving Ethernet packets at line rate, wherein the Ethernet packets identify a source of the Ethernet packets and a destination of the Ethernet packets; logic for identifying a state of a carrier; logic for determining one or more management actions to be taken on the packets based at least in part on the state of the carrier; and logic for performing the one or more management actions on the packets.

[0008] On the other hand, the present disclosure provides a carrier comprising a networking device, wherein the networking device includes: logic for receiving Ethernet packets at line rate, the Ethernet packets identifying the source of the Ethernet packets and the destination of the Ethernet packets; logic for identifying the state of the carrier; logic for determining one or more management actions to be taken on the packets based at least in part on the state of the carrier; and logic for performing the one or more management actions on the packets. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a block diagram of a vehicle including a vehicle network according to some embodiments.

[0010] Figure 2 is a block diagram illustrating a network-connected device, according to some embodiments.

[0011] Figure 3 is a flow chart illustrating a method of filtering packets according to some embodiments.

[0012] Figures 4 to 6 Components of a filtering rule according to some embodiments are described. DETAILED DESCRIPTION

[0013] Various embodiments provide devices (including networked devices), logic for programming such devices, and methods for filtering packets in a network (which may be performed, for example, by such devices). (As used herein, "filtering" means performing one or more management actions on a packet, e.g., as described in detail below). As used herein, the term "network" means any communication system (including transmission media and networked devices) that provides communication between various devices. In a particular set of embodiments, the network is an in-vehicle network, such as an Automotive Ethernet (AE) network, which, as one example, may include the functionality of a Controller Area Network (CAN).

[0014] If Figure 1 As illustrated, in some embodiments, the vehicle network 100 may be part of a vehicle 105 and may include one or more networked devices 110. The network 100 provides communications between various sensors 115 (e.g., temperature sensors, motion sensors, proximity sensors, cameras, presence sensors, vehicle operation sensors, etc.), actuators 120, engine control systems 125, ECUs 130 (e.g., transmission control systems, anti-lock brake systems, body control systems, speed control systems, battery management systems, powertrain control systems, door control systems, etc.), infotainment and driver information systems 135, 140, and other data generating or data consuming devices 145 in, on, or around the vehicle 105. In some cases, the network 100 may provide communications with a network 150 (e.g., the Internet) external to the vehicle 105.

[0015] Therefore, some embodiments provide a networking device (and corresponding methods and logic) for a vehicle network. As used herein, the term "vehicle" means any type of means of transport for people or items. According to some embodiments, the vehicle may be a car, motorcycle, bus, truck, construction equipment, etc. In other embodiments, the vehicle may be an airplane, a ship, or a boat, etc. Some embodiments include a vehicle including such a network and / or networking device. Unless otherwise expressly indicated, the term "network" refers to such a vehicle network and any other suitable network in this article. This network may include wired and / or wireless transmission media. In a specific embodiment, the network is an Internet Protocol (IP) network, which may (or may not) include a router or gateway for interconnecting with other networks (such as the Internet).

[0016] As used herein, the term "networking device" means any device or system capable of performing packet switching and / or routing in a network, and in particular, can perform the packet filtering operations described herein. In some cases, a networking device may be an integrated switch or router implemented as a system on a chip (SoC); in other cases, a networking device may be relatively less integrated, including several discrete components within a larger housing, such as a conventional desktop or rack-mount switch and / or router. Thus, while a device according to some embodiments may include the networking device itself, a device according to other embodiments may include (e.g., a microprocessor, a microcontroller, an SoC, an application specific integrated circuit (ASIC), etc.) that may be employed within the networking device and / or may perform some or all of the operations described herein.

[0017] Although specific packet filtering techniques are described in further detail below (and may include, but are not limited to, the management actions described below), the most basic implementation of packet filtering includes determining whether a particular packet received at a networking device should be delivered to its intended destination; if so, delivering the packet; and if not, refusing to deliver the packet (at least to the intended destination). Examples of networking devices may include, but are not limited to, routers, switches, bridges, gateways, firewalls, repeaters, hubs, modems, network interface cards, and / or access points. In some cases, a networking device may be a security device that communicates with another networking device (e.g., a router or switch). In a particular embodiment, a networking device may be embodied by a carrier-specific Ethernet switch or router. Such switches and routers are typically resource-constrained and must carefully manage the resources to avoid throttling of packets that should be delivered.

[0018] As used herein, the term "packet" generally means a protocol data unit (PDU) at any appropriate layer of the Open Systems Interconnection (OSI) model. An Ethernet packet or frame (the two terms are used interchangeably herein) is an example of a packet, as the terms are used herein. In general, a packet has a header (and / or trailer) portion and a payload portion. Thus, for example, an Ethernet packet (a physical (PHY or layer 1) packet) includes a preamble and a start frame delimiter, after which the packet includes an Ethernet frame, which is itself a data link layer (layer 2) packet. An Ethernet frame includes header information (including source and destination media access control (MAC) addresses) and a payload, which is typically a network (layer 3) packet. An IP packet is an example of a layer 3 packet, and it also contains header information and payload information.

[0019] As described above, various embodiments provide packet filtering techniques at any appropriate layer of the OSI model, and in particular at layer 2 and higher of the model. Networked devices according to some embodiments employ access control lists (ACLs) to perform the packet filtering techniques described herein. As used herein, an ACL is a table or database that may be stored in a content addressable memory (CAM), such as a ternary content addressable memory (TCAM), or elsewhere that includes one or more filtering rules. As described above, each filtering rule may be written with fields to match different packet fields (or portions) of interest to expected values; such fields may include header information (e.g., sending device address, destination device address, etc.) and / or payload information. Each rule also includes an action to be taken if the packet matches the expected value of the rule. As described in further detail below, the actions to be taken may include (but are not limited to) permitting (allowing) or denying (blocking or dropping) the delivery of a packet stream, such as in a firewall blacklist / whitelist application, or other more specific actions, such as redirecting the packet stream to an address (or port) different from the destination address (or port corresponding to the destination address) specified in the packet's header, listening to packets, and the like.

[0020] Table 1 depicts a typical ACL, with multiple rules (rows), each with fields (columns) for (1) rule priority, (2) expected packet value, and (3) action to take if a packet matches the expected packet value.

[0021]

[0022] Table 1

[0023] As shown by Table 1, the order field specifies the order in which the rules should be used to evaluate incoming packets. The protocol, source IP, source port, destination IP, and destination port fields contain the expected packet values, and the action field specifies the action to be taken. In a typical system, the networking device will evaluate each rule in the order specified by the order column until it finds a rule in which all expected packet values ​​match the actual value of the incoming packet. At this point, the networking device will take the specified action and stop evaluating the packet against any additional rules. It should be noted that Table 1 may include blank rows (e.g., rows 3 and 4) for future configuration. This is usually required because the ACL will need to be dynamically updated to add additional rules, which may be higher in priority than rules 5 and 6. As shown in this example, the priority of each rule is implicit in its order (Table 1 from top to bottom), but other priority schemes are also possible.

[0024] In a novel aspect of some embodiments, the ACL of a networked device is enhanced to include state information. As used herein, the terms "state" and "context" are used interchangeably to mean information about a state or context, regardless of the characteristics of the packet (or packet stream) itself in which the communication exists. In some embodiments, the state information relates to the state of a vehicle associated with (or including) a vehicle network of which the networked device is a part. Any of a variety of states or contexts is possible. For example, the state of a vehicle may include any one or more of the following data: vehicle gear state (driving, parked, etc.), vehicle engine state (on, off), vehicle position, vehicle speed, vehicle acceleration, vehicle direction, the identity of the driver or passenger in the vehicle, objects close to the vehicle (e.g., other vehicles, traffic signals, pedestrians, etc.) and their relative positions, vehicle maintenance mode state (on, off), the presence or absence of a "maintenance required" notification, fuel level, battery charge level, whether the vehicle is in autonomous driving or advanced driver assistance mode, etc. These examples should not be construed as limiting; in general, a vehicle state may include any identifiable state or characteristic of the vehicle, its systems, occupants, and / or environment.

[0025] It should also be noted that the embodiments are not limited to vehicle-related contexts. Any number of contexts or states may be implemented using the techniques within the various embodiments. For example, in a non-vehicle network, the context may include time constraints (e.g., only process rules where the current time matches the expected time state), business constraints (e.g., only process rules where the customer state matches the expected customer state), etc. In one aspect, the context (including (but not limited to) vehicle state) may include purchased additional services; for example, an ACL may specify that a networked device only allows a particular streaming service if the vehicle owner (or, in other cases, a customer of another type of service provider (e.g., an Internet service provider)) purchases a particular service (e.g., a streaming service).

[0026] Table 2 illustrates an example of such an enhanced ACL that may be employed by networked devices in a carrier network.

[0027]

[0028] Table 2

[0029] The ACL shown by Table 2 includes a field for "Car Status," which corresponds to the possible states of the vehicle, as described above. (The examples of Table 2 also include additional protocols, including Diagnostics over IP (DoIP), which is a remote diagnostic protocol for vehicles, and Service-Oriented Extensible Middleware over IP (SOME / IP), which is AE-specific middleware for communicating control messages between devices on the AE.) It may be noted that the expected packet fields in Table 2 are limited to header information, specifically the protocol and the source and destination addresses and ports. It should be understood that the nature of the expected packet value fields in Table 2 are exemplary, and various embodiments may include more or fewer fields, with various expected packet characteristics, including (but not limited to) values ​​corresponding to specific information in the packet payload and / or its characteristics.

[0030] According to some embodiments, a networking device evaluates packets differently than typical packet filtering techniques. For example, some embodiments pre-populate an ACL (eg, in a TCAM) with enabled filtering rules that collectively cover all possible bearer states.

[0031] Thus, in one set of embodiments, the networking device disregards any rule (regardless of priority) in which the vehicle state does not match the expected state field of the ACL. Advantageously, this can result in more efficient ACL parsing and packet evaluation than sequentially traversing each rule until a match is found, particularly for ACLs with hundreds or thousands of rules. In particular, this technique can allow even resource-constrained networking devices (e.g., in a vehicle network) to filter packets at line rate, thereby avoiding bottlenecks at the networking device. As used herein, the term "line rate" means the rate at which a networking device receives packets from a network.

[0032] In aspects of some embodiments, tracking the state of the vehicle is implemented in a configuration register external to the CAM. In some cases, a networked device will have multiple configuration registers to store parameters that control different aspects of the networked device. Any such register or portion of a register may be used to store a value (e.g., an 8-bit value) that represents a particular state of the vehicle at the current time. In contrast to many configuration registers (which remain static until manually changed and then take effect at the next boot of the device), the configuration register for the vehicle state may be dynamically updated. For example, a management entity, typically software running on a CPU or microcontroller (or elsewhere) of the networked device, updates this configuration register as the state of the vehicle changes; in some cases, these updates may be performed in real time or near real time as the state of the vehicle changes. According to various embodiments, the networked device matches rules against the state of the vehicle; when evaluating rule matches for incoming packets, only rules associated with the current state of the vehicle are considered. Advantageously, once the filtering rules are set, certain embodiments may allow all of this processing to be performed in hardware without CPU intervention; the CPU's only task may be to update the state variables, which is a very lightweight and fast task.

[0033] This hardware implementation can provide several benefits when compared to implementing the ACL in software running on the CPU or the CPU dynamically updating the ACL in the TCAM by populating or enabling rules relevant to the current state and removing irrelevant rules. Software implementations typically have limited processing power and are difficult to scale as data rates increase because each packet that needs to be filtered must be forwarded to the CPU and back.

[0034] Dynamically updating ACLs in the TCAM may also be problematic. Thus, various embodiments allow the ACL to be implemented as a static table (e.g., in the TCAM), but this is not required by all embodiments. Rather than leaving gaps in the ACL (an inefficient use of TCAM resources) and / or dynamically inserting, removing, or modifying rules in the ACL to try to account for different vehicle states (a time-consuming and resource-expensive process), the ACL can be preconfigured with rules that correspond to many different vehicle states. This capability can be advantageous because the alternatives—parsing the entire ACL for each packet, swapping different sets of rules, or dynamically enabling / disabling different rules—each introduce complexity, latency, additional points of failure, and / or security vulnerabilities.

[0035] An exemplary device includes logic to perform one or more operations. In some embodiments, the logic includes instructions stored on a non-transitory computer-readable medium and executable by a processor to perform the operations. Alternatively, and / or additionally, the logic may be implemented by circuitry in hardware or firmware that performs some or all of the operations independently of the processor and / or as described elsewhere herein. The operations may include a networking device receiving an Ethernet packet at a line rate. In one aspect, the Ethernet packet may include header information identifying a source of the Ethernet packet and a destination of the Ethernet packet; in another aspect, the Ethernet packet may include an IP packet.

[0036] The operations may further include identifying a state of the carrier and / or determining whether the Ethernet packets should be filtered based at least in part on the state of the carrier. The operations may further include performing one or more management actions based on determining whether the Ethernet packets should be filtered.

[0037] Another set of embodiments provides devices, including but not limited to devices programmed to perform the operations described herein. An exemplary device may include logic implemented in hardware and / or firmware circuitry that performs some or all of such operations independently of a CPU or other processor. Alternatively, and / or additionally, a device may include a processor that may be programmed (e.g., with firmware or software) to perform some or all of the operations described herein.

[0038] Exemplary methods provided by other embodiments may include receiving an Ethernet packet at a computing system at a line rate. In some cases, the Ethernet packet identifies a source of the Ethernet packet and a destination of the Ethernet packet. The method may further include identifying, with the computing system, a state of the carrier, and determining, with the computing system and based at least in part on the state of the carrier, whether the Ethernet packet should be filtered. The method may also include performing one or more management actions based on determining whether the Ethernet packet should be filtered.

[0039] Another set of embodiments provides a non-transitory computer-readable medium encoded with instructions. In some embodiments, the instructions are executable by one or more processors to perform operations. In other embodiments, the instructions are implemented in hardware or firmware and are executable by hardware circuitry to perform some or all operations independently of any processor. The operations may include a networked device receiving an Ethernet packet at a line rate. On the one hand, the Ethernet packet includes header information identifying a source of the Ethernet packet and a destination of the Ethernet packet; on the other hand, the Ethernet packet may include an IP packet. The operations may further include identifying a state of a carrier and / or determining whether the Ethernet packet should be filtered based at least in part on the state of the carrier. The operations may further include performing one or more management actions based on determining whether the Ethernet packet should be filtered.

[0040] Another set of embodiments provides a vehicle, including but not limited to a vehicle comprising a networking device as described herein, executing a method as described herein, and / or programmed with logic to perform the operations described herein.

[0041] Exemplary Embodiments

[0042] Certain exemplary embodiments are described below. Each of the described embodiments may be implemented alone or in any combination, as will be appreciated by those skilled in the art. Therefore, a single embodiment or combination of embodiments should not be considered limiting.

[0043] Figure 2 2 is a block diagram illustrating an example of a networked device 200 that can function as described herein, including but not limited to performing the methods described below. Figure 2 As shown in , device 200 may include a bus 205 , one or more processors 210 , a storage device 215 for instructions, a storage device 220 for ACLs, I / O ports 225 , and a working memory 230 .

[0044] Bus 205 includes one or more components that enable wired and / or wireless communication among the components of networked device 200. Bus 205 may Figure 2 Two or more components of a processor 210 are coupled together, for example, via operational coupling, communication coupling, electronic coupling, and / or electrical coupling. Processor 210 may include a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field programmable gate array, an application-specific integrated circuit, and / or another type of processing component. Processor 210 may be implemented in hardware, firmware, or a combination of hardware and software. In some embodiments, processor 210 includes one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein. For example, networking device 200 may include a storage device 215 for instructions for programming processor 210 in this manner. This storage device 215 may be a non-volatile memory, a hard drive, etc. that stores instructions. In a particular set of embodiments, the instructions are stored as hardware instructions, for example, as encoded in hardware and / or firmware (e.g., hardware circuit system 250, discussed below). In such embodiments, the instructions are typically static (or, in the case of firmware, programmable but non-volatile), because the operation of the networking device may only change as required by the rules in the ACL that may be stored in ACL storage device 220.

[0045] The ACL storage device may be any medium for storing ACLs, which may generally include a database or table of rules, as described elsewhere herein. For example, Table 2 above depicts an example of an ACL. This medium may include non-volatile storage devices, volatile storage devices, magnetic media, and / or the like. In a particular set of embodiments, the ACL storage device includes a TCAM, as described above. Advantageously, storing ACLs in a TCAM provides for more efficient ACL parsing.

[0046] The networking device includes a plurality of I / O ports 225, which in a particular embodiment are Ethernet ports. Other embodiments may include different types of I / O ports (e.g., serial ports, etc.) and / or radios. In some aspects, each of the ports of the networking device is connected to a different device or network segment of the carrier network, which enables the networking device to route or switch packets to the appropriate destination device / network segment if an ACL specifies that the packet should be delivered.

[0047] The networking device may also include a working memory 230 into which an operating system 235 and / or instructions 240 may be loaded (e.g., to perform the operations and methods described herein). In this manner, the networking device 200 may be configured (or programmed) to perform such operations. Depending on the embodiment, the operating system 235 and / or instructions 240 may be loaded into the working memory and / or may be run directly from firmware or hardware.

[0048] The networking device 200 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., instruction storage device 215) may store logic, such as a set of instructions 240 (e.g., one or more instructions or codes) for execution by the processor 210. The processor 210 may execute the set of instructions 240 to perform one or more operations or processes described herein, such as the procedures of the method 300 described below. In some implementations, execution of the set of instructions 240 by the one or more processors 210 causes the one or more processors 210 and / or the networking device 200 to perform such operations.

[0049] As described above, in some embodiments, some or all of the logic may be implemented in hardwired circuitry (e.g., hardware or firmware), working in conjunction with or independently of any processor 210 that the device may or may not have. (As described above, in some cases, circuitry 250 itself may be considered a processor 210.) In such cases, some or all of the logic that implements or causes the performance of some or all of the operations described herein may be encoded in hardware or firmware circuitry (e.g., circuitry 250) and executed directly by such circuitry, rather than being loaded into working memory 235 and run by processor 210.

[0050] For example, as described above, in some embodiments, once the rules in the ACL have been established, the hardware circuitry 250 encoded with this logic (e.g., instructions) performs some or all of the operations herein (described in further detail below) without intervention from the processor 210. In this case, the processor 210 may be used to update the vehicle state variables in the configuration registers 255, but may not need to provide any functionality with respect to the procedures described herein. Offloading such tasks from the processor 210 to the dedicated hardware circuitry 250 may help reduce consumption of limited computing resources in the networked device 200. Additionally, or alternatively, in other embodiments, the processor 210 may be configured (e.g., but software) to perform some or all of the operations or processes described herein. Accordingly, unless the context dictates otherwise, the embodiments described herein are not limited to any specific combination of hardware, firmware, and / or software.

[0051] In one set of embodiments, the networking device includes configuration registers 255 (and / or may communicate with external configuration registers 255). In some embodiments, information about the state of the vehicle is maintained in configuration registers, such as configuration registers 255, in addition to instruction storage 215, ACL storage 220, and / or working memory 230. A management entity, typically software running on a CPU or microcontroller (such as processor 210), may update this register as the state of the vehicle changes (in some cases, in real time or near real time).

[0052] supply Figure 2 The number and arrangement of components shown in FIG. are examples. Figure 2 , networked device 200 may include additional components, fewer components, different components, or differently arranged components than those shown in . Additionally, or alternatively, one set of components (e.g., one or more components) of networked device 200 may perform one or more functions described as being performed by another set of components of networked device 200.

[0053] Figure 3 A method 300 is described that can be used to perform packet filtering techniques according to various embodiments. The method 300 includes storing a plurality of filtering rules (block 310), for example, as part of an ACL, which can be stored in a Figure 2 220. As previously described, an ACL may be a database, table, or list storing a list of rules that specify actions to be taken when fields of an incoming packet match expected fields specified by the rules. Table 2 depicts an exemplary ACL according to some embodiments. Figure 4 The components of the filtering rules in the ACL employed by various embodiments are described in more detail.

[0054] As used herein, the term "filter rule" means any rule that specifies or governs the behavior of a device if the rule is matched. In a particular embodiment, a filter rule may specify management actions to be performed in certain circumstances; such circumstances may include (but are not limited to) information in the packet itself (and / or earlier packets in the packet stream) and / or information about the state of the vehicle, for example, as described in further detail herein. Various filter rules that are possible under various embodiments can be determined from several examples: As an example, DoIP packets transmit data related to vehicle diagnostics used for troubleshooting and repairing problems. A filter rule may allow diagnostic messages only when the vehicle is parked, perhaps because it is safer to run the diagnostics to be performed when the vehicle is not moving. As another example, an over-the-air (OTA) software update attempt may be blocked unless the vehicle is parked, and optionally only at certain times (e.g., midnight) or when the vehicle is parked in a specified location. Another example filter rule may not allow communication with an actuator that changes the position of a seat while the vehicle is moving, as a hardware protection mechanism.

[0055] Figures 4 to 6 Exemplary rule formats according to various embodiments are described. Figure 4 An exemplary regular format 400 for an IPv4 packet is illustrated, Figure 5 An exemplary regular format 500 for an IPv6 packet is illustrated, and Figure 6 An exemplary rule format 600 for non-IP packets is illustrated. Unless otherwise noted, the fields of each of the exemplary formats are labeled with similar reference numbers. Each exemplary rule format 400, 500, 600 includes a field (405, 505, 605) that identifies one or more possible states of a carrier, a port mapping field (410, 510, 610) (which can be a bit map of ingress ports on a networking device, so a given rule can be configured to match packets received from a selected ingress port), and a number of fields (420 to 460, 520 to 560, 570, 612 to 665) related to packet-specific information. Each rule may also include a plurality of user-defined fields (UDFs) (465, 565, 665), which are configurable fields with offsets; these fields can be used to match any arbitrary packet field. In the illustrated embodiment, the size of each field is indicated in bits (where applicable), and as described, the user-defined fields are 16 bits each. It should be appreciated that other embodiments may support different fields, different numbers of fields, and different sized fields.

[0056] As illustrated, the vehicle state fields (405, 505, 605) are encoded using 8 bits, which can allow 256 unique vehicle states to match the rules in the ACL. (Of course, the vehicle state can be encoded with more or fewer bits to support a greater or lesser number of unique vehicle states.) As described in further detail below, the vehicle state variables can be used to distinguish between applicable rules and inapplicable rules for any given state of the vehicle. The use of these fields also allows the entire ACL to be pre-populated (and therefore, the ACL is static during operation), eliminating the need for additional processing or ACL manipulation to account for different vehicle states.

[0057] In some embodiments, the method 300 includes masking the vehicle status field in one or more of the ACL rules (block 305). This masking operation may be performed before, after, or during (and / or as part of) storing the filtering rule. In some cases, a masking bit may be used to mask the filtering rule. For example, by specifying which bits (e.g., of an 8-bit vehicle identifier field) must match the actual vehicle status (e.g., another 8-bit value) and which bits do not need to match, the masking bit allows a given rule to be matched against multiple vehicle states, thereby providing greater flexibility because the rule does not have to be repeated for each applicable vehicle state. For example, a vehicle status field of 0001111X (where "X" represents a "don't care" value, which is applied using a bit mask) will match the status values ​​00011110 and 00011111, thereby allowing the field to match two different status fields.

[0058] Method 300 may further include receiving the packet, for example at a networking device. The networking device receives the packet on one or more ports coupled to a transmission medium (e.g., Ethernet) or a radio of the network, and the packet is received at the "line rate" of the network. To avoid becoming a bottleneck, the networking device ideally performs Figure 3 Packet filtering operations are performed to process incoming packets at line rate.

[0059] At block 320, method 300 includes accessing the ACL, and at block 325, the method includes identifying the state of the carrier. In various embodiments, one or both of these operations may be performed prior to receiving the packet (block 320). Figure 3 These operations are presented in a particular order, but various embodiments may employ these operations (and others) in a different order unless expressly specified otherwise.

[0060] In a particular set of embodiments, the ACL is stored in a TCAM, and accessing the ACL (block 320) may include accessing the ACL in the TCAM. As described herein, the ACL may include a plurality of filter rules. In one aspect, each of the plurality of filter rules may have an assigned priority and / or may include a field identifying one or more of a plurality of possible states of the vehicle.

[0061] In many embodiments, information about the current state of the vehicle is separate from the received packet; that is, in such embodiments, the received packet does not contain information about the state of the vehicle. Thus, identifying the state of the vehicle (block 325) may include receiving information about the state of the vehicle from another device. In some embodiments, identifying the state of the vehicle may include accessing a configuration register (which may be located internal or external to the networked device, but is typically not located in the ACL) that stores a value (which may (but is not necessarily) encoded using the same encoding scheme as the vehicle state field in the ACL).

[0062] Method 300 may include determining one or more management actions to be performed on the packet based at least in part on the state of the vehicle (box 345). Different embodiments may make this determination in different ways. By way of example only, in some embodiments, determining whether the packet should be filtered includes identifying applicable filtering rules (box 330). For example, the networked device may be configured to identify all rules with a vehicle state field that matches the current identified state of the vehicle as applicable by comparing the vehicle state value of each rule with the identified state of the vehicle. As described above, in some embodiments, the identified state of the vehicle is encoded in the same manner as possible vehicle state fields in the ACL, so this comparison may include a bit-by-bit matching operation; if the vehicle state field of the rule has a bit mask, then the bit mask may be considered in the comparison. For example, using the example of Table 2, if the state of the vehicle for which the packet is received is "traveling speed less than 55 mph", then the networked device will identify rules 1, 2, 4, and 6 as applicable to the state of the vehicle.

[0063] In some embodiments, determining the management action to be performed may include ignoring all filter rules except the filter rules identified as applicable to the current state of the vehicle (i.e., the filter rules that are not applicable) (block 335). Using the above example, where rules 1, 2, 4, and 6 are identified as applicable, the networking device will ignore rules 3 and 5 when evaluating that packet. This operation may provide significant advantages over evaluating the packet against all rules in the ACL, as described above. In ignoring all non-applicable filter rules, the networking device effectively remaps the search scope of the ACL to include only applicable rules without having to modify or update the ACL stored in the TCAM (or elsewhere) in any way.

[0064] Thus, determining the management action to be performed may include evaluating the packet against (only) those rules identified as applicable to the current state of the vehicle (block 340), and in particular evaluating the packet against one or more of those applicable rules until a matching rule has been identified. In one aspect, this evaluation may be similar to a typical packet filtering operation, except that by ignoring rules that are not applicable to the current state of the vehicle, the ACL is logically effectively reduced in size (without affecting the actual ACL itself, in some cases). Thus, the evaluation may include evaluating the packet against each applicable rule, in accordance with the priority of the rule, until a matching rule has been found (or, in the event that no higher priority matching rule is found, until a default lowest priority rule is reached). Returning to the example discussed in the previous paragraph, the networked device will evaluate the packet against rule 1, then (if the packet does not match rule 1) rule 2, then (if the packet does not match rule 2) rule 4, then (if the packet does not match rule 4) rule 6, and finally (if the packet does not match rule 6) rule 7 (which is the default rule in the ACL shown in Table 2). As shown in Table 2, the default rule may be a generic "drop all" rule that contains no matching criteria at all (i.e., a rule in which all fields are "any" or wildcards), and which therefore drops all packets by default (i.e., unless the packet matches one of the higher priority rules). In some embodiments, identifying applicable rules and ignoring inapplicable rules may be performed before evaluating the packet against any of the rules. In other embodiments, this is not required.

[0065] More specifically, it should be noted that in some cases (e.g., using TCAM), the procedures of operations 330-340 may be performed in parallel; that is, determining whether a rule is applicable based on the vehicle state may be performed in parallel with evaluating the packet against other fields of the rule. Thus, while some embodiments perform discrete procedures with respect to identifying applicable filtering rules (block 330), ignoring inapplicable rules (block 335), and evaluating the packet against applicable rules (block 340), in other embodiments, the procedures for each of those operations may be performed in parallel and / or as part of a single operation.

[0066] Thus, according to one set of embodiments, the networking device determines one or more management actions to be performed on the packet (block 345), and at block 350, method 300 includes performing the determined management actions. Some embodiments make this determination and / or perform the determined management actions at line rate, using techniques such as those described herein.

[0067] In some embodiments, the determination of the management action to be taken is based on the action field of the rule to which the packet matches, as determined by evaluating the packet against one or more of the applicable rules, as described above. Thus, for example, if the packet in the above example is not from source IP address 140.192.37.*, and the packet includes a SOME / IP packet, then it will match rule 4; the action field of the rule specifies "allow", so the networking device will determine that the management action to be taken will be to allow the packet to be delivered to its intended destination. If the packet is not from source IP address 140.192.37.*, and is not a SOME / IP packet, but is directed to a destination IP of address 140.192.37.40, then the packet will match rule 6, for which the specified actions are allow and listen. In this case, the networking device will determine that even if the packet is allowed to be delivered to its specified destination, the packet should be filtered in some manner (i.e., listen). However, if the same packet is directed to any other destination IP address, then the packet will match rule 7 (the default rule), for which the action is "drop". In this case, the networking device will determine that the packet should be dropped or blocked.

[0068] Method 300 may further include executing the determined management action (block 350). Any number of management actions may be taken within the scope of various embodiments. Figure 3 As illustrated, the most basic management action to be performed is typically to prevent a packet from being delivered to its intended destination (block 355) or to allow a packet to be delivered to its intended destination (block 360). However, in addition to those two basic actions, other actions are available. For example, if a packet is not delivered to its intended destination (i.e., the destination address originally indicated in the header of the packet), then the packet may be dropped (block 365) (i.e., discarded entirely), or it may be redirected to a new destination address (block 370), such as for further analysis, or because a matching applicable rule indicates that the new destination address is more appropriate for some reason.

[0069] Similarly, if the packet is allowed to be delivered, the method 300 may also include other actions. For example, the networking device may intercept the packet for further inspection (block 375), or otherwise allow the packet to be intercepted as it is delivered, may modify one or more fields of the packet (block 380), such as a virtual local area network (VLAN) tag of the packet, a quality of service (QoS) marking of the packet, and / or the like, and / or may meter the packet (and / or subsequent related packets) (block 385), such as to enforce a specified data rate limit.

[0070] in conclusion

[0071] As described above, various embodiments provide novel tools and techniques for packet filtering. Such tools and techniques are particularly advantageous in vehicle networks (which are typically characterized by networked devices with limited computing resources), but various embodiments can provide advantages in a variety of networking situations and are not limited in any way to vehicle implementations.

[0072] In the foregoing description, for the purpose of explanation, numerous details are set forth to provide a thorough understanding of the described embodiments. However, it will be apparent to those skilled in the art that other embodiments may be practiced without some of these details. In other examples, for clarity, structures and devices are shown in block diagram form without full details. Several embodiments are described herein, and although various features are attributed to different embodiments, it should be understood that features described with respect to one embodiment may also be combined with other embodiments. However, for the same reasons, it should not be considered that a single or multiple features of any described embodiment are necessary for every embodiment of the present invention, as other embodiments of the present invention may omit such features.

[0073] Thus, the foregoing description provides an illustration and description of some features and aspects of various embodiments, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Those skilled in the art will recognize that modifications may be made in light of the above disclosure, or may be obtained from the practice of the implementation scheme, all of which may fall within the scope of the various embodiments. For example, the methods and processes described herein may be implemented using instructions that may be encoded as software that may be executed by one or more processors, hardware and / or firmware circuitry, custom integrated circuits (ICs), programmable logic, and / or any combination thereof. As used herein, the term "logic" used to perform an operation may include any or all of these components.

[0074] In addition, although the various methods and processes described herein may be described with respect to specific structural and / or functional components for ease of description, the methods provided by the various embodiments are not limited to any specific structural and / or functional architecture, but may be implemented in any suitable hardware configuration. Similarly, although some functionality is attributed to one or more system components, unless the context indicates otherwise, according to several embodiments, this functionality may be distributed among various other system components.

[0075] Furthermore, although the procedures of the methods and processes described herein are described in a particular order for ease of description, various procedures may be reordered, added, and / or omitted according to various embodiments unless the context indicates otherwise. Furthermore, procedures described with respect to one method or process may be incorporated into other described methods or processes; similarly, system components described according to a particular structural architecture and / or with respect to one system may be organized in alternative structural architectures and / or incorporated into other described systems. Thus, although the embodiments are described with or without certain features for ease of description and illustration of aspects of the various embodiments, various components and / or features described herein with respect to particular embodiments may be replaced, added, and / or subtracted from other described embodiments unless the context indicates otherwise.

[0076] As used herein, the term "component" is intended to be interpreted broadly as hardware, firmware, or a combination of hardware and software. It is apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, and / or a combination of hardware and software. Unless specifically described in the accompanying claims, the actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, when the operation and behavior of the systems and / or methods are described herein without reference to specific software code, those skilled in the art will understand that software and hardware may be used to implement the systems and / or methods based on the description herein.

[0077] In the present disclosure, when an element is referred to herein as being "connected" or "coupled" to another element, it is understood that an element may be directly connected to another element, or that there may be an intermediary element between the elements. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, it is understood that there are no intermediary elements in the "direct" connection between the elements. However, the presence of a direct connection does not exclude other connections in which there may be intermediary elements. Similarly, although the methods and processes described herein may be described in a particular order for ease of description, it is understood that, unless otherwise indicated by the context, an intermediary process may occur before and / or after any portion of the described process, and as described above, the described procedures may be reordered, added, and / or omitted according to various embodiments.

[0078] In this application, unless otherwise specifically indicated, the use of the singular includes the plural, and unless otherwise indicated, the use of the term "and" means "and / or". In addition, as used herein, the term "or" is intended to be inclusive when used in a series, and may also be used interchangeably with "and / or" unless otherwise expressly stated (for example, if used in combination with "any one" or "only one of"). In addition, the use of the term "including" and other forms such as "includes" and "included" should be considered non-exclusive. In addition, terms such as "element" or "component" encompass elements and components that include one unit and elements and components that include more than one unit, unless otherwise specifically stated. As used herein, the phrase "at least one" preceding a series of items using the terms "and" or "or" to separate any of the items modifies the list as a whole, rather than each member of the list (i.e., each item). The phrase "at least one of..." does not require selection of at least one of each of the listed items; rather, the phrase allows for a meaning that includes at least one of any of the items and / or at least one of any combination of items. By way of example, the phrase "at least one of A, B, and C" or "at least one of A, B, or C" each refers to only A, only B, or only C; and / or any combination of A, B, and C. Where selection of "at least one of each of A, B, C" or, alternatively, "at least one of A, at least one of B, and at least one of C" is desired, it is expressly described as such.

[0079] Unless otherwise indicated, all numbers used herein to represent quantity, size, etc. should be understood to be modified by the term "about" in all cases. As used herein, the article "a, an" is intended to include one or more items, and can be used interchangeably with "one or more". Similarly, as used herein, the article "said" is intended to include one or more items quoted in conjunction with the article "said", and can be used interchangeably with "said one or more". As used herein, the term "group" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, and / or the like), and can be used interchangeably with "one or more". In the case of wishing only one item, the phrase "only one" or similar language is used. In addition, as used herein, the term "has", "have" and "having" or the like are intended to be open terms. In addition, unless otherwise expressly stated, the phrase "based on" is intended to mean "based at least in part on". In the foregoing description, satisfying a threshold may refer to a value being greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, and / or the like, depending on the context.

[0080] Although specific combinations of features are described in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of the various embodiments. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed in the specification. Therefore, although each dependent claim listed herewith may directly depend on only one claim, the disclosure of the various embodiments includes each dependent claim in combination with every other claim of the claim group. No element, act, or instruction used herein should be interpreted as critical or essential unless explicitly described as such.

Claims

1. A networking device in a vehicle, the networking device comprising: processor; Ternary Content Addressable Memory TCAM; circuitry to receive, at line rate, Ethernet packets including Internet Protocol (IP) packets, the Ethernet packets identifying a source of the Ethernet packets and a destination of the Ethernet packets; circuitry for accessing a configuration register of the carrier to identify a state of the carrier; Circuitry for accessing in the TCAM a static access control list (ACL) comprising a plurality of filter rules, wherein each of the plurality of filter rules: has priority; and including a field identifying one or more of a plurality of possible states of the vehicle; circuitry for comparing the identified state of the vehicle to the field of each filter rule that identifies one or more of the plurality of possible states of the vehicle to identify one or more of the plurality of filter rules as applicable based on the state of the vehicle; circuitry for evaluating the Ethernet packet against at least one of the one or more applicable filter rules in an order of priority of the one or more applicable filter rules; circuitry to determine one or more management actions to perform on the packet at the line rate and based at least in part on the evaluation of the Ethernet packet against at least one of the one or more applicable filtering rules; and Circuitry for performing the one or more management actions on the group.

2. A device comprising: logic to receive an Ethernet packet at a line rate, the Ethernet packet identifying a source of the Ethernet packet and a destination of the Ethernet packet; Logic to identify the state of the vehicle; logic for determining one or more management actions to take with respect to the group based at least in part on the state of the vehicle; and Logic is used to perform the one or more management actions on the group.

3. The device of claim 2, wherein the carrier comprises the device.

4. The device according to claim 2, further comprising: Ternary Content Addressable Memory TCAM.

5. The apparatus of claim 4, further comprising logic to store an access control list (ACL) comprising a plurality of filter rules in the TCAM.

6. The apparatus of claim 5, wherein determining one or more management actions to be taken on the group comprises: The Ethernet packet is evaluated against at least one of the filter rules.

7. A device according to claim 6, wherein each of the multiple filtering rules has a priority, and wherein evaluating the Ethernet packet against at least one of the filtering rules includes evaluating the Ethernet packet against the at least one of the filtering rules according to the priority of each of the at least one filtering rule.

8. The apparatus of claim 6, wherein determining whether the Ethernet packet should be filtered further comprises: identifying one or more of the plurality of filtering rules as applicable based on the status of the vehicle; and All of the filter rules other than the identified one or more applicable filter rules are disregarded when evaluating the Ethernet packet.

9. The apparatus of claim 8, wherein each of the plurality of filter rules comprises a field identifying one or more of a plurality of possible states of the vehicle.

10. An apparatus according to claim 9, wherein the multiple possible states of the vehicle include one or more of the following: vehicle gear state, vehicle engine state, vehicle position, vehicle speed, vehicle acceleration, vehicle direction, the identity of the driver or passengers in the vehicle, objects close to the vehicle and their relative positions, vehicle maintenance mode state, activation of maintenance required notification, fuel level, battery charge level, whether the vehicle is in autonomous driving mode; whether the vehicle is in advanced driver assistance mode.

11. The apparatus of claim 9, wherein identifying one or more of the plurality of filtering rules as applicable based on the status of the vehicle comprises: The identified state of the vehicle is compared to the field of each filter rule that identifies one or more of the plurality of possible states of the vehicle.

12. The device of claim 8, wherein disregarding all of the filter rules other than the identified one or more applicable filter rules when evaluating the Ethernet packet occurs before evaluating the Ethernet packet against any of the filter rules.

13. The apparatus according to claim 8, further comprising: Logic to mask the field identifying one of the plurality of possible states of the vehicle in one or more of the plurality of filter rules to identify at least two of the plurality of possible states of the vehicle.

14. An apparatus according to claim 2, wherein information identifying the status of the vehicle is separated from the Ethernet packet.

15. The apparatus of claim 2, wherein identifying the state of the vehicle comprises accessing a configuration register storing the information identifying the state of the vehicle.

16. The device of claim 2, wherein the logic comprises at least one of hardware instructions or firmware instructions executable by hardware independent of a processor.

17. The device of claim 2, wherein the device is a system-on-chip (SoC).

18. The apparatus of claim 2, wherein the one or more management actions comprise one of the following actions: preventing delivery of the Ethernet packet to the identified destination based at least in part on determining that the Ethernet packet should be filtered; or Based at least in part on not determining that the Ethernet packet should be filtered, allowing the Ethernet packet to be delivered to the identified destination.

19. The apparatus of claim 18, wherein the one or more management actions further comprise at least one of the following actions: redirecting the packet for further processing and inspection; allowing the packet to be intercepted for further inspection while allowing the packet to be delivered to the identified destination; modifying one or more fields of the packet and delivering the packet with the one or more modified fields; or The packet and a plurality of subsequent packets are metered to enforce a specified data rate limit.

20. A vehicle comprising a networking device, the networking device comprising: logic to receive an Ethernet packet at a line rate, the Ethernet packet identifying a source of the Ethernet packet and a destination of the Ethernet packet; Logic to identify the state of the vehicle; logic for determining one or more management actions to take with respect to the group based at least in part on the state of the vehicle; and Logic is used to perform the one or more management actions on the group.

Images