 Hello, everyone. Thank you for coming. Ni hao, si siu. And that about exhausts my vocabulary here, unfortunately. So I'm Mark Barel. I work for VMware and I've been involved in the Etsy OSM project for a little while and partially helping out with the VNF onboarding task force. So I'm going to be taking you through a little bit of a journey on what it means to onboard a VNF and what some of what Etsy and the VNF onboarding task force is working on. The example that I'm actually going to be using is a pretty telco specific one. It is an EPC open source EPC software called Next EPC. And because I might not, you know, not everybody may be familiar with what cellular data control plane and data plane looks like, I will just give a little bit of a brief explanation of, you know, sort of what we're doing. I'm going to take a little journey in walking through the entire deployment, you know, from I've got this piece of software to how do I get that up and running and how do I model it. So first of all, and I'm going to go through this fairly quickly because the last thing I want to do is read this all for you. But OSM was founded, it's part of under Etsy, basically, and they've defined a whole bunch of specifications and everything around NFV, VIM, NFVI and more acronyms than you could possibly imagine. And the the entire idea is to, you know, to form those standards and to use OSM to provide an implementation of those standards. So the main benefits of OSM is that their information model is based upon standard specs, the Etsy Sol 001 and 006, which I'll give the URLs for those at the end of the slide deck as well. So so it's a full life cycle, automating the network functions, whether they're virtual or physical. And yes, they're still working on defining containerized network functions. So there is no spack out on that yet. Network services and network slices. So for this, we're primarily concentrating on network services as part of a VNF. So it does go through the entire life cycle. Initial deployment, which you can call day zero. And that is about, you know, just laying the software down, getting the base operating system up and running. Day one configuration, which would be kind of last mile configuration, getting things to talk to each other. And then what they call day two operations. And that is, OK, once everything's up and running, typically there's some care and feeding that needs to be done. Things like monitoring and making sure that it's OK. Healing or in the case of the EPC, adding subscribers or adding routes to the P gateway so it knows where to go. And the good thing about this is the information model is completely infrastructure agnostic. Right now, OSM does have plugins for OpenStack and VMware VCD. So I can take the exact same service and deploy it on different virtual infrastructure managers. And OSM takes care of abstracting that for me. In fact, as long as I've got some sort of network route between them or an SDN controller that I can talk to, OSM can actually deploy VNFs or even virtual data units, aka VMs on OpenStack and VMware and have them talk with each other. So what is VNF onboarding? So one of the challenges as associated with actually getting things up and running is figuring out, OK, how do I get through all these specifications and know what I'm talking about? So the leadership group decided that an onboarding task force should be formed. And they're basically tasked with, OK, we got to, you know, come up with documentation, working procedures, examples and models of how you can actually deploy this and get it running. It, like, participation is open to all OSM members, but the contents and whatnot are all freely available. You don't need to sign up with Etsy in order to be able to read any of this documentation only if you want to contribute. They're working towards publication of white papers, documents, et cetera. There is a full VNF onboarding document as well as a walkthrough that is already available on GitHub. And they're working on actually coming up with a repository of VNF so people can use that as a sample. So onboarding requirements. I talked about day zero, day one, day two. So breaking that down a little bit more, day zero is the type of thing where, OK, I need to, you know, know what my images are, get them uploaded to OpenStack, figure out, you know, sort of the basic operations around there. And in as part of, you know, the OpenStack images, you'll also sort of need to make that decision of, do I use just a base cloud image like a Sentos base or an Ubuntu base and then install the software at deployment time? Or do I want to pre-install all of my software, save that as an image and send it out? Day one is service initialization. And typically, you're, you know, really closely tied with day zero because you don't have an operational service until day one is complete. And that's kind of the last mile configuration of gluing the pieces together. Making sure that, you know, they have IP addresses that were assigned, that each part knows their corresponding peers IP address to get set. Everybody can talk with each other and it's operational. And day two, runtime operations is all about modification to accommodate any form of changes in the environment. You can also do things like invoke healing routines or restart VMs or basically any script that you could think of can fall in under a day two operation. Monitoring of KPIs is actually taken care of by OSM. So you can put into the service descriptor directly. These are some of the KPIs I want you to gather. So the overall workflow looks like this. You take your VNF package, which is what we're going to be talking about today. We're uploading that into the orchestrator and it's going to go ahead and instantiate that with whatever parameters you need to specify the instantiation time and stick that into OpenStack or VMware vCloud or AWS. Sorry, forgot to mention that earlier that there is a plugin for OSM to manage AWS as well. And that will actually create the network services that get instantiated. OSM will then log into the various instances, perform any IP address, like configuration files or whatever is needed to get things talking with each other. And then three, monitoring the system and performing any additional operations that may be needed at runtime. So talking about the next EPC. Is everybody familiar with kind of what an EPC is or yes, no, maybe? Okay, well, we'll take a little bit of a walkthrough then. An EPC core is composed of a bunch of components that were already defined by the three GPP consortium. So they've come up with these various functions in the network that need to be present in order for cellular data traffic to be able to pass through it. So even things like a Volte call require these things to be present in order to be able to set up the call because you're going to be doing that all over the data plane. So all of these functions are required. So the first one is the mobility management entity, which is what ultimately your cell phone is going to talk to and register itself on the network. It, you know, it's the gateway into your cellular data control and cellular data user plane, but it's the control function that makes sure that you're authorized. It figures out the serving gateway, which is the module for signaling between the mobility management entity and the packet data network gateway. And its responsibility is specifically once you start distributing parts of your EPC network, it actually is responsible for which packet data gateway you're going to go out of. So in a multi-edge scenario, you could actually have multiple P-gateways out there. So the P-gateway is your kind of last mile hop, which takes you out of all of the encrypted GTP sessions, the bearer sessions inside of the network, inside of the cellular data network, breaks out your packets and then routes them to the appropriate endpoints. So those could be things that are actually inside of the carrier network or go out onto the internet at large. And lastly is the home subscriber service, which is where all of your authentication keys get stored and as well sort of profiles of what sort of access you can get inside of the carrier's network is stored inside of the HSS. So the NME gets the keys from the HSS, challenges the end user equipment, and then sets up a path out to the internet for you. What does that look like in a picture? So we've got our user equipment, UE in standard terminology, is sitting out here and it connects to what's called an E-node B or the radio. That then uses the standard interface published by the 3GPP consortium as the S1 interface to talk to the NME. NME uses an S6A interface to talk to the HSS, goes out through the S gateway and P gateway and uses the SGI interface to go out to whatever network you have out the back end. So ultimately you're ending up with a secure channel between here and here and then the breakout occurs to go to the internet or as needed. So the next DPC software that we're looking at today combines these four network functions as one piece of software. Now each one can be run independently or they can be run all inside of one VM. For the purpose of today's sort of little demo, I'm creating one VM that is going to be a combined S gateway, P gateway and NME and a stand another VM for the HSS. So the reason why I didn't specify what the protocols were in here, because they're not relevant right now, they're going to be running as processes inside the VM so there's no external connectivity going on. So we don't need to define a network for them. So now we're going back to our journey of day zero, day one, day two. The objectives for day zero is to make sure that we understand all the necessary elements so that we can actually create the VMs at the end of the day. We need to know if there's any sort of network that networks that already exist or networks that need to be created at instantiation time. Requirements for that? Well, you're going to need your images in OpenStack. We're going to need to find out all about your networks, whether they exist or not. IP addressing schemes may come into play there because it may be a network that already exists in the carrier and you have to adhere to their subnet. And host names and IP addresses as needed. So what I have here now is I have taken those two VMs and I'm now modeling it in terms of, well, I know that coming in one side, I've got the S1 interface and coming out another side, I've got an SGI interface. I know I'm going to need management to be able to get into these and control them. And I know that there's going to be another network in here. So for the VM itself, we're going to get down and, you know, a little bit into some of the details and go, okay, well, I have to define network interfaces here. As otherwise, how am I going to connect to the networks? So I just randomly picked, okay, well, management is always going to be zero because that's kind of the most important one for me to make sure that I can even get into it and talk to it. And then just kind of added IP address or, sorry, interfaces as we go along. So in my demo, the S1 gateway, or sorry, network, an SGI network already exist. So I'm pretending I'm going into an existing carrier and that they've already got a cellular data network set up. So these already exist. What doesn't exist is this little interface between the SP gateway MME and the HSS. And that doesn't need to exist outside of the VNF that I created. It's a private network that exists between the two only. So I'm going to let OSM create that. And it can be any arbitrary subnet as long as it doesn't collide with something else. And we can go ahead and, you know, assign IP addresses as we need to inside of there. So breaking things down a little further. I've got my S and P gateway and MME, single virtual data unit or deployment unit, basically, in other words, a VM that contains these three pieces of software, giving it a host name, defining what my external IP addresses are. I've got my HSS, give it a host name. I don't need to necessarily worry about the IP addresses because it's got no external connectivity. And something important here. This is going to be handling user traffic. So it's going to be passing a lot of data through the P gateway. So I want to enable some CPU pinning huge pages and SRIOV in this particular VM. So these are all things that can be specified in the network descriptor under OSM as well. And when it goes to hit open stack or whatever technology you have underneath, it's going to, you know, require that of the Nova schedule or saying, hey, schedule me on something where these requirements can be met. So next I get these cloud images, which are freely available for download. And I, you know, upload them to Glance, make sure they're there. And I take a look, I go, okay, what do I need? Well, these are cloud based images so I can use cloud in it to define my host names and have an SSH key pass through from an external source. So I could generate my SSH key locally and just pass that through OSM and OSM won't store the SSH information. That's for me to know, not for OSM to know. So that's day zero. Now we come to day one. And that is, we got to figure out how to make sure that all of the services are initialized and any dependencies between them such as, well, the HSS needs to know the IP address of the MME because they're going to be exchanging information back and forth over the 3GPP diameter protocol. So that's, that's the sort of stuff that we need to look at here. If there's any configuration that you need to do to your VM before it's operational, this is the time to do it. So taking a look at the next DPC side of things, here's my same diagram and I look at this and I go, okay, well I know I'm going to need four network interfaces and I'm going to need four addresses for it. I'm going to need to generate SSH keys and get them in through there. I know that the MME configuration needs to be updated so it knows where to find the HSS. The HSS only needs two interfaces. It needs SSH keys as well. And I'm going to want to update the HSS configuration so it knows how to get back to the S gateway and MME. At this point, our service should be operational. Things should be able to go out there and we should be able to say, okay, it's up and running. So what are the things that I might need to do after this has been running for a while and my users have been using it? Might need to reconfigure the VNF. We might need to do things like scale out or add additional capabilities to it. We also want to make sure that we're monitoring the KPIs and have the ability to raise alarms if anything happens to it. So with this, again, I want to see if there's dependencies between components. In the case of some sort of scale out, I would need to know, well, is there a load balancer that's capable of making sure that I'm scaling out and there's nothing that needs to be reconfigured? Can I just add additional IP addresses to the load balancer and it'll take care of it all for me? In the case of the EPC, that's not going to work because diameter doesn't work with load balancers. You need different software for that. Figure out what different configurations for the runtime operations you might have and as well figure out what metrics you want to collect from your VNF. As well, you're going to want to define if you've got any closed loop operations in terms of scaling or healing, this is the time to think about them. What does it mean at production time, at runtime, when this is already ready going and executing? If I want to scale out, tying back to the dependencies, what are the things that need to be affected in order for me to scale out? Next EPC, I decide to keep things fairly simple. I'm going to be able to say, well, I want to define different routes out this interface here so that the next hop is internal to my carrier network or external to the internet or perhaps pointing it at cash or something like that. I also want to be able to add and remove subscribers from my cellular data network. And I want to make sure that I'm capable of collecting CPU and memory metrics. Actually, I forgot one point there. I also want to capture the network throughput because I want to see if I'm saturating my network or not. So a little bit of a step aside again here for a moment before we get into a little bit of a demo of this and that is this is the published VNF onboarding guidelines. And it actually goes through an entire walkthrough, similar things to what you saw here, breaking down the individual units, how to build this all together. And if you want to actually get into it a bit deeper and see the Tosca templates for the network descriptors, this is where you're going to find it. Tosca templates aren't all that interesting, so I'm not going to pop them up here right now. But another thing, the code for today's demo. So this is basically sort of a screenshot and a couple little video type of demo. So if you wanted to be able to replicate this or do this yourself, first of all, you're going to need OSM and you're going to need an open stack or AWS or vCloud or something to be able to run it on. And then you can grab source code from here. You can also take a look at it and you know, I call it code, but it's really the the actual network service templates that were used for this. So it's not so much code as the full descriptors and how it plugs together. So what does this look like once you've loaded it into OSM? So here was the picture that I drew for myself originally saying, okay, here are the interfaces and here are the external connection points that go outwards. And so once I model this inside of OSM and there's actually a visual modeler inside of there so you can build some of your network service and virtual network function descriptors in OSM using the web UI, but here these green points are external connection points. So these are things that are going to be exposed to the outside world. The pink ones are internal connection points with an internal network. So I know that those ones are going to be created on demand and here are the two virtual deployment units or VMs that I'm going to be creating. So that's what it actually looks like once it's been visually modeled inside of OSM. So day zero, the OSM is going to automate the whole life cycle, the virtual network life cycle. So creating networks and removing them once the service is being deleted. SSH key injection and it does this through two key elements. The network service descriptor, which defines the entire environment around the VNF and the VNF descriptor itself, which describes the data units or VMs or physical network functions that may be used in your environment. So here's a little short video basically of me deploying, building and deploying the package. So inside of OSM right now we can see there is nothing there. I flipped over to my shell and I'm just running the build script right out of GitHub. And so it's basically pulling everything together and I'm going to pause for just one moment there and go. I'll get into it a little bit more in a few minutes, but the main automation tool that's being used under the hood in OSM is juju. So we're actually building juju charms to be able to do some of the work for us. Now these are not hugely sophisticated right now. It's more along the lines of log in, set this file, or log in, execute the sensible playbook. This is not hugely complicated stuff that I'm doing in this particular example, but it can become as complicated as you need it to be. So here I'm showing, oh, this foe LTE is more open source software and it's a radio and end user equipment simulator. So a little bit later on you will see I'm actually going to be logging into this here, starting up the radio software, starting up the cell phone emulator. And we'll be able to see that it gets an IP address from the P gateway. So there's no VMs currently deployed and the network topology is pretty similar to what I said before. There's just an S1 and an SGI network. So there you can see there's just the two of them. And as far as the instances go, just there. So here it's actually going ahead, uploading it now to OSM. So there is what these packages look like. We've got an NSD and a VNFD and now it's actually deploying the network service descriptor. And pause right here for just a moment. Here we can see it's now saying, oops, sorry, waiting for VIM to deploy. And what that is, it's now turned around and said to open stack. Here are the VNFs that I want you to create or the VMs I want you to create and here are the networks I want you to create. So we can see here that it's expecting up to two VMs to be created and it's going to validate up to four networks. One for management, one for SGI, one for S1 and the internal S6A1. So going back to open stack now, so continue, we can see that it is now created this internal network that I wanted. And as far as the network topology goes, it's created the VMs and it's hooked all the VMs up to the appropriate interfaces. Inside of the VM, my ETH0, ETH1, ETH2, they're all plumbed in the way I wanted them to be. And here we can see open stack says, okay, well, here are the IP addresses that you asked for and the service is now up and running. Well, with one exception. And that is, and I didn't automate this as part of the demo. I actually manually logged in through the web UI because I kind of ran out of time to show this being automated. But this is certainly something that can be automated as a day two operation. I'm actually logging into the HSS right now, and I'm adding a subscriber. So if you actually look on your cell phone, at some point you'll find that you have an IMZ, an IMSI, which is a unique identifier that identifies who you are as a subscriber. And in as part of this, we need to add the encryption keys that are going to be used to challenge the end user device to make sure it's authentic. So those keys are actually burned into your SIM card. And that's about it. Oh, the other things that we can do is you can actually configure access point names, but that's getting a little bit far down into the EPC core that we don't need to worry about right now. So day one. So now that I had everything, you know, sort of deployed, what we didn't see or I guess what we did see was it deployed it in OpenStack and then turned around. And here's what I was talking about the VNF configuration and abstraction module or VCA for short, which is another term, you know, Etsy loves their acronyms. They love defining these things. So this is a part of the man of specification, which is the thing that interacts with your VMs for you and keeps them running or logs in and does the work for you. So as I mentioned in OSM, this is implemented by a juju controller and it logs into the VM and performs actions. And in this demo, really all it did is it was modified configuration files to add the IP addresses for the current network and restarted the services so that they could find each other. So this one is not quite as interesting because I didn't use a real cell phone and it's more command lines. But basically what we've got here right now is, so this is my faux LTE VM again. I've logged into it a couple times. You'll see a couple terminals in a moment. So the first thing we do here is I show the IP configuration for this particular VM. This is the software radio starting up and then over here you can see with the IMZ, well, scrolled off and the keys that were acquired. So this is actually the cell phone starting up and now we can see we've got ourselves an IP address that wasn't there before. So this is actually attached to the EPC Core now and I can ping the P gateway and the P gateway can ping back to the cell phone. And this actually takes five to ten minutes altogether end to end and the entire thing is up and running. Oh, sorry. And here when I detach the cell phone, you can see the IP address went away again. So day two, monitoring. So as part of my network service descriptor, I said I want to collect CPU usage, memory usage, network packet sent and received. So that's already running now and OSM comes by default with a Prometheus database to use as its time series database for all of its metrics. And the alarming module also uses that to raise alarms. You can also have your own elk stack or ask OSM to provide you with an elk stack. So this Grafana dashboard is something that, you know, if you ask for the full stack to be installed, you'll be able to get this information right off from your Grafana instance that OSM has installed. And here what I have is brand new instantiation. There's nothing really running. My CPU is less than 0.8%. Memory is pretty low usage here, 490 megabytes. Yeah, 490 meg. Network packet sent, less than 0.7 packets per second, packets received, less than 0.65. So it's a pretty quiet system. The next thing I did was from the UE side, I just simply started up IPERF headed towards the P gateway. And on the P gateway side, I have the IPERF server running. So now I'm generating traffic running between the two of them and I can see in OSM, all of a sudden my packets sent are starting to go up. We're not at point something anymore. We're 250 packets received, 800. All of a sudden the memory has gone up because, well, IPERF is running and it's doing things. Same thing with CPU. CPU usage goes up. So all of this information is collected automatically and I can do things with it as needed. As part of the overall OSM architecture and the things that it provides, it actually does provide an alarming module. So you can set simple rules like if the memory goes above 64 gigabytes, raise an alarm. Or if the CPU drops below a certain amount, maybe I want to scale in at that point because maybe I've got too many instances running and if they're running really cold, why do I need them? Why don't I just scale on in? So OSM does have scaling operations that can go with it and the VDUs can be monitored and scaled independently. Yeah, I alluded to this earlier as well. They too, operations are actually capable of executing. You can write them to be arbitrary scripts and functions. So you could have something like an external monitoring system that either is taking a look at the alarms that are being raised by OSM, looking at the raw data, or maybe it's something like VMware vROPs where you realize operations that has been monitoring your VMware infrastructure and it's raising alarms on its own, which we can then turn around and tell OSM, do something for me. So there's built-in actions or there's the availability of external triggers as well. So the last thing is, what are the Etsy specs? These are the ones that I was referring to here earlier. So you can review them, Sol1 and Sol6, which are almost mirrors of each other. And just a quick little wrap up in any time for questions or I think we might be out of time because we were just asked to finish. All good?