Inter-domain flow isolation method for DDS (Direct Digital Synthesizer) communication system

Abstract

The invention provides an inter-domain flow isolation method for a DDS (Direct Digital Synthesizer) communication system, which comprises the following steps of: improving an existing message processing flow on a DDS terminal side, and adding Domain Id analysis and VLANTag filling and inserting operations, so that an RTPS (Real Time Packet Switching) message sent by a DDS terminal is a VLAN (Virtual Local Area Network) format message, and vid is consistent with Domain Id; at a switch side, an existing message processing flow is improved, a vid self-learning function is added, and a switch realizes VLAN-based flow isolation and forwarding according to a VLANTag carried by a message. The method has the advantages that zero configuration and operation and maintenance reduction are achieved, VLANTag needs to be manually configured traditionally, the message format is automatically converted on the terminal side, zero manual intervention is achieved, and operation and maintenance cost is reduced; the Domain and the VLAN are difficult to match traditionally, the terminal maps the Domain Id to the vid, the switch carries out self-learning forwarding, and the flow isolation is enhanced; the defects of a traditional scheme are overcome, and the method flexibly adapts to DDS entity changes; the defects of centralized control are avoided, the characteristics of the DDS are maintained, and the stability of the system is guaranteed.

Description

Technical Field

[0001] The present invention mainly relates to the field of network communication technologies, and particularly relates to an inter-domain traffic isolation method for a DDS communication system. Background Art

[0002] Data Distribution Service (DDS) is a distributed real-time communication protocol centered around data and adopting a publish / subscribe architecture. It usually supports data distribution for applications in the form of middleware running on an operating system. A DDS communication system generally includes several DDS terminals and at least one switch. The DDS terminals run DDS middleware and DDS applications thereon. The switch supports the access of DDS terminals and provides a traffic transmission channel for DDS applications. To ensure service quality, improve reliability, and optimize resource utilization, DDS supports logical grouping and traffic isolation of DDS publish / subscribe entities based on communication domains (Domains). DDS entities belonging to the same Domain are allowed to communicate, while DDS entities belonging to different Domains are prohibited from communicating. To limit the traffic broadcast range, isolate fault domains, and optimize resource utilization, the switch supports logical grouping and traffic isolation of communication terminals based on Virtual Local Area Networks (VLANs). Communication terminals belonging to the same VLAN are allowed to communicate, while communication terminals belonging to different VLANs are prohibited from communicating. Although both Domains and VLANs are used for traffic isolation, they usually cannot be perfectly matched and used together: (1) Domains are specified by DDS application developers. DDS entities have flexible deployment and access / exit requirements, and their mapping relationships with terminal devices or switch access points are usually dynamic. (2) VLANs are configured by network administrators, and their mapping relationships with terminal devices or switch access points are usually static. To adapt to the dynamic nature of DDS entities, it is necessary to update VLAN configurations in a timely manner during system operation. Currently, there is a lack of means to update VLAN configurations in a timely manner during system operation to perfectly match the Domain isolation requirements.

[0003] Due to the difficulty in matching and automatically updating Domain and VLAN configurations, when the scale of DDS entities is large and the communication model is complex, one solution is to abandon VLANs, that is, only use the Domain isolation mechanism. A possible solution that takes VLANs into account is to limit the dynamic nature of DDS entities. For example, ensure that the terminals involved in Domains and the terminals divided by VLANs remain fixed. Another possible solution is to introduce a centralized controller. When DDS exhibits dynamicity, manually or design a certain discovery mechanism to automatically collect requirements to the centralized controller, and design and deploy algorithms on the centralized controller to automatically generate VLAN configurations and distribute them to the switches.

[0004] For the "deprecated VLAN" solution, to address the resulting expansion of the broadcast domain or failure domain, it is usually mitigated by increasing network capacity. In this case, the system cost will increase significantly as the interface bandwidth of switches and terminal interface adapters increases, and the scalability is poor; for the "fixed VLAN" solution, it will greatly weaken the application advantages of DDS and narrow the applicable scenarios of DDS. The resource utilization efficiency depends on a single deployment and cannot automatically adapt to local failures during system operation; for the "centralized control" solution, in addition to introducing the single point of failure problem, this method destroys the distributed and dynamic advantages of DDS, introduces additional management traffic, and requires switches to provide remote in-band access interfaces externally.

[0005] It should be noted that the above content belongs to the technical cognition scope of the inventor. Due to the vast and extremely complex technical content in this field, the above content of this application does not necessarily constitute prior art. Summary of the Invention

[0006] 1. Technical problems to be solved by the invention: The present invention provides an inter-domain traffic isolation method for a DDS communication system to solve the technical problems existing in the above background technology.

[0007] 2. Technical solution: To achieve the above object, the technical solution provided by the present invention is: an inter-domain traffic isolation method for a DDS communication system, characterized in that the method relies on improved message processing mechanisms on the DDS terminal side and the switch side to achieve inter-domain traffic isolation in the DDS communication system. The method includes: On the DDS terminal side, the existing message processing process is improved by adding DomainId parsing, VLAN Tag filling and insertion operations, so that the RTPS message sent by the DDS terminal is a VLAN format message, and the vid is the same as the DomainId; On the switch side, the existing message processing process is improved by adding a vid self-learning function, and the switch realizes VLAN-based traffic isolation and forwarding based on the VLAN Tag carried in the message.

[0008] Further, the improved message processing process on the DDS terminal side specifically includes: Step 1: Receive a message from the protocol stack. Since DDS usually calls the protocol stack socket interface design and RTPS is usually encapsulated as a UDP message, a VLAN Tag is added before further delivering it to the network interface; Step 2: Parse and determine whether the received message is a DDS RTPS message, and identify it based on the "RTPS" special magic number field carried in the RTPS message header as specified by the DDS standard; Step 3: If it is not an RTPS message, directly send the message to the network interface according to the existing message processing flow; Step 2: If it is an RTPS message: 1) Parse the DomainId from the message. The DomainId is specified by the DDS application developer and is calculated after extracting the corresponding fields according to the RTPS organization format; 2) Fill in the VLANTag, assign the vid with the DomainId to implement the mapping from Domain to VLAN; 3) Insert the VLANTag between the MAC header and the IP header of the message, which is the same as the existing VLAN filling method; Step 4: Send the message with the VLAN filled from the network interface.

[0009] Furthermore, when implementing the mapping from Domain to VLAN on the DDS terminal side, expand the processing module between the operating system kernel protocol stack and the network interface driver, or expand it at the network interface driver or chip layer according to the actual situation.

[0010] Furthermore, the improved message processing flow on the switch side specifically includes: Step 1: Receive the message from the network interface, which is the starting point of message switching and forwarding; Step 2: Register several pieces of information inside the switch, including the message receiving port port, the source address smac, and the destination address dmac, etc.; Step 3: Parse whether the message carries a VLANTag; Step 4: Register the vid. For the message carrying the VLANTag, parse the vid from the VLANTag and assign it, and for the one not carrying it, directly assign it as 0; Step 5: Vid self-learning, write the registered information <smac, vid, port> into the forwarding table in the format of the forwarding table entry; Step 6: Query the forwarding table, use {dmac, vid} as the table lookup keyword to obtain the output port information that the current message needs to be forwarded to; Step 7: Analyze the table lookup result to determine whether valid output port port information is obtained; Step 8: Message forwarding. If broadcasting is required, send the message to all ports except its receiving port, otherwise send it according to the port information specified by port.

[0011] Furthermore, zero manual configuration is achieved through the improved message processing flow on the DDS terminal side. In the existing solutions, the addition of VLAN Tags is generally completed by the switch or the terminal network interface under the manual configuration of the network administrator. However, in this method, the VLAN format conversion is performed before the RTPS message enters the network, eliminating the need for additional VLAN configuration. When the DDS entity deployment terminal changes, or the publish / subscribe entity dynamically accesses or leaves the network as needed, the Domainid can be accurately obtained from the RTPS message and the VLAN Tag can be filled.

[0012] Furthermore, the perfect matching between Domain and VLAN is achieved through the improved message processing flow on the DDS terminal side and the switch side. In the existing solutions, the accurate matching from Domain to VLAN cannot be completed, or additional "centralized control" is required for auxiliary matching. In this method, before the RTPS enters the network, the one-to-one mapping from Domainid to vid is completed on the terminal side, and the switch side supports vid self-learning and forwards messages based on {dmac, vid}, ensuring that the messages carrying the same Domainid are forwarded between the DDS entities within the Domain scope.

[0013] Furthermore, the DDS terminal identifies the RTPS message only based on the "RTPS" special magic number field carried in the RTPS message header.

[0014] Furthermore, during the switch vid self-learning process, the information written into the forwarding table only includes <smac, vid, port>.

[0015] Furthermore, when the switch queries the forwarding table, only {dmac, vid} is used as the table lookup key.

[0016] Furthermore, when implementing traffic isolation in the DDS communication system, it can be applied to DDS entities of any scale and communication model scenarios of any complexity.

[0017] 3. Beneficial effects: Adopting the technical solution provided by the present invention, compared with the prior art, it has the following beneficial effects: 1. Zero manual configuration, reducing operation and maintenance costs: In the traditional solution, the addition of VLAN Tags requires the network administrator to manually configure the switch ports or terminal network interfaces. In the present invention, the message processing flow is improved on the DDS terminal side, and the VLAN format conversion is completed before the RTPS message enters the network. Even if the DDS entity changes dynamically, the terminal can automatically obtain the DomainId and fill the VLAN Tag without manual intervention, greatly reducing the operation and maintenance costs and improving the management efficiency; 2. Precise matching of Domain and VLAN to enhance traffic isolation: In traditional and other feasible solutions, it is difficult to achieve accurate matching of Domain and VLAN, or centralized controllers are required for assistance, which cannot meet the requirements of system scale expansion and automated configuration. In the present invention, DomainId is mapped to vid on the terminal side, and the traffic isolation requirement at the application layer is transformed to the link layer. The switch supports vid self-learning and forwards packets based on {dmac, vid}, effectively avoiding inter-domain traffic interference and enhancing the traffic isolation effect; 3. Improve system scalability and adaptability: The "discard VLAN" solution requires increasing network capacity, resulting in a sharp increase in cost and poor scalability; the "fixed VLAN" solution weakens the advantages of DDS applications and cannot adapt to local failures. The present invention can flexibly adapt to the dynamic changes of DDS entities through zero manual configuration and perfect matching of Domain and VLAN, without additional hardware upgrades or centralized control, and can operate stably in DDS communication systems of various scales and complexities; 4. Retain the advantages of DDS distribution and dynamics: Although introducing a centralized controller can solve some configuration matching problems, it will introduce a single point of failure, destroy the distribution and dynamics advantages of DDS, increase management traffic and pose requirements on switch interfaces. The present invention maintains the distribution and dynamics advantages of DDS while achieving traffic isolation through the local processing mechanisms of terminals and switches, ensuring the stability and reliability of the system.

[0018] It should be noted that the structures not introduced in the present invention are the same as the prior art or can be implemented using the prior art because they do not involve the design key points and improvement directions of the present invention, and will not be elaborated here. Description of the Drawings

[0019] Figure 1 It is the message processing flow chart after the improvement of the DDS terminal of the present invention; Figure 2 It is the message processing flow chart after the improvement of the switch of the present invention; Detailed Embodiments

[0020] To facilitate the understanding of the present invention, the present invention will be described more comprehensively with reference to the relevant drawings. Several embodiments of the present invention are given in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, the purpose of providing these embodiments is to make the disclosure of the present invention more thorough and comprehensive.

[0021] In the description of the present invention, it should be understood that the orientation or positional relationship indicated by terms such as "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", etc. is based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation to the present invention.

[0022] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the present invention, the meaning of "a plurality" is two or more unless otherwise specifically defined.

[0023] In the present invention, unless otherwise clearly specified and defined, terms such as "install", "connect", "join", "fix", "provide", "set" should be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or an integral connection; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances. Embodiment

[0024] Refer to the attached Figure 1 Message processing flowchart after the improvement of the DDS terminal: This figure shows the message processing flow of the improved DDS terminal of the present invention. In the figure, the rectangular boxes represent processing steps, and the arrows indicate the flow direction. "Receive message from the protocol stack" box: The DDS application passes the RTPS data encapsulated as a UDP message to this through calling the protocol stack socket interface, preparing for subsequent processing.

[0025] "Parse and determine whether it is a DDS RTPS message" box: According to the DDS standard, by identifying the special magic number field "RTPS" in the RTPS message header, the message type is determined. "Send the message directly to the network interface according to the existing message processing flow" box: When it is determined that the message is not of the RTPS type, the message is sent along the traditional processing path. "Parse DomainId from the message" box: Extract the corresponding fields from the RTPS message according to its organizational format and calculate to obtain the DomainId specified by the DDS application developer.

[0026] "Fill in the VLAN Tag" box: Assign the parsed DomainId to vid to complete the filling of the VLAN Tag and realize the mapping from Domain to VLAN. "Insert the VLAN Tag between the MAC header and the IP header of the message" box: Insert the VLAN Tag at a specific position according to the existing VLAN filling rules. "Send the message with the VLAN filling completed out from the network interface" box: Send the processed message to the network through the network interface.

[0027] Refer to Appendix Figure 2 The improved message processing flow chart of the switch: This figure shows the improved message processing flow of the switch in the present invention. The rectangular boxes in the figure represent the processing steps, and the arrows indicate the flow direction. "Receive the message from the network interface" box: The switch obtains the message from the network interface and starts the subsequent processing flow. "Register several pieces of information inside the switch" box: Record information such as the message receiving port port, source address smac, and destination address dmac. "Parse whether the message carries a VLAN Tag" box: Judge whether the received message contains a VLAN Tag. "Register vid" box: If the message carries a VLAN Tag, parse the vid from it and assign a value; if not, directly assign a value of 0. "Vid self-learning" box: Write the <smac, vid, port> information into the forwarding table in the format of the forwarding table entry. "Query the forwarding table" box: Use {dmac, vid} as the keyword to find the output port information for message forwarding in the forwarding table. "Analysis of the table lookup result" box: Judge whether the valid output port port information is found.

[0028] "Send the message to all ports except its receiving port" box: When no valid port is found, perform a broadcast operation. "Send according to the port specified by the port information" box: When a valid port is found, forward the message according to the specified port.

[0029] The detailed description of this technical solution is as follows: I. Domain to VLAN mapping on the DDS terminal side The processing module is extended between the operating system kernel protocol stack and the network interface driver. It can also be extended at the network interface driver or chip layer according to actual conditions. The specific processing steps are as follows: S1. Receive messages from the protocol stack: DDS is usually designed based on the protocol stack socket interface. RTPS messages are generally encapsulated as UDP messages. At this stage, in order to comply with the hierarchical design concept, VLANTag is added before the message is further sent to the network interface. S2. Analyze and determine whether it is a DDSRTPS message: According to the DDS standard, the RTPS message header carries a special magic field "RTPS", which is used as the basis for identifying the message type. S3. If it is not an RTPS message: according to the existing message processing flow, the message is directly sent to the network interface. S4. If it is an RTPS message: Parse DomainId from the message: DomainId is specified by the DDS application developer. According to the organization format of the RTPS message, the corresponding fields are extracted and calculated to obtain DomainId. Fill VLANTag: Assign the resolved DomainId to vid, complete the filling of VLANTag, and realize the mapping from Domain to VLAN. This makes all RTPS messages sent by DDS entities belonging to the same Domain carry the same vid, laying the foundation for the switch to isolate traffic based on VLAN in the future; Insert VLANTag between the MAC header and IP header of the message: insert VLANTag at a specific position according to the existing VLAN filling rules. S5. Send the message with VLAN filling completed from the network interface: At this point, the message processing on the DDS terminal side is completed, and the processed message is sent to the network through the network interface. 2. VLAN self-learning and forwarding on the switch side The existing switch network processing flow is appropriately modified. The specific steps are as follows: S1. Receive messages from the network interface: This is the starting step for the switch to perform message switching and forwarding, which is consistent with the current switch processing process. S2. The switch registers some information internally: records the message's receiving port, source address smac, destination address dmac and other information to provide necessary data for subsequent processing. S3. Analyze whether the message carries VLANTag: Since the DDS terminal has processed all DDSRTPS messages into messages carrying VLANTag format, this is a type of message that this solution focuses on. S4. Register vid: If the message carries a VLAN Tag, parse the vid from it and assign a value; if it does not carry a VLAN Tag, directly assign a value of 0 for subsequent unified processing. S5. Vid self-learning: Drawing on the existing MAC self-learning process, write the registered <smac, vid, port> information into the forwarding table in the format of forwarding table entries to facilitate obtaining accurate forwarding port information when looking up the table for subsequent messages. S6. Query the forwarding table: Using {dmac, vid} as the key for looking up the table, query in the forwarding table to obtain the output port information required for forwarding the current message. This operation is similar to the existing table lookup processing flow. S7. Analysis of table lookup results: Determine whether valid output port port information is obtained through table lookup; if an entry with {dmac, vid} as the key has been established, valid port information can be obtained; otherwise, it indicates that the switch currently does not know how to process this message. S8. Message forwarding: If broadcasting is required, send the message to all ports except its receiving port; if a valid port is found, send the message according to the port specified by the port information.

[0030] In summary, the present technical solution has the following technical innovation contents: 1. Zero manual configuration: Supported by the improved message processing flow and corresponding implementation modules on the terminal side. In the existing solution, the addition of VLAN Tags is generally completed by the switch. For example, a network administrator configures a specific vid for the switch port through a command, and the switch adds the corresponding VLAN Tag to the message after receiving the message from this port; modern operating systems or interface adapters also support configuring vid for network interfaces on the terminal side, but this is only an extension of the switch configuration solution and still requires manual configuration by the network administrator; in this solution, through the application of the improved process processing module, VLAN format conversion is performed before the RTPS message enters the network, so there is no need to further add a VLAN Tag after the message enters the network, that is, no additional VLAN configuration is required, achieving the goal of zero manual configuration; even when the terminal where the DDS entity is deployed changes, or publishing / subscribing entities dynamically access or leave the network as needed, since the RTPS message already accurately carries the Domainid before being sent from the protocol stack to the improved process processing module, this process can accurately obtain the Domainid from the RTPS message and perform VLAN Tag filling without additional manual configuration.

[0031] 2. Perfect match between Domain and VLAN: Supported by the improved message processing flow and corresponding implementation modules on the terminal side and switch side; in the existing solutions and potential feasible solutions, either the accurate match between Domain and VLAN cannot be completed, or additional "centralized control" is required to assist in the match, which cannot meet the requirements of the scale expansion of the DDS communication system or achieve the goal of automation and zero configuration. The fundamental reason is that it relies on VLAN configuration, and VLAN configuration is difficult to meet the dynamic and flexible requirements of DDS; in this solution, before RTPS enters the network, the terminal side completes the one-to-one mapping from Domainid to vid, so that the traffic isolation requirements at the application layer are accurately transformed into traffic isolation requirements at the link layer; at the same time, the switch side supports vid self-learning and supports message forwarding based on {dmac, vid}, ensuring that messages carrying the same Domainid can always be accurately forwarded between DDS entities within the Domain scope, thus achieving the goal and effect of inter-domain traffic isolation in DDS.

[0032] The above-described embodiments only represent a certain implementation manner of the present invention, and the description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the patent of the present invention; it should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention; therefore, the protection scope of the patent of the present invention should be subject to the appended claims.

Claims

1. A method for isolating inter-domain traffic in a DDS communication system, characterized in that: The method relies on an improved message processing mechanism on the DDS terminal side and the switch side to achieve inter-domain traffic isolation of the DDS communication system, and the method includes: On the DDS terminal side, the existing message processing flow is improved by adding DomainId parsing, VLANTag filling and insertion operations, so that the RTPS message sent by the DDS terminal is a VLAN format message, and the vid is consistent with the DomainId; On the switch side, the existing message processing flow is improved and the VID self-learning function is added. The switch implements VLAN-based traffic isolation and forwarding according to the VLANTag carried in the message.

2. The method for isolating inter-domain traffic in a DDS communication system according to claim 1, characterized in that: The improved message processing flow on the DDS terminal side specifically includes: Step 1: Receive the message from the protocol stack. Since DDS usually calls the protocol stack socket interface design, RTPS is usually encapsulated as a UDP message and adds a VLANTag before further sending it to the network interface. Step 2: Analyze and determine whether the received message is a DDSRTPS message, and identify it according to the "RTPS" special magic field carried in the RTPS message header specified in the DDS standard; Step 3: If it is not an RTPS message, send the message directly to the network interface according to the existing message processing process; Step 2: If it is an RTPS message: 1) Parse the DomainId from the message. The DomainId is specified by the DDS application developer and is calculated by extracting the corresponding fields according to the RTPS organization format; 2) Fill in VLANTag and assign vid with DomainId to implement Domain to VLAN mapping; 3) Insert VLANTag between the MAC header and IP header of the message, which is consistent with the existing VLAN filling method; Step 4: Send the message with VLAN filling completed from the network interface.

3. The method for isolating inter-domain traffic in a DDS communication system according to claim 2, characterized in that: When implementing Domain to VLAN mapping on the DDS terminal side, a processing module is extended between the operating system kernel protocol stack and the network interface driver, or extended at the network interface driver or chip layer according to actual conditions.

4. The method for isolating inter-domain traffic in a DDS communication system according to claim 1, characterized in that: The improved message processing flow on the switch side specifically includes: Step 1: Receive a message from the network interface, which is the starting point for message switching and forwarding; Step 2: The switch registers some information inside, including the message receiving port, message source address smac and destination address dmac, etc. Step 3: Analyze whether the message carries VLANTag; Step 4: Register vid. If the VLANTag is included, parse the vid from the VLANTag and assign a value. If the VLANTag is not included, directly assign a value of 0. Step 5: vid self-learning, the registered information<smac,vid,port> Write the forwarding table according to the forwarding table entry format; Step 6: Query the forwarding table, use {dmac, vid} as the table query key, and obtain the output port information that the current message needs to be forwarded; Step 7: Analyze the table lookup results to determine whether valid output port information is obtained; Step 8: Message forwarding: If broadcasting is required, the message is sent to all ports except the port where it is received; otherwise, it is sent to the port specified by the port information.

5. The method for isolating inter-domain traffic in a DDS communication system according to claim 1, characterized in that: Zero manual configuration is achieved through the improved message processing flow on the DDS terminal side. In the existing solution, VLANTag addition is generally completed by the switch or terminal network interface under manual configuration of the network administrator, while this method performs VLAN format conversion before the RTPS message enters the network, without the need for additional VLAN configuration. When the DDS entity deployment terminal changes or the publishing / subscribing entity dynamically accesses or leaves the network on demand, the DomainID can be accurately obtained from the RTPS message and the VLANTag can be filled.

6. The method for isolating inter-domain traffic in a DDS communication system according to claim 1, characterized in that: Perfect matching of Domain and VLAN is achieved through improved message processing flow on the DDS terminal side and the switch side. Existing solutions cannot complete accurate matching of Domain to VLAN or require additional "centralized control" to assist matching. Before RTPS enters the network, this method completes the one-to-one mapping of Domainid to vid on the terminal side, supports vid self-learning on the switch side, and forwards messages based on {dmac, vid}, ensuring that messages carrying the same Domainid are forwarded between DDS entities within the Domain range.

7. The method for isolating inter-domain traffic in a DDS communication system according to claim 2 or 3, characterized in that: The basis for the DDS terminal to identify the RTPS message is limited to the "RTPS" special magic field carried in the RTPS message header.

8. The method for isolating inter-domain traffic in a DDS communication system according to claim 4, characterized in that: During the switch vid self-learning process, the information written into the forwarding table only includes<smac,vid,port> .

9. The method for isolating inter-domain traffic in a DDS communication system according to claim 4, characterized in that: When the switch queries the forwarding table, only {dmac, vid} is used as the table query keyword.

10. The method for isolating inter-domain traffic in a DDS communication system according to any one of claims 1 to 9, characterized in that: When implementing traffic isolation in a DDS communication system, it can be applied to DDS entities of any scale and communication model scenarios of any complexity.

Images