Content delivery networks
As we know Content Delivery Networks (CDN) are used to enhance end user experience on downloading content. CDN bring the content closer to the end users and saves valuable bandwidth on core networks using caching mechanisms.
CDN engines consist of these parts:
- Routing Engine
- Serving Engine
- Management Engine
When an end users makes a request, the Routing Engine is responsible for routing the request to the most suitable Serving Engine. The Serving Engine is chosen based on multiple factors like Geographical location of the user, requested content, user agent etc. The Serving Engine is an HTTP/s server or a streaming engine which caches the content from the upstream Service Engines or from the content origin and serves the data for a group of users in a given area.
DNS based redirection
There are two commonly used redirection methods. The HTTP based and the DNS based.
DNS based redirection is determined using the source IP address of the client. In such a case the Routing Engine acts as a DNS server serving the NS for a given domain. For example, when a user puts cdn.example.com/img1.jpg to his browser, the Operating System makes a DNS query request on domain www.example.com. The request gets to the Routing Engine, which responds with the IP address of the closest Serving Engine. Once the OS gets the IP address, makes an HTTP GET request to this server.
 |
| DNS based redirection to the Serving Engine/cache |
Pros:
- Fast
Cons:
- Redirection based only on source IP address
HTTP based redirection
HTTP based redirection is more accurate redirection method than the DNS based and is more often used in CDNs. In this case the Service Router acts as a HTTP server. When a user makes a request, the domain name is resolved and a HTTP GET is sent to the Service Router. The Service Router responds with a 302 Moved Temporarily response and in the response puts the domain name of the Service Engine. The client has to resolve this domain name and make a new HTTP request to the Service Engine. This method is slower but more accurate.
 |
| HTTP based redirection to the Service Engine/cache |
Pros:
- Accurate redirection based on source IP, exact content, user agent etc.
Cons:
- Extra DNS query
- Extra HTTP GET request
Most of the service providers are using HTTP based redirection to redirect user requests to the best and closest Service Engine. Both redirection methods have their pros and cons. Our idea was to create a hybrid redirection method and get only the best of the best from the both redirection methods. This is a point where Software Defined Networking and Network Function Virtualisation comes to our mind. The redirection method and a CDN NFV will be described in the next chapter.
Software Defined Networking
Software Defined Networking is a new view on the networking. Today's network equipments like routers, switches, firewalls, NAT boxes, load-balancers, IDS/IPS systems are making their decisions based on the their implemented applications. Every node on a network is a separate thinking and decision making machine.
Software Defined Networking (SDN) separates the control plane from the data plane. The networking logic is centralised into a single node and every node on the network is just making dumb list of tasks based on rules installed by the controlling plane.
"The data plane comprises a set of one or more network elements, each of which contains a set of traffic forwarding or traffic processing resources."
In the data plane frames are forwarded according to the forwarding rules installed into the forwarder by the SDN controller. Forwarding rules are applied on the frames according to a series of match fields.
Most common matching fields are:
We can build our custom applications on top of a SDN controller. For example we can very easily create our custom application to do load balancing, firewalls DDoS filtering engine.
Software Defined Networking (SDN) separates the control plane from the data plane. The networking logic is centralised into a single node and every node on the network is just making dumb list of tasks based on rules installed by the controlling plane.
Data plane
"The data plane comprises a set of one or more network elements, each of which contains a set of traffic forwarding or traffic processing resources."
In the data plane frames are forwarded according to the forwarding rules installed into the forwarder by the SDN controller. Forwarding rules are applied on the frames according to a series of match fields.
Most common matching fields are:
- Ingress port
- Source / Destination MAC address
- Ether type
- VLAN ID
- MPLS label
- Source / Destination IP
- Source / Destination port
If a given frame matches a forwarding rule in the forwarding table the following actions may be taken:
- Output - port to send the frame out
- Set-queue - used for QoS
- Drop
- Group
- Set-field - can update field in the frame like MAC address, IP address, TTL, MPLS label etc.
If a frame enters a switch, which is not matching any forwarding rules the frame is sent to the Controller and then the controller decides what to to with the packet. Once the controller sets up the rules, sends commands to all the forwarders to what to do with the given frame if it enters their interface.
Control plane
SDN controller is a software system, which is responsible for the correct functioning of the network. This system monitors the network elements, updates the flow entries in the forwarding devices, does provisioning of new devices, makes routing and switching decisions in real time according to the state of the network, reports incidents and network failures, etc. The controller provides a high-level data model, which exactly describes the relationships between the managed devices. Provides an expansion capability for software run on the top of the SDN controller via RESTful API. Applications are able to get network information from the controller and send commands to the network elements via the SDN controller.We can build our custom applications on top of a SDN controller. For example we can very easily create our custom application to do load balancing, firewalls DDoS filtering engine.
Implementing an CDN engine in an SDN environment
Our goal was not just to implement the CDN engine, but also enhance it using SDN. In CDN HTTP based redirection is more often used because of its accuracy, but there are lot of embedded devices, set-top-boxes which are not able to handle HTTP 302 redirects and service providers must fall back to DNS based redirection. Our goal was to implement a new redirection method which is as accurate as HTTP based and fast as DNS based. So we came up with an hybrid redirection method which is using HTTP based redirection but without a 302 response message. This type of redirection is done by joining two separate TCP connections.
The initial TCP
packets and the first HTTP data packet have to be captured by the SDN
controller. The controller choses the best streaming edge server and
establishes the connection with it then joins the two separate TCP connections
to make the data flow directly between the two nodes. The TCP session joining will occur on one of the forwarders on the path.
TCP session handover
When a host
initializes a new TCP connection to the server, sends a TCP segment
encapsulated in IPv4 or IPv6 packet to the destination address. In the first
TCP segment the host sets the SYN flag, chooses a initial sequence number
(SEQ), sets the ACK number to 0, sets the window size and optionally sends some
OPTION parameters. The server on the receiving side goes to the SYN_RCVD state
and sends back his TCP packet and parameters to the client. Sets the SYN and
the ACK flag. Choses a sequence number too and sets the ACK number to sequence
number + 1 of the client. Using this he acknowledges the client to send the
next TCP window. The server chooses a window size too and sets some optional
parameters in OPTION fields. The client then sends back an ACK message to
acknowledge the parameters of the server. At this moment the session goes to
ESTABLISHED state. Now the client may request the data in a HTTP GET message
for example.
This happens
normally in networks, but we want to know, what data the client is requesting,
so we have to push the initial communication through the controller, start a
new connection to the streaming edge server and join the two connections
together.
In our case, the
establishing process will look like this. The CONTROLLER will set a flow to the
forwarder, which will pass the TCP packets to the controller. All the
communication to the request router will hit the controller, so we will be able
to catch the initial SYN request. In the controller we have to store the
request from the client and save the sequence number. We modify the raw TCP
packet, create a response SYN, ACK response for the client. We choose a random
sequence number for the response number and set the acknowledgement number to
sequence number + 1 of the initial packet. We send back the packet to the
client. The client will send back an ACK segment and will think, that it
has established a connection with the request router. It will send a HTTP GET
message in the next segment with the correct SEQ and ACK numbers. At this point
we examine the HTTP GET message and decide which streaming engine to use to
serve the content. Now we load the saved SYN request from the client, rewrite
the destination IP address and send it to the streaming edge. The streaming
edge will send back his SYN, ACK message and chooses a sequence number
randomly. Now we acknowledge the segment with the correct sequence and
acknowledgement number. Using an ACK message, we put the connection into an
established state too. Now the server waits for the HTTP GET message from us.
We load the message we received from the client, modify the acknowledgement
number and check if the sequence number is correct (should be correct as we
sent the SYN request with the same sequence number as the client sent to us),
recalculate the CRC checksum in the TCP segment, set the destination IP address
of the packet and send it to the server. At this point we have to prepare the
flows on the forwarding switch closest to the client. Flows are the following:
·
For
communication coming from the client matched by source IP address and source
TCP port:
o Increase the acknowledgement number by a
value, that it will match the sequence number of the server
o Rewrite the destination IP address of the
packet to the IP address of the service engine
o Send out the frame towards the server
·
For
communication returning from the server to the client matched by the
destination IP address and destination TCP port:
o Increase the sequence number by value,
that it will match initial sequence number chosen by the controller
o Rewrite the source IP address of the
packet to the IP address of the request router
o
Send
out the frame towards the client
With a little
luck, the TCP segments should flow the forwarder without reaching the
controller now and both client and server should communicate with each other.
Sequence and acknowledgement number will be translated too on the forwarder and
the client should think it is communicating with the request router directly.
 |
| Sequence diagram of TCP session handover |
Results
With some additional work we were able to implement a working prototype using RYU controller, OfSoftSwitch13 forwarders and some extra coding as GUI.
We created a new way of redirecting CDN sessions using SDN networks. Our redirection method is using HTTP to redirect the session, but no 302 redirected message status is necessary to be handled.
If you are interested in the whole writing feel free to download and read the document:
You can also take a look at the working prototype:
