Methods for network traffic presteering and devices thereof

Abstract

Methods, non-transitory computer readable media, and traffic manager computing devices that forward a request to resolve a domain name from a client device to a Domain Name System (DNS) server device and a response from the DNS server device including an original Internet Protocol (IP) address corresponding to the domain name to the client device. Content is retrieved from a location associated with the domain name in response to a request for the content received from the client device. Classification information comprising at least a type of the retrieved content is determined. The retrieved content is sent to the client device in response to the request for the content. A determination is made when a confidence threshold has been exceeded based on the classification information. A steering endpoint IP address is sent to the DNS server device, when the determining indicates that the confidence threshold has been exceeded.

Description

FIELD

This technology relates to network traffic management and, more particularly, to methods and devices for presteering network traffic to facilitate optimization of content corresponding to the network traffic.

BACKGROUND

In many communication service provider networks, it is advantageous to steer a subset of the overall subscriber traffic to value-added service (VAS) server devices that can process the traffic based upon a classification of the traffic. By way of example only, traffic associated with video type content can be steered through a VAS server device with a video optimizer application that can process or optimize the content prior to forwarding the content to requesting client devices.

Currently, in order to retrieve content, a client device can request that a Domain Name System (DNS) server device resolve a domain name and receive an Internet Protocol (IP) address in response. With the IP address, the client device can establish a connection with a server device and request the content. Upon the content being sent to the client device from the server device, the content and associated domain name can be classified (e.g., as video type content). Thereafter, requests for content associated with the domain name can be steered based on the classification.

However, this process is repeated for subsequent requests for content associated with the domain name from other client devices. Since the classification can only occur subsequent to retrieved content being classified, initial requests by the other client devices for the content associated with the domain name will not be steered, which is undesirable.

SUMMARY

A method for network traffic presteering includes forwarding, by a traffic manager computing device, a request to resolve a domain name from a client device to a Domain Name System (DNS) server device and a response from the DNS server device including an original Internet Protocol (IP) address corresponding to the domain name to the client device. Content is retrieved, by the traffic manager computing device, from a location associated with the domain name in response to a request for the content received from the client device. Classification information comprising at least a type of the retrieved content is determined by the traffic manager computing device. The retrieved content is sent, by the traffic manager computing device, to the client device in response to the request for the content. A determination is made, by the traffic manager computing device, when a confidence threshold has been exceeded based on the classification information. At least a steering endpoint IP address, identified based on the type of the retrieved content, is sent, by the traffic manager computing device, to the DNS server device, when the determining indicates that the confidence threshold has been exceeded.

A traffic manager computing device includes a processor and a memory coupled to the processor which is configured to be capable of executing programmed instructions comprising and stored in the memory to forward a request to resolve a domain name from a client device to a DNS server device and a response from the DNS server device including an original IP address corresponding to the domain name to the client device. Content is retrieved from a location associated with the domain name in response to a request for the content received from the client device. Classification information comprising at least a type of the retrieved content is determined. The retrieved content is sent to the client device in response to the request for the content. A determination is made when a confidence threshold has been exceeded based on the classification information. At least a steering endpoint IP address, identified based on the type of the retrieved content, is sent to the DNS server device, when the determining indicates that the confidence threshold has been exceeded.

A non-transitory computer readable medium having stored thereon instructions for network traffic presteering comprising executable code which when executed by a processor, causes the processor to perform steps including forwarding a request to resolve a domain name from a client device to a DNS server device and a response from the DNS server device including an original IP address corresponding to the domain name to the client device. Content is retrieved from a location associated with the domain name in response to a request for the content received from the client device. Classification information comprising at least a type of the retrieved content is determined. The retrieved content is sent to the client device in response to the request for the content. A determination is made when a confidence threshold has been exceeded based on the classification information. At least a steering endpoint IP address, identified based on the type of the retrieved content, is sent to the DNS server device, when the determining indicates that the confidence threshold has been exceeded.

A method for network traffic presteering includes receiving, by a Domain Name System (DNS) server device, a request originating from a client device to resolve an original Internet Protocol (IP) address of a domain name included in the request. A determination is made, by the DNS server device, when a steering endpoint IP address corresponding to the original IP address is stored. The corresponding steering endpoint IP address is sent, by the DNS server device, to the client device in response to the request, when the determining indicates that the steering endpoint IP address corresponding to the original IP address is stored. The original IP address is resolved, by the DNS server device, and sent to the client device in response to the request, when the determining indicates that the steering endpoint IP address corresponding to the original IP address is not stored.

A Domain Name System (DNS) server device includes a processor and a memory coupled to the processor which is configured to be capable of executing programmed instructions comprising and stored in the memory to receive a request originating from a client device to resolve an original IP address of a domain name included in the request. A determination is made when a steering endpoint IP address corresponding to the original IP address is stored. The corresponding steering endpoint IP address is sent to the client device in response to the request, when the determining indicates that the steering endpoint IP address corresponding to the original IP address is stored. The original IP address is resolved and sent to the client device in response to the request, when the determining indicates that the steering endpoint IP address corresponding to the original IP address is not stored.

A non-transitory computer readable medium having stored thereon instructions for network traffic presteering comprising executable code which when executed by a processor, causes the processor to perform steps including receiving a request originating from a client device to resolve an original IP address of a domain name included in the request. A determination is made when a steering endpoint IP address corresponding to the original IP address is stored. The corresponding steering endpoint IP address is sent to the client device in response to the request, when the determining indicates that the steering endpoint IP address corresponding to the original IP address is stored. The original IP address is resolved and sent to the client device in response to the request, when the determining indicates that the steering endpoint IP address corresponding to the original IP address is not stored.

This technology has a number of associated advantages including providing methods, non-transitory computer readable media, traffic manager computing devices, and DNS server devices that facilitate more efficient and effective presteering of network traffic to optimization devices prior to delivery to requested client devices. With this technology, DNS is used to route network traffic associated with previously classified domain names to value-added service (VAS) server devices that optimize the content associated with the network traffic. Accordingly, client devices can advantageously receive presteered, optimized content relatively quickly.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a block diagram of a network environment with an exemplary traffic manager computing device, an exemplary local Domain Name System (DNS) server device, an exemplary steering endpoint device, and an exemplary value-added service (VAS) server device;

FIG. 2 is a block diagram of the exemplary traffic manager computing device shown in FIG. 1;

FIG. 3 is a block diagram of the local DNS server device;

FIG. 4 is a flowchart of an exemplary method for facilitating network traffic presteering with the exemplary traffic manager computing device;

FIG. 5 is a flowchart of an exemplary method for steering client device requests with the exemplary local DNS server device;

FIG. 6 is a flowchart of an exemplary method for processing client device requests with the exemplary steering endpoint device;

FIG. 7 is a flowchart of an exemplary method for processing client device requests with the exemplary VAS server device; and

FIG. 8 is a timing diagram illustrating an exemplary method for network traffic presteering.

DETAILED DESCRIPTION

Referring to FIG. 1, a block diagram is shown including an exemplary network environment 10 which incorporates a traffic manager computing device 12, such as a policy enforcement manager (PEM) device by way of example only, coupled to a local Domain Name System (DNS) server device 14, a steering endpoint device 16 coupled to a value-added service (VAS) server device 18, a plurality of client devices 20(1)-20(2) by an access network 22, and a plurality of server devices 24(1)-24(n) by a provider network 26 and the Internet 28, although one or more of these devices can be coupled together via other topologies. Additionally, the network environment 10 may include other network devices such as one or more routers and/or switches, by way of example only, which are known to those skilled in the art and will not be described here. This technology provides a number of advantages including methods, non-transitory computer readable media, and traffic manager computing and local DNS server devices that presteer requests for content associated with previously classified domains through VAS server devices allowing for optimized content to be returned in response.

Referring to FIGS. 1-2, the traffic manager computing device 12 may perform any number of functions including providing services based on subscriber application usage, classifying network traffic, regulating network usage, implementing tailored service plans, managing bandwidth consumption and network capacity, and reducing network congestion, by way of example only. The traffic manager computing device 12 includes a processor 30, a memory 32, and a communication interface 34 which are coupled together by a bus or other communication link, although the traffic manager computing device 12 may include other types and/or numbers of elements in other configurations.

The processor 30 of the traffic manager computing device 12 may execute programmed instructions stored in the memory 32 of the traffic manager computing device 12 for the any number of the functions identified above and described and illustrated herein. The processor 30 of the traffic manager computing device 12 may include one or more CPUs or general purpose processors with one or more processing cores, by way of example only.

The memory 32 of the traffic manager computing device 12 stores these programmed instructions for one or more aspects of the present technology, as described and illustrated herein, although some or all of the programmed instructions could be stored and executed elsewhere. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk, or other computer readable media which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor 30, can be used for the memory 32.

In this example, the memory 32 includes a steering endpoint Internet Protocol (IP) address table 38 and a classification information table 40. The steering endpoint IP address table 38 stores IP addresses for steering endpoints, which can correspond with virtual servers hosted by the steering endpoint device 16, by way of example only. Accordingly, the traffic manager computing device 12 uses the steering endpoint IP address table 38 to identify available and appropriate steering endpoint IP address to send to the local DNS server device 14, as described and illustrated in more detail later.

The classification information table 40 includes per-domain name information regarding the type of content retrieved and the number of times content of a certain type has been observed by the traffic manager computing device 12, by way of example only. Additionally, the classification information table 40 in this particular example includes an indication of whether a domain name has been classified for a specific one of the client devices 20(1)-20(n). The traffic manager computing device 12 uses the classification information table 40 to determine when a confidence threshold has been exceeded such that all subsequent first requests for content associated with a domain name from one or more of the client devices 20(1)-20(n) should be presteered, as described and illustrated in more detail later.

The communication interface 34 in the traffic manager computing device 12 operatively couples and communicates between the traffic manager computing device 12 and at least the client devices 20(1)-2(n), server devices 24(1)-24(n), local DNS server device 14, and VAS server device 18, which are all coupled together by the access network 22, provider network 26, and the Internet 28, although other types and/or numbers of communication networks or systems with other types and/or numbers of connections and configurations to other devices and elements can also be used.

By way of example only, the access network 22, provider network 26, and/or Internet 28 can use TCP/IP over Ethernet and industry-standard protocols, although other types and/or numbers of communication networks, can be used. The access network 22, provider network 26, and/or Internet 28 in this example may employ any suitable interface mechanisms and network communication technologies including, by way of example only, teletraffic in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Ethernet-based Packet Data Networks (PDNs), combinations thereof, and the like.

Referring to FIGS. 1-3, the local DNS server device 14 may perform any number of functions including receiving domain names from the client devices 20(1)-20(n) and returning IP addresses to the client devices 20(1)-20(n), by way of example only. In other examples, the traffic manager computing device 12 and local DNS server device 14 can be located on the same physical device in the network environment 10. The local DNS server device 14 in this example includes a processor 42, a memory 44, and a communication interface 46, which are coupled together by a bus or other communication link, although the local DNS server device 14 may include other types and/or numbers of elements in other configurations.

The processor 42 of the local DNS server device 14 may execute programmed instructions stored in the memory 44 of the local DNS server device 14 for the any number of the functions identified above and described and illustrated herein. The processor 42 of the local DNS server device 14 may include one or more CPUs or general purpose processors with one or more processing cores, by way of example only.

The memory 44 of the local DNS server device 14 stores these programmed instructions for one or more aspects of the present technology, as described and illustrated herein, although some or all of the programmed instructions could be stored and executed elsewhere. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk, or other computer readable media which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor 42, can be used for the memory 44.

In this particular example, the memory 44 includes an IP address mapping table 52. The IP address mapping table 52 stores original IP addresses and/or domain names corresponding with steering endpoint IP address, as received from the traffic manager computing device 12, as described and illustrated in more detail later. Accordingly, the local DNS server device 14 uses the IP address mapping table 52 to determine when a steering endpoint IP address has been previously stored for the domain name so that the local DNS server device 14 can resolve the domain name to the steering endpoint IP address and thereby steer requests from one of the client devices 20(1)-20(n) associated with the domain name through the steering endpoint device 16 and VAS server device 18.

The communication interface 46 in the local DNS server device 14 operatively couples and communicates between the local DNS server device 14 and at least the traffic manager computing device 12, which are all coupled together by the access network 22 in this example, although other types and/or numbers of communication networks or systems with other types and/or numbers of connections and configurations to other devices and elements can also be used.

The steering endpoint device 16 in this example includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other types and/or numbers of network devices could be used. The steering endpoint device 16 can host a plurality of virtual services each having an associated steering endpoint IP address and configured to forward certain requests received from the client devices 20(1)-20(n) through the VAS server device 18 to one or more of the server devices 24(1)-24(n) hosting the requested content.

The VAS server device 18 in this example includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other types and/or numbers of network devices could be used. The VAS server device 18 hosts application(s) configured to process or optimize content requested by the client devices 20(1)-20(n) such as a video optimizer application, by way of example only, although any other type of application can be used. Accordingly, the VAS server device 18 can receive client device requests from virtual servers hosted by the steering endpoint device 16 and forward the requests to appropriate ones of the server devices 24(1)-24(n). The responses from the server devices 24(1)-24(n) are routed back to through the VAS server device 18, the requested content is processed or optimized, and the processed or optimized content is then returned to the requesting ones of the client devices 20(1)-20(n), as described and illustrated in more detail later.

Each of the server devices 24(1)-24(n) includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other types and/or numbers of network devices could be used. Generally, the server devices 24(1)-24(n) process requests received from requesting client devices 20(1)-20(n) via the access network 22, the provider network 26, and the Internet 28 according to the HTTP-based application RFC protocol, by way of example only, and respond to the client devices 20(1)-20(n) with the requested content. The server devices 24(1)-24(n) may be hardware or software or may represent a system with multiple servers in a server device pool, which may include internal or external networks.

Each of the client devices 20(1)-20(n) in this example include a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other types and/or numbers of network devices could be used. The client devices 20(1)-20(n) may run interface applications, such as Web browsers by way of example only, that may provide an interface to make requests for and receive content stored on one or more of the server devices 24(1)-24(n) via the access network 22, the provider network 26, and the Internet 28. Each of the client devices 20(1)-20(n) may further include a display device, such as a display screen or touchscreen, and/or an input device, such as a keyboard by way of example only.

Although the exemplary network environment 10 with the traffic manager computing device 12, local DNS server device 14, steering endpoint device 16, VAS server device 18, client devices 20(1)-20(n), server devices 24(1)-24(n), access network 22, provider network 26, and the Internet 28 are described and illustrated herein, other types and/or numbers of systems, devices, components, and elements in other topologies can be used. The systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).

In addition, two or more computing systems or devices can be substituted for any one of the systems or devices in any example. Accordingly, principles and advantages of distributed processing, such as redundancy and replication also can be implemented, as desired, to increase the robustness and performance of the devices and systems of the examples. The examples may also be implemented on computer system(s) that extend across any suitable network using any suitable interface mechanisms and traffic technologies, including by way of example only teletraffic in any suitable form (e.g., voice and modem), wireless traffic media, wireless traffic networks, cellular traffic networks, G3 traffic networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, and combinations thereof.

The examples may also be embodied as non-transitory computer readable media having instructions stored thereon for one or more aspects of the present technology as described and illustrated by way of the examples herein, which when executed by a processor, cause the processor to carry out the steps necessary to implement the methods of the examples, as described and illustrated herein.

An exemplary method for network traffic presteering will now be described with reference to FIGS. 1-8. Referring more specifically to FIG. 4, an exemplary method for facilitating network traffic presteering with the traffic manager computing device 12 will now be described. In step 400 in this example, the traffic manager computing device 12 receives a request from one of the client devices 20(1)-20(n) to resolve a domain name and sends the request to the local DNS server device 14. The request can originate from a web browser executed on the one of the client devices 20(1)-20(n), by way of example only, in response to a user of the one of the client devices 20(1)-20(n) requesting content (e.g., a video file associated with the “www.onlinefishing.tv” domain name, as used in the example described and illustrated later with reference to FIG. 8).

In step 402, the traffic manager computing device 12 receives a response to the request from the local DNS server device 14, stores the domain name associated with an original IP address included in the response, and sends the response to the requesting one of the client devices 20(1)-20(n). The traffic manager computing device 12 can store the domain name as associated with the corresponding original IP address in an entry of the classification information table 40, by way of example only, although the domain name and original IP address can also be stored elsewhere.

In step 404, the traffic manager computing device 12 receives a request from the one of the client devices 20(1)-20(n) for content at a location associated with the domain name. In the example described and illustrated later with reference to FIG. 8, the content is at a “/video/free” location associated with the “www.onlinefishing.tv” domain name.

In step 406, the traffic manager computing device 12 determines whether the domain name was previously classified. Domain names can be classified for a specific one of the client devices 20(1)-20(n) even if a confidence threshold has not been exceeded for the domain name, as described and illustrated in more detail later. Domain names can be classified for one of the client devices 20(1)-20(n) based on an established policy and can be stored in the entry of the classification information table 40 for the domain name.

By way of example only, the traffic manager computing device 12 can classify a domain name for one of the client devices 20(1)-20(n) when a specified number of received requests associated with the domain name are for content of a specific type, such as video by way of example only. Accordingly, a first request for content associated with a domain name will not be previously classified since the requested content and associated characteristics have not been observed yet by the traffic manager computing device 12. However, if the request is a second or subsequent request for content associated with a domain name, and the traffic manager computing device 12 determines in step 406 that the domain name has been previously classified, then the Yes branch is taken to step 408.

In step 408, the traffic manager computing device 12 sends the request to the VAS server device 18 and forwards the content received from the VAS server device 18 back to the requesting one of the client devices 20(1)-20(n). The location or IP address of the VAS server device 18 can be stored in the memory 32 of the traffic manager computing device 12 as part of an initial configuration, by way of example only. In examples in which multiple VAS server devices are present in the network environment, the classification information table 40 can include an indication of the appropriate one of the VAS server devices for the classification associated with the domain name.

As described and illustrated in more detail later, the VAS server device 18 retrieves the requested content from one of the server devices 24(1)-24(n), processes or otherwise optimizes the content, and sends the processed or otherwise optimized content to the traffic manager computing device 12 for forwarding to the requesting one of the client devices 20(1)-20(n). Accordingly, the content returned to the one of the client devices 20(1)-20(n) in step 408 in this example is the processed or otherwise optimized content.

Referring back to step 406, if the traffic manager computing device 12 determines that the domain name has not been previously classified, then the No branch is taken to step 410. In step 410, the traffic manager computing device 12 retrieves the content from the one of the server devices 24(1)-24(n) hosting the content and sends the content to the requesting one of the client devices 20(1)-20(n).

Irrespective of whether the Yes or No branch is taken from step 406, and step 408 or 410 is performed, respectively, the traffic manager computing device 12 proceeds to step 412. In step 412, the traffic manager computing device 12 determines and stores classification information for the domain name in the classification table 40. Exemplary classification information can include the type of the content that was requested and/or a number of times content of the type has been requested from a location associated with the domain name, by way of example only, although other types and/or numbers of information can also be determined and stored in step 412.

By way of example only, the traffic manager computing device 12 may determine, such as from an HTTP header in the response by way of example only, that the requested content was of a video type. Accordingly, in step 412, the traffic manager computing device 12 may retrieve the entry for the domain name from the classification information table 40, determine that video type content has been previously requested and retrieved a specified number of times, and increment the number to reflect the most recent request for content of the video type from a location associated with the domain name.

In step 414, the traffic manager computing device 12 determines whether a confidence threshold has been exceeded based on the classification information stored in the classification information table 40 for the domain name. The traffic manager computing device 12 can determine whether a confidence threshold has been exceeded based on a stored policy. The determination is indicative of the likelihood that a subsequent request associated with the domain name will be for content of a certain type. By way of example only, the traffic manager computing device 12 can determine a confidence threshold has been exceeded when a specified number of the client devices 20(1)-20(n) have requested content of a certain type from location(s) associated with the domain name. In other examples, other types and/or numbers of classification information or other data can be used to determine whether a confidence threshold has been exceeded.

If the traffic manager computing device 12 determines that a confidence threshold has not been exceeded for the domain name, then the No branch is taken to step 416. In step 416, the traffic manager computing device 12 determines whether the domain name should be classified for the one of the client devices 20(1)-20(n) even though the confidence threshold has not been exceeded. In one example, the domain name can be classified based on a stored policy requiring a specified number of requests associated with the domain name for content of a certain type from the one of the client devices 20(1)-20(n), although the policy can utilize any other type or number of classification information.

If the traffic manager computing device 12 determines in step 416 that the domain name should be classified, then the Yes branch is taken to step 418. In step 418, the traffic manager computing device 12 updates the entry for the domain name in the classification information table 40 to indicate that the domain name is classified for the one of the client devices 20(1)-20(n) along with the classification such as video type content by way of example only.

Subsequent to updating the classification information, or if the traffic manager computing device 12 determines in step 416 that the domain name should not be classified and the No branch is taken, the traffic manager computing device 12 proceeds back to step 400 and another request from one of the client devices 20(1)-20(n) to resolve a domain name is received. In another example, the traffic manager computing device 12 can proceed back to step 404 and another request from the one of the client devices 20(1)-20(n) can be received for content at a location associated with the domain name. Since the one of the client devices 20(1)-20(n) already received the original IP address for the domain name in step 402, subsequent requests from the one of the client devices 20(1)-20(n) for content at locations associated with the domain name will not require that the domain name first be resolved by the local DNS server device and will therefore be received in step 404.

Referring back to step 414, if the traffic manager computing device 12 determines that the confidence threshold has been exceeded, then the Yes branch is taken to step 420. In step 420, the traffic manager computing device 12 sends a steering endpoint IP address to the local DNS server device 14. The steering endpoint IP address sent to the local DNS server device 14 can be retrieved by the traffic manager computing device 12 from the steering endpoint IP address table 38 stored in the memory 32. The steering endpoint IP address table 32 can store steering endpoint IP addresses corresponding with content classifications.

Accordingly, the traffic manager computing device 12 can query the steering endpoint IP address table 32 based on the classification of the content (e.g., video type content) to identify a corresponding steering endpoint IP address. The steering endpoint IP address can point to a virtual server hosted by the steering endpoint device 16, by way of example only. Subsequent requests from the client devices 20(1)-20(n) to resolve the domain name will result in the local DNS server device 14 returning the steering endpoint IP address instead of the original IP address, as described and illustrated in more detail later.

In step 422, the traffic manager computing device 12 determines whether the request received in step 404, and associated network traffic, is based on the HTTP protocol. If the traffic manager computing device 12 determines that the request conforms to the HTTP protocol, then the Yes branch is taken back to step 400 and another request from one of the client devices 20(1)-20(n) to resolve a domain name is received. Since the host header is a required header in the HTTP protocol, when a subsequent request for content at a location associated with the domain name is received from another one of the client devices 20(1)-20(n) by the steering endpoint device 16, the steering endpoint device 16 will be able to inspect the HTTP host header and resolve the IP destination to steer the request through the VAS server device 18 to the one of the server devices 24(1)-24(n) hosting the content, as described and illustrated in more detail later.

However, if the traffic manager computing device 12 determines in step 422 that the request is not an HTTP request, then the No branch is taken to step 424. In step 424, the traffic manager computing device 12 sends the original IP address to the steering endpoint device 16 associated with the steering endpoint IP address sent to the local DNS server device 14 in step 420. Accordingly, a subsequent non-HTTP request for content at a location associated with the domain name from another one of the client devices 20(1)-20(n) that is received by the steering endpoint device 16 will be able to be processed by the steering endpoint device 16 since the original IP address will be stored locally, as described and illustrated in more detail later. The original IP address can be retrieved from an entry of the classification information table 40 as stored as described and illustrated earlier with reference to step 402, although the original IP address can be obtained in other manners.

Subsequent to sending the original IP address to the steering endpoint device 16, the traffic manager computing device 12 proceeds back to step 400 and another request from one of the client devices 20(1)-20(n) to resolve a domain name is received. In another example, the traffic manager computing device 12 can proceed back to step 404 and receive another request from the one of the client devices 20(1)-20(n) for content at a location associated with the domain name. Although the domain name has been classified, the one of the client devices 20(1)-20(n) already has the original IP address and subsequent traffic will be steered through the VAS server device 18 by the traffic manager computing device 12, as described and illustrated earlier with reference to steps 406 and 408. However, requests for content at a location associated with the domain name by other of the client devices 20(1)-20(n) will be steered through the VAS server device 18 by the steering endpoint device 16, as described and illustrated in more detail later with reference to FIG. 6.

Referring more specifically to FIG. 5, an exemplary method for steering client device requests with the local DNS server device 14 will now be described. In step 500 in this example, the local DNS server device 14 receives a request from one of the client devices 20(1)-20(n) to resolve an IP address of a domain name included in the request. The request can be forwarded by the traffic manager computing device 14, as described and illustrated earlier with reference to step 400 of FIG. 4, by way of example only.

In step 502, the local DNS server device 12 determines whether a steering endpoint IP address corresponding to the original IP address of the domain name, or the domain name itself, has been previously received and stored locally, such as in the IP address mapping table 52 by way of example only, as described and illustrated in more detail later. The steering endpoint IP address could have been received by the local DNS server device 14 as sent by the traffic manager computing device 12, as described and illustrated in more detail earlier with reference to step 420 of FIG. 4, by way of example only. Accordingly, if the local DNS server device 14 determines that there is a corresponding steering endpoint IP address, then the Yes branch is taken to step 504.

In step 504, the local DNS server device 12 sends the corresponding steering endpoint IP address to the one of the client devices 20(1)-20(n) in response to the request. If there is a corresponding steering endpoint IP address, then the traffic manager computing device 12 previously determined that a confidence threshold was exceeded for the domain name and that associated request traffic should be sent to the steering endpoint device 16 to be steered through the VAS server device 18. Accordingly, the steering endpoint IP address is sent to the one of the client devices 20(1)-20(n) instead of the original IP address for the domain name. Subsequent to sending the corresponding steering endpoint IP address to the one of the client devices 20(1)-20(n), the local DNS server device 14 proceeds back to step 500 and another request to resolve a domain name is received from one of the client devices 20(1)-20(n).

However, if the local DNS server device 14 determines in step 502 that there is not a corresponding steering endpoint IP address for the domain name, then the No branch is taken to step 506. In step 506, the local DNS server device 14 resolves the domain name and sends the original IP address for the one of the client devices 20(1)-20(n) in response to the request. Optionally, the local DNS server device 14 can send the response including the original IP address to the traffic manager computing device 12 to be forwarded to the one of the client devices 20(1)-20(n), as described and illustrated in more detail earlier with reference to step 402 of FIG. 4.

Subsequent to resolving the domain name and sending the response including the original IP address, the local DNS server device 14 proceeds to step 508. In step 508, the local DNS server device 14 determines whether a steering endpoint IP address is received for the domain name from the traffic manager computing device 12. The steering endpoint IP address can be sent by the traffic manager computing device 12 as described and illustrated earlier with reference to step 420 of FIG. 4, by way of example only. If the local DNS server device 14 determines a steering endpoint IP address is not received for the domain name, then the No branch is taken back to step 500 and another request to resolve a domain name is received from one of the client devices 20(1)-20(n).

However, if the local DNS server device 14 determines in step 508 that a steering endpoint IP address has been received for the domain name, then the Yes branch is taken to step 510. In step 510, the steering endpoint IP address is stored as associated with the domain name and/or the original IP address corresponding to the domain name. The steering endpoint IP address can be stored in the IP address mapping table 52, by way of example only, although the steering endpoint IP address and corresponding domain name and/or original IP address can also be stored elsewhere. Accordingly, subsequent requests to resolve the domain name from another of the client devices 20(1)-20(n) will result in the local DNS server device 14 comparing the domain name, by way of example only, to the IP address mapping table 52 and retrieving and returning the steering endpoint IP address associated with the domain name in the IP address mapping table 52.

Referring more specifically to FIG. 6, an exemplary method for processing client device requests with the steering endpoint device 16 will now be described. In step 600 in this example, the steering endpoint device 16 receives a request for content from one of the client devices 20(1)-20(n). A request for content received from one of the client devices 20(1)-20(n) by the steering endpoint device 16 will have been sent by the one of the client devices 20(1)-20(n) after receiving a steering endpoint IP address in response to a request to resolve a domain name, as described and illustrated in more detail earlier with reference to step 504 of FIG. 5. Accordingly, the request received in step 600 is for content at a location associated with a domain name for which the confidence threshold has been exceeded. Additionally, the request can optionally be received by a virtual server hosted by the steering endpoint device 16 and one or more of the steps described and illustrated with reference to FIG. 6 can be performed by the virtual server.

In step 602, the steering endpoint device 16 determines whether the request is an HTTP request. If the steering endpoint device 16 determines that the request is an HTTP request, then the Yes branch is taken to step 604. In step 604, the steering endpoint device 16 resolves an original IP address for a domain name included in a host header of the request. The original IP address can be resolved by communicating with the local DNS server device 14 or another DNS server device, by way of example only, although other methods of resolving the original IP address can also be used.

Referring back to step 602, if the steering endpoint device 16 determines that the request is not an HTTP request, then the No branch is taken to step 606. In step 606, the steering endpoint device 16 retrieves an original IP address from local storage. The retrieved original IP address could have been sent to the steering endpoint device 16 by the traffic manager computing device 12, as described and illustrated earlier with reference to step 424 of FIG. 4, by way of example only.

Irrespective of whether the steering endpoint device 16 resolves or retrieves the original IP address in step 604 or 606, respectively, the steering endpoint device 16 proceeds to step 608. In step 608, the steering endpoint device 16 sends a request including the original IP address to the VAS server device 18 to be forwarded by the VAS server device 18 to one of the server devices 24(1)-24(n) hosting the requested content. The VAS server device 18 can forward the request to the appropriate one of the server devices 24(1)-24(n) using the original IP address. By sending the request through the VAS server device 18, the one of the server devices 24(1)-24(n) will respond to the VAS server device 18 with the content, as described and illustrated in more detail later. Subsequent to sending the request, the steering endpoint device 16 can proceed back to step 600 and receive another request for content from one of the client devices 20(1)-20(n).

Referring more specifically to FIG. 7, an exemplary method for processing client device requests with the VAS server device 18 will now be described. In step 700 in this example, the VAS server device 18 receives a request for content from the steering endpoint device 16 and forwards the request to one of the server devices 24(1)-24(n) located at an original IP address included in the received request. The request can be sent by the steering endpoint device 16, as described and illustrated earlier with reference to step 608 of FIG. 6, by way of example only.

In step 702, the VAS server device 18 can receive the content from the one of the server devices 24(1)-24(n) as sent in response to the forwarded request. In step 704, the VAS server device 18 can optimize the content. By way of example only, the VAS server device 18 can optimize video files for communication through the provider network 26 and the access network 22 to the requesting one of the client devices 20(1)-20(n), although other types of content can also be optimized and the VAS server device 18 can process the content in other ways. In step 706, the VAS server device 18 sends the optimized content to the requesting one of the client devices 20(1)-20(n). Accordingly, request traffic in this example can advantageously be steered through the VAS server device 18, and content sent in response can be optimized, subsequent to the traffic manager computing device 12 determining that a confidence threshold has been exceeded for the domain name associated with the content.

Referring more specifically to FIG. 8, a timing diagram illustrating an exemplary method for network traffic presteering will now be described. In step 800 in this example, a client device 20(1) (referred to as “Client 1” in this example) sends a request to the local DNS server device 14 (referred to as “GTM (LDNS)” in this example), optionally through the traffic manager computing device 12 (referred to as “PEM (FWD VS)” in this example), to resolve a domain name (“www.onlinefishing.tv” in this example). In step 802, the local DNS server 14 returns an original IP address (“78.109.162.156” in this example) to the client device 20(1).

In step 804, the client device 20(1) sends a request for content at a location (“/video/free” in this example) associated with the domain name to the traffic manager computing device 12. In this example, the request is an HTTP GET request, although other types of requests associated with other protocols can also be used. In step 806, the traffic manager computing device 12 forwards the request for content to the Internet 28 and one of the server devices 24(1)-24(n) (not shown) located at the original IP address included in the request for content.

In step 808, the traffic manager computing device 12 receives a response from the Internet 28, and the one of the server devices 24(1)-24(n), which includes the content and an indication of the content type (“video/mp4” in this example). In step 810, the traffic manager computing device 12 determines and stores classification information in an entry of the classification information table 40 for the domain name based on the information included in the response and forwards the response with the requested content to the client device 20(1).

In step 812, the client device 20(1) sends another request for content at a location (“/video/free2” in this example) associated with the domain name to the traffic manager computing device 12. Since the client device 20(1) previously resolved the original IP address for the domain name, the other request for content can be sent directly to the traffic manager computing device 12. In step 814, the traffic manager computing device 12 forwards the request for content directly to the VAS server device 18 (referred to as “Video Optimizer” in this example). Accordingly, in this example, the traffic manager computing device 12 also determined in step 810 that the domain name should be classified for the client device 20(1) as associated with video content based on the classification information indicating that video type content was retrieved from a location associated with the domain name one time by the client device 20(1).

In step 816, the VAS server device 18 forwards the request for content to the Internet 28 and one of the server devices 24(1)-24(n) associated with an original IP address included in the request for content. In step 818, the VAS server device 18 receives a response including the requested content from the Internet 28 and the one of the server devices 24(1)-24(n). In step 820, the VAS server device 18 optimizes the video content included in the response and sends the response with the optimized video content to the traffic manager computing device 12. In step 822, the traffic manager computing device 12 determines and stores classification information in the classification information table 40 based on the response and forwards the response with the optimized content to the client device 20(1).

In step 824, another client device 20(2) (referred to as “Client 1+n” in this example) sends a request to the local DNS server device 14 to resolve the same domain as included in the request sent in step 800 by the client device 20(1). In step 826, the local DNS server device 14 sends a steering endpoint IP address (“2.2.2.2” in this example) to the client device 20(2) in response.

Accordingly, the traffic manager computing device 12 previously determined, such as in step 822, by way of example only, or during any other sequence of servicing a request for the client device 20(1) or any number of other client devices for content at a location associated with the domain name, that the confidence threshold was exceeded and there was sufficient likelihood that content associated with the domain name is of the video type. Therefore, the traffic manager computing device 12 sent the steering endpoint IP address to the local DNS server device 14 so that the local DNS server device 14 would steer request traffic associated with the domain name to the steering endpoint device 16 (referred to as “(PEM (Video VS) 2.2.2.2” in this example).

In step 828, the client device 20(2) sends a request for content at a location (“/video/free” in this example) associated with the domain name to the steering endpoint IP address received in step 826, which is associated with the steering endpoint device 16. In step 830, the steering endpoint device 16, or a virtual server located at the steering endpoint IP address and hosted by the steering endpoint device 16, sends the request to the VAS server device 18. The request can be sent to an appropriate application hosted by the VAS server device 18 for processing or optimizing content of the type for which the domain name has been classified, and to which the request was sent as described and illustrated earlier with reference to step 814.

Additionally, the steering endpoint device 16 resolves the original IP address using the domain name included in the host header of the request since the request is an HTTP GET request in this example. In other examples in which the request is not an HTTP request, the steering endpoint device 16 can retrieve the original IP address from local storage as stored in response to receiving the original IP address from the traffic manager computing device 12 subsequent to the traffic manager computing device 12 determining the confidence threshold had been exceeded for the domain name.

In step 832, the VAS server device 18 inserts the resolved original IP address into the request and forwards the request to the Internet 28 and the one of the server devices 24(1)-24(n). In step 834, the one of the server devices 24(1)-24(n) and the Internet 28 sends a response including the requested content to the VAS server device 18. In step 836, the VAS server device 18 optimizes the video content and sends a response including the optimized content to the client device 20(2). Accordingly, the client device 20(2) is steered through the VAS server device 18 and receives optimized video content without ever having to receive video content that is not optimized since the content is at a location associated with a domain name for which the traffic manager computing device 12 previously determined a confidence threshold was exceeded and was likely to be associated with content of the video type.

Accordingly, with this technology, domain names can be classified as associated with content of a specified type based on a confidence threshold being exceeded. Using DNS, request traffic associated with the domain names from client devices sent subsequent to the confidence threshold being exceeded can then be presteered through VAS server device(s) so that the content can be optimized. Accordingly, the client devices receiving optimized content that is presteered can receive the content relatively quickly and in an optimized format. Advantageously, both HTTP and non-HTTP network traffic can be presteered through a highly scalable process.

Having thus described the basic concept of the invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the invention. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.

Claims

1. A method for network traffic presteering to facilitate improved delivery of optimized content, the method implemented by a network traffic system comprising one or more traffic manager computing devices, Domain Name System (DNS) server devices, steering endpoint devices, value-added service (VAS) server devices, content server devices, or client devices, the method comprising: retrieving, via at least one of one or more provider networks or one or more wide area networks, content from a server at a location associated with a domain name in response to a request for the content received via one or more access networks from a client;determining classification data for the domain name, the classification data comprising at least a type of the retrieved content and a request volume for the type of the retrieved content;determining when a confidence threshold has been reached based on the request volume for the type of the retrieved content in the classification data, the request volume corresponding to a number of received requests for content of the type of the retrieved content;identifying a steering endpoint Internet Protocol (IP) address based on the type of the retrieved content;sending at least the steering endpoint IP address and the domain name to a Domain Name System (DNS) server to facilitate resolution of the domain name in a DNS request from another client to the steering endpoint IP address, when the determining indicates that the confidence threshold has been reached, wherein a virtual server at the steering endpoint IP address is configured to identify a value-added service (VAS) server configured to optimize content of the type of the retrieved content; andsending the retrieved content to the client via the one or more access networks in response to the received request.

2. The method of claim 1, further comprising: receiving another request from the client for content at the location associated with the domain name; andsending the another request to the VAS server.

3. The method of claim 1, further comprising updating the request volume, wherein the request volume represents a number of times content of the type of the requested content has been retrieved from one or more locations associated with the domain name.

4. The method of claim 1, further comprising: forwarding another DNS request to resolve the domain name from the client to the DNS server and a response from the DNS server including an original IP address corresponding to the domain name to the client; andsending the original IP address to the virtual server located at the steering endpoint IP address when the request for the content is not a HyperText Transfer Protocol (HTTP) request.

5. The method of claim 1, wherein the confidence threshold corresponds to a likelihood that another received request associated with the domain will be for content of the type of the retrieved content.

6. A traffic manager computing device, comprising a memory comprising programmed instructions stored thereon and at least one processor configured to be capable of executing the stored programmed instructions to: retrieve, via at least one of one or more provider networks or one or more wide area networks, content from a server at a location associated with a domain name in response to a request for the content received via one or more access networks from a client;determine classification data for the domain name, the classification data comprising at least a type of the retrieved content and a request volume for the type of the retrieved content;determine when a confidence threshold has been reached based on the request volume for the type of the retrieved content in the classification data, the request volume corresponding to a number of received requests for content of the type of the retrieved content;identify a steering endpoint Internet Protocol (IP) address based on the type of the retrieved content;send at least the steering endpoint IP address and the domain name to a Domain Name System (DNS) server to facilitate resolution of the domain name in a DNS request from another client to the steering endpoint IP address, when the determining indicates that the confidence threshold has been reached, wherein a virtual server at the steering endpoint IP address is configured to identify a value-added service (VAS) server configured to optimize content of the type of the retrieved content; andsend the retrieved content to the client via the one or more access networks in response to the received request.

7. The traffic manager computing device of claim 6, wherein the at least one processor is further configured to be capable of executing the stored programmed instructions to: receive another request from the client for content at the location associated with the domain name; andsend the another request to the VAS server.

8. The traffic manager computing device of claim 6, wherein the at least one processor is further configured to be capable of executing the stored programmed instructions to updating the request volume, wherein the volume represents a number of times content of the type of the requested content has been retrieved from one or more locations associated with the domain name.

9. The traffic manager computing device of claim 6, wherein the at least one processor is further configured to be capable of executing the stored programmed instructions to: forward another DNS request to resolve the domain name from the client to the DNS server and a response from the DNS server including an original IP address corresponding to the domain name to the client; andsend the original IP address to the virtual server located at the steering endpoint IP address when the request for the content is not a HyperText Transfer Protocol (HTTP) request.

10. The traffic manager computing device of claim 6, wherein the confidence threshold corresponds to a likelihood that another received request associated with the domain will be for content of the type of the retrieved content.

11. A non-transitory computer readable medium having stored thereon instructions for network traffic presteering to facilitate improved delivery of optimized content comprising executable code which when executed by one or more processor, causes the one or more processors to: retrieve, via at least one of one or more provider networks or one or more wide area networks, content from a server at a location associated with a domain name in response to a request for the content received via one or more access networks from a client;determine classification data for the domain name, the classification data comprising at least a type of the retrieved content and a request volume for the type of the retrieved content;determine when a confidence threshold has been reached based on the request volume for the type of the retrieved content in the classification data, the request volume corresponding to a number of received requests for content of the type of the retrieved content;identify a steering endpoint Internet Protocol (IP) address based on the type of the retrieved content;send at least the steering endpoint IP address and the domain name to a Domain Name System (DNS) server to facilitate resolution of the domain name in a DNS request from another client to the steering endpoint IP address, when the determining indicates that the confidence threshold has been reached, wherein a virtual server at the steering endpoint IP address is configured to identify a value-added service (VAS) server configured to optimize content of the type of the retrieved content; andsend the retrieved content to the client via the one or more access networks in response to the received request.

12. The non-transitory computer readable medium of claim 11, wherein the executable code when executed by the one or more processors further causes the one or more processors to: receive another request from the client for content at the location associated with the domain name; andsend the another request to the VAS server.

13. The non-transitory computer readable medium of claim 11, wherein the executable code when executed by the one or more processors further causes the one or more processors to update the request volume, wherein the volume represents a number of times content of the type of the requested content has been retrieved from one or more locations associated with the domain name.

14. The non-transitory computer readable medium of claim 11, wherein the executable code when executed by the one or more processors further causes the one or more processors to: forward another DNS request to resolve the domain name from the client to the DNS server and a response from the DNS server including an original IP address corresponding to the domain name to the client; andsend the original IP address to the virtual server located at the steering endpoint IP address when the request for the content is not a HyperText Transfer Protocol (HTTP) request.

15. The non-transitory computer readable medium of claim 11, wherein the confidence threshold corresponds to a likelihood that another received request associated with the domain will be for content of the type of the retrieved content.

16. A network traffic management system, comprising one or more traffic manager computing devices, Domain Name System (DNS) server devices, steering endpoint devices, value-added service (VAS) server devices, content server devices, or client devices, the network traffic management system comprising memory comprising programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to: retrieve, via at least one of one or more provider networks or one or more wide area networks, content from a server at a location associated with a domain name in response to a request for the content received via one or more access networks from a client;determine classification data for the domain name, the classification data comprising at least a type of the retrieved content and a request volume for the type of the retrieved content;determine when a confidence threshold has been reached based on the request volume for the type of the retrieved content in the classification data, the request volume corresponding to a number of received requests for content of the type of the retrieved content;identify a steering endpoint Internet Protocol (IP) address based on the type of the retrieved content;send at least the steering endpoint IP address and the domain name to a Domain Name System (DNS) server to facilitate resolution of the domain name in a DNS request from another client to the steering endpoint IP address, when the determining indicates that the confidence threshold has been reached, wherein a virtual server at the steering endpoint IP address is configured to identify a value-added service (VAS) server configured to optimize content of the type of the retrieved content; andsend the retrieved content to the client via the one or more access networks in response to the received request.

17. The network traffic management system of claim 16, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: receive another request from the client for content at the location associated with the domain name; andsend the another request to the VAS server.

18. The network traffic management system of claim 16, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to update the request volume, wherein the volume represents a number of times content of the type of the requested content has been retrieved from one or more locations associated with the domain name.

19. The network traffic management system of claim 16, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: forward another DNS request to resolve the domain name from the client to the DNS server and a response from the DNS server including an original IP address corresponding to the domain name to the client; andsend the original IP address to the virtual server located at the steering endpoint IP address when the request for the content is not a HyperText Transfer Protocol (HTTP) request.

20. The network traffic management system of claim 16, wherein the confidence threshold corresponds to a likelihood that another received request associated with the domain will be for content of the type of the retrieved content.