Communication method and apparatus

Abstract

The application provides a communication method and device, the method comprising: sending a first ORF capability negotiation message to a second network device, the first ORF capability negotiation message comprising at least one first indication information, each first indication information being used for indicating a supported prefix policy type; receiving a second ORF capability negotiation message sent by the second network device, the second ORF capability negotiation message comprising at least one second indication information, each second indication information being used for indicating a supported prefix policy type under each type of address family supported by the second network device; according to each first indication information and each second indication information, negotiating and determining a commonly supported prefix policy type with the second network device; and sending a first ORF prefix policy message to the second network device, the first ORF prefix policy message comprising a prefix policy corresponding to the commonly supported prefix policy type.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0002] RFC 5291 and RFC 5292 specify the prefix-based outbound route filtering (ORF) feature of the Border Gateway Protocol (BGP). This feature allows the local network device to send its prefix-based inbound policy to its BGP neighbor via a route refresh message. The BGP neighbor then constructs its own outbound policy based on the received prefix-based inbound policy and its local routing policy, filtering routes during transmission. This avoids the local network device receiving a large number of useless routes, reduces its CPU utilization, and effectively reduces the configuration work for BGP neighbors, thus lowering link bandwidth usage.

[0003] When a local network device wants its BGP neighbor to send only the routes required by the local network device, and the BGP neighbor is unwilling to maintain different egress policies for different network devices, both ends can run the BGP ORF feature.

[0004] like Figure 1 As shown, Figure 1 This diagram illustrates the BGP ORF features used in existing network devices. Figure 1 In this scenario, Router A and Router B are directly connected BGP neighbors. After negotiating prefix-based ORF capabilities, Router A includes its locally configured prefix-based ingress policy in a route refresh message and sends it to Router B. Router B constructs its egress policy based on the prefix-based ingress policy included in the route refresh message and its local routing policy. According to the egress policy, when Router B sends routes to Router A, Router A only receives the routes it needs, while Router B does not need to maintain its own routing policy, reducing configuration work.

[0005] Because no address family neighbor could simultaneously support multiple prefix types (e.g., both IPv4 and IPv6 prefix policies) when BGP ORF features were defined, the RFC uses a (length, prefix) approach to uniformly represent IPv4 or IPv6 prefixes in order to save memory. When resolving address prefixes, network devices determine whether to resolve using the IPv4 or IPv6 prefix based on the address family (AFI: Address Family Identifier; or SAFI: Subsequent Address Family Identifier) ​​specified in the packet.

[0006] Type 5 routes in the EVPN (Ethernet VPN) address family can be used to carry both IPv4 and IPv6 prefix addresses. If the current EVPN address family intends to send its local prefix policy to the peer via BGP ORF, the local network device can only carry one type of prefix policy: either the local IPv4 prefix policy or the local IPv6 prefix policy. Interoperability is achieved when both network segments support the same default EVPN prefix type.

[0007] If the current EVPN address family sends both the local IPv4 prefix policy and IPv6 prefix policy to the peer network device simultaneously via the BGP ORF feature, the peer network device cannot confirm that the received prefix policy is both an IPv4 prefix policy and an IPv6 prefix policy, and therefore cannot achieve interoperability. Summary of the Invention

[0008] In view of this, this application provides a communication method and apparatus to solve the problem that the existing BGP ORF features cannot support multiple types of routing prefixes at the same time, resulting in the inability of multiple network devices to communicate with each other.

[0009] In a first aspect, this application provides a communication method applied to a first network device, the first network device supporting multiple address families, each address family supporting multiple prefix policy types, the method comprising:

[0010] Send a first ORF capability negotiation message to the second network device. The first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported under each type of address family supported by the first network device.

[0011] The second network device receives a second ORF capability negotiation message, which includes at least one second indication information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device.

[0012] Based on each first indication information and each second indication information, negotiate with the second network device to determine the prefix policy type commonly supported by each type of address family;

[0013] Send a first ORF prefix policy message to the second network device. The first ORF prefix policy message includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0014] Secondly, this application provides a communication apparatus applied to a first network device, the first network device supporting multiple address families, each address family supporting multiple prefix policy types, the method comprising:

[0015] The sending unit is configured to send a first ORF capability negotiation message to the second network device. The first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported under each type of address family supported by the first network device.

[0016] The receiving unit is configured to receive a second ORF capability negotiation message sent by the second network device. The second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device.

[0017] The negotiation unit is configured to negotiate with the second network device and determine the prefix policy type commonly supported by each type of address family based on each first indication information and each second indication information.

[0018] The sending unit is further configured to send a first ORF prefix policy message to the second network device, wherein the first ORF prefix policy message includes a prefix policy corresponding to a prefix policy type commonly supported by each type of address family.

[0019] Thirdly, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the first aspect of this application.

[0020] Therefore, by applying the communication method and apparatus provided in this application, a first network device sends a first ORF capability negotiation message to a second network device. This first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information indicates a prefix policy type supported under each type of address family supported by the first network device. The first network device receives a second ORF capability negotiation message sent by the second network device. This second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information indicates a prefix policy type supported under each type of address family supported by the second network device. Based on each first indication information and each second indication information, the first network device and the second network device negotiate and determine each prefix policy type commonly supported by each type of address family. The first network device sends a first ORF prefix policy message to the second network device. This first ORF prefix policy message includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0021] In this way, by leveraging ORF capability negotiation messages, both ends of the network device negotiate the supported prefix policy types. Once the negotiation is successful, the local device sends the prefix policy corresponding to the commonly supported prefix policy type to the peer network device via ORF prefix policy messages. This solves the problem that existing BGP ORF features cannot simultaneously support multiple types of routing prefixes, causing the peer network device to be unable to confirm whether the received prefix policy is an IPv4 prefix policy or an IPv6 prefix policy, thus hindering interoperability. Simultaneously, it also eliminates the need for the peer network device to send all routes that the local device does not need, reducing network bandwidth consumption and the processing overhead of unnecessary routes for the local network device. Attached Figure Description

[0022] Figure 1 A schematic diagram illustrating the BGP ORF features between existing network devices;

[0023] Figure 2 A flowchart illustrating a communication method provided in an embodiment of this application;

[0024] Figure 3 A schematic diagram of the negotiation portion of the ORF capability negotiation message provided in the embodiments of this application;

[0025] Figure 4 A schematic diagram of the prefix policy portion of the ORF prefix policy message provided in this application embodiment;

[0026] Figure 5 This is a schematic diagram of the ORF entity field format provided in the embodiments of this application;

[0027] Figure 6 This is a schematic diagram of the format of the type characteristic field provided in the embodiments of this application;

[0028] Figure 7 A structural diagram of a communication device provided in an embodiment of this application;

[0029] Figure 8 The network device hardware structure provided in the embodiments of this application. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0031] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0032] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0033] The following is a detailed description of a communication method provided by an embodiment of this application. See also... Figure 2 , Figure 2 This is a flowchart illustrating a communication method provided in an embodiment of this application. The method is applied to a first network device. The communication method provided in this application embodiment may include the following steps.

[0034] Step 210: Send a first ORF capability negotiation message to the second network device. The first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported under each type of address family supported by the first network device.

[0035] Specifically, if the first network device and the second network device are within an EVPN network, and before the two devices mutually advertise EVPN Category 5 routes, the first network device will run the BGP ORF feature if it wants the second network device to send only the routes it needs. Similarly, the second network device can also run the BGP ORF feature.

[0036] The first network device and the second network device perform ORF negotiation to determine whether the second network device supports the same prefix policy type as itself under a certain type of address family, whether each prefix policy type supports ORF capability, and the transmit and receive capabilities of each prefix policy type. The first network device generates a first ORF capability negotiation message, which includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported by the first network device under each type of address family supported by the first network device.

[0037] It should be noted that in the embodiments of this application, each network device can simultaneously support multiple address families, including but not limited to the EVPN address family (which will be used as an example in the following description), address families that simultaneously support IPv4 prefix policies and IPv6 prefix policies, etc. Each address family can support multiple prefix policy types, including but not limited to IPv4 prefix policy types and IPv6 prefix policy types.

[0038] During the generation of the first ORF capability negotiation message, the first network device generates a negotiation section corresponding to each prefix policy type supported under each address family type. This negotiation section includes various information related to that prefix policy type. Thus, upon receiving the second ORF capability negotiation message, the second network device can determine that the first network device simultaneously supports multiple address families, supports multiple prefix policy types under each address family type, and whether each prefix policy type supports ORF capabilities. Under the same address family, the second network device matches the first with the prefix policy types it supports.

[0039] Optionally, the first ORF capability negotiation message includes multiple negotiation parts, each negotiation part as follows: Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the negotiation portion of the ORF capability negotiation message provided in this embodiment of the application. Figure 3The negotiation section includes a 2-byte Address Family Identifier field, a 1-byte Reserved field, a 1-byte Subsequent Address Family Identifier field, a 1-byte Number of ORFs field, a 1-byte ORF Type field, and a 1-byte Send / Receive field.

[0040] The address family and sub-address family fields should be filled in according to the existing EVPN NLRI specifications. The ORF quantity and ORF type fields should be filled in according to the existing BGP ORF specifications. A value of 64 for the ORF type field indicates support for the ORF prefix strategy.

[0041] The reserved field is used to carry first indication information about a prefix policy type supported by the first network device. The transmit / receive capability field is used to carry the transmit / receive capabilities supported by a prefix policy type, specifically the receive capability or the transmit capability.

[0042] Of course, in practical applications, the ORF capability negotiation message also includes other defined fields, which are described in... Figure 3 And those not mentioned in the embodiments can be referred to the existing BGP ORF protocol configuration, which will not be repeated here.

[0043] In this embodiment, the first network device supports the EVPN address family and simultaneously supports both IPv4 and IPv6 prefix policy types under the EVPN address family. The first network device generates two negotiation parts. For example, one negotiation part corresponds to the IPv4 prefix policy type, and the other negotiation part corresponds to the IPv6 prefix policy type. The first ORF capability negotiation message includes two negotiation parts.

[0044] The first network device distinguishes itself by using different bits in the reserved field to indicate that it supports two prefix policy types simultaneously. For example, it can use the low bits of the reserved field to indicate support for the IPv4 prefix policy type and the high bits to indicate support for the IPv6 prefix policy type; or, it can configure the value of the reserved field to 0 to indicate support for the IPv4 prefix policy type and configure the value of the reserved field to 1 to indicate support for the IPv6 prefix policy type.

[0045] The first network device sends a first ORF capability negotiation message to the second network device, so that after receiving the first ORF capability negotiation message, the second network device negotiates the ORF prefix policy with the first network device.

[0046] Through the first ORF capability negotiation message, the second network device determines and records the EVPN address families supported by the first network device. Under the EVPN address family, the first network device simultaneously supports both IPv4 and IPv6 prefix policy types, and both of these prefix policy types support ORF capabilities. Under the EVPN address family, the second network device can match the various prefix policy types supported by the first network device with the various prefix policy types it supports to determine whether both network devices support the same prefix policy type.

[0047] In this embodiment, under the EVPN address family, the second network device also supports both IPv4 and IPv6 prefix policy types, and each prefix policy type also supports ORF capability. Thus, both network devices support the same multiple prefix policy types, and each prefix policy type supports ORF capability.

[0048] Understandably, the second network device also generates a second ORF capability negotiation message, which includes at least one second piece of information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device.

[0049] The second network device sends a second ORF capability negotiation message to the first network device. The format of the second ORF capability negotiation message is the same as that of the first ORF capability negotiation message, and will not be repeated here.

[0050] It should be noted that if a network device supports a prefix policy type under a certain type of address family, the generated ORF capability negotiation message will include a negotiation part, which corresponds to a supported prefix policy type.

[0051] Step 220: Receive a second ORF capability negotiation message sent by the second network device. The second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device.

[0052] Specifically, as described in step 210, the second network device generates and sends a second ORF capability negotiation message to the first network device. After receiving the second ORF capability negotiation message, the first network device obtains multiple negotiation parts from it.

[0053] Step 230: Based on each first indication information and each second indication information, negotiate with the second network device and determine the prefix policy type commonly supported by each type of address family;

[0054] Specifically, according to the descriptions of steps 210 and 220, after the first network device and the second network device send ORF capability negotiation messages to each other, the first network device determines, based on the multiple negotiation parts included in the second ORF capability negotiation message, the prefix policy types that the second network device and itself jointly support under the same address family, whether the jointly supported prefix policy types support ORF capabilities, and the send / receive capabilities of the jointly supported prefix policy types.

[0055] Optionally, if each first indication information matches each second indication information, then the first network device determines that it and the second network device mutually support all prefix policy types belonging to the same type of address family;

[0056] If a portion of the first indication information in each first indication information matches a portion of the second indication information in each second indication information, then the first network device determines that it and the second network device mutually support a partial prefix policy type belonging to the same address family.

[0057] In this embodiment of the application, under the EVPN address family, the first network device and the second network device jointly support the IPv4 prefix policy type and the IPv6 prefix policy type.

[0058] Optionally, based on the value of the ORF type field included in each negotiation section, the first network device determines whether the prefix policy type commonly supported by each type of address family supports ORF capability.

[0059] Optionally, based on the values ​​of the transmit / receive capability fields included in each negotiation section, the first network device determines the transmit / receive capabilities supported by each commonly supported prefix policy type.

[0060] Step 240: Send a first ORF prefix policy message to the second network device. The first ORF prefix policy message includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0061] Specifically, according to the description of step 230, after the first network device and the second network device successfully negotiate, they establish a neighbor relationship. The first network device generates a first ORF prefix policy message, which includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0062] Optionally, in the embodiments of this application, the prefix policy corresponding to the prefix policy type specifically includes IPv4 prefix policy and IPv6 prefix policy.

[0063] Optionally, the first ORF prefix policy message includes multiple prefix policy parts, each prefix policy part as follows: Figure 4 As shown, Figure 4 This is a schematic diagram of the prefix policy portion of the ORF prefix policy message provided in the embodiments of this application. Figure 4 In the prefix strategy section, there are 2-byte Address Family Identifier fields, 1-byte Reserved fields, 1-byte Subsequent Address Family Identifier fields, 1-byte When-to-refresh fields, 1-byte ORF Type fields, 2-byte Length of ORF entries fields, and variable ORF entry fields.

[0064] The address family and sub-address family fields should be filled in according to the existing EVPN NLRI specifications. The update time, ORF type, and ORF entity length fields should be filled in according to the existing BGP ORF specifications. A value of 64 in the ORF type field indicates that the network device supports ORF prefix policies. The ORF entity field is used to carry the prefix policy corresponding to a prefix policy type supported by the first network device.

[0065] The reserved field is used to carry first indication information about a prefix policy type supported by the first network device under a certain address family. Thus, the first indication information carried by the reserved field can determine whether the prefix policy carried by the ORF entity field is an IPv4 prefix policy or an IPv6 prefix policy.

[0066] Of course, in practical applications, the ORF prefix policy message also includes other defined fields, which are described in... Figure 4 And those not mentioned in the embodiments can be referred to the existing BGP ORF protocol configuration, which will not be repeated here.

[0067] Optionally, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the ORF entity field format provided in an embodiment of this application. Figure 5 In ORF, the entity fields include a 2-bit Action field, a 1-bit Match field, a 5-bit Reserved field, and a variable Type-specific part field.

[0068] The type characteristic field is used to carry the prefix policy corresponding to a prefix policy type supported by the first network device; the action field indicates the action of adding, deleting, or deleting all prefix policies performed by the first network device; the value of the match field is either permit or deny.

[0069] Optionally, such as Figure 6 As shown, Figure 6 This is a schematic diagram illustrating the format of the type characteristic field provided in an embodiment of this application. Figure 6 In the data, the type-specific fields include a 4-bit Sequence field, a 1-bit Minlen field, a 1-bit Maxlen field, a 1-bit Length field, and a variable length Prefix field.

[0070] Among them, the minimum length field, maximum length field, length field, and prefix field are used to identify a prefix; the minimum length field, maximum length field, and length field are used to identify a mask.

[0071] Understandably, after successfully negotiating with the first network device, the second network device also establishes a neighbor relationship with the first network device. The second network device generates a second ORF prefix policy message, which includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0072] The second network device sends a second ORF prefix policy message to the first network device.

[0073] It should be noted that the explanation is based on the first network device. If the first network device determines that the second network device only supports a portion of the same prefix policy types within the same address family, then the first ORF prefix policy message generated by the first network device includes the prefix policy corresponding to that portion of the same prefix policy types.

[0074] For example, if the first network device supports both IPv4 and IPv6 prefix policy types, and during the negotiation process with the second network device, it is determined that the second network device supports the IPv4 prefix policy type, then the first ORF prefix policy message generated by the first network device includes the IPv4 prefix policy.

[0075] Therefore, by applying the communication method provided in this application, a first network device sends a first ORF capability negotiation message to a second network device. This first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information indicates a prefix policy type supported under each type of address family supported by the first network device. The first network device receives a second ORF capability negotiation message sent by the second network device. This second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information indicates a prefix policy type supported under each type of address family supported by the second network device. Based on each first indication information and each second indication information, the first network device and the second network device negotiate and determine each prefix policy type commonly supported by each type of address family. The first network device sends a first ORF prefix policy message to the second network device. This first ORF prefix policy message includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0076] In this way, by leveraging ORF capability negotiation messages, both ends of the network device negotiate the supported prefix policy types. Once the negotiation is successful, the local device sends the prefix policy corresponding to the commonly supported prefix policy type to the peer network device via ORF prefix policy messages. This solves the problem that existing BGP ORF features cannot simultaneously support multiple types of routing prefixes, causing the peer network device to be unable to confirm whether the received prefix policy is an IPv4 prefix policy or an IPv6 prefix policy, thus hindering interoperability. Simultaneously, it also eliminates the need for the peer network device to send all routes that the local device does not need, reducing network bandwidth consumption and the processing overhead of unnecessary routes for the local network device.

[0077] Based on the same inventive concept, embodiments of this application also provide a communication device corresponding to the communication method. See also Figure 7 , Figure 7 A communication device provided in this application embodiment is applied to a first network device that supports multiple address families. The method includes:

[0078] The sending unit 710 is configured to send a first ORF capability negotiation message to the second network device. The first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported under each type of address family supported by the first network device.

[0079] The receiving unit 720 is configured to receive a second ORF capability negotiation message sent by the second network device. The second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device.

[0080] The negotiation unit 730 is configured to negotiate with the second network device and determine the prefix policy type commonly supported by each type of address family based on each first indication information and each second indication information.

[0081] The sending unit 710 is further configured to send a first ORF prefix policy message to the second network device, wherein the first ORF prefix policy message includes a prefix policy corresponding to a prefix policy type commonly supported by each type of address family.

[0082] Optionally, the negotiation unit 730 is specifically used to determine that if each first indication information matches each second indication information, the first network device and the second network device mutually support all prefix policy types belonging to the same type of address family.

[0083] If a portion of the first indication information in each first indication information matches a portion of the second indication information in each second indication information, then it is determined that the first network device and the second network device mutually support a partial prefix policy type belonging to the same type of address family.

[0084] Optionally, the ORF capability negotiation message also includes the transmit and receive capabilities supported by each prefix policy type;

[0085] The negotiation unit 730 is further configured to negotiate with the second network device and determine the transmit / receive capabilities supported by each prefix policy type, based on the transmit / receive capabilities supported by each prefix policy type.

[0086] Optionally, the ORF capability negotiation message includes multiple reserved fields and multiple transmit / receive capability fields;

[0087] Each reserved field carries a first indication of each prefix policy type; each transmit / receive capability field carries the transmit / receive capabilities supported by each prefix policy type.

[0088] Optionally, the first ORF prefix policy message includes multiple ORF entity fields, each ORF entity field being used to carry a prefix policy corresponding to a prefix policy type.

[0089] Optionally, the first network device supports multiple address families, specifically including EVPN address families or address families that can simultaneously support IPv4 prefix policies and IPv6 prefix policies; each type of address family supports multiple prefix policy types, specifically including IPv4 prefix policies and IPv6 prefix policies.

[0090] Therefore, by applying the communication device provided in this application, a first network device sends a first ORF capability negotiation message to a second network device. This first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information indicates a prefix policy type supported under each type of address family supported by the first network device. The first network device receives a second ORF capability negotiation message sent by the second network device. This second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information indicates a prefix policy type supported under each type of address family supported by the second network device. Based on each first indication information and each second indication information, the first network device and the second network device negotiate and determine each prefix policy type commonly supported by each type of address family. The first network device sends a first ORF prefix policy message to the second network device. This first ORF prefix policy message includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

[0091] In this way, by leveraging ORF capability negotiation messages, both ends of the network device negotiate the supported prefix policy types. Once the negotiation is successful, the local device sends the prefix policy corresponding to the commonly supported prefix policy type to the peer network device via ORF prefix policy messages. This solves the problem that existing BGP ORF features cannot simultaneously support multiple types of routing prefixes, causing the peer network device to be unable to confirm whether the received prefix policy is an IPv4 prefix policy or an IPv6 prefix policy, thus hindering interoperability. Simultaneously, it also eliminates the need for the peer network device to send all routes that the local device does not need, reducing network bandwidth consumption and the processing overhead of unnecessary routes for the local network device.

[0092] Based on the same inventive concept, embodiments of this application also provide a network device, such as... Figure 8 As shown, the system includes a processor 810, a transceiver 820, and a machine-readable storage medium 830. The machine-readable storage medium 830 stores machine-executable instructions that can be executed by the processor 810. The processor 810 is prompted by the machine-executable instructions to execute the communication method provided in the embodiments of this application. (The foregoing...) Figure 7 The communication device shown can be used as follows: Figure 8 The hardware structure of the network device shown is implemented.

[0093] The aforementioned computer-readable storage medium 830 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the computer-readable storage medium 830 may also be at least one storage device located remotely from the aforementioned processor 810.

[0094] The processor 810 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0095] In this embodiment of the application, the processor 810 reads the machine-executable instructions stored in the machine-readable storage medium 830, and is prompted by the machine-executable instructions to enable the processor 810 itself and the transceiver 820 to execute the communication method described in the foregoing embodiment of the application.

[0096] In addition, this application provides a machine-readable storage medium 830 that stores machine-executable instructions. When called and executed by the processor 810, the machine-executable instructions cause the processor 810 itself and the transceiver 820 to execute the communication method described in the aforementioned application.

[0097] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0098] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0099] For the embodiments of communication devices and machine-readable storage media, since the methods involved are basically similar to those of the aforementioned method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0100] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that, The method is applied to a first network device, which supports multiple address families and, under each address family, supports multiple prefix policy types. The method includes: Send a first ORF capability negotiation message to the second network device. The first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported under each type of address family supported by the first network device. The second network device receives a second ORF capability negotiation message, which includes at least one second indication information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device. Based on each first indication information and each second indication information, negotiate with the second network device to determine the prefix policy type commonly supported by each type of address family; Send a first ORF prefix policy message to the second network device. The first ORF prefix policy message includes the prefix policy corresponding to the prefix policy type commonly supported by each type of address family.

2. The method according to claim 1, characterized in that, The step of negotiating and determining the prefix policy type commonly supported by each address family with the second network device based on each first indication information and each second indication information specifically includes: If each first indication information matches each second indication information, then it is determined that the first network device and the second network device mutually support all prefix policy types belonging to the same type of address family; If a portion of the first indication information in each first indication information matches a portion of the second indication information in each second indication information, then it is determined that the first network device and the second network device mutually support a partial prefix policy type belonging to the same type of address family.

3. The method according to claim 1, characterized in that, The ORF capability negotiation message also includes the send and receive capabilities supported by each prefix policy type; Before sending the first ORF prefix policy message to the second network device, the method further includes: Based on the transmit / receive capabilities supported by each prefix policy type, negotiate with the second network device to determine the transmit / receive capabilities supported by each prefix policy type that is commonly supported by each type of address family.

4. The method according to claim 1, characterized in that, The ORF capability negotiation message includes multiple reserved fields and multiple send / receive capability fields; Each reserved field carries a first indication of each prefix policy type; each transmit / receive capability field carries the transmit / receive capabilities supported by each prefix policy type.

5. The method according to claim 1, characterized in that, The first ORF prefix policy message includes multiple ORF entity fields, each of which carries a prefix policy corresponding to a prefix policy type.

6. The method according to claim 1, characterized in that, The first network device supports multiple address families, specifically including EVPN address families or address families that can simultaneously support IPv4 prefix policies and IPv6 prefix policies; each type of address family supports multiple prefix policy types, specifically including IPv4 prefix policies and IPv6 prefix policies.

7. A communication device, characterized in that, The apparatus is applied to a first network device, which supports multiple address families, and each address family supports multiple prefix policy types. The apparatus includes: The sending unit is configured to send a first ORF capability negotiation message to the second network device. The first ORF capability negotiation message includes at least one first indication information for each type of address family supported by the first network device. Each first indication information is used to indicate a prefix policy type supported under each type of address family supported by the first network device. The receiving unit is configured to receive a second ORF capability negotiation message sent by the second network device. The second ORF capability negotiation message includes at least one second indication information for each type of address family supported by the second network device. Each second indication information is used to indicate a prefix policy type supported under each type of address family supported by the second network device. The negotiation unit is configured to negotiate with the second network device and determine the prefix policy type commonly supported by each type of address family based on each first indication information and each second indication information. The sending unit is further configured to send a first ORF prefix policy message to the second network device, wherein the first ORF prefix policy message includes a prefix policy corresponding to a prefix policy type commonly supported by each type of address family.

8. The apparatus according to claim 7, characterized in that, The negotiation unit is specifically used to determine that if each first indication information matches each second indication information, the first network device and the second network device mutually support all prefix policy types belonging to the same type of address family. If a portion of the first indication information in each first indication information matches a portion of the second indication information in each second indication information, then it is determined that the first network device and the second network device mutually support a partial prefix policy type belonging to the same type of address family.

9. The apparatus according to claim 7, characterized in that, The ORF capability negotiation message also includes the send and receive capabilities supported by each prefix policy type; The negotiation unit is further configured to negotiate with the second network device and determine the transmit / receive capabilities supported by each prefix policy type, based on the transmit / receive capabilities supported by each prefix policy type.

10. The apparatus according to claim 7, characterized in that, The ORF capability negotiation message includes multiple reserved fields and multiple send / receive capability fields; Each reserved field carries a first indication of each prefix policy type; each transmit / receive capability field carries the transmit / receive capabilities supported by each prefix policy type.

11. The apparatus according to claim 7, characterized in that, The first ORF prefix policy message includes multiple ORF entity fields, each of which carries a prefix policy corresponding to a prefix policy type.

12. The apparatus according to claim 7, characterized in that, The first network device supports multiple address families, specifically including EVPN address families or address families that can simultaneously support IPv4 prefix policies and IPv6 prefix policies; each type of address family supports multiple prefix policy types, specifically including IPv4 prefix policies and IPv6 prefix policies.

Images