Reducing memory size of system-generated messages prior to transmission

Abstract

Embodiments of the present disclosure relate to reducing memory size of messages generated by a system prior to transmission. A network device may receive traffic associated with a network, and may generate a system message based on the traffic. The network device may convert the system message to a binary message, and may compress the binary message to generate a compressed binary message. The network device may provide the compressed binary message to the server device, and the server device may process the compressed binary message with a decoder to generate the system message.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer networks, and more particularly, to reducing the memory size of system-generated messages before transmission. Background Art

[0002] Network Address Translation (NAT) is a method for translating network address information in a packet header. One or both of the source address and the destination address in the packet can be translated with NAT. NAT can include the translation of port numbers as well as network (e.g., Internet Protocol (IP)) addresses. Summary of the Invention

[0003] Some implementations described herein relate to a method. The method can include receiving traffic associated with a network and generating a system message based on the traffic. The method can include converting the system message into a binary message and compressing the binary message to generate a compressed binary message. The method can include providing the compressed binary message to a server device.

[0004] Some implementations described herein relate to a network device. The network device can include one or more memories and one or more processors. The one or more processors can be configured to receive traffic associated with a network and generate a system message based on the traffic. The one or more processors can be configured to convert the system message into a binary message and compress the binary message to generate a compressed binary message. The one or more processors can be configured to provide the compressed binary message to a server device such that the server device processes the compressed binary message with a decoder to generate a system message.

[0005] Some implementations described herein relate to a non-transitory computer-readable medium storing a set of instructions. When executed by one or more processors of a network device, the set of instructions can cause the network device to receive traffic associated with a network and generate a system message based on the traffic. When executed by one or more processors of a network device, the set of instructions can cause the network device to process the system message with an encoder to identify an attribute field, generate an attribute list based on the attribute field, and generate a table based on the attribute list, where the table corresponds to a binary message. When executed by one or more processors of a network device, the set of instructions can cause the network device to compress the binary message to generate a compressed binary message and provide the compressed binary message to a server device.

[0006] One aspect of the present disclosure provides a method, including: receiving, by a network device, traffic associated with a network; generating, by the network device, a system message based on the traffic; converting, by the network device, the system message into a binary message; compressing, by the network device, the binary message to generate a compressed binary message; and providing, by the network device, the compressed binary message to a server device.

[0007] According to one or more embodiments of the present disclosure, converting the system message into the binary message includes: processing the system message by an encoder to identify attribute fields, generating an attribute list based on the attribute fields, and generating a table based on the attribute list, where the binary message corresponds to the table.

[0008] According to one or more embodiments of the present disclosure, the encoder is header compression for a Hypertext Transfer Protocol (HTTP) encoder or header compression for system log attribute pairs similar to an HTTP / 2 encoder.

[0009] According to one or more embodiments of the present disclosure, the table is maintained in a first-in first-out order.

[0010] According to one or more embodiments of the present disclosure, the table is limited by a memory threshold.

[0011] According to one or more embodiments of the present disclosure, providing the compressed binary message to the server device includes: providing the compressed binary message to enable the server device to process the compressed binary message by a decoder to generate the system message.

[0012] According to one or more embodiments of the present disclosure, the decoder is header compression for a Hypertext Transfer Protocol (HTTP) decoder or header compression for system log attribute pairs similar to an HTTP / 2 decoder.

[0013] Another aspect of the present disclosure provides a network device, including: one or more memories; and one or more processors, configured to: receive traffic associated with a network; generate a system message based on the traffic; convert the system message into a binary message; compress the binary message to generate a compressed binary message; and provide the compressed binary message to a server device to enable the server device to process the compressed binary message by a decoder to generate the system message.

[0014] According to one or more embodiments of the present disclosure, the binary message includes a frame handler layer provided above a transport layer of the system message.

[0015] According to one or more embodiments of the present disclosure, wherein the binary message includes a version field, and the version field indicates that the binary message includes structured binary data.

[0016] According to one or more embodiments of the present disclosure, wherein the one or more processors are further configured to: perform Huffman coding of the system message before converting the system message into the binary message.

[0017] According to one or more embodiments of the present disclosure, wherein the binary message includes a structured data frame configured to include field block fragments.

[0018] According to one or more embodiments of the present disclosure, wherein the one or more processors for compressing the binary message to generate the compressed binary message are configured to: compress a set of field rows of the binary message to generate a field block corresponding to the compressed binary message.

[0019] According to one or more embodiments of the present disclosure, wherein the binary message includes encoded binary data.

[0020] Another aspect of the present disclosure provides a network device and a non-transitory computer-readable medium storing a set of instructions, the set of instructions including: one or more instructions that, when executed by one or more processors of the network device, cause the network device to: receive traffic associated with a network; generate a system message based on the traffic; process the system message using an encoder to identify attribute fields to generate an attribute list based on the attribute fields, and generate a table based on the attribute list, wherein the table corresponds to a binary message; compress the binary message to generate a compressed binary message; and provide the compressed binary message to a server device.

[0021] According to one or more embodiments of the present disclosure, wherein the encoder is header compression for a Hypertext Transfer Protocol (HTTP) encoder or header compression for system log attribute pairs similar to an HTTP / 2 decoder.

[0022] According to one or more embodiments of the present disclosure, wherein the table is maintained in a first-in, first-out order.

[0023] According to one or more embodiments of the present disclosure, wherein the table is limited by a memory threshold.

[0024] According to one or more embodiments of the present disclosure, wherein the binary message includes a frame handler layer provided on a transport layer of the system message.

[0025] According to one or more embodiments of the present disclosure, wherein the binary message includes a version field that indicates that the binary message includes structured binary data. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figures 1A - 1H is a diagram of an example associated with reducing the memory size of system-generated messages prior to transmission.

[0027] Figure 2 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0028] Figure 3 and Figure 4 is Figure 2 a diagram of example components of one or more devices of.

[0029] Figure 5 is a flowchart of an example process for reducing the memory size of system-generated messages prior to transmission. DETAILED DESCRIPTION

[0030] The following detailed description of example implementations refers to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0031] The system logging protocol (e.g., syslog) provides logging that allows network administrators to monitor and manage logs from different parts of a network. Messages (e.g., syslog messages) may be generated by a system (e.g., a network device) when a service session is created, when a service session is transformed (e.g., via NAT), when a service session passes through a firewall or service delivery, etc. Syslog messages may be utilized to analyze service patterns and / or subscriber usage for billing purposes, etc. With the rapid growth in technology and the growth in subscriber service and service demands, network devices are generating an increasing number of syslog messages. Thus, the memory size of syslog messages is becoming a serious bandwidth issue. General memory size compression techniques operate on data without any knowledge of the structure or semantics of the data being compressed, while syslog messages include a fixed and well-defined structure with repeating elements that are not exploited by such general techniques.

[0032] Thus, current techniques for processing system-generated messages (e.g., syslog messages) consume computing resources (e.g., processing resources, memory resources, communication resources, etc.), networking resources, etc., and are associated with failing to reduce the memory size of a large number of syslog messages, restricting the bandwidth of network devices and / or the network based on the memory size of the large number of un-reduced syslog messages, and enabling lost traffic in the network based on the memory size of the large number of un-reduced syslog messages.

[0033] Some implementations described herein relate to network devices that reduce the memory size of system-generated messages prior to transmission. For example, a network device can receive traffic associated with a network and can generate system messages based on the traffic. The network device can convert the system messages to binary messages and can compress the binary messages to generate compressed binary messages. The network device can provide the compressed binary messages to a server device, and the server device can process the compressed binary messages with a decoder to generate system messages.

[0034] In this way, prior to transmission, the network device reduces the memory size of the system-generated messages. For example, the network device can provide a new framer layer to syslog messages. The new framer layer can enable the network device to convert the syslog messages from text format to binary format and compress the syslog messages in binary format to generate compressed binary syslog messages. The network device can forward the compressed binary syslog messages to the server device for further processing. Thus, the network device saves computing resources, networking resources, etc., which would otherwise be consumed by failing to reduce the memory size of a large number of syslog messages, restricting the bandwidth of network devices and / or the network based on the memory size of the large number of un-reduced syslog messages, and enabling lost traffic in the network based on the memory size of the large number of un-reduced syslog messages.

[0035] Figures 1A - 1H A diagram of example 100 associated with reducing the memory size of system-generated messages prior to transmission. As shown in Figures 1A - 1H Example 100 includes an endpoint device and a server device associated with the network of the network device. Further details of the endpoint device, the server device, the network, and the network device are provided elsewhere in this document.

[0036] As shown in Figure 1AAs shown in, and by reference numeral 105, the network device may receive traffic destined for a destination. For example, the network device may receive traffic from an endpoint device destined for other endpoint devices and / or server devices. In another example, the network device may receive traffic from a server device destined for one or more of the endpoint devices. In some implementations, the network device may receive traffic from another network device on the network.

[0037] As further shown in Figure 1A and by reference numeral 110, the network device may generate syslog messages based on the traffic. For example, when a traffic session is created by the network device for the traffic, when a traffic session is transformed (e.g., via NAT) by the network device, when a traffic session is passed through the network device, etc., the network device may generate a system message (e.g., a syslog message). As further shown, the syslog message may include a content layer, a syslog application layer (e.g., identifying the originator of the message, the collector of the message, and / or the relay of the message), a syslog framing layer (e.g., a syslog frame handler), and a syslog transport layer (e.g., identifying the transport sender and / or the transport receiver). In some implementations, the syslog framing layer may cause the network device to convert the syslog message into a binary format to apply compression or decompression and to send or receive the syslog message.

[0038] As in Figure 1AAs further shown in and by reference numeral 115, a network device can convert a syslog message into a binary message. For example, a syslog framing layer can cause the network device to convert a syslog message from a text format to a binary format (e.g., a binary message). Except for the interpretation of the Structured-Data-Binary field in the binary message, the binary message can include an augmented Backus-Naur form (ABNF) format. The interpretation of the Structured-Data-Binary field can include binary representation rather than text (e.g., ASCII) characters. Thus, a field with a length of a bit value %x0 / %x1 can be represented as a single bit whose value is "0" or "1", and not a full byte (octet) representing the character "0" or "1" in ASCII encoding. In ABNF, a specific mapping (encoding) of values to a character set can be specified. Here, the specified encoding is a binary encoding, where each terminal value can be encoded in a specified number of bits, which is different for each format defined for the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). In some implementations, the network device can perform Huffman encoding of the syslog message before converting the syslog message into a binary message.

[0039] In some implementations, when converting a syslog message into a binary message, the network device can process the syslog message with an encoder to identify attribute fields, generate an attribute list based on the attribute fields, and generate a dynamic table based on the attribute list. The binary message can correspond to the dynamic table. The encoder can include header compression for a Hypertext Transfer Protocol (HTTP) encoder, header compression for syslog attribute pairs similar to an HTTP / 2 encoder, etc. The dynamic table can be maintained in a first-in-first-out order and can be limited by a memory threshold. More details of processing the syslog message with the encoder are provided in the following Figure 1C and 1D connection.

[0040] As further shown in Figure 1A and by reference numeral 120, the network device can compress the binary message to generate a compressed binary message. For example, when the network device processes a syslog message, the encoder that generates the dynamic table can compress the binary message to generate a compressed binary message. In some implementations, when compressing the binary message to generate a compressed binary message, the network device can utilize field section compression to compress a set of field rows of the binary message to form a field block. Further details of field section compression are provided in the following Figure 1C andFigure 1D Contact provided.

[0041] A field section can include a collection of field lines. Each field line in the field block can include a single value. A serialized field block can be divided into one or more octet sequences, called field block fragments. The first field block fragment can be transmitted within the frame payload of the structured data, which can be followed by a continuation frame to carry subsequent field block fragments. A receiving device (e.g., a server device) can reconstruct the field block by splicing its fragments and decompressing the block to reconstruct the field section. A complete field section can include a single structured data frame with the end structured data flag set, or a structured data frame with the end structured data flag not set and one or more continuation frames, where the last continuation frame can include the end structured data flag set. The field block fragments can be sent as the frame payload of the structured data or the continuation frame, as these frames carry data that can modify the compression context maintained by the receiving device. Even if a frame is to be discarded, the receiving device can reconstruct the field block and perform decompression. If it does not decompress the field block, the receiving device may terminate the connection due to a connection error.

[0042] Field compression is stateful, and a network device and / or a server device can include an encoder context and a decoder context for encoding and decoding all field blocks on a connection. A dynamic table can define the main state for each context. The dynamic table can include a maximum size set by the decoder. The network device and / or the server device can use the header table size setting to convey the size selected by the decoder context. When a connection is established, the dynamic table sizes for the decoder and the encoder can include the initial value of the header table size setting. When a set message is sent by the encoder, any change to the maximum value set using the header table size setting can take effect. The encoder can set the dynamic table to any size before the maximum value set by the decoder.

[0043] As in Figure 1AAs further shown and by reference numeral 125, a network device can provide a compressed binary message to a server device. For example, the server device can be a syslog server that receives syslog messages, monitors syslog messages, and / or stores syslog messages received from the network device. In some implementations, the network device can provide a compressed binary message (e.g., based on syslog messages) to the server device, and the server device can receive the compressed binary message. In some implementations, the server device can process the compressed binary message with a decoder to generate a syslog message. The decoder can include header compression for an HTTP decoder, header compression for syslog attribute pairs similar to an HTTP / 2 decoder, etc. Further details of processing the compressed binary message with the decoder are as follows Figures 1E - 1H Provided.

[0044] In some implementations, the server device can perform one or more actions based on the syslog message. For example, the server device can enable a network administrator to monitor and manage syslog messages and network devices from different parts of the network. In another example, the server device can utilize the syslog message to analyze traffic patterns and / or subscriber usage for billing purposes, etc.

[0045] Figure 1BProvides an example of a syslog message that can be generated by a network device. As shown, the syslog message can include a HEADER field, PRI field, VERSION field, HOSTNAME field, APP-NAME field, PROCID field, MSGID field, TIMESTAMP field, FULL-DATE field, DATE-FULLYEAR field, DATE-MONTH field, DATE-MDAY field, FULL-TIME field, PARTIAL-TIME field, TIME-HOUR field, TIME-MINUTE field, TIME-SECOND field, TIME-SECFRAC field, TIME-OFFSET field, TIME-NUMOFFSET field, STRUCTURED-DATA-BINARY field, BIT field, MSG field, MSG-ANY field, MSG-UTF8 field, BOM field, UTF-8-STRING field, OCTET field, SP field, PRINTUSASCII field, NONZERO-DIGIT field, DIGIT field, NILVALUE field, etc. Unless otherwise described herein, the fields can include the characteristics of the existing fields in the syslog message.

[0046] The version field can represent the version of the syslog protocol specification. The version number can be incremented (e.g., to a value of 2). In this version, structured binary data may need to be interpreted according to the syslog frame format mentioned below for each. If the received content does not match, the server device may discard the compressed binary message. The content of the structured data binary field can include the syslog frame format described below. The syslog message can include multiple syslog frames. All frames can start with a fixed 4-octet attribute, followed by a variable-length frame payload: Syslog Frame{Length(24),Type(8),Frame Payload(..),}. The length can refer to the length of the frame payload expressed as an unsigned 24-bit integer in octets. The type can refer to the 8-bit type of the frame. The frame type can determine the format and semantics of the frame. The structure and content of the frame payload depend entirely on the frame type. The size of the frame payload is limited by the maximum size advertised by the sending device in the SETTINGS_MAX_FRAME_SIZE setting.

[0047] Frame types can include SETTINGS frames, STRUCTURED-DATA-BINARY frames, and CONTINUATION frames. SETTINGS frames can be used to send control information. STRUCTURED-DATA-BINARY frames and CONTINUATION frames can follow any of the literal attribute field representations. SETTINGS frames can convey configuration parameters that affect how a network device communicates with a server device, such as preferences and constraints. Individually, the configuration parameters from a SETTINGS frame can be referred to as settings. Settings describe the characteristics of the sending network device, which are used by the receiving server device. Different values for the same setting can be published by the network device. Each parameter in a SETTINGS frame can replace any existing value for that parameter. Settings can be processed in the order in which they appear, and the recipient of a SETTINGS frame does not need to maintain any state other than the current value of each setting. Thus, the value of a setting parameter is the last value seen by the recipient.

[0048] The frame payload of a SETTINGS frame can include zero or more settings, each consisting of an unsigned 16-bit setting identifier and an unsigned 32-bit value. A SETTINGS frame can have the following format: SETTINGS Frame{Length(24),Type(8)=0x01,Settings(48)…,}, where a setting has the format Settings{Identifier(16),Value(32),}. The length and type are as described above, and the frame payload of a SETTINGS frame can include any number of setting fields, each of which includes an identifier (e.g., a 16-bit setting identifier) and a value (e.g., a 32-bit value for the setting). One defined setting can include the SETTINGS_HEADER_TABLE_SIZE setting, which enables a network device to notify a receiving device of the maximum size of the compression table used to decode field blocks, in octets. The encoder can select any size equal to or less than this value by using signaling specific to the compression format within the field blocks. Most values in settings benefit from or require knowledge of when a peer device has received and applied the changed parameter value. To provide such a synchronization point in time, the recipient of a SETTINGS frame can apply the updated settings as soon as possible after receipt.

[0049] The structured data frame can be used to carry field block fragments and can include the following format: STRUCTURED-DATA Frame{Length(24), Type(8)=0x01, Unused Flags(6), PADDED Flag(1), END_STRUCTURED_DATA Flag(1), [Pad Length(8)], Field Block Fragment(..), Padding(..2040),}. The field block fragments are described elsewhere in this document. The padding can include padding octets that do not contain application semantic values. The pad length can include an 8-bit field that contains the length of the frame padding in octets. The structured data frame can define the following flags: the PADDED flag (e.g., when set, indicates the presence of the pad length field and any padding it describes), and the END_STRUCTURED_DATA flag (e.g., when set, indicates that this frame contains the entire field block and no continuation frame follows). A structured data frame with the END_STRUCTURED_DATA flag not set can be followed by a continuation frame. A field block that cannot be accommodated within a structured data frame continues in a continuation frame.

[0050] The continuation frame can be used to continue a sequence of field block fragments. Any number of continuation frames can be sent as long as the previous frame is a structured data frame or a continuation frame with the END_STRUCTURED_DATA flag not set. The continuation frame can include the following format: CONTINUATION Frame{Length(24), Type(8)=0x09, Unused Flags(7), END_STRUCTURED_DATA Flag(1), Field Block Fragment(..),}. The length and type fields are described elsewhere in this document. The continuation frame payload contains field block fragments. The continuation frame can define the following flag: the END_STRUCTURED_DATA flag (e.g., when this flag is set, indicates that this frame ends the field block). If the END_STRUCTURED_DATA flag is not set, this frame can be followed by another continuation frame. The receiver can treat the reception of any other type of frame as a connection error. The continuation frame can be placed before a structured data frame.

[0051] As shown in Figure 1C and by reference numeral 130, the network device can process the syslog message with an encoder to identify the attribute fields and generate an attribute list and a dynamic table. For example, the network device can be associated with an encoder that processes the syslog message and generates a binary message and a compressed binary message (e.g., the dynamic table) based on processing the syslog message. As shown in Figure 1CAs further shown in, an example syslog message can include the following syntax: 1 2020-11-26T11:33:03.494Z blades RT_FLOW-RT_FLOW_SESSION_CREATE_USF [service-set-name="sset1" source-address="50.50.50.2" source-port="51420" destination-address="60.60.60.2" destination-port="2000" session-id="21990232555528"]. In some implementations, a network device can process the syslog message with an encoder to identify the attribute fields, and generate an attribute list based on the attribute fields, and generate a dynamic table based on the attribute list.

[0052] The encoder can treat the list of attribute fields as an ordered set of name-value pairs that can include duplicate pairs. The encoder can consider the name and value as opaque sequences of octets and can preserve the order of the attribute fields after compression and decompression. The encoder can be informed by an attribute field table that maps the attribute fields to index values. These field tables can be updated incrementally when encoding or decoding new attribute fields. In the encoded form, an attribute field is either represented literally or as a reference to the attribute field table. Thus, the list of attribute fields can be encoded using a mixture of references and literals. Literals are either encoded directly or using static Huffman codes. The encoder can determine which attribute fields to insert as new entries in the attribute field table. A decoder (e.g., in a server device) can perform modifications to the attribute field table specified by the encoder, reconstructing the list of attribute fields in the process. This can enable the decoder to remain simple and interoperate with various encoders.

[0053] An attribute field is a name-value pair where both the name and the value are considered opaque sequences of octets. A dynamic table is a table that associates stored attribute fields with index values. The table is dynamic and specific to an encoding or decoding context. A static table is a table that statically associates frequently occurring attribute fields with index values. This table is ordered, read-only, always accessible, and it can be shared across all encoding or decoding contexts. The static table can be a radius (radius) vendor-specific attribute (VSA) table with a maximum size (e.g., 256 entries). Each vendor can define specific attributes, and for syslog messages, the static table can utilize common attributes. Since syslog messages are vendor-specific, the radius VSA table can be redefined as a static table. An attribute list is an ordered collection of jointly encoded attribute fields and can contain duplicate attribute fields. The complete list of attribute fields contained in a syslog attribute block is an attribute list. An attribute field representation is a representation of an attribute field as literal or indexed in encoded form. An attribute block is an ordered list of attribute field representations that, when decoded, yields the complete attribute list.

[0054] The encoder can preserve the order of the attribute fields within the attribute list. The encoder can sort the attribute field representations in the attribute block according to the order of the attribute fields in the original attribute list. The decoder can sort the attribute fields in the decoded attribute list according to the order of the attribute fields in the attribute block.

[0055] Network devices and / or server devices can utilize two tables for associating attribute fields with indexes. The static table is predefined and contains common attribute fields. The dynamic table is dynamic and can be used by the encoder to index duplicate attribute fields in the encoded attribute list. These two tables can be combined into a single address space for defining index values. The static table can include a predefined static list of attribute fields. The dynamic table can include a list of attribute fields maintained in first-in, first-out order. The first and newest entries in the dynamic table are at the lowest indexes, and the oldest entry in the dynamic table is at the highest index. The dynamic table may initially be empty, and entries can be added when decompressing each attribute block. The dynamic table can contain duplicate entries (i.e., entries with the same name and the same value). The encoder can determine how to update the dynamic table and thus can control the memory size used by the dynamic table. To limit the memory requirements of the decoder, the dynamic table size can be strictly limited. The decoder can update the dynamic table during the processing of the list of attribute field representations.

[0056] Static tables and dynamic tables can be combined into a single index address space. Indexes between 1 and the length of the static table can refer to elements in the static table. Indexes greater than the length of the static table can refer to elements in the dynamic table. The length of the static table can be subtracted to find the index of the dynamic table.

[0057] Encoded attribute fields can be represented as an index or a literal presentation. An index representation can define an attribute field as a reference to an entry in a static table or a dynamic table. A literal presentation can define an attribute field by specifying its name and value. The attribute field name can be represented literally or as a reference to an entry in a static table or a dynamic table. The attribute field value can be represented literally. A literal representation can add the attribute field as a new entry at the beginning of the dynamic table. Alternatively, the literal representation may not add the attribute field to the dynamic table. Alternatively, the literal representation may not add the attribute field to the dynamic table with an additional stipulation that this attribute field always uses a literal representation, especially when being re-encoded by an intermediary. This representation is intended to protect the attribute field value from being at risk by compressing them. For protecting sensitive attribute field values, the choice of one of these literal presentations may be guided by security considerations. The literal presentation of an attribute field name or an attribute field value can directly or use a static Huffman code to encode a sequence of octets.

[0058] Figure 1D Describes how an encoder of a network device processes syslog messages, such as the example syslog message shown in Figure 1C For example, the encoder can process the example syslog message to identify the following attribute fields: service-set-name = "sset1"; source-address = 50.50.50.2";...; session-id = "21990232555528". The encoder can generate an attribute list based on the attribute fields. The attribute list can include the following: service-set-name = "sset1" source-address = "50.50.50.2" source-port = "51420" destination-address = "60.60.60.2" destination-port = "2000" session-id = "21990232555528". Finally, the encoder can generate a dynamic table based on the attribute list. The dynamic table can include the following information.

[0059]

[0060] As shown in Figure 1EAs shown in , and by reference numeral 135, the server device can process the compressed binary message with a decoder to generate a syslog message. For example, the server device can be associated with a decoder that processes the compressed binary message and generates a syslog message based on processing the compressed binary message. In some implementations, the decoder can process the attribute blocks sequentially to reconstruct the original attribute list. An attribute block is a concatenation of attribute field representations. Different possible attribute field representations are described elsewhere herein. Once an attribute field is decoded and added to the reconstructed attribute list, the attribute field cannot be removed. The attribute fields added to the attribute list can be safely passed to the application. By passing the resulting attribute fields to the application, the decoder can be implemented with a minimum amount of temporary memory committed, except for the memory required for the dynamic table. In some implementations, the decoder can decompress the binary message to generate a system message and can provide the system message to the syslog application for interpretation.

[0061] The decoder can process the attribute blocks to obtain an attribute list. To ensure that the decoding will successfully produce an attribute list, the decoder can follow the following rules. The decoder can process all the attribute field representations contained in the attribute block in the order in which they appear. For an index representation, the attribute field in the static table or the dynamic table can be appended to the decoded attribute list. For a literal representation that is not added to the dynamic table, the attribute field can be appended to the decoded attribute list. For a literal representation that is added to the dynamic table, the attribute field can be appended to the decoded attribute list, and the attribute field can be inserted at the beginning of the dynamic table. The size of the dynamic table can be the sum of the sizes of its entries. The size of an entry can be the sum of the length of its name in octets, the length of its value in octets, and the overhead count. The size of an entry can be calculated using the lengths of its name and value without applying any Huffman coding.

[0062] When the size of the dynamic table changes, the decoder can evict entries from the dynamic table. For example, whenever the maximum size for the dynamic table is reduced, entries can be deleted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size. When a new entry is added to the dynamic table, the decoder can evict entries from the dynamic table. For example, before a new entry is added to the dynamic table, entries can be evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size minus the size of the new entry, or until the dynamic table is empty.

[0063] Figures 1F - 1H Describes how the decoder of the server device can process the compressed binary message to generate a syslog message. As in Figure 1FAs shown in, the decoder can decode the service set name of the compressed binary message and add the service set name to the property list and the dynamic table. The service set name added to the property list can be service-set-name = "sset1", and the dynamic table entry can be 4010 7365 7276 6963652D7365 742D 6E61 6D65|service-set-name and 0573 7365 7431|set1. As in Figure 1F As further shown in, the decoder can decode the source address of the compressed binary message and add the source address to the property list and the dynamic table. The source address added to the property list can be source-address = "50.50.50.2", and the dynamic table entry can be 400E 736F 7572 6365 2D61 6464 7265 7373|source-address and 0A35 302E3530 2E35 302E 32|50.50.50.2. As in Figure 1F As further shown in, the decoder can decode the source port of the compressed binary message and add the source port to the property list and the dynamic table. The source port added to the property list can be source-port = "51420", and the dynamic table entry can be 400B 736F 7572 63652D706F72 74|source-port and 0535 3134 3230|51420.

[0064] As in Figure 1G As shown in, the decoder can decode the destination address of the compressed binary message and add the destination address to the property list and the dynamic table. The destination address added to the property list can be destination-address = "60.60.60.2", and the dynamic table entry can be 4013 6465 7374 696e6174 696F 6E2D6164 6472 6573 73|destination-address and 0A36 302E 3630 2E36 302E 32|60.60.60.2. As in Figure 1GAs further shown in [description], the decoder can decode the destination port of the compressed binary message and add the destination port to the property list and the dynamic table. The destination port added to the property list can be destination-port="2000", and the dynamic table entry can be 4010 6465 7374 696E 6174 696F6E2D 706F 7274|destination-port and 0432 3030 30|2000.

[0065] As shown in Figure 1H [description], the decoder can decode the session id (ID) of the compressed binary message and add the session id to the property list and the dynamic table. The session id added to the property list can be session-id="21990232555528", and the dynamic table entry can be 400A 7365 7373 696F 6E2D 6964|session-id and 0E32 31393930 3233 3235 3535 3532 38|21990232555528.

[0066] In this way, the network device reduces the memory size of the system-generated messages before transmission. For example, the network device can provide a new framing layer to the syslog message. The new framing layer can enable the network device to convert the syslog message from text format to binary format and compress the binary-format syslog message to generate a compressed binary syslog message. The network device can forward the compressed binary syslog message to the server device for further processing. Therefore, the network device saves computing resources, networking resources, etc., which would otherwise be consumed by failing to reduce the memory size of a large number of syslog messages, limit the bandwidth of the network device and / or the network based on failing to reduce the memory size of a large number of syslog messages, cause traffic loss in the network based on failing to reduce the memory size of a large number of syslog messages, etc.

[0067] As shown above, Figures 1A - 1H is provided as an example. Other examples may be different from those described with respect to Figures 1A - 1H In Figures 1A - 1H [description], the number and arrangement of the devices shown are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or devices arranged differently from those shown in Figures 1A - 1H [description]. In addition, two or more devices shown in Figures 1A - 1H [description] can be implemented within a single device, or in Figures 1A - 1HThe single device shown in the figure can be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) shown in Figures 1A - 1H can perform one or more functions described by another set of devices shown in Figures 1A - 1H .

[0068] Figure 2 FIG. 200 is a diagram of an example environment in which the systems and / or methods described herein can be implemented. As shown in Figure 2 , environment 200 can include a device 210, a set of network devices 220 (shown as network devices 220-1 through network device 220-N), a server device 230, and a network 240. The devices of environment 200 can be interconnected via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0069] Endpoint device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information, such as the information described herein. For example, endpoint device 210 can include a mobile phone (e.g., a smartphone or a wireless phone), a laptop computer, a tablet computer, a desktop computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smartwatch, a pair of smart glasses, a heart rate monitor, a fitness tracker, smart clothing, smart jewelry, or a head-mounted display), a network device, or a device of a similar type. In some implementations, endpoint device 210 can receive network traffic from and / or can provide network traffic to other endpoint devices 210 and / or server device 230 via network 240 (e.g., by routing packets using network device 220 as an intermediate device).

[0070] Network device 220 includes one or more devices capable of receiving, processing, storing, routing, and / or providing traffic (e.g., packets or other information or metadata) in the manner described herein. For example, network device 220 can include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router or a provider core router), a virtual router, or other types of routers. Additionally or alternatively, network device 220 can include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, or a data center server), a load balancer, and / or similar devices. In some implementations, network device 220 can be a physical device implemented within an enclosure (e.g., a chassis). In some implementations, network device 220 can be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center. In some implementations, a set of network devices 220 can be a set of data center nodes used to route traffic flows through network 240.

[0071] The server device 230 may include one or more devices capable of receiving, generating, storing, processing, providing, and / or routing information, as described elsewhere herein. The server device 230 may include a communication device and / or a computing device. For example, the server device 230 may include a server, such as an application server, a client server, a web server, a database server, a host server, a proxy server, a virtual server (e.g., executed on computing hardware), or a server in a cloud computing system. In some implementations, the server device 230 may include computing hardware used in a cloud computing environment.

[0072] The network 240 includes one or more wired and / or wireless networks. For example, the network 240 may include a packet-switched network, a cellular network (e.g., a fifth-generation (5G) network, a fourth-generation (4G) network, such as a Long-Term Evolution (LTE) network, or a third-generation (3G) network), a Code Division Multiple Access (CDMA) network, a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., a Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-optic-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0073] The Figure 2 number and arrangement of the devices and networks shown in Figure 2 are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently from those shown in Figure 2 In addition, two or more of the devices shown in Figure 2 may be implemented within a single device, or a single device shown in

[0074] Figure 3 is Figure 2 a diagram of example components of one or more of the devices. The example components may be included in the device 300, which may correspond to the endpoint device 210, the network device 220, and / or the server device 230. In some implementations, the endpoint device 210, the network device 220, and / or the server device 230 may include one or more devices 300 and / or one or more components of the device 300. As shown in Figure 3 the device 300 may include a bus 310, a processor 320, a memory 330, an input component 340, an output component 350, and a communication interface 360.

[0075] Bus 310 includes one or more components that enable wired and / or wireless communication among the components of device 300. Bus 310 may couple two or more components together, such as via operational coupling, communicative coupling, electrical coupling, and / or electro - coupling. Figure 3 Processor 320 includes a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a controller, a microcontroller, a digital signal processor (DSP), a field - programmable gate array (FPGA), an application - specific integrated circuit (ASIC), and / or other types of processing components. Processor 320 is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 320 includes one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0076] Memory 330 includes volatile and / or non - volatile memory. For example, memory 330 may include random access memory (RAM), read - only memory (ROM), a hard disk drive, and / or another type of memory (e.g., flash memory, magnetic memory, and / or optical memory). Memory 330 may include internal memory (e.g., RAM, ROM, or a hard disk drive) and / or removable memory (e.g., removable via a universal serial bus connection). Memory 330 may be a non - transitory computer - readable medium. Memory 330 stores information, instructions, and / or software (e.g., one or more software applications) related to the operation of device 300. In some implementations, memory 330 includes one or more memories coupled to one or more processors (e.g., processor 320), such as via bus 310.

[0077] Input component 340 enables device 300 to receive input, such as user input and / or sensed input. For example, input component 340 may include a touch screen, a keyboard, a keypad, a mouse, buttons, a microphone, switches, sensors, a global positioning system sensor, an accelerometer, a gyroscope, and / or an actuator. Output component 350 enables device 300 to provide output, such as via a display, a speaker, and / or a light - emitting diode. Communication interface 360 enables device 300 to communicate with other devices via a wired connection and / or a wireless connection. For example, communication interface 360 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and / or an antenna.

[0078] Device 300 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 330) may store a set of instructions (e.g., one or more instructions or code) for execution by processor 320. Processor 320 may execute a set of instructions to perform one or more operations or processes described herein. In some implementations, execution of a set of instructions by one or more processors 320 causes one or more processors 320 and / or device 300 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry may be used instead of or in combination with instructions to perform one or more operations or processes described herein. Additionally or alternatively, processor 320 may be configured to perform one or more operations or processes described herein. Thus, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0079] As shown in Figure 3 the number and arrangement of components are provided as an example. Compared to those shown in Figure 3 device 300 may include additional components, fewer components, different components, or components in a different arrangement. Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions described as being performed by another set of components of device 300.

[0080] Figure 4 is Figure 2 a diagram of example components of one or more devices. Example components may be included in device 400. Device 400 may correspond to network device 220. In some implementations, network device 220 may include one or more devices 400 and / or one or more components of device 400. As shown in Figure 4 device 400 may include one or more input components 410-1 to 410-B (B≥1) (collectively referred to herein as input components 410 and individually as input component 410), a switching component 420, one or more output components 430-1 to 430-C (C≥1) (collectively referred to herein as output components 430 and individually as output component 430), and a controller 440.

[0081] The input component 410 can be a point for one or more attachments of a physical link and can be a point for one or more entries of incoming traffic (e.g., packets). The input component 410 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 410 can transmit and / or receive packets. In some implementations, the input component 410 can include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and / or input queues. In some implementations, the device 400 can include one or more input components 410.

[0082] The switching component 420 can interconnect the input component 410 and the output component 430. In some implementations, the switching component 420 can be implemented via one or more crossbars, via a bus, and / or with a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 410 before the packets are finally scheduled for delivery to the output packet 430. In some implementations, the switching component 420 can enable communication between the input component 410, the output component 430, and / or the controller 440.

[0083] The output component 430 can store packets and can schedule packets for transmission on an output physical link. The output component 430 can support data link layer encapsulation or decapsulation, and / or various advanced protocols. In some implementations, the output component 430 can transmit packets and / or receive packets. In some implementations, the output component 430 can include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, the device 400 can include one or more output components 430. In some implementations, the input component 410 and the output component 430 can be implemented by the same set of components (e.g., and the input / output component can be a combination of the input component 410 and the output component 430).

[0084] The controller 440 includes a processor that is in the form of, for example, a CPU, GPU, accelerated processing unit (APU), microprocessor, microcontroller, DSP, FPGA, ASIC, and / or other types of processors. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 440 can include one or more processors that can be programmed to perform functions.

[0085] In some implementations, controller 440 may include RAM, ROM, and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by controller 440.

[0086] In some implementations, controller 440 may communicate with other devices, networks, and / or systems connected to device 400 to exchange information about the network topology. Controller 440 may create a routing table based on the network topology information, may create a forwarding table based on the routing table, and may forward the forwarding table to input component 410 and / or output component 430. Input component 410 and / or output component 430 may use the forwarding table to perform route lookups for incoming and / or outgoing packets.

[0087] Controller 440 may execute one or more of the processes described herein. In response to executing software instructions stored by a non-transitory computer-readable medium, controller 440 may perform these processes. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0088] The software instructions may be read into the memory and / or storage components associated with controller 440 from another computer-readable medium or from another device via a communication interface. When the software instructions stored in the memory and / or storage components associated with controller 440 are executed, they may cause controller 440 to perform one or more of the processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with the software instructions to perform one or more of the processes described herein. Accordingly, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0089] As shown in Figure 4 The number and arrangement of components are provided as an example. In practice, device 400 may include additional components, fewer components, different components, or a different arrangement of components compared to the components shown in Figure 4 Additionally or alternatively, a set of components (e.g., one or more components) of device 400 may perform one or more of the described functions being performed by another set of components of device 400.

[0090] Figure 5 is a flowchart of an example process 500 for reducing the memory size of system-generated messages before transmission. In some implementations, Figure 5 one or more of the process blocks in Figure 5One or more process blocks of may be executed by another device or group of devices, which are independent of or include network devices, such as server devices (e.g., server device 230). Additionally or alternatively, Figure 5 One or more processing blocks of may be executed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication interface 360. Additionally or alternatively, Figure 5 One or more process blocks of may be executed by one or more components of device 400, such as input component 410, switching component 420, output component 430, and / or controller 440.

[0091] As shown in Figure 5 Process 500 may include receiving traffic associated with a network (block 510). For example, a network device may receive traffic associated with a network, as described above.

[0092] As further shown in Figure 5 Process 500 may include generating a system message based on the traffic (block 520). For example, a network device may generate a system message based on the traffic, as described above.

[0093] As further shown in Figure 5 Process 500 may include converting the system message into a binary message (block 530). For example, a network device may convert the system message into a binary message, as described above. In some implementations, converting the system message into a binary message includes processing the system message with an encoder to identify attribute fields, generating an attribute list based on the attribute fields, and generating a table based on the attribute list, where the binary message corresponds to the table. In some implementations, the encoder is header compression for an HTTP encoder, header compression for syslog attribute pairs similar to an HTTP / 2 encoder, etc. In some implementations, the table is maintained in a first-in, first-out order. In some implementations, the table is limited by a memory threshold.

[0094] In some implementations, the binary message includes a frame handler layer provided above the transport layer of the system message. In some implementations, the binary message includes a version field indicating that the binary message includes structured binary data. In some implementations, the binary message includes a structured data frame configured to include field block fragments. In some implementations, the binary message includes encoded binary data.

[0095] As shown in Figure 5As further shown in, process 500 may include compressing a binary message to generate a compressed binary message (block 540). For example, a network device may compress a binary message to generate a compressed binary message as described above. In some implementations, compressing a binary message to generate a compressed binary message includes: compressing a set of field lines of the binary message to generate a field block corresponding to the compressed binary message.

[0096] As shown in Figure 5 As further shown in, process 500 may include providing the compressed binary message to a server device (block 550). For example, a network device may provide the compressed binary message to a server device as described above. In some implementations, providing the compressed binary message to a server device includes providing the compressed binary message to enable the server device to process the compressed binary message with a decoder to generate a system message. In some implementations, the decoder is header compression for an HTTP decoder, header compression for syslog property pairs similar to an HTTP / 2 decoder, etc.

[0097] In some implementations, process 500 includes performing Huffman coding of the system message before converting the system message to a binary message.

[0098] Although Figure 5 the example blocks of process 500 are shown, in some implementations, process 500 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those described in Figure 5 As such. Additionally or alternatively, two or more of the blocks of process 500 may be executed in parallel.

[0099] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the exact form disclosed. Modifications may be made in accordance with the above disclosure or obtained from practice of the implementation.

[0100] As used herein, the term "component" is intended to be broadly construed as hardware, firmware, or a combination of hardware and software. It is apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, and / or combinations of hardware and software. The actual specific control hardware or software code for implementing these systems and / or methods is not a limitation of the implementation. Accordingly, the operation and behavior of the systems and / or methods described herein are not referenced to a specific software code - it is understood that based on the description herein, software and hardware may be used to implement the systems and / or methods.

[0101] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features may be combined in ways that are not recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on one claim, the disclosure of various implementations includes each dependent claim combined with every other claim in the claim set.

[0102] Elements, acts, or instructions used herein are not to be construed as critical or essential, unless expressly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Also, as used herein, the article "the" is intended to include one or more reference items associated with the article "the" and may be used interchangeably with "the one or more." Also, as used herein, the term "a set of" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, and / or the like) and may be used interchangeably with "one or more." If only one item is intended, the phrase "only one" or similar language is used. Also, as used herein, the terms "has," "have," "having," or similar terms are intended to be open-ended terms. Also, the phrase "based on" is intended to mean "at least partially based on," unless expressly stated otherwise. Also, as used herein, the term "or" is intended to be inclusive when used in a series and may be used interchangeably with "and / or," unless expressly stated otherwise (e.g., if used in conjunction with "one of" or "only one of").

[0103] In the previous specification, various example embodiments were described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the following claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method comprising: Receiving, by the network device, traffic associated with the network; The network device generates a system message based on the service; The network device converts the system message into a binary message; compressing, by the network device, the binary message to generate a compressed binary message; as well as The compressed binary message is provided by the network device to a server device.

2. The method of claim 1, wherein converting the system message into the binary message comprises: processing the system message with an encoder to identify attribute fields, to generate an attribute list based on the attribute fields, and to generate a table based on the attribute list, Wherein the binary message corresponds to the table.

3. The method of claim 2, wherein the encoder is a header compression for Hypertext Transfer Protocol (HTTP) encoder or a header compression for system log attribute pairs similar to an HTTP / 2 encoder. The method of claim 2 , wherein the table is maintained in a first-in, first-out order. The method of claim 2 , wherein the table is limited by a memory threshold.

6. The method of claim 1 , wherein providing the compressed binary message to the server device comprises: The compressed binary message is provided so that the server device processes the compressed binary message using a decoder to generate the system message.

7. The method of claim 6, wherein the decoder is a header compression for Hypertext Transfer Protocol (HTTP) decoder or a header compression for system log attribute pairs similar to HTTP / 2 decoder.

8. A network device comprising: one or more memories; as well as One or more processors to: receiving a service associated with the network; generating a system message based on the service; Converting the system message into a binary message; compressing the binary message to generate a compressed binary message; as well as The compressed binary message is provided to a server device so that the server device processes the compressed binary message using a decoder to generate the system message.

9. The network device of claim 8, wherein the binary message comprises a frame handler layer provided above a transport layer of the system message.

10. The network device of claim 8, wherein the binary message includes a version field, the version field indicating that the binary message includes structured binary data.

11. The network device of claim 8, wherein the one or more processors are further configured to: Before converting the system message into the binary message, Huffman encoding of the system message is performed.

12. The network device of claim 8, wherein the binary message comprises a structured data frame configured to include field block fragments.

13. The network device of claim 8, wherein the one or more processors configured to compress the binary message to generate the compressed binary message are configured to: A set of field rows of the binary message is compressed to generate field blocks corresponding to the compressed binary message.

14. The network device of claim 8, wherein the binary message comprises encoded binary data.

15. A non-transitory computer readable medium storing a set of instructions, the set of instructions comprising: One or more instructions that, when executed by one or more processors of a network device, cause the network device to: receiving a service associated with the network; generating a system message based on the service; processing the system message with an encoder to identify attribute fields, to generate an attribute list based on the attribute fields, and to generate a table based on the attribute list, wherein the table corresponds to a binary message; compressing the binary message to generate a compressed binary message; as well as The compressed binary message is provided to a server device.

16. The non-transitory computer readable medium of claim 15, wherein the encoder is a header compression for Hypertext Transfer Protocol (HTTP) encoder or a header compression for syslog attribute pairs similar to HTTP / 2 decoder.

17. The non-transitory computer readable medium of claim 15, wherein the table is maintained in a first-in, first-out order.

18. The non-transitory computer readable medium of claim 15, wherein the table is limited by a memory threshold.

19. The non-transitory computer readable medium of claim 15, wherein the binary message comprises a frame handler layer provided over a transport layer of the system message.

20. The non-transitory computer-readable medium of claim 15, wherein the binary message comprises a version field indicating that the binary message comprises structured binary data.

Images