Cross-layer forwarding in a Low-power and Lossy Network

In accordance with techniques presented herein, a packet is received at a forwarding device operating in a multi-service Low-power and Lossy Network (LLN). The forwarding device is configured to retrieve service requirements associated with the packet and obtain forwarding information from a plurality of networking layers associated with forwarding of the packet. The forwarding device is further configured to evaluate the service requirements in view of the forwarding information to dynamically adjust one or more parameters within the LLN for use in forwarding packets within the LLN.

TECHNICAL FIELD

The present disclosure relates to packet forwarding in a Low-power and Lossy network.

BACKGROUND

Low-power and Lossy Networks (LLNs) communicate using low data rate links, such as Radio-Frequency (RF) links defined by the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard or Power Line Communication (PLC) links defined by the IEEE P1901.2 standard. LLNs experience a number of issues that may make communication between nodes challenging. For example, the radio or physical links within LLNs are strongly affected by environmental conditions that change over time. These changes may include temporal changes in interference (e.g., other wireless networks or electrical appliances), physical obstruction (e.g. doors opening/closing or seasonal changes in foliage density of trees), and propagation characteristics of the physical media (e.g. temperature or humidity changes). The time scales of such temporal changes can range between milliseconds (e.g. transmissions from other transceivers) to months (e.g. seasonal changes of outdoor environment).

Other issues result from the use of low-cost and low-power designs that the limit the capabilities of the LLN transceivers. In particular, LLN transceivers typically provide low throughput and typically support limited link margin, making the effects of interference and environmental changes visible to link and network protocols. Interference may be from external sources (non-network devices generating electromagnetic interference) or internal sources (other network devices communicating within the same frequency band).

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

In accordance with techniques presented herein, a packet is received at a forwarding device operating in a multi-service Low-power and Lossy Network (LLN). The forwarding device is configured to retrieve service requirements (e.g., quality-of-service (QoS) requirements, delays, packet delivery rate, etc.) associated with the packet and obtain forwarding information from a plurality of networking layers associated with forwarding of the packet. The forwarding device is further configured to evaluate the service requirements in view of the forwarding information at multiple layers to dynamically adjust one or more parameters within the LLN for forwarding packets within the LLN. In one example, the forwarding device the adjustment of the one or more parameters comprises selection of one or more LLN forwarding mechanisms for use in forwarding the packet towards the destination device.

Example Embodiments

LLNs may be used for a wide variety of purposes including, but not limited to, industrial monitoring, building automation (e.g., lighting, security/access control, fire, heating, ventilation, and air conditioning (HVAC)), connected homes, healthcare, environmental monitoring, urban sensor or utility systems (e.g., Smart Grid), utility distribution control, asset tracking, etc. In certain examples, an LLN (or a portion thereof) may be a multi-service LLN. A multi-service LLN is a network or network segment that is shared by multiple applications.

FIG. 1is a block diagram illustrating an example multi-service LLN10that is used by a utility provider and that is configured to perform cross-layer forwarding techniques described herein. In the example ofFIG. 1, the LLN10is shared by a monitoring application (e.g., to read meters at business, homes, etc.) and a distribution control application (e.g., for closed loop control of a distribution grid). It is to be appreciated that the utility deployment ofFIG. 1is merely illustrative and other deployments are possible.

The LLN10comprises a utility control center30, at least one Field Area Router (FAR)40, and a plurality of devices60(1)-60(N). The devices60(1)-60(N) are interconnected with one another so as to form a “mesh” of devices that is referred to herein as mesh network70. The devices60(1)-60(N) within the mesh network are also referred to herein as mesh devices60(1)-60(N).

In the utility network deployment ofFIG. 1, the mesh devices60(1)-60(N) are primarily meter devices (i.e., devices at homes or business that record utility usage). However, one or more of the mesh devices60(1)-60(N) may alternatively be switches, relays, range extenders, distribution automation devices, and/or other devices that are remotely controlled by a management server20that, in this example, is in the utility control center30.

In certain circumstances, the mesh devices60(1)-60(N) and FAR40may operate as forwarding devices. That is, the mesh devices60(1)-60(N) and FAR40may operate as intermediate networking nodes that receive data packets (traffic) transmitted by a source device to a destination device. Upon receiving a packet, a mesh device60(1)-60(N) and/or the FAR40forwards a received packet towards the destination device.

The mesh devices60(1)-60(N) may communicate with each other and the FAR40according to the IEEE 802.15.4 communication standard. The FAR40communicates with the management server20by way of the network80and provides wide area network (WAN) connectivity for the mesh devices60(1)-60(N) in the LLN10. There may be multiple FARs in a given LLN and a single FAR40is shown merely for ease of illustration.

In general, an LLN may experience a number of issues that may make communication between LLN nodes challenging. For example, the communication links between LLN nodes may be affected by changing environmental conditions, interference (e.g., from wireless networks or electrical appliances), physical obstructions (e.g. doors opening/closing or seasonal changes in foliage density of trees), and propagation characteristics of the physical media (e.g. temperature or humidity changes). As such, links between neighboring LLN nodes may be reliable at some points in time, but unreliable at other points in time.

Due to the dynamic nature of LLN links, forwarding mechanisms have been developed for packet forwarding in an LLN. These LLN forwarding mechanisms include, by way of example, multi-path forwarding techniques, dynamic selection of a multicast method based on the amount of state a device must store, and dynamic use of localized 1+1 protection upon detection of a weak or failed link.

As noted above, LLN10is a multi-service LLN shared by a plurality of applications that may have a number of different service requirements. For example, a meter reading application supported by the LLN10may have relaxed latency and reliability requirements (i.e., high latency and low reliability is acceptable within the meter reading application). However, a distribution automation application supported by the LLN10may have stringent latency and reliability requirements (i.e., low latency and high reliability are required within the distribution automation application). The above conventional arrangements do not use cross-layer information to dynamically employ the use of lower-layer optimizations on a per-packet basis and, as such, do not have the ability to efficiently use the LLN resources to support multiple applications while satisfying the varying service requirements of the applications. As such, proposed herein are cross-layer forwarding techniques that utilize cross-layer information to dynamically select one or more LLN forwarding mechanisms for use in forwarding packets through an LLN, such as LLN10. The LLN forwarding mechanisms may be selected on a per-packet basis to ensure that the service requirements of different applications are met in a manner that efficiently uses the LLN resources.

More specifically, in accordance with the cross-layer forwarding techniques presented herein, a forwarding device obtains information about a packet from a plurality of layers of the networking stack (e.g., latency/reliability requirements, packet delivery rate, etc. from the application layer, routing topology information, path reliability/latency from the network layer, etc.). Using the collected information, the forwarding device can dynamically adjust one or more parameters within the LLN used to forward packets. In one example, the adjustment of one or more parameters comprises selection of one or more LLN forwarding mechanisms (optimizations) (e.g., multi-path forwarding techniques, changes to a link-layer retransmission threshold, changes to a timer, etc.). The adjustment of the one or more parameters may also comprise dynamically preempting existing traffic to grant a higher priority at the Media Access Control (MAC) layer for use in forwarding received packets. The one or more parameter adjustments may be based on whether the adjustments allow the forwarding device to satisfy the service requirements associated with a packet/application and the associated resource costs (i.e., how costly, in terms of network resources, the mechanism may be to implement). In general, adjustments (e.g., LLN forwarding mechanisms) that are the least costly, but that satisfy the QoS requirements are selected. In certain embodiments, the forwarding device is configured to mark packets in a manner that records the adjustments used to forward the packet (e.g., reducing each packet's reliability requirement after copying a packet for multi-path forwarding). In summary, the cross-layer forwarding techniques provide a method that utilizes information across the network stack (link to application layers) to dynamically employ the use of mesh networking optimizations on a per-packet basis.

As shown inFIG. 1, the mesh devices60(1)-60(N) and the FAR40each include a cross-layer forwarding module90that is configured to implement the cross-layer forwarding techniques presented herein. The cross-layer forwarding modules90may be implemented in hardware and/or software, and may have varying degrees of functionality depending, for example, on the type of device, location in the LLN10, etc. For example, in certain embodiments the cross-layer forwarding module90at FAR40may have more functionality than a cross-layer forwarding module in a range extender within the mesh network70Likewise, the cross-layer forwarding module within the range extender may have more functionality than a metering device within the mesh network70.

Reference is now made toFIG. 2.FIG. 2is a schematic diagram illustrating further details of cross-layer forwarding techniques executed at a range extender100that is part of a mesh network105. As shown, the mesh network105comprises a plurality of other mesh devices110(1)-110(13) that may be, for example, meter devices, other range extenders, distribution automation devices, etc. Connected to the mesh network105is a FAR115. The mesh network105and the FAR115, along with a second network (not shown inFIG. 2) and other components (also not shown inFIG. 2) may collectively form an LLN120.

It is to be appreciated thatFIG. 2illustrates a specific example of the arrangement ofFIG. 1. That is, the range extender100is a specific instance of a mesh device60(1)-60(N) and the cross-layer forwarding module130corresponds to the cross-layer forwarding modules90ofFIG. 1. Similarly, the FAR115inFIG. 2corresponds to FAR40ofFIG. 1.

In the example ofFIG. 2, a mesh device110(1) transmits a packet125to a destination device (not shown). The mesh device110(1) is, in this example, a meter device and the packet125may be transmitted to a management server in a utility control center (e.g., as depicted inFIG. 1). It is to be appreciated that, in certain examples a device such as mesh device110(1) may transmit a plurality of packets to a destination device. As such, it is to be appreciated that the use of a single packet125inFIG. 2is merely for ease of illustration.

Returning to the example ofFIG. 2, the packet125transmitted by mesh device110(1) is first received by range extender100. Range extender100includes a cross-layer forwarding module130that is configured to forward the packet125towards the destination device using the cross-layer forwarding techniques presented herein. The cross-layer forwarding module130may be implemented in hardware, software, or a combination of hardware/software.

After receiving the packet125, the cross-layer forwarding module130identifies the application associated with the packet (e.g., the meter reading application, distribution automation application, etc.) That is, the cross-layer forwarding module130determines what application supported by the LLN120has transmitted the packet125. In certain examples, the cross-layer forwarding module130identifies the application associated with the packet125based on information contained in the packet (e.g., an identified traffic class, option header, etc.)

Once the application associated with the packet is identified, the cross-layer forwarding module130retrieves the service requirements (e.g., reliability/latency requirements, packet delivery rate requirements, etc.) for the application associated with the packet. In certain circumstances, the service requirements for each application may be recorded locally (i.e., within memory) on the range extender100. In other circumstances, a message (e.g., a Constrained Application Protocol (CoAP) message) may be defined that enables the range extender100to retrieve the associated packet from a management server or other data repository in the LLN120. In another example, the actual service requirements for the application may be identified in the packet header (e.g., the service requirements may be inserted in the packet in the form of additional hop-by-hop Internet Protocol version 6 (IPv6) headers).

In one specific example ofFIG. 2, the packet125is an IPv6 packet that includes a traffic class identifier in the header that is used to distinguish packets associated with different applications. That is, each application supported by the LLN120is assigned a specific traffic class identifier that may be carried in the IPv6 packets. The cross-layer forwarding module130, upon receiving the packet125, uses the traffic class identifier to identify the application associated with the packet. The cross-layer forwarding module130may then use one of the above or other methods to determine the service requirements for the application and hence for the packet.

The service requirements may, in certain circumstances, specific absolute values (e.g., a total latency (delay) for application A at 5 seconds, delivery reliability for application B of 90%, etc.). In another example, the service requirements may be in a more general form (e.g., a flag that indicates that the application requires high, medium, or low reliability or latency). It is to be appreciated that these are merely examples and that the service requirements for an application may vary and take a number of other forms as well.

As is well-known, the Open System Interconnection (OSI) model abstractly defines a networking framework to implement protocols in seven layers.FIG. 2includes a schematic representation150of the OSI model and the seven networking layers that include the application layer155, the presentation layer160, the session layer165, the transport layer170, the network layer175, the data link layer180, and the physical layer185. In operation, control is passed from one layer to the next, starting at the application layer155in one device, and proceeding to the bottom layer, over the channel to the next device and back up the hierarchy of layers.

In essence, the above retrieval of the service requirements results in the identification of application layer information associated with the forwarding of the packet125. In addition to this application layer information, the cross-layer forwarding module130is further configured to obtain forwarding information from a plurality of other networking layers associated with forwarding of the packet125(i.e., other layers of the OSI model). For example, the cross-layer forwarding module130may obtain forwarding information from the network layer175that identifies the expected latency and/or reliability for reaching the packet's destination. Additionally, the cross-layer forwarding module130may obtain information from the data link layer180about the expected latency and/or reliability of reaching the packet's next-hop destination. The retrieval of forwarding information from a plurality of networking layers associated with forwarding of the packet125is schematically shown inFIG. 2by arrows190.

In one specific example, a routing protocol of the network layer175can provide information about the reliability along various paths through LLN120and/or latency toward a destination along those paths. As such, the network layer information may be obtained from the routing protocol itself or, alternatively, could be obtained by actively sending probe packets through the LLN120and receiving subsequent probe responses.

At the data link layer180, it is standard that an acknowledgement message is received at a device that transmits a packet. The acknowledgement message is transmitted by the next hop (i.e., the next forwarding device in the LLN12). As such, in certain examples the cross-layer forwarding module130(or other component) tracks the acknowledgement messages for subsequent use in determining the link conditions. The resulting information may be, for example, the expected number of transmissions needed before receiving an acknowledgement message. This information provides an indication of reliability and latency.

At the transport layer170, the transport protocol (e.g., Transmission Control Protocol (TCP)) header may include information about, for example, what packets have been dropped. The cross-layer forwarding module130may examine the transport protocol header and maintain statistics about the reliability of various paths or latencies along those paths. As such, instead of just using the routing protocol to forward the packet, the cross-layer forwarding module130may additionally or alternatively monitor flows based on information from the transport layer170or the application layer.

In one example, the cross-layer forwarding module130could use application layer information to monitor the packet QoS requirements. Indeed, some application layers may encode the expected QoS, or may indicate that the packet has been retransmitted (that information may not be available at the transport layer if one uses UDP). If the application layer indicates that the packet is retransmitted this may influence the forwarding decision.

After obtaining forwarding information from the plurality of networking layers, the cross-layer forwarding module130evaluates the service requirements for the packet125(i.e., defined for the underlying application) in view of the other forwarding information to dynamically adjust one or more parameters within the LLN used to forward packets. This may include, for example, selection at the link layer of PHY parameters (e.g., modulation, data rate, tone map, etc. that trade data rate vs. robustness), selection at the link layer of MAC parameters (e.g., backoff window, clear-channel assessment, etc. that trade congestion avoidance vs. latency), packet re-ordering at the network layer to service latency-critical packets first, etc.

In one example, the adjustment of one or more parameters comprises selection of one or more LLN forwarding mechanisms (optimizations) (e.g., multi-path forwarding techniques, changes to a link-layer retransmission threshold, selection of a different path, changes to a timer, etc.). The adjustment of the one or more parameters may also comprise dynamically preempting existing traffic to grant a higher priority at the MAC layer for use in forwarding received packets. It is to be that the various parameter adjustments listed above are merely illustrative and other adjustments are possible.

In certain circumstances, the networking layer parameters are adjusted in isolation based on the properties of packet125(i.e., network layer decisions are made independent of the link layer). However, in other embodiments the cross-layer forwarding module130considers information from a plurality of networking layers to adjust one or more LLN parameters. It is to be appreciated that the cross-layer forwarding module130may evaluate the service requirements in view of forwarding information from a plurality of other layers in a number of different manners based on the network topology and number of available parameter adjustments. For example, the cross-layer forwarding module130may use the forwarding information to generate reliability and/or latency estimates for all or a selected number of different parameter adjustments or combinations of parameter adjustments. Using statistical approaches, the cross-layer forwarding module130may determine and select the parameter adjustments that enable the forwarding device to satisfy the service requirements for packet125with the lowest cost (i.e., the parameter adjustment(s) that place the least load on LLN infrastructure). As such, in certain examples, cost metrics may be computed for the all or a selected number of different parameter adjustment(s) or combinations of parameter adjustment(s). Cost metrics may take into account, for example, how many transmissions it takes to successfully transmit a packet, the number of paths used, etc.

In certain examples, a subset of parameter adjustment(s) (or combinations of parameter adjustment(s)) may be known or previously determined to typically satisfy certain service requirements with the lowest costs. In such examples, this subset may be the only parameter adjustment(s) that are evaluated during the evaluation process. In this way, the evaluation space may be greatly reduced (e.g., evaluate five predetermined combinations instead of hundreds or thousands of combinations).

In one specific example, when forwarding packet125, the cross-layer forwarding module130may determine the high-throughput metric (ETX) for a path and expected latency for delivering a packet to its destination along the path. The ETX for the path provides information on the path's reliability. If that reliability is above the packet's requirements, then the cross-layer forwarding module130may forward the packet without using any additional parameter adjustment(s). However, if the reliability is below the packet's reliability threshold, then the cross-layer forwarding module130will evaluate whether to use other parameter adjustment(s) (e.g., backtracking, multi-path forwarding, etc.). Combining reliability and communication latency, the cross-layer forwarding module130can determine the expected latency of delivering a packet along a single path vs. multiple paths.

After selection of the one or more parameter adjustment(s), the cross-layer forwarding module130forwards the packet125towards the destination device using those selected parameter adjustment(s). In certain examples, the cross-layer forwarding module130may mark the packet125upon exit to indicate which parameter adjustment(s) where used to forward the packet.

More specifically, when the packet125first enters the LLN120, it may be unmarked and initialized based on traditional techniques (e.g., Traffic Class markings, Deep Packet Inspection, etc.). However, after one or more parameter adjustment(s) have been used, the packet125should provide information about what strategies so that forwarding devices further down the path can take those decisions into account. For example, once a forwarding device selects multi-path forwarding, it may choose to reduce the reliability requirement for each copy of the packet. In other words, the forwarding device may utilize a single path with an increased link-layer retransmission threshold or multiple paths with a decreased link-layer retransmission threshold. If a packet is being transmitted along multiple paths, each path need not employ as much in the way of reliability techniques to ensure packet delivery.

In certain examples, the cross-layer forwarding techniques may include a feedback loop that enables cross-layer forwarding module130to learn about the parameter adjustment(s) that it selected and determine if those adjustments where successful in satisfying the requirements for packet125. In such examples, upon receiving a packet forwarded from cross-layer forwarding module130, the destination device may send feedback packets back to the various forwarding devices in the successful path, along with a copy of the packet and an indication on the actual QoS that was achieved.

In one example, a set of X packets with similar multi-layer profiles (same application, Differentiated services code point (DSCP), etc.) received with long delays may trigger the transmission of feedback packets back to the forwarding devices along the path in order for those forwarding devices to adapt their multi-layer routing strategies (a copy of the packet is also provided or a subset of the IPv6 header). As a result, the forwarding devices along the path may subsequently decide to favor links with lower latency or a higher path ETX (in order to get lower retransmission).

FIG. 2has been described with reference to execution of the cross-layer forwarding techniques at range extender100. It is to be appreciated that the cross-layer forwarding techniques may be executed at other devices (e.g., FAR115) in the LLN120. However, it is to be appreciated that not all forwarding devices employ the same parameter adjustment(s) (e.g., LLN forwarding mechanisms) or have the same information accessible to them. For example, a RPL Root/Border Router (i.e. Connected Grid Router) may have much more information about the routing topology (i.e. in non-storing mode) and obtain additional information through Data Access Object (DAO) messages. In this case, the RPL Root may have the ability to employ multi-path forwarding by utilizing different source routes towards a destination. However, other RPL devices may only be able to optimize their link-layer parameters based on the packet's reliability and latency requirements.

FIG. 3illustrates a block diagram of a FAR240according to one example presented herein, and which is configured to perform the techniques presented herein (corresponding to FAR40inFIG. 1and FAR115inFIG. 2). The FAR240is a device that is configured to communicate with a mesh network and to communicate over a WAN connection on behalf of the devices in the mesh network for data/control purposes. To this end, the FAR240comprises a radio transceiver242, at least one antenna243, a modem244, a WAN interface unit246, a controller248and a memory250.

The WAN interface unit246may be a wired network interface unit (e.g., an Ethernet card) or a wireless interface unit (e.g., cellular or WiMAX™ interface wireless interface unit). In one example, the radio transceiver22and modem244comprise one or more integrated circuit chips that are configured to perform wireless communication in accordance with the IEEE 802.15.4 wireless personal area network (WPAN) communication protocol to communicate with wireless devices in the mesh network. The radio transceiver242and modem244may be considered parts of a wireless transceiver unit245. The WAN interface unit246enables WAN communications so that the FAR240can communicate with servers or other devices reachable over a LAN or WAN. The controller248is a data processor, e.g., a microprocessor or microcontroller that is configured to execute software instructions stored in memory250. In the case in which the LLN is a wired network, then the wireless transceiver unit245is a transceiver unit comprising a transceiver242and a modem244that are configured for wired communication over a wired (copper or optical) network media.

The memory250may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. The memory250stores computer executable software instructions for cross-layer forwarding logic220. The cross-layer forwarding logic220comprises software instructions that cause the controller248to perform cross-layer forwarding operations (e.g., operations of cross-layer forwarding module130ofFIG. 2). Thus, in general, the memory250may comprise one or more tangible computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the controller248) it is operable to perform the operations described herein in connection with cross-layer forwarding logic220.

Reference is now made toFIG. 4for a description of an example of a block diagram of a mesh device (e.g., that can serve as any of the mesh devices referred to above in connection withFIGS. 1 and 2), generically referred to at reference numeral260that is configured to perform cross-layer forwarding operations. The mesh device260comprises a radio transceiver262, at least one antenna263, a modem264, a controller266and a memory267. In one example, the radio transceiver262and modem264comprise one or more integrated circuit chips that are configured to perform wireless communication in accordance with the IEEE 802.15.4 WPAN communication protocol to communicate with other mesh devices in a mesh network and with a FAR.

The radio transceiver262and modem264may be considered parts of a wireless transceiver unit265. The controller266is a data processor, e.g., a microprocessor or microcontroller that is configured to execute software instructions stored in memory268. In the case in which the LLN is a wired network, then the wireless transceiver unit265is a transceiver unit comprising a transceiver262and a modem264that are configured for wired communication over a wired (copper or optical) network media.

The memory268may comprise ROM, RAM, magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. The memory268stores computer executable software instructions for cross-layer forwarding logic222. The cross-layer forwarding logic222comprises software instructions that cause the controller266to perform cross-layer forwarding operations (e.g., operations of cross-layer forwarding module130ofFIG. 2). Thus, in general, the memory268may comprise one or more tangible computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the controller266) it is operable to perform the operations described herein in connection with cross-layer forwarding logic222.

FIG. 5is a flowchart of a method300in accordance with examples presented herein. Method300begins at305where a packet is received at a forwarding device operating in a multi-service LLN. At310, the forwarding device retrieves service requirements associated with the packet and at315the forwarding device obtains forwarding information from a plurality of networking layers associated with forwarding of the packet. At320, the forwarding device evaluates the service requirements in view of the forwarding information to dynamically adjust one or more parameters for forwarding packets within the LLN. At325, the forwarding device forwards the packet using the one or more adjusted parameters. In certain examples, prior to forwarding, the packet is marked with an indication of the adjusted parameters used to forward the packet.

While the techniques presented herein are described in connection with a wireless LLN (e.g., a wireless mesh network), this is only an example and not meant to be limiting. LLNs are not necessarily constrained to wireless networks and can also apply to wired environments. For example, Power Line Communication (PLC) technology is a wired connectivity technology that exhibits many of the same characteristics as wireless mesh networks (relatively high loss rates compared to traditional link technologies used in IP networks, time-varying link qualities and interference, and a communication medium that is not a single broadcast domain, etc.). In general, an LLN refers to any network that communicates over links that exhibit higher loss rates than a typical Ethernet-based network and connectivity is not well-defined by physical connections. Thus, the techniques described herein are applicable to wireless and wired LLN environments.

The cross-layer forwarding techniques presented herein allow a much more dynamic approach to dealing with varying traffic profiles and network characteristics within an LLN. By taking a cross-layer approach in optimizing packet delivery, the network can make the proper tradeoffs on a per-packet basis. When using both application and network layer information when forwarding a packet, these techniques minimize networking overhead by ensuring that the proper techniques are employed only when needed.

The above description is intended by way of example only.