CN118233364A - Message transmission method, device and network equipment - Google Patents

Message transmission method, device and network equipment Download PDF

Info

Publication number
CN118233364A
CN118233364A CN202310321021.2A CN202310321021A CN118233364A CN 118233364 A CN118233364 A CN 118233364A CN 202310321021 A CN202310321021 A CN 202310321021A CN 118233364 A CN118233364 A CN 118233364A
Authority
CN
China
Prior art keywords
address
message
bier
bier message
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310321021.2A
Other languages
Chinese (zh)
Inventor
谢经荣
段方红
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN118233364A publication Critical patent/CN118233364A/en
Pending legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The application provides a message transmission method, a message transmission device and network equipment, and belongs to the technical field of communication. In the message transmission method, an inlet device acquires a first BIER message, and the source address of the first BIER message is the address of a first user; obtaining a second BIER message based on the first BIER message, wherein the source address of the second BIER message is the address of the entry device corresponding to the address of the first user; the ingress device sends a second BIER message. Through the scheme, the configuration quantity can be greatly reduced, and the implementation complexity is reduced.

Description

Message transmission method, device and network equipment
The present application claims priority from chinese patent application No. 202211642514.8, entitled "BIER MVPN method and apparatus," filed on 12/20/2022, the entire contents of which are incorporated herein by reference.
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, and a network device for transmitting a message.
Background
Bit index based explicit replication (bit indexed explicit replication, BIER) techniques are techniques for implementing multicast message forwarding. BIER virtual private network (virtual private networks, VPN) technology employs VPN implementations to transport BIER messages across operator networks. When transmitting BIER messages across an operator network, an operator edge (PE) node needs to be configured accordingly based on network security requirements to enable a multicast user to access another multicast user in the VPN. The above configuration increases implementation complexity when there are a plurality of multicast users or addresses of the multicast users are changed.
Disclosure of Invention
The application provides a message transmission method, a message transmission device and network equipment, which can reduce the implementation complexity.
The technical scheme is as follows.
In a first aspect, a method for transmitting a message is provided, where the method includes: the method comprises the steps that an inlet device obtains a first bit index based explicit copy BIER message, and a source address of the first BIER message is an address of a first user; the method comprises the steps that an inlet device obtains a second BIER message based on a first BIER message, and a source address of the second BIER message is an address of the inlet device corresponding to an address of a first user; the ingress device sends a second BIER message.
The ingress device may refer to an ingress device of an operator network, for example, an operator edge device of the operator network.
In this implementation, after the ingress device obtains the BIER message, the source address in the BIER message is updated, so that the updated source address is the address of the ingress device, and then the second BIER message is sent. Because the addresses of the entrance devices can be accessed by other nodes in the operator network, relevant configuration in the nodes is not needed, the configuration quantity is reduced, the configuration efficiency is improved, and the implementation complexity is reduced.
In an implementation of the present application, the first user is a multicast user, and the address of the first user is a multicast source address.
Illustratively, the multicast subscriber may be a VPN in general; or the multicast subscriber may also be a public network subscriber.
In one example, the first BIER message may be a BIERv message generated by the host, at which point the address of the first user is the address of the host.
In another example, the first BIER packet may be a BIERv packet after the user edge device encapsulates the received user multicast packet, where the address of the first user is the address of the user edge device.
In the portal device, the addresses of the different first users correspond to the addresses of the different portal devices. Correspondingly, the obtaining, by the inlet device, the second BIER message based on the first BIER message includes:
The method comprises the steps that the entrance equipment obtains an address of the entrance equipment based on the address of a first user and a corresponding relation, wherein the corresponding relation comprises the address of the first user and the address of the entrance equipment; the ingress device obtains a second BIER message based on the first BIER message and an address of the ingress device.
In this implementation, the portal device obtains the address of the portal device through the address of the first user and the correspondence, and the address of the portal device may be obtained for each of the different addresses of the first user. The access authority of the addresses of different first users is not required to be configured by other nodes in the operator network, so that the configuration quantity is greatly reduced, the configuration efficiency is improved, and the implementation complexity is reduced.
When the inlet device processes the first BIER message, besides modifying the source address, the parameters such as the destination address, the time-to-live TTL and the like are modified, so as to obtain a second BIER message.
Optionally, the method further comprises:
The method comprises the steps that an entrance device obtains an address of a first user; the method comprises the steps that an inlet device allocates an address of the corresponding inlet device for the address of a first user in a network segment corresponding to an IPv 6-based segment routing position identifier; the portal device obtains a correspondence based on the address of the first user and the address of the portal device.
In this implementation, after acquiring the address of the first user, the ingress device allocates an address of the corresponding ingress device to the corresponding network segment from the IPv 6-based segment routing location identifier. Since the address in the network segment corresponding to the IPv6 based segment routing location identification can be allowed access by other nodes in the operator network. Thus, when the subsequent ingress device receives the first BIER message, the source address of the BIER message is updated (or modified) using the address allocated thereto, enabling the second BIER message to be received by other nodes in the operator network without being discarded.
Optionally, the obtaining, by the portal device, the address of the first user includes:
The ingress device receives an interior gateway protocol, IGP, message or a first border gateway protocol, BGP, message, the IGP message or the first BGP message comprising an address of the first user.
Illustratively, the ingress device receives the IGP message or the first BGP message over an interface corresponding to the first VPN. Wherein the first VPN is the first user.
In the IGP message or the first BGP message, the indication information is carried in addition to the address of the first user. The indication information is used for indicating that the portal device needs to be used as a multicast source address, so that the portal device opens the address access authority of the address of the first user, i.e. allows a message with the source address being the address of the first user to be received from an interface of the portal device corresponding to the first VPN without discarding the message. Meanwhile, the indication message is further used for indicating the entrance equipment to allocate the address of the corresponding entrance equipment for the address of the first user.
Since the ingress device modifies the source address of the BIER message before sending the BIER message. In order to ensure that the source address of the BIER message received by the destination host is unchanged compared with the source address received by the ingress device, the egress device is required to modify the source address of the BIER message, and the source address is modified to be the address of the first user.
In one possible implementation manner of the present application, the ingress device may send the above correspondence to the egress device, so that the egress device may obtain the first BIER message based on the correspondence and the second BIER message, and then send the first BIER message to the destination host.
For example, the ingress device sends a second BGP message to the egress device, the second BGP message including the correspondence.
In another possible implementation of the present application, the address of the first user may be carried in the second BIER message. That is, the second BIER message also includes the address of the first user. By carrying the address of the first user in the second BIER message, the output device can obtain the first BIER message based on the address of the first user and the second BIER message, and then send the first BIER message to the destination host.
Illustratively, the IPv6 extension header of the second BIER message includes the address of the first user; or the destination option header DOH header of the second BIER message includes the address of the first user.
In a second aspect, a method for transmitting a message is provided, where the method includes:
The outlet device obtains a second bit index based explicit copy BIER message, and the source address of the second BIER message is the address of the inlet device; the outlet device obtains a first BIER message based on the second BIER message, wherein the source address of the first BIER message is the address of a first user corresponding to the address of the inlet device; the exit device sends a first BIER message.
The egress device may refer to an egress device of an operator network, for example, an operator edge device of the operator network.
In this implementation, the source address of the BIER message acquired by the egress device is the address of the ingress device. Because the addresses of the entrance devices can be accessed by other nodes in the operator network, relevant configuration in the nodes is not needed, the configuration quantity is reduced, the configuration efficiency is improved, and the implementation complexity is reduced. After the outlet device acquires the BIER message, the source address of the BIER message is modified, the source address is modified into the address of the first user, and the source address of the BIER message received by the target host is ensured to be unchanged compared with the source address of the BIER message received by the inlet device.
In one possible implementation manner of the present application, the first BIER message is obtained in the outlet device according to the corresponding relationship between the address of the inlet device and the address of the first user and the second BIER message. That is, the obtaining, by the outlet device, the first BIER message based on the second BIER message includes:
The method comprises the steps that the outlet equipment obtains an address of a first user based on an address of the inlet equipment and a corresponding relation, wherein the corresponding relation comprises the address of the inlet equipment and the address of the first user; and the outlet equipment obtains the first BIER message according to the second BIER message and the address of the first user.
In this implementation, the exit device obtains the address of the first user through the address and the correspondence relationship of the entry device, and the address of the first user may be obtained for different addresses of the entry device. The access authority of the addresses of different first users is not required to be configured by other nodes in the operator network, so that the configuration quantity is greatly reduced, the configuration efficiency is improved, and the implementation complexity is reduced.
Illustratively, the method further comprises:
the outlet device receives a border gateway protocol BGP message sent by the inlet device, where the BGP message includes a correspondence.
In another possible implementation manner of the present application, the first BIER message is obtained in the egress device according to the second BIER message. In this implementation, the second BIER message also includes the address of the first user.
Illustratively, the IPv6 extension header of the second BIER message includes the address of the first user, or the destination option header DOH header of the second BIER message includes the address of the first user.
The obtaining, by the outlet device, the first BIER message based on the second BIER message includes:
the outlet equipment acquires the address of the first user based on the second BIER message; the exit device obtains a first BIER message based on the second BIER message and the address of the first user.
In a third aspect, a message transmission apparatus is provided, including:
The acquisition unit is used for acquiring a first BIER message which is explicitly copied based on the bit index, and the source address of the first BIER message is the address of a first user; the processing unit is used for obtaining a second BIER message based on the first BIER message, and the source address of the second BIER message is the address of the entrance equipment corresponding to the address of the first user; and the sending unit is used for sending the second BIER message.
Optionally, the processing unit is configured to obtain an address of the entry device based on the address of the first user and a corresponding relationship, where the corresponding relationship includes the address of the first user and the address of the entry device; and obtaining a second BIER message based on the first BIER message and the address of the access device.
Optionally, the acquiring unit is further configured to acquire an address of the first user; the processing unit is further used for distributing the address of the corresponding entrance equipment to the address of the first user in the network segment corresponding to the segment routing position identification based on the IPv 6; and obtaining a corresponding relation based on the address of the first user and the address of the entrance equipment.
Optionally, the obtaining unit is configured to receive an IGP message of an interior gateway protocol or a BGP message of a first border gateway protocol, where the IGP message or the BGP message includes an address of the first user.
Optionally, the sending unit is further configured to send a second BGP message to the egress device, where the second BGP message includes the correspondence.
Optionally, the second BIER message further includes the address of the first user.
Optionally, the IPv6 extension header of the second BIER message includes an address of the first user; or the destination option header DOH header of the second BIER message includes the address of the first user.
In a fourth aspect, a message transmission apparatus is provided, including:
The acquisition unit is used for acquiring a second BIER message which is explicitly copied based on the bit index, and the source address of the second BIER message is the address of the inlet equipment; the processing unit is used for obtaining a first BIER message based on the second BIER message, and the source address of the first BIER message is the address of a first user corresponding to the address of the inlet equipment; and the sending unit is used for sending the first BIER message.
Optionally, the processing unit is configured to obtain an address of the first user based on an address of the entry device and a correspondence, where the correspondence includes the address of the entry device and the address of the first user; and obtaining the first BIER message according to the second BIER message and the address of the first user.
Optionally, the acquiring unit is further configured to receive a border gateway protocol BGP message sent by the ingress device, where the BGP message includes a correspondence.
Optionally, the second BIER message further includes the address of the first user.
Optionally, the IPv6 extension header of the second BIER message includes the address of the first user, or the destination option header DOH header of the second BIER message includes the address of the first user.
Optionally, the processing unit is configured to obtain an address of the first user based on the second BIER packet; and obtaining the first BIER message based on the second BIER message and the address of the first user.
In a fifth aspect, there is provided a network device comprising a processor and a memory for storing a software program, the processor causing the network device to implement the method of or the second aspect or any of the alternatives described above by running or executing the software program stored in the memory.
In a sixth aspect, a messaging system is provided, the messaging system comprising an ingress device that performs the method of the first aspect or any of the alternatives of the first aspect, and an egress device that performs the method of the second aspect or any of the alternatives of the second aspect.
In a seventh aspect, there is provided a computer readable storage medium having stored therein at least one instruction that when executed on a computer causes the computer to perform the method provided in the first aspect or any of the alternatives of the first aspect or perform the method in the second aspect or any of the alternatives of the second aspect.
In an eighth aspect, there is provided a computer program product comprising one or more computer program instructions which, when loaded and executed by a computer, cause the computer to perform the method provided in or the method in or the second aspect or any of the alternatives described above.
In a ninth aspect, there is provided a chip comprising a memory for storing computer instructions and a processor for calling and executing the computer instructions from the memory to perform the method of the first aspect and any possible implementation of the first aspect, or to perform the method of the second aspect or any alternative implementation of the second aspect.
Drawings
Fig. 1 is a schematic diagram of a network deployment scenario provided in an embodiment of the present application;
fig. 2 is a schematic diagram of a network deployment scenario provided in an embodiment of the present application;
Fig. 3 is a flowchart of a message transmission method provided in an embodiment of the present application;
fig. 4 is a flowchart of a message transmission method provided in an embodiment of the present application;
Fig. 5 is a flowchart of a message transmission method according to an embodiment of the present application;
FIG. 6 is a diagram illustrating a BIER message format according to an embodiment of the present application;
fig. 7 is a flowchart of a message transmission method according to an embodiment of the present application;
FIG. 8 is a diagram illustrating a BIER message format according to an embodiment of the present application;
fig. 9 is a flowchart of a message transmission method provided in an embodiment of the present application;
Fig. 10 is a flowchart of a message transmission method according to an embodiment of the present application;
Fig. 11 is a schematic structural diagram of a message transmission device according to an embodiment of the present application;
fig. 12 is a schematic structural diagram of a message transmission device according to an embodiment of the present application;
Fig. 13 is a schematic structural diagram of a network device according to an embodiment of the present application;
Fig. 14 is a schematic structural diagram of a network device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, embodiments of the present application will be described in further detail with reference to the accompanying drawings.
Some term concepts related to the embodiments of the present application are explained below.
(1) Explicit replication based on Bit Indices (BIER)
BIER technology is a multicast technology in which BFR-ids are assigned to edge nodes of BIER domains, e.g., a value between 1 and 256. The edge node floods its configured BIER information in the BIER domain through IGP, so that other nodes in the BIER domain obtain parameters needed for implementing BIER forwarding. For example, if the value of BFR-id of a node is not 0, then the node is an edge node, and if BFR-di of a node is 0, then the node is an intermediate node, i.e., a non-edge node.
(2) BIER message
The BIER message includes a BIER header and a multicast data message. The format of the BIER header can be found in request for comments (request for comment, RFC) 8296, description of the BIER header. The BIER header includes a BIER-Label or BIER forwarding table identification (bit indexed forwarding table identifer, BIFT-ID). BIER header may also include traffic class (TRAFFIC CLASS, TC), S-bit, time To Live (TTL), discriminator (Nibble), version (Ver), bit string length (bitslength, BSL), entropy (Entropy), detection (OAM), reserved (Rsv), differentiated services field code (DIFFERENTIATED SERVICES FIELD codepoints, DSCP), protocol (Proto), BIER forwarding ingress router (bit forwarding ingress router, BFIR) Identification (ID). The BIER header also includes a bit string (BitString). Each Bit in BitString corresponds to a BIER forwarding egress router (Bit forwarding egress router, BFER), and the lower (rightmost) Bit of, for example BitString is used to identify a BFER with a BFR-id of 1. The 2 nd Bit from right to left in BitString is used to identify BFER with BFR-id of 2. BFIR, intermediate BFR or BFER in the BIER domain can realize the forwarding of the BIER message according to the BIER forwarding table item and BitString included in the BIER message.
(3)BIER VPN
The network in which the Provider Edge (PE) device and the Customer Edge (CE) device pass through the BIER packet transmission path is referred to as a customer network. By configuring VPNs on PE nodes to distinguish between different customer networks, one VPN corresponds to each customer network. After receiving the BIER message from the CE, the PE device forwards the BIER message in a transparent transmission manner, so as to implement BIER VPN. The transparent transmission mode refers to forwarding according to BitString in the BIER message without encapsulating the BIER message.
Optionally, in the embodiment of the present application, the user network or the VPN may also refer to a public network.
RFC4364 defines the concept and method of an operator network to provide a virtual private network (Virtual Private Network, VPN) to a customer, including: an operator Edge (PE) router interfaces with Customer Edges (CEs), and the same PE may interface with CEs of multiple customers, who may have CE interfaces across multiple PEs of an operator network and may be referred to as different sites. To support forwarding, i.e., isolation, of multiple clients, a plurality of routing forwarding tables are maintained on the PE router, one of which is a "default routing forwarding table (default forwarding table)" or a public network forwarding table or a public network space forwarding table, and the other routing forwarding tables are called "VPN routing forwarding tables (VPN Routing and Forwarding tables)" or VRFs, and the VRFs may also be referred to as private network routing forwarding tables or private network space forwarding tables. When a PE connects an interface of a CE and a VPN binding or corresponding, the interface is also referred to as a "VRF interface", a link between the PE and the CE is also referred to as a "VRF link" (VRF ATTACHMENT circuit), and a packet received from the interface is forwarded using a private network routing table.
RFC4364 also defines the concept of an IP VPN, meaning that the operator network is responsible for sending IP unicast messages of VPN users from one site to another. In particular, an ingress carrier edge (INGRESS PE) router device receives IP messages from a Customer Edge (CE) device, transmits the messages over a carrier network to an Egress PE router, and to a Customer Edge (CE) device of another site.
Based on the concept of IP VPN described above, RFC6513 defines a Multicast VPN, meaning that the operator network is responsible for sending IP Multicast messages for VPN users from one site to another or to other sites. In particular, an ingress carrier edge (INGRESS PE) router device receives an IP multicast message from a Customer Edge (CE) device, transmits the message over a carrier network to an Egress PE router, and to another Customer Edge (CE) device. Wherein the destination address of the user's IP multicast message is a multicast group address, the concept of which is defined in RFC1112, is an address different from a unicast address, such as 224.0.0.1 to 239.255.255.255 is defined as a multicast address.
Based on the concept of IP VPN as described above, a BIER VPN is called if the operator network is responsible for sending BIER messages of VPN users from one site to another or to other sites. Specifically, if the packet of the customer site CE received by the ingress PE is a BIER packet, where the BIER packet carries BitString a customer node designated to be located at another site, and the operator network can refer to the packet as a customer node of another site designated in BitString, the service provided by this operator network for the customer is referred to as BIER VPN service.
In one implementation of BIER VPN, the message received by the ingress PE from the customer site CE is an IPv6 encapsulated BIER message that includes not only BitString, but also an IPv6 header, such as a message format defined by draft-xie-BIER-IPv6-encapsulation-10, also referred to as BIERv message. And after receiving BIERv messages from the CE, the PE equipment forwards the BIER messages in a transparent transmission mode to realize BIER VPN. The transparent transmission mode refers to forwarding according to BitString in the BIER message without encapsulating the BIER message.
In another implementation of BIER VPN, the BIER message received by the ingress PE may come from not only "VRF links" or links to which VRFs are bound, but also links to which VRFs are not bound or public network links, and although such links are no longer conceptual scope of VPN, the method employed is the same as BIER VPN. Similarly, the method of the present invention can be used not only in BIER VPN scenarios where "VRF links" are used between PE-CEs, but also in scenarios where "public network links" are used between PE-CEs, but in the specific description, the "VRF links" and BIER VPN are taken as examples.
(4) Virtual routing forwarding (virtual routing and forwarding, VRF)
The VRF table allows multiple instances of a routing table to coexist in the same router. Since the routing instances in the VRF table are independent, the same or overlapping internet protocol (internet protocol, IP) addresses can be used without collision. The VRF function provides a function of changing from one physical router to a plurality of virtual routers. On the PE device, different VRFs are configured for different VPNs, e.g. VPNa and VPNb are configured on PE1, and correspondingly, VRF1 corresponding to VPNa and VRF2 corresponding to VPNb are configured in PE 1. A public network (pubic) routing table (route table) is configured on a provider edge (P) device or a backbone (BB) device.
(5)End.BIER
Bier is a new type of SID defined by BIERv network that handles the BIERv extension header in messages as the forwarding plane for IPv6 destination address pointing devices. When each node receives and processes BIERv messages, the end.bier of the next-hop node is packaged as the outer layer IPv6 destination address of BIERv messages, so that the next-hop node forwards the messages according to the BIERv flow.
End. Bier can be divided into two parts: location identification (Locator) and other bits. The Locator represents a BIERv forwarding node. The locators have a locating function, and after the nodes configure the locators, the system generates a Locator network segment route and diffuses the network segment route (segment routing over IPv, SRv) based on the IPv6 through an interior gateway protocol (interior gateway protocol, IGP). Other nodes in the network can be positioned to the node through the router network segment route. The end-BIER can guide the message to the appointed BFR, and the BFR recognizes that the destination address of the message is the end-BIER of the local address, determines the VRF according to the Locator, and forwards the message based on the BIER forwarding table corresponding to the VRF.
The PE equipment needs to configure corresponding end.bier towards the VPN example, so that the VPN to which the received message belongs is determined, and the BIER forwarding table corresponding to the VPN is adopted for forwarding. For example, for PE1, in the VRF Context (Context) of VPNa, PE 1's end.BIER may be configured as PE1.vrf1.end.BIER, and in the VRF Context of VPNb, PE 1's end.BIER may be configured as PE1.vrf2.end.BIER. After configuration of PE1.Vrf1.End. Bier, it is also necessary to issue a route towards the VPNa user side device (e.g. CE 1), which may contain the IPv6 address prefix of PE1.Vrf1.End. Bier, so that the user side device CE1 of VPNa may route to PE1.
When the P device or the BB device is acting as a node on the VPN topology, for example as an intermediate node between 2 PE devices, they may also configure end. The end.bier of these P-devices or BB-devices is in public network space and may be referred to as VPN-specific end.bier. For example, BB4 has VPNa and VPNb, and 2 VPN-related (associated) end. Biers are required to be used as destination addresses for message transmission of VPNa and VPNb, respectively. On the P device or the BB device, the BIER forwarding table comprises a group of forwarding table items related to a public network and a plurality of groups of forwarding table items related to each VPN, and when the BIER message is received, table lookup forwarding is performed in the corresponding forwarding table items according to BIFT-id < sub-domain, SD)/bit string length (BitString length, BSL)/set identifier (SET IDENTIFIER, SI) >.
(6)SRv6 Locator
According to SRv architecture standards RFC8986 and RFC8754, an IPv6 address block is planned in the network and SRv locators are configured in the address block for individual devices in the operator network. For example, the address block is 2001:db8:ffff:48, and SRv Locator of the Kth node is identified by 2001:db8:ffff:k::64 based on the address block. For example, the PE1/PE2/PE3/P1 is the 1/2/3/10 node, and the corresponding SRv Locator is 2001:db8:ffff:1:64, 2001:db8:ffff:2:64, 2001:db8:ffff:3:64, 2001:db8:ffff:A:64.
The network deployment scenario of the embodiment of the present application is illustrated below.
Fig. 1 is a schematic diagram of a network deployment scenario provided in an embodiment of the present application. As shown in fig. 1, the scenario includes a user-side network 10 and an operator network 20, where hosts, such as H1-H3 in fig. 1, included in the user-side network 10 are connected to PE devices, such as PE 1-PE 3 in fig. 1, of the operator network 20 through CE devices, such as CE 1-CE 3 in fig. 1. The operator network 20 also includes P devices, such as P1 in fig. 1. In fig. 1, H2 and H3 in the user-side network 10 belong to the same VPN, for example VPNa. H1 may send BIER messages to H2 and H3 via the VPNa.
Fig. 2 is a schematic diagram of another network deployment scenario provided in an embodiment of the present application. Fig. 2 differs from fig. 1 in that there are more paths between two PE devices, e.g. PE1a and PE2a in fig. 2, that can be selected. As shown in fig. 2, the operator network 20 includes a plurality of backbone (backbone) devices, such as BB1 to BB4, in addition to the PE devices. In the network shown in fig. 2, hosts included in the user-side network 10, such as H1 to H9 in fig. 2, are divided into 2 VPNs, such as VPNa and VPNb. Wherein VPNa comprises H2, H3, H6-H8, VPNb comprises H1, H4, H5 and H9. When the host in VPNa sends the BIER message, the BIER message is transmitted through BB1 and/or BB4 in the operator network 20. For example, the BIER message of H2 is sent to H6 sequentially through CE1r, PE1a, BB1, BB4, PE2a, and CE2r, or the BIER message of H2 is sent to H7 sequentially through CE1r, PE1a, BB1, BB4, PE4a, and CE4r, or the BIER message of H2 is sent to H8 sequentially through CE1r, PE1a, BB1, BB4, PE4b, and CE5 r.
When the host in VPNb sends the BIER message, it transmits through BB4 in the operator network 20.
The following describes the BIER configuration and transmission procedure using the network shown in fig. 1 as an example:
(1) BIER configuration
BFR-id of H1 is 1, BFR-id of H2 is 2, and BFR-id of H3 is 3.
For PE1, the next hop through to reach a host with BFR-id of 1 is CE1, and the next hop through to reach a host with BFR-id of 2 or BFR-id of 3 is P1. The node of P1 is identified as P1.End. BIER. Vrf.
For P1, the next hop through to reach a host with BFR-id of 1 is PE1, the next hop through to reach a host with BFR-id of 2 is PE2, and the next hop through to reach a host with BFR-id of 3 is PE3. The node identified by node identification PE1.vrf.End.BIER, PE2 of PE1 as node identification PE2.vrf.End.BIER, PE is identified by pe3.vrf.end.bier.
For PE2, the next hop through to reach a host with BFR-id 2 is CE2, and the next hop through to reach a host with BFR-id 1 or a host with BFR-id 3 is P1. The node of P1 is identified as P1.End. BIER. Vrf.
For PE3, the next hop through to reach a host with BFR-id 3 is CE3, and the next hop through to reach a host with BFR-id 1 or a host with BFR-id 2 is P1. The node of P1 is identified as P1.End. BIER. Vrf.
The above-described apparatus generates BIER forwarding tables based on the respective acquired BIER configurations.
(2) BIER transmission
When H1 sends messages to H2 and H3, H1 obtains BitString, such as 0110, based on BFR-ids corresponding to H2 and H3. H1 obtains a first BIER message based on the message and BitString. The first BIER message includes an IPv6 extension header, e.g., an IPv6 destination option header (destination options header, DOH). The IPv6 extension header includes BitString. The payload (payload) in the first BIER message contains messages sent to H2 and H3. The payload includes a user datagram protocol (user datagram protocol, UDP) header. The destination address of the IPv6 header is pe1.Vrf. End. Bier. H1 sends the first BIER message to PE1 through CE 1.
PE1 receives a first BIER message, and determines that the next hop is P1 according to BitString with the value of 0110 in the first BIER message; and the PE1 updates the destination address of the first BIER message from PE1.vrf.end.BIER to P1.end.BIER.vrf to obtain a second BIER message. PE1 sends a second BIER message to P1.
P1 receives a second BIER message, and determines that the next hop is PE2 and PE3 according to BitString with the value of 0110 in the second BIER message; the P1 is duplicated to obtain two second BIER messages, the destination address of one second BIER message is updated to PE2.vrf.end.bier and BitString is updated to 0010, so as to obtain a third BIER message; p1 updates the destination address of another second BIER message to PE3.vrf.end.BIER and BitString to 0100 to obtain a fourth BIER message. P1 sends a third BIER message to PE2 and a fourth BIER message to PE3.
PE2 receives the third BIER message, determines that the next hop is CE2 according to BitString with the value 0010 in the third BIER message, and updates the destination address from PE2.vrf.end.BIER to the address of H2 to obtain a fifth BIER message. PE2 sends the fifth BIER message to H2 via CE 2.
After receiving the fourth BIER message, the PE3 determines that the next hop is CE3 according to BitString with the value of 0100 in the fourth BIER message, and updates the destination address from pe3.vrf.end.bier to the address of H3 to obtain a sixth BIER message; PE2 sends the sixth BIER message to H3 through CE 2.
In the transmission process, the source address of the BIER message is the address of H1, so that in order to ensure that the BIER message can be transmitted between the nodes, the PE devices need to be able to be accessed by the address of H1, and for this reason, configuration needs to be performed on each PE device to allow access by the address of H1. However, when there are a plurality of H1 or H1 addresses, the configuration amount is large, the configuration efficiency is low, and the implementation complexity is high.
For example, when the user side interface of PE1 receives the address with the source address of BIER message being H1 (for example, 2001:: 1), and when the BIER message is transmitted to P1 by PE1, the source address of the BIER message is still the address of H1, and the destination address is one address in 1 of location 2001: db8: ffff: A:: 64. The "network side interface rule" configuration of P1 allows address access for IPv6 address block 2001:db8:ffff:/48 range, and P1 does not allow address access for H1 (because the address of H1 is not in 2001:db8:ffff:/48 range). For this reason, network-side interface rules need to be configured at P1, allowing the address of H1 to be accessed as a source address. Correspondingly, PE2 and PE3 also modify the network side interface rules. It can be seen that, in order to support the transparent transmission of BIERv messages sent by H1 in the network, configuration modification needs to be performed on multiple devices, if multiple hosts, such as H1b/H1c/H1d, all need to send BIERv messages and pass through the network, and addresses of the hosts also change, which may cause a large configuration management burden to a network administrator.
The following is an illustration of a method flow of an embodiment of the present application.
Fig. 3 is a flowchart of a message transmission method according to an embodiment of the present application. The method shown in fig. 3 includes the following steps S201 to S203. The network deployment scenario on which the method shown in fig. 3 is based is optionally as shown in fig. 1 above, in which scenario the method shown in fig. 3 may be performed by an ingress device of an operator network, e.g. by PE1 in fig. 1. The network deployment scenario on which the method shown in fig. 3 is based is optionally as shown in fig. 2 above, in which scenario shown in fig. 2 the method shown in fig. 3 may be performed by an ingress device of the operator network, e.g. by PE1a or PE3a in fig. 2.
S201, the inlet equipment acquires a first BIER message, and the source address of the first BIER message is the address of a first user.
In the network deployment scenario shown in fig. 1, the ingress device may be PE1, and the first user may be H1. For example, H1 sends a first BIER message through VPNa, the first BIER message is transmitted to PE1 through CE1, and PE1 receives the first BIER message. In the network deployment scenario shown in fig. 2, the ingress device may be PE1a or PE3a, and the first user may be any host from H1 to H4. For example, H3 sends a first BIER message through VPNb, which is transmitted to PE3a via CE3b, and PE3a receives the first BIER message.
S202, the entrance device obtains a second BIER message based on the first BIER message, and the source address of the second BIER message is the address of the entrance device corresponding to the address of the first user.
In the implementation manner of the application, the access device can allocate addresses corresponding to the access device for different users, and after receiving BIER messages of different users, the source address of the first BIER message can be updated by adopting the allocated corresponding addresses to obtain the second BIER message. For example, the source address of the first BIER message is the address of H1, and the ingress device modifies this to address 1 of the ingress device corresponding to the address of H1. Illustratively, the ingress device may assign corresponding addresses for the addresses of different users in the network segment corresponding to the IPv 6-based segment routing location identifier (SRv Locator). For example, SRv network segments corresponding to the Locator are 2001:db8:ffff:1: the portal device may assign corresponding addresses 2001:db8:ffff:1::a01 to the addresses of the first user, the portal device may assign corresponding addresses 2001:db8:ffff:1:a 02 to the addresses of the second user, and the portal device may assign corresponding addresses 2001:db8:ffff:1:a 03 to the addresses of the third user.
S203, the inlet device sends a second BIER message.
The inlet device sends the second BIER message to the outlet device, and the outlet device sends the second BIER message to the host of the user side network. In the transmission process, each node distributes the message according to BitString.
Fig. 4 is a flowchart of a message transmission method according to an embodiment of the present application. The method shown in fig. 4 includes the following steps S301 to S303. The network deployment scenario on which the method of fig. 4 is based is optionally as described above in fig. 1, in which scenario the method of fig. 3 may be performed by an egress device of an operator network, e.g. by PE2 or PE3 in fig. 1. The network deployment scenario on which the method of fig. 4 is based is optionally as described above with reference to fig. 2, in which scenario the method of fig. 3 may be performed by an egress device of an operator network, e.g. by PE2a, PE4a or PE4b of fig. 2.
S301, the outlet device acquires a second BIER message, and the source address of the second BIER message is the address of the inlet device.
In the network deployment scenario shown in fig. 1, the egress device may be PE2 and the ingress device may be PE1. For example, PE2 receives a second BIER message sent from PE1 to PE2, where the source address of the second BIER message is the address PE1.Addr of PE1. In the network deployment scenario shown in fig. 2, the egress device may be PE4a and the ingress device may be PE1a. For example, the PE4a receives a second BIER packet sent from the PE1a to the PE4a, where the source address of the second BIER packet is the address PE1a. Addr of the PE1a.
S302, the outlet device obtains a third BIER message based on the second BIER message, and the source address of the third BIER message is the address of the first user corresponding to the address of the inlet device.
In an implementation manner of the present application, the outlet device may obtain correspondence between addresses of different inlet devices and addresses of the first user. After receiving the second BIER message, the outlet device modifies the source address into the address of the corresponding first user. For example, the source address of the second BIER packet is the address pe1.addr of the ingress device PE1, the egress device searches the address H1 with the address H1 corresponding to pe1.addr according to the corresponding relationship, and the egress device modifies the source address in the second BIER packet from pe1.addr to the address H1 with H1.
In the embodiment of the present application, step S302 obtains a third BIER message based on the second BIER message, where the third BIER message is the same as the source address of the first BIER message received by the ingress device.
S303, the outlet device sends a third BIER message.
And the outlet equipment sends the third BIER message to a host of the user side network. For example, in the network deployment scenario shown in fig. 1, PE2 sends a third BIER message to CE2, which CE2 sends to H2.
Fig. 5 is a flowchart of a message transmission method according to an embodiment of the present application. The method shown in fig. 5 includes the following steps S401 to S412. The network deployment scenario on which the method shown in fig. 5 is based is optionally as shown in fig. 1, where the method shown in fig. 5 may be performed by a CE1, PE1, P1, PE2, PE3, CE2, CE3, etc. device. Wherein PE1 is the ingress device and PE2 and PE3 are the egress devices. In the network deployment scenario shown in fig. 1, the first BIER packet transmitted in this embodiment may be a BIERv packet generated by H1, and the address of the first user is the address of H1. In the network deployment scenario shown in fig. 1, the first BIER packet transmitted in this embodiment may also be a BIERv packet obtained after the CE1 encapsulates the received multicast packet, where the address of the first user is the address of the CE1 device. The following describes the flow of the message transmission method by taking BIERv messages generated by transmitting H1 as an example:
S401, PE1 receives the address of H1 transmitted by CE 1.
Wherein PE1 is the ingress device and the address of H1 is the address of the first user. The first user here is a first multicast user, which is VPNa. The address of the first user is the address of the multicast source. The first multicast subscriber may be a public network subscriber in addition to a VPN.
In some possible implementations of the application, CE1 sends an IGP message that includes the address of H1; PE1 receives the IGP message to obtain the address of H1, i.e., the address of the first user. CE1 sends the IGP message to the interface of PE1 corresponding to VPNa, and PE1 receives the IGP message through the interface corresponding to VPNa. Illustratively, the IGP message may be an intermediate system-to-intermediate system (INTERMEDIATE SYSTEM-to-INTERMEDIATE SYSTEM, ISIS) message or an Open Shortest path first (Open Shortest PATH FIRST, OSPF) message. For example, ISIS SRv6 Locator type, length and value (TYPE LENGTH value, TLV) (or TLV 27) and corresponding Sub-TLV, as defined by RFC9352, carry a SRv SID, which SRv SID corresponds to the address of H1. For another example, a SRv6 Locator TLV and corresponding Sub-TLV defined by draft-ietf-lsr-ospfv3-srv6-extensions carries a SRv SID, which SRv SID corresponds to the address of H1. In other possible implementations of the application, CE1 sends a first border gateway protocol (border gateway protocol, BGP) message that includes an address of H1; PE1 receives the first BGP message, thereby obtaining the address of H1, i.e. the address of the first user. For example, the BGP Prefix-SID TLV and corresponding Sub-TLV defined by RFC9252 carry a SRv SID, which SRv SID corresponds to the address of H1. In the IGP message or the first BGP message, the indication information is carried in addition to the address of H1. The indication information is used for indicating that the address of the PE1 'H1 needs to be used as a multicast source address' so as to facilitate the PE1 to open the address access authority of the address of the H1, namely, allow the message with the source address of the H1 and the destination address of the PE1.Vrf. End. Bier to be received from the interface corresponding to VPNa of the PE1 without discarding. Meanwhile, the indication message is also used for indicating the PE1 to allocate a corresponding address for the address of the H1. By carrying the indication information in the IGP message or the first BGP message, the ingress device PE1 may automatically allow access to the address of the H1 by using the indication information, without manually configuring on the ingress device, and pushing the configuration procedure from PE1 to the more marginal CE1. For example, the IGP message or the first BGP message includes BIERv-VPN SENDER, BIERV6-VPN SENDER, also referred to as the foregoing indication information.
S402, PE1 allocates a corresponding address to the address of H1.
After the PE1 acquires the address of the H1, determining that the address of the H1 is the address of the first user sending the BIER message based on the indication information, and allocating the address of the corresponding PE1 to the address of the H1 by the PE 1. Illustratively, PE1 assigns a corresponding address to the address of H1 in a network segment corresponding to the IPv 6-based segment routing location identifier (SRv Locator). For example, PE1 assigns a corresponding address to the address of H1 in the 2001:db8:ffff:1:64 network segment. The address is in the range of IPv6 address block 2001:db8:ffff:48, and P1, PE2, PE3, etc. all allow the address to be accessed.
When the PE1 receives the addresses of the plurality of first users, the addresses of the corresponding entrance devices are respectively allocated to the addresses of the plurality of first users. The plurality of first users may be hosts in the same VPN, or the plurality of first users may be hosts in different VPNs, or the plurality of first users may include hosts in the same VPN, or may include hosts in different VPNs. Illustratively, PE1 may assign a corresponding address 2001:db8:ffff:1 to address H1 of H1 of VPNa:: a01; PE1 may assign corresponding addresses 2001:db8:ffff:1:a 1a to address H1a of H1a of VPNa; PE1 may assign a corresponding address 2001:db8:ffff:1:b 1b to address H1b of H1b of VPNb.
S403, PE1 obtains the corresponding relation between the address of H1 and the address of PE1 based on the address of H1 and the address of PE1 allocated.
The correspondence may include correspondence of one or more addresses of the first user and addresses of the portal device. Illustratively, on the basis of step S402, the correspondence obtained by PE1 includes: the correspondence of the address H1 of H1 of VPNa and the address 2001:db8:ffff:1 of PE 1: a 01; the correspondence of the address H1a of H1a of VPNa to the address 2001:db8:ffff:1 of PE 1: a1 a; the correspondence of the address H1b of H1b of VPNb to the address 2001:db8:ffff:1 of PE 1:b 1 b.
S404, PE1 sends the correspondence to PE2 and PE 3.
Illustratively, PE1 sends a second BGP message that includes the correspondence; PE2 and PE3 receive the second BGP message, so as to obtain the corresponding relation between the address of H1 and the address of PE1, namely, the corresponding relation between the address of the first user and the address of the entrance device.
In one example, the second BGP message may be a BGP-VPNv6 routing message. BGP-VPNv6 routing messages are defined in RFC4364 and RFC4659, using sub-address family (SAFI) value 128 defined in RFC4364, and IPv6 address family (ADDRESS FAMILY IDENTIFIER, AFI) value 2 and VPN IPv6 network layer reachability information (network layer reachability information, NLRI) Encoding (Encoding) message Encoding formats described by RFC 4659. An address Prefix1 is included in the NLRI, and a label such as a routing label (route distinguisher, RD) is distinguished VPNa on the PE1, where the Prefix1 covers an address H1 of H1, for example, the H1 address is 2001:1, the Prefix1 is 2001:48 or 2001:32, and the NLRI can be used as a key value of a message. BGP-VPNv6 routing messages also contain other attributes, such as: a Route Target (RT) attribute from which the node receiving the message, e.g., PE2/PE3, determines to which VPN (e.g., VPNa) the message corresponds; the extended community (extended community, EC) attribute is used to carry the address pe1.addr1 of PE1. By carrying the address of Prefix1 corresponding to H1 on NLRI of BGP-VPNv6 and carrying the address of PE1 on EC attribute, the corresponding relationship between the address of H1 and the address of PE1 can be sent to PE2 and PE3.
H1 in the correspondence belongs to VPNa, and the correspondence may further include an identifier of VPNa, that is, the correspondence may be expressed as (VPNa, H1, pe1. Addr).
In another example, the second BGP message may be a BGP-EVPN routing message. Similar to the BGP-VPNv6 routing message, the BGP-EVPN routing message also includes an NLRI and other attributes, and carries the address of H1 in the NLRI and the address of PE1 in the other attributes, so as to implement the sending of the correspondence.
In another example, the second BGP message may be a new BGP v6-VPN address family message. In addition to BGP-VPNv6 and BGP-EVPN mentioned above, new SAFI (i.e., sub address family) and AFI (i.e., address family) may be defined to convey the above correspondence, which is not described herein.
In some possible implementations of the present application, the PE1 sends the second BGP message to the PE2 and the PE3 through the P1, so as to implement the foregoing correspondence transmission. In another possible implementation manner of the present application, the network deployment scenario shown in fig. 1 further includes a Route Reflector (RR), where the RR is connected to PE1, PE2 and PE3, and the PE1 sends a second BGP message to PE2 and PE3 through the RR, so as to implement transmission of the foregoing correspondence.
After receiving BGP messages, PE2 and PE3 obtain prefixes corresponding to addresses of H1 through NLRI, and obtain addresses of PE1 through other attributes, so as to obtain correspondence between addresses of H1 and addresses of PE1.
S405, a CE1 sends a first BIER message, and the source address of the first BIER message is the address of H1; PE1 receives the first BIER message.
Illustratively, the first BIER message may be a BIERv message generated by H1, where the address of H1 is the IPv6 address of H1.
S406, the PE1 determines the address of the PE1 corresponding to the source address of the first BIER message based on the corresponding relation between the address of the H1 and the address of the PE 1.
PE1 obtains the source address, i.e., the address of H1, from the first BIER message. The PE1 queries the corresponding relationship by using H1, determines the address of the corresponding PE1, and executes the subsequent step S407. If not, step S407 is not executed, but forwarding of BIER message is performed.
In one example, the BIER message format referred to in embodiments of the present application is IPv6 based.
Fig. 6 is a diagram illustrating a BIER message format according to an embodiment of the present application. Referring to fig. 6, the BIER message includes an IPv6 header, a DOH header, and a payload (payload).
The IPv6 header includes a source address and a destination address (not shown). The DOH Header includes a Next Header (Next Header), an extension Header length (Ext Hdr Len), an Option Type (Option Type), an Option field length (Opt Data Len), and BIER Option Data (BIER Option Data).
Wherein BIER Option Data is also referred to as BIER header. The BIER Option Data, the Option Type and the Opt Data Len form an Option TLV format, the BIER Option Data is used as a value in the Option TLV, the Option Type in the Option TLV is identified as BIER, and the Option Data Len in the Option TLV is used for identifying the Option length.
The embodiment of the application does not limit the BIER Option Data format in DOH, and the BIER Option Data contains BitString fields, bitString is used for BIER forwarding.
In the message transmission method shown in fig. 5, the message format shown in fig. 6 may be used for both the first BIER message and other BIER messages in subsequent steps.
In the first BIER packet, the source address is H1, and the destination address is PE1.vrf.End.BIER, bitString =0110. 0110 indicates that the first BIER message needs to be sent to H2 and H3.
S407, PE1 obtains a second BIER message based on the first BIER message and the address of PE 1.
After the PE1 determines the address of the corresponding PE1, modifying the source address of the first BIER message into the determined address of the PE1 to obtain a second BIER message. Optionally, in the process of obtaining the second BIER message on the basis of the first BIER message, other contents of the first BIER message may be modified, for example, a destination address, a Time To Live (TTL) of the first BIER message may be modified, in addition to the source address.
The source address and the destination address in the IPv6 header of the second BIER message are different from the source address and the destination address in the IPv6 header of the first BIER message.
In the second BIER message in step S407, the source address is the address PE1.Addr of PE1, and the destination address is P1.End.BIER.vrf, bitString =0110.
S408, PE1 sends a second BIER message; p1 receives the second BIER message.
After the PE1 obtains the second BIER message, according to BitString in the second BIER message, determining that the next hop is P1, and sending the second BIER message to P1.
S409, P1 obtains a third BIER message and a fourth BIER message based on the second BIER message, and sends the third BIER message and the fourth BIER message; PE2 receives the third BIER message, and PE3 receives the fourth BIER message.
After receiving the second BIER message, P1 determines that the next hop is PE2 and PE3 according to BitString (0110) in the second BIER message.
In the query process, P1 determines that the destination H2, H3 is not on its own private network interface according to BitString, so that the multicast state of P1 is an intermediate node state (also referred to as a Transit state) of BIER multicast, and the state is different from an Ingress (Ingress) state or an Egress (Egress) state of BIER multicast. In this state, P1 does not need to modify the source address of the second BIER message. That is, in the embodiment of the present application, the device in the operator network determines whether the destination host is on its own private network side interface based on BitString in the second BIER packet; if not, the source address of the second BIER message does not need to be modified. If so, the source address of the second BIER message needs to be modified.
And P1 copies two second BIER messages, and updates the destination address of one second BIER message to PE2.vrf.end.bier and BitString to 0010 to obtain a third BIER message. P1 updates the destination address of another second message BIER message to PE3.vrf.end.BIER and BitString to 0100 to obtain a fourth BIER message. Third BIER message: the source address is PE1 address pe1.addr and the destination address is PE2.vrf.End.BIER, bitString =0010. Fourth BIER message: the source address is PE1 address pe1.addr and the destination address is PE3.vrf.End.BIER, bitString =0100. P1 sends a third BIER message to PE2 and a fourth BIER message to PE3.
The processing manner of the third BIER message by the PE2 is the same as the processing manner of the fourth BIER message by the PE3, so that the subsequent steps are described by taking the PE3 as an example, and the processing procedure of the PE2 refers to the PE3 and will not be described in detail.
S410, PE3 determines the address of H1 corresponding to the source address of the fourth BIER message based on the corresponding relation.
After the PE3 obtains the fourth BIER message, determining that the next hop is CE3 according to BitString with the value of 0100 in the fourth BIER message.
In the query process, the PE3 determines, according to BitString, that the destination H3 is on its own private network interface, so that the multicast state of the PE3 is an Egress (Egress) state, and in this state, the PE3 needs to modify the source address of the fourth BIER packet. PE3 obtains the source address from the fourth BIER message, adopts the source address of the fourth BIER message to query the corresponding relationship, determines the corresponding H1 address, and executes the subsequent step S411.
S411, PE3 obtains a fifth BIER message based on the fourth BIER message and the determined H1 address.
And after the PE3 determines the corresponding H1 address, modifying the source address of the fourth BIER message into the determined H1 address to obtain a fifth BIER message.
Optionally, in the process of obtaining the fifth BIER message on the basis of the fourth BIER message, other contents of the fourth BIER message may be modified, for example, a destination address, a TTL, etc. of the fourth BIER message may be modified, in addition to the source address.
In the fifth BIER message in step S411, the source address is H1, the destination address is H3, bitString =0100, and the destination address is H3.
S412, PE3 sends a fifth BIER message; CE3 receives the fifth BIER message.
In step S410, the PE3 determines that the next hop is CE3, and after obtaining the fifth BIER message, the PE3 sends the fifth BIER message to CE3. And after the CE3 receives the fifth BIER message, forwarding the fifth BIER message to H3.
In any of the embodiments provided herein, the "first BIER message," "second BIER message," … … "fifth BIER message," etc. are used to distinguish between different BIER messages. In different embodiments provided in the present application, the messages with the same names may be the same BIER messages, and the messages with the same names may also be different BIER messages, for example, the "first BIER message" in the embodiment corresponding to fig. 3 is the same as the "first BIER message" in the embodiment corresponding to fig. 5, and the "third BIER message" in the embodiment corresponding to fig. 4 is different from the "third BIER message" in the embodiment corresponding to fig. 5.
In the message transmission method shown in fig. 5, the ingress device PE1 sends the correspondence between the address of H1 and the address of PE1 to the egress devices PE2 and PE3 through BGP messages, so that the PE2 and PE3 can update the source addresses of the third BIER message and the fourth BIER message from the address of PE1 to the address of H1 according to the obtained correspondence, and then distribute the updated source addresses to CE2 and CE3, and further send the updated source addresses to the destinations H2 and H3.
In another message transmission method provided by the embodiment of the present application, the source address of the second BIER message is the address of PE1, and the ingress device PE1 may further carry the address of H1 in the second BIER message, for example, an IPv6 extension header carried in the second BIER message; or carried in the DOH header of the second BIER message. In this way, the egress device PE2 may obtain the address of H1 from the third BIER packet, and the egress device PE3 may obtain the address of H1 from the fourth BIER packet. This message transmission method is described below with reference to fig. 7: fig. 7 is a flowchart of another message transmission method according to an embodiment of the present application.
The method shown in fig. 7 comprises the steps of:
s501, CE1 sends an address of H1; PE1 receives the address of H1 sent by CE 1.
S502, PE1 allocates a corresponding address for the address of H1.
S503, PE1 obtains the corresponding relation between the address of H1 and the address of PE1 based on the address of H1 and the address of allocated PE 1.
S504, CE1 sends a first BIER message, and the source address of the first BIER message is the address of H1; PE1 receives the first BIER message.
The first BIER message in step S504 may be in the BIER message format shown in fig. 6, which is not described herein.
S505, the PE1 determines the address of the PE1 corresponding to the source address of the first BIER message based on the corresponding relation between the address of the H1 and the address of the PE 1.
Steps S501-S505 may refer to the descriptions in steps S401-S403 and steps S405-S406 in the corresponding embodiment of fig. 5, and are not described herein.
S506, the PE1 obtains a second BIER message based on the first BIER message, the determined address of the PE1 and the determined address of the H1.
After determining the address of the corresponding PE1, the PE1 modifies the source address of the first BIER message into the address of the PE1, and carries the address of H1 in an IPv6 extension header or a DOH header of the first BIER message to obtain a second BIER message. Optionally, in the process of obtaining the second BIER message based on the first BIER message, other contents of the first BIER message may be modified, for example, a destination address, a TTL, etc. of the first BIER message may be modified.
Since in step S506, an additional H1-carrying address is required, for example, the new option field in the DOH header carries the H1 address, the format of the second BIER message is changed from that of the first BIER message. The format of the second BIER message is described below with reference to fig. 8:
Fig. 8 is a diagram illustrating another BIER message format according to an embodiment of the present application. Referring to fig. 8, the BIER message includes an IPv6 header, a DOH header, and a payload (payload).
The IPv6 header includes a source address and a destination address (not shown). The DOH Header includes a Next Header (Next Header), an extension Header length (Ext Hdr Len), an Option Type (Option Type), an Option field length (Opt Data Len), and BIER Option Data (BIER Option Data).
Wherein BIER Option Data is also referred to as BIER header. The BIER Option Data, the Option Type and the Opt Data Len form an Option TLV format, the BIER Option Data is used as a value in the Option TLV, the Option Type in the Option TLV is identified as BIER, and the Option Data Len in the Option TLV is used for identifying the Option length.
The embodiment of the application does not limit the BIER Option Data format in DOH, and the BIER Option Data contains BitString fields, bitString is used for BIER forwarding.
The DOH header of the BIER message shown in fig. 8 includes an option to carry the source address (SRCADDRESS) in addition to the option to carry BIER as in the DOH header of the BIER message shown in fig. 6.
As shown in fig. 8, the options carrying the source address correspond to the Option Type (SRCADDRESS), opt Data Len, opt Data fields. The Option Data carrying the Option of the source address includes an IPv6 address field, which is used for carrying the source address, that is, the address of H1, and the Option Type is used for identifying that the Option Type is SRCADDRESS, and the Opt Data Len is used for identifying the Option length. The Option Data (IPv 6 address) shown in fig. 8 is a field, and is shown only for the purpose of showing the length of the field.
Optionally, the DOH header of the BIER message shown in fig. 8 may also include a padding (PadN) option.
The fill Option corresponds to the Option Type (PadN), opt Data Len, and Option Data fields. This padding option is defined in RFC8200 to ensure DOH header 8 byte alignment. Option Data for a fill Option contains fill Data, option Type is used to identify the Option Type as PadN, and Opt Data Len is used to identify the Option length.
In one example, the BIER Option Data is 44 bytes, the SRCADDRESS Option Data is 16 bytes, the PadN Option Data is 4 bytes, the Next Header, ext Hdr Len, option Type, opt Data Len fields are all 1 byte, the length of the whole DOH Header is 72 bytes, and the 8 byte alignment of the DOH Header is ensured.
In the second BIER message in step S506, the source address is PE1 address PE1.Addr, the destination address is P1.End.BIER.vrf, bitString =0110, and the DOH header further carries H1 address H1, which is indicated as, for example, DOH header < source=h1 >.
S507, PE1 sends a second BIER message; p1 receives the second BIER message.
S508, P1 obtains a third BIER message and a fourth BIER message based on the second BIER message, and sends the third BIER message and the fourth BIER message; PE2 receives the third BIER message, and PE3 receives the fourth BIER message.
The third BIER message and the fourth BIER message in step S508 may be in the BIER message format shown in fig. 8, which is not described herein.
Steps S507 to S508 may refer to the descriptions in steps S408 to S409 in the corresponding embodiment of fig. 5, and are not described herein.
S509, PE3 obtains the address of H1 based on the fourth BIER message.
PE3 resolves the address of H1 from the fourth BIER message, for example, if the DOH header carries the address H1 of H1, PE3 resolves the address of H1 from the DOH header of the fourth BIER message. For example, if the IPv6 extension header carries the address H1 of H1, the PE3 resolves the address of H1 from the IPv6 extension header of the fourth BIER packet.
PE3 has been previously configured or contracted to obtain the address of H1 from where the fourth BIER message is.
S510, PE3 obtains a fifth BIER message based on the fourth BIER message and the determined H1 address.
In step S510, when obtaining the fifth BIER message based on the fourth BIER message, the PE3 may remove the option and/or the padding option carrying the source address in the fourth BIER message, in addition to modifying the fields such as the source address, the destination address, the TTL, etc. Illustratively, the fifth BIER message may be in a BIER message format shown in fig. 6, which is not described herein.
S511, PE3 sends a fifth BIER message; CE3 receives the fifth BIER message.
Steps S510 to S511 may refer to the descriptions in steps S411 to S412 in the corresponding embodiment of fig. 5, and are not described herein.
Fig. 9 is a flowchart of another message transmission method according to an embodiment of the present application. The method shown in fig. 9 includes the following steps S601 to S613. The network deployment scenario on which the method shown in fig. 9 is based is optionally as shown in fig. 2 above, and in the scenario shown in fig. 2, CE1r, CE2r, CE3r, CE4r and CE5r belong to VPNa, CE1b, CE2b, CE3b and CE4b belong to VPNb. PE1a, PE2a, PE3a and PE4b are each configured with VRFs VPNa and VPNb, and PE4a is configured with VRFs VPNa. BB1 and BB4 can be used as VPNa forwarding nodes, for example, the next hop of BIER message sent by PE1a to VPNa is BB1, the next hop of BB1 is BB4, and BB4 is sent to PE2a, PE4a and PE4b. BB4 can be used as VPNb forwarding node, for example, the next hop of BIER message sent by PE1a to VPNb is BB4, and BB4 is sent to PE2a and PE4b again. The method shown in fig. 9 may be performed by a CE1r, PE1a, BB1, BB4, PE2a, PE4b, CE2r, CE4r, CE5r, or the like. Wherein PE1a is an inlet device, and PE2a, PE4b are outlet devices. In the network deployment scenario shown in fig. 2, in the packet transmission method provided in fig. 9, the transmitted first BIER packet may be a BIERv packet generated by H2, and the address of the first user is the address of H2. In the network deployment scenario shown in fig. 2, in the packet transmission method provided in fig. 9, the transmitted first BIER packet may also be BIERv packet after the CE1r encapsulates the received user multicast packet, where the address of the first user is an address on the CE1r device. The following describes the flow of the message transmission method by taking BIERv message generated by transmitting H2 as an example:
s601, CE1r sends an address of H2; PE1a receives the address of H2 sent by CE 1.
S602, PE1a assigns a corresponding address to the address of H2.
S603, the PE1a obtains the corresponding relation between the address of the H2 and the address of the PE1a based on the address of the H2 and the address of the allocated PE 1.
S604, PE1a sends the corresponding relation; PE2a, PE4b receive the correspondence.
S605, CE1r sends a first BIER message, and the source address of the first BIER message is the address of H2; PE1a receives the first BIER message.
S606, the PE1a determines the address of the PE1a corresponding to the source address of the first BIER message based on the corresponding relation between the address of the H2 and the address of the PE1 a.
In the message transmission method shown in fig. 9, the message format shown in fig. 6 may be used for both the first BIER message and other BIER messages in subsequent steps. In the first BIER packet, the source address is H2, and the destination address is PE1a.vrf.End.BIER, bitString =11100. 11100 indicates that the BIER message needs to be sent to H6, H7, and H8.
S607, PE1a obtains a second BIER message based on the first BIER message and the determined address of PE1 a.
The source address and the destination address in the IPv6 header of the second BIER message are different from the source address and the destination address in the IPv6 header of the first BIER message.
In the second BIER message in step S607, the source address is PE1 address pea. Addr, and the destination address is BB1.End.BIER.vrf, bitString =11100.
S608, PE1a sends a second BIER message; BB1 receives the second BIER message.
Steps S601 to S608 may refer to the descriptions in steps S401 to S408 in the corresponding embodiment of fig. 5, and are not described herein.
S609, BB1 sends a third BIER message; BB4 receives the third BIER message.
After receiving the second BIER message, BB1 queries the routing table according to BitString (11100) in the second BIER message, and determines that the next hop is BB4.
In the query process, the BB1 determines according to BitString that the destination H6, H7, and H8 are not on its own private network side interface, so that the multicast state of the BB1 is a transmission (Transit) state, where the BB1 does not need to modify the source address of the second BIER packet.
Optionally, the BB1 may modify other contents of the second BIER packet, for example, modify a destination address, TTL, etc. of the second BIER packet, so as to obtain the third BIER packet.
In the third BIER message in step S609, the source address is PE1 address pea. Addr, and the destination address is BB4.End.BIER.vrf, bitString =11100.
S610, BB4 obtains a fourth BIER message, a fifth BIER message and a sixth BIER message based on the fourth BIER message, and sends the fourth BIER message, the fifth BIER message and the sixth BIER message; PE2a receives the fourth BIER message, PE4a receives the fifth BIER message, and PE4b receives the sixth BIER message.
After receiving the third BIER packet, BB4 queries the routing table according to BitString (11100) in the third BIER packet, and determines that the next hop is PE2a, PE4a, and PE4b.
In the query process, the BB4 determines according to BitString that the destination H6, H7, and H8 are not on its own private network side interface, so that the multicast state of the BB4 is a transmission (Transit) state, where the BB4 does not need to modify the source address of the third BIER packet.
BB4 replicates out three third BIER messages, and updates the destination address of one third BIER message to PE2a. Vrf. End. BIER and BitString to 00100 to obtain a fourth BIER message. BB4 updates the destination address of another third BIER message to PE4a.vrf.end.BIER and BitString to 01000 to obtain a fifth BIER message. BB4 updates the destination address of the third BIER message to PE4b.vrf.end.BIER and BitString to 100000 to obtain a sixth BIER message. Fourth BIER message: the source address is PE1a address PE1a. Addr and the destination address PE2a.vrf.End.BIER, bitString =00100. Fifth BIER message: the source address is PE1a address PE1a. Addr and the destination address PE4a.vrf.End.BIER, bitString =01000. Sixth BIER message: the source address is PE1a address PE1a. Addr and the destination address PE4b.vrf.End.BIER, bitString =10000. BB4 sends the fourth BIER message to PE2a, the fifth BIER message to PE4a, and the sixth BIER message to PE4b.
The processing manner of the fifth BIER message by the PE4a and the processing manner of the sixth BIER message by the PE4b are the same as the processing manner of the fourth BIER message by the PE2a, so that the subsequent steps are described by taking the PE2a as an example, and the processing procedures of the PE4a and the PE4b refer to the PE2a and are not described in detail.
S611, PE2a determines the address of H2 corresponding to the source address of the fourth BIER message based on the corresponding relation between the address of H2 and the address of PE1 a.
S612, PE2a obtains a seventh BIER message based on the fourth BIER message and the determined H2 address.
In the seventh BIER message in step S611, the source address is H2, and the destination address is H6, bitString =00100, which is H6.
S613, PE2a sends a seventh BIER message; CE2r receives the seventh BIER message.
In step S610, the PE2a determines that the next hop is CE2r, and after obtaining the first BIER message, the PE2a sends a seventh BIER message to the CE2r. And after receiving the seventh BIER message, the CE2r forwards the seventh BIER message to H6.
Steps S611 to S613 can refer to the descriptions in steps S409 to S412 in the corresponding embodiment of fig. 5, and are not described herein.
In the message transmission method shown in fig. 9, the ingress device PE1a sends the correspondence between the address of H2 and the address of PE1a to the egress devices PE2a, PE4a, and PE4b through BGP messages, so that the PE2a, PE4a, and PE4b can update the source address of the fourth BIER message, the fifth BIER message, and the sixth BIER message from the address of PE1a to the address of H2 according to the obtained correspondence, and then distribute the updated source address to CE2r, CE4r, and CE5r, and then send the updated source address to the destinations H6, H7, and H8.
In another message transmission method provided by the embodiment of the present application, the source address of the second BIER message is the address of PE1a, and the ingress device PE1 may further carry the address of H2 in the second BIER message, for example, an IPv6 extension header carried in the second BIER message; or carried in the DOH header of the second BIER message. Thus, the egress device PE2a may obtain the address of H2 from the fourth BIER message, the egress device PE4a may obtain the address of H2 from the fifth BIER message, and the egress device PE4b may obtain the address of H2 from the sixth BIER message. This message transmission method is described below with reference to fig. 10: fig. 10 is a flowchart of another message transmission method according to an embodiment of the present application. The method shown in fig. 10 includes the steps of:
S701, CE1r sends the address of H2; PE1a receives the address of H2 sent by CE 1.
S702, PE1a assigns a corresponding address to the address of H2.
S703, PE1a obtains a correspondence between the address of H2 and the address of PE1a based on the address of H2 and the address of the assigned PE 1.
S704, CE1r sends a first BIER message, and the source address of the first BIER message is the address of H2; PE1a receives the first BIER message.
The first BIER message in step S704 may be in the BIER message format shown in fig. 6, which is not described herein.
S705, the PE1a determines, based on the correspondence between the address of H2 and the address of PE1a, the address of PE1a corresponding to the source address of the first BIER packet.
Steps S701 to S705 may refer to the descriptions in steps S401 to S403 and steps S405 to S406 in the corresponding embodiment of fig. 5, and are not described herein.
S706, the PE1a obtains a second BIER message based on the first BIER message, the determined address of the PE1a and the determined address of the H2.
After determining the address of the corresponding PE1a, modifying the source address of the first BIER message into the determined address of the PE1a, and carrying the address of H2 in the IPv6 extension header or the DOH header to obtain a second BIER message. Optionally, in the process of obtaining the second BIER message based on the first BIER message, other contents of the first BIER message may be modified, for example, a destination address, a TTL, etc. of the first BIER message may be modified.
Since in step S506, an additional H1-carrying address is required, for example, the new option field in the DOH header carries the H2 address, the format of the second BIER message is changed from that of the first BIER message.
The second BIER message in step S706 may be in the BIER message format shown in fig. 8, which is not described herein.
In the second BIER message in step S706, the source address is PE1a address pea. Addr, the destination address is BB1.End.BIER.vrf, bitString =11100, and the DOH header further carries H2 address H2, which is indicated as, for example, DOH header < source=h2 >.
S707, PE1a sends a second BIER message; BB1 receives the second BIER message.
Step S707 may refer to the description in step S408 in the corresponding embodiment of fig. 5, which is not described herein.
S708, BB1 sends a third BIER message; BB4 receives the third BIER message.
S709 and BB4 obtain a fourth BIER message, a fifth BIER message and a sixth BIER message based on the fourth BIER message, and send the fourth BIER message, the fifth BIER message and the sixth BIER message; PE2a receives the fourth BIER message, PE4a receives the fifth BIER message, and PE4b receives the sixth BIER message.
The third BIER message, the fourth BIER message, the fifth BIER message, and the sixth BIER message in steps S708-S709 may be in the BIER message format shown in fig. 8, and are not described herein.
Steps S708 to S709 may refer to the descriptions in steps S608 to S609 in the corresponding embodiment of fig. 9, and are not described herein.
S710, PE2a obtains the address of H2 based on the fourth BIER message.
PE2a resolves the address of H2 from the second BIER message, for example, if the DOH header carries the address H2 of H2, PE2a resolves the address of H2 from the DOH header of the second BIER message.
S711, PE2a obtains a seventh BIER message based on the fourth BIER message and the determined H2 address.
In step S711, when obtaining the seventh BIER message based on the fourth BIER message, the PE2a may remove the option and/or the padding option carrying the source address in the fourth BIER message, in addition to modifying the fields such as the source address, the destination address, the TTL, etc. Illustratively, the seventh BIER message may be in a BIER message format shown in fig. 6, which is not described herein.
S712, PE2a sends a seventh BIER message; CE2r receives the seventh BIER message.
Steps S710 to S712 may refer to the descriptions in steps S410 to S412 in the corresponding embodiment of fig. 5, and are not described herein.
Fig. 11 is a block diagram of a message transmission device according to an embodiment of the present application. The message transmitting means may be implemented as all or part of the portal device by software, hardware or a combination of both. The message transmission apparatus 800 may include: an acquisition unit 801, a processing unit 802, and a transmission unit 803.
The obtaining unit 801 is configured to obtain a first bit index based explicit copy BIER packet, where a source address of the first BIER packet is an address of a first user;
A processing unit 802, configured to obtain a second BIER packet based on the first BIER packet, where a source address of the second BIER packet is an address of an entry device corresponding to an address of the first user;
a sending unit 803, configured to send a second BIER packet.
Optionally, the processing unit 802 is configured to obtain an address of the entry device based on the address of the first user and a corresponding relationship, where the corresponding relationship includes the address of the first user and the address of the entry device; and obtaining a second BIER message based on the first BIER message and the address of the access device.
Optionally, the acquiring unit 801 is further configured to acquire an address of the first user; the processing unit is further used for distributing the address of the corresponding entrance equipment to the address of the first user in the network segment corresponding to the segment routing position identification based on the IPv 6; and obtaining a corresponding relation based on the address of the first user and the address of the entrance equipment.
Optionally, the obtaining unit 801 is configured to receive an IGP message of an interior gateway protocol or a BGP message of a first border gateway protocol, where the IGP message or the BGP message includes an address of the first user.
Optionally, the sending unit 803 is further configured to send a second BGP message to the egress device, where the second BGP message includes the correspondence.
Optionally, the second BIER message further includes the address of the first user.
Optionally, the IPv6 extension header of the second BIER message includes an address of the first user; or the DOH header of the second BIER message includes the address of the first user.
In operation, the message transmission device provided in the above embodiment is only exemplified by the above division of each functional unit, and in practical application, the above functional allocation may be performed by different functional units according to needs, that is, the internal structure of the device is divided into different functional units, so as to complete all or part of the functions described above. In addition, the message transmission device and the message transmission method provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are detailed in the method embodiments and are not repeated herein.
Fig. 12 is a block diagram of a message transmission device according to an embodiment of the present application. The message transmitting means may be implemented as all or part of the egress device by software, hardware or a combination of both. The message transmission apparatus 900 may include: an acquisition unit 901, a processing unit 902, and a transmission unit 903.
The acquiring unit 901 is configured to acquire a second bit index based explicit copy BIER packet, where a source address of the second BIER packet is an address of the ingress device;
A processing unit 902, configured to obtain a first BIER packet based on the second BIER packet, where a source address of the first BIER packet is an address of a first user corresponding to an address of the ingress device;
a sending unit 903, configured to send a first BIER packet.
Optionally, the processing unit 902 is configured to obtain an address of the first user based on an address of the entry device and a correspondence relationship, where the correspondence relationship includes the address of the entry device and the address of the first user; and obtaining the first BIER message according to the second BIER message and the address of the first user.
Optionally, the obtaining unit 901 is further configured to receive a BGP message of a border gateway protocol sent by the ingress device, where the BGP message includes a correspondence.
Optionally, the second BIER message further includes the address of the first user.
Optionally, the IPv6 extension header of the second BIER message includes the address of the first user, or the DOH header of the second BIER message includes the address of the first user.
Optionally, the processing unit 902 is configured to obtain an address of the first user based on the second BIER packet; and obtaining the first BIER message based on the second BIER message and the address of the first user.
In operation, the message transmission device provided in the above embodiment is only exemplified by the above division of each functional unit, and in practical application, the above functional allocation may be performed by different functional units according to needs, that is, the internal structure of the device is divided into different functional units, so as to complete all or part of the functions described above. In addition, the message transmission device and the message transmission method provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are detailed in the method embodiments and are not repeated herein.
The descriptions of the processes corresponding to the drawings have emphasis, and the descriptions of other processes may be referred to for the parts of a certain process that are not described in detail.
The embodiment of the application also provides a message transmission system. The message transmission system comprises an ingress device, which may comprise the message transmission apparatus shown in fig. 11, and an egress device, which may comprise the message transmission apparatus shown in fig. 12.
Fig. 13 is a schematic structural diagram of a network device 1000 according to an embodiment of the present application. The network device 1000 may be the aforementioned ingress or egress device, the network device 1000 comprising at least one processor 1001, memory 1002, and at least one network interface 1003.
Alternatively, the network device 1000 shown in fig. 13 is a PE device in fig. 1 or fig. 2, as viewed in connection with the network deployment scenario shown in fig. 1 or fig. 2.
Optionally, in conjunction with the flow of the method shown in fig. 3, the network device 1000 shown in fig. 13 is configured to perform the method shown in fig. 3, the network interface 1003 is configured to support the network device to obtain a message in S201, send the message in S203, and the processor 1001 is configured to support the network device to perform S202.
Optionally, in conjunction with the flow of the method shown in fig. 4, the network device 1000 shown in fig. 13 is configured to perform the method shown in fig. 4, the network interface 1003 is configured to support the network device to obtain a message in S301, send the message in S303, and the processor 1001 is configured to support the network device to perform S302.
The processor 1001 is, for example, a general-purpose central processing unit (central processing unit, CPU), a network processor (network processer, NP), a graphics processor (graphics processing unit, GPU), a neural-network processor (neural-network processing units, NPU), a data processing unit (data processing unit, DPU), a microprocessor, or one or more integrated circuits for implementing aspects of the present application. For example, the processor 1001 includes an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. PLDs are, for example, complex programmable logic devices (complex programmable logic device, CPLD), field-programmable gate arrays (FPGAs), general-purpose array logic (GENERIC ARRAY logic, GAL), or any combination thereof.
The Memory 1002 is, for example, but not limited to, a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, as well as a random access Memory (random access Memory, RAM) or other type of dynamic storage device that can store information and instructions, as well as an electrically erasable programmable read-only Memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ-only Memory, EEPROM), compact disc read-only Memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Alternatively, the memory 1002 may exist separately and be connected to the processor 1001 through the internal connection 1004. Or alternatively the memory 1002 and the processor 1001 may be integrated.
The network interface 903 uses any transceiver-like device for communicating with other apparatus or communication networks. The network interface 903 includes at least one of a wired network interface or a wireless network interface, for example. The wired network interface is, for example, an ethernet interface. The ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a cellular network interface, a combination thereof, or the like.
In some embodiments, processor 1001 includes one or more CPUs, such as CPU0 and CPU1 shown in fig. 13.
In some embodiments, network device 1000 optionally includes multiple processors, such as processor 1001 and processor 1005 shown in fig. 13. Each of these processors is, for example, a single-core processor (single-CPU), and is, for example, a multi-core processor (multi-CPU). A processor herein may optionally refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).
In some embodiments, network device 1000 also includes internal connection 1004. The processor 1001, the memory 1002 and the at least one network interface 1003 are connected by an internal connection 1004. The internal connections 1004 include pathways that communicate information between the components described above. Optionally, the internal connection 1004 is a board or bus. Optionally, the internal connections 1004 are divided into address buses, data buses, control buses, and the like.
In some embodiments, the network device 1000 also includes an input-output interface 1006. The input-output interface 1006 is connected to the internal connection 1004.
In some embodiments, the input/output interface 1006 is configured to connect with an input device, and receive a command or data related to the above method embodiment, such as a setting command, an expected result of the setting command, a regular expression corresponding to the setting command, address information corresponding to the forensic server, a setting string, and so on, which are input by a user through the input device.
Alternatively, the processor 1001 implements the method in the above embodiment by reading the program code 1010 stored in the memory 1002, or the processor 1001 implements the method in the above embodiment by internally storing the program code. In the case where the processor 1001 implements the method in the above embodiment by reading the program code 1010 stored in the memory 1002, the program code implementing the method provided by the embodiment of the present application is stored in the memory 1002.
For more details on the implementation of the above-described functions by the processor 1001, reference is made to the description of the previous method embodiments, which is not repeated here.
Fig. 14 is a schematic hardware structure of another network device 1200 according to an embodiment of the present application. The network device 1200 shown in fig. 14 may perform the corresponding steps performed by the ingress device or the egress device in the method of the above-described embodiments.
As shown in fig. 14, the network apparatus 1200 includes: master board 1210, interface board 1230, switch fabric 1220 and interface board 1240. The main control board 1210, the interface boards 1230 and 1240 and the exchange network board 1220 are connected with the system back board through a system bus to realize intercommunication. The main control board 1210 is used for performing functions such as system management, equipment maintenance, and protocol processing. The switch board 1220 is used to complete data exchange between interface boards (interface boards are also referred to as line cards or traffic boards). Interface boards 1230 and 1240 are used to provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and to enable forwarding of data packets.
Interface board 1230 may include a central processor 1231, forwarding table entry memory 1234, physical interface card 1233, and network processor 1232. The central processor 1231 is used for controlling and managing the interface board and communicating with the central processor on the main control board. The forwarding table entry memory 1234 is used for storing forwarding table entries. The physical interface card 1233 is used to complete the reception and transmission of traffic. The network memory 1232 is configured to control the physical interface card 1233 to send and receive traffic according to the forwarding table entry.
Specifically, physical interface card 1233 is configured to receive BIER messages. Physical interface card 1233 is also used to forward updated BIER messages to the next hop network device of the network device.
After receiving the BIER message, physical interface card 1233 sends the BIER message to central processor 1211 via central processor 1231, and central processor 1211 processes the BIER message.
The central processor 1211 is also configured to determine an address corresponding to the source address of the BIER message.
It should be appreciated that the operations on the interface board 1240 in embodiments of the invention are consistent with the operations of the interface board 1230 and will not be described in detail for brevity. It should be understood that the network device 1200 of the present embodiment may correspond to the functions and/or the implemented steps of the above-described method embodiments, which are not described herein.
In addition, it should be noted that the main control board may have one or more blocks, and the main control board and the standby main control board may be included when there are multiple blocks. The interface boards may have one or more, the more data processing capabilities the network device is, the more interface boards are provided. The physical interface card on the interface board may also have one or more pieces. The switching network board may not be provided, or may be provided with one or more blocks, and load sharing redundancy backup can be jointly realized when the switching network board is provided with the plurality of blocks. Under the centralized forwarding architecture, the network device may not need to exchange network boards, and the interface board bears the processing function of the service data of the whole system. Under the distributed forwarding architecture, the network device may have at least one switching fabric, through which data exchange between multiple interface boards is implemented, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing power of the network devices of the distributed architecture is greater than that of the devices of the centralized architecture. The specific architecture employed is not limited in any way herein, depending on the specific networking deployment scenario.
In some embodiments, there is also provided a computer program product comprising one or more computer program instructions which, when loaded and run by a computer, cause the computer to perform the method provided by the above-described method embodiments.
In some embodiments, a chip is also provided, including a memory for storing computer instructions and a processor for calling and executing the computer instructions from the memory to perform the methods provided by the above-described method embodiments.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are referred to each other, and each embodiment is mainly described as a difference from other embodiments. A refers to B, referring to a simple variation where A is the same as B or A is B. The terms first and second and the like in the description and in the claims of embodiments of the application, are used for distinguishing between different objects and not necessarily for describing a particular sequential or chronological order of the objects, and should not be interpreted to indicate or imply relative importance. For example, the first BIER message and the second BIER message are used to distinguish between different BIER messages, rather than to describe a particular order of BIER messages, nor should the first BIER message Wen Bidi be understood to be more important. In the embodiments of the present application, unless otherwise indicated, the meaning of "at least one" means one or more, and the meaning of "a plurality" means two or more.
The above-described embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk Solid STATE DISK (SSD)), etc.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims (30)

1. A method for transmitting a message, the method comprising:
the method comprises the steps that an inlet device obtains a first bit index based explicit copy BIER message, and a source address of the first BIER message is an address of a first user;
The entrance device obtains a second BIER message based on the first BIER message, wherein the source address of the second BIER message is the address of the entrance device corresponding to the address of the first user;
And the inlet equipment sends the second BIER message.
2. The method of claim 1, wherein the obtaining, by the ingress device, a second BIER message based on the first BIER message comprises:
The entrance device obtains the address of the entrance device based on the address of the first user and a corresponding relation, wherein the corresponding relation comprises the address of the first user and the address of the entrance device;
the entrance device obtains the second BIER message based on the first BIER message and the address of the entrance device.
3. The method according to claim 2, wherein the method further comprises:
the entrance device obtains the address of the first user;
the entrance equipment allocates the address of the entrance equipment corresponding to the address of the first user in the network segment corresponding to the IPv 6-based segment routing position identification;
The portal device obtains the correspondence based on the address of the first user and the address of the portal device.
4. A method according to claim 3, wherein the obtaining, by the portal device, the address of the first user comprises:
The ingress device receives an interior gateway protocol, IGP, message or a first border gateway protocol, BGP, message, the IGP message or the first BGP message including an address of the first user.
5. The method according to any one of claims 2 to 4, further comprising:
And the inlet equipment sends a second BGP message to the outlet equipment, wherein the second BGP message comprises the corresponding relation.
6. The method of any one of claims 1 to 5, wherein the second BIER message further includes an address of the first user.
7. The method of claim 6, wherein the IPv6 extension header of the second BIER message includes an address of the first user; or alternatively
The destination option header DOH header of the second BIER message includes the address of the first user.
8. A method for transmitting a message, the method comprising:
the method comprises the steps that an outlet device obtains a second bit index based explicit copy BIER message, and a source address of the second BIER message is an address of an inlet device;
The outlet equipment obtains a first BIER message based on the second BIER message, wherein the source address of the first BIER message is the address of a first user corresponding to the address of the inlet equipment;
And the outlet equipment sends the first BIER message.
9. The method of claim 8, wherein the exit device obtaining a first BIER message based on the second BIER message comprises:
the outlet device obtains the address of the first user based on the address of the inlet device and a corresponding relation, wherein the corresponding relation comprises the address of the inlet device and the address of the first user;
And the outlet equipment obtains the first BIER message according to the second BIER message and the address of the first user.
10. The method according to claim 9, wherein the method further comprises:
And the outlet equipment receives a Border Gateway Protocol (BGP) message sent by the inlet equipment, wherein the BGP message comprises the corresponding relation.
11. The method of claim 8, wherein the second BIER message further includes an address of the first user.
12. The method of claim 11, wherein the IPv6 extension header of the second BIER message includes an address of the first user, or wherein the destination option header DOH header of the second BIER message includes an address of the first user.
13. The method according to claim 11 or 12, wherein the obtaining, by the outlet device, the first BIER message based on the second BIER message comprises:
the outlet equipment acquires the address of the first user based on the second BIER message;
And the outlet equipment obtains the first BIER message based on the second BIER message and the address of the first user.
14. A message transmission apparatus, the apparatus comprising:
The acquisition unit is used for acquiring a first BIER message which is explicitly copied based on the bit index, wherein the source address of the first BIER message is the address of a first user;
The processing unit is used for obtaining a second BIER message based on the first BIER message, and the source address of the second BIER message is the address of the entrance equipment corresponding to the address of the first user;
and the sending unit is used for sending the second BIER message.
15. The apparatus of claim 14, wherein the processing unit is configured to obtain the address of the ingress device based on an address of the first user and a correspondence, the correspondence including the address of the first user and the address of the ingress device; and obtaining the second BIER message based on the first BIER message and the address of the inlet equipment.
16. The apparatus of claim 15, wherein the obtaining unit is further configured to obtain an address of the first user;
The processing unit is further configured to allocate an address of the corresponding entry device to the address of the first user in a network segment corresponding to the segment routing location identifier based on IPv 6; and obtaining the corresponding relation based on the address of the first user and the address of the entrance equipment.
17. The apparatus of claim 16, wherein the means for obtaining is configured to receive an interior gateway protocol, IGP, message or a first border gateway protocol, BGP, message, the IGP message or the first BGP message comprising an address of the first user.
18. The apparatus according to any of claims 15 to 17, wherein the sending unit is further configured to send a second BGP message to the egress device, the second BGP message including the correspondence.
19. The apparatus of any one of claims 14 to 18, wherein the second BIER message further includes an address of the first user.
20. The apparatus of claim 19, wherein the IPv6 extension header of the second BIER message includes an address of the first user; or alternatively
The destination option header DOH header of the second BIER message includes the address of the first user.
21. A message transmission apparatus, the apparatus comprising:
The acquisition unit is used for acquiring a second BIER message which is explicitly copied based on the bit index, and the source address of the second BIER message is the address of the inlet equipment;
The processing unit is used for obtaining a first BIER message based on the second BIER message, and the source address of the first BIER message is the address of a first user corresponding to the address of the entrance equipment;
And the sending unit is used for sending the first BIER message.
22. The apparatus of claim 21, wherein the processing unit is configured to obtain the address of the first user based on an address of the ingress device and a correspondence, the correspondence including the address of the ingress device and the address of the first user; and obtaining the first BIER message according to the second BIER message and the address of the first user.
23. The apparatus of claim 22, wherein the obtaining unit is further configured to receive a border gateway protocol BGP message sent by the ingress device, the BGP message including the correspondence.
24. The apparatus of claim 21, wherein the second BIER message further comprises an address of the first user.
25. The apparatus of claim 24, wherein the IPv6 extension header of the second BIER message includes an address of the first user, or wherein the destination option header DOH header of the second BIER message includes an address of the first user.
26. The apparatus according to claim 24 or 25, wherein the processing unit is configured to obtain the address of the first user based on the second BIER message; and obtaining the first BIER message based on the second BIER message and the address of the first user.
27. A network device comprising a processor and a memory for storing a software program, the processor causing the network device to implement the method of any one of claims 1 to 13 by running or executing the software program stored in the memory.
28. A messaging system comprising an ingress device that performs the messaging method of any of claims 1 to 7 and an egress device that performs the messaging method of any of claims 8 to 13.
29. A computer readable storage medium for storing program code for execution by a processor, the program code comprising instructions for implementing the method of any one of claims 1 to 13.
30. A computer program product comprising program code which, when run on a computer, causes the computer to perform the method of any of claims 1to 13.
CN202310321021.2A 2022-12-20 2023-03-28 Message transmission method, device and network equipment Pending CN118233364A (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211642514 2022-12-20
CN2022116425148 2022-12-20

Publications (1)

Publication Number Publication Date
CN118233364A true CN118233364A (en) 2024-06-21

Family

ID=91503021

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310321021.2A Pending CN118233364A (en) 2022-12-20 2023-03-28 Message transmission method, device and network equipment

Country Status (1)

Country Link
CN (1) CN118233364A (en)

Similar Documents

Publication Publication Date Title
CN111865898B (en) Communication method, device and system based on flow rule protocol
CN109861926B (en) Message sending and processing method, device, node, processing system and medium
JP7208386B2 (en) Packet transfer method, packet transmitter, and packet receiver
EP3896923A1 (en) Bier packet sending method and apparatus
CN106059924B (en) Method, device and system for managing information
EP4239973A1 (en) Packet sending method, device, and system
JP2023549797A (en) BIER packet forwarding methods, devices, and systems
CN111698162A (en) Method, device and system for information synchronization
US11362954B2 (en) Tunneling inter-domain stateless internet protocol multicast packets
CN108429680A (en) A kind of method for configuring route, system, medium and equipment based on virtual private cloud
WO2020259420A1 (en) Method for generating multicast forwarding table entry, and access gateway
US20220200820A1 (en) Packet Sending Method and Apparatus
WO2022117018A1 (en) Packet transmission method and apparatus
CN112822097A (en) Message forwarding method, first network device and first device group
CN110022263B (en) Data transmission method and related device
JP7273125B2 (en) Method and first network device for transmitting BIERv6 packets
WO2022166465A1 (en) Message processing method and related apparatus
CN117478503A (en) Multicast configuration method and device
CN118233364A (en) Message transmission method, device and network equipment
WO2021103744A1 (en) Heterogeneous network communication method and system, and controller
JPH10190715A (en) Network switching system
WO2024001821A1 (en) Distribution method for encrypted information, and related apparatus
US20230318966A1 (en) Packet Transmission Method, Correspondence Obtaining Method, Apparatus, and System
CN117411822A (en) Management method of forwarding router BRF based on bit index explicit replication
CN115695087A (en) Method, device, equipment and storage medium for establishing cross-domain local area network

Legal Events

Date Code Title Description
PB01 Publication
SE01 Entry into force of request for substantive examination