 Hello, my name is Kathy Zhang. I'm a principal architect at Huawei. I'm also the project lead of the OpenStack Neutron Service Function Chain project. My name is Igor Duarte-Cardos, software engineer at Intel in China and Ireland from Portugal. I've been working on service function chaining, mainly for Neutron Networking SFC, and I'll be talking with Kathy today about SFC graphs, NSH SFC encapsulation, and how we can do that using Networking SFC. So I'll start first. So today our topic is about how you can empower your NFV services through the OpenStack Service Function Chain and the Service Function Chain graph. So first I'm going to go through the service chain logical model and API of existing OpenStack Service Function Chain. So the OpenStack Service Function Chain API is composed of two parts. The first part is a flow classifier. The second part is a port chain. The flow class file specifies the classification rules that I use to classify the flow, which will go through the service chain. And the port chain consists of ordered sequence of service functions. So in this example, the port chain consists of a firewall service function and then an IPS service function and then a video optimizer service function. So each service function could consist of multiple instances. For example, like in this example, the firewall functions consist of two instances. IPS consists of three instances and the video optimizer consists of two instances. So those are for low distribution purpose. And each service function instance is modeled, is represented by a neutron port of that service function instance. And then the neutron port of those functional like service instances are grouped together to form the port pair group. So the port chain is actually specified by an ordered sequence of port pair groups. So like traffic flow originate from a source will go through this first port pair group, which will do the load distribution to select the instance for the firewall and then go to the second service function and then go to the third and then reach the destination. So this slide shows more detail the logical models of the service function chain. So we have, as we mentioned before, we have four logical entities, port chain, port pair group, port pair and flow classifier. So I'm going to talk about port pair first. So in port pair that represent a specific service function instance. So you specify in the API, you specify the ingress port and ingress port of that service function. So that service function can run on a VM, which will be the neutron port, right? Or can run on a container or physical device. Container also has a neutron port using the VMware VM. And then there's also another parameter you can specify for service function, service function parameters. For example, you can specify whether this service function is a layer two type or layer three type. Or what is a weight for that service function in the load distribution in the group so that you can do more smart load distribution. And then these, the port pairs, multiple port pairs can be grouped together into a port pair group. So in port pair group, you specify the list of port pairs. And then you can also specify port pair group parameters such as, you know, the, um, the hashing field for that port pair group, what hashing field to use for your load distribution algorithm. And there could be other port pair group parameters for future extension. And then there's this flow classifier. So here you can specify any combination of these fields to, to classify your flow. For example, you can specify a source on IP address range or at least the IP address range, IP addresses, or destination IP address, or like, you know, logical source port, or like the TCP port or UDP port, either source port or destination port, any combination. You can also specify up to the layer seven parameters. That's for the future extension. Okay, so, um, so how we are going to cut, how we can form a trend graph, um, based on the open stack service trends. Um, so there are two cases here. One case is when the traffic flow goes through the sequence of service function, the classification rules change. So like for this case, you know, some service function could modify the N-tuple of the traffic flow. For example, that very simple case is going to modify the IP address. Then in this case, right, we can, um, we can handle this case by creating two port chains, two service chains to form the trend graph. For example, we can create port chain one and port chain two. So the original flow is from that logical source port P1 to the destination IP address. So for port chain one, we specify the flow classifier as the source port is from P1. The destination IP address is IP1. And then that flow will go through service function one, service function two. The second port chain we specify the source port now is originate from P2. And then the destination IP address now is changed to IP2. And then this traffic flow will go through service function three and service function four. So we can coordinate these two chains together to form a chain graph. Of course, in the later slide, we're going to show more complicated cases built on this, you know, theory. So another case is for the classification rules do not change. So in this case, it's simpler. For example, in here, right, we have one and the red line shows the first port chain, and the black shows the second port chain, and the green shows the third port chain. So the first port chain is classified by flow classifier one. It goes through service function A, B, E, F. The second is classified by flow classifier two. It goes through A, B, D, G. These are different service functions. And the third is classified by flow classifier three. It goes through service function B, C, F. So you can see that, you know, some service function can handle, you know, multiple chains. So these we can form a chain graph just by, you know, group them together as a chain graph. We're going to show in later slide how you specify in the API, you know, to group this together. Now I'm going to hand over to Igor to go through this in more detail. Thank you, Cathy. So I'll be talking mainly about a new resource for networking as FC called as FC Graph. It's seen very much the same fashion as the first kind of chain that Cathy presented where the classification rules change during the chain. So I'll start by why do we need the FC Graphs? What can we do with them? Essentially we have two to three reasons for doing that. We may have service functions that change the classification of traffic. So the incoming traffic is a certain classification, but the outgoing traffic will be of a different classification because the function has made changes to the traffic. Or we might have certain service functions with classification capabilities, advanced classification capabilities that are able to go deeper in the traffic in the packets and detect other kinds of classifications that the main classifier may not be able to detect. And in both of these cases we may want to branch out of our current chain depending on these classification criteria. Or we may just want to have a dependency between chains. We may have many different chains depending on the same chain regardless of classification. This is more as a consequence of the first two reasons. So to justify this, why introducing an FC Graph resource? I'll show you a couple of use cases to start with. I have a very simple academic use case where we get initially some encrypted traffic inside an IPsec tunnel. It could be something else but just some encrypted traffic which is then sent to a first service function, an IPsec tunnel terminator which will decapsulate and decrypt traffic. And we will then know what is the actual classification inside of that traffic that we did not know beforehand because it was encrypted. So this is an illustration of the first scenario where we don't yet know the... actually where we changed the classification of traffic because initially all traffic or IPsec traffic got into the chain but now we know that it's actually TCP or something else. So the classification has changed and we now are in a position to better decide what the next function should be. So if it's TCP, it goes to a TCP optimizer. That's the TO function at the top. If it's not, it goes to some other function, a load balancer for example. And in here we have three port chains, three networking SFC port chains which are very similar to service function paths in ITF SFC. So for the first chain, we just look at all traffic coming from a certain source, an IPsec source. It could be a neutron port, it could be the virtual router. We send it to the first service function. And for the next two chains, they will both depend on that initial PC1 chain, the first chain to be processed and the difference between these two branches will be the actual classification, if it's TCP or not. But in both of the branches we have a dependency. Traffic first needs to go through PC1. So that's the first use case. Then I have another use case, slightly more complex. I've taken it from the ITF 89, some slides from ITF 89 regarding mobility use cases in SFC. It identifies a video optimizer use case chain. And we will focus on just that rectangle there because all of the rest doesn't really change the SFC graph. It would only make the figure even more complex than this. So this is the focus of that use case. So we get all of the traffic from a big gateway. It goes through a load balancer and then we detect whether it's TCP port 80 or not. If it is, it goes to a DPI function, Deep Packet Inspector, which has advanced classification capabilities. That illustrates the second reason for why we should have SFC graphs. It has advanced classification capabilities and it's able to know whether we actually have video inside of that traffic or not. And if we go through a video optimization function, that's the VO function, if we don't have it just goes through the load balancer. In this case we have five port chains. The initial chain just looks at all of the traffic coming from the big gateway and the other chains all depend on some other chain. I specifically mentioned PC4, which is the chain that depends on the chain of the DPI function. So the traffic will go through the DPI function and if it's video, it then goes to the video optimizer function and that's chain 4. So you can see the advanced capabilities used case for a classifier. You can see dependencies between chains. You can see two examples of branching in a chain and here we have an SFC graph. Now, how can we achieve SFC graphs? How can you bring them to network SFC specifically? We make sure that the traffic from a certain port chain will reach the next port chain and only that traffic, not any other traffic, because there's a dependency. We need to make sure that traffic doesn't get mixed up in different port chains when the classification is the same. There needs to be some kind of segregation, some kind of encapsulation, chain or path identification. So we take a look at the SFC encapsulation concept from ITFSFC which has researched this in very deep detail. And the main thing about SFC encapsulation is that we have a way of identifying paths in a chain or a graph. And we fully encapsulate where we are able to fully encapsulate the whole frames. So there's no loss of information or context and we know exactly where in a chain or where in a graph we are thanks to service function path identification. Service function path is essentially a port chain in networking SFC. NSH is the protocol being developed and detailed to be the SFC encapsulation protocol in ITFSFC. It's a proposed standard. It's still a draft yet, but it's the only SFC encapsulation protocol being developed, specifically for this purpose. It includes service path identifier and a service index to contain the service function path information so that we know exactly where in the chain we are. SFC encapsulation allows us to then do branching in our chains and consequently create SFC graphs. Here's the NSH protocol. You can specifically see the SPI and SI fields which uniquely identify the path of our packets and consequently the chain and the graph. Now, specifically to networking SFC, what have we done so far? What are we going to do to bring SFC graphs and NSH to the project? A first change was already submitted and merged which is a chain ID field in the API. The chain ID is a parameter of the port chain resource and it's essentially the same as the SPI here, the service path identifier. It uniquely identifies the service function path or a port chain in networking SFC. It's the same thing. It has been merged already. Even though we don't really need to expose that in the API, we just had to use it in the backend to properly segregate traffic. It's very useful if we want to share the chain identifications across the manual layer, let's say. The chain ID parameter is there as part of the port chain highlighted in blue. It's the last parameter in the port chain resource. This figure here illustrates why chain ID is important when it is shared across the manual layer, across NFVO, NFE orchestrator and the VNF manager. What can we do by exposing that chain ID there? We can have networking SFC with the enabled Neutron backend, for example, OpenVswitch, managing chains with certain SPIs, but we can then tell NFVO about those chain IDs, which can then tell the NF manager, which can then tell the service functions that are deployed, which might be classifiers as well. We can enable external classifiers alongside the Neutron classifier provided by OpenVswitch. We can have, for example, Layer 7 DPI function during classification based on Layer 7 fields, parameters, attributes, and inserting traffic in the appropriate chains, in the appropriate paths based on what the orchestrator has deployed. We can have a very consistent deployment of service functions and classifiers, both built-in and managed by Neutron and externally deployed using a VNF manager. Second change is to actually enable NSH. So until now, networking SFC has only used MPLS, and MPLS is not exposed to the service functions at the moment. So there's a logical SFC proxy. SFC proxy is another definition from IETF SFC, which, before sending the packets to every function, OpenVswitch will take out the MPLS chain layer so that the functions will understand the packets as typical Ethernet IP packets. So this patch enables NSH support. It enables NSH exposed to the VMs. So without taking the NSH header before sending it to the VMs, it still supports an SFC proxy. So OpenVswitch is still able to remove the header if we specify in the API that we don't want NSH to be exposed to the VMs. You can do that. And yeah, this is the first part to enable SFC upstation in networking SFC. It still doesn't enable SFC graphs, though. That's the final patch. Oh, by the way, these are the changes. You can see in PortChain, the chain parameters field inside it's a dictionary. It has a key called correlation. If we set that to NSH, then our PortChain will be NSH-based. The other change as part of this patch in the API is at the PortPair resource. Again, service function parameters, it's a dictionary. The key correlation, if we set that to NSH, then NSH header will be exposed to the VMs. The VMs will receive NSH. If we don't specify NSH there, the obvious driver, which has been the backend that has NSH reports so far in the patch that I've submitted, it will execute an SFC proxy and will remove the NSH header before sending it to the VM. All right, final patch, SFC graphs. For now it's only an API patch. It provides a new resource. You can see here, bottom right, SFC graph. It's a dictionary of PortChains. The keys are the previous PortChains and the values are the next PortChains, are the branches of the PortChains. So PortChain 1 will branch to PortChain 2 or PortChain 3, in the example, depending on different classification criteria. The classification criteria will be provided by the full classifier associated to PortChain 2 and PortChain 3. For PortChain 2 as an initial chain, same thing will happen. So this is how we can have SFC graphs in network NSFC. The API patch has been submitted. The implementation still needs to come in the next few days. Now, I'll go back to the use case of the video optimizer, but I will expand it a little bit more so we can better understand what happens internally. This is a service plane view of our chain, of our graph. What if we want to have a look at the folding plane of the same graph? Here it is. This folding plane view shows the data plane elements that are used to have the graph shown here. So initially, there's a classifier that will get all of the traffic from the P gateway and will send it to a service function forwarder. That's another definition from my ETF, SFC. The service function forwarder, essentially, is a logical element that looks at service function path information, SPISI, and decides what the next hop is for that chain. So classifier will insert the NSH header, CL1, and will send the packets to the forwarder. The forwarder will look at SPI and SI information at the NSH header and will send the packets to the load balancer. Now, after the load balancer, we have an example of a branching scenario, so a branching chain there. Same thing will happen. CL1, the classifier will set the service function path information based on the classification of traffic. So at that point, it will check whether it's TCP port 80 or not, and will insert the appropriate NSH header. It will then send the packets to the forwarder, and it will look up its NSH mapping table, looking for the SPI-SSI that the classifier has inserted, and will then select the next hop accordingly. The same thing happens for the classifier 2 and SFF at the top after the DPI. The only difference is that CL2, classifier 2, it's an external classifier that will usually be co-located with the DPI. Remember, these are all logical functions, logical resources. CL1 and SFF can be co-located together, as in the case of the OpenVitch driver for networking SFC, or CL2 and DPI can be co-located. They can be a VM doing that job of both inspecting traffic and classifying traffic. These are all logical elements. And that's all for me. Okay. So here's some project status update. So we already have two official releases, Liberty and Metacor. And the new features for Metacor is the add-chain ID to port-chain parameters, which Igor just mentioned about, you know, has already talked about why we need to add that. And then we also add weight to the service function parameter to allow, you know, more smart load distribution. We also add the port-pair group parameters for the, like, you know, L2, L3 type. And then we also add a function which can dynamic insert and remove service function to or from a port-chain. Of course, we add, you know, Tempest test, functional test, which are all those automatic tests. We're going to do the new-time release in December 2016. And for this new release, we are going to add support for symmetric chain, exact match-based flow, rule creation, deletion. And here are some information links if you would like to know more about this project. For this NSH support, we will do after the new-time release. And that also has dependence on that NSH patch being merged into the OBS. So here are some reference on the IETF on service function chain architecture, you know, the data pass encapsulation spec, and also some other NSH-related information, including the OBS and NSH patch information. Okay, that's it. Thank you. Any questions? So your question is how can you use a classifier at the... Okay, so... No, currently the classifier is implemented in the OBS. So it do up to the layer four. It doesn't do up to the layer seven yet. So for the layer seven, you know, you will need a DPI device to do that classifier. Okay, so the question is... Yeah, it's a microphone. If you can go to the microphone. If you have any questions, yeah. Good presentation. We liked it. One question I have is, since we talk about graphs, VNF forwarding graph, and you say here SFC graph, so are they different? And another question continuing on that, do you have any domain specific language for the service function chain which you can use for chaining? Okay, so for the first question, VNF FG, right? It is different from SFC graph as presented here. So VNF FG, the main difference would be almost everything, but VNF FG is you have your VNFs, your service functions, and then you connect them through different chains. You present all of the chains that go through your multiple service functions from the beginning to the end. So you have an initial classification for every chain, and then you just draw how they connect to different functions together, and then you've got your VNF forwarding graph. Now, SFC graph is different. It's like an extension to a chain but with branches. So it's still scoped to a particular use case, but instead of starting from the beginning, having an initial classification and going until the end, you can branch out of your current chain based on different criteria, but it's still scoped for a particular use case. Whereas VNF FG is, you know, all of your chains and how they connect to different functions. So this is local. Who is the superset? VNF FG is the superset and SFC is the, chaining is the subset of that? Can I consider VNF FG as the full chaining and SFC chaining is just a subset of that? Not really, but you could present an SFC graph by using a VNF FG. What you would say as the classification for the chains of the VNF FG is that the classification would be a dependency on another chain. You'd have to say, the classification is another chain first. You could draw it like that. So it's a dependency chain. Second, that was related to, is there any specific DSL, domain-specific language, like you are writing chain paths and all that? Can I consider that as some kind of a DSL, domain-specific language for service function chain? We haven't worked on any DSL. At least for the time being, it's just a dictionary of Portion dependencies. Thanks for that talk. So my question is, can the classifier exist outside of neutron? And if so, how does that work? You want to go? Yes, you can have a classifier outside of neutron. You just need to make sure that it is fed with the appropriate chain IDs, SPIs, so that it classifies accordingly to the setup of functions and chains that you have. It's to be consistent. Yeah, we have a slide on this. Hold on. Let me go to... Yeah, here, right? So this slide shows that you can have the classifier outside of the OVS. When you say neutron, neutron is more the management control plant, right? So this is on the data path, right? You can have the classifier outside of the OVS, but you need the VF manager to coordinate the chain ID. For example, you do the DPI, right? As a separate device, you do the classification. You have to insert the chain ID, right? That chain ID has to be recognized by the switch. And this naturally requires NSH? Yeah, a chain ID could be... So without NSH, this functionality is not possible? Yeah, NSH, or you can use... Since currently NSH is not merged into OVS yet, so we use NPR's label to represent the chain ID as a placeholder for the chain ID. You need some field for the chain ID. That's the key. Yeah, and you need the upper layer to coordinate the chain ID, to be the same chain ID it knows, right? Oh, this handy represents which chain, right? So you know the DPI device, insert that chain ID, the service function for order, which could be a virtual switch, either OVS or physical switch, or other virtual switch, need to understand. Okay, for that chain ID, I need to forward to which service function, what's the next hop service function. So the upper layer, like in this diagram shows, need to coordinate this information. Right, understand. And just last thing, you did say that the asset proxy function is already implemented? Yeah. So if the VNF doesn't have an idea of what to do with the metadata, this wouldn't be a problem? Wouldn't be a problem. Yes, it's already implemented. So service function proxy functionality is already implemented in this new service function chain project. Cool, thank you very much. You're welcome. Including with NSH. Yeah. I had a question regarding the load balancing function. How does the load balancing work within, so you mentioned weight, but I didn't see a lot of information on that, so maybe you can elaborate on how it load balances between, within the port pair. Okay, so the weight, you can specify the weight for the, for example, if a service function, for file or service function type, right, you'll have three instances, right? You can specify the weight for each service function instance, and then that information will pass down through the driver, and then to the, for example, OBS driver path, the native path, or a new translated path, right? Then, you know, the OBS agent will, based on that weight, to do automatic load distribution, based on different weight. You give a higher weight, it's going to be selected. That service function with a higher weight will be selected to be used for the chain path, I mean, more probability. Yeah. Okay, it's not based on the, the traffic going through each of the, it's not dynamically adjusted by SFC or anything like that, right? We just specify the weight and then, based on the traffic, it doesn't get readjusted, it's just static. Yeah, so once, you know, so you specify the weight for that chain, right? And then for that flow class, right? So based on that weight, a service function will be selected for that traffic flow. Once it's selected, it will not change. I would say it will not change, but okay, so let's get into a little bit more technical detail. So for state for service function, once you selected the service function, you don't want to change, you know, when the service function scale out or scale in, right? You don't want to change, right? So when you scale out, you want to maintain the same service function for the previous traffic flow. But when you, but for new traffic flow, when it comes, right? It depends on the weight. It can catch to a new service function. So this weight is just for load distribution. If you give a high weight, it will be selected more for different traffic flow. Because one service function, the same group of service function can be shared by multiple chains. We have a slide on that, you know, here. For example, the service function B, you can see it's shared by three chains, right? And then if service function B, there are multiple instances. Then which instance you select for chain one? Which instance is that for chain two and chain three? It depends on the weight we'll play out there. Just that one flow, right? It's not static. Let's say I'm redirecting from port one to the service function. So the port one traffic always goes through that service function or like maybe for a session, it goes through that. And then for the next session, it might go through a different service function. So for the same traffic flow, the same type of traffic flow, same flow classifier flow, will go through that same service function. Okay. I follow on a question from that one. So I understand you've got the waiting to do kind of load balancing across the service function instances. What in this picture is doing detection of the liveness of those service function instances so that, for example, it doesn't attempt to root a new traffic flow to an instance which has just gone down? Okay, that's a good question. So you're talking about the health of that service function, right? That's kind of out of scope of the chain. So you need another service function manager or any health monitor to monitor that service function and then to feedback that information to the service function chain so it knows, okay, now that service function is out of service. So I will not, you know, hash any traffic flow to that service function instance. Right. So you need some kind of external management agent to monitor the liveness and update the definitions. Exactly. Yeah, but the lifecycle of service function management is outside of this scope, but it needs to be coordinated together. Yeah, like you said, feedback below. Yeah, that's right. Any more questions? Okay, that's it. Thank you very much. Thank you.