WO2017009461A1

WO2017009461A1 - Method and device for packet processing

Info

Publication number: WO2017009461A1
Application number: PCT/EP2016/066938
Authority: WO
Inventors: Ritesh Banerjee; Ingo Volkening; Shivaji ROY
Original assignee: Lantiq Beteiligungs-GmbH & Co.KG
Priority date: 2015-07-15
Filing date: 2016-07-15
Publication date: 2017-01-19

Abstract

Method and device for packet processing An embodiment relates to a method for packet processing, comprising a first packet processing (4') which comprises packet processing that is common to every packet of a session or an IP flow, and a second packet processing (5') which comprises packet processing which varies from packet to packet in the session or IP flow. Further, the an embodiment relates to a packet processing device (1), comprising a packet processing path (6), the packet processing path (6) being adapted to perform a first packet processing (4') that is common to every packet of a session or IP flow and a second packet processing (5') which may vary from packet to packet in the session.

Description

Method and device for packet processing

Technical field

The application relates to methods and devices for processing packets communicated according to a protocol. In particular, the packets to be processed may refer to packets transmitted through communication networks, such as Internet protocol (IP) packets. Background

Protocol Processing is one of the major loads in many networked devices including routers, gateways, PCs and servers which all communicate to other devices over various network media and technologies. As interface speeds have gone up to multiple Gigabit, the CPU power to cope with receiving packets, forwarding packets, performing the required protocol processing at ingress and egress, and transmitting packets easily overwhelms even the fastest CPUs. Besides, the CPU power needs to be available to run applications, management and control protocols, and not be consumed totally by packet loads for a useful and high performing system. This has spawned a lot of techniques to offload CPU protocol and packet processing to dedicated hardware, firmware and or software acceleration engines, thus maximizing throughput while also making more CPU power available to other tasks and loads.

Summary

A method and a device according to the independent claims are provided. Further embodiments are defined in the dependent claims.

According to an embodiment, a method for packet processing comprises a first packet processing, which comprises packet processing that is common to every packet of a session or an IP flow, and a second packet processing, which comprises packet processing varying from packet to packet in the session or IP flow. This embodiment may be based on the approach looking at the packet fastpath processing requirements broadly as two sets of complementary steps, and using simplified actions in the fastpath to achieve the final result.

According to another embodiment, a packet processing device comprises a packet processing path, wherein the packet processing path is adapted to perform a first packet processing that is common to every packet of a session or IP flow and a second packet processing which may vary from packet to packet in the session.

This device may operate based on the above method.

Packet processing within the meaning of the present disclosure refers to any operation performed on a packet which is adapted to induce amendments on said packet. In particular, said packet refers to an object which is to be transmitted through a network. For example, said network includes at least one of a router, a gateway, a computer and a server.

A packet within the meaning of the present disclosure refers to an object that is adapted to be transmitted. In particular, said transmission refers to a networking device. In particular, said packet is adapted to pass at least one central processing unit. For example, said packet is an internet protocol (IP) packet.

A session within the meaning of the present disclosure refers to a connection that provides interactive information interchange. Said session may refer to a network session. Said session may be configured not to be maintained permanently.

An IP flow within the meaning of the present disclosure may refer to any data flow in accordance with an internet protocol (IP). For example, said data flow may refer to a net flow. Said IP flow may be performed within a network. Said IP flow within a network may be adapted for communication in between at least two network media. A processing path within the meaning of the present disclosure refers to any continuous trajectory in between an input port and an output port comprising at least one device which is adapted to process an object. For example, said object is a packet, and in particular an IP packet. For example, said trajectory may include an electrical connection.

In an embodiment of the method, the first packet processing is implemented in a first packet processing path, a second packet processing path being provided that is slower than the first packet processing path. In another embodiment of the method, the first packet processing is implemented in said second packet processing path.

In such embodiments, packet protocol acceleration may be achieved by splitting a first packing processing in a faster first processing path and a slower second processing path, which constitutes an offload mechanism of the packing processing.

In another embodiment of the method, the second packet processing path comprises packet processing in a central processing unit.

In this way, in some embodiments packet protocol acceleration can be performed by integrating conventional network components.

In another embodiment of the method, the first packet processing path comprises packet processing using acceleration hardware, acceleration firmware and/or acceleration software.

In this way, in some embodiments packet throughput can be maximized while also making more central processing unit (CPU) power available to other tasks and loads.

In another embodiment of the method, the first packet processing comprises creating a template header for a session. Therefore, in some embodiments a substitute for metadata of a packet is created that may be adapted for the creation of modified packets, which exhibit a more homogenous constitution. In some embodiments of the method, the first packet processing comprises inserting the template header in the header of each received packet, replacing the header of each received packet of the session with the template header and/or partially overwriting the header of each received packet of the session with the template header. In this way, in some embodiments modified packets exhibiting a more homogenous constitution are created, which are adapted to fast path processing, in particular using a first packet processing path.

In another embodiment of the method, the method further comprises using the template header and metadata of said template header to carry out all packet processing and/or editing for each packet by one or more memory copy operations.

Using the memory copy operations, fastpath packet processing can be achieved in some embodiments without having the need for any algorithmic knowledge of the packet editing, which is to be carried out for said packet in a first packet processing. In doing so, the number of software cycles that is required for such an operation can be reduced, e.g. when using a hardware direct memory access (DMA).

In an embodiment of the method, the metadata of said template header comprises an offset of the template header and/or a length of the template header.

Using these additional information regarding said template header, memory copy operation can be performed in a streamlined manner in some embodiments. In another embodiment of the method, the method further comprises using a hardware memory copy engine and/or a cache coherent device for the memory copy operation. Using such components, memory copy operation can further be offloaded and/or can further be speeded up in some embodiments. In particular, said achievement is reachable, since the number of software cycles that is required for such an operation can further be reduced, when a cache coherent device directly accesses to said header.

In another embodiment of the method, the second packet processing further comprises manipulating a parameter value in a header of a received packet. In an embodiment of the method, said parameter value is adapted for decrementing an IP time to live field. In this way, in some embodiments permanent forwarding of packets, the purpose of which has already ended, can be avoided, which may consequently result in discharging a network.

In another embodiment of the method, the second packet processing further comprises updating a field to the packet header based on a state of session. In some embodiments of the method, said updating may refer to incrementing an IP identification field in an added tunnel IP header based on a value used for a previous packet of a session. In some embodiments therefore, distinct labeling of packets traversing said second processing can be achieved, wherein said labeling may also ensure to label the sequence of said packets passing said second processing. Therefore, defragmenting of said packets - after being processed within said second processing - can be facilitated. In another embodiment of the method, the method may further comprise updating the checksum per packet. In some embodiments, said checksum may be an IP checksum and/or a TCP checksum and/or an UDP checksum.

In some embodiments, an error within the header of a packet which may creep in said header at a certain point of time and in particular within a certain packet processing, may be detected at a preferably early point of time. Thereby, forwarding packets comprising defective headers may be avoided. ln another embodiment of the method, updating said checksum per packed may be performed by a checksum calculation engine and/or is applied incrementally from session-based metadata on checksum adjustment.

In some embodiments, therefore checksum update can be handed in a preferably simple manner.

In another embodiment of the method, the second packet processing is performed not in every session.

In some cases, this may reduce the number of processing steps and/or algorithm complexity. In another embodiment of the method, the second packet processing may be applied on top of the first packet processing.

In such implementations, intervention of second packet processing may be adapted to first packet processing operations and can therefore be kept on a preferably low level of intervention.

In an embodiment of the device, the first packet processing and the second packet processing may be implemented separately. In such embodiments, the device may be configured for running the first packet processing and the packet processing independently from each other. This enables an adaption of the device to any packet processing which is to be performed.

In another embodiment of the device, the packet processing path is a first packet processing path, which is adapted for implementation of the first packet processing, which may adapt the device for fastpath processing, which significantly increases packet throughput. The device may be adapted to perform any of the methods mentioned above for packet processing within the sense of the present disclosure. A central processing unit within the meaning of the present disclosure refers to any electronic device comprising an electronic circuit which carries out instructions by performing operations specified by the instructions. For example, said instructions refer to a computer program. In particular, said electronic device is a microprocessor comprising an integrated circuit.

A header within the meaning of the present disclosure refers to metadata of a packet. For example, said packet is an IP packet. In particular, said header comprises information regarding at least one of origin, target, status and fragmenting of said packet. For example, said header comprises at least one of a total length array, an identification array, a fragment offset array, a time of live array and a header checksum array.

A template header within the meaning of the present disclosure refers to any substitute of a header within the sense of the present disclosure. For example, said template header is created in the first packet processing. For example, said header is created in a second packet processing path.

Metadata within the meaning of the present disclosure refers to any data that provides information about other data. For example, metadata refers to a header or a template header of a packet, in particular an IP packet. For example, metadata refers to an offset or length of a template header. For example, said object is a header. For example, said memory refers to a direct memory access (DMA).

A memory copy operation within the meaning of the present disclosure refers to any operation within a network, wherein copying of an object is performed using any memory device. The above summary is merely intended to give a short overview over some features of some embodiments and implementations and is not to be construed as limiting. Other embodiments may comprise other features than the ones explained above. Description of the drawings

The above and other elements, features, steps and characteristics of the present disclosure will be more apparent from the following detailed description of embodiments with reference to the following figures:

Figure 1 schematically illustrates a block diagram of a packet processing device according to an embodiment.

Figure 2 schematically illustrates a principle of operation of packet processing according to an embodiment.

Detailed description

Referring to Figure 1 , an embodiment of a packet processing device 1 is shown in a schematic manner. Said processing device 1 may comprise at least one of a first packet processing unit 4 adapted for performing a first packet processing 4' and a second packet processing unit 5 adapted for performing a second packet processing 5'. Said first packet processing unit 4 and/or said second packet processing unit 5 may be fully or partly included within said packet processing device 1 . Processing device 1 may further comprise a packet input port 2 adapted for receiving packets to be processed. Processing device 1 may further comprise a packet output port 3 adapted for outputting processed packets, after processing of said processing packets in device 1 . In the embodiment depicted in Figure 1 , packet input port 2 and packet output port 3 are separated from each other. However, it may also be that packet input port 2 and packet output port 3 are at least partly implemented in common, for example by a bi-directional packet port. Processing device 1 may also comprise two or a plurality of packet input ports 2 and/or packet output ports 3. Further, the embodiment of Figure 1 may implement at least one of a first packet processing path 6 and a second packet processing path 7. In some embodiments, any of said first and second processing paths 6, 7 is configured to couple one packet input port 2 with at least one packet output port 3. In the embodiment of Figure 1 , said first packet processing path 6 and said second processing path 7 have a common section. In other embodiments, the first packet processing path 6 and the second processing path 7 may not comprise any common section. Said first and second processing paths 6, 7 are adapted to enable packet processing according methods as described below. Arrows in Figure 1 illustrate a direction in which every packet is processed. Following said direction, sequence of components is provided according to Figure 1 : packet input port 2, first packet processing unit 4, second packet processing unit 5 and packet output port 3. Based on said sequence, a corresponding sequence, in which at least one of said components is missing, also refers to an embodiment.

In operation, packet processing device 1 is adapted for transmitting a packet during a session or an IP flow from packet input port 2 to first packet processing unit 4 along a path that is a common section of the first and second processing paths 6, 7. First packet processing unit 4 is configured for subsequent first processing of said packets and is adapted for processing every packet during a session or an IP flow in a common manner. An example of such first packet processing 4' will be given below referring to Figure 2. Said first packet processing unit 4 may comprise junction 8, at which the first and second packet processing paths 6, 7 separates. In an embodiment, second processing path 7 operates slower than first processing path 6. First packet processing path 6 and/or second packet processing path 7 may be configured to transmit packets during a session or an IP flow from first packet processing unit 4 to second packet processing unit 5, as illustrated in Figure 1 . Second packet processing unit 5 may be adapted to vary from packet to packet within a session or an IP flow. An example to second packet processing 5' will be explained with reference to Figure 2.

First packet processing unit 4 and second packet processing unit 5 may be implemented as hardware, software, firmware or combinations thereof, for example as specifically designed circuits like ASICs (application specific integrated circuits) or as digital signal processor(s) programmed accordingly. While units 4, 5 are depicted as separate blocks, they may be implemented using at least in part common components. Referring to Figure 2, a flowchart illustrates a packet processing method according to an embodiment. Said method may be performed within packet processing device 1 . According to the embodiment depicted in Figure 2, a first packet processing 4' is performed, wherein said packet processing 4' may be performed using the first packet processing unit 4 according to Figure 1 . Further, a second packet processing 5' is performed according to Figure 2, wherein said packet processing 5' may be performed using the second packet processing unit 5 according to Figure 1 . In such an embodiment, first packet processing 4' may be performed in both the first packet processing path 6 and the second packet processing path 7. In other embodiments, first packet processing 4' is only implemented in first processing path 6. According to an embodiment of such a method, the packet processing device 1 in use may comprise at least one packet input port 2, 2'. In one embodiment, the packet input port 2, 2' inputs packets to the first packet processing 4'.

When a session or an IP flow is started, said flow originated from packet input port 2 is transmitted to the first packet processing 4' performed within the first packet processing unit 4. At A, parsing of the session and IP flow, respectively is performed, which results in a plurality of single packets. Subsequently at B, the header of each packet is analyzed. Analysis of the header may refer to at least one of the following: determining the offset of said packet and saving its IP time to live (IP TTL). Following, said analysis is used at C. Based on one of the previous performed at A and/or at B, it is defined at C, whether the present packet and its header, respectively is presently suited for performing further processing at the first packet processing path 6. The definition may be based on the fact, whether the present packet is already known at the first packet processing path 6.

In case that the answer at C is negative (N), the present packet leaves the first packet processing path 6 at the present stage C and moves to C1 , wherein at C1 the transmission of said present packet towards the second packet processing path 7 of the first packet processing 4' performed within the first packet processing unit 4 is performed. In such an embodiment, the second packet processing path 7 may operate slower than the first packet processing path 6. Within said second packet processing path 7, a learning phase may be performed at the present packet. The learning phase may be based on CPU software. A packet that is presently processed may process all session based packet processing and/or editing requirements at C2 of the second packet processing path 7 and may create a per session template header which may be for inserting and/or replacing and/or partially overwriting the header of a received packet during at least one following step.

Referring to C again and in the opposite case if the answer within the definition is positive (Y), the present packet may continue processing within the first packet processing path 6. In this case, a subsequent process at D may be performed at said present packet. The per session template header created at C and/or data of analysis according to the processes at B may be used for the performance at D. Processing at D may use said template header and/or metadata of said template header - in particular the offset and/or length of the template header - to carry out all first packet processing 4' and/or editing by at least one memory copy operation. In such an embodiment, there may be no need for any algorithmic knowledge of the packet editing carried out for the packet on a first packet processing 4' basis.

Figure 2 further illustrates that first packet processing 4' within first packet processing unit 4 may then substantially be completed. The present packet may then be transmitted to second packet processing 5', which may be performed using a second packet processing unit 5. At E of said second packet processing 5', at least one further action may be provided, which varies from packet to packet within the present session. Said at least one action may refer to: a) Looking at a parameter value in the received packet header, and then manipulating it, in particular decrementing the IP time to live (IP TTL) field in the IP header, b) Updating and/or adding a field to the packet header based on state of the session, in particular incrementing the IP identification (IP ID) field in the added tunnel IP header (like IP-in-IP) based on the value used for the previous packet of this session, and per packet checksum(s) update, in particular IP checksum and/or TCP checksum and/or UDP checksum, which may be performed by a checksum calculation engine and/or may be applied incrementally from session based meta-data on checksum adjustment.

Pertaining to Figure 2, a final process may be performed at F. The packet presently processed may then (at F) be forwarded to any destination. The destination may refer to a packet output port 3 according to Figure 1 . The destination may be at least partly included within a packet processing device 1 , which is illustrated by Figure 2.

Claims

1 . A method for packet processing, comprising:

a first packet processing (4') which comprises packet processing that is common to every packet of a session or an IP flow, and

a second packet processing (5') which comprises packet processing which varies from packet to packet in the session or IP flow.

2. The method of claim 1 , wherein the first packet processing (4') is implemented in a first packet processing path (6), a second packet processing path (7) being provided that is slower than the first packet processing path (6).

3. The method of claim 2, wherein the first packet processing (4') is implemented in said second packet processing path (7).

4. The method of claim 2 or 3, wherein the second packet processing path (7) comprises packet processing in a central processing unit.

5. The method of any of claims 2 to 4, wherein the first packet processing path (6) comprises packet processing using acceleration hardware, acceleration firmware and/or acceleration software.

6. The method of any one of claims 2 to 5, wherein the first packet processing (4') comprises creating a template header for a session.

7. The method of claim 6, wherein the first packet processing (4') comprises inserting the template header in the header of each received packet, replacing the header of each received packet of the session with the template header and/or partially overwriting the header of each received packet of the session with the template header.

8. The method of claim 6 or 7, further comprising using the template header and metadata of said template header to carry out all packet processing and/or editing for each packet by a one or more memory copy operations.

9. The method of claim 8, wherein the metadata of said template header comprise an offset of the template header and/or a length of the template header.

10. The method of any one of claims 6 to 9, further comprising using a hardware memory copy engine and/or cache a coherent device for the memory copy operation.

1 1 . The method of any one of claims 2 to 10, wherein the second packet processing (5') further comprises manipulating a parameter value in a header of a received packet.

12. The method of claim 1 1 , wherein said parameter value is adapted for decrementing an IP time to live field.

13. The method of any one of claims 2 to 12, wherein the second packet processing (5') further comprises updating a field to the packet header based on a state of session.

14. The method of claim 13, wherein said updating refers to incrementing an IP identification field in an added tunnel IP header based on a value used for a previous packet of a session.

15. The method of any one of claims 1 to 14, further comprising updating the checksum per packet.

16. The method of claim 15, wherein said checksum is an IP checksum and/or a TCP checksum and/or an UDP checksum.

17. The method of claim 15 or 16, wherein updating said checksum per packed is performed by a checksum calculation engine and/or is applied incrementally from session-based metadata on checksum adjustment.

18. The method of any of claims 1 to 17, wherein the second packet processing (5') is performed not in every session.

19. The method of any of claims 1 to 18, wherein the second packet processing (5') is applied on top of the first packet processing (4').

20. A packet processing device (1 ), comprising a packet processing path (6, 7), the packet processing path (6, 7) being adapted to perform a first packet processing (4') that is common to every packet of a session or IP flow and a second packet processing (5') which may vary from packet to packet in the session.

21 . The device (1 ) of claim 20, wherein the first packet processing (4') and the second packet processing (5') are implemented separately.

22. The device (1 ) of claim 20 or 21 , wherein the packet processing path (6, 7) is a first packet processing path (6), which is adapted for implementation of the first packet processing (4').

23. The device of any of claims 20 to 22, wherein the device (1 ) is adapted to perform the method of any one of claims 1 to 19.

24. The device of any of claims 20 to 23, wherein the first packet processing (4') is performed by a first packet processing unit (4).

25. The device of any of claims 20 to 24 wherein the second packet processing (5') is performed by a second packet processing unit (5).