SYSTEMS AND METHODS FOR STATIC CONTEXT HEADER COMPRESSION INSTANTIATION

Systems, methods and computer-readable storage media are provided for encoding, within the SRH-6LoRH field within a data packet, an IPV6 address that can be used to decompress the SCHC information in the data packet. A rule is generated that indicates that the first network address in the SRH-6LoRH field of the data packet is usable to decompress the SCHC information from the data packet as opposed to the compression residue. When the data packet is received at the destination node, the destination node, through a SCHC decompressor, uses the first network address in the SRH-6LoRH field according to the rule to decompress the SCHC information.

TECHNICAL FIELD

The present disclosure generally relates to the field of computer networking, particularly with regard to the extension of statis context header compression (SCHC) to allow for rules to be instantiated dynamically during packet processing based on information found within a node network address and a 6LoRH.

BACKGROUND

SCHC is a stateful compression technique, primarily designed for Internet-of-Things (IoT) and other constrained devices, that recognizes regular expressions as bit patterns and compresses these regular expressions. Through SCHC, a regular expression is given as a matching rule and, based on the rule, an SCHC compressor can elide some bits and indicate that the rule was applied. However, the writing of SCHC rules for every device to hardcode local information, such as their Internet Protocol (IP) address, is impractical. Thus, there is a need to obtain rules from a more dynamically instantiated location.

DETAILED DESCRIPTION

Overview

Disclosed herein are systems, methods and computer-readable storage media for encoding, within the SRH-6LoRH field within a data packet, an IPV6 address that can be used to decompress the SCHC information in the data packet.

In an example, a computer-implemented method comprises generating a data packet. A first field of the data packet is usable to define a set of network addresses corresponding to different nodes along a network route. Further, the data packet includes a SCHC residue. The computer-implemented method further comprises encoding a first network address of the set of network addresses within the first field of the data packet. The first network address corresponds to a destination network address. Further, the destination network address is usable to decompress SCHC information encoded in the data packet. The computer-implemented method further comprises generating a rule. The rule indicates that the first network address within the first field is usable to decompress the SCHC information. Further, an identifier corresponding to the rule is encoded into the data packet. The computer-implemented method further comprises transmitting the data packet. When the data packet is received at a destination node along the network route, the destination node processes the rule identifier to decompress the SCHC information using the first network address according to the rule.

In an example, the set of network addresses includes one or more Internet Protocol version 6 (IPv6) addresses corresponding to the different nodes along the network route.

In an example, the first field is a Segment Routing Header-6LoWPAN Routing Header (SRH-6LoRH).

In an example, the rule is generated dynamically during processing of the data packet.

In an example, the set of network addresses includes one or more Media Access Control (MAC) addresses corresponding to the different nodes along the network route.

In an example, the data packet does not include other SCHC residue corresponding to the destination network address.

In an example, the set of network addresses are consumed as the data packet progresses through the different nodes such that, when the data packet is received at the destination node along the network route, the first field of the data packet includes only the first network address of the set of network addresses.

In an example, a system comprises one or more processors and memory storing thereon instructions that, as a result of being executed by the one or more processors, cause the system to generate a data packet. A first field of the data packet is usable to define a set of network addresses corresponding to different nodes along a network route. Further, the data packet includes a SCHC residue. The instructions further cause the system to encode a first network address of the set of network addresses within the first field of the data packet. The first network address corresponds to a destination network address. Further, the destination network address is usable to decompress SCHC information encoded in the data packet. The instructions further cause the system to generate a rule. The rule indicates that the first network address within the first field is usable to decompress the SCHC information. Further, an identifier corresponding to the rule is encoded into the data packet. The instructions further cause the system to transmit the data packet. When the data packet is received at a destination node along the network route, the destination node processes the rule identifier to decompress the SCHC information using the first network address according to the rule.

In an example, a non-transitory computer-readable storage medium stores thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to generate a data packet. A first field of the data packet is usable to define a set of network addresses corresponding to different nodes along a network route. Further, the data packet includes a SCHC residue. The executable instructions further cause the computer system to encode a first network address of the set of network addresses within the first field of the data packet. The first network address corresponds to a destination network address. Further, the destination network address is usable to decompress SCHC information encoded in the data packet. The executable instructions further cause the computer system to generate a rule. The rule indicates that the first network address within the first field is usable to decompress the SCHC information. Further, an identifier corresponding to the rule is encoded into the data packet. The executable instructions further cause the computer system to transmit the data packet. When the data packet is received at a destination node along the network route, the destination node processes the rule identifier to decompress the SCHC information using the first network address according to the rule.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Disclosed herein are systems, methods and computer-readable storage media for encoding, within the SRH-6LoRH field within a data packet, an IPV6 address that can be used to decompress the SCHC information in the data packet. The present technologies will be described in more detail in the following disclosure as follows. The discussion begins with a detailed description of example systems, processes and environments for encoding an IPV6 address that can be used to decompress the SCHC information in the data packet, as illustrated inFIGS.1through4. The discussion concludes with a description of an example network and computing devices, as illustrated inFIGS.5and6.

FIG.1shows an illustrative example of an environment100in which a data packet102is generated that indicates that the destination IP address specified in the SRH-6LoRH is usable to decompress SCHC information from the data packet102in accordance with at least one embodiment. In the environment100, a new data packet102is generated that may be transmitted to a destination node along a network route. The destination node and any other nodes along the network route may include IoT devices or other constrained devices within a low-power wide area network (LPWAN) or other network that interconnects these IoT devices or other constrained devices. The IoT devices or other constrained devices within the LPWAN or other network may have limited bandwidth with low bit rates, thereby limiting the size of the data packets that may be transmitted over the LPWAN or other network.

In an embodiment, a root node within the LPWAN or other network generates a data packet102that encodes network addresses corresponding to the myriad nodes (including the destination node) along a network route in a SRH. The first network address encoded in the SRH is defined as the destination network address corresponding to the destination node that is to receive and process the data packet102. The other network addresses encoded in the SRH, thus, may correspond to the other intermediate network nodes, or hops, through which the data packet102is to be routed through in order to reach the destination node.

The data packet102may include a dispatch value104that indicates a binary value corresponding to a context switch in the 6LoWPAN parser. This context switch, as illustrated inFIG.1, may correspond to Page 1. This Page 1 paging dispatch (given a binary value of “11110001,” as illustrated inFIG.1), provides a context switch mechanism for 6LoWPAN compression that allows for the introduction of a 6LoWPAN Routing Header (6LoRH) that may be used to carry IPv6 routing information. The 6LoRH may include source routing information such as a compressed form of SRH and other sorts of routing information (e.g., Routing Protocol for Low-Power and Lossy Networks (RPL) Packet Information (RPI), IP-in-IP encapsulation, etc.). The 6LoRH may be expressed in the data packet102as a type-length-value (TLV) field.

In an embodiment, the data packet102further includes an SRH-6LoRH header106that includes a set of compressed network addresses corresponding to the different network nodes or hops according to the network route the data packet102is to traverse to reach a destination node. As illustrated inFIG.1, the SRH-6LoRH header106is a Type 1 SRH-6LoRH header, whereby the network addresses that are compressed into the data packet102are derived from an Institute of Electrical and Electronic Engineers (IEEE) 802.15.4 short address and the corresponding network nodes share a personal area network (PAN) identifier. The SRH-6LoRH header106may further indicate the number of different network nodes or hops that the data packet102is to traverse, including the root and destination nodes. As an illustrative example, the SRH-6LoRH header106may indicate a size, S, of x. This may denote that the SRH-6LoRH indicates x+1 hops, including the root and destination nodes. The network address of the root node may be taken as reference and the last two octets of the network addresses of the intermediate hops are encoded.

The data packet102may further include an SCHC dispatch field108, which may serve to indicate that the next fields in the data packet102include a SCHC header that comprises a rule identifier and a compression residue. In an embodiment, the SCHC dispatch field108is used to indicate that the data packet102is using the 6LoRH for the SCHC-compressed address. Accordingly, the root node may instantiate a rule according to the SCHC charter that provides for the use of the destination network address indicated in the SRH-6LoRH to decompress the SCHC information encoded in the data packet102. This rule may be assigned a rule identifier, which is denoted in the rule identifier field110in the data packet102. The rule identifier field110may be part of the SCHC header, as described above.

In an embodiment, the compression residue112within the data packet102and the SCHC header. The compression residue112may include the bits that could not be compressed in a dense concatenated form. These bits are encoded after the rule identifier field110of the data packet102and SCHC header, as illustrated inFIG.1. In an embodiment, since the newly defined rule indicates that the SCHC-compressed address is found in the 6LoRH of the data packet102, the compression residue112does not need to be used for decompression of SCHC information from the data packet102. Instead, the destination IP address encoded in the SRH-6LoRH may be used to decompress the SCHC information from the data packet102according to this rule. This may reduce the amount of compression residue112that needs to be included in the data packet102and transported along the network route.

In an embodiment, once the data packet102has been generated, the root node may transmit the data packet102to the next hop as indicated in the SRH-6LoRH. The network addresses in the SRH-6LoRH may be provided in order such that the first address in the SRH-6LoRH corresponds to the destination node (e.g., the destination network address) with each subsequent address corresponding to the preceding network node or hop that is to be transited in order to reach the destination network node. In an embodiment, as the data packet102is transited through these intermediate network nodes, each corresponding network address in the SRH-6LoRH is consumed and removed from the data packet102. Accordingly, when the data packet102arrives at the last SRH-6LoRH entry (e.g., the destination network address), the only network address remaining in the SRH-6LoRH is the destination network address of the destination network node.

When the data packet102arrives at the destination network node corresponding to the last SRH-6LoRH entry in the data packet102, the destination network node may evaluate the rule corresponding to the rule identifier specified in the rule identifier field110. As noted above, the rule identifier field110may indicate a rule identifier corresponding to a new rule generated by the root node. This new rule may indicate that the destination IP address encoded in the SRH-6LoRH may be used to decompress the SCHC information from the data packet102. Accordingly, the destination network node may use the destination network address from the SRH-6LoRH to decompress the SCHC information from the data packet102. As the destination network node does not need to rely on the compression residue112to decompress the encoded SCHC information, the compression residue112(as illustrated inFIG.1) need not include any residue for the destination network address. This reduces the size of the compression residue112, thereby decreasing the overall size of the data packet102being transmitted to the destination network node through any intermediate hops.

FIG.2shows an illustrative example of an environment200in which a data packet102is encoded with a rule identifier based on information included in the SRH-6LoRH in the data packet in accordance with at least one embodiment. The data packet102may be similar to the data packet described above in connection withFIG.1. For instance, the data packet102may include the aforementioned dispatch value104, SRH-6LoRH header106, SCHC dispatch field108, and SCHC header, which may include the rule identifier field110and the compression residue112.

In the environment200, a SCHC compressor may, at step210, generate an appropriate rule that may be used for compression/decompression or for fragmentation/reassembly of SCHC information within a data packet. The rule may be assigned a corresponding rule identifier, which may be included in the rule identifier field110of the data packet102, as described above. This rule identifier may be transmitted through the data packet102as opposed to known field values. The new rule may match original packet values that may be known by both the root node and the destination node. Thus, based on the provided rule identifier, the destination node may use the rule identifier to obtain the corresponding rule and determine how to decompress the SCHC information encoded in the data packet102.

A rule (such as rules 202-1-202-N, illustrated inFIG.2) may include a list of field descriptors comprising a field identifier, a field length, a field position, a direction indicator, a target value, a matching operator, and a compression/decompression action. The field identifier may designate a protocol and field among all protocols that a SCHC compressor processes. If protocol nesting is present, the field identifier may further identify this nesting. The field position may indicate which occurrence the field descriptor applies to in the event that some fields occur multiple times in a packet header. The default value for the field descriptor may be “1” and may denote the first occurrence. The direction indicator may indicate the packet direction the field descriptor applies to (e.g., uplink, downlink, either uplink or downlink). The target value may be used to match against the packet header field. The target value can be a scalar value or a complex structure. The matching operator may be used to match the field value and the target value. The compression/decompression action may describe the pair of actions that are performed at the compressor to compress a header field and at the decompressor to recover the original value of the header field. A further description of these field descriptors and rules in the SCHC context is provided in IEEE Request for Comments (RFC) 8724, which is incorporated in its entirety into the present disclosure by reference.

In an embodiment, the SCHC compressor dynamically instantiates a rule based on information found in the 6LoRH of the data packet102, which may already compress network addresses in the network address header. Thus, the new rule instantiated by the SCHC compressor may indicate that the SCHC-compressed network address may be found in the 6LoRH of the data packet102as opposed to the compression residue112. At step220, the SCHC compressor may compress the different headers of the data packet102and obtain the rule identifier for the newly generated rule. For instance, the SCHC compressor may encode the dispatch value104to indicate the binary value corresponding to the Page 1 paging dispatch for 6LoWPAN compression and the use of the 6LoRH for carrying network address routing information. The SCHC compressor may further encode the SRH-6LoRH header106with the set of compressed network addresses corresponding to the different network nodes or hops according to the network route the data packet102is to traverse to reach a destination node. The SCHC compressor may further encode the SCHC dispatch field108, which may serve to indicate that the next fields in the data packet102include a SCHC header that comprises the rule identifier corresponding to the newly generated rule and a compression residue. As noted above, the SCHC dispatch field108may be encoded to indicate that the data packet102is using the 6LoRH for the SCHC-compressed address in the SRH-6LoRH header106.

As noted above, as the data packet102transits along the network route defined through the ordering of network addresses within the first field of the data packet102, the intermediate network nodes or hops may consume these network addresses until the only network address remaining is that of the destination node (e.g., the final recipient of the data packet102along the network route). The destination node, through a SCHC decompressor, may receive the data packet102and, at step230, check the rule identifier specified in the rule identifier field110of the data packet102.

Based on the rule identifier specified in the rule identifier field110, the SCHC decompressor, at step240, may obtain the corresponding rule and begin decompression of the SCHC information encoded in the data packet102. As noted above, the rule may indicate that the SCHC-compressed network address is encoded within the 6LoRH as opposed to the compression residue112of the data packet102. Accordingly, the SCHC decompressor may evaluate the SRH-6LoRH header106of the data packet102to obtain the destination network address and use this destination network address to decompress the SCHC information encoded in the data packet102. Since the SCHC information is decompressed using the destination network address indicated in the SRH-6LoRH header106, the compression residue112within the data packet102does not need to be used for decompression of the SCHC information.

It should be noted that while IPv6 network addresses and corresponding fields are used throughout the present disclosure for the purpose of illustration, other types of network addresses and corresponding fields may be used for the data packet102and for decompression of the SCHC information encoded in the data packet102. For instance, if the data packet102includes a Media Access Control (MAC) header, the SCHC-compressed address may be encoded in the interface identifier (IID) within the MAC header. For data packets including this MAC header, the data packets may encode and compress the MAC addresses corresponding to the different network nodes along the network route.

FIG.3shows an illustrative example of a process300for generating a data packet that encodes a set of IP addresses within the SRH-6LoRH and a rule identifier corresponding a new rule indicating a SCHC-compressed address that is included in the 6LoRH in accordance with at least one embodiment. The process300may be performed by a SCHC compressor, which may generate data packets that encode network addresses corresponding to the different network nodes or hops along a network route, rule identifiers corresponding any applicable rules for decompressing the SCHC information encoded in the data packets, and compression residues. As noted above, while IPv6 addresses are uses extensively throughout the present disclosure, the SCHC compressor may generate data packets that include a MAC header that encodes the different MAC addresses corresponding to the different network nodes or hops along a network route.

At step302, the SCHC compressor may compress the network addresses (e.g., IPv6 addresses, MAC addresses, etc.) corresponding to the network nodes or hops along a network route within the SRH-6LoRH header or MAC header (depending on the type of network address) of the data packet. As noted above, the SRH-6LoRH header of the data packet may be a Type 1 SRH-6LoRH header, where IPv6 network addresses are compressed according to the IEEE 802.15.4 short address format and where the corresponding network nodes each share a PAN identifier. If the network addresses of the different network nodes or hops are MAC addresses, the SCHC compressor may compress the network addresses within the IID of the MAC header.

At step304, the SCHC compressor may define a new rule indicating that the SCHC-compressed network address is included in the 6LoRH or the IID of the MAC header (depending on the type of network address) of the data packet. The new rule may indicate that the destination network address is the first address within the SRH-6LoRH or IID of the MAC header within the data packet. As noted above, the network addresses within the SRH-6LoRH or IID may be listed in order according to the network route defined for the data packet, with the first network address listed corresponding to the destination network node for the data packet. As the data packet passes through the different intermediate network nodes or hops along the network route, each intermediate node may consume or otherwise snip its corresponding network address from the SRH-6LoRH or IID of the data packet. Thus, when the data packet is received at the destination network node, the remaining network address indicated in the SRH-6LoRH or IID may correspond to the destination network node.

At step306, the SCHC compressor may encode the data packet with a rule identifier corresponding to the newly generated rule and with the set of compressed network addresses. For instance, referring toFIG.1, the SCHC compressor may encode the rule identifier corresponding to this new rule into the rule identifier field110of the data packet. As noted above, the rule identifier field may be a part of the SCHC header, which includes both the rule identifier field and the compression residue. The SCHC compressor may encode the SCHC dispatch field108of the data packet, which may serve to indicate that the next fields in the data packet include a SCHC header that comprises the rule identifier corresponding to the newly generated rule and a compression residue. The SCHC dispatch field108may be encoded to indicate that the data packet is using the 6LoRH for the SCHC-compressed address in the SRH-6LoRH header.

The SCHC compressor may further encode the data packet to include a dispatch value corresponding to the Page 1 paging dispatch for 6LoWPAN compression and the use of the 6LoRH for carrying network address routing information. The SCHC compressor may further encode the SRH-6LoRH header with the set of compressed network addresses corresponding to the different network nodes or hops according to the network route the data packet is to traverse to reach a destination node.

At step308, the SCHC compressor, through the root node associated with the network route, may transmit the data packet to the destination network node along the defined network route. For instance, the root node may evaluate the SRH-6LoRH header of the data packet to identify the next hop for the data packet. Prior to transmitting the data packet to the identified next hop, the root node may consume or snip its network address from the SRH-6LoRH header. Each intermediate network node or hop may perform similar operations, consuming or snipping their corresponding network addresses from the SRH-6LoRH header until the data packet is received at the destination network node. The destination network node may correspond to the last entry in the SRH-6LoRH header.

FIG.4shows an illustrative example of a process400for using a network address indicated in the last 6LoRH or IID entry in the data packet to decompress SCHC information encoded in the data packet in accordance with at least one embodiment. The process400may be performed by any network node or hop along a network route, including a destination node that may be associated with a SCHC decompressor. The SCHC decompressor may decompress the SCHC information encoded in any received data packets according to any applicable rules indicated through a rule identifier field in these data packets. As noted above, the rules corresponding to the rule identifiers specified in these data packets may indicate that the SCHC-compressed network address is to be found in the 6LoRH or the IID of the MAC header in these data packets as opposed to the compression residue.

At step402, a network node along a network route may receive a data packet that encodes a set of network addresses in the SRH-6LoRH header or MAC header of the data packet. As noted above, the SRH-6LoRH header or MAC header includes a set of compressed network addresses (e.g., IPv6 addresses or MAC addresses for SRH-6LoRH or MAC headers, respectively) corresponding to the different network nodes or hops according to the network route the data packet is to traverse to reach a destination node. If the network addresses are compressed in a SRH-6LoRH header, the SRH-6LoRH may be implemented as a Type 1 SRH-6LoRH header, whereby the network addresses that are compressed into the data packet are derived from an IEEE 802.15.4 short address and for which the corresponding network nodes share a PAN identifier. A SRH-6LoRH header may further indicate the number of different network nodes or hops that the data packet is to traverse, including the root and destination nodes, as described above. Alternatively, if the network addresses are MAC addresses corresponding to the different network nodes or hops along the network route, the compressed network addresses may be encoded in the IID of the MAC header within the data packet.

At step404, the network node along the network route may determine whether the data packet has been received at the network corresponding to the last 6LoRH or IID entry in the data packet. As noted above, the network addresses in the SRH-6LoRH or MAC header may be provided in order such that the first address in the SRH-6LoRH or MAC header corresponds to the destination node (e.g., the destination network address) with each subsequent address corresponding to the preceding network node or hop that is to be transited in order to reach the destination network node. As the data packet is transited through these intermediate network nodes, each corresponding network address in the SRH-6LoRH or MAC header is consumed and removed from the data packet. Accordingly, when the data packet arrives at the last SRH-6LoRH or MAC header entry (e.g., the destination network address), the only network address remaining in the SRH-6LoRH or MAC header is the destination network address of the destination network node.

If the 6LoRH or IID within the data packet includes more than one compressed network address, this may serve as an indication that the data packet has not been received by the destination node. Accordingly, the network node, at step406, may snip the IPV6 or MAC address corresponding to the network node from the first field of the data packet. This may ensure that the remaining network addresses in the 6LoRH or IID within the data packet correspond to the next network nodes or hops along the network route, including the destination node. Once the network node has snipped its network address from the 6LoRH or IID, the network node, at step408, may transmit the data packet to the next network node or hop along the network route, as indicated through the 6LoRH or IID.

If the 6LoRH or IID within the data packet includes a single compressed network address, the network node may determine that it is the destination node for the data packet. Accordingly, the network node, through the SCHC decompressor, may evaluate the rule identifier field of the data packet to obtain the rule identifier specified in data packet. Based on the rule identifier indicated in the data packet, the SCHC decompressor may obtain the corresponding rule and, at step410, begin decompression of the SCHC information encoded in the data packet. As noted above, the rule may indicate that the SCHC-compressed network address is encoded within the 6LoRH or IID of the MAC header as opposed to the compression residue of the data packet. Accordingly, the SCHC decompressor may evaluate the SRH-6LoRH header or MAC header of the data packet to obtain the destination network address and use this destination network address to decompress the SCHC information encoded in the data packet. Since the SCHC information is decompressed using the destination network address indicated in the SRH-6LoRH header or MAC header, the compression residue within the data packet does not need to be used for decompression of the SCHC information.

FIG.5illustrates an example network device500suitable for performing switching, routing, and other networking operations in accordance with some implementations. Network device500includes a CPU504, interfaces502, and a connection510(e.g., a Peripheral Component Interconnect (PCI) bus). When acting under the control of appropriate software or firmware, the CPU504is responsible for executing packet management, error detection, and/or routing functions. The CPU504can accomplish these functions under the control of software including an operating system and any appropriate applications software. The CPU504may include one or more processors508, such as a processor from the Intel® X98 family of microprocessors. In some cases, the processor508can be specially designed hardware for controlling the operations of network device500. In some cases, a memory506(e.g., non-volatile RAM, ROM, etc.) also forms part of the CPU504. However, there are many different ways in which memory could be coupled to the system.

Although the system shown inFIG.5is one specific network device of the present technologies, it is by no means the only network device architecture on which the present technologies can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc., is often used. Further, other types of interfaces and media could also be used with the network device500.

The network device500can also include an application-specific integrated circuit (ASIC)512, which can be configured to perform routing and/or switching operations. The ASIC512can communicate with other components in the network device500via the connection510, to exchange data and signals and coordinate various types of operations by the network device500, such as routing, switching, and/or data storage operations, for example.

FIG.6illustrates a computing system architecture600including various components in electrical communication with each other using a connection606, such as a bus, in accordance with some implementations. Example system architecture600includes a processing unit (CPU or processor)604and a system connection606that couples various system components including the system memory620, such as ROM618and RAM616, to the processor604. The system architecture600can include a cache602of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor604. The system architecture600can copy data from the memory620and/or the storage device608to the cache602for quick access by the processor604. In this way, the cache can provide a performance boost that avoids processor604delays while waiting for data. These and other modules can control or be configured to control the processor604to perform various actions.

Other system memory620may be available for use as well. The memory620can include multiple different types of memory with different performance characteristics. The processor604can include any general purpose processor and a hardware or software service, such as service 1610, service 2612, and service 3614stored in storage device608, configured to control the processor604as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor604may be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

Storage device608is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, RAMs616, ROM618, and hybrids thereof.

The storage device608can include services610,612,614for controlling the processor604. Other hardware or software modules are contemplated. The storage device608can be connected to the system connection606. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor604, connection606, output device624, and so forth, to carry out the function.