MVO Optimization Daisy Chains

The concept of Daisy Chains as it relates to Circadence MVO technology involves the ability to connect to multiple destination networks from a single client and optimize the delivery of content from each of the connected networks individually.  The Daisy Chain allows the client to utilize the Circadence MVO optimized path between multiple MVO appliances across networks (or across subnets within a single network) until it reaches the nearest point of access.  This serves a dual purpose by extending the WAN optimization data path  as well as the Circadence Link Resilience capability as far as possible (or as far as is necessary).

One way to envision this concept is to have an organization with end users connecting to applications and retrieving content that are located at more than one location across the enterprise. Typically this could include content located in a branch office as well as a headquarters location and perhaps a datacenter. In typical WAN Optimization deployment the end user or client side implementation would have to have individual tunnels established from the end point to each head-end location separately.  With Daisy Chaining enabled in MVO there is a single head-end configured in the end user client or client-side endpoint, only the first link in the chain needs to be configured.

To illustrate the concept assume a user is connecting via laptop to their enterprise while on the road. The user has applications which connect to servers located within the enterprise and is requesting content that is located at multiple locations within the enterprise extranet. The user’s device has the MVO client installed and configured to connect to the MVO head-end installation located at their home office, which is a branch of the larger corporation. Further assume that the applications and content required are located at: the user’s brand office, at the company headquarters, at a company datacenter, and at a cloud hosted location. The configuration and workflow would be the following: 

We can make the following assumptions about the network connection:

1. The end user “A” is connecting to the public internet “B” via WiFi, Cellular Data, or wired Ethernet.
2. The end user “A” has/has not established a VPN connection to the Branch Office “C”.
3. The Branch Office “C” is connected by an IP network connection to Corp Headquarters “D”.
4. The Corp Headquarters “D” is connected by an IP network connection to a Corp Datacenter “W”. 
5. The Corp Datacenter is connected by an IP network connection to a private or public Cloud Service “E”.

The MVO client application installed on “A” is configured as a MVO Remote with a peer connection to the MVO Hub located at “C”. The Hub at “C” has a MVO Managed Traffic Definition “MTD” configured for applications and content located on network “C” (c.c.c.c). If “A” requests content located on the c.c.c.c network the MVO Remote client will divert the original IP request to the MVO process, which will then encode the original IP packets into the enhanced TMP and send the request via the TMP protocol to the MVO Hub located at “C”. The Hub at “C” will process the request from “A” and return the appropriate c.c.c.c content via the TMP connection from the MVO Hub process at “C” to the MVO Remote process at “A”. The MVO Remote process at “A” will then decode the TMP packets into the original IP and forward to the original requesting local client process.

The MVO instance located at “C” is configured as both a MVO Hub and a MVO Remote. The MVO Remote process is configured to connect to the MVO peer located at “D”. The Hub at “D” has a MVO Managed Traffic Definition “MTD” configured for applications and content located on network “D” (d.d.d.d). If “C” requests content located on the d.d.d.d network the MVO Remote process will divert the original IP request to the MVO process, which will then encode the original IP packets into the enhanced TMP and send the request via the TMP protocol to the MVO Hub located at “D”. The Hub at “D” will process the request from “C” and return the appropriate d.d.d.d content via the TMP connection from the MVO Hub process at “D” to the MVO Remote process at “C”. The MVO Remote process at “C” will then decode the TMP packets into the original IP and forward to the original requesting local client process.  Additionally, the MVO instance at “C” has been configured to support Daisy Chains. The Daisy Chain configuration allows the MVO Hub instance to internally forward IP packets destined for a network which has MTD rules applied at the same MVO instance’s Remote process from a distant MVO Hub. With Daisy Chains enabled, if “A” requests content located on the d.d.d.d network the MVO Remote client will divert the original IP request to the MVO process, which will then encode the original IP packets into the enhanced TMP and send the request via the TMP protocol to the MVO Hub located at “C”. The Hub at “C” will process the d.d.d.d request from “A” and forward the request for content from d.d.d.d to the MVO Remote process at “C”. The MVO Remote process at “C” will send the request via the TMP protocol to the MVO Hub located at “D”. The Hub at “D” will process the request from “A” and return the appropriate d.d.d.d content via the TMP connection from the MVO Hub process at “D” to the MVO Remote process at “C”. The Daisy Chain enabled MVO instance at “C” will then internally forward the d.d.d.d content from the “C” Remote process to the “C” Hub process for transport to “A”. The MVO Remote process at “A” will then decode the TMP packets into the original IP and forward to the original requesting local client process at “A”.

The MVO instance located at “D” is also configured as both a MVO Hub and a MVO Remote. The MVO Remote process is configured to connect to the MVO peer located at “W”. The Hub at “W” has MVO Managed Traffic Definition “MTD” configured for applications and content located on network “W” (w.w.w.w) and Cloud Service “E” (e.e.e.e). If “D” requests content located on the w.w.w.w or e.e.e.e network the MVO Remote process will divert the original IP request to the MVO process, which will then encode the original IP packets into the enhanced TMP and send the request via the TMP protocol to the MVO Hub located at “W”. (The process for content from either w.w.w.w or e.e.e.e is fundamentally similar so only w.w.w.w will be detailed) The Hub at “W” will process the request from “D” and return the appropriate w.w.w.w content via the TMP connection from the MVO Hub process at “W” to the MVO Remote process at “D”. The MVO Remote process at “D” will then decode the TMP packets into the original IP and forward to the original requesting local client process.  Additionally, the MVO instance at “D” and at “W” have been configured to support Daisy Chains. The Daisy Chain configuration allows the MVO Hub instance to internally forward IP packets destined for a network which has MTD rules applied at the same MVO instance’s Remote process from a distant MVO Hub. With Daisy Chains enabled, if “A” requests content located on the w.w.w.w network the MVO Remote client will divert the original IP request to the MVO process, which will then encode the original IP packets into the enhanced TMP and send the request via the TMP protocol to the MVO Hub located at “C”. The Hub at “C” will process the w.w.w.w request from “A” and forward the request for content from w.w.w.w to the MVO Remote process at “C”. The MVO Remote process at “C” will send the request via the TMP protocol to the MVO Hub located at “D”. The Hub at “D” will process the w.w.w.w request from “A” through “C” and forward the request for content from w.w.w.w to the MVO Remote process at “D”. The MVO Remote process at “D” will send the request via the TMP protocol to the MVO Hub located at “W”. The Hub at “W” will process the forwarded request from “A” and return the appropriate w.w.w.w content via the TMP connection from the MVO Hub process at “W” to the MVO Remote process at “D”. The Daisy Chain enabled MVO instance at “D” will then internally forward the w.w.w.w content from the “D” Remote process to the “D” Hub process for transport to “C”. The Daisy Chain enabled MVO instance at “C” will then internally forward the w.w.w.w content from the “C” Remote process to the “C” Hub process for transport to “A”. The MVO Remote process at “A” will then decode the TMP packets into the original IP and forward to the original requesting local client process at “A”.

Functionally the Daisy Chain process works as an inherent function of MVO being able to operate with both Frontend (Remote) and Backend (Hub) processes running simultaneously. In a network consisting of a MVO Remote “A”, first MVO Hub “B”, and second MVO Hub “C”: As traffic from a Frontend process at Remote “A” arrives at the Backend process of the Hub “B” if it does NOT meet a MTD rule being diverted by the “B” Hub’s Frontend process it is exited from the MVO application at that location. If the traffic from the Remote meets the definition of a MTD divert running on the Frontend process at the “B” Hub it is reprocessed and sent along to the upstream “C” Hub. The configuration is best approached in reverse, from the last link in the chain to the first remote client.