A MPLS VPN label forwarding path planning method based on SDN

Abstract

The present invention discloses a method for planning a MPLS VPN label forwarding path based on SDN, which is characterized by comprising the following steps: 1) setting parameters; 2) SDN controller formulating a unified allocation strategy; 3) calculating a physical path; 4) creating LSP data; 5) SDN controller synchronizing the LSP process; 6) SDN controller merging the LSP process. This method has the advantages of simple LSP planning, low error probability, good response to extreme network failures, and can improve the availability of SDN technology to meet the stringent requirements of users.

Description

Technical Field

[0001] The present invention relates to a software defined packet transport network SPTN (Software Defined Packet Transport Network, referred to as SPTN) technology, in particular to a label forwarding path planning method for a large-scale flat MPLS VPN packet transport network using software defined network SDN (Software Defined Network, referred to as SDN) controller software in a centralized manner, and specifically to a label forwarding path planning method for an MPLS VPN multi-protocol label switching MPLS (Multi-Protocol Label Switching, referred to as MPLS) virtual private network VPN (Virtual Private Network, referred to as VPN) based on SDN. Background Art

[0002] Software Defined Network (SDN) is an inevitable trend in the current network development. Combining SDN with packet transport network (PTN) can fully meet the needs of convenient user service activation, improve maintenance efficiency, improve network resource utilization, and improve anti-destruction capabilities. SDN controller is the key to SDN centralized control technology. In order to avoid the impact of single point failure of the controller on system reliability, multiple controllers are usually deployed in a master-slave distributed manner. A key issue of this solution is to maintain the correctness and consistency of data synchronization between the master and slave controllers. Layer 2 and Layer 3 MPLS VPN networks are typical networking solutions for PTN networks. When networking, this solution requires the creation of a large number of label switching paths (LSPs) between the MPLS VPN network headquarters and each site. The traditional solution uses a distributed label distribution protocol (LDP) or a resource reservation protocol (RSVP-TE) based on traffic engineering extensions. The creation of LSPs is too complicated and has gradually been replaced by a simple solution based on the centralized creation of LSPs by SDN controller software. Therefore, SDN controller software has become a key link in the current MPLS VPN network. How to simply, reliably and quickly create and dismantle LSPs on demand in large-scale and flat MPLS VPN networking, and how to ensure the correctness and consistency of LSP data between controllers when the SDN controller software is deployed in a master-slave distributed manner, and the consistency and correctness of LSP data between the controllers on the control plane and the network elements on the forwarding plane are important topics in the field of MPLS VPN network engineering applications.

[0003] In scenarios where strict requirements are placed on the stability of MPLS VPN network LSPs, the current centralized SDN-based LSP planning method has the following problems that need to be solved in engineering applications:

[0004] 1. The SDN controller uses the traditional auto-negotiation method to randomly assign LSP protection group identifiers, global LSP identifiers, network element LSP identifiers, and label values. When data conflicts occur on the forwarding plane, different LSPs affect each other, making it impossible to isolate LSP faults from the headquarters to a single site. In addition, it is difficult to locate the cause of LSP faults when the network scale is large.

[0005] 2. The SDN controller uses the traditional auto-negotiation method to randomly assign LSP protection group identifiers, global LSP identifiers, network element LSP identifiers, and label values. When errors and conflicts occur during the control plane data replication process, the receiving controller cannot determine which headquarters and site the conflicting data belongs to, making error handling difficult.

[0006] 3. The SDN controller uses the traditional auto-negotiation method to randomly assign LSP protection groups, global LSP identifiers, network element LSP identifiers, and label values. In the control plane master-slave distributed deployment scenario, the SDN controller has a "brain split" and multiple master controllers run independently, which is prone to conflicts in LSP protection group identifiers, global LSP identifiers, network element LSP identifiers, and label allocation. After the "brain split" is repaired, it is difficult to merge the data of multiple master controllers. Summary of the invention

[0007] The purpose of the present invention is to provide a SDN-based MPLS VPN label forwarding path planning method to address the deficiencies of the prior art. This method has the advantages of simple LSP planning, low error probability, good response to extreme network failures, and can improve the availability of SDN technology to meet the stringent requirements of users.

[0008] The technical solution for achieving the purpose of the present invention is:

[0009] A method for planning an MPLS VPN label forwarding path based on SDN includes the following steps:

[0010] 1) Setting parameters: The network management system sets the number of headquarters N1, the number of sites N2, and the maximum number of LSPs N3 in the LSP protection group between the headquarters and the sites of the MPLS VPN network, and sends them to each SDN controller;

[0011] 2) The SDN controller formulates a unified allocation strategy: The SDN controller receives the N1, N2, and N3 parameters in step 1) issued by the network management and formulates a unified allocation strategy for LSP data. The unified allocation strategy is:

[0012] 2-1) Different from the traditional auto-negotiation random allocation of LSP protection group identifiers, the SDN controller allocates a unique LSP protection group identifier range LspGroupId between each headquarters X and each site m: (X-1)*N2+m, where 1<=X<=N1, 1<=m<=N2;

[0013] 2-2) Different from the traditional auto-negotiation random allocation of LSP identifiers, the SDN controller allocates a unique identifier range LspId for each N3 LSP in each LSP protection group: (LspGroupId-1)*N3+j, 1<=j<=N3;

[0014] 2-3) Different from the traditional auto-negotiation method of randomly assigning label values, the SDN controller assigns a unique incoming label (LspId-1)*2+1 and a unique outgoing label (LspId-1)*2+2 to each LSP;

[0015] 3) Calculate the physical path: The network management sends the service intent to the main SDN controller, and the main SDN controller plans the MPLS VPN label forwarding path, including:

[0016] 3-1) Create an LSP protection group instance between each headquarters and each site;

[0017] 3-2) Calculate the physical path for each LSP protection group instance. If the physical path calculation succeeds, create an LSP instance, and create network element LSP-PE or LSP-P instances for all network elements that the physical path passes through. If the physical path calculation fails, stop the calculation;

[0018] 3-3) Repeat step 3-2 until the number reaches N3 or the calculation of the physical path fails;

[0019] 4) Create LSP data: including:

[0020] 4-1) The network management system sends the MPLS VPN network service intent to the main SDN controller. After receiving the service intent sent by the network management system, the main SDN controller creates LSP data, including: LSP protection group instance, LSP instance, network element LSP-PE instance and network element LSP-P instance, where:

[0021] 4-1-1) The content of the LSP protection group instance is shown in Table 1:

[0022] Table 1

[0023] Field Name Data Types meaning Id uint32 LSP protection group identifier SrcDevice string "Start" network element identifier DstDevice string "End" network element identifier Lsp uint32[] LSP ID set Exp uint8 Priority Bandwidth uint32 Bandwidth requirements InLabel uint32 Incoming label OutLabel uint32 Out label ;

[0024] 4-1-2) The content of the LSP instance is shown in Table 2:

[0025] Table 2

[0026] Field Name Data Types meaning Id uint32 LSP ID Oam uint32 Oam logo OamIvl uint32 Oam cycle SrcLspPe uint32 "Starting" network element LSP-PE identifier DstLspPe uint32 "End" network element LSP-PE identifier LspPs uint32[] "Middle" network element LSP-P identifier ;

[0027] 4-1-3) The network element LSP-PE instance, i.e. the start and end node contents are shown in Table 3, where the identifier is equal to the LSP instance identifier, and the incoming label and outgoing label are equal to the incoming label and outgoing label of the LSP instance:

[0028] Table 3

[0029]

[0030]

[0031] 4-1-4) The content of the network element LSP-P instance, i.e., the intermediate node, is shown in Table 4, where the identifier is the same as the LSP identifier, the incoming label and outgoing label of the LSP-PE instance are equal to the incoming label and outgoing label of the LSP instance, the westbound incoming label and eastbound outgoing label of the LSP-P instance are equal to the outgoing label of the starting LSP-PE instance, and the eastbound incoming label and westbound outgoing label of the LSP-P instance are equal to the incoming label of the starting LSP-PE instance:

[0032] Table 4

[0033] Field Name Data Types meaning Id uint32 NE LSP-P ID Device string Network element identification WInLabel uint32 Westbound inbound label WoutLabel uint32 Westbound outbound label EinLabel uint32 Eastbound incoming label EoutLabel uint32 Eastbound outgoing label Wport uint32 Westbound Outlet WdstMac string West Next hop MAC address Eport uint32 Eastbound port EdstMac string East next hop MAC address ;

[0034] 4-2) The main controller sends the created network element LSP-PE and LSP-P instances to the corresponding network elements respectively. After receiving them, the network elements execute the configuration and record them;

[0035] 5) SDN controller synchronization LSP process: including:

[0036] 5-1) The master SDN controller copies all LSP data to the slave SDN controller in the form of identification / content;

[0037] 5-2) If the identifier of the unique LSP protection group instance between the headquarters identified as X and the site identified as m is not equal to (X-1)*N2+m, the data is wrong and needs to be corrected;

[0038] 5-3) If the identifier of the kth LSP instance in each LSP protection group instance is not equal to ((X-1)*N2+m)-1)*N3+k, the data is wrong and needs to be corrected, 1<=k<=N3;

[0039] 5-4) If the outgoing label of the LSP instance identified as j is not equal to (j-1)*2+2 or the incoming label is not equal to (j-1)*2+1, the data is wrong and needs to be corrected;

[0040] 5-5) If the physical path formed by all network elements and ports in sequence through the LSP instance does not match the link information of the current real-time topology, the data is wrong and the LSP instance, network element LSP-PE, and LSP-P instance need to be recreated;

[0041] 5-5) After the error processing is completed, the SDN controller actively obtains the LSP data of all network elements in the forwarding plane and verifies the correctness of the network element data, and decides whether to update the LSP data of the network element based on the verification result;

[0042] 6) SDN controller merge LSP process: including:

[0043] 6-1) Assuming that SDN controller 1 is the master controller after the merger, after receiving the LSP data from SDN controller 2, if the corresponding LSP identifier is not found in its local cache, it first verifies the data. If the verification passes, the LSP data is stored in the local cache. Otherwise, the LSP data is recalculated and the LSP data of the network element is created;

[0044] 6-2) After SDN controller 1 receives the LSP data from SDN controller 2, if the corresponding LSP identifier is also found in its local cache, it will be ignored;

[0045] 6-3) After the LSP data is merged, the SDN controller 1 actively obtains the LSP configuration data of all network elements, verifies the LSP data received from the SDN controller 2 and the LSP configuration data of the network elements, and updates the LSP configuration data of the network elements according to the verification result.

[0046] In this technical solution, the SDN controller formulates a unified allocation strategy for LSP protection group identifiers, LSP identifiers, and label values ​​according to the number of headquarters and sites in a specific MPLS VPN network; all LSP data synchronized in the form of identifier / content (key / value) between the master and slave SDN controllers can identify errors in the data content and correct them according to the unified allocation strategy; all SDN controllers adopt a unified allocation strategy, and the LSP data of multiple master controllers can be directly combined. The processing measures in the present invention improve the availability of SDN technology in MPLS VPN networks and ensure the reliability and stability of large-scale flat MPLSVPN fixed networks based on SDN.

[0047] This technical solution has the following advantages:

[0048] The technical solution first provides a method for planning LSP of an MPLS VPN network: in an MPLS VPN network, according to the service needs of users, it is necessary to plan LSP when establishing a service connection between two sites. This method is different from the protocol auto-negotiation allocation method. Instead, it is centrally processed by an SDN controller according to a unified allocation strategy. The same LSP identifier and label are used for each network element on each LSP, and each LSP identifier and label only corresponds to two specific sites, which reduces the probability of errors and improves the reliability of the entire MPLS VPN network.

[0049] The second technical solution is to provide a controller synchronization and error handling method for LSP data in an MPLS VPN network. Since all controllers use the same strategy, even if unexpected errors occur during the synchronization of master and slave controller data, the receiver can automatically identify and handle the errors according to the unified allocation strategy. This method improves the practicality and robustness of the application of SDN technology in MPLSVPN networks.

[0050] The third technical solution is to solve the problem that LSP data cannot be merged in the "brain split" scenario of the SDN controller. Since all controllers use the same strategy, there is no LSP data planning conflict between them. LSP data with different identifiers can be directly taken as a union, and LSP data with identifiers that exist at the same time can be ignored by the receiving controller. This method solves the data partition fault tolerance and consistency problems introduced by the "brain split" in SDN technology.

[0051] This technical solution changes the random allocation of the global LSP protection group, global LSP identifier, network element LSP identifier, and label value under the existing auto-negotiation mechanism, and simplifies the LSP identifier into one, thereby reducing the probability of LSP failure in the forwarding plane and the difficulty of locating the cause of the failure, and improving the error handling capability of the SDN controller when label conflicts occur in the control plane, and overcoming the problem that LSP data cannot be merged due to data conflicts such as the LSP protection group identifier, global LSP identifier, network element LSP identifier, and label value after the "brain split" of the SDN controller is repaired in the master-slave distributed deployment scenario.

[0052] This method has the advantages of simple LSP planning, low error probability, good response to extreme network failures, improved availability of SDN technology, and met the stringent requirements of users. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 It is a schematic diagram of the process flow of the embodiment method;

[0054] Figure 2 A schematic diagram of the MPLS VPN label forwarding path planning method in implementation;

[0055] Figure 3Schematic diagram of the MPLS VPN network label forwarding path planning method for the SDN controller "split brain" scenario being implemented. DETAILED DESCRIPTION

[0056] The content of the present invention is further described below in conjunction with the drawings and embodiments, but the present invention is not limited thereto.

[0057] Example:

[0058] Reference Figure 1 , a method for planning an MPLS VPN label forwarding path based on SDN, comprising the following steps:

[0059] 1) Setting parameters: The network management system sets the number of headquarters N1, the number of sites N2, and the maximum number of LSPs N3 in the LSP protection group between the headquarters and the sites of the MPLS VPN network, and sends them to each SDN controller;

[0060] 2) The SDN controller formulates a unified allocation strategy: The SDN controller receives the N1, N2, and N3 parameters in step 1) issued by the network management and formulates a unified allocation strategy for LSP data. The unified allocation strategy is:

[0061] 2-1) Different from the traditional auto-negotiation random allocation of LSP protection group identifiers, the SDN controller allocates a unique LSP protection group identifier range LspGroupId between each headquarters X and each site m: (X-1)*N2+m, where 1<=X<=N1, 1<=m<=N2;

[0062] 2-2) Different from the traditional auto-negotiation random allocation of LSP identifiers, the SDN controller allocates a unique identifier range LspId for each N3 LSP in each LSP protection group: (LspGroupId-1)*N3+j, 1<=j<=N3;

[0063] 2-3) Different from the traditional auto-negotiation method of randomly assigning label values, the SDN controller assigns a unique incoming label (LspId-1)*2+1 and a unique outgoing label (LspId-1)*2+2 to each LSP;

[0064] 3) Calculate the physical path: The network management sends the service intent to the main SDN controller, and the main SDN controller plans the MPLS VPN label forwarding path, including:

[0065] 3-1) Create an LSP protection group instance between each headquarters and each site;

[0066] 3-2) Calculate the physical path for each LSP protection group instance. If the physical path calculation succeeds, create an LSP instance, and create network element LSP-PE or LSP-P instances for all network elements that the physical path passes through. If the physical path calculation fails, stop the calculation;

[0067] 3-3) Repeat step 3-2 until the number reaches N3 or the calculation of the physical path fails;

[0068] 4) Create LSP data: including:

[0069] 4-1) The network management system sends the MPLS VPN network service intent to the main SDN controller. After receiving the service intent sent by the network management system, the main SDN controller creates LSP data, including: LSP protection group instance, LSP instance, network element LSP-PE instance and network element LSP-P instance, where:

[0070] 4-1-1) The content of the LSP protection group instance is shown in Table 1:

[0071] Table 1

[0072] Field Name Data Types meaning Id uint32 LSP protection group identifier SrcDevice string "Start" network element identifier DstDevice string "End" network element identifier Lsp uint32[] LSP ID set Exp uint8 Priority Bandwidth uint32 Bandwidth requirements InLabel uint32 Incoming label OutLabel uint32 Out label ;

[0073] 4-1-2) The content of the LSP instance is shown in Table 2:

[0074] Table 2 LSP instance description

[0075] Field Name Data Types meaning Id uint32 LSP ID Oam uint32 Oam logo OamIvl uint32 Oam cycle SrcLspPe uint32 "Starting" network element LSP-PE identifier DstLspPe uint32 "End" network element LSP-PE identifier LspPs uint32[] "Middle" network element LSP-P identifier ;

[0076] 4-1-3) The network element LSP-PE instance, i.e. the start and end node contents are shown in Table 3, where the identifier is equal to the LSP instance identifier, and the incoming label and outgoing label are equal to the incoming label and outgoing label of the LSP instance:

[0077] Table 3

[0078] Field Name Data Types meaning Id uint32 Network element LSP-PE identification LspGroupId uint32 LSP protection group ID Device string Network element identification InLabel uint32 Incoming label OutLabel uint32 Out label Port uint32 Outgoing port DstMac string Next hop MAC address ;

[0079] 4-1-4) The content of the network element LSP-P instance, i.e., the intermediate node, is shown in Table 4, where the identifier is the same as the LSP identifier, the incoming label and outgoing label of the LSP-PE instance are equal to the incoming label and outgoing label of the LSP instance, the westbound incoming label and eastbound outgoing label of the LSP-P instance are equal to the outgoing label of the starting LSP-PE instance, and the eastbound incoming label and westbound outgoing label of the LSP-P instance are equal to the incoming label of the starting LSP-PE instance:

[0080] Table 4

[0081] Field Name Data Types meaning Id uint32 NE LSP-P ID Device string Network element identification WInLabel uint32 Westbound inbound label WOutLabel uint32 Westbound outbound label EInLabel uint32 Eastbound incoming label EOutLabel uint32 Eastbound outgoing label WPort uint32 Westbound Outlet WDstMac string West Next hop MAC address EPort uint32 Eastbound port EDstMac string East next hop MAC address ;

[0082] 4-2) The main controller sends the created network element LSP-PE and LSP-P instances to the corresponding network elements respectively. After receiving them, the network elements execute the configuration and record them;

[0083] 5) SDN controller synchronization LSP process: including:

[0084] 5-1) The master SDN controller copies all LSP data to the slave SDN controller in the form of identification / content;

[0085] 5-2) If the identifier of the unique LSP protection group instance between the headquarters identified as X and the site identified as m is not equal to (X-1)*N2+m, the data is wrong and needs to be corrected;

[0086] 5-3) If the identifier of the kth LSP instance in each LSP protection group instance is not equal to ((X-1)*N2+m)-1)*N3+k, the data is wrong and needs to be corrected, 1<=k<=N3;

[0087] 5-4) If the outgoing label of the LSP instance identified as j is not equal to (j-1)*2+2 or the incoming label is not equal to (j-1)*2+1, the data is wrong and needs to be corrected;

[0088] 5-5) If the physical path formed by all network elements and ports in sequence through the LSP instance does not match the link information of the current real-time topology, the data is wrong and the LSP instance, network element LSP-PE, and LSP-P instance need to be recreated;

[0089] 5-5) After the error processing is completed, the SDN controller actively obtains the LSP data of all network elements in the forwarding plane and verifies the correctness of the network element data, and decides whether to update the LSP data of the network element based on the verification result;

[0090] 6) SDN controller merge LSP process: including:

[0091] 6-1) Assuming that SDN controller 1 is the master controller after the merger, after receiving the LSP data from SDN controller 2, if the corresponding LSP identifier is not found in its local cache, it first verifies the data. If the verification passes, the LSP data is stored in the local cache. Otherwise, the LSP data is recalculated and the LSP data of the network element is created;

[0092] 6-2) After SDN controller 1 receives the LSP data from SDN controller 2, if the corresponding LSP identifier is also found in its local cache, it will be ignored;

[0093] 6-3) After the LSP data is merged, the SDN controller 1 actively obtains the LSP configuration data of all network elements, verifies the LSP data received from the SDN controller 2 and the LSP configuration data of the network elements, and updates the LSP configuration data of the network elements according to the verification result.

[0094] In this example, Figure 2 In a large-scale flat MPLS VPN network, the network manager sets the number of headquarters 2 and the number of sites 20 to the master SDN controller and the slave SDN controller. After receiving the information, the two controllers formulate unified allocation strategies respectively. The network manager sends the service intent to the master SDN controller. After receiving the information, the master SDN controller creates an LSP protection group instance between the headquarters 1 and the site 18 according to the unified allocation strategy, and creates three LSP instances, network element LSP-PE instances, and network element LSP-P instances, which are identified as 52, 53, and 54 respectively. The inbound and outbound labels of each LSP instance are 104 / 105, 106 / 107, and 108 / 109 respectively. The LSP data creation process in step 3) includes:

[0095] 3-1) The main SDN controller creates an LSP protection group instance between headquarters 1 and site 18, identified as 18;

[0096] 3-2) The main SDN controller calculates the physical path for LSP protection group instance 18, and the calculation is successful for three times. Three LSP instances are created, with identifiers 52, 53, and 54, and inbound and outbound labels 104 / 105, 106 / 107, and 108 / 109 respectively;

[0097] 3-3) The main SDN controller creates network element LSP-PE and LSP-P instances corresponding to the three LSP instances;

[0098] 3-4) The main SDN controller sends the network element LSP-PE and LSP-P instances created above to the corresponding network elements respectively;

[0099] 3-5) The master SDN controller copies all the above instances to the slave SDN controller;

[0100] The LSP data synchronization process in step 5) includes:

[0101] 5-1) The master SDN controller copies the LSP protection group instance identified as 18 to the slave SDN controller;

[0102] 5-2) The master SDN controller copies the LSP instances identified as 52, 53, and 54 to the slave SDN controller;

[0103] 5-3) The master SDN controller copies the network element LSP-PE and LSP-P instances identified as 52, 53, and 54 to the slave SDN controller;

[0104] The LSP data verification process in step 5) includes:

[0105] 5-4) After receiving the LSP protection group instance with identification 18 from the SDN controller, check the "starting" network element and the "destination" network element information, and verify whether the LSP protection group instance with identification 18 corresponds to these two network elements according to the allocation strategy;

[0106] 5-5) After receiving the LSP instances with identifiers 52, 53, and 54 from the SDN controller, check whether the LSP array information in the LSP protection group instance with identifier 18 contains these three LSP instances according to the allocation strategy;

[0107] 5-6) After receiving the network element LSP-PE and LSP-P instances with identifiers 52, 53, and 54 from the SDN controller, check whether the inbound and outbound label values ​​in the network element LSP-PE and LSP-P instances are correct according to the allocation strategy;

[0108] 5-7) After receiving the network element LSP-PE and LSP-P instances with identifiers 52, 53, and 54 from the SDN controller, a physical path is formed in sequence according to the network element identifiers and ingress and egress port information in the network element LSP-PE and LSP-P instances, and the physical path information carried by the network element LSP-PE and LSP-P is verified to be correct with the link information in the current topology of the SDN controller;

[0109] The LSP data merging process in step 6) includes:

[0110] 6-1) Assumptions Figure 1 The MPLS VPN network in the example is split into two partitions at some point due to a collective failure of the intermediate links. Figure 3 As shown in the figure, two main SDN controllers appear after the split. Controller 2 in the lower partition recalculates three LSP instances from headquarters 2 to site 13, with identifiers 97, 98, and 99, and sends them to the relevant network elements of the forwarding plane. The physical path from headquarters 1 to site 13 in the upper partition is disconnected. Controller 1 removes the previously calculated LSP instances from headquarters 1 and headquarters 2 to site 13, and cannot calculate new LSP instances.

[0111] 6-2) When the disconnected link in the middle is restored, the network is re-merged, controller 1 regains the role of the master controller, and controller 2 is downgraded to the role of the slave controller. Controller 2 copies the three LSP instances from headquarters 2 to site 13 that it created to controller 1. Since controller 1 no longer has the LSP instance from headquarters 2 to site 13, it stores the new LSP instance in the local cache after receiving it. In this way, controller 1 does not need to recalculate the LSP instance from headquarters 2 to site 13, and it remains consistent with the relevant network element LSP instances on the forwarding plane.

Claims

1. A method for planning an MPLS VPN label forwarding path based on SDN, characterized in that: The steps include: 1) Setting parameters: The network management system sets the number of headquarters N1, the number of sites N2, and the maximum number of LSPs N3 in the LSP protection group between the headquarters and the sites of the MPLS VPN network, and sends them to each SDN controller; 2) The SDN controller formulates a unified allocation strategy: The SDN controller receives the N1, N2, and N3 parameters in step 1) issued by the network management and formulates a unified allocation strategy for LSP data. The unified allocation strategy is: 2-1) The SDN controller allocates a unique LSP protection group identifier range LspGroupId between each headquarters X and each site m: (X-1)*N2+m, where 1<=X<=N1, 1<=m<=N2; 2-2) The SDN controller allocates a unique identification range LspId to each of the N3 LSPs in each LSP protection group: (LspGroupId-1)*N3+j, 1<=j<=N3; 2-3) The SDN controller assigns a unique incoming label (LspId-1)*2+1 and a unique outgoing label (LspId-1)*2+2 to each LSP; 3) Calculate the physical path: The network management sends the service intent to the main SDN controller, and the main SDN controller plans the MPLS VPN label forwarding path, including: 3-1) Create an LSP protection group instance between each headquarters and each site; 3-2) Calculate the physical path for each LSP protection group instance. If the physical path calculation succeeds, create an LSP instance, and create network element LSP-PE or LSP-P instances for all network elements that the physical path passes through. If the physical path calculation fails, stop the calculation; 3-3) Repeat step 3-2 until the number reaches N3 or the calculation of the physical path fails; 4) Create LSP data: including: 4-1) The network management system sends the MPLS VPN network service intent to the main SDN controller. After receiving the service intent sent by the network management system, the main SDN controller creates LSP data, including: LSP protection group instance, LSP instance, network element LSP-PE instance and network element LSP-P instance, where: 4-1-1) The content of the LSP protection group instance is shown in Table 1: Table 1 ； 4-1-2) The content of the LSP instance is shown in Table 2: Table 2 ； 4-1-3) The network element LSP-PE instance, i.e. the start and end node contents are shown in Table 3, where the identifier is equal to the LSP instance identifier, and the incoming label and outgoing label are equal to the incoming label and outgoing label of the LSP instance: Table 3 ； 4-1-4) The content of the network element LSP-P instance, i.e., the intermediate node, is shown in Table 4, where the identifier is the same as the LSP identifier, the incoming label and outgoing label of the LSP-PE instance are equal to the incoming label and outgoing label of the LSP instance, the westbound incoming label and eastbound outgoing label of the LSP-P instance are equal to the outgoing label of the starting LSP-PE instance, and the eastbound incoming label and westbound outgoing label of the LSP-P instance are equal to the incoming label of the starting LSP-PE instance: Table 4 ； 4-2) The main controller sends the created network element LSP-PE and LSP-P instances to the corresponding network elements respectively. After receiving them, the network elements execute the configuration and record them; 5) SDN controller synchronization LSP process: including: 5-1) The master SDN controller copies all LSP data to the slave SDN controller in the form of identification / content; 5-2) If the identifier of the unique LSP protection group instance between the headquarters identified as X and the site identified as m is not equal to (X-1)*N2+m, the data is wrong and needs to be corrected; 5-3) If the identifier of the kth LSP instance in each LSP protection group instance is not equal to ((X-1)*N2+m)-1)*N3+k, the data is wrong and needs to be corrected, 1<=k<=N3; 5-4) If the outgoing label of the LSP instance identified as j is not equal to (j-1)*2+2 or the incoming label is not equal to (j-1)*2+1, the data is wrong and needs to be corrected; 5-5) If the physical path formed by all network elements and ports in sequence through the LSP instance does not match the link information of the current real-time topology, the data is wrong and the LSP instance, network element LSP-PE, and LSP-P instance need to be recreated; 5-5) After the error processing is completed, the SDN controller actively obtains the LSP data of all network elements in the forwarding plane and verifies the correctness of the network element data, and decides whether to update the LSP data of the network element based on the verification result; 6) SDN controller merge LSP process: including: 6-1) Assuming that SDN controller 1 is the master controller after the merger, after receiving the LSP data from SDN controller 2, if the corresponding LSP identifier is not found in its local cache, it first verifies the data. If the verification passes, the LSP data is stored in the local cache. Otherwise, the LSP data is recalculated and the LSP data of the network element is created; 6-2) After SDN controller 1 receives the LSP data from SDN controller 2, if the corresponding LSP identifier is also found in its local cache, it will be ignored; 6-3) After the LSP data is merged, the SDN controller 1 actively obtains the LSP configuration data of all network elements, verifies the LSP data received from the SDN controller 2 and the LSP configuration data of the network elements, and updates the LSP configuration data of the network elements according to the verification result.

Images