Patent Description:
Some network data flows are conveyed using tunneling protocols, which enable movement of end user data traffic from one network to another. Tunneling protocols can allow private network communications to be sent across a public network, such as the Internet, through a process called tunneling or encapsulation. Also, tunneling allows sending otherwise unsupported protocols across diverse networks, for example, conveying IPv6 over IPv4 or conveying non-IP protocols over IP. Another important use of tunneling is for services that are impractical or unsafe to be offered using only the underlying network services, such as providing a corporate network address to a remote user whose physical network address is not part of the corporate network.

Tunneling of network flows can frustrate efforts at applying the above-noted acceleration and optimization network functions. For example, tunneling that encapsulates TCP traffic can prevent use of TCP performance enhancing proxies (PEPs) to perform TCP spoofing of TCP <NUM>-way handshakes for establishing TCP connections and TCP ACK spoofing to improve performance of TCP windowing algorithms under high latency conditions. Although optimization of tunneled traffic flows has been provided by tunnel-specific handling and transport, as illustrated in <CIT>), substantial engineering resources have been required to modify and enhance the underlying transport infrastructure to support and optimize acceleration and optimization of each new and different tunneling protocol.

<CIT> discloses a satellite communication system which may be configured to establish multiple different tunnels between a first satellite modem and a second satellite modem in accordance with a protocol. The first satellite modem may receive a packet via a tunnel established in accordance with a different protocol, determine an endpoint identifier corresponding to the tunnel based on information from one or more headers included in the packet, identify one of the multiple different tunnels that corresponds to the tunnel, generate a corresponding packet omitting at least a portion of the information from the one or more headers and comprising at least a portion of data included in a payload of the packet and an information block comprising a tunnel index corresponding to the identified one of the multiple different tunnels, and transmit the corresponding packet to the second satellite modem via the identified one of the multiple different tunnels.

<CIT> discloses a node for a communications system that has a hardware accelerator supporting communications using any of a variety of different, UDP-based, tunnel protocols. A tunnel software application configures the hardware accelerator to operate for any of the supported tunnel protocols. The hardware accelerator works for any UDP-based, non-cryptographic tunnel protocol. The tunnel software application provides the hardware accelerator with particular instances of generic outbound and inbound profiles that define the header fields for particular tunnel protocols. The hardware accelerator uses those profiles respectively to encapsulate and decapsulate outbound and inbound packets. In this way, tunnel processing is accelerated without having to provide different hardware accelerators for different tunnel protocols.

The invention is defined in the dependent claims to which reference should now be made.

A method for facilitating data communication, in accord with a first aspect of the invention, includes receiving, at a first network node device, via a local network interface, a first tunnel data packet encapsulating a first payload according to a first tunneling protocol, a second tunnel data packet encapsulating a second payload according to the first tunneling protocol, and a third tunnel data packet encapsulating a third payload according to a second tunneling protocol that is different than the first tunneling protocol. In addition, the method includes identifying a first tunnel session associated with the first tunnel data packet and a second tunnel session associated with the third tunnel data packet that is different than the first tunnel session, and a third step involves generating and maintaining a first packet context for the first tunnel session based on at least the received first tunnel data packet, and a second packet context for the second tunnel session based on at least the received third tunnel data packet. The method further includes determining, based on at least the first packet context and the second tunnel data packet, that the second tunnel data packet is for the first tunnel session. The method also includes de-encapsulating the second payload from the second tunnel data packet in accordance with the first tunneling protocol, in response to the determination that the second tunnel data packet is for the first tunnel session, as well as de-encapsulating the third payload from the third tunnel data packet in accordance with the second tunneling protocol in response to the determination that the third tunnel data packet is for the second tunnel session. Furthermore, the method includes submitting the second payload and the third payload to a common acceleration and optimization processor of the first network node device.

A data communication network node device, in accord with a second aspect of this invention, includes a common acceleration and optimization processor, a local network interface, and an input data packet processor. The input data packet processor is configured to receive, via the local network interface, a first tunnel data packet encapsulating a first payload according to a first tunneling protocol, a second tunnel data packet encapsulating a second payload according to the first tunneling protocol, and a third tunnel data packet encapsulating a third payload according to a second tunneling protocol that is different than the first tunneling protocol, as well as identify a first tunnel session associated with the first tunnel data packet and a second tunnel session associated with the third tunnel data packet that is different than the first tunnel session. The input data packet processor is further configured to generate and maintain a first packet context for the first tunnel session based on at least the received first tunnel data packet, and a second packet context for the second tunnel session based on at least the received third tunnel data packet, and determine, based on at least the first packet context and the second tunnel data packet, that the second tunnel data packet is for the first tunnel session. In addition, the input data packet processor is configured to de-encapsulate the second payload from the second tunnel data packet in accordance with the first tunneling protocol in response to the determination that the second tunnel data packet is for the first tunnel session, and de-encapsulate the third payload from the third tunnel data packet in accordance with the second tunneling protocol in response to the determination that the third tunnel data packet is for the second tunnel session. The input data packet processor is also configured to submit the second payload and the third payload to the common acceleration and optimization processor.

In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings may be practiced without such details. In other instances, well known methods, procedures, components, and/or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

This disclosure presented improved techniques for accelerating and optimizing tunneled data flows, in which core acceleration and optimization processing of tunneled data flows is separated from tunneling protocol specific processing. These techniques enable providing acceleration and optimization for additional tunneling protocols more easily and seamlessly without any need to modify the underlying transport infrastructure. Additionally, these techniques better ensure that a complete or more complete range of acceleration and optimization functions are applied for each supported tunneling protocol. Additionally, these acceleration and optimization functions can be applied more universally to both tunneled and un-tunneled data flows.

In different implementations, end-users can communicate and/or exchange information via networks. In order to better illustrate some of the proposed implementations, one example of a data communication system is presented with reference to <FIG>. In this example, the data communication system <NUM> is implemented as a satellite data communication system providing data communication services between a first network node device <NUM> and a second network node device <NUM> via a GEO space satellite <NUM> (which may be more simply referred to as a "satellite"). It is understood that the techniques described herein may be applied to, and provide benefits for, other types of data communication systems, even if they do not involve communications via a space satellite or involve high latency links. In some examples, the first network node device <NUM> may be implemented as a very small aperture terminal (VSAT) and the second network node device <NUM> may be implemented as a satellite gateway operated by a network service provider and providing access to public network resources (such as the Internet) and/or private network resources. In some examples, both the first network node device <NUM> and the second network node device <NUM> may be implemented as VSATs communicating via a peer-to-peer satellite link.

In this example, the GEO space satellite <NUM> operates at approximately <NUM>,<NUM> above the surface of the Earth. At this distance, the speed of light becomes a significant factor, as it takes approximately <NUM> milliseconds (ms) for a radio signal to travel between a radio terminal on the Earth's surface and the GEO space satellite <NUM>, resulting in a round trip time (RTT) of approximately <NUM> between the first network node device <NUM> and the second network node device <NUM> via the satellite <NUM>, and an even greater RTT between network devices communicating via the satellite link (which may be referred to as a "backhaul link" or "backhaul connection") between the first network node device <NUM> and the second network node device <NUM> and one or more intervening networks. The TCP protocol is not well designed for operating across links with such high latency. For example, aspects such as TCP <NUM>-way handshaking used to establish TCP connections and TCP windowing algorithms operate poorly over high-latency links.

To address this and provide a more acceptable end-user quality of experience, the first network node device <NUM> includes a common acceleration and optimization processor <NUM> configured to provide various network acceleration and/or optimization functions. For example, some acceleration and optimization functions that may be provided for the end user data that is tunneled over one of the tunneling protocols as mentioned above can include, but are not limited to (<NUM>) traffic class prioritization using tunneling protocol header including DSCP marking and as well as headers of the tunneled packets; (<NUM>) TCP-specific PEP for tunneled TCP flows (for example, TCP handshake or ACK spoofing); (<NUM>) other PEP functions; (<NUM>) header compression for tunnel headers and/or other headers of the tunneled packet; (<NUM>) DNS prefetching and/or caching; (<NUM>) DHCP relay (for IPv4 and/or IPv6); (<NUM>) payload compression for tunneled flow data; (<NUM>) HTTP acceleration, such as prefetching and/or caching, for tunneled HTTP requests; and/or (<NUM>) output jitter reduction for jitter sensitive tunneled applications by using a jitter buffer. Some examples of performance enhancing proxy functions (for example, TCP spoofing) are described in <CIT><CIT><CIT><CIT><CIT><CIT> and <CIT>.

Referring again to <FIG>, in some implementations, end-users may access a data service (represented by a network device <NUM>) via another network device <NUM>. As an example, network device <NUM> may be a server or other end-user device with which network device <NUM> is exchanging data. In this example, network device <NUM> transmits a data packet 162a via a network <NUM> to a first tunnel endpoint device <NUM>. The first tunnel endpoint device <NUM> implements a tunnel session <NUM> (also referred to herein simply as "tunnel", and described in further detail below) according to a particular tunneling protocol with another second tunnel endpoint device <NUM> via the backhaul link between the first network node device <NUM> and the second network node device <NUM>.

As will be shown in greater detail further below, the first tunnel endpoint device <NUM> can encapsulate data packet 162a or a portion thereof according to a tunneling protocol-specific encoding within a tunnel data packet 164a and deliver the tunnel data packet 164a to the first network node device <NUM> via network <NUM>. A tunnel data packet may also be referred to as a "tunnel encapsulated data packet" or an "encapsulated data packet. " As a general matter, tunnel data packets can be understood to include a data payload carrying a user packet that is encapsulated by one or more tunneling protocol-specific portions. A few examples of some tunneling protocols that may be used include, but are not limited to (<NUM>) IPIP (Internet Protocol number <NUM>): IP in IPv4/IPv6 as described in RFC <NUM>; (<NUM>) SIT/IPv6 (Internet Protocol number <NUM>): IPv6 in IPv4/IPv6 as described in RFC <NUM>; (<NUM>) Teredo tunneling (UDP destination port <NUM>) as described in RFC <NUM>; (<NUM>) GRE (Internet Protocol number <NUM>): Generic Routing Encapsulation as described in RFC <NUM> and RFC <NUM>; (<NUM>) L2TP (Internet Protocol number <NUM>): Layer <NUM> Tunneling Protocol using UDP datagrams as described in RFC <NUM>; (<NUM>) VXLAN (UDP destination port <NUM>): Virtual Extensible Local Area Network as described in RFC <NUM>; (<NUM>) PPTP: Point to point tunneling protocol as described in RFC <NUM>; (<NUM>) GPRS Tunneling Protocol (GTP) for cellular backhaul; (<NUM>) Layer-<NUM><NUM>. 1Q and/or <NUM>. 1ad tunnels; (<NUM>) Multiprotocol Label Switching (MPLS) (EtherTypes 0x8847 and 0x8848); and/or (<NUM>) MPLS-in-IP (Internet Protocol number <NUM>): MPLS encapsulated in IP as described in RFC <NUM> and RFC <NUM>, as well as any future tunneling protocols designed by IETF or other standards bodies. For purposes of clarity, some more specific examples of tunnel data packets for some of the above tunneling protocols are illustrated and will be described with reference to <FIG>.

By application of various operations described herein, a payload encapsulated by the tunnel data packet 164a, and associated data, can be transmitted from the first network node device <NUM> to the second network node device <NUM> with a reduced amount of data and re-generated by the second network node device <NUM> to produce a corresponding tunnel data packet 166a, thereby accelerating communication between the network device <NUM> and the network device <NUM> through the tunnel <NUM>. It should be understood that in different implementations, the benefits of the disclosed implementations are also applicable to un-tunneled data communications. For example, <FIG> shows a network device <NUM> which transmits an un-tunneled data packet 119a via the network <NUM> to the first network node device <NUM> via the backhaul link with the second network node device <NUM> for delivery to a network device <NUM> as a data packet 159a. Acceleration and optimization functions offered by the common acceleration and optimization processor <NUM>, such as TCP PEP, may be applied for the data packets 119a and 159a.

For purposes of reference, additional detail regarding the first network node device <NUM> will now be provided. In the example of <FIG>, the first network node device <NUM> includes a local network interface <NUM>, a tunnel processor <NUM>, the common acceleration and optimization processor <NUM>, and a backhaul network interface <NUM>. Similarly, in some implementations, the second network node device <NUM> includes a local network interface <NUM>, a tunnel processor <NUM>, a common acceleration and optimization processor <NUM>, and a backhaul network interface <NUM>. For certain network data flows, the first network node device <NUM> and/or the second network node device <NUM> are configured to receive and transmit data via respective networks <NUM> and <NUM> in the form of tunnel data packets, such as the tunnel data packets 164a, 164b, 166a, and 166b shown in <FIG>.

As noted above, the first network node device <NUM> includes the local network interface <NUM>. In different implementations, the local network interface <NUM> is adapted to exchange data via the network <NUM> (which, in some implementations, may be referred to as a "local network"), which may be implemented as one or more wired and/or wireless networks. The first network node device <NUM> also includes the backhaul network interface <NUM>, which is configured to exchange data via the satellite <NUM>, such as via Ka-band and/or Ku-band radio frequency (RF) data communications. Furthermore, the tunnel processor <NUM> of the first network node device <NUM> is configured to, for multiple different tunneling protocols, identify associated tunnel data packets, and extract their encapsulated payloads for processing by the common acceleration and optimization processor <NUM>. Additionally, the tunnel processor <NUM> delivers un-tunneled data packets to the common acceleration and optimization processor <NUM>, allowing the acceleration and optimization features provided by the common acceleration and optimization processor <NUM> to be applied to both tunnel data packets and un-tunneled data packets.

Thus, it can be understood that some aspects of the first network node device <NUM> described herein can be adapted to share information with one another, thereby facilitating improvement of end-user quality of experience. Together, the tunnel processor <NUM> and the common acceleration and optimization processor <NUM> operate to substantially reduce the volume of, and costs for, traffic that is transferred via the satellite <NUM> while at the same time reducing apparent latency experienced by end-users of the first network node device <NUM>. The common acceleration and optimization processor <NUM> is configured to generate data for transmission via the backhaul network interface <NUM> based on data received from the tunnel processor <NUM>. In addition, the common acceleration and optimization processor <NUM> is configured to receive data from the backhaul network interface <NUM> and provide corresponding data to the tunneling processor <NUM> which in turn generates tunnel data packet(s) 164b that are output via the local network interface <NUM> and subsequently received by the first tunnel endpoint device <NUM>, which delivers corresponding data packets 162b to the network device <NUM>.

It should further be understood that some or all of the features and operations of the first network node device <NUM> described above can also be applicable to the second network node device <NUM>. Thus, in some implementations, data transmission arrangement on the `opposite' or corresponding side of the data communication system <NUM> can be substantially similar to that described above with respect to the end-user and network device <NUM>. In different implementations, a data service (represented by network device <NUM>) can communicate with end-users via a network <NUM>. In this example, network device <NUM> transmits a data packet 168b via a network <NUM> to a second tunnel endpoint device <NUM> to be conveyed via the tunnel <NUM>. The second tunnel endpoint device <NUM> can encapsulate data packet 168b or a portion thereof according to a tunneling protocol-specific encoding within a tunnel data packet 166b and deliver the tunnel data packet 166b to the second network node device <NUM> via network <NUM>. A payload encapsulated by tunnel data packet 166b, and associated data, can be transmitted to the first network node device <NUM> with a reduced amount of data and re-generated by the first network node device <NUM> to produce a corresponding tunnel data packet 164b, thereby accelerating communication between the network device <NUM> and the network device <NUM> through the tunnel <NUM>.

As noted above, the second network node device <NUM> includes local network interface <NUM>. In different implementations, the local network interface <NUM> is adapted to exchange data via local network <NUM>, which may be implemented as one or more wired and/or wireless networks. The second network node device <NUM> also includes the backhaul network interface <NUM>, which is configured to exchange data via the satellite <NUM>, such as via Ka-band and/or Ku-band RF data communications. Furthermore, as with the tunnel processor <NUM> of the first network node device <NUM>, the tunnel processor <NUM> of the second network node device <NUM> is configured to, for multiple different tunneling protocols, identify associated tunnel data packets, and extract their encapsulated payloads for processing by the common acceleration and optimization processor <NUM>, allowing the acceleration and optimization features provided by the common acceleration and optimization processor <NUM> to be applied to both tunnel data packets and un-tunneled data packets. It is noted that the benefits obtained by the tunnel processors <NUM> and <NUM> and the common acceleration and optimization processors <NUM> and <NUM> are obtained in part by interoperation of the tunnel processors <NUM> and <NUM> and interoperation of the common acceleration and optimization processors <NUM> and <NUM> of the two network node devices <NUM> and <NUM>, such as by use of common communication protocols to exchange tunnel- and packet-related information via the backhaul link between the first network node device <NUM> and the second network node device <NUM>.

Together, the tunnel processor <NUM> and the common acceleration and optimization processor <NUM> operate to substantially reduce the volume of, and costs for, traffic that is transferred via the satellite <NUM> while at the same time reducing apparent latency experienced by end-users of the first network node device <NUM>. The common acceleration and optimization processor <NUM> is configured to generate data for transmission via the backhaul network interface <NUM> based on data received from the tunnel processor <NUM>. In addition, the common acceleration and optimization processor <NUM> is configured to receive data from the backhaul network interface <NUM> and provide corresponding data to the tunneling processor <NUM> which in turn generates tunnel data packet(s) 166a that are output via the local interface <NUM> and subsequently received by the second tunnel endpoint device <NUM>, which delivers corresponding data packets 168a to the network device <NUM>.

As with the first network node device <NUM>, it should be understood that in different implementations, the benefits of the disclosed implementations of the second network node device <NUM> are also applicable to un-tunneled data communications. For example, <FIG> shows network device <NUM> which transmits an un-tunneled data packet 159b via the network <NUM> to the second network node device <NUM> for delivery to the network device <NUM> as a data packet 119b. Acceleration and optimization functions offered by the common acceleration and optimization processor <NUM>, such as TCP PEP, may be applied to the data packets 119b and 159b.

Referring next to <FIG>, some examples of data packets communicated via the data communication system <NUM> shown in <FIG> are presented, including data packets <NUM>, <NUM>, <NUM>, and <NUM>. Some data packets, as noted earlier, can be identified as tunnel data packets for associated tunnel sessions according to associated tunneling protocols. In this example, the data packets <NUM>, <NUM>, and <NUM> are tunnel data packets, whereas the data packet <NUM> is an un-tunneled data packet. In <FIG>, an example of an un-tunneled data packet <NUM> is shown. In different implementations, the un-tunneled data packets 119a, 119b, 159a, and 159b in <FIG> may have similar structures to the un-tunneled data packet <NUM> in <FIG>. In this example, the un-tunneled data packet <NUM> is an IPv4 TCP or UDP data packet, and accordingly the un-tunneled data packet <NUM> includes an IPv4 header portion <NUM> and a TCP/UDP packet portion <NUM> (which in turn includes a TCP or UDP data portion that is not separately illustrated in <FIG>). It is to be understood that the un-tunneled data packet <NUM> is not limited to IPv4 TCP or UDP data packets. However, for example, the common acceleration and optimization processor <NUM> of <FIG> may include various acceleration and/or optimization functions that are applied to selected TCP packets, such as TCP PEP. For convenience of illustration and discussion, <FIG> does not illustrate portions of the un-tunneled data packet <NUM> corresponding to OSI layers <NUM> and <NUM>, including, for example, a Layer-<NUM> header portion of the un-tunneled data packet <NUM>.

In addition, <FIG> illustrates an example tunnel data packet <NUM>, in which the GRE tunneling protocol, an IP-layer tunneling protocol, is employed. The tunnel data packet <NUM> includes an IP-layer tunneling protocol specific portion <NUM> and a payload <NUM> (which may be referred to as an "encapsulated payload"). The IP-layer tunneling protocol specific portion <NUM> includes an IPv4 header <NUM> and a GRE header <NUM>. The payload <NUM> may have content similar to the data packet <NUM> shown in <FIG>, including an IPv4 header portion <NUM> and a TCP/UDP packet portion <NUM>. It can further be observed that the payload <NUM> is encapsulated by or within the tunnel data packet <NUM>.

It is noted that although for some tunneling protocols, such as the example of the GRE tunneling protocol shown in <FIG>, encapsulation of a payload is performed simply by prepending one or more associated header portions to the payload, some tunneling protocols use other approaches for performing encapsulation. For example, various tunneling protocols may perform encapsulation of a payload by one or more of prepending data before the payload, appending data after the payload, inserting data within the payload, and/or reencoding the payload into different encoding format (for example, to provide an encoding that allows error detection and/or error correction to be performed on a received tunnel data packet and/or its encapsulated payload).

<FIG> illustrates an example tunnel data packet <NUM>, in which the IEEE <NUM>. 1Q tunneling protocol is employed in a Layer-<NUM> Ethernet packet. The tunnel data packet <NUM> includes a Layer-<NUM> tunneling protocol specific portion <NUM> and a payload <NUM>. The Layer-<NUM> tunneling protocol specific portion <NUM> includes an Ethernet MAC <NUM> and an <NUM>. 1Q tag <NUM>. The payload <NUM> may have content similar to the data packet <NUM> shown in <FIG>, including an IPv4 header portion <NUM> and a TCP/UDP packet portion <NUM>. It can further be observed that the payload <NUM> is encapsulated by or within the tunnel data packet <NUM>.

In different implementations, tunnel data packets may further be nested within tunnel data packets where a first tunnel session is being conveyed by a second tunnel session. A nested tunnel data packet is a type of tunnel data packet and may also be referred to as a "recursive tunnel data packet. " <FIG> illustrates one example nested tunnel data packet in which the GRE tunneling protocol is employed within the IEEE <NUM>. 1Q tunneling protocol. In this example, a first tunnel data packet <NUM> includes an Ethernet MAC <NUM>, an <NUM>. 1Q tag <NUM>, IPv4 header <NUM>, a GRE header <NUM>, an IPv4 header portion <NUM>, and a TCP/UDP packet portion <NUM>. For purposes of clarity, the Ethernet MAC <NUM> and <NUM>. 1Q tag <NUM> will be collectively referred to as a Layer-<NUM> tunneling protocol specific portion <NUM>, and the IPv4 header <NUM> and GRE header <NUM> will be collectively referred to as an IP-layer tunneling protocol specific portion <NUM>.

It can be observed that the first tunnel data packet <NUM> encapsulates a second tunnel data packet, also referred herein to as a first payload <NUM>. The first payload <NUM> includes both the IP-layer tunneling protocol specific portion <NUM> as well as the IPv4 header portion <NUM>, and TCP/UDP packet portion <NUM>, where the IPv4 header portion <NUM>, and TCP/UDP packet portion <NUM> comprise a second payload <NUM>. In some implementations, the second payload <NUM> may have content similar to the data packet <NUM> shown in <FIG>. As the second payload <NUM> does not provide tunnel encapsulation for a further payload, the second payload <NUM> may also be referred to as the "innermost" payload of the first tunnel data packet <NUM>. Likewise, the payload <NUM> in <FIG> and the payload <NUM> in <FIG> are also the innermost payloads of their respective tunnel data packets <NUM> and <NUM>.

Because the first payload <NUM> includes or encapsulates the second payload <NUM>, it can be understood in this example that the first tunnel data packet <NUM>, by encapsulation of the first payload <NUM>, also encapsulates the second payload <NUM>. Thus, the first tunnel data packet <NUM> of <FIG> comprises a nested tunnel data packet. For nested tunnel data packets, such as the first tunnel data packet <NUM>, more than one layer of tunneling protocol specific encapsulation must be recognized and processed by the tunnel processor <NUM> in order to obtain and provide a de-encapsulated IPv4 header portion <NUM> and TCP/UDP packet portion <NUM> to the common acceleration and optimization processor <NUM> (see <FIG>) for processing.

In addition, in some circumstances, a payload in a nested tunnel data packet can be associated with either a parent tunnel or child tunnel. As a general matter, a "parent" tunnel (or outer tunnel) can include a "child" tunnel (or inner tunnel) nested within the parent tunnel and configured to transport or convey a corresponding data packet layer. In some circumstances, a first parent tunnel may also be a child tunnel of a second parent tunnel. In some circumstances, a first child tunnel may also be a parent tunnel of a second child tunnel. In the example of <FIG>, the first payload <NUM> is conveyed by an outermost tunnel according to the IEEE <NUM>. 1Q tunneling protocol, while the second payload <NUM> is conveyed by a first inner tunnel or sub-tunnel that is 'within' the outermost tunnel. In this case, the outermost tunnel is a parent tunnel, with the first inner tunnel as its respective child tunnel.

For purposes of clarity, had the data packet illustrated in <FIG> included another nested data packet layer ("third payload") encapsulated by the second payload <NUM>, this third payload would be conveyed by a second inner tunnel that would be provided within and encapsulated by the first inner tunnel, which in turn was further encapsulated by the outermost tunnel. Thus, for purposes of reference, the term "parent" tunnel will be used to describe a tunnel that encapsulates another (more inner) tunnel. Similarly, a "child" tunnel will be used to describe the tunnel that is being encapsulated by the (more outer) parent tunnel. Depending on the arrangement being described, in some cases a first inner tunnel may be identified as a parent tunnel and a second inner tunnel may be identified as a child tunnel, while in another case the same second tunnel may be identified as a parent tunnel for a third inner tunnel. Additional nested data packet layers would similarly be conveyed by corresponding additional inner tunnels. Each additional inner tunnel would be increasingly distal to the outermost parent tunnel and/or would be disposed or encapsulated within an increasing number or series of inner tunnels that approach an innermost payload being conveyed by the nested arrangement of tunnels.

For purposes of clarity, <FIG> illustrates an example implementation of the tunnel processor <NUM> shown in <FIG>. In different implementations, the tunnel processor <NUM> includes an input data packet processor <NUM> configured to receive incoming Layer-<NUM> data packets <NUM> (including a tunnel data packet <NUM>) from the local network interface (see local network interface <NUM> of <FIG>) and process the received data packets, including identifying new tunnel sessions and identifying tunnel data packets for supported tunneling protocols. It should be understood that each new tunnel session identified by the input data packet processor <NUM> can be associated with a plurality of tunnel data packets.

In different implementations, the input data packet processor <NUM> utilizes a plurality of tunneling protocol submodules <NUM>, each corresponding to a different supported tunneling protocol (which may be referred to as a `tunnel type'), in order to facilitate identification of tunnel sessions, associated tunnel data packets, and perform tunneling protocol-specific processing. For purposes of reference, the tunneling protocol submodules <NUM> may include one or more of Layer-<NUM> tunneling protocol submodules <NUM>, one or more IP-Layer tunneling protocol submodules <NUM>, and/or one or more other tunneling protocol submodules <NUM> (for tunneling protocol submodules not included in the Layer-<NUM> tunneling protocol submodules or the IP-Layer tunneling protocol submodules <NUM>). Although examples are presented using three categories of tunneling protocols ("Layer-<NUM>," "IP-Layer," and "other"), in other examples there may be additional and/or different categories.

In an example in which the tunnel data packet <NUM> is for a new tunnel session and is received by the input data packet processor <NUM>, the input data packet processor <NUM> can, with reference to tunneling protocol submodules <NUM>, associate a tunnel protocol submodule with the newly identified tunnel session. In conjunction with this association, a tunnel type is also identified for the tunnel session (for example, implicitly in connection with the association with the tunnel protocol submodule).

In connection with identifying a new tunnel session, the input data packet processor <NUM> makes use of a packet context module <NUM> to instantiate a new packet context (in this example, referred to as first packet context <NUM>) for the new tunnel session. The packet context module <NUM> can be configured to generate and maintain multiple packet contexts <NUM>, including, for example, the first packet context <NUM>, in different implementations. In some circumstances, the input data packet processor <NUM> may identify hundreds or thousands of tunnel sessions, each with a respective packet context <NUM> maintained by the packet context module <NUM>. In some implementations, a packet context may be generated at least in part by reference to data provided by the corresponding tunnel protocol submodule associated with the tunnel session (see tunneling protocol submodules <NUM>).

In addition, for example in implementations that support processing of nested tunnel data packets (see <FIG>), the packet context module <NUM> can be configured to generate a packet context <NUM> for each 'layer' of a given nested tunnel session. Thus, the input data packet processor <NUM> can distinguish or recognize multiple packet contexts as appropriate for each layer of nested tunnel data packets. As there are parent/child relationships between the nested tunnel sessions for a nested tunnel data packet, there are corresponding parent/child relationships between the corresponding packet contexts of each layer.

In order to allow the reader to better appreciate the examples described herein, a more detailed example of a content of a packet context <NUM> (for example, the first packet context <NUM>, a second packet context <NUM>, etc.) is presented with reference to <FIG>. In <FIG>, the packet context <NUM> includes a context identifier <NUM>, an optional parent context identifier <NUM>, tunneling protocol submodule identifier <NUM>, static tunnel state <NUM>, an optional dynamic/current tunnel state <NUM>, child contexts identifiers <NUM>, and IP packet fragments <NUM>. For purposes of the example shown in <FIG>, the term "identifier" should be understood to include a numeric or alphanumeric value and/or a pointer to an object, structure, or value in a memory.

In different implementations, the tunnel processor <NUM> can include provisions for facilitating identification and selection of a packet context <NUM>. For example, in <FIG>, the context identifier <NUM> is a unique identifier assigned to and associated with the packet context <NUM>. The context identifier may also be referred to as a "tunnel identifier. " In some implementations, the context identifier <NUM> may include a portion indicating a tunneling protocol type for the packet context <NUM>. Furthermore, in implementations that support processing of nested tunnel data packets (see <FIG>), the packet context <NUM> can further include the parent context identifier <NUM>. The parent context identifier <NUM> can be configured to identify a packet context for the data packet that encapsulates the packet context <NUM>. For example, for the first packet context <NUM>, the parent context is the outermost packet context <NUM>. As another example, the outermost parent context <NUM> has no parent context. In addition, the tunneling protocol submodule identifier <NUM> provides a unique identifier for the tunneling protocol submodule <NUM> that is associated with the packet context <NUM>, and which may be used by the tunnel processor <NUM> to identify and select one of the multiple tunnel protocol submodules <NUM>.

Furthermore, the static tunnel state <NUM> stores data describing encapsulation information, such as header fields, which is re-used for one or more first portions of the tunnel data packets for the tunnel session associated with the packet context <NUM> or can be used to calculate, without additional packet-specific encapsulation information, one or more other second portions of the tunnel data packets for the tunnel session. In some implementations, the static tunnel state <NUM> is for tunnel session-specific information that may be different between two different tunnel sessions of the same tunneling protocol. In addition, the dynamic/current tunnel state <NUM> stores packet-specific data describing encapsulation information, for the most recent tunnel data packet for the tunnel session associated with the packet context <NUM>, for one or more third portions of tunnel data packets for the tunnel session that may change without a pattern described and/or determined by the static tunnel state <NUM>. These third portions may be described as being irregular, variable, or erratic. For some tunneling protocols, a first portion of the dynamic tunnel state may be for the tunnel data packet previously received by the input data packet processor <NUM> for the tunnel session, and a second portion may be for the tunnel data packet previously output or generated by the output data packet generator <NUM> for the tunnel session. In some implementations, the input data packet processor <NUM> is configured to use the tunnel protocol submodule associated with a packet context to generate the static tunnel state <NUM> when a new packet context is instantiated and to generate a dynamic tunnel state for each tunnel data packet received for the packet context. The content, encoding, and formatting of the static tunnel state <NUM> and the dynamic tunnel state <NUM> may be determined by the generating tunnel protocol submodule and treated as an opaque data "blob" that is stored and/or transferred by other portions of the first network node <NUM> without modification (including, for example, via the satellite <NUM>).

As one example, for the tunnel data packet <NUM> shown in <FIG>, in which the payload <NUM> is encapsulated according to the GRE tunneling protocol, portions re-used in tunnel data packets for a same GRE tunnel session and included in the static tunnel state <NUM> would include the fields of the IPv4 header <NUM> and GRE header <NUM> that are unchanged across tunnel data packets of a single GRE tunnel session, such as the Version, Source IP Address, Destination IP Address, Time to Live, Flags, and Internet Header Length fields of the IPv4 header <NUM>, and the Checksum Present (C), Routing Present (R), Key Present (K), Sequence Number Present (S), Strict Source Route Present (s), Acknowledgement Sequence Number Present (A), Flags, Version (Ver), Protocol Type, and Key fields of the GRE header <NUM>. It is noted that although the Version and Protocol fields of the IPv4 header <NUM> are unchanged across tunnel data packets, they are not tunnel session-specific, as in all GRE tunnel sessions the Version field has a value of <NUM> and the Protocol field has a value of <NUM>; accordingly, the Version and Protocol fields of the IPv4 header <NUM> may not be included in the static tunnel state <NUM>. Portions of the tunnel data packet <NUM> which can be used to calculate corresponding portions of tunnel data packets for a same GRE tunnel session and included in the static tunnel state <NUM> would include fields such as the Sequence Number field of the GRE header <NUM> (which is simply incremented by one on each tunnel data packet transmitted). A dynamic tunnel state <NUM> would be generated, for each tunnel data packet of a GRE tunnel session, from the fields of the IPv4 header <NUM> and GRE header <NUM> which may change irregularly in the middle of a GRE tunnel session, such as the Type of Service (ToS) field of the IPv4 header <NUM>. The dynamic tunnel state <NUM> is used by the output data packet generator <NUM> (for example, including an output data packet generator included in the tunnel processor <NUM> of the second network node device <NUM>) to effectively re-generate a tunnel data packet after corresponding data is transmitted via the backhaul network interface <NUM> (see <FIG>).

As another example, for the tunnel data packet <NUM> shown in <FIG>, in which the payload <NUM> is encapsulated according to the IEEE <NUM>. 1Q tunneling protocol, portions re-used in tunnel data packets for a same IEEE <NUM>. 1Q tunnel session and included in the static tunnel state <NUM> would include the fields of the Ethernet MAC <NUM> and <NUM>. 1Q tag <NUM> that are unchanged across tunnel data packets of a single IEEE <NUM>. 1Q tunnel session, such as the Destination MAC Address, Source MAC Address, and EtherType / VLAN Protocol ID fields of the Ethernet MAC <NUM>. A dynamic tunnel state <NUM> would be generated, for each tunnel data packet of an IEEE <NUM>. 1Q tunnel session, from the fields of the Ethernet MAC <NUM> and <NUM>. 1Q tag <NUM> which may change irregularly in the middle of an IEEE <NUM>. 1Q tunnel session, such as the VLAN Priority Code Point (PCP) and VLAN identifier (VID) fields of the <NUM>. 1Q tag <NUM>.

The child context identifiers <NUM> identify packet contexts for tunnel sessions that have been identified for the packet context <NUM>. For example, the first packet context <NUM> would be identified as a child context of the outermost packet context <NUM>. In some implementations, as shown in <FIG>, the child context identifiers <NUM> may be segregated into different groups such as Layer-<NUM> tunneling protocol child context identifiers <NUM>, IP-layer tunneling protocol child context identifiers <NUM>, and/or other tunneling protocol child context identifiers <NUM>. This segregation facilitates the process <NUM> described further below with reference to <FIG> and <FIG>. Furthermore, IP packet fragments <NUM> are IP packet fragments that have been received within the packet context <NUM> and for which additional IP packet fragments are required to reassemble complete un-fragmented IP packets for processing in connection with IP-Layer tunneling protocols (additional details will be provided with reference to <FIG>).

Returning now to <FIG>, it can be seen that in response to identifying the new tunnel session for which the first packet context <NUM> has been instantiated, the input data packet processor <NUM> issues a new tunnel notification <NUM> to the common acceleration and optimization processor <NUM> that includes a tunneling protocol identifier (for example, the tunnel protocol submodule identifier <NUM> or other unique identifier for the tunnel protocol submodule for the new first packet context <NUM>) and the static tunnel state <NUM> (see <FIG>) of the first packet context <NUM>. In some examples, the new tunnel notification <NUM> may include the context identifier <NUM> (to associate an identifier with the tunnel session) of the new first packet context <NUM> and/or the parent context identifier <NUM> (for example, if nested tunneling is supported) of the new first packet context <NUM>.

In response to receiving the new tunnel notification <NUM> from the input data processor <NUM>, the common acceleration and optimization processor <NUM> transmits corresponding data via the backhaul network interface <NUM> and the satellite <NUM> to the common acceleration and optimization processor <NUM> included in the second network node device <NUM> (see <FIG>). For example, the common acceleration and optimization processor <NUM> may transmit data indicating a new tunnel has been identified, the tunneling protocol identifier, the static tunnel state, the context identifier, and/or the parent context identifier received from the input data packet processor <NUM>. In some implementations, instead of providing the new tunnel notification <NUM> to the common acceleration and optimization processor <NUM>, the input data packet processor <NUM> provides the new tunnel notification <NUM> to the backhaul network interface <NUM> or other portion of the first network node device <NUM> for transmission of corresponding data via the backhaul network interface <NUM> and the satellite <NUM> to the second network node device <NUM>.

In response to receiving via the backhaul network interface <NUM> such data indicating a new tunnel was identified by another network node device (such as the second network node device <NUM>), the common acceleration and optimization processor <NUM> may be configured to provide a corresponding notification <NUM> to the output data packet generator <NUM>, in response to which the output data packet generator <NUM> instantiates a corresponding new packet context <NUM>. In some implementations, instead of using the common acceleration and optimization processor <NUM> to provide the notification <NUM>, the first network node device <NUM> is configured to receive a context identifier, tunneling protocol identifier, and/or static tunnel state via the backhaul network node interface <NUM> and provide the corresponding notification <NUM> to the output data packet generator <NUM>.

In an example in which the tunnel data packet <NUM> is received for a previously identified tunnel session, the input data packet processor <NUM> is configured to identify one or more corresponding packet contexts <NUM> (multiple packet contexts <NUM> may be identified for a nested tunnel data packet). For example, for the tunnel data packet <NUM> shown in <FIG>, a single packet context <NUM> (for a GRE tunnel session) would be identified whereas for the first tunnel data packet <NUM> in <FIG>, two packet contexts <NUM> (one for an IEEE <NUM>. 1Q tunnel session, and another for a child GRE tunnel session) would be identified.

Whether the tunnel data packet <NUM> is identified as being for a new tunnel session or not, the input data packet processor <NUM> further obtains the innermost payload of the tunnel data packet <NUM> and provides the de-encapsulated innermost payload as packet data <NUM>, along with the context identifier <NUM> (see <FIG>) for a packet context <NUM> of the innermost payload, to the common acceleration and optimization processor <NUM> (see <FIG>). If there is a dynamic tunnel state <NUM> associated with the tunnel data packet <NUM>, the dynamic tunnel state <NUM> is also provided to the common acceleration and optimization processor <NUM> with the packet data <NUM> as an associated dynamic tunnel state <NUM>. For a nested tunnel data packet, multiple dynamic tunnel states <NUM>, for respective tunnel layers, may be generated and provided to the common acceleration and optimization processor <NUM>. In some implementations, if a first dynamic tunnel state for the current tunnel data packet <NUM> (or a portion thereof) is unchanged from a second dynamic tunnel state for the tunnel data packet previously received for the current packet context, it may not be provided to the common acceleration and optimization processor <NUM>. For an un-tunneled data packet such as the example data packet <NUM> depicted in <FIG>, the input data packet processor <NUM> simply delivers the received data packet <NUM> as the packet data <NUM> to the common acceleration and optimization processor <NUM>. In an implementation in which a context identifier is included with the packet data <NUM> (for example, an implementation supporting nested tunneling), the context identifier <NUM> (see <FIG>) for the outermost packet context <NUM> may also be included in the packet data <NUM> for the un-tunneled data packet.

In response to receiving the packet data <NUM>, and in some circumstances the associated dynamic tunnel state <NUM>, from the input data packet processor <NUM>, the common acceleration and optimization processor <NUM> may transmit corresponding data for a new data packet via the backhaul network interface <NUM> and the satellite <NUM> to the common acceleration and optimization processor <NUM> included in the second network node device <NUM> (see <FIG>). For example, the common acceleration and optimization processor <NUM> may transmit the packet data <NUM>, the context identifier, and/or the dynamic tunnel state received from the input data packet processor <NUM>. In response to receiving via the backhaul network interface <NUM> such data for a new data packet (such as from the second network node device <NUM>), or in certain other circumstances (for example, providing cached data), the common acceleration and optimization processor <NUM> may be configured to provide a corresponding packet data <NUM> and dynamic tunnel state <NUM> to the output data packet generator <NUM>, in response to which the output data packet generator <NUM> instantiates a corresponding new data packet <NUM>. In some circumstances, in response to receiving the packet data <NUM> from the input data packet processor <NUM>, the common acceleration and optimization processor <NUM> may generate and transmit, and in some cases also receive, one or more acceleration data packets via the backhaul link to implement an acceleration function. For example, a TCP PEP transport acceleration packet or an acceleration packet including caching data.

In some implementations, the data communication system <NUM> supports quality of service (QoS) or other prioritization techniques for transferring data packets via the backhaul link between the first network node device <NUM> and the second network node device <NUM>. For example, the common acceleration and optimization processor <NUM> may be configured to selectively assigned data packets to various data flows with different data transfer characteristics, such as, but not limited to, bandwidth, latency, and/or guarantees for delivery. For some such implementations, the input data packet processor <NUM> is configured to, for some tunnel data packets, generate a packet priority <NUM> that is provided to the common acceleration and optimization processor <NUM> with a packet data <NUM>. For example, a tunnel protocol submodule <NUM> may be configured to, based on at least a tunneling protocol-specific portion of a tunnel data packet, generate a priority value for a tunnel data packet that is used by the input data packet processor <NUM> to generate the packet priority <NUM>. The tunnel protocol submodule <NUM> may be configured to generate the priority value as part of generating a dynamic tunnel state <NUM>. As an example, for the tunnel data packet <NUM> shown in <FIG>, in which the payload <NUM> is encapsulated according to the IEEE <NUM>. 1Q tunneling protocol, the VLAN Priority Code Point (PCP) field of the <NUM>. 1Q tag <NUM> may be used to generate a priority value for an IEEE <NUM>. 1Q tunneled data packet. The eight different values that may be used for the PCP field may be translated to appropriate values understood by the common acceleration and optimization processor <NUM> by the tunnel protocol submodule <NUM>, the input data processor <NUM>, and/or a priority translator (not shown in <FIG>) between the input data processor <NUM> and the common acceleration and optimization processor <NUM>.

The output data packet generator <NUM> is configured to receive a new tunnel notification <NUM> including a corresponding static tunnel state; in some implementations, from the common acceleration and optimization processor <NUM> (see <FIG>). In response to receiving the new tunnel notification <NUM>, the output data packet generator <NUM> causes the packet context module <NUM> to instantiate a corresponding second packet context <NUM> included in the packet contexts <NUM> maintained by the packet context module <NUM>. In some implementations, the new tunnel notification <NUM> includes values for use as, for effective for determining, the unique context identifier <NUM>, parent context identifier <NUM>, and tunneling protocol submodule identifier <NUM> of the new second packet context <NUM> instantiated in response to the new tunnel notification <NUM>.

The output data packet generator <NUM> is further configured to generate outgoing Layer-<NUM> data packets <NUM> based on at least packet data <NUM> and any associated dynamic tunnel state <NUM> received from the common acceleration and optimization processor <NUM> (see <FIG>). As described for the packet data <NUM>, the packet data <NUM> is accompanied by a context identifier effective for selecting a corresponding packet context <NUM>. Where the identified packet context is associated with the outermost packet context <NUM>, an un-tunneled data packet <NUM> is output by the output data packet generator <NUM> with the packet data <NUM>.

Otherwise, the output data packet generator <NUM> generates a tunnel data packet <NUM> that encapsulates the packet data <NUM>. To generate the tunnel data packet <NUM>, a packet context <NUM> corresponding to the context identifier provided with the packet data <NUM> is identified and selected. In some implementations, the context identifier provided with the packet data <NUM> includes a portion indicating a tunneling protocol type for the packet context <NUM>, which may be used to select a tunneling protocol. Then the packet data <NUM> is encapsulated according to the selected packet context <NUM>; for example, the tunneling protocol submodule identifier associated with the selected packet context <NUM> is used, based on at least the static tunnel state <NUM> for the packet context <NUM> and any dynamic tunnel state <NUM> received in association with the packet data <NUM> for the packet context <NUM>. The dynamic tunnel state <NUM> may also be used to update the dynamic tunnel state <NUM> of the selected packet context <NUM>. At this point, and if nested tunneling is supported, the second packet context <NUM> is considered a `current' packet context, and the just-encapsulated packet data <NUM> is considered a 'current' payload. While the parent context identifier <NUM> of the current packet context is not for the outermost packet context <NUM> (as would occur for a nested tunnel data packet), the packet context <NUM> corresponding to the parent context identifier <NUM> becomes the new current packet context and the current payload is encapsulated according to the new current packet context to become a new current payload. Once the parent context identifier <NUM> of the current packet context is for the outermost packet context <NUM>, encapsulation of the packet data <NUM> as an innermost payload of the tunnel data packet <NUM>, including for nested tunneling if it applies, is complete and the current payload is output as the tunnel data packet <NUM>. The output data packet generator <NUM> and/or the local network interface <NUM> may be configured to generate a Layer-<NUM> header for the tunnel data packet <NUM>.

For purposes of clarity, <FIG> illustrate an example process flow diagram ("process") <NUM> for processing of incoming Layer-<NUM> data packets by the input data packet processor <NUM> shown in <FIG>. Thus, some of the steps described below will also refer to items described with reference to <FIG>. As shown in <FIG>, the process begins with a first step <NUM> where the input data packet processor receives a Layer-<NUM> ("L2") packet (such as, but not limited to, an Ethernet packet) from the local network interface <NUM> of <FIG> and the process <NUM> creates a corresponding current packet layer item <NUM> for which the Data is the Layer-<NUM> packet, a DataType of "L2" (indicating the Data is for a Layer-<NUM> packet, including, for example, a Layer-<NUM> header), and a CurrentContext of the outermost packet context <NUM> described in <FIG>.

The process <NUM> then determines at a second step <NUM> whether the current packet layer item is for an IP packet fragment. For example, for Layer-<NUM> Ethernet, the current packet layer item may be identified as for an IPv4 packet fragment when an EtherType field of the current packet layer item is for an IPv4 (i.e., 0x0800) and fields of an IPv4 header portion of the data for the current packet layer item (such as the More Fragments and Fragment Offset fields) indicate IP packet fragmentation. If so (<NUM>, Y), the process <NUM> continues to third step <NUM> at which it determines whether the identified IP packet fragment <NUM> will, with one or more IP packet fragments previously identified for the current packet context (see IP packet fragments <NUM> in <FIG>), provide all of the IP packet fragments needed to complete reassembly of an entire IP packet. If so (<NUM>, Y), at fourth step <NUM> the process reassembles the fragmented IP packet using the currently identified IP packet fragment <NUM> and its associated previously identified IP packet fragments for the current packet context (which are also removed from the IP packet fragments <NUM> of the current packet context). The Data for the current packet layer item then becomes the reassembled IP packet data, the DataType becomes "IP" (indicating the Data is for an IP packet, including an IP header), and the CurrentContext remains unchanged, as represented by the current data packet item <NUM>. The process then continues in <FIG> (symbolized by a "C"), as will be discussed further below.

Returning to third step <NUM>, if the currently identified IP packet fragment does not complete an IP packet (<NUM>, N) at fifth step <NUM> the process adds the newly identified IP packet fragment to the IP Packet Fragments <NUM> for the current packet context, and the process <NUM> ends. The process can then be repeated for the next L2 packet received by the local network interface <NUM> (see <FIG>).

Returning to second step <NUM>, if the current packet layer item is not for an IP packet fragment (<NUM>, N), at sixth step <NUM> the process <NUM> determines if the current packet layer item is for an existing L2 tunneling protocol child context of the current context. For example, for each of the Layer-<NUM> tunneling protocol child context identifiers <NUM> in <FIG> for the current context, the corresponding child packet context is used in combination with its associated tunneling protocol submodule (see tunneling protocol identifier <NUM> in <FIG>) to determine if the current packet layer item matches the tunnel for the child packet context. If so (<NUM>, Y), the matching child packet context is used to generate a new dynamic tunnel state, if any, for the current packet layer item at a seventh step <NUM>. If a new dynamic tunnel state is generated, it is provided to the common acceleration and optimization processor <NUM> (see <FIG>) in association with the packet received at first step <NUM>. Then, at an eighth step <NUM>, the tunneling protocol submodule for the matching child packet context is used to obtain the de-encapsulated payload from the current packet layer item.

The Data for the current packet layer item then becomes the de-encapsulated payload, the DataType becomes a payload type indicated by the tunneling protocol submodule, and the CurrentContext is changed to the matching child packet context, as represented by the current data packet item <NUM>. The tunneling protocol submodule is configured to indicate the payload DataType, as it is specific to the tunneling protocol. For example, whereas the IPIP protocol is an IP-Layer tunneling protocol that carries an IP packet payload, the L2TP protocol is also an IP-Layer tunneling protocol that instead carries a Layer-<NUM> packet payload. In order to determine if there is a nested tunnel within the de-encapsulated payload then the process can continue (symbolized by "A") at a ninth step <NUM>, where a determination is made if the Data Type for the current packet layer item is for an IP packet. If so (<NUM>, Y), the process continues in <FIG> (symbolized by a "C"), as will be discussed further below. If not (<NUM>, N), and the DataType is for an L2 packet, the process <NUM> returns to second step <NUM>.

Returning to sixth step <NUM>, if the current packet layer item is not for an existing L2 tunneling protocol child context (<NUM>, N), at a tenth step <NUM> the process determines whether the current packet layer item is for a new L2 tunnel. For example, each of the Layer-<NUM> tunneling protocol submodules <NUM> in <FIG> may be invoked to determine, based at least on the current packet layer item, whether the current packet layer item is encapsulating a payload according to the Layer-<NUM> tunneling protocol associated with the invoked Layer-<NUM> tunneling protocol submodule. If so (<NUM>, Y), the packet context module is used to create a new child packet context for the current packet context at an eleventh step <NUM>. At a subsequent twelfth step <NUM> the context identifier for the newly created packet context is added to the Layer-<NUM> tunneling protocol child context identifiers <NUM> for the current packet context. Additionally, at thirteenth step <NUM>, the Layer-<NUM> tunneling protocol submodule for the new packet context is used to generate a static tunnel state for the newly identified tunnel (see static tunnel state <NUM> in <FIG>). This static tunnel state, along with a notification that a new tunnel has been identified, is provided to the common acceleration and optimization processor <NUM> in association with the L2 data packet received at the first step <NUM>.

Furthermore, at a fourteenth step <NUM>, the Layer-<NUM> tunneling protocol submodule is also used to obtain the de-encapsulated payload from the current packet layer item and the current packet data context is updated as described in eighth step <NUM>. The Data for the current packet layer item then becomes the de-encapsulated payload, the DataType becomes a payload type indicated by the tunneling protocol submodule, and the CurrentContext is changed to the matching child packet context, as represented by the current data packet item <NUM>. Also, as described previously for the eighth step <NUM>, in order to determine if there is a nested tunnel within the de-encapsulated payload then the process can continue (symbolized by "A") at ninth step <NUM>, where a determination is made if the Data Type for the current packet layer item is for an IP packet. If so (<NUM>, Y), the process continues in <FIG> (symbolized by a "C"), as will be discussed further below. If not (<NUM>, N), and the Data Type is for an L2 packet, the process <NUM> returns to second step <NUM>. Returning to tenth step <NUM>, if the current packet layer item is not for a new tunnel for an L2 tunneling protocol (<NUM>, N) then the process continues on to <FIG> (symbolized by a "B"), discussed below.

Referring now to <FIG>, at a fifteenth step <NUM>, the process determines whether an EtherType field of the current packet layer item is either for an IPv4 (i.e., 0x0800) or IPv6 packet (i.e., 0x86DD). If so (<NUM>, Y), the Data for the current packet layer item then becomes the L2 packet payload of the current packet layer item (for example, by removing or otherwise omitting a Layer-<NUM> Ethernet header portion), the DataType becomes "IP", and the CurrentContext remains unchanged, as represented by the current data packet item <NUM>. At a sixteenth step <NUM>, the process <NUM> continues by determining if the current packet layer item is for an existing IP tunneling protocol child context of the current context. For example, for each of the IP-Layer tunneling protocol child context identifiers <NUM> in <FIG> for the current context, the corresponding child packet context is used in combination with its associated tunneling protocol submodule (see tunneling protocol identifier <NUM> in <FIG>) to determine if the current packet layer item matches the tunnel for the child packet context. If so (<NUM>, Y), the matching child packet context is used to generate a new dynamic tunnel state, if any, for the current packet layer item at a seventeenth step <NUM>. If a new dynamic tunnel state is generated, it is provided to the common acceleration and optimization processor <NUM> (see <FIG>) in association with the packet received at first step <NUM>. Then, at an eighteenth step <NUM>, the tunneling protocol submodule for the matching child packet context is used to obtain the de-encapsulated payload from the current packet layer item.

The Data for the current packet layer item then becomes the de-encapsulated payload, the DataType becomes a payload type indicated by the tunneling protocol submodule, and the CurrentContext is changed to the matching child packet context, as represented by the current data packet item <NUM>. In order to determine if there is a nested tunnel within the de-encapsulated payload then the process can continue (symbolized by "A") at the ninth step <NUM> (see previous <FIG>).

Returning to sixteenth step <NUM>, if the current packet layer item is not for an existing IP tunneling protocol child context (<NUM>, N), at a nineteenth step <NUM> the process determines whether the current packet layer item is for a new tunnel for an IP-Layer tunneling protocol. For example, each of the IP-Layer tunneling protocol submodules <NUM> in <FIG> may be invoked to determine, based at least on the current packet layer item, whether the current packet layer item is encapsulating a payload according to the IP-Layer tunneling protocol associated with the invoked IP-Layer tunneling protocol submodule. If so (<NUM>, Y), the packet context module is used to create a new child packet context for the current packet context at a twentieth step <NUM>.

At a subsequent twenty-first step <NUM> the context identifier for the newly created packet context is added to the IP-Layer tunneling protocol child context identifiers <NUM> for the current packet context. Additionally, at twenty-second step <NUM>, the IP-Layer tunneling protocol submodule for the new packet context is used to generate a static tunnel state for the newly identified tunnel (see static tunnel state <NUM> in <FIG>). This static tunnel state, along with a notification that a new tunnel has been identified, is provided to the common acceleration and optimization processor <NUM> in association with the L2 data packet received at the first step <NUM>.

Furthermore, at a twenty-third step <NUM>, the IP-Layer tunneling protocol submodule is also used to obtain the de-encapsulated payload from the current packet layer item and the current packet data context is updated as described in the eighteenth step <NUM>. The Data for the current packet layer item then becomes the de-encapsulated payload, the DataType becomes a payload type indicated by the tunneling protocol submodule, and the CurrentContext is changed to the matching child packet context, as represented by the current data packet item <NUM>. Also as described previously for the eighteenth step <NUM>, in order to determine if there is a nested tunnel within the de-encapsulated payload then the process can continue (symbolized by "A") at the ninth step <NUM> (see <FIG>).

Returning to nineteenth step <NUM>, if a new tunnel for an IP-Layer tunneling protocol is not identified (<NUM>, N), at a twenty-fourth step <NUM>, data from the current packet layer item including the Data, DataType, and CurrentContext are provided to the common acceleration and optimization processor <NUM>, which concludes the processing by the input data packet processor <NUM> of the data packet received at the first step <NUM>.

Returning to fifteenth step <NUM>, if the current packet layer item is not for an IP packet (<NUM>, N), the process continues in <FIG> (symbolized by a "D"), as will now be discussed below. In <FIG>, at a twenty-fifth step <NUM> the process <NUM> continues by determining if the current packet layer item is for an existing other tunneling protocol child context of the current context. For example, for each of the other tunneling protocol child context identifiers <NUM> in <FIG> for the current context, the corresponding child packet context is used in combination with its associated tunneling protocol submodule (see tunneling protocol identifier <NUM> in <FIG>) to determine if the current packet layer item matches the tunnel for the child packet context. If so (<NUM>, Y), the matching child packet context is used to generate a new dynamic tunnel state, if any, for the current packet layer item at a twenty-sixth step <NUM>. If a new dynamic tunnel state is generated, it is provided to the common acceleration and optimization processor <NUM> (see <FIG>) in association with the data packet received at first step <NUM>. Then, at a twenty-seventh step <NUM>, the tunneling protocol submodule for the matching child packet context is used to obtain the de-encapsulated payload from the current packet layer item.

Returning to the twenty-fifth step <NUM>, if the current packet layer item is not for an existing other tunneling protocol child context (<NUM>, N), at a twenty-eighth step <NUM> the process determines whether the current packet layer item is for a new other tunnel. For example, each of the other tunneling protocol submodules <NUM> in <FIG> may be invoked to determine, based at least on the current packet layer item, whether the current packet layer item is encapsulating a payload according to the other tunneling protocol associated with the invoked other tunneling protocol submodule. If so (<NUM>, Y), the packet context module is used to create a new child packet context for the current packet context at a twenty-ninth step <NUM>.

At a subsequent thirtieth step <NUM> the context identifier for the newly created packet context is added to the other tunneling protocol child context identifiers <NUM> for the current packet context. Additionally, at a thirty-first step <NUM>, the other tunneling protocol submodule for the new packet context is used to generate a static tunnel state for the newly identified tunnel (see static tunnel state <NUM> in <FIG>). This static tunnel state, along with a notification that a new tunnel has been identified, is provided to the common acceleration and optimization processor <NUM> in association with the L2 data packet received at the first step <NUM>.

Furthermore, at a thirty-second step <NUM>, the other tunneling protocol submodule is also used to obtain the de-encapsulated payload from the current packet layer item and the current packet data context is updated as described in the twenty-seventh step <NUM>. The Data for the current packet layer item then becomes the de-encapsulated payload, the DataType becomes a payload type indicated by the tunneling protocol submodule, and the CurrentContext is changed to the matching child packet context, as represented by the current data packet item <NUM>. Also as described previously for the twenty-seventh step <NUM>, in order to determine if there is a nested tunnel within the de-encapsulated payload then the process can continue (symbolized by "A") at the ninth step <NUM> (see <FIG>).

Returning to twenty-eighth step <NUM>, if a new other protocol tunnel is not identified (<NUM>, N), at a thirty-third step <NUM>, data from the current packet layer item including the Data, DataType, and CurrentContext are provided to the common acceleration and optimization processor <NUM>, which concludes the processing by the input data packet processor <NUM> of the data packet received at the first step <NUM>.

For purposes of clarity, an implementation of a method facilitating data communication will now be provided. In different implementations, the method can include a first step of receiving, at a first network node device, via a local network interface, a first tunnel data packet encapsulating a first payload according to a first tunneling protocol, a second tunnel data packet encapsulating a second payload according to the first tunneling protocol, and a third tunnel data packet encapsulating a third according to a second tunneling protocol that is different than the first tunneling protocol. In a second step, the method includes identifying a first tunnel session associated with the first tunnel data packet and a second tunnel session associated with the third tunnel data packet that is different than the first tunnel session, and a third step involves generating and maintaining a first packet context for the first tunnel session based on at least the received first tunnel data packet, and a second packet context for the second tunnel session based on at least the received third tunnel data packet. In addition, the method can include a fourth step of determining, based on at least the first packet context and the second tunnel data packet, that the second tunnel data packet is for the first tunnel session. A fifth step includes de-encapsulating the second payload from the second tunnel data packet in accordance with the first tunneling protocol, in response to the determination that the second tunnel data packet is for the first tunnel session, and a sixth step includes de-encapsulating the third payload from the third tunnel data packet in accordance with the second tunneling protocol in response to the determination that the third tunnel data packet is for the second tunnel session. Furthermore, a seventh step of the method can include submitting the second payload and the third payload to a common acceleration and optimization processor of the first network node device.

In other implementations, the method can include additional or alternate steps. For example, the method may further include receiving, at the first network node device, via the local network interface, a first un-tunneled data packet, and submitting the first un-tunneled data packet to the common acceleration and optimization processor of the first network node device. In another example, the generation of the second packet context includes assigning a unique context identifier and a tunneling protocol identifier to the second packet context and generating a static tunnel state describing encapsulation information including values re-used in subsequent tunnel data packets for the second tunnel session and/or data for use in calculating other values included in subsequent tunnel data packets for the second tunnel session. In such a case, the method can further include providing the unique context identifier, the tunneling protocol identifier, and the static tunnel state to the common acceleration and optimization processor.

In some implementations, the method can further include generating a dynamic tunnel state for the third tunnel data packet, where the dynamic tunnel state includes values of the third tunnel data packet that change without a pattern described by the static tunnel state, and providing the dynamic tunnel state to the common acceleration and optimization processor in association with the third tunnel data packet.

In another implementation, the method may also include receiving a notification indicating that a second network node device different than the first network node device identified a third tunnel session. In some cases, the notification include a unique first context identifier and a tunneling protocol identifier for the third tunnel session as well as a static tunnel state describing encapsulation information including values re-used in tunnel data packets for the third tunnel session and/or data for use in calculating other values included in tunnel data packets for the third tunnel session. The method may further include receiving, at the first network node device, a fourth payload and an associated second context identifier, and selecting a third tunneling protocol based on the second context identifier. In addition, the method can involve generating a fourth tunnel data packet encapsulating the fourth payload according to the third tunneling protocol based on at least the static tunnel state, and outputting the fourth tunnel data packet via the local network interface. In some implementations, the method also includes receiving, at the first network node device, a dynamic tunnel state associated with the fourth payload data, where generating the fourth tunnel data packet is based on at least the dynamic tunnel state and the static tunnel state.

As another example, the method can include receiving, at the first network node device, via a backhaul network interface, a cache data item, and then storing the cache data item at the first network node device. In addition, the method can include determining, by the common acceleration and optimization processor, that the cache data item fulfills a request included in the third payload, and then generating, by the common acceleration and optimization processor, a response to the request based at least on a content of the cache data item. Furthermore, the method can include generating, at the first network node device and based at least on the second packet context, a fourth tunnel data packet encapsulating a portion of the response according to the second tunneling protocol, and then outputting the fourth tunnel data packet via the local network interface.

In one implementation, the method may further include transmitting the third payload in combination with a unique identifier assigned to the second packet context via a backhaul network interface to a second network node device. In some other implementations, the method also includes generating, by the common acceleration and optimization processor, an acceleration data packet based at least on the third payload, transmitting the acceleration data packet via a backhaul network interface to a second network node device, and generating, by the common acceleration and optimization processor, a response to the third payload. In addition, the method can include generating, at the first network node device and based at least on the second packet context, a fourth tunnel data packet encapsulating a portion of the response according to the second tunneling protocol, and then outputting the fourth tunnel data packet via the local network interface.

The detailed examples of systems, devices, and techniques described in connection with <FIG> are presented herein for illustration of the disclosure and its benefits. Such examples of use should not be construed to be limitations on the logical process implementations of the disclosure, nor should variations of user interface methods from those described herein be considered outside the scope of the present disclosure. In some implementations, various features described in <FIG> are implemented in respective modules, which may also be referred to as, and/or include, logic, components, units, and/or mechanisms. Modules may constitute either software modules (for example, code embodied on a machine-readable medium) or hardware modules.

In some examples, a hardware module may be implemented mechanically, electronically, or with any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic that is configured to perform certain operations. For example, a hardware module may include a special-purpose processor, such as a field-programmable gate array (FPGA) or an Application Specific Integrated Circuit (ASIC). A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations, and may include a portion of machine-readable medium data and/or instructions for such configuration. For example, a hardware module may include software encompassed within a programmable processor configured to execute a set of software instructions. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (for example, configured by software) may be driven by cost, time, support, and engineering considerations.

Accordingly, the phrase "hardware module" should be understood to encompass a tangible entity capable of performing certain operations and may be configured or arranged in a certain physical manner, be that an entity that is physically constructed, permanently configured (for example, hardwired), and/or temporarily configured (for example, programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering examples in which hardware modules are temporarily configured (for example, programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where a hardware module includes a programmable processor configured by software to become a special-purpose processor, the programmable processor may be configured as respectively different special-purpose processors (for example, including different hardware modules) at different times. Software may accordingly configure a particular processor or processors, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time. A hardware module implemented using one or more processors may be referred to as being "processor implemented" or "computer implemented.

Where multiple hardware modules exist contemporaneously, communications may be achieved through signal transmission (for example, over appropriate circuits and buses) between or among two or more of the hardware modules. In implementations in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory devices to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output in a memory device, and another hardware module may then access the memory device to retrieve and process the stored output.

In some examples, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. For example, at least some of the operations may be performed by, and/or among, multiple computers (as examples of machines including processors), with these operations being accessible via a communication network (for example, the Internet) and/or via one or more software interfaces (for example, an application program interface (API)). The performance of certain of the operations may be distributed among the processors, not only residing within a single machine, but deployed across a number of machines. Processors or processor-implemented modules may be located in a single geographic location (for example, within a home or office environment, or a server farm), or may be distributed across multiple geographic locations.

<FIG> is a block diagram <NUM> illustrating an example software architecture <NUM>, various portions of which may be used in conjunction with various hardware architectures herein described, which may implement any of the above-described features. <FIG> is a non-limiting example of a software architecture and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. A representative hardware layer <NUM> includes a processing unit <NUM> and associated executable instructions <NUM>. The executable instructions <NUM> represent executable instructions of the software architecture <NUM>, including implementation of the methods, modules and so forth described herein. The hardware layer <NUM> also includes a memory/storage <NUM>, which also includes the executable instructions <NUM> and accompanying data. The hardware layer <NUM> may also include other hardware modules <NUM>. Instructions <NUM> held by processing unit <NUM> may be portions of instructions <NUM> held by the memory/storage <NUM>.

The frameworks <NUM> (also sometimes referred to as middleware) provide a higher-level common infrastructure that may be used by the applications <NUM> and/or other software modules. For example, the frameworks <NUM> may provide various graphic user interface (GUI) functions, high-level resource management, or high-level location services. The frameworks <NUM> may provide a broad spectrum of other APIs for applications <NUM> and/or other software modules.

The applications <NUM> include built-in applications <NUM> and/or third-party applications <NUM>. Examples of built-in applications <NUM> may include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and/or a game application. Third-party applications <NUM> may include any applications developed by an entity other than the vendor of the particular platform. The applications <NUM> may use functions available via OS <NUM>, libraries <NUM>, frameworks <NUM>, and presentation layer <NUM> to create user interfaces to interact with users.

Some software architectures use virtual machines, as illustrated by a virtual machine <NUM>. The virtual machine <NUM> provides an execution environment where applications/modules can execute as if they were executing on a hardware machine (such as the machine <NUM> of <FIG>, for example). The virtual machine <NUM> may be hosted by a host OS (for example, OS <NUM>) or hypervisor, and may have a virtual machine monitor <NUM> which manages operation of the virtual machine <NUM> and interoperation with the host operating system. A software architecture, which may be different from software architecture <NUM> outside of the virtual machine, executes within the virtual machine <NUM> such as an OS <NUM>, libraries <NUM>, frameworks <NUM>, applications <NUM>, and/or a presentation layer <NUM>.

<FIG> is a block diagram illustrating components of an example machine <NUM> configured to read instructions from a machine-readable medium (for example, a machine-readable storage medium) and perform any of the features described herein. The example machine <NUM> is in a form of a computer system, within which instructions <NUM> (for example, in the form of software components) for causing the machine <NUM> to perform any of the features described herein may be executed. As such, the instructions <NUM> may be used to implement modules or components described herein. The instructions <NUM> cause unprogrammed and/or unconfigured machine <NUM> to operate as a particular machine configured to carry out the described features. The machine <NUM> may be configured to operate as a standalone device or may be coupled (for example, networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. Machine <NUM> may be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and/or entertainment system, a smart phone, a mobile device, a wearable device (for example, a smart watch), and an Internet of Things (IoT) device. Further, although only a single machine <NUM> is illustrated, the term "machine" include a collection of machines that individually or jointly execute the instructions <NUM>.

The machine <NUM> may include processors <NUM>, memory <NUM>, and I/O components <NUM>, which may be communicatively coupled via, for example, a bus <NUM>. The bus <NUM> may include multiple buses coupling various elements of machine <NUM> via various bus technologies and protocols. In an example, the processors <NUM> (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 712a to 712n that may execute the instructions <NUM> and process data. In some examples, one or more processors <NUM> may execute instructions provided or identified by one or more other processors <NUM>. The term "processor" includes a multi-core processor including cores that may execute instructions contemporaneously. Although <FIG> shows multiple processors, the machine <NUM> may include a single processor with a single core, a single processor with multiple cores (for example, a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, the machine <NUM> may include multiple processors distributed among multiple machines.

As used herein, "machine-readable medium" refers to a device able to temporarily or permanently store instructions and data that cause machine <NUM> to operate in a specific fashion. The term "machine-readable medium," as used herein, does not encompass transitory electrical or electromagnetic signals per se (such as on a carrier wave propagating through a medium); the term "machine-readable medium" may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible machine-readable medium may include, but are not limited to, nonvolatile memory (such as flash memory or read-only memory (ROM)), volatile memory (such as a static random-access memory (RAM) or a dynamic RAM), buffer memory, cache memory, optical storage media, magnetic storage media and devices, network-accessible or cloud storage, other types of storage, and/or any suitable combination thereof. The term "machine-readable medium" applies to a single medium, or combination of multiple media, used to store instructions (for example, instructions <NUM>) for execution by a machine <NUM> such that the instructions, when executed by one or more processors <NUM> of the machine <NUM>, cause the machine <NUM> to perform and one or more of the features described herein. Accordingly, a "machine-readable medium" may refer to a single storage device, as well as "cloud-based" storage systems or storage networks that include multiple storage apparatus or devices.

The I/O components <NUM> may include a wide variety of hardware components adapted to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components <NUM> included in a particular machine will depend on the type and/or function of the machine. For example, mobile devices such as mobile phones may include a touch input device, whereas a headless server or IoT device may not include such a touch input device. The particular examples of I/O components illustrated in <FIG> are in no way limiting, and other types of components may be included in machine <NUM>. The grouping of I/O components <NUM> are merely for simplifying this discussion, and the grouping is in no way limiting. In various examples, the I/O components <NUM> may include user output components <NUM> and user input components <NUM>. User output components <NUM> may include, for example, display components for displaying information (for example, a liquid crystal display (LCD) or a projector), acoustic components (for example, speakers), haptic components (for example, a vibratory motor or force-feedback device), and/or other signal generators. User input components <NUM> may include, for example, alphanumeric input components (for example, a keyboard or a touch screen), pointing components (for example, a mouse device, a touchpad, or another pointing instrument), and/or tactile input components (for example, a physical button or a touch screen that provides location and/or force of touches or touch gestures) configured for receiving various user inputs, such as user commands and/or selections.

In some examples, the communication components <NUM> may detect identifiers or include components adapted to detect identifiers. For example, the communication components <NUM> may include Radio Frequency Identification (RFID) tag readers, NFC detectors, optical sensors (for example, one- or multi-dimensional bar codes, or other optical codes), and/or acoustic detectors (for example, microphones to identify tagged audio signals). In some examples, location information may be determined based on information from the communication components <NUM>, such as, but not limited to, geo-location via Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and/or signal triangulation.

While various embodiments have been described, the description is intended to be exemplary, rather than limiting, and it is understood that many more embodiments and implementations are possible that are within the scope of the embodiments. Although many possible combinations of features are shown in the accompanying figures and discussed in this detailed description, many other combinations of the disclosed features are possible. Any feature of any embodiment may be used in combination with or substituted for any other feature or element in any other embodiment unless specifically restricted. Therefore, it will be understood that any of the features shown and/or discussed in the present disclosure may be implemented together in any suitable combination. Accordingly, the embodiments are not to be restricted except in light of the attached claims and their equivalents. Also, various modifications and changes may be made within the scope of the attached claims.

It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "a" or "an" does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

Claim 1:
A method for facilitating data communication comprising:
receiving, at a first network node device (<NUM>), via a local network interface (<NUM>), a first tunnel data packet (<NUM>) encapsulating a first payload (<NUM>) according to a first tunneling protocol (<NUM>), a second tunnel data packet (<NUM>) encapsulating a second payload (<NUM>) according to the first tunneling protocol (<NUM>), and a third tunnel data packet (<NUM>) encapsulating a third payload (<NUM>) according to a second tunneling protocol (<NUM>) that is different than the first tunneling protocol (<NUM>);
identifying a first tunnel session associated with the first tunnel data packet (<NUM>) and a second tunnel session associated with the third tunnel data packet (<NUM>) that is different than the first tunnel session;
generating and maintaining a first packet context for the first tunnel session based on at least the received first tunnel data packet (<NUM>), and a second packet context for the second tunnel session based on at least the received third tunnel data packet (<NUM>);
determining, based on at least the first packet context and the second tunnel data packet (<NUM>), that the second tunnel data packet (<NUM>) is for the first tunnel session;
in response to the determination that the second tunnel data packet (<NUM>) is for the first tunnel session, de-encapsulating the second payload (<NUM>) from the second tunnel data packet (<NUM>) in accordance with the first tunneling protocol (<NUM>);
in response to the determination that the third tunnel data packet (<NUM>) is for the second tunnel session, de-encapsulating the third payload (<NUM>) from the third tunnel data packet (<NUM>) in accordance with the second tunneling protocol (<NUM>); and
submitting the second payload (<NUM>) and the third payload (<NUM>) to a common acceleration and optimization processor (<NUM>) of the first network node device (<NUM>).