Differentiation of Services in IMS over MPLS Network Core
Differentiation of Services in IMS over MPLS Network Core
Differentiation of Services in IMS over MPLS Network Core
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Differentiation</strong> <strong>of</strong> <strong>Services</strong> <strong>in</strong> <strong>IMS</strong> <strong>over</strong> <strong>MPLS</strong><strong>Network</strong> <strong>Core</strong>Filip BURDA, Peter HAVRILA, Marián KNĚZEK, Klaudia KONÔPKOVÁ, JurajNEMEČEK, Ján MURÁNYI*Slovak University <strong>of</strong> TechnologyFaculty <strong>of</strong> Informatics and Information TechnologiesIlkovičova 3, 842 16 Bratislava, Slovakia{filip.burda,phavrila,marian.knezek,konopielka,jan.muranyi,juraj.nemecek}@gmail.comAbstract Traffic eng<strong>in</strong>eer<strong>in</strong>g and QoS Fguarantee is crucial po<strong>in</strong>t <strong>of</strong>any operators’ network. To evaluate <strong>IMS</strong> services <strong>over</strong> <strong>MPLS</strong> enablednetwork <strong>in</strong> case study, we have created a testbed for a serviceprovider. Our service provider distributes various services requir<strong>in</strong>gdifferent traffic priorities together with customer-generated traffic. Wehave enabled the <strong>IMS</strong> core to trigger associations based on customerclasses with specified server act<strong>in</strong>g as RTP proxy for media flows.The network traffic is shaped to provide <strong>MPLS</strong> Traffic Eng<strong>in</strong>eer<strong>in</strong>gtunnels with various priorities towards these application servers <strong>in</strong><strong>IMS</strong> core. This setup allowed us to show that <strong>IMS</strong> <strong>over</strong> <strong>MPLS</strong>network creates scalable and susta<strong>in</strong>able solution for provid<strong>in</strong>gadequately priced priorities together with QoS management fordifferent customer classes based on <strong>IMS</strong> user pr<strong>of</strong>iles.1 Introduction<strong>IMS</strong> (IP Multimedia Subsystem) architecture is beh<strong>in</strong>d the current movement, result<strong>in</strong>g<strong>in</strong> extensive research <strong>of</strong> telecommunication technologies and data networks. These twopreviously separate worlds are fus<strong>in</strong>g <strong>in</strong>to the one converged environment. At thispo<strong>in</strong>t, there are more than few issues that operators would like to resolve for thesmooth <strong>in</strong>corporation <strong>of</strong> the <strong>IMS</strong> <strong>in</strong>to their networks. In our research, we have focusedon fundamental operation <strong>of</strong> the underly<strong>in</strong>g data rout<strong>in</strong>g around the <strong>IMS</strong> core. In thelatest generation <strong>of</strong> mobile networks, the quality <strong>of</strong> service and load-balanc<strong>in</strong>g couldbe native to the whole network. On the other side, data networks, and particularly the* Supervisor: Assoc. Pr<strong>of</strong>essor. Ivan Kotuliak, Institute <strong>of</strong> Computer Systems and <strong>Network</strong>s,Faculty <strong>of</strong> Informatics and Information Technologies STU <strong>in</strong> BratislavaIIT.SRC 2010, Bratislava, April 21, 2010, pp. 1–8.
<strong>Differentiation</strong> <strong>of</strong> <strong>Services</strong> <strong>in</strong> <strong>IMS</strong> <strong>over</strong> <strong>MPLS</strong> <strong>Network</strong> <strong>Core</strong> 3Figure 1. Topology with underutilized bandwidth from router R2 to R6 (dashed l<strong>in</strong>e).Currently, a comb<strong>in</strong>ation <strong>of</strong> ATM facilitates management through PVCs (PermanentVirtual Circuit) and scalability <strong>of</strong> the IP <strong>in</strong>frastructure resulted <strong>in</strong> the <strong>MPLS</strong> networksas <strong>MPLS</strong> TE. <strong>MPLS</strong> enables cha<strong>in</strong><strong>in</strong>g <strong>of</strong> labels <strong>in</strong> Protocol Data Units (PDU) and thusthe ability <strong>of</strong> non-bottom labels to have other than rout<strong>in</strong>g purposes. The two mostcommon uses for these labels <strong>in</strong> one PDU are VPN (Virtual Private <strong>Network</strong>) and TEtunnels identifications. However, tunnels are still created mostly manually as a part <strong>of</strong>the network design. Add<strong>in</strong>g new TE tunnels to the network can be accomplished eitherby a strategic approach - by creat<strong>in</strong>g full mesh <strong>of</strong> TE tunnels <strong>in</strong> parts <strong>of</strong> the network, orby a tactical approach - by the monitor<strong>in</strong>g l<strong>in</strong>k utilizations and by add<strong>in</strong>g TE tunnelswhen they are required.This work is based on [1], where VoIP requirements and deployment is described<strong>in</strong> great detail.Several works study the methodology <strong>of</strong> VoIP deployment. Most <strong>of</strong> them justsimulate VoIP calls and do not pay attention to customer differentiation [2]. We divideour customers <strong>in</strong>to three groups – gold, silver and best-effort customers. As such, weprovide a backup plan for gold customers <strong>in</strong> case the prescribed path is unavailable orquality is markedly degraded.Another approach is to allow only as much calls with assured quality as thenetwork can handle it. In <strong>MPLS</strong> network the DiffServ QoS model is used and EF(Expedited Forward<strong>in</strong>g) class is used for limited number <strong>of</strong> calls. Any other call isallowed, but it has decreased priority from the AF (Assured Forward<strong>in</strong>g) family [3].We are more ravenous, as we try to allow all the calls from gold customers even at thecost <strong>of</strong> suppress<strong>in</strong>g silver customers, which do not pay<strong>in</strong>g for these services <strong>in</strong> ourscenario.<strong>IMS</strong> is a new approach <strong>in</strong> accomplish<strong>in</strong>g convergence <strong>of</strong> communicationnetworks. It allows users to access a rich set <strong>of</strong> communication services andmultimedia content us<strong>in</strong>g already-established, and thus cost-effective, IP networks. Itsarchitecture is designed with two ma<strong>in</strong> features <strong>in</strong> m<strong>in</strong>d.
4 Filip BURDA, Peter HAVRILA, Marián KNĚZEK, Klaudia KONÔPKOVÁ, JurajNEMEČEK, Ján MURÁNYIFirst, it focuses on provid<strong>in</strong>g session control us<strong>in</strong>g a standardized set <strong>of</strong> servicescalled functions. These functions are distributed among various nodes with<strong>in</strong> thenetwork core and each function is responsible for a different set <strong>of</strong> operations,<strong>in</strong>clud<strong>in</strong>g authentication, authorization, registration, media handl<strong>in</strong>g, rout<strong>in</strong>g andservice provision<strong>in</strong>g.Its second ma<strong>in</strong> feature is the architecture's ability to add services to the network<strong>in</strong> a well-def<strong>in</strong>ed and scalable manner. These services are implemented <strong>in</strong> so-calledapplication servers and can provide a vast amount <strong>of</strong> features for the network'ssubscribers to utilize. Even <strong>in</strong> the current early stages <strong>of</strong> <strong>IMS</strong> <strong>in</strong>tegration, there arealready application servers with the ability to provide presence notification, IPTVstream<strong>in</strong>g, Video-on-Demand or <strong>in</strong>stant messag<strong>in</strong>g services. The amount <strong>of</strong> servicesand their <strong>in</strong>tegration with other services commonly available <strong>over</strong> the Internet isexpected to rapidly grow <strong>in</strong> the near future [7]. All this is implemented upon robustand tested protocols <strong>of</strong> the TCP/IP stack.Another important feature <strong>of</strong> the <strong>IMS</strong> network is its openness and focus on<strong>in</strong>teroperability. The primary communication protocol <strong>in</strong> the <strong>IMS</strong> network is theSession Initiation Protocol (SIP). S<strong>in</strong>ce this protocol is standard-based, this allows theoperator to construct parts <strong>of</strong> his <strong>IMS</strong> network us<strong>in</strong>g components and s<strong>of</strong>tware fromdifferent vendors, thus form<strong>in</strong>g a more competitive market. From the operator's po<strong>in</strong>t<strong>of</strong>-view,this feature makes <strong>in</strong>vestments <strong>in</strong> an upgrade to <strong>IMS</strong>, as opposed to currentlegacy network architectures and their closed-vendor nature, very feasible.The last important reason why <strong>IMS</strong> is expected to supersede any other form <strong>of</strong><strong>in</strong>telligent telecommunication network is the architecture's ability to use legacynetworks as part <strong>of</strong> the doma<strong>in</strong> core. This means the operator does not have to startimplement<strong>in</strong>g <strong>IMS</strong> network from scratch, but can <strong>in</strong>stead evolve his current legacynetworks to IP-based <strong>in</strong> small steps. Rather than be<strong>in</strong>g just a technology concept, thisfeature turns the <strong>IMS</strong> architecture <strong>in</strong>to a appeal<strong>in</strong>g bus<strong>in</strong>ess case which can bef<strong>in</strong>ancially justified.3 Topology descriptionIn Figure 2, the test-bed <strong>of</strong> <strong>IMS</strong> core with the surround<strong>in</strong>g redundant carrier network ispresented. The carrier network is composed <strong>of</strong> many routers with multiple redundantl<strong>in</strong>ks. We have two exit po<strong>in</strong>ts <strong>in</strong> our network to simulate transit SP (Service Provider).One exit po<strong>in</strong>t is on the far left side, and one on the far right side. <strong>IMS</strong> core is situated<strong>in</strong> the network center.
<strong>Differentiation</strong> <strong>of</strong> <strong>Services</strong> <strong>in</strong> <strong>IMS</strong> <strong>over</strong> <strong>MPLS</strong> <strong>Network</strong> <strong>Core</strong> 5Figure 2. The general transit through SP topology.In our laboratory environment, we have a limited number <strong>of</strong> devices, and that is whywe will adjust the topology as <strong>in</strong> Figure 3. We will further describe our laboratoryadjusted topology.Figure 3. Our proposed prototype <strong>of</strong> general transit through SP.We create 24 TE tunnels, 8 primary TE tunnels for gold customers, 8 backup TEtunnels for gold customers and 8 silver TE tunnels. The primary gold TE tunnels arefrom routers R1 to R3, from R2 to R3, from R7 to R5, from R8 to R5 and vice versa,because TE tunnels are unidirectional. These l<strong>in</strong>ks will be used by silver customers:from router R1 to R4, from R2 to R4, from R7 to R6, from R8 to R6 and vice versa.
6 Filip BURDA, Peter HAVRILA, Marián KNĚZEK, Klaudia KONÔPKOVÁ, JurajNEMEČEK, Ján MURÁNYIL<strong>in</strong>ks used by silver customers are also backup TE tunnels for gold customers.Therefore tunnels for gold customers and TE tunnels for silver customers share thesame paths. For a better imag<strong>in</strong>ation see Figure 4. TE tunnels are situated from everyredundant exit po<strong>in</strong>t to the network center, where we have the <strong>IMS</strong> core.Figure 4. Our <strong>MPLS</strong> TE tunnel implementation <strong>in</strong> prototype topology.We assume that on the exit po<strong>in</strong>ts, the External Border Gateway Protocol (eBGP) willbe configured. The primary TE tunnels for gold customers are placed <strong>in</strong> the rout<strong>in</strong>gtable and backup TE tunnels are not signaled yet. All the TE tunnels, for gold andsilver customers, are placed <strong>in</strong> the rout<strong>in</strong>g table via a dynamic rout<strong>in</strong>g protocol, <strong>in</strong> ourcase via the Integrated Intermediate System to Intermediate System (IS-IS) protocol.When the primary TE tunnel for gold customers fails, prescribed backup TE tunnel willbe signaled and created. Convergence time is a little bit longer, because a backup pathmust be created and demands must be signaled first. Protection or fast reroute optionsare other options, but they are not widely implemented and are not supported <strong>in</strong> ourdevices. Their convergence time is much shorter.Because <strong>of</strong> the limited bandwidth on the l<strong>in</strong>ks, it is possible that the backup TEtunnel will force out the TE tunnel for silver customers, if the required constra<strong>in</strong>ts <strong>of</strong>the l<strong>in</strong>ks are not satisfied. When the primary path renews, the backup path is shut downand traffic flows return to prescribed paths.For the purpose <strong>of</strong> monitor<strong>in</strong>g and manag<strong>in</strong>g available bandwidth on the l<strong>in</strong>ks <strong>in</strong><strong>MPLS</strong> environment, we are us<strong>in</strong>g a 3rd party external tool. This tool <strong>in</strong>teractivelychanges the requirements for bandwidth demands for TE tunnels, thus hav<strong>in</strong>gsufficient reserved bandwidth at all times. It is imperative that real time traffic flows <strong>in</strong><strong>MPLS</strong> [5] receive required bandwidth and therefore monitor<strong>in</strong>g is essential.
<strong>Differentiation</strong> <strong>of</strong> <strong>Services</strong> <strong>in</strong> <strong>IMS</strong> <strong>over</strong> <strong>MPLS</strong> <strong>Network</strong> <strong>Core</strong> 74 <strong>IMS</strong> <strong>Core</strong> ImplementationsOur <strong>IMS</strong> network is based on an open source project called Open <strong>IMS</strong> <strong>Core</strong>. Theimplemented network consists <strong>of</strong> several separate physical mach<strong>in</strong>es, each runn<strong>in</strong>g anunique service used to guarantee control <strong>over</strong> exist<strong>in</strong>g sessions or execut<strong>in</strong>g other tasksrelated to <strong>IMS</strong> architecture functionality. These <strong>in</strong>dividual parts <strong>of</strong> the <strong>IMS</strong> corenetwork can be seen <strong>in</strong> Figure 2.The CSCF mach<strong>in</strong>e provides session control functions with<strong>in</strong> our <strong>IMS</strong> doma<strong>in</strong>. Itis built us<strong>in</strong>g an open-source SIP Express Router s<strong>of</strong>tware (SER). Comb<strong>in</strong>ed withthe HSS these two components form the core <strong>of</strong> our <strong>IMS</strong> network.The HSS mach<strong>in</strong>e's s<strong>of</strong>tware is implemented us<strong>in</strong>g an open source MySQLdatabase and a Diameter server created us<strong>in</strong>g the Java programm<strong>in</strong>g language.The Application Servers (AS) are primarily based on SER. For hardwarerequirements reduction, multiple Application Servers are runn<strong>in</strong>g on one physicalmach<strong>in</strong>e. Due to this setup, AS <strong>in</strong>stances are separated by us<strong>in</strong>g several IP addresseson this one physical mach<strong>in</strong>e, with one address for each <strong>in</strong>dividual Application Server.The Gateway + DNS mach<strong>in</strong>e provides DNS services and other supportive tasksrequired by both network subscribers and the <strong>IMS</strong> core.QoS provision<strong>in</strong>g <strong>in</strong> our network can be done <strong>in</strong> numerous ways. In our solution,we focus on provid<strong>in</strong>g QoS for RTP streams us<strong>in</strong>g two ma<strong>in</strong> tools.Firstly, a RTP stream for each call is processed by a special Application Servercalled Gold AS and Silver AS. These ASs are responsible for modify<strong>in</strong>g the contents<strong>of</strong> the SDP protocol fields <strong>in</strong> <strong>in</strong>dividual SIP INVITE messages, so that all parties<strong>in</strong>cluded with<strong>in</strong> a dialog send RTP not directly, but through these AS servers. Thedest<strong>in</strong>ation IP <strong>of</strong> RTP packets for such dialogs orig<strong>in</strong>ation from our subscribers willtherefore conta<strong>in</strong> the IP address <strong>of</strong> the AS and thus the SIP User Agents will notcommunicate directly with each other.Secondly, each customer has a specific service pr<strong>of</strong>ile (<strong>IMS</strong> user pr<strong>of</strong>ile)depend<strong>in</strong>g on the required level <strong>of</strong> QoS. These pr<strong>of</strong>iles are sets <strong>of</strong> conditions anddest<strong>in</strong>ations for <strong>in</strong>com<strong>in</strong>g SIP messages. Based on the caller and the requested service,we can specify AS to handle session creation and management. Us<strong>in</strong>g two unique AS(Gold and Silver), one for each customer class, we can dist<strong>in</strong>guish and classify usertraffic based on the unique source or dest<strong>in</strong>ation IP address <strong>of</strong> our AS <strong>in</strong> the RTPpacket. S<strong>in</strong>ce our network <strong>of</strong>fers two types <strong>of</strong> customer classes along with best effort,we have two AS <strong>in</strong>stances attached to two different service pr<strong>of</strong>iles.Us<strong>in</strong>g this method, we are able to provide several different levels <strong>of</strong> QoSguarantees by simply provision<strong>in</strong>g different service pr<strong>of</strong>iles for customers with adifferent customer class.
8 Filip BURDA, Peter HAVRILA, Marián KNĚZEK, Klaudia KONÔPKOVÁ, JurajNEMEČEK, Ján MURÁNYI5 ConclusionsIn this paper, we have briefly expla<strong>in</strong>ed <strong>MPLS</strong> Traffic Eng<strong>in</strong>eer<strong>in</strong>g solution withregard to prioritize QoS differentiated multimedia traffic by def<strong>in</strong>ed <strong>IMS</strong> corecustomer classes. The testbed was created for simulation <strong>of</strong> transit service providerwhich was able to provide gold, silver and best-effort priority customer classes basedsolely on <strong>IMS</strong> user pr<strong>of</strong>iles. By us<strong>in</strong>g a comb<strong>in</strong>ation <strong>of</strong> <strong>MPLS</strong> Traffic Eng<strong>in</strong>eer<strong>in</strong>g and<strong>IMS</strong> with several application servers act<strong>in</strong>g as RTP proxies for voice calls, we wereable to make the whole <strong>MPLS</strong> backbone recognize these customer classes.Consequently, the network is able to provide QoS management us<strong>in</strong>g <strong>MPLS</strong> TrafficEng<strong>in</strong>eer<strong>in</strong>g tunnels with various priorities. This setup allowed us to create scalableand susta<strong>in</strong>able solution for provid<strong>in</strong>g price adequate priorities to different customerclasses based on <strong>IMS</strong> user pr<strong>of</strong>iles.Acknowledgement: This work was supported by the Grant No.1/0243/10 <strong>of</strong> the SlovakVEGA Grant Agency. We would like to thank Tatrabanka foundation grant forsupport<strong>in</strong>g this project.References[1] Karapantazis, S., Pavlidou, F.: VoIP: A comprehensive survey on a promis<strong>in</strong>gtechnology. Computer <strong>Network</strong>s, August 2009, vol. 53, no. 12, pp. 2050-2090.[2] Salah, K.: VoIP: On the deployment <strong>of</strong> VoIP <strong>in</strong> Ethernet networks: methodologyand case study. Computer Communications, May 2006, vol. 29, no. 8, pp. 1039-1054.[3] Chen, H., Cheng, B., Su, H.: An objective-oriented service model for VoIP<strong>over</strong>lay networks <strong>over</strong> DiffServ/<strong>MPLS</strong> networks. Computer Communications,November 2007, vol. 30, no. 16, pp. 3055-3062.[4] Mohan, G., Shi, T. J.: An efficient traffic eng<strong>in</strong>eer<strong>in</strong>g approach based on flowdistribution and splitt<strong>in</strong>g <strong>in</strong> <strong>MPLS</strong> networks. Computer Communications, May2006, vol. 29, no. 9, pp. 1284-1291.[5] Liefvoort, A., Medhi, D., Srivastava, S.: Traffic eng<strong>in</strong>eer<strong>in</strong>g <strong>of</strong> <strong>MPLS</strong> backbonenetworks <strong>in</strong> the presence <strong>of</strong> heterogeneous streams. Computer <strong>Network</strong>s, October2009, vol. 53, no. 15, pp 2688-2702.[6] M<strong>in</strong>gozzi, E., Callejo-Rodríguezb, M.A., Enríquez-Gabeirasb, J.: EuQoS: Endto-EndQuality <strong>of</strong> Service <strong>over</strong> Heterogeneous <strong>Network</strong>s. ComputerCommunications, July 2009, vol. 32, no. 12, pp. 1355-1370.[7] Russel, T.: The IP Multimedia Subsystem (<strong>IMS</strong>). McGraw-Hill, 2008, pp. 27-55.