Net­work Func­tion Vir­tu­al­iza­tion Im­pact on OSS

A spot­light on the ben­e­fits of Net­work Func­tion Vir­tu­al­iza­tion (NFV), and its im­pact on Oper­a­tions Sup­port Sys­tem (OSS).

Voice&Data - - FRONT PAGE - Ajay Pat­ter Veetil [email protected]­ber­me­dia.co.in

Vir­tu­al­iza­tion is not new. It dates back to 1960 when vir­tual mem­ory man­age­ment was made pos­si­ble on main­frames and to­day many com­mu­ni­ca­tion func­tions such as pol­icy con­trol, real-time charg­ing etc. are al­ready run­ning on vir­tu­al­ized en­vi­ron­ment. It makes sense to ex­tend this func­tion­al­ity to other ar­eas as the tra­di­tional net­work is over en­gi­neered to meet the worst-case sce­nar­ios of busy hours and 40-60% of the net­work is un­der­uti­lized. In con­trast to this ap­proach, if we ad­dress ‘the need of hour’ by dy­namic de­ploy­ment of net­work re­sources, the an­tic­i­pated amount of sav­ings would be mul­ti­fold.

NFV is an at­tempt to vir­tu­al­ize and au­to­mate net­work func­tions so that it can be man­aged on a gen­eral-pur­pose x86-based IT in­fra­struc­ture in­stead of ASIC-based pur­pose built ap­pli­ances. Any net­work func­tion that is/or can be vir­tu­al­ized is termed as Vir­tual Net­work Func­tion (VNF). NFV aims to bring in ex­ten­sive or­ches­tra­tion ca­pa­bil­ity to make dy­namic de­ploy­ment of VNF pos­si­ble, there by ad­dress­ing the is­sue of un­der­uti­lized net­work. The fig­ure be­low is a con­cep­tual ar­chi­tec­ture of NFV plat­form.

Key Driv­ers

Fol­low­ing are ob­vi­ous ben­e­fits re­al­ized from the NFV con­cept.

Low Capex and Opex: Capex sav­ings will come by re­plac­ing the ex­pen­sive be­spoke ap­pli­ances cheaper com­mod­ity hard­ware and op­ti­mized net­work uti­liza­tion with ‘Just in Time’ in­tro­duc­tion of VNFs. Opex cost will be re­duced by au­tomat­ing tra­di­tional man­ual net­work con­fig­u­ra­tion oper­a­tions.

Elas­tic­ity: With the re­al­iza­tion of NFV, scale up and scale down of net­work shall be pos­si­ble which will en­able com­mu­ni­ca­tion ser­vice provider to man­age an op­ti­mized net­work.

Ser­vice Agility: NFV will sup­port new ser­vice roll­outs faster. In the cur­rent sce­nario it takes weeks to months to roll out busi­ness ser­vices due to lengthy cy­cle of pro­cure­ment, test­ing and de­ploy­ment. With NFV this is ex­pected to re­duce dras­ti­cally lev­er­ag­ing on faster soft­ware based in­te­gra­tion, val­i­da­tion and de­ploy­ment.

Op­er­a­tional Sim­plic­ity: NFV vouches for open stan­dards-based im­ple­men­ta­tion, which will bring an op­por­tu­nity to sim­plify the el­e­ments and EMS, which in turn will sim­plify

pro­vi­sion­ing em­bar­rass­ing multi-ven­dor ecosys­tem.

Rapid In­no­va­tion: In­no­va­tion will be made easy since soft­ware is gov­ern­ing net­work. Gone will be the days where ser­vice provider will have to re­quest for a hard­ware change and wait for the NEM to de­liver. Ser­vice Provider will be able to in­no­vate new Net­work Ser­vices in his lab with­out de­pen­dency on NEM ven­dor.

Chal­lenges of NFV for OSS

Some of the key chal­lenges that will be faced by OSS are:

Hy­brid En­vi­ron­ment: Vir­tual Net­work Func­tions (VNFs) and Phys­i­cal Net­work Func­tions (PNFs) will have to co-ex­ist and man­age­ment of such a hy­brid en­vi­ron­ment is in­evitable. OSS mod­ules will have to be en­hanced to ad­dress a sce­nario where a net­work func­tion will be partly in a phys­i­cal de­vice and the re­main­ing part will be on a vir­tual server. In such an en­vi­ron­ment there will be need for a sin­gle Re­source and Ser­vice In­ven­tory which will hold ref­er­ences of both PNFs and VNFs to pro­vide other OSS and BSS sub­sys­tems a global view of Net­work Re­sources.

Ab­strac­tion: As op­posed to con­ven­tional way of man­age­ment now it has to be done to an “ab­strac­tion”. This is a ma­jor change to the tra­di­tional OSS. There will be a need to de­sign a re­la­tion be­tween ab­stract vir­tual in­fra­struc­ture and phys­i­cal in­fra­struc­ture. One or many of the OSS mod­ules may be re­spon­si­ble to model this ab­strac­tion. The re­la­tion is im­por­tant to be main­tained to mon­i­tor net­work func­tions at both phys­i­cal and log­i­cal lev­els.

Man­age Dy­nam­ic­ity and Real Time: De­ploy­ment of a VNF will take few min­utes as op­posed to weeks / months. Due to the dy­namic na­ture of re­source de­ploy­ment in the net­work, OSS com­po­nents like Re­source In­ven­tory, Pro­vi­sion­ing & Ac­ti­va­tion and Fault man­age­ment will have to scale up with ad­di­tional fea­tures to cope with this dy­namic be­hav­ior. One can en­vis­age the need for real time OSS com­po­nents to man­age VNFs. Cur­rent OSS sys­tems es­pe­cially Re­source & Ser­vice In­ven­tory is not equipped to man­age this dy­nam­ic­ity and real time be­hav­ior.

Ca­pac­ity Man­age­ment

With the abil­ity to spawn VNFs dy­nam­i­cally, there has to be a tight con­trol and man­age­ment on: —Thresh­olds, upon cross­ing which VNFs should be spawned. —The clash be­tween mul­ti­ple VNFs com­pet­ing for un­der­line phys­i­cal re­sources. —Pol­icy driven de­ci­sion on when a new VNF is to be spawned and de­com­mis­sioned.

Process Re­align­ment

With the ad­vent of NFV, there will be a need for OSS pro­cesses to be re­aligned so that both tra­di­tional and vir­tu­al­ized in­fra­struc­ture can be man­aged si­mul­ta­ne­ously. Pro­vi­sion­ing process will definitely wit­ness an ad­di­tional layer of man­age­ment and or­ches­tra­tion. In cur­rent tra­di­tional way, ex­pan­sion of net­work hap­pens af­ter a lot of test­ing and plan­ning us­ing Plan­ning Tool.

Once ap­proved net­work re­sources are in­stan­ti­ated in Re­source In­ven­tory to model the en­hanced in­fra­struc­ture with an “Avail­able” sta­tus. While this process will con­tinue to ex­ist in the case of ma­jor net­work ex­pan­sions, one can en­vis­age quicker plan­ning and de­ploy­ment process for small scale up / scale down of net­work. It will be de­mand based and there will be use of more an­a­lyt­ics and in­tel­li­gent mech­a­nism for scale up and scale down of net­work. In the ful­fill­ment process, ser­vice fea­si­bil­ity process might change. If the re­lated VNFs are run­ning out of ca­pac­ity, ser­vice fea­si­bil­ity check might not fail as there is a pos­si­bil­ity of scal­ing up the cor­re­spond­ing VNF or spawn­ing a new VNF. Fea­si­bil­ity check might ac­tu­ally fail only if the un­der­line vir­tual in­fra­struc­ture is also run­ning out of ca­pac­ity.

With the ab­strac­tion of soft­ware com­po­nents from ASIC hard­ware to stan­dard x86-based com­mod­ity servers, net­work en­gi­neers will have to learn IT and IT en­gi­neers will have to learn more Net­works.

Per­for­mance

To make OSS real time, per­for­mance of the sys­tems are ex­pected to in­crease dras­ti­cally. Ac­cord­ingly, hard­ware and soft­ware changes should hap­pen to OSS Sys­tems. To cope with the dy­namic changes like scale up and scale down of net­work, per­for­mance of th­ese sys­tems will be crit­i­cal. Cur­rent OSS sys­tems will not be able to scale up for this de­mand. Hence, it has to be re­vamped to meet this need.

En­vis­aged Changes and Im­pact on OSS

New gen­er­a­tion OSS will have to man­age an ‘ab­strac­tion’ and not just a phys­i­cal ap­pli­ance or PNF. OSS will have to be more ser­vice-cen­tric. Net­work ser­vice(s) which en­com­passes mul­ti­ple VNFs, and tra­di­tional PNFs, will have to be mod­eled in OSS. There should be a means to model all NFV en­ti­ties in Re­source & Ser­vice In­ven­tory of OSS along with a ref­er­ence map­ping to its cor­re­spond­ing Vir­tual Ma­chines. Once the con­cept is fully evolved, there is pos­si­bil­ity of an over­lap of func­tion­al­ity be­tween OSS com­po­nents and NFV com­po­nents.

New gen­er­a­tion OSS will for sure be more ‘Real Time’. It will also be gov­erned by some busi­ness rules and poli­cies to take in­tel­li­gent de­ci­sions. Hence, OSS will have to cope with this dy­nam­ic­ity and be­come more real-time with the help of NFV Ser­vice As­sur­ance and data an­a­lyt­ics.

Some of the key ar­eas un­der the OSS do­main which will un­dergo change are dis­cussed be­low.

Re­source & Ser­vice In­ven­tory

and Ac­ti­va­tion Sys­tem: While mod­el­ing of phys­i­cal de­vices will con­tinue to hap­pen for PNFs, re­source in­ven­tory will have to be en­hanced to model more log­i­cal ob­jects and maps with all NFV en­ti­ties in the form of net­work ser­vice ob­jects that de­pict end-to-end net­work ser­vice. A map­ping of VNF in­stances and its cor­re­spond­ing vir­tual ma­chine de­tails will have to be stored in Re­source & Ser­vice In­ven­tory. Re­source in­ven­tory will be en­hanced to man­age hy­brid global net­work which com­prise PNFs and VNFs. The in­ter­faces to Re­source and Ser­vice In­ven­tory will be en­hanced to take feeds from NFV Or­ches­tra­tor so that it can up­date the global re­source in­ven­tory with the changes that are hap­pen­ing to VNFs.

Tra­di­tional re­source in­ven­tory is more or less static. Re­source In­ven­tory sys­tems will need to scale up for dy­namic be­hav­ior. Cur­rent re­source in­ven­tory can be ex­tended to model NFV log­i­cal en­ti­ties as ex­plained above and make it co-ex­ist with the ex­ist­ing phys­i­cal net­work func­tions. It is also im­por­tant to de­vise a smart mech­a­nism in the re­source and ser­vice in­ven­tory to have a global view of all net­work ser­vices which will span across the hy­brid net­work (VNF and PNF).

Or­ches­tra­tion ca­pa­bil­i­ties of ac­ti­va­tion sys­tem can be en­hanced to man­age the re­quired VNF or­ches­tra­tion as pre­scribed by ETSI. Or­ches­tra­tion in en­tirety will not be done by Ac­ti­va­tion sys­tem. It will be man­aged along with the re­source and ser­vice in­ven­tory sys­tem which will hold the spec­i­fi­ca­tions / cat­a­logs for VNF con­fig­u­ra­tion and man­age­ment.

Ac­ti­va­tion Sys­tem will in turn in­ter­act with re­spec­tive VNF man­agers to get the re­quired VNF ac­tiv­ity com­pleted. Thereby a com­bi­na­tion of Re­source & Ser­vice In­ven­tory and Ac­ti­va­tion ca­pa­bil­i­ties will sup­ple­ment VNF Or­ches­tra­tor. At the same time Re­source In­ven­tory and Ac­ti­va­tion sys­tem in its orig­i­nal ca­pac­ity will con­tinue to per­form tra­di­tional func­tions and man­age the PNFs. This ar­chi­tec­ture will en­able to man­age the re­quired hy­brid view which con­tains VNFs and PNFs.

One should not un­der­mine the need for high per­for­mance in­te­gra­tion be­tween Re­source In­ven­tory, Ac­ti­va­tion Sys­tem and VNF Man­ager in or­der to cope with swift changes that is bound to

hap­pen in the net­work. Dis­cov­ery and Rec­on­cil­i­a­tion: While tra­di­tional dis­cov­ery will con­tinue to func­tion the same way, there will also be a need to syn­chro­nize the changes in vir­tu­al­iza­tion layer with the re­source in­ven­tory. There will be a need to dis­cover and syn­chro­nize the VNFs onto Re­source In­ven­tory, if not up­dated by the stan­dard process for any rea­son. Syn­chro­niza­tion in this case is ex­pected to be largely au­to­matic. Changes hap­pen­ing to VM should also be syn­chro­nized. Tra­di­tional dis­cov­ery and rec­on­cil­i­a­tion tool will have to change. In this case en­tity dis­cov­ered and rec­on­ciled into re­source in-

ven­tory will be VNFs and its as­so­ci­ated at­tributes that is re­quired for Global Hy­brid In­ven­tory.

Fault and Per­for­mance Man­age

ment: Due to the ab­strac­tion brought in by vir­tu­al­iza­tion, VNFs or es­sen­tially a VM has to be mon­i­tored in a dif­fer­ent way. Dy­namic na­ture of VNFs will make it more com­pli­cated. VNFs will have dif­fer­ent mon­i­tor­ing needs. Though not ex­actly like mon­i­tory IT sys­tems, it will have to bring in that fla­vor.

One VNF can be de­ployed over mul­ti­ple Vir­tual Ma­chines (VMs) or on a sin­gle VM. This will call for lot more cor­re­la­tion to be done to en­sure ser­vice con­ti­nu­ity. If a VM is im­pacted, the cor­re­spond­ing

VNFs and the re­spec­tive net­work ser­vices should be iden­ti­fied to as­sess the im­pact. Global Re­source In­ven­tory will be of use in this sce­nario.

Ser­vice As­sur­ance & Data Ana

lyt­ics: As per ETSI de­sign, VNF Man­ager is ex­pected to mon­i­tor the VNFs un­der it and take nec­es­sary ac­tions in­clud­ing spawn­ing of a new VNF or scal­ing up an ex­ist­ing VNF based on de­mand. How­ever, it is al­ways de­bat­able that a sin­gle VNF Man­ager will not have a com­plete view of all the VNFs in the do­main and hence will not be ca­pa­ble of de­cid­ing on the de­mand. Hence prob­a­bly there is a need for an ex­ter­nal Ser­vice As­sur­ance sys­tems like fault and per­for­mance man­age sys­tem to man­age this ac­tiv­ity. In con­junc­tion with Data An­a­lyt­ics tool, should de­ter­mine the ex­act need for spawn­ing / scal­ing VNFs. Once de­ter­mined, the VNFs should be in­stan­ti­ated via Or­ches­tra­tor mod­ule men­tioned in “Re­source & Ser­vice In­ven­tory and Ac­ti­va­tion Sys­tem” sec­tion men­tioned above. VIM is also man­dated to pro­vide in­puts on ca­pac­ity plan­ning, mon­i­tor­ing and op­ti­miza­tion. Hence a de­mand man­age­ment is ex­pected to hap­pen in con­junc­tion with in­puts from data an­a­lyt­ics, VIM and VNF Man­agers. How­ever, the fi­nal de­ci­sion to scale up / down, in­stan­ti­ate, ter­mi­nate of a VNF shall be driven by pol­icy / busi­ness rules de­fined in Pol­icy Man­ager hosted by VNF Or­ches­tra­tor.

Con­cep­tual NFV Ar­chi­tec­ture

This sec­tion at­tempts to draw a con­cep­tual ar­chi­tec­ture in­clud­ing NFV com­po­nents work­ing in tan­dem with OSS com­po­nents. There is a pos­si­bil­ity to en­hance the Re­source & Ser­vice In­ven­tory to host NFV Cat­a­logues – the spec­i­fi­ca­tion re­quired to in­stan­ti­ate a VNF. It can also host the Net­work Ser­vice in­stances along with the VNF in­stances. Pol­icy Man­ager can be con­fig­ured with rules as be­low:

-Elas­tic­ity re­quired to scale up and scale down based on per­for­mance trends

-Ca­pac­ity man­age­ment rules based on busi­ness con­sid­er­a­tions,

-Com­pli­ance, SLA, thresh­olds based on cost of op­er­a­tion of im­ple­men­ta­tion of Net­work Ser­vice

Upon get­ting a re­quest for on­board­ing new Net­work Ser­vice, VNF-FG and/or VNF, Pol­icy Man­ager will do the val­i­da­tion and au­tho­riza­tion based on de­fined rules.

This ar­chi­tec­ture will en­able the Re­source & Ser­vice in­ven­tory to have a global view of all tra­di­tional net­work en­ti­ties along with NFV com­po­nents. It is im­por­tant to hold a map­ping of all VNF in­stances to its cor­re­spond­ing VMs. This will fa­cil­i­tate co-re­lat­ing ser­vices that are im­pacted in the event of Vir­tual in­fra­struc­ture fail­ures re­ported by ser­vice as­sur­ance ap­pli­ca­tions. Cre­ation, Ter­mi­na­tion and Scale up/down of a VNF can be man­aged us­ing the NFV Cat­a­logue by in­ter­act­ing with the ac­ti­va­tion sys­tem, which is ex­tended with or­ches­tra­tion ca­pa­bil­i­ties.

Ac­ti­va­tion sys­tem will take the re­quest from Re­source & Ser­vice In­ven­tory. Re­quest man­ager will route the re­quest to Or­ches­tra­tor mod­ule to man­age con­fig­u­ra­tion re­quest by in­ter­act­ing with VNF Man­ager with the help of NFV Car­tridges and Pol­icy Man­ager. Re­sponse is sent back by VNF Manger to Ac­ti­va­tion Sys­tem and in turn to Re­source & Ser­vice In­ven­tory to main­tain the state change. Thereby up­stream O/BSS sys­tem is in­formed about the net­work re­source changes.

Key fea­tures of this com­po­nent:

NFV Or­ches­tra­tor will be gov­erned by a set of poli­cies and busi­ness rules de­fined in ‘Pol­icy Man­ager’.

Takes feed from ‘NFV Ser­vice As­sur­ance and Data An­a­lyt­ics’ mod­ule and in con­junc­tion with well-de­fined poli­cies and NFV Cat­a­logue -

o Creates, scale up / scale down, ter­mi­nate log­i­cal in­stances of VNFs and Net­work Ser­vices in ‘Re­source and Ser­vice In­ven­tory’ .

o Stiches a log­i­cal view of net­work ser­vices of­fered.

Main­tains a ‘VNF to VM Map­ping’ to help cor­re­late ser­vice im­pact in the event of a fault be­ing dis­cov­ered in the Vir­tual In­fra­struc­ture.

Hav­ing cre­ated log­i­cal in­stances, NFV Or­ches­tra­tor shall or­ches­trate the cre­ation of NFV in­stances by pass­ing down the ac­ti­va­tion re­quest to VNF Man­agers for ac­tual cre­ation on vir­tual in­fra­struc­ture.

Main­tains and man­ages state tran­si­tion for log­i­cal VNF in­stances in ‘Re­source & Ser­vice In­ven­tory’

Ar­chi­tec­tural con­sid­er­a­tions are the fol­low­ing:

Real time OSS with hy­brid view of tra­di­tional net­work ob­jects and NFV ob­jects

Tra­di­tional and new gen OSS can co-ex­ist

Phase out and mi­gra­tion of tra­di­tional OSS will be easy

It is one of the ap­proaches to en­hance ex­ist­ing ‘Re­source & Ser­vice In­ven­tory’ and ‘Ac­ti­va­tion Sys­tem’ to in­cor­po­rate NFV Or­ches­tra­tor fea­tures. With this, one can quickly build a sin­gle repos­i­tory of hy­brid view of tra­di­tional net­work ob­jects and NFV ob­jects. While there are def­i­nite ben­e­fits of en­hanc­ing cur­rent ‘Re­source & Ser­vice In­ven­tory’ and ‘Ac­ti­va­tion Sys­tem’, there will be chal­lenges to scale up this plat­form to meet the per­for­mance re­quire­ments de­manded by NFV. Alternate op­tion is to build a sep­a­rate com­po­nent for ‘NFV Or­ches­tra­tor’ and in­te­grate with tra­di­tional ‘Re­source & Ser­vice In­ven­tory’ and ‘Ac­ti­va­tion Sys­tem’, keep­ing in mind the im­por­tance of hy­brid view of PNFs and VNFs to be catered in ei­ther of the sys­tems.

Fig­ure 2 NFV Con­cep­tual Ar­chi­tec­ture and Im­pact on OSS

Fig­ure 1 NFV – Con­cep­tual Ar­chi­tec­ture

(The au­thor, Ajay Pat­ter Veetil, has over 17 years of ex­pe­ri­ence in the IT in­dus­try, and has been as­so­ci­ated with Wipro Tech­nolo­gies for 14 years now. He has been through var­i­ous roles like De­vel­oper, Sys­tem Ar­chi­tect, and So­lu­tion Ar­chi­tect and has...

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.