 Good afternoon everyone. Welcome to bringing dynamic service chaining to the telco cloud with new age and cloud band I'm Scott Drennan. I product manager at new age and my cohort as a copar is a cloud band architect and What we're going to be talking about is some of the components involved in an NFV solution How open stack is relevant to that and how open stack Can be extended with the additional capabilities To provide a More complete solution as well as what some of the work items are around that so starting from the always always exciting Etsy reference architecture I you've got OSS BSS and NFV orchestrator at the top with various components. You've got I A VNF manager With VNF's talking over NFVI With a virtualized infrastructure manager, so your network functions are going to include a Bunch of traditional telco Network functions like IMS MME S&P gateway, but also more traditional IT functions such as firewalls IMS or IMS IPS IDS and And things like that. You also have a network network management function, which I didn't mention and Then the the VNF manager that's providing a Lifecycle management elasticity I and then at the top you've got the orchestration layer that provides the service management and some of the SDN SDN management components So where's open stack in all of this open stack sits down at the bottom I doing all of the hard work and all the heavy lifting and Makes I Makes the whole thing work without say without open stack. We we really wouldn't say it wouldn't be anywhere and Admittedly there are other options for deploying NFV architectures, but From what we're seeing open stack is really becoming the standard infrastructure for NFVI and That's a good thing because it it provides a level of commonality and Stability that you can build interesting things on top of so You've got a bunch of best of breed capabilities that come with open stack Things like multi hypervisor orchestration and including things that are not hypervisors such as ironic You've got multi region single sign-on when you're extending Your system across multiple data centers and to have multiple geographies I IPAM and pluggable IPAM integration back-end storage VM templating All of these things say are very important from an infrastructure perspective but there's a bunch of stuff that open stack doesn't do and Probably won't do and in my opinion at least shouldn't do because open stack is already trying to do many many things and Well, it's fun to contemplate taking over the world. I it's a The more things you do the harder it is to do things well, so there are some additional components outside of open stack That say some of which We're providing as part as part of the Nokia solution and those are some of the things we're going to talk about today so NFV orchestration is a key component a Robust high-performance networking Open stack networking is continuing to improve. It's improved release over release For as long as I've been involved, but in terms of the requirements for NFV It's not there yet and the the bar is is ever rising as far as what What the networking requirements are so we'll see we'll see how that turns out It's also kind of important to be able to connect out of your NFV cloud if you're doing network function virtualization with with Nothing to talk to it's it's not really very interesting And then also a portal or a marketplace to expose these These functions out to the broader internal or external customer community So what does this look like from? From a workflow perspective You've got customers Those may be internal customers those may be external customers. You may be doing resale But say they're making a request for a VNF service of some sort or other and The marketplace and VNF catalog really ends up being being custom per Per deployment. It's not something that you can really general size The same way as you can to a large extent with some of the other components And then the marketplace needs to provide a Call into the NFV orchestrator Requesting whatever I the Services that has been has been requested. So NFBO needs to provide a simple abstracted a templated model to make it easy to deploy a Marketplace and to simplify what the marketplace looks like from there I NFBO is Calling into various components in our case I it's Calling into OpenStack and calling into Nuage And the reason that we're not doing all of this through OpenStack is To provide some more expansive Networking capabilities And there's work in OpenStack to expose APIs and there are extensions, but It's still at least in the near term easier to make those calls calls directly. So From a from the marketplace, you've also got cases where you've got complex VNF's Where you've got potentially a separate VNF manager those would be Cases like a mobile gateway or an IMS and in that case they may need each their individual Dedicated VNF managers or that may end up being a plug-in from the NFBO that depends on the use case and Either way you end up launching launching VNF's and configuring them That results in OpenStack deploying AVM, many VMs A network, many networks lots of lots of complex configuration and One of the key use cases for NFV is you want to be able to take all of your VNF's Deploy them in a relatively generic fashion and Say hook them together in in various different different flows and Aje is going to talk more about that a little bit later on but say That allows for simpler templates on the VNF side and More composability as far as the as far as the configuration goes and then Obviously you do need to be able to connect that out into the broader network and One of the things that is critical from a Configuration perspective is you you want to make that as programmable as everything else because you've got lots of different VRFs Out in your broader network, you've got the internet and you want to be able to Hook those those pieces together in a logical fashion And then you want to be able to scale out to multiple multiple VNF's in that service chain so What do you need from an SDN for service chaining? Like I said previously, you need robust networking You need to be able to scale to potentially very large numbers of VNF's Today those numbers are in the Hundreds thousands But the modeling that say the architects who are building this stuff are doing are showing that you're looking at tens of thousands especially as you Move to VNF's with more microservice style architectures you end up breaking that out into smaller and smaller Components and there are more and more of them you obviously need high performance and throughput and you need a small packet size capabilities and To do that the tools we have today are I networking I based on either dpdk or SRI ove and that depends on the VNF and you do want to be able to Cover off both of those Now from a chaining perspective there are a bunch of different ways to Attach things together You can Deploy your VNF's or your VNF components and Do hop-by-hop inspection as each packet goes in and out of the VNF I Look at the packet header. I do the inspection and tell it where to go The next time and generally you would aggregate that up into flows so that you're not doing the As much of a look up each time You can also approach this from a routing perspective and Deploy Each each VNF in a separate VRF And connect them together with the with routing I that means you're deploying an awful lot of VRF's in your data center but it means that As long as you don't need I Packets with the same destination to go through different service chains that can be a simpler simpler topology and The holy grail of all of this I is service function chaining using NSH and I'm not going to get into what NSH is or Or how it works. It's a way of putting An additional header on your packet that is used by by the SDN to Steer traffic without having to do all of the lookups each time and there are many many Drafts in IETF talking about all sorts of different things you can do with NSH I Think in the near term what you're going to see is a bunch of things using steering I Proxy information going to going to VNF's is is going to take more time to standardize but that's that's my take but the from a functionality perspective you need to be able to I take all of this abstract it away make it easy and Provide the support that that VNF's need so Now handing it over to Ajay. He's going to talk in more detail about NFVO for service chaining and how that I ties into configuring service chains in the In the SDN layer Thanks, Scott. Can you hear me? Hi, I'm a Jacob or I am the Claude Brunner architect has called introduced me so Now with the basics of SDN behind what Scott has said NFVO is basically we are using NFVO for Provisioning networks and also to basically to do the service chaining is one of the use cases Simplify provisioning using service chain templates and VNF scaling in in the process NFVO which is network function virtualization orchestrator We have a product in Nokia, which is called as Claude Brunner director And that's basically use this lot of open stack components like mistral morano and heat and With the combination of these components and and no arch we are able to say Do a service orchestration and also do the SDN configuration via by a new watch So the next few slides will take you over to the modeling. How do you model network services in Claude Brunner director? And then little animation on how basically we will And realized in SDN use case using new watch Okay, so network service Descriptor is basically the language which the cloud network direct See the cloud manager director understands So it's it's a collection of working network functions which are interlinked together to form a graph and In the HC world this needs to be modeled and and in CBND, which is Claude Brunner director. We have Gone in for Tosca as the modeling language Tosca is basically a domain specific language which is chosen for for nsd and It has it's a series of say it has a hierarchical look on services and templates in relationships so network service descriptor is modeled as a service template and This service template is comprised of different node templates and relationship templates So every virtual network function of VNF is modeled as a node template and between the VNF There are relationships established and those are primarily modeled as the relation templates in Tosca you can have node types define custom node types and So that customers custom attributes and properties can be extended from a base node types so there are node types which which are done for for VNF's which you want to have proprietary extensions to that and Tosca is primarily Say decoupled from the underlying VNFM in NFEI. It's a modeling language which is decoupled from the NFEI and VNFM and You can attach policy in process and do advanced LCM operations From if Tosca is used basically you can generate an entity graph out of a Tosca model and execute the entity graph which will which will basically Provide the LCM of the entire network service LCM basically lifecycle management And it's open driven by the community. So in Nokia We have contributed back to the Tosca community as well. So Tosca is basically one of the DSL which is used in In cloud management director Yeah, so we document Tosca in YAML format. So it's easy to read human readable format which is which is used to document Tosca and We have used simple profile for NFV for Tosca and extended it to define our own node templates and relation templates and the virtual links and some of the HCR constructs like the virtual links connection points VNF forwarding graphs and Network function forwarding parts are modeled in Tosca as node templates Okay, this is what this is one one picture which we which basically shows We have the physical network functions on the right hand on the right and the left side of the picture which are basically having say three virtual network functions VNFA, B and C and The the little boxes circles blue circles who are there which which are basically the connection points which represents Interfaces of the virtual network function and between Between the VNFs and the connection points the the brown link which goes there which is called the virtual link So these are terminology terminology which are used in HC virtual link is basically a logical connection between one or more VNFs and They represent basically a VLAN or a VXLan when it's realized when we instantiate a network service and realize it connection point it's an interface on a VNF PNF which connects to the virtual link and it can be realized as a V port VNIC or a physical port and VNF forwarding graph defines traffic flows between the between the VNFs in a network service So the dotted line which are there Basically form a network function path and it's which part of a VNF forwarding graph and yeah now I will take you to a Through a small animation on the use case So here we have different elements of Etsy the NFVO, which is cloudbed network director the SDN manager Which is Nuage the VNF M and then so basically When you want to deploy a network service when operated charge deploy a network service The network service evaluated the data center is identified on which the network service has to be deployed an open check data center basically and the tenants for the VNF the VNF placement where to place the VNF based on the VNF characteristics is identified and The external connection points for VNF NSD are evaluated whether they they fit to be deployed in a particular data center This is done by the NFVO Sorry Okay, then invoke the SDN manager So once the once the initial validations are done the external virtual links Which I showed before in the previous slide the links between the two VNFs needs to be realized and those external virtual links are basically realized using the SDN manager in this case Nuage, so NFVO makes Nuage call and Create these virtual links Then the SDN manager based in the data center network topology information Decides to create reuse a tenant or edge router using the rest in SDN control interface So it can be done by a neutron and it can also be done by Nuage So for service training use case we do it by By a nuage and for normal network creation. It is done by a neutron Then connect an edge router to a data center. So the edge router is connected to the data center edge router as needed Then create virtual links, Elan and connect to a 10 edge router So the virtual links are created and these are connected to the edge gateway of edge router over here once the external virtual links are Are created then the then the network NFV orchestrator is notified so that it can update its own internal database about this about the external connection external links and This is what I'm saying so Once the external links are virtual links are in place then the the deployment of the VNF starts so NFV orchestrator will call the relevant VNF managers to and passes To pass the VNF details to be instantiated along with the external Virtual links so that VNF manager can use these virtual links to establish continuity between the VNFs and then Now we move on to the VNF manager which evaluates the VNF descriptor VNF descriptor is like a network descriptor a meta data for a VNF It identifies the VM VM needs the internal connection points and internal networks so it identifies this the needs and then Invokes the VIM API so in case in this case open-stack APIs are invoked to say create a server and then create the virtual links virtual links between the VNFs Then the VNF is basically a collection of VMs and you need internal connections between the VM this the to create internal links between the virtual machines responsibility of the VNF manager and VNF manager does it creates virtual links between the the VMs basically and And then create external connection points and connect external connection points external virtual link So once the internal links are created The the external connection points of VNF are Connected using the external virtual link which is passed from the orchestrator towards the VNF manager okay, and notify Network NFVU about the required VNF so the last step so so that the bookkeeping can be done on the on the orchestrator side Yeah, then the orchestrator basically updates his internal Internal database about the virtual links in the state of the network service and also can notify in the umbrella applications on top of it So the so here I here I've shown an example of open-stack data center, which is used to simulate the entire network service Okay, okay, so with that I will Take you through a very small Animation on how how we are using no watch now and neutron together to achieve the service chain So we have Cloud Minit of director which which which receives What do you say? a network service descriptor as a Tosca model and The virtual links connection points the virtual VNF of G are all modeled in Tosca Then we have an open in the open stack as an ml2 plug-in neutron VSD is plugged in and As Scott told for some advanced use case like service training We we basically create the the networks and the subnet in the in no watch using the the VSD the VSP API's and Once that Once basically the the network and subnets are created in the in no watch then they are mapped to the neutron network so They're mapped and we use the the rest API is provided by neutron and also the also no watch to basically map these subnets to the to the new watch subnets and After all is this is done. This is the basic plumbing work of interconnecting the VNF's is Over that means if there are in network service if there are multiple VNF's the interconnection between the VNF's been done now the next step is to do a service training one on them and In order to do service training In no watch there is there are needs to create forward and deduction policies Per VNF Connection point in virtual link these forward forward and deduction policies are created using the again the no watch VSD API's and Once they are done then the basically the service Service chain between the VNF's that is will be will be basically be established. So this is a small animation of how we try to achieve service training using no watch and neutron and Eat the sorry for this, okay, so that was One brief animation on how we use neutron in the in the no watch extensions Then the last slide basically is on and this is the service chain what we achieve so ultimately there are chain of VNF's and the the arrow show the how the packet flows and whenever whenever a packet is destined for a For an destination then the no watch intercepts the package applies forwarding policy on that and and then Roots it via the by the different VNF's So conclusion open stack is Enhanced by NF you and SDN solutions. So we use open stack for our as NFEI layer And use basically no watch as an as an ML 2 plug-in for open stack to achieve our SDN solutions Cloud CBND, which is cloud been root director is a NFEI orchestrator which orchestrated network service it basically Deploys VNF using underlying VNF manager. It uses SD SDN from no watch and also neutron to realize the external and internal internal networking and establish an entrant continuity and No watch VSP provides and SDN for NFEI and it's and it's it's it's already proven in the market So that's any questions on this good behavior and coming to coming to the mic No keep presenting different solutions in different places I saw no keep presenting they will go with tacker one place No keep presenting saying that they will follow open source manner where the core is juju now We have this cloud band director reminding red hat director. So which one is it really going to be realistic? Thank you So a good question from Ericsson. Thank you And my answer to that is just as with anywhere else in the NFB space there are lots of different people doing lots of different things and I Would I would hesitate to predict the future? so I And I think if you look at any vendor in the NFB space There is there is no one Consistent answer. There are there are many answers for many different use cases and until they I don't think we're gonna see convergence in NFB Any time anytime soon there's gonna be lots of different things happening in the call flow What at what point do you actually provision the v&f's themselves or is that out of scope? of the process here in the call flow when When we basically create the external virtual links using the SDM controller is when we start deploying the the v&f's and calling the right element vnf managers because The vnf the vnf's will need external connection External virtual links to establish end-to-end continuity. So after the the External virtual links are provisioned into the system and then is when the deployment of the vnf starts. Yes, so NFB orchestrator is basically Basically talk can talk to multiple vnf managers from different vendors it's multi vendor multi vendor and the HC specifies an interface between the Orchestrator and the vnf manager which is called or vnfm interface and there are a set of API's on which you can deploy a vnf Terminate heal or do whatever so that those that's what we basically rely on in order to deploy and Nokia supplies some of those and we partner with with people to supply others, but again the Ecosystem is quite diverse at this point a question about your workflow My understanding is you use a template to find the interface and the connections in between them So my question is about the templates yourself. Do you provide a tool to actually generate a template? So it's actually a manual process So we follow Tosca now to model the templates There is we are in the process of say building a Tosca editor wherein you can basically build this Build this network service descriptors using the Tosca editor as a drag-and-drop and which can generate a Tosca template as an output Right now it is How do you handle the failover and monitoring of the vnf and the service chains? So Two things I well, there's two pieces of this one is at the SDN layer monitoring that vnfs are alive and That I and then taking action at the at the network layer But then there's also Cases where it may look alive from a network perspective And not be so that becomes the responsibility of the vnf manager any other questions platform aware, let's say I want for a network service on a dbdk enabled node is your platform has the capability to talk to the nodes to find out which Basically, do you have the intelligence to to do the placement? So that becomes a question more for more for Nova I and It's a it's a question of Availability zones in Nova I To to group things. So that's that's a place where open stack actually gives you Give gives you the tools to To construct your your compute resources and group them separately Yeah, and just to add from the orchestrator. We have We have a policy-driven Approach to place the vnfs so you can basically define policies and in that policies you can have different rules defined Based on a vnf characteristics like CPU pinning whatever and based on that the the vnf placement distance are taken Where's this policy sitting it's policy sitting in the inside in the orchestrator, okay? It's in the orchestrator, and it makes Yeah Thank you. All right. Thank you all very much