 I have the pleasure to give you some information about Telecom Deutschland's approach to network function virtualization. What we are doing, what we are planning to do, what we are thinking about, and that's about my presentation and in between I will show you a short movie which we made to explain the network function virtualization, to explain the rational behind it. So, lean back and enjoy the show. What I want to do, I'll give a short introduction about NFV. NFV more than a hype? Is it a question? Or is it a statement? I will give some words about that. And then I'll talk about the network function virtualization as we are currently doing, planning it within Telecom Deutschland. Why we want to do it, what we think about and how we plan to do it. And later on at the end of my presentation I will raise some questions about open source pros and cons looking from a network operator's point of view on that stuff. Open source in general and later on also open stack in special. And as Christmas becomes nearer and nearer I will have a wish list with me about some topics I'd like to raise and I'd like to think the open stack community about. So, just some words to my person. My name is Stefan Häuser, Stephen or Stefan. However, you like to pronounce it. I am program manager for the virtualization program within the German branch of the technology part of Deutsche Telekom. And we started our program last year in summer. The management decided, yeah, it's quite an interesting thing. Network function virtualization. Let's think about it. Let's think about it in some more depth. And so we put a lot of experts together. Some of them I'm glad to have with me. So I'm not the techie guy. If you have later on some technical questions I may have to pass them to my experts. Thanks guys that you are here with me. And I hope you support me. That's it for that, yeah. Let me just have a look on my notes. Fine. So, network function virtualization. More than a hype? What do you think? I just did a search. What do you think? How many results did I get? What do you believe? I just put NFV in the mask. What do you think? How many results? Pardon? Ten thousands? I'd like to hear some more. Okay. 1.3 million. But I have to admit, it took me a lot of work to convince my browser not to show the Norddeutscher Fußballverband. The Nathan German Soccer Association at the first results. So I had to do a lot of work to get these results directly on the first page. So there may be a lot of unrelated topics or let's say topics not related to network function virtualization with that. But there is anyhow, if it's 1.3 million or if it's only 1.2 or 1.1 million, there's a lot of things going on on network function virtualization. So my statement is it's more than a hype. We left, if you think about the Gardner hype cycle, we left this high peak. But we still have a long way to go to have it really in the network and to have it work in the network, in a carrier-grade network, I have to say. So network function virtualization is of course one innovation driver for telco providers like Deutsche Telekom. So far that movie, so parts of my questions are already answered, but I want to emphasize just two points why we are doing it. The one is scaling. As mentioned in the movie before, to base it on a standard hardware, not on a vendor-specific hardware, not to have the silos, but to distribute it over a lot of other unused servers can help you to use your resources more efficiently. So just to switch off what you don't need or at least have in a low power mode running and later on, if you need more of your resources, you just fire up these resources and use them. It's just shown here for two virtual network functions, VNF1 and VNF2, but if you have more of them, the idea behind is that you will have the peaks, hopefully not at the same time for all of your virtual network functions, but who have distributed peaks. As mentioned in the movie, for the example the SMS, just give you a figure. At the 31st of December last year, starting at 11 p.m. until the 1st of January, 2 a.m. there were sent about 40 million SMS alone inside the network of Deutsche Telekom. I'm not talking about SMS which were sent to other providers or which were then from other providers into the network of Deutsche Telekom. Just within the network of Deutsche Telekom, within three hours, 40 million SMS. So you would need, and you need as we currently have, a lot of resources unused most of the year. And the idea behind the network function virtualization is to have these unused resources used by other network functions and then use their resources which they don't need because usually at Sylvester at midnight most of people are having their Sylvester party or New Year's Eve party and not working though you may use these resources just for kind of that services. So scaling and better usage of resources is one thing and the other thing as also mentioned is time to market. To decouple the hardware cycle and the software cycle. So currently we just have minor releases of new software based on our hardware we have but if you have a major release then in most cases you also have to change the hardware or if you have to change the hardware you also have to change the software. And therefore a decoupling of hardware and software as shown in the lower figure that's one possibility, one chance of network function virtualization we want to use with that. So scaling and time to market or decoupling of hardware and software and that's a rational that are the two main drivers besides others which were mentioned before operational issues, energy consumption and things like that. Yes the whole bunch that's the rational behind of going into such and of course for a traditional network provider new field. And what we think about as we talk about network functions we have several different network functions. We have let's say to give a rough cluster two kinds of functions we have the one who are network and data agnostic and a lot of power in terms of bits per seconds which have to be distributed to a customer. These functions will be distributed over our network near the customer. That's what we call a talk or what we call front-end data center or FTC. These FTCs will be distributed around Germany several locations currently thinking about 20 locations where we will have that but no final decision so far and this will be located as shown here in a distributed cloud. So we are not talking about a distinct data center we are talking about the cloud the FTC cloud and the applications shall be cloud aware. The redundancy will be handled by the application itself meaning in the front-end data center we don't have any backup redundancy concepts or things like that. The application is responsible to ensure that and on the other hand we have the so-called back-end data center which will be only a smaller number currently talking about three and there we will have the stateful applications the applications needing databases, needing a lot of computing power and things like that and that will be located into one of our back-end data centers and there we will have of course high availability concepts but again if the application needs a higher availability then can be provided by the infrastructure itself then the application has to ensure that there is a high availability of this application that means in the back-end data center case we may install an application in more than one location and to have the combination of both locations to reach an availability of 99.999 whatever percent more than the infrastructure itself can provide and for the FTC case we say okay the application itself has to ensure the interworking and the availability meaning if there is one FTC let's say by flood or by a fire out of order another FTC can be taking over the work and the load of the FTC which is not or which is unusable for that time so the application itself the infrastructure on the one hand shall support that and the application on the other hand has to make use of it I think this picture is well known I don't have to explain it just to emphasize the hardware and the virtualization layer and the NFV the manual block on this side that's the data center overview as given by Etsy NFV our approach looks a little bit different okay I step out of the pictures just give me a sign when you're done but the slides will be uploaded so there is no need to take a picture except my face is not uploaded okay so the main difference is here of course you have noticed the open stack here but the main difference is there and where the Etsy picture says okay we have the orchestrator doing the overall stuff we have the VNF managers and we have the infrastructure manager and the VNF managers may have access to the infrastructure managers we say no way the VNF manager must not no should not, no shall not, must not have access, direct access on the what we call infrastructure orchestration the rationale behind this if you have even in our case where we are talking about a private cloud and not a public cloud if we have different product owners different providers of your network function within a huge company like Deutsche Telecom you will have different interests you will have different policies for scaling of those applications and if you don't get a single and unique few on your infrastructure you will be lost you don't know in a case of scaling what's really available everybody scales out but what's happening in case of conflict who will solve this conflict if they have the direct access therefore we say okay we bundle VNF manager and application orchestration we have them and only via the orchestration there is an access to the infrastructure so we have one point of truth where we know about what's happening here and that's the main difference besides some other minor points but that's the main difference regarding our well-known Etsy picture though that's what we plan to do and open source, open stack some remarks from an operator's point of view there are lots of discussions or had been lots of discussions within our company shall we use an open source software or should we stay with the well-known software provided by our vendors should we stay with a silo approach or shall we move to the more open or hopefully totally open approach using network function virtualization I just took them pros and cons of course, positive from our perspective is we have only a limited vendor dependency community-driven development and enhancement and of course fast innovation cycles and there are a lot more but also from our point of view there are some contrasts, there are the negative points it's an unclear feature roadmap when, at which point in time will what feature be available uncertain stability is it really stable what's now provided with that release will it be stable will it be the same two or three releases from now the at least currently lacking maturity of the software can we use it for a carrier-grade network can we use it for carrier-grade requirements and therefore at least from our perspective the carrier-grade version is currently not available and again on the con side there are a lot more topics we had in our discussions nevertheless we decided okay let's try open source let's see it's promising and let's see how it works will it work for us or not we will see we'll do the one or the other tests we are doing some proof of concept on different areas in different locations with different focus but we are trying and that leads me to my wish list for Christmas as I said is coming nearer so there are some topics where we think there is work to be done one thing is the upgrade new release short release cycles as I said it's positive in principle fast innovation cycles though if there is something which doesn't work as expected it's very soon that you have a working version of it that's great but looking on an operator's business when I look the old analog telephone how long is it in our network look at the ISDN how long is it in the network so we are talking about long innovation and business investment cycles you don't replace for 40, 50, 60 million customers you don't just replace every year the technology in your network your business case wouldn't come out so that's one problem and at least the experience we make currently you have to do a lot of configuration work so it's not just installing a new software and everything runs you have to check the configuration does it work and at least currently the different maturity of the different OpenStack projects makes it hard to estimate the maturity of the overall software and how it can be used within our network the APIs, stable APIs are imperative as I said before if we install a new version it should work as before and if there are too many changes we have to adapt a lot of stuff within our network and if we have it's currently not the case but if we are talking about a productive system and we have several VNFs hopefully in future several hundred VNFs within our network we can't adapt them all and we can't spend the effort to do regression tests with all of them that would be several millions of personal days and therefore several millions of euros which we have to spend and of course that's not worth the effort again it will kill any business case another thing is KPIs and SLAs currently when buying a function as a silo we can define in the contract some SLAs at the let's say customer side throughput or whatever there will be but if we just buy the software we have to ensure KPIs at the upper end of our data center let's say at the hypervisor level and on this KPIs we have to provide the VNF provider has to rely on in order to guarantee his SLAs and if there's something going wrong the finger pointing will start your software doesn't work your platform doesn't work and then we start again the discussion who is responsible for this fault who is responsible that let's say one million customer couldn't start a phone call or couldn't surf in the web or couldn't watch a Champions League final game or whatever so that's another thing to think about and how will this be influenced if there is a new release hopefully it gets better but who guarantees it gets better maybe they're the one or the other thing it becomes worse no one knows and again here as mentioned before the error handling a breakup of silos means breakup of responsibilities and monitoring tools and measures also have to be provided in order to see where and in whose responsibility an error comes up as mentioned as well in the film and later on multi-region is a topic for us so we don't want to talk about 20 odd something data centers we talk about an infrastructure cloud and we want to provide our application within this infrastructure cloud maybe it's necessary to provide an application especially in Munich and not in Hamburg so or let's say in Munich and in Nuremberg and where else in the southern part of Germany but not in the northern part of Germany then we have to have measures to define the region where it is deployed and of course if we have the redundancy case then in another region the data center, the NFV or the VNF has to take over in case of failure in another data center so multi-region or spatial redundancy or however you will call it the need for us orchestration of course the whole stuff must be orchestrated and in best case the operational guys have just one tool, one monitor to look at one screen to type and to handle the whole stuff and not for each region a different tool a different log in and different it would become a nightmare so that's again one thing security, of course our security guys are very strict and if they don't approve we won't go into production and therefore of course we need from the application side security measures to avoid problems, to avoid security leaks but also we need at least from our point also from the open stack side some intrinsic security topics and especially when talking about running more than one virtual network function on one bare metal then you have to ensure that the virtual network function A does not corrupt the virtual function B or does something else with the virtual function B which is not allowed so the whole stuff becomes at least from our point a very very severe point and of course quality assurance is necessary including also contributions from third party vendors of course and should ensure the stability of APIs and also the external interfaces so that's my visualist nevertheless you may say hey he asks for a lot of things are they willing to contribute I have to say yes we are willing to contribute we have some people maybe not as much as we would like within the open stack community but we already have several contributors within the open stack community especially in the QA section I'm quite sure you know the statistics just filtered the Deutsche Telekom people so we are willing to contribute we are contributing we are willing to contribute I hope I can convince my management that we can extend the manpower for contributing within open stack to bring this project forward and to make it a helpful project for Deutsche Telekom thank you for your attention so far are there any questions would you just take the mic although the other people at the back can hear you hi Rod Randall from Cirrus Capital as you look at the transition to NFV and the re-architecture of your network where would you place priorities on the financial benefits would it be in savings of cost from the infrastructure do you expect a different pricing of the network functions or do you expect it to be in the agility in the introduction of new services to the communities or something else that's a good question there are several screws to drive in order to make it successful yes of course one is the cost and there probably be as our first calculations show probably be the operational cost a driver of course agility is a topic that's introducing such a kind of technology introducing that decoupling of hardware and software and become more agile is also a transformation process within the organization and it's a mind-change so we have the technology challenge and we also have the mind-change challenge and therefore I think the first step is of course the operational and later on coming together with the mind-change within the organization will be the agility okay all right thank you you're welcome so there was another question in the first row okay thank you very good presentation now Hippolodini from HP there was somebody from Orange earlier in the week who said that you know definitely it's a technical challenge but it's also a very strong cultural change you know in the operators and he said that you know in Orange it would take you know at least six years or maybe more like ten years what is your take on that it's again a good question so the let me give an answer like that the we don't have currently a final roadmap though I can't say let's say six years from today we will have all our network function virtualized and nevertheless we will of course have an approach using the life cycle of our network functions otherwise we will get some problems with our financial guys if you just replace a system you installed a year ago just replace by a virtual system they will say no way so we will have our release cycles which are between three and five years so depending on the maturity of the underlying software it will take at least five years till we have substituted our network functions our siloed network functions by virtual network functions so I think the five to six year you mentioned which was talked about the calling from Orange yes that's reasonable my name is Rao Michelinia I'm from the C3DNA is a startup one of the things that I come from telecom background AT&T Bell Labs and so on so forth so one of the things that telecom is good at is really telecom great service and that was made possible by separation of the data path and the control path so the signaling layer and so on so forth so in this architecture in the data center you do not have a service control plane the management cannot be done without a service control plane it's the same time infrastructure if you want to provide an infrastructure to your service control plane you have to have an infrastructure control plane that the service control plane can actually negotiate saying hey here is my resource requirements you can provide however you provide your resources and so on so forth so in the current data center architecture there is a piece that is missing that used to be the telecom industry and the telecom great trust came from the signaling layer as soon as you pick up the phone there were resources the profile of the the application essentially told exactly what it needed as soon as you dialed the URL the profile of the other dialed number told you what the network has to provide and there was a lot of stuff that was happening so that architecture is missing in the data center with a single data path everything is running around and so to me all of the efforts are not going to resolve the complexity because you are going to put managers of managers and managers of managers so the orchestration is going to be extremely complex so have you thought about separating actually the infrastructure control plane and the service control plane and having a signaling mechanism to negotiate maybe I'm wrong that's a good point completely but what you were talking about is within the network function so the network function itself whether it's a phone service or whether it's an SMS service of course has to ensure the signaling to be working but that has nothing to do with the infrastructure I need within the data center to get this network function up and running but nevertheless that's what our application orchestrator what that block I showed here is doing that block is responsible for allowing a network function to use a resource or not to providing the resource or to take away the resource so there of course is the signaling and that via that way there is information to the EMS or the let's say EMS and WNF manager within the EMS they are talking about they are negotiating if you like with each other and then the application orchestrator as a single point of truth will provide an infrastructure and will of course also take away if it's not used anymore yes of course right but that's that's a missing piece of course and therefore I said in my bushlist orchestration is one of the things I'd like to see Thank you Mr. Heuser, Daniel Goder from Ericsson was a very good presentation on NFV are you planning to kind of merge this project with the things which are going on in the IT cloud and the public cloud so some of the operators have chosen to provide only one infrastructure for public IT and telco is that going to I don't know be a decision later on or is that going to be an infrastructure only for NFV for the current point in time it's focused on the NFV because it's focused on our business regarding the network or our network centric business as I may say maybe there will be later on another step of evolution to bring this together but not decided for today Thank you Yes please I'm Harshad Danna from Ericsson again cloud manager project in Ericsson so it's very good that you mentioned that there is a single point of truth of control for the infrastructure resources and that's the view that we have also taken but seems like it is moving in the direction of allowing VNF managers to directly go into infrastructure orchestration that really puts vendors like us into a dilemma how to go about it with any comments Not only vendors like you but also providers like us we also have the discussions with our vendors and have to convince them no you're not allowed to do with the infrastructure what you like and you're only allowed to do what we like and that's really a crucial point from our point of view I don't want to say Etsy didn't think carefully enough about there may be other reasons or there are other reasons behind that but nevertheless that's our approach and that's our approach we are fighting for yeah of course we're just regarding the agriculture picture we just cut this connection maybe yes of course maybe we will have of course let's say that the VNF manager may listen that's okay but he may not control or must not control to make it clear okay there's another question at the end it's very quick NEC Europe from the OP NFV project website I think that Deutsche Telekom has not joined the project there are a lot a lot more operators involved why haven't Deutsche Telekom joined or is it a political reason behind or technical are you joining later and not decided for today nevertheless there are a lot of initiatives and groups popping up like mushrooms and the problem is the resources you need to have the resources and you need to ensure that the resources of one company within all those groups provide the same opinion and the same statements and so far no decision if we also participate in the open NFV group it's as I said we have to discuss how far we will go into that topic thanks the question I get from your business unit people in fact on the consumer SMB and enterprise side the we all understand the agility the cost reduction and so on but your teams are really concerned about will it make more money will it make more revenue are you considering scenario use cases where you could create innovation paths and what it means for you yes that's that point to be more flexible to be more active or even to admit when one of our competitors is faster than we are to be more reactive so that's of course a point where we think yeah we can do that but as I said before it needs also a mind change within the organization and therefore it's nothing I see in the let's say short future but at least midterm yes of course yeah between the infrastructure orchestration and the vnf manager I wanted to understand your rationale behind that I don't want to make it a design discussion but how do you envision changes in the infrastructure or the vnf manager having to make an autoscale decision and thereby requesting some virtual resources etc. scenarios and how do you handle those if you bypass that connection okay the short answer is that way the rationale behind as I said if you're talking about let's say currently we just checked part of our organization units came about 450, 480 services so if you virtualize all of them and all of the 400 or 500 or maybe 800 or even 100 services are talking directly to your infrastructure without one single point of truth you will have chaos and virtualized chaos as one of our manager says virtualized chaos is still chaos even more complex so that's the point behind it because if everyone may talk may ask for resources may block resources without one referee over it we may run into the problem that we still have lots of unused resources they are blocked by one VNF manager on what decision ever and are not available for other VNFs so that's the point behind it we need this control unit, this referee and therefore we say our single point of truth hit this up there and if a VNF requests more resources it has to be done by the administration via this single point of truth which knows which resources are available where are these resources available does the policy of the VNF allow that let's say resources in Hamburg in another part of Germany are required and does the application allow that these resources will be in the southern part in Munich provided all of our applications will allow if you need in Hamburg more resources that in Munich these resources are provided so and therefore we said just that way and not directly okay then I'm over my time thank you for your attendance thank you for your questions