 Let's speak with you today about application-aware service training and what is it designed for and what is the current status of standardization on this topic. So let's start first by a quick definition of what we mean by application-aware service training. If you have a look at a regular network, you will find a long chain of middle boxes. Typically, that could be on a GI LAN or even in a data center. You will find firewall, load balancer, caching. And in a typical network, you have this long chain of devices. And it means that each and every flow have to go in each and every middle box. That's very inefficient because many of the flows shouldn't have to go to all of these boxes. And people are thinking about service training to make that a bit more efficient so that you can automate placement of middle boxes. But in general, it's not application-aware. What we'd like to do with application-aware service training is making sure that only the right flows are going to the right boxes. Typically, in this example, you'd like to have HTTP flow going to load balancing and firewall. But video might not go to firewall because there is not much thread to find inside videos. So the general idea of application-aware service training is to build service chain which are subscriber-aware and application-aware, which is not the case today. So service training is useful when you want to dynamically deploy boxes and you want to enforce some policies and do some processing on some flows, but certainly not on all the flows. So at the end of the day, if you build a network with application-awareness service training, you will be able to get a better optimization of your resources because only the right flows will go to the right middle boxes. And it will make you easier to automate the deployment of services inside the network. So this problem has been taken from different angle by different standard organization. We can start by the Etsy, right? So at the Etsy, there is this concept of network services. And it's basically a VNF forwarding graph. So you take several virtual network functions, you connect them with virtual links, and with that, you build network services. And what we see is that it's very close to service training because you have these virtual network functions connected with virtual links. So this is mainly something designed at the manual management and orchestration level at the Etsy. At the ONF, this is as well something which is being discussed. But from a different perspective, here it's more how you can dynamically configure that from the control plane level. And for that, you need to extend the northbound interface of a controller. But you also need to extend the open-flow protocol so that the controller can populate the network infrastructure with the right application level, layer 7 information. So that's something which is currently being discussed as well at the ONF. And if you have a look at the Etsy, people are working on that as well. So there is a very active working group called SFC, which stands for Service Function Training. And here you have mainly two proposals, one coming from Cisco. It's called NSH. Another one is coming from Huawei. It's called SCA. Then you have a bunch of other proposals. The good news is that during last IETF in Toronto, it was decided to merge these two different protocols. But basically, the idea is to tag IP packets and to extend IP packets with chain or pass identifier or chain IDs. And this protocol could be NSH, SCH. It's a great example of a great place where we could also carry layer 7 information, such as application ID or metadata. And we'll talk more about that. There is also a lot of work currently being done in the Open Daylight Foundation and in the OpenStack regarding group-based policy, GBP. There are many discussions around GBP right now. And GBP is also all about service training and how you have these model-driven policies. And we are also working on that to make it more application aware. So three different perspectives and three different standard organization trying to solve a similar problem. The good news is that all of that is currently emerging. And the goal of this presentation is to present you how all that articulates with more details. So let's start with IETF. So at the IETF, there is this reference architecture where all packets have to go to what we called a classifier. It's also called service classifier. My presentation should be shorter than that. So yeah, at the IETF, the idea is to have all packets arriving in a classifier. Classifier is a network function that could be done in a virtual suite. That could be a separate physical box. But the idea is to say, OK, based on various criteria, could be layer 2, layer 3, layer 4, could be subscriber, could be DPI, different kind of criteria, you will tag IP packets. And you will add a new header in front of this IP packet. So it could be NSH, it could be SCH, based on VXLAN, it could be Genev and VGRE. So you have many proposals here. But the idea is to tag these IP packets. And then in the data plane, it could be physical or it could be virtual data plane instead of routing IP packets based on IP addresses or switching IP address, switching packets based on MAC addresses, you will do chain switching. And this chain can be defined by an application ID. So suddenly, you have the ability to say, OK, if I see video traffic, I want to go this chain. If I see video traffic, I want to go this chain. And you have an application-aware network. So that's what we are working on at the IETF. And you have many people working on that at the IETF. And this is mainly the service training but taken from the data plane point of view. So typical example extracted from the IETF draft. So you are adding that in front of an IP packet. You have this path identifier. And this path can be the result of a rule and gene taking into account subscriber ID and application ID. Second level is this level. So this graph has been designed by people working at the Layer 4 to 7 working group at the ONF, at the Open Networking Foundation. So the idea is to say, OK, we now have this very smart infrastructure which is able to do switching based on chain IDs instead of IP addresses or MAC addresses. But now you need to populate all the network infrastructure with all this information. And this is where the ONF is working. So you have this SDN controller. And one application that could be designed on top of this SDN controller is an SFC controller, SFC for service function training. So you have REST APIs where you can say, OK, if I see HTTP, I want this chain. If I see audio, I want this chain. So you are an application sitting on the north of this infrastructure will be able to configure the underlying infrastructure using a regular SDN controller. And then you have the SDN controller using OpenFlow extension which will populate the physical infrastructure or the virtual infrastructure using OpenFlow or using up flex like protocols. So you have different options here. But the idea is to say, OK, here you have REST APIs where you describe the chains. And here you have the controller doing computing how that should be deployed then in the physical or virtual network. And using an OpenFlow extension or an up flex protocol, you are deploying that into the underlying infrastructure. And you use IETF, SFC, it could be an SH or SCH to do the physical switching or virtual switching of IP packets. So here is a typical extension that could be done in OpenFlow. But OpenFlow is just an option. There are other options to do that. So if you take a typical OpenFlow table, you will find the regular 14 criteria. But you could certainly add others like the application IDs and build OpenFlow rules based on layer 7 criteria instead of layer 2, layer 3, or layer 4 criteria. So these are very interesting extensions that could be added to OpenFlow or to virtual switches and that have to be populated using OpenFlow protocols. So this is the second layer of this architecture. Third layer is what is being done at the Etsy. Well, I'm speaking about Etsy. But actually, you have similar stuff happening with GPP for OpenStack. People in Neutron are also working on that. So basically here, what we need to say is to explain is how you build. So if we use the Etsy terminology, it's network services. So a network service is a combination of several virtual network functions. And they are all connected together using virtual links. And with each and every virtual link, you have a policy which is coming, right? Saying, I want this QS. I want this security policy, and so on. And at the end of the day, that's very close to service chaining. So the good news is that as you might know, we are about to end the phase one of the Etsy. We are about to enter in the phase two of Etsy NFV ISG. And in this phase two, we are now defining how this Etsy orchestration will be interconnected with OpenFlow infrastructure. So they are new. They call that liaison group, which are currently being set up to define how the management and orchestration layer of the Etsy should interact with people at the ONF. And these are definitely this SFC source-bound interface, which is a northbound interface of the controller, which is currently being defined here. Typically, that will probably be REST APIs. And then here you will have OpenFlow or UpFlex protocols being used to populate that down to the infrastructure. So here it's a typical example. It's extracted from the NFV draft, right? So you have endpoints. You have the network functions that are virtual network functions. But then you have this physical infrastructure or virtual infrastructure, which is under that. So that's very interesting, because we see at the end of the day, we are coming. That's very funny, because I think that at the beginning, you have three different standard organizations taking similar problems from three different angles. But what we see right now is all of that is currently converging into a unified infrastructure to be able to do application-aware service training and service training. So that's very interesting to see all this trend where three different things are converging to a unified view and a unified model. So if we have a look at that in more details, so what are the important working groups working on that? So you will find at OpenStack, so you have many people working on GBP, group-based policy. So it's a simplified neutron, if you will, or something making the network more policy-driven. So there are many discussions on this topic there. Then there is the Etsy NFV Management and Orchestration Group, which is very important. And in this group, there is a subgroup called the VNF Forwarding Graph, which is all about how you connect all these virtual network functions. So this is really for the management and orchestration layer. Then if we have a look at this controller level, there is a little bit of work being done currently at the ONF. It's mainly people working on the NBI, the northbound interface, how you configure these service chains using REST APIs. So right now, people are talking about that. But then also, you have people working on the Extensibility Working Group, which is all about how you extend the open-flow protocol so that it's richer and it is able to carry and to populate the underlying infrastructure with chain information and layer seven informations. And there is also an interesting working group here, which is the layer four to seven working group, where people are defining use case and how middle boxes are being plugged into an open-flow infrastructure. So this is currently work currently being done. And then if we have a look at the infrastructure level, you will find the IETF. So Service Function Chaining is a key working group right now. A lot of work is currently being done in this working group at the IETF. But there is also the NV03, which is about the overlay network. So these are protocols like, this is where we define protocol like Vexline, NVGRE, Geneva, and all of that to be able to extend these IP packets with chain information, also known as past identifiers. So this is, I call that the unified model because this is a result of three different standard organization converging to a unified model. That's very important. And that's a good news to see that these groups are working all together. We can speak a bit about projects and products. So you will find products like open-source product in green and commercial product in black. So you will find all the usual companies right here. Typical Alcatel Lucent, HP, Huawei. All these guys are working in these domains. Here for the controller, open daylight, very active. Control working on service chaining. HP with commercial product like Van working on that. And you see all these guys are involved in this control plane layer. And here you will find Huawei, Cisco, all these guys working on the infrastructure. OK, then there is a very, now that we have this unified view, you have key questions that are still remaining. And there are a lot of debates right now. Where should the intelligence be, right? So if we assume that we have a model-driven management, meaning that you define policies, right, using GDP, group-based policies, to describe the way communication should be described, then this could be the way rules are then computed and executed, could be done in different places. So you have people who say, OK, that should be done at OpenStack level, OK? You have other people saying, OK, GPP should just be, GPP rules and policies should be stored at OpenStack. But then that should be done at the controller level. It could be Open Daylight or it could be another controller. And then that should be converted into OpenFlow at the controller level. And then you have a third model, which is to say, OK, you have GPP here, you have similar GPP rules, and that should be, and you should have all the policies directly being stored in the infrastructure. And that's why the UpFlex protocol have been designed by Cisco and is now proposed at the IETF. It's to say, OK, the intelligence should remain here, and all this complex rule should go from the top to the bottom, but then computed and executed at the bottom. So you have debates here about where the intelligence should be, and you probably understand there is a lot of implication with that. OK, so a few words on what we are doing at Cosmos to make all these service training infrastructure application aware. So a few key contributions we did, and we are working on GPP. So we are making classifiers application aware, which is not the case today because they are mainly layer 2, 3, 4 driven, Etsy, SDN, liaison group. So it's a joint group between the OpenFlow and the Etsy. So we are involved there in a few proof of concept. We will work at the ONF to make that more application aware and design how we should populate the underlying infrastructure. And we have a few drafts being signed by our company here to make SFC more application aware. So these are our key contributions to make this infrastructure application aware. So as a summary, I think the reason for this presentation was just to explain service training is becoming a key concept because it will be a new way to design networks instead of having a chain of services. People will have that more like as an hub with a service classifier, and then you will divert only some flows to some virtual functions. So that will be absolutely key in the future, both for service providers and data centers. It requires a tremendous amount of standardization to make that possible because you make different solutions and interoperate. And it requires application awareness that is lacking today if you want to make sure that you save resources and you only send the right flows to the right middle boxes. I have 16 seconds, so I don't know if you have questions. No? Thank you.