Communication method and apparatus

Abstract

The application provides a communication method and device, the method is applied to a first MSDP peer in a first multicast domain, the first MSDP peer comprises a message publishing strategy, the message publishing strategy comprises at least one MSDP peer identifier, and the method comprises the following steps: receiving a first SA message sent by a second MSDP peer, wherein the first SA message comprises multicast source information of a second multicast domain terminal where the second MSDP peer is located; if the message publishing strategy has configured an identifier of the second multicast domain for a third MSDP peer indicated by an MSDP peer identifier, the first SA message is no longer sent to the third MSDP peer, so that the third MSDP peer no longer acquires the multicast source information; wherein a third multicast domain where the third MSDP peer is located is different from the second multicast domain.

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] Currently, multicast networks typically involve multiple multicast domains. The existing Multicast Source Discovery Protocol (MSDP) is an inter-domain multicast solution developed to address the interconnection between multiple Protocol Independent Multicast-Sparse Mode (PIM-SM) domains. It can be used to discover multicast source information within other PIM-SM domains.

[0003] The MSDP protocol establishes MSDP peer relationships by selecting appropriate network devices in the network to connect the rendezvous points (RPs) of each PIM-SM domain. Multicast source information is then shared by exchanging Source Active (SA) messages between MSDP peers.

[0004] like Figure 1 As shown, Figure 1 This diagram illustrates the interaction and communication between multiple existing multicast domains. Figure 1 The system includes multiple multicast domains, with three tenant multicast domains located on the internal network and one multicast domain located on the external network. Within each multicast domain, a network device is selected to establish an MSDP peering relationship with network devices selected by other multicast domains. After the MSDP peering relationship is successfully established, each multicast domain can obtain multicast source information from other multicast domains via SA messages.

[0005] For example, an SA message sent by tenant multicast domain 2, after being processed by the MSDP peers included in the external multicast domain, is by default propagated to all multicast domains in the internal network. However, in practical applications, it is often necessary for SA messages sent between tenant multicast domains not to be propagated. For example, the MSDP peers included in tenant multicast domain 1 or tenant multicast domain 2 may not learn or receive SA messages sent by tenant multicast domain 2.

[0006] To overcome the above problems, the following method can be used to prevent the spread of SA messages in all tenant multicast domains within the intranet: SA messages are filtered by configuring multicast source addresses and multicast group addresses that are not sent within the MSDP peer.

[0007] However, the above methods are prone to operational and maintenance inconveniences. For example, when adding multicast sources, multicast groups, or multicast services, the aforementioned filtering policies need to be configured on multiple MSDP peers (adding or removing corresponding multicast source addresses, multicast group addresses, etc. in the filtering policies), resulting in a large and complex workload for operations and maintenance. Especially when the multicast domain network is complex, a complete understanding of the global multicast services and multicast address distribution is required before any operational or maintenance operations can be performed. Summary of the Invention

[0008] In view of this, this application provides a communication method and apparatus to solve the problem of inconvenience in operation and maintenance that easily occurs in the process of avoiding the spread of SA messages in all tenant multicast domains.

[0009] In a first aspect, this application provides a communication method applied to a first MSDP peer located within a first groupcast domain, the first MSDP peer including a message distribution policy, the message distribution policy including at least one MSDP peer identifier, the method comprising:

[0010] Receive a first SA message sent by the second MSDP peer, the first SA message including multicast source information in the second multicast domain where the second MSDP peer is located;

[0011] If the message publishing policy has already configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, then the first SA message will no longer be sent to the third MSDP peer, so that the third MSDP peer will no longer obtain the multicast source information.

[0012] The third group of broadcast domains in which the third MSDP peer resides is different from the second group of broadcast domains.

[0013] Secondly, this application provides a switching device applied to a first MSDP peer located within a first group broadcast domain. The first MSDP peer includes a message distribution policy, the message distribution policy including at least one MSDP peer identifier. The device includes:

[0014] The receiving unit is configured to receive a first SA message sent by the second MSDP peer, wherein the first SA message includes multicast source information in the second multicast domain where the second MSDP peer is located.

[0015] The processing unit is configured to, if the message publishing policy has already configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, then stop sending the first SA message to the third MSDP peer, so that the third MSDP peer no longer obtains the multicast source information.

[0016] The third group of broadcast domains in which the third MSDP peer resides is different from the second group of broadcast domains.

[0017] 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.

[0018] Therefore, using the communication method and apparatus provided in this application, a first MSDP peer located in a first multicast domain receives a first SA message sent by a second MSDP peer. The first SA message includes multicast source information in the second multicast domain where the second MSDP peer is located. If the message distribution policy has configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, the first MSDP peer will no longer send the first SA message to the third MSDP peer, so that the third MSDP peer will no longer obtain multicast source information. The third multicast domain where the third MSDP peer is located is different from the second multicast domain.

[0019] Thus, by carrying the identifiers of the multicast domains of other MSDP peers in the SA message, a message distribution policy can be generated in the first MSDP peer. When the first MSDP peer receives the SA message, it can decide whether to send the SA message to other MSDPs or not, according to the message distribution policy, facilitating regional control of the SA message. This solves the problem of operational inconvenience that can easily occur when trying to prevent the SA message from spreading across all tenant multicast domains. It achieves flexibility in managing SA messages between multicast domains, while also reducing the workload and complexity of operations and maintenance. Attached Figure Description

[0020] Figure 1 This is a schematic diagram illustrating the interaction and communication between multiple existing multicast domains.

[0021] Figure 2 A flowchart illustrating the communication method provided in the embodiments of this application;

[0022] Figure 3 A diagram illustrating the SA message format provided in this application embodiment;

[0023] Figure 4 This is a schematic diagram illustrating the interaction communication between multiple multicast domains provided in an embodiment of this application;

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

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

[0026] 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.

[0027] 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.

[0028] 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."

[0029] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 2 , Figure 2 A flowchart illustrating a communication method provided in an embodiment of this application. This method is applied to a first MSDP peer, and the communication method provided in this application may include the following steps.

[0030] Step 210: Receive a first SA message sent by the second MSDP peer, wherein the first SA message includes multicast source information in the second multicast domain where the second MSDP peer is located;

[0031] Specifically, the first MSDP peer is located in the first multicast domain, and the second MSDP peer is located in the second multicast domain. The first multicast domain can be an external network multicast domain, and the second multicast domain can be a tenant multicast domain located on the internal network. There can be multiple tenant multicast domains.

[0032] The first MSDP peer has generated a message publishing policy, which includes at least one MSDP peer identifier, each MSDP peer identifier indicating an MSDP peer. The MSDP peer identifier may specifically be the address information of the MSDP peer, such as the IP address of the MSDP peer. The generation of the message publishing policy by the first MSDP peer will be described in subsequent embodiments and will not be repeated here.

[0033] In this embodiment, a network device is selected in each multicast domain to establish an MSDP peer relationship with network devices selected in other multicast domains. The MSDP peer can specifically be an RP within the multicast domain.

[0034] After the MSDP peer relationship is successfully established, each multicast domain can obtain multicast source information from other multicast domains through SA messages.

[0035] The second MSDP peer generates and sends a first SA message to the first MSDP peer. The first SA message includes multicast source information in the second multicast domain to which the second MSDP peer resides. Specifically, the multicast source information may include the multicast source address and the multicast group address.

[0036] After receiving the first SA message, the first MSDP peer determines that it was sent by the second MSDP peer located in the second multicast domain based on the source address included in the first SA message, and obtains the multicast source information from it. The first MSDP peer determines that the multicast source information is information of a multicast source in the second multicast domain.

[0037] Step 220: If the message publishing policy has already configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, then the first SA message will no longer be sent to the third MSDP peer, so that the third MSDP peer will no longer obtain the multicast source information.

[0038] Specifically, according to the description of step 210, after the first MSDP peer obtains the multicast source information in the second multicast domain, it identifies whether each MSDP peer identifier in the locally generated message publishing policy is configured with the identifier of the second multicast domain.

[0039] In one implementation, if the identifier of the second group broadcast domain has been configured for the third MSDP peer indicated by the MSDP peer identifier, then the first MSDP peer determines that the third MSDP peer will not receive messages sent from the second group broadcast domain. At this time, the first MSDP peer no longer sends the first SA message to the third MSDP peer, so that the third MSDP peer no longer obtains multicast source information from the second group broadcast domain.

[0040] In this embodiment of the application, the third MSDP peer is located in the third multicast domain, which may also be a tenant multicast domain and the third multicast domain is a different tenant multicast domain from the second multicast domain.

[0041] Optionally, the method for the first MSDP peer to identify whether each MSDP peer identifier in the locally stored message distribution policy is configured with the identifier of the second group of broadcast domains also includes another implementation: if the identifier of the second group of broadcast domains is not configured for the third MSDP peer, then the first MSDP peer determines that the third MSDP peer receives messages sent from the second group of broadcast domains. In this case, the first MSDP peer sends a first SA message to the third MSDP peer, so that the third MSDP peer can obtain multicast source information in the second group of broadcast domains.

[0042] Therefore, using the communication method provided in this application, the first MSDP peer located in the first multicast domain receives the first SA message sent by the second MSDP peer. The first SA message includes multicast source information in the second multicast domain where the second MSDP peer is located. If the message distribution policy has configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, the first MSDP peer will no longer send the first SA message to the third MSDP peer, so that the third MSDP peer will no longer obtain multicast source information. The third multicast domain where the third MSDP peer is located is different from the second multicast domain.

[0043] Thus, by carrying the identifiers of the multicast domains of other MSDP peers in the SA message, a message distribution policy can be generated in the first MSDP peer. When the first MSDP peer receives the SA message, it can decide whether to send the SA message to other MSDPs or not, according to the message distribution policy, facilitating regional control of the SA message. This solves the problem of operational inconvenience that can easily occur when trying to prevent the SA message from spreading across all tenant multicast domains. It achieves flexibility in managing SA messages between multicast domains, while also reducing the workload and complexity of operations and maintenance.

[0044] Optionally, this application embodiment also includes a process in which the first MSDP peer generates a message publishing strategy locally.

[0045] Specifically, each tenant multicast domain includes an MSDP peer that receives a second configuration instruction input by an administrator (or user), which includes the identifier of the multicast domain configured by the administrator for that tenant multicast domain.

[0046] According to the second configuration instruction, each tenant multicast domain includes the identifier of the MSDP peer storage multicast domain.

[0047] After each tenant multicast domain's MSDP peers establish an MSDP peer relationship with the first MSDP peer, each tenant multicast domain's MSDP peers generate and send a second SA message to the first MSDP peer. Each second SA message includes the identifier of the multicast domain in which the MSDP peer resides.

[0048] Simultaneously, the first MSDP peer also receives a first configuration instruction input by the user, which includes packet filtering rules. The packet filtering rules are used to indicate whether to configure the corresponding multicast domain identifier for each MSDP peer included in the tenant multicast domain.

[0049] According to the message filtering rules, the first MSDP peer generates a message publishing policy, which includes the MSDP peer identifier and the identifier of the multicast domain configured for the MSDP peer indicated by the MSDP peer identifier, or the message publishing policy includes the MADP peer identifier.

[0050] In one example, the network includes tenant multicast domain 1 and tenant multicast domain 2. The multicast domain identifier for tenant multicast domain 1 is id1, and the multicast domain identifier for tenant multicast domain 2 is id2. The above packet filtering rules instruct MSDP peers included in tenant multicast domain 1 not to receive packets sent from tenant multicast domain 2; MSDP peers included in tenant multicast domain 2 can receive packets sent from any tenant multicast domain.

[0051] The message publishing strategies generated by the first MSDP peer are shown in Table 1:

[0052] Table 1 Message Distribution Strategy

[0053] MSDP peer identification Multicast domain identifier XXXX (indicates the MSDP peers included in tenant multicast domain 1) id2 YYYY (indicates the MSDP peers included in tenant multicast domain 2)

[0054] As shown in Table 1, XXXX is configured with the multicast domain identifier id2, which means that the MSDP peers included in tenant multicast domain 1 do not receive messages sent by tenant multicast domain 2; while YYYY is not configured with the multicast domain identifier, which means that the MSDP peers included in tenant multicast domain 2 can receive messages sent by any tenant multicast domain.

[0055] Optionally, in this embodiment, the second SA message includes a Transmission Control Protocol (TCP) segment attribute, which includes a Type field, a Length field, and a Value field. The Type field has a value of 5 to indicate the identifier of the multicast domain where the MSDP peer resides, and the Length field represents the length of the Value field.

[0056] like Figure 3 As shown, Figure 3 This is a diagram illustrating the SA message format provided in an embodiment of this application. Figure 3 In a TCP segment, the SA message includes an IP header, a TCP header, and a TCP segment. The TCP segment includes a Type field, a Length field, and a Value field. The Type field occupies 8 bits; the Length field occupies 16 bits; and the Value field has a variable length.

[0057] It should be noted that the values ​​and functions of the Type field are already defined in the existing MSDP. Different values ​​of the Type field determine the different functions of the SA message. For example, when the Type field is set to 1, it indicates that the SA message is used to carry multicast source information. In practical applications, the Type field can also take values ​​of 2, 3, 4, 5, 6, and 7, each value of the Type field identifying a different function of the SA message.

[0058] In existing MSDP, when the Type field value is 5, the SA message is a reserved type. In this embodiment, the SA message with a Type field value of 5 carries the identifier of the multicast domain, so as to announce the identifier of the tenant multicast domain to the MSDP peers included in the external multicast domain.

[0059] like Figure 4 As shown, Figure 4 This diagram illustrates the interaction communication between multiple multicast domains provided in an embodiment of this application. Figure 4 The system includes multiple multicast domains. Tenant multicast domain 1, tenant multicast domain 2, and tenant multicast domain 3 are located on the internal network, while multicast domain 4 is located on the external network. Within each multicast domain, a network device is selected to establish an MSDP peer relationship with network devices selected in other multicast domains.

[0060] After the MSDP peer relationship is successfully established, each MSDP peer in the tenant multicast domain generates and sends an SA message 1 to the MSDP peers in multicast domain 4. Each SA message 1 includes the identifier of the tenant multicast domain.

[0061] For example, MSDP peer 1 generates SA message 1, which includes the identifier id1 of tenant multicast domain 1; MSDP peer 2 generates SA message 1, which includes the identifier id2 of tenant multicast domain 1; MSDP peer 3 generates SA message 1, which includes the identifier id3 of tenant multicast domain 1.

[0062] It is understandable that the Type field of the SA message 1 above has a value of 5.

[0063] After receiving multiple SA messages 1, MSDP peer 4 retrieves the IDs of each tenant's multicast domain from the SA messages 1. Simultaneously, MSDP peer 4 receives configuration instructions from administrators, which include message filtering rules. MSDP peer 4 then generates a message distribution policy based on these filtering rules, as shown in Table 2.

[0064] Table 2 Message Distribution Strategy

[0065]

[0066]

[0067] MSDP peer 2 generates and sends SA message 2 to MSDP peer 4. This SA message 2 includes multicast source information in tenant multicast domain 2. It is understood that the Type field of the above SA message 2 has a value of 1.

[0068] After receiving SA message 2, MSDP peer 4 determines that it was sent by MSDP peer 2 based on the source address included in SA message 2, and obtains the multicast source information from it. MSDP peer 4 determines that the multicast source information is information of a multicast source in tenant multicast domain 2. MSDP peer 4 identifies whether each MSDP peer identifier in the message distribution policy is configured with an identifier of tenant multicast domain 2. In this embodiment, MSDP peer 4 configures the identifier of tenant multicast domain 2 for MSDP peer 1.

[0069] Therefore, MSDP peer 4 sends SA message 2 to MSDP peer 3, but not to MSDP peer 1. This ensures that MSDP peer 3 obtains the multicast source information in tenant multicast domain 2, while MSDP peer 1 does not.

[0070] By including the identifiers of the multicast domains of other MSDP peers in SA message 1, a message distribution policy is generated in MSDP peer 4. When MSDP peer 4 receives SA message 2, it determines whether to send SA messages to other MSDPs or not, based on the message distribution policy, facilitating regional control of SA messages. This solves the operational inconvenience that can easily arise in existing methods for preventing SA messages from spreading across all tenant multicast domains. It achieves flexibility in managing SA messages between multicast domains, while also reducing operational workload and complexity.

[0071] Based on the same inventive concept, embodiments of this application also provide a communication device corresponding to the communication method. See also Figure 5 , Figure 5The communication apparatus provided in this application embodiment is applied to a first MSDP peer located within a first groupcast domain. The first MSDP peer includes a message distribution policy, the message distribution policy including at least one MSDP peer identifier. The apparatus includes:

[0072] The receiving unit 510 is configured to receive a first SA message sent by the second MSDP peer, wherein the first SA message includes multicast source information in the second multicast domain where the second MSDP peer is located.

[0073] The processing unit 520 is configured to, if the message publishing policy has configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, then stop sending the first SA message to the third MSDP peer, so that the third MSDP peer no longer obtains the multicast source information.

[0074] The third group of broadcast domains in which the third MSDP peer resides is different from the second group of broadcast domains.

[0075] Optionally, the device further includes:

[0076] The sending unit (not shown in the figure) is used to send the first SA message to the third MSDP peer if the identifier of the second multicast domain is not configured for the third MSDP peer in the message publishing policy, so that the third MSDP peer can obtain the multicast source information.

[0077] Optionally, the receiving unit 510 is further configured to receive at least one second SA message sent by an MSDP peer, each second SA message including an identifier of the multicast domain to which the MSDP peer belongs;

[0078] The receiving unit 510 is further configured to receive a first configuration instruction input by a user, the first configuration instruction including a message filtering rule, the message filtering rule being used to indicate whether it is an identifier for configuring a multicast domain for an MSDP peer;

[0079] The apparatus further includes: a generation unit (not shown in the figure), configured to generate the packet distribution policy according to the packet filtering rules, wherein the packet distribution policy includes an MSDP peer identifier and an identifier of a multicast domain configured for the MSDP peer indicated by the MSDP peer identifier, or the packet distribution policy includes an MADP peer identifier.

[0080] Optionally, the second SA message includes TCP segment attributes, which include a type field, a length field, and a value field. The type field has a value of 5 to indicate the identifier of the multicast domain where the MSDP peer resides, and the length field represents the length of the value field.

[0081] Optionally, the second SA message is sent by the MSDP peer after receiving the second configuration instruction input by the user, the second configuration instruction including the identifier of the multicast domain configured by the user for the multicast domain where the MSDP peer is located.

[0082] Therefore, using the communication device provided in this application, a first MSDP peer located in a first groupcast domain receives a first SA message sent by a second MSDP peer. The first SA message includes multicast source information in the second groupcast domain where the second MSDP peer is located. If the message distribution policy has configured the identifier of the second groupcast domain for the third MSDP peer indicated by the MSDP peer identifier, the first MSDP peer will no longer send the first SA message to the third MSDP peer, so that the third MSDP peer will no longer obtain multicast source information. The third groupcast domain where the third MSDP peer is located is different from the second groupcast domain.

[0083] Thus, by carrying the identifiers of the multicast domains of other MSDP peers in the SA message, a message distribution policy can be generated in the first MSDP peer. When the first MSDP peer receives the SA message, it can decide whether to send the SA message to other MSDPs or not, according to the message distribution policy, facilitating regional control of the SA message. This solves the problem of operational inconvenience that can easily occur when trying to prevent the SA message from spreading across all tenant multicast domains. It achieves flexibility in managing SA messages between multicast domains, while also reducing the workload and complexity of operations and maintenance.

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

[0085] The aforementioned computer-readable storage medium 630 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 630 may also be at least one storage device located remotely from the aforementioned processor 610.

[0086] The processor 610 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.

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

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

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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 MSDP peer located within a first groupcast domain, the first MSDP peer including a message distribution policy, the message distribution policy including at least one MSDP peer identifier, the method comprising: Receive a first SA message sent by the second MSDP peer, the first SA message including multicast source information in the second multicast domain where the second MSDP peer is located; If the message publishing policy has already configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, then the first SA message will no longer be sent to the third MSDP peer, so that the third MSDP peer will no longer obtain the multicast source information. Wherein, the third group of broadcast domains in which the third MSDP peer is located is different from the second group of broadcast domains; Before receiving the first SA message sent by the second MSDP peer, the method further includes: Receive at least one second SA message sent by an MSDP peer, each second SA message including the identifier of the multicast domain to which the MSDP peer belongs; Receive a first configuration instruction input by the user, the first configuration instruction including a packet filtering rule, the packet filtering rule being used to indicate whether it is an identifier for configuring a multicast domain for an MSDP peer; Based on the packet filtering rules, a packet distribution policy is generated. The packet distribution policy includes an MSDP peer identifier and an identifier of the multicast domain configured for the MSDP peer indicated by the MSDP peer identifier. Alternatively, the packet distribution policy includes an MADP peer identifier.

2. The method according to claim 1, characterized in that, The method further includes: If the message publishing policy does not configure the identifier of the second multicast domain for the third MSDP peer, then the first SA message is sent to the third MSDP peer so that the third MSDP peer can obtain the multicast source information.

3. The method according to claim 1, characterized in that, The second SA message includes TCP segment attributes, which include a type field, a length field, and a value field. The type field has a value of 5 to indicate the identifier of the multicast domain where the MSDP peer resides, and the length field indicates the length of the value field.

4. The method according to claim 1, characterized in that, The second SA message is sent by the MSDP peer after receiving the second configuration instruction input by the user. The second configuration instruction includes the identifier of the multicast domain configured by the user for the multicast domain where the MSDP peer is located.

5. A communication device, characterized in that, The apparatus is applied to a first MSDP peer located within a first group broadcast domain. The first MSDP peer includes a message distribution policy, the message distribution policy including at least one MSDP peer identifier. The apparatus includes: The receiving unit is configured to receive a first SA message sent by the second MSDP peer, wherein the first SA message includes multicast source information in the second multicast domain where the second MSDP peer is located. The processing unit is configured to, if the message publishing policy has already configured the identifier of the second multicast domain for the third MSDP peer indicated by the MSDP peer identifier, then stop sending the first SA message to the third MSDP peer, so that the third MSDP peer no longer obtains the multicast source information. Wherein, the third group of broadcast domains in which the third MSDP peer is located is different from the second group of broadcast domains; The receiving unit is further configured to receive at least one second SA message sent by an MSDP peer, each second SA message including the identifier of the multicast domain to which the MSDP peer belongs; The receiving unit is further configured to receive a first configuration instruction input by a user, the first configuration instruction including a message filtering rule, the message filtering rule being used to indicate whether it is an identifier for configuring a multicast domain for an MSDP peer; The apparatus further includes: a generation unit, configured to generate the packet distribution policy according to the packet filtering rules, wherein the packet distribution policy includes an MSDP peer identifier and an identifier of a multicast domain configured for the MSDP peer indicated by the MSDP peer identifier, or the packet distribution policy includes an MADP peer identifier.

6. The apparatus according to claim 5, characterized in that, The device further includes: The sending unit is configured to send the first SA message to the third MSDP peer if the identifier of the second multicast domain is not configured for the third MSDP peer in the message publishing policy, so that the third MSDP peer can obtain the multicast source information.

7. The apparatus according to claim 5, characterized in that, The second SA message includes TCP segment attributes, which include a type field, a length field, and a value field. The type field has a value of 5 to indicate the identifier of the multicast domain where the MSDP peer resides, and the length field indicates the length of the value field.

8. The apparatus according to claim 5, characterized in that, The second SA message is sent by the MSDP peer after receiving the second configuration instruction input by the user. The second configuration instruction includes the identifier of the multicast domain configured by the user for the multicast domain where the MSDP peer is located.

Images