Data communication and network-IP Multicast Routing Protocol

Source: Internet
Author: User

Part of this article is reproduced in: http://network.51cto.com/art/200912/168407.htm

Before talking about IGMP, it is said that IGMP packets cannot be transmitted outside the LAN (for details, see: http://blog.csdn.net/todd911/article/details/9530633), so how to communicate between routers after hosts in different network segments join multicast groups, do you know which subnet to forward? This is the function of the IP multicast routing protocol.

Here we mainly introduce the IP Multicast Routing Protocol. A common idea of multicast routing is to construct an extended distribution tree between multicast group members. The IP multicast routing protocol traffic on a specific "sending source, destination group" is transmitted from the sending source to the receiver through this extension tree, the extension tree connects all hosts in the multicast group. Different IP Multicast Routing Protocols use different technologies to construct these multicast extension trees. Once this tree is constructed, all multicast traffic will be transmitted through it.

According to the distribution of multicast group members in the network, IP multicast routing protocols can be divided into the following two basic types. First, assume that multicast group members are densely distributed in the network. That is to say, most subnets in the network contain at least one multicast group member, and the network bandwidth is large enough, this multicast routing protocol, called dense-mode, relies on broadcast technology to push data to all routers in the network. The IP Multicast Routing Protocol in dense mode includes the distance vector IP Multicast Routing Protocol (dvmrp: Distance Vector Multicast
Routing Protocol), multicast Open Shortest Path First (mospf: multicast Open Shortest Path First) and intensive mode independent multicast protocol (PIM-DM: Protocol-Independent Multicast-dense mode) and so on.

The second type of multicast routing assumes that multicast group members are sparse and scattered in the network, and the network cannot provide sufficient transmission bandwidth, for example, a large number of users in many different regions are connected over ISDN lines on the Internet. In this case, broadcast will waste a lot of unnecessary network bandwidth, which may cause serious network performance problems. Therefore, the IP Multicast Routing Protocol in Sparse Mode must rely on technologies with routing selection capabilities to establish and maintain multicast trees. Sparse Mode mainly includes the core tree-based multicast protocol (CBT: core based tree) and sparse mode independent protocol multicast (PIM-SM: Protocol-independent)
Multicast-Sparse Mode ).

Dense mode protocol (1) Distance Vector IP Multicast Routing Protocol (dvmrp)

The first routing protocol that supports multicast is the distance vector IP multicast routing protocol. It has been widely used in the multicast Backbone Network mbone. Dvmrp builds different distribution trees for each sending source and Target Host group. Each distribution tree is a minimum extended distribution tree that uses multicast transmission sources as the root and receives the target host as the leaf. This distribution tree provides a shortest path between the sending source and each multicast receiver in the group. The shortest path in the unit of "Number of hops" is the measurement of dvmrp. When a sending source needs to send messages to multicast groups, an extended distribution tree is created based on this request, we also use the broadcast and Trim Technology to maintain this extended distribution tree.



When a vro receives a multicast packet, it first checks its unicast route table to find the shortest path interface of the Multicast Group Sending source. If this interface is the interface that the multicast packet arrives, then, the vro records the multicast group information to its internal route table (indicating the interface that the group data packet should be sent ), in addition, the multicast packet is sent to the nearby router except the router that receives the packet. If the arrival interface of the multicast packet is not the shortest path from the router to the sending source, the packet will be discarded. This mechanism is called the reverse-path broadcasting mechanism, which ensures that no loops are generated in the constructed tree and is the shortest path from the sending source to all recipients. Dvmrp works well for intensive multicast groups in sub-networks, but for multicast groups that are distributed in a large range of regions, periodic broadcast behavior can cause serious performance problems. Dvmrp does not support sparse and scattered multicast groups in large networks.

(2) mospf)

Open Shortest Path First (OSPF) is an IP multicast routing protocol that transmits packets over the minimum overhead path. The overhead here is a measure of the link status. In addition to the number of hops in the path, other network performance parameters that may affect the path overhead include Load Balancing information and QoS required by applications. Mospf is designed for unicast routing multicast. Mospf depends on OSPF as the unicast routing protocol, just as dvmrp also includes its own unicast protocol. In an OSPF/mospf network, each vro maintains the latest full network topology. This "link status" information is used to build a multicast distribution tree.

Each mospf router periodically collects multicast group member information through the IGMP protocol. The information and the link status information are sent to all other routers in the routing domain. Routers update their internal connection status based on the information they receive from the neighboring routers. Because each vro knows the topology of the entire network, it can independently calculate a minimum overhead extension tree, and use multicast sending sources and multicast group members as the root and leaf of the tree. This tree is the path used to send multicast streams from the sending source to multicast group members.

(3) Independent Multicast intensive mode protocol (PIM-DM)

The Independent Multicast Protocol (PIM) is a standard IP multicast routing protocol. It can provide scalable Inter-Domain multicast routing over the Internet without relying on any unicast protocol. Pim has two operation modes: dense distribution multicast group mode and sparse distribution multicast group mode. The former is called Independent Multicast intensive mode protocol (PIM-DM ), the latter is known as the standalone Multicast Sparse Mode protocol (PIM-SM ). The PIM-DM is somewhat similar to dvmrp, both of which use the reverse path multicast mechanism to build the distribution tree. The main difference between them is that Pim is completely independent of the unicast routing protocol in the network, and dvmrp is dependent on a related unicast routing protocol mechanism, and the PIM-DM is simpler than dvmrp.

The PIM-DM protocol is also data-driven like all the intensive-mode IP multicast routing protocols. But since the PIM-DM does not rely on any unicast routing protocol, a router receiving port (that is, the port that returns to the shortest path of the source) the received multicast packet is sent to all downstream interfaces until the unneeded branches are trimmed from the tree. Dvmrp can use the topology data provided by unicast protocol to selectively send data packets in the next row in the tree build phase, PIM-DM is more inclined to simplicity and independence, and even do not hesitate to increase the additional overhead caused by data packet replication.

Multicast Routing Protocol in Sparse Mode

When multicast groups are centrally distributed in the network or the network provides sufficient bandwidth, the intensive mode IP multicast routing protocol is an effective method, when multicast group members are sparse in a wide range of regions, another method is required: The Sparse Mode IP Multicast Routing Protocol controls multicast traffic to the link path connected to multicast group members, instead of "leaking" to unrelated link paths, this not only ensures data transmission security, but also effectively controls the total traffic in the network and the load of the router.

(1) Core tree-based multicast protocol (CBT)

Unlike dvmrp and mospf, the shortest path tree is constructed for each "Send source and target group", the CBT protocol only creates one tree for all members in the group to share, this tree is also called a shared tree. The multicast traffic of the whole multicast group is sent and received on the shared tree, regardless of the number or location of the source. The use of this shared tree can greatly reduce the multicast status information in the router.

The CBT share tree has a core router used to build this tree. The vro to be added sends a join request to the core vro. After receiving the join request, the core router returns a confirmation along the reverse path, which constitutes a branch of the tree. Incoming request packets do not need to be transmitted to the core router until they are confirmed. If a request packet arrives at a router on the tree before arriving at the core router, the router receives the request packet and does not send it forward and confirm the request packet. The router that sends the request is connected to the shared tree. CBT distributes multicast traffic to a minimum number of links instead of a source-based sharing tree. Traffic concentrated on the core router may cause some multicast routing problems. Some versions of CBT support the use of multiple multicast cores, and load balancing is better than that of a single multicast core.

(2) Independent Multicast Sparse Mode protocol (PIM-SM)

Similar to CBT, The PIM-SM is designed to restrict multicast to the router that needs to be sent and received. The PIM-SM builds a multicast distribution tree around an IP multicast routing protocol called a centralized point (RP: rendezvous point. This centralized point plays the same role as the CBT core router. the receiver can query the new sending source at the centralized point. But PIM-SM is more flexible than CBT, CBT tree is usually multicast group sharing tree, the independent receiver in the PIM-SM can choose to build a group sharing tree or shortest path tree. The PIM-SM protocol first creates a group of shared trees for multicast fabric. This tree is constructed by the sender and receiver connecting to the centralized point, just like the sharing tree built around the core router by the CBT protocol. After the sharing tree is established, a receiver (actually the router closest to the receiver) can choose to change the connection to the sending source through the Shortest Path Tree. This operation is completed by sending a PIM request to the sending source. Once the shortest path from the sending source to the receiver is established, the external branches of the RP are trimmed.


Finally, attach the multicast address category:

224.0.0.0 ~ 224.0.0.255 is the reserved multicast address (Permanent Group address)

The address 224.0.0.0 is retained without allocation. Other addresses are used by the routing protocol.

224.0.1.0 ~ 238.00000000255 is the user's available multicast address (temporary group address), which is valid across the network.

239.0.0.0 ~ 239.00000000255 is the multicast address of the Local Management Group. It is valid only for a specific local range.

The list of Common Reserved multicast addresses is as follows:
224.0.0.0 base address (retained)
224.0.0.1 addresses of all hosts
224.0.0.2 addresses of all multicast routers
224.0.0.3 not allocated
224.0.0.4 dvmrp Router
224.0.0.5 OSPF Router
224.0.0.6 OSPF Dr
224.0.0.7 st Router
224.0.0.8 st host
224.0.0.9 rip-2 Router
224.0.0.10
224.0.0.11 activity proxy
224.0.0.12 DHCP server/relay proxy
224.0.0.13 all PIM Routers
224.0.0.14 RSVP Encapsulation
224.0.0.15 all CBT Routers
224.0.0.16 specify SBM
224.0.0.17 all sbms
224.0.0.18 vrrp

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.