 Okay, guys, nice to meet you all. Thank you for joining, okay. Today I will discuss the SuiteCon project, which is a new open source project to help us to accelerate control plan for edge networking. My name is Hong Junyi. I'm working at Intel. Since three years ago, I have been working on FIDO project. And now I'm the WPB maintainer, the SuiteCon project leader, and also the Institute of Surface BunkChamp project leader. Okay, actually the SuiteCon is teamwork from many countries. Currently it has 12 initial organizations, including Cisco, Huazantia, China and Vio, China Unicom, China Telecom, and XP, Tiato, Tessant, Alibaba, Viti and Huawei. So lots of guys have given great contribution to this project. Okay, this is today's agenda. First, we will talk about the requirements for edge networking. And then we will talk about the SuiteCon, software architecture and its roadmap. And then we will explain the details for the software implementation. And then the current progress and the release notes for some release. And then we will talk about its usage in the UCB SDK reference solution, and then the summary. Okay, first of all, the requirements for the edge networking. And on the top side, it's the traditional SDN controller networking. So on the top side, it's the SDN controller orchestration. So it will configure the configuration through the net conf, rest conf and other not spawned interfaces to the data plan. But you know, for many SDN controller and orchestration, its configuring is using the young models. So we need a management agent in the middle to translate the young models to the low-level APIs, such as the VPP, DBDK, and the NICS kernel. So for the management agent, there are many requirements. Currently, there are four requirements. First of all, for edge, it's low resources, such as we need less CPUs, less memories, and other resources. And secondly, for edge, you know, the end devices join and move very quickly. So we need the faster configuration rate. And then you also, you know, for especially for the edge, it's used for the telecom. So the high ability is also required. And we also need to support the structured model because, you know, many countries have their own devices and also their configuration. But this configuration is unstructured. So we need a standard and a specification to help us structure the definition and the configuration. So this is the solution architecture for SWITCon. Actually, it's a big picture. We will explain it from the top to the bottom. On the top, the SWITCon provides different northbound interfaces, such as the NetConf, RESTConf, GMI, and we will also support PFCP for 5G. We provided these different northbound interfaces to integrate with different orchestration and S-Dain controller for us orchestration project, such as UNAP and Kubernetes. For the S-Dain controller, there are some open source projects, such as OpenDelight and ONS. And we also provide some interfaces for the data collect. For young models, you know, actually currently there are two young models. One is IETF for telecom, and another young model is OpenCovic for service clouders. And for the data store, we leverage OpenSource data store, which names the system report. It contains two data stores, one is configuration data store, another is operational data store. Okay, for the, I will talk about first the data plan. Currently, there are Linux kernel data plan, the Linux networking stacking, and also user-spec data plan project, such as the DBDK and the VPB project. So, here we have a translation layer, which means it will translate the young models, the different young models, such as IETF young models and OpenCovic young models, to different data plan APIs. So, all the translation layer are supported in plug-ins. So for example, if we want to translate the IETF young models to VPB APIs, so we have the IETF for VPB plug-ins. Also, for the OpenCovic, it's also the OpenCovic for VPB. And for DBDK, it's also the same IETF and to DBDK and IETF OpenCovic to DBDK, lots of things. And for the operating systems, currently we support different packages, such as the DBAN, SUZI, and IPM packages. And for hardware, we will support the CPU, memory, NIC, and IPsec, hardware, and FBGA, and Wi-Fi. So on the right side, it's the local control plan. So we will plan support three control plans. The one is the FR routing and the GGB for the routing demo. And the strong one is for the IKE control plan. And the top is used for the DPI. Okay, this is the software architecture. Actually, it contains three key parts. We will explain from the left to the right. On the left side, it supports three software interfaces. One is the GMI, and the GMI will contain two parts. One is GMI client, another is GMI server. GMI client will communicate with the GMI server through the GRPC protocol and the Google protocol buffer. And for the NetConf, it also has a client and a server. It will communicate to each other through the SSH protocol and the XML format. And for the GMI and the NetConf, it has been supported in sweetcom project. For the RESTConf, it's working progress. It will also support a client and the server. It will communicate through the HTTB or HTTPS and the ingestion format or XML format. In the middle piece is the data store engine. So we have leveraged the open source data store, the system project, which has three data stores, the startup data store, the running data store and the client data store, which is used to support the high availability. On the right side, it's a framework to connection with the data plan. So different plugins are supported here. For the flow progress, firstly, when you run the sweetcom project, it will run the accessible plugin demo and then the plugin demo will load the models from the startup, from the startup, the data store to the running data store. And then the accessible demo plugin and also will subscribe to the system engine. When customers configure their data through the SDN controller or orchestration, the data will go into the running data store and the candidate data store. When the running data store was notified a change, it will notify the accessible plugin to the change and the accessible plugin will configure the data plan through the low level APIs. Okay, this is for young models and network conf scenery. We have this picture. Actually, the network conf client will communicate with the network conf server through the network conf not in the base. Under the way, it's the SSH protocol and also it can support the XML or JSON format. For the network conf server, it will access as a accessible client. It will configure communication with the system engines through the Google protocol buffer and then all the young models will be stored in the data files. Besides the local applications, it also can leverage the Google protocol buffer to communicate with the system engine. Okay, we have two young models. One is the ITF. It's developed and maintained by the telecom vendors but the progress is very slow. So many service providers such as Google, Apple, Amazon, they think that the ITF young model definition progress is very slow. So they develop their own young models, so which is open configure young models. So far it has developed and defined more young models. So this is the picture that I have defined so far. As a result, they define the network in instance such as routing and PRS, service routing and also for interfaces, they also support the internet, the IP and the IPOE. And also they define some young models for the platform such as CPU fans and also other platform young models and also they define the ACR, QS and for the Wi-Fi and optical transport, they also define the young models. So this is for the open configure, they have their own northbound interface, which is the GMI, which for the GMI, it also has two parts, the client and the server. They communicate with each other through the GMI protocol. So for GMI server, it also acts as a accessible client and communicator with the accessible engine through the GBB. For the accessible engine and the data plan, it will communicate through the plug-in. Here is the open configure for VPP. You know for different operations such as the REST Conf, Net Conf or GMI, they have different commands and for different commands, they have different operations and actions. So this is the picture summary, all the actions and their touches. We will take the GMI as an example. For GMI, they have three commands, one is the subscribe, the second one is the set, the third one is the get. For the subscribe, it will subscribe the requirement to the configure data store. You can see this is the configure data store and also the subscribe the state to the data plan. Here is the data plan. And for the set, it will only have config. First, it will configure the data store and then configure it to the data plan. For the get, it will have different parameters such as get all, get config, get state and get an optional state. So for get config, it will get a configuration, items from the data store. For the state and the optional parameters, it will get the state from the data plan. This is, for the H, it will get some statics to from the data plan to the cloud. So here's the example we have set up to collect all the status from the data plan to the cloud. Initially, it will, the VPB is the data plan. It will stat all the parameters such as interface, statics and write it to the shared memory. And there is a VPB API exposed to the upper layer application. So here's the JPC server is running on the data plan cause. And it will retrieve all the status from the shared memory and push it up to the apply such as data collect in other host. And the data collect will also show this statics in the network management interface, such as the permissions, what's our project. Okay, this is the current key progress. This project is founded in last November. There are 15 committers from 12 organizations. So there are two organizations from USA, two from Europe and eight organizations from China. Actually, these 12 organizations covers a major system. So for the silicon vendors, they are Intel and XP. For the networking vendors, they are VGE, Cisco and Huawei. For telecom operators, they are China Mobile, China Unicom and China Telecom. For cloud providers, they are Tessence and Alibaba. For ODM vendors, they are Huazintiao and for IT server vendors, they are Teatro. So actually, even if it's created in last November, there are many customers that leverage it in their product right now. So we delivered our first release on this February and the second release on April. Actually, the next release, 90-08 release will be coming soon by the end of this month. Okay, this is the first release note. Actually, we have, in the first release, we have supported the two non-sponsored interfaces, the NetConf and GMI. And we also support one ITF young model that interface and the two open-fitting young models interface and the cloud team. We also supported the Tessence and Alibaba configuration, data store and operational data store. And we also configure the connection to VPP. So this is the next release note. In this release, we have supported the initialized GMI server and also supported the ITF net young models. And we also supported the high ability to health check. And besides that, we have refracted the code to clean up on some legacy code and reflect the build system. And another key part is we added the test framework to help improve the code quality. So we add a unit test and also add a doc environment to test the integration. So this is the SWITCOM leverage. We use CPE reference solution. Actually, this solution has been applied in deployment. So actually, there are four parts pieces in this UCP reference solution. For the first one is here. It's a UCP wide box reference design that's done in tele architecture. So there are some automteamers, BIOS, firmware and driver. It has supported the internet Wi-Fi, Wi-Fi, and voice. And for the second part, it's the UCP reference solution. It runs on the send OS and the KVM on the data plan. It has supported the DPP and the VPP 90.01 release. And here is the SWITCOM management agent. And on the third piece, it can run different way of use. On the fourth piece, it's the virtual CPE acts as a cloud gateway. So in the UCP SDK and the VCP, it can run the DPI. And for the last part, it's the SDN controller. So we can support the open delights or onus. So the SDN controller can configure the VPP through the NetConf and young models. Also, you can also, for the SDN controller, it can also run other sort of party, commercial SDN controllers. If only it can support the young models and the NetConf and REST Conf not supporting interfaces. Okay, this is the future work we're planning to do. The first one is the REST Conf in the phase support. Actually, it's the working progress and some code has been upstreamed for review right now. And we also support the power management. You know, for the DPP and the VPP, it's running in polling mode and it means the CPU are always running 100% even if no traffic in it. So we are introducing the power management to serve the power when the CPU is idle. And we're also working on the strengths when integration. The strengths when it's used for IK control plan to support the IP stack. And in future, we will support the routing demo integration and also support, you know, currently we just support the VPP data plan and we will plan to support the DPTK plan and also the Linux kernel plan. And support the more young models. We also support the integrated, the not in top for the DPI. Okay, this is the summary. We leveraged the sweetcom product to accelerate control plan with low resources and with high performance. It helped us to save more CPU costs and memory for data plan processing. And then we will provide the RESTConf GMI and also support the ITF young models and the config young models. For ITF young models, it will be used for telecom and for open config and GMI, it will be used for the cloud. Okay, actually, I will do a promotion for our new project. So just one minute. Actually, we plan to create a new project which is the UDPI project, which is universal and deep package in specification. It will be reviewed next Thursday and proposed to create it next week. So far, we have 13 organizations joined and 19 initial committers. So welcome. If you are interested, please join us. So currently, we have lots of organizations such as Intel, ZTE, China Telecom, Huazintel, INSPOR, YX-Link, CIFO, Tessent, China Telecom, Huawei, QingCloud, NetGate and Alibaba. So if you are interested in, please join us. Before next Thursday, it's Prova. So all the guys joined will be initial committers. Okay, thank you. Any questions? If you are interested in the SWEDCOM project, you can join this mail list. And we also have a work page about the SWEDCOM project. Thank you guys. Thank you.