System and method for processing communication packets

Abstract

A communication packet processing system and method are provided. Embodiments of the present invention are intended to reduce system load and improve real-time processing performance by reflecting causal relationships between events during the processing of communication packets and proactively determining a processing policy at the hardware level.

Description

Technology Field

[0001] Embodiments of the present invention relate to a technique for determining a processing policy for communication packets based on a causal chain on a hardware packet processing pipeline in a resource-constrained environment.

[0002] This invention is the result of the project “IRIS Project Unique Number (RS-2023-KT226444)”. Background Technology

[0004] Generally, in a network environment, the processing of communication packets is structured such that received packets are transmitted to the system processing unit, after which the CPU or software stack determines the processing method or policy. In this approach, the analysis, status determination, and policy decision of communication packets are primarily performed by software; in particular, the processing policy for communication packets is often determined based on statically defined conditions, such as the network protocol stack, Quality of Service (QoS) policies, and traffic control logic.

[0005] In addition, while some systems provide hardware-based packet filtering or classification functions, these technologies are mostly limited to simple comparison of packet headers or restricted rule-based processing. As a result, conventional technologies have limitations in establishing processing policies that comprehensively consider multiple packet flows, temporal relationships between events, or system states.

[0006] In particular, in resource-constrained processor environments such as automotive network environments, the real-time processing and stability of communication packets are becoming increasingly important. For example, systems such as automotive zonal controllers must satisfy real-time communication requirements, such as Time Sensitive Networking (TSN), within limited computational resources, while simultaneously processing various sensor and control signals reliably.

[0007] However, conventional technology having a structure in which all communication packets are processed software-wise in the system processing unit has the following problems.

[0008] First, a problem of load concentration on the system processing unit occurs.

[0009] In a structure where packet processing policies are determined by the system processing unit, all communication packets must pass through the CPU, so when traffic increases or complex processing conditions are required, the load on the system processing unit increases rapidly.

[0010] Second, real-time processing performance may be degraded.

[0011] In software-based processing structures, processing delays may occur during packet analysis, state determination, and policy decision-making, which can lead to network performance degradation.

[0012] Third, there is a limitation in that it is difficult to determine processing policies that reflect the causal relationships between events.

[0013] In conventional technology, processing policies are determined primarily based on single packets or individual conditions, making it difficult to make sophisticated judgments that reflect the temporal sequence of multiple events or the flow of state changes.

[0014] Fourth, the application of dynamic policies reflecting the system state is limited.

[0015] System state information, such as CPU load, memory status, interrupt occurrences, and network traffic status, is not sufficiently reflected in packet processing policies, making it difficult to respond adaptively to various operating situations.

[0016] Fifth, the hardware-based pre-processing structure is inadequate.

[0017] Due to the lack of a structure to determine processing policies at a stage prior to packet delivery to the system processing unit, a problem arises where even unnecessary or inefficient packets are delivered to the system processing unit. Prior art literature

[0019] Korean Published Patent Application No. 10-2023-0173706 (December 27, 2023) The problem to be solved

[0020] The embodiments of the present invention are intended to reduce system load and improve real-time processing performance by reflecting causal relationships between events during the processing of communication packets and proactively determining a processing policy at the hardware level. means of solving the problem

[0022] According to one embodiment, a communication packet processing system is provided, comprising: a packet parser unit that generates packet observation information from a communication packet; a state management unit that generates a state transition result of a packet flow according to time flow based on the packet observation information; a system state collection unit that collects system state information related to the processing of the communication packet; an event processing unit that generates events based on at least one of the packet observation information, the state transition result, and the system state information, selects a plurality of events included in a set same judgment time window among the events, sorts the selected plurality of events according to a reference time representing the events, and generates a causal chain when the sorted plurality of events satisfy both a temporal precedence relationship and a predefined order constraint condition; a policy decision unit that determines a processing policy for the communication packet according to the causal chain; and a system processing unit that performs processing for the communication packet according to the processing policy.

[0023] The above packet parser, the above state management, the above system state collection, the above event processing, and the above policy decision unit are a hardware packet processing pipeline that performs control operations for determining the processing policy based on metadata regarding the communication packet before the communication packet is transmitted to the system processing unit, and the original data regarding the communication packet is transmitted simultaneously to the system processing unit and the hardware packet processing pipeline, wherein the system processing unit receives the original data regarding the communication packet through a separate path distinct from the hardware packet processing pipeline and performs processing on the communication packet according to the processing policy.

[0024] The above packet observation information includes identification information, type information, time information, and characteristic information of the communication packet, and the state management unit can generate the state transition result by updating the existing state transition result based on at least one of the identification information, type information, time information, and characteristic information of the communication packet whenever the communication packet is input, thereby reflecting the change in packet flow or the accumulated state over time.

[0025] The above system status information may include one or more of CPU load status, memory status, interrupt status, and network status.

[0026] The above event processing unit generates an event by combining at least one of the packet observation information, the state transition result, and the system state information, and inserts the reference time into the event, wherein the reference time may be time information generated based on at least one of the arrival time of the communication packet that caused the generation of the event, the occurrence time of the state transition result, and the change time of the system state.

[0027] The above same judgment time window is a temporal range for determining causal relationships between the above events, and the event processing unit can select the plurality of events by excluding events among the above events that are not included in the above same judgment time window.

[0028] The above temporal sequence is defined as a relationship in which the reference time of a preceding event is earlier than the reference time of a subsequent event based on the reference time of each event, and the above sequence constraint is composed of a plurality of rule sets including a plurality of event sequence patterns, and the event processing unit can generate the causal chain only when the aligned plurality of events satisfy the above temporal sequence and match with an event sequence pattern for at least one of the plurality of rule sets.

[0029] The event processing unit dynamically selects one of the plurality of rule sets according to the system state information to generate the causal chain, and each rule set may include an application condition corresponding to the system state information, a policy objective for a processing policy corresponding to the causal chain, and a processing strategy.

[0030] The above processing policy may include one or more of allowing processing of the communication packet, restricting processing, delaying processing, merging processing, and adjusting priority.

[0031] According to another embodiment, a method for processing communication packets is provided, comprising: a step of generating packet observation information from a communication packet in a packet parser; a step of generating a state transition result of a packet flow according to time flow in a state management unit based on the packet observation information; a step of collecting system state information related to the processing of the communication packet in a system state collection unit; a step of generating events based on at least one of the packet observation information, the state transition result, and the system state information in an event processing unit; a step of selecting a plurality of events included in a set same judgment time window among the events in the event processing unit; a step of sorting the selected plurality of events according to a reference time representing the events in the event processing unit; a step of generating a causal chain in the event processing unit when the sorted plurality of events satisfy both a temporal precedence relationship and a predefined order constraint condition; a step of determining a processing policy for the communication packet according to the causal chain in a policy decision unit; and a step of performing processing on the communication packet according to the processing policy in a system processing unit.

[0032] The above packet parser, the above state management, the above system state collection, the above event processing, and the above policy decision unit are a hardware packet processing pipeline that performs control operations for determining the processing policy based on metadata regarding the communication packet before the communication packet is transmitted to the system processing unit, and the original data regarding the communication packet is transmitted simultaneously to the system processing unit and the hardware packet processing pipeline, and the step of performing processing on the communication packet may receive the original data regarding the communication packet through a separate path distinguished from the hardware packet processing pipeline and perform processing on the communication packet according to the processing policy.

[0033] The above packet observation information includes identification information, type information, time information, and characteristic information of the communication packet, and the step of generating the state transition result may generate the state transition result by updating the existing state transition result based on at least one of the identification information, type information, time information, and characteristic information of the communication packet whenever the communication packet is input, thereby reflecting a change in packet flow or an accumulated state over time.

[0034] The above system status information may include one or more of CPU load status, memory status, interrupt status, and network status.

[0035] The step of generating the above events involves generating an event by combining at least one of the packet observation information, the state transition result, and the system state information, wherein the reference time is inserted into the event, and the reference time may be time information generated based on at least one of the arrival time of the communication packet that caused the generation of the event, the occurrence time of the state transition result, and the change time of the system state.

[0036] The above identical judgment time window is a temporal range for determining the causal relationship between the above events, and the step of selecting the plurality of events may select the plurality of events by excluding events among the above events that are not included in the identical judgment time window.

[0037] The above temporal order is defined as a relationship in which the reference time of a preceding event is earlier than the reference time of a subsequent event based on the reference time of each event, and the above order constraint is composed of a plurality of rule sets including a plurality of event sequence patterns, and the step of generating the above causal chain can generate the above causal chain only when the aligned plurality of events satisfy the above temporal order and match with an event sequence pattern for at least one of the plurality of rule sets.

[0038] The step of generating the above causal chain involves dynamically selecting one of the plurality of rule sets according to the system state information to generate the above causal chain, and each rule set may include an application condition corresponding to the system state information, a policy objective for a processing policy corresponding to the above causal chain, and a processing strategy.

[0039] The above processing policy may include one or more of allowing processing of the communication packet, restricting processing, delaying processing, merging processing, and adjusting priority. Effects of the invention

[0041] According to embodiments of the present invention, by generating an event based on packet observation information, state transition results, and system state information at a stage prior to the transmission of a communication packet to a system processing unit, and determining a processing policy based on a causal chain satisfying temporal precedence and sequence constraints between events, the following effects can be obtained.

[0042] First, by proactively determining the processing policy for communication packets in the hardware packet processing pipeline, the load on the system processing unit can be reduced.

[0043] Second, by utilizing the reference time of events to reflect the actual order of occurrence between events, it is possible to analyze accurate causal relationships based on temporal sequence.

[0044] Third, by applying the same judgment time window to select only temporally relevant events, the accuracy of causal chain generation can be improved.

[0045] Fourth, by applying order constraints using a rule set composed of multiple event sequence patterns, a more sophisticated packet processing policy can be established compared to simple condition-based processing.

[0046] Fifth, by dynamically selecting a rule set based on system status information, the processing policy can be flexibly changed even for the same set of events, allowing for adaptive response to various operating environments.

[0047] Sixth, various processing policies such as allowing, restricting, delaying, merging, and prioritizing communication packet processing can be applied, thereby simultaneously improving system stability and processing efficiency. Brief explanation of the drawing

[0049] FIG. 1 is a block diagram showing the detailed configuration of a communication packet processing system according to an embodiment of the present invention. FIG. 2 is an example showing the operation flow in a hardware packet processing pipeline according to an embodiment of the present invention. FIG. 3 is a flowchart illustrating a communication packet processing method according to an embodiment of the present invention. FIG. 4 is a flowchart for explaining step S114 according to an embodiment of the present invention. FIG. 5 is an example of the application of the same judgment time window according to an embodiment of the present invention. FIG. 6 is a flowchart illustrating step S116 according to an embodiment of the present invention. FIG. 7 is an example of determining whether the temporal sequence relationship is satisfied according to an embodiment of the present invention. FIG. 8 is an example of determining whether a sequence constraint is satisfied according to an embodiment of the present invention. FIG. 9 is an example illustrating a process in which a causal chain and a processing policy change dynamically based on system state information according to an embodiment of the present invention. FIG. 10 is an example for explaining a process in which a causal chain and a processing policy change dynamically based on system state information according to an embodiment of the present invention. FIG. 11 is an example illustrating a process in which a causal chain and a processing policy change dynamically based on system state information according to an embodiment of the present invention. FIG. 12 is a block diagram illustrating a computing environment including a computing device suitable for use in exemplary embodiments. Specific details for implementing the invention

[0050] Hereinafter, specific embodiments of the present invention will be described with reference to the drawings. The following detailed description is provided to facilitate a comprehensive understanding of the methods, apparatuses, and / or systems described herein. However, this is merely illustrative and the present invention is not limited thereto.

[0051] In describing the embodiments of the present invention, detailed descriptions of known technologies related to the present invention are omitted if it is determined that such detailed descriptions may unnecessarily obscure the essence of the present invention. Furthermore, the terms described below are defined in consideration of their functions within the present invention, and these may vary depending on the intentions or practices of the user or operator. Therefore, such definitions should be based on the content throughout this specification. Terms used in the detailed description are intended merely to describe the embodiments of the present invention and should not be limiting in any way. Unless explicitly stated otherwise, expressions in the singular form include the meaning of the plural form. In this description, expressions such as "include" or "comprise" are intended to refer to certain characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof, and should not be interpreted to exclude the existence or possibility of one or more other characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof other than those described.

[0053] FIG. 1 is a block diagram showing the detailed configuration of a communication packet processing system (100) according to an embodiment of the present invention. As shown in FIG. 1, the communication packet processing system (100) according to an embodiment of the present invention includes a packet input unit (110), a packet parser unit (120), a state management unit (130), a system state collection unit (140), an event processing unit (150), a policy decision unit (160), and a system processing unit (170).

[0054] The packet input unit (110) is an interface module that receives a communication packet. In the embodiments, a communication packet refers to a unit of data transmitted and received through a network, which includes a data structure comprising a header and a payload, and may include various forms such as an IP packet, an Ethernet frame, or a transport layer packet. Such a communication packet is used as a basic unit for data transmission in a network environment.

[0055] The packet input unit (110) can be implemented in various forms, such as a network interface, a communication port, or a bus interface, and can receive communication packets transmitted in a wired or wireless communication environment. The packet input unit (110) may include, for example, an Ethernet interface, a CAN interface, or other data communication interfaces, but is not limited thereto.

[0056] The packet input unit (110) can simultaneously transmit the original data of the communication packet to the system processing unit (170) and the hardware packet processing pipeline. For example, the packet input unit (110) can transmit the original data of the communication packet to the system processing unit (170) and the packet parser unit (120) of the hardware packet processing pipeline, respectively. At this time, the packet input unit (110) can transmit the original data of the communication packet to the system processing unit (170) through a separate path distinct from the hardware packet processing pipeline. That is, the communication packet is transmitted to the system processing unit (170) and the hardware packet processing pipeline, respectively, but the transmission paths may be different from each other.

[0057] As described below, the hardware packet processing pipeline can determine a processing policy for the communication packet and transmit it to the system processing unit (170) before processing the original data of the communication packet at the system processing unit (170).

[0058] In the embodiments thereof, the hardware packet processing pipeline refers to a processing structure in which a plurality of hardware-based processing blocks are connected in a pipeline form to perform various control operations for determining a processing policy based on metadata regarding the communication packet, such as analyzing information related to the communication packet, determining the state, and determining the processing policy, before the communication packet is transmitted to the system processing unit (170). It may include a packet parser (120), a state management unit (130), a system state collection unit (140), an event processing unit (150), and a policy determination unit (160) to be described later. Here, metadata regarding the communication packet refers to information that is distinct from the original data of the communication packet, and refers to additional information extracted from the communication packet or generated during the processing of the communication packet. For example, metadata regarding the communication packet may include identification information, type information, time information, characteristic information, state transition results according to packet flow, system state information, etc., of the communication packet, and may be expressed as follows. The above metadata can be generated and managed separately without affecting the original data of the communication packet, and can be utilized as input data for event generation, causal chain formation, and processing policy determination within the hardware packet processing pipeline. Furthermore, the metadata defined in this way serves as control information separated from the data content of the communication packet itself, and can play a role in improving the efficiency and flexibility of communication packet processing. In this way, the hardware packet processing pipeline can operate to determine the processing policy of the communication packet by analyzing the communication packet before processing it in the system processing unit (170), instead of processing the communication packet.

[0060] <Example of metadata regarding communication packets>

[0061] source IP: 192.168.0.10

[0062] destination port: 8080

[0063] packet type: control packet

[0064] arrival time: 100μs

[0065] traffic state: threshold exceeded

[0066] system state: CPU overload

[0068] The components within these hardware packet processing pipelines are distinct from the system processing unit (170), such as a CPU or software stack, and can be implemented with dedicated hardware circuits or logic, such as an Application Specific Integrated Circuit (ASIC) or a Field-Programmable Gate Array (FPGA). By predetermining a processing policy for the communication packet before it is delivered to the system processing unit (170), the hardware packet processing pipeline can improve the real-time performance and stability of the communication packet processing system (100) by reducing the load on the system processing unit (170) and minimizing processing delays. Below, we will examine the detailed configuration of the hardware packet processing pipeline in more detail.

[0069] The packet parser (120) generates packet observation information from a communication packet input through the packet input unit (110). In the present embodiments, the packet observation information is information extracted from the communication packet or generated during the reception process of the communication packet, and refers to data indicating the attributes and state of the communication packet. Specifically, it may include identification information, type information, time information, and characteristic information of the communication packet. Here, the identification information of the communication packet may be, for example, the source address, destination address, port number, etc. of the communication packet. In addition, the type information of the communication packet may be, for example, whether it is a control packet, whether it is a data packet, protocol type, etc. In addition, the time information of the communication packet may include a timestamp regarding the arrival time (or reception time) of the communication packet. In addition, the characteristic information of the communication packet may be the size of the communication packet, priority information, QoS-related information, etc.

[0070] The packet parser (120) can, for example, parse the header of a communication packet according to hardware logic to generate packet observation information as follows.

[0072] <Example of Packet Observation Information>

[0073] source IP: 192.168.0.10

[0074] destination port: 8080

[0075] arrival time: 100 μs

[0076] packet type: control packet

[0078] This packet observation information can be stored in a hardware register or an internal buffer of the hardware packet processing pipeline and then transmitted to the state management unit (130) and the event processing unit (150), respectively. In this way, the packet parser unit (120) can extract the characteristics of the packet hardware-wise without software intervention and provide them as input for the event generation described later.

[0079] The state management unit (130) generates a state transition result of the packet flow over time based on packet observation information. In the embodiments, the state transition result is information that reflects the state of a communication packet or packet flow that changes over time based on packet observation information, and may include, for example, a traffic change state such as an increase or decrease in the communication packet flow, a state of change in the number of communication packets or traffic density within a certain time interval, whether a specific threshold related to the communication packet or packet flow is reached, and whether a specific condition related to the communication packet or packet flow occurs or is repeated.

[0080] The state management unit (130) can generate a state transition result by updating an existing state transition result based on at least one of the identification information, type information, time information, and characteristic information of the communication packet whenever a communication packet is input, reflecting a change in packet flow or an accumulated state over time. For example, when a new communication packet is input, the state management unit (130) can generate a state transition result by updating an existing state transition result as follows.

[0082] <Example of State Transition Result Generation>

[0083] Existing state transition result: Number of packets to specific port = 99

[0084] Currently input communication packet: Communication packet on the same port

[0085] State transition result: Number of packets to specific port = 100

[0087] In the above example, the state transition result can be expressed as “reaching the traffic threshold for a specific port,” “entering a traffic increase state,” etc.

[0088] These state transition results are not merely information about individual communication packets, but rather information generated by reflecting the cumulative or temporal relationships of multiple communication packets, which can represent the continuity and change patterns of the packet flow. Furthermore, in the event generation process described later, the state transition results can be combined with packet observation information and system state information to be utilized as elements constituting an event.

[0089] The system state collection unit (140) collects system state information related to the processing of communication packets. In the present embodiments, the system state information is external environment information distinct from the attributes of the communication packet itself, and may indicate the current operating state related to the processing of communication packets. Such system state information may include, for example, one or more of CPU load state, memory state, interrupt state, and network state, and may be expressed as follows.

[0091] <Example of System Status Information>

[0092] CPU usage 85% → “CPU Overload”

[0093] Memory usage 70% → “Insufficient memory”

[0094] Input queue occupancy 95% → “Input queue full”

[0096] The system state collection unit (140) can, for example, monitor system state information in hardware or collect it in real time through performance counters, status registers, internal signals, etc. The system state collection unit (140) can transmit the system state information collected in this manner to the event processing unit (150), thereby allowing the system state information to be reflected in event generation along with packet observation information and state transition results. Through this, even for the same communication packet, different events may be generated depending on the system state information, or the causal chain and processing policy described later may be dynamically determined.

[0097] The event processing unit (150) generates events based on at least one of packet observation information, state transition results and system state information, and generates a causal chain by analyzing the temporal sequence of the generated events and predefined order constraints.

[0098] First, the event processing unit (150) can generate events based on at least one of packet observation information, state transition results, and system state information. In the present embodiments, the event is unit data reflecting the attributes of the communication packet, the state change of the packet flow, and the system state, and can be utilized as a basic data unit for determining the generation of the causal chain and the processing policy thereafter. Such events may consist of, for example, a first event based on packet observation information, a second event based on state transition results, a third event based on system state, and a fourth event based on information combining at least two of packet observation information, state transition results, and system state information, and can be expressed as follows.

[0100] <Example of the 1st Event>

[0101] Received a specific type of communication packet → “Control packet reception event” or “Specific port access event”

[0102] <Example of the 2nd Event>

[0103] The number of communication packets for a specific port exceeds a threshold within a certain time interval → “Traffic increase event” or “Threshold reached event”

[0104] <Example of the 3rd Event>

[0105] CPU usage exceeds threshold → “CPU Overload Event”

[0106] Input queue occupancy exceeds threshold → “Input queue saturation event”

[0107] <Example of the 4th Event>

[0108] Received control packet simultaneously with traffic surge and CPU overload conditions → “Control packet + Traffic surge + CPU overload event”

[0110] The event processing unit (150) can determine whether to generate an event by considering packet observation information, state transition results, and system state information at each input time of a communication packet, and then generate one or more events when specific conditions are satisfied. In addition, the event processing unit (150) can generate events using various hardware methods, such as combination logic-based logical operations, lookup table-based mapping methods, and event structure registers, when generating events by considering packet observation information, state transition results, and system state information.

[0111] At this time, the event processing unit (150) may generate an event by combining at least one of packet observation information, state transition result, and system state information, and may insert a reference time representing the event into the event. In the present embodiments, the reference time is a reference time distinct from the time of event generation and may be time information indicating the time when the event occurred. That is, such a reference time may be time information generated based on at least one of the arrival time of the communication packet that caused the event generation, the time of occurrence of the state transition result, and the time of change of the system state.

[0112] As an example, assuming that packet observation information, state transition result and system state information are as follows, the event processing unit (150) can generate the following event (E1).

[0114] <Event Creation Example>

[0115] Packet observation information

[0116] packet type: control

[0117] destination port: 8080

[0118] arrival time: 100 μs

[0119] State transition result

[0120] Exceeding traffic threshold on a specific port

[0121] System status information

[0122] CPU usage 85%

[0123] Event E1

[0124] Event Type: control packet + high load condition

[0125] Related Status: Traffic Threshold Reached + CPU Overload

[0126] Reference time: 100 μs

[0128] In the above example, the reference time can be the arrival time of the communication packet.

[0129] In another example, the event processing unit (150) can set the time of occurrence of the state transition result, that is, the time when the traffic increase state occurs, as the reference time during the process of generating the “traffic increase event”.

[0130] In another example, the event processing unit (150) can set the point of change in the system state, that is, the point of time when the CPU load state exceeds a threshold, as the reference time during the process of generating a “CPU overload event.”

[0131] Accordingly, the reference time may be set differently depending on which element among packet observation information constituting the event, state transition results, or system state information is based on which event was generated. That is, the reference time may be set differently depending on the characteristics of the event, and may be selectively set based on at least one of the arrival time of the communication packet, the occurrence time of the state transition result, and the change time of the system state.

[0132] The events generated in this way can be stored in the internal buffers, event queue structures, etc., of the hardware packet processing pipeline.

[0133] Next, the event processing unit (150) selects a plurality of events among the generated events that are included in the same judgment time window set. In the present embodiments, the same judgment time window refers to a temporal range for determining the causal relationship between events.

[0134] As an example, the event processing unit (150) can determine whether an event is included in the same judgment time window based on the reference time included in each event. At this time, the same judgment time window may be a preset temporal range (or interval), but may also be dynamically set according to system status information or traffic conditions as needed.

[0135] The event processing unit (150) can select events that are included in the same judgment time window among a plurality of events and exclude events that are not included in the same judgment time window. In this case, it is possible to prevent events that are not temporally related from being included in the causal relationship analysis. For example, assuming that among a plurality of events the reference time of the first event is 100μs, the reference time of the second event is 120μs, and the reference time of the third event is 300μs, and the same judgment time window is set to 100μs to 200μs, the event processing unit (150) can select the first and second events because they are included in the same judgment time window, while excluding the third event because it is not included in the same judgment time window.

[0136] In this way, the event processing unit (150) can form a set of temporally related events through an event selection process based on the same judgment time window, and can improve the accuracy of event alignment and causal chain generation performed in subsequent steps.

[0137] Next, the event processing unit (150) sorts the selected multiple events according to a reference time. As described above, the reference time may be time information generated based on at least one of the arrival time of the communication packet that caused the event, the time of occurrence of the state transition result, and the time of change of the system state.

[0138] Generally, events may be generated in different processing paths or processing stages, and processing delays may be included at the time of event generation. Therefore, if events are sorted by simply comparing them based on the time of event generation, the events may be arranged in an order different from the actual order of occurrence. Accordingly, the event processing unit (150) can eliminate time distortion due to processing delays and reflect the actual order of occurrence between events by sorting the events based on the reference time included in each event.

[0139] As an example, the event processing unit (150) can sort multiple events in ascending order according to the magnitude of the reference time, thereby determining the temporal relationship between the preceding event and the succeeding event. For example, assuming that the time of creation of the first event (E1) is 110 μs and the reference time is 100 μs, and the time of creation of the second event (E2) is 135 μs and the reference time is 95 μs, if sorted based on the time of creation, it may be determined that the second event occurred later, but if sorted based on the reference time, it may be determined that the second event occurred before the first event.

[0141] <Example of event sorting based on reference time>

[0142] E1: Event occurrence time 100μs, processing delay 10μs, event generation time 110μs

[0143] → Reference time 100μs

[0144] E2: Event occurrence time 95μs, processing delay 40μs, event generation time 135μs

[0145] → Reference time 95μs

[0146] Event alignment: E2, E1

[0148] In this way, the event processing unit (150) can accurately reflect the actual temporal relationship between events through event alignment according to the reference time, and can improve the accuracy of determining the temporal sequence and generating the causal chain performed in subsequent steps.

[0149] Next, the event processing unit (150) generates a causal chain when a plurality of aligned events satisfy both the temporal sequence and the predefined order constraints.

[0150] In the embodiments thereof, the temporal sequence is defined as a relationship in which the reference time of a preceding event is earlier than the reference time of a subsequent event, based on the reference time of each event. The event processing unit (150) can reflect the actual order of occurrence between events using the events sorted according to the aforementioned reference times, thereby enabling the configuration of a temporally valid event flow.

[0151] Additionally, the order constraint refers to a pre-set event sequence pattern to define a valid connection relationship between multiple events, and may be composed of multiple rule sets containing multiple event sequence patterns. These rule sets may be defined based on a combination of event attributes or the order of occurrence of events, and the event processing unit (150) may determine whether the sorted events match an event sequence pattern for at least one of the multiple rule sets. Here, the pre-defined order constraint may be stored in the form of a lookup table or a pattern matching table, but the implementation method of the order constraint is not limited to this and may be implemented in various hardware logic circuit structures.

[0152] At this time, the event processing unit (150) can generate a causal chain only when a plurality of aligned events satisfy a temporal sequence relationship and match an event sequence pattern for at least one of a plurality of rule sets.

[0153] For example, it is assumed that the first event indicates the reception of a specific packet, the second event indicates a traffic increase state, and the third event indicates a CPU overload state. In this case, if the events satisfy the temporal sequence of the first event → second event → third event and the sequence matches an event sequence pattern for at least one of a plurality of predefined rule sets, the event processing unit (150) can connect the events to create a causal chain.

[0154] On the other hand, if the temporal order between events is reversed or if multiple sorted events do not match the predefined order constraints, a causal chain may not be generated, and in this case, the events may be excluded from subsequent processing or processed according to the default policy. The causal chain generated in this way is a structure representing a continuous relationship between events and can subsequently be used as input information for determining the processing policy of a communication packet by the policy decision unit (160).

[0155] The policy decision unit (160) determines a processing policy for a communication packet according to a previously determined causal chain. A causal chain is a structure representing a continuous relationship of events formed when the temporal order of multiple events and predefined order constraints are satisfied, and may represent a situation or state flow related to the processing of a communication packet.

[0156] The policy decision unit (160) can determine a processing policy for a communication packet by referring to a predefined policy mapping relationship according to the type or pattern of the causal chain. At this time, the processing policy may include at least one of allowing processing of the communication packet, restricting processing, delaying processing, merging processing, and adjusting priority.

[0157] As an example, if a specific causal chain includes a traffic increase and a system overload state, the policy decision unit (160) may decide to limit processing or delay processing for the communication packet as a processing policy. On the other hand, if the causal chain indicates a normal packet flow, the policy decision unit (160) may decide to allow processing of the communication packet or maintain or increase its priority as a processing policy.

[0158] Additionally, the policy decision unit (160) can dynamically change the processing policy corresponding to the causal chain according to the system state information. For example, even if the same causal chain is formed, different processing policies may be applied when the system state is in a normal state and when it is in an overloaded state.

[0159] Meanwhile, the policy decision unit (160) may perform processing on communication packets by applying a set default policy or an alternative policy when a causal chain is not generated. In this way, the policy decision unit (160) determines the method of processing communication packets based on a causal chain that reflects the causal relationship between events, thereby enabling more sophisticated and situation-adaptive packet processing compared to simple condition-based processing.

[0160] The system processing unit (170) performs processing on communication packets according to a processing policy. The system processing unit (170) is a processing area distinct from the hardware packet processing pipeline described above, and is implemented with system components including a CPU, DSP (Digital Signal Processor), NPU (Neural Processing Unit), or software stack, etc., to perform actual processing operations on communication packets.

[0161] Specifically, the system processing unit (170) can receive the original data of the communication packet through a separate path distinct from the hardware packet processing pipeline and perform processing on the communication packet according to the processing policy determined by the policy decision unit (160).

[0162] For example, the system processing unit (170) may delay the processing of the communication packet or limit the processing of the communication packet according to the processing policy determined by the policy decision unit (160). Additionally, the system processing unit (170) may process the communication packet as is or maintain the priority for processing the communication packet according to the processing policy determined by the policy decision unit (160).

[0163] In this way, the system processing unit (170) can perform actual processing operations of communication packets based on the processing policy determined in the hardware packet processing pipeline, and accordingly, the determination of the processing policy and the actual processing execution can be separated to enable efficient packet processing. Below, with reference to FIG. 2, we will examine in more detail the operation of the hardware packet processing pipeline illustrated in FIG. 1.

[0165] FIG. 2 is an example showing the operation flow in a hardware packet processing pipeline according to one embodiment of the present invention.

[0166] Referring to FIG. 2, packet observation information, state transition results, and system state information generated from a communication packet can be provided as inputs to an event generation step. In the event generation step, these input information can be combined to generate an event that reflects the attributes of the communication packet, the state change of the packet flow, and the system state.

[0167] Subsequently, in the event selection step, among the generated events, those included in the same judgment time window can be selected, and events not included in the same judgment time window can be excluded from the causal relationship analysis.

[0168] Next, in the event sorting step, selected events can be sorted according to a reference time representing each event. This eliminates time distortion caused by processing delays that may occur during the event generation process and allows for sorting based on the actual order of occurrence among the events.

[0169] Finally, in the processing policy decision stage, a causal chain is generated for the aligned events if they satisfy the temporal precedence and predefined order constraints, and a processing policy for the communication packet can be determined based on the causal chain.

[0170] This operation flow can be performed on a hardware packet processing pipeline. In this case, a processing policy is determined at a stage prior to the communication packet being delivered to the system processing unit (170), thereby improving real-time performance and processing efficiency.

[0172] FIG. 3 is a flowchart illustrating a method for processing communication packets according to an embodiment of the present invention. In the illustrated flowchart, the method is described by dividing it into a plurality of steps, but at least some of the steps may be performed in a different order, combined with other steps and performed together, omitted, divided into detailed steps, or performed with one or more steps not illustrated added.

[0173] In step S102, the packet input unit (110) receives a communication packet from the outside. As described above, the packet input unit (110) can be implemented in various forms, such as a network interface, a communication port, or a bus interface, and can receive a communication packet transmitted in a wired or wireless communication environment.

[0174] In step S104, the packet parser (120) generates packet observation information from the communication packet. As described above, the packet observation information may include identification information, type information, time information, and characteristic information of the communication packet.

[0175] In step S106, the state management unit (130) generates a state transition result of the packet flow over time based on packet observation information. The state management unit (130) can generate a state transition result by updating an existing state transition result based on at least one of the identification information, type information, time information, and characteristic information of the communication packet whenever a communication packet is input, thereby reflecting the change or accumulated state of the packet flow over time.

[0176] In step S108, the system state collection unit (140) collects system state information related to the processing of communication packets. As described above, the system state information may include, for example, one or more of CPU load status, memory status, interrupt status, and network status. The system state collection unit (140) may, for example, monitor the system state information in hardware or collect it in real time through a performance counter, status register, internal signal, etc. Meanwhile, step S108 may be performed independently of steps S104 and S106, and may operate either before or after steps S104 and S106.

[0177] In step S110, the event processing unit (150) generates events based on at least one of packet observation information, state transition results, and system state information. The event processing unit (150) determines whether to generate an event by considering the packet observation information, state transition results, and system state information at each input time of a communication packet, and then generates one or more events when a specific condition is satisfied. At this time, the event processing unit (150) generates an event by combining at least one of the packet observation information, state transition results, and system state information, and may insert a reference time representing the event into the event.

[0178] In step S112, the event processing unit (150) selects multiple events that are included in the same judgment time window among the events. The event processing unit (150) may select multiple events by excluding events that are not included in the same judgment time window among the events.

[0179] In step S114, the event processing unit (150) sorts the selected multiple events according to the reference time.

[0180] In step S116, the event processing unit (150) generates a causal chain when a plurality of aligned events satisfy both a temporal precedence relationship and a predefined order constraint. As described above, the temporal precedence relationship can be defined as a relationship in which the reference time of a preceding event is earlier than the reference time of a subsequent event based on the reference time of each event. Additionally, the order constraint can be composed of a plurality of rule sets including a plurality of event sequence patterns. The event processing unit (150) can generate a causal chain only when the plurality of aligned events satisfy the temporal precedence relationship and match with an event sequence pattern for at least one of the plurality of rule sets.

[0181] In step S118, the policy decision unit (160) determines a processing policy for the communication packet according to the causal chain.

[0182] In step S120, the system processing unit (170) receives a communication packet and a processing policy from the packet input unit (110) and the policy decision unit (160), respectively. As described above, the system processing unit (170) can receive the original data of the communication packet through a separate path distinct from the hardware packet processing pipeline.

[0183] In step S122, the system processing unit (170) performs processing on the communication packet according to the processing policy.

[0185] FIG. 4 is a flowchart illustrating step S114 according to one embodiment of the present invention.

[0186] In step S202, the event processing unit (150) determines whether each of the generated events is included in the same judgment time window.

[0187] In steps S204 and S206, the event processing unit (150) can select events among a plurality of events that are included in the same judgment time window and exclude events that are not included in the same judgment time window by not selecting them.

[0189] FIG. 5 is an example of the application of the same judgment time window according to one embodiment of the present invention.

[0190] Referring to FIG. 5, multiple events each include a reference time and can be distributed along a time axis. The event processing unit (150) may apply a same judgment time window to form a set of events for determining causal relationships among these events. As described above, the same judgment time window refers to a temporal range for determining causal relationships between events.

[0191] The event processing unit (150) can set a time interval centered on a specific reference time as the same judgment time window, and can select events included within the time interval while simultaneously excluding events outside the time interval.

[0192] For example, if the reference time of the first event is 100μs, the reference time of the second event is 130μs, the reference time of the third event is 145μs, and the reference time of the fourth event is 210μs, it is assumed that the same judgment time window is set to 0μs to 150μs. In this case, the first, second, and third events, which fall within the range of 0μs to 150μs, are included in the same judgment time window and selected, whereas the fourth event, which does not fall within the range of 0μs to 150μs, is not included in the same judgment time window and is therefore not selected.

[0193] In this way, the event processing unit (150) can select only temporally related events by applying the same judgment time window, and accordingly, prevent temporally irrelevant events from being included in the causal chain generation.

[0194] Additionally, the same judgment time window may be set to a fixed value, but may also be dynamically adjusted according to system status information or traffic conditions. For example, the event processing unit (150) may narrow the same judgment time window to select events more strictly as the system load increases, and conversely, in a normal state, may expand the same judgment time window to select more events.

[0196] FIG. 6 is a flowchart illustrating step S116 according to one embodiment of the present invention.

[0197] In step S302, the event processing unit (150) determines whether the multiple events sorted in step S114 satisfy the temporal precedence relationship. To this end, the event processing unit (150) may sort the multiple events in ascending order according to the size of the reference time, and thereby determine the temporal precedence relationship between the preceding event and the succeeding event.

[0198] FIG. 7 is an example of determining whether a temporal sequence is satisfied according to an embodiment of the present invention. FIG. 7 (a) shows a reference time for each of a plurality of events, and FIG. 7 (b) shows a process of determining whether a plurality of aligned events satisfy a temporal sequence.

[0199] Referring to FIG. 7(a), the reference times for the first event (E1), the second event (E2), and the third event (E3) may be 100 μs, 130 μs, and 145 μs, respectively. In this case, the first event (E1) is a preceding event to the second event (E2), and the second event (E2) is a succeeding event to the first event (E1). Additionally, the second event (E2) is a preceding event to the third event (E3), and the third event (E3) is a succeeding event to the second event (E2).

[0200] Referring to FIG. 7(b), if the aligned events have an event sequence pattern of E1 → E2 → E3, the temporal order between the first event (E1), the second event (E2), and the third event (E3) described above is satisfied; however, if the aligned events have an event sequence pattern of E2 → E1 → E3, the temporal order between the first event (E1), the second event (E2), and the third event (E3) described above is not satisfied. In this way, the event processing unit (150) can determine the temporal order based on the actual order of occurrence between events using a reference time included in the event.

[0201] Returning to FIG. 6, in step S304, the event processing unit (150) determines whether the multiple events sorted in step S114 satisfy a predefined order constraint. As described above, the order constraint may be composed of multiple rule sets including multiple event sequence patterns. The rule sets may be defined based on combinations of event attributes or the order of occurrence of events, and the event processing unit (150) may determine whether the input event sequence pattern matches an event sequence pattern for at least one of the multiple rule sets.

[0202] In steps S306, S308, and S310, the event processing unit (150) generates a causal chain only when the aligned multiple events satisfy a predefined order constraint while satisfying a temporal sequence relationship, and does not generate a causal chain when the aligned multiple events do not satisfy a temporal sequence relationship or do not satisfy the order constraint.

[0203] FIG. 8 is an example of determining whether a sequence constraint condition is satisfied according to one embodiment of the present invention.

[0204] Here, it is assumed that one of the predefined order constraints is as follows.

[0206] <Example of Order Constraints>

[0207] control packet → increased traffic → CPU overload

[0209] In this case, the event processing unit (150) may determine that E1 (control packet) → E2 (traffic increase) → E3 (CPU overload) matches the preceding order constraint, and that E1 (CPU overload) → E2 (traffic increase) → E3 (control packet) does not match the preceding order constraint. In the case of E1 (CPU overload) → E2 (traffic increase) → E3 (control packet), even if the temporal order relationship is satisfied, it may be determined as a meaningless event sequence pattern because it does not satisfy the order constraint.

[0210] Meanwhile, predefined order constraints may exist in a fixed form, but may be selectively applied or changed according to system state information. Specifically, the event processing unit (150) may dynamically select one of a plurality of rule sets according to system state information, and may perform matching with sorted events using the event sequence pattern included in the selected rule set as an order constraint.

[0211] Here, the rule set is a set of event sequence patterns and can be configured to reflect policy objectives and processing strategies corresponding to specific system state information. That is, each rule set may include application conditions corresponding to system state information, policy objectives and processing strategies for processing policies corresponding to causal chains.

[0212] Examples of application conditions, policy objectives, and processing strategies included in rule sets based on system status information are as follows. Here, normal state, overload state, abnormal traffic state, etc., may be application conditions to which the rule set applies. Furthermore, the policy objective refers to the goal for the processing policy in these system states, and the processing strategy refers to the strategy for achieving the above policy objective. Additionally, the examples included in the processing strategy represent examples of specific execution actions for the processing policy that are actually applied. In other words, each rule set can be structured as Application Condition → Policy Objective → Processing Strategy → Execution Action.

[0214] System Status Information: Normal Mode

[0215] Rule set

[0216] → Application Condition: Normal State

[0217] → Policy Objective: Maintaining Performance

[0218] → Processing Strategy: Generate a causal chain capable of processing communication packets in a way that secures maximum throughput.

[0219] - (Execute Action) Optional Priority Adjustment

[0220] - (Execute Action) Limit / Minimize processing delay of communication packets

[0221] - (Execution Action) Processing focused on maintaining the flow of communication packets

[0223] Overload Mode

[0224] Rule set

[0225] → Application Condition: Overload condition

[0226] → Policy Objective: System Protection

[0227] → Processing Strategy: Selectively process to stabilize throughput and generate causal chains in a direction that alleviates the load.

[0228] - (Execution Action) Restrict processing of some communication packets

[0229] - (Execution Action) Delayed processing of low-priority communication packets

[0230] - (Execute Action) Processing the merging of communication packets

[0232] Abnormal Traffic Mode

[0233] Rule set

[0234] → Application Condition: Abnormal Traffic Condition

[0235] → Policy Objective: Suppress abnormal traffic

[0236] → Processing Strategy: Generate causal chains in a direction for system protection and traffic control

[0237] - (Execute Action) Block specific packet types or flows

[0238] - (Execute Action) Apply Rate Limit

[0239] - (Execute Action) Filtering based on specific sources

[0240] - (Execute Action) Force lower priority

[0242] As shown in the example above, when the system status information is in a normal state, relatively relaxed order constraints are applied so that various event sequences can be generated as causal chains, and when the system status information is in an overloaded state, stricter order constraints are applied so that causal chains can be generated only for specific event sequences. In addition, even for the same set of events, the satisfaction of order constraints may vary depending on the applied rule set, so the generated causal chains and the corresponding processing policy may also change dynamically. In this way, the event processing unit (150) can adaptively respond to changes in the communication packet processing environment by selectively applying an appropriate rule set according to the system status information, and can enable more efficient and stable packet processing. Meanwhile, the above-described normal state, overloaded state, and abnormal traffic state are merely examples of system status information, and the system status information that serves as the application condition for the rule set is not limited to these.

[0244] FIGS. 9 to 11 are examples for explaining a process in which a causal chain and a processing policy change dynamically based on system state information according to an embodiment of the present invention.

[0245] First, FIG. 9 illustrates the process of selecting a rule set corresponding to the normal state in the event processing unit (150) when the system state information is in a normal state. FIG. 9 (a) is an example of the creation of a causal chain for normal traffic when the system state information is in a normal state, and FIG. 9 (b) is an example of the creation of a causal chain for a slight increase in traffic when the system state information is in a normal state.

[0246] Referring to FIG. 9(a), when the system state information is in a normal state, if the first event (E1) and the second event (E2) are aligned as shown below, the event processing unit (150) can search for an event sequence pattern that matches the aligned event E1 → E2 by comparing the event sequence pattern for the rule set corresponding to the normal state with the aligned event E1 → E2.

[0248] E1: Arrival of communication packet

[0249] E2: Maintain normal traffic levels

[0251] In this case, the event processing unit (150) can generate a causal chain as follows by searching for an event sequence pattern that matches the sorted event E1 → E2.

[0253] Chain N1 = E1 → E2

[0255] Afterwards, the policy decision unit (160) can decide the processing policy corresponding to Chain N1 to allow processing / maintain priority.

[0257] Additionally, referring to Fig. 9(b), when the system state information is in a normal state, if the first event (E1) and the second event (E2) are aligned as shown below, the event processing unit (150) can search for an event sequence pattern that matches the aligned event E1 → E2 by comparing the event sequence pattern for the rule set corresponding to the normal state with the aligned event E1 → E2.

[0259] E1 : control packet

[0260] E2 : Traffic increase (minor)

[0262] In this case, the event processing unit (150) can generate a causal chain as follows by searching for an event sequence pattern that matches the sorted event E1 → E2.

[0264] Chain N2 = E1 → E2

[0266] Afterwards, the policy decision unit (160) can determine the processing policy corresponding to Chain N2 by allowing processing / making a slight adjustment to the priority.

[0268] Next, FIG. 10 illustrates the process of selecting a rule set corresponding to the overload state in the event processing unit (150) when the system state information is in an overload state. FIG. 10 (a) is an example of the creation of a causal chain for a load increase flow when the system state information is in an overload state, and FIG. 10 (b) is an example of the creation of a more simplified causal chain when the system state information is in an overload state.

[0269] Referring to FIG. 10 (a), when the system state information is in an overload state, the first event (E1), the second event (E2), and the third event (E3) are aligned as follows, the event processing unit (150) can search for an event sequence pattern that matches the aligned events E1 → E2 → E3 by comparing the event sequence pattern for the rule set corresponding to the overload state with the aligned events E1 → E2 → E3.

[0271] E1: Increase traffic on a specific port

[0272] E2: Traffic threshold exceeded

[0273] E3: Increased CPU usage

[0275] In this case, the event processing unit (150) can generate a causal chain as follows by searching for an event sequence pattern that matches the sorted events E1 → E2 → E3.

[0277] Chain O1 = E1 → E2 → E3

[0279] Afterwards, the policy decision unit (160) can determine the processing policy corresponding to Chain O1 as a partial packet drop / processing slight delay.

[0281] Additionally, referring to (b) of FIG. 10, when the system status information is in an overload state, if the first event (E1) and the second event (E2) are aligned as shown below, the event processing unit (150) can search for an event sequence pattern that matches the aligned event E1 → E2 by comparing the event sequence pattern for the rule set corresponding to the overload state with the aligned event E1 → E2.

[0283] E1: Traffic threshold exceeded

[0284] E2: Increased CPU usage

[0286] In this case, the event processing unit (150) can generate a causal chain as follows by searching for an event sequence pattern that matches the sorted event E1 → E2.

[0288] Chain O2 = E1 → E2

[0290] Afterwards, the policy decision unit (160) can determine the processing policy corresponding to Chain O2 as multiple packet drop / merge processing.

[0292] Next, FIG. 11 illustrates the process of selecting a rule set corresponding to the abnormal traffic state in the event processing unit (150) when the system state information is in an abnormal traffic state. FIG. 11 (a) is an example of the creation of a causal chain for a Denial of Service (DoS) pattern when the system state information is in an abnormal traffic state, and FIG. 11 (b) is an example of the creation of a causal chain for an abnormal protocol flow when the system state information is in an abnormal traffic state.

[0293] Referring to FIG. 11 (a), when the system status information is in an abnormal traffic state, the first event (E1), the second event (E2), and the third event (E3) are aligned as follows, the event processing unit (150) can compare the aligned events E1 → E2 → E3 with the event sequence pattern for the rule set corresponding to the abnormal traffic state to find an event sequence pattern that matches the aligned events E1 → E2 → E3.

[0295] E1: Multiple packets generated from the same source

[0296] E2 : short interval burst

[0297] E3: Concentrated attack on specific ports

[0299] In this case, the event processing unit (150) can generate a causal chain as follows by searching for an event sequence pattern that matches the sorted events E1 → E2 → E3.

[0301] Chain A1 = E1 → E2 → E3

[0303] Afterwards, the policy decision unit (160) can determine the processing policy corresponding to Chain A1 as the source drop / rate limit.

[0305] Additionally, referring to (b) of FIG. 11, when the system status information is in an abnormal traffic state, if the first event (E1) and the second event (E2) are aligned as follows, the event processing unit (150) can search for an event sequence pattern that matches the aligned event E1 → E2 by comparing the event sequence pattern for the rule set corresponding to the abnormal traffic state with the aligned event E1 → E2.

[0307] E1: Abnormal packet type

[0308] E2: Repeated occurrence

[0310] In this case, the event processing unit (150) can generate a causal chain as follows by searching for an event sequence pattern that matches the sorted event E1 → E2.

[0312] Chain A2 = E1 → E2

[0314] Afterwards, the policy decision unit (160) can determine the processing policy corresponding to Chain A2 as blocking the packet / forcing a lowering of priority.

[0316] As such, different causal chains are generated even for the same event sequence depending on the rule set, and the processing policy may differ accordingly.

[0318] FIG. 12 is a block diagram illustrating a computing environment including a computing device suitable for use in exemplary embodiments. In the illustrated embodiments, each component may have different functions and capabilities in addition to those described below, and may include additional components in addition to those not described below.

[0319] The illustrated computing environment (10) includes a computing device (12). In one embodiment, the computing device (12) may be a communication packet processing system (100) or one or more components included in the communication packet processing system (100).

[0320] The computing device (12) includes at least one processor (14), a computer-readable storage medium (16), and a communication bus (18). The processor (14) can cause the computing device (12) to operate according to the exemplary embodiment described above. For example, the processor (14) can execute one or more programs stored in the computer-readable storage medium (16). The one or more programs may include one or more computer-executable instructions, and the computer-executable instructions may be configured to cause the computing device (12) to perform operations according to the exemplary embodiment when executed by the processor (14).

[0321] A computer-readable storage medium (16) is configured to store computer-executable instructions or program code, program data and / or other suitable forms of information. A program (20) stored in the computer-readable storage medium (16) includes a set of instructions executable by a processor (14). In one embodiment, the computer-readable storage medium (16) may be memory (volatile memory such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other forms of storage media that are accessed by a computing device (12) and capable of storing desired information, or a suitable combination thereof.

[0322] The communication bus (18) interconnects various other components of the computing device (12), including the processor (14) and the computer-readable storage medium (16).

[0323] The computing device (12) may also include one or more input / output interfaces (22) and one or more network communication interfaces (26) that provide interfaces for one or more input / output devices (24). The input / output interfaces (22) and network communication interfaces (26) are connected to a communication bus (18). The input / output devices (24) may be connected to other components of the computing device (12) through the input / output interfaces (22). An exemplary input / output device (24) may include an input device such as a pointing device (such as a mouse or trackpad), a keyboard, a touch input device (such as a touchpad or touchscreen), a voice or sound input device, various types of sensor devices and / or imaging devices, and / or an output device such as a display device, a printer, a speaker and / or a network card. An exemplary input / output device (24) may be included inside the computing device (12) as a component constituting the computing device (12), or it may be connected to the computing device (12) as a separate device distinct from the computing device (12).

[0325] Although the present invention has been described in detail above through representative embodiments, those skilled in the art will understand that various modifications can be made to the aforementioned embodiments without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof. Explanation of the symbols

[0327] 100: Communication packet processing system 110: Packet input section 120 : Packet parser 130 : Status Management Department 140: System status collection unit 150 : Event handling section 160 : Policy-making department 170 : System processing unit

Claims

Claim 1 A communication packet processing system comprising: a packet parser unit that generates packet observation information from a communication packet; a state management unit that generates state transition results of a packet flow according to time flow based on the packet observation information; a system state collection unit that collects system state information related to the processing of the communication packet; an event processing unit that generates events based on at least one of the packet observation information, the state transition result, and the system state information, selects a plurality of events included in a set same judgment time window among the events, sorts the selected plurality of events according to a reference time representing the events, and generates a causal chain when the sorted plurality of events satisfy both a temporal precedence relationship and a predefined order constraint condition; a policy decision unit that determines a processing policy for the communication packet according to the causal chain; and a system processing unit that performs processing for the communication packet according to the processing policy. Claim 2 A communication packet processing system according to claim 1, wherein the packet parser, the state management unit, the system state collection unit, the event processing unit, and the policy determination unit are a hardware packet processing pipeline that performs a control operation for determining the processing policy based on metadata regarding the communication packet before the communication packet is transmitted to the system processing unit, and the original data regarding the communication packet is transmitted simultaneously to the system processing unit and the hardware packet processing pipeline, wherein the system processing unit receives the original data regarding the communication packet through a separate path distinguished from the hardware packet processing pipeline and performs processing on the communication packet according to the processing policy. Claim 3 A communication packet processing system according to claim 1, wherein the packet observation information includes identification information, type information, time information, and characteristic information of the communication packet, and the state management unit generates the state transition result by updating the existing state transition result based on at least one of the identification information, type information, time information, and characteristic information of the communication packet whenever the communication packet is input, thereby reflecting a change in packet flow or an accumulated state over time. Claim 4 A communication packet processing system according to claim 1, wherein the system state information includes one or more of a CPU load state, a memory state, an interrupt state, and a network state. Claim 5 A communication packet processing system according to claim 1, wherein the event processing unit generates an event by combining at least one of the packet observation information, the state transition result, and the system state information, and inserts the reference time into the event, and the reference time is time information generated based on at least one of the arrival time of the communication packet that caused the generation of the event, the time of occurrence of the state transition result, and the time of change of the system state. Claim 6 A communication packet processing system according to claim 5, wherein the same judgment time window is a temporal range for determining causal relationships between the events, and the event processing unit selects the plurality of events by excluding events among the events that are not included in the same judgment time window. Claim 7 A communication packet processing system according to claim 6, wherein the temporal precedence relationship is defined as a relationship in which the reference time of a preceding event is earlier than the reference time of a succeeding event based on the reference time of each event, the order constraint condition is composed of a plurality of rule sets including a plurality of event sequence patterns, and the event processing unit generates the causal chain only when the aligned plurality of events are matched with an event sequence pattern for at least one of the plurality of rule sets while satisfying the temporal precedence relationship. Claim 8 A communication packet processing system according to claim 7, wherein the event processing unit dynamically selects one of the plurality of rule sets according to the system state information to generate the causal chain, and each rule set includes an application condition corresponding to the system state information, a policy objective for a processing policy corresponding to the causal chain, and a processing strategy. Claim 9 A communication packet processing system according to claim 1, wherein the processing policy comprises one or more of allowing processing of the communication packet, restricting processing, delaying processing, merging processing, and adjusting priority. Claim 10 A method for processing communication packets, comprising: a step of generating packet observation information from a communication packet in a packet parser; a step of generating a state transition result of a packet flow according to time flow in a state management unit based on the packet observation information; a step of collecting system state information related to the processing of the communication packet in a system state collection unit; a step of generating events based on at least one of the packet observation information, the state transition result, and the system state information in an event processing unit; a step of selecting a plurality of events included in a set same judgment time window among the events in the event processing unit; a step of sorting the selected plurality of events according to a reference time representing the events in the event processing unit; a step of generating a causal chain in the event processing unit when the sorted plurality of events satisfy both a temporal precedence relationship and a predefined order constraint; a step of determining a processing policy for the communication packet according to the causal chain in a policy decision unit; and a step of performing processing on the communication packet according to the processing policy in a system processing unit. Claim 11 In claim 10, the packet parser, the state management unit, the system state collection unit, the event processing unit, and the policy determination unit are a hardware packet processing pipeline that performs a control operation for determining the processing policy based on metadata regarding the communication packet before the communication packet is transmitted to the system processing unit, and the original data regarding the communication packet is transmitted simultaneously to the system processing unit and the hardware packet processing pipeline, wherein the step of performing processing on the communication packet is to receive the original data regarding the communication packet through a separate path distinguished from the hardware packet processing pipeline and perform processing on the communication packet according to the processing policy. Claim 12 A communication packet processing method according to claim 10, wherein the packet observation information includes identification information, type information, time information, and characteristic information of the communication packet, and the step of generating the state transition result generates the state transition result by updating the existing state transition result based on at least one of the identification information, type information, time information, and characteristic information of the communication packet whenever the communication packet is input, thereby reflecting a change in packet flow or an accumulated state over time. Claim 13 A communication packet processing method according to claim 10, wherein the system state information includes one or more of a CPU load state, a memory state, an interrupt state, and a network state. Claim 14 A communication packet processing method according to claim 10, wherein the step of generating the events comprises generating an event by combining at least one of the packet observation information, the state transition result, and the system state information, wherein the reference time is time information generated based on at least one of the arrival time of the communication packet that caused the generation of the event, the time of occurrence of the state transition result, and the time of change of the system state. Claim 15 A communication packet processing method according to claim 14, wherein the same judgment time window is a temporal range for determining causal relationships between the events, and the step of selecting the plurality of events selects the plurality of events by excluding events among the events that are not included in the same judgment time window. Claim 16 A communication packet processing method according to claim 15, wherein the temporal precedence relationship is defined as a relationship in which the reference time of a preceding event is earlier than the reference time of a succeeding event based on the reference time of each event, the order constraint condition is composed of a plurality of rule sets including a plurality of event sequence patterns, and the step of generating the causal chain is to generate the causal chain only when the aligned plurality of events are matched with an event sequence pattern for at least one of the plurality of rule sets while satisfying the temporal precedence relationship. Claim 17 A communication packet processing method according to claim 16, wherein the step of generating the causal chain comprises dynamically selecting one of the plurality of rule sets according to the system state information to generate the causal chain, and each rule set includes an application condition corresponding to the system state information, a policy objective for a processing policy corresponding to the causal chain, and a processing strategy. Claim 18 A method for processing communication packets according to claim 10, wherein the processing policy comprises one or more of allowing processing of the communication packet, restricting processing, delaying processing, merging processing, and adjusting priority.

Images