CN117014357A

CN117014357A - Method, device and storage medium for transmitting route

Info

Publication number: CN117014357A
Application number: CN202210474664.6A
Authority: CN
Inventors: 赵雅倩; 张如云; 郭冰清; 方晟
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-04-29
Filing date: 2022-04-29
Publication date: 2023-11-07

Abstract

The embodiment of the application discloses a method, a device and a storage medium for sending a route, belonging to the technical field of communication. The method comprises the following steps: the first node acquires a first BGP route, and an effective node of the first BGP route is a second node. In response to the second node not being a BGP neighbor of the first node, the first node establishes a BGP neighbor relationship with the second node. After establishing the BGP neighbor relation with the second node, the first node sends the first BGP route to the second node. The embodiment of the application realizes the flexible establishment of the BGP neighbor relation between the first node and any node, ensures that the first node can issue BGP routes to any node on one hand, and can avoid large-scale reconstruction of networking on the other hand.

Description

Method, device and storage medium for transmitting route

Technical Field

The embodiment of the application relates to the technical field of communication, in particular to a method, a device and a storage medium for transmitting routes.

Background

In segment routing-traffic engineering (SR-TE) technology, a controller may carry a forwarding path of a packet in a Policy (Border Gateway Protocol Segment Routing IPv6 Policy, BGP SRv6 Policy) route based on a border gateway protocol and a sixth generation network protocol, and then issue the BGP SRv6 Policy route to a forwarding node designated by the network so that the forwarding node forwards the packet based on the BGP SRv6 Policy route, and the designated forwarding node is also referred to as an active node of the BGP SRv6 Policy route.

In the related art, some forwarding nodes in the network are configured as Route Reflectors (RRs) in advance, each RR is further configured with a corresponding client (client), the client is implemented by a packet forwarding node in the network, and for convenience of description, the client of each RR is referred to as a forwarding node corresponding to the RR. After generating a certain BGP SRv6Policy route, the controller sends the BGP SRv6Policy route to each RR, and each RR reflects (i.e., sends) the BGP SRv6Policy route to a corresponding forwarding node. After receiving the BGP SRv6Policy route, any forwarding node determines whether itself is an active node of the BGP SRv6Policy route based on the BGP SRv6Policy route. If the BGP SRv6Policy route is an effective node, the BGP SRv6Policy route is accepted, and if the BGP SRv6Policy route is not an effective node, the BGP SRv6Policy route is discarded.

After the BGP SRv6Policy neighbor relation is established between the RR and the corresponding forwarding node, the RR may successfully send the BGP SRv6Policy route to the corresponding forwarding node. In a complex networking scenario, since any forwarding node may be an effective node of a certain BGP SRv6Policy route, in order to ensure that any BGP SRv6Policy route can be successfully issued to a corresponding effective node, during network initialization, a BGP SRv6Policy neighbor relationship between each RR and all corresponding forwarding nodes is established by a manual configuration manner. Because of the large number of forwarding nodes in the network, the technology needs to establish a large number of BGP SRv6Policy neighbor relations, which results in the network becoming complex and further increases the instability risk of the network.

Disclosure of Invention

The embodiment of the application provides a method, a device and a storage medium for sending a route, which can solve the problem that a network becomes complex caused by establishing a large number of BGP SRv6 Policy neighbor relations in the related technology. The technical scheme is as follows:

in a first aspect, a method for sending a route is provided, the method comprising: the first node acquires a first BGP route, and an effective node of the first BGP route is a second node. In response to the second node not being a BGP neighbor of the first node, the first node establishes a BGP neighbor relationship with the second node. After establishing the BGP neighbor relation with the second node, the first node sends the first BGP route to the second node.

In the embodiment of the application, when a first node receives a first BGP route, whether a BGP neighbor relation is established between a second node and the first node of the effective node of the first BGP route is judged first, if the second node is not the BGP neighbor of the first node, the first node establishes the BGP neighbor relation with the second node first, and after the neighbor relation is established, the first node sends the first BGP route. That is, the embodiment of the application provides a scheme for adaptively establishing BGP neighbor relation based on the demand of BGP routing. Based on the scheme, in the scene that the first node is the RR, BGP neighbor relation is not required to be established between the RR and all corresponding forwarding nodes during network initialization, so that the complexity of networking is correspondingly reduced, and the instability risk of networking is further reduced.

Optionally, after the first node sends the first BGP route to the second node, the first node may also revoke the BGP neighbor relation with the second node.

In the embodiment of the application, when the BGP neighbor relation is determined not to be needed between the first node and the second node, the first node withdraws the BGP neighbor relation between the first node and the second node, so that the problems of complex networking structure and the like caused by too many nodes establishing the BGP neighbor relation with the first node can be avoided.

Optionally, the first BGP route is a first BGP SRv6 Policy route, where the first BGP SRv6 Policy route further carries an identifier of a head node and an identifier of a tail node, and the second node is an adhesion node on a link between the head node and the tail node. The first node receives a second BGP SRv6 Policy route, and an effective node of the second BGP SRv6 Policy route is a third node. And responding to the fact that the identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are respectively the same, the third node and the second node are different adhesion nodes, and the first node cancels the BGP neighbor relation with the second node.

In the embodiment of the application, when the identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are the same, and the third node and the second node are different adhesion nodes, it is indicated that the control node currently needs to resend the adhesion BGP SRv6 Policy route for the same link, and the resend is due to the change of the adhesion node on the same link. Thus, the first node needs to revoke BGP neighbor relations established with the previous stuck node (second node).

Optionally, in response to the second BGP SRv6 Policy route and the first BGP SRv6 Policy route carrying the same identifier of the head node and the same identifier of the tail node, respectively, and the third node and the second node are different adhesion nodes, the first node obtains an adhesion node set, where the adhesion node set includes adhesion nodes on each of a plurality of links in the network. If the second node is not a node in the set of stuck nodes, the first node revokes the BGP neighbor relationship with the second node.

In the embodiment of the application, when the adhesion node on the same link is changed, as the second node is possibly the adhesion node on other links, whether the first node still needs to establish BGP neighbor relation with the second node cannot be determined. Based on this, when the third node and the second node are determined to be different adhesion nodes, it is further required to determine whether the second node is an adhesion node in the adhesion node set, if the second node is not an adhesion node in the adhesion node set, it may be determined that the second node is not an adhesion node on other links, and at this time, the first node cancels the BGP neighbor relation with the second node.

Optionally, the BGP neighbor relationships include BGP SRv6 Policy neighbor relationships and BGP-LS neighbor relationships.

In the embodiment of the application, the first node receives the BSID which is returned by the second node and used for identifying the candidate path carried by the first BGP SRv6 Policy route based on the BGP-LS neighbor relation. Successful release of BGP SRv6 Policy routes can be achieved based on BGP SRv6 Policy neighbor relations. Based on the above, the scheme for adaptively establishing the BGP neighbor relation based on the BGP routing requirement provided by the embodiment of the application can be applied to adaptively establishing the BGP SRv6 Policy neighbor relation and the BGP-LS neighbor relation.

Optionally, the first node obtains a state of an automatic neighbor function. If the state of the automatic neighbor establishment function is an on state, the first node establishes a BGP neighbor relation with the second node. Thus, the self-adaptive neighbor establishment between the first node and the second node can be realized.

Optionally, before the first node obtains the state of the auto-neighbor function, the first node marks the state of the auto-neighbor function as an on state in response to an enabling instruction of the auto-neighbor function.

In the embodiment of the application, when the first node determines that the automatic neighbor building function is enabled under the corresponding BGP address family, the automatic neighbor building function can be determined to be in an on state so as to automatically build the corresponding BGP neighbor relation between the first node and the forwarding node, and further, the BGP SRv6 Policy route is issued based on the BGP SRv6 Policy neighbor relation, and the BSID returned by the forwarding node is received based on the BGP-LS neighbor relation.

Optionally, the first node is an RR and the second node is an operator P node.

When the first node is an RR, according to the scheme for adaptively establishing BGP neighbor relations according to BGP routing requirements provided by the embodiment of the present application, during network initialization, the RR may not need to establish BGP neighbor relations with all P nodes corresponding to the network, so that the BGP neighbor number of the RR may be effectively reduced.

In a second aspect, there is provided an apparatus for transmitting a route, the apparatus for transmitting a route having a function of implementing the method behavior of the transmission route in the first aspect. The device for sending the route comprises at least one module, and the at least one module is used for realizing the method for sending the route provided by the first aspect.

In a third aspect, a network node is provided, where the network node includes a processor and a memory, where the memory is configured to store a program for supporting the network node to perform the method for sending a route provided in the first aspect, and store data related to the method for implementing the sending route provided in the first aspect. The processor is configured to execute a program stored in the memory. The operating means of the memory device may further comprise a communication bus for establishing a connection between the processor and the memory.

In a fourth aspect, a computer readable storage medium is provided, in which instructions are stored which, when run on a computer, cause the computer to perform the method of sending a route according to the first aspect.

In a fifth aspect, there is provided a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of sending a route as described in the first aspect above.

The technical effects obtained in the second, third, fourth and fifth aspects are similar to the technical effects obtained in the corresponding technical means in the first aspect, and are not described in detail herein.

Drawings

FIG. 1 is a schematic diagram of a candidate path according to an embodiment of the present application;

fig. 2 is a system architecture diagram of a communication network according to an embodiment of the present application;

fig. 3 is a flowchart of a method for sending a route according to an embodiment of the present application;

fig. 4 is a schematic diagram of a BGP SRv6 Policy routing structure according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a BGP-LS neighbor relation provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of a network topology provided by an embodiment of the present application;

Fig. 7 is a schematic diagram of a Sub-TLV format carrying BSID according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an apparatus for sending a route according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a network node according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the following detailed description of the embodiments of the present application will be given with reference to the accompanying drawings.

It should be understood that reference herein to "a plurality" means two or more. In the description of the present application, "/" means or, unless otherwise indicated, for example, A/B may represent A or B; "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", etc. are used to distinguish the same item or similar items having substantially the same function and effect. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ.

Before explaining the embodiment of the present application, an application scenario provided by the embodiment of the present application is explained.

With the development of fifth-generation mobile communication technology (5th Generation Mobile Communication Technology,5G), cloudiness, internet of things and other technologies, information automation and other services become more and more abundant, and the abundant services require that the operator network has stronger programmable capability. After the sixth generation network protocol (Internet Protocol Version, IPv 6) appears, the SRv technology generated by combining the Segment Routing (SR) technology with IPv6 has a programmable capability, so that an important technical means is provided for building an end-to-end intelligent network.

The segment identifier (Segment Identifier, SID) in SRv technology has programmable capability, so that the operator can indicate some instructions or services through SID, thereby enriching the network function category in SRv6 technology. For example, the SID may be programmed such that the SID is used to indicate a forwarding path or to indicate a Value-added Service (VAS), etc. The value added service may be, for example: firewall, application acceleration, etc. In addition, SRv has very strong extensibility, if a new network function is to be supported, only a new SID needs to be defined, and no mechanism or deployment of the protocol needs to be changed, which greatly shortens the lead time of the network innovation service.

SRv6 Policy technology is a new tunnel drainage technology developed on the basis of SRv6 technology. SRv6 Policy technology can explicitly instruct the message to be forwarded according to a planned path by encapsulating a series of SIDs in a segmented routing header (Segment Routing Header, SRH), thereby realizing end-to-end fine granularity control of the forwarding path and meeting the requirements of high reliability, large bandwidth, low delay and the like of the service. Meanwhile, the SRv Policy technology can also support load sharing and active-standby path protection, so that the reliability is higher. Therefore, SRv Policy technology can implement service end-to-end requirements, and is a main mechanism for implementing SRv network programming.

Specifically, SRv6 Policy technology uses SRv6 Policy model to implement service end-to-end requirements. The SRv Policy model includes Key (Key) values, candidate paths (Candidate paths), segment lists (Segment lists), and other elements.

Wherein the key value is used to globally uniquely identify a SRv Policy model. The key value is in a triplet format, and the triplet includes a head end (head), a Color (Color), and a tail end (Endpoint). Wherein a head end (head) is used to identify a head node that can direct traffic into a specified path based on a SRv Policy model. Color (Color) is used to identify the identity (Identity document, ID) of the SRv Policy model, and may be specifically associated with a range of business attributes. The business attributes may be, for example: low latency, high bandwidth, etc. Tail ends (end) are used to identify tail nodes.

The candidate path is the base unit of the controller sending SRv Policy alternative paths to the head node. In BGP SRv6 Policy technology, the controller may send candidate paths through a protocol such as the path computation element communication protocol (Path Computation Element Communication Protocol, PCEP). Different candidate paths may be sent under different protocols. One SRv Policy model may associate multiple candidate paths, each configured with a priority (reference). When a plurality of candidate paths exist, the controller can select the candidate path with the highest priority as the main path, so as to send the main path to the head node, and then control the flow forwarding through the main path. In SRv Policy technology, the candidate paths may be carried in BGP SRv6 Policy route and will be described in detail later, which is not described herein.

In addition, one candidate path is associated with one or more Segment lists (Segment lists), any one of which indicates a source routing path to the tail node. The design of the multi-Segment List can promote the network elasticity, meet the requirement of real-time change of the service, and realize the dynamic elastic expansion of network resources.

In addition, a Binding SID (BSID) is used to identify a candidate path, and functions such as tunnel connection, traffic guidance, etc. can be provided through the BSID. Specifically, if a message carries a BSID corresponding to a candidate path, the message is directed to the corresponding candidate path, which is not described herein.

Note that the BSID is generated by the active node of the candidate path. That is, when the controller issues a candidate path to an validating node of the candidate path, the validating node generates a BSID of the candidate path, and the BSID is reported to the controller, so that the controller performs other operations based on the BSID. Wherein the validating node is also the forwarding node that directs traffic to the candidate path.

In the SRv Policy technique, candidate paths may be generated by statically specifying a path, a head node path, a controller path, and the like. The static path and head node calculation mode can only realize the optimal path calculation in the interior gateway protocol (Interior Gateway Protocol, IGP) domain, and the controller calculation circuit can support the functions of global flow optimization, resource reservation, priority preemption, end-to-end cross-domain and the like, and can better support TE.

In the scenario of generating candidate paths based on the controller calculation, after obtaining each candidate path in the SRv Policy model, the controller selects one candidate path based on the current service requirement, and issues the selected candidate path to the head node. The controller carries the selected candidate paths in the BGP SRv6 Policy route for issuing.

In addition, since one BGP SRv6 Policy route will only be effective in a designated node, in order to reduce the flooding range of the BGP SRv6 Policy route, it is necessary for the RR to forward only the BGP SRv6 Policy route issued by the control node to the designated node. To achieve this, in network planning, BGP-LS neighbor relations and BGP SRv6 Policy neighbor relations with the RRs are established on nodes that need to receive BGP SRv6 Policy routes. If a node does not establish a BGP SRv6 Policy neighbor relation with an RR, the RR will not be able to successfully issue a BGP SRv6 Policy route to the node, and if the node does not establish a BGP-LS neighbor relation with the RR, the RR will not be able to obtain a BSID returned to the node for identifying a path in the BGP SRv6 Policy route. By the mode, the RR only forwards the BGP SRv6 Policy route issued by the control node to the appointed node.

Therefore, before the controller issues the BGP SRv6 Policy route to the head node, the controller needs to establish a link state (Border Gateway Protocol Link state, BGP-LS) neighbor relation based on the border gateway protocol and the BGP SRv6 Policy neighbor relation with the head node, and then the controller can send the BGP SRv6 Policy route to the head node based on the established BGP SRv6 Policy neighbor relation, and receive the BSID returned by the head node based on the BGP-LS neighbor relation, where the BSID is used to identify a candidate path carried by the BGP SRv6 Policy route received by the head node, and the BSID is returned to the controller by means of BGP-LS routing.

In addition, the maximum allowable stack depth of the current BGP SRv6 Policy route is 10, that is, the maximum allowable hop count of the path indicated by the BGP SRv6 Policy route is 10. When the hop count of the candidate path selected by the controller exceeds 10 hops, the candidate path needs to be issued through two BGP SRv6 Policy routes respectively.

In particular, the controller may select one of the stuck nodes, which is a node other than the head node and the tail node, on the selected candidate path. The controller generates two BGP SRv6 Policy routes based on the adhesion node, including a first BGP SRv6 Policy route sent to the adhesion node and a second BGP SRv6 Policy route sent to the head node.

The first BGP SRv6 Policy route, i.e., the blocking BGP SRv6 Policy route, indicates a path from the blocking node to the tail node. The second BGP SRv6 Policy route indicates a path from the head node to the tail node, but one of the SIDs in the SID list of the second BGP SRv6 Policy route is a BSID identifying the path in the first BGP SRv6 Policy route. When the head node forwards the traffic based on the SID list in the second BGP SRv6 Policy route and the blocking node receives the traffic, the blocking node replaces the BSID in the SRH of the traffic with the SID list in the first BGP SRv6 Policy route so that the subsequent node continues forwarding the traffic based on the path indicated by the SID list of the first BGP SRv6 Policy route. From this, the BSID is used to tie together BGP SRv6 Policy routes with two segments of stack depths less than 10.

Based on the above, in the scenario that the number of hops of the candidate path selected by the controller exceeds 10 hops, the controller needs to issue a blocking BGP SRv6 Policy route to the blocking node in addition to issuing the BGP SRv6 Policy route to the head node. Accordingly, the controller needs to establish BGP-LS and BGP SRv6 Policy neighbor relationships with the adhesion node in addition to establishing BGP-LS and BGP SRv6 Policy neighbor relationships with the head node before issuing BGP SRv6 Policy routes.

Fig. 1 is a schematic diagram of a candidate path according to an embodiment of the present application. As shown in fig. 1, the hop count of the candidate path is 13, where P1 is the head node of the candidate path, P13 is the tail node of the candidate path, and P2-P12 are the intermediate nodes of the candidate path. If the controller needs to issue a BGP SRv6Policy route to a certain node in the candidate paths, the controller needs to establish a BGP-LS neighbor relation and a BGP SRv6Policy neighbor relation with the node, and after the controller establishes the BGP-LS neighbor relation and the BGP SRv6Policy neighbor relation with the corresponding node, the node can receive the BGP SRv6Policy route issued by the controller based on the BGP SRv6Policy neighbor relation and return the BSID for identifying the paths in the BGP SRv6Policy route to the controller based on the BGP-LS neighbor relation.

Illustratively, since the number of hops of the candidate path in fig. 1 exceeds 10 hops, the controller needs to not only issue BGP SRv6Policy routes to the head node P1 in the candidate path, but also sticky-link BGP SRv6Policy routes to the sticky nodes in the candidate path. Before the controller issues the BGP SRv6Policy route and adheres to the BGP SRv6Policy route, the controller needs to establish a BGP-LS neighbor relation and a BGP SRv6Policy neighbor relation with the head node and the adhering node in the candidate path. Illustratively, if the blocking node calculated by the controller is P3, the controller needs to establish BGP-LS neighbor relation and BGP SRv6Policy neighbor relation with both the head node P1 and the blocking node P3.

When the current controller calculates BGP SRv6 Policy route, if the controller determines that the node needs to be adhered, the controller automatically determines the adhered node from the candidate paths, and a user cannot plan and expect which node the controller can select as the adhered node. That is, any node in the candidate path may be considered a stuck node. Thus, for the candidate path shown in fig. 1, in order for the bonded BGP SRv6 Policy route to be successfully delivered to the corresponding bonded node, each node in the candidate path except for the head node and the tail node needs to establish a BGP-LS neighbor relation and a BGP SRv6 Policy neighbor relation with the controller. This will lead to an increase in network complexity.

Further, as network capacity increases, the controller may need to establish BGP-LS neighbor relationships and BGP SRv6 Policy neighbor relationships with a large number of nodes, resulting in a greater number of BGP neighbors for the controller, which may increase the data processing pressure of the controller. Thus, in one possible implementation, to reduce the number of BGP neighbors of the controller, at least one RR may be deployed in the network, BGP-LS and BGP SRv6 Policy neighbors are established by the controller and the at least one RR, respectively, and BGP-LS and BGP SRv6 Policy neighbors are established by each RR and each forwarding node within the domain in which the RR is located. In this scenario, the controller issues BGP SRv6 Policy routes to the RRs, which forward the BGP SRv6 Policy routes to the corresponding forwarding nodes.

For the candidate paths shown in fig. 1, the head node P1 and the tail node P13 play roles of operator edge (PE) in the network, and since the head node and the tail node must receive BGP SRv6 Policy routes issued by the controller, the head node and the tail node both establish BGP-LS neighbor relations and BGP SRv6 Policy neighbor relations with the RR during network planning. And an operator (P) node like P3 is not required to have BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation with the RR. However, when determining the stuck node, the controller automatically confirms the stuck node, that is, each P node has the possibility of being determined by the controller as a stuck node. Therefore, in order to avoid failure of issuing BGP SRv6 Policy routes to the adhesion nodes, each P node needs to establish BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation with the RR during network planning, so that any BGP SRv6 Policy route can be successfully issued to the corresponding effective node.

Moreover, when the number of nodes in the network is large and the path is complex, the candidate path determined by the controller is artificially unpredictable, and the adhered nodes on the candidate path cannot be planned. Therefore, before forwarding BGP SRv6 Policy routes, the RR needs to establish BGP-LS neighbor relations and BGP SRv6 Policy neighbor relations with each node, so as to ensure that the controller can successfully issue BGP SRv6 Policy routes to any node, thereby ensuring successful establishment of end-to-end BGP SRv6 Policy routes.

However, the above scheme is too much improved for networking, each forwarding node (including P node and PE node) in the networking needs to establish BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation with the RR, and the operation of establishing BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation of each forwarding node and RR is complex. Secondly, for clients of the RR (i.e., forwarding nodes corresponding to the RR), after the clients establish BGP neighbor relations with the RR, the RR reflects the received BGP routes to each client (including the P node), and the P node receives and processes a large number of BGP routes that are not useful to itself, so that the data processing pressure of the P node is increased. Meanwhile, for the RR, due to the increase of the number of BGP neighbors, any BGP route received by the RR needs to be reflected to a large number of BGP neighbors, and the data processing pressure of the RR is larger. While an RR acts as a key node of the network, as the data processing pressure of the RR increases, the risk of network instability increases.

Based on the above scenario, the embodiment of the present application provides a method for sending a route, in which, in the embodiment of the present application, the RR does not need to establish BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation with all P nodes in the network.

The system architecture according to the embodiment of the present application is explained below.

Fig. 2 is a system architecture diagram of a communication network according to an embodiment of the present application. As shown in fig. 2, the system includes a control node 201, at least one RR202 (one RR is shown in the example in fig. 2), and n forwarding nodes 203 (P1, P2, …, pn n nodes are shown in the example in fig. 2).

The control node 201 is configured to collect information such as network topology, TE attributes, and SRv attributes, and generate SRv candidate paths in the Policy model based on the information. After obtaining the candidate paths, the control node is further configured to select one candidate path based on the current traffic demand, and send the selected candidate path to RR202. The controller carries the selected candidate paths in the BGP SRv6 Policy route for issuing.

RR202 is configured to receive a BGP SRv6 Policy route issued by control node 201, and issue the BGP SRv6 Policy route to forwarding node 203 with which it establishes a BGP SRv6 Policy neighbor relation. RR202, on the other hand, is configured to reflect the BSID returned by forwarding node 203 based on BGP-LS neighbor relation and report the BSID to the controller, where the BSID is used to identify paths in the BGP SRv6 Policy route.

Forwarding node 203 is configured to receive BGP SRv6 Policy routes issued by RR202 based on BGP SRv6 Policy neighbor relations. Forwarding node 203, on the other hand, is configured to return BSID to the RR based on BGP-LS neighbor relation.

The nodes P1, P2, …, pn may be any routing device with SRv functionality.

It should be noted that fig. 2 is an example of one control node, one RR, and n forwarding nodes, and the number of RR and forwarding nodes included in the system architecture in the embodiment of the present application is not limited. The n forwarding nodes include P nodes and PE nodes.

The control node may be a controller described in the above application scenario. The RR and the forwarding node are forwarding devices such as routers.

The method for transmitting the route provided by the embodiment of the application is explained in detail.

Fig. 3 is a flowchart of a method for sending a route according to an embodiment of the present application, where the method may be applied to the system architecture shown in fig. 2. Referring to fig. 3, the method includes the following steps 301-303.

Step 301: the first node acquires a first BGP route, and an effective node of the first BGP route is a second node.

Wherein the first BGP route carries an identity of the second node.

The first node may be a control node (i.e., a controller) or an RR. When the first node is a control node, the control node generates a first BGP route. When the first node is an RR, the RR receives a first BGP route sent by the control node, that is, the control node generates the first BGP route, and sends the first BGP route to the RR, and the RR acquires the first BGP route. The following description will take RR as an example.

In addition, the second node is an effective node of the first BGP route, so as to enable the second node to stream the traffic onto the path in the first BGP route.

In BGP, different network layer protocols can be distinguished by different address families, based on which BGP is divided under a plurality of address families, such as BGP-LS address family, BGP SRv6 Policy address family, etc. Various extended applications of BGP may be implemented based on these address families, where collection of link state information may be implemented based on BGP-LS address families and release of BGP SRv6 Policy routes may be implemented based on BGP SRv6 Policy address families.

In some embodiments, in the BGP SRv6 Policy scenario, the first BGP route in step 301 may be a first BGP SRv6 Policy route.

Based on the foregoing description about the SRv6 Policy technology, when the hop count of the candidate path selected by the control node does not exceed 10 hops, the control node only needs to send the candidate path to the head node through the first BGP SRv6 Policy route, where the first BGP route is the BGP SRv6 Policy route sent to the head node. I.e. the second node is the head node.

When the hop count of the candidate path selected by the control node exceeds 10 hops, the control node needs to issue the candidate path through two BGP SRv6 Policy routes respectively, and in this scenario, the control node needs to issue not only the BGP SRv6 Policy route to the head node but also the adhesion BGP SRv6 Policy route to the adhesion node. At this time, the first BGP route may be a BGP SRv6 Policy route issued to the head node, or may be a bonded BGP SRv6 Policy route issued to the bonded node. That is, in the scenario where the first BGP route is a BGP SRv6 Policy route that the control node issues to the head node, the second node in step 301 is the head node on the first link. Under the scene that the first BGP route control node is the adhesion BGP SRv6 Policy route issued to the adhesion node, the second node is the adhesion node on the first link. The first link is the link indicated by the candidate path selected by the control node.

It should be noted that, in any scenario, BGP SRv6 Policy routes carry the identifier of the head node and the identifier of the tail node. Therefore, the first link may also be understood as a link between a head node and a tail node, where the head node identifier and the tail node identifier carried in the first BGP SRv6 Policy route are respectively indicated by the head node identifier and the tail node identifier.

Additionally, in some embodiments, the first BGP route includes an extended community attribute, and the identity of the second node is carried in a route identification field of the extended community attribute.

For example, in the case where the first BGP route is a first BGP SRv6 Policy route, fig. 4 is a schematic message format diagram of the first BGP SRv6 Policy route according to an embodiment of the present application. As shown in fig. 4, the first BGP SRv6 Policy route belongs to an Update message that is used to deliver the route. Wherein the Update message comprises a routing Attribute (Path Attribute) further comprising an extended community (ext-community) Attribute, a router-ID (route identification) field in the extended community Attribute being used for carrying an identification of the second node. The relevant explanation of the other fields of the message in fig. 4 may refer to the relevant standards of BGP routing, and will not be described herein.

The lower picture of fig. 4 is a schematic diagram of the message content of a specific first BGP SRv6 Policy route. As shown in fig. 4, the identity (144.1.14.24:0) of the second node is carried in the router-ID (route identification) field of the extended community attribute (ext-community).

For ease of understanding, the implementation of the control node to generate BGP SRv6 Policy routes is explained below.

The implementation process of the control node generating the BGP SRv6 Policy route may be: the control node gathers information such as network topology, TE attributes, SRv attributes, etc. And based on this information, calculates a path meeting the requirements of the service level agreement (service level agreement, SLA). The calculated path can be carried in the BGP SRv6 Policy route, and the BGP SRv6 Policy route is issued to the head node or the adhesion node. The network topology comprises link overhead, packet loss rate and other information, and the TE attribute comprises delay, bandwidth and other information. SRv6 attributes include information such as SID.

In some embodiments, to avoid the BGP neighbor relationship in the network being too complex, no BGP-LS neighbor relationship is established between the forwarding node and the RR at network initialization, and only BGP-LS neighbor relationship is established between the control node and the RR. In this scenario, the implementation manner of collecting the information such as network topology, TE attribute, SRv attribute, etc. by the control node is: the RR obtains information such as network connection relation information and SRv information of each forwarding node in an IGP flooding mode, and further reports the information such as the network connection relation information and SRv information of each forwarding node to the control node through BGP-LS neighbor relation.

In other embodiments, if a BGP-LS neighbor relationship is established between the forwarding node and the RR at network initialization, a BGP-LS neighbor relationship is also established between the control node and the RR. In this scenario, the implementation manner of collecting the information such as network topology, TE attribute, SRv attribute, etc. by the control node is: based on BGP-LS neighbor relation, the forwarding node sends information such as network connection relation information and SRv6 information to RR through BGP-LS route, RR sends the information to control node, and control node obtains information such as network connection relation information and SRv6 information of each node.

The BGP-LS protocol has advantages of reliable transmission based on a transmission control protocol (Transmission Control Protocol, TCP), good expansibility based on RR, flexible control mechanism based on policy, etc., and therefore has become a main protocol for controlling nodes to collect information such as network topology, TE attributes, SRv attributes, etc.

As shown in fig. 5, the control node and the RR establish BGP-LS neighbor relation, and the RR and each forwarding node (including the P node and the PE node in fig. 5) establish BGP-LS neighbor relation, and use these forwarding nodes as their clients (clients), so that the control node can collect information such as network topology, TE attribute, and SRv attribute through the RR based on BGP-LS protocol.

Illustratively, as shown in fig. 6, the control node and the RR establish BGP-LS neighbor relations (RR in fig. 6, not shown), the RR sends the network connection relation information of each forwarding node and the attributes of SRv and the like to the control node based on the BGP-LS neighbor relations, the control node calculates the network topology as shown in the upper right of fig. 6 based on the information, and then determines a path for sending traffic based on the network topology and the TE attributes, and carries the path in BGP SRv6Policy route to obtain BGP SRv6Policy route.

Wherein, as shown in the network topology at the upper right of fig. 6, SID A4:42 indicates that if a message carries the SID, forwarding node 4 forwards the message to forwarding node 2, SID A4:45 indicates that if a message carries the SID, forwarding node 4 forwards the message to forwarding node 5, SID A4:46 indicates that if a message carries the SID, forwarding node 4 forwards the message to forwarding node 6. All three SIDs are obtained by the control node through a flooding mode. In addition, in FIG. 6, the related content like A1:1 can be understood as a locator (locator) of a corresponding forwarding node, and the forwarding node can allocate some SIDs based on its locator (locator).

In addition, because the first BGP route carries the identifier of the second node, when the first node obtains the first BGP route, the first node may determine whether the second node is a BGP neighbor of the first node based on the identifier of the second node.

In some embodiments, an RR creates a neighbor list under the BGP address family that is used to record forwarding nodes that make up BGP neighbor relationships with the RR, and in which the neighbor state of each forwarding node is also recorded. The neighbor state illustratively includes established (active), connected, and the like. When the neighbor state is established, it indicates that the BGP neighbor relationship is successfully established between the RR and the forwarding node, and other states indicate that the BGP neighbor relationship is not established between the RR and the forwarding node. Therefore, after establishing BGP neighbor relation with any forwarding node, each time, the RR records the forwarding node in a neighbor list under the corresponding BGP address family, and updates the neighbor state of the forwarding node.

In other words, if a forwarding node is in a neighbor list under the BGP address family and the neighbor state is established, it indicates that the forwarding node's neighbor relation to the BGP address family is established. Based on this, the first node may find out from the neighbor list under the BGP address family whether the second node is a BGP neighbor of the first node, and confirm whether the BGP neighbor state of the second node is established.

In some embodiments, when the first BGP route is a first BGP SRv6 Policy route, after receiving the first BGP SRv6 Policy route, the RR first searches, in a neighbor list under a BGP SRv6 Policy address family, whether a second node exists in each node with which it establishes a BGP SRv6 Policy neighbor relation.

If the RR does not find the second node in the neighbor list under the BGP SRv6 Policy address family, or the RR finds the second node in the neighbor list under the BGP SRv6 Policy address family, but the neighbor state of the second node is not established, it may be determined that the second node is not a BGP SRv6 Policy neighbor of the RR. In this way, the RR establishes a BGP SRv6 Policy neighbor relation with the second node based on step 603, so that subsequent RRs can successfully forward the first BGP SRv6 Policy route to the second node.

If the RR finds the second node in the neighbor list under the BGP SRv6 Policy address family, and the neighbor state of the second node is established, it may be determined that the second node is already a BGP SRv6 Policy neighbor of the RR. In this way, the RR may directly send the first BGP SRv6 Policy route to the second node in response to the second node being a BGP SRv6 Policy neighbor of the first node (RR) to complete the operation of forwarding the route by the RR.

In addition, if no BGP-LS neighbor relation is established between the forwarding node and the RR at the time of network initialization, when the first BGP route is the first BGP SRv6 Policy route, after receiving the first BGP SRv6 Policy route, the RR needs to check whether the second node is its BGP SRv6 Policy neighbor or not, and if the second node is a BGP-LS neighbor of the RR, the RR needs to search a neighbor list under the BGP-LS address family for whether the second node exists in each node with which the BGP-LS neighbor relation is established, and if the neighbor state of the second node is established, so as to determine whether the second node is a BGP-LS neighbor of the RR.

If the RR does not find the second node in the neighbor list under the BGP-LS neighbor address family, or the RR finds the second node in the neighbor list under the BGP-LS address family, but the neighbor state of the second node is not established, it may be determined that the second node is not a BGP-LS neighbor of the RR. In this way, the RR establishes a BGP-LS neighbor relation with the second node based on step 603, so that subsequent RRs can obtain the BSID from the forwarding node identifying the path in the first BGP SRv6 Policy path based on the BGP-LS neighbor relation.

Accordingly, if the RR finds the second node in the neighbor list under the BGP-LS address family and the neighbor state of the second node is established, it may be determined that the second node is already a BGP-LS neighbor of the RR. In this way, in the case that the second node is also a BGP SRv6 Policy neighbor of the RR, the RR may respond that the second node is a BGP SRv6 Policy neighbor and a BGP-LS neighbor of the first node (RR), and directly send the first BGP SRv6 Policy route to the second node, so as to complete the operation of forwarding the route by the RR.

That is, in the embodiment of the present application, the RR may adaptively establish a BGP SRv6 Policy neighbor, or may adaptively establish a BGP-LS neighbor.

Step 302: in response to the second node not being a BGP neighbor of the first node, the first node establishes a BGP neighbor relationship with the second node.

When an RR determines that a second node is not its BGP neighbor, it first needs to establish a BGP neighbor relationship with the second node.

In the embodiment of the present application, in order to enable the RR to automatically establish a BGP neighbor relation with the forwarding node, an automatic neighbor establishment function of the RR may be enabled, and based on this, in some embodiments, the implementation process of the RR to establish a BGP neighbor relation with the second node may be: and in response to the automatic neighbor building function being in an on state, the first node builds a BGP neighbor relationship with the second node.

When determining that the second node is not its BGP neighbor relationship, the RR first determines the state of the automatic neighbor establishment function because the RR has the automatic neighbor establishment function. When the auto-neighbor function is on (i.e., the auto-neighbor function is enabled), the RR can establish BGP neighbor relation with the second node.

In addition, the implementation process of establishing the BGP neighbor relation between the first node and the second node may be: the RR may send a neighbor establishment request to the second node, where the neighbor establishment request carries information of a BGP neighbor relation to be established, and the BGP neighbor relation may be a BGP SRv6 Policy neighbor relation. When the second node receives the neighbor establishment request, firstly reading information of a BGP neighbor relation to be established (namely, what kind of BGP neighbor relation needs to be established between the RR and the second node) carried in the neighbor establishment request, and searching neighbor establishment configuration information under a BGP address family corresponding to the second node by the second node based on the information of the BGP neighbor relation, wherein the neighbor establishment configuration information indicates that the second node is allowed to automatically establish neighbor with the RR. If the neighbor configuration information exists in the BGP address family corresponding to the second node, the second node can establish the BGP neighbor relation with the RR. At this point, the second node may send a response request to the RR, the response request indicating that the second node agrees to establish the neighbor request. When the RR receives the response request, the neighbor relation between the current RR and the second node is successfully established, a neighbor list of the RR under the BGP address family corresponding to the RR records the second node, and the neighbor state of the second node is marked as established so as to indicate that the second node is the BGP neighbor of the RR.

The neighbor configuration information on the second node is manually configured, and the neighbor configuration information may also be referred to as a command line that is neighbor to the RR.

Because the implementation process of establishing the BGP-LS neighbor relation between the RR and the second node and the implementation process of establishing the BGP SRv6Policy neighbor relation between the RR and the second node are the same, the detailed description will be given below with reference to the implementation process of establishing the BGP SRv6Policy neighbor relation between the RR and the second node by taking BGP SRv6Policy neighbor as an example. It should be noted that, when the RR needs to adaptively build the BGP SRv6Policy neighbor and the BGP-LS neighbor at the same time, the above-mentioned neighbor building configuration information needs to be configured under different address families, that is, enable the automatic neighbor building function under different address families, which is not described in detail herein.

For example, when the RR needs to establish a BGP SRv6Policy neighbor relation with a second node, the RR sends a neighbor establishment request to the second node, where the neighbor establishment request carries information of the BGP SRv6Policy neighbor relation that needs to be established. When the second node receives the neighbor establishment request, firstly, information of a BGP SRv6Policy neighbor relation to be established, which is carried in the neighbor establishment request (namely, the BGP neighbor relation established between RR and the second node is the BGP SRv6Policy neighbor relation), is read (namely, the BGP SRv6Policy neighbor relation established between RR and the second node), and the second node determines whether neighbor establishment between the second node and the first node is enabled or not under the BGP SRv6Policy address family of the second node (namely, neighbor establishment configuration information aiming at the first node is searched). If the BGP SRv6Policy address family of the second node enables the establishment of a neighbor between the second node and the first node (i.e., the configuration information about the establishment of the neighbor for the first node is found), it indicates that the second node may establish a BGP SRv6Policy neighbor relationship with the RR. At this time, the second node may send a response request to the RR, where the response request carries information that the second node agrees to establish the neighbor request, so as to implement adaptive neighbor establishment between the first node and the second node.

Furthermore, in some embodiments, the implementation of the automatic neighbor establishment function of the first node may be enabled as follows: and responding to an enabling instruction of the automatic neighbor building function, and starting the automatic neighbor building function by the first node.

Specifically, a developer may design and develop a new command line in advance through an extended community attribute auto-connect (auto connect through ext-community), and when an operator configures the command line on the RR, the configuration operation triggers the RR to generate an enable instruction of the auto-neighbor function, thereby triggering the RR to start the auto-neighbor function.

The configuration of the command line on the RR by the operator specifically means that the command line is configured under the BGP-LS address family and BGP SRv6 Policy address family of the RR, so as to enable the automatic neighbor establishment function. Accordingly, when the RR determines that the automatic neighbor building function is enabled (the command line is found) under the BGP-LS address family and the BGP SRv6 Policy address family, the automatic neighbor building function can be determined to be in an on state, so that the RR and the forwarding node automatically build the BGP-LS neighbor relation and the BGP SRv6 Policy neighbor relation, and then the BGP SRv6 Policy route is issued based on the BGP SRv6 Policy neighbor relation, and the BSID returned by the forwarding node is received based on the BGP-LS neighbor relation.

Step 303: after establishing the BGP neighbor relation with the second node, the first node sends the first BGP route to the second node.

After the RR is successfully established with the BGP neighbor relation of the second node, the first BGP route can be sent to the second node, so that the second node can successfully receive the BGP route issued by the control node.

In addition, when the first BGP route is a first BGP SRv6 Policy route and the second node is a blocking node, since the first BGP SRv6 Policy route only indicates a path from the blocking node to the tail node, that is, end-to-end traffic between the head node and the tail node has not been successfully established at this time, the second node needs to generate a BSID for identifying a path in the first BGP SRv6 Policy route based on the first BGP SRv6 Policy route, and send the BSID to the control node through the RR, so that the subsequent control node sends another BGP SRv6 Policy route to the head node based on the BSID. For ease of description to follow, another BGP SRv6 Policy route is referred to as a third BGP SRv6 Policy route.

The second node may randomly allocate a BSID in a dynamic range of a locator (locator) of its SID, and bind the BSID with the first BGP SRv6 Policy route.

In some embodiments, the BGP SRv6Policy route provides a new tunnel encapsulation attribute, and a set of subtype length values (Sub-TLVs) are inserted into the tunnel encapsulation attribute, where the Sub-TLVs include the BSID, priority (Preference), and Duan Liebiao (Segment List) information of the BGP SRv6Policy route. Thus, the BSID associated with a specified Candidate Path (Candidate Path) may be carried over the Sub-TLV in the BGP SRv6Policy route.

Fig. 7 is a schematic diagram of a Sub-TLV format carrying BSID according to an embodiment of the present application. As shown in fig. 7, the BSID field is included in the Sub-TLV. The relevant explanation of other fields in fig. 7 may refer to BGP routing standards, and will not be described in detail herein.

Based on this, the second node may send the BSID carried in the updated first BGP SRv6Policy route to the control node, where the updated first BGP SRv6Policy route includes a Sub-TLV, and the Sub-TLV carries the BSID bound to the first BGP SRv6Policy route. The specific implementation is not described in detail here.

After the control node obtains the BSID, a third BGP SRv6Policy route is generated based on the BSID, where a path indicated by the third BGP SRv6Policy route is a path between the head node and the tail node, and the third BGP SRv6Policy route carries an identifier of the head node and an identifier of the tail node in the first link, and the BSID generated by the second node. The control node issues the third BGP SRv6Policy route to the head node on the first link via the RR. After receiving the third BGP SRv6Policy route, the head node forwards the traffic according to the path indicated by the BGP SRv6Policy route, and after the adhesion node receives the traffic, replaces the BSID with the SID list in the first BGP SRv6Policy route, so that the subsequent forwarding node forwards the traffic to the tail node based on the first BGP SRv6Policy route, thereby successfully establishing the BGP SRv6Policy route from the upper end to the end of the first link.

In addition, when the RR issues the third BGP SRv6 Policy route to the head node, it is also required to determine whether the head node is its BGP SRv6 Policy neighbor, and establish a BGP SRv6 Policy neighbor relationship with the head node if the head node is not its BGP SRv6 Policy neighbor. The implementation process of determining whether the head node is its BGP SRv6 Policy neighbor and establishing the BGP SRv6 Policy neighbor with the head node by the RR may refer to the RR to determine whether the adhesion node is its BGP SRv6 Policy neighbor and establish the content related to the BGP SRv6 Policy neighbor between the adhesion node and the adhesion node, which is not described herein.

In addition, when the RR issues a third BGP SRv6 Policy route to the head node, it may also determine whether the head node is its BGP-LS neighbor, and if the head node is not its BGP-LS neighbor, establish a BGP-LS neighbor relationship with the head node. The implementation process of determining whether the head node is its BGP-LS neighbor and establishing a BGP-LS neighbor relationship with the head node by the RR may refer to the RR to determine whether the adhesion node is its BGP SRv6 Policy neighbor and establish the relevant content of the BGP SRv6 Policy neighbor relationship with the adhesion node, which is not described herein.

In the embodiment of the application, under the condition that the BGP route has an ultra-long path and has the adhesion nodes, any adhesion node randomly selected by the control node can be ensured to successfully receive the BGP route through the operations of the steps 301-303, thereby realizing the end-to-end BGP route transfer on the link, and avoiding the need of pre-establishing BGP neighbor relations between RRs and all forwarding nodes on the link, thereby reducing the pressure of sending and receiving invalid BGP routes by the RRs and all P nodes.

The operation of the above steps 301-303 will be further explained using the networking of fig. 2 as an example.

Illustratively, in the networking shown in fig. 2, at the time of network initialization, the control node and the RR pre-establish BGP SRv6 Policy neighbor relation and BGP-LS neighbor relation, and BGP SRv6 Policy neighbor relation and BGP-LS neighbor relation are not established between the RR and each forwarding node (including P node and PE node).

If the complete BGP SRv6 Policy path calculated by the control node is 13 nodes P1 to P13 in a certain scene, and exceeds the maximum stack depth 10 of the BGP SRv6 Policy path, at this time, the control node defaults to select one node from P1 to P13 as a blocking node.

For example, the control node may take P3 as a blocking node, and the control node may issue a fourth BGP SRv6 Policy route (blocking BGP SRv6 Policy route) to the RR, so that the RR sends the fourth BGP SRv6 Policy route to P3.

For example, as shown in fig. 4, the fourth BGP SRv6 Policy route includes an extended community attribute (ext-community) field, and the identifier of the adhesion node P3 is carried in a route identifier (router-ID) field of the extended community attribute, as shown in 144.1.14.24 in a box in fig. 4, that is, the router-ID of P3.

When the RR receives the fourth BGP SRv6 Policy route, whether P3 is a BGP SRv6 Policy neighbor and a BGP-LS neighbor of the RR is judged. If the RR determines that P3 is not the BGP SRv6 Policy neighbor and the BGP-LS neighbor of the RR, the RR establishes a BGP SRv6 Policy neighbor relation and a BGP-LS neighbor relation with P3 in response to the automatic neighbor building function being in an on state, so as to send a fourth BGP SRv6 Policy route to P3 based on the BGP SRv6 Policy neighbor relation.

After the P3 receives the fourth BGP SRv6 Policy route, the P3 generates a BSID for the fourth BGP SRv6 Policy route based on the fourth BGP SRv6 Policy route, then sends the BSID to the RR based on the BGP-LS neighbor relation established with the RR, and then sends the BSID to the control node through the RR.

After receiving the BSID, the control node generates a fifth BGP SRv6 Policy route based on the BSID, and issues the fifth BGP SRv6 Policy route to the head node P1 through the RR. When the RR sends the fifth BGP SRv6 Policy route to the P1, it is also required to determine whether the P1 is a BGP SRv6 Policy neighbor and a BGP-LS neighbor of the RR, and when it is determined that the P1 is not a BGP SRv6 Policy neighbor and a BGP-LS neighbor of the RR, firstly, a BGP SRv6 Policy neighbor relation and a BGP-LS neighbor relation between the RR and the P1 are established, and based on the BGP SRv6 Policy neighbor relation, the fifth BGP SRv6 Policy route is sent to the P1, and based on the BGP-LS neighbor relation, a BSID returned by the P1 is received. After the two BGP SRv6 Policy routes (the fourth BGP SRv6 Policy route and the fifth BGP SRv6 Policy route) are successfully issued, the BGP SRv6 Policy routes of P1-P13 can be established, so as to ensure the smoothness of the end-to-end service.

The arrangement mode of the fourth BGP SRv6 Policy route may be expressed as: policy_P3-P13= { end.x_3, end.x_4, end.x_5, …, end.x_12}. The arrangement of the fifth BGP SRv6 Policy route may be expressed as: policy_P1-P13= { end.x_1, end.x_2, end.b6_3, end_13}. end.b6_3 is BSID. At this time, based on BGP SRv6 Policy neighbor relations between the RR and the head node P1 and between the blocking node P3, the control node issues fourth BGP SRv6 Policy routes (policy_p3 to P13) to the blocking node P3 through the RR, generates fifth BGP SRv6 Policy routes (policy_p1 to P13) based on BSID fed back by the P3, and issues fifth BGP SRv6 Policy routes to the head node P1 through the RR, and when both BGP SRv6 Policy routes are issued successfully, the BGP SRv6 Policy routes of P1 to P13 can be established, so as to ensure end-to-end traffic smoothness.

In addition, if, after the control node selects one adhesion node, the RR establishes a BGP-LS neighbor relation and a BGP SRv6 Policy neighbor relation with the adhesion node, and if the control node selects a different adhesion node each time, the RR establishes a BGP-LS neighbor relation and a BGP SRv6 Policy neighbor relation with the adhesion nodes, and after multiple operations, the RR establishes a BGP-LS neighbor relation and a BGP SRv6 Policy neighbor relation with each node. Thus, the architecture of the networking is still complex and the risk of uncertainty in the network increases. Therefore, the BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation established by the RR and the node need to be timely revoked, so as to avoid the problems of complex networking structure and the like caused by too many nodes establishing the BGP-LS neighbor relation and BGP SRv6 Policy neighbor relation with the RR.

Thus, in some embodiments, when it is determined that no BGP neighbor relationship is needed between a first node (RR) and a second node, the first node cancels the BGP neighbor relationship with the second node. It should be noted that BGP neighbor relations here may include BGP-LS neighbor relations and BGP SRv6 Policy neighbor relations.

In one possible implementation manner, in a case that the first route is a first BGP SRv6 Policy route, the first node receives a second BGP SRv6 Policy route, identifiers of a head node and a tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are the same, and the second BGP SRv6 Policy route indicates that a blocking node on the first link is a third node, where the third node and the second node are different. In response to the third node and the second node being different, a set of sticky nodes is obtained, the set of sticky nodes comprising sticky nodes for each of a plurality of links in the network. If the second node is not a node in the set of stuck nodes, it is determined that no BGP SRv6 Policy neighbor relationship is required between the first node and the second node.

The identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are the same, and the identifiers of the third node and the second node are different, which indicates that the control node needs to resend the BGP SRv6 Policy route for the same link at present, and the resend is due to the change of the blocking node on the same link.

When a change occurs in a stuck node on the same link, it is not yet possible to determine whether the RR still needs to establish BGP neighbor relation with the second node, since the second node may also be a stuck node on other links. Based on this, when it is determined that the third node and the second node are different, it is further determined whether the second node is a stuck node in the stuck node set, and if the second node is not a stuck node in the stuck node set, it may be determined that the second node is not a stuck node on other links. At this point it is indicated that the RR no longer needs BGP neighbor relation with the second node.

In another possible implementation, when the third node and the second node are different adhesion nodes, the RR determines that the adhesion node on the same link has changed, and further directly determines that the BGP neighbor relation between the RR and the second node is no longer needed, so as to cancel the BGP neighbor relation between the first node (RR) and the second node.

In addition, when the BGP SRv6 Policy neighbor relation between the second node and the first node is unstable or there is repetitive oscillation, the networking may misunderstand that the BGP SRv6 Policy neighbor relation between the second node and the first node is not needed, so as to cancel the BGP SRv6 Policy neighbor relation between the second node and the first node. For example, a delay time may be set, and when it is determined that the duration after the second node and the first node do not need the BGP SRv6 Policy neighbor relation exceeds the delay time, the BGP SRv6 Policy neighbor relation between the second node and the first node is revoked.

The delay time may be set in advance, for example, 10 minutes, which is not limited in the embodiment of the present application.

In addition, the embodiment of the application can directly cancel the BGP neighbor relation between the first node and the second node after the first node transmits the first BGP SRv6 Policy route to the second node based on the BGP SRv6 Policy neighbor relation.

The above description is given by taking automatic neighbor establishment of BGP SRv6 Policy address group in BGP address group as an example. Optionally, an auto-neighbor function may also be enabled in other address families under BGP address families, such as an auto-neighbor function under an ipv4-family unicasting address family.

The embodiment of the application realizes the flexible establishment of BGP neighbor relation between RR and any node based on the scheme of automatic neighbor establishment, on one hand, ensures that the control node can issue BGP route to any node, and on the other hand, can avoid large-scale reconstruction of networking. In addition, the RR in the embodiment of the application only establishes the neighbor with the P node needing to establish the BGP neighbor relation, thereby greatly reducing the quantity of invalid BGP routes sent by the RR received by the P node, and further greatly reducing the data processing pressure of the P node. Meanwhile, the data processing pressure of RR is reduced, and the risk of network problems is further reduced. In addition, in the embodiment of the application, according to the extended community attribute of the BGP route, which P node the receiving party of the BGP route is determined, and then the BGP neighbor state of the P node is judged, thereby automatically initiating the establishment of the neighbor under a certain address family of the BGP. The automatic enabling mode can be extended to other BGP address families, so that the networking has expandability.

Fig. 8 is a schematic structural diagram of an apparatus for routing according to an embodiment of the present application. The apparatus may be the first node in the foregoing embodiment. Referring to fig. 8, the apparatus includes: a transceiver module 801 and a processing module 802.

The transceiver module 801 is configured to obtain a first border gateway protocol BGP route, where an effective node of the first BGP route is a second node;

a processing module 802 configured to establish a BGP neighbor relationship with the second node in response to the second node not being a BGP neighbor of the first node;

the transceiver module 801 is further configured to send the first BGP route to the second node after establishing a BGP neighbor relation with the second node.

Optionally, the processing module 802 is further configured to:

the BGP neighbor relationship with the second node is revoked.

Optionally, the first BGP route is a first BGP SRv6 Policy route, where the first BGP SRv6 Policy route further carries an identifier of a head node and an identifier of a tail node, and the second node is an adhesion node on a link between the head node and the tail node;

the processing module 802 is further configured to:

receiving a second BGP SRv6 Policy route, wherein an effective node of the second BGP SRv6 Policy route is a third node;

and responding to the fact that the identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are respectively the same, and the third node and the second node are different adhesion nodes, and the BGP neighbor relation between the third node and the second node is cancelled.

Optionally, the processing module 802 is further configured to:

responding to the fact that the identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are respectively the same, and the third node and the second node are different adhesion nodes, obtaining an adhesion node set, wherein the adhesion node set comprises adhesion nodes on each link in a plurality of links in a network;

if the second node is not a node in the set of stuck nodes, the BGP neighbor relationship with the second node is revoked.

Alternatively, the neighbor relationships include BGP SRv6 Policy neighbor relationships and BGP-LS neighbor relationships.

Optionally, the processing module 802 is further configured to:

acquiring the state of an automatic neighbor building function;

if the state of the automatic neighbor building function is an on state, a BGP neighbor relation with the second node is built.

Optionally, the processing module 802 is further configured to:

and responding to an enabling instruction of the automatic neighbor building function, and marking the state of the automatic neighbor building function as an on state.

Optionally, the first node is an RR and the second node is an operator node.

It should be noted that: in the device for transmitting a route according to the above embodiment, only the division of the above functional modules is used for illustration, and in practical application, the above functional allocation may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to perform all or part of the functions described above. In addition, the device for sending a route provided in the foregoing embodiment and the method embodiment for sending a route belong to the same concept, and specific implementation processes of the device for sending a route are detailed in the method embodiment, which is not described herein again.

Fig. 9 is a schematic structural diagram of a network node according to an embodiment of the present application. The network node is configured to implement the functions of the apparatus for sending routes in the foregoing embodiments. Referring to fig. 9, the network node comprises at least one processor 901, a communication bus 902, a memory 903 and at least one communication interface 904.

Processor 901 may be a general purpose central processing unit (central processing unit, CPU), application Specific Integrated Circuit (ASIC), or one or more integrated circuits for controlling the execution of programs in accordance with aspects of the present application.

Communication bus 902 may include a path to transfer information between the aforementioned components.

The Memory 903 may be, but is not limited to, a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, a random access Memory (random access Memory, RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only Memory (electrically erasable programmable read-only Memory, EEPROM), a compact disc (compact disc read-only Memory) or other optical disk storage, optical disk storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 903 may be separate and coupled to the processor 901 via a communication bus 902. The memory 903 may also be integrated as the processor 901.

The memory 903 is used for storing program codes for executing the scheme of the present application, and the processor 901 controls the execution. The processor 901 is for executing program code stored in the memory 903. One or more software modules may be included in the program code.

The communication interface 904, uses any transceiver-like means for communicating with other devices or communication networks, such as ethernet, radio access network (radio access network, RAN), wireless local area network (wireless local area networks, WLAN), etc.

In a specific implementation, as an embodiment, the network node may comprise a plurality of processors, such as processor 901 and processor 905 shown in fig. 9. Each of these processors may be a single-core (single-CPU) processor or may be a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, data subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital versatile disk (digital versatile disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), etc.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The embodiments of the present application are not limited to the above embodiments, but any modifications, equivalent substitutions, improvements, etc. within the spirit and principle of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A method of transmitting a route, the method comprising:

the method comprises the steps that a first node obtains a first Border Gateway Protocol (BGP) route, and an effective node of the first BGP route is a second node;

responsive to the second node not being a BGP neighbor of the first node, the first node establishes a BGP neighbor relationship with the second node;

after establishing a BGP neighbor relation with the second node, the first node sends the first BGP route to the second node.

2. The method of claim 1, wherein after the first node sends the first BGP route to the second node, the method further comprises:

The first node revokes BGP neighbor relationships with the second node.

3. The method of claim 2, wherein the first BGP route is a first BGP SRv6 Policy route that is a BGP and sixth generation network protocol-based Policy for segment routing, the first BGP SRv6 Policy route further carries an identity of a head node and an identity of a tail node, and the second node is a blocking node on a link between the head node and the tail node;

the first node revokes BGP neighbor relationships with the second node, comprising:

the first node receives a second BGP SRv6 Policy route, and an effective node of the second BGP SRv6 Policy route is a third node;

and responding to the fact that the identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are respectively the same, the third node and the second node are different adhesion nodes, and the first node withdraws the BGP neighbor relation with the second node.

4. The method of claim 3, wherein the responding to the identity of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route being the same, respectively, and the third node being a different attachment node than the second node, the first node tearing down BGP neighbor relation with the second node comprises:

Responding to the fact that the identifiers of the head node and the tail node carried by the second BGP SRv6 Policy route and the first BGP SRv6 Policy route are respectively the same, the third node and the second node are different adhesion nodes, and the first node acquires an adhesion node set which comprises adhesion nodes on each link in a plurality of links in a network;

if the second node is not a node in the set of stuck nodes, the first node revokes a BGP neighbor with the second node.

5. The method of claim 3 or 4, wherein the BGP neighbor relationships comprise BGP SRv6 Policy neighbor relationships and border gateway protocol-based link state BGP-LS neighbor relationships.

6. The method of any of claims 1-5, wherein the first node establishing a BGP neighbor relationship with the second node comprises:

the first node acquires a state of an automatic neighbor building function;

and if the state of the automatic neighbor building function is an on state, the first node builds a BGP neighbor relation with the second node.

7. The method of claim 6, wherein before the first node obtains the status of the auto-neighbor function, the method further comprises:

And responding to the enabling instruction of the automatic neighbor building function, and marking the state of the automatic neighbor building function as an on state by the first node.

8. A method according to any of claims 1-7, characterized in that the first node is a route reflector RR and the second node is an operator P node.

9. An apparatus for transmitting a route, the apparatus comprising:

the receiving and transmitting module is used for acquiring a first Border Gateway Protocol (BGP) route, and an effective node of the first BGP route is a second node;

a processing module configured to establish a BGP neighbor relationship with the second node in response to the second node not being a BGP neighbor of the first node;

the transceiver module is further configured to send the first BGP route to the second node after establishing a BGP neighbor relation with the second node.

10. The apparatus of claim 9, wherein the processing module is further to:

and the BGP neighbor relation between the second node and the second node is revoked.

11. The apparatus of claim 10, wherein the first BGP route is a first BGP SRv6 Policy route that is a BGP and sixth generation network protocol-based Policy for segment routing, the first BGP SRv6 Policy route further carries an identity of a head node and an identity of a tail node, and the second node is a blocking node on a link between the head node and the tail node;

The processing module is further configured to:

and in response to the second BGP SRv6 Policy route and the first BGP SRv6 Policy route carrying the same identifier of the head node and the tail node respectively, wherein the third node and the second node are different adhesion nodes, and the BGP neighbor relation between the third node and the second node is cancelled.

12. The apparatus of claim 11, wherein the processing module is further to:

and if the second node is not a node in the adhesion node set, the BGP neighbor relation between the second node and the second node is cancelled.

13. The apparatus of claim 11 or 12, wherein the BGP neighbor relationships comprise BGP SRv6 Policy neighbor relationships and border gateway protocol-based link state BGP-LS neighbor relationships.

14. The apparatus of any of claims 9-13, wherein the processing module is further to:

acquiring the state of an automatic neighbor building function;

and if the state of the automatic neighbor building function is an on state, building a BGP neighbor relation with the second node.

15. The apparatus of claim 14, wherein the processing module is further to:

and responding to the enabling instruction of the automatic neighbor building function, and marking the state of the automatic neighbor building function as an on state.

16. The apparatus according to any of claims 9-15, wherein the first node is a route reflector RR and the second node is an operator P node.

17. A computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the method of any of claims 1-8.