Patent Application
20120147901
This application claims priority to European Patent Application No. EP10306404, entitled “COMPACTION OF A BINARY IDENTIFIER,” filed Dec. 14, 2010, the disclosure of which is hereby incorporated herein by reference in its entirety.
The present application is related to the following commonly assigned patent applications: U.S. patent application Ser. No. ______ (Attorney Docket No. FR920100060US1), entitled “ANALYSIS OF NETWORK PACKETS USING A GENERATED HASH CODE” by Claude Basso et al.; and U.S. patent application Ser. No. ______ (Attorney Docket No. FR920100061US1), entitled “BIDIRECTIONAL PACKET FLOW TRANSFORMATION” by Claude Basso et al., all of which were filed on even data herewith and are incorporated herein by reference in their entirety for all purposes.
1. Field
This disclosure relates generally to generation of a compacted binary identifier and, more specifically, to generation of compacted Internet Protocol version 6 (IPv6) addresses.
2. Related Art
Internet Protocol version 4 (IPv4) defines the addressing capabilities of the Internet in its original form with 32-bit addresses, which provides a total of 232 or about 4.3 billion possible addresses. The explosive growth and worldwide proliferation of networks has meant that all available addresses under IPv4 are expected to be exhausted by 2012. Accordingly, Internet Protocol version 6 (IPv6) has been defined to replace IPv4 to addresses certain shortcomings of IPv4. In particular, IPv6 specifies 128-bit addresses for a theoretical capacity of 3.4×1038 addresses.
A technique for generating a compacted binary identifier includes breaking an original binary identifier into equal parts. Each bit of a first one of the parts is exclusive ORed with a start-up value to generate a first result. Each bit of the first result is then exclusive ORed with a respective bit of a second one of the parts to generate a second result.
The present invention is illustrated by way of example and is not intended to be limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.
As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, system, device, or computer program product. Accordingly, the present invention may take the form of an embodiment including hardware, an embodiment including software (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a circuit, module, or system. The present invention may, for example, take the form of a computer program product on a computer-usable storage medium having computer-usable program code, e.g., in the form of one or more design files, embodied in the medium.
Any suitable computer-usable or computer-readable storage medium may be utilized. The computer-usable or computer-readable storage medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or flash memory, a portable compact disc read-only memory (CD-ROM), an optical storage device, or a magnetic storage device. As used herein the term “coupled” includes a direct electrical connection between elements or blocks and an indirect electrical connection between elements or blocks achieved using one or more intervening elements or blocks.
According to aspects of the present disclosure, compaction of relatively large (16-byte) IPv6 addresses into regular (4-byte) address fields is performed while preserving the properties required for a hash key. The compaction utilizes cumulative exclusive OR (XOR) based prehashing of 4-bytes at a time. Compaction of 4-bytes at a time advantageously minimizes the logic and silicon area required to support IPv6 addresses, for example, in a hasher that accepts keys like ‘5-tuples’. In the case of a 5-tuple, hash keys are assembled with five fields extracted from packet headers that are representative of a packet flow to which an associated packet belongs. A typical example of a 5-tuple used to identify transmission control protocol (TCP) connections includes: an IP source address (IP SA); an IP destination address (IP DA); a protocol byte (Prot); a TCP source port (TCP SP); and a TCP destination port (TCP DP).
It should be appreciated that an implementation problem may occur when a packet has an IPv6 layer 3 (L3) header. For example, while IPv4 headers have 4-byte IP addresses, IPv6 headers have 16-byte IP addresses. As such, a 5-tuple key for an IPv6 header is much larger than an IPv4 header. For example, a 5-tuple key for an IPv4 header includes thirteen bytes (i.e., IPv4=IP SA(4 bytes)+IP DA(4 bytes)+protocol(1 byte)+TCP SP(2 bytes)+TCP DP(2 bytes)=13 bytes) while a 5-tuple key for an IPv6 header includes thirty-seven bytes (i.e., IPv6=IP SA(16 bytes)+IP DA(16 bytes)+protocol(1 byte)+TCP SP(2 bytes)+TCP DP(2 bytes)=37 bytes).
Implementing a hasher with a 37-byte input register is usually more expensive in silicon area due to, for example, the one-hundred ninety-two (24×8=192) additional latches required to hold the larger IPv6 addresses and the larger combinatorial cone of logic originating at 37×8=296 versus 13×8=104 inputs. Since the size of the cone of logic constituting a hasher is not linear with the number of hasher inputs, the area ratio between the two implementations is at least four times. According to the present disclosure, IPv6 addresses are pre-processed to reduce IPv6 addresses to the IPv4 address size in order to utilize the same key input registers and logic cone for IPv6 and IPv4 addresses.
According to the present disclosure, a compacted binary identifier (e.g., a compacted IPv6 address) is generated such that the same key input registers and logic cone may be utilized for both IPv6 and IPv4 addresses. In general, the disclosed compaction process is non-deterministic. That is, a number of different binary identifiers can produce the same compacted identifier and, as such, it is not possible to reconstitute an original binary identifier from a compacted identifier. While this property may rule out the use of a compacted identifier in certain applications there are, nevertheless, many applications in which a compacted identifier is satisfactory. More particularly, the disclosed approach is suitable for many applications where it is desired to characterise packets or other data on the basis of identity information without that characterisation being granular to the level of unique identities. Examples of such applications include packet identifiers and IP filters. As mentioned above, the disclosed approach is particularly useful for a hash function, e.g., a hash function that identifies packet flows in a network processor.
The flexibility of hash functions are typically defined by two properties: the way in which the hash key is assembled; and the properties of the hash function. Several trade-offs are often made to implement flexible hashers by playing on variations of the two properties. Traditionally, flexibility in hash key assembly is achieved in software implementations of hashers, while flexible hash functions usually involve some form of configurable hardware hasher implementation. Each aspect of hasher flexibility typically has limitations. For example, software hash key assemblies have performance limitations when complex patterns are required to build the hash key (in particular, when the key assembly is done at bit-level granularity). As another example, configurable hardware hash functions have silicon area limitations due to configuration logic implementing the base hashing elements (which are typically implemented with XOR gates). The foregoing limitations appear to be especially significant when a hasher is used for identifying packet flows on high-speed interfaces (e.g., 10 Gbps or more), mainly because of the very short packet periodicity (e.g., 67.2 ns or less).
Flexibility for hash key assembly is achieved through distribution bus 120. Distribution bus 120 can fill any input of compaction array 140 byte-wise from parser 110, which may, for example, be implemented as a pico-coded finite state machine (FSM). In this manner, raw keys with any combinations of bytes extracted from the packet by parser 110 may be assembled. The input stages of compaction array 140 (and by the same token the hasher combinatorial cone 150) include a set of 16-byte wide registers that are individually addressable in order to be loaded by any packet parser capable of extracting bytes from packet headers and/or payloads. The order in which the various bytes are loaded is determined by the amount of information included in each extracted byte that can contribute to the flow identification.
The hash function implemented by hasher combinatorial cone 150 is a classical combinatorial cone of logic based on XOR gates that combine all 128-bits of a hash key and produce a resulting 32-bit hash value. Compaction array 140 implements a compaction feature that minimizes the size of the key assembly area (and conversely the silicon area of the hardware hash function receiving the key) by reducing long elements of the key into smaller fields. A typical application is the reduction of 16-byte address fields in IPv6 headers into 4-byte elements that can use the same input registers as the 4-byte addresses extracted from IPv4 headers. As mentioned above, depending on the circumstances, the specific pieces of information that are available (for the construction of the key and which may be desirable to use as inputs to hasher combinatorial cone 150 ) vary.
For example, information available for key construction may include various scenarios, e.g., a 5-tuple format, a 3-tuple format, a 2-tuple format, a multi-protocol label switching (MPLS) 1 format, an MPLS 2 format, and a tunnelled IP-in-IP packet format. The designation and sizes of the various scenario are illustrated in the tables below:
Tunnelled IP-in-IP packets
Depending on the situation, parser control module 112 extracts the various components of the packet in registers 111 that are required to complete a dataset and sends each component to a respective input of compaction array 140. In accordance with at least one embodiment, parser control module 112 maps the information extracted from a packet, in accordance with the scenarios listed above, onto a standard hasher input structure.
It should be appreciated that in other embodiments different structures may be used, or a structure may not be defined, in which case parser control module 112 may simply retain data in the order the data is extracted from a packet, as long as it is reassembled in a set of back-to-back fields. In one or more embodiments, compaction array 140 may only intercept values for the first to fourth and ninth to twelfth bytes, since these are the only bytes which are needed to handle IPv6 addresses. In general, however, compaction array 140 should provide compaction modules for every input of hasher combinatorial cone 150 so as to allow full flexibility in the assignment of data to different inputs. Compaction array 140 has a number of data inputs and a number of outputs equal to the number of inputs of hasher combinatorial cone 150. As shown in
Four bytes of the total of sixteen bytes available at inputs of hasher combinatorial cone 150 are generally reserved for a given IP address, e.g., a source (i.e., first section 210) or destination (i.e., fourth section 240). In the case of an IPv6 address, which as described above requires sixteen bytes, four bytes is insufficient. As described in more detail herein, by sequentially feeding parts of an IPv6 address to a same set of inputs of compaction array 140, a compacted identifier is compiled at the corresponding outputs of compaction array 140 so that a whole IPv6 address can be fed, in compacted form, into hasher combinatorial cone 150. With reference again to
It should be noted that while the structure shown allows the compaction of a series of input values for a given compaction module, in a case where only one input value is received (if the initial value from each latch 1413, 1423, 1433 is 0), the result of the XOR function written to each latch 1413, 1423, 1433 will be equal to the input value. This feature is controlled via reset line 130, which is connected to one input of a respective AND gate 1412, 1422, 1432 situated in each compaction module, so as to AND together the value on reset line 130 and the output of the respective XOR gate, and provide the result as an input to each latch 1413, 1423, 1433. In this manner, by setting the value on reset line 130 to 0, the output of each AND gate 1412, 1422, 1432 is set to 0 and each latch 1413, 1423, 1433 value is also then set to 0 so that the next value received at the input of any compaction module is transmitted faithfully to its output (and on to hasher combinatorial cone 150) without modification. By way of example, the above-described approach is applied to the binary identifier of Table 1.
The binary identifier includes sixteen octets and, as such, corresponds to a standard IPv6 address, although the actual values are random and may not correspond to a valid address. In accordance with the foregoing, the sixteen octets are split into four parts. A first part (Part 1), corresponding to the first row of Table 1, is XORed bitwise with a start-up value of zero. A first partial result (as stored in the latches 1413, 1423, 1433, etc.) after the first cycle is shown in Table 2 below.
Next, a second part (Part 2), corresponding to the second row of Table 1, is XORed bitwise with the result of the preceding (first) cycle (as stored in the latches 1413, 1423, 1433, etc.) to provide a second partial result as shown in Table 3 below.
Then, the third part (Part 3), corresponding to the third row of Table 1, is XORed bitwise with the result of the preceding (second) cycle (as stored in latches 1413, 1423, 1433, etc.) to provide a third partial result as shown in Table 4 below.
Finally, the fourth part (Part 4), corresponding to the fourth row of Table 1, is XORed bitwise with the result of the preceding (third) cycle (as stored in the latches 1413, 1423, 1433, etc.) to provide a final result as shown in Table 5 below.
The final result is then processed through hasher combinatorial cone 150.
As shown in
The process next proceeds to block 425 where it is determined whether any parts remain, i.e., whether n=P. In the case where the last part has been XORed, the process terminates at block 430, where the result of the last XOR function forms the compacted binary identifier. Otherwise the process loops back to block 415. In one or more embodiments, each of the parts comprises a respective sequence of bits retaining the order of a continuous sequence of bits from the original binary identifier. After the completion of the compaction process of
Thereafter, at block 635 a value ‘M’ is set to ‘9’, and at block 625 the Mth byte of the IPV6 address is extracted from the packet in registers 111. At block 635 parser control module 112 determines whether the value of ‘M’ is between ‘8’ and ‘13’, in which case the extracted byte is sent to section 210 of compaction array 140 reserved for source addresses at block 640. If at block 635 it is determined that the value of M is not between ‘8’ and ‘13’, at block 645 parser control module 112 determines whether the value of ‘M’ is between ‘12’ and ‘17’, in which case the extracted byte is sent to section 240 of compaction array 140 reserved for destination addresses at block 650.
If at block 635 parser control module 112 determines that the value of ‘M’ is not between ‘12’ and ‘17’, the process terminates at block 665. After either block 640 or 650 the process proceeds to block 660, where ‘M’ is incremented by one before looping back to block 630. It will be appreciated that the blocks may be carried out in different orders without modifying the overall effect of identifying the presence of an IPv6 packet, extracting the address fields, and sending the fields to the appropriate parts of compaction array 140.
Accordingly, a hasher been disclosed herein that advantageously generates compacted binary identifiers that may be utilized to identify packets for assignment to a packet flow.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” (and similar terms, such as includes, including, has, having, etc.) are open-ended when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Having thus described the invention of the present application in detail and by reference to preferred embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10306404 | Dec 2010 | EP | regional |
