Difference between revisions of "VICN/Tutorial/HetnetLoadBalancing"
Jordan.auge (Talk | contribs) (Created page with "This tutorial is focused on the network emulation aspects of vICN, and illustrates how the tool allows to create topology including both wired links, as well as WiFi and LTE w...") |
(No difference)
|
Revision as of 23:23, 24 March 2017
This tutorial is focused on the network emulation aspects of vICN, and illustrates how the tool allows to create topology including both wired links, as well as WiFi and LTE wireless links. We focus on a typical 5G use case where we want to seamlessly load balance traffic over both available radio links at the same time, using the optimal load-balancing scheme present in the ICNET stack, and more precisely in the RAAQM transport scheme.
The topology is made of four nodes: a consumer, a WIFI AP, an LTE base station, and a producer, as illustrated in the picture, and the consumer is using both radio access at the same time to download content from the producer.
Topology creation
The JSON topology file corresponding to this tutorial can be found in examples/tutorial/tutorial03-hetnet.json
This file contains two parts, a declaration of the resource, as well as some configuration parameters for the experiment, in our case the IP subnet used to configure the nodes.
{
"resources": [...],
"settings": {
"network": "192.168.2.0/24"
}
}
Base resources
We start by describing the resources on which we will deploy our experiment, a physical node (identified by "localhost" since we will run the experiment on the local machine) connected to the Internet via a bridge br0 in our case.
{
"type": "Physical",
"name": "server",
"hostname": "localhost"
},
{
"type": "NetDevice",
"device_name": "br0",
"node": "server",
"managed": false
}
We also use [image] as in the previous tutorials.
{
"type": "LxcImage",
"name": "ubuntu1604-cicnsuite-rc1",
"node": "server"
},
Experiment resources
Based on this image, we will deploy 4 containers to form the simple diamond topology we described previously: cons, wifi, lte and prod.
{
"type": "LxcContainer",
"image": "ubuntu1604-cicnsuite-rc1",
"name": "cons",
"node": "server",
"category": "tablet",
"x": 1,
"y": 2
},
{
"type": "LxcContainer",
"image": "ubuntu1604-cicnsuite-rc1",
"name": "wifi",
"node": "server",
"category": "wifi",
"x": 2,
"y": 1
},
{
"type": "LxcContainer",
"image": "ubuntu1604-cicnsuite-rc1",
"name": "lte",
"node": "server",
"category": "lte",
"x": 2,
"y": 3
},
{
"type": "LxcContainer",
"image": "ubuntu1604-cicnsuite-rc1",
"name": "prod",
"node": "server",
"category": "video-server",
"x": 3,
"y": 2
},
We added new attributes that are used by the visualization tool to display the topology, which is to be released as part of the vICN codebase: a category that mainly sets the icon, as well as some coordinates.
Each of these nodes will receive a CICN forwarder, and the producer will also host a webserver able to serve content such as DASH video.
{
"type": "MetisForwarder",
"node": "cons"
},
{
"type": "MetisForwarder",
"node": "wifi"
},
{
"type": "MetisForwarder",
"node": "lte"
},
{
"type": "MetisForwarder",
"node": "prod"
},
{
"type": "WebServer",
"node": "prod",
"prefixes": [
"/webserver"
]
},
We remark that the Webserver (which inherits from Producer) includes a prefix that will get advertised in the network thanks to the central routing functionality we present later.
We now add two wired links between the wifi and lte nodes, and the producer:
{
"type": "Link",
"src_node": "wifi",
"dst_node": "prod"
},
{
"type": "Link",
"src_node": "lte",
"dst_node": "prod"
},
In the same way, we create the emulated radio channels, respectively WiFi and LTE
{
"type": "EmulatedWiFiChannel",
"name": "wch",
"node": "server",
"ap": "wifi",
"stations": ["cons"],
"control_port": 30001
},
{
"type": "EmulatedLteChannel",
"name": "lch",
"node": "server",
"ap": "lte",
"stations": ["cons"],
"control_port": 30002
},
In our simple setup, each channel has a single station: the consumer node. We define for each channel a control port that will both allow the monitoring of the channel as well as its dynamic configuration (not covered yet by the tutorial).
Finally, we add the centralized control resources for both the IP (control plane) and ICN (experimental plane) layers, as previously used.
{
"type": "CentralIP",
"ip_routing_strategy": "spt"
},
{
"type": "CentralICN",
"icn_routing_strategy": "spt",
"face_protocol": "udp4"
}
== First tests
For a first test, we will not setup the WebServer with a DASH video catalog, but will resort to some test tools to generate interests and produce data. We will take advantage of the fact that the /webserver prefix is routed in the network, by setting a more specific prefix for our application not to conflict a potentially running webserver (in that case the traffic would be spread among the two).
On our host machine, we can run:
$ lxc exec prod -- producer-test ccnx:/webserver/test $ lxc exec cons -- consumer-test ccnx:/webserver/test
We notice that the traffic goes onto the WiFi link only (or LTE depending on the results of the routing). This is because we specified the Shortest Path Tree algorithm in our CentralICN resource, which uses a typical Dijkstra algorithm to compute the routes.
Indeed, a single route is present in the forwarder located on the consumer:
lxc exec cons -- metis_control -k keystore.pkcs12 -p password list routes
[...]
iface protocol route cost next prefix
3 STATIC LONGEST 1 ---.---.---.---/.... ccnx:/webserver
Done
Let's for the moment just fix the forwarder configuration to enable two output interfaces and benefit from multipath load-balancing across the two. We can list the connections to find the right ID to add.
$ lxc exec cons -- metis_control -k keystore.pkcs12 -p password list connections
[...]
3 UP inet4://192.168.2.2:6363 inet4://192.168.2.3:6363 UDP
5 UP inet4://192.168.2.6:6363 inet4://192.168.2.7:6363 UDP
7 UP inet4://127.0.0.1:9695 inet4://127.0.0.1:32876 TCP
$ lxc exec cons -- metis_control -k keystore.pkcs12 -p password add route 5 ccnx:/webserver 1
By starting our same test commands, we now see the traffic being spread over both radio links, as depicted in the picture at the beginning of this tutorial.
Planned tutorial extensions
- Setting link capacities
- Setup node position/distance in the radio channel
- Using a multipath routing protocol
- Serving DASH content
- More information about monitoring both wired and wireless links
