Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Definitions

• 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.
• 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.
• PDUs may include packets of the internet protocol (IP) layer and segments of the transmission control protocol (TCP) layer.
• IP internet protocol
• TCP transmission control protocol
• 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.
• 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.
• PDC parsing depth capability
• 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.
• hosts such as a personal computer or a server, that use Network Interface Cards (NICs), switches, routers and/or middle boxes, such as firewalls.
• NICs Network Interface Cards
• middle boxes such as firewalls.
• 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
• 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.
• 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).
• 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.
• Embodiments of the disclosure 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.
• PDU protocol data unit
• PDC parsing depth capability
• 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.
• 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.
• a method of processing packets received in a computer network comprising:
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the computer network is a software defined network (SDN).
• SDN software defined network
• 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.
• 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.
• UDP user datagram protocol
• 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.
• 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.
• 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.
• 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.
• the capacity packet is a Transmission Control Protocol (TCP) synchronize (SYN) packet.
• TCP Transmission Control Protocol
• SYN Transmission Control Protocol synchronize
• 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.
• the parsing depth value is defined 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 is further configured to update Layer 2 (L2), i.e. Data link layer, headers of packets according to the capacity packet value.
• L2 i.e. Data link layer
• 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.
• OSI Open Systems Interconnection
• 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 Transmission Control Protocol
• 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.
• 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.
• 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.
• 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.
• a data processor such as a computing platform for executing a plurality of instructions.
• 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.
• 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.
• 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.
• FIG. 6 is a schematic illustration of an illustrative architecture in accordance with principles of the invention.
• the present invention in some embodiments thereof, relates to digital communication, and, more specifically, but not exclusively, to packet-switching data networks.
• PDC parsing depth capability
• 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
• 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.
• 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.
• 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).
• 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.
• the packet processing device may be configured to use a simple connectionless communication model with a minimum of protocol mechanisms.
• the packet processing device may be configured to encode the transport layer packets according to the User Datagram Protocol (UDP).
• UDP User Datagram Protocol
• 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.
• 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.
• a number of bytes of the PDU may be reduced to the PDC of the virtual machine or application, transparently.
• an application of the packet processing device may use, for example, Transmission Control Protocol (TCP) and/or Stream Control Transmission Protocol (SCTP).
• TCP Transmission Control Protocol
• SCTP Stream Control Transmission Protocol
• 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.
• TCP Transmission Control Protocol
• TCP SYN Transmission Control Protocol
• 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.
• 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).
• TCP Transmission Control Protocol
• 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.
• 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.
• 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.
• RAM random access memory
• ROM read-only memory
• EPROM or Flash memory erasable programmable read-only memory
• SRAM static random access memory
• CD-ROM compact disc read-only memory
• DVD digital versatile disk
• memory stick a floppy disk
• a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon
• a computer readable storage medium 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.
• ISA instruction-set-architecture
• machine instructions machine dependent instructions
• microcode firmware instructions
• state-setting data state-setting data
• 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.
• 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).
• LAN local area network
• WAN wide area network
• Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
• 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.
• FPGA field-programmable gate arrays
• PLA programmable logic arrays
• 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).
• the functions noted in the block may occur out of the order noted in the figures.
• 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.
• 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.
• 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.
• NIC network interface controller
• 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.
• 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.
• 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.
• 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.
• 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.
• the announcing of the PDC value may be to a central network node.
• the method may include allowing the central network node to obtain the PDC value of the local device.
• 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.
• 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.
• TLV Type/Length/V alue
• 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.
• the second of the modules may execute the interception of the PDC announcement.
• 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.
• NETCONF Network Configuration Protocol
• SNMP Simple 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.
• Process 200 may be implemented by systems 141, 181 and/or 191 shown in FIG. 1.
• Process 200 may begin 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• TCP Transmission Control Protocol
• the parsing depth may be announced using a TCP option in TCP SYN packets, i.e., during connection initiation.
• 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).
• TCP Transmission Control Protocol
• QUIC Quick UDP Internet Connections
• RDMA Remote Direct Memory Access
• 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.
• the PDC e.g., in a TCP option
• 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.
• the network entities may run the QUIC transport layer network protocol.
• an exchange of setup keys and supported protocols may be part of an initial handshake process.
• 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.
• 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.
• 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.
• a peer device such as with one of the devices described with regard to process 200 depicted in FIG. 2.
• 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.
• 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.
• 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.
• the PDCs may be included in level 2 payloads of transmitted packets.
• 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.
• 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.
• a peer device such as with one of the devices described with regard to process 200 depicted in FIG. 2.
• compositions comprising, “comprising”, “includes”, “including”, “having” and their conjugates mean “including but not limited to”. This term encompasses the terms “consisting of and “consisting essentially of.
• 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.
• a compound or “at least one compound” may include a plurality of compounds, including mixtures thereof.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (2)

Applications Claiming Priority (1)

Publications (1)

Family

ID=69804908

Family Applications (1)

Country Status (2)

Citations (3)

Family Cites Families (4)

• 2020
  • 2020-03-12 CN CN202080043015.XA patent/CN114008998B/zh active Active
  • 2020-03-12 WO PCT/EP2020/056609 patent/WO2021180321A1/en active Application Filing

Patent Citations (3)

Also Published As

Similar Documents

Legal Events