Patent Description:
Further background is provided in the following documents.

<CIT> discloses a network element that is configured for receiving, from an access point, a data packet originating from a client, the data packet comprising a packet header that comprises a packet header augmented with context information; decapsulating the packet header to identify the context information; applying a client-specific policy on the packet based, at least in part, on the context information; and forwarding the packet to a next hop in the network. The network element can be part of a network, such as a datacenter fabric architecture.

<CIT> discloses methods and apparatus for integrating VLAN-unaware devices into VLAN-enabled networks. For example, a method of assigning a virtual local area network identifier (VID) to a data unit may include receiving a data unit encapsulated in a wireless header from a source host via a wireless access point, wherein the data unit is addressed to a target host. A VID is determined based at least in part on an identifier of a wireless network included in the wireless header, and the VID is assigned to the data unit.

<CIT> discloses a symmetric flow response path from an Autonomous System (AS) which can be forced by using a same edge gateway for ingress and egress of communications with an Internet source. An asymmetric flow response path from an AS can be used by using different edge gateways for ingress and egress of communications with an Internet source. An anycast IP address can be used for selecting egress edge gateways of an AS. Packets in an AS can be redirected to selected egress edge gateways of the AS.

<NPL>, discloses "The Arista VXLAN Pseudowire Solution" and outlines advantages which enable enables organizations to leverage cost effective and efficient methods to meet a variety of requirements and modernize their networks.

There is provided a method for processing network traffic data units as set out in Claim <NUM>.

There is also provided a method for processing network traffic data units as set out in Claim <NUM>.

There is further provided a wireless access point as set out in Claim <NUM>.

In to the following, there is disclosed a method for processing network traffic data units (NTDUs). The method includes receiving, by a wireless access point (WAP), a NTDU from a client device, identifying a virtual tunnel upon which to transmit the NTDU, wherein the virtual tunnel is associated with a network device, and transmitting, via the virtual tunnel, the NTDU to the network device.

In general, implementations relate to a method for processing network traffic data units (NTDUs). The method includes receiving, by a network device, an encapsulated NTDU from a wireless access point (WAP) via a virtual tunnel, obtaining the NTDU from the encapsulated NTDU, and processing the NTDU by the network device.

In general, implementations relate to a wireless access point (WAP) comprising a processor, an antenna, a physical network interface, and memory comprising computer readable program code, wherein when computer readable program code is executed by the processor, the WAP performs a method, the method comprising receiving, via the antenna, a network traffic data unit (NTDU) from a client device, identifying a virtual tunnel upon which to transmit the NTDU, wherein the virtual tunnel is associated with a network device, and transmitting, via the virtual tunnel and the physical network interface, the NTDU to the network device.

Specific embodiments will now be described with reference to the accompanying figures. In the following description, numerous details are set forth as examples of the invention.

Certain details known to those of ordinary skill in the art may be omitted to avoid obscuring the description.

Further, in the following description of the figures, any component described with regard to a figure, in various embodiments of the invention, may be equivalent to one or more like-named components shown and/or described with regard to any other figure.

In general, embodiments of the invention relate to systems and methods for receiving and processing network traffic data units (NTDUs). Specifically, embodiments of the invention relate to processing NTDUs received by wireless access points (WAPs) and then transmitting the received NTDUs, via a virtual tunnel, to a network device in a network. The network devices may then decapsulate and process the NTDUs, where the processing may include further encapsulation of the NTDUs within the network to transmit the NTDU to the appropriate virtual endpoint (VEP). Depending on the configuration of the network, the VEP may be in the same domain (e.g., same layer-<NUM> domain), or in a different domain, than the network device that received the NTDU from the WAP. Embodiments enable NTDUs from WAPs to be transmitted to a network (e.g., an edge of a network) without requiring the WAP to participate in any learning about the location of destinations within the network. In this manner, various embodiments of the invention may utilize encapsulation from the WAP through to the ultimate destination of the NTDU without the WAP experiencing any overhead related to "learning" about the network.

In one or more embodiments of the invention, a NTDU is any relevant data that is transmitted in a format dictated by any one or more network protocols or standards over any wired or wireless transmission medium (or any combination thereof). Examples of such protocols or standards include, but are not limited to, Internet Protocol (IP), Media Access Control (MAC), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Infiniband, Hypertext Transfer Protocol (HTTP), the IEEE <NUM> family of protocols, etc. In one or more embodiments of the invention, the relevant data is at least a portion of the payload of a NTDU of any format.

<FIG> shows a system in accordance with one or more embodiments of the invention. As shown in <FIG>, the system includes one or more client devices (100A, 100N), one or more network devices (e.g., network device A (<NUM>), network device B (<NUM>), network device C (<NUM>), and network device D (<NUM>)), a WAP (<NUM>), and one or more local devices (e.g., local device (<NUM>). Each of these components is described below.

In one or more embodiments of the invention, one or more client devices (100A, 100N), may be implemented as computing devices. In one or more embodiments of the invention, a computing device is any device or any set of devices capable of electronically processing instructions and that includes, at least, one or more processors, memory, input and output device(s), and operative network connectivity to one or more network devices or one or more WAPs. Examples of computing devices include, but are not limited to, a server (e.g., a blade-server in a blade-server chassis, a rack server in a rack, etc.), a virtual machine (VM), a desktop computer, a mobile device (e.g., laptop computer, smart phone, personal digital assistant, tablet computer and/or any other mobile computing device), a network device (e.g., switch, router, multi-layer switch, etc.) and/or any other type of computing device with the aforementioned requirements.

In one embodiment of the technology, one or more client devices (100A, 100N) includes functionality to communicate with one or more WAPs (e.g., <NUM>). Communicating with the WAPs may include functionality to send NTDUs to the resource WAP (<NUM>) and to receive NTDUs from the WAP (<NUM>).

In one or more embodiments of the invention, a network device (e.g., <NUM>, <NUM>, <NUM>, <NUM>) may be a physical device that includes, but is not limited to, all or any subset of the following: persistent storage (not shown), memory (e.g., random access memory (RAM)) (not shown), one or more processor(s) (not shown), one or more network chips, one or more circuit components (e.g., wire, resistors, capacitors, transistors, inductors, integrated circuitry packages, printed circuit boards, diodes, comparators, etc.), one or more field programmable gate arrays (FPGAs), one or more application specific integrated circuits (ASICs), one or more complex programmable logic devices (CPLDs) and/or two or more physical network interfaces (which may also be referred to as ports). A network device may be connected to other devices via wired (e.g., using the ports) and/or wireless connections.

In one or more embodiments of the invention, the one or more network devices (<NUM>, <NUM>, <NUM>, <NUM>) include functionality to receive NTDUs at any of the physical network interfaces (i.e., ports) of the network device, and to subsequently transmit NTDUs from any of the physical network interfaces of the network device. The NTDU may be transmitted to other network devices and/or to client devices (not shown) connected to the network device. In one embodiment of the invention the network devices includes functionality to process NTDU in accordance with <FIG>.

Network devices may also include functionality to inspect all or certain portions of a NTDU in order to determine whether to: (i) drop the NTDU; (ii) process the NTDU (which may include encapsulation); and/or (iii) transmit the NTDU, based on the processing by network device, where the processing may be performed by a hardware component in the network device, software executing on the network device, or any combination thereof.

In one or more embodiments of the invention, the network device includes functionality to store (e.g., in persistent storage, in memory, in a register, etc.), any number of data structures (e.g., filtering information, buffering information, routing information base (RIB), queued and timestamped NTDUs, etc., forwarding information base (FIB), link state database, counters, etc.) for facilitating operation of at least some aspects of the network device.

Such structures may be stored in a data repository (not shown) included in and/or operatively connected to a network device. In one or more embodiments of the invention, a data repository is any type of storage unit(s) and/or device(s) (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data. Further, the data repository may include multiple different storage units and/or devices. The multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. In one or more embodiments of the invention, the network device data repository includes all or any portion of the persistent and/or non-persistent storage of the network device as described above.

Examples of network devices include, but are not limited to, a layer <NUM> network switch, a router, a multilayer switch, a fiber channel device, an InfiniBand® device, etc..

The local devices (e.g., <NUM>) may be implemented as network devices (described above) and/or computing devices (described above). The local devices include functionality to receive NTDUs with or without virtual local area network (VLAN) tags from the WAP (<NUM>).

A WAP (<NUM>) may be implemented as network device with one or more antennae. The antennae enables the WAP to receive and transmit NTDUs to one or more client devices (100A, 100N) over a wireless transmission medium. When sending and receiving NTDUs via the wireless transmission medium, the NTDUs may be transmitted in accordance with a wireless communication standard such as IEEE <NUM> family of protocols. Other wireless communication standards and/or protocols may be used without departing from the invention.

The WAP transmits NTDUs to, and receives NTDUs from, one or more local devices via one or more physical network interfaces (not shown) on the WAP. Further, the WAP transmits NTDUs to and receives NTDUs from one or more network devices (e.g., <NUM>, <NUM>, <NUM>, <NUM>).

The WAP (<NUM>) uses a virtual tunnel to transmit NTDUs to (and receive NTDUs from) network devices (<NUM>, <NUM>, <NUM>, <NUM>). For example, a virtual end point (<NUM>) executing (or otherwise implemented on the WAP) may encapsulate the NTDU using an encapsulation protocol (e.g., virtual extensible local area network (VXLAN), generic routing encapsulation (GRE), multiprotocol label switching (MPLS), etc.) and then transmit the encapsulated NTDU to a network device. Unlike standard encapsulation, which requires that the encapsulated NTDU is transmitted to a network device that is locally connected to the destination of the NTDU, the encapsulation and transmission by the WAP transmits the NTDU to a preconfigured destination (i.e., to a specific network device) regardless of the actual destination of the NTDU.

The network device, as described below in <FIG>, may then further process the NTDU to transmit it towards its ultimate destination (which may or may not include encapsulation). In one embodiment of the invention, the network device (e.g., <NUM>) that received the encapsulated from the WAP includes a VEP (e.g., <NUM>) that decapsulates the encapsulated NTDU received over the virtual tunnel. Unlike the VEP executing on the WAP, the VEP (e.g., <NUM>, <NUM>) executing on the network devices include functionality to "learn" destinations associated with the operatively connected network devices (e.g., <NUM>, <NUM>, <NUM>, <NUM>). In one embodiment of the invention, the VEPs (e.g., <NUM>, <NUM>) executing on the network devices are virtual tunnel end points (VTEPs) that implement the VXLAN protocol. The VEPs may implement other encapsulation protocols (e.g., GRE, MPLS) without departing from the invention. Additional detail about the functionality of the various VEPs is provided in <FIG> and <FIG>.

In one embodiment of the invention, the network devices (e.g., <NUM>, <NUM>, <NUM>, <NUM>) the may be in the same domain (e.g., layer-<NUM> domains; Domain X in <FIG>), in different domains (not shown), or a combination thereof (not shown). The manner in which NTDUs are transmitted between the various network devices depends on the domain(s) in which the network device resides as well as how the network devices are connected. For example, the NTDUs that are transmitted between the network devices may be encapsulated or unencapsulated even when the network devices are in the same domain. When the network devices (e.g., <NUM>, <NUM>) are locally connected (e.g., there is direct physical connection between the network devices), then the NTDUs may be transmitted without encapsulation. However, when the network devices (e.g., <NUM>, <NUM>) are not locally connected but within the same domain, then in accordance with one or more embodiments of the invention the NTDUs are transmitted as encapsulated NTDUs. Additional detail is provided below with respect to <FIG>.

Any above-described system component may also include software and/or firmware stored in any data repository (not shown) and/or memory (not shown) (i.e., non-transitory computer readable mediums). Such software and/or firmware may include instructions which, when executed by one or more processors (not shown) included in and/or operatively connected to the component, cause the one or more processors to perform all or a portion of the methods/functionality described in this application in accordance with one or more embodiments of the invention.

The instructions may be in the form of computer readable program code to perform embodiments of the invention, and may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions may correspond to computer readable program code that when executed by a processor(s), is configured to perform functionality related to embodiments of the invention.

While <FIG> shows a configuration of components, other configurations may be used without departing from the scope of the invention. For example, there may be any number of client devices, WAPs, network devices, local devices, etc., which may be arranged in any manner. Accordingly, embodiments disclosed herein should not be limited to the configuration of components shown in <FIG>.

<FIG> show flowcharts in accordance with one or more embodiments of the invention. While the various steps in the flowcharts are presented and described sequentially, one of ordinary skill in the relevant art will appreciate that some or all of the steps may be executed in different orders, may be combined or omitted, and some or all steps may be executed in parallel. In one embodiment of the invention, the steps shown in <FIG> may be performed in parallel with any other steps shown in <FIG> without departing from the scope of the invention.

<FIG> shows a method for transmitting NTDUs in accordance with one or more embodiments of the invention. The method shown in <FIG> may be performed, for example, by a WAP.

Turning to <FIG>, in step <NUM>, a NTDU is received by a WAP from a client device. The client device may receive the NTDU via an antenna on the WAP.

In step <NUM>, the NTDU is analyzed to determine whether to: (i) transmit the NTDU to a local device (see e.g., <FIG>, <NUM>) or (ii) to transmit the NTDU to a network device via a virtual tunnel. The analysis about whether to select option (i) or (ii) may be performed using at least a portion of the contents of a header of the NTDU. For example, the WAP may use the source internet protocol (IP) address, the destination IP address, a tag within the header of the NTDU, any other portion of the header of the NTDU, or any combination thereof to make the aforementioned determination.

Continuing with the discussion of step <NUM>, the analysis may use the aforementioned contents of the header of the NTDU in order to determine: (a) that the NTDU should be sent via a physical network interface to a local device; (b) that the NTDU should be tagged with an appropriate VLAN tag and then sent via a physical network interface to a local device; or (c) that the NTDU should be sent via a virtual tunnel to a network device.

With respect to (c), as discussed above, the WAP may encapsulate and transmit the NTDU to a network device via a virtual tunnel. The virtual tunnel that is used to transmit the encapsulated NTDU to the network device is a point-to-point virtual tunnel. Said another way, the virtual tunnel is pre-configured between the WAP and a particular network device such that all encapsulated NTDUs that are transmitted in the tunnel will reach the particular network device, regardless of the content of the header of the NTDU. In one embodiment of the invention, the virtual tunnel between the WAP and the particular network device may be implemented as a VXLAN pseudowire. The aforementioned virtual tunnel may implemented using other protocols without departing from the invention.

If, based on the above analysis, the NTDU is to be transmitted to the network device via a virtual tunnel, then a determination is made about which virtual tunnel to use for the transmission of the NTDU; said another way, virtual tunnel is identified. If there is only one configured virtual tunnel then the NTDU is transmitted via this virtual tunnel. However, if there are multiple virtual tunnels, then the WAP may implement a policy to select a virtual tunnel of the set of virtual tunnels to use to transmit the NTDU.

In this scenario, the WAP, using the header of the NTDU (or a portion thereof) may select a particular virtual tunnel from the set of available virtual tunnels based on a policy. In one embodiment of the invention, the policy may be implemented as a look-up table, where the policy maps portions of the header of the NTDU to a given virtual tunnel. For example, NTDUs with source IP addresses within a first range may be transmitted to a first network device via a first virtual wire while NTDUs with source IP addresses within a second range may be transmitted to a second network device via a second virtual wire. The invention is not limited to the aforementioned policy; rather, any policy may be used to select a virtual wire upon which to transmit the NTDU. Further, there may be any number of pre-configured virtual tunnels that connect the WAP to one or more network devices, where the network devices may be the same or different domains. The virtual tunnel is identified using metadata associated with the NTDU that is to be transmitted via the virtual tunnel. The metadata includes, at least one of (i) the wireless frequency (also referred to as a wireless frequency band) (e.g., <NUM>, <NUM>, etc.) over which the NTDU was transmitted from the client to the WAP; (ii) the wireless channel (i.e., the portion of the wireless frequency band) over which the NTDU was transmitted from the client to the WAP; and (iii) a service set identifier (SSID) of the wireless network over which the NTDU was transmitted from the client to the WAP. The metadata may include, but is not limited to, (iv) client vendor/brand, (v) client device type, (vi) current operating system version executing on the client, (vii) authentication state (e.g., authenticated or unauthenticated) of the client, and/or (viii) authentication method being implemented on the client.

Continuing with the discussion of <FIG>, in step <NUM>, if the NTDU is to be transmitted to a network device via a virtual tunnel, then the NTDU is encapsulated and transmitted from the VEP of the WAP to a VEP of network device via the identified virtual tunnel. Though not shown in <FIG>, if the NTDU is to be transmitted to a local device, then the NTDU is transmitted (with or without a VLAN tag) to the local device.

<FIG> shows a method for processing NTDUs by a network device in accordance with one or more embodiments of the invention. The method shown in <FIG> may be performed by any network device upon receipt of an encapsulated NTDU via virtual tunnel that originated from a WAP.

Turning to <FIG>, in step <NUM>, the encapsulated NTDU is received from the WAP by the network device via the virtual tunnel.

In step <NUM>, the encapsulated NTDU is decapsulated to obtain the NTDU.

In step <NUM>, a determination is made as to whether the NTDU is to be routed or bridged. This determination may be made based the contents of at least a portion of the header of the NTDU. For example, if the NTDU is a frame, then the determination in step <NUM> may be based on analyzing the destination media access control (MAC) address of the NTDU. If, based on the analysis, the NTDU needs to be routed (e.g., because the destination of the NTDU is in a different L2 domain than the L2 domain of the network device that received the NTDU), then process proceeds to step <NUM>; otherwise, the NTDU needs to be bridged (e.g., because the destination of the NTDU is in the same L2 domain as the network device that received the NTDU) and the process proceeds to step <NUM>.

While the NTDU is to be bridged, the NTDU destination may be associated with a locally connected network device or a remotely connected network device that is in the same domain. Accordingly, in step <NUM> a determination is made about whether the NTDU destination is reachable via a locally connected network device. If the NTDU destination is reachable via a locally connected network device, then the process proceeds to step <NUM>; otherwise, the process proceeds to step <NUM>.

In one or more embodiments, the aforementioned determination is required to be made for bridging scenarios because the network device that received the NTDU from the WAP may be not be locally connected to the NTDU destination. Said another way, while the WAP uses encapsulation to transmit the NTDU to the network device, because the WAP transmits the NTDU using a virtual tunnel that is preconfigured to, regardless of the destination of the NTDU, transmit the NTDU to a preconfigured network device. As a result, and contrary to the operation of other encapsulation schemes (e.g., VXLAN, GRE), the NTDU does not reach the network device that is locally connected to the NTDU destination. Accordingly, and again contrary to the operation of other encapsulation schemes (e.g., VXLAN, GRE), the network device may need to reencapsulate the NTDU for transmission within the same layer-<NUM> domain.

In step <NUM>, the network device bridges the NTDU towards the NTDU destination. In one embodiment of the invention, the NTDU is bridged to a locally connected network device without a VLAN tag. In another embodiment of the invention, the NTDU is bridged to a locally connected computing device once a VLAN tag is added to the NTDU.

Returning to step <NUM>, if the NTDU needs to be routed or bridged to non-locally connected network device, then in step <NUM>, the NTDU is processed to obtain an encapsulated NTDU. However, the processing and encapsulation of the NTDU varies based on the whether the NTDU is to be routed or bridged.

If the NTDU is to be routed, then the header of the NTDU is used to route the NTDU to the appropriate domain. For example, the destination IP address in the NTDU is used to determine where to route the NTDU. The contents of the encapsulated NTDU is then generated based on where the NTDU is being routed. For example, if the encapsulation is performed in accordance with the VXLAN protocol, then the header of the encapsulated NTDU may include a VNI for the domain in which the NTDU destination is located as well as the VTEP IP address of a VTEP in the aforementioned layer-<NUM> domain.

However, if the NTDU is to be bridged, then a lookup is performed to identify the destination VEP (e.g., a destination VTEP) on a network device from which the NTDU may be locally bridged to the NTDU destination. Unlike the routing scenario, the destination VEP is in the same layer-<NUM> domain as the source VEP (i.e., the VEP that is on the network device that initially received the NTDU from the WAP). Based on the result of the lookup, the contents of the encapsulated NTDU is then generated. For example, if the encapsulation is performed in accordance with the VXLAN protocol, then the header of the encapsulated NTDU may include a VNI of the current layer-<NUM> domain as well as the VTEP IP address of the aforementioned destination VTEP.

In step <NUM>, the encapsulated NTDU generated in step <NUM> is transmitted towards the NTDU destination.

<FIG> show an example in accordance with one or more embodiments of the invention.

Referring to <FIG>, consider a scenario for processing NTDUs in which a client device (<NUM>) is communicating over a wireless transmission medium with a WAP (<NUM>). The WAP (<NUM>) is operatively connected to network device A (<NUM>) and a local device (<NUM>). The network device A (<NUM>) is operatively connected to network device C (<NUM>).

The following describes a scenario for transmitting and processing of NTDUs in the aforementioned system.

Turning to the example, (<NUM>) the WAP (<NUM>) receives the NTDU from a client device (<NUM>).

Referring to <FIG>, the following describes another scenario for transmitting and processing of NTDUs in the aforementioned system.

Claim 1:
A method for processing network traffic data units, NTDUs, comprising the steps of:
receiving, by a wireless access point, WAP, (<NUM>) a NTDU from a client device (100A);
identifying, by the WAP, a pre-configured virtual tunnel upon which to transmit the NTDU, wherein the identified pre-configured virtual tunnel is associated with a network device (<NUM>); and
transmitting, by the WAP, via the identified pre-configured virtual tunnel, the NTDU to the network device (<NUM>),
wherein identifying the pre-configured virtual tunnel comprises using metadata associated with the NTDU to select the pre-configured virtual tunnel from a set of one or more available pre-configured virtual tunnels, and
wherein the metadata associated with the NTDU specifies at least one of: a wireless channel over which the NTDU was transmitted to the WAP (<NUM>), a service set identifier, SSID, associated with a wireless network over which the NTDU was transmitted to the WAP (<NUM>), and a wireless frequency over which the NTDU was transmitted to the WAP (<NUM>).