Effective TLV Style Header Parsing and Editing

Abstract

This application relates to efficient TLV-style header parsing and editing. In some aspects, the present disclosure relates to methods and systems for a flexible TLV parser and identification map that can be used to quickly identify type-length-value (TLV) sequences of packet headers for subsequent processing in a pipeline. The flexible TLV bus can provide an auxiliary path for the TLV headers and identification map, allowing subsequent processing stages to read, process, modify, delete, or otherwise utilize individual TLV sequences within the headers.

Description

Technical Field

[0001] The present disclosure generally relates to systems and methods for network packet processing. In particular, the present disclosure relates to systems and methods for parsing type-length-value (TLV) headers in network packets. Background Art

[0002] Type-length-value (TLV) headers provide flexibility for communication protocols by including optional elements within a data stream that need not be of a fixed length or at a predetermined location. The type code can indicate the value type, and the length of the value can be encoded in the length field. For example, an Internet Protocol voice service system can communicate with a gateway connected to a traditional or plain old telephone system (POTS), and can transmit packets having headers that contain TLV tuples, where the TLV tuple has a type code for a telephone number, a length code indicating 10 digits (or 10 digits encoded in binary nibbles in many implementations), and a value that is the telephone number to be called. Other systems not configured for such operations can still correctly forward the TLV option, thus ignoring the value. Other uses include device or network monitoring data and instrumentation, simple remote controls, security functions, selective acknowledgments for reliable transport protocols, etc., or any other use where a higher protocol layer payload may not be required. Due to the encoded length identifier, multiple TLV headers can be serially connected and included in the option field or other part of the header, and can be extracted, parsed, and utilized by them as the device processes and forwards the packet stream. Summary of the Invention

[0003] In one aspect, the present application provides a method for flexibly parsing a TLV header of a communication packet, which includes: (a) identifying, by a TLV extractor, the presence of a TLV sequence in the header of the communication packet and an anchor offset corresponding to the position of the TLV sequence; (b) determining, by the TLV extractor, the type of the TLV sequence; (c) calculating, by the TLV extractor, a position offset corresponding to the TLV sequence within the header based on the anchor offset; and (d) filling, by the TLV extractor, an existence bitmap with the determined type and position offset.

[0004] In another aspect, the present application provides a circuit for flexibly parsing a TLV header of a communication packet, which includes: a TLV extractor configured to receive a TLV header extracted from a communication packet and further configured to: (a) identify the presence of a TLV sequence in the TLV header and an anchor offset corresponding to the position of the TLV sequence; (b) determine the type of the TLV sequence; (c) calculate a position offset corresponding to the TLV sequence within the header based on the anchor offset; and (d) fill an existence bitmap with the determined type and position offset.

[0005] On the other hand, the present application provides a circuit for modifying a TLV header of a communication packet, comprising: a TLV processor communicating with a TLV extractor via a first bus, the TLV processor being configured to: receive a presence bitmap from the TLV extractor via the first bus, the presence bitmap including tuples identifying types of TLV sequences in a communication packet received via a second bus and position offsets of the TLV sequences within the packet; modify the TLV sequences in the communication packet according to the position offsets in the presence bitmap; update the presence bitmap according to the modified TLV sequences; transmit the updated presence bitmap via the first bus; and transmit the modified communication packet via the second bus. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Various objects, aspects, features, and advantages of the present disclosure will become more apparent and better understood by reference to the detailed description taken in conjunction with the accompanying drawings, in which like reference symbols identify corresponding elements throughout. In the drawings, like reference numerals generally indicate identical, functionally similar, and / or structurally similar elements.

[0007] Figure 1 is a block diagram depicting a parser and a flexible TLV extractor circuit according to some embodiments;

[0008] Figure 2 is a block diagram depicting functional blocks within a flexible TLV extractor circuit according to some embodiments;

[0009] Figure 3 is a block diagram depicting a flexible TLV processor circuit according to some embodiments;

[0010] Figure 4 is a flowchart depicting a method of flexible TLV parsing and extraction according to some embodiments;

[0011] Figure 5 is a flowchart depicting a method of flexible TLV editing according to some embodiments;

[0012] Figure 6A is a block diagram depicting an example of a network environment including one or more access points communicating with one or more devices or stations; and

[0013] Figure 6B and 6C is a block diagram depicting an example of a computing device usable in conjunction with the methods and systems described herein.

[0014] Details of various embodiments of the methods and systems are set forth in the drawings and the description below. DETAILED DESCRIPTION

[0015] The following IEEE standards, any draft versions of which contain this (class of) standard, are hereby incorporated by reference in their entirety and made a part of this disclosure for all purposes: IEEE P802.11nTM; and IEEE P802.11acTM. Although aspects of these standards may be referenced in this disclosure, this disclosure is in no way limited by these standards.

[0016] For purposes of reading the descriptions of the various embodiments below, the following descriptions of the specification and the sections of its corresponding content may be helpful:

[0017] - Section A describes embodiments of systems and methods for flexible TLV processing; and

[0018] - Section B describes network environments and computing environments that may be useful in practicing the embodiments described herein.

[0019] A. Systems and Methods for Flexible TLV Processing

[0020] A type-length-value (TLV) header provides flexibility for communication protocols by including optional elements within a data stream that need not be of fixed length or at a predetermined location. The type code can indicate the value type, and the length of the value can be encoded in a length field. Due to the encoded length identifier, multiple TLV sequences can be concatenated (collectively or commonly referred to as the TLV header) and included in the options field or other part of a packet header, and can be extracted, parsed, and utilized by devices as they process and forward the packet stream. However, this can present difficulties in identifying and parsing the TLV sequences, and typically requires each system or circuit processing packets that include the TLV header to read each TLV sequence in order, resulting in inefficiencies and throughput bottlenecks. For example, in one implementation, a packet processor can be configured to extract a timestamp from a TLV sequence to identify upstream device processing times and overloads. However, the particular TLV sequence containing the timestamp may not be the first TLV sequence (starting at octet 0 of the TLV header), but could be the second or third (or higher) TLV sequence with an unknown start location. For example, if the first TLV sequence includes 32 octets and the second TLV sequence includes 18 octets, then the third could start at octet 50; but if the first sequence includes 24 octets, then the third could start at octet 42. Thus, such packet processors may need to read each TLV sequence in order (including irrelevant TLV sequences or sequences that do not contain the desired information) to identify the start location of the relevant sequence. Worse yet, the TLV sequence order and types may not be consistent between packets, even within a single communication stream. For example, the first packet of a stream may contain a TLV sequence related to the start transmission time of the sequence, while the second packet of the stream may instead contain a TLV sequence related to memory utilization at the transmitting device. Thus, each packet may need to be examined individually. This can significantly degrade throughput, especially in systems attempting to process gigabytes or terabytes per second.

[0021] To address these and other issues, embodiments of the systems and methods discussed herein provide flexible TLV parsers and identification maps that can be used to quickly identify TLV sequences for subsequent processing in a pipeline. A flexible TLV bus can provide an auxiliary path for the TLV header and identification map, allowing subsequent processing stages to read, process, modify, delete, or otherwise utilize individual TLV sequences within the header. Such embodiments of the parser and processing pipeline may be able to handle very high throughputs, up to terabytes or more per second.

[0022] First, refer to Figure 1, illustrates a block diagram depicting parser 100 and flexible TLV extractor circuit 110 according to some embodiments. Parser 100 may include hardware, software, or a combination of hardware and software for receiving and parsing incoming packet data on packet data bus 10. For example, in many embodiments, parser 100 may include a packet processing engine or circuit for identifying and parsing the header of an incoming packet (e.g., an ASIC, FPGA, or other circuitry for identifying and interpreting various packet header fields). In many embodiments, parser 100 may operate at a lower layer of the network stack (e.g., the data or link layer, network layer, or transport layer (e.g., layers 2, 3, or 4 of the OSI model, respectively)), and may be configured to extract and / or identify headers at such lower layers of the packet. For example, in many embodiments, parser 100 may be configured to copy and / or remove headers encapsulating higher layer payloads. In other embodiments, parser 100 may operate at a higher layer of the network stack and may parse and / or remove application layer headers from the packet before passing the incoming packet to an application or operating system of the device. For example, in some embodiments, parser 100 may be configured to identify a Transport Layer Security (TLS) header encapsulating an application data payload; while in other embodiments, parser 100 may be configured to identify a Link Layer Discovery Protocol (LLDP) header encapsulating a network layer payload.

[0023] Parser 100 may communicate with TLV extractor 110. In many embodiments, TLV extractor 110 may be referred to as a TLV parser, and parser 100 may be referred to as a “standard parser” or non-TLV parser. TLV extractor 110 may include hardware, software, or a combination of hardware and software for receiving from parser 100 a packet including one or more TLV sequences or entities in a TLV header and for identifying and extracting each TLV sequence or entity from the TLV header. For example, as shown in the embodiments of Figure 1 , parser 100 may receive or retrieve a packet from packet data bus 10, identify the presence of a TLV header in the packet (e.g., in a data layer header, network layer header, transport layer header, application layer header, or anywhere else in the packet, depending on the embodiment); in some embodiments, place an indication of the presence of the TLV header on flexible pipeline bus 20 (generally referred to herein as the “flexible bus”); and provide the TLV header (and in some embodiments, an indication of the number of octets in the header) to TLV extractor 110.

[0024] The TLV extractor 110 can be configured to read the TLV header 130 and identify or extract each TLV sequence within the header, regardless of length or order in many embodiments. The TLV extractor 110 can produce a TLV presence bitmap that identifies each TLV sequence within the header for subsequent processing, as well as the location of the TLV sequences within the header. For example, in some embodiments, the TLV header can include a first TLV header having type n, length m, and value x; a second TLV header having type n′, length m′, and value y; a third TLV header having type n″, length m″, and value z, and so on. The TLV extractor 110 can produce a TLV presence bitmap 140 indicating that the TLV header includes a first header of type n, a second header of type n′, a third header of type n″, and so on. For example, in some embodiments, the bitmap can include the string {n, n′, n″, etc.}. In other embodiments, the bitmap can identify the length of each header and include the string {n, m; n′, m′; n″, m″, etc.}.

[0025] The length of the TLV sequence can identify the length of the value field for that particular sequence, which may require further calculation to identify the location within the TLV header. For example, in some embodiments, the TLV header can contain a first TLV sequence having an 8-bit type field, an 8-bit length field, and a 60-byte (480-bit) value field; and a second TLV sequence having an 8-bit type field, an 8-bit length field, and a 32-byte (256-bit) value field; and thus a third TLV sequence starting at bit 768 in the header. Instead of requiring a subsequent TLV processor to perform this calculation to identify the location at which any particular sequence starts, in some embodiments, the TLV extractor 110 can produce a set of tuples for each TLV sequence identifying the offset at which the sequence starts, as well as the sequence identifier and / or type identifier. For example, in some embodiments, each tuple can include the tuple {type, offset} for the TLV sequence, and the tuples can be placed on the flexible bus 20. A subsequent TLV processor (e.g., a TLV processor) configured to process a particular type of TLV data can monitor the flexible bus for tuples identifying the corresponding type (which can be encoded as a bit string, e.g., an 8-bit value encoding 256 potential TLV types or any other such encoding) and the offset within the TLV header. The processor can start reading the TLV header at the corresponding offset to extract the bit string corresponding to the sequence.

[0026] In another embodiment, the offset for each TLV sequence can be further based on an anchor offset that identifies the start of the TLV header. For example, in one embodiment, the example TLV header discussed above can include an LLDP data unit within an Ethernet frame, starting at byte 22 (bit 176) within the frame in some embodiments. This value can be referred to as the anchor offset. In some embodiments, an individual TLV sequence offset can be added to the anchor offset to determine the location of each individual TLV sequence offset within the frame. In some embodiments, the anchor offset can be provided separately to the flexible bus (e.g., as part of the header identification 120 and / or the TLV presence bitmap 140) and / or can be added to the offset of each TLV tuple 160. For example, in some embodiments, the anchor offset can indicate that the TLV header starts at byte 22 within the frame, and the TLV tuple can identify TLV sequences starting at bytes 0, 20, and 50 within the TLV header (e.g., at bytes 22, 42, and 72 within the frame, respectively). In many embodiments, the TLV processing stages in the pipeline do not need to know the anchor offset of the TLV header, and thus, the tuple can simply identify the offset location within the TLV header (e.g., 0, 20, and 50 in the above example). In some other embodiments, the tuple can identify the combined anchor offset and offset location (e.g., bytes 22, 42, and 72 in the above example), allowing a specific TLV sequence to be extracted from the entire packet without having to separately read the anchor offset.

[0027] Additionally, in many embodiments, one or more TLV values 150 can be extracted by the TLV extractor 110 and placed on the flexible bus for faster processing by downstream TLV processors. For example, in some embodiments, the TLV header can contain a timestamp as a value (or as part of a value) that can be important for several processing operations (e.g., for packet queuing, determining whether a retransmission timeout has occurred, determining whether the processing delay has exceeded a threshold). In some embodiments, such values can be placed by the TLV extractor 110 on the flexible bus 20, allowing subsequent processing stages to directly read the values without having to first identify the corresponding TLV sequence within the packet header and extract the value.

[0028] Although shown as a single block, in many embodiments, the TLV extractor 110 may include a pipeline of successive extractor stages, e.g., for parsing different sequences of TLV headers in parallel. For example, a TLV header may be provided to a first extractor 110, which may identify the offset of a second sequence within the header and forward the previous bits (e.g., corresponding to the first sequence) to a subsequent TLV extractor stage for parsing (such that the first extractor parses the second TLV sequence while the second extractor parses the first TLV sequence). This may be iterated for additional TLV sequences until there are no additional bytes in the TLV header (subtracting the number of bits forwarded from the total header length identified by the parser in communication 130).

[0029] Figure 2 is a block diagram depicting functional blocks within a flexible TLV extractor circuit according to some embodiments. As discussed above, in many embodiments, the TLV extractor 110 may receive a TLV header and the number of bytes in the TLV header 130 (which may be the number of bytes remaining in the header after being passed, e.g., via the flexible bus 20, to another TLV extractor 110 on a portion of the TLV header). At block 205, the TLV extractor 110 may read the type from the first TLV sequence of the received header, which may include extracting a first predetermined number of bits from the TLV sequence (e.g., the first octet in many embodiments, although in other embodiments, the type field may use fewer or greater numbers of bits).

[0030] At block 210, the TLV extractor 110 may compare the extracted type bits with the type identifiers in the memory 212. For example, in many embodiments, block 210 may include N number of match circuits, such as content addressable memory (CAM) circuits or flip-flop based arrays (or in some embodiments, N CAM circuits), each corresponding to a predetermined type identifier. In some embodiments, each array may have its entries defined with a type (e.g., corresponding octets or another such value) such that the input bits may be compared with the stored type bits (e.g., via a bitwise AND or similar operation). In some embodiments, each array or memory array may also store the bit offsets and / or masks of the length fields (e.g., identifying the bits associated with the corresponding type of length field that may be different for different types of TLV sequences). In some embodiments, the array or memory may store the left shift value of the length value, which may be used to convert the length value into bytes. In some embodiments, the array or memory may store a constant to be added to the length value (e.g., for types of length values within a predetermined range or having a minimum value such that length “0” is equivalent to a predetermined minimum value (e.g., 32 bits), which may be used to reduce the number of bits required to encode the length field). In some embodiments, the array or memory may store the byte offset of the value field in the TLV sequence. Any or all of the above additional data may be provided to subsequent blocks in the TLV extractor 110 to control the extraction of data and / or may be placed in a flexible bus entry for the TLV sequence. In some embodiments, the array or memory may store extraction commands (e.g., identifying one or more words or octets to extract from the TLV sequence). For example, the extraction command may include an offset value to place a word or octet in the bus or to extract a word or octet from the value field of the TLV sequence, and / or may include the identification of a start or end octet or word (e.g., indicating to extract the first octet or word or the last octet or word from the value field of the TLV sequence respectively). For example, in some embodiments, a timestamp may be the last 32-bit word in a value field that includes four 32-bit values, and the extraction command may indicate that the last 32 bits of the TLV sequence value field should be placed in the flexible bus.

[0031] At block 215, the extractor 110 may set a type presence bitmap according to the identified types (e.g., from a match array). In some embodiments, the type presence bitmap may include the encoding of the types of the sequences and the order within the TLV headers of the sequences (e.g., if the TLV header contains a first sequence of type 2 and a second sequence of type 4, the bitmap may encode "2, 4"). In some embodiments, the type presence bitmap may include {type, offset} values of the identified types and positions within the TLV headers of the sequences. For example, as discussed above, in some embodiments, the offset may be based on the length of the previous TLV sequence and / or an anchor offset or position within the packet header of the TLV header. Thus, in some such embodiments, the bitmap may encode {type, offset} tuples based on the bit positions of the TLV sequences within the packet header (including other parts of the header such as source or destination addresses, packet type, etc.). In other embodiments, other encodings are possible.

[0032] At block 220, in some embodiments and according to an extraction command, one or more words or octets may be extracted from the start of the value field of the TLV sequence for placement on the flexible bus. Similarly, in some embodiments, at block 225, the length of the value field of the TLV sequence may be calculated (e.g., based on length bits in the array and any offsets or shifts as discussed above). At block 230, the value field may be shifted (e.g., via a barrel shift or a similar bit shift) such that one or more octets or words at the end of the value field may be extracted at block 235 for placement on the flexible bus 20.

[0033] At block 240, the flexible bus may be updated with the value words or octets extracted from the start and / or end of the value field and / or with the type presence bitmap according to a command from block 245. In many embodiments, the blocks of the TLV extractor may be pipelined to parse the bit stream of the TLV sequence as it passes through the extractor; the update command may be triggered by the completion of the pipeline stage processing such that a single bus update command may trigger the insertion of the extracted words and type presence bitmap onto the flexible bus.

[0034] In some embodiments, to process consecutive TLV sequences, blocks 205 to 245 may be repeated (as shown by the dashed lines). In other embodiments, as discussed above, in many embodiments, multiple TLV extractors may be placed in series to process consecutive TLV sequences.

[0035] As discussed above, the information about the TLV headers and sequence types and structures placed in the flexible bus can be used by subsequent TLV processors to edit TLV sequences without sacrificing speed or requiring such processors to re-parse or scan the entire TLV header. For example, a TLV processor can identify the presence of a TLV header stack from a packet based on an indication from a flexible parser in the flexible bus. Using a {type, offset} tuple or other TLV sequence identifier, the processor can extract a specific TLV sequence from the packet by reading the header bits at the offset. TLV sequences can be modified, logged, added, or deleted by modifying the TLV presence bitmap and recalculating the required offsets.

[0036] Figure 3is a block diagram depicting a flexible TLV processor circuit 300 according to some embodiments. The TLV processor circuit can read the TLV presence bitmaps generated by a TLV parser or extractor as discussed above, and in some embodiments, can also read the modified TLV presence bitmaps generated by previous TLV processors in the pipeline. If a TLV sequence tuple or header is identified in the parser or extractor presence bitmap but not in the updated bitmap, the TLV sequence may have been deleted by the processor. Conversely, if the TLV sequence is present in the updated bitmap but not in the bitmap from the extractor, the sequence may have been added by the processor. If it is present in both, the sequence may have been rewritten or modified. Based on the comparison results, the offsets can be recalculated (e.g., based on the length of that sequence, the offsets of the tuples after the added, deleted, or rewritten sequences are updated according to the bitmap). For example, given an anchor offset identifying 20 octets and type / offset tuples [{A, 0}, {C, 22}, {E, 40}] (e.g., indicating that the first TLV sequence starts at octet 20 in the frame after non-TLV header information (e.g., source or destination address) or at octet 0 in the TLV header; the second TLV sequence starts at octet 42 in the frame or at octet 22 in the TLV header; and the third TLV sequence starts at octet 60 in the frame or at octet 40 in the TLV header) for an extractor output bitmap and an updated bitmap [{A, 0}, {C, 24}, {D, 2}], the processor can determine that the first TLV sequence has been written and extended by two octets, the second TLV sequence has been maintained (or rewritten with the same length), and the third TLV sequence has been removed and replaced. In many embodiments, the tuples of the most recently added TLV sequences (e.g., the {D, 2} tuple above) may not have the correct position offsets (or may not contain position offsets in some embodiments) because the processing stage in the pipeline where the tuple was added may not know the correct position offset value and may only know the order of the TLV sequences within the header. In such embodiments, the processor can determine from the comparison of the bitmaps that the sequence has been added and its order within the sequence. In various embodiments, the processor can also read type / offset tuples and / or type / order tuples. At block 305, the offset of each TLV sequence can thus be recalculated based on the previous processing stage, and at block 310, one or more TLV sequences can be extracted from the updated (or original (if not modified)) TLV header and added, modified, or deleted as necessary. Value containers each corresponding to the value of a TLV sequence can be placed on and retrieved from the flexible bus 20, allowing data to be exchanged between processors 300. For example, as discussed above, a timestamp value can be placed on the bus 20 for use by other processing stages. The values can be placed in containers that can contain masks and / or shift values (e.g., for scaling).In some embodiments, containers may be allowed to overlap to update the same fields depending on shift and mask capabilities.

[0037] At block 315, the updated TLV header stack may be rewritten to the packet. As discussed above, advantageously, due to the flexible TLV embodiments discussed herein, each of one or more TLV processors may operate on different TLV sequences within them simultaneously as the packet flows through packet bus 10 by extracting, buffering, and reinserting the entire packet or TLV header into the bus, without bottlenecks or throughput delays. This may allow gigabyte or terabyte throughput, as discussed above.

[0038] Figure 4 is a flow chart depicting a method of flexible TLV parsing and extraction according to some embodiments. At step 402, a parser may receive a packet and determine whether the packet contains a TLV header. Identifying the header may include parsing one or more flags or pre-positioned option fields, identifying the type of the packet, or otherwise identifying whether one or more TLV sequences are included in the header. If so, then at step 404, the parser may generate an identifier that a TLV header exists and identify an offset or anchor offset corresponding to the start of the TLV header within the packet or frame.

[0039] At step 406, a TLV parser or extractor may read a portion of the TLV header, such as the first TLV sequence. At step 408, the TLV parser or extractor may identify the type of the TLV sequence. Identifying the type may include matching the type field of the TLV sequence to a plurality of predetermined types, such as via a CAM array or other memory circuit storing corresponding type identifiers. The match array may output one or more of the type, bit offset, length mask, length displacement, length constant, byte offset of the value field, and / or extraction command, as discussed above. The output may be used to identify the length of the value field of the TLV sequence at step 410. In some embodiments, the TLV extractor or parser may calculate a position offset of the TLV sequence based on the anchor offset, the length or position offset of any previous TLV sequences, and / or the offset output by the type match array.

[0040] In some embodiments in which the array contains an extraction command, one or more words or octets may be extracted from the start or end of the value field at step 416, where the field is shifted (e.g., via a barrel shifter or other such word- or octet-based shifter) at step 414 if necessary to extract the value from the end of the value field. The value may be placed on a flexible bus and may be placed in a container, as discussed above (e.g., together with a mask and / or shift identifier, in some embodiments as discussed above). In some embodiments, steps 414 to 416 may be repeated for additional values to be extracted (as shown by the dashed lines).

[0041] In step 418, a TLV sequence in the TLV presence bitmap can be identified, for example, by adding a tuple {type, position offset} to the TLV presence bitmap. In step 420, the bitmap can be placed into the flexible bus for use by other TLV extractors and / or TLV processors. In some embodiments where a TLV parser or extractor is used to parse additional TLV sequences within a header, the header can be shifted by an amount based on the identified length of the sequence (e.g., the length of the type and length fields and the value field), and steps 406 to 422 can be repeated for the additional TLV sequences within the header. In other embodiments, an additional TLV parser or extractor can process other TLV sequences in parallel based on an identifier of an anchored offset and the length or position offset of one or more previous TLV sequences placed onto the flexible bus by the TLV parser or extractor.

[0042] Figure 5 is a flowchart depicting a method of flexible TLV editing according to some embodiments. In step 502, a TLV processor can receive or retrieve a TLV presence bitmap from a TLV parser or extractor. In some embodiments, the TLV processor can receive or retrieve one or more {type, offset} tuples, for example, from the flexible bus or directly from an upstream parser.

[0043] In step 504, in some embodiments, the TLV processor can extract a TLV header stack from the packet based on an anchored offset. In step 506, the TLV processor can read the TLV presence bitmap to identify a desired TLV sequence within the TLV header, and in step 508, the TLV sequence and one or more associated values can be modified by extracting the TLV sequence from the TLV header of the packet based on the position offset and / or the anchored offset associated with the corresponding type identifier in the presence bitmap and / or by deleting the TLV sequence or inserting the TLV sequence into the TLV header. In some embodiments, values can be retrieved from the flexible bus to be inserted into the TLV sequence and / or to modify values within the TLV sequence.

[0044] In step 510, in some embodiments, the TLV processor can generate a new or modified TLV presence bitmap and can place the bitmap into the flexible bus or pass the bitmap to a subsequent processor stage in the pipeline. In step 512, the TLV processor can update the packet by inserting the modified TLV header stack into the packet header.

[0045] As discussed above, steps 502 through 512 may be repeated for additional TLV sequences or headers, and / or steps 502 through 512 may be performed in parallel by multiple TLV processors on different TLV sequences or portions of the TLV header stack. In some embodiments (shown in dashed lines), steps 508 through 510 and / or steps 502 through 510 may be repeated before inserting or updating the grouped TLV headers at step 512. Similarly, in other embodiments, any of steps 502 through 510 may be performed multiple times before updating the group at step 512. In some embodiments, the group may not be updated (e.g., step 512 may be skipped), and the modified TLV sequence may be used elsewhere.

[0046] Accordingly, embodiments of the systems and methods discussed herein provide a flexible TLV parser and identification map that can be used to quickly identify TLV sequences for subsequent processing in a pipeline. The flexible TLV bus may provide an auxiliary path for the TLV headers and identification map, allowing subsequent processing stages to read, process, modify, delete, or otherwise utilize individual TLV sequences within the headers.

[0047] In some aspects, the present disclosure relates to a method for flexibly parsing a type-length-value (TLV) header of a communication packet. The method includes (a) identifying, by a TLV extractor, the presence of a TLV sequence in a header of a communication packet and an anchor offset corresponding to a position of the TLV sequence. The method further includes (b) determining, by the TLV extractor, a type of the TLV sequence. The method further includes (c) calculating, by the TLV extractor, a position offset corresponding to the TLV sequence within the header based on the anchor offset. The method further includes (d) filling, by the TLV extractor, an existence bitmap with the determined type and position offset.

[0048] In some embodiments, determining the type of the TLV sequence includes: providing a first portion of the TLV sequence to each of a plurality of matching circuits, each matching circuit associated with a type among a plurality of corresponding types; and receiving, from a first matching circuit among the plurality of matching circuits, an identification of the matching type. In another embodiment, the plurality of matching circuits includes a plurality of content-addressable memory circuits.

[0049] In some embodiments, the TLV sequence is the first TLV sequence among a plurality of TLV sequences, and the method includes: advancing the header of a communication packet to a second TLV sequence among the plurality of TLV sequences; and repeating steps (a) through (d) for the second TLV sequence. In another embodiment, calculating the position offset corresponding to the second TLV sequence includes: extracting, by a TLV extractor, the length identified in the first TLV sequence; and calculating, by the TLV extractor, the position offset corresponding to the second TLV sequence based on the anchor offset of the first TLV sequence and the extracted length. In yet another embodiment, advancing the header of the communication packet includes advancing the header by an amount based on the extracted length of the first TLV sequence.

[0050] In some embodiments, a presence bitmap includes a plurality of tuples of types of a plurality of corresponding TLV sequences in the header of a communication packet and position offsets. In some embodiments, the method includes transmitting the presence bitmap to a TLV processor via a bus. In another embodiment, the method includes extracting at least one word from the value of the TLV sequence and transmitting the extracted at least one word to the TLV processor via the bus.

[0051] In another aspect, the present disclosure relates to a circuit for flexibly parsing a type-length-value (TLV) header of a communication packet. The circuit includes: a TLV extractor configured to receive a TLV header extracted from a communication packet and further configured to: (a) identify the presence of a TLV sequence in the TLV header and an anchor offset corresponding to the position of the TLV sequence; (b) determine the type of the TLV sequence; (c) calculate a position offset corresponding to the TLV sequence within the header based on the anchor offset; and (d) populate a presence bitmap with the determined type and position offset.

[0052] In some embodiments, the TLV extractor further includes a plurality of matching circuits, each matching circuit associated with a type among a plurality of corresponding types; and a first matching circuit among the plurality of matching circuits is configured to generate an identification of the matching type of the TLV sequence. In another embodiment, the plurality of matching circuits includes a plurality of content-addressable memory circuits.

[0053] In some embodiments, the TLV sequence is the first TLV sequence among a plurality of TLV sequences, and the TLV extractor is further configured to: advance the header of the communication packet to the second TLV sequence among the plurality of TLV sequences; and repeat steps (a) through (d) for the second TLV sequence. In another embodiment, the TLV extractor is further configured to calculate a position offset corresponding to the second TLV sequence by extracting the length identified in the first TLV sequence and calculating the position offset corresponding to the second TLV sequence based on the anchor offset and the extracted length of the first TLV sequence. In yet another embodiment, the TLV extractor is further configured to advance the header by an amount based on the extracted length of the first TLV sequence.

[0054] In some embodiments, an existence bitmap includes a plurality of tuples of types of a plurality of corresponding TLV sequences in the header of the communication packet and position offsets. In some embodiments, the TLV extractor communicates with the TLV processor via a bus and is further configured to transmit the existence bitmap to the TLV processor via the bus. In another embodiment, the TLV extractor is further configured to extract at least one word from the value of the TLV sequence and transmit the extracted at least one word to the TLV processor via the bus.

[0055] In yet another aspect, the present disclosure relates to a circuit for modifying a type-length-value (TLV) header of a communication packet. The circuit includes a TLV processor that communicates with a TLV extractor via a first bus, the TLV processor being configured to: receive, via the first bus, an existence bitmap from the TLV extractor, the existence bitmap including tuples identifying types of TLV sequences in a communication packet received via a second bus and position offsets of the TLV sequences within the packet; modify the TLV sequences in the communication packet according to the position offsets in the existence bitmap; update the existence bitmap according to the modified TLV sequences; transmit the updated existence bitmap via the first bus; and transmit the modified communication packet via the second bus.

[0056] In some embodiments, the TLV processor is further configured to modify the TLV sequences by inserting a second TLV sequence into the communication packet and update the existence bitmap with a new position offset of the TLV sequences based on the length of the second TLV sequence.

[0057] B. Computing and Network Environment

[0058] Specific embodiments of the solution have been discussed. It may be helpful to describe aspects of the operating environment and associated system components (such as hardware elements) in connection with the methods and systems described herein. Refer to Figure 6A, depicting an embodiment of a network environment. In a brief overview, the network environment includes a wireless communication system that includes one or more access points 606, one or more wireless communication devices 602, and network hardware components 692. The wireless communication devices 602 may include, for example, laptop computers 602, tablet computers 602, personal computers 602, and / or cellular phone devices 602. Details of embodiments of each wireless communication device and / or access point are described in more detail with reference to Figure 6B and 6C described in more detail. In one embodiment, the network environment may be an ad-hoc network environment, an infrastructure wireless network environment, a subnet environment, etc.

[0059] The access point (AP) 606 may be operably coupled to the network hardware components 692 via a local area network connection. The network hardware 692, which may include routers, gateways, switches, bridges, modems, system controllers, devices, etc., may provide a local area network connection for the communication system. Each of the access points 606 may have an associated antenna or antenna array to communicate with the wireless communication devices 602 in its area. The wireless communication devices 602 may register with a specific access point 606 to receive services from the communication system (e.g., via a SU-MIMO or MU-MIMO configuration). For direct connections (e.g., point-to-point communication), some wireless communication devices 602 may communicate directly via an allocated channel and communication protocol. Some wireless communication devices 602 may be mobile or relatively stationary with respect to the access point 606.

[0060] In some embodiments, the access point 606 includes a device or module (including a combination of hardware and software) that allows the wireless communication device 602 to connect to a wired network using WiFi or other standards. The access point 606 is sometimes referred to as a wireless access point (WAP). The access point 606 may be configured, designed, and / or built to operate in a wireless local area network (WLAN). In some embodiments, the access point 606 may be connected to a router as a stand-alone device (e.g., via a wired network). In other embodiments, the access point may be a component of the router. The access point 606 may provide access to the network for multiple devices 602. The access point 606 may be connected to a wired Ethernet connection, for example, and use a radio frequency link to provide a wireless connection for other devices 602 to utilize the wired connection. The access point 606 may be built and / or configured to support standards for sending and receiving data using one or more radio frequencies. Those standards and the frequencies they use may be defined by the IEEE (e.g., the IEEE 802.11 standard). The access point may be configured and / or used to support public Internet hotspots and / or to extend the Wi-Fi signal range on an internal network.

[0061] In some embodiments, the access point 606 can be used in a wireless network (such as IEEE 802.11, Bluetooth, ZigBee, any other type of radio-based network protocol, and / or variations thereof) (e.g., in a home or building). Each of the wireless communication devices 602 can include a built-in radio and / or be coupled to a radio. Such wireless communication devices 602 and / or access point 606 can operate according to various aspects of the present disclosure presented herein to enhance performance, reduce cost and / or size, and / or enhance broadband applications. Each wireless communication device 602 can have the ability to act as a client node attempting to access resources (such as data and connections to networked nodes such as servers) via one or more access points 606.

[0062] The network connection can include any type and / or form of network and can include any of the following: point-to-point network, broadcast network, telecommunications network, data communication network, computer network. The topology of the network can be a bus, star, or ring network topology. The network can be any such network topology known to those of ordinary skill in the art that can support the operations described herein. In some embodiments, different types of data can be transmitted via different protocols. In other embodiments, the same type of data can be transmitted via different protocols.

[0063] The communication devices 602 and access point 606 can be deployed on and / or executed on any type and form of computing device, such as a computer, network device, or equipment capable of communicating on any type and form of network and performing the operations described herein. Figure 6B and 6C A block diagram depicting a computing device 600 that can be used to practice embodiments of the wireless communication device 602 or access point 606. As Figure 6B and 6C shown, each computing device 600 includes a central processing unit 621 and a main memory unit 622. As Figure 6B shown, the computing device 600 can include a storage device 628, an installation device 616, a network interface 618, an I / O controller 623, display devices 624a to 624n, a keyboard 626, and a pointing device 627 such as a mouse. The storage device 628 can include (without limitation) an operating system and / or software. As Figure 6C shown, each computing device 600 can also include additional optional elements, such as a memory port 603, a bridge 670, one or more input / output devices 630a to 630n (generally referred to using the reference element symbol 630), and a cache memory 640 that communicates with the central processing unit 621.

[0064] The central processing unit 621 is any logic circuitry that responds to and processes instructions fetched from the main memory unit 622. In many embodiments, the central processing unit 621 is provided by a microprocessor unit such as, for example, a microprocessor unit manufactured by Intel Corporation of Mountain View, California; a microprocessor unit manufactured by International Business Machines of White Plains, New York; or a microprocessor unit manufactured by Advanced Micro Devices of Sunnyvale, California. The computing device 600 can be based on any of these processors or any other processor capable of operating as described herein.

[0065] The main memory unit 622 can be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor 621, such as any type or variant of static random access memory (SRAM), dynamic random access memory (DRAM), ferroelectric RAM (FRAM), NAND flash memory, NOR flash memory, and solid state drive (SSD). The main memory 622 can be based on any of the memory chips described above or any other available memory chip capable of operating as described herein. In Figure 6B the illustrated embodiment, the processor 621 communicates with the main memory 622 via the system bus 650 (described in more detail below). Figure 6C An embodiment of the computing device 600 is depicted in which the processor communicates directly with the main memory 622 via a memory port 603. For example, in Figure 6C the main memory 622 can be DRDRAM.

[0066] Figure 6C An embodiment is depicted in which the main processor 621 communicates directly with the cache memory 640 via an auxiliary bus sometimes referred to as a backside bus. In other embodiments, the main processor 621 uses the system bus 650 to communicate with the cache memory 640. The cache memory 640 typically has a faster response time than the main memory 622 and is provided by, for example, SRAM, BSRAM, or EDRAM. In Figure 6CIn the illustrated embodiment, the processor 621 communicates with various I / O devices 630 via a local system bus 650. Various buses can be used to connect the central processing unit 621 to any of the I / O devices 630, such as a VESA VL bus, an ISA bus, an EISA bus, a Micro Channel Architecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or a NuBus. For an embodiment in which the I / O device is a video display 624, the processor 621 can use an Accelerated Graphics Port (AGP) to communicate with the display 624. Figure 6C Depicts an embodiment of a computer 600 in which the main processor 621 can communicate directly with the I / O device 630b, for example, via HyperTransport, RapidIO, or InfiniBand communication technologies. Figure 6C Also depicts an embodiment in which a combination of local bus and direct communication is used: the processor 621 communicates with the I / O device 630a using a local interconnect bus while communicating directly with the I / O device 630b.

[0067] A wide variety of I / O devices 630a through 630n can be present in the computing device 600. Input devices include keyboards, mice, trackpads, trackballs, microphones, dials, touchpads, touchscreens, and graphics tablets. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and dye-sublimation printers. The I / O devices can be Figure 6B controlled by the I / O controller 623 shown in. The I / O controller can control one or more I / O devices, such as the keyboard 626 and the pointing device 627 (such as a mouse or a stylus). Additionally, the I / O devices can also provide storage devices and / or mounting media 616 for the computing device 600. In still other embodiments, the computing device 600 can provide a USB connection (not shown) to receive a handheld USB storage device, such as a USB flash drive series device of a device manufactured by Twintech Industry, Inc. of Los Alamitos, California.

[0068] Referring again to Figure 6B, the computing device 600 may support any suitable installation device 616, such as a disk drive, CD-ROM drive, CD-R / RW drive, DVD-ROM drive, flash drive, tape drives of various formats, USB devices, hard disk drives, network interfaces, or any other device suitable for installing software and programs. The computing device 600 may further include storage devices for storing an operating system and other related software and for storing application software programs (e.g., any program or software 620 for implementing (e.g., configured and / or designed for) the systems and methods described herein), such as one or more hard disk drives or redundant arrays of independent disks. Optionally, any of the installation devices 616 may also be used as a storage device. Additionally, the operating system and software may run from a bootable medium.

[0069] In addition, the computing device 600 may include a network interface 618 to interface to a network 604 through various connections, including but not limited to standard telephone lines, LAN or WAN links (such as 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (such as ISDN, frame relay, ATM, gigabit Ethernet, Ethernet-over-SONET), wireless connections, or some combination of any or all of the above connections. Various communication protocols (e.g., TCP / IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.16B, IEEE 802.11g, IEEE 802.11n, IEEE802.11ac, IEEE 802.11ad, CDMA, GSM, WiMax, and direct asynchronous connections) may be used to establish the connection. In one embodiment, the computing device 600 communicates with other computing devices 600' via any type and / or form of gateway or tunneling protocol (such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS)). The network interface 618 may include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing the computing device 600 to any type of network capable of communicating and performing the operations described herein.

[0070] In some embodiments, computing device 600 may include or be connected to one or more display devices 624a through 624n. Accordingly, any of I / O devices 630a through 630n and / or I / O controller 623 may include any type and / or form of suitable hardware, software, or a combination of hardware and software to support, enable, or provide the connection to and use of display devices 624a through 624n by computing device 600. For example, computing device 600 may include any type and / or form of video adapter, video card, driver, and / or library to interface, communicate with, connect to, or otherwise use display devices 624a through 624n. In one embodiment, the video adapter may include multiple connectors to interface to display devices 624a through 624n. In other embodiments, computing device 600 may include multiple video adapters, where each video adapter is connected to display devices 624a through 624n. In some embodiments, any portion of the operating system of computing device 600 may be configured to use multiple displays 624a through 624n. Those skilled in the art will recognize and understand the various ways and embodiments in which computing device 600 may be configured to have one or more display devices 624a through 624n.

[0071] In additional embodiments, I / O device 630 may be a bridge between system bus 650 and an external communication bus such as a USB bus, an Apple Desktop bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a FibreChannel bus, a Serial Attached SCSI bus, a USB connection, or an HDMI bus.

[0072] Figure 6B and 6CThe computing device 600 of the type depicted may operate under the control of an operating system that controls the scheduling of tasks and access to system resources. The computing device 600 may run any operating system, such as any version of the MICROSOFT WINDOWS operating system, different versions of Unix and Linux operating systems, any version of MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open-source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein. Exemplary operating systems include, but are not limited to: Android, produced by Google Inc.; WINDOWS 7 and 8, produced by Microsoft Corporation of Redmond, Washington; MAC OS, produced by Apple Computer of Cupertino, California; WebOS, produced by Research In Motion (RIM); OS / 2, produced by International Business Machines of Armonk, New York; and Linux, a freely available operating system released by Caldera of Salt Lake City, Utah, or any type and / or form of Unix operating system, etc.

[0073] The computer system 600 may be any workstation, telephone, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone or other portable telecommunications device, media playback device, gaming system, mobile computing device, or any other type and / or form of computing, telecommunications, or media device capable of communicating. The computer system 600 has sufficient processor power and memory capacity to perform the operations described herein.

[0074] In some embodiments, computing device 600 may have different processors, operating systems, and input devices consistent with the device. For example, in one embodiment, computing device 600 is a smart phone, mobile device, tablet computer, or personal digital assistant. In yet other embodiments, computing device 600 is an Android-based mobile device, a handheld device or smart phone by Apple Computer of Cupertino, California, or based on BlackBerry or WebOS, such as a device manufactured by Research In Motion Limited. Additionally, computing device 600 may be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone, any other computer, or other form of computing or telecommunications device capable of communicating and having sufficient processor power and memory capacity to perform the operations described herein.

[0075] Although the present disclosure may refer to one or more "users", such "users" may refer to devices or stations (STAs) associated with a user, e.g., consistent with the terms "user" and "multi-user" commonly used in the context of multi-user multiple-input and multiple-output (MU-MIMO) environments.

[0076] Although the examples of communication systems described above may include devices and APs operating according to the 802.11 standard, it should be understood that embodiments of the described systems and methods may operate according to other standards and use wireless communication devices other than those configured as devices and APs. For example, multi-unit communication interfaces associated with cellular networks, satellite communications, vehicle communication networks, and other non-802.11 wireless networks may utilize the systems and methods described herein to achieve improved overall capacity and / or link quality without departing from the scope of the systems and methods described herein.

[0077] It should be noted that certain paragraphs of the present disclosure may refer to terms such as "first" and "second" related to devices, operating modes, transmission chains, antennas, etc. for the purpose of identification or differentiation from each other or others. These terms are not intended to solely associate entities (e.g., first device and second device) in terms of time or sequence, although in some cases, these entities may include such a relationship. These terms also do not limit the number of possible entities (e.g., devices) that may operate within a system or environment.

[0078] It should be understood that the systems described above may provide any or multiple or each of those components, and these components may be provided on a stand-alone machine or, in some embodiments, on multiple machines in a distributed system. Additionally, the systems and methods described above may be provided as one or more computer-readable programs or executable instructions embodied on or in one or more articles of manufacture. The article of manufacture may be a floppy disk, a hard disk, a CD-ROM, a flash memory card, a PROM, a RAM, a ROM, or a magnetic tape. Generally, the computer-readable program may be implemented in any programming language such as LISP, PERL, C, C++, C#, PROLOG or in any byte code language such as JAVA. The software program or executable instructions may be stored on or in one or more articles of manufacture as object code.

[0079] While the foregoing written description of the methods and systems enables one of ordinary skill in the art to make and use what is currently considered to be its best mode, one of ordinary skill in the art should understand and appreciate that there are variations, combinations, and equivalents of specific embodiments, methods, and examples herein. The methods and systems should not, therefore, be limited by the embodiments, methods, and examples described above, but rather should be limited by all embodiments and methods within the scope and spirit of the present invention.

Claims

1. A method for flexibly parsing a type - length - value (TLV) header of a communication packet, which includes: (a) identifying, by a TLV extractor, the presence of a TLV sequence in a header of a communication packet and an anchoring offset corresponding to a position of the TLV sequence; (b) determining, by the TLV extractor, a type of the TLV sequence; (c) calculating, by the TLV extractor, a position offset corresponding to the TLV sequence within the header based on the anchoring offset; and (d) filling, by the TLV extractor, an existence bitmap with the determined type and position offset.

2. The method according to claim 1, wherein determining the type of the TLV sequence further includes: providing a first portion of the TLV sequence to each of a plurality of matching circuits, each matching circuit being associated with a type among a plurality of corresponding types; and receiving, from a first matching circuit among the plurality of matching circuits, an identification of a matching type.

3. The method according to claim 2, wherein the plurality of matching circuits includes a plurality of content - addressable memory circuits.

4. The method according to claim 1, wherein the TLV sequence is a first TLV sequence among a plurality of TLV sequences, and the method further includes: advancing the header of the communication packet to a second TLV sequence among the plurality of TLV sequences, and repeating steps (a) to (d) for the second TLV sequence.

5. The method according to claim 4, wherein calculating the position offset corresponding to the second TLV sequence further includes: extracting, by the TLV extractor, a length identified in the first TLV sequence; and calculating, by the TLV extractor, the position offset corresponding to the second TLV sequence based on the anchoring offset of the first TLV sequence and the extracted length.

6. The method according to claim 5, wherein advancing the header of the communication packet further includes advancing the header by an amount based on the extracted length of the first TLV sequence.

7. The method according to claim 1, wherein the existence bitmap includes a plurality of tuples of types of a plurality of corresponding TLV sequences in the header of the communication packet and position offsets.

8. The method according to claim 1, which further includes transmitting the existence bitmap to a TLV processor via a bus.

9. The method according to claim 8, which further includes extracting at least one word from a value of the TLV sequence and transmitting the extracted at least one word to the TLV processor via the bus.

10. A circuit for flexibly parsing a type - length - value (TLV) header of a communication packet, which includes: a TLV extractor configured to receive a TLV header extracted from a communication packet and further configured to: (a) identify the presence of a TLV sequence in the TLV header and an anchoring offset corresponding to a position of the TLV sequence; (b) determine the type of the TLV sequence; (c) calculate a position offset corresponding to the TLV sequence within the header based on the anchoring offset; and (d) fill an existence bitmap with the determined type and position offset.

11. The circuit according to claim 10, wherein the TLV extractor further comprises a plurality of matching circuits, each matching circuit being associated with a type among a plurality of corresponding types; and wherein a first matching circuit among the plurality of matching circuits is configured to generate an identification of the matching type of the TLV sequence.

12. The circuit according to claim 11, wherein the plurality of matching circuits comprises a plurality of content addressable memory circuits.

13. The circuit according to claim 10, wherein the TLV sequence is a first TLV sequence among a plurality of TLV sequences, and wherein the TLV extractor is further configured to: advance the header of the communication packet to a second TLV sequence among the plurality of TLV sequences, and repeat steps (a) to (d) for the second TLV sequence.

14. The circuit according to claim 13, wherein the TLV extractor is further configured to calculate a position offset corresponding to the second TLV sequence by extracting a length identified in the first TLV sequence and calculating the position offset corresponding to the second TLV sequence based on the anchor offset and the extracted length of the first TLV sequence.

15. The circuit according to claim 14, wherein the TLV extractor is further configured to advance the header by an amount based on the extracted length of the first TLV sequence.

16. The circuit according to claim 11, wherein the presence bitmap comprises a plurality of tuples and position offsets of the types of a plurality of corresponding TLV sequences in the header of the communication packet.

17. The circuit according to claim 11, wherein the TLV extractor communicates with a TLV processor via a bus, and is further configured to transmit the presence bitmap to the TLV processor via the bus.

18. The circuit according to claim 17, wherein the TLV extractor is further configured to extract at least one word from the value of the TLV sequence and transmit the extracted at least one word to the TLV processor via the bus.

19. A circuit for modifying a type-length-value (TLV) header of a communication packet, the circuit comprising: a TLV processor that communicates with a TLV extractor via a first bus, the TLV processor being configured to: receive, via the first bus, a presence bitmap from the TLV extractor, the presence bitmap comprising tuples identifying TLV sequence types in a communication packet received via a second bus and position offsets of the TLV sequences within the packet; modify the TLV sequences in the communication packet according to the position offsets in the presence bitmap; update the presence bitmap according to the modified TLV sequences; transmit the updated presence bitmap via the first bus; and and transmit the modified communication packet via the second bus.

20. The circuit according to claim 19, wherein the TLV processor is further configured to modify the TLV sequence by inserting a second TLV sequence into the communication packet and update the presence bitmap with a new position offset of the TLV sequence based on the length of the second TLV sequence.

Images