CN107171953B - Virtual router implementation method - Google Patents
Virtual router implementation method Download PDFInfo
- Publication number
- CN107171953B CN107171953B CN201710365654.8A CN201710365654A CN107171953B CN 107171953 B CN107171953 B CN 107171953B CN 201710365654 A CN201710365654 A CN 201710365654A CN 107171953 B CN107171953 B CN 107171953B
- Authority
- CN
- China
- Prior art keywords
- vfe
- vce
- intraport
- virtual
- port
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/58—Association of routers
- H04L45/586—Association of routers of virtual routers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a virtual router implementation method, which solves the problem of forwarding part bottleneck in virtualization. All external ports in the virtual router are centralized on the switching component, and the design has the advantages that: when the virtual router uses a plurality of forwarding elements to meet the requirement of the packet processing capacity of the virtual network, the packet forwarding between any two ports in the virtual router can not occur, and the situation that the data packet passes through two forwarding elements in a serial mode can not occur any more; the switching component will distribute the packets to both forwarding elements for parallel processing, in which case the forwarding rate of the virtual router is equal to the sum of the forwarding rates of the two forwarding elements.
Description
Technical Field
The invention belongs to the technical field of network communication, and particularly relates to a virtual router implementation method.
Background
Computer networks are typically comprised of a large number of routers, switches, and network middleware that vary in functionality. In order to effectively manage a network, an administrator makes various policies based on the traffic (e.g., video, language, Web, etc.) carried by the current network, and due to the lack of available tools, the administrator needs to manually translate these high-level policies into low-level configuration commands that are recognizable by network devices, which is challenging and highly error-prone.
Another difficulty that has been almost impossible for network practitioners and researchers to overcome is the "rigidity" of the internet. The huge deployment scale of the internet enables the internet to become a key infrastructure in the society, the continuous expansion of the deployment scale is accompanied by the increasing difficulty in the evolution and the revolution of the internet, and the internet designed for solving the basic interconnection problem in decades is increasingly careless in the face of the current day-to-day variation.
In the background, a programmable network represented by IETF ForCES (Forwarding and Control separation, ForCES) is proposed as a means for promoting network evolution. Software Defined Networking (SDN) is a new form of programmable Network, providing a new Network architecture. The SDN is expected to fundamentally solve the problem of internet 'rigidness' by separating a forwarding plane and a control plane in a network and aiming at simplifying network management and supporting network innovation and evolution.
Network virtualization is the basis for realizing network programmability by a forwarding and control separation technology, and all the network virtualizations are always the objects of great interest to researchers.
As an advocate for the idea of separation of forwarding and control, IETF ForCES is a new network device architecture proposed for breaking the black-box phenomenon of a single network device at first. According to the definition of IETF ForCES, a Network Element (NE) (network node in general) is formed by combining a Control Element (CE) and a plurality of Forwarding Elements (FEs), and the combination relationship can be set in a software-defined manner. ForceSene de-emphasizes the geographic location and physical morphology of CEs and FEs, in other words NE is a logical concept, if the function performed by NE is a Router, then the Router is a Virtual Router (VR), which is not in mind with node virtualization in network virtualization research.
Applying Virtual machine technology to the virtualization of the CE and the FE, generating a plurality of CE Virtual machines and FE Virtual machines on top of the CE and FE physical machines, the CE Virtual machines and the FE Virtual machines being Virtual control elements (Virtual CE, vCE) and Virtual forwarding elements (Virtual FE, vFE), respectively, and these vces and vFE in combination with each other constituting a plurality of vnes (Virtual NE, vNE). As previously described, if the functions implemented by these vnes are routers, then multiple VRs will be present in one NE. Since the vces and vFE that make up the vnes are isolated from each other, multiple vnes within the same NE are also isolated from each other.
When multiple virtual networks need to be run simultaneously on top of one NE, the NE may assign a dedicated VR (i.e., vNE) to each virtual network, and these VRs isolated from each other ensure isolation between the virtual networks.
However, in the conventional ForCES router, the external ports are distributed on the FEs, and the original port distribution mode in the virtualization process may cause the problem of "FE bottleneck". The so-called "FE bottleneck" problem refers to: when multiple vFE are used by the VR to meet the packet processing capability requirements of the virtual network, to achieve packet forwarding between the external ports of two of the vFE (i.e., the two ports of the VR), the data packet will traverse the two vFE in a "serial" fashion, with the final packet forwarding rate depending on the vFE, which is the smaller forwarding rate, thus making the VR unable to provide the desired packet processing capability at all.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provides a virtual router implementation method.
The purpose of the invention is realized by the following technical scheme: a virtual router implementation method comprises the following steps:
each Virtual Router (VR) in the step (1) consists of a virtual controller (vCE) and a plurality of virtual repeaters (vFE), wherein the vCE runs a routing protocol and maintains a routing table, and vFE performs routing table lookup and output port determination on a data packet;
the vces and vFE are both virtual machines on a physical machine, and the vces and vFE belonging to the same VR may be located on different physical machines. vFE the processing capacity of the data packet is determined by the amount of CPU and memory of the virtual machine in which it is located;
all data packets entering and exiting the VR in the step (2) are scheduled through a Switching Element (SE);
the SE is a multi-port switch, ports on the SE are divided into an external port (extraPort) and an internal port (intraPort), the intraPort is used for communication between vCE and vFE and between vFE and vFE, and the extraPort is used for input and output of data packets entering and exiting VR; the SE maintains a virtual mapping relation table (vMap) of VR → vCE → vFE, each line of the vMap table represents a virtual mapping relation of VR, and the vMap table consists of five parts, namely VR-vCE-vFE, intra port from vCE to SE, and intra port from vFE to SE;
step (3) when a data packet (P1) enters SE, checking the input port of P1, if the input port is an extraPort, entering step (4); if the input port is an intraPort, entering the step (5);
step (4) SE checks the destination address of the data packet P1, if the destination address of P1 is vCE, SE searches vMap tableDetermining IntraPort (INTRAPort) of vCE to SEi) Through intraPortiDirectly send P1 to vCE; otherwise, the SE looks up the vMap table, selects vFE with light load (vFE)j) While determining vFEjIntraPort to SEj) Through intraPortjDirectly send P1 to vFEj；
Step (5) SE checks the source and destination addresses of packet P1, if the source address is vCE and the destination address is vFE (vFE)k) SE lookup vMap Table determination vFEkIntraPort to SEk) Through intraPortkDirectly send P1 to vFEk(ii) a If the source address is vCE and the destination address is another VR, SE will select an extraPort to send P1 according to the external port label carried by P1; if neither the source address nor the destination address is any of vCE and vFE, SE will select an extraPort to send P1 according to the external port label carried by P1; if the source address is vFE and the destination address is vCE, the SE looks up the vMap table to determine the intraPort (intraPort) from the vCE to the SEl) Through intraPortlP1 is sent to vCE.
The invention has the following beneficial effects: the invention provides a virtual router implementation method for solving the problem of forwarding element bottleneck in virtualization. All external ports in the virtual router are centralized on the switching component, and the design has the advantages that: when the virtual router uses a plurality of forwarding elements to meet the requirement of the packet processing capacity of the virtual network, the packet forwarding between any two ports in the virtual router can not occur, and the situation that the data packet passes through two forwarding elements in a serial mode can not occur any more; the switching component will distribute the packets to both forwarding elements for parallel processing, in which case the forwarding rate of the virtual router is equal to the sum of the forwarding rates of the two forwarding elements.
Drawings
FIG. 1 is a network virtualization method based on the separation of forwarding and control;
FIG. 2 is a network virtualization platform design based on the separation of forwarding and control;
FIG. 3 is a schematic diagram of the internal structure and data distribution of the switching elements.
Detailed Description
The invention is further illustrated by the following figures and examples.
The invention provides a virtual router implementation method, which comprises the following steps:
each Virtual Router (VR) in the step (1) consists of a virtual controller (vCE) and a plurality of virtual repeaters (vFE), wherein the vCE runs a routing protocol and maintains a routing table, and vFE performs routing table lookup and output port determination on a data packet;
the vces and vFE are both virtual machines on a physical machine, and the vces and vFE belonging to the same VR may be located on different physical machines. vFE the processing capacity of the data packet is determined by the amount of CPU and memory of the virtual machine in which it is located;
all data packets entering and exiting the VR in the step (2) are scheduled through a Switching Element (SE);
the SE is a multi-port switch, ports on the SE are divided into an external port (extraPort) and an internal port (intraPort), the intraPort is used for communication between vCE and vFE and between vFE and vFE, and the extraPort is used for input and output of data packets entering and exiting VR; the SE maintains a virtual mapping relation table (vMap) of VR → vCE → vFE, each line of the vMap table represents a virtual mapping relation of VR, and the vMap table consists of five parts, namely VR-vCE-vFE, intra port from vCE to SE, and intra port from vFE to SE;
step (3) when a data packet (P1) enters SE, checking the input port of P1, if the input port is an extraPort, entering step (4); if the input port is an intraPort, entering the step (5);
step (4) SE checks the destination address of the data packet P1, if the destination address of P1 is vCE, SE searches vMap table to determine the intraPort (intraPort) from vCE to SEi) Through intraPortiDirectly send P1 to vCE; otherwise, the SE looks up the vMap table, selects the less loaded vFE (vFE)j) While determining vFEjIntraPort to SEj) Through intraPortjDirectly send P1 to vFEj；
Step (5) SE inspectionSource and destination addresses of packet P1, if source address is vCE and destination address is vFE (vFE)k) SE lookup vMap Table determination vFEkIntraPort to SEk) Through intraPortkDirectly send P1 to vFEk(ii) a If the source address is vCE and the destination address is another VR, SE will select an extraPort to send P1 according to the external port label carried by P1; if neither the source address nor the destination address is any of vCE and vFE, SE will select an extraPort to send P1 according to the external port label carried by P1; if the source address is vFE and the destination address is vCE, the SE looks up the vMap table to determine the intraPort (intraPort) from the vCE to the SEl) Through intraPortlP1 is sent to vCE.
Examples
In order to facilitate the understanding and implementation of the present invention for those skilled in the art, the technical solutions of the present invention will be further described with reference to the accompanying drawings, and a specific embodiment of the present invention is provided.
According to the definition of IETF ForCES, an NE (network node in the general sense) is formed by combining one CE and a plurality of FEs, and the combination relationship can be set in a software-defined manner. ForCES NE de-emphasizes the geographical location and physical morphology of CEs and FEs, in other words NE is a logical concept, if the function performed by the NE is a Router, then the Router is a Virtual Router (VR), which is unmisleading with respect to node virtualization in network virtualization studies.
When multiple virtual networks need to be run simultaneously on top of one NE, the NE may assign a dedicated VR (i.e., vNE) to each virtual network, and these VRs isolated from each other ensure isolation between the virtual networks.
As shown in FIG. 1, the network virtualization method based on ForCES is essentially a ForCES-in-ForCES architecture design. The ForCES at the outer layer is the extension of the traditional ForCES, on one hand, NE is constructed, and a physical network node for forwarding and controlling separation is presented to the outside; on the other hand, the management of vFE and vCE is needed to be added for controlling the construction process of vNE. The ForCES of the inner layer is the conventional ForCES, and the operation environment is changed into a virtual machine. Therefore, the ForCES-in-ForCES architecture design solves the problem of node virtualization and simultaneously solves the virtualization of a network layer, namely the construction of a virtual network.
Based on the network virtualization method shown in fig. 1, a network virtualization platform (vForTER) is designed and implemented, and the internal structure thereof is designed as shown in fig. 2. The vForTER is a cluster of physical servers where one server is a control plane device, i.e., CE, and the data plane is typically spread over multiple servers, i.e., FEs, that perform data forwarding functions. The vForTER builds the VR for the virtual network, and ensures that each virtual network corresponds to one VR. The number of vFE in the VR depends on the forwarding capability required by the virtual network and the available resources that the vForTER can provide.
In fig. 2, SE is a dispatching center of communication traffic in vForTER, all communication traffic flowing through vForTER, between vCE-vFE and between vFE-vFE will be collected thereon, SE distributes them according to virtual network labels, and then the subsequent processing is completed by vCE and vFE, SE is only responsible for receiving and sending data packets. For example, when a SE receives a packet, it first determines the virtual network to which it belongs, and then delivers it to vFE for further processing (e.g., routing table lookup and traffic shaping), and the vFE processed packet is returned to the SE, where the packet is vFE appended with specific VN label information (e.g., output port, etc.), and the SE completes transmission according to the label information.
In fig. 2, over vForTER is carried 3 virtual nets, so vForTER generates 3 VRs, each VR consisting of one vCE and several vFE. A vCE exists in a CE and is a virtual machine of the CE, and each vCE independently runs a routing protocol. vFE are distributed over the FEs, each VR contains vFE that may be across FEs, depending on the packet forwarding capability required by the current VR. Taking three virtual networks in the figure as an example, virtual network 1 and virtual network 2 have higher requirements on packet forwarding capability, so 2 vFE are respectively allocated to VRs in virtual network 1 and virtual network 2 (vFE of virtual network 1 includes vFE1-1 and vFE1-2, and vFE of virtual network 2 includes vFE2-1 and vFE 2-2), while virtual network 3 has lower requirements on packet forwarding capability, so only 1 vFE (i.e. vFE3-1) is allocated thereto. All vFE processed data packets will be labeled and assembled to SE again, and SE will distribute the data packets according to these labels.
Fig. 3 shows an internal structure diagram of a switching component SE, which is a dispatching center of the entire vfaster and through which all data packets in the vfaster must pass, the main task of the switching component SE is to classify the data packets, and then the distributor performs distribution processing of the data packets according to a mapping relation table between "VR → vCE → vFE". for each data packet entering the SE, the classifier first judges its source, there may be two cases, 1) external port input and 2) internal interface input, and for the former, the former is subdivided into two cases, 1) a routing protocol packet sent from VR in the external vfaster is and then the distributor needs to send the routing protocol packet to vCE (identified by ① in the figure) in a redirection manner through the internal port, and 2) a normal forwarding packet from the virtual network, and the distributor selects corresponding vFE and sends the routing protocol packet (identified by ② in the figure).
When the source of the data packet is internal interface input, the method is divided into four cases, namely 1) ForCES control message from vCE for realizing control management of vFE by vCE, and the distributor sends the data packet to vFE (indicated by ③ in the figure), 2) routing protocol packet from vCE, the destination of which is VR in external vForTER, so the distributor needs to send the data packet through external interface (indicated by ④ in the figure), 3) the forwarded data packet after vFE processing is labeled, and the distributor needs to select corresponding external interface to send the data packet according to the label information (indicated by ② in the figure), 4) vFE actively generated ForCES event message, and the distributor only needs to send the data packet to corresponding vCE through internal interface (indicated by ⑤ in the figure), and meanwhile, SE maintains a mapping table of "VR → vCE → vFE", which is very important because the table defines the corresponding relation among internal virtual network, VR, FE, vFE and vCE, and creates a synchronous network partition table.
As previously described, each vFE processed packet is sent back to the SE. During processing, vFE performs a routing lookup table, retrieves egress ports and appends egress port information to the packet in the form of a tag. These tags exist only inside the vForTER, with lightweight packaging, and the dispatcher in the SE sends data according to the tags and through an external interface. Obviously, in the case of packet forwarding at high speed, SE may become the bottleneck of vForTER, so we take 2 measures to speed up the packet switching process: 1) the classifier and the distributor work in a kernel mode, and unnecessary system call overhead in the data packet processing process is reduced; 2) the SE avoids deep packet inspection of the packet and instead simply classifies certain fields in the packet header (e.g., port numbers in UDP packets) for immediate processing (e.g., routing table lookup) at vFE.
To prevent SE from becoming a bottleneck for the entire vForTER, the classifier and distributor can also be implemented by some special hardware, such as NetFPGA, network processor, or OpenFlow switch. The classifiers and distributors of the SE are treated the same for all virtual networks, so there is no need to virtualize the SE.
Claims (1)
1. A virtual router implementation method is characterized by comprising the following steps:
each Virtual Router (VR) in the step (1) consists of a virtual controller (vCE) and a plurality of virtual repeaters (vFE), wherein the vCE runs a routing protocol and maintains a routing table, and vFE performs routing table lookup and output port determination on a data packet;
the vces and vFE are both virtual machines on a physical machine, and the vces and vFE belonging to the same VR may be located on different physical machines; vFE the processing capacity of the data packet is determined by the amount of CPU and memory of the virtual machine in which it is located;
all data packets entering and exiting the VR in the step (2) are scheduled through a Switching Element (SE);
the SE is a multi-port switch, ports on the SE are divided into an external port (extraPort) and an internal port (intraPort), the intraPort is used for communication between vCE and vFE and between vFE and vFE, and the extraPort is used for input and output of data packets entering and exiting VR; the SE maintains a virtual mapping relation table (vMap) of VR → vCE → vFE, each line of the vMap table represents a virtual mapping relation of VR, and the vMap table consists of five parts, namely VR-vCE-vFE, intra port from vCE to SE, and intra port from vFE to SE;
step (3) when a data packet (P1) enters SE, checking the input port of P1, if the input port is an extraPort, entering step (4); if the input port is an intraPort, entering the step (5);
step (4) SE checks the destination address of the data packet P1, if the destination address of P1 is vCE, SE searches vMap table to determine the intraPort (intraPort) from vCE to SEi) Through intraPortiDirectly send P1 to vCE; otherwise, the SE looks up the vMap table, selects vFE with light load (vFE)j) While determining vFEjIntraPort to SEj) Through intraPortjDirectly send P1 to vFEj；
Step (5) SE checks the source and destination addresses of packet P1, if the source address is vCE and the destination address is vFE (vFE)k) SE lookup vMap Table determination vFEkIntraPort to SEk) Through intraPortkDirectly send P1 to vFEk(ii) a If the source address is vCE and the destination address is another VR, SE will select an extraPort to send P1 according to the port label carried by P1; if neither the source address nor the destination address is any of vCE and vFE, SE will select an extraPort to send P1 according to the external port label carried by P1; if the source address is vFE and the destination address is vCE, the SE looks up the vMap table to determine the intraPort (intraPort) from the vCE to the SEl) Through intraPortlP1 is sent to vCE.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710365654.8A CN107171953B (en) | 2017-05-22 | 2017-05-22 | Virtual router implementation method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710365654.8A CN107171953B (en) | 2017-05-22 | 2017-05-22 | Virtual router implementation method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107171953A CN107171953A (en) | 2017-09-15 |
| CN107171953B true CN107171953B (en) | 2020-04-28 |
Family
ID=59816191
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710365654.8A Expired - Fee Related CN107171953B (en) | 2017-05-22 | 2017-05-22 | Virtual router implementation method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107171953B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102511151A (en) * | 2011-04-27 | 2012-06-20 | 华为技术有限公司 | Router, virtual cluster router system and establishing method thereof |
| CN102957619A (en) * | 2011-08-25 | 2013-03-06 | 清华大学 | Virtual routing system and method |
| CN103067287A (en) * | 2013-01-18 | 2013-04-24 | 浙江工商大学 | Method achieving virtual programmable router under framework of forwarding and control separation |
| CN103430498A (en) * | 2013-02-06 | 2013-12-04 | 华为技术有限公司 | Method and device for network virtualized data transmission, and routing system |
| CN103491006A (en) * | 2013-09-13 | 2014-01-01 | 清华大学 | Method for forwarding data of virtual network router in centralized mode |
| CN105227454A (en) * | 2014-06-18 | 2016-01-06 | 中兴通讯股份有限公司 | Virtual flow-line system and method |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6907039B2 (en) * | 2002-07-20 | 2005-06-14 | Redback Networks Inc. | Method and apparatus for routing and forwarding between virtual routers within a single network element |
-
2017
- 2017-05-22 CN CN201710365654.8A patent/CN107171953B/en not_active Expired - Fee Related
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102511151A (en) * | 2011-04-27 | 2012-06-20 | 华为技术有限公司 | Router, virtual cluster router system and establishing method thereof |
| CN102957619A (en) * | 2011-08-25 | 2013-03-06 | 清华大学 | Virtual routing system and method |
| CN103067287A (en) * | 2013-01-18 | 2013-04-24 | 浙江工商大学 | Method achieving virtual programmable router under framework of forwarding and control separation |
| CN103430498A (en) * | 2013-02-06 | 2013-12-04 | 华为技术有限公司 | Method and device for network virtualized data transmission, and routing system |
| CN103491006A (en) * | 2013-09-13 | 2014-01-01 | 清华大学 | Method for forwarding data of virtual network router in centralized mode |
| CN105227454A (en) * | 2014-06-18 | 2016-01-06 | 中兴通讯股份有限公司 | Virtual flow-line system and method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107171953A (en) | 2017-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11625154B2 (en) | Stage upgrade of image versions on devices in a cluster | |
| JP7417825B2 (en) | slice-based routing | |
| EP3355553B1 (en) | Reliable load-balancer using segment routing and real-time application monitoring | |
| EP2880828B1 (en) | System and method for virtual ethernet interface binding | |
| US10063470B2 (en) | Data center network system based on software-defined network and packet forwarding method, address resolution method, routing controller thereof | |
| EP3063903B1 (en) | Method and system for load balancing at a data network | |
| US10033585B2 (en) | Methods and apparatus related to a switch fabric system having a multi-hop distributed control plane and a single-hop data plane | |
| KR100624681B1 (en) | Apparatus and method for combining forwarding tables in a distributed architecture router | |
| US8369296B2 (en) | Distributed link aggregation | |
| CN103905523A (en) | Cloud computing network virtualization method and system based on SDN | |
| CN105429870A (en) | VXLAN security gateway device and application method thereof in SDN | |
| CN104303467A (en) | Integrated heterogeneous software-defined network | |
| US10103980B1 (en) | Methods and apparatus for maintaining an integrated routing and bridging interface | |
| WO2016107594A1 (en) | Accessing external network from virtual network | |
| EP2680536B1 (en) | Methods and apparatus for providing services in a distributed switch | |
| US9537785B2 (en) | Link aggregation group (LAG) link allocation | |
| CN110430114B (en) | Virtual router and method for realizing interconnection between SDN network and traditional IP network | |
| CN106059915A (en) | System and method for implementing limitation of north-south traffic of tenants based on SDN controller | |
| TW201541262A (en) | Method for virtual machine migration using software defined networking (SDN) | |
| US11799972B2 (en) | Session management in a forwarding plane | |
| EP2930893A1 (en) | Communication system, control apparatus, communication control method, transfer control method, and transfer control program | |
| Yan et al. | A survey of low-latency transmission strategies in software defined networking | |
| KR101841026B1 (en) | Service function chaining network system for path optimization | |
| CN103346950A (en) | Sharing method and device of load between user service boards of rack-mounted wireless controller | |
| KR101794719B1 (en) | Method and system for ip address virtualization in sdn-based network virthalization platform |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20200428 Termination date: 20210522 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |