A method, device and system for information synchronization

Abstract

The present application provides a method for information synchronization, which includes a controller sending a first message to a network device, wherein the first message carries CRP routing table entry information for publishing CRP routes. The first message includes first identification information, and after the forwarding device receives the first message, the CRP routing table entry information is saved in the CRP routing table of the network device according to the indication of the first identification information. In the technical solution of the present application, since the routes published by the controller and the routes published in the routing protocol between the forwarding devices are stored in different routing tables, it will not affect the applications related to the routes published by the routing protocol between the forwarding devices.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, device and system for information synchronization. Background Art

[0002] In recent years, the value of software-defined networks (SDN) has been recognized by telecom network operators and is the direction of future network evolution. The SDN system includes a controller and a forwarding device, where the controller can be used to control network traffic and the forwarding device can be used to forward received data packets. The SDN technology separates the control plane and the forwarding plane (also called the data plane) of network devices, achieving flexible control of network traffic and accelerating innovation of network services.

[0003] Border Gateway Protocol (BGP) is a dynamic routing protocol used between autonomous systems (AS). It is mainly used to exchange reachable routing information between ASs and build propagation paths between AS domains. The current version in use is BGP-4 (RFC4271). As the Internet external routing protocol standard, BGP is widely used between Internet Service Providers (ISPs). In order to provide support for multiple network layer protocols, the Internet Engineering Task Force (IETF) has extended BGP-4 to form Multi-protocol Extensions for BGP (MP-BGP).

[0004] In the current SDN architecture, if the controller uses the BGP protocol to publish routes to the forwarding device, the routes it publishes and the routes published between the forwarding devices using ordinary BGP are stored in the same BGP routing information table (English: Route Information Bate, RIB) (in this application, "routing information table RIB", "routing information table", "RIB" and "routing table" can be used interchangeably). Figure 1As shown, the routes sent by the controller are treated as ordinary BGP routes. When the routes published by the controller are preferred, the related applications of the routes published by the ordinary BGP will be affected. For example, forwarding device A publishes route P1 with prefix X to forwarding device B, and the controller publishes route P2 with the same prefix X to forwarding device B. At this time, forwarding device B receives two routes with the same prefix X. Forwarding device B forwards the route to forwarding device C. When performing route selection, the priority of route P2 is higher than the priority of route P1. Forwarding device B sends route P2 to forwarding device C. At this time, it will affect the applications related to route P1. For example: when the BGP MED (Multi-Exit-Disc) attribute associated with route P1 is set to 100, route P1 is introduced into the intermediate system to intermediate system (English: Intermediate System toIntermediate System, ISIS) RIB of forwarding device C. At this time, since route P2 is preferred and the MED attribute of route P2 is set to 200, route P2 will not be introduced into the ISIS RIB. Therefore, the related applications of route P1 published by ordinary BGP between forwarding devices are affected.

[0005] If the controller uses the first path computation element communication protocol (English: Path Computation Element Protocol, PCEP) or other existing routing protocols to publish routes to the forwarding device, it also faces similar problems as mentioned above, that is, the routes published by the controller and the ordinary PECP routes between the forwarding devices or the routes in other routing protocols are stored in the same PCEP routing information table RIB or the ordinary routing information table RIB under other routing protocols. In this case, the routes published by the controller are treated as ordinary PECP routes or ordinary routes in other routing protocols. When the routes published by the controller are preferred, the related applications of the routes published by the ordinary PCEP or other routing protocols will be affected. Summary of the invention

[0006] In view of this, an embodiment of the present application provides a method for information synchronization, in which a controller sends routing table entry information to a forwarding device, and the forwarding device establishes a routing table that separately stores the routing table entry information sent by the controller. The preferred routes in the routing table are added to the RM RIB, so that the RM module can select routes between routes generated by different protocols such as routes sent by the controller, static routes, ISIS routes, Open Shortest Path First (OSPF) routes, and BGP routes, and because the routes published by the controller and the routes published in the routing protocol between the forwarding devices are stored in different routing tables, it will not affect applications related to the routes between the forwarding devices.

[0007] In the first aspect, an embodiment of the present application provides a method for information synchronization. First, the controller determines the control routing protocol (English: Control Routing Protocol, CRP) routing table entry information, and the CRP routing table entry information includes a mapping relationship between a routing prefix and an address of the first next hop of a network device. The above-mentioned "CRP" refers to: a protocol running between a controller and a forwarding device, supporting the controller to publish routes to the forwarding device. The controller generates a first message, and the CRP routing table entry information is carried in the first message for publishing CRP routes. The first message includes first identification information, and the first identification information is used to indicate that the network device saves the CRP routing table entry information in the CRP routing table of the network device. Then, the controller sends the first message to the network device, so that the network device saves the CRP routing table entry information in the CRP routing table according to the first identification information, and guides message forwarding according to the CRP routing table.

[0008] Therefore, the information synchronization method of the embodiment of the present application runs the CRP protocol between the controller and the network device, and through indication information, such as the first identification information mentioned above, the network device can create a separate CRP routing table according to the indication information to store the CRP routing table item information sent by the controller. Since the network device stores the CRP routes published by the controller and the routes published according to the routing protocol between the network devices in different routing tables, the routing policy related to the CRP routes will not affect the related application of the routing policy related to the routes published according to the routing protocol between the network devices.

[0009] In combination with the first aspect, in a first possible implementation manner of the first aspect, the CRP routing table entry information further includes a routing priority, where the routing priority is used to identify a priority of the CRP route when being used to guide message forwarding.

[0010] By carrying the route priority in the CRP route table information, the CRP route priority can be flexibly set. For example, the CRP route can be set as the preferred route, so as to achieve the purpose of controlling the traffic using the route published by the controller. For various subsequent complex policy controls on routes, it can be completed by upgrading the controller, without the need for all devices to implement complex policies like existing routing policies, such as BGP routing policies. Therefore, traffic regulation is simpler and more flexible. In addition, in some application scenarios, customers believe that internally deployed IGP routes are trusted and should be preferred, while external routes are untrusted and should not be preferred. In this way, the priority of the CRP route can also be set to be lower than the priority of the ISIS route and the OSPF route. It can be seen that by setting the priority of the CRP route, the different needs of customers can be met.

[0011] In combination with the first aspect and the above-mentioned possible implementation methods, in a second possible implementation method of the first aspect, the CRP routing table entry information further includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following next hop attribute information types: bandwidth, load balancing ratio, and next hop type.

[0012] By carrying the attribute information of the next hop in the CRP routing table entry information, the network device can obtain the attribute information of the next hop in the CRP routing table, and send the attribute information of the next hop to the forwarding information base (FIB) to guide message forwarding.

[0013] In combination with the first aspect and the above-mentioned possible implementation methods, in a third possible implementation method of the first aspect, the first message is a first update message BGP UPDATE Message. The first BGP UPDATE Message includes a multi-protocol extended reachable network layer reachability information (Multi-Protocol Reach Network Reachability Information, referred to as "MP_REACH_NLRI") attribute field. The MP_REACH_NLRI attribute field includes a sub-address family identifier SAFI field, a network layer reachable information NLRI field and a next hop information field. The SAFI field indicates that the MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family, and carries the first identification information. The NLRI field carries the routing prefix. The next hop information field carries the address of the first next hop.

[0014] The first identification information may be directly represented by the value of SAFI in the SAFI field.

[0015] Optionally, the NLRI field includes a Type Length Value (TLV) field, the Type T field of the TLV field indicates that the type of the TLV field is a BGP routing synchronization type, and the Value V field of the TLV field carries the routing prefix.

[0016] In combination with the first aspect and the above-mentioned possible implementation manner, in a fourth possible implementation manner of the first aspect, the first message is a first PCEP Message. The first PCEP Message includes a message type Message-Type field, a route object Route object field, and a next hop object Next Hop object field. The Message-Type field carries the first identification information. The Route object field carries the route prefix. The Next Hop object field carries the address of the first next hop.

[0017] The first identification information may be directly represented by the value of the Message-Type in the Message-Type field.

[0018] In combination with the second possible implementation of the first aspect, in a fifth possible implementation of the first aspect, the first message is a first BGP UPDATE Message. The first BGP UPDATE Message includes a multi-protocol reachable network layer reachable information MP_REACH_NLRI attribute field and a route synchronization attribute Route SynchronizationAttribute field. The MP_REACH_NLRI attribute field includes a sub-address family identifier SAFI field, a network layer reachable information NLRI field, and a next hop information field. The SAFI field indicates that the MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family and carries the first identification information. The NLRI field carries the route priority, and the next hop information field carries the address of the first next hop. The RouteSynchronization Attribute field carries the route priority. In an optional implementation, the Route Synchronization Attribute field includes a sub-TLV field, the sub-TLV field includes a T field, an L field, and a V field, the T field represents the route priority, and the V field indicates a value determined based on the route priority.

[0019] The first identification information may be directly represented by the value of SAFI in the SAFI field.

[0020] Optionally, the NLRI field includes a type-length-value TLV field, the type T field of the TLV field indicates that the type of the TLV field is a BGP routing synchronization type, and the value V field of the TLV field carries the routing prefix.

[0021] In combination with the second possible implementation of the first aspect, in a sixth possible implementation of the first aspect, the first message is a first PCEP Message. The first PCEP Message includes a message type Message-Type field, a route object Route object field, a next hop object Next Hop object field, and a route attribute object Route Attribute object field. The Message-Type field is used to carry the first identification information. The Route object field carries the route prefix. The Next Hop object field carries the address of the first next hop. The Route Attribute object field carries the route priority. In an optional implementation, the Route Attribute object field includes a sub-TLV field, the sub-TLV field includes a T field, an L field, and a V field, the T field represents the route priority, and the V field indicates a value determined based on the route priority.

[0022] The first identification information may be directly represented by the value of the Message-Type in the Message-Type field.

[0023] In combination with the third possible implementation manner of the first aspect, in a seventh possible implementation manner of the first aspect, the first message is a first BGP UPDATE Message. The first BGP UPDATE Message includes a multi-protocol reachable network layer reachable information MP_REACH_NLRI attribute field and a next hop attribute Next Hop Attribute field. The MP_REACH_NLRI attribute field includes a sub-address family identifier SAFI field, a network layer reachable information NLRI field, and a next hop information field. The SAFI field indicates the

[0024] The MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronous address family and carries the first identification information. The NLRI field carries the routing prefix. The next hop information field carries the address of the first next hop. The Next Hop Attribute field carries the attribute information of the first next hop. In an optional implementation, the Next Hop Attribute field includes at least one sub-TLV field, and the type of attribute information of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the types of attribute information of the next hop, and the V field indicates the content determined based on the attribute information type of the corresponding next hop.

[0025] The first identification information may be directly represented by the value of SAFI in the SAFI field.

[0026] In combination with the third possible implementation manner of the first aspect, in an eighth possible implementation manner of the first aspect, the first message is a first PCEP Message. The first PCEP Message includes a message type Message-Type field, a route object Route object field, a next hop object Next Hop object field, and a next hop attribute object Next Hop Attribute object field. The Message-Type field carries the first identification information. The Route object field carries the route prefix. The Next Hop object field carries the address of the first next hop. The Next Hop Attribute object carries the attribute information of the first next hop. In an optional implementation manner, the Next Hop Attribute object field includes at least one sub-TLV field, and the attribute information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the types of the attribute information of the next hop, and the V field indicates the content determined based on the type of the attribute information of the corresponding next hop.

[0027] The first identification information may be directly represented by the value of the Message-Type in the Message-Type field.

[0028] In combination with the first aspect and the above-mentioned possible implementations, in a ninth possible implementation of the first aspect, the method further includes: the controller generates a second message, and the second message carries the table entry information of the second next hop of the network device. The table entry information of the second next hop includes a mapping relationship between the address of the second next hop of the network device and the attribute information of the second next hop. The second message includes second identification information, and the second identification information is used to indicate that the network device saves the table entry information of the second next hop in the next hop table of the network device. The controller sends the second message to the network device so that the network device saves the table entry information of the second next hop in the next hop table of the network device according to the second identification information.

[0029] The address of the second next hop may be the same as or different from the address of the first next hop. The attribute information types of the second next hop include but are not limited to the following parameter types: the type of next hop access, such as Internet Protocol (IP) network, Virtual Extensible Local Area Network (VXLAN), etc.; available bandwidth (Band Width) and load balancing ratio (Weight), etc.

[0030] In the above technical solution, the controller sends the next hop information to the network device separately without binding the routing prefix. The network device saves the next hop address and next hop attribute information in a separately maintained next hop table, and the controller manages the next hop information of the network device separately. Separate management includes separate creation or update of next hop information. The above solution makes the controller more flexible in the next hop management of the network device; and effectively saves the system resources occupied by carrying the routing prefix in the information interaction between the controller and the network device for the next hop management; the information that the network device needs to parse is reduced, and the business processing efficiency of the network device is also improved.

[0031] Furthermore, when the controller independently sends the next hop information to the network device, it carries the attribute information of the next hop customized by the controller, and describes the differentiated features between the next hop and other next hops through the attribute information of the next hop, for example, some applications need to describe the available bandwidth of the next hop, the load balancing ratio of the next hop, etc. This allows the network device to obtain the attribute information of the next hop in the next hop table, and send the attribute information of the next hop to the FIB table for guiding packet forwarding.

[0032] In combination with the ninth possible implementation of the first aspect, in the tenth possible implementation of the first aspect, the second message is a second BGP UPDATE Message. The second BGP UPDATE Message includes a multi-protocol reachable network layer reachability information MP_REACH_NLRI attribute field and a next hop attribute Next Hop Attribute field. The MP_REACH_NLRI attribute field includes a sub-address family identifier SAFI field, a network layer reachability information NLRI field, and a next hop information field. The SAFI field indicates that the MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family and carries the second identification information. The NLRI field carries the address of the second next hop or the next hop information field carries the address of the second next hop. The Next Hop Attribute field carries the attribute information of the second next hop. In an optional implementation, the Next Hop Attribute field includes at least one sub-TLV field, and the attribute information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, wherein the T field represents any type of attribute information of the second next hop, and the V field indicates content determined based on the type of the corresponding attribute information of the second next hop.

[0033] The second identification information may be directly represented by the value of SAFI in the SAFI field.

[0034] In combination with the ninth possible implementation of the first aspect, in the eleventh possible implementation of the first aspect, the second message is a second PCEP Message. The second PCEP Message includes a message type Message-Type field, a next hop object Next Hop object field, and a next hop attribute object Next Hop Attributeobject field. The Message-Type field is used to carry the second identification information. The Next Hop object field carries the address of the second next hop. The Next Hop Attribute object field carries the attribute information of the second next hop. In an optional implementation, the Next Hop Attribute object field includes at least one sub-TLV field, and the attribute information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the attribute information types of the next hop, and the V field indicates the content determined based on the attribute information type of the corresponding next hop.

[0035] The second identification information may be directly represented by the value of the Message-Type in the Message-Type field.

[0036] Optionally, the first PCEP Message also includes a state request parameter (English: RequestParameters, RP) object field. The Message-Type carrying the second identification information specifically includes: the Message-Type field and the RP object field jointly carry the second identification information. That is, the second identification information can be jointly represented by the value of the Message-Type in the Message-Type field and the value of the R mark in the RP object field.

[0037] In combination with the first aspect and the above-mentioned possible implementation manners, in a twelfth possible implementation manner of the first aspect, the method further includes: the controller generates a third message, the third message carries the address of the third next hop of the network device. The third message includes third identification information, and the third identification information is used to instruct the network device to delete the entry of the third next hop corresponding to the address of the third next hop in the next hop table stored locally. The controller sends the third message to the network device so that the network device deletes the entry of the third next hop according to the instruction of the third identification information.

[0038] It can be seen that, through the first message carrying the first next hop address sent by the controller, the network device deletes the first next hop table entry corresponding to the first next hop address in the separately stored next hop table according to the first identification information carried in the first message, and there is no need to bundle routing prefixes and delete an unavailable next hop by revoking a large number of routing messages, thus saving network resources. Moreover, when there are multiple routing table entries corresponding to the same next hop at the same time, by deleting the next hops corresponding to the multiple routing table entries, multiple routing table entries using the next hop can be deleted. Therefore, only one message needs to be sent between the controller and the network device to achieve the purpose of fast and batch deletion of routing table entries. Therefore, the number of interactive messages between the controller and the forwarding device is greatly reduced, system resources are saved, and business processing efficiency is improved.

[0039] In combination with the twelfth possible implementation of the first aspect, in the thirteenth possible implementation of the first aspect, the third message is a third BGP UPDATE Message. The third BGP UPDATE Message includes a multi-protocol unreachable network layer reachability information (Multi-Protocol Unreach Network reachability Information, MP_UNREACH_NLRI) attribute field. The MP_UNREACH_NLRI attribute field includes a sub-address family identifier SAFI field and an unreachable network layer unreachability information NLRI field. The SAFI field indicates that the MP_UNREACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family, and carries the third identification information. The unreachable NLRI field carries the address of the third next hop.

[0040] The third identification information may be directly represented by the value of SAFI in the SAFI field.

[0041] In combination with the twelfth possible implementation manner of the first aspect, in the fourteenth possible implementation manner of the first aspect, the third message is a third PCEP Message. The third PCEP Message includes a message type Message-Type field and a next hop object Next Hop object field. The Message-Type field indicates that the third PCEP Message is used to send the address of the third next hop to the network device and is used to carry the third identification information. The Next Hop object field carries the address of the third next hop.

[0042] The third identification information may be directly represented by the value of the Message-Type in the Message-Type field.

[0043] In combination with the fourteenth possible implementation of the first aspect, in the fifteenth possible implementation of the first aspect, the third PCEP Message also includes a state request parameter (English: Request Parameters, RP) object field. The Message-Type carrying the third identification information specifically includes: the Message-Type field and the RP object field jointly carry the third identification information. That is, the third identification information can be jointly represented by the value of the Message-Type in the Message-Type field and the value of the R mark in the RP object field.

[0044] In combination with the first aspect and the above-mentioned possible implementations, in a sixteenth possible implementation of the first aspect, the method further includes: the controller receives a fourth message sent by the network device. The fourth message carries routing status report information, and the routing status report information includes a mapping relationship between the routing prefix and the status information of the CRP route. The controller updates the statistical information of the routing prefix according to the received routing status report information as a basis for recalculating the CRP route.

[0045] The status information of the CRP route includes but is not limited to: the status of the route, such as whether the route is legal, whether it is preferred, whether it is sent to the FIB, etc.; the survival time of the route; the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the bandwidth occupancy ratio of the next hop; the packet loss rate of the next hop; the packet sending delay of the next hop; and the survival time of the next hop.

[0046] Therefore, the controller can regularly and in real time obtain the routing status information reported by the network equipment, and can understand the routing status of the network equipment in real time as a basis for adjusting the routing, thereby improving the reliability and real-time performance of traffic control.

[0047] In combination with the first aspect and the above-mentioned possible implementation methods, in the seventeenth possible implementation method of the first aspect, the method also includes: the controller receives a fifth message sent by the network device; the fifth message carries next-hop status report information, and the next-hop status report information includes a mapping relationship between the address of the fourth next hop of the network device and the status information of the fourth next hop; the controller updates the statistical information of the fourth next hop according to the received next-hop status report information as a basis for recalculating the next hop of the network device.

[0048] The next hop status report information includes but is not limited to: the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the next hop bandwidth occupancy ratio; the next hop packet loss rate; the next hop packet sending delay; and the next hop survival time.

[0049] Therefore, the controller can regularly and in real time obtain the next-hop status information reported by the forwarding device, and can understand the status of the forwarding device in real time as a basis for calculation and adjustment of the next hop, thereby improving the reliability and real-time performance of traffic control.

[0050] In the second aspect, an embodiment of the present application provides a method for information synchronization, first, a network device receives a first message sent by a controller; the first message carries the control routing protocol CRP routing table entry information determined by the controller, which is used to publish the CRP route. The CRP routing table entry information includes a mapping relationship between a routing prefix and an address of the first next hop of the network device, and the first message includes first identification information. Then, the network device saves the CRP routing table entry information in a local CRP routing table according to the indication of the first identification information, and guides message forwarding according to the CRP routing table.

[0051] By running the CRP protocol between the controller and the network device, a separate CRP routing table is created on the network device to store the CRP routing table entry information sent by the controller. Since the CRP routes published by the controller and the routes published by the routing protocol between the network devices are stored in different routing tables, the routing policies related to the CRP routes will not affect the related applications of the routing policies reflected in the routes in the routing protocol between the network devices.

[0052] In combination with the second aspect, in a first possible implementation manner of the second aspect, the CRP routing table entry information further includes a routing priority, where the routing priority is used to identify a priority of the CRP route when being used to guide message forwarding.

[0053] By carrying the route priority in the CRP route table information, the CRP route priority can be flexibly set. For example, the CRP route can be set as the preferred route, so as to achieve the purpose of controlling the traffic using the route published by the controller. For various subsequent complex policy controls on routes, it can be completed by upgrading the controller, without the need for all devices to implement complex policies like existing routing policies, such as BGP routing policies. Therefore, traffic regulation is simpler and more flexible. In addition, in some application scenarios, customers believe that internally deployed IGP routes are trusted and should be preferred, while external routes are untrusted and should not be preferred. In this way, the priority of the CRP route can also be set to be lower than the priority of the ISIS route and the OSPF route. It can be seen that by setting the priority of the CRP route, the different needs of customers can be met.

[0054] In combination with the second aspect and the above possible implementation manner, in a second possible implementation manner of the second aspect, the CRP routing table entry information further includes attribute information of the first next hop, and the attribute information of the first next hop includes the following one or more types of attribute information of the next hop: bandwidth, load balancing ratio, and type of next hop access. The method also includes:

[0055] The network device saves the address of the first next hop and the attribute information of the first next hop in the first next hop entry of the next hop table of the network device, and the first next hop entry records the mapping relationship between the address of the first next hop and the attribute information of the first next hop.

[0056] By carrying the attribute information of the next hop in the CRP routing table entry information, the network device can obtain the attribute information of the next hop in the CRP routing table, and send the attribute information of the next hop to the FIB to guide message forwarding.

[0057] In combination with the second possible implementation method of the second aspect, in a third possible implementation method of the second aspect, the method also includes: the network device obtains attribute information of the first next hop, and sends the attribute information of the first next hop to a forwarding information table for guiding message forwarding.

[0058] In combination with the second aspect and the foregoing possible implementation manners, in a fourth possible implementation manner of the second aspect, the method further includes:

[0059] The network device receives a second message sent by the controller; the second message carries the table entry information of the second next hop of the network device. The table entry information of the second next hop records the mapping relationship between the address of the second next hop of the network device and the attribute information of the second next hop. The second message includes second identification information; the network device saves the table entry information of the second next hop in the next hop table of the network device according to the indication of the second identification information.

[0060] Therefore, the controller sends the next hop information to the network device separately without binding the routing prefix. The network device saves the next hop address and the next hop attribute information in the separately maintained next hop table, and the controller manages the next hop information of the network device separately, and the separate management includes creating or updating the next hop information separately. The above scheme makes the controller more flexible in the next hop management of the network device; and effectively saves the system resources occupied by the routing prefix in the information interaction between the controller and the network device for the next hop management; the information that the network device needs to parse is reduced, and the business processing efficiency of the network device is also improved. When the controller sends the next hop information to the network device independently, it carries the next hop attribute information associated with the next hop customized by the controller, and describes the different differentiation features between the next hop and other next hops through the next hop attribute information, for example, some applications need to describe the available bandwidth of the next hop, the load balancing ratio of the next hop, etc. The network device can obtain the next hop attribute information in the next hop table, and send the next hop attribute information to the forwarding information table (English: Forwarding Information Base, FIB) table for guiding message forwarding.

[0061] In combination with the fourth possible implementation method of the second aspect, in the fifth possible implementation method of the second aspect, the method also includes: the network device uses the address of the second next hop as a keyword to search the next hop table, obtain the attribute information of the second next hop, and sends the attribute information of the second next hop to the forwarding information table to guide packet forwarding.

[0062] In combination with the second aspect and the foregoing possible implementation manners, in a sixth possible implementation manner of the second aspect, the method further includes:

[0063] The network device receives a third message sent by the controller; the third message carries the address of the third next hop of the network device, and the third message includes third identification information; the network device deletes the table entry of the third next hop corresponding to the address of the third next hop in the next hop table saved by the network device according to the indication of the third identification information.

[0064] It can be seen that through the first message carrying the first next hop address sent by the controller, the network device deletes the first next hop table entry corresponding to the first next hop address in a separately stored next hop table according to the first identification information carried in the first message. There is no need to bundle routing prefixes and to delete an unavailable next hop by revoking a large number of routing messages, thereby saving network resources.

[0065] In combination with the sixth possible implementation manner of the second aspect, in a seventh possible implementation manner of the second aspect, the network device deletes, according to an instruction of the third identification information, an entry of a third next hop corresponding to the address of the third next hop in the next hop table stored by the network device, specifically including:

[0066] The network device searches the next hop table according to the instruction of the third identification information and takes the address of the third next hop as a keyword, hits the table entry of the third next hop, and deletes the table entry of the third next hop.

[0067] In combination with the seventh possible implementation manner of the second aspect, in an eighth possible implementation manner of the second aspect, the method further includes:

[0068] The network device deletes the routing table entry associated with the address of the third next hop.

[0069] When there are multiple routing table entries corresponding to the same next hop at the same time, the controller determines that the next hop is unavailable, and by deleting the next hop, multiple routing table entries using the next hop can be deleted. Therefore, only one message needs to be sent between the controller and the network device to achieve the purpose of fast and batch deletion of routing table entries. This greatly reduces the number of interactive messages between the controller and the forwarding device, saves system resources, and improves business processing efficiency.

[0070] In combination with the second aspect and the foregoing possible implementation manners, in a ninth possible implementation manner of the second aspect, the method further includes:

[0071] The network device generates a fourth message, the fourth message carries routing status report information, and the routing status report information records a mapping relationship between the routing prefix and the status information of the CRP route;

[0072] The network device sends the fourth message to the controller, so that the controller updates the statistical information of the routing prefix according to the received routing status report information as a basis for recalculating the CRP route.

[0073] The status information of the CRP route includes but is not limited to: the status of the route, such as whether the route is legal, whether it is preferred, whether it is sent to the FIB, etc.; the survival time of the route; the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the bandwidth occupancy ratio of the next hop; the packet loss rate of the next hop; the packet sending delay of the next hop; and the survival time of the next hop.

[0074] Therefore, the controller can regularly and in real time obtain the routing status information reported by the network equipment, and can understand the routing status of the network equipment in real time as a basis for adjusting the routing, thereby improving the reliability and real-time performance of traffic control.

[0075] In combination with the ninth possible implementation of the second aspect, in the tenth possible implementation of the second aspect, the fourth message is a fourth BGP UPDATE Message. The fourth BGP UPDATE Message includes an MP_REACH_NLRI attribute field and a Route Status Report Attribute field. The MP_REACH_NLRI attribute field includes an NLRI field, and the NLRI field is used to carry the route prefix. The RouteStatus Report Attribute field is used to carry the status information of the CRP route. In an optional implementation, the Route Status Report Attribute field includes at least one sub-TLV field, and each type of status information of the CRP route corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the CRP route, and the V field indicates the content determined based on the corresponding status information type of the CRP route.

[0076] In combination with the ninth possible implementation manner of the second aspect, in the eleventh possible implementation manner of the second aspect, the fourth message is a fourth PCEP Message. The fourth PCEP Message includes a message type Message-Type field, a route object Route object field, and a route status report attribute object Route Status ReportAttribute object field. The Message-Type field indicates that the fourth PCEP Message is used to send the route status report information to the controller. The Route object field carries the route prefix. The RouteStatus Report Attribute object field carries the status information of the CRP route. In an optional implementation manner, the Route Status Report Attribute object field includes at least one sub-TLV field, and each status information type of the CRP route corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the CRP route, and the V field indicates the content determined based on the corresponding status information type of the CRP route.

[0077] In combination with the second aspect and the foregoing possible implementation manners, in a twelfth possible implementation manner of the second aspect, the method further includes:

[0078] The network device generates a fifth message; the fifth message carries next hop status report information, and the next hop status report information includes a mapping relationship between the address of the fourth next hop of the network device and the status information of the fourth next hop. The network device sends the fifth message to the controller so that the controller updates the statistical information of the next hop according to the received next hop status report information as a basis for recalculating the next hop of the network device.

[0079] The next hop status report information includes but is not limited to: the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the next hop bandwidth occupancy ratio; the next hop packet loss rate; the next hop packet sending delay; and the next hop survival time.

[0080] Therefore, the controller can regularly and in real time obtain the next-hop status information reported by the forwarding device, and can understand the status of the forwarding device in real time as a basis for calculation and adjustment of the next hop, thereby improving the reliability and real-time performance of traffic control.

[0081] In combination with the twelfth possible implementation manner of the second aspect, in the thirteenth possible implementation manner of the second aspect, the fifth message is the fifth BGP UPDATE Message. The fifth BGP UPDATE Message includes a multi-protocol reachable network layer reachable information MP_REACH_NLRI attribute field and a next hop status report attribute Next Hop StatusReport Attribute field. The MP_REACH_NLRI attribute field includes a network layer reachable information NLRI field, and the NLRI field is used to carry the address of the fourth next hop. The Next Hop Status Report Attribute field is used to carry the status information of the fourth next hop. In an optional implementation manner, the Next Hop StatusReport Attribute field includes at least one sub-TLV field, and the status information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the next hop, and the V field indicates the content determined based on the status information type of the corresponding next hop.

[0082] In combination with the twelfth possible implementation manner of the second aspect, in the fourteenth possible implementation manner of the second aspect, the fifth message is a fifth PCEP Message. The fifth PCEP Message includes a message type Message-Type field, a next hop object Next Hop object field, and a next hop status report attribute object Next HopStatus Report Attribute object field. The Message-Type field indicates that the fifth PCEPMessage is used to send the next hop status report information to the controller. The Next Hop object field carries the address of the fourth next hop. The Next Hop Status Report Attribute object field carries the status information of the fourth next hop. In an optional implementation manner, the Next Hop Status ReportAttribute object field includes at least one sub-TLV field, and the status information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the next hop, and the V field indicates the content determined based on the status information type of the corresponding next hop.

[0083] In a third aspect, an embodiment of the present application provides a controller for executing the method in the first aspect or any possible implementation of the first aspect. Specifically, the controller includes a module for executing the method in the first aspect or any possible implementation of the first aspect.

[0084] In a fourth aspect, an embodiment of the present application provides a network device for executing the method in the second aspect or any possible implementation of the second aspect. Specifically, the network device includes a module for executing the method in the second aspect or any possible implementation of the second aspect.

[0085] In a fifth aspect, an embodiment of the present application provides a communication system, comprising the controller provided in the third aspect and the network device provided in the fourth aspect.

[0086] In a sixth aspect, an embodiment of the present application provides a controller, the controller comprising: an input interface, an output interface, a processor and a memory. The input interface, the output interface, the processor and the memory may be connected via a bus system. The memory is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the memory to complete the method in the first aspect or any possible implementation of the first aspect.

[0087] In a seventh aspect, an embodiment of the present application provides a network device, the network device comprising: an input interface, an output interface, a processor and a memory. The input interface, the output interface, the processor and the memory may be connected via a bus system. The memory is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the memory to complete the method in the second aspect or any possible implementation of the second aspect.

[0088] In an eighth aspect, the present application provides an embodiment of a computer-readable storage medium for storing a computer program for executing instructions of the method in the first aspect, the second aspect, any possible implementation of the first aspect, or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0090] Figure 1 A schematic diagram of a controller publishing a route in the prior art;

[0091] Figure 2 A schematic diagram of an application scenario according to an embodiment of the present application;

[0092] Figure 3 is a flow chart of a method for information synchronization according to an embodiment of the present application;

[0093] Figure 4 A schematic diagram of a multi-protocol extended reachable network layer reachability information MP_REACH_NLRI field encapsulated based on an encapsulation format supported by a BGP synchronization address family according to an embodiment of the present application;

[0094] Figure 5 is a schematic diagram of a TLV field in an NLRI field according to an embodiment of the present application;

[0095] Figure 6 Schematic diagram of the encapsulation format of a common message header of a PCEP Message according to an embodiment of the present application;

[0096] Figure 7 This is a schematic diagram of the encapsulation format of a common object header of an object object of a PCEP Message according to an embodiment of the present application;

[0097] Figure 8 1 is a schematic diagram of the encapsulation format of a route object in a PCEP Message according to an embodiment of the present application;

[0098] Fig. 9 Schematic diagram of the encapsulation format of a sub-object Sub-object in a route object Route object according to an embodiment of the present application;

[0099] Fig.10 This is a schematic diagram of the encapsulation format of a sub-object Sub-object in a route object Route object according to another embodiment of the present application;

[0100] Fig.11 2 is a schematic diagram of the encapsulation format of the Next Hop object in the PCEP Message according to an embodiment of the present application;

[0101] Fig.12 A schematic diagram of an MP_UNREACH_NLRI field encapsulated based on an encapsulation format supported by a BGP synchronization address family according to an embodiment of the present application;

[0102] Fig.13 is a schematic diagram of a controller according to an embodiment of the present application;

[0103] Fig.14is a schematic diagram of a network device according to an embodiment of the present application;

[0104] Fig.15 is a schematic diagram of the hardware structure of a controller according to an embodiment of the present application;

[0105] Fig.16 Schematic diagram of the hardware structure of a network device according to an embodiment of the present application. DETAILED DESCRIPTION

[0106] The application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person of ordinary skill in the art can appreciate that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0107] Unless otherwise specified, the ordinal numbers such as "first", "second", "third", "fourth" and "fifth" mentioned in the embodiments of the present application are used to distinguish multiple objects and are not used to limit the order of the multiple objects.

[0108] Combine the following Figure 2 The scenarios of the embodiments of the present application are described exemplarily.

[0109] Figure 2 The SDN 100 used in the embodiment of the present application is shown. The SDN 100 includes a controller 110 and a plurality of network devices 120. In the present application, the controller 110 may also be referred to as a control device, a control system, or a control node. Optionally, the controller 120 may specifically be a smart network controller (English: Smart Network Controller, SNC), but the embodiment of the present application is not limited thereto.

[0110] The network device 120 can be used to forward the message. The network device can be a traditional router, switch or other routing and forwarding device in a traditional path computation element (PCE) network, or a router or switch or other routing and forwarding device in an SDN based on control and forwarding separation, which is not limited in the embodiments of the present application.

[0111] Figure 2 Five routers are shown: R1 to R5, it should be understood that Figure 2 Only one controller and five routers are shown for example. The network 100 may include any other number of controllers and network devices, which is not limited in the embodiments of the present application.

[0112] The controller 110 collects the network element resource information and network topology information of each network device 120, determines the routing table information, generates the corresponding route, and publishes it to the network device 120. After receiving the route published by the controller, the network device 120 saves it in the routing table maintained separately by the network device 120. The routes published by the controller and the routes published through other protocols are sent to the Routing Management (RM) RIB, for example, Figure 1 The RMRIB and RM RIB shown select an optimal route through inter-protocol routing, which serves as the basis for the network device 120 to forward the message.

[0113] The following is combined with Figure 3 The information synchronization method 300 provided in the embodiment of the present application is described in detail. The method 300 can be applied to Figure 2 The SDN 100 shown in FIG. 1 is not limited thereto. Figure 3 As shown, the method includes:

[0114] S301. A controller determines control routing protocol (CRP) routing table entry information, where the CRP routing table entry information records a mapping relationship between a routing prefix and an address of a first next hop.

[0115] The "CRP" described in this application refers to: a protocol that runs between a controller and a forwarding device and supports the controller to publish routes to the forwarding device. Based on the CRP protocol, the forwarding device saves the routes generated and published by the controller into a routing table maintained separately by the forwarding device, which is called a "CRP routing table". The CRP protocol can be an extended protocol formed by the extension of an existing routing protocol so that it can carry the routes sent by the controller to the forwarding device, such as the BGP extension protocol formed by the extension of the existing routing protocol BGP, or the extended PCEP protocol formed by the extension of the existing PCEP protocol. The CRP protocol can also be an extension of the routing protocol used between newly created traditional forwarding devices. The CRP protocol can also be a newly created protocol specifically used for interaction between the controller and the traditional forwarding device and carrying the routing information sent by the controller. This application does not limit the specific protocol for carrying the routes laid down by the controller. In addition, the traditional forwarding device mentioned in the embodiment of the present application can be understood as a non-pure or hybrid SDN forwarding device, such as a forwarding device that has both the control and forwarding functions of a traditional forwarding device and the function of forwarding according to the routes published by the controller in the SDN control and forwarding separation scenario. In addition, the CRP routing table can be understood as a routing table for storing routes published by the controller, to distinguish it from other forms of routing tables, such as a routing table for storing routes published between forwarding devices. In the case where the CRP routing table item information is carried by means of an extended protocol, such as when carried by an extended BGP protocol, the network device will store a CRP routing table for routes published by the controller and a BGP routing table for storing ordinary BGP routes (such as routes published between network devices). The CRP routing table includes multiple routing table items, referred to as "CRP routing table items". The routing information recorded in each CRP routing table item is referred to as CRP routing table item information. The routes published by the controller to the forwarding device are referred to as "CRP routes".

[0116] For example, the CRP routing table may be as shown in Table 1:

[0117]

[0118] Table 1

[0119] As shown in Table 1, the CRP routing table includes multiple CRP routing table entries. The fields in CRP routing table 1 are explained as follows:

[0120] Network field: indicates the routing prefix, usually expressed as destination address / mask. If a natural mask is used, the mask can be omitted.

[0121] Next-Hop field: indicates the address of the next hop;

[0122] Status field: indicates the routing status;

[0123] Preference field: indicates the routing priority; the routing priority is used to indicate the priority of the CRP routing when guiding message forwarding. The smaller the value of the routing priority, the higher the routing priority. The priority of the CRP routing can be flexibly set through the Preference field.

[0124] Topology field: indicates the topology identifier of the network device. When the corresponding topology identifier is specified, the corresponding topology is used according to the specified identifier information; if no specific identifier is specified, the default global topology is used.

[0125] Band Width field: indicates the available bandwidth of the next hop.

[0126] When the controller publishes CRP routes to network devices, each CRP route table entry must at least include the mapping relationship between the route prefix and the next hop address, and the information contained in other fields is optional and can be configured by default. After the network device receives the message, it can forward the message to the next hop network device according to the guidance of the CRP route table.

[0127] In a specific implementation, the above-mentioned "Status" field may be composed of 32 bits, each bit representing a routing state. For example, the encapsulation format of the "Status" field is shown in Table 2:

[0128] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 V B A R

[0129] Table 2

[0130] V—Valid, 1 indicates a valid route, 0 indicates an invalid route;

[0131] B—Best, 1 indicates the best route, 0 indicates a non-optimal route;

[0132] A—Active, 1 indicates an activated route, 0 indicates an inactivated route;

[0133] D—Download to FIB, 1 means the route is sent to FIB, 0 means the route is not sent to FIB.

[0134] The following are examples of "Status" encoding:

[0135] 0x80000000: Only the V bit is 1, indicating that the route is a legal route, a non-optimal route, an inactive route, and has not been sent to the FIB.

[0136] 0xD0000000: The V, B, and D bits are 1, and the A bit is 0, indicating that the route is legal, optimal, and has been sent to the FIB, but the route is not activated.

[0137] This application only takes the above four bits as an example to illustrate how to use the Status field in the CRP routing table. Those skilled in the art can understand that in the above four bits, 0 and 1 can also represent opposite meanings, such as:

[0138] V—Valid, 0 indicates a valid route, 1 indicates an invalid route;

[0139] B—Best, 0 indicates the best route, 1 indicates a non-optimal route;

[0140] A—Active, 0 indicates an activated route, 1 indicates an inactivated route;

[0141] D—Download to FIB. 0 means the route is sent to FIB, and 1 means the route is not sent to FIB.

[0142] Other numerical values ​​may also be used to represent the above status information, and the embodiments of the present application do not specifically limit this.

[0143] Those skilled in the art will appreciate that the Status field may also be encapsulated in other encapsulation formats, which is merely an exemplary description and should not be construed as a limitation to the present application.

[0144] It should be understood that the various information listed in Table 1 is only an example and does not limit the present application. In addition, although Table 1 lists various information, those skilled in the art can understand that the CRP routing table entry information does not necessarily include all information. Alternatively, the CRP routing table entry information may also include information represented by other fields not listed here, and the embodiments of the present application do not specifically limit this.

[0145] In a specific implementation, the controller may be used to control network traffic and send control routing information to the network device. For example, the controller may be Figure 2 The controller 110 shown. The network device may be specifically Figure 2 Any one of R1 to R5 shown. As an optional example, the controller may be specifically an SNC, but this embodiment of the application is not limited to this.

[0146] The controller calculates the CRP route and determines the CRP route entry information by collecting the network element resource information and network topology information of each network device. The network element resource information includes but is not limited to label information, interface resource information, virtual local area network (English: Virtual Local Area Network, VLAN) information and tunnel ID. The network topology information is information that describes the connection relationship between nodes and links in the network and between nodes. The controller can obtain the topology information of the entire network based on various existing topology collection protocols, such as the Interior Gateway Protocol (English: Interior Gateway Protocol, IGP), ISIS protocol, and OSPF protocol. The network topology information includes but is not limited to the path information between each network device in SDN. Optionally, the network topology information also includes weight information of the paths between each network device, etc.

[0147] S302: The controller generates a first message for publishing a CRP route.

[0148] Specifically, the controller generates a first message, the first message carries the CRP routing table entry information, and is used to publish the CRP route. The first message includes first identification information, and the first identification information is used to instruct the network device to save the CRP routing table entry information in the CRP routing table of the network device.

[0149] The network device may specifically be a switch or a router. Figure 2 Any one of R1 to R5 shown.

[0150] In a specific implementation, the first message may be a first BGP update message BGP UPDATEMessage. The first BGP UPDATE Message includes an MP_REACH_NLRI attribute field. The MP_REACH_NLRI attribute field includes a Subsequent Address Family Identifier (SAFI) field, a Network Layer Reachability Information NLRI field, and a Next Hop Information field. The SAFI field indicates that the MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family and carries the first identification information. The NLRI field carries the routing prefix, and the next hop information field carries the address of the first next hop.

[0151] The first identification information is directly represented by the value of SAFI in the SAFI field of the BGP synchronization address family.

[0152] In the embodiment of the present application, a new BGP synchronization address family can be added to the existing BGP address family, and the above CRP routing table entry information can be encapsulated based on the encapsulation format supported by the new BGP synchronization address family. Specifically, the encapsulation format of the new MP_REACH_NLRI of the BGP synchronization address family is as follows: Figure 4 shown.

[0153] Figure 4 It is a schematic diagram of the MP_REACH_NLRI attribute field encapsulated based on the encapsulation format indicated by the BGP synchronization address family according to an embodiment of the present application.

[0154] MP_REACH_NLRI can be understood as the multi-protocol extended attribute information of NLRI, which includes three parts: address family information field, next hop information field, and network layer reachability information (NLRI) field.

[0155] The address family information field includes an address family identifier field (2 bytes) and a sub-address family identifier field (1 byte). The address family identifier (AFI) is used to identify the network layer protocol. For example, AFI is 1, indicating IPv4; AFI is 2, indicating IPv6. SAFI identifies the type of the sub-address family. For example, SAFI is 1, indicating unicast; SAFI is 2, indicating multicast; SAFI is 128, indicating a virtual private network (VPN). More specifically, an AFI value of 1 and a SAFI value of 1 indicate that the NLRI field carries an IPv4 unicast route; an AFI value of 1 and a SAFI value of 128 indicate that the NLRI field carries a BGP-VPNv4 route; an AFI value of 1 and a SAFI value of 4 indicate that the NLRI field carries a BGP label route.

[0156] In the embodiment of the present application, the BGP synchronization address family can be understood as a sub-address family extended in the IPv4 or IPv6 address family in the existing BGP protocol, that is, the AFI value can be 1 or 2. The value of SAFI can be determined according to the standards formulated by the Internet Engineering Task Force (IETF).

[0157] The next hop information field includes the next hop address length field (1 byte) and the next hop address field (variable length). The next hop address length field is used to identify the length of the next hop address field, and the length of the next hop address field is determined by the length identified by the next hop address length field.

[0158] A 1-byte reserved field is left between the next hop information field and the NLRI field.

[0159] The NLRI domain includes an NLRI field.

[0160] In a specific implementation, the NLRI field may consist of a two-tuple: <length-prefix>Length: indicates the length of the route prefix in bytes. Prefix: contains the route prefix, followed by padding bits to ensure that the end of the field conforms to the byte boundary. The value of the padding bits is meaningless.

[0161] In another specific embodiment, the NLRI field includes a TLV field (variable length). Figure 5 It is a schematic diagram of the TLV field in the NLRI field according to an embodiment of the present application. Among them, the type T field indicates that the type of the TLV field is the BGP synchronization type, the length L field indicates the length of the V field, and the value V field carries the content determined according to the BGP synchronization type. In the embodiment of the present application, specifically, when the T field value is 1, the BGP route synchronization (Route EntrySynchronization) type can be identified. Optionally, the L field value is 16 bits, that is, 2 bytes; the V field is a route prefix of the length indicated by the L field value. The BGP synchronization type includes the BGP route synchronization type.

[0162] It should be understood that the Type 1 type listed here as the BGP route synchronization type is only an exemplary description and should not constitute any limitation to the present application. The present application embodiment does not exclude the possibility of indicating other types through Type 1, or indicating the BGP route synchronization type in other ways. Moreover, the present application embodiment does not specifically limit the number of NLRI Type types.

[0163] In another specific implementation, the first message is a first PCEP message Message. The first PCEP Message includes a message type Message-Type field, a route object Route object field, and a next hop object Next Hop object field. The Message-Type field indicates that the first PCEP Message is used to publish the CRP route to the network device and is used to carry the first identification information. The Route object field carries the route prefix. The Next Hop object field carries the address of the first next hop.

[0164] The first identification information is directly represented by the value of the Message-Type in the Message-Type field.

[0165] In an embodiment of the present application, a new message type may be added to the existing Message-Type to indicate the first PCEP Message. In this embodiment of the present application, the first PCEP Message may also be referred to as a PCE-initiated Route Message. Typically, a PCEP Message consists of a common message header and a message body of variable length, and the message body consists of a series of objects. Specifically, the first PCEP Message includes a common message header, the route object, and the next hop object.

[0166] The encapsulation format of the common message header of the first PCEP Message is as follows: Figure 6 shown. Figure 6 This is a schematic diagram of the encapsulation format of a common message header of a first PCEP Message according to an embodiment of the present application.

[0167] The fields are explained as follows:

[0168] Version (Ver) field (3 bits): identifies the PCEP version number. The current version number is 1.

[0169] Flags field (5 bits): Flags. Currently, no flags are defined. The allocated 5 bits are reserved. The sender must set them to 0 and the receiver must ignore them.

[0170] Message Type field (8 bits): message type. To be defined.

[0171] In the embodiment of the present application, the Message-Type in the first PCEP Message (for example, the above-mentioned PCE-initiated Route Message) can be understood as a message type based on the Message-Type extension in the existing PCEP protocol, and the value of Message-Type can be determined according to the standard established by IETF.

[0172] Message-Length field (16 bits): the total length of the PCEP message (including the length of the common header), in bytes.

[0173] A PCEP Message object consists of a common object header and object body.

[0174] The encapsulation format of the common object header is as follows: Figure 7 As shown:

[0175] The fields in the public object header are explained as follows:

[0176] Object Class field (8 bits): identifies the type of PCEP object.

[0177] Object Type (OT) field (4 bits): identifies the type of PCEP object.

[0178] The Object-Class field and the OT field are managed by the Internet Assigned Numbers Authority (IANA) and together uniquely identify a PCEP object. For example, in the OPEN object of PCEP, the value of Object-Class is 1 and the value of Object-Type is 1, and the two together uniquely identify the OPEN object.

[0179] Usually, an Object-Class includes at least one Object-Type.

[0180] Reserved (Res) field (2 bits): a reserved field, filled with 0 when sending and ignored when receiving.

[0181] Processing rule flag (P) field (1 bit): processing rule. Not involved in this application.

[0182] Ignore Flag (I) field (1 bit): Ignore field. Not involved in this application.

[0183] Object Length field (16 bits): identifies the length of the object, including the length of the object header, in bytes.

[0184] Optionally, the object body includes a series of one or more optional sub-TLV fields. The sub-TLV fields include a T field, an L field, and a V field. The T field identifies the type of the sub-object, which occupies 2 bytes; the L field identifies the length of the sub-object, including the message header unit in bytes; the V field identifies the content determined according to the type of the sub-object.

[0185] Optionally, the object body includes a series of sub-objects, and the sub-objects may be encapsulated using the sub-object encapsulation format defined in RFC3209.

[0186] Specifically, as an example, the encapsulation format of the Route object is as follows: Figure 8 As shown:

[0187] The fields of the Route object are explained as follows:

[0188] The value of the object class (Object-Class) is to be defined and managed by IANA; the value of the object type (Object-Type, OT) is 1; Object-Class and Object-Type together uniquely identify the Route object. The reserved (Res) field is filled with 0 when sent and ignored when received;

[0189] The Processing Rule Flag (P) field and the Ignore Flag (I) field are not used in this Route object and are set to 0.

[0190] The value of Object Length is the length of the Route object, including the object header.

[0191] The Route object includes one or more sub-objects Sub-object, and the sub-object has a variable length. The length of the sub-object field is determined by the length identified by the object length field.

[0192] In a specific implementation, the Sub-object in the Route object is an IPv4 prefix sub-object that carries an IPv4 address prefix. For example, Fig. 9 The encapsulation format shown is encapsulated, such as Fig. 9 As shown:

[0193] The fields of the IPv4 prefix sub-object are explained as follows:

[0194] Attribute (L) field of the sub-object: In the Route object, the L bit is not used yet and is set to 0.

[0195] Sub-object type (Type) field: The value is 0x01, indicating an IPv4 address. The value of Type is only for illustrative purposes and is not specifically limited.

[0196] Sub-object length (Length) field: the length of the sub-object.

[0197] IPv4 Address Field: IPv4 address. This address is treated as a prefix based on the following prefix length (PrefixLength). Bits beyond the prefix are ignored on reception and set to 0 on transmission.

[0198] Prefix length field: The length of the IPv4 prefix.

[0199] Padding field: Set to 0 when transmitting and ignored when receiving.

[0200] The content of an IPv4 prefix object is a 4-byte IPv4 address, a 1-byte prefix length and a 1-byte padding field. The abstract node represented by this sub-object is a series of nodes with the same IP address prefix. Among them, the prefix length of 32 indicates a single IPv4 node.

[0201] In another specific implementation, the Sub-object in the Route object is an IPv6 prefix sub-object that carries an IPv6 address prefix. Fig.10 The encapsulation format shown is encapsulated, such as Fig.10 As shown:

[0202] The fields of the IPv6 prefix sub-object are explained as follows:

[0203] Attribute (L) field of the sub-object: In the Route object, the L bit is not used yet and is set to 0.

[0204] Sub-object type (Type) field: The value is 0x02, indicating an IPv6 address.

[0205] Sub-object length (Length) field: the length of the sub-object.

[0206] IPv6 Address Field: IPv6 address. This address is treated as a prefix based on the following prefix length (PrefixLength). Bits beyond the prefix are ignored on reception and set to 0 on transmission.

[0207] Prefix length field: The length of the IPv6 prefix.

[0208] Padding field: Set to 0 when transmitting and ignored when receiving.

[0209] The content of an IPv6 prefix sub-object is a 16-byte IPv6 address, a 1-byte prefix length, and a 1-byte padding field. The abstract node represented by this sub-object is a series of nodes belonging to the same IP prefix. Among them, the prefix length of 128 represents a single IPv6 node.

[0210] It should be understood that the values ​​and / or lengths of the sub-segments listed here are only exemplary and should not constitute any limitation to the present application. The present embodiment does not exclude the possibility that the Object-Type field may have other values.

[0211] It should be understood that the encapsulation format of the Route object listed here is only for illustrative purposes, and the present application embodiment does not specifically limit the encapsulation format of the Route object and the values ​​of the relevant fields in the Route object. The present application embodiment does not exclude the possibility of encapsulating the Route object in other encapsulation formats.

[0212] Specifically, as an example, the encapsulation format of the next hop object Next Hop object is as follows: Fig.11 As shown:

[0213] The fields of the Next Hop object are explained as follows:

[0214] The value of the object class (Object-Class) is to be defined and managed by IANA. When the object type (Object-Type, OT) value is 1, the object body (Object body) carries a 4-byte IPv4 unicast address; when the value is 2, the Object body carries a 16-byte IPv6 unicast address. Object-Class and Object-Type together uniquely determine the Next Hop object.

[0215] The reserved (Res) field is filled with 0 when sent and ignored when received;

[0216] The Processing Rule Flag (P) field and the Ignore Flag (I) field are not used in this Route object and are set to 0.

[0217] The value of Object Length is the length of the Next Hop object, including the object header.

[0218] It should be understood that the values ​​and / or lengths of the sub-segments listed here are only exemplary and should not constitute any limitation to the present application. The present embodiment does not exclude the possibility that the Object-Type field may have other values.

[0219] S303: The controller sends the first message to the network device.

[0220] Specifically, the controller sends the first message to the network device, so that the network device saves the CRP routing table entry information in the CRP routing table of the network device according to the first identification information, and guides message forwarding according to the CRP routing table.

[0221] Optionally, the controller itself stores a CRP routing table. After determining the CRP routing table entry information, the controller stores the CRP routing table entry information in the CRP routing table stored in the controller.

[0222] S304: The network device receives the first message.

[0223] S305: The network device stores the CRP routing table entry information in the CRP routing table of the network device.

[0224] Specifically, after the network device receives the first message, it identifies, based on the first identification information carried in the first message, that the CRP routing table entry information carried in the first message needs to be saved in the local CRP routing table, and then saves the CRP routing table entry information in the local CRP routing table, and then can guide message forwarding according to the CRP routing table.

[0225] In a specific implementation, after receiving the first message, the network device uses the routing prefix carried in the first message as a keyword to search for an entry in the CRP routing table stored locally, and if a corresponding entry is hit, the CRP routing table entry information is used to update the corresponding information in the found entry. If no corresponding entry is hit, a CRP routing table entry is created, and the CRP routing table entry information is saved in the newly created CRP routing table entry.

[0226] Through the above technical solution, the CRP protocol is run between the controller and the forwarding device, and a separate CRP routing table is created on the forwarding device to store the CRP routing table item information sent by the controller. The preferred routes in the CRP routing table are added to the RM RIB, so that the RM module can perform routing selection among the routes generated by different routing protocols such as CRP routing, ISIS routing, BGP routing, and OSPF routing. And because the CRP routes published by the controller and the routes published by the routing protocol between the forwarding devices are stored in different routing tables, the routing policies related to the CRP routes will not affect the related applications of the routing policies embodied in the routes in the routing protocol between the forwarding devices.

[0227] Optionally, the CRP routing table entry information further includes: routing synchronization attribute information, where the routing synchronization attribute information is used by the controller to carry routing attribute information formulated by the controller when the controller sends a routing prefix.

[0228] The routing synchronization attributes include, but are not limited to: the routing priority, the topology, and attribute information of the next hop.

[0229] The attribute information of the next hop includes at least one attribute information type of the next hop. The attribute information type of the next hop includes but is not limited to: the type of next hop access, such as: Internet Protocol (English: Internet Protocol, IP) network, Virtual Extensible Local Area Network (Virtual Extensible Local Area Network, VXLAN), etc.; available bandwidth (Band Width) and load balancing ratio (Weight), etc.

[0230] In a specific implementation, in the above-mentioned embodiment in which the CRP routing table entry information is carried by the BGP UPDATE Message, the first BGP UPDATE Message also includes a route synchronization Route Synchronization attribute Attribute field. The Route Synchronization Attribute carries the route synchronization attribute information. Optionally, the Route Synchronization Attribute field includes at least one sub-TLV field, and each type of route synchronization attribute information corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the types of the route synchronization attribute information, and the V field indicates the content determined based on the corresponding route synchronization attribute information type. The type of the route synchronization attribute information includes the route priority.

[0231] In another specific implementation, in the above-mentioned embodiment in which the CRP routing table entry information is carried by a PCEP Message, the first PCEP Message further includes a PCEP routing attribute object Route Attribute object field, and the PCEP Route Attribute object field carries the routing synchronization attribute information. Optionally, the PCEP Route Attribute object field includes at least one sub-TLV field, each type of routing synchronization attribute information corresponds to a sub-TLV field in the at least one sub-TLV field, and each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the types of the routing synchronization attribute information, and the V field indicates the content determined based on the type of the corresponding routing synchronization attribute information. The type of the routing synchronization attribute information includes the routing priority.

[0232] In the above two implementation methods of carrying the routing synchronization attribute information, the specific content or value of the TLV can be set according to the specific circumstances of each message, and the same setting method or different setting methods can be adopted, and the present application does not limit this. In a specific embodiment, for example, when the T field is 1, the routing priority type can be identified; the L field is 2 bytes; the V field is the value of the specific routing priority, such as 3. For another example, when the T field is 2, the topology type can be identified; the L field is 2 bytes; the V field is a specific topology identifier, such as 1. When the T field is 3, the next hop available bandwidth type can be identified; the L field is 2 bytes; the V field is a specific available bandwidth value, such as 20000 kbit / sec. For another example, when the T field is 4, the next hop load balancing ratio type can be identified; the L field is 2 bytes; the V field is a specific load balancing ratio, such as 50%, indicating that the next hop participates in 50% load sharing.

[0233] It should be understood that the types of route synchronization attribute information listed above are only exemplary and should not constitute any limitation to the present application. The fields used to carry route synchronization attribute information are not limited to the above-mentioned Route SynchronizationAttribute field or Route Attribute object field, and can also be carried by other existing or newly added fields, which is not particularly limited in the present application. In addition, the Type 1 type listed here is the route priority type, the Type 2 type is the topology type, the Type 3 is the next hop available bandwidth type, and the Type 4 is the next hop load balancing ratio type, which should also not constitute any limitation to the present application. The embodiments of the present application do not exclude the possibility of indicating other types through Type 1 to Type 4, or indicating the route priority type, topology type, next hop available bandwidth type, and next hop load balancing ratio type in other ways. In addition, the embodiments of the present application do not particularly limit the number of types of route synchronization attribute information.

[0234] Optionally, in the present application, the next hop attribute field may be used alone to carry the attribute information of the next hop.

[0235] In a specific implementation, in the above-mentioned embodiment in which the CRP routing table entry information is carried by the BGP UPDATE Message, the first BGP UPDATE Message further includes a next hop attribute Next Hop Attribute field, and the Next Hop Attribute field carries the attribute information of the first next hop. Optionally, the Next HopAttribute field includes at least one sub-TLV field, and each attribute information type of the next hop corresponds to a sub-TLV field in the at least one sub-TLV field, and each sub-TLV field includes a T field, an L field, and a V field, and the T field represents any one of the types of the attribute information of the next hop, and the V field indicates the content determined based on the attribute information type of the corresponding next hop.

[0236] In another specific implementation, in the above-mentioned embodiment of using PCEP Message to carry the CRP routing table entry information, the first PCEP Message also includes a PCEP next hop attribute object Next Hop Attributeobject field, which carries the attribute information of the first next hop. Optionally, the PCEP Next HopAttribute object field includes at least one sub-TLV field, and each attribute information type of the next hop corresponds to a sub-TLV field in the at least one sub-TLV field, and each sub-TLV field includes a T field, an L field, and a V field, and the T field represents any one of the attribute information types of the next hop, and the V field indicates the content determined based on the attribute information type of the corresponding next hop.

[0237] In the above two implementations of using the next hop attribute field alone to carry the attribute information of the next hop, the specific content or value of the TLV can be set according to the specific circumstances of each message, and the same setting method or different setting methods can be used. This application does not limit this. In an embodiment of the present application, for example, when the T field is 1, the available bandwidth type can be identified; the L field is 2 bytes; the V field is the specific value of the available bandwidth, such as 20000 kbit / sec. For another example, when the T field is 2, the load balancing ratio type can be identified; the L field is 2 bytes; the V field is the specific load balancing ratio, such as 50%, indicating that the next hop participates in 50% load sharing.

[0238] It should be understood that the above-listed next hop attribute information types are only exemplary and should not constitute any limitation to the present application. The field used to carry the attribute information of the next hop is not limited to the above-mentioned Next Hop Attribute field or Next Hop Attribute object field, and can also be carried by other existing or newly added fields, which is not specifically limited in the present application. In addition, the Type 1 type listed here is the available bandwidth type, and the Type 2 type is the load balancing ratio type, which should also not constitute any limitation to the present application. The embodiments of the present application do not exclude the possibility of indicating other types through Type 1 and Type 2, or indicating the available bandwidth type and load balancing type in other ways. In addition, the embodiments of the present application do not specifically limit the number of Next Hop Attribute types.

[0239] In the present application, by carrying the route priority in the route attribute information, the CRP route priority can be flexibly set. For example, the CRP route is set as the preferred route, so as to achieve the purpose of controlling the traffic using the route published by the controller. For the subsequent various complex policy controls for the route, it can be completed by upgrading the controller, without the need for all devices to implement complex policies like the existing routing policies, such as BGP routing policies. Therefore, traffic regulation is simpler and more flexible. In addition, in some application scenarios, the customer believes that the internally deployed IGP route is trusted and should be preferred, while the external route is untrusted and should not be preferred, then the priority of the CRP route can also be set to be lower than the priority of the ISIS route and the OSPF route. It can be seen that by setting the priority of the CRP route, the different needs of customers can be met.

[0240] Furthermore, by carrying the attribute information of the next hop in the routing attribute information, the network device can obtain the attribute information of the next hop in the CRP routing table, and send the attribute information of the next hop to the FIB to guide message forwarding.

[0241] It should be noted that when the CRP routing table item information includes the routing synchronization attribute information, after the network device receives the first message, the routing synchronization attribute information is saved in the CRP routing table according to the instruction of the first identification information. Specifically, when the network device receives the first message, the routing prefix carried in the first message is used as the key value to perform a CRP routing table search, and if the corresponding table item is hit, the routing synchronization attribute information is used to update the corresponding information in the hit table item. If the corresponding table item is not hit, a new table item is created and the routing synchronization attribute information is saved in the new table item.

[0242] Furthermore, after the network device receives the first message, the attribute information of the next hop is saved in the local next hop table according to the instruction of the first identification information. Specifically, in addition to saving the attribute information of the first next hop in the CRP routing table, the network device also uses the address of the first next hop carried in the first message as the key value to search in the next hop table saved by itself. If the corresponding table entry is hit, the attribute information of the next hop is used to update the corresponding information in the found table entry. If the table entry is not hit, a new table entry is created to save the address of the first next hop and the attribute information of the first next hop.

[0243] It should be noted that when the first message does not carry the routing synchronization attribute information, the network device can process it with default values ​​according to the existing rules, for example: setting the inter-protocol routing priority to 1, not limiting the bandwidth of the next hop, not setting the load balancing ratio of the next hop, and not specifying the type of the next hop.

[0244] For example, the format of the next hop table may be as shown in Table 3:

[0245]

[0246] Table 3

[0247] As shown in Table 3, the next hop table includes multiple next hop entries, including multiple fields:

[0248] Next-Hop field: indicates the address of the next hop;

[0249] Type field: indicates the type of next-hop access, such as IP network, VXLAN, etc.

[0250] Status field: indicates the next hop status;

[0251] Band Width field: indicates the available bandwidth of the next hop;

[0252] Weight field: indicates the next hop load balancing ratio. Calculated as a percentage, 100 means that this next hop does not participate in load balancing.

[0253] In a specific implementation, the above "Status" field may be composed of 32 bits, each bit representing a next hop state. For example, the encapsulation format of the "Status" field is shown in Table 4:

[0254] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 V U

[0255] Table 4

[0256] V-valid, 1 indicates a valid next hop, 0 indicates an invalid next hop;

[0257] U-used, 1 indicates the next hop is used, and 0 indicates the next hop is not used.

[0258] Status encoding example description:

[0259] 0xC0000000: Both the V and U bits are 1, indicating that the next hop is legal and is being used.

[0260] This example uses the above two bits as an example to illustrate how to use the Status field in the next hop table in combination with this application. Those skilled in the art can understand that in the above two bits, 0 and 1 can also represent opposite meanings, such as:

[0261] V-valid, 0 indicates a valid next hop, 1 indicates an invalid next hop;

[0262] U-used, 0 indicates the next hop is used, and 1 indicates the next hop is not used.

[0263] Other numerical values ​​may also be used to represent the above status information, and the embodiments of the present application do not specifically limit this.

[0264] Those skilled in the art will appreciate that the Status field may also be encapsulated in other encapsulation formats, which is merely an exemplary description and should not be construed as a limitation to the present application.

[0265] It should be noted that the network device saves the next hop information in a table maintained separately by the network device, which is called the "next hop table".

[0266] In a specific implementation, only one next hop table is maintained in the network device, and the next hop table is associated with all routing tables maintained by the network device. Specifically, each next hop table entry in the next hop table records the mapping relationship between the address of the next hop and the attribute information of the next hop. The routing table records the mapping relationship between the routing prefix and the address of the next hop. There may be a situation in the routing table where multiple different routing prefixes correspond to the address of the same next hop A, that is, there are multiple routing table entries in the routing table, and the routing prefixes of the multiple routing table entries are different, but they all correspond to the address of the same next hop A. In the network device, there is also an entry in the next hop table for recording the address of the next hop A and the attribute information of the next hop A. The network device will associate the table entry of the next hop A with all routing table entries in the routing table that use the address of the next hop A.

[0267] The above-mentioned “all routing tables” include multiple routing tables used by the network device to store routes published through different protocols.

[0268] In another specific implementation, the network device independently maintains multiple next hop tables, each of which corresponds to a routing table storing routes published by each protocol, for example, next hop table 1 corresponds to an ISIS routing table, and next hop table 2 corresponds to a CRP routing table. That is, the multiple next hop tables are respectively associated with the multiple routing tables, in other words, there is a one-to-one mapping relationship between the multiple next hop tables and the multiple routing tables.

[0269] As an example, the address of the next hop can be used as an index to find all routing table entries using the address of the next hop. Those skilled in the art will understand that it is not excluded to use other fields as indexes to find routing table entries corresponding to the next hop address. This is only an exemplary description and should not be understood as a limitation on the present application.

[0270] Optionally, the network device itself stores a CRP table, the CRP table includes the CRP routing table and the next hop table. The CRP table includes multiple CRP table entries, the CRP table entries include the CRP routing table entries and the next hop table entries.

[0271] It should be understood that the table entry information of the next hop listed in Table 3 is only an example and does not limit the present application. In addition, although Table 3 lists a variety of information, those skilled in the art can understand that the table entry information of the next hop may include one or more of the multiple information, and does not necessarily include all the information. Alternatively, the table entry information of the next hop may also only include information represented by other fields not listed here, and the embodiments of the present application do not specifically limit this.

[0272] Optionally, the method 300 may further include S306-S310:

[0273] S306: The controller determines the entry information of the second next hop of the network device.

[0274] The entry information of the second next hop records the mapping relationship between the address of the second next hop and the attribute information of the second next hop. The address of the second next hop may be the same as the address of the first next hop, or may be different from the address of the first next hop.

[0275] The attribute information types of the second next hop include but are not limited to the following parameter types: the type of next hop access, such as IP, VXLAN, etc.; available bandwidth (Band Width) and load balancing ratio (Weight), etc.

[0276] S307: The controller generates a second message for sending the entry information of the second next hop.

[0277] Specifically, the controller generates a second message, the second message carries the table entry information of the second next hop, the second message includes second identification information, and the second identification information is used to instruct the network device to save the table entry information of the second next hop in a local next hop table. The table entry information of the next hop does not need to include a routing prefix, so that the controller can send the next hop information to the network device alone.

[0278] The second identification information is used to instruct the network device to save the entry information of the second next hop in a local next hop table, and specifically includes:

[0279] The second identification information is used to instruct the network device to create or update the entry information of the second next hop in the next hop table.

[0280] In a specific implementation manner, the second message is a second BGP UPDATE Message, and the second BGP UPDATE Message includes a multi-protocol reachable network layer reachability information MP_REACH_NLRI attribute field and a next hop attribute Next Hop Attribute field. The MP_REACH_NLRI attribute field includes a sub-address family identifier SAFI field, a network layer reachability information NLRI field, and a next hop information field. The SAFI field indicates that the MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family, and carries the second identification information. Among them, the second identification information can be directly represented by the value of SAFI in the SAFI field. The NLRI field carries the address of the second next hop or the next hop information field carries the address of the second next hop. Optionally, the NLRI field includes a type length value TLV field, the type T field of the TLV field indicates that the type of the TLV field is the next hop synchronization type, and the value V field of the TLV field carries the address of the second next hop. The Next Hop Attribute field carries the attribute information of the second next hop. Optionally, the Next Hop Attribute field includes at least one sub-TLV field, and each attribute information type of the next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the attribute information types of the second next hop, and the V field indicates content determined based on the corresponding attribute information type of the second next hop.

[0281] In another specific embodiment, the second message is a second PCEP Message. The second PCEP Message includes a message type Message-Type field, a next hop object Next Hop object field, and a next hop attribute object Next Hop Attribute object field. The Message-Type field is used to carry the second identification information. The Next Hop object field carries the address of the second next hop. The Next Hop Attribute object field carries the attribute information of the second next hop. Optionally, the Next Hop Attribute object field includes at least one sub-TLV field, and the attribute information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field, and each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the attribute information types of the next hop, and the V field indicates the content determined based on the attribute information type of the corresponding next hop.

[0282] In the embodiment of the present application, the Message-Type in the second PCEP Message can be understood as a message type based on the Message-Type extension in the existing PCEP protocol, and the value of the Message-Type can be determined according to the standard established by the IETF. By newly defining a Message-Type value, it is used to indicate that the second PCEP Message is a message for updating or creating a next hop. The second PCEP Message can also be called a PCE-initiatedNexthop Message.

[0283] Optionally, the second identification information is directly represented by the value of Message-Type in the Message-Type field.

[0284] Optionally, the second PCEP Message also includes a state request parameter (English: RequestParameters, RP) object field. The Message-Type field is used to carry the second identification information, specifically including the Message-Type field and the RP object field jointly carrying the second identification information, that is, the second identification information is jointly represented by the value of the Message-Type in the Message-Type field and the value of the R mark in the RP object field.

[0285] Specifically, the encapsulation format of the RP object and the interpretation of each field can refer to the relevant definition of RFC5440. The Message-Type field is used to identify that the second PCEP Message is a message used to send next-hop information separately, and the next-hop information includes at least the address of the next hop. When the R mark in the RP object is set to 0, the network device saves the table entry information of the second next hop in the local next-hop table. That is, the Message-Type field and the RP object field jointly carry the second identification information.

[0286] Those skilled in the art can understand that the field used to carry the second identification information together with the Message-Type field is not limited to the above-mentioned RP object field, and can also be carried by other existing or newly added fields, and the present application does not specifically limit this. Moreover, here, the example of setting the R mark to 0, the network device saves the table entry information of the second next hop in the local next hop table, which should not constitute any limitation to the present application. The embodiment of the present application does not exclude the possibility that the network device saves the table entry information of the second next hop when the R mark is set to 1 or other values.

[0287] In the above two implementation methods of carrying the attribute information of the next hop, the specific content or value of the TLV can be set according to the specific circumstances of each message, and the same setting method or different setting methods can be adopted, and this application does not limit this. In a specific embodiment, for example, when the T field is 1, the available bandwidth type can be identified; the L field is 2 bytes; the V field is the specific value of the available bandwidth, such as 20000 kbit / sec. For another example, when the T field is 2, the load balancing ratio type can be identified; the L field is 2 bytes; the V field is the specific load balancing ratio, such as 50%, indicating that the next hop participates in 50% of the load sharing.

[0288] It should be understood that the above-listed next-hop attribute information types are only illustrative and should not constitute any limitation to the present application. The field used to carry the attribute information of the next hop is not limited to the above-mentioned Next Hop Attribute field or Next Hop Attribute object field, and can also be carried by other existing or newly added fields, which is not specifically limited in the present application. In addition, the Type 1 type listed here is the available bandwidth type, and the Type 2 type is the load balancing ratio type, which should also not constitute any limitation to the present application. The embodiments of the present application do not exclude the possibility of indicating other types through Type 1 and Type 2, or indicating the available bandwidth type and load balancing type in other ways. In addition, the embodiments of the present application do not specifically limit the number of attribute information types for the next hop.

[0289] S308. The controller sends the second message to the network device.

[0290] Specifically, the controller sends the second message to the network device, so that the network device saves the entry information of the second next hop in the next hop table of the network device according to the second identification information.

[0291] Optionally, the controller itself stores a next hop table. After determining the entry information of the second next hop, the controller stores the entry information of the second next hop in the next hop table stored in the controller itself.

[0292] S309: The network device receives the second message.

[0293] S310. The network device saves the entry information of the second next hop in the next hop table.

[0294] In a specific implementation manner, the network device stores the entry information of the second next hop in the next hop table, specifically including:

[0295] After receiving the second message, the network device uses the address of the second next hop carried in the second message as a keyword to search for an entry in the next hop table stored in the network device, and if a corresponding entry is hit, the found entry is updated using the entry information of the second next hop. If no corresponding entry is hit, a new next hop entry is created, and the entry information of the second next hop is saved in the newly created next hop entry.

[0296] It should be noted that when the second message does not carry the attribute information of the second next hop, the network device can process it with default values ​​according to existing rules, for example: not limiting the bandwidth of the next hop, not setting the load balancing ratio of the next hop, and not specifying the type of next hop access.

[0297] Through the technical solution provided in this embodiment, the controller can send the next hop information to the forwarding device separately, so that the controller can manage the next hop information of the forwarding device separately. Separate management includes creating or updating the next hop information separately without binding the routing prefix. The above solution makes the controller more flexible in managing the next hop of the forwarding device; and effectively saves the system resources occupied by carrying the routing prefix in the information interaction between the controller and the forwarding device; the information that the forwarding device needs to parse is reduced, and the business processing efficiency of the forwarding device is also improved.

[0298] Furthermore, when the controller independently sends the next hop information to the forwarding device, it carries the attribute information of the next hop customized by the controller, so that the network device can obtain the attribute information of the next hop in the next hop table and send the attribute information of the next hop to the FIB table for guiding packet forwarding.

[0299] Optionally, the method may further include S311-S315.

[0300] S311. The controller generates a third message.

[0301] The third message carries the address of the third next hop of the network device, and the third message includes third identification information, and the third identification information is used to instruct the network device to delete the third next hop entry corresponding to the address of the third next hop in the locally stored next hop table.

[0302] In a specific implementation manner, the third message is a third BGP UPDATE Message.

[0303] The third BGP UPDATE Message includes a multi-protocol unreachable network layer reachability information MP_UNREACH_NLRI attribute field. The MP_UNREACH_NLRI attribute field includes a sub-address family identifier SAFI field and an unreachable network layer reachability information NLRI field. The SAFI field indicates that the MP_UNREACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family and carries the third identification information. Among them, the third identification information is directly represented by the value of SAFI in the BGP synchronization address family SAFI field. The unreachable NLRI field carries the address of the third next hop or the next hop information field carries the address of the third next hop.

[0304] The encapsulation format of the MP_UNREACH_NLRI newly added to the BGP synchronization address family is as follows: Fig.12 shown.

[0305] Among them, MP_UNREACH_NLRI can be understood as the multi-protocol extended attribute information of the network layer unreachable NLRI, which includes two parts: the address family information field and the unreachable network layer reachability information (NLRI) field.

[0306] For more information about the address family information field, see Figure 4 The relevant instructions will not be repeated here.

[0307] The Unreachable NLRI domain includes an Unreachable NLRI field.

[0308] In a specific implementation, the Unreachable NLRI field may consist of a two-tuple:<Length-Next Hop> Identifier. Length: Indicates the length of the next hop address field in bytes. Next Hop: Contains the address of the next hop, followed by padding bits to ensure that the end of the field conforms to the byte boundary. The value of the padding bit is meaningless.

[0309] In another specific implementation, the unreachable NLRI field may include a TLV field (variable length). The schematic diagram of the TLV field can be referred to Figure 5 . Among them, the type T field indicates that the type of the TLV field is the BGP synchronization type, the length L field indicates the length of the V field, and the value V field carries the content determined according to the BGP synchronization type. In an embodiment of the present application, specifically, when the T field value is 2, the next hop synchronization type can be identified. Optionally, the L field value is 16 bits, that is, 2 bytes, indicating the specific length value of the V field. For example: when the L field is 4, the V field is a 4-byte IPv4 address, and when the L field is 16, the V field is a 16-byte IPv6 address; the V field is a 2-byte address of the next hop.

[0310] It should be understood that the Type 2 type listed here as the next hop synchronization type is only an exemplary description and should not constitute any limitation to the present application. The embodiments of the present application do not exclude the possibility of indicating other types by Type 2 or indicating the next hop synchronization type in other ways. Moreover, the embodiments of the present application do not specifically limit the number of NLRI Type types.

[0311] In another specific implementation, the third message is a third PCEP Message. The third PCEP Message includes a message type Message-Type field and a next hop object Next Hop object field. The Message-Type field indicates that the third PCEP Message is used to send the address of the third next hop to the network device and is used to carry the third identification information. The third identification information is directly represented by the value of Message-Type in the Message-Type field. The Next Hop object field carries the address of the third next hop.

[0312] The encapsulation format of the third PCEP Message is the same as the encapsulation format of the second PCEP Message. For details, refer to the relevant description of the encapsulation format of the second PCEP Message in the above text.

[0313] In the embodiment of the present application, the Message-Type in the third PCEP Message can be understood as a message type based on the Message-Type extension in the existing PCEP protocol, and the value of the Message-Type can be determined according to the standard established by the IETF.

[0314] In a specific implementation, the third identification information is carried according to the extended Message-Type, which is used to instruct the network device to delete the entry of the third next hop corresponding to the address of the third next hop in the locally stored next hop table. The third identification information is directly represented by the value of Message-Type in the Message-Type field. The third PCEP Message can also be called a PCE-initiated Next Hop Message.

[0315] In another specific implementation, the third PCEP Message also includes a state request parameter (English: Request Parameters, RP) object field. The Message-Type field carries the third identification information, specifically including: the Message-Type field and the RP object field jointly carry the third identification information. That is, the third identification information is jointly represented by the value of the Message-Type in the Message-Type field and the value of the R mark in the RP object field.

[0316] Specifically, the interpretation of each field in the RP object can refer to the relevant definition of RFC5440. The Message-Type field is used to identify that the third PCEP Message is a message for sending the address of the third next hop. When the R flag in the RP object is set to 1, the network device deletes the entry of the third next hop corresponding to the address of the third next hop in the locally stored next hop table. That is, the Message-Type field and the RP object field jointly carry the third identification information.

[0317] Those skilled in the art will appreciate that the field used to carry the third identification information together with the Message-Type field is not limited to the above-mentioned RP object field, and can also be carried by other existing or newly added fields, and the present application does not specifically limit this. Furthermore, the R mark listed here is set to 1, and the network device deletes the entry of the third next hop corresponding to the address of the third next hop in the locally stored next hop table, which should also not constitute any limitation to the present application. It is also possible that when the R mark is set to 0 or other values, the network device deletes the entry of the third next hop. The embodiment of the present application does not exclude the possibility that the network device deletes the entry of the third next hop when the R mark is set to 0 or other values.

[0318] S312. The controller sends the third message to the network device.

[0319] S313: The network device receives the third message.

[0320] S314: The network device deletes the entry of the third next hop in the locally stored next hop table according to the instruction of the third identification information.

[0321] Specifically, after receiving the third message, the network device uses the address of the third next hop carried in the third message as a keyword to search for an entry in the next hop table stored in the network device, and if the entry of the third next hop is hit, the entry of the third next hop is deleted from the next hop table. If no corresponding entry is hit, the process ends.

[0322] Optionally, the method further includes:

[0323] S315. The network device deletes the routing table entry associated with the address of the third next hop.

[0324] Specifically, a plurality of routing tables are stored in the network device, and each routing table may record a routing table entry associated with the address of the third next hop. When the network device determines that the address of the third next hop is unavailable, the third next hop address is used as an index to find all routing table entries using the address of the third next hop, and all routing table entries associated with the address of the third next hop are deleted.

[0325] Through the technical solution provided by this embodiment, when multiple routing prefixes correspond to the same next hop at the same time, multiple routing table entries using the next hop can be deleted by deleting the next hops corresponding to the multiple routing prefixes. Only one message needs to be sent between the controller and the forwarding device to achieve the purpose of fast and batch deletion of routing table entries. Therefore, the number of interactive messages between the controller and the forwarding device is greatly reduced, system resources are saved, and business processing efficiency is improved.

[0326] It should be noted that the present application does not specifically limit the execution order of S301-S305, S306-S310 and S311-S315. For example, S306-S310 can be executed before S301-S305 or after S301-S305. S311-S315 can be executed before S306-S310 or after S306-S310.

[0327] Optionally, the method 300 may further include S316-S318:

[0328] S316: The network device generates a fourth message.

[0329] The fourth message carries routing status report information, and the routing status report information records the mapping relationship between the routing prefix and the status information of the CRP routing.

[0330] The status information of the CRP route includes, but is not limited to: the status of the route, such as whether the route is legal, whether it is preferred, whether it is sent to the FIB, etc.; the survival time of the route; the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the bandwidth occupancy ratio of the next hop; the packet loss rate of the next hop; the packet delay of the next hop; the survival time of the next hop. The status information related to the next hop (such as the status of the next hop, such as whether the next hop is legal, whether it is used, etc., the bandwidth occupancy ratio of the next hop, the packet loss rate of the next hop, the packet delay of the next hop, and the survival time of the next hop) can also be carried in the next hop status report information described in the following step 319. For details, please refer to the following description.

[0331] In a specific implementation, the fourth message is a fourth BGP UPDATE Message, and the fourth BGP UPDATE Message includes an MP_REACH_NLRI attribute field and a route status report attribute Route StatusReport Attribute field. The MP_REACH_NLRI attribute field includes an NLRI field. The NLRI field is used to carry the route prefix. The Route Status Report Attribute field is used to carry the status information of the CRP route. Optionally, the Route Status Report Attribute field includes at least one sub-TLV field, and the type of the status information of each CRP route corresponds to the at least one sub-TLV field, and each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the CRP route, and the V field indicates the content determined based on the corresponding CRP route status information type.

[0332] In another specific implementation, the fourth message is a fourth PCEP Message, and the fourth PCEP Message includes a message type Message-Type field, a route object Route object field, and a route status report attribute object Route Status Report Attribute object field. The Message-Type field indicates that the fourth PCEP Message is used to send the route status report information to the controller. The Route object field carries the route prefix. The Route Status Report Attribute object field carries the status information of the CRP route. Optional. The Route Status Report Attribute object field includes at least one sub-TLV field, and the type of the status information of each CRP route corresponds to the at least one sub-TLV field, and each sub-TLV field includes a T field, an L field, and a V field, and the T field represents any one of the status information types of the CRP route, and the V field indicates the content determined based on the corresponding CRP route status information type.

[0333] In an embodiment of the present application, for example, the T field is 1, which can identify the current status Status type of the CRP route; the L field is 2 bytes; the V field indicates the specific content of the current status Status of the CRP route, such as whether the current route is legal, whether it is preferred, whether it is activated, etc.

[0334] It should be understood that the Type 1 type listed here is the current status Status type of the CRP route for exemplary purposes only and should not constitute any limitation to the present application. The present application embodiment does not exclude the possibility of indicating other types through Type 1, or indicating the current status Status type of the CRP route in other ways. Moreover, the present application embodiment does not specifically limit the number of TLV Type types.

[0335] In a specific implementation, the network device locally stores a routing status report information table for storing the routing status report information. Optionally, the CRP table includes the routing status report information table. As an example, the routing status report information table is shown in Table 5:

[0336]

[0337]

[0338] Table 5

[0339] As shown in Table 5, the routing status report information table includes multiple fields, and each field is explained as follows:

[0340] Network field: indicates the routing prefix;

[0341] Next-Hop field: indicates the address of the next hop;

[0342] Status field: indicates the routing status;

[0343] Age field: indicates the survival time of the current route;

[0344] Band Width field: indicates the available bandwidth of the next hop.

[0345] For the encapsulation format and related descriptions of the Status field, please refer to Table 2 and the related descriptions of Table 2, which will not be repeated here.

[0346] It should be understood that the various state information listed in Table 5 is only an example and does not limit the present application. In addition, although various state information is listed in Table 5, those skilled in the art will understand that the routing state report information may include one or more of the various state information, and does not necessarily include all state information. Alternatively, the routing state report information may also only include state information represented by other fields not listed here, and the embodiments of the present application do not specifically limit this.

[0347] S317: The network device sends a fourth message to the controller.

[0348] In a specific implementation, the network device periodically reports the CRP route status information. For example, when the system is running stably, the network device reports the route status information such as traffic statistics information and bandwidth usage information to the controller once every 180 seconds through configuration or negotiation.

[0349] In another specific implementation, the network device reports the status information of the route in real time. For example, when an important event occurs in the system, such as when the table item corresponding to the route information changes from being preferred to no longer preferred, or when the route table item fails to iterate the tunnel, the network device reports the status information of the route to the controller.

[0350] S318. The controller receives the fourth message.

[0351] The controller updates the statistical information of the routing prefix according to the received routing status report information as a basis for recalculating the CRP route.

[0352] Through the above technical solution, the controller can regularly and in real time obtain the routing status information reported by the forwarding device, and can understand the status of the forwarding device in real time as a basis for adjusting the route, thereby improving the reliability and real-time performance of traffic control.

[0353] Optionally, the method 300 may further include S319-S321.

[0354] S319: The network device generates a fifth message.

[0355] The fifth message carries next hop status report information, and the next hop status report information records a mapping relationship between the address of the fourth next hop and the status information of the fourth next hop.

[0356] The next hop status report information includes but is not limited to: the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the next hop bandwidth occupancy ratio; the next hop packet loss rate; the next hop packet sending delay; and the next hop survival time.

[0357] In a specific embodiment, the fifth message is the fifth BGP UPDATE Message. The fifth BGP UPDATE Message includes a multi-protocol reachable network layer reachable information MP_REACH_NLRI attribute field and a next hop status report attribute Next Hop Status Report Attribute field. The MP_REACH_NLRI attribute field includes a network layer reachable information NLRI field, and the NLRI field is used to carry the address of the fourth next hop. The NextHop Status Report Attribute field is used to carry the status information of the fourth next hop. Optionally, the Next Hop Status Report Attribute field includes at least one sub-TLV field, and the status information type of each next hop corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the next hop, and the V field indicates the content determined based on the status information type of the corresponding next hop.

[0358] In another specific implementation, the fifth message is the fifth PCEP Message. The fifth PCEP Message includes a message type Message-Type field, a next hop object Next Hop object field, and a next hop status report attribute object Next Hop Status Report Attribute object field. The Message-Type field indicates that the fifth PCEP Message is used to send the next hop status report information to the controller. The NextHop object field carries the address of the fourth next hop. The Next Hop Status Report Attribute object field carries the status information of the fourth next hop. Optionally, the Next Hop Status ReportAttribute object field includes at least one sub-TLV field, and each next hop status information type corresponds to a sub-TLV field in the at least one sub-TLV field. Each sub-TLV field includes a T field, an L field, and a V field, the T field represents any one of the status information types of the next hop, and the V field indicates the content determined based on the corresponding next hop status information type.

[0359] In an embodiment of the present application, for example, the T field is 1, which can identify the Status type of the current status of the next hop; the L field is 2 bytes; the V field indicates the specific content of the next hop status Status, such as whether the current route is legal, whether it is preferred, whether it is activated, etc.

[0360] It should be understood that the Type 1 type listed here is only an exemplary description of the Status type of the current state of the next hop, and should not constitute any limitation to this application. The embodiment of the present application does not exclude the possibility of indicating other types by Type 1, or indicating the Status type of the current state of the next hop in other ways. In addition, the embodiment of the present application does not specifically limit the number of TLVType types.

[0361] In another specific implementation, the network device locally stores a next hop status report information table for storing the next hop status report information. Optionally, the CRP table includes the next hop status report information table. As an example, the next hop status report information table is shown in Table 6:

[0362]

[0363] Table 6

[0364] As shown in Table 6, the next hop status report information table includes multiple fields, and each field is explained as follows:

[0365] Next-Hop field: indicates the next hop network address;

[0366] Type field: indicates the next hop type;

[0367] Status field: indicates the next hop status;

[0368] Band Width field: indicates the available bandwidth of the next hop;

[0369] Weight field: indicates the next hop load balancing ratio;

[0370] Loss field: indicates the number of lost packets;

[0371] Delay field: indicates the delay in microseconds.

[0372] For the encapsulation format and related descriptions of the Status field, please refer to Table 4 and the related descriptions of Table 4, which will not be repeated here.

[0373] It should be understood that the various status information listed in Table 6 is only an example and does not limit the present application. In addition, although various status information is listed in Table 6, those skilled in the art can understand that the next hop status report information may include one or more of the various status information, and does not necessarily include all status information. Alternatively, the next hop status report information may also only include other status information represented by other fields not listed here, and the embodiments of the present application do not specifically limit this.

[0374] S320. The network device sends the fifth message to the controller.

[0375] In a specific implementation, the network device periodically reports the next hop status information. For example, when the system is running stably, the network device reports the next hop status information such as traffic statistics information and bandwidth usage information to the controller once every 180 seconds through configuration or negotiation.

[0376] In another specific implementation, the network device reports the state information of the next hop in real time. For example, when an important event occurs in the system, such as when the table entry corresponding to the next hop information changes from reachable to unreachable, or when the bandwidth usage rate of the egress link corresponding to the next hop exceeds a threshold (e.g., 90%), the network device reports the state information of the next hop to the controller.

[0377] S321. The controller receives the fifth message.

[0378] The controller updates the statistical information of the next hop information of the network device according to the received next hop status report information as a basis for recalculating the next hop information.

[0379] Through the above technical solution, the controller can regularly and in real time obtain the next-hop status information reported by the forwarding device, and can understand the status of the forwarding device in real time as a basis for calculation and adjustment of the next hop, thereby improving the reliability and real-time performance of traffic control.

[0380] It should be noted that the present application does not specifically limit the execution order of S301-S305, S306-S310, S311-S315, S316-S318 and S319-S321.

[0381] Above, combined Figures 2 to 12 The information synchronization method provided by the embodiment of the present application is described in detail. Figure 13-Figure 16 The following describes in detail an apparatus and system for information synchronization provided according to an embodiment of the present application.

[0382] Fig.13 is a schematic diagram of a controller 400 according to an embodiment of the present application. The controller 400 may be Figure 2 The controller 110 in the embodiment may be used to execute Figure 3 As shown in the method. Fig.13 As shown, the controller 400 includes: a processing module 401 and a sending module 402 .

[0383] The processing module 401 is used to determine the control routing protocol CRP routing table entry information, and the CRP routing table entry information includes a mapping relationship between a routing prefix and an address of a first next hop. The processing module 401 is also used to generate a first message, and the first message carries the CRP routing table entry information, and is used to publish a CRP route. The first message includes first identification information, and the first identification information is used to instruct the network device to save the CRP routing table entry information in the CRP routing table of the network device.

[0384] The sending module 402 is used to send the first message to the network device, so that the network device saves the CRP routing table entry information in the CRP routing table according to the first identification information, and guides message forwarding according to the CRP routing table.

[0385] In a specific embodiment, the first message is a first border gateway protocol BGP update message UPDATE Message. The first BGP UPDATE Message includes a multi-protocol reachable network layer reachable information MP_REACH_NLRI attribute field. The MP_REACH_NLRI attribute field includes a sub-address family identifier SAFI field, a network layer reachable information NLRI field, and a next hop information field. The SAFI field indicates that the MP_REACH_NLRI attribute field is encapsulated based on the encapsulation format supported by the BGP synchronization address family, and carries the first identification information. The NLRI field carries the routing prefix. Optionally, the NLRI field includes a type length value TLV field, the type T field of the TLV field indicates that the type of the TLV field is a BGP routing synchronization type, the value V field of the TLV field carries the routing prefix, and the next hop information field carries the address of the first next hop.

[0386] The first identification information may be directly represented by the value of SAFI in the SAFI field.

[0387] In another specific implementation, the first message is a first path computation unit communication protocol message PCEP Message, and the first PCEP Message includes a message type Message-Type field, a route object Routeobject field, and a next hop object Next Hop object field; the Message-Type field carries the first identification information, the Route object field carries the route prefix, and the Next Hop object field carries the address of the first next hop.

[0388] The first identification information may be directly represented by the value of the Message-Type in the Message-Type field.

[0389] Therefore, according to the controller of the embodiment of the present application, by running the CRP protocol between the controller and the network device, a separate CRP routing table is created on the network device to store the CRP routing table item information sent by the controller. The preferred routes in the CRP routing table are added to the RM RIB, so that the RM module can perform routing selection between routes generated by different routing protocols such as CRP routing, ISIS routing, BGP routing, and OSPF routing, and because the CRP routes issued by the controller and the routes issued by the routing protocol between the forwarding devices are stored in different routing tables, the routing policies related to the CRP routes will not affect the related applications of the routing policies embodied in the routes in the routing protocol between the forwarding devices.

[0390] Optionally, the CRP routing table entry information further includes: routing synchronization attribute information, where the routing synchronization attribute information is used by the controller to carry routing attribute information formulated by the controller when the controller sends a routing prefix.

[0391] The routing synchronization attributes include, but are not limited to: the routing priority, the topology, and attribute information of the next hop.

[0392] The attribute information of the first next hop includes one or more types of the following attribute information of the next hop: bandwidth, load balancing ratio, and type of the next hop.

[0393] In a specific implementation, in the above-mentioned embodiment of using BGP UPDATE Message to carry the CRP routing table entry information, the first BGP UPDATE Message also includes a route synchronization attribute field for carrying the route synchronization attribute. The specific carrying method, that is, what message structure or field format is used, can refer to the description of the corresponding part in the above-mentioned method embodiment, which will not be repeated here.

[0394] In another specific implementation, in the above-mentioned embodiment of using PCEP Message to carry the CRP routing table entry information, the first PCEP Message also includes a PCEP routing attribute object Route Attribute object field for carrying the routing synchronization attribute. The specific carrying method, that is, what message format and field format to use, etc., can refer to the description of the corresponding part in the above-mentioned method embodiment, which will not be repeated here.

[0395] In the above two implementation methods of carrying the routing synchronization attribute information, the specific content or value of the TLV can be set according to the specific situation of each message, and can adopt the same setting method or different setting methods, which is not limited in this application.

[0396] It should be noted that when the first message does not carry the routing synchronization attribute information, the network device can process it with default values ​​according to the existing rules, for example: setting the inter-protocol routing priority to 1, not limiting the bandwidth of the next hop, not setting the load balancing ratio of the next hop, and not specifying the type of the next hop.

[0397] By carrying the route priority in the route attribute information, the CRP route priority can be flexibly set. For example, the CRP route can be set as the preferred route, so as to achieve the purpose of controlling the traffic using the route published by the controller. For the subsequent various complex policy controls for the route, it can be completed by upgrading the controller, without the need for all devices to implement complex policies like the existing routing policies, such as BGP routing policies. Therefore, traffic regulation is simpler and more flexible. In addition, in some application scenarios, the customer believes that the internally deployed IGP route is trusted and should be preferred, while the external route is untrusted and should not be preferred, then the priority of the CRP route can also be set to be lower than the priority of the ISIS route and the OSPF route. It can be seen that by setting the priority of the CRP route, the different needs of customers can be met.

[0398] Optionally, in the present application, the next hop attribute field may be used alone to carry the attribute information of the next hop.

[0399] In a specific implementation, in the above-mentioned embodiment of using BGP UPDATE Message to carry the CRP routing table entry information, the first BGP UPDATE Message also includes a next hop synchronization Next HopSynchronization attribute Attribute field, which is used to carry the attribute information of the next hop. The specific carrying method, that is, which message format or field format is used (such as which fields or extended fields are used), can refer to the description of the corresponding part in the above-mentioned method embodiment, which will not be repeated here.

[0400] In another specific implementation, in the above-mentioned embodiment of using PCEP Message to carry the CRP routing table entry information, the first PCEP Message also includes a PCEP next hop attribute object Next Hop Attributeobject field for carrying the attribute information of the next hop. The specific carrying method, that is, which message format and field format (such as which fields or extended fields are used) can be referred to the description of the corresponding part in the above-mentioned method embodiment, which will not be repeated here.

[0401] By carrying the attribute information of the next hop in the CRP routing table entry information, the network device can obtain the attribute information of the next hop in the CRP routing table, and send the attribute information of the next hop to the FIB to guide message forwarding.

[0402] Optionally, the processing module 401 is also used to generate a second message. The second message carries the table entry information of the second next hop of the network device, and the table entry information of the second next hop records the mapping relationship between the address of the second next hop of the network device and the attribute information of the second next hop. The second message includes second identification information, and the second identification information is used to indicate that the network device saves the table entry information of the second next hop in the next hop table of the network device.

[0403] The sending module 402 is further configured to send the second message to the network device, so that the network device saves the entry information of the second next hop in the next hop table of the network device according to the second identification information.

[0404] In a specific implementation, the second message is a second BGP UPDATE Message, which is used to carry the table entry information of the second next hop. For the specific message format or field format (such as which fields or extended fields are used), refer to the description of the corresponding part in the above method embodiment, which will not be repeated here. In another specific implementation, the second message is a second PCEP Message. For the specific message format or field format (such as which fields or extended fields are used) used to carry the table entry information of the second next hop, refer to the description of the corresponding part in the above method embodiment, which will not be repeated here.

[0405] Therefore, the controller can send the next hop information to the network device separately, so that the controller can manage the next hop information of the network device separately. Separate management includes creating or updating the next hop information separately without binding the routing prefix. The above scheme makes the controller more flexible in managing the next hop of the network device; and effectively saves the system resources occupied by carrying the routing prefix in the information interaction between the controller and the network device; the information that the network device needs to parse is reduced, which also improves the business processing efficiency of the network device.

[0406] Furthermore, when the controller independently sends the next hop information to the network device, it carries the attribute information of the next hop customized by the controller, so that the network device can obtain the attribute information of the next hop in the next hop table and send the attribute information of the next hop to the FIB table for guiding packet forwarding.

[0407] Optionally, the processing module 401 is also used to generate a third message, which carries the address of the third next hop of the network device; the third message includes third identification information, and the third identification information is used to instruct the network device to delete the table entry of the third next hop corresponding to the address of the third next hop in the locally stored next hop table.

[0408] The sending module 402 is further configured to send the third message to the network device so that the network device deletes the entry of the third next hop according to the instruction of the third identification information.

[0409] In a specific implementation, the third message is a third BGP UPDATE Message, which is used to delete the entry of the third next hop. The specific message format or field format (such as which fields or extended fields are used) can be referred to the description of the corresponding part in the above method embodiment, which will not be repeated here.

[0410] In another specific implementation, the third message is a third PCEP Message, which is used to delete the entry of the third next hop. For the specific message format or field format (such as which fields or extended fields are used), please refer to the description of the corresponding part in the above method embodiment, which will not be repeated here.

[0411] Therefore, when there are multiple routing table entries corresponding to the same next hop at the same time, by deleting the next hops corresponding to the multiple routing table entries, the multiple routing table entries using the next hop can be deleted. Therefore, only one message needs to be sent between the controller and the network device to achieve the purpose of fast and batch deletion of routing table entries. This greatly reduces the number of interactive messages between the controller and the network device, saves system resources, and improves business processing efficiency.

[0412] In a specific implementation, the controller 400 further includes a receiving module 403. The receiving module 403 is configured to receive a fourth message sent by the network device; the fourth message carries routing status report information, and the routing status report information records a mapping relationship between the routing prefix and the status information of the CRP routing.

[0413] The processing module 401 is further configured to update the statistical information of the routing prefix according to the received routing status report information, as a basis for recalculating the CRP route.

[0414] The status information of the CRP route includes but is not limited to: the status of the route, such as whether the route is legal, whether it is preferred, whether it is sent to the FIB, etc.; the survival time of the route; the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the bandwidth occupancy ratio of the next hop; the packet loss rate of the next hop; the packet sending delay of the next hop; and the survival time of the next hop.

[0415] Therefore, the controller can regularly and in real time obtain the routing status information reported by the network equipment, and can understand the routing status of the network equipment in real time as a basis for adjusting the routing, thereby improving the reliability and real-time performance of traffic control.

[0416] Optionally, the receiving module 403 is further used to receive a fifth message sent by the network device; the fifth message carries next hop status report information, and the next hop status report information records the mapping relationship between the address of the fourth next hop and the status information of the fourth next hop.

[0417] The processing module 401 is further configured to update the statistical information of the fourth next hop according to the received next hop status report information, as a basis for recalculating the next hop of the network device.

[0418] The next hop status report information includes but is not limited to: the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the next hop bandwidth occupancy ratio; the next hop packet loss rate; the next hop packet sending delay; and the next hop survival time.

[0419] Therefore, the controller can regularly and in real time obtain the next-hop status information reported by the forwarding device, and can understand the status of the forwarding device in real time as a basis for calculation and adjustment of the next hop, thereby improving the reliability and real-time performance of traffic control.

[0420] The controller 400 according to the embodiment of the present application may correspond to the controller in the method 300 for information synchronization according to the embodiment of the present application, and each module in the controller 400 and the above-mentioned other operations and / or functions are respectively for implementing Figure 3 For the sake of brevity, the corresponding process of method 300 is not repeated here.

[0421] Fig.14 is a schematic diagram of a network device 500 according to an embodiment of the present application. The network device 500 can be used to perform Figure 3 As shown in the method. Fig.14 As shown, the network device 500 includes: a receiving module 501 and a processing module 502 .

[0422] The receiving module 501 is used to receive a first message sent by the controller; the first message carries the CRP routing table entry information determined by the controller, which is used to publish the CRP route; the CRP routing table entry information records the mapping relationship between the routing prefix and the address of the first next hop, and the first message includes first identification information.

[0423] The processing module 502 is used to store the CRP routing table entry information in a local CRP routing table according to the instruction of the first identification information, and guide message forwarding according to the CRP routing table.

[0424] By running the CRP protocol between the controller and the network device, a separate CRP routing table is created on the network device to store the CRP routing table entry information sent by the controller. Since the CRP routes published by the controller and the routes published by the routing protocol between the network devices are stored in different routing tables, the routing policies related to the CRP routes will not affect the related applications of the routing policies reflected in the routes in the routing protocol between the network devices.

[0425] Optionally, the CRP routing table entry information further includes: routing synchronization attribute information, where the routing synchronization attribute information is used by the controller to carry routing attribute information formulated by the controller when the controller sends a routing prefix.

[0426] The routing synchronization attributes include, but are not limited to: the routing priority, the topology, and attribute information of the next hop.

[0427] The attribute information of the first next hop includes one or more types of the following attribute information of the next hop: bandwidth, load balancing ratio, and type of the next hop.

[0428] By carrying the route priority in the CRP route table information, the CRP route priority can be flexibly set. For example, the CRP route can be set as the preferred route, so as to achieve the purpose of controlling the traffic using the route published by the controller. For various subsequent complex policy controls on routes, it can be completed by upgrading the controller, without the need for all devices to implement complex policies like existing routing policies, such as BGP routing policies. Therefore, traffic regulation is simpler and more flexible. In addition, in some application scenarios, customers believe that internally deployed IGP routes are trusted and should be preferred, while external routes are untrusted and should not be preferred. In this way, the priority of the CRP route can also be set to be lower than the priority of the ISIS route and the OSPF route. It can be seen that by setting the priority of the CRP route, the different needs of customers can be met.

[0429] Optionally, the processing module 502 is also used to save the address of the first next hop and the attribute information of the first next hop in the table entry of the first next hop in the next hop table of the network device, and the table entry of the first next hop records the mapping relationship between the address of the first next hop and the attribute information of the first next hop.

[0430] By storing the address of the next hop and the attribute information of the next hop mapped to it in the next hop table of the network device, the network device can achieve separate management of the next hop. For example, by deleting the table entry information of a next hop in the next hop table alone, all routing table entries associated with the next hop can be deleted, thereby achieving the purpose of batch deletion of routing table entries. This can effectively reduce the number of interactive messages between the controller and the network device, save system resources, and improve business processing efficiency.

[0431] Further optionally, the processing module 502 is further configured to obtain attribute information of the first next hop, and send the attribute information of the first next hop to a forwarding information table for guiding message forwarding.

[0432] Optionally, the receiving module 501 is also used to receive a second message sent by the controller; the second message carries the table entry information of the second next hop of the network device; the table entry information of the second next hop records the mapping relationship between the address of the second next hop of the network device and the attribute information of the second next hop, and the second message includes second identification information.

[0433] The processing module 502 is further configured to store the entry information of the second next hop in the next hop table of the network device according to an instruction of the second identification information.

[0434] Therefore, the network device can create or update the next hop information independently by receiving the next hop information sent by the controller without binding the routing prefix. The above scheme makes the controller more flexible in managing the next hop of the network device; and effectively saves the system resources occupied by carrying the routing prefix in the information interaction between the controller and the network device; the network device needs to parse less information, which also improves the business processing efficiency of the network device.

[0435] Optionally, the processing module 502 is further configured to obtain attribute information of the second next hop, and send the attribute information of the second next hop to a forwarding information table to guide packet forwarding.

[0436] Optionally, the receiving module 501 is further used to receive a third message sent by the controller; the third message carries the address of the third next hop of the network device, and the third message includes third identification information.

[0437] The processing module 502 is further configured to delete, according to an instruction of the third identification information, an entry of the third next hop corresponding to the address of the third next hop in the next hop table stored in the network device.

[0438] Specifically, the processing module 502 searches the next hop table according to the instruction of the third identification information and takes the address of the third next hop as a keyword, hits the entry of the third next hop, and deletes the entry of the third next hop.

[0439] The processing module is further configured to delete the routing table entry associated with the address of the third next hop.

[0440] Therefore, when there are multiple routing table entries corresponding to the same next hop at the same time, by deleting the next hops corresponding to the multiple routing table entries, the multiple routing table entries using the next hop can be deleted. Therefore, only one message needs to be sent between the controller and the network device to achieve the purpose of fast and batch deletion of routing table entries. This greatly reduces the number of interactive messages between the controller and the forwarding device, saves system resources, and improves business processing efficiency.

[0441] Optionally, the processing module 502 is further configured to generate a fourth message, wherein the fourth message carries routing status report information, and the routing status report information records a mapping relationship between the routing prefix and the status information of the CRP routing.

[0442] The network device 500 further includes a sending module 503, and the sending module 503 is used to send the fourth message to the controller, so that the controller updates the statistical information of the routing prefix according to the received routing status report information as a basis for recalculating the CRP route.

[0443] The status information of the CRP route includes but is not limited to: the status of the route, such as whether the route is legal, whether it is preferred, whether it is sent to the FIB, etc.; the survival time of the route; the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the bandwidth occupancy ratio of the next hop; the packet loss rate of the next hop; the packet sending delay of the next hop; and the survival time of the next hop.

[0444] Therefore, the controller can regularly and in real time obtain the routing status information reported by the network equipment, and can understand the routing status of the network equipment in real time as a basis for adjusting the routing, thereby improving the reliability and real-time performance of traffic control.

[0445] In a specific implementation, the fourth message is a fourth BGP UPDATE Message, which is used to carry the routing status report information. For the specific message format or field format (such as which fields or extended fields are used), please refer to the description of the corresponding part in the above method embodiment, which will not be repeated here. In another specific implementation, the fourth message is a fourth PCEP Message, which is used to carry the routing status report information. For the specific message format or field format (such as which fields or extended fields are used), please refer to the description of the corresponding part in the above method embodiment, which will not be repeated here. Optionally, the processing module 502 is also used to generate a fifth message; the fifth message carries next hop status report information, and the next hop status report information records the mapping relationship between the address of the fourth next hop and the status information of the fourth next hop.

[0446] The sending module 503 is further configured to send the fifth message to the controller, so that the controller updates the statistical information of the next hop according to the received next hop status report information as a basis for recalculating the next hop of the network device.

[0447] The next hop status report information includes but is not limited to: the status of the next hop, such as whether the next hop is legal, whether it is used, etc.; the next hop bandwidth occupancy ratio; the next hop packet loss rate; the next hop packet sending delay; and the next hop survival time.

[0448] Therefore, the controller can regularly and in real time obtain the next-hop status information reported by the forwarding device, and can understand the status of the forwarding device in real time as a basis for calculation and adjustment of the next hop, thereby improving the reliability and real-time performance of traffic control.

[0449] In a specific implementation, the fifth message is a fifth BGP UPDATE Message, which is used to carry the next hop state information. The specific message format or field format (such as which fields or extended fields are used) can be referred to the description of the corresponding part in the above method embodiment, which will not be repeated here.

[0450] In another specific implementation, the fifth message is the fifth PCEP Message, which is used to carry the next hop status information. For the specific message format or field format (such as which fields or extended fields are used), please refer to the description of the corresponding part in the above method embodiment, which will not be repeated here. The network device 500 according to the embodiment of the present application may correspond to the network device in the method for information synchronization according to the embodiment of the present application, and the modules in the network device and the above-mentioned other operations and / or functions are respectively implemented Figure 3 For the sake of brevity, the corresponding process of method 300 is not repeated here.

[0451] The controller 400 and the network device 500 provided in the above embodiments of the present application are only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0452] Fig.15 is another schematic diagram of a controller 600 according to an embodiment of the present application. The controller 600 may be Figure 2 The controller 110 in the embodiment can be used to perform Figure 3 Method 300 in. Fig.15 As shown, the controller 600 includes: an input interface 601 , an output interface 602 , a processor 603 and a memory 604 . The input interface 601 , the output interface 602 , the processor 603 and the memory 604 may be connected via a bus system 605 .

[0453] The memory 604 is used to store programs, instructions or codes. The processor 604 is used to execute the programs, instructions or codes in the memory 604 to control the input interface 601 to receive signals, control the output interface 602 to send signals, and complete the operations in S301-S303, S306-S308, S311, S312, S318, and S321.

[0454] Fig.16 is another schematic diagram of a network device 700 according to an embodiment of the present application. The network device 700 can be used to perform Figure 3 Method 300 in. Fig.16 As shown, the network device 700 includes: an input interface 701, an output interface 702, a processor 703 and a memory 704. The input interface 701, the output interface 702, the processor 703 and the memory 704 may be connected via a bus system 705.

[0455] The memory 704 is used to store programs, instructions or codes. The processor 704 is used to execute the programs, instructions or codes in the memory 704 to control the input interface 701 to receive signals, control the output interface 702 to send signals, and complete the operations in S304, S305, S309, S310, S313-S316, S319, and S320.

[0456] It should be understood that in the embodiment of the present application, the processor 603 and the processor 703 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0457] The memory 604 and the memory 704 may include a read-only memory and a random access memory, and provide instructions and data to the processor 603 and the processor 703 respectively. The memory 604 or a part of the memory 704 may also include a non-volatile random access memory. For example, the memory 604 or the memory 704 may also store information of the device type.

[0458] The bus system 605 and the bus system 705 may include, in addition to the data bus, a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, various buses are labeled as bus systems in the figure.

[0459] In the implementation process, each step of method 300 can be completed by the hardware integrated logic circuit in processor 603 and processor 703 or the instruction in software form. The steps of the positioning method disclosed in the embodiment of the present application can be directly embodied as the execution of the hardware processor, or the combination of the hardware and software modules in the processor. The software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register, etc. The storage medium is respectively located in memory 604 and memory 704, and the processor 603 reads the information in memory 604, and the processor 703 reads the information in memory 704, and the steps of the above method 300 are completed in combination with its hardware. To avoid repetition, it is not described in detail here.

[0460] It should be noted that Fig.13 and Fig.15 The controller provided, Fig.14 and Fig.16 The network equipment provided is used for Figure 2 In the SDN 100 shown in FIG. 1 , a method for implementing information synchronization is implemented. In a specific implementation, Fig.13 The processing module 401 in can be used Fig.15 The sending module 402 may be implemented by the processor 603. Fig.15 The output interface 602 is implemented, and the receiving module 403 can be Fig.15 The input interface 601 is implemented. Similarly, Fig.14 The processing module 502 in Fig.16 The sending module 503 may be implemented by the processor 703 of Fig.16 The output interface 702 is implemented, and the receiving module 501 can be Fig.16 The input interface 701 is implemented.

[0461] The present application also provides a communication system, including a controller and a network device, wherein the controller may be Fig.13 , Fig.15 The controller provided by the corresponding embodiment. The network device may be Fig.14 , Fig.16 The network device provided by the corresponding embodiment. The communication system is used to perform Figure 3-Figure 12 The method 300 of the corresponding embodiment.

[0462] It should be understood that in the various embodiments of the present application, the size of the serial number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0463] Those of ordinary skill in the art will appreciate that the modules and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0464] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0465] Those skilled in the art should be aware that in one or more of the above examples, the functions described in this application can be implemented with hardware, software or any combination thereof. If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention is essentially or part of the prior art that contributes to the part or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

[0466] Each part of this specification is described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment part.

[0467] Finally, it should be noted that the above is only a preferred embodiment of the technical solution of the present application and is not intended to limit the scope of protection of the present application. Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. If these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, any modifications, equivalent substitutions, improvements, etc. made shall be included in the scope of protection of the present application.

Claims

1. A method for information synchronization, characterized in that: The controller determines the control routing protocol CRP route; The controller generates a first message, where the first message is used to publish the CRP route, where the CRP route includes a mapping relationship between a route prefix and an address of a first next hop of a network device; The controller sends the first message to the network device so that the network device saves the CRP route into a CRP routing table, where the CRP routing table is a routing table used by the network device to save routes published by the controller.

2. The method according to claim 1, characterized in that: The CRP route also includes a route priority, and the route priority is used to identify the priority of the CRP route.

3. The method according to claim 1, characterized in that: The first message also includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following attribute information types of the next hop: bandwidth, load balancing ratio, and type of the next hop.

4. The method according to claim 2, characterized in that: The first message also includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following attribute information types of the next hop: bandwidth, load balancing ratio, and type of the next hop.

5. The method according to claim 2, characterized in that: The first message includes a priority field, and the priority field is used to carry the routing priority.

6. The method according to any one of claims 1 to 5, characterized in that: The first message includes a next hop information field, where the next hop information field is used to carry the address of the first next hop.

7. The method according to claim 6, characterized in that The first message includes a next hop attribute field, which is used to carry attribute information of the first next hop.

8. The method according to any one of claims 1 to 5, characterized in that: The first message is a first border gateway protocol update message BGP UPDATE Message or the first message is a first path computation unit communication protocol message PCEP Message.

9. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The controller sends a second message to the network device, where the second message carries a mapping relationship between an address of a second next hop of the network device and attribute information of the second next hop.

10. The method according to claim 9, characterized in that: The second message is a second BGP UPDATE Message.

11. The method according to claim 10, characterized in that The second BGP UPDATE Message includes a multi-protocol reachable network layer reachability information MP_REACH_NLRI attribute field and a next hop attribute Next Hop Attribute field; the MP_REACH_NLRI attribute field includes the address of the second next hop; and the Next Hop Attribute field includes attribute information of the second next hop.

12. The method according to claim 9, characterized in that The second message is a second PCEP Message.

13. The method according to claim 12, characterized in that The second PCEP Message includes a Next Hop object field and a Next Hop Attribute object field; The NextHop object field includes the address of the second next hop, and the Next Hop Attribute object field includes attribute information of the second next hop.

14. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The controller sends a third message to the network device, the third message carrying the address of the third next hop of the network device, the third message including third identification information, and the third identification information is used to instruct the network device to delete the table entry of the third next hop corresponding to the third next hop address in the locally stored next hop table.

15. The method according to claim 14, characterized in that: The third message is a third BGP UPDATE Message or the third message is a third PCEP Message.

16. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The controller receives routing status report information sent by the network device, where the routing status report information records a mapping relationship between the routing prefix and the status information of the CRP routing.

17. The method according to claim 16, characterized in that The CRP route status information includes one or more of the following information: route status, route lifetime or next hop status.

18. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The controller receives next hop status report information sent by the network device, where the next hop status report information records a mapping relationship between an address of a next hop of the network device and status information of the next hop.

19. A method for information synchronization, characterized in that: The network device receives a first message sent by the controller, where the first message is used to publish a control routing protocol (CRP) route determined by the controller, where the CRP route includes a mapping relationship between a route prefix and an address of a first next hop of the network device; The network device stores the CRP route in a CRP routing table, where the CRP routing table includes a first routing table entry for recording the CRP route. The CRP routing table is a routing table used by the network device to store routes published by the controller.

20. The method according to claim 19, characterized in that: The CRP route also includes a route priority, and the route priority is used to identify the priority of the CRP route.

21. The method according to claim 19, characterized in that: The first message includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following attribute information types of the next hop: bandwidth, load balancing ratio, and type of the next hop.

22. The method according to claim 20, characterized in that: The first message includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following attribute information types of the next hop: bandwidth, load balancing ratio, and type of the next hop.

23. The method according to claim 21, characterized in that The method further includes: the network device sending the attribute information of the first next hop to a forwarding information table for guiding message forwarding.

24. The method according to any one of claims 19 to 23, characterized in that: The network device includes a next hop table, and the method further includes: The network device stores the address of the first next hop in the next hop table.

25. The method according to claim 20, characterized in that The first message includes a priority field, and the priority field is used to carry the routing priority.

26. The method according to any one of claims 19 to 23, characterized in that: The first message includes a next hop information field, where the next hop information field is used to carry the address of the first next hop.

27. The method according to claim 26, characterized in that The next hop information field includes a next hop attribute field, which is used to carry attribute information of the first next hop.

28. The method according to any one of claims 19 to 23, characterized in that: The first message is a first Border Gateway Protocol update message BGP UPDATE Message or the first message is a first Path Computation Element Communication Protocol message PCEP Message.

29. The method according to any one of claims 19 to 23, characterized in that The method further comprises: The network device receives a second message sent by the controller, where the second message carries a mapping relationship between an address of a second next hop and attribute information of the second next hop.

30. The method according to claim 29, characterized in that The method further comprises: The network device stores the address of the second next hop and the attribute information of the second next hop in a next hop table.

31. The method according to claim 30, characterized in that The method further comprises: The network device sends the attribute information of the second next hop to the forwarding information table for guiding message forwarding.

32. The method according to any one of claims 19 to 23, characterized in that: The method further comprises: The network device receives a third message sent by the controller, the third message carrying the address of the third next hop of the network device, the third message including third identification information, and the third identification information is used to instruct the network device to delete the entry of the third next hop corresponding to the third next hop address in the next hop table stored locally; The network device deletes the table entry related to the third next hop.

33. The method according to any one of claims 19 to 23, characterized in that: The method further comprises: The network device sends routing status report information to the controller, where the routing status report information records a mapping relationship between the routing prefix and the status information of the CRP routing.

34. The method according to claim 33, characterized in that The CRP route status information includes one or more of the following information: route status, route lifetime or next hop status.

35. The method according to any one of claims 19 to 23, characterized in that: The method further comprises: The network device sends next hop status report information to the controller, where the next hop status report information records a mapping relationship between an address of a next hop of the network device and status information of the next hop.

36. A method for managing information, characterized in that: The controller generates a first message, wherein the first message carries table entry information and identification information of a first next hop of the network device, wherein the table entry information of the first next hop includes a mapping relationship between an address of the first next hop and attribute information of the first next hop, and the identification information is used to instruct the network device to save the table entry information of the first next hop in a locally saved next hop table; The controller sends the first message to the network device so that the network device saves the entry information of the first next hop.

37. The method according to claim 36, characterized in that The attribute information of the first next hop includes one or more of the following: bandwidth, load balancing ratio or type of next hop.

38. The method according to claim 36, characterized in that The first message includes a next hop information field, where the next hop information field is used to carry attribute information of the first next hop.

39. The method according to claim 36, characterized in that The first message includes a next hop information field, where the first next hop information field is used to carry the address of the first next hop.

40. The method according to any one of claims 36 to 39, characterized in that: The first message is a first Border Gateway Protocol update message BGP UPDATE Message or the first message is a first Path Computation Element Communication Protocol message PCEP Message.

41. A method for managing information, characterized in that: The network device receives a first message sent by the controller, where the first message carries table entry information and identification information of a first next hop of the network device, where the table entry information of the first next hop includes a mapping relationship between an address of the first next hop and attribute information of the first next hop, and the identification information is used to instruct the network device to save the table entry information of the first next hop in a locally saved next hop table; The network device stores the entry information of the first next hop in the next hop table.

42. The method according to claim 41, characterized in that The attribute information of the first next hop includes one or more of the following: bandwidth, load balancing ratio or type of next hop.

43. The method according to claim 41, characterized in that The first message includes a next hop information field, where the next hop information field is used to carry attribute information of the first next hop.

44. The method according to claim 42, characterized in that The first message includes a next hop information field, where the next hop information field is used to carry attribute information of the first next hop.

45. The method according to claim 43 or 44, characterized in that The first next hop information field includes a first next hop attribute field, and the first next hop attribute field is used to carry attribute information of the first next hop.

46. ​​The method according to any one of claims 41 to 44, characterized in that The first message includes a next hop information field, where the first next hop information field is used to carry the address of the first next hop.

47. The method according to any one of claims 41 to 44, characterized in that The first message is a first Border Gateway Protocol update message BGP UPDATE Message or the first message is a first Path Computation Element Communication Protocol message PCEP Message.

48. A controller, characterized in that: include: A memory storing instructions; A processor is used to execute the instruction so that the controller executes the method described in any one of claims 1-18 or claims 36-40.

49. A controller, characterized in that: include: Processing modules for: Determine the control routing protocol CRP route; Generate a first message, where the first message is used to publish the CRP route, where the CRP route includes a mapping relationship between a route prefix and an address of a first next hop of a network device; Sending module, used for: The first message is sent to the network device so that the network device saves the CRP route into a CRP routing table, where the CRP routing table is a routing table used by the network device to save routes published by a controller.

50. The controller according to claim 49, characterized in that The CRP route also includes a route priority, and the route priority is used to identify the priority of the CRP route.

51. The controller according to claim 49, characterized in that: The first message also includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following attribute information types of the next hop: bandwidth, load balancing ratio, and type of the next hop.

52. The controller according to claim 50, characterized in that: The first message also includes attribute information of the first next hop, and the attribute information of the first next hop includes one or more of the following attribute information types of the next hop: bandwidth, load balancing ratio, and type of the next hop.

53. The controller according to claim 50, characterized in that The first message includes a priority field, and the priority field is used to carry the routing priority.

54. A controller according to any one of claims 49 to 53, characterized in that: The first message includes a next hop information field, where the next hop information field is used to carry the address of the first next hop.

55. The method according to claim 54, characterized in that The first message includes a next hop attribute field, which is used to carry attribute information of the first next hop.

56. A controller according to any one of claims 49 to 53, characterized in that: The first message is a first Border Gateway Protocol update message BGP UPDATE Message or the first message is a first Path Computation Element Communication Protocol message PCEP Message.

57. A controller according to any one of claims 49 to 53, characterized in that: The sending module is also used for: A second message is sent to the network device, where the second message carries a mapping relationship between the address of the second next hop of the network device and the attribute information of the second next hop.

58. The controller according to claim 57, characterized in that: The second message is a second BGP UPDATEMessage.

59. The controller according to claim 58, characterized in that The second BGP UPDATE Message includes a multi-protocol reachable network layer reachability information MP_REACH_NLRI attribute field and a next hop attribute Next Hop Attribute field; the MP_REACH_NLRI attribute field includes the address of the second next hop; and the Next Hop Attribute field includes attribute information of the second next hop.

60. The controller according to claim 57, characterized in that The second message is a second PCEP Message.

61. The controller according to claim 60, characterized in that The second PCEP Message includes a Next Hop object field and a Next Hop Attribute object field; The NextHop object field includes the address of the second next hop, and the Next Hop Attribute object field includes attribute information of the second next hop.

62. A controller according to any one of claims 49 to 53, characterized in that: The sending module is also used for: A third message is sent to the network device, wherein the third message carries the address of the third next hop of the network device, and the third message includes third identification information, wherein the third identification information is used to instruct the network device to delete the table entry of the third next hop corresponding to the third next hop address in the locally stored next hop table.

63. The controller according to claim 62, characterized in that: The third message is a third BGP UPDATE Message or the third message is a third PCEP Message.

64. A controller according to any one of claims 49 to 53, characterized in that: Also includes: The receiving module is used to receive the routing status report information sent by the network device, and the routing status report information records the mapping relationship between the routing prefix and the status information of the CRP route.

65. The controller according to claim 64, characterized in that The CRP route status information includes one or more of the following information: route status, route lifetime or next hop status.

66. A controller according to any one of claims 49 to 53, characterized in that: Also includes: The receiving module is used to receive the next hop status report information sent by the network device, and the next hop status report information records the mapping relationship between the address of the next hop of the network device and the status information of the next hop.

67. A controller, characterized in that: include: a processing module, configured to generate a first message, wherein the first message carries table entry information and identification information of a first next hop of a network device, wherein the table entry information of the first next hop includes a mapping relationship between an address of the first next hop and attribute information of the first next hop, and the identification information is used to instruct the network device to save the table entry information of the first next hop in a locally saved next hop table; and The sending module is used to send the first message to the network device so that the network device can save the table entry information of the first next hop.

68. The controller according to claim 67, characterized in that The attribute information of the first next hop includes one or more of the following: bandwidth, load balancing ratio or type of next hop.

69. The controller according to claim 67, characterized in that The first message includes a next hop information field, where the next hop information field is used to carry attribute information of the first next hop.

70. The controller according to claim 67, characterized in that The first message includes a next hop information field, where the first next hop information field is used to carry the address of the first next hop.

71. A controller according to any one of claims 67 to 70, characterized in that: The first message is a first Border Gateway Protocol update message BGP UPDATE Message or the first message is a first Path Computation Element Communication Protocol message PCEP Message.

72. A network device, characterized in that: include: A memory storing instructions; A processor is used to execute the instructions so that the controller executes the method described in any one of claims 19-35 or claims 41-47.

73. A communication system, characterized in that: The communication system comprises: a controller according to any one of claims 48-71 and a network device according to claim 72.

74. A computer-readable storage medium, characterized in that The method comprises instructions which, when executed on a computer, cause the computer to execute the method according to any one of claims 1 to 47.

Images