Adding the OpenFlow variable to the IMS equation
Tinniam V Ganesh 270004Y158 Visits (4184)
IMS a non-starter: IP Multimedia Systems (IMS) has been the grand vision of this decade. Unfortunately it has remained just that, a vision, with sporadic deployments. IMS has been a non-starter in many respects. Operators and Network Providers somehow don’t find any compelling reason to re-architect the network with IMS network elements. There have been no killer applications too. But IP Multimedia Systems definitely hold enormous potential and a couple of breakthroughs in key technologies can result in the ‘tipping point’ of this great technology which promises access agnostic services including applications like video-conferencing, multi-player gaming, white boarding all using an all-IP backbone.
SDNs, revolutionary: In this scenario a radically new, emerging concept is the Software Define Networks (SDNs). SDN is the result of pioneering effort by Stanford University and University of California, Berkeley and is based on the Open Flow Protocol and represents a paradigm shift to the way networking elements operate. SDNs consist of the OpenFlow Controller which is able to control network resources in a programmatic manner. These network resources can span routers, hubs and switches, known as a slice, and can be controlled through the OpenFlow Controller. The key aspect of the OpenFlow protocol is the ability to manage slices of virtualized resources from end-to-end. It is this particular aspect of Software Defined Networks (SDNs) and the OpenFlow protocol which can be leveraged in IMS networks.
This article looks at a way in which OpenFlow protocol can be included in the IMS fabric and provide for QoS in the IMS network. However, please note that this post is exploratory in nature and does not purport to be a well researched article. Nevertheless the idea is well worth mulling over.
QoS in IMS: The current method of ensuring differentiated QoS in IMS networks is through two key network elements, namely the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). The PDP retrieves the necessary policy rules (flow parameters), in response to a RSVP message, which it then sends to the PEP. The PEP then executes these instructions. In the IMS the Policy Control Function (PCF), in the P-CSCF, plays the role of the PDP. The PEP resides in the GGSN. In an IMS call flow, the SDP message is encapsulated within SIP and carries the QoS parameters. The PCF examines the parameters, retrieves appropriate policies and informs the PEP in the GGSN for that traffic flow.
OpenFlow in P-CSCF: This post looks at a technique in which the OpenFlow Controller can be a part of the P-CSCF. The QoS parameters which come in the SDP message can be similarly examined. Instead of retrieving fixed policy rules, the OpenFlow Controller in the P-CSCF can be made to programmatically identify bandwidth speeds, the routers and the network slice through which the flow should flow. It would then inform the equivalent of the OpenFlow Switch in the GGSN which would control the necessary network resources end-to-end. The advantage of using OpenFlow Controller/OpenFlow switch to the PDP/PEP combination would be the ability to adapt the network flow according to bandwidth changes and traffic. The OpenFlow Controller will be able to dynamically re-route the traffic to alternate network resources, or a different ‘network slice’ in cases of congestion.
Conclusion: In my opinion, adding the OpenFlow Protocol to the IP Multimedia Switching fabric can provide for a much more control and better QoS in the network. It may also be able to provide for a lot more interesting applications to the already existing set of powerful applications