(#) For this reason being that : - application that doesn't use multicast, sends one copy of each packet ( data unit of traffic at layer 3 ) to each client (" who seeks the traffic ). - application that does use multicast, sends one copy of each packet ( data unit of traffic at layer 3 ) to all clients (" who seek the traffic ).
Hence, if we do not use Multicast (for a given application), then bandwidth ( that gets ending up required on the network, where multicast is not being used) becomes proporotional to the count of users ( who use that said application )
(#) In IPv4, there are only three ways of communication:
Request : client ------> server ( Broadcast ) // must be in same network, can not be in different networks. Response: client <----- server ( Broadcast ) // must be in same network, can not be in different networks. client and server need to know each other's networks.
Request : client ------> server ( Unicast ) // can be in same network, can be in different networks, however Router takes a routing decision , per packet ( which wants to go outside its network ) Response: client <------ server ( Unicast ) // can be in same network, can be in different networks, however Router takes a routing decision , per packet ( which wants to go outside its network ) client and server need to know each other's networks.
Request : client -->MG<-- server ( Multicast ) // can be in same network, can be in different networks, however Router takes a routing decision , per MulticastGroup ( which wants to go outside its network ) Source ip address of a multicast datagram is always a Unicast IP Address. Destination ip address of a multicast datagram is always a Multicast IP Address.
client and server do not need to know each other's networks.
=There are three actors/objects/entities in a multicast-baesed traffic-flow(communication):
-Wired/wireless Client : mClient. -Wired/Wireless Server : mServer [ which runs the multicastApplication ( which provides multicastService)] -Multicast Group : which mServer provides which mService (ID identifying this mapping between mServer and mService ).
=Relationship between these actors/objects/entities in a multicast-baesed traffic-flow(communication), can be understood in point #1, #2,and #3, as indicated below:
1 It is a multicast application: - that is used by multicastClients to request the service from the multicastServer . - that is used by a multicastServer to serve the service to the multicastClients.
IF - A multicastClient requests a particular service from a multicastServer . - A multicastServer serves that particular service to the multicastClient .
THEN - both the multicastClient and the multicastServer must be using a same Multicast Application
3 At layer 3, a Multicast IP Address, idenitfies a particular Multicast Service from Particular mServer/mApplication. At layer 2, a Multicast MAC Address, identifies all wired/wireless clients who seek services from that particular mServer/mApplication.
Every Multicast Application, is made aware of this Multicast ip address , either manually or dynamically.
(#) A tree is a collectIon of dots ( mState entries) represents the communication between LHR and RP/mSource in case of Sparse/Dense mode of PIM, respectively.
Trees: [ the illusion of these distribution trees is created by joining the dots; where each dot is an mState entry in mRouting table: (*,G) | (S,G) ] These mState entries ( found in the mRouting tables of the mRTRs ) reveal the way t h i s mRTR is related to its upstream mRTRs (all the way to the leaf of the mTree) w.r.t the specific G (MG) , as in the mState entry. In other words, these entries signify the membership of t h i s mRTR to the upstream routers. Thus, if we do not get these entries, there is no way that the mClients can ever receive mTraffic, because the mTree doesn't even exist to- and-fro w.r.t the source of the traffic, sending data to MG.
mClient's edgeRTR becomes the leaf of the mTree. mServer/mServer's RP becomes the root of the mTree.
VIA PIM, these mTrees : - keep getting built automatically, when the mSource of mTraffic keeps getting searched via unicast routing tables, from the mClient's RTR to RP ( of mSource ) - once built, the mTraffic just slides from the root of the mTree to its leaf and thus reaches the mClien't RTR.
It is the ( *,G ) and ( S,G ) entries in the mRouting tables of the mRTRs, which keep getting inserted , while searching the mSource of a given MG, which act like dots, which when joined together, give the illusion of a mTree.
So, its clear that between the mClient's RTR and the mSource ( of the mTraffic , requested by mClient ), theere can be very well more than one mRTRs. These mRTRs will have their routing tables, which further will have mState entries, revealing how t h i s mRTR is related to a given G (MG). This relationship is depicted via OutgoingInterfaceList (OIL) and IncomingInterfaceList(IIL) of a given mRTR.
OIL refers to the path to the upstream router, toward the mSource ( w.r.t a given MG ) IIL refers to the part to the downstream router, toward the mClient ( w.r.t the given MG ) // so, OIL and IIL mappings are w.r.t a given MG. For different MGs, there can be different OILs and IILs.
It should be clear now, that how the multicast routing tables come to know , how to forward the data from the mSource to the mClient. ( it is due to the mState entries and the Inteface lists ! )
Thus, now we can understand that how by this IIL and OIL, the mSource can talk to its community of mClients.
(#) RPF: - is used to locate the source ip address of a multicast Packet. - is not used to locate the destn ip address of a unicast Packet.
In other words: the multicast traffic, won't be allowed on a given Incoming Interface ( IIL ), unless, that interface won't be the outgoing interface to the mSource as per the unicast routing table ( which stores the shortest path to source of the mPacket which will be that of mSource ).
In yet other words, if an mRTR gets an mPacket, the mRTR check two things of that mPacket : source ip address (S) of that mPacket, and the physical port # of the mRTR, through which the mPacket is trying to get inside the mRTR.
- if , as per the unicast routing table in t h i s mRTR, the path to S is via #, then that mPacket is allowed to enter t h i s mRTR. - if , as per the unicast routing table in t h i s mRTR, the path to S is NOT via #, then that mPacket is disallowed to enter t h i s mRTR.
RPF check is towards the RP, in case of PIM Sparse mode. RPF check is towards the S , in case of PIM Dense mode.
Multicast ensures that only those clients get the data , who want it.
So that, a multicastClient ( wired/wireless) can submit its expressionOfInterest to receive traffic from a particular Multicast Group, Hence, every multicastClient needs to know ( corresponding to the MulticastGroup, whose service is being requested by the multicastClient ) : - the MG's layer3-id (ip addresss) , at the time of sending request, to THAT MULTICAST GROUP. - the MG's layer2-id (mac address) , at the time of receiving the service, from THAT MULTICAST GROUP. (if IGMP snooping is enabled)
Thus: - at layer 2, the multicastApplication ( that knows the ip address of the multicastService) converts the mIP into mMAC and binds it to the NIC of the mClient. - Now, the moment mTraffic reaches the network of the mClient ( at layer 2 ), the traffic gets forwarded ONLY to those nodes sharing the same mMAC .