Communication between IPv6 multicast IN MTG

The concepts related to IPv6 multicast have been described in many previous articles. Now let's take a look at the role of IPv6 multicast in MTG. First, we will give you a specific example of a video meeting to help you understand the MTG workflow, and then describe the configuration of the IPv6 multicast route.

MTG Workflow

The following uses a video conference as an example to describe the MTG workflow ｡

Both F1 and F2 participants in IPv4 and S1 and S2 participants in IPv6. F1 is the organizer of the meeting. All participants run the Session Description Protocol (SDR) or a listener similar to SAP obtains session information ｡

The IPv4 address and IPv6 address of the MTG are 202.112.25.214 and 3FFE: 3206: 1000: 19D6 respectively. At the same time, the MTG is configured as the IPv6 multicast router ｡

The participant F1 first announces the meeting Information to 224.2.127.254: 9875, notifies other participants to use 224.5.5.5 as the session address, and simultaneously sends a video/audio stream to IPv4 ｡

Participants F2 directly receive the SAP announcement through SDR and start the multicast conference tool. At this time, F1 and F2 can have sessions ｡

When SAP announcement arrives at MTG, MP4 transfers it to MT, MT converts its header, and the source address is converted to the fixed IPv6 address 3FFE: 3206: 1000: 19D6 of MTG, the IP address is FF0E: 0: 2: 7FFE. Call the application layer callback function to parse the multicast session address 224.5.5.5, and then obtain the corresponding IPv6 address FF1E: 224.5.5.5 from AM, modify the information carried by the application layer. MT then transfers the converted SAP packet to MP6 and sends it to the IPv6 network. When SAP arrives for the first time, AM updates the ing table ｡

After receiving the SAP announcement, both S1 and S2 initiate the MLD member report. MP6 transfers the MLD report to MT and MT converts the mld report to the igmp member report, send the member relationship report to IPv4 through MP4 and add the Report to the 224.5.5.5 group. So far, all four participants have joined the multicast session ｡

MP4 receives the IPv4 multicast packets sent by the participant F1 and forwards them to MT. MT converts the header and the source address to the fixed IPv6 address 3FFE: 3206: 1000: 19D6 of the mtg, destination Address 224.5.5.5 is converted to the corresponding IPv6 address FF1E: 224.5.5.5, then, the MP6 multicast is sent to S1 and S2 of the participant. MP6 receives IPv6 multicast packets from S1 and S2 of the participant and forwards the packets to MT for header conversion, the source address is converted to the fixed IPv4 address 202.112.25.214 of the MTG, And the destination address FF1E: 224.5.5.5 is converted to the corresponding IPv4 address 224.5.5.5, then, an MP4 multicast is sent to the F1 and F2 participants. When both S1 and S2 members exit, MP4 no longer forwards the multicast packets to the MT group ｡

When SAP is not used, the session address 202.5.5.5 must notify all conference participants by means of manual communication or Web publishing. The administrator or authorized end users register the 202.5.5.5 multicast group through the SNMP external interface, obtain the IPv6 ing address FF1E: 224.5.5.5. IPv6 users use the FF1E: 224.5.5.5 address to join the multicast session ｡

To enable multicast communication between an IPv4 host and an IPv6 host, you must perform protocol conversion such as a forwarder (at the transport layer) or a gateway (at the network layer ｡

MTG makes some improvements to the gateway based on the implementation of the basic functions of the gateway. The Gateway is insensitive to the members of IPv4 multicast group and the source validity period, you can make MTG an IPv4 multicast router at the same time, so that MTG has the ability to know the status of group members. for IPv4 in the gateway, you can only access IPv6 groups with a given prefix, from the MTG model structure, we can see that, based on the additional prefix, IPv4 addresses can be used to eliminate IPv6 Access restrictions through manageable static address ing ｡

MTG also discussed issues not specific to the gateway solution. According to the standard draft RFC2365, it added the ing of multicast management domains between different protocols. Through the SNMP interface and extended MIB, the gateway management is standardized. In addition, MTG adopts a step-by-step refined processing process to add configurable gateway congestion control policies and packet scheduling policies, supports controllable scheduling of cached packets based on QoS and traffic control requirements ｡

MTG can effectively achieve intercommunication between IPv4-IPv6 multicast ｡