A system framework and network architecture for edge virtual network functions
By adopting a three-tier architecture and a Sidecar traffic access mechanism, the resource management and traffic scheduling issues of the NaaS platform in multi-tenant scenarios are solved, enabling flexible network service chain deployment and isolation, and improving the platform's flexibility and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- COMP NETWORK INFORMATION CENT CHINESE ACADEMY OF SCI
- Filing Date
- 2026-03-12
- Publication Date
- 2026-06-16
Smart Images
Figure CN122226356A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of cloud computing technology, and in particular to a system framework and network architecture for edge virtual network functionality. Background Technology
[0002] Cloud computing, as a crucial foundation of modern information technology, is subtly influencing production across various industries and transforming human life. Through technologies such as virtualization and microservices, it constructs a resource control layer for unified management and scheduling of resources and tasks, centralizing dispersed resources into a resource pool and dynamically allocating them to applications on demand. In recent years, with the urgent need for digital transformation among enterprises, the application scenarios of cloud computing have continuously expanded, covering multiple levels from Infrastructure as a Service (IaaS) to Software as a Service (SaaS).
[0003] Traditional network architectures typically require significant capital investment and complex equipment maintenance, and their flexibility and scalability are often insufficient in dynamically changing market environments. Traditional network models, such as... Figure 1 As shown, enterprises urgently need efficient, flexible, and cost-effective solutions to meet their ever-growing network demands. Against this backdrop, Network as a Service (NaaS) has emerged, providing a new model for delivering network resources on demand through a cloud platform. NaaS enables enterprises to dynamically configure services such as network bandwidth, virtual private networks, firewalls, and traffic management based on real-time needs, thereby reducing hardware investment and maintenance costs. In this way, enterprises are no longer limited by fixed network architectures, enabling them to flexibly respond to business changes and quickly expand or shrink network resources. Simultaneously, enterprises do not need to manage and maintain their own network infrastructure, easily enjoying convenient and flexible bandwidth control, flexible networking, transmission optimization, security guarantees, and other network capabilities. Users can focus more on defining their own network needs and operational service outcomes.
[0004] Despite the numerous advantages offered by NaaS platforms, significant technical challenges remain. Current Network-as-a-Service platforms are often viewed as underlying infrastructure, providing only basic network communication capabilities and failing to offer tenants customized networking capabilities, thus struggling to meet their diverse and flexible networking needs. As the number of tenants increases, effectively controlling multi-tenant traffic, uniformly managing resources, and flexibly configuring services based on tenant networking strategies become critical issues. Summary of the Invention
[0005] The present application aims at the above-mentioned problems, and proposes a system framework and network architecture of edge virtual network function. The framework adopts a three-layer architecture of "service portal and operation system-service capability empowerment and dispatching center (referred to as service center)-POP (Point of Presence)": the upper layer (service portal and operation system) provides service systems such as portal management, operation and maintenance alarm, operation order, order delivery, and unifies identity authentication and permission management; the middle layer is the service capability empowerment and dispatching center, which provides core capabilities such as connection control, API gateway, multi-tenant management, service guarantee, identity authentication, policy issuing and unified third-party service interface; the bottom layer carries tenant business through multi-POP cluster resource management and agent system, and realizes efficient traffic scheduling and resource isolation in a multi-tenant environment in combination with service chain control, data / log collection and reporting, fault recovery and high-performance forwarding plane (such as DPDK / SmartNIC / SR-IOV). The architecture improves the flexibility, controllability and service quality guarantee capability of the NaaS platform in a multi-tenant scenario through a closed-loop mechanism of "policy generation-issuing-execution-feedback".
[0006] To achieve the above-mentioned purpose, the present application provides a system framework and network architecture of edge virtual network function. The present application realizes the automatic deployment and dynamic scheduling of network service chain in a multi-tenant scenario through unified service identification, cross-cluster resource scheduling strategy and Sidecar traffic access mechanism. It is used to solve the technical problems of NaaS platform in resource management, traffic scheduling and multi-tenant isolation. It is used to solve the technical problems of NaaS platform in resource management, traffic scheduling and multi-tenant isolation.
[0007] The overall architecture of the platform is composed of a portal management center, a service capability empowerment and dispatching center, and multiple POP clusters. The portal management center provides a unified portal for users, operation and maintenance, operation and service providers, including portal management, operation and maintenance alarm, operation order, order delivery and unified identity authentication; the service capability empowerment and dispatching center is responsible for connection control, API gateway, tenant management, service guarantee, identity authentication, multi-cluster resource scheduling strategy issuing and third-party interface unification; the POP cluster is responsible for service chain orchestration and operation of the NFV network function pool, and completes tenant business carrying in combination with monitoring and operation, resource scheduling and high-performance forwarding plane.
[0008] After a tenant registers through a portal, the tenant obtains a Universally Unique Identifier (UUID) and submits a network service subscription or deployment request in a service management interface. A middle platform generates a scheduling strategy based on tenant demand and resource status and issues the scheduling strategy to a target POP cluster; the POP cluster executes service deployment and writes service UUID, service type, name, and service address information into a service database, providing a basis for subsequent flow table configuration.
[0009] In terms of multi-tenant isolation, the platform uses Virtual Private Cloud (VPC), namespace, and tunnel technology to achieve network isolation, and uses a multi-tenant plug-in to automatically splice tenant UUID conditions in SQL queries to achieve data isolation at the data layer. The platform distinguishes between business networks and management networks, and the two are isolated from each other; the management network is built based on OVS (OpenvSwitch), and tenant gateways achieve internal and external network access of services through EIP / NAT.
[0010] Key innovations of the platform include the synergy of a DP flow device, a Sidecar container, and a flow table configuration engine: the flow table engine is deployed inside the DP flow device, reads information from the service database after successful service deployment to build a network table and issue OVS rules, completes service mesh construction and performs connectivity detection, and triggers re-linking in the event of an exception. The DP flow device splits and back-announces tenant traffic according to source / destination IP, and each tenant corresponds to an OVS bridge on the DP flow device and accesses at least two network interfaces to form a stable service mesh; the Sidecar shares a network namespace with tenant services and achieves service mesh and tenant traffic isolation through VXLAN tunnels, with VNI using a tenant unique ID and REMOTE_IP obtained from the service database to avoid conflicts.
[0011] Through the above mechanisms, the application realizes controllable traffic orchestration, resource elastic allocation, and performance guarantee in a multi-tenant scenario, improving the flexibility, scalability, and user experience of the NaaS platform. BRIEF DESCRIPTION OF DRAWINGS
[0012] In order to more clearly illustrate the technical solutions of the multiple embodiments disclosed in the specification, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only a part of the embodiments disclosed in the specification, and other drawings can also be obtained by those skilled in the art without creative labor.
[0013] Figure 1 Traditional network architecture and service-oriented network architecture schematic diagram;
[0014] Figure 2A platform overall architecture schematic diagram is provided for the embodiment of the present application.
[0015] Figure 3 A system framework schematic diagram of the edge virtual network function is provided for the embodiment of the present application.
[0016] Figure 4 A network architecture schematic diagram of the edge virtual network function is provided for the embodiment of the present application.
[0017] Figure 5 A POP cluster initialization flowchart is provided for the embodiment of the present application.
[0018] Figure 6 A tenant request response system flowchart is provided for the embodiment of the present application.
[0019] Figure 7 A service provider registration flowchart is provided for the embodiment of the present application.
[0020] Figure 8 A service provider deregistration flowchart is provided for the embodiment of the present application.
[0021] Figure 9 A service provider service onboarding flowchart is provided for the embodiment of the present application.
[0022] Figure 10 A service provider service offboarding flowchart is provided for the embodiment of the present application.
[0023] Figure 11 A sidecar container structure schematic diagram is provided for the embodiment of the present application.
[0024] Figure 12 A sidecar mode service network schematic diagram is provided for the embodiment of the present application.
[0025] Figure 13 A DP shunt structure schematic diagram is provided for the embodiment of the present application.
[0026] Figure 14 A hardware architecture schematic diagram is provided for the embodiment of the present application. DETAILED DESCRIPTION
[0027] The present specification will be further described in conjunction with the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related application, and not to limit the application. The described embodiments are only part of the embodiments of the present specification, not all embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor are within the scope of the present application.
[0028] Figure 2 A platform overall architecture schematic diagram is provided for the embodiment of the present application. As shown in the figure, Figure 2As shown, the platform's overall architecture consists of a portal management center, a business capability empowerment and scheduling platform, and multiple POP clusters. The portal management center provides a unified entry point for users, operations, maintenance, and service providers, including portal management, operations alarms, operations work orders, order delivery, and unified identity authentication capabilities. The business capability empowerment and scheduling platform is responsible for connection control, API gateway, tenant management, business assurance, identity authentication, multi-cluster resource scheduling policy distribution, and unified third-party interface. The POP clusters are responsible for service chain orchestration and the operation of the NFV network function pool, combining monitoring and operations, resource scheduling, and a high-performance forwarding plane to complete tenant business carrying.
[0029] The NaaS cloud computing platform of this invention adopts a bare metal architecture and provides high-performance computing and network services for multi-tenant scenarios. The platform consists of a management and control center, a business middleware platform, and multiple POP clusters. Each POP cluster contains at least 4 x86 architecture physical servers and 2 high-performance physical switches, forming a highly reliable and scalable computing and network resource pool; each physical server is equipped with multiple high-speed network cards to meet the requirements of high bandwidth and low latency network connectivity.
[0030] Figure 3 This is a schematic diagram of the system framework for an edge virtual network function provided in an embodiment of the present invention. For ease of explanation, only a typical scenario of one tenant and one POP cluster is described.
[0031] like Figure 3 As shown, the control center includes a tenant management module and a business interaction module. The tenant management module is responsible for tenant registration, identity authentication, lifecycle management, and access control, and generates a unique tenant identifier (UUID). The business interaction module is responsible for accepting tenant service subscription, change, and configuration requests, verifying and recording requests, and submitting business requests to the business middle platform for processing.
[0032] The business capability empowerment and scheduling platform comprises a business logic processing module and a resource scheduling module. The business logic processing module parses tenant requests to form service links and policy schemes (including required network function combinations, traffic governance rules, bandwidth and latency targets, etc.); the resource scheduling module completes resource matching and allocation based on the resource status and load of each POP cluster, and generates scheduling decisions to be sent to the target POP cluster.
[0033] The POP cluster includes a service chain orchestration / resource allocation module and specific network function services (vAF, vAC, vDPI, IPS). The service chain orchestration module is responsible for service instance deployment, link organization, and resource allocation. Each service instance is equipped with a Sidecar container to handle traffic access, forwarding, and policy enforcement. The cluster data plane employs high-performance forwarding and hardware acceleration technologies such as DPDK / SmartNIC / SR-IOV, combined with CPU and NUMA optimizations to improve forwarding performance and stability.
[0034] After tenant business traffic enters the POP cluster from the tenant's internal network, the service chain orchestration module decides which service chain to enter. The traffic then passes through the Sidecar to network function services such as vAF / vAC / vDPI / IPS for processing and back-injection, finally being forwarded to the tenant's destination address. To ensure multi-tenant isolation and security, the platform uses VPC / namespace isolation and tunneling technologies (such as VXLAN) to achieve traffic isolation between tenants; the Sidecar shares the network namespace with the services and executes isolation policies, thereby ensuring that traffic from different tenants does not interfere with each other.
[0035] Through the above implementation methods, the embodiments of the present invention achieve controllable traffic orchestration, elastic resource allocation, and performance assurance in multi-tenant scenarios, thereby improving the platform's flexibility, scalability, and user experience.
[0036] Figure 4 This is a schematic diagram of a network architecture for an edge virtual network function provided in an embodiment of the present invention. Figure 4 As shown, the framework network layer of this embodiment includes two network architectures: a management network architecture and a service network architecture. These two are isolated from each other and are used for platform management and tenant service traffic processing, respectively.
[0037] The management network architecture is built on OVS (Open vSwitch) and OVN (Open Virtual Network). OVS is responsible for high-speed forwarding of the data plane, while the OVN controller is responsible for the logical control plane, realizing centralized management and scheduling of network resources.
[0038] In this implementation, the POP cluster uses VPCs and namespace isolation to build a multi-tenant network. Each tenant corresponds to a VPC, which exists as a logical router (LR) in OVN; each VPC can contain multiple virtual subnets, and each subnet corresponds to a logical switch (LS). Subnets within the same VPC can communicate with each other; different tenants are isolated through LR configuration. To meet the service's internal and external network access requirements, the platform configures a gateway for each tenant and uses, but is not limited to, EIP and NAT technologies to enable external access and outbound network capabilities.
[0039] The business network architecture adopts a service mesh-based architecture, using a sidecar proxy pattern to achieve fine-grained management of tenant business traffic. This architecture includes a DP traffic splitter and a sidecar container. For example... Figure 4 As shown, after entering the service traffic inlet, business traffic first enters the DP splitter, which dynamically determines the transmission path and processing method of the traffic based on business needs. Subsequently, the traffic enters the service area where the "service subscribed to by the tenant" resides, and traffic access and policy enforcement are completed through the Sidecars of each service instance. The processed traffic is then reinjected by the DP splitter and forwarded from the service traffic outlet. The Sidecar container is deployed inside the service, sharing the same network namespace with the service, and establishes a connection with the DP splitter through a VXLAN tunnel, forming a service mesh, thereby achieving traffic isolation and controllable forwarding between tenants. The DP splitter can maintain stable forwarding capabilities under high load conditions, and does not affect the tenant's normal internet access needs during the platform's takeover of tenant traffic.
[0040] The aforementioned system framework and network framework constitute the service framework of this embodiment of the invention. The portal management center provides business entry and operation management, while the business capability empowerment and scheduling platform is responsible for global resource management and the distribution of scheduling policies between POP clusters. The POP cluster, as the core computing resource layer, executes service deployment and carries tenant business traffic according to the platform's policies.
[0041] The POP cluster initialization process is as follows: Figure 5 As shown. After the process begins, the POP cluster sends a heartbeat / registration request via cAgent, carrying the key. The request is processed by the control center and the business platform to obtain and verify the key, and then proceeds to the "verification passed" judgment node; if it fails, it returns a registration failure and ends the process. If the verification passes, the POP cluster is ready to go online and participate in resource scheduling. Then, cluster initialization is performed: First, the cluster control system is initialized, which includes the Kubernetes native control system (responsible for basic orchestration and resource management) and the service chain orchestration control system (responsible for service chain and network function orchestration); second, cluster resources are initialized, and resources are configured and managed according to category, including but not limited to computing resources (CPU / GPU / memory), storage resources (local disk / distributed storage volume), network resources (bandwidth / network card / VPC / subnet), etc. After completion, the process ends and enters a state where it can support services.
[0042] After the POP cluster initialization is complete, the system needs to ensure that registered tenants can dynamically allocate the resources required by the POP cluster. To achieve this, the POP cluster uses a central scheduling engine developed based on the Go language. This system can intelligently and flexibly allocate computing resources, network bandwidth, storage resources, etc., according to tenant needs and the current resource status of the POP cluster. The system also supports automatic deployment of tenant services: when a tenant initiates a service deployment request, the management center and business platform will call the system's deployment interface to automatically complete the service deployment configuration. In addition, the central scheduling engine also supports real-time expansion and reclamation of resources to cope with sudden traffic peaks or meet the ever-changing resource needs of tenants, making the platform more flexible and adaptable. The POP cluster receives tenant registration and service subscription requests, automatically determines the legality of the request, creates Virtual Private Cloud (VPC) and subnet resources for legal registration requests, and stores tenant information in the database. For legal subscription service requests, the system retrieves tenant information from the database and automatically orchestrates business traffic according to the service type, thereby achieving rapid configuration of the network environment. The response process for ordinary tenant requests is as follows: Figure 6 As shown, when the platform receives a tenant request, it determines the validity of the request and executes the corresponding process (service subscription, service update, custom configuration, etc.) based on the tenant's request type. Simultaneously, the platform also records tenant information, such as the tenant UUID and request type. The recorded tenant UUID is a unique ID that distinguishes each tenant, and it also serves as the VNI value for the corresponding tenant's VXLAN tunnel, enabling features such as multi-tenant traffic isolation.
[0043] Meanwhile, the platform configures different execution processes for different user roles. In addition to the tenant response process mentioned above, the following details the processes for service provider registration, deregistration, service listing, and service delisting. Service providers submit registration requests through the platform entry point, such as... Figure 7 As shown, users need to fill in basic information including company name, contact person, and business type, and upload necessary qualification documents (such as business license, industry certifications, etc.). The platform verifies the submitted information using third-party authentication services or internal audit mechanisms. After approval, the platform generates a unique identity key for the service provider, used for subsequent authentication and access control, and distributes the key through a secure channel. The platform allocates resource permissions according to the service provider's business needs and opens relevant service interfaces, providing functional support such as access resource allocation modules and service listing modules.
[0044] The service provider submits a cancellation request through the platform management interface, such as Figure 8As shown, fill in the reason for cancellation and confirm your identity information. After the platform confirms the legitimacy of the cancellation request through multiple verification mechanisms (such as identity key verification and two-factor authentication), it initiates the cancellation process. First, the platform notifies the associated tenants and service consumers and provides necessary migration or alternative solutions. Subsequently, the platform clears the service provider's resource usage, including canceling its allocated computing, storage, and network resources, and revoking its access permissions and authentication keys. Finally, the platform generates a cancellation report, archives relevant information for auditing, and confirms the completion of cancellation to the service provider through a secure channel.
[0045] Service providers fill out a service listing form on the platform, such as Figure 9 As shown, submissions include the service name, description, technical specifications, pricing model, and Service Level Agreement (SLA), along with the upload of the container image and runtime environment description. The platform performs a security scan on the submitted content, verifies its compatibility, and then automatically deploys it to the test environment for functional verification and performance evaluation. After testing, the platform generates a test report, which is then comprehensively evaluated by reviewers. Services that pass the review are officially listed in the service repository for tenants to choose from. After service listing, the platform continuously monitors the service's operational status, collects performance data and user feedback, and supports service providers in dynamically adjusting service configurations and optimizing operational strategies.
[0046] Service provider login platform service management module, such as Figure 10 As shown, users select the service to be decommissioned and submit a decommissioning application, filling in the reason for decommissioning and the planned decommissioning time. After the platform verifies the decommissioning application, it notifies the tenants and consumers currently using the service and sets a reasonable transition period to ensure business continuity. After the transition period ends, the platform removes the service from the service repository and terminates resource allocation to it. The service's operational status will be transferred to backup storage for auditing and historical querying, and then related resources will be released. The platform generates a service decommissioning report, provides feedback to the service provider, and updates system records to ensure data consistency.
[0047] After the tenant service is deployed, tenant business traffic needs to be redirected to a designated service link. An innovation of this invention lies in using the Sidecar pattern to construct the business network architecture, achieving fine-grained traffic management and controllable forwarding. The Sidecar service network structure is as follows: Figure 12 As shown, the system divides the service network into two parts: "service instances" and "Sidecar containers". The Sidecar containers are responsible for building the service network architecture, while the service instances run the functional logic of the services subscribed to by the tenants.
[0048] Sidecar containers are used to provide high-speed packet processing and control forwarding capabilities. Their structure is as follows: Figure 11As shown, the container contains virtual switching and tunnel endpoint capabilities, and connects to two ports of the DP splitter via net1 and net2, respectively for tenant traffic inflow and outflow. The two tunnel endpoints establish virtual tunnels with the DP splitter to achieve packet encapsulation and decapsulation. To ensure internal traffic consistency between the Sidecar and the tenant service, the Sidecar and the service share the same network namespace. The Sidecar is deployed as a component of a Pod; each tenant service can be equipped with one or more Sidecar containers, and different network functions can be configured as needed.
[0049] Since Sidecar needs to access multiple networks, the platform uses multi-NIC plugins (such as Multus-CNI) for network connection management; at the same time, it combines DP splitters and flow table policies to achieve tenant-level traffic isolation, path control, and service link orchestration. Practice shows that this solution maintains low resource overhead while ensuring high throughput and low latency, demonstrating the engineering advantages of high performance and lightweight design.
[0050] Because the flow table rules of the aforementioned Sidecar container are relatively scattered, traffic policy management is complex, necessitating unified management of the flow tables. A key innovation of this invention lies in the introduction of a traffic policy management system based on a DP splitter. This system allows the services of various tenants to be integrated into a large service network, such as... Figure 12 As shown, each service in the service network is equipped with a corresponding Sidecar container, and each Sidecar container is managed uniformly by the DP traffic splitter. This architecture forms a tenant-oriented business service network, dedicated to the efficient management of tenant business traffic, and realizes centralized control and optimization of traffic policies.
[0051] One implementation of the DP traffic splitter is to deploy it as a Pod within a POP cluster. First, build an image containing Open vSwitch, and then deploy the DP traffic splitter within the cluster based on this image. During deployment, ensure the DP traffic splitter has three network interface cards (NICs): one to receive all tenant traffic and direct it into the cluster, one to forward tenant traffic to the external network, and another to build a VXLAN tunnel with the Sidecar container. When building the VXLAN tunnel, the corresponding VNI and REMOTE_IP values need to be configured. The specific DP traffic splitter structure is as follows... Figure 13 As shown, the main bridge br0 carries the business traffic of all tenants; ovs-br1 and ovs-brn are the tenants' private bridges (n is the tenant's unique ID), which are responsible for building VXLAN tunnels with the Sidecar container and configuring the corresponding service chain orchestration rules to support the tenants' personalized service needs.
[0052] The traffic policy management system, developed using the Go programming language, operates as follows: First, after a tenant successfully deploys its service, a flow table construction process is triggered. This process retrieves relevant information about the tenant and its services to determine if flow table configuration is necessary. If flow table construction is required, the system builds a VXLAN tunnel based on the IP-port mapping. Next, the corresponding traffic policy is issued, and the connectivity of the constructed tunnel is checked. If the tunnel is connected, the corresponding flow table policy is persistently written to a MongoDB database. If the tunnel is not connected, the connectivity of the corresponding service IP address is further checked. If the service IP address is connected to the DP splitter, the flow table rules are reissued, and connectivity is checked again. Otherwise, the service deployment fails, and the deployment process is restarted.
[0053] Regarding the design of the platform infrastructure, the NaaS cloud computing platform of this embodiment is built on a bare metal architecture, aiming to provide superior computing and network service performance in a multi-tenant environment. The platform design includes a centralized management and control center and multiple POP clusters. Each POP cluster consists of at least 4 high-performance physical servers with x86 architecture and 2 high-reliability physical switches, forming a computing and network resource pool with high reliability and scalability.
[0054] To meet the platform's stringent requirements for high bandwidth and low latency network connectivity, each physical server is equipped with multiple high-speed network interface cards (NICs) and supports multi-link aggregation to enhance network availability. The physical topology of the POP cluster is as follows: Figure 14 As shown, tenant service traffic flows in and out through Layer 2 switches. The design places particular emphasis on link redundancy; some network interface cards (NICs) use bonding technology to bundle two network ports together, ensuring high availability and fault tolerance of the link transmission.
[0055] In addition, the data physical switch handles all traffic except for tenant traffic within the cluster, while also providing cross-cluster network interconnection capabilities for the platform. To optimize cluster performance, the design also strictly isolates computing and storage resources, equipping them with independent storage devices to ensure the efficiency of storage services and the overall stability of the cluster operation.
[0056] This architecture, through efficient resource scheduling and network management strategies, not only provides stable and secure services for businesses in a multi-tenant environment, but also flexibly responds to diverse business needs, demonstrating outstanding high performance and reliability.
[0057] The physical server is configured with the following technical features:
[0058] I. Network Interfaces: Each server is equipped with multiple high-speed network cards, including: a) two 4×100Gbps network cards, serving as the data plane interface and the service plane interface respectively; b) multi-network card bonding is achieved through Link Aggregation Group (LAG) technology; c) physical link redundancy is achieved using Bonding technology, supporting primary / standby / load balancing modes.
[0059] II. System Optimization:
[0060] BIOS layer: Enable IOMMU virtualization support;
[0061] Operating system: Deploy a custom Rocky Linux 9 kernel, enabling HugePage and NUMA architecture optimizations;
[0062] Driver layer: Install the DPDK acceleration framework and dedicated network card driver.
[0063] As attached Figure 14 As shown, the network topology of the POP cluster has the following innovative design:
[0064] 1. Switching architecture:
[0065] The core switches are interconnected via 4×100Gbps optical fibers and a non-blocking switching matrix is constructed using MLAG (Multi-chassis Link Aggregation) technology.
[0066] Configure STP / RSTP protocol to achieve loop protection, with a convergence time of <1s;
[0067] 2. Traffic path:
[0068] Tenant service traffic is transmitted directly through the Layer 2 switching plane;
[0069] Control traffic is transmitted through a dedicated VLAN channel;
[0070] 3. Reliability Mechanism:
[0071] All critical links are protected with 1+1 redundancy.
[0072] Single-link fault switching time ≤ 50ms.
[0073] This invention aims to address the technical challenges of current Network as a Service (NaaS) platforms in resource management, traffic scheduling, and multi-tenant environments. The platform's core architecture comprises a portal control center, a business capability empowerment and scheduling platform, and multiple POP clusters. Through dynamic resource scheduling and a strict tenant isolation mechanism, it achieves efficient deployment and management of network services. The platform employs innovative technologies such as Virtual Private Cloud (VPC), namespace isolation, flow table engine, DP splitter, and Sidecar containers, combined with service chain orchestration, NFV network function pools, and a high-performance forwarding plane, to build a stable service model and ensure traffic isolation and resource independence between different tenants. Through VXLAN tunnel construction, CPU binding, memory limiting, and multi-tenant data isolation strategies, it enhances the flexibility, security, and scalability of network services. Simultaneously, the platform designs a dual-network architecture for business and management networks and supports external network access to internal services, such as EIP and NAT, fully meeting the needs of multi-tenants for efficient, secure, and dynamic network services, thereby optimizing user experience and business efficiency.
[0074] The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of the multiple embodiments disclosed in this specification. It should be understood that the above description is only within the scope of this specification. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the multiple embodiments disclosed in this specification should be included within the protection scope of the multiple embodiments disclosed in this specification.
Claims
1. A system framework for edge virtual network functionality, characterized in that, include: The system includes a portal control center, a business capability empowerment and scheduling platform, and multiple POP clusters; among them, The portal management center includes a tenant management module and a business interaction module. The tenant management module is responsible for tenant registration, identity authentication, lifecycle management and access control, and generates a unique tenant identifier (UUID). The business interaction module is responsible for accepting tenant service subscription, change and configuration requests, completing request verification and recording, and submitting business requests to the business middle platform for processing. The business capability empowerment and scheduling platform includes a business logic processing module and a resource scheduling module. The business logic processing module parses tenant requests to form service links and strategy schemes. The resource scheduling module completes resource matching and allocation based on the resource status and load of each POP cluster, and generates scheduling decisions to be sent to the target POP cluster. The POP cluster includes a service chain orchestration / resource allocation module and specific network function services; the service chain orchestration module is responsible for service instance deployment, link organization and resource allocation; each service instance is equipped with a Sidecar container to realize traffic access, forwarding and policy execution; After registering through the portal, tenants obtain a universally unique identifier (UUID) and submit network service subscription or deployment requests on the service management interface. The business capability empowerment and scheduling platform generates scheduling policies based on tenant needs and resource status and distributes them to the target POP cluster. The POP cluster executes service deployment and writes the service UUID, service type, name, and service address information into the service database, providing a basis for subsequent flow table configuration.
2. The system framework according to claim 1, characterized in that, The POP cluster is specifically used for: The cAgent sends a heartbeat / registration request along with a key; the control center and the business platform respectively complete the key acquisition and verification, and then proceed to the "verification passed" judgment node; if it fails, the registration failure is returned and the process ends. If the verification passes, the POP cluster is marked as ready to go online and participate in resource scheduling. Then, cluster initialization is performed: first, the cluster control system is initialized, which includes the Kubernetes native control system and the service chain orchestration control system; second, the cluster resources are initialized, and the resources are configured and managed according to their categories, including but not limited to computing resources, storage resources and network resources. After completion, the process ends and the cluster enters a state where it can support business.
3. The system framework according to claim 1, characterized in that, The POP cluster uses a central scheduling engine, and the system flexibly allocates computing resources, network bandwidth, and storage resources according to tenant needs and the current resource status of the POP cluster. as well as The system also supports automatic deployment of tenant services: when a tenant initiates a service deployment request, the management center and business platform will call the system's deployment interface to automatically complete the service deployment configuration; as well as, The central scheduling engine also supports real-time expansion and recycling of resources to cope with sudden traffic spikes or meet the ever-changing resource needs of tenants, making the platform more flexible and adaptable.
4. The system framework according to claim 1, characterized in that, The POP cluster receives registration and subscription service requests from tenants, automatically determines the legitimacy of the requests, creates virtual private cloud and subnet resources for legitimate registration requests, and stores tenant information in the database. For legitimate subscription service requests, the system will retrieve tenant information from the database and automatically orchestrate business traffic according to the service type, thereby achieving rapid configuration of the network environment. For ordinary tenant requests, the platform will determine the legitimacy of the request upon receiving it and execute the corresponding process according to the tenant's request type. At the same time, the platform also needs to record the tenant's information, including the tenant's UUID and request type. The recorded tenant UUID is a unique ID that distinguishes tenants. At the same time, the UUID also serves as the VNI value of the corresponding tenant's VXLAN tunnel to achieve features such as multi-tenant traffic isolation.
5. The system framework according to claim 1, characterized in that, Service providers submit registration requests through the platform, filling in basic information including company name, contact information and business type, and uploading necessary qualification certificates. The platform uses third-party authentication services or internal audit mechanisms to verify the submitted information. After the audit is passed, the platform generates a unique identity key for the service provider for subsequent authentication and access control, and distributes the key through a secure channel. The platform allocates resource permissions according to the service provider's business needs and opens relevant service interfaces to provide access to resource allocation modules and service listing modules.
6. The system framework according to claim 1, characterized in that, The service provider submits a cancellation application on the platform management interface, fills in the reason for cancellation and confirms its identity information; after the platform confirms the legality of the cancellation request through multiple verification mechanisms, it initiates the cancellation process; first, the platform notifies the associated tenants and service consumers and provides the necessary migration or alternative solutions. Subsequently, the platform cleans up the service provider's resource usage, including canceling its allocated computing, storage, and network resources, and revoking its access permissions and authentication keys. Finally, the platform generates a cancellation report, archives relevant information for auditing purposes, and confirms the cancellation completion to the service provider through a secure channel.
7. The system framework according to claim 1, characterized in that, Service providers fill out a service listing form on the platform, submitting information including the service name, description, technical specifications, pricing model, and service level agreement, as well as uploading container images and runtime environment descriptions. The platform performs a security scan on the submitted content, verifies its compatibility, and then automatically deploys it to the test environment for functional verification and performance evaluation. After the test is completed, the platform generates a test report, which is then comprehensively evaluated by reviewers. Services that pass the review will be officially listed in the service repository for tenants to choose from. After a service is launched, the platform continuously monitors its operational status, collects performance data and user feedback, and supports service providers in dynamically adjusting service configurations and optimizing operational strategies.
8. A network architecture for edge virtual network functionality, applied to the system framework as described in claims 1 to 7; characterized in that, include: Management network architecture and business network architecture; The two are isolated from each other and are used for platform management and tenant business traffic processing, respectively. The management network architecture is built on OVS and OVN. OVS is responsible for high-speed forwarding of the data plane, while the OVN controller is responsible for the logical control plane, enabling centralized management and scheduling of network resources. The POP cluster uses VPCs and namespace isolation to build a multi-tenant network, with each tenant corresponding to one VPC. VPCs exist as logical routers in OVN. Each VPC can contain multiple virtual subnets, and each subnet corresponds to a logical switch. Subnets within the same VPC can communicate with each other. Isolation between different tenants is achieved through LR configuration. The business network architecture adopts a service mesh-based architecture and uses the Sidecar proxy pattern to achieve fine-grained management of tenant business traffic; the architecture includes a DP splitter and a Sidecar container. After entering the service traffic inlet, the service traffic first enters the DP splitter, which dynamically determines the transmission path and processing method of the traffic according to the service requirements. Then the traffic enters the service area where the "service subscribed by the tenant" is located, and the traffic access and policy execution are completed by the Sidecar of each service instance. The processed traffic is then injected back by the DP splitter and transferred out from the service traffic outlet. The Sidecar container is deployed inside the service, shares the same network namespace with the service, and establishes a connection with the DP splitter through a VXLAN tunnel to form a service mesh, thereby realizing traffic isolation and controllable forwarding between tenants.
9. The network architecture according to claim 8, characterized in that, The DP traffic splitter is deployed as a Pod within the POP cluster. First, an image containing Open vSwitch is built, and the DP traffic splitter is deployed in the cluster based on this image. During deployment, ensure that the DP traffic splitter has three network interface cards (NICs): one for receiving all tenants' service traffic and introducing it into the cluster, one for forwarding tenant traffic to the external network, and another for building a VXLAN tunnel with the Sidecar container. When building the VXLAN tunnel, the corresponding VNI and REMOTE_IP values need to be configured.
10. The network architecture according to claim 9, characterized in that, A traffic policy management system based on DP splitter was introduced. The overall process of the traffic policy management system is as follows: First, after a tenant successfully deploys the corresponding service, the flow table building process will be triggered, and relevant information about the tenant and its services will be retrieved to determine whether a flow table needs to be configured. If a flow table needs to be built, the system will set up a VXLAN tunnel based on the mapping relationship between IP and port; then, it will issue the corresponding traffic policy and check the connectivity of the constructed tunnel. If the tunnel is connected, the corresponding flow table policy is written to the MongoDB database for persistent storage; if the tunnel is not connected, the connectivity of the corresponding service IP address is further determined. If the service IP address can connect to the DP splitter, then reissue the flow table rules and check connectivity again; Otherwise, return a service deployment failure message and restart the corresponding service deployment process.