WO2021180321A1

WO2021180321A1 - Methods and apparatus for packet processing based on parsing depth of communication nodes

Info

Publication number: WO2021180321A1
Application number: PCT/EP2020/056609
Authority: WO
Inventors: Reuven Cohen; Ben-Shahar BELKAR; Tal Mizrahi
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-03-12
Filing date: 2020-03-12
Publication date: 2021-09-16
Also published as: CN114008998A; CN114008998B

Abstract

Apparatus and methods for ensuring critical prefix of PDU(s) is within parsing depth capability of destination device(s) are described. A method of processing packets received in a computer network includes: encoding, in capacity packet header(s), value(s) indicating parsing depth capacity of device(s) for processing packets at transport layer; sending and/or receiving capacity packet(s) during setup of network connection between devices; decoding capacity packet value(s) indicating parsing depth(s) from header(s) during setup; encoding transport layer packets according to capacity packet value(s); and/or sending transport layer packets to device(s) over network.

Description

METHODS AND APPARATUS FOR PACKET PROCESSING BASED ON PARSING DEPTH OF COMMUNICATION NODES

TECHNICAL FIELD

The present disclosure relates to the field of digital communication, and in particular, related to methods and apparatuses for packet processing based on parsing depth of communication nodes.

BACKGROUND

Packet switching technology forms a basis of modem data telecommunication. Packet switching technology enables delivery of data streams over a network. Data may be transmitted between peer entities of the network in protocol data units (PDUs) including protocol specific control information and user data. The PDUs may include packets of the internet protocol (IP) layer and segments of the transmission control protocol (TCP) layer. As used herein, the terms “packet” and “PDU” may be used interchangeably, unless the context clearly dictates otherwise.

A packet typically has more than one protocol header. Each header may correspond to a network protocol in different layers of a network layer model. Network protocol headers may be of various lengths. A network device that receives a packet needs to parse or inspect the header in order to process it. As used herein, several beginning bytes of the PDU that carry critical information that is to be processed by the packet processing device are referred to as the “critical prefix” of the PDU. The required parsing depth, i.e., the number of bytes that need to be read by the packet processing device can be from a few bytes to hundreds of bytes.

In many cases, in order to increase communication speed, processing of a PDU is offloaded to network device hardware. The hardware usually has an ability to process only a short part of the PDU, such as: 64 bytes, 128 bytes or 256 bytes. As used herein, this limited parsing depth capacity is referred to as the “parsing depth capability” (PDC) of the hardware. The PDC may be relevant to any network device, including hosts, such as a personal computer or a server, that use Network Interface Cards (NICs), switches, routers and/or middle boxes, such as firewalls.

Very often, network entities that communicate with each other have different PDCs. In such cases, there is a problem if the PDC of the receiver is shorter than the critical prefix of the received PDU. As an example, a network entity may receive an IP packet whose payload includes a TCP segment, as shown in Table 1.

Table 1 An IP packet whose payload includes a TCP segment

If the network entities include a router which is used to route the packet, hardware of the router may need to process only the IP header comprising the beginning 20 bytes. Accordingly, the PDU critical prefix is only 20 bytes.

If, however, the network entities include a network interface card (NIC) that implements TCP offload, hardware of the NIC may need to process both the IP header (20 bytes) and the TCP headers. Since the TCP headers contain both a fixed header of 20 bytes and an optional header of 0-40 bytes, then the PDU critical prefix is 80 bytes (20 bytes + 20 bytes + 40 bytes).

If a relevant header is too long to be read by hardware, it may be only partially parsed or processed by software, which may be insufficient and/or may result in poor performance. For example, IP fragmentation may result in excess retransmissions such as when fragments encounter packet loss and protocols such as TCP are required to retransmit all the fragments in order to recover from the loss of just a single fragment.

SUMMARY

An objective of the embodiments of the disclosure is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions. Embodiments of the current invention use a new approach, where each network entity has an attribute called Hardware Parsing Depth Capability (PDC attribute). The attribute may be known to the network entity and may be communicated to other network entities in a variety of ways. The disclosure aims at providing a solution for ensuring that a critical prefix of a protocol data unit (PDU) is not longer than a parsing depth capability (PDC) of an entity processing the PDU.

The above and further objectives are solved by the subject matter of the independent claims. Further advantageous embodiments can be found in the dependent claims.

According to a first aspect of the present invention there is provided a packet processing device for processing packets received in a computer network, configured to: - receive a capacity packet during a setup of a computer network connection with a remote device; decode a capacity packet value indicating a parsing depth from a header of the capacity packet during the setup; encode transport layer packets according to the capacity packet value; and send the transport layer packets to the remote device over the computer network.

According to a second aspect of the present invention there is provided a packet processing device for processing packets received in a computer network, configured to: encode in a header of a capacity packet a capacity packet value indicative of a parsing depth, wherein the capacity packet value is used for processing packets at transport layer; and send the capacity packet during a setup of a computer network connection with a remote device.

According to a third aspect of the present invention there is provided a method of processing packets received in a computer network, comprising:

- receiving a capacity packet during a setup of a computer network connection with a remote device; decoding a parsing depth value from a header of the capacity packet during the setup; encoding transport layer packets according to the parsing depth value; and sending the transport layer packets to the remote device over the computer network.

According to a fourth aspect of the present invention there is provided a method of processing packets received in a computer network, comprising: encoding in a header of a capacity packet a capacity packet value indicative of a parsing depth, wherein the capacity packet value is used for processing packets at transport layer; and sending the capacity packet during a setup of a computer network connection with a remote device.

According to a fifth aspect of the present invention there is provided a computer software product comprising program code for performing the method of the third aspect and/or the method of the fourth aspect when executed on a computer.

According to a sixth aspect of the present invention there is provided a non-transitory computer-readable storage medium that stores therein a computer program product which, when executed by a processor, causes the method according to the third aspect and/or the fourth aspect to be performed. The computer readable storage medium, comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive.

According to a seventh aspect of the present invention there is provided an apparatus for processing packets received in a computer network includes a processor and a memory. The memory is storing instructions that cause the processor to performing the method of the third aspect and/or the method of the fourth aspect when executed on a computer.

Conventionally, if a packet header includes a critical prefix that is too long to be read by hardware of a device, it may be partially parsed and/or processed by software, which may be insufficient and/or may result in poor performance. An improvement provided by the disclosed aspects is the use of the parsing depth in the network protocol itself, by encoding it in a capacity packet header. By sending the capacity packet during setup of the network connection with the packet processing device, the announced parsing capacity ensures that the critical prefixes of transport layer packets sent to the packet processing device are not longer than the PDC of the packet processing device hardware, thereby enabling flexibility and interoperability between network devices from different vendors. Further advantages of the disclosed aspects include: facilitating taking advantage of hardware capabilities of a network devices in a heterogeneous environment; usability at various layers of the protocol stack; usability for various network protocols in various environments; and ease of detection of the PDC, such as by a packet analyzer.

In a further implementation form of the first aspect, the packet processing device is further configured to receive the capacity packet from the remote device or from a central network node. An improvement of the implementation form may include streamlined direct availability of the capacity packet data without the need for additional device involvement. Alternatively, an improvement may be found, e.g., in centrally managed networks, in which the network is managed by a central node configured to streamline access to information about the PDC attribute of each entity, and share this information in an optimized manner with some or all other entities, as relevant.

In a further implementation form of the first aspect, the computer network is a software defined network (SDN). An improvement of the implementation form may include, for example, an SDN controller configured to streamline access to data regarding the PDC attribute of each affiliated entity, and to distribute this information in an optimized manner with some or all other entities, as relevant. Use of the SDN may facilitate a dynamic, flexible, programmatically efficient network configuration that improves both network performance and monitoring. In a further implementation form of the first aspect, the packet processing device is further configured to encode the transport layer packets according to a user datagram protocol (UDP). Announcement using a central entity is applicable to the connectionless communication model of UDP. Improvements related to use of UDP include providing of checksums for data integrity and providing of port numbers for addressing different functions at source and destination of transmitted datagrams. Setup of communication channels does not require prior communication. Use of UDP may avoid unnecessary error-checking overhead in the protocol stack. Likewise, since the parsing depth of the recipient hardware is made known to the sender, there may be less need for retransmission-related delays.

In a further implementation form of the first aspect, the packet processing device is further configured to execute an enforcement function to assure that a critical prefix of each of the transport layer packets complies with the capacity packet value. The enforcement function may provide an improvement by applying the PDC of a peer network device when sending a packet to the peer network device, thus enforcing that critical prefixes of sent packets are within the PDC of the peer network device. Consequently, the packet processing device does not generate packets in which a critical header or part thereof exceed the PDC.

In a further implementation form of the first aspect, the packet processing device is further configured to have a different parsing depth capacity for processing packets at the transport layer; wherein the packet processing device is further configured to encode, in a header of a different capacity packet, a different capacity packet value indicative of the different parsing depth; and wherein the packet processing device is further configured to send the different capacity packet during the setup. By sending the capacity packet during setup of the network connection, the announced parsing capacity ensures that the critical prefixes of transport layer packets sent to the packet processing device are not longer than the PDC of the packet processing device hardware, thereby enabling flexibility and interoperability between network devices from different vendors.

In a further implementation form of the first aspect, the capacity packet is a Transmission Control Protocol (TCP) synchronize (SYN) packet. By including the parsing depth of the remote device, e.g., in a TCP option, during connection initiation via a TCP SYN packet, compliance with the PDC of the remote device may be ensured for all packets transmitted from the packet processing device to the remote device following the initial TCP SYN packet. Encoding/decoding of a capacity packet value at a later stage may result in noncompliance with the PDC of the remote device for packets transmitted prior to the encoding/decoding of the capacity packet value. In a further implementation form of the first aspect, the capacity packet is a Quick UDP Internet Connections, QUIC, Initial packet and the parsing depth value is defined as a transport parameter. QUIC has shorter latencies and is more flexible than TCP. By defining the parsing depth value as one of the transport parameters of QUIC Initial packets, compliance with the PDC of the remote device may be ensured for all packets transmitted from the packet processing device following the QUIC initial packet. Encoding/decoding of a capacity packet value at a later stage may result in noncompliance with the PDC of the remote device for packets transmitted prior to the encoding/decoding of the capacity packet value.

In a further implementation form of the first aspect, the packet processing device is further configured to update Layer 2 (L2), i.e. Data link layer, headers of packets according to the capacity packet value. When the parsing depth is defined for the data-link layer of the Open Systems Interconnection (OSI) model, or Layer 2, it includes all packet headers, including L2, Layer 3 (L3), i.e. Network layer, Layer 4 (L4), i.e. Transport layer, and any other headers. Accordingly, the parsing depth is not header-specific. A parsing depth announcement from a different level may be modified by a Layer 2 hardware module that may update the announced depth in order to compensate for a Layer 2 header not considered by the software module.

In a further implementation form of the second aspect, the capacity packet value is defined for a Transmission Control Protocol (TCP) and defines a parsing depth for parsing any header starting from a Layer 4 header, by a packet processing unit. TCP may facilitate reliable, ordered and error-checked data transmission between applications running on devices communicating over an IP network. Protocols of the transport layer, or L4, are configured to provide host-to-host communication services for applications. L4 may facilitate connection- oriented communication, reliability, flow control, and multiplexing. By defining the parsing depth for L4 for TCP, the PDC includes all headers starting from the L4 header. Accordingly, the actual parsing depth, including the L2 and L3 headers, is greater than the announced L4 parsing depth.

The method according to the third aspect or the fourth aspect can be extended into implementation forms corresponding to the implementation forms of the packet processing device according to the first aspect or the second aspect respectively. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the packet processing device. The advantages of the methods according to the third aspect or the fourth aspect are the same as those for the corresponding implementation forms of the packet processing device according to the first aspect or the second aspect respectively.

Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks automatically. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

FIG. 1 is a schematic diagram of an exemplary networked system in accordance with principles of the invention;

FIG. 2 is a schematic flow chart of an exemplary process in accordance with principles of the invention;

FIG. 3 is a schematic flow chart of an exemplary process in accordance with principles of the invention;

FIG. 4 is a schematic illustration of an illustrative architecture in accordance with principles of the invention;

FIG. 5 is a schematic illustration of an illustrative architecture in accordance with principles of the invention; and

FIG. 6 is a schematic illustration of an illustrative architecture in accordance with principles of the invention.

DETAILED DESCRIPTION

The present invention, in some embodiments thereof, relates to digital communication, and, more specifically, but not exclusively, to packet-switching data networks.

According to some embodiments of the present invention, there are provided apparatuses and methods for ensuring that one or more than one critical prefix of one or more than one protocol data unit (PDU) is not longer than a parsing depth capability (PDC) of an entity processing the PDU. The apparatus may include, and the methods may involve, one or more systems, devices and/or computer program products.

The apparatus may include and the methods may involve one or more than one packet processing device. The packet processing device(s) may be configured for processing packets received in a computer network. The packet processing device(s) may be configured for processing one or more than one PDU. The packet processing device(s) may be configured for processing one or more packets. The packets may include the one or more than one PDU. The packets may be received via one or more than one computer network.

The apparatus may involve and the methods may include a method of processing one or more of the packets. The packet processing device(s) may be configured to implement one or more steps of the method. The packet processing device(s) may include and/or make use of hardware and/or software configured for the processing of the packets. The packet processing device(s) may include and/or make use of hardware and/or software configured to implement the one or more steps of the method. The packet processing device(s) may include circuitry configured to execute one or more steps of the method. The packet processing device(s) may include and/or make use of one or more than one storage medium configured to store one or more steps of the method. The packet processing device(s) may include and/or make use of one or more than one processor configured to execute one or more steps of the method.

The method may involve and the packet processing device(s) may include one or more than one computer software product. The software product may include software and/or hardware. The software product may include program code for performing the method when executed on one or more than one computer. The software product may include program code for performing one or more steps of the method when executed on one or more than one computer.

The packet processing device(s) and the method may include or involve one or more than one computer-readable storage medium. The computer readable medium may be non-transitory. The computer readable medium may include or involve one or more than one memory. The computer readable medium may store machine-readable instructions. The machine-readable instructions may include the method. The machine-readable instructions may include one or more steps of the method. The storage medium may store therein one or more than one computer program product. The computer program product may, when executed by a processor, cause one, some or all steps of the method to be performed. The packet processing device(s) may include the software product and/or the storage medium. The packet processing device(s) may include or involve the processor.

The packet processing device(s) may involve or be included in one or more than one personal computer. The packet processing device(s) may involve or be included in one or more than one server. The packet processing device(s) may include one or more than one network interface card (NIC), switch(es), router(s), network appliance and/or middlebox(es), such as firewall(s), network address translator(s), load balancers, and/or deep packet inspection box(es). The packet processing device may be configured for receiving one or more than one capacity packet. The receiving of the capacity packet may be during setup of one or more than one computer network connection with one or more than one remote device. The method may include the setup of the network connection. The method may include the receiving of the capacity packet. The remote device may include one, some or all features of the packet processing device. The network connection may be via wired and/or wireless hardware. The receiving of the capacity packet may be from the remote device. The receiving of the capacity packet may be from one or more than one central network node.

The capacity packet(s) may include the PDU(s). The capacity packet(s) may include one or more than one IP packet. The capacity packet(s) may include one or more than one header. The header(s) may include internet protocol (IP) header(s). The header(s) may include transmission control protocol (TCP) header(s). The capacity packet(s) may include TCP payload(s). The capacity packet(s) may include TCP segment(s). The payload(s) may include the TCP segment(s). The capacity packet may include one or more than one PDC announcement. The PDC announcement(s) may indicate one or more than one respective PDC of the one or more than one remote device. The header(s) may include the PDC announcement(s) .

The method may include decoding one or more than one capacity packet value from the header(s) of the capacity packet. The PDC announcement(s) may include the capacity packet value(s). The decoding may be implemented during the setup. The capacity packet value may indicate one or more than one parsing depth. The parsing depth may be of the remote device. The packet processing device may be configured for the decoding of the capacity packet value. The decoding may include announcing of a PDC of the remote device. The capacity packet value may indicate the PDC of the remote device.

The packet processing device and/or the remote device may include one or more modules. A first of the modules may generate the PDC announcement. A second of the modules may intercept the PDC announcement upon transmission to a peer network node, such as the packet processing device and/or the remote device. The interception of the PDC announcement may facilitate reducing of the announced PDC value to a new value that is applicable to the second module.

Alternatively or additionally, one or more than one network entity may be queried. The network entity may include an orchestrator entity storing PDC data for some or all of the network. In some embodiments, one or more than one central node, such as an offloading switch, facilitates ensuring that the prefix of the transport layer packets is no longer than the PDC of the remote device. The central node may facilitate segmentation of transmitted data, thereby ensuring that the prefix of the transport layer packets is no longer than the PDC of the remote device.

The method may include encoding one or more transport layer packets according to the capacity packet value. The encoding may include the interception of the PDC announcement. The encoding may include the reducing of the announced PDC value. The packet processing device may be configured for the encoding of the transport layer packets. Encoding of the transport layer packets may ensure that the prefix of the transport layer packets isn’t longer than the PDC of the remote device.

The method may include sending the transport layer packets to the remote device over the computer network. The sending may be of the encoded transport layer packets. The packet processing device may be configured for the sending of the transport layer packets.

The computer network may include a software defined network (SDN). The SDN may facilitate dynamic and programmatically efficient network configurations. The SDN may improve network performance and monitoring. The SDN may disassociate a forwarding process of network packets from a routing process. The SDN may centralize network intelligence in one network component. A control plane of the SDN may include one or more controllers.

In some embodiments, the packet processing device may be configured to use a simple connectionless communication model with a minimum of protocol mechanisms. For example, the packet processing device may be configured to encode the transport layer packets according to the User Datagram Protocol (UDP). Use of UDP may provide for checksums for data integrity and port numbers for addressing different functions at both the packet processing device and at the remote device.

In some embodiments the packets may be encapsulated. The network may include a cloud environment. A host entity may facilitate ensuring that the prefix of the transport layer packets is no longer than the PDC for a virtual machine and/or for host traffic. As needed, additional headers may be added to transmitted packets to indicate the relevant PDCs.

Some embodiments of the invention may use network virtualization technology, such as Virtual Extensible LAN (VXLAN). The method may include encapsulation of OSI layer 2 Ethernet frames in layer 4 UDP datagrams. VXLAN endpoints may include virtual or physical switch ports. As infrastructure headers are unknown to a virtual machine or application processing the PDU, using VXLAN encapsulation, a number of bytes of the PDU may be reduced to the PDC of the virtual machine or application, transparently. In some embodiments, such as when error-correction may be necessary at a network interface level, an application of the packet processing device may use, for example, Transmission Control Protocol (TCP) and/or Stream Control Transmission Protocol (SCTP).

The packet processing device may be configured for execution of one or more than one enforcement function. The method may include the execution of the enforcement function. The enforcement function may ensure that one or more than one critical prefix of one or more of the transport layer packets complies with the capacity packet value. The enforcement function may ensure that the critical prefix of each of the transport layer packets complies with the capacity packet value. The enforcement function may include the interception of the PDC announcement. The enforcement function may include the reducing of the announced PDC value. The encoding of the transport layer packets may include the enforcement function.

The packet processing device may be configured to have a different PDC for processing packets at the transport layer. The packet processing device may be configured to encode, in a header of a different capacity packet, a different capacity packet value indicative of the different parsing depth. The different parsing depth may be of the packet processing device and/or of one or more than one additional device. The packet processing device may be configured to send the different capacity packet during the setup. The additional device may include features of the packet processing device and/or the remote device.

The capacity packet may include a Transmission Control Protocol (TCP) SYN packet. By including the parsing depth of the remote device, e.g., in a TCP option, during connection initiation via a TCP SYN packet, compliance with the PDC of the remote device may be ensured for all packets transmitted from the packet processing device to the remote device following the initial TCP SYN packet. Encoding/decoding of a capacity packet value at a later stage may result in noncompliance with the PDC of the remote device for packets transmitted prior to the encoding/decoding of the capacity packet value.

The capacity packet may include a QUIC Initial packet. The parsing depth value may be defined as a transport parameter. QUIC has shorter latencies and is more flexible than TCP. By defining the parsing depth value as one of the transport parameters of QUIC Initial packets, compliance with the PDC of the remote device may be ensured for all packets transmitted from the packet processing device following the QUIC initial packet. Encoding/decoding of a capacity packet value at a later stage may result in noncompliance with the PDC of the remote device for packets transmitted prior to the encoding/decoding of the capacity packet value.

The packet processing device may be configured to update Layer 2 headers of packets according to the capacity packet value. When the parsing depth is defined for the data-link layer of the Open Systems Interconnection (OSI) model, or Layer 2, it includes all packet headers, including L2, Layer 3 (L3), Layer 4 (L4), and any other headers. Accordingly, the parsing depth is not header-specific. A parsing depth announcement from a different level may be modified by a Layer 2 hardware module that may update the announced depth in order to compensate for a Layer 2 header not considered by the software module.

The packet processing device may be configured to encode a capacity packet value indicative of a parsing depth. The parsing depth may include the PDC of the packet processing device. The parsing depth may include the PDC of a different network device. The capacity packet value may be encoded by the packet processing device in the capacity packet. The capacity packet value may be encoded in a header of the capacity packet. The capacity packet value may be used for processing packets at a transport layer. The capacity packet value may be defined for a Transmission Control Protocol (TCP). The capacity packet value may define a parsing depth for parsing any header starting from a Layer 4 header by the packet processing unit.

The packet processing device may be configured for sending the capacity packet. The sending may be during setup of a computer network connection with a remote device. The sending may be to the remote device. The remote device may include one, some or all features of the packet processing device. The remote device may include a peer device and/or a central node.

The apparatus may include and the method may involve one or more than one non- transitory computer-readable storage medium. The computer-readable storage medium may store therein a computer program product. The methods may involve and the apparatus may include one or more than one computer software product. The computer program product may include the computer software product. The computer program product may, when executed by a processor, cause the method to be performed. The software product may include program code for performing the method when executed on one or more than one computer. The method may include the receiving of the capacity packet during setup of the computer network connection with the remote device. The method may include the decoding of the parsing depth value from a header of the capacity packet during the setup. The method may include encoding transport layer packets according to the parsing depth value. The method may include sending the transport layer packets to the remote device over the computer network. The method may include the encoding in the header of the capacity packet the capacity packet value indicative of the parsing depth. The capacity packet value may be used for the processing of the packets at the transport layer. The method may include the sending of the capacity packet during the setup of the computer network connection with the remote device.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer program code comprising computer readable program instructions embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

The computer readable program instructions for carrying out operations of the present invention may be written in any combination of one or more programming languages, such as, for example, assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Referring now to the drawings, FIG. 1 shows an illustrative block diagram of illustrative packet processing system 100. System 100 includes packet processing systems 141, 181 and/or 191. System 141 may include processor 143 for controlling operation of system 141 and associated components of system 141. In some embodiments of the invention, system 141 includes memory 155. Processor 143 executes software running on system 141, such as software including one or more steps of the method.

Memory 155 comprises any suitable storage technology, such as a hard drive. Memory 155 stores software including application(s) 159. Application(s) 159 may include software comprising one or more steps of the method. Application program(s) 159, used by system 141, may include computer executable instructions including steps of the method. Alternatively or additionally, some or all of computer executable instructions, such as those including steps of the method, may be embodied in hardware or firmware. System 141 may execute the instructions embodied by the software to perform various functions, such as one or more steps of the method.

Network connections of system 100 include local area network (LAN) 153 and wide area network (WAN) 169, but may also include other networks. System 100 includes network interface controller (NIC) 151 and other means for establishing communications over WAN 169, such as Internet 171. System 141 is connected to other systems via NIC 151. System 141 operates in a networked environment supporting connections to one or more remote systems, such as systems 181 and 191. Systems 181 and 191 may be included in and/or involve one or more personal computers or servers that comprise many or all of the elements described above regarding system 141.

It is understood that network connections shown are illustrative and other means of establishing a communications link between systems 141, 181 and 191 may be used. The existence of various well-known protocols such as TCP/IP, UDP/IP, QUIC, Ethernet, FTP, HTTP and the like is presumed, and system 100 can be operated in a client-server configuration including one or more than one web-based server. The web-based server may be configured to transmit data to any other suitable system, such as systems 181 and 191.

Systems 141, 181 and/or 191 may also include various other components, such as a battery, speaker, and antennas (not shown).

Systems 181 and 191 may be portable devices such as a laptop, Smartphone, or any other suitable device for storing, transmitting and/or transporting relevant information. Systems 181 and 191 may include other devices. These devices may be identical to system 100 or different. The differences may be related to hardware components and/or software components.

System 100 may include some or all features of the disclosed apparatus and/or devices. System 100 may be configured to implement one, some or all steps of the disclosed methods. The packet processing device may include systems 141, 181 and/or 191. The remote device may include systems 141, 181 and/or 191. Systems 141, 181 and/or 191 may include and/or execute the disclosed computer software product(s). Memory 155 may store therein a computer program product which, when executed by a processor, such as processor 143, causes one or more steps of the method to be performed. The computer network connection may include LAN 153 and/or WAN 169.

Systems 181 and/or 191 may execute the encoding in the header of the capacity packet the capacity packet value indicative of the parsing depth of hardware of systems 181 and/or 191. Systems 181 and/or 191 may execute the sending of the capacity packet during the setup of the computer network connection.

Processor 143 may execute the decoding of the parsing depth value from the header of the capacity packet during the setup. Processor 143 may execute the encoding of the transport layer packets according to the parsing depth value. Processor 143 may execute the sending of the transport layer packets to systems 181 and/or 191 over LAN 153 and/or WAN 169.

Systems 141, 181 and/or 191 may run TCP. Illustratively, a PDC attribute of system 141, such as of NIC 151, may be 40 bytes and a PDC attribute of systems 181 and/or 191 may be 60 bytes. System 141 may store and/or have access to the PDC attribute of systems 181 and/or 191. Systems 181 and/or 191 may store and/or have access to the PDC attribute of system 141. When NIC 151 sends a TCP segment to systems 181 and/or 191, NIC 151 is configured to limit a TCP Option field in packets sent to 20 bytes. Similarly, when NICs of systems 181 and/or 191 send a TCP segment to A, the NICs of systems 181 and/or 191 are configured to limit the TCP Option field in the packets it sends to 0 bytes, i.e., there should be no Option field.

The method may include defining a PDC attribute for each of a plurality of network entities. The network entities may include hosts, and/or nodes, such as systems 141, 181 and/or 191. The method may include transmitting the PDC attribute of one of the network entities to a second of the network entities. The network entities may run one or more than one connection setup protocol, such as TCP, QUIC and/or RDMA. The network entities may communicate via one or more than one centrally managed network, such as an SDN. The centrally managed network may be managed by a central node, such as an SDN controller or a Network Management System (NMS). The central node may obtain information about the PDC attribute of the network entities. The central node may perform a transmitting of the information with one, some or all of the network entities. The transmitting may be performed as needed and/or relevant.

The method may include determining a local PDC of a first network device, such as system 141. The local PDC may be of NIC 151. The local PDC may be with respect to a beginning of a packet. The local PDC may be with respect to a beginning of one of protocol headers of the packet.

The method may include announcing a value of the local PDC. The announcing may include an announcement of data indicating the local PDC. The announcing may be to a second network device, such as systems 181 and/or 191. The announcing may be executed during connection setup between the first and second network devices. Alternatively or additionally, the announcing of the PDC value may be to a central network node. Alternatively or additionally, the method may include allowing the central network node to obtain the PDC value of the local device. In some embodiments, systems 181 and/or 191 may include the central node.

The method may include maintaining the PDC value of each peer network device. The PDC value may be obtained from the peer network device during connection setup. Alternatively or additionally, the PDC value may be obtained from the central node.

The method may include one or more than one enforcement function. The enforcement function may be implemented by machine readable code. The machine readable code may be included in the disclosed computer software product(s). The machine readable code may be stored in memory 155 and/or may be executed by processor 143. The enforcement function may apply the PDC of the peer network device, such as system(s) 181 and/or 191, when sending a packet to the peer network device, thus enforcing that a critical prefix of the packet is within the PDC of the peer network device. Consequently, a network device, such as system 141, implementing the enforcement function may be prevented from generating packets in which the critical header or a part of it exceed the PDC of peer devices, such as system(s) 181 and/or 191.

According to some embodiments of the invention, a plurality of network nodes may communicate with each other over one or more than one network protocol. One or more of the network nodes may maintain one or more than one attribute indicating one or more than one parsing depth of one or more than one peer node. Each network node may generate packets for transmission using the parsing depth of the peer node as a criterion for limiting the length of a packet header. The node may not generate any headers, such as optional headers, extended headers, or Type/Length/V alue (TLV) fields, which exceed the parsing depth of the peer node.

In some embodiments, a network device includes and/or implements a plurality of modules. A first of the plurality of modules may execute the announcing of the PDC value. A second of the modules may execute an interception of a PDC announcement. The interception may be executed upon transmission to a peer network node. The announced PDC value may be reduced to a new value applicable to the second module. Upon the announcing, the second of the modules may execute the interception of the PDC announcement. Upon the interception, the announced PDC value may be reduced to the new value.

The PDC may be defined with respect to the beginning of the packet. Alternatively or additionally, the PDC may be defined with respect to the beginning of a specific protocol header in a specific layer. For example, if a parsing depth is defined only for Layer 4, e.g., for TCP, the defined parsing depth may include headers starting from the Layer 4 header. Accordingly, the actual parsing depth, including the L2 and L3 headers, may be greater than the announced L4 parsing depth. The starting point of the PDC, e.g., the beginning of the packet or beginning of a specific header, may be previously agreed upon and/or defined with regard to the communicating network devices and/or may be announced as part of the announcement.

The central network entity may include a controller and/or a network management system. The central network entity may read the PDC of each network device. The central network entity may execute configuration, in each network device, of the PDCs of peer network devices. The configuration may be via a network management protocol, such as the Network Configuration Protocol (NETCONF) and/or the Simple Network Management Protocol (SNMP), or any other suitable network management protocol. Announcement during connection setup may be applicable to connection-oriented protocols, such as TCP). Announcement using a central entity may be applicable to connection- oriented and/or connectionless protocols, such as UDP.

The software product may include one or more than one extension for low layer interception. The parsing depth announcement may take place between two connection endpoints, such as systems 141 and 191. An endpoint may include a plurality of layers. The layers may be implemented in different modules, such as an application layer module implemented in software, and a link layer module implemented in hardware .A low layer module may intercept the announcement of an endpoint. The low layer module may modify the announced parsing depth based on a respective header depth of a current layer. For example, a Layer 4 software module may announce a parsing depth from the beginning of the Layer 4 header. The announcement may be modified by a Layer 2 hardware module. The L2 module may update the announced depth in order to compensate for a Layer 2 header that is not considered by the software module.

Reference is now made to FIG. 2 schematically showing illustrative parsing depth implementation process 200. Process 200 may be implemented by systems 141, 181 and/or 191 shown in FIG. 1. Process 200 may begin at step 201.

At step 201, a packet processing device, such as systems 141, 181 and/or 191, may receive a capacity packet during setup of a computer network connection with a remote device. The receiving of the capacity packet may be from the remote device. Alternatively, the receiving of the capacity packet may be from a central network node. The capacity packet may include a header including an encoded capacity packet value indicating a PDC of the remote device.

At step 203, the packet processing device decodes the capacity packet value from the header of the capacity packet. The decoding may be implemented during the setup of the network connection.

At step 205, the packet processing device encodes one or more transport layer packets according to the decoded capacity packet value. Encoding of the transport layer packets may ensure that the prefix of the transport layer packets isn’t longer than the PDC of the remote device.

At step 207, the packet processing device sends the encoded transport layer packets to the remote device over the computer network. The sending may be of the encoded transport layer packets. Reference is now made to FIG. 3 schematically showing illustrative parsing depth announcement process 300. Process 300 may be implemented by systems 141, 181 and/or 191 shown in FIG. 1. Process 300 may begin at step 301.

At step 301, a packet processing device, such as systems 141, 181 and/or 191, encodes in a header of a capacity packet, a capacity packet value indicative of a PDC. The PDC may be of the packet processing device and/or of one or more than one additional device, such as of the remote device described with regard to process 200 depicted in FIG. 2. Step 301 may include PDC announcement encapsulation. PDC announcement data may be integrated into a connection setup protocol. The encoded capacity packet may include a Transmission Control Protocol (TCP) SYN packet. The parsing depth may be announced using a TCP option in TCP SYN packets, i.e., during connection initiation.

At step 303, the packet processing device sends the capacity packet during network connection setup with a peer device, such as with one of the devices described with regard to process 200 depicted in FIG. 2.

The network entities may run one or more than one connection setup protocol, such as TCP, Quick UDP Internet Connections (QUIC) and/or Remote Direct Memory Access (RDMA). By including the PDC, e.g., in a TCP option, during connection initiation via a TCP SYN packet, compliance with the PDC of the packet processing device may be ensured for all packets transmitted from the peer device to the packet processing device following the sending of the initial TCP SYN packet.

Reference is now made to FIG. 4 showing a schematic diagram of illustrative capacity packet 400. Capacity packet 400 may be generated by system(s) 141, 181 and/or 191 shown in FIG. 1. Capacity packet 400 may be sent via network connections, such as connections 153 and/or 169 shown in FIG. 1.

Capacity packet 400 may be encoded at step 301 shown in FIG. 3. Capacity packet 400 may be sent at step 303 shown in FIG. 3. Capacity packet 400 may be received at step 201 shown in FIG. 2. Capacity packet 400 may be decoded at step 203 shown in FIG. 2.

Capacity packet 400 may include an IP packet containing a Transmission Control Protocol (TCP) segment. The capacity packet may include a TCP SYN packet. Packet 400 may include payload 401, TCP Options 403, TCP Header 405, IP header 407 and Ethernet header 409.

Capacity packet 400 may be generated via PDC announcement encapsulation. The parsing depth may be announced using TCP Options 403, i.e., during connection initiation. A packet processing device may send capacity packet 400 during network connection setup with a peer device, such as with one of the devices described with regard to process 200 depicted in FIG. 2. By including the PDC, e.g., in a TCP option, during connection initiation via a TCP SYN packet, compliance with the PDC of the packet processing device may be ensured for all packets transmitted from the peer device to the packet processing device following the sending of the initial TCP SYN packet.

In some embodiments, the network entities may run the QUIC transport layer network protocol. As such, an exchange of setup keys and supported protocols may be part of an initial handshake process. Upon opening of a network connection, a QUIC connection setup uses QUIC Initial packets configured to include data for future packets, thereby eliminating a need to set up a TCP connection and then negotiate a security protocol using additional packets. Other protocols may be similarly serviced, combining multiple steps into a single request-response. Received data may be used for subsequent requests in an initial setup and for subsequent requests that might otherwise have had to be negotiated as separate connections.

Reference is now made to FIG. 5 showing a schematic diagram of illustrative QUIC initial packet 500. QUIC initial packet 500 may include a PDC announcement in the QUIC transport protocol. QUIC initial packet 500 may be generated by systems 141, 181 and/or 191 shown in FIG. 1. QUIC initial packet 500 may be sent via network connections, such as connections 153 and/or 169 shown in FIG. 1.

QUIC initial packet 500 may be encoded at step 301 shown in FIG. 3. QUIC initial packet 500 may be sent at step 303 shown in FIG. 3. QUIC initial packet 500 may be received at step 201 shown in FIG. 2. QUIC initial packet 500 may be decoded at step 203 shown in FIG. 2.

QUIC initial packet 500 includes transport parameters 501, QUIC Header 503, UDP Header 505, IP header 507 and Ethernet header 509. Transport parameters 501 are related to the QUIC connection. In QUIC initial packet 500, the PDC is defined as one of transport parameters 501.

QUIC initial packet 500 may be generated via PDC announcement encapsulation. The parsing depth may be announced using transport parameters 501. The packet processing device may send QUIC initial packet 500 during network connection setup with a peer device, such as with one of the devices described with regard to process 200 depicted in FIG. 2. By including the PDC in transport parameters 501, during connection initiation, compliance with the PDC of the packet processing device may be ensured for all packets transmitted from the peer device to the packet processing device following the sending of QUIC initial packet 500. By including the parsing depth in the QUIC network protocol itself, the announced parsing capacity enables flexibility and interoperability between network devices from different vendors.

The parsing depth may be announced in various ways that are a variation of the proposed method. For example the announced PDC may be announced not only during connection setup, but also at any time during the lifetime of the connection. Another possible variation is to use negative announcement, i.e., to announce the PDC only when it is exceeded, as a form of error message that is sent to the peer network device.

In some embodiments, the PDCs may be included in level 2 payloads of transmitted packets. Reference is now made to FIG. 6 showing a schematic diagram of illustrative packet 600. Packet 600 may include a PDC announcement. Packet 600 may be generated by systems 141, 181 and/or 191 shown in FIG. 1. Packet 600 may be sent via network connections, such as connection 153 shown in FIG. 1.

Packet 600 may be encoded at step 301 shown in FIG. 3. Packet 600 may be sent at step 303 shown in FIG. 3. Packet 600 may be received at step 201 shown in FIG. 2. Packet 600 may be decoded at step 203 shown in FIG. 2.

Packet 600 includes level 2 payload 601 and header 603. In packet 600, the PDC is included in payload 601. Packet 600 may be configured to involve any suitable network protocol.

In some embodiments, packet 600 may be generated via PDC announcement encapsulation. The parsing depth may be announced using payload 601. The packet processing device may send packet 600 during network connection setup with a peer device, such as with one of the devices described with regard to process 200 depicted in FIG. 2. By including the PDC in payload 601, e.g., during connection initiation, compliance with the PDC of the packet processing device may be ensured for all packets transmitted from the peer device to the packet processing device following the sending of packet 600.

It is expected that during the life of a patent maturing from this application many relevant systems, methods and computer programs will be developed and the scope of the terms security code and encryption technologies are intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of. The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word “exemplary” is used herein to mean “serving as an example, an instance or an illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the invention may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible sub ranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed sub ranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals there between.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the invention may include a plurality of “optional” features unless such features conflict. It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub- combination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.

In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.

Claims

WHAT IS CLAIMED IS:

1. A packet processing device for processing packets received in a computer network, the device being configured to: receive a capacity packet during a setup of a computer network connection with a remote device; decode a capacity packet value indicating a parsing depth from a header of the capacity packet during the setup; encode transport layer packets according to the capacity packet value; and send the transport layer packets to the remote device over the computer network.

2. The packet processing device of claim 1, wherein the packet processing device is further configured to receive the capacity packet from the remote device or from a central network node.

3. The packet processing device of any of the previous claims, wherein the computer network is a software defined network (SDN).

4. The packet processing device of any of the previous claims, wherein the packet processing device is further configured to encode the transport layer packets according to a user datagram protocol (UDP).

5. The packet processing device of any of the previous claims, wherein the packet processing device is further configured to execute an enforcement function to assure a critical prefix of each of the transport layer packets complies with the capacity packet value.

6. The packet processing device of any of the previous claims, further configured to have a different parsing depth capacity for processing packets at the transport layer; wherein the packet processing device is further configured to encode, in a header of a different capacity packet, a different capacity packet value indicative of the different parsing depth; and wherein the packet processing device is further configured to send the different capacity packet during the setup.

7. The packet processing device of any of the previous claims, wherein the capacity packet is a Transmission Control Protocol (TCP) SYN packet.

8. The packet processing device of any of the previous claims, wherein the capacity packet is a Quick UDP Internet Connections, QUIC, Initial packet and the parsing depth value is defined as a transport parameter.

9. The packet processing device of any of the previous claims, further configured to update Layer 2 headers of packets according to the capacity packet value.

10. A packet processing device for processing packets received in a computer network, the device being configured to: encode in a header of a capacity packet a capacity packet value indicative of a parsing depth, wherein the capacity packet value is used for processing packets at transport layer; and send the capacity packet during a setup of a computer network connection with a remote device.

11. The packet processing device of claim 10, wherein the capacity packet value is defined for a Transmission Control Protocol (TCP) and defines a parsing depth for parsing any header starting from a Layer 4 header by a packet processing unit.

12. A method of processing packets received in a computer network, comprising: receiving a capacity packet during a setup of a computer network connection with a remote device; decoding a parsing depth value from a header of the capacity packet during the setup; encoding transport layer packets according to the parsing depth value; and sending the transport layer packets to the remote device over the computer network.

13. A method of processing packets received in a computer network, comprising: encoding in a header of a capacity packet a capacity packet value indicative of a parsing depth, wherein the capacity packet value is used for processing packets at transport layer; and sending the capacity packet during a setup of a computer network connection with a remote device.

14. A computer software product comprising program code for performing the method of claim 12 and/or the method of claim 13 when executed on a computer.

15. A non-transitory computer-readable storage medium that stores therein a computer program product which, when executed by a processor, causes the method according to claim 12 and/or 13 to be performed.