Method for dynamically negotiating border gateway protocol (BGP) connection parameter, and communication apparatus

Abstract

The embodiments of the present application relate to the technical field of communications. Provided are a method for dynamically negotiating a border gateway protocol (BGP) connection parameter, and a communication apparatus. A BGP connection parameter can be adjusted without interrupting a BGP connection, and the time for service convergence in the case of large-scale routing can be reduced. In the method, after a first communication apparatus and a second communication apparatus establish a BGP connection on the basis of a first BGP connection parameter, BGP connection parameter negotiation between the first communication apparatus and the second communication apparatus can be completed by means of a first message while keeping the BGP connection uninterrupted. A first BGP connection parameter to be updated carried in the first message may comprise at least one of an AS number, a hold time, or a BGP identifier.

Description

Method and communication apparatus for dynamically negotiating border gateway protocol (BGP) connection parameters

[0001] The present application claims priority from the Chinese patent application No. 202410895773.4 filed on July 4, 2024, and entitled "Method and communication apparatus for dynamically negotiating border gateway protocol (BGP) connection parameters", the contents of which are incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of communication technology, and in particular to a method and a communication apparatus for dynamically negotiating border gateway protocol (BGP) connection parameters. BACKGROUND

[0003] After a border gateway protocol (BGP) device and a peer establish a transmission control protocol (TCP) connection, the BGP device and the peer send BGP Open messages to each other to negotiate BGP connection parameters for establishing a BGP connection (which can also be referred to as a BGP peer connection or a BGP session or a BGP peer session). When the state machine of the BGP peer switches to an established state, the BGP device can only process update messages, notification messages, keepalive messages, and the like. If the BGP device needs to enable, disable, or update a capability or a parameter on a BGP connection that has been successfully established, the BGP device needs to interrupt the current BGP connection, reissue a BGP Open message to renegotiate the BGP connection parameters, and thus establish a new BGP connection. However, the process of interrupting the BGP connection and renegotiating the BGP connection parameters by reissuing the BGP Open message can cause a large amount of route convergence. SUMMARY

[0004] Embodiments of the present application provide a method and a communication apparatus for dynamically negotiating border gateway protocol (BGP) connection parameters, which can dynamically adjust the BGP connection parameters without interrupting an established BGP connection, thereby avoiding route convergence caused by interrupting the BGP connection.

[0005] In a first aspect, a method for dynamically negotiating a BGP connection parameter is provided. The execution subject of the method can be a BGP device, a component or apparatus (e.g., a processor, a chip, or a chip system, etc.) applied to the BGP device, or a logic module or software capable of realizing all or part of the function of the BGP device. In this application, the BGP device refers to a device implementing BGP. The BGP device can be a router or a switch, etc. The BGP device can also be referred to as a BGP speaker. The method comprises: a first communication device and a second communication device establishing a first BGP connection based on a first BGP connection parameter; the first communication device sending a first message to the second communication device while maintaining the first BGP connection, the first message including a first BGP connection parameter to be updated, the first BGP connection parameter to be updated including at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and updating the first BGP connection parameter according to the first BGP connection parameter to be updated.

[0006] Thus, in the case of establishing a BGP connection, if the BGP connection parameter needs to be updated, the established BGP connection needs to be disconnected, a BGP Open message needs to be re-sent for BGP connection parameter negotiation, and the BGP connection parameter needs to be used after the BGP connection is re-established. In other words, in the process of BGP connection parameter negotiation, the BGP connection needs to be disconnected and re-established, and a BGP Open message needs to be re-sent for new BGP connection parameter negotiation. In this application, the first communication device and the second communication device can negotiate the first BGP connection parameter to be updated by transmitting the first message while maintaining the first BGP connection, and update the first BGP connection parameter. In this way, the first BGP connection parameter negotiated when the first BGP connection is established does not need to be interrupted, and the route convergence caused by the interruption of the BGP connection in the case of a large number of routes can be avoided.

[0007] In particular, when adjusting the parameter irrelevant to the route, such as the Hold Time, the interruption of the first BGP connection can be avoided, and a large number of route convergences caused by the interruption of the first BGP connection can be avoided.

[0008] In this application, the BGP connection can also be understood as a BGP session. Establishing the BGP connection can also be understood as establishing a peer session or establishing a BGP session, that is, establishing the BGP connection means establishing the peer session or the BGP session. In some scenarios, establishing the BGP connection can also be referred to as establishing a BGP neighbor. The BGP neighbor can be understood as a peer BGP device, and the BGP session is a channel used for the two BGP devices to negotiate and send protocol messages.

[0009] In this application, the BGP connection parameter can also be understood as a BGP session parameter.

[0010] In this application, the first communication device in the case of maintaining the first BGP connection can also be understood as the BGP state machine of the first communication device being in the established state. The second communication device in the case of maintaining the first BGP connection can also be understood as the BGP state machine of the second communication device being in the established state.

[0011] In a possible design, the first message is a border gateway protocol message (BGP message).

[0012] In a possible design, the first message is a newly defined BGP message in addition to currently known types of BGP messages. In a possible design, the newly defined BGP message includes at least one of a flag bit and a version number of the BGP message, and the flag bit indicates that the BGP message is a request message. In this way, in the case of the newly defined BGP message, the first communication device can directly carry the BGP connection parameter to be negotiated by the newly defined BGP message in the case of maintaining the BGP connection, so as to meet the requirement of negotiating the BGP connection parameter in the case of the BGP connection.

[0013] In a possible design, the first message is a first border gateway protocol (BGP) open message. In this design, the first BGP open message can be a newly defined BGP open message or an updated BGP open message in the format of an original BGP open message. In this way, the communication device running the BGP can perform BGP connection parameter negotiation while maintaining the BGP connection, i.e., the state machine of the first communication device and the second communication device is in the established state. In the prior art, when the communication device receives a BGP open message while in the established state, the communication device disconnects the BGP connection and reestablishes the BGP connection. In this application, when the communication device receives the BGP open message while in the established state, the communication device does not disconnect the BGP connection, but performs BGP connection parameter negotiation according to the BGP open message while maintaining the established state.

[0014] In a possible design, the first BGP open message includes indication information, which indicates that the first BGP open message carries the first BGP connection parameter to be updated. Considering that the BGP open message is a message used for negotiating the BGP connection parameter and is transmitted in the process of establishing the first BGP connection, the BGP node can only process update, notification, and keepalive messages without interrupting the first BGP connection, and cannot process the BGP open message. This application can make the second communication device (BGP node) receive the first BGP open message and identify the indication information while maintaining the first BGP connection, and perform connection parameter negotiation according to the first BGP connection parameter to be updated in the first BGP open message, by carrying the indication information in the first BGP open message. The BGP node can identify the indication information, which can be understood as indicating that the BGP node performs BGP connection parameter negotiation through the BGP open message without interrupting the first BGP connection, or can be understood as being used to identify that the first BGP open message is used for negotiating the BGP connection parameter. In this way, the BGP node that identifies the indication information can perform parameter negotiation without interrupting the first BGP connection.

[0015] In one possible design, the optional parameter of the first BGP Open message includes a type-length-value (TLV) field, and the TLV field carries the first BGP connection parameter to be updated. There can be one or more TLV fields in this case. This design can be understood as adding a new TLV field to the original BGP Open message, which indicates that the BGP node performs BGP connection parameter negotiation with the first BGP connection parameter to be updated carried in the currently transmitted first BGP Open message while maintaining the first BGP connection.

[0016] In one possible design, the method further includes: the first communication device establishes a second BGP connection with a third communication device based on a second BGP connection parameter; and the first communication device receives a second BGP Open message sent by the third communication device while maintaining the second BGP connection (corresponding to the established state of the BGP state machine), where the second BGP Open message includes a second BGP connection parameter to be updated, and the second BGP connection parameter to be updated includes at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and the first communication device updates the second BGP connection parameter based on the second BGP connection parameter to be updated. In this design, the BGP connection parameter negotiation between BGP neighbors is performed using the BGP Open message. This case can be that the first communication device and the second communication device are preconfigured with a command line, and the command line is used to control the behavior of the BGP node in the established state when receiving the BGP Open message. The behavior is used to enable the BGP node to perform BGP connection parameter negotiation based on the BGP connection parameter carried in the BGP Open message. In this way, the BGP connection parameter negotiation capability is enabled at both ends of the BGP neighbor, and normal BGP connection parameter negotiation is ensured without interrupting the second BGP connection.

[0017] In one possible design, the first message is a link layer discovery protocol (LLDP) message or a layer 3 discovery and alive (L3DL) message, and the first message includes at least one TLV, and the at least one TLV includes the first BGP connection parameter to be updated. This design can be understood as performing BGP connection parameter negotiation using a newly defined LLDP message or L3DL message or a message obtained by improving the original LLDP message or L3DL message, and the BGP connection parameter negotiation can be completed without interrupting the BGP connection.

[0018] In a possible design, before the first communication device sends the first message, the method further includes: the first communication device sending, to the second communication device, a connection identifier of the first BGP connection. This design takes into account that there can be multiple connections between the first communication device and the second communication device, and in the case of sending the connection identifier of the first BGP connection for which the parameters are to be negotiated to the peer, the BGP node receiving the first message can determine which BGP connection the parameters are to be negotiated for, so as to perform the parameter update according to the received first BGP connection parameters to be updated, while maintaining the BGP connection.

[0019] In this application, the connection identifier of the BGP connection can also be understood as a session identifier of a BGP session in the case that the BGP connection can be understood as a BGP session.

[0020] In a possible design, the first BGP connection parameters further include capability information (capability) indicating a capability supported by the first communication device. That is, the first BGP connection parameters to be updated carried in the first message while maintaining the first BGP connection can further include the capability information, so that the second communication device can also learn the capability information updated by the first communication device in a timely manner while maintaining the first BGP connection. For example, the capability information can include one or more of multiprotocol extensions capability, route refresh capability, or support for 4-octet AS number capability.

[0021] In a possible design, the method further includes: the first communication device receiving a second message fed back by the second communication device, the second message indicating that the second communication device receives the first message. Generally, if the second communication device supports the BGP connection parameter negotiation while maintaining the first BGP connection, the second communication device can complete the connection parameter negotiation and feed back the second message to the first communication device after receiving the first message and correctly parsing the first message. When the first communication device receives the second message, it is considered that the first communication device has received the first message, and the local first BGP connection parameters to be updated can be validated, and the first communication device and the second communication device complete the first BGP connection parameter negotiation. The second message can be an acknowledgement (ACK) message.

[0022] In a second aspect, a method for dynamically negotiating a BGP connection parameter is provided. The execution subject of the method can be a BGP device, a component or apparatus (e.g., a processor, a chip, or a chip system) applied to the BGP device, or a logic module or software capable of realizing all or part of the function of the BGP device. For example, the BGP device can be a router or a switch, and the BGP device can also be referred to as a BGP speaker. The method comprises: establishing, by a second communication device, a first BGP connection with a first communication device based on a first BGP connection parameter; receiving, by the second communication device, a first message sent by the first communication device while maintaining the first BGP connection, the first message comprising a first BGP connection parameter to be updated, and the first BGP connection parameter to be updated comprising at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and updating, by the second communication device, the first BGP connection parameter based on the first BGP connection parameter to be updated.

[0023] The beneficial effects of the second aspect can be referred to the description of the beneficial effects of the first aspect.

[0024] In a possible design, the first message is a border gateway protocol (BGP) message.

[0025] In a possible design, the first message is a newly defined BGP message, and the BGP message further comprises at least one of a flag bit and a version number of the BGP message, the flag bit being used to indicate that the BGP message is a request message.

[0026] In a possible design, the first message is a first BGP open message.

[0027] In a possible design, the first BGP open message comprises indication information, and the indication information indicates that the first BGP open message carries the first BGP connection parameter to be updated.

[0028] In a possible design, an optional parameter of the first BGP open message comprises a type-length-value (TLV) field, and the TLV field carries the first BGP connection parameter to be updated.

[0029] In a possible design, the method further includes: the second communication device establishes a second BGP connection with a third communication device based on second BGP connection parameters; the second communication device sends a second BGP Open message to the third communication device while maintaining the second BGP connection, where the second BGP Open message includes second BGP connection parameters to be updated, and the second BGP connection parameters to be updated include at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and the second communication device updates the second BGP connection parameters according to the second BGP connection parameters to be updated.

[0030] In a possible design, the first message is a link layer discovery protocol (LLDP) message or a layer 3 discovery and alive (L3DL) message; and the first message includes at least one TLV, and the at least one TLV includes the first BGP connection parameters to be updated.

[0031] In a possible design, the first message further includes capability information, and the capability information indicates a capability supported by the first communication device.

[0032] In a possible design, the second communication device sends a second message to the first communication device, and the second message indicates that the second communication device receives the first message.

[0033] In a third aspect, a first communication device is provided, which is configured to perform the method in the first aspect and any possible design of the first aspect. The first communication device can be a BGP device, or a component or apparatus (for example, a processor, a chip, or a chip system, etc.) applied to the BGP device, or a logic module or software capable of implementing all or part of the functions of the BGP device. For example, the BGP device can be a router or a switch, and the BGP device can also be referred to as a BGP speaker. In a possible design, the first communication device includes a transceiver and a processing unit. The transceiver is configured to perform operations related to receiving and / or sending in the method in the first aspect and any possible design of the first aspect. The processing unit is configured to perform operations other than the operations related to receiving and / or sending in the method in the first aspect and any possible design of the first aspect. For example, the processing unit is configured to establish a first BGP connection with a second communication device based on first BGP connection parameters; and the transceiver is configured to send a first message to the second communication device while maintaining the first BGP connection, where the first message includes first BGP connection parameters to be updated, and the first BGP connection parameters to be updated include at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and the first BGP connection parameters are updated according to the first BGP connection parameters to be updated.

[0034] In a possible design, the processing unit is further configured to: establish, with the second communication device, a second BGP connection based on second BGP connection parameters; and the transceiver is further configured to receive, while the second BGP connection is maintained, a second BGP Open message sent by the second communication device, the second BGP Open message including second BGP connection parameters to be updated, the second BGP connection parameters to be updated including at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and the processing unit is further configured to update the second BGP connection parameters based on the second BGP connection parameters to be updated.

[0035] In a possible design, the transceiver is further configured to send, to the second communication device, a connection identifier of the first BGP connection.

[0036] In a possible design, the transceiver is further configured to receive a second message fed back by the second communication device, the second message indicating that the first message is received by the second communication device.

[0037] In a fourth aspect, a second communication device is provided, configured to perform the method in the second aspect and any possible design of the second aspect. The second communication device can be a BGP device, or a component or apparatus (for example, a processor, a chip, or a chip system, etc.) applied to the BGP device, or a logic module or software capable of implementing all or part of the function of the BGP device. For example, the BGP device can be a router or a switch, etc. The BGP device can also be referred to as a BGP speaker. In a possible design, the second communication device includes a transceiver and a processing unit. The transceiver is configured to perform the operations related to receiving and / or sending in the method in the second aspect and any possible design of the second aspect. The processing unit is configured to perform other operations in the method in the second aspect and any possible design of the second aspect, other than the operations related to receiving and / or sending. For example, the processing unit is configured to: establish, with the first communication device, a first BGP connection based on first BGP connection parameters; and the transceiver is configured to receive, while the first BGP connection is maintained, a first message sent by the first communication device, the first message including first BGP connection parameters to be updated, the first BGP connection parameters to be updated including at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and the processing unit is further configured to update the first BGP connection parameters based on the first BGP connection parameters to be updated.

[0038] In a possible design of the first aspect, the processing unit is further configured to establish, with the first communication device, a second BGP connection based on the second BGP connection parameter; and the transceiver is further configured to send, to the first communication device, a second BGP Open message while maintaining the second BGP connection, the second BGP Open message including a second BGP connection parameter to be updated, the second BGP connection parameter to be updated including at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; and the processing unit is further configured to update the second BGP connection parameter according to the second BGP connection parameter to be updated.

[0039] In a possible design of the first aspect, the transceiver is further configured to send, to the first communication device, a second message, the second message being used to indicate that the second communication device receives the first message.

[0040] In a fifth aspect, a communication device is provided, which includes a module configured to perform some or all of the operations of the first aspect and any possible design of the first aspect, and / or the second aspect and any possible design of the second aspect. For example, the communication device can be a chip, or a BGP device including the chip.

[0041] In a sixth aspect, a communication device is provided, which includes at least one processor and a memory. The at least one processor is configured to read and execute a program stored in the memory, so that the device performs the method of the first aspect and any possible design of the first aspect, and / or the second aspect and any possible design of the second aspect.

[0042] In a seventh aspect, a communication system is provided, which includes a first communication device and a second communication device. The first communication device is configured to perform the method of the first aspect and any possible design of the first aspect. The second communication device is configured to perform the method of the second aspect and any possible design of the second aspect.

[0043] In an eighth aspect, a computer-readable storage medium is provided, which stores computer instructions. When the computer instructions are executed on a communication device, the communication device performs the method of the first aspect and any possible design of the first aspect, and / or the second aspect and any possible design of the second aspect.

[0044] In a ninth aspect, a computer program product is provided, which includes a computer program. When the computer program is executed on a communication device, the communication device performs the method of the first aspect and any possible design of the first aspect, and / or the second aspect and any possible design of the second aspect.

[0045] In a tenth aspect, a chip is provided, which stores computer-executable instructions that, when executed, cause performance of the method of the first aspect and any possible design thereof, and / or the method of the second aspect and any possible design thereof. BRIEF DESCRIPTION OF DRAWINGS

[0046] FIG. 1 is a schematic diagram of an architecture of a BGP network according to an embodiment of the present application;

[0047] FIG. 2 is a schematic diagram of a state of a BGP protocol according to an embodiment of the present application;

[0048] FIG. 3 is a schematic diagram of a method for dynamically negotiating BGP connection parameters according to an embodiment of the present application;

[0049] FIG. 4 is a schematic diagram of a method for dynamically negotiating BGP connection parameters according to an embodiment of the present application;

[0050] FIG. 5 is a schematic diagram of a method for dynamically negotiating BGP connection parameters according to an embodiment of the present application;

[0051] FIG. 6 is a schematic diagram of a format of a first BGP Open message according to an embodiment of the present application;

[0052] FIG. 7 is a schematic diagram of a method for dynamically negotiating BGP connection parameters according to an embodiment of the present application;

[0053] FIG. 8 is a schematic diagram of a format of a Type 128 message according to an embodiment of the present application;

[0054] FIG. 9 is a schematic diagram of a method for dynamically negotiating BGP connection parameters according to an embodiment of the present application;

[0055] FIG. 10 is a schematic diagram of a format of a plurality of TLV fields in a BGP Dynamic Update Sub-TLVs field according to an embodiment of the present application;

[0056] FIG. 11 is a schematic diagram of a format of a Type 10 message according to an embodiment of the present application;

[0057] FIG. 12 is a schematic diagram of a structure of a communication apparatus according to an embodiment of the present application;

[0058] FIG. 13 is a schematic diagram of a structure of a communication apparatus or a BGP node according to an embodiment of the present application. DETAILED DESCRIPTION

[0059] Embodiments of the present application can be applied in a border gateway protocol (BGP) network. The BGP is a routing protocol for autonomous systems (AS) running on the transmission control protocol (TCP). The BGP can be used to handle the protocols of the Internet-sized network, and can also handle the protocols of multi-connection between unrelated routing domains. The main function of the BGP network is to exchange network reachable information with other BGP networks. The network reachable information includes, for example, information of AS. These information effectively constructs the topology of AS interconnection, and thus eliminates the routing loop, and can realize the inter-domain routing without loop between AS.

[0060] When two ASs need to exchange routing information, each AS can specify a node running BGP to exchange routing information with other ASs. The node running BGP can be a host, but is usually implemented by a router. The routers in two ASs exchanging information by BGP can also be called border gateway or border router.

[0061] In an AS, there can be multiple border routers running BGP. The BGP running between two or more peer entities in the same AS is called IBGP (internal or interior BGP). The BGP running between peer entities belonging to different ASs is called EBGP (external or exterior BGP). The router exchanging information with other ASs on the border of the AS is the border router or border gateway.

[0062] In the BGP network, each AS is assigned a unique AS number to distinguish different ASs. For example, the AS number can be divided into 2-byte AS number and 4-byte AS number. The range of the 2-byte AS number is, for example, 1-65535, and the range of the 4-byte AS number is 1-4294967295. The node supporting the 4-byte AS number can be compatible with the node supporting the 2-byte AS number.

[0063] Figure 1 shows a schematic diagram of a BGP network architecture. The architecture includes two ASes: AS 100 and AS 200. AS 100 includes nodes A, B and C, and AS 200 includes nodes D, E and F. These nodes can be understood as nodes running BGP. The BGP running between nodes A, B and C can be understood as IBGP, the BGP running between nodes D, E and F can be understood as IBGP, and the BGP running between nodes A and E can be understood as EBGP. Each node can correspond to a Router identity (RID). Router ID can be a 32-bit unsigned integer used to uniquely identify a node or router in an AS. Any node running BGP must have a corresponding Router ID. The Router ID can be manually configured or automatically elected by a routing protocol.

[0064] In the architecture, the nodes can be routers or switches. A node sending BGP messages can be referred to as a BGP speaker, which can receive or generate new routing information and publish it to other BGP speakers. BGP speakers exchanging messages with each other can be referred to as peers or BGP peers. If the BGP peer is in the same AS, the BGP peer can be referred to as an IBGP peer. If the BGP peer is in different ASes, the BGP peer can be referred to as an EBGP peer. In some scenarios, the BGP peer can also be referred to as a BGP neighbor, the EBGP peer can be referred to as an EBGP neighbor, and the IBGP peer can be referred to as an IBGP neighbor.

[0065] Generally, EBGP peers can be physically directly connected. IBGP peers are not necessarily physically directly connected, but must be TCP reachable.

[0066] Figure 2 shows a schematic diagram of a BGP protocol state machine. The transition process between states can be understood as the process of establishing a BGP connection, which can be referred to in RFC 4271. The states of the state machine include: idle state, connect state, active state, Open message sent state, Open message confirmed state, and established state. For any node system:

[0067] In idle state, no BGP connection is received and start event is waited. If start event occurs, connectRetry timer is started and TCP connection is initiated to the neighbor. The state machine is in connect state.

[0068] In connect state, TCP connection is waited. If TCP state is established, connectRetry timer is cleared and Open message is sent. The state machine is in opensent state. If TCP connection fails, connectRetry timer is reset and Open message is sent. The state machine is in active state. If connectRetry timer expires, TCP connection is reinitiated and the state machine is in connect state.

[0069] If start time occurs but TCP connection is not completed, the state machine is in active state. In active state, TCP connection is reinitiated in response to connectRetry timer expiration. The state machine is in connect state. If TCP connection is successfully established, Open message is sent and the state machine is in opensent state. connectRetry timer is cleared and holdtime timer is reset.

[0070] When the state machine is in opensent state, Open message is sent and Open message from the neighbor is waited. If Open message from the neighbor is received and parsed correctly, the state machine is in OpenConfirm state. holdtime timer is set to the negotiated value, keepalive message is sent and keepalive timer is reset. If the message is parsed incorrectly, notification message is sent and TCP connection is closed.

[0071] When the state machine is in the OpenConfirm state, it indicates that the system has sent a keepalive message and is waiting for a keepalive message from the neighbor. If a keepalive message from the neighbor is received, the state is changed to the established state and the Holdtime timer is reset; if the keepalive timer expires and no keepalive message from the neighbor is received, the keepalive timer is reset and a keepalive message is sent; if a notification message from the neighbor is received at this time, the TCP connection is disconnected.

[0072] When the state machine is in the established state, it indicates that the BGP connection is established and update messages can be sent to exchange routing information. If the keepalive timer expires and no keepalive message is received, the keepalive timer is reset and a keepalive message is sent; if a keepalive message is received within the keepalive timer time, the holdtime timer is reset; if an error is detected or a notification message is received, the BGP connection is disconnected.

[0073] It can be understood that in the change process of the above state machine, the message types involved include Open messages, keepalive messages, update messages, and notification messages. When the BGP connection is established, router-refresh messages can also be transmitted between BGP peers.

[0074] The Open message is the first message sent after the TCP connection is established, and is used to establish the connection relationship between BGP peers and perform parameter negotiation. The Open message can include the BGP version number used by the node running BGP, the AS number to which the node belongs, the BGP ID, the hold time, etc. The Open message can also be used to announce the capability information of the device.

[0075] Wherein, the version can be understood as the version number of the BGP message. The AS number can be used to negotiate the AS number, and determine whether to establish the EGP or the IBGP. The holdtime can be understood as the time used to determine the neighbor timeout restart, that is, if the keepalive message or the update message is not received within the time, the BGP connection is considered to be interrupted, and the BGP connection can be restarted. The capability information can be used to negotiate the protocol capability supported by the BGP neighbor, and the definition in the draft-ietf-idr-dynamic-cap-16 can be referred to.

[0076] The keepalive message can be understood as a message periodically sent by the running BGP node to the BGP neighbor, which is mainly used to let the BGP neighbor know the existence of itself, and maintain the stability of the neighbor relationship. Another function is to respond to the received Open message.

[0077] The update message is mainly used to exchange route information between peers. The update message can publish reachable route information and unreachable route information. One update message can carry multiple reachable routes with the same path attribute, and can also carry multiple unreachable routes.

[0078] The function of the notification message is error notification. If the BGP speaker detects that the message sent by the opposite party has an error or actively disconnects the BGP connection, the notification message can be sent to notify the neighbor and close the connection to return to the idle state. If the notification message sent by the neighbor is received, the connection state will also be changed to the idle state. The content of the notification message can include error code, error subcode, error data and other information.

[0079] The router-refresh message can be used to require the peer to resend the route information of the specified address family.

[0080] At present, the protocol of RFC4271 stipulates that when the BGP device is in the established state, only the update message, the notification message and the keepalive message can be processed, and the BGP connection parameters of the neighbor cannot be updated. If the BGP connection parameters of the BGP device need to be re-negotiated, the BGP connection needs to be disconnected, and after the TCP connection is re-established, the Open message is re-sent to re-establish the BGP connection. The Open message carries the BGP connection parameters to be negotiated.

[0081] For example, BGP capabilities such as multi-address family capability, graceful-restart capability or add-path capability are usually published through BGP Open message when BGP connection is initialized, and the neighbor can use the capability after successful negotiation and completion of BGP connection establishment. However, if a capability needs to be enabled or disabled on a successfully established BGP session, the established session needs to be reset, i.e. the BGP connection is disconnected, and the Open message is republished for capability negotiation in the process of rebuilding the BGP connection. In this way, in the case of large-scale routing, a large amount of routing convergence is caused, and the service convergence time is relatively long, and the user experience is poor.

[0082] Currently, in draft-ietf-idr-dynamic-cap-16, dynamic capability negotiation is defined, which allows dynamic updating of the capability of the BGP device on an already established BGP connection. However, in the draft, only how to update the capability information of the BGP device is defined, and the capability negotiation of the BGP device can be performed through the capability message.

[0083] Therefore, how to avoid a large amount of routing convergence caused in the current BGP connection parameter negotiation process is a problem to be solved.

[0084] Therefore, the application provides a method for dynamically negotiating BGP connection parameters. In the method, the parameter negotiation can be performed through a newly added BGP message or using the original message + configuration in the process of dynamically negotiating connection parameters while maintaining the BGP connection uninterrupted, i.e. adjusting the BGP connection parameters while maintaining the BGP connection uninterrupted. In this way, in the case of large-scale routing, the service convergence time can be reduced. In particular, in the case of adjusting parameters irrelevant to routing, such as hold time, a large amount of routing convergence caused by neighbor interruption can be avoided.

[0085] As shown in FIG. 3, the application provides a flowchart of a method 30 for dynamically negotiating BGP connection parameters. In the method, if new BGP connection parameters are required in the case of establishing a BGP connection, the BGP connection parameter update can be performed through a message while maintaining the BGP connection. The method 30 includes the following processes.

[0086] 301. The first communication device and the second communication device establish a first BGP connection based on first BGP connection parameters.

[0087] In some embodiments, the first communication device and the second communication device can be routers or switches. The first BGP connection established by the first communication device and the second communication device can be an EBGP connection or an IBGP connection. The first communication device and the second communication device can also be understood as BGP speaker 1 and BGP speaker 2.

[0088] The process of establishing the first BGP connection between the first communication device and the second communication device can refer to the description of the BGP protocol state in the above description of FIG. 2, that is, it can be generally understood that: after the TCP connection is established, the first communication device and the second communication device send Open messages to each other for negotiating the first BGP connection parameters. Further, the state machines of the first communication device and the second communication device switch to the OpenConfirm state. When the first communication device and the second communication device respectively receive the keepAlive message sent by the opposite end, the state machine switches to the established state, and the first BGP connection establishment is completed. For details, refer to the above description of FIG. 2.

[0089] In some embodiments, the first BGP connection parameters can be understood as that the first communication device stores the BGP connection parameters of the first communication device and the BGP connection parameters of the second communication device, and the second communication device stores the BGP connection parameters of the second communication device and the BGP connection parameters of the first communication device.

[0090] For the first communication device, the stored BGP connection parameters of the first communication device can be preconfigured in the first communication device, and the stored BGP connection parameters of the second communication device can be received from the second communication device during the process of establishing the first BGP connection, for example, received from the second communication device through the Open message.

[0091] Similarly, for the second communication device, the stored BGP connection parameters of the second communication device can be preconfigured in the second communication device, and the stored BGP connection parameters of the first communication device can be received from the first communication device during the process of establishing the first BGP connection, for example, received from the first communication device through the Open message.

[0092] For example, the BGP connection parameters of the first communication device include the AS number of the first communication device, the hold time of the first communication device, and the BGP identifier of the first communication device. Optionally, it can also include the capability information of the first communication device.

[0093] Similarly, the BGP connection parameters of the second communication device include an AS number of the second communication device, a hold time of the second communication device, and a BGP identifier of the second communication device. Optionally, the capability information of the second communication device can also be included.

[0094] For example, the AS number of the first communication device and the AS number of the second communication device indicate that the first BGP connection established between the first communication device and the second communication device is an EBGP connection or an IBGP connection. The hold time of the first communication device indicates that the first communication device does not receive the keepalive message or the update message sent by the second communication device within the hold time timer, and the first communication device can disconnect the first BGP connection established with the second communication device and restart the BGP connection. The hold time of the second communication device indicates that the second communication device does not receive the keepalive message or the update message sent by the first communication device within the hold time timer, and the second communication device can disconnect the first BGP connection established with the first communication device and restart the BGP connection. The BGP identifier of the first communication device indicates the routing identifier of the first communication device, and the BGP identifier of the second communication device indicates the routing identifier of the second communication device.

[0095] In some embodiments, the first communication device and the second communication device establish the first BGP connection, which can also be understood as that the first communication device and the second communication device establish the first BGP session. When the first communication device and the second communication device establish the first BGP session, the first communication device and the second communication device can perform service routing. The first BGP connection parameters can also be understood as the first BGP session parameters.

[0096] In some embodiments, one BGP connection corresponds to one BGP session. The first communication device can establish multiple BGP connections, or multiple BGP sessions, with the second communication device, and the first communication device can also establish one BGP connection or one BGP session with each of the plurality of communication devices.

[0097] 302. In the case of maintaining the first BGP connection, the first communication device sends a first message to the second communication device, and the first message includes the first BGP connection parameters to be updated, and the first BGP connection parameters to be updated include at least one of the AS number, the hold time, or the BGP identifier.

[0098] In some embodiments, the first message can be a border gateway protocol message (BGP message).

[0099] In the present application, in some embodiments, the first message can be a newly defined BGP message, or can be a border gateway protocol open message (BGP Open message). If the first message is a BGP Open message, it can be a newly defined BGP Open message, or can be a BGP Open message using the original BGP Open message.

[0100] In some embodiments, the first message can also be a newly defined link layer discovery protocol (LLDP message) or a layer-3 discovery and liveness (L3DL) message.

[0101] The specific implementation of the first message can be seen from the description below.

[0102] The first BGP connection parameter to be updated corresponds to a parameter to be negotiated by the first BGP session or the first BGP connection. The first BGP connection can be any one of a plurality of BGP connections established by the first communication device and the second communication device, or in other words, the first BGP session can be any one of a plurality of BGP sessions established by the first communication device and the second communication device. The first BGP connection parameter to be updated can also be understood as the first BGP session parameter to be updated.

[0103] The first BGP connection parameter to be updated can be understood as a BGP connection parameter to be updated by the first communication device for the first BGP connection saved by the first communication device.

[0104] In some embodiments, the AS number included in the first BGP connection parameter to be updated can be understood as the AS number of the first BGP node, which is used to determine whether the first BGP connection established between the first communication device and the second communication device is an EBGP connection or an IBGP connection. The hold time can be understood as a hold time timer, and when the first communication device does not receive a keepalive message or an update message sent by the second communication device within the hold time timer, the first communication device can disconnect the first BGP connection established with the second communication device and restart the BGP connection. The BGP identifier can be understood as the BGP identifier of the first communication device, which is used to negotiate the router identifier of the first communication device so as to be recognized by the second communication device.

[0105] In some embodiments, the method further comprises: receiving, by the first communication device, a second message of the second communication device, the second message indicating that the second communication device has received the first message.

[0106] 303、the first communication device updates the first BGP connection parameter according to the first BGP connection parameter to be updated.

[0107] The first communication device updates the first BGP connection parameter according to the first BGP connection parameter to be updated, which can also be understood as the first communication device validating the first BGP connection parameter to be updated on the side of the first communication device.

[0108] In some embodiments, for the second communication device, the second message can be fed back to the first communication device, which can be considered that the second communication device accepts the first BGP connection parameter to be updated and can update locally according to the first BGP connection parameter to be updated. When the first communication device receives the second message, the first communication device can validate the first BGP connection parameter to be updated on the side of the first communication device. In this way, the update of the first BGP connection parameter to be updated between the first communication device and the second communication device is completed. Moreover, the update is completed while maintaining the first BGP connection, which can avoid a large number of route convergences caused by the interruption of the first BGP connection.

[0109] In some embodiments, the scenario of triggering the first communication device to send the first message carrying the first BGP connection parameter to be updated can be as follows: when the operator of the first communication device performs network integration, resulting in the modification of the AS number, the first message can be used to negotiate the AS number with the second communication device. In this way, the second communication device can determine whether the connection with the first communication device is EBGP or IBGP according to the AS number, and the routing behavior of the second communication device needs to be refreshed according to whether the connection is EBGP or IBGP. At the same time, the AS number carried by the routing of the second communication device will also be refreshed according to the negotiated AS number; when the business of the first communication device grows, or converges, or for other reasons, the hold time needs to be adjusted, the first message can be used to negotiate the hold time of the first communication device with the second communication device. For example, when the business grows, the hold time of the first communication device can be increased, and when the task converges, the hold time of the first communication device can be reduced; when the router-id of the device where the first communication device is located is re-planned, the BGP identifier of the first communication device can be negotiated with the second communication device through the first message.

[0110] In some embodiments, the first BGP connection parameter to be updated can also include capability information, which indicates the capability supported by the first communication device. The field of the capability information in the first message can be a capability unit (capability unit), which is used to negotiate the protocol capability supported by the BGP neighbor, and the specific definition can refer to draft-ietf-idr-dynamic-cap-16.

[0111] Thus, the scenario of triggering the first communication device to send the first message can also be that when the capability unit of the first communication device is changed, re-negotiation is needed, and the capability unit of the first communication device can be negotiated with the second communication device through the first message, so that the second communication device determines the capability supported by the first communication device.

[0112] The present application does not limit the scenario of triggering the first communication device to send the first message, and the scenario of triggering the first communication device to send the first message to the second communication device can also be other scenarios.

[0113] The following is described by taking the first message as an example of a border gateway protocol message and a non-border gateway protocol message. The border gateway protocol message is, for example, a newly defined BGP message or a border gateway protocol open message (BGP Open message), and the non-border gateway protocol message is, for example, an LLDP message or an L3DL message.

[0114] The following embodiment is described by taking the first communication device as a first BGP node and the second communication device as a second BGP node. The first BGP node and the second BGP node can be understood as a BGP speaker 1 and a BGP speaker 2.

[0115] As shown in FIG. 4, the method 40 provided by the embodiment of the present application is a flowchart of a method for dynamically negotiating a BGP connection parameter. In the method, the first message can be a newly defined BGP message or a BGP Open message. The method 40 includes the following processes. The way of taking the first message as a newly defined BGP message can be recorded as way one, and the way of taking the first message as a BGP Open message can be recorded as way two.

[0116] 401. The first BGP node establishes a first BGP connection with the second BGP node based on a first BGP connection parameter.

[0117] The implementation of step 410 can refer to the description of step 301.

[0118] 402. The first BGP node determines a first BGP connection parameter to be updated, and the first BGP connection parameter to be updated includes at least one of an AS number, a hold time or a BGP identifier.

[0119] The first BGP node determines which BGP connection parameter to update can refer to the above-mentioned scenario of triggering the first communication device to send the first message.

[0120] In some embodiments, the first BGP connection parameter to be updated includes at least one of an AS number, a hold time, a BGP identifier, or a capability unit.

[0121] In the first BGP connection parameter to be updated, the capability unit can be one or more, and each capability unit includes a capability code, a capability length, and a capability value. Each capability unit can also include an action field, for example, when the action field occupies 0 bits, it indicates that the capability unit is a published capability, and when the action field occupies 1 bit, it indicates that the capability unit is a deleted capability.

[0122] 403、In the case of maintaining the first BGP connection, the first BGP node sends a newly defined first BGP message to the second BGP node, and the first BGP message includes the first BGP connection parameter to be updated.

[0123] In some embodiments, in the first way, in the first BGP connection parameter to be updated, the AS number, the hold time, and the BGP identifier are full updates. That is, when at least one of the AS number, the hold time, or the BGP identifier of the first BGP node needs to be negotiated, the first BGP node needs to carry the BGP connection parameter that needs to be negotiated and the BGP connection parameter that remains unchanged in the newly defined BGP message, so as to facilitate the implementation of the BGP message. The newly defined BGP message can define a new type in the message header, so that the BGP peer can process the newly defined BGP message. The message body of the newly defined BGP message can refer to the format of the existing OPEN message to carry various parameters required to update the BGP connection. It can also be modified according to actual needs, for example, the format shown in Table 1 below.

[0124] In the first BGP connection parameter, if the capability unit is also included, only the changed capability unit can be carried, and the unchanged capability unit is not carried. For example, when a capability unit needs to be added or deleted, the capability unit can be carried.

[0125] In some embodiments, the newly defined first BGP message further comprises at least one of a flag bit and a version number of the first BGP message. The flag bit indicates whether the first BGP message is a request message or a response message. For the first BGP node, the flag bit in the sent first BGP message indicates that the first BGP message is a request message, i.e. requests to negotiate the BGP connection parameters. The version number of the first BGP message can be used by the second BGP node to parse the received first BGP message according to the version number of the first BGP message.

[0126] For example, the format of the newly defined first BGP message can be as shown in Table 1.

[0127] Table 1

[0128] R represents the R flag bit, which can occupy 1 bit, and is used to identify that the first BGP message sent by the first BGP node is a request message. For example, when the value of the R flag bit is 0, it indicates that the first BGP message sent by the first BGP node is a request message; similarly, when the value of the R flag bit is 1, it indicates that the first BGP message sent by the first BGP node is a response message.

[0129] version represents the version number of the first BGP message, which can occupy 1 byte.

[0130] AS number can occupy 2 bytes or 4 bytes, and is used for the first BGP node to determine whether to establish EBGP or IBGP. For example, before the first BGP node sends the first BGP message, EBGP is established between the first BGP node and the second BGP node. When the first BGP node determines to update the BGP neighbor relationship, it can send the first BGP message carrying the AS number to indicate that EBGP is updated to IBGP.

[0131] hold time can occupy 2 bytes, and is used for the first BGP node to determine the time of neighbor timeout restart. For example, when the traffic of the first BGP node increases, the first BGP node can send the first BGP message carrying the hold time to indicate the length of the hold time timer, and the length is increased. When the first BGP node does not receive the keepalive message or the update message sent by the opposite end within the length of the hold time timer, the first BGP connection can be disconnected, and the BGP connection is restarted.

[0132] identifier can occupy 4 bytes, and is used to negotiate the Router-id of the first BGP node. That is, when the router-id of the first BGP node is updated, the first BGP node can send the first BGP message carrying the identifier to indicate the router-id of the first BGP node.

[0133] The capability unit can be used to negotiate the protocol capabilities supported by the first BGP node, including newly added capabilities or deleted capabilities.

[0134] 404、The second BGP node negotiates the BGP connection parameters of the first BGP connection according to the first BGP connection parameters to be updated, and feeds back a second BGP message to the first BGP node, the second BGP message indicating that the second BGP node receives the first BGP node.

[0135] In some embodiments, when the second BGP node receives the first BGP message sent by the first BGP node, the second BGP node can update the parameters of the first BGP node saved locally by the second BGP node for the first BGP connection according to the first BGP connection parameters to be updated carried in the first BGP message. In some embodiments, the second message described above can be the second BGP message in step 404, and the second BGP message can be understood as a response message of the first BGP message, i.e., equivalent to an ACK message.

[0136] In some embodiments, the format of the second BGP message can be similar to the format of the first BGP message shown in Table 1, the second BGP message can include other fields in the first BGP message except the R flag bit, and the value of the R flag bit in the second BGP message is different from the value of the R flag bit in the first BGP message, the R flag bit in the second BGP message indicating that the second BGP message is a response message.

[0137] In some embodiments, when the second BGP message is received by the first BGP node, the first BGP node can consider that the second BGP node has completed the local BGP connection parameter negotiation, i.e., has updated the BGP connection parameters of the first BGP node saved locally by the second BGP node for the first BGP connection.

[0138] 405、The first BGP node validates the first BGP node local first BGP connection parameters to be updated.

[0139] In some embodiments, when the second BGP message is received by the first BGP node, it is considered that the second BGP node has received the first BGP message, or it is considered that the second BGP node has received the first BGP message and completed the BGP connection parameter negotiation of the first BGP node saved locally for the first BGP connection, and the first BGP node can validate or enable the first BGP connection parameters to be updated of the first BGP node.

[0140] In this way, for the established first BGP connection, the application can complete the negotiation of the BGP connection parameters through the newly defined BGP message without disconnecting the first BGP connection. This can avoid the large amount of route convergence caused by the interruption of the BGP connection, and can also reduce the service convergence time in the case of large-scale routing.

[0141] In some embodiments, when the second BGP node receives the first BGP message, if the second BGP node does not support the capability of non-interrupting the BGP connection for the negotiation of the BGP connection parameters, or the second BGP node parses the first BGP message incorrectly, the second BGP node determines that the negotiation is unsuccessful, and can disconnect the first BGP connection with the first BGP node. In this case, the first BGP node and the second BGP node can perform the negotiation of the BGP connection parameters according to the original process of rebuilding the BGP connection.

[0142] In some embodiments, the first message can be implemented in the following manner two, that is, when the first message is the BGP Open message, the application can pre-configure the BGP Open message or newly define the format of the BGP Open message to indicate the second BGP node to negotiate the BGP connection parameters without interrupting the BGP connection.

[0143] In the case of using manner two, the process of the negotiation of the BGP connection parameters between the first BGP node and the second BGP node is similar to that shown in FIG. 4. The difference is that in the process of dynamically negotiating the BGP connection parameters shown in FIG. 5, step 403 can be replaced by step 503, and step 404 can be replaced by step 504. For details, refer to the process of the method 50 shown in FIG. 5.

[0144] 503、The first BGP node sends a first BGP Open message to the second BGP node, and the first BGP Open message includes indication information indicating that the first BGP Open message is used to carry the first BGP connection parameters to be updated.

[0145] In some embodiments, the sending of the first BGP Open message by the first BGP node can be understood as being triggered automatically by the first BGP node after adjusting the parameters of the first BGP connection.

[0146] In some embodiments, the indication information can be implemented by a type-length-value (TLV) field.

[0147] In some embodiments, the optional parameter of the first BGP Open message includes a TLV field, and the TLV field indicates that the first BGP Open message is used to carry the first BGP connection parameter to be updated.

[0148] For example, the TLV field can be a newly added TLV field in the original Optional Parameter of the BGP Open message, which is used to identify that the type of the first BGP Open message is to update the BGP connection parameter, that is, to indicate that the first BGP Open message carried by the second BGP node carries the first BGP connection parameter to be updated. In this way, for the second BGP node, in the case that the second BGP node establishes the first BGP connection with the first BGP node, or in the case that the state machine of the second BGP node is in the Established state, if the second BGP node receives the first BGP Open message and identifies the TLV field, the second BGP node will not consider that the first BGP Open message is received in the case that the BGP connection is disconnected, and the second BGP node will not continue to perform the subsequent process of establishing the BGP connection as shown in the state machine flow of FIG. 2 after receiving the first BGP Open message and performing parameter negotiation, but will perform BGP connection parameter negotiation according to the first BGP connection parameter to be updated carried by the first BGP Open message without interrupting the first BGP connection when identifying the TLV field.

[0149] In this way, for the second BGP node, when the second BGP node correctly parses the first BGP Open message and obtains the first BGP connection parameter to be updated, the second BGP node can perform BGP connection parameter negotiation for the saved BGP connection parameter of the first BGP node for the first BGP connection locally according to the first BGP connection parameter to be updated, that is, can perform parameter updating.

[0150] In some embodiments, the newly added TLV field of the first BGP Open message can be equivalent to an identifier, which is used to identify that the type of the first BGP Open message is to update the BGP connection parameter, or to dynamically negotiate the BGP connection parameter, and in this case, the TLV field does not carry the first BGP connection parameter to be updated. The first BGP connection parameter to be updated can be carried in other fields of the first BGP Open message.

[0151] Or, the TLV field newly added in the first BGP Open message carries not only the above-mentioned identification, but also the first BGP connection parameter to be updated.

[0152] For example, as shown in Fig. 6, the format of the first BGP Open message includes version field, my autonomous system field, hold time field, BGP identifier field, optional parameters length field and optional parameters field. The my autonomous system field is similar to the AS number in Table 1. The optional parameters length field represents the length of the optional parameters field. The optional parameters field can include other optional fields besides the version field, my autonomous system field, hold time field and BGP identifier field.

[0153] In the present application, the TLV field carried by the first BGP Open message can be carried in the optional parameters field.

[0154] For example, the optional parameters field can also carry fields such as capability, parameter type, parameter length and various capability information.

[0155] In some embodiments, if the second BGP node has not established the first BGP connection with the first BGP node, i.e., step 401 is not performed, and the state machines of the second BGP node and the first BGP node are in the Non-Established state, if the first BGP node sends a first BGP Open message to the second BGP node, i.e., the format of the first BGP Open message can be similar to the format of the original BGP Open, the second BGP node can update the saved BGP connection parameters of the first BGP node locally for the first BGP connection according to the first BGP connection parameters to be updated in the first BGP Open message upon receiving the first BGP Open message, and establish the BGP connection according to the state machine change process shown in FIG. 2.

[0156] 504、The second BGP node updates the first BGP connection parameters according to the first BGP connection parameters to be updated, and feeds back a third BGP Open message to the first BGP node, the third BGP Open message indicating that the second BGP node has received the first BGP Open message.

[0157] When the second BGP node correctly parses the first BGP Open message and identifies the TLV field, it indicates that the second BGP node supports BGP connection parameter update processing according to the BGP Open message in the Established state. The second BGP node can update the saved BGP connection parameters of the first BGP node locally for the first BGP connection according to the first BGP connection parameters to be updated.

[0158] In some embodiments, when the second BGP node receives the first BGP Open message, it can not feed back a third BGP Open message to the first BGP node, or it can also feed back a third BGP Open message to the first BGP node, and the third BGP Open message can be understood as an ACK message.

[0159] In some embodiments, if the second BGP node cannot identify the TLV field, it can be understood that the second BGP node does not support the BGP connection parameter update processing according to the BGP Open message in the established state, and in this case, the negotiation is unsuccessful. In this case, the second BGP node can disconnect the first BGP connection, and perform BGP connection reconstruction, and in the process of reconstruction, the first BGP connection parameter to be updated can be carried in the BGP Open message to perform BGP connection parameter negotiation. Alternatively, the second BGP node can send an alarm indication to the first BGP node to indicate that the negotiation is unsuccessful, and the first BGP node can disconnect the first BGP connection with the second BGP node according to the alarm indication, to send the BGP Open message to perform BGP connection parameter negotiation and reconstruct the BGP connection.

[0160] In some embodiments, the format and content of the third BGP Open message can be the same as the format and content of the first BGP Open message. When the first BGP node receives the third BGP Open message, it can be considered that the second BGP node has received the first BGP Open message, and it is determined that the second BGP node supports the BGP connection parameter update processing according to the first BGP Open message in the established state. In this case, step 405 can be continued after step 504 to complete the local update of the first BGP node for the first BGP connection parameter. Thus, in this way two, the present application can not need to add a BGP message, and directly sends the BGP Open message in the established state to perform BGP connection parameter negotiation, which can complete the BGP connection parameter update while maintaining the first BGP connection, can avoid a large number of route convergence behaviors caused by BGP connection interruption, and can also reduce the service convergence time in a large-scale route case.

[0161] In some embodiments, the first message described above can be implemented in the following way three, that is, when the first message is a BGP Open message, the BGP Open message can use the original message format, that is, no new message field is added, and the behavior of receiving the BGP Open message in the Established state is pre-controlled by the command line. Of course, the ability of the command line needs to be enabled at both ends of the first communication device and the third communication device to ensure normal BGP connection parameter negotiation without interrupting the BGP connection.

[0162] Thus, in some embodiments, when the command line is configured in the first communication device and the third communication device, if the BGP connection parameter negotiation is initiated by the third communication device to the first communication device, the method can further include:

[0163] The first communication device and the third communication device establish a second BGP connection based on the second BGP connection parameters;

[0164] The first communication device receives a second BGP Open message sent by the third communication device while maintaining the second BGP connection, the second BGP Open message including second BGP connection parameters to be updated, the second BGP connection parameters to be updated including at least one of an AS number, a hold time or a BGP identifier;

[0165] The first communication device updates the second BGP connection parameters according to the second BGP connection parameters to be updated.

[0166] In some embodiments, when the first communication device and the third communication device establish the second BGP connection, for the third communication device, the third communication device locally saves the second BGP connection parameters, which include the BGP connection parameters of the third communication device for the second BGP connection and the BGP connection parameters of the first communication device for the second BGP connection received from the first communication device. Similarly, for the first communication device, the first communication device locally saves the second BGP connection parameters, which include the BGP connection parameters of the first communication device for the second BGP connection and the BGP connection parameters of the third communication device for the second BGP connection received from the third communication device.

[0167] In some embodiments, when the first communication device and the third communication device establish the second BGP connection, for the third communication device, the third communication device locally saves the second BGP connection parameters, which include the BGP connection parameters of the third communication device for the second BGP connection and the BGP connection parameters of the first communication device for the second BGP connection received from the first communication device. Similarly, for the first communication device, the first communication device locally saves the second BGP connection parameters, which include the BGP connection parameters of the first communication device for the second BGP connection and the BGP connection parameters of the third communication device for the second BGP connection received from the third communication device.

[0168] The third communication device and the second communication device can be the same or different devices.

[0169] In this way, the first communication device can perform BGP connection parameter negotiation locally according to the second BGP connection parameters to be updated carried in the received second BGP Open message while the first communication device and the third communication device maintain the second BGP connection.

[0170] Similarly, in some embodiments, when a command line is configured in the second communication device and the third communication device, if the BGP connection parameter negotiation is initiated by the second communication device to the third communication device, the method can further include:

[0171] establishing, by the second communication device and the third communication device, a second BGP connection based on the second BGP connection parameters;

[0172] sending, by the second communication device to the third communication device, a second BGP Open message while maintaining the second BGP connection, the second BGP Open message including second BGP connection parameters to be updated, the second BGP connection parameters to be updated including at least one of an AS number, a hold time, or a BGP identifier;

[0173] updating, by the second communication device, the second BGP connection parameters according to the second BGP connection parameters to be updated.

[0174] In some embodiments, when the second communication device and the third communication device establish the second BGP connection, for the second communication device, the second communication device locally stores second BGP connection parameters, the second BGP connection parameters including BGP connection parameters of the second communication device for the second BGP connection and BGP connection parameters of the third communication device for the second BGP connection received from the third communication device. Similarly, for the third communication device, the third communication device locally stores the second BGP connection parameters, the second BGP connection parameters including BGP connection parameters of the third communication device for the second BGP connection and BGP connection parameters of the second communication device for the second BGP connection received from the second communication device.

[0175] In the case of maintaining the second BGP connection, if the second communication device side has reconfiguration or update (not yet effective) for the BGP connection parameter of the second BGP connection, the second BGP connection parameter to be updated carried in the second BGP Open message sent by the second communication device includes the BGP connection parameter updated by the second communication device side for the second BGP connection, that is, at least one of the AS number, the hold time or the BGP identifier included in the second BGP connection parameter to be updated is the BGP connection parameter reconfigured or updated by the second communication device for the second BGP connection. The third communication device can update the BGP connection parameter of the second communication device saved by the third communication device for the second BGP connection according to the second BGP connection parameter to be updated. The second communication device renews the second BGP connection parameter to be updated at the local end of the second communication device side for the second BGP connection.

[0176] Wherein, the third communication device and the first communication device are the same device, or the third communication device and the first communication device are not the same device. Here, the third communication device establishing the second BGP connection with the second communication device can be the same device as the third communication device establishing the second BGP connection with the first communication device, or can not be the same device.

[0177] Taking the first communication device and the third communication device as BGP nodes as an example, in the case of the third mode, the process of parameter negotiation between the first BGP node and the third BGP node is similar to the process shown in FIG. 5. The difference is that, in the third mode, the format of the second BGP Open message is different from the format of the first BGP Open message in the second mode. The format of the second BGP Open message in the third mode can refer to the format shown in FIG. 6, but the optional parameters field does not carry the first TLV field. Based on the third mode, as shown in FIG. 7, a method 70 for dynamically negotiating BGP connection parameters provided by an embodiment of the present application is a flowchart, and the method 70 includes the following processes.

[0178] 701, configure a command line in the first BGP node and the third BGP node, the command line being used to control the BGP node to perform BGP connection parameter negotiation according to the received BGP Open message in the established state.

[0179] The first BGP node corresponds to the first communication device, and the third BGP node corresponds to the third communication device.

[0180] 702, the first BGP node and the third BGP node establish a second BGP connection based on the second BGP connection parameter.

[0181] 703、In the case of maintaining the second BGP connection, the third BGP node sends a second BGP Open message to the first BGP node, the second BGP Open message including the second BGP connection parameter to be updated, the second BGP connection parameter to be updated including at least one of an AS number, a hold time or a BGP identifier.

[0182] Correspondingly, the first BGP node receives the second BGP Open message sent by the second BGP node.

[0183] Similar to the above, the second BGP connection parameter to be updated is the BGP connection parameter to be updated by the third BGP node for the second BGP connection. For example, the AS number carried in the second BGP connection parameter to be updated can be used to indicate to the first BGP node that the third BGP node wants to establish EBGP or IBGP with the first BGP node, the hold Time indicates the time of the third BGP node timeout restart, and the BGP identifier indicates the route identifier of the third BGP node.

[0184] 704、The first BGP node updates the second BGP connection parameter according to the second BGP connection parameter to be updated, and feeds back a third BGP Open message to the third BGP node, the third BGP Open message indicating that the first BGP node has received the second BGP Open message.

[0185] 705、The third BGP node updates the second BGP connection parameter according to the second BGP connection parameter to be updated.

[0186] In other words, the third BGP node validates the second BGP connection parameter to be updated.

[0187] In some embodiments, if the first BGP node receives the second BGP Open message in the non-established state, the processing behavior of the first BGP node to the second BGP Open message can be similar to that of the original BGP Open message, which can be seen from the state machine flow shown in FIG. 2.

[0188] If the first BGP node is not configured with a command line, or in other words, if the first BGP node is not configured to update the BGP connection parameter in the Established state, the processing behavior of the first BGP node to the second BGP Open message can be similar to that of the original BGP Open message, which can be seen from the state machine flow shown in FIG. 2.

[0189] In this way, the application can complete BGP connection parameter update while maintaining the second BGP connection through pre-configuration of the command line without format change of the BGP Open message, can avoid the behavior of massive route convergence caused by neighbor interruption, and can reduce the service convergence time in the case of large-scale routing.

[0190] In some embodiments, the first message can be implemented in the following manner four. In the manner four, the first message is an LLDP message. In other words, the first message is a newly added LLDP message or an LLDP extended message, which can be used to support dynamic update of BGP connection parameters of the BGP neighbor.

[0191] In some scenarios, the BGP node can discover the neighbor and establish the BGP connection using the LLDP message of Type 127. In the application, in the case of adding the LLDP message, the LLDP message can be referred to as Type 128 message or other name message.

[0192] For example, as shown in FIG. 8, it is a format diagram of an LLDP message of Type 128. The LLDP message includes fields such as Type (128), length, OUI (3 Octets) 00-00-5E, OUI continued, TBD, and BGP dynamic update sub-TLVs (BGP dynamic update sub-TLVs). Among them, the Type (128) field is used to indicate that the type of the LLDP message is 128; the length field indicates the length of the LLDP message, the BGP dynamic update sub-TLVs indicates the sub-TLV carried by the LLDP message, which is used to support dynamic update of BGP connection parameters of the BGP neighbor. OUI (3 Octets) 00-00-5E OUI continued and TBD can refer to the definition in the existing IEEE-802-IANA protocol.

[0193] Considering that one or more BGP connections can be established between the first communication device and the second communication device, the number of established connections can be one or more, in the case of establishing multiple BGP connections between the first communication device and the second communication device, the first communication device needs to notify the opposite end of the connection identifier to be negotiated if it wants to negotiate the BGP connection parameters with the second communication device.

[0194] Therefore, in some embodiments, before the first communication device sends the first message, the method further includes:

[0195] The first communication device sends a connection identifier of the first BGP connection to the second communication device. In this application, the connection identifier can also be understood as a session ID.

[0196] In this way, for the second communication device, when the second communication device receives the LLDP packet carrying the first BGP connection parameter, the second communication device can determine that the parameter negotiated is the parameter of the first BGP connection according to the connection identifier of the first BGP connection.

[0197] Still taking the first communication device and the second communication device as BGP nodes as an example, FIG. 9 is a flowchart of a method 90 for dynamically negotiating a BGP connection parameter, and the method 90 includes the following steps.

[0198] 901. The first BGP node establishes one or more BGP connections with the second BGP node, wherein the first BGP connection is established based on a first BGP connection parameter.

[0199] 902. The first BGP node sends a connection identifier of the first BGP connection to the second BGP node.

[0200] For example, after the first BGP node enters the established state, the first BGP node can send the connection identifier of the first BGP connection corresponding to the locally established first BGP connection to the second BGP node, so as to be used for subsequent LLDP automatic discovery association, that is, when the parameter is negotiated by using the LLDP packet, the second BGP node can know the parameter of the first BGP connection negotiated.

[0201] For example, the message type in which the first BGP node sends the connection identifier of the first BGP connection can be a predefined message containing the connection identifier of the first BGP connection. Alternatively, the connection identifier of the first BGP connection does not need to be sent by using a separate message, but can be sent in the BGP Open message optional parameter field in the process of establishing the BGP connection in step 901.

[0202] 903. The first BGP node determines a first BGP connection parameter to be updated, and the first BGP connection parameter to be updated includes at least one of an AS number, a hold time, or a BGP identifier.

[0203] 904. In the case of maintaining the first BGP connection, the first BGP node sends an LLDP packet to the second BGP node, and the LLDP packet includes the first BGP connection parameter to be updated and the connection identifier of the first BGP connection.

[0204] In some embodiments, the LLDP packet includes at least one TLV, and the at least one TLV includes the first BGP connection parameter to be updated.

[0205] For example, one TVL in the LLDP packet can indicate the first BGP connection parameter to be updated, or multiple TLVs can respectively indicate one parameter in the first BGP connection parameter to be updated.

[0206] For example, the BGP dynamic update sub-TLVs field in the LLDP packet shown in FIG. 8 can include at least one TLV herein.

[0207] For example, if multiple TLV fields in the BGP dynamic update sub-TLVs field indicate the first BGP connection parameter to be updated, FIG. 10 shows a format diagram of the multiple TLV fields in the BGP dynamic update sub-TLVs field. The BGP dynamic update sub-TLVs field can include: a BGP peer key sub-TLV, a BGP local AS update sub-TLV, a BGP router-id sub-TLV, and a BGP hold time sub-TLV.

[0208] The BGP peer key sub-TLV field can indicate the connection identification of the first BGP connection. For example, as shown in (a) of FIG. 10, the BGP peer key sub-TLV field includes: a type (TBD), a length (4), a local AS, a local address, and a connection identification. The type field value TBD (to be define) can indicate that the TLV field has not yet applied for a valid type (all standard TLV fields need to apply to the IANA organization, and can be validly defined); the length field can indicate the length of the BGP peer key sub-TLV field, for example, 4 bytes; the local AS field can indicate the AS number before the update; the local address field can indicate the address of the first BGP node; and the session ID field can indicate the session number of the current BGP connection.

[0209] The BGP local AS update sub-TLV field can indicate the AS number carried by the first BGP connection parameter to be updated. For example, as shown in (b) of FIG. 10, the BGP local AS update sub-TLV field includes the following fields: type (TBD), length (4), and local AS. The length field can indicate the length of the BGP local AS update sub-TLV field, for example, 4 bytes; and the local AS field can indicate the AS number after the update. For example, the AS number of the first BGP node in the first BGP connection parameter indicates that the BGP neighbor is IBGP, and the AS number of the first BGP node in the first BGP connection parameter to be updated indicates that the BGP neighbor is EBGP.

[0210] The BGP router-id sub-TLV field can indicate the BGP identifier carried by the first BGP connection parameter to be updated. For example, as shown in (c) of FIG. 10, the BGP router-id sub-TLV field includes the following fields: type (TBD), length (4), and BGP identifier. The length field can indicate the length of the BGP router-id sub-TLV field, for example, 4 bytes; and the BGP identifier field can indicate the BGP identifier updated by the first BGP node, i.e., the router Id after the reconfiguration or update of the first BGP node.

[0211] The BGP hold time sub-TLV field can indicate the hold time carried by the first BGP connection parameter to be updated. For example, as shown in (d) of FIG. 10, the BGP hold time sub-TLV field includes the following fields: type (TBD), length (2), and BGP hold time. The length field can indicate the length of the BGP hold time sub-TLV field, for example, 2 bytes; and the BGP hold time field indicates the BGP hold time updated by the first BGP node.

[0212] 905、The second BGP node updates the first BGP connection parameter according to the first BGP connection parameter to be updated, and feeds back an acknowledgement message to the first BGP node, the acknowledgement message indicating that the second BGP node has received the LLDP message.

[0213] When the second BGP node receives the LLDP packet, the first BGP connection to be updated in the BGP connection parameters can be determined according to the connection identifier in the LLDP packet, and then the first BGP connection parameters are updated according to the first BGP connection parameters to be updated carried by the LLDP packet. The second BGP node feeds back an acknowledgement packet to the first BGP node.

[0214] In some embodiments, the format of the acknowledgement packet can be the same as that of the LLDP packet, that is, the acknowledgement packet can also be an LLDP packet, except that a marking field identifying the acknowledgement can be carried in the acknowledgement packet. Alternatively, the acknowledgement packet can be an ACK packet.

[0215] In some embodiments, if the second BGP node does not support the capability of not interrupting the BGP connection for BGP connection parameter negotiation, for example, the second BGP node does not recognize the LLDP packet, or the second BGP node supports the capability of not interrupting the BGP connection for BGP connection parameter negotiation, but the LLDP packet is parsed incorrectly, the second BGP node determines that the negotiation is unsuccessful, and the second BGP node can disconnect the first BGP connection with the first BGP node. In this way, the first BGP node can perform BGP connection parameter negotiation through the BGP Open message in the process of reestablishing the BGP connection with the second BGP node according to the original negotiation process.

[0216] 906、The first BGP node updates the first BGP connection parameters according to the first BGP connection parameters to be updated.

[0217] In other words, the first BGP node validates the first BGP connection parameters to be updated locally by the first BGP node.

[0218] When the first BGP node receives the acknowledgement packet, it can be considered that the second BGP node has received the LLDP packet, or the second BGP node has received the LLDP packet and completed the local BGP connection parameter negotiation, and the first BGP node can validate the first BGP connection parameters to be updated locally by the first BGP node.

[0219] In this way, in the case where the first BGP node and the second BGP node establish the first BGP connection, the parameters of the BGP connection can be adjusted through the LLDP packet without interrupting the first BGP connection. In the case of large-scale routing, the convergence time of the service can be reduced. In particular, when adjusting the parameters irrelevant to routing, such as the hold time, the behavior of a large number of route convergences caused by the interruption of the BGP connection can be avoided.

[0220] In some embodiments, the first message described above can be implemented in the following manner five. In manner five, the first message is an L3DL message. In other words, the first message is a newly added L3DL message or L3DL extended message, which can be used to support dynamic update of the BGP connection parameters of the first BGP connection.

[0221] In some scenarios, the BGP node can discover the neighbor and establish the BGP connection using the L3DL message of Type 9. In this application, in the case of a newly added L3DL message, the L3DL message can be referred to as a Type 10 message or other named message.

[0222] For example, as shown in FIG. 11, the format of an L3DL message of Type 10 is shown. The L3DL message includes fields such as Type (10), Payload Length, ULPC Type, Attrcount, Attribute List,..., Sig Type, Signature Len, and other signatures.

[0223] The Type = 10 field is used to indicate that the type of the L3DL message is 10; the Payload Length field indicates the content length of the LLDP message; the ULPC Type field indicates BGP and can take the value of 1; the Attrcount field indicates the number of sub-attribute TLVs carried by the L3DL message; the Attribute List field indicates the newly added TLV of the L3DL message; the Sig Type field and the Signature Len field are used to indicate the data signature; and the other Signature field indicates other fields.

[0224] Similar to the implementation of the LLDP message, if the L3DL message is used for negotiation, the first BGP node can also notify the second BGP node of the connection identifier to be negotiated before the first BGP node and the second BGP node perform parameter negotiation.

[0225] In some embodiments, the process of parameter negotiation between the first BGP node and the second BGP node using the L3DL message is similar to the process shown in FIG. 9 using the LLDP message. The difference is that the first BGP connection parameters to be updated can be carried in the Attribute List field of the L3DL message. In other words, the Attribute List field can carry one or more TLV fields indicating the first BGP connection parameters to be updated.

[0226] In this way, in the case that the first BGP node and the second BGP node establish the first BGP connection, the parameters of the BGP connection can be adjusted through the L3DL packet without interrupting the first BGP connection, and similar technical effects to the LLDP packet can be achieved.

[0227] Based on the above examples, the following gives a possible use case of a method for dynamically negotiating BGP connection parameters, which includes the following method flow.

[0228] 1) The first BGP node and the second BGP node establish the first BGP connection based on the first BGP connection parameters.

[0229] For example, the first BGP connection parameters stored in the first BGP node include the BGP connection parameters of the first BGP node for the first BGP connection, and the BGP connection parameters of the second BGP node for the first BGP connection.

[0230] The BGP connection parameters of the first BGP node for the first BGP connection stored in the first BGP node can be preconfigured. The BGP connection parameters of the second BGP node for the first BGP connection stored in the first BGP node can be received through the BGP Open message sent by the second BGP node.

[0231] For example, the BGP connection parameters of the first BGP node for the first BGP connection stored in the first BGP node include the first AS number of the first BGP node, the first hold time of the first BGP node, and the first router-id of the first BGP node. Optionally, it can also include the first capability information of the first BGP node. For example, the first AS number is a 2-byte AS number, and is 1; the first hold time is 30 seconds (s); and the first BGP identifier is the router-id of the first BGP node (usually occupying 32 bits).

[0232] The BGP connection parameters of the second BGP node for the first BGP connection stored in the first BGP node include the second AS number of the second BGP node, the second hold time of the second BGP node, and the router-id of the second BGP node. Optionally, it can also include the second capability information of the second BGP node. For example, the second AS number is a 4-byte AS number, usually shown in a dotted form of x.y, the second hold time is 50 seconds (s); and the second BGP identifier is the router-id of the second BGP node (usually occupying 32 bits).

[0233] Optionally, the first BGP connection parameters of the first BGP node for the first BGP connection maintained by the first BGP node can further comprise capability information of the first BGP node. The first BGP connection parameters of the second BGP node for the first BGP connection maintained by the first BGP node can further comprise capability information of the second BGP node. The capability information can comprise, for example, multiprotocol extensions capability, route refresh capability, or support for 4-octet AS number capability.

[0234] Similarly, the first BGP connection parameters are also maintained in the second BGP node. The first BGP connection parameters of the second BGP node for the first BGP connection maintained by the second BGP node can be preconfigured. The first BGP connection parameters of the first BGP node for the first BGP connection maintained by the second BGP node can be received by the second BGP node through the BGP Open message sent by the first BGP node.

[0235] 2) As the traffic between the first BGP node and the second BGP node for the first BGP connection increases, the first BGP node determines that the first BGP connection parameters need to be updated, and at this time, the first BGP node determines the first BGP connection parameters to be updated.

[0236] For example, the first BGP connection parameters to be updated can be understood as the BGP connection parameters of the first BGP node for the first BGP connection that are updated. For example, in the case that the traffic between the first BGP node and the second BGP node for the first BGP connection increases, the first hold time in the first BGP connection parameters of the first BGP node for the first BGP connection maintained in the first BGP node is reconfigured to a third hold time, the third hold time is 40s, and the first AS number and the first router-id remain unchanged.

[0237] For example, in the case of full update, if the BGP connection parameters reconfigured by the first BGP node for the first BGP connection comprise the first AS number, the second hold time, the router-id, and the capability information. That is, the changed connection parameters are the hold time. For example, the second BGP node determines that the second hold time needs to be updated to 40s, and the AS number, the router-id, and the capability information remain unchanged.

[0238] 3) In the case of maintaining the first BGP connection, or in the case of the state machine of the first BGP node being in the established state, the first BGP node sends a first message to the second BGP node, the first message including the first BGP connection parameters to be updated. For example, in the case of full update, the first BGP connection parameters to be updated include the first AS number, the third hold time, and the first router-id.

[0239] For example, the implementation of the first message can refer to the implementation of the above-mentioned methods 30-50 or method 70 or method 90.

[0240] 4) In the case of receiving the first message, the second BGP node updates the first BGP connection parameters according to the first BGP connection parameters to be updated.

[0241] That is, in the case of the state machine of the second BGP node being in the established state, the second BGP node updates the first hold time in the BGP connection parameters of the first BGP node for the first BGP connection saved by the second BGP node from 30s to 40s, and keeps other parameters in the BGP connection parameters of the first BGP node for the first BGP connection saved by the second BGP node unchanged, that is, the first AS number and the first BGP identifier remain unchanged.

[0242] For example, as described above, when the second BGP node receives the first message, if the second BGP node does not support the capability of not interrupting the first BGP connection for BGP connection parameter negotiation, or the second BGP node parses the first message incorrectly, the second BGP node determines that the negotiation is unsuccessful, and can disconnect the first BGP connection with the first BGP node. In this case, the first BGP node and the second BGP node can perform BGP connection parameter negotiation according to the original process of rebuilding BGP connection.

[0243] If the second BGP node supports the capability of not interrupting the BGP connection for BGP connection parameter negotiation and correctly parses the first message, the second BGP node updates the parameters of the first BGP connection according to the first BGP connection parameters to be updated locally, and continues to perform step 5).

[0244] 5) the second BGP node feeds back a second message to the first BGP node, the second message can be an ACK for example, indicating that the second BGP node has received the first message, or has received the first message and has completed the update of the first BGP connection parameter to be updated. As described in the above embodiments, the step 5) is optional, if the first message is a BGP Open message, the second BGP node can not feed back an ACK or other type of message to the first BGP node.

[0245] 6) the first BGP node updates the first BGP connection parameter according to the first BGP connection parameter to be updated.

[0246] It can also be understood that the first BGP node locally takes effect the third hold time in the first BGP connection parameter to be updated, and other parameters in the first BGP connection parameter except the third hold time remain unchanged.

[0247] Therefore, in the present application, in the case that the first BGP node establishes the first BGP connection with the second BGP node, the present application can adjust the first BGP connection parameter without interrupting the first BGP connection, and can avoid the route convergence caused by the interruption of the BGP connection in the case of large-scale routing.

[0248] It can be understood that, in order to implement the functions in the above embodiments, the base station and the terminal include corresponding hardware structures and / or software modules for performing various functions. Those skilled in the art should easily realize that, in combination with the units and method steps of the examples described in the embodiments disclosed in the present application, the present application can be realized in the form of hardware or a combination of hardware and computer software. Whether a certain function is implemented in hardware or computer software driven hardware depends on the specific application scenario and design constraints of the technical solution.

[0249] FIG. 12 and FIG. 13 are structural schematic diagrams of possible communication apparatuses provided by the embodiments of the present application. These communication apparatuses can be used to implement the functions of the BGP nodes in the above method embodiments, and thus can also achieve the beneficial effects possessed by the above method embodiments. In the embodiments of the present application, the communication apparatus can be one of the BGP nodes A-F as shown in FIG. 1, and can also be a module (such as a chip) applied to the BGP node.

[0250] As shown in FIG. 12, the communication apparatus 120 includes a processing unit 1210 and a transceiver unit 1220. The communication apparatus 120 is used to implement the functions of at least one of the first communication apparatus, the second communication apparatus, the first BGP node or the second BGP node in one or more of the above method embodiments 30 of FIG. 3, 40 of FIG. 4, 50 of FIG. 5, 70 of FIG. 7 or 90 of FIG. 9.

[0251] When the communication device 120 is configured to implement the functions of the first communication device and / or the first BGP node in the method embodiments shown in FIG. 3-5 or FIG. 7 or FIG. 9, the transceiver unit 1220 is configured to implement the method of sending the first message, the first BGP message, the first BGP open message, the LLDP message or the L3DL message while maintaining the BGP connection; the method of receiving the second BGP message, the third BGP open message, the second BGP open message or the reply message. The processing unit 1210 can be configured to implement the method of establishing the BGP connection with the second communication device or the first BGP node; the method of determining the first BGP connection parameter to be updated; the method of validating the first BGP connection parameter.

[0252] When the communication device 120 is configured to implement the functions of the second communication device and / or the second BGP node in the method embodiments shown in FIG. 3-5 or FIG. 7 or FIG. 9, the transceiver unit 1220 is configured to implement the method of receiving the first message, the first BGP message, the first BGP open message, the LLDP message or the L3DL message while maintaining the BGP connection; the method of sending the second BGP message, the third BGP open message, the second BGP open message or the reply message. The processing unit 1210 can be configured to implement the method of establishing the BGP connection with the second communication device and / or the first BGP node; the method of negotiating the first BGP connection parameter.

[0253] For more detailed description of the processing unit 1210 and the transceiver unit 1220, please refer to the relevant description in the method embodiments shown in FIG. 3-5 or FIG. 7 or FIG. 9.

[0254] As shown in FIG. 13, the communication device or the BGP node in the embodiments of the present application can be a router or a switch. The specific hardware structure can have two ways:

[0255] In one way, as shown in (a) of FIG. 13, the communication device or the BGP node 130a includes a master board and an interface board, the master board includes at least one processor and a memory, and the interface board includes a processor, a memory and an interface card. The processor of the interface board is configured to invoke the program instructions in the memory of the interface board to perform the reception and transmission of the message. The processor of the master board is configured to invoke the program instructions in the memory of the master board to perform the corresponding processing functions, for example, to execute the flow of one or more of the methods 30-50, the method 70 or the method 90 in the embodiments of the present application.

[0256] In another implementation, as shown in (b) of FIG. 13, the communication device or BGP node 130b includes a transceiver, a processor and a memory. The transceiver is configured to receive a packet or data information, etc., the memory is configured to store program instructions, and the processor is configured to perform the relevant steps of processing in the communication device or BGP node in one or more of the methods 30-50, the method 70 or the method 90.

[0257] When the communication device 120 is configured to implement the method shown in FIG. 3-5 or FIG. 7 or FIG. 9, the processor is configured to implement the functions of the processing unit 1210, and the interface card is configured to implement the functions of the transceiver unit 1220.

[0258] In this application, the sending of information from entity A to entity B can be direct sending from A to B, or indirect sending from A to B through other entities. Similarly, the receiving of information from entity A by entity B can be direct receiving of the information sent by entity A, or indirect receiving of the information sent by entity A through other entities. The entities A and B can be RAN nodes or terminals, or modules inside RAN nodes or terminals. The sending and receiving of information can be the information interaction between RAN nodes and terminals, such as the information interaction between base stations and terminals; the sending and receiving of information can also be the information interaction between two RAN nodes, such as the information interaction between CUs and DUs; the sending and receiving of information can also be the information interaction between different modules inside one device, such as the information interaction between a terminal chip and other modules of the terminal, or the information interaction between a base station chip and other modules of the base station.

[0259] It can be understood that the processor in the embodiments of the present application can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor can be a microprocessor, or any conventional processor.

[0260] The method steps in the embodiments of the present application can be implemented in hardware or in software instructions executable by a processor. The software instructions can be composed of corresponding software modules, which can be stored in a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and write information to the storage medium. The storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in a base station or a terminal. The processor and the storage medium can also exist as discrete components in the base station or the terminal.

[0261] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer programs or instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments are performed. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable apparatus. The computer programs or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium, for example, the computer programs or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center through a wired or wireless manner. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, a magnetic tape; an optical medium, such as a digital video disc; or a semiconductor medium, such as a solid-state disk. The computer-readable storage medium can be a volatile or non-volatile storage medium, or can include both volatile and non-volatile storage media.

[0262] In various embodiments of the present application, the terms and / or descriptions of different embodiments are consistent and can be referred to each other if there is no special description and logical conflict. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0263] In the present application, "at least one" means one or more, "multiple" means two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three kinds of relationships, for example, A and / or B can represent: A exists alone, A and B exist together, B exists alone, where A, B can be singular or plural. In the text description of the present application, the character " / ", generally indicates that the front and rear associated objects are in an "or" relationship. "Including at least one of A, B and C" can mean: including A; including B; including C; including A and B; including A and C; including B and C; including A, B and C.

[0264] It can be understood that various numerical numbers involved in the embodiments of the present application are only distinguished for the convenience of description, and are not used to limit the scope of the embodiments of the present application. The size of the serial number of the above processes does not mean the order of execution, and the execution order of the processes should be determined according to its function and inherent logic.

Claims

1. A method for dynamically negotiating Border Gateway Protocol (BGP) connection parameters, characterized in that, The method comprises: The second communication device and the first communication device establish a first BGP connection based on first BGP connection parameters; The second communication device receives a first message sent by the first communication device while maintaining the first BGP connection, the first message comprising first BGP connection parameters to be updated, the first BGP connection parameters to be updated comprising at least one of an autonomous system (AS) number, a hold time or a BGP identifier; The second communication device updates the first BGP connection parameters based on the first BGP connection parameters to be updated.

2. The method of claim 1, wherein: The first message is a border gateway protocol (BGP) message.

3. The method of claim 2, wherein: The first message is a newly defined BGP message.

4. The method of claim 2, wherein: The first message is a first BGP open message.

5. The method of claim 4, wherein: The first BGP open message comprises indication information indicating that the first BGP open message carries the first BGP connection parameters to be updated.

6. The method of claim 4 or 5, wherein: An optional parameter of the first BGP open message comprises a type-length-value (TLV) field carrying the first BGP connection parameters to be updated.

7. The method of claim 4, wherein, The method further comprises: The second communication device and a third communication device establish a second BGP connection based on second BGP connection parameters; The second communication device sends a second BGP open message to the third communication device while maintaining the second BGP connection, the second BGP open message comprising second BGP connection parameters to be updated, the second BGP connection parameters to be updated comprising at least one of an autonomous system (AS) number, a hold time or a BGP identifier; The second communication device updates the second BGP connection parameters based on the second BGP connection parameters to be updated.

8. The method of claim 1, wherein: The first message is a link layer discovery protocol (LLDP) message or a layer 3 (L3) discovery and alive (DL) message; The first message comprises at least one TLV, and the at least one TLV comprises the first BGP connection parameters to be updated.

9. A method of dynamically negotiating Border Gateway Protocol (BGP) connection parameters, the method comprising: The method comprises: A first communication device and a second communication device establish a first BGP connection based on first BGP connection parameters; The first communication device sends a first message to the second communication device while maintaining the first BGP connection, the first message comprising first BGP connection parameters to be updated, the first BGP connection parameters to be updated comprising at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; The first BGP connection parameters are updated according to the first BGP connection parameters to be updated.

10. The method of claim 9, wherein The first message is a border gateway protocol (BGP) message.

11. The method of claim 10, wherein The first message is a newly defined BGP message.

12. The method of claim 10, wherein The first message is a first BGP open message.

13. The method of claim 12, wherein The first BGP open message comprises indication information indicating that the first BGP open message carries the first BGP connection parameters to be updated.

14. The method of claim 12 or 13, wherein An optional parameter of the first BGP open message comprises a type-length-value (TLV) field carrying the first BGP connection parameters to be updated.

15. The method of claim 9, wherein, The method further comprises: The first communication device establishes a second BGP connection with a third communication device based on second BGP connection parameters; The first communication device receives a second BGP open message sent by the third communication device while maintaining the second BGP connection, the second BGP open message comprising second BGP connection parameters to be updated, the second BGP connection parameters to be updated comprising at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; The first communication device updates the second BGP connection parameters according to the second BGP connection parameters to be updated.

16. The method of claim 9, wherein The first message is a link layer discovery protocol (LLDP) message or a layer 3 discovery and livelihood (L3DL) message; The first message comprises at least one TLV, the at least one TLV comprising the first BGP connection parameters to be updated.

17. A second communications device, characterized by Comprise: A processing unit configured to establish a first BGP connection with a first communication device based on first BGP connection parameters; A transceiver configured to receive a first message from the first communication device while maintaining the first BGP connection, the first message comprising first BGP connection parameters to be updated, the first BGP connection parameters to be updated comprising at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; The processing unit is further configured to update the first BGP connection parameter based on the first BGP connection parameter to be updated.

18. The apparatus of claim 17, wherein, The first message is a border gateway protocol message (BGP message).

19. The apparatus of claim 18, wherein, The first message is a newly defined border gateway protocol message (BGP message).

20. The apparatus of claim 18, wherein, The first message is a first border gateway protocol open message (BGP Open message).

21. The apparatus of claim 20, wherein, The first BGP Open message includes indication information indicating that the first BGP Open message carries the first BGP connection parameter to be updated.

22. The apparatus of claim 20 or 21, wherein, An optional parameter of the first BGP Open message includes a type-length-value (TLV) field, and the TLV field carries the first BGP connection parameter to be updated.

23. The apparatus of claim 20, wherein, The method further includes: The processing unit is further configured to establish a second BGP connection with a third communication apparatus based on a second BGP connection parameter; The transceiver is further configured to send a second BGP Open message to the third communication apparatus while maintaining the second BGP connection, the second BGP Open message including a second BGP connection parameter to be updated, the second BGP connection parameter to be updated including at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; The processing unit is further configured to update the second BGP connection parameter based on the second BGP connection parameter to be updated.

24. The apparatus of claim 17, wherein, The first message is a link layer discovery protocol (LLDP) message or a layer 3 discovery and alive (L3DL) message; The first message includes at least one TLV, and the at least one TLV includes the first BGP connection parameter to be updated.

25. A first communications device, characterized by: includes: A processing unit configured to establish a first BGP connection with a second communication apparatus based on a first BGP connection parameter; A transceiver configured to send a first message to the second communication apparatus while maintaining the first BGP connection, the first message including a first BGP connection parameter to be updated, the first BGP connection parameter to be updated including at least one of an autonomous system (AS) number, a hold time, or a BGP identifier; The processing unit is further configured to update the first BGP connection parameter based on the first BGP connection parameter to be updated.

26. The apparatus of claim 25, wherein, The first message is a border gateway protocol message (BGP message).

27. The apparatus of claim 26, wherein, The first message is a newly defined border gateway protocol message.

28. The apparatus of claim 26, wherein, The first message is a first border gateway protocol open message.

29. The apparatus of claim 28, wherein, The first border gateway protocol open message comprises indication information indicating that the first border gateway protocol open message carries the first border gateway protocol connection parameter to be updated.

30. The apparatus of claim 28 or 29, wherein, An optional parameter of the first border gateway protocol open message comprises a type-length-value field, and the type-length-value field carries the first border gateway protocol connection parameter to be updated.

31. The apparatus of claim 25, wherein, The method further comprises: The processing unit is further configured to establish a second border gateway protocol connection with a third communication apparatus based on second border gateway protocol connection parameters; The transceiver is further configured to receive a second border gateway protocol open message sent by the third communication apparatus while maintaining the second border gateway protocol connection, the second border gateway protocol open message comprising second border gateway protocol connection parameters to be updated, and the second border gateway protocol connection parameters to be updated comprising at least one of an autonomous system number, a hold time, or a border gateway protocol identifier; The processing unit is further configured to update the second border gateway protocol connection parameters according to the second border gateway protocol connection parameters to be updated.

32. The apparatus of claim 25, wherein, The first message is a link layer discovery protocol message or a layer 3 discovery and livelihood message. The first message comprises at least one type-length-value field, and the at least one type-length-value field comprises the first border gateway protocol connection parameter to be updated.

33. A communications device, characterized by The communication apparatus comprises at least one processor and a memory, the at least one processor being configured to read and execute a program stored in the memory, so that the communication apparatus performs the method of any one of claims 1-16.

34. A communication system, characterized by The communication apparatus comprises a first communication apparatus and a second communication apparatus, the first communication apparatus being configured to perform the method of any one of claims 9-16, and the second communication apparatus being configured to perform the method of any one of claims 1-8.

35. A computer program product, characterised in that, The computer program, when executed on a communication apparatus, causes the communication apparatus to perform the method of any one of claims 1-16.

36. A computer storage medium, comprising, The computer program, when executed on a communication apparatus, causes the communication apparatus to perform the method of any one of claims 1-16.

Images