- Information
- AI Chat
Was this document helpful?
Interdomain Multicast (MSDP)
Course: Systems Programming (01:198:214)
23 Documents
Students shared 23 documents in this course
University: Rutgers University
Was this document helpful?
Interdomain Multicast (MSDP)
Let's say a host now wants to address the group with a message. To do this, it creates a packet
with the correct multicast group address as its destination and delivers it to the specified router
on its local network (DR). Assume that the DR in Figure 4.14 is R1. R1 tunnels the multicast
packet to the RP rather than just forwarding it because there is no state for this multicast group
between R1 and the RP at this time. That is, R1 sends a PIM Register message to the RP's unicast
IP address, enclosing the multicast packet inside. The RP receives the packet directed to it just
like a tunnel endpoint of the kind described in Section 3.2.9, examines the payload of the
Register message, and discovers an IP packet inside that is addressed to the multicast address of
this group. Of course, the RP is aware of what to do with a packet of this nature and transmits it
onto the shared tree, of which it is the root.
This means that in the case of Figure 4.14, the RP delivers the packet to R2, who can then pass it
on to R4 and R5. Figure 4.15 depicts the full delivery of a packet from R1 to R4 and R5. We
observe the multicast packet directed to G making its way up the shared tree to R4 and R5, and
the tunneled packet traveling from R1 to the RP with an extra IP header containing the unicast
address of RP. Since all hosts may send to all receivers in this manner, we could be tempted to
declare success at this point. However, the encapsulation and decapsulation of packets on their
way to the RP use some bandwidth and require some processing, therefore the RP imposes
knowledge of this group into the intermediary routers to prevent tunneling. In Figure 4.14(c), a
Join message is sent to the transmitting host.
In order for the DR to deliver the packet to the group as native (i.e., not tunneled) multicast
packets, this Join instructs the routers along the path (R3) to become aware of the group as it
moves toward the host. The Join message delivered by the RP to the transmitting host is specific
to that sender, in contrast to the earlier ones sent by R4 and R5, which applied to all senders. This
is a critical distinction to make at this point. In order to construct sender-specific state in the
routers between the recognized source and the RP, the new Join has the aforementioned effect.
As opposed to the (*, G) state that was installed between the receivers and the RP, which applies
to all senders, this is known as the (S, G) state since it only applies to one sender to one group.
As a result, in Figure 4.14(c), a source-specific route from R1 to the RP is shown (marked by the
dashed line), and a tree from the RP to the receivers is shown that is valid for all senders
(indicated by the solid line).
The next potential optimization is to completely swap out the shared tree for a tree tailored to the
source. This is preferable because the route taken by the RP to connect the sender and receiver
may be considerably longer than the quickest route. Once more, this is most likely to be brought
on by a sender with a high data rate. In this situation, the router at the downstream end of the tree
—use let's R4 as an example—sends a source-specific Join in the direction of the source. This
tree develops (S, G) state as it travels down the shortest path to the source, resulting in a tree
with its root at the source rather than the RP. We would end up with the tree depicted in Figure
4.14 if both R4 and R5 switched to the source-specific tree (d). Note that the RP is now
completely unrelated to this tree. To make the diagram simpler, the shared tree has been
eliminated, but in practice, all routers that have receivers for a group must remain on the shared
