Methods for multipath transmission control protocol (MPTCP) based session migration and devices thereof

Information

  • Patent Grant
  • 11223689
  • Patent Number
    11,223,689
  • Date Filed
    Wednesday, January 2, 2019
    5 years ago
  • Date Issued
    Tuesday, January 11, 2022
    2 years ago
Abstract
Methods, non-transitory computer readable media, network traffic management apparatuses, and network traffic management systems that facilitates multipath transmission control protocol (MPTCP) based session migration. The primary network traffic management apparatus migrates the MPTCP session state data associated with a client-server pair flow transactions to a secondary traffic management apparatus. The primary traffic management apparatus then disconnects the first connection for the client-server pair flow transactions and the secondary traffic management apparatus establishes a second connection to continue with the processing of client-server pair flow transactions without introducing application faults.
Description
BACKGROUND

A session between a client device and a server device of a network utilizes a request response pair. Typically, the client device accesses data at the server device during the session for a period of time.


However, if the session between the client device and the server device is prolonged, this results in an increased load on the server device which is not beneficial for overall network efficiency. Additionally, if during the session the client device moves away from a home location server device to a new location to access an away location server device, this presents a challenge in maintaining a continuous session without discontinuity.


To prevent discontinuity, a migration of sessions between client device and server device without introducing application faults is needed which requires a mechanism to transition transmission control protocol (TCP) connections which previously has not been effectively solved.


SUMMARY

A method for multipath transmission control protocol (MPTCP) based session migration, implemented by a network traffic management system comprising one or more network traffic management apparatuses, administrator devices, client devices, or server devices includes managing a client-server pair flow transactions between a client device and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection. An indication to migrate a MPTCP session date data associated with the first MPTCP session from the primary computing device to a secondary computing device is received. The MPTCP session state data associated with the first MPTCP session is migrated to the secondary computing device. As identifier associated with the secondary computing device is advertised to the client device. An indication of a second MPTCP session being established between the client device and the secondary computing device is received from the secondary computing device. The first connection between the client device and the primary computing device is terminated.


A primary computing apparatus including memory including programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to manage a client-server pair flow transactions between a client device and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection. An indication to migrate a MPTCP session date data associated with the first MPTCP session from the primary computing device to a secondary computing device is received. The MPTCP session state data associated with the first MPTCP session is migrated to the secondary computing device. As identifier associated with the secondary computing device is advertised to the client device. An indication of a second MPTCP session being established between the client device and the secondary computing device is received from the secondary computing device. The first connection between the client device and the primary computing device is terminated.


A non-transitory computer readable medium having stored thereon instructions for including executable code that, when executed by one or more processors, causes the processors to manage a client-server pair flow transactions between a client device and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection. An indication to migrate a MPTCP session date data associated with the first MPTCP session from the primary computing device to a secondary computing device is received. The MPTCP session state data associated with the first MPTCP session is migrated to the secondary computing device. As identifier associated with the secondary computing device is advertised to the client device. An indication of a second MPTCP session being established between the client device and the secondary computing device is received from the secondary computing device. The first connection between the client device and the primary computing device is terminated.


A network traffic management system includes a memory comprising programmed instructions stored thereon for one or more primary computing modules, secondary computing modules, client modules, or remote server modules and one or more processors configured to be capable of executing the stored programmed instructions to manage a client-server pair flow transactions between a client device and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection. An indication to migrate a MPTCP session date data associated with the first MPTCP session from the primary computing device to a secondary computing device is received. The MPTCP session state data associated with the first MPTCP session is migrated to the secondary computing device. As identifier associated with the secondary computing device is advertised to the client device. An indication of a second MPTCP session being established between the client device and the secondary computing device is received from the secondary computing device. The first connection between the client device and the primary computing device is terminated.


This technology has a number of associated advantages including providing methods, non-transitory computer readable media, primary computing apparatuses, and network traffic management systems that provides an optimized process of transitioning a TCP connection from one device to another by using features of multipath transmission control protocol (MPTCP) to enable session migration. With MPTCP migration the sockets used in the transport layer are switched from the primary traffic management apparatus to the secondary traffic management apparatus. As these sockets are in the transport layer, the application layer of the devices is not disturbed and they continue processing and servicing the requested content between the client device and the one or more server devices without interruption. As a result the client device is not affected and keeps on receiving the requested data seamlessly without any discontinuity, this eliminates application faults.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a block diagram of an exemplary network traffic management system with a primary server device and a secondary server device pool;



FIG. 2 is a block diagram of an exemplary primary server device of FIG. 1;



FIG. 3 is a block diagram of an exemplary network traffic management system with a primary network traffic management apparatus, a plurality of secondary network traffic management apparatus and remote server device pool;



FIGS. 4A-4B is a block diagram of an exemplary primary network traffic management apparatus and a secondary network traffic management apparatus;



FIG. 5 is a flowchart of an exemplary method for exemplary network traffic management system with a primary server device and secondary server device pool of FIG. 1;



FIG. 6 is a timing diagram of an exemplary method for exemplary network traffic management system with a primary server device and secondary server device pool of FIG. 1;



FIG. 7 is a flowchart of an exemplary method for exemplary network traffic management system with a primary network traffic management apparatus, a plurality of secondary network traffic management apparatus and remote server device pool of FIG. 3; and



FIG. 8 is a timing diagram of an exemplary method for exemplary network traffic management system with a primary network traffic management apparatus, a plurality of secondary network traffic management apparatus and remote server device pool of FIG. 3.





DETAILED DESCRIPTION

Referring to FIG. 1, an exemplary network environment which incorporates an exemplary network traffic management system 10 is illustrated. The network traffic management system 10 in this example includes a primary server device 14a and a secondary server device pool including plurality of secondary server devices 15a(1)-15a(n) and a plurality of client devices 16a(1)-16a(n) coupled via communication network(s) 18a, although the primary server device 14a and the plurality of secondary server devices 15a(1)-15a(n), and/or client devices 16a(1)-16a(n) may be coupled together via other topologies. Additionally, the network traffic management system 10 may include other network devices such as one or more routers and/or switches, for example, which are well known in the art and thus will not be described herein. This technology provides a number of advantages including methods, non-transitory computer readable media, network traffic management systems, and the server devices that provide an optimized process of transitioning a TCP connection from a primary server device to a secondary server device by using features provided by multipath transmission control protocol (MPTCP) to enable an improved session migration. Further, the session migration is performed without involving the application layer involved in the request response pair which results in evading any discontinuity in communication of data to the client devices 16a(1)-16a(n) and further enables TCP session migration during device maintenance.


In this particular example, the primary server device 14a, the secondary server devices 15a(1)-15a(n) and the plurality of client devices 16a(1)-16a(n) are disclosed in FIG. 1 as dedicated hardware devices. However, one or more of the primary server device 14a and the secondary server devices 15a(1)-15a(n), or client devices 16a(1)-16a(n) can also be implemented in software within one or more other devices in the network traffic management system 10. As used herein, the term “module” refers to either an implementation as a dedicated hardware device or apparatus, or an implementation in software hosted by another hardware device or apparatus that may be hosting one or more other software components or implementations.


As one example, the primary server device 14a, as well as any of its components, models, or applications, can be a module implemented as software executing on one of the secondary server devices 15a(1)-15a(n), and many other permutations and types of implementations can also be used in other examples. Moreover, any or all of the primary server device 14a, secondary server devices 15a(1)-15a(n), and client devices 16(1)-16(n), can be implemented, and may be referred to herein, as a module.


Referring to FIGS. 1-2, the primary server device 14a of the network traffic management system 10 may perform any number of functions including migrating sessions between devices, managing network traffic, load balancing network traffic across the server devices, global load balancing network traffic, identifying potential security threats to the network traffic, accelerating network traffic associated with web applications or accelerating network traffic associated with an application hosted by one or more of the secondary server devices 15a(1)-15a(n), for example. The primary server device 14a in this example includes one or more processor(s) 29a, a memory 26a, and a communication interface 30a, which are coupled together by a bus 19a, although the primary server device 14a can include other types or numbers of elements in other configurations.


The processor(s) 29a of the primary server device 14a may execute programmed instructions stored in the memory 26a of the primary server device 14a for any number of the functions identified above. The processor(s) 29a of the primary server device 14a may include one or more central processing units (CPUs) or general purpose processors with one or more processing cores, for example, although other types of processor(s) can also be used.


The memory 26a of the primary server device 14a 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 elsewhere. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk, solid state drives, flash memory, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor(s) 29a, can be used for the memory 26a.


Accordingly, the memory 26a of the primary server device 14a can store one or more applications that can include computer executable instructions that, when executed by the primary server device 14a, cause the primary server device 14a to perform actions, such as to transmit, receive, or otherwise process messages, for example, and to perform other actions described and illustrated below with reference to FIGS. 5-6. The application(s) can be implemented as modules or components of other applications. Further, the application(s) can be implemented as operating system extensions, plugins, or the like.


Even further, the application(s) may be operative in a cloud-based computing environment. The application(s) can be executed within or as virtual machine(s) or virtual server(s) that may be managed in a cloud-based computing environment. Also, the application(s), and even the primary server device 14a, may be located in virtual server(s) running in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Also, the application(s) may be running in one or more virtual machines (VMs) executing on the server device. Additionally, in one or more embodiments of this technology, virtual machine(s) running on the server device may be managed or supervised by a hypervisor.


In this particular example, the memory 26a of the primary server device 14a includes session data storage 25a and profile data storage 28a, although the memory can include other types and/or numbers of policies, modules, databases, applications, and/or other data for example.


The session data storage 25a may store information associated with tracking a request response pair session associated between the client devices 16a(1)-16a(n) and the primary server device 14a. The request response pair session may correspond to communications performed between the client devices 16a(1)-16a(n) and the primary server device 14a forming a client-server pair flow transactions referred to as flow transactions. The flow transactions may include information about accessing by the client devices 16a(1)-16a(n) content at the primary server device 14a to form a session. The session data storage 25a information may also be used to determine when a session is completely migrated to an another device. By way of example, the another device may include the secondary server devices 15a(1)-15a(n).


The profile data storage 28a may store information associated with server load, server location, and/or monitoring user traffic data, although other types of data may be stored. The server load may include, for example, information associated with load capacity of the server and/or the peak load capacity of the server. The stored information may include other information, for example information on which of the client device 16a(1)-16a(n) accesses which of the server devices 15a(1)-15a(n) at which location over a period of time. The stored information may also identify the primary server device 14a as a home server device for one of the client devices 16a(1)-16a(n), based on a determination that the one of the client devices 16a(1)-16a(n) accesses that the primary server device 14a regularly. Further, the stored information may also identify the primary server device 14a as an away server device for one of the client devices 16a(1)-16a(n), based on determining that the one of the client devices 16a(1)-16a(n) does not access the primary server device 14a regularly, although other manners for determining home and/or away server devices for one or more client devices 16a(1)-16a(n) may be used. The stored information may also include user traffic data associated with the client device such as, tracked historical session information associated with the client devices 16a(1)-16a(n) over a period of time, although other type of information may be stored. The tracked historical information may include tracked information on various user activity, such as frequency of accessing websites by the client devices 16a(1)-16a(n), types of activity associated with the websites, historical shopping activity, and/or network activity any other activities in association with websites by way of example. The stored information may or may not identify one of the client devices 16a(1)-16a(n) as a known client device and/or may or may not store a classification of the one of the client devices 16a(1)-16a(n) as a safe device based on any identified security threat associated with that one of the client devices 16a(1)-16a(n). Further the stored information may identify the primary server device 14a that will best service a request based on the location and historical information associated with the client devices 16a(1)-16a(n) as explained below.


Referring back to FIGS. 1-2, the communication interface 30a of the primary server device 14a operatively couples and communicates between the secondary server devices 15a(1)-15a(n) server devices, and/or the client devices 161(1)-16a(n), which are all coupled together by the communication network(s) 18a, although other types and/or numbers of communication networks or systems with other types and/or numbers of connections and/or configurations to other devices and/or elements can also be used.


By way of example only, the communication network(s) 18(a) can include local area network(s) (LAN(s)) or wide area network(s) (WAN(s)), and can use TCP/IP over Ethernet and industry-standard protocols, although other types and/or numbers of protocols and/or communication networks can be used. The communication network(s) 18(a) in this example can employ any suitable interface mechanisms and network communication technologies including, for example, 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.


The primary server device 14a is illustrated in this example as a including a single device, the primary server device 14a in other examples can include one or more of the secondary server devices 15a(1)-15a(n). While each of the primary server device 14a and the secondary server devices 15a(1)-15a(n) is illustrated in this example as including a single device, the primary server device 14a and the secondary server devices 15a(1)-15a(n) in other examples can include a plurality of devices or blades each having one or more processors (each processor with one or more processing cores) that implement one or more steps of this technology. In these examples, one or more of the devices can have a dedicated communication interface or memory. Alternatively, one or more of the devices can utilize the memory, communication interface, or other hardware or software components of one or more other devices included in the primary server device 14a. Although the primary server device 14a is illustrated as single device, there may be one or more primary server device 14a connected to one or more secondary server devices 15a(1)-15a(n).


Additionally, one or more of the devices that together comprise the primary server device 14a in other examples can be standalone devices or integrated with one or more other devices or apparatuses, such as one of the secondary server devices 15a(1)-15a(n), for example. Moreover, one or more of the devices of the primary server device 14a in these examples can be in a same or a different communication network including one or more public, private, or cloud networks, for example.


Each of the secondary server devices 15a(1)-15a(n) of the network traffic management system 10 in this example includes processor(s), a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers or types of components could be used. The secondary server devices 15a(1)-15a(n) in this example can include application servers, database servers, access control servers, or encryption servers, for example, that exchange communications along communication paths expected based on application logic in order to facilitate interactions with an application by users of the client devices 16a(1)-16a(n).


Although the secondary server devices 15a(1)-15a(n) are illustrated as single devices, one or more actions of each of the secondary server devices 15a(1)-15a(n) may be distributed across one or more distinct network computing devices that together comprise one or more of the secondary server devices 15a(1)-15a(n). Moreover, the secondary server devices 15a(1)-15a(n) are not limited to a particular configuration. Thus, the secondary server devices 15a(1)-15a(n) may contain a plurality of network computing devices that operate using a master/slave approach, whereby one of the network computing devices of the server devices operate to manage and/or otherwise coordinate operations of the other network computing devices. The secondary server devices 15a(1)-15a(n) may operate as a plurality of network computing devices within a cluster architecture, a peer-to peer architecture, virtual machines, or within a cloud architecture, for example.


Thus, the technology disclosed herein is not to be construed as being limited to a single environment and other configurations and architectures are also envisaged. For example, one or more of the secondary server devices 15a(1)-15a(n) can operate within the primary server device 14a itself rather than as a stand-alone server device communicating with the primary server device 14a via communication network(s) 18a. In this example, the one or more of the secondary server devices 15a(1)-15a(n) operate within the memory 26a of the primary server device 14a.


The client devices 16a(1)-16a(n) of the network traffic management system 10 in this example include any type of computing device that can exchange network data, such as mobile, desktop, laptop, or tablet computing devices, virtual machines (including cloud-based computers), or the like. Each of the client devices 16a(1)-16a(n) 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 numbers and/or types of network devices could be used.


The client devices 16a(1)-16a(n) may run interface applications, such as standard web browsers or standalone client applications, which may provide an interface to make requests for, and receive content stored on, one or more of the primary server device 14a, the secondary server devices 15a(1)-15a(n) via the communication network(s) 18a. The client devices 16a(1)-16a(n) may further include a display device, such as a display screen or touchscreen, and/or an input device, such as a keyboard for example. Additionally, one or more of the client devices 16a(1)-16a(n) can be configured to execute software code (e.g., JavaScript code within a web browser) in order to log client-side data and provide the logged data to the primary server device 14a′, as described and illustrated in more detail later.


Although the exemplary network traffic management system 10 with the primary server device 14a, the secondary server devices 15a(1)-15a(n), client devices 16a(1)-16a(n), and communication network(s) 18a are described and illustrated herein, other types and/or numbers of systems, devices, components, and/or elements in other topologies can be used. It is to be understood that 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).


One or more of the components depicted in the network traffic management system 10, such as the primary server device 14a, the secondary server devices 15a(1)-15a(n) and the client devices 16a(1)-16a(n), for example, may be configured to operate as virtual instances on the same physical machine. In other words, one or more of the client devices 16a(1)-16a(n), the primary server device 14a, or the secondary server devices 15a(1)-15a(n) may operate on the same physical device rather than as separate devices communicating through communication network(s). Additionally, there may be more or fewer the primary server device 14a, the secondary server devices 15a(1)-15a(n) and the client devices 16a(1)-16a(n) than illustrated in FIG. 1.


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, wireless traffic networks, cellular traffic networks, Packet Data Networks (PDNs), the Internet, intranets, and combinations thereof.


The examples may also be embodied as one or more non-transitory computer readable media having instructions stored thereon, such as in the memory 26a, for one or more aspects of the present technology, as described and illustrated by way of the examples herein. The instructions in some examples include executable code that, when executed by one or more processors, such as the processor(s) 29a, cause the processors to carry out steps necessary to implement the methods of the examples of this technology that are described and illustrated herein.


An exemplary method of multipath transmission control protocol (MPTCP) based session migration and devices will now be described with reference to FIGS. 1-2, 5-6. Referring more specifically to FIG. 5, in a first step 500 the primary computing device monitors client server pair flow transactions between at least one of the client devices 16a(1)-16a(n) and itself over an established first connection. By way of example, the primary computing device in this example is the primary server device 14a of FIG. 1, although the primary computing device could be any other device and the one of the client device is the client device 16a(1). The primary server device 14a of the network traffic management system monitors client-server pair flow transactions between the client device 16a(1) and the primary server device 14a over an established first connection. In another example, the primary server device 14a of the network traffic management system 10 monitors client-server pair flow transactions between the client device 16a(1), the primary server device 14a and other secondary server devices 15a(1)-15a(n). The client device 16a(1) sends a SYN request including a MPTCP connection request to the primary server device 14a. In response to the SYN request the primary server device 14a sends a transmit SYN acknowledgement message to acknowledge receiving the SYN request to the client device 16a(1). Upon receiving the SYN acknowledgment the primary server device 14a and the client device 16a(1) establishes a first MPTCP session and exchanges MPTCP session data between them. Further, the primary server device 14a receives from a client device 16a(1) a client access request to access applications at the primary server device 14a and the secondary server devices 15a(1)-15a(n). Upon receiving the client access request the primary server device 14a transmits to the client device 16a(1) an acknowledgment for the client access request, to acknowledge receiving of the client access request. The primary network server device 14a then forwards a server response from the primary server device 14a to the client device 16a(1). The server response grants access to the application content requested by the client device 16a(1). The client device 16a(1) then accesses the primary server device 14a and thus establishing a first connection to transmit and receive content. The primary server device 14a manages the first connection by monitoring and storing session information associated with tracking a request response pair session associated between a client device 16a(1) and itself in the session data storage. This session information may include MPTCP session data exchanged between the client device 16a(1) and the primary server device 14a. The request response pair session corresponds to flow transactions performed between a client device 16a(1) and the primary server device 14a forming a client-server pair flow transactions. Further, the flow transactions may include accessing by the client device 16a(1) content at the primary server device 14a to form a session.


In another example, the primary server device 14a is a primary network traffic management apparatus 14b and the secondary server devices 15a(1)-15a(n) are secondary network traffic management apparatus 15b(1)-15b(n) of FIG. 3 explained in detail later below.


In step 510, the primary network traffic management apparatus 14a of the network traffic management system 10 receives an indication for migrating multipath transmission control protocol (MPTCP) session state data associated with the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a to one or more of the secondary computing devices. By way of example, the one or more secondary computing devices in this example are the one or more secondary server devices 15a(1)-15a(n) in the secondary server device pool of FIG. 1, although the secondary computing device could be any other device. In this example, the primary computing device is the primary server device 14a and the one or more secondary computing devices are the one or more secondary server devices 15a(1)-15a(n).


Receiving the indication may include, for example, receiving the indication automatically based on predefined policies. The predefined polices associated with automatically receiving an indication for migrating the MPTCP sessions may include migration policies stored in the profile data storage 28a. The primary server device 14a analyzes the migration policies to determine corresponding actions associated with those migration policies.


The migration policies include analyzing the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a to determine the type of content within the client-server pair flow transactions. When the type of content is determined to be a potential malicious content or a potential security threat, then the migration policy would migrate the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a to the secondary server device 15a(1) acting as an authentication entity and dedicated to handle that type of content. In this example, the secondary server device 15a(1) is dedicated to handle these threats which may include, for example, a DOS attack, viruses or any malicious content. In another example, the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a can be migrated to a plurality of secondary server devices 15a(1)-15a(n).


By way of example, there are various ways to receive an indication for migrating the MPTCP session state data, for example, based on a user selection at a user interface or automatically based predefined polices associated with the network traffic. The session state data may include, for example, requests, responses, session protocol information and any information in relation to the client-server pair transactions. Further receiving the indication may include, receiving an indication based on a user selection at a user interface, for example, from an administrator associated with managing the network traffic. When the administrator wants to offline the primary network traffic management apparatus 14a for maintenance purposes, the administrator may use a user interface to provide the indication. For example, when it is determined by the primary network traffic management apparatus 14a that primary network traffic management apparatus 14a accessed by the client device 16a(1) is an away service device and then the action associated with a migration policy is that, this session is to be transmitted and handled by one or more of the secondary network traffic management apparatus 15a(1)-15a(n) that is a home service device. The home service device is a device accessed by the client device 16a(1) on a frequent basis over a period of time and an away server device is a device accessed by the client device 16a(1) for the first time or less frequently. Further, in another example, when it is determined that the primary network traffic management apparatus 14a servicing a request for the client device 16a(1) has a long lived session, and has reached its maximum peak load capacity or based on a predetermined load capacity limit then the action with another migration policy is that the session is to be handled by one or more of the secondary network traffic management apparatus 15a(1)-15a(n) that is capable to service the request. Further based on determining that the client device 16a(1) requesting the content is a potential security threat based on monitoring historical information associated with the client device 16a(1), or the client device 16a(1) is accessing the primary server device 14a for the first time or any unusual activity associated with the client device 16a(1), then the action associated with the migration policy determines that the client device 16a(1) to be transferred to be handled by a secondary network traffic management apparatus 15a(1)-15a(n) acting as an authentication server. Although other types of policies and ways may be implemented for receiving the indication for migrating a MPTCP session data.


In another example, the one or more secondary server devices 15a(1)-15a(n) could be the one or more secondary network traffic management apparatus 15b(1)-15b(n) of FIG. 3 explained in detail later below.


In step 520, the primary server device 14a of the network traffic management system 10 stops transmission of acknowledgments for any new request received from the client device 16a(1) upon receiving an indication to migrate the MPTCP session state data. The primary server device 14a may keep on receiving new client requests from the client device 16a(1) to access it. However, the primary server device 16a(1) stops sending acknowledgments for the new client requests received upon receiving an indication to migrate the MPTCP session state data.


In step 530, the primary server device 14a of the network traffic management system 10 waits for completion of any pending client-server pair flow transactions. The primary server device 14a determines for the first connection established between the client device 16a(1) and itself as having transactions that are in progress and are pending. In this example the primary server device 14a waits for all the pending transactions to be processed. Proceeding with migrating the session state data without processing the pending transactions would be problematic because the pending transactions would be left stuck in the first connection and could not be migrated. Accordingly, if there were pending transactions during migration, the migrated data would be incomplete with missing information, for example, missing response/request, only including a beginning of a response/request, only including a middle of the response/request or only including an ending of a response/request. As a result to avoid these issues the primary server device 14a waits before initiating any migration of the session until all of the pending transactions have been completed between the client device 16a(1) and itself.


In step 540, the primary server device 14a of the network traffic management system 10 migrates the MPTCP session state data associated with the client-server pair flow transactions to one of the secondary server devices 15a(1)-15a(n). By way of example, the secondary server device 15a(1) is the one of the secondary server devices 15a(1)-15a(n) that the MPTCP session state data is migrated to, by the primary server device 14a although the MPTCP session state data may be migrated any of the secondary server devices 15a(1)-15a(n).


The migration of the MPTCP session state data associated with the client-server pair flow transactions to the secondary server device 15a(1) is initiated upon determining that all of the pending client server pair flow transactions have been completed. The migration of the MPTCP session date to one or more secondary server devices 15a(1)-15a(n) is based on the indication received in step 510. When the indication received in step 510 is based on a determination that the session of the primary server device 14a accessed by the client device 16a(1) is a long lived session and that has reached its maximum peak load capacity or has reached a predetermined load capacity limit, then a determination is made that the session is to be handled by the secondary server device 15a(1) that is capable of handling the traffic load, then the session is migrated to the secondary server device 15a(1) that is capable of handling the traffic load. When the indication received in step 510 is based on a determination that the type of content of the session handled by the primary server device 14a is to be handled by the secondary server device 15a(1) that is dedicated to handle that type of content, then the session is migrated to the secondary server device 15a(1) associated with the dedicated to handle that type of content. When the indication received in step 510 is based on determination that the client device 16a(1) could be potentially a malicious user or a potential security threat and that the session is to be handled by a secondary server device 15a(1) dedicated to handle threats, such as a DOS attack, viruses, or any malicious content by way of example, then the session is migrated to a secondary server device 15a(1) dedicated to handle threats such as a DOS attack, viruses or any malicious content, although other types of policies and ways may be implemented for migrating the MPTCP session data. With MPTCP migration the sockets used in the transport layer are switched from the primary server device 14a to the secondary server device 15a(1). As these sockets are in the transport layer, the application layer of the devices is not disturbed and they continue processing and servicing the requested content between the client device 16a and the secondary server device 15a(1). As a result the client device 16a(1) is not affected and keeps on receiving the requested data seamlessly without any discontinuity. In another example, the primary server device 14a of the network traffic management system 10 migrates the MPTCP session state data associated with the client-server pair flow transactions to a plurality of secondary server devices 15a(1)-15a(n).


In step 550, the primary server device 14a of the network traffic management system 10 determines when all of the MPTCP session state data has been migrated. Upon determining that all of the MPTCP session state data associated with the first connection between the client device 16a(1) and the primary server device 14a has been migrated to the one of the secondary server device 15a(1) then the primary server device 14a moves to step 560. If in step 550, the primary server device 14a of the network traffic management system determines all of the MPTCP session state data has not migrated, then the No branch is taken to continue the migration. If in step 550, the primary server device 14a of the network traffic management system 10 determines all of the MPTCP session state data has been migrated, then the Yes branch is taken to step 560.


In step 560, In step 560, the primary server device 14a of the network traffic management system 10 advertises the identifier of the secondary server device 15a(1) to which the MPTCP session state data has been migrated to in step 550. The secondary server device identifier includes an IP address associated with the secondary server device 15a(1) or any type of identifier associated. Further, the client device 16a(1) sends a MPTCP join request to the secondary server device 15a(1) to establish a connection with the secondary server device 15a(1). The MPTCP join request is to join the previously established MPTCP session between the primary server device 14a and with the client device 16a(1) requesting the content. Upon receiving the MPTCP join request, the secondary server device 15a(1) establishes a second connection with the client device 16a(1) by joining to the previously established MPTCP session.


In step 570, the primary server device 14a of the network traffic management system receives an indicator from the secondary server device 15a(1) indicating that the client device 16a(1) is connected to the secondary server device 15a(1) and the secondary server device 15a(1) has joined the previously established MPTCP session to establish a second connection. The received indicator indicating that the secondary server device 15a(1) utilizes the transmitted MPTCP session state data to connect with the client device 16a(1) and further to join the MPTCP session previously established between the primary server device 14a and the secondary server device 15a(1). The indicator further indicates that the client device 16a(1) is now connected to the secondary server device 15a(1) and transmitting data based on the previously established MPTCP session.


In step 580, the primary server device 14a of the network traffic management system 10 terminates the first connection between the client device 16a(1) and itself. Once the primary server device 14a of the network traffic management system 10 receives an indicator of step 580 from the secondary server device 15a(1), then the primary server device 14a terminates the first connection between the client device 16a(1) and itself.


Referring more specifically to FIG. 6, a timing diagram of an exemplary method of is illustrated. In a first step 1 in this example, the client device 16a(1) sends a SYN request including a MPTCP connection request to the primary server device 14a of the network traffic management system 10 to establish a connection. The primary server device 14a of the network traffic management system 10 receives the SYN request.


In step 2, the primary server device 14a of the network traffic management system in response to receiving the SYN request from the client device 16a(1) sends a transmit SYN acknowledgement message to acknowledge receiving the SYN request to the client device 16a(1).


In step 3, the primary server device 14a of the network traffic management system establishes a first MPTCP session. Upon receiving the SYN acknowledgment from the primary server device 14a, the primary server device 14a and the client device 16a(1) establishes a first MPTCP session and exchanges MPTCP session data between them.


In step 4, the primary server device 14a of the network traffic management system receives a first client access request to access applications at the primary server device 14a.


In step 5, the primary server device 14a of the network traffic management system transmits an acknowledgment message in response. Upon receiving the client access request the primary server device 14a transmits to the client device 16a(1) an acknowledgment for the client access request, to acknowledge receiving of the client access request.


In step 6, the primary server device 14a of the network traffic management system then sends a server response to the client device 16a(1). The server response grants access to the application content requested by the client device 16a(1).


In step 7, the primary server device 14a of the network traffic management system establishes a first connection with the client devices 16a(1) upon sending the server response to the client device 16a(1). This first connection is used to transmit and receive content and completes a client-server pair flow transaction to establish a MPTCP session. The primary server device 14a manages the first connection by monitoring and storing monitors and stores session information associated with tracking a request response pair session associated between a client device 16a(1) and itself in the session data storage. This session information may include MPTCP session data exchanged between the client device 16a(1) and itself. The request response pair session corresponds to flow transactions performed between a client device 16a(1) and the primary server device 14a forming a client-server pair flow transactions. Further, the flow transactions may include accessing by the client device 16a(1) content at the primary server device 14a to form a session.


In step 8, the primary network traffic management apparatus 14a of the network traffic management system 10 receives an indication for migrating multipath transmission control protocol (MPTCP) session state data associated with the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a to one or more of the secondary computing devices. By way of example, the one or more secondary computing devices in this example are the one or more secondary server devices 15a(1)-15a(n) in the secondary server device pool of FIG. 1, although the secondary computing device could be any other device. In this example, the primary computing device is the primary server device 14a and the one or more secondary computing devices are the one or more secondary server devices 15a(1)-15a(n).


Receiving the indication may include, for example, receiving the indication automatically based on predefined policies. The predefined polices associated with automatically receiving an indication for migrating the MPTCP sessions may include migration policies stored in the profile data storage 28a. The primary server device 14a analyzes the migration policies to determine corresponding actions associated with those migration policies.


The migration policies include analyzing the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a to determine the type of content within the client-server pair flow transactions. When the type of content is determined to be a potential malicious content or a potential security threat, then the migration policy would migrate the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a to the secondary server device 15a(1) acting as an authentication entity and dedicated to handle that type of content. In this example, the secondary server device 15a(1) is dedicated to handle these threats which may include, for example, a DOS attack, viruses or any malicious content. In another example, the client-server pair flow transactions between the client device 16a(1) and the primary server device 14a can be migrated to a plurality of secondary server devices 15a(1)-15a(n).


By way of example, there are various ways to receive an indication for migrating the MPTCP session state data, for example, based on a user selection at a user interface or automatically based predefined polices associated with the network traffic. The session state data may include, for example, requests, responses, session protocol information and any information in relation to the client-server pair transactions. Further receiving the indication may include, receiving an indication based on a user selection at a user interface, for example, from an administrator associated with managing the network traffic. When the administrator wants to offline the primary network traffic management apparatus 14a for maintenance purposes, the administrator may use a user interface to provide the indication. For example, when it is determined by the primary network traffic management apparatus 14a that primary network traffic management apparatus 14a accessed by the client device 16a(1) is an away service device and then the action associated with a migration policy is that, this session is to be transmitted and handled by one or more of the secondary network traffic management apparatus 15a(1)-15a(n) that is a home service device. The home service device is a device accessed by the client device 16a(1) on a frequent basis over a period of time and an away server device is a device accessed by the client device 16a(1) for the first time or less frequently. Further, in another example, when it is determined that the primary network traffic management apparatus 14a servicing a request for the client device 16a(1) has a long lived session, and has reached its maximum peak load capacity or based on a pre determined load capacity limit then the action with another migration policy is that the session is to be handled by one or more of the secondary network traffic management apparatus 15a(1)-15a(n) that is capable to service the request. Further based on determining that the client device 16a(1) requesting the content is a potential security threat based on monitoring historical information associated with the client device 16a(1), or the client device 16a(1) is accessing the primary server device 14a for the first time or any unusual activity associated with the client device 16a(1), then the action associated with the migration policy determines that the client device 16a(1) to be transferred to be handled by a secondary network traffic management apparatus 15a(1)-15a(n) acting as an authentication server. Although other types of policies and ways may be implemented for receiving the indication for migrating a MPTCP session data.


In another example, the one or more secondary server devices 15a(1)-15a(n) could be the one or more secondary network traffic management apparatus 15b(1)-15b(n) of FIG. 3 explained in detail later below.


In step 9, the primary server device 14a of the network traffic management system receives a second client access request from the client device 16a(1).


In step 10, the primary server device 14a of the network traffic management system 10 stops transmission of acknowledgments for any new request received from the client device 16a(1) upon receiving an indication to migrate the MPTCP session state data. The primary server device 14a may keep on receiving new client requests from the client device 16a(1) to access it. However, the primary server device 16a(1) stops sending acknowledgments for the new client requests received upon receiving an indication to migrate the MPTCP session state data.


In step 11, the primary server device 14a of the network traffic management system 10 waits for completion of any pending client-server pair flow transactions. The primary server device 14a determines for the first connection established between the client device 16a(1) and itself as having transactions that are in progress and are pending. In this example the primary server device 14a waits for all the pending transactions to be processed. Proceeding with migrating the session state data without processing the pending transactions would be problematic because the pending transactions would be left stuck in the first connection and could not be migrated. Accordingly, if there were pending transactions during migration, the migrated data would be incomplete with missing information, for example, missing response/request, only including a beginning of a response/request, only including a middle of the response/request or only including an ending of a response/request. As a result to avoid these issues the primary server device 14a waits before initiating any migration of the session until all of the pending transactions have been completed between the client device 16a(1) and itself.


In step 12, the primary server device 14a of the network traffic management system 10 migrates the MPTCP session state data associated with the client-server pair flow transactions to one of the secondary server devices 15a(1)-15a(n). By way of example, the secondary server device 15a(1) is the one of the secondary server devices 15a(1)-15a(n) that the MPTCP session state data is migrated to by the primary server device 14a although the MPTCP session state data may be migrated any of the secondary server devices 15a(1)-15a(n).


The migration of the MPTCP session state data associated with the client-server pair flow transactions to the secondary server device 15a(1) upon determining that all of the pending client server pair flow transactions have been completed. The migration of the MPTCP session date to one or more secondary server devices 15a(1)-15a(n) is based on the indication received in step 510. When the indication received in step 510 is based on a determination that the session of the primary server device 14a accessed by the client device 16a(1) is a long lived session and that has reached its maximum peak load capacity or has reached a predetermined load capacity limit, then a determination is made that the session is to be handled by the secondary server device 15a(1) that is capable of handling the traffic load, then the session is migrated to the secondary server device 15a(1) that is capable of handling the traffic load. When the indication received in step 510 is based on a determination that the type of content of the session handled by the primary server device 14a is to be handled by the secondary server device 15a(1) that is dedicated to handle that type of content, then the session is migrated to the secondary server device 15a(1) associated with the dedicated to handle that type of content. When the indication received in step 510 is based on determination that the client device 16a(1) could be potentially a malicious user or a potential security threat and that the session is to be handled by a secondary server device 15a(1) dedicated to handle threats, such as a DOS attack, viruses, or any malicious content by way of example, then the session is migrated to a secondary server device 15a(1) dedicated to handle threats such as a DOS attack, viruses or any malicious content, although other types of policies and ways may be implemented for migrating the MPTCP session data. With MPTCP migration the sockets used in the transport layer are switched from the primary server device 14a to the secondary server device 15a(1). As these sockets are in the transport layer, the application layer of the devices is not disturbed and they continue processing and servicing the requested content between the client device 16a and the secondary server device 15a(1). As a result the client device 16a(1) is not affected and keeps on receiving the requested data seamlessly without any discontinuity. In another example, the primary server device 14a of the network traffic management system 10 migrates the MPTCP session state data associated with the client-server pair flow transactions to a plurality of secondary server devices 15a(1)-15a(n).


In step 13, the primary server device 14a of the network traffic management system 10 determines when all of the MPTCP session state data has been migrated. Upon determining that all of the MPTCP session state data associated with the first connection between the client device 16a(1) and the primary server device 14a has been migrated to the one of the secondary server device 15a(1) then the primary server device 14a moves to step 14.


Back in step 13, the primary server device 14a of the network traffic management system determines loops back to repeat the determination if all of the MPTCP session state data has been migrated when it determines that the all of the MPTCP session state data has not been migrated to the secondary server device 15a(1).


In step 14, the primary server device 14a of the network traffic management system 10 advertises the identifier of the secondary server device 15a(1) to which the MPTCP session state data has been migrated to in step 550. The secondary server device identifier includes an IP address associated with the secondary server device 15a(1) or any type of identifier associated.


In step 15, the client device 16a(1) sends a MPTCP join request to the secondary server device 15a(1) to establish a connection with the secondary server device 15a(1). The MPTCP join request is to join the previously established MPTCP session between the primary server device 14a and with the client device 16a(1) requesting the content.


In step 16, upon receiving the MPTCP join request, the secondary server device 15a(1) establishes a second connection with the client device 16a(1) by joining to the previously established MPTCP session.


In step 17, receive by the primary server device 14a of the network traffic management system an indicator from the secondary server device 15a(1) indicating that the client device 16a(1) is connected to the secondary server device 15a(1) and the secondary server device 15a(1) has joined the previously established MPTCP session. The received indicator indicating that the secondary server device utilizes the transmitted MPTCP session state data to connect and join the MPTCP session previously established between the primary server device and the client device. The indicator further indicates that the client device is now connected to the secondary server device and transmitting data based on the previously established MPTCP session.


In step 18, once primary server device 14a of the network traffic management system 10 terminates the first connection between the client device 16a(1) and itself. Once the primary server device 14a of the network traffic management system 10 receives an indicator of step 580 from the secondary server device 15a(1), then the primary server device 14a terminates the first connection between the client device 16a(1) and itself.


Referring to FIG. 3, an exemplary network environment which incorporates an exemplary network traffic management system 11 is illustrated. The network traffic management system 11 in this example includes a primary network traffic management apparatus 14b that is coupled to a secondary network traffic management apparatus pool including a plurality of secondary network traffic management apparatus 15b(1)-15b(n), a remote server device pool including a plurality of remote server devices 17(1)-17(n) and a plurality of client devices 16b(1)-16b(n) via communication network(s) 18b, although the primary network traffic management apparatus 14b, the plurality of secondary network traffic management apparatus 15b(1)-15b(n), the remote server devices 17(1)-17(n), and/or client devices 16b(1)-16b(n) may be coupled together via other topologies. Additionally, the network traffic management system 11 may include other network devices such as one or more routers and/or switches, for example, which are well known in the art and thus will not be described herein. This technology provides a number of advantages including methods, non-transitory computer readable media, network traffic management systems, and network traffic management apparatuses that provides an optimized process of transitioning a TCP connection from one device to another device by using features provided by multipath transmission control protocol (MPTCP) to enable an improved session migration. Further, the session migration is performed without involving the application layer involved in the request response pair which results in evading any discontinuity in communication of data to the client device and further enables TCP session migration during device maintenance.


In this particular example, the primary network traffic management apparatus 14b, the secondary network traffic management apparatus 15b(1)-15b(n), the plurality of remote server devices 17(1)-17(n) and the plurality of client devices 16a(1)-16a(n) are disclosed in FIG. 1 as dedicated hardware devices. However, one or more of the primary network traffic management apparatus 14b and the secondary network traffic management apparatus 15b(1)-15b(n), the plurality of remote server devices 17(1)-17(n) or client devices 16a(1)-16a(n) can also be implemented in software within one or more other devices in the network traffic management system 10. As used herein, the term “module” refers to either an implementation as a dedicated hardware device or apparatus, or an implementation in software hosted by another hardware device or apparatus that may be hosting one or more other software components or implementations.


As one example, the primary network traffic management apparatus 14b, as well as any of its components, models, or applications, can be a module implemented as software executing on one of the secondary network traffic management apparatus 15b(1)-15b(n), and many other permutations and types of implementations can also be used in other examples. Moreover, any or all of the primary network traffic management apparatus 14b, secondary network traffic management apparatus 15b(1)-15b(n), remote server devices 17(1)-17(n) and client devices 16(1)-16(n), can be implemented, and may be referred to herein, as a module.


Referring to FIG. 3 and FIGS. 4A-4B, the primary network traffic management apparatus 14b of the network traffic management system 11 may perform any number of functions including migrating sessions between devices, managing network traffic, load balancing network traffic across the communication network 18b, global load balancing network traffic, identifying potential security threats to the network traffic, accelerating network traffic associated with web applications hosted by the remote server devices 17(1)-17(n). The primary network traffic management apparatus 14b of FIG. 4A in this example includes one or more processors 29b, a memory 26b, and/or a communication interface 30b, which are coupled together by a bus 19b or other communication link, although the primary network traffic management apparatus 14b can include other types and/or numbers of elements in other configurations.


The processor(s) 29b of the primary network traffic management apparatus 14b may execute programmed instructions stored in the memory 26b of the primary network traffic management apparatus 14b for the any number of the functions identified above. The processor(s) 29b of the primary network traffic management apparatus 14b may include one or more CPUs or general purpose processors with one or more processing cores, for example, although other types of processor(s) can also be used.


The memory 26b of the primary network traffic management apparatus 14b 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 elsewhere. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk, solid state drives, flash memory, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor(s) 29b, can be used for the memory 26b.


Accordingly, the memory 26b of the primary network traffic management apparatus 14b can store one or more applications that can include computer executable instructions that, when executed by the primary network traffic management apparatus 14b, cause the primary network traffic management apparatus 14b to perform actions, such as to transmit, receive, or otherwise process messages, for example, and to perform other actions described and illustrated below with reference to FIGS. 7-8. The application(s) can be implemented as modules or components of other applications. Further, the application(s) can be implemented as operating system extensions, module, plugins, or the like.


Even further, the application(s) may be operative in a cloud-based computing environment. The application(s) can be executed within or as virtual machine(s) or virtual server(s) that may be managed in a cloud-based computing environment. Also, the application(s), and even the primary network traffic management apparatus 14b itself, may be located in virtual server(s) running in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Also, the application(s) may be running in one or more virtual machines (VMs) executing on the network traffic management apparatus. Additionally, in one or more embodiments of this technology, virtual machine(s) running on the primary network traffic management apparatus 14b may be managed or supervised by a hypervisor.


In this particular example, the memory 26b of the primary network traffic management apparatus 14b includes session data storage 25b and profile data storage 28b, although the memory can include other types and/or numbers of policies, modules, databases, applications, and/or other data for example.


The session data storage 25a may store information associated with tracking a request response pair session associated between the client devices 16b(1)-16b(n) and the primary traffic management apparatus 14b. The request response pair session may correspond to flow transactions performed between a client device and a server device forming a client-server pair flow transactions. The flow transactions may include information about accessing by the client devices 16b(1)-16b(n) content at the primary traffic management apparatus 14b to form a session. The session data storage 25b information may also be used to determine when a session is completely migrated to an another device. By way of example, the another device may include the secondary traffic management apparatus 15b(1)-15b(n).


The profile data storage 28b may store information associated with server load, server location, and/or monitoring user traffic data, although other types of data may be stored. The server load may include, for example, information associated with load capacity of the server and/or the peak load capacity of the server. The stored information may include other information, for example information on which of the client device 16b(1)-16b(n) accesses which of the server devices 17(1)-17(n) at which location over a period of time. The stored information may also identify the one of the secondary network traffic management apparatus 15b(1)-15b(n) as a home server device for one of the client devices 16b(1)-16b(n), based on a determination that the one of the client devices 16b(1)-16b(n) accesses one of the secondary network traffic management apparatus 15b(1)-15b(n) regularly. Further, the stored information may also identify one of the secondary network traffic management apparatus 15b(1)-15b(n) as an away server device for one of the client devices 16b(1)-16b(n), based on determining that the one of the client devices 16b(1)-16b(n) does not access the one of the secondary network traffic management apparatus 15b(1)-15b(n) regularly, although other manners for determining home and/or away server devices for one or more client devices 16b(1)-16b(n) may be used. The stored information may also include user traffic data associated with the client device such as, tracked historical session information associated with the client devices 16b(1)-16b(n) over a period of time, although other type of information may be stored. The tracked historical information may include tracked information on various user activity, such as frequency of accessing websites by the client devices 16b(1)-16b(n), types of activity associated with the websites, historical shopping activity, and/or network activity any other activities in association with websites by way of example. The stored information may or may not identify one of the client devices 16b(1)-16b(n) as a known client device and/or may or may not store a classification of the one of the client devices 16b(1)-16b(n) as a safe device based on any identified security threat associated with that one of the client devices 16b(1)-16b(n). Further the stored information may identify the primary network traffic management apparatus 14b that will best service a request based on the location and historical information associated with the client devices 16b(1)-16b(n) as explained below.


Referring back to FIG. 3 and FIGS. 4A-4B, the communication interface 30b of the network traffic management apparatus operatively couples and communicates between the primary network traffic management apparatus 14b, the plurality of secondary network traffic management apparatus 15b(1)-15b(n), the remote server devices 17(1)-17(n), and/or the client devices 16b(1)-16b(n), which are all coupled together by the communication network(s) 18b, although other types and/or numbers of communication networks or systems with other types and/or numbers of connections and/or configurations to other devices and/or elements can also be used.


By way of example only, the communication network(s) 18b can include local area network(s) (LAN(s)) or wide area network(s) (WAN(s)), and can use TCP/IP over Ethernet and industry-standard protocols, although other types and/or numbers of protocols and/or communication networks can be used. The communication network(s) 18b in this example can employ any suitable interface mechanisms and network communication technologies including, for example, 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.


While the primary network traffic management apparatus 14b is illustrated in this example as a including a single device, the primary network traffic management apparatus 14b in other examples can include one or more of the secondary server devices 15a(1)-15a(n). While each of the primary network traffic management apparatus 14b, the plurality of secondary network traffic management apparatus 15b(1)-15b(n), and the remote server devices 17(1)-17(n) is illustrated in this example as including a single device, the primary network traffic management apparatus 14b and the secondary network traffic management apparatus 15b(1)-15b(n) in other examples can include a plurality of devices or blades each having one or more processors (each processor with one or more processing cores) that implement one or more steps of this technology. In these examples, one or more of the devices can have a dedicated communication interface or memory. Alternatively, one or more of the devices can utilize the memory, communication interface, or other hardware or software components of one or more other devices included in the primary network traffic management apparatus 14b. Although the primary network traffic management apparatus 14b is illustrated as single device, there may be one or more primary network traffic management apparatus 14b connected to one or more secondary network traffic management apparatus 15b(1)-15b(n).


Additionally, one or more of the devices that together comprise the primary network traffic management apparatus 14b in other examples can be standalone devices or integrated with one or more other devices or apparatuses, such as one of the server devices, for example. Moreover, one or more of the devices of the network traffic management apparatus 14b in these examples can be in a same or a different communication network including one or more public, private, or cloud networks, for example.


Each of the remote server devices 17(1)-17(n) in the remote server device pool of the network traffic management system 11 in this example includes one or more processors, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. The remote server devices 17(1)-17(n) in this example process requests received from the client devices 16b(1)-16b(n) via the communication network(s) 18b according to the HTTP-based application RFC protocol, for example. Various applications may be operating on the remote server devices 17(1)-17(n) and transmitting data (e.g., files or web pages) to the client devices 16b(1)-16b(n) via the primary network traffic management apparatus 14b in response to requests from the client devices 16b(1)-16b(n). The remote server devices 17(1)-17(n) may be hardware or software or may represent a system with multiple servers in a pool, which may include internal or external networks.


Although the remote server devices 17(1)-17(n) are illustrated as single devices, one or more actions of each of the remote server devices 17(1)-17(n) may be distributed across one or more distinct network computing devices that together comprise one or more of the remote server devices 17(1)-17(n). Moreover, the remote server devices 17(1)-17(n) are not limited to a particular configuration. Thus, the remote server devices 17(1)-17(n) may contain a plurality of network computing devices that operate using a master/slave approach, whereby one of the network computing devices of the remote server devices 17(1)-17(n) operate to manage and/or otherwise coordinate operations of the other network computing devices. The remote server devices 17(1)-17(n) may operate as a plurality of network computing devices within a cluster architecture, a peer-to peer architecture, virtual machines, or within a cloud architecture, for example.


Thus, the technology disclosed herein is not to be construed as being limited to a single environment and other configurations and architectures are also envisaged. For example, one or more of the remote server devices 17(1)-17(n) can operate within the primary network traffic management apparatus 14b itself rather than as a stand-alone server device communicating with the primary network traffic management apparatus 14b via the communication network(s) 18b. In this example, the one or more remote server devices 17(1)-17(n) operate within the memory 26b of the primary network traffic management apparatus 14b.


The client devices 16b(1)-16b(n) of the network traffic management system 11 in this example include any type of computing device that can receive, render, and facilitate user interaction with a webtop, such as mobile computing devices, desktop computing devices, laptop computing devices, tablet computing devices, virtual machines (including cloud-based computers), or the like. Each of the client devices 16b(1)-16b(n) 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 numbers and/or types of network devices could be used.


The client devices 16b(1)-16b(n) may run interface applications, such as standard web browsers or standalone client applications, which may provide an interface to make requests for, and receive content stored on, one or more of the primary network traffic management apparatus 14b, the secondary network traffic management apparatus 15b(1)-15b(n) via the communication network(s) 18a. The client devices 16b(1)-16b(n) may further include a display device, such as a display screen or touchscreen, and/or an input device, such as a keyboard for example. Additionally, one or more of the client devices 16b(1)-16b(n) can be configured to execute software code (e.g., JavaScript code within a web browser) in order to log client-side data and provide the logged data to the primary network traffic management apparatus 14b, as described and illustrated in more detail later.


Although the exemplary network traffic management system 11 with the primary network traffic management apparatus 14b, the plurality of secondary network traffic management apparatus 15b(1)-15b(n), the remote server devices 17(1)-17(n), the client devices 16b(1)-16b(n), and communication network(s) 18b are described and illustrated herein, other types and/or numbers of systems, devices, components, and/or elements in other topologies can be used. It is to be understood that 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).


One or more of the components depicted in the network traffic management system 11, such as the primary network traffic management apparatus 14b, the plurality of secondary network traffic management apparatus 15b(1)-15b(n), the remote server devices 17(1)-17(n) or the client devices 16b(1)-16b(n), for example, may be configured to operate as virtual instances on the same physical machine. In other words, one or more of the primary network traffic management apparatus 14b, client devices 16b(1)-16b(n), or the remote server devices 17(1)-17(n) may operate on the same physical device rather than as separate devices communicating through communication network(s) 18b. Additionally, there may be more or fewer the primary network traffic management apparatus 14b, the plurality of secondary network traffic management apparatus 15b(1)-15b(n), the remote server devices 17(1)-17(n) or the client devices 16b(1)-16b(n) than illustrated in FIG. 3.


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 networks, cellular traffic networks, Packet Data Networks (PDNs), the Internet, intranets, and combinations thereof.


Further, the configuration of the secondary network traffic management apparatus 15b(1)-15b(n) is similar to the primary network traffic management apparatus 14b. Referring to FIG. 4B, the secondary network traffic management apparatus 15b(1) of the network traffic management system 11 may perform any number of functions including migrating sessions between devices, managing network traffic, load balancing network traffic across the server devices, global load balancing network traffic, identifying potential security threats to the network traffic, accelerating network traffic associated with web applications hosted by the server devices. By way of example, one of the plurality of secondary network traffic management apparatus 15b(1)-15b(n) is show in FIG. 4B. In this example, the secondary network traffic management apparatus 15b(1) of FIG. 4B includes one or more processors 29b, a memory 26b, and/or a communication interface 30b, which are coupled together by a bus 19b or other communication link, although the primary network traffic management apparatus 14b can include other types and/or numbers of elements in other configurations. Further, the configurations of the each of the secondary network traffic management apparatus 15b(1)-15b(n) is similar to the primary network traffic management apparatus 14b as explained above.


The examples may also be embodied as one or more 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. The instructions in some examples include executable code that, when executed by one or more processors, cause the processors to carry out steps necessary to implement the methods of the examples of this technology that are described and illustrated herein.


An exemplary method of multipath transmission control protocol (MPTCP) based session migration and devices will now be described with reference to FIGS. 3-4, 7-8. Referring more specifically to FIG. 7, in a first step 700 in this example, the primary computing device of the network traffic management system 11 monitors client-server pair flow transactions between the client device 16b(1)-16b(n) and one or more remote server devices 17(1)-17(n) over an established connection. By way of example, the primary computing device in this example is the primary network traffic management apparatus 14b of FIG. 3, although the primary computing device could be any other device. By way of example, a client device 16b(1) sends a SYN request including a MPTCP connection request to the primary network traffic management apparatus 14b. In response to the SYN request the primary network traffic management apparatus 14b sends a transmit SYN acknowledgement message to acknowledge receiving the SYN request to the client device 16b(1). Upon receiving the SYN acknowledgment the primary network traffic management apparatus 14b and the client device 16b(1) establishes a first MPTCP session and exchanges MPTCP session data between them. Further, the primary network traffic management apparatus 14b receives from the client device 16b(1) a client access request to access applications at one or more of the remote server devices 17(1)-17(n). Upon receiving the client access request the primary network traffic management apparatus 14b transmits to the client device 16b(1) an acknowledgment for the client access request, to acknowledge receiving of the client access request. The primary network traffic management apparatus 14b then forwards the client access request to the one or more remote server devices 17(1)-17(n) associated with servicing the request. The primary network traffic management apparatus 14b then receives a server response from the one or more remote server devices 17(1)-17(n) granting access to the application content requested by the client device 16b(1). The primary network traffic management apparatus 14b then sends the server response to the client device 16b(1) and the client device 16b(1) then accesses the one or more remote server devices 17(1)-17(n) and thus establishing a first connection to transmit and receive content. The primary network traffic management apparatus 14b manages the first connection by monitoring and storing monitors and stores session information associated with tracking a request response pair session associated between the client device 16b(1) and one or more of the remote server devices 17(1)-17(n) in the session data storage 25b. This session information may include MPTCP session data exchanged between the client devices 16b(1) and the primary network traffic management apparatus 14b, and further may also include MPTCP session data exchanged between the primary network traffic management apparatus 14b and the one or more remote server devices 17(1)-17(n). The request response pair session corresponds to flow transactions performed between the client device 16b(1) and the remote server devices 17(1)-17(n) forming a client-server pair flow transactions. Further, the flow transactions may include accessing by the client device 16b(1) content at the remote server devices 17(1)-17(n) to form a session.


In step 710, the primary network traffic management apparatus 14b of the network traffic management system 11 receives an indication for migrating multipath transmission control protocol (MPTCP) session state data associated with the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) to one or more of the secondary computing devices. By way of example, the one or more secondary computing devices in this example are the one or more secondary network traffic management apparatus 15b(1)-15b(n) in the secondary network traffic management apparatus pool of FIG. 1, although the secondary computing could be any other device. In this example, the primary computing device is the primary network traffic management apparatus 14b and the one or more secondary computing devices are the one or more secondary network traffic management apparatus 15b(1)-15b(n).


Receiving the indication may include, for example, receiving the indication automatically based on predefined policies. The predefined polices associated with automatically receiving an indication for migrating the MPTCP sessions may include migration policies stored in the profile data storage 28b. The primary network traffic management apparatus 14b analyzes the migration policies to determine corresponding actions associated with those migration policies.


The migration policies include analyzing the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b to determine the type of content within the client-server pair flow transactions. When the type of content is determined to be a potential malicious content or a potential security threat, then the migration policy would migrate the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b to the secondary network traffic management apparatus 15b(1) acting as an authentication entity and dedicated to handle that type of content. In this example, the secondary network traffic management apparatus 15b(1) is dedicated to handle these threats which may include, for example, a DOS attack, viruses or any malicious content. In another example, the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b can be migrated to a plurality of secondary network traffic management apparatus 15b(1)-15b(n).


By way of example, there are various ways to receive an indication for migrating the MPTCP session state data, for example, based on a user selection at a user interface or automatically based predefined polices associated with the network traffic. The session state data may include, for example, requests, responses, session protocol information and any information in relation to the client-server pair transactions. Further receiving the indication may include, receiving an indication based on a user selection at a user interface, for example, from an administrator associated with managing the network traffic. When the administrator wants to offline the primary network traffic management apparatus 14b for maintenance purposes, the administrator may use a user interface to provide the indication. For example, when it is determined by the primary network traffic management apparatus 14b that primary network traffic management apparatus 14b accessed by the client device 16b(1) is an away service device and then the action associated with a migration policy is that, this session is to be transmitted and handled by one or more of the secondary network traffic management apparatus 15b(1)-15b(n) that is a home service device. The home service device is a device accessed by the client device 16b(1) on a frequent basis over a period of time and an away server device is a device accessed by the client device 16b(1) for the first time or less frequently. Further, in another example, when it is determined that the primary network traffic management apparatus 14b servicing a request for the client device 16b(1) has a long lived session, and has reached its maximum peak load capacity or based on a pre determined load capacity limit then the action with another migration policy is that the session is to be handled by one or more of the secondary network traffic management apparatus 15b(1)-15b(n) that is capable to service the request. Further based on determining that the client device 16b(1) requesting the content is a potential security threat based on monitoring historical information associated with the client device 16b(1), or the client device 16(b) is accessing one or more remote server devices 17(1)-17(n) for the first time or any unusual activity associated with the client device 16b(1), then the action associated with the migration policy determines that the client device 16b(1) to be transferred to be handled by a secondary network traffic management apparatus 15b(1)-15b(n) acting as an authentication server. Although other types of policies and ways may be implemented for receiving the indication for migrating a MPTCP session data.


In step 720, the primary network traffic management apparatus 14b of the network traffic management system 11 stops transmission of acknowledgments for any new request received from the client device 16b(1). The primary network traffic management apparatus 14b may keep on receiving new client requests from the client device 16b(1) to access the one or more remote server devices 17(1)-17(n). However, the primary network traffic management apparatus 14b stops sending acknowledgments for the new client requests received the client device 16b(1) upon receiving an indication to migrate the MPTCP session state data.


In step 730, the primary network traffic management apparatus 14b of the network traffic management system 11 waits for completion of any pending client-server pair flow transactions. The primary network traffic management apparatus 14b determines for the first connection established between the client device 16b(1) and the one or more remote server devices 17(1)-17(n) as having transactions that are in progress and are pending. In this example the primary network traffic management apparatus 14b waits for all the pending transactions to be processed. Proceeding with migrating the session state data without processing the pending transactions would be problematic because the pending transactions would be left stuck in the first connection and could not be migrated. Accordingly, if there were pending transactions during migration, the migrated data would be incomplete with missing information, for example, missing response/request, only including a beginning of a response/request, only including a middle of the response/request or only including an ending of a response/request. As a result to avoid these issues the primary network traffic management apparatus 14b waits before initiating any migration of the session until all of the pending transactions have been completed between the client device and the server device(s).


In step 740, the primary network traffic management apparatus 14b of the network traffic management system 11 migrates the MPTCP session state data associated with the client-server pair flow transactions to one of the secondary server devices 15b(1)-15b(n). By way of example, the secondary network traffic management apparatus 15b(1) is the one of the secondary network traffic management apparatus 15b(1)-15b(n) that the MPTCP session state data is migrated to, by the primary server device 14a although the MPTCP session state data may be migrated any of the secondary network traffic management apparatus 15b(1)-15b(n).


The migration of the MPTCP session state data associated with the client-server pair flow transactions to the secondary network traffic management apparatus 15b(1) is initiated upon determining that all of the pending client server pair flow transactions have been completed. The migration of the MPTCP session date to one or more secondary network traffic management apparatus 15a(1)-15a(n) is based on the indication received in step 710. When the indication received in step 710 is based on the type of content determined to be a potential malicious content or a potential security threat, then the migration policy would migrate the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b to the secondary network traffic management apparatus 15b(1) acting as an authentication entity and dedicated to handle that type of content. In this example, the secondary network traffic management apparatus 15b(1) is dedicated to handle these threats which may include, for example, a DOS attack, viruses or any malicious content.


By way of example when the indication received in step 710 is based on a determination that the session of the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b is a long lived session and that has reached its maximum peak load capacity or has reached a predetermined load capacity limit, then a determination is made that the session is to be handled by the secondary network traffic management apparatus 15b(1) that is capable of handling the traffic load, then the session is migrated to the secondary network traffic management apparatus 15b(1) that is capable of handling the traffic load. When the indication received in step 710 is based on determination that the client device 16b(1) could be potentially a malicious user or a potential security threat and that the session is to be handled by a secondary server device 15b(1) dedicated to handle threats, such as a DOS attack, viruses, or any malicious content by way of example, then the session is migrated to a secondary server device 15b(1) dedicated to handle threats such as a DOS attack, viruses or any malicious content, although other types of policies and ways may be implemented for migrating the MPTCP session data. With MPTCP migration the sockets used in the transport layer are switched from the primary server device 14b to the secondary server device 15b(1). As these sockets are in the transport layer, the application layer of the devices is not disturbed and they continue processing and servicing the requested content between the client device 16b and the secondary server device 15b(1). As a result the client device 16b(1) is not affected and keeps on receiving the requested data seamlessly without any discontinuity. In another example, the primary server device 14b of the network traffic management system 10 migrates the MPTCP session state data associated with the client-server pair flow transactions to a plurality of secondary server devices 15b(1)-15b(n).


In step 750, the primary network traffic management apparatus 14b of the network traffic management system 11 determines when all of the MPTCP session state data of the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b has been migrated to the secondary network traffic management apparatus 15b(1). The primary network traffic management apparatus moves to step 760 when it determines that all of the MPTCP session state data associated with the first connection between the client device 16b(1) and the remote server devices 17(1)-17(n) has been migrated to the secondary network traffic management apparatus 15b(1). If in step 750, the primary network traffic management apparatus 14b of the network traffic management system 11 determines all of the MPTCP session state data has not migrated, then the No branch is taken to continue the migration. If in step 750, the primary network traffic management apparatus 14b of the network traffic management system 11 determines all of the MPTCP session state data has been migrated, then the Yes branch is taken to step 760.


In step 760, the primary network traffic management apparatus 14b of the network traffic management system 11 advertises the identifier of the secondary traffic management apparatus 15b(1) to which the MPTCP session state data has been migrated to in step 750. The secondary traffic management apparatus 15b(1) identifier includes an IP address associated with the secondary traffic management apparatus 15b(1) or any type of identifier associated.


In step 770, the primary network traffic management apparatus 14b of the network traffic management system 11 receives an indicator from the secondary traffic management apparatus 15b(1) indicating that the client device 16b is connected to the remote server device 17(1)-17(n) and the secondary traffic management apparatus 15b(1) has joined the previously established MPTCP session. The received indicator indicating that the secondary traffic management apparatus 15b(1) utilizes the transmitted MPTCP session state data to connect with the server device (s) and further to join the MPTCP session previously established between the primary traffic management apparatus 14b and the remote server devices 17(1)-17(n). The indicator further indicates that the client device is now connected to the server device(s) via the secondary traffic management apparatus 15b(1) and transmitting data based on the previously established MPTCP session.


In step 780, once the primary network traffic management apparatus 14b of the network traffic management system 11 receives an indicator of step 780 from the second traffic management apparatus 15b(1), then the primary network traffic management apparatus 14b terminates the first connection between the client device 16b(1) and the remote server devices 17(1)-17(n).


Referring more specifically to FIG. 8, a timing diagram of an exemplary method of is illustrated. In a first step 1 in this example, the client device 16b(1) sends a SYN request including a MPTCP connection request to the primary network traffic management apparatus 14b to establish a connection with the remote server device 17 (1). The primary network traffic management apparatus 14b of the network traffic management system 11 receives the SYN request.


In step 2, the primary network traffic management apparatus 14b of the network traffic management system 11 in response to receiving the SYN request from the client device 16b(1) sends a transmit SYN acknowledgement message to acknowledge receiving the SYN request to the client device 16b(1).


In step 3, the primary network traffic management apparatus 14b of the network traffic management system 11 establishes a first MPTCP session. Upon receiving the SYN acknowledgment the primary network traffic management apparatus 14b and the client device 16b(1) establishes a first MPTCP session and exchanges MPTCP session data between them.


In step 4, the primary network traffic management apparatus 14b of the network traffic management system 11 receives a first client access request to access applications at the remote server device 17(1). The first client access request is to access application content at the remote server device 17(1).


In step 5, the primary network traffic management apparatus 14b of the network traffic management system 11 transmits an acknowledgment message in response. Upon receiving the client access request the primary network traffic management apparatus 14b transmits to the client device 16b(1) an acknowledgment for the client access request, to acknowledge receiving of the client access request.


In step 6, the primary network traffic management apparatus 14b of the network traffic management system 11 then forwards the first client access request to the remote server device 17(1) associated with servicing the request.


In step 7, the primary network traffic management apparatus 14b of the network traffic management system 11 then receives a server response from the remote server device 17(1) granting access to the application content requested by the client device 16b(1).


In step 8, the primary network traffic management apparatus 14b of the network traffic management system 11 then sends the server response to the client device 16b(1) and the client device 16b(1) then accesses the requested at the remote server device 17(1) and thus establishing a first connection to transmit and receive content and to complete a client-server pair flow transaction. The primary network traffic management apparatus 14b manages the first connection by monitoring and storing monitors and stores session information associated with tracking a request response pair session associated between the client device 16b(1) and the remote server device 17(1) in the session data storage 31b. This session information may include MPTCP session data exchanged between the client device 16b(1) and the primary network traffic management apparatus 14b, and further may also include MPTCP session data exchanged between the primary network traffic management apparatus 14b and the remote server device 17(1). The request response pair session corresponds to flow transactions performed between the client device 16b(1) and the remote server device 17(1) forming a client-server pair flow transactions. Further, the flow transactions may include accessing by the client device 16b(1) content at the remote server device 17(1) to form a session.


In step 9, the primary network traffic management apparatus 14b of the network traffic management system 11 receives an indication for migrating multipath transmission control protocol (MPTCP) session state data associated with the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) to one or more of the secondary computing devices. By way of example, the one or more secondary computing devices in this example are the one or more secondary network traffic management apparatus 15b(1)-15b(n) in the secondary network traffic management apparatus pool of FIG. 1, although the secondary computing could be any other device. In this example, the primary computing device is the primary network traffic management apparatus 14b and the one or more secondary computing devices are the one or more secondary network traffic management apparatus 15b(1)-15b(n).


Receiving the indication may include, for example, receiving the indication automatically based on predefined policies. The predefined polices associated with automatically receiving an indication for migrating the MPTCP sessions may include migration policies stored in the profile data storage 28b. The primary network traffic management apparatus 14b analyzes the migration policies to determine corresponding actions associated with those migration policies.


The migration policies include analyzing the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b to determine the type of content within the client-server pair flow transactions. When the type of content is determined to be a potential malicious content or a potential security threat, then the migration policy would migrate the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b to the secondary network traffic management apparatus 15b(1) acting as an authentication entity and dedicated to handle that type of content. In this example, the secondary network traffic management apparatus 15b(1) is dedicated to handle these threats which may include, for example, a DOS attack, viruses or any malicious content. In another example, the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b can be migrated to a plurality of secondary network traffic management apparatus 15b(1)-15b(n).


By way of example, there are various ways to receive an indication for migrating the MPTCP session state data, for example, based on a user selection at a user interface or automatically based predefined polices associated with the network traffic. The session state data may include, for example, requests, responses, session protocol information and any information in relation to the client-server pair transactions. Further receiving the indication may include, receiving an indication based on a user selection at a user interface, for example, from an administrator associated with managing the network traffic. When the administrator wants to offline the primary network traffic management apparatus 14b for maintenance purposes, the administrator may use a user interface to provide the indication. For example, when it is determined by the primary network traffic management apparatus 14b that primary network traffic management apparatus 14b accessed by the client device 16b(1) is an away service device and then the action associated with a migration policy is that, this session is to be transmitted and handled by one or more of the secondary network traffic management apparatus 15b(1)-15b(n) that is a home service device. The home service device is a device accessed by the client device 16b(1) on a frequent basis over a period of time and an away server device is a device accessed by the client device 16b(1) for the first time or less frequently. Further, in another example, when it is determined that the primary network traffic management apparatus 14b servicing a request for the client device 16b(1) has a long lived session, and has reached its maximum peak load capacity or based on a pre determined load capacity limit then the action with another migration policy is that the session is to be handled by one or more of the secondary network traffic management apparatus 15b(1)-15b(n) that is capable to service the request. Further based on determining that the client device 16b(1) requesting the content is a potential security threat based on monitoring historical information associated with the client device 16b(1), or the client device 16(b) is accessing one or more remote server devices 17(1)-17(n) for the first time or any unusual activity associated with the client device 16b(1), then the action associated with the migration policy determines that the client device 16b(1) to be transferred to be handled by a secondary network traffic management apparatus 15b(1)-15b(n) acting as an authentication server. Although other types of policies and ways may be implemented for receiving the indication for migrating a MPTCP session data.


In step 10, the primary network traffic management apparatus 14b of the network traffic management system 11 stops transmission of acknowledgments for any new request received from the client device 16b(1). The primary network traffic management apparatus 14b may keep on receiving new client requests from the client device 16b(1) to access the one or more remote server devices 17(1)-17(n). However, the primary network traffic management apparatus 14b stops sending acknowledgments for the new client requests received the client device 16b(1) upon receiving an indication to migrate the MPTCP session state data.


In step 11, the primary network traffic management apparatus 14b of the network traffic management system 11 waits for completion of any pending client-server pair flow transactions. The primary network traffic management apparatus 14b determines for the first connection established between the client device 16b(1) and the one or more remote server devices 17(1)-17(n) as having transactions that are in progress and are pending. In this example the primary network traffic management apparatus 14b waits for all the pending transactions to be processed. Proceeding with migrating the session state data without processing the pending transactions would be problematic because the pending transactions would be left stuck in the first connection and could not be migrated. Accordingly, if there were pending transactions during migration, the migrated data would be incomplete with missing information, for example, missing response/request, only including a beginning of a response/request, only including a middle of the response/request or only including an ending of a response/request. As a result to avoid these issues the primary network traffic management apparatus 14b waits before initiating any migration of the session until all of the pending transactions have been completed between the client device and the server device(s).


In step 12, the primary network traffic management apparatus 14b of the network traffic management system 11 waits for completion of any pending client-server pair flow transactions. The primary network traffic management apparatus 14b determines for the first connection established between the client device 16b(1) and the one or more remote server devices 17(1)-17(n) as having transactions that are in progress and are pending. In this example the primary network traffic management apparatus 14b waits for all the pending transactions to be processed. Proceeding with migrating the session state data without processing the pending transactions would be problematic because the pending transactions would be left stuck in the first connection and could not be migrated. Accordingly, if there were pending transactions during migration, the migrated data would be incomplete with missing information, for example, missing response/request, only including a beginning of a response/request, only including a middle of the response/request or only including an ending of a response/request. As a result to avoid these issues the primary network traffic management apparatus 14b waits before initiating any migration of the session until all of the pending transactions have been completed between the client device and the server device(s).


In step 13, the primary network traffic management apparatus 14b of the network traffic management system 11 migrates the MPTCP session state data associated with the client-server pair flow transactions to one of the secondary server devices 15b(1)-15b(n). By way of example, the secondary network traffic management apparatus 15b(1) is the one of the secondary network traffic management apparatus 15b(1)-15b(n) that the MPTCP session state data is migrated to, by the primary server device 14a although the MPTCP session state data may be migrated any of the secondary network traffic management apparatus 15b(1)-15b(n).


The migration of the MPTCP session state data associated with the client-server pair flow transactions to the secondary network traffic management apparatus 15b(1) is initiated upon determining that all of the pending client server pair flow transactions have been completed. The migration of the MPTCP session date to one or more secondary network traffic management apparatus 15a(1)-15a(n) is based on the indication received in step 710. When the indication received in step 710 is based on the type of content determined to be a potential malicious content or a potential security threat, then the migration policy would migrate the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b to the secondary network traffic management apparatus 15b(1) acting as an authentication entity and dedicated to handle that type of content. In this example, the secondary network traffic management apparatus 15b(1) is dedicated to handle these threats which may include, for example, a DOS attack, viruses or any malicious content.


By way of example when the indication received in step 710 is based on a determination that the session of the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b is a long lived session and that has reached its maximum peak load capacity or has reached a predetermined load capacity limit, then a determination is made that the session is to be handled by the secondary network traffic management apparatus 15b(1) that is capable of handling the traffic load, then the session is migrated to the secondary network traffic management apparatus 15b(1) that is capable of handling the traffic load. When the indication received in step 710 is based on determination that the client device 16b(1) could be potentially a malicious user or a potential security threat and that the session is to be handled by a secondary server device 15b(1) dedicated to handle threats, such as a DOS attack, viruses, or any malicious content by way of example, then the session is migrated to a secondary server device 15b(1) dedicated to handle threats such as a DOS attack, viruses or any malicious content, although other types of policies and ways may be implemented for migrating the MPTCP session data. With MPTCP migration the sockets used in the transport layer are switched from the primary server device 14b to the secondary server device 15b(1). As these sockets are in the transport layer, the application layer of the devices is not disturbed and they continue processing and servicing the requested content between the client device 16b and the secondary server device 15b(1). As a result the client device 16b(1) is not affected and keeps on receiving the requested data seamlessly without any discontinuity. In another example, the primary server device 14b of the network traffic management system 10 migrates the MPTCP session state data associated with the client-server pair flow transactions to a plurality of secondary server devices 15b(1)-15b(n).


In step 14, the primary network traffic management apparatus 14b of the network traffic management system 11 determines when all of the MPTCP session state data of the client-server pair flow transactions between the client device 16b(1) and the remote server devices 17(1)-17(n) serviced by the primary network traffic management apparatus 14b has been migrated to the secondary network traffic management apparatus 15b(1). The primary network traffic management apparatus moves to step 15 when it determines that all of the MPTCP session state data associated with the first connection between the client device 16b(1) and the remote server devices 17(1)-17(n) has been migrated to the secondary network traffic management apparatus 15b(1). If in step 14, the primary network traffic management apparatus 14b of the network traffic management system 11 determines all of the MPTCP session state data has not migrated, then the No branch is taken to continue the migration. If in step 14, the primary network traffic management apparatus 14b of the network traffic management system 11 determines all of the MPTCP session state data has been migrated, then the Yes branch is taken to step 15.


In step 15, the primary network traffic management apparatus 14b of the network traffic management system 11 advertises the identifier of the secondary traffic management apparatus 15b(1) to which the MPTCP session state data has been migrated to in step 13. The secondary traffic management apparatus 15b(1) identifier includes an IP address associated with the secondary traffic management apparatus 15b(1) or any type of identifier associated.


In step 16, the client device 16b(1) sends a MPTCP join request to establish a connection with the secondary network traffic management apparatus 15b(1). Upon receiving the MPTCP join request, the secondary network traffic management apparatus 15b(1) establishes a connection with the client device 16b(1).


In step 17, the secondary network traffic management apparatus 15b(1) sends a MPTCP join request to join the previously established MPTCP connection. The previously established MPTCP connection between the remote server device 17(1) associated with the client device 16b(1) requesting content.


In step 18, the client device 16b(1) and the remote server device 17(1) establish a second connection via the second network traffic management apparatus 15b(1) by joining to the previously established MPTCP session.


In step 19, receive an indicator from the secondary traffic management apparatus 15b(1) indicating that the client device 16b(1) is connected to the remote server 17(1) and the secondary traffic management apparatus 15b(1) has joined the previously established MPTCP session. The received indicator indicating that the secondary traffic management apparatus 15b(1) utilizes the transmitted MPTCP session state data to connect with the remote server device 17(1) and further to join the MPTCP session previously established between the primary traffic management apparatus 14b and the remote server device 17(1). The indicator further indicates that the client device 16b(1) is now connected to the remote server device 17(1) via the secondary traffic management apparatus 15b(1) and transmitting data based on the previously established MPTCP session


In step 20, once the primary network traffic management apparatus 14b of the network traffic management system 11 receives an indicator of step 19 from the second traffic management apparatus 15b(1), then the primary network traffic management apparatus 14b terminates the first connection between the client device 16b(1) and the remote server device 17(1).


Advantageously this technology, provides an optimized process of transitioning a TCP connection from one device to another by using features of multipath transmission control protocol (MPTCP) to enable session migration. With MPTCP migration the sockets used in the transport layer are switched from the primary traffic management apparatus to the secondary traffic management apparatus. As these sockets are in the transport layer, the application layer of the devices is not disturbed and they continue processing and servicing the requested content between the client device and the one or more server devices without interruption. As a result the client device is not affected and keeps on receiving the requested data seamlessly without any discontinuity, this eliminates application faults.


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 multipath transmission control protocol (MPTCP) based session migration implemented by a network traffic management system comprising one or more network traffic management apparatuses, administrator devices, client devices, or server devices, the method comprising: managing one or more client-server pair flow transactions between a client and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection;receiving an indication for migrating MPTCP session state data associated with the first MPTCP session from the primary computing device to at least one of one or more secondary computing devices, wherein the received indication is in response to analysis of one or more migration policies determining a migration is needed to mitigate a network attack;migrating the MPTCP session state data associated with the first MPTCP session to the at least one of the secondary computing devices;advertising an identifier associated with the one of the one or more secondary computing devices to the client;receiving an indication from the one of the one or more secondary computing devices indicating that a second MPTCP session has been established between the client and the one of the one or more secondary computing devices; andterminating the established first connection between the client device and the primary computing device.
  • 2. The method of claim 1, further comprising: analyzing the one or more client-server pair flow transactions between the client and the primary computing device to determine a type of content within the client-server pair flow transactions; andmigrating the MPTCP session state data associated with the first MPTCP session to the one of the one or more secondary computing devices based on the determined type of content within the client-server pair flow transactions.
  • 3. The method of claim 1, further comprising: stopping transmission of acknowledgments for any new requests received from the client upon receiving the indication for migration.
  • 4. The method of claim 1, further comprising: waiting for completion of any of the one or more client-server pair flow transactions that are pending, before migrating the MPTCP session state data.
  • 5. The method of claim 1, further comprising: determining when all of the MPTCP session state data have been migrated to the one of the one or more secondary computing devices; andterminating the established connection between the client and the one or more remote server devices when the determination indicates that all of the MPTCP session state has been migrated to the one of the one or more secondary computing devices.
  • 6. A network traffic manager apparatus, comprising memory with programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to: manage one or more client-server pair flow transactions between a client and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection;receive an indication for migrating MPTCP session state data associated with the first MPTCP session from the primary computing device to at least one of one or more secondary computing devices, wherein the received indication is in response to analysis of one or more migration policies determining a migration is needed to mitigate a network attack;migrate the MPTCP session state data associated with the first MPTCP session to the at least one of the secondary computing devices;advertise an identifier associated with the one of the one or more secondary computing devices to the client;receive an indication from the one of the one or more secondary computing devices indicating that a second MPTCP session has been established between the client and the one of the one or more secondary computing devices; andterminate the established first connection between the client device and the primary computing device.
  • 7. The apparatus of claim 6, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: analyze the one or more client-server pair flow transactions between the client and the primary computing device to determine a type of content within the client-server pair flow transactions; andmigrate the MPTCP session state data associated with the first MPTCP session to the one of the one or more secondary computing devices based on the determined type of content within the client-server pair flow transactions.
  • 8. The apparatus of claim 6, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: stop transmission of acknowledgments for any new requests received from the client upon receiving the indication for migration.
  • 9. The apparatus of claim 6, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: wait for completion of any of the one or more client-server pair flow transactions that are pending, before migrating the MPTCP session state data.
  • 10. The apparatus of claim 6, wherein the one or more processors are further configured to be capable of executing the stored programmed instructions to: determine when all of the MPTCP session state data have been migrated to the one of the one or more secondary computing devices; andterminate the established connection between the client and the one or more remote server devices when the determination indicates that all of the MPTCP session state has been migrated to the one of the one or more secondary computing devices.
  • 11. A non-transitory computer readable medium having stored thereon instructions for multipath transmission control protocol (MPTCP) based session migration comprising executable code that, when executed by one or more processors, causes the processors to: manage one or more client-server pair flow transactions between a client and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection;receive an indication for migrating MPTCP session state data associated with the first MPTCP session from the primary computing device to at least one of one or more secondary computing devices, wherein the received indication is in response to analysis of one or more migration policies determining a migration is needed to mitigate a network attack;migrate the MPTCP session state data associated with the first MPTCP session to the at least one of the secondary computing devices;advertise an identifier associated with the one of the one or more secondary computing devices to the client;receive an indication from the one of the one or more secondary computing devices indicating that a second MPTCP session has been established between the client and the one of the one or more secondary computing devices; andterminate the established first connection between the client device and the primary computing device.
  • 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: analyze the one or more client-server pair flow transactions between the client and the primary computing device to determine a type of content within the client-server pair flow transactions; andmigrate the MPTCP session state data associated with the first MPTCP session to the one of the one or more secondary computing devices based on the determined type of content within the client-server pair flow transactions.
  • 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: stop transmission of acknowledgments for any new requests received from the client upon receiving the indication for migration.
  • 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: wait for completion of any of the one or more client-server pair flow transactions that are pending, before migrating the MPTCP session state data.
  • 15. 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: determine when all of the MPTCP session state data have been migrated to the one of the one or more secondary computing devices; andterminate the established connection between the client and the one or more remote server devices when the determination indicates that all of the MPTCP session state has been migrated to the one of the one or more secondary computing devices.
  • 16. A network traffic management system comprising a memory with programmed instructions stored thereon for one or more primary computing modules, secondary computing modules, client modules, or remote server modules, and one or more processors configured to be capable of executing the stored programmed instructions to: manage one or more client-server pair flow transactions between a client and a primary computing device over a first multipath transmission control protocol (MPTCP) session established over a first connection;receive an indication for migrating MPTCP session state data associated with the first MPTCP session from the primary computing device to at least one of one or more secondary computing devices, wherein the received indication is in response to analysis of one or more migration policies determining a migration is needed to mitigate a network attack;migrate the MPTCP session state data associated with the first MPTCP session to the at least one of the secondary computing devices;advertise an identifier associated with the one of the one or more secondary computing devices to the client;receive an indication from the one of the one or more secondary computing devices indicating that a second MPTCP session has been established between the client and the one of the one or more secondary computing devices; andterminate the established first connection between the client device and the primary computing device.
  • 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: analyze the one or more client-server pair flow transactions between the client and the primary computing device to determine a type of content within the client-server pair flow transactions; andmigrate the MPTCP session state data associated with the first MPTCP session to the one of the one or more secondary computing devices based on the determined type of content within the client-server pair flow transactions.
  • 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: stop transmission of acknowledgments for any new requests received from the client upon receiving the indication for migration.
  • 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: wait for completion of any of the one or more client-server pair flow transactions that are pending, before migrating the MPTCP session state data.
  • 20. 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: determine when all of the MPTCP session state data have been migrated to the one of the one or more secondary computing devices; andterminate the established connection between the client and the one or more remote server devices when the indicates that all of the MPTCP session state has been migrated to the one of the one or more secondary computing devices.
Parent Case Info

This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/613,765, filed Jan. 5, 2018, which is hereby incorporated by reference in its entirety.

US Referenced Citations (605)
Number Name Date Kind
4993030 Krakauer et al. Feb 1991 A
5218695 Noveck et al. Jun 1993 A
5282201 Frank et al. Jan 1994 A
5303368 Kotaki Apr 1994 A
5473362 Fitzgerald et al. Dec 1995 A
5511177 Kagimasa et al. Apr 1996 A
5537585 Blickenstaff et al. Jul 1996 A
5548724 Akizawa et al. Aug 1996 A
5550816 Hardwick et al. Aug 1996 A
5550965 Gabbe et al. Aug 1996 A
5583995 Gardner et al. Dec 1996 A
5586260 Hu Dec 1996 A
5590320 Maxey Dec 1996 A
5606665 Yang et al. Feb 1997 A
5623490 Richter et al. Apr 1997 A
5649194 Miller et al. Jul 1997 A
5649200 Leblang et al. Jul 1997 A
5668943 Attanasio et al. Sep 1997 A
5692180 Lee Nov 1997 A
5721779 Funk Feb 1998 A
5724512 Winterbottom Mar 1998 A
5806061 Chaudhuri et al. Sep 1998 A
5832496 Anand et al. Nov 1998 A
5832522 Blickenstaff et al. Nov 1998 A
5838970 Thomas Nov 1998 A
5862325 Reed et al. Jan 1999 A
5884303 Brown Mar 1999 A
5893086 Schmuck et al. Apr 1999 A
5897638 Lasser et al. Apr 1999 A
5905990 Inglett May 1999 A
5917998 Cabrera et al. Jun 1999 A
5920873 Van Huben et al. Jul 1999 A
5926816 Bauer et al. Jul 1999 A
5937406 Balabine et al. Aug 1999 A
5991302 Berl et al. Nov 1999 A
5995491 Richter et al. Nov 1999 A
5999664 Mahoney et al. Dec 1999 A
6012083 Savitzky et al. Jan 2000 A
6026500 Topff et al. Feb 2000 A
6029168 Frey Feb 2000 A
6029175 Chow et al. Feb 2000 A
6041365 Kleinerman Mar 2000 A
6044367 Wolff Mar 2000 A
6047129 Frye Apr 2000 A
6047356 Anderson et al. Apr 2000 A
6067558 Wendt et al. May 2000 A
6072942 Stockwell et al. Jun 2000 A
6078929 Rao Jun 2000 A
6085234 Pitts et al. Jul 2000 A
6088694 Burns et al. Jul 2000 A
6104706 Richter et al. Aug 2000 A
6128627 Mattis et al. Oct 2000 A
6128717 Harrison et al. Oct 2000 A
6154777 Ebrahim Nov 2000 A
6157950 Krishnan Dec 2000 A
6161145 Bainbridge et al. Dec 2000 A
6161185 Guthrie et al. Dec 2000 A
6181336 Chiu et al. Jan 2001 B1
6202156 Kalajan Mar 2001 B1
6223206 Dan et al. Apr 2001 B1
6233648 Tomita May 2001 B1
6237008 Beal et al. May 2001 B1
6256031 Meijer et al. Jul 2001 B1
6259405 Stewart et al. Jul 2001 B1
6260070 Shah Jul 2001 B1
6282610 Bergsten Aug 2001 B1
6289345 Yasue Sep 2001 B1
6292832 Shah et al. Sep 2001 B1
6304913 Rune Oct 2001 B1
6308162 Ouimet et al. Oct 2001 B1
6324581 Xu et al. Nov 2001 B1
6329985 Tamer et al. Dec 2001 B1
6330226 Chapman Dec 2001 B1
6330574 Murashita Dec 2001 B1
6338082 Schneider Jan 2002 B1
6339785 Feigenbaum Jan 2002 B1
6349343 Foody et al. Feb 2002 B1
6353848 Morris Mar 2002 B1
6363056 Beigi et al. Mar 2002 B1
6370527 Singhal Apr 2002 B1
6370543 Hoffert et al. Apr 2002 B2
6374263 Bunger et al. Apr 2002 B1
6389433 Bolosky et al. May 2002 B1
6389462 Cohen et al. May 2002 B1
6393581 Friedman et al. May 2002 B1
6397246 Wolfe May 2002 B1
6412004 Chen et al. Jun 2002 B1
6438595 Blumenau et al. Aug 2002 B1
6446108 Rosenberg et al. Sep 2002 B1
6466580 Leung Oct 2002 B1
6469983 Narayana et al. Oct 2002 B2
6477544 Bolosky et al. Nov 2002 B1
6487561 Ofek et al. Nov 2002 B1
6493804 Soltis et al. Dec 2002 B1
6513061 Ebata et al. Jan 2003 B1
6514085 Slattery et al. Feb 2003 B2
6516350 Lumelsky et al. Feb 2003 B1
6516351 Borr Feb 2003 B2
6542909 Tamer et al. Apr 2003 B1
6542936 Mayle et al. Apr 2003 B1
6549916 Sedlar Apr 2003 B1
6553352 Delurgio et al. Apr 2003 B2
6556997 Levy Apr 2003 B1
6556998 Mukherjee et al. Apr 2003 B1
6560230 Li et al. May 2003 B1
6578069 Hopmann et al. Jun 2003 B1
6601101 Lee et al. Jul 2003 B1
6606663 Liao et al. Aug 2003 B1
6612490 Herrendoerfer et al. Sep 2003 B1
6615267 Whalen et al. Sep 2003 B1
6654346 Mahalingaiah et al. Nov 2003 B1
6701415 Hendren, III Mar 2004 B1
6708220 Olin Mar 2004 B1
6721794 Taylor et al. Apr 2004 B2
6728265 Yavatkar et al. Apr 2004 B1
6728704 Mao et al. Apr 2004 B2
6738357 Richter et al. May 2004 B1
6738790 Klein et al. May 2004 B1
6742035 Zayas et al. May 2004 B1
6744776 Kalkunte et al. Jun 2004 B1
6748420 Quatrano et al. Jun 2004 B1
6754215 Arikawa et al. Jun 2004 B1
6754699 Swildens et al. Jun 2004 B2
6757706 Dong et al. Jun 2004 B1
6760337 Snyder, II et al. Jul 2004 B1
6775672 Mahalingam et al. Aug 2004 B2
6775673 Mahalingam et al. Aug 2004 B2
6775679 Gupta Aug 2004 B2
6782450 Arnott et al. Aug 2004 B2
6795860 Shah Sep 2004 B1
6801960 Ericson et al. Oct 2004 B1
6826613 Wang et al. Nov 2004 B1
6839761 Kadyk et al. Jan 2005 B2
6847959 Arrouye et al. Jan 2005 B1
6847970 Keller et al. Jan 2005 B2
6850997 Rooney et al. Feb 2005 B1
6865593 Reshef et al. Mar 2005 B1
6868447 Slaughter et al. Mar 2005 B1
6871221 Styles Mar 2005 B1
6871245 Bradley Mar 2005 B2
6880017 Marce et al. Apr 2005 B1
6883137 Girardot et al. Apr 2005 B1
6889249 Miloushev et al. May 2005 B2
6914881 Mansfield et al. Jul 2005 B1
6922688 Frey, Jr. Jul 2005 B1
6928518 Talagala Aug 2005 B2
6934706 Mancuso et al. Aug 2005 B1
6938039 Bober et al. Aug 2005 B1
6938059 Tamer et al. Aug 2005 B2
6959373 Testardi Oct 2005 B2
6961815 Kistler et al. Nov 2005 B2
6970475 Fraser et al. Nov 2005 B1
6970924 Chu et al. Nov 2005 B1
6973455 Vahalia et al. Dec 2005 B1
6973490 Robertson et al. Dec 2005 B1
6973549 Testardi Dec 2005 B1
6975592 Sedddigh et al. Dec 2005 B1
6985936 Agarwalla et al. Jan 2006 B2
6985956 Luke et al. Jan 2006 B2
6986015 Testardi Jan 2006 B2
6990074 Wan et al. Jan 2006 B2
6990114 Erimli et al. Jan 2006 B1
6990547 Ulrich et al. Jan 2006 B2
6990667 Ulrich et al. Jan 2006 B2
6996841 Kadyk et al. Feb 2006 B2
6999912 Loisey et al. Feb 2006 B2
7003533 Noguchi et al. Feb 2006 B2
7003564 Greuel et al. Feb 2006 B2
7006981 Rose et al. Feb 2006 B2
7039061 Connor et al. Feb 2006 B2
7010553 Chen et al. Mar 2006 B2
7013379 Testardi Mar 2006 B1
7020644 Jameson Mar 2006 B2
7020669 McCann et al. Mar 2006 B2
7023974 Brannam et al. Apr 2006 B1
7024427 Bobbitt et al. Apr 2006 B2
7035212 Mittal et al. Apr 2006 B1
7051112 Dawson May 2006 B2
7054998 Arnott et al. May 2006 B2
7055010 Lin et al. May 2006 B2
7065482 Shorey et al. Jun 2006 B2
7072917 Wong et al. Jul 2006 B2
7075924 Richter et al. Jul 2006 B2
7076689 Atkinson Jul 2006 B2
7080314 Garofalakis et al. Jul 2006 B1
7089286 Malik Aug 2006 B1
7089491 Feinberg et al. Aug 2006 B2
7111115 Peters et al. Sep 2006 B2
7113962 Kee et al. Sep 2006 B1
7113996 Kronenberg Sep 2006 B2
7120728 Krakirian et al. Oct 2006 B2
7120746 Campbell et al. Oct 2006 B2
7127556 Blumenau et al. Oct 2006 B2
7133863 Teng et al. Nov 2006 B2
7133967 Fujie et al. Nov 2006 B2
7143146 Nakatani et al. Nov 2006 B2
7146524 Patel et al. Dec 2006 B2
7152184 Maeda et al. Dec 2006 B2
7155466 Rodriguez et al. Dec 2006 B2
7165095 Sim Jan 2007 B2
7167821 Hardwick et al. Jan 2007 B2
7171469 Ackaouy et al. Jan 2007 B2
7173929 Testardi Feb 2007 B1
7181523 Sim Feb 2007 B2
7191163 Herrera et al. Mar 2007 B2
7194579 Robinson et al. Mar 2007 B2
7228359 Monteiro Jun 2007 B1
7234074 Cohn et al. Jun 2007 B2
7236491 Tsao et al. Jun 2007 B2
7240100 Wein et al. Jul 2007 B1
7243089 Becker-Szendy et al. Jul 2007 B2
7243094 Tabellion et al. Jul 2007 B2
7263610 Parker et al. Aug 2007 B2
7269168 Roy et al. Sep 2007 B2
7269582 Winter et al. Sep 2007 B2
7272613 Sim et al. Sep 2007 B2
7280536 Testardi Oct 2007 B2
7284150 Ma et al. Oct 2007 B2
7292541 C S Nov 2007 B1
7293097 Borr Nov 2007 B2
7293099 Kalajan Nov 2007 B1
7293133 Colgrove et al. Nov 2007 B1
7296263 Jacob Nov 2007 B1
7299250 Douceur et al. Nov 2007 B2
7308475 Pruitt et al. Dec 2007 B1
7324533 DeLiberato et al. Jan 2008 B1
7330486 Ko et al. Feb 2008 B2
7340571 Saze Mar 2008 B2
7343398 Lownsbrough Mar 2008 B1
7346664 Wong et al. Mar 2008 B2
7373438 DeBergalis et al. May 2008 B1
7383288 Miloushev et al. Jun 2008 B2
7401220 Bolosky et al. Jul 2008 B2
7406484 Srinivasan et al. Jul 2008 B1
7409440 Jacob Aug 2008 B1
7415488 Muth et al. Aug 2008 B1
7415608 Bolosky et al. Aug 2008 B2
7418439 Wong Aug 2008 B2
7437358 Arrouye et al. Oct 2008 B2
7440982 Lu et al. Oct 2008 B2
7457982 Rajan Nov 2008 B2
7467158 Marinescu Dec 2008 B2
7475241 Patel et al. Jan 2009 B2
7477796 Sasaki et al. Jan 2009 B2
7509322 Miloushev et al. Mar 2009 B2
7512673 Miloushev et al. Mar 2009 B2
7519813 Cox et al. Apr 2009 B1
7532577 Park May 2009 B2
7562110 Miloushev et al. Jul 2009 B2
7571168 Bahar et al. Aug 2009 B2
7574433 Engel Aug 2009 B2
7577723 Matsuda et al. Aug 2009 B2
7587471 Yasuda et al. Sep 2009 B2
7590747 Coates et al. Sep 2009 B2
7599941 Bahar et al. Oct 2009 B2
7610307 Havewala et al. Oct 2009 B2
7610390 Yared et al. Oct 2009 B2
7624109 Testardi Nov 2009 B2
7639883 Gill Dec 2009 B2
7640347 Sloat et al. Dec 2009 B1
7644109 Manley et al. Jan 2010 B2
7653699 Colgrove et al. Jan 2010 B1
7656788 Ma et al. Feb 2010 B2
7684423 Tripathi et al. Mar 2010 B2
7685177 Hagerstrom et al. Mar 2010 B1
7689596 Tsunoda Mar 2010 B2
7694082 Golding et al. Apr 2010 B2
7698458 Lui et al. Apr 2010 B1
7711771 Kirnos May 2010 B2
7734603 McManis Jun 2010 B1
7739540 Akutsu et al. Jun 2010 B2
7743035 Chen et al. Jun 2010 B2
7752294 Meyer et al. Jul 2010 B2
7769711 Srinivasan et al. Aug 2010 B2
7788335 Miloushev et al. Aug 2010 B2
7809691 Karmarkar et al. Oct 2010 B1
7822839 Pruitt et al. Oct 2010 B1
7822939 Veprinsky et al. Oct 2010 B1
7831639 Panchbudhe et al. Nov 2010 B1
7849112 Mane et al. Dec 2010 B2
7853958 Matthew et al. Dec 2010 B2
7861085 Case et al. Dec 2010 B1
7870154 Shitomi et al. Jan 2011 B2
7877511 Berger et al. Jan 2011 B1
7885970 Lacapra Feb 2011 B2
7886218 Watson Feb 2011 B2
7895653 Calo et al. Feb 2011 B2
7900002 Lyon Mar 2011 B2
7903554 Manur et al. Mar 2011 B1
7904466 Valencia et al. Mar 2011 B1
7908245 Nakano et al. Mar 2011 B2
7913053 Newland Mar 2011 B1
7953085 Chang et al. May 2011 B2
7953701 Okitsu et al. May 2011 B2
7958222 Pruitt et al. Jun 2011 B1
7958347 Ferguson Jun 2011 B1
7984500 Khanna et al. Jul 2011 B1
8005953 Miloushev et al. Aug 2011 B2
8015157 Kamei et al. Sep 2011 B2
8024443 Jacob Sep 2011 B1
8046547 Chatterjee et al. Oct 2011 B1
8055724 Amegadzie et al. Nov 2011 B2
8064342 Badger Nov 2011 B2
8069225 McCanne et al. Nov 2011 B2
8099758 Schaefer et al. Jan 2012 B2
8103622 Karinta Jan 2012 B1
8112392 Bunnell et al. Feb 2012 B1
8117244 Marinov et al. Feb 2012 B2
8155128 Balyan et al. Apr 2012 B2
8171124 Kondamuru May 2012 B2
8190769 Shukla et al. May 2012 B1
8209403 Szabo et al. Jun 2012 B2
8271751 Hinrichs, Jr. Sep 2012 B2
8302100 Deng et al. Oct 2012 B2
8326798 Driscoll et al. Dec 2012 B1
8351600 Resch Jan 2013 B2
8396836 Ferguson et al. Mar 2013 B1
8463850 McCann Jun 2013 B1
8484348 Subramanian et al. Jul 2013 B2
8559313 Mukerji Oct 2013 B1
8560693 Wang et al. Oct 2013 B1
8601000 Stefani et al. Dec 2013 B1
10476809 Daniel Nov 2019 B1
10659475 Lazri May 2020 B2
10795707 Hay Oct 2020 B2
20010003164 Murakami Jun 2001 A1
20010007560 Masuda et al. Jul 2001 A1
20010047293 Waller et al. Nov 2001 A1
20020012352 Hansson et al. Jan 2002 A1
20020012382 Schilling Jan 2002 A1
20020035537 Waller et al. Mar 2002 A1
20020038360 Andrews et al. Mar 2002 A1
20020059263 Shima et al. May 2002 A1
20020065848 Walker et al. May 2002 A1
20020072048 Slattery et al. Jun 2002 A1
20020087571 Stapel et al. Jul 2002 A1
20020087744 Kitchin Jul 2002 A1
20020087887 Busam et al. Jul 2002 A1
20020099829 Richards et al. Jul 2002 A1
20020099842 Jennings et al. Jul 2002 A1
20020103823 Jackson et al. Aug 2002 A1
20020106263 Winker Aug 2002 A1
20020120727 Curley Aug 2002 A1
20020120763 Miloushev et al. Aug 2002 A1
20020143819 Han et al. Oct 2002 A1
20020143852 Guo et al. Oct 2002 A1
20020143892 Mogul Oct 2002 A1
20020150253 Brezak et al. Oct 2002 A1
20020156905 Weissman Oct 2002 A1
20020161911 Pinckney, III et al. Oct 2002 A1
20020162118 Levy et al. Oct 2002 A1
20020174216 Shorey et al. Nov 2002 A1
20020194112 dePinto et al. Dec 2002 A1
20020194342 Lu et al. Dec 2002 A1
20020198956 Dunshea et al. Dec 2002 A1
20030005172 Chessell Jan 2003 A1
20030009528 Sharif et al. Jan 2003 A1
20030012382 Ferchichi et al. Jan 2003 A1
20030018450 Carley Jan 2003 A1
20030018585 Butler et al. Jan 2003 A1
20030028514 Lord et al. Feb 2003 A1
20030033308 Patel et al. Feb 2003 A1
20030033535 Fisher et al. Feb 2003 A1
20030034905 Anton et al. Feb 2003 A1
20030051045 Connor Mar 2003 A1
20030055723 English Mar 2003 A1
20030065956 Belapurkar et al. Apr 2003 A1
20030074301 Solomon Apr 2003 A1
20030105846 Zhao et al. Jun 2003 A1
20030108000 Chaney et al. Jun 2003 A1
20030108002 Chaney et al. Jun 2003 A1
20030128708 Inoue et al. Jul 2003 A1
20030130945 Force et al. Jul 2003 A1
20030139934 Mandera Jul 2003 A1
20030156586 Lee et al. Aug 2003 A1
20030159072 Bellinger et al. Aug 2003 A1
20030171978 Jenkins et al. Sep 2003 A1
20030177364 Walsh et al. Sep 2003 A1
20030177388 Botz et al. Sep 2003 A1
20030179755 Fraser Sep 2003 A1
20030189936 Terrell et al. Oct 2003 A1
20030191812 Agarwalla et al. Oct 2003 A1
20030195813 Pallister et al. Oct 2003 A1
20030195962 Kikuchi et al. Oct 2003 A1
20030200207 Dickinson Oct 2003 A1
20030204635 Ko et al. Oct 2003 A1
20030212954 Patrudu Nov 2003 A1
20030220835 Barnes, Jr. Nov 2003 A1
20030229665 Ryman Dec 2003 A1
20030236995 Fretwell, Jr. Dec 2003 A1
20040003266 Moshir et al. Jan 2004 A1
20040006575 Visharam et al. Jan 2004 A1
20040006591 Matsui et al. Jan 2004 A1
20040010654 Yasuda et al. Jan 2004 A1
20040015783 Lennon et al. Jan 2004 A1
20040017825 Stanwood et al. Jan 2004 A1
20040028043 Maveli et al. Feb 2004 A1
20040030627 Sedukhin Feb 2004 A1
20040030740 Stelting Feb 2004 A1
20040030857 Krakirian et al. Feb 2004 A1
20040043758 Sorvari et al. Mar 2004 A1
20040044705 Stager et al. Mar 2004 A1
20040054748 Ackaouy et al. Mar 2004 A1
20040059789 Shum Mar 2004 A1
20040064544 Barsness et al. Apr 2004 A1
20040064554 Kuno et al. Apr 2004 A1
20040093361 Therrien et al. May 2004 A1
20040098595 Aupperle et al. May 2004 A1
20040122926 Moore et al. Jun 2004 A1
20040123277 Schrader et al. Jun 2004 A1
20040133577 Miloushev et al. Jul 2004 A1
20040133605 Chang et al. Jul 2004 A1
20040133606 Miloushev et al. Jul 2004 A1
20040138858 Carley Jul 2004 A1
20040139355 Axel et al. Jul 2004 A1
20040148380 Meyer et al. Jul 2004 A1
20040153479 Mikesell et al. Aug 2004 A1
20040167967 Bastian et al. Aug 2004 A1
20040199547 Winter et al. Oct 2004 A1
20040213156 Smallwood et al. Oct 2004 A1
20040215665 Edgar et al. Oct 2004 A1
20040236798 Srinivasan et al. Nov 2004 A1
20040236826 Harville et al. Nov 2004 A1
20050008017 Datta et al. Jan 2005 A1
20050021703 Cherry et al. Jan 2005 A1
20050027841 Rolfe Feb 2005 A1
20050027862 Nguyen et al. Feb 2005 A1
20050044158 Malik Feb 2005 A1
20050050107 Mane et al. Mar 2005 A1
20050091214 Probert et al. Apr 2005 A1
20050108575 Yung May 2005 A1
20050114701 Atkins et al. May 2005 A1
20050117589 Douady et al. Jun 2005 A1
20050160161 Barrett et al. Jul 2005 A1
20050165656 Frederick et al. Jul 2005 A1
20050174944 Legault et al. Aug 2005 A1
20050175013 Permec et al. Aug 2005 A1
20050180419 Park Aug 2005 A1
20050187866 Lee Aug 2005 A1
20050198234 Leib et al. Sep 2005 A1
20050213587 Cho et al. Sep 2005 A1
20050234928 Shkvarchuk et al. Oct 2005 A1
20050240664 Chen et al. Oct 2005 A1
20050246393 Coates et al. Nov 2005 A1
20050256806 Tien et al. Nov 2005 A1
20050198501 Andreev et al. Dec 2005 A1
20050273456 Revanuru et al. Dec 2005 A1
20050289111 Tribble et al. Dec 2005 A1
20060010502 Mimatsu et al. Jan 2006 A1
20060031374 Lu et al. Feb 2006 A1
20060031778 Goodwin et al. Feb 2006 A1
20060045089 Bacher et al. Mar 2006 A1
20060045096 Farmer et al. Mar 2006 A1
20060047785 Wang et al. Mar 2006 A1
20060074922 Nishimura Apr 2006 A1
20060075475 Boulos et al. Apr 2006 A1
20060080353 Miloushev et al. Apr 2006 A1
20060100752 Kim et al. May 2006 A1
20060106882 Douceur et al. May 2006 A1
20060112367 Harris May 2006 A1
20060123062 Bobbitt et al. Jun 2006 A1
20060123210 Pritchett et al. Jun 2006 A1
20060130133 Andreev et al. Jun 2006 A1
20060140193 Kakan, I et al. Jun 2006 A1
20060153201 Hepper et al. Jul 2006 A1
20060167838 Lacapra Jul 2006 A1
20060184589 Lees et al. Aug 2006 A1
20060198300 Li Sep 2006 A1
20060200470 Lacapra et al. Sep 2006 A1
20060224636 Kathuria et al. Oct 2006 A1
20060224687 Popkin et al. Oct 2006 A1
20060230265 Krishna Oct 2006 A1
20060235998 Stecher et al. Oct 2006 A1
20060259320 LaSalle et al. Nov 2006 A1
20060268692 Wright et al. Nov 2006 A1
20060270341 Kim et al. Nov 2006 A1
20060271598 Wong et al. Nov 2006 A1
20060277225 Mark et al. Dec 2006 A1
20060282442 Lennon et al. Dec 2006 A1
20060282461 Marinescu Dec 2006 A1
20060282471 Mark et al. Dec 2006 A1
20070005807 Wong Jan 2007 A1
20070016613 Foresti et al. Jan 2007 A1
20070024919 Wong et al. Feb 2007 A1
20070027929 Whelan Feb 2007 A1
20070027935 Haselton et al. Feb 2007 A1
20070028068 Golding et al. Feb 2007 A1
20070038994 Davis et al. Feb 2007 A1
20070061441 Landis et al. Mar 2007 A1
20070088702 Fridella et al. Apr 2007 A1
20070112775 Ackerman May 2007 A1
20070124415 Lev-Ran et al. May 2007 A1
20070124502 Li May 2007 A1
20070130255 Wolovitz et al. Jun 2007 A1
20070136308 Tsirigotis et al. Jun 2007 A1
20070139227 Speirs, II et al. Jun 2007 A1
20070162891 Burner et al. Jul 2007 A1
20070168320 Borthakur et al. Jul 2007 A1
20070180314 Kawashima et al. Aug 2007 A1
20070208748 Li Sep 2007 A1
20070209075 Coffman Sep 2007 A1
20070233826 Tindal et al. Oct 2007 A1
20070250560 Wein et al. Oct 2007 A1
20080004022 Johannesson et al. Jan 2008 A1
20080010372 Khedouri et al. Jan 2008 A1
20080022059 Zimmerer et al. Jan 2008 A1
20080046432 Anderson et al. Feb 2008 A1
20080070575 Claussen et al. Mar 2008 A1
20080114718 Anderson et al. May 2008 A1
20080183888 Brown Jul 2008 A1
20080189468 Schmidt et al. Aug 2008 A1
20080208917 Smoot et al. Aug 2008 A1
20080208933 Lyon Aug 2008 A1
20080209073 Tang Aug 2008 A1
20080215836 Sutoh et al. Sep 2008 A1
20080222223 Srinivasan et al. Sep 2008 A1
20080243769 Arbour et al. Oct 2008 A1
20080263401 Stenzel Oct 2008 A1
20080270578 Zhang et al. Oct 2008 A1
20080281908 McCanne et al. Nov 2008 A1
20080282047 Arakawa et al. Nov 2008 A1
20080294446 Guo et al. Nov 2008 A1
20080298233 Arora Dec 2008 A1
20090007162 Sheehan Jan 2009 A1
20090019535 Mishra et al. Jan 2009 A1
20090037975 Ishikawa et al. Feb 2009 A1
20090041230 Williams Feb 2009 A1
20090055507 Oeda Feb 2009 A1
20090055607 Schack et al. Feb 2009 A1
20090077097 Lacapra et al. Mar 2009 A1
20090080440 Balyan et al. Mar 2009 A1
20090089344 Brown et al. Apr 2009 A1
20090094252 Wong et al. Apr 2009 A1
20090094311 Awadallah et al. Apr 2009 A1
20090106255 Lacapra et al. Apr 2009 A1
20090106263 Khalid et al. Apr 2009 A1
20090106413 Salo et al. Apr 2009 A1
20090125955 DeLorme May 2009 A1
20090132616 Winter et al. May 2009 A1
20090138314 Bruce May 2009 A1
20090161542 Ho Jun 2009 A1
20090185497 Arora Jul 2009 A1
20090187915 Chew et al. Jul 2009 A1
20090204649 Wong et al. Aug 2009 A1
20090204650 Wong et al. Aug 2009 A1
20090204705 Marinov et al. Aug 2009 A1
20090210431 Marinkovic et al. Aug 2009 A1
20090217163 Jaroker Aug 2009 A1
20090217386 Schneider Aug 2009 A1
20090240705 Miloushev et al. Sep 2009 A1
20090240899 Akagawa et al. Sep 2009 A1
20090241176 Beletski et al. Sep 2009 A1
20090265396 Ram et al. Oct 2009 A1
20090265467 Peles Oct 2009 A1
20090292957 Bower et al. Nov 2009 A1
20090300161 Pruitt et al. Dec 2009 A1
20090316708 Yahyaoui et al. Dec 2009 A1
20090319600 Sedan et al. Dec 2009 A1
20100017643 Baba et al. Jan 2010 A1
20100042743 Jeon et al. Feb 2010 A1
20100061232 Zhou et al. Mar 2010 A1
20100064001 Daily Mar 2010 A1
20100070476 O'Keefe et al. Mar 2010 A1
20100082542 Feng et al. Apr 2010 A1
20100093318 Zhu et al. Apr 2010 A1
20100103819 Samuels Apr 2010 A1
20100131654 Malakapalli et al. May 2010 A1
20100179984 Sebastian Jul 2010 A1
20100205206 Rabines et al. Aug 2010 A1
20100228819 Wei Sep 2010 A1
20100242092 Harris et al. Sep 2010 A1
20100250497 Redlich et al. Sep 2010 A1
20100274772 Samuels Oct 2010 A1
20100306169 Pishevar et al. Dec 2010 A1
20100325257 Goel et al. Dec 2010 A1
20100325634 Ichikawa et al. Dec 2010 A1
20110055921 Narayanaswamy et al. Mar 2011 A1
20110066736 Mitchell et al. Mar 2011 A1
20110072321 Dhuse Mar 2011 A1
20110083185 Sheleheda et al. Apr 2011 A1
20110087696 Lacapra Apr 2011 A1
20110093471 Brockway et al. Apr 2011 A1
20110107112 Resch May 2011 A1
20110119234 Schack et al. May 2011 A1
20110185082 Thompson Jul 2011 A1
20110296411 Teng et al. Dec 2011 A1
20110320882 Beaty et al. Dec 2011 A1
20120007239 Agarwal et al. Mar 2012 A1
20120117028 Gold et al. May 2012 A1
20120144229 Nadolski Jun 2012 A1
20120150699 Trapp et al. Jun 2012 A1
20120150805 Pafumi et al. Jun 2012 A1
20130058229 Casado et al. Mar 2013 A1
20130058252 Casado et al. Mar 2013 A1
20130058255 Casado et al. Mar 2013 A1
20130074181 Singh Mar 2013 A1
20130086142 Hampel Apr 2013 A1
20140143308 Tychina May 2014 A1
20140223556 Bignon Aug 2014 A1
20150281367 Nygren Oct 2015 A1
20150282219 Kweon Oct 2015 A1
20160140045 Bergeron May 2016 A1
20170339219 Le Nov 2017 A1
20190150150 Calin May 2019 A1
20190182367 Kim Jun 2019 A1
Foreign Referenced Citations (23)
Number Date Country
2003300350 Jul 2004 AU
2080530 Apr 1994 CA
2512312 Jul 2004 CA
0605088 Jul 1996 EP
0 73 8 970 Oct 1996 EP
1081918 Jul 2001 EP
63010250 Jan 1988 JP
6205006 Jul 1994 JP
06-332782 Dec 1994 JP
8021924 Mar 1996 JP
08-328760 Dec 1996 JP
08-339355 Dec 1996 JP
9016510 Jan 1997 JP
11282741 Oct 1999 JP
2000-183935 Jun 2000 JP
566291 Dec 2008 NZ
WO 0058870 Oct 2000 WO
WO 0239696 May 2002 WO
WO 02056181 Jul 2002 WO
WO 2004061605 Jul 2004 WO
WO 2006091040 Aug 2006 WO
WO 2008130983 Oct 2008 WO
WO 2008147973 Dec 2008 WO
Non-Patent Literature Citations (126)
Entry
Bhalla, A., et al., “Future-Proof Your Hardware Investment,” F5 Networks, Inc., Aug. 16, 2018.
“Software-Defined Hardware: Enabling Performance and Agility with the BIG-IP iSeries Architecture,” F5 Networks, Inc., Nov. 11, 2016.
F5 Networks, Inc , “BIG-IP® Local Traffic Management: Basics”, Manual, May 9, 2016, 58 pages , version 12.1, F5 Networks, Inc.
F5 Networks, Inc., “F5 BIG-IP TMOS: Operations Guide”, Manual, Dec. 2018, 226 pages, F5 Networks, Inc.
F5 Networks, Inc., “BIG-IP® Local Traffic Manager™: Implementations”, Manual, May 4, 2018, 228 pages, version 12.1, F5 Networks, Inc.
F5 Networks, Inc., “BIG-IP® Tmos:® Implementations”, Manual, May 9, 2016, 184 pages, version 12.1, F5 Networks, Inc.
F5 Networks Inc., “BIG-IP® Local Traffic Manager™: Implementations”, Manual, May 25, 2016, pp. 1-284, vol. 12.0, F5 Networks, Inc., Retrieved from the Internet:<https://support.f5.com/kb/en-US/products/big-ip_ltm/manuals/product/ltm-implementations-12-0-0.html>.
F5 Networks Inc., “F5 BIG-IP TMOS: Operations Guide”, Manual, Mar. 5, 2016, pp. 1-236, F5 Networks, Inc., Retrieved from the Internet:<https://support.f5.com/kb/en-US/products/big-ip_Itm/manuals/product/f5-tmos-operations-guide.html>.
F5 Networks Inc., “BIG-IP® Local Traffic Management: Basics”, Manual, Oct. 20, 2015, pp. 1-68, vol. 12.0, F5 Networks, Inc., Retrieved from the Internet:<https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-basics-12-0-0.html>.
F5 Networks Inc., “BIG-IP LTM and TMOS 12.0.0”, Release Notes, Oct. 6, 2016, pp. 1-110, vol. 12.0, F5 Networks, Inc., Retrieved from the Internet:<https://support.f5.com/kb/en-US/products/big-ip_ltm/releasenotes/product/relnote-ltm-12-0-0.html>.
F5 Networks Inc., “BIG-IP® Analytics: Implementations”, Manual, Oct. 27, 2015, pp. 1-50, vol. 12.0, F5 Networks, Inc., Retrieved from the Internet:<https://support.f5.com/kb/en-US/products/big-ip_ltm/manuals/product/ltm-basics-12-0-0.html>.
“A Storage Architecture Guide,” Second Edition, 2001, Auspex Systems, Inc., www.auspex.com, last accessed on Dec. 30, 2002.
“CSA Persistent File System Technology,” A White Paper, Jan. 1, 1999, pp. 1-3, http://www.cosoa.com/white_papers/pfs.php, Colorado Software Architecture, Inc.
“Distributed File System: A Logical View of Physical Storage: White Paper,” 1999, Microsoft Corp., www.microsoft.com, <http://www.eu.microsoft.com/TechNet/prodtechnol/windows2000serv/maintain/DFSnt95>, pp. 1-26, last accessed on Dec. 20, 2002.
“Market Research & Releases, CMPP PoC documentation”, last accessed Mar. 29, 2010, (http://mainstreet/sites/PD/Teams/ProdMgmt/MarketResearch/Universal).
“Market Research & Releases, Solstice Diameter Requirements”, last accessed Mar. 29, 2010, (http://mainstreet/sites/PD/Teams/ProdMgmt/MarketResearch/Unisversal).
“NERSC Tutorials: I/O on the Cray T3E, ‘Chapter 8, Disk Striping’,” National Energy Research Scientific Computing Center (NERSC), http://hpcfnersc.gov, last accessed on Dec. 27, 2002, 9 pages.
“Respond to server depending on TCP: :client_port”, DevCentral Forums iRules, pp. 1-6, last accessed Mar. 26, 2010, (http://devcentral.f5.com/Default/aspx?tabid=53&forumid=5&tpage=1&v).
“Scaling Next Generation Web Infrastructure with Content-Intelligent Switching: White Paper,” Apr. 2000, pp. 1-9, Alteon Web Systems, Inc.
“The AFS File System in Distributed Computing Environment,” www.transarc.ibm.com/Libraiy/whitepapers/AFS/afsoverview.html, last accessed on Dec. 20, 2002.
“Veritas SanPoint Foundation Suite(tm) and SANPoint Foundation Suite(tm) HA: New Veritas Volume Management and File System Technology for Cluster Environments,” Sep. 2001, 26 pages, Veritas Software Corp.
“Windows Clustering Technologies-An Overview,” Nov. 2001, 31 pages, Microsoft Corp.
Aguilera et al., “Improving recoverability in multi-tier storage systems,” International Conference on Dependable Systems and Networks (DSN-2007), Jun. 2007, 10 pages, Edinburgh, Scotland.
Anderson et al., “Interposed Request Routing for Scalable Network Storage,” ACM Transactions on Computer Systems 20(1): (Feb. 2002), pp. 1-24.
Anderson et al., “Serverless Network File System,” in the 15th Symposium on Operating Systems Principles, Dec. 1995, 18 pages, Association for Computing Machinery, Inc.
Anonymous, “How DFS Works: Remote File Systems,” Distributed File System (DFS) Mar. 2003, 54 pages, Technical Reference retrieved from the Internet on Jan. 29, 2010, URL<http://technetmicrosoft.com/en-us/library/cc782417(WS. 10,printer).aspx>.
Apple, Inc., “Mac OS X Tiger Keynote Intro. Part 2,” Jun. 2004, www.youtube.com <http://www.youtube.com/watch?v=zSBJwEmRJbY>, 1 page.
Apple, Inc., “Tiger Developer Overview Series: Working with Spotlight,” Nov. 23, 2004, www.apple.com using www.archive.org <http://web.archive.org/web/20041123005335/developer.apple.com/macosx/tiger/spotlight.html>, pp. 1-11.
Baer, T., et al., “The elements of Web services” ADTmag.com, Dec. 2002, pp. 1-6, (http://www.adtmag.com).
Basney et al., “Credential Wallets: A Classification of Credential Repositories Highlighting MyProxy,” Sep. 19-21, 2003, pp. 1-20, 31st Research Conference on Communication, Information and Internet Policy (TPRC 2003), Arlington, Virginia.
Blue Coat, “Technology Primer: CIFS Protocol Optimization,” Blue Coat Systems Inc., 2007, pp. 1-3, (http://www.bluecoat.com).
Botzum, Keys, “Single Sign On—A Contrarian View,” Aug. 6, 2001, pp. 1-8, Open Group Website, http://www.opengroup.org/security/topics.htm.
Cabrera et al., “Swift: A Storage Architecture for Large Objects,” In Proceedings of the-Eleventh IEEE Symposium on Mass Storage Systems, Oct. 1991, pp. 1-7.
Cabrera et al., “Swift: Using Distributed Disk Striping to Provide High I/O Data Rates,” Fall 1991, pp. 405-436, vol. 4, No. 4, Computing Systems.
Cabrera et al., “Using Data Striping in a Local Area Network,” 1992, 22 pages, Technical report No. UCSC-CRL-92-09 of the Computer & Information Sciences Department of University of California at Santa Cruz.
Callaghan et al., “NFS Version 3 Protocol Specifications” (RFC 1813), Jun. 1995, 127 pages, The Internet Engineering Task Force (1E1N.
Carns et al., “PVFS: A Parallel File System For Linux Clusters,” in Proceedings of the Extreme Linux Track: 4th Annual Linux Showcase and Conference, Oct. 2000, pp. 317-327, Atlanta, Georgia, USENIX Association.
Cavale, M. R., “Introducing Microsoft Cluster Service (MSCS) in the Windows Server 2003”, Nov. 2002, 10 pages, Microsoft Corporation.
English Translation of Notification of Reason(s) for Refusal for JP 2002-556371 (DispatchDate: Jan. 22, 2007).
F5 Networks Inc., “3-DNS® Reference Guide, version 4.5”, F5 Networks Inc., Sep. 2002, pp. 2-1 -2-28, 3-1 -3-12, 5-1 -5-24, Seattle, Washington.
F5 Networks Inc., “Big-IP® Reference Guide, version 4.5”, F5 Networks Inc., Sep. 2002, pp. 11-1-11-32, Seattle, Washington.
F5 Networks Inc., “Case Information Log for 'Issues withBoNY upgrade to 4.3'”, as early as Feb. 2008.
F5 Networks Inc., “Deploying the BIG-IP LTM for Diameter Traffic Management,” F5® Deployment Guide, Publication date Sep. 2010, Version 1.2, pp. 1-19.
F5 Networks Inc., “F5 Diameter RM”, Powerpoint document, Jul. 16, 2009, pp. 1-7.
F5 Networks Inc., “F5 WANJet CIFS Acceleration”, White Paper, F5 Networks Inc., Mar. 2006, pp. 1-5, Seattle, Washington.
F5 Networks Inc., “Routing Global Internet Users to the Appropriate Data Center and Applications Using F5's 3-DNS Controller”, F5 Networks Inc., Aug. 2001, pp. 1-4, Seattle, Washington, (http://www.f5.com/f5producs/3dns/relatedMaterials/UsingF5.html).
F5 Networks Inc., “Using F5's-DNS Controller To Provide High Availability Between Two or More Data Centers”, F5 Networks Inc., Aug. 2001, pp. 1-4, Seattle, Washington, (http://www.f5.com/f5products/3dns/relatedMaterials/3DNSRouting.html).
Fajardo V., “Open Diameter Software Architecture,” Jun. 25, 2004, pp. 1-6, Version 1.0.7.
Fan et al., “Summary Cache: A Scalable Wide-Area Protocol”, Computer Communications Review, Association Machinery, New York, USA, Oct. 1998, pp. 254-265, vol. 28, Web Cache Sharing for Computing No. 4.
Farley, M., “Enterprise Storage Forum,” Jan. 2000, 2 pages, Book Review-Building Storage Networks, 2nd Edition, http://www.enterprisestorageforum.com/sans/features/print/0,,10556_1441201.00.html, Enterprise Storage Forum Staff, last accessed Dec. 20, 2002.
GIBSON et al., “File Server Scaling with Network-Attached Secure Disks,” in Proceedings of the ACM International Conference on Measurement and Modeling of Computer Systems (Sigmetrics '97), Association for Computing Machinery, Inc., Jun. 15-18, 1997, 13 pages.
Gibson et al., “NASD Scalable Storage Systems,” Jun. 1999, 6 pages, USENIX99, Extreme Linux Workshop, Monterey, California.
Gupta et al., “Algorithms for Packet Classification,” Dept, of Comput. Sci., Stanford Univ., CA 15(2):24-32 (Mar./Apr. 2001) (Abstract only).
Harrison, C., May 19, 2008 response to Communication pursuant to Article 96(2) EPC dated Nov. 9, 2007 in corresponding European patent application No. 02718824.2.
Hartman, J., “The Zebra Striped Network File System,” 1994, Ph.D. dissertation submitted in the Graduate Division of the University of California at Berkeley.
Haskin et al., “The Tiger Shark File System,” 1998, in proceedings of IEEE, Spring COMPCON, Santa Clara, CA, www.research.IBM.com, last accessed on Dec. 30, 2002.
Heinz, “Priorities in Stream Transmission Control Protocol (SCTP) Multistreaming,” Thesis submitted to the Faculty of the University of Delaware (Spring 2003).
Hwang et al., “Designing SSI Clusters with Hierarchical Checkpointing and Single 1/0 Space,” IEEE Concurrency, Jan.-Mar. 1999, pp. 60-69.
Ilvesmaki et al., “On the Capabilities of Application Level Traffic Measurements to Differentiate and Classify Internet Traffic,” Presented in SPIE's International Symposium ITCom, Denver Colorado USA (Aug. 19-21, 2001).
International Search Report for International Patent Application No. PCT/US2008/083117 (dated Jun. 23, 2009).
International Search Report for International Patent Application No. PCT/US2008/060449 (dated Apr. 9, 2008).
International Search Report for International Patent Application No. PCT/US2008/064677 (dated Sep. 6, 2009).
International Search Report for International Patent Application No. PCT/US02/00720, dated Mar. 19, 2003.
International Search Report for International Patent Application No. PCT/US2012/038228 (dated Oct. 19, 2012).
International Search Report from International Application No. PCT/US03/41202, dated Sep. 15, 2005.
Internet Protocol, “Darpa Internet program Protocol Specification,” (RFC:791) at http://www.ietf.org/rfc/rfc791.txt, by Information Sciences Institute University of Southern California, Marina del Rey, CA, for Defense Advanced Research Project Agency Information Processing Techniques Office, Arlington, VA, pp. 1-49 (Sep. 1981).
Karamanolis, C. et al., “An Architecture for Scalable and Manageable File Services,” HPL-2001-173, Jul. 26, 2001. pp.1-14.
Katsurashima, W. et al., “NAS Switch: A Novel CIFS Server Virtualization, Proceedings,” 20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003 (MSST 2003), Apr. 2003.
Kawamoto, D., “Amazon files for Web services patent”, CNET News.com, Jul. 28, 2005, pp. 1-2, (http://news.com).
Kimball, C.E. et al., “Automated Client-Side Integration of Distributed Application Servers,” 13Th LISA Conf., 1999, pp. 275-282 of the Proceedings.
Klayman, J., response filed by Japanese associate to office action dated Jan. 22, 2007 in corresponding Japanese patent application No. 2002-556371.
Klayman, J., Nov. 13, 2008 e-mail to Japanese associate including instructions for response to office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371.
Klayman, J., Jul. 18, 2007 e-mail to Japanese associate including instructions for response to office action dated Jan. 22, 2007 in corresponding Japanese patent application No. 2002-556371.
Kohl et al., “The Kerberos Network Authentication Service (V5),” RFC 1510, Sep. 1993, 105 pages, http://www.ietf.org/rfc/rfc1510.txt?number=1510.
Korkuzas, V., Communication pursuant to Article 96(2) EPC dated Sep. 11, 2007 in corresponding European patent application No. 02718824.2-2201, 3 pages.
LaMonica M., “Infravio spiffs up Web services registry idea”, CNET News.com, May 11, 2004, pp. 1-2, (http://www.news.com).
Lelil, S., “Storage Technology News: AutoVirt adds tool to help data migration projects,” Feb. 25, 2011, last accessed Mar. 17, 2011, 3 pages, <http://searchstorage.techtarget.com/news/article/0,289142,sid5_gci1527986,00.html>.
Long et al., “Swift/RAID: A distributed RAID System”, Computing Systems, Summer 1994, 20 pages, vol. 7.
Mac Vittie, L., “Message-Based Load Balancing: Using F5 solutions to address the challenges of scaling Diameter, RADIUS, and message-oriented protocols”, F5 Technical Brief, Jan. 2010, pp. 1-9, F5 Networks Inc., Seattle, Washington.
Modiano, “Scheduling Algorithms for Message Transmission Over a Satellitebroadcast System,” MILCOM 97 Proceedings Lincoln Lab., MIT, Lexington, MA 2(2):628-34 (Nov. 2-5, 1997) (Abstract only).
Nichols, et al., “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” (RFC:2474) at http://www.ieft.org/rfc/tfc2474.txt, pp. 1-19 (Dec. 1998).
Noghani et al., “A Novel Approach to Reduce Latency on the Internet: ‘Component-Based Download’,” Proceedings of the Computing, Las Vegas, NV, Jun. 2000, pp. 1-6 on the Internet: Inti Conf. on Internet.
Norton et al., “CIFS Protocol Version CIFS-Spec 0.9,” 2001, 125 pages, Storage Networking Industry Association (SNIA), www.snia.org, last accessed on Mar. 26, 2001.
Novotny et al., “An Online Credential Repository for the Grid: MyProxy,” 2001, pp. 1-8.
Ott et al., “A Mechanism for TCP-Friendly Transport-level Protocol Coordination,” Proceedings of the General Track of the Annual Conference on USENIX Annual Technical Conference (Jun. 2002).
Padmanabhan, “Using Predictive Prefething to Improve World Wide Web Latency,” '96, SIGCOM, all pp. (1-15).
Pashalidis et al., “A Taxonomy of Single Sign-On Systems,” 2003, pp. 1-16, Royal Holloway, University of London, Egham Surray, TW20, 0EX, United Kingdom.
Pashalidis et al., “Impostor: A Single Sign-On System for Use from Untrusted Devices,” Global Telecommunications Conference, 2004, GLOBECOM '04, IEEE, Issue Date: Nov. 29,-Dec. 3, 2004, 5 pages, Royal Holloway, University of London.
Patterson et al., “A case for redundant arrays of inexpensive disks (RAID)”, Chicago, Illinois, Jun. 1-3, 1998, pp. 109-116, in Proceedings of ACM SIGMOD conference on the Management of Data, Association for Computing Machinery, Inc.
Pearson, P. K., “Fast Hashing of Variable-Length Text Strings,” Comm. of the ACM, Jun. 1990, pp. 677-680, vol. 33, No. 6.
Peterson, M., “Introducing Storage Area Networks,” Feb. 1998, 6 pages, InfoStor, www.infostor.com. last accessed on Dec. 20, 2002.
Preslan et al., “Scalability and Failure Recovery in a Linux Cluster File System,” in Proceedings of the 4th Annual Linux Showcase & Conference, Atlanta, Georgia, Oct. 10-14, 2000, pp. 169-180 of the Proceedings, www.usenix.org/publications/library/proceedings/als2000/full_papers/preslan/presl, last accessed on Dec. 20, 2002.
Raghavan B., et al., “Cloud Control with Distributed Rate Limiting”, SIGCOMM'07, Aug. 27-31, 2007, pp. 1-11, Department of Computer Science and Engineering, University of California, San Diego, CA.
Rodriguez et al., “Parallel-access for mirror sites in the Internet,” InfoCom 2000. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE Tel Aviv, Israel Mar. 26-30, 2000, Piscataway, NJ, USA, IEEE, U.S., Mar. 26, 2000 (Mar. 26, 2000), pp. 864-873, XP010376176 ISBN: 0-7803-5880-5 p. 867, col. 2, last paragraph -p. 868, col. 1, paragraph 1.
Rosen, et al., “MPLS Label Stack Encoding,” (RFC: 3032) at http://www.iett.org/rfc/rfc3032.txt, pp. 1-2 2 (Jan. 2001).
RSYNC, “Welcome to the RSYNC Web Pages,” Retrieved from the Internet URL: http://samba.anu.edu.ut.rsync/. (Retrieved on Dec. 18, 2009), 5 pages.
Savage, et al., “Afraid—A Frequently Redundant Array of Independent Disks,” Jan. 22-26, 1996, pp. 1-13, USENIX Technical Conference, San Diego, California.
Schilit B., “Bootstrapping Location-Enhanced Web Services”, University of Washington, Dec. 4, 2003, (http://www.cs.washington.edu/news/colloq.info.html).
Seeley R., “Can Infravio technology revive UDDI?”, ADTmag.comAccessed Sep. 30, 2004, (http://www.adtmag.com).
Shohoud, Y., “Building XML Web Services with VB .NET and VB 6”, Addison Wesley, Sep. 17, 2002, pp. 1-14.
Sleeper B., “The Evolution of UDDI”, UDDI.org White Paper, The Stencil Group, Inc., Jul. 19, 2002, pp. 1-15, San Francisco, California.
Sleeper B., “Why UDDI Will Succeed, Quietly: Two Factors Push Web Services Forward”, The Stencil Group, Inc., Apr. 2001, pp. 1-7, San Francisco, California.
Snoeren A., et al., “Managing Cloud Resources:Distributed Rate Limited”, Building and Programming the Cloud Workshop, Jan. 13, 2010, pp. 1-10, UCSDCSE Computer Science and Engineering.
Soltis et al., “The Design and Performance of a Shared Disk File System for IRIX,” Mar. 23-26, 1998, pp. 1-17, SixthNASA Goddard Space Flight Center Conference on Mass Storage and Technologies in cooperation with the Fifteenth IEEE Symposium on Mass Storage Systems, University of Minnesota.
Soltis et al., “The Global File System,” Sep. 17-19, 1996, 24 pages, in Proceedings of the Fifth NASA Goddard Space Flight Center Conference on Mass Storage Systems and Technologies, College Park, Maryland.
Sommers F., “Whats New in UDDI 3.0—Part 1”, Web Services Papers, Jan. 27, 2003, pp. 1-4, (http://www.webservices.org/index.php/article/articleprint/871/-1/24/).
Sommers F., “Whats New in UDDI 3.0—Part 2”, Web Services Papers, Mar. 2, 2003, pp. 1-7, (http://www.web.archive.org/web/20040620131006/).
Sommers F., “Whats New in UDDI 3.0—Part 3”, Web Services Papers, Sep. 2, 2003, pp. 1-4, (http://www.webservices.org/index.php/article/articleprint/894/-1/24/).
Sorenson, K.M., “Installation and Administration: Kimberlite Cluster Version 1.1.0, Rev. Dec. 2000,” 137 pages, Mission Critical Linux, http://oss.missioncriticallinux.com/kimberlite/kimberlite.pdf.
Stakutis, C., “Benefits of SAN-based file system shanng,” Jul. 2000, pp. 1-4, InfoStor, www.infostor.com, last accessed on Dec. 30, 2002, Penn Well Corporation.
Thekkath et al., “Frangipani: A Scalable Distributed File System,” in Proceedings of the 16th ACM Symposium on Operating Systems Principles, Oct. 1997, pp. 1-14, Association for Computing Machinery, Inc.
Traffix Systems, “Diameter Routing Agent (DRA)”, Accessed Apr. 8, 2013, pp. 2-5, (http://www traffixsystems comsolutionsdiameter-routing-agent-DRA).
Traffix Systems, “Product Brochure, Traffix Signaling Deliver Controller™ (SDC)”, Mar. 2011, pp. 1-11, F5 Networks Inc.
Traffix Systems, “Signaling Deliver Controller™: Control Your 4G Network”, Data Sheet, Mar. 2011, pp. 1-6, F5 Networks Inc.
Traffix Systems, “Signaling Delivery Controller (SDC)”, Jul. 1, 2012, pp. 2-5, (http://www traffixsystems comsolutionsSDC).
Tulloch, Mitch, “Microsoft Encyclopedia of Security,” 2003, pp. 218, 300-301, Microsoft Press, Redmond, Washington.
UDDI “UDDI Version 3.0.1”, UDDI Spec Technical Committee Specification, Oct. 14, 2003, pp. 1-383, uddi.org, (http://www.uddi.org/).
UDDI, “UDDI Overview”, Sep. 6, 2000, pp. 1-21, uddi.org, (http://www.uddi.org/).
UDDI, “UDDI Technical White Paper,” Sep. 6, 2000, pp. 1-12, uddi-org, (http://www.uddi.org/).
Uesugi, H., Nov. 26, 2008 amendment filed by Japanese associate in response to office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371, 5 pages.
Uesugi, H., English translation of office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371, 2 pages.
Wang, “Priority and Realtime Data Transfer Over the Best-effort Internet,” University of Massachusetts Amherst Dissertation (2005) (Abstract only).
Wikipedia, “Diameter (protocol)”, pp. 1-11, last accessed Oct. 27, 2010, (http://en.wikipedia.org/wiki/Diameter_(protocol)).
Wilkes, J., et al., “The HP AutoRAID Hierarchical Storage System,” Feb. 1996, 29 pages, vol. 14, No. 1, ACM Transactions on Computer Systems.
Woo, “A Modular Approach to Packet Classification: Algorithms and Results,” Nineteenth Annual Conference of the IEEE Computer and Communications Societies 3(3)1213-22 (Mar. 26-30, 2000).
Zayas, E., “AFS-3 Programmer's Reference: Architectural Overview,” Sep. 2, 1991, 37 pages, Version 1.0 (doc. number FS-00-D160) Transarc Corporation.
Provisional Applications (1)
Number Date Country
62613765 Jan 2018 US